UNIT-1 INDRODUCTION TO DBMS

DEFINITION

 Database

 A collection of data stored in a standardized format, designed to be shared by multiple

users.

 Database Management System

 Software that defines a database, stores the data, supports a query language,
produces reports, and creates data entry screens.

 DBMS contains information about a particular enterprise

o Collection of interrelated data
o Set of programs to access the data
o An environment that is both convenient and efficient to use
 Database Applications:
o Banking: all transactions
o Airlines: reservations, schedules
o Universities: registration, grades
o Sales: customers, products, purchases
o Online retailers: order tracking, customized recommendations
o Manufacturing: production, inventory, orders, supply chain
o Human resources: employee records, salaries, tax deductions

PURPOSE OF DATABASE SYSTEMS

 In the early days, database applications were built directly on top of file systems

 Drawbacks of using file systems to store data:

o Data redundancy and inconsistency

 Multiple file formats, duplication of information in different files

o Difficulty in accessing data

 Need to write a new program to carry out each new task

o Data isolation — multiple files and formats

o Integrity problems

 Integrity constraints (e.g. account balance > 0) become “buried” in

program code rather than being stated explicitly
  Hard to add new constraints or change existing ones

o Atomicity of updates

 Failures may leave database in an inconsistent state with partial updates

carried out

 Example: Transfer of funds from one account to another should either

complete or not happen at all

o Concurrent access by multiple users

 Concurrent accessed needed for performance

 Uncontrolled concurrent accesses can lead to inconsistencies

 Example: Two people reading a balance and updating it at the

same time

o Security problems

 Hard to provide user access to some, but not all, data

 Database systems offer solutions to all the above problems

WHY USE DBMS? (ADVANTAGES OFDBMS)

 Data independence and efficient access.

 Reduced application development time.

 Data integrity and security.

 Uniform data administration.

 Concurrent access, recovery from crashes.

 STRUCTURE OF A DBMS

The DBMS accepts SQL commands generated from a variety of user interfaces, produces query
evaluation plans, executes these plans against the database, and returns the answers. (This is a
simplification: SQL commands can be embedded in host-language application programs, e.g., Java or
COBOL programs.)

When a user issues a query, the parsed query is presented to a query optimizer, which uses
information about how the data is stored to produce an efficient execution plan for evaluating the
query. An execution plan is a blueprint for evaluating a query, and is usually represented as a tree of
relational operators (with annotations that contain additional detailed information about which access
methods to use, etc.).

The code that implements relational operators sits on top of the file and access methods layer. This
layer includes a variety of software for supporting the concept of a file, which, in a DBMS, is a collection
of pages or a collection of records. This layer typically supports a heap file, or file of unordered pages, as
well as indexes. In addition to keeping track of the pages in a file, this layer organizes the information
within a page.

The files and access methods layer code sits on top of the buffer manager, which brings pages in from
disk to main memory as needed in response to read requests. The lowest layer of the DBMS software
deals with management of space on disk, where the data is stored. Higher layers allocate, deallocate,
read, and write pages through (routines provided by) this layer, called the disk space manager.

The DBMS supports concurrency and crash recovery by carefully scheduling user requests and
maintaining a log of all changes to the database. DBMS components associated with concurrency control
and recovery include the transaction manager, which ensures that transactions request and release
locks according to a suitable locking protocol and schedules the execution transactions; the lock
manager, which keeps track of requests for locks and grants locks on database objects when they
become available; and the recovery manager, which is responsible for maintaining a log, and restoring
the system to a consistent state after a crash. The disk space manager, buffer manager, and file and
access method layers must interact with these components.

DATA MODELS

 A collection of tools for describing

o Data
o Data relationships
o Data semantics
o Data constraints

TYPES OF DATA MODELS

 Relational model
 Entity-Relationship data model (mainly for database design)
 Object-based data models (Object-oriented and Object-relational)
 Semistructured data model (XML)
 Other older models:
o Network model
o Hierarchical model

E-R MODELLING
ENTITY:

An entity is an object in the real world that is distinguishable from other objects.

Examples : a person, a car, a toy, a department, a course.

ENTITY SET:

It is often useful to identify a collection of similar entities. Such a collection is called an entity
set. Note that entity sets need not be disjoint

ATTRIBUTES:

An entity is described using a set of attributes. All entities in a given entity set have the same
attributes. For example, the Employees entity set could use name, social security number (ssn)

 Attribute types:
o Simple and composite attributes.

o Single-valued and multi-valued attributes

Example: multivalued attribute: phone_numbers
o Derived attributes
Can be computed from other attributes
Example: age, given date_of_birth

DOMAIN:

For each attribute associated with an entity set, we must identify a domain of possible values. For
example, the domain associated with the attribute name of Employees might be the set of 20-
character strings.2 As another example, if the company rates employees on a scale of 1 to 10 and
stores ratings in a field called rating, the associated domain consists of integers 1 through 10.

KEY:

A key is a minimal set of attributes whose values uniquely identify an entity in the set. There could
be more than one candidate key; if so, we designate one of them as the primary key.

RELATIONSHIPS AND RELATIONSHIP SETS

A relationship is an association among two or more entities. For example, we may have the
relationship that ALLEN works in the pharmacy department. As with entities, we may wish to collect
a set of similar relationships into a relationship set.
A relationship set can be thought of as a set of n-tuples:

{(e1,...,en)|e1 ∈E1,...,en ∈En}

Each n-tuple denotes a relationship involving n entities e1 through en, where entity ei

is in entity set Ei.

RELATIONSHIP ATTRIBUTES

A relationship can also have descriptive attributes. Descriptive attributes are used to record
information about the relationship, rather than about any one of the participating entities; for
example

we may wish to record that ALLEN works in the pharmacy department SINCE January 1991.

DEGREE OF RELATIONSHIP

 Refers to number of entity sets that participate in a relationship set.

 Relationship sets that involve two entity sets are binary (or degree two). Generally, most
relationship sets in a database system are binary.
 Relationship sets may involve more than two entity sets.
 Relationships between more than two entity sets are rare. Most relationships are binary.
MAPPING CARDINATILIES

 Express the number of entities to which another entity can be associated via a relationship set.
 Most useful in describing binary relationship sets.
 For a binary relationship set the mapping cardinality must be one of the following types:

o One to one
o One to many
o Many to one
o Many to many

ER DIAGRAM SYMBOLS:
 SIMPLE ER DIAGRAM

MAPPING CONSTRAINTS IN ER DIAGRAM

 We express cardinality constraints by drawing either a directed line (®), signifying “one,” or an
undirected line (—), signifying “many,” between the relationship set and the entity set.
 ONE TO MANY

MANY TO ONE

MANY TO MANY

PARTICIPATION CONSTRAINTS IN ER DIAGRAM

 Total participation (indicated by double line): every entity in the entity set participates in at
least one relationship in the relationship set
o E.g. participation of loan in borrower is total
 every loan must have a customer associated to it via borrower
 Partial participation: some entities may not participate in any relationship in the relationship set
o Example: participation of customer in borrower is partial
WEAK ENTITY SET

 An entity set that does not have a primary key is referred to as a weak entity set.
 The existence of a weak entity set depends on the existence of a identifying entity set
 it must relate to the identifying entity set via a total, one-to-many relationship
set from the identifying to the weak entity set
o Identifying relationship depicted using a double diamond
 The discriminator (or partial key) of a weak entity set is the set of attributes that distinguishes
among all the entities of a weak entity set.
 The primary key of a weak entity set is formed by the primary key of the strong entity set on
which the weak entity set is existence dependent, plus the weak entity set’s discriminator.
 We depict a weak entity set by double rectangles.
 We underline the discriminator of a weak entity set with a dashed line.
 payment_number – discriminator of the payment entity set
 Primary key for payment – (loan_number, payment_number)

ENHANCED E-R MODELLING

1. SPECIALIZATION
 Top-down design process; we designate subgroupings within an entity set that are
distinctive from other entities in the set.
 These subgroupings become lower-level entity sets that have attributes or participate in
relationships that do not apply to the higher-level entity set.
 Depicted by a triangle component labeled ISA (E.g. customer “is a” person).
 Attribute inheritance – a lower-level entity set inherits all the attributes and relationship
participation of the higher-level entity set to which it is linked.
 2. GENERALIZATIONS
 A bottom-up design process – combine a number of entity sets that share the same
features into a higher-level entity set.
 Specialization and generalization are simple inversions of each other; they are represented
in an E-R diagram in the same way.
 The terms specialization and generalization are used interchangeably.
 The ISA relationship also referred to as superclass - subclass relationship

SPECIALIZATION CONSTRAINTS

(i) Constraint on whether or not entities may belong to more than one lower-level entity set
within a single generalization.

Disjoint

An entity can belong to only one lower-level entity set

Noted in E-R diagram by writing disjoint next to the ISA triangle

Overlapping

An entity can belong to more than one lower-level entity set

(ii) Completeness constraint -- specifies whether or not an entity in the higher-level entity set
must belong to at least one of the lower-level entity sets within a generalization.

total : an entity must belong to one of the lower-level entity sets

partial: an entity need not belong to one of the lower-level entity sets

3. AGGREGATION

Consider the ternary relationship works_on, Suppose we want to record managers for tasks
performed by an employee at a branch
 Relationship sets works_on and manages represent overlapping information
o Every manages relationship corresponds to a works_on relationship
o However, some works_on relationships may not correspond to any manages
relationships
 So we can’t discard the works_on relationship
 Eliminate this redundancy via aggregation
o Treat relationship as an abstract entity
o Allows relationships between relationships
o Abstraction of relationship into new entity
 Without introducing redundancy, the following diagram represents:
o An employee works on a particular job at a particular branch
o An employee, branch, job combination may have an associated manager

RELATIONAL MODEL

 Relational database: a set of relations

 Relation: made up of 2 parts:
o Instance : a table, with rows and columns.
#Rows = cardinality, #fields = degree / arity.
o Schema : specifies name of relation, plus name and type of each column.
 E.G. Students(sid: string, name: string, login: string, age: integer, gpa: real)
 Can think of a relation as a set of rows or tuples (i.e., all rows are distinct).

Sid Name Login age

5366 Jones jones@cs 23
5367 Smith Smith2ees 18
 5368 Smith smith@math 19

Cardinality = 3, degree = 5, all rows distinct

LEVELS OF DATA ABSTRACTIONS

 Physical level: describes how a record (e.g., customer) is stored.

 Logical level: describes data stored in database, and the relationships among the data.

type customer = record

customer_id : string;
customer_name : string;
customer_street : string;
customer_city : string;

end;

 View level: application programs hide details of data types. Views can also hide information
(such as an employee’s salary) for security purposes.

INSTANCES & SCHEMAS

 Similar to types and variables in programming languages

 Schema – the logical structure of the database

o Example: The database consists of information about a set of customers and accounts
and the relationship between them)

o Analogous to type information of a variable in a program

o Physical schema: database design at the physical level

o Logical schema: database design at the logical level

  Instance – the actual content of the database at a particular point in time

o Analogous to the value of a variable

 Physical Data Independence – the ability to modify the physical schema without changing
the logical schema

o Applications depend on the logical schema

o In general, the interfaces between the various levels and components

should be well defined so that changes in some parts do not seriously
influence others.

EXAMPLE- LEVELS OF SCHEMA

 Conceptual schema:

 Students(sid: string, name: string, login: string,

age: integer, gpa:real)

 Courses(cid: string, cname:string, credits:integer)

 Enrolled(sid:string, cid:string, grade:string)

 Physical schema:

 Relations stored as unordered files.

 Index on first column of Students.

 External Schema (View):

 Course_info(cid:string,enrollment:integer)

CONCEPT OF KEYS:

A set of fields is a key for a relation if :

1. No two distinct tuples can have same values in all key fields, and

2. This is not true for any subset of the key.

 Part 2 false? A superkey.

 If there’s >1 key for a relation, one of the keys is chosen (by DBA) to be the primary key.

Regno is the primary key for the student relation

{regno,gpa} is the superkey.

Candidate key

This is the minimal super key. If the extraneous attributes are removed from super key, it is
called candidate key.

Primary key:

One of the candidate key which is choosen to uniquely identify a record is called primary key.

Primary key = unique+not null

Foreign key :

Set of fields in one relation that is used to `refer’ to a tuple in another relation.

RELATIONAL QUERY LANGUAGES

 Language in which user requests information from the database.

 Categories of languages
o procedural
o non-procedural
 “Pure” languages:
o Relational Algebra
o Tuple Relational Calculus
o Domain Relational Calculus

Pure languages form underlying basis of query languages that people use

RELATIONAL ALGEBRA

 Procedural language

 Six basic operators

o Select s branch-name=“Perryridge”(account)

o Project Õaccount-number, balance (account)

o Union Õcustomer-name (depositor) È Õcustomer-name (borrower)

o set difference r – s = {t | t Î r and t Ï s}

o Cartesian product r x s

o Rename r x (E)

 The operators take one or more relations as inputs and give a new relation as a result
*****(Give examples for each discussed in class)*****
SQL- STRUCTURED QUERY LANGUAGE

 Structured Query Language (SQL) is the most widely used commercial relational
database language. It was originally developed at IBM in the SEQUEL-XRM and System-R
projects (1974–1977). Almost immediately, other vendors introduced DBMS products
based on SQL, and it is now a de facto standard. SQL continues to evolve in response to
changing needs in the database area. extensions in the new standard, SQL:1999.
 The SQL language has several aspects to it:
 The Data Definition Language (DDL): This subset of SQL supports the creation, deletion,
and modification of definitions for tables and views. Integrity constraints can be defined
on tables, either when the table is created or later. The DDL also provides commands for
specifying access rights or privileges to tables and views.
 The Data Manipulation Language (DML): This subset of SQL allows users to pose
queries and to insert, delete, and modify rows.
 Embedded and dynamic SQL: Embedded SQL features allow SQL code to be called from
a host language such as C or COBOL. Dynamic SQL features allow a query to be
constructed (and executed) at run-time.
 Triggers: The new SQL:1999 standard includes support for triggers, which are actions
executed by the DBMS whenever changes to the database meet conditions specified in
the trigger.
 Security: SQL provides mechanisms to control users’ access to data objects such as
tables and views.
 Transaction management: Various commands allow a user to explicitly control aspects
of how a transaction is to be executed.
 Client-server execution and remote database access: These commands control how a
client application program can connect to an SQL database server,or access data from a
database over a network.

******(Give supporting SQL queries from practical classes)******

RELATIONAL DATABASE DESIGN

I. Functional Dependency:
 FD is the property of the information represented by the relation.

 A functional dependency (FD) is a constraint between two sets of attributes in a relation from a
database.

Given a relation R, a set of attributes X in R is said to functionally determine another attribute Y, also in
R, (written X → Y) if, and only if, each X value is associated with precisely one Y value. Customarily we
call X the determinant set and Y the dependent attribute. Thus, given a tuple and the values of the
attributes in X, one can determine the corresponding value of the Y attribute. In simple words, if X value
is known, Y value is certainly known.
  A functional dependency FD: X → Y is called trivial if Y is a subset of X.

Properties of functional dependencies

Given that X, Y, and Z are sets of attributes in a relation R, one can derive several properties of functional
dependencies. Among the most important are Armstrong's axioms, which are used in database
normalization:

 Subset Property (Axiom of Reflexivity): If Y is a subset of X, then X → Y

 Augmentation (Axiom of Augmentation): If X → Y, then XZ → YZ
 Transitivity (Axiom of Transitivity): If X → Y and Y → Z, then X → Z

From these rules, we can derive these secondary rules:

 Union: If X → Y and X → Z, then X → YZ

 Decomposition: If X → YZ, then X → Y and X → Z
 Pseudotransitivity: If X → Y and WY → Z, then WX → Z
 Self-Determination: X→X
 Composition: if X→Y and Z→W then XZ→YW
 Self Accumulation: if X→YZ and Z→W, then X→YZW

Equivalent sets of functional dependencies are called covers of each other. Every set of functional
dependencies has a canonical cover.

Example

This example illustrates the concept of functional dependency. The situation modeled is that of college
students visiting one or more lectures in each of which they are assigned a teaching assistant (TA). Let's
further assume that every student is in some semester and is identified by a unique integer ID.

StudentID Semester Lecture TA

1234 6 Numerical Methods John
2380 4 Numerical Methods Peter
1234 6 Visual Computing Amina
1201 4 Numerical Methods Peter
1201 4 Physics II Simone

We notice that whenever two rows in this table feature the same StudentID, they also necessarily have
the same Semester values. This basic fact can be expressed by a functional dependency:

 StudentID → Semester.

Other nontrivial functional dependencies can be identified, for example:

 {StudentID, Lecture} → TA
 {StudentID, Lecture} → {TA, Semester}
The latter expresses the fact that the set {StudentID, Lecture} is a superkey of the relation.

Functional Dependency Diagrams

Functional dependency diagrams are a useful diagrammatic way of showing functional dependencies.
They are especially helpful in deducing the closure of an attribute set or of a set of functional
dependencies.

The following are some guidelines for drawing functional dependency diagrams.

1. Each attribute in the relation schema appears only once in the diagram.
2. If the left side of a functional dependency consists of an irreducible set of attributes, these
attributes are enclosed in a box from which the arrow for that FD originates.
3. All arrows terminate on single attributes. In other words, apply Armstrong's decomposition rule
to turn FDs with multiple attributes on the right-hand side into multiple FDs with only one
attribute on the right-hand side.

Example: Given the set of functional dependencies

A→BC

CG→HI A B

B→H H
C

G I

Background to normalization: definitions

Functional dependency

In a given table, an attribute Y is said to have a functional dependency on a set of attributes X

(written X → Y) if and only if each X value is associated with precisely one Y value. For example,
in an "Employee" table that includes the attributes "Employee ID" and "Employee Date of Birth",
the functional dependency {Employee ID} → {Employee Date of Birth} would hold. It follows
from the previous two sentences that each {Employee ID} is associated with precisely one
{Employee Date of Birth}.

Trivial functional dependency

A trivial functional dependency is a functional dependency of an attribute on a superset of itself.

{Employee ID, Employee Address} → {Employee Address} is trivial, as is {Employee Address} →
{Employee Address}.

Full functional dependency

 An attribute is fully functionally dependent on a set of attributes X if it is

 functionally dependent on X, and

 not functionally dependent on any proper subset of X. {Employee Address} has a
functional dependency on {Employee ID, Skill}, but not a full functional dependency,
because it is also dependent on {Employee ID}.

Transitive dependency
A transitive dependency is an indirect functional dependency, one in which X→Z only by virtue
of X→Y and Y→Z.

Multivalued dependency

A multivalued dependency is a constraint according to which the presence of certain rows in a

table implies the presence of certain other rows.

Join dependency

A table T is subject to a join dependency if T can always be recreated by joining multiple tables
each having a subset of the attributes of T.

Redundant FD

A FD in the set is redundant it it can be derived from the other FD in the set. A redundant FD is
detected using the following steps.

1. Start with a set of S of FD’s.

2. Remove an FD f and create a set of FD’s.S’=S-f
3. Test whether f can be derived from the FD’s in S by using armstrongs axioms.
4. If f can be so derived, it is redundant, hence S’=S
5. Repeat steps 2 to 4 for all FDs in S

Closure of a set of FD

A closure of a set of FD defines all the FDs that can be derived from a given set of FDs.

II. DECOMPOSTION

A Functional Decomposition is the process of breaking down the functions of an organization

into progressively great levels of detail. It helps in eliminating redundancy,inconsistencies and
anomalies.

Lossy Decompostion

One of the disadvantages of decomposition into two or more realational schema is that come
information is lost during retrieval of original relation or table. This is called lossy decomposition of
Lossy-join decomposition.
Example:

A B C
A1 B1 C1
A2 B2 C2
A3 B3 C3
A4 B4 C4
Decomposition

A BC
A1 B1
A3 B1
A2 B2
A4 B2
B
B1 C1
B1 C2
B2 C3
B2 C4
JOIN

A B C
A1 B1 C1
A2 B2 C2
A3 B1 C1
A3 B1 C2
A2 B2 C3
A2 B2 C4
A4 B2 C3
A4 B2 C4

Lossless decomposition

Lossless-Join if R1⋈R2 = R.
Can also be called Nonadditive. If you decompose a relation R into relations R1 and R2 you will guaranty a

Let R be a relation schema.

Let F be a set of functional dependencies on R.

Let R1 and R2 form a decomposition of R.

The decomposition is a lossless-join decomposition of R if at least one of the following functional

dependencies are in F+(where F+ stands for the closure for every attribute in F):

 R1 ∩ R2 → R1
  R1 ∩ R2 → R2

Example:

X Y Z
X1 Y1 Z1
X2 Y2 Z2
X3 Y2 Z1
X4 Y1 Z2

Decompose
X Y
X1 Y1 X Z
X2 Y2 X1 Z1
X3 Y2 X2 Z2
X4 Y1 X3 Z1
Join
X4 Z2
X Y Z
X1 Y1 Z1
X2 Y2 Z2
X3 Y2 Z1
X4 Y1 Z2

Dependency Preserving Decomposition

Decomposition d={R1,R2,…Rm} of R is said to be dependency preserving with respect to F if the union of

the projections of F on each Ri in D is equivalent to F.

NORMALIZATION

DEFINITION

In the design of a relational database management system (RDBMS), the process of organizing data to
minimize redundancy is called normalization.

GOAL:

The goal of database normalization is to decompose relations with anomalies in order to produce
smaller, well-structured relations. 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.
1NF A relation R is in first normal form (1NF) if and only if all underlying domains contain atomic
values only

Example: 1NF but not 2NF

FIRST (supplier_no, status, city, part_no, quantity)

Functional Dependencies:

(supplier_no, part_no)  quantity

(supplier_no)  status

(supplier_no)  city

city  status (Supplier's status is determined by location)

Comments:

Non-key attributes are not mutually independent (city  status).

Non-key attributes are not fully functionally dependent on the primary key (i.e., status and city are
dependent on just part of the key, namely supplier_no).

Anomalies:

INSERT: We cannot enter the fact that a given supplier is located in a given city until that supplier
supplies at least one part (otherwise, we would have to enter a null value for a column participating in
the primary key C a violation of the definition of a relation).

DELETE: If we delete the last (only) row for a given supplier, we lose the information that the supplier is
located in a particular city.

UPDATE: The city value appears many times for the same supplier. This can lead to inconsistency or the
need to change many values of city if a supplier moves.

Decomposition (into 2NF):

SECOND (supplier_no, status, city)

SUPPLIER_PART (supplier_no, part_no, quantity)

2NF A relation R is in second normal form (2NF) if and only if it is in 1NF and every non-key attribute is
fully dependent on the primary key
Example (2NF but not 3NF):

SECOND (supplier_no, status, city)

Functional Dependencies:

supplier_no  status

supplier_no  city

city  status

Comments:

Lacks mutual independence among non-key attributes.

Mutual dependence is reflected in the transitive dependencies: supplier_no  city, city  status.

Anomalies:

INSERT: We cannot record that a particular city has a particular status until we have a supplier in that
city.

DELETE: If we delete a supplier which happens to be the last row for a given city value, we lose the fact
that the city has the given status.

UPDATE: The status for a given city occurs many times, therefore leading to multiple updates and
possible loss of consistency.

Decomposition (into 3NF):

SUPPLIER_CITY (supplier_no, city)

CITY_STATUS (city, status)

Third Normal Form

3NF is an even stricter normal form and removes virtually all the redundant data :

 A relation is in 3NF if, and only if, it is in 2NF and there are no transitive functional dependencies
 Transitive functional dependencies arise:
 when one non-key attribute is functionally dependent on another non-key attribute:
 FD: non-key attribute -> non-key attribute
 and when there is redundancy in the database
Example (3NF but not BCNF):

SUPPLIER_PART (supplier_no, supplier_name, part_no, quantity)

Functional Dependencies:

We assume that supplier_name's are always unique to each supplier. Thus we have two candidate keys:

(supplier_no, part_no) and (supplier_name, part_no)

Thus we have the following dependencies:

(supplier_no, part_no)  quantity

(supplier_no, part_no)  supplier_name

(supplier_name, part_no)  quantity

(supplier_name, part_no)  supplier_no

supplier_name  supplier_no

supplier_no  supplier_name

Comments:

Although supplier_name  supplier_no (and vice versa), supplier_no is not a non-key column — it is part
of the primary key! Hence this relation technically satisfies the definition(s) of 3NF (and likewise 2NF,
again because supplier_no is not a non-key column).

Anomalies:

INSERT: We cannot record the name of a supplier until that supplier supplies at least one part.

DELETE: If a supplier temporarily stops supplying and we delete the last row for that supplier, we lose
the supplier's name.

UPDATE: If a supplier changes name, that change will have to be made to multiple rows (wasting
resources and risking loss of consistency).

Decomposition (into BCNF):

SUPPLIER_ID (supplier_no, supplier_name)

SUPPLIER_PARTS (supplier_no, part_no, quantity)

BCNF : BOYCE CODE NORMAL FORM

A table is in BCNF when every determinant in the table is a candidate key.

When a table contains only one candidate key, 3NF and BCNF are equivalent.

BCNF is a special case of 3NF.

A table is in 3NF if it is in 2NF and there are no transitive dependencies.

But if a non-key attribute is a determinant of a key attribute then it falis to meet the BCNF requirement.

Example:

A+b---c,D

c--B

This does not have any partial dependencies, nor transitive dependency. The condition c->B indicates
that a non-key attribute determines a part of primary key. To convert the table structure into BCNF, first
change primary key to A+C. Now the table is in 1NF as it contains a partial dependency. Then follow the
standard decomposition procedure

A B C D 3NF but not BCNF,

A C B D Now in 1NF with partial dependency.

Decomposing,

A C D 3NF & BCNF

C B

Fourth Normal Form

4NF is concerned with multivalued dependency. A table is in 4NF if for every one of its non-trivial
multivalued dependency x->> y, x is a superkey

A functional dependency is a special case of multivalued dependency. In a functional dependency X

→ Y, every x determines exactly one y, never more than one.
A trivial multivalued dependency X->> Y is one where either Y is a subset of X, or X and Y together
form the whole set of attributes of the relation.

Example

Consider the following example:

Pizza Delivery Permutations

Restaurant Pizza Variety Delivery Area

A1 Pizza Thick Crust Springfield

A1 Pizza Thick Crust Shelbyville

A1 Pizza Stuffed Crust Capital City

Elite Pizza Thin Crust Capital City

Elite Pizza Stuffed Crust Capital City

Each row indicates that a given restaurant can deliver a given variety of pizza to a given area.

The table has no non-key attributes because its only key is {Restaurant, Pizza Variety, Delivery Area}.
Therefore it meets all normal forms up to BCNF

The problem is that the table features two non-trivial multivalued dependencies on the {Restaurant}
attribute (which is not a superkey). The dependencies are:

{Restaurant}->> {Pizza Variety}

{Restaurant} >{Delivery Area}

To eliminate the possibility of these anomalies, we must place the facts about varieties offered into
a different table from the facts about delivery areas, yielding two tables that are both in 4NF:

Varieties By Restaurant( Restaurant, Pizza Variety )

Delivery Areas By Restaurant (Restaurant, Delivery Area )

FIFTH NORMAL FORM

A relation is said to be in 5NF, if every join dependency is a consequence of its candidate keys.

5NF is also called Project Join Normal Form.

5NF is mainly used for theoretical purpose and not for practical database design.

Any relation that is in 5Nf, is also in other normal forms.

Example:

Consider the relations

has_skills(person,skill_type)

needs_skill(skill_type,job)

job_assigned(person,job)

Now by applying the definition of 5NF, the join dependency is given as,

(person,skill_type),(skill_type,job),(person,job)

The join relation of the 3 will give the original relation.