Sign In Start Free Trial
Account

Add to playlist

Create a Playlist

Modal Close icon
You need to login to use this feature.
  • Data Modeling for Azure Data Services
  • Toc
  • feedback
Data Modeling for Azure Data Services

Data Modeling for Azure Data Services

By : Braake
4.8 (16)
close
Data Modeling for Azure Data Services

Data Modeling for Azure Data Services

4.8 (16)
By: 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)
close
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...

Unlock full access

Continue reading for free

A Packt free trial gives you instant online access to our library of over 7000 practical eBooks and videos, constantly updated with the latest in tech
bookmark search playlist download font-size

Change the font size

margin-width

Change margin width

day-mode

Change background colour

Close icon Search
Country selected

Close icon Your notes and bookmarks

Delete Bookmark

Modal Close icon
Are you sure you want to delete it?
Cancel
Yes, Delete