Overview of the design process

• 2‐fold Process
• Model some part of the Real World
(Miniworld) as DATA
• Determine the OPERATIONS to be used on this
model.
• Both have DBMS independent and DBMS
specific aspects
 REQUIREMENTS COLLECTION &ANALYSIS

• Discover DATA and OPERATIONS requirements

– Interaction with the customer
• We will discuss DATA now, OPERATIONS later
• Questions
– what data must be available?
– How are data elements to be related?
• RESULT: DATABASE REQUIREMENTS
CONCEPTUAL DESIGN PROCESS
 LOGICAL DESIGN for DATA MODEL

• Implement High Level CONCEPTUAL SCHEMA

in some database
• Use DATA MODEL of that DB: Relational,
Network, OO…
• RESULT: Database CONCEPTUAL SCHEMA
– In RDB, Table Schemas and Constraints
 PHYSICAL DESIGN

• Incorporates knowledge of how the data will

be used:
– from the operations analysis
• RESULT: INTERNAL SCHEMA
– Layout
– Clustering (what tables near other tables for
faster disk access)
Database Design Process
 OPERATIONS DESIGN PROCESS
• REQUIREMENTS COLLECTION & ANALYSIS
• Discover OPERATIONS requirements
– Interaction with the customer
• Questions
– How will data be used?
– Estimated Frequency of Operations
• RESULT: FUNCTIONAL REQUIREMENTS
 FUNCTIONAL ANALYSIS

• Requirements are broken down into

operations and sequences
• List of the transactions known to be required
• RESULT: High Level TRANSACTION SPECS
– Info needed for PHYSICAL DESIGN of DB
•APPLICATION PROGRAM DESIGN

• Can plan LOGIC of programs without full

knowledge of final DB design
• RESULT: Program Skeleton

TRANSACTION IMPLEMENTATION
• Requires at least CONCEPTUAL DB DESIGN
• RESULT: APPLICATION PROGRAMS
Operations Design Process
Combined Design Process
Data Models
 Data Model
• A database model defines the logical design of
data. The model also describes the
relationships between different parts of the
data.
• Various types of data models are:
– Object oriented model
– Hierarchical data model
– Relational data model
– Network model
 Data Models
• Hierarchical data model: This is called a parent-child
relationship. In this model each entity has only one
parent but several children. At the top of the
hierarchy there is only one entity which is called
Root.
 Data Models
• Network model: In a network DBMS every
data item can be related to many others ones.
The database structure is like a graph. This is
similar to the hierarchical model and also
provides a tree-like structure. However, a child
is allowed to have more than one parent.
 Data Models
• Relational data model: In relational data model,
data exists in two dimensional tables known as
relations. A relation (table) consists of unique
attributes (columns) and tuples (rows).
 Data Models
• Object oriented model: Object based data
models use concepts such as entities,
attributes, and relationships
• The entity relational model( E-R model) has
emerged as one of the main techniques for
modeling database design .
 E-R Model
• ER Model is based on:
Entities and their attributes
Relationships among entities
 E-R Model components
• Entity: An entity in ER Model is real world entity,
which has some properties called attributes.
Every attribute is defined by its set of values,
called domain. For example, in a school database,
a student is considered as an entity. Student has
various attributes like name, age and class etc.
• An entity set is a collection of similar types of
entities. For example, Students set may contain
all the student of a school.
 Attributes
• Attributes describe the properties of the entity of
which they are associated.
• A particular instance of an attribute is a value. For
example, "Ram" is one value of the attribute Name.
• We can classify attributes as following:
¨ Simple
¨ Composite
¨ Single-valued
¨ Multi-valued
¨ Derived
• Simple attribute − Simple attributes are
atomic values, which cannot be divided further.
• For example, a student's phone number is an
atomic value of 10 digits.
• Composite attribute − Composite attributes are
made of more than one simple attribute.
• For example, a student's complete name may
have first_name and last_name.
• Single-Valued Attributes. An attribute is considered single-
valued if there is at most one value associated with it at any one
point in time. For example, suppose "gender" is an attribute in our
design.

•  Multi-value attributes may contain more than one values. For

example, a person can have more than one phone number,
email_address, etc.

• Derived Attribute : Attributes derived from other stored attribute.

For example age from Date of Birth and Today’s date.
 E-R model
• E-R diagrams are used to model real-world objects like a
person, a car, a company etc. and the relation between these
real-world objects. An e-r diagram has following features:

1. E-R diagrams are used to represent E-R model in a database,

which makes them easy to be converted into relations
(tables).
2. E-R diagrams provide the purpose of real-world modeling of
objects which makes them intently useful.
3. E-R diagrams require no technical knowledge & no hardware
support.
4. These diagrams are very easy to understand and easy to
create even by a naive user.
5. It gives a standard solution of visualizing the data logically.
E-R Model: Symbols and notations
E-R Model: Symbols and notations
E-R Model: Symbols and notations
 An E-R diagram constitutes of following Components

• A. Entity:- Any real-world object can be represented

as an entity about which data can be stored in a
database. All the real world objects like a book, an
organization, a product, a car, a person are the
examples of an entity. Any living or non-living
objects can be represented by an entity. An entity is
symbolically represented by a rectangle enclosing its
name.
• Two types of entity:
• Strong entity: A strong entity has a primary key
attribute which uniquely identifies each entity.
Symbol of strong entity is same as an entity.

• Weak entity: A weak entity does not have a primary

key attribute and depends on other entity via a
foreign key attribute.
• Attribute:- Each entity has a set of properties.
These properties of each entity are termed as
attributes. For example, a car entity would be
described by attributes such as price,
registration number, model number, color etc.
Attributes are indicated by ovals in an e-r
diagram.
•  Relationships:- A relationship is defined as bond
or attachment between 2 or more entities.
Normally, a verb in a sentence signifies a
relationship.
• For example,
• An employee assigned a project.
• Teacher teaches a student.
• Author writes a book.
• A diamond is used to symbolically represent a
relationship in the e-r diagram.
 E-R Model
• Relationship: The association among entities
is called relationship. For example, employee
entity has relation works_at with department.
• Relationships are mapped with entities in
various ways. Mapping cardinalities define the
number of association between two entities.
 Constraints
• Various types of constraints are:
1. Mapping cardinalities
2. Participation constraints
3. Keys
 Mapping Cardinalities
• Mapping cardinality or cardinality ratios ,
express the number of entities to which
another entity can be associated via a
relationship set
• Mapping cardinalities:
– one to one
– one to many
– many to one
– many to many
• One-to-one: one entity from entity set A can be
associated with at most one entity of entity set B and
vice versa.

• One-to-many: One entity from entity set A can be

associated more than one entities of entity set B but
from entity set B one entity can be associated with at
most one entity.
• Many-to-one: More than one entities from entity set A
can be associated with at most one entity of entity set B
but one entity from entity set B can be associated with
more than one entity from entity set A.

• Many-to-many: one entity from A can be associated with

more than one entity from B and vice versa.
 Participation Constraints
• The participation of an entity set E in a
relationship set R is said to be total if every
entity in E participates in at least one
relationship in R.
• If only some entities in E participate in
relationships in R, the participation is said to
be partial.
 Example

borro
wer

Total participation of Loan entity

 Types of Keys
1. Superkey: An attribute (or combination of
attributes) that uniquely identifies each row in a
table. It is a super set of candidate key.
2. Candidate key : An attribute (or set of attributes)
that uniquely identifies a row. Let K be a set of
attributes of relation R. Then K is a candidate key
for R if it possess the following properties:
1. Uniqueness – No legal value of R ever contains two
distinct tuples with the same value of K
2. Irreducibility- No proper subset of K has the
uniqueness property
 Types of Keys
3. Primary key : is the candidate key which is
selected as the principal unique identifier. It is a
key that uniquely identify each record in the
table. Cannot contain null entries.
 Types of Keys
4. Composite Key: Key that consist of two or
more attributes that uniquely identifies an entity
occurrence is called composite key.

Reg_no Crs_id subjects

 Types of Keys
5. Foreign Key: A foreign key is generally a
primary key from one table that appears as a
field in another where the first table has a
relationship to the second.
In other words, if we had a table A with a
primary key X that linked to a table B where X
was a field in B, then X would be a foreign key in
B.
Example
 Steps in designing E-R Diagram
• There are following steps:
– Identify the entities from the requirement sheets
– Find relationships among those entities
– Identify the key attributes for every entity
– Identify other relevant attributes
– Draw complete E-R diagram with all attributes
including Primary key
– Review your results with your Business users
Library management system
Example: University Management System
 Keys
• The key is defined as the column or attribute
of the database table.
• They are used to establish and identify
relation between tables.
• They also ensure that each record within a
table can be uniquely identified by
combination of one or more fields within a
table.
 Strong and Weak entity sets
• The entity set which does not have sufficient attributes to
form a primary key is called a Weak entity set.
• The entity set which has the primary key is called as Strong
entity set.
• A member of a strong entity set is called dominant entity
and member of a weak entity set is called subordinate entity.
• Weak entity does not have a primary key but we need a
mean to distinguish among other entities. The discriminator
of a weak entity set is a set of attributes that allows this
distinction to be made. Ex: payment_number.
Example
Example
E-R Diagram
 Roles
• Entity sets of a relationship need not be distinct
• The labels “manager” and “worker” are called roles; they specify how
employee entities interact via the works_for relationship set.
• Roles are indicated in E-R diagrams by labeling the lines that connect
diamonds to rectangles.
• Role labels are optional, and are used to clarify semantics of the
relationship
Removing Redundant attributes in entity set
• Once the entities and their corresponding attributes are
chosen, the relationship sets among the various entities
are formed.
• These relationship sets may result in a situation where
attributes in the various entity sets are redundant and
need to be removed .
• Consider the entity sets instructor and department
– Instructor includes the attributes ID, name, dept_name, and
salary with ID as primary key
– Department includes the attributes dept_name, building, and
budget with dept_name as primary key
Removing Redundant attributes in entity set

• Attribute dept_name appears in both entity sets. It is

primary key for entity department, it is redundant in
the entity set instructor and needs to be removed.
• If both entities have one to one relationship then we
can remove it from instructor table as it will get
added up in the relational schema of department.
• But if an instructor has more than one associated
department, the relationship between the entities is
recorded in a separate relation inst_dept
 Reduction to relational schema
• Both E-R model and relational database model are
abstract, logical representations of real-world
enterprises.
• Because the two models employ similar design we
can convert an E-R design to relational design
• E-R schema can be represented by relation schema in
following ways:
– Representing of strong entity sets with Simple Attributes
– Representing of strong entity sets with Complex Attributes
– Representation of weak entity sets
– Representation of relationship sets
 Representing of strong entity sets with Simple
Attributes

• A strong entity set reduces to a table with the

same attributes as represented in E-R diagram
 Representing of strong entity sets with Complex
Attributes

• In order to convert an entity having composite

attributes, the composite attributes are
flattened out by creating a separate attribute
for each component attribute.
• Multivalued attributes are treated differently
from other attributes. New relation schemas
are created for these attributes.
• Derived attributes are not explicitly
represented in the relational model.

BOOK entity set with author_id as multi-value attribute

 Representation of weak entity sets

• For schemas derived from a weak entity set,

the combination of the primary key of the
strong entity set and the discriminator of the
weak entity set serves as primary key of the
schema.
payment = ( loan_number, payment_number,
payment_date, payment_amount )
 Representation of relationship sets

• There are different strategies used for each

type of relationship.
1. Conversion of many to many relationship to
relational model:
– A many to many relationship set is represented as
a table with columns for the primary keys of the
two participating entity sets, and the descriptive
attributes of the relationship set.
2. Conversion of one to many relationship to
relational model:
For one to many or many to one relationship, there
is no need to create the separate table for the
relationship. Copy the primary key of entity set on one
side of relationship into the entity set on “many” side
of relationship.
Customer and Loan relationship with 1:M type
3. Conversion of one to one relationship to
relational model:
• In case of 1:1 relationship, there is no need to
create a separate table for relationship and
the primary key of any entity set can be
moved to other side depending upon the
requirement. It is preferable to copy the
primary key of non-totally participated entity
set towards totally participated entity set.
 Design Issues
• There are number of different ways to define
set of entities and relationship among them.
We examine basic issues in the design of an E-
R model. These are:
– Use of entity sets vs. attributes
– Use of entity sets vs. relationship sets
– Binary versus n-ary relationship sets
– Placement of relationship attributes
Design Issues: Use of entity sets vs. attributes
• Treating telephone as an attribute telephone-number implies that
employees have exactly one telephone number each
• Treating telephone as an entity permits employees to have several
telephone numbers associated with them.
• The distinctions to consider an object as attribute or entity depends
on the structure of real-world enterprise being modeled.
 Design Issues: Use of entity sets vs. relationship sets

• Each loan is represented by a relationship between a customer and

a branch, if every loan is associated with exactly one customer and
is associated with exactly one branch
• If several customers hold a joint loan then, loan should be
considered as an entity
The guideline in determining whether to use an entity set or
a relationship set is to designate a relationship set to
describe an action that occurs between entities
Design Issues: Binary versus n-ary relationship sets

• Although it is possible to replace any nonbinary (n-ary, for n >

2) relationship set by a number of distinct binary relationship
sets, a n-ary relationship set shows more clearly that several
entities participate in a single relationship.
• There is one advantage of using binary relationship, with this it is
possible to store partial information but in ternary relationship it
is not possible to represent it.
• But there are some relationships that are naturally non-binary.
 Design Issues: Placement of relationship attributes

• The cardinality ratio of a relationship can affect the

placement of relationship attributes
• Example: Let us take two entities instructor and student
with relationship advisor, if we want to add attribute date
( which specifies when the instructor became advisor)
• If relationship is one to many then the date must be placed
to the entity set on the “many” side of relationship
• For one to one relationship, it could be placed on either
side
• For many to many relationship, the date must be placed as
the relationship attribute
• Create the table for employee having
emp_name,emp_id,emp_address as attribute.
• Alter the table with adding new column
emp_dob
• Modify the column emp_name as “char(40)”
• Delete the column emp_dob from employee
table.
• Drop the employee table