Introduction to Relational Database

Management Systems

©NIIT Introduction to Relational Database Management Systems 1.1

1.2 Implementing a Database Design Using Microsoft SQL Server 7.0 ©NIIT
RATIONALE

Why This Module

Information is a critical factor for any business to be successful. Information is extracted from data stored in
databases. Today, Relational Databases are the most popular form of storing data. Besides storing data and
extracting information, a database has to be managed effectively. The software that is used to manage and
retrieve information in a relational database is called a Relational Database Management System (RDBMS).
This module aims at providing solid foundations in understanding a database design.

©NIIT Introduction to Relational Database Management Systems 1.3

OBJECTIVES

This module covers the concepts of a Relational Database Management System (RDBMS). The module
introduces you to some basic concepts of relational models. Elementary concepts like database, relation, and
normalization are also discussed.

The module starts with the basics of a Database Management System (DBMS) and then goes on to explain
terms like table, database, primary key, foreign key and composite key.

The module then explains the basics of the Relational Model and the Entity Relationship Model. The
method of creation of E/R diagrams and their mapping to tables is also covered in the lessons. The concepts
of normalization and denormalization are also explained in this module.

1.4 Implementing a Database Design Using Microsoft SQL Server 7.0 ©NIIT
ENTRY PROFILE

A student should have knowledge on the following topics before starting with the RDBMS module:

„ Interact in English in a classroom environment.

„ Build Flowcharts – the student should be able to represent logic, sequence tasks for execution, and
implement conditional operations and iteration.

©NIIT Introduction to Relational Database Management Systems 1.5

EXIT PROFILE

After completing this module, the student should be able to:

„ Appreciate the need for database management systems.

„ Design a database.

„ Apply the concepts of normalization and denormalization while designing a database.

1.6 Implementing a Database Design Using Microsoft SQL Server 7.0 ©NIIT
LESSON -W ISE INPUTS

Lesson One

Experiences
This lesson introduces the students to database management systems. Discuss the benefits of a database approach. It
also introduces the students to relational database design and describes data models and relational operators.
Explain the object-based logical model. Also explain the concept of entities, relationships, and attributes in
an entity-relationship model.

This lesson also explains the relational model.

Object-based Logical Model

„ Explain the various object-based logical models.

„ Explain the entity-relationship model.

„ Explain the various types of relationships. Also explain the concept of attributes, subtypes, and
supertypes.

• Highlight the guidelines for identifying an entity. Tell the students to underline all nouns in a
problem statement. Those nouns which form part of the scope of data storage will be the entities.
Do caution them that certain nouns might be attributes. Attributes are those, which describe an
entity. Also, tell them that entities are stored in a database in the form of tables.

• In most of the problem statements, the given attributes constitute a partial list. Ask the class to
identify the other attributes of an entity for which data can be captured.

Record-based Logical Model

„ Explain the various types of record-based logical models.

„ Explain the relational model.

„ Explain the various relational operators.

• Restrict

• Project

• Product

©NIIT Introduction to Relational Database Management Systems 1.7

 • Union

• Intersect

• Difference

• Join

• Divide

„ Give examples of some typical applications of an RDBMS.

This session is a packed session so please do a recap of this session before starting off with lesson-2 in the
next class.

Additional Inputs
A database is a collection of information organized in such a way that a computer program can quickly
select the desired data. You can think of a database as an electronic filing system.

Traditional databases are organized by fields, records, and files. A field is a single unit of information; a
record is one complete set of fields; and a file is a collection of records. For example, a telephone book is
analogous to a file. It contains a list of records, each of which consists of three fields: name, address, and
telephone number.

A relationship is an association established between the common fields (columns) in two tables. A
relationship can be one-to-one, one-to-many, or many-to-many.

A field is a space allocated for a particular item of information. For example, a tax form can contain a
number of fields to store information like your name, your Social Security number, your income, and so on.
In database systems, fields are the smallest units of information that can be accessed. In spreadsheets, fields
are referred to as cells.

Fields have certain attributes associated with them. For example, some fields are numeric whereas others are
textual. In addition, every field has a name, called the field name.

In an RDBMS, a field is also referred to as a key that you use to sort data. It can also be called a key field,
sort key, index, or key word. For example, if you sort records by age, then the age field is a key. Most
database management systems allow you to have more than one key so that you can sort records in different
ways. One of the keys is designated as the primary key, and must hold a unique value for each record. The
field that identifies records in a different table is called a foreign key.

Consider a situation where each customer is assigned a customer number. The customer number is unique
for that customer; this might be a customer number that is used by your company or a number that is
automatically assigned by the computer, which the user may never even see. It is essential, however, that
there be only one customer at any time having that customer number. The customer number uniquely
identifies each customer "record". A "record" is a single entry in a table; for instance, in the Customers
table, each customer's information constitutes a record; in the Sales table, each sale constitutes a record.

The customer number in the Customer table is called a "primary key".

1.8 Implementing a Database Design Using Microsoft SQL Server 7.0 ©NIIT
 A primary key is also required in the Sales table. In addition, the customer number of the customer should
also appear in this table as a "field". A field is a single type of information in a table; in the Customers table,
we would have a customer name field, a customer number field, etc.

The customer number in the Sales table is called a "foreign key". A foreign key is a copy of a primary key
that appears elsewhere.

Question: What kinds of fields make good primary keys?

Answer: One type of field that makes an excellent primary key is a "counter" field. This is a field with a
whole number as its value, which automatically creates a new, unique number for each record. As a rule,
numeric keys are preferable to text keys because they take up less memory and therefore are faster and
require less data storage space. The counter field additionally removes the concern of generating a unique
value for the primary key field for each new record.

Date/time stamps make tolerable primary keys in some RDBMSs, as long as the program is never being
used by more than one person at a time.

A social security number may not be the best primary key, for several reasons: first, they take up more digits
than would generally be required. Second, the U.S. government sometimes assigns the same social security
number twice (usually when the first holder is deceased). Third, anyone who is not a U.S. citizen may not
have a social security number. Fourth, we are told that it is not permissible by law to require a person to
supply their social security number; tax ID numbers can be assigned and used instead in some cases.

Two foreign keys can be collectively set to create a primary key, called a "compound key" (also referred to
as the composite key). Some RDBMSs will then automatically prevent the duplication of any combination
of those fields. Any number of fields may be identified as a compound key together. However, compound
keys should not be used too widely, as they are slower than single-field primary keys (since the RDBMS has
to check two or more full fields of information in each table rather than just one field). Also, compound keys
become awkward when more than two or three fields are in use, and it is more difficult to refer to specific
records through compound keys than through single keys.

You can take the following example to explain an entity:

„ BRANCHis a set of all branches of a particular bank.

„ CUSTOMERis a set all people who have their account in the bank.

„ EMPLOYEEis a set of all people who work in the bank.

„ ACCOUNTis a set of all accounts that are maintained in the bank.

You can take the following entities to explain an attribute:

„ BRANCHhas attributes such as branch_code, branch_name, and location.

„ CUSTOMERhas attributes such as customer_code, customer_name, customer_address, and

account_number.

„ EMPLOYEEhas attributes such as employee_code, employee_name, and employee_address.

„ ACCOUNThas attributes such as account_number, account_type, and balance_amount.

For the above mentioned entities and attributes, unique identifiers will be:

©NIIT Introduction to Relational Database Management Systems 1.9

 „ BRANCHbranch_code

„ CUSTOMERcustomer_code, account_number

„ EMPLOYEEemployee_code

„ ACCOUNTaccount_number

In a Hierarchical Database Management System (HDBMS) the data is stored conceptually in a hierarchical
format. An example of such kind of data storage is an XML data island where there is a root tag and there
are child tags below the root tag. Each of these child tags can in turn have child tags. This kind of a
formation resembles a tree. An example can be a Firm that can have a child called Factory(s), which in turn
can have a child called Employee(s). In an HDBMS a one-to-one or a one-to-many relationship can be very
easily implemented but implementing a many-to-many relationship is not possible. In a Networked Database
Management System (NDBMS) the child node of a HDBMS can be associated to multiple parent nodes.
Like HDBMS a many-to-many relationship cannot be implemented in an NDBMS.

Object-Relational Database Management System (ORDBMS) are extensions of existing RDBMS that can
be used to fulfill complex jobs of storing and managing objects. For instance using an ORDBMS image
objects can be stored and managed. Examples of ORDBMS are Informix Universal Server and Adaptive
Server of Sybase Inc.

Just a Minute…

The following statement has been extracted from a case presented by a manufacturer regarding the
maintenance of their data: “A supplier ships certain parts”. Identify the entities mentioned in this statement,
and their relationship. Draw a diagram depicting the relationship.
Solution
Entities: SUPPLIER, PARTS.
Relationship: SHIP (or SHIPMENT)

SUPPLIERS SHIP PARTS

1.10 Implementing a Database Design Using Microsoft SQL Server 7.0 ©NIIT
 Just a Minute…

1. What do the following E/R diagrams represent?

Solution
Many students can work on many projects.
Many employees belong to only one department.

2. Consider the following statement of a manufacturing company:

“ A supplier ships certain parts. A particular part is not necessarily shipped by only one supplier. No supplier
ships only a single part.”
What type of relationship is this? Draw a diagram to depict the relationship.
Solution
Many-to-many type.

m m
SUPPLIER SHIP PARTS

Just a Minute…

A manufacturer needs to maintain the following details about the supplier:

a. Name
b. Address
c. Credit status
d. Assigned code number
Draw a diagram to depict this information.

©NIIT Introduction to Relational Database Management Systems 1.11

 Solution
CODE NAME
NAME

SUPPLIER

ADD CR_STATUS

Just a Minute…

There are two types of suppliers. One type of supplier allows credit, while the other type insists on payment in cash
before delivery. The manufacturer wishes to maintain separate information on these two types of suppliers. For the
credit supplier, “credit period” and “credit limit” have to be recorded. For the cash supplier, “date of payment” has
to be stored. Represent this information diagrammatically.
Solution
SUPPLIERS

CASH CREDIT

PAY_D
CR LIMIT CR_PERIOD

1.12 Implementing a Database Design Using Microsoft SQL Server 7.0 ©NIIT
 Faculty Observations

©NIIT Introduction to Relational Database Management Systems 1.13

1.14 Implementing a Database Design Using Microsoft SQL Server 7.0 ©NIIT
Lesson Two

Experiences
This session defines the terms entity, relationship, and attribute with respect to the entity-relationship model.
Relationships should be discussed in detail with enough examples. The different types of relationships are
very important and should be made clear to the student. The symbols to represent the different types of
relationships between entities should be explained. The structure of a table and the concept of tuples and
attributes should be discussed in detail. Primary key and foreign key should be explained. Mapping E/R
diagrams to tables is very important.

Conceptual Model
„ Explain the conceptual model and then explain the following:

• Regular entities

• Attributes

• Relationships (many-to-many, many-to-one, one-to-many, and one-to-one)

• Weak entities

• Subtypes and supertypes

E/R Diagrams
„ Stress on the symbols used for depicting the entities, the attributes, and the relationship between the
entities.

„ Stress that there is no difference between a one-to-many and a many-to-one relationship except for the
fact as to how the entities are placed while drawing the E/R diagram. For example, the relationship
between a department and an employee can be represented in two ways.

Many employees belonging to a department can be represented as follows:

m Belong 1
Employee to Department

©NIIT Introduction to Relational Database Management Systems 1.15

 The above diagram can also be represented as follows which depicts a department having many employees.

1 m
Has
Department Employee

„ Stress the fact that in a one-to-many relationship, a common attribute is required to relate the two tables.

FAQs
Q: What is the difference between a database structure and an ER Diagram?

A:

E/R Diagram Database Structure

Is an Object-based model. Is a Record-based model.

Comprises of collection of objects or entities and the Represents data in the database as simple tables in the row-
relationships among these. column format

Can be mapped into a database structure

Q: What is the difference between a Weak Entity and a Sub Entity?

A: A Weak entity depends upon a regular entity for its existence whereas a Sub entity is part of a Regular
entity. For example, an entity called Students is used to store all student details. Now, every student is
enrolled for a course and there are some students who have taken a break from the course. In this kind of a
scenario, we can have a Sub entity called Break-Students, which stores details of all students who have
currently taken a break. Note that a Sub entity will contain all the columns of the super-entity from which it
is derived. A Weak entity on the other hand has attributes that are different from those of the regular entity
on which it is dependent.

Q: What is the difference between a Weak entity and a Regular entity?

A: A Weak entity depends upon a regular entity for its existence. For example, the entity called Children
depends on the entity Employee for its existence. If an Employee resigns, then the corresponding records for
the specific employee from the table Children is also removed.

Q: What is the difference between a Subtype and a Supertype?

A: The difference between a Subtype and a Supertype entity is best understood with an example. An entity
called Student has two sub entities Boarder and Day-scholar. Here, the entity Student stores details about
students like name, age, course, class etc. and has student-id as the primary key. The Boarder sub-type entity
has a distinguishing attribute Room-no while the Day-scholar entity, has a distinguishing attribute Locker-
no. Apart from the distinguishing attributes the sub-type entities also contain the primary key of the super-
entity.

Additional Inputs
The database design created from a well-prepared E/R Diagram will result in tables, which are fairly
normalized. To further reduce redundancy, you will need to normalize the tables and in certain situations,

1.16 Implementing a Database Design Using Microsoft SQL Server 7.0 ©NIIT
 because of system requirements, you may need to introduce some amount of redundancy by denormalizing
the tables. Tell the students that normalization will be discussed in detail later in the course.

Tips
„ Be comfortable with the types of relationships – one-to-one, one-to-many, many-to-one, and
many-to-many.

„ You should be able to look at a schema and identify the types of relationships and what data can be
captured in the same.

Just a Minute…

1. Define the following terms:

a. Candidate Key

b. Alternate Key
Solution
a. 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.

b. Any attribute that is a candidate for the primary key but is not the primary key is called the
alternate key.

Solutions: 2.P.1

Mapping the E/R Diagram to Tables

Table Aircraft

Column Data Type Allow Null Description

Values

aircraft_id (PK) char (4) No Aircraft Id. For example, it will store A330 for Airbus 330
and B747 for Boeing 747-400 aircraft

description varchar(50) No Aircraft description

first_class_seats int No The total number of first class seats in a particular type of an
aircraft

envoy_class_seats int No The total number of envoy class seats

coach_class_seats Int No The total number of coach class seats

©NIIT Introduction to Relational Database Management Systems 1.17

 Table Sector

Column Data Type Allow Null Description

Values

sector_id (PK) char(5) No Id for a particular sector where the flight operates

description varchar(50) No Sector description

week_day1 char(3) No Days of week when a flight covers the sector

week_day2 char(3) No

first_class_fare float No First class fare for a particular sector

envoy_class_fare float No Envoy class fare

coach_class_fare float No Coach class fare

Table Flight

Column Data Type Allow Null Description

Values

flight_no (PK) char(5) No Flight number

flight_date (PK) date No Date of flight

dep_time time No Departure time of flight

arr_time time No Arrival time of flight

aircraft_id (FK) char(4) No Aircraft id. Should exist in the Aircraft table.

sector_id (FK) char(5) No Sector where the flight operates. Should exist in the Sector
table

first_class_seats int No Number of first class seats available on a particular flight

envoy_class_seats int No Number of envoy class seats available on a particular flight

coach_class_seats int No Number of envoy class seats available on a particular flight

* Note: The number of seats in each class for a particular flight will be initialized based on the aircraft Id. Every time a
reservation takes place, the number of seats in this table will be decremented based on the class of travel chosen by
passenger. Similarly, in case of a cancellation, the number of available seats will be incremented. Though this is
redundant data, it is still maintained in this table for ease of use in queries.

Table Passenger

Column Data Type Allow Null Description

Values

pnr_no (PK) char(8) No Passenger Name Request (PNR) number

flight_no (FK) char(5) No Flight number

1.18 Implementing a Database Design Using Microsoft SQL Server 7.0 ©NIIT
 travel_date (FK) date No Date of travel. The flight number and the date of travel
together form a foreign key that references the flight number
and flight date in the Flight table.

name varchar(50) No Passenger name

age int No Passenger age

gender char(1) No Gender (Male/Female)

class char(1) No Class of travel (First/Envoy/Coach)

seat_pref char(1) No Seat preference (Aisle/Window)

seat_zone char(1) No Seat zone (Smoking/Non-smoking)

meal_pref char(1) No Meal preference

(Vegetarian/Non-vegetarian)

SSR varchar(100) No Special service request

status char(1) Yes Passenger status (Confirmed/overbooked/wait-listed)

cancel_flag char(1) No ‘Y’ if the passenger has cancelled the ticket, ‘N’ otherwise.

Table DailyCollection

Column Data Type Allow Null Description

Values

pnrno (FK) char(8) No PNR number. It references the PNR number from the
Passenger table

trans_date date No Date when the collection or refund took place

tran_type char(1) No ‘C’ for collection and ‘R’ for refund

amount float No Amount collected or refunded

*Note: This table is updated whenever a transaction such as a reservation, cancellation, or modification takes place.
This table is created for the purpose of generation of reports. Although this table is not depicted in the E/R diagram, it is
used to maintain a record of daily transactions.

©NIIT Introduction to Relational Database Management Systems 1.19

 Faculty Observations

1.20 Implementing a Database Design Using Microsoft SQL Server 7.0 ©NIIT
Lesson Three

Experiences
This session is an introduction to database design and SQL. The session starts with an introduction to normalization
and the types of normal forms. The Boyce-Codd normal form and denormalization are also explained in the
session.

Normalization
„ Explain the need for normalization.

„ Explain functional dependency.

„ Explain the first, second, and third normal forms.

„ Explain the Boyce-Codd normal form using examples.

Denormalization
„ Explain the concept of denormalization.

„ Explain relations with respect to domains. Also, explain the properties of relations.

„ Explain language support for the relational model.

Additional Inputs
„ Fourth Normal Form: If a relation has many-to-many relationships with two or more relations, then the
attributes of all the three or more relations cannot be depicted in the same relation. For the relations to
be in the fourth normal form, the relation has to be in the third normal form and each of the many-to-
many relationships should be assigned to separate relations. For example consider an entity called
Student has multiple Skills and has enrolled in multiple courses. Here the relationship between a
Student and Skills are many to many as one student can have multiple skills and the same skill can be
attributed to multiple students. Also one student can enroll for multiple courses and a course can have
multiple students. To be in the Fourth Normal form, you should have two relations Student-Course and
Student-Skill.

„ Fifth Normal Form: For a relation to be in the Fifth normal form it has to be in the Fourth Normal form
and abide by some business rules. Let us now understand the business rule involved in the Fifth normal
form with an example. A student is enrolled in one or more courses of the three available courses and
each course has two modules and there is a business rule which states that a student can be associated
with only one module at any time then there should be three relations: Course-Module, Course-Student
and Student-Module. If the business rule did not exist then there is no need of the fifth normal form.

©NIIT Introduction to Relational Database Management Systems 1.21

 Solutions

Just a Minute…

You have received a proposed table structure for the table Position. After testing the table structure with
some data, you find that there is a problem in inserting, deleting, and modifying data. You see that the table
structure could lead to inconsistency in data and is also occupying a lot of disk space.

The table structure is as follows:

Position

cPositionCode

vDescription

iBudgetedStrength

siYear

iCurrentStrength

vSkill

Sample data for the table Position is as shown below:

cPositionCode vDescription iBudgetedStre iCurrentStrength vSkill

ngth

0001 Sales Manager 100 82 Communication

0002 Marketing Manager 100 83 Presentation

0003 Financial Analyst 50 30 Team Leading

0004 Training Co-ord 20 15 Communication

0005 Database Analyst 10 8 Presentation

0006 Staff Accountant 20 18 Convincing

0007 Audit Manager 20 18 Planning

0008 Telephone Operator 20 18 Communication

0009 Office Clerk 20 18 Team Leading

0010 Legal Secretary 20 18 MS- Office

0011 Administrative Assistant 20 18 Interpersonal

1.22 Implementing a Database Design Using Microsoft SQL Server 7.0 ©NIIT
 cPositionCode vDescription iBudgetedStre iCurrentStrength vSkill
ngth

0012 Senior Receptionist 20 18 Communication

0013 Consultant 20 18 Team Leading

0014 Maintenance Technician 20 18 Presentation

0015 Receptionist 21 18 Convincing

Modify the above table structure to optimize data storage.

Solution
Use Normalization and break the table as follows:

Position BudgetedPositions PositionSkill

PositionCode PositionCode PositionCode
Description BudgetedStrength vSkill
CurrentStrength

Just a Minute…

In the reporting system, the total amount paid to a contract recruiter is often required. The required result
can be calculated using the two tables - Payment and ContractRecruiter.

ContractRecruiter Payment

cContractRecruiterCode cSourceCode

cName mAmount

vAddress cChequeNo

cCity dDate

cZip

cPhone

cFax

siPercentageCharge

©NIIT Introduction to Relational Database Management Systems 1.23

 Solution

Denormalize the tables. Add a column called mTotalPaid to the ContractRecruiter table.

ContractRecruiter

cContractRecruiterCode

cName

vAddress

cCity

cZip

cPhone

cFax

siPercentageCharge

mTotalPaid

Note: You can communicate to the students that the value of mTotalPaid will get automatically updated
through the usage of various tools provided by different RDBMS software’s.

Just a Minute…

Each time the salary slip for an employee is generated, the referral bonus (if present) has to be calculated
and printed in the salary slip. The following three tables are used for this query- MonthlySalary,
Employee, and EmployeeReferrals. The table structures are:

Employee MonthlySalary EmployeeReferrals

cEmployeeCode cEmployeeCode cEmployeeReferrralNo

vFirstname mMonthlySalary cEmployeeCode

vLastName dPayDate cCandidateCode

cCandidateCode

vAddress

cCity

cZip

cCountryCode

cPhone

1.24 Implementing a Database Design Using Microsoft SQL Server 7.0 ©NIIT
 vQualification

dBirthDate

cSex

cCurrentPosition

cDesignation

cEmailId

cDepartmentCode

cRegion

imPhoto

vSkill

dJoiningDate

dResignationDate

cSocialSecurityNo

However, since the tables structures are large, it is necessary to improve the performance of this query by
modifying the table structures.
Solution
Identify how to increase the performance of queries. Denormalize the tables by adding Referralbonus
attribute in the MonthlySalary table.

Employee MonthlySalary EmployeeReferrals

CEmployeeCode cEmployeeCode cEmpRefNo

VFirstName mMonthlySalary cEmployeeCode

VLastName dPayDate cCandidateCode

CCandidateCode Referralbonus

VAddress

CCity

CZip

CCountryCode

CPhone

VQualification

©NIIT Introduction to Relational Database Management Systems 1.25

 DBirthDate

CSex

CCurrentPosition

CDesignation

CEmailId

CDepartmentCode

cRegion

imPhoto

vSkill

dJoiningDate

dResignationDate

cSocialSecurityNo

Additional Exercises

To make students comfortable with Normalization, faculty can ask students to attempt the following
questions:

Q1. Following table is in 1ST NF. Convert the following table structure in 3RD NF.

Pno PName Eno EName JobProfile JobRate Hours

1 Toys 101 John News Eng. 65 13

1 Toys 102 David Talk Com. 60 16

1 Toys 103 Ann Smith Prog. 55 19

2 Books 101 John News Eng. 65 24

2 Books 103 Ann Smith Prog. 55 44

2 Books 104 Tom Jones Com. 60 11

Where:

• Pno is the project code

• PName is the project name.

• Eno is the employee code

1.26 Implementing a Database Design Using Microsoft SQL Server 7.0 ©NIIT
 • EName is the employee name.

• JobProfile is the designation.

• JobRate is the amount which is paid to the specific designation.

• Hours is the time taken by an employee to finish the project.

Sol:

Second Normal Form

• Find and remove attributes that are functionally dependent on only a part of the key and not on the
whole key. Place them in a different table.

• Group the remaining attributes.

So,

Project

Pno

PName

Employee

Eno

Ename

JobProfile

JobRate

Assignment

Pno

Eno

Hours

Third Normal Form

• Remove the non-key attributes that are functionally dependent on attributes that are not the primary
key. Place them in a different table.

• Group the remaining attributes.

©NIIT Introduction to Relational Database Management Systems 1.27

 Project

Pno

Pname

Employee

Eno

Ename

JobProfile

Assignment

Pno

Eno

Hours

Job

JobProfile

JobRate
Q2. Following table is in 1ST NF. Convert it into 2ND NF.

Rep ID* Rep First Name Rep Last Name Client ID* Client Time With Client
TS-89 Gilroy Gladstone 978 US Corp 14 hrs
TS-89 Gilroy Gladstone 665 Taggarts 26 hrs
TS-89 Gilroy Gladstone 782 Kilroy Inc. 9 hrs
RK-56 Mary Mayhem 221 Italiana 67 hrs
RK-56 Mary Mayhem 982 Linkers 2 hrs
RK-56 Mary Mayhem 665 Taggarts 4 hrs

Solution:

Rep ID* Client ID* Time With Client

TS-89 978 14 hrs
TS-89 665 26 hrs
TS-89 782 9 hrs
RK-56 221 67 hrs
RK-56 982 2 hrs
RK-56 665 4 hrs

The above table contains time card information.

1.28 Implementing a Database Design Using Microsoft SQL Server 7.0 ©NIIT
 Rep ID* First Name Last Name
TS-89 Gilroy Gladstone
RK-56 Mary Mayhem

The above table contains Employee Information.

Client ID* Client Name

978 US Corp
665 Taggarts
782 Kilroy Inc.
221 Italiana
982 Linkers

The above table contains Client Information

Q3: State the advantages of Third Normal Form.

Sol. Advantages of Third Normal Form:

The advantage of having relational tables in 3NF is that it eliminates redundant data, which in turn saves
space and reduces manipulation anomalies.

Q4: State the Benefits of Normalization.

Sol. Normalization provides following benefits to a database:

• The tables are narrower and have more records in a page, which results in less I/O.

• Database is organized.

• Reduction of redundant data

• Data consistency within the database

• Flexible database design

• Better handle on database security

Q5: Explain the Denormalization process.

Sol. Denormalization is the process of taking a normalized database and modifying table structures to allow
controlled redundancy for increased database performance. This is used to improve the performance a
database. A denormalized database is not the same as a database that has not been normalized.
Denormalizing a database is the process of taking the level of normalization within the database.
Normalization can slow down the performance of a database with its frequently table join operations.
Denormalization may involve recombining separate tables or creating duplicate data within tables to reduce
the number of tables that need to be joined to retrieve the requested data, which results in less I/O and CPU
time.

©NIIT Introduction to Relational Database Management Systems 1.29

 However, there are costs to denormalization. Data redundancy is increased in a denormalized database,
which can improve performance but requires more efforts to keep track of related data. Application coding
renders more complications, because the data has been spread across various tables and may be more
difficult to locate. In addition, referential integrity is more of a chore; related data has been divided among a
number of tables. The better way is to keep both normalization and denormalization, but to put it to practice
requires a thorough knowledge of the actual data and specific business requirements.

Q6: State the Drawbacks of Normalization process.

Sol. Although most successful databases are normalized to some degree, there is one substantial drawback
of a normalized database. Normalization slows down the database performance. The acceptance of reduced
performance requires the knowledge that a normalized database requires much more CPU, memory, and I/O
to process transactions and database queries than does a denormalized database. A normalized database
must locate the requested tables and then join the data from these tables to either get the requested
information or to process the desired data.

The primary disadvantage of normalization is that it increases the number of joins. Joins are a mechanism in
relational databases that let two tables with matching key values retrieve information from both the tables. It
is a disadvantage to have too many joins in a query because of the way the query optimizer works and
because of the number of I/Os that are required to retrieve all the information.

1.30 Implementing a Database Design Using Microsoft SQL Server 7.0 ©NIIT
 Faculty Observations

©NIIT Introduction to Relational Database Management Systems 1.31

SOLUTIONS TO A DDITIONAL EXERCISES
Lesson 1
1. Entities: Employee, Department.

Relationship: Works

Attributes: Emp_No, Name, Address, Dept_name, capacity

2. The entity-relationship diagram depicting the relationship between an instructor and students is as
follows: 1 m

TEACHES ROLL_NO
INSTRUCTOR STUDENTS

NAME ADDRESS NAME COURSE

Lesson 2
1. The relationships between the following entities is given below:

a. Mother and a Child: One to one

b. University and Faculty: One to Many

c. Airplane and Passengers: One to Many

2. For the given E-R diagram:

City CountryID Order No. Shipping

Zip Code Model ID

1 m
Order Shopper
Recipient Gives
Address ID

Last First Name Order Date Total

Name Cost

Cart ID

1.32 Implementing a Database Design Using Microsoft SQL Server 7.0 ©NIIT
 Table Structure can be:

Table Recipient

Order_No FirstName LastName Address City CountryID ZipCode

(FK)

Table Order

Order_No OrderDate CartID ShopperID ShippingModeID Total Cost

(PK)

Lesson 3
1. ORDER TABLE
OrderNo
OderDate
Total Cost

TOY TABLE
ToyID
ToyName

RECIPIENT TABLE
OrderNo
FirstName
LastName
Address
2. The following tables are in their normal forms.

Emp_code Emp_name Address Department_Code

(PK) (FK)

E001 Joseph H 44 Street Road D001

E002 Susan K 8 Bakers Street D002

E003 Samantha Thames 8 Street Lane D002

E004 Nancy Thomas Mark Lane 67 D001

E005 Catherine M 5 Bakers Street D001

E006 Mac James 99 Lancers Mall D001

©NIIT Introduction to Relational Database Management Systems 1.33

 DEPARTMENT TABLE

Department_Code Department_Name Department_Head

D001 Accounts John Fairbrother

D002 Marketing Cathy Thames

1.34 Implementing a Database Design Using Microsoft SQL Server 7.0 ©NIIT
 ADDITIONAL REFERENCE
„ C. J. Date: An Introduction to Database Systems

„ Henry F. Korth, Abraham Silberschatz: Database system Concepts

„ Michael J. Hernandez: Database Design for Mere Mortals: A Hands-On Guide to Relational Database
Design

„ Thomas M. Connolly, Carolyn E. Begg; Database Systems: A Practical Approach to Design,

Implementation, and Management (International Computer Science Series)

„ C. J. Date, Hugh Darwen: Foundation for Future Database Systems: The Third Manifesto

„ Jeffrey D. Ullman, Jennifer Widom: First Course in Database Systems, A

„ C. J. Date, What Not How: The Business Rules Approach to Application Development

„ Philip J. Pratt, Joseph J. Adamski: Database Systems : Management and Design

©NIIT Introduction to Relational Database Management Systems 1.35

SESSION P LAN: RDBMS
Cycle # Activity/Problem No. Duration (In
Mins)
Cycle1
OCR1
Lesson 1: Objectives 5
Database Management Systems 5
Data Models 10
Object-based Logical Model 25
Record-based Logical Model 20
Relational Operators 30
Applications of RDBMS 5
Summary 5
Total 105
Cycle2
OCR1
Lesson 2: Objectives 5
Conceptual Model 60
Tips on Local Database Design 20
2.P.1 10
Summary 10
Total 105
Cycle3
OCR1
Lesson 3: Objectives 5
Understanding Data Redundancy 80
Understanding Denormalization 20
Total 105

1.36 Implementing a Database Design Using Microsoft SQL Server 7.0 ©NIIT