Book Image

Data Modeling for Azure Data Services

By : Peter ter Braake
Book Image

Data Modeling for Azure Data Services

By: Peter ter Braake

Overview of this book

Data is at the heart of all applications and forms the foundation of modern data-driven businesses. With the multitude of data-related use cases and the availability of different data services, choosing the right service and implementing the right design becomes paramount to successful implementation. Data Modeling for Azure Data Services starts with an introduction to databases, entity analysis, and normalizing data. The book then shows you how to design a NoSQL database for optimal performance and scalability and covers how to provision and implement Azure SQL DB, Azure Cosmos DB, and Azure Synapse SQL Pool. As you progress through the chapters, you'll learn about data analytics, Azure Data Lake, and Azure SQL Data Warehouse and explore dimensional modeling, data vault modeling, along with designing and implementing a Data Lake using Azure Storage. You'll also learn how to implement ETL with Azure Data Factory. By the end of this book, you'll have a solid understanding of which Azure data services are the best fit for your model and how to implement the best design for your solution.
Table of Contents (16 chapters)
1
Section 1 – Operational/OLTP Databases
8
Section 2 – Analytics with a Data Lake and Data Warehouse
13
Section 3 – ETL with Azure Data Factory

Designing dimensions

The first thing to look at is the primary key to use for a dimension table.

Defining the primary key of a dimension table

To get straight to the point: we always use surrogate keys for dimension tables. In Chapter 1, Introduction to Databases, we discussed logical versus surrogate keys. We will not repeat the discussion here. The best practice is to use surrogate keys for dimension tables.

In a star schema database model, using an efficient primary key is even more important than in a normalized OLTP database. In earlier examples, it became clear that fact tables might become really big in terms of the number of rows they store. Suppose you have a fact table with seven dimensions that has 1 billion rows. The difference between using keys that are 4 bytes in size and keys that are 8 bytes in size is 7 x 4 x 1,000,000,000, which is 28 GB. Some people might argue that today 28 GB is not really something to consider. But you might have a lot more rows than...