relationship between the data is not showing when I tried to used the data source view
enter image description here
Are you sure there are relationships present. Plus even if they are not no problem, you can define them in the dsv. Simple create a logical primary key in you dimensions then drag the attribute from the fact to the dimension attribute.
Related
I have a fact table containing lines of different types. Based upon each type I have a different dimension table that I need to connect. Is there a solution to this problem without creating different fact tables for each type of line?
When connecting the fact to one dimension, I get the error that one key cannot be found in the dimension table. That's right, because that value exists in another dimension table
Here a picture of what I intend to achieve:
I have three tables, one fact and two dimensions. I want to make a referenced relationship between the fact table(measures) called InternetSales and the Geography table, se image(schemaCubeStructure".
The intermediate table is Customer. I first create the Geography and InternetSales tables and then the Customer with a field from Geography to use later when creating the ref. rel.
Everything works fine until browsing the data in the cube (se image "errorBrowseSalesCube". If i don´t make the relationship between the two tables i get image "correctBrowseSalesCube" which is what i want. That is i don´t get any data when processing with the rel.ref.
See image "dimensionUsageSalesCube for rel.ref.
Why is that i don´t get any data?
correctBrowseSalesCube
errorBrowseSalesCube
dimensionUsageSalesCube
schemaCubeStructure
What fields did you use when setting up your reference dimension relationship between Georgaphy and Internet Sales?
The in the AdventureWorksDW database, the Georgaphy dimension is a snowflake off of Customer dimension. In the AdvWrks cube project, Microsoft includes the geography table and corresponding attributes in the customer ssas dimension (red boxes in screenshot below). However, they could have, as it looks like you are trying to do, simply added the GeographyKey to the customer dimension (red arrow in screenshot below)
This exposes the GeorgaphyKey field when creating the reference dimension relationship so that you can properly define the relationship between the intermediate dimension (customer) and the reference dimension (geography):
After that, you can properly browse the Internet Sales facts by Georgraphy dimension attribute (and user) hierarchies:
The correctBrowse sales cube can be easily explained. It means that the data is not calculated based on the Geography dimension and thus indicates that the connection between the Internet sales and the Geography is not correctly calculated.
I would suggest the following:
Try making the customer a Mesaure (or fact table). Do not rename it just make a measure i.e. the count of customers (can be used as a counter of customers/per region or can be invisible altogether).
Then The customer will appear as a measure in Dimension usage and then connect Geography to Internet sales via a many to many relation Using the customer measure table.
I have a Dimensional table structure which resembles the following:
Ideally the hierarchial representation should be
CodeClassDesc --> CodeDesc
So A would be a Parent to A and B; B would be a Parent to A, B and C in my Analysis Server Cube. The problem is that because CodeClassDesc has multiple entries in the table it produces multiple duplicate Parents in my Cube with a single corresponding Child Element per Parent which is not what I'd consider a true Hierarchy. Or at least not what I am looking for the expected results.
I believe this is possible in SSAS without having to manipulate the data within the table via a VIEW but I don't know what I'm missing.
I've tried defining the CodeClassDesc and CodeDesc fields as a composite key but that doesn't work, yet I am almost certain there is a way to do this.
After attempting every conceivable permutation of methods to acquire resolution for this, I concluded that normalization of the required attribute was the only way to resolve the issue of having multiple entries of the Parent for every corresponding Child element.
So I created a VIEW of the table using a DISTINCT SELECT of only the CodeClass and CodeClassDesc fields in my DSV (DataSource View) in the Cube. Then I set the CodeClass field as a logical Primary Key and created a relationship between it and the CodeClass field of the main table.
I then used the CodeClassDesc field of the VIEW to create the top-level parent in my Dimension, which gave me only 1 distinct record for each value; and added the CodeDesc fields from the Table to create the Child Relationships. Works like a charm so I guess the answer would have to be that you cannot create a Parent Hierarchy consisting of a single Value per Parent if the source has multiple records.
In the dimension structure, you should change the property KeyColumn of the attribute "CodeClassDesc" to a composite key containing both "CodeClassDesc" and "CodeDesc" then change the NameColumn property to show itself
I currently have a source fact table, that references all of its source dimensions. I have already used SSIS to take the source dimensions and load them into our destination dimensions. While doing this, I had a PK created in each dimension, and moved the original source PK into another column within the table.
The trouble I am encountering now, is how to perform the look from when I load the source fact table into the destination fact table, and have each source dimension primary key (now in a new column in the destination dimensions) reference the correct destination dimension primary key. Of which, the destination primary key will be in the destination fact table.
Would I need to use SK lookups, or just a transformation lookup? Furthermore, for a novice user, what would be the easiest / quickest to learn?
Hopefully some of this makes sense!
Thanks in advance for any help or advice!
I didn't completely understand your scenario, its quite confusing. Maybe if you give more specific examples it would be easier to help.
Nevertheless, the logical behavior in these type of scenarios is always load the dimensions first and when loading the fact, you use lookup transformation components to get the correct value of the foreign key from the dimension tables
here is an official video from youtube teaching how to use this component
When loading the data from the source "fact" you would be looking up the Source PKs, which in your case would be the Business Keys, or what you would call it. If you are using SCD type 2 dimensions, you would perhaps also want the Start/End dates in your lookup as well.
For Non-type2 dimensions, the easiest (and fastest) would be to just do a regular lookup. Your Source Fact table has a DimA_id (which is the Business Key). Use SELECT PK, BK FROM DimA in your lookup task, join the dima_id to the dimensions BK, and put the PK into the downstream. Use the PK when inserting to the destination Fact table.
In SSAS I have three dimensions one of which relates to a fact table. When I process the dimension with attributes from each of the other two dimensions I get the above error.
There is definitely a join, between the main dimension and the other two dimensions. The primary key in the same dimension i.e book also relates to the other book foreign keys in the other dimensions.
If I script with two joins it works but SSAS doesn't seem to pick this up.
I have looked at previous posts and tried their recomendation but they are not appropriate for my issue it seems.
Have you refreshed your DSV ? From what i can remember this was usually caused by something going mishap in the DSV, so that the table or view used for the dimension wasn't accessible
Could you post your DSV? Last time I saw this error message, the table relationships were set up incorrectly in the DSV, causing a circular reference.
This error occurs due to selection of attribute from any other tabale/view instead of related one.
Go to dimension structure -> datasource view pane (center pane)
Right click and -> show related tables
Drag and drop field from table/view .
It should work fine.