DIMENSIONAL DATA MODELING TUTORIALS - STAR SCHEMA | Based on a case study | Part 1

[@biwithmina7066]

Dear Subscribers, Thank you for your interest in our videos. We value all of your feedback and will do our best to reply in the comments. Nevertheless, we may not be able to answer all practical questions, via comments. To help with practical sessions, our dedicated team can be reached through email. Send an email to [e-mail] if you wish to get in touch with us.

[@gkool4655]

Your videos are helpful

[@biwithmina7066]

Please SUBSCRIBE, SHARE, COMMENT, AND LIKE MY VIDEOS kzbin.info/aero/PL2R9mo00yw_0_PudT11yjhZFcrTbues2P kzbin.info/aero/PL2R9mo00yw_0I5ekj_HHolqpXSh1w80qt

[@agushadianto8354]

Hi Mina, I really enjoy your clear explanations in the video. It's so helpful to make understand more about how to build the dimensional model. Thanks a lot.

[@richardnartey6683]

This tutorial has really helped me clear the clouds of data warehouse designing. Thank you.

[@blaiseashun111]

i have a project work in uk as a student and this video has opened my eyes to the solution... i was struggling but now i understand dimension tables, its entity and fact tables. ah tanks o. i appreciate.

[@nadinecollard3528]

Great video and break down of how to process the data when starting a model 🙏🏾

[@El_Duderino01]

Repeating Glenda's comment - Clear and concise - well done!

[@tapashmazumder3212]

Good Video. A question - Do we create a conceptual model in the form of star schema before converting into logical dimensional model? Don't we create a relational kind of a conceptual model and then convert it into dimensional model in the logical layer?

[@WasimKhan-xm1vt]

Good Explanation of Dimension modeling

[@amna_c_]

Great video! I had trouble understanding the concept of dimensional modelling and this cleared all my doubts. Thanks

[@biwithmina7066]

Glad it helped!

[@victorruto1152]

Thank you

[@carloscampanholi4530]

Thank you! Clearly explained, really good video!!

[@shuwylicious]

I love how you explain stuff, well done!

[@johnsonakanbi367]

Wow,this is excellent!

[@maintalbischofsheim]

Thanks for this explanation !

[@ayimebenezer104]

Simple to understand. Great

[@Crazy5exycurvy]

Clear and concise - well done!

[@mohammedansari818]

Excellent explanation. Thank you.

[@CrazyFunCricket]

Awesome Teaching skill !!! you are rock :) Please make more videos with more case studies.

[@biwithmina7066]

studio.kzbin.infohsFfWTGHOKU/edit

[@Sharmasurajlive]

Fantastic 👍🏻

[@edwinaquansah7295]

Great teaching

[@biwithmina7066]

Glad you think so!

[@StudywithDani]

Awesome stuff

[@dulanjalivithanage2291]

thanks lot😀😀

[@00EagleEye00]

Good day. I would like to ask on how to include a dimension on a hierarchical design (recursion) to a fact? Kindly set an example and provide explanation if possible. Thank you.

[@MrMLBson09]

I've heard it's best practice to design the fact table at the lowest grain possible. What if they want to see how many holes were drilled by an employee in the morning vs the evening in the future? Doesn't this model limit yourself to potentially answering those questions?

[@biwithmina7066]

Yes, in responds to the business requirements, the gain was rolled up to Daily drills instead of point in time

[@minhnguyenhainhat234]

how could we define the measure of the fact table, why the measure is DrillAmount, but it is not the drilled Hole amount

[@user-dx2dg4bd7q]

Could you please explain the differences between different data models(Inmon,Kimball,3NF,Dimension Modelling,Data Vault).

[@biwithmina7066]

kzbin.info/www/bejne/aX2zZpZ-hbOqatk

[@irdunno2204]

can you explain what is a grain? I don't really understand what lowest level of information means

[@CrazyFunCricket]

you can provide few more case studies so that we can practice more

[@biwithmina7066]

studio.kzbin.infohsFfWTGHOKU/edit

[@akshaybaura]

I think the issue I see here is that Drilling company has no relation to employee apart from the fact, so only if there's a record in the fact for an employee of a company, we'll ever get to know that the employee exists.

[@suleimanbashirshamsudeen3785]

Good illustration Mina. Why is the DateKey(Date_Dim) not linked to the facttable like the other dimension tables? and why in some star schemas surrogate keys are used in the fact tables instead of a primary key(drillingID) like you have here.

[@biwithmina7066]

1)Showing Datekey in the Fact table is also accepted depending on your requirements. Here I assumed and linked Drillstart and DrillEnd to Date key (role-playing dimensions). You may want to watch Part 2of the model creation process to see how I replicated the physical model in SSMS kzbin.info/www/bejne/aX2zZpZ-hbOqatk&ab_channel=BIwithMina, @12:00 min 2) Use a surrogate key if the primary key records will change. Also, use a surrogate key to track changes to records such as in slowly changing dimensions kzbin.info/www/bejne/e6O5Z3uQrtB3sKc&ab_channel=BIwithMina

[@dorisandjohn8582]

About the date Dimension, when it comes to fill it in the fact table, at minute 14:18 you add a "DateStamp" that after in the logical schema does not apears but instead there are: "DrillStartDate (FK)" & "DrillEndDate (FK)". Could you please explain why that change ? Thank you.

[@biwithmina7066]

You are right, you can as well specify just "DateStamp" but I decided to go extra further. You may want to watch Part 2of the model creation process to see how I replicated this model in SSMS and health with the 2 dates in the Fact Table kzbin.info/www/bejne/aX2zZpZ-hbOqatk&ab_channel=BIwithMina, @12:00 min

[@reg-210bandichaitanya8]

Very good teaching but kind of hard to understand.

[@dorisandjohn8582]

I have watched several similar video and I dont understand why the date dimension never has a DateID but always has a DateKey. Could you explain please?

[@biwithmina7066]

you can call it DateID

[@dorisandjohn8582]

What is a degenerate dimension ? minute 3.57 in the video. Thank you.

[@biwithmina7066]

This is an excellent question; to illustrate, consider the following scenario: you need to generate a Star Schema from a Table that contains columns for Amount, Employee, and Invoice Number information. The amount is a metric, so it goes to the Fact Table. Employee, and Invoice Number information are Dimensions. When we create Dim Employee Table, it will undoubtedly contain several columns (attributes) such as Employee ID, Name, Age, Address, and so on. Dim Invoice Number, on the other hand, does not have any attributes other than a primary key. Because Dim Invoice Number does not have any attributes, there is, therefore, no need to create a Dimension Table for it. In such a case, it is advisable to keep the Invoice Number in the Fact Table; this dimension is referred to as a Degenerate Dimension.

[@dorisandjohn8582]

@@biwithmina7066 Super clear. Thanks a lot.

[@aakashpatel2792]

Where is an amount field? Is it coming from transaction table?

[@biwithmina7066]

The amount is a metric required by the business in the case study. So we had to put it in the fact table

[@joepitz1]

Great Video, but no Part II :(

[@biwithmina7066]

kzbin.info/www/bejne/aX2zZpZ-hbOqatk

[@joepitz1]

Here's part 2 just not labeled as such: kzbin.info/www/bejne/aX2zZpZ-hbOqatk