Conception de bases de

données normalisées
(décomposition en 3NF)

[Link]/bdd
[Link]

Stéphane Crozat

Paternité - Partage des Conditions Initiales à l'Identique : [Link] 29 janvier 2018

/licenses/by-sa/4.0/fr/
 Table des
matières
I - Cours 3

1. Conception de bases de données normalisées ................................................................................................. 3

1.1. Exercice : Étapes de la conception d'une base de données ............................................................................................................. 3
1.2. Algorithme de décomposition 0NF->1NF ..................................................................................................................................... 3
1.3. Exemple de décomposition 0NF->1NF (attribut multivalué) ......................................................................................................... 4
1.4. Algorithme de décomposition 1NF->3NF ..................................................................................................................................... 4
1.5. Exemple de décomposition 1NF->3NF ......................................................................................................................................... 5
1.6. Normalisation par transformation d'attributs en méthodes ........................................................................................................... 6
1.7. Synthèse : Processus de conception d'une base de données normalisée .......................................................................................... 7

2. Exemple de synthèse : MCD-Relationnel-Normalisation-SQL ...................................................................... 8

2.1. Première étape : Modélisation conceptuelle .................................................................................................................................. 8
2.2. Deuxième étape : Modèle relationnel .......................................................................................................................................... 11
2.3. Troisième étape : Dépendances fonctionnelles ............................................................................................................................ 11
2.4. Quatrième étape : Formes normales ........................................................................................................................................... 11
2.5. Cinquième étape : Décomposition ............................................................................................................................................... 12
2.6. Sixième étape : Implémentation SQL LDD .................................................................................................................................. 12

II - Exercices 14

1. Exercice : Project manager ........................................................................................................................... 14

2. Exercice : Objectifs II .................................................................................................................................. 14

3. Exercice : Jeu de construction ....................................................................................................................... 15

4. Exercice : À l'école ....................................................................................................................................... 16

III - Devoir 18

1. Exercice : Gestion d'incidents ....................................................................................................................... 18

Questions de synthèse 20

Solutions des exercices 21

Abréviations 26
 Cours

Cours
I
1. Conception de bases de données normalisées
Objectifs
Savoir créer des schémas relationnels en troisième forme normale.

1.1. Exercice : Étapes de la conception d'une base de données [solution n°1 p.21]
[*]

Mettre dans l'ordre les étapes de conception suivantes.

Décomposition des relations jusqu'à arriver en 3NF en préservant les DF

Énonciation de la forme normale avant normalisation

Établissement des DF sous la forme de la fermeture transitive pour chaque relation du modèle

Élaboration du modèle logique en relationnel ou relationnel-objet

Création du code SQL LDD pour un SGBDR ou un SGBDRO

Modélisation conceptuelle en UML ou E-A

Analyse de la situation existante et des besoins

Rétro-conception d'un modèle UML normalisé

1.2. Algorithme de décomposition 0NF->1NF

Méthode : Attributs composés

Soit R une relation. Si R contient un attribut non atomique portant sur des valeurs hétérogènes (correspondant à
un attribut composé au niveau conceptuel), alors l'attribut est décomposé en plusieurs attributs a 1...an.

R(#pk,a,b,...) avec a non atomique se décompose en : R(#pk,a1,a2,...,an,b,...)

3
 Exemple de décomposition 0NF->1NF (attribut multivalué)

Méthode : Attributs multivalués

Soit R une relation avec la clé primaire pk. Si R contient un attribut non atomique portant sur des valeurs
homogènes (correspondant à un attribut multivalué au niveau conceptuel), alors R est décomposée en R1 et R2,
tel que :

- R1 est R moins l'attribut a

- R2 est composé de pk et de a, avec (pk,a) clé primaire de R2 et [Link] clé étrangère vers [Link]

R(#pk,a,b,...) avec a non atomique se décompose en :

- R1(#pk,b,...)
- R2(#pk=>R1,#a)

1.3. Exemple de décomposition 0NF->1NF (attribut multivalué)

Exemple : Situation initiale

1 Élève(#login, nom, prénom, uvs)

Exemple d'enregistrement :

1 ('tpassoir', 'Passoire', 'Toto', ('SY02','NF26','NF17'))

Méthode
L'attribut uvs est multivalué (donc non atomique). On va donc créer deux relations, la première sans l'attribut
uvs, et la seconde qui va contenir autant d'enregistrements que de valeur par enregistrement dans
l'enregistrement initial.

Exemple : Situation finale

1 Élève(#login, nom, prénom)

2 UVÉlève(#login=>Élève, #uv)

En reprenant le même exemple, on va avoir l'enregistrement suivant dans Élève :

1 ('tpassoir', 'Passoire', 'Toto')

et les enregistrements suivants dans UVÉlève :

1 ('tpassoir', 'SY02')
2 ('tpassoir', 'NF26')
3 ('tpassoir', 'NF17')

1.4. Algorithme de décomposition 1NF->3NF

Fondamental : Décomposition > 1NF

Pour les NF supérieures à 1, afin de normaliser une relation R on réalise une décomposition en R1 et R2 pour
chaque DFE responsable d'un défaut de normalisation tel que :

- la partie gauche de la DFE :

1. devient la clé primaire de R2

2. devient une clé étrangère de R1 vers R2

4
 Exemple de décomposition 1NF->3NF

- la partie droite de la DFE

1. est enlevée de R1
2. est ajoutée comme attributs simples de R2

Méthode : Décomposition 1NF->2NF

Soit R une relation comportant une clé composée de k1 et k1'. Si R contient une DFE de k1' vers des attributs
n'appartenant pas à la clé, alors R est décomposée en R1 et R2, tel que :

- R1 est R moins les attributs déterminés par k1' et avec k1' clé étrangère vers R2
- R2 est composée de k1' et des attributs qu'elle détermine, avec k1' clé primaire de R2

R(#pk,k1,k1',a,b,c,...) avec (k1,K1') clé et k1'→a,b se décompose en :

- R1(#pk,k1,k1'=>R2,c,...)
- R2(#k1',a,b)

Méthode : Décomposition 2NF->3NF

Soit R une relation comportant une DFE de a vers b qui n'appartiennent pas à une clé, alors R est décomposée
en R1 et R2, tel que :

- R1 est R moins les attributs déterminés par a et avec a clé étrangère vers R2
- R2 est composée de a et des attributs qu'elle détermine, avec a clé primaire de R2

R(#pk,a,b,c,...) avec a→b se décompose en

- R1(#pk,a=>R2,c,...)
- R2(#a,b)

1.5. Exemple de décomposition 1NF->3NF

Exemple : Situation initiale

1 Resultat (#pknum,knumetu,kuv,prenom,nom,credits,resultat,obtenu) avec (knumetu,

kuv) clé
DF :

- pknum → knumetu,kuv,prenom,nom,credits,resultat,obtenu
- knumetu,kuv → pknum,prenom,nom,credits,resultat,obtenu
- knumetu → prenom,nom
- kuv → credits
- resultat → obtenu

La relation est en 1NF.

pknum knumetu kuv prenom nom credits resultat obtenu

1 X01 NF17 Pierre Alpha 6 A oui

2 X01 NF26 Pierre Alpha 6 B oui

3 X02 NF17 Alphonse Béta 6 F non

5
 Normalisation par transformation d'attributs en méthodes

Exemple d'instance

knumetu → prenom,nom

1 Resultat (#pknum,knumetu=>Etudiant,kuv,credits,resultat,obtenu)
2 Etudiant (#knumetu,prenom,nom)

kuv → credits

1 Resultat (#pknum,knumetu=>Etudiant,kuv=>Uv,resultat,obtenu)
2 Etudiant (#knumetu,prenom,nom)
3 Uv(#kuv,credits)

resultat → obtenu

1 Resultat (#pknum,knumetu=>Etudiant,kuv=>Uv,resultat=>Note)
2 Etudiant (#knumetu,prenom,nom)
3 Uv(#kuv,credits)
4 Note(#resultat,obtenu)

1.6. Normalisation par transformation d'attributs en méthodes

Il arrive que la fonction sous-jacente à la DF soit une fonction simple, que l'on peut calculer. Par exemple pour
la DF : ddn age ( ddn*), on peut calculer age en fonction de ddn par le calcul : age = today() - ddn.

Méthode
Chaque fois que c'est possible, on remplacera un attribut par une méthode si cela permet de supprimer une DF
sans perdre d'information.

Cette solution est à privilégier a priori sur une décomposition.

En relationnel, on supprimera l'attribut de la table et on ajoutera une vue permettant de le retrouver.

Exemple : Existence d'une fonction de calcul simple

Soit la relation en 2NF :

1 personne (#numsecu, nom, prenom, ddn, age) avec ddn → age

On remplacera cette relation par une relation en 3NF et une vue :

1 Personne (#numsecu, nom, prenom, ddn)

2 vPersonne (#numsecu, nom, prenom, ddn, age) avec age = today() - ddn

Exemple : Cas de transformation d'un héritage exclusif par la classe mère

Soit le schéma UML suivant :

6
 Synthèse : Processus de conception d'une base de données normalisée

Une transformation de l'héritage par la classe mère donnera :

1 Salle (#nom:string, surface:string, nbplaces:int, type:{Réunion|Bureau})

2 DF : nom → surface, type, nbplaces et nbplaces → type

On peut donc supprimer l'attribut type et aboutir à la relation en 3NF :

1 Salle (#nom:string, surface:string, nbplaces:int)

2 vSalle (nom, surface, nbplaces, type) avec SI nbplace IS NULL ALORS type=Bureau
SINON type=Réunion

1.7. Synthèse : Processus de conception d'une base de données normalisée

1. Analyse et clarification du problème posé
2. Modélisation conceptuelle en UML
Résultat : MCD1
3. Traduction en relationnel en utilisant les règles de passage UML vers relationnel
Résultat : MLD1
4. Établissement des DF sous la forme de la fermeture transitive pour chaque relation du modèle
Résultat : MLD1 avec F+
5. Établissement de la forme normale
Résultat : MLD1 avec F+ et NF
6. Décomposition des relations jusqu'à arriver en 3NF en préservant les DF
Résultat : MLD2 avec F+ et 3NF
7. Rétro-conception du modèle UML correspondant
Résultat : MCD2
8. Implémentation en SQL du modèle MLD2

  

*  *

La normalisation permet de décomposer un schéma relationnel afin d'obtenir des relations non redondantes.

La 3NF* est souhaitable car toujours possible à obtenir, sans perte d'information et sans perte de DF*. La BCNF* est
également indiquée, car elle est un peu plus puissante, et plutôt plus simple que la 3NF.

La BCNF* n'est pas encore suffisante pour éliminer toutes les redondances. Il existe pour cela les 4NF* et 5NF* qui
ne sont pas abordées dans ce cours. Notons également que les cas de non-4NF et de non-5NF sont assez rares dans la
réalité.

7
 Exemple de synthèse : MCD-Relationnel-Normalisation-SQL

2. Exemple de synthèse : MCD-Relationnel-Normalisation-SQL

Problème posé

Soit un modèle conceptuel représentant :

- un type d'entité "chercheur", identifié par le numéro de sécurité sociale, et possédant les autres propriétés
suivantes : le nom, le nom de l'université à laquelle il appartient, la ville dans laquelle est basée cette
université.
- un type d'entité "professeur", héritant de "chercheur"
- un type d'entité "doctorant", héritant de "chercheur"
- une association de type "encadrement" entre professeur et doctorant (un professeur pouvant encadrer
plusieurs doctorants et un doctorant n'ayant qu'un et un seul directeur de thèse).

Afin de réaliser le modèle de données :

1. Dessiner le modèle conceptuel

2. Traduire le modèle conceptuel en modèle logique relationnel.
3. Après avoir identifié les DF, normaliser le modèle relationnel en BCNF.
4. Ecrire les instructions SQL de création d'un tel modèle.

2.1. Première étape : Modélisation conceptuelle

Méthode : Modélisation conceptuelle : Entité Chercheur

Conception UML (1/4)

8
 Méthode : Modélisation conceptuelle : Entité Professeur

Conception UML (2/4)

9
Méthode : Modélisation conceptuelle : Entité Doctorant

Conception UML (3/4)

Méthode : Modélisation conceptuelle : Association Encadrement

Conception UML (4/4)

10
2.2. Deuxième étape : Modèle relationnel

Méthode : Modèle relationnel : Héritage

Choix de transformation de l'héritage : L'héritage est exclusif (les professeurs ne sont plus doctorants), mais pas
complet, car l'association Encadre n'est pas symétrique. On choisit donc un héritage par les classes filles
(Chercheur étant par ailleurs abstrait).

Méthode : Modèle relationnel : Entité Professeur

1 Professeur (#N°SS:int(13), Nom:char(20), NomUniv:char(50), VilleUniv:char(20))

Méthode : Modèle relationnel : Entité Doctorant

1 Professeur (#N°SS:int(13), Nom:char(20), NomUniv:char(50), VilleUniv:char(20))

2 Doctorant (#N°SS:int(13), Nom:char(20), NomUniv:char(50), VilleUniv:char(20))

Méthode : Modèle relationnel : Association EncadréPar

1 Professeur (#N°SS:int(13), Nom:char(20), NomUniv:char(50), VilleUniv:char(20))

2 Doctorant (#N°SS:int(13), Nom:char(20), NomUniv:char(50), VilleUniv:char(20),
EncadrePar=>Professeur)

2.3. Troisième étape : Dépendances fonctionnelles

Méthode : Dépendances fonctionnelles : DF évidente (professeur)

- Professeur.N°SS → Nom, NomUniv, VilleUniv

Méthode : Dépendances fonctionnelles : DF évidente (doctorant)

- Professeur.N°SS → Nom, NomUniv, VilleUniv
- Doctorant.N°SS → Nom, NomUniv, VilleUniv, EncadrePar

Méthode : Dépendances fonctionnelles : DF déduites du sens des propriétés

Connaissant l'université, on connaît la ville, donc :

- Professeur.N°SS → Nom, NomUniv, VilleUniv

- [Link] → VilleUniv
- Doctorant.N°SS → Nom, NomUniv, VilleUniv, EncadrePar
- [Link] → VilleUniv

2.4. Quatrième étape : Formes normales

Méthode : Forme normale : 1NF

Le schéma est en 1NF (clés et attributs atomique).

Méthode : Forme normale : 2NF

Le schéma est en 2NF (la clé est composée d'un seul attribut)

11
 Méthode : Forme normale : 3NF
La schéma n'est pas en 3NF : NomUniv → VilleUniv

2.5. Cinquième étape : Décomposition

Méthode : Normalisation en BCNF : Résultat

1 Professeur (#N°SS:int(13), Nom:char(20), NomUniv=>Univ)

2 Doctorant (#N°SS:int(13), Nom:char(20), NomUniv=>Univ, EncadrePar=>Professeur)
3 Univ (#NomUniv:char(50), VilleUniv:char(20))

Méthode : Normalisation en BCNF : Vérification

Le modèle est bien en BCNF, toutes les DF ont pour source une clé.

Méthode : Normalisation en BCNF : Conservation des DF

La transformation préserve les DF car :

- N°SS → NomUniv et [Link] → Ville

- Donc N°SS → [Link] (par transitivité)

2.6. Sixième étape : Implémentation SQL LDD

Méthode : Implémentation SQL : Professeur

1 Create Table Professeur (

2 N°SS INTEGER(13) PRIMARY KEY,
3 Nom CHAR(20) NOT NULL,
4 NomUniv CHAR(50) REFERENCES Univ(Nom));

Méthode : Implémentation SQL : Doctorant

1 Create Table Professeur (

2 N°SS INTEGER(13) PRIMARY KEY,
3 Nom CHAR(20) NOT NULL,
4 NomUniv CHAR(50) REFERENCES Univ(Nom));

1 Create Table Doctorant (

2 N°SS INTEGER(13) PRIMARY KEY,
3 Nom CHAR(20) NOT NULL,
4 NomUniv CHAR(50) REFERENCES Univ(Nom),
5 EncadrePar INTEGER(13) REFERENCES Professeur(N°SS));

Méthode : Implémentation SQL : Univ

1 Create Table Professeur (

2 N°SS INTEGER(13) PRIMARY KEY,
3 Nom CHAR(20) NOT NULL,
4 NomUniv CHAR(50) REFERENCES Univ(Nom));

1 Create Table Doctorant (

2 N°SS INTEGER(13) PRIMARY KEY,
3 Nom CHAR(20) NOT NULL,

12
 4 NomUniv CHAR(50) REFERENCES Univ(Nom),
5 EncadrePar INTEGER(13) REFERENCES Professeur(N°SS));

1 Create Table Univ (

2 Nom CHAR(50) PRIMARY KEY,
3 Ville CHAR(20) );

13
 Exercices

Exercices
II
1. Exercice : Project manager
[15 min]
Soit la table suivante (Emp signifie Employee, Pro signifie Project et Man signifie Manager).

Soit les dépendances fonctionnelles suivantes :

- Emp → EmpName
- Emp → Pro
- Pro → ProName
- Pro → Man
- Pro → ManName
- Man → ManName

Question 1 [solution n°2 p.21]

[* ]

Montrer que ce modèle n'est pas en 3NF.

Question 2 [solution n°3 p.22]

[* ]

Proposer un modèle équivalent en 3NF.

2. Exercice : Objectifs II
[15 min]
Vous êtes le président de l'association "Objectifs", dont l'objet est d'aider ses étudiants membres à mener des
projets dans le cadre de leurs études. Pour le moment cette association gère tous ces projets avec un logiciel de
type tableur.

14
 Exercice : Jeu de construction

Exemple de fichier de gestion des projets de l'association Objectifs

La concision et la clarté de la rédaction, ainsi que la bonne mobilisation des concepts et de la terminologie du
domaine des bases de données seront intégrées à l'évaluation.

Question 1 [solution n°4 p.22]

[*]

On considérera ce tableau comme une relation, et on admettra que cette extension est suffisante pour
l'interprétation des données :

1. Démontrer que cette relation ne peut admettre qu'une seule clé.

2. Démontrer que la 1NF* n'est pas respectée à plusieurs reprises (on peut trouver jusque six causes
empêchant la 1NF, proposez-en un maximum).

Question 2 [solution n°5 p.22]

[*]

On propose une première décomposition pour que le modèle soit en 1NF.

1 Projet (#Num, Nom, Debut, Fin, Specialite, CDP-Prenom, CDP-Nom, CDP-Specialite)

2 Tache (#NumProjet=>Projet, #NumTache, Nom, Participant-Prenom, Participant-Nom,
Participant-Specialite)
3 Partenaire (#Nom, Description)
4 Partenariat (#Partenaire=>Partenaire, #Projet=>Projet, role)

1. Montrer que ce modèle n'est pas en 3NF et lister l'ensemble des DFE responsables.
2. Proposer une décomposition en 3NF.

3. Exercice : Jeu de construction

[30 min]
Soit le diagramme UML ci-après décrivant des constructions composées d'éléments et faisant appel à des
compétences pour leur montage.

Par exemple une "Maison de type I" contiendra :

- 100 m² de "Brique traditionnelle" (Type de l'élément), pour un prix de 2 euros par unité (Prix/U), 12
briques par m² (U/m²) et 100g / brique (Poids/U)
- 125 m² de "Tuile plate" (Type de l'élément), pour un prix de 4 euros par unité (Prix/U), 24 tuile par m²
(U/m²) et 75g / tuile (Poids/U)

et fera appel à :

- 500h de travail de "Maçon" (Type de compétence), pour un tarif horaire de 20€/h

- 425h de travail de "Couvreur" (Type de compétence), pour un tarif horaire de 30€/h
- 75h de "Chef de chantier" (Type de compétence), pour un tarif horaire de 45€/h

15
 Exercice : À l'école

Modèle UML

Question 1 [solution n°6 p.23]

[* ]

Effectuer le passage au relationnel de ce modèle.

Question 2 [solution n°7 p.23]

[* ]

Sachant que deux mêmes types d'élément ont toujours les mêmes caractéristiques (Prix/U, U/m², Poids/U) et
que deux mêmes types de compétence ont toujours les mêmes prix (Prix/h), établir la fermeture transitive des
DFE et la forme normale de ce modèle (justifier).

Donner un exemple de données redondantes.

Indice :
Deux types de maison ont évidemment des quantités d'éléments (m²) et de compétences (h) différentes.

Question 3 [solution n°8 p.23]

[* ]

Normaliser le modèle en 3NF (justifier, et montrer que la transformation est sans perte).

Question 4 [solution n°9 p.24]

[* ]

En repartant de la forme normalisée en 3NF, rétro-concevoir un modèle UML qui aurait permis d'aboutir
directement à ce schéma non redondant.

4. Exercice : À l'école
[15 min]
Une école souhaite se doter d'une base de données pour suivre ses effectifs (élèves et professeurs) ainsi que les
classes auxquelles ils sont rattachés. L'analyse des besoins est la suivante :

- Les classes sont identifiées par un niveau et une lettre (6-A, 6-B, 5-A, ...).
- Les classes peuvent avoir un programme adapté suivant un thème unique (sport-étude, bilingue anglais ou
bilingue allemand).
- Les classes ont un professeur principal et plusieurs professeurs intervenant dans leur spécialité.
- Les classes accueillent des élèves.

16
 Exercice : À l'école

- Les élèves sont sous la responsabilité d'un parent (qui peut aussi être professeur, voire lui même élève).

École

Question 1 [solution n°10 p.24]

[*]

À partir du schéma UML proposé, réaliser le passage au modèle relationnel en justifiant les choix pour les
deux héritages.

Question 2 [solution n°11 p.24]

[*]

Montrer que ce schéma n'est pas en première forme normale, et proposer une correction du schéma relationnel.

17
 Devoir

Devoir
III
1. Exercice : Gestion d'incidents
[30 minutes]
Soit la table ci dessous permettant d'enregistrer des relevés d'incident sur les chaînes de montage d'un grand
groupe de construction de tondeuses.

Chaque ligne de la table permet de relever un incident.

tIncident

Soit le relevé des DF suivant :

- Num → Dat, Gra, Nom, Typ

- Pie → Mag, Fou, Mod, Usi
- Mod → Cat
- Typ → Fam

Question 1

Établissez la fermeture transitive des DF. Justifiez votre réponse.

18
 Exercice : Gestion d'incidents

Question 2

Donnez toutes les clés possibles de ce modèle et choisissez la meilleure candidate comme clé primaire.
Justifiez votre réponse.

Question 3

En quelle forme normale est ce schéma (vos clés font partie du schéma) ? Justifiez votre réponse.

Question 4

Proposez une couverture minimale des DF. Justifiez votre réponse.

Question 5

Proposez un modèle relationnel décomposé normalisé en 3NF, sans perte. Justifiez votre réponse.

Question 6

Montrez que le modèle conceptuel qui aurait permis de trouver directement ce modèle normalisé comprend
trois associations.

19
 Questions de synthèse

Questions de synthèse

Quelles sont les étapes de la conception d'une base de données normalisée ?

..................................................................................................................................................................................................................
..................................................................................................................................................................................................................
..................................................................................................................................................................................................................
..................................................................................................................................................................................................................
..................................................................................................................................................................................................................
..................................................................................................................................................................................................................
..................................................................................................................................................................................................................

Pourquoi doit-on réaliser une décomposition chaque fois qu'une DFE est responsable d'un défaut de normalisation ?

..................................................................................................................................................................................................................
..................................................................................................................................................................................................................
..................................................................................................................................................................................................................
..................................................................................................................................................................................................................
..................................................................................................................................................................................................................
..................................................................................................................................................................................................................
..................................................................................................................................................................................................................

20
Stéphane Crozat (Contributions : Antoine Vincent, Dritan Nace)
 Solutions des exercices

Solutions des exercices

> Solution n°1 Exercice p. 3

Mettre dans l'ordre les étapes de conception suivantes.

Analyse de la situation existante et des

Modélisation conceptuelle en UML ou E-A
besoins

Élaboration du modèle logique en relationnel ou relationnel-objet

Établissement des DF sous la forme de la fermeture transitive pour chaque relation du modèle

Énonciation de la forme normale avant normalisation

Décomposition des relations jusqu'à arriver en 3NF en préservant les DF

Rétro-conception d'un modèle UML normalisé

Création du code SQL LDD pour un SGBDR ou un SGBDRO

> Solution n°2 Exercice p. 14

Fermeture transitive F+

- Emp → EmpName
- Emp → Pro
- Emp → ProName
- Emp → Man
- Emp → ManName
- Pro → ProName
- Pro → Man
- Pro → ManName
- Man → ManName

Clé

- Emp

21
Stéphane Crozat (Contributions : Antoine Vincent, Dritan Nace)
 Solutions des exercices

2NF

Cette relation est 1NF car elle possède une clé Emp (et l'on pose que ses attributs sont atomiques.)

Cette relation est 2NF car la seule clé candidate Emp n'est composée que d'un attribut.

Cette relation n'est pas 3NF car des attributs non clés dépendent d'attributs non clés :

- Pro → ProName, Man

- Man → ManName

> Solution n°3 Exercice p. 14

On doit procéder ici à deux décompositions, pour aboutir à la solution suivante :

1 EMPLOYEE (#Emp, EmpName, Pro=>PROJECT)

2 PROJECT (#Pro, ProName, Man=>MANAGER)
3 MANAGER (#Man, ManName)

> Solution n°4 Exercice p. 15

1. La colonne "Numéro" peut être une clé et c'est la seule possible :

- La colonne "Projet / Tâche" ne peut pas être une clé car elle contient deux valeurs identiques.
- Toutes les autres colonnes admettent au moins une valeur nulle et ne peuvent donc faire partie
d'une clé.
- Il n'est pas possible de définir une clé composée car elle contiendrait soit "Numéro" (qui est déjà
une clé, elle ne serait alors pas minimale) soit une colonne avec des valeurs nulles (ce qui est
interdit).

2. Les colonnes suivantes ne sont pas atomiques :

- "Numéro" contient le numéro de projet et de tâche

- "Chef de projet" et "Participants tâches" contiennent des noms, prénoms et spécialités de membres
- Dates contient un début et une fin de période
- Partenaire contient un nom et une description de partenaire
- Partenaire contient plusieurs partenaires

> Solution n°5 Exercice p. 15

DFE responsables

- Projet : CDP-Prenom, CDP-Nom → CDP-Specialite

- Tâche : Participant-Prenom, Participant-Nom → Participant-Specialite

Décomposition

1 Projet (#Num, Nom, Debut, Fin, Specialite, CDP-Prenom=>Membre, CDP-Nom=>Membre)

2 Tache (#NumProjet=>Projet, #NumTache, Nom, Participant-Prenom=>Membre,
Participant-Nom=>Membre)
3 Membre (#Nom, #Prenom, Specialite)
4 Partenaire (#Nom, Description)

22
Stéphane Crozat (Contributions : Antoine Vincent, Dritan Nace)
 Solutions des exercices

5 Partenariat (#Partenaire=>Partenaire, #Projet=>Projet, role)

On observe que CDP et Participant renvoient à une même entité que l'on nomme Membre.

> Solution n°6 Exercice p. 16

1 Construction (#Nom:String)
2 Élément (#Type:String, #Construction=>Construction, m²:Integer, Prix/U:Integer, U
/m²:Integer, Poids/U:Integer)
3 Compétence (#Type:String, #Construction=>Construction, h:Integer, Prix/h:Integer)

> Solution n°7 Exercice p. 16

Fermeture transitive des DFE

1 Élé[Link], Élé[Link] → m²
2 Élé[Link] → Prix/U
3 Élé[Link] → U/m²
4 Élé[Link] → Poids/U
5 Compé[Link], Compé[Link] → h
6 Compé[Link] → Prix/h

Complément
DF élémentaire (cf. p.)

Notion de fermeture transitive des DFE (cf. p.)

Forme normale

Le modèle est en 1NF, les attributs sont atomiques et les relations ont des clés.

Elle n'est pas en 2NF car des parties de clé (Élé[Link] et Compé[Link]) déterminent des
attributs.

Complément
Deuxième forme normale (cf. p.)

Exemple

Maison I Maçon 500 20

Maison II Maçon 600 20

Exemple de données redondantes

> Solution n°8 Exercice p. 16

1 Construction (#Nom:String)
2 Élément (#Type=>TypeÉlément, #Construction=>Construction, m²:Integer)
3 TypeÉlément (#Type:String, Prix/U:Integer, U/m²:Integer, Poids/U:Integer)

23
Stéphane Crozat (Contributions : Antoine Vincent, Dritan Nace)
 Solutions des exercices

4 Compétence (#Type=>TypeCompétence, #Construction=>Construction, h:Integer)

5 TypeCompétence (#Type:String, Prix/h:Integer)

Complément
Algorithme de décomposition (cf. p.4)

La décomposition est sans perte car :

- Les attributs ont été préservés  : JointureNaturelle(Élément,TypeÉlément) et

JointureNaturelle(Compétence,TypeCompétence) nous permettent de retrouver les
relations Élément et Compétence d'origine
- Les DFE ont été préservées : la fermeture transitive du modèle décomposé est exactement la même que
celle du modèle d'origine

> Solution n°9 Exercice p. 16

Modèle normalisé

> Solution n°10 Exercice p. 17

Gestion de l'héritage

- Personne : La classe mère est abstraite, l'héritage est non exclusif et non complet, c'est donc un cas
problématique. La meilleure solution est ici un choix d'héritage par référence, l'héritage par les classes
filles introduirait de la redondance et l'héritage par la classe mère poserait des problèmes au niveau des
associations.
- Classe : La classe mère est non abstraite et l'héritage est complet, c'est un cas simple, on adopte un
héritage par la classe mère.

1 personne (#num:entier,nom:chaîne, prénom:chaîne, date_de_naissance:date)

2 élève (#num=>personne, moyenne_générale:réel, responsable=>parent, classe=>classe)
3 parent (#num=>personne, profession:chaîne)
4 professeur (#num=>personne, matière:chaîne)
5 classe (#id:entier(1)-char(1), type
{normal|sport_étude|bilingue_anglais|bilingue_allemand}, prof_principal=>professeur)
6 enseigne (#professeur=>professeur, #classe=>classe)

24
Stéphane Crozat (Contributions : Antoine Vincent, Dritan Nace)
 Solutions des exercices

> Solution n°11 Exercice p. 17

Le schéma n'est pas en première forme normale car l'attribut [Link] n'est pas atomique. Ici il suffit de
séparer cet attribut en deux sous-attributs :

1 classe (#niveau:entier(1), #lettre:char(1) ...)

2 élève (... [Link]=>classe, [Link]=>classe)

25
Stéphane Crozat (Contributions : Antoine Vincent, Dritan Nace)
 Signification des abréviations

Abréviations
1NF : First Normal Form

3NF : Third Normal Form

4NF : Fourth Normal Form

5NF : Fifth Normal Form

BCNF : Boyce-Codd Normal Form

DDN : Date De Naissance

DF : Dépendance Fonctionnelle

26
Stéphane Crozat (Contributions : Antoine Vincent, Dritan Nace)