1. Entity Relationship Modeling
Chapter 11

2. Objectives ER Model Entity type Relationship type Attribute
Cardinality and modality
Symbols
Examples

3. ER Model
It is a semantic data model that is used for the graphical representation of the conceptual database design.
An ER Model is a detailed, logical representation of the data for an organization or for a business area.
It is expressed in terms of entities in the business environment, the relationships (or associations) among those entities, and the attributes of both the entities and their relationships.
An ER model is normally expressed as an entity- relationship diagram which is graphical representation of an ER model.

4. Concepts of the ER Model
Entity types
Relationship types
Attributes

5. Entity Types Entity type Entity occurrence
Group of objects with same properties, identified by enterprise as having an independent existence.
Entity occurrence
Uniquely identifiable object of an entity type.

6. Example of Entity Type

7. Relationship Types Relationship type Relationship occurrence
Set of meaningful associations among entity types.
Relationship occurrence
Uniquely identifiable association, which includes one occurrence from each participating entity type.

8. Attributes Attribute Attribute Domain
Property of an entity or a relationship type.
Attribute Domain
Set of allowable values for one or more attributes.

9. Symbols
Entity
Attribute
Relationship

10. Example
program
is _enrolled_in
Student
Course
C_id
C_name
S_id
name

11. Attribute Types Simple Attribute Composite Attribute
Attribute composed of a single component with an independent existence.
E.g. salary attribute of Staff entity.
Composite Attribute
Attribute composed of multiple components, each with an independent existence.
E.g. address attribute of Branch entity can be subdivided into city, street and postcode attributes.

12. Composite Attribute Representation
address
postcode
city
street

13. Attribute Types (Contd.)
Single-valued Attribute
Attribute that holds a single value for each occurrence of an entity type.
E.g. each occurrence of the Branch entity type has a single value for the branchNo attribute.
Multi-valued Attribute
Attribute that holds multiple values for each occurrence of an entity type.
Each occurrence of the Branch entity type can have multiple values for telNo attribute.

14. Attribute Types (Contd.)
Derived Attribute
Attribute that represents a value that is derivable from value of a related attribute, or set of attributes, not necessarily in the same entity type.
E.g. age attribute of Staff entity type can be calculated from dateOfBirth attribute.

15. Symbols (Attribute Types)
Multi-valued attribute
street
Derived attribute

16. Entity Type Strong Entity Type Weak Entity Type
Entity type that is not existence-dependent on some other entity type.
Instances of a strong entity type always have a unique characteristic (called identifier)
E.g. Student, Employee, Course etc
Weak Entity Type
Entity type that is existence-dependent on some other entity type.

17. Entity types Employee Dependent Has Dependent_name Employee_id
Employee_name
Date_of_birth
Employee
Has
Dependent

18. Entity Type
Employee is a strong entity type with identifier employee_id (denoted by underline).
Dependent is a weak entity type, indicated by double-lined rectangle.
The relationship between a weak entity type and its owner is called an identifying relationship. (indicated by double lined diamond symbol)
The attribute dependent_name serves as partial identifier (indicated by double undderline).
During a later design stage, dependent_name will be combined with employee_id to form a full identifier for Dependent.

19. Cardinality and Modality
Cardinality is the specification of the number of occurrences of one [object] that can be related to the number of occurrences of another [object]. Cardinality is usually expressed as simply 'one' or 'many.'
Cardinality defines “the maximum number of objects that can participate in a relationship”.
The modality of a relationship is 0 if there is no explicit need for the relationship to occur or the relationship is optional. The modality is 1 if an occurrence ofthe relationship is mandatory.

20. Symbols
Mandatory One
Mandatory Many
Optional One
Optional Many

21. Example

22. Degree of relationship
The number of entity types that participate in a relationship.
3 types
Unary: Relationship between instances of a single entity type
Binary: Relationship between instances of two entity types
Ternary: A simultaneous relationship among instances of three entity types

23. Types of relationships
One-to-one (l:l)—An occurrence of [object] 'A' can relate to one and only one occurrence of [object] 'B,' and an occurrence of 'B' can relate to only one occurrence of 'A.'
One-to-many (l:N)—One occurrence of [object] 'A' can relate to one or many occurrences of [object] 'B,' but an occurrence of 'B' can relate to only one occurrence of 'A.’
Many-to-many (M:N)—An occurrence of [object] 'A' can relate to one or more occurrences of 'B,' while an occurrence of 'B' can relate to one or more occurrences of 'A.’

24. Relationship types and Examples
Unary relationship
manages
Employee
One-to-many

25. Relationship types and Examples
is_assigned
Employee
Parking_Place
One-to-one
registers_for
Student
Course
Many-to-many
Binary relationship

26. Relationship types and Examples
Part
supplies
Vendor
Warehouse
Ternary relationship

27. Examples

28. Exercise
Make ERD for a “has” relationship between patient and patient history entity types.
Make ERD for “is_assigned_to” relationship between employee and project entity types.

29. Associative Entity
An associative entity is an entity type that associates the instances or more entity types and contains attributes that are peculiar to the relationship between those entity instances.
Symbol:

30. Following are four conditions that should exist:
When to convert relationship to an associative entity type?
Following are four conditions that should exist:
All of the relationships for the participating entity types are “many” relationships.
The resulting associative entity type has independent meaning to end users, and preferably can be identified with a single-attribute identifier.
The associative entity has one or more attributes, in addition to the identifier.
The associative entity participates in one or more relationships independent of the entities related in the associated relationship.

31. Associative Entity-Example

32. Multiple Relationships
In some situations, an organization may wish to model more than one relationship between the same entity types.

33. Examples-Multiple Relationships

34. Enhanced E-R Model
The model that has resulted from extending the original E-R model with new modeling constructs.
The most important modeling construct incorporated in the EER model is super-type/subtype relationships. This facility enables us to model a general entity type (called the supertype) and then subdivide it into several specialized entity types (called subtypes).
For example the entity type CAR can be modeled as a supertype, with subtypes SEDAN, SPORTS CAR, COUPE, and so on.
Each subtype inherits attributes from its supertype and in addition may have special attributes and be involved in relationships of its own.

35. Representing supertypes and subtypes
Subtype: A subgrouping of the entities in an entity type that is meaningful to the organization and that shares common attributes or relationships distinct from other subgroupings.
Supertype: A generic entity type that has a relationship with one or more subtypes.

36. Basic Concepts and Notation
The supertype is connected with a line to a circle, which in turn is connected by a line to each subtype that has been defined.
The U-shaped symbol on each line connecting a subtype to the circle emphasizes that the subtype is a subset of the supertype. It also indicates the direction of the subtype/supertype relationship.

37. Basic Concepts and Notation (Contd.)

38. Example
Suppose that an organization has three basic types of employees: hourly employees, salaried employees, and contract consultants. Some of the important attributes for each of these types of employees are the following:
Hourly employees: Emp_Number, Emp_Name, Address, Date_Hired, Hourly_Rate
Salaried employees: Employee_Number, Employee_Name, Address, Date_Hired, Annual_Salary, Stock_Option
Contract consultants: Employee_Number, Employee_Name, Address, Date_Hired, Contract_Number, BiI1ing_Rate
Notice that all of the employee types have several attributes in common: Employee_Number, Employee_Name, Address, and Date_Hired. In addition, each type has one or more attributes distinct from the attributes of other types (e.g., Hourly_Rate is unique to hourly employees).

39. Employee supertype with three subtypes

40. When to Use Supertype/Subtype Relationships
Whether to use supertype/subtype relationships is a decision that the data modeler must make in each situation. You should consider using subtypes when either (or both) of the following conditions are present:
1. There are attributes that apply to some (but not all) instances of an entity type.
2. The instances of a subtype participate in a relationship unique to that subtype.

41. Supertype/subtype relationships in a hospital

42. Representing Specialization and Generalization
Generalization: The process of defining a more general entity type from a set of more specialized entity types.
Specialization: The process of defining one or more subtypes of the supertype and forming supertype/subtype relationships.

43. Example of generalization

44. Example of generalization (Contd.)

45. Example of Specialization

46. Example of Specialization (Contd.)

47. Specifying constraints in supertype/subtype relationships
Completeness constraint: A type of constraint that addresses the question whether an instance of a supertype must also be a member of at least one subtype.
Total specialization rule: Specifies that each entity instance of the supertype must be a member of some subtype in the relationship.
Partial specialization rule: Specifies that an entity instance of the supertype is allowed not to belong to any subtype.

48. Examples of completeness constraints

49. Examples of completeness constraints (Contd.)

50. Specifying constraints in supertype/subtype relationships (Contd.)
Disjointncss constraint: A constraint that addresses the question whether an instance of a supertype may simultaneously be a member of two (or more) subtypes.
Disjoint rule: Specifies that if an entity instance (of a supertype) is a member of one subtype, it cannot simultaneously be a member of any other subtype.
Overlap rule: Specifies that an entity instance can simultaneously be a member of two (or more) subtypes.

51. Examples of disjointness constraints

52. Examples of disjointness constraints (Contd.)

53. The End