Delve into the Dataverse
Connecting Data with Connectors
The course is part of this learning path
This course explores the core components of Microsoft's Power Platform, including the Microsoft Dataverse, common data model, compliance, connecting data to Power Platform, and the AI Builder.
- Learn about the Microsoft Dataverse and the Common Data Model
- Learn about Power Platform environments and data compliance
- Understand the types of connectors you can use within Power Platform
- Explore the AI Builder and various low- to no-code use cases for various AI Models
This course is for anyone who wants to understand the core components within the Power Platform and who wants additional insight into how their data connects within it.
To get the most out of this course you should already have a basic understanding of Power Platform. Before embarking on this course, we recommend that you take our course "Understanding the Business Value of Microsoft Power Platform" beforehand.
Since the Dataverse is built utilizing the common data model, we need to understand the building blocks of it and how tables apply. Data within the Dataverse is contained within tables following the standards set in the common data model. Breaking this down into its core components, there are tables, columns, and relationships. An effective way to visualize this is something like a table in an Excel spreadsheet. Spreadsheets have tables, rows, columns, and can reference other cells or other tables. To keep that visualization in mind when thinking of tables in the Dataverse. There are two types of tables, standard and complex.
Standard tables are simply the standard tables created in a Dataverse database and a complex table contains things like business logic and plugins. These tables can be defined as a logical structure containing rows and columns that represent a set of data where columns actually define data stored within the table. To clarify, let's visualize the Excel table again. Let's say you have a table labeled expenses, which houses data for organizational expenses. While the table contains all the data pertaining to expenses, each column in that table classifies that data by defining it.
So a table called the expenses might have columns of data like a vendor, date and cost. All of which are labels that define the data stored in each of those columns. Now, this can go a step further by adding in relationships. Relationships, as you may have guessed, are how different sets of data relate to one another. Relationships can be one to one, one to many, or many to many simply referring to how many relationships apply to any given set of data. These are particularly useful when you have data that is relatable to one another, but doesn't necessarily make logical sense to put together into the same table.
An example of this would be something like customers and invoices. While you could technically put invoices and customers into the same table, it doesn't necessarily make sense since you may need data from either of those topics, for something unrelated to the other. So you could instead create two separate tables, one for customers and one for invoices, and then relate the data in them, creating a relationship between the two tables. That way you don't have unnecessary columns within either of these tables, but you can still relate the data and gather insights from it without hassle. And that's tables, columns, and relationships. Next, we move into how data can be broken up in a different environment and what that means for managing and interacting with your data.
Lee has spent most of his professional career learning as much as he could about PC hardware and software while working as a PC technician with Microsoft. Once covid hit, he moved into a customer training role with the goal to get as many people prepared for remote work as possible using Microsoft 365. Being both Microsoft 365 certified and a self-proclaimed Microsoft Teams expert, Lee continues to expand his knowledge by working through the wide range of Microsoft certifications.