IST 601: Database Management
ER Modelling
(Chapters 10, 12 & Appendix C)
Denis L. Nkweteyim
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
1
Outline
●
Database design process
●
Conceptual Design
●
Entity-relationship diagrams (covered)
●
Review of UML data modelling (not covered)
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
2
Database Analysis and Design
●
●
●
Diagram sketches the database design process
This course is concerned with the database design
stages
This chapter is concerned with conceptual design
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
3
Overview of Database Design
●
Database design
●
The process of creating a design that will support the enterprise’s mission
statement and mission objectives for the required database system
●
Involves creation of data models
●
Stages include
●
Conceptual Design
●
Logical Design
●
Schema Refinement (normalization)
●
Physical Design
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
4
Overview of Database Design
●
Why create data models
●
●
●
Describes high level conceptual structuring of data
Useful because it hides fine details of the data storage that
most DB users do not need
Examples
●
●
21/10/22
Modelling student data as a set of records, each with ID, name,
address, and courses
Modelling data as a graph where nodes represent people and
edges represent friendship relations
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
5
Overview of Database Design
●
Conceptual Design
●
The process of constructing a model of the data used in an enterprise,
independent of all physical considerations
●
A high level conceptual data model is created for the database
●
Define the the high-level user operations that are noted during analysis
●
●
Does not include implementation details and so easier to understand
and helps in communication with non-technical users
Two common approaches
●
●
21/10/22
ER diagramming
UML (User Modelling Language) design
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
6
Overview of Database Design
●
Logical Design
●
The process of constructing a model of the data used in an enterprise based on
a specific data model, but independent of a particular DBMS and other physical
considerations.
●
Follows conceptual design
●
Also called the data modeling mapping phase
●
Conversion from conceptual to logical design is typically a mechanical operation
●
●
Examples
●
●
21/10/22
Just follow the rules
Relational design
Object database design
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
7
Overview of Database Design
●
Schema Refinement (normalization)
●
●
21/10/22
Logical model usually includes redundancy and other
anomalies
Normalization gives a way to change the relation schema to
reduce these redundancies and anomalies
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
8
Overview of Database Design
●
Physical (or Implementation) Design
●
The process of producing a description of the implementation of
the database on secondary storage
●
●
●
●
21/10/22
Describes the base relations, file organizations, and indexes used to
achieve efficient access to the data, and any associated integrity
constraints and security measures
Select which DBMS to use
Specification of internal storage structures, access paths,
indices, data types, integrity constraints etc.
Adding data to and testing the database
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
9
Overview of Database Design
●
Figure shows the
correspondence between
the three-level
architecture and
conceptual, logical, and
physical database design
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
10
Entity-Relationship Modelling
●
What is ER Modelling?
●
Definitions: Entity types, Attributes, Relationships
●
Model shapes
●
Constraints on relationships
●
Weak entity types
●
Subclasses
●
Other notations: Minmax, Crow's foot
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
11
What is ER Modelling?
●
●
●
●
●
Top-down diagramming approach to data modelling
Diagrams are developed from business requirements of
database
Deals with entities (things of interest to the business)
and the relationships among them
The E/R model allows us to sketch the design of a
database informally
Designs are pictures called entity-relationship diagrams
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
12
What is ER Modelling?
●
Several notations available for ER modelling
–
–
●
We shall use the Chen notation
...and introduce the “crow’s foot” notation commonly used in
several CASE tools
CASE tools exist for ER diagramming and for converting
diagrams into corresponding database tables
–
21/10/22
We shall use MySQL Workbench for this purpose
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
13
Enhanced (or Extended_ Entity Relationship
Diagram (EERD)
●
ERD was the original ER model
–
●
This was sufficient for traditional databases
EERD
–
21/10/22
Extension to the original model to be able to handle new
database systems that have more demanding database
requirements
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
14
Some Definitions
●
Entity type (Entity set)
●
Attribute
●
Relationship type (Relationship set)
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
15
Entity type
●
Entity type (Entity set)
–
Represents a group of real world objects or concepts to be
represented in the database
●
–
Examples: employee, project, student, course, etc.
Each uniquely identifiable object of an entity type is referred
to simply as an entity occurrence or entity
●
Example
–
–
21/10/22
Entity set Student
Entity John (one of the students who make up the entity set)
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
16
Relationship type (Relationship set)
●
A set of associations between one or more participating entity types
●
Each relationship type is given a name that describes its function
●
Example
–
●
Relationship type studies between students and the courses they register for
Relationship occurrence
–
–
A uniquely identifiable association that includes one occurrence from each
participating entity type
Example
●
21/10/22
Entity John (from entity type Student) studies course Biology (from entity type Course)
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
17
Relationship type (Relationship set)
●
Illustrating individual relationships between students and
the courses they study
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
18
Attribute
●
Some property of interest that further describes an entity
–
21/10/22
Examples: student name, date of birth, employee salary
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
19
Relationship Type
●
Diagrammatic representation
●
One notation
●
●
Another notation
●
●
21/10/22
Use a diamond connecting the
associated entity types
A line connecting the associated
entity types and labeled with the
name of the relationship (normally a
verb)
Label relationship in one direction
(with an arrow), the direction in which
the name makes sense (e.g. Branch
Has Staff makes more sense than
Staff Has Branch)
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
20
Degree of a Relationship
●
Number of participating entity types in the relationship
–
Binary
●
●
●
–
Tenary
●
–
Degree 3
Quaternary
●
–
Degree 2
Most common
Many modelling systems only support binary relationships
Degree 4
n-ary
●
●
21/10/22
Degree n
Has n edges in the relationship construct R, one connecting R to each participating entity type
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
21
Degree of a Relationship Examples
●
Binary
●
●
Tenary
●
●
PrivateOwner POwns PropertyForRent
Registration of a client by a member of
staff at a branch
Quatenary
●
Buyer, advised by a solicitor and supported
by a financial ­institution, places a bid
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
22
Recursive Relationship
●
A relationship type in which the same entity type participates more than once in
different roles.
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
23
Role Names
●
●
●
Each entity type in a relationship plays a particular role in that relationship
Usually, entity and relationship name clearly define the individual roles of each entity in a
relationship
If this is not the case, role names can be attached to the ends of the relationship construct
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
24
Attributes
●
Attribute
●
●
A property of an entity or a relationship type.
Attribute domain
●
21/10/22
The set of allowable values for one or more attributes
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
25
Diagrammatic Representation of Attributes I
●
Represented by an oval, with a line to the rectangle
representing its entity set
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
26
Diagrammatic Representation of Attributes II
●
Divide the rectangle ­representing the entity in two
●
Upper part displays the name of the entity and the lower part lists the names of the attributes
●
The first attribute(s) to be listed is the primary key for the entity type, if known.
●
The name(s) of the primary key attribute(s) can be labeled with the tag {PK}
●
Additional tags that can be used include partial primary key {PPK} when an attribute
forms part of a composite primary key, and alternate key {AK}
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
27
Classification of Attributes
●
Keys (i.e., identifiers) vs descriptors
●
Keys or identifiers
●
●
●
●
Descriptors
●
21/10/22
The minimal set of attributes that uniquely identifies each
occurrence of an entity type
Sometimes, several attributes together form a key
Key attributes are underlined in ER diagram that uses ovals for
attribute
Used to specify a non-unique characteristic of an instance of an
entity set
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
28
Classification of Attributes
●
Simple (atomic) vs composite (complex)
–
Composite attributes can be divided into smaller subparts
●
●
E.g., address comprises door number, street name, city, etc.
Simple attributes are not divisibleSimple (atomic) vs composite (complex)
–
Composite attributes can be divided into smaller subparts
●
–
E.g., address comprises door number, street name, city, etc.
Simple attributes are not divisible
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
29
Classification of Attributes
●
Single-valued vs multi-valued
–
Most attributes have single values
●
E.g., first name, age, birth date
–
Some attributes have a set of values for the same entity
–
E.g., hobbies
–
A person may have no hobby, another may have one, yet another two, etc.
–
One notation for multi-valued attribute: ellipse with double borders
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
30
Classification of Attributes
●
Stored vs derived
●
Example: age and date of birth
–
Age can be derived from today’s date and the date of birth
–
Hence, date of birth is a stored attribute
–
Age is a derived attribute
–
21/10/22
Derived attributes represented in ER diagrams as ovals with
dashed borders
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
31
Attributes on Relationships
●
Sometimes it is useful to attach an attribute to a
relationship
●
●
First example
●
●
●
Think of this attribute as a property of tuples (rows) in the
relationship set
Relationship Advertises between Newspaper and
PropertyForRent
To record the date the property was advertised and the
cost, we associate this information with the Advertises
relationship as attributes called dateAdvert and cost
Second example
●
Price is a function of both the bar that sells the beer and
the beer, not of one alone
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
32
Structural Constraints
●
●
Constraints limit the possible combinations of entities
that may participate in a relationship set
2 main types of constraints
–
Cardinality (or multiplicity or connectivity constraints)
–
Participation constraints
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
33
Cardinality Constraints
●
What is cardinality?
●
●
The number (or range) of possible occurrences of an entity type
that may relate to a single occurrence of an associated entity
type through a particular relationship
For binary relationships (the most common type), we have
the following relationship types
●
One-to-one (1:1)
●
One-to-many (1:*) or (1:N)
●
Many-to-many (*:*) or M:N
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
34
Some examples of Integrity Constraints
●
A member of staff manages a branch
●
●
●
This is a one-to-one (i.e., 1:1) relationship
A member of staff oversees properties for rent (1:*)
●
●
●
Put another way: Each member of staff manages a maximum of one branch; Each branch
is managed by a maximum of one member of staff
Put another way: Each member of staff manages several properties (i.e., zero or more
properties); Each property is managed by a maximum of one member of staff
This is a one-to-many (i.e., 1:* or 1:N) relationship
Newspapers advertise properties for rent
●
●
Put another way: Each newspaper advertises many (zero or more) properties; Each
property is advertised in many (i.e., zero or more) newspapers
This is a many-to-many (i.e., *:* or M:N) relationship
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
35
One-to-One (1:1) Relationships
●
●
In a one-one relationship, each entity of either entity set is related
to at most one (i.e., exactly zero or one) entity of the other set
In the example, we see that
–
StaffNo SG5 manages branchNo B003
–
StaffNo SL21 manages branchNo BOO5
–
StaffNo SG37 does not manage any branch
●
–
21/10/22
i.e., each staff manages zero or one branch
Similarly, each branch is managed by a maximum of one member of
staff
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
36
One-to-Many (1:* or 1:M) Relationships
●
Some binary relationships are many-one from one
entity set to another
–
–
Or One-Many if read in the reversed direction
Each entity of the first set is
connected to at
most one entity of the second set.
–
But an entity of the second set can be connected to
zero, one, or many entities of the first set
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
37
Many-to-Many (*:* or M:N) Relationships
●
In a many-many relationship, an entity of either
set can be connected to many (i.e., zero or
more) entities of the other set
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
38
Representing 1:1 Cardinalities on ER Diagrams (1)
●
In the example, we see that
–
StaffNo SG5 manages branchNo B003
–
StaffNo SL21 manages branchNo BOO5
–
StaffNo SG37 does not manage any branch
●
–
i.e., each staff manages zero or one branch
Similarly, each branch is managed by a maximum of one member of staff
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
39
Representing 1:1 Cardinalities on ER Diagrams (2)
●
Representation of the left
–
Each employee manages a maximum of one department; each department is
managed by a maximum of one employee
●
●
Nothing said about minimum cardinalities
Representation of the right (min-max notation)
–
Each employee manages a zero or many (0:N) departments; each department
is managed by exactly one (1:1) employee
–
–
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
40
Representing 1:* Cardinalities on ER Diagrams (1)
●
●
In the example, we see that
–
staffNo SG37 oversees property Nos PG21 and PG36
–
staffNo SA9 oversees propertyNo PA14
–
staffNo SG5 does not oversee any properties for rent
–
propertyNo PG4 is not overseen by any member of staff
In summary, a member of staff can oversee zero or more properties for rent and a property
for rent is overseen by zero or one member of staff
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
41
Representing 1:* Cardinalities on ER Diagrams (2)
●
Representation of the left
–
Each customer places many orders, but each order can be placed by one customer only
●
●
Nothing said about minimum cardinalities
Representation of the right
–
Each employee works for exactly 1 (min of 1, max of 1) department, and each department
has at least one employee (min of 1, max of many)
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
42
Representing *:* Cardinalities on ER Diagrams (1)
●
●
In the example, we see that
–
Glasgow Daily advertises propertyNos PG21 and PG36
–
The West News advertises propertyNo PG36
–
Aberdeen Express advertises propertyNo PA14
–
propertyNo PG4 is not advertised in any newspaper
In other words, one newspaper advertises one or more properties for rent and one property for rent is
advertised in zero or more newspapers
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
43
Representing *:* Cardinalities on ER Diagrams (2)
●
Each student belongs to many student organizations,
each organization can admit many students
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
44
Participation Constraints
●
●
Specifies whether the existence of some entity depends
on the existence of another entity
May be
–
Mandatory (or total participation)
–
Optional (or partial participation)
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
45
Participation Constraints
●
Total (or mandatory) participation
–
Every entity in the entity set must participate in at least one relationship instance in that relationship set
–
Depicted in Chen notation as a double line
●
●
Partial (or optional) participation
–
–
Each entity in the entity set may or may not participate in the relationship instance in that relationship
set
Depicted in Chen notation as a single line
●
●
each student must be enrolled in at least one courser
There might exist some courses for which no enrollments are made
Alternative notation
–
Single line for total participation
–
Single line + circle for partial participation
Professor
21/10/22
1
Guides
N
Student
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
46
Relationship between Cardinality and
Participation Constraints
●
●
●
Minimum cardinality tells whether the participation is
partial or total
●
If minimum cardinality = 0, then it signifies partial participation
●
If minimum cardinality = 1, then it signifies total participation
Maximum cardinality tells the maximum number of entities
that participates in a relationship set
When type of participation is not known, we assume
minimum connectivity of 1
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
47
Participation Constraints
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
48
Alternative representation for cardinality and
participation I
●
Cardinality of 1
–
●
Single arrow
Cardinality of many
–
21/10/22
No arrow
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
49
Alternative representation for cardinality and
participation II
●
●
Use two indicators for relationships, shown on both sides of the
relationship symbol
First indicator (multiplicity)
–
–
●
Refers to the maximum number of times that an instance of one entity can
be associated with instances in the related entity
Can be one or many
Second indicator (participation constraint)
–
–
21/10/22
Describes the minimum number of times one instance can be related to
others
Can be zero (optional) or one (mandatory)
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
50
First indicator (Multiplicity)
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
51
Second indicator (Participation constraint)
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
52
Combining the two indicators
●
Always in a specific order
–
Reading from the relationship symbol
●
●
21/10/22
Participation constraint (minimum cardinality) comes first
Multiplicity (maximum cardinality) comes second
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
53
Four possible edges to a relationship
●
●
Zero or many
One or many
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
54
Four possible edges to a relationship
●
●
One and only one
Zero or one
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
55
Alternative representation for cardinality and
participation III (Minmax)
●
We already saw an example of this (Slide 40)
–
–
Associate a pair of integers (min, max) with each participation of an
entity type E in a relationship type R (0 ≤ min ≤ max and max ≥ 1)
For each entity e in E, e must participate in at least min and at most
max relationship instances in R at any point in time
●
●
min = 0 implies partial participation
min > 0 implies total participation
●
●
●
21/10/22
Default (no constraint): min=0, max=n
Must have min ≤ max, min ≥ 0, max ≥ 1
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
56
Minmax Example I
●
A department has exactly one manager and an
employee can manage at most one department.
–
Specify (0,1) for participation of Employee in Manages
–
Specify (1,1) for participation of Department in Manages
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
57
Minmax Example II
●
An employee can work for exactly one department but a
department can have any number of employees.
–
–
21/10/22
Specify (1,1) for participation of EMPLOYEE in
WORKS_FOR
Specify (0,N) for participation of DEPARTMENT in
WORKS_FOR
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
58
Problems with ER Models
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
59
Strong and Weak Entity Types
●
●
Strong entity type
●
An entity type that is not existence-dependent on some other entity type
●
They have keys that uniquely identify instances
Strong entity type
●
●
●
●
An entity type that is existence-dependent on some other entity type
Weak entities do not have key attributes of their own and so need “help” to
identify them uniquely
They derive their identity from the key attributes of one or more parent (also
called identifying or owner) entities
Identifying relationship
●
21/10/22
Relationship type that relates a weak entity type to its owner
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
60
Strong and Weak Entity Types
●
Example
●
●
21/10/22
There is no primary key for the Preference
entity, hence we cannot identify each
occurrence of the Preference entity type
using only its attributes
We can uniquely identify each preference
only through the relationship that a
preference has with a client who is
uniquely identifiable using the primary key
for the Client entity type, namely clientNo
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
61
Strong and Weak Entity Types
●
Weak entity type
–
●
Normally has a partial key (set of attributes that can uniquely identify
weak entities related to the same owner)
In Chen Notation
●
●
●
21/10/22
Both the weak entity type and its identifying relationship depicted in
ER diagrams with double-bordered rectangle and diamond
respectively
Weak entity type
Normally has a partial key (set of attributes that can uniquely identify
weak entities related to the same owner)
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
62
Strong and Weak Entity Types
●
Example: Modelling books and the chapters they contain
●
●
21/10/22
Chapter ID is a partial key because different books can have
the same chapter ID
However, the combination of BookID and ChaperID is unique
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
63
Strong and Weak Entity Types
●
Weak entity type always has total participation constraint
(existence dependency) wrt the identifying relationship
–
●
Because weak entity type cannot be identified without an
owner entity
Reverse in not true: existence dependency does not
necessarily imply weak entity type
–
21/10/22
E.g., DriverLicense entity cannot exist without the
corresponding Person entity even though it has its own key
(the LicenseNumber)
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
64
Specialization/Generalization
●
Superclasses and Subclasses
●
Specialization and Generalization Processes
●
Diagramatic Representation of Specialization and
Generalization
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
65
Superclasses and Subclasses
●
Each member of a subclass is also a member of the superclass
●
●
Some superclasses may contain overlapping subclasses
●
●
The entity in the subclass is the same entity in the superclass, but has
a distinct role
A member of staff (superclass ) who belongs to both the Manager and
Sales Personnel subclasses
But not every member of a superclass is necessarily a member of
a subclass
●
21/10/22
Example, members of staff without a distinct job role such as a
Manager or Sales Personnel.
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
66
Superclasses and Subclasses
●
●
Superclasses and subclasses help avoid describing
different entity types with possibly different attributes
within a single entity type
Example
●
●
21/10/22
Sales personnel may have special attributes such as
salesArea and carAllowance
If all staff attributes and those specific to particular jobs are
described by a single Staff entity type, this may result in a lot
of nulls for the job-specific attributes
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
67
Illustrating need for superclasses and subclasses
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
68
Superclasses and Subclasses
●
IS-A relationship holds between subclass and superclass
●
A subclass entity is a superclass entity
●
●
A subclass may possess subclass-specific attributes, as well as those
associated with the superclass
●
●
Superclass attributes are inherited
Example
●
●
21/10/22
A postgraduate student (subclass entity) is a student (superclass entity)
A member of the SalesPersonnel subclass inherits all the attributes of the Staff
superclass, such as staffNo, name, position, and salary
Additionally, a SalesPersonnel has those specifically associated with the
SalesPersonnel subclass, such as salesArea and carAllowance
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
69
Specialization and Generalization
●
Specialization
●
●
The process of maximizing the differences between
members of an entity type by identifying their distinguishing
characteristics
Top-down approach
●
●
21/10/22
In the process, subclasses are defined on the basis of some
distinguishing characteristics of the entities in the superclass
We then associate attributes specific to each subclass (where
necessary), and also identify any relationships between each
subclass and other entity types or subclasses (where necessary)
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
70
Specialization and Generalization
●
Generalization
●
●
The process of identifying similarities between entity types,
such as common attributes and relationships
Bottom-up approach
●
21/10/22
In the process, superclasses are identified from entity types
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
71
Diagramatic Representation of Specialization
and Generalization
●
Specialization/generalization of
the Staff entity into subclasses
representing job roles
●
Superclass
●
●
Subclasses
●
●
●
●
Manager
SalesPersonnel
Secretary
Relationships
●
●
21/10/22
Staff
Between Superclass Staff and
Branch
Between Subclass Manager and
Branch
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
72
Diagramatic Representation of Specialization
and Generalization
●
21/10/22
Specialization/
generalization of the
Staff entity into
subclasses
representing job
roles and contracts
of employment
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
73
Diagramatic Representation of Specialization
and Generalization
●
21/10/22
Specialization/generalization
of the Staff entity into job
roles including a shared
subclass called
SalesManager and a
subclass called Secretary
with its own subclass called
AssistantSecretary
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
74
Constraints on Specialization/Generalization
●
Described along two dimensions
–
Participation constraint
●
Determines whether every member in the superclass must participate as a
member of a subclass
–
–
–
Disjoint constraint
●
Describes the relationship between members of the subclasses and indicates
whether it is possible for a member of a superclass to be a member of one, or
more than one, subclass
–
–
21/10/22
complete vs incomplete
i.e., mandatory vs optional
disjoint versus overlapping
i.e., disjoint vs non-disjoint
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
75
Participation Constraint
●
Incomplete specialization
●
Also called a partial or optional specialization
●
Only some individuals of the parent class are specialized
●
Other individuals of the parent class have only the common attributes
●
●
To represent optional participation, “Optional” or “Partial” or “Incomplete” is
placed in curly brackets below the triangle that points towards the superclass
Complete (Mandatory) specialization
●
●
21/10/22
Each individual of the parent class can be placed in a subclass
To represent mandatory participation, “Mandatory” or “Complete” is placed in
curly brackets below the triangle that points towards the superclass
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
76
Disjoint Constraint
●
Disjoint specialization
●
●
●
●
Also called an exclusive specialization
An individual of the parent class may be a member of only one specialized
subclass
To represent a disjoint superclass/subclass relationship, “Or” is placed next to the
participation constraint within the curly brackets
Overlapping (Non-disjoint) specialization
●
An individual of the parent class may be a member of more than one of the
specialized subclasses
●
To represent a nondisjoint superclass/subclass relationship, “And” is placed next to
●
the participation constraint within the curly brackets
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
77
Crows Feet Notation
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
78
Crows Feet Notation
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
79
Chen Notation vs Crows Feet Notation
21/10/22
Denis L. Nkweteyim@UB - IST601 (Database Management - ER Modelling)
80