Hi, all,
I have a questions on the dimension wizard.
Question 1: Main table: the data source table where we want to derive the new dimension data from?
Key columns: the keys columns which are the key of the main table above?
Column containing the member name Here I am confused,), as when we choose composite keys for the main table above, we will have to choose the column containing the member name? What is this column for? And what does it really mean? This column containing what member name?
Please any of you here give me any advices on this and I am looking forward to hearing from you shortly and thanks a lot in advance.
With best regards,
Yours sincerely,
The key columns uniquely identify each member of an attribute. This is different from the key columns of the table which uniquely identify each row of the table. As an example, if you had a column containing Month names with 12 values and another column containing years with 5 values, but you wanted an attribute that contained individual members for every month of every year, 60 values, then you would use both Month and Year as the key columns of your attribute. Now the name column determines what each attribute will be called. In this example, you could use Month as the name column, but you won't be able to tell your January of 2006 from your January of 2007 (unless you just use this attribute in a hierarchy with Year above it.) Here you'd probably want another column - likely a named calculation which contactinates month and year - as your name column.
You might want to try the Analysis Services 2005 Tutorial included with the product to help with some concepts if you have further problems with this.
|||Hi, Matt,
Thank you very much for your kind advices.
I now have a clearer understanding of it. Thanks again.
With best regards,
Yours sincerely,
|||Hi, Matt,
Thank you very much for your kind advices.
But I am still a bit confused as key columns are the columns which relate the new derived dimension to the fact table (where this new derived dimension table from), therefore these key columns will be the dimension granularity of the usage of the new derived dimension to the fact table. But the fact table has composite keys consisting of different FKs of different tables, in this case, the name column will be the column naming the above composite keys? Actually in fact table, there is no such columns yet, therefore I will have to go to the data source view to create a such new name column for the above key columns which make up of the composite keys of the fact table?
Hope my question is clear and please give me further advices on this issue.
I am looking forward to hearing from you shortly and thanks a lot in advance.
With best regards,
Yours sincerely,
|||The key columns of the key attribute of the dimension uniquely identify each member of the attribute witht he lowest granularity in the dimension. Although it is common, it is not necessary that these key columns correspond to the relational key of the table which uniquely identifies each row in the table. It sounds like you have a table which contains both fact information and some denormalized dimensional information. In cases such as this where tables are not normalized, it is common to create dimension keys which are not the same as the table key. For example, if you had a table with sales information and it also contained the columns EmployeeNumber, EmployeeName, EmployeeDepartment, then you would probably want to create an employee dimension whose key attribute's key column was EmployeeNumber. Note that the table containing EmployeeNumber might not even have any key as it is common for fact type tables to allow duplicate transaction entries. (So a Customer would be allowed to buy the same product from the same employee on the same day, even if there is no notion of transaction ID.)|||Hi,
Thank you for your advices. The schema of my fact table contains transactional facts, and FKs from its related dimensional tables. E.g
FK1
FK2
FK3
TransactionID
.......
Thanks again.
With best regards,
Yours sincerely,
|||Hi, Matt,
Please ignore my previous post, I have figured out the problem.
Thanks again.
With best regards,
Yours sincerely,
No comments:
Post a Comment