I have following table:
CatId CatName parent CatId
1 Category 1 NULL
2 Category 2 NULL
3 SubCat 1 1
4 SubSubCat 1 3
5 SSSubCat 1 4
In Analysis Service I want to create Hierarchy in dimension such that it allows me to drill down till N Level.. Currently I am able to do it only 2 levels.. Category and Sub Category.. but I would like to go till N level if N level is not possible atleast till 4-5 levels.
The type of Hierarchy you appear to be attempting is called a Parent-Child Dimension. SSAS will use recursive joins to "explode" your data into a tree shape.
But your table as you describe it is a little confusing. So I am offering a solution that requires you to rethink your table a little. A classic Parent-Child will have for each node (record) in the hierarchy:
A key (ID) for the node
The literal text (Name) for the node
A foreign key called the parent
In your example, the column labelled "parent" appears to be superfluous. The last column in your example (called "CatID") is what the Parent of the dimension usually looks like. If you consider that each record in the table is a "child", the parent of the child acts as a pointer back to some record that owns or contains that record. At the highest level in the hierarchy, records will have no Parent so the Parent column is set to NULL.
Rename the second "CatID" to "parent" and remove or rename the original column called "Parent" (you don't need it). If you tweak your table as I suggest, you should check that the highest level is correct by running the following query:
SELECT CatID, CatName, parent FROM mytable WHERE (parent IS NULL)
Then to get the next level down run the following query:
SELECT HighestLevel.CatID, HighestLevel.CatName, HighestLevel.parent, Level2.CatID AS Level2ID, Level2.CatName AS Level2Name
FROM mytable AS HighestLevel
INNER JOIN mytable AS Level2 ON HighestLevel.CatID = Level2.parent
WHERE (HighestLevel.parent IS NULL)
Note the recursive INNER JOIN. Run at least one more query to view another level down to verify that the keys are "expanding" the way you expect:
SELECT HighestLevel.CatID, HighestLevel.CatName, HighestLevel.parent, Level2.CatID AS Level2ID, Level2.CatName AS Level2Name, Level3.CatID AS Level3ID, Level3.CatName AS Level3Name
FROM mytable AS HighestLevel
INNER JOIN mytable AS Level2 ON HighestLevel.CatID = Level2.parent
INNER JOIN mytable AS Level3 ON Level2.CatID = Level3.parent
WHERE (HighestLevel.parent IS NULL)
You could keep adding levels as necessary to convince yourself that the data is correct. This is essentially what SSAS is doing when it builds a Parent-Child hierarchy.
Finally, you'll add this table to the DSV and create a Parent-Child Dimension. That's a bit more complicated and this looks like a great starter article. SSAS will keep adding levels as necessary until it runs out of data.
In AdventureWorks, the Employee dimension has an example of this. Assuming your category is on your fact table:
Set your ParentCatID to be a FK of CatID in the DSV
Reference your Parent attribute as the Parent Attribute type in the Dimension Hierarcy manager
Add the attribute into your hierarchy
The nested levels should be able to be browsed in your Category Hierarchy.
Related
I'm using MS SqlServer 2008. And I have a table 'Users'. This table has the key field ID of bigint. And also a field Parents of varchar which encodes all chain of user's parent IDs.
For example:
User table:
ID | Parents
1 | null
2 | ..
3 | ..
4 | 3,2,1
Here user 1 has no parents and user 4 has a chain of parents 3->2->1. I created a function which parses the user's Parents field and returns result table with user IDs of bigint.
Now I need a query which will select and join IDs of some requested users and theirs parents (order of users and theirs parents is not important). I'm not an SQL expert so all I could come up with is the following:
WITH CTE AS(
SELECT
ID,
Parents
FROM
[Users]
WHERE
(
[Users].Name = 'John'
)
UNION ALL
SELECT
[Users].Id,
[Users].Parents
FROM [Users], CTE
WHERE
(
[Users].ID in (SELECT * FROM GetUserParents(CTE.ID, CTE.Parents) )
))
SELECT * FROM CTE
And basically it works. But performance of this query is very poor. I believe WHERE .. IN .. expression here is a bottle neck. As I understand - instead of just joining the first subquery of CTE (ID's of found users) with results of GetUserParents (ID's of user parents) it has to enumerate all users in the Users table and check whether the each of them is a part of the function's result (and judging on execution plan - Sql Server does distinct order of the result to improve performance of WHERE .. IN .. statement - which is logical by itself but in general is not required for my goal. But this distinct order takes 70% of execution time of the query). So I wonder how this query could be improved or perhaps somebody could suggest some another approach to solve this problem at all?
Thanks for any help!
The recursive query in the question looks redundant since you already form the list of IDs needed in GetUserParents. Maybe change this into SELECT from Users and GetUserParents() with WHERE/JOIN.
select Users.*
from Users join
(select ParentId
from (SELECT * FROM Users where Users.Name='John') as U
cross apply [GetDocumentParents](U.ID, U.Family, U.Parents))
as gup
on Users.ID = gup.ParentId
Since GetDocumentParents expects scalars and select... where produces a table, we need to apply the function to each row of the table (even if we "know" there's only one). That's what apply does.
I used indents to emphasize the conceptual parts of the query. (select...) as gup is the entity Users is join'd with; (select...) as U cross apply fn() is the argument to FROM.
The key knowledge to understanding this query is to know how the cross apply works:
it's a part of a FROM clause (quite unexpectedly; so the syntax is at FROM (Transact-SQL))
it transforms the table expression left of it, and the result becomes the argument for the FROM (i emphasized this with indent)
The transformation is: for each row, it
runs a table expression right of it (in this case, a call of a table-valued function), using this row
adds to the result set the columns from the row, followed by the columns from the call. (In our case, the table returned from the function has a single column named ParentId)
So, if the call returns multiple rows, the added records will be the same row from the table appended with each row from the function.
This is a cross apply so rows will only be added if the function returns anything. If this was the other flavor, outer apply, a single row would be added anyway, followed by a NULL in the function's column if it returned nothing.
This "parsing" thing violates even the 1NF. Make Parents field contain only the immediate parent (preferably, a foreign key), then an entire subtree can be retrieved with a recursive query.
I have a very simple database. It contains 3 tables. The first is the primary input table where values go in. The 2nd and 3rd are there purely for translating values to names for a view. When I view the rows in table 1, I can see that column businessUnit contains valid values in all rows. When I add the Business_Units table (The 3rd table in this DB), all but 2 rows go away and despite the businessUnit value both being 1 in the 1st table, the view gives them different names.
I created a DB diagram and uploaded a screenshot to imgur. Link: http://imgur.com/jXF7L1R
I only have 2 relationships in the table. One from equipType on New_Equipment_User to id in Equipment_Type and one from businessUnit in New_Equipment_User to id in Business_Units. The weird thing is that the Equipment Type works perfectly, yet when I replicate the table, relationship and view information exactly, it doesn't work. Instead of 6 rows appearing, there are only 2 which share the same value in businessUnit, but gives 2 different names for it.
In case it matters, here is my view Query:
SELECT dbo.New_Equipment_User.id, dbo.Equipment_Type.name AS equipType, dbo.New_Equipment_User.jobNumber, dbo.New_Equipment_User.costCode,
dbo.New_Equipment_User.reason, dbo.New_Equipment_User.mobile, dbo.New_Equipment_User.mobileQty, dbo.New_Equipment_User.mobileComment,
dbo.New_Equipment_User.laptop, dbo.New_Equipment_User.laptopQty, dbo.New_Equipment_User.laptopComment, dbo.New_Equipment_User.desktop,
dbo.New_Equipment_User.desktopQty, dbo.New_Equipment_User.desktopComment, dbo.New_Equipment_User.modem, dbo.New_Equipment_User.modemQty,
dbo.New_Equipment_User.modemComment, dbo.New_Equipment_User.printer, dbo.New_Equipment_User.printerQty, dbo.New_Equipment_User.printerComment,
dbo.New_Equipment_User.camera, dbo.New_Equipment_User.cameraQty, dbo.New_Equipment_User.cameraComment, dbo.New_Equipment_User.dateRequired,
dbo.New_Equipment_User.requestedBy, dbo.New_Equipment_User.dateRequested, dbo.New_Equipment_User.approvalStatus,
dbo.Business_Units.name AS businessUnit
FROM dbo.New_Equipment_User
JOIN dbo.Equipment_Type ON dbo.New_Equipment_User.equipType = dbo.Equipment_Type.id
JOIN dbo.Business_Units ON dbo.New_Equipment_User.id = dbo.Business_Units.id
WHERE (dbo.New_Equipment_User.approvalStatus = '0')
And here is an image of the view since it is easier to read: http://imgur.com/pZ97ehQ
Is anyone able to assist with why this might be happening?
Try using a LEFT JOIN
SELECT ...
FROM dbo.New_Equipment_User
JOIN dbo.Equipment_Type ON dbo.New_Equipment_User.equipType = dbo.Equipment_Type.id
LEFT JOIN dbo.Business_Units ON dbo.New_Equipment_User.id = dbo.Business_Units.id
This will ensure that all dbo.New_Equipment_User and all dbo.Equipment_Type is present
I'm trying to implement a feature whereby, apart from all the reports that I have in my system, I will allow the end user to create simple reports. (not overly complex reports that involves slicing and dicing across multiple tables with lots of logic)
The user will be able to:
1) Select a base table from a list of allowable tables (e.g., Customers)
2) Select multiple sub tables (e.g., Address table, with AddressId as the field to link Customers to Address)
3) Select the fields from the tables
4) Have basic sorting
Here's the database schema I have current, and I'm quite certain it's far from perfect, so I'm wondering what else I can improve on
AllowableTables table
This table will contain the list of tables that the user can create their custom reports against.
Id Table
----------------------------------
1 Customers
2 Address
3 Orders
4 Products
ReportTemplates table
Id Name MainTable
------------------------------------------------------------------
1 Customer Report #2 Customers
2 Customer Report #3 Customers
ReportTemplateSettings table
Id TemplateId TableName FieldName ColumnHeader ColumnWidth Sequence
-------------------------------------------------------------------------------
1 1 Customer Id Customer S/N 100 1
2 1 Customer Name Full Name 100 2
3 1 Address Address1 Address 1 100 3
I know this isn't complete, but this is what I've come up with so far. Does anyone have any links to a reference design, or have any inputs as to how I can improve this?
This needs a lot of work even though it’s relatively simple task. Here are several other columns you might want to include as well as some other details to take care of.
Store table name along with schema name or store schema name in additional column, add column for sorting and sort order
Create additional table to store child tables that will be used in the report (report id, schema name, table name, column in child table used to join tables, column in parent table used to join tables, join operator (may not be needed if it always =)
Create additional table that will store column names (report id, schema name, table name, column name, display as)
There are probably several more things that will come up after you complete this but hopefully this will get you in the right direction.
I have 3 tables, a parent table and 2 child tables. Lets say Mother_c is the parent. Then Child_c and Pet_c are the 2 child tables that have master-detail relationship pointer to Mother_c.
I have the Id of one row from Child_c, I want to retrieve all the rows from Pet_c that correspond to the Mother_c of that single Child_c row.
I'm wondering if this is possible in one SOQL query?
Yes, this is totally possible with semi-join SOQL. I tested this out with the standard CRM objects like this:
SELECT Id,
(SELECT Id FROM Cases)
FROM Account
WHERE Id IN (SELECT AccountId
FROM Contact
WHERE Id = '0036000000qCwp9'
)
To walk you through this, with a given Contact id, you first find the parent Account, and then traverse back down to the child Cases. In your example with custom objects, it would be very similar, but would use the __r custom relationships names instead:
SELECT Id,
(SELECT Id FROM Pet__r)
FROM Mother__c
WHERE Id IN (SELECT Mother__c
FROM Child__c
WHERE Id = '003a000000qCwp9'
)
Sorry if the title is poorly descriptive, but I can't do better right now =(
So, I have this master-detail scheme, with the detail being a tree structure (one to many self relation) with n levels (on SQLServer 2005)
I need to copy a detail structure from one master to the another using a stored procedure, by passing the source master id and the target master id as parameters (the target is new, so it doesn't has details).
I'm having troubles, and asking for your kind help in finding a way to keep track of parent id's and inserting the children without using cursors or nasty things like that...
This is a sample model, of course, and what I'm trying to do is to copy the detail structure from one master to other. In fact, I'm creating a new master using an existing one as template.
If I understand the problem, this might be what you want:
INSERT dbo.Master VALUES (#NewMaster_ID, #NewDescription)
INSERT dbo.Detail (parent_id, master_id, [name])
SELECT detail_ID, #NewMaster_ID, [name]
FROM dbo.Detail
WHERE master_id = #OldMaster_ID
UPDATE NewChild
SET parent_id = NewParent.detail_id
FROM dbo.Detail NewChild
JOIN dbo.Detail OldChild
ON NewChild.parent_id = OldChild.detail_id
JOIN dbo.Detail NewParent
ON NewParent.parent_id = OldChild.parent_ID
WHERE NewChild.master_id = #NewMaster_ID
AND NewParent.master_id = #NewMaster_ID
AND OldChild.master_id = #OldMaster_ID
The trick is to use the old detail_id as the new parent_id in the initial insert. Then join back to the old set of rows using this relationship, and update the new parent_id values.
I assumed that detail_id is an IDENTITY value. If you assign them yourself, you'll need to provide details, but there's a similar solution.
you'll have to provide create table and insert into statements for little sample data.
and expected results based on this sample data.