LOGICAL DATABASE DESIGN pptx

2A.1 Relational Database Desi
g
n
L
L
E
E
S
S
S
S
O
O
N
N
:
:
2
2
A
A
L
L
O
O
G
G
I
I
C
C

A
A
L
L
D
D
A
A
T
T
A
A
B
B
A
A
S
S
E
E
D
D
E
E
S
S
I
I
G
G

N
N
O
O
b
b
j
j
e
e
c
c
t
t
i
i
v
v
e
e
s
s
In this lesson, you will learn to:

Map an E/R Diagram to Tables in relation to the following:
x Regular entities
x Attributes
x Relationships
x Weak entities
x Subtypes and supertypes

 Identify keys
 Define Specialization and Generalization
2A.2
Relational Database Desi
g
n
Logical Database Design Lesson 2A / Slide 1 of 15©NIIT
Logical Database Design
Objectives
In this section, you will learn to:
•
Map an E/R diagram to tables in relation to the following:
•
Regular entities
•
Attributes
•
Relationships
•
Weak entities
•
Subtypes and supertypes
•
Identify keys
•
Define Specialization and Generalization
I
I
N
N

S
S
T
T
R
R
U
U
C
C
T
T
O
O
R
R
N
N
O
O
T
T
E
E
S
S
Lesson Overview
The lesson introduces the concept of mapping E/R diagrams to tables with respect to
regular entities, weak entities, relationships, attributes, subtypes, and supertypes.
This lesson also contains tips for logical database design and covers the various types

of keys and their applications. In addition, this lesson explains specialization and
generalization of entities.
2A.3 Relational Database Desi
g
n
Logical Database Design Lesson 2A / Slide 2 of 15©NIIT
Logical Database Design
Pre-assessment Questions
1. In an E/R diagram, an entity is represented as a ______.
a. Diamond
b. Line
c. Box
d. Oval
2. Which of the following denotes an association between entity types?
a. Relation
b. Relationship
c. Relationship type
d. Relation type
3. Which data model has the database structured in fixed-format records of several
types?
a. Relational model
b. Object-based logical model
c. Network model
d. Hierarchical model
2A.4
Relational Database Desi
g
n
Logical Database Design Lesson 2A / Slide 3 of 15©NIIT
Logical Database Design

Pre-assessment Questions (Contd )
4. A(n) ______ is a pool of values from which one or more attributes draw their
actual values.
a. Relation
b. Domain
c. Entity
d. Supertype
5. Which of the following features is essential for two tables to be union compatible?
a. Attributes with same data types
b. Attributes with same data
c. Attributes with unique data
d. Attributes with different data types
2A.5 Relational Database Desi
g
n
Logical Database Design Lesson 2A / Slide 4 of 15©NIIT
Logical Database Design
Solutions
Ans1. Box
Ans2. Relationship type
Ans3. Hierarchical model
Ans4. Domain
Ans5. Attributes with same data types
2A.6
Relational Database Desi
g
n
C
C
O

O
N
N
C
C
E
E
P
P
T
T
U
U
A
A
L
L
M
M
O
O
D
D
E
E
L
L
Logical Database Design Lesson 2A / Slide 5 of 15©NIIT
Logical Database Design
Conceptual Model

•
The conceptual model reflects entities and their relationships based
on the data-processing needs of an organization.
•
The conceptual model can be mapped to a relational, hierarchical,
or a network model.
•
The conceptual model is independent of individual applications,
database management systems, hardware, and physical storage of
data.
•
Data analysis is the first step in designing a conceptual model and
begins with collecting data.
•
Data analysis involves identifying entities, their attributes, and the
relationships between entities based on the data collected.
•
The next step is to check all the operational and data processing
uses of the organization’s data, and to eliminate any unnecessary
or repeating data.
•
After completing data analysis, you draw the entity-relationship
diagram. This diagram gives an intuitive overview of the design
and is particularly good for communicating ideas to users.
The conceptual model reflects entities and their relationships based on the data-
processing needs of an organization. To develop a database that satisfies the
information needs of the present as well as the future, you must design a conceptual
model of the database first.
The conceptual model design is not concerned with the implementation and operation
phases of the database. The conceptual model can be mapped to a relational,

hierarchical, or a network model. It is independent of individual applications, database
management systems, hardware, and physical storage of data.
Data analysis is the first step in designing a conceptual model, and begins with
collecting information about data. This usually involves using a questionnaire or any
similar method to obtain a list of data that an organization needs. Existing forms, bills,
2A.7 Relational Database Desi
g
n
and reports are the starting points for data collection. The next step is to check all the
operational and data processing uses of the organization’s data, and to eliminate any
unnecessary or repeating data.
Data analysis involves identifying entities, their attributes, and the relationships
between entities based on the data collected.
After you complete data analysis, you draw the entity-relationship diagram. This
diagram gives an intuitive overview of the design, and is particularly good for
communicating ideas to users. The mapping of real objects to the symbols of the
entity-relationship is subjective. Often, something that was originally defined as an
attribute may later, after design review iterations, become an entity. There are no
stated rules to identify an object as an entity or attribute or relationship.
Mapping Entity-Relationship Diagrams to Tables
Logical Database Design Lesson 2A / Slide 6 of 15©NIIT
Logical Database Design
Mapping Entity- Relationship
Diagrams to Tables
•
A database that conforms to an E/R diagram can be represented by
a collection of tables in the relational system.
•
E/R diagrams can be mapped to tables in relation to the following:
•

Regular entities
•
Attributes
•
Relationships
•
Weak entities
•
Subtypes and supertypes
A database that conforms to an E/R diagram can be represented by a collection of
tables in the relational system. Let’s discuss the mapping of E/R diagrams to tables in
relation to the following:
Regular entities
2A.8
Relational Database Desi
g
n
Attributes
Relationships
Weak entities
Subtypes and supertypes
Regular Entities
Logical Database Design Lesson 2A / Slide 7 of 15©NIIT
Logical Database Design
Regular Entities
•
Regular entities are independent entities.
•
They are the “building blocks” of the database and can exist in
isolation, independent of any other entity.

•
Each regular entity maps to a table.
You will recall that regular entities are not dependent. They can exist in isolation,
independent of any other entity. They are the “building blocks” of the database. Each
regular entity maps to a table. For example, consider the following E/R diagram:
Regular Entities
STUDENT
BOOKS
ISSUES
2A.9 Relational Database Desi
g
n
The regular entities STUDENT and BOOKS map to two separate tables.
Attributes
Logical Database Design Lesson 2A / Slide 8 of 15©NIIT
Logical Database Design
Attributes
•
Attributes are properties of entities.
•
Each attribute in an E/R diagram maps to an attribute in the
appropriate table.
Each property or attribute shown in the E/R diagram maps to an attribute in the
appropriate table (refer to the figure below). Properties or attributes of STUDENT and
BOOKS map to attributes in the relevant tables.
STUDENT BOOKS
ROLL_NO NAME ADDRESS CODE DESC PRICE

2A.10
Relational Database Desi

g
n



Attributes
The primary key in the table is identified as the key in the E/R diagram, that is,
ROLL_NO and CODE. Remember that the primary key must be able to uniquely
identify each tuple in the table.
Relationships
Logical Database Design Lesson 2A / Slide 9 of 15©NIIT
Logical Database Design
Relationships
•
The mapping of relationships depends on the type of relationship.
•
Each type of relationship maps to tables in a different manner in
the relational database management system.
•
There should be a minimum number of tables with a minimum
number of attributes.
•
A join operation retrieves all information by combining two or more
tables.
ROLL_NO
STUDENT
ISSUES
PRICE
NAME ADDRESS
CODE

DESC
BOOKS
2A.11 Relational Database Desi
g
n
The mapping of relationships depends on the type of relationship, which we discussed
in the previous session. Each type of relationship maps to tables in a different manner
in the relational database management system.
The most important principle is to create tables where information from the real world
is stored and retrieved in an optimal way; that is, a minimum number of tables with a
minimum number of attributes. In a relational system, a join operation retrieves all
information by combining two or more tables.
One-to-One Relationship
In one-to-one relationships, one instance of an entity can relate to only one instance
of the related entity.
For example, assume that a student can do only one project and no other student can
do the same project. Then, there is a one-to-one relation between the student and the
project.
You represent a relationship between the two entities Student and Project in the
form of an E/R diagram as follows:
One-to-One Relationship
This type of relationship can be handled in several ways. One way to handle it is in the
same manner as a one-to-many relationship by storing a foreign key in either table.
Another way is to merge the two tables into one for faster access. For example, if
frequent queries required data from the two tables Student and Project, then it may
be better to merge the two tables to improve query performance.
2A.12
Relational Database Desi
g
n

Student
ROLL_NO Name Address Project Project
Duration
R0011 Paul CA Banking 16
R0012 Martha NY Sales
Order
20
R0013 Chris CA Invoicing 16
One-to-Many Relationship
In a one-to-many relationship, one instance of an entity can relate to more than one
instance of the related entity.
For example, a department has more than one employee.
2A.13 Relational Database Desi
g
n
You represent the relationship between an employee and a department in the form of
an E/R diagram as follows:
Mapping One-to-Many Relationship
The Dept_ID of an employee can be stored in the Employee table as shown.
Therefore, Dept_ID in the Employee table is foreign key in the Employee table.
Many-to-Many Relationship
Consider the following diagram:
Many-to-Many Relationship
One student can issue many books and one book can be issued to many students. The
relationship ISSUES associates students to books. ISSUES may have some attributes
Department Employee
Dept_ID Dept
Name
Dept
Head

Emp_ID Name Address Dept_ID
D001 Marketing John
S.
E001 Robert P. NY D001
D002 Accounts Tony
D.
E002 Polly W. CA D001

E003 David J. CA D002

E004 Nelson G. NY D002
2A.14
Relational Database Desi
g
n
that are unique to it, for example, the date on which the book was issued and the date
on which the book has to be returned. Therefore, you must understand that attributes
do not belong only to entities. They can also belong to relationships. The relationship
ISSUES is a many-to-many relationship. Such a relationship maps to a table.
The new table ISSUE must include the primary keys of both the tables, STUDENT
and BOOKS (ROLL_NO and CODE). These are foreign keys in the ISSUE table that
help join the two tables, STUDENT and BOOKS.

ROLL_NO NAME ADDRESS CODE DESC PRICE

ROLL_NO CODE ISSUE_DATE RETURN_DATE

Mapping Relationships
Recall the join operation discussed in relational algebra. Assume that a user wants to
know which book was issued to a particular student, and on which date. You can use

the foreign keys in the ISSUE table to make a join involving all three tables. This gives
a complete description of the issued transaction, as shown below.
ROLL_NO NAME ADDRESS CODE DESC ISSUE
_DATE
RETURN
_DATE

Joining Tables
What is the primary key of the ISSUE table? There are two possibilities. One
possibility is to take a combination of the two foreign keys (ROLL_NO and CODE) if
the combination uniquely identifies every row in the table. The resulting key is known
as a composite key, that is, a key made up of more than one attribute. Another
possibility is to create a new attribute for the primary key, for example ISSUENUM.
2A.15 Relational Database Desi
g
n
ROLL_NO CODE ISSUE_DATE RETURN_DATE
ISSUENUM ROLL_NO CODE ISSUE_DATE RETURN_DATE
You represent the type of relationship between two entities in an entity-relationship
diagram by certain symbols. An entity may be associated with one, none, or many
occurrences of another entity.
Weak Entities
Logical Database Design Lesson 2A / Slide 10 of 15©NIIT
Logical Database Design
Weak Entities
•
A weak entity is an entity whose existence depends on some other
entity.
•
The weak entity can be mapped to a separate table.

Composite Key
Primary Key
2A.16
Relational Database Desi
g
n
A weak entity is an entity whose existence depends on some other entity. For
example, the dependents of an employee.
Weak Entity
In the above example, we have a weak entity called DEPENDENT that depends on the
entity EMPLOYEE. The DEPENDENT entity can be mapped to a separate table as
follows:
DEPNO EMPNO DNAME

Weak Entity Mapping to a Table
2A.17 Relational Database Desi
g
n
Subtypes and Supertypes
Logical Database Design Lesson 2A / Slide 11 of 15©NIIT
Logical Database Design
Subtypes and Supertypes
•
A subtype is a subset of another entity.
•
A subtype is always dependent on the supertype for its existence.
•
Each entity type (subtype or supertype) maps to a separate table.
•
The primary key of the supertype is the foreign key of the subtype.

It creates a link between the two.
•
The foreign key of the subtype is also its primary key.
A subtype is a subset of another entity. A subtype is always dependent on supertype
for its existence.
2A.18
Relational Database Desi
g
n
Subtypes and Supertypes
Each entity type (subtype or supertype) maps to a separate table (see the example
below).
EMPLOYEE
EMPNO NAME ADDRESS

HOURLY EMPLOYEE SALARIED EMPLOYEE
EMPNO WAGES OVERTIME EMPNO SALARY BONUS CONV_
ALLOW

Mapping Subtypes and Supertypes
The primary key of the supertype is the foreign key of the subtype. It creates a link
between the two. The foreign key of the subtype is also its primary key. A coded
attribute may be included in the EMPLOYEE table to indicate the subtype, for example,
“S” for salaried employees, and “H” for hourly employees.
HOURLY EMPLOYEE SALARIED EMPLOYEE
Foreign Key
2A.19 Relational Database Desi
g
n
EMPNO WAGES OVERTIME EMPNO SALARY BONUS CONV_

ALLOW
H001 - - S001 - - -
H002 - - S002 - - -
HOO3 - - S003 - - -
Table Structure with the Coded Attribute
Tips on Logical Database Design
Logical Database Design Lesson 2A / Slide 12 of 15©NIIT
Logical Database Design
Tips on Logical Database Design
•
Do not introduce any unnecessary attributes.
•
Relational systems require keys that can uniquely identify the rows
of a table.
•
The different types of keys are:
•
Primary
•
Foreign
•
Candidate
•
Alternate
•
Composite
•
Some attributes may acquire further attributes to qualify
themselves during database design and become entities. You can
create a new entity to represent important recurring groups of

attributes.
2A.20
Relational Database Desi
g
n
Logical Database Design Lesson 2A / Slide 13 of 15©NIIT
Logical Database Design
Tips on Logical Database Design
(Contd )
•
Specialization is the result of taking a subset of a higher-level
entity set to form a lower-level entity set.
•
Generalization is the result of taking the union of two or more
lower-level entity sets to produce a higher-level entity set.
•
Generalization simplifies multiple references.
•
In generalization, every higher-level entity must also be a lower-
level entity. However, specialization does not have this constraint.
Here are some tips on database design. Remember that these are only guidelines.
Attributes
Do not introduce any unnecessary attributes. An attribute serves three purposes:
To identify its owner entity
To refer to another entity
To simplify the description of an entity
SALES
SNO DESCRIPTION ICODE

Attributes of a Table

Foreign
Key
Primary
Key
2A.21 Relational Database Desi
g
n
If there are any entities with common attributes, merge the entities. Remember that
the main objective is to come up with a database that has the minimum number of
tables with minimum number of attributes.
Merging Entities with Common Attributes
Keys
An RDBMS uses associative addressing; that is, it identifies and locates rows by value.
The physical address is transparent to the user. Therefore, relational systems require
keys that can uniquely identify the rows of a table.
There are various types of keys, some of which you are already familiar with. These
keys are:
Primary
Foreign
Candidate
Alternate
Composite
Any attribute (or set of attributes) that uniquely identifies a row in a table is a
candidate for the primary key. Such an attribute is called a candidate key. One of the
candidate keys is chosen to be the primary key, based on familiarity, greater usage,
and so on. Any attribute that is a candidate for the primary key but is not the primary
2A.22
Relational Database Desi
g
n

key is called the alternate key. When the key that uniquely identifies the rows of the
table is made up of more than one attribute, it is called a Composite key. Foreign keys
always represent relationships.
It is important to understand that the primary key is the only guaranteed way to
identify rows of a table. Therefore, NULL values are not permitted as primary keys. If
a primary key is allowed NULL values, it becomes difficult to identify the rows
uniquely.
Consider the following VEHICLE table:
Candidate, Primary, and Alternate Keys
In the above table, ENGINE# and REGN# are both individually unique in every tuple.
Therefore, they are both candidate keys. If ENGINE# is chosen as the primary key,
then REGN# is the alternate key.
Keys can be simple or composite. A simple key is composed of a single attribute. A
composite key, on the other hand, comprises two or more attributes.
Consider the following Accounts table:
Account
Number
Transaction
Date
Transaction
Time
Amount Description
A001 01/02/2001 12:30 P.M 1000.00 Deposit
A002 01/02/2001 12:30 P.M 2000.00 Deposit
A001 02/02/2001 10:30 A.M 3000.00 Deposit
In the above example, assume that only one transaction can take place for a given
account number at a time. We can select AccountNumber, TransactionDate and
TransactionTime as composite key.
ENGINE# REGN# DESCRIPTION
135268 2362 Honda

833647 7389 Mercedes
784799 8399 BMW
347889 9077 Rolls Royce
2A.23 Relational Database Desi
g
n
Entities
Some attributes may acquire further attributes to qualify themselves during database
design and become entities. You can create a new entity to represent important
recurring groups of attributes. For example, the attribute “address” may acquire
further attributes like “block”, “street”, “city”, “state”, and “pin”. In this case, the
attribute “address” becomes an entity as shown in the following example.
Attributes may Become Entities
Subentities
Consider the following example. The entity PLANT has the attributes shown in the
following diagram. However, some of the attributes do not apply to all plants. For
instance, the attribute “pressure” applies only to steam plants. In this case, all non-
steam plants have the value NULL stored in the “pressure” column. A good practice is
to replace optional attributes with subentities. This is also called specialization.
Specialization is the result of taking a subset of a higher-level entity set to form a
lower-level entity set. In this example, PLANT is the higher-level entity set, while
2A.24
Relational Database Desi
g
n
HYDRO, STEAM, and NUCLEAR are lower-level entity sets.
Specialization
Now, consider the opposite of the above example. Two entities, SAVING-ACCOUNT
and CURRENT-ACCOUNT, have some attributes that are common. In this case, a
better option is to create a new superentity to simplify multiple references. This is also

called generalization.
Generalization is the result of taking the union of two or more lower-level entity sets
to produce a higher-level entity set.
Generalization highlights the similarities between the lower-level
entity sets and hides their differences.
2A.25 Relational Database Desi
g
n
Generalization
Generalization is the opposite of specialization. In generalization, every higher-level
entity must also be a lower-level entity. For example, an account is a higher-level
entity, which has saving and current account as lower level entities. Specialization
does not have this constraint. For example, every account must either be a savings
account or a current account.
I
I
N
N
S
S
T
T
R
R
U
U
C
C
T
T

O
O
R
R
N
N
O
O
T
T
E
E
S
S
Conceptual Model
You can give the following additional information about weak entities:
A weak entity set depends on a regular or strong entity set for its existence. For
example, consider the entity sets book and issue with respect to a library. For a
particular book of the library, there may be several issue records. This is a one-to-
many relationship set from book to issue. Every issue must be associated with a book.
If the records of a book are deleted, all corresponding issue records of the book get
deleted. However, the entity issue can be deleted from the database without affecting
the book entity. Therefore, the entity issue is dependent on the entity book for its
existence. Hence, book is the strong entity and issue is the weak entity.