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.
Related
I am creating a logical model on Oracle SQL, however am having a bit of trouble. When I add a relationship between two entities, I'd expect Oracle to add the PK of the parent entity to the child entity, as a foreign key.
But instead of adding the already existing attribute as a FK, Oracle keeps adding an additional attribute with the same name but with a '_1' at the end of the name (e.g. teacher_1 instead of using the already existing 'teacher' attribute)
Any ideas why this is the case?
When using the data modeler, we assume when you add a foreign key, you haven’t already created the ID column.
So we create that for you.
Here’s what that looks like.
I draw the relationship.
You don’t want that.
You want it to use USER.USER_ID instead.
Click on the Column, and toggle it to USER_ID.
When I click ‘Apply’ or ‘OK’ – the generated column goes away.
If you don’t like being asked, you can set the default action when deleting the FK in the preferences: ‘Delete FK columns strategy’
Tip: Draw from Parent to Child
When I go to draw a FK, I always go from child to parent…I think backwards for some reason.
I have a GraphCool model called Student which has a field called studentNumber. How can I prevent two (or more) different Student nodes with the same studentNumber? In SQL databases I was able to create a unique index to accomplish this.
The easiest way to do so is by enabling the "Unique" constraint for a certain field (studentNumber in your case for the Student model). You can enable constraints in the structure view when editing a model.
Note: Under the hood, this creates a unique index in the database just like you suggested.
I have
- Contact class with joined inheritance
- Counterpart class extending Contact
- Customer extending Counterpart
- field 'code' in Customer I would like to be unique
Why is CUBA studio does not allow me to tick the 'unique' checkbox for the 'code' field ?
Probably your entities implement the SoftDelete interface. It means that unique constraints must either include the DELETE_TS field or have a where condition with this field (depending on the database type).
In case of JOINED inheritance strategy the DELETE_TS field exists only in the root table, so the automatic creation of unique constraints is impossible for child entities.
You can create any constraints manually in the 30.create-db.sql script, but keep in mind that if the unique index does not consider the soft deletion mark, users will not be able to create a new record with the same CODE as in a deleted record.
I have two tables: ZDEPARTMENT01 and ZEMPLOY01.
ZDEPARTMENT01 has a foreign key DEPHEAD, whose data element is ZPERSONNEL_NO of domain ZPERSONNEL_NO ( NUMC, 10 ). ZEMPLOY01 has a primary key EMP_NUM, whose data element is ZEMP_NUM of domain ZEMP_NUM ( NUMC, 10 ).
ZDEPARTMENT01-DEPHEAD is the foreign key and ZEMPLOY01-EMP_NUM is the check key, and ZDEPARTMENT01-DEPHEAD domain ZPERSONNEL_NO has value table: ZEMPLOY01.
While setting the check table for ZDEPARTMENT01-DEPHEAD I got the error Check table ZEMPLOY01 has no key field with the domain ZPERSONNEL_NO of the field DEPHEAD
Even though both domains have the same datatype and length (but different domains) the system is unable to recognize the foreign key table and check table relationship.
The document says: The system attempts to assign the key fields of the check table to fields of the table with the same domain. Does it mean in addition to the datatype and the length, the domain names should be same between the foreign key table and the check table?
How to solve this?
Yes that's what it means. You have two Data Elements: ZEMP_NUM and ZPERSONNEL_NO. If you double-click on these, in your table, you will navigate to the data element definition. There you will see the Domain assigned to each. These should be the same, so make them the same.
Think about it this way:
Domains provide structural consistency for data that can appear in multiple places. You wouldn't have an employee id that's 10 digits in some places and 8 in others or it will cause 10-digit records to get truncated. Likewise, if you run out of digits and need to extend your employee id to 11 digits, you want to make sure it's changed everywhere, in every table where it's used. Domains let you do this. Domains also let you configure the default look up relationship (value table) or fixed values that can be selected (eg the Employee table).
Data Elements provide contextual relevance. You'll notice that in addition to supplying the domain of a data element, you can define the field labels and heading, and you can assign a custom search help. These allow you to display the field to the user in a way that is relevant to the current activity. In this case, you can label the Employee "Department Head", because it would be confusing to have a field meant to hold the ID of the department head and have it display as only "Employee". You could also add a search help that restricts the Employee list to only those flagged as "Managers".
As it already says in the message, you'll have to adjust your data elements to use the same domains:
The check table must have a key field to which the domain of the check
field is assigned.
(documentation)
I'm not entirely sure about this, but I believe the rationale behind this is that this will prevent you from changing one of the table field definitions without changing the other one at the same time.
I think your problem are the key fields definitions. The table 'ZEMPLOY01' has the key fields 'CARRIER' and 'EMPNUM' and if you want that the foreign key 'DEPHEAD' of table 'ZDEPARTMENT01' works then you have two options:
Change the key fields defined in table 'ZEMPLOY01'. Just set 'EMPNUM' as your only key field and then try to make the relation.
Add the field 'CARRIER' to table 'ZDEPARTMENT01' and then try to make the relation.
Please confirm.
Hope it helps.
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