Design Methodology

Design
Methodology
Lecture
Design Methodology
A structured approach that uses
procedures, techniques, tools and
documentation aids to support and
facilitate the process of design.
A design methodology consists of phases.
It help designer to plan, manage, control
and evaluate database development
projects.
Database Design Phases
The design process is divided into three
main phases:
• Conceptual Database Design

• Logical Database Design
• Physical Database Design
Conceptual Database Design
The process of constructing a model of the data used in an
enterprise, independent of all physical considerations.
With the creation of a conceptual data model of the

enterprise.
The model is entirely independent of implementation details

such as the target DBMS, application program,
programming languages, hardware platform, performance
issues or any other physical considerations.
Steps in Conceptual Database
Design Phase
Step 1 Build conceptual data model
Step 1.1 Identify entity types
Step 1.2 Identify Relationship Types
Step 1.3 Identify and associate
attributes with entity or relationship types
Step 1.4 Determine attribute domains
Step 1.5 Determine candidate,
primary and alternate key attributes
Step 1.6 Consider the use of
enhanced modeling concepts (Optional
step)
Step 1.7 Check model for redundancy
Step 1.8 Validate conceptual model
against user transactions
Step 1.9 Review conceptual data
model with user
Step 1 Build Conceptual Data Model
Objective: To build a conceptual data model

of the data requirements of the enterprise.
A conceptual data model comprises:

•Entity types
•Relationship types
•Attributes and attributes domains
•Primary key and alternate keys
•Integrity constraints
Step 1.1 Identify Entity Types
The first step is to define the main objects that
users are interested in.
These objects are the entity types for the model.
One method of identifying entities is to examine
the users requirement specification.
From this specification identify nouns (for example
staffNo, staffName etc.)
Identify major objects like places, concepts.
Difficulties in Entity Identification
1)The way the entities are presented in
user requirement specification document.
User often talk in terms of examples. For
example talking about staff in general, the
user may mention the name of staff
members.
In some cases user talk in terms of job
roles such as Director, Manager,
Supervisor or Assistant.
2) Users frequently use the synonyms for
example branch and office.
3) It is not always obvious whether a
particular object is an entity, a relationship
or an attribute.
Solution:
• Successive iteration of design process
• Experience and judgement
Document Entity Types
In data dictionary record the following
attributes related to entities:
•Entity Name
•Description
•Aliases
•Occurrence
Step 1.2 Identify Relationship
Types
Objective: To identify the important
relationships that exist between the entity
types.
Use ER diagrams
Determine the multiplicity constraints of
relationship types
Check for fan and chasm traps
Document Relationship Types
In data dictionary table record the following
attributes related to Relationship types:
•Entity Name
•Multiplicity
•Relationship
•Multiplicity
•Entity Name
Step 1.3 Identify and associate attributes with
entity or relationship types
Objective: To associate attributes with

suitable entity or relationship types.
The easiest way is that, identified an entity
(x) or a relationship (y). Then ask, What
information are we require to hold on x or y?
Decide Simple and Composite attributes
Single and multi-valued attributes
Derived Attributes
Document Attributes
In data dictionary record the following
information related to attributes.
Entity Name
Attributes
Descriptions
Data Type and Length
Nulls
Multi-valued…….
Step 1.4 Determine Attribute
Domain
Objective: To determine domains for the
attributes in the conceptual data model.
•Allowable set of values for the attributes;

•Sizes and formats of the attribute.
1.5 Determine Candidate, Primary
and Alternate key attribute
Objective:
To identify the candidate key(s) for each
entity type and, if there is more than one
candidate key, to choose one to be the
primary key and others as alternate key.
Document primary and alternate keys

Step 1.6 Consider use of Enhanced
Modeling Concepts (Optional Step)
Objective:
To consider the use of enhanced modeling
concepts, such as
specialization/generalization, aggregation
and composition.
Step 1.7 Check Model for Redundancy
Objective:
To check for the presence of any redundancy in
the model.
The three activities in this step are:

1)Re-examine One-to-One (1:1) relationships
2)Remove Redundant Relationships
3)Consider Time Dimension
(1) Re-examine One-to-One (1:1)
Relationships
In the identification of entities identified two entities
that represent the same object in the enterprise.
For example identified two entities Client and

Renter that are actually the same.
In other words Client is a synonym for Renter.
In this case two entities merged together. If the

primary keys are different, choose one of them to
be the primary key and leave other as alternate
key.
(2) Remove Redundant
Relationships
A relationship is redundant if the same
information can be obtained via other
relationships.
These relationships are unnecessary, they

should be removed.
It is relatively easy to identify whether there

is more than one path between two entities.
(3) Consider Time Dimension
The time dimension of relationship is
important when assessing redundancy.
Step 1.8 Validate the Conceptual
Model against User Transactions
Objective:
To ensure that the conceptual model
supports the required transactions.
Attempt to perform the operations manually.
If model resolve all the transactions then the
model support the required transactions.
If unable to support the transactions then
problem with data model, which must be
resolved.
Two approaches to ensuring that the
conceptual data model support the required
transactions:
(1)Describing the transaction

(2)Using the transaction pathways.
(1) Describing the transaction
Using the first approach check that all the
information like entities, relationships and
their attributes required by each transaction
is provided by the model.
(2) Using transaction pathways
The second approach to validating the data
model against the required transactions
involves diagrammatically representing the
pathway taken by each transaction directly
on the ER diagram.
Step 1.9 Review the Conceptual
Data Model with user
Objective:
To review the conceptual data model with

the users to ensure that they consider the
model to be a true representation of the data
requirements of the enterprise.

Design Methodology

Uploaded by

Copyright:

Available Formats

Design Methodology

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Design Methodology

Uploaded by

Copyright:

Available Formats

Design

• Conceptual Database Design

With the creation of a conceptual data model of the

The model is entirely independent of implementation details

Objective: To build a conceptual data model

A conceptual data model comprises:

Objective: To associate attributes with

•Allowable set of values for the attributes;

Document primary and alternate keys

The three activities in this step are:

For example identified two entities Client and

In this case two entities merged together. If the

These relationships are unnecessary, they

It is relatively easy to identify whether there

(1)Describing the transaction

To review the conceptual data model with

You might also like