Download Introduction to Relational Database Management Systems

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.
©NIIT
•
Restrict
•
Project
•
Product
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
1.10 Implementing a Database Design Using Microsoft SQL Server 7.0
PARTS
©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.
SUPPLIER
m
m
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
NAME
NAME
CODE
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
PAY_D
1.12 Implementing a Database Design Using Microsoft SQL Server 7.0
CREDIT
CR LIMIT
CR_PERIOD
©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:
Employee
©NIIT
m
Belong
to
1
Department
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
Department
m
Has
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
relationships among these.
Represents data in the database as simple tables in the rowcolumn 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 Lockerno. Apart from the distinguishing attributes the sub-type entities also contain the primary key of the superentity.
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
©NIIT
Column
Data Type
Allow Null
Values
Description
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
Introduction to Relational Database Management Systems 1.17
Table Sector
Column
Data Type
Allow Null
Values
Description
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
Values
Description
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
Values
Description
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
Values
Description
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-tomany 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
ngth
iCurrentStrength
vSkill
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
ngth
iCurrentStrength
vSkill
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
©NIIT
•
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.
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
INSTRUCTOR
NAME
COURSE
NAME
ADDRESS
ROLL_NO
STUDENTS
Lesson 2
1.
2.
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
For the given E-R diagram:
City
CountryID
Shipping
Model ID
Order No.
Zip Code
1
Address
Last
Name
Recipient
m
First Name
Shopper
ID
Order
Gives
Order Date
Total
Cost
Cart ID
1.32 Implementing a Database Design Using Microsoft SQL Server 7.0
©NIIT
Table Structure can be:
Table Recipient
Order_No
(FK)
FirstName
LastName
Address
City
CountryID
ZipCode
Table Order
Order_No
(PK)
OrderDate
CartID
ShopperID
ShippingModeID
Total Cost
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
(PK)
©NIIT
Emp_name
Address
Department_Code
(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
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