Thank you so much! This is very helpful and it never dawned on me that we can normalize data using Power Query.
@SMCGPRAАй бұрын
Holy grail channel for learning data analysis
@abidurrahmanabir7745Ай бұрын
Salaam Brother..... This is masterclass video for any1 to understand the Basic of full Dataset Analyzing... ❤️❤️😱😊.......
@officesuperhero4651Ай бұрын
This is a great tutorial. Thanks. I use a lot of Power BI. I guess my biggest caveat would be these relationships are one to many so slicers in Power BI won't work unless you use a measure with a slicer as a work around.
@abdielgutierrez88125 күн бұрын
Thank you very much. I am a beginner in the use of Power BI and I appreciate this super video that helps me to improve my data management. If you can post a video of how I can keep this file updated after performing the normalization.
@kossiviaglee299724 күн бұрын
I really enjoyed your video. I needed to know this. I give to myself some database projects in Ms-Access but I don't always know the number of normalisation levels to go. Sometimes I run into a total confusion at the end specially when it's time to build my queries. That's why I appreciate the end of your video. So please do you have a video on how be successful building queries no matter what level of normalization you got? Thanks again for this video.
@ericgusmao51648 күн бұрын
Great video, but I'd like to point out that we might also need a price column on Order Line Items table because the price of the product may vary over time.
@peterrender4716Ай бұрын
Thanks Chris. Very helpful. This is by far the best explanation of 'normalisation' that I have seen. One question. I understood that many to many connections were not to be used in Power BI but note that the Order Line Item Table has a many to one connection to the Orders Table and a many to one connection 'chain' with the Products, subcategories and Categories Table. Can you explain how filters work through this structure please. I understood that the dimension tables are used for filtering the fact tables in the star schema but I am struggling to understand how the snowflake structure works, particularly with the addition of the one to many connection between the Orders and Orde Line Items Table. Thanks Peter
@DarcyWhyteАй бұрын
In power BI you would not have a coneection between Orders and Line Items. Just between those fact tables and dimensions. Further, you'd probably have not completed as much normalization to create a snowflake, just keep it as a star...
@JunaidKhan-wg7cj26 күн бұрын
I have watched first time and it was realy helpful. Thanks and keep teaching :)
@NitinKunigalАй бұрын
Hey Chris, I really liked the way you explained the concept of Normalization! However, I need some clarification. According to my understanding, I think it's always better to rather reference a query than duplicate a query for creating dim tables. Here's the logic: reference query establishes parent-child dependency with the master query (transaction table). Whenever there's an update made to the transaction table i.e., a new customer being added or something else, the child query (used for dim tables) also gets updated accordingly. On the other hand, duplicate query is independent and doesn't have any relationship with the master query (transaction table). Please share your insights! Cheers!
@txreal2Ай бұрын
Makes sense. Thanks 👍
@Chris-at-MavenАй бұрын
Great point! Referencing the existing query (vs. duplicating) would be the better approach if the source data will be changing over time. Thanks for the comment!
@Benry1984Ай бұрын
I think it's fine in this instance since they all reference the exact same source - i.e. if the transaction workbook is updated / superseded then all queries would also reflect the changes. If there were changes to the transaction data which was saved in a new separate workbook (or filename changes) then the reference is definitely the option to go with - i.e. all of the other queries would point to the old table, or one that doesn't exist.
@NitinKunigalАй бұрын
@@Benry1984 No, the queries won't get updated at any cost because there's no reference with the master query (relationship doesn't exist). Unless you're absolutely sure that the source data won't get updated, it's always a good practice to reference a query rather than using the duplicate option. Regardless, it's always better to use the reference query option to create lookup tables.
@McKaySavageАй бұрын
Additionally, duplicating queries duplicates all the query calculation steps up to that point. So in parallel language, you should be removing the redundancies and normalizing your queries with exactly the same thought as your datasets :)
@Benry1984Ай бұрын
Great video. Really summarises the various concepts well. Interested in your thoughts on using this single source method to normalise the data versus just using the master data tables (e.g. get the customer, product, category etc table data separate and bring it in). I like to see what is not in the transactional data to spot things not being used (e.g. what cost centers are not being used at all) and means outputs will have a more consistent look. I figure it will mostly come down to the practical problem of actually being able to get access to updated master tables rather than any profound arguments.
@ExcelWithChrisАй бұрын
Great video explaining the concepts, but I do agree that there is no need starting off with everything in one file and then using PowerQuery to split. It still means that that when you add data you are still going to do it in the original file (which will get very large). Just makes sense to have all those dimensions from the start in different files, import into PowerQuery and then create relationships. If the original file with everything inside is going to be your source, then you are not gaining anything by splitting it into different tables.
@LJ-jd5yy26 күн бұрын
This is the best video I’ve seen on normalization using Power query!
@pierre-yves_davidАй бұрын
Thanks, Chris, good to remind the different steps to normalise a database. Your video raises several questions (you have already answered to replacing duplicates by references). Is there a good reason to use CPU to sort the dimension tables (i.e., a form of investment to accelerate future table joins)? How can we identify functional (partial) dependencies between columns when you have no idea of the data contained in a base.
@dp70737Ай бұрын
😲 wait you can profile the entire data set. 😅😁 game changer
@rajeshmajumdar4999Ай бұрын
Hi Chris, thank you very much. ⭐⭐⭐⭐⭐⭐ Loved the way you explained it. God bless you.
@eniolaadekoya5623Ай бұрын
Great lesson i will like to this on microsoft fabric over the weekend
@mehranbarahouei2346Ай бұрын
Great tutorial ❤❤❤❤❤❤
@muhammadomer1654Ай бұрын
Thanks, Chris, for another great informative tutorial. But can you please tell us how you identified that in the process of the 2nd NF, fields like order date, delivery date, CustomerID, and StoreID depend on OrderNumber, while fields like Quantity and ProductID depend on both OrderNumber and LineItem?
@MrAhmedHaider19 күн бұрын
Absolutely brilliant 👍
@omondif9Ай бұрын
Thanks Chris, i love the way you always breakdown the concepts into simple bitable bits.
@Chris-at-MavenАй бұрын
Thanks for the feedback!
@ThịnhNguyễnPhúc-x7c6 күн бұрын
Your video so great and helpful but I have a question i hope you can answer: Could you tell me the largest different between 1 table and star schema in building the dashboard when i have a big dataset?
@sambameissaАй бұрын
Thank you, really love how clear you guys explain concepts. keep up the good work.
@Chris-at-MavenАй бұрын
Glad you enjoyed this one!
@benosborne413Ай бұрын
Great lesson. What if I want to update the info on a daily, weekly or monthly basis?
@Chris-at-MavenАй бұрын
In this case we're working with a local CSV file for simplicity, but it reality you'd likely have a database connection that would pull in new information when the query is refreshed. If you don't have a DB, you could also connect to shared locations like SharePoint or OneDrive, or point to a local folder where you can add new files and automatically append them via Power Query.
@benosborne413Ай бұрын
@@Chris-at-Maven Do you a full video on Power Query?
@artiguf10 күн бұрын
Amazing video. And yes well explained.. thanks.
@CodeWithMuhammadAhsan12 күн бұрын
beautifully explained
@andreag612619 күн бұрын
Thanks for sharing!
@udayteja6595Ай бұрын
Thankyou very much...
@Loves-f3yАй бұрын
Nice. Subscribed. What type of data model is best for a model driven Power App?
@KumarSrinivasAvvaruАй бұрын
Great work, thanks for sharing
@Chris-at-MavenАй бұрын
Glad you enjoyed this one!
@balrajvirdee1087Ай бұрын
Thank you great explanation 👍🏽
@Chris-at-MavenАй бұрын
Thank you, glad you found it helpful!
@95andresilloАй бұрын
Hi Chris I love your videos. I was looking at making the business intelligence roadmap that you have on your page, is it possible to make that same roadmap but with your udemy courses? If so, what would they be?
@SothearithKONGMrMuyKhmerАй бұрын
Thank you so much! That’s really helpful! 🥰
@Chris-at-MavenАй бұрын
Glad to hear it!
@SothearithKONGMrMuyKhmerАй бұрын
@@Chris-at-Maven Thank you! 🙏
@jefffisher1377Ай бұрын
Great Video - Learnt a bunch of things. One question for clarity if I may - When I remove duplicates of Store ID being my main key , I have a database file with weekly data that 'grows' every week, and history data snowballs. I need to keep history , so removing duplicates of Store ID , will this remove history ?
@Chris-at-MavenАй бұрын
Tough to say without the full context, but generally speaking you'll want to make sure that your dimension tables contain EVERY possible primary key that might appear in your data tables.
@jefffisher1377Ай бұрын
@@Chris-at-Maven Thanks Chris - More Context : I receive weekly data collected, by our field staff per outlet (Each outlet has a unique numeric code) by date in that week. This data is extracted from the back-end every Monday and added (more rows at the bottom of the table). I now have original raw data daily data which has a Month , QTD and YTD component added via Excel formula. If I keep the main file (as you have in this video) and duplicate it 3 times , in one of the copies , I could get rid of duplicates and when I want to get Monthly , QTD and YTD , I could reference back to the original master file ?
@eniolaadekoya5623Ай бұрын
First I have been able to go through the tutorial my question is instead of having an order line items and orders table can i just have a single transactional table? for star schema to be achieved. Second is if i have a date target table how can i link this to the model so that i can compare metrics by target value. Thank you Chris
@Chris-at-MavenАй бұрын
Yeah that's part of the point we're making at the end of the video., While techincally you CAN continue to normalize your models, sticking with a simpler star schema will often be the best bet in terms of balancing storage and query optimization. You can approach a date table in a similar way - by referencing the transaction table, depuplicating the transaction date field to get the full range of dates (assuming it's contiguous, no gaps), then adding date columns like day name, start of week, year, etc. That becomes your Calendar dimension table, which you can add to your star schema just like the others. Hope that helps!
@eniolaadekoya5623Ай бұрын
@@Chris-at-Maven Thank you Got That
@awesh1986Ай бұрын
Loved the video. Too good.
@Chris-at-MavenАй бұрын
Glad you enjoyed this one!
@orlandofury26 күн бұрын
I'll do choose columns instead of removing
@丁恩妃-h9dАй бұрын
thanks for the tutorial will there are chances that excel refuse to work data mode module since the amount of data is too large, like several thousands of rows and many columns?
@contactpaulo22 күн бұрын
Great!!! Thanks.
@JJ_TheGreatАй бұрын
Question: When you remove the duplicate IDs, how do you know that you are removing the proper rows (in general)? Thanks.
@mjbine21 күн бұрын
When refreshing the data, will the dimension keep the uniqueness or do you have to remove dups with each refresh?
@md.shamsuzzaman4156Ай бұрын
Great. Thanks
@Loves-f3yАй бұрын
Question - @8:00 when you chose Home > Close & Load To… then used 'Only create Connection' saying you don't want to dump all the rows and data points into a worksheet and that you want to create a datamodel instead Choosing [x] Add this data to the Data Model. I guess I’m confused because right then the Queries & Connections shows all the records being loaded. Have you gone over that in more depth in another video?
@seanys27 күн бұрын
I understand that this is a beginner’s tutorial but @4:40, as soon as you remove duplicates, you’re potentially throwing away current data. Transactions take place over time and customer’s names and addresses change over time. The least you should do is sort the initial table by time to ensure only the oldest duplicate Client IDs are removed. A better approach would involve retaining historical customer data.
@MrSlurrpyАй бұрын
For Power BI it is suggested by Microsoft own documentation to use the Star Schema which means data should be and stop at the 2NF level? Is this a correct understanding?
@bhavishyaaggarwal352317 күн бұрын
Hey I downloaded the excel file from the link in description and then without any normalization I created a pivot table using the info originally given in the excel sheet !! And it gave the same results as u were getting , the what was the need for all that normalization ?
@KeoniPKimАй бұрын
So when you get a new "Transactions File" would you just refresh the data?
@potatocraftd6629Ай бұрын
Yes
@Chris-at-MavenАй бұрын
It depends. In this case we're working with a local CSV file for simplicity, but it reality you'd likely have a database connection that would pull in new information when the query is refreshed. If you don't have a DB, you could also connect to shared locations like SharePoint or OneDrive, or point to a local folder where you can add new files and automatically append them via Power Query. If the file name and path didn't change, then yes you could update the source file and refresh the query to see the new data.
@mahmoudmohsen8105Ай бұрын
Lovely!
@ExcelWithChris19 сағат бұрын
Maybe a stupid question. All of these are based on the original data source with all the columns in it. What is the use of splitting it if you are still going to add new data to the original source to update all these queries. Are we assuming the source data is a once off? Or am I missing something here.
@orthodox_gentleman21 күн бұрын
Dang brother you look GOOD! Male perfection…
@DataThomasАй бұрын
What if my initial table does not have all the IDs (transaction, order, date, etc.) already in it?
@christabelabraham8402Ай бұрын
Hey Chris , my power pivot is not on my excell what can I do
@202lbsАй бұрын
being wiped out due to overstaying in mid, not pushing lanes
@NirRobinsonАй бұрын
Why do you prefer duplicate vs reference?
@Chris-at-MavenАй бұрын
Ah I just reread your comment and get what you're asking. I used the duplicate approach here since I'm assuming the data won't change, but in reality I think referencing would be a smarter approach to keep everything in sync if the data changes - thanks for the comment!
@pierre-yves_davidАй бұрын
@@Chris-at-Maven There is an additional benefit (and possibly two): 1) if the source location change, you have only one request to correct => maintability 2) probably it is more efficient to download the Excel worksheet or CSV file once and to create the dimension tables from that unique source => performance
@NirRobinsonАй бұрын
@@pierre-yves_david 2- fully agree 1- via connection options you can also change it once 😇
@christabelabraham8402Ай бұрын
Never new life could be this simple 😂
@sunnygawande5283Ай бұрын
So if I do calculations on denormalized data then will it give an error??
@Chris-at-MavenАй бұрын
No, it's not that there's anything WRONG about denormalized tables, it's just that they contain more information than you technically need. Normalization is essentially just about reorganizing your data to minimize redundancy.
@Milhouse77BSАй бұрын
Good example of making a 3NF, but final result is not a good dimensional model aka star schema for Power BI. Never join fact tables together.
@Chris-at-MavenАй бұрын
That's the point we make at the end of the video, when we talk about how much normalization is appropriate. 99% of the time, simplifying the model to a star schema is the right move even if your tables aren't fully normalized.
@Milhouse77BSАй бұрын
@@Chris-at-Maven Understood, another point is that the fact table in a star schema is usually already in 3NF. the star schema fact table is not denormalized, but reorganized as opposed to the header-detail design. In this case, at 9:36, with dimensions in Transactions table, and TransactionID, OrderID, and LineID as "degenerate dimensions", the Transactions table is in 3NF. There can be more than one 3NF design. The artificial Transaction/Order/Line IDs don't contribute much to dimensionality of model. If have Customer and Time in fact table, could probably drop those IDs, except for benefit to tie back to source systems.
@MaxOnTheRunАй бұрын
Day ❤
@ahmeddafa-allah3603Ай бұрын
🎉🎉🎉🎉🎉🎉🎉
@hoang16191Ай бұрын
Is that your normal voice or u attend to lower your tone?
@abd518411 күн бұрын
Remove background music
@mrbartuss1Ай бұрын
Why are all examples on this channel so simple and in real world it is all messed up...
@Chris-at-MavenАй бұрын
Fair point! The intention here is to help people build a really clear intuition for what data normalization means, and how to apply normalization techniques to create star and snowflake schemas. In later demos we'll start layering in more complexity and messier datasets, but that would be counterproductive unless you'll built that foundational understanding first.
@mrbartuss1Ай бұрын
@@Chris-at-Maven I totally agree. However, you’ve already made plenty of videos for total beginners. More complex content would be really appreciated
@vishalmane3139Ай бұрын
half information
@Chris-at-MavenАй бұрын
🤔
@vishalmane31392 күн бұрын
@@Chris-at-Maven how to make dim and fact table hw to identify pk and fk
@remek5758Ай бұрын
Actually, isnt normalization meant to be for Transactional databases (inda like snowflake schema) and denormalization is simplifying queries for analytics purposes (star schema) ? maybe I'm just confused. But I dont know anyone who wants to have Snowflake over Star Model in analytics, (I Know that sometime you have to but thats not ideal)