CSE202 Database Management Systems

Lecture #4

Prepared & Presented by Asst. Prof. Dr. Samsun M. BAŞARICI

 Learning Objectives
 Apply high-level conceptual data modeling
 Creating a sample database
 Understand and apply DB terms
 Differentiate between ER and UML notations

2
 Outline
 Using high-level conceptual data models for database design
 A sample database application
 Entity types, entity sets, attributes, and keys
 Relationship types, relationship sets, roles, and structural
constraints
 Weak entity types
 Refining the ER design for the COMPANY database
 ER diagrams, naming conventions, and design issues
 Example of other Notation: UML class diagrams
 Relationship types of degree higher than two

3
Data Modeling Using the Entity-Relationship (ER) Model

 Entity-Relationship (ER) model

Popular high-level conceptual data model
 ER diagrams
Diagrammatic notation associated with the ER model
 Unified Modeling Language (UML)
 Using High-Level Conceptual Data Models for
Database Design

 Requirements collection and analysis

Database designers interview prospective database users to
understand and document data requirements
Result: data requirements
Functional requirements of the application
Using High-Level Conceptual Data Models (cont’d.)

 Conceptual schema
Conceptual design
Description of data requirements
Includes detailed descriptions of the entity types,
relationships, and constraints
Transformed from high-level data model into
implementation data model
Using High-Level Conceptual Data Models (cont.)

 Logical design or data model mapping

Result is a database schema in implementation data model
of DBMS
 Physical design phase
Internal storage structures, file organizations, indexes,
access paths, and physical design parameters for the
database files specified
 A Sample Database Application

 COMPANY
Employees, departments, and projects
Company is organized into departments
Department controls a number of projects
Employee: store each employee’s name, Social Security
number, address, salary, sex (gender), and birth date
Keep track of the dependents of each employee
Entity Types, Entity Sets, Attributes, and Keys

 ER model describes data as:

Entities
Relationships
Attributes
 Entities and Attributes

 Entity
Thing in real world with independent existence
 Attributes
Particular properties that describe entity
Types of attributes:
 Composite versus simple (atomic) attributes
 Single-valued versus multivalued attributes
 Stored versus derived attributes
 NULL values
 Complex attributes
Entities and Attributes (cont.)
Entity Types, Entity Sets, Keys, and Value Sets

 Entity type
Collection (or set) of entities that have the same attributes
Entity Types, Entity Sets, Keys, and Value Sets (cont.)

 Key or uniqueness constraint

Attributes whose values are distinct for each individual
entity in entity set
Key attribute
 Uniqueness property must hold for every entity set of the entity
type
 Value sets (or domain of values)
Specifies set of values that may be assigned to that attribute
for each individual entity
Initial Conceptual Design of the COMPANY Database
Relationship Types, Relationship Sets, Roles, and
Structural Constraints

 Relationship
When an attribute of one entity type refers to another entity
type
Represent references as relationships not attributes
 Relationship Types, Sets, and Instances

 Relationship type R among n entity types E1, E2, ..., En

Defines a set of associations among entities from these
entity types
 Relationship instances ri
Each ri associates n individual entities (e1, e2, ..., en)
Each entity ej in ri is a member of entity set Ej
 Relationship Degree

 Degree of a relationship type

Number of participating entity types
Binary, ternary
 Relationships as attributes
Think of a binary relationship type in terms of attributes
 Role Names and Recursive Relationships

 Role names and recursive relationships

Role name signifies role that a participating entity plays in
each relationship instance
 Recursive relationships
Same entity type participates more than once in a
relationship type in different roles
Must specify role name
 Constraints on Binary Relationship Types

 Cardinality ratio for a binary relationship

Specifies maximum number of relationship instances that
entity can participate in
 Participation constraint
Specifies whether existence of entity depends on its being
related to another entity
Types: total and partial
 Attributes of Relationship Types

 Attributes of 1:1 or 1:N relationship types can be migrated

to one entity type
 For a 1:N relationship type
Relationship attribute can be migrated only to entity type on
N-side of relationship
 For M:N relationship types
Some attributes may be determined by combination of
participating entities
Must be specified as relationship attributes
 Weak Entity Types

 Do not have key attributes of their own

Identified by being related to specific entities from another
entity type
 Identifying relationship
Relates a weak entity type to its owner
 Always has a total participation constraint
Refining the ER Design for the COMPANY Database

 Change attributes that represent relationships into

relationship types
 Determine cardinality ratio and participation constraint of
each relationship type
ER Diagrams, Naming Conventions, and Design Issues
 Proper Naming of Schema Constructs

 Choose names that convey meanings attached to different

constructs in schema
 Nouns give rise to entity type names
 Verbs indicate names of relationship types
 Choose binary relationship names to make ER diagram
readable from left to right and from top to bottom
 Design Choices for ER Conceptual Design

 Model concept first as an attribute

Refined into a relationship if attribute is a reference to
another entity type
 Attribute that exists in several entity types may be
elevated to an independent entity type
Can also be applied in the inverse
 Alternative Notations for ER Diagrams

 Specify structural constraints on relationships

Replaces cardinality ratio (1:1, 1:N, M:N) and single/double
line notation for participation constraints
Associate a pair of integer numbers (min, max) with each
participation of an entity type E in a relationship type R,
where 0 ≤ min ≤ max and max ≥ 1
 Additional Material
Enhanced Entity-Relationship (EER)
Model

31
 Chapter 8 (Elmasri) Outline

 Subclasses, Superclasses, and Inheritance

 Specialization and Generalization
 Constraints and Characteristics of Specialization and
Generalization Hierarchies
 Modeling of UNION Types Using Categories
 A Sample UNIVERSITY EER Schema, Design Choices, and
Formal Definitions
 Example of Other Notation: Representing Specialization and
Generalization in UML
Class Diagrams
 Data Abstraction, Knowledge Representation, and Ontology
Concepts
The Enhanced Entity-Relationship (EER) Model

 Enhanced ER (EER) model

Created to design more accurate database schemas
 Reflect the data properties and constraints more precisely
More complex requirements than traditional applications
 Subclasses, Superclasses, and Inheritance

 EER model includes all modeling concepts of the ER

model
 In addition, EER includes:
Subclasses and superclasses
Specialization and generalization
Category or union type
Attribute and relationship inheritance
Subclasses, Superclasses, and Inheritance (cont.)

 Enhanced ER or EER diagrams

Diagrammatic technique for displaying these concepts in an
EER schema
 Subtype or subclass of an entity type
Subgroupings of entities that are meaningful
Represented explicitly because of their significance to the
database application
Subclasses, Superclasses, and Inheritance (cont.)

 Terms for relationship between a superclass and any one

of its subclasses
Superclass/subclass
Supertype/subtype
Class/subclass relationship
 Type inheritance
Subclass entity inherits all attributes and relationships of
superclass
 Specialization and Generalization

 Specialization
Process of defining a set of subclasses of an entity type
Defined on the basis of some distinguishing characteristic
of the entities in the superclass
 Subclass can define:
Specific attributes
Specific relationship types
 Generalization

 Reverse process of abstraction

 Generalize into a single superclass
Original entity types are special subclasses
 Generalization
Process of defining a generalized entity type from the given
entity types
Constraints on Specialization and Generalization (cont.)

 Disjointness constraint
Specifies that the subclasses of the specialization must be
disjoint
 Completeness (or totalness) constraint
May be total or partial
 Disjointness and completeness constraints are independent
 Specialization and Generalization Hierarchies
and Lattices

 Specialization hierarchy
Every subclass participates as a subclass in only one
class/subclass relationship
Results in a tree structure or strict hierarchy
 Specialization lattice
Subclass can be a subclass in more than one class/subclass
relationship
Modeling of UNION Types Using Categories

 Union type or a category

Represents a single superclass/subclass relationship with
more than one superclass
Subclass represents a collection of objects that is a subset of
the UNION of distinct entity types
Attribute inheritance works more selectively
Category can be total or partial
 Some modeling methodologies do not have union types
A Sample UNIVERSITY EER Schema, Design
Choices, and Formal Definitions

 The UNIVERSITY Database Example

UNIVERSITY database
 Students and their majors
 Transcripts, and registration
 University’s course offerings
Formal Definitions for the EER Model Concepts

 Class
Set or collection of entities
Includes any of the EER schema constructs of group entities
 Subclass
Class whose entities must always be a subset of the entities
in another class
 Specialization
Set of subclasses that have same superclass
Formal Definitions for the EER Model Concepts (cont.)

 Generalization
Generalized entity type or superclass
Formal Definitions for the EER Model Concepts (cont.)

 Category
Class that is a subset of the union of n defining superclasses
 Relationship type
Any class can participate in a relationship