Forum Discussion
Post ProdigyCombine TREATAS with Calculate function
No worries. Did you see my response here: https://community.powerbi.com/t5/DAX-Commands-and-Tips/Combine-TREATAS-with-Calculate-function/m-p/1953210/highlight/true#M42622
Basically I commented out your TREATAS and got the results you wanted as per your first post here.
I do not know what the semantics of your model should be like, but like you said in your last post, there is no direct relationship between the 2 table Main and Index. Even so, it is not necessary to perform your computation, as I have shown in my response at the link above.
Now, if on the other hand, you need some sort of relationship between Main and Index, then use everything you know from SQL re how to design a proper ER diagram. Those principles translate well to designing a star- or snowflake schema in Power BI. In fact, it's actually easier to design a star schema with Dim or Lookup tables on top in the modeling space, and the Fact tables underneath the Dim tables.
Fundamentally, if you are gonna have to deal with date and/or time, then you need to make sure you first create a well-formed DimDate table and/or a DimTime table. You can do it in M in Power Query Editor, or in DAX. I do it in M usually because that way I can parameterize the table creation. Google it and you'll find the code for both options online.
Once you have that, you need to think about the semantic relationship between you data and that will help come up with the Fact tables and what the relationships among them should be. And so on.
Post ProdigyElement115 First of all, thank you for helping me.
I tried with "Related", but it give me an error.
BTW, you could try with a Pbix file that I am sharing on the Google drive.
As far as I know, TREATAS is needed to create a virtual relationship because they are many-to-many relationship of (..Rating and ProcessinDate). I got a help for the original DAX code from this post that I asked earlier regards to this.
So, going back to idea of not using TREATAS, I guess what I could do is creating a combined column (by merging two columns) and create one column to connect two tables. I am trying to decide what makes more sesnse (to create a merged column in PowerBI, to create a merge column in SQL (data source) or wait for possible solution with code change).
I am leaning toward code change only (waiting for advice) because I could learn for possibility, but I also think that merging columns might be a good practice...
Thanks!
Memorable MemberBy the way, as a side note, looking at your model, and I should say, I am not by far an expert yet in DAX or Power BI, but nonetheless, my understanding of modeling tells me that in this case you are showing us, having a column with unique values in both tables you linking to via the bridge table, would be a good thing to have. Something like a unique key, ie what in the DB world they call a unique primary key, like an ID of some sort. If possible. The idea also being to avoid as much as possible many-to-many relationship and favor instead one-to-many relationships as much as possible.
Which also means, the most important part of the work is modelling. Screw the model up, ie not understanding how to categorize the source data and how to link it in a way that is conceptually logical and sensical for the problem domain, and you will find yourself in a world of pain real fast when trying to code DAX measures. I know, I learned the hard way ;-).
So getting the DB side right first: ideally pushing all your data to a data warehouse structure as opposed as getting from a OLTP relational DB (data structure is different).
Then import and ETL becomes easier too, and easy modelling naturally flows from there.
Good luck!