Thanks to visit codestin.com
Credit goes to www.scribd.com

0% found this document useful (0 votes)
7 views26 pages

Com 312 Lecture Note-1

Computer science materials

Uploaded by

abbalkhairy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
7 views26 pages

Com 312 Lecture Note-1

Computer science materials

Uploaded by

abbalkhairy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 26

Week 1

Understand the types of information need.


Understand the purpose of data base systems

UNDERSTAND THE TYPES OF INFORMATION NEED

Introduction
• A database is an organized collection of data. Database information is organized in such a way
that a computer program can quickly select the pieces of data. Database is a collection of
information that is organized so that it can be easily accessed, managed, updated and deleted. In
other words, database is a Collection of logically interrelated data. (Eg: College)

THE PURPOSE OF DATABASE SYSTEM


Database Management System arouse in response to early method of computerized management
of commercial data. As an example of such methods, typical of the 1960s, consider part of the
University organization that, among other data, keeps information about all instructors, students,
departments, and course offerings. To allow users to manipulate the information, the system has
a number of application program that manipulate the files, including the program to:
 Add new students, instructors and courses.
 Register student for courses, and generate class roasters.
 Assign grades to students, compute grade point averages (GPA) and generate Transcripts.

Week 2
Understand data view and data model
Understand database administrators, users and languages.

UNDERSTAND DATA VIEW AND DATA MODEL

A database system is a collection of interrelated data and a set of programs that allow users to
access and modify these data. A major purpose of a database is to provide users with an abstract
view of data. That is, the system hide certain details of how the data are stored and maintained.

DATA ABSTRACTION
Underlying the structure of a database is the data model: a collection of conceptual tools for de
scribing data, data relationships, data semantics, and consistency constraints. A data model
provides a way to describe the design of a database at the physical, logical, and view levels. For
the system to be usable, it must retrieve data efficiently. The need for efficiency has led
designers to use complex data structures to represent data in the database. Since many database-
system users are not computer trained, developers hide the complexity from users through
several levels of abstraction, to simplify users’ interaction with the system:
Physical Level: the lowest level of abstraction describe how the data are actually stored. The
physical level describes complex low-level data structures.

Logical level: the next higher level of abstraction what data are stored in the database, and what
relationship exist among those data. The logical level thus describes the entire database in terms
of a small number of relatively simple structures. Although implementation of the simple
Prepared by BABA SALEH1
structures at the logical level may involve complex physical-level structures, the user of the
logical level does not need to be aware of this complexity. This is referred to as physical data
independence. Database administrators, who must decide what information to keep in the
database, use the logical level of abstraction.

View Level: The highest level of abstraction describes only part of the entire database. Even
though the logical level uses simpler structures, complexity remains because of the variety of
information stored in a large database. Many users of the database system do not need all this
information; instead, they need to access only a part of the database. The view level of
abstraction exists to simplify their interaction with the system. The system may provide many
views for the same database.

The three Levels of Abstraction

UNDERSTAND DATABASE ADMINISTRATORS, USERS AND LANGUAGES

Database Administrator
One of the main reasons for using DBMSs is to have central control of both the data and the
programs that access those data. A person who has such central control over the system is called
a database administrator (DBA). The functions of a DBA include:
Schema definition. The DBA creates the original database schema by executing a set of data
definition statements in the DDL.
Storage structure and access-method definition.
Schema and physical-organization modification. The DBA carries out changes to the schema
and physical organization to reflect the changing needs of the organization, or to alter the
physical organization to improve performance.
Granting of authorization for data access. By granting different types of authorization, the
database administrator can regulate which parts of the database various users can access. The
authorization information is kept in a special system structure that the database system consults
whenever someone attempts to access the data in the system.
Routine maintenance. Examples of the database administrator’s routine maintenance activities
are:
 Periodically backing up the database, either onto tapes or onto remote servers, to prevent
loss of data in case of disasters such as flooding.

Prepared by BABA SALEH2


 Ensuring that enough free disk space is available for normal operations, and upgrading
disk space as required.
 Monitoring jobs running on the database and ensuring that performance is not degraded
by very expensive tasks submitted by some users.

Week 3 & 4
Different types of data model: hierarchical, network and relational model
Continued Different types of data model: hierarchical, network and relational models

DIFFERENT TYPES OF DATA MODEL: HIERARCHICAL, NETWORK AND


RELATIONAL MODEL

A database model defines the logical design and structure of a database and defines how data
will be stored, accessed and updated in a database management system. While the Relational
Model is the most widely used database model, there are other models too:
 Hierarchical Model
 Network Model
 Entity-Relationship Model
 Relational Model
Hierarchical Model
This database model organizes data into a tree-like structures, with a single roots, to which all
other data is linked. The hierarchy starts from the Root data, and expands like a tree, adding child
nodes to the parent nodes.
In this model, a child node will only have a single parent nodes.
This model efficiently describes many real-world relationship like index of a book, recipes etc.
In hierarchical model, data is organized into tree-like structure with one-to-many relationship
between two different types of data, for example, one department can have many courses, many
professors and off-course many students.

Prepared by BABA SALEH3


Network Model
This is an extension of hierarchical model. In this model data is organized more like a graph, and
are allowed to have more than one parent node.
In this database model data is more related as more relationships are established in this database
model. Also, as the data is more related, hence accessing the data is also easier and fast. This
model was used to map many-to-map data relationships.
This was widely used database model, before relational model was introduced.

Relational Model
In this model, data is organized in two-dimensional tables and the relationship is maintained by
storing a common field.
This model was introduced by E.F Cold in 1970, and since then it has been the most widely used
database model, in fact we can say the only database model used around the world.
The basic structure of data in the relational model is tables. All the information related to a
particular type is stored in the rows of that table.
Hence, tables are also known as relations in the relational model.
In the coming tutorials we will learn how to design tables, normalize them to reduce data
redundancy and how use Structured Query Language (SQL) to access data from tables.

Prepared by BABA SALEH4


Week 5 & 6
Understand the concept of E-R, entity sets, entity relationship, weak entity sets
Be able to design E-R database schema
Understand reduction of E-R schema into tables.

Up to this point in the text, we have assumed a given database schema and studied how queries
and updates are expressed. We now consider how to design a database schema in the first place.
In this portion, we focus on the entity relationship data model (E-R), which provides a means of
identifying entities to be represented in the database and how those entities are related.
Ultimately, the database design will be expressed in terms of a relational database design and an
associated set of constraints. We show in this portion how an E-R design can be transformed into
a set of relation schemas and how some of the constraints can be captured in that design. Then, in
this portion, we consider in detail whether a set of relation schemas is a good or bad database
design and study the process of creating good designs using a broader set of constraints. These
two chapters cover the fundamental concepts of database design.
The entity-relationship (E-R) data model was developed to facilitate database design by
allowing specification of an enterprise schema that represents the overall logical structure of a
database.
The E-R model is very useful in mapping the meanings and interactions of real-world enterprises
onto a conceptual schema. Because of this usefulness, many database-design tools draw on
concepts from the E-R model. The E-R data model employs three basic concepts: entity sets,
relationship sets, and attributes, which we study first. The E-R model also has an associated
diagrammatic representation, the E-R diagram, will be study later in this chapter.

Entity Sets
An entity is a “thing” or “object” in the real world that is distinguishable from all other objects.
For example, each person in a university is an entity. An entity has a set of properties, and the
values for some set of properties may uniquely identify an entity. For instance, a person may
have a person id property whose value uniquely identifies that person. Thus, the value 677-89-
9011 for person id would uniquely identify one particular person in the university. Similarly,
courses can be thought of as entities, and course id uniquely identifies a course entity in the
university. An entity may be concrete, such as a person or a book, or it may be abstract, such as a
course, a courses offering, or a flight reservation.
An entity set is a set of entities of the same type that share the same properties, or attributes. The
set of all people who are instructors at a given university, for example, can be defined as the
entity set instructor. Similarly, the entity set student might represent the set of all students in the
university.
In the process of modeling, we often use the term entity set in the abstract, without referring to a
particular set of individual entities. We use the term extension of the entity set to refer to the
actual collection of entities belonging to the entity set. Thus, the set of actual instructors in the
university forms the extension of the entity set instructor. The above distinction is similar to the
difference between a relation and a relation instance.
Entity sets do not need to be disjoint. For example, it is possible to define the entity set of all
people in a university (person). A person entity may be an instructor entity, a student entity,
both, or neither.

Prepared by BABA SALEH5


An entity is represented by a set of attributes. Attributes are descriptive properties possessed by
each member of an entity set. The designation of an attribute for an entity set expresses that the
database stores similar information concerning each entity in the entity set; however, each entity
may have its own value for each attribute. Possible attributes of the instructor entity set are ID,
name, dept name, and salary. In real life, there would be further attributes, such as street number,
apartment number, state, postal code, and country, but we omit them to keep our examples
simple. Possible attributes of the course entity set are course id, title, dept name, and credits.
Each entity has a value for each of its attributes. For instance, a particular instructor entity may
have the value 12121 for ID, the value Wu for name, the value Finance for dept name, and the
value 90000 for salary.
The ID attribute is used to identify instructors uniquely, since there may be more than one
instructor with the same name. In the United States, many enterprises find it convenient to use
the social-security number of a person2 as an attribute whose value uniquely identifies the
person. In general the enterprise would have to create and assign a unique identifier for each
instructor.
A database thus includes a collection of entity sets, each of which contains any number of
entities of the same type. Figure 7.1 shows part of a university database that consists of two
entity sets: instructor and student. To keep the figure simple, only some of the attributes of the
two entity sets are shown.
A database for a university may include a number of other entity sets. For example, in addition to
keeping track of instructors and students, the university also has information about courses,
which are represented by the entity set course

Prepared by BABA SALEH6


Figure:

Entity Relationship, Strong Entity Set, Weak Entity Sets


Entity Relationship: A relationship represents an association between two or more entities.
Relationship are classified by their degree, connectivity, cardinality, direction, types of existence,
dependency and participation. Mapping cardinalities or cardinality ratios express the number of
entities to which another entity can be associated via relationship set.
Whereas the E-R diagram can express the overall logical structure of a database graphically. E-R
diagram are simple and clear qualities that may well account in large part. We use different
symbols for representing any E-R diagram. Also various relationship can be used to design the
structure of E-R diagrams. Below are some the relationship sets:

Prepared by BABA SALEH7


Following the relationships is the symbols used in E-R notation

In addition, the following is another symbol:

AN ENTITY SETS
An Entity set is divided into two:

1. Strong entity set


2. Weak entity set

1. Strong Entity Set-


Prepared by BABA SALEH8
 Strong entity set is an entity set that contains sufficient attributes to uniquely identify all its
entities.
 In other words, a primary key exists for a strong entity set.
 Primary key of a strong entity set is represented by underlining it.
Symbols Used-
 A single rectangle is used for representing a strong entity set.
 A diamond symbol is used for representing the relationship that exists between two strong
entity sets.
 A single line is used for representing the connection of the strong entity set with the
relationship set.
 A double line is used for representing the total participation of an entity set with the
relationship set.
 Total participation may or may not exist in the relationship.
Example-
Consider the following ER diagram-

In this ER diagram,
 Two strong entity sets “Student” and “Course” are related to each other.
 Student ID and Student name are the attributes of entity set “Student”.
 Student ID is the primary key using which any student can be identified uniquely.
 Course ID and Course name are the attributes of entity set “Course”.
 Course ID is the primary key using which any course can be identified uniquely.
 Double line between Student and relationship set signifies total participation.
 It suggests that each student must be enrolled in at least one course.
 Single line between Course and relationship set signifies partial participation.
 It suggests that there might exist some courses for which no enrollments are made.
2. Weak Entity Set-
A weak entity set is an entity set that does not contain sufficient attributes to uniquely identify its
entities.
 In other words, a primary key does not exist for a weak entity set.
 However, it contains a partial key called as a discriminator.
 Discriminator can identify a group of entities from the entity set.
 Discriminator is represented by underlining with a dashed line.

Prepared by BABA SALEH9


NOTE-
 The combination of discriminator and primary key of the strong entity set makes it possible to
uniquely identify all entities of the weak entity set.
 Thus, this combination serves as a primary key for the weak entity set.
 Clearly, this primary key is not formed by the weak entity set completely.
Symbols Used
 A double rectangle is used for representing a weak entity set.
 A double diamond symbol is used for representing the relationship that exists between the
strong and weak entity sets and this relationship is known as identifying relationship.
 A double line is used for representing the connection of the weak entity set with the
relationship set.
 Total participation always exists in the identifying relationship.

Example-

Consider the following ER diagram-

In this ER diagram,

 One strong entity set “Building” and one weak entity set “Apartment” are related to each
other.
 Strong entity set “Building” has building number as its primary key.
 Door number is the discriminator of the weak entity set “Apartment”.
 This is because door number alone can not identify an apartment uniquely as there may be
several other buildings having the same door number.
 Double line between Apartment and relationship set signifies total participation.
 It suggests that each apartment must be present in at least one building.
 Single line between Building and relationship set signifies partial participation.
 It suggests that there might exist some buildings which has no apartment.

Prepared by BABA SALEH10


To uniquely identify any apartment,
 First, building number is required to identify the particular building.
 Secondly, door number of the apartment is required to uniquely identify the apartment.
Thus,
Primary key of Apartment
= Primary key of Building + Its own discriminator
= Building number + Door number
Differences between Strong entity set and Weak entity set-

Strong entity set Weak entity set

A single rectangle is used for the


A double rectangle is used for the
representation of a strong entity
representation of a weak entity set.
set.

It contains sufficient attributes to It does not contain sufficient


form its primary key. attributes to form its primary key.

A double diamond symbol is used


A diamond symbol is used for the
for the representation of the
representation of the relationship
identifying relationship that exists
that exists between the two strong
between the strong and weak
entity sets.
entity set.

A single line is used for the A double line is used for the
representation of the connection representation of the connection
between the strong entity set and between the weak entity set and
the relationship. the relationship set.

Total participation may or may not Total participation always exists in


exist in the relationship. the identifying relationship.

https://www.gatevidyalay.com/entity-sets-in-dbms/

Prepared by BABA SALEH11


UNDERSTAND REDUCTION OF E-R SCHEMA INTO TABLES
A database which confirms to an E-R (diagram) can be represented by a collection of tables. For
each entity set and relationship set there is a unique table. Each table has a unique name.
Each tables has a number of columns which have a unique names Columns are the collection of
values. Converting an E-R diagram to a format is the basis of driving a relational database design
for an E-R diagram.it is clear from E-R diagram that it can show all attributes with name but not
values. Values are shown by tabular representation of E-R diagram.

Tabular Representation of Strong Entity Sets


Consider the entity set student shown below
Student (Sid, name)

E-R diagram for student


Student is a strong entity set because it has attribute to form a primary key. Sid is the primary
key for the student table. The above E-R diagram is shown in tabular form below:

Sid Sname
101 AB Abdullahi
102 PQ John
103 RS Kabiru
104 UV Rabiu
105 NM Usman

Tabular Representation of Weak Entity Set


Consider the entity set college shown in the figure below:

E-R diagram for college


The entity college having two attributes college name and college-address, college is a weak
entity set because it does not have a sufficient attributes to form a primary key. We can use
primary key of another table for college entity. If we us Sid of student table and college name
collectively forms a primary key for college entity. Because the primary key of student entity is

Prepared by BABA SALEH12


Sid, on which college is department. So college entity is represented by a table with three
columns that are Sid, college-name and college-Address which is shown in table below.

Sid College-name College-Address


101 PQ T.I.T Bhopal
102 AB OIST Indore
103 RS R.G.P.V Bhopal
104 UV NRI Gwalior
College table

Week 7
Understand pitfalls in relational-database design

UNDERSTAND NORMALIZATION AND DECOMPOSITION


NORMALIZATION
Definition
• Database normalization is the process of organizing the fields and tables of a relational
database to minimize redundancy and dependency. Normalization usually involves dividing
large tables into smaller (and less redundant) tables and defining relationships between them.
The objective is to isolate data so that additions, deletions, and modifications of a field can be
made in just one table and then propagated through the rest of the database via the defined
relationships.
What is anomalies?
Database anomalies are the problems in relations that occur due to redundancy in the relations.
These anomalies affect the process of inserting, deleting and modifying data in the relations.
Some important data may be lost if a Relation is updated that contains database anomalies.
It is important to remove these anomalies in order to perform different processing on the
relations without any problem.
Types of Anomalies.
• Redundancy
– Repeat info unnecessarily in several tuples
• Update anomalies:
– Change info in one tuple but not in another.
• Deletion anomalies:
– Delete some values & lose other values too.
• Insert anomalies:
– Inserting row means having to insert other, separate info.
Data Redundancy
Data redundancies is duplicity of data that means, the same data is stored in different location in
a data base, or if you getting some problem to extract the data from the file due to duplicity of
data then this cause is called as redundancies.
Update Anomalies

Prepared by BABA SALEH13


An update anomaly occurs when we have a lot of redundancy in our data. Due to redundancy,
data updating becomes cumbersome. If we have to update one attribute value, which is occurring
a number of times, we have to search for every occurrence of that value and then change it.

An Update Anomaly exists when one or more instances of duplicated data is updated, but not all
i.e Change info in one tuple but not in another. In STU_DETAIL, if we want to change the name
of Instructor of Cource_ID cap301 then it will update all the tuples in the table, but some reason

Prepared by BABA SALEH14


all the tuples are not updated, we might have a database that gives two names of instructor for
subject cap301.

Prepared by BABA SALEH15


Insert Anomalies
An insertion anomaly occurs when we are unable to insert a tuple into a table. Such a situation
can arise when the value of primary key is not known. As per the entity integrity rule, the
primary key cannot have null value. Therefore, the value/s corresponding to primary key
attribute/s of the tuple must be assigned before inserting the tuple. If these values are unknown,
the tuple cannot be inserted into the table.
Delete Anomalies
In case of a deletion anomaly, the deletion of a tuple causes problems in the database. This can
happen when we delete a tuple, which contains an important piece of information, and the tuple
being the last one in the table containing the information. With the deletion of the tuple the
important piece of information also gets removed from the database.
Dependency
A dependency refers to relationship amongst attributes. These attributes may belong to the same
relation or different relations. Dependencies can be of various types viz., functional
dependencies, transitive dependencies, multivalued dependencies, join dependencies, etc. We
shall briefly examine some of these dependencies.
Types of Dependency
• Functional Dependency
– Fully Functional Dependency
– Partial Functional Dependency
• Transitive Dependency
• Multivalued Dependency
• Join Dependency
Functional Dependency
Functional Dependency (F.D) – Functional dependency represents semantic association between
attributes. If a value of an attribute A determines the value of another attribute B, we say B is
functionally dependent on A. This is denoted by A => B and read as “A determines B” and A is
called the determinant.

Fully Functional Dependency


Full Functional dependency Indicates that if A and B are attributes (columns)of a table, B is fully
functionally dependent on A if B is functionally dependent on A, but not on any proper subset
of A. E.g. Staff_ID----> Domain

Partial Functional Dependency


Partial Functional Dependency Indicates that if A and B are attributes of a table , B is partially
dependent on A if there is some attribute that can be removed from A and yet the dependency
still holds. Say for Ex, consider the following functional dependency that exists in the
STUDENT
table:
Reg_no, Name -------> Section_No

Prepared by BABA SALEH16


Section_No is functionally dependent on a subset of A
Transitive Dependency
Transitive dependency is a form of intermediate dependency. For example, if we have attributes
or groups of attributes A, B and C such that A determines B and B determines C i.e.
A => B
B => C
Then we say a transitive dependency represented by A => B => C

C is transitively dependent on A through B.


Consider the table below:

Book -> Author: Here, the Book attribute determines the Author attribute. If you know the book
name, you can learn the author's name. However, Author does not determine Book, because an
author can write multiple books. For instance, just because we know the author's name Orson
Scott Card, we still don't know the book name. Author -> Author_Nationality: Likewise, the
Author attribute determines the Author_Nationality, but not the other way around: just because
we know the nationality does not mean we can determine the author.
Book -> Author -> Author_Nationality

Multi-valued Dependency
Multi-valued Dependency refers to m:n (many-to-many) relationships.
We say multi-valued dependency exists between two data items when one value of the first data
item gives a collection of values of the second data item i.e., it multi-determines the second data
items.
For example, imagine a car company that manufactures many models of car, but always makes
both red and black colors of each model. If you have a table that contains the model name, color
and year of each car the company manufactures, there is a multivalued dependency in that table.
If there is a row for a certain model name and year in blue, there must also be a similar row
corresponding to the red version of that same car.

Prepared by BABA SALEH17


For example: Consider a car manufacture company, which produces two colors (Black and red)
in each model every year. Here columns manuf_year and color are independent of each other and
dependent on car_model. In this case these two columns are said to be multivalued dependent on
car_model. These dependencies can be represented like this: car_model ->> manuf_year.

Join Dependency
Join Dependency—If we decompose a relation into smaller relations and the join of the smaller
relations does not give us tuples as in the parent relation, we say the relation has join
dependency.
Example relation R is decomposed into r1, r2.....rn than when you assembled them it should
equals to R (without any loss).
Decomposition???
 Splitting the relation into two or more subrelations.
 Decomposition can be of two types:
Loss Less Join Decomposition.
Lossy Decomposition.

Student_table:

Lossy JOIN

Prepared by BABA SALEH18


Lossy Decomposition

Loss-Less JOIN Decomposition

NORMAL FORMS
The normal forms (abbrev. NF) of relational database theory provide criteria for determining a
table's degree of vulnerability to logical inconsistencies and anomalies.
The higher the normal form applicable to a table, the less vulnerable it is to inconsistencies and
anomalies.
Each table has a "highest normal form" (HNF): by definition, a table always meets the
requirements of its HNF and of all normal forms lower than its HNF.

Prepared by BABA SALEH19


1NF
• A relation is said to be in First Normal Form (1NF) if and only if every entry of the relation
(the intersection of a tuple and a column) has at most a single value.
• In other words “a relation is in First Normal Form if and only if all underlying domains contain
atomic values or single value only.
Example • Suppose a designer wishes to record the names and telephone numbers of customers.
He defines a customer table which looks like this.
Customer_table:
Customer ID FirstName SurName Telephone_no
123 Robert Ingram 08035462722
456 Jane Wright 08020335576
789 Maria Fernandez 08077223456

The designer then becomes aware of a requirement to record multiple telephone numbers for
some customers. He reasons that the simplest way of doing this is to allow the "Telephone
Number" field in any given record to contain more than one value.
Customer_table:
Customer ID FirstName SurName Telephone_no
123 Robert Ingram 08035462722
456 Jane Wright 08020335576
07035456633
789 Maria Fernandez 08077223456

Student Table :
In First Normal Form, any row must not have a column in which more than one value is saved,
like separated with commas.
Rather than that, we must separate such data into multiple rows.

Student Age Subject


Rahul 25 C++,JAVA
Neha 24 DBMS
Sushil 27 Maths

Student Table following 1NF will be :


Using the First Normal Form, data redundancy increases, as there will be many columns with
same data in multiple rows but each row as a whole will be unique.
Student Age Subject
Rahul 25 C++
Rahul 25 JAVA
Neha 24 DBMS
Sushil 27 Maths

Prepared by BABA SALEH20


2NF
• Second normal form (2NF) a relation in first normal form in which every non key attribute is
fully functionally dependent on the primary key.
• A Table is said to be in 2NF if it is in 1NF and there are no partial dependencies i.e. every
non primary key attribute of the Table is fully functionally dependent on the primary key.
Example: Consider a table describing employees' skills:
Employees' Skills

• Neither {Employee} nor {Skill} is a candidate key for the table. This is because a given
Employee might need to appear more than once (he might have multiple Skills), and a given
Skill might need to appear more than once (it might be possessed by multiple Employees). Only
the composite key {Employee, Skill} qualifies as a candidate key for the table.
• The remaining attribute, Current Work Location, is dependent on only part of the candidate
key, namely Employee. Therefore the table is not in 2NF.
• Note the redundancy in the way Current Work Locations are represented: we are told three
times
that Jones works at 114 Main Street, and twice that Ellis works at 73 Industrial Way.
• This redundancy makes the table vulnerable to update anomalies: it is, for example, possible to
update Jones' work location on his "Typing" and "Shorthand" records and not update his
"Whittling" record. The resulting data would imply contradictory answers to the question "What
is Jones' current work location?"
A 2NF alternative to this design would represent the same information in two tables: an
"Employees" table with candidate key {Employee}, and an "Employees' Skills" table with
candidate key {Employee, Skill}:

Prepared by BABA SALEH21


Neither of these tables can suffer from update anomalies. Not all 2NF tables are free from update
anomalies
3NF
• Third normal form (3NF)a relation that is in second normal form and has no transitive
dependencies.
• Meeting both above forms and removing duplicate data.
• A Table that is in 1NF and 2NF and in which no non primary key attribute is transitively
dependent on primary
key.
• Third Normal form applies that every non-prime attribute of table must be dependent on
primary key, or we can say that, there should not be the case that a non-prime attribute is
determined by anothernon-prime attribute. So this transitive functional dependency should be
removed from the table and also the table must be in Second Normal form. For example,
consider a table with following fields.
• Student_Detail Table

• In this table Student_id is Primary key, but street, city and state depends upon Zip. The
dependency between zip and other fields is called transitive dependency. Hence to apply 3NF,
we need to move the street, city and state to new table, with Zip as primary key.
• New Student_Detail Table :

• Address Table :
Student
_id
BCNF
• It is an advance version of 3NF that’s why it is also referred as 3.5NF. BCNF is stricter than
3NF. A table complies with BCNF if it is in 3NF and for every functional dependency X->Y, X
should be the super key of the table. R must be in 3rd Normal Form
• And, for each functional dependency ( X -> Y ), X should be a super Key(or at least a
candidate key).
• In the above 3NF example, STUDENT_ID is the Primary key in STUDENT table and ZIP is
the primary key in the ZIPCODE table. There is no other key column in each of the tables which
determines the functional dependency. Hence it's in BCNF form. That is, with STUDENT_ID,
we can retrieve STUDENT_NAME and ZIP from STUDENT table. Similarly, with ZIP value,
we can retrieve STREET and CITY from ZIPCODE table.
• BCNF is much restrictive than 3NF which help in normalizing the table more. The relation in
3NF has minimum redundancy left which is further removed by the BCNF.

4NF
• Fourth Normal Form (4NF) 4NF is a stronger normal form than BCNF as it prevents Tables
from containing nontrivial Multi-Valued Dependencies (MVDs) and hence data redundancy.

Prepared by BABA SALEH22


• The Normalization of BCNF Tables to 4NF involves the removal of MVDs from the Table by
placing the attribute(s) in a new Table along with the copy of the determinant(s). Fourth Normal
Form (4NF) MVD
• Dependency between attributes (for example, A, B, and C) in a relation, such that for each
value of A there is a set of values for B and a set of values for C. However, set of values for B
and C are independent of each other.
• MVD between attributes A, B, and C in a relation using the following notation:
A --- B
A --- C
example involving Course, Student_name and text_book.
Course Student_Name Text_Book
Physics Anik Mechanics
Physics Anik Optics
Physics Rahat Mechanics
Physics Rahat Optics
Chemistry Anik Organic_Chemistry
Chemistry Anik InOrganic_Chemistry
English Raj English_Literature
English Raj English_Grammer

• Clearly the attributes 'Student_name' and 'Text_book' are multivalued facts about the attribute
'Course'.
• However, since a student has no influence over the text books to be used for a course, these
multi-valued facts about courses are independent of each other. Thus the table contains an MVD.
• Multi-value facts are represented by. Here, in above database following MVDs exists:
Course --> --> Student_name
Course --> --> Text book
Here, Student_name and Text_book are independent of each other.
Rule to transform a relation into Fourth Normal Form
A relation R having A, B, and C, as attributes can be non loss-decomposed into two projections
R1(A,B) and R2(A,C) if and only if the MVD A--> --> B|C hold in R. Looking again at the un-
decomposed COURSE_STUDENT_BOOK table, it contains a multi-valued dependency as
shown below:
Course ---> --> Student_name
Course ---> --> Text_book
To put it into 4NF, two separate tables are formed as shown below:
COURSE_STUDENT (Course, Student_name)
COURSE_BOOK (Course, text_book)

Prepared by BABA SALEH23


5NF
• Fifth Normal Form (5NF) 5NF is also called Project-Join Normal Form(PJRF) and
specifies that a 5NF Table has no Join dependency.
• Formally, A table is said to be in 5NF if and only if
– Table is already in 4NF
– It cannot be further non-loss decomposed.
Consider the table
AGENT_COMPANY_PRODUCT (Agent, Company, Product _Name)

Consider another decomposition:

Prepared by BABA SALEH24


• We can see from the given example that by performing natural join of decomposed tables, the
table which was formed was not equal to the original table.
• That states that there is no join dependency in the resultant table. Thus, table is in 5 NF.

Week 8
Understand domain-key normal form
DOMAIN KEYS IN NORMAL FORMS
A relation is in DKNF when insertion or delete anomalies are not present in the database.
Domain-Key Normal Form is the highest form of Normalization. The reason is that the insertion
and updation anomalies are removed. The constraints are verified by the domain and key
constraints.
A table is in Domain-Key normal form only if it is in 4NF, 3NF and other normal forms. It is
based on constraints:
Domain Constraint
Values of an attribute had some set of values, for example, EmployeeID should be four digits
long:
EmpID EmpName EmpAge
0921 Tom 33
0922 Jack 31

Prepared by BABA SALEH25


Key Constraint
An attribute or its combination is a candidate key
General Constraint
Predicate on the set of all relations.
Every constraint should be a logical sequence of the domain constraints and key constraints
applied to the relation. The practical utility of DKNF is less.
Week 9
Understand the background of SQL
An Overview of SQL
SQL is the de factor standard used to manipulate and retrieve data from these relational database.
SQL enables a programmer or database administrator to do the following:
 Modify a database’s structure
 Change system security settings
 Add user permission on database or tables
 Query a database for information
 Update the content of database
Understand the basic structure of SQL

Week 10
Understand nested sub-queries
Understand derived relations and views
Week 11 & 12
Understand views
Understand joined relations
Understand data definition language and embedded SQL.

Week 13
Understand centralized systems
Understand client- server systems

Week 14 & 15
Understand parallel systems
Understand distributed systems and netrgtfwork types

Prepared by BABA SALEH26

You might also like