1. Bases de Donn´es Avanc´es
e e
Introduction & Rappel
Conception et Mod´lisation
e
Thierry Hamon
Bureau H202 - Institut Galil´e
e
T´l. : 33 1.48.38.35.53
e
Bureau 150 – LIM&BIO – EA 3969
Universit´ Paris 13 - UFR L´onard de Vinci
e e
74, rue Marcel Cachin, F-93017 Bobigny cedex
T´l. : 33 1.48.38.73.07, Fax. : 33 1.48.38.73.55
e
thierry.hamon@univ-paris13.fr
http://www-limbio.smbh.univ-paris13.fr/membres/hamon/BDA-20102011
INFO2 – BDA
1/61

2. Sources des transparents
M.P. Dorville/F. Goasdou´, LRI, Universit´ Paris Sud
e e
V. Mogbil, LIPN, Universit´ Paris Nord
e
J. Ullman http://infolab.stanford.edu/~ullman/
C. Rouveirol, LIPN, Universit´ Paris Nord
e
F. Boufares, LIPN, Universit´ Paris Nord
e
2/61

3. Pr´sentation du cours
e Pr´sentation du cours
e
Objectif du cours (12 s´ances de 1h30) :
e
Des Bases de Donn´es aux Entrepˆts de Donn´es Exploitation
e o e
Intelligente des Donn´es
e
Travaux Pratiques (12 s´ances de 1h30) :
e
Mise en œuvre de concepts vus en cours (PL/SQL, UML →
SQL2/3, int´grit´ des donn´es, etc.)
e e e
3/61

4. Programme des enseignements Pr´sentation du cours
e
Rappels de SQL
Conception & Mod´lisation de Bases de Donn´es
e e
M´ta-Mod´lisation, Formalismes utilis´s (ER, EER, UML, ...)
e e e
Expression & Coh´rence des contraintes (SQL2/3, PL/SQL,
e
OCL, ...)
Implantation de Bases de Donn´es
e
Relationnel-´tendu, Orient´ Objet (de UML ` SQL2/3, JDBC,
e e a
Java, PL/SQL J...)
Optimisation de Requˆtes, Evaluation de Requˆtes
e e
Architecture de SGBD, Administration de BD
Autres (Bases de Donn´es, Entrepˆts de donn´es, XML)
e o e
Gros volumes de donn´es / Entrepˆts de donn´es / Donn´es
e o e e
MultiDimensionnelles
Donn´es Homog`nes & H´t´rog`nes,
e e ee e
Donn´es R´parties/Web, Donn´es de type documents, ...
e e e
4/61

5. Des bases de donn´es aux Entrepˆts de donn´es du cours
e o eesentation
Pr´
5/61

6. Historique Historique
G´n´rations de SGBD
e e
Indépendance physique
Volume de données
SGBD4/5
Type de données
Avancés
2004/5 − 2010
Portabilité
SGBD 3
Avancés
1980 − 1990 − 2000
SGBD 2
Relationnels
1970 − 1980 − 1990
SGBD 1
Hiérarchies, Réseaux
1960 − 1970 − 1980
Puissance
Performance
Cohérence
6/61

7. Historique Historique
Exemples de SGBD
SGBD4/5
ORACLE 9i, 10g, 11
DB2, ...
Indépendance physique
Volume de données
XML, ...
Type de données
SGBD 3
ORACLE 7/8,
Portabilité
INGRES, DB2, Sybase,
Verssant Enjin (O2),
ObjectStore, Orlent,
MySQL, PostGreSQL,
SGBD 2 SQLServer, ACCESS, ...
ORACLE 5/6
INGRES,
DB2, ...
Bases de données
SGBD 1 Entrepôts de données
COADSYL, Intégration de Données
SOCRATE,
... Puissance
Performances
Cohérence
7/61

8. Historique Historique
Applications BD, ED, FD
Volume de données
Type de données
Fouille de données
(Analyse du comportement des clients, etc.)
Entrepôts de données (grosses masses de données)
Intégration de plusieurs systèmes d’information nationaux et internationnaux)
(milliers de tables de quelques millions de lignes) > 100 Go
Applications : Gestion des risques, Analyse des ventes
(100 tables de quelques millions de lignes) 2 Go
Bases de Données
Entrepôts de Données
Intégration de Données
Applications : Paie, Marketing, Financière
(50 tables de quelques milliers de lignes) 50 Mo Performance
8/61

9. Historique Historique
Applications BD, ED, FD
Volume de données
Type de données
Entrepôts de données
(OLTP : < 10 secondes) (OLAP < 1 heure)
( MV : agrégation, ...) (Batch : Quotidien ou mensuel < 1h)
Grosse volumétrie : travail d’optimisation et suivi des activités
du DWh nécéssaire
Par expérience, certains traitements ne se terminent pas
au bout de quelques jours
Nécessité de modifications techniques et fonctionnelles
Applications : Gestion des risques, Analyse des ventes
(Batch : < 1 heure) Bases de Données
Entrepôts de Données
Intégration de Données
Applications : Paie, Marketing, Financière
(OLTP: quelques secondes) (Batch : < 1 heure) Performance
9/61

10. Historique Historique
Structure et type de donn´es
e
Relationnelle
& objet Type de données
Indépendance physique
Volume de données
COMPLEXE
Type de données
Relations
Structure de données
Portabilité
TABULAIRE
Hiérarchique Structure de données
& Réseau en RESEAU
Structure HIERARCHIQUE
des données
Puissance
Performance
Cohérence
10/61

11. Commandes SQL
Plusieurs sortes de commandes SQL parmi lesquelles :
LDD (langage de d´finition de donn´es),
e e
LMD (langage de manipulation des donn´es) c’est-`-dire du
e a
LMJ (langage de mise ` jour) et du LID (langage
a
d’interrogation des donn´es),
e
LCD (langage de contrˆle des donn´es).
o e
11/61

12. Le Langage de D´finition de Donn´es (LDD)de Donn´es : LDD
e Le e
Langage de D´finition
e e
Ensemble de commandes qui d´finit une base de donn´es et
e e
les objets qui la composent
la d´finition d’un objet inclut
e
sa cr´ation: CREATE
e
sa modification ALTER
sa suppression DROP
12/61

13. Le langage de manipulation de donn´es manipulation de donn´es : LMD
Le langage de : LMD
e e
Ensemble de commandes qui permet la consultation et la mise
` jour des objets cr´´s par le langage de d´finition de donn´es
a ee e e
Consultation : SELECT
La mise ` jour inclut :
a
l’insertion de nouvelles donn´es : INSERT
e
la modification de donn´es existantes : UPDATE
e
la suppression de donn´es existantes : DELETE
e
13/61

14. Le langage de manipulation de donn´es manipulation de donn´es : LMD
Le langage de : LMD
e e
Exemple
SELECT < l i s t e champ ( s )> FROM < l i s t e n o m t a b l e ( s )>
[WHERE c o n d i t i o n ( s ) ] [ o p t i o n s ] ;
INSERT INTO <n o m t a b l e > [( < l i s t e champ ( s ) >)]
VALUES (< l i s t e v a l e u r s >);
UPDATE <n o m t a b l e > SET <champ> = <e x p r e s s i o n >
[WHERE < l i s t e c o n d i t i o n ( s )> ] ;
DELETE FROM <n o m t a b l e > [WHERE < l i s t e c o n d i t i o n ( s )> ] ;
14/61

15. Le langage de contrˆle de donn´eslangage de contrˆle de donn´es : LCD
o e Le : LCD o e
Ensemble de commandes de contrˆle d’acc`s aux donn´es
o e e
Le contrˆle d’acc`s inclut :
o e
l’autorisation ` r´aliser une op´ration : GRANT
a e e
l’interdiction de r´aliser une op´ration : DENY
e e
Annulation d’une commande de contrˆle pr´c´dente : REVOKE
o e e
l’autorisation ` modifier des enregistrements : UPDATE
a
l’interdiction de modifier des enregistrements : READ
(consultation en lecture seulement)
l’autorisation ` supprimer des enregistrements : DELETE
a
15/61

16. Conception, D´veloppement, Utilisation, Administration
e Introduction
1 Etape conceptuelle : Conception et Mod´lisation de bases de
e
donn´es
e
Utilisation de
M´thodes, Mod`les, Formalismes
e e
Mod`le Entit´-Association E/A / Mod`le Entit´-Association
e e e e
´tendu
e
Mod`les Objet, Formalisme UML
e
Power AMC, Power Designer WinDev, Oracle Designer
Rational Rose, ...
2 Etape logique : Implantation d’une base de donn´es
e
Mod`le Relationnel / Mod`le Objet-Relationnel / Mod`le
e e e
Objet
Optimisation du sch´ma (Normalisation, D´normalisation ...)
e e
16/61

17. Conception, D´veloppement, Utilisation, Administration
e Introduction
3 Etape physique :
SGBD Relationnel / SGBD Objet-Relationnel / SGBD Orient´
e
Objet
Langages ( SQL, PL/SQL, PRO*C, JDBC, Java, ...)
Optimisations (Groupement, Index, ...)
Administration
Oracle, DB2, My SQL
4 Logiciels (SGBD, Interfaces, ...) & Mat´riels
e
17/61

18. Conception du sch´ma des bases
e Introduction
→ Une des tˆches essentielles des d´veloppeurs de bases de
a e
donn´es
e
Objectif : structuration du domaine d’application afin de
de le repr´senter sous forme de types et de tables
e
d’accompagner ces structures de contraintes sur les donn´es
e
afin de tirer plus de s´mantique
e
18/61

19. Conception du sch´ma des bases
e Introduction
La repr´sentation doit ˆtre :
e e
juste pour ´viter les erreurs s´mantiques, notamment dans les
e e
r´ponses aux requˆtes ;
e e
compl`te pour permettre le d´veloppement des programmes
e e
d’application souhait´s ;
e
´volutive afin de supporter la prise en compte rapide de
e
nouvelles demandes.
19/61

20. Etapes de conception Introduction
D´marche de conception traditionnelle :
e
par abstractions successives
en descendant depuis les probl`mes de l’utilisateur vers le
e
Syst`me de Gestion de Bases de Donn´es.
e e
Cinq ´tapes :
e
1 Perception du monde r´el et capture des besoins
e
2 ´
Elaboration du sch´ma conceptuel
e
3 Conception du sch´ma logique
e
4 Affinement du sch´ma logique
e
5 ´
Elaboration du sch´ma physique
e
20/61

21. Remarques Introduction
´
Etape 1 : plutˆt relative au domaine du g´nie logiciel
o e
´
Etapes 2, 3, 4 et 5 : relative au domaine des bases de donn´es
e
21/61

22. Etape 1 : Perception du monde r´el et capture des besoins
e Introduction
Etude des probl`mes des utilisateurs
e
Compr´hension de leurs besoins
e
→ Mise en place d’entretiens, d’analyses des flux d’information et
des processus m´tier
e
Difficult´ : compr´hension du probl`me dans son ensemble
e e e
→ R´alisation des ´tudes de cas partiels par les concepteurs
e e
R´sultat : ensemble de vues ou sch´mas externes devant ˆtre
e e e
int´gr´s dans l’´tape suivante
e e e
Vues exprim´es dans un mod`le de de donn´es : de type
e e e
entit´-association ou objet, selon la m´thode choisie
e e
22/61

23. ´
Etape 2 : Elaboration du sch´ma conceptuel
e Introduction
Int´gration des sch´mas externes obtenus ` l’´tape pr´c´dente
e e a e e e
Chaque composant est un sch´ma conceptuel : diagramme
e
entit´-association ou diagramme de classes
e
R´sultat : mod`le de probl`me repr´sentant une partie de
e e e e
l’application
Difficult´ : int´gration de toutes les parties dans un sch´ma
e e e
conceptuel global complet, non redondant et coh´rent
e
NB : des allers et retours avec l’´tape pr´c´dente sont souvent
e e e
n´cessaires
e
23/61

24. Etape 3 : Conception du sch´ma logique
e Introduction
Transformation du sch´ma conceptuel en structures de donn´es
e e
support´es par le syst`me choisi : le sch´ma logique.
e e e
Avec un SGBD relationnel : passage ` des tables.
a
Avec un SGBD relationnel-objet : G´n´ration de types et de
e e
tables,
NB : les types sont r´utilisables
e
Avec un SGBD objet : g´n´ration de classes et de associations
e e
NB : Cette ´tape peut ˆtre compl`tement automatis´e.
e e e e
24/61

25. Etape 4 : Affinement du sch´ma logique
e Introduction
V´rification : le sch´ma logique est-il un
e e bon sch´ma ?
e
D´finition en premi`re approximation : un bon sch´ma
e e e
est un sch´ma sans oublis ni redondances d’informations
e
Plus pr´cis´ment : un sch´ma est bon si le mod`le
e e e e
relationnel associ´ respecte au moins la troisi`me forme
e e
normale et la forme normale de Boyce-Codd (voir plus loin)
Objectif en relationnel : regrouper ou d´composer les tables
e
de mani`re ` repr´senter fid`lement le monde r´el mod´lis´
e a e e e e e
25/61

26. ´
Etape 5 : Elaboration du sch´ma physique
e Introduction
Etape n´cessaire pour obtenir de bonnes performances
e
Prise en compte de toutes les transactions concernant les
applications trait´es
e
Permet de d´terminer les acc`s fr´quents
e e e
Choix des bonnes structures physiques : groupement ou
partitionnement de tables, index, etc.
point essentiel pour obtenir de bonnes performances
26/61

27. ´
Elaboration du sch´ma conceptuel
e ´
Elaboration du sch´ma conceptuel
e
Mod´lisation du probl`me en utilisant les sp´cifications des besoins
e e e
obtenues ` l’´tape 1 (capture des besoins)
a e
Deux possibilit´s :
e
utilisation du formalisme Entit´ Relation (ou Entit´
e e
Association)
→ production d’un diagramme ER/EA
utilisation du formalisme UML
→ production de classe
Ind´pendance du mod`le conceptuel par rapport au sch´ma
e e e
physique
27/61

28. Phases d’´laboration du sch´ma conceptuel sch´ma conceptuel
e e ´
Elaboration du e
Identification des entit´s ou classes
e
Identification des associations
Identification des attributs pour chacune des entit´s ou classes
e
D´finition des identifiants
e
28/61

29. Identification des entit´s ou classes du sch´ma conceptuel
e ´
Elaboration e
Entit´s : ´l´ment abstrait ou concret (objet, ´v`nement, etc.)
e ee e e
reconnu distinctement
Exemples : Jean Dupont, Michel Durant
Type-entit´s : Ensemble des entit´s ayant les mˆmes
e e e
caract´ristiques
e
Exemple : Personne(nom, prenom)
NB : Par abus de langage, on parle souvent d’entit´s ` la
e a
place de type-entit´s
e
Dans l’´tape 1, il s’agit de la description des ´l´ments
e ee
29/61

30. Identification des associations Elaboration du sch´ma conceptuel
´ e
Association : Lien logique entre deux entit´s
e
Type-Association : Ensemble d’association ou de relations
poss`dant les mˆmes caract´ristiques.
e e e
Association/type-association : mˆme abus de langage
e
A l’´tape 1 : une phrase simple reliant deux entit´s
e e
Exemple : un professeur est en charge de cours (lien entre
les entit´s professeur et cours)
e
Plusieurs types d’association existent
30/61

31. Types d’association ´
Elaboration du sch´ma conceptuel
e
unaire : relation au sein d’une mˆme entit´
e e
Exemple : un employ´ supervise un employ´
e e
binaire : relation entre deux entit´s (diff´rentes)
e e
Exemple : un client passe plusieurs commandes
ternaire : relation entre trois entit´s (diff´rentes)
e e
Exemple : un internaute note un film ` diff´rentes date (on
a e
veut conserver l’historique des notes)
31/61

32. Cardinalit´ d’un type-association
e ´
Elaboration du sch´ma conceptuel
e
Cardinalit´ : nombre minimal et maximal de fois qu’une entit´
e e
peut intervenir dans une association de ce type
Exemple : un client peut commander 1 ` n produits
a
Remarques :
la cardinalit´ minimal doit ˆtre inf´rieure ` la cardinalit´
e e e a e
maximale
la cardinalit´ doit ˆtre associ´e ` chaque patte de la relation
e e e a
32/61

33. Cardinalit´ minimale/maximaleElaboration du sch´ma conceptuel
e ´ e
Cardinalit´ minimale :
e
0 : une entit´ peut exister tout en ´tant impliqu´e dans
e e e
aucune association
1 : une entit´ ne peut exister que si elle est impliqu´e dans au
e e
moins une association
n : une entit´ ne peut exister que si elle est impliqu´e dans
e e
plusieurs associations (cas rare,` ´viter car cela pose des
ae
probl`mes)
e
Cardinalit´ maximale :
e
0 : une entit´ ne peut pas ˆtre impliqu´e dans une association
e e e
(normalement inexistant sinon probl`me de conception)
e
1 : une entit´ peut ˆtre impliqu´e dans au maximum une
e e e
association
n : une entit´ peut ˆtre impliqu´e dans plusieurs associations
e e e
33/61

34. Identification des attributs ´
Elaboration du sch´ma conceptuel
e
Attribut : caract´ristique associ´e ` une entit´
e e a e
Exemples : nom, pr´nom, age
e
Domaine associ´ ` un attribut : ensemble des valeurs possibles
ea
Chaque attribut doit poss`der une valeur compatible avec son
e
domaine
Remarque : Eviter absolument les attributs calcul´s.
e
Toujours utiliser des donn´es primaires – les attributs qui
e
servent ` les calculer
a
34/61

35. D´finition de l’identifiant
e ´
Elaboration du sch´ma conceptuel
e
Identifiant : liste des attributs devant avoir une valeur unique
chaque entit´e
Exemple : num´ro d’immatriculation d’une voiture, num´ro de
e e
s´curit´ sociale
e e
Remarques :
On utilise plutˆt le terme cl´ que identifiant
o e
Chaque type doit poss`der un identifiant (form´ d’un ou
e e
plusieurs attributs)
L’identifiant d’une association est la concat´nation des
e
identifiants des entit´s li´s
e e
NB : on peut d´finir un identifiant plus naturel
e
35/61

36. Remarques sur la conception ´
Elaboration du sch´ma conceptuel
e
Un attribut ne peut ˆtre partag´ entre deux entit´s ou
e e e
associations (probl`me de redondance)
e
En cas de difficult´ ` choisir entre entit´ et association (par
ea e
exemple, mariage) : utiliser le contexte pour y r´pondre
e
En cas de difficult´ ` trouver un identifiant pour un
ea
type-entit´ : ne s’agirait-il pas une association ?
e
Association dont toutes les pattes ont une cardinalit´ 1,1 :
e
l’association et les entit´s li´es ne correspondraint-ils pas `
e e a
une seule entit´ ?
e
36/61

37. Entit´-relation et UML
e ´
Elaboration du sch´ma conceptuel
e
Formalisme ER :
Formalisme UML :
37/61

38. Retour sur les cardinalit´s
e ´
Elaboration du sch´ma conceptuel
e
interpr´tation – Formalisme ER
e
(une des cardinalit´s est volontairement absente)
e
Tout ´tudiant participe au moins une fois ` l’association est inscrit.
e a
Tout ´tudiant est inscrit dans au moins une formation
e
Autrement dit : ` une instance d’´tudiant peut ˆtre associ´ `
a e e ea
plusieurs formations
38/61

39. Retour sur les cardinalit´s
e ´
Elaboration du sch´ma conceptuel
e
G´n´ralisation
e e
Formalisme ER :
Interpr´tations :
e
A est li´ 0 ` n fois ` B
e a a
La connaissance de B permet de d´finir A
e
La cl´ de B d´finit l’instance de A
e e
Formalisme UML :
39/61

40. ER ou UML ? ´
Elaboration du sch´ma conceptuel
e
Si conception de bases de donn´es : utilisation du mod`le
e e
entit´/relation
e
On mets l’accent sur le syst`me d’information (stockage,
e
traitement, r´ception, diffusion de l’information)
e
Si conception objet et programmation : utilisation de UML(2
– incluant l’h´ritage)
e
On mets l’acent sur les structures de donn´es et la
e
programmation
40/61

41. ´
Elaboration du sch´ma logique
e ´
Elaboration du sch´ma logique
e
Transformation du mod`le conceptuel en une structure de donn´es
e e
bas´e sur un mod`le de donn´es sp´cifique (par exemple, mod`le
e e e e e
relationnel)
R´alisation de la transformation ` l’aide de r`gles formelles
e a e
→ Possibilit´ d’automatisation de cette ´tape (Objecteering,
e e
Rational Rose)
Ind´pendant de la couche physique
e
R´sultat : mod`le logique de la base de donn´es
e e e
41/61

42. Passage au relationnel ´
Elaboration du sch´ma logique
e
Impl´mentation des entit´s et associations sous forme de
e e
tables
Les attributs correspondent aux colonnes des tables
le nom de l’attribut est le nom de la colonne
l’ensemble des valeurs possibles est le domaine
Exemple :
Professeur(numProf, nom, prenom)
Cours(nomCours, nom)
Charge(numProf, numCours)
42/61

43. Passage au relationnel ´
Elaboration du sch´ma logique
e
Traduction des associations :
R`gle de base : repr´sentation des associations par une table
e e
dont
le sch´ma est le nom de l’association
e
la liste des cl´s des entit´s participantes suivie des attributs de
e e
l’association
Am´lioration : Regrouper les associations 1..n avec la classe
e
cible
Exemple :
Voiture(numV, Marque, modele)
Possede(numProp, numV, Date)
→ les deux tables peuvent ˆtre regroup´es si toutes les
e e
voitures n’ont qu’un et un seul propri´taire
e
43/61

44. Affiner les requˆtes
e Affinement des requˆtes
e
respecter les formes normales
Pourquoi normaliser ?
pour limiter les redondances de donn´es
e
pour limiter les pertes de donn´es
e
pour limiter les incoh´rences au sein des donn´es
e e
pour am´liorer les performances des traitements
e
44/61

45. Formes normales Affinement des requˆtes
e
8 formes normales :
Formes normales 1 ` 3
a
Forme normale de Boyce-Codd
Formes normales de 4/5(/6)
Forme normale de domaine-cl´
e
Objectifs des trois premi`res formes normales : permettre la
e
d´composition de relations sans perdre d’informations
e
Une relation en forme normale de niveau N est forc´ment de forme
e
normale de niveau N − 1
45/61

46. Premi`re forme normale (1FN)
e Affinement des requˆtes
e
Une relation est en premi`re forme normale si tous ses attributs
e
contiennent des valeurs
simples et non-d´composables (utiliser une liste ou une table
e
externe)
non-r´p´titives
e e
constantes dans le temps (date de naissance plutˆt que l’ˆge)
o a
46/61

47. Premi`re forme normale (1FN)
e Affinement des requˆtes
e
Vol(NoVol*, CodeAeroDep, CodeAeroArr, HeureDep,
HeureArr, Jours)
devient
Vol(NoVol*, CodeAeroDep, CodeAeroArr, HeureDep,
HeureArr, Jour)
Vol(NoVol*, Jour)
47/61

48. Deuxi`me forme normale (2FN)
e Affinement des requˆtes
e
Une relation est en deuxi`me forme normale si et seulement si :
e
elle est en premi`re forme normale
e
tout attribut non cl´ est totalement d´pendant de toute la cl´
e e e
Autrement dit, une des trois conditions doit ˆtre respect´e :
e e
La cl´ primaire n’est form´e que d’un seul attribut
e e
La cl´ primaire contient tous les attributs de la table
e
Si la cl´ a plus d’un attribut, une d´pendance fonctionnelle ne
e e
doit jamais exister entre une partie seulement de la cl´ et un
e
autre attribut de la table.
48/61

49. Deuxi`me forme normale (2FN)
e Affinement des requˆtes
e
Avion(Constr*, Mod`le*, Conso, Capacit´, VitesseMax)
e e
→ il y a une d´pendance fontionnelle entre Constr et Mod`le
e e
On divise la table en deux :
Avion(Constr*, Mod`le*)
e
ModeleAvion(Mod`le*, Conso, Capacit´, VitesseMax)
e e
49/61

50. Troisi`me forme normale (3FN)
e Affinement des requˆtes
e
Une relation est en troisi`me forme normale si et seulement si :
e
elle est en deuxi`me forme normale
e
tout attribut n’appartenant pas ` une cl´ ne d´pend pas d’un
a e e
attribut non cl´
e
→ les d´pendances fonctionnelles entre deux attributs ordinaires
e
(ne faisant par partie de la cl´) ne sont pas autoris´es
e e
50/61

51. Troisi`me forme normale (3FN)
e Affinement des requˆtes
e
Exemple :
Voiture(Modele, Couleur, Annee, Cote)
→ il y a une d´pendance entre l’ann´e et la cote
e e
devient
Voiture(Modele, Couleur, Annee)
Cote(Ann´e, Cote)
e
51/61

52. Forme normale de Boyce-Codd (BCNF) Affinement des requˆtes
e
Extension plus rigide de la troisi`me forme normale (d´finie
e e
par R.F. Boyce et E.F. Codd – en partant du constat que la
3FN comportait certaines anomalies)
Une relation est en forme normale de Boyce-Codd si et
seulement si :
aucun attribut faisant partie de la cl´ ne d´pend
e e
d’un attribut ne faisant pas partie de la cl´ primaire
e
Remarques :
Un mod`le relationnel en FNBC est consid´r´ comme ´tant de
e ee e
qualit´ suffisante pour une l’implantation
e
Les cas de relations en 3FN qui ne sont pas d´j` en FNBC
ea
sont tr`s rares
e
52/61

53. Forme normale de Boyce-Codd (BCNF) Affinement des requˆtes
e
Exemple :
soit la relation Vins(Cru, Pays, R´gion)
e
Cru Pays R´gion
e
Chenas France Beaujolais
Julienas France Beaujolais
Morgon France Beaujolais
Brouilly France Beaujolais
Chablis Etats-Unis Californie
Attention : de nombreuses redondances
On propose les relations :
Crus (Cru, R´gion)
e
R´gions (R´gion, Pays)
e e
53/61

54. ´
Elaboration du sch´ma physique Elaboration du sch´ma physique
e ´ e
Objectifs :
Rechercher de bonnes performances
Prendre en compte les transactions
Indexer, d´normaliser, grouper, partitionner les tables
e
R´sultat : mod`le physique optimis´ de la base de donn´es
e e e e
54/61

55. Exemple ´
Elaboration du sch´ma physique
e
Sch´ma relationnel
e
COURS ( NUM COURS, NOMC, NBHEURES, ANNEE )
PROFESSEURS ( NUM PROF, NOMP, SPECIALITE , DATE ENTREE ,
DER PROM, SALAIRE BASE , SALAIRE ACTUEL )
CHARGE( NUM PROF∗ , NUM COURS∗ )
55/61

56. Sch´ma physique (SQL2)
e ´
Elaboration du sch´ma physique
e
c r e a t e t a b l e COURS
(NUM COURS NUMBER( 2 ) NOT NULL ,
NOMC VARCHAR( 2 0 ) NOT NULL ,
NBHEURES NUMBER( 2 ) ,
ANNE NUMBER( 1 ) ,
c o n s t r a i n t PK COURS p r i m a r y key (NUM COURS) ) ;
c r e a t e t a b l e PROFESSEURS
(NUM PROF NUMBER( 4 ) NOT NULL ,
NOMP VARCHAR2( 2 5 ) NOT NULL ,
SPECIALITE VARCHAR2( 2 0 ) ,
DATE ENTREE DATE,
DER PROM DATE,
SALAIRE BASE NUMBER,
SALAIRE ACTUEL NUMBER,
c o n s t r a i n t PK PROFESSEURS p r i m a r y key (NUM PROF) ) ;
56/61

57. Sch´ma physique (SQL2)
e ´
Elaboration du sch´ma physique
e
c r e a t e t a b l e CHARGE
(NUM PROF NUMBER( 4 ) NOT NULL ,
NUM COURS NUMBER( 4 ) NOT NULL ,
c o n s t r a i n t PK CHARGE p r i m a r y key (NUM COURS, NUM PROF) ) ;
a l t e r t a b l e CHARGE
add c o n s t r a i n t FK CHARGE COURS
f o r e i g n key (NUM COURS)
r e f e r e n c e s COURS (NUM COURS ) ;
a l t e r t a b l e CHARGE
add c o n s t r a i n t FK CHARGE PROFESSEUR
f o r e i g n key (NUM PROF)
r e f e r e n c e s PROFESSEURS (NUM PROF ) ;
57/61

58. Sch´ma physique (SQL2)
e ´
Elaboration du sch´ma physique
e
Ajout de contraintes
c r e a t e t a b l e COURS
(NUM COURS NUMBER( 2 ) ,
NOMC VARCHAR( 2 0 ) ,
NBHEURES NUMBER( 2 ) ,
ANNE NUMBER( 1 ) ,
c o n s t r a i n t PK COURS p r i m a r y key (NUM COURS) ,
c o n s t r a i n t NN COURS NOMC c h e c k (NOMC I S NOT NULL ) ) ;
c r e a t e t a b l e PROFESSEURS
(NUM PROF NUMBER( 4 ) ,
NOMP VARCHAR2( 2 5 ) ,
SPECIALITE VARCHAR2( 2 0 ) ,
DATE ENTREE DATE,
DER PROM DATE,
SALAIRE BASE NUMBER,
SALAIRE ACTUE NUMBER,
c o n s t r a i n t PK PROFESSEURS p r i m a r y key (NUM PROF) ,
c o n s t r a i n t NN PROFESSEURS NOMP c h e c k (NOMP I S NOT NULL ) ) ;
58/61

59. Sch´ma physique (SQL2)
e ´
Elaboration du sch´ma physique
e
Ajout de contraintes
c r e a t e t a b l e CHARGE
(NUM PROF NUMBER( 4 ) ,
NUM COURS NUMBER( 4 ) , ,
c o n s t r a i n t PK CHARGE p r i m a r y key (NUM COURS, NUM PROF) ) ;
a l t e r t a b l e CHARGE
add c o n s t r a i n t FK CHARGE COURS
f o r e i g n key (NUM COURS)
r e f e r e n c e s COURS (NUM COURS ) ;
a l t e r t a b l e CHARGE
add c o n s t r a i n t FK CHARGE PROFESSEUR
f o r e i g n key (NUM PROF)
r e f e r e n c e s PROFESSEURS (NUM PROF ) ;
59/61

60. Sch´ma relationnel-objet
e ´
Elaboration du sch´ma physique
e
COURS ( NUM COURS, NOMC, NBHEURES, ANNEE )
PROFESSEURS ( NUM PROF, NOMP, SPECIALITE , DATE ENTREE ,
DER PROM, SALAIRE BASE , SALAIRE ACTUEL ,
Ensemble−de (COURS) )
60/61

61. Sch´ma physique SQL3
e ´
Elaboration du sch´ma physique
e
create type c o u r s t y p e as o b j e c t
( n u m c o u r s number ( 2 ) , nomc v a r c h a r 2 ( 2 0 ) , n b h e u r e s number ( 2 ) ,
a n n e e number ( 1 ) )
/
create type l e s c o u r s t y p e as t a b l e of c o u r s t y p e
/
create type p r o f e s s e u r t y p e as o b j e c t
( n u m p r o f number ( 4 ) , nom v a r c h a r 2 ( 2 5 ) , s p e c i a l i t e v a r c h a r 2 ( 2 0 ) ,
cours lescours type . . . )
/
create table professeur of professeur type
( p r i m a r y key ( n u m p r o f ) )
n e s t e d t a b l e c o u r s s t o r e a s tabemp
/
61/61