04 Ch4 HighLevelDatabaseModels

INTRODUCTION
TO
DATABASE
L E A R N B Y E X A M P L E S
HIGH LEVEL
DATABASE MODEL
Objectives
 Understand concepts of:

I2DB: Design Theory for Relational Databases
 The database design process
 Conceptual, logical design
 Entity relationship diagram

Database Design Process
Relational
Getting
High-Level Database Relational
User
Design Schema DBMS
Requirement
Design
ER diagram Relational Database Schema

Figure 4.1: The database modeling and implementation process

 High-level design describes exactly the information needs

of the business
 Logical design is process of constructing a model of
information used in an enterprise based on a specific data
model, but independent of a particular DBMS or other
physical considerations
 Physical design is process translating the logical
description of the data into technical specifications for
storing and retrieving data
 Several options for high level design

 The first and oldest method is the Entity Relationship
Model
 A more recent trend is Unified Modeling Language
4.1 The Entity Relationship Model
 Represent the structure of data

 Not include the operations on data

 Principle components
 Entity sets
 Attributes
 Relationships
 There are many notation to represent the

components. Chen notation is a first choice
Comparison of E-R Modeling
notations
8
The Entity Relationship Diagrams
name address
title year
Stars Stars-in
name Movies
Studios Owns length genre
address
Figure 4.2: An entity relationship diagram for the movie database
Multiplicity of Binary E/R
Relationships
 A binary relationship can connect any member of one of its entity sets to any
number of members of the other entity set

 Suppose R is a relationship connecting entity sets E and F
• Each entity in E can be connected by R to at most one entity in F, and each entity in F can be
connected to many entities in E, then R is many-one from E to F
• Similarity, if an entity of F can be connected by R to at most one entity in E, then R is many-one
from F to E (equivalently, one-many from E to F)
• Show a many-one relationship by an arrow pointing to the one side
 If R is both many-one from E to F and many-one from F to E, then we say that R
is one-one
• Show a one-one relationship by an arrows entering both entity sets
 If R is neither many-one from E to F or from F to E , then we say R is many-many
Multiplicity of Binary E/R
Relationships
• Example: many-one, one-one and many-many

relationships
Movies Owns Studios
Studios Runs Presidents
Stars Stars-in Movies

Multi-way Relationships
Stars Contracts Movies
Studios
Roles in Relationships
 Consider a relationship Sequel-of between the

entity set Movies and itself
Original
Sequel-of Movies
Sequel
Roles in Relationships
 Consider the Contracts relationship involves two

studios, a star, a movie
Studio Producing
of star studio
Studios
Attributes on Relationships
 Consider the contracts between a star and studio

for a movie. We wish to record the salary

associated with this contract. How can we do
that?
name address title year

Salary
length genre
Studios
name address
Salary
name address Salaries title year
length genre
Studios
name address
Converting Multi-way
Relationships to Binary
 Consider the Contracts relationship involves two

studios, a star, a movie
Studio Producing
of star studio
Studios
Converting Multi-way
Relationships to Binary
 Consider the Contracts relationship involves two studios, a star, a movie

Studio Producing
of star Studios studio
Stars Movies
Star-of Contracts Movie-of
Studio Producing
of star studio
Studios
Subclasses in E/R Model
 Consider Cartoons and Murder Mysteries are the

special kinds of movies, with some special

properties
to Stars length title year genre
Voices Movies
isa isa weapon
Murder
Cartoons
Mysteries
Summary 4.1
 Entity Sets
 Attributes
 Relationships
 E/R Diagrams
 Roles in Relationships
 Subclasses in the E/R Model
DESIGN PRINCIPLES
Faithfulness
 The design should be faithful to the specifications

of the application
 Entity sets and their attributes should reflect
reality
Faithfulness
 Consider the Movie database

 A relationship Stars-in between Stars and Movies
should be a many-many relationship

▪ Why?
 A relationship Teaches from Courses to Instructors
should be
▪ a many-one relationship? When? Why?
▪ a many-many relationship? When? Why?

Avoiding Redundancy
 What is redundancy?
 Why we need avoid a redundancies?

Avoiding Redundancy
 Consider a relationship Owns between movies

and studios
 Let studioName is an attribute of entity set
Movies
 Is it good?
name studioName
Studios Owns Movies

Simplicity Counts
 Avoid introducing more elements into your design

than is absolutely necessary

 Make your design as simple as possible
Simplicity Counts
 Consider creating entity set Holdings for the

ownership of single movie as below
Movies Represents Holdings Owns Studios
 Is it good?
Simplicity Counts
 A better design without an unnecessary entity set

Movies Owns Studios

Choosing the right relationships
 Entity sets can be connected in various ways by

relationships
 Do we use all possible relationships in our
model?
Choosing the Right Relationships
Salary
title year name addr
Movies Contracts Stars
 Do we need the relationships

length genre between Movies and Studios and
Movies and Stars directly?
Studios  What if a star can work on a movie
without there being a contract?
name addr
Picking the Right Kind of Element
 Do we use attributes or use entity set/relationship

combinations for a particular questions?

 In general, an attribute is simpler to implement
than either an entity set or a relationship
 Consider the Movies database

 We use the name and address of studio as attributes of
movies, so we eliminate the Studios entity set

 Is it good?
 An entity set should satisfy at least one of the

following conditions:
 It is more than the name of something; it has at least
one non-key attribute, or

 It is the many in a many-one or many-many relationship
Summary 4.2
 Faithfulness
 Avoiding redundancy
 Simplicity counts
 Choosing the right relationship
 Picking the right kind of element
CONSTRAINTS IN E/R MODEL

Keys in the E/R Model
 Two entities to agree on some, but not all, of the

key attributes
 Every entity set has key(s), one of them is
primary key
Representing Keys in the E/R
Model
name address
title year
Stars Stars-in
name Movies
address
Referential Integrity
 Consider a relationships between Movies, Studios,

and President
Movies Owns Studios Runs President
 We say
 Movies refers to Studios
 Studios refers to President
 President refers to Studios

Referential Integrity
 A referential integrity constraints

 A value appearing in one context must also appear in
another
Degree Constraints
 How we represented every movie has at least 10

stars?
name address title year
>=10
Stars Stars-in Movies
length genre
Summary 4.3
 Keys in the E/R model

 Referential Integrity
 Degree Constraints
WEAK ENTITY SETS

Weak Entity Sets
 Consider the relationship

number crewChief name address
Crews Unit-of Studios
Weak entity set Supporting entity set
 An entity set’s key to be composed of attributes, some
or all of which belong to another entity set. Such an

entity set is called a weak entity set.
Requirements for Weak Entity
Sets
 R is a relationship from E to F
 R is called supporting relationship if

 R must be a binary, many-one relationship from E to F
 R must have referential integrity from E to F
 The attributes that F supplies for the key of E must be
key attributes of F
Weak Entity Sets
 Example weak entity set

Contracts salary
Studio-of Movie-of
Star-of
Stars Studios Movies
genre
year
length
name addr title
name addr
FROM E/R TO RELATIONAL

From E/R Diagrams to Relational
Design
 Entity set -> relation

 Attributes -> attributes
 Relationships -> relations whose attributes are only

 The keys of the connected entity sets
 Attributes of the relationship itself
 However, two rules above cover only common situations. There

are also several special situations that we need deal with
 Weak entity sets
 “ISA” relationships and subclasses
 Combination of two relations

From Entity Sets to Relations
name address name address
Stars Studios
Stars(name,address) Studios(name,address)
From E/R Relationships to
Relations
Stars-in(title,year,starName)
name address Owns(title,year,studioName)
Stars Stars-in title year
name Movies

address
 The relation for a given relationship R has attributes:

 For each entity set involved in relationship R, we take its key attributes as a part of the schema
of the relation for R
 If the relationship has own attributes, then these are also attributes of relation R
 If one entity set is involved several times in a relationship in different roles, then its key attributes
each appear as many times as there are roles
From E/R Relationship to
Relations
Studio Producing
of star studio
Studios
Contracts(starName, title,year, studioOfStar_name, producingStudio_name)

Combining Relations
name address Movies(title,year,length,genre)
Owns(title,year,studioName)
Stars title year

Stars-in
name Movies
Movies(title,year,length,genre,studioName)
address
 Suppose an entity set E and a many-one relationship R from E to F. We can combine

two relations E and R into one relation with a schema consisting of:
 All attributes of E,
 The key attributes of F,
 and all own attributes belonging to relationship R
Handling Weak Entity Sets
number crewChief name address
Crews Unit-of Studios
Studios(name,address)
Crews(number,crewChief,studioName)
 If W is a weak entity set, construct for W a relation whose schema consists of:
• All attributes of W
• All own attributes of supporting relationships for W
• For each supporting relationship for W, say a many-one relationship from W to entity set
E, all the key attributes of E
 Rename attributes, if necessary, to avoid name conflicts
 Do not construct a relation for any supporting relationship for W
SUBCLASS STRUCTURES TO
RELATIONS
Converting Subclass Structures
to Relations
 How we convert this structure to relations?

Voices Movies
isa isa weapon
Murder
Cartoons
Mysteries
Converting Subclass Structures
to Relations
 The principal conversion strategies

 Follow E/R viewpoint

▪ For each entity set E in the hierarchy, create a relation that includes the key
attributes from the root and any attributes belong to E
 Treat entities as object-oriented

▪ For each possible subtree that includes the root, create one relation, whose
schema includes all the attributes of all the entity sets in the subtree
 Use null values

▪ Create only one relation with all attributes of all entity sets in the hierarchy.
Each entity is represented by one tuple, and that tuple has a NULL value for
whatever attributes the entity does not have
E/R Style Conversion
Voices Movies
isa isa weapon
Murder
Cartoons
Mysteries
Movies(title,year,length,genre)
MurderMysteries(title,year,weapon)
Cartoons(title,year)  remove
Voices(title,year,starName)
An Object-Oriented Approach
Voices Movies
isa isa weapon
Murder
Cartoons
Mysteries
Movies(title,year,length,genre)
MoviesC(title,year,length,genre)
MoviesMM(title,year,length,genre,weapon)
MoviesCMM(title,year,length,genre,weapon)
Using Null Values
Voices Movies
isa isa weapon
Murder
Cartoons
Mysteries
Movie(title,year,length,genre,weapon)
Unified Modeling Language
 Introduction
 UML is designed to model software in an object-
oriented style, but has been adapted as a database

modeling language
 UML offers much the same capabilities as the E/R
model, with the exception of multi-way relationships,

only binary relationships in UML.
UML vs. E/R Model
(self studying)
UML E/R Model

Class Entity Set

Association Binary relationship
Association class Attributes on a relationship
Subclass is-a hierarchy
Aggregation Many-one relationship
Composition Many-one relationship with
referential integrity
Figure 4.34: Comparison between UML and E/R terminology

UML Classes
Movies Class’ name

title PK
State year PK
length
genre
init()
modify()
Behavior
Associations
 Consider an associations between Movies, Stars,

and Studios in UML

Studios
0..1
name PK
address Owns Movies
0..* title PK
year PK
Stars 0..* length
name PK 0..* Stars-in genre
address
Associations
 Comparison with E/R Multiplicities

E/R UML
0..* 0..*
0..* 0..1
0..* 1..1
Self-Associations
 An association can have both ends at the same

class; such an association is called a self-

association
 Example
Movies
0..1 theOriginal
title PK
year PK
length
genre 0..* theSequel
Association Classes
Movies
Stars Stars-in title PK
0..* 0..*
name PK year PK
address length
genre
Compensation
salary
residuals
Subclasses in UML
 Consider Movies and its three subclasses

Movies
title PK
year PK
length
genre
Murder Cartoons Cartoon-

Mysteries Murder
Mysteries
weapon
weapon
Figure 4.40: Cartoons and murder mysteries as disjoint subclasses of movies
Aggregations and
Compositions
MovieExecs
cert# PK
name
address
networth
Movies
title PK Studios Presidents
year PK 1..* name PK 0..1
0..1 address 1..1
length
genre
Figure 4.41: An aggregation from Movies to Studios and

a composition from Presidents to Studios
UML-to-Relations Basics
 Classes to Relations
 For each class, create a relation

▪ name is the name of the class
▪ attributes are the attributes of the class
 Associations to Relations
 For each association, create a relation
▪ name is the name of that association
▪ attributes are the key attributes of the two connected classes
UML-to-Relations Basics
Studios
0..1
name PK
address Owns Movies
0..* title PK
year PK
Stars 0..* length
name PK 0..* Stars-in genre
address
Movies(title,year,length,genre) Stars-In(movieTitle,movieYear,starName)
Stars(name,address) Owns(movieTitle,movieYear,studioName)
From UML Subclasses to
Relations
 We can use any of the three strategies outlined

for E/R to convert a class and its subclasses to

relations
 E/R-style: each subclass’ relation stores only its own
attributes, plus key

 OO-style: relations store attributes of subclass and all
super-classes
 Nulls: One relation, with NULL’s as needed
From Aggregations and
Composition to Relation
 No relation for the aggregation or composition

 Add to the relation for the class at the non-

diamond end the key attribute(s) of the class at
the diamond end
 In the case of an aggregation, it is possible that these
attributes can be null

From Aggregations and
Composition to Relation
MovieExecs
cert# PK
name
address
networth
Movies
title PK Studios President
year PK 1..* name PK 0..1
0..1 address 1..1
length
genre
MovieExecs(cert#,name,address,netWorth)
Presidents(cert#,studioName)
Movies(title,year,length,genre,studioName)
The UML Analog of Weak Entity
Sets
 We use the composition, which goes from the

weak class to the supporting class, for a weak

entity set
 Example:
Crews Studios
number PK 0..* 1..1 name PK
PK
crewChief address
Crews(number,crewChief,studioName)
University DB
 The aim of this assignment is to develop a database system to

hold records for students and their training programs. The

system will be used for analyzing the students’s performance
during the training program as well as to select students of the
year based on the data entered into the system.
 Our university is organized into several departments which are
described by a name, department code, office number, office
phone, and a particular instructor who manages the department.
We keep track of the start date when that instructor began
managing the department.
University DB
 University recruits more instructors and arranges them on each different

department based on their expertise. Instructors are known as the

identification number, name, birthdate, startdate, sex and qualifications.
For each qualification, they should provide information about specialized
training, training institue or university and year of graduation
 Scientific subjects are distributed on each department. Information on
subjects includes subject code, name, total credit, credits theory, practice
credits, and prerequisite subjects. Department assigns its courses for
instructors. Each instructor can teach multiple subjects from different
departments. We also keep information about when he/she started and/or
stoped teaching a particular subject.
University DB
 Annual university enrollments 2000 students and arranges them in

many different classes and assigns for departments depending on

the coursework program that students sign up. Information about
the class is including class code, coursework program. Each class
has one academic supervisor from instructors of its managing
department.
 The information on students includes student’s name, student
number, social security name, current address and phone,
permanent address and phone, birth date, sex. Both social security
number and student number has unique values for each student.
University DB
 The coursework program lasts for 4 years, with 8 semesters. The subjects are
arranged for classes by sections in each semester. Information on section includes

number of semester, training year, section number. The section number distinguishes
sections of the same class that are taught during the same semester/year; its values
are 1, 2, 3... up to the number of sections taught during each semester for this class.
Managing department assigns specific instructor for each section depending on its
subject.
 Student has grade report for each subject that he/she has joined. There are two
evaluation modes: grade theory and practicle grade in rating 50%-50%. One student
passes the course if grade theory is greater than 4.0 and total score is greater than 5.0.
Otherwise, student must take part in a retake exam for grade theory. Finally, he/she
must rejoin the course in the next chances.

04 Ch4 HighLevelDatabaseModels

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

04 Ch4 HighLevelDatabaseModels

Uploaded by

Copyright:

Available Formats

INTRODUCTION

 Understand concepts of:

 The database design process

 Conceptual, logical design

 Entity relationship diagram

ER diagram Relational Database Schema

Database Design Process

 High-level design describes exactly the information needs

 Several options for high level design

 The first and oldest method is the Entity Relationship

 Represent the structure of data

 Not include the operations on data

 There are many notation to represent the

Studios Owns length genre

number of members of the other entity set

• Example: many-one, one-one and many-many

Movies Owns Studios

Studios Runs Presidents

Stars Stars-in Movies

Stars Contracts Movies

 Consider a relationship Sequel-of between the

entity set Movies and itself

 Consider the Contracts relationship involves two

studios, a star, a movie

Stars Contracts Movies

 Consider the contracts between a star and studio

for a movie. We wish to record the salary

name address title year

Stars Contracts Movies

name address Salaries title year

Stars Contracts Movies

 Consider the Contracts relationship involves two

studios, a star, a movie

Stars Contracts Movies

Stars Contracts Movies

Star-of Contracts Movie-of

 Consider Cartoons and Murder Mysteries are the

special kinds of movies, with some special

isa isa weapon

 The design should be faithful to the specifications

 Consider the Movie database

 A relationship Stars-in between Stars and Movies

should be a many-many relationship

 A relationship Teaches from Courses to Instructors

▪ a many-many relationship? When? Why?

 Why we need avoid a redundancies?

 Consider a relationship Owns between movies

Studios Owns Movies

 Avoid introducing more elements into your design

than is absolutely necessary

 Consider creating entity set Holdings for the

ownership of single movie as below

Movies Represents Holdings Owns Studios

 A better design without an unnecessary entity set

Movies Owns Studios

 Entity sets can be connected in various ways by

Movies Contracts Stars

 Do we need the relationships

 Do we use attributes or use entity set/relationship

combinations for a particular questions?

 Consider the Movies database

 We use the name and address of studio as attributes of