I am trying to create a new dimension in my cube, that is a subset of another dimension. I am working with SQL Server Analyisis Services.
I have a measure that represents the number of employees in my organization, both in brach offices and in the central office, and I have a Location dimension that contains all offices.
I want to create a new dimension that contains only branch offices, so that when I apply it to the measure it show me only the numbers in the branch offices and the total aggregates only the employees in them.
I could create another dimension table with only the branch offices in it, but then I would have employees asigned to an Unknown member (the central office)
I also want to keep the original dimension, where I can see all offices and get the total of employees in the organization.
I understand I could get that result using with my current Location dimension applying a filter to my query, but I was wondering if it was possible to create a "pre-filtered" dimension.
You could add an additional measure (possibly calcualted) called something like Branch Office Employee Count that excludes head off employees. The name of the measure should make a count of 0 against the head office self explanatory.
If this is something your business often measures I'd take this approach. If not I'd put a new field in the existing dimension for filtering/etc.
Related
I am going to model one of the star schemas for a university data warehousing project. We need to compare the actual application count with a target.
There are target counts (set by the colleges every year) associated with Departments, Course groups, and Courses.
The requirement is to ensure that the targets set get correctly allocated and also the progress of applications against the target.
One proposal is to include all the actual counts (department level total accepted count, course group level total accepted count, course level total accepted count) and corresponding target counts (dept level target counts, course group target counts, course target counts) in single fact table. One of the dimensions in this star schema is Course dimensions. It consists of all the
course, course group and department information. I do understand a granularity problem here, but this could be handled at the cube implementation level.
Or if I want to set the target at different hierarchy levels of a dimension, should I build different fact tables? As mentioned below:
Implement 3 fact tables for 3 different types of targets and connect these fact tables to the actual fact table. In this situation, the Course dimension can snowflake into course group dimension and department dimensions. First fact is connected to course. Second fact to course group and the 3rd one to dept. The actual fact table is of granularity of course level so all three fact tables can be connected to the actual fact table via course. Note that the actual fact table is of grain course-level and this can be aggregated to get higher level such as course group and dept actual counts.
Data Architects please comment!
I have a fact table called "FactActivity" and a few dimension tables like users, clients, actions, date and tenants.
I create measure groups corresponding to each of them as follows
FactActivity => Sum of ActivityCount colums
DimUser => Count of rows
DimTenant => Count of rows
DimDate => Count of rows and distinct count of weekofyear column
Each user can do multiple actions using multiple clients. A tenant is logical grouping of users. So a tenant contain multiple users but a user can't belong to more than 1 tenant. All the dimension tables and fact tables are connected to DimDate via regular relationship.
The cube structure is as follows.
Now I want to defined the dimension relationships to each of the measure group. Some of them are Many-Many relationsip (to enable distinct count calculation). The designer is showing me multiple options to choose from for many of the intersections. I'm confused as to which one to select as intermediate measure group. Should I always pick the measure group whose total # rows is the least ex: DimDate? Or what is the right logic to determine the intermediate measure group.
This is what I got. IS this right? If no, what is wrong?
For more information to hep choose the right answer.
FactActivity = 1 billion rows
DimUser = 35 million rows
DimTenant = 1 million rows
DimDate = 1000 rows
The correct way to choose the intermediate measure group depends on how you want to evaluate your measures with respect to the dimension related:
Let's start with Activity measure group to Tenant dimension: The question is: How should Analysis Services determine the activity count (or any other measure in the Activity measure group) of a tenant? The only reasonable way to determine this would be to go from the activity fact table through the user table to the tenant table. And actually, the last relationship is not a many-to-many relationship, but a many-to one relationship. I. e. you could optimize away the tenant dimension by integrating it into the user dimension. However, using a many-to-many relationship will work as well, just be a little less efficient. You might also consider using a reference relationship from user to tenant instead of a many-to-many relationship. And there may be other considerations why you may have chosen to have them two separate dimensions, thus I do not discuss this any further.
Now let us continue with the next one: Tenant measure group to User dimension: The way you have configured it (using the date measure group) means that for each date that a tenant and a user have in common, the tenant count of a user adds one to the count. This is probably not what you want. I would assume you want to relate tenant measures to user dimension by the user measure group. However, I am not sure what the purpose of the DateKey in the user and tenant dimension tables is at all. Thus, your relationship may be correct.
Let's continue with the relationships from the Date measure group to the Tenant and User dimensions. I would assume there should be no relationship at all, as the week of the year and the date count do not depend on tenants or users. Please note that it is absolutely ok to have no relationship between some measure groups and some dimensions. If you look at the Microsoft sample cube "Adventure Works", it has more gray cells (i. e. measure group and dimension being unrelated) in the Dimension Usage than white ones (i. e. there is some kind of relationship between measure group and dimension, of whichever type). In the default setting of IgnoreUnrelatedDimensions = true of a measure group, this means that the measure value will be the same for all members of the dimension. This should be the case for date count and week of year. However, again, as I do not know the purpose of the DateKey in the user and tenant dimension tables, I am not sure if this assumption is correct for your data.
And after these examples, I would hope you can continue with the rest of relationships yourself.
Let's say 2 fact tables Employee_Fact and Manager_Fact are available. And the dimension tables like Organisation_Dim, Location_Dim, Department_Dim, Calender_Dim.
Employee_Fact is connected with all the dimension Tables and Manager_Fact is connected with the alias of the same dimension tables.
In Report 1, I have a table that gives the Organisation_Name, Department_Name, Employee_Salary, Manager Name and Manager Salary. In this report I need the filter Organisation Name, Region. Also, the drill down from Organisation Name --> Department Name --> Location --> Manager Name --> Employee Name.
I have 2nd Report that shows the Organisation Name, Department Name, Department Amount, Location Name, no of Employee. Here I have drill down from Organisation name --> Department name --> Location.
How can I obtain drill down in this scenario. Do I need to add 2 different Hierarchy or only one hierarchy is needed? This confusion occurred as I take values from both fact tables in 1st report.
For the example you described, you would probably be better off not creating aliases of your conformed dimension tables, but instead joining all dimension tables to both fact tables, then creating two contexts. One context would include all of the joins between employee_fact and the dimensions; the other context would include manager_fact and the dimensions.
If there are any dim tables that are not conformed, then they will simply be joined to only one fact table (and, accordingly, will only be in one context).
With this model, you can create a single query that includes measures from both facts, and attributes from one or more dim table. The report engine will automatically create a separate SELECT query for each fact table; but it will be presented as a single block in the report.
You will also only need a single hierarchy since you no longer have multiple copies of dimensions.
Regarding your statement:
I have 2nd Report that shows the Organisation Name,Department Name,
Department Amount, Location Name, no of Employee. Here i have drill
down from Organisation name --> Department name --> Location.
This doesn't really make sense. If your report block already contains Department Name and Location, there would be little value in offering a drilldown from Organization Name.
It was a mistake that I did not select the same drill down objects in my Report too. Rather I selected from other Class Folder which did not give correct hierarchy.
Thanks
Niki
I have a fact table with columns Product Model and measure Installed base(not important, any other measure would do the same).
Than I have dimension table, and here comes the tricky part:
I have many product models, and each belong to higher level custom_groups (4 in total),
Same product model may belong to more than one custom groupX, and custom groupX may belong to more than one custom groups X-1.
for example hierarchy from highest CG1 to lowest PM Level:
XXX=>YYY=>ZZZ=>WWW
LLL=>MMM=>QQQ=>WWW
RRR=>PPP=>QQQ=>TTT
you can see, that last level PM WWW belongs to 2 different custom groups 3 (QQQ and ZZZ) whereas custom group 3 QQQ may belong to two different custom groups 2 (MMM and PPP in this case).
I tried to model this via hierarchies in SSAS but either I got wrong measure results (IB is summed up without aggregations and results are same for all custom groups), or I get missing some custom groups in my hierarchy.
You can solve this using a many-to-many relationship: Create a dimension table with four columns for the four custom group levels, as well as a custom_group_id column. Fill in to this table all combinations of custom groups that appear in your data. Then build a bridge table (aka factless fact table) with the two columns product_model and custom_group_id. Fill a record into this for each group combination that a product belongs to.
Then, in BIDS create a dimension from the custom group table, and a measure group from your bridge table, using count as the only measure, and make this measure invisible. Finally in the "Dimension Usage" tab of Cube Editor, configure the relationship between the main measure group and the custom group dimension to be many-to-many via the bridge measure group.
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.