Base de Donnée

NF17
CONCEPTION
DE BASES
DE DONNES
Version 10.01 Cours Gnral
STPHANE CROZAT
Paternit - Pas d'Utilisation Commerciale - Partage des Conditions Initiales l'Identique : http://creativecommons.org/licenses/by-nc-sa/2.0/fr/
Publi le 11 janvier 2010
TABLE DES MATIRES
Introduction I - Prsentation des bases de donnes
9 11
A. BD et SGBD : vue d'ensemble...............................................................................................................11

1. Qu'est ce qu'une BD ?..................................................................................................................................................11 2. Qu'est ce qu'un SGBD ?...............................................................................................................................................11 3. Pourquoi des SGBD ?..................................................................................................................................................12 4. Caractristiques des SGBD.........................................................................................................................................13
B. Notions gnrales pour les bases de donnes........................................................................................13

1. Notion de donnes........................................................................................................................................................14 2. Notion de modle de donnes......................................................................................................................................14 3. Notion de schma de donnes......................................................................................................................................15 4. Notion de langage de donnes.....................................................................................................................................16 5. Notion d'administration de donnes............................................................................................................................17
C. Les mthodes de conception de bases de donnes.................................................................................17

1. Mthodologie de conception d'une base de donnes...................................................................................................18 2. La mthode MERISE et le modle E-A........................................................................................................................19 3. Le langage de modlisation UML................................................................................................................................19 4. lments pour l'analyse de l'existant et des besoins....................................................................................................19 5. Le MCD........................................................................................................................................................................21 6. Le MLD........................................................................................................................................................................21
D. En rsum : Conception de bases de donnes.......................................................................................22
II - Le niveau conceptuel
: la modlisation des bases de donnes
23
A. Bases du diagramme de classes UML...................................................................................................23

1. Prsentation d'UML.....................................................................................................................................................23 2. Classes.........................................................................................................................................................................24 3. Attributs.......................................................................................................................................................................24 4. Mthodes......................................................................................................................................................................25 5. Associations.................................................................................................................................................................26 6. Cardinalit...................................................................................................................................................................27 7. Hritage.......................................................................................................................................................................27 8. Exemple : Des voitures et des conducteurs..................................................................................................................28
B. Diagramme de classes UML avanc......................................................................................................29

1. Explicitation des associations......................................................................................................................................29 2. Classe d'association.....................................................................................................................................................30 3. Associations ternaires..................................................................................................................................................31 4. Composition.................................................................................................................................................................31 5. Classes abstraites........................................................................................................................................................32 6. Contraintes...................................................................................................................................................................34 7. Contraintes sur les associations..................................................................................................................................35 8. Paquetages...................................................................................................................................................................36
C. Le modle E-A.......................................................................................................................................37
1. Le modle E-A en bref.................................................................................................................................................37
S. Crozat - UTC 2009
2. Entit............................................................................................................................................................................37 3. Association...................................................................................................................................................................39 4. Cardinalit d'une association......................................................................................................................................39 5. Modle E-A tendu.......................................................................................................................................................40 6. Entit de type faible.....................................................................................................................................................41 7. Illustration d'entits faibles.........................................................................................................................................41
D. En rsum : Schma conceptuel............................................................................................................42 E. Bibliographie commente sur la modlisation UML.............................................................................43
III - Le niveau logique
: la modlisation relationnelle
45
A. Description du modle relationnel.........................................................................................................45

1. Le niveau logique.........................................................................................................................................................45 2. Le modle relationnel..................................................................................................................................................46 3. Domaine.......................................................................................................................................................................46 4. Produit cartsien..........................................................................................................................................................46 5. Relation........................................................................................................................................................................47 6. Attribut et enregistrement............................................................................................................................................47 7. La relation Vol.............................................................................................................................................................48 8. Cl................................................................................................................................................................................48 9. Cl artificielle..............................................................................................................................................................49 10. Lien entre relations....................................................................................................................................................50 11. clatement des relations pour viter la redondance.................................................................................................50 12. Cl trangre.............................................................................................................................................................52 13. Schma relationnel....................................................................................................................................................52 14. Exemple de schma relationnel simple pour la gographie......................................................................................53
B. Le passage UML vers Relationnel.........................................................................................................54

1. Transformation des classes..........................................................................................................................................54 2. Transformation des associations.................................................................................................................................55 3. Remarques concernant la transformation des associations 1:1..................................................................................55 4. Transformation des attributs et mthodes...................................................................................................................56 5. Transformation des classes d'association....................................................................................................................56 6. Transformation des compositions................................................................................................................................57 7. Transformation de la relation d'hritage.....................................................................................................................57 8. Transformation de la relation d'hritage par rfrence..............................................................................................59 9. Transformation de la relation d'hritage par les classes filles....................................................................................59 10. Transformation de la relation d'hritage par la classe mre....................................................................................60 11. Exemple de transformation d'une relation d'hritage...............................................................................................61 12. Hritage et cl primaire.............................................................................................................................................63 13. Liste des contraintes..................................................................................................................................................63 14. Correspondance entre UML et relationnel................................................................................................................63
C. Le passage E-A vers Relationnel...........................................................................................................64

1. Transformation des entits...........................................................................................................................................64 2. Transformation des associations.................................................................................................................................64 3. Transformation de la relation d'hritage.....................................................................................................................65 4. Exemple de passage E-A vers relationnel....................................................................................................................65 5. Comparaison des modles E-A, UML et relationnel...................................................................................................66
D. Algbre relationnelle.............................................................................................................................67
1. Concepts manipulatoires.............................................................................................................................................67 2. Oprateurs ensemblistes..............................................................................................................................................68 3. Projection.....................................................................................................................................................................69 4. Restriction....................................................................................................................................................................69 5. Produit.........................................................................................................................................................................70 6. Jointure........................................................................................................................................................................70 7. Jointure naturelle.........................................................................................................................................................71 8. Jointure externe...........................................................................................................................................................71 9. Division........................................................................................................................................................................72 10. Proposition de notations............................................................................................................................................73 11. Exercice de synthse : Oprateurs de base et additionnels.......................................................................................73
E. En rsum : Schma relationnel.............................................................................................................74 F. Bibliographie commente sur le modle relationnel..............................................................................74
IV - Le langage SQL
75
A. Qu'appelle-t-on SQL?............................................................................................................................75 B. Le Langage de Dfinition de Donnes de SQL.....................................................................................76

1. Types de donnes.........................................................................................................................................................76 2. Cration de tables........................................................................................................................................................77 3. Contraintes d'intgrit.................................................................................................................................................78 4. Cration de vues..........................................................................................................................................................79 5. Suppression d'objets.....................................................................................................................................................80 6. Modification de tables.................................................................................................................................................80 7. Exemple de modifications de tables.............................................................................................................................81
C. Gestion avec le Langage de Manipulation de Donnes de SQL............................................................82

1. Insertion de donnes....................................................................................................................................................82 2. Mise jour de donnes................................................................................................................................................83 3. Suppression de donnes...............................................................................................................................................83
D. Questions avec le Langage de Manipulation de Donnes de SQL........................................................84

1. Slection.......................................................................................................................................................................84 2. Oprateurs de comparaisons et oprateurs logiques..................................................................................................85 3. Expression du produit cartsien..................................................................................................................................86 4. Expression d'une projection.........................................................................................................................................86 5. Expression d'une restriction........................................................................................................................................86 6. Expression d'une jointure............................................................................................................................................86 7. Oprateurs ensemblistes..............................................................................................................................................87 8. Tri.................................................................................................................................................................................88 9. Fonctions de calcul......................................................................................................................................................88 10. Agrgats.....................................................................................................................................................................89
E. Instructions avances pour le LMD de SQL..........................................................................................90

1. Requtes imbriques....................................................................................................................................................90 2. Sous-requte d'existence IN.........................................................................................................................................91 3. Sous-requte d'existence EXISTS.................................................................................................................................92 4. Sous-requte de comparaison ALL..............................................................................................................................92 5. Sous-requte de comparaison ANY..............................................................................................................................93 6. Raffinement de questions dans la clause FROM.........................................................................................................93
F. Le Langage de Contrle de Donnes de SQL........................................................................................94

1. Attribution de droits.....................................................................................................................................................94 2. Rvocation de droits....................................................................................................................................................95
G. En rsum : SQL....................................................................................................................................95 H. Bibliographie commente sur le SQL....................................................................................................96
V - La thorie de la normalisation relationnelle
97
A. Les dpendances fonctionnelles............................................................................................................97

1. Exercice introductif : Redondance..............................................................................................................................97 2. Les problmes soulevs par une mauvaise modlisation.............................................................................................98 3. Principes de la normalisation......................................................................................................................................99 4. Dpendance fonctionnelle............................................................................................................................................99 5. Les axiomes d'Armstrong...........................................................................................................................................100 6. Autres proprits dduites des axiomes d'Armstrong................................................................................................100 7. DF lmentaire..........................................................................................................................................................101 8. Notion de fermeture transitive des DFE....................................................................................................................101 9. Notion de couverture minimale des DFE...................................................................................................................101 10. Notion de graphe des DFE......................................................................................................................................102 11. Dfinition formelle d'une cl....................................................................................................................................102
B. Les formes normales............................................................................................................................103

1. Principe de la dcomposition.....................................................................................................................................103 2. Formes normales.......................................................................................................................................................103
3. Premire forme normale............................................................................................................................................104 4. Deuxime forme normale...........................................................................................................................................104 5. Troisime forme normale...........................................................................................................................................105 6. Forme normale de Boyce-Codd.................................................................................................................................106
C. Bibliographie commente sur la normalisation...................................................................................107
VI - Le relationnel-objet
109
A. Introduction : R, OO, RO....................................................................................................................109

1. Les atouts du modle relationnel...............................................................................................................................109 2. Les inconvnients du modle relationnel...................................................................................................................109 3. Les SGBDOO.............................................................................................................................................................110 4. Les SGBDRO.............................................................................................................................................................111
B. Le modle relationnel-objet.................................................................................................................111
1. Les SGBDRO.............................................................................................................................................................111 2. Le modle imbriqu...................................................................................................................................................111 3. Les types utilisateurs..................................................................................................................................................112 4. Les collections............................................................................................................................................................113 5. Comparaison relationnel et relationnel-objet...........................................................................................................113 6. Tables d'objets...........................................................................................................................................................114 7. Hritage et rutilisation de types...............................................................................................................................114 8. Identification d'objets et rfrences...........................................................................................................................115
C. Le passage conceptuel vers relationnel-objet......................................................................................116

1. Classe.........................................................................................................................................................................116 2. Attributs.....................................................................................................................................................................116 3. Association 1:N..........................................................................................................................................................117 4. Association N:M.........................................................................................................................................................117 5. Hritage.....................................................................................................................................................................117
D. SQL3 (implmentation Oracle 9i).......................................................................................................117

1. Les nouveaux types de donnes.................................................................................................................................117 2. Les types de donnes abstraits...................................................................................................................................117 3. Mthodes et SELF......................................................................................................................................................118 4. Nested tables..............................................................................................................................................................119 5. Tables d'objets...........................................................................................................................................................119 6. Insertion d'objets........................................................................................................................................................120 7. Insertion de collections partir de requtes SELECT..............................................................................................120 8. Slection dans des objets...........................................................................................................................................121 9. Slection dans des tables imbriques.........................................................................................................................122 10. Manipulation d'OID.................................................................................................................................................123
E. Exemples RO.......................................................................................................................................124
1. Exemple : Gestion de cours.......................................................................................................................................124 2. Exemple : Gestion de cours simplifie (version avec OID).......................................................................................127
F. En rsum : Le relationnel-objet..........................................................................................................129 G. Bibliographie commente sur le relationnel-objet...............................................................................129
VII - La gestion des transactions
131
A. Problmatique des pannes et de la concurrence..................................................................................131 B. Transactions.........................................................................................................................................132

1. Notion de transaction.................................................................................................................................................132 2. Droulement d'une transaction..................................................................................................................................132 3. Proprits ACID d'une transaction...........................................................................................................................132 4. Transactions en SQL..................................................................................................................................................133 5. Exemple de transaction sous Oracle..........................................................................................................................133 6. Exemple de transaction sous Access..........................................................................................................................134 7. Journal des transactions............................................................................................................................................134
C. Fiabilit et transactions........................................................................................................................135
1. Les pannes..................................................................................................................................................................135 2. Point de contrle........................................................................................................................................................135
3. Reprise aprs panne...................................................................................................................................................136 4. Algorithme de reprise UNDO-REDO........................................................................................................................137 5. Ecriture en avant du journal......................................................................................................................................138
D. Concurrence et transactions.................................................................................................................139
1. Trois problmes soulevs par la concurrence...........................................................................................................139 2. Le verrouillage...........................................................................................................................................................141 3. Le dverrouillage.......................................................................................................................................................142 4. Protocole d'accs aux donnes..................................................................................................................................142 5. Solution aux trois problmes soulevs par la concurrence.......................................................................................143 6. Inter-blocage..............................................................................................................................................................144
E. En rsum : Les transactions................................................................................................................145 F. Bibliographie commente sur les transactions.....................................................................................145
VIII - L'optimisation du schma interne
147
A. Introduction l'optimisation des BD...................................................................................................147

1. Schma interne et performances des applications.....................................................................................................147 2. valuation des besoins de performance....................................................................................................................148 3. Indexation..................................................................................................................................................................149 4. Dnormalisation........................................................................................................................................................149 5. Groupement de tables................................................................................................................................................150 6. Partitionnement de table............................................................................................................................................151 7. Vues concrtes...........................................................................................................................................................151
B. En rsum : L'optimisation..................................................................................................................152 C. Bibliographie commente sur l'optimisation.......................................................................................152
IX - Ouvrage de rfrence conseill Questions de synthse Solution des exercices de TD Glossaire Signification des abrviations Bibliographie Index
153 155 173 175 177 179 181
INTRODUCTION
Les BD sont nes vers la fin des annes 1960 pour combler les limites des systmes de fichiers. Les BD relationnelles, issues de la recherche de Codd, sont celles qui ont connu le plus grand essor depuis plus de 20 ans, et qui reste encore aujourd'hui les plus utilises. Le langage SQL est une couche technologique, idalement indpendante des implmentations des SGBDR, qui permet de crer et manipuler des BD relationnelles. Les usages de BD se sont aujourd'hui gnraliss pour entrer dans tous les secteurs de l'entreprise, depuis les "petites" BD utilises par quelques personnes dans un service pour des besoins de gestion de donnes locales, jusqu'aux "grosses" BD qui grent de faon centralise des donnes partages par tous les acteurs de l'entreprise. Paralllement l'accroissement de l'utilisation du numrique comme outil de manipulation de toutes donnes (bureautique, informatique applicative, etc.) et comme outil d'extension des moyens de communication (rseaux) d'une part et les volutions technologiques (puissance des PC, Internet, etc.) d'autre part ont la fois rendu indispensable et complexifi la problmatique des BD. Les consquences de cette gnralisation et de cette diversification des usages se retrouvent dans l'mergence de solutions conceptuelles et technologiques nouvelles et sans cesse renouveles.
I -
PRSENTATION DES BASES DE

BD et SGBD : vue d'ensemble Notions gnrales pour les bases de donnes Les mthodes de conception de bases de donnes En rsum : Conception de bases de donnes
DONNES
I
11 14 19 24
Les BD ont t cres pour faciliter la gestion qualitative et quantitative des donnes informatiques. Les SGBD sont des applications informatiques permettant de crer et de grer des BD (comme Oracle ou MySQL par exemple). Les BD relationnelles sont les plus rpandues et l'on utilise des SGBDR pour les implmenter. Le langage SQL est le langage commun tous les SGBDR, ce qui permet de concevoir des BD relativement indpendamment des systmes utiliss.
A. BD et SGBD : vue d'ensemble

Objectifs
Comprendre l'intrt des BD. Comprendre ce qu'est un SGBD.
1. Qu'est ce qu'une BD ?
Dfinition : Base de donnes
Une BD est un ensemble volumineux, structur et minimalement redondant de donnes, relies entre elles, stockes sur supports numriques centraliss ou distribus, servant pour les besoins d'une ou plusieurs applications, interrogeables et modifiables par un ou plusieurs utilisateurs travaillant potentiellement en parallle.
Exemple : Compagnie arienne

Une BD de gestion de l'activit d'une compagnie arienne concernant les voyageurs, les vols, les avions, le personnel, les rservations, etc. Une telle BD pourrait permettre la gestion des rservations, des disponibilits des avions en fonction des vols effectuer, des affectation des personnels volants, etc.
2. Qu'est ce qu'un SGBD ?

Dfinition : Systme de Gestion de Bases de Donnes
Un SGBD est un logiciel qui prend en charge la structuration, le stockage, la mise jour et la
11
Prsentation des bases de donnes
maintenance d'une base de donnes. Il est l'unique interface entre les informaticiens et les donnes (dfinition des schmas, programmation des applications), ainsi qu'entre les utilisateurs et les donnes (consultation et mise jour).
Exemple : Exemples de SGBD

Oracle est un SGBD relationnel (et Relationnel-Objet dans ses dernires versions) trs reconnu pour les applications professionnelles. MySQL est un SGBD relationnel libre (licence GPL et commerciale), simple d'accs et trs utilis pour la ralisation de sites Web dynamiques. Depuis la version 4 MySQL implmente la plupart des fonctions attendues d'un SGBD relationnel. PosgreSQL est un SGBD relationnel et relationnel-objet trs puissant qui offre une alternative open-source aux solutions commerciales comme Oracle ou IBM. Access est un SGBD relationnel Microsoft, qui offre une interface conviviale permettant de concevoir rapidement des applications de petite envergure ou de raliser des prototypes moindre frais.
3. Pourquoi des SGBD ?

a) Jadis...
Avant l'avnement des SGBD, chaque application informatique dans l'entreprise impliquait sa propre quipe de dveloppement, ses propres supports physiques, ses propres fichiers, ses propres normes, ses propres langages, etc.
b) Consquences...
L'existence conjointe et croissante de ces applications indpendantes a des effets ngatifs, tels que : La multiplication des tches de saisie, de dveloppement et de support informatique La redondance anarchique des informations dans les fichiers L'incohrence des versions simultanes de fichiers La non-portabilit des traitements en raison des diffrences dans les formats et langages. La multiplication des cots de dveloppement et de maintenance des applications.
c) Problmes...
Les consquences prcdemment cites se rpercutent sur l'entreprise en gnrant des problmes humains et matriels. Cots en personnels qualifis et en formations Remise des pouvoirs de dcision entre les mains de spcialistes informatiques Tout changement matriel ou logiciel a un impact sur les applications Tout changement de la structure des donnes ncessite de modifier les programmes
d) Or...
En ralit les applications ne sont jamais totalement disjointes, des donnes similaires (le coeur de l'information d'entreprise) sont toujours la base des traitements. On peut citer typiquement : Les donnes comptables Les donnes clients et fournisseurs Les donnes relatives la gestion des stocks Les donnes relatives aux livraisons Les donnes marketting et commerciales
12
Les donnes relatives au personnel etc.
4. Caractristiques des SGBD

La conception d'un systme d'information pour tre rationnelle l'chelle d'une entreprise se doit d'adopter un certain nombre de principes, tels que : Une description des donnes indpendante des traitements Une maintenance de la cohrence de donnes Le recours des langages non procduraux, interactifs et structurants Dans ce cadre les SGBD se fixent les objectifs suivants : Indpendance physique des donnes Le changement des modalits de stockage de l'information (optimisation, rorganisation, segmentation, etc.) n'implique pas de changements des programmes. Indpendance logique des donnes L'volution de la structure d'une partie des donnes n'influe pas sur l'ensemble des donnes. Manipulation des donnes par des non-informaticiens L'utilisateur n'a pas savoir comment l'information est stocke et calcule par la machine, mais juste pouvoir la rechercher et la mettre jour travers des IHM ou des langages assertionnels simples. Administration facilite des donnes Le SGBD fournit un ensemble d'outils (dictionnaire de donnes, audit, tuning, statistiques, etc.) pour amliorer les performance et optimiser les stockages. Optimisation de l'accs aux donnes Les temps de rponse et de dbits globaux sont optimiss en fonctions des questions poses la BD. Contrle de cohrence (intgrit smantique) des donnes Le SGBD doit assurer tout instant que les donnes respectent les rgles d'intgrit qui leurs sont imposes. Partageabilit des donnes Les donnes sont simultanment consultables et modifiables. Scurit des donnes La confidentialit des donnes est assure par des systmes d'authentification, de droits d'accs, de cryptage des mots de passe, etc. Sret des donnes La persistance des donnes, mme en cas de panne, est assure, grce typiquement des sauvegardes et des journaux qui gardent une trace persistante des oprations effectues.
B. Notions gnrales pour les bases de donnes

Objectifs
Connatre les diffrences entre modle conceptuel, modle logique et implmentation physique. Comprendre l'importance de la modlisation conceptuelle.
13
1. Notion de donnes
Dfinition : Donnes
Elment effectif, rel, correspondant une type de donnes. Synonymes : Occurence, Instance
Exemple : Donnes

L'entier 486 Le vhicule (460HP59, Renault, Megane, Jaune)
Dfinition : Type de donnes

Ensemble d'objets qui possdent des caractristiques similaires et manipulables par des oprations identiques. Synonymes : Classe
Exemple : Type de donnes

Entier = { 0, 1, 2, ... , N } Vhicule = (immatriculation, marque, type, couleur)
2. Notion de modle de donnes

Dfinition : Modle de donnes
Ensemble de concepts et de rgles de composition de ces concepts permettant de dcrire des donnes (cf. Bases de donnes : objet et relationnel [Gardarin99]). Un modle est souvent reprsent au moyen d'un formalisme graphique permettant de dcrire les donnes (ou plus prcisment les types de donnes) et les relations entre les donnes. On distingue trois niveaux de modlisation pour les bases de donnes : Le modle conceptuel Il permet de dcrire le rel selon une approche ontologique, sans prendre en compte les contraintes techniques. Le modle logique Il permet de dcrire une solution, en prenant une orientation informatique gnrale (type de SGBD typiquement), mais indpendamment de choix d'implmentation prcis. Le modle physique Il correspond aux choix techniques, en terme de SGBD choisi et de sa mise en uvre (programmation, optimisation, etc.).
Exemple : Exemple de formalisme de modlisation conceptuelle

Le modle Entit-Association (cf. The entity-Relationsheep Model - Towards a Unified View of Data [Chen76]) a t le plus rpendu dans le cadre de la conception de bases de donnes. Le modle UML, qui se gnralise pour la conception en informatique, se fonde sur une approche objet.
Exemple : Exemple de formalisme de modlisation logique

Le modle relationnel est le modle dominant. Le modle relationnel-objet (adaptation des modles relationnel et objet au cadre des SGBD) est actuellement en pleine croissance. Le modle objet "pur" reste majoritairement au stade exprimental et de la recherche.
14
Des modles plus anciens (hirarchique, rseau, etc.) ne sont plus gure utiliss aujourd'hui.
3. Notion de schma de donnes

Dfinition : Schma de donnes
Description, au moyen d'un langage formel, d'un ensemble de donnes dans le contexte d'une BD. Un schma permet de dcrire la structure d'une base de donnes, en dcrivant l'ensemble des types de donnes de la base. L'occurence d'une base de donnes est constitue de l'ensemble des donnes correspondant aux types du schma de la base.
Exemple : Schma de base de donnes

Etudiant (NumEtud, nom, ville) Module(NumMod, titre) Inscription(NumEtud, NumMod, date)
Exemple : Instance de base de donnes

Etudiant (172, 'Dupont', 'Lille') Etudiant (173, 'Durand', 'Paris') Etudiant (174, 'Martin', 'Orlans') Module(1, 'SGBD') Module(1, 'Systmes d'exploitation') Inscription(172, 1, 2002) Inscription(172, 2, 2002) Inscription(173, 1, 2001) Inscription(174, 2, 2002) On distingue trois niveaux d'abstraction de schmas : Le niveau conceptuel Il permet de dcrire les entits et les associations du monde rel. Il s'agit du schma global de la base de donnes, il en propose une vue canonique. Le niveau conceptuel correspond au modle conceptuel. Le niveau externe Il permet de dcrire les entits et les associations du monde rel, mais vues d'un utilisateur ou d'un groupe d'utilisateurs particuliers (on parle d'ailleurs galement de "vue" pour un shma externe). Il s'agit d'une restriction du schma conceptuel oriente vers un usage prcis. Il existe gnralement plusieurs schmas externes pour un mme schma conceptuel. Le niveau externe correspond un sous ensemble du modle conceptuel restreint aux points de vue de certains utilisateurs. Le niveau interne Il correspond l'implmentation physique des entits et associations dans les fichiers de la base. Le niveau interne correspond aux modles logiques et physiques.
Remarque : ANSI/X3/SPARC
Les trois niveaux, conceptuel, externe et interne, sont les trois niveaux distingus par le groupe de normalisation ANSI/X3/SPARC en 1975.
15
Les trois niveaux de schma selon ANSI/X3/SPARC
4. Notion de langage de donnes

Dfinition : Langage de donnes
Langage informatique permettant de dcrire et de manipuler les schmas d'une BD d'une une manire assimilable par la machine. Synonymes : Langage orient donnes
Exemple : SQL
SQL est le langage orient donnes consacr aux SGBD relationnels et relationnels-objet. Un langage de donnes peut tre dcompos en trois sous langages : Le Langage de Dfinition de Donnes Le LDD permet d'implmenter le schma conceptuel (notion de table en SQL) et les schmas externes (notion de vue en SQL). Le Langage de Contrle de Donnes Le LCD permet d'implmenter les droits que les utilisateurs ont sur les donnes et participe donc la dfinition des schmas externes. Le Langage de Manipulation de Donnes Le LMD permet l'interrogation et la mise jour des donnes. C'est la partie du langage
16
indispensable pour exploiter la BD et raliser les applications.
Exemple : Dfinition de donnes en SQL

CREATE TABLE Etudiant ( NumEtu : integer, Nom : string, Ville : string) Cette instruction permet de crer une relation "Etudiant" comportant les proprits "NumEtu", "Nom" et "Ville".
Exemple : Contrle de donnes en SQL

GRANT ALL PRIVILEGES ON Etudiant FOR 'Utilisateur' Cette instruction permet de donner tous les droits l'utilisateur "Utilisateur" sur la relation "Etudiant".
Exemple : Manipulation de donnes en SQL

SELECT Nom FROM Etudiant WHERE Ville = 'Compigne' Cette instruction permet de rechercher les noms de tous les tudiants habitant la ville de Compigne.
5. Notion d'administration de donnes

Dfinition : Administrateur
Personne ou groupe de personnes responsables de la dfinition des diffrents niveaux de schma. On distingue un type d'administrateur par niveau de schma : L'administrateur entreprise est en charge de la gestion du schma conceptuel et des rgles de contrle des donnes. L'administrateur de donnes est en charge de la gestion des schmas externes et de leur correspondance avec le schma conceptuel. L'administrateur base de donnes est en charge de la gestion du schma interne et de sa correspondance avec le schma conceptuel.
Dfinition : Dictionnaire des donnes

Le dictionnaire de donnes d'un SGBD contient les informations relatives aux schmas et aux droits de toutes les bases de donnes existantes au sein de ce SGBD. Il s'agit d'un outil fondamental pour les administrateurs. Les dictionnaires de donnes sont gnralement implments sous la forme d'une base de donnes particulire du SGBD, ce qui permet de grer les donnes relatives aux bases de donnes de la mme faon que les autres donnes de l'entreprise (i.e. dans une base de donnes). Synonymes : Catalogue des donnes, Mtabase
C. Les mthodes de conception de bases de donnes

Objectifs
Connatre la mthodologie de conception d'une BD.
17
1. Mthodologie de conception d'une base de donnes

Mthode : tapes de la conception d'une base de donnes
1. Analyse de la situation existante et des besoins 2. Cration d'une srie de modles conceptuels (canonique et vues externes) qui permettent de reprsenter tous les aspects importants du problme 3. Traduction des modles conceptuels en modle logique et optimisation (normalisation) de ce modle logique 4. Implmentation d'une base de donnes dans un SGBD, partir du modle logique
Processus de conception d'une base de donnes
Conseil : L'importance de l'tape d'analyse

La premire tape de la conception repose sur l'analyse de l'existant et des besoins. De la qualit de la ralisation de cette premire tape dpendra ensuite la pertinence de la base de donnes par rapports aux usages. Cette premire tape est donc essentielle et doit tre mene avec soins. Si la premire tape est fondamentale dans le processus de conception, elle est aussi la plus dlicate. En effet, tandis que des formalismes puissants existent pour la modlisation conceptuelle puis pour la modlisation logique, la perception de l'existant et des besoins reste une tape qui repose essentiellement sur l'expertise d'analyse de l'ingnieur.
Conseil : L'importance de l'tape de modlisation conceptuelle

Etant donne une analyse des besoins correctement ralise, la seconde tape consiste la traduire selon un modle conceptuel. Le modle conceptuel tant formel, il va permettre de passer d'une spcification en langage naturel, et donc soumise interprtation, une spcification non ambige. Le recours aux formalismes de modlisation tels que E-A ou UML est donc une aide fondamentale pour parvenir une reprsentation qui ne sera plus lie l'interprtation du lecteur. La traduction d'un cahier des charges spcifiant l'existant et les besoins en modle conceptuel reste nanmoins une tape dlicate, qui va conditionner ensuite l'ensemble de l'implmentation informatique. En effet les tape suivantes sont plus mcaniques, dans la mesure o un modle logique est dduit de faon systmatique du modle conceptuel et que l'implmentation logicielle est galement ralise par traduction directe du modle logique.
Remarque : Les tapes de traduction logique et d'implmentation

Des logiciels spcialiss (Sybase PowerDesigner [w_sybase] pour la modlisation E-A ou Objecteering software [w_objecteering] pour la modlisation UML) sont capables partir d'un modle
18
conceptuel d'appliquer des algorithmes de traduction qui permettent d'obtenir directement le modle logique, puis les instructions pour la cration de la base de donnes dans un langage orient donnes tel que SQL. L'existence de tels algorithmes de traduction montre que les tapes de traduction logique et d'implmentation sont moins complexes que les prcdentes, car plus systmatiques. Nanmoins ces tapes exigent tout de mme des comptences techniques pour optimiser les modles logiques (normalisation), puis les implmentations en fonction d'un contexte de mise en oeuvre matriel, logiciel et humain.
2. La mthode MERISE et le modle E-A

MERISE est une mthode d'analyse informatique particulirement adapte la conception de bases de donnes.
L'analyse selon MERISE La mthode MERISE a pour fondement le modle E-A, qui a fait son succs. Les principales caractristiques du modle E-A sont : Une reprsentation graphique simple et naturelle Une puissance d'expression leve pour un nombre de symboles raisonnables Une lecture accessible tous et donc un bon outil de dialogue entre les acteurs techniques et non techniques Une formalisation non ambige et donc un bon outil de spcification dtaille
3. Le langage de modlisation UML

UML est un autre langage de modlisation, plus rcent et couvrant un spectre plus large que les bases de donnes. En tant que standard de l'OMG et en tant que outil trs utilis pour la programmation oriente objet, il est amen supplanter petit petit la modlisation E-A.
4. lments pour l'analyse de l'existant et des besoins
19
La phase d'analyse de l'existant et des besoins est une phase essentielle et complexe. Elle doit aboutir des spcifications gnrales qui dcrivent en langage naturel les donnes manipules, et les traitements effectuer sur ces donnes. On se propose de donner une liste non exhaustive d'actions mener pour rdiger de telles spcifications.
Mthode : L'analyse de documents existants

La conception d'une base de donnes s'inscrit gnralement au sein d'usages existants. Ces usages sont gnralement, au moins en partie, instruments travers des documents lectroniques ou non (papier typiquement). Il est fondamental d'analyser ces documents et de recenser les donnes qu'ils manipulent.
Exemple : Exemples de document existants

Fichiers papiers de stockage des donnes (personnel, produits, etc.) Formulaires papiers d'enregistrement des donnes (fiche d'identification d'un salari, fiche de description d'un produit, bon de commande, etc.) Documents lectroniques de type traitement de texte (lettres, mailing, procdures, etc.) Documents lectroniques de type tableurs (bilans, statistiques, calculs, etc.) Bases de donnes existantes, remplacer ou avec lesquelles s'accorder (gestion des salaires, de la production, etc.) Intranet d'entreprise (information, tlchargement de documents, etc.) etc.
Mthode : Le recueil d'expertise mtier

Les donnes que la base va devoir manipuler sont toujours relatives aux mtiers de l'entreprise, et il existe des experts qui pratiquent ces mtiers. Le dialogue avec ces experts est une source importante d'informations. Il permet galement de fixer la terminologie du domaine.
Exemple : Exemples d'experts consulter

Praticiens (secrtaires, ouvrier, contrleurs, etc.) Cadres (responsables de service, contre-matres, etc.) Experts externes (clients, fournisseurs, etc.) etc.
Mthode : Le dialogue avec les usagers

La base de donnes concerne des utilisateurs cibles, c'est dire ceux qui produiront et consommeront effectivement les donnes de la base. Il est ncessaire de dialoguer avec ces utilisateurs, qui sont les dtenteurs des connaissances relatives aux besoins rels, lis leur ralit actuelle (aspects de l'organisation fonctionnant correctement ou dfaillants) et la ralit souhaite (volutions, lacunes, etc.).
Exemple : Exemples d'utilisateurs

Personnes qui vont effectuer les saisies d'information ( partir de quelles sources ? Quelle est leur responsabilit ? etc.) Personnes qui vont consulter les informations saisies (pour quel usage ? pour quel destinataire ? etc.) Personnes qui vont mettre jour les informations (pour quelles raisons ? comment le processus est enclench ? etc.) etc.
Mthode : L'tude des autres systmes informatiques existants

la base de donnes va gnralement (et en fait quasi systmatiquement aujourd'hui) s'insrer parmi un ensemble d'autres logiciels informatiques travaillant sur les donnes de l'entreprise. Il est important
20
d'analyser ces systmes, afin de mieux comprendre les mcanismes existants, leurs forces et leurs lacunes, et de prparer l'intgration de la base avec ces autres systmes. Une partie de ces systmes seront d'ailleurs souvent galement des utilisateurs de la base de donnes, tandis que la base de donnes sera elle mme utilisatrice d'autre systmes.
Exemple : Exemples d'autres systmes coexistants
Autres bases de donnes (les donnes sont elle disjointes ou partiellement communes avec celles de la base concevoir ? quelles sont les technologies logicielles sur lesquelles reposent ces BD ? etc.) Systmes de fichiers classiques (certains fichiers ont-ils vocations tre supplants par la base ? tre gnrs par la base ? alimenter la base ? etc.) Applications (ces applications ont elles besoins de donnes de la base ? peuvent-elles lui en fournir ? etc.) etc.
5. Le MCD
Dfinition : MCD
Le MCD est l'lment le plus connu de MERISE et certainement le plus utile. Il permet d'tablir une reprsentation claire des donnes du SI et dfinit les dpendances des donnes entre elles.
Exemple
Le modle E-A est un formalisme de MCD, le diagramme de classe UML en est un autre.
Remarque
Un MCD est indpendant de l'tat de l'art technologique. A ce titre il peut donc tre mis en oeuvre dans n'importe quel environnement logiciel et matriel, et il devra tre traduit pour mener une implmentation effective.
6. Le MLD
Introduction
On ne sait pas implmenter directement un modle conceptuel de donnes dans une machine et il existe diffrentes sortes de SGBD qui ont chacun leur propre modle : SGF (qui ne sont pas vraiment des SGBD), SGBD hirarchiques (organiss selon une arborescence), SGBD rseau (encore appels CODASYL), SGBDR, SGBDOO, SGBDRO, etc.
Dfinition : MLD
Un MLD est une reprsentation du systme tel qu'il sera implment dans un ordinateur.
Exemple
Le modle relationnel est un formalisme de MLD.
Remarque
Il ne faut pas confondre le MLD (relationnel par exemple) avec le MCD (E-A par exemple). Il ne faut pas confondre le MLD avec son implmentation logicielle en machine (avec Oracle par exemple)
21
D. En rsum : Conception de bases de donnes

Conception
Modle Conceptuel Schma conceptuel canonique et schmas externes Exemples E-A UML Modle Logique Schma interne indpendant d'un SGBD Exemples Relationnel Objet Relationnel-Objet Rseau Hirarchique Modle Physique Schma interne pour un SGBD particulier Exemples Oracle MySQL PostgreSQL DB2 Access SQLServer
* * *
Les SGBD assurent la gestion efficace et structure des donnes partages. Leur conception repose sur une approche trois niveaux : conceptuel et externe, logique, physique.
22
II -
LE NIVEAU CONCEPTUEL : LA
Bases du diagramme de classes UML Diagramme de classes UML avanc Le modle E-A En rsum : Schma conceptuel Bibliographie commente sur la modlisation UML
MODLISATION DES BASES DE DONNES
II
27 36 46 52 52
La modlisation est l'tape fondatrice du processus de conception de BD. Elle consiste abstraire le problme rel pos pour en faire une reformulation qui trouvera une solution dans le cadre technologique d'un SGBD. Aprs avoir rappel succinctement les fondements et objectifs des SGBD, ce chapitre proposera les outils mthodologiques ncessaires la modlisation, travers les formalismes E-A et UML.
A. Bases du diagramme de classes UML

Objectifs
Savoir-faire un modle conceptuel. Savoir interprter un modle conceptuel.
Si le modle dominant en conception de bases de donnes a longtemps t le modle E-A, le modle UML se gnralise de plus en plus. Nous ne donnons ici qu'une introduction au diagramme de classes (parmi l'ensemble des outils d'UML), limit aux aspects particulirement utiliss en modlisation de bases de donnes.
1. Prsentation d'UML
UML est un langage de reprsentation destin en particulier la modlisation objet. UML est devenu une norme OMG en 1997. UML propose un formalisme qui impose de "penser objet" et permet de rester indpendant d'un langage de programmation donn. Pour ce faire, UML normalise les concepts de l'objet (numration et dfinition exhaustive des concepts) ainsi que leur notation graphique. Il peut donc tre utilis comme un moyen de communication entre les tapes de spcification conceptuelle et les tapes de spcifications techniques. Dans le domaine des bases de donnes, UML peut tre utilis la place du modle E-A pour modliser le domaine. De la mme faon, un schma conceptuel UML peut alors tre traduit en schma logique
23
Le niveau conceptuel : la modlisation des bases de donnes
(relationnel ou relationnel-objet typiquement).
2. Classes
Dfinition : Classe
Une classe est un type abstrait caractris par des proprits (attributs et mthodes) communes un ensemble d'objets et permettant de crer des instances de ces objets, ayant ces proprits.
Syntaxe
Reprsentation UML d'une classe
Exemple : La classe Voiture
Exemple de classe reprsente en UML
Exemple : Une instance de la classe Voiture

L'objet V1 est une instance de la classe Voiture. V1 : Voiture Marque : 'Citron' Type : 'ZX' Portes : 5 Puissance : 6 Kilomtrage : 300000
Remarque : Cl
Le reprage des cls n'est pas systmatique en UML (la dfinition des cls se fera alors au niveau logique). On conseillera nanmoins de les reprsenter (en les soulignant dans le dessin). On vitera par contre d'ajouter des cls artificielles lorsqu'aucune cl n'est vidente.
Remarque
La modlisation sous forme de diagramme de classes est une modlisation statique, qui met en exergue la structure d'un modle, mais ne rend pas compte de son volution temporelle. UML propose d'autres types de diagrammes pour traiter, notamment, de ces aspects.
3. Attributs
24
Dfinition : Attribut
Un attribut est une information lmentaire qui caractrise une classe et dont la valeur dpend de l'objet instanci.
Remarque

Un attribut est typ : Le domaine des valeurs que peut prendre l'attribut est fix a priori. Un attribut peut tre multivalu : Il peut prendre plusieurs valeurs distinctes dans son domaine. Un attribut peut tre driv : Sa valeur alors est une fonction sur d'autres attributs de la classe (il peut donc aussi tre reprsent comme une mthode, et c'est en gnral prfrable). Un attribut peut tre compos : Il joue alors le rle d'un groupe d'attributs (par exemple une adresse peut tre un attribut compos des attributs numro, type de voie, nom de la voie). Cette notion renvoie la notion de variable de type Record dans les langages de programmation classiques.
Syntaxe
attribut:type attribut_multivalu[nbMinValeurs..nbMaxValeurs]:type /attribut_driv:type attribut_compos - sous-attribut1:type - sous-attribut2:type - ...
Exemple : La classe Personne
Reprsentation d'attributs en UML Dans cet exemple, les attributs Nom, Prnom sont de type string, l'un de 20 caractres et l'autre de 10, tandis que DateNaissance est de type date et Age de type integer. Prnom est un attribut multivalu, ici une personne peut avoir de 1 3 prnoms. Age est un attribut driv, il peut tre calcul par une fonction sur DateNaissance.
4. Mthodes
Dfinition : Mthode
Une mthode (ou opration) est une fonction associe une classe d'objet qui permet d'agir sur les objets de la classe ou qui permet ces objets de renvoyer des valeurs (calcules en fonction de paramtres).
25
Syntaxe
methode(paramtres):type
Remarque : Mthodes et modlisation de BD

Pour la modlisation des bases de donnes, les mthodes sont surtout utilises pour reprsenter des donnes calcules ( l'instar des attributs drives) ou pour mettre en exergue des fonctions importantes du systme cible. Seules les mthodes les plus importantes sont reprsentes, l'approche est moins systmatique qu'en modlisation objet par exemple.
Remarque : Mthodes, relationnel, relationnel-objet

Lors de la transformation du modle conceptuel UML en modle logique relationnel, les mthodes ne seront pas implmentes. Leur reprage au niveau conceptuel sert donc surtout d'aide-mmoire pour l'implmentation au niveau applicatif. Au contraire, un modle logique relationnel-objet permettra l'implmentation de mthodes associes des tables. Leur reprage au niveau conceptuel est donc encore plus important.
5. Associations
Dfinition : Association
Une association est une relation logique entre deux classes (association binaire) ou plus (association naire) qui dfinit un ensemble de liens entre les objets de ces classes. Une association est nomme, gnralement par un verbe. Une association peut avoir des proprits ( l'instar d'une classe). Une association dfinit le nombre minimum et maximum d'instances autorise dans la relation (on parle de cardinalit).
Syntaxe
Notation de l'association en UML
Remarque
Une association est gnralement bidirectionnelle (c'est dire qu'elle peut se lire dans les deux sens). Les associations qui ne respectent pas cette proprit sont dites unidirectionnelles ou navigation restreinte.
Exemple : L'association Conduit
Reprsentation d'association en UML L'association Conduit entre les classes Conducteur et Voiture exprime que les conducteurs conduisent des voitures.
26
6. Cardinalit
Dfinition : Cardinalit d'une association
La cardinalit d'une association permet de reprsenter le nombre minimum et maximum d'instances qui sont autorises participer la relation. La cardinalit est dfinie pour les deux sens de la relation.
Syntaxe
Si mina (resp. maxa) est le nombre minimum (resp. maximum) d'instances de la classe A autorises participer l'association, on note sur la relation, ct de la classe A : mina..maxa. Si le nombre maximum est indtermin, on note n ou *.
Attention
La notation de la cardinalit en UML est oppose celle adopt en E-A. En UML on note gauche (resp. droite) le nombre d'instances de la classe de gauche (resp. de droite) autorises dans l'association. En EA, on note gauche (resp. droite) le nombre d'instances de la classe de droite (resp. de gauche) autorises dans l'association.
Remarque
Les cardinalit les plus courantes sont : 0..1 (optionnel) 1..1 ou 1 (un) 0..n ou 0..* ou * (plusieurs) 1..n ou 1..* (obligatoire)
Exemple : La cardinalit de l'association Possde
Reprsentation de cardinalit en UML Ici un conducteur peut possder plusieurs voitures (y compris aucune) et une voiture n'est possde que par un seul conducteur.
7. Hritage
Dfinition : Hritage
L'hritage est l'association entre deux classes permettant d'exprimer que l'une est plus gnrale que l'autre. L'hritage implique une transmission automatique des proprits (attributs et mthodes) d'une classe A une classe A'. Dire que A' hrite de A quivaut dire que A' est une sous-classe de A. On peut galement dire que A est une gnralisation de A' et que A' est une spcialisation de A.
Syntaxe
27
Notation de l'hritage en UML
Remarque
L'hritage permet de reprsenter la relation "est-un" entre deux objets.
Remarque
Outre qu'il permet de reprsenter une relation courante dans le monde rel, l'hritage a un avantage pratique, celui de factoriser la dfinition de proprits identiques pour des classes proches.
Exemple : La classe Conducteur
Reprsentation d'hritage en UML Dans cet exemple la classe Conducteur hrite de la classe Personne, ce qui signifie qu'un objet de la classe conducteur aura les attributs de la classe Conducteur (TypePermis et DatePermis) mais aussi ceux de la classe Personne (Nom, Prnom, DateNaissance et Age). Si la classe Personne avait des mthodes, la classe Conducteur en hriterait de la mme faon.
8. Exemple : Des voitures et des conducteurs

Exemple
28
Exemple trs simple de diagramme de classes Les relations de ce diagramme expriment que les conducteurs sont des personnes qui ont un permis ; que toute voiture est possde par une unique personne (qui peut en possder plusieurs) ; que les voitures peuvent tre conduites par des conducteurs et que les conducteurs peuvent conduire plusieurs voitures.
Remarque
Les mots cls in, out et in/out devant un paramtre de mthode permettent de spcifier si le paramtre est une donne d'entre, de sortie, ou bien les deux.
Remarque
Le but d'une modlisation UML n'est pas de reprsenter la ralit dans l'absolu, mais plutt de proposer une vision d'une situation rduite aux lments ncessaires pour rpondre au problme pos. Donc une modlisation s'inscrit toujours dans un contexte, et en cela l'exemple prcdent reste limit car son contexte d'application est indfini.
B. Diagramme de classes UML avanc

Objectifs
Matriser le diagramme de classe UML dans le cas de la conception de BD.
Les lments de modlisation suivant compltent les notations basiques du diagramme de classe : classe, attribut, association, cardinalit et hritage.
1. Explicitation des associations

Syntaxe : Sens de lecture
Il est possible d'ajouter le sens de lecture du verbe caractrisant l'association sur un diagramme de classe UML, afin d'en faciliter la lecture. On ajoute pour cela une flche sur l'association
29
Syntaxe : Rle
Il est possible de prciser le rle jou par une ou plusieurs des classes composant une association afin d'en faciliter la comprhension. On ajoute pour cela ce rle ct de la classe concerne (parfois prcd d'un "+" ou bien dans un petit encadr coll au trait de l'association.
Exemple
Rle et sens de lecture sur une association
Remarque : Associations rflexives

L'explicitation des associations est particulirement utile dans le cas des associations rflexives.
2. Classe d'association
Dfinition : Classe d'association
On utilise la notation des classes d'association lorsque l'on souhaite ajouter des proprits une association.
Syntaxe : Notation d'une classe d'association en UML
Notation d'une classe d'association en UML
Exemple : Exemple de classe d'association
30
Emplois
3. Associations ternaires
Syntaxe
Notation d'une association ternaire
Conseil : Ne pas abuser des associations ternaires

Il est toujours possible de rcrire une association ternaire avec trois associations binaires, en transformant l'association en classe.
Conseil : Pas de degr suprieur 4

En pratique on n'utilise jamais en UML d'association de degr suprieur 3.
4. Composition
Dfinition : Association de composition
On appelle composition une association particulire qui possde les proprits suivantes :
31
La composition associe une classe composite et des classes parties, tel que tout objet partie appartient un et un seul objet composite. C'est donc une association 1:N. La composition n'est pas partageable, donc un objet partie ne peut appartenir qu' un seul objet composite la fois. Le cycle de vie des objets parties est li celui de l'objet composite, donc un objet partie disparat quand l'objet composite auquel il est associ disparait.
Remarque
La composition est une association particulire.
Syntaxe : Notation d'une composition en UML
Notation d'une composition en UML
Attention : Composition et cardinalit

La cardinalit ct composite est toujours de exactement 1. Ct partie la cardinalit est libre, elle peut tre 0..1, 1, * ou bien 1..*.
Exemple : Exemple de composition
Un livre On voit bien ici qu'un chapitre n'a de sens que faisant partie d'un livre, qu'il ne peut exister dans deux livres diffrents et que si le livre n'existe plus, les chapitres le composant non plus.
Remarque : Composition et entits faibles

La composition permet d'exprimer une association analogue celle qui relie une entit faible une entit identifiante en modlisation E-A. L'entit de type faible correspond un objet partie et l'entit identifiante un objet composite.
5. Classes abstraites
32
Dfinition : Classe abstraite

Une classe abstraite est une classe non instanciable. Elle exprime donc une gnralisation abstraite, qui ne correspond aucun objet existant du monde.
Attention : Classe abstraite et hritage

Une classe abstraite est toujours hrite. En effet sa fonction tant de gnraliser, elle n'a de sens que si des classes en hritent. Une classe abstraite peut tre hrite par d'autres classes abstraites, mais en fin de chane des classes non abstraites doivent tre prsentes pour que la gnralisation ait un sens.
Syntaxe : Notation d'une classe abstraite en UML

On note les classes abstraites en italique.
Notation d'une classe abstraite en UML
Exemple : Exemple de classe abstraite
Des chiens et des hommes Dans la reprsentation prcdente on a pos que les hommes, les femmes et les chiens taient des objets instanciables, gnraliss respectivement par les classes mammifre et humain, et mammifre. Selon cette reprsentation, il ne peut donc exister de mammifres qui ne soient ni des hommes, ni des femmes ni des chiens, ni d'humains qui ne soient ni des hommes ni des femmes.
33
6. Contraintes
Ajout de contraintes dynamiques sur le diagramme de classe
Il est possible en UML d'exprimer des contraintes dynamiques sur le diagramme de classe, par annotation de ce dernier.
Syntaxe : Notation de contraintes
Notation contraintes en UML
Exemple : Exemple de contraintes
Commandes
34
Mthode : Expressions formelles ou texte libre ?

Il est possible d'exprimer les contraintes en texte libre ou bien en utilisant des expressions formelles. On privilgiera la solution qui offre le meilleur compromis entre facilit d'interprtation et non ambigut. La combinaison des deux est galement possible si ncessaire.
Mthode : Quelles contraintes exprimer ?

En pratique il existe souvent de trs nombreuses contraintes, dont certaines sont videntes, ou encore secondaires. Or l'expression de toutes ces contraintes sur un diagramme UML conduirait diminuer considrablement la lisibilit du schma sans apporter d'information ncessaire la comprhension. En consquence on ne reprsentera sur le diagramme que les contraintes les plus essentielles. Notons que lors de l'implmentation toutes les contraintes devront bien entendu tre exprimes. Si l'on souhaite prparer ce travail, il est conseill, lors de la modlisation logique, de recenser de faon exhaustive dans un tableau toutes les contraintes implmenter.
7. Contraintes sur les associations

Concernant les associations, il existe une liste de contraintes exprimes de faon standard.
Syntaxe
Notation des contraintes sur les associations
Dfinition : Inclusion
Si l'association inclue est instancie, l'autre doit l'tre aussi (la contrainte d'inclusion a un sens, reprsent par une flche).
Syntaxe
{IN}, galement note {Subset} ou {I}.
Dfinition : Et (galit, simultanit)

Si une association est instancie, l'autre doit l'tre aussi (quivalent une double inclusion).
Syntaxe
{AND}, galement note {=} ou {S} pour simultanit.
Dfinition : Exclusion
Les deux associations ne peuvent tre instancis en mme temps.
Syntaxe
{X}
35
Dfinition : Ou inclusif (couverture, totalit)

Au moins une des deux relations doit tre instancie.
Syntaxe
{OR}, galement not {T} pour totalit.
Dfinition : Ou exclusif (partition)

Une exactement des deux relations doit tre instancie.
Syntaxe
{XOR}, galement note {+} ou {XT} ou {Partition}.
8. Paquetages
Dfinition : Package
Les paquetages (plus communment appels package) sont des lments servant organiser un modle. Ils sont particulirement utile ds que le modle comporte de nombreuses classes et que celles-ci peuvent tre tries selon plusieurs aspects structurants.
Syntaxe
Syntaxe des paquetages
Exemple
Exemple d'utilisation des packages
Mthode
On reprsente chaque classe au sein d'un package. Il est alors possible de faire une prsentation globale du modle (tous les packages), partielle (1 package) ou centre sur un package : l'on reprsente alors le
36
package avec ses classes, ainsi que toutes les classes lies des autres packages.
Prsentation partielle du modle centre sur un package
C. Le modle E-A
Objectifs
Savoir-faire un modle E-A tendu. Savoir interprter un modle E-A tendu.
1. Le modle E-A en bref

Le modle E-A (ou E-R en anglais) permet la modlisation conceptuelle de donnes. Il correspond au niveau conceptuel de la mthode MERISE (mthode d'analyse informatique), le MCD (cf. Mthode MERISE Tome 1 : Principes et outils [Tardieu83], Mthode MERISE Tome 2 : Dmarche et pratiques [Tardieu85]). La conception E-A est issue des travaux de Chen [Chen76] et se fonde sur deux concepts principaux et un troisime sous-jacent : l'entit, l'association et l'attribut ou proprit.
2. Entit
Dfinition : Entit
Une entit est un objet du monde rel avec une existence indpendante. Une entit (ou type dentit) est une chose (concrte ou abstraite) qui existe et est distinguable des autres entits. L'occurrence dune entit est un lment particulier correspondant lentit et associ un lment du rel. Chaque entit a des proprits (ou attributs) qui la dcrivent. Chaque attribut est associ un domaine de valeur. Une occurence a des valeurs pour chacun de ses attributs, dans le domaine correspondant.
Syntaxe
Notation MERISE de l'entit
37
Notation Chen de l'entit
38
Remarque

Un attribut est atomique, c'est dire qu'il ne peut prendre qu'une seule valeur pour une occurence. Un attribut est lmentaire, c'est dire qu'il ne peut tre exprim par (ou driv) d'autres attributs. Un attribut qui identifie de faon unique une occurence est appel attribut cl.
3. Association
Dfinition : Association
Une association (ou type dassociation) reprsente un lien quelconque entre diffrentes entits. Une occurrence dune association est un lment particulier de lassociation constitu dune et une seule occurrence des objets participants lassociation. On peut dfinir des attributs sur les associations. Le degr d'une association est le nombre d'entits y participant (on parlera notamment d'association binaire lorsque deux entits sont concernes).
Syntaxe
Notation MERISE de l'association
Notation Chen de l'association
Remarque
On peut avoir plusieurs associations diffrentes dfinies sur les mmes entits.
4. Cardinalit d'une association

Dfinition : Cardinalit d'une association binaire
Pour les associations binaires la cardinalit minimale (resp. maximale) d'une association est le nombre minimum (resp. maximum) d'occurrences de l'entit d'arrive associes une occurrence de l'entit de dpart.
Syntaxe
39
Notation de la cardinalit
Exemple
Livre-Auteur Le diagramme E-A prcdent exprime qu'un auteur peut avoir crit plusieurs livres (mais au moins un), et que tout livre ne peut avoir t crit que par un et un seul auteur.
Remarque : Trois grands types de cardinalit

Il existe trois grands types de cardinalit : Les associations 1:N (qui incluent les association 0,1:N) Les associations N:M Les associations 1:1 (qui incluent les association 0,1:1) Les autres associations peuvent toujours tre ramenes des associations N:M (dans le cas gnral) ou plusieurs associations 1:N (cas des associations 2:N ou 3:N par exemple).
5. Modle E-A tendu

Introduction
On peut tendre le modle E-A "classique" de faon accroitre son pouvoir de reprsentation. Cette extension du modle E-A permet de favoriser la dimension conceptuelle et de s'approcher des reprsentations objet, telles que UML.
a) Attributs composites
Un attribut peut tre compos hirarchiquement de plusieurs autres attributs.
Exemple
Un attribut Adresse est compos des attributs Numro, Rue, No_Appartement, Ville, Code_Postal, Pays.
Remarque
Le domaine d'un attribut composite n'est donc plus un domaine simple (entier, caractres, etc.).
b) Attributs multivalus
Tout attribut peut tre monovalu ou multivalu.
Exemple
Les ges des enfants dun employ.
Remarque
Un attribut multivalu n'est donc plus atomique.
40
c) Attributs driv
La valeur d'un attribut peut tre drive d'une ou plusieurs autres valeurs d'attributs.
Exemple
L'ge d'une personne peut tre driv de la date du jour et de celle de sa naissance.
Remarque
Un attribut driv n'est donc plus lmentaire.
d) Sous-type d'entit
Une entit peut-tre dfinie comme sous-type d'une entit plus gnrale.
Exemple
Les entits Cadre et Technicien sont des sous-types de l'entit Employ.
Remarque
La notion de sous-type est quivalente la notion d'hritage en modlisation objet.
6. Entit de type faible

Certaines entits dites "faibles" n'existent qu'en rfrence d'autres entits dites "identifiantes". L'entit identifiante est appel "identifiant tranger" et l'association qui les unit "association identifiante".
Dfinition : Entit de type faible

Une entit de type faible, galement appele entit non identifie, possde une cl locale (appele identifiant relatif) qui permet d'identifier une de ses occurrences parmi l'ensemble des occurrences associes une occurrence de l'entit identifiante. La cl complte d'une entit faible est la concatnation de la cl de l'entit identifiante et de sa cl locale.
Exemple
Association identifiante L'entit Tche est compltement dpendante de l'entit Projet et sa cl locale (No_tche) n'est pas suffisante l'identifier de faon absolue.
Attention
Le reprage des entits de type faible est trs important dans le processus de modlisation, il permet de rflchir la meilleure faon d'identifier de faon unique les entits et donc de trouver les meilleures cls. Notons de plus que le reprage d'entits faibles aura une influence importante sur le modle relationnel rsultant.
7. Illustration d'entits faibles

Exemple
41
Villes Dans le schma ci-avant, on remarque que l'entit "ville" est faible par rapport l'entit "dpartement", qui est faible par rapport "rgion", qui est faible par rapport "pays". Cela signifie que la cl de ville, son nom, est une cl locale et donc que l'on considre qu'il ne peut pas y avoir deux villes diffrentes avec le mme nom, dans un mme dpartement. Il est par contre possible de rencontrer deux villes diffrentes avec le mme nom, dans deux dpartements diffrents. De la mme faon chaque dpartement possde un nom qui l'identifie de faon unique dans une rgion, et chaque rgion possde un nom qui l'identifie de faon unique dans un pays. Si les entits n'taient pas faibles, l'unicit d'un nom de ville serait valable pour l'ensemble du modle, et donc, concrtement, cela signifierai qu'il ne peut exister deux villes avec le mme nom au monde (ni deux dpartements, ni deux rgions).
Remarque
Notons pour terminer que, puisque "pays" n'est pas une entit faible, sa cl "nom" est bien unique pour l'ensemble du modle, et donc cela signifie qu'il ne peut exister deux pays avec le mme nom au monde.
D. En rsum : Schma conceptuel

Schma conceptuel
Un schma conceptuel peut tre reprsent sous forme de modle E-A ou sous forme de diagramme de classe UML. Entit ou Classe Proprit ou Attribut Typ Multi-valu Compos Driv Mthode Paramtres Valeur de retour Association Association Verbe Cardinalit Hritage Hritage d'attributs Hritage de mthodes Composition (ou entit faible) Cardinalit
42
E. Bibliographie commente sur la modlisation UML

Complment : Outils de modlisation UML
Il existe de nombreux outils de modlisation UML. On pourra citer : Dia [w_dia] : logiciel Open Source et multi-plateformes facile d'usage (qui marche nanmoins 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).
Complment : Modlisation UML

UML2 en action [Roques04] Pour un aperu plus dtaill des possibilits d'expression du diagramme de classe UML, lire le chapitre 7 : Dveloppement du modle statique (pages 133 163). On pourra notamment y trouver : L'association d'agrgation Les proprits d'association L'expression de rles dans les associations Les attributs de classe Les qualificatifs Les oprations (ou mthodes) Le chapitre donne de plus des conseils mthodologiques pour la conception (voir en particulier la synthse page 163). On pourra galement y trouver : Des principes de choix de modlisation entre attributs et classes et sur la segmentation des classes Des principes de slection des attributs (redondance avec les associations, avec les classes, etc.) Des principes de slection des associations Des principes de choix de cardinalit (notamment pour la gestion d'historisation) Des principes de slection des relations de gnralisation (hritage) Des principes d'introduction de mtaclasses (type)s
Complment : Rfrence UML en ligne

UML en Franais [w_uml.free.fr] Une trs bonne rfrence en ligne sur la modlisation UML, avec des cours, des liens vers la norme, etc. Le contenu dpasse trs largement l'usage d'UML pour la modlisation de BD (et ne fait d'ailleurs pas de rfrence prcise ce sous-ensemble particulier). On pourra consulter en particulier le chapitre sur les diagrammes de classe : http://uml.free.fr/cours/ip14.html
Complment : Tutoriel sur la modlisation UML.

UML en 5 tapes [w_journaldunet.com(1)] On consultera en particulier le tutoriel sur les diagrammes http://developpeur.journaldunet.com/tutoriel/cpt/010607cpt_umlintro.shtml de classe :
Complment : Conseils
Cinq petits conseils pour un schma UML efficace [w_journaldunet.com(2)]
1 - http://argouml.tigris.org/ 2 - http://www.eclipsedownload.com/ S. Crozat - UTC 2009
43
III -
LE NIVEAU LOGIQUE : LA
Description du modle relationnel Le passage UML vers Relationnel Le passage E-A vers Relationnel Algbre relationnelle En rsum : Schma relationnel Bibliographie commente sur le modle relationnel
MODLISATION RELATIONNELLE
III
55 68 80 85 92 93
Le modle relationnel est aux fondements des SGBDR. Il a t - et continue d'tre - le modle thorique dominant pour la reprsentation logique des BD. Le modle relationnel permet de reformuler le modle conceptuel dans un formalisme beaucoup plus proche de l'implmentation informatique, bien que encore indpendant d'une solution technologique particulire. Le modle relationnel, et en particulier l'algbre relationnelle qui lui est associe, est aussi le fondement thorique du langage standard SQL, qui est utilis pour manipuler les donnes stockes dans une BD.
A. Description du modle relationnel

Objectifs
Connatre les fondements thoriques du modle relationnel. Comprendre le principe d'clatement des relations et de non-redondance.
1. Le niveau logique
Le niveau logique est le lien entre le niveau conceptuel et l'implmentation effective de l'application. Le modle conceptuel tant un modle formel, le modle logique a pour vocation d'tre galement un modle formel, mais spcifiant non plus la ralit existante ou recherche comme le modle conceptuel, mais les donnes telles qu'elles vont exister dans l'application informatique. Pour assumer cette fonction, le modle relationnel [Codd70] s'est impos en raction aux insuffisances des modles prcdents, les modles hirarchique et rseau, et de part la puissance de ses fondements mathmatiques. Encore aujourd'hui dominant le modle relationnel est un fondement indispensable la conception de bases de donnes. De plus le modle mergeant actuellement est le modle relationnel-objet, et ce dernier est bien une extension du modle relationnel qui le renforce et s'y appuie.
45
Le niveau logique : la modlisation relationnelle
2. Le modle relationnel
Introduction
Le modle relationnel a t introduit par Codd [Codd70], en 1970 au laboratoire de recherche d'IBM de San Jos. Il s'agit d'un modle simple et puissant la base de la majorit des bases de donnes aujourd'hui.
Dfinition : Modle relationnel

Ensemble de concepts pour formaliser logiquement la description d'articles de fichiers plats, indpendamment de la faon dont ils sont physiquement stocks dans une mmoire numrique. Le modle relationnel inclut des concepts pour la description de donnes, ainsi que des concepts pour la manipulation de donnes. Les objectifs du modle relationnel, formuls par Codd, sont les suivants : Assurer l'indpendance des applications et de la reprsentation interne des donnes Grer les problmes de cohrence et de redondance des donnes Utiliser des langages de donnes bass sur des thories solides
Remarque : Extension du modle relationnel

Le modle relationnel est un standard, normalis par l'ISO travers son langage, le SQL. Il se veut nanmoins ds l'origine extensible, pour permettre de grer des donnes plus complexes que les donnes tabulaires. Le modle relationnel-objet est n de cette extension.
3. Domaine
Dfinition : Domaine
Ensemble, caractris par un nom, dans lequel des donnes peuvent prendre leurs valeurs.
Remarque
Un domaine peut-tre dfini en intention (c'est dire en dfinissant une proprit caractristique des valeurs du domaine) ou en extension (c'est dire en numrant toutes les valeurs du domaine)
Exemple : Domaines dfinis en intention

Entier Rel Boolen Chane de caractres Montaire : rel avec deux chiffres aprs la virgule Date : chane de 10 caractres comprenant des chiffres et des tirets selon le patron "00-00-0000" Salaire : Montaire compris entre 15.000 et 100.000
Exemple : Domaines dfinis en extension

Couleur : {Bleu, Vert, Rouge, Jaune, Blanc, Noir} SGBD : {Hirarchique, Rseau, Relationnel, Objet, Relationnel-Objet}
4. Produit cartsien
Dfinition : Produit cartsien
Le produit cartsien, not "X", des domaines D1, D2, ... , Dn, not "D1 X D2 X ... X Dn" est l'ensemble des tuples (ou n-uplets ou vecteurs) <V1,V2,...,Vn> tel que Vi est une valeur de Di et tel que toutes les
46
combinaisons de valeurs possibles sont exprimes.
Exemple
D1 = {A, B, C} D2 = {1, 2, 3} D1 X D2 = {<A,1>, <A,2>, <A,3>, <B,1>, <B,2>, <B,3>, <C,1>, <C,2>, <C,3>,}
5. Relation
Dfinition : Relation
Une relation sur les domaines D1, D2, ..., Dn est un sous-ensemble du produit cartsien "D1 X D2 X ... X Dn". Une relation est caractrise par un nom. Synonymes : Table, tableau
Syntaxe
On peut reprsenter la relation R sur les domaine D1, ... , Dn par une table comportant une colonne pour chaque domaine et une ligne pour chaque tuple de la relation.
D1 V1 ... V1 ... ... ... ... Vn ... Vn Dn
Tableau 1 Relation R
Remarque
Une relation est toujours dfinie en extension, par l'numration des tuples la composant.
6. Attribut et enregistrement
Dfinition : Attribut
On appelle attribut d'une relation, une colonne de cette relation. Un attribut est caractris par un nom et un domaine dans lequel il prend ses valeurs. Synonymes : Champs, Proprit, Colonne
Dfinition : Enregistrement
On appelle enregistrement d'une relation, une ligne de cette relation. Un enregistrement prend une valeur pour chaque attribut de la relation. Synonymes : Tuple, N-uplet, Vecteur, Ligne
Exemple
A 1 1 2 1 2 2 B
Tableau 2 Relation R La relation R comporte les deux attributs A et B et les trois enregistrements <1,1>, <1,2> et <2,2>
47
Remarque : Attribut, domaine, ordre

Un attribut se distingue d'un domaine car il peut ne comporter que certaines valeurs de ce domaine. Les colonnes de la relation ne sont pas ordonnes et elles ne sont donc repres que par le nom de l'attribut.
Remarque : Valeur nulle

Un enregistrement peut ne pas avoir de valeur pour certains attributs de la relation, parce que cette valeur est inconnue ou inapplicable, sa valeur est alors "null".
7. La relation Vol
Exemple
Numero AF3245 AF6767 KLM234 Compagnie AirFrance AirFrance KML 747 A320 727 Avion Dpart Paris Paris Paris Arriv e OulanBator Toulouse Amsterdam Date 01082002 30072002 31072002
Tableau 3 Relation Vol
8. Cl
Dfinition : Cl
Une cl est un groupe d'attributs minimum qui dtermine un tuple unique dans une relation.
Attention : Attributs de cls toujours valus

Afin d'tre dterminants pour l'identification d'un enregistrement, tous les attributs d'une cl doivent tre valus, c'est dire qu'aucun ne peut avoir de valeur "null".
Dfinition : Cl primaire
Toute relation doit comporter au moins une cl, ce qui implique qu'une relation ne peut contenir deux tuples identiques. Si plusieurs cls existent dans une relation, on en choisit une parmi celles-ci. Cette cl est appele cl primaire. La cl primaire est gnralement choisie de faon ce qu'elle soit la plus simple, c'est dire portant sur le moins d'attributs et sur les attributs de domaine les plus basiques (entiers ou chanes courtes typiquement).
Dfinition : Cls candidates

On appelle cls candidates l'ensemble des cls d'une relation qui n'ont pas t choisies comme cl primaire (elles taient candidates cette fonction).
Remarque : Dtermination d'une cl

Dfinir un groupe d'attributs comme tant une cl ncessite une rflexion smantique sur les donnes composant ces attributs, afin de s'assurer de leur unicit.
Exemple
L'attribut numro de scurit sociale d'une relation personne est une bonne cl car son unicit est assure smantiquement.
48
Le groupe d'attributs nom, prnom d'une relation personne est en gnral une mauvaise cl, car les homonymes existent.
9. Cl artificielle
Dfinition : Cl artificielle
S'il est impossible de trouver une cl primaire, ou que les cls candidates sont trop complexes, il est possible de faire appel une cl artificielle. Une cl artificielle est un attribut supplmentaire ajout au schma de la relation, qui n'est li aucune signification, et qui sert uniquement identifier de faon unique les enregistrements et/ou simplifier les rfrences de cls trangres.
Dfinition : Cl signifiante
Une cl est signifiante si elle n'est pas artificielle.
Remarque : Cl artificielle et niveau logique

Au niveau du modle logique, il faut viter la simplicit consistant identifier toutes les relations avec des cls artificielles, et ne rserver cet usage qu'aux cas particuliers.
Remarque : Cl artificielle et niveau physique, volutivit, maintenance et performance

Au niveau de l'implmentation physique par contre, il est courant que des cls artificielles soient utilises de faon systmatique. Du point de vue de l'volutivit de la BD, il existe toujours un risque qu'une cl non-artificielle perde sa proprit d'unicit ou de non-nullit. Du point de vue de la maintenance de la BD, il existe toujours un risque qu'une cl non-artificielle voit sa valeur modifie et dans ce cas, la rpercution de ce changement pour mettre jour toutes les rfrences peut poser problme. Du point de vue de la performance de la BD, les cls non-artificielles ne sont pas en gnral optimises en terme de type et de taille, et donc peuvent limiter les performances dans le cadre des jointures. Prcisons nanmoins qu'inversement les cls artificielles ont pour consquence de systmatiser des jointures qui auraient pu tre vites avec des cls primaires signifiantes.
Exemple : Problme d'volutivit pos par une cl signifiante

Soit le numro de scurit sociale la cl primaire d'une table d'une BD franaise, elle ne permettra pas d'entrer un individu non-franais issu d'un pays ne disposant pas d'un tel numro.
Exemple : Problme de maintenance pos par une cl signifiante

Soit le numro de scurit sociale la cl primaire d'une table d'une BD centrale dont les donnes sont exploites par d'autres tables d'autres BD qui viennent "piocher" dans cette BD pour leurs propres usages, sans que la BD centrale ne connaisse ses "clients". Soit une erreur dans la saisie d'un numro de scurit sociale dans la BD centrale, si ce numro est corrig, il faudrait (ce qui n'est pas possible dans notre cas) imprativement en avertir toutes les bases utilisatrices pour qu'elles mettent jour leurs rfrences.
Exemple : Problme de performance pos par une cl signifiante

Soit le numro de scurit sociale la cl primaire d'une table comptant un million d'enregistrements, ce numro est gnralement un nombre 13 chiffres ou une chane 13 caractres, ce qui dans les deux cas est suprieur au nombre 7 chiffres suffisant pour identifier tous les individus de la BD. Les performances seront donc toujours moins bonnes, lors des jointures, si une cl prend deux fois plus de place en mmoire que son optimum. Mais ajoutons que cette perte de performance n'a pas toujours de consquence sur la ralit perceptible par les utilisateurs de la BD. Inversement, soit une cl artificielle la cl primaire d'une table T1, par ailleurs rfrence par une autre table T2. Soit le numro de scurit sociale un attribut cl de T1. Si l'on veut par requte disposer des
49
informations de T2 ainsi que du numro de scurit sociale de T1, alors il faudra faire une jointure, tandis que si ce numro signifiant avait t choisi comme cl primaire, cela n'aurait pas t ncessaire.
10. Lien entre relations

Le modle relationnel a pour objectif la structuration de donnes selon des relations. L'enjeu est de parvenir traduire un modle conceptuel en modle logique relationnel. Typiquement si le formalisme conceptuel utilis est le modle E-A, il faudra pouvoir traduire les entits et les associations en relations. Afin que la reprsentation des donnes ne soit pas redondante, il est ncessaire que les donnes soit rparties dans de multiples relations et non regroupes dans une seule. Or un modle conceptuel informe sur les liens entre les entits et associations, cela est traduit graphiquement par les lignes qui les relient. Il est donc fondamental que le modle relationnel puisse galement maintenir cette information, savoir les liens entre les donnes rparties dans les relations. Afin de reprsenter des liens entre relations dans un modle relationnel, la seule solution est de stocker l'information dans une relation, et donc que certains attributs d'une relation servent pointer sur d'autres relations.
Mthode : Lien
Le lien entre deux tuples A=>B de deux relations diffrentes est matrialisable par une rfrence depuis l'un des tuples, A, la cl primaire de l'autre tuple, B.
Exemple
Principe des liens entre relations L'attribut "Attribut2" de la relation "Relation1" rfrence l'attribut "Attribut1" de la relation "Relation2" ("Attribut1" est la cl primaire de "Relation2").
Remarque : Direction du lien

Dans un modle relationnel, un lien est toujours unidirectionnel.
11. clatement des relations pour viter la redondance

a) Relation redondante
Numero
1010 1011 1012 1013
Date
Gare1
Gare2
Lyon Limoges Madrid Limoges
Train
TG V TER TG V TER
Vitesse
450 200 450 200
Nom
Dupont Durand Dupont Dupont
Prnom
Jolle JeanPierre Jolle JeanPierre
01012001 Paris 02012001 Paris 03012001 Paris 03012001 Lyon
Tableau 4 Relation VoyageEnTrain
Dans la reprsentation prcdente, les voyages en train sont reprsents dans une unique relation, qui contient des informations relatives au voyage lui mme (numro, date, dpart, arrive), mais aussi au train utilis pour le voyage (type de train et vitesse maximale), et au conducteur du train (nom et prnom). Cette reprsentation, bien que trs simplifie par rapport la ralit (on imagine facilement plusieurs
50
dizaines d'attibuts possibles) est redondante. En effet chaque fois qu'un voyage mobilisera un train TGV, la vitesse maximale de 450 km/h devra aussi tre rappele. De mme pour chaque conducteur, il faudra rappeler le nom et le prnom. Cette redondance pose un certain nombre de problmes : Incohrence Imaginons qu'une faute de saisie se glisse dans l'orthographe du nom de Dupont (un "d" la place du "t") pour le voyage 1010, il sera impossible de savoir que c'est la mme personne qui conduit le train pour le voyage 1012 (car Jolle Dupond peut exister et tre conductrice de train). Mise jour Imaginons que Jolle Dupont se marie et change de nom, il faudra changer cette information pour tous les voyages auxquels participe cette conductrice. Ceci est galement un risque d'erreur, qui renvoie au risque d'incohrence prcdemment mis en exergue. Perte d'information Imaginons que temporairement plus aucun voyage n'existe pour des TGV. Tous les enregistrements portant sur les TGV disparaitront. On perdra alors l'information comme quoi la vitesse d'un TGV est de 450 km/h, car cette information n'existera plus dans la base. Or l'information intrinsque au TGV, qui est sa vitesse maximale, n'est pas lie un voyage en particulier, et donc il est dommage de ne pas conserver cette information indpendamment du fait que les TGV sont ou non utiliss un instant t. Dpendance des insertions Imaginons que nous souhaitions reprsenter dans la base de donnes un nouveau conducteur, qui n'est encore affect aucun voyage. Il est impossible d'ajouter une telle information, car l'insertion d'une personne est dpendant de l'insertion d'un tuple complet portant galement sur un voyage. Il est videmment trs mauvais d'imaginer des solutions de contournement, telles que par exemple un tuple avec des valeurs nulles sur toutes les proprits sauf les nom et prnom.
b) Relation clate
Le bon usage du modle relationnel consiste donc clater les informations dans de multiples relations, afin de ne pas conserver de redondance. Dans le cas prcdent, on prfrera donc un dcoupage de la relation VoyageEnTrain en trois relations, Voyage, Modele et Conducteur, chacune reprsentant des informations correspondant des objets diffrents (notons l'ajout d'une cl artificielle numro pour la nouvelle relation conducteur, non identifiable de faon unique par les attributs nom et prnom).
Numero 1010 1011 1012 1013 Date 01012001 02012001 03012001 03012001 Paris Paris Paris Lyon Gare1 Lyon Limoges Madrid Limoges Gare2
Tableau 5 Relation Voyage

Modele TGV TER 450 200 Vitesse
Tableau 6 Relation Modele
51

Numero 1 2 Dupont Durand Nom Jolle JeanPierre Prnom
Tableau 7 Relation Conducteur
c) Relation clate avec liens

Dans cette reprsentation clate des donnes prcdemment regroupes dans la mme relation, on a perdu des informations importantes, relatives aux liens entre les voyages, les modles de train et les conducteurs. En effet on ne sait plus que le voyage numro 1010 s'effectue sur un TGV avec la conductrice Jolle Dupont. Il est indispensable, pour conserver l'ensemble des informations, de matrialiser nouveau ces liens, en ajoutant des rfrences dans la relation Voyage, aux tuples de Modele et Conducteur.
Numero 1010 1011 1012 1013 Date 01012001 02012001 03012001 03012001 Gare1 Paris Paris Paris Lyon Gare2 Lyon Limoges Madrid Limoges Modele TGV TER TGV TER 1 2 1 2 Conducteur
Tableau 8 Relation Voyage
12. Cl trangre
Dfinition : Cl trangre
Groupe d'attributs d'une relation R1 devant apparatre comme cl dans une autre relation R2 afin de matrialiser un lien entre les tuples de R1 et les tuples de R2. La cl trangre d'un tuple rfrence la cl primaire d'un autre tuple.
Dfinition : Contrainte d'intgrit rfrentielle

Une cl trangre respecte la contrainte d'intgrit rfrentielle si sa valeur est effectivement existante dans la cl primaire d'un tuple de la relation rfrence, ou si sa valeur est "null". Une cl trangre qui ne respecte pas la contrainte d'intgrit rfrentielle exprime un lien vers un tuple qui n'existe pas et donc n'est pas cohrente.
Remarque : Suppression et mise jour en cascade

Pour que la cohrence soit conserve, lors de la suppression d'un tuple rfrenc par d'autres tuples, les tuples rfrenants doivent galement tre supprims. Sinon leur cl trangre pointerait vers des tuples qui n'existent plus et la contrainte d'intgrit rfrentielle ne serait plus respecte. Afin de maintenir la cohrence, il faut donc procder une suppression en cascade (sachant que les tuples rfrenant peuvent galement tre rfrencs par ailleurs). La problmatique est la mme lors d'une mise jour de la cl primaire d'un tuple : il faut alors mettre jour toutes les cls trangres rfrenant ce tuple. Notons que certains SGBD peuvent se charger automatiquement de ces suppressions et mises jour en cascade.
13. Schma relationnel

Dfinition : Schma d'une relation
Le schma d'une relation dfinit cette relation par intention. Il est compos du nom de la relation, de la
52
liste de ses attributs avec les domaines respectifs dans lesquels ils prennent leurs valeurs, de la cl primaire, et des cls trangres.
Dfinition : Schma relationnel d'une base de donne

Le schma relationnelle d'une BD est la dfinition en intention de cette BD (par opposition l'instance de la BD qui est une extension de la BD). Il est compos de l'ensemble des schmas de chaque relation de la BD.
Syntaxe : Relation
Relation (Attribut1:Domaine1, Attribut2:Domaine2, ... , AttributN:DomaineN) La relation "Relation" contient N attributs chacun dfini sur son domaine.
Syntaxe : Cl primaire
Relation (#Attribut1:Domaine1, ... , #AttributM:DomaineM, ... , AttributN:DomaineN) La cl de la relation "Relation" est compose des attributs "Attribut1" "AttributM" (attribut prcds de # ou bien souligns) En gnral on note la cl primaire en premier dans la relation.
Syntaxe : Cl trangre
Relation1 (..., AttributM=>Relation2, ... , AttributN=>Relation2) La relation "Relation1" comporte une cl trangre (compose des attributs "AttributM" "AttributN") rfrenant la cl primaire de "Relation2". Bien sr il peut exister plusieurs cls trangres vers plusieurs relations distinctes. Une cl trangre et sa cl primaire rfrence sont toujours composes du mme nombre d'attributs. Il n'est pas ncessaire de prciser les domaines des attributs appartenant la cl trangre car ce sont forcment les mmes que ceux de la cl primaire rfrence. Il n'est pas non plus en gnral ncessaire de prciser dans le schma relationnel quels attributs de la cl trangre rfrencent quels attributs de la cl primaire (cela est gnralement vident) mais il est possible de la faire on notant "Attribut=>Relation.Attribut". En gnral on note les cls trangres en dernier dans la relation, sauf pour les cls trangres qui font partie de la cl primaire (cls identifiantes).
Attention : Cls candidates

On ne reprsente pas, en gnral, sur le schma relationnel les cls candidates afin de ne pas alourdir la notation. On recommande nanmoins de dresser la liste des cls candidates (non choisies comme cls primaires) en annotation du schma relationnel afin d'en conserver la mmoire. On peut nanmoins noter les cls candidates en les soulignant en pointill.
14. Exemple de schma relationnel simple pour la gographie

Exemple
Personne (#Numero:Entier, Nom:Chane, Prnom:Chane, LieuNaissance=>Ville) Pays (#Nom:Chane, Population:Entier, Superficie:Rel, Dirigeant=>Personne) Rgion (#Pays=>Pays, #Nom:Chane, Superficie, Dirigeant=>Personne) Ville (#CodePostal:CP, Nom:Chane, Pays=>Rgion.Pays,
53
Rgion=>Rgion.Nom, Dirigeant=>Personne) Le schma relationnel prcdent dcrit : Des personnes Elles sont identifies par un numro qui est en fait une cl artificielle. En effet, mme une cl compose de tous les attributs (Nom, Prnom, LieuNaissance) laisse une possibilit de doublons (homonymes ns dans la mme ville). La cl trangre LieuNaissance fait rfrence la relation Ville, et plus prcisment sa cl primaire CodePostal, ce qui est est laiss implicite car vident. Des pays Ils sont identifis par leur nom, puisque deux pays ne peuvent avoir le mme nom. Les pays sont dirigs par des personnes, et ce lien est matrialis par la cl trangre Dirigeant. Des rgions Elles font partie d'un pays et ont un nom. Deux rgions de pays diffrents pouvant avoir le mme nom, il faut utiliser une cl primaire compose la fois du nom de la rgion et du nom du pays, qui est une cl trangre (le nom est appel cl locale car il n'est pas suffisant pour identifier un tuple de la relation Rgion, et la cl trangre vers la relation Pays est appele cl identifiante). Des villes Elles sont identifi par un code postal qui est unique dans le monde (en utilisant le prfixe de pays de type "F-60200"). Ce code postal pour domaine CP qui est une chane compose d'une ou deux lettres, d'un tiret, puis d'une srie de chiffres. Le lien d'appartenance entre une ville et une rgion est matrialis par la cl trangre compose des deux attributs Pays et Rgion. Cette cl rfrence la cl primaire de la relation Rgion, galement compose de deux attributs. Pour clairement expliciter les rfrences (bien que smantiquement la dnomination des attributs ne laisse pas de place au doute) on utilise la syntaxe Rgion.Pays et Rgion.Nom.
B. Le passage UML vers Relationnel

Objectifs
Savoir-faire le passage d'un schma conceptuel UML un schma relationnel. Connatre les choix possibles pour les cas dlicats (hritage, relation 1:1, etc.) et savoir-faire les bons choix.
Afin de pouvoir implmenter une base de donnes, il faut pouvoir traduire le modle conceptuel en modle logique. Cela signifie qu'il faut pouvoir convertir un modle UML en modle relationnel. Les modles conceptuels sont suffisamment formels pour ce passage soit systmatis.
1. Transformation des classes

Mthode : Classe
Pour chaque classe C non abstraite, on cre une relation R dont le schma est celui de la classe. La cl primaire de R est une des cls de C.
54
Remarque
Les classes abstraites sont ignores ce stade, et n'tant pas instanciables, ne donnent gnralement pas lieu la cration de relation.
2. Transformation des associations

Mthode : Association 1:N
Pour chaque association binaire A de type 1:N (le cas chant 0,1:N) entre les classes S et T (reprsents par les relations RS et RT respectivement) on inclut dans la dfinition de RT comme cl trangre la cl de RS.
Mthode : Association M:N et associations de degr suprieur 2

Pour chaque association binaire A de type M:N ou pour chaque association A de degr suprieur 2, on cre une nouvelle relation RA pour reprsenter A. On met dans RA comme cl trangre, les cls de toutes les relations correspondant aux classes participant A et dont la concatnation formera sa cl.
Mthode : Association 1:1

Pour chaque association binaire A de type 1,1:1,1 ou 1,1:1,0 entre les classes S et T (reprsents par les relations RS et RT respectivement) on substitut dans la dfinition de RS l'ventuelle cl primaire (si RS tait identifie) par la cl primaire de RT qui est galement dfinie comme cl trangre vers RT. Notons que dans le cas d'une association 1,1:1,1 RT peut-tre choisi la place de RS pour accueillir la cl trangre. Pour chaque association binaire A de type 0,1:0,1 entre les classes S et T (reprsents par les relations RS et RT respectivement) on inclut dans la dfinition de RS comme cl trangre la cl de RT. La cl trangre vers RT incluse dans RS est galement dfinie comme tant unique, afin d'assurer la cardinalit maximum de 1. Notons qu'il n'tait pas possible dans ce cas 0,1:0,1 que la cl trangre vers RT incluse dans RS soit galement la cl primaire, car la cardinalit de 0 supposerait que la cl primaire puisse tre "null", ce qui est illgal pour une cl.
Mthode : Cardinalit minimale 0 ou 1

Selon que la cardinalit minimale est 0 ou 1 (ou plus) du ct de la relation rfrenante on ajoutera ou non une contrainte de non nullit sur la cl trangre. Selon que la cardinalit minimale est 0 ou 1 (ou plus) du ct de la relation rfrence on ajoutera ou non une contrainte d'existence de tuples rfrenant pour chaque tuple de la relation rfrence.
3. Remarques concernant la transformation des associations 1:1

Remarque : Choix de la relation rfrenante pour la traduction de l'association 1:1
La traduction d'une association 1:1 ou 0..1:0..1 conduit devoir faire un choix entre les deux classes composant l'association, afin de dterminer laquelle est rfrence de laquelle est rfrenante. Ce choix peut-tre arbitraire, mais peut galement tre clair par la smantique des relations, et l'on choisira alors celle qui est de plus faible importance du point de vue de la modlisation pour rfrencer (et donc intgrer la cl trangre).
Exemple : Exemple de choix de la relation rfrenante pour une relation 1:1

Soit deux classes, "homme" et "femme" et une association "mariage" de cardinalit 1:1 (hommes et femmes sont donc obligatoirement maris) unissant ces deux classes. Les classes "homme" et "femme" sont identifies par un attribut "nom". S'il serait plus galant de choisir "femme" comme classe principale, il sera dans la pratique plus opportun de choisir "homme", car le "nom" de la classe "homme" sera effectivement une proprit pertinente pour la classe "femme" et donc aura plus de sens en tant que cl primaire et en tant que cl trangre (dans le cas inverse, la cl de l'homme serait le nom de sa femme, ce qui ne correspond pas la ralit administrative du mariage). On choisira donc plutt la reprsentation :
55
homme (#nom) femme (#nomMariage=>homme, nomJeuneFille) avec nomJeuneFille cl Si l'association avait t de cardinalit 0..1:0..1 (certains hommes et femmes ne sont pas maris), le mme choix se serait impos et l'on aurait abouti au rsultat suivant: homme (#nom) femme (#nomJeuneFille, nomMariage=>homme) avec nomMariage unique
Remarque : Fusion des relations dans le cas de la traduction de l'association 1:1

Il est possible, dans le cas d'une association 1:1 de dcider de fusionner les deux relations en une seule. La relation rsultante est alors compose de l'ensemble des attributs de chacune des deux relations, en choisissant l'une des deux cls de l'une des deux relations pour identifier la nouvelle relation. Ce choix sera conduit par une apprciation du rapport entre : La complexit introduite par le fait d'avoir deux relations l ou une suffit, La pertinence de la sparation des deux relations d'un point de vue smantique, Les pertes de performance dues l'clatement des relations, Les pertes de performance dues au fait d'avoir une grande relation, Les questions de scurit et de suret factorises ou non au niveau des deux relations, etc. Dans le doute il est prfrable d'adopter l'approche systmatique consistant sparer les deux relations.
4. Transformation des attributs et mthodes

Mthode : Attributs simples
Pour chaque attribut lmentaire et monovalu A d'une classe E (idem pour les associations), on cre un attribut correspondant A sur la relation RE correspondant E.
Mthode : Attributs composites

Pour chaque attribut composite C, comprenant N sous-attributs, d'une classe E (idem pour les associations), on cre N attributs correspondants C sur la relation RE correspondant E.
Mthode : Attributs multivalus

Pour chaque attribut multivalu M d'une classe E (idem pour les associations), on cre une nouvelle relation RM qui comprend un attribut monovalu correspondant M plus la cl de RE (relation reprsentant E). La cl de RM est la concatnation des deux attributs.
Mthode : Attributs drivs et mthodes

On ne reprsente pas en gnral les attributs drivs ni les mthodes dans le modle relationnel, ils seront calculs dynamiquement soit par des procdures internes la BD (procdures stockes), soit par des procdures au niveau applicatif. On peut nanmoins dcider (pour des raisons de performance essentiellement) de reprsenter l'attribut driv ou la mthode comme s'il s'agissait d'un attribut simple, mais il sera ncessaire dans ce cas d'ajouter des mcanismes de validation de contraintes dynamiques (avec des triggers par exemple) pour assurer que la valeur stocke volue en mme temps que les attributs sur lesquels le calcul driv porte. Notons qu'introduire un attribut driv ou un rsultat de mthode dans le modle relationnel quivaut introduire de la redondance, ce qui est en grnal dconseill, et ce qui doit tre dans tous les cas contrl.
5. Transformation des classes d'association

56
Mthode : Classe d'association 1:N

Les attributs de la classe d'association sont ajouts la relation issue de la classe ct N.
Mthode : Classe d'association N:M

Les attributs de la classe d'association sont ajouts la relation issue de l'association N:M. Si la classe d'association possde une cl, celle-ci est concatne aux cls trangres composant dj la cl primaire de la relation d'association.
Mthode : Classe d'association 1:1

Les attributs de la classe d'association sont ajouts la relation qui a t choisie pour recevoir la cl trangre. Bien entendu si les deux classes ont t fusionnes en une seule relation, les attributs sont ajoute celle-ci.
6. Transformation des compositions

Remarque
Une composition est transforme comme une association 1:N, mais on ajoute la cl de la classe partie (dite cl locale) la cl trangre vers la classe composite.
Mthode : Compositions
Soit la composition entre la classe composite C et la classe partie P (reprsents par les relations RC et RP respectivement) on inclut dans la dfinition de RP comme cl trangre la cl de RC. La cl de RP est redfinie comme la concatnation de la cl de P (cl locale) avec la cl trangre vers RC.
Remarque : Composition et entits faibles en E-A

Une composition est transforme selon les mmes principes qu'une entit faible en E-A.
7. Transformation de la relation d'hritage

Le modle relationnel ne permet pas de reprsenter directement une relation d'hritage, puisque que seuls les concepts de relation et de rfrence existent dans le modle. Il faut donc appauvrir le modle conceptuel pour qu'il puisse tre reprsent selon un schma relationnel. Trois solutions existent pour transformer une relation d'hritage : Reprsenter l'hritage par une rfrence entre la classe mre et la classe fille. Reprsenter uniquement les classes filles par des relations. Reprsenter uniquement la classe mre par une relation.
Mthode : Choisir le bon mode de transformation d'une relation d'hritage

La difficult consiste donc pour chaque relation d'hritage choisir le bon mode de transformation, sachant que chaque solution possde ses avantages et ses inconvnients.
57
Modedetrans formation
Limite
Casd'usage
Exemple
Vue
Parrfrence
EtudiantetEm ployehritentde Personne(un Adapttousles tudiantpeut tre Lourdeurli ela casd'hritageni employ etles ncessitdere exclusif,nicom propritsdes prsenterles pletpar tudiantsetdes donnesdes ticulirementad employ ssont classesfillessur aptlorsquela diffrentes,de deuxrelations classemren'est plusdesper pasabstraite. sonnespeuvent existerquine sontniemploy s nitudiants). Hommeet Femmehritent dePersonne(un tupledeHomme Adaptl'hrit Redondanceli e nepeutpas tre ageexclusifpar l'existancesim untuplede ticulirementad ultanedetuples FemmeetPer aptlorsquela dansplusieurs sonneestab classemreest classesfilles straite,iln'existe abstraite. pasdePersonne quinesoitniun Homme,niune Femme). ResponsableetS alarihritent deEmploy (un Nullitsys responsableest tmatiquepour salarietaucun lesattributsd'une Adaptl'hrit attributn'estsp classe agecompletpar cifiqueni Re fillen'existantpas ticulirementad sponsable,ni pouruneautre aptlorsquela Salari,deplusil classefille(et classemren'est existedesstagi pourlaclasse pasabstraite. airesparexemple mresicelleci quisontjuste n'estpasab employ s,mais straite) nonsalari set nonrespons ables)
Unevuedoit tre crepour chaqueclasse fille(ralisantla jointureavecla classemre).
Parlesclasses filles
Unevuedoit tre cre,unique mentdanslecas olaclassem re n'estpasab straite,pourunir lestuplesdes classesfilles avecceuxsp ci fiques laclasse mre.
Parlaclasse mre
Unevuedoit tre systmatique mentcrepour chaqueclasse fille(ralisantla restrictionetla projectiondepuis larelationunique cre).
Tableau 9 Choix de la bonne transformation
58
Modede transform ation Par rfrence Parles classes filles Parla classe mre
Classe mreab straite
Classe mrenon abstraite
Hritage exclusif
Hritage nonex clusif
Hritage complet
Hritage presque complet
Hritage noncom plet
+ +
= ++ +
= =
= ++
= = =
= =
Tableau 10 Choix de la bonne transformation
8. Transformation de la relation d'hritage par rfrence

Mthode : Hritage reprsent par une rfrence
Chaque classe, mre ou fille, est reprsente par une relation. La cl primaire d'une classe mre est utilise pour identifier chacune de ses classes filles (cette cl tant pour chaque classe fille la fois la cl primaire et une cl trangre vers la classe gnrale). Si une classe fille avait une autre cl primaire candidate dans le modle conceptuel, cette cl n'est pas retenue pour tre la cl primaire, tant donn que c'est la cl trangre rfrence la classe mre qui est retenue. La cardinalit d'un lien entre une classe fille et une classe mre est (1,1):(0,1). En effet toute classe fille rfrence obligatoirement une et une seule classe mre (pas d'hritage multiple) et toute classe mre est rfrence une ou zro fois (zro fois si un objet peut tre directement du type de la classe mre) par chaque classe fille . Une vue devra tre cre pour chaque classe fille en ralisant une jointure sur la classe mre.
Exemple : Hritage reprsent par une rfrence

Soit 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 modle relationnel correspondant selon cette transformation est : A (#K, A1, A2) B (#K=>A, K', B1, B2)
Remarque : Classe mre non abstraite

Cette solution est particulirement adapte lorsque la classe mre n'est pas abstraite, car cela en autorise l'instanciation sans aucun bruit dans la relation li aux classes filles. Par contre si la classe mre est abstraite il faut introduire une contrainte dynamique complexe pour imposer la prsence d'un tuple rfrenant dans une des classes filles. Ainsi dans l'exemple prcdent, un A peut tre instanci en toute indpendance par rapport la relation B.
Conseil : Solution gnrale

Cette solution est la plus gnrale, elle fonctionne correctement dans tous les cas. Le seul problme est la complexit de la structure de donne qu'elle induit.
9. Transformation de la relation d'hritage par les classes filles

Mthode : Hritage absorb par les classes filles
Chaque classe fille est reprsent par une relation. Tous les attributs de la classe mre sont rpts au niveau de chaque classe fille .
59
Si une classe fille a une cl primaire propre, cette cl n'est pas retenue, et c'est bien la cl hrite de la classe mre qui devient la cl primaire (mais la cl est bien entendu maintenue comme cl candidate) Si la classe mre n'est pas abstraite, elle est galement reprsente par une relation qui ne contiendra que les tuples qui ne sont pas aussi des instances de classes filles. La classe mre est alors reprsente par une vue qui unit ses propres tuples avec les tuples de toutes ses classes filles et en les projetant sur les attributs hrits uniquement.
Exemple : Hritage absorb par les classes filles

Soit la classe abstraite A avec la cl K et les attributs A1 et A2. Soit la classe B, classe fille de A avec les attributs B1 et B2. Soit la classe C, classe fille de A avec les attributs C1 et C2 Le modle relationnel correspondant selon cette transformation est : B (#K, A1, A2, B1, B2) C (#K, A1, A2, C1, C2) Si A n'avait pas t abstraite elle aurait donn naissance une relation A possdant les attributs A1 et A2 et qui n'aurait alors contenu que les tuples qui ne sont ni des B ni des C.
Remarque : Classe mre abstraite

Cette solution est particulirement adapte lorsque la classe mre est abstraite, car elle permet de ne pas matrialiser cette classe mre par une relation. En revanche dans le cas o la classe mre n'est pas abstraite, la solution est moins adapte, car il faut alors passer par une vue pour retrouver tous les tuples de la classe.
Conseil : Hritage exclusif

Cette solution est optimum dans le cas d'un hritage exclusif, c'est dire si aucun objet d'une classe fille n'appartient aussi une autre classe fille. Dans le cas contraire, le problme est que des redondances vont tre introduites puisqu'un mme tuple devra tre rpt pour chaque classe fille laquelle il appartient.
10. Transformation de la relation d'hritage par la classe mre

Mthode : Hritage absorb par la classe mre
La classe mre est reprsente par une relation, mais ses classes filles ne sont pas reprsentes par des relations. Tous les attributs de chaque classe fille sont rintgrs au niveau de la classe mre. Un attribut supplmentaire, dit de discrimination, est ajout la classe mre, afin de distinguer les tuples des diffrentes classes filles. Cet attribut est de type numration et a pour valeurs possibles les noms des diffrents classes filles. Afin de grer l'hritage non exclusif (un objet peut tre de plusieurs classe fille la fois), le domaine de l'attribut de discrimination, peut tre tendu des combinaisons de noms des diffrents classes filles. Si la classe mre n'est pas abstraite, une valeur supplmentaire peut-tre ajoute au domaine, ou bien l'on peut autoriser la valeur null qui dsignera alors un objet de la classe mre. Si une classe fille a une cl primaire propre, cette cl sera rintgre la classe mre, au mme titre qu'un autre attribut, mais bien entendu n'officiera pas en tant que cl primaire (et en gnral pas non plus en tant que cl candidate car elle pourra contenir des valeurs nulles). Chaque classe fille est reprsente par une vue qui slectionne les tuples de la classe mre qui appartiennent la classe fille et les projete sur les attributs de la classe fille.
Exemple : Hritage absorb par la classe mre

Soit la classe A avec la cl K et les attributs A1 et A2. Soit la classe B, classe fille de A avec les attributs B1 et B2. Soit la classe C, classe fille de A avec les attributs C1 et C2 Le modle relationnel correspondant selon cette transformation est : A (#K, A1, A2, B1, B2, C1, C2, D:{'B','C','BC'}) Si l'on pose que A n'est pas abstraite, alors un tuple sera un A s'il a la valeur null pour sa proprit D. Si l'on pose que A est abstraite, on ajoutera la contrainte NOT NULL la proprit D.
60
Remarque : Classe mre non abstraite

Cette solution est particulirement adapte lorsque la classe mre n'est pas abstraite, car cela en autorise l'instanciation naturellement, en ne renseignant pas l'attribut de discrimination. Lorsque la classe mre est abstraite il est moins naturel de disposer d'une table associe cette classe (et l'on pensera ajouter la contrainte NOT NULL sur l'attribut de discrimination).
Conseil : Hritage complet

Cette solution est optimum dans le cas d'un hritage complet, c'est dire si les classes filles ne dfinissent pas d'attributs autre que ceux hrits. Dans le cas contraire cela engendre des valeurs null. En pratique l'hritage complet est rare, mais nombre d'hritages le sont presque et pourront alors tre raisonnablement grs sellon cette approche, a fortiori si la classe mre n'est pas abstraite.
Conseil : Autre reprsentation de la discrimination

Si l'hritage concerne un nombre lev de classes filles et qu'il est principalement non exclusif alors le domaine de l'attribut de discrimination peut impliquer une combinatoire importante de valeurs. Pour contourner cette lourdeur il est possible d'utiliser, en remplacement, un attribut de domaine boolen pour chaque classe fille spcifiant si un tuple est un objet de cette classe. Dans cette configuration la classe mre sera logiquement considre comme non abstraite et un objet appartiendra la classe mre si tous ses attributs de discrimination valent "faux". Seule une contrainte dynamique permettra de dfinir la classe mre comme abstraite, en prcisant que les attributs de discrimination ne peuvent tre tous "faux".
11. Exemple de transformation d'une relation d'hritage

Exemple
Soit le modle UML suivant :
Reprsentation de documents Il existe trois faons de traduire la relation d'hritage : par rfrence, par absorption par les classes filles, par absorption par la classe mre.
Remarque : Type d'hritage

Si une thse peut galement tre un livre (c'est le cas si une thse peut-tre publie comme un livre par exemple), alors l'hritage n'est pas exclusif puisque un mme document peut tre une thse et un livre. L'hritage n'est pas non plus complet, puisque l'on observe que les thses et les livres ont des attributs qui ne sont pas communs (la discipline pour la thse et l'diteur pour le livre). En toute rigueur, il faudrait donc appliquer le cas gnral (ni exclusif, ni complet) et appliquer une traduction de l'hritage par rfrence. Observons nanmoins les avantages et inconvnients que chacun des trois choix porterait.
61
a) Hritage reprsent par une rfrence

Document(#Titre:Chane, Auteur:Chane) These(#Titre=>Document, Discipline:Chane) Livre(#Titre=>Document), Editeur:Chane
Remarque : Avantages du choix

Il n'y a ni redondance ni valeur nulle inutile dans les relations These et Livre, c'est la traduction la plus juste pour le problme pos.
Remarque : Inconvnient du choix

Il est relativement lourd de devoir crer un tuple dans Document pour chaque tuple dans These ou Livre, alors que la relation Document ce porte que l'information concernant l'auteur, juste pour assurer les cas, par ailleurs plutt rare dans la ralit, o les thses sont publies sous forme de livres. De plus la classe Document tant abstraite, il ne devra jamais y avoir de tuple dans document qui n'a pas de tuple correspondant dans Livre ou These. Ceci n'est pas contrlable directement en relationnel et devra donc tre vrifi au niveau applicatif (ou bien la classe ne devra plus tre considre comme abstraite).
b) Hritage absorb par les classes filles

These(#Titre, Discipline:Chane, Auteur:Chane) Livre(#Titre, Editeur:Chane, Auteur:Chane)

Il est plus simple que le prcdent, puisque la reprsentation d'une thse ou d'un livre ne ncessite plus que d'ajouter un seul tuple. Il vite donc les cls trangres, toujours plus dlicates grer d'un point de vue applicatif.

Lorsqu'une thse est publie sous la forme d'un livre, alors une information sera duplique (l'auteur), ce qui introduit de la redondance. Si une telle redondance peut-tre tolre pour des raisons de simplification ou de performance (si on considre que le cas est rare par exemple et donc que l'hritage est "presque" exclusif), il sera nanmoins ncessaire d'assurer son contrle par un moyen supplmentaire. Dans le cas gnral, il n'est pas souhaitable de tolrer une telle redondance.
c) Hritage absorb par la classe mre

Document(#Titre, Discipline:Chane, Editeur:Chane, Auteur:Chane, Type:{These|Livre|These+Livre})

Il est plus simple que le premier, puisque la reprsentation d'une thse ou d'un livre ne ncessite plus que d'ajouter un seul tuple. Il vite donc les cls trangres, toujours plus dlicates grer d'un point de vue applicatif.

Puisqu'il est rare que les thses soient publies sous forme de livre alors les tuples de la relation Document contiendront la plupart du temps une valeur nulle soit pour l'diteur soit pour la discipline. Cette introduction de valeurs nulles est moins problmatique que l'introduction de redondance observe dans le cas prcdent, aussi elle peut-tre plus facilement tolre. On considre alors que l'hritage est "presque" complet, puisque seuls deux attributs sont distingus. Cela dit ils s'agit de deux attributs sur quatre, soit une proportion importante d'une part, et il est regrettable que l'hritage soit galement
62
"presque" exclusif puisque l'introduction d'une valeur nulle sera quasi-systmatique.
d) En conclusion Conseil
L'hritage est toujours dlicat traduire en relationnel, ce qui est dommage car son pouvoir de reprsentation conceptuel est fort. Un conseil pour assumer une gestion correcte de la traduction de la relation d'hritage serait d'appliquer la lettre les rgles de transformation (ce qui conduira le plus souvent un hritage par rfrence) et, l'exprience aidant, de tolrer dans des cas bien matriss des digressions cette rgle.
Attention : Penser aux vues !

Il est important de bien penser ajouter les vues permettant de retrouver le schma initialement recherch.
12. Hritage et cl primaire

Attention
Dans tous les cas, notamment en cas d'hritage plusieurs niveaux, c'est la cl primaire de la classe la plus gnrale qui est retenue pour identifier les classes filles hritant directement ou indirectement de cette classe.
Exemple
Ainsi si C hrite de B qui hrite de A, c'est la cl de A qui permettra d'identifier les classes A, B et C, et ce quelque soit le mode de transformation retenu.
13. Liste des contraintes

Mthode : Contraintes exprimes sur le diagramme
Les contraintes exprimes sur le diagrammes sont reportes dans un tableau qui accompagnera le modle logique.
Mthode : Extension des contraintes exprimes

On s'attachera lors de la modlisation logique exprimer l'ensemble des contraintes dynamiques pesant sur le modle, mme celles qui ont t considres comme secondaires ou videntes lors de la modlisation conceptuelle.
14. Correspondance entre UML et relationnel
63
ModleUML Classeinstanciable Classeabstraite Objet Attributsimple Attributcomposite Attributmultivalu Attributdriv Mthode Association1:N AssociationN:M Associationdedegr 3ousuprieur Composition Classed'association Occurenced'uneassociation Hritage Relation Rien Nuplet
Modlerelationnel
Attributatomique Ensembled'attributs Relation Procdurestock eoucontraintedynamique Procdurestock e Attributs Relation Relation Attributs Attributs Nuplet Vues
Tableau 11 Passsage UML vers Relationnel
C. Le passage E-A vers Relationnel
Le passage E-A vers relationnel est trs similaire au passage UML vers relationnel. Les rgles dcrites ciaprs sont donc complter avec celles prescrites dans la partie prcdente.
1. Transformation des entits

Mthode : Entit identifie
Pour chaque entit (identifie) E, on cre une relation R dont le schma est celui de l'entit. La cl primaire de R est une des cls de E.
Mthode : Entit non identifie

Pour chaque entit non identifie I ayant un identifiant tranger E, on cre une relation R qui comprend tous les attributs de I, ainsi que les attributs cls de la relation correspondant E. La cl de R est la concatnation de la cl locale de I et de la cl de E.
2. Transformation des associations

Mthode : Association 1:N
Pour chaque association binaire A de type 1:N (le cas chant 0,1:N) entre les entits S et T (reprsents par les relations RS et RT respectivement) on inclut dans la dfinition de RT comme cl trangre la cl de RS ainsi que tous les attributs simples de A.
Mthode : Association M:N et associations de degr suprieur 2

Pour chaque association binaire A de type M:N ou pour chaque association A de degr suprieur 2, on
64
cre une nouvelle relation RA pour reprsenter A. On met dans RA comme cl trangre, les cls de toutes les relations correspondant aux entits participant A et dont la concatnation formera sa cl. On ajoute galement RA (et ventuellement dans sa cl pour les attributs cls) les attributs dfinis sur A.
Mthode : Association 1:1

Pour chaque association binaire A de type 1,1:1,1 ou 1,1:1,0 entre les entits S et T (reprsentes par les relations RS et RT respectivement) on substitut dans la dfinition de RS l'ventuelle cl primaire (si RS tait identifie) par la cl primaire de RT qui est galement dfinie comme cl trangre vers RT. On ajoute galement RS l'ensemble des attributs de A. Notons que dans le cas d'une association 1,1:1,1 RT peut-tre choisie la place de RS pour accueillir la cl trangre. Pour chaque association binaire A de type 0,1:0,1 entre les entits S et T (reprsentes par les relations RS et RT respectivement) on inclut dans la dfinition de RS comme cl trangre la cl de RT ainsi que tous les attributs simples de A. La cl trangre vers RT incluse dans RS est galement dfinie comme tant unique, afin d'assurer la cardinalit maximum de 1. Notons qu'il n'tait pas possible dans ce cas 0,1:0,1 que la cl trangre vers RT incluse dans RS soit galement la cl primaire, car la cardinalit de 0 supposerait que la cl primaire puisse tre "null", ce qui est illgal pour une cl.
Remarque : Cardinalit minimale 0 ou 1

Selon que la cardinalit minimale est 0 ou 1 (ou plus) du ct de la relation rfrenante on ajoutera ou non une contrainte de non nullit sur la cl trangre. Selon que la cardinalit minimale est 0 ou 1 (ou plus) du ct de la relation rfrence on ajoutera ou non une contrainte d'existence de tuples rfrenant pour chaque tuple de la relation rfrence.
3. Transformation de la relation d'hritage

Comme en UML, trois solutions existent pour transformer une relation d'hritage exprime en E-A : par rfrence, par absorption par les sous-types d'entit, par absorption par l'entit gnrale.
Attention : Les entits non finales sont abstraites

En modlisation E-A on considrera toujours que les entits non finales (c'est dire qui sont hrites par d'autres entits) sont abstraites. Une entit abstraite est une entit qui ne peut pas tre instancie. Donc si E2 hrite de E1 (et que E2 est finale c'est dire qu'aucune classe n'hrite de E2), il existera des objets de E2, mais pas des objets de E1. Si l'on veut disposer d'objets de E1, il suffit de crer une classe E1' qui hrite de E1 sans apporter de proprit supplmentaire. En modlisation UML on pourra diffrencier les classes abstraites des classes instanciables.
4. Exemple de passage E-A vers relationnel

Exemple
65
Transformation avec une relation 1:N
Exemple
Transformation avec une relation M:N
5. Comparaison des modles E-A, UML et relationnel
66

Mod leEA Entit Occurenced'uneentit Attributsimple Attributcomposite Attributmultivalu Attributd riv Entit faible Association1:N AssociationN:M Associationdedegr sup rieur Hritage 3ou Classe Objet Attributsimple Attributcomposite Attributmultivalu Attributd riv Mthode Association1:N AssociationN:M Associationdedegr sup rieur Hritage 3ou Mod leUML Nuplet Attributatomique Ensembled'attributs Relation Proc durestock eoucon traintedynamique Proc durestock e Relation Attributs Relation Relation Nuplet Vue Mod lerelationnel Relation
Occurenced'uneassociation
Occurenced'uneassociation
Tableau 12 Passage E-A et UML vers Relationnel
D. Algbre relationnelle
Objectifs
Connatre les oprateurs relationnels. Matriser l'algbre relationnelle.
1. Concepts manipulatoires
La reprsentation d'information sous forme relationnelle est intressante car les fondements mathmatiques du relationnel, outre qu'ils permettent une modlisation logique simple et puissante, fournissent galement un ensemble de concepts pour manipuler formellement l'information ainsi modlise. Ainsi une algbre relationnelle, sous forme d'un ensemble d'oprations formelles, permet d'exprimer des questions, ou requtes, poses une reprsentation relationnelle, sous forme d'expressions algbriques. L'algbre relationnelle est compose par les cinq oprateurs de base et les trois oprateurs additionnels suivants : Oprateurs de base Union Diffrence Projection Restriction Produit cartsien Oprateurs additionels Intersection Jointure Division
67
Remarque : Algbre relationnelle et SQL

Les questions formules en algbre relationnelle sont la base du langage SQL, qui est un langage informatique d'expressions permettant d'interroger une base de donnes relationnelle.
Remarque : Algbre relationnelle et objet

L'algbre relationnelle est tendue une algbre permettant de manipuler des objets autres, et a priori plus complexes, que des relations. Cette algbre tendue permet l'interrogation d'informations modlises sous forme relationnelle-objet.
2. Oprateurs ensemblistes
Attention
Les oprateurs ensemblistes sont des relations binaires (c'est dire entre deux relations) portant sur des relations de mme schma.
Dfinition : Union
L'union de deux relations R1 et R2 de mme schma produit une relation R3 de mme schma constitue de l'ensemble des tuples appartenant R1 et/ou R2.
Dfinition : Diffrence
La diffrence entre deux relations R1 et R2 de mme schma produit une relation R3 de mme schma constitue de l'ensemble des tuples de R1 n'appartenant pas R2. Notons que la diffrence entre R1 et R2 n'est pas gale la diffrence entre R2 et R1.
Dfinition : Intersection
L'intersection de deux relations R1 et R2 de mme schma produit une relation R3 de mme schma constitue de l'ensemble des tuples appartenant la fois R1 et R2. Notons que l'intersection n'est pas une opration de base, car elle est quivalent deux oprations de diffrence successives.
Exemple
Soit les deux relations suivantes : Homme (Nom, Prnom, Age) Femme (Nom, Prnom, Age) Soit les tuples suivants pour ces deux relations respectivement : (Dupont, Pierre, 20) (Durand, Jean, 30) (Martin, Isabelle, 20) (Tintin, Hlne, 30) Soit l'opration suivante : R = Union (Homme, Femme) On obtient alors la relation R compose des tuples suivants : (Dupont, (Durand, (Martin, (Tintin, Pierre, 20) Jean, 30) Isabelle, 20) Hlne, 30)
La diffrence entre Homme et Femme (respectivement entre Femme et Homme) renvoie la relation Homme (respectivement Femme), car aucun tuple n'est commun aux deux relations. L'intersection entre
68
Homme est Femme est vide, pour la mme raison.
Remarque : Union externe

Il est possible de dfinir une opration d'union externe, qui permet de raliser l'union de deux relations de schma diffrent, en ramenant les relations aux mmes schmas, et en les compltant avec des valeurs nulles.
3. Projection
Dfinition : Projection
La projection est une opration unaire (c'est dire portant sur une seule relation). La projection de R1 sur une partie de ses attributs {A1, A2, ...} produit une relation R2 dont le schma est restreint aux attributs mentionns en oprande, comportant les mmes tuples que R1, et dont les doublons sont limins.
Remarque : Elimination des doublons

Aprs suppression d'une partie des attributs du schma, la relation peut comporter des doublons. Etant donn que l'on ne pourrait plus identifier ces doublons les uns par rapport aux autres, la seule solution sense est donc de considrer que deux doublons sont quivalents, et donc de n'en garder qu'un seul dans la relation rsultante.
Exemple
Soit la relation suivante : Personne (Nom, Prnom, Age) Soit les tuples suivants : (Dupont, Pierre, 20) (Durand, Jean, 30) Soit l'opration suivante : R = Projection (Personne, Nom, Age) On obtient alors la relation R compose des tuples suivants : (Dupont, 20) (Durand, 30)
4. Restriction
Dfinition : Restriction
La restriction est une opration unaire (c'est dire portant sur une seule relation). La restriction de R1, tant donne une condition C, produit une relation R2 de mme schma que R1 et dont les tuples sont les tuples de R1 vrifiant la condition C.
Exemple
Soit la relation suivante : Personne (Nom, Prnom, Age) Soit les tuples suivants : (Dupont, Pierre, 20) (Durand, Jean, 30) Soit l'opration suivante :
69
R = Restriction (Personne, Age>25) On obtient alors la relation R compose de l'unique tuple restant suivant : (Durand, Jean, 30)
5. Produit
Dfinition : Produit cartsien
Le produit cartsien est une opration binaire (c'est dire portant sur deux relations). Le produit de R1 par R2 (quivalent au produit de R2 par R1) produit une relation R3 ayant pour schma la juxtaposition de ceux des relations R1 et R2 et pour tuples l'ensemble des combinaisons possibles entre les tuples de R1 et ceux de R2. Synonymes : Produit
Remarque
Le nombre de tuples rsultant du produit de R1 par R2 est gal au nombre de tuples de R1 multipli par le nombre de tuples de R2.
Exemple
Soit les deux relations suivantes : Homme (Nom, Prnom, Age) Femme (Nom, Prnom, Age) Soit les tuples suivants pour ces deux relations respectivement : (Dupont, Pierre, 20) (Durand, Jean, 30) (Martin, Isabelle, 15) (Tintin, Hlne, 40) Soit l'opration suivante : R = Produit (Homme, Femme) On obtient alors la relation R compose des tuples suivants : (Dupont, (Durand, (Dupont, (Durand, Pierre, 20, Martin, Isabelle, 15) Jean, 30, Martin, Isabelle, 15) Pierre, 20, Tintin, Hlne, 40) Jean, 30, Tintin, Hlne, 40)
6. Jointure
Dfinition : Jointure
La jointure est une opration binaire (c'est dire portant sur deux relations). La jointure de R1 et R2, tant donn une condition C portant sur des attributs de R1 et de R2, de mme domaine, produit une relation R3 ayant pour schma la juxtaposition de ceux des relations R1 et R2 et pour tuples l'ensemble de ceux obtenus par concatnation des tuples de R1 et de R2, et qui vrifient la condition C.
Exemple
Soit les deux relations suivantes : Homme (Nom, Prnom, Age)
70
Enfant (Nom, Prnom, Age) Soit les tuples suivants pour ces deux relations respectivement : (Dupont, Pierre, 20) (Durand, Jean, 30) (Dupont, Georges, 1) (Dupont, Jacques, 3) Soit l'opration suivante : R = Jointure (Homme, Enfant, Homme.Nom=Enfant.Nom) On obtient alors la relation R compose des tuples suivants : (Dupont, Pierre, 20, Dupont, Georges, 1) (Dupont, Pierre, 20, Dupont, Jacques, 3)
Remarque : Opration additionnelle

La jointure n'est pas une opration de base, elle peut tre rcrite en combinant le produit et la restriction.
7. Jointure naturelle
Dfinition : Jointure naturelle
La jointure naturelle entre R1 et R2 est une jointure pour laquelle la condition est l'galit entre les attributs de mme nom de R1 et de R2. Il est donc inutile de spcifier la condition dans une jointure naturelle, elle reste toujours implicite.
Exemple
Soit deux relations R1 (A, B, C) et R2 (A, D), l'opration Jointure(R1,R2,R1.A=R2.A) est quivalente l'opration JointureNaturelle(R1,R2).
Remarque
Pour appliquer une jointure naturelle, il faut que les deux relations oprandes aient au moins un attribut ayant le mme nom en commun.
8. Jointure externe
Introduction
La jointure est une opration qui entrane la perte de certains tuples : ceux qui appartiennent une des deux relations oprandes et qui n'ont pas de correspondance dans l'autre relation. Il est ncessaire dans certains cas de palier cette lacune, et l'on introduit pour cela la notion de jointure externe.
Dfinition : Jointure externe

La jointure externe entre R1 et R2 est une jointure qui produit une relation R3 laquelle on ajoute les tuples de R1 et de R2 exclus par la jointure, en compltant avec des valeurs nulles pour les attributs de l'autre relation.
Dfinition : Jointure externe gauche

La jointure externe gauche entre R1 et R2 est une jointure externe pour laquelle on ajoute seulement les tuples de R1 (c'est dire la relation de gauche) ayant t exclus. Synonymes : Jointure gauche
71
Dfinition : Jointure externe droite

La jointure externe droite entre R1 et R2 est une jointure externe pour laquelle on ajoute seulement les tuples de R2 (c'est dire la relation de droite) ayant t exclus. Bien entendu une jointure externe droite peut tre rcrite par une jointure externe gauche (et rciproquement) en substituant les relations oprandes R1 et R2. Synonymes : Jointure droite
Exemple
Soit les deux relations suivantes : Homme (Nom, Prnom, Age) Enfant (Nom, Prnom, Age) Soit les tuples suivants pour ces deux relations respectivement : (Dupont, Pierre, 20) (Durand, Jean, 30) (Dupont, Georges, 1) (Martin, Isabelle, 15) Soit l'opration suivante : R = JointureExterne (Homme, Enfant, Homme.Nom=Enfant.Nom) On obtient alors la relation R compose des tuples suivants : (Dupont, Pierre, 20, Dupont, Georges, 1) (Durand, Jean, 30, Null, Null, Null) (Null, Null, Null, Martin, Isabelle, 15) Une jointure externe gauche n'aurait renvoy que les deux premiers tuples et une jointure externe droite n'aurait renvoye que le premier et le troisime tuple.
9. Division
Dfinition : Division
La division est une opration binaire (c'est dire portant sur deux relations). La division de R1 par R2, sachant que R1 et R2 ont au moins un attribut commun (c'est dire de mme nom et de mme domaine), produit une relation R3 qui comporte les attributs appartenant R1 mais n'appartenant pas R2 et l'ensemble des tuples qui concatns ceux de R2 donnent toujours un tuple de R1.
Exemple
Soit les deux relations suivantes : Homme (Nom, Prnom, Mtier) Mtier (Metier) Soit les tuples suivants pour ces deux relations respectivement : (Dupont, Pierre, Ingnieur) (Dupont, Pierre, Professeur) (Durand, Jean, Ingnieur) (Ingnieur) (Professeur) Soit l'opration suivante : R = Division (Homme, Mtier)
72
On obtient alors la relation R compose des tuples suivants : (Dupont, Pierre)
Remarque : Rponse aux questions : Pour tous les ...

La division permet de rpondre aux questions du type : "Donnez toutes les personnes qui pratiquent tous les mtiers de la relation mtier".
Remarque : Opration additionnelle

La division n'est pas une opration de base, elle peut tre rcrite en combinant le produit, la restriction et la diffrence.
10. Proposition de notations

Introduction
Il existe plusieurs syntaxes pour crire des oprations d'algbre relationnelle, certaines inspires de l'algbre classiques, d'autres reposant sur des notations graphiques. Nous proposons une notation fonctionnelle qui a le mrite d'tre facile crire et d'tre lisible. Si cette notation peut parfois perdre en simplicit, lorsqu'elle concerne un nombre lev d'oprateurs, il est possible de dcomposer une opration complique afin de l'allger.
Syntaxe
R R R R R R R R R R R R = = = = = = = = = = = = Union (R1, R2) Diffrence (R1, R2) Intersection (R1, R2) Projection (R1, A1, A2, ...) Restriction (R1, condition) Produit (R1, R2) Jointure (R1, R2, condition) JointureNaturelle (R1, R2) JointureExterne (R1, R2, condition) JointureGauche (R1, R2, condition) JointureDroite (R1, R2, condition) Division (R1, R2)
Exemple : Notation synthtique

R = Projection( Restriction(R1, A1=1 AND A2=2), A3)
Exemple : Notation dcompose

R' = Restriction(R1, A1=1 AND A2=2) R = Projection (R', A3)
11. Exercice de synthse : Oprateurs de base et additionnels

Rcrivez les oprateurs additionnels suivants, partir d'oprateurs de base : Question 1
[Solution n1 p 173]
Rcrivez Intersection partir de Diffrence Question 2

[Solution n2 p 173]
Rcrivez Jointure partir de Produit et Restriction

73
Question 3
[Solution n3 p 173]
Rcrivez Division partir de Produit, Restriction et Difference
E. En rsum : Schma relationnel

Schma relationnel
Un schma relationnel permet une formalisation d'un modle logique. Relation ou table Sous-ensemble d'un produit cartsien Attribut ou colonne Prend ses valeurs dans un domaine Enregistrement ou ligne Pose une valeur (y compris la valeur "null") pour chaque attribut Cl Groupe d'attributs ayant un rle d'identification au sein d'un enregistrement Cl candidate Identifie de faon unique un enregistrement Cl primaire Cl candidate choisie pour reprsenter un enregistrement pour sa facilit d'usage Cl trangre Rfrence la cl primaire d'un tuple d'une autre relation pour exprimer un lien
F. Bibliographie commente sur le modle relationnel

Complment : Synthses
SQL2 SQL3, applications Oracle [Delmal01] Une dfinition synthtique et efficace du domaine relationnel : relation, domaine, attribut, cl, intgrit, oprateurs (Premier chapitre).
74
IV -
LE LANGAGE SQL
Qu'appelle-t-on SQL? Le Langage de Dfinition de Donnes de SQL
IV
95 96 103 105 115 119 122 123
Gestion avec le Langage de Manipulation de Donnes de SQL Questions avec le Langage de Manipulation de Donnes de SQL Instructions avances pour le LMD de SQL Le Langage de Contrle de Donnes de SQL En rsum : SQL Bibliographie commente sur le SQL
SQL est un langage standardis, implment par tous les SGBDR, qui permet, indpendamment de la plate-forme technologique et de faon dclarative, de dfinir le modle de donnes, de le contrler et enfin de le manipuler.
A. Qu'appelle-t-on SQL?
Dfinition : SQL
SQL (pour langage de requtes structur) est un langage dclaratif destin la manipulation de bases de donnes au sein des SGBD et plus particulirement des SGBDR. SQL est un langage dclaratif, il n'est donc pas a proprement parl un langage de programmation, mais plutt une interface standard pour accder aux bases de donnes. Il est compos de trois sous ensembles : Le Langage de Dfinition de Donnes (LDD, ou en anglais DDL Data Definition Language) pour crer et supprimer des objets dans la base de donnes (tables, contraintes d'intgrit, vues, etc.). Le Langage de Contrle de Donnes (LCD, ou en anglais DCL, Data Control Language) pour grer les droits sur les objets de la base (cration des utilisateurs et affectation de leurs droits). Le Langage de Manipulation de Donnes (LMD, ou en anglais DML, Data Manipulation Language) pour la recherche, l'insertion, la mise jour et la suppression de donnes. Le LMD est bas sur les oprateurs relationnels, auxquels sont ajouts des fonctions de calcul d'agrgats et des instructions pour raliser les oprations d'insertion, mise jour et suppression.
Complment : Origine du SQL

Le modle relationnel a t invent par E.F. Codd (Directeur de recherche du centre IBM de San Jos) en 1970, suite quoi de nombreux langages ont fait leur apparition : IBM Sequel (Structured English Query Language) en 1977
75
Le langage SQL
IBM Sequel/2 IBM System/R IBM DB2 Ce sont ces langages qui ont donn naissance au standard SQL, normalis en 1986 au tats-Unis par l'ANSI pour donner SQL/86 (puis au niveau international par l'ISO en 1987).

Complment : Versions de SQL

SQL-86 (ou SQL-87) : Version d'origine SQL-89 (ou SQL-1) : Amliorations mineures SQL-92 (ou SQL-2) : Extensions fonctionnelles majeures (types de donnes, oprations relationnelles, instruction LDD, transactions, etc. SQL-99 (ou SQL-3) : Introduction du PSM (couche procdurale sous forme de procdure stockes) et du RO SQL-2003 : Extensions XML SQL-2006 : Amliorations mineures (pour XML notamment) SQl-2008 : Amliorations mineures (pour le RO notamment)
Remarque : Version SQL et implmentations SGBD

Selon leur niveau d'implmentation de SQL, les SGBD acceptent ou non certaines fonctions. Certains SGBD ayant entam certaines implmentations avant leur standardisation dfinitive, ces implmentations peuvent diffrer de la norme.
B. Le Langage de Dfinition de Donnes de SQL

Objectifs
Matriser les bases du SQL pour crer et modifier des tables et des vues,
Le LDD permet de crer les objets composant une BD de faon dclarative. Il permet notamment la dfinition des schmas des relations, la dfinition des contraintes d'intgrit, la dfinition de vues relationnelles.
1. Types de donnes
Introduction
Un attribut d'une relation est dfini pour un certain domaine. On peut galement dire qu'il est d'un type particulier. Les types de donnes disponibles en SQL varient d'un SGBD l'autre, on peut nanmoins citer un certain nombre de types standards que l'on retrouve dans tous les SGBD.
a) Les types numriques
Les nombres entiers INTEGER(X), o X est optionnel et dsigne le nombre de chiffres maximum pouvant composer le nombre. Il existe galement un certain nombre de variantes permettant de dfinir des entiers plus ou moins volumineux, tels que TINYINT, SMALLINT ou LONGINT. Les nombres dcimaux DECIMAL(X,Y), o X et Y sont optionnels et dsignent respectivement le nombre de chiffres
76
Le langage SQL
maximum pouvant composer le nombre avant et aprs la virgule. NUMERIC est galement utilis de faon quivalente. Les nombres virgule flottante REAL(X,Y), avec X et Y optionnels et dfinissant le nombre de chiffres avant et aprs la virgule. Il existe galement un certain nombre de variantes permettant de dfinir une prcision plus grande, telles que DOUBLE.
b) Les types chane de caractres

On distingue principalement les types CHAR(X) et VARCHAR(X), o X et obligatoire et dsigne la longueur de la chane. CHAR dfinit des chanes de longueur fixe (complte droites par des espaces, si la longeur est infrieure X) et VARCHAR des chanes de longueurs variables. CHAR et VARCHAR sont gnralement limits 255 caractres. La plupart des SGBD proposent des types, tels que TEXT ou CLOB (Character Long Object), pour reprsenter des chanes de caractres longues, jusqu' 65000 caractres par exemple.
c) Les types date

Les types date dont introduits avec la norme SQL2. On distingue le type DATE qui reprsente une date selon un format de type "AAAA-MM-JJ" et le types DATETIME qui reprsente une date avec un horaire, dans un format tel que "AAAA-MM-JJ HH:MM:SS". Il existe galement des restrictions de ces types, tels que YEAR, TIME, etc.
d) Les autres types

En fonction du SGBD, il peut exister de nombreux autres types. On peut citer par exemple les types montaires pour reprsenter des dcimaux associs une monnaie, les types ENUM pour reprsenter des numrations, les types BLOB (pour Binary Long Oject) pour reprsenter des donnes binaires tels que des documents multimdia (images bitmap, vido, etc.).
e) Le type absence de valeur

L'absence de valeur, reprsente par la valeur NULL, est une information fondamentale en SQL, qu'il ne faut pas confondre avec la chane espace de caractre o bien la valeur 0. Il ne s'agit pas d'un type proprement parler, mais d'une valeur possible dans tous les types.
2. Cration de tables
Introduction
La cration de table est le fondement de la cration d'une base de donnes en SQL.
Dfinition : Cration de table

La cration de table est la dfinition d'un schma de relation en intension, par la spcification de tous les attributs le composant avec leurs domaines respectifs.
Syntaxe
CREATE TABLE <nom de table> ( <nom colonne1> <type colonne1>, <nom colonne2> <type colonne2>, ... <nom colonneN> <type colonneN>, );
77
Le langage SQL
Exemple
CREATE TABLE Personne ( Nom VARCHAR(25), Prenom VARCHAR(25), Age INTEGER(3) );
Attention : Contrainte d'intgrit

La dfinition des attributs n'est pas suffisante pour dfinir un schma relationnel, il faut lui adjoindre la dfinition de contraintes d'intgrit, qui permette de poser les notions de cl, d'intgrit rfrentielle, de restriction de domaines, etc.
3. Contraintes d'intgrit
Dfinition : Contraintes d'intgrit
Une contrainte d'intgrit est une rgle qui dfinit la cohrence d'une donne ou d'un ensemble de donnes de la BD. Il existe deux types de contraintes : sur une colonne unique, ou sur une table lorsque la contrainte porte sur une ou plusieurs colonnes. Les contraintes sont dfinies au moment de la cration des tables. Les contraintes d'intgrit sur une colonne sont : PRIMARY KEY : dfinit l'attribut comme la cl primaire NOT NULL : interdit l'absence de valeur pour l'attribut UNIQUE : interdit que deux tuples de la relation aient la mme valeur pour l'attribut. REFERENCES <nom table> (<nom colonnes>) : contrle l'intgrit rfrentielle entre l'attribut et la table et ses colonnes spcifies CHECK (<condition>) : contrle la validit de la valeur de l'attribut spcifi dans la condition dans le cadre d'une restriction de domaine Les contraintes d'intgrit sur une table sont : PRIMARY KEY (<liste d'attibuts>) : dfinit les attributs de la liste comme la cl primaire UNIQUE (<liste d'attibuts>) : interdit que deux tuples de la relation aient les mmes valeurs pour l'ensemble des attributs de la liste. FOREIGN KEY (<liste d'attibuts>) REFERENCES <nom table>(<nom colonnes>) : contrle l'intgrit rfrentielle entre les attributs de la liste et la table et ses colonnes spcifies CHECK (<condition>) : contrle la validit de la valeur des attributs spcifis dans la condition dans le cadre d'une restriction de domaine
Syntaxe
CREATE TABLE <nom de table> ( <nom colonne1> <type colonne1> <contraintes colonne1>, <nom colonne2> <type colonne2> <contraintes colonne2>, ... <nom colonneN> <type colonneN> <contraintes colonneN>, <contraintes de table> );
Remarque : Cl candidate
La contrainte UNIQUE NOT NULL sur un attribut ou un groupe d'attributs dfinit une cl candidate non primaire.
78
Le langage SQL
Remarque
Les contraintes sur une colonne et sur une table peuvent tre combines dans la dfinition d'un mme schma de relation. Une contrainte sur une colonne peut toujours tre remplace par une contrainte sur une table.
Exemple
CREATE TABLE Personne ( NSS CHAR(13) PRIMARY KEY, Nom VARCHAR(25) NOT NULL, Prenom VARCHAR(25) NOT NULL, Age INTEGER(3) CHECK (Age BETWEEN 18 AND 65), Mariage CHAR(13) REFERENCES Personne(NSS), Codepostal INTEGER(5), Pays VARCHAR(50), UNIQUE (Nom, Prenom), FOREIGN KEY (Codepostal, Pays) REFERENCES Adresse (CP, Pays) ); CREATE TABLE Adresse ( CP INTEGER(5) NOT NULL, Pays VARCHAR(50) NOT NULL, Initiale CHAR(1) CHECK (Initiale = LEFT(Pays, 1)), PRIMARY KEY (CP, Pays) ); Dans la dfinition de schma prcdente on a pos les contraintes suivantes : La cl primaire de Personne est NSS et la cl primaire de Adresse est (CP, Pays). Nom, Prnom ne peuvent pas tre null et (Nom, Prnom) est une cl. Age doit tre compris entre 18 et 65 et Initiale doit tre la premire lettre de Pays (avec la fonction LEFT qui renvoie la sous chane gauche de la chane passe en premier argument, sur le nombre de caractres passs en second argument) Mariage est cl trangre vers Personne et (Codepostal, Pays) est une cl trangre vers Adresse.
4. Cration de vues
Dfinition : Vue
Une vue est une dfinition logique d'une relation, sans stockage de donnes, obtenue par interrogation d'une ou plusieurs tables de la BD. Une vue peut donc tre perue comme une fentre dynamique sur les donnes, ou encore une requte stocke (mais dont seule la dfinition est stocke, pas le rsultat, qui reste calcul dynamiquement). Une vue permet d'implmenter le concept de schma externe d'un modle conceptuel. Synonymes : Relation drive, Table virtuelle calcule
Syntaxe
CREATE VIEW <nom de vue> <nom des colonnes> AS <spcification de question> La spcification d'une question se fait en utilisant le LMD. Le nombre de colonnes nommes doit tre gal au nombre de colonnes renvoyes par la question spcifie. Le nom des colonnes est optionnel, s'il n'est pas spcifi, c'est le nom des colonnes telle qu'elles sont renvoyes par la question, qui sera utilis.
79
Le langage SQL
Exemple
CREATE VIEW Employe (Id, Nom) AS SELECT NSS, Nom FROM Personne La vue Employe est ici une projection de la relation Personne sur les attributs NSS et Nom, renomms respectivement Id et Nom.
Remarque : Vue en lecture et vue en criture

Une vue est toujours disponible en lecture, condition que l'utilisateur ait les droits spcifis grce au LCD. Une vue peut galement tre disponible en criture dans certains cas, que l'on peut restreindre aux cas o la question ne porte que sur une seule table (mme si dans certains cas, il est possible de modifier une vue issue de plusieurs tables). Dans le cas o une vue est destine tre utilise pour modifier des donnes, il est possible d'ajouter la clause "WITH CHECK OPTION" aprs la spcification de question, pour prciser que les donnes modifies ou ajoutes doivent effectivement appartenir la vue.
Remarque : Vue sur une vue

Une vue peut avoir comme source une autre vue.
Rappel : Vues et hritage

Les vues sont particulirement utiles pour restituer les relations d'hritage perdues lors de la transformation MCD vers MLD.
5. Suppression d'objets
Il est possible de supprimer des objets de la BD, tels que les tables ou les vues.
Syntaxe
DROP <type objet> <nom objet>
Exemple
DROP TABLE Personne; DROP VIEW Employe;
6. Modification de tables
Introduction
L'instruction ALTER TABLE permet de modifier la dfinition d'une table (colonnes ou contraintes) pralablement cre. Cette commande absente de SQL-89 est normalise dans SQL-92
Syntaxe : Ajout de colonne

ALTER TABLE <nom de table> ADD (<dfinition de colonne>);
80
Le langage SQL
Syntaxe : Suppression de colonne

ALTER TABLE <nom de table> DROP (<nom de colonne>);
Syntaxe : Modification de colonne

ALTER TABLE <nom de table> MODIFY (<redfinition de colonne>);
Syntaxe : Ajout de contrainte

ALTER TABLE <nom de table> ADD (<dfinition de contrainte de table>);
Remarque : Modification de table sans donne sans la commande ALTER

Pour modifier une table ne contenant pas encore de donne, la commande ALTER n'est pas indispensable, l'on peut supprimer la table modifier (DROP) et la recrer telle qu'on la souhaite. Notons nanmoins que si la table est rfrence par des clauses FOREIGN KEY, cette suppression sera plus complique, car il faudra galement supprimer et recrer les tables rfrenantes (ce qui ce complique encore si ces dernires contiennent des donnes).
Remarque : Modification de table avec donnes sans la commande ALTER

Pour modifier une table contenant des donnes, la commande ALTER n'est pas absolument indispensable. On peut en effet : 1. Copier les donnes dans une table temporaire de mme schma que la table modifier 2. Supprimer et recrer la table modifier avec le nouveau schma 3. Copier les donnes depuis la table temporaire vers la table modifie
7. Exemple de modifications de tables

a) Table initiale
Soit une table intiale telle que dfinie ci-aprs. create table t_personnes ( pk_n number (4), nom varchar(50), prenom varchar (50), PRIMARY KEY (pk_n) );
b) Modifications
On dcide d'apporter les amnagements suivants la table : on passe la taille du champ "nom" de 50 255 caractres maximum, on dfinit "nom" comme UNIQUE et on supprime le champ "prenom". alter table t_personnes modify (nom varchar(255)); alter table t_personnes add (UNIQUE (nom)); alter table t_personnes
81
Le langage SQL
drop (prenom);
c) Table finale
La table obtenue aprs modification est identique la table qui aurait t dfinie directement telle que ciaprs. create table t_personnes ( pk_n number (4), nom varchar(255), PRIMARY KEY (pk_n), UNIQUE (nom) );
C. Gestion avec le Langage de Manipulation de Donnes de SQL

Objectifs
Matriser les bases du SQL pour entrer, modifier et effacer des donnes dans les tables.
1. Insertion de donnes
Le langage SQL fournit galement des instructions pour ajouter des nouveaux tuples une relation. Il offre ainsi une interface standard galement pour ajouter des information dans une base de donnes. Il existe deux moyens d'ajouter des donnes, soit par fourniture directe des valeurs des proprits du tuple ajouter, soit par slection des tuples ajouter dans une autre relation.
Syntaxe : Insertion directe de valeurs

INSERT INTO <Nom de la relation> (<Liste ordonne des proprits valoriser>) VALUES (<Liste ordonne des valeurs affecter aux proprits spcifies ci-dessus>)
Exemple : Insertion directe de valeurs

INSERT INTO Virement (Date, Montant, Objet) VALUES (14-07-1975, 1000, 'Prime de naissance');
Syntaxe : Insertion de valeurs par l'intermdiaire d'une slection

INSERT INTO <Nom de la relation> (<Liste ordonne des proprits valoriser>) SELECT ... L'instruction SELECT projetant un nombre de proprits identiques aux proprits valoriser.
Exemple : Insertion de valeurs par l'intermdiaire d'une slection

INSERT INTO Credit (Date, Montant, Objet)
82
Le langage SQL
SELECT Date, Montant, 'Annulation de dbit' FROM Debit WHERE Debit.Date = 25-12-2001; Dans cet exemple tous les dbits effectus le 25 dcembre 2001, sont recrdits pour le mme montant (et la mme date), avec la mention annulation dans l'objet du crdit. Ceci pourrait typiquement ralis en cas de dbits errrons ce jour l.
Remarque
Les proprits non valorises sont affectes la valeur null. Il est possible de ne pas spcifier les proprits valoriser, dans ce cas, toutes les proprits de la relation seront considres, dans leur ordre de dfinition dans la relation ( n'utiliser que dans les cas les plus simples).
2. Mise jour de donnes

Le langage SQL fournit une instruction pour modifier des tuples existants dans une relation.
Syntaxe : Mise jour directe de valeurs

UPDATE <Nom de la relation> SET <Liste d'affectation Proprit=Valeur> WHERE <Condition pour filtrer les tuples mettre jour>
Exemple : Mise jour directe de valeurs

UPDATE Compte SET Monnaie='Euro' WHERE Monnaie='Franc'
Exemple : Mise jour par calcul sur l'ancienne valeur

UPDATE Compte SET Total=Total * 6,55957 WHERE Monnaie='Euro'
3. Suppression de donnes
Le langage SQL fournit une instruction pour supprimer des tuples existants dans une relation.
Syntaxe
DELETE FROM <Nom de la relation> WHERE <Condition pour filtrer les tuples supprimer>
Exemple : Suppression de tous les tuples d'une relation

DELETE FROM FaussesFactures
Exemple : Suppression slective

DELETE FROM FaussesFactures WHERE Auteur='Moi'
83
Le langage SQL
D. Questions avec le Langage de Manipulation de Donnes de SQL

Objectifs
Matriser les bases du SQL pour crire des questions exigeant des jointures, projections, restriction, des tris et des agrgats.
1. Slection
Introduction
La requte de slection ou question est la base de la recherche de donnes en SQL.
Dfinition : Slection
La selection est la composition d'un produit cartsien, d'une restriction et d'une projection (ou encore la composition d'une jointure et d'une projection).
Syntaxe
SELECT <liste d'attributs projets> FROM <liste de relations> WHERE <condition> La partie SELECT indique le sous-ensemble des attributs qui doivent apparatre dans la rponse (c'est le schma de la relation rsultat). La partie FROM dcrit les relations qui sont utilisables dans la requte (c'est dire l'ensemble des attributs que l'on peut utiliser). La partie WHERE exprime les conditions que doivent respecter les attributs d'un tuple pour pouvoir tre dans la rponse. Une condition est un prdicat et par consquent renvoie un boolen. Cette partie est optionnelle. Afin de dcrire un attribut d'une relation dans le cas d'une requte portant sur plusieurs relations, on utilise la notation "RELATION.ATTRIBUT".
Exemple
SELECT Nom, Prenom FROM Personne WHERE Age>18 Cette requte slectionne les attributs Nom et Prenom des tuples de la relation Personne, ayant un attribut Age suprieur 18.
Exemple
SELECT Parent.Prenom, Enfant.Prenom FROM Parent, Enfant WHERE Enfant.Nom=Parent.Nom Cette requte slectionne les prnoms des enfants et des parents ayant le mme nom. On remarque la notation Parent.Nom et Enfant.Nom pour distinguer les attributs Prenom des relations Parent et Enfant. On notera que cette slection effectue une jointure sur les proprits Nom des relations Parent et Enfant.
Remarque : SELECT *
Pour projeter l'ensemble des attributs d'une relation, on peut utiliser le caractre "*" la place de la liste des attributs projeter.
84
Le langage SQL
Exemple
SELECT * FROM Avion Cette requte slectionne tous les attributs de la relation Avion. Notons que dans cet exemple, la relation rsultat est exactement la relation Avion
Remarque : SELECT DISTINCT

L'oprateur SELECT n'limine pas les doublons (i.e. les tuples identiques dans la relation rsultat) par dfaut. Il faut pour cela utiliser l'oprateur "SELECT DISTINCT".
Exemple
SELECT DISTINCT Avion FROM Vol WHERE Date=31-12-2000 Cette requte slectionne l'attribut Avion de la relation Vol, concernant uniquement les vols du 31 dcembre 2000 et renvoie les tuples dans doublons.
Remarque : Renommage de proprit

Il est possible de redfinir le nom des proprits de la relation rsultat. Ainsi "SELECT p AS p' FROM relation" renvoie une relation ayant comme proprit p'. Cette possibilit est offerte partir de SQL2 (niveau entre).
Remarque : Projection de constante

Il est possible de projeter directement des constantes. Ainsi "SELECT 'Bonjour' AS Essai" renverra un tuple avec une proprit Essai la valeur 'Bonjour'.
2. Oprateurs de comparaisons et oprateurs logiques

Introduction
La clause WHERE d'une instruction de slection est dfinie par une condition. Une telle condition s'exprime l'aide d'oprateurs de comparaison et d'oprateurs logiques. Le rsultat d'une expression de condition est toujours un boolen.
Dfinition : Condition
Condition Elmentaire ::= Proprit <Oprateur de comparaison> Constante Condition ::= Condition <Oprateur logique> Condition | Condition Elmentaire Les oprateurs de comparaison sont : P=C P <> C P<C P>C P <= C P >= C P BETWEEN C1 AND C2 P LIKE 'chane'
85
Le langage SQL
P IN (C1, C2, ...) P IS NULL Les oprateur logique sont : OR AND NOT

Remarque : Oprateur LIKE

L'oprateur LIKE 'chane' permet d'insrer des jokers dans l'opration de comparaison (alors que l'oprateur = teste une galit stricte) : Le joker % dsigne 0 ou plusieurs caractres quelconques Le joker _ dsigne 1 et 1 seul caractre On prfrera l'oprateur = l'oprateur LIKE lorsque la comparaison n'utilise pas de joker.
3. Expression du produit cartsien

Syntaxe
SELECT * FROM R1, R2, Ri
4. Expression d'une projection

Syntaxe
SELECT P1, P2, Pi FROM R
5. Expression d'une restriction

Syntaxe
SELECT * FROM R WHERE <condition>
6. Expression d'une jointure

Syntaxe : Jointure par la clause WHERE
En tant que composition d'un produit cartsien et d'une restriction la jointure s'crit alors : SELECT * FROM R1, R2, Ri WHERE <condition> Avec Condition permettant de joindre des attributs des Ri
Syntaxe : Jointure par la clause ON

On peut galement utiliser la syntaxe ddie suivante : SELECT * FROM R1 INNER JOIN R2
86
Le langage SQL
ON <condition> Et pour plusieurs relations : SELECT * FROM (R1 INNER JOIN R2 ON <condition>) INNER JOIN Ri ON <condition>
Exemple : Une jointure naturelle

SELECT * FROM R1, R2 WHERE R2.NUM = R1.NUM
Remarque : Auto-jointure
Pour raliser une auto-jointure, c'est dire la jointure d'une relation avec elle-mme, on doit utiliser le renommage des relations. Pour renommer une relation, on note dans la clause FROM le nom de renommage aprs le nom de la relation : "FROM NOM_ORIGINAL NOUVEAU_NOM".
Exemple : Auto-jointure
SELECT E1.Nom FROM Employe E1, Employe E2 WHERE E1.Nom= E2.Nom
Remarque : Jointure externe gauche ou droite

Pour exprimer une jointure externe on se base sur la syntaxe INNER JOIN en utilisant la place LEFT OUTER JOIN ou RIGHT OUTER JOIN.
Exemple : Jointure externe gauche

SELECT Num FROM Avion LEFT OUTER JOIN Vol ON Avion.Num=Vol.Num Cette requte permet de slectionner tous les avions, y compris ceux non affects un vol.
Remarque
Remarquons que "Avion LEFT OUTER JOIN Vol" est quivalent "Vol RIGHT OUTER JOIN Avion" en terme de rsultat. Intuitivement, on prfre utiliser la jointure gauche pour slectionner tous les tuple du ct N d'une relation 1:N, mme si il ne sont pas rfrencs ; et la jointure droite pour pour slectionner tous les tuples d'une relation 0:N, y compris ceux qui ne font pas de rfrence. Cette approche revient toujours garder gauche de l'expression "JOIN" la relation "principale", i.e. celle dont on veut tous les tuples, mme s'ils ne rfrencent pas (ou ne sont pas rfrencs par) la relation "secondaire".
7. Oprateurs ensemblistes
Introduction
Les oprateurs ensemblistes ne peuvent tre exprims l'aide de l'instruction de slection seule.
Syntaxe : Union
SELECT * FROM R1
87
Le langage SQL
UNION SELECT * FROM R2
Syntaxe : Intersection
SELECT * FROM R1 INTERSECT SELECT * FROM R2
Syntaxe : Diffrence
SELECT * FROM R1 EXCEPT SELECT * FROM R2
Remarque
Les oprations INTERSECT et EXCEPT n'existe que dans la norme SQL2, et non dans la norme SQL1. Certain SGBD sont susceptibles de ne pas les implmenter.
8. Tri
Introduction
On veut souvent que le rsultat d'une requte soit tri en fonction des valeurs des proprits des tuples de ce rsultat.
Syntaxe : ORDER BY
SELECT <liste d'attributs projets> FROM <liste de relations> WHERE <condition> ORDER BY <liste ordonne d'attributs> Les tuples sont tris d'abord par le premier attribut spcifi dans la clause ORDER BY, puis en cas de doublons par le second, etc.
Remarque : Tri dcroissant

Pour effectuer un tri dcroissant on fait suivre l'attribut du mot cl "DESC".
Exemple
SELECT * FROM Personne ORDER BY Nom, Age DESC
9. Fonctions de calcul
Dfinition : Fonction de calcul
Une fonction de calcul s'applique l'ensemble des valeurs d'une proprit d'une relation avec pour rsultat la production d'une valeur atomique unique (entier, chane, date, etc). Les cinq fonctions prdfinies sont : Count(Relation.Proprit) Renvoie le nombre de valeurs non nulles d'une proprit pour tous les tuples d'une relation ; Sum(Relation.Proprit)
88
Le langage SQL
Renvoie la somme des valeurs d'une proprit des tuples (numriques) d'une relation ; Avg(Relation.Proprit) Renvoie la moyenne des valeurs d'une proprit des tuples (numriques) d'une relation ; Min(Relation.Proprit) Renvoie la plus petite valeur d'une proprit parmi les tuples d'une relation . Max(Relation.Proprit) Renvoie la plus grande valeur d'une proprit parmi les tuples d'une relation.
Syntaxe
SELECT <liste de fonctions de calcul> FROM <liste de relations> WHERE <condition appliquer avant calcul>
Exemple
SELECT Min(Age), Max(Age), Avg(Age) FROM Personne WHERE Qualification='Ingnieur'
Remarque : Utilisation de fonctions pour les agrgats

Dans le cas du calcul d'un agrgat, les fonctions peuvent tre utilises dans la claude HAVING ou dans la clause ORDER BY d'un tri. Les fonctions ne peuvent pas tre utilises dans la clause WHERE.
Remarque : Comptage d'une relation

Pour effectuer un comptage sur tous les tuples d'une relation, appliquer la fonction Count un attribut de la cl primaire. En effet cet attribut tant non nul par dfinition, il assure que tous les tuples seront compts.
10. Agrgats
Dfinition : Agrgat
Un agrgat est un partitionnement horizontal d'une table en sous-tables, en fonction des valeurs d'un ou plusieurs attributs de partitionnement, suivi de l'application d'une fonction de calcul chaque attribut des sous-tables obtenues.
Syntaxe
SELECT <liste d'attributs de partionnement projeter et de fonctions de calcul> FROM <liste de relations> WHERE <condition appliquer avant calcul de l'agrgat> GROUP BY <liste ordonne d'attributs de partitionnement> HAVING <condition sur les fonctions de calcul>
Exemple
SELECT Societe.Nom, AVG(Personne.Age) FROM Personne, Societe WHERE Personne.NomSoc = Societe.Nom GROUP BY Societe.Nom HAVING Count(Personne.NumSS) > 10 Cette requte calcul l'ge moyen du personnel pour chaque socit comportant plus de 10 salaris.
89
Le langage SQL
Remarque : Restriction
Une restriction peut tre applique avant calcul de l'agrgat, au niveau de la clause WHERE, portant ainsi sur la relation de dpart, mais aussi aprs calcul de l'agrgat sur les rsultats de ce dernier, au niveau de la clause HAVING.
Remarque : Projection
Si dans la clause SELECT, un attribut est projet directement, sans qu'une fonction lui soit applique, alors il faut imprativement que cet attribut apparaisse dans la clause GROUP BY (car ce ne peut tre qu'un attribut de partitionnement).
Remarque : Fonctions de calcul sans partitionnement

Si une ou plusieurs fonctions de calcul sont appliques sans partitionnement, le rsultat de la requte est un tuple unique.
Remarque : Intrt de la clause GROUP BY

Pour que l'utilisation de la clause GROUP BY ait un sens, il faut qu'au moins une fonction de calcul soit utilise, soit dans la clause SELECT, soit dans la clause HAVING.
Remarque : Contrle impos par quelques SGBDR

Notons que dans le cas de certains SGBDR (par exemple Oracle), l'ensemble des attributs de l'agrgation (clause GROUP BY) doivent tre pralablement projets (donc dclars dans la clause SELECT).
E. Instructions avances pour le LMD de SQL

Objectifs
tre capable d'apprendre des notions particulires de SQL lis un SGBD en particulier ou des volutions futures de SQL.
1. Requtes imbriques
Introduction
Il est possible d'imbriquer des requtes les unes dans les autres pour procduraliser les questions, et ainsi rpondre des questions plus complexes, voire impossibles, crire en algbre relationnel classique.
Dfinition : Sous-requte
Requte incluse dans la clause WHERE ou FROM d'une autre requte. Synonymes : Sous-question, Requte imbrique
Syntaxe : Requtes imbriques par la clause WHERE

SELECT <projections> FROM <relations> WHERE <sous-requte>
90
Le langage SQL
Exemple
SELECT Nom FROM Chercheur WHERE Nom IN (SELECT Nom FROM Enseignant)
2. Sous-requte d'existence IN
Introduction
Cette sous-requte permet de vrifier que la projection d'un tuple de la requte principale est prsent dans la sous-requte.
Syntaxe
SELECT <projections> FROM <relations> WHERE (<projection d'un tuple>) IN (<requte imbrique>) La projection du tuple de la requte principale doit conduire un schma relationnel identique celui de la requte imbrique.
Exemple : Sous-requte IN une colonne et plusieurs lignes

SELECT Chercheur.Nom FROM Chercheur WHERE Chercheur.Universite IN (SELECT Universite.Nom FROM Universite WHERE Universite.Ville='Paris')
Exemple : Sous-requte IN plusieurs colonnes et plusieurs lignes

SELECT NSS FROM Chercheur WHERE (Nom, Prenom, Age) IN (SELECT Nom, Prenom, Age FROM Enseignant)
Exemple : Imbrication multiple de requtes

SELECT Nom FROM Chercheur WHERE Universite='Paris6' AND Nom IN (SELECT Nom FROM Enseignant WHERE Universite IN (SELECT Nom FROM Universite WHERE Ville='Paris'))
Remarque : Jointure par la sous-requte IN

La sous-requte IN est une troisime voie, avec les clauses WHERE et JOIN, pour raliser des jointures entre relations. On prfrera nanmoins viter d'utiliser cette unique fin cette version plus procdurale.
91
Le langage SQL
Remarque : NOT IN
On peut tester la non existence du tuple dans la sous requte en utilisant la clause NOT IN la place de la clause IN.
3. Sous-requte d'existence EXISTS

Introduction
Cette sous-requte permet de vrifier que la sous-requte contient au moins un tuple.
Syntaxe
SELECT <projections> FROM <relations> WHERE EXISTS (<requte imbrique>) La requte imbrique faisant rfrence des proprits (ventuellement non projetes) de la requte principale.
Exemple
SELECT Chercheur.Nom FROM Chercheur WHERE EXISTS (SELECT * FROM Universite WHERE Universite.Nom=Chercheur.Universite)
Remarque : Projection dans la sous-requte

Puisque la sous-requte n'est destine qu' valider l'existence d'un tuple, il est inutile de procder une projection particulire pour cette sous-requte. On utilise donc en gnral la clause SELECT * pour une sous-requte avec une clause EXISTS.
Remarque : NOT EXISTS

On peut tester la non prsence de tuple dans la sous-requte en utilisant la clause NOT EXISTS la place de la clause EXISTS.
4. Sous-requte de comparaison ALL

Introduction
Cette sous-requte permet de vrifier que les tuples de la requte principale vrifient bien une condition donne avec tous les tuples de la sous-requte.
Syntaxe
SELECT <projections> FROM <relations> WHERE <proprit> <oprateur de comparaison> ALL (<requte imbrique>) La requte imbrique renvoyant un tuple ne comportant qu'une proprit de mme domaine que la proprit teste de la requte principale.
92
Le langage SQL
Exemple
SELECT Nom FROM Chercheur WHERE Age > ALL (SELECT Age FROM Etudiant)
5. Sous-requte de comparaison ANY

Introduction
Cette sous-requte permet de vrifier que les tuples de la requte principale vrifie bien une condition donne avec au moins un tuple de la sous-requte.
Syntaxe
SELECT <projections> FROM <relations> WHERE <proprit> <oprateur de comparaison> ANY (<requte imbrique>) La requte imbrique renvoyant un tuple ne comportant qu'une proprit de mme domaine que la proprit teste de la requte principale.
Exemple
SELECT Nom FROM Chercheur WHERE Age < ANY (SELECT Age FROM Etudiant)
Remarque : SOME
SOME peut tre utilis comme un synonyme de ANY.
6. Raffinement de questions dans la clause FROM

Il est possible de raffiner progressivement une requte en enchanant les questions dans la clause FROM.
Syntaxe
SELECT ... FROM (SELECT ... FROM ... WHERE ...) WHERE ...)
Remarque
Il est possible d'enchaner rcursivement N questions.
Mthode
Cette extension est particulirement utile pour les calculs d'agggat aprs filtrage ou pour enchaner les calculs d'aggrgat (par exemple pour faire la moyenne de sommes aprs regroupement).
Exemple : Enchanement de calculs d'aggrgat

select avg(s) from (select sum(b) as s from t group by a)
93
Le langage SQL
F. Le Langage de Contrle de Donnes de SQL

Objectifs
Matriser les bases du SQL pour attribuer et rvoquer des droits sur des objets d'une base de donnes.
Le LCD permet de crer les utilisateurs et de dfinir leurs droits sur les objets de la BD de faon dclarative. Il permet notamment l'attribution et la rvocation de droits des utilisateurs, sur l'ensemble des bases du SGBD, sur une BD en particulier, sur des relations d'une BD, voire sur certains attributs seulement d'une relation.
1. Attribution de droits
SQL propose une commande pour attribuer des droits des utilisateurs sur des tables.
Syntaxe
GRANT <liste de droits> ON <nom table> TO <utilisateur> [WITH GRANT OPTION] Les droits disponibles renvoient directement aux instructions SQL que l'utilisateur peut excuter : SELECT INSERT DELETE UPDATE ALTER De plus il est possible de spcifier 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 prciser que l'utilisateur a le droit de transfrer ses propres droits sur la table d'autres utilisateur. Une telle clause permet une gestion dcentralise de l'attribution des droits et non reposant uniquement dans les mains d'un administrateur unique. La spcification PUBLIC la place d'un nom d'utilisateur permet de donner les droits spcifis tous les utilisateurs de la BD.
Exemple
GRANT SELECT, UPDATE ON Personne TO Pierre; GRANT ALL PRIVILEGES ON Adresse TO PUBLIC;
Remarque : Droits sur un SGBD

Certains SGBD permettent de spcifier des droits au niveau du SGBD, c'est dire pour toutes les tables de toutes les BD du SGBD. La syntaxe dans le cas de MySQL est "*.*" la place du nom de la table. Dans ce cas les droits CREATE et DROP sont gnralement ajouts pour permettre ou non aux utilisateurs de crer et supprimer des BD et des tables.
Remarque : Droits sur une BD

Certains SGBD permettent de spcifier des droits au niveau d'une BD, c'est dire pour toutes les tables
94
Le langage SQL
de cette base de donnes. La syntaxe dans le cas de MySQL est "nom_bd.*" la place du nom de la table. Dans ce cas les droits CREATE et DROP sont gnralement ajouts pour permettre ou non aux utilisateurs de crer et supprimer des tables sur cette BD.
Remarque : Droits sur une vue

Il est possible de spcifier des droits sur des vues plutt que sur des tables, avec une syntaxe identique (et un nom de vue la place d'un nom de table).
Remarque : Catalogue de donnes

Les droits sont stocks dans le catalogue des donnes, il est gnralement possible de modifier directement ce catalogue la place d'utiliser la commande GRANT. Cela reste nanmoins dconseill.
Remarque : Cration des utilisateurs

Les modalits de cration d'utilisateurs, voire de groupes d'utilisateurs dans le SGBD, reste dpendantes de celui-ci. Des commande SQL peuvent tre disponibles, telles que CREATE USER, ou bien la commande GRANT lorsque qu'elle porte sur un utilisateur non existant peut tre charge de crer cet utilisateur. Des modules spcifiques d'administration sont gnralement disponibles pour prendre en charge la gestion des utilisateurs.
2. Rvocation de droits
SQL propose une commande pour rvoquer les droits attribus des utilisateurs.
Syntaxe
REVOKE <liste de droits> ON <nom table> FROM <utilisateur>
Exemple
REVOKE SELECT, UPDATE ON Personne TO Pierre; REVOKE ALL PRIVILEGES ON Adresse TO PUBLIC;
Remarque : Rvocation du droit de donner les droits

Pour retirer les droits de donner les droits un utilisateur (qui l'a donc obtenu par la clause WITH GRANT OPTION), il faut utiliser la valeur GRANT OPTION dans la liste des droits rvoqus.
Remarque : Rvocation en cascade

Lorsque qu'un droit est supprim pour un utilisateur, il l'est galement pour tous les utilisateurs qui avait obtenu ce mme droit par l'utilisateur en question.
G. En rsum : SQL
Langage SQL
Le langage SQL permet la cration, le contrle et la manipulation d'une BD. LDD Permet de crer, modifier et supprimer les objets d'une BD CREATE TABLE CREATE VIEW LCD Permet de dfinir les droits des utilisateurs sur les objets de la BD
95
Le langage SQL
GRANT REVOKE LMD Permet d'entrer et sortir des donnes dans la BD INSERT, UPDATE, DELETE SELECT
-
H. Bibliographie commente sur le SQL

Complment : Exerciseur faire
Tutoriel SQL [w_univ-lyon2.fr/~jdarmont] Un excellent exerciseur permettant de poser des questions en SQL une base de donnes en temps rel. 18 questions faire absolument.
Complment : Pour continuer de s'exercer

Initiation SQL : Cours et exercices corrigs [Pratt01] Un ensemble d'exemples, de questions/rponses, de how-to, et d'exercices corrigs pour travailler les basiques du LMD SQL avec une approche trs pratique. Un bon outil pour s'entraner et un bon compagnon avoir ses cts pour des dbuts en SQL (pour la ralisation de travaux pratiques par exemple). Programmation SQL [Mata03] De nombreux exemples et exercices, des listings complets, une rfrence SQL (mots rservs et diagrammes de Conway de la syntaxe).
Complment : Pratique
Comprendre les jointures dans Access [w_mhubiche.developpez.com] Un tutoriel trs pdagogique sur l'expression de jointures sous Access qui aide comprendre l'opration de jointure en gnral.
96
V-
LA THORIE DE LA
Les dpendances fonctionnelles Les formes normales Bibliographie commente sur la normalisation
NORMALISATION RELATIONNELLE
V
125 134 139
La thorie de la normalisation relationnelle est trs importante pour la conception de BD, dans la mesure o elle donne le cadre thorique pour la gestion de la redondance, et dans la mesure o une bonne matrise de la redondance est un aspect majeur de cette conception.
A. Les dpendances fonctionnelles

Objectifs
Comprendre la problmatique de la redondance et des dpendances fonctionnelles.
1. Exercice introductif : Redondance

Soit la relation R suivante, dfinie en extension :
A 0 0 0 0 1 0 1 1 1 2 1 1 2 3 4 1 B 1 1 2 3 3 3 3 4 C 10 10 10 10 20 10 20 20 D 5 9 6 7 7 9 8 9 E X X X X Y X Y Y F A G S D D G F G G
Tableau 13 Relation R Question 1

[Solution n4 p 173]
Proposez une cl primaire pour cette relation. Justifiez brivement.
97
La thorie de la normalisation relationnelle
Question 2
[Solution n5 p 174]
Cette relation contient-elle des redondances ? Si oui lesquelles ? Justifiez brivement. Question 3
[Solution n6 p 174] Si la relation contient des redondances, proposez une solution contenant exactement la mme information, mais sans redondance.
2. Les problmes soulevs par une mauvaise modlisation

Attention
Il y a toujours plusieurs faons de modliser conceptuellement un problme, certaines sont bonnes et d'autres mauvaises. C'est l'expertise de l'ingnieur en charge de la modlisation, travers son exprience accumule et sa capacit traduire le problme pos, qui permet d'obtenir de bons modles conceptuels. S'il est difficile de dfinir un bon modle conceptuel, on peut par contre poser qu'un bon modle logique relationnel est un modle o la redondance est contrle. On peut alors poser qu'un bon modle conceptuel est un modle conceptuel qui conduit un bon modle relationnel, aprs application des rgles de passage E-A ou UML vers relationnel. Mais on ne sait pas pour autant le critiquer avant ce passage, autrement qu' travers l'oeil d'un expert. A dfaut de disposer d'outils systmatiques pour obtenir de bons modles conceptuels, on cherche donc critiquer les modles relationnels obtenus. La thorie de la normalisation est une thorie qui permet de critiquer, puis d'optimiser, des modles relationnels, de faon en contrler la redondance.
Exemple : Un mauvais modle relationnel

Imaginons que nous souhaitions reprsenter des personnes, identifies par leur numro de scurit sociale, caractrises par leur nom, leur prnom, ainsi que les vhicule qu'elles ont achet, pour un certain prix et une certaine date, sachant qu'un vhicule est caractris par un type, une marque et une puissance. On peut aboutir la reprsentation relationnelle suivante : Personne(NSS, Nom, Prnom, Marque, Type, Puiss, Date, Prix) Imaginons que cette relation soit remplie par les donnes suivantes :
NSS 16607... 16607... 24908... 15405... 15405... 15405... Nom Dupont Dupont Martin Durand Durand Durand Prnom Paul Paul Marie Olivier Olivier Olivier Marque Renault Peugeot Peugeot Peugeot Renault BMW Type Clio 504 504 504 Clio 520 5 7 7 7 5 10 Puiss Date 1/1/96 2/7/75 1/10/89 8/8/90 7/6/98 4/5/2001 Prix 60000 47300 54900 12000 65000 98000
Tableau 14 Relation redondante On peut alors se rendre compte que des redondances sont prsentes, et l'on sait que ces redondances conduiront des problmes de contrle de la cohrence de l'information (erreur dans la saisie d'un numro de scurit sociale), de mise jour (changement de nom reporter dans de multiples tuples), de perte d'information lors de la suppression de donnes (disparition des informations concernant un type de vhicule) et de difficult reprsenter certaines informations (un type de vhicule sans propritaire).
Complment
On conseillera de lire le chapitre 2 de SQL2 SQL3, applications Oracle [Delmal01] (pages 42 49) qui propose une trs bonne dmonstration par l'exemple des problmes poss par une mauvaise modlisation relationnelle.
98
3. Principes de la normalisation
Fondamental
La thorie de la normalisation est une thorie destine concevoir un bon schma dune BD sans redondance dinformation et sans risques d'anomalie de mise jour. Elle a t introduite ds l'origine dans le modle relationnel. La thorie de la normalisation est fonde sur deux concepts principaux : Les dpendances fonctionnelles Elles traduisent des contraintes sur les donnes. Les formes normales Elles dfinissent des relations bien conues. La mise en oeuvre de la normalisation est fonde sur la dcomposition progressive des relations jusqu' obtenir des relations normalises.
4. Dpendance fonctionnelle
Dfinition : Dpendance fonctionnelle
Soient R(A1, A2, ... , An) un schma de relation, X et Y des sous-ensembles de A1, A2, ... , An. On dit que X dtermine Y, ou que Y dpend fonctionnellement de X, si est seulement s'il existe une fonction qui partir de toute valeur de X dtermine une valeur unique de Y. Plus formellement on pose que X dtermine Y pour une relation R ssi quelle que soit 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)
Syntaxe
Si X dtermine Y, on note : XY
Exemple
Soit la relation R suivante : Personne(NSS, Nom, Prnom, Marque, Type, Puiss, Date, Prix) On peut poser les exemples de DF suivants : NSSNom NSSPrnom TypeMarque TypePuiss (NSS, Type, Date)Prix etc.
Remarque : Comment trouver les DF ?

Une DF est dfinie sur l'intention du schma et non son extension. Une DF traduit une certaine perception de la ralit. Ainsi la DF (NSS, Type, Date)Prix signifie que personne n'achte deux voitures du mme type la mme date. La seule manire de dterminer une DF est donc de regarder soigneusement ce que signifient les attributs et de trouver les contraintes qui les lient dans le monde rel.
Remarque : Pourquoi trouver les DF ?

Les DF font partie du schma d'une BD, en consquence, elles doivent tre dclares par les
99
administrateurs de la BD et tre contrles par le SGBD. De plus l'identification des DF est la base indispensable pour dterminer dans quelle forme normale est une relation et comment en diminuer la redondance.
5. Les axiomes d'Armstrong

Introduction
Les DF obissent des proprits mathmatiques particulires, dites axiomes d'Armstrong.
Dfinition : Rflexivit
Tout groupe d'attributs se dtermine lui mme et dtermine chacun de ses attributs (ou sous groupe de ses attributs). Soient X et Y des attributs : XYXY et XYX et XYY
Dfinition : Augmentation
Si un attribut X dtermine un attribut Y, alors tout groupe compos de X enrichi avec d'autres attributs dtermine un groupe compos de Y et enrichi des mmes autres attributs. Soient X, Y et Z des attributs : XY XZYZ
Dfinition : Transitivit
Si un attribut X dtermine un attribut Y et que cet attribut Y dtermine un autre attribut Z, alors X dtermine Z. Soient X, Y et Z des attributs : XY et YZ XZ
6. Autres proprits dduites des axiomes d'Armstrong

Introduction
A partir des axiomes d'Amstrong, on peut dduire un certain nombre de proprits supplmentaires.
Dfinition : Pseudo-transitivit
Si un attribut X dtermine un autre attribut Y, et que Y appartient un groupe G qui dtermine un troisime attribut Z, alors le groupe G' obtenu en substituant Y par X dans G dtermine galement Z. Soient, W, X, Y et Z des attributs : XY et WYZ WXZ Cette proprit est dduite de l'augmentation et de la rflexivit : XY et WYZ WXWY et WYZ WXZ
Dfinition : Union
Si un attribut dtermine plusieurs autres attributs, alors il dtermine tout groupe compos de ces attributs. Soient X, Y et Z des attributs : XY et XZ XYZ Cette proprit est dduite de la rflexivit, de l'augmentation et de la transitivit : XY et XZ XXX et XXXY et YXYZ XYZ
Dfinition : Dcomposition
Si un attribut dtermine un groupe d'attribut, alors il dtermine chacun des attributs de ce groupe pris
100
individuellement. Soient X, Y et Z des attributs : XYZ XZ et XY Cette proprit est dduite de la rflexivit et de la transitivit : XYZ XYZ et YZZ XZ
7. DF lmentaire
Dfinition : Dpendance fonctionnelle lmentaire
Soit G un groupe d'attributs et A un attribut, une DF GA est lmentaire si A n'est pas inclu dans G et qu'il n'existe pas d'attribut A' de G qui dtermine A.
Exemple : DF lmentaires

ABC est lmentaire si ni A, ni B pris individuellement ne dterminent C. Nom, DateNaissance, LieuNaissancePrnom est lmentaire.
Exemple : DF non lmentaires

ABA n'est pas lmentaire car A est inclu dans AB. ABCB n'est pas lmentaire car CB n'est pas un attribut, mais un groupe d'attributs. NSSNom, Prnom n'est pas lmentaire.
Remarque
On peut toujours rcrire un ensemble de DF en un ensemble de DFE, en supprimant les DF triviales obtenues par rflexivit et en dcomposant les DF partie droite non atomique en plusieurs DFE.
Exemple : Rcriture de DF en DFE

On peut rcrire les DF non lmentaires de l'exemple prcdent en les dcomposant DFE : ABA n'est pas considre car c'est une DF triviale obtenu par rflxivit. ABCB est dcompose en ABC et ABB, et ABB n'est plus considre car triviale. NSSNom, Prnom est dcompose en NSSNom et NSSPrnom.
8. Notion de fermeture transitive des DFE

Dfinition : Fermeture transitive
On appelle fermeture transitive F+ d'un ensemble F de DFE, l'ensemble de toutes les DFE qui peuvent tre composes par transitivit partir des DFE de F.
Exemple
Soit l'ensemble F = {AB, BC, BD, AE}. La fermeture transitive de F est F+ = { AB, BC, BD, AE, AC, AD }
9. Notion de couverture minimale des DFE

Dfinition : Couverture minimale
La couverture minimale dun ensemble de DFE est un sous-ensemble minimum des DFE permettant de gnrer toutes les autres DFE. Synonymes : Famille gnratrice
101
Remarque
Tout ensemble de DFE (et donc tout ensemble de DF) admet au moins une couverture minimale (et en pratique souvent plusieurs).
Exemple
L'ensemble F = {AB, AC, BC, CB} admet les deux couvertures minimales : CM1 = {AC, BC, CB} et CM2 = {AB, BC, CB}
10. Notion de graphe des DFE

On peut reprsenter un ensemble de DFE par un graphe orient (ou plus prcisment un rseau de Ptri), tel que les noeuds sont les attributs et les arcs les DFE (avec un seul attribut en destination de chaque arc et ventuellement plusieurs en source).
Exemple : Relation Voiture

Soit la relation Voiture(NVH, Marque, Type, Puis, Couleur) avec l'ensemble des DF F = {NVHType, TypeMarque, TypePuis, NVHCouleur}. On peut rprsenter F par le graphe ci-dessous :
Graphe des DFE de la relation Voiture
Exemple : Relation CodePostal

Soit la relation CodePostal(Code, Ville, Rue ) avec l'ensemble des DF F={CodeVille, (Ville,Rue)Code}. On peut rprsenter F par le graphe ci-dessous :
Graphe des DFE de la relation CodePostal
11. Dfinition formelle d'une cl

Dfinition : 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 KA1,A2,...,An et il n'existe pas X inclu dans K tel que XA1,A2,...,An. Une cl est donc un ensemble minimum d'attributs d'une relation qui dtermine tous les autres.
102
Remarque : Cls candidates et cl primaire

Si une relation comporte plusieurs cls, chacun est dite cl candidate et l'on en choisit une en particulier pour tre la cl primaire.
Remarque
Toute cl candidate dtermine les autres cls candidates, puisque qu'une cl dtermine tous les attributs de la relation.
B. Les formes normales

Objectifs
Savoir crer des schmas relationnels en troisime forme normale.
1. Principe de la dcomposition
Dfinition : Dcomposition
L'objectif de la dcomposition est de "casser" une relation en relations plus petites afin d'en liminer les redondances et sans perdre d'information. La dcomposition d'un schma de relation R(A1,A2,...,An) est le processus de remplacement de ce schma par une collection de schmas R1,R2,...,Rn telle qu'il est possible de reconstruire R par des oprations relationnelles de jointure sur R1,R2,...,Rn.
Dfinition : Dcomposition prservant les DF

Une dcomposition d'une relation R en relations R1,R2,...Rn prserve les DF si la fermeture transitive F+ des DF de R est la mme que celle de l'union des fermetures transitives des DF de R1,R2,...,Rn.
Exemple : Dcomposition prservant les DF d'une relation Voiture

Soit la relation Voiture(Numro,Marque,Type,Puissance,Couleur) avec la fermeture transitive suivante : NumroMarque NumroType NumroPuissance NumroCouleur TypeMarque TypePuissance On peut dcomposer Voiture en prservant les DF en deux relations R1(Numro,Type,Couleur) et R2(Type,Puissance,Marque).
2. Formes normales
Les formes normales ont pour objectif de dfinir la dcomposition des schmas relationnels, tout en prservant les DF et sans perdre d'informations, afin de reprsenter les objets et associations canoniques du monde rel de faon non redondante. On peut recenser les 6 formes normales suivantes, de moins en moins redondantes : la premire forme normale la deuxime forme normale la troisime forme normale
103
la forme normale de Boyce-Codd la quatrime forme normale la cinquime forme normale La troisime forme normale est gnralement reconnue comme tant la plus importante respecter.

3. Premire forme normale

Dfinition : 1NF
Une relation est en 1NF si elle possde une cl et si tous ses attributs sont atomiques.
Dfinition : Attribut atomique

Un attribut est atomique si il ne contient qu'une seule valeur pour un tuple donn, et donc s'il ne regroupe pas un ensemble de plusieurs valeurs.
Exemple : Avoir plusieurs mtiers

Soit la relation Personne instancie par deux tuples : Personne(Nom, Profession) (Dupont, Gomtre) (Durand, Ingnieur-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 faire apparatre deux tuples pour Durand, on obtiendrait : Personne(Nom, Profession) (Dupont, Gomtre) (Durand, Ingnieur) (Durand, Professeur) Une autre solution aurait t d'ajouter un attribut ProfessionSecondaire. On obtiendrait ainsi : Personne(Nom, Profession, ProfessionSecondaire) (Dupont, Gomtre, Null) (Durand, Ingnieur, Professeur)
Remarque : Relativit de la notion d'atomicit

L'atomicit d'un attribut est souvent relative : on peut dcider qu'un attribut contenant une date n'est pas atomique (et que le jour, le mois et l'anne constituent chacun une valeur), ou bien que l'attribut est de domaine date et donc qu'il est atomique.
4. Deuxime forme normale

Introduction
La deuxime forme normale permet d'liminer les dpendances entre des parties de cl et des attributs n'appartenant pas une cl.
Dfinition : 2NF
Une relation est en 2NF si elle est en 1NF et si tout attribut qui n'est pas dans une cl ne dpend pas d'une partie seulement d'une cl. C'est dire encore que toutes les DF issues d'une cl sont lmentaires.
104
Exemple : Echelle de salaire

Soit la relation Personne : Personne(Nom, Profession, Salaire) Soit les DF suivantes sur cette relation : Nom,ProfessionSalaire ProfessionSalaire On note alors que la premire DF est issue de la cl et qu'elle n'est pas lmentaire (puisque Profession dtermine Salaire) et donc que le schma n'est pas en 2NF. Pour avoir un schma relationnel en 2NF, il faut alors dcomposer Personne en deux relations : Personne(Nom, Profession) Profession(Profession, Salaire) On remarque que ce schma est en 2NF (puisque Salaire dpend maintenant fonctionnellement d'une cl et non plus d'une partie de cl). On remarque aussi que la dcomposition a prserv les DF, puisque nous avons prsent : ProfessionSalaire (DF de la relation Profession) Nom,ProfessionProfession (par Rflexivit) Nom,ProfessionSalaire (par Transitivit)
Remarque
La dfinition de la 2NF doit tre vrifie pour toutes les cls candidates et non seulement la cl primaire (dans le cas o il y a plusieurs cls).
Remarque
Si toutes les cls d'une relation ne contiennent qu'un unique attribut, et que la relation est en 1NF, alors la relation est en 2NF.
5. Troisime forme normale

Introduction
La troisime forme normale permet d'liminer les dpendances entre les attributs n'appartenant pas une cl.
Dfinition : 3NF
Une relation est en 3NF si elle est en 2NF et si tout attribut n'appartenant pas une cl ne dpend pas d'un autre attribut n'appartenant pas une cl. C'est dire encore que toutes les DFE vers des attributs n'appartenant pas une cl, sont issues d'une cl.
Attention : Cl candidate
La dfinition concerne toutes les cls candidates et non uniquement la cl primaireSQL avanc : Programmation et techniques avances. [Celko00] (p.27).
Exemple : Echelle de salaire et de prime

Soit la relation Profession : Profession(Profession, Salaire, Prime) Soit les DF suivantes sur cette relation : ProfessionSalaire ProfessionPrime
105
SalairePrime Cette relation n'est pas en 3NF car Salaire, qui n'est pas une cl, dtermine Prime. Pour avoir un schma relationnel en 3NF, il faut dcomposer Profession :
Profession(Profession, Salaire) Salaire(Salaire, Prime) Ce schma est en 3NF, car Prime est maintenant dtermin par une cl. On remarque que cette dcomposition prserve les DF, car par transitivit, Profession dtermine Salaire qui dtermine Prime, et donc Profession dtermine toujours Prime.
Remarque : 3NF et 2NF

Une relation en 3NF est forcment en 2NF car : Toutes les DFE vers des attributs n'appartenant pas une cl sont issues d'une cl, ce qui implique qu'il n'existe pas de DFE, issues d'une partie de cl vers un attribut qui n'appartient pas une cl. Il ne peut pas non plus exister de DFE issues d'une partie de cl vers un attribut appartenant une cl, par dfinition 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 partie d'une cl, et donc que toutes les DF issues d'une cl sont lmentaires.
Fondamental
Il est souhaitable que les relations logiques soient en 3NF. En effet, il existe toujours une dcomposition sans perte d'information et prservant les DF d'un schma en 3NF. Si les formes normales suivantes (BCNF, 4NF et 5NF) assurent un niveau de redondance encore plus faible, la dcomposition permettant de les atteindre ne prserve plus les DF.
Remarque : Limite de la 3NF

Une relation en 3NF permet des dpendances entre des attributs n'appartenant pas une cl vers des parties de cl.
6. Forme normale de Boyce-Codd

Introduction
La forme normale de Boyce-Codd permet d'liminer les dpendances entre les attributs n'appartenant pas une cl vers les parties de cl.
Dfinition : BCNF
Une 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 DFE existantes sont celles dans lesquelles une cl dtermine un attribut.
Exemple : Employs
Soit la relation Personne : Personne(NSS, Pays, Nom, Rgion) Soit les DF suivantes sur cette relation : NSS,PaysNom NSS,PaysRgion RgionPays Il existe une DFE qui n'est pas issue d'une cl et qui dtermine un attribut appartenant une cl. Cette relation est en 3NF, mais pas en BCNF (car en BCNF toutes les DFE sont issues d'une cl).
106
Pour avoir un schma relationnel en BCNF, il faut dcomposer Personne : Personne(NSS, Rgion, Nom) Rgion(Region, Pays) Remarquons que les DF n'ont pas t prserves par la dcomposition puisque NSS et Pays ne dterminent plus Rgion.
Remarque : Simplicit
La BCNF est la forme normale la plus facile apprhender intuitivement et formellement, puisque les seules DFE existantes sont de la forme KA o K est une cl.
Attention : Non prservation des DF

Une dcomposition en BCNF ne prserve en gnral pas les DF.
* * *
La normalisation permet de dcomposer un schma relationnel afin d'obtenir des relations non redondantes. La 3NF est souhaitable car toujours possible obtenir, sans perte d'information et sans perte de DF. La BCNF est galement indique, car elle est un peu plus puissante, et plutt plus simple que la 3NF. La BCNF n'est pas encore suffisante pour liminer toutes les redondances. Il existe pour cela les 4NF et 5NF qui ne sont pas abordes dans ce cours. Notons galement que les cas de non-4NF et de non-5NF sont assez rares dans la ralit.
C. Bibliographie commente sur la normalisation

SQL2 SQL3, applications Oracle [Delmal01] On conseillera de lire le chapitre 2 (pages 42 49) qui propose une trs bonne dmonstration par l'exemple des problmes poss par une mauvaise modlisation relationnelle. Une description claire des formes normales, rendue simple et pratique grce des exemples reprsentatifs (chapitre 2).
107
VI -
LE RELATIONNEL-OBJET
Introduction : R, OO, RO Le modle relationnel-objet Le passage conceptuel vers relationnel-objet SQL3 (implmentation Oracle 9i) Exemples RO En rsum : Le relationnel-objet Bibliographie commente sur le relationnel-objet
VI
141 144 149 151 158 163 164
Si le modle logique relationnel a prouv sa puissance et sa fiabilit au cours des 20 dernires annes, les nouveaux besoins de l'informatique industrielle ont vu l'mergence de structures de donnes complexes mal adaptes une gestion relationnelle. La naissance du courant "orient objet" et des langages associes (Java et C++ par exemple) ont donc galement investi le champ des SGBD afin de proposer des solutions pour tendre les concepts du relationnel et ainsi mieux rpondre aux nouveaux besoins de modlisation.
A. Introduction : R, OO, RO
Objectifs
Comprendre les limites du modle relationnel Comprendre pourquoi et comment le modle relationnel peut tre tendu
1. Les atouts du modle relationnel

Fond sur une thorie rigoureuse et des principes simples Mature, fiable, performant Indpendance programme et donnes SGBDR : les plus utiliss, connus, matriss SQL une implmentation standard du modle relationnel, avec des API pour la plupart des langages de programmation Les SGBDR incluent des outils performants de gestion de requtes, de gnrateurs d'applications, d'administration, d'optimisation, etc, ...
2. Les inconvnients du modle relationnel

109
Le relationnel-objet
La structure de donne en tables est pauvre d'un point de vue de la modlisation logique Le mapping MCD vers MLD entrane une perte de smantique La manipulation de structures relationnelles par des langages objets entrane une impedance mismatch, c'est dire un dcalage entre les structures de donnes pour le stockage et les structures de donnes pour le traitement (ce qui implique des conversions constantes d'un format l'autre) La 1NF est inapproprie la modlisation d'objets complexes La normalisation entrane la gense de structures de donnes complexes et trs fragmentes, qui peuvent notamment poser des problmes de performance ou d'volutivit Le SQL doit toujours tre combin d'autres langages de programmation pour tre effectivement mis en uvre La notion de mthode ne peut tre intgre au modle logique, elle doit tre gre au niveau de l'implmentation physique Les types de donnes disponibles sont limits et non extensibles
3. Les SGBDOO
Introduction
Les SGBDOO ont t crs pour grer des structures de donnes complexes, en profitant de la puissance de modlisation des modles objets et de la puissance de stockage des BD classiques. Objectifs des SGBDOO : Offrir aux langages de programmation orients objets des modalits de stockage permanent et de partage entre plusieurs utilisateurs Offrir aux BD des types de donnes complexes et extensibles Permettre la reprsentation de structures complexes et/ou taille variable Avantages des SGBDOO : Le schma d'une BD objet est plus facile apprhender que celui d'une BD relationnelle (il contient plus de smantique, il est plus proche des entits relles) L'hritage permet de mieux structurer le schma et de factoriser certains lments de modlisation La cration de ses propres types et l'intgration de mthodes permets une reprsentation plus directe du domaine L'identification des objets permet de supprimer les cls artificielles souvent introduites pour atteindre la 3NF et donc de simplifier le schma Les principes d'encapsulation et d'abstraction du modle objet permettent de mieux sparer les BD de leurs applications (notion d'interface). Inconvnient des SGBDOO : Gestion de la persistance et de la coexistence des objets en mmoire (pour leur manipulation applicative) et sur disque (pour leur persistance) complexe Gestion de la concurrence (transactions) plus difficile mettre en uvre Interdpendance forte des objets entre eux Gestion des pannes Complexit des systmes (problme de fiabilit) Problme de compatibilit avec les SGBDR classiques Les SGBDOO apportent donc des concepts fondamentaux pour l'volution des BD, mais leur ralit est encore en grande partie du domaine de la recherche ou d'applications "de niche". Ils apportent donc une innovation sur des aspects que les SGBDR ne savent pas faire, mais sans tre au
110
mme niveau sur ce que les SGBDR savent bien faire.
4. Les SGBDRO
Introduction
Les SGBDRO sont ns du double constat de la puissance nouvelle promise par les SGBDOO et de l'insuffisance de leur ralit pour rpondre aux exigences de l'industrie des BD classiques. Leur approche est plutt d'introduire dans les SGBDR les concepts apports par les SGBDOO plutt que de concevoir de nouveaux systmes. Objectifs additionnels des SGBDRO : Grer des donnes complexes (temps, go-rfrencement, multimdia, types utilisateurs, etc.) Rapprocher le modle logique du modle conceptuel Rduire l' impedance mismatch
B. Le modle relationnel-objet
Objectifs
Connaitre les caractristiques principales du modle relationnel-objet Comprendre les avantages du modle relationnel-objet
1. Les SGBDRO
Dfinition : Modle relationnel-objet
Modle relationnel tendu avec des principes objet pour en augmenter les potentialits. Synonymes : Modle objet-relationnel Les apports principaux du modle relationnel-objet sont : Les types utilisateurs et l'encapsulation (recours aux mthodes) La gestion de collections L'hritage et la rutilisation L'identit d'objet et les rfrences physiques
2. Le modle imbriqu

nested model La 1NF est relche pour permettre d'affecter des valeurs non atomiques un attribut, pour modliser des objets complexes. Gestion directe des attributs multivalus, sans passer par une nouvelle relation Gestion directe des attributs composs Un attribut ne sera plus seulement value par une valeur simple, mais pourra l'tre par une collection d'objets complexes
Exemple
111
Exemple de table imbrique
3. Les types utilisateurs

Dfinition : Type de donnes utilisateur
Type de donnes cr par le concepteur d'un schma relationnel-objet, qui encapsule des donnes et des oprations sur ces donnes. Ce concept est rapprocher de celui de classe d'objets. Synonymes : Type utilisateur, Type de donnes abstrait
Syntaxe
Type nom_type : < attribut1 typeattribut1, attribut2 typeattribut2, ... attributN typeattributN, =methode1 (paramtres) typeretourn1, =methode2 (paramtres) typeretourn2, =... =methodeN (paramtres) typeretournN >
Remarque
Les type des attributs ou des mthodes d'un type peuvent galement tre des types utilisateurs.
Exemple : Adresse en relationnel

employe (#nom:chane, prenom:chane, ad_num:chane, ad_rue:chane, ad_ville:chane, ad_cp:chane, ad_ville:chane, ad_pays:chane, societe=>societe) societe (#nom:chane, ad_num:chane, ad_rue:chane, ad_ville:chane, ad_cp:chane, ad_ville:chane, ad_pays:chane)
Exemple : Adresse en relationnel-objet avec type

Type adresse : <num:chane, rue:chane, ville:chane, cp:chane, ville:chane, pays:chane> employe (#nom:chane, prenom:chane, ad:adresse, societe=>societe) societe (#nom:chane, ad:adresse)
Exemple : Type adresse avec mthode

Type adresse : < num:chane, rue:chane, ville:chane, cp:chane, ville:chane, pays:chane, =CPprefix() chane
112
>
Remarque : Premire forme normale

Le recours aux types utilisateurs brise une rgle de la premire forme normale, celle de l'atomicit des valeurs d'attribut. Ce non respect de la 1NF ne pose pas de problme car la dclaration de type permet d'accder la structure interne des attributs composs. Dans le modle relationnel classique, le problme du non respect de la 1NF tait bien l'opacit de la structure interne des attributs ainsi constitus qui interdisait l'accs des sous informations extraites de la valeur de l'attribut (par exemple un attribut comprenant le nom et le prnom ensemble interdit l'accs l'information "nom" ou l'information "prnom" indpendamment). L'usage de type claire cette opacit et rend ainsi le respect de l'atomicit superflu.
4. Les collections
Dfinition : Collection
Une collection est un type de donnes gnrique dfini afin de supporter les attributs multi-valus. Synonymes : Collection d'objets
Syntaxe
Type nom_type : collection de <type_objet>
Remarque
Les objets d'une collection peuvent tre d'un type utilisateur.
Exemple : Collection d'entiers

Type liste_telephone : collection de <entier>
Exemple : Collection d'objets complexe

Type adresse : <num, rue, ville> Type liste_adresse : collection de <adresse>
5. Comparaison relationnel et relationnel-objet

Exemple : Documents en relationnel
document (#ISBN:entier, titre:chane, soustitre:chane, editeur:chane, annee:entier) auteur (#id:entier, nom:chane, prenom:chane) motscles (#document=>document, #motcle=>motcle auteurslivres(#idauteur=>auteur, #ISBN=>document
Exemple : Documents en relationnel-objet

Type Type Type Type Type titre : <titre, soustitre> edition : <titre, soustitre> liste_motscles : collection de <chane> liste_auteurs : collection de <auteur> auteur : <nom, prenom>
113
document (#ISBN, titre:titre, edition:edition, motscles:liste_motscles, auteurs:liste_auteurs)
Remarque : Perte de smantique

La transformation prcdente du modle initiale, a limin l'entit auteur. La notion d'auteur n'est donc plus qu'une proprit des livres et non un objet dfini indpendamment dans le schma de donne. Dans le cas gnral cette modlisation ne sera pas souhaitable et on prfrera conserver l'entit auteur. Bien entendu l'existence pralable d'un schma conceptuel permet de lever l'ambigut puisque selon que les auteurs seront dfinis comme des entits ou bien comme des proprits de l'entit livre, le choix de modlisation sera effectu.
Exemple : Documents et auteurs en relationnel-objet

Type titre : <titre, soustitre> Type edition : <titre, soustitre> Type liste_motscles : collection de <chane> Type liste_auteurs : collection de <number> document (#ISBN, titre:titre, edition:edition, motscles:liste_motscles, auteurs:liste_auteurs) auteur (#id:entier, nom:chane, prenom:chane)
Remarque : Association N:M imbrique

Dans l'exemple ci-dessus, le schma relationnel-objet a permis de se dbarrasser de la table "auteurslivres" du modle initial et qui n'existait que pour modliser l'association N:M entre les livres et les auteurs. Dans l'exemple ci-dessus l'utilisation d'une collection a permis de simplifier le schma en le dbarassant de cette relation artificielle. Notons nanmoins que le fait d'avoir choisi d'imbriquer les auteurs dans les livres (et non l'inverse qui tait galement possible) est porteur de sens tant au niveau conceptuel (ce sont plutt les livres qui nous intressent que les auteurs), qu'au niveau oprationnel (il sera plus facile et plus efficace de trouver les auteurs d'un livre que les livres d'un auteur).
6. Tables d'objets
Une table peut tre dfinie en rfrenant un type de donnes plutt que par des instructions LDD classiques. On parle alors de table d'objets.
Syntaxe
nom_table de nom_type (#attributs_cls)
Remarque : OID
Une telle dfinition de table peut permettre d'identifier les objets par un OID
Remarque : Hritage
Cette modalit de dfinition de schma permet de profiter de l'hritage de type pour permettre l'hritage de schma de table.
7. Hritage et rutilisation de types

Dfinition : Hritage de type
Un type de donnes utilisateur peut hriter d'un autre type de donnes utilisateur.
114
Syntaxe
Type sous_type hrite de type : < attributs et mthodes spcifiques >
Remarque : Hritage de schma de table

Pour qu'une table hrite du schma d'une autre table, il faut dfinir les tables depuis des types. L'hritage entre les types permet ainsi l'hritage entre les schmas de table.
8. Identification d'objets et rfrences

Le modle relationnel-objet permet de disposer d'identificateurs d'objet (OID)
Caractristiques

L'OID est une rfrence unique pour toute la base de donnes qui permet de rfrencer un enregistrement dans une table d'objets. L'OID est une rfrence physique (adresse disque) construit partir du stockage physique de l'enregistrement dans la base de donnes.
Avantages

Permet de crer des associations entre des objets sans effectuer de jointure (gain de performance). Fournit une identit l'objet indpendamment de ses valeurs (cl artificielle). Fournit un index de performance maximale (un seul accs disque). Permet de garder en mmoire des identificateurs uniques dans le cadre d'une application objet, et ainsi grer la persistance d'objets que l'on ne peut pas garder en mmoire, avec de bonnes performances (alors que sinon il faudrait excuter des requtes SQL pour retrouver l'objet).
Inconvnient

Plus de sparation entre le niveau logique et physique. L'adresse physique peut changer si le schma de la table change (changement de la taille d'un champs par exemple) Manipulation des donnes plus complexes, il faut un langage applicatif au dessus de SQL pour obtenir, stocker et grer des OID dans des variables.
Exemple : Cadre d'usage

L'usage d'OID est pertinent dans le cadre d'applications crites dans un langage objet, manipulant un trs grand nombre d'objets relis entre eux par un rseau d'associations complexe. En effet si le nombre d'objets est trop grand, les objets ne peuvent tous tre conservs en mmoire vive par l'application objet qui les manipule. Il est alors indispensable de les faire descendre et remonter en mmoire rgulirement. Or dans le cadre d'un traitement portant sur de trs nombreux objets, la remont en mmoire d'un objet est un point critique en terme de performance. A fortiori si l'identification de l'objet remonter demande une interrogation complexe de la BD, travers de nombreuses jointures. Le fait d'avoir conserv en mmoire un OID permet de retrouver et de recharger trs rapidement un objet, sans avoir le rechercher travers des requtes SQL comportant des jointures et donc trs couteuses en performance.
Remarque : Dbat
la communaut des BD est plutt contre les OID, qui rompent avec la sparation entre manipulation logique et stockage physique des donnes. La communaut objet est l'origine de l'intgration des OID dans SQL3, en tant qu'ils sont une rponse
115
au problme de persistance dans les applications objets.
Syntaxe : Rfrence en utilisant l'OID

Dans une dfinition de table ou de type : attribut REF nom_table_d_objets
C. Le passage conceptuel vers relationnel-objet

Objectifs
Savoir dduire un modle logique relationnel-objet depuis un modle conceptuel E-A ou UML. Intgrer les apports du modle relationnel-objet par rapport au relationnel dans ce processus.
Cette partie permet de traiter la traduction d'un modle conceptuel UML ou E-A en modle relationnel-objet. Le modle E-A tendu est bien plus adapt au relationnel-objet que le modle E-A classique.
1. Classe
Pour chaque classe (ou entit), crer un type d'objet avec les attributs de la classe (ou entit). Crer une table d'objets de ce type pour instancier la classe (ou entit), en ajoutant les contraintes d'intgrit.
Remarque : Table d'objet

La fait d'instancier la classe (l'entit) via une table d'objets plutt qu'une relation classique, permet l'accs l'hritage de type, l'implmentation des mthodes et ventuellement l'usage d'OID la place de cls trangres classiques. Si aucun de ces aspects n'est utilis, il est possible d'instancier directement la classe (l'entit) en table. Mais le passage par un type est a priori plus systmatique.
Remarque : Mapping des mthodes

Si le modle conceptuel autorise l'expression de mthodes (UML ou extension de E-A), alors on ajoute la dfinition de ces mthodes sur le type d'objet cr pour de chaque classe (ou entit).
2. Attributs
Attributs composites
Pour chaque type d'attribut compos, crer un type d'objet.
Attributs multi-valus
Pour chaque attribut multi-valu crer une collection du type de cet attribut.
Remarque : Attributs composites multi-valus

Si l'attribut multi-valu est composite, alors crer une collection d'objets.
116
Attributs drivs
Pour chaque attribut driv crer une mthode associe au type d'objet de la classe (l'entit).
3. Association 1:N
Les associations 1:N sont gres comme en relationnel. On peut nanmoins favoriser l'usage d'objets pour les cls trangres composes de plusieurs attributs, ainsi que pour les attributs migrants de l'association vers le relation ct N. Il est aussi possible de grer la cl trangre avec un OID la place d'une cl trangre classique.
4. Association N:M
Les associations N:M peuvent tre gres comme en relationnel. Il est aussi possible de grer ces relations, en utilisant une collection de rfrences (une collection de cls trangres) (NB : on favorise ainsi une des deux relations). Il est aussi possible de grer ces relations en utilisant un OID comme cl trangre. Il est aussi possible de grer ces relations en utilisant une collection de rfrence OID.
Remarque : Collection de cls trangres

Oracle n'autorise pas ( ma connaissance ...) la spcification de contraintes d'intgrit rfrentielle dans une table imbrique. Ce qui limite l'utilisation de telles tables pour grer des relations N:M avec des collections de cls trangres. Par contre cela fonctionne avec des rfrences des OID.
5. Hritage
L'hritage est gr comme en relationnel classique, avec la possibilit de profiter de l'hritage de type pour liminer la redondance dans la dfinition des schmas.
D. SQL3 (implmentation Oracle 9i)

Objectifs
Connaitre l'extension du LDD, et en particulier les types abstrait, les relations imbriques et l'hritage. Connaitre l'extension du LMD pour naviguer dans les objets manipuls.
1. Les nouveaux types de donnes

SQL3 introduit de nouveaux types de donnes : Large Object (CLOB and BLOB) Boolean Array Row
2. Les types de donnes abstraits

117
Implmentation des types utilisateurs.
Syntaxe : Dclaration de type de donnes

CREATE TYPE nom_type AS OBJECT ( nom_attribut1 type_attribut1 ... MEMBER FUNCTION nom_fonction1 (parametre1 IN|OUT type_parametre1, ...) RETURN type_fonction1 ... ) [NOT FINAL]; CREATE TYPE BODY nom_type IS MEMBER FUNCTION nom_fonction1 (...) RETURN type_fonction1 IS BEGIN ... END MEMBER FUNCTION nom_fonction2 ... ... END
Syntaxe : Hritage de type

CREATE TYPE sous_type UNDER sur_type ( Dclarations spcifiques ou surcharges )
Remarque : NOT FINAL

Pour tre "hritable", un type doit tre dclar avec la clause optionnelle NOT FINAL.
3. Mthodes et SELF
SELF
Lorsque l'on crit une mthode on a gnralement besoin d'utiliser les attributs propres (voire d'ailleurs les autres mthode), de l'objet particulier que l'on est en train de manipuler. On utilise pour cela la syntaxe SELF qui permet de faire rfrence l'objet en cours.
Syntaxe : SELF
self.nom_attribut self.nom_mthode(...)
Exemple : Total d'une facture

MEMBER FUNCTION total RETURN number IS t number; BEGIN SELECT sum(f.qte) INTO t FROM facture f WHERE f.num=self.num; RETURN t; END total;
118
Remarque : SELF implicite

Dans certains cas simples, lorsqu'il n'y a aucune confusion possible, SELF peut tre ignor et le nom de l'attribut ou de la mthode directement utilis. Il est toutefois plus systmatique et plus clair de mettre explicitement le self.
Exemple : Exemple de SELF implicite

MEMBER FUNCTION adresse RETURN varchar2 IS BEGIN RETURN num || rue || ville; END;
4. Nested tables
Implmentation des collections sous forme de tables imbriques.

--Cration d'un type abstrait d'objet CREATE TYPE nom_type AS OBJECT (...); -- Dclaration d'un type abstrait de collection CREATE TYPE liste_nom_type AS TABLE OF nom_type; -- Dclaration d'une table imbriquant une autre table CREATE TABLE nom_table_principale ( nom_attribut type_attribut, ... nom_attribut_table_imbrique liste_nom_type, ... ) NESTED TABLE nom_attribut_table_imbrique STORE AS nom_table_stockage;
5. Tables d'objets
Implmentation d'une dfinition de table depuis un type.

CREATE TABLE nom_table_principale OF nom_type ( PRIMARY KEY(attribut1), attribut2 NOT NULL, UNIQUE (attribut3) FOREIGN KEY (attribut4) REFERENCES ... );
Remarque : Mthodes
Si le type sur lequel s'appuie la cration de la table dfinit des mthodes, alors les mthodes seront associes la table.
Remarque : Contraintes
Il est possible, sur une table ainsi dfinie, de spcifier les mmes contraintes que pour une table cre
119
avec une clause CREATE TABLE (contraintes de table). Ces contraintes doivent tre spcifies au moment de la cration de la table, et non au moment de la cration du type. (bien que la dfinition d'objet permet de spcifier des contraintes du type NOT NULL, etc.)
6. Insertion d'objets
La manipulation de donnes est tendue pour assurer la gestion des objets et des collections.
Remarque : Constructeur d'objet

Pour tout type d'objet est automatiquement cre une mthode de construction, dont le nom est celui du type et les arguments les attributs du type.
Syntaxe : Insertion d'objets

INSERT INTO nom_table (..., attribut_type_objet, ...) VALUES (..., nom_type(valeur1, valeur2, ...), ...);
Syntaxe : Insertion de collections d'objets

INSERT INTO nom_table (..., attribut_type_collection, ...) VALUES ( ... nom_type_collection( nom_type_objet(valeur1, valeur2, ...), nom_type_objet(valeur1, valeur2, ...), ...); ... );
7. Insertion de collections partir de requtes SELECT

Les constructeurs d'objets sont utilisables dans les instructions de type INSERT ... VALUES, mais ne peuvent tre utiliss dans les instructions de type INSERT ... SELECT. Pour ces dernires une autre mthode de construction est ncessaire.
Syntaxe : Insrer une collection d'objets depuis une table

Soient les tables tro et t dfinies par le schma RO ci-aprs. type col : collection de <string> tro(a_obj:col) t(a:string) L'instruction suivante permet d'insrer le contenu de l'attribut a pour tous les enregistrements de t dans un seul attribut a_obj d'un seul enregistrement de tro sous la forme d'une collection. INSERT INTO tro (a_objet) VALUES (CAST(MULTISET(SELECT a FROM t ) AS col));

L'instruction CAST (...) AS <type> permet de renvoyer un type donn partir d'une expression. L'instruction MULTISET (...) permet de renvoyer une collection partir d'une liste de valeurs.
Mthode : Approche gnrale

Soit la table tro dfinie par le schma RO ci-aprs. Elle contient un attribut cl (pk_id) et un attribut
120
qui est une collection (a_obj). type col : collection de <string> tro(#pk_id:string, a_obj:col) Soit la table tr dfinie par le schma relationnel ci-aprs. tr(a:string, b:string) a1 a1 a1 a2 a2 b1 b2 b3 b4 b5 Tableau 15 Extrait de tr
Si l'on souhaite insrer le contenu de tr dans tro de telle faon que les valeurs de a correspondent pk_id et celles de b obj_a, en insrant une ligne pour chaque valeur ax et que tous les bx correspondant soient stocks dans la mme collection, il faut excuter une requte INSERT ... SELECT qui fait appel aux instructions CAST et MULTISET. INSERT INTO tro (pk_id, a_obj) SELECT a, CAST( MULTISET( SELECT b FROM tr tr1 WHERE tr1.a= tr2.a) AS col) FROM tr tr2; a1 a2 (b1, b2, b3) (b4, b5) Tableau 16 Extrait de tro aprs excution de la requte INSERT
8. Slection dans des objets

Syntaxe : Accs aux attributs des objets
SELECT alias_table.nom_objet.nom_attribut FROM nom_table AS alias_table
Syntaxe : Accs aux mthodes des objets

SELECT alias_table.nom_objet.nom_mthode(paramtres) FROM nom_table AS alias_table
Remarque : Alias obligatoire

L'accs aux objets se fait obligatoirement en prfixant le chemin d'accs par l'alias de la table et non directement par le nom de la table.
121
9. Slection dans des tables imbriques

Syntaxe : Accs aux tables imbriques
Soit "nt" une table imbrique dans la table "t". SELECT t2.* FROM t t1, TABLE(t1.nt) t2;
Remarque : Jointure avec la table imbrique

La jointure entre la table principale et sa table imbrique est implicitement ralise, il n'est pas besoin de la spcifier.
Remarque : Accs la colonne d'une table imbrique de scalaires

Lorsque la table imbrique est une table de type scalaire (et non une table d'objets d'un type utilisateur), alors la colonne de cette table n'a pas de nom (puisque le type est scalaire la table n'a qu'une colonne). Pour accder cette colonne, il faut utiliser la syntaxe ddie : COLUMN_VALUE
Exemple : Nested table pour grer une collection de cls trangres

Soit la gestion de deux relations pour grer des livres et des auteurs, avec une relation N:M entre elles. On dcide de grer cette relation par une collection de cls trangres dans la table des livres. CREATE TABLE tAuteur ( Id integer PRIMARY KEY, Nom char(20), Prenom char(20)); CREATE TYPE ListeFkAuteur AS TABLE OF integer; CREATE TABLE tLivre ( Titre char(20) PRIMARY KEY, fkAuteurs ListeFkAuteur ) NESTED TABLE fkAuteurs STORE AS tLivresAuteurs; INSERT INTO tAuteur VALUES (1, 'Merle', 'Robert'); INSERT INTO tAuteur VALUES (2, 'Barjavel', 'Ren'); INSERT INTO tLivre VALUES ('Malvil', ListeFkAuteur(1, 2)); SELECT t1.Titre, t2.COLUMN_VALUE FROM tLivre t1, TABLE(t1.fkAuteurs) t2; TITRE COLUMN_VALUE ----------------------------Malvil 1 Malvil 2 SELECT t1.Titre, t3.Nom FROM tLivre t1, TABLE(t1.fkAuteurs) t2, tAuteur t3 WHERE t2.COLUMN_VALUE=t3.Id; TITRE NOM ----------------------------Malvil Merle Malvil Barjavel
122
10. Manipulation d'OID

Une table d'objets, i.e. cre depuis un type, dispose d'un OID pour chacun de ses tuples. Cet OID est accessible depuis la syntaxe REF dans une requte SQL.
Syntaxe : REF
SELECT REF(alias) FROM nom_table alias
Exemple : OID
0000280209DB703686EF7044A49F8FA67530383B36853DE7106BC74B678 1275ABE5A553A5F01C000340000
Syntaxe : Cl trangre par l'OID

CREATE TYPE type_objet AS OBJECT ... CREATE TABLE table1 OF type_objet ... CREATE TABLE table2 ( ... cl_trangre REF type_objet, SCOPE FOR (cl_trangre) IS table1, );
Remarque : SCOPE FOR

Renforce l'intgrit rfrentielle en limitant la porte de la rfrence une table particulire (alors que REF seul permet de pointer n'importe quel objet de ce type)
Syntaxe : Insertion de donnes en SQL

INSERT INTO table1 (champs1, ..., cl_trangre) SELECT 'valeur1', ..., REF(alias) FROM table2 alias WHERE cl_table2='valeur';
Syntaxe : Insertion de donnes en PL/SQL

DECLARE variable REF type_objet; BEGIN SELECT REF(alias) INTO variable FROM table2 alias WHERE cl_table2='valeur'; INSERT INTO tCours (champs1, ..., cl_trangre) VALUES ('valeur1', ..., variable); END;
Syntaxe : Navigation d'objets

La rfrence par OID permet la navigation des objets sans effectuer de jointure, grce la syntaxe suivante : SELECT t.cl_trangre.attribut_table2
123
FROM table1 t;
E. Exemples RO
1. Exemple : Gestion de cours
a) Modle conceptuel
Modle conceptuel en UML
b) Modle logique
Type Bureau : < poste:entier, centre:chane, btiment:chane, numro:entier, =coordonnes():chane > Type Personne : < nom:chane, prnom:chane > Type Intervenant hrite de Personne : < bureau:Bureau > tIntervenant de Intervenant (#nom, #prnom) Type RefIntervenant : <nom:chane, prnom:chane> Type ListeRefIntervenants: collection de <RefIntervenant> Type Cours(semestre:chane, num:entier, titre:chane, type:enum, contenu:chane,
124
lIntervenant:ListeRefIntervenant) tCours de Cours (#semestre, #num)
Remarque : Mthode coordonnes()

On a choisi de mettre la mthode coordonnes au niveau du type Bureau plutt que du type Personne, pour augmenter les possibilits de rutilisabilit (car d'autres entits que Intervenant pourraient utiliser le type Bureau). C'est une possibilit offerte par le fait que les attributs composs donnent naissance des types utilisateurs (on dcide donc de remonter certaines mthodes qui ne concerne que cet attribut compos au niveau de ce type).
c) Implmentation
CREATE TYPE Bureau AS OBJECT ( poste number(4), centre char(2), batiment char(1), numero number(3), MEMBER FUNCTION coordonnees RETURN varchar2 ); CREATE TYPE BODY Bureau IS MEMBER FUNCTION coordonnees RETURN varchar2 IS BEGIN RETURN centre||batiment||numero||' - poste '||poste; END; END; CREATE TYPE Personne AS OBJECT( pkNom varchar2(50), pkPrenom varchar2(50) ) NOT FINAL ; CREATE TYPE Intervenant UNDER Personne ( aBureau Bureau ); CREATE TABLE tIntervenant OF Intervenant ( PRIMARY KEY(pkNom,pkPrenom) ); CREATE TYPE RefIntervenant AS OBJECT ( nom varchar2(50), prenom varchar2(50) ); CREATE TYPE ListeRefIntervenants AS TABLE OF RefIntervenant; CREATE TYPE Cours AS OBJECT( pkSemestre char(5), pkNum number(2), aTitre varchar2(50), aType char(2), aContenu varchar2(300), lIntervenant ListeRefIntervenants );
125
CREATE TABLE tCours OF Cours ( PRIMARY KEY(pkSemestre, pkNum), CHECK (aType='C' or aType='TD' or aType='TP') ) NESTED TABLE lIntervenant STORE AS ntCoursIntervenants;
d) Initialisation
INSERT INTO tIntervenant VALUES ('CROZAT', 'Stphane', Bureau('4287','R','A',108)); INSERT INTO tIntervenant VALUES ('JOUGLET', 'Antoine', Bureau('4423','R','C',100)); INSERT INTO tCours VALUES ('P2003',1,'Conception','C','E-A et UML', ListeRefIntervenants(RefIntervenant('CROZAT','Stphane'))); INSERT INTO tCours VALUES ('P2003',5,'Access','TP','Initiation', ListeRefIntervenants(RefIntervenant('CROZAT','Stphane'), RefIntervenant('JOUGLET','Antoine')));
e) Questions
SET LINESIZE 60 SET PAGESIZE 10 COLUMN Quand FORMAT A5 COLUMN Quoi FORMAT A10 COLUMN Qui FORMAT A20 COLUMN Ou FORMAT A19 SELECT t.pkNom||' '||t.pkPrenom AS Qui, t.aBureau.coordonnees() AS Ou FROM tIntervenant t; QUI OU ------------------------------------CROZAT Stphane R A108 - poste 4287 JOUGLET Antoine R C100 - poste 4423 SELECT c.pkSemestre AS Quand,c.aTitre AS Quoi,ci.Nom AS Qui FROM tCours c, TABLE(c.lIntervenant) ci; QUAND QUOI QUI -----------------------------P2003 Conception CROZAT P2003 Access CROZAT P2003 Access JOUGLET SELECT c.pkSemestre AS Quand,c.aTitre AS Quoi,i.pkNom AS Qui,i.aBureau.coordonnees() AS Ou FROM tCours c, TABLE(lIntervenant) ci, tIntervenant i WHERE ci.nom=i.pkNom AND ci.prenom=i.pkPrenom; QUAND QUOI QUI OU -------------------------------------------------
126
P2003 Conception CROZAT R A108 - poste 4287 P2003 Access CROZAT R A108 - poste 4287 P2003 Access JOUGLET R C100 - poste 4423
2. Exemple : Gestion de cours simplifie (version avec OID)

a) Modle conceptuel
Modle conceptuel en UML
b) Modle logique
Type Intervenant : < nom:chane, prnom:chane > tIntervenant de Intervenant (#nom) Type Cours(num:entier, titre:chane, fkIntervenant REF tIntervenant) tCours de Cours (#num)
c) Implmentation
CREATE TYPE Intervenant AS OBJECT ( pkNom varchar2(50), aPrenom varchar2(50) ); CREATE TABLE tIntervenant OF Intervenant (PRIMARY KEY (pkNom)); CREATE TYPE Cours AS OBJECT ( pkNum number(2), aTitre varchar2(50), fkIntervenant REF Intervenant ); CREATE TABLE tCours OF Cours ( SCOPE FOR (fkIntervenant) IS tIntervenant, PRIMARY KEY(pkNum) );
d) Initialisation de la table d'objets tIntervenant

INSERT INTO tIntervenant VALUES ('CROZAT', 'Stphane');
127
e) Insertion de donnes dans la table d'objets tCours (SQL)

INSERT INTO tCours SELECT 2, 'Modlisation', REF(i) FROM tIntervenant i WHERE pkNom='CROZAT';
f) Insertion de donnes dans la table tCours (PL/SQL)

DECLARE ri REF Intervenant; BEGIN SELECT REF(i) INTO ri FROM tIntervenant i WHERE i.pkNom='CROZAT'; INSERT INTO tCours VALUES (1,'Conception',x); END;
g) Slection : Cl trangre sous forme d'OID

SELECT * FROM tCours; PKNUM ATITRE FKINTERVENANT ----------------------------------------------------------1 Conception 0000220208DE4BD8F3191044589847E31E64B83EBB5807280A335B44C4A D958EDF20D185B5 2 Modlisation 0000220208DE4BD8F3191044589847E31E64B83EBB5807280A335B44C4A D958EDF20D185B5
h) Slection : Jointure sur l'OID Contre-exemple : ce qu'il ne faut pas faire !

SELECT c.pkNum, i.pkNom FROM tCours c, tIntervenant i WHERE c.fkIntervenant=REF(i); PKNUM PKNOM ------------------------1 CROZAT 2 CROZAT
i) Slection : Navigation d'objets

SELECT pkNum, c.fkIntervenant.pkNom FROM tCours c PKNUM PKNOM ------------------------1 CROZAT 2 CROZAT
128
F. En rsum : Le relationnel-objet
Types
Pr-dfinis Domaines classiques Chane, Entier, Date, Boolen, etc. Domaines avancs CLOB, BLOB, etc. Dfinis par l'utilisateur Relation Comme dans le modle relationnel classique Objets Types utilisateurs Collections Tables imbriques
Modle RO
Modle imbriqu Table d'objets CREATE TYPE CREATE TABLE OF Collection NESTED TABLE Type utilisateur OID REF SCOPE FOR Hritage de type NOT FINAL Mthode MEMBER FUNCTION CREATE TYPE BODY
G. Bibliographie commente sur le relationnel-objet

Complment : Synthse SQL3 sous Oracle 8i
SQL2 SQL3, applications Oracle [Delmal01] On consultera les chapitre 11 et 12 pour avoir une description des extensions SQL3 et de ses implmentations et extensions sous Oracle (version 8i).
129
VII -
LA GESTION DES
Problmatique des pannes et de la concurrence Transactions Fiabilit et transactions Concurrence et transactions En rsum : Les transactions Bibliographie commente sur les transactions
TRANSACTIONS
VII
165 166 169 174 181 182
Les transactions sont une rponse gnrale aux problmes de fiabilit et d'accs concurrents dans les BD, et en particulier dans les BD en mode client-serveur. Elles sont le fondement de toute implmentation robuste d'une BD. Des systmes comme Oracle ne fonctionnent nativement qu'en mode transactionnel.
A. Problmatique des pannes et de la concurrence

Une BD est un ensemble persistant de donnes organises qui a en charge la prservation de la cohrence de ces donnes. Les donnes sont cohrentes si elles respectent l'ensemble des contraintes d'intgrit spcifies pour ces donnes : contraintes de domaine, intgrit rfrentielle, dpendances fonctionnelles, etc. La cohrence des donnes peut tre remise en cause par deux aspects de la vie d'une BD : La dfaillance Lorsque le systme tombe en panne alors qu'un traitement est en cours, il y a un risque qu'une partie seulement des instructions prvues soit excute, ce qui peut conduire des incohrences. Par exemple pendant une mise jour en cascade de cls trangres suite au changement d'une cl primaire. La concurrence Lorsque deux accs concurrents se font sur les donnes, il y a un risque que l'un des deux accs rende l'autre incohrent. Par exemple si deux utilisateurs en rseau modifient une donne au mme moment, seule une des deux mises jour sera effectue. La gestion de transactions par un SGBD est la base des mcanismes qui permettent d'assurer le maintien de la cohrence des BD. C'est dire encore qu'il assure que tous les contraintes de la BD seront toujours respectes, mme en cas de panne et mme au cours d'accs concurrents.
131
La gestion des transactions
B. Transactions
Objectifs
Comprendre les principes et l'intrt des transactions Connatre les syntaxes SQL standard, Oracle et Access pour utiliser des transactions Matriser les modalits d'utilisation des transactions
1. Notion de transaction
Dfinition : Transaction
Une transaction est une unit logique de travail, c'est dire une squence d'instructions, dont l'excution assure le passage de la BD d'un tat cohrent un autre tat cohrent.
Fondamental : Cohrence des excutions incorrectes

La transaction assure le maintien de la cohrence des donnes que son excution soit correcte ou incorrecte.
Exemple : Exemples d'excutions incorrectes

L'excution d'une transaction peut tre incorrecte parce que : Une panne a lieu Un accs concurrent pose un problme Le programme qui l'excute en a dcid ainsi
2. Droulement d'une transaction

1. DEBUT 2. TRAITEMENT Accs aux donnes en lecture Accs aux donnes en criture 3. FIN Correcte : Validation des modifications Incorrecte : Annulation des modifications
Remarque
Tant qu'une transaction n'a pas t termine correctement, elle doit tre assimile une tentative ou une mise jour virtuelle, elle reste incertaine. Une fois termine correctement la transaction ne peut plus tre annule par aucun moyen.
3. Proprits ACID d'une transaction

Une transaction doit respecter quatre proprits fondamentales : L'atomicit Les transactions constituent l'unit logique de travail, toute la transaction est excute ou bien rien du tout, mais jamais une partie seulement de la transaction. La cohrence Les transactions prservent la cohrence de la BD, c'est dire qu'elle transforme la BD d'un tat cohrent un autre (sans ncessairement que les tats intermdiaires internes de la BD au
132
cours de l'excution de la transaction respectent cette cohrence) L'isolation Les transactions sont isoles les unes des autres, c'est dire que leur excution est indpendante des autres transactions en cours. Elles accdent donc la BD comme si elles taient seules s'excuter, avec comme corollaire que les rsultats intermdiaires d'une transaction ne sont jamais accessibles aux autres transactions. La durabilit Les transactions assurent que les modifications qu'elles induisent perdurent, mme en cas de dfaillance du systme.
Remarque
Les initiales de Atomicit, Cohrence, Isolation et Durabilit forme le mot mnmotechnique ACID.
4. Transactions en SQL
Introduction
Le langage SQL fournit trois instructions pour grer les transactions.
Syntaxe : Dbut d'une transaction

BEGIN TRANSACTION Cette syntaxe est optionnelle (voire inconnue de certains SGBD), une transaction tant dbute de faon implicite ds qu'instruction est initie sur la BD.
Syntaxe : Fin correcte d'une transaction

COMMIT TRANSACTION (ou COMMIT) Cette instruction SQL signale la fin d'une transaction couronne de succs. Elle indique donc au gestionnaire de transaction que l'unit logique de travail s'est termine dans un tat cohrent est que les donnes peuvent effectivement tre modifies de faon durable.
Syntaxe : Fin incorrecte d'une transaction

ROLLBACK TRANSACTION (ou ROLLBACK) Cette instruction SQL signale la fin d'une transaction pour laquelle quelque chose s'est mal pass. Elle indique donc au gestionnaire de transaction que l'unit logique de travail s'est termine dans un tat potentiellement incohrent et donc que les donnes ne doivent pas tre modifies en annulant les modifications ralises au cours de la transaction.
Remarque : Programme
Un programme est gnralement une squence de plusieurs transactions.
5. Exemple de transaction sous Oracle

Exemple : Exemple basique en SQL
INSERT INTO t1 (a,b) VALUES (1,1); COMMIT;
Exemple : Exemple de gestion de compte toujours positif sur Oracle en PL/SQL

DECLARE vTotal number;
133
BEGIN UPDATE compte SET total=total-1000 WHERE nom="dupont"; SELECT total INTO vTotal FROM compte WHERE nom="dupont"; IF vTotal<0 THEN ROLLBACK; ELSE COMMIT; END IF; END;
6. Exemple de transaction sous Access

Exemple : Exemple de transfert financier sous Access
Sub Transaction BeginTrans CurrentDb.CreateQueryDef("", "UPDATE Compte1 SET Solde=Solde+100 WHERE Num=1").Execute CurrentDb.CreateQueryDef("", "UPDATE Compte2 SET Solde=Solde-100 WHERE Num=1").Execute CommitTrans End Sub
Remarque : VBA et transactions

Sous Access, il n'est possible de dfinir des transactions sur plusieurs objets requtes qu'en VBA.
Remarque : Transactions automatique sous Access

Sous Access, toute requte portant sur plusieurs lignes d'une table est (sauf paramtrage contraire) encapsule dans une transaction. Ainsi par exemple la requte "UPDATE Compte SET Solde=Solde*6,55957" est excute dans une transaction et donc, soit toutes les lignes de la table Compte seront mises jour, soit aucune.
7. Journal des transactions

Dfinition : Journal
Le journal est un fichier systme qui constitue un espace de stockage redondant avec la BD. Il rpertorie l'ensemble des mises jour faites sur la BD (en particulier les valeurs des enregistrements avant et aprs mise jour). Le journal est donc un historique persistant (donc en mmoire secondaire) qui mmorise tout ce qui se passe sur la BD. Le journal est indispensable pour la validation (COMMIT), l'annulation (ROLLBACK) et la reprise aprs panne de transactions. Synonymes : Log
134
C. Fiabilit et transactions
Objectifs
Apprhender la gestion des pannes dans les SGBD. Comprendre la rponse apporte par la gestion des transactions.
1. Les pannes
Une BD est parfois soumise des dfaillances qui entranent une perturbation, voire un arrt, de son fonctionnement. On peut distinguer deux types de dfaillances : Les dfaillances systme ou dfaillances douces (soft crash), par exemple une coupure de courant ou une panne rseau. Ces dfaillances affectent toutes les transactions en cours de traitement, mais pas la BD au sens de son espace de stockage physique. Les dfaillances des supports ou dfaillances dures (hard crash), typiquement le disque dur sur lequel est stocke la BD. Ces dfaillances affectent galement les transactions en cours (par rupture des accs aux enregistrements de la BD), mais galement les donnes elles-mmes.
Remarque : Annulation des transactions non termines

Lorsque le systme redmarre aprs une dfaillance, toutes les transactions qui taient en cours d'excution (pas de COMMIT) au moment de la panne sont annuls (ROLLBACK impos par le systme). Cette annulation assure le retour un tat cohrent, en vertu des proprits ACID des transactions.
Remarque : R-excution des transactions termines avec succs

Au moment de la panne certaines transactions taient peut-tre termines avec succs (COMMIT) mais non encore (ou seulement partiellement) enregistres dans la BD (en mmoire volatile, tampon, etc.). Lorsque le systme redmarre il doit commencer par rejouer ces transactions, qui assurent un tat cohrent de la BD plus avanc. Cette reprise des transactions aprs COMMIT est indispensable dans la mesure o c'est bien l'instruction COMMIT qui assure la fin de la transaction et donc la durabilit. Sans cette gestion, toute transaction pourrait tre remise en cause.
Remarque : Unit de reprise

Les transactions sont des units de travail, et donc galement de reprise.
Remarque : Dfaillance des supports

Tandis que la gestion de transactions et de journal permet de grer les dfaillances systmes, les dfaillances des supports ne pourront pas toujours tre grs par ces seuls mcanismes. Il faudra leur adjoindre des procdures de sauvegarde et de restauration de la BD pour tre capable au pire de revenir dans un tat antrieur cohrent et au mieux de rparer compltement la BD (cas de la rplication en temps rel par exemple).
2. Point de contrle
Dfinition : Point de contrle
Un point de contrle est une criture dans le journal positionne automatiquement par le systme qui
135
tablit la liste de toutes les transactions en cours (au moment o le point de contrle est pos) et force la sauvegarde des donnes alors en mmoire centrale dans la mmoire secondaire. Le point de contrle est positionn intervalles de temps ou de nombre d'entres dans le journal prdfinis. Le dernier point de contrle est le point de dpart d'une reprise aprs panne, dans la mesure o c'est le dernier instant o toutes les donnes ont t sauvegardes en mmoire non volatile. Synonymes : Syncpoint
3. Reprise aprs panne

Introduction
Le mcanisme de reprise aprs panne s'appuie sur le journal et en particulier sur l'tat des transactions au moment de la panne et sur le dernier point de contrle. Le schma ci-aprs illustre les cinq cas de figure possibles pour une transaction au moment de la panne.
tats d'une transaction au moment d'une panne
Transactions de type T1 Elles ont dbut et se sont termines avant tc. Elles n'interviennent pas dans le processus de reprise. Transactions de type T2 Elles ont dbut avant tc et se sont termines entre tc et tf. Elles devront tre rejoues (il n'est pas sr que les donnes qu'elles manipulaient aient t correctement inscrites en mmoire centrale, puisque aprs tc, or le COMMIT impose la durabilit). Transactions de type T3
136
Elles ont dbut avant tc, mais n'tait pas termines tf. Elles devront tre annules (pas de COMMIT). Transactions de type T4 Elles ont dbut aprs tc et se sont termines avant tf. Elles devront tre rejoues. Transactions de type T5 Elles ont dbut aprs tc et ne se sont pas termines. Elles devront tre annules.
Remarque
Les transactions sont des units d'intgrit.
4. Algorithme de reprise UNDO-REDO.

Introduction
L'algorithme suivant permet d'assurer une reprise aprs panne qui annule et rejoue les transactions adquates. 1. SOIT deux listes 1a. Initialiser la 1b. Initialiser la en cours au dernier REDO et UNDO liste REDO vide liste UNDO avec toutes les transactions point de contrle
2. FAIRE une recherche en avant dans le journal, partir du point de contrle 2a. SI une transaction T est commence ALORS ajouter T UNDO 2b. SI une transaction T est termine avec succs alors dplacer T de UNDO REDO 3. QUAND la fin du journal est atteinte 3a. Annuler les transactions de la liste UNDO (reprise en arrire) 3b. Rejouer les transactions de la liste REDO (reprise en avant) 4. TERMINER la reprise et redevenir disponible pour de nouvelles instructions
Exemple
137
tats d'une transaction au moment d'une panne

Transactions de type T1 Non prises en compte par l'algorithme. Transactions de type T2 Ajoutes la liste UNDO (tape 1b) puis dplace vers REDO (tape 2b) puis rejoue (tape 3b). Transactions de type T3 Ajoutes la liste UNDO (tape 1b) puis annule (tape 3a). Transactions de type T4 Ajoutes la liste UNDO (tape 2a) puis dplace vers REDO (tape 2b) puis rejoue (tape 3b). Transactions de type T5 Ajoutes la liste UNDO (tape 2a) puis annule (tape 3a).
5. Ecriture en avant du journal.

Fondamental
On remarquera que pour que la reprise de panne soit en mesure de rejouer les transactions, la premire action que doit effectuer le systme au moment du COMMIT est l'criture dans le journal de cette fin correcte de transaction. En effet ainsi la transaction pourra tre rejoue, mme si elle n'a pas eu le temps de mettre effectivement jour les donnes dans la BD, puisque le journal est en mmoire secondaire.
138
* * *
On voit que la gestion transactionnelle est un appui important la reprise sur panne, en ce qu'elle assure des tats cohrents qui peuvent tre restaurs.
D. Concurrence et transactions
Objectifs
Apprhender la gestion de la concurrence dans les SGBD. Comprendre la rponse apporte par la gestion des transactions.
1. Trois problmes soulevs par la concurrence.

Introduction
Nous proposons ci-dessous trois problmes poss par les accs conccurents des transactions aux donnes.
a) Perte de mise jour

Temps t1 t2 t3 t4 t5 t4 LIRET ... UPDATET ... COMMIT LIRET ... UPDATET ... COMMIT TransactionA TransactionB
Tableau 17 Problme de la perte de mise jour du tuple T par la transaction A Les transaction A et B accdent au mme tuple T ayant la mme valeur respectivement t1 et t2. Ils modifient chacun la valeur de T. Les modifications effectues par A seront perdues puisqu'elle avait lu T avant sa modification par B.
Exemple
139

Temps t1 t2 t3 t4 t5 t6 A:Ajouter100 LIRECOMPTE C=1000 ... UPDATECOMPTE C=C+100=1100 ... COMMIT C=1100 LIRECOMPTE C=1000 ... UPDATECOMPTE C=C+10=1010 ... COMMIT C=1010 B:Ajouter10
Tableau 18 Doucle crdit d'un compte bancaire C Dans cet exemple le compte bancaire vaut 1010 la fin des deux transactions la place de 1110.
b) Accs des donnes non valides

Temps t1 t2 t3 LIRET TransactionA ... ROLLBACK TransactionB UPDATET
Tableau 19 Problme de la lecture impropre du tuple T par la transaction A La transaction A accde au tuple T qui a t modifi par la transaction B. B annule sa modification et A a donc accd une valeur qui n'aurait jamais d exister (virtuelle) de T. Pire A pourrait faire une mise jour de T aprs l'annulation par B, cette mise jour inclurait la valeur avant annulation par B (et donc reviendrait annuler l'annulation de B).
Exemple
Temps t1 t2 t3 t4 t5 t6 LIRECOMPTE C=1100 ... UPDATEC C=C+10=1110 COMMIT C=1110 A:Ajouter10 B:Ajouter100(erreur) LIRECOMPTE C=1000 UPDATECOMPTE C=C+100=1100 ... ROLLBACK C=1000
Tableau 20 Annulation de crdit sur le compte bancaire C Dans cet exemple le compte bancaire vaut 1110 la fin des deux transactions la place de 1010.
140
c) Lecture incohrente
Temps t1 t2 t3 t4 LIRET ... ... LIRET UPDATET COMMIT TransactionA TransactionB
Tableau 21 Problme de la lecture non reproductible du tuple T par la transaction A Si au cours d'une mme transaction A accde deux fois la valeur d'un tuple alors que ce dernier est, entre les deux, modifi par une autre transaction B, alors la lecture de A est inconsistente. Ceci peut entraner des incohrences par exemple si un calcul est en train d'tre fait sur des valeurs par ailleurs en train d'tre mises jour par d'autres transactions.
Remarque
Le problme se pose bien que la transaction B ait t valide, il ne s'agit donc pas du problme d'accs des donnes non valides.
Exemple
Temps t1 t2 t3 t4 t5 t6 t7 t8 A:CalculdeS=C1+C2 LIRECOMPTE1 C1=100 ... ... ... ... ... LIRECOMPTE2 C2=110 CALCULS S=C1+C2=210 LIRECOMPTE1 C1=100 LIRECOMPTE2 C2=100 UPDATECOMPTE1 C1=10010=90 UPDATECOMPTE2 C2=100+10=110 COMMIT B:Transfertde10deC1 C2
Tableau 22 Transfert du compte C1 au compte C2 pendant une opration de calcul C1+C2 Dans cet exemple la somme calcule vaut 210 la fin du calcul alors qu'elle devrait valoir 200.
2. Le verrouillage.
Introduction
Une solution gnrale la gestion de la concurrence est une technique trs simple appele verrouillage.
Dfinition : Verrou
Poser un verrou sur un objet (typiquement un tuple) par une transaction signifie rendre cet objet inaccessible aux autres transactions. Synonymes : Lock
141
Dfinition : Verrou partag

Un verrou partag, not S, est pos par une transaction lors d'un accs en lecture sur cet objet. Un verrou partag interdit aux autres transaction de poser un verrou exclusif sur cet objet et donc d'y accder en criture. Synonymes : Verrou de lecture, Shared lock, Read lock
Dfinition : Verrou exclusif

Un verrou exclusif, not X, est pos par une transaction lors d'un accs en criture sur cet objet. Un verrou exclusif interdit aux autres transactions de poser tout autre verrou (partag ou exclusif) sur cet objet et donc d'y accder (ni en lecture, ni en criture). Synonymes : Verrou d'criture, Exclusive lock, Write lock
Remarque : Verrous S multiples

Un mme objet peut tre verrouill de faon partage par plusieurs transactions en mme temps. Il sera impossible de poser un verrou exclusif sur cet objet tant qu'au moins une transaction disposera d'un verrou S sur cet objet.
Mthode : Rgles de verrouillage

Soit 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 dj d'un ou plusieurs verrous S alors A peut poser un verrou S 3. Si O dispose dj 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 dj d'un ou plusieurs verrous S ou d'un verrou X alors A ne peut pas poser de verrou X
VerrouXpr sent VerrouXdemand VerrouSdemand Demanderefus e Demanderefus e Verrou(s)Spr sent(s) Demanderefus e Demandeaccord e Pasdeverroupr Demandeaccord Demandeaccord sent e e
Tableau 23 Matrice des rgles de verrouillage
Remarque : Promotion d'un verrou

Une transaction qui dispose dj, elle-mme, d'un verrou S sur un objet peut obtenir un verrou X sur cet objet si aucune autre transaction ne dtient de verrou S sur l'objet. Le verrou est alors promu du statut partag au statut exclusif.
3. Le dverrouillage.
Dfinition : Dverrouillage
Lorsqu'une transaction se termine (COMMIT ou ROLLBACK) elle libre tous les verrous qu'elle a pos. Synonymes : Unlock
4. Protocole d'accs aux donnes.

Mthode : Rgles de verrouillage avant les lectures et critures des donnes
Soit la transaction A voulant lire des donnes 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
142
3. Sinon A attend le droit de poser son verrou (et donc que les verrous qui l'en empchent soient levs)
Soit la transaction A voulant crire des donnes 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 empchent soient levs) Soit la transaction A se terminant (COMMIT ou ROLLBACK) : 1. A libre tous les verrous qu'elle avait pos 2. Certaines transactions en attente obtiennent ventuellement le droit de poser des verrous
Remarque : Liste d'attente

Afin de rationaliser les attentes des transactions, des stratgies du type FIFO sont gnralement appliques et donc les transactions sont empiles selon leur ordre de demande.
5. Solution aux trois problmes soulevs par la concurrence.

Introduction
Le principe du verrouillage permet d'apporter une solution aux trois problmes classiques soulevs par les accs aux concurrents aux donnes par les transactions.
a) Perte de mise jour

Temps t1 t2 t3 t4 ... LIRET VerrouS ... UPDATET Attente... ... Attente... Interblocage LIRET VerrouS ... UPDATET Attente... TransactionA TransactionB
Tableau 24 Problme de la perte de mise jour du tuple T par la transaction A
Remarque
Le problme de perte de mise jour est rgl, mais soulve ici un autre problme, celui de l'interblocage.
b) Accs des donnes non valides
143

Temps t1 t2 t3 t4 VerrouS LIRET Attente... TransactionA TransactionB UPDATET VerrouX ... ROLLBACK LibrationduverrouX
Tableau 25 Problme de la lecture impropre du tuple T par la transaction A
c) Lecture incohrente
Temps t1 t2 t3 ... LIRET VerrouS ... LIRET VerrousS ...lib rationdesverrous... UPDATET Attente... ... ...reprisedelatransaction... TransactionA TransactionB
Tableau 26 Problme de la lecture non reproductible du tuple T par la transaction A
Remarque
La lecture reste cohrente car aucune mise jour ne peut intervenir pendant le processus de lecture d'une mme transaction.
6. Inter-blocage
Dfinition : Inter-blocage
L'inter-blocage est le phnomne qui apparait quand deux transactions (ou plus, mais gnralement deux) se bloquent mutuellement par des verrous poss sur les donnes. Ces verrous empchent chacune des transactions de se terminer et donc de librer les verrous qui bloquent l'autre transaction. Un processus d'attente sans fin s'enclenche alors. Les situations d'inter-blocage sont dtectes par les SGBD et gres, en annulant l'une, l'autre ou les deux transactions, par un ROLLBACK systme. Les mthodes utilises sont la dtection de cycle dans un graphe d'attente et la dtection de dlai d'attente trop long. Synonymes : Deadlock, Blocage, Verrou mortel
Dfinition : Cycle dans un graphe d'attente

Principe de dtection d'un inter-blocage par dtection d'un cycle dans un graphe reprsentant quelles transactions sont en attente de quelles transactions (par infrence sur les verrous poss et les verrous causes d'attente). Un cycle est l'expression du fait qu'une transaction A est en attente d'une transaction B qui est en attente d'une transaction A. La dtection d'un tel cycle permet de choisir une victime, c'est dire une des deux transactions qui sera annule pour que l'autre puisse se terminer. Synonymes : Circuit de blocage
144
Dfinition : Dlai d'attente

Principe de dcision qu'une transaction doit tre abandonne (ROLLBACK) lorsque son dlai d'attente est trop long. Ce principe permet d'viter les situations d'inter-blocage, en annulant une des deux transactions en cause, et en permettant donc l'autre de se terminer. Synonymes : Timeout
Remarque : Risque li l'annulation sur dlai

Si le dlai est trop court, il y a un risque d'annuler des transactions en situation d'attente longue, mais non bloques. Si le dlai est trop long, il y a un risque de chute des performances en situation d'inter-blocage (le temps que le systme ragisse). La dtection de cycle est plus adapte dans tous les cas, mais plus complexe mettre en uvre.
Remarque : Relance automatique

Une transaction ayant t annule suite un inter-blocage (dtection de cycle ou de dlai d'attente) n'a pas commis de "faute" justifiant son annulation. Cette dernire est juste due aux contraintes de la gestion de la concurrence. Aussi elle n'aurait pas d tre annule et devra donc tre excute nouveau. Certains SGBD se charge de relancer automatiquement les transactions ainsi annules.
E. En rsum : Les transactions

Transaction
Unit logique de travail pour assurer la cohrence de la BD mme en cas de pannes ou d'accs concurrents. Panne Mme en cas de panne, la BD doit rester cohrente. Dfaillances systme Coupure de courant, de rseau, etc. Dfaillances du support Crash disque (dans ce cas les transactions peuvent tre insuffisantes). Concurrence Dimension relevant de la conception d'application. Perte de mise jour Accs des donnes non valides Lecture incohrente Programmation Un programme peut dcider de l'annulation d'une transaction. ROLLBACK Instruction SQL d'annulation d'une transaction.
F. Bibliographie commente sur les transactions

Les transactions [w_developpez.com/hcesbronlavau] Une bonne introduction courte au principe des transactions avec un exemple trs bien choisi. Des exemples d'implmentation sous divers SGBD (InterBase par exemple)
145
SQL2 SQL3, applications Oracle [Delmal01] Une bonne description des principes des transactions, avec les exemples caractristiques, l'implmentation SQL et une tude de cas sous Oracle 8 (chapitre 5). Tutoriel de bases de donnes relationnelles de l'INT Evry [w_int-evry.fr] (http://www-inf.intevry.fr/COURS/BD/BD_REL/SUPPORT/poly.html#RTFToC30 Un aperu gnral de l'ensemble de la problmatique des transactions, de la concurrence et de la fiabilit. Programmation SQL [Mata03] Un exemple d'excution de transactions (pages 20-23)
146
VIII -
L'OPTIMISATION DU SCHMA
Introduction l'optimisation des BD En rsum : L'optimisation Bibliographie commente sur l'optimisation
INTERNE
VIII
184 189 189
La conception des SGBDR exige qu'une attention particulire soit porte la modlisation conceptuelle, afin de parvenir dfinir des modles logiques relationnels cohrents et manipulables. De tels modles relationnels, grce au langage standard SQL, prsentent la particularit d'tre implmentables sur toute plate-forme technologique indpendamment de considrations physiques. Nanmoins l'on sait que dans la ralit, il est toujours ncessaire de prendre en considration les caractristiques propres de chaque SGBDR, en particulier afin d'optimiser l'implmentation. Les optimisations concernent en particulier la question des performances, question centrale dans les applications de bases de donnes, qui, puisqu'elles manipulent des volumes de donnes importants, risquent de conduire des temps de traitement de ces donnes trop longs par rapport aux besoins d'usage. Chaque SGBDR propose gnralement des mcaniques propres pour optimiser les implmentations, et il est alors ncessaire d'acqurir les comptences particulires propres ces systmes pour en matriser les arcanes. Il existe nanmoins des principes gnraux, que l'on retrouvera dans tous les systmes, comme par exemple les index, les groupements ou les vues matrialises. Nous nous proposerons d'aborder rapidement ces solutions pour en examiner les principes dans le cadre de ce cours. Nous aborderons galement quelques techniques de conception, qui consistent revenir sur la structure propose par l'tape de modlisation logique, pour tablir des modles de donnes plus aptes rpondre correctement des questions de performance. La dnormalisation ou le partitionnement en sont des exemples.
A. Introduction l'optimisation des BD

Objectifs
Assimiler la problmatique de la performance en bases de donnes Connatre les grandes classes de solutions technologiques existantes aux problmes de performance Connatre et savoir mobiliser les techniques de conception permettant d'optimiser les performances d'une BD
1. Schma interne et performances des applications

La passage au schma interne (ou physique), i.e. l'implmentation du schma logique dans un SGBD
147
L'optimisation du schma interne
particulier, dpend de considrations pratiques lies aux performances des applications. Les possibilits d'optimisation des schmas internes des BD dpendent essentiellement des fonctions offertes par chaque SGBD. On peut nanmoins extraire certains principes d'optimisation des schmas internes suffisamment gnraux pour tre applicables dans la plupart des cas.
2. valuation des besoins de performance

a) lments surveiller
Pour optimiser un schma interne, il est d'abord ncessaire de reprer les aspects du schma logique qui sont succeptible de gnrer des problmes de performance. On pourra citer titre d'exemple les paramtres surveiller suivants : Taille des tuples Nombre de tuples Frquence d'excution de requtes Complexit des requtes excutes (nombre de jointures, etc.) Frquence des mises jour (variabilit des donnes) Accs concurents Distribution dans la journe des accs Qualit de service particulire recherche Paramtrabilit des excutions etc.
b) valuation des cots

Une fois les lments de la BD valuer reprs, il faut mesurer si oui ou non ils risquent de poser un problme de performance. L'valuation des performances peut se faire : Thoriquement En calculant le cot d'une opration (en temps, ressources mmoires, etc.) en fonction de paramtres (volume de donnes, disparit des donnes, etc.). En gnral en BD le nombre de paramtres est trs grand, et les calculs de cots trop complexes pour rpondre de faon prcise aux questions poses. Empiriquement En ralisant des implmentations de parties de schma et en les soumettant des tests de charge, en faisant varier des paramtres. Ce modle d'valuation est plus raliste que le calcul thorique. Il faut nanmoins faire attention ce que les simplifications d'implmentation faites pour les tests soient sans influence sur ceux-ci.
c) Proposition de solutions
Une fois certains problmes de performance identifis, des solutions d'optimisation sont proposes, puis values pour vrifier leur impact et leur rponse au problme pos. Parmi les solutions d'optimisation existantes, on pourra citer : L'indexation La dnormalisation Le regroupement (clustering) de tables Le partitionnement vertical et horizontal Les vues concrtes
148
3. Indexation
Dfinition : Index
Un index est une structure de donnes qui permet d'acclrer les recherches dans une table en associant une cl d'index (la liste des attributs indexs) l'emplacement physique de l'enregistrement sur le disque. Les accs effectues sur un index peuvent donc se faire sur une liste trie au lieu de se faire par parcours squentiel des enregistrements.
Mthode : Cas d'usage

Les index doivent tre utiliss sur les tables qui sont frquemment soumises des recherches. Ils sont d'autant plus pertinents que les requtes slectionnent un petit nombre d'enregistrements (moins de 25% par exemple). Les index doivent tre utiliss sur les attributs : souvent mobiliss dans une restriction, donc une jointure trs discrimins (c'est dire pour lesquels peu d'enregistrements ont les mmes valeurs) rarement modifis Les index diminuent les performances en mise jour (puisqu'il faut mettre jour les index en mme temps que les donnes). Les index ajoutent du volume la base de donnes et leur volume peut devenir non ngligeable.
Syntaxe : Syntaxe Oracle

CREATE INDEX nom_index ON nom_table (NomColonneCl1, NomColonneCl2, ...);
Remarque : Index implicites

La plupart des SGBD crent un index pour chaque cl (primaire ou candidate). En effet la vrification de la contrainte d'unicit chaque mise jour des donnes justifie elle seule la prsence de l'index.
Attention : Attributs indexs utiliss dans des fonctions

Lorsque les attributs sont utiliss dans des restrictions ou des tris par l'intermdiaire de fonctions, l'index n'est gnralement pas pris en compte. L'opration ne sera alors pas optimise. Ainsi par exemple dans le code suivant, le restriction sur X ne sera pas optimise mme s'il existe un index sur X. SELECT * FROM T WHERE ABS(X) > 100 Cette non prise en compte de l'index est logique dans la mesure o, on le voit sur l'exemple prcdent, une fois l'attribut soumis une fonction, le classement dans l'index n'a plus forcment de sens (l'ordre des X, n'est pas l'ordre des valeurs absolues de X). Lorsqu'un soucis d'optimisation se pose, on cherchera alors sortir les attributs indexs des fonctions. Notons que certains SGBD, tels qu'Oracle partir de la version 8i, offrent des instructions d'indexation sur les fonctions qui permettent une gestion de l'optimisation dans ce cas particulier SQL2 SQL3, applications Oracle [Delmal01].
4. Dnormalisation
La normalisation est le processus qui permet d'optimiser un modle logique afin de le rendre non redondant. Ce processus conduit la fragmentation des donnes dans plusieurs tables.
Dfinition : Dnormalisation
Processus consistant regrouper plusieurs tables lies par des rfrences, en une seule table, en ralisant
149
statiquement les oprations de jointure adquates. L'objectif de la dnormalisation est d'amliorer les performances de la BD en recherche sur les tables considres, en implmentant les jointures plutt qu'en les calculant.
Remarque : Dnormalisation et redondance

La dnormalisation est par dfinition facteur de redondance. A ce titre elle doit tre utilise bon escient et des moyens doivent tre mis en oeuvre pour contrler la redondance cre.
Mthode : Quand utiliser la dnormalisation ?

Un schma doit tre dnormalis lorsque les performances de certaines recherches sont insuffisantes et que cette insuffisance pour cause des jointures. La dnormalisation peut galement avoir un effet nfaste sur les performances : En mise jour Les donnes redondantes devant tre dupliques plusieurs fois. En contrle supplmentaire Les moyens de contrle ajouts (triggers, niveaux applicatifs, etc.) peuvent tre trs couteux. En recherche cible Certaines recherches portant avant normalisation sur une "petite" table et portant aprs sur une "grande" table peuvent tre moins performantes aprs qu'avant.
5. Groupement de tables
Dfinition : Groupement de table
Un groupement ou cluster est une structure physique utilise pour stocker des tables sur lesquelles doivent tre effectues de nombreuses requtes comprenant des oprations de jointure. Dans un groupement les enregistrements de plusieurs tables ayant une mme valeur de champs servant une jointure (cl du groupement) sont stockes dans un mme bloc physique de la mmoire permanente. Cette technique optimise donc les oprations de jointure, en permettant de remonter les tuples joints par un seul accs disque.
Dfinition : Cl du groupement
Ensemble d'attributs prcisant la jointure que le groupement doit optimiser.
Syntaxe : Syntaxe sous Oracle

Il faut d'abord dfinir un groupement, ainsi que les colonnes (avec leur domaine), qui constituent sa cl. On peut ainsi ensuite, lors de la cration d'une table prciser que certaines de ses colonnes appartiennent au groupement. CREATE CLUSTER nom_cluster (NomColonneCl1 type, NomColonneCl2 type, ...); CREATE TABLE nom_table (...) CLUSTER nom_cluster (Colonne1, Colonne2, ...);
Remarque
Le clutering diminue les performances des requtes portant sur chaque table prise de faon isole, puisque les enregistrements de chaque table sont stocks de faon clate.
Remarque : Groupement et dnormalisation

Le groupement est une alternative la dnormalisation, qui permet d'optimiser les jointures sans crer de redondance.
150
6. Partitionnement de table
Dfinition : Partitionnement de table
Le partitionnement d'une table consiste dcouper cette table afin qu'elle soit moins volumineuse, permettant ainsi d'optimiser certains traitements sur cette table. On distingue : Le partitionnement vertical, qui permet de dcouper une table en plusieurs tables, chacune ne possdant qu'une partie des attributs de la table initiale. Le partitionnement horizontal, qui permet de dcouper une table en plusieurs tables, chacune ne possdant qu'une partie des enregistrements de la table initiale.
a) Implmentation de projection Dfinition : Partitionnement vertical

Technique consistant implmenter deux projections ou plus d'une table T sur des table T1, T2, etc. en rptant la cl de T dans chaque Ti pour pouvoir recomposer la table initiale par jointure sur la cl Bases de donnes : objet et relationnel [Gardarin99].
Remarque
Ce dcoupage quivaut considrer l'entit diviser comme un ensemble d'entits relies par des associations 1:1.

Un tel dcoupage permet d'isoler des attributs peu utiliss d'autres trs utiliss, et ainsi amliore les performances lorsque l'on travaille avec les attributs trs utiliss (la table tant plus petite). Cette technique diminue les performances des oprations portant sur des attributs ayant t rpartis sur des tables diffrentes (une opration de jointure tant prsent requise). Le partitionnement vertical est bien entendu sans intrt sur les tables comportant peu d'attributs.
b) Implmentation de restriction Dfinition : Partitionnement horizontal

Technique consistant diviser une table T en plusieurs sous-table T1, T2, etc. selon des critres de restriction Bases de donnes : objet et relationnel [Gardarin99] et de telle faon que tous les tuples de T soit conservs. La table T est alors recomposable par union sur les Ti.

Un tel dcoupage permet d'isoler des enregistrements peu utiliss d'autres trs utiliss, et ainsi amliore les performances lorsque l'on travaille avec les enregistrements trs utiliss (la table tant plus petite). C'est le cas typique de l'archivage. Un autre critre d'usage est le fait que les enregistrements soient toujours utiliss selon un partitionnement donn (par exemple le mois de l'anne). Cette technique diminue les performances des oprations portant sur des enregistrements ayant t rpartis sur des tables diffrentes (une opration d'union tant prsent requise). Le partitionnement horizontal est bien entendu sans intrt sur les tables comportant peu d'enregistrements.
7. Vues concrtes
Un moyen de traiter le problme des requtes dont les temps de calcul sont trs longs et les frquences de mise jour faible est l'utilisation de vues concrtes.
151
Dfinition : Vue concrte

Une vue concrte est un stockage statique (dans une table) d'un rsultat de requte. Un accs une vue concrte permet donc d'viter de recalculer la requte et est donc aussi rapide qu'un accs une table isole. Il suppose par contre que les donnes n'ont pas t modifies (ou que leur modification est sans consquence) entre le moment o la vue a t calcule et le moment o elle est consulte. Une vue concrte est gnralement recalcule rgulirement soit en fonction d'un vnement particulier (une mise jour par exemple), soit en fonction d'un moment de la journe ou elle n'est pas consulte et o les ressources de calcul sont disponibles (typiquement la nuit). Synonymes : Vue matrialise
B. En rsum : L'optimisation
Optimisation
Modification du schma interne d'une BD pour en amliorer les performances. Techniques au niveau physique Indexation Regroupement physique Vue concrte Techniques de modlisation Dnormalisation Partitionnement Horizontal Vertical
C. Bibliographie commente sur l'optimisation

SQL2 SQL3, applications Oracle [Delmal01] Une bonne description des index (page 79) et clusters (page 81) par l'image. Une description intressante d'une fonction (sous Oracle 8i) qui permet d'indexer des fonctions, ce qui rpond un problme important d'optimisation (page 84). Une description des vues matrialises, leur implmentation sous Oracle, des exemples d'usage dans le domaine du datawarehouse. Bases de Donnes Relationnelles et Systmes de Gestion de Bases de Donnes Relationnels, le Langage SQL [w_supelec.fr/~yb] Des informations gnrales sur les index3 et sur les clusters4.
3 - http://wwwsi.supelec.fr/~yb/poly_bd/node122.html 4 - http://wwwsi.supelec.fr/~yb/poly_bd/node126.html S. Crozat - UTC 2009
152
Ouvrage de rfrence conseill

IX -
SQL2 SQL3, applications Oracle [Delmal01] Cet ouvrage aborde tous les thmes du cours de faon claire et illustre, en dehors de la phase de modlisation.
153
Questions de synthse
En quoi une base de donnes est-elle plus intressante qu'un systme de fichier classique ?
Quelles sont les fonctions remplies par un SGBD ?
Pourquoi est-ce que l'on distingue trois niveaux de modlisation lors de la conception d'une base de donnes ?
155
Quelles est la diffrence entres le schma conceptuel et le ou les schmas externes ?
Quelles sont les fonctions d'un langage orient donnes ?
A quoi et qui sert un dictionnaire de donnes ?
Pourquoi est-il fondamental mais difficile de parvenir un MCD correct ?
156
Enoncer quelques actions mener pour raliser une spcification gnrale de l'existant et des besoins ?
Qu'est ce qui diffrencie fondamentalement un MCD d'un MLD ?
Quels sont les principaux lments du diagramme de classes UML ?
Quelles sont les diffrences et points communs entre la diagramme de classe UML et le modle E-A tendu ?
157
A quoi servent les classes abstraites ?
Quand doit-on expliciter des contraintes sur les associations ?
Quand doit-on utiliser les paquetages ?
Enoncer les principaux lments composants le modle E-A ?
158
Quels sont les avantages apports par l'extension du modle E-A ?
Que permet d'exprimer une entit de type faible ?
Qu'est ce qu'un domaine ?
Quel rapport y-a-t il entre une relation et une table ?
159
Comment identifie-t-on un attribut d'une relation ?
Comment identifie-t-on un enregistrement d'une relation ?
Quelle problme pose la redondance et comment le rsoudre ?
Le passage UML vers relationnel est-il systmatique ou soumis interprtation ? Pourrait-il tre ralis par un algorithme ?
160
Pourquoi dispose-t-on de trois mthodes pour traduire l'hritage dans un modle relationnel ? Ces trois mthodes sont-elles quivalentes ?
Quels sont les oprateurs algbriques de base ? Quels sont les autres oprateurs ? Qu'est ce qui les diffrencie ?
Quels sont les oprateurs ensemblistes ? Qu'est ce qui les caractrise ?
Pourquoi la jointure est-elle un oprateur essentiel ?
161
Qu'est ce qui diffrencie une jointure externe d'une jointure classique ?
A quoi sert le LDD ?
En quoi le LDD est il un langage dclaratif ?
Quel rapport y-a-t il entre le LDD et le concept de relation ?
162
A quoi sert le LMD ?
Quel rapport y-a-t il entre le SQL et l'algbre relationnelle ?
Pourquoi SQL n'est-il pas un langage de programmation ?
Quels types de droits peuvent tre accords ou rvoqus en SQL ?
163
Pourquoi peut-on dire que la gestion des droits est dcentralise en SQL ?
En quoi peut-on dire que certains schmas relationnels sont mauvais ?
Pourquoi est-il primordial de reprer les dpendances fonctionnelles sur un schma relationnel ?
Comment repre-t-on ces dpendances fonctionnelles ?
164
Que sont les axiomes d'Armstrong et quoi servent-ils ?
Qu'est ce que la dcomposition d'une relation ?
Pourquoi le respect de la premire forme normale reste-t-il en partie subjectif ?
Quelle forme normale est gnralement souhaitable pour un schma relationnel ?
165
Quels sont les atouts du modle relationnel-objet par rapport au modle relationnel ?
Quels sont les extensions les plus importantes apports par le modle relationnel-objet au modle relationnel ?
En quoi le modle relationnel-objet peut-il tre considr comme plus proche que le modle relationnel du modle conceptuel ?
En quoi le mapping E-A vers relationnel-objet est-il plus fidle que le mapping E-A vers relationnel ?
166
Dans quel cas l'utilisation de collections peut-il tre destructeur de smantique ?
En quoi l'implmentation de l'hritage en relationnel-objet simplifie-t-il le mapping ? En quoi ne le simplifie-t-il pas ?
Qu'apporte les OID par rapport aux cls trangres classiquement manipules dans le modle relationnel ?
Quelles solutions de modlisation apporte les instructions de cration de type sous Oracle ?
167
L'utilisation d'OID pour les rfrences est-elle prfrable l'utilisation de cls trangres classique, en particulier dans le cas o la cl trangre est compose ?
Pourquoi une transaction est-elle atomique ?
Pourquoi une transaction est-elle cohrente ?
Pourquoi une transaction est-elle isole ?
168
Pourquoi une transaction est-elle durable ?
A quoi sert le journal des transactions ?
Qu'est ce qu'un point de contrle ?
L'aglorithme de reprise UNDO-REDO terminera-t-il toutes les transactions qui taient commences au moment de la panne ?
169
Laquelle des proprits ACID des transactions est-elle particulirement utile pour grer les accs concurrents ?
Le verrouillage est-il une solution parfaite pour la gestion de la concurrence ?
Pourquoi peut-on dire que les transactions sont les unit logique de travail, les units d'intgrit, les units de reprise et les units de concurrence ?
Citer des paramtres propres une BD que l'on doit surveiller dans le cadre de la performance ?
170
Peut-on anticiper sur des problmes de performance futurs lors de la conception d'une BD ?
Pourquoi n'indexe-t-on pas tous les champs d'une BD ?
Quels problmes pose la dnormalisation ?
Quels problmes pose le clustering ?
171
Quels problmes pose le partionnement ?
Quels problmes pose les vues concrtes ?
172
Solution des exercices de TD

> Solution n1 (exercice p. 73)
Intersection (R1, R2) = Difference (R1, Difference (R1, R2))

Jointure (R1, R2, condition) = Restriction ( Produit (R1, R2), condition)

Considrons la division de R1 par R2 : Soit Ai les attribut de R1 n'appartenant pas R2 Soit R_p = Projection (R1, Ai) Soit R_px2 = Produit (R_p, R2) Soit R_px2-1 = Difference (R_px2, R1) Soit R_px2-1p = Projection (R_px2-1, Ai) Division (R1, R2) = Difference (R_p, R_px2-1p) Notons ce que reprsente les relations intermdiaires : "R_p" est la relation obtenu partir de R1 en ne gardant que les attributs n'appartenant pas R2. Cette relation est de mme schma que la relation rsultat. "R_px2" est la relation qui combine tous les tuples de R2 avec les tuples de la relation R_p. Cette relation est de mme schma que R1, et elle contient tous les tuples possibles, et non seulement ceux qui correspondent au rsultat. "R_px2-1" est la relation qui restreint R_px2 au tuples n'appartenant pas R1, elle contient donc tous les mauvais tuples, c'est dire tous ceux que l'on ne veut pas voir appartre dans le rsultat. "R_px2-1p" est la relation de mme schma que le rsultat, et donc qui contient les mauvais tuples. Le rsultat de la division est obtenu par diffrence entre tous les tuples possibles (R_p) et tous les mauvais tuples (R_px2-1p).

Il y a trois cls candidates : {B,C}, {B,E} et {B,G}, soit la concatnation des colonnes B et C, ou B et E ou Bet G. Ce sont en effet les plus petites combinaisons qui sont uniques pour cette relation, et donc qui permettent de distinguer deux enregistrements. Pour toutes les autres combinaisons, soit elles ne sont pas uniques, soit elles contiennent {B,C}, {B,E} ou {B,G}.
173
La cl primaire peut donc tre choisie parmi ces trois candidates.

La relation contient des redondances : les colonnes A, D et F d'une part et E et G d'autre part sont redondantes. En effet pour une valeur donne de A, on obtient toujours les mmes valeurs de D et F et pour une valeur donne de E on obtient toujours la mme valeur de G.

La seule solution pour supprimer les redondances est de dcouper la relation R en relations non redondantes.
A 0 0 0 0 1 0 1 1 1 2 1 1 2 3 4 1 B 1 1 2 3 3 3 3 4 C 5 9 6 7 7 9 8 9 E
Tableau 27 Relation R1
A 0 1 10 20 D X Y F
E 5 9 6 7 8 A G S D F G
174
Glossaire
Constructeur d'objet En programmation oriente objet, un constructeur d'objet est une mthode particulire d'une classe qui permet d'instancier un objet de cette classe. L'appel cette mthode de classe a donc pour consquence la cration d'un nouvel objet de cette classe. Exception Une exception est un vnement gnr par un systme informatique pour signifier une erreur d'excution. La gestion des exceptions est un aspect de la programmation informatique, qui consiste intercepter ces vnements particuliers et les traiter pour, soit les corriger automatiquement, soit en donner une information approprie un utilisateur humain. Impedance mismatch Le terme d'impedance mismatch renvoie au dcalage qui peut exister entre le niveau d'abstraction de deux langages qui ont travailler sur des structures de donnes communes, par exemple un langage applicatif objet et un langage de donnes relationnel. L'impedance mismatch a des consquences ngatives en terme de complexification de l'implmentation et en terme de performance, puisqu'il faut constamment passer d'une structure de donnes l'autre. RAID La technologie RAID permet de repartir de l'information stocker sur plusieurs "petits" disques, au lieu de la concentrer sur un seul "gros" disque. Cette technologie permet donc d'amliorer les performances (les accs disques pouvant tre parallliss) et d'amliorer la sret (en repartissant les risques de crash et en jouant sur une redondance des donnes). Il existe plusieurs types d'architecture RAID, privilgiant ou combinant la paralllisation et la redondance. Serveur Un serveur est un programme informatique qui a pour fonction de recevoir des requtes d'un autre programme, appel client, de traiter ces requtes et de renvoyer en retour une rponse. Notons qu'un programme peut-tre serveur vis vis d'un programme et client vis vis d'un autre. On ne prend pas ici le terme serveur dans son acception matrielle, qui signifie alors un ordinateur qui a pour fonction d'hberger des programmes serveurs.
175
Signification des abrviations

1NF 2NF 3NF 4NF 5NF ACID ANSI API BCNF BD DF DFE E-A E-R FIFO IHM ISO LCD LDD LMD MCD MLD OID OMG PSM RO SGBD SGBDOO SGBDR SGBDRO SGF SI SQL UML XML First Normal Form Second Normal Form Third Normal Form Fourth Normal Form Fifth Normal Form Atomicity, Consistency, Isolation, Durability American National Standards Institute Application Program Interface Boyce-Codd Normal Form Base de Donnes Dpendance Fonctionnelle Dpendance Fonctionnelle Elmentaire Entit-Association Entity-Relationship First In First Out Interaction Homme Machine ou Interface Homme Machine International Standardization Organization Langage de Contrle de Donnes Langage de Dfinition de Donnes Langage de Manipulation de Donnes Modle Conceptuel de Donnes Modle Logique de Donnes Object Identifier Object Management Group Persistent Stored Modules Relationnel-Objet Systme de Gestion de Bases de Donnes Systme de Gestion de Bases de Donnes Orientes Objets Systme de Gestion de Bases de Donnes Relationnelles Systme de Gestion de Bases de Donnes Relationnelles-Objets Systme de Gestion de Fichiers Systme d'Information Structured Query Language Unified Modeling Language eXtensible Markup Language
177
Bibliographie
[C el ko00] C ELK JO O E
. SQL avanc : Programmation et techniques avances. Vuibert, 2000.
[C h en 76] C EN P.P . The entity-Relationsheep Model - Towards a Unified View of Data. ACM Transactions H on Database systems. 1976-mars. 1, 1. [C odd70] C D EF O D
, A relational model for large shared data banks, Communications de l'ACM, juin 1970.
[Del m al 01] D ELM PIER E AL R
. SQL2 SQL3, applications Oracle. De Boeck Universit, 2001.
[Gar dar i n 99] G D R G R ES AR A IN EO G [M at a03] M ATA-TO LED R O A O AM N . Ediscience, 2003. [M u ll er 98] M LLER P.A U . [Pr at t 01] PR TT PH A ILIP J. 2001.
. Bases de donnes : objet et relationnel. Eyrolles, 1999. , C S M N PAU U H A LIN K E .
. Programmation SQL.
, Modlisation objet avec UML, Eyrolles, 1998.
. Initiation SQL : Cours et exercices corrigs. Eyrolles, Collection Noire.
[Roqu es 04] R Q ES PAS AL O U C , VA LLE FR C AN K . UML 2 en action : De l'analyse des besoins la conception J2EE. ISBN 2-212-11462-1 (3me dition). Paris : Eyrolles, 2004. 385 p. architecte logiciel. [S ou t ou 02] SO TO C R TIAN U U H IS
. De UML SQL : Conception de bases de donnes. Eyrolles, 2002.
[Tar di eu 83] TA D R IEU H . , R C FELD A O H . , C LLETI R O . outils. Paris : Les Editions d'Organisation, 1983.
. Mthode MERISE Tome 1 : Principes et
[Tar di eu 85] TA D R IEU H . , R C FELD A O H . , C LLETI R O . , PA ET G N . ,V H G A EE . Mthode MERISE Tome 2 : Dmarche et pratiques. Paris : Les Editions d'Organisation, 1985.
179
[w _devel oppez .com / h ces br on l avau ] C ESB O -LA AU H R R N V EN Y , Les transactions, http://www.developpez.com/hcesbronlavau/Transactions.htm, 2002. [w _di a] Dia, http://live.gnome.org/Dia [w _in t -evr y.fr ] D EFU E B U O D R N , Tutoriel de bases de donnes relationnelles de l'INT Evry, http://www-inf.intevry.fr/COURS/BD/, consult en 2009. [w _j ou r n al du n et .com (1)] M R N JR M O LO E , UML en 5 tapes, http://developpeur.journaldunet.com/dossiers/alg_uml.shtml, 2004. [w _j ou r n al du n et .com (2)] B R ER X IER O D IE AV , Cinq petits conseils pour un schma UML efficace, http://developpeur.journaldunet.com/tutoriel/cpt/031013cpt_uml5conseils.shtml, 2004. [w _mh u bi ch e.devel oppez .com ] H B H M EN E U IC E AX C , Comprendre les jointures dans Access, http://mhubiche.developpez.com/Access/tutoJointures/, consult en 2009. [w _obj ect eer i n g] Objecteering software. www.objecteering.com. [2002-septembre]. [w _su pel ec.fr / ~yb ] B U D YO O R A LAIN E , Bases de Donnes Relationnelles et Systmes de Gestion de Bases de Donnes Relationnels, le Langage SQL, http://wwwsi.supelec.fr/~yb/poly_bd/, consult en 2009. [w _s ybas e] Sybase PowerDesigner, http://www.sybase.com/products/enterprisemodeling, consult en 2002. [w _u m l .fr ee.fr ] UML en Franais, http://uml.free.fr, consult en 2002. [w _u n i v- l yon 2.fr / ~j dar m ont ] D R O T JR M A M N E janvier].
. Tutoriel SQL. http://eric.univ-lyon2.fr/~jdarmont/tutoriel-sql/. [2004-
180
Index
1:N p.117 1NF p.104, 111, 112 2NF p.104 3NF p.105, 106 Abstraite.................................... p.32 Acces p.134 ACID p.132 Administration................... p.13, 17 Agrgat.............................. p.88, 89 Algbre p.46, 67, 67, 68, 69, 69, 70, 70, 71, 71, 72, 73 ALL p.92 ALTER TABLE.................. p.80, 81 Analyse....... p.17, 18, 19, 19, 19 AND p.85 Annulation.............................. p.132 ANY p.93 Armstrong..................... p.100, 100 Association p.26, 30, 31, 39, 50, 50, 55, 56, 57, 64, 117, 117 Association 1:1.......................... p.55 Atomicit................................. p.104 Attente..................................... p.142 Attribut p.24, 30, 40, 47, 48, 48, 49, 52, 56, 56 Attribut composite.................. p.116 Attribut driv......................... p.116 Attribut multi-valu................ p.116 BCNF p.106 BD p.9, 11, 11 BETWEEN................................. p.85 BLOB p.117 Boolean................................... p.117 Calcul p.88 Cardinalit......................... p.27, 39 Cartsien................................... p.70 Catalogue.................................. p.17 CHECK..................................... p.78 Classe p.14, 24, 28, 32, 54, 56, 112 Cl p.41, 48, 49, 52, 102 Cl artificielle........................... p.49
Cl candidate............................ p.48 Cl trangre...... p.113, 117, 122 Cl primaire...................... p.48, 49 Cl signifiante........................... p.49 Cluster.................................... p.150 Codd p.46 Cohrence p.131, 132, 132, 139 Collection p.113, 116, 117, 119, 122 COMMIT...................... p.133, 138 Comparaison............................. p.85 Composition....................... p.31, 57 Conception.... p.9, 13, 17, 18, 98 Conceptuel p.9, 14, 15, 18, 19, 19, 21, 23, 23, 29, 37, 37, 54, 63, 66 Concurrence....... p.131, 139, 143 Condition................................... p.85 Constructeur........................... p.120 Contrainte............................... p.119 Contraintes........................ p.34, 63 Contrle............................. p.13, 94 CREATE INDEX..................... p.149 CREATE TABLE............. p.77, 119 CREATE TYPE............. p.117, 119 CREATE VIEW......................... p.79 Cration.................................... p.76 Dclaratif.................................. p.76 Dcomposition................ p.99, 103 Dfaillance............................. p.131 DELETE............................ p.82, 83 Dnormalisation........... p.149, 150 Dpendance.................... p.97, 103 Dverrouillage........................ p.142 DF p.99, 100, 100, 101, 101, 101, 102, 103 Diagramme................ p.23, 28, 29 Dictionnaire.............................. p.17 Diffrence.................................. p.68 DISTINCT................................. p.84 Division..................................... p.72 Domaine............. p.46, 46, 47, 76 Donne...................................... p.13 Donnes..................................... p.14
Droits p.94 DROP p.80 Durabilit............................... p.134 Dynamique................................ p.34 E-A p.14, 19, 21, 26, 27, 37, 37, 37, 39, 39, 40, 41, 64, 64, 65, 65, 66 Ecriture................................... p.141 Enregistrement.................. p.47, 48 Entit p.37, 40, 41, 64, 116 valuation.............................. p.148 EXCEPT.................................... p.87 Excution................................ p.132 EXISTS...................................... p.92 Externe............................... p.15, 71 Fermeture............................... p.101 Fonction.......................... p.88, 117 FOREIGN KEY......................... p.78 FROM p.84 FUNCTION............................ p.117 GRANT...................................... p.94 GROUP BY............................... p.89 Groupement............................ p.150 HAVING.................................... p.89 Hritage p.27, 32, 40, 57, 59, 59, 60, 61, 63, 65, 114, 117 IN p.85, 91 Index p.149 INNER....................................... p.86 INSERT.............................. p.82, 82 INSERT INTO............... p.120, 123 Instance............................. p.14, 15 Inter-blocage................ p.143, 144 Interne....................................... p.15 INTERSECT.............................. p.87 Intersection............................... p.68 IOD p.123 IS NULL.................................... p.85 JOIN p.86 Jointure...................... p.70, 71, 71 Journal............... p.134, 135, 138 Langage...... p.13, 16, 82, 84, 90 LCD p.16, 94
181
LDD p.16, 76, 114 Lecture.................................... p.141 LEFT p.86 Lien p.50, 50 LIKE p.85 LMD p.16, 82, 84, 90 Logique. p.9, 13, 14, 21, 45, 45, 46, 54, 63, 66, 85, 97, 103 Manipulation............................. p.67 MERISE..................... p.19, 21, 37 Mthode p.25, 112, 116, 116, 119, 121 Modle p.9, 13, 14, 21, 21, 37, 45, 46, 52, 53, 97, 103, 111 N:M p.117 Naturelle.................................... p.71 NESTED TABLE........... p.119, 122 NF p.103 Nomalisation................... p.97, 103 Normalisation p.99, 99, 100, 100, 101, 101, 101, 102, 103, 103, 104, 104, 105, 109, 149 NOT p.85 NOT NULL................................ p.78 Objet p.110, 114, 115, 120 Occurence................................. p.14 OID p.115, 127 OMG p.23 Oprateur.................................. p.85 Opration........................... p.25, 46 Optimisation p.13, 97, 103, 147, 148 OR p.85 Oracle p.133 ORDER BY................................ p.88
OUTER...................................... p.86 Panne p.134, 135, 135, 136, 137 Partitionnement...................... p.151 Passage.............. p.54, 63, 65, 66 Performance........................... p.148 Perte p.139 Physique............................ p.13, 14 PL/SQL......................... p.123, 133 Point de contrle p.135, 136, 137 PRIMARY KEY.......................... p.78 Problme................................... p.98 Produit....................... p.46, 47, 70 Projection........................ p.69, 151 Proprit.................... p.24, 30, 40 Question............................. p.84, 90 Redondance p.12, 97, 98, 103, 149 Rfrence...................... p.113, 115 REFERENCES.......................... p.78 Relation p.47, 47, 48, 48, 49, 50, 50, 52, 52 Relationnel p.11, 14, 21, 45, 45, 46, 46, 47, 52, 53, 54, 54, 55, 56, 56, 57, 57, 59, 59, 60, 61, 63, 63, 63, 64, 64, 65, 65, 66, 67, 67, 73, 97, 103, 109, 109 Relationnel-objet p.45, 46, 111, 124, 127 Requte...................... p.82, 84, 90 Restriction....................... p.69, 151 REVOKE................................... p.95 RIGHT....................................... p.86 ROLLBACK........ p.133, 135, 144 Schma p.9, 13, 15, 52, 53, 114, 147
Scurit..................................... p.13 SELECT........... p.84, 86, 86, 121 SGBD p.9, 11, 11, 12, 14 SGBDOO................................ p.110 SGBDRO............ p.111, 124, 127 SGBR p.13 Sous-requtes p.90, 91, 92, 92, 93 Spcifications............................ p.19 SQL p.16, 76, 82, 84, 90, 94, 117, 133 Table p.76 TABLE.................................... p.122 Table imbrique p.111, 113, 119, 122 Transaction. p.13, 132, 133, 134 Tri p.88 Tuple p.47 Type p.14, 76, 112, 113, 114, 114, 116, 116, 117, 119 UML p.14, 19, 23, 23, 24, 24, 25, 27, 28, 29, 30, 31, 32, 34, 54, 54, 55, 56, 56, 57, 57, 59, 59, 60, 61, 63, 63, 63, 66 UNDO-REDO......................... p.137 Union p.68 UNION...................................... p.87 UNIQUE.................................... p.78 Unit p.132, 132, 135, 136 UPDATE............................ p.82, 83 Utilisateur................................. p.94 Validation............................... p.132 VBA p.134 Verrou p.141, 142, 142, 143, 144 Vue p.151 WHERE...................... p.84, 86, 86
182

Base de Donnée

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Base de Donnée

Uploaded by

Copyright:

Available Formats

NF17

Version 10.01 Cours Gnral

Publi le 11 janvier 2010

TABLE DES MATIRES

Introduction I - Prsentation des bases de donnes

A. BD et SGBD : vue d'ensemble...............................................................................................................11

B. Notions gnrales pour les bases de donnes........................................................................................13

C. Les mthodes de conception de bases de donnes.................................................................................17

D. En rsum : Conception de bases de donnes.......................................................................................22

: la modlisation des bases de donnes

A. Bases du diagramme de classes UML...................................................................................................23

B. Diagramme de classes UML avanc......................................................................................................29

S. Crozat - UTC 2009

D. En rsum : Schma conceptuel............................................................................................................42 E. Bibliographie commente sur la modlisation UML.............................................................................43

III - Le niveau logique

A. Description du modle relationnel.........................................................................................................45

B. Le passage UML vers Relationnel.........................................................................................................54

C. Le passage E-A vers Relationnel...........................................................................................................64

S. Crozat - UTC 2009

E. En rsum : Schma relationnel.............................................................................................................74 F. Bibliographie commente sur le modle relationnel..............................................................................74

A. Qu'appelle-t-on SQL?............................................................................................................................75 B. Le Langage de Dfinition de Donnes de SQL.....................................................................................76

C. Gestion avec le Langage de Manipulation de Donnes de SQL............................................................82

D. Questions avec le Langage de Manipulation de Donnes de SQL........................................................84

E. Instructions avances pour le LMD de SQL..........................................................................................90

F. Le Langage de Contrle de Donnes de SQL........................................................................................94

G. En rsum : SQL....................................................................................................................................95 H. Bibliographie commente sur le SQL....................................................................................................96

V - La thorie de la normalisation relationnelle

A. Les dpendances fonctionnelles............................................................................................................97

B. Les formes normales............................................................................................................................103

S. Crozat - UTC 2009

C. Bibliographie commente sur la normalisation...................................................................................107

A. Introduction : R, OO, RO....................................................................................................................109

C. Le passage conceptuel vers relationnel-objet......................................................................................116

D. SQL3 (implmentation Oracle 9i).......................................................................................................117

F. En rsum : Le relationnel-objet..........................................................................................................129 G. Bibliographie commente sur le relationnel-objet...............................................................................129

VII - La gestion des transactions

A. Problmatique des pannes et de la concurrence..................................................................................131 B. Transactions.........................................................................................................................................132

S. Crozat - UTC 2009

E. En rsum : Les transactions................................................................................................................145 F. Bibliographie commente sur les transactions.....................................................................................145

VIII - L'optimisation du schma interne

A. Introduction l'optimisation des BD...................................................................................................147

B. En rsum : L'optimisation..................................................................................................................152 C. Bibliographie commente sur l'optimisation.......................................................................................152

153 155 173 175 177 179 181

S. Crozat - UTC 2009

S. Crozat - UTC 2009

PRSENTATION DES BASES DE

A. BD et SGBD : vue d'ensemble

Exemple : Compagnie arienne

2. Qu'est ce qu'un SGBD ?

Prsentation des bases de donnes

Exemple : Exemples de SGBD

3. Pourquoi des SGBD ?

Prsentation des bases de donnes

Les donnes relatives au personnel etc.

4. Caractristiques des SGBD

B. Notions gnrales pour les bases de donnes

S. Crozat - UTC 2009

Prsentation des bases de donnes

L'entier 486 Le vhicule (460HP59, Renault, Megane, Jaune)

Dfinition : Type de donnes

Exemple : Type de donnes

Entier = { 0, 1, 2, ... , N } Vhicule = (immatriculation, marque, type, couleur)

2. Notion de modle de donnes