1. Conceptual Modeling and Entity-Relationship Diagrams
Chapter 3: Elmasri/Navathe

2. Outline Phases of Database Design Conceptual Modeling
Abstractions in Conceptual Design
Example Database Requirements
Deconstructing the E-R Diagram
Entities, Attributes and Relationships
Participation, Cardinality and Keys
3753 X

3. Phases of Database Design
Application Domain
Requirements Analysis
Database Requirements
DBMS
Independent
Conceptual Design
Conceptual Schema
Data Model Mapping
Implementation Schema
Physical Design
DBMS
Dependent
Physical Schema
3753 X

4. A Data Modeling Process
Steps in the data modeling process
Plan project
Determine requirements
Specify entities
Specify relationships
Determine identifiers
Specify attributes
Specify domains
Validate model
3753 X

5. Planning the Project Obtaining project authorization and budget
Building the project team
Planning the team’s activities
Establishing tools, techniques, and standards for consistent results
Defining the project’s scope
3753 X

6. Determining System Requirements
Sources for data modeling requirements
User interviews and user activity observations
Existing forms and reports
New forms and reports
Existing manual files
Existing computer files/databases
Formally defined interfaces (XML)
Domain expertise
The result of the requirements determination will be a repository of notes, diagram, forms reports, files, etc., that can be used to develop the data model
3753 X

7. Specifying Entities
An entity is something that the users want to track; something the users want to keep data about
Entities
can be physical things or logical concepts
are identifiable; you can tell one from another
are things described by nouns, not characteristics described by adjectives
3753 X

8. Specifying Relationships
Includes:
Identity of the parent and child entities
Relationship type
Minimum and maximum cardinalities
Name of the relationships
Two techniques:
Examine whether a relationship exists between every combination of two entities
Locate relationships from requirement documents
A combination of the two approaches may be used
3753 X

9. Determining Identifiers
Identifier is an attribute or group of attributes that uniquely identifies an entity instance
If there is difficulty specifying an identifier, maybe:
it should be part of a different entity
it is a subtype or category of a common entity
it needs one or more identifying relationships
3753 X

10. Specifying Attributes and Domains
Find attributes on forms, reports, existing files, etc., and add them to entities
Determine whether the attribute has already defined a domain
If so, the attribute is based upon that domain
If not, a new domain is defined
Review the domains and make adjustments as necessary
Domain property inheritance: when the domain properties change, all the attribute properties change as well
Domains may be used to enforce data standards promoting compatible data types and systems
Once all attributes have been specified the model should be reviewed for missing entities
3753 X

11. Validating Model
Data model is a model of humans’ models, not a model of reality
A data model is wrong if it does not accurately reflect the ways the users think about their world
Data models are validated through a series of reviews
Normally, a team review is followed by user reviews
E-R model as well as prototypes of forms and reports may be used to communicate to users features of the data model
3753 X

12. Creating Data Models From Forms and Reports
Example: Single entities
3753 X

13. Example: Identifying Connection Relationships

14. Example: Repeating Groups

15. Example: Repeating Groups

16. Example: Nested Groups

17. Example: Non-Identifying Connection Relationships

18. Example: Non-Identifying Connection Relationships

19. Example: 1:N
3753 X

20. Example: 1:N
3753 X

21. Example: 1:N
3753 X

22. Example: N:M
3753 X

23. Example: Assignment Relationship

24. Example: Assignment Relationship

25. Example: Category Relationship

26. Example: Category Relationship

27. Example: Category Relationship

28. Sales-Order Model
3753 X

29. Example: Sales Order
3753 X

30. Example: Sales Order
Figure 3-16(c) shows an alternative design that allows an item to appear more than once on a given order
3753 X

31. Conceptual Design
Similar to the analysis phase in software development
produce a description of the data
capture the semantics of the data
Description in a high-level model
close to the user’s view of the world
abstract concepts
means of communication between the user and the developer
3753 X

32. Reasons for Conceptual Modeling
Independent of DBMS.
Allows for easy communication between end-users and developers.
Has a clear method to convert from high-level model to relational model.
Conceptual schema is a permanent description of the database requirements.
3753 X

33. Abstractions in Conceptual Design
An abstraction is a mental process where we select some set of properties of an object and exclude others.
3 types of abstractions
classification
aggregation
generalization
3753 X

34. Classification
Define a class of real-world objects with common properties
Month …
January
February
December
3753 X

35. Aggregation
Define a new class from a set of other classes that represent component parts
Car
Tires
Steering Wheel
Engine
Gas pedal
3753 X

36. Generalization
Defines a subset relationship between elements of 2 or more classes
Person
Employee
Student
Faculty
Staff
3753 X

37. Entity-Relationship Model
Most popular conceptual model for database design
Basis for many other models
Describes the data in a system and how that data is related
Describes data as entities, attributes and relationships
3753 X

38. Database requirements
We must convert the written database requirements into an E-R diagram
Need to determine the entities, attributes and relationships.
nouns = entities
adjectives = attributes
verbs = relationships
3753 X

39. Academic Teaching Database
Design an E-R schema for a database to store info about professors, courses and course sections indicating the following:
The name and employee ID number of each professor
The salary and address(es) for each professor
How long each professor has been at the university
The course sections each professor teaches
The name, number and topic for each course offered
The section and room number for each course section
Each course section must have only one professor
Each course can have multiple sections
3753 X

40. Visual View of the Database
Employee ID
Start Date
Years Teaching
Section ID
Room N 1
Section
Professor
teaches N
Salary
First
Part of
Name
Last 1
Number
Course
Topic
Name

41. The Pieces Objects “Structural” Constraints
Entity (including weak entities)
Attribute
Relationship
“Structural” Constraints
Cardinality
Participation
3753 X

42. Entities Entity – basic object of the E-R model
Represents a “thing” with an independent existence
Can exist physically or conceptually
a professor, a student, a course
Entity type – used to define a set of entities with the same properties.
3753 X

43. Entity and Entity Types
Course
Number
Topic
Name
Number: 3753
Name: Database Management Systems
Topic: Introduction to DBMSs
Entity
3753 X

44. Attributes
Each entity has a set of associated properties that describes the entity. These properties are known as attributes.
Attributes can be:
Simple or Composite
Single or Multi-valued
Stored or Derived
NULL
3753 X

45. Attributes (cont’d) Simple Composite Professor Start Date Professor
Name
First
Last
3753 X

46. Attributes (cont’d) Single Multi-Valued Professor Employee ID#
3753 X

47. Attributes (cont’d) Stored Derived Professor Start Date Professor
Years Teaching
3753 X

48. Attributes (cont’d) NULL attributes have no value
not 0 (zero)
not a blank string
Attributes can be “nullable” where a null value is allowed, or “not nullable” where they must have a value.
3753 X

49. Primary Keys Employee ID is the primary key
Professor
Employee ID
Employee ID is the primary key
Primary keys must be unique for the entity in question
3753 X

50. Relationships defines a set of associations between various entities
can have attributes to define them
are limited by:
Participation
Cardinality Ratio
3753 X

51. Relationships (cont’d)
Section
part of
Course
3753 X

52. Participation
Defines if the existence of an entity depends on it being related to another entity with a relationship type.
Partial
Total
Section
part of
Course
3753 X

53. Concepts and Notations (cont)
Relationship
A relationship R among n entity types E1,E2, .. En defines a set of associations (relationship set) among entities from these types.
A relationship has its type and set (instances).
Each instance in R is an association of entities, where the association includes exactly one entity from each participating entity type.
The reference from entity to another should be represented in the ER model as a relationship not as attributes.
3753 X

54. Concepts and Notations (cont)
In ER diagram, relationship types are displayed as diamond-shaped boxes, which are connected by straight lines to the rectangular boxes representing the participating entity types.
EMPLOYEE r1  r2 r3 r4 r5
WORKS_FOR
e1 •
e2 •
e3 •
e4 •
e5 • .
DEPARTMENT
• d1
• d2
• d3 .
3753 X

55. Concepts and Notations (cont)
Degree of relationship type: it is the number of participating entity type (binary, ternary, .).
Ex: the next figure is a ternary relationship.
SUPPLIER
SUPPLY r1  r2 r3 r4 r5
s1 •
s2 •
s3 • .
PROJECT
• j1
• j2
• j3 .
PART
p1 •
p2 •
p3 • .
3753 X

56. Constraints on Relationship Types
Cardinality Ratio: it specifies the number of relationship instances that an entity can participate in.
There is three types:
1:1 (one-to-one) relationship.
1:N (one-to-many) relationship.
M:N (many-to-many) relationship.
3753 X

57. Constraints on Relationship Types
1:1 (one-to-one) relationship:
MANGES
EMPLOYEE r1  r2 r3 r4 r5
e1 •
e2 •
e3 •
e4 •
e5 • .
DEPARTMENT
• d1
• d2
• d3 .
3753 X

58. Constraints on Relationship Types
1:N (one-to-many):
WORKS_FOR
EMPLOYEE r1  r2 r3 r4 r5
e1 •
e2 •
e3 •
e4 •
e5 • .
DEPARTMENT
• d1
• d2
• d3 .
3753 X

59. Constraints on Relationship Types
M:N (many-to-many):
WORKS_ON
EMPLOYEE r1  r2 r3 r4 r5
e1 •
e2 •
e3 •
e4 •
e5 • .
PROJECT
• p1
• p2
• p3 .
3753 X

60. Constraints on Relationship Types
Types of participation constraints:
Total participation (Mandatory):
Every entity must be related to an instance in the relationship..
It is represented in the ER by a double line connecting the participating entity type to the relationship.
It is also called the existence dependency.
The “Works-For” relationship illustrates how Employee is total participated in the relationship.
3753 X

61. Constraints on Relationship Types
Types of participation constraints:
Partial participation (Optional):
Part (some) of the entities are related to some instances in the relationship.
It is represented in the ER by a single line connecting the entity to the relationship.
Employee is partially participated in “Manages”.
3753 X

62. Attributes of Relationship Types
Relationship types can also have attributes (e.g. “Works-On” may have attributes as hours, start_date, ..etc).
3753 X

63. Cardinality
The number of relationships that an entity may participate in.
1:1, 1:N, N:M, M:1 N 1
Section
part of
Course
3753 X

64. Weak entity Weak entities do not have key attributes of their own.
Weak entities cannot exist without another a relationship to another entity.
A partial key is the portion of the key that comes from the weak entity. The rest of the key comes from the other entity in the relationship.
Weak entities always have total participation as they cannot exist without the identifying relationship.
3753 X

65. Identifying Relationship
Weak Entity (cont’d)
Section
Section ID
Identifying Relationship
part of
Number
Course
3753 X

66. Review of the E-R Diagram
Employee ID
Start Date
Years Teaching
Section ID
Room N 1
Section
Professor
teaches N
Salary
First
Part of
Name
Last 1
Number
Course
Topic
Name

67. University DB Case Study
Maintain the following information about undergrad students:
Name, address, student number, date of birth, year of study, degree program (BA, BSc, BCS), concentration (Major, Honours, etc) and department of concentration.
Note: An address is composed of a street, city, province and postal code; the student number is unique for each student
3753 X

68. University Case Study (cont’d)
Maintain information about departments
Name, code (CS, Phy), office phone, and faculty members
Maintain information about courses:
Course number (3753), title, description, prerequisites.
Maintain information about course sections:
Section (A, B, C), term (X1), slot #, instructor
3753 X

69. University Case Study (cont’d)
Maintain information about faculty:
Name, rank, employee number, salary, office number, phone number and address.
Note: employee number is unique
Maintain a program of study for the current year for each student:
i.e. courses that each student is enrolled in
3753 X

70. MultivaluedAttribute Partial Participation
ER conventions
Relation
Entity
Weak Entity
Attribute 1 N
1:N Relation
MultivaluedAttribute
Total Participation
(Mandatory)
Derived Attribute
Key Attribute
Partial Participation
(Optional)
Composite Attribute
3753 X

71. Extended E-R Model
E-R model is sufficient for traditional database applications
Nontraditional applications (CAD, multimedia) have more complex requirements
Can extend traditional E-R diagrams with semantic data modeling concepts
3753 X

72. IS-A Relationship (cont’d)
Name
S.I.N.
Employee d
Staff
Teaching Assistant
Faculty
Position
Rank
Student #
3753 X

73. Specialization & Generalization
process of taking an entity and creating several specialized subclasses
Generalization
process of taking several related entities and creating a general superclass
We will talk mainly of specialization, but most information will also apply to generalization
3753 X

74. Specialization constraints
Specializations can be predicate-defined or attribute-defined (otherwise called user-defined)
Disjointness constraint – specialization is disjoint or overlapping
Completeness constraint – specialization is total or partial
3753 X

75. Predicate-defined subclass
An attribute value is used to determine the members of a subclass
Not all members of every subclass can be determined by the attribute value
In the following example, the Pension Plan type can be used to determine faculty from staff, but has no effect on students or those who opted out of the pension plan.
3753 X

76. Predicate-defined subclass
Pension
Plan Type
S.I.N.
Employee
Note: not all
employees included d
Staff
Faculty
Rank
Position
3753 X

77. Attribute-defined subclass
There is one defining attribute for all subclasses
Each member of the superclass can be assigned to the appropriate subclass based on this one attribute
3753 X

78. Attribute-defined subclass
S.I.N.
Jobtype
Employee
Jobtype d
“Faculty”
“Staff”
“Student”
Students
Faculty
Staff
Rank
Year
Rank
3753 X

79. User-defined subclass
When there is no condition to automatically determine membership in a subclass, it must be done at the discretion of the user.
3753 X

80. Disjointness constraint
Specifies that an entity can be a member of at most one subclass
There can be no overlap between the subclasses
We use the notation of a d in a circle to symbolize that the subclasses are disjoint
3753 X

81. Disjoint constraint Name S.I.N. Employee d Staff Teaching Assistant
Faculty
Position
Rank
Student #
3753 X

82. Overlap Entities are able to belong to more than one subclass
Notation is an o inside of a circle
3753 X

83. Overlap S.I.N. Employee Jobtype A staff member may also be a student o
Faculty
Staff
Students
Rank
Rank
Year
3753 X

84. Completeness Constraint
May be total or partial
for total, every entity in the superclass must belong to a subclass
for partial, entities in the superclass do not need to be part of any subclass
notation for total and partial are the same as in a regular E-R diagram – single and double lines
3753 X

85. Partial S.I.N. Jobtype Employee o Faculty Staff Students Rank Rank
Year
3753 X

86. Total S.I.N. Employee Jobtype o Staff Students Faculty Rank Rank Year
3753 X

87. Hierarchies and Lattices
a tree-like structure where each subclass belongs to only one superclass
everything we have seen so far is a hierarchy
Lattices
a graph-like structure where a subclass can belong to more than one superclass
3753 X

88. Lattice name Person student # Employee Student salary course
Teaching Assistant
3753 X

89. 3753 X

90. مثال
3753 X

91. Example 2
3753 X

92. Example 3
3753 X

93. Example 3
3753 X

94. Example 4
3753 X

95. Continue example 4
3753 X