Instructor : Lec Ayesha Naseer

Contact: ayeshanaseer@mcs.edu.pk
 The database design process can be divided into six steps:

1. Requirement Analysis
2. Requirement Specification Document
3. Conceptual Database design
4. Logical Database Design
5. Physical Database Design
6. Application and Security Design
 The very first step in designing a database application is to
understand what data is to be stored in the database.

 what applications must be built on top of it.

 what operations are most frequent and subject to

performance requirements.
 Software requirements specification establishes the basis for
agreement between customers and contractors or suppliers,
on what the software product is to do as well as what it is not
expected to do.

 Software requirements specification permits a rigorous

assessment of requirements before design can begin and
reduces later redesign.

 It should also provide a realistic basis for estimating product

costs, risks, and schedules.
 A conceptual data model identifies the highest-level
relationships between the different entities. Features of
conceptual data model include:

 Entities
 Relationship between entities
 mapping constraints

 ER model is used.
 A logical data model describes the data in as much detail as
possible, without regard to how they will be physical
implemented in the database.

The steps for designing the logical data model are as follows:
1. Specify primary keys for all entities.
2. Find the relationships between different entities.
3. Find all attributes for each entity.
4. Resolve many-to-many relationships.
5. Normalization
  Physical data model represents how the model will be built in
the database.
 A physical database model shows all table structures,
including column name, column data type, column
constraints, primary key, foreign key, and relationships
between tables.
 The steps for physical data model design are as follows:
1. Convert entities into tables.
2. Convert relationships into foreign keys.
3. Convert attributes into columns.
4. Modify the physical data model based on physical constraints
/ requirements.
 In this step we describe the role of each entity in every
process that is reflected in some application task, as part of a
complete workflow for that task.

 For each role, we must identify the parts of the database that
must be accessible and the parts of the database that must
not be accessible, and we must take steps to ensure that
these access rules are enforced
 ER model is an abstract and conceptual representation of
data.

 The conceptual schema design phase of databases is done

using ER Diagrams.
 Entity
 weak Entity
 Strong Entity
 Attributes
 Atomic
 Composite Attribute
 Multi valued Attribute
 Derived Attribute
 Relationships
 Relationship cardinality
 One - One
 One - Many
 Many - One
 Identifiers
 Primary key
 Candidate key
 Composite key
 Foreign key

 Participation constraints
 Total
 Partial

 Extended ER Features
 Specialization or Generalization
 Singular Nouns
- EMPLOYEE, CUSTOMER, SALE
 An Entity
– Will have many instances in the database
– Is composed of many attributes
– Is something needed for the system to work (something we
are trying to model)
 Examples
– Person: EMPLOYEE, STUDENT, PATIENT
– Place: STORE, WAREHOUSE, STATE
– Object: MACHINE, BUILDING, VEHICLE
– Event: SALE, REGISTRATION, BROADCAST
– Concept: ACCOUNT, COURSE, ROLE
 Usually a noun
• EmployeeID, Employee_Name

 Derived
• [YearsEmployed]

 Multivalued
• {Skill}
. {Address}

 Composite
• Name (First, Middle, Last)
 Verbs, or Verb Phrases
• has, wants, manages,
 Link between entity types

 Examples
- Employee has children (Existence relationship)
- Professor teaches students (Functional relationship)
- Customer places order (Event relationship)
 Express number of entities to which another entity can be
associated via relationship set. For Binary relationship
mapping cardinality must of one of following type.
 One to One
• Each entity will have exactly 0 or 1 related entity
 One to Many
• One of the entities will have 0, 1 or more related entities,
the other will have 0 or 1.
 Many to Many
• Each of the entities will have 0, 1 or more related entities
• We break these up so we can implement them in a
relational database.
 Identifiers or Keys are used to identify a single instance of an
entity
 Primary Key
• The identifier used to identify a specific entity instance
 Candidate Key
• The set of possible primary keys, We select the primary key
from this
 Composite Key
• A key made up of more than one attribute
– E.g. For the entity flight we may need a composite key
» FlightNumber PLUS FlightDate
 Foreign Key
• The key used to link to a primary key in another table
Allows us to join tables in the eventual database
 Identifiers are
– Never NULL
– Are UNIQUE
– Do not change in value
 IF A can exist without being associated with a B
 THEN A has partial (optional) participation
 ELSE A has total (mandatory) participation.
 Strong Entity
 Can exist by its self
 Does have its primary key

 Weak Entity
 Can’t exist without Entity 1
 Does not have its own primary key

 Examples
 Employer, dependent
 An entity set may not have sufficient attributes to form a
primary key. Such an entity set is termed a weak entity set.
An entity set that has a primary key is termed a strong entity
set.
 Consider the entity set payment, which has the three
attributes: payment-number, payment-date, and payment-
amount. Payment numbers are usually sequential numbers,
starting from 1, generated separately for each loan. Although
each payment entity is distinct, payments for different loans
may share the same payment number. Thus this entity set
does not have a primary key, it is a weak entity.
 For a weak entity set to be meaningful, it must be associated
with another entity set called the identifying or owner entity
set.
 Identifying entity set for payment entity is loan.
 The primary key of a weak entity is formed by the primary key
of the identifying entity plus the weak entity set’s
discriminator.
 The discriminator of the weak entity payment is the attribute
payment-number. Since for each loan payment-number
uniquely identifies one single payment for that loan.
 An entity set may include sub groupings of entities that are
distinct in some way from other entities in the set. The
process of sub grouping within an entity is called
specialization or generalization.
 Examples
 A student entity may be further classified as a teaching
assistant, research assistant.
 An account entity may be further classified as a saving
account, checking account.
Here are the major characteristics of the banking enterprise.
 The bank is organized into branches. Each branch is
located in a particular city and is identified by a unique
name. The bank monitors the assets of each branch.
 Bank customers are identified by their customer-id
values. The bank stores each customer’s name, and the
street and city where the customer lives. Customers may
have accounts and can take out loans. A customer may be
associated with a particular banker, who may act as a loan
officer or personal banker for that customer.
 Bank employees are identified by their employee-id
values. The bank administration stores the name and
telephone number of each employee, the names of the
employee’s dependents, and the employee-id number of
the employee’s manager. The bank also keeps track of the
employee’s start date and, thus, length of employment.
 The bank offers two types of accounts—savings and checking
accounts. Accounts can be held by more than one customer, and
a customer can have more than one account. Each account is
assigned a unique account number. The bank maintains a record
of each account’s balance, and the most recent date on which
the account was accessed by each customer holding the account.
In addition, each savings account has an interest rate, and
overdrafts are recorded for each checking account.

 A loan originates at a particular branch and can be held by one

or more customers. A loan is identified by a unique loan number.
For each loan, the bank keeps track of the loan amount and the
loan payments. Although a loan payment number does not
uniquely identify a particular payment among those for all the
bank’s loans, a payment number does identify a particular
payment for a specific loan. The date and amount are recorded
for each payment.
Recommended Readings:

 Chapter 2 of . Silberchatz, Korth, Sudarshan.

Database System Concept