Cours de bases de données. Philippe Rigaux

Transcription

1 Cours de bases de données Philippe Rigaux 13 juin 2001

2 2

3 TABLE DES MATIÈRES 3 Table des matières 1 Introduction 7 2 Présentation générale Données, Bases de données et SGBD Que doit-on savoir pour utiliser un SGBD? Définition du schéma de données Les opérations sur les données Optimisation Concurrence d accès Le plan du cours I Modèles et langages 15 3 Le modèle Entité/Association Principes généraux Bons et mauvais schémas La bonne méthode Le modèle E/A : Présentation informelle Le modèle Entités, attributs et identifiants Associations binaires Entités faibles Associations généralisées Avantage et inconvénients du modèle E/A Exercices Le modèle relationnel Définition d un schéma relationnel Passage d un schéma E/A à un schéma relationnel Règles générales Retour sur le choix des identifiants Dénormalisation du modèle logique Le langage de définition de données SQL Types SQL Création des tables Contraintes Modification du schéma Exercices

4 4 TABLE DES MATIÈRES 5 L algèbre relationnelle Les opérateurs de l algèbre relationnelle La sélection, La projection, Le produit cartésien, L union, La différence, Jointure, Expression de requêtes avec l algèbre Sélection généralisée Requêtes conjonctives Requêtes avec et Exercices Le langage SQL Requêtes simples SQL Sélections simples La clause WHERE Valeurs nulles Requêtes sur plusieurs tables Jointures Union, intersection et différence Requêtes imbriquées Conditions portant sur des relations Sous-requêtes correllées Agrégration Fonctions d agrégation La clause GROUP BY La clause HAVING Mises-à-jour Insertion Destruction Modification Exercices Schémas relationnels Schémas Définition d un schéma Utilisateurs Contraintes et assertions Vues Création et interrogation d une vue Mise à jour d une vue Triggers Principes des triggers Syntaxe Exercices Programmation avec SQL Interfaçage avec le langage C Un exemple complet Développement en C/SQL Autres commandes SQL L interface Java/JDBC

5 TABLE DES MATIÈRES Principes de JDBC Le plus simple des programmes JDBC Exemple d une applet avec JDBC II Aspects systèmes Techniques de stockage Stockage de données Supports Fonctionnement d un disque Optimisations Technologie RAID Fichiers Enregistrements Blocs Organisation d un fichier Oracle Fichiers et blocs Les tablespaces Création des tables Indexation Indexation de fichiers Index non-dense Index dense Index multi-niveaux L arbre-b Présentation intuitive Recherches avec un arbre-b Hachage Principes de base Hachage extensible Les index bitmap Indexation dans Oracle Arbres B Arbres B Indexation de documents Tables de hachage Index bitmap Introduction à la concurrence d accès Préliminaires Exécutions concurrentes : sérialisabilité Transaction Exécutions concurrentes : recouvrabilité Contrôle de concurrence Verrouillage à deux phases Contrôle par estampillage Gestion des transactions en SQL Exercices

6 6 TABLE DES MATIÈRES 12 Travaux pratiques Environnement Connexion au système Les commandes utiles Utilisation de SQLPLUS Requêtes SQL Sélections simples Jointures Négation Fonctions de groupe Concurrence d accès Normalisation d un schéma relationnel Optimisation

7 7 Chapitre 1 Introduction Sommaire Ce cours s adresse aux étudiants du cycle A du CNAM et a pour objectif l étude des principes des SGBD relationnels et la mise en pratique de ces principes. Le contenu du cours est essentiellement le suivant : 1. Conception d un schéma relationnel. Il s agit de savoir définir un schéma relationnel complet et correct, comprenant des tables, des contraintes, des vues. 2. Langages d interrogation et de manipulation. L accent est mis sur SQL et ses fondements, et sur l intégration de SQL avec un langage de programmation comme le C. De plus, le cours comprend une introduction aux problèmes de concurrence d accès, dont la connaissance est nécessaire aux développeurs d applications basées sur des SGBD. Des travaux pratiques avec le SGBD ORACLE permettent de mettre en oeuvre les techniques étudiées en cours. L accent est donc plutôt mis sur les notions de base (qu est-ce qu un SGBD, qu une base de données, qu un langage d interrogation) et leur application pratique. Il demandé d avoir acquis à la fin du cours les connaissances nécessaires à l utilisation d un SGBD par un informaticien non-spécialiste. : création d un schéma, insertion, mise-à-jour, destruction, interrogation de données, et comprehension des mécanismes de concurrence intervenant dans la gestion d un SGBD. En revanche, tout ce qui relève de la compréhension des mécanismes internes d un SGBD (représentation physique, évaluation de requêtes) ou des fondements théoriques du modèle relationnel n est pas abordé ici. Ce document est un support de cours : il ne prétend certainement pas être exhaustif ni traiter en détail tous les sujets abordés. L assistance au cours proprement dit, ainsi qu aux travaux dirigés et aux travaux pratiques est fortement recommandée. Il existe de plus un site WEB qui donne des renseignements complémentaires, les horaires des cours, les solutions de certains exercices, etc. Voici l adresse : Pour ceux qui veulent en savoir plus, il existe une riche bibliographie dont voici quelques éléments recommandables : Ouvrages en français 1. Carrez C., Des Structures aux Bases de Données, Masson 2. Gardarin G., Maîtriser les Bases de Données: modèles et langages, Eyrolles 3. Marcenac, P., SGBD relationnels, Optimisation des performances, Eyrolles.

8 8 CHAPITRE 1. INTRODUCTION Ouvrages en anglais 1. Melton J. et A.R. Simon, Understanding SQL, A Complete Guide, Morgan Kaufmann, Ullman J.D., Principles of Database and Knowledge-Base Systems, 2 volumes, Computer Science Press 3. Date C.J., An Introduction to Database Systems, Addison-Wesley Le premier chapitre (correspondant au premier cours) est une (rapide) présentation de tous les thèmes présentés en détails dans ce cours. On peut le lire comme une mise en perspective générale de l ensemble de l enseignement.

9 9 Chapitre 2 Présentation générale Sommaire 2.1 Données, Bases de données et SGBD Que doit-on savoir pour utiliser un SGBD? Définition du schéma de données Les opérations sur les données Optimisation Concurrence d accès Le plan du cours Ce chapitre présente un panorama général de la problématique des bases de données. 2.1 Données, Bases de données et SGBD La première chose à faire est d établir quelques points de terminologie. Qu est-ce qu une donnée? C est une information quelconque comme, par exemple : voici une personne, elle s appelle Jean. C est aussi une relation entre des informations : Jean enseigne les bases de données. Des relations de ce genre définissent des structures. Une base de données est un ensemble, en général volumineux, de telles informations, avec une caractéristique essentielle : on souhaite les mémoriser de manière permanente. D où la définition : Definition 2.1 Une Base de données est un gros ensemble d informations structurées mémorisées sur un support permanent. On peut remarquer qu une organisation consistant en un (ou plusieurs) fichier(s) stockés sur mémoire secondaire est conforme à cette définition. Un ensemble de fichiers ne présentant qu une complexité assez faible, il n y aurait pas là matière à longue dissertation. Malheureusement l utilisation directe de fichiers soulève de très gros problèmes : 1. Lourdeur d accès aux données. En pratique, pour chaque accès, même le plus simples, il faudrait écrire un programme. 2. Manque de sécurité. Si tout programmeur peut accéder directement aux fichiers, il est impossible de garantir la sécurité et l intégrité des données. 3. Pas de contrôle de concurrence. Dans un environnement où plusieurs utilisateurs accèdent aux même fichiers, des problèmes de concurrence d accès se posent. D où le recours à un logiciel chargé de gérer les fichiers constituant une base de données, de prendre en charge les fonctionnalités de protection et de sécurité et de fournir les différents types d interface nécessaires à l accès aux données. Ce logiciel (le SGBD) est très complexe et fournit le sujet principal de

10 10 CHAPITRE 2. PRÉSENTATION GÉNÉRALE ce cours. En particulier, une des tâches principales du SGBD est de masquer à l utilisateur les détails complexes et fastidieux liés à la gestion de fichiers. D où la définition. Definition 2.2 Un Système de Gestion de Bases de Données (SGBD) est un logiciel de haut niveau qui permet de manipuler les informations stockées dans une base de données. La complexité d un SGBD est essentiellement issue de la diversité des techniques mises en oeuvre, de la multiplicité des composants intervenant dans son architecture, et des différents types d utilisateurs (administrateurs, programmeurs, non informaticiens,...) qui sont confrontés, à différents niveaux, au système. Voici quelques exemples illustrant tous les cas de figure qu il faudrait envisager dans un cours exhaustif : Les modèles de données : entité-relation, réseau, hiérarchique, relationnel, orienté-objet, modèles sémantiques. Les langages de requêtes : fondements théoriques (logiques du premier ordre, du point fixe, algèbres diverses) et les langages comme SQL, SQL3, Datalog, OQL, etc. Les techniques de stockage : sur disque (optique), sur bande. L organisation des fichiers : index, arbre-b, hachage,... L architecture : centralisé, distribué, sur d autres bases accessibles par réseau. Les techniques d évaluation et d optimisation de requêtes. La concurrence d accès et les techniques de reprise sur pane. Pour mettre un peu d ordre dans tout cela, on peut se raccrocher à une architecture standard conforme à la plus grande partie des SGBD existant, et offrant l avantage de bien illustrer les principales caractéristiques d un SGBD. Cette architecture distingue trois niveaux correspondant d une part à trois représentations équivalentes de l information, d autre part aux champs d interventions respectifs des principaux acteurs. Pour ces derniers, nous utiliserons la terminologie suivante : Utilisateur naïf : du non spécialiste des SGBD au non informaticien. Concepteur et programmeur d application : à partir des besoins des différents utilisateurs, écrit l application pour des utilisateurs naïfs. Utilisateur expert : informaticien connaissant le fonctionnement interne d un SGBD et chargé d administrer la base. Chaque niveau du SGBD remplit (réalise) un certain nombre de fonctions : Niveau physiques : gestion sur mémoire secondaire (fichiers) des données, du schéma, des index ; Partage de données et gestion de la concurrence d accès ; Reprise sur pannes (fiabilité) ; Distribution des données et interopérabilité (accès aux réseaux). Niveau logique : Définition de la structure de données : Langage de Description de Données (LDD) ; Consultation et Mise à Jour des données : Langages de Requêtes (LR) et Langage de Manipulation de Données (LMD) ; Gestion de la confidentialité (sécurité) ; Maintien de l intégrité ; Niveau externe : Vues ; Environnement de programmation (intégration avec un langage de programmation) ; Interfaces conviviales et Langages de 4e Génération (L4G) ; Outils d aides (e.g. conception de schémas) ; Outils de saisie, d impression d états. En résumé, un SGBD est destiné à gèrer un gros volume d informations, persistantes (années) et fiables (protection sur pannes), partageables entre plusieurs utilisateurs et/ou programmes et manipulées indépendamment de leur représentation physique.

11 2.2. QUE DOIT-ON SAVOIR POUR UTILISER UN SGBD? Que doit-on savoir pour utiliser un SGBD? L utilisation d un SGBD suppose de comprendre (et donc de savoir utiliser) les fonctionnalités suivantes : 1. Définition du schéma de données en utilisant les modèles de données du SGBD. 2. Opérations sur les données : recherche, mises-à-jour, etc. 3. Partager les données entre plusieurs utilisateurs. (Mécanisme de transaction). 4. Optimiser les performances, par le réglage de l organisation physique des données. Cet aspect relève plutôt de l administration et ne sera évoqué que dans l introduction. Reprenons dans l ordre ces différents points Définition du schéma de données Un schéma est simplement la description des données contenues dans la base. Cette description est conforme à un modèle de données qui propose des outils de description (structures, contraintes et opérations). En fait, dans un SGBD, il existe plusieurs modèles plus ou moins abstraits des mêmes objets, e.g. : Le modèle conceptuel : la description du système d information Le modèle logique : interface avec le SGBD Le modèle physique : fichiers. Ces différents modèles correspondent aux niveaux dans l architecture d un SGBD. Prenons l exemple du modèle conceptuel le plus courant : le modèle Entité/Association. C est essentiellement une description très abstraite qui présente les avantages suivants : l analyse du monde réel la conception du système d information la communication entre différents acteurs de l entreprise En revanche, il ne propose pas d opérations. Or définir des structures sans disposer d opérations pour agir sur les données stockées dans ces structures ne présente pas d intérêt pratique pour un SGBD. D où, à un niveau inférieur, des modèles dits logiques qui proposent : 1. Un langage de définition de données (LDD) pour décrire la structure, incluant des contraintes. 2. Un langage de manipulation de données (LMD) pour appliquer des opérations aux données. Ces langages sont abstraits : le LDD est indépendant de la représentation physique des données, et le LMD est indépendant de l implantation des opérations. On peut citer une troisième caractéristique : oute les structures et les opérations, un modèle logique doit permettre d exprimer des contraintes d intégrité sur les données. Exemple : nom character 15, not null; âge integer between 0 and 120; débit = crédit;...

12 12 CHAPITRE 2. PRÉSENTATION GÉNÉRALE Bien entendu, le SGBD doit être capable de garantir le respect de ces contraintes. Quand on conçoit une application pour une BD, on tient compte (plus ou moins consciemment) de cette architecture en plusieurs niveaux. Typiquement : (1) On décide la structure logique, (2) on décide la structure physique, (3) on écrit les programmes d application en utilisant la structure logique, enfin (4) Le SGBD se charge de transcrire les commandes du LMD en instructions appropriées appliquées à la représentation physique. Cette aproche offre de très grands avantages qu il est important de souligner. Tout d abord elle ouvre l utilisation des SGBD à de utilisateurs non-experts : les langages proposés par les modèles logiques sont plus simples, et donc plus accessibles, que les outils de gestion de fichiers. Ensuite, on obtient une caractéristique essentielle : l indépendance physique. On peut modifier l implantation physique sans modifier les programmes d application. Un concept voisin est celui d indépendance logique : on peut modifier les programmes d application sans toucher à l implantation. Enfin le SGBD décharge l utilisateur, et en grande partie l administrateur, de la lourde tâche de contrôler la sécurité et l intégrité des données Les opérations sur les données Il existe 4 opérations classiques (ou requêtes) : 1. La création (ou insertion). 2. La modification (ou mise-à-jour). 3. La destruction. 4. La recherche. Ces opérations correspondent à des commandes du LMD. La plus complexe est la recherche en raison de la variété des critères. Pour l utilisateur, une bonne requête a les caractéristiques suivantes. Tout d abord elle s exprime facilement : l idéal serait de pouvoir utiliser le langage naturel, mais celui-ci présente trop d ambiguités. Ensuite le langage ne devrait pas demander d expertise technique (syntaxe compliquée, structures de données, implantation particulière...). Il est également souhaitable de ne pas attendre trop longtemps (à charge pour le SGBD de fournir des performances acceptables). Enfin, et peut-être surtout, la réponse doit être fiable. Une bonne partie du travail sur les SGBD consiste à satisfaire ces besoins. Le résultat est ce que l on appelle un langage de requêtes, et constitue à la fois un sujet majeur d étude et une caractéristique essentielle de chaque SGBD. Le langage le plus répandu à l heure actuelle est SQL Optimisation L optimisation (d une requête) s appuie sur l organisation physique des données. Les principaux types d organisation sont les fichiers séquentiels, les index (denses. secondaires, arbres B) et le regroupement des données par hachage. Un module particulier du SGBD, l optimiseur, tient compte de cette organisation et des caractéristiques de la requête pour choisir le meilleur séquencement des opérations Concurrence d accès Plusieurs utilisateurs doivent pouvoir accéder en même temps aux mêmes données. Le SGBD doit savoir : Gérer les conflits si les deux font des mises-à-jour. Offrir un mécanisme de retour en arrière si on décide d annuler des modifications en cours. Donner une image cohérente des données si l un fait des requêtes et l autre des mises-à-jour. Le but : éviter les blocages, tout en empéchant des modifications anarchiques.

13 2.3. LE PLAN DU COURS Le plan du cours Le cours comprend trois parties consacrées successivement à la conception d une base de données relationnelles, aux langages de requêtes relationnels, enfin à la pratique d un SGBD relationnel. Conception d un schéma relationnel Le cours présente d abord la technique classique de conception à l aide du modèle entité/association, suivie de la transcription du schéma obtenu dans le modèle relationnel. On obtient un moyen simple et courant de créer des schémas ayant de bonnes propriétés. Les concepts de bon et de mauvais schémas sont ensuite revus plus formellement avec la théorie de la normalisation. Langages relationnels Les langages d interrogation et de manipulation de données suivants sont présentés : l algèbre relationnelle qui fournit un petit ensemble d opérateurs permettant d exprimer des requêtes complexes et le langage SQL, norme SQL2. Pratique d un SGBD relationnel Cette partie reprend et étend les sujets précédents et développe leur mise en pratique dans l environnement d un SGBD relationnel. Elle comprend : 1. Une revue complète du langage de définition de données SQL2 pour la création de schémas relationnels, incluant l expression de contraintes, les vues et les triggers. 2. Une introduction au développement d applications avec SQL. 3. Une introduction à la concurrence d accès et à ses implications pratiques. 4. Une série de travaux pratiques et d exercices avec le SGBD Oracle.

14 14 CHAPITRE 2. PRÉSENTATION GÉNÉRALE

15 15 Première partie Modèles et langages

16

17 17 Chapitre 3 Le modèle Entité/Association Sommaire 3.1 Principes généraux Bons et mauvais schémas La bonne méthode Le modèle E/A : Présentation informelle Le modèle Entités, attributs et identifiants Associations binaires Entités faibles Associations généralisées Avantage et inconvénients du modèle E/A Exercices Ce chapitre présente le modèle Entité/Association (E/A) qui est utilisé à peu près universellement pour la conception de bases de données (relationnelles principalement). La conception d un schéma correct est essentielle pour le développement d une application viable. Dans la mesure où la base de données est le fondement de tout le système, une erreur pendant sa conception est difficilement récupérable par la suite. Le modèle E/A a pour caractéristiques d être simple et suffisamment puissant pour représenter des structures relationnelles. Surtout, il repose sur une représentation graphique qui facilite considérablement sa compréhension. Le modèle E/A souffre également de nombreuses insuffisances : la principale est de ne proposer que des structures. Il n existe pas d opération permettant de manipuler les données, et pas (ou peu) de moyen d exprimer des contraintes. Un autre inconvénient du modèle E/A est de mener à certaines ambiguités pour des schémas complexes. La présentation qui suit est délibérement axée sur l utilité du modèle E/A dans le cadre de la conception d une base de données. Ajoutons qu il ne s agit pas de concevoir un schéma E/A (voir un cours sur les systèmes d information), mais d être capable de le comprendre et de l interpréter. Dans tout ce chapitre nous prenons l exemple d une base de données décrivant des films, avec leur metteur en scène et leurs acteurs, ainsi que les cinémas où passent ces films. Nous supposerons également que cette base de données est accessible sur le Web et que des internautes peuvent noter les films qu ils ont vus. 3.1 Principes généraux La méthode permet de distinguer les entités qui constituent la base de données, et les associations entre ces entités. Ces concepts permettent de donner une structure à la base, ce qui s avère indispensable. Nous commençons par montrer les problèmes qui surviennent si on traite une base relationnelle comme un simple fichier texte, sans se soucier de lui donner une structure correcte.

18 18 CHAPITRE 3. LE MODÈLE ENTITÉ/ASSOCIATION Bons et mauvais schémas Considérons une table FilmSimple stockant des films avec quelques informations de base, dont le metteur en scène. Voici une représentation de cette table. titre année nommes prénommes annéenaiss Alien 1979 Scott Ridley 1943 Vertigo 1958 Hitchcock Alfred 1899 Psychose 1960 Hitchcock Alfred 1899 Kagemusha 1980 Kurosawa Akira 1910 Volte-face 1997 Woo John 1946 Pulp Fiction 1995 Tarantino Quentin 1963 Titanic 1997 Cameron James 1954 Sacrifice 1986 Tarkovski Andrei 1932 Même pour une information aussi simple, il est facile d énumérer tout un ensemble de problèmes potentiels. Tous ou presque découlent d un grave défaut de la table ci-dessus : il est possible de représenter la même information plusieurs fois. Anomalies lors d une insertion Rien n empêche de représenter plusieurs fois le même film. Pire : il est possible d insérer plusieurs fois le film Vertigo en le décrivant à chaque fois de manière différente, par exemple en lui attribuant une fois comme réalisateur Alfred Hitchcock, puis une autre fois John Woo, etc. Une bonne question consiste d ailleurs à se demander ce qui distingue deux films l un de l autre, et à quel moment on peut dire que la même information a été répétée. Peut-il y avoir deux films différents avec le même titre par exemple? Si la réponse est non, alors on devrait pouvoir assurer qu il n y a pas deux lignes dans la table avec la même valeur pour l attribut titre. Si la réponse est oui, il reste à déterminer quel est l ensemble des attributs qui permet de caractériser de manière unique un film. Anomalies lors d une modification La redondance d information entraîne également des anomalies de mise à jour. Supposons que l on modifie l année de naissance de Hitchcock pour la ligne Vertigo et pas pour la ligne Psychose. On se retrouve alors avec des informations incohérentes. Les mêmes questions que précédemment se posent d ailleurs. Jusqu à quel point peut-on dire qu il n y a qu un seul réalisateur nommé Hitchcock, et qu il ne doit donc y avoir qu une seule année de naissance pour un réalisateur de ce nom? Anomalies lors d une destruction On ne peut pas supprimer un film sans supprimer du même coup son metteur en scène. Si on souhaite, par exemple, ne plus voir le film Titanic figurer dans la base de données, on va effacer du même coup les informations sur James Cameron La bonne méthode Une bonne méthode évitant les anomalies ci-dessus consiste à ; 1. être capable de représenter individuellement les films et les réalisateurs, de manière à ce qu une action sur l un n entraîne pas systématiquement une action sur l autre ; 2. définir une méthode d identification d un film ou d un réalisateur, qui permette d assurer que la même information est représentée une seule fois ; 3. préserver le lien entre les films et les réalisateurs, mais sans introduire de redondance.

19 3.1. PRINCIPES GÉNÉRAUX 19 Commençons par les deux premières étapes. On va d abord distinguer la table des films et la table des réalisateurs. Ensuite on décide que deux films ne peuvent avoir le même titre, mais que deux réalisateurs peuvent avoir le même nom. Afin d avoir un moyen d identifier les réalisateurs, on va leur attribuer un numéro, désigné par id. On obtient le résultat suivant, les identifiants (ou clés) étant en gras. titre année Alien 1979 Vertigo 1958 Psychose 1960 Kagemusha 1980 Volte-face 1997 Pulp Fiction 1995 Titanic 1997 Sacrifice 1986 La table des films id nommes prénommes annéenaiss 1 Scott Ridley Hitchcock Alfred Kurosawa Akira Woo John Tarantino Quentin Cameron James Tarkovski Andrei 1932 La table des réalisateurs Premier progrès : il n y a maintenant plus de redondance dans la base de données. Le réalisateur Hitchcock, par exemple, n apparaît plus qu une seule fois, ce qui élimine les anomalies de mise à jour évoquées précédemment. Il reste à représenter le lien entre les films et les metteurs en scène, sans introduire de redondance. Maintenant que nous avons défini les identifiants, il existe un moyen simple pour indiquer quel est le metteur en scène qui a réalisé un film : associer l identifiant du metteur en scène au film. On ajoute un attribut idmes dans la table Film, et on obtient la représentation suivante. titre année idmes Alien Vertigo Psychose Kagemusha Volte-face Pulp Fiction Titanic Sacrifice La table des films id nommes prénommes annéenaiss 1 Scott Ridley Hitchcock Alfred Kurosawa Akira Woo John Tarantino Quentin Cameron James Tarkovski Andrei 1932 La table des réalisateurs Cette représentation est correcte. La redondance est réduite au minimum puisque seule la clé identifiant un metteur en scène a été déplacée dans une autre table (on parle de clé étrangère). On peut vérifier que toutes les anomalies que nous avons citées ont disparu. Anomalie d insertion. Maintenant que l on sait quelles sont les caractéristiques qui identifient un film, il est possible de déterminer au moment d une insertion si elle va introduire ou non une redondance. Si c est le cas on doit interdire cette insertion. Anomalie de mise à jour. Il n y a plus de redondance, donc toute mise à jour affecte l unique instance de la donnée à modifier. Anomalie de destruction. On peut détruire un film sans affecter les informations sur le réalisateur. Ce gain dans la qualité du schéma n a pas pour contrepartie une perte d information. Il est en effet facile de voir que l information initiale (autrement dit, avant décomposition) peut être reconstituée intégralement. En prenant un film, on obtient l identité de son metteur en scène, et cette identité permet de trouver l unique ligne dans la table des réalisateurs qui contient toutes les informations sur ce metteur en scène. Ce processus de reconstruction de l information, dispersée dans plusieurs tables, peut s exprimer avec SQL. La modélisation avec un graphique Entité/Association offre une méthode simple pour arriver au résultat ci-dessus, et ce même dans des cas beaucoup plus complexes.

20 20 CHAPITRE 3. LE MODÈLE ENTITÉ/ASSOCIATION 3.2 Le modèle E/A : Présentation informelle Un schéma E/A décrit l application visée, c est-à-dire une abstraction d un domaine d étude, pertinente relativement aux objectifs visés. Rappelons qu une abstraction consiste à choisir certains aspects de la réalité perçue (et donc à éliminer les autres). Cette sélection se fait en fonction de certains besoins qui doivent être précisément définis. Par exemple, pour notre base de données Films, on n a pas besoin de stocker dans la base de données l intégralité des informations relatives à un internaute, ou à un film. Seules comptent celles qui sont importantes pour l application. Voici le schéma décrivant cete base de données Films (figure 3.1). Sans entrer dans les détails pour l instant, on distingue 1. des entités, représentées par des rectangles, ici Film, Artiste, Internaute et Pays ; 2. des associations entre entités représentées par des liens entre ces rectangles. Ici on a représenté par exemple le fait qu un artiste joue dans des films, qu un internaute note des films, etc. Chaque entité est caractérisée par un ensemble d attributs, parmi lesquels un ou plusieurs forment l identifiant unique (en gras). Comme nous l avons exposé précédemment, il est essentiel de dire ce qui caractérise de manière unique une entité, de manière à éviter la redondance d information. Artiste Internaute id Réalise nom 0..1 prénom 0..* * Donne une note * note nom prénom annéenaissance 0..* Joue Film id titre 0..* année motdeppasse annéenaissance rôle genre résumé Pays * 1..1 code nom langue FIG. 3.1 Le schéma de la base de données Films Les associations sont caractérisées par des cardinalités. La notation 0..* sur le lien Réalise, du côté de l entité Film, signifie qu un artiste peut réaliser plusieurs films, ou aucun. La notation 0..1 du côté Artiste signifie en revanche qu un film ne peut être réalisé que par au plus un artiste. En revanche dans l association Donne une note, un internaute peut noter plusieurs films, et un film peut être noté par plusieurs internautes, ce qui justifie l a présence de 0..* aux deux extrêmités de l association. Le choix des cardinalités est essentiel. Ce choix est aussi parfois discutable, et constitue donc l aspect le plus délicat de la modélisation. Reprenons l exemple de l association Réalise. En indiquant qu un film est réalisé par un seul metteur en scène, on s interdit les rares situations où un film est réalisé par plusieurs personnes. Il ne sera donc pas possible de représenter dans la base de données une telle situation. Tout est ici question de choix et de compromis : est-on prêt en l occurrence à accepter une structure plus complexe (avec 0..* de chaque côté) pour l association Réalise, pour prendre en compte un nombre minime de cas? Les cardinalités sont notées par deux chiffres. Le chiffre de droite est la cardinalité maximale, qui vaut en général 1 ou *. Le chiffre de gauche est la cardinalité minimale. Par exemple la notation 0..1 entre