Draw relation lines to identify what an entity does. Draw relation lines between a hotel guest, reservation, vehicle, and room. Define their relationship to each other.
There are four kinds of relationship types available in the logical data model for establishing associations between entities:
•Identifying, which is a type of parent/child relationship
•Non-identifying, which is a type of parent/child relationship
•Super-sub type
•Non-specific
Identifying relationships
An identifying relation indicates that the existence of the child entity is completely dependent on the parent entity. Therefore, the primary key of the parent entity is part of the primary key of the child entity. Identifying relations are, by definition, mandatory. That is, an instance of the child entity cannot exist without an instance of the parent entity with the same primary key value. A child entity in an identifying relationship does not have to have its own primary key.
Example: the relationship between the entity Employee and the entity Dependent in our company’s health plan is identifying. A dependent must "belong" to an employee, because you do not insure dependents of non-employees.
Non-identifying relationship
A non-identifying relation indicates that the child entity does not rely on the parent entity for its existence. The child entity must, therefore, have its own unique primary key. The parent can be specified as mandatory or optional in a non-identifying relationship.
The foreign keys that are propagated through a non-identifying relation line in the entity relation model are not primary key attributes in the child entity.
Note If the parent and the child entities have an attribute in common (that is, the same name and the same underlying data element), and that attribute in both the parent and child entities is primary key, the foreign key in the child entity will be displayed in the model as [PK][FK].
Non-specific relationship
The non-specific relationship line is used during conceptual modeling, when you just want to relate two entities, but don't want to spend time figuring out the exact details of the relationship.
Super-sub relationship
The super-sub relationship indicates that one entity can have types. For example, an employee might be in a union. One type of employee is "union"; another type is "non-union"; and a third might be "management." The super-sub relationship line models those relationships. In our Hotel system, one might want to model a Customer divided into "Business Traveler" and "Vacationer," or into "Preferred" and "Regular." Each sub-entity inherits attributes from Customer, and each has specific attributes of its own.
The super-sub relationship can be complete or incomplete. That is, the sub-entities in the model can be all the possible types or just a sample of types. In standard ERD modeling, there is no way to differentiate between a complete and incomplete relationship; in IDEF1X modeling, the line is drawn differently in order to differentiate.
Names of relationships
System Architect does not require names on relation lines, but it is good practice to name the relation line to indicate the relationship being represented. The relationship can generally be read as a sentence:
•The Guest owns a Vehicle.
•A Room belongs to a Guest.
•A Reservation belongs to a Guest.
Draw relationship lines
Draw a relationship line between Guest and Vehicle:
1 In the Tutorial encyclopedia, from the Draw toolbar, choose the Identifying Relation line.
2 Click the Guest entity. A + mark appears, indicating that a line is attached to the entity.
3 Click the Vehicle entity. A + mark appears, indicating that the line is attached to the entity. Release the mouse button to attach the line.
4 A cursor appears on the relation line, specifying a name. Name the relation line owns and click.
Notice that the Vehicle entity now has a double line around it: it has been transformed to a Weak Entity to reflect the fact that a Guest record must exist for a Vehicle to exist.
Note If you select Tools > Preferences, and toggle on the Auto-Define choice, the Relationship Editor will appear automatically each time you put a relation line on a diagram. By default, this choice is toggled off; in this exercise you will first draw the relationship lines between entities, and then go back and define them.
5 You should still be in draw mode -- your cursor should still resemble a pen. Using the procedure for drawing lines described in steps 2 and 3 above, draw a relationship between Room and Guest. Name the line belongs to.
Notice that the Guest entity now has a double line around it - it has been transformed to a Weak Entity to reflect the fact that a Room must exist for a Guest to exist.
6 You should still be in draw mode. Using the procedure for drawing lines described in steps 2 and 3 above, draw a line between Reservation and Guest and name it makes.
Note System Architect supports a number of types of relationship lines. To see the variety, select from the menu bar Format > Diagram Format > Notation.
Relationship Line Types
System Architect supports a number of types of relationship lines. To see the variety, select Format > Diagram Format > Notation.
The most widely-used notations in data modeling are Crow's feet and IDEF1X. Whichever notation you choose will be used for all relation lines in all ERDs in the encyclopedia. All the examples in this tutorial use Crow's feet.
Crow's Feet and IDEF1X Relationship Lines
One-to-Many (one person owns many houses):
One-to-One (one person owns one house):
One-to-One or Many (one person owns one or more houses):
One-to-Zero or One (one person owns no houses or one house):
One-to-zero, one or many:
Zero-to-many:
Lesson checkpoint
In this lesson, you learned:
•the four kinds of relationship types between entities
