PRACTICAL OF DBMS

Practical 1:

Given the table EMPLOYEE (EmpNo, Name, Salary, Designation, DeptID) write a cursor to select the five
highest paid employees from the table.

EMPLOYEE (EmpNo, Name, Salary, Designation, DeptID)

SOLUTION:

CREATE TABLE EMPLOYEE (EMPNO INTEGER PRIMARY KEY, NAME VARCHAR(20),

SALARY NUMBER(7,2), DESIGNATION VARCHAR(10), DEPTID INTEGER);

get e:/p8.sql;
1 declare
2 i number:=0;
3 cursor ec is select empno,name,salary from employee order by gross_salary desc;
4 rec%rowtype;
5 begin
6 open ec;
7 loop
8 exit when i=5;
9 fetch ec into r;
10 dbms_output.put_line(r.emp_no||' '||r.employee_name||' '||r.salary);
11 i:=i+1;
12 end loop;
13 close ec;
14* end;
SQL> /

1 rajesh 31000
2 paramesh 15000
3 pushpa 14000
4 vijaya 14000
5 keerthi 13000
PL/SQL procedure successfully completed.

Practical 2:
Write relational algebra queries for a set of relations?

RA provides a theoretical foundation for relational databases. I assume that you know the basic terms used in
relational databases. Now pay attention to the terms relation, attribute and tuple as denoted.
- we will go through the following RA operators.
1. Projection
2. Selection
3. Rename
4. Cross product
5. Natural join
6. Conditional join
7. Union
8. Intersection
9. Set difference
1. Projection (π)

Projection is used to select the required columns of data from a relation. Note that projection removes
duplicate data (tuples).

Query: Member IDs of members who have borrowed books.

Query: Member IDs of members and the Book IDs of the books they have borrowed books.
2. Selection (σ)

Selection is used to select the required tuples of data from a relation. During selection, we can specify certain
conditions that the data must satisfy.

Query: Details of the members who were born on 21/10/1997.

3. Rename (ρ)

Rename operation allows renaming a certain output relation.

Query: Rename the Member relation as Library Member.

4. Cross product (✕)

Cross product is used to combine data from two different relations into one combined relation. If we consider
two relations; A with n tuples and B with m tuples, A ✕ B will consist of n.m tuples.

Query: Member ✕ Borrow

Note that Member relation has 5 tuples and Burrow relation has 5 tuples. Hence Member ✕ Borrow has 5✕5
= 25 tuples.

5. Natural join (⋈)

Natural join between two or more relations will result in all the combination of tuples where they have equal
values for the common attribute.

Query: Member ⋈ Borrow

Note that the common attribute in this example is Member ID.

6. Conditional join (⋈c)

Conditional join is similar to the natural join but in the conditional join, we can specify any join condition
with the operators greater than, less than, equal or not equal. You can combine conditions as well with AND
(^) and OR (v) operators.

Query: Borrowing details of members who have burrowed more than one book.

7. Union (⋃)

The union operation in RA is very similar to that of set theory. However, for the union of two relations, both
the relations must have the same set of attributes.

Query: Book IDs of the books borrowed by Charlie and Mike.

8. Intersection (⋂)

The intersection operation in RA is very similar to that of set theory. However, for the intersection of two
relations, both the relations must have the same set of attributes.

Query: Member IDs of the members who have borrowed both the books “Fences” and
“Inheritance”.
9. Set difference (-)

The set difference operation in RA is very similar to that of set theory. However, for the set difference
between two relations, both the relations must have the same set of attributes.

Query: Member IDs of the members who have never borrowed books.

R1 will return details of all the members Alice, Bob, Charlie, Mike and Katie. R2 will return details of Alice,
Charlie, Mike and Katie as they have borrowed books. When we take the difference between R1 and R2, the
details of Bob will be returned.

Practical 3:

Draw ER diagram like: Bank, University?

1.Bank:

ER diagram is known as Entity-Relationship diagram. It is used to analyze to structure of the Database. It

shows relationships between entities and their attributes. An ER model provides a means of
communication.
 ER diagram of Bank has the following description :
Bank have Customer.
 Banks are identified by a name, code, address of main office.
 Banks have branches.
 Branches are identified by a branch_no., branch_name, address.
 Customers are identified by name, cust-id, phone number, address.
 Customer can have one or more accounts.
 Accounts are identified by account_no., acc_type, balance.
 Customer can avail loans.
 Loans are identified by loan_id, loan_type and amount.
 Account and loans are related to bank’s branch.

ER Diagram of Bank Management System :

This bank ER diagram illustrates key information about bank, including entities such as branches,
customers, accounts, and loans. It allows us to understand the relationships between entities.
Entities and their Attributes are :

 Bank Entity : Attributes of Bank Entity are Bank Name, Code and Address.
Code is Primary Key for Bank Entity.
 Customer Entity : Attributes of Customer Entity are Customer_id, Name, Phone Number and
Address.
Customer_id is Primary Key for Customer Entity.
 Branch Entity : Attributes of Branch Entity are Branch_id, Name and Address.
Branch_id is Primary Key for Branch Entity.
 Account Entity : Attributes of Account Entity are Account_number, Account_Type and Balance.
Account_number is Primary Key for Account Entity.
 Loan Entity : Attributes of Loan Entity are Loan_id, Loan_Type and Amount.
Loan_id is Primary Key for Loan Entity.

Relationships are :

 Bank has Branches => 1 : N

One Bank can have many Branches but one Branch can not belong to many Banks, so the relationship
between Bank and Branch is one to many relationship.

 Branch maintain Accounts => 1 : N

One Branch can have many Accounts but one Account can not belong to many Branches, so the
relationship between Branch and Account is one to many relationship.
 Branch offer Loans => 1 : N
One Branch can have many Loans but one Loan can not belong to many Branches, so the relationship
between Branch and Loan is one to many relationship.

 Account held by Customers => M : N

One Customer can have more than one Accounts and also One Account can be held by one or more
Customers, so the relationship between Account and Customers is many to many relationship.
 Loan availed by Customer => M : N
(Assume loan can be jointly held by many Customers).
One Customer can have more than one Loans and also One Loan can be availed by one or more
Customers, so the relationship between Loan and Customers is many to many relationship.

2. University:
The university database stores details about university students, courses, the semester a student took a
particular course (and his mark and grade if he completed it), and what degree program each student is
enrolled in. The database is a long way from one that’d be suitable for a large tertiary institution, but it does
illustrate relationships that are interesting to query, and it’s easy to relate to when you’re learning SQL.

Consider the following requirements list:

1. The university offers one or more programs.

2. A program is made up of one or more courses.

3. A student must enroll in a program.

4. A student takes the courses that are part of her program.

5. A program has a name, a program identifier, the total credit points required to graduate, and the year it
commenced.

6. A course has a name, a course identifier, a credit point value, and the year it commenced.

7. Students have one or more given names, a surname, a student identifier, a date of birth, and the year
they first enrolled. We can treat all given names as a single object—for example, “John Paul.”

8. When a student takes a course, the year and semester he attempted it are recorded. When he finishes the
course, a grade (such as A or B) and a mark (such as 60 percent) are recorded.

9. Each course in a program is sequenced into a year (for example, year 1) and a semester (for example,
semester 1).

The ER diagram derived from our requirements Although it is compact, the diagram uses some advanced
features, including relationships that have attributes and two many-to-many relationships.
 The ER diagram of the university database

In our design:

 Student is a strong entity, with an identifier, student_id, created to be the primary key used to
distinguish between students (remember, we could have several students with the same name).

 Program is a strong entity, with the identifier program_id as the primary key used to distinguish
between programs.

 Each student must be enrolled in a program, so the Student entity participates totally in the many-to-
one Enrolls In relationship with Program. A program can exist without having any enrolled students, so
it participates partially in this relationship.

 A Course has meaning only in the context of a Program, so it’s a weak entity, with course_id as a weak
key. This means that a Course is uniquely identified using its course_id and the program_id of its
owning program.
 As a weak entity, Course participates totally in the many-to-one identifying relationship with its
owning Program. This relationship has Year and Semester attributes that identify its sequence position.

 Student and Course are related through the many-to-many Attempts relationships; a course can exist
without a student, and a student can be enrolled without attempting any courses, so the participation is
not total.

 When a student attempts a course, there are attributes to capture the Year and Semester, and
the Mark and Grade.

Practical 4:

Normalization the schema as per 1NF, 2NF and 3NF?

1.FIRST NORMAL FORM

It is a property of a relation in a relational database wherein only when the domain of each attribute has
only atomic values (values that cannot be divided or simplified further) and the value of each attribute has
only one value from the selected domain. Edgar Codd, an English Computer Scientist, stated that a relation
is said to be in the first normal form when none of its domains have any sets as elements. This form is a
very important relation in RDBMS. It enforces several criteria including:

1) Removing repeating groups in individual tables,

2) 2) Creating separate tables for every set of related data and

3) 3) Identifying related data using the primary key of a given set.

Example:

Consider a table containing the details of a company. The fields to be included are employee name,
employee ID no, employee location and employee contact no. For better understanding, this will be
displayed in a table form.
In the above table, we can see the employee details of a certain company. All rows have values as shown
but we can see that the values in the first two rows under the column ‘EMPLOYEE CONTACT NO’ have
multiple values. Employees AJAY and AMIT have multiple contact numbers which cannot be accepted in
the first normal form. It brings ambiguity to the database and can generate anomalies. Hence the need arises
to maintain the uniqueness of the field. In order to bring it to the first normal form, one of the values from
the field of employee contact no should be removed (from both Ajay and Amit’s data). So the correct first
normal form will be obtained upon editing in such a manner. The correct table will be:

The correct table complies with the first normal form criteria i.e., “each attribute of a table must have
atomic values”. The extra contact numbers were removed to obtain the required form design.

WHAT IS ATOMICITY IN DATABASE?

A definition of first normal form makes reference to the concept of ‘atomicity’. It states that the domain
should have values in the relation which are impossible to be broken down into smaller contents of data,
with respect to DBMS. Codd defines an atomic value as one that “cannot be decomposed into smaller
pieces.

2. SECOND NORMAL FORM (2NF)

An entity is said to be in the second normal form when it is already in 1NF and all the attributes contained
within it are dependent solely on the unique identifier of the entity. In other words, it maintains two
important criteria to be met in order to provide a normalized data with the second normal form tag.

1) It is in the first normal form

2) All non-key attributes are fully functional and dependent on the primary key.

To give more clarity to the statements said above, consider a table and two attributes within the table, A and
B. Suppose attribute B is functionally dependent on A, but is not on a proper subset of A. Then B can be
considered to be fully functional and dependent on A. Therefore in a 2NF table, all of the non-key attributes
cannot be dependent on the primary key’s subset. A table that is in 1st normal form and contains only a
single key as the primary key is automatically in 2nd normal form.

Example:

Consider a toy shop that has three branches in three different locations. A table is prepared indicating the
customer IDs, store IDs and store location.

The above table is a composite one and has a composite primary key (CUSTOMER ID, STORE ID). The
non-key attribute in this arrangement is STORE LOCATION. In the above case, the STORE LOCATION
only depends on the STORE ID, which is the sole part of the primary key. Hence the table does not satisfy
the second normal form.
To resolve this issue and to convert the entity into the 2NF, the table is split into two separate tables. By
splitting the table, the partial functional dependency is removed and atomicity is achieved for both the
tables (thus realizing 1NF in the process). Now, the column STORE LOCATION is completely dependent
on the primary key, the STORE ID thereby achieving 2NF for the table under consideration.

3.THIRD NORMAL FORM

An entity is said to be in the third normal form when,

1) It satisfies the criteria to be in the second normal form.

2) There exists no transitive functional dependency. (Transitive functional dependency can be best
explained with the relationship link between three tables. If table A is functionally dependent on B, and B is
functionally dependent on C then C is transitively dependent on A and B). It can also be said that the
transitive functional dependency of non-prime attribute on any super key is removed. (A super key is a
combined column system that is used to uniquely identify a row within any RDBMS. A super key is
reduced to a minimum no of columns required to uniquely identify each row.)
3NF states that every column reference in referenced data which are not dependent on the primary key
should be removed or that only foreign key columns should be used to reference another table, and no other
columns from the parent table should exist in the referenced table.

Example:

Consider a table that shows the database of a bookstore. The table consists of details on Book ID, Genre ID,
Book Genre and Price. The database is maintained to keep a record of all the books that are available or will
be available in the bookstore. The table of data is given below.

The data in the table provides us with an idea of the books offered in the store. Also, we can deduce that
BOOK ID determines the GENRE ID and the GENRE ID determines the BOOK GENRE. Hence we can
see that a transitive functional dependency has developed which makes certain that the table does not satisfy
the third normal form.
After splitting the tables and regrouping the redundant content, we obtain two tables where all non-key
attributes are fully functional dependent only on the primary key.To further explain the advanced step of the
normalization process, we are required to understand the Boyce-Codd Normal Form and its comparison
with the third normal form.

3. THE BOYCE-CODD NORMAL FORM AND RELATION WITH 3NF

The Boyce-Codd Normal Form or BCNF or 3.5 NF is a normal form which is slightly stronger than the
3NF. It was developed in 1974 to address certain types of anomalies that were not dealt by 3NF. A
relational scheme, once prepared in BCNF, will remove all sorts of functional dependency (though some
other forms of redundancy can prevail). Coming to the relation between BCNF AND 3NF, in certain rare
cases, the 3NF table fails to meet the requirements of the BCNF. A 3NF table sans multiple overlapping
candidate keys is guaranteed to be in BCNF and depending on the functional dependencies of the entity, a
3NF table that possesses two or more overlapping candidate keys may/may not be capable of being in
BCNF.

Here is an example of a 3NF table that does not meet the demands of the BCNF:

The table shows the details of the booking schedule for a swimming pool complex with the fields of POOL
NO, START TIME, END TIME and TYPE OF MEMBERSHIP. The details are filled in the rows and
columns of the table below:
In the above table, no non-prime attributes exist which means that all attributes belong to some candidate
key. This justifies the table being of 2NF and 3NF.However,the table does not follow BCNF because of the
dependency of the type of membership in which the determining attribute,type of membership on which
pool no: depends is neither a candidate key nor a superset of a candidate key. The design needs to be
modified in order to conform to the BCNF. The significance of explaining the BCNF comes when the step
of normalization is to be explained. The ‘Fourth Normal Form’ or 4NF

4. FOURTH NORMAL FORM

A normal form that is used in database normalization. The 4NF came at a significant time period as the next
level of normalization. It was introduced by Ronald Fagin in 1977, after the Boyce-Codd Normal Form.
The 4NF is basically concerned with a more general type of dependency known as a multivalued
dependency and is different from 2NF, 3NF and BCNF and their functional dependencies. A table can be
considered to be in 4NF only if for every one of the non-trivial multivalued dependencies, X->Y, when X is
a super key. (This means that X is either a candidate key or a superset ).

Example:

Consider the table given below:

Here COURSE ID and INSTRUCTOR are multi valued dependent attributes. They can be converted to
4NF by separating the single table into two tables which are as given below.

COURSE-INST

COURSE-TEXT

USE OF 4NF

At the higher levels of normalization, the teaching and use of database normalization slows down substantially mostly
because most of the tables are in direct violation of the 4NF. A table that satisfies 4NF is hard to come by most of the
business applications. A study proves that, as of now, over 20% of business processes contains tables that violates
4NF but successfully meets all lower forms of normalization.
BEYOND 4NF

At 4NF, the performance reduces considerably and a further 5NF procedure may not be feasible as it causes great
chances of error and very few tables practically satisfy the criteria to be of 5NF. The 5NF is also called the project-
join normal form and is the highest level of normalization designed to reduce redundancy in relational databases
which is done by recording multi-valued facts by isolating semantically related multiple relationships.