DP-900 Core Concept

Relational vs Non-Relational Databases on Azure: Complete DP-900 Guide

Two domains of the DP-900 exam are dedicated to relational and non-relational data. Understanding the difference — and knowing which Azure service implements each — is foundational to passing.

By MSCertQuiz TeamUpdated March 202618 min read

DP-900 Exam Coverage

Domain 2 (Relational Data, 25%) and Domain 3 (Non-Relational Data, 25%) together make up 50% of the DP-900 exam. These two domains are where most of the Azure service selection and data modeling questions come from. Mastering the relational vs non-relational distinction is essential.

The Core Difference: Relational vs Non-Relational

Relational Databases (SQL)

Data is organized into tables with rows and columns. Tables are related to each other through keys. The schema (structure) is defined before data is inserted.

• Fixed, predefined schema

• Tables with rows and columns

• Relationships via primary/foreign keys

• ACID transactions

• Query with SQL (Structured Query Language)

• Normalized to reduce redundancy

• Scales vertically (larger hardware)

Non-Relational Databases (NoSQL)

Data is organized in flexible structures — documents, key-value pairs, columns, or graphs. Schema is flexible or absent. Multiple data models exist for different use cases.

• Flexible or dynamic schema

• Documents, key-value, columns, or graph

• Relationships handled differently per model

• Eventual to strong consistency (configurable)

• Query varies by database type

• Denormalized for performance

• Scales horizontally (more servers)

Relational Database Concepts for DP-900

Domain 2 of DP-900 covers relational data concepts. Here are the key concepts the exam tests:

Tables, Rows, and Columns

The fundamental structure of relational data. A table represents an entity (Customers, Orders, Products). Each row is one instance. Each column is one attribute.

Exam tip: "Entity" in modeling becomes "table" in the database. "Attribute" becomes "column." "Instance" becomes "row/record."

Primary Keys and Foreign Keys

A primary key uniquely identifies each row in a table (e.g., CustomerID). A foreign key in one table references the primary key of another table to create a relationship (e.g., Orders.CustomerID references Customers.CustomerID).

Exam tip: Know that foreign keys enforce referential integrity — you cannot insert an order for a CustomerID that doesn't exist in the Customers table.

Normalization

The process of organizing tables to reduce data redundancy. Normalization splits data across multiple related tables rather than storing it all in one flat table.

Exam tip: DP-900 tests the concept of normalization but not the specific normal forms (1NF, 2NF, 3NF) in depth. Know that normalization reduces duplication and improves consistency.

SQL: SELECT, INSERT, UPDATE, DELETE

The four core DML (Data Manipulation Language) statements. The exam may show basic SQL syntax. Know: SELECT retrieves data, INSERT adds rows, UPDATE modifies rows, DELETE removes rows.

DDL (Data Definition Language) statements: CREATE TABLE, ALTER TABLE, DROP TABLE — these define the schema structure.

Exam tip: Know DDL vs DML. DDL modifies structure; DML modifies data.

Database Objects: Views, Indexes, Stored Procedures

View: A saved SELECT query presented as a virtual table. Simplifies complex queries for users.

Index: A data structure that speeds up SELECT queries on specific columns at the cost of slower INSERT/UPDATE/DELETE operations.

Stored Procedure: Pre-compiled SQL code stored in the database that can be called by name. Accepts parameters and can return results.

Azure Relational Database Services

ServiceEngineBest ForKey Differentiator
Azure SQL DatabaseSQL ServerCloud-native applicationsServerless option, hyperscale tier, always-updated
Azure SQL Managed InstanceSQL ServerSQL Server migrationNear-100% SQL Server compatibility, SQL Agent, CLR
SQL Server on Azure VMSQL ServerFull control, legacy appsIaaS — you manage OS and SQL Server
Azure Database for PostgreSQLPostgreSQLOpen-source PostgreSQL workloadsFlexible Server, Hyperscale (Citus) for distributed
Azure Database for MySQLMySQLWeb applications, WordPressFlexible Server, compatible with MySQL community
Azure Database for MariaDBMariaDBMariaDB workloadsManaged MariaDB, MySQL fork compatibility

Non-Relational Data Models

Domain 3 covers four types of non-relational data models. The exam tests when to use each and which Azure service implements each:

Key-Value

The simplest NoSQL model. Each item has a unique key and an associated value. The value can be anything — a string, number, JSON blob, or binary. No schema required.

Use when: Session state, user preferences, shopping carts, caching. Simple lookup by key with no complex queries needed.

Azure service: Azure Cosmos DB (Table API), Azure Cache for Redis, Azure Table Storage

Document

Data stored as semi-structured documents — typically JSON or BSON. Each document can have a different structure. Documents are organized into collections.

Use when: Product catalogs (different products have different attributes), user profiles with optional fields, content management, any data with variable structure.

Azure service: Azure Cosmos DB (NoSQL API or MongoDB API)

Column-Family (Wide-Column)

Data stored in column families — groups of related columns. Each row can have a different set of columns. Highly efficient for queries that read specific column families.

Use when: Time-series data, IoT telemetry, log data, large-scale write-heavy workloads. Excellent when different rows have different attributes.

Azure service: Azure Cosmos DB (Cassandra API)

Graph

Data stored as vertices (nodes) and edges (relationships). Vertices are entities; edges define how entities are related. Relationships are first-class data, not just foreign keys.

Use when: Social networks (friendships), recommendation engines (users → products), fraud detection (transaction relationships), knowledge graphs.

Azure service: Azure Cosmos DB (Gremlin API)

Exam Decision Framework

Use this framework when the DP-900 exam asks you to choose between relational and non-relational options:

Scenario signals: Fixed schema, relationships between entities, ACID transactions needed

→ Relational (Azure SQL Database or SQL Managed Instance)

Scenario signals: Variable schema, documents with different fields per item

→ Cosmos DB NoSQL API (document store)

Scenario signals: Simple key-value lookups with no complex queries

→ Cosmos DB Table API or Azure Table Storage

Scenario signals: Graph relationships, friend-of-friend, recommendation engine

→ Cosmos DB Gremlin API

Scenario signals: Time-series, IoT, log data, write-heavy, existing Cassandra app

→ Cosmos DB Cassandra API

Scenario signals: Existing MongoDB application migrating to Azure

→ Cosmos DB MongoDB API

Scenario signals: Global distribution, low latency SLA, horizontal scaling

→ Azure Cosmos DB (any relevant API)

Scenario signals: SQL Server migration with SQL Agent, cross-database queries, CLR

→ Azure SQL Managed Instance

Practice Relational & Non-Relational Questions

500 DP-900 practice questions including Domains 2 and 3 in full. Start with 40 questions free.

Start Free DP-900 Practice →

Related Resources