7.1 Relationship Types
Following is a brief summary of the extended Chen E-R Relationships.
Note that the Abstraction relationship is not implemented in the Logical Modeler. However, Abstractions can be created to group objects together. Refer to 8. Abstractions.
One entity is said to be the Parent of another if the data of the Child entity belongs to (is contained within) the Parent. Parent/Child relationships can be identified by asking:
- Is the entity's identifier unique?
- Can the entity exist on its own?
If the related entity's identifying element is unique, that is, you can identify an occurrence in the entity solely by its identifying element, then the entity probably has no parents. If you require other information to identify an occurrence, that is, another entity must exist before it can exist, then the entity probably has a parent.
For example, an Ordered Product cannot exist on its own. The Ordered Product must have a parent, Order, before it can exist.
The identifying elements of the Parent entity are inherited by the Child entity. These elements are often called Parent Keys or Foreign Keys.
Also see Parent/Child Rules.
One entity is said to be joined (or to refer) to another if a data (that is, non-key) element or group of elements from the first entity can be used to access an occurrence of the second.
The Join relationship differs from the Parent/Child relationship in that the element(s) used to access the referenced entity are not necessary to identify the primary (or referencing) entity. However, they are still inherited to become Foreign Keys.
For example, an Order is placed by a Customer. The Order is identified by its Order Number. It will look up a Customer Code in the Customer entity.
The Join relationship is further classified as a Mandatory Join or an Optional Join. The Mandatory Join is described as a must refer to relationship. The Optional Join is described as a may refer to relationship.
Also see Join Rules.
The Include relationship allows elements from one entity to exist in many different entities. However, unlike a Parent/Child and Join relationships, no foreign keys result. The elements become part of the entity.
For example, a conceptual entity called Address is created with attributes of Street, State, City, Country and Post Code. This entity has no identifying element. The Address entity could be included into a Customer entity or Supplier entity. The Address elements will become part of the Customer file and Supplier file instead of being in a separate Address file.
Also see Include Rules.
This type of relationship is used in situations where elements within an entity are dependent on the value of another element. For example, a Product can either be manufactured or sourced from a third party supplier. If the product is manufactured, a drawing number may be required. If the product is sourced from a supplier, a supplier code is required. Rather than create a single Product entity with all elements for manufactured and supplied products, three entities are created. Product will have variations called Manufactured Product and Supplied Product. Storing all the elements in a single Product entity would result in a sparsely populated database, i.e. many fields will be unused.
Once a Product has been created and designated as Manufactured, the same product cannot be designated as Supplied.
Note that the database, once built, will have no awareness of how variations of the original entity are accessed. An element should be created in the original entity to hold a value which can be used in determining which database file variant information should be retrieved from in your application.
Also see Variation Rules.