Chapter 3 DB
Chapter 3 DB
Chapter 3 DB
1
Chapter Outline
The high-level conceptual model
Example database
Slide
3- 2
Overview of Database Design Process
Two main activities:
Database design
Applications design
Focus in this chapter on database design
To design the conceptual schema for a database
application
Applications design focuses on the programs and
interfaces access to the database
Generally considered part of software engineering
Slide
3- 3
Overview of Data base Design
Database design consists of several tasks: requirements analysis,
conceptual design, schema refinement, logical design, physical
design and tuning.
In general, one has to go back and forth between these tasks to refine a database
design, and decisions in one task can influence the choices in another task.
In developing a good design, one should ask: What are the important queries and
updates? What attributes/relations are involved?
Why is database design important?
A well-designed database facilitates data management and becomes a valuable
information generator.
A poorly designed database is a breeding ground for uncontrolled data
redundancies.
A poorly designed database generates errors that lead to bad decisions.
Slide
3- 4
High-level Conceptual Model
Slide
3- 5
Requirement Gathering & Analysis
Database designers carry out data gathering methods to
requirements.
These requirements should be specified in detail and
complete form
Functional requirements of the system are also identified at
this phase
Slide
3- 6
Database Design
Is the process of modeling the solution domain
Conceptual design
Logical design
Physical design
Slide
3- 7
Database Design…
Conceptual Design
Slide
using ER diagrams to describe the data
3- 8
Finally, refinement of the schema is required to verify the
Database Design…
Logical Design
The process of constructing a model of the information used
in an enterprise based on a specific data model (e.g.
relational), but independent of a particular DBMS and other
physical considerations.
Activities are:
Normalization process
Collection of Rules to be maintained
Discover new entities in the process
Revise attributes based on the rules and the discovered
Entities
Slide
3- 9
Database Design…
Physical Design
The process of producing a description of the
implementation of the database on secondary storage.
Describes the storage structures and access methods used to
achieve efficient access to the data.
Tailored to a specific DBMS system -- Characteristics are
function of DBMS and operating systems
Includes estimate of storage space
Activities are specifications of:
internal storage structure
Indexes
Access paths
File organizations of the databases
Slide
3- 10
ER Model Concepts
Entity-Relationship modeling is used to represent conceptual view of the
database
Its purpose is to create an accurate reflection of the real world in a database.
It gives us an intermediate step from which it is easy to define a database.
The E-R data model is based on a perception of a real world that consists of
a set of basic objects called entities, and of relationships among these
objects.
It was developed to facilitate database design by allowing the specification
of an enterprise schema, which represents the overall logical structure of a
database.
The E-R data model is one of several semantic data models
It is extremely useful in mapping the meanings and interactions of real-
world enterprises onto a conceptual scheme.
Slide
3- 11
ER Model Concepts
Main components are:
Entity Type or Set:
An entity type is any type of object that we wish to store data about
They are specific objects or things in the mini-world that are represented
in the database
Attribute:
is some quality about the entities that we are interested in
and want to hold on the database
These are behaviors used to describe an entity
Relationships:
are communications among entities
Constraints
Slide
3- 12
ER….
Attributes :
Each entity within the entity type will have the same set and number of
entity type
Slide
3- 14
ER …
Entities and Attributes
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, ID,
Address, Sex, BirthDate
A specific entity will have a value for each of its attributes.
For example a specific employee entity may have Name=Abebe
Kebede', ID='1234', Address ='731, Arada, AA', 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, …
Slide
3- 15
Types of Attributes (1)
Simple
Each entity has a single atomic value for the attribute. For example,
ID, Sex, etc.
Composite
The attribute may be composed of several components. For example:
Address(Apt#, House#, Street, City, State, ZipCode, Country), or
Name(FirstName, MiddleName, LastName).
Telephone (home, mobile, office)
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 or
DependentName.
Denoted as {Color} or {PreviousDegrees} or {DependentName}.
Slide
3- 16
Types of Attributes …
Derived
The value is derived (computed) from the values of other
attributes.
• Age (current year – year of birth)
• Profit (earning-cost)
• G.P.A (grade point/credit hours)
Stored : not possible to derive or compute
Eg. Name, Address, ID, etc
Null Values
attributes which are not applicable or which do not have
values.
Slide
3- 17
Types of Attributes (2)
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
Slide
3- 18
Example of a composite attribute
Slide
3- 19
Value sets of attributes
Are domains of attributes
language
Slide
3- 20
Entity Types and Key Attributes
Entities with the same basic attributes are grouped or typed
An attribute of an entity type for which each entity must have
Slide
key attributes at the same time
3- 21
Entity Types and Key Attributes
A key attribute may be composite.
VehiclePlateNumber is a key of the CAR entity type with
components (Number, City).
An entity type may have more than one key.
The CAR entity type may have two keys:
VehicleIdentificationNumber
VehiclePlateNumber
Slide
3- 22
Displaying an Entity type
In ER diagrams, an entity type is displayed in a
rectangular box
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
Slide
3- 23 Derived attributes denoted by dotted ovals
Entity is represented by a
containing the name of theRectangle
entity.
Slide
3- 25
Example COMPANY Database
We need to create a database schema design based on
the following 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.
Slide
3- 26
Example COMPANY Database (Contd.)
We store each EMPLOYEE’s ID 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.
Slide
3- 27
Initial Design of Entity Types for the COMPANY Database Schema
Slide
3- 28
Initial Design of Entity Types:
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT
Slide
3- 29
Relationships, Associations and Constraints
A relationship relates two or more distinct entities
with a specific meaning.
For example, EMPLOYEE A B works on the ProductX
PROJECT, or EMPLOYEE X Y manages the Research
DEPARTMENT.
Relationships of the same type are grouped or typed
into a relationship type.
A relationship type R among n entity type E1, E2, …,
En is a relationship set among entities from these
entity types
For example, the WORKS_ON relationship type in which
EMPLOYEEs and PROJECTs participate, or the
Slide MANAGES relationship type in which EMPLOYEEs and
3- 30
DEPARTMENTs participate.
Relationship Type
A relationship type R among n entity types E1,
…,En is a set of relationship instances ri, where
each ri associates n entities (e1,…,en), s.t. each ej Î
Ej. Informally, a relationship instance is an
association of entities, with exactly one entity from
each participating entity type.
The degree n of a relationship type is the number
of participating entity types.
In the ER model relationships are explicitly
represented.
Slide
3- 31
Relationship type vs. relationship set
Relationship Type:
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
Slide
The current state of a relationship type
3- 32
Relationship instances of the WORKS_FOR N:1 relationship between
EMPLOYEE and DEPARTMENT
Slide
3- 33
Relationship instances of the M:N WORKS_ON
relationship between EMPLOYEE and PROJECT
Slide
3- 34
Relationship type vs. relationship set
Slide
3- 35
Example 1
Build an ER Diagram for the following information:
Students
Have an Id, Name, Login, Age, Gpa
Courses
Have Number, Name, Credit Hours
Students enroll in courses
Receive a grade
Slide
3- 36
Example 1 Answer
Id Gpa
Students Courses
Enrolled_In
Grade
Slide
3- 37
Example 2
Build an ER Diagram for the following
information:
Patients
Name, Address, Phone #, Age
Drugs
Name, Manufacturer , Expiration Date
Patients are prescribed for drugs
Dosage, # Days
Slide
3- 38
Example 2 Answer
Age
Patients Drug
Prescribed
Dosage #days
Slide
3- 39
Degree, Roles and Constraints
The degree of a relationship type is the number of
Supervision
Slide
3- 41
Structural Constraints
Structural constraints of a relationship type:
Cardinality ratio: Limits the number of relationship instances an
entity can participate in
specifies maximum participation
(Also known as multiplicity constraint)
eg. 1:1, 1:N, M:N
Participation constraint (Existence Dependency Constraint):
Determines whether the existence of an entity depends on its being related to
another entity via the relationship type
If each entity of an entity type is required to participate in some
instance of a relationship type, then that participation is total;
otherwise, it is partial.
specifies minimum participation
zero (optional participation, not existence-dependent)
one or more (mandatory participation, existence-dependent)
Slide
3- 42
Structural Constraint Min, Max
Slide
3- 43
Structural Constraints –one way to express semantics
of relationships
Structural constraints on relationships:
Cardinality ratio (of a binary relationship): 1:1,
1:N, N:1, or M:N
SHOWN BY PLACING APPROPRIATE NUMBER ON
THE LINK.
Participation constraint (on each participating
entity type): total (called existence dependency) or
partial.
SHOWN BY DOUBLE LINING THE LINK for Total,
Single otherwise
NOTE: These are easy to specify for Binary
Slide Relationship Types.
3- 44
Many-to-one (N:1) Relationship
Slide
3- 45
Many-to-many (M:N) Relationship
Slide
3- 46
Refining the COMPANY database schema by
introducing relationships
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)
Slide
3- 47
ER DIAGRAM – Relationship Types are:
WORKS_FOR, MANAGES, WORKS_ON, CONTROLS, SUPERVISION, DEPENDENTS_OF
Slide
3- 48
Alternative (min, max) notation for relationship
structural constraints:
Specified on each participation of an entity type E in a
relationship type R
Specifies that each entity e in E participates in at least min
and at most max relationship instances in R
Default(no constraint): min=0, max=n (signifying no limit)
Must have minmax, min0, max 1
Derived from the knowledge of mini-world constraints
Examples:
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
An employee can work for exactly one department but a
department can have any number of employees.
Specify (1,1) for participation of EMPLOYEE in WORKS_FOR
Specify (0,n) for participation of DEPARTMENT in WORKS_FOR
Slide
3- 49
The (min,max) notation for relationship
constraints
Read the min,max numbers next to the entity type and looking away
from the entity type
Slide
3- 50
COMPANY ER Schema Diagram using (min, max) notation
Slide
3- 51
Discussion on Relationship Types
In the refined design, some attributes 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.
Slide
3- 52
Attributes of Relationship types
A relationship type can have attributes:
For example, Hours 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 case of 1:1 or 1:N relationships, attributes can be migrated
to one of the participating entity types (on the N side of the
relationship)
Where to place an attribute should be decided by the designer
Slide
3- 53
Example Attribute of a Relationship Type:
Hours of WORKS_ON
Slide
3- 54
Recursive Relationship Type
A relationship type which is defined 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
Slide One employee in supervisee role
3- 55
Displaying a recursive relationship
In a recursive relationship type.
Both participations are with same entity
type in different roles.
For example, SUPERVISION relationships
between EMPLOYEE (in role of supervisor
or boss) and (another) EMPLOYEE (in role
of subordinate or worker).
In ER diagram, we need to display role names to
distinguish participations.
Slide
3- 56
A Recursive Relationship Supervision`
Slide
3- 57
Recursive Relationship Type is: SUPERVISION
(participation role names are shown)
Slide
3- 58
Weak Entity Types
Are related to another entity type ( called identifying owner)
through a relationship type ( called identifying relationship), in
combination with values of a set of its own attributes (called partial
key).
A weak entity type has total participation constraint w.r.t. its
identifying relationship.
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
Example:
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
Slide
3- 59
Summary of notation for ER diagrams
Slide
3- 60
Relationships of Higher Degree
Relationship types of degree 2 are called binary
Relationship types of degree 3 are called ternary and
of degree n are called n-ary
In general, an n-ary relationship is not equivalent to n
binary relationships
Constraints are harder to specify for higher-degree
relationships (n > 2) than for binary relationships
Slide
3- 61
Discussion of n-ary relationships (n > 2)
In general, 3 binary relationships can
represent different information than a single
ternary relationship
If needed, the binary and n-ary relationships
can all be included in the schema design
In some cases, a ternary relationship can be
represented as a weak entity if the data model
allows a weak entity type to have multiple
identifying relationships (and hence multiple
owner entity types)
Slide
3- 62
Examples
Slide
3- 63
Discussion of n-ary relationships (n > 2)
If a particular binary relationship can be
derived from a higher-degree relationship at
all times, then it is redundant
For example, the TAUGHT_DURING
binary relationship in (see next slide) can be
derived from the ternary relationship
OFFERS (based on the meaning of the
relationships)
Slide
3- 64
Another example of a ternary relationship
Slide
3- 65
Displaying constraints on higher-degree
relationships
The (min, max) constraints can be displayed
on the edges – however, they do not fully
describe the constraints
Displaying a 1, M, or N indicates additional
constraints
An M or N indicates no constraint
A 1 indicates that an entity can participate in at
most one relationship instance that has a
particular combination of the other participating
entities
Slide In general, both (min, max) and 1, M, or N
3- 66
Data Modeling Tools
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
Slide form rather than a conceptual ER-based design
3- 67
ER Mapping
ER diagram focuses on representing the schema of the
database during the conceptual design
Relational model: represents the logical design of the
database
Seven steps to map ER to relation
1. Strong Entity Types:
For each entity E, create a relation R consisting of all
simple attributes of E
Only simple attributes of composite attribute should be
represented
Denote the key attributes of E as primary key of R
68
ER Mapping
2. Weak Entity Types:
For each weak entity type W with owner entity E, create a
R
Primary key of R is combination of partial key of W and
70
ER Mapping
4. 1:N binary relationship types:
Identify the relation S denoting the entity from the N side of the
relationship type
Include the primary key of the other relation denoting the entity
4. Multivalued attributes:
For each multivalued attribute M, create a separate relation R
attribute of R
Include the primary key (P) of the entity type or relationship
72
ER Mapping
6. M:N binary relationship types:
Create a new relation R to represent the relationship type
Include the primary keys of the participating entity types as
foreign key of R. these will be used as primary key for R
Include any simple attribute of the relationship type
Eg. Employee works-on project
Slide
3- 74