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.