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.
@gkool4655 Жыл бұрын
Your videos are helpful
@biwithmina70663 жыл бұрын
Please SUBSCRIBE, SHARE, COMMENT, AND LIKE MY VIDEOS kzbin.info/aero/PL2R9mo00yw_0_PudT11yjhZFcrTbues2P kzbin.info/aero/PL2R9mo00yw_0I5ekj_HHolqpXSh1w80qt
@agushadianto83548 ай бұрын
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.
@richardnartey66833 жыл бұрын
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_Duderino013 жыл бұрын
Repeating Glenda's comment - Clear and concise - well done!
@tapashmazumder32122 күн бұрын
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-xm1vt3 жыл бұрын
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
@carloscampanholi45302 жыл бұрын
Thank you! Clearly explained, really good video!!
@shuwylicious3 жыл бұрын
I love how you explain stuff, well done!
@johnsonakanbi3672 жыл бұрын
Wow,this is excellent!
@maintalbischofsheim3 жыл бұрын
Thanks for this explanation !
@ayimebenezer1044 жыл бұрын
Simple to understand. Great
@Crazy5exycurvy3 жыл бұрын
Clear and concise - well done!
@mohammedansari8183 жыл бұрын
Excellent explanation. Thank you.
@CrazyFunCricket3 жыл бұрын
Awesome Teaching skill !!! you are rock :) Please make more videos with more case studies.
@biwithmina70663 жыл бұрын
studio.kzbin.infohsFfWTGHOKU/edit
@Sharmasurajlive2 жыл бұрын
Fantastic 👍🏻
@edwinaquansah72954 жыл бұрын
Great teaching
@biwithmina70663 жыл бұрын
Glad you think so!
@StudywithDani3 жыл бұрын
Awesome stuff
@dulanjalivithanage2291 Жыл бұрын
thanks lot😀😀
@00EagleEye003 жыл бұрын
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.
@MrMLBson092 жыл бұрын
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?
@biwithmina70662 жыл бұрын
Yes, in responds to the business requirements, the gain was rolled up to Daily drills instead of point in time
@minhnguyenhainhat23410 ай бұрын
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).
@biwithmina70665 ай бұрын
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
@CrazyFunCricket3 жыл бұрын
you can provide few more case studies so that we can practice more
@biwithmina70663 жыл бұрын
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.
@suleimanbashirshamsudeen37852 жыл бұрын
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.
@biwithmina70662 жыл бұрын
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
@dorisandjohn85822 жыл бұрын
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.
@biwithmina70662 жыл бұрын
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-210bandichaitanya82 жыл бұрын
Very good teaching but kind of hard to understand.
@dorisandjohn85822 жыл бұрын
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?
@biwithmina70662 жыл бұрын
you can call it DateID
@dorisandjohn85822 жыл бұрын
What is a degenerate dimension ? minute 3.57 in the video. Thank you.
@biwithmina70662 жыл бұрын
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.
@dorisandjohn85822 жыл бұрын
@@biwithmina7066 Super clear. Thanks a lot.
@aakashpatel27923 жыл бұрын
Where is an amount field? Is it coming from transaction table?
@biwithmina70663 жыл бұрын
The amount is a metric required by the business in the case study. So we had to put it in the fact table
@joepitz12 жыл бұрын
Great Video, but no Part II :(
@biwithmina70662 жыл бұрын
kzbin.info/www/bejne/aX2zZpZ-hbOqatk
@joepitz12 жыл бұрын
Here's part 2 just not labeled as such: kzbin.info/www/bejne/aX2zZpZ-hbOqatk