1. Chapter 5 Entity-Relationship Modeling

2. Chapter Outline How to use ER modelling in database design.
Basic concepts of an ER model
Entities
Relationships
Attributes
Constraints
A diagrammatic technique for displaying an ER model.
diagrammatic technique 圖解技術
connection traps 連接陷阱

3. Goals of Entity Relationship Modeling
Gather and capture information about what the users require of the DB applications
Information appears only once in the modeling
Do not model on information that is derivable from other modeled information
Model business data, not implementation
A robust notation that results in easy-to-read diagrams
Capture all required information
捕獲所有需要的資訊
Derivable 推導得出
in a predictable, logical place
是在可預見的，邏輯的地方

4. ER Modelling A Top-down approach to database design
Start by identifying
entities : important data, and
relationships between the data.
Then add more details such as
attributes : the information about the entities and relationships,
constraints on the entities, relationships, and attributes.

5. Basic Concepts Of The ER Model
Entities
Relationships
Attributes
Constraints
The ER diagram for StayHome company

6. Entity Type Entity type （實體類型） ~ a relational table
A group of objects with same properties, identified by an enterprise as having an independent existence.
Example : Employee (Faculty), Customer, Supplier
An entity occurrence（一個實體物件、個例) ~ a record
An object of an entity type, e.g., 陳春賢 (a Faculty member of CGU)
Each object should be uniquely identifiable within an entity type.
Entity occurrence
一個具體化的實體

7. Diagrammatic Notation of Entity Types

8. Relationship Types Relationship type （關係類型）
A set of similar associations (關連、聯結) among participating entities.
Each association should be uniquely identifiable within the set.
A relationship occurrence （一個關係物件、個例）
A uniquely identifiable association.

9. Diagrammatic Notation of Branch Has Staff Relationship
箭頭代表方向性

10. Example of Relationship Type and Occurrence
StayHome ERD
Branch
、個例
Has
Manages
Staff

11. Degree (度數) of a Relationship
Number of participating entity types in a relationship.
Two is binary
Three is ternary
Four is quaternary

12. A Binary Relationship Called Has
Has is a binary relationship
Binary Relationship二元關係

13. A Ternary Relationship Called Registers
Registers is a ternary relationship
A relationship occurrence of Registers involves
A staff member
A member
A branch
Ternary Relationship 三元關係

14. Recursive Relationships
A relationship where a same entity type participates more than once, but in different roles.
A recursive relationship may be given different role names to indicate the purpose that each end of the participating entity type plays in the relationship.
Recursive Relationships 遞迴關係

15. A Recursive Relationship Called Supervises with Different Role Names
Supervisee 受監管者
Supervisor 管理者

16. Two Entities Associated by Two Relationships

17. Attributes
Attribute
A particular property of an entity or a relationship.
Hold a value that describes an occurrence of an entity or relationship
Attribute Domain
A set of allowable values for an attribute.

18. Examples of Attributes of Various Entities

19. Classification of Attributes
Simple Attribute (簡單的屬性)
Attribute composed of a single component
Cannot be further subdivided
For example: price attribute for a video
Composite Attribute (複合的屬性)
Attribute composed of multiple components, each with an independent existence
Can be further subdivided
For example: name and address attribute of the member entity

20. Classification of Attributes
Single-valued Attribute (單一值的屬性)
holds a single value for each entity occurrence
For example: each entity occurrence of the Video entity has a single value for the catalogNo attribute
Multi-valued Attribute (多值的屬性)
holds multiple values for each entity occurrence
For example: each entity occurrence of the Video entity type may have multiple values for the category attribute, e.g, action and sci-fiction movie

21. Classification of Attributes
Derived Attribute (衍生的屬性)
holds a value that is derivable from the value of a related attribute, or a set of attributes
For example:
The age of a staff member
Total number of staff in each branch

22. ER Diagram of Entities and Their Attributes
Entity name
Entity name

23. Relationship with Attributes

24. Diagrammatic Notation of Primary Key
For complex database applications, we usually display just the primary key of each entity.
When only the primary key attributes are shown in the ER model, the {PK} tag can be omitted .

25. Strong And Weak Entities
Strong Entity
An entity type whose primary key is not dependent on the existence of another entity type
Weak Entity
An entity type whose primary key is partially or wholly dependent on the existence of another entity type (or entity types).

26. Strong and Weak Entities

27. Multiplicity Constraints on Relationships
Represents the number of possible occurrences of an entity type that may relate to a single occurrence of its associated entity
Main type of constraint on relationships
Represents policies (called business rules) in an organization.
Multiplicity Constraints On Relationships
關係的多重限制式
Multiplicity constrains the number of entity occurrences that relate to other
entity occurrences through a particular relationship

28. Cardinality （基數比）of Relationships
The most common degree for relationships is binary.
Cardinality of a binary relationship
A multiplicity constraint for a binary relationship
Describes maximum numbers of possible relationship occurrences for the two participating entities in a binary relationship.
Three types
one-to-one (1:1)
one-to-many (1:*)
many-to-many (*:*)

29. Example of One-to-One (1:1) Relationship
A member of staff manages a branch.

30. Diagramming Representation
maximum
minimum
minimum
maximum
Above ERD represents the following business rules:
Each branch is managed by exactly one member of Staff.
A member of Staff may manage at most one Branch.

31. Types of One-to-One (1:1) Relationships
1..1
(a)
1..1
0..1
(a)
0..1
1..1
(b)
0..1
(c)
A 1:1 relationship, mandatory at both ends, tightly connects two entities: when you create an instance of one entity there must be exactly one dedicated instance for the other simultaneously; for example, entity PERSON and entity BIRTH. This leads to the question why you want to make a distinction between the two entities anyway. The only acceptable answer is: only if there is a functional need.
Mandatory at one end is often in a model where roles are modeled, for example, in a hospital model, a person may be a patient. A person may be an employee. Both PATIENT and EMPLOYEE are roles played by a PERSON. The attribute BLOOD TYPE is, according to this model, only of interest when this person is a PATIENT.
Optional at both ends is uncommon. However, they can occur, for example, when there is a relationship between two entities that are conceptually the same but exist in different systems. An example of this is entity EMPLOYEE in one system and entity PERSON in a different, possibly a third-party, system. Many 1:1 relationships (of all three variants) do occur when some of the entities represent various stages in a process.

32. Example of One-to-Many (1:*) Relationships
A branch has many members of staff.

33. Diagramming Representation
exactly one
at least one
The ERD represents the following business rules:
Each Branch has at least one Staff
Each member of Staff works at exactly one Branch

34. Type of One-to-Many (1:* ) Relationships
1..1
1..*
(a)
1..1
0..*
(b)
(c)
0..1
1..*
(d)
0..1
0..*
Note: Try to avoid type (a) in favor of type (b)
Mandatory at both ends.
This type of relationship typically models entities that cannot exist without each other. Often the relationship expresses that an entity is always split into details. Seen from the other perspective, it often expresses an entity that is always classified, assigned.
Optional 1: mandatory m.
This is a very common type of relationship, together with (d). Normally, at least 90% all relationships are of type (b) and (d). The relationship expresses that the entity at the 1-end can stand alone, whereas the entity at the many end can only exist in the context of the other entity.
Mandatory 1: optional m.
This is not common. You will see it only when the relationship expresses that an entity instance only exists when it is a non-empty set, and where the elements of the set can exist independently. For example, a PRODUCT may be part of one BUNDLE. According to the model, a BUNDLE is of no interest if it is empty.
Optional at both ends. See remarks for (b).

35. Circumventing （迴避）Type 1..1 -- 1..* in 1:* Relationship
Usually you would try to avoid relationship type (a) in favor of type (b).
For example,
A 1:* relationship that is mandatory at both ends
A 1:* relationship that is mandatory at one end

36. Why Circumvent?
Implementing a 1:* relationship that is mandatory at both ends causes technical problems.
In particular, it is difficult for a user to enforce that there exists a related record at the same time for two newly-created records in a binary relationship.
雞生蛋，或蛋生雞

37. Example of Many-to-Many (*:*) Relationships
Actors play in videos.

38. Diagrammatic Representation
The ERD represents the following business rules:
Each actor may play in more than one video.
Each actor plays in at least one video.
A video may have more than one actors.
Not all video have actors.

39. Types of Many-to-Many (*:*) Relationships
1..*
(a)
1..*
0..*
(b)
(c)
0..*
1..*
(d)
0..*
Mandatory at both sides is very uncommon in normal circumstances. This relationship seems to mean that an entity instance can only be created if it is immediately assigned to an instance of the other entity, as well as conversely. But how can this occur when we do not have an instance of either entity? Enforcing the mandatory rule from scratch leads to a conflict. The relationship can, however, be part of a model of a theoretical nature, like the mathematical: a LINE always consists of many POINTS and a POINT is always part of many LINES. It can also describe an existing situation: a DEPARTMENT always has EMPLOYEES and an EMPLOYEE is always assigned to a DEPARTMENT. Here the question may arise if it is guaranteed that the situation will always remain this way.
Mandatory at one end is not uncommon in early versions of a model although they usually disappear at a later stage.
Optional at both ends is common in early versions of a model. These also usually disappear at a later stage.

40. Example for Non-Binary Relationships
Staff registers a member at a branch.

41. Example for Non-Binary Relationship Occurrences
The ternary Registers relationship from the Branch perspective with fixed values for Staff and Member.
Perspective 的角度
Fixed composition for Staff and Member

42. Diagrammatic Representation

43. Summary Of Multiplicity Constraints

44. Resolving *:* Relationships
xxxx
..* B A In
..* B
A/B Combination
..1
Has
Create a new associative entity (組合實體、關聯實體)
Create two 1:* relationships
Remove *:* relationship

45. Resolving *:* Relationships 1/2
First create a new associative entity.
Next create two new 1:* relationships for the associative entity, one from A and one from B.
Name the relationships.
First create a new intersection entity.
You will experience that sometimes there is no suitable word available for the concept you are modeling. The new entity can always be named with the neologism “A/B COMBINATION”, or a name that is somehow derived from the name of the original *:* relationship.
Do not let the unavailability of a proper name for the entity stop you from modeling it.
2. Next create two new 1:* relationships from intersection entity, one to A and one to B.
If the original *:* relationship was optional (or mandatory) at A’s side, then the new relationship from A to A/B COMBINATION is also optional (or mandatory).

46. Resolving *:* Relationships 2/2
The next step is to remove the *:* relationship you started with.
Finally, reconsider the newly-drawn relationships.
They may be optional at the A/B COMBINATION side. Also, they may turn out to be of type *:* and require further resolving.