Chapter 3

Database Design:
Logical Design-Part1
Introduction
 Steps For Designing
Database
Conceptual Design STEP 1

STEP 2
Logical Design
STEP 3

STEP 4 STEP 6
STEP 5 STEP 7
Physical Design
STEP 8
STEP 9
 Methodology Overview -
Conceptual Database Design
z Step 1 Build local conceptual data
model for each user view
z Step 1.1 Identify entity types
z Step 1.2 Identify relationship types
z Step 1.3 Identify and associate attributes with entity or
relationship types
z Step 1.4 Determine attribute domains
z Step 1.5 Determine candidate and primary key attributes
z Step 1.6 Consider use of enhanced modeling concepts (optional
step)
z Step 1.7 Check model for redundancy
z Step 1.8 Validate local conceptual model against user transactions
z Step 1.9 Review local conceptual data model with user
 Methodology Overview - Logical
Database Design for Relational
Model
z Step 2 Build and validate local logical
data model for each view
z Step 2.1 Remove features not compatible with
the relational model (optional step)
z Step 2.2 Derive relations for local logical data
model
z Step 2.3 Validate relations using normalization
z Step 2.4 Validate relations against user transactions
z Step 2.5 Define integrity constraints
z Step 2.6 Review local logical data model with user
 Methodology Overview - Logical
Database Design for Relational
Model (cont)
z Step 3 Build and validate global logical
data model
z Step 3.1 Merge local logical data models into
global model
z Step 3.2 Validate global logical data model
z Step 3.3 Check for future growth
z Step 3.4 Review global logical data model with
users
 Methodology Overview - Physical
Database Design for Relational
Databases
z Step 4 Translate global logical data model for target DBMS
z Step 4.1 Design base relations

z Step 4.2 Design representation of derived data

z Step 4.3 Design enterprise constraints

z Step 5 Design physical representation

z Step 5.1 Analyze transactions

z Step 5.2 Choose file organization

z Step 5.3 Choose indexes

z Step 5.4 Estimate disk space requirements

Methodology Overview - Physical
Database Design for Relational
Databases(cont)

z Step 6 Design user views

z Step 7 Design security mechanisms
z Step 8 Consider the introduction of
controlled redundancy
z Step 9 Monitor and tune the
operational system
 Logical Design
z To translate the conceptual representation to the
logical structure of the database, which inlcudes
designing the relations.
z It maps the conceptual model on to a logical model,
which is influenced by the data model for the target
database (for example, the relational model).
z The logical data model is a source of information for
the physical design phase, providing the physical
database with a vehicle for making tradeoffs that are
very important to the design of an efficient database
 Conceptual Level,
Conceptual Schema,
Logical Design,
Logical Data Model
 CASE 1

DreamHome Case Study – An Overview

Pls refer to Connolly, T., Begg,

C.(2002).“Database System: A Practical
Approach to Design, Implementation, and
Management”, Addision Wesley, USA
Chapter 10, Section 10.4.1, pp 309
Local Conceptual Data Model for
Staff View Showing all Attributes
 Step 2 Build and Validate Local
Logical Data Model
Step 2.1 Remove features not compatible with
the relational model (optional step)
z To refine the local conceptual data model to remove
features that are not compatible with the relational
model. This involves:
1. remove *:* binary relationship types;
2. remove *:* recursive relationship types;
3. remove complex relationship types;
4. remove multi-valued attributes.
[1] Remove *:* Binary
Relationship Types
[2] Remove *:* Recursive
Relationship Types
[3]Remove Complex
Relationship Types
[4]Remove Multi-valued
Attributes
 Step 2 Build and Validate
Local Logical Data Model
z Step 2.2 Derive relations for local
logical data model
z To create relations for the local logical data
model to represent the entities,
relationships, and attributes that have been
identified.
 Step 2.2 Derive Relations for
Local Logical Data Model(cont)
[1] Strong entity types
z Create a relation that includes all simple
attributes of that entity. For composite
attributes, include only constituent simple
attributes.

Staff (staffNo, fName, lName, position,

sex, DOB)
 Step 2.2 Derive Relations for
Local Logical Data Model(cont)
[2] Weak entity types
z Create a relation that includes all simple
attributes of that entity.
z Primary key is partially or fully derived
from each owner entity.

Preference (prefType, maxRent)

Primary Key None (at present)
 Step 2.2 Derive Relations for
Local Logical Data Model(cont)
[3] 1:* binary relationship types
z Entity on ‘one side’ is designated the parent entity and
entity on ‘many side’ is the child entity.
z Post copy of the primary key attribute(s) of
parent entity into relation representing child
entity, to act as a foreign key.
 Step 2.2 Derive Relations for
Local Logical Data Model(cont)
[4] 1:1 binary relationship types
z More complex as cardinality cannot be used to identify parent
and child entities in a relationship.
z Instead, participation used to decide whether to combine
entities into one relation or to create two relations and post copy
of primary key from one relation to the other. Consider
following:
z (a) mandatory participation on both sides of 1:1
relationship;
z (b) mandatory participation on one side of 1:1
relationship;
z (c) optional participation on both sides of 1:1
relationship.

1..1 States 1..1

Client Preference
 Step 2.2 Derive Relations for
Local Logical Data Model(cont)
[a] Mandatory participation on both
sides of 1:1 relationship
z Combine entities involved into one relation and choose
one of the primary keys of original entities to be primary
key of new relation, while other (if one exists) is used as
an alternate key.
Client (clientNo, fName, lName, telNo, prefType,
maxRent, staffNo)
Primary Key clientNo
Foreign Key staffNo references Staff(staffNo)

1..1 States 1..1

Client Preference
 Step 2.2 Derive Relations for
Local Logical Data Model(cont)
[b] Mandatory participation on one side of a 1:1
relationship
z Identify parent and child entities using participation
constraints.
z Entity with optional participation is designated
parent entity, and other entity designated child entity
(not every client specifies preferences).
z Copy of primary key of parent placed in relation representing
child entity.
z If relationship has one or more attributes, these attributes
should follow the posting of the primary key to the child
relation.
1..1 States 0..1
Client Preference
 Step 2.2 Derive Relations for
Local Logical Data Model(cont)
[b] Mandatory participation on one
side of a 1:1 relationship - Example
 Step 2.2 Derive Relations for
Local Logical Data Model(cont)
[c] Optional participation on both sides of a 1:1 relationship
z Designation of the parent and child entities is arbitrary unless
can find out more about the relationship.
z Consider 1:1 Staff Uses Car relationship with optional participation
on both sides. Assume majority of cars, but not all, are used by
staff and only minority of staff use cars.
z Car entity, although optional, is closer to being mandatory than
Staff entity. Therefore designate Staff as parent entity and Car as
child entity. In this case, post a copy of the primary key of the
Staff entity into the Car relation

0..1 States 0..1

Client Preference
 Step 2.2 Derive Relations for
Local Logical Data Model(cont)
[5] 1:1 recursive relationships - follow
rules for participation for a 1:1
relationship.
z mandatory participation on both sides: single
relation with two copies of the primary key.
z mandatory participation on only one side: option to
create a single relation with two copies of the
primary key, or create a new relation to
represent the relationship. The new relation
would only have two attributes, both copies of the
primary key.
z optional participation on both sides, again create a
new relation as described above.
 Step 2.2 Derive Relations for
Local Logical Data Model(cont)
[6] Superclass/subclass relationship types
z Identify superclass as parent entity and subclass
entity as child entity.
z There are various options on how to represent such a
relationship as one or more relations.
z Most appropriate option dependent on number of
factors such as:
z disjointness and participation constraints on the
superclass/subclass relationship,
z whether subclasses are involved in distinct
relationships,
z number of participants in superclass/subclass
relationship.
 Guidelines for Representation of
Superclass / Subclass Relationship
 Guidelines for Representation of
Superclass / Subclass Relationship
(cont)
Owner
ownerNo {PK}
address
telNo
{Mandatory, And}

PrivateOwner BusinessOwner
Name bName

F_Name bType

L_Name contactName

AllOwner (ownerNo, address, telNo, F_Name, L_Name, bName,

bType, contactName, pOwnerFlag, bOwnerFlag)
 Guidelines for Representation of
Superclass / Subclass Relationship
(cont)
Owner
ownerNo {PK}
address
telNo
{Optional, And}

PrivateOwner BusinessOwner
Name bName

F_Name bType

L_Name contactName

Owner (ownerNo, address, telNo);

OwnerDetails (ownerNo, F_Name, L_Name, bName, bType,
contactName, pOwnerFlag, bOwnerFlag);
 Guidelines for Representation of
Superclass / Subclass Relationship
(cont)
Owner
ownerNo {PK}
address
telNo
{Mandatory, Or}

PrivateOwner BusinessOwner
Name bName

F_Name bType

L_Name contactName

PrivateOwner (ownerNo, F_Name, L_Name, address, telNo);

BusinessOwner (ownerNo, bName, bType, contactName, address,
telNo);
 Guidelines for Representation of
Superclass / Subclass Relationship
(cont)
Owner
ownerNo {PK}
address
telNo
{Optional, Or}

PrivateOwner BusinessOwner
Name bName

F_Name bType

L_Name contactName

Owner (ownerNo, address, telNo);

PrivateOwner (ownerNo, F_Name, L_Name);
BusinessOwner (ownerNo, bName, bType, contactName);
 Step 2.2 Derive Relations for
Local Logical Data Model(cont)

[7] *:* binary relationship types

z Create relation to represent relationship and
include any attributes that are part of relationship.
z Post a copy of the primary key attribute(s)
of the entities that participate in
relationship into new relation, to act as
foreign keys.
z These foreign keys will also form primary key of
new relation, possibly in combination with some
of the attributes of the relationship.
 Step 2.2 Derive Relations for
Local Logical Data Model(cont)
[7] *:* binary relationship types - Example
 Step 2.2 Derive Relations for
Local Logical Data Model(cont)
[8] Complex relationship types
z Create relation to represent relationship and include
any attributes that are part of the relationship.
z Post copy of primary key attribute(s) of
entities that participate in the complex
relationship into new relation, to act as foreign
keys.
z Any foreign keys that represent a ‘many’ relationship
(for example, 1..*, 0..*) generally will also form the
primary key of new relation, possibly in combination
with some of the attributes of the relationship.g
 Step 2.2 Derive Relations for
Local Logical Data Model(cont)
[8] Complex relationship types - Example
 Step 2.2 Derive Relations for
Local Logical Data Model(cont)

[9] Multi-valued attributes

z Create new relation to represent multi-
valued attribute and include primary key of
entity in new relation, to act as a foreign
key.
z Unless the multi-valued attribute is itself
an alternate key of the entity, primary key
of new relation is combination of the
multi-valued attribute and the primary key
of the entity.
 Step 2.2 Derive Relations for
Local Logical Data Model(cont)
[9]Multi-valued attributes - Example
Summary of How to Map Entities
and Relationships to Relations
Relations for the Staff View of
DreamHome
Questions