Derive a one-to-one conceptual relationship
Let's extend the example of Derive a one-to-many conceptual relationship with an Invoice entity.
Example: Order and Invoice
Each invoice is issued for exactly one order (cardinality 1 on the Order side), and an order has at most one invoice (cardinality 0..1 on the Invoice side, assuming no backorder capability in this example):
In a one-to-one relationship, the foreign key attributes are created on the optional side. Hackolade Studio adds a required Order_id column to the Invoice table, and also creates a unique key on this column, so that the same order cannot be invoiced twice. When there are several foreign key columns, the unique key is created on all of them together. No unique key is added when these columns already form the complete primary key of the Invoice table.
Same cardinality on both sides
When both sides have the same cardinality (1 and 1, or 0..1 and 0..1), both choices are valid from a modeling point of view. Hackolade Studio then applies a convention: the foreign key attributes are created in the second entity listed in the Linked entities section of the relationship's properties.
Tip
To get the foreign key attributes in the other entity, swap the two entities in the Linked entities section of the relationship's properties before deriving, with the arrows described in Direction as a semantic choice.
Summary: cardinality impact on placement of foreign key
The child entity and the parent entity are determined according to the logic in this table:
| Relationship | Child entity | Parent entity |
|---|---|---|
| One-to-many | The entity on the "many" side (0..n or 1..n) | The entity on the "one" side (1 or 0..1) |
| One-to-zero-to-one, 1 on one side and 0..1 on the other | The entity with cardinality 0..1 | The entity with cardinality 1 |
| One-to-one, same cardinality on both sides | The second entity in the Linked entities list | The first entity in the Linked entities list |