Bases de données MS-Access

Transcription

1 Steven ROMAN Bases de données MS-Access conception et programmation Traduction de James Guérin O'REILLY Éditions O'REILLY 18 rue Séguier Paris france@oreilly.com Cologne Cambridge Paris Sebastopol Tokyo

2 L'édition originale de ce livre a été publiée aux États-Unis par O'Reilly & Associates sous le titre Access Database Design é4 Programming (ISBN : ). O'REILLY & ASSOCIATES, 1997 Couverture conçue par Edie Freedman & Hanna Dyer Les programmes figurant dans ce livre ont pour but d'illustrer les sujets traités. Il n'est donné aucune garantie quant à leur fonctionnement une fois compilés, assemblés ou interprétés dans le cadre d'une utilisation professionnelle ou commerciale. Éditeur : Xavier CAZIN ÉDITIONS O'REILLY, Paris, 1998 ISBN : Toute représentation ou reproduction, intégrale ou partielle, faite sans le consentement de l' auteur, de ses ayants droit, ou ayants cause, est illicite (loi du 11 mars 1957, alinéa 1 er de l' article 40). Cette représentation ou reproduction, par quelque procédé que ce soit, constituerait une contrefaçon sanctionnée par les articles 425 et suivants du Code pénal. La loi du 11 mars 1957 autorise uniquement, aux termes des alinéas 2 et 3 de l'article 41, les copies ou reproductions strictement réservées à l'usage privé du copiste et non destinées à une utilisation collective d'une part et, d'autre part, les analyses et les courtes citations dans un but d' exemple et d'illustration.

3 Table des Matières Préface... ix Pour obtenir des mises à jour de l'information... xv 1. Introduction...1 Conception des bases de données...1 Programmation des bases de données Modèle relationnel d'une base de données...11 Qu'est-ce qu'une base de données?...12 Les entités et leurs attributs...12 Clés et super-clés Relations entre entités Implantation de modèles relationnels : bases de données relationnelles...21 Implantation d'entités Un court glossaire Implantation de relations dans une base de données relationnelle...26 La base de données relationnelle LIBRARY...32 Fichiers d'index...37 Valeurs NULL...40 Sur le CD-Rom Principes de conception des bases de données Redondances Formes normales...46 Première Forme normale Dépendances fonctionnelles... 47

4 ri Table des Matières Seconde forme normale...49 Troisième forme normale...50 Forme normale de Boyce-Codd...52 Normalisation...53 Sur le CD-Rom Langages de requête et algèbre relationnel...61 Langages de requête Algèbre relationnel et calcul relationnel Détails de l'algèbre relationnel...66 Sur le CD-Rom Langage Access SOL Introduction à Access SQL Conception de requêtes Access Types de requêtes Access Pourquoi utiliser SQL? Access SQL Le composant DDL d'access SQL Le composant DML de Access SQL Sur le CD-ROM Architecture d'un ystème de base de données Pourquoi programmer? Systèmes de bases de données Systèmes de gestion de bases de données Le module de gestion jet DBMS Langages de définition de données Langages de manipulation de données Langages hôte L'architecture client/serveur Sur le CD-Rom Bases de la programmation avec VBA Constantes et variables Lancement d'un programme Opérateurs VBA

5 Table des Matières vii Quelques instructions et fonctions VBA Sur le CD-Rom Programmation DAO : vue d'ensemble Objets Le modèle objet DAO Le modèle objet Microsoft Access Objets de référence Les collections sont aussi des objets La collection Properties Fermeture d'objets DAO Un coup d'ceil sur les objets DAO La fonction CurrentDb Sur le CD-Rom Programmation DAO : Langage de définition de données Créer une base de données Ouvrir une base de données Créer une table et ses champs Créer un index Créer une relation Créer un objet QueryDef Sur le CD-Rom Programmation DAO : Langage de manipulation de données Objets Recordset Ouverture d'un jeu d'enregistrements Recordset Déplacements dans un jeu Recordset Recherches dans un jeu Recordset Édition de données à partir d'un jeu d'enregistrements Sur le CD-Rom

6 viii Table des Matières A. DAO 3.0/3.5 Collections, Propriétés et Méthodes B. Le Quotient : opération complémentaire de l'algèbre relationnel C. Consulter ou créer la base de données échantitlon D. Suggestions de lecture Index

7 Préface Ce livre semble traiter deux sujets distincts-la conception d'une base de données, d'une part, et la programmation d'une base de données, de l'autre. C'est en effet le cas. Il serait fallacieux de prétendre que la conception et la programmation des bases de données sont intimement liées. Dans ces conditions, pourquoi sont-elles abordées dans un même ouvrage? La réponse est simple. Les deux sujets ne sont pas liés, dans le sens où la connaissance de l'un n'implique pas la connaissance de l'autre, mais ils sont cependant intimement imbriqués par le simple fait qu'un utilisateur averti doit avoir nécessairement des connaissances sur chacun de ces sujets pour pouvoir efficacement créer, utiliser et maintenir une base de données. En fait, on peut dire que la création et la maintenance d'une base de données dans Microsoft Access s'effectue en trois grandes étapes-conception de la base, création de l'interface graphique (c'est-à-dire, conception des tables, des requêtes, des formulaires et des rapports) et mise au point de l'application pour qu'elle fonctionne de la manière souhaitée. La seconde de ces étapes est relativement linéaire, dans la mesure où elle consiste principalement à se familiariser avec l'utilisation de l'interface graphique d'access. Une aide est disponible à cet effet à travers le propre système d'aide en ligne du logiciel, de même qu'au travers des douzaines de tomes de 1000 pages ou plus, dédiés à Microsoft Access, et qui n'ont cessé de fleurir sur le sujet. Malheureusement, aucun des livres que j'ai vus ne rend réellement justice aux deux autres étapes. D'où l'existence de ce livre.

8 x Préface Pour être un peu plus précis, le livre poursuit deux objectifs Aborder les concepts de base de la théorie et de la conception des bases de données relationnelles. Discuter de la manière dont on peut profiter toute la puissance de Microsoft Access, à l'aide de la programmation SQL (Structured Query Language) et du modèle DAO (Data Access Object) du moteur de base de données Microsoft Jet. Pour atteindre ce premier objectif, nous décrivons le pourquoi et le comment de la création d'un système de bases de données efficace, en expliquant des concepts tels que Entités et classes d'entités Clés, super-clés et clés primaires Types de relations un-à-un, un-à-plusieurs et plusieurs-à-plusieurs Intégrité référentielle Jointures de différents types (jointures internes, jointures externes, equi-jointu res, semi-jointures, 9-jointures, etc.) Opérations algébriques relationnelles (sélection, projection, jointure, union, intersection, etc.) Formulaires normaux et leur importance Naturellement, dès lors que vous possédez les connaissances de base pour créer une base de données relationnelle efficace, vous voudrez en tirer plein avantage, ce qui ne peut être fait qu'à l'aide de la programmation. En outre, nombre de techniques de programmation que nous abordons dans ce livre peuvent être utilisées pour créer et maintenir une base de données depuis d'autres applications, telles que Microsoft Visual Basic, Microsoft Excel et Microsoft Word. Nous nous empressons d'ajouter que cet ouvrage n'est pas un livre de cuisine traditionnel conçu pour l'apprentissage de Microsoft Access. Par exemple, nous ne discutons pas des formulaires et des rapports, nous n'abordons pas des sujets tels que la sécurité des bases de données et leur duplication ou les problèmes d'utilisateurs multiples. Ceci explique pourquoi nous avons pu limiter ce livre à quelques centaines de pages et le rendre ainsi, nous l'espérons, plus facile à lire. Cet ouvrage est destiné aux utilisateurs Access de tous niveaux. Il s'applique aussi bien aux versions Access 2.0, Access 7.0 et Access 8.0 (une composante de Micro-

9 Préface xi soft Office 97). Nous admettons que vous avez déjà eu l'occasion de faire connaissance avec l'environnement de développement d'access. Par exemple, nous supposons que vous savez déjà créer une table et une requête. Tout au long de l'ouvrage, nous allons utiliser un exemple de base de données de taille modeste pour illustrer les concepts que nous exposons. Il s'agit d'une base appelée LIBRARY, conçue pour recueillir des données sur des livres dans une certaine bibliothèque. Naturellement, la quantité de données que nous utiliserons sera artificiellement maintenue faible-suffisante pour illustrer les concepts. L audience du livre La plupart des livres consacrés à Microsoft Access sont principalement centrés sur son interface Access et ses composants, accordant peu d'attention au thème beaucoup plus important de la conception d'une base de données. En fin de compte, lorsque l' application est achevée, les composants de l'interface jouent un rôle modeste, tandis que la conception détermine l'utilité de l'application. En s'efforçant de traiter surtout de la conception des bases de données, ce livre aspire à être une sorte de cours complémentaire sur Microsoft Access-en somme un livre pour les utilisateurs d'access qui maîtrisent les concepts de base de l'interface, sont rompus à la création de tables et à la réalisation de requêtes, mais veulent maintenant aller au-delà de l'interface et créer des applications Access programmables. Ce livre fournit de solides fondations sur lesquelles vous pouvez commencer à bâtir des applications de bases de données mettant en ceuvre vos capacités de développeur. Ce livre constitue une introduction pour ceux qui aspirent à devenir des développeurs d'applications Access et présente aussi un intérêt pour les programmeurs Access expérimentés. Pour l'essentiel, des sujets tels que les formulaires normaux ou les détails de l'algèbre relationnel sont presque exclusivement la chasse gardée du monde académique. En mettant ces sujets à la portée du coeur de l'audience Access, nous proposons un guide concis, succinct, facile à lire que des développeurs Access expérimentés peuvent feuilleter chaque fois que certains détails leurs échappent dans la conception d'une base de donnérs ou d'instructions SQL. Organisation du livre Cet ouvrage comprend 11 chapitres qui peuvent être répartis en trois parties. Il contient, en outre, quatre annexes.

10 xii Préface Le chapitre 1, Introduction, examine les problèmes qu'entraîne l'utilisation d'une base de données simple -une seule table contenant toutes les données de l'applicationet décrit un cas d'utilisation d'une base de données relationnelle consistant en de multiples tables. En raison du fait que les applications de bases de données relationnelles répartissent les données entre plusieurs tables, il est nécessaire de pouvoir reconstituer les données de manière utile -c'est-à-dire de reconstituer le tout à partir des morceaux prélevés dans les différentes tables. D'où le besoin de langages de requêtes et de la programmation, qui déterminent de bien des manières le mode de conception d'une base de données. La première partie du livre est centrée sur la conception d'une base de données-en d'autres termes, sur le processus qui consiste à décomposer des données entre de multiples tables. Le chapitre 2, Modèle relationnel d'une base de données, introduit certains des concepts de base de la gestion d'une base de données relationnelle, comme les entités, les classes d'entités, les clés, les super-clés, les relations un-à-plusieurs et plusieurs-à-plusieurs. Le chapitre 3, Mise en ceuvre de bases de données à l'aide de modèles relationnels, montre comment les concepts généraux et les principes sont appliqués dans la conception d' une base de données réelle. En particulier, le chapitre montre comment décomposer une base de données simple en une base de données relationnelle correctement conçue. Le chapitre 4, Principes de conception d'une base données, continue l'étude commencée au chapitre 3 en se focalisant sur le problème majeur de la conception des bases de données, sur l'élimination des données redondantes sans perte des relations essentielles entre les différents éléments de la base. Le chapitre introduit la notion de dépendances fonctionnelles et examine chacune des formes majeures de normalisation des bases de données. Lorsqu'une base de données est normalisée ou lorsque ses données sont réparties entre des tables discrètes, elle doit, de manière paradoxale, être «rapiécée» de manière à présenter de la valeur pour tous. La seconde partie du livre est centrée sur les langages de requête qui permettent cette opération. Le chapitre 5, Langages de requête et algèbre relationnel, introduit les langages de requête procéduraux basés sur l'algèbre relationnel et les langages de requête non-procéduraux basés sur le calcul relationnel, puis traite plus spécifiquement des opérations fondamentales-comme les unions, intersections et les jonctions internes ou externes- disponibles lorsqu'on utilise l'algèbre relationnel.

11 Préface X711 Le chapitre 6, Langage SQL (Structured Query Language) et Access, expose comment l' algèbre relationnel est implémenté dans Microsoft Access, à la fois dans la fenêtre de Conception de requêtes d'access et dans Access SQL. À noter que la fenêtre Conception de requêtes d'access est réellement l'interface frontale qui construit les instructions Access SQL, habituellement cachées à l'utilisateur ou au développeur. Elle n'offre pas, cependant, un remplacement complet d'access SQL-un certain nombre d'opérations ne peut être effectué qu'en utilisant des instructions SQL et non par l'intermédiaire de l'interface graphique d'access. Ceci rend importante la connaissance de base d'access SQL. Bien que SQL soit un outil critique pour accéder aux données et retourner des ensembles d'enregistrements offrant différentes vues des données, son utilisation reste peu intuitive. La fenêtre Conception de requêtes d'access, par exemple, a été développée à l'origine pour dissimuler l'implémentation d'access SQL à la fois à l' utilisateur et au programmeur. Mais Access SQL, et les commodités de requête graphique qui le dissimulent, ne constituent pas un environnement intégré sur lequel peut s'appuyer le programmeur de base de données pour préserver l'utilisateur des détails de mise en oeuvre d'une application. Au contraire, la création de cet environnement est de la responsabilité d'un langage de programmation (Visual Basic pour Applications) et une interface entre le langage et le moteur de la base (DAO). La partie finale du livre examine ces deux outils de développement d'applications. Le chapitre 7, Architecture ystème d'une base de données, décrit le rôle de la programmation dans le développement d'applications et introduit les principaux outils et concepts nécessaires pour créer une application Access. Le chapitre 8, Les bases de la programmation dans VBA, fournit une rapide vue d' ensemble de Visual Basic pour Applications qui se concentre sur les types de données, les fonctions intrinsèques les plus utilisées et les déclarations de contrôle de flux. Le chapitre 9, Programmation DAO : vue d'ensemble, introduit la programmation DAO ( Data Access Objects). Le modèle DAO fournit l'interface entre Visual Basic pour Applications et le moteur de bases de données jet utilisé par Access. Le chapitre offre un aperçu de la programmation objet dans VBA avant d'examiner les modèles objet DAO et Microsoft Access. Le chapitre 10, Programmation DAO : langage de définition de données, est centré sur le sousensemble DAO utilisé pour définir les objets d'une base de données. Le chapitre aborde les opérations telles que la création de tables, d'indices et de définitions de requêtes sous le contrôle d'un programme.

12 .xiv Préface Le chapitre 11, Programmation DAO : langage de manipulation de données, explique comment manipuler les jeux d'enregistrement et effectuer des opérations pratiques sur les enregistrements. Le chapitre aborde des sujets tels que la navigation, la recherche et l'édition de données. L'annexe A, Collections DAO 3.0/3.5, propriétés et méthodes, doit être vue comme un guide de références de DAO 3.0 (inclus dans Access pour Office 95) et de DAO 3.5 ( inclus dans Access pour Office 97). L'annexe B, Le quotient : une opération additionnelle de l'algèbre relationnel, examine une opération additionnelle peu utilisée dans les requêtes, qui n'a pas été abordée au chapitre 5. L'annexe C, Obtenir ou créer la base de données échantillon, contient des instructions sur le téléchargement des fichiers exemples du livre ou la création de la base de données par vous-même. L'annexe D, Suggestions de lecture, liste quelques-unes des œuvres majeures qui offrent une approche en profondeur des problèmes relatifs à la conception et à la normalisation des bases de données relationnelles. Conventions introduites dans l'ouvrage Les conventions typographiques suivantes sont utilisées dans cet ouvrage MAJUSCULES indiquent un nom de base de données (c-à-d, LIBRARY) ou le nom d'une table dans une base de données (LIVRES). Les mots-clés dans les instructions SQL ( SELECT) apparaissent également en majuscules, de même que les types de données (LONG), commandes (CREATE VALUE), options (HAVING), etc. Espacement fixe indique un exemple de code. Italique est utilisé dans le texte normal pour introduire un nouveau terme et indiquer des noms d'objet (par exemple, QueryDef), les noms de classes d'entité (par exemple, la classe Livres), et les mots-clés de Visual Basic pour Applications (VBA).

13 Préface Le contenu du CD-Rom Pour faciliter la compréhension des différents chapitres une même base de données, LIBRARY (fichier library.mdb), est utilisée dans tout l'ouvrage. Les exemples de tables de la base de données LIBRARY sont placés dans le répertoire Exemples du CD-Rom qui accompagne ce livre. Les exemples du livre sont repris et accompagnés d' exercices commentés pour la plupart des chapitres. Il a paru judicieux de calquer sur cette première base à caractère didactique, une base de données en vraie grandeur, qui a pour nom CATALOG (fichier catalog.mdb). Elle concerne le catalogue des ouvrages français, allemands et américains des Editions O' Reilly et comporte plusieurs centaines d'enregistrements. Cette base de données se trouve placée sur le CD-Rom dans le répertoire Applis. La base de données CATALOG respecte la structure de la base LIBRARY. Pour faciliter le passage de l'une à l'autre, les noms de champs de la première ont été conservés, mais d'autres champs et d'autres tables ont été ajoutés. En particulier, chaque enregistrement représentant un ouvrage du catalogue est associé à une photo de la première de couverture et à une notice décrivant l'ouvrage. En outre, chaque enregistrement comporte deux liens hypertexte : le premier pointe vers la description détaillée de l'ouvrage placée dans le catalogue national sur le CDRom (catalog.us, catalog.de, catalogfr); le second pointe vers l'un des trois sites Internet des Éditions O'Reilly. Ces liens constituent l'interface entre l'application CATALOG et l'image des sites Web sur le CD ou les sites eux-mêmes sur l'internet. La capacité de créer des liens hypertexte est propre à la dernière version d'access, qui est livrée avec Microsoft Office 97, version entreprise. En conséquence, les exemples du CD-Rom ne sont compatibles qu'avec cette version. Pour obtenir des mises a jour de l'information Les exemples, de même que les échantillons de programmes présentés dans le livre, sont disponibles en ligne sur l'internet et peuvent être librement téléchargés. Si vous ne pouvez pas accéder à l'internet en utilisant un navigateur Web ou un client FTP ( File Transfer Protocol) et si vous n'utilisez pas non plus une messagerie électronique, vous pouvez créer vous-même la base de données et ses tables. Pour plus d' information, voyez l'annexe C. Les mises à jour de l'information contenue dans le livre, ainsi que les développements Access, sont accessibles depuis notre site web, Suivez simplement les liens vers la section Windows. xv

14 xvi Préface Vos commentaires En votre qualité de lecteur, vous pouvez nous aider à améliorer la prochaine édition. Si vous découvrez des erreurs, inexactitudes ou erreurs typographiques dans cet ouvrage, faites-nous le savoir. Prévenez-nous également, si vous trouvez des explications confuses ou des déclarations ambiguës. Envoyez vos compte-rendus de bogues et vos commentaires à Editions O'Reilly 18, rue Séguier PARIS (FAX) frarua(a),ora.c m Faites-nous savoir de quelle manière nous pouvons améliorer ce livre. Nous tiendrons compte de vos commentaires au sérieux et ferons tout ce qui est en notre pouvoir pour rendre ce livre aussi utile que possible. Remerciements Mes remerciements à Ron Petrusha, éditeur chez O'Reilly & Associates, pour les nombreuses suggestions ayant amélioré cet ouvrage. Mes remerciements également à l'équipe de production d'o'reilly & Associates, Jane Ellin, la responsable de production, Edie Freedman qui a conçu la couverture, Nancy Priest pour la conception intérieure, Mike Sierra pour le support utilitaires, Chris Reilley et Rob Romano pour les illustrations, David Futato et Sheryl Avruch pour le contrôle de qualité et Seth Maislin pour l'index.

15 Dans ce chapitre ; Conception des bases de données Programmation des bases de données Introduction Conception des bases de données Comme nous l'avons mentionné dans la préface, l'un des buts de ce livre est d'expliquer les principaux concepts de la théorie moderne des bases de données relationnelles et de montrer comment ils sont mis en application dans Microsoft Access. Permettez-moi de mettre l'accent sur la noblesse de cet objectif. Un exemple simple servira cet objectif. Une base de données est simplement une collection de données ayant une origine commune. Un système de gestion de bases de données est un logiciel conçu pour deux buts principaux Ajouter, effacer et mettre à jour les données dans la base de données Fournir différentes manières de visualiser (à l'écran ou sur le papier) les données de la base de données Si les données sont simples et peu abondantes, une base de données peut-être constituée d'une simple table. En fait, une base de données simple peut facilement être mise à jour à l'aide d'un traitement de texte Pour l'illustrer, supposons que vous vouliez définir une base de données correspondant aux livres d'une bibliothèque. Pour les besoins de cette illustration, supposons donc que la bibliothèque contient quatorze livres. La même discussion s' appliquerait à une bibliothèque de plusieurs centaines de livres. La table 1-1 montre la base de données LIBRARY sous la forme d'une table unique, LIBRARY FLAT. 1

16 Table 1-1. Base de données échantillon LIBRARY FLAT ISBN Titre AulD AuNom AuPhone PubID PubNom PubPhone Prix C++ 4 Roman Big House $ Emma 1 Austen Big House $ Faerie Queene 7 Spenser Big House $ Hamlet 5 Shakespeare Alpha Press $ Iliad 3 Homer Big House $ Jane Eyre I Austen Small House $ King Lear 5 Shakespeare Alpha Press $ Macbeth 5 Shakespeare Alpha Press $ Moby Dick 2 Melville Small House $ On Liberty 8 Mill Big House $ Balloon 13 Sleepy Small House $ Balloon 11 Snoopy Small House $ Balloon 12 Grumpy Small House $ Main Street 10 Jones Small House $ Main Street 9 Smith Small House $ Ulysses 6 Joyce Alpha Press $ Visual Basic 4 Roman Big House $25.00 Les colonnes intitulées AuID et PubID sont insérées dans un but d'identification (c-à-d, pour identifier un auteur ou un éditeur de manière unique). En aucun cas, lur présence ou absence n'affecte le présent exposé.

17 Conception des bases de données 3 La base LIBRARY a été créée en utilisant Microsoft Word. Pour une base de données aussi simple, Word a suffisamment de puissance pour remplir les deux objectifs mentionnés plus haut. L'addition, la suppression et l'édition d'une table ne présente aucun problème particulier (à condition de savoir gérer les tables dans Word). Par exemple, si nous voulons trier les données par auteur, nous pouvons simplement sélectionner la table et choisir Trier depuis le menu Table de Microsoft Word. L' extraction d'une partie des données dans la table (c'est-à-dire, la création d'une vue) peut être effectuée en faisant une copie de la table puis en effaçant les rangées et ou les colonnes appropriées. Pourquoi utiliser une base de données relationnelle? La maintenance d'une seule table, appelée base de données simple, ne réclame pas de connaissances approfondies de la théorie des bases de données. Toutefois, la plupart des bases de données qui méritent une maintenance sont nettement plus compliquées que celle-ci. Les bases de données réelles abritent souvent des centaines de milliers ou même des millions d'enregistrements avec des données profondément imbriquées les unes dans les autres. C'est à ce stade que l'utilisation d' une base de données relationnelle devient essentielle. Considérez, par exemple, la Bibliothèque du Congrès, qui possède plus de 16 millions de volumes dans ses collections. Pour des raisons qui vont vous sembler bientôt évidentes, une simple table pour une telle base de données est totalement inadaptée! Redondances Les principaux problèmes associés à l'utilisation d'une seule table pour maintenir une base de données proviennent de la répétition inutile des données, c'est-à-dire de ce qu'on appelle les redondances. Une certaine répétition des données est toujours nécessaire, comme nous allons le voir, mais l'idée est d'éliminer autant de répétitions inutiles que possible. Les redondances dans la table LIBRARY (table 1-1) sont évidentes. Par exemple, le nom et le numéro de téléphone de l'éditeur Big House sont répétés six fois dans la table, et le numéro de téléphone de Shakespeare est répété trois fois. Dans un effort afin d'éliminer autant de redondances que possible dans une base de données, le concepteur doit ventiler les données entre plusieurs tables. Voici une possibilité de partage pour l'exemple LIBRARY, qui éclate la base de données originelle en quatre tables séparées.

18 4 Chapitre 1: Introduction Une table LIVRES, illustrée à la table 1-2, dans laquelle chaque livre a son propre enregistrement Une table AUTEURS, illustrée à la table 1-3, dans laquelle chaque auteur a son propre enregistrement Une table EDITEURS, illustrées à la table 1-4, dans laquelle chaque éditeur a son propre enregistrement Nous expliquerons le but de la table LIVRE/AUTEUR (qui apparaît à la table 1-5) plus tard. Table 1-2. La table LIVRES extraite de la base de données LIBRARY ISBN Titre PubiD Prix Macbeth 2 $ Faerie Queene 1 $ Emma 1 $ Hamlet 2 $ Main Street 3 $ Visual Basic 1 $ On liberty 1 $ Iliad 1 $ C++ 1 $ Balloon 3 $ Ulysses 2 $ King Lear 2 $ Jane Eyre 3 $ Moby Dick 3 $49.00 Table 1-3. La table AUI E URS extraite de la base de données LIBRARY AuID AuNom AuPhone 1 Austen Grumpy Homer Jones Joyce Melville Mill Roman Shakespeare

19 Conception des bases de données 5 Table 1-3. La table AUl E URS extraite de la base de données LIBRARY(suite) AuNom AuPhone Sleepy Smith Snoopy Spenser Table 1-4. La table EDT1 E URS extraite de la base de données LIBRARY PubiD PubNom PubPhone 1 Big House Alpha Press Small House Table 1-5. La table LIVREIAUI EUR extraite de la base de données LIBRARY ISBN AuID Notez que maintenant le nom et le numéro de téléphone de Big House n'apparaissent qu'une fois dans la base de données (dans la table EDITEURS), de même que le numéro de téléphone de Shakespeare (dans la table AUTEURS).

20 6 Chapitre 1: Introduction Naturellement, certaines données sont imbriquées dans la base. Par exemple, l'information PubID apparaît à plusieurs endroits dans ces tables. Comme nous l'avons mentionné plus haut, nous ne pouvons éliminer toutes les duplications de données et maintenir en même temps leurs inter relations. Pour avoir une idée de la réduction des duplications de données obtenue à l'aide de l' approche en quatre tables, imaginons que la base de données inclut également l' adresse de chaque éditeur. La table 1-1 nécessiterait alors une nouvelle colonne contenant quatorze adresses, nombre d'entre elles étant dupliquées. De son côté, la base de données en quatre tables ne nécessite qu'une nouvelle colonne dans la table EDITEURS, n'ajoutant ainsi qu'un total de trois adresses distinctes. Considérons maintenant la base de données de la Bibliothèque du Congrès qui contient 16 millions d'ouvrages. Supposons que cette base de données contienne des livres en provenance de éditeurs différents. Une colonne comportant l' adresse des éditeurs dans une base de données simple contiendrait 16 millions d' adresses, tandis que dans l'approche multi-tables elle ne réclamerait de rentrer que adresses. Maintenant, si la longueur moyenne d'une adresse est de 50 caractères, l'approche par tables multiples permettrait d'économiser environ 800 millions de caractères ( ) H 50 = millions de caractères En supposant que chaque caractère occupe deux octets (dans le format Unicode qui est utilisé de façon interne par Microsoft Access), l'approche par table unique gaspille environ 1,6 Go d'espace, simplement pour le champ adresse! En vérité, le problème des redondances à lui seul est suffisamment important pour convaincre un concepteur de base de données d'éviter l'approche par table unique. Il y a plusieurs autres problèmes liés aux bases de données à table unique, que nous allons exposer maintenant. Problèmes relatifs aux valeurs multiples Il est évident que certains livres de notre base de données ont été rédigés par plusieurs auteurs. Ceci nous place en face de trois choix dans une base de données à table unique Nous pouvons traiter les livres à auteurs multiples sur plusieurs lignes, une ligne pour chaque auteur, comme cela apparaît dans la base de données LIBRARY, table 1-1, pour les livres Balloon et Main Street.

21 Conception des bases de données 7 Nous pouvons accommoder plusieurs auteurs dans plusieurs colonnes sur une seule ligne, une pour chaque coauteur. Nous pouvons inclure tous les noms d'auteurs dans une seule colonne de la table. Le problème avec la solution à lignes multiples est que toutes les données relatives à un livre doivent être répétés autant de fois qu'il y a d'auteurs du livre - un cas évident de redondance. L'approche multi-colonnes présente le problème de limiter arbitrairement le nombre d'auteurs possibles pour un livre donné et provoque un gaspillage de place (au moins un champ vide) pour les livres n'ayant qu'un auteur. Un autre inconvénient de cette approche est de créer des casse-tête majeurs en programmation. Le troisième choix et d'inclure tous les noms d'auteurs dans une cellule, ce qui crée des problèmes intrinsèques. Par exemple, il devient plus difficile de faire une recherche dans la base de données pour un seul auteur. Pire, comment pourrionsnous créer une liste alphabétique des auteurs? Anomalie de mise à jour En vue de mettre à jour, par exemple, le numéro de téléphone des éditeurs dans la base de données LIBRARY (table 1-1), il est nécessaire de modifier chaque ligne contenant ce numéro de téléphone. Si nous manquons une ligne, nous produisons une anomalie de mise à jour, se traduisant par une table abritant des données fausses. Anomalies d'insertion Des difficultés vont surgir si nous désirons insérer un nouvel éditeur dans la base de données LIBRARY (table 1-1), car nous n'avons à ce stade aucune information sur les livres de cet éditeur. Nous pourrions ajouter une nouvelle ligne à la table existante et placer des valeurs NULL dans toutes les colonnes à l'exception des trois concernant les éditeurs, mais ceci pourrait conduire à des problèmes. Une valeur NULL est une valeur destinée à indiquer une valeur manquante ou inconnue dans un champ. Par exemple, l'ajout de plusieurs éditeurs signifie que la colonne ISBN, qui ne devrait contenir que des données uniques, contiendra plusieurs valeurs NULL. Ce problème d'ordre général est référencé sous le nom d'anomalie d'insertion.

22 8 Chapitre 1: Introduction Anomalies de suppression En contraste avec le problème précédent, si nous effaçons toutes les entrées de livres pour un éditeur donné, nous perdons alors toutes informations sur cet éditeur. C'est une anomalie de suppression. Cette liste de problèmes potentiels devrait suffire à nous convaincre que l'idée d' utiliser une base de données à une seule table n'est en général pas une bonne idée. La conception correcte d'une base de données dicte au bon sens de diviser les données entre plusieurs tables, et d'établir des relations entre elles. Une telle base de données est appelée base de données relationnelle. D'un autre côté, les bases de données relationnelles ont leurs propres problèmes. En voici quelques exemples. Éviter la perte de données Une difficulté dans la conception d'une base de données relationnelle est d'imaginer la manière dont les données doivent être placées dans différentes tables sans perte d' information. Si, par exemple, nous n'avions pas créé la table LIVRE/AUTEUR (table 1-5) de l'exemple précédent, il n'y aurait aucun moyen de déterminer les auteurs de chaque livre. En fait, le seul but de la table LIVRE/AUTEUR est de préserver la relation entre un auteur et ses livres! Maintien de l'intégrité référentielle Nous devons être très attentif au maintien de l'intégrité des diverses relations existant entre les tables lorsque nous effectuons des modifications. Par exemple, si nous décidons d'enlever un éditeur de la base de données, il ne suffit pas d' enlever l'éditeur de la table EDITEURS, car cela laisserait des références boiteuses à cet éditeur dans la table LIVRES. Création de vues Lorsque les données sont réparties entre plusieurs tables, il devient plus difficile de créer des vues variées des données. Par exemple, si nous voulons obtenir une liste de tous les éditeurs qui publient des livres dont le prix est inférieur à 10 dollars. Ceci oblige à rassembler des données provenant de plusieurs tables. Le problème est que, en répartissant les données entre plusieurs tables, nous sommes souvent confrontés au problème de recoller ensemble les morceaux de manière à en obtenir une vue plus complète!

23 Programmation des bases de données 9 Sommaire En résumé, il est clair que pour éviter des problèmes de redondances et des anomalies fâcheuses, une base de données doit contenir plusieurs tables, avec des relations définies entre elles. D'un autre côté, cette conception soulève d'autres difficultés telles que la conception de tables qui évitent la perte de données et en même temps permettent le rapprochement de ces données à partir des différentes tables pour créer des vues synthétiques. Le principal but de la première partie de ce livre sur la conception des bases de données est d'explorer ces sujets fondamentaux. Programmation des bases de données En matière de base de données, la motivation à l'origine de l'apprentissage de la programmation est la puissance. Si vous voulez exercer un contrôle maximal sur vos bases de données, vous serez contraint de programmer. En fait, même des choses simples réclament ici ou là de la programmation. Par exemple, il n'y a aucun moyen de retrouver la liste des champs d'une table donnée en utilisant l'interface graphique d' Access - vous ne pouvez obtenir cette liste que par programmation. Vous pouvez visualiser une telle liste en mode conception de table mais vous ne pouvez pas accéder à la liste elle-même pour, par exemple, la présenter à l'utilisateur final et lui demander s'il désire effectuer des modifications. En outre, la programmation peut être le seul moyen d'accéder à une base de données et de la manipuler depuis une autre application. Si vous travaillez dans Microsoft Excel par exemple, vous pouvez créer et manipuler une base de données Access avec autant de facilité et de puissance que si vous étiez dans Access luimême, mais seulement grâce à de la programmation! La raison à cela est qu'excel est dans l' impossibilité d'afficher une représentation des objets d'une base de données. Vous pouvez créer la base de données avec Access, puis la manipuler de façon programmée de l'intérieur d'excel. Il faut mentionner que la programmation peut vous procurer une grande satisfaction. Il n'y a rien de plus gratifiant que d'observer un programme, que vous avez écrit, accéder aux lignes d'une table et effectuer les changements requis. Il est souvent plus facile d'écrire un programme pour exécuter une action comme celle-ci, que d'essayer de se souvenir comment l'on effectue la même action en utilisant l' interface graphique. En bref, la programmation est synonyme de puissance, mais elle est aussi parfois la voie la plus simple pour parvenir à un but particulier. N'oublions pas non plus que la programmation peut apporter tout simplement beaucoup de plaisir!

24 Dans ce chapitre a Qu'est une base de données? Entités et leurs attributs Clés et super-clés Relations entre entités Modèle relationnel d'une base de données Commençons notre exposé sur la conception d'une base de données en jetant un coup d'œil au modèle informel appelé modèle entité-relation. Ce modèle de base de données relationnelle offre une perspective très utile, en particulier dans le contexte de la conception initiale. Nous allons illustrer les principes généraux de ce modèle à l'aide de notre base de données LIBRARY, utilisée tout au long de cette ouvrage, et conçue pour recueillir les informations sur les livres d'une certaine bibliothèque. La quantité de données que nous allons utiliser sera maintenue artificiellement faible - mais suffisante pour illustrer les concepts. Si, à ce point du livre, vous désirez jeter un coup d'ceil à l'exemple de base de données, reportez-vous au CD-Rom et chargez dans Access le fichier library.mdb qui se trouve dans le répertoire Exemples. Pour obtenir des détails sur l'utilisation de Microsoft Access pour la créer vous-même, voyez l'annexe C, Obtenir ou créer une base de données. Au chapitre suivant, nous implémenterons le modèle entité-relation (E/R) utilisé pour notre base LIBRARY. La base LIBRARY, volontairement limitée, sert principalement des objectifs didactiques. Pour que vous puissiez transposer au fur et à mesure les concepts exposés dans le monde réel, nous avons placé une base de données en vraie grandeur sur le CD.Rom. Ses principales caractéristiques et l'usage qu'on peut en faire sont exposés à la fin de ce chapitre. Pour examiner cette base, chargez dans Access le fichier catalog.mdb que vous trouverez dans le répertoire Applis. 1 1

25 12 Chapitre 2: Modèle relationnel d'une base de données,qu'est-ce qu'une base de données? Un base de donnée peut être définie comme une collection de données persistantes. Le terme persistant est quelque peu vague, mais il est intentionnel ; il implique que les données ont une existence plus ou moins indépendante ou semi permanente. Par exemple, des données conservées sur le papier dans un classeur, stockées sur un disque magnétique ou une bande magnétique sont des données persistantes, tandis que les données présentes dans une mémoire d'ordinateur sont généralement considérées comme volatiles (non persistantes). Le terme "permanent" est un petit peu trop fort, car peu de choses sont vraiment permanentes. Il s'agit naturellement d'un concept très général. La plupart des bases de données réelles contiennent des données qui existent dans un but spécifique et qui sont persistantes. Les entités et leurs attributs Le but d'une base de données est de stocker de l'information sur certains types d' objets. Dans le langage des bases de données, ces objets sont appelés des entités. Par exemple, les entités de la base de données LIBRARY comprennent les livres, les auteurs et les éditeurs. Il est très important dès maintenant de faire une distinction entre les entités qui sont contenues dans une base de données à un moment donné et l'univers de toutes les entités possibles que la base de données pourrait contenir. La raison de cette importance est que le contenu d'une base de données est en perpétuel changement et que nous devons prendre des décisions non seulement basées sur le contenu de la base a un moment donné, mais aussi en fonction de ce qu'elle pourrait contenir dans le futur. À un certain moment, notre base LIBRARY pourrait contenir par exemple 14 entités (livres). Cependant, au fur et à mesure du temps, de nouveaux livres pourront être ajoutés à la base et les plus anciens pourront en être retirés. Si, par exemple, en nous basant sur le fait que les quatorze livres actuellement présents dans la base de données ont des titres différents, nous décidons d'utiliser le titre comme seul identifiant de chaque livre, nous. pourrions rencontrer quelques problèmes plus tard si un livre différent arrivait à la bibliothèque avec le même titre qu'un livre existant. L'ensemble de toutes les entités possibles d'un type spécifique qu'une base de données peut contenir est désigné sous le terme générique de classe d'entités (nous

26 Les entités et leurs attributs 13 utiliserons les caractères italiques pour désigner les classes d'entités). Ainsi, l'univers de tous les livres possibles est la classe d'entité Livres et l'univers de tous les auteurs possibles est la classe d'entités Auteurs. Précisons qu'une classe d'entités n'est qu'une description abstraite de quelque chose, tandis qu'une entité est un exemple concret de cette description. Les classes d'entités de notre exemple très modeste de base de données LIBRARY sont (du moins à ce stade) Livres Auteurs Éditeurs L'ensemble des éléments d'une classe d'entités présents dans la base de données à un moment donné est appelé un jeu d'entités. Pour clarifier la différence entre le jeu d' entités et la classe d'entités, par exemple, considérons la table LIVRES de la base de données LIBRARY, qui est illustrée à la table 2-1. Table 2-1. Table LIVRES extraite de la base LIBRARY ISBN Titre Prix On Liberty $ Iliad $ Faerie Queene $ Emma $ Visual Basic $ C++ $ Hamlet $ Macbeth $ King Lear $ Ulysses $ Jane Eyre $ Moby Dick $ Balloon $ Main Street $22.95 Les entités sont des livres, la classe d'entités est l'ensemble de tous les livres possibles et le jeu d'entités (en ce moment) est le jeu spécifique de 14 livres présentés dans la table LIVRES. Le jeu d'entités va changer lorsque de nouveaux livres

27 14 Chapitre 2: Modèle relationnel d'une base de données (entités livre) seront ajoutés à la table ou lorsque d'anciens livres en seront ôtés. Quant à elle, la classe d'entités ne change pas. Si les concepts de programmation orientée objet vous sont familiers, vous reconnaîtrez le concept de classe. Dans les cercles de la programmation objet, nous ferions référence à une classe d'entités simplement. comme à une classe et à une entité simplement comme à un objet. Les entités d'une classe d'entités possèdent certaines propriétés, appelées attributs. Habituellement, nous les mentionnons comme étant les attributs de la classe d' entités elle-même. Il appartient au concepteur de base de données de déterminer quels attributs il doit inclure pour chaque classe d'entités car ce sont eux qui vont correspondre aux champs dans les tables de la base de données. Les attributs d'une classe d'entités servent trois buts principaux Les attributs sont utilisés pour inclure l'information que nous voulons ajouter à la base de données. Par exemple, si nous voulons que le titre de chaque livre soit inséré dans la base de données, alors nous ajouterons un attribut Titre pour la classe d'entités Livres. Les attributs sont utilisés uniquement pour permettre l'identification d'entités individuelles à l'intérieur d'une classe d'entités. Par exemple, nous pouvons désirer inclure un attribut d'identification ID de l'éditeur pour la classe d'entités Editeurs afin d'identifier de façon unique chaque éditeur. Si des combinaisons d'autres attributs (tels que le nom de l'éditeur ou l'adresse de l'éditeur) servent le même but, l'inclusion d'un attribut d'identification n'est pas strictement nécessaire, mais il peut s'avérer plus efficace d'inclure un tel attribut, lorsque nous pouvons créer un attribut d'identification beaucoup plus court. Par exemple, une combinaison de titre, auteur, éditeur et date de copyright aurait pour résultat un attribut d'identifications inefficace pour la classe d'entités livres - en tout état de cause moins efficace que l'attribut ISBN. Les attributs sont utilisés pour décrire des relations entre les entités présentes dans différentes classes d'entités. Nous aborderons ce sujet plus en détail ultérieurement. Pour l'instant, établissons la liste des attributs pour la base de données LIBRARY dont nous avons besoin pour fournir l'information sur chaque entité et pour identifier chaque entité de manière unique. Nous traiterons ultérieurement du problème de la description des relations. Souvenez-vous que notre exemple est volontairement de petite taille-dans la réalité, il ne fait pas de doute que nous aurions à

28 Les entités et leurs attributs 15 inclure bien d'autres attributs (reportez-vous pour cela à la base de données en vraie grandeur CATALOG). Les attributs des classes d'entités de la base LIBRARY sont Attributs Livres Titre ISBN Prix Attributs Auteurs AuNom AuPhone AuID Attributs Editeurs Pub Nom Pub Phone Pub ID Faisons quelques remarques à propos de ces attributs. A partir de ces attributs considérés isolément, il n'y a pas de moyen direct de déterminer quel est l'auteur d'un livre donné, puisqu'il n'y a pas d'attribut relatif à l'auteur dans la classe d'entités Livres. Une remarque similaire s'applique en ce qui concerne la détermination de l'éditeur d'un livre. Nous avons donc besoin d'ajouter davantage d'attributs afin de décrire ces relations. L'ISBN (International Standard Book Number) d'un livre sert à l'identifier de manière unique, du fait que deux livres différents ne peuvent avoir le même ISBN. Par ailleurs, le titre seul ne permet pas d'identifier de façon unique un livre, car plusieurs livres peuvent avoir le même titre. En fait, l'unique but de l' ISBN (dans le présent exemple et dans le monde réel) est d'identifier les livres de manière unique. Autrement dit, l'isbn est l'attribut d'identification essentiel. On peut raisonnablement supposer qu'il n'y a pas deux éditeurs dans le monde qui ont le même nom ou le même numéro de téléphone. Ainsi, les deux attributs pris ensemble identifient de manière unique l'éditeur. Néanmoins, nous avons inclus un attribut ID d'éditeur pour rendre l'identification plus facile. Soulignons qu'une classe d'entités est une description et non un jeu d'entités. Par exemple, la classe d'entités Livres est une description des attributs des entités que nous identifions comme étant des livres. Une entité Livres est la «version base de

29 16 Chapitre 2: Modèle relationnel d'une base de données données» d'un livre. Ce n'est pas un livre physique, mais plutôt un livre défini par les valeurs de ses attributs. Par exemple, voici l'entité Livres Titre = Gone With The Wind ISBN = Prix = $24.00 Il y a certainement dans le monde plus d'un exemplaire physique du livre Gone W'ith The W'ind, avec cet ISBN et ce prix, mais ceci n'entre pas dans le champ de notre discussion. En ce qui concerne la base de données, il y a seulement une entité livres, définie par Titre = Gone With The Wind ISBN = Prix = $24.00 Si nous voulons représenter dans notre base les différents exemplaires des ouvrages physiques (comme le ferait une bibliothèque), nous devons alors ajouter un autre attribut à la classe d'entités Livres, appelé par exemple NbExemplaires. Même à ce stade, une entité livre n'est rien d'autre qu'un jeu de valeurs d'attributs. Ceci met l'accent sur le fait qu'il appartient au concepteur d'une base de données de garantir que le jeu d'attributs relatifs à une entité distingue cette entité de toutes les autres entités de manière unique (maintenant et pour toujours, si possible!). Par exemple, si la classe d'entités Livres ne comprenait que les attributs Titre et Prix, il y aurait fort à parier sur la possibilité qu'un jour quelqu'un veuille inclure deux livres portant le même titre et ayant le même prix. Ceci est autorisé par certains programmes d'application de bases de données, mais doit être formellement déconseillé, en raison de la confusion qui peut en résulter. C'est même interdit par définition dans une vraie base de données relationnelle. En d'autres termes, deux entités distinctes ne peuvent s'accorder sur l'ensemble de leurs attributs (cela est permis cependant dans Microsoft Access). Clés et super-clés Un jeu d'attributs permettant d'identifier de manière unique et de distinguer toute entité de l'ensemble des autres entités d'une classe d'entités pouvant apparaître dans la base de données est appelé une super-clé pour la classe d'entités. Ainsi, le jeu {ISBN} est une super-clé pour la classe d'entités livres et les jeux {PubID} et {PubNom, PubPhone} sont tous deux des super-clés pour la classe d'entités Editeurs.