My source data set contains a table of records, with columns "code", "name" and "parent".
The "code" column contains the unique record key, the "name" contains a text value, and "parent" holds a foreign key pointing back to the "code" column. This table structure is used to allow records to be structured as a hierarchy, where each record can have at most a single parent.
How do I model this in the LDM for GoodData? Currently, I have captured the "code" as a connection point, and "name" as a label, but I'm uncertain what to do with the "parent". Attempting to create a circular connection produces an error message "a cycle has been detected" in the CloudConnect problems window.
You have to split it into two datasets "User" and "Parent". Both datasets have same columns "code" (connection point) and "name" (this may be attribute or label) and there is a reference:
Or you can join parent name in the ETL and you create just one datasets wit columns "code","name","parent name"
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 tried setting up a relationship although I don't know if this is how I'm meant to do it:
Category column settings:
Description column settings:
Linked to the table that contains different type of furniture, "Furniture":
Furniture design:
So what I want to do, is make it so that when you choose a furniture category, you can only choose from furniture descriptions of that category:
I do not think this can be done using only tables — you'll have to create a form that will limit the selection in the descriptions listbox based on the category.
Also, there are a number of problems with your data structure:
I imagine multiple Furnitures can have the same CATEGORY. This means that CATEGORY cannot be the primary key -- a uniquely identifying piece of data -- for Furniture. I would suggest adding a Long number column called FurnitureID. If you make this an Autonumber column, every new record will get a new number by default; otherwise you'll have to insert the number by hand.
Once you have such a column, you should have a corresponding column — AKA the foreign key column — in Stock of the same type (or Long if the FurnitureID is an Autonumber). These two columns should be related in the Relationships window. The relationship means that every1 Stock record must have a related Furniture record with the same data in both records.
Once you've done that, there is no need to repeat the CATEGORY and DESCRIPTION fields between the Stock and Furniture tables. This means no duplicate data, and no potential conflicts.
1. Depending on how the column is defined, it might be possible to have no data in the foreign key column in the Stock record; but this is relatively uncommon
Here goes with as much detail and clarity as I can give you...
Goal: Append portions of "Validated" table to several existing tables, all related by "PropertyID" field
Problem: Even a very basic append query fails to work. I created a query in design view to append [PropertyName] from the Validated table to the GeneralProperty table. Both are text field, same length, not required, allowed zero length, not indexed. When I run the query nothing happens. No error message, no result. The GeneralProperty table remains empty. I went to SQL view and pressed run on the following query and still got nothing:
INSERT INTO GeneralProperty ( PropertyName )
SELECT [Import2-Validated].PropertyName
FROM [Import2-Validated];
Additional Info:
Primary Key is "PropertyID" and it is an autonumbered field.
GeneralProperty table contains the above Primary key
Four other tables contain "PropertyID", joined by a relationship
Relationship enforces referential integrity, and cascades updates+deletes
Append query does work to append text from the "Validated" table to tables other than GeneralProperty, so long as I do not try to append PropertyID in the query.
Database is working as expected for manual entry through a form. All relationships and autonumbering of the primary key work as expected.
Using MS Access 2010
Edits
Result of SELECT [Import2-Validated].PropertyName is a popup to enter parameter value
Haven't specified DoCmd.SetWarnings=False in code anywhere
I have a person dimension with a email alias field in it. This field is unique and there is also an instance ID in my dimension table. I am wondering if there is any performance difference between creating an attribute with a key referencing the instance id, and name referencing the alias vs. creating a hidden attribute in my dimension called "instance ID" and using that to define my dimension relationships.
Won't the cube just use the instance ID in processing within both cases?
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