Database Systems

Arsi University
1

Fundamental of Database
Systems

Target Dept.:- Computer Science

By:Kedir E.
 2

Lecture Three

Database Modelling

Arsi University
 Kedir E.

Outline
3
3.1 The Entity Relationship (ER) Model
3.1.1. The high-level conceptual model
3.1.2. Entities, Attributes, and Keys
3.1.3. Relationships, Associations, and Constraints
3.1.4 The ER diagrams representation
3.1.5. Mapping ER-models to relational tables
3.2. Enhanced Entity Relationship (EER) Model
3.2.1. Inheritance
3.2.2. Union
3.2.3. Aggregation and Association
3.2.4. Mapping EER model to relational model
3.3. The Relational Database Model
3.3.1. The Relational Model Concepts
3.3.2. The Relational Constraints and Relational Database Schemas
3.3.3. The Relational Operations
Arsi University
3.1 The Entity Relationship (ER) Model
4
 An Entity Relationship (ER) Diagram is a type of flowchart that
illustrates how “entities” such as people, objects or concepts relate
to each other within a system.
 ER Diagrams are most often used to design or debug relational
databases in the fields of software engineering, business
information systems, education and research.
 Also known as ERDs or ER Models, they use a defined set of
symbols such as rectangles, diamonds, ovals and connecting lines
to depict the interconnectedness of entities, relationships and their
attributes.
Cont’d…
5
Example: Company Database
6
 We need to create a database schema design based on the following
(simplified) requirements of the COMPANY Database:
 The company is organized into DEPARTMENTs. Each
department has a name, number and an employee who
manages the department. We keep track of the start date of the
department manager. A department may have several locations.
 Each department controls a number of PROJECTs. Each
project has a unique name, unique number and is located at a
single location.
Example: Company Database …
7
 We store each EMPLOYEE’s social security number,
address, salary, sex, and birthdate.
 Each employee works for one department but may work on
several projects.
 We keep track of the number of hours per week that an
employee currently works on each project.
 We also keep track of the direct supervisor of each employee.
 Each employee may have a number of DEPENDENTs.
 For each dependent, we keep track of their name, sex, birthdate,
and relationship to the employee.
 3.1.2. Entities, Attributes and keys
8
 Entities are specific objects or things in the mini-world that
are represented in the database.
 For example the EMPLOYEE John Smith, the Research DEPARTMENT, the ProductX
PROJECT

 Attributes are properties used to describe an entity.

 For example an EMPLOYEE entity may have the attributes Name, SSN, Address, Sex,
BirthDate

 A specific entity will have a value for each of its attributes.

 For example a specific employee entity may have Name='John Smith', SSN='123456789',
Address ='731, Fondren, Houston, TX', Sex='M', BirthDate='09-JAN-55‘
 Each attribute has a value set (or data type) associated with it – e.g. integer, string, subrange,
enumerated type, …
Entity, Attribute and Relationship
9
Entities
10
 Are a real world thing either living or non living that is easily
recognizable and no recognizable.
 It can be a place , person, object, event, or a concept which stores
data in the database .
 The characteristics of entities are must have an attribute and
unique key.

 Example
 Person: employee, student, patient
 Place : store, building
 Object: sale, registration, renewal
 Concepts: account, course
Entities …
11
 An entity set is a set of entities of the same type that share the
same properties, or attributes.
 The set of all persons who are customers at a given bank, for
example, can be defined as the entity set customer
 Entity sets do not need to be disjoint. For example, it is possible to
define the entity Set of all employees of bank (employee) the entity
set of all customers of the bank (customer) a person entity may be
an employee entity ,a customer entity, both, or neither.
Entities …
12
Entity Types
 Entities with the same basic attributes are grouped or typed into an
entity type.
 For example, the entity type EMPLOYEE and PROJECT.

Displaying an Entity Type

 In ER diagrams, an entity type is displayed in a rectangular box.
 See CAR example on next slide
Entities…
13
 Entity Type CAR with two keys and a corresponding Entity Set
Entities...
14
Initial Design of Entity Types for the COMPANY Database Schema
 Based on the requirements, we can identify four initial entity types in
the COMPANY database:
 DEPARTMENT
 PROJECT
 EMPLOYEE
 DEPENDENT
 Their initial design is shown on the following slide
 The initial attributes shown are derived from the requirements
description
Entities…
15
Initial Design of Entity Types: EMPLOYEE, DEPARTMENT,
PROJECT, DEPENDENT
Entities…
16
Weak Entity
 An entity set may not have sufficient attributes to form a primary
key
 An entity that does not have a key attribute
 A weak entity must participate in an identifying relationship type
with an owner or identifying entity type
 Entities are identified by the combination of:
 A partial key of the weak entity type
 The particular entity they are related to in the identifying entity
type
Entities…
 Weak Entity Example:
17
 A DEPENDENT entity is identified by the dependent’s first name, and the
specific EMPLOYEE with whom the dependent is related
 Name of DEPENDENT is the partial key
 DEPENDENT is a weak entity type
 EMPLOYEE is its identifying entity type via the identifying relationship
type DEPENDENT_OF
Attributes
18
 The items of information which characterize and describe
these entities.
 Attributes are pieces of information ABOUT entities
 Attributes are displayed in ovals
 Each attribute is connected to its entity type.
 Components of a composite attribute are connected to the
oval representing the composite attribute
 Each key attribute is underlined
 Multivalued attributes displayed in double ovals
Attributes…
19
 Attributes are properties used to describe an entity.
 For example: an EMPLOYEE entity may have the attributes Name,
SSN, Address, Sex, BirthDate

 A specific entity will have a value for each of its attributes.

 For example a specific employee entity may have Name='John Smith',
SSN='123456789', Address ='731, Fondren, Houston, TX', Sex=‘M',
BirthDate='09-JAN-55‘
Types of Attributes
20
 Simple
 Each entity has a single atomic value for the attribute. For example, SSN or Sex.

 Composite
 The attribute may be composed of several components. For example:
 Address (Apt#, House#, Street, City, State, ZipCode, Country), or
 Name (FirstName, MiddleName, LastName).
 Composition may form a hierarchy where some components are themselves composite.

 Multi-valued
 An entity may have multiple values for that attribute. For example, Color of a CAR or
PreviousDegrees of a STUDENT.
 Denoted as {Color} or {PreviousDegrees}.
Types of Attributes …
21
 In general, composite and multi-valued attributes may be
nested arbitrarily to any number of levels, although this is
rare.
 For example, PreviousDegrees of a STUDENT is a
composite multi-valued attribute denoted by
{PreviousDegrees (College, Year, Degree, Field)}
 Multiple PreviousDegrees values can exist
 Each has four subcomponent attributes:
 College, Year, Degree, Field
Types of Attributes …
22
 Example of Composite attribute
Types of Attributes …
 Stored vs. Derived Attribute 23

 Stored: not possible to derive or compute

 E.g. Name, Address

 Derived: The value may be derived (computed) from the values

of other attributes.
 E.g. G.P.A (grade point/credit hours), age (birth date –current date )
 Null Values
 NULL applies to attributes which are not applicable or which do not have
values. (eg. Middle name )
 You may enter the value NA (meaning not applicable)
 Value of a key attribute cannot be null.
 Default value - assumed value if no explicit value
 Key Attributes
24
 An attribute of an entity type for which each entity
must have a unique value is called a key attribute
of the entity type.
 For example, SSN of EMPLOYEE.
Key Attributes …
25
 A key attribute may be composite.
 VehicleTagNumber is a key of the CAR entity type with
components (Number, State).
 An entity type may have more than one key.
 The CAR entity type may have two keys:
 VehicleIdentificationNumber (popularly called VIN)
 VehicleTagNumber (Number, State), aka license plate number.

 Each key is underlined

3.1.3. Relationships, Associations, and Constraints

26
Relationships and relationship types
 A relationship relates two or more distinct entities with a
specific meaning.
 For example, EMPLOYEE John Smith works on the ProductX PROJECT,
or EMPLOYEE Franklin Wong manages the Research DEPARTMENT.

 Relationships of the same type are grouped or typed into a

relationship type.
 For example, the WORKS_ON relationship type in which EMPLOYEEs
and PROJECTs participate, or the MANAGES relationship type in which
EMPLOYEEs and DEPARTMENTs participate.
Relationships…
27
 The degree of a relationship type is the number of participating
entity types.
 Both MANAGES and WORKS_ON are binary relationships.
 Among the Degrees of relationship, the following are the basic:
 UNARY/RECURSIVE RELATIONSHIP: is a relationship type where the
same entity type participates more than once in a different role

 BINARY RELATIONSHIPS: Tuples/records of two entities are associated in

a relationship

Doctors patient
Relationships…
28
 TERNARY RELATIONSHIP: Tuples/records of three different entities are
associated

 N-NARY RELATIONSHIP: Tuples from arbitrary number of entity sets are

participating in a relationship
Relationship…
 Role indicates the purpose29 that each participating entity
type plays in a relationship.
 (E.g. prerequisite, requester)

 Role can be used when two entities are associated through more than one
relationship to classify the purpose of each relationship.
Relationship…
 Relationship Type: 30

 Is the schema description of a relationship

 Identifies the relationship name and the participating entity
types
 Also identifies certain relationship constraints
 Relationship Set:
 The current set of relationship instances represented in the
database
 The current state of a relationship type
Relationship type vs. relationship set…
31
 Each instance in the set relates individual
participating entities – one from each participating
entity type
 In ER diagrams, we represent the relationship type as
follows:
 Diamond-shaped box is used to display a relationship
type
 Connected to the participating entity types via straight lines
Refining the COMPANY database schema by introducing relationships

32
 By examining the requirements, six relationship types are identified
 All are binary relationships( degree 2)
 Listed below with their participating entity types:
 WORKS_FOR (between EMPLOYEE, DEPARTMENT)
 MANAGES (also between EMPLOYEE, DEPARTMENT)
 CONTROLS (between DEPARTMENT, PROJECT)
 WORKS_ON (between EMPLOYEE, PROJECT)
 SUPERVISION (between EMPLOYEE (as subordinate),
EMPLOYEE (as supervisor))
 DEPENDENTS_OF (between EMPLOYEE, DEPENDENT)
Discussion on Relationship Types
 In the refined design, some 33attributes from the initial
entity types are refined into relationships:
 Manager of DEPARTMENT -> MANAGES
 Works_on of EMPLOYEE -> WORKS_ON
 Department of EMPLOYEE -> WORKS_FOR
 etc
 In general, more than one relationship type can exist
between the same participating entity types
 MANAGES and WORKS_FOR are distinct relationship types
between EMPLOYEE and DEPARTMENT
 Different meanings and different relationship instances.
Recursive Relationship Type
 The same entity participates 34
in a relationship set more
than once then it is called recursive relationship set.
 An relationship type whose with the same participating
entity type in distinct roles
 Example: the SUPERVISION relationship
 EMPLOYEE participates twice in two distinct roles:
 supervisor (or boss) role
 supervisee (or subordinate) role
 Each relationship instance relates two distinct EMPLOYEE entities:
 One employee in supervisor role
 One employee in supervisee role
Constraints on Relationships
35
 Constraints on Relationship Types
 (Also known as ratio constraints)
 Cardinality Ratio (specifies maximum participation)
 One-to-one (1:1)
 One-to-many (1:N) or Many-to-one (N:1)
 Many-to-many (M:N)
 Existence Dependency Constraint (specifies minimum
participation) (also called participation constraint)
 zero (optional participation, not existence-dependent)

Constraints on Relationships …
 One-to-one (1:1): 36
one tuple is associated with only one
other tuple.

 E.g. Building – Location

 As a single building will be located in a single location and as a single
location will only accommodate a single Building
Constraints on Relationships …
 One – to – many (1:N):
37 one tuple can be associated with
many other tuples, but not the reverse

 E.g. staff-doctors (As one staff can have multiple doctors .

Constraints on Relationships …
 Many-to-one (N:1): many
38 tuples are associated with one
tuple but not the reverse.

 E.g. patient – Doctors: (many Patients are examined by

one doctor )
Constraints on Relationships …
 Many – to – many (M:N):
39 one tuple is associated with
many other tuples and from the other side, with a different role
name one tuple will be associated with many tuples,

 E.g. medicines – patients (many medicines can be taken by many

patients.)
Constraints on Relationships …
40
Recursive Relationship Type is: SUPERVISION
(participation role names are shown)

41
Attributes of Relationship types
42
 A relationship type can have attributes:
 For example, HoursPerWeek of WORKS_ON
 Its value for each relationship instance describes the
number of hours per week that an EMPLOYEE works on a
PROJECT.
 A value of HoursPerWeek depends on a particular
(employee, project) combination
 Most relationship attributes are used with M:N relationships
 In 1:N relationships, they can be transferred to the entity
type on the N-side of the relationship
Alternative diagrammatic notation
43
 ER diagrams is one popular example for
displaying database schemas
 Many other notations exist in the literature and in
various database design and modeling tools
 Appendix A illustrates some of the alternative
notations that have been used
 UML class diagrams is representative of another way
of displaying ER concepts that is used in several
commercial design tools
Summary of notation for ER diagrams
44
UML class diagrams
45
 Represent classes (similar to entity types) as large rounded
boxes with three sections:
 Top section includes entity type (class) name
 Second section includes attributes
 Third section includes class operations (operations are not in basic
ER model)
 Relationships (called associations) represented as lines
connecting the classes
 Other UML terminology also differs from ER terminology
 Used in database design and object-oriented software design
UML class diagram for COMPANY database schema

46
Other alternative diagrammatic notations
47
Data Modelling Tools
48
 A number of popular tools that cover conceptual modeling and
mapping into relational schema design.
 Examples: ERWin, S- Designer (Enterprise Application Suite), ER-
Studio, etc.
 POSITIVES:
 Serves as documentation of application requirements, easy user
interface - mostly graphics editor support
 NEGATIVES:
 Most tools lack a proper distinct notation for relationships with
relationship attributes
 Mostly represent a relational design in a diagrammatic form rather
than a conceptual ER-based design
 3.1.4. Entity - Relation Diagram Representation

49
 E-R diagram can express the overall logical structure of a database
graphically.
 E-R diagrams are simple and clear-qualities that may well account
in large part for the widespread use of the E-R model.
Steps to create ER Diagram
Cont’d…
50
Cont’d…
51
Cont’d…
52
E-R diagram with composite, multivalued, and derived
attributes.
Cont’d…
53
Simple ER diagram
Cont’d…
Ex2: ER diagram for music54database
Cont’d…
55
Ex3: ER diagram for University database
Cont’d…
Ex4: ER diagram for Flight56database
Cont’d…
57
Exercise 1: Build an ER diagram for the following
information

 A student record management system will have the following

two basic data object categories with their own features or
properties:

 Students will have an Id, Name, Dept, Age, GPA and

 Course will have an Id, Name, Credit Hours

 Whenever a student enroll in a course in a specific Academic

Year and Semester, the Student will have a grade for the course \
Cont’d…
58
Solution
Cont’d…
59
Exercise 2: Build an ER diagram for the following
information
 “A football club has a name and a ground and is made up of
players.
 A player can play for only one club and a manager, represented by
his name manages a club.
 A footballer has a registration number, name and age.
 A club manager also buys players.
 Each club plays against each other club in the league and matches
have a date, venue and score.”
Cont’d…
60
Solution
3.1.5. Mapping ER Model to Relation Table
61
Three basic rules to convert ER into tables or relations
 Rule 1: Entity Names will be automatically be table name.
 Rule 2: Mapping of attributes: attributes will be columns of the
respective tables.
• Atomic or single-valued or derived or stored attributes will be column.
• Composite attributes: the parent attribute will be ignored and the
decomposed attributes (child attributes) will be columns of the table.
• Multi-valued attributes: will be mapped to a new table where the primary key
of the main table will be posted for cross referencing.

 Rule 3: Mapping of relationships: relationship will be mapped by

using a foreign key attribute. Foreign key is a primary or candidate
key of one relation used to create association between tables.
Cont’d…
62
A. For a relationship with one-to-one cardinality:
 Post the primary key or candidate key of the table into the other as a
foreign key.
 In case where one entity is having partial participation on the
relationship, it is recommended to post the candidate key of the
partial participants to the total participants so as to save memory
location due to null values on the foreign key attribute.
Cont’d…
63

B. For a relationship with one-to-many cardinality:

 Post the primary key or candidate key from the –one side as a
foreign key attribute to the –many side..

 Example: for a relationship called –Belongs To between Employee

(Many) and Department (one) the primary or candidate key of the
one side, which is Department, should be posted to the many side,
which is Employee table.
Cont’d…
64

C. For a relationship with Many-to-many cardinality:

 For a relationships having Many-to-many cardinality, one has to
create a new table and Post the primary key or candidate key from
the participant entity as a foreign key attribute in the new table
along with some additional attributes (if applicable)
Example: convert the following ER diagram to relational table

65
Soln:
Mapping Employee entity 66

 There will be Employee table with Fname, Minit, Lname, SSN,

Bdate, Address, Sex and Salary being the columns.
 The composite attribute Name will be ignored.
 the Telephone attribute will be a new table as it is multi-valued.
Soln:
Mapping Department entity 67
 There will be Department table with Dname, Dnumber, and
Dlocation (is multi valued)
Soln:
Mapping Project entity 68

 There will be Project table with Pnumber, Pname, and dnum

being the columns

 Mapping Dependent entity

Solution: Final Converted relational table
69
3.2. Extended ER Diagram
70
3.2.1. sub class, super class and Inheritance

Subclasses and Super classes

71

 An entity type may have additional meaningful subgroupings

of its entities
 Example: EMPLOYEE may be further grouped into:
 SECRETARY, ENGINEER, TECHNICIAN, …
 Based on the EMPLOYEE’s Job
 MANAGER
 EMPLOYEEs who are managers
 SALARIED_EMPLOYEE, HOURLY_EMPLOYEE
 Based on the EMPLOYEE’s method of pay

 EER diagrams extend ER diagrams to represent these

Cont’d…
72
Cont’d…
73
 Each of these subgroupings is a subset of EMPLOYEE entities
 Each is called a subclass of EMPLOYEE
 EMPLOYEE is the superclass for each of these subclasses
 These are called superclass/subclass relationships:
 EMPLOYEE/SECRETARY
 EMPLOYEE/TECHNICIAN
 EMPLOYEE/MANAGER
 …
Cont’d…
74
 These are also called IS-A relationships
 SECRETARY IS-A EMPLOYEE, TECHNICIAN IS-A
EMPLOYEE, ….
 Note: An entity that is member of a subclass represents the same
real-world entity as some member of the superclass:
 The subclass member is the same entity in a distinct specific role
 An entity cannot exist in the database merely by being a member of a
subclass; it must also be a member of the superclass
 A member of the superclass can be optionally included as a member
of any number of its subclasses
Cont’d…
 Examples: 75

 A salaried employee who is also an engineer belongs to the

two subclasses:
 ENGINEER, and
 SALARIED_EMPLOYEE
 A salaried employee who is also an engineering manager
belongs to the three subclasses:
 MANAGER,
 ENGINEER, and
 SALARIED_EMPLOYEE
 It is not necessary that every entity in a superclass be a
member of some subclass
Attribute Inheritance in Superclass / Subclass
Relationships
76
 An entity that is member of a subclass inherits
 All attributes of the entity as a member of the superclass
 All relationships of the entity as a member of the
superclass
 Example:
 In the previous slide, SECRETARY (as well as
TECHNICIAN and ENGINEER) inherit the attributes
Name, SSN, …, from EMPLOYEE
 Every SECRETARY entity will have values for the
inherited attributes
3.2.2. Union
77
Categories (UNION TYPES)
 All of the superclass/subclass relationships we have seen

thus far have a single superclass

 A shared subclass is a subclass in:

 more than one distinct superclass/subclass relationships

 each relationships has a single superclass
 shared subclass leads to multiple inheritance
 In some cases, we need to model a single
superclass/subclass relationship with more than one
superclass
 Superclasses can represent different entity types
 Such a subclass is called a category or UNION TYPE
Cont’d…
78
 Example: In a database for vehicle registration, a vehicle
owner can be a PERSON, a BANK (holding a lien on a
vehicle) or a COMPANY.
 A category (UNION type) called OWNER is created to
represent a subset of the union of the three superclasses
COMPANY, BANK, and PERSON
 A category member must exist in at least one of its
superclasses
 Difference from shared subclass, which is a:
 subset of the intersection of its superclasses
 shared subclass member must exist in all of its superclasses
Two categories (UNION types): OWNER,
REGISTERED_VEHICLE
79
3.2.3. Specialization and Generalization
80

Specialization
 Specialization is the process of defining a set of
subclasses of a superclass
 The set of subclasses is based upon some distinguishing
characteristics of the entities in the superclass
 Example: {SECRETARY, ENGINEER, TECHNICIAN} is
a specialization of EMPLOYEE based upon job type.
 May have several specializations of the same superclass
Specialization …
81
 Example: Another specialization of EMPLOYEE based on method
of pay is {SALARIED_EMPLOYEE, HOURLY_EMPLOYEE}.
 Superclass/subclass relationships and specialization can be
diagrammatically represented in EER diagrams
 Attributes of a subclass are called specific or local attributes.
 For example, the attribute TypingSpeed of SECRETARY
 The subclass can also participate in specific relationship types.
 For example, a relationship BELONGS_TO of HOURLY_EMPLOYEE
Specialization …
82
Generalization
83
 Generalization is the reverse of the specialization process
 Several classes with common features are generalized into a
superclass;
 original classes become its subclasses
 Example: CAR, TRUCK generalized into VEHICLE;
 both CAR, TRUCK become subclasses of the superclass VEHICLE.
 We can view {CAR, TRUCK} as a specialization of VEHICLE
 Alternatively, we can view VEHICLE as a generalization of CAR and
TRUCK
Generalization …
84
Generalization and Specialization
85
 Diagrammatic notation are sometimes used to distinguish
between generalization and specialization
 Arrow pointing to the generalized superclass represents a
generalization
 Arrows pointing to the specialized subclasses represent a
specialization
 We do not use this notation because it is often subjective as
to which process is more appropriate for a particular
situation
Generalization and Specialization …
86
 Data Modeling with Specialization and
Generalization
 A superclass or subclass represents a collection (or
set or grouping) of entities
 It also represents a particular type of entity
 Shown in rectangles in EER diagrams (as are entity
types)
 We can call all entity types (and their corresponding
collections) classes, whether they are entity types,
superclasses, or subclasses
Constraints on Specialization and Generalization
87
 If we can determine exactly those entities that will
become members of each subclass by a condition,
the subclasses are called predicate-defined (or
condition-defined) subclasses
 Condition is a constraint that determines subclass
members
 Display a predicate-defined subclass by writing the
predicate condition next to the line attaching the
subclass to its superclass
Constraints on Specialization and Generalization
… 88
 If all subclasses in a specialization have membership
condition on same attribute of the superclass, specialization
is called an attribute-defined specialization
 Attribute is called the defining attribute of the specialization
 Example: JobType is the defining attribute of the specialization
{SECRETARY, TECHNICIAN, ENGINEER} of EMPLOYEE
 If no condition determines membership, the subclass is
called user-defined
 Membership in a subclass is determined by the database users
by applying an operation to add an entity to the subclass
 Membership in the subclass is specified individually for each
entity in the superclass by the user
Displaying an attribute-defined specialization in
EER diagrams 89
Constraints on Specialization and Generalization
90

 Two basic constraints can apply to a

specialization/generalization:
 Disjointness Constraint:
 Completeness Constraint:
Constraints on Specialization and Generalization
… 91
 Disjointness Constraint:
 Specifies that the subclasses of the specialization
must be disjoint:
 an entity can be a member of at most one of the
subclasses of the specialization
 Specified by d in EER diagram
 If not disjoint, specialization is overlapping:
 that is the same entity may be a member of more than
one subclass of the specialization
 Specified by o in EER diagram
Constraints on Specialization and Generalization
… 92
 Completeness Constraint:
 Total specifies that every entity in the superclass
must be a member of some subclass in the
specialization/generalization
 Shown in EER diagrams by a double line
 Partial allows an entity not to belong to any of the
subclasses
 Shown in EER diagrams by a single line
Constraints on Specialization and Generalization
… 93

 Hence, we have four types of

specialization/generalization:
 Disjoint, total
 Disjoint, partial
 Overlapping, total
 Overlapping, partial
 Note: Generalization usually is total because the
superclass is derived from the subclasses.
Example of disjoint partial Specialization
94
Example of overlapping total Specialization
95
 Specialization/Generalization Hierarchies,
Lattices & Shared
96
Subclasses
 A subclass may itself have further subclasses
specified on it
 forms a hierarchy or a lattice
 Hierarchy has a constraint that every subclass has
only one superclass (called single inheritance); this
is basically a tree structure
 In a lattice, a subclass can be subclass of more
than one superclass (called multiple inheritance)
Shared Subclass “Engineering_Manager”
97
 Specialization/Generalization Hierarchies,
Lattices & Shared
98
Subclasses …
 In a lattice or hierarchy, a subclass inherits attributes not
only of its direct superclass, but also of all its predecessor
superclasses
 A subclass with more than one superclass is called a
shared subclass (multiple inheritance)
 Can have:
 specialization hierarchies or lattices, or
 generalization hierarchies or lattices,
 depending on how they were derived
 We just use specialization (to stand for the end result of
either specialization or generalization)
Specialization / Generalization Lattice Example
(UNIVERSITY)
99
 Formal Definitions of EER Model
100
 Class C:
 A type of entity with a corresponding set of entities:
 could be entity type, subclass, superclass, or category
 Note: The definition of relationship type in ER/EER should
have 'entity type' replaced with 'class‘ to allow relationships
among classes in general
 Subclass S is a class whose:
 Type inherits all the attributes and relationship of a class C
 Set of entities must always be a subset of the set of entities of the
other class C
 S⊆C
 C is called the superclass of S
 A superclass/subclass relationship exists between S and C
 Formal Definitions of EER Model …
 Specialization Z: Z = {S1,101S2,…, Sn} is a set of
subclasses with same superclass G; hence, G/Si is
a superclass relationship for i = 1, …., n.
 G is called a generalization of the subclasses {S1,
S2,…, Sn}
 Z is total if we always have:
 S1 ∪ S2 ∪ … ∪ Sn = G;
 Otherwise, Z is partial.
 Z is disjoint if we always have:
 Si ∩ S2 empty-set for i ≠ j;
 Otherwise, Z is overlapping
 Formal Definitions of EER Model …
102
 Subclass S of C is predicate defined if predicate (condition)
p on attributes of C is used to specify membership in S;
 that is, S = C[p], where C[p] is the set of entities in C that satisfy
condition p
 A subclass not defined by a predicate is called user-defined
 Attribute-defined specialization: if a predicate A = ci (where A
is an attribute of G and ci is a constant value from the domain
of A) is used to specify membership in each subclass Si in Z
 Note: If ci ≠ cj for i ≠ j, and A is single-valued, then the attribute-
defined specialization will be disjoint.
 Formal Definitions of EER Model …
103
 Category or UNION type T
 A class that is a subset of the union of n defining
superclasses
D1, D2,…Dn, n>1:
 T ⊆ (D1 ∪ D2 ∪ … ∪ Dn)
 Can have a predicate pi on the attributes of Di to
specify entities of Di that are members of T.
 If a predicate is specified on every Di: T = (D1[p1] ∪
D2[p2] ∪…∪ Dn[pn])
 Alternative diagrammatic notations
104
 ER/EER diagrams are a specific notation for
displaying the concepts of the model
diagrammatically
 DB design tools use many alternative notations for
the same or similar concepts
 One popular alternative notation uses UML class
diagrams
 see next slides for UML class diagrams and other
alternative notations
UML Example for Displaying Specialization /
Generalization
105
Alternative Diagrammatic Notations
106
 General Conceptual Modelling Concepts
107
 GENERAL DATA ABSTRACTIONS
 CLASSIFICATION and INSTANTIATION
 AGGREGATION and ASSOCIATION (relationships)
 GENERALIZATION and SPECIALIZATION
 IDENTIFICATION
 CONSTRAINTS
 CARDINALITY (Min and Max)
 COVERAGE (Total vs. Partial, and Exclusive (disjoint)
vs. Overlapping)
 Ontologies
 Use conceptual modeling108and other tools to develop
“a specification of a conceptualization”
 Specification refers to the language and vocabulary
(data model concepts) used
 Conceptualization refers to the description (schema)
of the concepts of a particular field of knowledge and
the relationships among these concepts
 Many medical, scientific, and engineering ontologies
are being developed as a means of standardizing
concepts and terminology
 3.3. The Relational Database Model
109
 3.3.1. Relational Model Concepts
 The relational Model of Data is based on the concept of a
Relation
 The strength of the relational approach to data management

comes from the formal foundation provided by the theory

of relations
 In practice, there is a standard model based on SQL – this is
described in last chapter
Relational Model Concept…
110
 A Relation is a mathematical concept based on the ideas
of sets
 The model was first proposed by Dr. E.F. Codd of IBM
Research in 1970 in the following paper:
 "A Relational Model for Large Shared Data Banks,"
Communications of the ACM, June 1970
 The above paper caused a major revolution in the field of
database management and earned Dr. Codd the coveted
ACM Turing Award
Informal Definitions
111
 Informally, a relation looks like a table of values.
 A relation typically contains a set of rows.
 The data elements in each row represent certain facts that correspond
to a real-world entity or relationship
 In the formal model, rows are called tuples
 Each column has a column header that gives an indication of the
meaning of the data items in that column
 In the formal model, the column header is called an attribute name (or
just attribute)
Example of a Relation
112
Informal Definitions …
113
 Key of a Relation:
 Each row has a value of a data item (or set of items)
that uniquely identifies that row in the table
 Called the key
 In the STUDENT table, SSN is the key

 Sometimes row-ids or sequential numbers are assigned

as keys to identify the rows in a table
 Called artificial key or surrogate key
Informal Definitions - Schema
 The Schema (or description)114
of a Relation:
 Denoted by R(A1, A2, .....An)
 R is the name of the relation
 The attributes of the relation are A1, A2, ..., An

 Example:
CUSTOMER (Cust-id, Cust-name, Address, Phone#)
 CUSTOMER is the relation name
 Defined over the four attributes: Cust-id, Cust-name, Address,
Phone#
 Each attribute has a domain or a set of valid values.
 For example, the domain of Cust-id is 6 digit numbers.
Informal Definitions - Tuple
115
 A tuple is an ordered set of values (enclosed in angled
brackets ‘< … >’)
 Each value is derived from an appropriate domain.
 A row in the CUSTOMER relation is a 4-tuple and would
consist of four values, for example:
 <632895, "John Smith", "101 Main St. Atlanta, GA 30332",
"(404) 894-2000">
 This is called a 4-tuple as it has 4 values
 A tuple (row) in the CUSTOMER relation.
 A relation is a set of such tuples (rows)
Informal Definitions - Domain
116
 A domain has a logical definition:
 Example: “USA_phone_numbers” are the set of 10 digit phone
numbers valid in the U.S.
 A domain also has a data-type or a format defined for it.
 The USA_phone_numbers may have a format: (ddd)ddd-dddd where
each d is a decimal digit.
 Dates have various formats such as year, month, date
formatted as yyyy-mm-dd, or as dd mm,yyyy etc.

 The attribute name designates the role played by a domain in

a relation:
 Used to interpret the meaning of the data elements

corresponding to that attribute

 Example: The domain Date may be used to define two attributes
named “Invoice-date” and “Payment-date” with different meanings
Informal Definitions - State
117
 The relation state is a subset of the Cartesian
product of the domains of its attributes
 each domain contains the set of all possible values
the attribute can take.
 Example: attribute Cust-name is defined over the
domain of character strings of maximum length 25
 dom(Cust-name) is varchar(25)
 The role these strings play in the CUSTOMER
relation is that of the name of a customer.
Informal Definitions - Summary
118
 Formally,
 Given R(A1, A2, .........., An)
 r(R)  dom (A1) X dom (A2) X ....X dom(An)
 R(A1, A2, …, An) is the schema of the relation
 R is the name of the relation
 A1, A2, …, An are the attributes of the relation
 r(R): a specific state (or "value" or “population”) of relation R
– this is a set of tuples (rows)
 r(R) = {t1, t2, …, tn} where each ti is an n-tuple
 ti = <v1, v2, …, vn> where each vj element-of dom(Aj)
Informal Definitions - Example
119
 Let R(A1, A2) be a relation schema:
 Let dom(A1) = {0,1}
 Let dom(A2) = {a,b,c}
 Then: dom(A1) X dom(A2) is all possible combinations:
{<0,a> , <0,b> , <0,c>, <1,a>, <1,b>, <1,c> }

 The relation state r(R)  dom(A1) X dom(A2)

 For example: r(R) could be {<0,a> , <0,b> , <1,c> }
 this is one possible state (or “population” or “extension”) r of the
relation R, defined over A1 and A2.
 It has three 2-tuples: <0,a> , <0,b> , <1,c>
Definitions Summary
120
Example – A relation STUDENT
121
Characteristics of Relations
122
 Ordering of tuples in a relation r(R):
 The tuples are not considered to be ordered,

even though they appear to be in the tabular

form.
 Ordering of attributes in a relation schema R (and of
values within each tuple):
 We will consider the attributes in R(A1, A2, ..., An)

and the values in t=<v1, v2, ..., vn> to be

ordered .
 (However, a more general alternative definition of
relation does not require this ordering).
Same state as previous Figure (but with different order of tuples)

123
Characteristics Of Relations
124
 Values in a tuple:
 All values are considered atomic (indivisible).
 Each value in a tuple must be from the domain of the
attribute for that column
 If tuple t = <v1, v2, …, vn> is a tuple (row) in the
relation state r of R(A1, A2, …, An)
 Then each vi must be a value from dom(Ai)

 A special null value is used to represent values that

are unknown or inapplicable to certain tuples.
Characteristics Of Relations …
125
 Notation:
 We refer to component values of a tuple t by:
 t[Ai] or t.Ai
 This is the value vi of attribute Ai for tuple t
 Similarly, t[Au, Av, ..., Aw] refers to the subtuple of t
containing the values of attributes Au, Av, ..., Aw,
respectively in t
Relational Integrity Constraints
126
 Constraints are conditions that must hold on all valid
relation states.
 There are three main types of constraints in the relational
model:
 Key constraints
 Entity integrity constraints
 Referential integrity constraints
 Another implicit constraint is the domain constraint
 Every value in a tuple must be from the domain of its attribute
(or it could be null, if allowed for that attribute)
 Kedir E.(MSc)

127

End of Chapter Three