Dimensional Data Model Tutorial - A Kimball Style Data Model
HTML-код
- Опубликовано: 23 июл 2024
- Let's take a hand's on look at data modeling, specifically for data warehousing. Today we're modeling a dimensional data warehouse, based on Kimball methodology. We'll look at picking fact tables and dimension tables, how to create a star schema, and what to consider in the design.
⏯RELATED VIDEOS⏯
Data Vault Model Tutorial: • Data Vault Model Tutor...
Database Normalization Tutorial: • Database Normalization...
------------------------------------------------------------------------------
Data Podcast ►► open.spotify.com/show/4PWmW2g...
Website ►► www.nullqueries.com/
------------------------------------------------------------------------------
🎓Data courses (Not Produced by nullQueries)🎓
Azure Data Engineering: click.linksynergy.com/deeplin...
DE Essentials, hands on: click.linksynergy.com/deeplin...
------------------------------------------------------------------------------
📷VIDEO GEAR📷
Programming Mouse: amzn.to/3zEom7f
Lighting: amzn.to/3o8tXAM
RGB light: amzn.to/3o8AQBS
USB Microphone: amzn.to/3m3hjAt
Mixer: amzn.to/2ZyqMIk
XLR Microphone: amzn.to/3AHPZ0L
💻VIDEO SOFTWARE💻
music/stock: 1.envato.market/rnX70y
------------------------------------------------------------------------------
For business inquiries please contact nullQueries@gmail.com
Some of the links in this description are affiliate links and support the channel. Thanks for the support!
------------------------------------------------------------------------------
00:00 Intro
00:39 Business Process
01:19 Facts and Dims
02:33 Star vs Snowflake
03:23 Surrogate Keys
04:20 Dim Types
04:53 Grain
06:05 ER diagram 
Наука
How does your dimensional modeling process work? Is it different than mine? Next video we'll be modeling a Data Vault.
Check it out here: ruclips.net/video/XROtSVXbTvs/видео.html
Succinct and direct videos like these are not only lifesavers for the countless report analysts who walked into work one day and were christened BI developers without their consultation, but they are also excellent recaps for people who zoned out when the boss threw down five figures for substandard training.
Thanks! We've all been there, I'm pretty sure that's how BI devs are made.
High quality content! Have to catch up on some terminology but I learned a bunch
Excellent, this is what we call live guide. Congrats 👏
Nice explanation. Thanks a lot.
I have watched all your video 🕵️ great 🧑🔬
Finally, a data modeling tutorial I can actually understand....bookmark...
Glad you found it useful!
I agree. I’ve read so many things trying to figure out the difference between dim/fact tables. This is by far the clearest.
great explanation of data modelling . As a data engineering entusiast , can you make an hands on sql query video with use case . show basic to advanced commands inorder to manipulate data .😇
Could you please explain the differences between different data models(Inmon,Kimball,3NF,Dimension Modelling,Data Vault).
I like your videos, great explanation with clear and nice examples. I just need more time and effort to focus because of the loud music in the background. I hope to make it low in rest of your videos. thanks again for your explanation and your time.
What would be the Surrogate key of a book?
a composed id made of book name + author?
it is not clear to me why do we need both SK and BK
A SK is system generated (something like an increasing integer) and not related to the data. The reasons for SKs is, while a BK _shouldn't_ be changed, sometimes businesses do dumb things, and we don't have control over it. And also, a warehouse is meant to bring multiple sources together into shared tables, and two sources could have overlapping values for BKs. So the SK can help us identify them properly.
@@nullQueries Thanks a lot, I had a similar question. BTW brilliant videos .. Stumbled upon your channel today and look at all videos one by one. Great content!
A fact table might have *billions* of rows, and each row might contain *hundreds* (or *tens* anyway) of foreign keys into different descriptive dimensions. It's important that the keys are short so that they don't take up too much room. Plus the SK for a dimension is stable, it's possible for a BK to change e.g. to correct a typo in it, and it's also static - so that the new version, with different elements (e.g. a book is reprinted with a different ISBN) of a dimension record and might have the same BK (plus a version/timestamps) but a different SK. The fact will relate to the dimensional record as it was when the fact happened (unless it's decided to always get the latest - or different - version of the record).
@@nullQueries What happens to these SK if we decide to separate the sources that were previously brought together? Is the SK column thrown away, then a new set of SK created after a re-merging of different source tables? That sounds wrong because if SK is thrown for a few tables, all other SK refering to these deleted SK's can't be used to refer to rows in old design anymore
Looking for a video to help some curious clients understand concepts, but this one made two serious no-nos in five minutes: 1) saying you must "put publisher in its own dimension so you can slice on it." Publisher has a hierarchical relationship to book, it's perfectly normal to store hierarchies in dimensions, and nothing is stopping you from "slicing" (filtering or grouping) on publisher if it's an attribute of book, 2) saying "it may be worth making a fact table at both grains" to make for easier library checkout "borrowed" event reporting. You should NOT build two independent fact tables here, because they will never load at the same time, and could violate a concept known as "Single Source of Truth" (SSOT) -- getting inconsistent results from queries on your "borrowing event" star vs your "book checkout" star. Instead just build the lowest granularity fact (at book level), and if really needed for performance, create your second "fact" as an aggregate of the first fact instead, using group by. This is all explained repeatedly in the Design Tips on the Kimball Group web site.
Ahhh yes, dimensional drilling. My favorite