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
Related
I'm trying to create a small company database as a personal learning experience in PostgreSQL.
I'm trying to follow Derek Banas tutorial (which is really helpful) but there is something different how my products are processed.
So far I've made these tables as shown in the image Table list
In the components table I have a row 'where_used' where I wanted to put an reference INT to the product where it is used.
But as you can see, some components are used in multiple products. And I can only store one value?
So my question is:
Can someone point me in the right direction on how to get this working?
I tried googling for a solution,
But as I'm such a noob I do not know how to get the right keywords for the search...
In data modeling this technic of having multiple sub entities from a super entity is called Inheritage...
As an exemple, you can have a table that is called "Vehicle" and some child tables that are called "Planes", "Boats", "Car".
The main table (Vehicle) will have shared properties
The "Plane" table will have some properties specific to planes and so on...
Of course the Primary KEY of vehicle will be shared in an exclusive mode betwwen "Planes", "Boats" and "Cars"...
From a child point of view, the tables will have a PRIMARY KEY that is also a FOREIGN KEY.
So in your case you have a table 'COMPONENTS' that is linked to the table 'PRODUCTS'
You want to have a column in your table 'COMPONENTS' that you'll call 'where_used' that say if the component is used in x or y product.
There is different ways of doing it but this is what I would do :
Basically, you'll need 3 tables :
The first one is "COMPONENT" which store unique component values
The second one is "PRODUCT" which store every unique products
The third one is "COMPOSITION" (or whatever name you like) which is the associated table between "COMPONENT" and "PRODUCT" which will look like this :
COMPONENT_ID
PRODUCT_ID
1
1
1
2
2
3
2
1
I'm working on a project in ASP.NET MVC 5, with ADO.NET EF to generate data from the SQL server. I have several one-to-many relationships in the database. When I fetch data and project it to a local variable, e.g. var query = model.listFromDbChildTable.ToList(); where model.listFromDbChildTable is just entities loaded from the db. This is the lowest table in the relationship hierarchy.
So the thing is, and I am not sure why, every time I go to "locals" in VS, in debug mode, I can go deeper and deeper into my relations, for example, I am looking at a child table (department), and when I go to this child in locals, I see child has a relation with parent (above it), s I go to parent table, (I believe this is normal,) but when I'm at parent (table), again I can go to child table from there, and I am not going up one step back in the hierarchy, but so to say deeper, like a stair down all the time. So I go again to child, and child can go to parent again, every time with the same element. And I can redo this process many times?
So what is going on? Are my relations wrong or is this some normal procedure with locals in VS?
The following image shows two tables that participate in one-to-many relationship. The Course table is the dependent table because it contains the DepartmentID column that links it to the Department table.
Basically any link between two entities can be explored(Table in SQL ,class in EF)
In SQL you refer just a column in child table as key whereas in entity a property is create which has type of a class .
Like in below example, Course will have property name "Department" of type "Department" class as it depends on it (also a DepartmentId property).
you can read more in detail here on msdn..and Don't worry moving from SQL to Entity framework does give you small suprises :) .Hope it helps.
Parent Child Entity MSDN
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 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])
I am planning on using a recursive table in my data model so that I can support an undetermined number of children that can live under a parent. My example is a Table of Contents where I don't know how deep my subsections will be under a chapter.
The issue I am stumbling over is what techniques do folks use to populate there DB once they have defined a recursive table? By that I mean if I have a list of items that refer to a chapter -> Section -> Subsection...when I load the Chapter, Section, and Subsection into the model I need to identity the lowest level of the hierarchy and assign that value to the Item I am loading (Foreign Key - I would assume) so that I can always get all of the info about that item.
So for example:
Item: 2A-GHI: Chapter: 2 Section: A SubSection: GHI
If I have my data loaded like
ID|TOCID|TOC_VALUE|PARENT_ID
1|Chapter|2|-1
2|Section|A|1
3|SubSection|GHI|2
How do i tie the item to GHI so that I can set the FK to the Recursive Table for that Item?
Do you use all three values as a Key and set that as another column in the table so that on load you can identity the lowest level?
Like So:
ID|TOCID|TOC_VALUE|PARENT_ID|Key
1|Chapter|2|-1|2
2|Section|A|1|2_A
3|SubSection|GHI|2|2_A_GHI
I can load the recursive table and I am using a CTE to recurse the data, but I am not sure what the best method is to load the recursive data and tie that data into the model so that my item has a FK to the Table of Contents data.
You need a column for the row's parent ID.
ID|TOCID|TOC_VALUE|parent
1|Chapter|2|0
2|Section|A|1
3|SubSection|GHI|2
a parentID of 0 or null means it's a root (chapter) node