Cnam Cours Base De Données

download Cnam Cours Base De Données

of 209

Transcript of Cnam Cours Base De Données

  • 8/22/2019 Cnam Cours Base De Donnes

    1/209

    Cours de bases de donnes

    Philippe Rigaux

    20 fvrier 2002

  • 8/22/2019 Cnam Cours Base De Donnes

    2/209

    2

  • 8/22/2019 Cnam Cours Base De Donnes

    3/209

    TABLE DES MATIRES 3

    Table des matires

    1 Introduction 7

    2 Prsentation gnrale 92.1 Donnes, Bases de donnes et SGBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Que doit-on savoir pour utiliser un SGBD? . . . . . . . . . . . . . . . . . . . . . . . . . 11

    2.2.1 Dfinition du schma de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.2 Les oprations sur les donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.3 Optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.4 Concurrence daccs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

    2.3 Le plan du cours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

    I Modles et langages 15

    3 Le modle Entit/Association 17

    3.1 Principes gnraux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.1.1 Bons et mauvais schmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.2 La bonne mthode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

    3.2 Le modle E/A : Prsentation informelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3 Le modle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

    3.3.1 Entits, attributs et identifiants . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3.2 Associations binaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3.3 Entits faibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.3.4 Associations gnralises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

    3.4 Avantage et inconvnients du modle E/A . . . . . . . . . . . . . . . . . . . . . . . . . . 303.5 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

    4 Le modle relationnel 354.1 Dfinition dun schma relationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2 Passage dun schma E/A un schma relationnel . . . . . . . . . . . . . . . . . . . . . . 37

    4.2.1 Rgles gnrales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.2.2 Retour sur le choix des identifiants . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2.3 Dnormalisation du modle logique . . . . . . . . . . . . . . . . . . . . . . . . . 43

    4.3 Le langage de dfinition de donnes SQL2 . . . . . . . . . . . . . . . . . . . . . . . . . . 454.3.1 Types SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.3.2 Cration des tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3.3 Contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.3.4 Modification du schma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

    4.4 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

  • 8/22/2019 Cnam Cours Base De Donnes

    4/209

    4 TABLE DES MATIRES

    5 Lalgbre relationnelle 555.1 Les oprateurs de lalgbre relationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

    5.1.1 La slection, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

    5.1.2 La projection,

    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.1.3 Le produit cartsien, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.1.4 Lunion, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.1.5 La diffrence, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.1.6 Jointure, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

    5.2 Expression de requtes avec lalgbre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.2.1 Slection gnralise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.2.2 Requtes conjonctives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.2.3 Requtes avec et . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

    5.3 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

    6 Le langage SQL 676.1 Requtes simples SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

    6.1.1 Slections simples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.1.2 La clause WHERE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706.1.3 Valeurs nulles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

    6.2 Requtes sur plusieurs tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.2.1 Jointures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.2.2 Union, intersection et diffrence . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

    6.3 Requtes imbriques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746.3.1 Conditions portant sur des relations . . . . . . . . . . . . . . . . . . . . . . . . . 746.3.2 Sous-requtes correlles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

    6.4 Agrgration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.4.1 Fonctions dagrgation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.4.2 La clause GROUP BY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

    6.4.3 La clause HAVING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786.5 Mises--jour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786.5.1 Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786.5.2 Destruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786.5.3 Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

    6.6 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

    7 Schmas relationnels 817.1 Schmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

    7.1.1 Dfinition dun schma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827.1.2 Utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

    7.2 Contraintes et assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837.3 Vues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

    7.3.1 Cration et interrogation dune vue . . . . . . . . . . . . . . . . . . . . . . . . . 857.3.2 Mise jour dune vue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

    7.4 Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877.4.1 Principes des triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877.4.2 Syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

    7.5 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

    8 Programmation avec SQL 918.1 Interfaage avec le langage C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

    8.1.1 Un exemple complet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918.1.2 Dveloppement en C/SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 948.1.3 Autres commandes SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

    8.2 Linterface Java/JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

  • 8/22/2019 Cnam Cours Base De Donnes

    5/209

    TABLE DES MATIRES 5

    8.2.1 Principes de JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978.2.2 Le plus simple des programmes JDBC . . . . . . . . . . . . . . . . . . . . . . . . 998.2.3 Exemple dune applet avec JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . 100

    II Aspects systmes 105

    9 Techniques de stockage 1079.1 Stockage de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

    9.1.1 Supports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1089.1.2 Fonctionnement dun disque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1099.1.3 Optimisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119.1.4 Technologie RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

    9.2 Fichiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1179.2.1 Enregistrements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1179.2.2 Blocs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

    9.2.3 Organisation dun fichier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1229.3 Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

    9.3.1 Fichiers et blocs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1269.3.2 Les tablespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1299.3.3 Cration des tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

    10 Indexation 13310.1 Indexation de fichiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

    10.1.1 Index non-dense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13510.1.2 Index dense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13710.1.3 Index multi-niveaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

    10.2 Larbre-B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

    10.2.1 Prsentation intuitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14010.2.2 Recherches avec un arbre-B+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14110.3 Hachage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

    10.3.1 Principes de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14310.3.2 Hachage extensible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

    10.4 Les index bitmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14810.5 Indexation dans Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

    10.5.1 Arbres B+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15010.5.2 Arbres B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15110.5.3 Indexation de documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15110.5.4 Tables de hachage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15210.5.5 Index bitmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

    11 valuation de requtes 15511.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15511.2 Evaluation dune requte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

    11.2.1 Evaluation de requtes efficace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15711.2.2 Mesure du cot dune opration . . . . . . . . . . . . . . . . . . . . . . . . . . . 15711.2.3 Techniques daccs et prtraitement . . . . . . . . . . . . . . . . . . . . . . . . . 15811.2.4 Le Tri externe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15911.2.5 La Slection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16111.2.6 Projection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16511.2.7 Jointure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

    11.3 Compilation dune requte et optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . 17311.3.1 Traduction de la requte en un plan dexcution logique . . . . . . . . . . . . . . 173

    11.3.2 Lois algbriques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

  • 8/22/2019 Cnam Cours Base De Donnes

    6/209

    6 TABLE DES MATIRES

    11.3.3 Amlioration dun plan dexcution logique . . . . . . . . . . . . . . . . . . . . . 17511.3.4 Estimation des cots et choix dun plan dexcution physique . . . . . . . . . . . 17811.3.5 Exemple destimation du cot dune opration . . . . . . . . . . . . . . . . . . . 182

    11.3.6 Choix dun oprateur pour la slection . . . . . . . . . . . . . . . . . . . . . . . . 18211.3.7 Stratgies pour le choix dun oprateur pour la jointure . . . . . . . . . . . . . . . 18311.3.8 Pipelinage ou matrialisation des rsultats intermdiaires . . . . . . . . . . . . . . 183

    12 Introduction la concurrence daccs 18712.1 Prliminaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

    12.1.1 Excutions concurrentes: srialisabilit . . . . . . . . . . . . . . . . . . . . . . . 18812.1.2 Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18912.1.3 Excutions concurrentes: recouvrabilit . . . . . . . . . . . . . . . . . . . . . . . 190

    12.2 Contrle de concurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19212.2.1 Verrouillage deux phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19212.2.2 Contrle par estampillage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

    12.3 Gestion des transactions en SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

    12.4 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

    13 Travaux pratiques 19913.1 Environnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

    13.1.1 Connexion au systme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19913.1.2 Les commandes utiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20013.1.3 Utilisation de SQLPLUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

    13.2 Requtes SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20313.2.1 Slections simples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20313.2.2 Jointures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20313.2.3 Ngation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20413.2.4 Fonctions de groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

    13.3 Concurrence daccs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20413.4 Normalisation dun schma relationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20613.5

    Optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

  • 8/22/2019 Cnam Cours Base De Donnes

    7/209

    7

    Chapitre 1

    Introduction

    Sommaire

    Ce cours sadresse aux tudiants du cycle A du CNAM et a pour objectif ltude des principes desSGBD relationnels et la mise en pratique de ces principes. Le contenu du cours est essentiellement lesuivant :

    1. Conception dun schma relationnel. Il sagit de savoir dfinir un schma relationnel complet etcorrect, comprenant des tables, des contraintes, des vues.

    2. Langages dinterrogation et de manipulation. Laccent est mis sur SQL et ses fondements, et surlintgration de SQL avec un langage de programmation comme le C.

    De plus, le cours comprend une introduction aux problmes de concurrence daccs, dont la connais-

    sance est ncessaire aux dveloppeurs dapplications bases sur des SGBD. Des travaux pratiques avec leSGBD ORACLE permettent de mettre en oeuvre les techniques tudies en cours.

    Laccent est donc plutt mis sur les notions de base (quest-ce quun SGBD, quune base de donnes,quun langage dinterrogation) et leur application pratique. Il demand davoir acquis la fin du cours lesconnaissances ncessaires lutilisation dun SGBD par un informaticien non-spcialiste. : cration dunschma, insertion, mise--jour, destruction, interrogation de donnes, et comprehension des mcanismes deconcurrence intervenant dans la gestion dun SGBD. En revanche, tout ce qui relve de la comprhensiondes mcanismes internes dun SGBD (reprsentation physique, valuation de requtes) ou des fondementsthoriques du modle relationnel nest pas abord ici.

    Ce document est un support de cours : il ne prtend certainement pas tre exhaustif ni traiter en dtailtous les sujets abords. Lassistance au cours proprement dit, ainsi quaux travaux dirigs et aux travauxpratiques est fortement recommande. Il existe de plus un site WEB qui donne des renseignements com-plmentaires, les horaires des cours, les solutions de certains exercices, etc. Voici ladresse :

    http://sikkim.cnam.fr/~rigaux/bdpi.html

    Pour ceux qui veulent en savoir plus, il existe une riche bibliographie dont voici quelques lmentsrecommandables :

    Ouvrages en franais

    1. Carrez C., Des Structures aux Bases de Donnes, Masson

    2. Gardarin G., Matriser les Bases de Donnes: modles et langages, Eyrolles

    3. Marcenac, P., SGBD relationnels, Optimisation des performances, Eyrolles.

  • 8/22/2019 Cnam Cours Base De Donnes

    8/209

    8 CHAPITRE 1. INTRODUCTION

    Ouvrages en anglais

    1. Melton J. et A.R. Simon, Understanding SQL, A Complete Guide, Morgan Kaufmann, 1993.

    2. Ullman J.D. et Widom J., A first Course in database Systemsd, Prentice Hall, 1999

    3. Date C.J., An Introduction to Database Systems, Addison-Wesley

    Le premier chapitre (correspondant au premier cours) est une (rapide) prsentation de tous les thmesprsents en dtails dans ce cours. On peut le lire comme une mise en perspective gnrale de lensemblede lenseignement.

  • 8/22/2019 Cnam Cours Base De Donnes

    9/209

    9

    Chapitre 2

    Prsentation gnrale

    Sommaire

    2.1 Donnes, Bases de donnes et SGBD . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Que doit-on savoir pour utiliser un SGBD? . . . . . . . . . . . . . . . . . . . . . . 11

    2.2.1 Dfinition du schma de donnes . . . . . . . . . . . . . . . . . . . . . . . . . 11

    2.2.2 Les oprations sur les donnes . . . . . . . . . . . . . . . . . . . . . . . . . . 12

    2.2.3 Optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

    2.2.4 Concurrence daccs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

    2.3 Le plan du cours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

    Ce chapitre prsente un panorama gnral de la problmatique des bases de donnes.

    2.1 Donnes, Bases de donnes et SGBDLa premire chose faire est dtablir quelques points de terminologie. Quest-ce quune donne ? Cest

    une information quelconque comme, par exemple : voici une personne, elle sappelle Jean. Cest aussi unerelation entre des informations : Jean enseigne les bases de donnes. Des relations de ce genre dfinissentdes structures. Une base de donnes est un ensemble, en gnral volumineux, de telles informations, avecune caractristique essentielle : on souhaite les mmoriser de manire permanente. Do la dfinition :

    Definition 2.1 Une Base de donnes est un gros ensemble dinformations structures mmorises sur unsupportpermanent.

    On peut remarquer quune organisation consistant en un (ou plusieurs) fichier(s) stocks sur mmoiresecondaire est conforme cette dfinition. Un ensemble de fichiers ne prsentant quune complexit assez

    faible, il ny aurait pas l matire longue dissertation. Malheureusement lutilisation directe de fichierssoulve de trs gros problmes :

    1. Lourdeur daccs aux donnes. En pratique, pour chaque accs, mme le plus simples, il faudraitcrire un programme.

    2. Manque de scurit. Si tout programmeur peut accder directement aux fichiers, il est impossible degarantir la scurit et lintgrit des donnes.

    3. Pas de contrle de concurrence. Dans un environnement o plusieurs utilisateurs accdent aux mmefichiers, des problmes de concurrence daccs se posent.

    Do le recours un logiciel charg de grer les fichiers constituant une base de donnes, de prendreen charge les fonctionnalits de protection et de scurit et de fournir les diffrents types dinterface n-

    cessaires laccs aux donnes. Ce logiciel (le SGBD) est trs complexe et fournit le sujet principal de

  • 8/22/2019 Cnam Cours Base De Donnes

    10/209

    10 CHAPITRE 2. PRSENTATION GNRALE

    ce cours. En particulier, une des tches principales du SGBD est de masquer lutilisateur les dtailscomplexes et fastidieux lis la gestion de fichiers. Do la dfinition.

    Definition 2.2 Un Systme de Gestion de Bases de Donnes (SGBD) est un logiciel dehaut niveau

    quipermet de manipuler les informations stockes dans une base de donnes.

    La complexit dun SGBD est essentiellement issue de la diversit des techniques mises en oeuvre, dela multiplicit des composants intervenant dans son architecture, et des diffrents types dutilisateurs (ad-ministrateurs, programmeurs, non informaticiens, ...) qui sont confronts, diffrents niveaux, au systme.Voici quelques exemples illustrant tous les cas de figure quil faudrait envisager dans un cours exhaustif :

    Les modles de donnes : entit-relation, rseau, hirarchique, relationnel, orient-objet, modlessmantiques.

    Les langages de requtes : fondements thoriques (logiques du premier ordre, du point fixe, algbresdiverses) et les langages comme SQL, SQL3, Datalog, OQL, etc.

    Les techniques de stockage : sur disque (optique), sur bande.

    Lorganisation des fichiers : index, arbre-B, hachage, ...

    Larchitecture : centralis, distribu, sur dautres bases accessibles par rseau.

    Les techniques dvaluation et doptimisation de requtes.

    La concurrence daccs et les techniques de reprise sur pane.

    Pour mettre un peu dordre dans tout cela, on peut se raccrocher une architecture standard conforme la plus grande partie des SGBD existant, et offrant lavantage de bien illustrer les principales caractris-tiques dun SGBD.

    Cette architecture distingue trois niveaux correspondant dune part trois reprsentations quivalentes

    de linformation, dautre part aux champs dinterventions respectifs des principaux acteurs. Pour ces der-niers, nous utiliserons la terminologie suivante :

    Utilisateur naf : du non spcialiste des SGBD au non informaticien.

    Concepteur et programmeur dapplication : partir des besoins des diffrents utilisateurs, crit lap-plication pour des utilisateurs nafs.

    Utilisateur expert : informaticien connaissant le fonctionnement interne dun SGBD et charg dad-ministrer la base.

    Chaque niveau du SGBD remplit (ralise) un certain nombre de fonctions :

    Niveau physiques : gestion sur mmoire secondaire (fichiers) des donnes, du schma, des index;

    Partage de donnes et gestion de la concurrence daccs ; Reprise sur pannes (fiabilit) ; Distributiondes donnes et interoprabilit (accs aux rseaux).

    Niveau logique : Dfinition de la structure de donnes : Langage de Description de Donnes (LDD) ;Consultation et Mise Jour des donnes : Langages de Requtes (LR) et Langage de Manipulationde Donnes (LMD); Gestion de la confidentialit (scurit) ; Maintien de lintgrit ;

    Niveau externe : Vues; Environnement de programmation (intgration avec un langage de program-mation) ; Interfaces conviviales et Langages de 4e Gnration (L4G); Outils daides (e.g. conceptionde schmas) ; Outils de saisie, dimpression dtats.

    En rsum, un SGBD est destin grer un gros volume dinformations, persistantes (annes) et fiables(protection sur pannes), partageables entre plusieurs utilisateurs et/ou programmes et manipules indpen-

    damment de leur reprsentation physique.

  • 8/22/2019 Cnam Cours Base De Donnes

    11/209

    2.2. QUE DOIT-ON SAVOIR POUR UTILISER UN SGBD ? 11

    2.2 Que doit-on savoir pour utiliser un SGBD?

    Lutilisation dun SGBD suppose de comprendre (et donc de savoir utiliser) les fonctionnalits sui-

    vantes:

    1. Dfinition du schma de donnes en utilisant les modles de donnes du SGBD.

    2. Oprations sur les donnes : recherche, mises--jour, etc.

    3. Partager les donnes entre plusieurs utilisateurs. (Mcanisme de transaction).

    4. Optimiser les performances, par le rglage de lorganisation physique des donnes. Cet aspect relveplutt de ladministration et ne sera voqu que dans lintroduction.

    Reprenons dans lordre ces diffrents points.

    2.2.1 Dfinition du schma de donnes

    Un schma est simplement la description des donnes contenues dans la base. Cette description estconforme un modle de donnes qui propose des outils de description (structures, contraintes et op-rations). En fait, dans un SGBD, il existe plusieurs modles plus ou moins abstraits des mmes objets,e.g.:

    Le modle conceptuel : la description du systme dinformation

    Le modle logique : interface avec le SGBD

    Le modle physique : fichiers.

    Ces diffrents modles correspondent aux niveaux dans larchitecture dun SGBD. Prenons lexemple dumodle conceptuel le plus courant : le modle Entit/Association. Cest essentiellement une descriptiontrs abstraite qui prsente les avantages suivants :

    lanalyse du monde rel

    la conception du systme dinformation

    la communication entre diffrents acteurs de lentreprise

    En revanche, il ne propose pas doprations. Or dfinir des structures sans disposer doprations pour agirsur les donnes stockes dans ces structures ne prsente pas dintrt pratique pour un SGBD. Do, unniveau infrieur, des modles dits logiques qui proposent :

    1. Un langage de dfinition de donnes (LDD) pour dcrire la structure, incluant des contraintes.

    2. Un langage de manipulation de donnes (LMD) pour appliquer des oprations aux donnes.

    Ces langages sont abstraits : le LDD est indpendant de la reprsentation physique des donnes, et leLMD est indpendant de limplantation des oprations. On peut citer une troisime caractristique : outeles structures et les oprations, un modle logique doit permettre dexprimer des contraintes dintgritsurles donnes. Exemple:

    nom character 15, not null;

    ge integer between 0 and 120;

    dbit = crdit;

    ...

  • 8/22/2019 Cnam Cours Base De Donnes

    12/209

    12 CHAPITRE 2. PRSENTATION GNRALE

    Bien entendu, le SGBD doit tre capable de garantir le respect de ces contraintes.Quand on conoit une application pour une BD, on tient compte (plus ou moins consciemment) de

    cette architecture en plusieurs niveaux. Typiquement : (1) On dcide la structure logique, (2) on dcide

    la structure physique, (3) on crit les programmes dapplication en utilisant la structure logique, enfin (4)Le SGBD se charge de transcrire les commandes du LMD en instructions appropries appliques lareprsentation physique.

    Cette aproche offre de trs grands avantages quil est important de souligner. Tout dabord elle ouvrelutilisation des SGBD de utilisateurs non-experts: les langages proposs par les modles logiques sontplus simples, et donc plus accessibles, que les outils de gestion de fichiers. Ensuite, on obtient une carac-tristique essentielle : lindpendance physique. On peut modifier limplantation physique sans modifierles programmes dapplication. Un concept voisin est celui dindpendance logique : on peut modifier lesprogrammes dapplication sans toucher limplantation.

    Enfin le SGBD dcharge lutilisateur, et en grande partie ladministrateur, de la lourde tche de contr-ler la scurit et lintgrit des donnes.

    2.2.2 Les oprations sur les donnesIl existe 4 oprations classiques (ou requtes) :

    1. La cration (ou insertion).

    2. La modification (ou mise--jour).

    3. La destruction.

    4. La recherche.

    Ces oprations correspondent des commandes du LMD. La plus complexe est la recherche en raisonde la varit des critres.

    Pour lutilisateur, une bonne requte a les caractristiques suivantes. Tout dabord elle sexprime facile-ment : lidal serait de pouvoir utiliser le langage naturel, mais celui-ci prsente trop dambiguits. Ensuitele langage ne devrait pas demander dexpertise technique (syntaxe complique, structures de donnes, im-plantation particulire ...). Il est galement souhaitable de ne pas attendre trop longtemps ( charge pour leSGBD de fournir des performances acceptables). Enfin , et peut-tre surtout, la rponse doit tre fiable.

    Une bonne partie du travail sur les SGBD consiste satisfaire ces besoins. Le rsultat est ce que lon ap-pelle un langage de requtes, et constitue la fois un sujet majeur dtude et une caractristique essentiellede chaque SGBD. Le langage le plus rpandu lheure actuelle est SQL.

    2.2.3 Optimisation

    Loptimisation (dune requte) sappuie sur lorganisation physique des donnes. Les principaux typesdorganisation sont les fichiers squentiels, les index (denses. secondaires, arbres B) et le regroupement desdonnes par hachage.

    Un module particulier du SGBD, loptimiseur, tient compte de cette organisation et des caractristiquesde la requte pour choisir le meilleur squencement des oprations.

    2.2.4 Concurrence daccs

    Plusieurs utilisateurs doivent pouvoir accder en mme temps aux mmes donnes. Le SGBD doitsavoir:

    Grer les conflits si les deux font des mises--jour.

    Offrir un mcanisme de retour en arrire si on dcide dannuler des modifications en cours.

    Donner une image cohrente des donnes si lun fait des requtes et lautre des mises--jour.

    Le but : viter les blocages, tout en empchant des modifications anarchiques.

  • 8/22/2019 Cnam Cours Base De Donnes

    13/209

    2.3. LE PLAN DU COURS 13

    2.3 Le plan du cours

    Le cours comprend trois parties consacres successivement la conception dune base de donnesrelationnelles, aux langages de requtes relationnels, enfin la pratique dun SGBD relationnel.

    Conception dun schma relationnel

    Le cours prsente dabord la technique classique de conception laide du modle entit/association,suivie de la transcription du schma obtenu dans le modle relationnel. On obtient un moyen simple etcourant de crer des schmas ayant de bonnes proprits. Les concepts de bon et de mauvais schmassont ensuite revus plus formellement avec la thorie de la normalisation.

    Langages relationnels

    Les langages dinterrogation et de manipulation de donnes suivants sont prsents : lalgbre rela-tionnelle qui fournit un petit ensemble doprateurs permettant dexprimer des requtes complexes et lelangage SQL, norme SQL2.

    Pratique dun SGBD relationnel

    Cette partie reprend et tend les sujets prcdents et dveloppe leur mise en pratique dans lenvironne-ment dun SGBD relationnel. Elle comprend :

    1. Une revue complte du langage de dfinition de donnes SQL2 pour la cration de schmas relation-nels, incluant lexpression de contraintes, les vues et les triggers.

    2. Une introduction au dveloppement dapplications avec SQL.

    3. Une introduction la concurrence daccs et ses implications pratiques.

    4. Une srie de travaux pratiques et dexercices avec le SGBD Oracle.

  • 8/22/2019 Cnam Cours Base De Donnes

    14/209

    14 CHAPITRE 2. PRSENTATION GNRALE

  • 8/22/2019 Cnam Cours Base De Donnes

    15/209

    15

    Premire partie

    Modles et langages

  • 8/22/2019 Cnam Cours Base De Donnes

    16/209

  • 8/22/2019 Cnam Cours Base De Donnes

    17/209

    17

    Chapitre 3

    Le modle Entit/Association

    Sommaire

    3.1 Principes gnraux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

    3.1.1 Bons et mauvais schmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

    3.1.2 La bonne mthode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

    3.2 Le modle E/A : Prsentation informelle . . . . . . . . . . . . . . . . . . . . . . . . 20

    3.3 Le modle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

    3.3.1 Entits, attributs et identifiants . . . . . . . . . . . . . . . . . . . . . . . . . . 21

    3.3.2 Associations binaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

    3.3.3 Entits faibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

    3.3.4 Associations gnralises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

    3.4 Avantage et inconvnients du modle E/A . . . . . . . . . . . . . . . . . . . . . . . 30

    3.5 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

    Ce chapitre prsente le modle Entit/Association (E/A) qui est utilis peu prs universellement pourla conception de bases de donnes (relationnelles principalement). La conception dun schma correct estessentielle pour le dveloppement dune application viable. Dans la mesure o la base de donnes estle fondement de tout le systme, une erreur pendant sa conception est difficilement rcuprable par lasuite. Le modle E/A a pour caractristiques dtre simple et suffisamment puissant pour reprsenter desstructures relationnelles. Surtout, il repose sur une reprsentation graphique qui facilite considrablementsa comprhension.

    Le modle E/A souffre galement de nombreuses insuffisances: la principale est de ne proposer quedes structures. Il nexiste pas dopration permettant de manipuler les donnes, et pas (ou peu) de moyendexprimer des contraintes. Un autre inconvnient du modle E/A est de mener certaines ambiguits pourdes schmas complexes.

    La prsentation qui suit est dlibrement axe sur lutilit du modle E/A dans le cadre de la conceptiondune base de donnes. Ajoutons quil ne sagit pas de concevoirun schma E/A (voir un cours sur lessystmes dinformation), mais dtre capable de le comprendre et de linterprter. Dans tout ce chapitrenous prenons lexemple dune base de donnes dcrivant des films, avec leur metteur en scne et leursacteurs, ainsi que les cinmas o passent ces films. Nous supposerons galement que cette base de donnesest accessible sur le Web et que des internautes peuvent noter les films quils ont vus.

    3.1 Principes gnraux

    La mthode permet de distinguer les entits qui constituent la base de donnes, et les associationsentre ces entits. Ces concepts permettent de donner une structure la base, ce qui savre indispensable.Nous commenons par montrer les problmes qui surviennent si on traite une base relationnelle comme un

    simple fichier texte, sans se soucier de lui donner une structure correcte.

  • 8/22/2019 Cnam Cours Base De Donnes

    18/209

    18 CHAPITRE 3. LE MODLE ENTIT/ASSOCIATION

    3.1.1 Bons et mauvais schmas

    Considrons une table FilmSimple stockant des films avec quelques informations de base, dont le met-teur en scne. Voici une reprsentation de cette table.

    titre anne nomMES prnomMES anneNaissAlien 1979 Scott Ridley 1943Vertigo 1958 Hitchcock Alfred 1899Psychose 1960 Hitchcock Alfred 1899Kagemusha 1980 Kurosawa Akira 1910Volte-face 1997 Woo John 1946Pulp Fiction 1995 Tarantino Quentin 1963Titanic 1997 Cameron James 1954Sacrifice 1986 Tarkovski Andrei 1932

    Mme pour une information aussi simple, il est facile dnumrer tout un ensemble de problmespotentiels. Tous ou presque dcoulent dun grave dfaut de la table ci-dessus : il est possible de reprsenterla mme information plusieurs fois.

    Anomalies lors dune insertion

    Rien nempche de reprsenter plusieurs fois le mme film. Pire : il est possible dinsrer plusieurs foisle film Vertigo en le dcrivant chaque fois de manire diffrente, par exemple en lui attribuant une foiscomme ralisateur Alfred Hitchcock, puis une autre fois John Woo, etc.

    Une bonne question consiste dailleurs se demander ce qui distingue deux films lun de lautre, et quel moment on peut dire que la mme information a t rpte. Peut-il y avoir deux films diffrents avecle mme titre par exemple ? Si la rponse est non, alors on devrait pouvoir assurer quil ny a pas deuxlignes dans la table avec la mme valeur pour lattribut titre. Si la rponse est oui, il reste dterminerquel est lensemble des attributs qui permet de caractriser de manire unique un film.

    Anomalies lors dune modification

    La redondance dinformation entrane galement des anomalies de mise jour. Supposons que lonmodifie lanne de naissance de Hitchcock pour la ligne Vertigo et pas pour la ligne Psychose. On seretrouve alors avec des informations incohrentes.

    Les mmes questions que prcdemment se posent dailleurs. Jusqu quel point peut-on dire quil nya quun seul ralisateur nomm Hitchcock, et quil ne doit donc y avoir quune seule anne de naissancepour un ralisateur de ce nom ?

    Anomalies lors dune destruction

    On ne peut pas supprimer un film sans supprimer du mme coup son metteur en scne. Si on souhaite,

    par exemple, ne plus voir le film Titanic figurer dans la base de donnes, on va effacer du mme coup lesinformations sur James Cameron.

    3.1.2 La bonne mthode

    Une bonne mthode vitant les anomalies ci-dessus consiste ;

    1. tre capable de reprsenter individuellement les films et les ralisateurs, de manire ce quuneaction sur lun nentrane pas systmatiquement une action sur lautre ;

    2. dfinir une mthode didentification dun film ou dun ralisateur, qui permette dassurer que lamme information est reprsente une seule fois ;

    3. prserver le lien entre les films et les ralisateurs, mais sans introduire de redondance.

  • 8/22/2019 Cnam Cours Base De Donnes

    19/209

  • 8/22/2019 Cnam Cours Base De Donnes

    20/209

    20 CHAPITRE 3. LE MODLE ENTIT/ASSOCIATION

    3.2 Le modle E/A : Prsentation informelle

    Un schma E/A dcrit lapplication vise, cest--dire une abstraction dun domaine dtude, pertinente

    relativement aux objectifs viss. Rappelons quune abstraction consiste choisir certains aspects de laralit perue (et donc liminer les autres). Cette slection se fait en fonction de certains besoins quidoivent tre prcisment dfinis.

    Par exemple, pour notre base de donnes Films, on na pas besoin de stocker dans la base de donneslintgralit des informations relatives un internaute, ou un film. Seules comptent celles qui sont im-portantes pour lapplication. Voici le schma dcrivant cete base de donnes Films (figure 3.1). Sans entrerdans les dtails pour linstant, on distingue

    1. des entits, reprsentes par des rectangles, ici Film, Artiste, Internaute et Pays ;

    2. des associations entre entits reprsentes par des liens entre ces rectangles. Ici on a reprsent parexemple le fait quun artiste joue dans des films, quun internaute note des films, etc.

    Chaque entit est caractrise par un ensemble dattributs, parmi lesquels un ou plusieurs forment

    lidentifiant unique (en gras). Comme nous lavons expos prcdemment, il est essentiel de dire ce quicaractrise de manire unique une entit, de manire viter la redondance dinformation.

    Pays

    nom

    langue

    code

    Artiste

    nom

    email

    Internaute

    Film

    note

    Donne une noteid Ralise

    motDePpasse

    anneNaissance

    anneNaissance

    Joue

    rsum

    genreanne

    id0..*

    0..*

    0..*0..1

    *

    *

    1..1*

    titre

    prnomprnom

    nom

    rle

    FIG . 3.1 Le schma de la base de donnes Films

    Les associations sont caractrises par des cardinalits. La notation

    0..*

    sur le lien Ralise, duct de lentit Film, signifie quun artiste peut raliser plusieurs films, ou aucun. La notation 0..1 duct Artiste signifie en revanche quun film ne peut tre ralis que par au plus un artiste. En revanchedans lassociation Donne une note, un internaute peut noter plusieurs films, et un film peut tre not parplusieurs internautes, ce qui justifie la prsence de 0..* aux deux extrmits de lassociation.

    Le choix des cardinalits est essentiel. Ce choix est aussi parfois discutable, et constitue donc laspect leplus dlicat de la modlisation. Reprenons lexemple de lassociation Ralise. En indiquant quun film estralis par un seul metteur en scne, on sinterdit les rares situations o un film est ralis par plusieurspersonnes. Il ne sera donc pas possible de reprsenter dans la base de donnes une telle situation. Tout estici question de choix et de compromis : est-on prt en loccurrence accepter une structure plus complexe(avec

    0..*

    de chaque ct) pour lassociation Ralise, pour prendre en compte un nombre minime de

    cas?Les cardinalits sont notes par deux chiffres. Le chiffre de droite est la cardinalit maximale, qui vaut

    en gnral 1 ou *. Le chiffre de gauche est la cardinalit minimale. Par exemple la notation

    0..1

    entre

  • 8/22/2019 Cnam Cours Base De Donnes

    21/209

    3.3. LE MODLE 21

    Artiste et Film indique quon sautorise ne pas connatre le metteur en scne dun film. Attention: celane signifie pas que ce metteur en scne nexiste pas. Une base de donnes, telle quelle est dcrite par unschma E/A, nest quune vision partielle de la ralit. On ne doit surtout pas rechercher une reprsentation

    exhaustive, mais sassurer de la prise en compte des besoins de lapplication.La notation

    1..1

    entre Film et Pays indique au contraire que lon doit toujours connatre le paysproducteur dun film. On devra donc interdire le stockage dans la base dun film sans son pays.

    Les cardinalits minimales (galement appeles contraintes de participation ) sont moins importantesque les cardinalits maximales, car elles ont un impact moindre sur la structure de la base de donnes etpeuvent plus facilement tre remises en cause aprs coup. Il faut bien tre conscient de plus quelles nereprsentent quun choix de conception, souvent discutable. Dans la notation UML que nous prsentonsici, il existe des notations abrges qui donnent des valeurs implicites aux cardinalits minimales :

    1. La notation * est quivalente 0..* ;

    2. la notation 1 est quivalente 1..1 .

    Outre les proprits dj voques (simplicit, clart de lecture), videntes sur ce schma, on peutnoter aussi que la modlisation conceptuelle est totalement indpendante de tout choix dimplantation. Leschma de la figure 3.1 ne spcifie aucun systme en particulier. Il nest pas non plus question de type oude structure de donnes, dalgorithme, de langage, etc. En principe, il sagit donc de la partie la plus stabledune application. Le fait de se dbarrasser ce stade de la plupart des considrations techniques permetde se concentrer sur lessentiel : que veut-on stocker dans la base ?

    Une des principales difficults dans le maniement des schmas E/A est que la qualit du rsultat ne peutsvaluer que par rapport une demande qui est souvent floue et incomplte. Il est donc souvent difficilede valider (en fonction de quels critres ?) le rsultat. Peut-on affirmer par exemple que :

    1. toutes les informations ncessaires sont reprsentes ;

    2. quun film ne sera jamais ralis par plus dun artiste ;

    3. quil ny aura jamais deux films avec le mme titre.

    Il faut faire des choix, en connaissance de cause, en sachant toutefois quil est toujours possible defaire voluer une base de donnes, quand cette volution nimplique pas de restructuration trop importante.Pour reprendre les exemples ci-dessus, il est facile dajouter des informations pour dcrire un film ou uninternaute ; il serait beaucoup plus difficile de modifier la base pour quun film passe de un, et un seul,ralisateur, plusieurs. Quant changer la cl de Film, cest une des volutions les plus complexes raliser. Les cardinalits et le choix des cls font vraiment partie des des aspects dcisifs des choix deconception.

    3.3 Le modle

    Le modle E/A, conu en 1976, est la base de la plupart des mthodes de conception. La syntaxeemploye ici est celle de la mthode UML, reprise peu prs lidentique de celle de la mthode OMT.Il existe beaucoup dautres notations, dont celle de la mthode MERISE principalement utilise en France.Ces notations sont globalement quivalentes. Dans tous les cas la conception repose sur deux conceptscomplmentaires, entitet association.

    3.3.1 Entits, attributs et identifiants

    Il est difficile de donner une dfinition trs prcise des entits. Les points essentiels sont rsums ci-dessous.

    Definition 3.1 (Entit) On dsigne parentit tout objetidentifiable etpertinent pour lapplication.

  • 8/22/2019 Cnam Cours Base De Donnes

    22/209

    22 CHAPITRE 3. LE MODLE ENTIT/ASSOCIATION

    Comme nous lavons vu prcdemment, la notion didentitest primordiale. Cest elle qui permet dedistinguer les entits les unes des autres, et donc de dire quune information est redondante ou quelle nelest pas. Il est indispensable de prvoir un moyen technique pour pouvoir effectuer cette distinction entre

    entits au niveau de la base de donnes : on parle didentifiantou de cl.La pertinence est galement essentielle : on ne doit prendre en compte que les informations ncessairespour satisfaire les besoins. Par exemple:

    1. le film Impitoyable ;

    2. lacteur Clint Eastwood;

    sont des entits pour la base Films.La premire tape dune conception consiste identifier les entits utiles. On peut souvent le faire en

    considrant quelques cas particuliers. La deuxime est de regrouper les entits en ensembles : en gnral onne sintresse pas un individu particulier mais des groupes. Par exemple il est clair que les films et lesacteurs sont des ensembles distincts dentits. Quen est-il de lensemble des ralisateurs et de lensembledes acteurs? Doit-on les distinguer ou les assembler ? Il est certainement prfrable de les assembler,

    puisque des acteurs peuvent aussi tre ralisateurs.

    Attributs

    Les entits sont caractrises par des proprits : le titre (du film), le nom (de lacteur), sa date denaissance, ladresse, etc. Ces proprits sont dnotes attributs dans la terminologie du modle E/A. Lechoix des attributs relve de la mme dmarche dabstraction qui a dict la slection des entits : il nestpas question de donner exhaustivement toutes les proprits dune entit. On ne garde que celles utiles pourlapplication.

    Un attribut est dsign par un nom et prend ses valeurs dans un domaine numrable comme les entiers,les chanes de caractres, les dates, etc. On peut considrer un nom datribut comme une fonction dfiniesur un ensemble dentits et prenant ses valeurs dans un domaine . On note alors la valeur delattribut pour une entit " .

    Considrons par exemple un ensemble de films % & ( 0 &! 2 3 0 4 4 4 & 7 8 et les attributs titre et anne. Si & ( estle film Impitoyable, tourn par Clint Eastwood en 1992, on aura:

    titre ( &() = Impitoyable; anne ( &

    () = 1992

    Il est trs important de noter que selon cette dfinition un attribut prend une valeur et une seule. On ditque les attributs sont atomiques. Il sagit dune restriction importante puisquon ne sait pas, par exemple,dfinir un attribut tlphones dune entit Personne, prenant pour valeur les numros de tlphone dunepersonne. Certaines mthodes admettent (plus ou moins clairement) lintroduction de constructions pluscomplexes:

    1. les attributs multivalus sont constitus dun ensemble de valeurs prises dans un mme domaine;une telle construction permet de rsoudre le problme des numros de tlphones multiples ;

    2. les attributs composs sont constitus par agrgation dautres atributs ; un attribut adresse peutpar exemple tre dcrit comme lagrgation dun code postal, dun numro de rue, dun nom de rueet dun nom de ville.

    Nous nous en tiendrons pour linstant aux attributs atomiques qui, au moins dans le contexte dunemodlisation oriente vers un SGBD relationnel, sont suffisants.

    Types dentits

    Il est maintenant possible de dcrire un peu plus prcisment les entits par leur type.

    Definition 3.2 (Type dentit) Le type dune entit est compos des lments suivants :

    1. son nom;

  • 8/22/2019 Cnam Cours Base De Donnes

    23/209

    3.3. LE MODLE 23

    2. la liste de ses attributs avec, optionnellement le domaine o lattribut prend ses valeurs : lesentiers, les chanes de caractres;

    3. lindication du (ou des) attribut(s) permettant didentifier lentit : ils constituent la cl.

    On dit quun entit est une instance de son type . Enfin, un ensemble dentits % ( 0 ' 2 3 0 4 4 4 7 8

    instance dun mme type est une extension de .Il reste dfinir plus prcisment la notion de cl.

    Definition 3.3 (Cl) Soit un type dentit et lensemble des attributs de . Une cl de est unsous-ensemble minimal de permettant didentifier de manire unique une entit parmi nimporte quelleextension de

    .

    Prenons quelques exemples pour illustrer cette dfinition. Un internaute est caractris par plusieursattributs : son email, son nom, son prnom, la rgion o il habite. Lemail constitue une cl naturelle puis-quon ne trouve pas, en principe, deux internautes ayant la mme adresse lectronique. En revanche liden-tification par le nom seul parat impossible puisquon constitureait facilement un ensemble contenant deux

    internautes avec le mme nom. On pourrait penser utiliser la paire (nom,prnom), mais il faut utiliseravec modration lutilisation didentifiants composs de plusieurs attributs, quoique possible, peut poserdes problmes de performance et complique les manipulations par SQL.

    Il est possible davoir plusieurs cls pour un mme ensemble dentits. Dans ce cas on en choisit unecomme cl primaire, et les autres comme cls secondaires. Le choix de la cl (primaire) est dterminantpour la qualit du schma de la base de donnes. Les caractristiques dune bonne cl primaire sont lessuivantes :

    sa valeur est connue pour toute entit ;

    on ne doit jamais avoir besoin de la modifier ;

    enfin, pour des raisons de performance, sa taille de stockage doit tre la plus petite possible.

    Il nest pas toujours vident de trouver un ensemble dattributs satisfaisant ces proprits. Considronslexemple des films. Le choix du titre pour identifier un film serait incorrect puisquon aura affaire un jourou lautre deux films ayant le mme titre. Mme en combinant le titre avec un autre attribut (par exemplelanne), il est difficile de garantir lunicit.

    Dans la situation, frquente, o on a du mal dterminer quelle est la cl dune entit, on cre unidentifiant

    abstrait

    indpendant de tout autre attribut. On peut ainsi ajouter dans le type dentit Film un

    attribut id, corespondant un numro squentiel qui sera incrment au fur et mesure des insertions. Cechoix est souvent le meilleur, ds lors quun attribut ne simpose pas de manire vidente comme cl. Ilsatisfait notamment toutes les proprits nonces prcdemment (on peut toujours lui attribuer une valeur,il ne sera jamais ncessaire de la modifier, et elle a une reprsentation compacte).

    On reprsente graphiquement un type dentit comme sur la figure 3.2 qui donne lexemple des typesInternaute et Film. Lattribut (ou les attributs sil y en a plusieurs) formant la cl sont en gras.

    Internaute

    emailnomprnomrgion

    Identifiant

    Attributs

    Film

    titre

    genre

    id

    annersum

    Nom du type dentit

    FIG . 3.2 Reprsentation des types dentit

    Il est essentiel de bien distinguer types dentits et entits. La distinction est la mme quentre schma

    et base dans un SGBD, ou entre type et valeurdans un langage de programmation.

  • 8/22/2019 Cnam Cours Base De Donnes

    24/209

    24 CHAPITRE 3. LE MODLE ENTIT/ASSOCIATION

    3.3.2 Associations binaires

    La reprsentation (et le stockage) dentits indpendantes les unes des autres est de peu dutilit. On vamaintenant dcrire les relations (ou associations) entre des ensembles dentits.

    Definition 3.4 Une association binaire entre les ensembles dentits (

    et

    2

    est un ensemble de couples

    ( 0 ' 2 6

    , avec

    ( " (

    et

    2 " 2

    .

    Cest la notion classique de relation en thorie des ensembles. On emploie plutt le terme dassociationpour viter toute confusion avec le modle relationnel. Une bonne manire dinterprter une associationentre des ensembles dentits est de faire un petit graphe o on prend quelques exemples, les plus gnrauxpossibles.

    Les ralisateurs Les liens "Ralise" Les films

    Alfred Hitchcock

    Clint Eastwood

    Psychose

    Vertigo

    Impitoyable

    FIG . 3.3 Association entre deux ensembles.

    Prenons lexemple de lassociation reprsentant le fait quun ralisateur met en scne des films. Sur legraphe de la figure 3.3 on remarque que :

    1. certains ralisateurs mettent en scne plusieurs films ;2. inversement, un film est mis en scne par au plus un ralisateur.

    La recherche des situations les plus gnrales possibles vise sassurer que les deux caractristiquesci-dessus sont vraies dans tout les cas. Bien entendu on peut trouver 1% des cas o un film a plusieursralisateurs, mais la question se pose alors : doit-on modifier la structure de notre base, pour 1% des cas.Ici, on a dcid que non. Encore une fois on ne cherche pas reprsenter la ralit dans toute sa complexit,mais seulement la partie de cette ralit que lon veut stocker dans la base de donnes.

    Ces caractristiques sont essentielles dans la description dune association entre des ensembles denti-ts.

    Definition 3.5 (Cardinalit) Soit une association ( 0 2

    entre deux types dentits. La cardinalit delassociation pour

    I 0 Q " % T 0 V 8

    , est une paire [min, max] telle que :

    1. Le symbole max (cardinalit maximale) dsigne le nombre maximal de fois o une une entit I de

    Ipeut intervenir dans lassociation.

    En gnral, ce nombre est 1 (au plus une fois) ou Y (plusieurs fois, nombre indetermin), not par lesymbole

    *

    .

    2. Le symbole min (cardinalit minimale) dsigne le nombre minimal de fois o une une entit I de Ipeut intervenir dans la relation. En gnral, ce nombre est 1 (au moins une fois) ou 0.

    Les cardinalits maximales sont plus importantes que les cardinalits minimales ou, plus prcisment,elles savrent beaucoup plus difficiles remettre en cause une fois que le schma de la base est constitu.On dcrit donc souvent une association de manire abrge en omettant les cardinalits minimales. La

    notation

    *

    , en UML, est labrviation de

    0..*

    , et

    1

    est labrviation de

    1..1

    . On caractrise

  • 8/22/2019 Cnam Cours Base De Donnes

    25/209

    3.3. LE MODLE 25

    galement une association de manire concise en donnant les cardinalits maximales aux deux extrmits,par exemple

    1:n

    (association de un plusieurs) ou

    n:n

    (association de plusieurs plusieurs).

    Les cardinalits minimales sont parfois dsignes par le terme contraintes de participation . La valeur

    0 indique quune entit peut ne pas participer lassociation, et la valeur 1 quelle doit y participer.Insistons sur le point suivant : les cardinalits nexpriment pas une vrit absolue, mais des choix deconception. Elles ne peuvent tre dclars valides que relativement un besoin. Plus ce besoin sera exprimprcisment, et plus il sera possible dappcier la qualit du modle.

    Il existe plusieurs manires de noter une association entre types dentits. Nous utilisons ici la nota-tion de la mthode UML, qui est trs proche de celle de la mthode OMT. En France, on utilise aussicouramment de moins en moins... la notation de la mthode MERISE que nous ne prsenterons pas ici.

    FilmRalisateur

    id

    anneNaissance

    id

    genre

    titre

    anne

    Ralise

    0..n0..1

    nom

    prnom

    FIG . 3.4 Reprsentation de lassociation.

    Dans la notation UML, on indique les cardinalits aux deux extrmits dun lien dassociation entredeux types dentits ` a et ` c . Les cardinalits pour ` a sont places lextrmit du lien allant de ` avers ` c et les cardinalits pour ` c sont lextrmit du lien allant de ` a vers ` c . Pour lassociation entre

    Ralisateuret Film, cela donne lassociation de la figure 3.4. Cette association se lit Un ralisateur ralisezro, un ou plusieurs films, mais on pourrait tout aussi bien utiliser la forme passive avec comme intitul

    de lasscoiation Est ralis paret une lecture Un film est ralis par au plus un ralisateur. Le seul critre privilgier dans ce choix des termes est la clart de la reprsentation.

    Prenons maintenant lexemple de lassociation (Acteur,Film) reprsentant le fait quun acteur joue dansun film. Un graphe bas sur quelques exemples est donn dans la figure 3.5. On constate tout dabordquun acteur peut jouer dans plusieurs films, et que dans un film on trouve plusieurs acteurs. Mieux : ClintEastwood, qui apparaissait dj en tant que metteur en scne, est maintenant galement acteur, et dans lemme film.

    Les filmsLes acteurs Les liens "Joue"

    Ennemi dtatTom Cruise

    Gene Hackman

    Clint EastwoodJacques Dutronc Van Gogh

    Impitoyable

    FIG . 3.5 Association (Acteur,Film)

    Cette dernire constatation mne la conclusion quil vaut mieux regrouper les acteurs et les rali-sateurs dans un mme ensemble, dsign par le terme plus gnral

    Artiste

    . On obtient le schma de la

    figure 3.6, avec les deux associations reprsentant les deux types de lien possible entre un artiste et un film :il peut jouer dans le film, ou le raliser. Ce

    ou

    nest pas exclusif : Eastwood joue dans Impitoyable, quil

    a aussi ralis.

  • 8/22/2019 Cnam Cours Base De Donnes

    26/209

    26 CHAPITRE 3. LE MODLE ENTIT/ASSOCIATION

    FilmRalise

    Artiste

    id

    genre

    anne

    id

    titre

    anneNaiss Joue rle

    1..1

    0..*

    0..*

    0..*prnomnom

    FIG . 3.6 Associations entre Artiste etFilm.

    Dans le cas dassociations avec des cardinalits multiples de chaque ct, on peut avoir des attributsqui ne peuvent tre affects qu lassociation elle-mme. Par exemple lassociation Joue a pour attribut lerle tenu par lacteur dans le film (figure 3.6).

    Rappelons quun attribut ne peut prendre quune et une seule valeur. Clairement, on ne peut associerrle ni Acteurpuisquil a autant de valeurs possibles quil y a de films dans lesquels cet acteur a jou,ni Film, la rciproque tant vraie galement. Seules les associations ayant des cardinalits multiples dechaque ct peuvent porter des attributs.

    Quelle est la cl dune association ? Si lon sen tient la dfinition, une association est un ensemble decouples, et il ne peut donc y avoir deux fois le mme couple (parce quon ne trouve pas deux fois le mmelment dans un ensemble). On a donc :

    Definition 3.6 (Cl dune association) La cl dune association (binaire) entre un type dentit ( et untype dentit

    2est le couple constitu de la cl d

    (de

    (et de la cl d

    2de

    2.

    En pratique cette contrainte est souvent trop contraignante car on souhaite autoriser deux entits trelies plus dune fois dans une association. Imaginons par exemple quun internaute soit amen noter plusieurs reprises un film, et que lon souhaite conserver lhistorique de ces notations successives. Avec

    une association binaire entre Internaute et Film, cest impossible : on ne peut dfinir quun seul lien entreun film donn et un internaute donn.Le problme est quil nexiste pas de moyen pour distinguer des liens multiples entre deux mmes

    entits. Le seul moyen pour effectuer une telle distinction est dintroduire une entit discriminante, parexemple la date de la notation. On obtient alors une association ternaire dans laquelle on a ajout un typedentit Date (figure 3.7).

    Internaute

    email

    rgion

    Film

    genre

    anne

    id

    titrenote

    Date

    date

    prnom

    nom

    FIG . 3.7 Ajout dune entitDate pour conserver lhistorique des notations

    Un lien de cette association runit donc une entit Film, une entit Internaute et une entit Date. Onpeut identifier un tel lien par un triplet (id, email, date) constitu par les cls des trois entits constituant le

    lien.

  • 8/22/2019 Cnam Cours Base De Donnes

    27/209

    3.3. LE MODLE 27

    Comme le montre la figure 3.8, il devieent alors possible, pou un mme internaute, de noter plusieursfois le mme film, pourvu que ce ne soit pas la mme date. Rciproquement un internaute peut noter desfilms diffrents le mme jour, et un mme film peut tre not plusieurs fois la mme date, condition que

    ce ne soit pas par le mme internaute.

    Phileas Fogg

    Van Gogh

    Ennemi dtat

    12 juillet 2023 6 juin 2000

    Internautes Films

    Dates

    Jules Maigret

    FIG . 3.8 Graphe dune association ternaire

    Mme si cette solution est correcte, elle prsente linconvnient dintroduire une entit assez artificielle,Date, qui porte peu dinformation et vient alourdir le schma. En pratique on sautorise une notation abr-ge en ajoutant un attribut date dans lassociation, et en le soulignant pour indiquer quil fait partie de lacl, en plus du couple des cls des entits (voir figure 3.9).

    Internaute

    email

    rgion

    Film

    genre

    anne

    id

    titrenote

    date

    0..n 0..n

    prnom

    nom

    FIG . 3.9 Notation abrge dune association avec un type dentitDate

    Nous reviendrons plus longuement sur les associations ternaires par la suite.

    3.3.3 Entits faibles

    Jusqu prsent nous avons considr le cas dentits indpendantes les unes des autres. Chaque entit,disposant de son propre identifiant, pouvait tre considre isolment. Il existe des cas o une entit ne peutexister quen troite association avec une autre, et est identifie relativement cette autre entit. On parlealors dentit faible.

    Prenons lexemple dun cinma, et de ses salles. On peut considrer chaque salle comme une entit,dote dattributs comme la capacit, lquipement en son Dolby, ou autre. Il est diffcilement imaginable dereprsenter une salle sans quelle soit rattache son cinma. Cest en effet au niveau du cinma que lonva trouver quelques informations gnrales comme ladresse ou le numro de tlphone.

    Il est possible de reprsenter le lien en un cinma et ses salles par une association classique, commele montre la figure 3.10.a. La cardinalit

    1..1

    force la participation dune salle un lien dassociation

    avec un et un seul cinma. Cette reprsentation est correcte, mais prsente un inconvnient: on doit crer

  • 8/22/2019 Cnam Cours Base De Donnes

    28/209

    28 CHAPITRE 3. LE MODLE ENTIT/ASSOCIATION

    un identifiant artificiel id pour le type dentit Salle, et numroter toutes les salles, indpendamment ducinma auquel elles sont rattaches.

    On peut considrer quil est beaucoup plus naturel de numroter les salles par un numro interne

    chaque cinma. La cl didentification dune salle est alors constitue de deux parties :

    1. la cl de Cinma, qui indique dans quel cinma se trouve la salle ;

    2. le numro de la salle au sein du cinma.

    En dautres termes, lentit salle ne dispose pas dune identification absolue, mais dune identificationrelative une autre entit. Bien entendu cela force la salle a toujours tre associe un et un seul cinma.

    La reprsentation graphique des entits faibles avec UML est illustre dans la figure 3.10.b. La salle estassocie au cinma avec une association qualifie par lattribut no qui sert de discriminant pour distinguerles salles au sein dun mme cinma. Noter que la cardinalit du ct Cinma est implicitement

    1..1

    .

    dateConstr.

    nom

    ruenumro

    no

    nom

    ruenumro

    dateConstr.

    id

    1

    **

    (a (b

    Salle

    capacit

    Cinma

    ville

    Cinma

    ville

    Salle

    capacit

    FIG . 3.10 Modlisation du lien Cinma-Salle (a) sous la forme dune association classique (b) avec uneentit faible

    Lintroduction dentits faibles nest pas une ncessit absolue puisquon peut trs bien utiliser uneassociation classique. La principale diffrence est que, dans le cas dune entit faible, on obtient un iden-tification compose qui est souvent plus pratique grer, et peut galement rendre plus faciles certainesrequtes.

    La prsence dun type dentit faible e associ un type dentit implique galement des contraintes

    fortes sur les crations, modifications et destructions des instances de e et car on doit toujours sassurerque la contrainte est valide. Concrtement, en prenant lexemple de Salle et de Cinma, on doit mettre enplace les mcanismes suivants :

    1. Quand on insre une salle dans la base, on doit toujours lassocier un cinma ;

    2. quand un cinma est dtruit, on doit aussi dtruire toutes ses salles ;

    3. quand on modifie la cl dun cinma, il faut rpercuter la modification sur toutes ses salles.

    Pour respecter les rgles de destruction/cration nonces, on doit mettre en place une stratgie. Nous

    verrons que les SGBD relationnels nous permettent de spcifier de telles stratgies.

  • 8/22/2019 Cnam Cours Base De Donnes

    29/209

    3.3. LE MODLE 29

    3.3.4 Associations gnralises

    On peut envisager des associations entre plus de deux entits, mais elles sont plus difficiles com-prendre, et surtout la signification des cardinalits devient beaucoup plus ambigue. La dfinition dune

    association Y -aire est une gnralisation de celle des associations binaires.

    Definition 3.7 Une association Y -aire entre Y types dentits ( 0 2 0 4 4 4 7

    est un ensemble de Y -uplets

    ( 0 ' 2 3 0 4 4 4 0 7 o chaque

    Iappartient

    I.

    Mme sil ny a en principe pas de limite sur le degr dune association, en pratique on ne va jamaisau-del dune association entre trois entits.

    *

    dateConstr.

    nom

    ruenumro

    no

    Film

    idtitreannegenretarif

    heureDbutheureFin

    id

    SanceSalle

    capacit

    Cinma

    ville

    Horaire

    FIG . 3.11 Association ternaire reprsentant les sances

    Salle Rex1 Impitoyable

    VertigoSalle Kino3

    14h16h 16h18h

    Horaires

    SallesFilms

    FIG . 3.12 Graphe dune association ternaire

    Nous allons prendre lexemple dune association permettant de reprsenter la projection de certainsfilms dans des salles certains horaires. Il sagit dune association ternaire entre les types dentits Film,Salle et Horaire (figure 3.11). Chaque instance de cette association lie un film, un horaire et une salle. Lafigure 3.12 montre quelques-unes de ces instances.

    Bien que, jusqu prsent, une association ternaire puisse tre considre comme une gnralisationdirecte des associations binaires, en ralit de nouveaux problmes sont soulevs.

    Tout dabord les cardinalits sont, implicitement,

    0..* . Il nest pas possible de dire quune entit ne

    participe quune fois lassociation. Il est vrai que, dune part la situation ce prsente rarement, dautrepart cette limitation est due la notation UML qui place les cardinalits lextrmit oppose dune entit.

    Plus problmatique en revanche est la dtermination de la cl. Quest-ce qui identifie un lien entre troisentits ? En principe, la cl est le triplet constitu des cls respectives de la salle, du film et de lhoraire

    constituant le lien. On aurait donc leY

    -uplet [nomCinma, noSalle, idFilm, idHoraire]. Une telle cl est

  • 8/22/2019 Cnam Cours Base De Donnes

    30/209

    30 CHAPITRE 3. LE MODLE ENTIT/ASSOCIATION

    assez volumineuse, ce qui risque de poser des problmes de performance. De plus elle ne permet pasdimposer certaines contraintes comme, par exemple, le fait que dans une salle, pour un horaire donn, ilny a quun seul film. Comme le montre la figure 3.12, il est tout fait possible de crer deux liens distincts

    qui sappuient sur le mme horaire et la mme salle.Ajouter une telle contrainte, cest signifier que la cl de lassociation est en fait le couple (nomCinma,noSalle, idHoraire]. Donc cest un sous-ensemble de la concatnation des cls, ce qui semble rompreavec la dfinition donne prcdemment. On peut videmment compliquer les choses en ajoutant unedeuxime contrainte similaire, comme connaissant le film et lhoraire, je connais la salle . Il faut ajou-ter une deuxime cl [idFilm, idHoraire]. Il nest donc plus possible de dduire automatiquement la clcomme on le faisait dans le cas des associations binaires. Plusieurs cls deviennent possibles : on parle decl candidates.

    Lesassociations de degr suprieur deux sont donc difficiles manipuler et interprter. Il est toujourspossible de remplacer cette association par un type dentit. Pour cela on suit la rgle suivante :

    Rgle 3.1 Soit une association entre les types dentit % ( 0 2 0 4 4 4 0 7 8

    . La transformation de entype dentit seffectue en trois tapes :

    1. On attribue un identifiant autonome

    .

    2. On cre une association I

    de type 1:n entre et chacun des I. La contrainte minimale, du ct

    de , est toujours 1.

    Lassociation prcdente peut tre transforme en un type dentit Sance. On lui attribue un identifiantidSeance et des associations 1-n avec Film, Horaire et Salle. Voir figure 3.13.

    *

    dateConstr.

    heureDbutheureFin

    id

    Film

    idtitreannegenre

    nom

    rue

    numrono

    id

    tarif

    Sance1..1 *

    1..1

    * 1..1

    *

    Salle

    capacit

    HoraireCinma

    ville

    FIG . 3.13 Lassociation Sance transforme en entit

    3.4 Avantage et inconvnients du modle E/A

    Le modle Entit/Association est simple et pratique.

    1. Il ny a que 3 concepts : entits, associations et attributs.

    2. Il est appropri une reprsentation graphique intuitive, mme sil existe beaucoup de conventions.

    3. Il permet de modliser rapidement des structures pas trop complexes.

    Il y a malheureusement plusieurs inconvnients. Tout dabord il est non-dterminisme : il ny a pas de

    rgle absolue pour dterminerce qui est entit, attribut ou relation. Exemple : est-il prfrable de reprsenter

  • 8/22/2019 Cnam Cours Base De Donnes

    31/209

    3.5. EXERCICES 31

    le metteur en scne (MES) comme un attribut de Film ou comme une association avec Artiste ? Rponse :comme une association ! Les arguments sont les suivants :

    1. On connat alors non seulement le nom, mais aussi toutes les autres proprits (prnom, ge, ...).

    2. Lentit MES peut-tre associe beaucoup dautres films : on permet le partage de linformation.

    Autre exemple : est-il indispensable de grer une entitHoraire? Rponse : pas forcment ! Arguments :

    1. Pour. Permet de normaliser les horaires. Plusieurs sances peuvent alors faire rfrence au mmehoraire (gain de place, facilit de mise jour, cohrence, ...)

    2. Contre. On alourdit le schma inutilement : un horaire est propre une sance. On peut le reprsentercomme un attribut de Sance.

    Enfin on a vu quune association pouvait tre transforme en entit. Un des principaux inconvnientsdu modle E/A reste sa pauvret : il est difficile dexprimer des contraintes dintgrit, des structures com-

    plexes. Beaucoup dextensions ont t proposes, mais la conception de schma reste en partie matire debon sens et dexprience. On essaie en gnral :

    1. de se ramener des associations entre 2 entits : au-del, on a probablement intrt a transformerlassociation en entit ;

    2. dviter toute redondance : une information doit se trouver en un seul endroit ;

    3. enfin et surtout de privilgier la simplicit et la lisibilit, notamment en ne reprsentant que cequi est strictement ncessaire.

    Pour en savoir plus

    Le modle E/A est utilis dans la plupart des mthodes danalyse/conception : OMT, CASE, MERISE,

    etc. La syntaxe varie, mais on retrouve toujours les mmes lments fondamentaux. Pour en savoir (beau-coup) plus : J. Rumbauch h i q , r i s u h w x ` .

    Dans le cadre des bases de donnes, le modle E/A est utilis dans la phase de conception. Il permetde spcifier la structure des informations qui vont tre contenues dans la base et doffrir une reprsentationabstraite indpendante du modle logique qui sera choisi ensuite. Le modle E/A cepedant linconvnientmajeur de ne pas proposer doprations sur les donnes.

    3.5 Exercices

    Exercice 3.1 On vous donne un schma E/A (figure 3.14) reprsentant des visites dans un centre mdical.Rpondez aux questions suivantes en fonction des caractristiques de ce schma (autrement dit, indiquez sila situation dcrite est reprsentable, indpendamment de sa vraissemblance).

    1. Un patient peut-il effectuer plusieurs visites ?

    2. Un mdecin peut-il recevoir plusieurs patients dans la mme consultation ?

    3. Peut-on prescrire plusieurs mdicaments dans une mme consultation?

    4. Deux mdecins diffrents peuvent-ils prescrire le mme mdicament ?

    Exercice 3.2 Le second schma (figure 3.15) reprsente des rencontres dans un tournoi de tennis.

    1. Peut-on jouer des matchs de double ?

    2. Un joueur peut-il gagner un match sans y avoir particip ?

  • 8/22/2019 Cnam Cours Base De Donnes

    32/209

    32 CHAPITRE 3. LE MODLE ENTIT/ASSOCIATION

    nbPrises

    Mdicament

    Assiste

    Donne

    Mdecin Patient

    noSSmatriculecode

    no

    libell nom

    0..*

    0..* 0..*

    0..*

    1..1 1..1

    Consultation

    nom

    date

    FIG . 3.14 Centre mdical

    nonoCarte

    id

    0..*

    0..*

    0..*

    2..2

    Joue

    Gagne

    1..1

    1..1

    Terrain

    surface

    Joueur

    nom

    Match

    horaire Se joue sur

    FIG . 3.15 Tournoi de tennis

    3. Peut-il y avoir deux matchs sur le mme terrain la mme heure?

    4. Connaissant un joueur, peut-on savoir sur quels terrains il a jou ?

    Exercice 3.3 Voici le schma E/A (figure 3.16) du systme dinformation (trs simplifi) dun quotidien.

    1. Un article peut-il tre rdig par plusieurs journalistes?

    2. Un article peut-il tre publi plusieurs fois?

    3. Peut-il y avoir plusieurs articles sur le mme sujet dans le mme numro ?

    4. Connaissant une article, est-ce que je connais le journal o il est paru?

    Exercice 3.4 Voici (figure 3.17) le dbut dun schma E/A pour la gestion dune mdiathque. La spcifi-cation des besoins est la suivante : un disque est constitu dun ensemble de plages. Chaque plage contientun oeuvre et une seule, mais une oeuvre peut stendre sur plusieurs plages (Par exemple une symphonieen 4 mouvements). De plus, pour chaque plage, on connat les interprtes.

    1. Compltez le modle de la figure 3.17, en ajoutant les cardinalits.

    2. On suppose que chaque interprte utilise un instrument (voix, piano, guitare, etc) et un seul sur uneplage. O placer lattribut

    Instrument

    dans le modle prcdent?

    3. Transformez lassociation

    Joue

    dans la figure 3.17 en entit. Donnez le nouveau modle, sansoublier les cardinalits.

    4. Introduisez maintenant les entits Auteur (dune oeuvre) etEditeur dun disque dans le schma. Un

    disque na quun diteur, mais une oeuvre peut avoir plusieurs auteurs.

  • 8/22/2019 Cnam Cours Base De Donnes

    33/209

    3.5. EXERCICES 33

    Journaliste

    id interviewe id

    Sujet

    id

    nom

    nom

    dateNaiss

    Numrono

    0..n 0..n

    rdige

    1..1

    0..n no

    datetirage

    0..na travaill pour

    0..n

    1..1

    0..n

    parat dans

    0..n 1..1

    Personnalit

    Journal

    Article

    libelle

    adresse

    contenu

    nom

    prnomnation.

    FIG . 3.16 Systme dinformation dun quotidien

    titre

    producteur

    id

    anne

    id

    prnom

    joue sur

    nodateEnreg

    Disque

    anne

    Oeuvre

    titre

    Plage

    Interprte

    nom

    dure

    FIG . 3.17 Contenu dun disque

    Exercice 3.5 La figure 3.18 montre la modlisation de sances de cours sous forme dune associationternaire. Noter que lhoraire fait partie de la cl (on aurait pu le reprsenter comme une entit supplmen-taire).

    La notion de

    cours

    regroupe les notions de cours magistral, enseignement dirig et travaux pra-tiques, pour une UV donne. Par exemple lUV Base de donnes comprend un cours, un ED et un TP.

    1. Donner une reprsentation, sous forme de graphe ou de tableau, de linstance de lassociation cor-respondant aux enseignements (cours, EDs, TPs) de lUV Base de donnes.

    2. Comment exprimer les contraintes suivantes : (i) un professeur ne donne pas deux cours en mme

    temps, (ii) Pour une salle, un cours, un horaire, il y a un seul professeur.

  • 8/22/2019 Cnam Cours Base De Donnes

    34/209

    34 CHAPITRE 3. LE MODLE ENTIT/ASSOCIATION

    3. Transformer lassociation en entit, selon la rgle vue en cours.

    Exercice 3.6 Voici quelques tableaux (figure 3.19, 3.20, 3.21) reprsentant des associations entre entits.Pour chacun,

    1. Donner une reprsentation sous forme de graphe.

    2. Donner le schma E/A avec les cardinalits correspondant aux exemples donns.

    #ID

    #ID

    #ID

    COURS SALLE

    PROFESSEUR

    Libelle

    Niveau

    No

    Emplacement

    Nom

    Grade

    Seance

    #date-heure

    FIG . 3.18 Sances de cours

    SOCIETE DIRECTEUR

    Tresys CharlusFungus MorelDemona Saint-LoupFaribole Charlus

    FIG . 3.19 Association SOCIETE/DIRECTEUR

    ORDINATEUR UTILISATEURPC124 Charlus

    MAC04 MorelMAC03 Saint-Loup

    PC02 Morel

    MAC03 Charlus

    FIG . 3.20 Association ORDINATEUR/UTILISATEUR

    ORDINATEUR DISQUESPC124 dsk09

    MAC04 dsk08MAC04 dsk05PC124 dsk11PC02 dsk04

    FIG . 3.21 Association ORDINATEUR/DISQUES DURS

  • 8/22/2019 Cnam Cours Base De Donnes

    35/209

    35

    Chapitre 4

    Le modle relationnel

    Sommaire

    4.1 Dfinition dun schma relationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

    4.2 Passage dun schma E/A un schma relationnel . . . . . . . . . . . . . . . . . . . 37

    4.2.1 Rgles gnrales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

    4.2.2 Retour sur le choix des identifiants . . . . . . . . . . . . . . . . . . . . . . . . 43

    4.2.3 Dnormalisation du modle logique . . . . . . . . . . . . . . . . . . . . . . . . 43

    4.3 Le langage de dfinition de donnes SQL2 . . . . . . . . . . . . . . . . . . . . . . . 45

    4.3.1 Types SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

    4.3.2 Cration des tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

    4.3.3 Contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

    4.3.4 Modification du schma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

    4.4 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

    Un modle de donnes dfinit un mode de reprsentation de linformation selon trois composantes :

    1. Des structures de donnes.

    2. Des contraintes qui permettent de spcifier les rgles que doit respecter une base de donnes.

    3. Des oprations pour manipuler les donnes, en interrogation et en mise jour.

    Les deux premires composantes relvent du Langage de Dfinition de Donnes (DDL) dans un SGBD.Le DDL est utilis pour dcrire le schma dune base de donnes. La troisime composante (oprations)est la base du Langage de Manipulation de Donnes (DML) dont le reprsentant le plus clbre est SQL.

    Dans le contexte des bases de donnes, la principale qualit dun modle de donnes est dtre indpen-

    dant de la reprsentation physique. Cette indpendance permet de sparer totalement les tches respectivesdes administrateurs de la base, chargs de loptimisation de ses performances, et des dveloppeurs dap-plication ou utilisateurs finaux qui nont pas se soucier de la manire dont le systme satisfait leursdemandes.

    Le modle relationnel, venant aprs les modles hirarchique et rseau, offre une totale indpendanceentre les reprsentations logique et physique. Ce chapitre prsente la partie du modle relative la dfinitionet la cration des tables, ce qui constitue lessentiel du schma.

    4.1 Dfinition dun schma relationnel

    Un des grands avantages du modle relationnel est sa trs grande simplicit. Il nexiste en effet quuneseule structure, la relation. Une relation peut simplement tre reprsente sous forme de table, comme sur

    la figure 4.1. Une relation a donc un nom (Film) et se compose dun ensemble de colonnes dsignes par

  • 8/22/2019 Cnam Cours Base De Donnes

    36/209

    36 CHAPITRE 4. LE MODLE RELATIONNEL

    titre anne genreAlien 1979 Science-FictionVertigo 1958 Suspense

    Volte-face 1997 ThrillerPulp Fiction 1995 Policier

    FIG . 4.1 Une relation

    un nom dattribut. Dans chaque colonne on trouve des valeurs dun certain domaine (chanes de caractres,nombres). Enfin on constate que chaque ligne (ou tuple) correspond une entit (ici des films).

    Un schma relationnel est constitu dun ensemble de schmas de relations qui dcrivent, laidedes lements prsents informellement ci-dessus (domaines, attributs, noms de relation) le contenu dunerelation. Le schma de la relation de la figure 4.1 est donc :

    Film (titre: string, anne: number, genre : string)

    Il existe un langage de dfinition pour crer une relation dans un SGBDR (voir section 4.3), mais nousnous contenterons pour linstant de la description ci-dessus. Voici maintenant quelques prcisions sur laterminologie introduite ci-dessus.

    Domaines

    Un domaine de valeurs est un ensemble dinstances dun type lmentaire. Exemple: les entiers, lesrels, les chanes de caractres, etc. La notion de type lmentaire soppose celle de type structur : ilest interdit en relationnel de manipuler des valeurs instances de graphes, de listes, denregistrements, etc.En dautres termes le systme de types est fig et fourni par le systme.

    AttributsLes attributs nomment les colonnes dune relation. Il servent la fois indiquer le contenu de cette

    colonne, et la rfrencer quand on effectue des oprations. Un attribut est toujours associ un domaine.Le nom dun attribut peut apparatre dans plusieurs schmas de relations.

    Schma de relation

    Un schma de relation est simplement un nom suivi de la liste des attributs, chaque attribut tant associ son domaine. La syntaxe est donc :

    ( ( 0 2 2 0 4 4 4 0 7 7

    o les I

    sont les noms dattributs et les I

    les domaines. Laritdune relation est le nombre de sesattributs.

    On peut trouver dans un schma de relation plusieurs fois le mme domaine, mais une seule fois unnom dattribut. Le domaine peut tre omis en phase de dfinition.

    Instance dune relation

    Une instance dune relation

    , ou simplement relation se dfinit mathmatiquement comme un sous-ensemble fini du produit cartsien des domaines des attributs de

    . Rappelons que le produit cartsien

    ( 4 4 4 7entre des domaines

    ( 0 4 4 4 0 7est lensemble de tous les tuples

    ( 0 4 4 4 0 7 o

    I " I.

    Un des fondements du modle relationnel est la thorie des ensembles et la notion de relation dans lemodle correspond strictement au concept mathmatique dans cette thorie.

    Une relation se reprsente sous forme de table, et on emploie le plus souvent ces deux termes comme

    des synonymes.

  • 8/22/2019 Cnam Cours Base De Donnes

    37/209

    4.2. PASSAGE DUN SCHMA E/A UN SC