Database Design

Methodology
What is a design methodology?
• Design methodology is an approach taken in designing or building
things and it serves as a guideline on how things are done.
• Normally a design methodology is broken down into phases or stages
and for each phase the detailed steps are outlined, and appropriate
tools and techniques are specified.
• A design methodology is able to support and facilitate designers in
planning, modeling, and managing a database development project in
a structured and systematic manner.
• The methodology consists of three main phases, starting with
conceptual, then logical and lastly the physical database design
phase.

• The core activity in conceptual database design phase involves the

use of ER modelling in which the entities, relationship and attributes
are defined.
• For the logical design phase, the aim is to map the conceptual model
which is represented by the ER model to the logical structure of the
database.
• In the physical design phase, the emphasis is to translate the logical
structure to the physical implementation of the database using the
defined database management system.
Critical Success factors in Database Design
• Work interactively with users as much as possible.
• Follow a structured methodology throughout the data modeling process.
• Employ a data-driven approach.
• Incorporate structural and integrity considerations into the data models.
• Combine conceptualisation, normalisation, and transaction validation
techniques into the data modeling methodology.
• Use diagrams to represent as much of the data models as possible.
• Use a Database Design Language (DBDL) to represent additional data semantics.
• Build a data dictionary to supplement the data model diagrams.
Conceptual Database Design
• The main focus of the conceptual database design phase is to produce a
conceptual data model that fulfils the enterprise requirements.

Step 1: Build Conceptual Data Model

Among the key elements that need to be identified for a conceptual model include:

• entity types,
• relationship types,
• attributes and attribute domains,
• primary and alternate keys, and
• integrity constraints.
Step 1.1: Identify Entity Types
Identifying the main objects also referred to as entity types, which are required for the
model, is the first step to be performed. This information can be obtained from the
user’s requirement specification.

Step 1.2: Identify Relationship Types

Next, we need to determine the important relationships that exist between the entity
types that have been identified.

Use of ER diagram helps to visualise the relationship and the model more effectively.

We need also to include the cardinality and the participation constraints of

relationship types in the diagram.
In Product ordering case study, following are the possible entities & relationships:

Entities
Customer, Employee, Product, Order, Invoice, Delivery, Supplier
Relationships
• Between Customer and Order : Customer makes Order
• Between Product and Order : Order has Product
• Between Supplier and Product : Supplier supplies Product
• Between Order and Invoice : Order has Invoice
• Between Employee and Order : Employee takes Order
• Between Order and Delivery : Order sends for Delivery
Step 1.3: Identify and Associate Attributes with Entity or Relationship Types

After identifying the entity and relationship types, the next step is to identify their
attributes.

Attributes can be categorised as

simple or composite

single or multi-valued

and stored or derived attributes.

Single valued Attributes : An attribute, that has a single value for a particular entity is
known as single valued attributes. For example, age of a employee entity. E.g. Library
card Number, Order ID.

Multi valued Attributes : An attributes that may have multiple values for the same
entity is known as multi valued attributes. For example colors of a car entity. E.g. Email
Id, Phone Number

Compound Attribute/Composite Attribute : Attribute can be subdivided into two or

more other Attribute. For Example, Name can be divided into First name, Middle name
and Last name.

Simple Attributes/Atomic Attributes : The attributes which cannot be divided into

smaller subparts are called simple or atomic attributes. For example, age of employee
entity.
Stored Attribute : An attribute, which cannot be derived from other attribute, is known
as stored attribute. For example, BirthDate of employee.
Derived Attribute : Attributes derived from other stored attribute. For example age from
Date of Birth and Today’s date.
Complex Attributes : If an attribute for an entity, is built using composite and
multivalued attributes, then these attributes are called complex attributes. For example,
a person can have more than one residence and each residence can have multiple
phones
Key Attribute : represents primary key. (main characteristics of an entity). It is an
attribute, that has distinct value for each entity/element in an entity set. For example,
Roll number in a Student Entity Type.

Non Key Attributes : These are attributes other than candidate key attributes in a table.
For example Firstname is a non key attribute as it does not represent the main
characteristics of the entity.
For our example, the list of attributes for the defined entities is as follows:

Customer CustNo, Name, CustAddress,TelNo, Balance

Employee EmpNo, Name, TelNo, Position, Gender, DOB, Salary

Order OrderNo, OrderDate, OrderAddress

Invoice InvoiceNo, Date, DatePaid, OrderNo;

Product ProductNo,Name,UnitPrice, QtyOnHand, ReorderLevel, SuppNo

Delivery DeliveryNo, DeliveryDate, OrderNo, ProductNo;

Supplier SuppNo, Name, SuppAddress, TelNo, ContactPerson

Step 1.4: Determine Attribute Domains
Next, we need to determine domains for each attributes and document the details of
each domain.

Step 1.5: Determine candidate, primary, and alternate key attributes

A relation must have a key that can uniquely identify each of the tuples.

Customer CustNo, Name, CustAddress,TelNo, Balance

Employee EmpNo, Name, TelNo, Position, Gender, DOB, Salary
Order OrderNo, OrderDate, OrderAddress, CustNo
Invoice InvoiceNo, Date, DatePaid, OrderNo;
Product ProductNo,Name,UnitPrice, QtyOnHand, ReorderLevel, SuppNo
Delivery DeliveryNo, DeliveryDate, OrderNo, ProductNo;
Supplier SuppNo, Name, SuppAddress, TelNo, ContactPerson
Step 1.6: Consider use of enhanced Modelling Concepts (optional step)
This step is involved with the use of enhanced modeling concepts, such as specialisation
/ generalisation, aggregation, and composition.

Step 1.7: Check Model for Redundancy

Check for the presence of any redundancy in the model as an important step to perform.

The common checking for the redundancy is to re-evaluate the 1:1 relationship.

If the entities in the relationship are similar, then we need to merge them together as
one entity, and may need to redefine the primary key.

Step 1.8: Validate Conceptual Model against User Transactions

We have to ensure that the conceptual model supports the transactions required by the
user view.
Step 1.9: Review Conceptual Data Model with User
User involvement during the review of the model is important to ensure that the
model is a ‘true’ representation of the user’s view of the enterprise.