I new to OLAP, and still not sure how to create a relationship between 2 or more entities.
I am basing my cube on views. For simplicity sake let's call them like this:
viewParent (ParentID PK)
viewChild (ChildID PK, ParentID FK)
these views have more fields, but they're not important for this question.
in my data source, i defined a relationship between viewParent and viewChild using ParentID for the link.
As for measures, i was forced to create separate measures for Parent and Child.
in my MDX query however, the relationship does not seem to be enforced. If i select record count for parent, child, and add some filters for the parent, the child count is not reflecting it..
SELECT {
[Measures].[ParentCount],[Measures].[ChildCount]
} ON COLUMNS
FROM [Cube]
WHERE {
(
{[Time].[Month].&[2011-06-01T00:00:00]}
,{[SomeDimension].&[Foo]}
)
}
the selected ParentCount is correct, but ChildCount is not affected by any of the filters (because they are parent filters). However, since i defined a relationship, how can i take advantage of that to filter children by parent using a WHERE clause?
Facts:
viewParent, viewChild
Dimensions:
ParentDimension (contains attributes from parent view that i'd aggregate on)
ChildDimension (contains attributes from child view that i'd aggregate on)
This is just an idea i came up with, but maybe my design/relationship is off.
Figured it out.
Looking at the dimensions tab of the cube in vs2008 it became obvious.
my relationship between dimension and the measures was not set-up correctly. My dimension was keyed on uniqueID which corresponded to parentView uniqueID.
I changed the relationship (of SomeDimension) to key on a different ID field (shared by both parentView and childView) let's call it ViewID.
and my MDX queries started working as expected. Meaning, WHERE clause affected both measure groups: parent and child.
It may be that I am reading too closely into the wording you chose in your description, but you may want to clarify what you mean by filters. Technically the WHERE clause isn't a filter but instead identifies the slicer axis for the resulting data set. If you mean FILTER, then you may want to look into the MDX function named FILTER which you can apply to a set expression.
What you may try is rearranging your MDX query to define BOTH Axis - ROWS and COLUMNS.
SELECT
{
[Measures].[ParentCount],[Measures].[ChildCount]
} ON COLUMNS,
{
[SomeDimension].&[Foo]
} ON ROWS
FROM [Cube]
WHERE ([Time].[Month].&[2011-06-01T00:00:00])
Related
What is best practise when a parent & child table both FK to the same table?
Parent > Child(ren)
CommonAttributes: Sex, Age, Height, Weight
Is it better to directly reference the common table:
CommonAttributes > Parent(s) > Child(ren)
&
CommonAttributes > Child(ren)
Or use a reference table:
RefTable: CommonAttributes_Id, Parent_Id(null), Child_Id(null)
I think the first method works OK (with regards to EF) but it is a bit of a circular reference. Is it better to use a reference table to define the constraints?
There are several approaches to this and the one you need depends on your business needs.
First, can a child record have more than one parent? For instance you might be modelling an organizational structure where an employee can have two supervisors. If this is true, then you have a one to many relationship and need a separate table for this model to work.
If you are guaranteed to have only one parent per child (but each parent might have a parent (building a hierarchy), then you can model this is one table. The table structure would include the Primary key, say UserID and then a nullable column for the parent such as ParentUserID. Then you can create the foreign key to the field in the same table.
ALTER TABLE dbo.Mytable ADD CONSTRAINT FK_Mytable _UserPArent FOREIGN KEY (ParentUserD) REFERENCESdbo.Mytable (UserID)
If you want to build a hierarchy in a query, you then use a recursive CTE to get it. See example here:
https://msdn.microsoft.com/en-us/library/ms186243.aspx
Another time you might want to build a separate table for the child parent relationship is if only a small portion of teh records in the main table would have parent child relationships. For instance suppose you had a people table that stored, sales reps and customers. Only sales reps would have a parent child relationship. So you would want a separate SalesRepHierarchy table to store it which woudl make querying more straightforward.
While in general you woudl want to create hierarchies in a recursive CTE, there are special cases when it might be faster to pre calculate the hierarchies. This is true if the hierarchy is frequently queried, the CTE performance is slow and you have control over how the hierarchy is built (preferably through an import of data only) and if it changes fairly rarely (you would not want to be rebuilding the hierarchy every minute, but a once a day import can be accommodated. This can greatly speed up and simply querying for the whole hierarchy, but is not recommended if the parent child relationships are created and changed constantly through the application.
I'm new to that topic. I've got a database with a flat fact table, which contain data like date, product group, product subgroup, product actual name, and some calculations/statistics. All I need to do is create a report using olap cube. I have got two ideas how to create that, but dont know which draft is better (if even correct). The original DAILY_REPORT... table has not a primary key. Its just a data table. In first concept I have created every table (which will be as a dimension) with a ID, and connected the product->family of product->project->building in a hierarchy. Another concept is without all ID's and hierarchy. Relation created automatically based on names. Can somebody explain me in which direction I should tend...?
First idea:
http://imgur.com/iKNfAXF
Second:
http://imgur.com/IZjW1W6
Thanks in advance!
You can follow these steps to create your cube:
Create a separate view for each of the dimensions you want to have. Group similar type of data in one view, for e.g. Product Name, Product Group, Product Sub-Group, etc.
Keep the data in your dimension view as DISTINCT data. for e.g. SELECT DISTINCT [Product Name], [Product Group], [Product Sub-Group] FROM TABLE
Keep an 'ID' column in each dimension view, for e.g. Product ID in Product view
Create a view for your fact. Include 'ID' column of each dimension in your Fact view. This will help you to create relationship on 'ID' column, which will be a lot faster than relationship created on top of names.
For creating hierarchies in dimension attributes, SSAS provide drag and drop functionality.
If you need more details let me know.
You could construct the dimensions you need by views that based on distinct queries (i.e. SELECT DISTINCT) from the source data. These can be used to populate the dimensions.
You can make a synthetic date dimension fairly easily.
Then you can create a DSV that joins the views back against the fact table to populate the measure group.
If you need to fake a primary key then you can use a view that annotates the fact table with a column generated from row_number() or some similar means. Note that this is not necessarily stable across runs, so you can't rely on it for incremental loads. However, it would work fine for complete refreshes.
SQL Query
select * from zchildren where zparent = 3586 OR zparent in (Select zid from zchildren where zparent = 3586)
I have tried few cases with $SUBQUERY but Still i am not getting any success. So how can i achieve this ?
Update
I have Table Name which is Children which has Parent which contains the ID of the same table ID , Its a Inverse Relationship now i want All the children which parent is '3586' and its all sub children
Update2
I am Attaching the screen shot
Now Few more points
Table Group has One-To-Many Relationship with Children
Table Children has Two Relationship
First which is Inverse to Group One-To-One
Second children relation which is Inverse to itself which is called Reflexive
Updated Question
Now suppose i have one Query i want to search from Children table where title is 'Medical' AND Parent is '3586'
Now This '3586' is parent id which is coming from Table Group And i can easily predicate this .
Problem
It Gives me children whose parent '3586' but i also want to search in the title of sub-children which are Reflexive of this parent ID , Means sub-children of children which came from parent '3586'.
I really need this solution. I can still update my question if any one is not clear in this question.
When tackling somewhat complicated Core Data issues, you really have to be a bit more accurate. Your code and your variable names are sloppy and wrought with mistakes.
In your SQL query you have an attribute parent (or "zparent"), but in the Core Data model it becomes an attribute rather than a relationship. (Were you perhaps thinking of modeling ids? That would indicate that you are still trapped in relational database thinking and have not fully grasped the concept of the object graph yet. Forget about ids and think in relationships instead.)
You need a reverse relationship to children, so this cannot be the same relationship. Calling the entity "Children" is confusing because 1) you are using the plural for a singular object and 2) you are calling both parent and children "Children". You also misspell "Children" as "Childran", potentially leading to all sorts of errors.
Instead, let me suggest the entity name Person. A person can have one or more parents (or is it only one?) and one or more children both of which are also of type Person, resulting in a many-to-many relationship:
Person - parents <<----------------->> children - Person
If a person can only have one parent it if of course a many-to-one relationship.
Person - parent <------------------->> children - Person
You can then fetch a Person with idNumber 3586 (notice that using id is perhaps also a bad idea as it is a reserved word in some contexts). You can then access that person's children very succinctly:
person.children
That's really all there is to it.
Dimension is made with collection of key column attributes so:
...
hierarchylevel2key = level2attribute + level1attribute
hierarchylevel1key = level1attribute
...
Hierarchy has many levels, so in the lowest levels of the hierarchy, the key combinations are quite complex:
[Dim].[Hierarchy].[level1].&[level2]&[level3]&[level4]&[level5]&[level6]&[level7]
Now if i want to make a generic named set for level5 members, it's in MDX:
[Dimension].[Hierarchy].[level5].members.item(2)
and it returns the second member of the level5, but because the hierarchy is ragged (?) sometimes this item(2) does not exist.
.
Do i have to make gazillion of different named sets and manually have to pick the right existing items for the sets?
Or alternatively have i made mistake building the dimension hierarchy this way ?
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