ER Modeling ER Diagram ID-Dependent and Weak Entities Pg 1 ER Diagram ID-Dependent and Weak Entities Ray Lockwood Points: An ID-dependent entity is an entity whose identifier (key) includes the identifier of another entity. A weak entity is one whose existence depends on the presence of another entity. A strong entity is an entity that isn't weak. All ID-dependent entities are weak, but not all weak entities are ID-dependent. Terminology We might be blending our terminology a little here. These are terms that apply to the ER Model, to the Relational Model, and to the Database view of things: ER Model Relational Model Database Entity Relation Table Attribute Attribute Column Instance Tuple Row Identifier Key Key Relationships In the ER Diagram and the Relational Model Relationships in an ER diagram aren't implemented by foreign keys. They're made by drawing lines from one entity to another. Part of the transformation from an ER diagram to a database is adding foreign key columns to tables to implement the relationships. Another Look At Some Old Tables Here's our and tables: People mix up their terminology all the time. The ER Diagram is at a higher level of abstraction than the Relational Database. We don t have to worry about the mechanics of foreign keys when working with an ER Diagram. Num LastName FirstName DeptNum 014 Smith Bob 100 086 Jones Bill 200 127 Doe John 100 192 Doe Jane 300 Num LastName FirstName Relationship 014 Smith Susan Wife 014 Smith Billy Son 014 Smith John Son 192 Doe Jane Wife 192 Doe Mary Daughter 428 Smith Betty Wife No primary key yet
ER Modeling ER Diagram ID-Dependent and Weak Entities Pg 2 Here s the ER Diagram in different styles: Identifying relationship 1 Participation constraint M This one is old fashioned. 1 0..M This is a little better. Participation constraint (same as 1..1) Participation constraint Identifying relationship (Solid line) (Rounded corners) This is how modern data modeling tools draw an ER diagram. Notice all the double lines in the original style diagram: The double outline in the relationship diamond indicates an identifying relationship. That means the key of contains the key of as one of its components. The double line leading from the diamond to is called a constraint and indicates a mandatory in the relationship. Every row must be associated with an row. The double outline on the entity means that is a weak entity. A row of can't exist on its own without a corresponding instance. We ll examine these concepts below. Let s Make a Primary Key in the Table Remember we said that we hadn t gotten around to giving the table a primary key? We'll do that now by adding a FamMbrId attribute: Composite Key ( multiple attributes) New attribute added to make the key unique. Num FamMbrId LastName FirstName Relationship 014 01 Smith Susan Wife 014 02 Smith Billy Son 014 03 Smith John Son 192 01 Doe Jane Wife 192 02 Doe Mary Daughter 428 01 Smith Betty Wife FamMbrId is a sequential number that starts over for each Num. The key of is a Composite Key because it's composed of multiple attributes.
ER Modeling ER Diagram ID-Dependent and Weak Entities Pg 3 Composite Key The attributes Num+FamMbrId combine to form the primary key of. A key made up of more than a single attribute is called a composite key. Cardinality Refresher Maximum Cardinality Notice the maximum cardinalities in the ER Diagram. One row can be connected to many rows, but a row can be connected to only one row. This is called a one-to-many relationship. There are three types of maximum cardinality ratios: One-to-one (1:1) One-to-Many (1:M) Many-to-Many (M:M) Maximum cardinality tells us how many rows can participate in a relationship. Minimum Cardinality Now look at the minimum cardinalities. An row is required to have at least zero s. This is called an optional constraint and is indicated by either: The zero in the 0..M near the entity in the old style. The near the entity in the crow s foot style. Notice that in the other direction, there is no choice in cardinality. Minimum cardinality for a row is the same as the maximum cardinality: one. This is shown by: The one (without a zero) near the entity in the old style. The near the entity in the crow s foot style. When the minimum cardinality is greater than zero, it s called a mandatory constraint. Minimum Cardinality tells us at least how many rows must participate in a relationship. The full minimum cardinality specification is Optional-to-, or O-M. Optional and Participation What makes the relationship of to mandatory? It s the company s rule that to be called a family member, a person must be in the family of an employee. A key can be composed of any number of attributes. A Composite Key has more than one attribute. A little review. Maximum cardinality is the most important characteristic of a relationship. Maximum cardinality tells how many rows can potentially be associated with another row. Minimum cardinality tells at least how many rows must be associated with another row. An can optionally have a. A must belong to an. means (in this case) that a child row must have a parent. Frequently, minimum determined by business rules.
ER Modeling ER Diagram ID-Dependent and Weak Entities Pg 4 There are other such obvious rules: For example, we can t have a room without having a building in which the room is located. However, we could have a building that hasn t been divided into rooms. Room-to-Building is therefore an Optional-to- relationship. ID-Dependent Entities Look at the two tables again: Num LastName FirstName DeptNum 014 Smith Bob 100 086 Jones Bill 200 127 Doe John 100 192 Doe Jane 300 Part of the key of is also the key of. Num FamMbrId LastName FirstName Relationship 014 01 Smith Susan Wife 014 02 Smith Billy Son 014 03 Smith John Son 192 01 Doe Jane Wife 192 02 Doe Mary Daughter 428 01 Smith Betty Wife The primary key in the table is the composite of Num+ FamMbrId. There is something critically important about this key: The key of contains an attribute that is the key of another entity. The Num attribute, which is part of the key of, is the key of. We have a special name for this. is what we call an ID-Dependent entity. It s impossible for a row to exist without a corresponding row. The definition of an ID-dependent entity is an entity whose identifier (key) contains the key of another entity. The Num attribute is a key of the entity, and is used as the foreign key in the table. Merely having a foreign key is not significant; it s the fact that this attribute is part of the key of that makes this entity ID- Dependent. is ID-Dependent on. Part of the key of is the whole key of. An ID-Dependent entity is one whose key contains the key of another entity. An ID-Dependent row cannot exist without its parent row in the other table.
ER Modeling ER Diagram ID-Dependent and Weak Entities Pg 5 Weak Entities & Strong Entities If we were to delete an row that had rows attached, what would happen to those rows? The Num in their primary key would no longer be valid. They are no longer family members of an employee, and they should be deleted from the database, too. A rule to enforce this is called a referential integrity constraint. A Weak Entity is an entity whose existence depends on the existence of another entity. All ID-dependent entities are weak, but not all weak entities are ID-dependent. A Strong Entity is any entity that isn't weak. A strong entity s existence doesn't depend on the existence of some other entity. Weak Entities Are Not Necessarily ID-Dependent All ID-dependent entities are weak, but not all weak entities are ID-dependent. An example of a weak entity that isn t ID-dependent is the relationship of an Automobile to its Model number. The model is the automobile s design. We can say this car is a Buick Skylark but we can t say this car is not any model, it s just a car. There can t be an automobile without a design, so the Automobile entity is weak to the Model entity. Referential integrity rules that make sure there are no orphan rows. Possible 1. Automatically delete children. 2. Prevent deleting parents with children. Weak entities cannot exist without the existence of another entity. All ID-dependent entities are weak, but not all weak entities are ID-dependent. But an automobile s identifier is its serial number which isn't related to the model number. So the relationship between Automobile and Model is not ID-dependent, although Automobile is still a weak entity and can't exist without the Model. A Relationship Does Not Make an Entity Weak All weak entities have a mandatory relationship, but not all entities with a mandatory relationship are weak. For example, the University requires all students to have an advisor, so the relationship of Student to Advisor is mandatory. We can t have a student without an advisor. But this is the result of a business rule. The existence of a student doesn t depend on the existence of an advisor. If an advisor left the university, the students he advised would still exist. This means that Student is a strong entity even though it participates in a mandatory relationship. means that the minimum cardinality is greater than zero. does not make an entity weak.