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 support@ewanalytics.com if you wish to get in touch with us.
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.
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.
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?
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.
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?
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.
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.
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 th-cam.com/video/3LP5cHPNw4w/w-d-xo.html&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 th-cam.com/video/ErV6HZykDzE/w-d-xo.html&ab_channel=BIwithMina
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.
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 th-cam.com/video/3LP5cHPNw4w/w-d-xo.html&ab_channel=BIwithMina, @12:00 min
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?
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.
Please SUBSCRIBE, SHARE, COMMENT, AND LIKE MY VIDEOS th-cam.com/play/PL2R9mo00yw_0_PudT11yjhZFcrTbues2P.html th-cam.com/play/PL2R9mo00yw_0I5ekj_HHolqpXSh1w80qt.html
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 support@ewanalytics.com if you wish to get in touch with us.
Your videos are helpful
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.
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.
This tutorial has really helped me clear the clouds of data warehouse designing. Thank you.
Great video and break down of how to process the data when starting a model 🙏🏾
Repeating Glenda's comment - Clear and concise - well done!
Good Explanation of Dimension modeling
Great video! I had trouble understanding the concept of dimensional modelling and this cleared all my doubts. Thanks
Glad it helped!
Awesome stuff
Simple to understand. Great
Fantastic 👍🏻
Great teaching
Glad you think so!
I love how you explain stuff, well done!
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?
Thank you
Clear and concise - well done!
Wow,this is excellent!
Excellent explanation. Thank you.
Thanks for this explanation !
Thank you! Clearly explained, really good video!!
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.
Awesome Teaching skill !!! you are rock :)
Please make more videos with more case studies.
studio.th-cam.com/users/videohsFfWTGHOKU/edit
thanks lot😀😀
how could we define the measure of the fact table, why the measure is DrillAmount, but it is not the drilled Hole amount
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?
Yes, in responds to the business requirements, the gain was rolled up to Daily drills instead of point in time
Could you please explain the differences between different data models(Inmon,Kimball,3NF,Dimension Modelling,Data Vault).
th-cam.com/video/3LP5cHPNw4w/w-d-xo.html
can you explain what is a grain? I don't really understand what lowest level of information means
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.
you can provide few more case studies so that we can practice more
studio.th-cam.com/users/videohsFfWTGHOKU/edit
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.
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 th-cam.com/video/3LP5cHPNw4w/w-d-xo.html&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 th-cam.com/video/ErV6HZykDzE/w-d-xo.html&ab_channel=BIwithMina
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.
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 th-cam.com/video/3LP5cHPNw4w/w-d-xo.html&ab_channel=BIwithMina, @12:00 min
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?
you can call it DateID
Very good teaching but kind of hard to understand.
Where is an amount field? Is it coming from transaction table?
The amount is a metric required by the business in the case study. So we had to put it in the fact table
Great Video, but no Part II :(
th-cam.com/video/3LP5cHPNw4w/w-d-xo.html
What is a degenerate dimension ? minute 3.57 in the video. Thank you.
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.
@@biwithmina7066 Super clear. Thanks a lot.
Please SUBSCRIBE, SHARE, COMMENT, AND LIKE MY VIDEOS
th-cam.com/play/PL2R9mo00yw_0_PudT11yjhZFcrTbues2P.html
th-cam.com/play/PL2R9mo00yw_0I5ekj_HHolqpXSh1w80qt.html
Here's part 2 just not labeled as such: th-cam.com/video/3LP5cHPNw4w/w-d-xo.html