# Data model

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/data-model

## Quick definition

A data model is like a map for your data. It decides what kind of information you can store, how different pieces of information relate to each other, and what rules they must follow. Think of it as the structure that turns raw data into something useful and organized.

## Simple meaning

Imagine you are building a library. Before you put a single book on a shelf, you need to decide how to organize the books. You could sort them by genre, by author's last name, or by title. You also need to decide what information to record about each book, like the title, the author, the publication year, and the genre. A data model is exactly that kind of plan, but for digital information. 

In everyday terms, a data model is a set of rules that tells a database what to expect. For example, if you are creating an online store, your data model would say that every product must have a name, a price, and a category. It would also say that a customer can have multiple orders, but each order belongs to only one customer. Without these rules, data would be messy and inconsistent, like a library where books are piled in random stacks. 

A data model also enforces relationships. In our library analogy, you might want to know which books a specific person has borrowed. Your model would create a link between the "Person" table and the "Book" table. This link ensures that when you look up a person, you can see all the books they borrowed, and when you look up a book, you can see who borrowed it. 

Finally, a data model helps you decide what kind of database to use. Some models work best with rigid, table-based storage, like a spreadsheet. Others are more flexible and allow for nested data, like a folder on your computer. The choice depends on what you are building and how you plan to use the data.

## Technical definition

In the context of Azure data services and the DP-900 exam, a data model is a formalized abstraction that defines the structure, constraints, operations, and relationships of data within a database system. It is not the data itself but the schema that dictates how data can be stored, queried, and manipulated. A data model consists of three primary components: the structural part (the types of data and their organization), the integrity part (rules that ensure data correctness), and the manipulation part (operations allowed on the data). 

There are several types of data models relevant to the Azure data ecosystem. The **relational data model** is the most common, organizing data into tables (relations) with rows (tuples) and columns (attributes). It enforces integrity through primary keys (unique identifiers for each row) and foreign keys (links between tables). In Azure, relational data is typically stored in Azure SQL Database, Azure SQL Managed Instance, or SQL Server on Azure Virtual Machines. 

The **entity-relationship data model** is a high-level conceptual model used to map business requirements before creating a physical database. It visually represents entities (like "Customer" or "Order") and their relationships (like "places"). This model is essential for designing normalized databases. 

The **non-relational (NoSQL) data model** includes several sub-types. The **key-value model** is used in Azure Cosmos DB for Redis Cache and Azure Table Storage, where each item has a unique key and a blob of data. The **document model** stores data in JSON documents, with Azure Cosmos DB being a primary example. The **column-family model** is used by Azure Cosmos DB for Cassandra API and stores data in rows that can have different columns. The **graph model** focuses on relationships between entities, used in Azure Cosmos DB for Gremlin API. 

Azure data services also support **dimensional models** used in data warehousing, such as star schemas and snowflake schemas. These models are optimized for read-heavy analytical queries and are implemented in Azure Synapse Analytics, Azure Data Lake Storage, and Azure Databricks. 

The process of creating a data model involves three stages: conceptual, logical, and physical. The conceptual model defines the business entities and their relationships in plain terms. The logical model adds details like attributes and data types, independent of any specific database technology. The physical model is the actual implementation in a particular database system, including indexes, partitions, and storage details. 

In the DP-900 exam, you are expected to understand the differences between these models, when to use each one, and how Azure implements them. You should also know how data models affect performance, scalability, and consistency, especially when choosing between relational and non-relational solutions.

## Real-life example

Think about a family recipe box. You have many recipe cards. Each card has a structure: the recipe name at the top, a list of ingredients, step-by-step instructions, and maybe a note about who gave you the recipe. That fixed structure is a kind of data model. Every card follows the same rules, so you can easily find what you need. 

Now imagine you want to organize these recipes for a big family reunion. You could sort them by course (appetizer, main course, dessert). That is another kind of data model: it defines categories and which recipe belongs to which category. If you later want to know all the recipes your grandmother contributed, you would need a link between the recipe and the person. Your model would need to include a field for "contributor" so you can filter by that. 

In digital terms, this is exactly how a database works. The recipe cards are rows in a table. The fields on the card are columns. The categories are a second table, and the link between them is a relationship. If you change the data model (for example, adding a new field for "cooking time"), you need to update all the cards. In a database, that means altering the table schema. 

A data model also prevents chaos. Without a model, someone might write the recipe on a napkin or use shorthand that nobody else understands. With a model, everyone follows the same format, ensuring consistency. This is why data modeling is the first step in building any data system, whether it is a simple app or a global cloud service like Azure.

## Why it matters

In practical IT, a well-designed data model is the foundation of every data-driven application. It determines how efficiently you can store, retrieve, and update information. A bad data model leads to slow queries, data duplication, and difficult-to-maintain code. For example, if you model an e-commerce site without normalizing the data, you might end up storing the same customer address in every order record, wasting storage and risking inconsistency. 

Data models directly affect scalability. In Azure, choosing between a relational model and a NoSQL model can mean the difference between a system that scales vertically (bigger server) or horizontally (more servers). The DP-900 exam covers this tradeoff: relational models offer strong consistency and complex queries, while NoSQL models offer high throughput and flexible schemas. 

Security also ties into data modeling. When you define relationships, you also define access boundaries. For example, a data model that separates customer data from payment data can help you comply with regulations like GDPR. Azure services like Azure SQL Database use the data model to implement row-level security and column-level encryption. 

From a career perspective, data modeling is a skill that distinguishes junior from senior roles. Understanding how to design a star schema in Azure Synapse Analytics or how to model a document database in Azure Cosmos DB opens doors to roles in data engineering, data analysis, and solution architecture. 

Finally, data models drive cost. In cloud environments, storage and compute consumption are directly tied to how you organize data. A poorly modeled dataset might require more storage space and more processing power, increasing your Azure bill. Therefore, mastering data model concepts is not just about passing the exam, it is about building cost-effective and performant systems.

## Why it matters in exams

For the DP-900 Azure Data Fundamentals exam, understanding data models is essential because the entire exam is structured around different data storage paradigms and their appropriate use cases. The exam objectives explicitly include describing core data concepts, working with relational and non-relational data, and identifying appropriate Azure data services. Each of these areas relies on a solid grasp of data models. 

One of the key skills measured in the DP-900 is the ability to differentiate between relational and non-relational data models. You will see questions that present a scenario, such as a company needing to store user profiles that have varying attributes, and ask you to recommend either Azure SQL Database or Azure Cosmos DB. The correct answer depends on recognizing that a document data model (NoSQL) handles schemaless data better than a rigid relational model. 

Another exam topic is the concept of normalization. You need to understand that a relational data model uses normal forms to reduce redundancy and improve data integrity. The DP-900 does not require deep knowledge of all normal forms, but you should know that breaking data into multiple related tables (like separate tables for Customers, Orders, and Products) is standard practice. 

Data modeling also appears in questions about data consistency. For example, you might need to explain that relational models offer ACID (Atomicity, Consistency, Isolation, Durability) compliance, while NoSQL models often offer eventual consistency. The exam will test your ability to match consistency requirements with the correct data model. 

you should be familiar with dimensional modeling for analytics. The DP-900 includes concepts like star schemas and snowflake schemas, which are specific types of data models used in data warehousing. Knowing the difference between fact tables (measurable events) and dimension tables (descriptive attributes) is crucial. 

Finally, exam questions may ask you to identify the correct Azure service for a given data model. For instance, if the model requires complex joins and transactions, you choose Azure SQL Database. If the model is a key-value store, you choose Azure Cosmos DB or Azure Table Storage. These questions test your ability to map conceptual data models to real Azure services. 

To prepare, focus on the official Microsoft Learn modules for DP-900, especially the ones on core data concepts and working with relational and non-relational data. Practice identifying data model types from descriptions, and be comfortable with the trade-offs between different models.

## How it appears in exam questions

In the DP-900 exam, data model concepts are tested through scenario-based questions, definition matching, and service recommendation tasks. You will rarely be asked to directly define a data model. Instead, you will be given a business requirement and asked to choose the appropriate Azure service or data storage approach. For example, a question might describe a company that needs to store customer feedback forms where each form has a different set of questions. The correct answer would be to use a document database like Azure Cosmos DB because its document data model supports a flexible schema. 

Another common pattern is the comparison question. The exam might list two Azure services, such as Azure SQL Database and Azure Cosmos DB, and ask you to identify which one uses a relational data model. The trap here is that Azure Cosmos DB can also support a relational API (like the PostgreSQL API), but the core data model is still document-based. You need to know that the default and most common model for Cosmos DB is non-relational. 

You will also encounter questions about the components of a data model. For example, you might be asked to identify what a primary key is or what a foreign key does. These are simple multiple-choice questions that test your understanding of relational model constraints. A typical wrong answer might call a foreign key a unique identifier for a row, whereas it is actually a link to a primary key in another table. 

Data model types come up in drag-and-drop or multiple-select questions. You might be given three data model descriptions and asked to match them to the correct type: relational, key-value, document, column-family, or graph. For instance, a description stating "data is stored in JSON documents with nested fields" should be matched to the document data model. 

Troubleshooting-style questions are less common in DP-900, but you might see a scenario where a database query is slow, and you need to identify the root cause as a poorly chosen data model. For example, storing hierarchical data in a single flat table without using proper relationships can lead to slow queries. The fix would be to normalize the data or use a graph data model. 

there are questions on data modeling for analytics. You might be asked to identify a star schema from a description. For example, a scenario where a sales fact table is linked to date, product, and store dimension tables. The correct answer would be star schema. These questions test your ability to recognize dimensional modeling patterns. 

To handle these questions, always read the scenario carefully. Note keywords like "flexible schema", "ACID compliance", "complex relationships", or "JSON documents". Map those keywords to the correct data model type and then to the corresponding Azure service.

## Example scenario

You work for a small library that wants to build a digital catalog. The library has books, authors, and members. You need to design a database to store information about each book, who wrote it, and which members have borrowed books. This is a classic case for using a relational data model. 

First, you create a table called Books. Each book has a unique BookID, a title, an ISBN number, a publication year, and a genre. You also create a table called Authors, with AuthorID, name, and birth year. To link books to authors, you add a column called AuthorID in the Books table, which is a foreign key pointing to the Authors table. This way, you can query which books a particular author wrote without storing the author's name multiple times. 

Next, you create a Members table with MemberID, name, and contact information. Then you need to track borrowing. You create a Loans table with LoanID, BookID, MemberID, and loan date. This table connects books to members. Since a member can borrow multiple books over time, the Loans table has many rows for the same member. This relationship is a one-to-many relationship: one member can have many loans. 

Now imagine the library wants to add e-books that can have multiple file formats and multiple authors. Your relational model should handle this. You can create a junction table called BookAuthors for books with multiple authors, and a FileFormats table linked to Books. This preserves data integrity and avoids duplication. 

If you had chosen a non-relational model like a document database, you might store each book as a JSON document containing all its authors and formats nested inside. That could work too, but it would make it harder to query all books by a specific author or to update an author's name across multiple documents. The relational model is better here because relationships are explicit and queries across linked data are efficient. 

This scenario shows how the data model you choose affects the entire system design. For the DP-900 exam, you need to recognize when a relational model is appropriate (structured data with clear relationships) versus when a NoSQL model is better (high volume, flexible schema, or hierarchical data).

## Common mistakes

- **Mistake:** Assuming all data models are the same as relational models.
  - Why it is wrong: Data models include relational, document, key-value, column-family, and graph. Each is designed for different use cases. Thinking only of relational limits your ability to choose the right Azure service.
  - Fix: Learn the characteristics of each model type. For example, document models store JSON, key-value models use simple key lookups, and graph models focus on relationships.
- **Mistake:** Confusing a data model with a database management system (DBMS).
  - Why it is wrong: A data model is the conceptual structure, while a DBMS is the software that implements it. Azure SQL Database is a DBMS that uses the relational data model. They are not interchangeable terms.
  - Fix: Remember: data model = blueprint, DBMS = construction crew. The blueprint (model) guides what the crew (DBMS) builds.
- **Mistake:** Thinking that a key-value data model supports complex queries like joins.
  - Why it is wrong: Key-value stores like Azure Table Storage only allow lookups by key. They do not support relational joins or complex filtering. Trying to use them for reporting queries leads to performance issues.
  - Fix: Use key-value models only for simple, high-speed lookups. For complex queries, choose a relational or document model.
- **Mistake:** Believing that a document data model is schemaless, so no structure is needed.
  - Why it is wrong: While the schema is flexible, you still need to design your documents to meet application needs. An unstructured document store can become chaotic and hard to query.
  - Fix: Plan your document structure ahead of time. Keep related data together and use indexes on fields you will frequently query.
- **Mistake:** Assuming dimensional models are only for large enterprises.
  - Why it is wrong: Dimensional models like star schemas are used in data warehousing, but they are relevant for any analytical workload, even for small datasets. Ignoring them means missing out on optimized query performance.
  - Fix: Learn the basics of star and snowflake schemas. They are testable in DP-900 and useful in real projects using Azure Synapse Analytics.

## Exam trap

{"trap":"The exam presents a scenario where a company needs to store user settings with varying fields, and the options include Azure SQL Database and Azure Cosmos DB. Learners pick Azure SQL Database because they think relational is always better.","why_learners_choose_it":"Learners are comfortable with relational databases and assume they are the default choice. They overlook the fact that user settings often have a flexible schema that does not fit well into rigid tables.","how_to_avoid_it":"Read the scenario for keywords like 'flexible', 'varying attributes', 'schemaless'. For flexible schemas, document models in Azure Cosmos DB are the correct choice. Relational models require pre-defined columns and are harder to adapt."}

## Commonly confused with

- **Data model vs Database schema:** A database schema is the actual implementation of a data model in a specific database system. The data model is the abstract design, while the schema is the concrete set of tables, columns, and constraints. For example, the relational data model is a concept, while a Customer table with ID, Name, and Email columns is a schema. (Example: You design a data model that says 'each customer has a name and email'. The schema is the actual SQL CREATE TABLE statement that creates the Customer table.)
- **Data model vs Entity-relationship diagram (ERD):** An ERD is a visual representation of a data model. It shows entities as boxes and relationships as lines. The data model is the underlying logic and rules, while the ERD is the picture of that logic. You can have a data model without an ERD, but the ERD helps communicate the model. (Example: Your data model includes the rule that a customer can have multiple orders. An ERD would show a box for Customer, a box for Order, and a line connecting them with a '1' on one side and many lines on the other.)
- **Data model vs Data structure:** Data structure is a broader term that refers to how data is organized in memory or storage, such as arrays, lists, or trees. A data model is a high-level design for a database, while a data structure is a specific implementation detail. Data models often use data structures internally, but they are not the same. (Example: A linked list is a data structure. The relational data model uses B-trees as an internal data structure for indexes, but the model itself is about tables and relationships.)

## Step-by-step breakdown

1. **Identify the business requirements** — Before you design a data model, you must understand what the system needs to do. What data must be stored? How will it be queried? What are the relationships between entities? This step is the same for any Azure data service.
2. **Create a conceptual data model** — List the main entities (like Customer, Product, Order) and their relationships. Use plain language. This is a rough sketch that does not involve any technical details. It helps you communicate with stakeholders.
3. **Transform to a logical data model** — Add attributes to each entity, define keys, and specify relationships more precisely. For example, the Customer entity now has CustomerID (primary key), Name, and Email. The Order entity has OrderID and CustomerID (foreign key). This model is technology-agnostic.
4. **Choose the appropriate type of data model** — Based on the logical model, decide whether to use a relational, document, key-value, column-family, or graph model. Consider factors like data shape, query patterns, consistency needs, and scalability. For example, if entities have nested data, a document model might be better.
5. **Create the physical data model** — Implement the logical model in a specific Azure data service. This means writing schema definitions, setting up indexes, defining partitions, and selecting data types. For Azure SQL Database, this involves CREATE TABLE statements. For Azure Cosmos DB, it involves defining container structures and indexing policies.
6. **Test and refine the model** — Run sample queries to verify that the model performs as expected. Optimize indexes, adjust partitioning, and normalize or denormalize as needed. Monitoring performance in Azure is crucial, especially for production workloads.

## Practical mini-lesson

When working with Azure data services, choosing the right data model is a decision that impacts everything from application code to cost. Let us go through a practical example. Suppose you are building a catalog for an online clothing store. Each product has a name, price, category, and a set of attributes like size, color, and material. Some products have many attributes, some have few. This is a classic case for a document data model. 

In Azure Cosmos DB, you would create a container for products. Each product is a JSON document. The flexibility of the document model allows you to have a field for 'size' only if the product is clothing, and a field for 'screen size' only for electronics. In a relational model, you would need separate tables for entity-attribute-value design, which is complex and slow. 

Now consider that the same store also needs to process customer orders. Each order has multiple line items, and each line item references a product. This is where relationships become important. In a document model, you could embed the line items inside the order document. That works well if the number of line items per order is small and you always fetch the entire order. But if you need to query all orders for a specific product, embedded documents make that query expensive because you have to scan all order documents. A better approach might be to use a relational model for orders and line items, and keep the product catalog in a document model. This hybrid approach uses the strengths of both data models. 

Professionals also need to consider index management. In Azure Cosmos DB, you can define custom indexing policies to speed up queries. In Azure SQL Database, indexes are crucial for performance. Understanding how the data model influences indexing is key. For example, in a document model, you might create a composite index on category and price to speed up a catalog search. In a relational model, you would create a non-clustered index on the same columns. 

What can go wrong? One common pitfall is over-normalizing a relational model. Breaking data into too many tiny tables with excessive joins can cripple performance. Another is under-documenting the data model, leading to confusion during maintenance. In the cloud, poor modeling can lead to high RU/s (Request Units per second) charges in Cosmos DB or high DTU (Database Transaction Unit) usage in Azure SQL Database. 

To avoid these issues, always prototype your model with realistic data. Use Azure tools like Azure Data Studio to test queries. For DP-900, you do not need to be an expert in tuning, but you must understand that the data model directly affects which Azure service is appropriate and how well that service performs.

## Memory tip

Data Model = The Blueprint of Data. The three types are 'Flat' (like a spreadsheet), 'Linked' (like tables with connections), and 'Flexible' (like nested documents).

## FAQ

**What is the simplest way to understand a data model?**

Think of it as the plan for a building. You decide where the rooms, doors, and windows go, and you set the rules for how they connect. A data model does the same for your data.

**Do I need to know multiple data models for the DP-900 exam?**

Yes. You need to understand relational, document, key-value, column-family, and graph models. The exam tests your ability to choose the right model for a given scenario.

**Is a relational data model always better than a NoSQL model?**

No. Relational models are great for structured data with complex relationships and strong consistency. NoSQL models are better for high scalability, flexible schemas, and simple lookups. The best choice depends on the use case.

**What is the difference between a conceptual and a logical data model?**

A conceptual model is high-level and uses business language. A logical model adds details like attributes and keys but is still independent of any database technology. The conceptual model is the first draft, and the logical model is the detailed blueprint.

**Does Azure Cosmos DB use a relational data model?**

Azure Cosmos DB is primarily a non-relational database that supports multiple data models (document, key-value, column-family, graph) through its various APIs. However, it also offers a relational API (PostgreSQL), but its core architecture is non-relational.

**How does a data model affect query performance?**

A well-designed data model allows efficient indexing and joins. A poor model can cause slow queries because the database has to scan many rows or documents. In Azure Cosmos DB, a proper data model can reduce Request Units (RU) cost significantly.

**Can I change a data model after it is implemented?**

Yes, but it can be costly and complex. In relational databases, altering tables can cause downtime and require data migration. In NoSQL databases, altering the schema is easier because they support flexible schemas, but you may still need to update application code.

## Summary

A data model is the foundational blueprint for any data storage system in Azure. It determines how data is structured, related, and accessed. Understanding the different types of data models, including relational, document, key-value, column-family, and graph, is critical for the DP-900 exam and for real-world cloud data solutions. 

In the DP-900 exam, you will be tested on your ability to match data model types to business requirements and to choose the appropriate Azure data service. Common traps include forgetting that NoSQL models are not schemaless in the sense of no structure, and assuming relational models are always superior. 

For your career, mastering data modeling helps you design efficient, scalable, and cost-effective systems. It is a skill that spans all roles from developer to data architect. Always start by understanding the business needs, then choose the model and service that fits best. 

Use the memory tip 'Data Model = The Blueprint of Data' to remember its importance. Practice identifying models from scenario descriptions, and you will be well prepared for the exam and your future projects.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/data-model