Glad to hear that. Messay, I am not sure if you know, but we offer many On-Demand Learning courses, such as, Power BI, Azure, SQL Server, Data Science, Business Intelligence and much more. You should check out our FREE trial: www.pragmaticworkstraining.com/trial-registration/?source=odl_youtubeorg
@@PragmaticWorks 32:33 suggests using int datatype for surrogate key -> ProductSK. Since this is a DW wouldn't it be better to use bigint or double? Not rhetorical I really want to know. Thanks.
Thank you for the video!! Can you give an advice, where i can read/watch about designing an olap-cube in SSAS, having a multiple fact tables in my DWH??
what is/are the best practice in building a data warehouse from an existing relational database. meaning; I have an operational database in a retail model and I would like to be able to build a data warehouse form this existing DB.
Hey Edward, with data modeling it always depends on what your ultimate goal is. Adding the returns information to the sales information would create a "Consolidated" Fact table. Generally, I try to avoid this method. I would prefer to keep the returns table as a separate fact table. The sales and returns information would share a lot of the same conformed dimensions and therefore you could easily drill across and see the sales and returns by item. Hope this helps! -Mitchell Pearson
@@PragmaticWorks Makes sense! I like that approach. What about the item cancelation example? Perhaps wait untill an item is shipped before including it in the sales table?
@Janak Dharmik People pay us to build stuff ... Why would a car mechanical engineer talk for hours - about how to replace engine parts - without actually popping the hood is a real mystery ...
We live in a world where I can sit at home and get high quality education for my career for free. Amazing. Thank you for this lecture.
Now go get a job 😂
Thanks Tow Hee, so glad you enjoyed it!
I just read. Sit home and get higj😂😂😂
Excellent tutorial. Thanks for posting. Explains the whole process in a 1 hr video.
Glad to hear that. Messay, I am not sure if you know, but we offer many On-Demand Learning courses, such as, Power BI, Azure, SQL Server, Data Science, Business Intelligence and much more. You should check out our FREE trial: www.pragmaticworkstraining.com/trial-registration/?source=odl_youtubeorg
@@PragmaticWorks 32:33 suggests using int datatype for surrogate key -> ProductSK. Since this is a DW wouldn't it be better to use bigint or double? Not rhetorical I really want to know. Thanks.
@@xst9880 Only if you need a bigint. But performance-wise a normal int is always better.
Thanks for this wonderful session it is very crisp and clearly explained the fact and dimensions
Glad you enjoyed it (:
Thank you for the video!!
Can you give an advice, where i can read/watch about designing an olap-cube in SSAS, having a multiple fact tables in my DWH??
what is/are the best practice in building a data warehouse from an existing relational database. meaning; I have an operational database in a retail model and I would like to be able to build a data warehouse form this existing DB.
looking forward to watching till the end. Personal Time Stamp 14:22 44:30
Would you say contribution in a municipality is a process or is eath specific contribution a process? Or is payment a better schema (marts)
Thanks for this! A suggestion would be to try keep it a bit more simple and summarised! :)
Awesome job, thanks for sharing
Hey Rodrigo, Dustin and I had a lot of fun doing this webinar, glad you enjoyed it!
Awesome as usual.
Great video guys, very helpful
Very helpful. Thank you!
Glad it was helpful!
If the data is dirty, there can be process corrections and it can be made clean....
10:17 Busterblock 😂. You probably have heard about this 😂😂!!
Like that 'somebody went home that day' lol
Very informative!
Glad you think so!
Nice job!
Big help -
Thanks :)
Absolutely! Thanks for watching!
How do you deal with sale cancelations and returns? Do we add it to the fact table with negative values?
Hey Edward, with data modeling it always depends on what your ultimate goal is. Adding the returns information to the sales information would create a "Consolidated" Fact table. Generally, I try to avoid this method. I would prefer to keep the returns table as a separate fact table. The sales and returns information would share a lot of the same conformed dimensions and therefore you could easily drill across and see the sales and returns by item. Hope this helps! -Mitchell Pearson
@@PragmaticWorks Makes sense! I like that approach. What about the item cancelation example? Perhaps wait untill an item is shipped before including it in the sales table?
the ads are insane. can't get throught ONE concept before the next ad. every 2 minutes, what kind of learning experience do you hope this would be?
Dustin really loves cheeseballs.
So easy a janitor could do it.
I just love it when a supposed to be technical-step-by-step tutorial to actually BUILD something turns out to be a HowYouDoin chatter ...
@Janak Dharmik
People pay us to build stuff ... Why would a car mechanical engineer talk for hours - about how to replace engine parts - without actually popping the hood is a real mystery ...
p
Huh ? There is no actual step by step, is that what u are saying ?
@@kishataylor6963
Yeah .. can believe this ...
please some practice , its a only theory like always
zzz...
Annoying theory as always
You're more annoying