🔒 Guided

Pre-launch preview. Authorised access only.

Incorrect code

Guided by A Guide to Cloud
Explore AB-900 AI-901
Guided DP-900 Domain 2
Domain 2 — Module 1 of 7 14%
8 of 27 overall

DP-900 Study Guide

Domain 1: Core Data Concepts

  • Your First Look at Data Free
  • Data File Formats: CSV, JSON, Parquet & More Free
  • Databases: Relational vs Non-Relational Free
  • Transactional Workloads: Keeping Data Consistent Free
  • Analytical Workloads: Finding the Insights Free
  • Data Roles: DBA, Engineer & Analyst Free
  • The Azure Data Landscape Free

Domain 2: Relational Data on Azure

  • Relational Data: Tables, Keys & Relationships
  • Normalization: Why Duplicate Data is Bad
  • SQL Basics: SELECT, INSERT, UPDATE, DELETE
  • Database Objects: Views, Indexes & More
  • Azure SQL: Your Database in the Cloud
  • Open-Source Databases on Azure
  • Choosing the Right Azure Database

Domain 3: Non-Relational Data on Azure

  • Azure Blob Storage: Files in the Cloud
  • Azure Files & Table Storage
  • Azure Cosmos DB: The Global Database
  • Cosmos DB APIs: SQL, MongoDB & More
  • Choosing Non-Relational Storage

Domain 4: Analytics on Azure

  • Data Ingestion & Processing
  • Analytical Data Stores: Data Lakes, Warehouses & Lakehouses
  • Microsoft Fabric & Azure Databricks
  • Batch vs Streaming: Two Speeds of Data
  • Real-Time Analytics on Azure
  • Power BI: See Your Data
  • Data Models in Power BI
  • Choosing the Right Visualization

DP-900 Study Guide

Domain 1: Core Data Concepts

  • Your First Look at Data Free
  • Data File Formats: CSV, JSON, Parquet & More Free
  • Databases: Relational vs Non-Relational Free
  • Transactional Workloads: Keeping Data Consistent Free
  • Analytical Workloads: Finding the Insights Free
  • Data Roles: DBA, Engineer & Analyst Free
  • The Azure Data Landscape Free

Domain 2: Relational Data on Azure

  • Relational Data: Tables, Keys & Relationships
  • Normalization: Why Duplicate Data is Bad
  • SQL Basics: SELECT, INSERT, UPDATE, DELETE
  • Database Objects: Views, Indexes & More
  • Azure SQL: Your Database in the Cloud
  • Open-Source Databases on Azure
  • Choosing the Right Azure Database

Domain 3: Non-Relational Data on Azure

  • Azure Blob Storage: Files in the Cloud
  • Azure Files & Table Storage
  • Azure Cosmos DB: The Global Database
  • Cosmos DB APIs: SQL, MongoDB & More
  • Choosing Non-Relational Storage

Domain 4: Analytics on Azure

  • Data Ingestion & Processing
  • Analytical Data Stores: Data Lakes, Warehouses & Lakehouses
  • Microsoft Fabric & Azure Databricks
  • Batch vs Streaming: Two Speeds of Data
  • Real-Time Analytics on Azure
  • Power BI: See Your Data
  • Data Models in Power BI
  • Choosing the Right Visualization
Domain 2: Relational Data on Azure Premium ⏱ ~12 min read

Relational Data: Tables, Keys & Relationships

Relational databases are the backbone of business software. Let's explore how they organise data into tables and connect them with keys.

How relational databases organise data

☕ Simple explanation

A relational database is like a collection of spreadsheets that link to each other.

Each spreadsheet (table) has column headers (schema) and rows of data (records). The clever part: tables can point to each other. A “Customers” spreadsheet and an “Orders” spreadsheet share a Customer ID — so you can instantly find all orders for a specific customer.

This linking between tables is what makes them “relational.”

A relational database organises data into tables (relations) with a predefined schema. Each table has a fixed set of columns (attributes) with defined data types, and stores data as rows (records/tuples). Tables are connected through key relationships — primary keys uniquely identify rows, and foreign keys reference primary keys in other tables to establish links between entities.

This model, based on E.F. Codd’s relational algebra (1970), enforces referential integrity and enables powerful querying through SQL joins across multiple tables.

Core concepts

Tables, rows, and columns

A table represents one type of entity — customers, orders, products, drivers.

TermAlso CalledWhat It Is
TableRelation, entityA collection of related data with a fixed schema
ColumnAttribute, fieldA named property with a data type (text, number, date)
RowRecord, tupleOne instance of the entity (one customer, one order)
SchemaTable definitionThe blueprint: column names, types, and constraints

Tom’s example — Pacific Freight has a Drivers table:

DriverIDNameLicenceClassHireDate
D001Sarah ParkClass 52023-06-15
D002James TuiClass 22024-01-10

Every row follows the same structure. Every column has a defined type. That’s the relational model.

Primary keys

A primary key uniquely identifies each row in a table. No two rows can have the same primary key, and it can never be null (empty).

  • In the Drivers table, DriverID is the primary key
  • In a Customers table, it might be CustomerID or an auto-generated number

Primary keys can be:

  • Natural keys: A real-world value that’s already unique (email address, licence number)
  • Surrogate keys: A system-generated value with no business meaning (auto-increment ID, GUID)

Foreign keys

A foreign key is a column in one table that references the primary key of another table. This creates a relationship between them.

Tom’s example: A Deliveries table links to the Drivers table:

DeliveryID (PK)DestinationDateDriverID (FK)
DEL-501Auckland CBD2026-04-20D001
DEL-502Hamilton2026-04-20D002
DEL-503Wellington2026-04-21D001

DriverID in the Deliveries table is a foreign key — it points to DriverID in the Drivers table. This means:

  • You can find which driver handled each delivery
  • You can find all deliveries for a specific driver
  • The database won’t let you assign a delivery to a driver that doesn’t exist (referential integrity)

Types of relationships

RelationshipExampleHow It Works
One-to-manyOne driver → many deliveriesMost common. FK in the “many” table points to PK in the “one” table
Many-to-manyMany products → many ordersNeeds a junction table (OrderItems) linking the two
One-to-oneOne driver → one licence recordFK with a unique constraint. Used to split large tables
ℹ️ Junction tables for many-to-many

When two entities have a many-to-many relationship (one order has many products, one product appears in many orders), you need a junction table (also called a bridge table or associative table).

Example: Products and Orders

OrderItems (junction)
OrderID (FK)ProductID (FK)
ORD-101PROD-A
ORD-101PROD-B
ORD-102PROD-A

The junction table has two foreign keys — one pointing to Orders, one pointing to Products.

💡 Exam tip: key recognition

The exam tests your understanding of keys and relationships. Quick guide:

  • “Uniquely identifies each row” → Primary key
  • “References another table” → Foreign key
  • “Prevents orphaned records” → Referential integrity (via foreign keys)
  • “One customer has many orders” → One-to-many relationship
  • “Students enrolled in courses, courses have many students” → Many-to-many (needs junction table)

Flashcards

Question

What is a primary key?

Click or press Enter to reveal answer

Answer

A column (or combination of columns) that uniquely identifies each row in a table. It must be unique and never null.

Click to flip back

Question

What is a foreign key?

Click or press Enter to reveal answer

Answer

A column in one table that references the primary key of another table. It creates a relationship between the two tables and enforces referential integrity.

Click to flip back

Question

What is referential integrity?

Click or press Enter to reveal answer

Answer

A rule that ensures foreign key values always reference existing primary key values. The database won't let you create an orphaned record (e.g., an order for a customer that doesn't exist).

Click to flip back

Knowledge check

Knowledge Check

Tom's Deliveries table has a DriverID column that points to the Drivers table. What type of key is DriverID in the Deliveries table?

Knowledge Check

Aisha's food app needs to track which students have ordered which menu items. One student can order many items, and one item can be ordered by many students. What does Aisha need?

🎬 Video coming soon

Next up: Normalization: Why Duplicate Data is Bad — learn why relational databases split data across tables.

← Previous

The Azure Data Landscape

Next →

Normalization: Why Duplicate Data is Bad

Guided

I learn, I simplify, I share.

A Guide to Cloud YouTube Feedback

© 2026 Sutheesh. All rights reserved.

Guided is an independent study resource and is not affiliated with, endorsed by, or officially connected to Microsoft. Microsoft, Azure, and related trademarks are property of Microsoft Corporation. Always verify information against Microsoft Learn.