Fundamentals of Database System

Chapter Five
Logical and Physical Database Design
5.1 Logical Database Design
Logical design is the process of constructing a model of the information used in an
enterprise based on a specific data model (e.g. relational, hierarchical or network or
object), but independent of a particular DBMS and other physical considerations.
There are a collection of rules to be maintained in logical database design that helps us to
discover new entities and Revise attributes based on the rules and the discovered Entities.
This rule is called Normalization process.
The first step before applying the rules in relational data model is converting the
conceptual design to a form suitable for relational logical model, which is in a form of
tables.

5.1.1 Converting ER Diagram to Relational Tables

Three basic rules to convert ER into tables or relations:
1. For a relationship with One-to-One Cardinality:
• All the attributes are merged into a single table. Which means one can post the
primary key or candidate key of one of the relations to the other as a foreign key.
2. For a relationship with One-to-Many Cardinality:
• Post the primary key or candidate key from the “one” side as a foreign key
attribute to the “many” side. E.g.: For a relationship called “Belongs To” between
Employee (Many) and Department (One)
3. For a relationship with Many-to-Many Cardinality:
• Create a new table (which is the associative entity) and post primary key or
candidate key from each entity as attributes in the new table along with some
additional attributes (if applicable)
After converting the ER diagram in to table forms, the next phase is implementing the
process of normalization, which is a collection of rules each table should satisfy.

5.1.2 Normalization
A relational database is merely a collection of data, organized in a particular manner. As
the father of the relational database approach, Codd created a series of rules called
normal forms that help define that organization.

AASTU Compiled by Chere L. (M.Tech) Page 1

 Fundamentals of Database System
One of the best ways to determine what information should be stored in a database is to
clarify what questions will be asked of it and what data would be included in the answers.
Database normalization is a series of steps followed to obtain a database design that
allows for consistent storage and efficient access of data in a relational database. These
steps reduce data redundancy and the risk of data becoming inconsistent.
Normalization is the process of identifying the logical associations between data items
and designing a database that will represent such associations but without suffering the
update anomalies which are;
• Insertion Anomalies
• Deletion Anomalies
• Modification Anomalies
Normalization may reduce system performance since data will be cross referenced from
many tables. Thus de-normalization is sometimes used to improve performance, at the
cost of reduced consistency guarantees.
Normalization normally is considered as good if it is lossless decomposition. All the
normalization rules will eventually remove the update anomalies that may exist during
data manipulation after the implementation.
The type of problems that could occur in insufficiently normalized table is called update
anomalies which includes;

(a) Insertion anomalies

An "insertion anomaly" is a failure to place information about a new database entry into
all the places in the database where information about that new entry needs to be stored.
In a properly normalized database, information about a new entry needs to be inserted
into only one place in the database; in an inadequately normalized database, information
about a new entry may need to be inserted into more than one place and, human fallibility
being what it is, some of the needed additional insertions may be missed.

(b) Deletion anomalies

A "deletion anomaly" is a failure to remove information about an existing database entry
when it is time to remove that entry. In a properly normalized database, information
about an old, to-be-gotten-rid-of entry needs to be deleted from only one place in the
database; in an inadequately normalized database, information about that old entry may
need to be deleted from more than one place, and, human fallibility being what it is, some
of the needed additional deletions may be missed.

AASTU Compiled by Chere L. (M.Tech) Page 2

 Fundamentals of Database System
(c) Modification anomalies
A modification of a database involves changing some value of the attribute of a table. In
a properly normalized database table, whatever information is modified by the user, the
change will be effected and used accordingly.
Note: The purpose of normalization is to reduce the chances for anomalies to occur in a
database.
Example of problems related with Anomalies

Emp FName LName Skill Skill Skill_Type School SchoolAdd Skill

_ID _ID
Level

12 Abebe Mekuria 2 SQL Database AAU Sidist_Kilo 5

16 Lemma Alemu 5 C++ Programming Unity Gerji 6

28 Chane Kebede 2 SQL Database AAU Sidist_Kilo 10

25 Abera Taye 6 VB6 Programming Helico Piazza 8

65 Almaz Belay 2 SQL Database Helico Piazza 9

24 Dereje Tamiru 8 Oracle Database Unity Gerji 5

51 Selam Belay 4 Prolog Programming Jimma JimmaCity 8

94 Alem Kebede 3 Cisco Networking AAU Sidist_Kilo 7

18 Girma Dereje 1 IP Programming Jimma JimmaCity 4

13 Yared Gizaw 7 Java Programming AAU Sidist_Kilo 6

Deletion Anomalies:
If employee with ID 16 is deleted then ever information about skill C++ and the type of
skill is deleted from the database. Then we will not have any information about C++ and
its skill type.
Insertion Anomalies:
What if we have a new employee with a skill called Pascal? We cannot decide whether
Pascal is allowed as a value for skill and we have no clue about the type of skill that
Pascal should be categorized as.

AASTU Compiled by Chere L. (M.Tech) Page 3

 Fundamentals of Database System
Modification Anomalies:
What if the address for Helico is changed froPiazza to Mexico? We need to look for
every occurrence of Helico and change the value of School_Add from Piazza to Mexico,
which is prone to error.
Note:
Database-management system can work only with the information that we put explicitly
into its tables for a given database and into its rules for working with those tables, where
such rules are appropriate and possible.

5.1.3 Functional Dependency (FD)

Before moving to the definition and application of normalization, it is important to have
an understanding of "functional dependency."
Data Dependency
The logical associations between data items that point the database designer in the
direction of a good database design are referred to as determinant or dependent
relationships.
Two data items A and B are said to be in a determinant or dependent relationship if
certain values of data item B always appears with certain values of data item A. if the
data item A is the determinant data item and B the dependent data item then the direction
of the association is from A to B and not vice versa.
The essence of this idea is that if the existence of something, call it A, implies that B
must exist and have a certain value, then we say that "B is functionally dependent on
A." We also often express this idea by saying that "A determines B," or that "B is a
function of A," or that "A functionally governs B." Often, the notions of functionality and
functional dependency are expressed briefly by the statement, "If A, then B." It is
important to note that the value B must be unique for a given value of A, i.e., any given
value of A must imply just one and only one value of B, in order for the relationship to
qualify for the name "function." (However, this does not necessarily prevent different
values of A from implying the same value of B.)
X
Y holds if whenever two tuples have the same value for X, they must
have the same value for Y
The notation is: A
B which is read as; B is functionally dependent on A
In general, a functional dependency is a relationship among attributes. In relational
databases, we can have a determinant that governs one other attribute or several other
attributes.
FDs are derived from the real-world constraints on the attributes

AASTU Compiled by Chere L. (M.Tech) Page 4

 Fundamentals of Database System
Example
Dinner Course Type of Wine
Meat Red
Fish White
Cheese Rose

Since the type of Wine served depends on the type of Dinner, we say Wine is
functionally dependent on Dinner.
Dinner
Wine
Dinner Type of Wine Type of Fork
Course
Meat Red Meat fork
Fish White Fish fork
Cheese Rose Cheese fork

Since both Wine type and Fork type are determined by the Dinner type, we say Wine is
functionally dependent on Dinner and Fork is functionally dependent on Dinner.
Dinner
Wine
Dinner
Fork
Partial Dependency
If an attribute which is not a member of the primary key is dependent on some part of the
primary key (if we have composite primary key) then that attribute is partially
functionally dependent on the primary key.
Let {A,B} is the Primary Key and C is no key attribute.

C and B

Then if {A,B}

C
Then C is partially functionally dependent on {A,B}
Full Dependency
If an attribute which is not a member of the primary key is not dependent on some part of
the primary key but the whole key (if we have composite primary key) then that attribute
is fully functionally dependent on the primary key.
Let {A,B} is the Primary Key and C is no key attribute

C and B

Then if {A,B}

C and A


C does not hold
Then C Fully functionally dependent on {A,B}
Transitive Dependency
In mathematics and logic, a transitive relationship is a relationship of the following form:
"If A implies B, and if also B implies C, then A implies C."

AASTU Compiled by Chere L. (M.Tech) Page 5

 Fundamentals of Database System
Example:
If Mr X is a Human, and if every Human is an Animal, then Mr X must be an Animal.
Generalized way of describing transitive dependency is that:
If A functionally governs B, AND
If B functionally governs C
THEN A functionally governs C
Provided that neither C nor B determines A i.e. (B /
A and C /
A)
In the normal notation:
{(A
B) AND (B
C)}==> A
C provided thatB /
A and C /
A

5.1.4 Steps of Normalization:

We have various levels or steps in normalization called Normal Forms. The level of
complexity, strength of the rule and decomposition increases as we move from one lower
level Normal Form to the higher.
A table in a relational database is said to be in a certain normal form if it satisfies certain
constraints. Normal form below represents a stronger condition than the previous one
Normalization towards a logical design consists of the following steps:
 UnNormalized Form:
Identify all data elements
 First Normal Form:
Find the key with which you can find all data
 Second Normal Form:
Remove part-key dependencies. Make all data dependent on the whole key.
 Third Normal Form
Remove non-key dependencies. Make all data dependent on nothing but the key.
For most practical purposes, databases are considered normalized if they adhere to third
normal form.

(1) First Normal Form (1NF)

Requires that all column values in a table are atomic (e.g., a number is an atomic value,
while a list or a set is not). We have two ways of achieving this:
 Putting each repeating group into a separate table and connecting them with a
primarykey-foreignkey relationship

AASTU Compiled by Chere L. (M.Tech) Page 6

 Fundamentals of Database System
 Moving this repeating groups to a new row by repeating the common attributes. If
so then Find the key with which you can find all data
Definition: a table (relation) is in 1NF if the following meet
 There are no duplicated rows in the table. Unique identifier
 Each cell is single-valued (i.e., there are no repeating groups).
 Entries in a column (attribute, field) are of the same kind.
Example for First Normal form (1NF )
Unnormalized
Emp First_ Last_ Skill SkillType School SchoolAdd Skill
ID Name Name Level

12 Abebe Mekuria SQL, Database, AAU, Sidist_Kilo 5

VB6 Programming Helico Piazza 8

16 Lemma Alemu C++ Programming Unity Gerji 6

IP Programming Jimma JimmaCity 4

28 Chane Kebede SQL Database AAU Sidist_Kilo 10

65 Almaz Belay SQL Database Helico Piazza 9

Prolog Programming Jimma JimmaCity 8
Java Programming AAU Sidist_Kilo 6

24 Dereje Tamiru Oracle Database Unity Gerji 5

94 Alem Kebede Cisco Networking AAU Sidist_Kilo 7

First Normal Form (1nf): Remove all repeating groups. Distribute the multi-valued
attributes into different rows and identify a unique identifier for the relation so that is can
be said is a relation in relational database.
Emp First LastName Skill Skill SkillType Schoo SchoolAdd Skill
ID Name ID l Level

12 Abebe Mekuria 1 SQL Database AAU Sidist_Kilo 5

12 Abebe Mekuria 3 VB6 Programming Helico Piazza 8

16 Lemma Alemu 2 C++ Programming Unity Gerji 6

16 Lemma Alemu 7 IP Programming Jimma JimmaCity 4

28 Chane Kebede 1 SQL Database AAU Sidist_Kilo 10

AASTU Compiled by Chere L. (M.Tech) Page 7

 Fundamentals of Database System
65 Almaz Belay 1 SQL Database Helico Piazza 9
65 Almaz Belay 5 Prolog Programming Jimma JimmaCity 8
65 Almaz Belay 8 Java Programming AAU Sidist_Kilo 6
24 Dereje Tamiru 4 Oracle Database Unity Gerji 5
94 Alem Kebede 6 Cisco Networking AAU Sidist_Kilo 7

(2) Second Normal form 2NF

No partial dependency of a non key attribute on part of the primary key. This will result
in a set of relations with a level of Second Normal Form.
Any table that is in 1NF and has a single-attribute (i.e., a non-composite) key is
automatically also in 2NF.
Definition: a table (relation) is in 2NF if the following meet
 It is in 1NF and
 If all non-key attributes are dependent on the entire primary key. i.e. no partial
dependency.
Example for 2NF:
EMP_PROJ
EmpID EmpName Proj ProjName Proj ProjFund ProjMang Incentive
No Loc ID

EMP_PROJ rearranged
EmpID Proj EmpName ProjName Proj ProjFund ProjMangID Incentiv
No Loc e

Business rule: Whenever an employee participates in a project, he/she will be entitled for
an incentive.
This schema is in its 1NF since we don’t have any repeating groups or attributes with
multi-valued property. To convert it to a 2NF we need to remove all partial dependencies
of non key attributes on part of the primary key.
{EmpID, ProjNo}
EmpName, ProjName, ProjLoc, ProjFund, ProjMangID, Incentive
But in addition to this we have the following dependencies
FD1: {EmpID}
EmpName
FD2: {ProjNo}
ProjName, ProjLoc, ProjFund, ProjMangID
FD3: {EmpID, ProjNo}
Incentive

AASTU Compiled by Chere L. (M.Tech) Page 8

 Fundamentals of Database System
As we can see, some non key attributes are partially dependent on some part of the
primary key. This can be witnessed by analyzing the first two functional dependencies
(FD1 and FD2). Thus, each Functional Dependencies, with their dependent attributes
should be moved to a new relation where the Determinant will be the Primary Key for
each.
EMPLOYEE
EmpID EmpName

PROJECT
ProjNo ProjName ProjLoc ProjFund ProjMangID

EMP_PROJ
EmpID ProjNo Incentive

(3) Third Normal Form (3NF )

Eliminate Columns Dependent on another non-Primary Key - If attributes do not
contribute to a description of the key, remove them to a separate table.
This level avoids update and delete anomalies.
Definition: a Table (Relation) is in 3NF if the following meet
 It is in 2NF and
 There are no transitive dependencies between a primary key and non-primary
key attributes.
Example for (3NF)
Assumption: Students of same batch (same year) live in one building or dormitory
STUDENT
StudID Stud_F_Name Stud_L_Name Dept Year Dormitary
125/97 Abebe Mekuria Info Sc 1 401
654/95 Lemma Alemu Geog 3 403
842/95 Chane Kebede CompSc 3 403
165/97 Alem Kebede InfoSc 1 401
985/95 Almaz Belay Geog 3 403

AASTU Compiled by Chere L. (M.Tech) Page 9

 Fundamentals of Database System
This schema is in its 2NF since the primary key is a single attribute.
Let’s take StudID, Year and Dormitaryand see the dependencies.
StudID
Year AND Year
Dormitary
And Year cannot determine StudID and Dormitary cannot determine StudIDThen
transitively StudID
Dormitary
To convert it to a 3NF we need to remove all transitive dependencies of non key
attributes on another non-key attribute.
The non-primary key attributes, dependent on each other will be moved to another table
and linked with the main table using Candidate Key- Foreign Key relationship.
STUDENT DORM

StudID Stud Stud Dept Year

Year Dormitary
F_Name L_Name
1 401
125/97 Abebe Mekuria Info Sc 1
3 403
654/95 Lemma Alemu Geog 3
842/95 Chane Kebede CompSc 3
165/97 Alem Kebede InfoSc 1
985/95 Almaz Belay Geog 3

Generally, even though there are other four additional levels of Normalization, a table is
said to be normalized if it reaches 3NF. A database with all tables in the 3NF is said to be
Normalized Database.
Mnemonic for remembering the rationale for normalization up to 3NF could be the
following:
 No Repeating or Redunduncy: no repeting fields in the table.
 The Fields Depend Upon the Key: the table should solely depend on the key.
 The Whole Key: no partial keybdependency.
 And Nothing But The Key: no inter data dependency.
 So Help Me Codd: since Coddcame up with these rules.

AASTU Compiled by Chere L. (M.Tech) Page 10

 Fundamentals of Database System
5.1.5 Other Levels of Normalization

Boyce-CoddNormal Form (BCNF):

Isolate Independent Multiple Relationships - No table may contain two or more 1:n or
N:M relationships that are not directly related.
The correct solution, to cause the model to be in 4th normal form, is to ensure that all
M:M relationships are resolved independently if they are indeed independent, as shown
below.
Def: A table is in BCNF if it is in 3NF and if every determinant is a candidate key.

Forth Normal form (4NF)

Isolate Semantically Related Multiple Relationships - There may be practical constrains
on information that justify separating logically related many-to-many relationships.
Def: A table is in 4NF if it is in BCNF and if it has no multi-valued dependencies.

Fifth Normal Form (5NF)

A model limited to only simple (elemental) facts, as expressed in ORM.
Def: A table is in 5NF, also called "Projection-Join Normal Form" (PJNF), if it is
in 4NF and if every join dependency in the table is a consequence of the
candidate keys of the table.

Domain-Key Normal Form (DKNF)

A model free from all modification anomalies.
Def: A table is in DKNF if every constraint on the table is a logical consequence
of the definition of keys and domains.
The underlying ideas in normalization are simple enough. Through normalization we
want to design for our relational database a set of tables that;
(1) Contain all the data necessary for the purposes that the database is to serve,
(2) Have as little redundancy as possible,
(3) Accommodate multiple values for types of data that require them,
(4) Permit efficient updates of the data in the database, and
(5) Avoid the danger of losing data unknowingly.

AASTU Compiled by Chere L. (M.Tech) Page 11

 Fundamentals of Database System

5.1.6 Pitfalls of Normalization

 Requires data to see the problems
 May reduce performance of the system
 Is time consuming,
 Difficult to design and apply and
 Prone to human error

AASTU Compiled by Chere L. (M.Tech) Page 12

 Fundamentals of Database System
6.2 Physical Database Design
We have established that there are three levels of database design:
• Conceptual: producing a data model which accounts for the relevant entities and relationships
within the target application domain;
• Logical: ensuring, via normalization procedures and the definition of integrity rules, that the
stored database will be non-redundant and properly connected;
• Physical: specifying how database records are stored, accessed and related to ensure adequate
performance.

It is considered desirable to keep these three levels quite separate -- one of Codd's requirements for an
RDBMS is that it should maintain logical-physical data independence. The generality of the relational
model means that RDBMSs are potentially less efficient than those based on one of the older data
models where access paths were specified once and for all at the design stage. However the relational
data model does not preclude the use of traditional techniques for accessing data - it is still essential to
exploit them to achieve adequate performance with a database of any size.
We can consider the topic of physical database design from three aspects:
• What techniques for storing and finding data exist
• Which are implemented within a particular DBMS
• Which might be selected by the designer for a given application knowing the properties of the
data
Thus the purpose of physical database design is:
1. How to map the logical database design to a physical database design.
2. How to design base relations for target DBMS.
3. How to design enterprise constraints for target DBMS.
4. How to select appropriate file organizations based on analysis of transactions.
5. When to use secondary indexes to improve performance.
6. How to estimate the size of the database
7. How to design user views
8. How to design security mechanisms to satisfy user requirements.

Physical database design is the process of producing a description of the implementation of the database
on secondary storage.

Physical design describes the base relation, file organization, and indexes used to achieve efficient
access to the data, and any associated integrity constraints and security measures.

AASTU Compiled by Chere L. (M.Tech) Page 13

 Fundamentals of Database System
• Sources of information for the physical design process include global logical data model and
documentation that describes model.
• Logical database design is concerned with the what; physical database design is concerned with
the how.
• The process of producing a description of the implementation of the database on secondary
storage.
• Describes the storage structures and access methods used to achieve efficient access to the data.

6.2.1 Steps in physical database design

1. Translate logical data model for target DBMS
1.1. Design base relation
1.2. Design representation of derived data
1.3. Design enterprise constraint
2. Design physical representation
1.1. Analyze transactions
1.2. Choose file organization
1.3. Choose indexes
1.4. Estimate disk space and system requirement
3. Design user view
4. Design security mechanisms
5. Consider controlled redundancy
6. Monitor and tune the operational system

6.2.2 Translate Logical Data Model for Target DBMS

This phase is the translation of the global logical data model to produce a relational database schema in
the target DBMS. This includes creating the data dictionary based on the logical model and information
gathered.
After the creation of the data dictionary, the next activity is to understand the functionality of the target
DBMS so that all necessary requirements are fulfilled for the database intended to be developed.
Knowledge of the DBMS includes:
 how to create base relations
 whether the system supports:
o definition of Primary key o definition of Alternate key
o definition of Foreign key o definition of Domains
o Referential integrity constraints
o definition of enterprise level constraints

AASTU Compiled by Chere L. (M.Tech) Page 14

 Fundamentals of Database System
a) Design base relation
To decide how to represent base relations identified in global logical model in target DBMS.
Designing base relation involves identification of all necessary requirements about a relation starting
from the name up to the referential integrity constraints.
For each relation, need to define:
• The name of the relation;
• A list of simple attributes in brackets;
• The PK and, where appropriate, AKs and FKs.
• A list of any derived attributes and how they should be computed;
• Referential integrity constraints for any FKs identified.
For each attribute, need to define:
• Its domain, consisting of a data type, length, and any constraints on the domain;
• An optional default value for the attribute;
• Whether the attribute can hold nulls.
The implementation of the physical model is dependent on the target DBMS since some has more
facilities than the other in defining database definitions.
The base relation design along with every justifiable reason should be fully documented.

b) Design representation of derived data

While analyzing the requirement of users, we may encounter that there are some attributes holding data
that will be derived from existing or other attributes. A decision on how to represent any derived data
present in the global logical data model in the target DBMS should be devised.
Examine logical data model and data dictionary, and produce list of all derived attributes. Most of the
time derived attributes are not expressed in the logical model but will be included in the data dictionary.
Whether to store derived attributes in a base relation or calculate them when required is a decision to be
made by the designer considering the performance impact.
Option selected is based on:
• Additional cost to store the derived data and keep it consistent with operational data from which
it is derived;
• Cost to calculate it each time it is required.
Less expensive option is chosen subject to performance constraints.
The representation of derived attributes should be fully documented.

AASTU Compiled by Chere L. (M.Tech) Page 15

 Fundamentals of Database System
c) Design enterprise constraint
Data in the database is not only subjected to constraints on the database and the data model used but also
with some enterprise dependent constraints. These constraint definitions are also dependent on the
DBMS selected and enterprise level requirements.
One need to know the functionalities of the DBMS since in designing the enterprise constraints for the
target DBMS some DBMS provide more facilities than others.
All the enterprise level constraints and the definition method in the target DBMS should be fully
documented.
6.2.3 Design physical representation
This phase is the level for determining the optimal file organizations to store the base relations and the
indexes that are required to achieve acceptable performance; that is, the way in which relations and
tuples will be held on secondary storage.
Number of factors that may be used to measure efficiency:
• Transaction throughput: number of transactions processed in given time interval.
• Response time: elapsed time for completion of a single transaction.
• Disk storage: amount of disk space required to store database files.
However, no one factor is always correct.
Typically, have to trade one factor off against another to achieve a reasonable balance.
a) Analyze transactions
To understand the functionality of the transactions that will run on the database and to analyze the
important transactions.
Attempt to identify performance criteria, e.g.:
• Transactions that run frequently and will have a significant impact on performance;
• Transactions that are critical to the business;
• Times during the day/week when there will be a high demand made on the database (called the
peak load).
Use this information to identify the parts of the database that may cause performance problems.
To select appropriate file organizations and indexes, also need to know high-level functionality of the
transactions, such as:
• Attributes that are updated in an update transaction;
• Criteria used to restrict tuples that are retrieved in a query.
Often not possible to analyze all expected transactions, so investigate most ‘important’ ones.

AASTU Compiled by Chere L. (M.Tech) Page 16

 Fundamentals of Database System
To help identify which transactions to investigate, can use:
• Transaction/relation cross-reference matrix, showing relations that each transaction accesses,
and/or
• Transaction usage map, indicating which relations are potentially heavily used.

To focus on areas that may be problematic:

1. Map all transaction paths to relations.
2. Determine which relations are most frequently accessed by transactions.
3. Analyze the data usage of selected transactions that involve these relations.

b) Choose file organization

To determine an efficient file organization for each base relation
File organizations include Heap, Hash, Indexed Sequential Access Method (ISAM), B+-Tree, and
Clusters.

c) Choose indexes
To determine whether adding indexes will improve the performance of the system.
One approach is to keep tuples unordered and create as many secondary indexes as necessary.
Another approach is to order tuples in the relation by specifying a primary or clustering index.
In this case, choose the attribute for ordering or clustering the tuples as:
• Attribute that is used most often for join operations - this makes join operation more efficient, or
• Attribute that is used most often to access the tuples in a relation in order of that attribute.
If ordering attribute chosen is key of relation, index will be a primary index; otherwise, index will be a
clustering index.
Each relation can only have either a primary index or a clustering index.
Secondary indexes provide a mechanism for specifying an additional key for a base relation that can be
used to retrieve data more efficiently.
Overhead involved in maintenance and use of secondary indexes that has to be balanced against
performance improvement gained when retrieving data.
This includes:
• Adding an index record to every secondary index whenever tuple is inserted;
• Updating a secondary index when corresponding tuple is updated;
• Increase in disk space needed to store the secondary index;
• Possible performance degradation during query optimization to consider all secondary
indexes.

AASTU Compiled by Chere L. (M.Tech) Page 17

 Fundamentals of Database System
Guidelines for Choosing Indexes
(1) Do not index small relations.
(2) Index PK of a relation if it is not a key of the file organization.
(3) Add secondary index to a FK if it is frequently accessed.
(4) Add secondary index to any attribute that is heavily used as a secondary key.
(5) Add secondary index on attributes that are involved in: selection or join criteria; ORDER
BY; GROUP BY; and other operations involving sorting (such as UNION or DISTINCT).
(6) Add secondary index on attributes involved in built-in functions.
(7) Add secondary index on attributes that could result in an index-only plan.
(8) Avoid indexing an attribute or relation that is frequently updated.
(9) Avoid indexing an attribute if the query will retrieve a significant proportion of the tuples
in the relation.
(10) Avoid indexing attributes that consist of long character strings.

d) Estimate disk space and system requirement

To estimate the amount of disk space that will be required by the database.
Purpose:
• If system already exists: is there adequate storage?
• If procuring new system: what storage will be required?

6.2.4 Design user view

To design the user views that was identified during the Requirements
Collection and Analysis stage of the relational database application lifecycle.
Define views in DDL to provide user views identified in data model
Map onto objects in physical data model

6.2.5 Design security mechanisms

To design the security measures for the database as specified by the users.
 System security
 Data security

6.2.6 Consider the Introduction of Controlled Redundancy

To determine whether introducing redundancy in a controlled manner by relaxing the normalization
rules will improve the performance of the system.

AASTU Compiled by Chere L. (M.Tech) Page 18

 Fundamentals of Database System
Result of normalization is a logical database design that is structurally consistent and has minimal
redundancy.
However, sometimes a normalized database design does not provide maximum processing efficiency.
It may be necessary to accept the loss of some of the benefits of a fully normalized design in favor of
performance.
Also consider that denormalization:
• Makes implementation more complex;
• Often sacrifices flexibility;
• May speed up retrievals but it slows down updates.
Denormalization refers to a refinement to relational schema such that the degree of normalization for a
modified relation is less than the degree of at least one of the original relations.
Also use term more loosely to refer to situations where two relations are combined into one new
relation, which is still normalized but contains more nulls than original relations.
Consider denormalization in following situations, specifically to speed up frequent or critical
transactions:
• Step 1 Combining 1:1 relationships
• Step 2 Duplicating non-key attributes in 1:* relationships to reduce joins
• Step 3 Duplicating foreign key attributes in 1:* relationships to reduce joins
• Step 4 Introducing repeating groups
• Step 5 Merging lookup tables with base relations
• Step 6 Creating extract tables.

6.2.7 Monitoring and Tuning the operational system

Meaning of denormalization
When to denormalize to improve performance
Importance of monitoring and tuning the operational system
To monitor operational system and improve performance of system to correct inappropriate design
decisions or reflect changing requirements.

AASTU Compiled by Chere L. (M.Tech) Page 19