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?
Related
I am using AGE to create a graph database, and I want to ensure that all nodes in my database are unique. I want to avoid having multiple nodes with the same properties and labels in my graph.
For example, if I have a node with label Person and properties name and age, I want to ensure that there is only one node with the label Person and the same name and age properties. If a second node is created with the same label and properties, I want to prevent it from being added to the database, or find a way to merge the two nodes into one.
You can ensure uniqueness of nodes in your graph database by using a constraint on the combination of the node's label and properties. In AGE, you can add a constraint to enforce the uniqueness of specific properties by using a unique constraint.
For example, to enforce uniqueness of nodes with label "Person" and properties "name" and "age", you can run the following query:
CREATE CONSTRAINT ON (p:Person) ASSERT (p.name, p.age) IS UNIQUE;
When a new node with the same label and properties is added to the database, AGE will check if the combination of the "name" and "age" properties is unique. If not, it will raise an error and the node will not be added to the database.
If you want to merge two nodes with the same label and properties, you can delete one of the nodes and add a relationship from its connected nodes to the remaining node.
I have a misunderstood problem when trying to work with SSAS in creating and configuring Dimension. The problem is: My dimension named Author have three attributes (AuthorKey, AuthorID, AuthorState), which AuthorKey is the primary key of my dimension.
With Visual studio 2013, I have created a user-hierarchy like:
Hierarchy name: AuthorByState
+ AuthorState
+ AuthorKey
- AuthorID
- AuthorState
When I switched to Attribute Relationship tab, i have seen an auto-generated relationship like:
AuthorKey(AuthorID) --> AuthorState
My questions is: I understand that SSAS automatically relates every attribute in a dimension to the dimension key, but why does the AuthorID attribute is "inside" the AuthorKey attribute instead of "outside" as normally like AuthorState? What it means the attribute relationship?
Thanks for any explanation and sorry for my bad English!
When you build a user-defined hierarchy (the thing you called AuthorsByState) then that causes the Attribute Relationship tab diagram to render differently. Basically any attribute that appears in a user-defined hierarchy has it's own bubble. If you were to build a second user-defined hierarchy with AuthorId in it, then AuthorId would have it's own bubble in the Attribute Relationships tab diagram.
The Problem
Attributes in the hierarchy are not being defined correctly.
Symptoms
When you define a hierarchy, attributes which are not related are being dragged in
Solution
If you dimension has one key (the "Natural Key" - the key for business use only) - then that should be defined as your key (It clearly says that "Author" is your key, and I don't know what that field stand for).
If your dimension has two keys, a natural Key and surrogate key. The Natural key is the key with the business meaning (as every author has an id) and the surrogate key is the key that we allocate (an identity int or whatever).
Put the Surrogate key in the dimension. Define it as a key, and choose the "visible attribute" as the Name/Natural key. Once you do that the Hierarchy wouldn't drag unnecessary attribute inside that section.
A comment: if Author Key is your substitute Key and Author Id is your natural key you can hide Author Key; make it display Author Id instead in Properties->NameColumn
Please note the use of "date key" in the following post by Microsoft:
https://www.mssqltips.com/sqlservertip/3414/sql-server-analysis-services-attribute-relationships/
As without it the Hierarchy just wouldn't be set.
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
I have a class A and a class B that inherits from A. Class A has a certain attribute X. Class B adds another attribute Y. An instance of B is uniquely identified by its pair of attributes {X,Y}. So, {X,Y} is a candidate key for class B. Obviously this key doesn't exist at the class A level since attribute Y isn't there. I use a surrogate key for class A.
Now, I use Hibernate for the object-relational mapping. If I use the TABLE PER SUBCLASS inheritance strategy, I don't see a possibility for defining a UNIQUE constraint on multiple attributes that belong to different classes (and then in the DB, to different tables).
My question is how can I define a unique constraint for this candidate key using Hibernate and more generally in SQL? If it's not possible, what do you recommend?
Thanks
Here are two solutions:
Create a new table with one column which is its PK. This table should hold all the values which you want to make unique. Create foreign keys to this table which will ensure that the domain on the columns comes from the unique table.
Create triggers which raise an error if the condition is violated.
I'm attempting to design a schema for a consignment store's POS system. I have a master item's table and multiple entities that reference it as a foreign key and contain different attributes. The items table contains all of the information that is common to all items, regardless of its type. The entities that reference any given item offer a specific attribute for that given item type. For example, a "split" item needs an asking price, while a store item needs a cost price.
While this design technically works and enforces only one item in the items table, I'd like to be able to maintain that any given item is only referenced by ONE of these entities. The concern is that I don't want a "split" item to also me considered a "store" item accidently. Is there any way to enforce this through schema design?
The ERD is here: http://randywestergren.com/pos-erd.pdf
The tables in question are phppos_items, phppos_items_entity_split, phppos_items_entity_store, etc.
Thanks in advance!
It seems like you're determining whether or not a item is a "split" or a "store" type by which related row exists. Instead, how about adding a type field to the items table? It won't prevent the other related row from actually existing, but it will let you know definitively that it's an error.
Create a secondary table:
typed_items (poorly named)
{
PK: item_key - this points to the item
PK: int item_type_id - this type code specified which 'type' of item, ie: store, split
// optional, depending on your key design:
// 1...n FK:
// split_item_id,
// store_item_id,
// etc.., if you reference the items PK in the sub-item-type-detail tables, this
// isnt nessicary. if you are using a synthetic key on the sub-item-type-detail
// tables and no key relationship exists you can use this table as a linking table,
// otherwise its not nessicary
}
Since type items key and the type descriminator id are part of a primary key, you know that your model will not allow an item to belong to 2 different sub-item-type-detail tables.
If you want (paranoid) integrity you can now add a constraint on these type-detail tables that ensures the item's key paired with the constant type descriminator value for that type exists in this table.