Scribd
Upload
10 views

Chapter 3 Data Merise

Uploaded by

ndjobaprincesse8
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
10 views

Chapter 3 Data Merise

Uploaded by

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

CHAPTER 2 : DATABASE NORMALIZATION

NORMALIZATION is a database design technique that


organizes tables in a manner that reduces redundancy and
dependency of data. Normalization divides larger tables into
smaller tables and links them using relationships. The
purpose of Normalization is to eliminate redundant
(useless) data and ensure data is stored logically.

I- Functional Dependencies
We say an attribute, B, has a functional dependency on
another attribute, A, if for any two records, which have
the same value for A, then the values for B in these two
records must be the same. We illustrate this as:
A →B
Example: Suppose we keep track of employee email
addresses, and we only track one email address for each
employee. Suppose each employee is identified by their
unique employee number. We say there is a functional
dependency of email address on employee number:
employee number → email address

Exemple

If EmpNum is the PK then the FDs:


EmpNum → EmpEmail
EmpNum → EmpFname
EmpNum → EmpLname
must exist.
II- Transitive dependency

Consider attributes A, B, and C, and where


A →B and B → C.
Functional dependencies are transitive, which
means that we also have the functional dependency
A→C
We say that C is transitively dependent on A
through B.
Exemple
III- Partial Dependency

A partial Dependency exists when an attribute B is


functionally dependent on an attribute A, and A is a
component of a multipart candidate key.

Candidate keys: {InvNum, LineNum} InvDate is


partially dependent on {InvNum, LineNum} as
InvNum is a determinant of InvDate and InvNum is
part of a candidate key

IV- FIRST Normal FORM

We say a relation is in 1NF if all values stored in the


relation are single-valued and atomic.
1NF places restrictions on the structure of relations.
Values must be simple.

The following in not in 1NF

EmpDegrees is a multi-valued field:


employee 679 has two degrees: BSc and MSc
employee 333 has three degrees: BA, BSc, PhD

To obtain 1NF relations we must, without loss of


information, replace the above with two relations
An outer join between Employee and EmployeeDegree will
produce the information we saw before

Boyce-Codd Normal Form


Boyce-Codd Normal Form
BCNF is defined very simply:
a relation is in BCNF if it is in 1NF and if every
determinant is a candidate key.
If our database will be used for OLTP (on line transaction
processing), then BCNF is our target. Usually, we meet this
objective. However, we might denormalize (3NF, 2NF, or
1NF) for performance reasons.

V – SECOND Normal Form

A relation is in 2NF if it is in 1NF, and every non-key attribute


is fully dependent on each candidate key. (That is, we don’t
have any partial functional dependency.)
• 2NF (and 3NF) both involve the concepts of key and
non-key attributes.
• A key attribute is any attribute that is part of a key;
any attribute that is not a key attribute, is a non-key
attribute.
• Relations that are not in BCNF have data redundancies
• A relation in 2NF will not have any partial dependencies
Is the following relation in 2NF?
2NF, but not in 3NF

VI- Third Normal Form


A relation is in 3NF if the relation is in 1NF and all
determinants of non-key attributes are candidate keys
That is, for any functional dependency: X  Y, where Y is
a non-key attribute (or a set of non-key attributes), X is a
candidate key.
• This definition of 3NF differs from BCNF only in the
specification of non-key attributes - 3NF is weaker than
BCNF. (BCNF requires all determinants to be candidate
keys.)
• A relation in 3NF will not have any transitive dependencies
of non-key attribute on a candidate key through another
non-key attribute.
In 3NF, but not in BCNF:
EXEXCICE
You must create a data base for a bus company. The company manager gives you
the following indications: each bus is numbered. It realises ways made of a
departure, several stops and a terminus. Each bus can every day be allocated to
several ways and it can do many journeys on each way with eventually distinct
drivers. The management of customers is done separately (in another data base
not concerned for this project) but the management of buses (date of the next
revision, the mileage, number and name of the depot,…) and drivers (name,
surname, grade, seniority, salary, buses droved, ways done,…) is included in this
data base.

Problem
1 Specification
Let consider the case of realisation of the data base of the students of the national
higher school of applied statistics and economy (ENSEA) of Abidjan in Côte
d’Ivoire. In this data base, we are called to manage notably: (1) students
characterised each by a registration number, a name, a surname, the year of first
registration, the date of bird and the sex; (2) courses characterised each by au code,
a name, a level and the hourly quota; (3) marks of students, teachers characterised
each by a code, a name, a surname, a speciality, a grade and a sex; (4) the option
(Mathematic, Economy,…), the category (ISE, ITS,…), the level and the function
(delegate or not) of each student; The constraints are as follow. 1. The registration
code belongs to one and only one student. 2. The registration code is sufficient to
determine all other characteristics of the student. 3. The mark depends on the
student, the course and the year. 4. Each course has only one principal teacher. 5.
The same teacher can be principal teacher for many courses, independently to the
level of the course.
2 The expected result.
The data base should produce answers to the following preoccupations: Extract all
female students who have a mark greater than 12 in Information System in 2009.
Extract all the principal teachers for the course Data base since 2007. Extract and
order by level and by option all the delegates

You might also like