Conception des bases de données II : Conception des bases de … · s t p h. s c e n a r i-c o m m...

stph

.sce

nari-

com

mu

nity

.org

/bdd

bdd2.pdf

Conception des basesde données II

Conception des basesde données

relationnelles

Paternité - Partage des Conditions Initiales à l'Identique : http://creativecommons.org/licenses/by-sa/2.0/fr/

STÉPHANE CROZAT

Publiée le 14 février 2017

Table des matières

I - L'héritage dans la modélisation conceptuelle de données 5

A. Cours..............................................................................................................5 1. Introduction à l'héritage..........................................................................................................5 2. Notions avancées pour l'usage de l'héritage en modélisation des BD.............................................9

B. Exercices.......................................................................................................14 1. Capitaine Krik......................................................................................................................14 2. Armoires secrètes................................................................................................................14

II - Transformation de l'héritage en relationnel 16

A. Cours............................................................................................................16 1. Les trois représentations de l'héritage en relationnel.................................................................16 2. Choisir la meilleure modélisation de l'héritage en relationnel......................................................21

B. Exercices.......................................................................................................28 1. Lab II+...............................................................................................................................28 2. Literie.................................................................................................................................29 3. Parc informatique.................................................................................................................30

III - Modélisation avancée des associations en UML et en relationnel 31

A. Cours............................................................................................................31 1. Modélisation avancée des associations en UML.........................................................................31 2. Passage UML-Relationnel : Associations avancées.....................................................................36 3. Synthèse sur la modalisation UML et relationnelle.....................................................................42 4. Modélisation avancée des associations 1:1 en relationnel..........................................................45

B. Exercices.......................................................................................................49 1. Lab III................................................................................................................................49 2. Étudiants et UVs (introduction)..............................................................................................50

IV - Modélisation conceptuelle de données avancée avec le diagramme de classes UML 51

A. Cours............................................................................................................51 1. Diagramme de classes avancé...............................................................................................51 2. Passage UML-Relationnel : Expression de contraintes................................................................57

B. Exercices.......................................................................................................63 1. Ouaf !.................................................................................................................................63 2. Super-héros relationnels I.....................................................................................................64 3. Médiathèque........................................................................................................................64

Stéphane Crozat 2

V - Analyse de bases de données SQL avec les agrégats (GROUP BY) 66

A. Cours............................................................................................................66 1. Introduction aux agrégats avec GROUP BY..............................................................................66 2. Approfondissement des agrégats avec GROUP BY et HAVING.....................................................73

B. Exercices.......................................................................................................77 1. Location d'appartements en groupe........................................................................................77 2. Championnat de Formule 1....................................................................................................78 3. Questions scolaires...............................................................................................................78 4. Quiz : SQL LMD...................................................................................................................79

VI - Vues et gestion des droits 82

A. Cours............................................................................................................82 1. Notion de schéma externe et de vue.......................................................................................82 2. Passage UML-Relationnel : Expression des vues pour l'héritage et les méthodes...........................84 3. Le Langage de Contrôle de Données de SQL............................................................................88

B. Exercice.........................................................................................................90 1. Du producteur au consommateur++.......................................................................................90 2. Gauloiseries........................................................................................................................91

VII - Théorie de la normalisation relationnelle 93

A. Cours............................................................................................................93 1. Redondance et normalisation.................................................................................................93 2. Les dépendances fonctionnelles.............................................................................................95 3. Les formes normales..........................................................................................................101 4. Bibliographie commentée sur la normalisation........................................................................106

B. Exercices.....................................................................................................107 1. De quoi dépend un cours ?..................................................................................................107 2. Cuisines et dépendances.....................................................................................................107 3. Test : Normalisation...........................................................................................................108

VIII - Conception de bases de données normalisées 111

A. Cours..........................................................................................................111 1. Conception de bases de données normalisées........................................................................111 2. Exemple de synthèse : MCD-Relationnel-Normalisation-SQL....................................................115

B. Exercices.....................................................................................................118 1. Project manager................................................................................................................118 2. Objectifs II........................................................................................................................119 3. Jeu de construction............................................................................................................120 4. À l'école............................................................................................................................120

IX - Gestion des transactions pour la fiabilité et la concurrence122

A. Cours..........................................................................................................122 1. Principes des transactions...................................................................................................122 2. Manipulation de transactions en SQL....................................................................................124 3. Fiabilité et transactions.......................................................................................................127 4. Concurrence et transactions................................................................................................133 5. Synthèse : Les transactions.................................................................................................140 6. Bibliographie commentée sur les transactions........................................................................140

B. Exercices.....................................................................................................141 1. Super-héros sans tête........................................................................................................141 2. Exercice : Films en concurrence...........................................................................................142

Stéphane Crozat 3

X - Introduction à l'optimisation des bases de données 145

A. Cours..........................................................................................................145 1. Introduction à l'optimisation du schéma interne.....................................................................146 2. Mécanismes d'optimisation des moteurs de requêtes..............................................................154 3. Analyse et optimisation manuelle des requêtes......................................................................156 4. Synthèse : L'optimisation....................................................................................................159 5. Bibliographie commentée sur l'optimisation...........................................................................159

B. Exercices.....................................................................................................160 1. Film concret......................................................................................................................160 2. Super-lents.......................................................................................................................160

Glossaire 162

Signification des abréviations 163

Bibliographie 164

Webographie 165

Index 166

L'héritage dans la modélisation conceptuelle de données

Stéphane Crozat 4

I - L'héritage dans la modélisation conceptuelle de données

I

A. Cours

1. Introduction à l'héritage

Objectifs

Savoir utiliser l'héritage lors une modélisation

a) Exercice : Mariages

Étant donné le schéma UML suivant, quelles sont les assertions vraies ?

Image 1

Stéphane Crozat 5

Les mariages homosexuels sont possibles.

La polygamie est possible.

Une femme peut ne pas être mariée.

Les enfants peuvent être plus âges que leurs parents.

Deux hommes peuvent avoir un enfant ensemble.

Une femme peut avoir plusieurs enfants.

Un enfant a obligatoirement deux parents.

Les enfants peuvent se marier.

Tous les enfants sont mariés.

Les personnes mariées ont toujours le même nom.

b) Héritage

Définition : HéritageL'héritage est l'association entre deux classes permettant d'exprimer que l'une est plusgénérale que l'autre. L'héritage implique une transmission automatique des propriétés(attributs et méthodes) d'une classe A à une classe A'.Dire que A' hérite de A équivaut à dire que A' est une sous-classe de A. On peut égalementdire que A est une généralisation de A' et que A' est une spécialisation de A.

Syntaxe

Image 2 Notation de l'héritage en UML

Fondamental : FactorisationOutre qu'il permet de représenter une relation courante dans le monde réel,l'héritage a un avantage pratique, celui de factoriser la définition de propriétésidentiques pour des classes proches.

Héritage et factorisation


Stéphane Crozat 6

Fondamental : Is-aL'héritage permet de représenter la relation "est-un" entre deux objets (is-a enanglais).Donc tout ce qui est vrai pour la classe mère est vrai pour ses classes filles. Enparticulier si une classe C exprime une association avec une classe A dont hérite B,cela signifie que C peut être associée à B.

Héritage et propriété "is-a"

Exemple : La classe Conducteur

Image 3 Représentation d'héritage en UML

Dans cet exemple la classe Conducteur hérite de la classe Personne, ce qui signifie qu'un objetde la classe conducteur aura les attributs de la classe Conducteur (TypePermis et DatePermis)mais aussi ceux de la classe Personne (Nom, Prénom, DateNaissance et Age). Si la classePersonne avait des méthodes, des associations..., la classe Conducteur en hériterait de lamême façon.


Stéphane Crozat 7

c) Exemple : Des voitures et des conducteursExemple

Image 4 Exemple très simple de diagramme de classes

Les relations de ce diagramme expriment que les conducteurs sont des personnes qui ont unpermis ; que toute voiture est possédée par une unique personne (qui peut en posséderplusieurs) ; que les voitures peuvent être conduites par des conducteurs et que lesconducteurs peuvent conduire plusieurs voitures.

RemarqueLes mots clés in, out et in/out devant un paramètre de méthode permettent de spécifier si leparamètre est une donnée d'entrée, de sortie, ou bien les deux.

AttentionLe but d'une modélisation UML n'est pas de représenter la réalité dans l'absolu, maisplutôt de proposer une vision d'une situation réduite aux éléments nécessaires pourrépondre au problème posé. Donc une modélisation s'inscrit toujours dans uncontexte, et en cela l'exemple précédent reste limité car son contexte d'applicationest indéfini.

d) Classe abstraite

Définition : Classe abstraiteUne classe abstraite est une classe non instanciable. Elle exprime donc une généralisationabstraite, qui ne correspond à aucun objet existant du monde.

Attention : Classe abstraite et héritageUne classe abstraite est toujours héritée. En effet sa fonction étant de généraliser,elle n'a de sens que si des classes en héritent. Une classe abstraite peut être héritéepar d'autres classes abstraites, mais en fin de chaîne des classes non abstraitesdoivent être présentes pour que la généralisation ait un sens.

Syntaxe: Notation d'une classe abstraite en UMLOn note les classes abstraites en italique.


Stéphane Crozat 8

Image 5 Notation d'une classe abstraite en UML

Exemple : Exemple de classes abstraites

Image 6 Des chiens et des hommes

Dans la représentation précédente on a posé que les hommes, les femmes et les chiens étaientdes objets instanciables, généralisés respectivement par les classes mammifère et humain, etmammifère.Selon cette représentation, il ne peut donc exister de mammifères qui ne soient ni deshommes, ni des femmes ni des chiens, ni d'humains qui ne soient ni des hommes ni desfemmes.

2. Notions avancées pour l'usage de l'héritage en modélisation des BD

Objectifs

Savoir utiliser l'héritage lors une modélisation

a) Lab II

[15 min]

Description du problèmeUn laboratoire souhaite gérer les médicaments qu'il conçoit.

Un médicament est décrit par un nom, qui permet de l'identifier. En effet il n'existe pasdeux médicaments avec le même nom. Un médicament comporte une descriptioncourte en français, ainsi qu'une description longue en latin. On gère aussi le


Stéphane Crozat 9

conditionnement du médicament, c'est à dire le nombre de pilules par boîte (qui est unnombre entier).

À chaque médicament on associe une liste de contre-indications, généralementplusieurs, parfois aucune. Une contre-indication comporte un code unique qui l’identifie,ainsi qu'une description. Une contre-indication est toujours associée à un et un seulmédicament.

Tout médicament possède au moins un composant, souvent plusieurs. Un composantest identifié par un code unique et possède un intitulé. Tout composant peut intervenirdans la fabrication de plusieurs médicaments. Il existe des composants qui ne sont pasutilisés pour fabriquer des médicaments et que l'on veut quand même gérer.

Il existe des composants naturels et des composants artificiels. Pour les composantsnaturels, on gère l'espèce végétale qui porte le composant. Pour les composantsartificiels, on gère le nom de la société qui le fabrique.

Exemple de donnéesAfin de matérialiser notre base de données, nous obtenons les descriptions suivantes :

Le Chourix a pour description courte « Médicament contre la chute des choux » et pourdescription longue « Vivamus fermentum semper porta. Nunc diam velit, adipiscing uttristique vitae, sagittis vel odio. Maecenas convallis ullamcorper ultricies. Curabiturornare. ». Il est conditionné en boîte de 13. Ses contre-indications sont :- CI1 : Ne jamais prendre après minuit.- CI2 : Ne jamais mettre en contact avec de l'eau.Ses composants sont le HG79 et le SN50.

Le Tropas a pour description courte « Médicament contre les dysfonctionnementsintellectuels » et pour description longue « Suspendisse lectus leo, consectetur intempor sit amet, placerat quis neque. Etiam luctus porttitor lorem, sed suscipit estrutrum non. ». Il est conditionné en boîte de 42.Ses contre-indications sont :- CI3 : Garder à l'abri de la lumière du soleilSon unique composant est le HG79.

Les composants existants sont :- HG79 : "Vif-argent allégé" ; il s'agit d'un composant naturel extrait de l'edelweiss.- HG81 : "Vif-argent alourdi" ; il s'agit aussi d'un composant naturel extrait de

l'edelweiss.- SN50 : "Pur étain" ; il s'agit d'un composant artificiel fabriqué par Lavoisier et fils

SA.

Q u e s t i o n Réaliser le modèle conceptuel de données en UML du problème.

b) Héritage complet

Définition : Héritage complet et presque completUn héritage est complet si ses classes filles n'ont aucune caractéristiques (attributs, méthodes,associations) propres.


Stéphane Crozat 10

Classe2 Classe3

a {key}b

Classe1

Graphique 1 Héritage complet

Un héritage est presque complet si les classes filles ont des méthodes propres, quelquesattributs propres, et aucune association propre.

c) Héritage exclusif

Définition : Héritage exclusifUn héritage est exclusif si les objets d'une classe fille ne peuvent appartenir aussi à une autreclasse fille. On peut le noter avec la contrainte {X} sur le diagramme UML ({XT} si la classemère est abstraite).

c {key}d

Classe2

e {key}f

Classe3

a {key}b

Classe1

X

Graphique 2 Héritage exclusif

Définition : Héritage non exclusifL'héritage non exclusif est une forme d'héritage qui exprime qu'un objet peut appartenir àdeux classes filles en même temps.

Syntaxe: Notation des héritages exclusifsNormalement la notation UML par défaut désigne un héritage non exclusif.Mais l'héritage exclusif étant plus commun, on conviendra plutôt qu'un schéma UMLqui ne comporte que des héritages non contraints exprime par défaut des héritagesexclusifs.Une note peut être ajoutée précisant que tous les héritages sont exclusifs pour lever touteambiguïté.En revanche un schéma qui comporte explicitement des contraintes sur certains héritages estpas sur d'autres permet effectivement d'exprimer de l'héritage non exclusif.Une dernière possibilité, moins standard, est de marquer d'une contrainte de type {NON X} unhéritage non exclusif.

Méthode : On évitera l'héritage non exclusif pour la conception de BDBien que cette forme d'héritage soit autorisée en modélisation conceptuelle de bases dedonnées et en UML, on évitera de la mobiliser, sauf en cas d'apport vraiment importantd'expressivité, car elle a tendance à complexifier la modalisation, que ce soit au niveau de soninterprétation humaine ou de son implémentation en machine.


Stéphane Crozat 11

Il est toujours possible d'exprimer différemment un héritage non exclusif : en multipliant les classes filles pour les singulariser,

et/ou en utilisant la composition pour factoriser les parties communes.

ComplémentExemple de contraintes standardisées sur les associations

d) Héritage multiple

Définition : Héritage multipleL'héritage multiple est une forme d'héritage qui exprime qu'une classe fille hérite de plusieursclasses mères.

Syntaxe: Notation des héritages multiplesOn conseillera d'ajouter une note lors de l'utilisation d'un héritage multiple, expliquant le choixde modélisation et actant qu'il ne s'agit pas d'une erreur.

Méthode : On évitera l'héritage multiple pour la conception de BDOn évitera d'utiliser l’héritage multiple en modélisation de bases de données, sauf en casd'apport vraiment important d'expressivité.Il est toujours possible de remplacer un héritage multiple par plusieurs héritages simples.

e) Équivalence entre association d'héritage et association 1:1

RemarqueUne association d'héritage est un cas particulier d'association 1:1.Elle ajoute une sémantique de type "est-un".

Exemple


Stéphane Crozat 12

f) Gestion des défauts

[20 minutes]Un groupe industriel construisant des moteurs cherche à organiser la gestion des défautsobservés sur des moteurs confrontés à des tests en situation réelle. Pour cela un de sesingénieurs modélise le processus de gestion des défauts, tel qu'il existe actuellement, par lediagramme de classes suivant.

Image 7 Diagramme de classes de gestion des défauts

Q u e s t i o n 1Décrivez en français ce que représente ce diagramme.

Q u e s t i o n 2Étant donné ce modèle, est-il possible de savoir dans quelle usine a été fabriqué un moteur etqui est responsable de sa production ?

Q u e s t i o n 3

La responsabilité d'un modèle est elle toujours assumée par un employé travaillant dans l'usinedans laquelle ce modèle est produit ?

Q u e s t i o n 4Pourquoi avoir fait le choix d'une classe Type pour codifier les défauts, plutôt qu'un attribut detype énuméré directement dans la classe Defaut ?

Q u e s t i o n 5

Pourquoi l'attribut kilométrage apparaît-il à la fois dans les classes Defaut et Moteur etpourquoi avoir fait apparaître la méthode SetKilometrage ?

Q u e s t i o n 6Ce diagramme permet-il de répondre à la question : Quel est le nombre moyen de défautsrencontrés par les moteurs de chaque modèle ayant été mis en service avant 2000 ? Quellessont les classes et attributs utiles ?


Stéphane Crozat 13

Q u e s t i o n 7Peut-on également répondre à la question : Quel est le kilométrage moyen des moteurs ayantété concernés par au moins deux défauts d'une gravité supérieure à 5 ?

B. Exercices

1. Capitaine Krik

[30 min]Le Capitaine Krik a pour tâche de développer une base de données sur les vaisseaux spatiauxet les équipages de la TarFleet.La flotte ne possède que trois types de vaisseaux : les croiseurs, les frégates et les chasseurs.Chaque membre de la TarFleet a un nom, un prénom, une date de naissance, une planèted'origine et un numéro d'identifiant unique. Certains membres sont aussi soit pilotes, soitcapitaines : les pilotes ont un nombre de chasseurs ennemis abattus, tandis que les capitainesont un certain nombre d'étoiles (entre zéro et cinq).Krik veut savoir dans la base de données quelles personnes sont affectées à quel vaisseau.Dans la flotte, un chasseur a pour équipage un unique pilote, une frégate a deux pilotes et cinqautres membres d'équipage, tandis qu'un croiseur a un capitaine et de nombreux autrespersonnels. Les croiseurs peuvent aussi transporter dans leur hangar plusieurs chasseurs(leurs pilotes ne sont alors pas comptés dans l'équipage du croiseur).Pour chaque vaisseau, on veut connaître son nom et son identifiant, sachant que celui-ci estgénéré automatiquement à partir du nom et du type de vaisseau (par exemple"EnterpriseCruser"). Pour les frégates et les croiseurs, on veut également connaître lapuissance de leur bouclier (les chasseurs n'en sont pas équipés), et, pour un croiseur, lenombre de membres d'équipage maximal qu'il peut accueillir.Krik veut aussi des informations sur les réacteurs de chaque vaisseau. Les réacteurs sont soit àfission nucléaire, soit à trou noir miniature. Chacun a un numéro d'emplacement (qui indiqueoù le moteur est monté sur le vaisseau), un poids et une poussée, mais les réacteurs à fissionont également une quantité maximale de carburant, tandis que les réacteurs à trou noir ontune puissance critique.

Q u e s t i o n

Proposer un schéma UML permettant de modéliser une telle base de données.

2. Armoires secrètes

[20 minutes]Dans le cadre de la réalisation d'une base de données pour les services secrets français, vousdisposez de l'analyse de besoins suivant :

les agents secrets sont identifiés par un code sur 3 chiffres (comme 007) et possède unnom et un prénom ;

les agents secrets produisent des rapports, parfois seul, parfois à plusieurs. Tous lesagents secrets ont produit au moins un rapport ;

les agents secrets sont communément appelés par leurs initiales et leur code : ainsiJames Bond 007 est en général appelé JB007 ;

un rapport est identifié par un titre (il n'existe pas deux rapports avec le même titre) etil possède une description ainsi que des mots-clés (au moins 2, au plus 10) ;


Stéphane Crozat 14

le rangement des rapports est organisé comme suit : les rapports sont situés dans desdossiers, qui sont classés dans des casiers, qui sont rangés sur des étagères, dans desarmoires ;

les dossiers, casiers, étagères et armoires sont des rangements, qui sont identifiés parune lettre et un nombre (inférieur à 100). Chaque rangement a une capacité quidétermine le nombre de rangements qu'il peut contenir ;

il n'existe pas de rapport ou de rangement qui ne serait rangé nulle part.

Q u e s t i o n

Proposez un MCD en UML de ce problème. L'on cherchera le modèle le plus expressifpossible.On fera apparaître les types des attributs, en étant le plus précis possible avec les informationsdont nous disposons, ainsi que les clés.


Stéphane Crozat 15

II - Transformation del'héritage en relationnel

II

A. Cours

1. Les trois représentations de l'héritage en relationnel

Objectifs

Savoir faire le passage d'un schéma conceptuel UML à un schémarelationnel.Connaître les choix possibles pour le cas de l'héritage et savoirfaire les bons choix.

La traduction en relationnel des héritages modélisés au niveau conceptuel peut se faire deplusieurs façons, et le choix demande d'étudier plus en détail la nature de cet héritage.

a) Exercice

Traduire chacun des schémas conceptuels suivants en schéma relationnel.

Stéphane Crozat 16

Q u e s t i o n 1

c {key}d

Classe2

e {key}f

Classe3

a {key}b

Classe1

X

Graphique 3 Héritage exclusif (classe mère abstraite)

Q u e s t i o n 2

Classe2 Classe3

a {key}b

Classe1


Q u e s t i o n 3

c {key}d

Classe2

e {key}f

Classe3

a {key}b

Classe1

0..N0..1

Graphique 5 Héritage non complet

Transformation de l'héritage en relationnel

Stéphane Crozat 17

b) Transformation de la relation d'héritageFondamentalLe modèle relationnel ne permet pas de représenter directement une relationd'héritage, puisque que seuls les concepts de relation et de clé existent dans lemodèle. Il faut donc appauvrir le modèle conceptuel pour qu'il puisse être représentéselon un schéma relationnel.Trois solutions existent pour transformer une relation d'héritage :

Représenter l'héritage par une référence entre la classe mère et la classe fille.

Représenter uniquement les classes filles par une relation chacune.

Représenter uniquement la classe mère par une seule relation.

c {key}d

Classe2

e {key}f

Classe3

a {key}b

Classe1

Graphique 6 Héritage

MéthodeEn pratique le choix entre ces trois solutions va dépendre de l'étude détaillée de l'héritage :

L'héritage est-il complet ?

La classe mère est-elle abstraite ?

Quelles sont les associations qui lient la classe mère et les classes filles à d'autresclasses ?

RappelClasse abstraiteHéritage complet

c) Transformation de la relation d'héritage par référence

Méthode Chaque classe, mère ou fille, est représentée par une relation.

La clé primaire de la classe mère est utilisée pour identifier chacune de ses classesfilles : cette clé étant pour chaque classe fille à la fois la clé primaire et une cléétrangère vers la classe mère.


Stéphane Crozat 18

c {key}d

Classe2

e {key}f

Classe3

a {key}b

Classe1


Classe1(#a,b)

Classe2(#a=>Classe1,c,d) avec c KEY

Classe3(#a=>Classe1,e,f) avec e KEY

RemarqueSi une classe fille a une clé primaire définie dans le modèle conceptuel, cette clé n'est pasretenue pour être la clé primaire dans le modèle relationnel, étant donné que c'est la cléétrangère référence à la classe mère qui est retenue.

RemarqueLa cardinalité d'un lien entre une classe fille et une classe mère est (1,1):(0,1) : En effet touteinstance fille référence obligatoirement une et une seule instance mère (pas d'héritagemultiple) et toute instance mère est référencée une ou zéro fois (zéro fois si un objet peut êtredirectement du type de la classe mère) par chaque instance fille.

ComplémentHéritage par une référence et vues

d) Transformation de la relation d'héritage par les classes filles

Méthode Chaque classe fille est représentée par une relation, la classe mère n'est pas

représentée (si elle est abstraite). Tous les attributs de la classe mère sont répétés au niveau de chaque classe fille.

La clé primaire de la classe mère est utilisée pour identifier chacune de ses classesfilles.

c {key}d

Classe2

e {key}f

Classe3

a {key}b

Classe1

Graphique 8 Héritage (classe mère abstraite)

Classe2(#a,b,c,d) avec c KEY Classe3(#a,b,e,f) avec e KEY


Stéphane Crozat 19

RemarqueSi une classe fille a une clé primaire au niveau du MCD, cette clé n'est pas retenue, et c'estbien la clé héritée de la classe mère qui devient la clé primaire (mais elle est bien entendumaintenue comme clé candidate).

Complément : Héritage exclusifCette solution est adaptée dans le cas d'un héritage exclusif, c'est à dire si aucun objet d'uneclasse fille n'appartient aussi à une autre classe fille. Dans le cas contraire, le problème est quedes redondances vont être introduites puisqu'un même tuple devra être répété pour chaqueclasse fille à laquelle il appartient.

ComplémentHéritage par les classes filles et vues

e) Transformation de la relation d'héritage par la classe mère

Méthode Seule la classe mère est représentée par une relation (ses classes filles ne sont pas

représentées par des relations). Tous les attributs de chaque classe fille sont réintégrés au niveau de la classe mère.

La clé primaire de la classe mère est utilisée pour identifier la relation.

Un attribut supplémentaire de discrimination t (pour "type"), est ajouté à la classemère, afin de distinguer les tuples. Cet attribut est de type énumération et a pour valeurs possibles les noms de la classemère ou des différents classes filles.

c {key}d

Classe2

e {key}f

Classe3

a {key}b

Classe1


Classe1(#a,b,c,d,e,f,t:{1,2,3}) avec c UNIQUE et e UNIQUE

RemarqueSi une classe fille a une clé primaire propre, cette clé sera réintégrée à la classe mère, aumême titre qu'un autre attribut, mais elle n'officiera pas en tant que clé candidate car ellepourra contenir des valeurs nulles (elle sera néanmoins unique).

Conseil : Classe mère non abstraiteCette solution est particulièrement adaptée lorsque la classe mère n'est pas abstraite, car celaen autorise l'instanciation naturellement. Lorsque la classe mère est abstraite il est moinsnaturel de disposer d'une table associée à cette classe.

Conseil : Héritage completCette solution est optimum dans le cas d'un héritage complet, c'est à dire si les classes fillesne définissent pas d'attributs autre que ceux hérités. Dans le cas contraire cela engendre desvaleurs null.


Stéphane Crozat 20

En pratique l'héritage complet est rare, mais nombre d'héritages le sont presque et pourrontalors être raisonnablement gérés selon cette approche, a fortiori si la classe mère n'est pasabstraite.

Complément : Héritage non exclusifafin de gérer l'héritage non exclusif (un objet peut être de plusieurs classes filles à la fois), ledomaine de l'attribut de discrimination, peut être étendu à des combinaisons de noms desdifférentes classes filles. Classe1(#a,b,c,d,e,f,t:{1,2,3,23})

Complément : Représentation de la discrimination par des booléensSi l'héritage concerne un nombre élevé de classes filles et qu'il est principalement non exclusifalors le domaine de l'attribut de discrimination peut impliquer une combinatoire importante devaleurs. Pour contourner cette lourdeur il est possible d'utiliser, en remplacement, un attributde domaine booléen pour chaque classe fille spécifiant si un tuple est un objet de cette classe. Dans cette configuration la classe mère sera logiquement considérée comme non abstraite etun objet appartiendra à la classe mère si tous ses attributs de discrimination valent "faux".Seule une contrainte dynamique permettra de définir la classe mère comme abstraite, enprécisant que les attributs de discrimination ne peuvent être tous à "faux".Classe1(#a,b,c,d,e,f,t:{1,2,3,23})

équivaut à :Classe1(#a,b,c,d,e,f,t2:boolean:,t3:boolean)

ComplémentHéritage par la classe mère et vues

2. Choisir la meilleure modélisation de l'héritage en relationnel

a) Éléments de choix

Méthode : Choisir le bon mode de transformation d'une relation d'héritageLa difficulté consiste donc pour chaque relation d'héritage à choisir le bon mode detransformation, sachant que chaque solution possède ses avantages et ses inconvénients.

Inconvénients Cas d'usage

Par référence Lourdeur liée à la nécessité dereprésenter les données desclasses filles sur deux relations

Adapté à tous les cas,particulièrement lorsque laclasse mère n'est pasabstraite

Par les classesfilles

Les associations avec la classemère peuvent êtreproblématiques ; redondancedans le cas de l'héritage nonexclusif

Adapté à l'héritage exclusif,particulièrement lorsque laclasse mère est abstraite etne comporte pas d'association

Par la classemère

Nullité systématique pour lesattributs des classes filles (et pourla classe mère si celle-ci n'est pasabstraite) ; héritage non exclusifet non complet problématique

Adapté à l'héritage complet etpresque complet,particulièrement lorsque laclasse mère n'est pasabstraite


Stéphane Crozat 21

Par référence

Par les classes filles

Par la classe mère

Classe mère abstraite

Classe mère non abstraite

Héritage exclusif

Héritage non exclusif

Héritage complet

Héritage presque complet

Héritage non complet

Association classe mère

Tableau 1 Choix de la bonne transformation

ComplémentClasses abstraitesHéritage completHéritage exclusif

b) Cas simples

Méthode : Héritage completDans ce cas, choisir un héritage par la classe mère.

Classe2 Classe3

a {key}b

Classe1


1. Si la classe mère est abstraite :Classe1(#a,b,t:{2,3})

2. Si la classe mère n'est pas abstraite :Classe1(#a,b,t:{1,2,3})

Méthode : Héritage non complet avec classe mère abstraite et sans associationDans ce cas, choisir un héritage par les classes filles.


Stéphane Crozat 22

c {key}d

Classe2

e {key}f

Classe3

a {key}b

Classe1

X

Graphique 11 Héritage exclusif (classe mère abstraite)

Classe2(#a,b,c,d) avec c KEY

Classe3(#a,b,e,f) avec e KEY

Méthode : Héritage presque completL'héritage presque complet peut être géré comme l'héritage complet, par la classe mère,surtout si les classes filles ne possèdent pas de clé propre.

c {key}d

Classe2

e {key}f

Classe3

a {key}b

Classe1

g {key}h

Classe4

assoc

N

Graphique 12 Héritage avec association X:N vers la classe mère

Classe1(#a,b,c,d,e,f,t:{1,2,3})

Classe4(#g,h,fka=>Classe1)

Méthode : Héritage non complet avec classe mère non abstraite et sans associationDans ce cas, choisir un héritage par les classes filles.


Stéphane Crozat 23

c {key}d

Classe2

e {key}f

Classe3

a {key}b

Classe1

0..N0..1

Graphique 13 Héritage non complet

Classe1(#a,b) Classe2(#a,b,c,d) avec c KEY

Classe3(#a,b,e,f,fka=>Classe2) avec e KEY

c) Cas problématiques

Attention : Héritage par les classes filles avec association X:N vers la classe mère

c {key}d

Classe2

e {key}f

Classe3

a {key}b

Classe1

g {key}h

Classe4

assoc

N

Héritage avec association X:N vers la classe mère


Classe3(#a,b,e,f) avec e KEY

Classe4(#g,h,fka=>Classe2, fkb=>Classe3)

Contraintes : fka OR fkb

La seule solution, peu élégante, consiste à ajouter autant de clés étrangères que declasses filles et à gérer le fait que ces clés ne peuvent pas être co-valuées. Cettesolution devient ingérable si le nombre de classes filles augmente.


Stéphane Crozat 24

Attention : Héritage non complet par la classe mère

c {key}d

Classe2

e {key}f

Classe3

a {key}b

Classe1

g {key}h

Classe4

assoc

N


Classe1(#a,b,c,d,e,f,t:{1,2,3})

Classe4(#g,h,fka=>Classe1)

Contraintes : fka ne référence que des enregistrements tels que t=3

On est obligé d'ajouter une contrainte pour limiter la portée de la clé étrangère deClasse4 ; on est sorti ici de ce que l'on sait faire de façon simple en relationnel.

Attention : Héritage non complet par la classe mère (association entre classes filles)

c {key}d

Classe2

e {key}f

Classe3

a {key}b

Classe1

0..N0..1


Classe1(#a,b,c,d,e,f,fka=>Classe1,t:{1,2,3})

Contraintes : fka ne référence que des enregistrements tels que t=3 ; si fkaalors t=2

Dans ce cas la solution est encore plus problématique, elle permettra en l'état desassociations entre Classe1 et Classe3, et même entre Classe3 et Classe3, on est trèsloin de la modélisation conceptuelle initiale.

ConseilAfin de déterminer si un héritage est presque complet ou non, il faut donc surtout regarder lesassociations, ce sont elles qui poseront le plus de problème un fois en relationnel (à cause del'intégrité référentielle).


Stéphane Crozat 25

Complément : Héritage non exclusifL'héritage non exclusif ne doit pas être traité par les classes filles, sous peine d'introduire de laredondance.

Complément : Héritage multipleL'héritage multiple sera généralement mieux géré avec un héritage par référence.

ComplémentHéritage completClasses abstraites

d) Exemple de transformation d'une relation d'héritage

ExempleSoit le modèle UML suivant :

Image 8 Représentation de documents

Il existe trois façons de traduire la relation d'héritage : par référence, par absorption par lesclasses filles, par absorption par la classe mère.

Remarque : Type d'héritage 1. L'héritage n'est pas complet, puisque l'on observe que les thèses et les livres ont des

attributs qui ne sont pas communs (la discipline pour la thèse et l'éditeur pour le livre).Mais l'on peut considérer qu'il est presque complet, car il n'y a qu'un attribut parclasse fille de différence et pas d'association associée aux classes filles.

2. La classe mère est abstraite, on ne gère que des livre ou des thèses, pas d'autresdocuments.

La meilleure solution est donc ici un héritage par les classes filles, mais un héritage par laclasse mère reste un bon choix. En revanche l'héritage par référence est un mauvais choix, caril conduit à une solution inutilement complexe.Observons néanmoins les avantages et inconvénients que chacun des trois choix porterait.

i Héritage représenté par une référence

1 Document(#Titre:Chaîne, Auteur:Chaîne) avec Document AND (These OR Livre)2 These(#Titre=>Document, Discipline:Chaîne)3 Livre(#Titre=>Document, Editeur:Chaîne)4

Complément

12 vThese = Jointure (Document, These, Document.Titre=These.Titre)3 vLivre = Jointure (Document, Livre, Document.Titre=Livre.Titre)


Stéphane Crozat 26

4 Contraintes : PROJ(Document,Titre) IN (PROJ(These,Titre) UNION PROJ(Livre,Titre))

Remarque : Avantages du choixIl n'y a ni redondance ni valeur nulle inutile dans les relations These et Livre.

Remarque : Inconvénients du choix Il est relativement lourd de devoir créer un tuple dans Document pour chaque tuple

dans These ou Livre, alors que la relation Document ce porte que l'informationconcernant l'auteur, juste pour assurer les cas, par ailleurs plutôt rare dans la réalité,où les thèses sont publiées sous forme de livres.

De plus la classe Document étant abstraite, il ne devra jamais y avoir de tuple dansdocument qui n'a pas de tuple correspondant dans Livre ou These. Ceci n'est pascontrôlable directement en relationnel et devra donc être vérifié au niveau applicatif (oubien la classe ne devra plus être considérée comme abstraite).

ii Héritage absorbé par les classes filles

1 These(#Titre, Discipline:Chaîne, Auteur:Chaîne)2 Livre(#Titre, Editeur:Chaîne, Auteur:Chaîne)

Remarque : Avantages du choixIl est plus simple que le précédent, puisque la représentation d'une thèse ou d'un livre nenécessite plus que d'ajouter un seul tuple. Il évite donc les clés étrangères, toujours plusdélicates à gérer d'un point de vue applicatif.

Remarque : Inconvénient du choixSi l'héritage est exclusif ce modèle n'a aucun inconvénient.Si l'héritage n'est pas exclusif et qu'une thèse est aussi un livre, alors une information seradupliquée (l'auteur), ce qui introduit de la redondance.

iii Héritage absorbé par la classe mère

1 Document(#Titre, Discipline:Chaîne, Editeur:Chaîne, Auteur:Chaîne, Type:{These|Livre})

2

Complément

12 vThese = Projection (Restriction (Document, Type='These'), Titre, Discipline,

Auteur)3 vLivre = Projection (Restriction (Document, Type='Livre'), Titre, Editeur,

Auteur)

Remarque : Avantages du choixIl est plus simple que le premier, puisque la représentation d'une thèse ou d'un livre nenécessite plus que d'ajouter un seul tuple. Il évite donc les clés étrangères..

Remarque : Inconvénient du choix Les tuples de Document contiendront systématiquement une valeur nulle soit pour

l'éditeur soit pour la discipline. Il faut vérifier l'adéquation entre la valeur de Type et le fait que Discipline ou Auteur

n'est pas valué.


Stéphane Crozat 27

Si l'héritage est exclusif (ce qui est le cas par défaut), alors les tuples de la relationDocument contiendront systématiquement une valeur nulle soit pour l'éditeur soit pourla discipline.

Il faudra pour être rigoureux vérifier l'adéquation entre la valeur de Type et le fait queDiscipline ou Auteur n'est pas valué (si Type='These' alors Editeur=Null et siType='Livre' alors Discipline=Null ).

B. Exercices

1. Lab II+

[30 min]


Un médicament est décrit par un nom, qui permet de l'identifier. En effet il n'existe pasdeux médicaments avec le même nom. Un médicament comporte une descriptioncourte en français, ainsi qu'une description longue en latin. On gère aussi leconditionnement du médicament, c'est à dire le nombre de pilules par boîte (qui est unnombre entier).

À chaque médicament on associe une liste de contre-indications, généralementplusieurs, parfois aucune. Une contre-indication comporte un code unique qui l’identifie,ainsi qu'une description. Une contre-indication est toujours associée à un et un seulmédicament.


Il existe des composants naturels et des composants artificiels. Pour les composantsnaturels, on gère l'espèce végétale qui porte le composant. Pour les composantsartificiels, on gère le nom de la société qui le fabrique.

Exemple de donnéesAfin de matérialiser notre base de données, nous obtenons les descriptions suivantes :

Le Chourix a pour description courte « Médicament contre la chute des choux » et pourdescription longue « Vivamus fermentum semper porta. Nunc diam velit, adipiscing uttristique vitae, sagittis vel odio. Maecenas convallis ullamcorper ultricies. Curabiturornare. ». Il est conditionné en boîte de 13. Ses contre-indications sont :- CI1 : Ne jamais prendre après minuit.- CI2 : Ne jamais mettre en contact avec de l'eau.Ses composants sont le HG79 et le SN50.

Le Tropas a pour description courte « Médicament contre les dysfonctionnementsintellectuels » et pour description longue « Suspendisse lectus leo, consectetur intempor sit amet, placerat quis neque. Etiam luctus porttitor lorem, sed suscipit estrutrum non. ». Il est conditionné en boîte de 42.Ses contre-indications sont :- CI3 : Garder à l'abri de la lumière du soleilSon unique composant est le HG79.


Stéphane Crozat 28

Les composants existants sont :- HG79 : "Vif-argent allégé" ; il s'agit d'un composant naturel extrait de l'edelweiss.- HG81 : "Vif-argent alourdi" ; il s'agit aussi d'un composant naturel extrait de

l'edelweiss.- SN50 : "Pur étain" ; il s'agit d'un composant artificiel fabriqué par Lavoisier et fils

SA.

Q u e s t i o n 1Réaliser le modèle conceptuel de données en UML du problème.

Q u e s t i o n 2En mobilisant les règles adéquates, proposer un modèle logique de données correspondant enrelationnel. Le repérage des domaines et des clés est obligatoire.

Q u e s t i o n 3

Dessiner des tableaux remplis avec les données fournies en exemple, afin de montrer que lemodèle fonctionne selon le besoin exprimé initialement. On pourra mettre le premier motseulement des descriptions pour gagner du temps.

2. Literie

[20 min]Un revendeur de matelas et de sommier a besoin de créer une base de données, afin degénérer son catalogue des produits. Pour cela, il fait appel à vous, afin de concevoir une basede données qui puisse prendre en compte ses besoins. Voici des extraits du document quiretrace les besoins, rédigé par le client :« Le fonctionnement actuel est relativement simple, nous souhaitons juste l'automatiser pouréviter les erreurs et les pertes de temps. Nous avons des types de produits, qui sont desmatelas ou des sommiers. Chaque type de produit est caractérisé par des références uniquesque nous créons en plus du nom posé par le fabricant (ce nom reprend parfois un plus anciend'un concurrent) ; nous ajoutons souvent une description textuelle et précisons toujours lacouleur. »« Un type de produit est toujours lié à un fabricant, caractérisé par son nom (sa marque), etnous avons toujours au minimum une adresse et un numéro de téléphone. Un type de matelasa en plus une épaisseur, nécessaire pour l'ajouter dans les catalogues et les publicités. Unmatelas est aussi catégorisé en fonction du matériau utilisé : ressort, latex ou mousse. Untype de sommier possède toujours une hauteur. »« Chaque type de produit est proposé en une ou plusieurs dimensions (longueur et largeur, quisont souvent des dimensions standardisées). »

Diagramme UMLUn stagiaire a déjà proposé le diagramme UML ci-après.


Stéphane Crozat 29

Literie

Q u e s t i o n 1Vérifiez que le diagramme est correct par rapport à l'énoncé.

Q u e s t i o n 2Proposez un modèle relationnel à partir de l'UML de la question précédente

3. Parc informatique

[30 minutes]Vous avez en charge la réalisation d'un modèle de base de données pour la gestion d'un parcinformatique.L'analyse des besoins révèlent les informations suivantes : tout matériel informatique estidentifié de façon unique par un numéro de série et est décrit par une désignation. Il existetrois types de matériel informatique distincts : les PC, les serveurs et les imprimantes. Pour lesPC, les informations que l'on veut gérer sont la taille de la mémoire vive et la cadence dumicro-processeur, pour les serveurs on veut gérer leur volume de disque dur et pour lesimprimantes leur résolution maximale d'impression. On veut également gérer les connexions au réseau sachant que tout PC peut être relié à un ouplusieurs serveurs et que chaque serveur sert bien entendu plusieurs PC ; et qu'un PC peutêtre relié à une imprimante, qui est également utilisée par plusieurs PC.

Q u e s t i o n 1

Réaliser le modèle conceptuel UML de ce problème.

Q u e s t i o n 2

Réalisez le passage au modèle logique relationnel.


Stéphane Crozat 30

III - Modélisation avancée des associations en UML et en relationnel

III

A. Cours

1. Modélisation avancée des associations en UML

Objectifs

Maîtriser le diagramme de classe UML dans le cas de la conceptionde BD.

a) Exercice : Entreprise

En analysant le schéma UML ci-après, sélectionner toutes les assertions vraies.

Image 9 MCD UML

Stéphane Crozat 31

Une association peut employer un directeur.

Une association peut employer plusieurs directeurs.

Une association peut ne pas employer de directeur.

Une filiale peut appartenir à plusieurs entreprises.

Il existe des organisations qui ne sont ni des entreprises ni des associations.

b) Composition

Définition : Association de compositionOn appelle composition une association particulière qui possède les propriétés suivantes :

La composition associe une classe composite et des classes parties, tel que tout objetpartie appartient à un et un seul objet composite. C'est donc une association 1:N (voire1:1).

La composition n'est pas partageable, donc un objet partie ne peut appartenir qu'à unseul objet composite à la fois.

Le cycle de vie des objets parties est lié à celui de l'objet composite, donc un objetpartie disparaît quand l'objet composite auquel il est associé disparaît.

Remarque La composition est une association particulière (binaire de cardinalité contrainte).

La composition n'est pas symétrique, une classe joue le rôle de conteneur pour lesclasses liées, elle prend donc un rôle particulier a priori.

La composition est une agrégation avec des contraintes supplémentaires (nonpartageabilité et cycle de vie lié).

Syntaxe: Notation d'une composition en UML

Image 10 Notation de la composition en UML

Attention : Composition et cardinalitéLa cardinalité côté composite est toujours de exactement 1.Côté partie la cardinalité est libre, elle peut être 0..1, 1, * ou bien 1..*.

Exemple : Exemple de composition

Image 11 Un livre

Modélisation avancée des associations en UML et en relationnel

Stéphane Crozat 32

On voit bien ici qu'un chapitre n'a de sens que faisant partie d'un livre, qu'il ne peut existerdans deux livres différents et que si le livre n'existe plus, les chapitres le composant non plus.

Remarque : Composition et entités faiblesLa composition permet d'exprimer une association analogue à celle qui relie une entité faible àune entité identifiante en modélisation E-A. L'entité de type faible correspond à un objetpartie et l'entité identifiante à un objet composite.

Conseil : Composition et attribut multivalué Une composition avec une classe partie dotée d'un seul attribut peut s'écrire avec un

attribut multivalué. Un attribut composé et multivalué peut s'écrire avec une composition.

Rappel : Voir aussi Attributs

Agrégation

c) Agrégation

Définition : Association d'agrégationL'agrégation est une association particulière utilisée pour préciser une relation tout/partie (ouensemble/élément), on parle d'association méréologique.Elle possède la propriété suivante : L'agrégation associe une classe agrégat et des classesparties, tel que tout objet partie appartient à au moins un objet agrégat.

Remarque L'agrégation est une association particulière (binaire de cardinalité libre).

L'agrégation n'est pas symétrique.

Syntaxe

Image 12 Notation de l'agrégation en UML

La cardinalité, peut être exprimée librement, en particulier les instances de la classe Élémentpeuvent être associées à plusieurs instances de la classe Ensemble, et même de plusieursclasses.

AttentionL'agrégation garde toutes les propriétés d'une association classique (cardinalité,cycle de vie, etc.), elle ajoute simplement une terminologie un plus précise via lanotion de tout/partie.

d) Explicitation des associations

Syntaxe: Sens de lectureIl est possible d'ajouter le sens de lecture du verbe caractérisant l'association sur undiagramme de classe UML, afin d'en faciliter la lecture. On ajoute pour cela un signe < ou > (ouun triangle noir) à côté du nom de l'association


Stéphane Crozat 33

Syntaxe: RôleIl est possible de préciser le rôle joué par une ou plusieurs des classes composant uneassociation afin d'en faciliter la compréhension. On ajoute pour cela ce rôle à côté de la classeconcernée (parfois dans un petit encadré collé au trait de l'association.

Exemple

Image 13 Rôle et sens de lecture sur une association

Définition : Association réflexiveUne association réflexive est une association qui associe une classe avec elle-même. L'explicitation des associations est particulièrement utile dans le cas des associationsréflexives.

e) Classe d'association avec clé locale

RappelClasse d'association

Contrainte inhérente à la relation N:MDans l'exemple suivant, chaque personne peut avoir un emploi dans plusieurs sociétés, maiselle ne peut pas avoir plusieurs emplois dans une même société.

Image 14 Emplois

La transformation en relationnelle est cohérente avec cette contrainte.

1 Société(...)2 Personne(...)3 Emploi(#personne=>Personne, #societe=>Societe, poste:string, salaire:integer,

quotite:numeric(1,2))

#personne #societe poste salaire quotiteAl Canonical Directeur 100000 0,5Al Canonical Développeur 50000 0,5


Stéphane Crozat 34

Méthode : Intérêt de la clé localeLa spécification d'une clé locale dans emploi, par exemple ici le poste, permet de lever cettecontrainte, lorsqu'on le souhaite, en permettant d'identifier chaque instance de l'association, icil'emploi d'une personne par sa société.

La transformation en relationnelle permettra de maintenir la modélisation, en ajoutant la clélocale à la clé initiale

1 Société(...)2 Personne(...)3 Emploi(#personne=>Personne, #societe=>Societe, #poste:string, salaire:integer,

quotite:numeric(7,2))

#personne #societe #poste salaire quotiteAl Canonical Directeur 100000 0,5Al Canonical Développeur 50000 0,5

f) Associations ternaires

Syntaxe

Image 15 Notation d'une association ternaire


Stéphane Crozat 35

Conseil : Ne pas abuser des associations ternairesIl est toujours possible de réécrire une association ternaire avec trois associations binaires, entransformant l'association en classe.

Conseil : Pas de degré supérieur à 3En pratique on n'utilise jamais en UML d'association de degré supérieur à 3.

2. Passage UML-Relationnel : Associations avancées

Objectifs

Savoir faire le passage d'un schéma conceptuel UML à un schémarelationnel dans tous les cas.Reconnaître les cas de transformation qui se traitent toujours dela même façon et ceux qui nécessite une modélisationcomplémentaire.

a) Composition et agrégation

Q u e s t i o n


a {key}b

Classe1

c {local key}d

Classe2

0..N

Graphique 14 Composition

a {key}b

Classe1

c {key}d

Classe2

0..N0..1

Graphique 15 Agrégation 1:N

a {key}b

Classe1

c {key}d

Classe2

0..N0..N

Graphique 16 Agrégation N:M

b) Classe d'association

Q u e s t i o n



Stéphane Crozat 36

a {key}b

Classe1

c {key}d

Classe2

1 1..N

e {local key}f

Cl-Assoc

Graphique 17 Classe d'association (1:N)

a {key}b

Classe1

c {key}d

Classe2

1..N 1..N

e {key}f

Cl-Assoc

Graphique 18 Classe assocation (N:M)

c) Transformation des compositions

MéthodeUne composition

est transformée comme une association 1:N,

puis on ajoute à la clé de la classe partie (dite clé locale) la clé étrangère vers la classecomposite pour construire une clé primaire composée.

a {key}b

Classe1

c {local key}d

Classe2

0..N

Graphique 19 Composition

Classe1(#a,b)

Classe2(#c,#a=>Classe1,d)

Remarque : Clé localePour identifier une classe partie dans une composition, on utilise une clé locale concaténée à laclé étrangère vers la classe composite, afin d'exprimer la dépendance entre les deux classes. Si une clé naturelle globale permet d'identifier de façon unique une partie indépendamment dutout, on préférera la conserver comme clé candidate plutôt que de la prendre pour cléprimaire. Si on la choisit comme clé primaire cela revient à avoir transformé la composition enagrégation, en redonnant une vie propre aux objets composants.

Complément : Composition et entités faibles en E-AUne composition est transformée selon les mêmes principes qu'une entité faible en E-A.


Stéphane Crozat 37

Complément : Attributs multivalués et composésLa transformation d'un attribut composé multivalué donne un résultat équivalent à latransformation d'une composition.

a {key}

Classe1

b1b2

RB

0..N a {key}b [0..N] -b1 -b2

Classe1

{(b1,b2) local key}

Graphique 20 Composition et attribut composé multivalué

Classe1(#a)

RB(#b_b1,#b_b2,#a=>Classe1)

La transformation d'une composition avec un seul attribut pour la classe composante donne unrésultat équivalent à la transformation d'un attribut multivalué.

a {key}

Classe1

b {local key}

RB

0..N a {key}b[1..N]

Classe1

Graphique 21 Composition et attribut multivalué

Classe1(#a)

RB(#b,#a=>Classe1)

Rappel : Voir aussiTransformation des attributs

d) Transformation des agrégations

Rappel : AgrégationLes associations de type agrégation se traitent de la même façon que les associationsclassiques.

a {key}b

Classe1

c {key}d

Classe2

0..N0..1

Graphique 22 Agrégation 1:N

Classe1(#a,b)

Classe2(#c,d,a=>Classe1)

a {key}b

Classe1

c {key}d

Classe2

0..N0..N

Graphique 23 Agrégation N:M

Classe1(#a,b)


Stéphane Crozat 38

Classe2(#c,d)

Assoc(#a=>Classe1,#c=>Classe2)

e) Transformation des classes d'association avec clé locale

Méthode : Classe d'association N:MLes attributs de la classe d'association,

sont ajoutés à la relation issue de l'association N:M ;

la clé locale de la classe d'association est concaténée aux clés étrangères composantdéjà la clé primaire de la relation d'association.

a {key}b

Classe1

c {key}d

Classe2

0..N 0..N

e {key}f

Cl-Assoc


Classe1(#a,b)

Classe2(#c,d)

Assoc(#a=>Classe1,#c=>Classe2,#e,f)

Méthode : Classe d'association 1:NLes attributs de la classe d'association,

sont ajoutés à la relation issue de la classe côté N ;

la clé locale devient un clé candidate.

a {key}b

Classe1

c {key}d

Classe2

0..1 0..N

e {key}f

Cl-Assoc


Classe1(#a,b) Classe2(#c,d,a=>Classe1, e, f) avec e KEY


Stéphane Crozat 39

f) Correspondance entre UML et relationnel

Modèle UML Modèle relationnel

Classe instanciable Relation

Classe abstraite Rien

Objet Nuplet

Attribut simple Attribut atomique

Attribut composite Ensemble d'attributs

Attribut multivalué Relation et clé étrangère

Attribut dérivé Procédure stockée ou contrainte dynamique

Méthode Procédure stockée

Association 1:N Clé étrangère

Association N:M Relation et clé étrangère

Association de degré 3 ou supérieur Relation et clé étrangère

Classe d'association Attributs

Composition Clé

Tableau 2 Passsage UML vers Relationnel

g) Exercice

Quel(s) schéma(s) relationnel(s) corresponde(nt) au modèle UML suivant ?

Image 16 Volley ball


Stéphane Crozat 40

Joueur(#Numero, Nom, Ville=>Ville)Equipe(#Nom, Joueur=>Joueur, Poste, Rencontre=>Equipe, Score, Ville=>Ville)Vile(#CodePostal, Nom)

Joueur(#Numero, #Equipe=>Equipe, Nom, Poste, Ville=>Ville) Equipe(#Nom, Ville=>Ville) Ville(#CodePostal, Nom)Rencontre(#Equipe1=>Equipe, #Equipe2=>Equipe, Score)

Joueur(#Numero, Nom, Ville=>Ville) Equipe(#Nom, Joueur=>Joueur, Poste, Ville=>Ville) Ville(#CodePostal, Nom) Rencontre(#Equipe1=>Equipe, #Equipe2=>Equipe, Score)

Joueur(#Numero, Nom) Equipe(#Nom) Ville(#CodePostal, Nom) Habite(#Numero=>Joueur, #CodePostal=>Ville) Joue(#Numero=>Joueur, #Nom=>Equipe, Poste)EstSituee(#Nom=>Equipe, #CodePostal=>Ville) Rencontre(#NomE1=>Equipe, #NomE2=>Equipe, Score)

h) Exercice

Soit le schéma UML suivant :

Image 17 Villes

Quelles sont les modèles relationnels qui correspondent à ce modèle conceptuel ?


Stéphane Crozat 41

Pays(#Nom, Capitale=>Ville) Region(#Nom, Prefecture=>Ville, Pays=>Pays) Departement(#Nom, Region=>Region) Ville(#Nom, Departement=>Departement)

Pays(#Nom, Capitale=>Ville)Region(#Nom, Prefecture=>Ville, Pays=>Pays) Departement(#Nom, Region=>Region, Pays=>Pays) Ville(#Nom, Departement=>Departement, Region=>Region, Pays=>Pays)

Pays(#Nom) Region(#Nom, Pays=>Pays) Departement(#Nom, Region=>Region) Ville(#Nom, Departement=>Departement, Capitale=>Pays, Prefecture=>Region)

Pays(#Nom, Capitale=>Ville) Region(#Nom, #Pays=>Pays, Prefecture=>Ville) Departement(#Nom, #Region=>Region) Ville(#Nom, #Departement=>Departement)

Pays(#Nom, CapitaleVille=>Ville, CapitaleDepartement=>Ville, CapitaleRegion=>Ville,CapitalePays=>Ville) Region(#Nom, #Pays=>Pays, PrefectureVille=>Ville, PrefectureDepartement=>Ville,PrefectureRegion=>Ville, PrefecturePays=>Ville) Departement(#Nom, #Region=>Region, #Pays=>Region)Ville(#Nom, #Departement=>Departement, #Region=>Departement,#Pays=>Departement)

3. Synthèse sur la modalisation UML et relationnelle

a) Quelques éléments de stylistique UML

Attention Toutes les associations doivent être nommées (sauf composition, héritage,

agrégation). Ne pas utiliser de nom générique pour les Classes comme "Entité", "Classe",

"Objet", "Truc"... Éviter les noms génériques pour les associations (comme "est associé à")

Attention au sens des compositions et agrégation, le losange est côtéensemble, et n'oubliez pas les cardinalités, notamment côté parties.

Conseil N'utilisez pas le souligné ni les # en UML pour identifier les clés, préférez la contrainte

{key} Préférez l'héritage aux booléens de typage en UML

Les attributs dérivés sont réservés aux dérivations simples (des attributs de la mêmeclasse), si c'est plus complexe, préférez des méthodes (et dans le doute, précisez lesmodes de calcul sur le schéma ou dans une note à part)

Donnez des exemples de contenu lorsque ce n'est pas évident (lorsque le couple nomd'attribut et type ne permet pas de façon évidente de comprendre de quoi l'on parle)


Stéphane Crozat 42

Inutile de déclarer le type booléen en UML, utilisez-le directement comme un type dedonnées connu

Complément Si tous vos héritages sont exclusifs, notez-le à part pour alléger votre schéma (et éviter

l'abondance de XOR)

b) Bibliographie commentée sur la modélisation UML

Complément : Outils de modélisation UMLIl existe de nombreux outils de modélisation UML. On pourra citer :

Dia [w_dia] : logiciel Open Source et multi-plateformes facile d'usage (qui marchenéanmoins mieux sur Linux que sur Windows).

Objecteering [w_objecteering] (version gratuite).

À voir également en Open Source : ArgoUML1 ou EclipseUML.2 (non testé par l'auteur).

Complément : Modélisation UMLUML2 en action [Roques04] Pour un aperçu plus détaillé des possibilités d'expression du diagramme de classe UML, lire lechapitre 7 : Développement du modèle statique (pages 133 à 163). On pourra notamment y trouver :

L'association d'agrégation

Les propriétés d'association

L'expression de rôles dans les associations

Les attributs de classe

Les qualificatifs

Les opérations (ou méthodes)

Le chapitre donne de plus des conseils méthodologiques pour la conception (voir en particulierla synthèse page 163).On pourra également y trouver :

Des principes de choix de modélisation entre attributs et classes et sur la segmentationdes classes

Des principes de sélection des attributs (redondance avec les associations, avec lesclasses, etc.)

Des principes de sélection des associations

Des principes de choix de cardinalité (notamment pour la gestion d'historisation)

Des principes de sélection des relations de généralisation (héritage)

Des principes d'introduction de métaclasses (type)s

Complément : Référence UML en ligneUML en Français [w_uml.free.fr] Une très bonne référence en ligne sur la modélisation UML, avec des cours, des liens vers lanorme, etc.Le contenu dépasse très largement l'usage d'UML pour la modélisation de BD (et ne faitd'ailleurs pas de référence précise à ce sous-ensemble particulier).

1 - http://argouml.tigris.org/2 - http://www.eclipsedownload.com/


Stéphane Crozat 43

http://www.eclipsedownload.com/

http://argouml.tigris.org/

On pourra consulter en particulier le chapitre sur les diagrammes de classe :http://uml.free.fr/cours/i-p14.html3

Complément : Tutoriel sur la modélisation UML.UML en 5 étapes [w_journaldunet.com(1)] On consultera en particulier le tutoriel sur les diagrammes de classe :http://developpeur.journaldunet.com/tutoriel/cpt/010607cpt_umlintro.shtml4

Complément : ConseilsCinq petits conseils pour un schéma UML efficace [w_journaldunet.com(2)]

Complément : PratiqueUML2 par la pratique [Roques09] (chapitre 3)Des explications, exemples et études de cas.

c) Synthèse : Les diagrammes de modélisation conceptuelle

Un modèle conceptuel peut être représenté sous forme de diagramme E-A ou sous forme dediagramme de classe UML.

Classe ou Entité- Attribut ou Propriété

Typé Multi-valué Composé Dérivé

- Méthode Paramètres Valeur de retour

Association - Association

Verbe Cardinalité

- Héritage Héritage d'attributs Héritage de méthodes

- Composition (ou entité faible) Cardinalité

3 - http://uml.free.fr/cours/i-p14.html4 - http://developpeur.journaldunet.com/tutoriel/cpt/010607cpt_umlintro.shtml


Stéphane Crozat 44

http://developpeur.journaldunet.com/tutoriel/cpt/010607cpt_umlintro.shtml

http://uml.free.fr/cours/i-p14.html

d) Correspondance entre UML et relationnel

Modèle UML Modèle relationnel

Classe instanciable Relation

Classe abstraite Rien

Objet Nuplet

Attribut simple Attribut atomique

Attribut composite Ensemble d'attributs

Attribut multivalué Relation et clé étrangère

Attribut dérivé Procédure stockée ou contrainte dynamique

Méthode Procédure stockée

Association 1:N Clé étrangère

Association N:M Relation et clé étrangère

Association de degré 3 ou supérieur Relation et clé étrangère

Classe d'association Attributs

Composition Clé

Tableau 3 Passsage UML vers Relationnel

4. Modélisation avancée des associations 1:1 en relationnel

Objectifs

Savoir faire le passage d'un schéma conceptuel UML à un schémarelationnel.Connaître les choix possibles pour le cas de l'association 1:1 etsavoir faire le meilleur choix.

Il existe des formulations conceptuelles en UML qui sont plus délicates à traduire au niveaulogique en relationnel, comme l'association 1:1. Ces cas requièrent un choix éclairé de la partdu concepteur.

a) Association 1:1

Q u e s t i o n


a {key}b

Classe1

c {key}d

Classe2

1..1 1..1association

Graphique 26 Association 1:1


Stéphane Crozat 45

a {key}b

Classe1

c {key}d

Classe2


Graphique 27 Association 0..1:1

a {key}b

Classe1

c {key}d

Classe2


Graphique 28 Association 0..1:0..1

b) Transformation des associations 1:1 (approche générale)

Il existe deux solutions pour transformer une association 1:1 : Avec deux relations : on traite l'association 1:1 comme une association 1:N, puis l'on

ajoute une contrainte UNIQUE sur la clé étrangère pour limiter la cardinalité maximale à1 ;

Avec une seule relation : on fusionne les deux classes en une seule relation.

a {key}b

Classe1

c {key}d

Classe2



Méthode : Avec deux relations (clé étrangère) Une des deux relations est choisie pour porter la clé étrangère ;

on ajoute les contraintes : UNIQUE ou KEY (clé candidate) sur la clé étrangère ; et sinécessaire une contrainte imposant l'instanciation simultanée des deux relations.

Classe1(#a,b,c=>Classe2) avec c UNIQUE ou KEY Classe2(#c,d)

Contrainte (éventuellement) : PROJ(Classe1,c)=PROJ(Classe2,c)

ouClasse1(#a,b)

Classe2(#c,d,a=>Classe1) avec a UNIQUE ou KEY

Contrainte (éventuellement) : PROJ(Classe1,a)=PROJ(Classe2,a)

Méthode : Avec une relation (fusion) On créé une seule relation contenant l'ensemble des attributs des deux classes ;

on choisit une clé parmi les clés candidates.Classe12(#a,b,c,d) avec c UNIQUE ou KEY

ouClasse21(#c,d,a,b) avec a UNIQUE ou KEY


Stéphane Crozat 46

Remarque : Fusion des relations dans le cas de la traduction de l'association 1:1Ce choix entre les deux méthodes sera conduit par une appréciation du rapport entre :

La complexité introduite par le fait d'avoir deux relations là ou une suffit

La pertinence de la séparation des deux relations d'un point de vue sémantique

Les pertes de performance dues à l'éclatement des relations

Les pertes de performance dues au fait d'avoir une grande relation

Les questions de sécurité et de sûreté factorisées ou non au niveau des deux relations

...

c) Transformation des associations 1..1:1..1

Méthode : Association 1..1:1..1 Le plus souvent c'est méthode par fusion des relations qui est la plus adaptée à ce cas.

Lorsqu'elle ne l'est pas, et que l'on choisit deux relations il faut ajouter une contraintedynamique qui contrôlera que les deux relations sont bien toujours instanciéesensembles. Notons que la clé étrangère peut être choisie comme clé primaire.

a {key}b

Classe1

c {key}d

Classe2




ouClasse21(#c,d,a,b) avec a KEY

ouClasse1(#a,b,c=>Classe2) avec c KEY

Classe2(#c,d)

Contrainte : PROJ(Classe1,c)=PROJ(Classe2,c)

ouClasse1(#a,b)

Classe2(#c,d,a=>Classe1) avec a KEY

Contrainte : PROJ(Classe1,a)=PROJ(Classe2,a)

d) Transformation des associations 0..1:1..1

Méthode : Association 0..1:1..1 Le plus souvent c'est la méthode par les deux relations qui est la plus adaptée, on

choisira toujours la relation côté 0..1 pour être référençante. Il est possible d'utiliser la fusion, dans ce cas les clés côté 0..1 deviennent des attributs

UNIQUE, il ne peuvent plus être clés, pouvant être NULL.


Stéphane Crozat 47

a {key}b

Classe1

c {key}d

Classe2


Graphique 31 Association 0..1:1

Classe1(#a,b,c=>Classe2) avec c KEY

Classe2(#c,d)

ouClasse12(#c,d,a,b) avec a UNIQUE

e) Transformation des associations 0..1:0..1

Méthode : Association 0..1:0..1 On choisit la solution avec deux relations, d'un côté ou de l'autre ; la clé étrangère est

associé à la contrainte UNIQUE, ce n'est pas une clé car elle peut être nulle.

Il n'est pas possible de choisir la fusion, en effet l'une des deux relations pouvantêtre nulle, on ne pourrait plus trouver de clé.

a {key}b

Classe1

c {key}d

Classe2


Graphique 32 Association 0..1:0..1

Classe1(#a,b,c=>Classe2) avec c UNIQUE

Classe2(#c,d)

ouClasse1(#a,b)

Classe2(#c,d,a=>Classe1) avec a UNIQUE

f) Exemple de choix pour une relation 1:1

Exemple Soit deux entités, "homme" et "femme" et une association "mariage" de cardinalité

1..1:1..1 entre ces deux entités (hommes et femmes sont donc obligatoirementmariés).

Les entités "homme" et "femme" sont identifiées par un attribut "nom" (dans ce modèlechaque personne a un nom unique, on pourrait remplacer le nom par un identifiantcomme le numéro de sécurité social ou par une clé artificielle pour être plus proche dela réalité).

Bien que de type 1..1:1..1, le choix de la fusion n'est pas très opportun car il s'agit biend'objets distincts que l'on veut modéliser.

On choisira donc plutôt la représentation avec deux relations.

La clé étrangère pourra être du côté "homme" ou "femme", même si la pratiquedominante nous incite à la mettre du côté femme.

On pourra également décider de prendre la clé étrangère comme clé primaire.

1 homme (#nom)


Stéphane Crozat 48

2 femme (#mariage=>homme, nom) avec nom KEY3 Contrainte : PROJ(homme,nom) = PROJ(femme,mariage)

ExempleSi l'association avait été de cardinalité 0..1:0..1 (certains hommes et femmes ne sont pasmariés), un choix similaire se serait imposé, avec l'impossibilité de choisir la clé étrangèrecomme clé primaire, celle-ci pouvant être nulle et n'étant donc plus candidate.

1 homme (#nom)2 femme (#nom, mariage=>homme) avec mariage UNIQUE

B. Exercices

1. Lab III

[20 min]


Un médicament est décrit par un nom, qui permet de l'identifier. En effet il n'existe pasdeux médicaments avec le même nom. Un médicament comporte une descriptioncourte en français, ainsi qu'une description longue en latin. On gère aussi leconditionnement du médicament, c'est à dire le nombre de pilules par boîte (qui est unnombre entier).

À chaque médicament on associe une liste dédiée de contre-indications, généralementplusieurs, parfois aucune.


Données de testAfin de matérialiser notre base de données, nous obtenons les descriptions suivantes :

Le Chourix a pour description courte « Médicament contre la chute des choux » et pourdescription longue « Vivamus fermentum semper porta. Nunc diam velit, adipiscing uttristique vitae, sagittis vel odio. Maecenas convallis ullamcorper ultricies. Curabiturornare. ». Il est conditionné en boîte de 13. Ses contre-indications sont :- Le Chourix ne doit jamais être pris après minuit.- Le Chourix ne doit jamais être mis au contact avec de l'eau.Ses composants sont le HG79 et le SN50.

Le Tropas a pour description courte « Médicament contre les dysfonctionnementsintellectuels » et pour description longue « Suspendisse lectus leo, consectetur intempor sit amet, placerat quis neque. Etiam luctus porttitor lorem, sed suscipit estrutrum non. ». Il est conditionné en boîte de 42.Ses contre-indications sont :- Le Tropas doit être gardé à l'abri de la lumière du soleilSon unique composant est le HG79.

Les composants existants sont :- HG79 : "Vif-argent allégé"


Stéphane Crozat 49

- HG81 : "Vif-argent alourdi"- SN50 : "Pur étain"

Q u e s t i o n 1Effectuez le modèle conceptuel en UML de ce problème.

Indices :

On note dans l'énoncé que les contre-indications sont dédiée aux médicaments, etpar ailleurs on note dans les données exemples que les contre-indications sonténoncées spécifiquement par rapport aux médicaments. Ce n'est pas parce que les composants s'appellent ainsi dans l'énoncé que l'on est enprésence d'une composition.

Q u e s t i o n 2En mobilisant les règles adéquates, proposer un modèle logique de données correspondant enrelationnel. Le repérage des domaines et des clés est obligatoire.

Q u e s t i o n 3

Dessiner des tableaux remplis avec les données fournies en exemple, afin de montrer que lemodèle fonctionne selon le besoin exprimé initialement. On pourra mettre le premier motseulement des descriptions pour gagner du temps.

2. Étudiants et UVs (introduction)

[20 min]On dispose du schéma UML ci-après qui décrit des étudiants, des UV, les notes obtenues parles étudiants à ces UV, et les diplômes d'origine de ces étudiants.

Étudiants et UVs

{key} désigne des clés candidates, ici toutes les clés ne sont composées que d'un seulattribut

{local key} désigne une clé locale

un semestre est de la forme 'PYYYY' ou 'AYYYY' (où YYYY désigné une année sur 4chiffre) ; exemple : 'A2013', 'P2014...

Rappel : Notion de clé locale dans classes d'association

Q u e s t i o n Traduire le schéma en modèle logique relationnel. (MLD1).

On choisira obligatoirement les clés primaires parmi celles nécessitant le plus petit nombre debits possible pour leur codage.


Stéphane Crozat 50

IV - Modélisation conceptuelle de données avancée avec le diagrammede classes UML

IV

A. Cours

1. Diagramme de classes avancé

Objectifs

Maîtriser le diagramme de classe UML dans le cas de la conceptionde BD.

a) Exercice : Modéliser un site Web

En analysant le schéma UML ci-après, sélectionner toutes les assertions vraies.

Image 18 MCD UML

Stéphane Crozat 51

Tous les chapitres ont un titre.

Il est possible d'avoir un auteur différent pour chaque chapitre.

Toutes les sections contiennent au moins une section.

Toutes les sections contiennent au moins une page.

Toutes les sites Web contiennent au moins une page.

b) Contraintes

Ajout de contraintes dynamiques sur le diagramme de classeIl est possible en UML d'exprimer des contraintes dynamiques sur le diagramme de classe, parannotation de ce dernier.

Syntaxe: Notation de contraintes

Image 19 Notation contraintes en UML

Exemple : Exemple de contraintes

Image 20 Commandes

Modélisation conceptuelle de données avancée avec le diagramme de classes UML

Stéphane Crozat 52

Méthode : Expressions formelles ou texte libre ?Il est possible d'exprimer les contraintes en texte libre ou bien en utilisant des expressionsformelles.On privilégiera la solution qui offre le meilleur compromis entre facilité d'interprétation et nonambiguïté. La combinaison des deux est également possible si nécessaire.

Méthode : Quelles contraintes exprimer ?En pratique il existe souvent de très nombreuses contraintes, dont certaines sont évidentes, ouencore secondaires. Or l'expression de toutes ces contraintes sur un diagramme UMLconduirait à diminuer considérablement la lisibilité du schéma sans apporter d'informationnécessaire à la compréhension. En conséquence on ne représentera sur le diagramme que lescontraintes les plus essentielles.Notons que lors de l'implémentation toutes les contraintes devront bien entendu êtreexprimées. Si l'on souhaite préparer ce travail, il est conseillé, lors de la modélisation logique,de recenser de façon exhaustive dans un tableau toutes les contraintes à implémenter.

c) Exemple de contraintes standardisées sur les associations

Rappel

Image 21 Notation des contraintes sur les associations

Définition : Inclusion {I}Si l'association inclue est instanciée, l'autre doit l'être aussi, la contrainte d'inclusion a un sens,représenté par une flèche (également notée {Subset} ou {IN}).

Définition : Simultanéité {S}Si une association est instanciée, l'autre doit l'être aussi (également notée {=} ou {AND}). La simultanéité est équivalente à une double inclusion.

Définition : Exclusion {X}Les deux associations ne peuvent être instanciées en même temps.

Définition : Totalité {T}, également notée {OR}Au moins une des deux associations doit être instanciée.

Définition : Partition {XT}, également notée {+} ou {XOR} ou {P}Exactement une des deux associations doit être instanciée.

d) Exemple de contraintes standardisées sur les attributs

Définition : {unique}La valeur de l'attribut est unique pour la classe.

Définition : {frozen}Une fois instancié l'attribut ne peut plus changer.


Stéphane Crozat 53

Définition : {key}Bien que non standardisé en UML, en base de données, il est courant d'utiliser {key}.

Exemple : Contrainte de clé

Clé en UML

Image 22 Clé composée de deux attributs

e) Paquetages

Définition : PackageLes paquetages (plus communément appelés package) sont des éléments servant à organiserun modèle.Ils sont particulièrement utiles dès que le modèle comporte de nombreuses classes et quecelles-ci peuvent être triées selon plusieurs aspects structurants.

Syntaxe

Image 23 Notation des paquetages en UML


Stéphane Crozat 54

Exemple

Image 24 Exemple d'utilisation des packages

MéthodeOn représente chaque classe au sein d'un package. Il est alors possible de faire uneprésentation globale du modèle (tous les packages), partielle (une partie des packages) oucentrée sur un seul package. Pour une représentation partielle ou centrée sur un package, on représente les packagesconcernés avec leurs classes propres, ainsi que toutes les classes liées des autres packages (etseulement celles-ci).

Image 25 Présentation partielle du modèle centrée sur un package

f) Stéréotype

Définition : Stéréotype UMLUn stéréotype UML est une syntaxe permettant d'ajouter de la sémantique à la modélisationdes classes. Il permet de définir des types de classe, afin de regrouper conceptuellement unensemble de classes (à l'instar d'une classe qui permet de regrouper conceptuellement unensemble d'objets). C'est une mécanique de méta-modélisation : elle permet d'étendre le méta-modèle UML, c'està dire le modèle conceptuel du modèle conceptuel.

Définition : Méta-modèleUn méta-modèle est le modèle d'un modèle. Par exemple le méta-modèle UML comprend lesconcepts de classe, attribut, association, cardinalité, composition, agrégation, contraintes,annotations, ... On mobilise ces concepts (on les instancie) pour exprimer un modèleparticulier suivant le formalisme UML.


Stéphane Crozat 55

Les stéréotypes permettent donc d'ajouter au méta-modèle UML standard, celui que tout lemonde utilise, des concepts locaux pour enrichir le langage de modélisation que l'on utilisepour réaliser des modèles.

Syntaxe

Image 26 Notation d'un stéréotype en UML

Conseil : Stéréotypes spécifiques et stéréotypes standardUn stéréotype spécifique enrichit le méta-modèle UML, mais selon une sémantique qui estpropre à celui qui l'a posé, non standard donc. La conséquence est que pour un tiers,l'interprétation du stéréotype n'est plus normalisée, et sera potentiellement plus facilementerronée. Il convient donc de ne pas abuser de cette mécanique. Deux ou trois stéréotypes spécifiques, correctement définis, sont faciles à transmettre,plusieurs dizaines représenteraient un nouveau langage complet à apprendre pour le lecteur dumodèle.Il existe des stéréotypes fournit en standard par UML, ou communément utilisés par lesmodélisateurs. L'avantage est qu'il seront compris plus largement, au même titre que le restedu méta-modèle (ils ont une valeur de standard).

g) Énumération : stéréotype <<enumeration>>

Syntaxe

Stéréotype UML permettant d'exprimer une énumération

Exemple

Exemple de modélisation UML d'énumération

h) Type utilisateurs : stéréotype <<dataType>>

Les types utilisateurs permettent de définir des types complexes propres en extension destypes primaires (entier, chaîne, date...).


Stéphane Crozat 56

Syntaxe

Stéréotype dataType

Exemple

Stéréotype dataType (exemple)

Méthode : Attributs composésCette modélisation est équivalente à la modélisation des attributs composés directement dansla classe principale. C'est une représentation plus standard en UML.

2. Passage UML-Relationnel : Expression de contraintes

Objectifs

Savoir exprimer les contraintes en modélisation relationnelle.

a) Contraintes

Q u e s t i o n


a {key}b

Classe1

c {key}d

Classe2

1 1..Nassociation

Graphique 33 Association 1:N


Stéphane Crozat 57

a {key}b

Classe1

c {key}d

Classe2

1..N 1..Nassociation

Graphique 34 Association N:M

a {key}b

Classe1

c {key}d

Classe2

1 1..N

e {local key}f

Cl-Assoc


a {key}b

Classe1

c {key}d

Classe2

1..N 1..N

e {key}f

Cl-Assoc


b) Liste des contraintes

Méthode : Contraintes exprimées sur le diagrammeLes contraintes exprimées sur le diagrammes sont reportées dans un tableau quiaccompagnera le modèle logique. On ajoutera également les clés candidates.

Relation1 AND (Relation1, Relation4) ; a KEY ; ...

Relation2 b > c ; XOR (Relation2, Relation 3) ; ...

L'on peut également commenter chaque relation directement lorsque les informations ne sontpas trop nombreuses.

1 Relation1 (a, b, c) avec : c clé candidate ; AND(Relation1,Relation4)2 Relation2 (b, c, d) avec : b > c ; XOR(Relation2, Relation3)

Méthode : Extension des contraintes expriméesOn s'attachera lors de la modélisation logique à exprimer l'ensemble des contraintesdynamiques pesant sur le modèle, même celles qui ont été considérées comme secondaires ouévidentes lors de la modélisation conceptuelle.


Stéphane Crozat 58

c) Contrainte de cardinalité minimale 1 dans les associations 1:N

RappelTransformation des associations 1:N

Méthode

a {key}b

Classe1

c {key}d

Classe2

1 1..Nassociation

Graphique 37 Association 1:N

Si la cardinalité est exactement 1 (1..1) côté 1, alors on ajoutera une contrainte de nonnullité sur la clé étrangère,

si la cardinalité est au moins 1 (1..N) côté N, on ajoutera une contrainte d'existence detuples référençant pour chaque tuple de la relation référencée.

Classe1(#a,b)

Classe2(#c,d,a=>Classe1)

Contraintes : a NOT NULL et PROJECTION(Classe1,a) PROJECTION(Classe2,a)⊆

Complément : Association 1:N avec classe d'association

a {key}b

Classe1

c {key}d

Classe2

1 1..N

e {local key}f

Cl-Assoc


Classe1(#a,b)

Classe2(#c,d,a=>Classe1, e, f) avec e KEY

Contraintes : a NOT NULL et PROJECTION(Classe1,a) PROJECTION(Classe2,a)⊆

ComplémentProjection

d) Contrainte de cardinalité minimale 1 dans les associations N:M

RappelTransformation des associations N:M

Méthode Si la cardinalité est au moins 1 (1..N) d'un côté et/ou de l'autre, alors des contraintes

d'existence simultanée de tuple devront être ajoutées. Ce n'est pas nécessaire si la cardinalité est 0..N.


Stéphane Crozat 59

a {key}b

Classe1

c {key}d

Classe2

1..N 1..Nassociation

Graphique 39 Association N:M

Classe1(#a,b)

Classe2(#c,d)

Assoc(#a=>Classe1,#c=>Classe2)

Contraintes : PROJ(Classe1,a) PROJ(Assoc,a) et PROJ(Classe2,c) PROJ(Assoc,c)⊆ ⊆

Complément : Association N:M avec classe d'association

a {key}b

Classe1

c {key}d

Classe2

1..N 1..N

e {key}f

Cl-Assoc


Classe1(#a,b)

Classe2(#c,d)

Cl-Assoc(#a=>Classe1,#c=>Classe2,#e,f)

Contraintes : PROJ(Classe1,a) PROJ(Assoc,a) et PROJ(Classe2,c) PROJ(Assoc,c)⊆ ⊆

ComplémentProjection

e) Contraintes de l'héritage par référence avec classe mère abstraite

RappelTransformation de la relation d'héritage par référence

MéthodeSi la classe mère est abstraite, il faut ajouter la contrainte que tous les tuples de la Classe1sont référencés par un tuple de la Classe2 et/ou de la Classe3.

c {key}d

Classe2

e {key}f

Classe3

a {key}b

Classe1



Stéphane Crozat 60

Classe1(#a,b)


Classe3(#a=>Classe1,e,f) avec e KEY

Contraintes : PROJ(Classe1,a) IN (PROJ(Classe2,a) UNION PROJ(Classe3,a))

ExempleSoit la classe A avec la clé K et les attributs A1 et A2. Soit la classe B, classe fille de A,comprenant la clé K' et les attributs B1 et B2. Le modèle relationnel correspondant selon cettetransformation est :

1 A (#K, A1, A2)2 B (#K=>A, K', B1, B2)3

Cette solution est particulièrement adaptée lorsque la classe mère n'est pas abstraite, car celaen autorise l'instanciation sans aucun bruit dans la relation lié aux classes filles. Par contre si laclasse mère est abstraite il faut introduire une contrainte dynamique complexe pour imposer laprésence d'un tuple référençant dans une des classes filles.Ainsi dans l'exemple précédent, un A peut être instancié en toute indépendance par rapport àla relation B.

f) Contraintes de l'héritage par les classes filles avec classe mère non abstraite

RappelTransformation de la relation d'héritage par les classes filles

MéthodeSi la classe mère n'est pas abstraite :

On créé une relation supplémentaire pour gérer les objets de la classe mère

On ajoute une contrainte qui exprime que les tuples de la classe mère ne peuventexister dans les classes filles

c {key}d

Classe2

e {key}f

Classe3

a {key}b

Classe1


Classe1(#a,b)


Contrainte : PROJ(Classe1,a) NOT IN (PROJ(Classe2,a) UNION PROJ(Classe3,a))

Exemple : Héritage absorbé par les classes fillesSoit la classe abstraite A avec la clé K et les attributs A1 et A2. Soit la classe B, classe fille deA avec les attributs B1 et B2. Soit la classe C, classe fille de A avec les attributs C1 et C2.


Stéphane Crozat 61

Le modèle relationnel correspondant selon cette transformation est :

1 B (#K, A1, A2, B1, B2)2 C (#K, A1, A2, C1, C2)

Si A n'avait pas été abstraite elle aurait donné naissance à une relation A possédant lesattributs A1 et A2 et qui n'aurait alors contenu que les tuples qui ne sont ni des B ni des C.

g) Contraintes de l'héritage par la classe mère avec classe mère abstraite

RappelTransformation de la relation d'héritage par la classe mère

MéthodeSi la classe mère est abstraite :

1. sa valeur est ôtée de l'attribut de discrimination ; 2. une contrainte supplémentaire doit vérifier que soit c soit e est obligatoirement valué

(ou les deux).

c {key}d

Classe2

e {key}f

Classe3

a {key}b

Classe1


Classe1(#a,b,c,d,e,f,t:{2,3})

Contraintes : c UNIQUE et e UNIQUE

AND (c NOT NULL OR e NOT NULL)

AND t NOT NULL

Exemple : Héritage absorbé par la classe mèreSoit la classe A avec la clé K et les attributs A1 et A2. Soit la classe B, classe fille de A avec lesattributs B1 et B2. Soit la classe C, classe fille de A avec les attributs C1 et C2.Le modèle relationnel correspondant selon cette transformation est :

1 A (#K, A1, A2, B1, B2, C1, C2, T:{'B','C'})

Si l'on pose que A n'est pas abstraite, alors un tuple sera un A s'il a la valeur null pour sapropriété D. Si l'on pose que A est abstraite, on ajoutera la contrainte NOT NULL à la propriétéT. On peut aussi ajouter 'A' aux valeurs possible de T.

Complément : Héritage exclusifSi l'héritage est exclusif, que la classe mère soit abstraite ou non, il faudrait vérifier par descontraintes que l'attribut de discrimination T et les attributs valués sont en correspondance,afin d'empêcher toute incohérence :

(T=2 AND c)

(T=3 AND e)

NOT (c AND e)


Stéphane Crozat 62

NOT (c AND f)

...

B. Exercices

1. Ouaf !

[45 min]Un réseau de chenils souhaite informatiser son activité et vous demande de créer un modèleconceptuel de sa future base de données. Un chenil est un établissement destiné à l'élevage ouà la pension des chiens. Dans ce réseau, les chenils s'occupent des chiens de leur naissancejusqu'à la fin de leur apprentissage. L'identité du propriétaire étant privée, aucun chien ne serarelié à un propriétaire dans cette base de données qui sert aussi de vitrine sur le savoir-fairedu réseau.Un chenil du réseau possède un nom unique permettant de l'identifier, un nom de contact ainsiqu'un numéro de téléphone, et une description de ses activités. Chaque chien est identifié parson nom et celui du chenil qui gère son apprentissage ; il possède une date de naissance et estassocié à une race. Certains des chiens suivront un apprentissage plus spécifique : ilsdeviendront guides d'aveugle, chiens de garde ou chiens de course. Chaque chien de gardepossède une spécialité : attaque, défense, pistage ou détection. Un chien de course quand à luipossède une vitesse maximum mesurée.Le chenil gère également l'historique des poids de chaque animal, afin d'enregistrerrégulièrement la courbe de croissance. Pour cela chaque relevé de poids est identifié par lenom du chien et la date du relevé.Les chiens aux parcours plus spécifiques (guides, chiens de garde ou chiens de course) sontliés à des entités qui les géreront après l'apprentissage. Ces entités sont identifiées par unnom, et possèdent une description ainsi qu'un nom de contact avec un numéro de téléphone.Les chiens guides d'aveugle sont ainsi gérés par une association qui propose ensuite les chiensaux personnes malvoyantes. Les chiens de gardes sont utilisés par des entreprises (le chenilsouhaite pouvoir ajouter une description de l'activité principale de chaque entreprise). Et unchien de course est possédé par une écurie (qui a une date de création). Bien sûr, chacune deces entités peut gérer plusieurs animaux.

Q u e s t i o n 1

Réalisez un modèle conceptuel en UML répondant aux besoins du réseau de chenils, sous laforme d'un package Chenil.Le réseau souhaiterait compléter cette première modélisation en ajoutant des informations surles chiens de course, pour améliorer sa publicité. L'objectif est de garder en mémoire pourchaque épreuve sportive auquel participe un chien de course son numéro de dossard (de 1 à6), sa position à l'issue de l'épreuve (de 1 à 6), son temps de course, et s'il a abandonné ounon. Une épreuve est identifiée par la date et le nom du tournoi à laquelle elle appartient (untournoi est identifié uniquement par son nom). Il y a toujours 6 chiens qui courent dans uneépreuve, mais ils ne proviennent pas tous d'un des chenils du réseau (nous ne gérons pas leschiens en dehors du réseau). Chaque épreuve a lieu dans un cynodrome identifié par son nom,et chaque cynodrome se situe dans un département, identifié par son numéro et possédant unnom.

Q u e s t i o n 2

Réalisez un second diagramme UML répondant à ces nouveaux besoins, sous la forme d'unsecond package Course.


Stéphane Crozat 63

2. Super-héros relationnels I

[20 min]La gamme de super-héros GARVEL veut réaliser la base de données de leurs figurinesarticulées. La société a fait réaliser un modèle UML qui doit servir de point de départ à la miseen œuvre.

Modèle UML Figurines GARVEL

Q u e s t i o n Transformer le modèle UML en modèle relationnel (justifier les passages non triviaux, enparticulier la relation d'héritage).

3. Médiathèque

[45 minutes]Une médiathèque veut s'informatiser pour gérer plus efficacement son catalogue, contenantdes livres, des films, et des albums de musique.Les informations à enregistrer pour les livres sont : les titres, le (ou les) auteur(s), la date deparution, l'éditeur, la date d'impression et le nombre de pages. Les informations à enregistrerpour les films sont : le nom, le (ou les) réalisateur(s), au maximum six acteurs ayant jouédans le film avec leur rôle (il peut n'y avoir aucun acteur), le studio de production et la date desortie. Les informations à gérer pour les albums sont : le nom de l'album, l'auteur, la maisonde production, l'année de sortie, et les supports disponibles à la médiathèque (CD et/ouvinyle).Pour chaque auteur, réalisateur, acteur ou musicien d'une œuvre, on veut gérer son nom, sonprénom, son ou ses noms d'artiste (s'il en a), et sa date de naissance. Un album de musiquepeut avoir pour auteur :

un artiste (ex : Jimmy Hendrix, Mozart),

ou un groupe (ex : les Rolling Stones ou Franz Ferdinand) dont on gérera le nom,l'année de formation, et les informations sur les différents membres.

Livres, films et albums sont identifiés de manière unique (un film ne peut pas avoir le mêmeidentifiant qu'un album) par un code interne à la médiathèque. On veut aussi pouvoir gérer les


Stéphane Crozat 64

adaptations cinématographiques (quels films sont les adaptations de quels livres). On veutenfin pouvoir retrouver facilement la BO correspondant à un film donné (la bande originale estl'album de musique du film).

Q u e s t i o n 1

Réalisez un package permettant de modéliser en UML le catalogue de la médiathèque.La médiathèque s'étend sur trois étages, chacun comprenant plusieurs rayons à thème(Romans Contemporains, Musique Classique, etc.). Certains de ces rayons peuventcomprendre à la fois des albums, des livres et des films (comme le rayon Science Fiction, ou lerayon Thriller). Dans un rayon, les œuvres centrales ou récentes sont disposées sur desprésentoirs (chacun pouvant recueillir un certain nombre d'œuvres : films, livres et/oualbums), tandis que les autres sont rangées sur des étagères identifiées par un codeparticulier. Chaque étagère peut comprendre un certain nombre d'œuvres, mais d'une seulecatégorie (on a des étagères de livres et des étagères d'albums, mais pas d'étagèrescomprenant à la fois des livres et des albums).

Q u e s t i o n 2

Réalisez un second package permettant de modéliser l'organisation de la bibliothèque et de sesmoyens de rangement.


Stéphane Crozat 65

V - Analyse de bases de données SQL avec les agrégats (GROUP BY)

V

A. Cours

1. Introduction aux agrégats avec GROUP BY

Objectifs

Savoir réaliser un agrégat en SQL en utilisant les fonctions deregroupement et les clause GROUP BY

a) Exercice : La somme finale

Que renvoie la dernière instruction SQL de la séquence ci-dessous ?

1 CREATE TABLE R1 (a INTEGER, b INTEGER);2 CREATE TABLE R2 (b INTEGER);3 INSERT INTO R1 VALUES (1,1);4 INSERT INTO R1 VALUES (2,1);5 INSERT INTO R2 VALUES (1);6 INSERT INTO R2 VALUES (2);7 SELECT sum(R1.a) FROM R1, R2 WHERE R1.b=R2.b;

b) Définition de l'agrégation

Définition : AgrégatUn agrégat est un partitionnement horizontal d'une table en sous-tables, en fonction desvaleurs d'un ou plusieurs attributs de partitionnement, suivi éventuellement de l'applicationd'une fonction de calcul à chaque attribut des sous-tables obtenues.Synonyme : Regroupement

Stéphane Crozat 66

Syntaxe

1 SELECT liste d'attributs de partionnement à projeter et de fonctions de calcul2 FROM liste de relations3 WHERE condition à appliquer avant calcul de l'agrégat4 GROUP BY liste ordonnée d'attributs de partitionnement

1. La table est divisée en sous-ensembles de lignes, avec un sous-ensemble pour chaquevaleur différente des attributs de partitionnement projetés dans le SELECT

2. Les fonctions d'agrégation sont appliquées sur les attributs concernés

Exemple

1 SELECT Societe.Nom, AVG(Personne.Age)2 FROM Personne, Societe3 WHERE Personne.NomSoc = Societe.Nom4 GROUP BY Societe.Nom

Societe.Nom est un ici le seul attribut de partitionnement, donc un sous ensemble est créépour chaque valeur différente de Societe.Nom, puis la moyenne (fonction AVG) est effectuéepour chaque sous-ensemble.

Nom | Age------------+----- Oracle | 45 Oracle | 35 IBM | 20 IBM | 25 IBM | 30

Nom | AVG(Age) ------------+--------- Oracle | 40 IBM | 30

Regroupement avec un attribut et une fonction

Cette requête calcul l'âge moyen du personnel pour chaque société.

Exemple

1 SELECT Societe.Nom, Societe.Dpt AVG(Personne.Age)2 FROM Personne, Societe3 WHERE Personne.NomSoc = Societe.Nom4 GROUP BY Societe.Nom, Societe.Dpt

Societe.Nom et Societe.Dpt sont les deux attributs de partitionnement, donc un sous-ensembleest créé pour chaque valeur différente du couple (Societe.Nom,Societe.Dpt).

Nom | Dpt | Age----------+---------+----- Oracle | Dev | 45 Oracle | Com | 35 IBM | Dev | 20 IBM | Dev | 25 IBM | Com | 30

Nom | Dpt | Age----------+---------+----- Oracle | Dev | 45 Oracle | Com | 35 IBM | Dev | 22.5 IBM | Com | 30

Regroupement avec deux attributs et une fonction

Cette requête calcul l'âge moyen du personnel pour chaque département de chaque société.

Remarque : Requête inutileLa requête est inutile dès lors que l'agrégat est défini sur une valeur unique dans la relation,puisqu'on aura bien une ligne par ligne de la table source.

1 SELECT Societe.Nom

Analyse de bases de données SQL avec les agrégats (GROUP BY)

Stéphane Crozat 67

2 FROM Societe3 GROUP BY Societe.Nom

countrycode ------------- Oracle IBM

countrycode ------------- Oracle IBM

Exemple d'agrégat inutile (countrycode est une clé de country)

c) Exemple d'attribut d'agrégation

Schéma relationnel

1 country(#countrycode:char(2), name:varchar, population:numeric) 2 city(#code:char(3), countrycode=>country, name:varchar, population:numeric):

Schéma de base de données

1 CREATE TABLE country (2 countrycode CHAR(2) NOT NULL,3 name VARCHAR NOT NULL, 4 population NUMERIC(3),5 PRIMARY KEY (countrycode)6 );78 CREATE TABLE city (9 citycode CHAR(3) NOT NULL,

10 countrycode CHAR(2) NOT NULL,11 name VARCHAR NOT NULL, 12 population NUMERIC(2,1),13 PRIMARY KEY (citycode),14 FOREIGN KEY (countrycode) REFERENCES country(countrycode)15 );

Données

1 INSERT INTO country VALUES ('ES', 'Spain', 46);2 INSERT INTO country VALUES ('FR', 'France', 67);3 INSERT INTO country VALUES ('DE', 'Germany', 82);45 INSERT INTO city VALUES ('BAR', 'ES', 'Barcelona', 1.9);6 INSERT INTO city VALUES ('MAD', 'ES', 'Madrid', 3.3);7 INSERT INTO city VALUES ('ZAR', 'ES', 'Zaragoza', 0.7);89 INSERT INTO city VALUES ('PAR', 'FR', 'Paris', 2.2);

10 INSERT INTO city VALUES ('LYO', 'FR', 'Paris', 0.5);11 INSERT INTO city VALUES ('LLL', 'FR', 'Lille', 0.2);12 INSERT INTO city VALUES ('AMN', 'FR', 'Amiens', 0.1);

Sélectionne les countrycode existants dans la table city

1 SELECT countrycode 2 FROM city;

1 countrycode 2 -------------3 ES4 ES5 ES


Stéphane Crozat 68

6 FR7 FR8 FR9 FR

Sélectionne les countrycode existants dans la table city avec agrégat

1 SELECT countrycode 2 FROM city3 GROUP BY countrycode;

1 countrycode 2 -------------3 FR4 ES

countrycode ------------- ES ES ES FR FR FR FR

countrycode ------------- ES FR

Principe de l'agrégation

d) Fonctions d'agrégation

Définition : Fonctions d'agrégationUne fonction d'agrégation (ou fonction de regroupement) s'applique aux valeurs du sous-ensemble d'un agrégat e relation avec pour résultat la production d'une valeur atomiqueunique (entier, chaîne, date, etc).Les cinq fonctions prédéfinies sont :

Count(Relation.Propriété)

Renvoie le nombre de valeurs non nulles d'une propriété pour tous les tuples d'unerelation ;

Sum(Relation.Propriété)

Renvoie la somme des valeurs d'une propriété des tuples (numériques) d'une relation ; Avg(Relation.Propriété)

Renvoie la moyenne des valeurs d'une propriété des tuples (numériques) d'unerelation ;

Min(Relation.Propriété)

Renvoie la plus petite valeur d'une propriété parmi les tuples d'une relation . Max(Relation.Propriété)

Renvoie la plus grande valeur d'une propriété parmi les tuples d'une relation.

Attention : Fonctions de calcul sans partitionnementSi une ou plusieurs fonctions de calcul sont appliquées sans partitionnement, lerésultat de la requête est un tuple unique.


Stéphane Crozat 69

Exemple

1 SELECT Min(Age), Max(Age), Avg(Age)2 FROM Personne3 WHERE Qualification='Ingénieur'

Remarque : Comptage d'une relationPour effectuer un comptage sur tous les tuples d'une relation, appliquer la fonction count à unattribut de la clé primaire. En effet cet attribut étant non nul par définition, il assure que tousles tuples seront comptés.

e) Exemple de fonctions d'agrégation

Rappel : Schéma relationnel

1 country(#countrycode:char(2), name:varchar, population:numeric) 2 city(#code:char(3), countrycode=>country, name:varchar, population:numeric):

Exemple d'attribut d'agrégation

i Agrégat avec un attribut d'agrégation et une fonction d'agrégation

Requête sans agrégatSélectionne les countrycode et les citycode existants dans la table city.

1 SELECT countrycode, citycode 2 FROM city;

1 countrycode | citycode 2 -------------+----------3 ES | BAR4 ES | MAD5 ES | ZAR6 FR | PAR7 FR | LYO8 FR | LLL9 FR | AMN

Requête avec agrégat Sélectionne les countrycode et les citycode existants dans la table city,

puis agrège par valeurs distinctes de countrycode.

1 SELECT countrycode, count(citycode) 2 FROM city3 GROUP BY countrycode;

1 countrycode | count 2 -------------+-------3 FR | 44 ES | 3


Stéphane Crozat 70

countrycode | citycode ------------+---------- ES | BAR ES | MAD ES | ZAR FR | PAR FR | LYO FR | LLL FR | AMN

countrycode | count(citycode) ------------+----------------- ES | 3 FR | 4

Regroupement avec fonction d'agrégation

ii Agrégat avec un attribut d'agrégation et deux fonctions d'agrégation

Sélectionne les countrycode, les citycode et les populations existants dans la table city.

1 SELECT countrycode, citycode, population 2 FROM city;

1 countrycode | citycode | population 2 -------------+----------+------------3 ES | BAR | 1.94 ES | MAD | 3.35 ES | ZAR | 0.76 FR | PAR | 2.27 FR | LYO | 0.58 FR | LLL | 0.29 FR | AMN | 0.1

Requête avec agrégat Sélectionne les countrycode, les citycode et les populations existants dans la table city,

puis agrège par valeurs distinctes de countrycode

puis calcule les fonctions count et sum.

1 SELECT countrycode, count(citycode), sum(population) 2 FROM city3 GROUP BY countrycode;

1 countrycode | count | sum 2 -------------+-------+-----3 FR | 4 | 3.04 ES | 3 | 5.9

countrycode | citycode | population ------------+----------+------------ ES | BAR | 1.9 ES | MAD | 3.3 ES | ZAR | 0.7 FR | PAR | 2.2 FR | LYO | 0.5 FR | LLL | 0.2 FR | AMN | 0.1

countrycode | count | sum ------------+-------+----- ES | 3 | 5.9 FR | 4 | 3.0

Regroupement avec deux fonctions d'agrégation


Stéphane Crozat 71

iii Agrégat sans attribut d'agrégation et avec une fonction d'agrégation

Requête sans agrégatSélectionne les populations existants dans la table city.

1 SELECT population 2 FROM city;

1 population 2 ------------3 1.94 3.35 0.76 2.27 0.58 0.29 0.1

Requête avec agrégat Sélectionne les populations existants dans la table city,

puis calcule la fonction avg (pour average, moyenne).

1 SELECT avg(population) 2 FROM city;

1 avg 2 --------------------3 1.2714285714285714

population ------------ 1.9 3.3 0.7 2.2 0.5 0.2 0.1

avg -------------------- 1.2714285714285714

Regroupement avec fonction d'agrégation sans GROUP BY


Stéphane Crozat 72

2. Approfondissement des agrégats avec GROUP BY et HAVING

Objectifs

Savoir réaliser un agrégat en SQL en utilisant les fonctions deregroupement et les clause GROUP BY et HAVING

a) Single-Value Rule

Fondamental : Principe de la "Single-Value Rule" établie par le standard SQLToute colonne de la clause GROUP BY doit désigner une colonne présente dans laclause SELECT :

soit comme attribut d'agrégation,

soit comme attribut présent dans une fonction d'agrégation.

Attention : Requête illégale

1 SELECT countrycode, citycode, COUNT(citycode)2 FROM city3 GROUP BY countrycode;

1 ERROR: column "city.citycode" must appear in the GROUP BY clause or be used in an aggregate function;

countrycode | citycode ------------+---------- ES | BAR ES | MAD ES | ZAR FR | PAR FR | LYO FR | LLL FR | AMN

countrycode | citycode | count | ------------+-----------------+-------- ES | BAR MAD ZAR | 3 FR | PAR LYO LLL AMN | 4

Tentative de GROUP BY illégal

La requête est non standard et non logique car on cherche à mettre plusieursdonnées dans la case citycode après le GROUP BY (il y a plusieurs citycode parcountrycode). Elle sera refusée par tous les SGBD.

Complément : Single-Value Rulehttps://mariadb.com/kb/en/sql-99/the-single-value-rule5

i Tolérance (de certains SGBD)

Requête non standard tolérée par certains SGBD

1 SELECT citycode, countrycode, AVG(population) 2 FROM city3 GROUP BY citycode;

1 citycode | countrycode | avg 2 ----------+-------------+------------------------

5 - https://mariadb.com/kb/en/sql-99/the-single-value-rule/


Stéphane Crozat 73

https://mariadb.com/kb/en/sql-99/the-single-value-rule/

3 LLL | FR | 0.200000000000000000004 BAR | ES | 1.900000000000000000005 PAR | FR | 2.20000000000000006 LYO | FR | 0.500000000000000000007 ZAR | ES | 0.700000000000000000008 AMN | FR | 0.100000000000000000009 MAD | ES | 3.3000000000000000

La requête est non standard, même si c'est logiquement acceptable, car il n'y a qu'uncountrycode par citycode ici, city étant une clé. Certains SGBD comme Postgres accepte donc cette syntaxe, en ajoutant implicitementl'attribut qui manque au GROUP BY, car il n'y a pas d’ambiguïté si l'on analyse le graphe desDF : citycode → countrycode. Mais le standard impose d'être explicite, car le SGBD a le droitde ne pas le deviner.

ii Tolérance partielle

Requête légale

1 SELECT ci.countrycode, co.name, count(*) 2 FROM city ci JOIN country co 3 ON ci.countrycode=co.countrycode 4 GROUP BY ci.countrycode, co.name;

1 countrycode | name | count 2 -------------+--------+-------3 FR | France | 44 ES | Spain | 3

Requête non standard tolérée par certains SGBD

1 SELECT co.countrycode, co.name, count(*) 2 FROM city ci JOIN country co 3 ON ci.countrycode=co.countrycode 4 GROUP BY co.countrycode;

La requête est non standard, car co.name est dans le SELECT mais pas dans le GROUP BY.Comme dans l'exemple précédent certains SGBD accepteront cette requête grâce à la DFévidente : co.countrycode → co.name

Attention : Requête non standard non toléréeMais si l'on utilise à présent ci.countrycode à la place de co.countrycode...

1 SELECT ci.countrycode, co.name, count(*) 2 FROM city ci JOIN country co 3 ON ci.countrycode=co.countrycode 4 GROUP BY ci.countrycode;

1 ERROR: column "co.name" must appear in the GROUP BY clause or be used in an aggregate function

La requête est non standard, co.name doit être mentionné dans la clause GROUP BY.Logiquement on pourrait juger cela superflu, car par transitivité ci.countrycode →co.name, mais le SGBD (ici Postgres) ne va pas jusque là.

ConseilIl est donc conseillé d'appliquer le Single-Value Rule et de toujours expliciter tous les attributsdans le GROUP BY, pour éviter la dépendance au SGBD ou bien les erreurs liées à desvariations mineures de syntaxe.


Stéphane Crozat 74

b) Restriction après agrégation (HAVING)

DéfinitionLa clause HAVING permet d'effectuer une second restriction après l'opération d'agrégation.

Syntaxe

1 SELECT liste d'attributs de partionnement à projeter et de fonctions de calcul2 FROM liste de relations3 WHERE condition à appliquer avant calcul de l'agrégat4 GROUP BY liste ordonnée d'attributs de partitionnement5 HAVING condition sur les fonctions de calcul

Exemple

1 SELECT Societe.Nom, AVG(Personne.Age)2 FROM Personne, Societe3 WHERE Personne.NomSoc = Societe.Nom4 GROUP BY Societe.Nom5 HAVING COUNT(Personne.NumSS) > 2

Cette requête calcul l'âge moyen du personnel pour chaque société comportant plus de 2salariés.

c) Ordre de résolution des requête SQL

FondamentalL'ordre de résolution standard d'une requête SQL est :

1. FROM 2. WHERE 3. GROUP BY 4. HAVING 5. SELECT 6. ORDER BY

Attention : Usage des alias dans le GROUP BY ou le HAVING : requête non standard, acceptée par certains SGBD

1 SELECT substring(name,1,1) AS initiale, count(citycode)2 FROM city3 GROUP BY initiale;

1 initiale | count 2 ----------+-------3 L | 14 Z | 15 B | 16 M | 17 P | 28 A | 19

La requête n'est pas standard, les résolutions de l'alias et de la fonction substringsont dans le SELECT, qui est postérieur à la résolution du GROUP BY. Postgresacceptera néanmoins cette syntaxe, ce qui évite de créer une vue ou d'utiliser unesous-requête.


Stéphane Crozat 75

Remarque : RestrictionUne restriction peut être appliquée avant calcul de l'agrégat, au niveau de la clause WHERE,portant ainsi sur la relation de départ, mais aussi après calcul de l'agrégat sur les résultats dece dernier, au niveau de la clause HAVING.

Remarque : Utilisation de fonctions d'agrégationLes fonctions d'agrégation peuvent être utilisées dans la claude HAVING ou dans la clauseORDER BY. Les fonctions ne peuvent pas être utilisées dans la clause WHERE (qui est résoluavant le GROUP BY).

d) Re-représentation de représentants

[30 minutes]Soit le schéma relationnel suivant :

1 REPRESENTANTS (#NR, NOMR, VILLE)2 PRODUITS (#NP, NOMP, COUL, PDS)3 CLIENTS (#NC, NOMC, VILLE)4 VENTES (#NR=>REPRESENTANTS(NR), #NP=>PRODUITS(NP), #NC=>CLIENTS(NC), QT)

Écrire en SQL les requêtes permettant d'obtenir les informations suivantes.

1 /* Les requêtes peuvent être testées dans un SGBDR, en créant une base de donnéesavec le script SQL suivant */

23 /*4 DROP TABLE VENTES ;5 DROP TABLE CLIENTS ;6 DROP TABLE PRODUITS ;7 DROP TABLE REPRESENTANTS ;8 */9

10 CREATE TABLE REPRESENTANTS (11 NR INTEGER PRIMARY KEY,12 NOMR VARCHAR,13 VILLE VARCHAR14 );1516 CREATE TABLE PRODUITS (17 NP INTEGER PRIMARY KEY,18 NOMP VARCHAR,19 COUL VARCHAR,20 PDS INTEGER21 );2223 CREATE TABLE CLIENTS (24 NC INTEGER PRIMARY KEY,25 NOMC VARCHAR,26 VILLE VARCHAR27 );2829 CREATE TABLE VENTES (30 NR INTEGER REFERENCES REPRESENTANTS(NR),31 NP INTEGER REFERENCES PRODUITS(NP),32 NC INTEGER REFERENCES CLIENTS(NC),33 QT INTEGER,34 PRIMARY KEY (NR, NP, NC)35 );3637 INSERT INTO REPRESENTANTS (NR, NOMR, VILLE) VALUES (1, 'Stephane', 'Lyon');38 INSERT INTO REPRESENTANTS (NR, NOMR, VILLE) VALUES (2, 'Benjamin', 'Paris');39 INSERT INTO REPRESENTANTS (NR, NOMR, VILLE) VALUES (3, 'Leonard', 'Lyon');40 INSERT INTO REPRESENTANTS (NR, NOMR, VILLE) VALUES (4, 'Antoine', 'Brest');41 INSERT INTO REPRESENTANTS (NR, NOMR, VILLE) VALUES (5, 'Bruno', 'Bayonne');


Stéphane Crozat 76

4243 INSERT INTO PRODUITS (NP, NOMP, COUL, PDS) VALUES (1, 'Aspirateur', 'Rouge',

3546);44 INSERT INTO PRODUITS (NP, NOMP, COUL, PDS) VALUES (2, 'Trottinette', 'Bleu',

1423);45 INSERT INTO PRODUITS (NP, NOMP, COUL, PDS) VALUES (3, 'Chaise', 'Blanc', 3827);46 INSERT INTO PRODUITS (NP, NOMP, COUL, PDS) VALUES (4, 'Tapis', 'Rouge', 1423);4748 INSERT INTO CLIENTS (NC, NOMC, VILLE) VALUES (1, 'Alice', 'Lyon');49 INSERT INTO CLIENTS (NC, NOMC, VILLE) VALUES (2, 'Bruno', 'Lyon');50 INSERT INTO CLIENTS (NC, NOMC, VILLE) VALUES (3, 'Charles', 'Compiègne');51 INSERT INTO CLIENTS (NC, NOMC, VILLE) VALUES (4, 'Denis', 'Montpellier');52 INSERT INTO CLIENTS (NC, NOMC, VILLE) VALUES (5, 'Emile', 'Strasbourg');5354 INSERT INTO VENTES (NR, NP, NC, QT) VALUES (1, 1, 1, 1);55 INSERT INTO VENTES (NR, NP, NC, QT) VALUES (1, 1, 2, 1);56 INSERT INTO VENTES (NR, NP, NC, QT) VALUES (2, 2, 3, 1);57 INSERT INTO VENTES (NR, NP, NC, QT) VALUES (4, 3, 3, 200);58 INSERT INTO VENTES (NR, NP, NC, QT) VALUES (3, 4, 2, 190);59 INSERT INTO VENTES (NR, NP, NC, QT) VALUES (1, 3, 2, 300);60 INSERT INTO VENTES (NR, NP, NC, QT) VALUES (3, 1, 2, 120);61 INSERT INTO VENTES (NR, NP, NC, QT) VALUES (3, 1, 4, 120);62 INSERT INTO VENTES (NR, NP, NC, QT) VALUES (3, 4, 4, 2);63 INSERT INTO VENTES (NR, NP, NC, QT) VALUES (3, 1, 1, 3);64 INSERT INTO VENTES (NR, NP, NC, QT) VALUES (3, 4, 1, 5);65 INSERT INTO VENTES (NR, NP, NC, QT) VALUES (3, 1, 3, 1);

Q u e s t i o n 1Le nombre de clients.

Q u e s t i o n 2Le nombre de produits de couleur rouge.

Q u e s t i o n 3Le nombre de clients par ville.

Q u e s t i o n 4La quantité totale des produits rouge vendus par chaque représentant.

Q u e s t i o n 5La quantité totale de produits rouges vendus pour chaque représentant ayant vendu plus de 5fois des produits rouges (ayant réalisé plus de 5 ventes différentes de produits rouges).

B. Exercices

1. Location d'appartements en groupe

[20 min]Soit le schéma relationnel suivant gérant le fonctionnement d'une agence de locationd'appartements.

1 APPARTEMENT(#code_appt:String, adresse:String, type:{studio,F1,F2,F3,F4,F5+}, prix_loyer:Real)

2 LOCATAIRE(#code_loc:String, nom:String, prenom:String)3 LOCATION(#code_loc=>Locataire, #code_appt=>Appartement)4 PAIEMENT_LOYER(#code_loc=>Locataire, #code_appt=>Appartement,

#date_payement:Date, prix_paye:Real)


Stéphane Crozat 77

Q u e s t i o n 1En SQL afficher le nombre d'appartements de chaque type, uniquement pour les types quicommencent par la lettre F.

Q u e s t i o n 2

En SQL afficher le total payé par locataire (avec son code, nom et prenom) pour l'ensemble deses appartements.

Q u e s t i o n 3En SQL afficher les locataires (code uniquement) qui louent au moins 2 appartements, enprécisant le nombre d'appartements loués et la moyenne des loyers, et trié par ordredécroissant de cette moyenne.

2. Championnat de Formule 1

[20 min]La base de données suivante permet de gérer les résultats des courses de Formule 1 dans unchampionnat.

1 CHAMPIONNAT(#nom:string, annee:integer)2 CIRCUIT(#nom:string, ville:string)3 COURSE(#nom:string,circuit=>CIRCUIT(nom), championnat=>CHAMPIONNAT(nom))4 SPONSOR(#nom:string)5 ECURIE(#nom:string, devise:string, couleur:string, sponsor=>SPONSOR(nom))6 PILOTE(#id:integer, nom:string, prenom:string, ecurie=>ECURIE(nom))7 TOUR(#pilote => PILOTE(id), #course => COURSE(nom), #num:integer, duree:integer)

Q u e s t i o n 1

En algèbre relationnel et en SQL, afficher la liste de tous les pilotes dont le nom commence parla lettre 'D'.

Q u e s t i o n 2En SQL, afficher le nombre de pilotes par écurie en classant les résultats par ordrealphabétique des noms des écuries.

Q u e s t i o n 3

En algèbre relationnel et en SQL, afficher les noms des sponsors qui ne sont pas liés à uneécurie.

Q u e s t i o n 4En SQL, afficher le numéro, nom, prénom et écurie, avec leur temps moyen par tour, despilotes participant à la course Daytonutc 500 ; mais en ne conservant que les pilotes qui onteffectués au moins deux tours de piste, et en classant le résultat par temps moyendécroissant.

3. Questions scolaires

[30 min]Soit le schéma relationnel suivant gérant le fonctionnement d'une école et les notes desélèves.

1 CLASSE(#intitule)2 MATIERE(#intitule)3 ELEVE(#login, nom, prenom, age, classe=>CLASSE)4 ENSEIGNANT(#login, nom, prenom, mail, matiere=>MATIERE)5 ENSEIGNE(#enseignant=> ENSEIGNANT, #classe=>CLASSE)


Stéphane Crozat 78

6 NOTE(#eleve=>ELEVE, #enseignant=>ENSEIGNANT, #date_examen, note)78 Contrainte : un enseignant ne peut mettre une note à un élève que si celui-ci se

trouve dans une classe dans laquelle il enseigne.

NB : Nous n'utiliserons pas de sous-requêtes.

Q u e s t i o n 1

En algèbre relationnel et en SQL, afficher la liste des tous les étudiants dont le nom commencepar A.

Q u e s t i o n 2En algèbre relationnel et en SQL, afficher les noms et prénoms des enseignants quin'enseignent à aucune classe.

Q u e s t i o n 3

En SQL, affichez le nombre d'étudiants enregistrés en "Terminale S 2".

Q u e s t i o n 4

En SQL, affichez les logins, noms, prénoms, classes et moyennes des élèves en cours de"Mathématiques", par ordre décroissant de moyenne, à condition qu'ils aient au minimum 2notes dans cette matière.

Q u e s t i o n 5

En SQL, à des fins de statistiques, nous souhaitons rechercher par enseignant et par classe, lesclasses qui n'ont pas la moyenne générale, et afficher pour celles-ci : le nom, prénom et mailde l'enseignant en question, la matière enseignée, la classe, la moyenne d'âge des étudiantsavec les extrêmes (minimum et maximum), la moyenne générale de la classe avec les valeursextrêmes, ainsi que le nombre d'étudiants présents dans cette classe ; le tout classé par ordrealphabétique de classe, puis de nom et de prénom de l'enseignant.

Indice :

On fera l'hypothèse que tous les étudiants d'une classe ont le même nombre de notes(pas d'absence aux examens).

4. Quiz : SQL LMD

Exercice 1Parmi les assertions suivantes concernant le langage SQL, sélectionner celles qui sontcorrectes.


Stéphane Crozat 79

Le langage SQL permet d'implémenter physiquement un modèle logique exprimé enrelationnel.

Le langage SQL permet d'entrer et de sortir des données d'une base de données.

Le langage SQL permet de donner et d'enlever des droits en lecture sur les donnéesd'une base de données.

Le langage SQL permet de donner et d'enlever des droits en écriture sur les donnéesd'une base de données.

Le langage SQL permet de créer une interface graphique utilisable par les utilisateursfinaux.

Le langage SQL permet de faire des traitements algorithmiques complexes.

Le langage SQL permet en général de créer une application informatique complète.

Exercice 2Soit les deux relations suivantes UV1 et UV2 représentant respectivement les placesdisponibles dans les cours de l'UTC et les inscriptions effectives pour les cours ouverts cesemestre :

Nom Nombre Nom NombreNF17 168 NF17 182NF18 48 NF18 46NF19 48 NF19 44NF20 48 NF22 98NF21 48 UV2 : InscriptionsNF22 168

UV1 : Place disponibles

Tableau 4 Relations UV1 et UV2

Compléter la requête SQL suivante pour qu'elle retourne pour tous les cours avec leur nom,plus le nombre d'inscrits en excès ou en défaut pour les cours ouverts et NULL pour les coursfermés.SELECT UV1.Nom,

FROM UV1 UV2

ON

Exercice 3Soit les deux relations suivantes UV1 et UV2 représentant respectivement les placesdisponibles dans les cours de l'UTC et les inscriptions effectives pour les cours ouverts cesemestre :

Nom Nombre Nom NombreNF17 168 NF17 182NF18 48 NF18 46NF19 48 NF19 44NF20 48 NF22 98NF21 48 UV2 : InscriptionsNF22 168

UV1 : Place disponibles

Tableau 5 Relations UV1 et UV2

Compléter la requête SQL suivante pour qu'elle retourne, pour les cours ouverts uniquement,le nombre d'inscrits moyen selon le nombre de places (nombre d'inscrits moyens pour lescours de 168 places, pour ceux de 48 places, etc.)


Stéphane Crozat 80

SELECT UV1.Nombre,

FROM UV1 UV2

ON

Exercice 4Quelle sont les requêtes équivalente à la requête ci-dessous :

1 SELECT Nom2 FROM Personne3 WHERE NOT(Nom IS NULL)4 GROUP BY Nom

SELECT DISTINCT NomFROM PersonneWHERE Nom LIKE '%'

SELECT NomFROM Personne

SELECT NomFROM PersonneGROUP BY NomHAVING Count(Nom) > 0

SELECT NomFROM PersonneWHERE NOT(Nom IS NULL)

Exercice 5Que renvoie la dernière instruction SQL de la séquence ci-dessous ?

1 CREATE TABLE R (a INTEGER, b INTEGER);2 INSERT INTO R VALUES (1,1);3 INSERT INTO R VALUES (1,2);4 INSERT INTO R VALUES (3,3);5 SELECT sum(R1.b) FROM R R1, R R2 WHERE R1.a=R2.a;


Stéphane Crozat 81

VI - Vues et gestion des droits

VI

A. Cours

1. Notion de schéma externe et de vue

a) Exercice : Problème de vue

Soit la vue V suivante, sélectionner toutes les assertions correctes.

1 CREATE VIEW V (n, p) AS SELECT nom, prenom FROM T ;

Le contenu de la table T est calculé dynamiquement à partir de la vue V.

Le contenu de la table T est stocké directement dans la base de données.

Le contenu de la vue V est calculé dynamiquement à partir de la table T.

Le contenu de la vue V est stocké directement dans la base de données.

La requête SELECT n FROM V est valide.

La requête SELECT nom FROM V est valide.

L'instruction CREATE VIEW V2 (n) AS SELECT n FROM V est valide.

b) Schéma externe

L'architecture ANSI/SPARC est à l'origine de la conception des SGBDR, elle postule deuxprincipes fondamentaux : la séparation logique/physique et la notion de schéma externe.

Rappel : La séparation du niveau logique et du niveau physiqueL'utilisateur du SGBDR ne se préoccupe pas de la façon dont celui-ci est implémenté, ilraisonne directement en relationnel grâce au langage SQL.

Notion de schéma externeLe schéma relationnel de la base de données intègre toutes les données que la base gère pourtoutes les applications d'une organisation. Or chaque application n'utilise en général qu'unepartie de ces données.On souhaite que chaque application ne voit que la partie des données qui la concerne :

pour des raisons de simplicité (la complexité globale lui est masquée)

Stéphane Crozat 82

pour des raisons de sécurité (on ne souhaite pas qu'une application accède à desdonnées qui ne la concerne pas).

Schémas interne et externes

DéfinitionOn appelle schéma externe un sous-ensemble du schéma intégral, destiné à une utilisationspécifique de la base de données.Dans les SGBDR les schémas externes sont implémentés par des vues.

c) Création de vues en SQL (CREATE VIEW)

Définition : VueUne vue est une définition logique d'une relation, sans stockage de données, obtenue parinterrogation d'une ou plusieurs tables de la BD. Une vue peut donc être perçue comme unefenêtre dynamique sur les données, ou encore une requête stockée (mais dont seule ladéfinition est stockée, pas le résultat, qui reste calculé dynamiquement).Une vue permet d'implémenter le concept de schéma externe d'un modèle conceptuel.Synonymes : Relation dérivée, Table virtuelle calculée

Syntaxe

1 CREATE VIEW <nom de vue> <nom des colonnes>2 AS <spécification de question>

La spécification d'une question se fait en utilisant le LMD.Le nombre de colonnes nommées doit être égal au nombre de colonnes renvoyées par laquestion spécifiée. Le nom des colonnes est optionnel, s'il n'est pas spécifié, c'est le nom descolonnes telle qu'elles sont renvoyées par la question, qui sera utilisé.

Exemple

1 CREATE VIEW Employe (Id, Nom) 2 AS 3 SELECT N°SS, Nom4 FROM Personne

La vue Employe est ici une projection de la relation Personne sur les attributs N°SS et Nom,renommés respectivement Id et Nom.

Remarque : Vue en lecture et vue en écritureUne vue est toujours disponible en lecture, à condition que l'utilisateur ait les droits spécifiésgrâce au LCD. Une vue peut également être disponible en écriture dans certains cas, que l'onpeut restreindre aux cas où la question ne porte que sur une seule table (même si danscertains cas, il est possible de modifier une vue issue de plusieurs tables).Dans le cas où une vue est destinée à être utilisée pour modifier des données, il est possibled'ajouter la clause "WITH CHECK OPTION" après la spécification de question, pour préciser queles données modifiées ou ajoutées doivent effectivement appartenir à la vue.

Vues et gestion des droits

Stéphane Crozat 83

Remarque : Vue sur une vueUne vue peut avoir comme source une autre vue.

Rappel : Vues et héritageLes vues sont particulièrement utiles pour restituer les relations d'héritage perdues lors de latransformation MCD vers MLD.

2. Passage UML-Relationnel : Expression des vues pour l'héritage et les méthodes

Objectifs

Savoir ajouter des vues pour améliorer l'expression de l'héritageen relationnel.

a) Héritage par une référence et vues

RappelTransformation de la relation d'héritage par référence

MéthodeUne vue est créée pour chaque classe fille en réalisant une jointure avec la classe mère.

c {key}d

Classe2

e {key}f

Classe3

a {key}b

Classe1


Classe1(#a,b)


Classe3(#a=>Classe1,e,f) avec e KEYvClasse2=jointure(Classe1,Classe2,a=a)

vClasse3=jointure(Classe1,Classe3,a=a)

ExempleSoit la classe A avec la clé K et les attributs A1 et A2. Soit la classe B, classe fille de A,comprenant la clé K' et les attributs B1 et B2. Le modèle relationnel correspondant selon cette transformation est :

1 A (#K, A1, A2)2 B (#K=>A, K', B1, B2)3 vB = Jointure (A, B, A.K=B.K)

Complément : Algèbre relationnelJointure


Stéphane Crozat 84

b) Héritage par les classes filles et vuesRappelTransformation de la relation d'héritage par les classes filles

Méthode : Héritage absorbé par les classes filles (classe mère abstraite)

c {key}d

Classe2

e {key}f

Classe3

a {key}b

Classe1



vClasse1=Union(Projection(Classe2,a,b),Projection(Classe3,a,b))

Méthode : Héritage absorbé par les classes filles (classe mère non abstraite)

c {key}d

Classe2

e {key}f

Classe3

a {key}b

Classe1


Classe1(#a,b)


vClasse1=Union(Union(Classe1,Projection(Classe2,a,b)),Projection(Classe3,a,b))

Exemple : Héritage absorbé par les classes fillesSoit la classe abstraite A avec la clé K et les attributs A1 et A2. Soit la classe B, classe fille deA avec les attributs B1 et B2. Soit la classe C, classe fille de A avec les attributs C1 et C2.Le modèle relationnel correspondant selon cette transformation est :

1 B (#K, A1, A2, B1, B2)2 C (#K, A1, A2, C1, C2)3 vA = Union (Projection (B, K, A1, A2), Projection (C, K, A1, A2))

Complément : Algèbre relationnelOpérateurs ensemblistesProjection


Stéphane Crozat 85

c) Héritage par la classe mère et vuesRappelTransformation de la relation d'héritage par la classe mère

MéthodeChaque classe est représentée par une vue qui restreint aux tuples de la relationcorrespondants et les projette sur les attributs correspondants.

c {key}d

Classe2

e {key}f

Classe3

a {key}b

Classe1


Classe1(#a,b,c,d,e,f,t:{1,2,3,23}) avec c UNIQUE et e UNIQUE

vClasse1=projection(restriction(Classe1,t=1),a,b)

vClasse2=projection(restriction(Classe1,t=2),a,b,c,d)

vClasse3=projection(restriction(Classe1,t=3),a,b,e,f)

Exemple : Héritage absorbé par la classe mèreSoit la classe A abstraite avec la clé K et les attributs A1 et A2. Soit la classe B, classe fille deA avec les attributs B1 et B2. Soit la classe C, classe fille de A avec les attributs C1 et C.Le modèle relationnel correspondant selon cette transformation est :

1 A (#K, A1, A2, B1, B2, C1, C2, T:{'B','C'})2 vB = Projection (Restriction (A, T='B'), K, A1, A2, B1, B2)3 vC = Projection (Restriction (A, T='C'), K, A1, A2, C1, C2)

Complément : Algèbre relationnelProjectionRestriction

d) Transformation des méthodes par des vues

MéthodeLorsqu'une méthode est spécifiée sur un diagramme UML pour une classe C, si cette méthodeest une fonction relationnelle (elle renvoie une unique valeur et elle peut être résolue par unerequête SQL), alors on crée une vue qui reprend les attributs de la classe C et ajoute descolonnes calculées pour les méthodes.

Remarque : Attributs dérivésLes attributs dérivés étant apparentés à des méthodes, ils peuvent également être gérés pardes vues.

e) Évaluation des enseignants

A la fin du semestre, chaque enseignant est évalué par les étudiants pour chacune de ses UV.Chaque note correspond à une UV assurée par cet enseignant, et est égale à la moyenne desévaluations attribuées par les étudiants de l’UV. Dans le relevé de note apparaît une


Stéphane Crozat 86

appréciation générale sur l’enseignant. Cette appréciation est la moyenne de toutes les notesde l’enseignant pour toutes ses UV. La figure suivante illustre le diagramme de classe et lemodèle relationnel associé, qui modélisent l’ « évaluation des enseignants ».

Image 27 Diagramme de classe

1 Enseignant(NSS, Nom, Prenom) ;2 UV(Code, Intitulé, Prof=>Enseignant) ;3 Etudiant(NumEtu, Nom, Prenom) ;4 Evaluer(NumEtu=>Etudiant, uv=>UV, Evaluation) ;

Q u e s t i o n 1

Écrire la vue SQL qui permet de calculer les notes de chaque UV et donnant le résultat ci-dessous : méthode UV.Note()

NOM PRENOM INTITULE NOTE

Dupont Jean Science de la Terre 15

Dupont Jean Informatique 7.5

Durand Paul Français 5

Tableau 6 Notes pour chaque UV

Q u e s t i o n 2Écrire la vue SQL qui permet d’afficher les enseignants avec leur appréciation générale :méthode Enseignant.Appreciation()


Stéphane Crozat 87

NOM PRENOM APPRECIATION

Dupont Jean 11,25

Durand Paul 5Appréciation pour chaque enseignant

3. Le Langage de Contrôle de Données de SQL

Objectifs

Maîtriser les bases du SQL pour attribuer et révoquer des droitssur des objets d'une base de données.

Le LCD permet de créer les utilisateurs et de définir leurs droits sur les objets de la BD defaçon déclarative. Il permet notamment l'attribution et la révocation de droits à desutilisateurs, sur l'ensemble des bases du SGBD, sur une BD en particulier, sur des relationsd'une BD, voire sur certains attributs seulement d'une relation.

a) Exercice : Les droits Lambda

Quelles sont les instructions SQL (sous-ensemble LMD) autorisées pour l'utilisateur "Lambda",étant données les instructions SQL (sous-ensemble LCD) suivantes, exécutéesantérieurement ?

1 REVOKE ALL PRIVILEGES ON * FROM Lambda;2 GRANT UPDATE, SELECT ON a TO Lambda;3 GRANT SELECT ON b TO Lambda;

SELECT a.x, b.yFROM a,bWHERE a.x=b.x

UPDATE bSET y='y'WHERE y='x'

UPDATE aSET x='x'WHERE x='y'

CREATE TABLE c (x CHAR(50),y CHAR(50))

SELECT a.x, c.yFROM a,cWHERE a.x=c.x

INSERT INTO a (x)VALUES ('y')


Stéphane Crozat 88

b) Attribution de droitsSQL propose une commande pour attribuer des droits à des utilisateurs sur des tables.

Syntaxe

1 GRANT <liste de droits> ON <nom table> TO <utilisateur> [WITH GRANT OPTION]

Les droits disponibles renvoient directement aux instructions SQL que l'utilisateur peutexécuter :

SELECT

INSERT

DELETE

UPDATE

ALTER

De plus il est possible de spécifier le droit ALL PRIVILEGES qui donne tous les droits àl'utilisateur (sauf celui de transmettre ses droits).La clause WITH GRANT OPTION est optionnelle, elle permet de préciser que l'utilisateur a ledroit de transférer ses propres droits sur la table à d'autres utilisateur. Une telle clause permetune gestion décentralisée de l'attribution des droits et non reposant uniquement dans lesmains d'un administrateur unique.La spécification PUBLIC à la place d'un nom d'utilisateur permet de donner les droits spécifiés àtous les utilisateurs de la BD.

Exemple

1 GRANT SELECT, UPDATE ON Personne TO Pierre;2 GRANT ALL PRIVILEGES ON Adresse TO PUBLIC;

Remarque : Droits sur une vueIl est possible de spécifier des droits sur des vues plutôt que sur des tables, avec une syntaxeidentique (et un nom de vue à la place d'un nom de table).

Remarque : Catalogue de donnéesLes droits sont stockés dans le catalogue des données, il est généralement possible de modifierdirectement ce catalogue à la place d'utiliser la commande GRANT. Cela reste néanmoinsdéconseillé.

Remarque : Création des utilisateursLes modalités de création d'utilisateurs, voire de groupes d'utilisateurs dans le SGBD, restedépendantes de celui-ci. Des commande SQL peuvent être disponibles, telles que CREATEUSER, ou bien la commande GRANT lorsque qu'elle porte sur un utilisateur non existant peutêtre chargée de créer cet utilisateur. Des modules spécifiques d'administration sontgénéralement disponibles pour prendre en charge la gestion des utilisateurs.

c) Révocation de droits

SQL propose une commande pour révoquer les droits attribués à des utilisateurs.

Syntaxe

1 REVOKE <liste de droits> ON <nom table> FROM <utilisateur>


Stéphane Crozat 89

Exemple

1 REVOKE SELECT, UPDATE ON Personne FROM Pierre;2 REVOKE ALL PRIVILEGES ON Adresse FROM PUBLIC;

Remarque : Révocation du droit de donner les droitsPour retirer les droits de donner les droits à un utilisateur (qui l'a donc obtenu par la clauseWITH GRANT OPTION), il faut utiliser la valeur GRANT OPTION dans la liste des droitsrévoqués.

Remarque : Révocation en cascadeLorsque qu'un droit est supprimé pour un utilisateur, il l'est également pour tous lesutilisateurs qui avait obtenu ce même droit par l'utilisateur en question.

d) Création d'utilisateurs

Le standard SQL laisse la gestion des utilisateurs à la discrétion du SGBD.Néanmoins le commande CREATE USER est couramment proposée (Oracle, Postgres, ...).

e) The show must go on

[10 minutes]Soit la base de données suivantes :

1 SPECTACLE (#nospectacle:int, nom:str, durée:int, type:{théâtre|danse|concert})2 SALLE (#nosalle:int, nbplaces:int)3 REPRESENTATION (#date:date, #nospectacle=>SPECTACLE, #nosalle=>SALLE,

prix:decimal)

On suppose des classes d'utilisateurs qui ont accès à tout ou partie de ce schéma relationnel : Le programmateur qui entre les spectacles dans la base de données,

Le régisseur qui gère les salles et les représentations,

Les clients qui peuvent accéder au programme.

Q u e s t i o n

Donner les droits associés à chaque classe d'utilisateurs.

B. Exercice

1. Du producteur au consommateur++

[30 min]Soit la base de données suivante :

1 CREATE TABLE Producteur (2 raison_sociale VARCHAR (25),3 ville VARCHAR(255),4 PRIMARY KEY (raison_sociale)5 );67 CREATE TABLE Consommateur (8 login VARCHAR(10),9 email VARCHAR(50),


Stéphane Crozat 90

10 nom VARCHAR(50) NOT NULL,11 prenom VARCHAR(50) NOT NULL,12 ville VARCHAR(255) NOT NULL,13 PRIMARY KEY (login,email),14 UNIQUE (nom,prenom,ville)15 );1617 CREATE TABLE Produit (18 id INTEGER,19 description VARCHAR(100),20 produit_par VARCHAR(25) NOT NULL,21 consomme_par_login VARCHAR(10),22 consomme_par_email VARCHAR(50),23 PRIMARY KEY (id),24 FOREIGN KEY (produit_par) REFERENCES Producteur(raison_sociale),25 FOREIGN KEY (consomme_par_login,consomme_par_email) REFERENCES

Consommateur(login,email)26 );

Q u e s t i o n 1

Établissez les instructions LCD permettant d'attribuer : les droits en lecture seule pour tous les utilisateurs pour la table Produit

les droits en lecture et en écriture pour l'utilisateur Admin sur toutes les tables.

Q u e s t i o n 2

Afin d'alimenter une application de suivi nommée Big Brother écrivez les trois vues SQL LMDpermettant de connaître :

Les produits produits et consommés dans la même ville

Les produits qui ne sont pas consommés

Le nombre de produits produits par chaque producteur

Établissez un schéma externe limité à ces trois vues pour l'utilisateur BB (sous lequel seconnecte l'application Big Brother).

2. Gauloiseries

[30 minutes]Un vieux druide perdant la mémoire souhaite réaliser une base de données pour se souvenirde la composition de ses potions. Un de ses apprentis ayant suivi un cours sur les bases dedonnées lors de son initiation druidique, il réalise le schéma conceptuel suivant :

Image 28 Potion : modèle UML

Vous pouvez tester vos requêtes directement sur votre base de données en l'initialisant avec lefichier de données.

1 /**2 DROP TABLE Composition ;3 DROP TABLE Ingredient ;4 DROP TABLE Potion ;


Stéphane Crozat 91

5 **/67 CREATE TABLE Potion (8 Nom VARCHAR PRIMARY KEY,9 Effet VARCHAR,

10 Duree INTEGER11 );1213 CREATE TABLE Ingredient (14 Nom VARCHAR PRIMARY KEY,15 Localisation VARCHAR16 );1718 CREATE TABLE Composition (19 NomP VARCHAR REFERENCES Potion(Nom),20 NomI VARCHAR REFERENCES Ingredient(Nom),21 PRIMARY KEY (NomP, NomI)22 );2324 INSERT INTO Potion (Nom, Effet, Duree) VALUES ('Potion Magique','Force', 60);25 INSERT INTO Ingredient (Nom, Localisation) VALUES ('Eau', 'Partout');26 INSERT INTO Ingredient (Nom, Localisation) VALUES ('Gui', 'Forêt');27 INSERT INTO Ingredient (Nom, Localisation) VALUES ('Pomme', 'Pommier');28 INSERT INTO Composition (NomP, NomI) VALUES ('Potion Magique', 'Eau');29 INSERT INTO Composition (NomP, NomI) VALUES ('Potion Magique', 'Gui');30 INSERT INTO Composition (NomP, NomI) VALUES ('Potion Magique', 'Pomme');31 INSERT INTO Ingredient (Nom, Localisation) VALUES ('Bière', 'Pic');32 INSERT INTO Potion (Nom, Effet, Duree) VALUES ('Potion Inutile','Rien', 0);33 INSERT INTO Composition (NomP, NomI) VALUES ('Potion Inutile', 'Eau');34 INSERT INTO Potion (Nom, Effet, Duree) VALUES ('Eau Aromatisée','Goût', 10);35 INSERT INTO Composition (NomP, NomI) VALUES ('Eau Aromatisée', 'Eau');36 INSERT INTO Composition (NomP, NomI) VALUES ('Eau Aromatisée', 'Gui');

Q u e s t i o n 1Réaliser le modèle logique correspondant en relationnel, en faisant apparaître les clésprimaires et étrangères (sans clé artificielle).

Q u e s t i o n 2

Écrivez une requête SQL permettant de trouver la recette de la potion magique.

Q u e s t i o n 3

Qu'a-t-on gagné à ne pas avoir utilisé de clé artificielle dans notre modèle relationnel ?

Q u e s t i o n 4

Écrivez une requête SQL permettant de trouver les ingrédients utilisés par aucune potion.

Q u e s t i o n 5

Écrivez une vue SQL permettant de préparer l'implémentation de la méthode NbIngrédients.Cette vue devra renvoyer le nombre d'ingrédients pour chaque potion.

Q u e s t i o n 6Critiquez le schéma conceptuel de l'apprenti : Est-ce qu'un même ingrédient peut apparaîtredeux fois dans la même potion ? Peut-on gérer la quantité d'ingrédients pour chaque potion ?Proposer une solution et redessiner le schéma conceptuel en Entité-Association, en y intégrantvotre amélioration.


Stéphane Crozat 92

VII - Théorie de la normalisation relationnelle

VII

A. Cours

La théorie de la normalisation relationnelle est très importante pour la conception de BD,dans la mesure où elle donne le cadre théorique pour la gestion de la redondance, et dans lamesure où une bonne maîtrise de la redondance est un aspect majeur de cette conception.

1. Redondance et normalisation

Objectifs

Comprendre la problématique de la redondance.

a) Introduction à la redondance

Soit la relation R suivante, définie en extension :

A B C D E F G

0 1 1 10 5 X A

0 2 1 10 9 X G

0 1 2 10 6 X S

0 1 3 10 7 X D

1 2 3 20 7 Y D

0 3 3 10 9 X G

1 4 3 20 8 Y F

1 1 4 20 9 Y G

Tableau 7 Relation R

Stéphane Crozat 93

Q u e s t i o n 1Proposez des clés pour cette relation. Justifiez brièvement.

Q u e s t i o n 2Cette relation contient-elle des redondances ? Si oui lesquelles ? Justifiez brièvement.

Q u e s t i o n 3Si la relation contient des redondances, proposez une solution contenant exactement la mêmeinformation, mais sans redondance.

b) Les problèmes soulevés par une mauvaise modélisation

AttentionIl y a toujours plusieurs façons de modéliser conceptuellement un problème,certaines sont bonnes et d'autres mauvaises. C'est l'expertise de l'ingénieur encharge de la modélisation, à travers son expérience accumulée et sa capacité àtraduire le problème posé, qui permet d'obtenir de bons modèles conceptuels.S'il est difficile de définir un bon modèle conceptuel, on peut en revanche poser qu'un bonmodèle logique relationnel est un modèle où la redondance est contrôlée. On peut alors poser qu'un bon modèle conceptuel est un modèle conceptuel qui conduit à unbon modèle relationnel, après application des règles de passage E-A ou UML vers relationnel.Mais on ne sait pas pour autant le critiquer avant ce passage, autrement qu'à travers l’œil d'unexpert.A défaut de disposer d'outils systématiques pour obtenir de bons modèles conceptuels, oncherche donc à critiquer les modèles relationnels obtenus. La théorie de la normalisation est une théorie qui permet de critiquer, puis d'optimiser, desmodèles relationnels, de façon à en contrôler la redondance.

Exemple : Un mauvais modèle relationnelImaginons que nous souhaitions représenter des personnes, identifiées par leur numéro desécurité sociale, caractérisées par leur nom, leur prénom, ainsi que les véhicule qu'elles ontacheté, pour un certain prix et à une certaine date, sachant qu'un véhicule est caractérisé parson numéro d'immatriculation, un type, une marque et une puissance. On peut aboutir à lareprésentation relationnelle suivante :

1 Personne(NSS, Nom, Prénom, Immat, Marque, Type, Puiss, Date, Prix)

Posons que cette relation soit remplie par les données suivantes :

NSS Nom Prénom Immat Marque Type Puiss Date Prix

16607... Dupont Paul AJ600AQ Renault Clio 5 1/1/96 60000

16607... Dupont Paul AA751KK Peugeot 504 7 2/7/75 47300

24908... Martin Marie AA751KK Peugeot 504 7 1/10/89 54900

15405... Durand Olivier AA751KK Peugeot 504 7 8/8/90 12000

15405... Durand Olivier AJ600AQ Renault Clio 5 7/6/98 65000

15405... Durand Olivier XX100XX BMW 520 10 4/5/01 98000

Tableau 8 Relation redondante

On peut alors se rendre compte que des redondances sont présentes, si l'on connaît NSS onconnaît Nom et Prénom, si on connaît Immat, on connaît Marque, Type et Puiss.

Théorie de la normalisation relationnelle

Stéphane Crozat 94

NSS Nom Prénom Immat Marque Type Puiss Date Prix

16607... Dupont Paul AJ600AQ Renault Clio 5 1/1/96 60000

16607... Dupont Paul AA751KK Peugeot 504 7 2/7/75 47300

24908... Martin Marie AA751KK Peugeot 504 7 1/10/89 54900

15405... Durand Olivier AA751KK Peugeot 504 7 8/8/90 12000

15405... Durand Olivier AJ600AQ Renault Clio 5 7/6/98 65000

15405... Durand Olivier XX100XX BMW 520 10 4/5/01 98000

Relation redondante

On sait que ces redondances conduiront à des problèmes de contrôle de la cohérence del'information (erreur dans la saisie d'un numéro de sécurité sociale), de mise à jour(changement de nom à reporter dans de multiples tuples), de perte d'information lors de lasuppression de données (disparition des informations concernant un type de véhicule) et dedifficulté à représenter certaines informations (un type de véhicule sans propriétaire).

ComplémentOn conseillera de lire le chapitre 2 de SQL2 SQL3, applications à Oracle [Delmal01] (pages 42à 49) qui propose une très bonne démonstration par l'exemple des problèmes posés par unemauvaise modélisation relationnelle.

c) Principes de la normalisation

FondamentalLa théorie de la normalisation est une théorie destinée à concevoir un bon schémad’une base de données sans redondance d’information et sans risques d'anomalie demise à jour. Elle a été introduite dès l'origine dans le modèle relationnel.La théorie de la normalisation est fondée sur deux concepts principaux :

Les dépendances fonctionnelles

Elles traduisent des contraintes sur les données. Les formes normales

Elles définissent des relations bien conçues.La mise en œuvre de la normalisation est fondée sur la décomposition progressive desrelations jusqu'à obtenir des relations normalisées.

2. Les dépendances fonctionnelles

Objectifs

Savoir repérer et exprimer des dépendances fonctionnelles.Définir une clé par les dépendances fonctionnelles.

a) Exercice : A1, dans l'eau !

Considérons le schéma de la relation suivante : r (A, B, C, D, E)


Stéphane Crozat 95

Cette relation est définie en intension par les tuples suivants :

A B C D E

a1 b2 c2 d3 e2

a1 b2 c2 d1 e4

a2 b3 c2 d1 e5

a2 b4 c5 d1 e5

Parmi les dépendances fonctionnelles suivantes, lesquelles s'appliquent à r ?

E D→

D E→

C A →

E B →

E A →

B C →

B D →

B A →

b) Dépendance fonctionnelle

Définition : Dépendance fonctionnelleSoient R(A1, A2, ... , An) un schéma de relation, X et Y des sous-ensembles de A1, A2, ... ,An. On dit que X détermine Y, ou que Y dépend fonctionnellement de X, si et seulement s'ilexiste une fonction qui à partir de toute valeur de X détermine une valeur unique de Y.Plus formellement on pose que X détermine Y pour une relation R si et seulement si quelle quesoit l'instance r de R, alors pour tous tuples t1 et t2 de r on a : Projection (t1,X) = Projection (t2,X) Projection (t1,Y) = Projection (t2,Y)⇒

SyntaxeSi X détermine Y, on note : X Y→

ExempleSoit la relation R suivante :

1 Personne(NSS, Nom, Prénom, Marque, Type, Puiss, Date, Prix)

On peut poser les exemples de DF suivants : NSS Nom→


Stéphane Crozat 96

NSS Prénom→

Type Marque→

Type Puiss→

(NSS, Type, Date) Prix→

etc.

Remarque : Comment trouver les DF ?Une DF est définie sur l'intension du schéma et non son extension. Une DF traduit une certaineperception de la réalité. Ainsi la DF (NSS, Type, Date) Prix signifie que personne n'achète→deux voitures du même type à la même date. La seule manière de déterminer une DF est donc de regarder soigneusement ce que signifientles attributs et de trouver les contraintes qui les lient dans le monde réel.

Remarque : Pourquoi trouver les DF ?Les DF font partie du schéma d'une BD, en conséquence, elles doivent être déclarées par lesadministrateurs de la BD et être contrôlées par le SGBD.De plus l'identification des DF est la base indispensable pour déterminer dans quelle formenormale est une relation et comment en diminuer la redondance.

c) Les axiomes d'Armstrong

IntroductionLes DF obéissent à des propriétés mathématiques particulières, dites axiomes d'Armstrong.

Définition : RéflexivitéTout groupe d'attributs se détermine lui même et détermine chacun de ses attributs (ou sousgroupe de ses attributs).Soient X et Y des attributs : XY XY et XY X et XY Y→ → →

Définition : AugmentationSi un attribut X détermine un attribut Y, alors tout groupe composé de X enrichi avec d'autresattributs détermine un groupe composé de Y et enrichi des mêmes autres attributs.Soient X, Y et Z des attributs : X Y XZ YZ→ ⇒ →

Définition : TransitivitéSi un attribut X détermine un attribut Y et que cet attribut Y détermine un autre attribut Z,alors X détermine Z.Soient X, Y et Z des attributs : X Y et Y Z X Z→ → ⇒ →

d) Autres propriétés déduites des axiomes d'Armstrong

IntroductionA partir des axiomes d'Amstrong, on peut déduire un certain nombre de propriétéssupplémentaires.


Stéphane Crozat 97

Définition : Pseudo-transitivitéSi un attribut X détermine un autre attribut Y, et que Y appartient à un groupe G qui détermineun troisième attribut Z, alors le groupe G' obtenu en substituant Y par X dans G détermineégalement Z.Soient, W, X, Y et Z des attributs :X Y et WY Z WX Z→ → ⇒ →

Cette propriété est déduite de l'augmentation et de la réflexivité :X Y et WY Z WX WY et WY Z WX Z→ → ⇒ → → ⇒ →

Définition : UnionSi un attribut détermine plusieurs autres attributs, alors il détermine tout groupe composé deces attributs.Soient X, Y et Z des attributs :X Y et X Z X YZ→ → ⇒ →

Cette propriété est déduite de la réflexivité, de l'augmentation et de la transitivité :X Y et X Z X XX et XX XY et YX YZ X YZ → → ⇒ → → → ⇒ →

Définition : DécompositionSi un attribut détermine un groupe d'attribut, alors il détermine chacun des attributs de cegroupe pris individuellement.Soient X, Y et Z des attributs :X YZ X Z et X Y→ ⇒ → →

Cette propriété est déduite de la réflexivité et de la transitivité :X YZ X YZ et YZ Z X Z→ ⇒ → → ⇒ →

e) DF élémentaire

Définition : Dépendance fonctionnelle élémentaireSoit G un groupe d'attributs et A un attribut, une DF G A est élémentaire si A n'est pas→incluse dans G et s'il n'existe pas d'attribut A' de G qui détermine A.

Exemple : DF élémentaires AB C est élémentaire si ni A, ni B pris individuellement ne déterminent C.→

Nom, DateNaissance, LieuNaissance Prénom est élémentaire.→

Exemple : DF non élémentaires AB A n'est pas élémentaire car A est incluse dans AB.→

AB CB n'est pas élémentaire car CB n'est pas un attribut, mais un groupe d'attributs.→

N°SS Nom, Prénom n'est pas élémentaire.→

RemarqueOn peut toujours réécrire un ensemble de DF en un ensemble de DFE, en supprimant les DFtriviales obtenues par réflexivité et en décomposant les DF à partie droite non atomique enplusieurs DFE.

Exemple : Réécriture de DF en DFEOn peut réécrire les DF non élémentaires de l'exemple précédent en les décomposant DFE :

AB A n'est pas considérée car c'est une DF triviale obtenu par réflexivité.→

AB CB est décomposée en AB C et AB B, et AB B n'est plus considérée car triviale.→ → → →

N°SS Nom, Prénom est décomposée en N°SS Nom et N°SS Prénom.→ → →


Stéphane Crozat 98

f) Notion de fermeture transitive des DFEDéfinition : Fermeture transitiveOn appelle fermeture transitive F+ d'un ensemble F de DFE, l'ensemble de toutes les DFE quipeuvent être composées par transitivité à partir des DFE de F.

ExempleSoit l'ensemble F = {A B, B C, B D, A E}.→ → → →

La fermeture transitive de F est F+ = { A B, B C, B D, A E, A C, A D }→ → → → → →

g) Notion de couverture minimale des DFE

Définition : Couverture minimaleLa couverture minimale d’un ensemble de DFE est un sous-ensemble minimum des DFEpermettant de générer toutes les autres DFE.Synonymes : Famille génératrice

RemarqueTout ensemble de DFE (et donc tout ensemble de DF) admet au moins une couvertureminimale (et en pratique souvent plusieurs).

ExempleL'ensemble F = {A B, A C, B C, C B} admet les deux couvertures minimales :→ → → →

CM1 = {A C, B C, C B} et CM2 = {A B, B C, C B}→ → → → → →

h) Notion de graphe des DFE

On peut représenter un ensemble de DFE par un graphe orienté (ou plus précisément unréseau de Pétri), tel que les nœuds sont les attributs et les arcs les DFE (avec un seul attributen destination de chaque arc et éventuellement plusieurs en source).

Exemple : Relation VoitureSoit la relation Voiture(NVH, Marque, Type, Puis, Couleur) avec l'ensemble des DF F ={NVH Type, Type Marque, Type Puis, NVH Couleur}. On peut représenter F par le graphe→ → → →ci-dessous :

Image 29 Graphe des DFE de la relation Voiture


Stéphane Crozat 99

Exemple : Relation CodePostalSoit la relation CodePostal(Code, Ville, Rue ) avec l'ensemble des DF F={Code Ville,→(Ville,Rue) Code}. On peut réprésenter F par le graphe ci-dessous : →

Image 30 Graphe des DFE de la relation CodePostal

i) Définition formelle d'une clé

Définition : CléSoient une relation R(A1,A2,...,An) et K un sous-ensemble de A1,A2,... ,An. K est une clé de R si et seulement si :

1. K A1,A2,...,An → 2. et il n'existe pas X inclus dans K tel que X A1,A2,...,An.→

FondamentalUne clé est donc un ensemble minimum d'attributs d'une relation qui détermine tousles autres.

Remarque : Clés candidates et clé primaireSi une relation comporte plusieurs clés, chacune est dite clé candidate et l'on en choisit une enparticulier pour être la clé primaire.

Attention : Les clés candidates sont des clés !Toutes les clés candidates sont des clés, pas seulement la clé primaire.

Remarque : Les clés candidates se déterminent mutuellementToute clé candidate détermine les autres clés candidates, puisque qu'une clé détermine tousles attributs de la relation.

Complément : Relation "toute clé"Étant donné qu'une relation dispose forcément d'une clé, si une relation R n'admet aucune cléK sous ensemble des attributs A1..An de R, alors c'est que K=A1..An (la clé est composée detous les attributs de R).On parle de relation "toute clé".

j) Exercice : A1, touché !



Stéphane Crozat 100


A B C D E

a1 b2 c2 d3 e2

a1 b2 c2 d1 e4

a2 b3 c2 d1 e5

a2 b4 c5 d1 e5

Après avoir énoncé les DF, déterminer, parmi les groupes d'attributs suivants, lesquels sontdes clés ?

A

B

C

D

E

{B,E}

{A,B,C,D,E}

3. Les formes normales

Objectifs

Connaître les formes normales et leurs implications en terme deredondance.

a) Formes normales

Les formes normales ont pour objectif de définir la décomposition des schémas relationnels,tout en préservant les DF et sans perdre d'informations, afin de représenter les objets etassociations canoniques du monde réel de façon non redondante. On peut recenser les 6 formes normales suivantes, de moins en moins redondantes :

la première forme normale

la deuxième forme normale

la troisième forme normale

la forme normale de Boyce-Codd

la quatrième forme normale

la cinquième forme normale



La troisième forme normale est généralement reconnue comme étant la plus importante àrespecter.

b) Principe de la décomposition

L'objectif de la décomposition est de "casser" une relation en relations plus petites afin d'enéliminer les redondances et sans perdre d'information.

Définition : DécompositionLa décomposition d'un schéma de relation R(A1,A2,...,An) est le processus de remplacementde ce schéma par une collection de schémas R1,R2,...,Rn telle qu'il est possible de reconstruireR par des opérations relationnelles de jointure sur R1,R2,...,Rn.

Définition : Décomposition préservant les DFUne décomposition d'une relation R en relations R1,R2,...Rn préserve les DF si la fermeturetransitive F+ des DF de R est la même que celle de l'union des fermetures transitives des DFde R1,R2,...,Rn.

Exemple : Décomposition préservant les DF d'une relation VoitureSoit la relation Voiture(Numéro,Marque,Type,Puissance,Couleur) avec la fermeture transitivesuivante :

Numéro Marque→

Numéro Type→

Numéro Puissance→

Numéro Couleur→

Type Marque→

Type Puissance→

On peut décomposer Voiture en préservant les DF en deux relations R1(Numéro,Type,Couleur)et R2(Type,Puissance,Marque).

c) Première forme normale

Définition : 1NFUne relation est en 1NF si elle possède au moins une clé et si tous ses attributs sontatomiques.

Définition : Attribut atomiqueUn attribut est atomique si il ne contient qu'une seule valeur pour un tuple donné, et donc s'ilne regroupe pas un ensemble de plusieurs valeurs.

Exemple : Avoir plusieurs métiersSoit la relation Personne instanciée par deux tuples :

1 Personne(#Nom, Profession)

1 (Dupont, Géomètre)2 (Durand, Ingénieur-Professeur)

La relation n'est pas en 1NF, car l'attribut Profession peut contenir plusieurs valeurs.Pour que la relation soit en 1NF, on pourrait par exemple ajouter Profession à la clé et faireapparaître deux tuples pour Durand, on obtiendrait :

1 Personne(#Nom, #Profession)



1 (Dupont, Géomètre)2 (Durand, Ingénieur)3 (Durand, Professeur)

Une autre solution aurait été d'ajouter un attribut ProfessionSecondaire. On obtiendrait ainsi :

1 Personne(#Nom, Profession, ProfessionSecondaire)

1 (Dupont, Géomètre, Null)2 (Durand, Ingénieur, Professeur)

Remarque : Relativité de la notion d'atomicitéL'atomicité d'un attribut est souvent relative : on peut décider qu'un attribut contenant unedate n'est pas atomique (et que le jour, le mois et l'année constituent chacun une valeur), oubien que l'attribut est de domaine date et donc qu'il est atomique.

Fondamental : Énoncer les clésLe modèle relationnel impose qu'une relation ait une clé, donc la condition "est en1NF si elle possède une clé" est superflue (au pire la relation est toute clé).Il est néanmoins fondamental d'avoir identifié les clés au début du processus denormalisation.

d) Deuxième forme normale

IntroductionLa deuxième forme normale permet d'éliminer les dépendances entre des parties de clé et desattributs n'appartenant pas à une clé.

Définition : 2NFUne relation est en 2NF si elle est en 1NF et si tout attribut qui n'est pas dans une clé nedépend pas d'une partie seulement d'une clé. C'est à dire encore que toutes les DF issuesd'une clé sont élémentaires.

Exemple : Echelle de salaireSoit la relation Personne :

1 Personne(#Nom, #Profession, Salaire)

Soit les DF suivantes sur cette relation : Nom,Profession Salaire→

Profession Salaire→

On note alors que la première DF est issue de la clé et qu'elle n'est pas élémentaire (puisqueProfession détermine Salaire) et donc que le schéma n'est pas en 2NF.Pour avoir un schéma relationnel en 2NF, il faut alors décomposer Personne en deux relations :

1 Personne(#Nom, #Profession=>Profession, Prenom) 2 Profession(#Profession, Salaire)

On remarque que ce schéma est en 2NF (puisque Salaire dépend maintenantfonctionnellement d'une clé et non plus d'une partie de clé).On remarque aussi que la décomposition a préservé les DF, puisque nous avons à présent :

Profession Salaire (DF de la relation Profession)→

Nom,Profession Profession (par Réflexivité)→



Nom,Profession Salaire (par Transitivité)→

AttentionLa définition de la 2NF doit être vérifiée pour toutes les clés candidates et nonseulement la clé primaire (dans le cas où il y a plusieurs clés).

RemarqueSi toutes les clés d'une relation ne contiennent qu'un unique attribut, et que la relation est en1NF, alors la relation est en 2NF.

e) Troisième forme normale

IntroductionLa troisième forme normale permet d'éliminer les dépendances entre les attributsn'appartenant pas à une clé.

Définition : 3NFUne relation est en 3NF si elle est en 2NF et si tout attribut n'appartenant pas à une clé nedépend pas d'un autre attribut n'appartenant pas à une clé. C'est à dire encore que toutes lesDFE vers des attributs n'appartenant pas à une clé, sont issues d'une clé.

Attention : Clé candidateLa définition concerne toutes les clés candidates et non uniquement la clé primaire(SQL avancé : Programmation et techniques avancées [Celko00], p.27).

Exemple : Échelle de salaire et de primeSoit la relation Profession :

1 Profession(#Profession, Salaire, Prime)

Soit les DF suivantes sur cette relation : Profession Salaire→

Profession Prime→

Salaire Prime→

Cette relation n'est pas en 3NF car Salaire, qui n'est pas une clé, détermine Prime.Pour avoir un schéma relationnel en 3NF, il faut décomposer Profession :

1 Profession(#Profession, Salaire=>Salaire)2 Salaire(#Salaire, Prime)

Ce schéma est en 3NF, car Prime est maintenant déterminé par une clé.On remarque que cette décomposition préserve les DF, car par transitivité, Professiondétermine Salaire qui détermine Prime, et donc Profession détermine toujours Prime.

Remarque : 3NF et 2NFUne relation en 3NF est forcément en 2NF car :

Toutes les DFE vers des attributs n'appartenant pas à une clé sont issues d'une clé, cequi implique qu'il n'existe pas de DFE, issues d'une partie de clé vers un attribut quin'appartient pas à une clé.

Il ne peut pas non plus exister de DFE issues d'une partie de clé vers un attributappartenant à une clé, par définition de ce qu'une clé est un ensemble minimum.

On n'en conclut qu'il ne peut exister de DFE, donc a fortiori pas de DF, issues d'une partied'une clé, et donc que toutes les DF issues d'une clé sont élémentaires.



FondamentalIl est souhaitable que les relations logiques soient en 3NF. En effet, il existe toujoursune décomposition sans perte d'information et préservant les DF d'un schéma en3NF. Si les formes normales suivantes (BCNF, 4NF et 5NF) assurent un niveaude redondance encore plus faible, la décomposition permettant de les atteindre nepréserve plus les DF.

Remarque : Limite de la 3NFUne relation en 3NF permet des dépendances entre des attributs n'appartenant pas à une clévers des parties de clé.

f) Forme normale de Boyce-Codd

IntroductionLa forme normale de Boyce-Codd permet d'éliminer les dépendances entre les attributsn'appartenant pas à une clé vers les parties de clé.

Définition : BCNFUne relation est en BCNF si elle est en 3NF et si tout attribut qui n'appartient pas à une clén'est pas source d'une DF vers une partie d'une clé. C'est à dire que les seules DFEexistantes sont celles dans lesquelles une clé détermine un attribut.

Exemple : EmployésSoit la relation Personne :

1 Personne(#N°SS, #Pays, Nom, Région)

Soit les DF suivantes sur cette relation : N°SS,Pays Nom→

N°SS,Pays Région→

Région Pays→

Il existe une DFE qui n'est pas issue d'une clé et qui détermine un attribut appartenant à uneclé. Cette relation est en 3NF, mais pas en BCNF (car en BCNF toutes les DFE sont issues d'uneclé).Pour avoir un schéma relationnel en BCNF, il faut décomposer Personne :

1 Personne(#N°SS, #Region=>Region, Nom) 2 Region(#Region, Pays)

Remarquons que les DF n'ont pas été préservées par la décomposition puisque N°SS et Paysne déterminent plus Région.

Remarque : SimplicitéLa BCNF est la forme normale la plus facile à appréhender intuitivement et formellement,puisque les seules DFE existantes sont de la forme K A où K est une clé.→

Attention : Non préservation des DFUne décomposition en BCNF ne préserve pas toujours les DF.



g) Synthèse

relation ( #k, #k, a, b)

3NFBCNF

2NF

Exemple

personne (#numsecu, #pays, continent, codepostal, ddn, age)2NF

BCNF 3NF

h) Exercice : A1, coulé !



A B C D E

a1 b2 c2 d3 e2

a1 b2 c2 d1 e4

a2 b3 c2 d1 e5

a2 b4 c5 d1 e5

Après avoir énoncé les DF et les clés, déterminer la forme normale du schéma ?

1NF

2NF

3NF

BCNF

4. Bibliographie commentée sur la normalisation

Complément : SynthèsesSQL2 SQL3, applications à Oracle [Delmal01]



On conseillera de lire le chapitre 2 (pages 42 à 49) qui propose une très bonne démonstrationpar l'exemple des problèmes posés par une mauvaise modélisation relationnelle.Une description claire des formes normales, rendue simple et pratique grâce à des exemplesreprésentatifs (chapitre 2).

B. Exercices

1. De quoi dépend un cours ?

[10 min]On considère le schéma relationnel R défini sur les attributs suivants : C : cours, P :professeur, H : heure, S : salle, E : étudiant, N : note.Un nuplet (c, p, h, s, e, n) a pour signification que le cours c est fait par le professeur p àl'heure h dans la salle s pour l'étudiant e qui a reçu la note n.L'ensemble E des dépendances fonctionnelles initiales est le suivant :

C P→

H,S C→

H,P S→

C,E N→

H,E S→

Q u e s t i o n 1

Donner la fermeture transitive F+ des dépendances fonctionnelles élémentaires engendréespar E.

Q u e s t i o n 2Quelle est la clé de la relation R ? Montrer qu'elle est unique.

2. Cuisines et dépendances

[20 min]On considère une relation R construite sur les attributs Propriétaire, Occupant, Adresse, Noapt,Nbpièces, Nbpersonnes, un nuplet (p, o, a, n, nb1, nb2) ayant la signification suivante : Lapersonne o habite avec nb2 personnes l'appartement de numéro n ayant nb1 pièces dont lepropriétaire est p.Une analyse de cette relation nous fournit un ensemble initial E de dépendancesfonctionnelles :

occupant adresse→

occupant noapt→

occupant nbpersonnes→

adresse, noapt propriétaire→

adresse, noapt occupant→

adresse, noapt nbpièces→

Q u e s t i o n 1

Donner l'ensemble des DFE engendrées par E (fermeture transitive F+).



Q u e s t i o n 2Quelles sont les clés candidates de R ?

Q u e s t i o n 3Montrer que R est en 3NF de deux façons différentes (sans passer et en passant par la BCNF).

3. Test : Normalisation

Exercice 1Soit la relation suivante et une couverture minimale des DF associée.

1 tUtilisateur (pklogin,mdp,nom,prenom,ville)

pklogin→mdp,nom,prenom,ville

nom,prenom→pklogin

ville→nom

Sélectionner la ou les clés de cette relation.

pklogin

mdp

nom

prenom

ville

(pklogin,mdp)

(pklogin,nom)

(nom,prenom)

(ville,nom)

(nom,prenom,ville)

Exercice 2Soit le schéma relationnel (on pose que les attributs A, B, C, D, X et Y sont atomiques) :

1 R1(A, B, C, D)2 R2(X, Y)

Soit les dépendances fonctionnelles identifiées : A C→

A,B D→

X Y→

En quelles formes normales est ce schéma relationnel ?

1NF

2NF

3NF

BCNF



Exercice 3Soit le schéma relationnel suivant :

1 Personne (Nom, Prenom, Age, DateNaissance)

Soit les DF suivantes : Nom Prenom→

Nom, Prenom Age→

Prenom DateNaissance, Nom→

DateNaissance, Age Age, Nom→

Age, Nom Age, DateNaissance→

DateNaissance Age→

Quelles sont les clés candidates pour la relation Personne ?

Nom

Prenom

Age

DateNaissance

Exercice 4Soit la relation R (A:Int, B:Int, C:Int, D:Int, E:Int) et l'ensemble de DFE suivant : {A B→ ; A

C→ ; A D→ ; A E→ ; B A→ ; B C}→

Sélectionner toutes les assertions vraies.

A est une clé

B est une clé

C est une clé

Le schéma est en 1NF

Le schéma est en 2 NF

Le schéma est en 3 NF

Cet ensemble de DFE est une fermeture transitive.

Cet ensemble de DFE est une couverture minimale.

Exercice 5Soit le schéma relationnel (on pose que tous les attributs sont atomiques) :

1 Adresse (Numero, Rue, Ville=>Ville, Pays=>Ville)2 Ville (Ville, Pays=>Pays)3 Pays (Pays)

En quelles formes normales est ce schéma relationnel ?



1NF

2NF

3NF

BCNF



VIII - Conception de bases de données normalisées

VIII

A. Cours

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

Objectifs

Savoir créer des schémas relationnels en troisième formenormale.

a) Exercice : Étapes de la conception d'une base de données

Mettre dans l'ordre les étapes de conception suivantes.1. Énonciation de la forme normale avant normalisation2. Création du code SQL LDD pour un SGBDR ou un SGBDRO3. Élaboration du modèle logique en relationnel ou relationnel-objet4. Modélisation conceptuelle en UML ou E-A5. Décomposition des relations jusqu'à arriver en 3NF en préservant les DF6. Rétro-conception d'un modèle UML normalisé7. Établissement des DF sous la forme de la fermeture transitive pour chaque relation du

modèle8. Analyse de la situation existante et des besoins

Réponse : ___ ___ ___ ___ ___ ___ ___ ___

b) Algorithme de décomposition

Méthode : Décomposition 0NF->1NFSoit R une relation avec la clé primaire pk. Si R contient un attribut non atomique, alors R estdé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 R2.pk clé étrangèrevers R1.pk


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

R1(#pk,b,...)

R2(#pk=>R1,#a)

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

la partie gauche de la DFE : a. devient la clé primaire de R2 b. devient une clé étrangère de R1 vers R2

la partie droite de la DFE a. est enlevée de R1 b. est ajoutée comme attributs simples de R2

Méthode : Décomposition 1NF->2NFSoit 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->3NFSoit R une relation comportant une DFE de a vers b qui n'appartiennent pas à une clé, alors Rest 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)

c) Exemple de décomposition

Exemple : Situation initiale

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

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

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

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

knumetu prenom,nom→

kuv credits→

Conception de bases de données normalisées


resultat obtenu→

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)

d) 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 lecalcul : age = ddn - today().

MéthodeChaque fois que c'est possible, on remplacera un attribut par une méthode si cela permet desupprimer 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 leretrouver.

Exemple : Exemple simpleSoit 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 = ddn - today()



Exemple : Un exemple plus approfondiSoit le schéma UML suivant :

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

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=Null alors type=Bureau

sinon type=Réunion

e) 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èleRésultat : MLD1 avec F+

5. Établissement de la forme normaleRésultat : MLD1 avec F+ et NF

6. Décomposition des relations jusqu'à arriver en 3NF en préservant les DFRésultat : MLD2 avec F+ et 3NF

7. Rétro-conception du modèle UML correspondantRé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 nonredondantes.La 3NF est souhaitable car toujours possible à obtenir, sans perte d'information et sans pertede DF. La BCNF est également indiquée, car elle est un peu plus puissante, et plutôt plussimple que la 3NF.



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

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édantles 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 professeurpouvant encadrer plusieurs doctorants et un doctorant n'ayant qu'un et un seuldirecteur 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.

a) Première étape : Modélisation conceptuelle

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

Image 31 Conception UML (1/4)

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




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


Méthode : Modélisation conceptuelle : Association Encadrement


b) Deuxième étape : Modèle relationnel

Méthode : Modèle relationnel : HéritageChoix de transformation de l'héritage : L'héritage est exclusif (les professeurs ne sont plusdoctorants), mais pas complet, car l'association Encadre n'est pas symétrique. On choisitdonc 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)

c) 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ésConnaissant l'université, on connaît la ville, donc :

Professeur.N°SS Nom, NomUniv, VilleUniv→

Professeur.NomUniv VilleUniv→

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

Doctorant.NomUniv VilleUniv→

d) Quatrième étape : Formes normales

Méthode : Forme normale : 1NFLe schéma est en 1NF (clés et attributs atomique).

Méthode : Forme normale : 2NFLe schéma est en 2NF (la clé est composée d'un seul attribut)

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

e) 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érificationLe modèle est bien en BCNF, toutes les DF ont pour source une clé.

Méthode : Normalisation en BCNF : Conservation des DFLa transformation préserve les DF car :

N°SS NomUniv et Univ.Nom Ville→ →

Donc N°SS Univ.Ville (par transitivité)→



f) 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 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 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));

1 Create Table Univ (2 Nom CHAR(50) PRIMARY KEY,3 Ville CHAR(20) );

B. Exercices

1. Project manager

[15 min]Soit la table suivante (Emp signifie Employee, Pro signifie Project et Man signifie Manager).

Emp EmpName Pro ProName Man ManNameE01 John P1 Eco M1 BeckyE02 Mary P2 Admin M2 JoeE03 Mark P2 Admin M2 JoeE04 Travis P3 Educ M1 Becky



Soit les dépendances fonctionnelles suivantes : Emp EmpName→

Emp Pro→

Pro ProName→

Pro Man→

Pro ManName→

Man ManName→

Q u e s t i o n 1

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

Q u e s t i o n 2

Proposer un modèle équivalent en 3NF.

2. Objectifs II

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

Numéro Projet / Tâche Spécialités Chef de projet Participant tâche Dates Partenaire

Logistique 25 décembre 1666 (Brasseur) Bières offertes

1,1 Gestion

Voyages Paul Manzarek Intersemestre

Sport Paul Manzarek 15/5 - 23/5

Gestion

1

La nuit du Picolo

Paul Densmore ; Spécialiste Musique

Barbara Krieger ; Spécialiste Sport

2

Escalade de l'Everest

Pentathlon1666 (Brasseur)

Fourniture de matérielPublicité

3

Tournoi de Volley-Ball

3.1

Recrutement des équipes

Barbara Krieger ; Spécialiste Sport

3.2

Paul Densmore ; Spécialiste Musique

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 laterminologie du domaine des bases de données seront intégrées à l'évaluation.

Q u e s t i o n 1

On considérera ce tableau comme une relation, et on admettra que cette extension estsuffisante 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).

Q u e s t i o n 2

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. Jeu de construction

[30 min]Soit le diagramme UML ci-après décrivant des constructions composées d'éléments etfaisant 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

Modèle UML

Q u e s t i o n 1Effectuer le passage au relationnel de ce modèle.

Q u e s t i o n 2Sachant 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 decompétences (h) différentes.

Q u e s t i o n 3Normaliser le modèle en 3NF (justifier, et montrer que la transformation est sans perte).

Q u e s t i o n 4En repartant de la forme normalisée en 3NF, rétro-concevoir un modèle UML qui aurait permisd'aboutir directement à ce schéma non redondant.

4. À l'école

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

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 leurspécialité.

Les classes accueillent des élèves.

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

École

Q u e s t i o n 1

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

Q u e s t i o n 2Montrer que ce schéma n'est pas en première forme normale, et proposer une correction duschéma relationnel.



IX - Gestion des transactions pour la fiabilité et la concurrence

IX

A. Cours

Les transactions sont une réponse générale aux problèmes de fiabilité et d'accès concurrentsdans les BD, et en particulier dans les BD en mode client-serveur. Elles sont le fondement detoute implémentation robuste d'une BD. Un SGBDR ne fonctionne nativement qu'en modetransactionnel.

1. Principes des transactions

Objectifs

Comprendre les principes et l'intérêt des transactions

a) Problématique des pannes et de la concurrence

Une BD est un ensemble persistant de données organisées qui a en charge la préservationde la cohérence de ces données. Les données sont cohérentes si elles respectent l'ensembledes contraintes d'intégrité spécifiées pour ces données : contraintes de domaine, intégritéréférentielle, dépendances fonctionnelles...La cohérence des données peut être remise en cause par deux aspects de la vie d'une BD :

La défaillance

Lorsque le système tombe en panne alors qu'un traitement est en cours, il y a un risquequ'une partie seulement des instructions prévues soit exécutée, ce qui peut conduire àdes incohérences. Par exemple pendant une mise à jour en cascade de clés étrangèressuite au changement d'une clé primaire.

La concurrence

Lorsque deux accès concurrents se font sur les données, il y a un risque que l'un desdeux accès rende l'autre incohérent. Par exemple si deux utilisateurs en réseau


modifient une donnée au même moment, seule une des deux mises à jour seraeffectuée.

La gestion de transactions par un SGBD est à la base des mécanismes qui permettentd'assurer le maintien de la cohérence des BD. C'est à dire encore qu'il assure que toutes lescontraintes de la BD seront toujours respectées, même en cas de panne et même au coursd'accès concurrents.

b) Notion de transaction

Définition : TransactionUne transaction est une unité logique de travail, c'est à dire une séquence d'instructions, dontl'exécution assure le passage de la BD d'un état cohérent à un autre état cohérent.

Fondamental : Cohérence des exécutions incorrectesLa transaction assure le maintien de la cohérence des données que son exécutionsoit correcte ou incorrecte.

Exemple : Exemples d'exécutions incorrectesL'exécution d'une transaction peut être incorrecte parce que :

Une panne a lieu

Un accès concurrent pose un problème

Le programme qui l'exécute en a décidé ainsi

c) Déroulement d'une transaction 1. DEBUT 2. TRAITEMENT

- Accès aux données en lecture- Accès aux données en écriture

3. FIN- Correcte : Validation des modifications- Incorrecte : Annulation des modifications

FondamentalTant qu'une transaction n'a pas été terminée correctement, elle doit être assimilée àune tentative ou une mise à jour virtuelle, elle reste incertaine. Une fois terminéecorrectement la transaction ne peut plus être annulée par aucun moyen.

d) Propriétés ACID d'une transaction

Une transaction doit respecter quatre propriétés fondamentales : L'atomicité

Les transactions constituent l'unité logique de travail, toute la transaction est exécutéeou bien rien du tout, mais jamais une partie seulement de la transaction.

La cohérence

Les transactions préservent la cohérence de la BD, c'est à dire qu'elle transforme laBD d'un état cohérent à un autre (sans nécessairement que les états intermédiairesinternes de la BD au cours de l'exécution de la transaction respectent cette cohérence)

L'isolation

Les transactions sont isolées les unes des autres, c'est à dire que leur exécution estindépendante des autres transactions en cours. Elles accèdent donc à la BD comme sielles étaient seules à s'exécuter, avec comme corollaire que les résultats intermédiairesd'une transaction ne sont jamais accessibles aux autres transactions.

La durabilité

Gestion des transactions pour la fiabilité et la concurrence


Les transactions assurent que les modifications qu'elles induisent perdurent, même encas de défaillance du système.

RemarqueLes initiales de Atomicité, Cohérence, Isolation et Durabilité forme le mot mnémotechniqueACID.

e) Journal des transactions

Définition : JournalLe journal est un fichier système qui constitue un espace de stockage redondant avec la BD.Il répertorie l'ensemble des mises à jour faites sur la BD (en particulier les valeurs desenregistrements avant et après mise à jour). Le journal est donc un historique persistant(donc en mémoire secondaire) qui mémorise tout ce qui se passe sur la BD.Le journal est indispensable pour la validation (COMMIT), l'annulation (ROLLBACK) et la repriseaprès panne de transactions. Synonymes : Log

2. Manipulation de transactions en SQL

Objectifs

Connaître les syntaxes SQL standard, PostgreSQL, Oracle etAccess pour utiliser des transactions

a) Transactions en SQL

IntroductionLe langage SQL fournit trois instructions pour gérer les transactions.

Syntaxe: Début d'une transaction

1 BEGIN TRANSACTION (ou BEGIN) ;

Cette syntaxe est optionnelle (voire inconnue de certains SGBD), une transaction étantdébutée de façon implicite dès qu'instruction est initiée sur la BD.

Syntaxe: Fin correcte d'une transaction

1 COMMIT TRANSACTION (ou COMMIT) ;

Cette instruction SQL signale la fin d'une transaction couronnée de succès. Elle indique donc augestionnaire de transaction que l'unité logique de travail s'est terminée dans un état cohérentest que les données peuvent effectivement être modifiées de façon durable.

Syntaxe: Fin incorrecte d'une transaction

1 ROLLBACK TRANSACTION (ou ROLLBACK) ;

Cette instruction SQL signale la fin d'une transaction pour laquelle quelque chose s'est malpassé. Elle indique donc au gestionnaire de transaction que l'unité logique de travail s'estterminée dans un état potentiellement incohérent et donc que les données ne doivent pas êtremodifiées en annulant les modifications réalisées au cours de la transaction.



Remarque : ProgrammeUn programme est généralement une séquence de plusieurs transactions.

b) Mini-TP : Transaction en SQL standard sous PostgreSQL 1. Se connecter à une base de données : psql mydb 2. Créer une table test : CREATE TABLE test (a integer);

Q u e s t i o n 1 1. Commencer une transaction : BEGIN TRANSACTION; 2. Insérer les deux valeurs 1 et 2 dans la table : INSERT INTO... 3. Valider la transaction : COMMIT 4. Vérifier que les valeurs sont bien dans la table : SELECT * FROM ...

Q u e s t i o n 2 1. Commencer une transaction : BEGIN TRANSACTION; 2. Insérer les deux valeurs 3 et 4 dans la table : INSERT INTO... 3. Annuler la transaction : ROLLBACK 4. Vérifier que les valeurs ne sont pas dans la table : SELECT * FROM ...

c) Exemple : Transaction sous Oracle en SQL

Exemple : Exemple en SQL sous Oracle

1 INSERT INTO test (a) VALUES (1);2 COMMIT;3

Attention : BEGIN implicite sous OracleLa commande BEGIN; ou BEGIN TRANSACTION; ne peut pas être utilisé sous Oracle (lacommande BEGIN est réservée à l'ouverture d'un bloc PL/SQL).

Toute commande SQL LMD (INSERT, UPDATE ou DELETE) démarre par défaut unetransaction, la commande BEGIN TRANSACTION est donc implicite.

d) Exemple : Transaction sous Oracle en PL/SQL

Exemple : Exemple en PL/SQL sous Oracle

1 BEGIN 2 INSERT INTO test (a) VALUES (1);3 COMMIT;4 END;5

e) Exemple : Transaction sous Access en VBA

Exemple : Exemple de transfert entre deux comptes en VBA sous Access

1 Sub MyTransaction2 BeginTrans3 CurrentDb.CreateQueryDef("", "INSERT INTO test (a) VALUES (1)").Execute4 CommitTrans5 End Sub



Remarque : VBA et transactionsSous Access, il n'est possible de définir des transactions sur plusieurs objets requêtes qu'enVBA.

f) Mode Autocommit

Attention : AutocommitLa plupart des clients et langages d'accès aux bases de données proposent un modeautocommit permettant d'encapsuler chaque instruction dans une transaction. Cemode revient à avoir un COMMIT implicite après chaque instruction.

Ce mode doit être désactivé pour permettre des transactions portant sur plusieursinstructions.

Oracle Sous Oracle SQL*Plus : SET AUTOCOMMIT ON et SET AUTOCOMMIT OFF

Sous Oracle SQL Developper : Menu Outils > Préférences > Base de données >Paramètres de feuille de calcul > Validation automatique dans une feuillede calcul

PostgreSQLAvec psql :

\set AUTOCOMMIT on \set AUTOCOMMIT off

Si l'autocommit est activé, il est néanmoins possible de démarrer une transaction sur plusieurslignes en exécutant un BEGIN TRANSACTION explicite : BEGIN ; ... ; COMMIT ;.

Ainsi deux modes sont possibles : Autocommit activé : BEGIN explicites, COMMIT implicites

Autocommit désactivé : BEGIN implicites, COMMIT explicites

AccessSous Access, toute requête portant sur plusieurs lignes d'une table est encapsulée dans unetransaction.Ainsi par exemple la requête UPDATE Compte SET Solde=Solde*6,55957 est exécutée dansune transaction et donc, soit toutes les lignes de la table Compte seront mises à jour, soitaucune (par exemple en cas de panne pendant .

g) Exercice

Quel est le résultat de l'exécution suivante sous Oracle ?

1 SET AUTOCOMMIT OFF2 CREATE TABLE T1 (A INTEGER);34 INSERT INTO T1 VALUES (1);5 INSERT INTO T1 VALUES (2);6 INSERT INTO T1 VALUES (3);7 COMMIT;8 INSERT INTO T1 (4);9 INSERT INTO T1 (5);

10 ROLLBACK;11 SELECT SUM(A) FROM T1



h) Exercice

Combien de lignes renvoie l'avant-dernière instruction SELECT ?

1 SET AUTOCOMMIT OFF2 CREATE TABLE T1 (A INTEGER);34 INSERT INTO T1 VALUES (1);5 INSERT INTO T1 VALUES (1);6 INSERT INTO T1 VALUES (1);7 SELECT * FROM T1;8 COMMIT;

i) Exercice

Combien de tables sont créées par cette série d'instruction ?

1 SET AUTOCOMMIT OFF2 CREATE TABLE T1 (A INTEGER);3 CREATE TABLE T2 (A INTEGER);4 CREATE TABLE T3 (A INTEGER);5 INSERT INTO T1 VALUES (1);6 INSERT INTO T2 VALUES (1);7 INSERT INTO T3 VALUES (1);8 ROLLBACK;

3. Fiabilité et transactions

Objectifs

Appréhender la gestion des pannes dans les SGBD.Comprendre la réponse apportée par la gestion des transactions.

a) Les pannes

Une BD est parfois soumise à des défaillances qui entraînent une perturbation, voire unarrêt, de son fonctionnement.On peut distinguer deux types de défaillances :

Les défaillances système

ou défaillances douces (soft crash), par exemple une coupure de courant ou une panneréseau. Ces défaillances affectent toutes les transactions en cours de traitement, maispas la BD au sens de son espace de stockage physique.

Les défaillances des supports

ou défaillances dures (hard crash), typiquement le disque dur sur lequel est stockée laBD. Ces défaillances affectent également les transactions en cours (par rupture desaccès aux enregistrements de la BD), mais également les données elles-mêmes.



Remarque : Annulation des transactions non terminéesLorsque le système redémarre après une défaillance, toutes les transactions qui étaient encours d'exécution (pas de COMMIT) au moment de la panne sont annulés (ROLLBACK imposépar le système). Cette annulation assure le retour à un état cohérent, en vertu des propriétés ACID destransactions.

Remarque : Ré-exécution des transactions terminées avec succèsAu moment de la panne certaines transactions étaient peut-être terminées avec succès(COMMIT) mais non encore (ou seulement partiellement) enregistrées dans la BD (en mémoirevolatile, tampon, etc.). Lorsque le système redémarre il doit commencer par rejouer cestransactions, qui assurent un état cohérent de la BD plus avancé.Cette reprise des transactions après COMMIT est indispensable dans la mesure où c'est bienl'instruction COMMIT qui assure la fin de la transaction et donc la durabilité. Sans cettegestion, toute transaction pourrait être remise en cause.

Remarque : Unité de repriseLes transactions sont des unités de travail, et donc également de reprise.

Remarque : Défaillance des supportsTandis que la gestion de transactions et de journal permet de gérer les défaillances systèmes,les défaillances des supports ne pourront pas toujours être gérés par ces seuls mécanismes.Il faudra leur adjoindre des procédures de sauvegarde et de restauration de la BD pour êtrecapable au pire de revenir dans un état antérieur cohérent et au mieux de réparercomplètement la BD (cas de la réplication en temps réel par exemple).

b) Point de contrôle

Définition : Point de contrôleUn point de contrôle est une écriture dans le journal positionnée automatiquement par lesystème qui établit la liste de toutes les transactions en cours (au moment où le point decontrôle est posé) et force la sauvegarde des données alors en mémoire centrale dans lamémoire secondaire.Le point de contrôle est positionné à intervalles de temps ou de nombre d'entrées.Le dernier point de contrôle est le point de départ d'une reprise après panne, dans la mesureoù c'est le dernier instant où toutes les données ont été sauvegardées en mémoire nonvolatile.Synonymes : Syncpoint

c) Ecriture en avant du journal

FondamentalOn remarquera que pour que la reprise de panne soit en mesure de rejouer lestransactions, la première action que doit effectuer le système au moment du COMMITest l'écriture dans le journal de cette fin correcte de transaction. En effet ainsi latransaction pourra être rejouée, même si elle n'a pas eu le temps de mettreeffectivement à jour les données dans la BD, puisque le journal est en mémoiresecondaire.



d) Reprise après panneIntroductionLe mécanisme de reprise après panne s'appuie sur le journal et en particulier sur l'état destransactions au moment de la panne et sur le dernier point de contrôle.Le schéma ci-après illustre les cinq cas de figure possibles pour une transaction au moment dela panne.

Image 35 États d'une transaction au moment d'une panne

Transactions de type T1

Elles ont débuté et se sont terminées avant tc. Elles n'interviennent pas dans leprocessus de reprise.


Elles ont débuté avant tc et se sont terminées entre tc et tf. Elles devront être rejouées(il n'est pas sûr que les données qu'elles manipulaient aient été correctement inscritesen mémoire centrale, puisque après tc, or le COMMIT impose la durabilité).


Elles ont débuté avant tc, mais n'était pas terminées à tf. Elles devront être annulées(pas de COMMIT).


Elles ont débuté après tc et se sont terminées avant tf. Elles devront être rejouées. Transactions de type T5

Elles ont débuté après tc et ne se sont pas terminées. Elles devront être annulées.

RemarqueLes transactions sont des unités d'intégrité.



e) Mini-TP : Simulation d'une panne sous PostgreSQL 1. Se connecter à une base de données : psql mydb 2. Créer une table test : CREATE TABLE test (a integer);

Q u e s t i o n 1. Commencer une transaction : BEGIN TRANSACTION; 2. Insérer les deux valeurs 1 et 2 dans la table : INSERT INTO... 3. Vérifier que les valeurs sont bien dans la table : SELECT * FROM ... 4. Simuler un crash en fermant le terminal : ROLLBACK du système 5. Se reconnecter et vérifier que les valeurs ne sont plus dans la table : SELECT *

FROM ...

f) Exemple : Transfert protégé entre deux comptes

Exemple : Transfert entre deux comptes en SQL standard sous PostgreSQL

1 BEGIN;2 UPDATE Compte1 SET Solde=Solde+100 WHERE Num=1;3 UPDATE Compte2 SET Solde=Solde-100 WHERE Num=1;4 COMMIT;5 /

Exemple : Transfert entre deux comptes en PL/SQL sous Oracle

1 CREATE OR REPLACE PROCEDURE myTransfC1C22 IS3 BEGIN4 UPDATE Compte1 SET Solde=Solde+100 WHERE Num=1;5 UPDATE Compte2 SET Solde=Solde-100 WHERE Num=1;6 COMMIT;7 END;8 /

Exemple : Transfert entre deux comptes en VBA sous Access

1 Sub myTransfC1C22 BeginTrans3 CurrentDb.CreateQueryDef("", "UPDATE Compte1 SET Solde=Solde+100 WHERE

Num=1").Execute4 CurrentDb.CreateQueryDef("", "UPDATE Compte2 SET Solde=Solde-100 WHERE

Num=1").Execute5 CommitTrans6 End Sub

Fondamental : Transfert protégéPour les trois exemples ci-avant le transfert est protégé au sens où soit les deuxUPDATE seront exécutés , soit aucun.

En cas de panne pendant la transaction, le transfert sera annulé (ROLLBACK système),mais en aucun cas un des deux comptes ne pourra être modifié sans que l'autre lesoit (ce qui aurait entraîné une perte ou un gain sur la somme des deux comptes).

g) Exercice

Pour faire un transfert sécurisé d'un point de vue transactionnel de 100€ du compte bancaireC1 vers le compte bancaire C2 pour le compte numéro 12, quelle est la série d'instructionscorrecte (en mode autocommit off)?



UPDATE C1 SET Solde=Solde-100 WHERE Numero=12;

ROLLBACK;

UPDATE C2 SET Solde=Solde+100 WHERE Numero=12;

COMMIT;

UPDATE C1 SET Solde=Solde-100 WHERE Numero=12

UPDATE C2 SET Solde=Solde+100 WHERE Numero=12

ROLLBACK;


COMMIT;


COMMIT;



COMMIT;


ROLLBACK;


ROLLBACK;

h) Complément : Algorithme de reprise UNDO-REDO

IntroductionL'algorithme suivant permet d'assurer une reprise après panne qui annule et rejoue lestransactions adéquates.

1 1. SOIT deux listes REDO et UNDO2 1a. Initialiser la liste REDO à vide3 1b. Initialiser la liste UNDO avec toutes les transactions en cours au dernier

point de contrôle45 2. FAIRE une recherche en avant dans le journal, à partir du point de contrôle6 2a. SI une transaction T est commencée ALORS ajouter T à UNDO7 2b. SI une transaction T est terminée avec succès alors déplacer T de UNDO à

REDO 89 3. QUAND la fin du journal est atteinte

10 3a. Annuler les transactions de la liste UNDO (reprise en arrière)11 3b. Rejouer les transactions de la liste REDO (reprise en avant)1213 4. TERMINER la reprise et redevenir disponible pour de nouvelles instructions



Exemple

Image 36 États d'une transaction au moment d'une panne


Non prises en compte par l'algorithme. Transactions de type T2

Ajoutées à la liste UNDO (étape 1b) puis déplacée vers REDO (étape 2b) puis rejouée(étape 3b).


Ajoutées à la liste UNDO (étape 1b) puis annulée (étape 3a). Transactions de type T4

Ajoutées à la liste UNDO (étape 2a) puis déplacée vers REDO (étape 2b) puis rejouée(étape 3b).


Ajoutées à la liste UNDO (étape 2a) puis annulée (étape 3a).

* *

*

On voit que la gestion transactionnelle est un appui important à la reprise sur panne, en cequ'elle assure des états cohérents qui peuvent être restaurés.



4. Concurrence et transactions

Objectifs

Appréhender la gestion de la concurrence dans les SGBD.Comprendre la réponse apportée par la gestion des transactions.

a) Trois problèmes soulevés par la concurrence.IntroductionNous proposons ci-dessous trois problèmes posés par les accès concurrents des transactionsaux données.

i Perte de mise à jour

Temps Transaction A Transaction B

t1 LIRE T

t2 ... LIRE T

t3 ...

t4 ... UPDATE T

t5 COMMIT ...

t4 COMMIT

UPDATE T

Tableau 9 Problème de la perte de mise à jour du tuple T par la transaction A

Les transaction A et B accèdent au même tuple T ayant la même valeur respectivement à t1 ett2. Ils modifient chacun la valeur de T. Les modifications effectuées par A seront perduespuisqu'elle avait lu T avant sa modification par B.

Exemple

Temps A : Ajouter 100 B : Ajouter 10

t1

t2...

t3...

t4...

t5...

t6

LIRE COMPTEC=1000

LIRE COMPTEC=1000

UPDATE COMPTEC=C+100=1100


COMMITC=1100

COMMITC=1010

Tableau 10 Doucle crédit d'un compte bancaire C

Dans cet exemple le compte bancaire vaut 1010 à la fin des deux transactions à la place de1110.



ii Accès à des données non validées


t1 UPDATE T

t2 LIRE T ...

t3 ROLLBACK

Tableau 11 Problème de la lecture impropre du tuple T par la transaction A

La transaction A accède au tuple T qui a été modifié par la transaction B. B annule samodification et A a donc accédé à une valeur qui n'aurait jamais dû exister (virtuelle) de T. PireA pourrait faire une mise à jour de T après l'annulation par B, cette mise à jour inclurait lavaleur avant annulation par B (et donc reviendrait à annuler l'annulation de B).

Exemple

Temps A : Ajouter 10 B : Ajouter 100 (erreur)

t1

t2

t3...

t4...

t5

t6

LIRE COMPTEC=1000


LIRE COMPTEC=1100

ROLLBACKC=1000

UPDATE CC=C+10=1110

COMMITC=1110

Tableau 12 Annulation de crédit sur le compte bancaire C

Dans cet exemple le compte bancaire vaut 1110 à la fin des deux transactions à la place de1010.

iii Lecture incohérente


t1 LIRE T

t2 ... UPDATE T

t3 ... COMMIT

t4 LIRE T

Tableau 13 Problème de la lecture non reproductible du tuple T par la transaction A

Si au cours d'une même transaction A accède deux fois à la valeur d'un tuple alors que cedernier est, entre les deux, modifié par une autre transaction B, alors la lecture de A estinconsistente. Ceci peut entraîner des incohérences par exemple si un calcul est en train d'êtrefait sur des valeurs par ailleurs en train d'être mises à jour par d'autres transactions.



RemarqueLe problème se pose bien que la transaction B ait été validée, il ne s'agit donc pas du problèmed'accès à des données non validées.

Exemple

Temps A : Calcul de S=C1+C2 B : Transfert de 10 de C1 à C2

t1

t2...

t3...

t4...

t5...

t6 ... COMMIT

t7

t8

LIRE COMPTE1C1=100

LIRE COMPTE 1C1=100

LIRE COMPTE 2C2=100

UPDATE COMPTE 1C1=100-10=90

UPDATE COMPTE 2C2=100+10=110

LIRE COMPTE 2C2=110

CALCUL SS=C1+C2=210

Tableau 14 Transfert du compte C1 au compte C2 pendant une opération de calcul C1+C2

Dans cet exemple la somme calculée vaut 210 à la fin du calcul alors qu'elle devrait valoir 200.

b) Le verrouillage

IntroductionUne solution générale à la gestion de la concurrence est une technique très simple appeléeverrouillage.

Définition : VerrouPoser un verrou sur un objet (typiquement un tuple) par une transaction signifie rendre cetobjet inaccessible aux autres transactions.Synonymes : Lock

Définition : Verrou partagé SUn verrou partagé, noté S, est posé par une transaction lors d'un accès en lecture sur cetobjet.Un verrou partagé interdit aux autres transaction de poser un verrou exclusif sur cet objet etdonc d'y accéder en écriture.Synonymes : Verrou de lecture, Shared lock, Read lock

Définition : Verrou exclusif XUn verrou exclusif, noté X, est posé par une transaction lors d'un accès en écriture sur cetobjet.



Un verrou exclusif interdit aux autres transactions de poser tout autre verrou (partagé ouexclusif) sur cet objet et donc d'y accéder (ni en lecture, ni en écriture).Synonymes : Verrou d'écriture, Exclusive lock, Write lock

Remarque : Verrous S multiplesUn même objet peut être verrouillé de façon partagée par plusieurs transactions en mêmetemps. Il sera impossible de poser un verrou exclusif sur cet objet tant qu'au moins unetransaction disposera d'un verrou S sur cet objet.

Méthode : Règles de verrouillageSoit la transaction A voulant poser un verrou S sur un objet O

1. Si O n'est pas verrouillé alors A peut poser un verrou S 2. Si O dispose déjà d'un ou plusieurs verrous S alors A peut poser un verrou S 3. Si O dispose déjà d'un verrou X alors A ne peut pas poser de verrou S

Soit la transaction A voulant poser un verrou X sur un objet O 1. Si O n'est pas verrouillé alors A peut poser un verrou X 2. Si O dispose déjà d'un ou plusieurs verrous S ou d'un verrou X alors A ne peut pas

poser de verrou X

Verrou X présent Verrou(s) S présent(s) Pas de verrou présent

Verrou X demandé Demande refusée Demande refusée Demande accordée

Verrou S demandé Demande refusée Demande accordée Demande accordée

Tableau 15 Matrice des règles de verrouillage

Remarque : Promotion d'un verrouUne transaction qui dispose déjà, elle-même, d'un verrou S sur un objet peut obtenir unverrou X sur cet objet si aucune autre transaction ne détient de verrou S sur l'objet. Le verrouest alors promu du statut partagé au statut exclusif.

c) Le déverrouillage

Définition : DéverrouillageLorsqu'une transaction se termine (COMMIT ou ROLLBACK) elle libère tous les verrous qu'elle aposé.Synonymes : Unlock

d) Inter-blocage

Définition : Inter-blocageL'inter-blocage est le phénomène qui apparaît quand deux transactions (ou plus, maisgénéralement deux) se bloquent mutuellement par des verrous posés sur les données. Cesverrous empêchent chacune des transactions de se terminer et donc de libérer les verrous quibloquent l'autre transaction. Un processus d'attente sans fin s'enclenche alors. Les situations d'inter-blocage sont détectées par les SGBD et gérées, en annulant l'une,l'autre ou les deux transactions, par un ROLLBACK système. Les méthodes utilisées sont ladétection de cycle dans un graphe d'attente et la détection de délai d'attente trop long.Synonymes : Deadlock, Blocage, Verrou mortel

Définition : Cycle dans un graphe d'attentePrincipe de détection d'un inter-blocage par détection d'un cycle dans un graphe représentantquelles transactions sont en attente de quelles transactions (par inférence sur les verrous



posés et les verrous causes d'attente). Un cycle est l'expression du fait qu'une transaction Aest en attente d'une transaction B qui est en attente d'une transaction A.La détection d'un tel cycle permet de choisir une victime, c'est à dire une des deuxtransactions qui sera annulée pour que l'autre puisse se terminer.Synonymes : Circuit de blocage

Définition : Délai d'attentePrincipe de décision qu'une transaction doit être abandonnée (ROLLBACK) lorsque son délaid'attente est trop long.Ce principe permet d'éviter les situations d'inter-blocage, en annulant une des deuxtransactions en cause, et en permettant donc à l'autre de se terminer.Synonymes : Timeout

Remarque : Risque lié à l'annulation sur délaiSi le délai est trop court, il y a un risque d'annuler des transactions en situation d'attentelongue, mais non bloquées.Si le délai est trop long, il y a un risque de chute des performances en situation d'inter-blocage(le temps que le système réagisse).La détection de cycle est plus adaptée dans tous les cas, mais plus complexe à mettre enœuvre.

Remarque : Relance automatiqueUne transaction ayant été annulée suite à un inter-blocage (détection de cycle ou de délaid'attente) n'a pas commis de "faute" justifiant son annulation. Cette dernière est juste due auxcontraintes de la gestion de la concurrence. Aussi elle n'aurait pas dû être annulée et devradonc être exécutée à nouveau.Certains SGBD se charge de relancer automatiquement les transactions ainsi annulées.

e) Mini-TP : Simulation d'accès concurrents sous PostgreSQL 1. Se connecter deux fois à une même base de données dans deux terminaux (term1 et

term2) :- psql mydb- psql mydb

2. Créer une table test : CREATE TABLE test (a integer);

Q u e s t i o n 1 1. term1 Insérer une valeur : INSERT ... (COMMIT implicite) 2. term2 Vérifier que la valeur est visible : SELECT ...

Q u e s t i o n 2 1. term1 Commencer une transaction : BEGIN TRANSACTION; 2. term1 Insérer la valeur 2 dans la table : INSERT INTO... 3. term1 Vérifier que la valeur est bien dans la table : SELECT * FROM ... 4. term2 Vérifier que la valeur n'est pas visible : SELECT * FROM ... 5. term1 Valider la transaction : COMMIT; 6. term2 Vérifier que la valeur est visible : SELECT * FROM ...

Q u e s t i o n 3 1. term1 Commencer une transaction : BEGIN TRANSACTION; 2. term1 Exécuter une mise à jour (multiplier toutes les valeurs par 2) : UPDATE... 3. term2 Exécuter une mise à jour concurrente (multiplier les valeurs par 3) : UPDATE... 4. term2 Observer la mise en attente 5. term1 Valider la transaction : COMMIT;



6. term2 Vérifier le déblocage et que les deux mises à jour ont bien été effectuées (amultiplié par 6) : SELECT...

7. term1 Vérifier que les deux mises à jour ont bien été effectuées (a multiplié par 6) :SELECT...

f) Solution aux trois problèmes soulevés par la concurrence.

IntroductionLe principe du verrouillage permet d'apporter une solution aux trois problèmes classiquessoulevés par les accès aux concurrents aux données par les transactions.

i Perte de mise à jour


t1

t2...

t3...

t4

... Inter-blocage

LIRE TVerrou S

LIRE TVerrou S

UPDATE T Attente...

...Attente...

UPDATE TAttente...

Tableau 16 Problème de la perte de mise à jour du tuple T par la transaction A

RemarqueLe problème de perte de mise à jour est réglé, mais soulève ici un autre problème, celui del'inter-blocage.

ii Accès à des données non validées


t1

t2...

t3

t4 Verrou S

UPDATE TVerrou X

LIRE TAttente...

ROLLBACKLibération du verrou X

Tableau 17 Problème de la lecture impropre du tuple T par la transaction A



iii Lecture incohérente


t1

t2...

t3...

... ... libération des verrous ... ... reprise de la transaction ...

LIRE TVerrou S

UPDATE TAttente...

LIRE TVerrous S

Tableau 18 Problème de la lecture non reproductible du tuple T par la transaction A

RemarqueLa lecture reste cohérente car aucune mise à jour ne peut intervenir pendant le processus delecture d'une même transaction.

g) Exercice

Soit l'exécution concurrente des deux transactions ci-dessous (on pose qu'aucune autretransaction ne s'exécute par ailleurs).NB : Le tableau fait état des temps auxquels les instructions sont soumises au serveur et nonauxquels elles sont traitées.

Temps Transaction 1 Transaction 2

t0 BEGIN TRANSACTION

t1 BEGIN TRANSACTION

t2

t3

t4

t5 COMMIT

t6

UPDATE TABLE1 SET TA-BLE1.A=TABLE1.A+1



?

Tableau 19 Transactions concurrentes

De combien le champ TABLE1.A a-t-il été augmenté à t6 du point de vue de la transaction 2 ?NB : Si vous pensez que le résultat ne peut être déterminé à cause d'une perte de mise à jourou d'un inter-blocage, répondez 0.



h) Complément : Protocole d'accès aux données.Méthode : Règles de verrouillage avant les lectures et écritures des donnéesSoit la transaction A voulant lire des données d'un tuple T :

1. A demande à poser un verrou S sur T 2. Si A obtient de poser le verrou alors A lit T 3. Sinon A attend le droit de poser son verrou (et donc que les verrous qui l'en empêchent

soient levés)Soit la transaction A voulant écrire des données d'un tuple T :

1. A demande à poser un verrou X sur T 2. Si A obtient de poser le verrou alors A écrit T 3. Sinon A attend le droit de poser son verrou (et donc que les verrous qui l'en empêchent

soient levés)Soit la transaction A se terminant (COMMIT ou ROLLBACK) :

1. A libère tous les verrous qu'elle avait posé 2. Certaines transactions en attente obtiennent éventuellement le droit de poser des

verrous

Remarque : Liste d'attenteAfin de rationaliser les attentes des transactions, des stratégies du type FIFO sontgénéralement appliquées et donc les transactions sont empilées selon leur ordre de demande.

5. Synthèse : Les transactions

TransactionUnité logique de travail pour assurer la cohérence de la BD même en cas de pannes ou d'accèsconcurrents.

Panne

Même en cas de panne, la BD doit rester cohérente.- Défaillances système

Coupure de courant, de réseau, etc.- Défaillances du support

Crash disque (dans ce cas les transactions peuvent être insuffisantes). Concurrence

Dimension relevant de la conception d'application.- Perte de mise à jour- Accès à des données non valides- Lecture incohérente

Programmation

Un programme peut décider de l'annulation d'une transaction.- ROLLBACK

Instruction SQL d'annulation d'une transaction.

6. Bibliographie commentée sur les transactions

Complément : SynthèsesLes transactions [w_developpez.com/hcesbronlavau] Une bonne introduction courte au principe des transactions avec un exemple très bien choisi.Des exemples d'implémentation sous divers SGBD (InterBase par exemple)SQL2 SQL3, applications à Oracle [Delmal01]



Une bonne description des principes des transactions, avec les exemples caractéristiques,l'implémentation SQL et une étude de cas sous Oracle 8 (chapitre 5).Tutoriel de bases de données relationnelles de l'INT Evry [w_int-evry.fr] (http://www-inf.int-evry.fr/COURS/BD/BD_REL/SUPPORT/poly.html#RTFToC306 Un aperçu général de l'ensemble de la problématique des transactions, de la concurrence et dela fiabilité. Programmation SQL [Mata03] Un exemple d'exécution de transactions (pages 20-23)

B. Exercices

1. Super-héros sans tête

[10 minutes]Les usines GARVEL construisent des figurines de super-héros à partir des données présentesdans la base de données PostgreSQL de l'entreprise. Un gros problème est survenu le moisdernier, lorsque l'usine en charge d'une nouvelle figurine, Superchild, a livré un milliond'exemplaires sans tête. À l'analyse de la base il a en effet été observé que la base contenaitun tuple "Superchild" dans la table Personnage, et cinq tuples associés dans la table Membre,deux pour les bras, deux pour les jambes et un pour le torse, mais aucun pour la tête. Le service qui a opéré la saisie du nouveau personnage assure, sans ambiguïté possible, que latête a pourtant été saisie dans la base. En revanche, l'enquête montre des instabilités de sonréseau à cette période.L'extrait du modèle UML utile au problème est proposé ci-après, ainsi que le code SQL exécutévia le client psql lors de l'insertion de la nouvelle figurine.

Modèle UML Figurines GARVEL (extrait)

1 \set AUTOCOMMIT on

6 - http://www-inf.int-evry.fr/COURS/BD/BD_REL/SUPPORT/poly.html#RTFToC30



http://www-inf.int-evry.fr/COURS/BD/BD_REL/SUPPORT/poly.html#RTFToC30

http://www-inf.int-evry.fr/COURS/BD/BD_REL/SUPPORT/poly.html#RTFToC30

2 INSERT INTO Personnage (designation, prix, identite_secrete, genre) VALUES ('Superchild','12','Jordy','superhéros') ;

3 INSERT INTO Membre (propriétaire, nom, couleur) VALUES ('Superchild','bras droit','bleu') ;

4 INSERT INTO Membre (propriétaire, nom, couleur) VALUES ('Superchild','bras gauche','bleu') ;

5 INSERT INTO Membre (propriétaire, nom, couleur) VALUES ('Superchild','jambe gauche','bleu') ;

6 INSERT INTO Membre (propriétaire, nom, couleur) VALUES ('Superchild','jambe droite','bleu') ;

7 INSERT INTO Membre (propriétaire, nom, couleur) VALUES ('Superchild','torse','rouge') ;

8 INSERT INTO Membre (propriétaire, nom, couleur) VALUES ('Superchild','tete','rose') ;

Q u e s t i o n 1

Expliquer la nature du problème qui est probablement survenu. Proposer une solution généralepour que le problème ne se renouvelle pas, en expliquant pourquoi. Soyez concis et précis : La bonne mobilisation des concepts du domaine et la clarté de larédaction seront appréciées.

Q u e s t i o n 2

Illustrer la solution proposée en corrigeant le code SQL de l'insertion de "Superchild".

2. Exercice : Films en concurrence

Soit la table Film suivante définie en relationnel permettant d'enregistrer le nombre d'entréesdes films identifiés par leur ISAN.

1 Film(#isan:char(33),entrees:integer)



Soit l'exécution concurrente de deux transactions TR1 et TR2 visant à ajouter chacune uneentrée au film '123' :

Temps Transaction TR1 Transaction TR2

t0 BEGIN

t1

BEGIN

t2 UPDATE Film SETentrees=entrees+1WHERE isan='123'

t3

t4

UPDATE Film SETentrees=entrees+1WHERE isan='123'

t5

t6 COMMIT

t7

t8

COMMIT

Tableau 20 Transaction parallèles TR1 et TR2 sous PostgreSQL

NB : Les instructions sont reportées au moment où elles sont transmises au serveur

Aucune autre transaction n'est en cours d'exécution entre t0 et t8.

Exercice

De combien les entrées du film 123 ont-t-elles été augmentées à t3 du point devue de la transaction TR1 ?

Exercice




Exercice


Exercice


Exercice


Exercice




X - Introduction à l'optimisation des bases de données

X

A. Cours

La conception des SGBDR exige qu'une attention particulière soit portée à la modélisationconceptuelle, afin de parvenir à définir des modèles logiques relationnels cohérents etmanipulables. De tels modèles relationnels, grâce au langage standard SQL, présentent laparticularité d'être implémentables sur toute plate-forme technologique indépendamment deconsidérations physiques.Néanmoins l'on sait que dans la réalité, il est toujours nécessaire de prendre en considérationles caractéristiques propres de chaque SGBDR, en particulier afin d'optimiserl'implémentation. Les optimisations concernent en particulier la question des performances,question centrale dans les applications de bases de données, qui, puisqu'elles manipulent desvolumes de données importants, risquent de conduire à des temps de traitement de cesdonnées trop longs par rapport aux besoins d'usage.Chaque SGBDR propose généralement des mécaniques propres pour optimiser lesimplémentations, et il est alors nécessaire d'acquérir les compétences particulières propres àces systèmes pour en maîtriser les arcanes. Il existe néanmoins des principes généraux, quel'on retrouvera dans tous les systèmes, comme par exemple les index, les groupements ou lesvues matérialisées. Nous nous proposerons d'aborder rapidement ces solutions pour enexaminer les principes dans le cadre de ce cours.Nous aborderons également quelques techniques de conception, qui consistent à revenir sur lastructure proposée par l'étape de modélisation logique, pour établir des modèles de donnéesplus aptes à répondre correctement à des questions de performance. La dénormalisation ou lepartitionnement en sont des exemples.


1. Introduction à l'optimisation du schéma interne

Objectifs

Assimiler la problématique de la performance en bases dedonnéesConnaître les grandes classes de solutions technologiquesexistantes aux problèmes de performanceConnaître et savoir mobiliser les techniques de conceptionpermettant d'optimiser les performances d'une BD

a) Schéma interne et performances des applicationsLa passage au schéma interne (ou physique), i.e. l'implémentation du schéma logique dans unSGBD particulier, dépend de considérations pratiques liées aux performances desapplications. Les possibilités d'optimisation des schémas internes des BD dépendent essentiellement desfonctions offertes par chaque SGBD.On peut néanmoins extraire certains principes d'optimisation des schémas internessuffisamment généraux pour être applicables dans la plupart des cas.

Proposition de solutionsParmi les solutions d'optimisation existantes, on pourra citer :

L'indexation

La dénormalisation

Le partitionnement vertical et horizontal

Les vues concrètes

Le regroupement (clustering) de tables

...

Méthode : Démarche d'optimisation 1. Des problèmes de performance sont identifiés, 2. des solutions d'optimisation sont proposées, 3. les solutions sont évaluées pour vérifier leur impact et leur réponse au problème posé.

b) Évaluation des besoins de performance

Éléments à surveillerPour optimiser un schéma interne, il est d'abord nécessaire de repérer les aspects du schémalogique qui sont susceptibles de générer des problèmes de performance.On pourra citer à titre d'exemple les paramètres à surveiller suivants :

Taille des tuples

Nombre de tuples

Fréquence d'exécution de requêtes

Complexité des requêtes exécutées (nombre de jointures, etc.)

Fréquence des mises à jour (variabilité des données)

Accès concurrents

Distribution dans la journée des accès

Qualité de service particulière recherchée

Paramétrabilité des exécutions

Introduction à l'optimisation des bases de données


etc.

Évaluation des coûtsUne fois les éléments de la BD à évaluer repérés, il faut mesurer si oui ou non ils risquent deposer un problème de performance.L'évaluation des performances peut se faire :

Théoriquement

En calculant le coût d'une opération (en temps, ressources mémoires, etc.) en fonctionde paramètres (volume de données, disparité des données, etc.). En général en BD lenombre de paramètres est très grand, et les calculs de coûts trop complexes pourrépondre de façon précise aux questions posées.

Empiriquement

En réalisant des implémentations de parties de schéma et en les soumettant à des testsde charge, en faisant varier des paramètres. Ce modèle d'évaluation est plus réalisteque le calcul théorique. Il faut néanmoins faire attention à ce que les simplificationsd'implémentation faites pour les tests soient sans influence sur ceux-ci.

c) Indexation

Définition : IndexUn index est une structure de données qui permet d'accélérer les recherches dans une table enassociant à une clé d'index (la liste des attributs indexés) l'emplacement physique del'enregistrement sur le disque. Les accès effectuées sur un index peuvent donc se faire sur des structures optimisées pour larecherche (liste triée, B-tree...) au lieu de se faire par parcours séquentiel et intégral desenregistrements.

ExempleConsulter une vidéo montrant la construction d'un index B-tree sur :http://www.youtube.com/embed/coRJrcIYbF47

Cf. "Exemple de construction d'un B-tree (b-tree-example)"Exemple de construction d'un B-tree

Méthode : Cas d'usage des index de type B-TreeLes index doivent être utilisés sur les tables qui sont fréquemment soumises à des recherches.Ils sont d'autant plus pertinents que les requêtes sélectionnent un petit nombred'enregistrements (moins de 25% par exemple).Les index doivent être utilisés sur les attributs :

souvent mobilisés dans une restriction (donc une jointure)

très discriminés (c'est à dire pour lesquels peu d'enregistrements ont les mêmesvaleurs)

rarement modifiés

Attention : Inconvénients des index Les index diminuent les performances en mise à jour (puisqu'il faut mettre à

jour les index en même temps que les données). Les index ajoutent du volume à la base de données et leur volume peut

devenir non négligeable.

7 - http://www.youtube.com/embed/coRJrcIYbF4



http://www.youtube.com/embed/coRJrcIYbF4

Syntaxe: Créer un index en SQL

1 CREATE INDEX nom_index ON nom_table (NomColonneClé1, NomColonneClé2, ...);

Remarque : Index implicitesLa plupart des SGBD créent un index pour chaque clé (primaire ou candidate). En effet lavérification de la contrainte d'unicité à chaque mise à jour des données justifie à elle seule laprésence de l'index.

Attention : Attributs indexés utilisés dans des fonctionsLorsque les attributs sont utilisés dans des restrictions ou des tris par l'intermédiairede fonctions, l'index n'est généralement pas pris en compte. L'opération ne seraalors pas optimisée. Ainsi par exemple dans le code suivant, le restriction sur X nesera pas optimisée même s'il existe un index sur X.

1 SELECT *2 FROM T3 WHERE ABS(X) > 100

Cette non prise en compte de l'index est logique dans la mesure où, on le voit surl'exemple précédent, une fois l'attribut soumis à une fonction, le classement dansl'index n'a plus forcément de sens (l'ordre des X, n'est pas l'ordre des valeursabsolues de X).Lorsqu'un soucis d'optimisation se pose, on cherchera alors à sortir les attributsindexés des fonctions.Notons que certains SGBD, tels qu'Oracle à partir de la version 8i, offrent desinstructions d'indexation sur les fonctions qui permettent une gestion del'optimisation dans ce cas particulier SQL2 SQL3, applications à Oracle [Delmal01].

d) Exercice

Soit les deux tables créées par les instructions suivantes :

1 CREATE TABLE T2 (2 E char(10) Primary Key);34 CREATE TABLE T1 (5 A number(5) Primary Key,6 B number(2) Not Null,7 C char(10) References T2(E),8 D char(5));

Soit une requête dont on cherche à optimiser les performances :

1 SELECT A2 FROM T1, T23 WHERE C=E AND Abs(B)>504 ORDER BY D;

Sachant que tous les attributs sont très discriminés (c'est à dire que les enregistrementscontiennent souvent des valeurs différentes les uns par rapport aux autres) et que les deuxtables contiennent un grand nombre d'enregistrements, quelles sont les instructions decréation d'index qui vont permettre d'optimiser l'exécution de cette requête ?



CREATE INDEX idxA ON T1(A);

CREATE INDEX idxB ON T1(B);

CREATE INDEX idxC ON T1(C);

CREATE INDEX idxD ON T1(D);

CREATE INDEX idxE ON T2(E);

e) Dénormalisation

RappelLa normalisation est le processus qui permet d'optimiser un modèle logique afin de le rendrenon redondant. Ce processus conduit à la fragmentation des données dans plusieurs tables.

Définition : DénormalisationProcessus consistant à regrouper plusieurs tables liées par des références, en une seule table,en réalisant statiquement les opérations de jointure adéquates. L'objectif de la dénormalisation est d'améliorer les performances de la BD en recherche surles tables considérées, en implémentant les jointures plutôt qu'en les calculant.

Remarque : Dénormalisation et redondanceLa dénormalisation est par définition facteur de redondance. A ce titre elle doit être utilisée àbon escient et des moyens doivent être mis en œuvre pour contrôler la redondance créée.

Méthode : Quand utiliser la dénormalisation ?Un schéma doit être dénormalisé lorsque les performances de certaines recherches sontinsuffisantes et que cette insuffisance à pour cause des jointures.

Attention : Inconvénients de la dénormalisationLa dénormalisation peut également avoir un effet néfaste sur les performances :

En mise à jour

Les données redondantes devant être dupliquées plusieurs fois. En contrôle supplémentaire

Les moyens de contrôle ajoutés (triggers, niveaux applicatifs, etc.) peuventêtre très coûteux.

En recherche ciblée

Certaines recherches portant avant normalisation sur une "petite" table etportant après sur une "grande" table peuvent être moins performantes aprèsqu'avant.

Fondamental : Redondance et bases de donnéesLa redondance volontaire est autorisée dans une base de données à trois conditions :

1. avoir une bonne raison d'introduire de la redondance (améliorer desperformances dans le cas de la dénormalisation)

2. documenter la redondance en explicitant les DF responsables de la non 3NF 3. contrôler la redondance par des mécanismes logiciels (triggers par exemple)



f) Les trois principes à respecter pour introduire de la redondance dansune base de données

FondamentalLa redondance volontaire est autorisée dans une base de données à condition derespecter trois principes :

1. il faut avoir une bonne raison d'introduire de la redondance (améliorer desperformances dans le cas de la dénormalisation)

2. il faut documenter la redondance en explicitant les DF responsables del'absence de 3NF

3. il faut contrôler la redondance par des mécanismes logiciels qui vont assurerque la redondance n'introduit pas d'incohérence (triggers par exemple)

g) Exercice

Soit les deux tables créées par les instructions suivantes :

1 CREATE TABLE T2 (2 C char(10) Primary Key,3 E char(10));45 CREATE TABLE T1 (6 A char(10) Primary Key,7 B char(10), 8 C char(10) References T2(C),9 D char(10));

Parmi les instructions suivantes qui viendraient remplacer les deux créations précédentes,lesquelles implémenteraient une dénormalisation ?



CREATE TABLE T3 (B char(10) Primary Key,D char(10));CREATE TABLE T2 (C char(10) Primary Key,E char(10));CREATE TABLE T1 (A char(10) Primary Key,B char(10) References T3(B),C char(10) References T2(C));

CREATE TABLE T1 (A char(10) Primary Key,B char(10), C char(10) Unique Not Null,D char(10),E char(10));

CREATE TABLE T1 (A char(10) Primary Key,B char(10), C char(10),D char(10),E char(10));

CREATE TABLE T5 (E char(10) Primary Key);

CREATE TABLE T4 (D char(10) Primary Key);

CREATE TABLE T3 (B char(10) Primary Key);

CREATE TABLE T2 (C char(10) Primary Key,E char(10) References T5(E));

CREATE TABLE T1 (A char(10) Primary Key,B char(10) References T3(B),C char(10) References T2(C),D char(10) References T4(D));



h) Partitionnement de tableDéfinition : Partitionnement de tableLe partitionnement d'une table consiste à découper cette table afin qu'elle soit moinsvolumineuse, permettant ainsi d'optimiser certains traitements sur cette table. On distingue :

Le partitionnement vertical, qui permet de découper une table en plusieurs tables,chacune ne possédant qu'une partie des attributs de la table initiale.

Le partitionnement horizontal, qui permet de découper une table en plusieurs tables,chacune ne possédant qu'une partie des enregistrements de la table initiale.

Définition : Partitionnement verticalLe partitionnement vertical est une technique consistant à implémenter des projectionsd'une table T sur des tables T1, T2, etc. en répétant la clé de T dans chaque Ti pour pouvoirrecomposer la table initiale par jointure sur la clé (Bases de données : objet et relationnel[Gardarin99]).

RemarqueCe découpage équivaut à considérer l'entité à diviser comme un ensemble d'entités reliées pardes associations 1:1.

Méthode : Cas d'usage du partitionnement verticalUn tel découpage permet d'isoler des attributs peu utilisés d'autres très utilisés, et ainsiaméliore les performances lorsque l'on travaille avec les attributs très utilisés (la table étantplus petite).Cette technique diminue les performances des opérations portant sur des attributs ayant étérépartis sur des tables différentes (une opération de jointure étant à présent requise). Le partitionnement vertical est bien entendu sans intérêt sur les tables comportant peud'attributs.

Définition : Partitionnement horizontalTechnique consistant à diviser une table T selon des critères de restriction en plusieurstables T1, T2... et de telle façon que tous les tuples de T soit conservés. La table T est alorsrecomposable par union sur les Ti (Bases de données : objet et relationnel [Gardarin99]).

Méthode : Cas d'usageUn tel découpage permet d'isoler des enregistrements peu utilisés d'autres très utilisés, etainsi améliore les performances lorsque l'on travaille avec les enregistrements très utilisés (latable étant plus petite). C'est le cas typique de l'archivage. Un autre critère d'usage est le faitque les enregistrements soient toujours utilisés selon un partitionnement donné (par exemplele mois de l'année).Cette technique diminue les performances des opérations portant sur des enregistrementsayant été répartis sur des tables différentes (une opération d'union étant à présent requise). Le partitionnement horizontal est bien entendu sans intérêt sur les tables comportant peud'enregistrements.

i) Exercice

Soit la table suivante contenant des listes de références produits :

1 CREATE TABLE Tref (2 ref1 char(100) Primary Key,3 ref2 char(100) Unique Not Null, 4 ref3 char(100) Unique Not Null,5 ref4 char(100) Unique Not Null,



6 ref5 char(100) Unique Not Null,7 ref6 char(100) Unique Not Null,8 ref7 char(100) Unique Not Null);

On cherche à optimiser la requête suivante ("_" et "%" sont des jokers qui signifientrespectivement "1 caractère quelconque" et "0 à N caractères quelconques") :

1 SELECT ref1 2 FROM Tref 3 WHERE (ref2 like 'REF42%' or ref2 like 'REF__7%' or ref2 like 'REF_78%');

Quelles sont les opérations de partitionnement qui permettront d'optimiser cette requête defaçon maximale (indépendamment des conséquences pour d'éventuelles autres requêtes) ?

Un partitionnement horizontal

Un partitionnement vertical

j) Vues concrètes

Un moyen de traiter le problème des requêtes dont les temps de calcul sont très longs et lesfréquences de mise à jour faible est l'utilisation de vues concrètes.

Définition : Vue concrèteUne vue concrète est un stockage statique (dans une table) d'un résultat de requête. Un accès à une vue concrète permet donc d'éviter de recalculer la requête et est donc aussirapide qu'un accès à une table isolée. Il suppose par contre que les données n'ont pas étémodifiées (ou que leur modification est sans conséquence) entre le moment où la vue a étécalculée et le moment où elle est consultée.Une vue concrète est généralement recalculée régulièrement soit en fonction d'un événementparticulier (une mise à jour par exemple), soit en fonction d'un moment de la journée ou ellen'est pas consultée et où les ressources de calcul sont disponibles (typiquement la nuit).Synonymes : Vue matérialisée

Complément : Voir aussiVue matérialisée sous Oracle

k) Complément : Groupement de tables

Définition : Groupement de tableUn groupement ou cluster est une structure physique utilisée pour stocker des tables surlesquelles doivent être effectuées de nombreuses requêtes comprenant des opérations dejointure. Dans un groupement les enregistrements de plusieurs tables ayant une même valeur dechamps servant à une jointure (clé du groupement) sont stockées dans un même blocphysique de la mémoire permanente.Cette technique optimise donc les opérations de jointure, en permettant de remonter les tuplesjoints par un seul accès disque.

Définition : Clé du groupementEnsemble d'attributs précisant la jointure que le groupement doit optimiser.

Syntaxe: Syntaxe sous OracleIl faut d'abord définir un groupement, ainsi que les colonnes (avec leur domaine), quiconstituent sa clé. On peut ainsi ensuite, lors de la création d'une table préciser que certainesde ses colonnes appartiennent au groupement.



1 CREATE CLUSTER nom_cluster (NomColonneClé1 type, NomColonneClé2 type, ...);23 CREATE TABLE nom_table (...)4 CLUSTER nom_cluster (Colonne1, Colonne2, ...);

RemarqueLe clustering diminue les performances des requêtes portant sur chaque table prise de façonisolée, puisque les enregistrements de chaque table sont stockés de façon éclatée.

Remarque : Groupement et dénormalisationLe groupement est une alternative à la dénormalisation, qui permet d'optimiser les jointuressans créer de redondance.

2. Mécanismes d'optimisation des moteurs de requêtes

Objectifs

Comprendre les principes de fonctionnement du moteurd'optimisation interne aux SGBD

a) Calcul du coût d'une requête

Soit deux relations t1(a:char(8),b:integer) et t2(b:integer) de respectivement 100 et 10lignes.Soit la requête SELECT * FROM t1 INNER JOIN t2 ON t1.b=t2.b WHERE t2.b=1.

Soit n1 le nombre de tuples tels que b=1 dans t1 ; n1 [0..100]∈

Soit n2 le nombre de tuples tels que b=1 dans t2 ; n2 [0..10]∈

Soit n3 le nombre de tuples tels que t1.b=t2.b ; : n3 [0..1000]∈

Q u e s t i o n 1Il existe plusieurs façons de traduire cette requête en algèbre relationnel, proposer quelquesexemples.

Q u e s t i o n 2

Calculer le nombre d'instructions de chaque exemple d'expression relationnelle : en considérant que les restrictions sont effectuées par un parcours intégral dans des

listes non triées (comme si c'était effectué avec des boucles de type FOR) ; en considérant que chaque opération est effectuée séparément.

Effectuer les calculs pour trois valeurs de n1,n2 et n3 (une valeur minimum, une valeurmaximum et une valeur intermédiaire). Donner un intervalle [min..max] indépendant de n1,n2 et n3.

Q u e s t i o n 3Conclure en indiquant quelle opération nécessite le moins d'instructions.

b) Principe de l'optimisation de requêtes

L'exécution d'une requête SQL suit les étapes suivantes : 1. Analyse syntaxique : Vérification de la correction syntaxique et traduction en opérations

algébriques 2. Contrôle : Vérification des droits d'accès 3. Optimisation : Génération de plans d'exécution et choix du meilleur



4. Exécution : Compilation et exécution du plan choisi

Définition : Plan d'exécutionL'analyse de la requête permet de produire un arbre d'opérations à exécuter.Or il est possible de transformer cet arbre pour en obtenir d'autres équivalents, qui proposentdes moyens différents pour arriver au même résultat, on parle de différents plansd'exécution.

Définition : Optimisation de la requêteL'optimisation de la requête est une opération informatique visant à réécrire l'arbre d'exécutionde la requête en vue de choisir le plan d'exécution le plus performant.

c) Techniques pour l'optimisation de requêtes

Restructuration algébriqueIl existe des propriétés permettant de modifier l'ordre des opérateurs algébriques, afind'obtenir des gains de performance par exemple :

Le groupage des restrictions : Il permet d'effectuer plusieurs restrictions en un seulparcours de la table, au lieu d'un par restrictionRestriction (Restriction (t,x=a), x=b) <=> Restriction (t,x=a ET x=b)

La commutativité des restrictions et Jointures : Elle permet d'appliquer les restrictionsavant les jointures

L'associativité des jointures : Elle permet de changer l'ordre des jointures, afin d'utiliserdes algorithmes plus performants dans certains cas

...

Heuristiques d'optimisationLe moteur d'optimisation de la base de données va poser des règles de réécriture pourproduire des arbres d'exécutions et choisir les moins coûteux.Il va typiquement appliquer d'abord les opérations réductrices (restrictions etprojections).

informations statistiques (modèle de coût)Une des actions du moteur est d'ordonner les jointures (et les opérations ensemblistes) afinde :

traiter le moins de tuples possibles ;

mobiliser les index existants au maximum ;

utiliser les algorithmes les plus performants.

Pour cela le moteur d'optimisation a besoin de connaître le contenu de la BD : nombre detuples dans les tables, présence ou non d'index, ...Le moteur de la BD met à sa disposition des informations statistiques répondant à ces besoins.

d) Collecte de statistiques pour le moteur d'optimisation

Le moteur d'optimisation d'une BD a besoin de collecter des informations sur les tables qu'il aà manipuler afin de choisir les meilleurs plans d'exécution, sur la taille des tables typiquement.Il est nécessaire de commander au moteur de collecter ces statistiques lorsque deschangements de contenu importants ont été effectués dans la BD.

Syntaxe: PostgreSQL : Analyse d'une table

1 ANALYSE <table> ;



Syntaxe: PostgreSQL : Analyse de toute la base

1 ANALYSE;

Syntaxe: PostgreSQL : Récupération des espaces inutilisés et analyse de toute la base

1 VACUUM ANALYZE ;

Complément : Exemple de données collectées nombre de lignes

volume des données

valeurs moyennes, minimales, maximales

nombre de valeurs distinctes (indice de dispersion)

nombre d'occurrences des valeurs les plus fréquentes (notamment pour les colonnespourvues d'index...)

http://sqlpro.developpez.com/cours/sqlaz/fondements/#L2.18

e) Jointures et optimisation de requêtes

AlgorithmesIl existe plusieurs algorithmes pour réaliser une jointure :

Jointures par boucles imbriquées (nested loop) : chaque tuple de la première table estcomparé à chaque tuple de la seconde table.

Jointure par tri-fusion (sort-merge) : les deux tables sont d'abord triées sur l'attribut dejointure, puis elles sont fusionnées.

Jointure par hachage (hash join) : les deux tables sont hachées, puis jointes parfragment.

3. Analyse et optimisation manuelle des requêtes

Objectifs

Savoir afficher et interpréter un plan d'exécution de requêteSavoir écrire des requêtes performantes

a) Analyse de coûts de requêtes (EXPLAIN)

Définition : Plan d'exécutionLe moteur SQL d'une BD peut afficher le plan qu'il prévoit d'exécuter pour une requête donnée,c'est à dire la liste des opération qui vont être exécutées, ainsi qu'une estimation du coup deces opérations.

Syntaxe: Syntaxe PostgreSQL

1 EXPLAIN <requête SQL>

8 - http://sqlpro.developpez.com/cours/sqlaz/fondements/#L2.1



http://sqlpro.developpez.com/cours/sqlaz/fondements/#L2.1

ExempleSoit la table "taero" des aérodromes de France.

SELECT count(*) FROM taero;

retourne 421 SELECT * FROM taero LIMIT 7;

retourne la table ci-après.

Image 37 Sept premières lignes de la table "taero"

Image 38 EXPLAIN SELECT code FROM taero

EXPLAIN SELECT code FROM taero retourne "Seq Scan on taero (cost=0.00..8.21rows=421 width=16)"

L'opération exécute un sequential scan (parcours séquentiel de toute la table)

Le coût estimé de démarrage (coût pour récupérer le premier enregistrement) est de0.00 et le coût estimé total (coût pour récupérer tous les tuples) est de 8.21. L'unité est relative aux pages disque accédées, mais elle peut être considéréearbitrairement pour faire des comparaisons.

Le nombre estimé de lignes rapportées est de 421, pour une taille de 16 octetschacune.

Définition : Analyse d'exécutionLe moteur SQL d'une BD peut exécuter une requête et afficher le coût réellement observéd'exécution des opérations.



Syntaxe: Syntaxe PostgreSQL

1 EXPLAIN ANALYSE <requête SQL>

Exemple

Image 39 EXPLAIN ANALYSE SELECT code FROM taero

EXPLAIN ANALYSE SELECT code FROM taero retourne "Seq Scan on taero(cost=0.00..8.21 rows=421 width=16) (actual time=0.017..1.960 rows=421 loops=1)Total runtime: 3.668 ms"

Le coût réel de démarrage de l'opération est de 0.017ms et le coût réel total est de1.960ms

Le nombre de lignes réellement rapporté est de 421

loops=1 indique l'opération de Seq Scan a été exécuté une seule fois

Le coût total de 3.668ms inclut le temps lié à l'environnement du moteur d'exécution(start and stop).

Attention 1. EXPLAIN ne donne qu'une valeur estimée algorithmiquement du coût :

- cette estimation est indépendante de contingences matériel, c'est un coûtthéorique

- cette estimation est reproductible (chaque exécution donne desinformations identiques)

- l'instruction SQL n'est pas exécutée 2. ANALYSE donne un temps de calcul mesuré réellement :

- ce temps mesuré dépend de l'environnement matériel (état du réseau,charge du serveur, ...)

- ce temps mesuré est variable à chaque exécution (en fonction des élémentsprécédents)

- l'instruction SQL est exécutée (on peut insérer la requête à analyser dans une transaction et effectuer unROLLBACK si l'on souhaite analyser l'exécution d'une requête sansl'exécuter)

RemarqueEXPLAIN n'existe pas dans le standard SQL.



Complément : Pour aller plus loin : PostgreSQL http://www.postgresql.org/docs/current/static/sql-explain.html9

http://www.postgresql.org/docs/current/static/using-explain10

http://www.bortzmeyer.org/explain-postgresql.html11

Syntaxe: Syntaxe sous Oracle

1 EXPLAIN PLAN FOR <requête SQL>

Il faut préalablement avoir créé ou avoir accès à une table particulière PLAN_TABLE qui sert àstocker les résultats du EXPLAIN.

Complément : Pour aller plus loin : Oracle http://jpg.developpez.com/oracle/tuning/12

b) Optimisation manuelle des requêtes

La façon d'écrire des requêtes influe sur l'exécution. L'idée générale est d'écrire des requêtesqui :

minimisent les informations retournées (par exemple en faisant toutes les projectionspossibles) ;

minimisent les traitements (par exemple en faisant toutes les restrictions possibles) ;

évitent des opérations inutiles (par exemple : SELECT DISTINCT, ORDER BY...) ;

Complément : Trucs et astuces...http://sqlpro.developpez.com/cours/optimiser/#L913

4. Synthèse : L'optimisation

OptimisationModification du schéma interne d'une BD pour en améliorer les performances.

Techniques au niveau physique- Indexation- Regroupement physique - Vue concrète

Techniques de modélisation- Dénormalisation- Partitionnement

Horizontal Vertical

5. Bibliographie commentée sur l'optimisation

Complément : SynthèsesSQL2 SQL3, applications à Oracle [Delmal01]

9 - http://www.postgresql.org/docs/current/static/sql-explain.html10 - http://www.postgresql.org/docs/current/static/using-explain11 - http://www.bortzmeyer.org/explain-postgresql.html12 - http://jpg.developpez.com/oracle/tuning/13 - http://sqlpro.developpez.com/cours/optimiser/#L9



http://sqlpro.developpez.com/cours/optimiser/#L9

http://jpg.developpez.com/oracle/tuning/

http://www.bortzmeyer.org/explain-postgresql.html

http://www.postgresql.org/docs/current/static/using-explain

http://www.postgresql.org/docs/current/static/sql-explain.html

Une bonne description des index (page 79) et clusters (page 81) par l'image. Une descriptionintéressante d'une fonction (sous Oracle 8i) qui permet d'indexer des fonctions, ce qui répondà un problème important d'optimisation (page 84). Une description des vues matérialisées,leur implémentation sous Oracle, des exemples d'usage dans le domaine du datawarehouse.Bases de Données Relationnelles et Systèmes de Gestion de Bases de Données Relationnels, leLangage SQL [w_supelec.fr/~yb] Des informations générales sur les index14 et sur les clusters15.

B. Exercices

1. Film concret

Soit le schéma relationnel suivant :

1 Film (#isan:char(33), titre:varchar(25), entrees:integer, nomReal=>Realisateur(nom), prenomReal=>Realisateur(prenom))

2 Realisateur (#nom:varchar(25), #prenom:varchar(25), ddn:date)

Soit la requête suivante portant sur ce schéma implémenté sous PostgreSQL :

1 SELECT f.titre AS film, r.ddn AS real2 FROM Film f, Realisateur r3 WHERE f.nomReal=r.nom AND f.prenomReal=r.prenom

Q u e s t i o n Proposer une optimisation de cette requête sous la forme de la vue matérialisée vTopFilms.

2. Super-lents

[10 minutes]L'entreprise GARVEL propose des figurines de super-héros à acheter en ligne sur un siteInternet adossé à sa base de données. Son catalogue a atteint cette année le million demodèles. Depuis quelques temps, et la récente forte augmentation des modèles au catalogue,les performances des consultations ont beaucoup chuté, entraînant des temps d'accès lents(plusieurs secondes) et une baisse des actes d'achat.La requête la plus utilisée par l'application Web sert à lister tous les super-héros avec toutesleurs caractéristiques, avec leurs véhicules et leurs repaires (et également toutes leurscaractéristiques) et à la trier par ordre de prix.

14 - http://wwwsi.supelec.fr/~yb/poly_bd/node122.html15 - http://wwwsi.supelec.fr/~yb/poly_bd/node126.html



http://wwwsi.supelec.fr/~yb/poly_bd/node126.html

http://wwwsi.supelec.fr/~yb/poly_bd/node122.html

Modèle UML Figurines GARVEL

Soyez concis et précis dans vos réponses ; La bonne mobilisation des concepts du domaineet la clarté de la rédaction seront appréciées.

Q u e s t i o n 1

Expliquer pourquoi cette requête peut poser des problèmes de performance, lorsque la basecomprend de nombreux enregistrements.

Q u e s t i o n 2Proposer et justifier une première solution d'optimisation à mettre en œuvre qui sera utile danstous les cas et n'aura que peu d'effets indésirables. Puis, expliquer pourquoi le passage enrelationnel-objet de la base de données, combiné à la solution précédente, peut améliorerconsidérablement les performances.

Q u e s t i o n 3

Proposer deux solutions alternatives qui, si l'on reste en relationnel, permettraient d'améliorerconsidérablement les performances. Vous en poserez les avantages, inconvénients et lesmesures à prendre pour contenir ces inconvénients.



Glossaire

Relation toute cléEn base de données, on appelle une relation toute clé une relation dont tous les attributs sontnécessaires pour constituer une clé.


Signification des abréviations

- 1NF First Normal Form- 2NF Second Normal Form- 3NF Third Normal Form- 4NF Fourth Normal Form- 5NF Fifth Normal Form- ACID Atomicity, Consistency, Isolation, Durability- BCNF Boyce-Codd Normal Form- BD Base de Données- DDN Date De Naissance- DF Dépendance Fonctionnelle- DFE Dépendance Fonctionnelle Elémentaire- E-A Entité-Association- FIFO First In First Out- LCD Langage de Contrôle de Données- LMD Langage de Manipulation de Données- MCD Modèle Conceptuel de Données- MLD Modèle Logique de Données- SGBD Système de Gestion de Bases de Données- SQL Structured Query Language- UML Unified Modeling Language


Bibliographie

[Celko00] CELKO JOE. SQL avancé : Programmation et techniques avancées. Vuibert, 2000.

[Delmal01] DELMAL PIERRE. SQL2 SQL3, applications à Oracle. De Boeck Université, 2001.

[Gardarin99] GARDARIN GEORGES. Bases de données : objet et relationnel. Eyrolles, 1999.

[Mata03] MATA-TOLEDO RAMON A., CUSHMAN PAULINE K.. Programmation SQL. Ediscience, 2003.

[Roques04] ROQUES PASCAL, VALLÉE FRANCK. UML 2 en action : De l'analyse des besoins à la conception J2EE. ISBN 2-212-11462-1 (3ème édition). Paris : Eyrolles, 2004. 385 p. architecte logiciel.

[Roques09] PASCAL ROQUES, UML 2 par la pratique, 7e édition, Eyrolles, 2009 [ISBN 978-2212125658]


Webographie

[w_developpez.com/hcesbronlavau] CESBRON-LAVAU HENRY, Les transactions,http://www.developpez.com/hcesbronlavau/Transactions.htm , 2002.

[w_dia] Dia, http://live.gnome.org/Dia

[w_int-evry.fr] DEFUDE BRUNO, Tutoriel de bases de données relationnelles de l'INT Evry, http://www-inf.int-evry.fr/COURS/BD/ , consulté en 2009.

[w_journaldunet.com(1)] MORLON JÉRÔME, UML en 5 étapes,http://developpeur.journaldunet.com/dossiers/alg_uml.shtml , 2004.

[w_journaldunet.com(2)] BORDERIE XAVIER, Cinq petits conseils pour un schéma UML efficace,http://developpeur.journaldunet.com/tutoriel/cpt/031013cpt_uml5conseils.shtml , 2004.

[w_objecteering] Objecteering software. http://www.objecteering.com . [2002-septembre].

[w_supelec.fr/~yb] BOURDA YOLAINE, Bases de Données Relationnelles et Systèmes de Gestion de Bases de DonnéesRelationnels, le Langage SQL, http://wwwsi.supelec.fr/~yb/poly_bd/ , consulté en 2009.

[w_uml.free.fr] UML en Français, http://uml.free.fr , consulté en 2002.


http://uml.free.fr/

http://wwwsi.supelec.fr/~yb/poly_bd/

http://www.objecteering.com/

http://developpeur.journaldunet.com/tutoriel/cpt/031013cpt_uml5conseils.shtml

http://developpeur.journaldunet.com/dossiers/alg_uml.shtml

http://www-inf.int-evry.fr/COURS/BD/

http://www-inf.int-evry.fr/COURS/BD/

http://live.gnome.org/Dia

http://www.developpez.com/hcesbronlavau/Transactions.htm

Index

1:1.................. p.45, 46, 47, 47, 481:N................................ p.591NF............................... p.1022NF............................... p.1033NF.......................... p.104, 105Abstraite.......................... p.8Acces....................... p.125, 130ACID............................. p.123Agrégat p.66, 66, 68, 69, 70, 73, 73, 75,75Agrégation................... p.73, 75Algèbre............................. p.Annulation..................... p.123Armstrong................... p.97, 97Association p.32, 34, 37, 38, 39, 46,47, 47, 48, 59, 59Association 1:1................ p.48Atomicité....................... p.102Attente.......................... p.140Attribut....................... p.34, 39BCNF............................. p.105Calcul.................. p.69, 70, 73, 75Cardinalité................... p.59, 59Classe........................ p.8, 8, 39Classe abstraite............... p.60Clé................................ p.100Cluster.......................... p.153Cohérence...... p.122, 123, 123, 133COMMIT.............. p.124, 126, 128Composition................ p.32, 37Conception...................... p.94Conceptuel p.5, 9, 16, 21, 31, 36, 40,45, 45, 51, 84Concurrence......... p.122, 133, 138Contraintes.................. p.52, 58Contrôle.......................... p.88CREATE INDEX............... p.147CREATE VIEW.................. p.83Décomposition. . p.95, 101, 102, 111Défaillance..................... p.122Dénormalisation. . . p.149, 150, 153

Dépendance....... p.93, 95, 101, 111Déverrouillage................ p.136DF...... p.96, 97, 97, 98, 99, 99, 99, 102Diagramme.......... p.5, 8, 9, 31, 51Différence.......................... p.Droits............................. p.88Durabilité....................... p.124Dynamique...................... p.52Ecriture......................... p.135Évaluation...................... p.146Exclusif........................... p.22Exécution....................... p.123Fermeture....................... p.99Fiabilité......................... p.130Fonction.............. p.69, 70, 73, 75GRANT............................ p.89GROUP BY........ p.66, 68, 73, 75, 75Groupement................... p.153HAVING.......................... p.75Héritage p.5, 6, 8, 10, 16, 18, 18, 19,20, 21, 21, 22, 24, 26, 60, 61, 62, 84, 84,85, 86Index............................ p.147Inter-blocage............ p.136, 138Intersection....................... p.Jointure............................. p.Journal................ p.124, 128, 128Langage...................... p.66, 73LCD................................ p.88Lecture.......................... p.135LMD............................ p.66, 73Logique p.16, 21, 36, 40, 45, 45, 84, 93,95, 101, 111Méthode............................ p.Modèle.............. p.93, 95, 101, 111N:M.................................. p.N :M............................... p.59NF................................. p.101Nomalisation................ p.93, 95Normalisation p.95, 96, 97, 97, 98,99, 99, 99, 101, 101, 102, 102, 103, 104,111, 149, 150

Opération.......................... p.Optimisation. p.93, 95, 101, 146, 146Oracle................. p.125, 125, 130Panne....... p.124, 127, 128, 129, 131Partitionnement.............. p.152Passage. . . p.16, 21, 36, 40, 45, 45, 84Performance................... p.146Perte............................. p.133PL/SQL..................... p.125, 130Point de contrôle. . p.128, 129, 131Problème........................ p.94Projection...................... p.152Propriété......................... p.34Question..................... p.66, 73Redondance p.93, 94, 95, 101, 111,149, 150Regroupement............. p.66, 68Relationnel p.10, 16, 18, 18, 19, 20,21, 21, 22, 24, 26, 36, 37, 38, 39, 40, 45,45, 46, 47, 47, 48, 57, 58, 59, 59, 60, 61,62, 84, 84, 85, 86, 93, 95, 101, 111Requête...................... p.66, 73Restriction..................... p.152REVOKE.......................... p.89ROLLBACK...... p.124, 126, 127, 136Schéma......................... p.146SQL.... p.66, 73, 88, 124, 125, 126, 130Transaction p.123, 125, 125, 125, 130Transfert........................ p.130UML p.5, 6, 8, 8, 9, 10, 16, 18, 18, 19, 20,21, 21, 22, 24, 26, 31, 32, 34, 36, 37, 38,39, 40, 45, 45, 46, 47, 47, 48, 51, 52, 57,58, 59, 59, 60, 61, 62, 84, 84, 85, 86UNDO-REDO................... p.131Union................................ p.Unité.............. p.123, 123, 127, 129Utilisateur....................... p.88Validation...................... p.123VBA......................... p.125, 130Verrou....... p.135, 136, 136, 138, 140Vue........................... p.83, 153


Conception des bases de données II : Conception des bases de … · s t p h. s c e n a r i-c o m m...

Documents

Transcript of Conception des bases de données II : Conception des bases de … · s t p h. s c e n a r i-c o m m...