Introduction to Relational Database Management Systemskc.niitstaff.com/NIITStaffUpgrade/CG/IEC Track...

©NIIT Introduction to Relational Database Management Systems 1.1

Introduction to Relational Database Management Systems

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.


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.


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.


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.


LESSON-WISE 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


• 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".


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:

BRANCHis a set of all branches of a particular bank.

CUSTOMERis a set all people who have their account in the bank.

EMPLOYEEis a set of all people who work in the bank.

ACCOUNTis a set of all accounts that are maintained in the bank.

You can take the following entities to explain an attribute:

BRANCHhas attributes such as branch_code, branch_name, and location.

CUSTOMERhas attributes such as customer_code, customer_name, customer_address, and account_number.

EMPLOYEEhas attributes such as employee_code, employee_name, and employee_address.

ACCOUNThas attributes such as account_number, account_type, and balance_amount.

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


BRANCHbranch_code

CUSTOMERcustomer_code, account_number

EMPLOYEEemployee_code

ACCOUNTaccount_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 PARTS SHIP


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.

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.

SUPPLIER PARTS SHIP m m


Solution

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

CREDIT CASH

PAY_DCR_PERIOD CR LIMIT

SUPPLIER

CODE NAME

ADD CR_STATUS

NAME


Faculty Observations


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 Belong

to Department m 1


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

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 row-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,

Department Has

Employee

m1


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 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


Table Sector


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

week_day2 char(3) No

Days of week when a flight covers the sector

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


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


Description

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

flight_no (FK) char(5) No Flight number


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


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.


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.


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


cPositionCode vDescription iBudgetedStrength

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


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


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


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


• 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.


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 ClientTS-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.


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.


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.


SOLUTIONS TO ADDITIONAL 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:

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:

INSTRUCTOR TEACHES STUDENTS

NAME ADDRESS NAME COURSE

ROLL_NO

1 m

Address Recipient Gives Order

Last Name

First Name Order Date

Cart ID

Zip Code City CountryID Order No. Shipping

Model ID

Shopper ID

1 m

Total Cost


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)

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


DEPARTMENT TABLE

Department_Code Department_Name Department_Head

D001 Accounts John Fairbrother

D002 Marketing Cathy Thames


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


SESSION PLAN: 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


Conceptual Model 60

Tips on Local Database Design 20

2.P.1 10

Summary 10

Total 105

Cycle3

OCR1


Understanding Data Redundancy 80

Understanding Denormalization 20

Total 105

Introduction to Relational Database Management Systemskc.niitstaff.com/NIITStaffUpgrade/CG/IEC Track...

Documents

Transcript of Introduction to Relational Database Management Systemskc.niitstaff.com/NIITStaffUpgrade/CG/IEC Track...