I have a question on best practice for a bridge table design:
I have a Fact table that has the following 3 columns where the primary keys are in bold:
Generator
FuelType
FuelCost
I then have a Generator dimension with the following columns:
Generator
PrimaryFuelType
SecondaryFuelType
I would like to be able to view my results by the combination of {Generator,PrimaryFuelType} and {Generator,SecondaryFuelType}
I was planning on creating 2 measure groups based on the Fact table and use my Generator dimension as a bridge in both. Basically have {Generator,FuelType} as the Join Columns (fact table) and {Generator,PrimaryFuelType} as Join columns (Bridge table). For the 2nd measure group it would then be {Generator,SecondaryFuelType} as Join columns (Bridge table).
Is that the best way to approach it? Would a potential restructuring of the data format in the dimension table make this more efficient.
thanks,
John
Using a bridge in the link definition of the measures between Generator and PrimaryFuelType and SecondaryFuelType (the dimensions) is a possible solution.
There is also another possibility, is to create a Dimension called Generator with 3 hierarchies ( Generator, PrimaryFuelType and SecondaryFuelType ).
The solution you choose will depends on the size of the Generator Hierarchy (if it's huge better not) and if you want to have it for your reports. Indeed you could hide the hierarchy using a perspective.
_hope it helps
Related
I'm performing a query and joining data from 3 different tables. In the final table, I would like to know which table each individual column comes from, since some of the column names repeat themselves. At the moment, I am doing a very long:
| project prefix1_column1=column1, prefix1_column2=column2
for each join.
In a perfect universe, I could add a parameter to the joins to specify a prefix but that doesn't exist. Is there a cleaner way to do this?
What you are currently doing is the best way to do it. For the feature you are asking for, please open a suggestion in the Azure Data Explorer user voice.
You should also look at the lookup operator, which does not repeat the columns that are part of the join keys, while this will not solve your use case it will reduce the noise.
I'm trying to figure out the best way to link a dimension to a fact table and having some trouble finding an example in the documentation. All of my data sources are csv files and I have the following 2 data tables:
Areas table with columns: Area,DateTime,Cost (Area,DateTime are unique)
Company table with columns: CompanyID,Area (CompanyID is unique and represents a dimension)
I would like to link the Company Dimension to the Cost measure from the Areas table. However, it seems that I can only link the Company dimension to the Areas measure group through the dimension key, which is CompanyID. Is there a way around this or do I need to add a CompanyID column to my Areas csv file prior to loading.
thanks
I'm not really sure what you want to achieve but it looks as you could use a many-to-many cube to create a link from Area to Company (even though it might be a one-to-on relation).
1) Create a many-to-many cube using your Company table (Advanced/Many-to-Many)
2) Bind the Company dimension in the facts, Area table, using the defined many-to-many relation.
Some documentation here (the first image is wrong).
hope it helps.
There are 3 entities:
vehicle_model
vehicle
extra_options (such as open top, leather seats, etc..)
Vehicle model can have a subset of the extra options.
Vehicle can have a subset of it's model extras.
I've been trying hours to figure out how to represent this as er diagram, but without success. I Thought about ternary relationship ,and although I don't understand it completely I think this isn't the way.
I thought about creating another 2 entities, model_ext & vehicle_ext ,so that vehicle_ext would be connected to model_ext but this isn't a good design.
This is my first er diagram design. I'm really lost (read er-diagram chapter in "Silberschatz, Database System Concepts" three times already) so any idea would be appreciated.
did you try adding a new table say 'vehicle_vehicle_model_extra_options_map'? (you can name this table to any thing short, but for better explanation i use __map as a standard way for defining the map tables.)
note those two null able foreign key columns in this table.
Basically, vehicle has one to many relation to extra_options, and vehicle_model has one to many relation to extra_options table, therefore the new table was added.
updated:
I am working on building a data mart for reporting purpose.
I am new to this field and looking for help.
I have a fact table and two dimension tables.
The fact table has only 3 fields, its primary key and foreign key references to two dimension tables.
The two dimension tables have data related to 1)phonenumbers and 2)extension numbers.
(I cannot combine these dimension tables because they have different information)
As you see my fact table does not have any quantitative columns.
I want to generate a report that displays phonenumbers and corresponding extensions.
I can get this information by performing a join on the two dimension tables.
So my question is do I have to use fact table for the report? i.e Should I first get the key from phonenumber table, perform join on fact table, get extension key and perform join on extension table?
OR
Simply join the two dimension tables to generate the report because it is possible in this case?
Do we have to involve the fact table?
Thanks for reading.
Any help is appreciated.
do I have to use fact table for the report? i.e Should I first get the key from phonenumber table, perform join on fact table, get extension key and perform join on extension table?
Often, this is necessary.
Simply join the two dimension tables to generate the report because it is possible in this case?
Sometimes, this works, also.
Do we have to involve the fact table?
Depends on the relationships.
If you have a "hierarchy" of dimensional information, then the two dimensions could be directly related. In this case, the fact table doesn't tie them together. The fact ties to the detailed dimension; the detailed dimension ties to the summary. This is rare.
Dimensions change.
If you have two or more Slowly Changing Dimensions, then your dimensions may include lots of "previous" relationship information.
Fact 1: Phone xxx-xxx-xxxx, Extension yyyy
Fact 2: Phone xxx-xxx-xxxx, Extension zzzz
Then, another load applies an SCD rule to modify zzzz to aaaa, as of 7/1/11 You may have the old dimension values available, as well as the new dimension values, with an applicable date range.
Now, the fact (and the date range) are required to define which copy of the dimension value you're going to get.
Fact 2: Phone xxx-xxx-xxxx, Extension zzzz, from beginning to before 7/1/11.
Fact 2: Phone xxx-xxx-xxxx, Extension aaaa, from 7/1/11 to end.
So, you may need the fact, dimensions and time to sort out the relationships.
Am making a cube in SQL Server Analysis Services 2005 and have a question about many to many relationships.
I have a many to many relationship between two entities that contains an additional descriptive column as part of the relationship.
I understand that I may need to a bridge table to model the relationship but I am not sure where to store the additional column - in the bridge table or elsewhere?
Many To Many relationsip in SSAS can be implemented via an intermediate fact table that contains both dimension key that subject to the relation.
For example; If you have a cube that has a book-sales-fact table and you want to aggregate total sales by author (which may have many books and a book may be written by many authors) you should also have a author-book intermediate fact table (just like in relational database world). In this bridge table, you should have both dimension keys (Author and Book) plus some measure related to the current book and author such as wages paid to the author to write the book (or chapters).
As a result, if your additional column is kind of a measure you should add that column to the intermediate fact table.