Database Design

Chapter 4-2
 Objectives
• To study the three main database design
phases
– Conceptual design
– Logical design
– Physical design
• Entities, Attributes, and Keys
• Relationships, Associations, and Constraints
• The ER Diagrams
• Mapping ER-models to relational tables
 Database Development Life Cycle
Development of Database Systems involve the following steps:
1. Requirements Analysis
2. Design
A. Conceptual Database Design
B. Logical Database Design
C. Physical Design
3. Implementation - the testing and deployment of the
designed database
4. Operation and Support - administering and maintaining
the operation of the database system and providing
support to users
 Database Design
4

The prime interest of a database system will be the Design part

which is again sub divided into other three sub-phases.
These sub-phases are:
• Conceptual Design
• Logical Design, and
• Physical Design
 Conceptual Design
• Conceptual Database Design – simple description of the
data that closely matches how users and developers think
of the data

• The process of constructing a model of the information

used in an enterprise, independent of all physical
considerations.

• entirely independent of implementation details such as the

target DBMS, application programs, programming
languages, hardware platform, performance issues, or any
other physical considerations.
 Cont’d
• It is the source of information for the logical
design phase.
• Mostly uses an Entity Relationship Model to
describe the data at this level.
• After the completion of Conceptual Design
one has to go for refinement of the schema,
which is verification of Entities, Attributes, and
Relationships.
 Logical Database Design
• The process of constructing a model of the
information used in an enterprise based on a
specific data model(e.g. Relational,
Hierarchical or Network or Object), but
independent of a particular DBMS and other
physical considerations.
 Cont’d
• The logical database design phase maps the
conceptual data model on to a logical model,
which is influenced by the data model for the
target database (for example, the relational
model).
• The logical data model is a source of information
for the physical design phase, providing the
physical database designer with a vehicle for
making trade-offs that are very important to the
design of an efficient database.
 Cont’d
• Includes the following tasks:
– Normalization process
– Collection of Rules to be maintained
– Discover new entities in the process
– Revise attributes based on the rules and the
discovered Entities
 Physical Database Design
• is the process of producing a description of the
implementation of the database on secondary storage.
-- defines specific storage or access methods used by
database.
• it describes the storage structure, base relations, file
organizations, and indexes used to achieve efficient
access to the data, and any associated integrity
constraints and security measures.
• Tailored to a specific DBMS system --Characteristics are
function of DBMS and operating systems.
• Includes estimate of storage space.
 Cont’d
• feedback between physical and logical design,
because decisions taken during physical
design for improving performance may affect
the logical data model.
 Conceptual Database Design

Before working on the conceptual design of the

database, one has to know and answer the following
basic questions.
• Identify what are the entities/entity types
• Identify what are the attributes: - the information
about entities and relationship should we store in
the database.
• Identify relationship types
• Identify what are the constraints/business rules that
hold?
 Cont’d
• Draw entity-relationship diagram: - representing
the database in the ER model using pictorial
representation called ER diagram
• Check model for redundancy
• Validate conceptual data model against user
transactions
• Review the conceptual data model with user
 Entity Relationship (E-R) Model
• An entity-relationship (E-R) data model is a high-level
conceptual model that describes data as entities,
attributes, and relationships.
• The E-R model is represented by E-R diagrams that show
how data will be represented and organized in the various
components of the final database. However, the model
diagrams do not specify the actual data, or even exactly
how it is stored. The users and applications will create the
data content and the database management system will
create the database to store the content.
• Entity-Relationship modeling is used to represent
conceptual view of the database.
 Developing an E-R Diagram
• Designing conceptual model for the database is
not a one linear process but an iterative activity
where the design is refined again and again.
• To identify the entities, attributes, relationships,
and constraints on the data, there are different
set of methods used during the analysis phase.
These include information gathered by
– Interviewing end users individually and in a group
– Questionnaire survey
– Direct observation
– Examining different documents
 Cont’d
• The basic E-R model is graphically depicted and presented
for review. The process is repeated until the end users and
designers agree that the E-R diagram is a fair
representation of the organization’s activities and
functions.
• Checking for Redundant Relationships in the ER Diagram.
Relationships between entities indicate access from one
entity to another - it is therefore possible to access one
entity occurrence from another entity occurrence even if
there are other entities and relationships that separate
them - this is often referred to as Navigation‘ of the ER
diagram.
• The last phase in ER modeling is validating an ER Model
against requirement of the user.
 Cont’d
11

The main components of ER Modeling are:

• Entities
• Attributes
• Relationships
• Constraints
 Components of ER Modeling -
Entity
12

 An entity is a person, place, thing, event, or

concept about which data is collected
 Each entity shown in the conceptual

model represents the entire class

for that entity
E.g., the Customer entity represents the
collection of all customers. The individual
customers are called instances of the
entity
 Cont’d
 Entity’s name should always be a singular
noun
E.g.: student NOT students
 An Entity corresponds to entire table, not row
 Entity Types
• Entity types that do not have key attributes of their
own are called weak entity types. In contrast,
regular entity types that do have a key attribute are
sometimes called strong entity types. Entities
belonging to a weak entity type are identified by being
related to specific entities from another entity
type in combination with some of their attribute
values. We call this other entity type the identifying or
owner entity type (Note 9), and we call the
relationship type that relates a weak entity type to its
owner the identifying relationship of the weak entity
type
 Strong vs Weak Entity Types

24
 Strong entity:
a regular entity type that have its own key
attribute
 Weak entity :
an entity that cannot exist without the entity
with which it has a relationship
entity types that do not have key attributes of
their own
has a total participation constraint with respect
to its identifying relationship
Example
◼ Consider the entity type DEPENDENT, related to
EMPLOYEE
 Strong vs Weak Entity Types

25

 In ER Diagram weak entity types and their

relationship have double borders
 Strong vs Weak Entity Types
26
 Components of ERModeling -
13
Attributes
 Attributes
Represents the property used to describe an entity or a
relationship
Are the characteristics of an entity that we are interested in
 Types of Attributes
Simple Attributes
Composite Attributes
Single-valued Attributes
Multi-valued Attributes
Derived Attributes
 Types of Attributes
14

 Simple Attributes: contains a single value (not divided into sub

parts)
E.g.Age, gender
 Composite Attributes: Divided into sub parts (composed of other
attributes)
E.g. Name, address
 Single-valued Attributes: have only single value (the value may
change but has only one value at one time)
E.g. Name, Id. No.color_of_eyes
 Multi-valued Attributes: have more than one value
E.g.Address, dependent-name, Person may have several college
degrees
 Derived Attributes: the value may be derived (computed) from the
values of other attributes
E.g.Age (current year – year of birth) , G.P.A(grade point/credit hours)
 Entity-Set and Keys
15

 Key is an attribute or collection of attributes that uniquely identifies

an entity among entity set
For example, the ID of a student makes him/her identifiable among
students
 Candidate Key - A nominee for primary key field is known as
candidate key. An entity set may have more than one candidate key
 Primary Key - A primary key is one of the candidate keys chosen
by the database designer to uniquely identify the entity set
Value of a primary key is unique and cannot be null
 Composite Key - If a table do not have any single column that
qualifies for a Candidate key, then you have to select 2 or more
columns to make a row unique. Such keys are called CompositeKey.
 Foreign Key – an attribute that can only take the values which are
present as values of other attribute
 Attribute Values - Null & Default
16
Values
 Null Value
NULL applies to attributes which are not applicable or
which do not have values
For such attributes, you may enter the value NA
(meaning notapplicable)
Value of a primary key attribute can not be null

 Default value
assumed value if no explicit value
 Entity-Set and Keys
17

 For StudentEntity  For Student_couseEntity

Candidate Key –
{STUD_NO}
Primary Key - STUD_NO
Candidate Key –{STUD_NO,
COURSE_NO}
Primary Key – {STUD_NO,
COURSE_NO} - Also Composite
keys
Foreign Key – STUD_NO
 Components of ERModeling -
18
Relationship
 The association among entities is called a relationship
E.g., an employee works_at a department, a student enrolls in a
course. Here, Works_at and Enrolls are called relationships
A relationship should be named by a word or phrase which
explains its function

 Relationship Attributes: it is also possible for a relationship

to have attributes
 Degree of Relationship: refers to the number of entities
participating in a relationship
Unary Relationship: a relationship involving only one entities
Binary Relationships: a relationship between two entities
Ternary Relationship: a relationship between three entities
N-ary Relationship: a relationship that participates more than
three entities
 Components of ERModeling -
19
Constraints
 Constraints
are the rules enforced on the data of a table
ensure the accuracy and reliability of the data in the
database
 For example, if a company has a rule that each
employee must work for exactly one department,
then we would like to describe this constraint in the
schema
 We can distinguish two main types of relationship
constraints: Cardinality Ratio andParticipation.
Structural Constraints on Relationship
• Constraints on Relationship/Multiplicity/
Cardinality Constraints:
• Multiplicity constraint is the number or range of
possible occurrence of an entity type/relation
that may relate to a single occurrence/tuple of an
entity type/relation through a particular
relationship. Mostly used to insure appropriate
enterprise constraints.
• Cardinality Ratio refers to the number of instances
associated with a single instance from another
entity in a relationship
 Cardinality Ratio Types

21
 ONE-TO-ONE (1:1) one tuple is associated with only
one other tuple
E.g. Department-Employee: in manages
relationship since one
department have only one manager
 ONE-TO-MANY (1:N) one tuple can be associated
with many other
tuples, but not the reverse
E.g. Department-Student: as one department can
have multiple students
 Cardinality Ratio Types
 MANY-TO-ONE (N:1) many tuples are associated with one
tuple but
• not the reverse
E.g. Employee – Department: as many employees belong
to a single
• department
 MANY-TO-MANY (N:M) one tuple can be associated with
more
• than one other tuple and vice versa
E.g. Student – Course as a student can take many courses
and a single
• course can be attended by mCaonmypilsetdudBye-nStesble
N.
 One-to-one relationship

ONE-TO-ONE (1:1) one tuple is associated with

only one other tuple
A customer is associated with at most one loan via the relationship
borrower. A loan is associated with at most one customer via borrower.
Eg : Relationship Manages between STAFF and
BRANCH.
• The multiplicity of the relationship is:
– One branch can only have one manager.
– One employee could manage either one or no
branches.
One-To-Many Relationships
• In the one-to-many relationship a loan is
associated with at most one customer via
Borrower , a customer is associated with
several (including 0) loans via borrower.
• E.g.: Relationship Leads between STAFF and
PROJECTThe multiplicity of the relationship is:
– One staff may Lead one or more project(s)
– One project is Lead by one staff
Many-To-Many Relationship
• A customer is associated with several
(possibly 0) loans via borrower. A loan is
associated with several (possibly 0) customers
via borrower.
.E.g.: Relationship Teaches between
INSTRUCTOR and COURSE The multiplicity of
the relationship
• One Instructor Teaches one or more Course(s)
• One Course Thought by Zero or more
Instructor(s)
 Participation of an Entity Set in a
Relationship Set
• Particpation constraints Participation
constraint of a relationship is involved in
identifying and setting the mandatory or
optional feature of an entity occurrence to
take a role in a relationship. There are two
distinct participation constraints with this
respect, namely: Total Participation and
Partial Participation.
• Total participation : every tuple in the entity or
relation participates in at least one relationship by
taking a role. This means, every tuple in a relation will
be attached with at least one other tuple. The entity
with total participation in a relationship will be
connected to the relationship using a double line.
• Partial participation: some tuple in the entity or
relation may not participate in the relationship. This
means, there is at least one tuple from that Relation
not taking any role in that specific relationship. The
entity with partial participation in a relationship will be
connected to the relationship using a single line.
 Components of ER Modeling -
Constraints
22

 Participation Constraint
specifies whether the existence of an entity
depends on its being related to another entity via
the relationship type

 There are two types of participation

constraints:
Total Participation − Each entity is involved in
the relationship
Partial participation − Not all entities are
involved in the relationship
 Participation Constraints Example

23

 Total Participation Example

If a company policy states that every employee
must work for a department, then an employee
entity can exist only if it participates in at least
one WORKS_ FOR relationship instance
◼ Thus, the participation of EMPLOYEE in
WORKS_FOR is called total participation,
meaning that every entity in employee entities
must be related to a department entity via
WORKS_FOR.
 Partial Participation Example
We do not expect every employee to manage a
department, so the participation of EMPLOYEE in
the MANAGES relationship type is partial,
meaning that some employee entities are related
to some department entity via MANAGES, but not
necessarily all
• Example identify the participation constraint
between the following entities on the relation
1. Employee belongs to a department
2.Employee manages the department
 E-R Diagram

27

 The ER Model is represented by means of an ER

diagram

 Any object, for example, entities, attributes of an

entity, relationship sets, and attributes of
relationship sets, can be represented with the help
of an ER diagram
 Graphical Representations in ER
28 Diagram
 Entities are represented by means of rectangles.
Rectangles are named with the entity set they
represent
 Graphical Representations in ER
29 Diagram
 Attributes are the properties of entities. Attributes
are represented by means of ellipses. Every ellipse
represents one attribute and is directly connected to
its entity (rectangle)
 Graphical Representations in ER Diagram
 If the attributes
30
are composite, they
are further divided in
a tree like structure.
Every node is then
connected to its
attribute. That is,
composite attributes
are represented by
ellipses that are
connected with an
ellipse.
Compiled By - Seble N.
 Graphical Representations in ER Diagram

31

 Multi-valued attributes are depicted by double

ellipse
 Graphical Representations in ER Diagram

32

 Relationships are represented by diamond-shaped

box
 Name of the relationship is written inside
the diamond-box
 All the entities (rectangles) participating in a
relationship, are connected to a Relationship by a
line
 Graphical Representations in ER Diagram

33

Relationship Cardinalities
 Graphical Representations in ER Diagram

34

Participation Constraints
Summary of the notation for ER
diagrams
Summary of the notation for ER
diagrams
Summary of the notation for ER
diagrams
Example #1:Build an E-R 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.
Example #2:Build an ER Diagram for the following
information:
• A Personnel record management system will have
the following two basic data object categories
with their own features or properties: Employee
will have an Id, Name, DoB, Age, Tel and
Department will have an Id, Name, Location.
Whenever an Employee is assigned in one
Department, the duration of his stay in the
respective department should be registered.
 ERDiagram Examples
35
 logical data model/Design
• Map the conceptual model to a logical model
• Mapping entities and relationships in ER-
Diagram into tables
– Translate ER-diagram with constraints in to
relation
 Cont’d
Step 2 Build and validate logical data model
– Step 2.1 Derive relations for logical data model
– Step 2.2 Validate relations using normalization
– Step 2.3 Validate relations against user
transactions
– Step 2.4 Define integrity constraints
 Cont’d
• Step 2.5 Review logical data model with user
• Step 2.6 Merge logical data models into global
model (optional step)
• Step 2.7 Check for future growth
 Relational Data Model
• Relational model represents the database as a collection
of relations, where each relation is a table with rows and
columns
• Relation: Two dimensional table
– Stores information or data in the form of tables : rows and
columns
• A row of the table is called tuple, equivalent to record
• A column of a table is called attribute, equivalent to fields
• Data value is the value of the Attribute
• In the relational model, each row in the table represents a
fact that typically corresponds to a real-world entity or
relationship
 Cont’d
The building blocks of the relational data
model are:
– Entities: real world physical or logical object
– Attributes: properties used to describe each Entity
or real world object.
– Relationship: the association between Entities
– Constraints: rules that should be obeyed while
manipulating the data.
 Types Of Relation
• Base Relation (Base Table)
– A Named Relation corresponding to an entity in the conceptual
schema, whose tuples are physically stored in the database
• View (Unnamed Relation)
– A View is the dynamic result of one or more relational
operations operating on the base relations to produce another
virtual relation that does not actually exist as presented
– produced upon request by a particular user at the time of
request
– can be created from single or different relations by extracting
some attributes and records with or without conditions
 Purpose of View
• Hides unnecessary information from users: since only
part of the base relation (Some collection of attributes,
not necessarily all) are to be included in the view
• Provide powerful flexibility and security: since
unnecessary information will be hidden from the user
there will be some sort of data security.
• Provide customized view of the database for users:
each user is going to be interfaced with their own
preferred data set and format by making use of the
Views
 Relation
• Definition: A relation is a named, two-dimensional table of
data
• Table is made up of rows (records), and columns (attribute
or field)
• Not all tables qualify as relations Requirements:
– Every relation has a unique name.
– Every attribute value is atomic (not multivalued not composite )
– Every row is unique (can’t have two rows with exactly the same
values for all their Fields )
– Attributes (columns) in tables have unique names
– Order of rows and columns is irrelevant
 Correspondence with ER Model
⚫ Relations (tables) correspond with entity types
and with many-to-many relationship types
⚫ Rows correspond with entity instances and
with many- to-many relationship instances
⚫ Columns correspond with attributes
NOTE: The word relation (in relational
database) is NOT the same same the word
relationship (in ER model)
 Key Fields
• Keys are special fields that serve two main purposes:
• Primary keys are unique identifiers of the relation in
question. Examples include employee numbers, social
security numbers, etc. This is how we can guarantee
that all rows are unique
• Foreign keys are identifiers that enable a dependent
relation (on the many side of a relationship) to refer to
its parent relation (on the one side of the relationship)
• Keys can be simple (a single field) or composite (more
than one field)
• Keys usually are used as indexes to speed up the
response to user queries
Figure 5-3 -- Schema for four relations
(Pine Valley Furniture)
 Integrity Constraints
• Domain Constraints
– No value of the attribute should be beyond the
allowable limits
• Entity Integrity
– states that in a base relation, no attribute of a primary
key can assume a value of null. All primary key fields
MUST have data
• Enterprise Integrity Constraints:
– Additional rules specified by the users or database
administrators of a database are incorporated
 Cont’d
• Referential Integrity – rule that states that any foreign
key value (on the relation of the many side) MUST
match a primary key value in the relation of the one
side. (Or the foreign key can be null)
For example: Delete Rules
– Restrict – don’t allow delete of“parent” side if related
rows exist in “dependent” side
– Cascade – automatically delete “dependent” side rows
that correspond with the “parent” side row to be deleted
– Set-to-Null – set the foreign key in the dependent side to
null if deleting from the parent side not allowed for
weak entities
Referential integrity constraints (Pine
Valley Furniture)
 Transforming ER Diagrams in to
Relation
• Steps in mapping ER Conceptual Database Design
to Relational Model
1. Mapping of Strong Entity Types
2. Mapping of Weak Entity Types
3. Mapping of 1:1 Relationship Types
4. Mapping of 1:N Relationship Types
5. Mapping of M:N Relationship Type
6. Mapping of Multi-valued Attributes
7. Mapping of N-ary Relationship Types
Step 1 Mapping Regular Entities to Relations
• For each strong entity type E in the ER schema, create a
relation R that includes all the simple attributes of E.
• Simple attributes: E-R attributes map directly onto the
relation
• Composite attributes: Use only their simple, component
attributes
• Multi-valued Attribute - Becomes a separate relation with
a foreign key taken from the superior entity
• Choose one of the key attributes of E as primary key
for R
 Mapping a regular entity

(a) CUSTOMER entity type with simple attributes

(b) CUSTOMER relation

Mapping a composite attribute
Step 2: Mapping of Weak Entity Types
• For each weak entity type W in the ER schema with owner
entity type E, create a relation R and include all simple
attributes of W as attributes of R and also include primary
key attributes of the E as foreign key attributes W
• The primary key of W is the combination of the primary keys
of E and the partial key of W
• Weak Entities Becomes a separate relation with a foreign
key taken from the superior entity
• Primary key composed of:
– Partial identifier of weak entity
– Primary key of identifying relation (strong entity)
(a) Weak entity DEPENDENT
Relations resulting from weak entity
Step 3: Mapping Binary Relationships
• One-to-Many - Primary key on the one side
becomes a foreign key on the many side
• Many-to-Many - Create a new relation with
the primary keys of the two entities as its
primary key
• One-to-One - Primary key on the mandatory
side becomes a foreign key on the optional
side
Step 3.1 Mapping of 1:1 Relationship
Types
• For each binary 1:1 relationship type R in the ER
schema say Relation(R1) with Relation (R2) do the
following –
– Include the primary key of R2 as a foreign key in R1
– It is better to choose an entity type with total
participation in the role of R1
– Include any simple attributes of the 1:1 relationship as
attributes of R1
 Physical database design
• Translate logical data model for target DBMS
– Design base relations
– Design representation of derived data
– Design general constraints
• Design file organizations and indexes
– Analyze transactions
– Choose file organizations
– Choose indexes
– Estimate disk space requirements
• Design user views
• Design security mechanisms
• Consider the introduction of controlled redundancy
• Monitor and tune the operational system