Thanks for that Patrick. I have been using star schema and some good data modeling practices and I have to say: "This is the way". Not only performance is better: design, end user understanding maintenance is much much easier as well. The good practices with Power BI make us Super Power Workers! Thanks again!
@Real285 жыл бұрын
This is 100% basics right here. Its all review for me but Im watching to support this great channel and to simply keep this fresh in my brain. STAR schema is a must in most cases.
@GuyInACube5 жыл бұрын
Love it! And love the support! 👊 Sometimes going back to basics is a good thing.
@Real285 жыл бұрын
@@GuyInACube I'm just now getting into PBI after years in SQL. So designing the back end is my specialty. But the same rules apply in a lot of situations because the concepts are the same. Many times I have to remind someone "do we need the information in two places or can we table these out and relate them?"
@phanirj5 жыл бұрын
I am looking for job.. Is there any vaccines, please
@felipebizarre3 жыл бұрын
NO WAY YOU CAN HAVE TWO DATA TABLE DISPOSITIONSSS, my mind just exploded ugh Patrick you're and angel sent from MS Heaven
@jeremyanderson23744 жыл бұрын
Dude, your videos are incredibly helpful. I've learned a ton from you over the past few weeks!
@dangelo905 жыл бұрын
I have recently started expanding my knowledge with PBI and your channel has amazing information, examples and tips. I appreciate your work very much! Thank you for your efforts!
@KuKuTV1084 жыл бұрын
u r one of the best teacher I have been through (few among above 1500 teachers world wide)
@bcippitelli5 жыл бұрын
Thanks for that Patrick. I have been using star schema and some good data modeling practices and I have to say: "This is the way". Not only performance is better, design is easier, understanding is easier and the maintenance is much much easier. The good practices with Power BI make us Power
@GuyInACube5 жыл бұрын
Bruno Cippitelli Yes! Just makes life easier.
@marthasanchez-avila90435 жыл бұрын
Love it! I’ve leveraged this process for all sorts of reports, everything from property and date tables to organize my various sources of data. Thanks for the deeper dive .
@GuyInACube5 жыл бұрын
Great to hear! Thanks for watching 👊
@innocentiuslacrim22904 жыл бұрын
Greetings from Finland. I find your videos really beneficial in getting better in the fundamentals when working with Power BI. Earlier I was working on a project with Cognos where the databases were already ready and I could only work in the UI and then give people with access to backend tasks on what to do there. That was pretty terrible as we were always facing performance issues to the point where individual KPIs were just failing randomly (timeouts). Efficient data modelling is really (REALLY) important when we want people to actually use the tools we create.
@hectoralvarorojas19185 жыл бұрын
Great topic you have chosen to talk about it here. AWESOME video Patrick! Now I will be waiting for the Part 2. Congratulations!
@patshanz4 жыл бұрын
Great video. Smart. Great pace. You very quickly setup the various problem statements, explained the options, and demo'd. You're a great instructor. Thank you!
@marcocardicchi14 жыл бұрын
You guys are by far the best at generating good quality content.....from inside the Cube! 👍🤟 Keep these video coming!! Thanks
@andr1358 ай бұрын
Thanks!
@someshkhatawe34045 жыл бұрын
Adam's dataset video actually worked for my reports. Thank you both 😀😀😀😀
@GuyInACube5 жыл бұрын
Woot! That is awesome to hear. 👊
@Randyminder5 жыл бұрын
There is another drawback to wide tables I think you could have mentioned. When a context transition occurs, the entire table being iterated is brought into memory, uncompressed. For wide tables with lots of rows, this will ravage memory even more.
@laszlokatai-pal56854 жыл бұрын
"I wrote a video" - that's some badass PowerBi skills, mate :D
@therickestpicklerick Жыл бұрын
😂😂
@hectoralvarorojas19185 жыл бұрын
Patrick: How about to get the links for what you talk about here: 1) Star Schema Overview (you talk about in 6:39) 2) "Flat tables and create data model" (you talk about in 6:48) This will be great to have it! I will be waiting for your answer. Best regards!
@pacoaus5 жыл бұрын
Agree! Here is the link to 1) Star Schema Overview -- docs.microsoft.com/en-us/power-bi/guidance/star-schema
@nelsonma47115 жыл бұрын
Patrick, as always, you know what I think, AWESOME video. Cheers!
@GuyInACube5 жыл бұрын
Thank you Nelson! And thanks for watching. 👊
@789riteshclement5 жыл бұрын
This is so helpful. Can't wait for the other parts to come out.
@GuyInACube5 жыл бұрын
Thanks for watching and stay tuned it will be release soon!
@kel78v26 ай бұрын
My experience with the star Schema is mixed especially with independent product tables where it limits your ability analyse to a certain extent. Cross tables was one of them
@marcosoliveira87315 жыл бұрын
Your report is fast as long your data model is concise. Great explanation.
@amarkhaliq6413 жыл бұрын
I had the same problem last week. Having two fact tables were i couldn’t use a slicer for a field in both tables correctly. The slicer would filter one table but not the other.
@PeterHolcroft4 жыл бұрын
When is Part 2 coming?
@gyorgy89114 жыл бұрын
I guess it is that: Where to create your columns in Power BI | Data Modeling Best Practices kzbin.info/www/bejne/kIS4dKCfa81oibs
@CrazySw3de Жыл бұрын
Would love to see more videos like this that I can share with my team. In particular I've been running into issues where we have a general policy that all transformations/data modeling are to be done on the back end, with I think the intention being that the logic can be accessed by other sources if needed and not just locked inside Power BI. At the same time though, it just seems like this approach cripples what Power BI is capable of and leads to so many other issues. Especially when I see things like essentially multiple flat-file like views being pulled into a model, with relationships just being created in a really ambiguous way that has caused all kinds of problems that I inevitably end up needing to fix by creating a dimensional model. Would love to see a video going more in depth on concepts like when is it right to do a calculated column in SQL vs. having a measure in DAX, or elaborating on why its better to have a flexible dimensional model instead of applying all your filtering logic etc. to a view and then using that to drive a single report page. I've created really clean, robust dimensional models in the past so this sort of thing is infuriating to see, but at the same time I can't seem to break this misconception with people that creating a dimensional model takes too long compared to making a SQL view, or that having a pre-joined view in SQL isn't really a good replacement for a solid data model.
@AFellowGentleman4 жыл бұрын
Break out everyhting into dimensions and facts and you will avoid ultra wide tables and allow you to re-use a lot of these dimensions also. Sometimes doing this seems to suck because you have to do a lot of joins on data which feels like it belongs in the same table, but in general you save pain later on doing this categorization at an early stage. The most important thing is to break out the "conformed dimensions" because these can be re-used again and again and again in your fact tables.
@KirtC3 жыл бұрын
Thanks for your videos. I always enjoy them. I understand star schemas. Been using them for decades. What causes my hangups are filtering directions in the model. Hopefully you have a video discussing that topic.
@jessemacdonough24584 жыл бұрын
Wow, very good information in here about optimizing tables. Thanks for the post as always, Patrick!
@matthewtupuola60913 жыл бұрын
New sub! Awesome vid and down to earth presentation with great humour and knowledge of the topic!
@sugartraders4 жыл бұрын
Awesome, Patrick, you make this stuff fun - thank you!
@Pri78G2 жыл бұрын
Excellent video. Very well explained. Thanks. I would like to see more videos like these around the topid BI. Thanks once again.
@antique-bs8bb2 жыл бұрын
Did a Part 2 ever emerge? Loved this one
@phungduong44684 жыл бұрын
omg I love the way he spoke out wiiiiide table. Give you a heart :)
@kimglick24944 жыл бұрын
Thanks Patrick! This was extremely helpful and easy to understand!
@GuyInACube4 жыл бұрын
Most welcome Kim! 👊
@patriciocahue37715 жыл бұрын
Yooooo! wassup! If you have SSAS capabilities, one should use this option for creating the model and then connecting to that source from Power BI. I find this to be a more efficient way to work with data coming from disparate sources. When things get too complex, it is always good to return to the basics. Good simple video with powerful information.
@syek34703 жыл бұрын
You are a Rockstar. Really Informative ,Great Job ..Keep it up and going
@jesslovejoy15334 жыл бұрын
Awesome!! I love watching your vids instead of going through formal Power BI training because I understand SQL and data analytics very well and want to jump right into using this tool which is new to me. Power BI is incredibly powerful and it's actually easy enough to get started in, but as things get complex it's not always intuitive. So thank you for all the tips, info and best practices! :) I do have a question though, and maybe you have already made a video on this but I'm new to the channel so here I go! Can you talk about the difference between star schemas, Merge with a JOIN, and simply setting up a relationship between 2 tables via the Manage Relationships button (which is maybe the same thing as star schema but I didn't realize that?) ? And when it is best to use which? I find myself wanting to use Merge b/c it's the most like writing in SQL, but I want to use more tools within Power BI, and let it do the work for me!
@eagillum4 жыл бұрын
Yes, I also want more relationship/join/star schema videos. But even more beginner than you've done.
@petecardona82032 жыл бұрын
Always enjoy your videos -thank you 🙏
@abeworldforever5 жыл бұрын
Adam, this video is a good start for someone that has not knowledge of star schema, but in my opinion you missed one opportunity : you explain how to use a dimension table, but realistically, if someone has no knowledge of data modeling, it would have been useful to show how to create such tables ( maybe by using a function table with distinct values for example ? ). in your example, you jump from having no dimension table, to a fact already having the foreign keys implemented, which is a big jump. Cheers,
@GuyInACube5 жыл бұрын
Great point, it was a big jump. That was actually a thought when recording the video. However, around the 6:50 mark Patrick refers to another video where is demonstrates how to do this. Check it out kzbin.info/www/bejne/rJuloaWln7R2sLc.
@bongrobs Жыл бұрын
awesome tips patrick, love it!
@vicoherndon4 жыл бұрын
Great channel! Cheers from Rio de Janeiro, Brazil!
@GuyInACube4 жыл бұрын
Appreciate that Vinicius! Hope you are doing well down there 👊
@StanMoong5 жыл бұрын
Thanks for the great tips. Currently, I have the following requirement for dashboard to show monthly comparison for the whole year, as well as, year to year comparison, with ability to drill down to transactions. 6 excel source reports each month, from different sources. These reports need to be consolidated after complex transformation and additional classifications from user mappings. My initial thought was to make it into one giant dataset for user convenience. After watching your video, it seems I need to redo from scratch and build the star schema, with additional mappings. Reason is there is no standard key fields from the different sources. Imagine you have 3 sales reports but for the same products, each report uses a different product code. Would this be the right approach?
@MrTC-rv3jo2 жыл бұрын
Hi Patrick, Great Video! But where is part 2 of this video as the title suggests? Thanks!
@uncle_eddies_adventures5 жыл бұрын
Hey Patrick, I'm not seeing the links to the STAR schema you referred to and I would also be interested to watch the video you did with your daughter on the topic.
@GuyInACube5 жыл бұрын
Apologies for that. Here is the link - docs.microsoft.com/power-bi/guidance/star-schema
@gkool46553 жыл бұрын
You guys channel are literally saving thousands of people from losing their jobs
@pipertripp10 ай бұрын
Also, great channel. Cheers to you and Adam!
@Cassiethecat6 ай бұрын
Great lecture! Can I ask you where the part 2 video please?
@oscarzamorano69015 жыл бұрын
Awsome advice!! many thanks Patrick... Hello from Colombia, Sourh America...
@GuyInACube5 жыл бұрын
Most welcome! Thanks for watching! all the way in South America 👊🙏
@mantistoboggan33842 жыл бұрын
Great video! Thank you for the very easy to digest examples
@frankw31013 жыл бұрын
Hello, I would say that the schema you are showing at 8:30 is not a start schema but a snowflake schema. Normally in a star schema you would only only have fact tables "in the middle" and then dim tables connected to the fact table. But no dim table should then have other dim tables connected to them. If you have dim tables connected to other dim tables then this is called Snowflake schema and this structure will reduce the performance as not only one filter is used but several filter must be used to get the result. To get an ideal star schema it is then necessary to have redundant data in the dim tables. and that is the biggest difference to a database schema. In a database schema you will try to avoid redundant data by normalising the database tables. But this normalisation is not usable for creating Power BI reports with optimal performance.
@Sarah-bb6nv5 жыл бұрын
Hello, I'm new to Power BI. I'm used to using Power Pivot in Excel and joining tables through SQLServer to create queries (sometimes many many tables). Occasionally creating relationships to other queries within the back end. I was just curious if you guys had any recommendations on when to join tables through relationships or when to merge tables in Query Editor? Coming from Excel, I thought the best practices were to merge tables with joins, but soon found out that wasn't optimal in many cases. So any tips? Thank you!
@EverythingDataWithSravani4 жыл бұрын
Your videos are really helpful. Can you please do a video on using multiple fact tables with different granularities.
@kristinamelnichenko57753 жыл бұрын
Thanks for waiting that was a great video
@mchopra19893 жыл бұрын
Awesome tips. Where could I see the part 2?
@EsdrasMellemberg4 жыл бұрын
Very good ... Looking forward to part 2!
@SolutionsAbroad4 жыл бұрын
Great video Patrick as always, is it more performant to have a relationship, or merging the columns in Power Query?
@sagnikmukherjee63134 жыл бұрын
Hello Patrick - Thanks for the videos. Learnt a lot through your videos and your unique teaching style :) I have a situation and I would like your inputs on this. I have a Fact Table where I have 3 different dates like Order Date, Shipped Date and Delivered Date. I have a custom Date Dimension Table that I created in my Data Model using the CALENDARAUTO() Dax Function. Now I need to use that Date Dimension Table as Role Playing Dimension because for some queries, I need to leverage the join between Order Date Date, for some Shipped Date Date and for some Delivered Date Date. However, while building the relationship I can only have one Active relationship between the Fact Table and the Date Dimension Table. I could think of 2 different possibilities based on whatever knowledge I have gained. Number 1: I know that I have an option to create 3 versions of each measure using the USERELATIONSHIP Dax Function to force which relationship to be used while calculating the measure. But as I mentioned that it would mean that I need to create 3 version of each measure e.g. Sales by Order Date, Sales by Shipped Date, Sales by Delivered Date etc. Number 2: Otherwise I think I have to have 3 separate Date Dimension Tables like Order Date Dimension, Shipped Date Dimension and Delivered Date Dimension. Can you please suggest what should be the right and appropriate way to solve this model design situation? Looking forward to your help.
@felixsaint-gelais-nault3028 Жыл бұрын
I think 3 tables would be simpler
@Jack2of35 жыл бұрын
The issue I would like solved, and you mentioned, is the memory usage. PBI works great with Excel obviously because Excel dataset size is limited. Hook it up to a database with hundreds of millions of rows regardless of how well modeled, partitioned, indexed and it just goes to sleep as in task manager, end process, sleep. I've cancelled the table analysis, joined the tables, published and the services can't handle it either. I can't decrease the data size any more than I already have. We get millions of transaction every day. Fact table has 10 columns. 2 dates, 4 numbers and four joinable dimension keys. The dimensions are created from their own tables. Everything that can be turned off in options is. Any thoughts?
@GuyInACube5 жыл бұрын
Working with large data can be problematic. That's where features such as incremental refresh and Aggregations really become powerful and I've seen data models with billions of rows work using those items. The struggle is real though.
@hc99873 жыл бұрын
Dang...where's the Power Bi 101 video! I just finished a Power BI course and it was great theory and cool to see all the tool can do, but I'm lost at where to begin! I need some basic report building exercises to show me step by step what to do. Any such resources?
@mohamadsaifjamadar19123 жыл бұрын
Thanks Patrick! Awesome advice.. I am great a fan of both of you guys. Just a question that, Is it a good practice to use SQL DB Views instead of DB Tables?
@Alpacastan21m3 жыл бұрын
Do you guys have a video on how to correctly handle Many to Many?
@peterh78424 жыл бұрын
Great vid question - How do you deal with data that contains different types of markers please i.e. ".." for missing data, "..." for suppressed data, "." for data from a different time period?
@RaphaelSantosNet5 жыл бұрын
Great video Patrick. So, I do have a question though: is creating conditional columns in the query editor better than creating custom columns in the data model? Does that make real difference in terms of performance? I do have a few reports in which I used to create custom columns, but I am seriously thinking in replacing them directly in the query editor. Thanks for all you do!
@lokeshramaraj28005 жыл бұрын
Conditional column in query editor would help. Bonus if query folding is enabled
@sravankumar17673 жыл бұрын
nice Patrick, Here multiple Fact tables are available . How can we handle the reports and dax queries..
@anaisalmasi31844 жыл бұрын
great channel! and thank you for what you do! i have a question. some time when i put some value in my table it s shaow me just the first value from my database and i can't choose any form of calculation (sum, average and co...) how can i do to change this? thank you agan
@johngay19813 жыл бұрын
Good content Patrick.
@orcademyedtech5 жыл бұрын
That was a quick and effective video on Data Modelling. I need help to model the data for one of my client. May be this will be of some help. Can I connect with you directly some how if I need some help on the data
@GuyInACube5 жыл бұрын
Great to hear Awesh! I'd recommend engaging community.powerbi.com for longer form questions. Tons of folks there that can assist.
@adolfojsocorro5 жыл бұрын
Thanks, Patrick! I love and follow in practice the theory of star schemas. However, 15 minutes into the real world you find that your stars are related and there is a dearth, if any, of examples on how to work such situations. The classic example: you build star schemas for orders and shipments and then realize that you need the shipments related to each order. Then what? One is not supposed to have relationships between fact tables! And this gets more complicated as you introduce more star schemas into your overall model.
@GuyInACube5 жыл бұрын
Fact-to-Fact. What a challenge. Typically you could integrate (join) two facts based on common dimensions. Using this method you can then analyze values between the two facts based on those dimensions. You could also look at degenerate dimensions, which is an advanced topic, but also a common practice.
@mjustesen5 жыл бұрын
@@GuyInACube Any chance of a video on this? :) Is it related to role-playing dimensions (you have a video on this: kzbin.info/www/bejne/aHPbkoiOod1mgZY) As far as I can see in youtube search no youtube video on degenerate dimension tables in Power BI, and very limited content on degenerate dimension in general..
@adolfojsocorro5 жыл бұрын
@@GuyInACube Yes, that works (it's what you do in the video) and it's a step forward in dealing with the whole situation. It would be interesting to keep developing your example, adding some other real-world challenges related to models with multiple star schemas in PBI.
@alt-enter2375 жыл бұрын
Wouldn’t a bridge table work? You could have a bridge table with the degenerate dimension (I love this term by the way). That way it could be a many to one from orders fact table to degenerate bridge table, and then one to many from degenerate bridge to shipping fact table.
@topjimmy444 жыл бұрын
Any tips on books or other resources for data modeling? I commonly find times where the data is set up in a way where creating summary tables using Power query would be necessary, or cases where I need to look for instances where a date in one table is less than or greater than a date in another table.
@EffnShaShinko5 жыл бұрын
This is pure gold.
@pipertripp10 ай бұрын
So basically, normalise your data if you have redundant data in tables to avoid duplication and the hideous many-to-many relationships and pivot wide tables to long format where that makes sense (normalisation will help with the width as well)?
@gopigadde67523 жыл бұрын
Hi Patrick, Need to understand how you are not getting an inactive relationship when you are dealing with multiple fact tables and multiple conformed tables? Is there any setting that you are making in power query editor etc?
@DPFierce5 жыл бұрын
Another great video and topic! If your new to Power BI and/or managing datasets, it's imperative you learn about relational database design, hence what this video talks about. The more efficient you design your database tables, so that you can create a star schema, the more analytical options you'll have in your reporting, plus your performance in Power BI will be optimized. Question...what's the reason/advantage of having different layout tabs in the model view within Power BI? How does that work in regards to a relational database design?
@GuyInACube5 жыл бұрын
Great points Doug. To answer your question, we use them just to focus on particular sections of a very large data model. For example, If you just want to see and work with relationships for a particular fact table. You could use a different layout to focus only on that table and it's related dimensions.
@tldrwithabiramisukumaran13344 жыл бұрын
Nice video. The demonstration of the data model seems to me like its Snow Flake. I know Snow flake is a variant of the star schema but varies at one critical point that Star Schema is allowed to be denormalized (which is opposite to what you are recommending in terms of narrowing the table) as it has to contain the attributes of the dimension whereas Snowflake is strictly normalized. Could you please clarify how your example defies the variation and conforms to Star schema?
@jourdango26154 жыл бұрын
I have an important question! What is the difference between data modeling (like star schema) and database design/ database schema? How do we design a database so that it flows nicely to a data model? Can’t the database schema already just be star schema so that they are one ans the same??? But how can we expect users to update data in star schema form when everything is so fragmented and it uses integer IDs everywhere? Thanks!!!!
@joelatino37484 жыл бұрын
Great video, thanks for putting this together.
@pranayreddy73033 жыл бұрын
hey patrick pls do a vedio on how to avoid bidirectional relationship and manu to many relationship
@AnupamKumar-sc5jx4 жыл бұрын
Great Video. at 7:30 are we creating lookup tables from large table in Power BI itself. Is there any other video on how to do it.
@robertoajolfi77825 жыл бұрын
Great video as usual Patrick! At 6:50 you mentioned a previous video on how to create narrow tables starting form a wide one. I haven't been able to find it; can you please provide the url?
@GuyInACube5 жыл бұрын
Thanks for watching. Here is the link kzbin.info/www/bejne/rJuloaWln7R2sLc to the video.
@robertoajolfi77825 жыл бұрын
@@GuyInACube Great! Thanks a lot a very interesting video, especially from a trainee perspective. Sometimes I have some hard time with people that do not understand why we talk about modelling, normalization and relationship.
@DarkOri3nt5 жыл бұрын
Imagine there is no dw but numerous summarised tables built with numerous dimension tables in rdm would the best way to tackle this be building denormalised table structure into a star schema model ? Our company has numerous models with different levels of summarisation - aggregation in the same model would you create lowest level of data and summarise using measures to aggregate to different levels using dimension relationships ?
@PhilWhite2225 жыл бұрын
Thanks Patrick. All your videos have helped a ton for me. Question... If I have two excel reports that have 200 columns each when I connect those to Power BI would I still be able to maximize performance if I duplicate the tables and in my first edit in the query I remove 190 columns and leave it with 10-20 columns and repeat the steps until I have say 10 new narrow tables with relationships connected with 1 key value for a 1 to 1 in all 10 tables. Didn’t know if by having 10 tables that start with all those columns does Power BI start by pulling in those huge wide tables and therefore I didn’t help my performance? Or does removing all columns in first step of my edit still accomplish good performance? FYI - it’s not possible for me to create multiple reports before bringing into Power BI. I am stuck with those two reports. Or is it better to use Power Query in excel to establish 10 tables off the big table in the excel workbook and then connect to Power BI ? The excel workbooks are updated daily manually by copy and paste overwriting previous info if that helps to understand my scenario. I have a few limitations on that as of now.
@GuyInACube5 жыл бұрын
From a model perspective, you should definitely see performance improvements by creating a start schema. This video walks you through those steps kzbin.info/www/bejne/rJuloaWln7R2sLc. This approach could slow down refreshes since there may be several steps required in Power Query to prep the data.
@jahedulrasel24524 жыл бұрын
Excellent done ! thank you.
@chanchalarya9832 жыл бұрын
How can I work with unstructured data, what process should I use to make structure data
@00EagleEye003 жыл бұрын
Good day sir. 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.
@sureshramadurgam37304 жыл бұрын
Hey Patrick i like your videos they are really helpfull for a newbies like me. I have a question whether i can use direct SQL tables in to power BI or do i need to create any views or Sql query or SSAS cubes first? . What happens if i use direct SQl tables into power bi in import mode? SQl tables size is relatively small
@tucavaleu5 жыл бұрын
Hey, Patrick! First of all congrats for your tips. So... could you put here the link where you talk about “Avoid many-to-many relationship”? I didn’t find it. Thanks, bro
@jimkyriacou40385 жыл бұрын
Great stuff again Patrick.......Jim from Oz
@karihosny94202 жыл бұрын
How many Columns in a Table you would consider it being a wide table?
@mranimal27115 жыл бұрын
Nice video Patrick! What about wide fact table? I have a wide consolidated fact table (60 Measures that are derived from 5 detail fact tables each covering 5 business processes - Sales, Marketing, etc..) that is rolled up w.r.t the conformed dimensions from the detail fact tables. this wide consolidated fact table is a physical table (with 60 Measures). Is this better than creating the 60 measures in DAX on top of detail fact tables?
@GuyInACube5 жыл бұрын
There are a lot of factors that go into that. Assuming these are integer columns and not strings as you referred to them as measures. Depends how many rows in the table, etc. Best bet is to determine what your performance baseline is and then if you can optimize that at all. If the baseline is pretty fast, you may not need to do anything. Also, if you are using all the columns then you need them. If you aren't using any of them, then can we get rid of them?
@romerofamily24536 ай бұрын
Hello Guy in a Cube, can you recommend a reputable Power BI expect? I need support integrating Power BI with forms and unfortunately the videos are a bit fast
@mjustesen5 жыл бұрын
Awesome video! I have a question for your model though - as it's shown at 08:35.. You have a Geography table that's related to your Customer table, so you can analyze InternetSales by Customer Geography. Let's say you would like to use the same Geography table to connect to SalesTerritory, in order to see Reseller Sales by Postcode or State (which is not existing in SalesTerritory). How would you go about that, as you cannot create a relationship directly between SalesTerritory and Geography (as it would introduce ambiguous relationships to the model). Is the solution to just duplicate the Geography table and connect it directly to ResellerSales..? Once again thanks for the great content, please keep it up :)
@GuyInACube5 жыл бұрын
Great question and even better observation. Honestly, in that case I would need to reshape the model. Since my Geography table would be on the many side of the relationship I would need to move it between ResellerSales and SalesTerritory. This is to ensure that all directions point to Reseller sales from the outer most dimension in the snowflake. With this change, I could reuse the same Geography table and avoid any ambiguous relationship. This is all theoretical since I don't have the data to validate this.
@TRINI123A4 жыл бұрын
Nice videos. Question that is driving me nuts: When I unselect all options in a filter in Power BI, the visualization shows as if all options were selected. It should logically show nothing. Thoughts?
@bradj2295 жыл бұрын
Love that Blockbuster shirt 😂
@GuyInACube5 жыл бұрын
Gotta keep it alive :) 👊
@franciscorodriguez2555 жыл бұрын
you are best ...! greetings from guatemala
@GuyInACube5 жыл бұрын
Appreciate that Francisco! Thanks for watching. 👊
@faisalmohammad25164 жыл бұрын
Wow super demonstration..
@MrYourDry5 жыл бұрын
Ah you're a life saver. Subscribed!
@karlaksixtos62944 жыл бұрын
Is it possible to add an already existing pivot table to a data model?? If not do you have any other option?? Thanks!
@GuyInACube4 жыл бұрын
You could get data from an Excel sheet. it would just be a static pull and you would lose the functionality of the pivottable.
@ThePalmefamily4 жыл бұрын
Do you have any tutorials with follow along for beginners?
@afsanarabeya44172 жыл бұрын
How can i narrower my table which have a column with comma separated string values for almost like 20?? And i really have to work with those values.. Really need the help. TIA
@shubhamrkrock4 жыл бұрын
Do relationships on numeric columns work faster than those on text columns? Hi Adam and Patrick, I have a very troubling question regarding the best way to design a data model I can't seem to find a solution online. It's about the relationships between tables in a Power BI data model. I have always been doing it on numeric columns (Keys), but a stakeholder is challenging that even if it is on long text columns, it's the same in terms of performance. Can you help me here by sharing your thoughts on below? - Ensuring the Primary and Foreign Keys between the DIMs and FACTs in the Power BI relationships are on numeric columns rather than text columns (This would also reduce the volume of data in the Model in terms of MegaBytes, so that also helps Front-end performance) o Example, DIM_ProductCategory and the FACT tables are on the concatenation of Level 1, Level 2…Level 6, that is a not as good as numeric columns o The FACT table has over 16 million rows which are just repetitions of 187 distinct values of concatenation of Level 1, Level 2…Level 6. This would consume way less space if these were just 1 to 187 number values. This is the same case in 3 such FACT tables (different levels) relationship with the Dimension table of ProductCategory
@lucernec31012 жыл бұрын
Can you tell me if we can do Power BI Adhoc Analytics