0% found this document useful (0 votes)
13 views

Chapter 4

this is advance DBS

Uploaded by

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

Chapter 4

this is advance DBS

Uploaded by

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

Chapter 4: Logical Database Design

Normalization
 A relational database is merely a collection of data, organized in a
particular manner.
 As the father of the relational database approach, Codd created a
series of rules called normal forms that help define that organization
 Database normalization is a series of steps followed to obtain a
database design that allows for consistent storage and efficient access
of data in a relational database.
 These steps reduce data redundancy and the risk of data becoming
inconsistent.
 NORMALIZATION is the process of identifying the logical
associations between data items and designing a database that will
represent such associations but without suffering the update anomalies
which are;
 Insertion Anomalies
Prepared by: Elisaye B.@ WSU-DTC 1
 Deletion Anomalies
 Normalization may reduce system performance since
data will be cross referenced from many tables.
 Thus denormalization is sometimes used to improve
performance, at the cost of reduced consistency
guarantees.
 Normalization normally is considered as good if it is
lossless decomposition.
 All the normalization rules will eventually remove the
update anomalies that may exist during data
manipulation after the implementation. The update
anomalies are;
 Insertion anomalies
 Deletion anomalies
 Modification anomalies
Prepared by: Elisaye B.@ WSU-DTC 2
1. Insertion anomalies
 In a properly normalized database, information about a new
entry needs to be inserted into only one place in the database
 An "insertion anomaly" is a failure to place information
about a new database entry into all the places in the database
where information about that new entry needs to be stored.
2. Deletion anomalies
 A "deletion anomaly" is a failure to remove information
about an existing database entry when it is time to remove
that entry.
3. Modification anomalies
 A modification of a database involves changing some value
of the attribute of a table.
 The purpose of normalization is to reduce the chances for
Prepared by: Elisaye B.@ WSU-DTC 3
anomalies to occur in a database.
Functional Dependency (FD)
 Before moving to the definition and application of normalization,
it is important to have an understanding of "functional
dependency.“
 Data Dependency
 The logical association between data items that point the
database designer in the direction of a good database design are
refered to as determinant or dependent relationships.
 X Y holds if whenever two tuples have the same value for X,
they must have the same value for Y
 The notation is: AB which is read as; B is functionally
dependent on A
 In general, a functional dependency is a relationship among
attributes.
 FDs are derived from the real-world
Prepared constraints on the attributes
by: Elisaye B.@ WSU-DTC 4
Prepared by: Elisaye B.@ WSU-DTC 5
 FDs basically categorized as Partial Dependency,
Full Dependency, Transitive Dependency.
Partial Dependency
 If an attribute which is not a member of the
primary key is dependent on some part of the
primary key (if we have composite primary key)
then that attribute is partially functionally
dependent on the primary key.
 Let {A,B} is the Primary Key and C is no key
attribute.
 Then if {A,B}C and B  C
 Then C is partially functionally dependent on
Prepared by: Elisaye B.@ WSU-DTC 6
Full Dependency
 If an attribute which is not a member of the
primary key is not dependent on some part of the
primary key but the whole key (if we have
composite primary key) then that attribute is fully
functionally dependent on the primary key.
 Let {A,B} is the Primary Key and C is no key
attribute

{A,B}  C and B  C
 Then if

and A  C does not hold


 Then C Fully functionally dependent on {A,B}
Prepared by: Elisaye B.@ WSU-DTC 7
Transitive Dependency
 In mathematics and logic, a transitive relationship is a relationship
of the following form: "If A implies B, and if also B implies C,
then A implies C."
Example:
 If Abebe is a Human, and if every Human is an Animal, then
Abebe must be an Animal.
 Generalized way of describing transitive dependency is that:
 If A functionally governs B, AND
 If B functionally governs C
 THEN A functionally governs C
 Provided that neither C nor B determines A (B /  A and C /  A)
 In the normal notation:

{(A  B) AND (B/  C)} ==> A/  C


Prepared by: Elisaye B.@ WSU-DTC 8
Steps of Normalization:
 We have various levels or steps in normalization called
Normal Forms.
Normalization towards a logical design
consists of the following steps:
 UnNormalized Form: Identify all data elements
 First Normal Form: Find the key with which you can
find all data
 Second Normal Form: Remove part-key
dependencies. Make all data dependent on the whole
key.
 Third Normal Form Remove non-key dependencies.
Prepared by: Elisaye B.@ WSU-DTC 9
First Normal Form (1NF)
 Requires that all column values in a table are atomic (e.g., a
number is an atomic value, while a list or a set is not).
 We have two ways of achieving this:
1. Putting each repeating group into a separate table and
connecting them with a primary key-foreign key relationship
2. Moving this repeating groups to a new row by repeating the
common attributes. If so then Find the key with which you can
find all data.
Definition of a table (relation) in 1NF: If
 There are no duplicated rows in the table. Unique identifier
 Each cell is single-valued (i.e., there are no repeating groups).
 Entries in a column (attribute, field) are of the same kind.
Prepared by: Elisaye B.@ WSU-DTC 10
Example for First Normal form (1NF )

1NF

Prepared by: Elisaye B.@ WSU-DTC 11


Second Normal form 2NF
 No partial dependency of a non key attribute on part of
the primary key. This will result in a set of relations with
a level of Second Normal Form.
 Any table that is in 1NF and has a single-attribute (i.e., a
non-composite) key is automatically also in 2NF.
 Definition of a table (relation) in 2NF
 It is in 1NF and
 If all non-key attributes are dependent on all of the key.
i.e. no partial dependency.
 Since a partial dependency occurs when a non-key
attribute is dependent on only a part of the (composite)
key, the definition of 2NF is sometimes phrased as, "A
table is in 2NF if it isPrepared
in by:1NF and
Elisaye B.@ if it has no partial 12
WSU-DTC
Example for Second Normal form (2NF )

 To convert it to a 2NF we need to remove all partial dependencies of non


key attributes on part of the primary key.
{EmpID, ProjNo} EmpName, ProjName, ProjLoc, ProjFund, ProjMangID
 But in addition to this we have the following dependencies
EmpIDEmpName
ProjNoProjName, ProjLoc, ProjFund, ProjMangID
 As we can see some non key attributes are partially dependent on some
part of the primary key. Thus these collections of attributes should be
moved to a new relation

Prepared by: Elisaye B.@ WSU-DTC 13


Third Normal Form (3NF )
 Eliminate Columns Not Dependent On Key - If
attributes do not contribute to a description of the
key, remove them to a separate table.
 This level avoids update and delete anomalies.
 Definition of a Table (Relation) in 3NF
 It is in 2NF and
 There are no transitive dependencies between
attributes.

Prepared by: Elisaye B.@ WSU-DTC 14


Example for (3NF)
 Assumption: Students of same batch (same year) live in one
building or dormitory

 This schema is in its 2NF since the primary key is a single


attribute.
 Let’s take StudID, Year and Dormitary and see the
dependencies.
 StudIDYear AND YearDormitary
Prepared by: Elisaye B.@ WSU-DTC 15
 Then transitively StudIDDormitary
 To convert it to a 2NF we need to remove all partial
dependencies of non key attributes on part of the
primary key.

Prepared by: Elisaye B.@ WSU-DTC 16


Boyce-Codd Normal Form (BCNF):
 It is advanced version of 3NF
 It is stricter than 3NF
 A 3NF table which does not have multiple
overlapping candidate key is said to be BCNF.
 The relation is in BCNF: IF
 R must be 3NF
 Each functional dependency(XY), X should be a
supper key
Example for (BCNF)
 Lets assume there is a company where employee
work in more than one department data like this:- 17
Prepared by: Elisaye B.@ WSU-DTC
EMPLOYEE table

Functional dependencies in the table above:


emp_id  emp_nationality
emp_dept {dept_type, dept_no_of_emp}
Candidate key: {emp_id, emp_dept}
The table is not in BCNF as neither emp_id nor emp_dept
alone are keys.
To make the table comply with BCNF we can break the
table in three tables like this:

Prepared by: Elisaye B.@ WSU-DTC 18


 Functional dependencies:
emp_id -> emp_nationality
emp_dept -> {dept_type, dept_no_of_emp}
 Candidate keys:
For first table: emp_id
For second table: emp_dept Prepared by: Elisaye B.@ WSU-DTC 19
Fourth Normal Form (4NF)
For a table to satisfy the Fourth Normal Form, it should satisfy the
following two conditions:
1. It should be in the Boyce-Codd Normal Form.
2. And, the table should not have any Multi-valued Dependency.

What is Multi-valued Dependency?


A table is said to have multi-valued dependency, if the following
conditions are true,
3. For a dependency A → B, if for a single value of A, multiple value of
B exists, then the table may have multi-valued dependency.
4. Also, a table should have at-least 3 columns for it to have a multi-
valued dependency.
5. And, for a relation R(A,B,C), if there is a multi-valued dependency
between, A and B, then B and C should be independent of each other.
Prepared by: Elisaye B.@ WSU-DTC 20
If all these conditions are true for any relation(table), it is said to
STUDENT
table

 The given STUDENT table is in 3NF, but the COURSE and


HOBBY are two independent entity. Hence, there is no
relationship between COURSE and HOBBY.
 In the STUDENT relation, a student with STU_ID, 21
contains two courses, Computer and Math and two
hobbies, Dancing and Singing. So there is a Multi-valued
dependency on STU_ID, which leads to unnecessary
repetition of data.
 So to make the above table into 4NF, we can decompose it
Prepared by: Elisaye B.@ WSU-DTC 21
into two tables:
Prepared by: Elisaye B.@ WSU-DTC 22
Fifth normal form (5NF)
 A relation is in 5NF if it is in 4NF and not contains
any join dependency and joining should be lossless.
 5NF is satisfied when all the tables are broken into
as many tables as possible in order to avoid
redundancy.
 5NF is also known as Project-join normal form
(PJ/NF.

Prepared by: Elisaye B.@ WSU-DTC 23


 In the above table, John takes both Computer and
Math class for Semester 1 but he doesn't take Math
class for Semester 2. In this case, combination of all
these fields required to identify a valid data.
 Suppose we add a new Semester as Semester 3 but
do not know about the subject and who will be
taking that subject so we leave Lecturer and Subject
as NULL. But all three columns together acts as a
primary key, so we can't leave other two columns
blank.
 So to make the above table into 5NF, we can
decompose it into three relations P1, P2 & P3:
Prepared by: Elisaye B.@ WSU-DTC 24
Prepared by: Elisaye B.@ WSU-DTC 25

You might also like