MODÉLISATION

RELATIONNELLE

à la fin de ce chapitre vous serez capables de…

utiliser une méthode pour structurer des

données comportant des relations entre elles
en évitant les redondances
 modèle de données
• un ensemble d’informations est associé à
chaque « objet »
• modèle de données (schéma de la base)
– définit la structure des données, leur organisation
générale pour le stockage dans la base
– évolue peu
• données :
– valeurs effectivement stockées
– peuvent changer fréquemment
 modèle de données 1 : hiérarchie
• informations organisées sous forme d’arbre
Données

prof
Tartempion
nom
Loria
laboratoire
1
Modèle de
n
données
cours base de données C++ réseau
titre septembre décembre avril
mois

adapté : aux nomenclatures

non adapté : et si 2 profs se partagent un cours ?
 modèle de données 2 : réseau
• informations organisées sous forme de graphe
« NoSQL »

interfaces de navigation
procédurales : on exprime
comment accéder à la donnée plutôt
que la donnée qu’on cherche →
programmes dépendants de la
structure des données

pas besoin de jointure →

passe à l’échelle

adaptable aux structures

changeantes
 modèle de données 3 : relationnel

Peter Chen
• informations organisées sous forme de tables, les
relations entre les tables sont elles-mêmes des tables
• la manipulation s’appuie sur des opérations d’algèbre
relationnelle (produit cartésien pour les associations)

Edgar « Ted » Codd

prof cours
nom enseigne titre
labo mois

table des professeurs table des services table des cours

nom labo prof cours titre mois
Truc Loria Truc réseau avancé développement octobre
Machin LMOPS Truc réseau 1 architecture décembre
Machin architecture réseau 1 janvier
réseau avancé mai
 les métiers de la BD
• concepteur : crée la
structure
• développeur
d’applications : utilise (et
modifie) les données
• administrateur : démarre le
serveur, le configure pour
qu’il soit performant, gère
les sauvegardes et les
reprises sur panne, accorde
ou révoque les droits
d’accès…
 BD design

informal description of the reality and needs

1. entity/relationship model
2. transformation to relational model
3. normalization

coherent set of tables

 why not a single table?

• example:
Library(Title, Author, ISBN, Name, Address, Date)

• proposed mode of operation:

– adding a line to each loan
– deleting line at each return
• service accomplished:
can know at any time the list of ongoing loans
 why not a single table?
because...
• no library catalog
management (only borrowed
books exist!)
• no clients management (only
clients with loans exist!)
• a book can have multiple
authors... What to do?
• duplication of data, eg address
of a person borrowing multiple
books
• no borrowing history
• ...
data semantic very poorly represented!
→ must define several tables / relationships
 design methodology
by entity-relationship diagram

observation and collection of information

data analysis and modeling

(common sense, experience...)

entity-relationship diagram

systematic process

relational schema (DB tables)

 definitions
• entity: concrete or abstract object, derived
from real world observation, has a name
• attribute: property of an entity, has a name
and a domain of values ​(type++)
• key/ID: minimum set of attributes whose
values ​uniquely identify each instance of an
entity Person entity

Name: String
FirstName: String
Address: String
attributes SSNb: int key
BirthDate: int
 definitions
• occurrence: instantiation of an entity

Person

Name: "Dupont" occurrence

FirstName: "John"
Address: "3 Madison st"
SSNb: 1784
BirthDate: 19071980
 definitions
• association: relationship between several
entities (links 1 to n entities, and at least 2
occurrences), has a name and can have
attributes

association of two entities

Person
Car
name

BelongsTo Name: String

Reg: String
FirstName: String
Type: String PurchaseDate:
int Address: String
Brand: String
Age: int
Color: int
attribute Gender: int
 recursive association
Person

Name: String
isManagedBy
FirstName: String
Address: String
Age: int

recursive association involves different

occurrences:
Person Person

Dupont isManagedBy Durand

Alex Paul
Paris Lyon
27 30
 cardinality of an association
• number of times (min and max) an instance of
the entity can be engaged in the association
• minimum cardinality:
– 0: can not be engaged
– 1: must be engaged at least once
• maximum cardinality:
– 1: can not be engaged more than once
– n: can be engaged more than once

min … max min … max

 examples (1/4)

Person
Car

Name: String
Reg: String 1 .. 1 BelongsTo 0 .. n
FirstName: String
Type: String PurchaseDate: int Address: String
Brand: String
Age: int
Color: int
Gender:int

Caution! In UML the cardinalities are indicated on the opposite side of the relation:
Person
Car
Owner
Name: String
Reg: String
FirstName: String
Type: String OwnedCars Address: String
Brand: String
Age: int
Color: int 0 .. n Gender:int
 examples (2/4)
3 entities connected by 2 associations

Borrower
Book

Name: String
? Borrows ?
FirstName : String
BorrowingDate: int Title : String
ISBN :String
Address :String
?

isWrittenBy

?
Author

Name: String
FirstName: String
 examples (2/4)
3 entities connected by 2 associations

Borrower
Book

Name: String
0 .. n Borrows 0 .. 1
FirstName : String
BorrowingDate: int Title : String
ISBN :String
Address :String
1 .. n

isWrittenBy

1 .. n
Author

Name: String
FirstName: String
 examples (3/4)

2 entities connected by 2 different associations

Car 1 .. n isUsedBy
0 .. n Person

Reg: int Name: String

Type: String FistName: String
Brand: String 1 .. 1 BelongsTo
0 .. n Address: String
Color: int PurchaseDate: int
 examples (4/4)

associations of more than 2 entities

Accident

Number: int
Date : int
Description: String

1 .. 1
Bing

0 .. n
Car 1 .. n isUsedBy
0 .. n Person

Reg: int Name: String

Type: String FistName: String
Brand: String 1 .. 1 BelongsTo
0 .. n Address: String
Color: int PurchaseDate: int
 tips
• identify natural entities:
subjects and complements in sentences
"A movie... "," An actor... "
• identify associations between these entities:
verbs (which do not express direct dependencies)
A movie is directed by one or more directors.
• identify the attributes and identifiers:
verbs describing direct dependencies
A movie is defined by... identified by... has one...
 tips
• identify cardinalities and roles
– look out for singular or plural, “may”, “must”...
– analyze whether “has a” means “one and only one” or
“0 or 1”...
• enumerate integrity constraints
"A car is used at a given time by one and only one
person"
• common sense rules:
– use meaningful names
– avoid redundancy
– aim for simplicity (for readability)
 tips
use ternary associations with caution
as they are more difficult to understand:
cardinalities may seem ambiguous

Schedule

0 .. n id: int
StartTime: Time
MovieTheater EndTime: Time

id: int
Name: String 0 .. n Offers

Capacity: int Rate

3D: boolean
Movie

id: int
0 .. n Title: String
Year: Date
 tips
transform ternary association into binary association
1. replace the association by a new entity
2. create associations between entities,
cardinality of new entity always being 1
Schedule
0 .. n
id: int
startAt StartTime: Time
EndTime: Time
MovieTheater 1 ..1

id: int 1 ..1 Show

Name: String takePlaceAt

id: int
Capacity: int
price: int
3D: boolean 0 .. n
1 ..1 isPlaying
Movie

0 .. n id: int
Title: String
Year: Date
 description of “the case”

• Hospital doctors, who have their specialties, examine patients

who have made an appointment on the recommendation of
their GP.
• On this occasion, doctors perform an examination of the
patient (visual examination, palpation, blood pressure
measurement... etc.) which can lead to a diagnosis.
• Sometimes they prescribe additional tests (blood tests, x-
rays... etc.).
• To confirm the diagnosis, they can refer the patient to another
hospital doctor.
• At the end of the appointment, the doctor may write a
prescription.

Exercise by Bernard Morand

 identification of natural entities
• Hospital doctors, who have their specialties, examine patients
who have made an appointment on the recommendation of
their GP.
• On this occasion, doctors perform an examination of the
patient (visual examination, palpation, blood pressure
measurement... etc.) which can lead to a diagnosis.
• Sometimes they prescribe additional tests (blood tests, x-
rays... etc.).
• To confirm the diagnosis, they can refer the patient to another
hospital doctor.
• At the end of the appointment, the doctor may write a
prescription for drugs.
 identification of associations
• Hospital doctors, who have their specialties, examine patients
who have made an appointment on the recommendation of
their GP.
• On this occasion, doctors perform an examination of the
patient (visual examination, palpation, blood pressure
measurement... etc.) which can lead to a diagnosis.
• Sometimes they prescribe additional tests (blood tests, x-
rays... etc.).
• To confirm the diagnosis, they can refer the patient to another
hospital doctor.
• At the end of the appointment, the doctor may write a
prescription for drugs.
 identification of cardinalities
• Hospital doctors, who have their specialties, examine patients
who have made an appointment on the recommendation of
their GP.
• On this occasion, doctors perform an examination of the
patient (visual examination, palpation, blood pressure
measurement... etc.) which can lead to a diagnosis.
• Sometimes they prescribe additional tests (blood tests, x-
rays... etc.).
• To confirm the diagnosis, they can refer the patient to another
hospital doctor.
• At the end of the appointment, the doctor may write a
prescription for drugs.
 modeling an appointment
Doctor
Appointment Patient
id: int
SSnb: int
Name: String Date
Name: String
Specialties: String
Age: int

Additional Test
code: int
description: String

Rule: if there is an instance of an association, then an instance of each

associated entities must necessarily exists
Problem: It’s possible that no additional tests are prescribed during the
appointment
(and a 0 multiplicity on Test would mean that there could be an instance of
Test not involved in an Appointment: not what we want to express)
 modeling an appointment
Doctor
Appointment Patient
id: int
SSnb: int
Name: String Date
Name: String
Specialties: String
Age: int
isPerformed

Examination
code: int
description: String

Problem:
an association binds (preferably) entities, not
associations
 modeling an appointment
Doctor
Patient
id: int
0..n SSnb: int
Name: String 0..n
Name: String
Specialties: String
conduct undergo Age: int

1..1 1..1
Consult
id: int
date: Date

0..n 1..n
isPrescribed isPerformed

Additional Test Examination

code: int
0..n 0..n code: int
description: String description: String
 and the diagnosis?
On nous a indiqué que diagnostic est une sorte de résultat auquel "la consultation peut conduire".
On peut en proposer 2 interprétations assez différentes de cette vague indication :
• Il s'agit d'une maladie clairement identifiée, répertoriée et indépendante de la consultation. En tant qu'information
récurrente, partagée par différentes consultations, patients et médecins, nous allons la représenter par une entité.
Conséquences : il nous faut un identifiant ("Code maladie") et nous pouvons la décrire plus amplement à l'aide de
propriétés telles que ses symptômes, le(s) protocole(s) de soins qui lui sont habituellement associés, etc.
• Il s'agit d'un simple compte-rendu d'observation, effectué par le médecin lors de cette consultation-ci, du genre "nette
amélioration de l'état du patient" ou encore "le traitement qui a été préconisé lors de la visite précédente semble de peu
d'effet", etc. Il s'agit alors d'une simple propriété de la consultation dont la valeur sera une chaîne de caractères plus ou
moins longue et documentée.

Comment choisir ?
Cela ne dépend pas de nous (concepteurs) mais des besoins de l'application (i.e. des utilisateurs).
• Dans le 1er cas, la "réification" de la notion de maladie va orienter l'application vers des fonctionnalités essentiellement
médicales : on pourra comparer plusieurs patients atteints de la même maladie, les protocoles de soins que l'on a utilisés,
leur efficacité, etc. Bref faire quelque chose qui ressemble à de l'aide à la recherche médicale. On se dirige alors vers une
application lourde (une base de données de toutes les maladies connues de la planète, des protocoles de soins connus ou
à expérimenter), une application qui participe à l'amélioration de la santé de tous.
• Dans le 2ème cas, l'application va se contenter d'offrir des fonctionnalités purement administratives : permettre de
consultation en consultation de retrouver aisément sur un écran ce qui avait été précédemment noté. On se dirige cette
fois vers une application légère, utile au quotidien, mais inexploitable sur le plan de la recherche médicale. En effet il est
très difficile d'extraire à partir de commentaires de circonstance et rédigés en langue naturelle des informations d'ordre
général (et en tout cas, pas de manière automatisée) : il existe actuellement dans les hôpitaux du monde entier des
mines d'informations dans des fichiers manuels que l'on ne sait guère exploiter.

Le modèle n'est donc pas neutre !

Pour la suite nous retenons la seconde conception du diagnostic, de manière purement arbitraire donc (nous aurions
d'ailleurs pu prendre la même décision pour les actes et les examens).
 and the diagnosis?
Doctor
Patient
id: int
0..n SSnb: int
Name: String 0..n
Name: String
Specialties: String
conduct undergo Age: int

1..1 1..1
Consult
id: int
date: Date
diagnosis: String
0..n 1..n
isPrescribed isPerformed

Additional Test Examination

code: int
0..n 0..n code: int
description: String description: String
 and the colleague referral?
Doctor 0..n addressTo Patient
id: int
0..n SSnb: int
Name: String 0..n
0..n Name: String
Specialties: String
conduct undergo Age: int

1..1 1..1
Consult
id: int
date: Date
diagnosis: String
0..n 1..n
isPrescribed isPerformed

Additional Test Examination

code: int
0..n 0..n code: int
description: String description: String
 and my medication?
Doctor 0..n addressTo Patient
id: int
0..n SSnb: int
Name: String 0..n
0..n Name: String
Specialties: String
conduct undergo Age: int

1..1 1..1
0..n Consult
isPrescribed
Drug id: int
name: String date: Date
0..n
diagnosis: String
0..n 1..n
isPrescribed isPerformed

Additional Test Examination

code: int
0..n 0..n code: int
description: String description: String
 what about the dosage?
Doctor 0..n addressTo Patient
id: int
0..n SSnb: int
Name: String 0..n
0..n Name: String
Specialties: String
conduct undergo Age: int

1..1 1..1
0..n Consult
isPrescribed
Drug id: int
quantity
name: String date: Date
0..n
diagnosis: String
0..n 1..n
isPrescribed isPerformed

Additional Test Examination

code: int
0..n 0..n code: int
description: String description: String
 what about the GP?
Doctor 0..n addressTo Patient
id: int
0..n SSnb: int
Name: String 0..n
0..n Name: String
Specialties: String
conduct undergo Age: int
GPName: String
GPPhoneNb:
1..1 1..1 String
0..n Consult
isPrescribed
Drug id: int
quantity
name: String date: Date
0..n
diagnosis: String
0..n 1..n
isPrescribed isPerformed

Additional Test Examination

code: int
0..n 0..n code: int
description: String description: String
 design methodology
by entity-relationship diagram

observation and collection of information

data analysis and modeling

(common sense, experience...)

entity-relationship diagram

systematic process

relational schema (DB tables)

 systematic process
from E/R model to relational schema
• create a table per entity
– attributes of entity → attributes of table
– if id consists of too many attributes (more than
one?) or too large attribute (eg. long string) → add
a numeric attribute as primary key to speed up
join operations
• create a table per association
– attributes = id of each entity + attributes of the
association
 Accident

example Number: int

Date : int
Description: String

1 .. 1
Bing

0 .. n
Car 1 .. n isUsedBy
0 .. n Person

Reg: int Name: String

Type: String FistName: String
Brand: String 1 .. 1 BelongsTo
0 .. n Address: String
Color: int PurchaseDate: int

Accident (Number, Date, Description)

Car (Reg, Type, Brand, Color)
Person (Id, Name, FirstName, Address)
Bing (Bing_Id, Number, Reg, pid)
isUsedBy (Reg, pid)
BelongsTo (Reg, pid, PurchaseDate)
disadvantage of systematic process
• results in large number of tables → many joins
(very expensive operations) for queries:
Mailing car owners who had a broken windshield:
1) R1 = Description=Windshield (Accident)
2) R2 = Number(R1)
3) R3 = R2 ⋈ Bing (Number=Number)
4) R4 = Reg(R3)
5) R5 = R4 ⋈ BelongsTo (Reg=Reg)
4 projections
6) R6 = Name,FirstName(R5)
1 restriction
7) R7 = R6 ⋈ Person (Name=Name and FirstName=FirstName)
3 joins
8) RESULT = Name,FirstName,Address (R7)

• → alternative transformations
 case E1 0..1 - 0..1 E2
add to one entity (E1 or E2) the identifier of the other
and the attributes of the association
If a teacher can supervise at most one thesis at a time:

Professor PhDStudent

Name 0 .. 1 advises 0 .. 1 StudId

FirstName StartDate Name
ReseachTopic FirstName
Laboratory Funding

Professor PhDStudent
possible issue:
Name StudId how to
FirstName Name represent a
ResearchTopic FirstName teacher who is
Laboratory Funding not advising a
StudId PhD student?
StartDate
 case E1 0..1 - 1..1 E2
add to E2 the identifier of E1 and the attributes of the
association

Professor PhDStudent

Name 0 .. 1 advises 1 .. 1 StudId

FirstName StartDate Name
ResearchTopic FirstName
Laboratory Funding

Professor PhDStudent
StudentId
Name Name
FirstName FirstName
ResearchTopic Funding
Laboratory advisorName
advisorFirstName
advisorReasechTopic
StartDate
 case E1 1..1 - 1..1 E2
add to one entity (E1 or E2) the identifier of the other
entity and the attributes of the association
Opportunity to do reduce to one single relation
If every teacher teaches a lesson and one only:

Course
Professor
1 .. 1 teach 1 .. 1
Title
Name room Duration
FirstName
Level

Professor Course Professor Course

OR
Name Title Name Title
FirstName Field FirstName Duration
courseTitle Level courseTitle Level
If the entity
room courseDuration is not engaged
courseLevel in another
room association
 case E1 x..1 - y..n E2
add to E1 the identifier of E2 and the attributes of the
association
If a teacher can respond to at most 1 call for project:

CallForPproposals
Professor
0 .. 1 propose 0 .. n Reference
Name
ResponseDate Field
FirstName
Duration
ResearchTopic
Funding

Professor CallForProposals
possible issue:
Name Reference how to
First name Field represent a
ResearchTopic Duration teacher who do
Reference Funding not make a
ResponseDate proposal?
 case E1 x..n - y..n E2
association gives a new relation

Article
Professor
0 .. n Publish 1 .. n Title
Name
ContractId Conference
First name
NbOfPages
ResearchTopic
Date

Professor Article Publish

Name Title Name

FirstName Conference FirstName
ResearchTopic NbOfPages Title
Date Conference
ContractId
 case E1 “is a” E2
• examples: Professor “is a” Person, Student “is
a” Person
• In this case the Professor and Student entities
do not have a key in the entity-relationship
model, they inherit the key from Person
add the identifier of E2 to E1
 limitations of the E/R model
• relational model does not take into account:
– structured objects with associated operations
→ object-oriented DB
– unstructured objects such as text, sounds, images, ...
→ multimedia DB
– AI techniques inferring new data
→ deductive DB
• The entity-relationship model is simple but:
– formalization is sometimes difficult
– same set of data can be modeled in different ways
• The systematic E/R model to relational model process:
doesn’t result in “optimal” relations, and DB update operations can be
unnecessarily complex
 E/A Model
Doctor 0..n addressTo Patient
id: int
0..n SSnb: int
Name: String 0..n
0..n Name: String
Specialties: String
conduct undergo Age: int
GPName: String
GPPhoneNb:
1..1 1..1 String
0..n Consult
isPrescribed
Drug id: int
quantity
name: String date: Date
0..n
diagnosis: String
0..n 1..n
isPrescribed isPerformed

Additional Test Examination

code: int
0..n 0..n code: int
description: String description: String
 from E/A to relations
first step: from entities to relations:
Doctor(Id, Name, Specialties)
Patient(SSnb, Name, Age, GPName,
GPPhoneNb)
Consult(id, Date, diagnosis)
Examination(code, description)
Test(code, description)
Drug(name)
 from E/A to relations
step 2: taking into account associations

Doctor 0..n conducts 1..1 Consult

→ case: E1 1..x - y..n E2
Consult(id, Date, diagnosis, DocId)

Patient 1..1 chooses 0..n GP

→ case: E1 x..1 - y..n E2
Patient(SSnb, Name, Age, GPName, GPPhoneNb)

Patient 0..1 undergoes 1..n Consult

→ case: E1 x..1 - y..n E2
Consult(id, Date, diagnosis, DocId, patientSSnb)

Consult 0..n addresses to 0..n Doctor

→ case: E1 x..n - y..n E2
Referral(DocId, consultId)
Consult 0..n prescribes 0..N Test
→ Cases: E1 x..n - y..n E2
TestPrescription (consultId, testCode)

Examination 0..n is performed 1..n Consult

→ Cases: E1 x..n - y..n E2
Action(consultId,examCode)

Consult 0..n prescribes 0..N Drug

→ Cases: E1 x..n - y..n E2
DrugPrescription (consultId, drugName, quantity)
 relations
Doctor(Id, Name, Specialties)
Patient(SSnb, Name, Age, GPName, GPPhoneNb)
Examination(code, description)
Test(code, description)
Drug(name)
Consult(id, Date, diagnosis, DocId, patientSSnb)
Referral(DocId, consultId)
TestPrescription (consultId, testCode)
Action(consultId,examCode)
DrugPrescription (consultId, drugName, quantity)
Normalization
 Another design methodology,
based on the theory of relations
start from a single huge table and cut it into
smaller ones to avoid redundancies while
preserving functional dependencies
Produit cartésien et jointures naturelles
Personne Personne X Adhérent
Nom Adresse Nom Adresse Nom Club
Alice Rue du lac, Metz Alice Rue du lac, Metz Alice Chant
Bob Rue haute, Cuvry Alice Rue du lac, Metz Bob Sport
Alice Rue du lac, Metz Bob Cuisine
Adhérent
Bob Rue haute, Cuvry Alice Chant
Nom Club
Bob Rue haute, Cuvry Bob Sport
Alice Chant
Bob Rue haute, Cuvry Bob Cuisine
Bob Sport
Bob Cuisine
Jointure sur Nom
Club
Nom Adresse Nom Club
Nom Devise
Alice Rue du lac, Metz Alice Chant
Chant Do-ré-mi
Bob Rue haute, Cuvry Bob Sport
Sport De l’avant
Bob Rue haute, Cuvry Bob Cuisine
Cuisine Miam !
 example of ill-advised decomposition
Car Registration Color Model Brand
AL AB 123 Blue S3 Audi
Vehicle Registration Model decomposition OR 542 CD Black Sax Citroën
AL AB 123 S3 EF 871 AA Yellow S3 Audi
OR 542 CD Sax GH 22 AK White C3 Citroën
EF 871 AA S3
GH 22 AK C3

Maker Model Brand Color

S3 Audi Blue
Sax Citroën Black Registration Color Model Brand
S3 Audi Yellow AL AB 123 Blue S3 Audi
C3 Citroën White AL AB 123 Yellow S3 Audi
OR 542 CD Black Sax Citroën
EF 871 AA Blue S3 Audi
Vehicle ⋈Manufacturer EF 871 AA Yellow S3 Audi
(natural join: model=model) GH 22 AK White C3 Citroën

not the same table!

 1st normal form (1NF)
A relation is in 1NF if and only if every attribute
• contains an atomic value
• doesn’t need to be regularly updated
 functional dependencies
• Definition:
Let R(A1, A2, ..., An) a relation schema,
X and Y subsets of {A1, A2, ... An}.
“X determines Y” or “Y functionally depends on X”
if the same values ​of X imply identical values ​of Y.
• notation: X → Y
• example: Car(Reg, Color, Type, Brand)
– Reg → Color
– Reg → Type
– Reg → Brand
– Type → Brand
elementary functional dependency
is a functional dependency X → Y where:
• Y is a single attribute and does not belong to X
• there is no X‘ included in X such that X’ →Y
 formal definition of key
• Let R (A1, ..., An) a relation schema
and X a subset of (A1, ..., An),
X is a key if, and only if:
– X → (A1, A2, ..., An)
– X is minimal: there is no subset Y of X such that Y → (A1,
A2, ..., An)
• example: {Reg} is a key but not {Reg, Brand}
• if several keys → primary key and candidate keys
• every relation has a key (possibly composed of all
attributes of the relation)
 2NF
• A relation is in 2NF if and only if:
– it is in first normal form
– and any attribute not belonging to a key does not
depend on a part of the key
→ "the whole key is useful all the time"
• Note: Any relation where the key is reduced to
one attribute is in 2NF
 example 2NF
majName year nbStudents campus functional dependencies::
SIR 2010 22 Metz
majName → campus
SIR 2011 19 Metz
majName, year →nbStudents
ISA 2009 15 Rennes
SPC 2011 9 Metz
ISA 2011 12 Rennes

campus does not belong to the key and depends only on majName → not in 2NF
solution:

majName year nbStudents majName campus

SIR 2010 22 SIR Metz
SIR 2011 19 ISA Rennes
ISA 2009 15 SPC Metz
SPC 2011 9
ISA 2011 12
 3NF
• A relation is in 3NF if and only if:
– it is in second normal form
– and any attribute not belonging to a key does not
depend on a non-key attribute
→ "the whole key and nothing but the key"
• notes:
– no dependencies between non-key attributes
– if multiple keys, check the property for all keys
 example 3NF
courseTitle track teachId teachName
functional dependencies:
InfSys Metz 007 Mercier
InfSys Gif 2 123 Jouga courseTitle, track →teachId
InfSys Gif 1 442 Galtier courseTitle, track →teachName
teachId →teachName
InfSys Rennes 123 Jouga

techName does not belong to the key and depends on teachId which does not belong to
the key neither→ not in 3NF
solution:

courseTitle track teachId teachId teachName

InfSys Metz 007 007 Mercier
InfSys Gif 2 123 123 Jouga
InfSys Gif 1 442 442 Galtier
InfSys Rennes 123
 decomposition without loss of
information
• Definition:
a decomposition of a relation R in a set of relations R1 .. Rn
is without loss of information
if the natural join of R1 .. Rn gives R
• theorem: any relation that is not in 3NF admits
a decomposition without loss of information in
a set of relations in 3NF
• there is an algorithm to obtain a set of relations
in 3NF
 Boyce-Codd NF (BCNF)
A relationship is BCNF if, and only if:
• it is 3NF,
• the only elementary functional dependencies
are those in which a key determines an
attribute

address
addr1 (Zipcode, City)
(City,Street,Number,Zipcode)
• City, Street, Number → Zipcode addr2 (Zipcode,Street,Number)
• Zipcode → City
there are other NF

1NF

2NC

3NF

BCNF

4NF

5NF

DKNF

6NF
 normalization: conclusion
gradually evolve from few large tables to many
small tables
• consistency
• but require more joins

3NF or BCNF usually constitute a good

compromise
 relations
Doctor(Id, Name, Specialties)
Patient(SSnb, Name, Age, GPName, GPPhoneNb)
Examination(code, description)
Test(code, description)
Drug(name)
Consult(id, Date, diagnosis, DocId, patientSSnb)
Referral(DocId, consultId)
TestPrescription (consultId, testCode)
Action(consultId,examCode)
DrugPrescription (consultId, drugName, quantity)
 1NF normalization
A relation is in 1NF if and only if every attribute
• contains an atomic value
Doctor(Id, Name, Specialties) →
Doctor(Id, Name)
Specialty(Name)
Specialist(DocId, SpecialtyName)
• is constant over time
Patient(SSnb, Name, Age, GPName, GPPhoneNb) →
Patient(SSnb, Name, BirthYear, GPName,
GPPhoneNb)
 2NF normalization
A relation is in 2NF if and only if:
• it is in first normal form
• and any attribute not belonging to a key does not depend on a part
of the key (Note: Any relation where the key is reduced to one
attribute is in 2NF)

Patient(SSnb, Name, BirthYear, GPName, GPPhoneNb)

 2NF as the key is composed of a single attribute

DrugPrescription (consultId, drugName, quantity)

 2NF as quantity does not depend on consultId only or drugName
only but on both (Doctor may adjust dosage from one consult to the
next)
 3NF normalization
A relation is in 3NF if and only if:
• it is in second normal form
• and any attribute not belonging to a key does not
depend on a non-key attribute

Patient(SSnb, Name, BirthYear, GPName,

GPPhoneNb)
not in 3NF because GPName → GPPhoneNb
Patient(SSnb, Name, BirthYear, GPName)
GP (Name, phoneNb)