Unit2 -DBMS.ppt with type of job operation

Data Dictionary
• A data dictionary contains metadata i.e
data about the database. The data
dictionary is very important as it contains
information such as what is in the
database, who is allowed to access it,
where is the database physically stored
etc. The users of the database normally
don't interact with the data dictionary, it is
only handled by the database
administrators.

The data dictionary in general contains information about
the following −
• Names of all the database tables and their schemas.
• Details about all the tables in the database, such as their
owners, their security constraints, when they were
created etc.
• Physical information about the tables such as where they
are stored and how.
• Table constraints such as primary key attributes, foreign
key information etc.
• Information about the database views that are visible.

This is a data dictionary describing a table that
contains employee details.
Field Name Data Type Field Size for
display
Description Example
Employee
Number
Integer 10 Unique ID of
each employee
1645000001
Name Text 20 Name of the
employee
David Heston
Date of Birth Date/Time 10 DOB of
Employee
08/03/1995
Phone Number Integer 10 Phone number
of employee
6583648648

The different types of data dictionary are −
Active Data Dictionary
• If the structure of the database or its specifications
change at any point of time, it should be reflected in the
data dictionary. This is the responsibility of the database
management system in which the data dictionary resides.
• So, the data dictionary is automatically updated by the
database management system when any changes are
made in the database. This is known as an active data
dictionary as it is self updating.

Passive Data Dictionary
• This is not as useful or easy to handle as an active data
dictionary. A passive data dictionary is maintained
separately to the database whose contents are stored in
the dictionary. That means that if the database is
modified the database dictionary is not automatically
updated as in the case of Active Data Dictionary.
• So, the passive data dictionary has to be manually
updated to match the database. This needs careful
handling or else the database and data dictionary are
out of sync.

Relational Algebra
• Relational algebra is a procedural query
language. It gives a step by step process
to obtain the result of the query. It uses
operators to perform queries.

• 1. Select Operation:
• The select operation selects tuples that satisfy a given predicate.
• It is denoted by sigma (σ).
Notation: σ p(r)
Where:
σ is used for selection prediction
r is used for relation
p is used as a propositional logic formula which may
use connectors like: AND OR and NOT. These relational
can use as relational operators like =, ≠, ≥, <, >, ≤.

For example: LOAN Relation
BRANCH_NAME LOAN_NO AMOUNT
Downtown L-17 1000
Redwood L-23 2000
Perryride L-15 1500
Downtown L-14 1500
Mianus L-13 500
Roundhill L-11 900
Perryride L-16 1300
Input:
σ BRANCH_NAME="perryride" (LOAN)

• Output:
BRANCH_NAME LOAN_NO AMOUNT
Perryride L-15 1500
Perryride L-16 1300

Project Operation:
• This operation shows the list of those attributes
that we wish to appear in the result. Rest of the
attributes are eliminated from the table.
• It is denoted by ∏.
Notation: ∏ A1, A2, An (r)
– Where
– A1, A2, A3 is used as an attribute name of relation r.

Example: CUSTOMER
RELATION
NAME STREET CITY
Jones Main Harrison
Smith North Rye
Hays Main Harrison
Curry North Rye
Johnson Alma Brooklyn
Brooks Senator Brooklyn
Input:
1.∏ NAME, CITY (CUSTOMER)

NAME CITY
Jones Harrison
Smith Rye
Hays Harrison
Curry Rye
Johnson Brooklyn
Brooks Brooklyn
Output:

Union Operation:
• Suppose there are two tuples R and S. The union
operation contains all the tuples that are either in R or S
or both in R & S.
• It eliminates the duplicate tuples. It is denoted by ∪.
Notation: R ∪ S
• A union operation must hold the following condition:
R and S must have the attribute of the same number.
• Duplicate tuples are eliminated automatically.

Example: DEPOSITOR
RELATION
CUSTOMER_NAME ACCOUNT_NO
Johnson A-101
Smith A-121
Mayes A-321
Turner A-176
Johnson A-273
Jones A-472
Lindsay A-284
CUSTOMER_NAME LOAN_NO
Jones L-17
Smith L-23
Hayes L-15
Jackson L-14
Curry L-93
Smith L-11
Williams L-17

Input:
∏ CUSTOMER_NAME (BORROW) ∪ ∏ CUSTOMER_NAME (DEPOS
ITOR)
CUSTOMER_NAME
Johnson
Smith
Hayes
Turner
Jones
Lindsay
Jackson
Curry
Williams
Mayes

Set Intersection:
•Suppose there are two tuples R and S. The
set intersection operation contains all tuples
that are in both R & S.
•It is denoted by intersection ∩.
1.Notation: R ∩ S
Example: Using the above DEPOSITOR
table and BORROW table

• Input:
1.∏ CUSTOMER_NAME (BORROW) ∩ ∏ C
USTOMER_NAME (DEPOSITOR)
CUSTOMER_NAME
Smith
Jones

Set Difference:
• Suppose there are two tuples R and S.
The set intersection operation contains all
tuples that are in R but not in S.
• It is denoted by intersection minus (-).
Notation: R - S
• Example: Using the above DEPOSITOR
table and BORROW table

Input:
∏ CUSTOMER_NAME (BORROW) -
∏ CUSTOMER_NAME (DEPOSITOR)
CUSTOMER_NAME
Jackson
Hayes
Willians
Curry

Cartesian product
• The Cartesian product is used to combine
each row in one table with each row in the
other table. It is also known as a cross
product.
• It is denoted by X.

Example
• EMPLOYEE
• Department
EMP_ID EMP_NAME EMP_DEPT
1 Smith A
2 Harry C
3 John B
DEPT_NO DEPT_NAME
A Marketing
B Sales
C Legal

Input:
EMPLOYEE X DEPARTMENT
EMP_ID EMP_NAME EMP_DEPT DEPT_NO DEPT_NAME
1 Smith A A Marketing
1 Smith A B Sales
1 Smith A C Legal
2 Harry C A Marketing
2 Harry C B Sales
2 Harry C C Legal
3 John B A Marketing
3 John B B Sales
3 John B C Legal

Rename Operation:
• The rename operation is used to rename
the output relation. It is denoted
by rho (ρ).
• Example: We can use the rename
operator to rename STUDENT relation to
STUDENT1.
ρ(STUDENT1, STUDENT)

Join Operations:
• A Join operation combines related tuples
from different relations, if and only if a
given join condition is satisfied. It is
denoted by ⋈.
Example:
EMPLOYEE
EMP_CODE EMP_NAME
101 Stephan
102 Jack
103 Harry

SALARY
Operation: (EMPLOYEE ⋈ SALARY)
EMP_CODE SALARY
101 50000
102 30000
103 25000
EMP_CODE EMP_NAME SALARY
101 Stephan 50000
102 Jack 30000
103 Harry 25000

Natural Join:
• A natural join is the set of tuples of all combinations in R
and S that are equal on their common attribute names.
• It is denoted by ⋈.
– Example: Let's use the above EMPLOYEE table and SALARY
table:
Input:
∏EMP_NAME, SALARY (EMPLOYEE ⋈ SALARY)
Output
EMP_NAME SALARY
Stephan 50000
Jack 30000
Harry 25000

Outer Join:
• The outer join operation is an extension of the join
operation. It is used to deal with missing information.
Example:
– EMPLOYEE
EMP_NAME STREET CITY
Ram Civil line Mumbai
Shyam Park street Kolkata
Ravi M.G. Street Delhi
Hari Nehru nagar Hyderabad

FACT_WORKERS
Input:(EMPLOYEE ⋈ FACT_WORKERS)
EMP_NAME BRANCH SALARY
Ram Infosys 10000
Shyam Wipro 20000
Kuber HCL 30000
Hari TCS 50000
EMP_NAM
E
STREET CITY BRANCH SALARY
Ram Civil line Mumbai Infosys 10000
Shyam Park street Kolkata Wipro 20000
Hari Nehru nagar Hyderabad TCS 50000

An outer join is basically of three types:
a.Left outer join
b.Right outer join
c.Full outer join

a. Left outer join:
• Left outer join contains the set of tuples of all
combinations in R and S that are equal on their common
attribute names.
• In the left outer join, tuples in R have no matching tuples
in S.
• It is denoted by ⟕.
• Example: Using the above EMPLOYEE table and
FACT_WORKERS table
Input
EMPLOYEE ⟕ FACT_WORKERS

EMP_NAME STREET CITY BRANCH SALARY
Hari Nehru street Hyderabad TCS 50000
Ravi M.G. Street Delhi NULL NULL

Right outer join:
• Right outer join contains the set of tuples of all
combinations in R and S that are equal on their common
attribute names.
• In right outer join, tuples in S have no matching tuples in
R.
• It is denoted by ⟖.
– Example: Using the above EMPLOYEE table and
FACT_WORKERS Relation
Input: EMPLOYEE ⟖ FACT_WORKERS

EMP_NAME BRANCH SALARY STREET CITY
Ram Infosys 10000 Civil line Mumbai
Shyam Wipro 20000 Park street Kolkata
Hari TCS 50000 Nehru street Hyderabad
Kuber HCL 30000 NULL NULL

• Full outer join:
• Full outer join is like a left or right join except that it
contains all rows from both tables.
• In full outer join, tuples in R that have no matching tuples
in S and tuples in S that have no matching tuples in R in
their common attribute name.
• It is denoted by ⟗.
• Example: Using the above EMPLOYEE table and
FACT_WORKERS table
• Input:
EMPLOYEE ⟗ FACT_WORKERS

EMP_NAME STREET CITY BRANCH SALARY
Hari Nehru street Hyderabad TCS 50000
Ravi M.G. Street Delhi NULL NULL
Kuber NULL NULL HCL 30000

Equi join:
• It is also known as an inner join. It is the
most common join. It is based on matched
data as per the equality condition. The
equi join uses the comparison operator(=).
Example:
CUSTOMER RELATION
CLASS_ID NAME
1 John
2 Harry
3 Jackson

PRODUCT_ID CITY
1 Delhi
2 Mumbai
3 Noida
CLASS_ID NAME PRODUCT_ID CITY
1 John 1 Delhi
2 Harry 2 Mumbai
3 Harry 3 Noida

Integrity Constraints
• Integrity constraints are a set of rules. It is
used to maintain the quality of information.
• Integrity constraints ensure that the data
insertion, updating, and other processes
have to be performed in such a way that
data integrity is not affected.
• Thus, integrity constraint is used to guard
against accidental damage to the
database

1. Domain constraints
• Domain constraints can be defined as the
definition of a valid set of values for an
attribute.
• The data type of domain includes string,
character, integer, time, date, currency,
etc. The value of the attribute must be
available in the corresponding domain.

2. Entity integrity constraints
• The entity integrity constraint states that
primary key value can't be null.
• This is because the primary key value is
used to identify individual rows in relation
and if the primary key has a null value,
then we can't identify those rows.
• A table can contain a null value other than
the primary key field.

3. Referential Integrity Constraints
• A referential integrity constraint is specified
between two tables.
• In the Referential integrity constraints, if a
foreign key in Table 1 refers to the Primary
Key of Table 2, then every value of the
Foreign Key in Table 1 must be null or be
available in Table 2.

Unit2 -DBMS.ppt with type of job operation

4. Key constraints
• Keys are the entity set that is used to
identify an entity within its entity set
uniquely.
• An entity set can have multiple keys, but
out of which one key will be the primary
key. A primary key can contain a unique
and null value in the relational table.

Normalization
• A large database defined as a single relation
may result in data duplication. This repetition of
data may result in:
• Making relations very large.
• It isn't easy to maintain and update data as it would
involve searching many records in relation.
• Wastage and poor utilization of disk space and
resources.
• The likelihood of errors and inconsistencies
increases.

• So to handle these problems, we should
analyze and decompose the relations with
redundant data into smaller, simpler, and
well-structured relations that are satisfy
desirable properties. Normalization is a
process of decomposing the relations into
relations with fewer attributes.

What is Normalization?
• Normalization is the process of organizing the
data in the database.
• Normalization is used to minimize the
redundancy from a relation or set of relations. It
is also used to eliminate undesirable
characteristics like Insertion, Update, and
Deletion Anomalies.
• Normalization divides the larger table into
smaller and links them using relationships.
• The normal form is used to reduce redundancy

Why do we need
Normalization?
• The main reason for normalizing the
relations is removing these anomalies.
Failure to eliminate anomalies leads to
data redundancy and can cause data
integrity and other problems as the
database grows. Normalization consists of
a series of guidelines that helps to guide
you in creating a good database structure.

Data modification anomalies can be categorized into
three types:
• Insertion Anomaly: Insertion Anomaly refers to when
one cannot insert a new tuple into a relationship due to
lack of data.
• Deletion Anomaly: The delete anomaly refers to the
situation where the deletion of data results in the
unintended loss of some other important data.
• Updation Anomaly: The update anomaly is when an
update of a single data value requires multiple rows of
data to be updated.

Types of Normal Forms:
• Normalization works through a series of stages called Normal forms. The
normal forms apply to individual relations. The relation is said to be in
particular normal form if it satisfies constraints.
• Following are the various types of Normal forms:

Normal Form Description
1NF A relation is in 1NF if it contains an atomic value.
2NF A relation will be in 2NF if it is in 1NF and all non-key attributes
are fully functional dependent on the primary key.
3NF A relation will be in 3NF if it is in 2NF and no transition
dependency exists.
BCNF A stronger definition of 3NF is known as Boyce Codd's normal
form.
4NF A relation will be in 4NF if it is in Boyce Codd's normal form and
has no multi-valued dependency.
5NF A relation is in 5NF. If it is in 4NF and does not contain any join
dependency, joining should be lossless.

Advantages of Normalization
• Normalization helps to minimize data
redundancy.
• Greater overall database organization.
• Data consistency within the database.
• Much more flexible database design.
• Enforces the concept of relational integrity.

Disadvantages of Normalization
• You cannot start building the database before
knowing what the user needs.
• The performance degrades when normalizing
the relations to higher normal forms, i.e., 4NF,
5NF.
• It is very time-consuming and difficult to
normalize relations of a higher degree.
• Careless decomposition may lead to a bad
database design, leading to serious problems.

First Normal Form (1NF)
• A relation will be 1NF if it contains an atomic
value.
• It states that an attribute of a table cannot hold
multiple values. It must hold only single-valued
attribute.
• First normal form disallows the multi-valued
attribute, composite attribute, and their
combinations.
• Example: Relation EMPLOYEE is not in 1NF
because of multi-valued attribute EMP_PHONE.

EMPLOYEE table:
The decomposition of the EMPLOYEE table into 1NF has been
shown below:
EMP_ID EMP_NAME EMP_PHONE EMP_STATE
14 John 7272826385,
9064738238
UP
20 Harry 8574783832 Bihar
12 Sam 7390372389,
8589830302
Punjab

EMP_ID EMP_NAME EMP_PHONE EMP_STATE
14 John 7272826385 UP
14 John 9064738238 UP
20 Harry 8574783832 Bihar
12 Sam 7390372389 Punjab
12 Sam 8589830302 Punjab

Second Normal Form (2NF)
In the 2NF, relational must be in 1NF.
• In the second normal form, all non-key attributes are fully
functional dependent on the primary key
• Example: Let's assume, a school can store the data of
teachers and the subjects they teach. In a school, a
teacher can teach more than one subject.
• TEACHER table
TEACHER_ID SUBJECT TEACHER_AGE
25 Chemistry 30
25 Biology 30
47 English 35
83 Math 38
83 Computer 38

• In the given table, non-prime attribute TEACHER_AGE is dependent
on TEACHER_ID which is a proper subset of a candidate key. That's
why it violates the rule for 2NF.
• To convert the given table into 2NF, we decompose it into two tables:
• TEACHER_DETAIL table:
TEACHER_ID TEACHER_AGE
25 30
47 35
83 38

• TEACHER_SUBJECT table:
TEACHER_ID SUBJECT
25 Chemistry
25 Biology
47 English
83 Math
83 Computer

Third Normal Form (3NF)
• A relation will be in 3NF if it is in 2NF and not contain any
transitive partial dependency.
• 3NF is used to reduce the data duplication. It is also
used to achieve the data integrity.
• If there is no transitive dependency for non-prime
attributes, then the relation must be in third normal form.
• A relation is in third normal form if it holds atleast one of
the following conditions for every non-trivial function
dependency X → Y.
1. X is a super key.
2. Y is a prime attribute, i.e., each element of Y is part of
some candidate key.

Example
EMPLOYEE_DETAIL table:
EMP_ID EMP_NAME EMP_ZIP EMP_STATE EMP_CITY
222 Harry 201010 UP Noida
333 Stephan 02228 US Boston
444 Lan 60007 US Chicago
555 Katharine 06389 UK Norwich
666 John 462007 MP Bhopal

• Super key in the table above:
{EMP_ID}, {EMP_ID, EMP_NAME}, {EMP_ID, EMP_NAME, EMP_ZIP}
....so on
• Candidate key: {EMP_ID}
• Non-prime attributes: In the given table, all attributes except
EMP_ID are non-prime.
• Here, EMP_STATE & EMP_CITY dependent on EMP_ZIP and
EMP_ZIP dependent on EMP_ID. The non-prime attributes
(EMP_STATE, EMP_CITY) transitively dependent on super
key(EMP_ID). It violates the rule of third normal form.
• That's why we need to move the EMP_CITY and EMP_STATE to
the new <EMPLOYEE_ZIP> table, with EMP_ZIP as a Primary key.

EMPLOYEE Table
EMPLOYEE_ZIP table:
EMP_ID EMP_NAME EMP_ZIP
222 Harry 201010
333 Stephan 02228
444 Lan 60007
555 Katharine 06389
666 John 462007
EMP_ZIP EMP_STATE EMP_CITY
201010 UP Noida
02228 US Boston
60007 US Chicago
06389 UK Norwich
462007 MP Bhopal

Boyce Codd normal form
(BCNF)
• BCNF is the advance version of 3NF. It is stricter than
3NF.
• A table is in BCNF if every functional dependency X → Y,
X is the super key of the table.
• For BCNF, the table should be in 3NF, and for every FD,
LHS is super key.
• Example: Let's assume there is a company where
employees work in more than one department.
• EMPLOYEE table:
EMP_ID EMP_COU
NTRY
EMP_DEP
T
DEPT_TY
PE
EMP_DEP
T_NO
264 India Designing D394 283
264 India Testing D394 300
364 UK Stores D283 232
364 UK Developing D283 549

• In the above table Functional dependencies
are as follows:
1.EMP_ID → EMP_COUNTRY
2.EMP_DEPT → {DEPT_TYPE, EMP_DEPT_N
O}
• Candidate key: {EMP-ID, EMP-DEPT}
• The table is not in BCNF because neither
EMP_DEPT nor EMP_ID alone are keys.
• To convert the given table into BCNF, we
decompose it into three tables:

EMP_COUNTRY table:
EMP_DEPT table:
EMP_DEPT_MAPPING table:
EMP_ID EMP_COUNTRY
264 India
264 India
EMP_DEPT DEPT_TYPE EMP_DEPT_NO
Designing D394 283
Testing D394 300
Stores D283 232
Developing D283 549
EMP_ID EMP_DEPT
D394 283
D394 300
D283 232

• Functional dependencies:
1.EMP_ID → EMP_COUNTRY
2.EMP_DEPT → {DEPT_TYPE, EMP_DEPT_N
O}
• Candidate keys:
For the first table: EMP_ID
For the second table: EMP_DEPT
For the third table: {EMP_ID, EMP_DEPT}
Now, this is in BCNF because left side part of both the functional
dependencies is a key.

Unit2 -DBMS.ppt with type of job operation

More Related Content

Similar to Unit2 -DBMS.ppt with type of job operation (20)

More from shindhe1098cv (10)

Recently uploaded (20)

Unit2 -DBMS.ppt with type of job operation