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 [email protected] 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.

30 Clés et super-clés 17 Notez qu'il y a une pointe de subjectivité dans la définition de super-clés, car en définitive le choix des entités qui peuvent apparaître dans une base de données dépend d'une décision personnelle et c'est probablement quelque chose sur lequel nous n'avons pas de certitude absolue. Considérez par exemple la classe d'entités Livres. Il n'y a pas de loi promulguant que tous les livres doivent avoir un numéro ISBN (beaucoup de livres n'en ont pas). Il n'y a pas de loi non plus imposant que deux livres ne peuvent avoir le même ISBN (lisbn est attribué, au moins en partie, par l'éditeur du livre). Ainsi, le jeu {ISBN) est seulement une super-clé si l'on est prêt à accepter le fait que tous les livres achetés par le bibliothécaire ont un numéro ISBN distinct ou que le bibliothécaire assignera un ersatz d'isbn distinct à tous les livres qui n'ont pas un vrai ISBN. Il est important de souligner que le concept de super-clé s'applique à des classes d' entités et non à des jeux d'entités. Bien que l'on puisse définir une super-clé pour un jeu d'entités, ceci est d'utilité restreinte, car ce qui peut servir à identifier les entités d'un jeu d'entités particulier peut échouer dans le cas où d'autres entités sont ajoutées à ce jeu. À titre d'illustration, l'attribut Titre sert uniquement à identifier chacun des 14 livres de la table LIVRES. Ainsi, {Titre} est une super-clé pour le jeu d' entités décrit par la table LIVRES. Cependant, {Titre} n'est pas une super-clé pour la classe d'entités Livres, car il y a plusieurs livres distincts portant le même titre. Nous avons fait la remarque que {ISBN} est une super-clé pour la classe d'entités Livres. Naturellement, il en est de même pour (Titre, ISBN}, mais il est inutile et inefficace d'inclure l'attribut Titre uniquement pour des besoins d'identification. En fait, l'une des difficultés inhérentes aux super-clés est qu'elles peuvent contenir plus d'attributs qu'il n'est nécessaire pour identifier de manière unique une entité. Il est souhaitable de travailler avec des super-clés qui ne présentent pas cette caractéristique. Une super-clé ayant la propriété telle qu'aucun de ses sous-ensemble n'est une super-clé, est appelée une clé. Ainsi, une clé est une super-clé qui, si l'on enlève un attribut, présente un jeu d'entités qui ne peut plus être une super-clé. En termes concis, une clé est une super-clé minimaliste. Les clés sont appelées parfois des clés candidates, car il arrive souvent que nous voulions sélectionner une clé particulière pour servir d'identifiant. La référence à ce choix particulier est appelée une clé primaire. Les clés primaires dans la base de données LIBRARY sont ISBN, AuID et PubID. Remarquons qu'une clé peut contenir plus d'un attribut et que différentes clés peuvent avoir différents nombres d'attributs. Il est raisonnable de supposer, par exemple, que {NumeroSecuriteSociale} et {Nom,Adresse,DateNaissance} sont toutes deux des clés pour une classe d'entités Citoyens français.

31 18 Chapitre 2: Modèle relationnel dune base de données Relations entre entites Si nous voulons représenter une base de données comme une collection de jeux d' entités (tables), nous devons décrire également les relations existant entre ces jeux. Par exemple, il existe une relation entre un livre et les auteurs qui ont écrit ce livre. Nous pouvons appeler cette relation EcritPar. Ainsi, Hamlet est EcritPar Shakespeare. On peut dessiner un diagramme appelé diagramme entité-relation ou diagramme E/R pour illustrer les classes d'entités, leurs attributs et leurs relations dans un modèle de bases de données. Figure 2-1. Diagramme des dations de la base LIBRARY

32 Relations entre entités 19 La figure 2-1 montre le diagramme LIBRARY E/R avec une classe d'entités supplémentaire appelée Contributeurs (un contributeur peut être quelqu'un qui collabore à un livre ou simplement écrit une petite portion de celui-ci, et qui, de ce fait, ne bénéficie pas de tous les droits attachés à la qualité d'auteur, tels que les droits d'auteur). Chaque classe d'entités est représentée par un rectangle et chaque attribut par une ellipse. Les relations sont symbolisées par des losanges. Nous avons inclus la classe d' entités Contributeurs dans ce modèle, simplement pour illustrer un type spécial de relations. En particulier, puisqu'un contributeur est assimilé à un auteur, il y a une relation EstUn entre les deux classes d'entités. Le modèle représenté par un diagramme E/R est parfois désigné comme modèle sémantique, car il décrit en grande partie la signification de la base de données. Types de relations En nous référant à la figure 2-1, nous remarquons que les symboles 1 et oo représentent le type de relations entre les classes d'entités correspondantes (le symbole 00 est lu «plusieurs»). Les relations peuvent être classifiées en trois types. Par exemple, la relation entre les Livres et les Auteurs est de type plusieurs-àplusieurs, ce qui signifie qu'un livre peut avoir plusieurs auteurs et un auteur peut écrire plusieurs livres. En outre, la relation d'editeurs à Livres est de type un-àplusieurs, ce qui signifie qu'un éditeur peut publier plusieurs livres, mais qu'un livre ne peut être publié que par un éditeur au plus (c'est du moins ce que nous admettrons). Les relations de type un-à-un où chaque entité d'un côté est reliée à au moins une entité de l'autre côté de la relation sont plutôt rares dans la conception des bases de données. Par exemple, considérons la relation Contributueur-Auteur, qui est du type unà-un. Nous pourrions remplacer la classe Contributeurs par un attribut contributeur de la classe auteurs, éliminant ainsi le besoin d'une classe séparée et d'une relation distincte. Par contre, si la classe Contributeurs avait plusieurs attributs qui ne sont pas partagés par la classe Auteurs, alors une classe séparée pourrait s'avérer justifiée. Au chapitre 3, Implémentation de modèles relationnels : base de données relationnelles, nous allons mettre en pratique le modèle relationnel complet de notre base de données LIBRARY.

33 Dans ce chapitre Implantation d'entités Un bref glossaire Introduction de relations dans une base de données relationnelles La base de données relationnelles LIBRARY Fichiers d'index Valeurs NULL La base de données relationnelles CATALOG Sur le CD-Rom Implantation de modèles relationnels : bases de données relationnelles Un modèle E/R de base de données est un modèle abstrait, visualisé à travers un diagramme E/R. Pour que ceci soit utile nous devons traduire le modèle abstrait en un modèle concret. Nous devons décrire chaque aspect du modèle en termes concrets qu'un programme de base de données peut manipuler. En bref, nous devons implanter le modèle E/R. Ceci requiert différentes choses Les entités Les classes d'entités Les jeux d'entités Les relations entre les classes d'entités Le résultat de cette implémentation est une base de données relationnelle. Comme nous le verrons, l'implémentation de relations implique habituellement des changements dans les classes d'entités, par addition de nouveaux attributs à des classes d'entités existantes ou par addition de nouvelles classes d'entités. Implantation d entités Comme nous l'avons vu au chapitre précédent, une entité est implémentée (ou décrite en termes concrets) simplement en attribuant des valeurs à ses attributs. Ainsi, ce qui suit est une implémentation de l'entité Livres Titre = Gone With The Wind ISBN = Prix = $

34 22 Chapitre 3 : Implantation de modèles relationnels : bases de données relationnelles Implantation de classes d'entités - modèles de tables Puisque les éléments d'une classe d'entités sont implantés par assignation de valeurs aux attributs, il est raisonnable d'implanter une classe d'entités par le jeu des noms d' attributs. Par exemple, la classe d'entités Livres peut être identifiée par le jeu {ISBN,Titre,Prix} Nous ajouterons l'attribut PubID ultérieurement, lorsque nous implanterons les relations. Comme les noms d'attributs sont utilisés habituellement comme en-tête de colonne dans une table, un jeu de noms d'attributs est appelé un schéma de table. Les classes d'entités sont implantées comme des schémas de table. Par convenance, nous utiliserons la notation suivante Livres{ISBN, Titre, Prix} qui montre non seulement le nom de la classe d'entités mais également les noms d'attributs dans le schéma de table correspondant. Vous pouvez également imaginer un schéma de table comme la rangée supérieure des en-têtes de colonnes dans toute table formée à partir d'un schéma de table (nous allons en voir un exemple dans quelques instants). Nous avons défini les concepts de super-clé et de clé pour des classes d'entités. Ces concepts s'appliquent également aux schémas de table, de sorte que nous pouvons dire que les attributs {A,B} forment une clé pour un schéma de table, ce qui veut dire qu'il forment une clé pour la classe d'entités implémentée à l'aide de ce schéma de table. Implantation de jeux d'entités -tables Dans une base de données relationnelles, chaque jeu d'entités est configuré par une table. Par exemple, considérons la table LIVRES, illustrée à la table 3-1, que nous notons comme suit La première rangée de la table est le schéma de table pour la classe d'entités Livres. Chacune des autres lignes de la table implémente une entité livre.

35 Implantation d'entités 23 Le jeu de toutes les lignes de la table, excepté la première rangée, correspond au jeu d'entités lui-même. Table 3-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 De façon plus formelle, une table T est un tableau rectangulaire d'éléments possédant les propriétés suivantes 1. Le sommet de chaque colonne est libellé avec un nom d'attribut Ai. L'étiquette Ai est appelée également en-tête de colonne. 2. Les éléments de la nième colonne de la table T proviennent d'un seul jeu Di, appelé le domaine pour la nième colonne. Ainsi, le domaine est le jeu de toutes les valeurs possibles de l'attribut. Par exemple, pour la table LIVRES, illustrée à la table 3-1, le domaine Di est le jeu de tous les numéros ISBN possibles et le domaine D2 est le jeu de tous les titres d'ouvrages possibles. 3. Il n'y a pas deux lignes de la table qui soient identiques. Faisons quelques remarques à propos du schéma de table. Une table peut avoir un nom (mais ceci n'est pas obligatoire), tel que LIVRES, dont le rôle est de véhiculer la signification de la table en tant que telle. Le nombre de lignes de la table est appelé la taille de la table et le nombre de colonne est appelé le degré de la table. Par exemple, la table LIVRES illustrée à

36 24 Chapitre 3 : Implantation de modèles relationnels : bases de données relationnelles la table 3-1 a une taille de 14 et un degré de 3. Les noms d'attributs sont ISBN, Titre et Prix. Comme nous l'avons mentionné plus haut, pour souligner les attributs d'une table, il est commode de noter une table en écrivant T(A1...An); par exemple, nous notons la table LIVRES à l'aide de : LIVRES {ISBN,Titre,Prix} L'ordre des lignes d'une table n'est pas important et deux tables qui diffèrent uniquement par l'ordre de leurs lignes sont réputées être une seule et même table. De manière similaire, l'ordre des colonnes d'une table n'est pas important aussi longtemps qu'un en-tête est considéré comme faisant partie de sa colonne. En d'autres termes, nous sommes libres de réorganiser les colonnes d'une table, à condition de conserver les en-têtes en regard de leur colonne respective. Finalement, il n'est pas requis que les domaines de différentes colonnes soient différents. Par exemple, il est possible que deux colonnes dans une seule table puissent utiliser simultanément le domaine des entiers. Cependant il est exigé que les noms d'attributs de différentes colonnes soient différents. Imaginez la confusion potentielle qui surviendrait en pareil cas dans la perspective d'une réorganisation des colonnes de la table Maintenant que nous avons défini le concept de table, nous pouvons dire qu'il est commode de définir une bases de données relationnelle comme une collection finie de tables. Cependant, cette définition repose sur le fait que les tables modèlent également les relations entre les classes d'entités, comme nous le verrons. Un court glossaire Afin de garder présent à l'esprit les différents termes utilisés pour les bases de données, nous avons rassemblé leur définition ci-dessous Entité Un objet dont la base de données est conçue pour stocker de l'information le décrivant. Exemple : un livre ; c'est-à-dire, un numéro ISBN, un titre et un prix comme dans Attribut , On Liberty, $25.00 Une propriété décrivant (partiellement ou complètement) une entité. Exemple : titre. Classe d'entités

37 Un court glossaire 25 Un groupe d'entités abstrait, possédant une description commune. Exemple : la classe d'entités livres, représentant tous les livres de l'univers. Jeu d'entités Le jeu des entités provenant d'une classe d'entités donnée se trouvant actuellement dans la base de données. Exemple : le jeu suivant de quatorze livres , On Liberty, $ , Iliad, $ , Faerie Queene, $ , Emma, $ , Visual Basic, $ , C++, $ , Hamlet, $ , Macbeth, $ , King Lear, $ , Ulysses, $ , Jane Eyre, $ , Moby Dick, $ , Balloon, $ , Main Street, $22.95 Super-clé Un jeu d'attributs pour une classe d'entités qui sert à identifier de manière unique une entité prise parmi toutes les entités possibles dans la classe d'entité considérée. Exemple : le jeu {Titre, ISBN} pour la classe d'entités livres. Clé Une super-clé minimale ; c'est-à-dire, une clé ayant comme propriété résultante de n' être plus une super-clé, lorsqu'on enlève un attribut. Exemple : le jeu {ISBN} pour la classe d'entité livres. Table Un tableau rectangulaire contenant des valeurs d'attributs, dont les colonnes contiennent les valeurs pour un attribut donné et dont les lignes contiennent les valeurs d'attribut pour une entité donnée. Les tables sont utilisées pour implanter des jeux d'entités. Exemple : la table LIVRES illustrée plus haut à la table 3-1. Schéma de table

38 26 Chapitre 3 : Implantation de modèles relationnels : bases de données relationnelles Le jeu de tous les noms d'attributs pour une classe d'entités. Exemple {ISBN, Titre, Prix} Puisqu'il s'agit du modèle de table pour la classe d'entités Livres, nous pouvons utiliser la notation Livres{ISBN, Titre, Prix} Base de données relationnelle Une collection finie de tables qui fournissent une implémentation d'un modèle de base de données relationnelle. Implantation de relations dans une base de données relationnelle Maintenant envisageons la manière dont nous pouvons implanter les relations dans un modèle de base de données relationnelle. Par convenance, nous répétons le diagramme E/R pour la base de données LIBRARY à la figure 3-1. Implanter une relation un-à plusieurs - clés étrangères Il est relativement simple d'implanter une relation un-à-plusieurs, telle que la relation EditeurDe. Comme {PubID} est une clé pour la classe d'entités Editeurs, nous n' avons pas ajouté cet attribut à la classe d'identités Livres. Ainsi, la classe d'entités livres devient Livres(ISBN,Titre, PubID,Prix) Le schéma de table livres est maintenant {ISBN,Titre,PubID,Prix}

39 Implantation de relations dans une base de données relationnelle 27 Figure 3-1. Diagramme relationnel LIBRA KY et la table LIVRES apparaît à la table 3-2 (triée par PubID). Table 3-2. Table LIVRES triée par PubID ISBN Titre PubID Prix On Liberty - I Iliad 1 $ Faerie Queene 1 $ Emma 1 $ Visual Basic 1 $ C++ 1 $ Hamlet 2 $ Macbeth 2 $12.00

40 28 Chapitre 3 : Implantation de modèles relationnels : bases de données relationnelles Table 3-2. Table LIVRES triée par PubID (suite) ISBN Titre PubiD Prix King Lear 2 $ Ulysses 2 $ Jane Eyre 3 $ Moby Dick 3 $ Balloon 3 $ Main Street 3 $22.95 L'attribut PubID dans la classe d'entités Livres est désigné comme une clé étrangère, car c'est une clé pour une classe d'entités étrangère; c'est-à-dire, pour la classe d'entité Editeurs. Notons que la valeur de la clé étrangère PubID dans la table LIVRES fournit une référence à la valeur correspondante dans la table EDITEURS. Comme {PubID} est une clé pour la classe d'entités Editeurs, il y a au plus une rangée d'éditeurs qui contient une valeur donnée. Ainsi, pour chaque entité, nous pouvons relier la valeur PubID dans la table EDITEURS pour obtenir le nom de l'éditeur de ce livre. De cette façon, nous avons établi la relation de type un-à-plusieurs EditeurDe. L'idée que nous venons de décrire est retracée de manière plus générale à la figure 3-2. Supposons qu'il existe une relation de type un-à-plusieurs entre les classes d'entités ( ou, de façon équivalente, entre les schémas de table) S et T. La figure 3-2 montre deux tables S et T basées sur ces schémas de table. Supposons par ailleurs que {A2} est une clé pour le schéma de table S (l'un des côtés de la relation). Nous ajoutons alors cet attribut au schéma de table T (et de ce fait à la table T). De cette manière, pour toute rangée de la table T, nous pouvons identifier la rangée unique de la table S qui lui est liée. Le jeu d'attributs {A2} dans la table S est une clef pour le schéma de table S. En conséquence, le jeu d'attributs {A2} est également appelé une clé étrangère pour le schéma de table T. Plus généralement, un jeu d'attributs appartenant au schéma de table T est une clé étrangère pour T s'il est une clé pour un autre schéma de table S. Notons qu'une clé étrangère pour T n'est pas une clé pour T- c'est une clé pour un autre schéma de table. Ainsi, le jeu d'attributs {PubID} est une clé pour Editeurs, mais une clé étrangère pour Livres. Comme le montre notre exemple, une clé étrangère fournit une référence à la classe d'entités (schéma de table) pour laquelle elle est une clé. Le schéma de table T est appelé le schéma de table référant et les schéma de table S est appelé le schéma de table de

41 Implantation de relations dans une base de données relationnelle Figure 3-2. Relation de type un-à plusieurs illustrée dans les tables S et T référence. La clé qui est référencée dans le schéma de table de référence est appelée la clé de référence. Notons que l'addition d'une clé étrangère à un schéma de table crée une duplication de valeurs dans la base de données, mais ajoute une information complémentaire, nécessaire à la description de relations. Implanter une relation de type un-à-un Naturellement, la procédure d'introduction d'une clé étrangère dans un schéma de table fonctionne aussi bien pour des relations de type un-à-un que pour des relations de type un-à-plusieurs. Par exemple, il nous suffit de renommer l'attribut ConID en AuID pour faire de ConID une clé étrangère qui introduit la relation EstUn entre auteurs-contributeurs. Implémenter une relation de type plusieurs-à plusieurs-nouvelles classes d'entités L'implémentation d'une relation de type plusieurs-à-plusieurs est un peu plus compliquée. Considérons par exemple la relation EcritPar entre livres et Auteurs. Au premier coup d'ceil, nous pourrions imaginer d'ajouter simplement des clés étrangères à chaque schéma de table, considérant la relation comme un ensemble de deux relations distinctes de type un-à-plusieurs. Cependant, cette approche n'est pas bonne, car elle oblige à dupliquer des lignes de la table. Par exemple, si nous

42 30 Chapitre 3 : Implantation de modèles relationnels : bases de données relationnelles voulons ajouter l'isbn au schéma de table Auteurs et la clef AuID au schéma de table L ivres, chaque livre écrit par deux auteurs doit être représenté par deux enregistrements dans la table LIVRES, et ainsi nous pouvons avoir deux AuID. Concrètement, comme le livre Main Street est écrit par Smith and Jones, nous aurions besoin de deux lignes dans la table LIVRES Titre: Main Street, ISBN , Prix: $22.95 AuID: Smith Titre: Main Street, ISBN , Prix: $22.95 AuID: Jones Il est clair que cette approche va encombrer la base de données d'informations redondantes. L'approche correcte pour établir une relation de type plusieurs-à-plusieurs est d' ajouter un nouveau schéma de table à la base de données, de manière à scinder la relation en deux relations de type un-à-plusieurs. Dans notre cas, nous ajoutons un schéma de table à Livre/Auteur, dont les attributs sont constituées précisément des clés étrangères ISBN et AuID : Livre/Auteur(I SBN,AuI D) Une vue graphique de cette procédure est fournie par la figure 3-3 affichant le diagramme E/R correspondant. Notons qu'il n'est pas habituel d'inclure ceci comme portion du diagramme E/R originel, car il relève davantage de la phase de conception que de la réalisation. Figure 3-3. Relation de type plusieurs-àplusieurs dans la table LIVRE/AUTEUR

43 Implantation de relations dans une base de données relationnelle 31 Intégrité référentielle Certaines considérations importantes doivent être abordées au regard de l'utilisation de clés étrangères pour implanter des relations. En premier lieu, il y a le fait que chaque valeur de la clé étrangère doit avoir une valeur correspondante dans la clé de référence. Autrement, nous aurions une référence dite boiteuse. Par exemple, si la clé PubID dans la table LIVRES n'avait pas de valeur correspondante dans la clé PubID de la table EDITEURS, nous aurions un livre dont les éditeurs n'existent pas dans la base de données; c'est-à-dire, une référence boiteuse à un éditeur inexistant. L'obligation que chaque valeur de la clé étrangère soit une valeur de la clé de référence est appelée la contrainte référentielle. Le nécessité de s'assurer qu'il n'y a pas de références boiteuses revient à veiller à l'intégrité référentielle. Il y a plusieurs manières de trouver un compromis concernant l'intégrité référentielle. Tout d'abord, nous pouvons ajouter une valeur à la clé étrangère qui n'est pas présente dans la clé de référence. Ceci surviendrait, par exemple, si nous ajoutions un nouveau livre à la table LIVRES, dont l'éditeur n'est pas listé dans la table des ÉDITEURS. Une telle action sera rejetée par une application de base de données qui a été programmée pour garantir l'intégrité référentielle. Une manière plus subtile d'affecter l'intégrité référentielle consiste à modifier ou à effacer une valeur dans la clé de référence-celle qui est référencée par la clé étrangère. Ceci survient, par exemple, si nous effaçons un éditeur de la table des ÉDITEURS alors que cet éditeur à au moins un livre dans la table LIVRES. Naturellement, le programme d'application peut simplement interdire une telle modification ou suppression, mais il existe parfois une option préférable que nous allons aborder maintenant. Mises à jour et suppressions en cascade De nombreux programmes de bases de données permettent les mises a Jour en cascade. Ceci signifie simplement que si une valeur est modifiée dans la clé de référence, alors toutes les entrées correspondantes dans la clé étrangère seront modifiées automatiquement pour correspondre à la nouvelle valeur. Si des mises à jour en cascade sont activées, la modification de PubID d'un éditeur dans la table des EDITEURS, par exemple de 100 à 101, entraînera automatiquement le passage à 101 de toutes les valeurs 100 de PubID de la clé étrangère de la table de référence LIVRES. En bref, les mises à jour en-cascade mettent chaque chose en synchronisation.

44 32 Chapitre 3 : Implantation de modèles relationnels : bases de données relationnelles De façon similaire, les suppressions en cascade signifient que si une valeur de la table de référence est supprimée par suppression de la ligne correspondante dans cette table, alors toutes les lignes de la table référante liées à la valeur supprimée seront aussi effacées! Ainsi, si nous effaçons un éditeur de la table EDITEURS, toutes les entrées de livres se référant à cet éditeur (par son PubID) seront effacées automatiquement de la table LIVRES. Les suppressions en cascade préservent également l'intégrité référentielle, au prix peut-être de suppressions massives dans d'autres tables. En conséquence, les suppressions en cascade doivent être utilisées avec prudence. Comme vous le savez peut-être, Microsoft Access permet à l'utilisateur d'activer ou de désactiver à la fois les mises à jour et les suppressions en cascade. Nous examinerons plus tard comment procéder. La base de données relationnelle LIBRARY Nous pouvons à présent achever l'implémentation de la base de données relation nelles LIBRARY (sans la classe d'entités Contributeurs) dans Microsoft Access. Si vous ouvrez la base LIBRARY, vous apercevrez quatre tables AUTEURS LIVRE/AUTEUR LIVRES EDITEURS La table unique de LIBRARY n'est pas utilisée dans la base de données relationnelle. Ces quatre tables correspondent aux quatre classes d'entités suivantes (ou schémas de table) Auteurs (AulD,AuNom,AuPhone) Livre/Auteur(ISBN,AuID) Livres(ISBN,Titre,PubID,Prix) Editeurs(PubID, PubNom, PubPhone)

45 La base de données relationnelle LIBRARY 33 Les tables sont illustrées aux tables 3-3 à 3-6. Table 3-3. Table AUl E URS extraite de la base Access LIBRARY AulD AuNom AuPhone 1 Austen Jones Snoopy Grumpy Sleepy Melville Homer Roman Shakespeare Joyce Spenser Mill Smith Table 3-4. Table LIVRE/AUTEUR extraite de la base LIBRARY ISBN AuID

46 34 Chapitre 3 : Implantation de modèles relationnels : bases de données relationnelles Table 3-5. Table LIVRES extraite de la base LIBRARY ISBN Titre PubiD Prix On Liberty 1 $ Iliad 1 $ Faerie Queene 1 $ Emma $ Visual Basic 1 $ C++ 1 $ Hamlet 2 $ Macbeth 2 $ King Lear 2 $ Ulysses 2 $ Jane Eyre 3 $ Moby Dick 3 $ Balloon 3 $ Main Street 3 $22.95 Table 3-6. Table EDITE URS extraite de la base LIBRARY PublD PubNom PubPhone 1 Big House Alpha Press Small House Notez que nous avons inclus la clé étrangère nécessaire {PubID} dans la table LIVRES à la table 3-5, pour établir la relation EditeurDe, qui est de type un-àplusieurs. Nous avons inclus également la table LIVRE/AUTEUR (table 3-4) pour implanter la relation EcritPar, qui est de type plusieurs-à-plusieurs. Même si toutes les relations sont établies à l'aide de clés étrangères, nous devons avertir Acces que ces clés étrangères sont utilisées pour établir les relations. En voici les étapes. Paramétrage des relations dans Access 1. Afin d'illustrer un point particulier, effectuez le petit changement suivant dans la table LIVRES : ouvrez la table et modifiez le champ PubID pour Hamlet et

47 La base de données relationnelle LIBRARY 35 écrivez 4. Remarquez qu'il n'y a aucun éditeur avec PubID 4 et ainsi nous avons créé une référence boiteuse. Fermez la fenêtre LIVRES 2. Choisissez Relations à partir du menu Outils. Vous devriez obtenir une fenêtre montrant les schémas de table de la base de données, similaires à ce que montre la figure 3-4. Les relations sont figurées par des lignes entre ces schémas de table. Comme vous pouvez le voir, il n'y a pour l'instant pas de relations. Notez que les attributs des clés primaires apparaissent en gras. Figure 3-4. Vue des schémas de tables de la base LIBRARY avant définition de relations 3. Pour établir des relations entre ÉDITEURS et LIVRES, placez le pointeur de la souris sur le nom d'attribut PubID du modèle de table ÉDITEURS, maintenez enfoncé le bouton gauche de la souris et glissez le nom d'attribut PubID dans le modèle de table LIVRES. Vous devriez obtenir une fenêtre similaire à celle de la figure 3-5. Figure 3-5. Relations entre les tables EDITEURS et LIVRES 4. Cette fenêtre montre la relation entre EDITEURS et LIVRES, listant la clé { PubID} dans Editeurs et la clé étrangère {PubID} dans Livres. Nous n'avions

48 36 Chapitre 3 : Implantation de modèles relationnels: bases de données relationnelles pas besoin d'appeler la clé étrangère PubID, mais il est raisonnable de le faire, car elle nous rappelle le rôle de l'attribut. 5. Maintenant, considérez la boîte de dialogue Intégrité Référentielle et cliquez sur le bouton Créer. Vous devez obtenir le message de la figure 3-6. Le problème est naturellement celui de la référence boiteuse que nous avons créée en changeant le champ PubID dans la table LIVRES qui se réfère à un éditeur non existant. Figure 3-6. Message d'erreur lors de références boiteuses 6. Cliquez sur le bouton OK, ouvrez de nouveau la table LIVRES et corrigez l' entrée inexacte (modifiez le champ PubID de Hamlet en ramenant sa valeur à 2). Fermez la table et établissez de nouveau les relations entre EDITEURS et LIVRES. Cochez cette fois l'option sur l'application de l'intégrité référentielle et celle sur les mises à jour des champs en cascade. 7. Ensuite, glissez le nom de l'attribut ISBN du schéma de table LIVRES sur le nom d'attribut ISBN dans le schéma de table LIVRE/AUTEUR. Vérifiez à nouveau les cases à cocher des options Appliquer l'intégrité référentielle et Mise à jour des champs en cascade. 8. Finalement, glissez le nom d'attribut AuID du schéma de table AUTEURS sur le nom d'attribut AuID du schéma de table LIVRE/AUTEUR. Cochez les cases des options Appliquer l'intégrité référentielle et Mettre à jour en cascade les champs correspondants. Vous devriez maintenant voir les lignes indiquant ces relations, telles que les montre la figure 3-7. Notez que la présence des petits 1 et du signe infini, indiquent le type de relation de chaque côté de la liaison.

49 Fichiers d'index 37 Figure 3-7. Vue des relations entre différentes tables 9. Pour tester l'application de l'intégrité référentielle, essayez l'expérience suivante : ouvrez les tables LIVRES et EDITEURS-et placez-les de manière à les voir simultanément à l'écran. Ensuite, modifiez les valeurs de PubID pour Small House de la table EDITEURS de 3 à 4. Dès que vous déplacez le curseur en dehors de la ligne Small House (ce qui opère le changement permanent), les valeurs PubID correspondantes dans LIVRES devraient changer automatiquement! Quand vous avez terminé, restaurez la valeur de PubID à 3 dans EDITEURS. Fichiers d'index Une table est sauvegardée sur le disque dans un fichier. Dans ce cas, chaque rangée de la table est un enregistrement et chaque colonne est appelée un champ (ces termes sont fréquemment utilisés pour tout type de table.) Comme les accès disque sont lents, un objectif important est de réduire le nombre d' accès disque nécessaires pour retrouver les données désirées à partir d'un fichier. La recherche séquentielle des données, enregistrement par enregistrement, peut nécessiter un grand nombre d'accès disque et est peu efficace. Le but d'un fichier d'index est de fournir un accès direct aux données dans un fichier de base de données. La figure 3-8 illustre le concept d'un fichier d'index. Nous avons modifié les données dans Editeurs pour les besoins de la démonstration et inclus une colonne Ville. Le fichier à gauche est le fichier index; il indexe le fichier de données Editeurs par le champ Ville, qui pour cette raison est appelé le champ d' indexation. Le fichier ville est appelé l'index de la table Editeurs. Le fichier index n'est pas une table au sens où la table Editeurs est une table. Nous ne pouvons accéder directement au fichier index-(au contraire, nous l'utilisons indirectement). Le fichier index

50 38 Chapitre 3 : Implantation de modèles relationnels : bases de données relationnelles contient les villes pour chaque éditeur avec des pointeurs vers les enregistrements correspondants du fichier Editeurs Figure 3-8. Index entre Ville et Editeur Un fichier d'index peut être utilisé de différentes manières. Par exemple, pour trouver tous les éditeurs situés à Kansas City, Access peut en premier rechercher dans la liste alphabétique des villes de l'index. Comme la liste est dans l'ordre alphabétique, Access sait que les entrées de Kansas City sont regroupées, de sorte que lorsqu'il atteint la première entrée après Kansas City, il peut stopper la recherche. En d'autres termes, Access n'a pas besoin de parcourir l'ensemble de l'index (du reste, il existe des algorithmes de recherche très efficaces pour les tables ordonnées). Lorsque les entrées de Kansas City sont trouvées dans l'index, les pointeurs sont utilisés pour aller directement aux données sur les éditeurs du fichier indexé. Comme l'index fournit une vue triée des données de la table d'origine, il peut être utilisé pour retrouver de manière efficace des séries d'enregistrements. Par exemple, si les données sur les livres sont indexées sur le prix, on peut retrouver rapidement tous les livres dont le prix se situe entre $20.00 et $ Une table peut être indexée sur plusieurs colonnes; autrement dit, une table peut avoir plus d'un index. Ainsi, une table peut être indexée sur une combinaison de deux colonnes ou davantage. Par exemple, si la table EDITEURS avait inclus une colonne Etat, nous pourrions indexer la table sur une combinaison de Ville et Etat, comme le montre la figure 3-9. Un index sur une clé primaire est appelé index primaire. Microsoft Access crée automatiquement un index sur une clé primaire. Un autre index sur toute autre colonne est appelé index secondaire. Un index basé sur une clé (pas nécessairement la clé primaire) est appelé index unique, car la colonne indexée contient des valeurs uniques.

51 Fichiers d'index 51 Figure 3-9. Index entre Ville, Etat et Editeur Exemple Pour voir les index d'une table donnée de Microsoft Access, ouvrez la table dans le mode conception et choisissez Index depuis le menu Vues. Pour la table LIVRES, vous devriez voir une fenêtre similaire à celle illustrée à la figure 3-10 (sans l'entrée PubTitre). Figure Vue des index de la table LIVRES Pour ajouter un index basé sur plus d'un attribut, vous devez entrer les divers attributs sur les lignes successives de la boite de dialogue Index. Ceci a été fait à la figure 3-10, en ajoutant un index PubTitre basé sur les attributs PubID et Titre. Cet index effectue l'indexation des entités LIVRES d'abord par PubID et ensuite par Titre (à l' intérieur de chaque PubID).

52 52 Chapitre 3 : Implantation de modèles relationnels : bases de données relationnelles La question des valeurs NULL peut engendrer la confusion dans l'esprit d'un utilisateur de bases de données. Aussi, tentons de poser les principes de base. D'une manière générale, NULL représente une valeur spéciale qui est utilisée pour deux raisons Indiquer qu'une valeur est manquante ou inconnue Indiquer qu'une valeur n'est pas applicable dans le contexte courant Par exemple, considérons la table des auteurs AUTEURS(AuID,AuNom,AuPhone) Si le numéro de téléphone d'un auteur est inconnu, il est approprié d'attribuer une valeur NULL à cette donnée. Ceci ne veut pas dire que l'auteur n'a pas de téléphone, mais que nous n'avons pas d'information sur son numéro-qu'il existe ou non. Si nous savions que l'auteur n'a pas de numéro de téléphone, l'information ne serait pas dès lors inconnue. Dans ce cas, la valeur appropriée de l'attribut AuPhone serait une chaîne vide ou peut-être la chaîne "pas de téléphone", mais pas un NULL. On voit ainsi que l'attribution d'une valeur NULL dépend du contexte. Le problème de savoir si des valeurs NULL doivent apparaître dans une clé mérite discussion. Le but d'une clé est de fournir un moyen d'identification unique des entités. Il pourrait sembler que les clés et les NULL sont incompatibles. Cependant, il est peu pratique d'interdire les valeurs NULL dans les clés. Si l'on considère l' entité Editeurs, par exemple, ceci signifierait qu'un champ PubPhone ne pourrait recevoir un NULL, puisque {PubNom, PubPhone} est une clé. Par ailleurs, la règle dite d'intégrité des entités interdit les NULL dans une clé primaire. Une remarque pour finir : la présence de NULL comme valeur d'une clé étrangère ne viole pas l'intégrité référentielle. L'intégrité référentielle requiert que chaque valeur non-null dans une clé étrangère ait une correspondance dans la clé référencée. La base de données relationnelle CATALOG La base de données CATALOG, calquée sur la base LIBRARY, comporte les mêmes classes d'entités de base AUTEURS LIVRES

53 Sur le CD-Rom 41 EDITEURS LIVRE/AUTEUR Il s'y ajoute deux autres entités PRODUITS REVENDEURS La classe d'entités PRODUITS contient les informations relatives à la production des livres tandis que la classe REVENDEURS fait référence à tous les intervenants dans la distribution d'un livre (distributeurs, revendeurs, libraires,etc.). Si vous ouvrez la base CATALOG dans Microsoft Access, vous apercevrez six tables correspondant aux schémas de tables suivants Auteurs (AulD,AuNom,AuPhone) Livre/Auteur(ISBN,AuID) Livres (ISBN,Titre,PubID,Prix,Date,Nbpages) Editeurs(PubID, PubNom, PubPhone) Produits(ISBN,NbPages,Format,Cover,Papier,PrixRev,EdiNom) Revendeurs(RevID,RevNom,RevPhone,PubID) Comme on peut le constater, le nombre des champs de chaque schéma de table a été augmenté pour tenir compte de la réalité. D'une manière générale, les exemples relatifs à la base LIBRARY s'appliquent à la base CATALOG. Sur le CD-Rom Vous trouverez les différents exemples de ce chapitre répartis entre plusieurs documents. Pour les consulter, lancez le document d'orientation placé dans : /exemples/ chap03/ chapo3. htm. La structure d'exposition des exemples et des exercices suit la structure du chapitre et est partagée en trois thèmes Implantation de jeux d'entités Implantation de relations de type un-à-plusieurs, un-à-un, etc. Définition d'index

54 42 Chapitre 3 : Implantation de modèles relationnels : bases de données relationnelles Quant à elle, la base de données CATALOG est accessible dans le répertoire Applis, fichier catalog.mdb. Pour des raisons pédagogiques, cette base respecte la structure générale de la base LIBRARY. Elle s'en distingue cependant sur un point : les quelques 250 enregistrements de la table LIVRES comportent un lien hypertexte vers la description des ouvrages, qu'elle se trouve sur le CD-Rom ou sur Internet. On utilise ainsi une puissante fonctionnalité d'access 97 qui permet de gérer des liens hypertexte dans des champs de table. La visualisation des documents se fait à l'aide de votre navigateur Web, qui doit être défini par défaut dans Windows 95. La base CATALOG doit être ouverte à la table LIVRES : en cliquant une première fois sur un lien dans la table, Access lance le navigateur qui affiche directement le document correspondant. Par la suite l'affichage est plus rapide, le navigateur étant ouvert. Les fonctionnalités de navigation du navigateur sont inchangées : en suivant les liens hypertexte, la navigation dans la base des documents est possible; on revient dans Accesss par l'historique ou en cliquant sur la touche Back du navigateur. On notera que la description des ouvrages étant au format HTML, la navigation dans la base des documents est possible en dehors d'access (lancer dans ce cas les fichiers Index.html qui se trouvent dans les répertoires catalogfr, catalog.de et catalog.us). Lors des opérations de recherche, de tri ou d'extraction de données, les champs hypertexte se manipulent comme les champs ordinaires. Comme vous pourrez le constater, ou l'expérimenter, il est possible de les inclure dans les diverses opérations sur les tables ou dans les requêtes. Ceci rend plus facile la surveillance ou la gestion d'un site Web local ou distant, la gestion d'une base documentaire (documents html, doc, txt, pdf, etc.), d'un catalogue de produits, de références, d'images qui peuvent être répartis, le cas échéant, entre différentes machines ou différents sites.

55 Dans ce chapitre Redondances Formes normales Première forme normale Dépendances fonctionnelles Seconde forme normale Troisième forme normale Forme normale de Boyce Codd Normalisation Sur le CD-Rom 4 Principes de conception des bases de données Au chapitre 1, Introduction, nous avons essayé de présenter dans une étude de cas des arguments selon lesquels la plupart des bases de données devraient être conçues comme des bases de- données relationnelles, plutôt que comme des bases de données plates. Nous avons essayé également de rendre claire la raison pour laquelle nous avons éclaté la table LIBRARY FLAT en quatre tables séparées AUTEURS, LIVRES, EDITEURS et LIVRE/AUTEUR. Cependant, pour les bases de données de grande taille de la vie pratique, il n'est pas toujours aisé de répartir les données entre des tables multiples. Comme nous l'avons mentionné au chapitre 1, le but poursuivi est de diminuer les redondances sans perdre d'information. La conception de bases de données efficaces est un problème complexe. La plupart des gens considèrent même que c'est un art plutôt qu'une science. Ceci signifie que l'intuition joue un rôle majeur lors de la conception. Néanmoins, les théories sur la conception des bases de données sont nombreuses, ce qui ne facilite pas les choses. Notre but dans ce chapitre est d'aborder les idées générales, sans se laisser entraîner dans les détails. Cet exposé servira, nous l'espérons, de guide pratique à l'intuition nécessaire dans la conception d'une base de données. Redondances Comme nous l'avons vu au chapitre 1, les redondances augmentent la taille d'une base de données, un problème très sérieux lorsque il s'agit de bases de grande taille ou même de taille moyenne. Les redondances peuvent conduire à des anomalies de différents types, ainsi que nous l'avons exposé précédemment. Pour comprendre les 43

56 44 Chapitre 4: Principes de conception des bases de données problèmes qui peuvent surgir en raison de redondances nous devons mieux définir ce mot. Commençons par observer que les attributs d'un schéma de table peuvent être classés en trois groupes 1. Attributs utilisés strictement pour des buts d'identification 2. Attributs utilisés strictement pour des buts d'information 3. Attributs utilisés à la fois pour des buts d'identification et d'information Par exemple, considérons le schéma de table suivant {PubID,PubNom,PubPhone,AnCreation} Dans ce schéma, PubID est utilisé strictement pour des buts d'identification. Il ne véhicule pas de contenu informatif. Par ailleurs, l'attribut AnCreation est strictement utilisé pour des buts d'information dans le contexte. Il indique l'année de fondation de la maison d'édition, mais il n'est pas nécessaire pour des buts d' identification. Considérons également le schéma de table suivant {Titre, PubID,AuID,NbPages,DateCopyright} Dans ce cas, si nous supposons qu'il n'y a qu'un livre ayant un titre donné, publié par un éditeur donné et écrit par un auteur donné, alors {Titre,PubID,AuID} est une clé. En conséquence, chacun des attributs est utilisé (au moins en partie) pour l' identification. Cependant, Titre est également un attribut informatif. Ceci dit, nous nous empressons d'ajouter que ces classifications sont dans une certaine mesure subjectives, et qu'elles dépendent des hypothèses qui sont faites à propos des classes d'entités. Néanmoins, le processus de classification apporte un cadre utile à l'intuition. Nous pouvons cerner plus précisément les attributs informatifs au sens strict en faisant l'observation suivante. Le signe qu'un attribut est utilisé (au moins en partie) à des buts d'identification est qu'il fait partie d'une clé. Ainsi, un attribut qui ne fait partie d'aucune clé est utilisé, dans ce schéma de table, uniquement pour des buts d' information. Appelons cet attribut un attribut strictement informatif. Maintenant, considérons la table 4-1. Dans ce cas, Titre et PubNom sont strictement informatifs, car {ISBN} est la clé unique et, ni Titre ni PubNom n' appartiennent à cette clé. Les valeurs de l'attribut Titre ne sont pas redondantes (le fait qu'il y ait deux valeurs n'implique pas qu'il y ait redondance : chaque valeur

57 Redondances 45 peut être requise séparément), tandis que les valeurs de l'attribut PubNom sont redondantes. Table 4-1. Table avec deux attributs informatifs ISBN Titre PubID PubNom C++ 1 Big House Faerie Queene 1 Big House C++ 2 ABC Press La raison pour laquelle Titre n'est pas redondant est qu'il n'existe aucun moyen d' éliminer l'un de ces titres. Chaque livre doit avoir un titre qui doit être listé quelque part dans la base de données-un titre par numéro ISBN. En conséquence, les deux livres ayant comme titre C++ doivent apparaître conjointement dans la base. Par opposition, PubNom est redondant. On peut facilement l'admettre en constatant que le même attribut PubNom apparaît deux fois sans ajouter d'informations supplémentaires à la base. Abordons le sujet sous un autre angle et considérons la table 4-2 qui comporte deux cellules vides. Pouvez-vous remplir le champ titre de la dernière rangée? La réponse est non, à moins de téléphoner à l'éditeur pour obtenir le titre correspondant au numéro d'isbn. En d'autres termes, l'information est manquante. Inversement, vous pouvez remplir sans peine le champ PubNom qui est vide. Table 4-2. Table avec des cellules villes pour illustrer la dépendance des attributs ISBN Titre PubID PubNom Macbeth 1 Big House Hamlet ABC Press Le problème est tout simple. L'attribut Titre dépend uniquement de l'attribut ISBN et {ISBN} est une clé. Cela veut dire que Titre dépend uniquement d'une clé. De son côté, PubNom dépend complètement de PubID, qui n'est pas une clé pour ce schéma de table. Naturellement, PubNom dépend aussi de la clé {ISBN }, mais ceci n'est pas significatif. Nous venons ainsi d'examiner un cas où la redondance provient du fait qu'un attribut dépend d'un autre attribut qui n'est pas une clé. Armés de cette observation, nous pouvons poursuivre.

58 46 Chapitre 4: Principes de conception des bases de données Formes normales Lorsqu'on étudie la conception des bases de données, on observe que les schémas de tables peuvent posséder des caractéristiques particulières, appelées formes, propriétés ou contraintes, en vue de réaliser certains ojectifs tels que la réduction des redondances. Ces formes, désignées sous le terme de formes normales, sont au nombre de six et portent des noms inspirés Première forme normale (1NF) Deuxième forme normale (2NF) Troisième forme normale (3NF) Forme normale Boyce Codd (BCNF) Quatrième forme normale (4NF) Cinquième forme normale (5NF) Nous allons examiner de manière informelle les quatre premières de ces formes. Selon une hiérarchie descendante, chacune de ces formes a plus de poids que son prédécesseur. Ainsi, un schéma de table conforme à la troisième forme est aussi conforme à la seconde forme. Il est généralement souhaitable que les schémas de tables aient un haut degré de normalisation. Mais, comme nous le verrons dans ce chapitre, cela n'est pas aussi simple qu'il n'y paraît. Par exemple, si l'on exige que les schémas de tables soient à la forme BCNF, ceci peut provoquer, dans certains cas, une perte d'informations sur les différentes relations entre les schémas de table. En général, il est possible de manipuler les données pour se conformer à la forme de troisième niveau, mais cela peut entraîner beaucoup de travail sans que le jeu en vaille la chandelle! Le fait d'imposer à tous les schémas de table un certain degré de normalisation impose des compromis. Chaque situation individuelle (chaque base de données) doit être examinée pour elle-même. Il est impossible d'établir des règles générales qui s' appliquent à toutes les situations. Le processus de modification d'une base de données pour produire des schémas de table dans une forme normale s'appelle la normalisation. Première Forme normale La première forme normale est très simple. Un schéma de table est réputé être à la première forme normale si les valeurs de ses attributs sont indivisibles. Pour illustrer

59 Dépendances fonctionnelles 47 ceci, nous avons examiné au chapitre 1 la question de l'insertion des auteurs de livres dans un seul attribut, appelé Auteurs. Voici un exemple d'entité ISBN = Titre = Main Street Auteurs = Jones, H. and Smith, K. Editeur = Small House Du fait que le schéma de table dans ce cas autorise plus d'un nom d'auteur pour l' attribut Auteur, le schéma n'est donc pas à la première forme. En vérité, l'un des problèmes évidents posé par l'attribut Auteur et qu'il est impossible de trier les données par nom d'auteur individuel. Il est également plus difficile, par exemple, de préparer des étiquettes de mailing par auteur, etc. Les attributs qui autorisent uniquement des valeurs indivisibles sont dits attributs scalaires ou attributs atomiques. Par opposition, un attribut dont les valeurs peuvent être une liste d'items (une liste d'auteurs) est dit attribut structuré. Ainsi, un schéma de table est dans la première forme normale si tous ses attributs sont atomiques. Une bonne conception des bases de données requiert presque toujours que tous les attributs soient atomiques, de sorte que le schéma de table soit de la première forme normale. En général, les ajustements nécessaires pour garantir la conformité à la forme normale de premier degré sont faciles à effectuer et c'est une règle généralement admise que les schémas de table doivent être conformes à la première forme normale. Cependant comme avec les autres formes (à plus forte raison si l'on monte dans la hiérarchie) chaque situation doit être considérée par rapport à ellemême. Par exemple, un seul champ peut être imaginé pour recueillir l'adresse de rue, telle que 1333 Bessemer street. La séparation entre attributs distincts du nom de la rue et du numéro de la rue est une affaire de contexte. Autrement dit, que l'adresse de la rue soit atomique ou non dépend du contexte. S'il y a une raison de manipuler les numéros de rue indépendamment des noms de rues, il sera préférable de leur conférer un attribut. Dépendances fonctionnelles Avant de discuter des autres formes normales, nous devons aborder le concept de dépendance fonctionnelle, qui est utilisé pour définir ces formes normales. Ce concept est très simple et nous l'avons déjà utilisé auparavant. Nous avons remarqué, dans l' exemple du schéma de table Editeurs, que l'attribut PubNom dépend complètement de l'attribut PubID. Plus exactement, nous devrions dire que la valeur de l' attribut PubNom dépend complètement de la valeur de l'attribut PubID, mais le

60 48 Cha itre 4: Principes de conception des bases de données raccourci employé reste valable. Nous pouvons dire ainsi que la dépendance fonctionnelle de PubID par rapport à PubNom, écrite PubiD --- >PubNom vaut pour le schéma de table Editeurs. Ceci peut être lu ainsi : PubID détermine PubNom ou PubNom dépend de PubID. Plus généralement, supposons que {Al,... Ak} sont attributs d'un schéma de table et que {Bl,...,Bn} sont aussi attributs du même schéma de table. Il n'est pas exigé que les B soient différents des A. Les attributs B dépendent alors des attributs A; ceci s'écrit {A,,...,Ak} -> {B,,...,Bn} si les valeurs de Al,...,Ak déterminent complètement les valeurs Bl,...,Bn. L'intérêt principal réside lorsqu'il n'y a qu'un attribut à droite {A,,...,Ak} --- > {B} Par exemple, il est correct de dire que {PubNom,PubPhone} --- > {PubID} ce qui est une autre façon de dire qu'il n'y a qu'un éditeur associé à un nom et à un numéro de téléphone donnés. Il est très important de bien comprendre qu'une dépendance fonctionnelle signifie que les attributs sur la gauche déterminent complètement les attributs de droite, maintenant et dans le futur, quelles que soient les données complémentaires qui pourraient être ajoutées à la base de données. De même que le concept de clé se réfère à des classes d'entités (schéma de table) plutôt qu'à des jeux d'entités individuels (table), il en va de même de la dépendance fonctionnelle. Chaque schéma de table a son jeu de dépendances fonctionnelles associé, basé sur le sens des attributs. Souvenez-vous qu'une super-clé est un jeu d'attributs qui détermine une entité unique. Autrement dit, une super-clé est un jeu d'attributs dont dépendent fonctionnellement tous les autres attributs du schéma de table. Certaines dépendances fonctionnelles sont évidentes. Par exemple, un attribut dépend fonctionnellement de lui-même. Ainsi, tout jeu d'attributs détermine fonctionnellement un ensemble secondaire de ses attributs, comme dans {A,B,C}--- > {A,B} Si nous connaissons les valeurs de A, B et C, alors nous connaissons la valeur de A et de B! De telles dépendances fonctionnelles ne sont pas du tout intéressantes et

61 Seconde forme normale 49 sont appelées dépendances triviales. Toutes les autres dépendances sont appelées non triviales. Seconde forme normale Intuitivement, un schéma de table T est dans le forme normale du deuxième ordre, ou 2NF, si tous les attributs strictement informatifs (attributs qui n'appartiennent à aucune clé) sont des attributs d'entités du schéma de table et non d'autres classes d' entités. En d'autres termes, les attributs informatifs fournissent une information spécifique sur les entités dans cette classe d'entités et non sur d'autres entités. Illustrons ceci par un exemple. Considérons un schéma de table simplifié, conçu pour recevoir des adresses de maisons. Une possibilité est la suivante {Ville, Rue, Numero, CouleurMaison, PopulationVille} L'attribut PopulationVille n'est pas à sa place ici, car c'est un attribut de ville et non d'adresses de particuliers. Plus précisément, PopulationVille est un attribut strictement informatif (ne servant pas à l'identification des maisons) car il fournit une information sur les villes et non sur les adresses. Ainsi, ce schéma de table n'est pas conforme à la deuxième forme normale. Nous pouvons être à peu près formels sur le sens de la seconde forme normale. En nous référant à l'exemple précédent, nous avons la dépendance suivante {Ville} -> {PopulationVille} où PopulationVille n'appartient à aucune clé et où Ville est un jeu secondaire de la clé {Ville, Rue, Numero}. Un schéma de table est dans le deuxième forme, 2NF, s'il n'est pas possible d'avoir une dépendance de la forme {A,,...,Ak} --- > {13) où B n'appartient à aucune clé (est strictement informatif) et {A1,...,Ak} est un jeu secondaire d'une clé et ainsi n'identifie pas les entités de cette classe d'entités, mais identifie plutôt les entités d'une autre classe d'entités. Abordons maintenant un exemple de schéma de table qui n'est pas conforme à la forme normale du deuxième ordre. Considérons le schéma de table suivant

62 50 Chapitre 4: Principes de conception des bases de données {Titre, PubID, AuID, Prix, AuAdresse} et supposons, pour les besoins de la démonstration, que deux livres ne peuvent pas avoir le même éditeur et le même auteur, bien qu'il puisse' y avoir plusieurs livres comportant le même titre dans la table. Ainsi, {Titre, PubID, AuID} est la clé unique. Pour l'instant, AuAdresse n'appartient à aucune clé, mais dépend de {AuID}, qui est un jeu secondaire de la clé, ce qui s'écrit {AuID} --- > {AuAdresse} En conséquence, ce schéma de table n'est pas conforme à la deuxième forme normale. En fait, AuAdresse n'est pas une portion d'information sur les entités placées dans le schéma de la table (c'est-à-dire, la table des livres), mais plutôt sur les auteurs. Naturellement, nous pourrions enlever l'attribut adresse pour mettre le schéma de table en conformité avec la deuxième forme normale. Si chaque éditeur ne publiait que des livres à prix unique, alors Prix serait cause d'une violation de la deuxième forme normale, mais ce n'est pas le cas naturellement. Troisième forme normale La seconde forme normale est excellente, mais il est possible de faire encore mieux. Nous avons vu que si le schéma de table est dans la seconde forme, il n'y a pas d' attributs strictement informatifs qui dépendent d'un jeu secondaire d'une clé. Cependant il existe une possibilité indésirable que nous allons illustrer par un exemple. Considérons le schéma de table suivant et supposons, pour les besoins de la démonstration, qu'il n'y a pas deux livres avec le même titre ayant le même éditeur {Titre, PubID,NbPages,Prix} La seule clé de ce schéma est {Titre,PubID}. NbPages et Prix ne sont que des attributs informatifs. Supposons maintenant que chaque éditeur décide que le prix de ses livres sera basé uniquement sur leur nombre de pages. Premièrement, nous observons que cette table est à la seconde forme normale Pour le constater, considérons les jeux secondaires de la clé. Ce sont {Titre} et {PubID} Mais aucune des dépendances suivantes {Titre} --- > {NbPages}

63 Troisième forme normale 51 {Titre} --- > {Prix} { PubID} -* {NbPages} { PubID} --* {Prix} ne s'applique au schéma de table. La connaissance du titre ne détermine pas le livre, puisqu'il peut y avoir plusieurs livres du même titre, publiés par différents éditeurs. C' est pourquoi la table respecte la seconde forme normale. Il n'est pas davantage correct d'écrire que {NbPages} -> {Prix} parce que différents éditeurs peuvent utiliser différents schémas de prix, tous basés sur le nombre de pages. Un éditeur peut, en effet, fixer un certain prix pour les ouvrages de plus de 1000 pages qui sera différent de celui fixé par ses concurrents pour le même type d'ouvrage. 11 est vrai cependant que {PubID,NbPages} - {Prix} est conforme. En d'autres termes, nous avons un attribut informatif {Prix} qui ne dépend pas d'un jeu secondaire d'une clé, mais dépend à la fois d'un jeu secondaire de clé {PubID} et d'un autre attribut informatif {NbPages}. Cette situation peut produire des redondances. Considérons par exemple la table 4-3. L'attribut Prix de cette table est redondant. Nous pourrions placer un prix sur la troisième ligne si la cellule était vide, parce que nous savons par ailleurs que PubID 2 fixe le prix des livres de 500 pages à $ Table 4-3. Données redondantes dans une table Titre PubID NbPages Prix Moby Dick Giant Moby Dick On peut résumer le problème avec la dépendance : {PubID,NbPages} -* {Prix} en disant que l'attribut Prix dépend d'un jeu d'attributs : {PubID,NbPages}

64 52 Chapitre 4: Principes de conception des bases de données qui n'est ni une clé, ni une super-clé, ni un jeu secondaire de clé. C'est un mélange contenant un attribut en provenance de la clé {Titre,PubID} et un attribut n'appartenant à aucune clé. En gardant cet exemple à l'esprit, définissons maintenant la troisième forme normale. Un schéma de table est conforme à la troisième forme normale, ou 3NF, s'il n'est pas possible d'avoir une dépendance de la forme {A1... Ak} -> {B} où B n'appartient à aucune clé (est strictement informatif) et {A1,... Ak} n'est pas une super-clé. En d'autres termes, le troisième forme normale ne permet pas qu'un attribut strictement informatif dépende d'autre chose que d'une super-clé. Les super-clés déterminent tous les attributs, y compris les attributs strictement informatifs, de sorte que tous les attributs dépendent tous d'une super-clé. Dans le troisième forme normale, des attributs purement informatifs dépendent exclusivement de super-clés. Forme normale de Boyce-Codd Il est possible de trouver des schémas de table qui sont conformes à la troisième forme normale et présentent néammoins des redondances. En voici un exemple. Considérons le schéma de table {Ville, Rue,CodePostal} avec les dépendances et {Ville, Rue} -> {CodePostal} {CodePostal} -> {Ville} Bien que dans la réalité un code postal puisse être partagé par deux villes différentes, nous supposons pour les besoins de l'exposé qu'il n'en est rien. Ce schéma de table est conforme à la troisième forme normale. Pour le vérifier, observons que les clés sont {Vi le,rue} et {CodePostal,Rue}. Pour cette raison, aucun attribut n'est purement informatif et rien ne viole la troisième forme normale. D'autre part, considérons la table 4-4. Nous pouvons remplir le champ vide de la deuxième ligne car :{CodePostal} -> {Ville} Table 4-4. Table avec dépendances Ville Rue CodePostal Los Angeles Hollywood Blvd Vine St 95000

65 Normalisation 53 Le problème ici concerne les dépendances {Code Postal}-{Ville} ne viole pas la troisième forme normale, car {Ville} n'est pas strictement informatif, comme nous l'avons déjà mentionné. L'exemple précédent nous incite à renforcer la condition dans la définition de la troisième forme normale, en abandonnant l'exigence selon laquelle B doit être strictement informatif. Nous pouvons ainsi définir notre dernière forme normale : un schéma de table est à la forme normale Boyce-Codd, ou BCNF, s'il n'est pas possible d'avoir une dépendance de la forme {A,,...,Ak} -> {B} où {A1,...,Ak} n'est pas une super-clé. Autrement dit, le forme BCNF ne permet pas à un attribut de dépendre d'autre chose qu'une super-clé. Comme nous l'avons déjà mentionné, tous les attributs doivent dépendre d'une super-clé, le terme super-clé étant pris dans son acception la plus rigoureuse. BCNF est ainsi la restriction la plus forte possible de ce type-il postule qu'un attribut ne peut dépendre exclusivement que d'une super-clé. Normalisation Le processus de modification relatif à la conception d'une base de données est appelé normalisation. Un simple exemple tel que le schéma de table suivant {ISBN,Titre,Auteur} n'est pas même à la première forme, parce que l'attribut Auteurs peut contenir plus d'un auteur et n'est pas atomique à cause de cela. En troquant ce schéma de table pour les deux schémas suivants {ISBN,Titre,AuID} et {AulD,AuNom} nous avons normalisé la base de données à la première forme normale. Voici un autre exemple impliquant les formes supérieures. Souvenez-vous d'un exemple précédent dans lequel le schéma de table {Ville,Rue, CodePostal} avec les dépendances et {ViIle,Rue} -> {CodePostal}

66 54 Chapitre 4: Principes de conception des bases de données {CodePostal} -> {Ville} est dans le troisième forme normale. Cependant, la table 4-5 montre qu'il subsiste des redondances avec ce schéma de table. Table 4-5. Une table avec des données redondantes Me Rue CodePostal Los Angeles Hollywood Blvd Vine St Le schéma n'est pas à la forme BCNF. En fait, il s'agit de l'exemple que nous avons utilisé pour étayer notre définition de BCNF (l'exemple ne respecte pas BCNF). Cependant, nous pouvons éclater le schéma de table en deux schémas {CodePostal,Ville} et {CodePostal, Rue} Dans ce cas, la table 4-5 est divisée en deux : tables 4-6 et 4-7 et les redondances disparaissent. Table 4-6. Première table dérivée de la table 4-5 pour éliminer les redondances I CodePostal Ville Los Angeles Table 4-7. Seconde table dérivée de la table 4-5 pour éliminer les redondances CodePostal Rue Hollywood Blvd Vine St D'une manière générale, la conception d'une base de données peut commencer avec un diagramme E/R. Ce diagramme peut être implémenté en considération des principes examinés au chapitre 3, Implémentation de modèles relationnels. Le résultat peut être une conception de base de données parfaitement satisfaisante. Toutefois, si certains des schémas de tables comportent des redondances, il peut être souhaitable de les diviser en des schémas de table plus petits satisfaisant une forme normalisée supérieure, comme dans l'exemple précédent.

67 Normalisation 55 Décomposition Bien que la décomposition d'un schéma de table en des schémas plus petits, si possible normalisés, soit souhaitable du point de vue de l'efficacité, pour éliminer les redondances et éviter diverses anomalies, elle présente un certain risque qui revêt deux formes Une possible perte d'information Une possible perte de dépendances L'exemple suivant illustre le premier problème - la perte d'informations. Considérons le schéma suivant {AuID,AuNom,PubID} La seule dépendance dans ce schéma de table est {AuID} -> {AuNom } Nous pouvons décomposer ce schéma de table en deux autres schémas. {AuID,AuNom} et {AuNom,PubID} Considérons maintenant la table 4-8, qui a deux auteurs différents portant le même nom. La décomposition donne les deux tables 4-9 et Table 4-8. Table avec deux noms d'auteur identiques AuID AuNom PublD Al A2 John Smith John Smith P1 P2 Table 4-9. Décomposition partielle de la table 4-8 AuID AuNom Al A2 John Smith John Smith Table Décomposition partielle de la table 4-8 AuNom PublD John Smith John Smith Pl P2

68 56 Chapitre 4: Principes de conception des bases de données Malheureusement, si nous demandions à Microsoft Access de nous afficher les données concernant les auteurs du nom de John Smith, nous aurions la table 4-11, qui n'est pas la table avec laquelle nous avons démarré! L'information a été perdue, dans le sens où nous ne savons plus que les deux John Smith ont publié seulement un livre, chacun avec un éditeur différent. Il peut sembler au premier abord que nous avons davantage d'informations, car la table est plus grande, mais en fait nous avons perdu de l'information. Table Reconstruction incorrecte de la table 4-8 AulD AuNom PublD Al John Smith Pl Al John Smith P2 A2 John Smith P1 A2 John Smith P2 Le second problème, lié à la décomposition d'un schéma de table, est celui de la perte de dépendances. Durant la vie de la base de données, nous allons devoir effectuer des modifications (mises à jour, insertions, suppressions) dans les différentes tables. Il est important de préserver les dépendances fonctionnelles héritées du schéma de table originel. Cependant, ceci ne garantit pas nécessairement que toutes les dépendances originelles seront préservées. Voici un exemple qui illustre le problème. Considérons le schéma de table {ISBN, NbPages, Prix} avec les dépendances {ISBN} -> {NbPages} {NbPages} -> {Prix} Considérons la décomposition en deux schémas {ISBN, NbPages} et {ISBN,Prix} La clef {ISBN} est présente dans les deux schémas de la décomposition. Malheureusement, la décomposition a provoqué la perte de la dépendance {NbPages} ->{Prix} car ces deux attributs ne sont plus dans le même schéma de table. A titre d' illustration, considérons la table 4-12, contenant deux ouvrages avec

69 Normalisation 57 le même prix et le même nombre de pages. La décomposition est illustrée aux tables 4-13 et Table Exemple montrant la suite de la décomposition ISBN NbPages Prix $ $39.95 Table Décomposition partielle de la table 4-12 ISBN NbPages Table Décomposition partielle de la table 4-12 ISBN Prix $ $39.95 Voici le problème. Si nous examinons la seconde table, nous ne trouvons aucune indication de la relation entre le nombre de pages et le prix qui figurait dans le schéma d'origine. C'est pourquoi il est possible de modifier le prix du second livre et de le ramener à $12.50, ce que nous avons fait à la table Table Exemple de décomposition sur le changement de prix ISBN Prix $ $12.50 En fusionnant les tables 4-13 et 4-15 pour obtenir une information synthétique sur l'ensemble des données, on obtient la table 4-16 qui révèle une violation de la règle de dépendance selon laquelle le nombre de pages détermine le prix! Table Vue des données après combinaison des tables 4-12 à 4-15 ISBN NbPages Prix $ $12.50

70 58 Chapitre 4: Principes de conception des bases de données Il est fort probable que quelqu'un chez l'éditeur s'irrite de constater que la société vend un ouvrage de 500 pages en-dessous de son prix. Inversement, considérons la décomposition du schéma de table originel en {ISBN,PubPhone} et {PubPhone, PubNom} Il n'y a pas ici de perte de dépendances, aussi nous pouvons sans crainte mettre à jour chaque table. Ces deux exemples illustrent les dangers d'une décomposition d'un schéma de table en des schémas de petite taille. Si une décomposition ne provoque aucune perte d' information, elle est dite décomposition sans perte. Si une décomposition ne provoque aucune perte de dépendances, elle est dite décomposition avec conservation des dépendances. Il est possible de démontrer que tout schéma de table peut être décomposé, sans perte d'information, en une série de schéma plus petits à la forme BCNF. Toutefois, il n'est pas possible de garantir que cette décomposition se fera sans perte de dépendances. Par ailleurs, tout schéma de table peut être décomposé sans perte d'information ni de dépendances en une série de schémas plus petits à condition de satisfaire le troisième forme normalisée. Cependant, pour calmer les enthousiasmes, hâtons-nous d'ajouter que les algorithmes que nous indiquons ne produisent pas toujours les résultats désirés. II peuvent créer, en effet, des décompositions moins intuitives que si nous utilisions notre propre intuition. Néanmoins, nous pouvons nous reposer sur eux pour produire la décomposition requise, si nous ne pouvons le faire nous-même. En conclusion, nous dirons qu'il n'y a pas de loi stipulant qu'une base de données est plus efficace et plus utile si les tables respectent un degré élevé de normalisation. Les problèmes de conception sont plus d'ordre subjectif que de nature objective et doivent être traités de manière ad hoc. Il apparaît à l'expérience que la meilleure procédure consiste à mixer quatre parts d'intuition pour une part de théorie. Espérons que notre exposé de la normalisation vous a donné une vue générale des problèmes concernés et un tremplin pour vous lancer dans l'étude plus approfondie de ces sujets quelque peu compliqués (voir Annexe D, Suggestions de lecture, pour une liste de livres sur le sujei).

71 Sur le CD-Rom 59 Sur le CD-Rom Ce chapitre, exceptionnellement, ne contient ni exemples, ni exercices.

72 Dans ce chapitre Langages de requête Algèbre relationnel et calcul relationnel L'ai èbre relationnel en détail Sur le CD-Rom Langages de requête et algèbre relationnel Dans la première partie de ce livre, nous avons essayé de fournir une argumentation convaincante sur l'importance que revêt une bonne conception pour l'utilisation efficace des bases de données. Comme nous l'avons vu, ceci suppose l'éclatement des données entre plusieurs tables. Naturellement, cela entraine l'utilisation de méthodes pour rassembler de nouveau les données sous différentes formes. L'une des fonctions principales d'un programme de base de données est de permettre à l'utilisateur de visualiser les données de nombreuses manières. Lorsque les données sont stockées dans de multiples tables, il est nécessaire de les rassembler pour générer ces diverses vues. Par exemple, nous pouvons désirer voir une liste de tous les éditeurs qui publient des ouvrages en-dessous de $ Cela exige le rassemblement de données en provenance de plusieurs tables. Le point d'achoppement est que, en éclatant les données entre plusieurs tables, nous sommes obligés souvent de les rassembler ensuite pour en obtenir une vue complète. Ainsi, nous pouvons établir l'importante maxime suivante Une bonne conception des bases de données a pour corollaire un recours fréquent à des méthodes de rassemblement de données à partir de plusieurs tables sous une forme unique et cohérente. De nombreuses applications de bases de données permettent à l'utilisateur de créer assez facilement des vues de données exhaustives à partir de plusieurs tables. Par exemple, Microsoft Access fournit une interface graphique pour créer des requêtes dans ce but. Notre objectif, dans ce chapitre, est de comprendre par quel moyen une application de base de données telle qu'access peut fournir ce service. Une brève réponse à la question est la suivante 61

73 62 Chapitre S: Langages de requête et algèbre relationnel 1. L'utilisateur d'une application de base de données, telle qu'access, demande à l' application de fournir une vue spécifique des données en créant une requête. 2. L'application de base de données convertit alors cette requête en une déclaration dans son langage de requête, qui dans le cas de Microsoft Access est dénommé Access Structured Query Language, ou Access SQL (il s'agit d'une forme dérivée du standard SQL). 3. Enfin, un composant spécial d'access (connu sous le nom de JetQuery Engine, que nous examinerons de nouveau au chapitre 7, Architecture système d'une base de données) exécute l'instruction SQL pour produire la vue désirée des données. Il est temps maintenant d'abandonner la discussion sur les problèmes de conception de bases de données et de nous tourner vers les sujets qui vont nous conduire à la programmation, en particulier, à la programmation à l'aide de langages de requête tels que Access SQL. Nous pouvons esquisser les grandes lignes de notre plan et du prochain chapitre. Dans ce chapitre, nous discuterons des méthodes impliquées dans le rassemblement de données à partir de différentes tables. En bref, nous allons examiner les méthodes de création de tables nouvelles à partir de tables existantes. Ceci nous éclairera sur les tâches générales qu'un langage de requête doit assurer. Au prochain chapitre, nous jetterons un coup d'ceil à Access SQL lui-même. Nous verrons que SQL est bien plus qu'un simple langage de requête, car il est non seulement capable de manipuler les composants d'une base de données existante (selon différentes vues), mais il est aussi capable de les créer. Langages de requête Une requête peut s'imaginer comme une requête sur la base de données, recevant comme réponse une nouvelle table, que nous dénommerons une table de résultats. Par exemple, en nous référant à la base de données LIBRARY, nous pourrions requérir le titre et le prix de tous les livres publiés par Big House qui valent plus de $ La table résultat dans ce cas figure à la table 5-1. Table 5-1. Livres publiés par Big House coûtant plus de $20.00 Titre Prix PubNom On liberty $25.00 Big House Iliad $25.00 Big House Visual Basic $25.00 Big House C++ $29.95 Big House

74 Langages de requête 63 Il n'est probablement pas nécessaire de souligner l'importance des requêtes, car quelle serait l'utilité d'une base de données si nous n'avions aucun moyen d'extraire les données sous une forme exploitable? Les langages spéciaux utilisés pour formuler des requêtes, en d'autres termes qui sont conçus pour créer de nouvelles tables à partir d'anciennes, sont connus sous le nom de langages de requête. Il ne semble pas qu'il y ait un consensus sur la signification précise du terme "langage de requête", aussi nous avons décidé de l'utiliser de la manière qui semble la plus cohérente avec le terme "requête". Il y a deux approches fondamentales des langages de requête : l'une est basée sur des expressions algébriques et l'autre est basée sur des expressions logiques. Dans les deux cas, une expression est formée en se référant à des tables existantes, des constantes (c' est-à-dire, des valeurs provenant du domaine des tables), et des opérateurs de types variés. La manière d'utiliser l'expression pour créer une table en retour dépend de l' approche, comme nous allons le voir. Avant de commencer, allons un peu plus loin dans la terminologie. Une table dont les données sont effectivement stockées dans une base de données est appelée une table de base. Les données de telles tables sont généralement stockées dans un format qui ne ressemble pas réellement à une table-le point essentiel est que les données sont stockées. Une table qui n'est pas stockée, telle que la table résultat d'une requête, est appelée une table dérivée. II est généralement possible de sauvegarder (c'est-àdire, stocker sur disque) une table résultat, qui pourrait devenir alors une table de base de la base de données. Dans Microsoft Access, ceci est fait grâce à une requête de génération de table. Une vue est une expression de requête à laquelle un nom est affecté, et qui est stockée dans la base de données. Par exemple, l'expression tous les titres où (PubNom = Big House) et (Prix > $20.00) est une vue. Notez que c'est l'expression qui est une vue et non la table résultat correspondante (ainsi que pourrait le laisser entendre le mot vue). Chaque fois que l'expression (ou vue) est exécutée, elle crée une table résultat. C'est pourquoi on fait souvent référence à une vue comme à une table virtuelle. Il est important de ne pas confondre une vue avec la table résultat, obtenue par l'exécution de l'expression. Le mérite d'une table virtuelle (ou vue) est qu'une expression généralement prend beaucoup moins de place que la table résultat correspondante. Les données dans une table résultat sont plus ou moins redondantes, puisque les

75 64 Chapitre 5: Lan2a2es de requête et algèbre relationnel données sont déjà dans les tables de base, même si ce n'est pas dans la même structure logique. Algèbre relationnel et calcul relationnel Le langage de requête algébrique le plus répandu est appelé algèbre relationnel. Ce langage est procédural, dans le sens où ses expressions décrivent une procédure explicite pour retourner les résultats. Les langages à base de logique tombent sous la désignation de calcul relationnel (il y a plusieurs de ces langages en usage actuellement). Ces langages sont dits non procéduraux, car leurs expressions représentent des déclarations décrivant les conditions qui doivent être satisfaites pour qu'une ligne soit dans la table résultat, sans montrer comment obtenir effectivement ces lignes. Illustrons ces idées par un exemple. Considérons la requête suivante, écrite en anglais Get the names and phone numbers for publishers who publish books costing under $ ( Rercherche du nom et numéro de téléphone d'éditeurs publiant des livres à moins de 20$). Par commodité, reproduisons les tables servant à cette requête. La table LIVRES apparaît en table 5-2, tandis que la table EDITEURS est illustrée à la table 5-3. Table 5-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

76 Algèbre relationnel et calcul relationnel 65 Table 5-3. La table EDIT FURS extraite de la base de données LIBRARY PublD PubNom PubPhone 1 Big House Alpha Press Small House Voici une procédure pour exécuter cette requête. Ne vous inquiétez pas si certains termes n'ont pas de sens pour vous maintenant ; nous les expliquerons plus tard. 1. Joignez les tables LIVRES et EDITEURS, sur l'attribut PubID. 2. Sélectionnez les lignes (de la jointure) avec l'attribut Prix ayant une valeur inférieure à $ Projetez en tête de colonnes PubNom et PubPhone. Dans l'algèbre relationnel, ceci prendrait la forme de l'expression suivante projpubnom,pubphone(jelprix<20.00(livres join EDITEURS)) Le résultat est illustré à la table 5-4. Table 5-4. Editeurs ayant des livres en-dessous de $20.00 PubNom PubPhone Big House Alpha Press o En calcul relationnel, l'expression correspondante prendrait la forme {(x,y) EDITEURS(z,x,y) and LIVRES(a,b,z,c) and c < $20.00} ù la barre I est lue "tel que" et l'expression entière est lue Le jeu de toutes les paires (x,y) telles que (z,x,y) est une ligne de la table EDITEURS, (a,b,z,c) est une ligne dans la table LIVRES, et c < $ Notez que la variable z apparaît deux fois et qu'elle doit être identique pour chaque occurence. C'est précisément ce qui fournit le lien entre les tables LIVRES et EDITEURS. En d'autres termes, la ligne EDITEURS(z,x,y) dans la table EDITEURS et la ligne LIVRES(a,b,z,c) dans la table LIVRES ont en commun une valeur d'attribut (representé par la lettre z commune). Cet attribut, qui est le premier attribut dans EDITEURS et le troisième attribut dans LIVRES, est PubID.

77 66 Chapitre 5: Langages de requête et algèbre relationnel Comme vous pouvez le constater à partir de cet exemple, le calcul relationnel est généralement plus complexe (et peut-être moins intuitif) que l'algèbre relationnel ; nous n'en parlerons plus dans ce livre, après avoir fait les commentaires suivants: Premièrement, il est important d'être au moins conscient de l'existence du calcul relationnel, puisqu'il y a plusieurs applications commerciales sur le marché, telles que celle d'ibm,,uery-by-example, qui utilisent le calcul relationnel. Deuxièmement, la plupart des langages basés sur le calcul relationnel ont exactement le même pouvoir d'expression que l'algèbre relationnel. Autrement dit, nous n'avons rien à gagner ou à perdre à utiliser un calcul relationnel par rapport à l'utilisation de l' algèbre relationnel. Détails de l'algèbre relationnel Nous sonmes prêts mainteant à examiner en detail l'algèbre relationnel. Les opérations qui en font partie sont décrites dans cette section. Vous remarquerez que la plupart de ces opérations sont intuitives. Toutefois, avant de commencer, nous dirons un mot sur la manière dont Microsoft Access implémente les opérations de l'algèbre relationnel. La plupart de ces opérations peuvent être implémentées dans Microsoft Access en créant une requête. La tâche est des plus aisée en mode Conception de requêtes d'access, qui fournit l'environnement graphique illustré à la figure 5-1. Figure 5-1. Fenêtre Conception de requêtes daccess L'utilisateur peut ajouter des schémas de table de la base de données dans la portion supérieure de la fenêtre Conception. Depuis là, de nombreux attributs peuvent être

78 Détails de l'agèbre relationnel 67 déplacés vers la grille de conception. Notez que la seconde ligne de la grille indique la table de provenance de l'attribut, pour le cas où deux tables auraient des attributs de même nom (c'est souvent le cas). La grille a des options de tri et d'affichage (pour pouvoir afficher ou non un attribut dans la table résultat). Elle ménage aussi de l'espace pour les critères utilisés pour filtrer les données de la requête. Notez que nous n'avons pas besoin d'inclure le champ PubID des deux tables à la section inférieure de la fenêtre. Microsoft Access prend soin de former la jointure appropriée basée sur l'information présente dans la partie supérieure de la fenêtre. Microsoft Access traduit la conception de la requête finale en une déclaration du langage de requête connu sous le nom structured query language (langage structuré de requête), ou SQL. Nous verrons en détail Access SQL (qui diffère quelque peu du langage SQL standard) au chapitre 6, Langage 5 L daccess, où les connaissances glanées ici s' avéreront très utiles. Nous nous devons de mentionner qu'access SQL est plus puissant que l'interface de conception des requêtes d'access, de sorte que certaines requêtes doivent être écrites directement en SQL. Heureusement, Access permet à l' utilisateur d'écrire directement des instructions SQL. Rappelons certaines notations utilisées précédemment. Pour mettre en évidence les attributs d'une table (ou schéma de table), nous utilisons la notation T(A 1,... A ). Par exemple, la table LIVRES peut être écrite LIVRES (ISBN,Titre,PublD,Prix) et le schéma de table Livres peut être écrit Livres(ISBN,Titre,PubID,Prix) Renommer Renommer signifie simplement changer le nom d'un attribut d'une table. Si une table T a un attribut A, nous noterons la table résultant du changement de nom de A en B par ren A - 4B (T) Pour la table ISBN Titre Prix PubiD The Firm S

79 68 Chapitre 5: Lamages de requête et algèbre relationnel ISBN _ Titre Prix Publi) Moby Dick $ War et Peace $ le résultat de l'exécution renisbn--->livreid,prix--->coût(livres) est illustré à la table 5-5. Table 5-5. La table LIVRES avec des champs renommés LivreiD Titre Coot PubiD The Firm $ Moby Dick $ War et Peace $ Union Si S et T sont deux tables avec les mêmes attributs, alors nous pouvons former l'union S u T, qui est justement la table obtenue en incluant toutes les lignes de S et T. Ainsi dans l'exemple suivant, l'union des deux premières tables produit la troisième. Exemple A, A 2 a b c e d f A l h A, A 2 a c e b d f

80 Détails de l'algèbre relationnel 69 A, A 2 g h Notez que si S et T n'ont pas les mêmes attributs, mais ont le même degré-c'est-àdire, le même nombre de colonnes, nous pouvons commencer par renommer les attributs d'une table pour les faire correspondre à ceux de l'autre, et puis effectuer leur union. Naturellement, ce ne sera pas toujours cohérent, car il peut en résulter la combinaisons de valeurs d'attributs de différents domaines dans une colonne. Considérons un exemple d'union opérée dans Microsoft Access. Les unions peuvent être réalisées dans Microsoft Access de deux manières différentes. La première est très simple 1. En premier lieu, nous avons besoin de tables extensibles pour cet exemple. Nous pouvons créer ces tables par recopie de la table LIVRES de la manière suivante. Activez la table LIVRES dans la fenêtre Bases de données et choisissez Copier du menu Edition. Ensuite, choisissez Coller depuis le menu Edition. Vous obtenez la boîte de dialogue de la figure 5-2. Figure 5-2. Boîte de dialogue Access : coller une table Tapez le nom de table Unionl et cliquez sur OK. Choisissez Coller une seconde fois pour créer une table nommée Union2. Ouvrez Unionl et effacez les sept dernières lignes de la table (mettez simplement les lignes en vidéo inverse et appuyez sur la touche Suppression). Ouvrez Union2 et effacez les sept premières lignes de la table. Ainsi, Unionl sera constituée de la première partie de la table LIVRES et Union2 sera constituée de la seconde moitié de LIVRES. 2. La façon la plus simple d'effectuer l'union est d'utiliser la même procédure Copier... Coller que celle de l'etape 1. Activez Union2 et choisissez Copier du

81 70 Chapitre 5: Lannaees de requête et algèbre relationnel menu Edition. Puis choisissez Coller et entrez le nom de table Unionl. Sélectionnez l'option : Ajouter des données à une table. Si vous cliquez sur OK, les lignes de la table copiée (Union2) seront ajoutées aux lignes de la table Unionl. En d'autres termes, Unionl contient maintenant l'union de la table d'origine Unionl et de la table Union2, qui dans ce cas reflète le contenu complet de LIVRES. Symboliquement, NewUnionl = OriginalUnionl U Union2 Ouvrez Unionl pour vérifier qu'elle a désormais 14 enregistrements. Effacez de nouveau les sept dernières lignes pour restaurer Unionl dans son état d'origine. Un autre moyen de créer une union est d'utiliser Requête Ajout.. comme suit 1. Depuis l'onglet Requête dans la fenêtre base de données choisissez le bouton Nouveau. Sélectionnez Mode Création et ajoutez Union2 à la partie supérieure de la fenêtre de conception. Sélectionnez Requête Ajout.. depuis le menu Requête pour obtenir la boîte de dialogue de la figure 5-3. Figure 5-3. Boite de dialogue Access : Requête Ajout 2. Cliquez sur OK pour obtenir la fenêtre illustrée à la figure 5-4. Glissez l'astérisque (*) du schéma de table de Union2 dans la première cellule de la ligne Champ de la grille de conception. Ceci remplit la première colonne de la grille de conception comme l'illustre la figure 5-4. Lancez la requête (choisissez Exécuter depuis le menu Requête). Vous recevez un avertissement selon lequel vous êtes sur le point d'ajouter 7 lignes de manière irréversible. Cliquez sur OK et ouvrez alors la table Unionl pour vérifier qu'elle contient désormais 14 enregistrements.

82 Détails de l'algèbre relationnel 11 Figure 5-4. Fenêtre Access Requête Ajout.. Intersection L'intersection S n T de deux tables S et T ayant les mêmes attributs est la table formée en ne gardant que les lignes apparaissant à la fois dans les deux tables. Dans l'exemple suivant, l'intersection des deux premières tables produit la troisième. A l A 2 a e e b d f A l A 2 e d e A l A 2 e e d f Nous verrons un exemple de création d'une intersection dans Microsoft Access lorsque nous aborderons la différence de deux tables, à la prochaine section.

83 72 Chapitre 5: Langages de requête et algèbre relationnel Différence La différence S - T de deux tables S et T avec les mêmes attributs est la table comprenant toutes les lignes de S qui n'apparaissent pas dans T ; elle est illustrée dans les tables suivantes A, a c e A 2 b d f h A, C e A, a g A 2 d 1 f A 2 b h Prenons un exemple de réalisation d'une intersection ou différence dans Microsoft Access. 1. Nous avons besoin de tables extensibles. Comme à la première étape de l'exemple de création d'une union, utilisez la fonction Copier/Coller pour créer deux tables intitulées Diff1 et Diff2 qui sont d'exactes copies de LIVRES. Ouvrez Diffl et supprimez les quatre dernières lignes. Ouvrez Diff2 et supprimez les quatre premières lignes. Ainsi, Diff1 contient les dix premiers ouvrages de LIVRES et Diff2 contient les dix derniers ouvrages de LIVRES. 2. Cliquez sur l'onglet Requête de la fenêtre Base de données et lancez une nouvelle requête. Ajoutez Diff1 et Diff2 à la requête. Vous devez noter une ligne de liaison entre les deux attributs ISBN. Si la ligne n'existe pas, glissez un nom ISBN sur l' autre pour créer une ligne. Maintenant cliquez sur la ligne avec le bouton droit de la souris et choisissez Propriétés de jointure depuis le menu déroulant. La boîte de dialogue, illustrée à la figure 5-5, devrait apparaître. Sélectionnez l'option 2, qui inclut tous les enregistrements (lignes) de Diff1 et tous les enregistrements de Diff2 qui ont un ISBN identique dans Diff1. C'est une

84 Détails de l'algèbre relationnel 73 jointure dite par la gauche. Nous aborderons ceci plus en détail plus loin dans cette section. Cliquez sur OK. Figure S-5. Boîte de dialogue Access :propriétés de jointure 3. Glissez l'astérisque (*) de Diffl vers la grille de conception et glissez l'isbn de Diff2 vers la seconde colonne de la grille. La fenêtre de conception devrait avoir l' apparence de la figure 5-6. Figure 5-6. Fenêtre Requête Sélection d Access : affichage d'une jointure entre deux propriétés 4. Lancez la requête. Vous obtenez la table illustrée à la figure 5-7. Cette table contient les dix lignes de Diffl, avec une colonne supplémentaire qui indique l'isbn correspondant de Diff2, s'il y en a un. Autrement, la colonne contient un NULL. Nous pouvons remarquer que les six lignes ayant un ISBN concordant dans la colonne Diff2.ISBN forment l'intersection des deux tables. Les quatre lignes n'ayant pas d'isbn concordant forment la différence Diff1 -

85 74 Chapitre 5: LanRa-ues de requête et algèbre relationnel Diff2. En fait, il suffit d'ajouter un simple critère à la requête pour obtenir l' intersection ou la différence. Figure 5-7. Fenêtre requêtes d Access : intersection de deux tables 5. Pour obtenir l'intersection Diffl r1 Diff2, retournez à la vue conception de la requête et ajoutez les mots Is Not Null sur la ligne Critère dans la colonne Diff2.ISBN. Exécutez la requête. 6. Pour obtenir la différence Diff1 - Diff2, retournez à la vue conception de la requête et ajoutez les mots Is Null sur la ligne Critère dans la colonne Diff2.ISBN column. Exécutez la requête. Produit cartésien Pour définir le produit cartésien de deux tables, nous devons adapter notre manière d' écrire les noms d'attributs, juste pour le cas où les tables auraient un attribut du même nom. Si une table T a un attribut appelé A, le nom d'attribut pleinement qualifié (ou simplement nom d'attribut qualifie) est T.A. Ainsi, nous pouvons écrire LIVRES.ISBN ou AUTEURS.AuID. Si S(A 1,... A,,) et T(Bsont des tables, le produit cartésien S X T de S et T est la table dont le jeu d'attributs contient les noms pleinement qualifiés de tous les attributs de S et T

86 Détail de l'agèbre relationnel 75 Les lignes de S X T sont formées par combinaison de chaque ligne s de S avec chaque ligne t de T, pour former une nouvelle ligne st. Dans l'exemple suivant, le produit des deux premières tables donne comme résultat la troisième table. A l A 2 a e e b d f g B 2 B 3 h k 1 S.A 1 S.A 2 T.B 1 T.B 2 T.B 3 a b g h a b k I d C g h c d k I e f b h e f 1 Notez que si S a k lignes et T a j lignes alors le produit cartésien a kj lgnes. En conséquence, le produit cartésien de deux tables peut être très grand. Pour obtenir le produit cartésien de deux tables dans Microsoft Access, procédez comme suit : 1. Créez les deux tables S et T de l'exemple précédent. 2. Créez une nouvelle requête et ajoutez les tables S et T. Assurez-vous qu'il n'y a aucune ligne joignant les schémas de table (s'il y en a, cliquez avec le bouton droit de la souris sur les lignes et choisissez Supprimer depuis le menu déroulant). 3. Glissez les astérisques de chaque schéma de table vers la grille de conception. Vous devriez obtenir la fenêtre de conception illustrée à la figure 5-8. Lancez la requête pour obtenir le produit cartésien.

87 76 Chapitre 5: LanRaües de requête et algèbre relationnel Figure 5-8. Fenêtre requêtes daccess :produit cartésien de deux tables Projection La projection est un concept très simple. Intuitivement, une projection d'une table sur un sous-ensemble de ses attributs (colonnes) est la table formée par élimination de toutes les autres colonnes. Plus formellement, posons que T(A1,...A,,) est une table, où A = {A 1,... A n } est le jeu d'attributs. Si B est un sous-ensemble de A alors la projection de T sur B est la table obtenue depuis T en conservant les colonnes dont l'en-tête provient des noms d'attributs de B. Nous désignons cette table par proj B (T). Exemple Pour la table ISBN Titre Prix PubID '8-9 The Firm S Moby Dick $ War et Peace $25.00 la projection projsbn,prix (LIVRES) est: ISBN Prix

88 Détails de l'algèbre relationnel 77 ISBN Prix $ S25.00 Notez que, si la projection produit deux lignes identiques, les lignes doublonnées doivent être supprimées, car une table ne peut pas avoir de doublons. (Cette règle des bases de données n'est pas respectée par l'ensemble des bases de données commerciales. En particulier, elle n'est pas respectée par Microsoft Access. C'est-àdire que certains produits autorisent des lignes identiques dans une table. Par définition, ces produits ne sont pas des base de données relationnelles-mais ce n'est pas nécessairement une tare). La fenêtre des requêtes de Microsoft Access a été taillée sur mesure pour créer des projections. Ajoutez la table dans la fenêtre de conception et glissez les noms d' attribut désirés sur la grille de conception. Exécutez la requête pour obtenir la projection. La figure 5-9 montre la fenêtre de conception de requêtes pour la réalisation d'une projection de Livres sur les attributs ISBN et Prix. I igure 5-9. C,iéatiou d nune projedion utilisant la table LI I K LS Sélection De la même manière que l'opération de projection sélectionne un sous-ensemble de colonnes d'une table, l'opération de sélection sélectionne un sous-ensemble de lignes d' une table. La première étape dans la définition d'une opération de sélection est de définir une condition de sélection ou un critère de sélection pouvant être toute expression formée légalement et mettant en oeuvre des

89 78 Chapitre 5: Lanwa-uer de requête et algèbre relationnel Constantes (c'est-à-dire, membres de n'importe quel domaine) Détails Noms de l'agèbre d'attribut relationnel Relations arithmétiques de comparaison (_, ~, <, < > >) Opérateurs logiques (and, or, no) Par exemple, les conditions suivantes sont des conditions de sélection Prix > $10.00 Prix <_ $50.00 and AuName = "Bronte" ( Prix <_ $50.00 and AuName = "Bronte") or (not AuName = "Austen") Si condition est une condition de sélection, alors la table résultat obtenue par application de l'opération de sélection correspondante à une table T est notée comme ceci Sel conditionl l l ou parfois par T si condition et est la table obtenue depuis T en conservant les seules lignes qui satisfont la condition de sélection. Par exemple, pour les LIVRES dans la base de données LIBRARY: ISBN Titre PubiD Prix Iliad 1 $ Moby Dick 3 $ On Liberty 1 $ Jane Eyre 3 $ Ulysses 2 $ Balloon 3 $ Main Street Macbeth 2 $ Hamlet 2 $ Faerie Queene 1 $ King Lear 2 $ Emma 1 $ C++ 1 $ Visual Basic 1 $25.00

90 79 la table selprix>525.00(livres) est ISBN Titre PublD Prix Janc Fv - re Moby Dick 3 $ King Lear 2 $ Ulysses 2 $ C++ 1 $ Balloon 3 $34.00 Certains auteurs utilisent le terme restriction à la place de selection. Il ne semble pas être mieux approprié mais a l'avantage qu'il n'est pas confondu avec l'instruction SQL SELECT, qui est bien plus générale que la sélection. Toutefois, il est moins répandu que le terme "selection", c'est pourquoi nous utilisons ce terme. La fenêtre de requêtes de Microsoft Access a été taillée sur mesure pour créer des sélections. Nous utilisons les lignes Critère pour appliquer les sélections. Par exemple, la figure 5-10 montre la fenêtre de requête pour la sélection: selprix>$25.00(livres) de l'exemple précédent. Figure I ru h e requétes daccess : création dune sélection Vous admettrez probablement que les opérations que nous avons couvertes jusqu' ici sont plutôt simples-union, intersection, différence et produit cartésien

91 80 Chapitre 5: I.anRaRes de requête et algèbre relationnel sont des opérations de base de la théorie des ensembles. Les sélections de lignes et de colonnes sont clairement des opérations de grand intérêt. Détails de l'agèbre relationnel Les six opérations de changement de nom, d'union, de différence, de produit cartésien, de projection et de sélection sont suffisantes pour définir complètement l' algèbre relationnel, par combinaison de ces opérations avec des constantes et des noms d'attribut pour créer des expressions algébriques relationnelles. Cependant, il est très pratique de définir des opérations complémentaires sur les tables, même si elles peuvent être exprimées de façon plus ou moins compliquée à l'aide des six opérations de base mentionnées plus haut. Jointures Les différents types de de jointures sont parmi les opérations les plus importantes et les plus utiles de l'algèbre relationnel. Jointurer deux tables revient à combiner les lignes de deux tables sur la base d'une comparaison de valeurs dans des colonnes sélectionnées. Equi jointure Dans une équi-jointure, les lignes sont combinées s'il y a des valeurs d'attribut égales dans certaines colonnes sélectionnées de chaque table. Pour être précis, soit S et T deux tables et supposons que {C1,...,Ck} sont des attributs sélectionnés de S et {D1,...,Dk} sont des attributs sélectionnés de T. Chaque table peut avoir également des attributs supplémentaires. À noter que nous sélectionnons le même nombre d'attributs de chaque table. L'équi-jointure de S et T sur les colonnes {C1,...,Ck} et {D 1,... D k } est la table formée par la combinaison d'une ligne de S avec une ligne de T à condition que les colonnes correspondantes aient même valeur, c'est-à-dire, à condition que l'on ait S.C 1 = T.D 1, S.C 2 = T.D 2,... S.C k = T.D k Exemple Considérons les tables A, A

92 81 B 1 B 2 B Pour former l'équi-jointure S equi join A2 = B 3 T nous combinons les lignes pour lesquelles S.A 2 = T.B 3 Ce qui donne S.A 1 S.A 2 T.B 1 T.B 2 T.B Notez que l'équi-jointure peut être exprimée en termes de produit cartésien et d' opération de sélection comme suit 3 equijoie =D,...,Ck=D k T=sel f =D,...,Ck=D,(SxT) Ceci signifie simplement que, pour former l'équi-jointure, nous prenons le produit cartésien S X T de S et T (c'est-à-dire, le jeu de toutes les combinaisons de lignes de S et de T) et que nous sélectionnons uniquement les lignes pour lesquelles S.C 1 = T.D 1, S.C 2 = T.D 2,..., S.C k = T.D k Jointure naturelle La jointure naturelle (natjoin) est une variante de l'équi-jointure, basée sur l'égalité de tous les attributs communs dans deux tables. Plus précisément, posons que S et T sont des tables et que le jeu de tous les attributs communs entre ces tables est {Cl,... C n }. Ainsi, chaque table pourrait avoir des attributs supplémentaires, mais aucun autre attribut en commun. La jointure naturelle de S et T, que nous notons ainsi S nat join T

93 82 Chapitre 5: Langages de requête et al èbre relationnel est effectuée en deux étapes 1. Formation de l'équi-jointure sur les attributs communs {C 1,... C n } 2. Elimination du second jeu de colonnes communes de la table Considérons ces tables: A, A 3 A 4 a c d e g h i k I m n o B, p A 4 B 4 a c d c 1 f f d g x z h s I j Dans ce cas, le jeu d'attributs communs est {A 2,A 4 }. Les colonnes correspondantes sont ombrées pour faciliter l'identification. L'équi-jointure sur A 2 et A 4 est S.A 1 S.A2 S.A 3 S.A 4 T.B 1 T.A 2 T.A 4 T.B 4 a c d f b d g k 1 c j 1 f k 1 s j h La suppression du second jeu de colonnes communes (les colonnes qui proviennent de T, grisées dans la table précédente) donne S.A 1 S.A 2 S.A 3 S.A 4 T.B 1 T.B 4 a b c f g i k I c f j k 1 s h L'importance de la jointure naturelle vient du fait que, en présence d'une relation de type un-à-plusieurs de S à T, nous pouvons l'arranger, en la renommant si néces-

94 Détails de l'algèbre relationnel 83 saire, de sorte que les seuls attributs communs soient la clé de S et la clé étrangère dans T. Dans ce cas, la jointure naturelle S natjoin T est simplement la table obtenue en faisant correspondre les lignes liées à travers la relation de type un-à-plusieurs. Par exemple, considérons les tables LIVRES et EDITEURS aux tables 5-6 et 5-7, respectivement Table 5-6. La table LIVRES ISBN Titre Prix PubiD The Firm $ Moby Dick $ War et Peace $ Jane Eyre $ Persuasion $ Emma $ The Chamber $ Partners $ Triple Play $ Mansfield Park $ Table 5-7. La table EDIT E URS PubID PubNom PubPhone 1 Big House Little House Medium House Alors, EDITEURS natjoin LIVRES est la table formée en prenant chaque ligne EDITEURS et en lui joignant chaque ligne LIVRES avec une correspondance exacte sur PublD, comme l'illustre la table 5-8. Table 5-8. Table de jointure naturelle EDTI L URS - LIVRES PubID PubNom PubPhone ISBN Titre Prix 1 Big House The Firm $ Big House War et Peace $ Big House Jane Eyre $ Big House Partners $ Big House Mansfield Park $ Little House Moby Dick $49.00

95 84 Chapitre 5: Lan. Wes de requête et algèbre relationnel Table 5-8. Table de jointure naturelle EDIT E URS - LIVRES (suite) PubID PubNom PubPhone ISBN Titre Prix 3 Medium House Persuasion $ Medium House Emma $ Medium House The Chamber $ Medium House Triple Play $44.00 O jointure La 6-jointure (lire theta jointure, car 6 est la lettre grecque theta) est similaire à l'équijointure et est utilisée quand nous devons faire une comparaison non égalitaire entre des valeurs de colonnes. En fait, la 8-jointure peut utiliser l'une ou l'autre des relations arithmétiques de comparaison suivantes =,~,<,< >,> Soit S et T deux tables; supposons que {C1,... C k } sont des attributs sélectionnés de S et {D1,...,Dk{ sont des attributs sélectionnés de T. Chaque table peut avoir également des attributs supplémentaires. Noter que nous sélectionnons le même nombre d'attributs dans chaque table. Soit O 1,...,6 k les relations de comparaison. La 0-jointure des tables S et T sur les colonnes Cl,...,Ck et D 1,...,Dk s'écrit S e joi n C, 9, D,,..., C k 9 k D k T=selc i 9,D I,..., C k O k D k (SXT) Pour former la 6-jointure nous utilisons le produit cartésien S X T de S et T, puis nous sélectionnons les seules lignes pour lesquels la valeur dans la colonne C 1 est en relation 0 1 à la valeur de la colonne D 1 et de même pour chacune des autres colonnes. Exemple Considérons ces tables A, A B, B 2 B

96 Détails de l'algèbre relationnel 85 Pour former la 6-jointure: S 8 joina2 < B; T nous conservons les seules lignes du produit cartésien des deux tables pour lesquelles la valeur de la colonne A 2 est <_ à la valeur de la colonne B 3 S.A 1 S.A 2 T.B 1 T.B 2 T.B Remarquons qu'une 6-jointure où toutes les relations 6 i sont égales (_) est précisément l'équi-jointure. Jointures externes Jointure naturelle, équi-jointure et 6-jointure sont qualifiées de jointures internes. Chaque jointure interne a une jointure externe gauche et une jointure externe droite correspondante, qui sont formées en prenant d'abord la jointure interne correspondante et en incluant des lignes supplémentaires. En particulier, pour la jointure externe gauche, si s est une ligne de S qui n'a pas été utilisée dans la jointure interne, nous incluons la ligne s, remplie avec des valeurs NULL. Un exemple servira à clarifier ce concept. Dans un exemple précédent, nous avons vu que la jointure naturelle des tables A, A 2 A 3 A 4 a b c d e f g h i k 1 m n o p B, A 2 A 4 B 4 a b d c j f f b g x y z h s j 1

97 26 Chapitre 5: Langages de requête et algèbre relationnel e A, st A 2 A 3 B 1 B 4 a b c d f g j k I c f i j k I s h La jointure externe gauche correspondante est la même que la jointure naturelle, mais avec quelques lignes supplémentaires A, A 2 A 3 A 4 B 1 B 4 a b c d f g k I c f k I s h e f g h NLLL NULL m n o p NULL NULL En particulier, la jointure externe gauche contient également deux lignes de S qui n' étaient pas concernées dans la jointure naturelle, avec des valeurs NULL utilisées pour remplir les lignes. La jointure externe droite est définie de manière similaire, et les lignes de T sont incluses, avec des valeurs NULL à la place des valeurs S. L'une des utilisations les plus simples d'une jointure externe est d'aider à voir ce qui ne fait pas partie d'une jointure interne! Par exemple, la table précédente nous montre immédiatement que les seconde et quatrième lignes de la table S ne sont pas impliquées dans la jointure naturelle S-T! Autrement dit, les valeurs ne sont présentes dans aucune ligne de la table T.

98 Détails de l'algèbre relationnel 87 Implémentation des jointures dans Microsoft Access Examinons maintenant comment implémenter les différents types de jointures dans Microsoft Access. La fenêtre Requêtes d'access rend aisée la création d'équi-jointures. Naturellement, une jointure naturelle est créée facilement à partir d'une équijointure appropriée en utilisant une projection. Illustrons cette déclaration à l'aide d' un exemple. Commençons par créer les deux tables, S et T, illustrées aux tables 5-9 et Table 5-9. La table S A, A2 a C e b d f Table La table T B, B 2 B 3 9 h j I C d c d y C Z Créons l'équi-jointure Ouvrons la fenêtre de conception de requêtes (en cliquant sur Nouveau...) et ajoutez ces deux tables. Pour établir les associations glissez le nom d'attribut A 1 sur B 1 et glissez le nom d'attribut A 2 vers B 2. Ceci devrait créer les lignes illustrées à la figure Glissez les deux astérisques vers le bas dans les deux premières colonnes de la grille de conception, comme le montre la figure Access fournit l'astérisque comme moyen rapide de glisser tous les champs dans la grille. Cela revient à glisser chaque champ séparément, mais avec une exception-les changements de la table sous-jacente sont reflétés dans l'asté

99 88 Chapitre 5: Lanna2es de requête et algèbre relationnel risque. En d'autres termes, si de nouveaux champs sont ajoutés à la table, ils seront inclus automatiquement dans la requête. Figure Fenêtre Requêtes d Access : établissement des associations Il ne nous reste plus qu'à lancer la requête. Le résultat est illustré à la table Table Une équi jointure des tables S et T A, A 2 B, B 2 B 3 c d c d c d c d a Autrement dit, Microsoft Access utilise les relations définies graphiquement dans la partie supérieure de la fenêtre pour créer une équi-jointure. La fenêtre de conception de requête de Access ne nous permet pas de créer une 6- jointure qui n'utilise pas l'égalité. Cependant, nous pouvons créer facilement une telle jointure à partir d'une équi-jointure en modifiant la déclaration SQL correspondante. Nous aborderons SQL en détail au chapitre 6. Pour l'instant, modifions l'exemple précédent pour illustrer la technique. Depuis la vue conception pour la requête de l'exemple précédent, selectionnez SQL dans le menu Affichage. Vous devriez voir la fenêtre de la figure Ceci est la déclaration SQL créée par Access à partir de notre requête pour l' exemple précédent. Éditons maintenant les deux signes d'égalité = et transformonsles en <_ (plus petit ou égal à). S'agissant de texte, les signes plus petit que ou égal à se réfèrent à l'ordre alphabétique.

100 Détails de l'algèbre relationnel 89 Figure L'instruction SQL générée à partir de la figure 5-11 Exécutons la requête. La table résultat devrait ressembler à celle de la table Table Table résultat d'une 0 jointure A i A 2 B i B 2 B 3 a b g h i a b k 1 a b c d x a b c d a b c z C d g h I C d 1 C d c d c d c d y C d c z e f g h e f k I Remarquons que pour chaque ligne de la table, A 1 précède ou égale B 1 en ordre alphabétique et A 2 précède ou égale B 2. Finalement, on observe que si nous essayons de retourner à la vue conception de cette requête, Access émet le message de la figure 5-13, parce que la vue conception ne peut créer de 6-jointures qui ne sont pas basées strictement sur l'égalité. Pour créer une jointure externe, remettez la déclaration SQL de l'exemple précédent dans sa forme d'origine (avec des signes =), puis revenez à la vue conception. Cliquez avec le bouton droit de la souris sur l'une des lignes de liaison entre les schémas de tables et choisissez Propriétés de jointure depuis le menu déroulant. Ceci donne la boîte de dialogue illustrée à la figure Sélectionnez l'option 2, qui va créer une jointure externe gauche (l'option 1 crée une jointure interne, l'option 2 crée une jointure externe gauche et l'option 3 crée

101 3 0 Chapitre 5: Langages de requête et algèbre relationnel Figure Message d'erreur Access : tentative de création de O jointures inégales Figure Boiîte de dialogue Access :propriétés de jointure une jointure externe droite). Faites la même chose pour l'autre ligne de liaison. Jetez un coup d'a-il à l'instruction SQL, affichée à la figure Figure Instruction iql illustrant une jointure externe gauche

102 Détails de l'algèbre relationnel 91 Nous pouvons exécuter maintenant la requête, qui devrait donner la table résultat de la table 5-13, dans laquelle les cellules vides contiennent une valeur NULL. Table Une jointure externe gauche A, a A 2 B, B 2 B 3 b c d c d c d c d e f Naturellement, une jointure externe droite est créée de façon similaire, en choisissant l' option 3 de la figure Semi jointures Une semi jointure est formée à partir d'une jointure interne (ou d'une 9-jointure) par projection sur l'une des tables ayant participé à la jointure. En d'autres termes, nous commençons par former la jointure et puis nous conservons juste les colonnes provenant de S ou de T. Ainsi; la formule pour la semi jointure gauche est Le concept de semi-jointure apparaît en liaison avec le mot-clé DISTINCTROW de la clause SELECT dans Access SQL, que nous étudierons au chapitre 6. Pour l' instant, considérons un exemple de semi-jointure, qui devrait démontrer l'utilité des semi-jointures. Imaginons que nous ajoutions un nouvel éditeur à la table EDITEURS (Another Press à la table 5-14), mais sans ajouter de livres de cet éditeur à la table LIVRES. Considérons la jointure interne des tables EDITEURS et LIVRES

103 1 92 Chapitre 5: LaneaRes de requête et algèbre relationnel de la base de données LIBRARY, la table résultat de cette jointure est illustrée à la table Table La (nouvelle) table EDTl L URS PubID PubNom PubPhone 1 Big House Alpha Press Small House Another Press Table Table résultat d'une jointure interne EDITEUR.PubID 3 Small House 3 Small House 3 Small House 3 Small House PubNom PubPhone ISBN Titre Jane Eyre Moby Dick LIVRES PubID Prix 3 $ $ Balloon 3 $ Main Street 1 Big House On Liberty 3 $ $ Big House Iliad 1 $ Big House Faerie Queene 1 $ Big House Emma 1 $ Big House Visual Basic 1 $ Big House C++ 1 $ Alpha Press 2 Alpha Press 2 Alpha Press 2 Alpha Press Hamlet 2 $ Macbeth 2 $ King Lear 2 $ Ulysses 2 $34.00 Si nous faisons une projection sur la table EDITEURS, nous obtenons une semijointure gauche

104 Détails de l'algèbre relationnel 93 dont la table résultat est illustrée à la table Table Table résultat d'une semi jointure POW PON= PubPhone 3 Small House Big House Alpha Press C'est le jeu de tous les éditeurs qui ont des entrées dans la base de données LIVRES. Autres opérations de l'algèbre relationnel Il y a une opération de l'algèbre relationnel qui apparaît de temps en temps, appelée le quotient. Comme cette opération est moins répandue, nous la traiterons à l'annexe B, Le quotient : opération complémentaire de l'algèbre relationnel (vous pouvez aller directement à cette annexe après avoir fini ce chapitre, si vous êtes intéressé). Optimisation Concluons cet exposé par une brève remarque sur l'optimisation. Comme nous l'avons vu, les formes de l'algèbre relationnel sont procédurales; c'est-à-dire qu'elles décrivent une procédure pour effectuer une série d'opérations. Cependant, cette procédure est souvent peu efficace. Illustrons ce propos à l'aide d'un exemple extrême. Considérons les deux schémas de table Si S est une table basée sur le premier schéma et T est une table basée sur le second schéma, la jointure naturelle est dans ce cas D'après cette formule, la jointure est effectuée selon les étapes suivantes 1. Formation du produit cartésien 2. Choix de la sélection appropriée 3. Choix de la projection appropriée

105 34 Chapitre 5: Langages de requête et al èbre relationnel Imaginons maintenant deux tables S et T, contenant toutes deux lignes. Admettons également que les tables ont seulement un attribut en commun, pour lequel il n'y a pas deux valeurs identiques dans les deux tables. Dans ce cas, en accord avec la définition de la jointure naturelle, la jointure est en fait une table vide. Cependant, conformément à la procédure décrite plus haut, la première étape du calcul de cette jointure est le calcul du produit S X T, qui a X = lignes; c'est-à-dire, cent millions de lignes! À l'évidence, il ne s'agit pas là de la meilleure procédure pour calculer la jointure! Heureusement, les programmes de bases de données qui utilisent un langage procédural ont des routines d'optimisation pour éviter des problèmes comme celui-là. De telles routines examinent la requête et essaient de trouver une procédure alternative qui produira le même résultat mais avec moins de calculs. Ainsi, d'un point de vue pratique, les langages procéduraux se comportent parfois comme des langages nonprocéduraux. Sur le CD-Rom L'ensemble des exemples de ce chapitre se trouvent placés dans différents documents. Pour les consulter, affichez le document d'orientation à l'adresse suivante / exemples/ chapo5/ chapo5. htm. La structure d'exposition des exemples et des exercices suit la structure du chapitre et aborde essentiellement les opérations de requête et les opérations sur les tables Algèbre relationnel Opérations détaillées Unions Intersections Produit cartésien Projections Sélections Jointures Les opérations effectuées sur la base LIBRARY peuvent être reportées sur la base CATALOG.

106 Dans ce chapitre Introduction à Access SQL Conception des requêtes Access Types de requêtes Access Pourquoi utiliser SQL Access SQL Le composant DDL d' Access SQL Le composant DML d' Access SQL Sur le CD-Rom Introduction à Access SQL Comme nous l'avons dit, Microsoft Access utilise une forme de langage de requête qualifié de structuré (StructuredQuey Language ou SQL). SQL est le plus répandu des langages de requête de bases de données en usage aujourd'hui. Il est en fait plus qu'un simple langage de requête, si on le rapproche de la définition que nous en avons donné au précédent chapitre. C'est un langage complet de système de gestion de bases de données (DBMS : Database Management System), car il a la capacité non seulement de manipuler les composants d'une base de données, mais aussi de les créer. En particulier, SQL a les composants suivants 1. Un langage de définition de données, ou DDL (Data Definiton Language), composant autorisant la définition (création) de composants de bases de données, tels que les tables. 2. Un langage de manipulation de données, ou DML (Data Manipulation Language), composant permettant la manipulation de composants de bases de données. 3. Un langage de contrôle des données, ou DCL (Data Control Language), composant fournissant la sécurité interne à la base de données. Nous allons étudier les deux premiers composants de SQL en détail dans ce chapitre. SQL (connu également sous le nom de SEQUEL) a été développé par IBM à San Jose, California. La version courante de SQL est appelée SQL-92. Toutefois, Microsoft Access, comme tous les autres produits commerciaux qui supportent SQL, n' implémente pas la totalité de SQL-92 standard, et ajoute en outre des caractéristi 95

107 96 Chapitre 6 : LannaRe Access SPLL ques supplémentaires de son cru au langage. Comme ce livre utilise Microsoft Access, nous allons étudier la version Access de SQL. Conception de requêtes Access Dans Microsoft Access, les requêtes peuvent être définies de plusieurs manières différentes, mais elles aboutissent toutes à une instruction SQL in fine. L'Assistant de requêtes facilite la création d'une requête en amenant l'utilisateur à répondre à une série de questions. Cette approche est la plus conviviale, mais aussi la moins puissante. Access propose aussi une fenêtre de conception de requêtes avec deux vues différentes. La Vue conception est présentée à la figure 6-1. Figure ire Conception de requête daccess La vue Conception de requêtes affiche des schémas de table, avec leurs relations, et permet à l'utilisateur de sélectionner les colonnes à retourner (projection) et spécifie les critères relatifs aux données retournées (sélection). La figure 6-1 montre une définition de requête avec jointure de la table LIVRES et de la table EDITEURS et retourne le titre, l'éditeur et le prix de tous les livres dont le prix est supérieur à $ La fenêtre Conception de requêtes a aussi une Vue SQL. Y accéder pour voir l' instruction SQL qui correspond à la Vue conception de requête. La figure 6-2 montre l'instruction SQL correspondant à la requête de la figure 6-1. En plus de l'utilisation de la Vue conception, les utilisateurs peuvent entrer directement des instructions SQL dans la fenêtre Vue SQL. En réalité, certaines

108 Typer de requêtes Access 97 Figure 6-2. La Vue.SEL Access de la Figure 6-1 constructions, telles que la construction directe de l'union de deux tables dans une troisième table, ne peuvent être réalisées à l'aide de la Vue conception, et doivent être saisies à l'aide de la Vue SQL. Toutefois, de tels montages sont rares, et il est souvent possible d'achever un projet sans avoir besoin d'entrer des instructions SQL directement. Types de requêtes Access Access supporte une grande variété de types de requêtes Requêtes Select. Ces requêtes retournent des données d'une ou de plusieurs tables et placent les résultats dans une table résultat. Cette dernière peut (habituellement) être mise à jour. Les modifications de données qui y sont effectuées seront répercutées dans les tables sous-jacentes. Les requêtes Select peuvent être utilisées également pour grouper des lignes et calculer des sommes, des moyennes, effectuer des comptages et d'autres types de totalisation pour ces groupes. Requêtes Action. Ce sont des requêtes qui impliquent une certaine forme d'action. Les requêtes Action sont - Requête Make-Table. Une requête conçue pour créer une nouvelle table destinée à recevoir des données en provenance de tables existantes. - Requête Delete. Une requête utilisée pour effacer des lignes dans une table ou des tables données. - Requête Append. Une requête utilisée pour ajouter des lignes supplémentaires à la fin d'une table existante. - Requête Update. Une requête utilisée pour effectuer des changements dans une ou plusieurs lignes d'une table. Requêtes SQL. Ce sont des requêtes qui doivent être entrées dans la Vue SQL. La requêtes SQL sont - Requête Union. Une requête qui crée l'union de deux tables ou davantage.

109 98 Chapitre 6 : LanRaRe Access SQL Requête Pass-Through. Une requête qui passe une instruction SQL non interprétée à un serveur externe de bases de données (nous n'examinons pas ces requêtes dans le présent ouvrage). Requête Data-Definition. Une requête utilisant le composant DDL de SQL, telle que CREATE TABLE ou CREATE INDEX. Requête Crosstab : Il s'agit d'un type spécial de requête Select qui affiche les données au format d'une feuille de calcul de tableur, avec en-têtes de ligne et de colonne. Par exemple, nous pouvons souhaiter connaître le nombre de livres publiés par chaque éditeur par classe de prix ou par prix. C'est plus facile à rendre, grâce à une requête croisée, comme le montre la table 6-1. Table 6-1. Une requête CROSSTAB Prix Total Big House Medium House Small House $ $ $ $ $ $ $ $ $ $ Requête Parameter. Avec les requêtes Select ou Crosstab, nous pouvons décider de laisser l'utilisateur fournir certaines données au lancement, en répondant à une boîte de dialogue. Ceci peut être fait à la fois dans la Vue conception et la Vue SQL. Lorsque la requête réclame une information à l'utilisateur, on dit de cette requête qu'elle est paramétrée, ou qu'il s'agit d'une requête avec paramètres. Finalement, mentionnons qu'access permet qu'une requête Select ou une requête Action contiennent une autre requête Select. Ceci se fait en imbriquant des instructions SQL SELECT, comme nous le verrons. La requête interne est appelée sousrequête ou requête secondaire de la requête externe. Access autorise plusieurs niveaux de requêtes secondaires.

110 Pourquoi utiliser SQL? 99 Pourquoi utiliser SQL? Lorsque nous examinerons par la suite la syntaxe des instructions SQL, vous serez peut-être étonné de constater que SQL n'est pas un langage particulièrement plaisant. Comme nous l'avons dit, de nombreuses caractéristiques de SQL sont plus ou moins accessibles à travers la fenêtre d'access, Conception de requête. Alors, pourquoi programmer en SQL? En voici quelques raisons D'importantes caractéristiques de SQL ne sont pas accessibles par l'intermédiaire de la fenêtre Conception de requête. Par exemple, il n'y a aucun moyen de créer une requête d'union, une requête secondaire ou une requête SQL transitoire (qui est une requête passant à travers un serveur externe de bases de données Access, tel que Microsoft SQL Server) en utilisant la fenêtre Conception de requête. Vous ne pouvez utiliser le composant DDL de SQL depuis la fenêtre Conception de requête. Pour utiliser ce composant, vous devez écrire les instructions SQL directement. SQL peut être utilisé depuis d'autres applications, telles que Microsoft Excel, Word et Visual Basic, pour employer le moteur Access SQL. SQL est le langage standard de requête des bases de données, et, comme tel, est utile en-dehors de l'environnement Microsoft Access. Malgré ces raisons importantes, nous vous suggérons de survoler les instructions SQL en première lecture, pour avoir une idée de leur mode de fonctionnement. Vous pourrez utiliser ensuite ce chapitre comme manuel de référence, chaque fois que vous aurez besoin d'écrire des instructions SQL vous-même. Par chance, SQL a relativement peu d'instructions, ce qui facilite la prise de contact avec le langage. Par exemple, SQL est orienté instruction simple. Il n'a pas de structures de contrôle telles que les boucles For... Next..., ni d'instructions conditionnelles telles que les instructions If...Then... L'utilisation de la fenêtre Conception de requête elle-même est un bon moyen d'apprendre SQL, car vous pouvez créer une requête dans la fenêtre Conception et passer ensuite dans la Vue SQL pour voir l'instruction SQL correspondante, obligeamment créée par Microsoft Access.

111 100 Chapitre 6 : Langage Access SQL Access SQL SQL est un langage non-procédural, ce qui signifie que les expressions SQL stipulent ce qui doit être fait, mais non comment cela doit être fait. Cela dispense le programmeur de se concentrer sur la logique du programme SQL. Le moteur de requête d'access prend en charge l'optimisation. Une manière d'expérimenter SQL est d'entrer une requête en utilisant la Vue conception et en permutant vers la Vue SQL pour voir comment Access rédige la requête SQL correspondante. Il convient de mentionner que le système d'aide fournit des informations complètes sur la syntaxe et les options de chaque instruction SQL. La lecture des définitions d'instructions SQL peut être pénible. Vous pouvez simplement survoler la syntaxe de chaque instruction puis vous reporter directement aux exemples sur le CD-Rom. L'objectif principal est de vous faire acquérir une bonne compréhension des instructions SQL et de ce qu'elles peuvent faire. Vous pourrez vous reporter à la syntaxe correcte d'une instruction si nécessaire (comme je le fais). Conventions sjntaxiques À l'examen des instructions SQL, il nous faudra utiliser une syntaxe cohérente. Nous allons employer les conventions suivantes Les mots en majuscules sont des mots-clé SQL, et ils doivent être tapés tels qu' écrits. Les mots en italique sont destinés à être remplacés par quelque chose d'autre. Par exemple, dans l'instruction CREATE TABLE TableName TableName doit être remplacé par le nom d'une table. Un item entre crochets [ ] est optionnel. Les accolades ({}) sont utilisées pour clarifier la syntaxe. Elles ne doiventjamais être incluses dans l'instruction proprement dite. Les parenthèses doivent être saisies comme dans les exemples. Le symbole ::= signifie "défini comme" et le symbole J signifie ou. Par exemple, la ligne TableElement ::= ColumnDefinition 1 TableConstraint

112 Le composant DDL d Access SQL 101 signifie qu'un élément de table est défini soit comme une définition de colonne, soit comme une contrainte de table. La syntaxe item,... signifie que l'on peut répéter un item autant de fois que l'on veut, avec la virgule comme séparateur. Par exemple, dans la ligne CREATE TABLE TableName (TableElement,...) vous pouvez répéter TableElement à volonté, car il n'est pas mis entre crochets, et n'est donc pas optionnel (les parenthèses doivent être mises). Si un groupe d'items peut être répété, on peut utiliser des accolades pour encadrer ces items (pour une meilleure lecture). Par exemple, l'expression suivante signifie que la clause ColName [ASC DESC] peut être répétée Notes Vous pouvez insérer des sauts de lignes dans une instruction SQL à n'importe quel endroit, ce qui est pratique pour augmenter la lisibilité. Chaque instruction SQL devrait se terminer par un point-virgule (bien qu' Access SQL ne l'exige pas). Si un nom de table (ou autre nom) contient un caractère que SQL considère comme illégal, le nom doit être placé entre crochets. Par exemple, le caractère slash est illégal dans SQL et ainsi le nom de table LIVRE/AUTEUR est illégal. C'est pourquoi il doit être placé entre crochets : [LIVRE/AUTEUR]. Il ne faut pas faire de confusion avec l'usage des crochets pour noter des items optionnels dans les descriptions SQL. Le composant DDL d Access SOL Commençons par jeter un regard aux instructions de définition de données dans Access SQL. Ces instructions n'ont pas de contrepartie dans la Vue conception de requête (bien que, naturellement, vous puissiez exécuter ces fonctions à travers l' environnement graphique d'access). Access SQL supporte les quatre instructions DDL suivantes

113 102 Chapitre 6: Lan'a'eAccess SIL Il faut mentionner ici qu'il existe une certaine duplication des caractéristiques dans les instructions DDL. Par exemple, vous pouvez ajouter un index à une table en utilisant soit l'instruction ALTER TABLE, soit l'instruction CREATE INDEX. Les paramètres de l'instruction CREATE TABLE sont un nom de table, suivi par une ou plusieurs définitions de colonnes, suivies par une ou plusieurs contraintes multicolonnes (optionnelles). À noter que les parenthèses font également partie de la syntaxe. I Définition de colonne Une définition de colonne est formulée ainsi Mot à mot, une définition de colonne - ColumnD finition - est un nom de colonne ColumnName -, suivi par un type de données - DataType - (avec indication de taille si nécessaire), suivi par une contrainte de colonne unique - Single-ColumnConstraint. Il y a plusieurs types de données disponibles dans Access SQL. Pour la comparaison, la liste à la table 6-2 inclut la sélection correspondante dans la fenêtre Access de conception de tables. Nous n'avons pas inclus tous les synonymes des types de données. Notez que le type INTEGER SQL correspond au type de données Long d'access. Notez aussi que l'option Site affecte seulement les champs TEXTE, indiquant la longueur du champ (s'il est omis, la longueur par défaut est de 255 caractères).

114 Le composant DDL d Access SQL 103 Table 6-2. Types de données Access SQL Types de données SQL BOOLEAN, LOGICAL, ou YES/NO BYTE ou INTEGERI COUNTER ou AUTOINCREMENT CURRENCY ou MONEY DATETIME, DATE ou TIME SHORT, INTEGER2 ou SMALLINT LONG, INT, INTEGER ou INTEGER4 SINGLE, FLOAT4 ou REAL DOUBLE, FLOAT, FLOAT8, NUMBER ou NUMERIC TEXT, ALPHANUMERIC, CHAR, CHARACTER ou STRING LONGTEXT, LONGCHAR, MEMO ou NOTE LONGBINARY, GENERAL ou OLEOBJECT GUID Type de champ Table Yes/No Nombre, Taille de champ = Byte Nombre auto, Taille de champ = Long Integer Monnaie Date/Heure Nombre, Taille de champ = Integer Nombre, Taille de champ = Long Nombre, Taille de champ = Single Nombre, Taille de champ = Double Texte Mémo Objet (OLE) Nombre auto, Taille de champ = Replication ID Contraintes Les clauses de contraintes peuvent être utilisées pour Désigner une clé primaire Désigner une clé étrangère, établissant une relation entre deux tables Déclarer qu'une colonne ne peut contenir que des valeurs uniques Dans SQL-92, ces clauses ont deux autres usages : interdire les valeurs NULL et restreindre les valeurs autorisées à une plage spécifiée. Il y a deux types de clauses de contraintes dans une instruction CREATE TABLE. La contrainte colonne unique est utilisée (comme suggéré par la syntaxe) à l'intérieur d'une définition de colonne. Sa syntaxe est La première option désigne la colonne comme clé primaire et crée un fichier index de nom IndexName sur cette colonne. La seconde option désigne la colonne comme

115 104 Chapitre 6 : Langage Access SQL clé (candidate) et crée un fichier index unique sur cette clé, sur le nom IndexName. La troisième option désigne la colonne comme clé étrangère qui référence les colonne(s) ReferencedColumn,... de la table ReferencedTable. La clause ReferencedColumn,... est optionnelle si la table référencée a une clé primaire, car cette dernière sera alors la clé de référence. Pour les contraintes multi-colonnes, la clause CONSTRAINT doit apparaître après toutes les définitions de colonnes et elle a la syntaxe Voici quelques exemples. Création du schéma de table Livres et du lien à Editeurs utilisant PubID comme clé étrangère Notes: L'instruction CREATE TABLE ne fournit aucun moyen de créer un index avec des valeurs non uniques. Ceci peut être fait, toutefois, en utilisant l'instruction CREATE INDEX. En spécifiant une clé étrangère, l'instruction CREATE TABLE active le module qui garantit l'intégrité référentielle, mais n'autorise pas l'option d'activation des mises à jour ou des suppressions en cascade. Dans ce cas, Access SQL présente une lacune par rapport à SQL-92, qui a une clause FOREIGN KEY autorisant le programmeur à spécifier ON UPDATE CASCADE et/ou ON DELETE CASCADE.

116 Le conmosant DDL d Access SOL 105 L instruction ALTER TAB T.F, L'instruction ALTER TABLE est utilisée pour Ajouter une nouvelle colonne à la table Supprimer une colonne de la table Ajouter ou supprimer des index simple- ou multi-colonnes La syntaxe de l'instruction ALTER TABLE est Comme vous pouvez le remarquer, les clauses de la contrainte Single- et MultaColumn ( voir définition plus haut) peuvent être utilisées ici pour ajouter ou supprimer ( DROP) un index. Notes Les nouvelles colonnes sont ajoutées au début de la table, suivant immédiatement les colonnes à clé primaire. Vous ne pouvez supprimer une colonne qui fait partie d'un index. L'index doit être enlevé préalablement en utilisant une instruction DROP CONSTRAINT (ou DROP INDEX). UNIQUE empêche les valeurs dupliquées dans l'index. WITH PRIMARY désigne la clé primaire et crée un fichier index primaire. Dans ce cas, le mot-clé UNIQUE est redondant. WITH DISALLOW NULL interdit les valeurs NULL dans la clé.

117 106 Chapitre 6 : Langage Access SQL WITH IGNORE NULL autorise les valeurs NULL dans la clé, mais ne les inclut pas dans le fichier index (en conséquence, elles seront ignorées dans toute recherche utilisant l'index). Note L'instruction CREATE INDEX est spécifique à Access SQL et ne fait pas partie de SQL-92 standard. L'instruction DROP La syntaxe de l'instruction DROP, qui est utilisée pour la suppression des tables et index, est Note. Une table doit être fermée avant d'être supprimée ou un index doit être extrait d'une table. Le composant DML de Access SOL Nous en venons maintenant au composant DML de SQL. Les instructions que nous allons aborder sont les suivantes SELECT UNION UPDATE DELETE INSERT INTO SELECT INTO TRANSFORM PARAMETER Avant d'aller à ces instructions, abordons un certain nombre de points importants. Requêtes de mise à jour Dans de nombreuses situations, une requête peut être mise à jour ; autrement dit, on peut éditer les valeurs dans la table résultat et les changements sont automatique

118 Le composant DML de Access SQL 107 ment répercutés dans les tables sous-jacentes. Les explications sur le fonctionnement interne de ces procédures sont plutôt compliquées; elles sont complètement détaillées dans le système d'aide d'access. Cette information n'est pas aisée à trouver, cependant vous pouvez la localiser à l'aide de l'assistant de recherche Access, en entrant "mise à jour des requêtes" et en choisissant "Déterminer quand je peux mettre à jour les données d'une requête". Jointures Commençons par un bref exposé sur la manière dont Access SQL décrit les jointures. Notons qu'une clause de jointure n'est pas une instruction SQL par ellemême, mais doit être placée à l'intérieur d'une instruction SQL. Jointures internes La clause INNER JOIN dans Access SQL décrit en fait une 9-jointure sur une ou plusieurs colonnes (voir l'exposé sur les jointures au chapitre 5, Langages de requête et l' algèbre relationnel). En particulier, la syntaxe est Jointures externes La syntaxe d'une clause de jointure externe est Jointures imbriquées Les instructions JOIN peuvent être imbriquées. Voici un exemple qui effectue la jointure des tables LIVRES, AUTEURS, EDITEURS, et LIVRE/AUTEUR et sélectionne alors les colonnes Titre, AuNom et PubNom. Nous avons indenté certaines lignes dans le but d'augmenter la lisibilité (nous allons décrire bientôt l' instruction SELECT).

119 108 Chapitre 6 : Langage Access SQL Pour voir comment cette instruction a été construite, il est utile de jeter un coup d' oeil aux relations entre les tables concernées. La figure 6-3 montre une partie de la fenêtre Access sur les relations entre tables. Figure 6-3. Une partie de la fenêtre des relations entre tables dans Access Une manière de créer l'instruction de jointure ci-dessus est de partir de centre de celle-ci. Premièrement, nous joignons LIVRES et LIVRE/AUTEUR par l'instruction (LIVRES INNER JOIN [LIVRE/AUTEUR] ON LIVRES.ISBN=[LIVRE/AUTEUR].ISBN) Ensuite, nous joignons ceci à EDITEURS sur la colonne PubID et pour finir, nous joignons ceci à AUTEURS sur la colonne AuID. Auto jointures Une table peut faire l'objet d'une jointure sur elle-même, donnant une auto-jointure. Pour y arriver, SQL requiert l'utilisation de la syntaxe AliasName. Par exemple, nous pouvons écrire La manière la moins déroutante d'aborder cette instruction est d'imaginer qu'access crée une seconde copie de la table LIVRES et l'appelle LIVRES2. Dès lors, nous pouvons nous référer aux colonnes de LIVRES comme LIVRES. ColumnName ou LIVRES2.ColumnName.

120 Le composant DML de Access SQL 109 Notes: Une jointure externe peut être imbriquée dans une jointure interne, mais une jointure interne ne peut être imbriquée dans une jointure externe. Il est possible d'utiliser des expressions Access, mettant en oeuvre des fonctions (telles que Left,$', Len, Trim$ et Instr), dans les instructions SQL (même si la syntaxe "officielle" ne le décrit pas). Dans Access, nous pouvons définir des relations entre des tables. Toutefois, ces relations n'ont aucun effet sur les instructions SQL. Ainsi, une instruction INNER JOIN n'exige pas qu'une relation existe préalablement entre les tables concernées. Les relations sont utilisées dans la Vue conception et se transforment en instructions INNER JOIN. Par exemple, si nous ajoutons LIVRES et EDITEURS à la fenêtre Conception de requêtes, si nous déplaçons Titre et PubNom vers la grille de conception et ensuite si nous visionnons la Vue SQL correspondante, nous verrons une clause INNER JOIN dans l'instruction SQL. L'instruction SET,F,C,`1' L'instruction SELECT est le cheval de labour des instructions SQL (comme vous pourrez en juger en raison de la longueur de notre exposé sur cette instruction). L' instruction retourne une table et peut exécuter les opérations d'algèbre relationnel sélection et projection. La syntaxe de l'instruction SELECT est Décrivons les divers composants de cette instruction. Nous notons immédiatement que le mot-clé SELECT est dans une certaine mesure malheureux, car il évoque l' opération de projection de l'algèbre relationnel, et non l'opération de sélection C' est la clause WHERE qui réalise la sélection. Predicats Le prédicat est utilisé pour décrire le traitement des lignes doublonnées en retour. Il peut prendre l'une des values suivantes: ALL, DISTINCT, DISTINCTROW, ou TOP. L'option (par défaut) ALL retourne toutes les lignes spécifiées, y compris les doublons. S'il y a plus d'une ligne spécifiée avec les mêmes valeurs dans toutes les

121 110 Chapitre 6 : Lan_aq Access S9L colonnes requises dans ReturnColumnDescription, le prédicat DISTINCT retourne seulement la première de ces lignes. Les options ou retournent le nombre (ou pourcentage) de lignes dans l'ordre de tri déterminé par la clause ORDER BY. Le prédicat DISTINCTROW pouvant prêter à confusion, voyons si nous pouvons en corriger le sens. Le système d'aide d'access dit que le prédicat DISTINCTROW "omet les données basées sur les enregistrements entièrement dupliqués, et non sur les champs dupliqués." Il ne dit rien du mode opératoire. Microsoft Technet est un petit peu moins vague sur le sujet Par contraste, DISTINCTROW est propre à Microsoft Access. Il (le prédicat) force une requête à ne retourner que les enregistrements ayant des valeurs uniques. Par exemple, si 10 clients ont pour nom Jones, une requête basée sur l'instruction SQL " SELECT DISTINCTROW Nom FROM Clients" retourne les 10 enregistrements ayant Jones dans le champ Nom. La raison principale de l'ajout du mot réservé DISTINCTROW à Microsoft Access SQL est le support de la mise à jour des semijointures, telles que les jointures de type un-à-plusieurs dans lesquelles les champs de sortie proviennent tous de la table sur le côté "un". L'option DISTINCTROW est spécifiée par défaut dans les requêtes Microsoft Access et est ignorée dans les requêtes où elle est sans effet. Il est conseillé de ne pas effacer le mot réservé DISTINCTROW dans la boîte de dialogue SQL. Le but avoué de DISTINCTROW est simple. DISTINCTROW s'applique seulement lorsque la clause FROM implique plus d'une table. Considérons cette instruction Comme il existe de nombreux livres publiés par le même éditeur, la table résultat tbiall illustrée à la table 6-3 a de nombreuses duplications du nom de l'éditeur. Table 6-3. La table tblall PubNom Small House Small House

122 Le composant DML de Access SOL 111 Table 6-3. La table tb/all PubNom Small House Small House Big House Big House Big House Big House Big House Big House Alpha Press Alpha Press Alpha Press Alpha Press Pour éliminer ces doublons, nous pouvons inclure le mot-clé DISTINCT. D'où l' instruction SELECT DISTINCT PubNom FROM EDITEURS INNER JOIN LIVRES ON EDITEURS.PubID = LIVRES.PubID; qui retourne la table tb1distinct, présentée à la table 6-4. Table 6-4. La table tb/distinct PubNom Alpha Press Big House Small House Examinons ce qui se passe si la table EDITEURS est modifiée par addition d'un nouvel éditeur ayant le même nom qu'un éditeur existant (mais un PubID et un numéro de téléphone différents), comme à la table 6-5. La précédente instruction DISTINCT donnera la même table résultat qu'auparavant, laissant de côté le nouvel éditeur. Table 6-5. La table EDITE URS (modifiée) PublD PubNom PubPhone 1 Big House Alpha Press

123 112 Chapitre 6 : Langage Access SQL Table 6-5. La table EDI1 E URS (modifiée) (suite) POID PON= PubPhone 3 Small House Small House Nous avons besoin d'un critère de sélection qui va retourner les deux noms d' éditeurs simplement parce qu'ils viennent de lignes différentes de la table EDITEURS. C'est le but de DISTINCTROW. Ainsi, l'instruction produit la table résultat tb1distinctrow illustrée à la table 6-6 (nous avons dû également ajouter un livre à la table LIVRES, avec PubID 4). Table 6-6. La table tbidistinci ROW PubNom Small House Big House Alpha Press Small House Nous pouvons décrire maintenant le fonctionnement de DISTINCTROW. Considérons le squelette SQL suivant Ici, ColumnsRequested est une liste de colonnes exigée par l'instruction et TablesClause est une jointure de tables. Désignons une table mentionnée dans TablesClause sous le nom de table retour si au moins l'une de ses colonnes est mentionnée dans quested. Ainsi, dans l'instruction EDITEURS est une table retour mais LIVRES ne l'est pas. Voici comment DISTINCTROW fonctionne dans ce cas

124 Le composant DML de Access SQL Forme la jointure décrite dans TablesClause. 2. Projette la table résultante sur toutes les colonnes de toutes les tables retour (et pas seulement les colonnes demandées). Autrement dit, enlève toutes les colonnes qui ne font pas partie d'une table retour. 3. Enlève toutes les lignes doublonnées, deux lignes étant considérées comme doublonnées si elles sont composées de lignes identiques provenant de chaque table résultat. Ce ne sont pas les valeurs qui sont comparées, mais bien les lignes réelles. Il est nécessaire d'ajouter cette précision, car deux lignes différentes peuvent avoir des valeurs identiques dans une table Access. Prenons un exemple simple pour illustrer le propos. Considérons les tables suivantes A, al a2 a3 A 2 link link B2 B3 b1 y z b2 link link2 C2 C3 cl t hnk2 c2 link2 c3 a x l'instruction A l A2 B2 B3 C2 C3 a3 link b2 link hnk2 c2 v lin 2 a3 link b2 link link2 cl t 1 k2

125 114 Chapitre 6 : Langage Access S L Al A2 B 1 B2 B3 C2 C3 a2 link b2 link hnk2 c2 v lin 2 a2 link b2 hnk li 2 c1 t hnk2 Ajoutons maintenant le mot-clé DISTINCTROW et sélectionnons une colonne unique à partir de tbla SELECT DISTINCTROW Al FROM (Tempt INNER JOIN Temp2 ON Tempi.A2 = Temp2.B2) INNER JOIN Temp3 ON Temp2.B3 = Temp3.C3; Considérons la projection sur les lignes de la seule table retour (tbla) A, A 2 a3 link a3 link a2 link a link Il est clair que les deux premières lignes de cette table sont les mêmes que les deux premières lignes de tbla, de sorte qu'il n'y a plus qu'une ligne dans la table résultat finale. Ceci s'applique aux deux dernières lignes. La table résultat est donc A l a2 a3 Introduisons un changement en demandant une colonne de tb1c, faisant de celle-ci une table retour par la même occasion La projection sur les lignes de la table retournée est A 2 C 2 a3 hnk c2 v hnk2 a3 hnk c1 t hnk2 a2 link c2 hnk2 a2 link c1 t hnk2

126 Le composant DML de Access SQL 115 Ces "paires" de lignes sont toutes distinctes. En fait La ligne 1 provient de la ligne 1 de tbla et de la ligne 2 de tb1c La ligne 2 provient de la ligne 1 de tbla et de la ligne 1 de tblc La ligne 3 provient de la ligne 2 de tbla et de la ligne 2 de tblc La ligne 4 provient de la ligne 2 de tbla et de la ligne 1 de tb1c Il s'en suit que la table retournée inclut toutes les lignes C1 a2 a2 a3 a3 cl c2 cl c2 Finalement, considérons ce qui se passe si nous modifions la troisième ligne de tbla en A 2 al a2 a2 x link link Le lancement de l'instruction DISTINCTROW donne: A l a2 a2 Si l'on compare ceci à la précédente table résultat, DISTINCTROW Al souligne le fait que, même si la seconde et la troisième lignes de tblnewa contiennent des valeurs identiques, ce sont des lignes distinctes, et elles intègrent toutes deux la table résultat finale. Si nous devions remplacer le mot-clé DISTINCTROW par le mot DISTINCT, la table résultat n'aurait seulement qu'une ligne, car dans ce cas, ce sont les valeurs de chaque ligne qui forment la base de la comparaison.

127 116 Chapitre 6 : Langage Access SQL Naturellement, ceci ne serait pas un problème si toutes les tables avaient une clé, car les valeurs d'une ligne la détermineraient de façon unique. Vous voyez pourquoi, il y a quelque temps, nous avons argumenté contre la présence de deux lignes différentes contenant des données identiques, même si Access permet cette possibilité ( mais les véritables bases de données relationnelles ne le permettent pas). Notez ce qui se passe si toutes les tables mentionnées dans TablesClause sont des tables retour. Ceci peut survenir, par exemple, s'il y a seulement une table dans TablesClause. Dans ce cas, la projection ne fait rien et comme chaque ligne de la table résultat TablesClause doit provenir d'une combinaison distincte de lignes de la table résultats, nous déduisons que DISTINCTROW a exactement le même effet que ALL, ou, pour l'exprimer d'une autre manière, que DISTINCTROW est ignorée. Il est utile de comparer DISTINCTROW et DISTINCT. Nous remarquons que la seule différence est qu'une instruction DISTINCT retournera des valeurs distinctes, plutôt que des valeurs provenant de lignes distinctes. Cependant, ce seront les mêmes si les colonnes requises de chaque table retour identifient leurs lignes de manière unique. Illustrons ceci à l'aide de l'exemple EDITEURS. Supposons que nous retournons une clé (PubID) pour EDITEURS, comme dans l'instruction Alors la table résultats retournera toutes les lignes EDITEURS qui ont au moins un livre dans la table LIVRES, comme le montre la table 6-7. Table 6-7. Editeurs ayant au moins un ouvrage dans LIVRES PubID PubNom 3 Small House 1 Big House 2 Alpha Press 4 Small House C'est en fait la semi-jointure EDITEURS semi joinediteurs.pubid=livres.pubid LIVRES Souvenez-vous qu'une semi-jointure est la projection de la jointure sur l'une des tables (dans ce cas, la table EDITEURS). Ainsi, comme le dit Microsoft, le but du

128 Le composant DML de Access SQL 117 prédicat DISTINCTROW est de retourner une semi-jointure pouvant être mise à jour Naturellement, la même instruction avec DISTINCT à la place de DISTINC- TROW retournera la même table résultat. Cependant, il y a une grande différence. Comme les instructions DISTINCT peuvent dissimuler complètement l'origine des valeurs retournées, ce serait un désastre si Access autorisait la mise à jour d'une table résultat-et en réalité, il ne le fait pas. Par exemple, rappelons la table tbidis- TINCT vue précédemment et montrée à la table 6-8. Table 6-8. La table tb/distincl PubNom Alpha Press Big House Small House Modifier le nom de Small House dans cette table résultat serait désastreux, car nous ne saurions plus quel Small House a été concerné! Par ailleurs, la table résultat de l'instruction DISTINCTROW a un "représentant" de chaque ligne de la table EDITEURS, comme le montre la table 6-9. Par suite, tandis qu'un changement de cette table particulière ne semble pas être une bonne idée (nous ne pouvons pas dire qui est qui à propos de Small House), il serait raisonnable d'effectuer un changement aux deux noms, par exemple. Table 6-9. La table tb/distinci'row Pub m Small House Big House Alpha Press Small House Plus généralement, Access ne permet pas la mise à jour de la table résultat d'une instruction DISTINCT, mais il permet la mise à jour de la table résultat d'une instruction DISTINCTROW. Finalement, mentionnons que Microsoft Access inclut le mot-clé DISTINCTROW par défaut lorsque vous créez une requête en utilisant la fenêtre Conception de requête d'access.

129 118 Chapitre 6 : Langage Access SQL ReturnColumnDescriplion ReturnColumnDescription décrit les colonnes, ou combinaisons de colonnes, à retourner. La description peut prendre l'une des formes suivantes * (indique toutes les colonnes) Le nom d'une colonne Une expression comprenant les noms de colonne, mise entre crochets, avec des chaînes de caractères et des opérateurs; par exemple, [PubID] & "-" & [Titre] Notez que, conformément à la syntaxe de l'instruction SELECT, ReturnColumnDescription peut être répété autant de fois que l'on veut. Lorsque deux colonnes retournées (de différentes tables) ont le même nom, il est nécessaire de qualifier les noms de colonne en utilisant les noms de tables. Par exemple, pour qualifier la nom de la colonne PubID, nous écrivons LIVRES.PubID et EDITEURS.PubID. Nous pouvons aussi écrire LIVRES.* pour indiquer toutes les colonnes de la table LIVRES. Finalement, chaque ReturnColumnDescription peut se terminer par [AS AliasName] pour donner à la colonne retour un (nouveau) nom. Par exemple, l'instruction suivante: retourne une table résultat ISBN-PUB à une colonne, comme le montre la table Table La table ISBN-PUB ISBN de PubNom de Small House de Small House de Small House de Small House de Big House de Big House de Big House de Big House

130 Le composant DML de Access SIL 119 Table La table ISBN-PUB (suite) ISBN de PubNom de Big House de Big House de Alpha P ess de Alpha Press de Alpha Press de Alpha Press Non seulement, le mot-clé AS AliasName permet de désigner une "colonne composée" comme ci-dessus, mais permet aussi de renommer les noms de colonnes dupliquées sans avoir à qualifier ces noms. La clause FROM TableE.xpression La clause FROM spécifie les tables (ou requêtes) dont l'instruction SELECT extrait ses lignes. L'expression TableExpression peut être un nom de table unique, plusieurs noms de tables séparés par des virgules, ou une clause de jointure. L'expression TableE.vpression peut inclure également la syntaxe AS AliasName pour les tables sans alias. Lorsque les tables sont séparées par des virgules dans la clause FROM, un produit cartésien est formé. Par exemple, l'instruction produira le produit cartésien des deux tables. L'expression RowCondition est toute expression Access qui spécifie les lignes incluses dans la table résultat. Les expressions peuvent comporter des noms de colonne, constantes, comparaisons (_, <, >, <_, >_, <>, BETWEEN), des relations ( AND, OR, XOR, NOT, IMP) et des fonctions. Voici quelques spécimens

131 I 120 SQL Chapitre 6 : Langage Access Notez que les dates sont placées entre les signes (#) et que les chaînes sont placées entre guillemets (" '). La clause GROUP BY GroupByCriteria La clause GROUP BY autorise le regroupement d'enregistrements dans le but de calculer la valeur d'une fonction agrégée (Avg, Count, Min, Max, Sum, First, Last, StDev, StDevP, Var, et VarP). L'opération est équivalente à la création d'une requête de totaux. L'option GroupByCriteria peut contenir les noms de dix colonnes maximum. L' ordre des noms de colonne détermine les niveaux de regroupement, du plus haut vers le plus bas. Par exemple, l'instruction suivante liste chaque éditeur par nom, avec le prix minimum des livres de chaque éditeur de la table LIVRES: SELECT EDITEURS.PubNom, MIN(Prix) AS [ PrixMinimum] FROM EDITEURS INNER JOIN LIVRES ON EDITEURS.PubID = LIVRES.PubID GROUP BY EDITEURS.PubNom; La table résultat apparaît à la table Table Livre le moins cher de chaque éditeur PON= PrixMinimum Alpha Press $12.00 Big House $15.00 Small House $22.95 La clause HAVING GroupCriteria La clause HAVING est utilisée en relation avec la clause GROUP BY et permet de spécifier un critère, en termes de fonctions agrégées, pour décider des données à afficher. Par exemple, l'instruction suivante est la même que la précédente, avec la clause supplémentaire HAVING qui limite la table retour aux éditeurs dont le prix minimum est inférieur à $20.00

132 Le composant DML de Access SOL 61 La table résultat est présentée à la table Table Livre le moins cher de chaque éditeur en-dessous de.$20.00 PubNom PrixMinimum Alpha Press $12.00 Big House $15.00 Notez que la clause WHERE restreint les lignes participant au regroupement, et donc contribue à la valeur des fonctions agrégées, tandis que la clause HAVING n'affecte que les valeurs qui sont affichées. La clause ORDER BY OrderByCriteria La clause ORDER BY décrit la succession selon laquelle les lignes doivent être retournées dans la table retour. OrderByCriteria a la forme OrderByCriteria ::= {NomColonne [ASC I DESC J},... En d'autres termes, c'est juste une liste de colonnes à utiliser dans la succession. Les lignes sont triées d'abord selon la première colonne listée, ensuite les lignes de valeur identique dans la première colonne sont triées selon les valeurs de la seconde colonne, et ainsi de suite. L'opération UNION L'opération UNION est utilisée pour créer l'union de deux ou plusieurs tables. La syntaxe est: où Query est soit une instruction SELECT, le nom d'une requête stockée ou le nom d'une table stockée, précédée par le mot-clé TABLE. L'option ALL force Access à inclure tous les enregistrements. Sans cette option, Access n'inclut pas les lignes dupliquées. L'utilisation de ALL améliore les performances et est ainsi recommandée même lorsqu'il n'y a pas de lignes doublonnées. Exemple L'instruction suivante réalise l'union de toutes les lignes de LIVRES et des lignes de NEWLIVRES qui satisfont Prix > $25.00 et trie la table résultat par titre

133 122 Chapitre 6 : Lan62a2e Access SQL Notes. Toutes les requêtes dans une opération UNION doivent retourner le même nombre de champs. Cependant, les champs n'ont pas besoin d'avoir la même taille ou type de données. Les colonnes sont combinées dans l'union selon leur ordre dans la clause de requêtes et non par leur nom. ALIAS peut être utilisé dans la première instruction SELECT (s'il y en a une) pour modifier les noms de colonnes retournées. Une clause ORDER BY peut être utilisée à la fin de la dernière requête pour ordonner les données retournées. Elle utilise les noms de colonnes de la première requête. Les clauses GROUP BY et/ou HAVING peuvent être utilisées dans chaque argument de requête pour grouper les données retournées. La table résultat d'une UNION ne peut pas être mise à jour. UNION ne fait pas partie de SQL-92. L'instruction UPDATE L'instruction UPDATE est équivalente à une requête Update et est utilisée pour mettre à jour les données dans une ou plusieurs tables. La syntaxe est La clause WHERE est utilisée pour limiter la mise à jour aux lignes spécifiées. Exemple L'exemple suivant met à jour la colonne Prix dans la table LIVRES avec de nouveaux prix provenant d'une table appelée NOUVPRIX ayant une colonne ISBN et une colonne Prix

134 Le composant DML de Access SQL 123 UPDATE ne fournit pas de table résultat. Pour déterminer quelles lignes seront mises à jour, lancez d'abord la requête SELECT correspondante, comme dans L'instruction DE I.F,TE L'instruction DELETE est équivalente à une requête Delete et est utilisée pour supprimer des lignes d'une table. Voici la syntaxe Criteria est utilisé pour déterminer quelles lignes supprimer. Cette instruction peut être utilisée pour effacer toutes les données d'une table, mais elle n'efface pas la structure de la table. Utilisez DROP dans ce but. Vous pouvez utiliser DELETE pour éliminer des enregistrements de tables qui ont une relation de type un-à-plusieurs. Si la suppression en cascade est activée lorsque vous supprimez une ligne du côté «un» de la relation, toutes les lignes liées sont supprimées du côté «plusieurs». L'action de l'instruction DELETE est irréversible. Faites toujours des sauvegardes avant d'effacer! Vous pouvez lancer une requête SELECT avant DELETE pour voir quelles lignes seront affectées par cette dernière. L'instruction INSERT INTO L'instruction INSERT INTO est conçue pour insérer de nouvelles lignes dans une table. Ceci se fait en spécifiant les valeurs d'une nouvelle ligne utilisant la syntaxe Si vous ne spécifiez pas FieldName(s), vous devez inclure alors des valeurs pour chaque champ dans la table. Examinons des exemples d'instruction INSERT INTO. La déclaration suivante insère une nouvelle ligne dans la table LIVRES

135 I 124 Chapitre 6 : Lan2a2e Access SOL La déclaration suivante insère une nouvelle ligne dans la table LIVRES. Les colonnes Prix et PubID ont des valeurs NULL. Pour insérer plusieurs lignes, on utilise cette syntaxe Dans les deux syntaxes, Target est le nom de la table ou requête dans laquelle des lignes doivent être insérées. Dans le cas d'une requête, celle-ci doit pouvoir être mise à jour et toutes les mises à jour doivent se répercuter dans les tables sous-jacentes. TableExpression est le nom de la table fournissant les enregistrements qui sont insérés ou le nom d'une requête sauvegardée ou une instruction SELECT. Admettons que NEWLIVRES est une table de trois champs : ISBN, PubID, et Prix. L' instruction suivante insère des lignes de LIVRES dans NEWLIVRES. Elle insère uniquement les livres dont Prix > $ Note Les valeurs de champ texte doivent être placées entre (" "). L'instruction SET.F,C - 1'... INTO L'instruction SELECT... INTO est équivalente à la requête MakeTable. Elle crée une nouvelle table et insère des données d'autres tables. La syntaxe est FieldName est le nom du champ à copier dans la nouvelle table. Source est le nom de la table d'où proviennent les données. Cela peut être aussi le nom d'une instruction de requête ou de jointure. Par exemple, l'instruction suivante crée une nouvelle table appelée LIVRESCHERS et inclut les livres de la table LIVRES qui valent plus de $45.00

136 Le composant DML de Access SQL 123 Notes: Cette instruction est propre à Access SQL. Cette instruction ne crée pas d'indices dans la nouvelle table. L'instruction TRANSFORM L'instruction TRANSFORM (qui ne fait pas partie de SQL-92) est conçue pour créer des requêtes croisées. La syntaxe de base est la suivante La fonction AgvregateFunction est l'une des fonctions d'agrégation d'access (A vg, Count, Min, Max, Sum, First, Last, StDev, StDevP, Var, et VarP). La colonne Column- Headings-Column est la colonne qui est pivotée pour fournir les en-têtes de colonnes de la table résultat à double entrée. La valeur Values dans la clause IN spécifie des entêtes de colonnes fixes. L'instruction SelectStatement est une instruction Select qui utilise la clause GROUP BY, avec quelques modifications. En particulier, l'instruction Select doit avoir au moins deux colonnes GROUP BY et pas de clause HAVING. Comme exemple, supposons que nous voulions afficher le nombre total de livres de chaque éditeur par prix. L'instruction SELECT dont la table résultat est présentée à la table 6-13, ne donne pas en réalité l'information dans la forme désirée. Par exemple, il est difficile de dire combien de livres coûtent $20.00 (rappel : cette petite table est juste pour l'exemple). Table Prix des livres par éditeur PubNom Prix Total Big House $ Big House $

137 126 Chapitre 6 : LanRaRe Access SQL Table Prix des livres par éditeur (suite) PubNom Prix Total Big House $ Big House $ Medium House $ Medium House $ Medium House $ Medium House $ Small House $ Nous pouvons la transformer en une table à double entrée en deux étapes 1. Ajouter une clause TRANSFORM au début et déplacer la fonction d'agrégat dont la valeur doit être calculée dans cette clause. 2. Ajouter une ligne PIVOT à la fin et déplacer la colonne dont les valeurs vont constituer les en-têtes de colonne de cette clause, et effacer la référence à cette colonne dans la clause SELECT. Cela donne avec la table résultat représentée à la table Table Tabulation croisée de Livres-Prix par éditeur Prix Big House Medium House Small House $ $ $ $ $ $ Nous pouvons grouper les lignes par valeurs dans plus d'une colonne. Par exemple, supposons que la table LIVRES a également une colonne DISCOUNT qui donne

138 Le comtosant DML de Access SOL 127 la remise appliquée sur le prix normal du livre (en pourcentage). En incluant la colonne DISCOUNT dans les clauses SELECT et GROUP BY, nous obtenons ce qui donne la table résultat présentée à la table Table Prix des livres et remise par éditeur Prix Discount Big House Medium House Small House $ % 2 $ % 1 $ % 1 $ % 1 $ % 1 $ % 1 $ % 1 $ % 1 $ % 1 1 Dans ce cas, chaque ligne représente une paire unique prix/remise. Un croisement peut inclure également des regroupements de lignes supplémentaires par addition de fonctions d'agrégation à la clause SELECT, comme suit ce qui donne la table résultat illustrée à la table Table Résultats agrégés dans une table à double entrée Prix Nombre Somme Big House Medium House Small House $ $ $ $ $ $ $ $

139 128 Table Résultats agrégés dans une table à double entrée (suite) Prix Nombre Somme Big House Medium House Small House $ $ $ $ Finalement, en incluant des noms de colonnes fixes, nous pouvons réordonner ou omettre des colonnes de la table résultat à double entrée. Par exemple, la déclaration suivante est identique à la précédente, à l'exception de la clause PIVOT La table résultat est présentée à la table À noter que l'ordre des colonnes a été modifié et que Big House n'est pas affiché. Table Omission de colonnes dans une table à double entrée Prix Nombre Somme Small House Medium House $ $ $ $15.00 $ $ $ $50.00 $ $ $ $ Requêtes secondaires SQL permet l'utilisation d'instructions SELECT au sein des instructions suivantes Autres instructions SELECT Instructions SELECT...INTO Instructions INSERT...INTO Instructions DELETE Instructions UPDATE L'instruction SELECT interne est qualifiée de requête secondaire et est généralement utilisée dans la clause WHERE de la requête principale.

140 69 Chapitre 6 : Langage Access SQL Le composant DML de Access SOL 129 La syntaxe d'une requête secondaire prend trois formes possibles, décrites ci-après. dans laquelle Comparison est une expression suivie par une relation de comparaison qui compare l'expression avec la valeur retournée par la requête secondaire. Cette syntaxe est utilisée pour comparer une valeur à celles obtenues depuis une autre requête. Par exemple, l'instruction suivante retourne tous les titres et prix de livres de la table LIVRES, dont les prix sont supérieurs au prix maximum des livres de la table LIVRES2 Puisque la requête secondaire retourne une seule valeur, il n'est pas nécessaire d'utiliser les mots-clé ANY, SOME ou ALL. L'instruction suivante sélectionne tous les titres de LIVRES et les prix des livres plus onéreux que TOUS les livres publiés par Big House Remarquons que ANY et SOME ont le même sens et retournent tous les choix qui valident la comparaison pour au moins une valeur retournée par la requête secondaire. Par exemple, si nous remplaçons ALL par SOME dans l'exemple précédent, la table retournée comprendra tous les titres et les prix des livres qui sont plus chers que le meilleur marché des livres publiés par Big House. Cette syntaxe est utilisée pour consulter une valeur de colonne dans la table résultat d'une autre requête. Par exemple, la déclaration suivante retourne tous les titres de la table LIVRES qui n'apparaissent pas dans la table LIVRES2

141 Syntaxe 3 [NOT] EXISTS (SQLStatement) Cette syntaxe est utilisée pour vérifier si un item existe (si retourné) dans la requête secondaire. Par exemple, la déclaration suivante sélectionne tous les éditeurs qui n'ont pas de livres dans la table LIVRES Remarquons que la table EDITEURS est référencée dans la requête secondaire. Ceci force Access à évaluer la requête secondaire de nouveau pour chaque valeur de EDITEURS.PubID dans la table EDITEURS. Notes Lors de l'utilisation des Syntaxes 1 ou 2, la requête secondaire doit retourner une seule colonne sinon il y a déclenchement d'une erreur. L'instruction SELECT qui constitue la requête secondaire obéit au même format et aux mêmes règles que toute instruction SELECT. Toutefois, elle doit être placée entre parenthèses. Paramètres Access SQL permet l'utilisation de paramètres pour obtenir une information de l' utilisateur lorsque la requête est lancée. La ligne PARAMETERS doit être la première ligne de l'instruction et obéir à la syntaxe suivante Un exemple va illustrer la technique. La déclaration suivante demande à l'utilisateur de fournir une portion du titre d'un livre, et retourne tous les livres de LIVRES comportant cette chaîne dans le titre. À noter le point-virgule à la fin de la ligne PARAMETERS.

142 71 Chapitre 6 : Langage Access SQL Sur le CD-ROM 131 SELECT* FROM LIVRES WHERE Instr(Titre, [Entrer une portion du titre:]) > 0; La fonction Instr(Textl,Text2) retourne la première localisation de la chaîne texte Text2 à l'intérieur de la chaîne texte Textl. Notez que Name est répété dans la clause WHERE et sera rempli par la valeur que l'utilisateur entre en raison de l'apparition de Name dans la clause PARAMETERS. Sur le CD-ROM Les exemples de ce chapitre se trouvent placés dans différents documents. Pour les consulter, lancez le document d'orientation à l'adresse suivante : l exemples/ chap06/ chapo6.htm. La structure d'exposition des exemples et des exercices suit la structure du chapitre et est partagée en quatre thèmes Conception et types de requêtes Access Conception et types de requêtes SQL Utilisation des instructions du composant DDL d'access SQL Utilisation des instructions du composant DML d'access SQL La base libray.mdb est spécifique de ce chapitre : elle contient plusieurs des requêtes décrites dans le texte. Il est préférable de lancer cette version pour lancer les requêtes soit depuis la vue Conception de requêtes d'access, soit depuis la vue SQLAccess.

143 Dans ce chapitre Pourquoi programmer? Systèmes de bases de données Systèmes de gestion de bases de données Le système Jet DBMS Langages de définition de données Langages de manipulation de données Langages hôte Architecture ckent/serveur Sur le CD-Rom Architecture d'un système de base de données Pourquoi programmer? Il ne fait aucun doute que SQL est un langage puissant-tel qu'il est. Cependant, c'est un langage peu convivial et il lui manque les structures de contrôle sophistiquées comme les boucles For...Next... et les déclarations If..Then...présentes dans des langages plus traditionnels. Ce n'est pas réellement un problème, car SQL est conçu dans un but très spécifique, en relation avec la création et la manipulation de composants de bases de données. SQL n'a pas été conçu pour fournir un environnement de programmation pour Microsoft Access lui-même. Ce rôle est joué par Visual Basic pour Applications, ou VBA. VBA est le macro-langage, ou langage de script, de toutes les applications majeures Microsoft Office : Microsoft Access, Excel, PowerPoint et Word (à partir de la version Word 97). C'est un langage de programmation puissant qui donne au programmeur accès à l'ensemble des fonctionnalités de ces applications, de même qu' aux ressources leur permettant de travailler ensemble. L'une des caractéristiques majeures de VBA est son support du modèle DAO (Data Access Objects model). DAO est l'interface du langage de programmation pour le système jet DBMS (Database management system) sous-jacent à Microsoft Access. Il offre un langage de définition de données (DDL) plus ou moins orienté objet et un langage de manipulation de données (DML), permettant ainsi au programmeur VBA de définir la structure d'une base de données et de manipuler ses données. 133

144 134 Chapitre 7: Architecture d'un s stème de base de données Il est naturel de vous demander pourquoi vous voudriez utiliser DAO, et VBA en général, plutôt que l'interface graphique intégrée à Microsoft Access. La réponse est simple. Tandis que l'interface graphique est très facile à utiliser, et tout à fait adaptée pour de nombreuses tâches, elle manque simplement de puissance par rapport à un langage de programmation. Le créateur de bases de données gagne plus de puissance et de souplesse en manipulant directement les objets basiques de la base de données (tels que tables, requêtes, relations, index, etc.) par la programmation. Prenons un exemple simple. Il n'y a aucun moyen d'obtenir la liste des champs d'une table donnée (c-à-d, le schéma de table de la table) en utilisant l'interface graphique d' Access. Par contre, c'est relativement simple en utilisant des techniques de programmation. Le court programme suivant affiche la liste ci-après des champs de la table LIVRES dans la fenêtre Debug C'est la place idéale pour examiner les relations entre DAO et SQL. Le fait est que le modèle DAO utilise SQL et s'en affranchit en même temps. En d'autres termes, de nombreuses commandes de DAO peuvent accepter une instruction SQL comme argument. Par exemple, le code VBA suivant ouvre un jeu d'enregistrements ( examiné plus loin dans ce livre) en utilisant une instruction SQL pour définir les enregistrements dans le jeu D'autre part, DAO s'affranchit de SQL dans le sens où de nombreuses actions peuvent être exécutées en utilisant indifféremment l'un ou l'autre de ces langages.

145 Systèmes de bases de données 135 Ainsi, une table peut être crée en utilisant au choix l'instruction SQL CREATE TABLE ou la méthode DAO CreateTable. Le choix appartient au programmeur. Notre objectif principal dans la partie restante de ce livre est d'aborder le modèle DAO. Avant de commencer, nous devons planter le décor en abordant l'architecture d'un système de gestion de bases de données en général et celle du système jet DBMS en particulier, de manière à placer DAO dans son véritable contexte. C'est ce que nous allons faire dans ce chapitre, et en jetant également un rapide coup d' œil à la programmation DAO. Au chapitre 8, Les bases de la programmation en VBA, nous présenterons une brève introduction à la programmation en Visual Basic pour Applications. Puis nous aborderons DAO lui-même dans les chapitres suivants du livre. Systèmes de bases de données Un ystème de base de données est souvent décrit comme une structure à trois niveaux, ainsi que le montre la figure 7-1. Figure 7-1. La structure à trois niveaux d'un système de base de données Au niveau inférieur de la structure est la base de données physique, qui contient les données brutes existant sur un objet physique tel qu'un disque dur. À ce niveau, les données n'ont aucune signification logique, par rapport à la base de données.

146 136 Chapitre 7: Architecture d'un système de base de données Cependant, elles ont une structure physique rigide, pour permettre des accès efficaces. Autrement dit, les données représentent plus qu'une simple suite d'octets. En fait, il y a une grande variété de structures grâce auxquelles les données peuvent être stockées, y compris dans des tables hash, des arborescences équilibrées, des listes liées, des enregistrements imbriqués. Le choix d'une structure pour les données n' est donc pas une chose simple. Toutefois, nous ne poursuivrons pas la discussion sur les bases de données physiques dans ce livre. Qu'il suffise de dire que les données sont vues, au niveau physique, comme une collection structurée de bits et que le seul but de la structure est d'assurer un accès efficace aux données. Le niveau physique d' une base de données est souvent qualifié de niveau interne. La base de données conceptuelle est une vue conceptuelle de la base de données dans son ensemble. Elle donne aux données une structure logique. Par exemple, dans un système de bases de données relationnelles, les données sont vues comme une collection de tables, avec des en-têtes de colonnes décrivant les attributs des classes d'entités correspondantes. Les tables sont reliées entre elles par certaines colonnes. Le modèle conceptuel est destiné à modeler la base de données entière. Cependant, un utilisateur individuel peut être intéressé par la vue d'une partie spécifique des données. Par exemple, dans la base de données LIBRARY, un étudiant utilisant le catalogue en ligne d'une bibliothèque ne sera pas intéressé, probablement, par le prix d'un livre mais par son emplacement sur les rayonnages. Ainsi, une simple base de données, telle que LIBRARY, pourra offrir des vues différentes pour l'étudiant et pour le bibliothécaire. Le niveau le plus élevé de cette structure à trois couches comprend les vues individuelles des données qui peuvent être détenues par des utilisateurs de la base de données. Ces vues sont appelées sous-schémas, et on se réfère à cette couche supérieure de la pile sous le nom de niveau externe. Comme autre exemple, nous pouvons imaginer le langage de programmation Microsoft Visual Basic comme fournisseur de vues externes du système de gestion de bases de données jet, qui est orienté vers la programmation de bases de données. Nous pouvons imaginer Microsoft Access comme fournisseur de vues externes destinées non seulement aux programmeurs, mais aussi au utilisateurs de haut niveau. Après tout, un utilisateur n'a pas besoin de connaissances sur la programmation des bases de données pour créer une base de données dans Microsoft Access, alors que l'approche conceptuelle d'une base de données relationnelle doit lui être familière.

147 Systèmes de gestion de bases de données 137 Le concept de base de données, perçue comme une structure à trois niveaux, a des avantages évidents. Il accorde par exemple un certain degré d'indépendance qui permet la modification ou le remplacement des couches individuelles sans affecter les autres couches. Par exemple, si la base de données est déplacée vers un autre ordinateur qui stocke les données dans des tables hash plutôt que dans des arborescences équilibrées, ceci ne devrait pas affecter le modèle conceptuel des données, ni les vues des utilisateurs de la base de données. Si nous basculons de la vue Visual Basic de la base de données à la vue Access, nous pouvons continuer à utiliser le même modèle conceptuel de base de données. Plus simplement, une table de base de données dans Visual Basic est toujours une table de base de données dans Microsoft Access. Systèmes de gestion de bases de données Un système de gestion de bases de données (DBMS) est un système logiciel responsable de la gestion de tous les aspects d'une base de données, à tous les niveaux. En particulier, un système DBMS devrait offrir les caractéristiques suivantes, et éventuellement davantage Un mécanisme pour la définition de la structure d'une base de données, sous la forme d'un langage de définition de données, ou DDL. Un mécanisme pour la manipulation de données, comprenant l'accès aux données, le tri, la recherche et le filtrage. Ceci prend la forme d'un langage de manipulation de données, ou DML. La possibilité d'une interaction avec un langage hôte de haut niveau ou d'une application hôte, permettant au programmeur d'écrire des applications de bases de données conçues dans un but spécifique. Le langage hôte peut être un langage de programmation standard, tel que C ou Visual Basic, ou un langage d'application de bases de données, tel que Microsoft Access. La gestion correcte et efficace d'accès concurrents aux données La sécurité effective des données. La Robustesse; c'est-à-dire, la capacité de prendre en charge des erreurs système sans perte de données. Un dictionnaire de données, ou catalogue de données. Il s'agit d'une base de données qui fournit une liste de définitions de tous les objets présents dans la base de données principale. Par exemple, un tel catalogue devrait contenir de l'information sur toutes les entités de la base de données, avec leurs attributs et index.

148 138 Chapitre 7: Architecture d'un s stème de base de données On appelle parfois métadonnées ces "données sur les données". Le dictionnaire de données devrait être accessible à l'utilisateur de la base de données, pour qu'il obtienne ces métadonnées. Le module de gestion jet DBMS Comme le suggère le titre du livre, notre intérêt principal réside dans le système DBMS qui sous-tend Microsoft Access (et aussi Visual Basic). En conséquence, nous allons tirer nos exemples de ce système DBMS, appelé jet DBMS ou jet Database Engine. La relation entre le système jet DBMS et d'autres programmes axés sur les bases de données, y compris Microsoft Access et Visual Basic, est décrite à la figure 7-2. Figure 7-2. Les relations et la structure du moteur de base de données jet

149 Le module de gestion jet DBMS 139 Les produits applicatifs de Microsoft comme Visual Basic, Access et Excel servent d' hôte à Visual Basic pour Applications (ou VBA), qui est le langage de programmation ( appelé également langage de script ou langage de macros) pour ces applications (Microsoft Word Version 7 n'utilise pas VBA-mais un langage similaire appelé Word Basic. Cependant, Microsoft Word 97 utilise VBA). Comme on peut s'y attendre, chacune de ces applications intègre VBA dans son environnement d'une manière spécifique, car chaque application a un objectif différent. À son tour, Visual Basic pour Applications est le langage hôte du système jet DBMS. Le système jet DBMS contient Data Access Object Component (ou DAO), qui est l' interface du langage de programmation du système jet DBMS. L'interface DAO offre un langage DDL plus ou moins orienté objet, et un langage DML, pour permettre au programmeur VBA de définir la structure d'une base de données et de manipuler ses données. Le moteur jet Database Engine est une collection de composants, généralement sous forme de DLL (dynamic link library), conçus pour fournir des fonctions spécifiques à l'intérieur de jet DBMS. Une DLL est essentiellement une collection de fonctions destinées à accomplir des tâches variées. Le moteur de requête jet effectue la traduction des requêtes de bases de données dans Access SQL (langage structuré de requête), leur compilation subséquente, l'optimisation et leur exécution. Bref, il traite les requêtes. Le module Internal ISAM Component est responsable du stockage et de la récupération des données dans la base de données physique. ISAM signifie Indexed Sequential Access Method (Méthode d'accès séquentiel indexée); c'est la méthode selon laquelle les données sont entreposées dans un fichier de base de données jet. Le moteur Replication Engine permet l'exacte duplication d'une base de données pour la portabilité sur divers systèmes, avec une synchronisation périodique. Les langages hôte du système jet DBMS, tels que Visual Basic et Access, sont utilisés par les programmeurs de bases de données pour créer des applications de base de données spécifiques. Par exemple, nous pouvons créer une application de bases de données Bibliothèque, qu'une bibliothèque peut utiliser pour mettre à jour les informations sur ses livres, ou une application de bases de données Prise de commandes pour une petite société. Le système jet DBMS est capable également de s'interfacer avec des bases de données autres qu'access, comme les bases au format Xbase (dbase), Paradox, Btrieve, Excel, et les bases au format texte délimité. Il peut s'interfacer aussi avec ODBC ( ODBC signifie open database connectivity) pour accéder aux serveurs d'applications de bases de données installés sur les réseaux.

150 140 Chapitre 7: Architecture d'un système de base de données Examinons de plus près les composants du système jet DBMS. Nous étudierons ces composants très en détail dans des chapitres séparés de ce livre. Langages de définition de données Nous avons déjà souligné qu'un système DBMS doit fournir une méthode de définition de nouvelles bases de données. Ceci s'effectue par la fourniture au programmeur d'un langage de définition de données, ou DDL. Le langage DDL n'est pas un langage procédural, ses instructions n'exécutant pas des opérations. II s'agit plutôt d'un langage de définition. Le langage jet de définition de données L'exemple 7-1 illustre l'utilisation du langage jet de définition de données. Le code tournera dans Visual Basic ou dans un module de code Access; vous pouvez le taper librement et l'essayer vous-même. Utilisez une nouvelle base de données dans Access, car une partie de code peut entrer en conflit avec la base de données LIBRARY que nous avons utilisée dans les chapitres précédents. L'objectif est de créer une nouvelle base de données appelée LIBRARY, avec une table LIVRES, contenant deux champs (ISBN et TITRE) et un index. Ne vous formalisez pas, si certaines portions de ce code n'ont pas un sens immédiat pour vous à ce stade. Notez qu'access utilise un espace suivi par un caractère souligné ( ) pour indiquer que la ligne suivante est la continuation de la ligne courante. Exemple 7-1. Utilisation du langage jet de d nition de données

151 Langages de manipulation de données 141 Exemple 7-1. Utilisation du langage jet de définition de données (suite) Comme vous pouvez le voir, l'indice que nous avons affaire à un langage DDL sont les instructions CreateDatabase, CreateTableDef, CreateField et Createlndex (en gras pour faciliter l'identification). Vous remarquerez également à partir du code que le langage jet DBMS utilise les collections pour contenir les propriétés d'un objet. Par exemple, les champs que nous créons pour une table doivent être ajoutés à la collection Fields de cette table. L'avantage principal est d'éviter de garder une référence séparée pour chaque champ-la collection le fait pour nous. Cette approche est typique de la programmation orientée-objet. Langages de man pulation de données Un système de gestion DBMS doit aussi fournir un langage conçu pour manipuler les données dans une base de données. Ce langage est appelé langage de manipulation de données, ou DML. La distinction entre les langages DDL et DML pourra

152 142 Chapitre 7: Architecture d'un système de base de données apparaître de pure forme aux programmeurs de bases de données, les deux langages se différenciant davantage par leurs objectifs que par leur syntaxe. L e langage jet de manipulation de données L'exemple 7-2 est le code jet DML pour ajouter deux enregistrements à la table LIVRES, définir l'index et afficher les enregistrements. Exemple 7-2. Code jet DML modifiant la table LIVRES Comme vous pouvez le constater à partir de ce simple exemple, le langage DML est conçu pour exécuter une grande variété d'actions, telles que Déplacements dans les données de la base de données Addition de données à la base de données

153 L'architecture client/ serveur 143 Édition ou mise à jour de données dans la base de données Suppression de données dans la base de données Recherche de données et renvoi de portions de données satisfaisant la requête Langages hôte Les données sont rarement manipulées sans but précis. Par exemple, considérons la base de données LIBRARY contenant l'information sur les livres d'une bibliothèque. Si un étudiant désire accéder à ces données, c'est probablement avec l' intention de trouver un certain livre, sur lequel l'étudiant a de l'information, telle que le titre. D'autre part, si un bibliothécaire désire accéder à l'information, ce peut être pour d'autres raisons, comme de déterminer quand le livre à été introduit à la bibliothèque ou combien il coûte. Ces sujets n'intéressent probablement pas l'étudiant. Un système DBMS devrait fournir une interface avec un langage de haut niveau avec lequel les programmeurs peuvent exploiter une base de données pour fournir des services spécifiques; c'est-à-dire, avec lequel les programmeurs peuvent créer des applications de bases de données. Ainsi, lorsqu'un étudiant s'installe sur un ordinateur de la bibliothèque pour rechercher un livre, il accédera à une application de base de données différente de celle à laquelle pourrait accéder le bibliothécaire. Le langage qui est utilisé pour la programmation des bases de données est le langage hôte du système DBMS. Comme nous l'avons vu, un langage hôte peut être un langage traditionnel de programmation, tels que C ou COBOL ou un langage applicatif, tel que Microsoft Access ou Visual Basic, comme c'est le cas avec jet DBMS. En fait, jet DBMS est si intimement intégré dans ces deux applications qu'il est difficile de dire où finit l'un et où commence l'autre. Autrement dit, il semble de temps en temps que Microsoft Access est Jet DBMS, tandis qu'il est plus juste de dire que Access et Visual Basic sont des programmes frontaux, ou applications hôtes, pour Jet DBMS. L architecture client/ serveur Le modèle client/serveur, illustré à la figure 7-3, d'un système de bases de données est réellement très simple, mais sa signification a évolué quelque peu à l'usage. Le serveur dans un modèle client/serveur est simplement le DBMS, tandis que le client est l'application de base de données servie par le DBMS (on pourrait aussi imaginer Visual Basic et Access comme clients du serveur jet DBMS). Le modèle

154 144 Chapitre 7: Architecture d'un système de base de données Figure 7-3. Exemple du mode client/serveur Figure 7-4. Exemple de modèle client/ serveur distribué Figure 7-5. Exemple de base de données distante de base client/serveur ne dit rien sur l'emplacement des différents composants. Cependant, puisque les composants sont distincts, il n'est pas rare de les trouver sur différents ordinateurs. Les deux configurations les plus répandues sont illustrées cidessus. Le modèle distribué client/serveur (figure 7-4), dans lequel le client est sur un ordinateur et le serveur et la base de données sont sur un autre, est si populaire qu'il est habituellement désigné sous le vocable de modèle client/serveur. Le modèle de base

155 Sur le CD-Rom 145 de données distante (figure 7-5) se rapporte au cas où le client et le serveur sont sur la même machine, mais où la base de données est sur un ordinateur distant. Sur le CD-Rom L'ensemble des exemples de ce chapitre se trouvent placés dans différents documents. Pour les consulter, accédez au document d'orientation : /exemples/chapo7/ chapo7. htm. La structure d'exposition des exemples suit la structure du chapitre suivant deux thèmes Langage jet de définition de données Langage jet de manipulation de données

156 Dans ce chapitre Constantes et variables Lancement d'un programme Opérateurs VBA -Quelques déclarations et fonctions VBA Sur le CD-Rom Ce chapitre traite des concepts de base du langage de programmation Visual Basic pour Applications, ou VBA, dans le seul but de vous permettre de suivre le chapitre sur la programmation DAO. Si vous avez une certaine expérience de la programmation, cette information vous semblera familière. Nous serons volontairement brefs ici, puisqu'il ne s'agit pas d'un livre sur la programmation en VBA. Même si vous êtes familier de Visual Basic, nous vous suggérons de parcourir rapidement ce chapitre. Un programme est simplement une série d'instructions exécutables. Les programmes prennent généralement la forme d'un ou plusieurs sous-programmes et/ou fonctions, référencés sous le terme générique de procédures. On peut dire qu'il s'agit en quelque sorte de modules de code conçus pour accomplir une tâche spécifique. La différence entre un sous-programme et une fonction est qu'une fonction retourne une valeur à la partie de programme qui l'appelle, tandis qu'un sous-programme ne le fait pas. Par exemple, si vous voulez afficher des données à l'écran, vous devez écrire un sous-programme, car il n'y a nul besoin de retourner une valeur. Par contre, si vous voulez qu'une procédure calcule la somme d'une collection de nombres, vous devez écrire une fonction, pouvant alors retourner cette somme. Dans Microsoft Access, les programmes sont écrits dans le langage Visual Basic pour Applications et sont contenus dans modules de code. Un module de code peut être associé à un formulaire ou rester indépendant. Nous allons nous limiter à l'écriture d'un seul module de code indépendant. Un nouveau module de code est créé en choisissant le bouton Nouveau à l'onglet Modules de la fenêtre Base de données. Une fenêtre, telle que celle de la figure 8-1, devrait en résulter (si la ligne OPTION EXPLICIT n'apparaît pas dans votre 147

157 148 Chapter 8: Bases de la programmation avec VBA nouveau module de code, sélectionnez alors l'onglet Module d'options dans le menu déroulant Outils et cochez dans la liste l'option Nécessite la déclaration des variables). Figure 8-1. Nouveau module de code Access La liste déroulante de gauche à la figure 8-1 (qui affiche le mot Genera. indique l' objet auquel le code appartient. Par exemple, lorsque un module est associé à un formulaire Access, les contrôles sur le formulaire sont listés dans cette boîte de liste. Comme notre module n'est pas associé à un formulaire, notre seul choix est General. La liste déroulante de droite contient une liste des différentes procédures dans le module. Pour un nouveau module, cette liste est vide, excepté pour l'option ( Déclarations), qui est là où des variables peuvent être déclarées. Nous allons utiliser de petits extraits de code pour illustrer à la fois les objets considérés et les techniques et la syntaxe de programmation de DAO. Nous vous suggérons de suivre ce cheminement sur votre ordinateur, depuis la base de données LIBRARY. Cette base de données échantillon se trouve sur le CD-Rom. Pour plus de détail, reportez-vous en fin de chapitre à la section qui décrit le contenu du dossier du CD-Rom relatif à ce chapitre. Pour ajouter un nouveau sous-programme ou une fonction dans un module, vous avez deux choix. Premièrement, vous pouvez sélectionner Procédure depuis le menu Insérer. Ceci fait apparaître la boîte de dialogue illustrée à la figure 8-2. Tapez simplement le nom et sélectionnez Sub ou Fonction, selon ce qui est approprié pour l' exemple. Pour créer un nouveau sous-programme, vous pouvez taper aussi Sub SubName ou Function FunctionName

158 Constantes et variables 149 Figure 8-2. La boite de dialogue Insérer dans Access dans toute autre fenêtre de code, après la déclaration End Sub, ou dans la fenêtre General. Access est suffisamment élaboré pour réaliser que vous voulez créer un nouveau sous-programme. Constantes et variables Une constante littérale (ou parfois tout simplement constante) est une valeur spécifique, telle qu'un nombre, une date ou une chaîne de texte, qui ne change pas et qui est utilisée exactement comme on l'écrit. Les constantes chaîne sont insérées entre guillemets, comme dans "Donna Smith" et les constantes de date sont placées entre des signes dièse, comme dans #1/1/96# Une constante symbolique (contractée parfois en constante) est un nom associé à une constante littérale. Par exemple, nous pouvons définir une constante symbolique en écrivant Const FirstName = "Donna" Dans ce cas, chaque fois que nous utilisons FirstName, VBA le remplacera par la chaîne "Donna". Ainsi, FirstName est une constante, car elle ne change jamais de valeur, mais ce n'est pas une constante littérale, car elle n'est pas utilisée telle qu'écrite. Le grand mérite des constantes symboliques est que, si vous décidez ultérieurement de changer "Donna" en "Diane", vous n'avez à modifier qu'une ligne du programme Const FirstName = "Diane"

159 150 Chapter 8: Bases de la programmation avec VBA au lieu de rechercher dans tout le programme entier chaque occurrence du mot " Donna." VBA a un grand nombre de constantes symboliques implantées, qui habituellement débutent par les lettres minuscules vb. Nous rencontrerons quelques-unes de ces constantes au fur et à mesure de notre progression. Pour l'instant, notons les deux constantes suivantes : vbcrlf, qui est équivalente à un retour chariot suivi par une alimentation de ligne, et vbtab, qui est équivalente au caractère tab (sans ces constantes symboliques, vous auriez à entrer Chr$(13) + Chr$(10) pour la première constante et Chr$(9) pour la dernière). Une variable est un emplacement mémoire qui peut contenir des valeurs d'un type spécifique. La valeur dans une variable peut changer durant la vie du programme. Dans VBA, chaque variable a un type spécifique, qui indique quel type de données elle peut contenir. Par exemple, une variable qui contient des chaînes de texte est appelée une variable de type chaîne. Lorsque l'option OPTION EXPLICIT est activée, toutes les variables doivent être déclarées avant de pouvoir être utilisées. Ceci indique à VBA le type de ces variables. Elles sont déclarées à l'aide du mot-clé Dim (ou des mots-clés Private et Public, que nous verrons plus tard dans ce chapitre). Voici quelques exemples La syntaxe générale d'une déclaration de variable est Par référence, la table 8-1 montre un jeu complet de types de données standard, avec la quantité de mémoire utilisée et la plage de valeurs correspondantes. Table 8-1 Types de données standard de VBA Type Taille en mémoire Plage de valeurs Byte Boolean 1 octet 2 octets 0 à 255 Vrai ou Faux Integer 2 octets à Long (long integer) 4 octets à Single 4 octets Approximativement (single-precision real) -3.4E38 à 3.4E38

160 Constantes et variables 151 Table 8-1 Types de données standard de VBA (suite) Type Taille en mémoire Plage de valeurs Double 8 octets Approximativement (double-precision real) -1.8E308 à 4.9E324 Currency 8 octets Approximativement (scaled integer) , ,5807 Date 8 octets 1/1/100 à l2/31/9999 Object 4 octets Référence Objet quelconque String Longueur de variable : Longueur de variable : <= environ 10 octets + longueur de chaîne; 2 milliards ( pour Win 3.1); Longueur fixe: longueur de Longueur fixe: jusqu'à chaîne Variant 16 octets pour les nombres Nombre: même que Double; 22 octets + longueur de chaîne Chaîne: même que String User-defined Varie C'est généralement une saine pratique en programmation d'inclure OPTION EXPLICIT dans les modules. Ceci indique à VBA d'exiger la déclaration explicite de toutes les variables. Cependant, ce n'est pas absolument nécessaire. Si vous omettez OPTION EXPLICIT, VBA utilise alors le type de données Variant pour toutes les variables non-déclarées. C'est un type de données fourre-tout conçu pour être capable de contenir des données de tous les autres types, excepté les données de String et des types définis par l'utilisateur. Le mérite du type de données Variant est qu'il vous libère du soin de déclarer le type de chaque variable. Son défaut est d'utiliser plus de mémoire qu'aucun autre type de données. Par exemple, dans le code: la variable intage prend 2 octets de mémoire (selon la table 8-1). Cependant, si la variable varage n'est pas déclarée et si vous écrivez alors VBA va assigner à la variable le type de données Variant et ainsi lui attribuer 16 octets de mémoire. même si elle ne stocke qu'un entier.

161 152 Chapter 8: Bases de la. programmation avec 1, /TA Vous pouvez aussi attacher un caractère spécial à des noms de variables pour en indiquer le type à VBA. En particulier, VBA autorise les suffixes de type-déclarations illustrés à la table 8-2. Table 8-2. Suffixes autorisés dans VBA pour les déclarations Suffixe & Type variable entière variable entière longue variable unique # variable variable monétaire $ variable chaîne Par exemple, la ligne: déclare une variable appelée Name,$ de type String. Nous pouvons écrire alors Tableaux Il est possible également de déclarer des variables englobant des tableaux de données, appelées variables tableau. Une variable tableau est essentiellement une collection de variables uniques utilisant le même nom, distinguées les unes des autres par une valeur d'indice. Par exemple, si nous voulons stocker l'âge de 10 personnes, nous pouvons déclarer une variable tableau de la manière suivante La variable tableau est intages. Elle a une taille de 10. Chacune des variables intages(1), intages(2),..., intages(1o) est une variable entière simple. Notez que nous pouvons omettre le premier indice dans la déclaration mais alors VBA va mettre le premier indice à 0 et la taille du tableau est alors de 11, avec 11 variables entières intages(o) à intages(10). L'avantage de déclarer des variables de tableau, par opposition à des variables individuelles, telles que intagesl, intages2,..., intageslo, est aisément perceptible si nous voulons non pas 10, mais variables! En outre, comme nous le verrons, il y a de

162 Constantes et variables 153 nombreuses façons de travailler collectivement avec tous les éléments d'un tableau, en utilisant un petit nombre de blocs de programmation. Variables de dénomination C'est une bonne pratique en programmation de développer une convention de nommage cohérente pour les noms de variables. Il y a de nombreuses conventions et chaque programmeur a les siennes. Un programmeur, Charles Simonyi, eut une très bonne idée concernant la dénomination des variables. En particulier, il développa un schéma dans lequel chaque nom est préfixé avec des caractères qui décrivent le type de la variable. Les capitales sont utilisées pour séparer des mots, de préférence à des espaces, qui ne sont pas toujours autorisés, ou le souligné, qui est difficile à manipuler. Par exemple, nous utilisons le préfixe int pour des variables entières, comme dans et le préfixe str pour les variables de type String, comme dans La table 8-3 montre les conventions de nommage des variables standard, dont nous n'allons utiliser qu'un nombre restreint dans nos exemples. Nous aurons l'occasion de donner des tables plus complètes au chapitre 9, Programmation DAO : aperçu. Table 8-3. Dénomination des variables Standard pour VBA Variable Type Boolean Byte Currency Date Double Integer Long Object Single String User-defined type Variant Préfixe bool, b, or f byt cur dte dbl int Ing obj sng str typ var

163 154 Chapter 8: Bases de la programmation avec VBA La portée d'une Variable Chaque variable a une portée, qui indique la zone du programme où la variable est reconnue. Les variables que nous déclarons ont soit une portée limitée à la procédure soit une portée limitée au module (abritant plusieurs procédures). Plus simplement, si une variable est déclarée dans une procédure (sous-programme ou fonction), elle est visible uniquement à l'intérieur de cette procédure. Aucune autre procédure ne reconnaîtra cette variable. Ceci vous permet de déclarer dans d'autres procédures d'autres variables du même nom mais bien distinctes. D'autre part, si la variable est déclarée dans la section (Déclarations) du module, elle a une portée limitée au module, signifiant qu'elle est visible de chaque procédure dans le module. Ainsi, par exemple, la variable intthismoduleonly déclarée à la figure 8-3 a une portée limitée au module. Figure 8-3. Exemple de module illustrant les variables module-level Lorsque l'on doit travailler avec plusieurs modules de code, il y a un niveau supplémentaire de portée. Les variables déclarées en utilisant le mot-clé Private (ou Dim) sont visibles dans le module dans lequel elles sont déclarées, tandis que des variables déclarées en utilisant le mot-clé Public peuvent être vues dans chaque module. Ces déclarations sont également illustrées à la figure 8-3. Lancement d un programme Pour lancer nos programmes échantillon dans Access, nous utilisons la fenêtre de débogage. Les programmes peuvent aussi être assignés à des macros, en utilisant la commande RunCode. Pour rendre visible la fenêtre de débogage, tapez Ctrl-G. La fenêtre de débogage est montrée à la figure 8-4. Pour lancer un sous-programme, tapez simplement son nom et pressez la touche Entrée.

164 Opérateurs VBA 155 Figure 8-4. Fenêtre de débogage d Access Il est temps d'écrire un petit programme. Démarrez un module de code et entrez le sous-programme suivant Ouvrez la fenêtre de débogage et lancez ce programme en tapant test et en appuyant sur la touche Entrée. Vous obtenez deux messages Ceci nous informe qu'un espace de travail est ouvert, dont le nom est #Default Workspace#. Opérateurs VBA VBA utilise une poignée d'opérateurs simples Opérateurs arithmétiques Addition: + Soustraction: - Multiplication: Division: / Exponentiation: ^

165 156 Chapter 8: Bases de la programmation avec VBA Opérateurs de chaînes Concaténation: & opérateurs logiques Opérateurs de comparaison La concaténation de chaînes est le seul opérateur que vous n'avez pas vu jusqu'à maintenant. En voici un exemple Quelques instructions et fonctions VBA Abordons maintenant quelques unes des instructions fondamentales dans VBA. L'instruction MsgBox L'instruction MsgBox est utilisée pour afficher un message et attend que l'utilisateur appuie sur un bouton. Il y a de nombreuses variantes de cette instruction. Consultez l'aide en ligne d'access pour une description complète. Nous allons l'utiliser dans sa forme la plus simple Par exemple, le code produit la boîte de message de la figure 8-5.

166 Quelques instructions et fonctions VBA 157 Figure 8-3. I:xenrple de jen tre illustrant l'utilisation de l'instruction MsgBox La fonction InputBox La fonction InputBox est conçue pour recevoir une entrée provenant de l'utilisateur. Considérons l'exemple. Le code suivant demande le nom d'un fichier de base de données sur le disque En réponse à la fonction InputBox, VBA affiche la boîte de dialogue de la figure 8-6. Figure 8-6. Exemple de boîte de dialogue de la fonction InputBox Lorsque l'utilisateur presse le bouton OK, la chaîne dans la boîte de texte sera placée dans la variable strresponse. Si l'utilisateur presse le bouton Cancel, alors strresponse sera la chaîne vide, notée " ".

167 158 Chapter 8: Bases de la programmation avec VBA La dernière portion de code, commençant à la ligne est utilisée pour détecter si strresponse est vide ou non. Si oui, nous quittons le sousprogramme. Si non, la valeur de strresponse est affichée à l'utilisateur. Nous allons examiner en détail l'instruction If... Then un peu plus tard. Quelques fonctions chaîne utiles Voici une poignée de fonctions s'appliquant à des chaînes (à la fois constantes et variables). La fonction Len La fonction 1-en retourne la longueur d'une chaîne, c'est-à-dire, le nombre de caractères dans la chaîne. Ainsi, retourne le nombre 11. Les fonctions UCase et LCase Ces fonctions convertissent une chaîne en majuscules ou en minuscules, respectivement. La syntaxe est Par exemple, affichera la chaîne: DONNA. Les fonctions Left, Right, et Mid Ces fonctions retournent une portion de chaîne. En particulier, retourne le nombre de caractères le plus à gauche dans string et retourne le nombre de caractères le plus à droite dans string. Par exemple, affiche la chaîne: Smith. La syntaxe de Mid est:

168 Puelques instructions et fonctions VBA 159 Cette fonction retourne le premier nombre de caractères length de string, débutant au nombre de caractères start. Par exemple, retourne la chaîne : mdb. Si le paramètre length est manquant, comme dans la fonction retourne le reste de la chaîne, débutant à start. La fonction Instr La syntaxe de cette fonction est: La valeur retour est la position de la première occurrence de StringToFind dans String- ToSearch, débutant à Start. Si Start est manquant, la fonction démarre la recherche au début de StringToSearch. Par exemple, affiche le nombre 7. Les fonctions Str et Val La fonction Str convertit un nombre en une chaîne. Par exemple, retourne la chaîne "123". Inversement, la fonction Val convertit une chaîne qui représente un nombre en un nombre (de manière à faire des opérations arithmétiques sur lui). Par exemple, retourne le nombre 4.5. La fonction Val est très utile. Par exemple,

169 160 Chapter 8: Bases de la programmation avec VBA est le nombre Notez, cependant, que Val ne reconnaît pas le signe dollar et la virgule. Ainsi, Val($12.00) retourne 0, non ,Quelques instructions de contrôle utiles Considérons quelques instructions de contrôle VBA. L'instruction V... Then L'instruction If.. Then est utilisée pour le contrôle conditionnel. La syntaxe complète est Notez que vous pouvez inclure autant de parties Elself que vous le souhaitez et que les parties Elself et Else sont optionnelles. L'exemple 8-1 affiche une note obtenue par un étudiant, basée sur le score obtenu durant le test.. Example 8-1. Exemple de l'instruction If... Then Sub exalfthen() Dim intgrade As Integer intgrade = Val(InputBox("Enter student's average test score: "))

170 _Quelques instructions et fonctions VBA 161 La boucle For Cette déclaration permet de boucler entre certaines lignes de code. Considérez l' exemple 8-2. Notez qu'un apostrophe au début d'une ligne introduit une ligne de commentaires, qui n'est pas exécutée par VBA. Example 8-2. Exemple de boucle For utilisent une boucle For pour affecter des valeurs à chacune des 11 variables de type entier de intarray(0) à intarray(10). Cet exemple illustre également la syntaxe voisine For Each, qui utilise une variable de type variant pour boucler dans le tableau intarray. Cette syntaxe s'applique aussi à des collections, comme nous le verrons au chapitre 9. Notez que la ligne imprime la valeur de Str(varldx) dans la fenêtre de débogage. La boucle Do La boucle Do a de légères variations, résumées ci-dessous. L'instruction

171 162 Chapter 8: Bases de la programmation avec VBA signifie que vous pouvez utiliser le mot While ou le mot Until (mais non les deux à la fois). Voici la syntaxe possible pour la boucle Do L'exemple 8-3 utilise une boucle Do pour calculer la somme des dix premiers nombres entiers. La valeur de cette somme est placée dans la variable intsum. Example 8-3. Exemple de boucle Do Sur le CD-Rom Les exemples de ce chapitre se trouvent placés dans différents documents. Pour les consulter, ouvrez le document d'orientation : /exemples/chapo8/chapo8.htm.

172 Dans ce chapitre Objets Le modèle objet DAO Le modèle objet Microsoft Access Objets de référence Les collections sont aussi des objets Collections de propriétés Objets DAO de fermeture Vue sur les objets DAO La fonction CurrentDb Sur le CD-Rom Nous avons vu qu'access SQL fournit un moyen de créer et de manipuler des objets de bases de données, tels que les tables et les requêtes, par l'intermédiaire de ses composants DDL et DML. De plus, les utilisateurs peuvent entrer des instructions SQL directement dans la fenêtre Vue Access SOL D'autre part, Microsoft Access nous permet de programmer le moteur jet directement, à travers son interface de programmation, qui est connue sous le nom de Data Access Objects, ou DAO. Ceci donne à l'utilisateur un bien meilleur contrôle sur une base de données. DAO est un ensemble compliqué et nous ne voulons pas discuter de tous ses aspects. Notre propos sera d'acquérir une compréhension générale des concepts et composants suivants L'organisation de DAO, qui est partiellement orientée objet Le composant DDL de DAO Le composant DML de DAO Nous n'allons certainement pas couvrir tous les aspects des composants DDL et DML. Notre objectif principal est de vous préparer à obtenir tout type d'information du vaste système d'aide en ligne de Microsoft Access pour le modèle DAO, ou d' autres manuels de référence similaires. Objets Avant d'aborder les différents composants de l'interface DAO, nous devons aborder le concept d'objet. Dans le jargon de la programmation objet, une classe est 163

173 164 Chapitre 9 : Programmation DAO: vue d'ensemble un moule permettant de créer des objets et est identifiée par ses propriétés (ou attributs) et ses méthodes (ou actions). Comme nous le verrons (et comme le nom l'indique) DAO est rempli d'objets. Par exemple, chaque table sauvegardée dans une base de données Access est un objet, appelé un objet TableDef (effectivement, c'est la définition de la table, plutôt que ses données, qui est un objet de type TableDe~. Certaines des propriétés des objets TableDef sont Name, RecordCount, DateCreated et LastUpdated. Les méthodes d'un objet peuvent être imaginées comme des procédures ou des fonctions qui agissent sur l'objet. Par exemple, l'une des méthodes d'un objet TableDef est CreateField qui, comme son nom l'indique, est utilisée pour créer un nouveau champ pour l'objet TableDef. Une autre méthode est OpenRecordset, qui crée un autre objet, appelé objet Recordset, qui peut être utilisé pour manipuler les données de la table. (Une vision plus orientée objet des méthodes les assimile à des messages qui sont envoyés à l'objet stipulant, en effet, d'exécuter l'action suivante). Variables objet Pour accéder aux propriétés ou invoquer les méthodes d'un objet, nous devons d' abord définir une variable objet pour référencer cet objet. VBA et DAO offrent une grande variété de types d'objets. Il y a une légère différence de syntaxe lorsqu'on déclare et paramètre une variable objet, par opposition à une variable standard. Par exemple, voici un exemple utilisant le type objet Database. Notez que le chemin complet de la base de données LIBRARY sur mon PC est d. \dbase\library. mdb. En général, la syntaxe est Remarquez que la seule différence de configuration entre variables objet et variables standard est le mot-clé Set. Cependant, cette différence mineure de syntaxe recouvre une différence bien plus significative entre variables standard et variables objet. En particulier, une variable standard peut être décrite comme un nom pour l'emplacement dans la mémoire de l'ordinateur qui contient des données. Par exemple, dans le code

174 Objets 165 intvar = 123 la variable intvar est un emplacement mémoire de 4 octets qui contient la valeur entière 123. La figure 9-1 illustre la variable intvar (effectivement, l'emplacement mémoire de 4 octets renferme la valeur 123 en format binaire, mais ce n'est pas en rapport direct avec notre exposé). Figure 9-1. Exemple de la variable intvar Naturellement, si nous devions écrire nous ne pourrions pas espérer que la dernière ligne de code ci-dessus puisse avoir un quelconque effet sur la valeur de la variable intvar qui devrait rester 123. D'autre part, une variable objet n'est pas le nom d'un emplacement mémoire qui renferme la "valeur" de l'objet. Une variable objet renferme plutôt l'adresse de la zone mémoire qui contient l'objet. En d'autres termes, la variable objet contient une référence à, ou pointe vers l'objet. Elle est appelée pour cette raison une variable pointeur. L'idée est imagée à la figure 9-2, où rsbooks et rsbooks2 sont des variables objet, pointant toutes les deux vers un objet de type Recordset. Figure 9-2. Un exemple de variables pointeurs Pour poursuive l'illustration, considérons le code de l'exemple 9-1. Exemple 9-1. Exemple de variable objet

175 166 Chapitre 9 : Programmation DAO: vue d'ensemble Exemple 9-1. Exemple de variable objet Premièrement, nous déclarons deux variables objet de type Recordset (jeu d'enregistrements ; nous aborderons ce type en détail ultérieurement). La ligne spécifie que rsbooks pointe vers (ou se réfère à) un objet Recordset créé depuis la table LIVRES. Notez de nouveau que, contrairement aux variables standard, définir une variable objet exige l'utilisation du mot-clé Set. La ligne spécifie que rsbooks2 pointe vers le même objet Recordset que rsbooks, comme le montre la figure 9-2. Ensuite, la ligne: affiche la boîte de messages à la figure 9-3, montrant qu'il y a 14 livres dans le Recordset ( dans le jeu d'enregistrements). Pour illustrer le fait que les deux variables pointent vers le même objet, la ligne:

176 Objets 167 Figure 9-3. I r Dor/e d, Illess ~, -s de l'exemple exaobjectvaro utilise le pointeur rsbooks2 pour détruire (ou fermer) l'objet Recordset. Lorsque la ligne: est exécutée, l'objet Recordset auquel se réfèrent les variables est enlevé, et ainsi l' expression rsbooks.recordcount provoque une erreur L objet est incorrect ou n'est pas défini, comme l'illustre la figure 9-4. Figure 9-4. Message d'erreur de l'exemple exaobjectvaro La morale de cet exemple est qu'il est important de se rappeler que les variables objet se référent à des objets et que plusieurs variables peuvent se référer au même objet. En dépit de cela, on a coutume d'utiliser l'instruction erronée "l'objet objvary" alors que nous devrions dire "l'objet adressé par objvar." Conventions de nommage des variables objet Les tables 9-1 et 9-2 décrivent la convention de nommage pour les variables standard et les variables objet que nous allons (essayer d')utiliser dans ce livre (la table 9-1 est une répétition de la table 8-3.) Nous expliquerons les différents types d'objets au fur et à mesure de notre progression dans ce chapitre. Table 9-1. Dénomination des variables standard dans VBA Variable Boolean Byte Préfixe bool, b, or f byt

177 168 Chapitre 9 : Programmation DAO: vue d'ensemble Table 9-1. Dénomination des variables standard dans VBA(suite) Variable Préfixe Currency cur Date dte Double dbl Integer int Long lng Single sng String str User-defined type typ Variant var Table 9-2. Dénomination des variables objets dans VBA Variable Container Database Document Dynaset Error Field Form Index Object Parameter Property QueryDef Recordset Relation Report Snapshot Table TableDef User Workspace Préfixe con db ou dbs doc dyn err fld frm idx obj prm prp qdf rs ou rst rel rpt snp tbl tdf ou tbl usr ws ou wrk

178 O jets 169 Enoncé des propriétés et méthodes d'un objet La syntaxe générale pour se référer aux propriétés et aux méthodes d'un objet est très simple. Supposons que objvar est une variable qui se réfère à un objet. Si APropery est une propriété de cet objet, alors nous pouvons y accéder en utilisant la syntaxe Si AMethod est une méthode pour cet objet, nous pouvons l'invoquer avec la syntaxe Pour l'illustrer, considérons le code de l'exemple 9-2. Exemple 9-2. Un exemple Property et Method La ligne spécifie la variable objet de type DATABASE pointant vers la base de données courante, c'est-à-dire, la base de données LIBRARY. La ligne affiche la valeur de la propriété Name de dblib. La ligne invoque la méthode CreateQueyDef pour créer une nouvelle requête, appelée Expensive, et définie par l'instruction SQL

179 170 Chapitre 9 : Programmation DAO: vue d'ensemble Notez que le code invoque la méthode, qui retourne l'objet QueryDef, vers lequel pointe la variable objet gdjexpensive. Si vous lancez ce programme, vous notez une nouvelle entrée à l'onglet Requêtes de la fenêtre Base de données (si la requête Expensive est déjà dans la base de données, effacez-la avant de lancer ce programme. Pour rafraîchir la liste si nécessaire quittez puis revenez à l'onglet Requêtes). Le modèle objet DAO Comme le nom Data Access Objects le suggère, le modèle DAO est, au moins partiellement, un environnement orienté objet. En particulier, le modèle objet DAO est implémenté comme une hiérarchie de collections d'objets. La figure 9-5 montre le modèle objet DAO, décrivant les collections et leurs objets. Chacune des cases ombrées représente une collection d'objets (ainsi DBEngine est la seule non-collection). Le nom des objets contenus dans une collection donnée est le nom au singulier de la collection. Par exemple, la collection TableDefs contient les objets TableDef et la collection Documents renferme les objets Document. DBEngine est le seul objet isolé-non contenu dans une collection. Il y a une cause potentielle de confusion à propos de la hiérarchie des objets DAO à la figure 9-5 que nous devons corriger. Considérons, par exemple, la relation entre les collections Databases et Workspaces. Il serait incorrect de dire, comme on pourrait l' inférer du diagramme, que la collection Databases est contenue dans la collection Workspaces. En vérité, la ligne allant de Workspaces à Databases signifie que chaque objet Workspace a (ou comme Microsoft dirait, "contient") une collection Databases. Le meilleur moyen de visualiser la situation est de dire que chaque objet dans la hiérarchie DAO s'est associé trois choses : des collections, des méthodes et des propriétés. Par exemple, un objet Workspace s'attache les items suivants Collections Databases Groups Users Properties (non illustrées à la figure 9-5)

180 Le modèle objet DAO 17 1 Figure 9-5. Le modèle objet DAO Méthodes BeginTrans Close CommitTrans CreateDatabase CreateGroup CreateUser OpenDatabase Rollback Propriétés IsolateODBCTrans Name UserName Faisons une pause pendant un bref instant. Dans un environnement orienté objet tel que C++, ou même Visual Basic, une collection est aussi considérée comme un objet. La valeur de la propriété d'un objet peut être assimilée, plus ou moins, à un

181 172 Chapitre 9 : Programmation DAO: vue d'ensemble autre objet (ce sont les objet propriétés). Pour cette raison, dans un tel environnement orienté objet, nous pourrions imaginer les collections associées à un objet comme étant juste des propriétés supplémentaires de cet objet. Cependant, Microsoft a choisi de ne pas l'exprimer de manière explicite dans le modèle DAO. La figure 9-6 montre un exemple plus détaillé de la relation objet-collection. La collection Containers dans ce cas contient trois objets Container, chacun d'eux ayant les mêmes propriétés et méthodes. Chaque objet "contient" également une collection Documents, qui contient certains objets Document. Figure 9-6. Un exemple détaillé de la relation objet-collection Ainsi, selon ce modèle, il peut y avoir plus d'une collection Documents. En fait, il y a une collection Documents pour chaque objet Container. De façon similaire, il y a une collection Databases pour chaque objet Workspace et une collection TableDefs pour chaque objet Database. Le modèle objet Microsoft Access Vous pouvez remarquer qu'il n'y a pas de collections dans le modèle DAO correspondant aux formulaires et rapports Access. Le fait est que DAO ne représente pas toute la saga des objets. Microsoft Access définit ses propres collections d'objets, comme le montre la figure 9-7.

182 Le modèle objet Microsoft Access 173 Figure 9-7. Le modèle objet MicrosoftAccess Access définit la collection Forms pour contenir les formulaires couramment ouverts (notez particulièrement les mots "couramment ouverts", utilisés parce que les fichiers sont ouverts à ce moment). De façon similaire, la collection Reports contient les rapports couramment ouverts. Les objets Application, DoCmd, et Screen ne sont pas contenus dans une collection. La collection Modules, qui est nouvelle dans Access 8.0, renferme tous les modules de code ouverts. La collection References, qui est aussi nouvelle pour Access 8.0, contient tous les objets Reference. Un objet Reference est une référence à une autre bibliothèque de types, un fichier contenant de l'information sur les objets que l'application expose à travers Automation. C'est à travers les objets Automation qu'une application peut partager certaines de ses caractéristiques avec d'autres applications. Cependant, nous n'en dirons pas plus sur ce sujet dans ce livre. (Pour plus d'information sur l' Automation OLE, permettez-moi de recommander le livre intitulé Concepts of Object- Oriented Programming with Visual Basic, du même auteur, publié par Springer-Verlag ( ISBN ), conçu à l'intention des programmeurs Visual Basic). Nous noterons également que VBA a quelques instructions de manipulation d' objets database, représentant des bases de données entières. Par exemple la ligne Set dblib = CurrentDb paramètre la variable dblib pour qu'elle pointe vers la base de données couramment ouverte. La fonction CurrentDb, que nous allons examiner plus en détail ultérieurement, n'est pas une fonction DAO-vous ne la trouverez pas dans le manuel de référence du modèle DAO. Elle fait partie de VBA. Ainsi, VBA, Access, et DAO fournissent tous des objets et des instructions pour la gestion des bases de données.

183 174 Chapitre 9 : Programmation DAO: vue d'ensemble R férencement à un objet La première étape pour comprendre les objets dans la hiérarchie DAO est de comprendre comment se référer à un objet dans la hiérarchie. En particulier, nous pouvons nous référer à un objet par le nom d'objectname qui appartient à une collection nommée CollectionName, par l'une des syntaxes suivantes CollectionName!ObjectName ou CollectionName![ObjectName] lorsque ObjectName a des caractères illégaux, comme les espaces CollectionName("ObjectName") CollectionName(StringVar), où StringVar renferme la chaîne ObjectName CollectionName(Index), où Index est le numéro d'index de l'objet dans la collection. Les index démarrent à 0 et s'incrémentent jusqu'au nombre d'objets de la collection moins un (comme nous le voyons, le nombre d'éléments dans une collection est noté par CollectionName.Count). Par exemple, l'objet TableDef nommé LIVRES dans la collection TableDefs est noté ou ou ou, si LIVRES apparaît comme étant le premier objet TableDef dans la collection TableDefs, Le point d'exclamation (!) utilisé dans la première syntaxe ci-dessus est appelé l' opérateur bang. Noms d'objets pleinement qualifiés Il y a un problème avec ces noms. Par exemple, à quel objet se réfère Fields(0)? Il y a plusieurs collections Fields dans la hiérarchie DAO, comme on peut le voir à la figure 9-5. Référons-nous aux noms décrits dans la syntaxe précédente comme des noms semiqualifiés. Pour éviter qu'un nom semi-qualifié ne soit pas unique, nous devons utiliser le nom d'objet pleinement qualifié, qui est formé en parcourant l'entière

184 Référencement à un obiet 175 hiérarchie depuis le haut (DBEngine) jusqu'à l'objet désiré. Par exemple, le nom pleinement qualifié pour LIVRES est Examinons ce nom. Il est composé de quatre noms d'objet semi-qualifiés, séparés par des points. On se réfère à ces points à l'aide de l'expression opérateur dot. La manière la plus simple de donner un sens à ce nom est de démarrer à partir du dernier élément. Le nom semi-qualifié de l'objet auquel nous nous intéressons est Cet objet est contenu dans la collection TableDefs pour l'objet Database spécifié Cet objet est, à son tour, contenu dans la collection Databases de l'objet Workspace par défaut (nous reviendrons là-dessus plus tard), qui est qui, à son tour, est contenu dans l'objet DBEngine. La séparation de chacun de ces noms d'objet par l'opérateur dot (ou opérateur point) donne le nom d'objet pleinement qualifié. En général, la syntaxe pour un nom d'objet semi-quah fié est: et pour un nom d'objet pleinement qualifié, elle est II semble régner une certaine confusion à propos de l'emploi de l'opérateur bang (!) et de l'opérateur dot (.). Espérons que ce qui suit va vous aider L'opérateur bang est utilisé pour séparer un nom d'objet du nom de la collection dont il est membre. En d'autres termes, bang annonce un membre d'une collection. Il apparaît ainsi dans les noms d'objet semi-qualifiés. L'opérateur dot est utilisé pour séparer chaque nom d'objet semi-qualifié dans un nom d'objet pleinement qualifié. En d'autres termes, il annonce le niveau suivant dans la hiérarchie.

185 176 Chapitre 9 : Programmation DAO: vue d'ensemble L'opérateur dot est utilisé aussi pour noter une propriété ou méthode d'un objet. En réalité, cette convention de nommage n'est pas aussi difficile à maîtriser qu'il y paraît au premier abord, si vous gardez en mémoire les trois maximes précédentes. Cependant, si la confusion ne vous fait pas peur, attendez d'arriver aux collections par défaut, qui sont pour bientôt. Utilisation de variables objet Comme vous pouvez le voir, un nom d'objet pleinement qualifié peut être très long. Ce problème est compliqué par le fait qu'il peut être nécessaire de se référer au même objet plusieurs fois dans un programme. Il y a deux façons habituelles de traiter ce problème. L'une est d'utiliser des variables objet. Considérons le code à l'exemple 9-3 pour afficher la propriété RecordCount de la table LIVRES. Exemple 9-3. Un exemple de variable objet En définissant trois variables objet, ws, dblib et tdjbooks, nous avons pu éviter l'écriture du nom pleinement qualifié de LIVRES (sur une seule ligne). La ligne est beaucoup plus facile à lire. (Elle se lit : "Envoie-moi le nombre d'enregistrements de TableDef tdfbooks."). L'utilisation de variables objet de cette manière a plusieurs avantages et est fortement recommandée. En premier, elle tend à raccourcir les lignes de code et à les rendre plus lisibles. Deuxièmement, elle permet de se référer à la variable objet tdjbooks plusieurs fois sans avoir à écrire le nom d'objet pleinement qualifié chaque

186 Référencement à un objet 177 fois. En conséquence, le programme tournera légèrement plus vite, puisque VBA n'a pas à résoudre le nom d'objet en parcourant la hiérarchie plus d'une fois. Collections par défaut Il y a une autre méthode qui peut être utilisée pour la contraction de noms d'objet pleinement qualifiés. En particulier, chaque objet a une collection par défaut, qui peut être utilisée comme suit. Considérons une portion de nom pleinement qualifié Si Collection2 est la collection par défaut de Objectl, ce nom peut être contracté en où nous avons omis le nom de la collection par défaut Collection2, de même que le point séparateur. Par exemple, la collection par défaut de DBEngine est Workspaces. De ce fait, peut être contracté en et la phrase peut être contractée en Ainsi, puisque la collection par défaut d'un objet Workspace est Databases, la phrase peut être contractée en La table 9-3 montre les collections par défaut du modèle objet DAO et Access. Table 9-3. Collections par défaut de DAO et Access Objet Collection par défaut DBEngine Workspace Database Workspaces Databases TableDefs

187 178 Chapitre 9 : Programmation DAO: vue d'ensemble Table 9-3. Collections par défaut de DAO et Access Objet TableDef Recordset QueryDef Index Relation Container User Group Forms Reports Collection par défaut Fields Fields Parameters Fields Fields Documents Groups Users Controls Controls L'utilisation de collections par défaut peut économiser de l'espace. Cependant, elle contribue très peu à l'augmentation de la lisibilité (c'est le moins qu'off puisse en dire) et doit être laissée de préférence aux programmeurs ayant une telle expérience que de toute façon, ils ont du mal à déchiffrer les noms! Pour souligner le propos, chacune des lignes de l'exemple 9-4 affiche la propriété RecordCount de la table LIVRES. Notez que le nom complet d'accès à la base de données LIBRARY sur mon ordinateur est d. \dbase\library.mdb. Exemple 9-4. Un exemple de collections par défaut

188 Les collections sont aussi des objets 179 T es collections sont aussi des objets Dans un environnement centré sur l'objet, chaque chose est un objet. Bien qu' Access, VBA et DAO n'aillent pas si loin, il est vrai que les collections sont des objets et ont leurs propres propriétés et méthodes. Dans l'environnement Access, les collections peuvent être réparties en trois types: Collections MicrosoftAccess, qui font partie de la hiérarchie objet Access Collections DAO, qui font partie de la hiérarchie DAO Collections définies par l'utilisateur, qui sont des objets VBA de type Collection Notez que seules les collections définies par l'utilisateur sont de type Collection, qui est un type de données VBA, non un type de données DAO. Les propriétés et méthodes de collections ne sont pas très compliquées, aussi dressons-en une liste. Propriétés et méthodes des collections Access Les collections Access Forms, Reports, et Controls n'ont pas de méthodes et seulement une propriété : Count, qui renvoie le nombre d'objets dans la collection. Ainsi, la ligne Forms.Count renvoie le nombre de formulaires ouverts dans la base de données courante (nous verrons plus tard, lorsque nous discuterons des objets Container, qu'il y a également une manière d'obtenir le nombre de formulaires sauvegardés). Propriétés et méthodes des collections DAO Les collections DAO se répartissent en deux catégories en regard de leurs propriétés et méthodes. Toutes les collections DAO ont une seule propriété : Count. Toutes les collections DAO ont également la méthode Ree resh, que nous allons aborder un petit peu plus tard. En outre, certaines des collections ont la méthode Append et la méthode Delete correspondante, tandis que d'autres ne les ont pas. Collections qui ont les méthodes Append et Delete Workspaces TableDefs QueryDefs Groups

189 180 Chapitre 9 : Programmation DAO: vue d'ensemble Users Relations Fields Indexes Properties (expliquées plus tard) Collections qui n'ont pas les méthodes Append et Delete Databases Errors Recordsets Containers Documents Parameters À l'évidence, certaines collections n'ont pas les méthodes Append ou Delete parce que le modèle DAO ne veut pas que l'utilisateur ajoute ou efface des objets dans ces collections. C'est raisonnable parce que le modèle DAO prend soin de faire le ménage automatiquement dans ces collections. Par exemple, DAO attache automatiquement de nouvelles bases de données à la collection Databases chaque fois qu'elles sont créées à l'aide de la méthode CreateDatabase. Cependant, il ne procède pas ainsi pour de nouveaux objets TableDefouQueryDef, par exemple. Notez que Microsoft Access accomplit pour vous les tâches ménagères lorsque les objets sont créés et sauvegardés à l'aide de l'interface Access. Propriétés et méthodes de collections définies par l'utilisateur Les objets Collection définis par l'utilisateur ont une propriété : Count. Ils ont trois méthodes: Add, Remove, et Item. Add et Remove agissent comme leur nom l'indique, et nous en verrons un exemple bientôt. La méthode Item est utilisée pour identifier les items dans la collection, puisqu'ils peuvent avoir ou ne pas avoir de nom. Un seule collection définie par l'utilisateur peut contenir des objets de différents types, y compris d'autres collections. Voici un exemple pour illustrer la méthode Add. Dans l'exemple 9-5, nous créons deux collections: colparent et colchild. Nous plaçons colchild dans co/parent, avec l'objet TableDef LIVRES. Ainsi, la collection colparent contient deux objets de type très différent-un objet Collection et un objet TableDef

190 Les collections sont aussi des omets 181 (bien que cet exemple n'ait pas beaucoup de valeur pratique, il illustre bien le propos). Exemple 9-5. Un exemple de Collections Dans l'exemple 9-5, nous avons utilisé la méthode Add de l'objet collection pour ajouter des items à la collection et la propriété Count de l'objet collection, qui retourne la taille de la collection. Notez aussi l'utilisation de la déclaration TypeOf pour déterminer le type de chaque objet dans la collection. Considérons maintenant la méthode Item, qui retourne un objet spécifique d'une collection. La syntaxe générale est ou index est un index de la collection. Notez que les collections DAO démarrent à l' index 0 et vont à l'index Collection. Count - 1. Pour illustrer la méthode Item, à la place du code

191 182 Chapitre 9 : Programmation DAO: vue d'ensemble de l'exemple précédent, nous pourrions écrire Remarquons que la position ordinale d'un objet dans une collection n'est jamais garantie et qu'elle peut changer parfois sans préavis. Ainsi, par exemple, il ne serait pas sage de compter sur le fait que l'objet Item(0) à un certain moment restera toujours l' Item (0) par la suite. L'un des inconvénients des collections qui contiennent différents types d'objets, comme dans l'exemple précédent, est que nous pouvons rarement appliquer le même traitement à tous les objets de la collection. Pour cette raison, la création de collections contenant différents types d'objets n'est pas très utile en général. Dites-le de nouveau Il est bon de souligner une fois de plus que les collections dans la hiérarchie DAO ne sont pas contenues dans leurs collections parentes (comme c'est le cas pour les collections définies par l'utilisateur dans l'exemple précédent). Par exemple, la collection TableDefs contient seulement des objets TableDef. Elle ne contient pas la collection Fields. Mieux, chaque objet TableDef contient une collection Fields. Nous pouvons confirmer ceci grâce au code de l'exemple 9-6 qui affiche la taille de la collection TableDefs pour la base de données LIBRARY à 14 et ensuite les noms de chacun de ses 14 objets, prouvant qu'il n'y a rien d'autre que les objets TableD j dans la TableDefs. Exemple 9-6. Un exemple TableDef

192 Les collections sont aussi des objets 183 Exemple 9-6. Un exemple TableDef Le lancement du code de l'exemple 9-6 produit la boîte de message de la figure 9-8 ; elle montre aussi que la plupart des TableDefs dans la base de données sont des définitions système des tables, créées par Microsoft Access pour son propre usage. Pour le cas où des tables supplémentaires auraient été ajoutées à la base de données LIBRARY après l'impression de ce livre, vous trouverez de légères différences dans la liste des tables lorsque vous lancerez cet exemple. Il illustre aussi l'utilisation de la fonction TypeName. Figure 9-8. Une liste de TableDefs générée par exacbecletabledefso Rafraîchissement de certaines collections Il arrive parfois que le moteur jet de Microsoft n'ait pas les dernières informations sur les contenus d'une collection. Par exemple, ceci peut arriver dans un environnement multi-utilisateurs, lorsqu'un un utilisateur effectue un changement dans une collection. Cela peut arriver également lorsque l'environnement hôte, tel que Microsoft Access, effectue un changement à l'environnement. Pour le constater, tentez l' expérience très simple qui suit.

193 184 Chapitre 9 : Programmation DAO: vue d'ensemble Entrez le code suivant Lancez la procédure. Vous devriez obtenir un message disant qu'il y a 13 tables dans la collection TableDefs. Utilisez maintenant Microsoft Access pour créer une nouvelle table et la sauvegarder. Puis relancez le code ci-dessus. Il va renvoyer un rapport indiquant qu'il y a toujours 13 tables! Enlevez maintenant la marque (') de commentaire sur la ligne: et relancez le code. Vous devriez obtenir maintenant un compte juste du nombre de tables. Le problème est que le moteur jet ne garde pas de trace des tribulations de son application hôte-microsoft Access. En conséquence, pour être certain qu'une collection est à jour, vous devez utiliser la méthode Refresh. La collection Properties La collection Properties est un item qui a été laissé de côté dans le diagramme du modèle objet DAO, illustré plus haut à la figure 9-5 (c'est ainsi dans la plupart des diagrammes DAO). C'est parce que chaque objet DAO a une collection Properties, ce qui encombrerait considérablement le diagramme, sans apporter beaucoup plus d'information. La figure 9-9 montre une collection Properties. Figure 9-9. Diagramme Access des collections de propriétés

194 La collection Properties 185 Le but des collections Properties est simple. Les propriétés sont aussi des objets contenus dans des collections, juste comme les autres objets du modèle DAO ( excepté DBEngine). Ainsi, la collection Properties d'un objet contient les objets Property (mieux connus sous le nom de propriétés) de l'objet. Le fait que les propriétés d'un objet sont elles-même des objets, et ainsi résident dans une collection, implique que l'on peut accéder à ces propriétés de différentes manières. Par exemple, on peut se référer à la propriété RecordCount de l'objet TableDef LIVRES des différentes manières suivantes (entre autres) ou simplement Naturellement, la dernière forme est la plus simple et la plus utilisée. Notez que la collection Properties n'est jamais la collection par défaut pour aucun objet. En conséquence, par exemple, la syntaxe (qui diffère de la précédente uniquement par un bang) va conduire VBA à rechercher l'objet RecordCount dans la collection Fields par défaut pour l'objet TableDe LIVRES. Naturellement, il ne va pas trouver un tel objet et le message d'erreur Item non trouvé dans cette collection va en résulter. Les vertus des collections de propriétés L'existence de collections Properties présente plusieurs avantages. L'un d'eux est la possibilité de procéder par itérations à travers toutes les propriétés d'un objet, en utilisant par exemple la syntaxe For Each, examinée précédemment, sans même connaître les noms des propriétés. Par exemple, le code suivant sort la liste de toutes les propriétés de l'objet LIVRES

195 186 Chapitre 9 : Programmation DAO: vue d'ensemble Une autre vertu des collections Properties est qu'elles autorisent la création (et le stockage) de nouvelles propriétés. Types de propriétés En général, les propriétés d'un objet peuvent être classées en trois groupes, en fonction de leur origine Propriétés natives Propriétés définies par l'application Propriétés définies par l'utilisateur Le moteur jet de base de données définit des propriétés natives pour ses objets. Par exemple, un objet TableDef a une propriété Name incorporée. En outre, Microsoft Access (et d'autres applications qui peuvent utiliser le moteur jet) peut créer des propriétés définies par l'application. Par exemple, si vous créez une table dans Microsoft Access et si vous remplissez le champ Description dans la boîte de dialogue Vue... Propriétés, Access crée une propriété Description pour la table et l'accroche à la collec tion Properties pour cet objet TableDef. Finalement, comme nous le verrons plus tard, l'utilisateur peut créer ses propres propriétés. Il est important de noter qu'une propriété définie par l'application est créée seulement si l'utilisateur attribue une valeur à cette propriété. Par exemple, si vous ne tapez pas de description dans le champ Description, alors Access ne créera pas une propriété Description. En d'autres termes, Access ne crée pas une propriété Description vierge. Si vous utilisez cette propriété dans votre code, une erreur est générée. Ainsi, lors de l'écriture de programmes qui se réfèrent soit à des propriétés définies par l'application, soit à des propriétés définies par l'utilisateur, il est important de traquer les erreurs, pour le cas où la propriété référencée n'existerait pas.

196 La collection Properties 187 Naturellement, chaque objet Properly, étant un objet, a ses propres propriétés, mais vous serez heureux d'apprendre que ces propriétés n'ont pas d'objets Property. Où cela va t-il finir? Mentionnons également que les propriétés peuvent être classées en trois catégories lecture/écriture, lecture seule, ou écriture seule. Un propriété lecture/écriture peut être à la fois lue et écrite (c-à-d, modifiée), tandis qu'une propriété en lecture seule peut être lue mais non modifiée et une propriété en écriture seule peut être modifiée mais non lue. Lorsqu'un objet est créé la première fois, ses propriétés en lecture/écriture peuvent être configurées. Cependant, dans de nombreux cas, une fois que l'objet est ajouté à une collection, certaines de ces propriétés sont accessibles en lecture seule et ne peuvent plus désormais être modifiées. Les propriétés d'un objet Propery sont décrites ci-dessous. Un objet Propery n'a pas de méthodes. Propery : Inherited Pour les objets Propery natifs, cette valeur est toujours 0 (False). Pour les propriétés définies par l'utilisateur, cette valeur est vraie si la propriété existe parce qu'elle a été héritée d'un autre objet. Par exemple, tout objet Recordset qui est créé à partir d'un objet,querydef hérite des propriétés de QueryDef. Property : Name La propriété Name habituelle, qui dans ce cas est le nom de la propriété représentée par cet objet propriété. Propery : Type Cette valeur donne le type de données de l'objet. Notez que la propriété Type est de type lecture/écriture jusqu'au moment où l'objet Property est attaché à la collection Properties, après quoi il est de type lecture seule. La valeur de la propriété Type est un entier. VBA fournit des constantes natives de sorte que nous n'avons pas besoin de nous souvenir des valeurs entières. La table 9-4 donne les valeurs, avec leur traduction numérique, qui sont retournées dans le code telles que Ms Box Property.Type. Table 9-4. Constantes pour la propriété Type dans VBA Type de données Constante Valeur numérique Boolean dbboolean 1 Byte dbbyte 2

197 188 Chapitre 9 : Programmation DAO: vue d'ensemble Table 9-4. Constantes pour la propriété Type dans 1-'BA (suite) Type de données Constante Valeur numérique Integer dblnteger 3 Long dblong 4 Currency dbcurrency 5 Single dbsingle 6 Double dbdouble 7 Date/Time dbdate 8 Text dbtext 10 Long Binary (Objet OLE) dblongbinary 11 Memo dbmemo 12 GUID dbguid 15 Property : Value Finalement, nous obtenons la propriété principale de l'objet Property-sa valeur, qui peut être toute valeur compatible avec la propriété assignée Type de l'objet Property. Considérons un autre exemple d'utilisation de la collection Properties. Le code dans l'exemple 9-7 affiche tout le contenu de la collection Properties pour l'objet TableDef LIVRES dans la base de données LIBRARY. Exemple 9-7. Exemple de collection Properties

198 La collection Properties 189 Exemple 9-7. Exemple de collection Properties Le lancement de cette procédure donne la fenêtre illustrée à la figure 9-10, où chaque ligne est de la forme Name = Value (Type) Inherited. Figure 9-I0. I eiieb e généree pur!'exécution de exapropertieso Propriétés définies par l'utilisateur Nous avons mentionné qu'un utilisateur peut ajouter à un objet des propriétés définies par lui. Considérons un exemple d'ajout d'une nouvelle propriété à l'objet TableDef LIVRES. Le code de l'exemple 9-8 ajoute la propriété définie par l'utilisateur appelée UserProperty à la table LIVRES. Il utilise la méthode CreatePropery de l'objet TableDef.. Exemple 9-8. Un exemple de propriétés définies par l'utilisateur

199 190 Chapitre 9 : Programmation DAO: vue d'ensemble Exemple 9-8. Un exemple de propriétés définies par l'utilisateur (suite) Cette procédure génère la fenêtre illustrée à la figure Notez la dernière propriété de la liste. Figure Fenêtre générée par l'exécution de exauserd fnedproperties() Fermeture d'objets DAO Nous devons faire quelques remarques sur la fermeture d'objets DAO qui ont été ouverts par programmation. Les objets Database, Recordset, et Workspace ont chacun une méthode Close. Cette méthode va enlever ces objets de leurs collections respec

200 Un cou# d'ail sur les ob ets DAO 191 Cives. C'est approprié aux trois types d'objet mentionnés ci-dessus pour les raisons suivantes La collection Databases est définie comme la collection de tous les objets Database ouverts. Les objets Recordset sont des objets temporaires, à utiliser uniquement pour des manipulations de données. Les tentatives de fermeture de l'objet Workspace par défaut sont ignorées, mais vous pouvez fermer d'autres objets Workspace. Notez que les objets de type autre que les trois mentionnés ci-dessus sont conçus pour être des membres permanents de leurs collections, stockés sur disque dans le fichier Access mdb. Cependant, ils peuvent être supprimés de leurs collections respectives à l'aide de la méthode Delete. Voici quelques avertissements à garder en mémoire, concernant la fermeture d' objets : Comme nous le verrons au chapitre 11, Programmation DAO : Langage de manipulation de données, vous devriez mettre à jour (c-à-d, compléter) toutes les éditions en attente avant de fermer un objet Recordset ouvert. Lorsqu'une procédure qui déclare un objet Recordset ou Database est quittée, l' ensemble d'enregistrements ou la base de données sont fermés; toute les modifications non sauvegardées ou les éditions en attente sont perdues. Si vous fermez un objet Database tandis que des objets Recordset sont encore ouverts ou si vous fermez un objet Workspace tandis que l'un quelconque de ses objets Database est ouvert, ces objets Recordset seront automatiquement fermés et toutes les mises à jour pendantes et les éditions en attente seront perdues. Un coup d ceil sur les objets DAO Maintenant, nous pouvons regarder brièvement chacune des collections (et leurs objets) dans le modèle objet DAO. Nous examinerons chaque objet et mentionnerons quelques unes des propriétés et méthodes les plus souvent utilisées. Une liste complète de toutes les collections, méthodes et propriétés de chaque objet est donnée à l'annexe A, Collections, propriétés et méthodes DAO 3.0/3.5.

201 192 Chapitre 9 : Programmation DAO: vue d'ensemble Objet DBEngine L'objet DBEngine, dont il n'existe qu'un exemplaire, représente le moteur de base de données jet. C'est le seul objet du modèle DAO qui n'est pas contenu dans une collection. Nous avons vu plusieurs exemples de son utilisation, nous avons aussi noté que la collection par défaut pour l'objet DBEngine est Workspaces, et ainsi est équivalent à Nous avons vu également que signifie la première base de données dans le premier espace de travail (par défaut). L'objet DBEngine a des méthodes pour, entre autres, créer un nouvel espace (CreateWorkspace), compacter une base de données (CompactDatabase) et réparer une base de données (RepairDatabase). Erreurs De temps en temps, une opération peut causer une ou plusieurs erreurs. Lorsque ceci arrive, la collection Errors est d'abord vidée puis remplie par un objet Error pour chaque erreur causée par l'opération (certaines opérations peuvent causer plus d'une erreur). Notez que si aucune erreur ne survient, la collection Errors demeure dans l'état où elle était avant l'opération. L'exemple 9-9, qui délibérément produit une erreur, illustre l'utilisation de la collection Errors. Il montre également l'utilisation de trois propriétés de l'objet Error: Number (le numéro d'erreur de VBA), Description (une description texte de l'erreur), et Source (l' objet ou l'application qui a généré l'erreur). Exemple 9-9. Un exemple de collection Errors

202 Un coup d'ail sur les objets DAO Exemple 9-9. Un exemple de collection Errors (suite) 193 Le lancement du code donne la fenêtre à la figure Figure Message d'erreur provenant de l'exécution de exaerrorscollectiono Espaces de travail (Workspace) Il y a un objet Workspace pour chaque session de travail dans Access. Dans un environnement mono-utilisateur, il y a généralement une seule session en cours. Lorsqu' un utilisateur démarre Access sans activer d'options sécuritaires, Access automatiquement crée un espace de travail appelé Comme nous ne sommes pas concernés dans ce livre par les configurations multiutilisateurs et les problèmes de sécurité de base de données, nous ne créerons pas des espaces de travail multiples.

203 194 Chapitre 9 : Programmation DAO: vue d'ensemble Les valeurs des propriétés Name et UserName de l'objet Workspace par défaut sont aisément déterminées en lançant le code suivant Ce code devrait produire trois boîtes de message, indiquant qu'il n'y a qu'un seul espace de travail ouvert, avec pour nom #Default lorkspace# et un nom d'utilisateur admin. Parmi les méthodes d'un objet Workspace il y a CreateDatabase (pour créer une nouvelle base de données) et OpenDatabase (pour ouvrir une base de données existante). Un autre groupe intéressant de méthodes est BeginTrans, CommitTrans et Rollback, qui permet au programmeur de grouper plusieurs opérations en une tion. À la fin de la transaction, le programmeur peut effectuer les opérations ou ramener la base de données à son état antérieur à toutes les opérations de la transaction. Un exemple d'utilisation est la mise à jour de tables liées (comme lors de transferts de sommes d'argent d'une table à une autre). Si le groupe entier d'opérations n'est pas achevé avec succès, alors un retour arrière est probablement souhaitable. Les objets Workspace ont aussi une méthode Close, pour fermer des espaces de travail ouverts. Cependant, la méthode est ignorée lorsqu'elle est appliquée à l'objet Workspace par défaut dans Microsoft Access. Utilisateurs Le moteur jet fournit une sécurité en attribuant des autorisations d'accès aux utilisateurs du moteur. Un objet User représente un utilisateur du moteur jet. La collection Users contient tous les objets User (naturellement, les utilisateurs féminins ne sauraient évidemment être considérés comme des objets). Groupes Un objet Group représente un jeu d'objets User (utilisateurs) qui ont un jeu commun de permissions d'accès. En utilisant des objets Group, tout nouvel utilisateur reçoit un jeu de permissions d'accès, simplement par addition de l'objet User correspondant à l'objet Group approprié. La collection Groups contient tous les objets Group.

204 Un coup d'ceil sur les objets DAO 195 Bases de données Un objet Database représente une base de données couramment ouverte. Dans Microsoft jet, vous pouvez avoir plusieurs bases de données ouvertes en même temps (en utilisant la fonction OpenDatabase, examinée au chapitre 10). Cependant, l'environnement Microsoft Access ne peut afficher qu'une interface graphique pour une seule base de données. Dans l'environnement Microsoft Access, l'ouverture d' une base de données correspond à : DBEngine.IWorkspaces(0).Databases(O). Les objets Database ont plusieurs méthodes pour la création de nouveaux objets CreateProperly, CreateQueyDef, CreateTableDef, et OpenRecordset. Il y a aussi une méthode Execute pour lancer des requêtes action ou exécuter des instructions SQL sur la base de données. Comme nous l'avons mentionné, les objets Database ont une méthode Close. TableDefs Un objet TableDef représente une définition de table pour une table sauvegardée dans la base de données. Un objet TableDef est plus qu'un schéma de table, en ce sens qu'il a une propriété RecordCount qui donne le nombre de lignes dans la table (et ainsi, dans un certain sens, reflète les données dans la table). Cependant, il est moins qu'une table, car il ne décrit pas les données courantes de la table. La collection TableDefs contient tous les objets TableDef pour une base de données spécifiée. Les objets TableDef ont des méthodes pour créer des champs (CreateField, pour créer des index (Createlndex) et ouvrir des ensembles d'enregistrements (Open-Recordset). QueryDefs Un objet QueyDef représente une requête sauvegardée dans la base de données. La collection Que?yDefs contient tous les objets QueryDef pour une base de données spécifiée. L'une des propriétés les plus intéressantes d'un objet QueryDef est SQL, qui peut être utilisée pour paramétrer ou lire la définition SQL de l'objet QuegDef. Jeux d'enregistrements Un objet Recordset représente les données en provenance d'une ou plusieurs tables ou requêtes, et est utilisé pour manipuler ces données. Notez qu'un objet Recordset est temporaire et qu'il n'est pas sauvegardé avec l'application. En fait, les jeux d'enregistrements sont créés en utilisant la fonction OpenRecordset. La collection Recordsets contient tous les objets Recordset ouverts dans la base de données courante.

205 196 Chapitre 9 : Programmation DAO: vue d'ensemble Les objets Recordset sont le cheval de trait du modèle objet DAO, avec environ 15 méthodes et 20 propriétés différentes. Il y a en fait trois types d'objets Recordset - Table-type, Dynaset, et Snapshot-utilisés pour différents buts. Nous aborderons la notion de jeux d'enregistrements au chapitre 10. Relations Un objet Relation représente une relation entre certains champs dans des tables ou des requêtes. L'objet Relation peut être utilisé pour visualiser ou créer des relations. La collection Relations contient tous les objets Relation pour une base de données spécifiée. Nous aborderons la création de relations au chapitre suivant. Conteneurs Le moteur jet de Microsoft fournit la collection Containers comme emplacement où une application hôte, telle que Microsoft Access, peut stocker ses propres objets. Ceci est réalisé par l'utilisation d'objets Container (conteneur) et illustré à la figure Figure Diagramme des objets Container du moteur Jet Le moteur jet lui-même crée trois objets Container: Un objet Container Databases, contenant de l'information sur la base de données

206 Un coup d'ail sur les ob ets DAO 197 Un objet conteneur Tables, contenant de l'information sur chaque table et requête sauvegardée Un objet conteneur Relations, contenant de l'information sur chaque relation sauvegardée Il est important de ne pas faire de confusion entre ces objets Container (qui ne sont pas des collections, en dépit de leur nom) avec les collections Databases, TableDefs et Relations. Ces objets sont à des emplacements complètement différents dans la hiérarchie objets du modèle DAO et servent différents objectifs, comme nous le verrons. En plus des objets Container créés par le moteur jet, Microsoft Access entrepose ses formulaires, rapports, macros et modules dans la collection Containers. C'est pourquoi la collection Containers contient également Un objet conteneur Forms, contenant de l'information sur tous les formulaires sauvegardés Un objet conteneur Reports, contenant de l'information sur tous les rapports sauvegardés Un objet conteneur Macros, contenant de l'information sur toutes les macros sauvegardées Un objet conteneur Modules, contenant de l'information sur tous les modules sauvegardés Les objets conteneurs Forms et Reports ne doivent pas être confondus avec les collections Microsoft Access du même nom (dans le modèle objet Access). En particulier, le premier contient de l'information sur tous les objets sauvegardés, tandis que le dernier contient de l'information sur tous les objets ouverts. Pour illustrer la différence mentionnée plus haut, créez et sauvegardez deux formulaires dans une session Access et assurez-vous qu'un formulaire est ouvert. Ensuite, lancez le code de l'exemple 9-10, qui doit renvoyer que le formulaire ouvert est 1 et le formulaire sauvegardé est 2. Exemple Un exemple de collection Containers

207 198 Chapitre 9 : Programmation DAO: vue d'ensemble Exemple Un exemple de collection Containers (suite) Notez qu'un utilisateur ne peut pas créer de nouveaux objets Container ni supprimer des objets existants-ils sont contrôlés par le moteur jet uniquement. Autrement dit, il n'y a rien qui pourrait ressembler à un objet Container défini par l'utilisateur. Les propriétés d'un objet Container reflètent généralement des préoccupations liées à la sécurité, tels que permissions et noms d'utilisateur/groupes. Les objets Container n'ont pas de méthodes. Documents Nous avons vu que des applications (y compris jet et Access) entreposent des objets à l'aide d'objets Container. Cependant, l'objet Forms Container, par exemple, n'a pas de réel intérêt en soi. Ce sont les objets Form qui résident dans l'objet conteneur Forms qui présentent de l'intérêt. En réalité, ces objets Form sont adressés en tant qu'objets Document et sont contenus dans la collection Documents du conteneur Forms, ce qui est illustré à la figure 9-6 (si vous êtes un peu désorientés, la figure 9-6 devrait vous aider-elle m'aide toujours). Ainsi, ce sont les objets Document (dans une collection Documents) qui sont la raison d'être des objets Container. L'exemple suivant illustre quelques-unes des propriétés d'un objet Document : Container, DateCreated, LastUpdated, Name et Owner. L'exemple 9-11 affiche la valeur de différentes propriétés des objets Document de la collection Documents de l'objet Container Tables. Exemple Propriétés de l'objet Document

208 Un coup d'ceil sur les objets DAO 199 Exemple Propriétés de l'objet Document (suite) Voici un extrait des sorties provenant de l'exécution de l'exemple 9-11: Champs La collection Fields contient des objets Field, qui décrivent les différents champs dans un objet TableDef, QueryDef, Index, Relation ou Recordset.

209 200 Chapitre 9 : Programmation DAO: vue d'ensemble Paramètres Les paramètres d'une requête paramètre sont représentés par les objets Parameter, contenus dans la collection Parameters pour cet objet QuenIDef. Notez que les objets Parameter ne peuvent être ajoutés ni enlevés d'une collection Parameters -les objets Parameter représentent des paramètres existants. Considérons un exemple. Le code de l'exemple 9-12 crée une requête paramètre appelée ParametetQuery et démontre certaines des propriétés d'un objet Parameter,-précisément, Name, Type, et Value. Exemple Un exemple de requete paramètre Index Une collection Indexes contient tous les objets Index sauvegardés (c-à-d, indices) pour un objet TableDef. Nous aborderons la création d'un index au chapitre suivant. La fonction CurrentDb Nous avons vu que DAO se réfère à la base de données courante comme suit DBEngine.Workspaces(O).Databases(O)

210 La fonction CurrentDb 201 ou, à travers des collections par défaut, comme Cependant, dans Microsoft Access, il y a une manière préférentielle de se référer à cette base de données, puisque, contrairement à DBEngine(0)(0), elle est toujours courante en regard des modifications faites dans l'interface graphique Access. Cette manière préférentielle consiste à utiliser la fonction Access CurrentDb. Malheureuse ment, il existe une certaine imprécision quant au rôle de cette fonction. Voici un extrait du système d'aide Access (versions Access 7.0 et Access 8.0) consacré à cette fonction La fonction CurrentDb retourne une variable objet de type Database qui représente la base de données actuellement ouverte dans la fenêtre Microsoft Access. La fonction CurrentDb fournit une manière d'accéder à la base de données courante depuis un code Visual Basic sans avoir à connaître le nom de la base de données. Dès que vous avez une variable qui pointe vers la base de données courante, vous pouvez également accéder à d'autres objets et collections et les manipuler dans la hiérarchie des objets d'accès aux données. Vous pouvez utiliser la fonction CurrentDb pour créer des variables objet multiples qui se réfèrent à la base de données courante. Dans l'exemple suivant, les variables dbsa et dbsb se réfèrent toutes deux à la base de données courante : Ceci fait apparaître que les variables objet dbsa et dbsb pointent apparemment vers un objet Database unique, précisément la base de données actuellement ouverte. En d' autres termes, l'exécution de l'instruction Set db = CurrentDb implique que db pointe vers l'objet Database connu du modèle DAO comme étant DBEngine(0)(0). Cependant, le système d'aide poursuit ainsi

211 202 Chapitre 9 : Programmation DAO: vue d'ensemble Note: dans les versions précédentes de Microsoft Access, vous avez peut-être utilisé la syntaxe DBEngine.Workspaces(0).Databases(O), ou DBEngine(0)(0) pour retourner un pointeur à la base de données courante. Dans Microsoft Access pour Windows 95, vous deviez utiliser la fonction CurrentDb à sa place. La fonction CurrentDb crée une autre instance de la base de données courante, tandis que la syntaxe DBEngine(O)(0) se réfère à la copie ouverte de la base de données courante. L'utilisation de la fonction CurrentDb vous permet de créer plus d'une variable de type Database qui se réfère à la base de données courante. Microsoft Access continue à supporter la syntaxe DBEngine(O)(0), mais vous devriez envisager de modifier votre code pour éviter de possibles conflits dans un environnement multiutilisateurs. Ceci semble contredire les déclarations précédentes, en indiquant que chaque fois que CurrentDb est exécuté, il crée un nouvel objet Database. En fait, si la base de données courante est considérée comme un objet, alors la mention "... crée une autre instance de la base de données courante..." n'a pas de sens, puisqu'on ne peut pas créer une instance d'un objet (en termes orientés objet, on peut créer une instance d'une classe, et une telle instance est appelée un objet). En tous cas, chaque appel à CurrentDb semble créer un nouvel objet, comme nous pouvons le remarquer d'après l'expérience de l'exemple 9-13, qui vérifie la propriété Count de la collection Databases à la fois avant et après l'appel de CurrentDb, montrant que le compteur croît!

212 La fonction CurrentDb 203 Exemple Un exemple de fonction CurrentDb Si chaque appel à CurrentDb produit un pointeur vers un nouvel objet, alors il est naturel de se demander ce qui se passe lorsque nous modifions l'objet pointé par l'un de ces pointeurs. Cela affecte t-il les autres objets? Qu'en est-il de DBEngine(0)(0)? Considérons le code de l'exemple 9-14, qui effectue les tâches suivantes crée deux variables objet Database dbone et dbtwo, et les définit toutes deux égales à CurrentDb Ajoute un nouveau champ NewFieldl à la table LIVRES utilisant dbone Ajoute un nouveau champ NewField2 à la table LIVRES utilisant dbtvo Affiche la liste des champs de LIVRES utilisant dbone Affiche la liste des champs de LIVRES utilisant dbtwo Ferme dbone et dbtwo; c-à-d, enlève leurs objets de la collection Databases

213 204 Chapitre 9 : Programmation DAO: vue d'ensemble Lancement de exacurrentdb2 Pour examiner le comportement de la procédure décrite à l'exemple 9-14, suivez ces étapes 1. Lancez le programme tel quel. Access affiche la boîte de dialogue de la figure Effacez NewFieldl et NewField2 de la table LIVRES. Pour cela, ouvrez la table dans la vue Conception d'access, sélectionnez chaque champ séparément et choisissez l'option Supprimer une ligne depuis le menu Edition. 3. Commentez (utilisez l'instruction Rem ou le caractère ') l'appel à la méthode Refresh, puis lancez la procédure. Access affiche la boîte de dialogue de la figure Une fois encore, effacez NewFieldl et NewField2 de la table LIVRES. 5. Enlevez le commentaire de l'appel à la méthode Refresh et modifiez-là pour lire dbtwo.tabledefs!books.fields.refresh. Lorsque vous lancez la procédure, Access affiche de nouveau la boîte de dialogue de la figure Supprimez une fois de plus NewFieldl et NewField2 de la table LIVRES. Il est nécessaire de supprimer à la fois NewFieldl et NewField2 chaque fois que vous lancez une variante de cette procédure, car autrement Access affiche un message d'erreur "Multiple définition d'un champ impossible".

214 La fonction CurrentDb 205 Exemple Exemple de variables dbone et dbtwo L'exécution de ce code donne la fenêtre illustrée à la figure Figure Boîte de messages à l'exécution de exacurrentdb2o

215 206 Cha itre 9 : Pro'rammation DAO: vue d'ensemble Ainsi, il apparaît que la modification de l'objet Database vers lequel pointe dhtwo modifie en fait l'objet Database vers lequel pointe dbone. Cependant, si nous ne rafraîchissons la collection Fields à l'aide de la variable dbone, ou si nous rafraîchissons à l'aide de la variable dbtwo à la place, nous obtenons la boite de message illustrée à la figure Notez que NewField2 manque dans le second groupe. Figure Boîte de messages à l'exécution de exacurrentdb2o lors d'un rafraîchissement avec dhtwo Notez aussi que même avant que les deux objets dbone et dbtwo soient fermés, l' interface graphique Access a été mise à jour pour renvoyer les deux nouveaux champs. En fait, si vous enlevez le commentaire en tête de la ligne Stop dans le code ci-dessus et vérifiez la structure de la table LIVRES dans Access, vous voyez apparaître les deux nouveaux champs, et cela même avant que la méthode Refresh soit appelée. Cette expérimentation nous laisse avec le sentiment qu'il y a des mystères associés à CurrentDb que Microsoft ne révèle pas (du moins sous une forme lisible). Nous pouvons résumer comme suit Invoquer CurrentDb crée un autre membre de la collection Databases. D'autre part, chaque variable paramétrée par CurrentDb semble affecter la même base de données.

216 La fonction CurrentDb 207 Le rafraîchissement est requis pour conserver les objets créés par de multiples invocations de CurrentDb, sous-tendant l'objectif de CurrentDb jusqu'à un certain point. D'autre part, l'interface Access ne réclame pas de rafraîchissement-elle reflète les dernières opérations effectuées en utilisant chacune des invocations de CurrentDb. Malgré ces problèmes, il est de bon sens de suivre les recommandations de Microsoft quant à l'utilisation de CurrentDb, car c'est le reflet plus exact de l'état actuel de l' environnement Access que DBEngine(0)(0). Il est toutefois conseillé de faire preuve de prudence (rafraîchissement) lors de la création de plus d'une variable à l'aide de CurrentDb. Finalement, si vous voulez utiliser CurrentDb, vous devez le faire en accord avec les règles de Microsoft, énumérées dans le fichier acreadme.txt d'access 7.0 (mais absentes du fichier acread80.uri d'access 8.0). Ce texte est reproduit ci-dessous. Notez l' utilisation du mot "once." Utilisation de la fonction CurrentDb pour retourner une référence à la base de données courante. Lorsque vous écrivez du code qui inclut une référence à la base de données courante, vous devriez déclarer une variable de type Database et utiliser la fonction CurrentDb une fois pour lui attribuer un pointeur vers la base de données courante. Vous devriez éviter d'utiliser CurrentDb pour retourner la base de données courante dans une instruction qui retourne également une référence à un autre objet, comme une instruction Set. Cela était possible dans certaines versions bêta de Microsoft Access, mais dans Microsoft Access pour Windows 95, votre code pourrait ne pas tourner correctement. Par exemple, pour déterminer le nombre d' objets Document dans la collection Documents, vous devriez écrire votre code de la manière qui est illustrée dans les deux exemples suivants ou Un code tel que celui qui suit ne fonctionnera pas

217 208 Chapitre 9 : Programmation DAO: vue d'ensemble Sur le CD-Rom L'ensemble des exemples de ce chapitre sont repris et commentés sur le CD-Rom. Affichez à l'aide de votre navigateur le fichier chap09.htm, qui expose le mode opératoire pour jouer tous les exemples. Ce fichier se trouve placé dans le dossier chap09 du répertoire Exemples. Les thèmes abordés sont les suivants Variables objet Collections Propriétés Objets DAO

218 Dans ce chapitre 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 une requête Sur le CD-Rom 10 Programmation DAO Langage de définition de données Dans notre vue d'ensemble de DAO, nous avons noté que les objets d'accès aux données renferment deux composants conceptuellement distincts : un langage de définition des données (ou DDL) qui permet de créer ou d'accéder aux objets de base des systèmes de bases de données, comme les bases de données, les définitions de tables et les index; et un langage de manipulation de données (ou DML) qui permet d'exécuter des opérations pratiques, telles que l'ajout de données (enregistrements) à des tables, la suppression de données indésirables et la modification de données existantes. Dans ce chapitre, nous examinerons le langage de définition des données (DDL) qui est l'un des aspects des DAO. Commençons par noter ce qui suit Pour indiquer des variables d'un certain type, nous écrirons le nom du type suivi du suffixe Var. Par exemple, Database Var indique une variable de type Database et TableD JVarindique une variable de type TableDef. En décrivant la syntaxe de certaines méthodes, nous utiliserons des crochets droits ([ ]) pour indiquer des items optionnels. Nous donnerons en général la syntaxe complète des méthodes, mais nous ne fournirons des détails que sur les options les plus répandues. Naturellement, les détails complets sont disponibles par l'intermédiaire du système d'aide Access. 209

219 210 Chapitre 10 : Programmation DAO : LaneaRe de définition de données Créer une base de données Les bases de données sont créées en utilisant la méthode CreateDatabase d'un objet Workspace. La syntaxe générale de cette méthode est où DatabaseName est une expression chaîne représentant le chemin complet et le nom du fichier pour la base en cours de création. Si vous ne précisez pas l'extension du fichier, l'extension mdb est automatiquement ajoutée. locale est une expression chaîne utilisée pour spécifier l'ordre d'assemblage pour la création de la base de données. Vous devez fournir l'argument sinon une erreur survient. Utilisez la constante dblanggenerai.. options concernent les spécifications de chiffrement ou l'utilisation d'une version spécifique du moteur, de base de données jet. Pour plus d'informations, veuillez consulter l'aide d'access. Notes: La méthode CreateDatabase crée un nouvel objet Database, ajoute la base de données à la collection Databases, sauvegarde la base de données sur le disque et retourne ensuite un objet Database ouvert, mais la base de données n'a pas de structure ou de contenu à ce stade. Pour dupliquer une base de données, vous pouvez utiliser la méthode CompactDatabase d'un objet Workspace, spécifiant un nom différent pour la base de données compactée. Une base de données ne peut pas être supprimée par programmation DAO. Pour supprimer une base de données en programmation utilisez la déclaration KILL dans VBA. L'exemple 10-1 crée une nouvelle base de données appelée MoreBks.mdb dans le répertoire c./temp, et alors liste les tables qui sont contenues dans la base de données. Exemple Exemple de méthode Database

220 Créer une table et ses champs 211 Exemple Exemple de méthode Database (suite) Le programme de l'exemple 10-1 affiche la liste de tables suivante Ces tables sont créées par Microsoft Access pour son propre usage. Ouvrir une base de données Pour ouvrir une base de données existante, utilisez la méthode OpenDatabase d'un objet Workspace. La syntaxe est dans laquelle DatabaseName est le nom d'une base de données existante (comme l' indiquent les crochets droits, les autres paramètres sont optionnels). Pour plus d' informations sur les paramètres optionnels, consultez le système d'aide d'access. Il est important de ne pas oublier de fermer une base de données, qui a été ouverte à l' aide de la méthode OpenDatabase. Ceci enlève la base de données de la collection Databases. Créer une table et ses champs Les tables sont créées en utilisant la méthode CreateTableDef d'un objet Database. La syntaxe complète de cette méthode est où

221 212 Chapitre 10 :Pro grammation DAO : LanRaRe de définition de données TableD fnme est une chaîne ou une variable chaîne contenant le nom du nouvel objet TableDef. Pour plus d'informations sur les paramètres optionnels, voyez le système d'aide d'access. Notes: Le nouvel objet TableDef doit être accroché à la collection TableDefs en utilisant la méthode Append. Cependant, avant l'opération, la table doit avoir au moins un champ. CreateTableDef ne vérifie pas s'il existe un TableD jname déjà utilisé. Si TableDeJName se réfère à un objet déjà présent dans la collection TableDefs, une erreur survient après que vous ayez utilisé la méthode Append, mais non avant. Pour enlever un objet TableDef d'une collection TableDefs, utilisez la méthode Delete. Les champs sont créés pour une table en utilisant la méthode CreateField de l'objet Table Def. La syntaxe est dans laquelle FieldName est une chaîne ou une variable chaîne qui attribue un nom à l'objet Field. type est une constante entière qui détermine le type de données du nouvel objet Field (voir la table 10-1). site est un entier entre 1 et 255 qui indique la taille maximum, en octets, pour un champ texte. Cet argument est ignoré pour d'autres types de champs. Note: Pour enlever un champ d'un objet TableDef, utilisez la méthode Delete. Table Constantes associées à la propriété Type Type de données Constante Valeur numérique Boolean dbboolean 1 Byte dbbyte 2 Integer dbinteger 3

222 Créer une table et ses champs 213 Table Constantes associées à la propriété Type(suite) Type de données Constante Valeur numérique Long dblong 4 Currency dbcurrency 5 Single dbsingle 6 Double dbdouble 7 Date/Time dbdate 8 Text dbtext 10 Long Binary (OLE Object) dblongbinary 11 Memo dbmemo 12 GUID dbguid 15 Les objets Field ont un grand nombre de propriétés, parmi lesquelles AllowZeroLength : True si une valeur de longueur zero est valide pour un champ texte ou un champ mémo (attribuer cette propriété à un champ non-texte génère une erreur). DefaultValue : Fixe ou retourne la valeur par défaut d'un objet Field. Required : True indique qu'une valeur null n'est pas autorisée ValidationRule et ValidationText : Utilisés pour la validation de valeurs de champ (voir l'exemple suivant). La procédure à l'exemple 10-2 crée une nouvelle table nommée NewTable, crée un nouveau champ nommé NewField, fixe certaines propriétés du champ et l'ajoute à la collection Fields, et ensuite accroche la nouvelle table à la collection TableDefs. Exemple Un exemple de méthode CreateTableDef

223 214 Chapitre 10 :Pro Exemple Un exemple de méthode CreateTableDef (suite) grammation DAO. Langage de définition de données Fixer les propriétés de validation d'un champ requiert de définir deux propriétés. La propriété ValidationRule est une chaîne de texte qui décrit la règle de validation et ValidationText est une chaîne qui est affichée pour l'utilisateur lorsque la validation échoue. Après l'exécution du code de l'exemple 10-2, une nouvelle table apparaît dans la fenêtre Base de donnée d'access (pour voir la nouvelle table, il se peut que vous soyez obligé de quitter l'onglet Tables puis de revenir à cet onglet). L'ouverture de cette table dans la Vue conception affiche la fenêtre de la figure Notez que le paramétrage des propriétés de champ reflète les propriétés définies dans notre code. Figure Vue Conception de la table générée par l'exécution de exacreatetable( Accessoirement, les objets TableDef ont aussi les propriétés ValidationRule et ValidationText, utilisées pour fixer les règles de validation qui impliquent de multiples champs dans la table.

224 Créer un index 215 Modifier les propriétés d'une table ou d'un champ existants Nous avons remarqué que certaines propriétés accessibles en lecture/écriture avant que l'objet soit ajouté à sa collection sont autorisées en lecture seule après l'addition. Un bon exemple en est la propriété Type d'un champ. D'autre part, la propriété Name d'un champ peut être modifiée. C'est un exemple de changement qui peut être fait à l'aide de DAO mais non via SQL. Créer un index Les index sont créés en utilisant la méthode Createlndex pour un objet TableDef. Voici la syntaxe Par elle-même, la création d'un index ne fait rien. Nous avons ajouté un ou plusieurs champs à la collection Fields de l'index pour indexer la table. L'ordre dans lequel les champs sont ajoutés (lorsqu'il y a plus d'un champ) a plus ou moins un effet sur l'ordre de l'index. Voici un exemple. L'exemple 10-3 ajoute un nouvel index appelé PriceTitle à la table LIVRES. Exemple Un exemple de méthode Createlndex

225 216 Chapitre 10 : Programmation DAO : Lannaje de définition de données Exemple Un exemple de méthode Createlndex (suite) La figure 10-2 affiche le résultat de l'exécution du programme de l'exemple ( pour voir la boîte de dialogue, ouvrez la table LIVRES dans la Vue conception et sélectionnez l'option Index depuis le menu Affichage). La figure montre clairement pourquoi nous avons commencé par créer deux champs-prix et Titre-et les ajoute, dans cet ordre, à la collection Fields de l'index. Figure Vue Index de la table LIVRES après exécution de exacreatelndex( Ainsi que nous l'avons exposé dans un chapitre précédent, l'index d'une table est en fait un fichier qui contient les valeurs des champs qui constituent l'index, avec un pointeur vers les enregistrements correspondants de la table. Microsoft tend à brouiller la distinction entre un index (comme fichier) et les champs qui participent de l' index. Ainsi, pour dire qu'un index est primaire on dit que les champs (en fait, les attributs) faisant partie de l'index constituent une clé primaire. En conservant ceci en mémoire, certaines des propriétés importantes d'un index sont les suivantes : DistinctCount : donne le nombre de valeurs distinctes de l'index. IgnoreNulls : détermine si un enregistrement avec une valeur null dans le champ (ou les champs) index devrait être inclus dans l'index. Primary : indique que les champs index constituent la clé primaire de la table. Required : détermine si tous les champs dans un index multi-champs doivent être remplis.

226 Créer une relation 217 Unique : détermine si les valeurs dans un index doivent être uniques, faisant ainsi des champs index une clé pour la table. v Notez que la différence entre une clé primaire et une valeur d'index unique est qu'une clé primaire ne peut avoir de valeur NULL. Créer une relation Les relations sont créées dans le DAO en utilisant la méthode CreateRelation. La syntaxe est: où RelName est le nom de la nouvelle relation KeejTable est le nom de la table référence de la relation (contenant la clé) Foreign Table est le nom de la table référencée dans la relation (contenant la clé étrangère) Attributes est une constante, dont les valeurs sont affichées à la table 10-2 Table Attributs d'un objet Relation Constante dbrelationunique dbrelationdontenforce dbrelationlnherited dbrelationupdatecascade dbrelationdeletecascade Description Relation de type un-à-un Intégrité référentielle non assurée par le moteur Une relation existe dans une base de données non-concur rente qui contient les deux tables attachées Mises à jour en cascade autorisées Suppressions en cascade autorisées Notes Toutes les propriétés d'un objet Relation sont marquées en lecture seule dès que l' objet est accroché à une collection Relations. Les objets Field pour les tables référencées et référantes doivent être ajoutés à la collection Fields préalablement à l'ajout de l'objet Relation à la collection Relations. Les noms dupliqués ou invalides vont provoquer une erreur lorsque la méthode Append sera invoquée.

227 218 Chapitre 10 : Programmation DAO : Langage de définition de données Pour enlever un objet Relation d'une collection, utilisez la méthode Delete pour cette collection. L'exemple 10-4 illustre l'utilisation des objets Relation. Dans cet exemple, nous allons créer une nouvelle relation dans la base de données LIBRARY. La première étape est de créer une table, en utilisant Microsoft Access. Appelez la table REGIONSVENTE et ajoutez deux champs texte : PubID et SalesRegions. Ajoutez ensuite quelques lignes à la table comme le montre la table Table La table REGIONS VENTE PubID RegionsVente 1 United States 1 Europe 1 Asia 2 United States 2 Latin America Le code de l'exemple 10-4 crée une relation entre le champ PubID de la table EDITEURS (la clé primaire) et le champ PubID de la table REGIONSVENTE (la clé étrangère). Exemple Un exemple de méthode CreateRelation

228 Créer un objet QueryDef 219 Exemple Un exemple de méthode CreateRelation (suite) re 1. Fields. Append fld 'Accroche l'objet Relation à la collection Relations. db.relations.append rel Après avoir lancé ce code, assurez-vous que la fenêtre Base de données est active et sélectionnez Outils... Relations depuis la barre des menus d'access. Sélectionnez ensuite Relations... Afficher tout et vous devriez voir une fenêtre similaire à celle de la figure 10-3, montrant la nouvelle relation! 10 - J. I ohlit' dt.u iilu/lull.~ tli5i /dlit i/jt1i/(it ta211zc/~l/10i1.i~~ Créer un objetquerydef La création d'un objet QueryDef est effectuée en utilisant la méthode CreateQueryDe La syntaxe est. où,queryd fvame est le nom du nouvel objet QuervDef et SQLText est une expression chaîne qui constitue une déclaration valide Access SQL. Notes Si vous incluez,quegdejname, QueryDef est automatiquement sauvegardé (ajouté à la collection QueryDefs appropriée) quand il est créé. La propriété Name et la propriété SQL d'un objet QueryyDef peuvent être modifiées à tout moment.

229 220 Chapitre 10 : Programmation DAO : LanRaAe de définition de données Vous pouvez créer un objet QueryDef temporaire, qui n'est pas attaché à la collection, en attribuant à la propriété QueryD JName une chaîne de longueur nulle (""). Vous ne pouvez pas modifier le nom d'un objet QueryDef temporaire. Si vous omettez l'argument SQLText, vous pouvez définir QueryDef en fixant sa propriété SQL avant ou après l'avoir ajouté à une collection. Pour enlever un objet QueryDef d'une collection QueryDefr, utilisez la méthode Delete. Lancer une requête Au chapitre 6, Langage SQL daccess nous avons vu que Microsoft Access supporte plusieurs types de requêtes. En particulier, une requête select retourne un jeu d' enregistrements, tandis qu'une requête action ne retourne pas un jeu d'enregistrements, mais exerce plutôt une action sur les données existantes, comme la création d'une nouvelle table, la suppression de lignes dans une table, l'ajout de lignes à une table ou la mise à jour des valeurs dans une table. Si un objet QueryDef représente une requête action, nous pouvons utiliser alors sa déclaration Execute pour la lancer. Si l'objet QueryDef représente une requête select, nous pouvons alors ouvrir la table résultats correspondante (jeu d'enregistrements) en utilisant la méthode OpenRecordset sur l'objetquerydef. Illustrons ceci. Le code de l'exemple 10-5 crée une nouvelle requête select et affiche le nombre d' enregistrements pour le jeu d'enregistrements correspondant. Exemple Un exemple de méthode CreateQueryDef

230 Créer un ob 'et I ue De 221 Exemple Un exemple de méthode CreateQueryDef (suite) Le code de l'exemple 10-6 crée une nouvelle requête action et l'exécute. L'effet est d'augmenter le prix de chaque livre de la table LIVRES de 10%. Exemple Exemple de requête action ' Crée une requête action et l'exécute Dès que l'objet QueryDef existe, nous pouvons continuer à utiliser les méthodes OpenRecordset ou Execute pour lancer la requête. La méthode Execute peut être utilisée sur un objet Database pour exécuter une déclaration SQL. Voici un exemple qui réduit le prix de chaque livre de la table LIVRES de 10% Propriétés d'un objet QueryDef Quand un objet QueryDef est créé ou modifié, jet détermine certaines de ses propriétés, telles que DateCreated, LastUpdated et Type (notez que la collection QueyDefs peut nécessiter un rafraîchissement avant que ces propriétés puissent être lues). Certains des types de requêtes possibles sont listés à la table 10-4.

231 222 Chapitre 10 : Programmation DAO : Lan a e de dé nition de données Table Constantes possibles pour les différents types de requêtes Constante Type de requête Valeur dbqselect Select 0 dbqaction Action 240 dbqcrosstab Crosstab 16 dbqdelete Delete 32 dbqupdate Update 48 dbqappend Append 64 dbqmaketable Make-table 80 La propriété RecordsAffected retourne le nombre d'enregistrements affectés par la dernière application de la méthode Execute. Illustrons le propos. L'exemple 10-7 modifie l'exemple antérieur de requête pour exécuter l'action (10% d'augmentation de prix) si, et seulement si, l'augmentation affecte 15 livres ou plus dans la table. Ceci est effectué en utilisant les propriétés BeginTrans, Committrans, et Rollback de l'objet courant Workspace. Exemple Un exemple de propriété RecordsAffected

232 Sur le CD-Rom 223 Exemple Un exemple(suite)de propriété RecordsAffected (suite) Sur le CD-Rom Les différents exemples de ce chapitre se trouvent placés dans quatre documents différents. Pour les consulter, lancez le document d'orientation à l'adresse suivante / exemples/chapl0/chapl0.htm. La base library.mdb dans le sous-répertoire chap10 est spécifique de ce chapitre. La structure d'exposition des exemples et des exercices suit la structure du chapitre et est divisée en quatre thèmes Créer une base et ses tables Créer un index Créer une relation Créer et lancer une requête La base LIBRARY contient un module de programmation avec les exemples de programmes exposés dans ce chapitre. Il est donc conseillé de lancer cette version pour lancer les exemples.

233 Dans ce chapitre Objets Recordset Ouvrir un jeu d'enregistrements Se déplacer dans un jeu Trouver des enregistrements dans un jeu Editer des données en utilisant un jeu Sur le (.D-Rom 11 Programmation DAO Langage de manipulation de données Au chapitre 10, Programmation DAO : langage de d finition de donnée.s nous avons étudié comment utiliser le langage DAO pour créer et accéder aux composants principaux d'une base de données, tels que ses tables, ses index, ou ses définitions de requêtes. Pour l'essentiel, cependant, le point de convergence d'une application de base de données est l'accession et la manipulation d'items discrets de données emmagasinées dans un ou plusieurs enregistrements. Dans ce chapitre, nous continuons notre revue des objets d'accès aux données (Data Access Objects) par l'examen de son composant de manipulation de données, qui vous permet de d'exécuter des opérations pratiques de maintenance telles que l'ajout, la suppression, la mise à jour d' enregistrements et l'accès aux enregistrements que votre application doit afficher. Objets Recordset Le principal outil pour la manipulation de données est l'objet Recordset. Il y a trois types d'objets Recordset L'objet Recordset de type Table est une représentation des enregistrements dans une seule table de la base de données. Il peut être assimilé à une fenêtre ouvrant sur la table. Aussi, les opérations sur ce type de jeu d'enregistrements affectent directement la table. Nous insistons sur le fait qu'un jeu de type Table ne peut être ouvert que pour une table. Il ne peut être ouvert pour une jointure de plus dune table ou pour une requête. Un jeu d'enregistrements de type Table peut être indexé en utilisant un index table. Ceci permet de manoeuvrer plus rapidement à l'intérieur de la table, en utilisant la méthode Seek, que nous expliquerons plus loin dans ce chapitre. 22 5

234 226 Chapitre 11: Programmation DAO : Langage de manipulation de données Un objet Recordset de type Dynaset est un jeu d'enregistrements dynamique (modifiable) qui peut contenir des champs d'une ou plusieurs tables ou requêtes. Les jeu d'enregistrements de type Dynaset peuvent généralement être mis à jour dans les deux directions. Ainsi, des modifications dans le jeu d'enregistrements sont répercutées dans les tables sous-jacentes ou les requêtes et des changements dans les tables ou les requêtes sont répercutées dans le jeu d'enregistrements de type Dynaset. Avec un jeu d'enregistrements de type Dynaset, aucune donnée n'est mise en mémoire. Par contre, une clé unique est chargée en mémoire pour référencer chaque ligne de données. La recherche dans un jeu d' enregistrements de type Dynaset est effectuée à l'aide de la méthode Find, qui est généralement plus lente que la méthode Seek (qui utilise l'un des index de table). Un objet Recordset de type Snapshot est un jeu d'enregistrements statique (non modifiable) qui peut contenir des champs d'une ou plusieurs tables ou requêtes. Ces jeux d'enregistrements ne peuvent être mis à jour. Pour une recherche, un jeu d'enregistrements de type Snapshot peut être plus rapide qu'un jeu d'enregistrements de type Dynaset. Ouverture d'un jeu d'enregistrements Recordset Pour créer ou ouvrir un jeu d'enregistrements, jet fournit la méthode OpenRecordset. Cette méthode peut être appliquée à Database, TableDef, QueryDef, ou aux objets Recordset. La syntaxe est ObjectVar pointe vers un objet TableDef,,QuervDef ou Recordset existant. Lorsqu'on ouvre un jeu d'enregistrements basé sur une base de données (la première syntaxe ci-dessus), source est une chaîne spécifiant la source des enregistrements pour le nouveau jeu d'enregistrements. La source peut être un nom de table, un nom de requête ou une déclaration SQL qui retourne des enregistrements. Pour les objets Recordset de type Table, la source ne peut être qu'un nom de table.

235 Ouverture d'un jeu d'enregistrements Recordset 227 Si vous ne spécifiez pas un type, alors un jeu d'enregistrements de type Table est créé si possible. En outre, la valeur Type peut être l'une des constantes entières suivantes : - dbopentable pour ouvrir un objet Recordset de type Table - dbopendynasetpour ouvrir un objet Recordset de type Dynaset - dbopensnapshot pour ouvrir un objet Recordset de type Snapshot Options a plusieurs valeurs se rapportant à des situations multi-utilisateurs, mais peut prendre aussi la valeur dbforwardonly, qui signifie que le jeu d'enregistrements est une vue instantanée qui défile vers l'avant. Ce type d'instantané est utile pour une recherche rapide. Note Un nouvel objet Recordset est automatiquement ajouté à la collection Recordsets quand vous ouvrez l'objet et est automatiquement enlevé quand vous le fermez, en utilisant la méthode Close. Le code de l'exemple 11-1 ouvre (et ensuite ferme) un jeu d'enregistrements de chaque type, basé sur la table LIVRES. Il affiche aussi (dans la fenêtre debug) la valeur de la propriété RecordCount pour ces jeux d'enregistrements. Pour un jeu d' enregistrements de type Dynaset et Snapshot, la propriété RecordCount est le nombre d'enregistrements répertoriés. En conséquence, pour déterminer le nombre d' enregistrements dans un tel jeu d'enregistrements, nous devons invoquer la méthode MoveLast, permettant d'accéder à tous les enregistrements. Pour un jeu d' enregistrements de type Table, la propriété RecordCount donne le nombre total d' enregistrements (nous exposerons la méthode MoveLast ultérieurement). Exemple Un exemple de la méthode OpenRecordset

236 228 Chapitre 11: Programmation DAO : Lamage de manipulation de données Exemple Un exemple de la méthode OpenRecordset (suite) Types Recordset par défaut Si vous ne spécifiez pas un type dans la méthode OpenRecordset, jet en choisira une pour vous en fonction des règles suivantes Le Type par défaut à l'ouverture d'un jeu d'enregistrements sur un objet Database (la première syntaxe ci-dessus) ou sur un objet TableDef (seconde syntaxe) est un objet Recordset de type Table. Le Type par défaut à l'ouverture d'un jeu d'enregistrements sur un objet QueryDef est un objet Recordset de type Dynaset (les jeux d'enregistrements de type Table ne sont pas disponibles). Le Type par défaut à l'ouverture d'un jeu d'enregistrements sur un objet Recordset existant de type Table est un jeu d'enregistrements de type Dynaset. Si le jeu d' enregistrements n'est pas de type Table, alors le nouveau jeu d'enregistrements a le même type que l'original. Déplacements dans un jeu Recordset Tous les jeux d'enregistrements ont une position courante (vers laquelle pointe le pointeur d'enregistrement courant, parfois appelé curseur) et un enregistrement courant. Normalement, l'enregistrement courant est l'enregistrement à la position courante. Cependant, il y a deux exceptions. La position courante peut être Avant le premier enregistrement Après le dernier enregistrement

237 Déplacements dans un jeu Recordset 229 auxquels cas il n'y a pas d'enregistrement courant. Pour modifier la position courante (et par suite l'enregistrement courant), jet fournit plusieurs méthodes Move MoveFirst : déplace la position vers le premier enregistrement MoveLast : déplace la position vers le dernier enregistrement MoveNext : déplace la position vers l'enregistrement suivant MovePrevious : déplace la position vers l'enregistrement précédent Move[n] : déplace la position vers l'avant ou l'arrière de n positions Dans chaque cas la syntaxe a la forme RecordSetVar.MoveCommand BOF et EOF Les propriétés BOF (Beginning of File : début de fichier) et EOF (End of File : fin de fichier) sont déterminées par jet après chaque commande move. Les notes qui suivent vont vous aider à mieux appréhender les concepts sous-jacents. Notes sur les propriétés BOF et EOF BOF est True (vrai) quand la position courante est avant le premier enregistrement dans le jeu d'enregistrements, et non au premier enregistrement. EOF est True quand la position courante est derrière le dernier enregistrement dans le jeu d'enregistrements, et non au dernier enregistrement. Si BOF ou EOF est True, alors il n'y a aucun enregistrement courant. Si vous ouvrez un jeu d'enregistrements ne contenant aucun enregistrement, alors BOF et EOF sont fixés à True. Si le jeu d'enregistrements a des enregistrements, alors jet effectue un MoveFirst tacite, de sorte que le premier enregistrement devient l'enregistrement courant et à la fois BOF et EOF sont fixés à False ( faux). Si vous effacez le dernier enregistrement restant dans un jeu, BOF et EOF demeurent False sauf si vous tentez de modifier la position courante. Notes sur les méthodes Move Si vous utilisez MovePrevious lorsque le premier enregistrement est l'enregistrement courant, la propriété BOF est fixée à True, et il n'y a aucun enregistrement

238 230 Chapitre 11: Programmation DAO : Lanuaee de manpulation de données courant. Un autre MovePrevious va produire une erreur et BOF contiendra toujours True. Si vous utilisez MoveNext lorsque le dernier enregistrement est l'enregistrement courant, la propriété EOF est fixée à True, et il n'y a aucun enregistrement courant. Un autre MoveNext produira une erreur et EOF contiendra toujours True. Si le jeu d'enregistrements est un jeu d'enregistrements de type Table, le mouvement suit l'index courant, qui utilise la propriété Index de l'objet Recordset. Si aucun index n'est défini (ou si le jeu d'enregistrements n'est pas de type Table), l'ordre des enregistrements retournés n'est pas prévisible. L'usage le plus répandu des méthodes Move est de passer en revue chaque enregistrement dans un jeu d'enregistrements. L'exemple 11-2 illustre cela. Il crée un jeu d' enregistrements à la fois de type Table et de type Dynaset sur LIVRES et imprime ( dans le fenêtre debug) une liste de PubID et de Titres. Notez l'utilisation de la déclaration Do while not rs.eof qui est typique de ce type de procédure. Notez également la présence de cette ligne rstable.movenext dans la boucle Do. C'est une erreur commune d'oublier d'avancer le pointeur d'enregistrement courant, auquel cas le PC entre dans une boucle sans fin et accède à la même ligne!

239 Déplacements dans un jeu Recordset 231 Exemple Déplacement dans un jeu d'enregistrements Il convient de remarquer que pour un jeu d'enregistrements de type Dynaset ou de type Snapshot, ou pour un jeu d'enregistrements de type Table pour lequel la propriété Index n'a pas été fixée, vous ne pouvez prédire l'ordre des enregistrements dans le jeu d'enregistrements. Dans ce contexte, deux propriétés Recordset d'utilisation particulière sont AbsolutePosition et PercentPosition, qui donnent respectivement la position ordinale de l' enregistrement courant dans un jeu d'enregistrements de type Snapshot ou de type

240 232 Chapitre 11: Programmation DAO : LanRaRe de manipulation de données Dynaset, et la position en pourcentage. Donnons-en une illustration en modifant l' exemplel l-2, comme le montre l'exemple Exemple Exemple de position dans le jeu d'enregistrements Recherches dans un jeu Recordset La méthode utilisée pour rechercher un enregistrement dans un jeu est différente pour un jeu d'enregistrements indexé de type Table que pour d'autres jeux d' enregistrements. Trouver des enregistrements dans un jeu de type Table Pour localiser un enregistrement dans un jeu d'enregistrements indexé de type Table, utilisez la méthode Seek. Notez que la propriété Index du jeu doit être spécifiée avant que la méthode Seek puisse être utilisée. La syntaxe de la méthode Seek est dans laquelle comparaison est l'une des chaînes suivantes

241 Recherches dans un jeu Recordset 233 et kg 1, key2,... sont des valeurs correspondant à chaque champ dans l'index courant. Notes: La méthode Seek recherche à travers les champs clés et localise le premier enregistrement correspondant. Une fois trouvé, il fait de cet enregistrement l'enregistrement courant et la propriété NoMatch (pas d'enregistrement correspondant à la requête) du jeu d'enregistrements aura False comme valeur. Si la méthode Seek échoue pour localiser une correspondance, la propriété NoMatch contient True et l' enregistrement courant est indéfini. Si comparison est égal (_), plus grand ou égal à (>_), or plus grand que (>), Seek démarre la recherche au début de l'index. Si comparison est plus petit que (<) ou plus petit ou égal à (<_), Seek démarre la recherche à la fin de l'index et recherche vers l'avant sauf s'il y a des entrées d'index dupliquées à la fin. Dans ce cas, Seek démarre à partir d'une entrée parmi les entrées dupliquées à la fin de l'index. Le code de l'exemple 11-4 utilise la méthode Seek sur l'index Titre de LIVRES pour trouver le premier titre qui débute par le mot "On". Exemple Un exemple de la méthode Seek

242 234 Chapitre 11: Programmation DAO : Laneaee de manipulation de données Exemple Un exemple de la méthode Seek (suite) rstable.close Trouver des enregistrements dans un jeu de type Dynaset ou Snapshot Pour rechercher un enregistrement dans un jeu d'enregistrements de type Dynaset ou Snapshot, jet fournit différentes méthodes Find FindFirst : trouve le premier enregistrement correspondant dans le jeu d' enregistrements FindNext : trouve l'enregistrement correspondant suivant, en partant de l' enregistrement courant FindPrevious : trouve l'enregistrement correspondant précédent, en partant de l' enregistrement courant FindLast : trouve le dernier enregistrement correspondant dans le jeu d'enregistrements La syntaxe de ces méthodes est où RecordsetVar représente un objet Recordset existant de type Dynaset ou de type Snapshot criteria est une chaîne, utilisant la même syntaxe que la clause WHERE SQL (mais sans le mot WHERE) Il est important de noter que, si un enregistrement correspondant au critère n'est pas localisé, la propriété NoMatch est fixée sur True, la position courante est indéterminée et ainsi il n'y a aucun enregistrement courant. Il est ainsi important de positionner le pointeur d'enregistrement courant. C'est habituellement effectué en plaçant un signet à hauteur de l'enregistrement courant avant de démarrer la recherche. Ainsi, si la recherche échoue, la position d'origine peut être restaurée à l'aide du signet. En fait, un signet est une chaîne générée par le système que jet peut utiliser pour identifier un enregistrement. Ainsi, en plaçant un signet sur l'enregistrement courant et en se déplaçant vers un autre enregistrement, nous pouvons revenir à l' enregistrement marqué. Illustrons ce propos.

243 Edition de données à partir d'un jeu d'enregistrements 235 Le code suivant affiche tous les titres de livres débutant par "M" et retourne ensuite à l'enregistrement courant d'avant la recherche. Exemple Un exemple de la méthode Find, Édition de données a partir d un jeu d'enregistrements Envisageons maintenant les méthodes utilisées pour éditer, ajouter ou effacer des données d'un jeu d'enregistrements de type Table ou de type Dynaset. Les jeux d' enregistrements de type Snapshot sont statiques, ainsi les données dans un tel jeu ne peuvent être modifiées. Dans cette section, le terme jeu d'enregistrements se référera à des jeux de type Table ou de type Dynaset. Souvenez-vous que toute modification apportée au contenu d'un jeu d'enregistrements est répercutée dans les tables ou les requêtes sous-jacentes. Éditer un enregistrement existant L'édition d'un enregistrement existant est effectuée en quatre étapes:

244 236 Chapitre 11: Programmation DAO : Langage de man pulation de données 1. Transformez l'enregistrement en l'enregistrement courant. 2. Invoquez la méthode Edit pour le jeu d'enregistrements. 3. Effectuez les modifications désirées à l'enregistrement. 4. Invoquez la méthode Update pour le jeu d'enregistrements. Il est important de noter que si vous déplacez le pointeur de l'enregistrement courant avant d'invoquer la méthode Update, toutes les modifications apportées à l' enregistrement seront perdues. Le code de l'exemple 11-6 met tous les titres dans une copie de la table LIVRES en majuscules. Avant de lancer ce code vous devriez utiliser les options Copier et Coller du menu (dans le menu Edition) pour faire une copie de LIVRES, appelée Copie de Livres. Sélectionnez LIVRES dans la fenêtre Base de données, choisissez Edition, Copier, puis choisissez Edition, Coller. Exemple Edition de données avec un jeu d'enregistrements Pour souligner un point abordé précédemment, vous pourriez démarrer avec une table Copie de Livres et lancer le code précédent sans la ligne rs.update pour voir qu'aucune modification n'a été apportée à la table.

245 Édition de données à partir d'un jeu d'enregistrements 237 Effacer un enregistrement existant L'effacement de l'enregistrement courant est effectué à l'aide de la méthode Delete de l' objet Recordset. La syntaxe est simplement Notes Les suppressions sont effectuées sans aucun avertissement ou confirmation. Si vous voulez une confirmation, vous devez écrire le code correspondant. Notez que, immédiatement après que l'enregistrement est effacé, il n'y a aucun enregistrement courant. Le pointeur d'enregistrement courant doit être déplacé vers un enregistrement existant (en invoquant habituellement MoveNexl). La procédure dans l'exemple 11-7 efface tous les livres qui ont un prix supérieur à $ dans une copie de la table LIVRES, après demande de confirmation. Avant d' exécuter ce code, vous devriez utiliser les commandes Copier, Coller pour faire une copie de LIVRES, intitulée Copie de Livres. Exemple Utilisation de la méthode Delete avec un jeu d'enregistrements

246 238 Chapitre 11: Pro, rammation DAO : Langage de manipulation de données Exemple Utilisation de la méthode Delete avec un jeu d'enregistrements (suite) Ajouter un nouvel enregistrement L'ajout d'un nouvel enregistrement à un jeu d'enregistrements est effectué en trois étapes 1. Invoquez la méthode AddNew pour créer un enregistrement vierge, que jet convertit en enregistrement courant. 2. Remplissez les champs de l' enregistrement. 3. Invoquez la méthode Update pour sauvegarder l'enregistrement. La syntaxe de la méthode AddNew est simple Notes Une fois la méthode Update invoquée, l'enregistrement qui était l'enregistrement courant avant que l'on invoque de nouveau la méthode AddNew devient l'enregistrement courant. Pour faire du nouvel enregistrement l'enregistrement courant, utilisez un signet avec la propriété LastMod fed, comme le montre l'exemple Dans un jeu d'enregistrements de type Table, le nouvel enregistrement est placé correctement à sa place par rapport à l'index courant. Dans un jeu d'enregistrements de type Dynaset, le nouvel enregistrement est placé à la fin du jeu d'enregistrements. Si le jeu a un ordre de tri (hérité par exemple d'une requête sousjacente), le nouvel enregistrement peut être repositionné en utilisant la méthode Requery. L'exemple 11-8 ajoute un nouveau livre à la table LIVRES et en fait l'enregistrement courant. Il démontre également la construction With... End With. Exemple Ajout d'un enregistrement dans Recordset

247 Sur le CD-Rom 239 Exemple Ajout d'un enregistrement dans Recordset (suite) Sur le CD-Rom L'ensemble des exemples de ce chapitre se trouvent placés dans quatre documents différents. Pour les consulter, visualisez le document d'orientation : /exemples/ chapll/ chapll.htm. La base libray.mdb dans le sous-répertoire chapll est spécifique à ce chapitre. La structure d'exposition des exemples et des exercices suit la structure du chapitre et est partagée en quatre thèmes Ouverture d'un jeu d'enregistrements Déplacements dans un jeu d'enregistrements Recherche d'enregistrements Edition de données depuis un jeu d'enregistrements La base LIBRARY contient un module de programmation avec les exemples de programmes exposés dans ce chapitre. Il est donc conseillé de lancer cette version pour lancer les exemples.

248 DAO Collections, Propriétés et Méthodes Microsoft Access 97 est livré avec un utilitaire connu sous le nom de Visualiseur d'objets, qui peut être utilisé pour explorer la hiérarchie des objets DAO. La figure A1 montre le viualiseur d'objets, qui peut être invoqué depuis un module de code Access en appuyant sur la touche de fonction F2 (ou depuis le menu Vues). Figure A-1. Le Visualiseur d'objets 241

249 242 Annexe A : DAO 3.0/3.5 Collections, Propriétés et Méthodes Le Visualiseur d'objets peut être un outil très utile, mais une copie d'écran peut s'avérer parfois aussi utile. Cette annexe contient des informations sur les Collections, Propriétés et Méthodes de chaque objet faisant partie de la hiérarchie objets de DAO 3.0 (qui s'intègre à Access 95) et DAO 3.5 (qui s'intègre à Access 97). Cette information devrait vous aider à vous orienter dans le système d'aide en ligne d' Access. En présentant ce guide de références DAO, nous avons placé en tête une table contenant la liste des classes et des collections disponibles dans DAO, suivies par des tableaux descriptifs des Propriétés et Méthodes de chaque classe, ainsi que les collections accessibles depuis chaque objet. Les tables indiquent également si chaque item s'applique à DAO 3.0, DAO 3.5, ou aux deux. Finalement, on trouvera une description sommaire de chaque item. Classes DAO Nom de classe Version Description Connection 3.5 Une connexion ODBCDirect ouverte Connections 3.5 Une collection d'objets dans un objet Connection Container 3.0/3.5 Stockage d'information sur un type d'objet prédéfini Containers 3.0/3.5 Une collection d'objets Container Database 3.0/3.5 Une base de données ouverte Databases 3.0/3.5 Une collection d'objets Database DBEngine 3.0/3.5 Le moteur jet database Document 3.0/3.5 Information sur un objet prédéfini et saauvegardé Documents 3.0/3.5 Une collection d'objets Document Error 3.0/3.5 Information sur une erreur survenue avec un objet DAO Errors 3.0/3.5 Une collection d'objets Error Field 3.0/3.5 Une colonne, partie d'une table, requête, index, relation ou jeu d'enregistrements Fields 3.0/3.5 Une collection d'objets Fields Group 3.0/3.5 Un groupe de comptes utilisateurs Groups 3.0/3.5 Une collection d'objets Group Index 3.0/3.5 Objet utilisé pour ordonner les valeurs et fournir un accès efficace à un jeu d'enregistrements Indexes 3.0/3.5 Une collection d'objets Index Parameter 3.0/3.5 Paramètre d'une requête Parameters 3.0/3.5 Une collection d'objets Parameter Properties 3.0/3.5 Une collection d'objets Property

250 Objet Collection 243 Nom de classe Version Description Property 3.0/3.5 Une propriété native ou définie par l'utilisateur QueryDef 3.0/3.5 Une définition de requête sauvegardée QueryDefs 3.0/3.5 Une collection d'objets QueryDef Recordset 3.0/3.5 La représentation des enregistrements dans une table ou du résultat depuis une requête Recordsets 3.0/3.5 Une collection d'objets Recordset Relation 3.0/3.5 Une relation entre champs dans des tables et des requêtes Relations 3.0/3.5 Une collection d'objets Relation TableDef 3.0/3.5 Une définition de table sauvegardée TableDefs 3.0/3.5 Une collection d'objets Tabledef User 3.0/3.5 Un compte d'utilisateur Users 3.0/3.5 Une collection d'objets User Workspace 3.0/3.5 Une session du moteur de bases de données jet database Workspaces 3.0/3.5 Une collection d'objets Workspace Objet Collection Chacun des objets Collection listés plus haut dans la table Classes DAO supporte une seule méthode et une seule propriété. Méthodes Méthode Type Version Description Refresh Sub 3.0/3.5 Met à jour la collection pour prendre en compte les change ments récents Propriétés Propriété Type Version Description Count Integer 3.0/3.5 Nombre d'objets dans la collection (lecture seule) En outre, les objets DynaCollection-c-à-d, les objets Collection dont les membre peuvent être dynamiquement ajoutés ou enlevés-ont les deux méthode s supplémentaires s

251 244 Annexe A : DAO Collections, Propriétés et Méthodes Méthodes Méthode Paramètres Retoune Version Description Append Object As Object Sub 3.0/3.5 Ajoute un objet à la collection Delete Name As String Sub 3.0/3.5 Supprime un objet de la collection Objet Connection (DAO 3.5 uniquement) Collections Propriété Type Version Description Database Database 3.5 Retourne une référence Database dans cet objet Connec tion QueryDefs QueryDefs 3.5 Une collection d'objets QueryDef Recordsets RecordSets 3.5 Une collection d'objets Recordset ouverte dans cette Connection Méthodes Méthode Paramètres Retourne Version Description Cancel Sub 3.5 Annule l'exécution d'une méthode asynchrone Execute ou OpenRe cordset Close Sub 3.5 Ferme l'objet Connection et tout ce qu'il contient CreateQueryDef [Name], [SQLText]) QueryDef 3.5 Crée un nouvel objet QueryDef Execute Query As String, Sub 3.5 Exécute une déclaration [Options] SQL OpenRecordSet Name As String, Recordset 3.5 Crée un nouvel objet [Type], [Options], Recordset [LockEdit] Propriétés Propriété Type Version Description Connect String 3.5 Information sauvegardée depuis l'argument Connect de la méthode OpenDatabase Name String 3.5 Nom de l'objet Connection QueryTimeout Integer 3.5 Nombre de secondes d>attente maxi lors de l'exécu tion d'une requête ODBC

252 Objet Database 245 Propriété Type Version Description RecordsAffected Long 3.5 Nombre d'enregistrements affectés par la méthode Execute StillExecuting Boolean 3.5 Indique si un appel de méthode asynchrone est en cours d'exécution Transactions Boolean 3.5 Indique si l'objet DAO supporte des transactions Updatable Boolean 3.5 Indique si la liaison autorise la mise à jour de données Objet Container Collections Propriété Type Version Description Documents Documents 3.0/3.5 Collection d'objets Document dans le conteneur Propriétés Propriété Type Version Description AliPermissions Long 3.0/3.5 Toutes les permissions s'appliquant au nom d'utilisa teur courant Inherit Boolean 3.0/3.5 Indique si les objets new Document héritent des permissions par défaut Name String 3.0/3.5 Le nom de cet objet Owner String 3.0/3.5 Détermine ou retourne le propriétaire de l'objet Permissions Long 3.0/3.5 Détermine ou retourne les permissions pour un utilisa teur ou un groupe indiquées par la propriété UserName lorsqu'on accède à l'objet UserName String 3.0/3.5 Utilisateur ou groupe auquel s'applique la propriété Permissions Objet Database Collections Propriété Type Version Description Connection Connection 3.5 Une liaison ODBCDirect ouverte Containers Containers 3.0/3.5 Collection d'objets Container dans l'objet Database QueryDefs QueryDefs 3.0/3.5 Collection d'objet QueryDefs dans l'objet Database Recordsets Recordsets 3.0/3.5 Collection d'objets Recordset ouverts dans l'objet Database

253 246 Annexe A : DAO 3.0/3.5 Collections, Propriétés et Méthodes Propriété Type Version Description Relations Relations 3.0/3.5 Collection d'objets Relation dans l'objet Database TableDefs TableDefs 3.0/3.5 Collection d'objets TableDef dans l'objet Database Méthodes Méthode Paramètres Retourne Version Description Close Sub 3.0/3.5 Ferme l'objet Database et tout ce qu'il contient CreatePropert y CreateQueryD ef CreateRelatio n CreateTableD ef Execute MakeRephca NewPassword OpenRecords et PopulatePartia l Synchronize Propriétés [Name], [Type], [Value, PDLI Property 3.0/3.5 Crée un nouvel objet user-defined Property [Name], [SQLText] QueryDef 3.0/3.5 Crée un nouvel objet QueryDef [Name], [Table], [ForcignTable], [Attributes] [Name], [Attributes], [SourceTableName], [Connect] Query As String, [Options] PathName As String, Description As String, [Options] bstrold As String, bstrnew As String Name As String, [Type], [Options] Relation 3.0/3.5 Crée un nouvel objet Relation TableDef 3.0/3.5 Crée un nouvel objet Tabledef Sub 3.0/3.5 Exécute une requête Sub 3.0/3.5 Effectue une replica Lion à partir de la base de données courante qui est duplicable Sub 3.0/3.5 Modifie le mot de passe d'une base de données existante Recordset 3.0/3.5 Crée un nouvel objet Recordset DbPathName As String Sub 3.5 Synchronise une repli cation partielle DbPathName As String, [ExchangeType] Sub 3.0/3.5 Synchronise l'objet database Propriété Type Version Description CollatingOrder Long 3.0/3.5 Définit l'ordre des tris et des comparaisons Connect DesignMasterID String String 3.0/3.5 Name String 3.0/3.5 Information sauvegardée depuis l'argument Connect de la méthode OpenDatabase Identifiant unique pour un modèle de conception de replication Le nom de cet objet Database

254 O jet DBEngine 247 Propriété Type Version Description QueryTimeout Integer 3.0/3.5 Nombre de secondes avant que survienne un timeout lors de l'exécution d'une requête ODBC RecordsAffected Long 3.0/3.5 Nombre d'enregistrements affectés par la dernière méthode Execute ReplicaID String 3.0/3.5 Identifiant unique pour une replication Transactions Boolean 3.0/3.5 Indique si l'objet Database supporte des transactions Updatable Boolean 3.0/3.5 Indique si l'objet Database peut être modifié Version String 3.0/3.5 Numéro de version du format de l'objet Database Objet DBEngine Collections Propriété Type Version Description Errors Errors 3.0./3.5 Collection d'erreurs suite à l'échec de la toute dernière opération DAO Properties Propriétés 3.0/3.5 Collection d'objets Property Workspaces Workspaces 3.0/3.5 Collection d'objets open Workspace Méthodes Méthode BeginTrans Paramètres Retourne Sub Version 3.0/3.5 Description Commence une nouvelle transaction CommitTrans Sub 3.0 Termine la transaction et sauvegarde toutes les modifications CommitTrans [Option as Long] Sub 3.5 Termine la transaction et sauvegarde toutes les modifications CompactDatabase CompactDatabase SrcName As String, DstName As String, [DstConnect], [Options], [SrcCon nect] SrcName As String, DstName As String, [DstLocale], [Options], [SrcLo cale] Sub 3.0 Compacte une base de données fermée Sub 3.5 Compacte une base de données fermée

255 248 Annexe A : DAO 3.0/3.5 Collections, Propriétés et Méthodes Méthode Paramètres Retourne Version Description CreateDatabase Name As String, Connect As String, [Option] Database 3.0 Crée une nouvelle base de données CreateDatabase CreateWorkspace CreateWorkspace Name As String, Locale As String, [Option] Name As String, UserName As String, Password As String Name As String, UserName As String, Password As String, [UseType] Database 3.5 Crée une nouvelle base MDB 3.0 Crée un nouvel objet Workspace 3.5 Crée un nouvel objet Workspace Idle [Action] Sub 3.0/3.5 Achève les tâches en cours du moteur telles que la suppression du verrouillage OpenConnection OpenDatabase OpenDatabase RegisterDatabase Name As String, [Options], [ReadOnly], [Connect] Name As String, [Exclusive], [ReadOnly], [Connect] Name As String, [Options], [ReadOnly], [Connect] Dsn As String, Driver As String, Silent As Boolean, Attributes As String Workspace Workspace Connection 3.5 Ouvre une connection à une base de données Database 3.0 Ouvre une base de données spécifiée Database 3.5 Ouvre une base de données spécifiée Sub 3.0/3.5 Entre l'information pour se connecter à une source de données ODBC RepairDatabase Name As String Sub 3.0/3.5 Répare une base de données endommagée Rollback Sub 3.0/3.5 Déroule les changements effectués depuis le dernier BeginTrans SetOption Option As Long, Value Sub 3.5 Écrase le paramétrage jet des registres

256 Objet Document 249 Propriétés Propriété Type Version Description DefaultPassword String 3.0/3.5 Mot de passe si un objet Workspace est créé sans mot de passe DefaultType DefaultUser Long String /3.5 Détermine le type par défaut de Workspace Nom d'utilisateur si un objet Workspace est créé sans nom d'utilisateur IniPath String 3.0/3.5 Chemin et fichier d'initialisation (dans jet 3.0) ou chemin complet de la base de registres (Jet 3.5) conte nant la configuration du moteur Jet LoginTimeout Integer 3.0/3.5 Nombre de secondes autorisées pour le login dans une base de données ODBC SystemDB String 3.0/3.5 Chemin vers la base de données système Version String 3.0/3.5 Numéro de version du moteur jet Objet Document Méthodes Méthode Paramètres Retourne Version Description CreateProperty Propriétés [Name], [Type], [Value], [DDL] Property 3.0/3.5 Crée un nouvel objet user defined Property Propriété Type Version Description AllPermissions Long 3.0/3.5 Toutes les permissions s'appliquant à l'utilisateur courant Container String 3.0/3.5 Nom de l'objet Container auquel cet objet Document appartient DateCreated Variant 3.0/3.5 Date et heure de création de l'objet Document LastUpdated Variant 3.0/3.5 Date et heure des changements les plus récents de l'objet Document Name String 3.0/3.5 Nom de cet objet Document Owner String 3.0/3.5 Le propriétaire de l'objet Permissions Long 3.0/3.5 Permissions pour l'utilisateur d'un groupe accédant à l'objet Document UserName String 3.0/3.5 Utilisateur ou groupe auxquels s'applique la propriété Permissions

257 250 Annexe A : DAO 3.0/3.5 Collections, Propriétés et Méthodes Objet Error Propriétés Propriété Type Version Description Description String 3.0/3.5 Description de l'erreur HelpContext Long 3.0/3.5 ID d'aide contextuelle pour une rubrique décrivant l'erreur HelpFile String 3.0/3.5 Chemin vers le fichier Aide décrivant l'erreur Number Long 3.0/3.5 Code d'erreur de l'erreur la plus récente Source String 3.0/3.5 Nom de la classe d'objets ayant généré l'erreur Objet Field Collections Propriété Type Version Description Properties Propriétés 3.0/3.5 Collection d'objets Property Méthodes Méthode AppendChunk Paramètres Val Retourne Sub Version 3.0/3.5 Description Écrit des données binaires de type long dans un champ CreateProperty [Name], [Type], [Value], [DDL] Property 3.0/3.5 Crée un nouvel objet user-defined Property FieldSize Long 3.0 Retourne le champ size field (taille du champ) GetChunk Propriétés Offset As Long, Bytes As Long Byte 3.0/3.5 Lit des données binaires d'un champ Propriété Type Version Description AllowZeroLength Boolean 3.0/3.5 Indique si une chaîne de longueur zéro est valide pour ce champ Attributes Long 3.0/3.5 Valeur indiquant les caractéristiques de cet objet Field CollatingOrder Long 3.0/3.5 Langage utilisé pour les tris et les comparaisons

258 Objet Group 251 Propriété DataUpdatable Type Boolean Version 3.0/3.5 Description Indique si les données dans le champ peuvent être mises à jour DefaultValue String 3.0/3.5 Valeur par défaut du champ pour un nouvel enregis trement FieldSize Long 3.5 Taille du champ mémo ou d'un champ binaire long ForeignName String 3.0/3.5 Le nom du champ étranger Name String 3.0/3.5 Le nom de cet objet Field OrdinalPosition Integer 3.0/3.5 Position relative de cet objet Field OriginalValue Variant 3.5 Valeur stockée dans le serveur de base de données au démarrage d'une mise à jour en mode batch Required Boolean 3.0/3.5 Indique si Field requiert une valeur différente de Null Size Long 3.0/3.5 Taille maximale du champ SourceField String 3.0/3.5 Nom de la source d'origine pour un objet Field SourceTable String 3.0/3.5 Nom de la table source Type Integer 3.0/3.5 Type de données du champ ValidateOnSet Boolean 3.0/3.5 Détermine si la validation survient immédiatement (valeur True) ou ultérieurement à la mise à jour (valeur False) ValidationRule String 3.0/3.5 Évaluation d'expression à True pour une mise à jour réussie VahdationText String 3.0/3.5 Message à afficher si la validation échoue avec Vali dationrule Value Variant 3.0/3.5 Les données de l'objet Field VisibleValue Variant 3.5 Données couramment stockées dans le serveur de bases de données Objet Group Collections Propriété Type Version Description Properties Propriétés 3.0/3.5 Une collection d'objets Property Users Users 3.0/3.5 Une collection d'objets User Méthodes Méthode Paramètres Retourn e Version Description CreateUser [Name], [PID], [Password] User 3.0/3.5 Crée un nouvel objet User

259 252 Annexe A : DAO Collections, Propriétés et Méthodes Propriétés Propriété Type Version Description Name String 3.0/3.5 Nom de l'objet Group PID String 3.0/3.5 Identifiant personnel (PID) pour un compte utilisateur ou un compte groupe Objet Index Collections Propriété Type Version Description Fields Fields 3.0/3.5 Collection de champs de l'objet Index Properties Propriétés 3.0/3.5 Collection d'objets Property Méthodes Méthode Paramètres Retourne Version Description CreateField CreateProperty Propriétés [Name], [Type], [Size] [Name], [Type], [Value], [DDL] Field 3.0/3.5 Crée un nouvel objet Field Property 3.0/3.5 Crée un nouvel objet user-defined Property Propriété Clustered Type Boolean Version 3.0/3.5 Description Indique si l'index est divisé en clusters DistinctCount Long 3.0/3.5 Nombre de valeurs uniques dans cet objet Index Foreign Boolean 3.0/3.5 Indique si un objet Index représente une clé étrangère IgnoreNulls Boolean 3.0/3.5 Indique si des valeurs Null sont stockées dans l'index Name String 3.0/3.5 Nom de cet objet Index Primary Boolean 3.0/3.5 Indique s'il s'agit d'un index primaire Required Boolean 3.0/3.5 Indique si l'index requiert une valeur différente de Null Unique Boolean 3.0/3.5 Indique s'il s'agit d'un index unique pour une table

260 Objet OuegDef 253 Objet Parameter Propriétés Propriété Type Version Description Direction Integer 3.5 Indique si un paramètre concerne les entrées, sorties ou des valeurs retournées. Name String 3.0/3.5 Nom de cet objet Parameter Type Integer 3.0/3.5 Type de données de l'objet Value Variant 3.0/3.5 Valeur de l'objet Objet Property Propriétés Propriété Type Version Description Inherited Boolean 3.0/3.5 Indique si une Propriété est héritée d'un objet sous-jacent Name String 3.0/3.5 Nom de l'objet Property Type Integer 3.0/3.5 Le type de données de l'objet Property Value Variant 3.0/3.5 La valeur de la propriété ObjetQueyyDef Collections Propriété Type Version Description Fields Fields 3.0/3.5 Collection de champs dans l'objet QueryDef Parameters Paramètres 3.0/3.5 Collection d'objets Parameter dans l'objet QueryDef Properties Propriétés 3.0/3.5 Collection d'objets Property dans l'objet QueryDef Méthodes Méthode Paramètres Retourne Version Description Cancel Sub 3.5 Annule l'exécution d'une méthode asynchrone Open Recordset Close Sub 3.0/3.5 Ferme l'objet ouvert QueryDef

261 254 Annexe A : DAO 3.0/3.5 Collections, Propriétés et Méthodes Méthode Paramètres Retourne Version Description CreateProperty [Name], [Type], [Value], [DDL] Property 3.0/3.5 Crée un nouvel objet user-defined Property Execute [Options] Sub 3.0/3.5 Exécute Querydef OpenRecordset OpenRecordset Propriétés [Type], [Options] [Type], [Options], [LockEdit] Recordset 3.0 Crée un nouvel objet Recordset Recordset 3.5 Crée un nouvel objet Recordset Propriété CacheSize Type Long Version 3.5 Description Nombre d'enregistrements dans à placer dans le cache depuis une source de données ODBC Connect String 3.0/3.5 Valeur fournissant une information sur une source de données pour QueryDef DateCreated Variant 3.0/3.5 Date et heure de création de QueryDef LastUpdated Variant 3.0/3.5 Date et heure de la dernière modification de QueryDef MaxRecords Long 3.5 Nombre maximum d'enregistrements à retourner depuis la requête Name String 3.0/3.5 Nom de l'objet QueryDef ODBCTimeout Integer 3.0/3.5 Nombre de secondes d'attente avant un timeout lors d'une interrogation de base de données ODBC Prepare Variant 3.5 Indique s'il faut préparer à partir de la requête une procédure stockée provisoirement RecordsAffected Long 3.0/3.5 Nombre d'enregistrements affectés par la dernière méthode Execute ReturnsRecords Boolean 3.0/3.5 Indique si une requête SQL pass-through retourne des enregistrements SQL String 3.0/3.5 Déclaration SQL qui définit la requête StillExecuting Boolean 3.5 Indique si un appel de méthode asynchrone est en cours d'exécution Type Integer 3.0/3.5 Le type de données de l'objet Updatable Boolean 3.0/3.5 Indique si la définition de la requête peut être changée

262 Objet Recordset 255 Objet Recordset Collections Propriété Type Version Description Connection Connection 3.5 Indique quelle Connection possède l'objet Recordset Fields Fields 3.0/3.5 Collection de champs dans l'objet Recordset Méthodes Méthode Paramètres Retourne Version Description AddNew Sub 3.0/3.5 Ajoute un nouvel enregistre ment à un jeu Cancel Sub 3.5 Annule l'exécution d'une méthode asynchrone Execute, OpenRecordset ou OpenConnection CancelUpdate Sub 3.0/3.5 Annule toutes les déclarations en cours AddNew ou Update Clone Recordset 3.0/3.5 Duplique un jeu d'enregistre ments Close Sub 3.0/3.5 Ferme un objet Recordset CopyQueryDef QueryDef 3.0/3.5 Retourne une copie de QueryDef qui a créé le jeu d'enregistrements Delete Sub 3.0/3.5 Efface un enregistrement dans le jeu d'enregistrements Edit Sub 3.0/3.5 Prépare une ligne du jeu pour édition FillCache [Rows], [Start- Bookmark] Sub 3.0/3.5 Remplit le cache pour un jeu d'enregistrements ODBC FindFirst Criteria As String Sub 3.0/3.5 Localise le premier enregistre ment satisfaisant le critère FindLast Criteria As String Sub 3.0/3.5 Localise le dernier enregistre ment satisfaisant le critère FindNext Criteria As String Sub 3.0/3.5 Localise le prochain enregistre ment satisfaisant le critère FindPrevious Criteria As String Sub 3.0/3.5 Localise le précédent enregistre ment satisfaisant le critère GetRows [crows] Variant 3.0/3.5 Écrit plusieurs enregistrements dans un tableau

263 256 Annexe A : DAO 3.0/3.5 Collections, Propriétés et Méthodes Méthode Paramètres Retourne Ve son Description Move Rows As Long, [StartBookmark] Sub 3.0/3.5 Repositionne le pointeur relati vement à la position courante ou à un signet MoveFirst Sub 3.0/3.5 Déplacement vers le premier enregistrement du jeu d'enregis trements MoveLast Sub 3.0 Déplacement vers le dernier enregistrement du jeu d'enregis trements MoveLast [Options As Long] Sub 3.5 Déplacement vers le dernier enregistrement du jeu d'enregis trements MoveNext Sub 3.0/3.5 Déplacement vers le prochain enregistrement du jeu d'enregis trements MovePrevious Sub 3.0/3.5 Déplacement vers le précédent enregistrement du jeu d'enregis trements NextRecordset Boolean 3.5 Retrouve le prochain jeu dans un jeu d'enregistrements multi requêtes OpenRecordset [Type], [Options] Recordset 3.0/3.5 Crée un nouvel objet Recordset Requery [NewQueryDef] Sub 3.0/3.5 Réexécute la requête sur laquelle est basé le jeu d'enregistrements Seek Comparison As String, Keyl... Sub 3.0/3.5 Localise un enregistrement dans un jeu d'enregistrements de type table Update Sub 3.0/3.5 Sauvegarde les changements initiés par les méthodes Edit ou AddNew Propriétés Propriété Type Version Description AbsolutePosition Long 3.0/3.5 Retourne ou paramètre le numéro d'ordre de l'enregistrement courant BatchCollisionCount Long 3.5 Nombre de lignes ayant eu des collisions dans la dernière mise à jour du batch BatchCollisions Variant 3.5 Indique les lignes ayant eu des collisions dans la dernière mise à jour du batch BatchSize Long 3.5 Détermine le nombre de mises à jours à inclure dans un batch BOF Boolean 3.0/3.5 Indique si la position de l'enregistrement courant est avant le premier enregistrement

264 Objet Recordset 257 Propriété Type Version Description Bookmark As Byte 3.0/3.5 Identifie de manière unique un enregistrement particulier dans un jeu d'enregistrements Bookmarkable Boolean 3.0/3.5 Indique si un jeu d'enregistrements supporte des signets CacheSize Long 3.0/3.5 Nombre d'enregistrements en provenance d'une source de données ODBC à placer dans le cache local CacheStart As Byte 3.0/3.5 Signet du premier enregistrement à placer dans le cache en provenance d'une source de données ODBC DateCreated EditMode EOF Filter Variant 3.0/3.5 Date et heure de création de la table de la base sous-jacente Integer 3.0/3.5 Indique l'état de l'édition pour l'enregistrement courant Boolean 3.0/3.5 Indique si la position de l'enregistrement courant est après le dernier enregistrement String 3.0/3.5 Définit un filtre à appliquer au jeu d'enregistre ments Index String 3.0/3.5 Nom de l'objet Index courant (jeu d'enregistrements de type table uniquement) LastModified As Byte 3.0/3.5 Signet indiquant l'enregistrement ajouté ou modifié en dernier LastUpdated Variant 3.0/3.5 Date et heure des changements les plus récents apportés à la table de la base sous-jacente LockEdits Boolean 3.0/3.5 Indique le type de verrouillage (optimiste ou pessimiste) en vigueur durant l'édition Narre String 3.0/3.5 Nom de l'objet Recordset NoMatch Boolean 3.0/3.5 Indique si les méthodes Seek ou Find ont réussi à retrouver un enregistrement PercentPosition Single 3.0/3.5 Indique ou modifie l'emplacement de l'enregis trement courant RecordCount Long 3.0/3.5 Nombre d'enregistrements dans l'objet Recordset RecordStatus Restartable Integer 3.5 Indique le statut de mise à jour de l'enregistre ment courant Boolean 3.0/3.5 Indique si le jeu d'enregistrements supporte la méthode Requery Sort String 3.0/3.5 Définit l'ordre de tri des enregistrements d'un jeu StillExecuting Boolean 3.5 Indique si une méthode d'appel asynchrone est en cours d'exécution Transactions Boolean 3.0/3.5 Indique si le jeu supporte les transactions Type Integer 3.0/3.5 Indique le type de données de l'objet Updatable Boolean 3.0/3.5 Indique si des enregistrement dans le jeu d'enre gistrements peuvent être mis à jour

265 258 Annexe A : DAO Collections, Propriétés et Méthodes Propriété Type Version Description UpdateOptions Long 3.5 Détermine la construction d'une requête de mise à jour par batch ValidationRule String 3.0/3.5 Contient une expression pour évaluer True pour assurer le succès de la mise à jour ValidationText String 3.0/3.5 Message à afficher si ValidationRule échoue Objet Relation Collections Propriété Type Version Description Fields Fields 3.0/3.5 Collection de champs dans l'objet Relation Properties Propriétés 3.0/3.5 Collection d'objets Property Méthodes Méthode Paramètres Retourne Version Description CreateField [Name], [Type], [Size] Field 3.0/3.5 Crée un nouvel objet Field Propriétés Propriété Type Version Description Attributes Long 3.0/3.5 Caractéristiques diverses de l'objet Relation ForeignTable String 3.0/3.5 Spécifie le nom de la table étrangère (référencée) dans une relation Name String 3.0/3.5 Nom de cet objet Relation PartialRepfica Boolean 3.5 Indique si la relation fournit les règles d'une syncronisa tion partielle Table String 3.0/3.5 Spécifie TableDef (référence) ou Querydef Objet TableDef Collections Propriété Type Version Description Fields Fields 3.0/3.5 Collection de champs dans l'objet TableDef Indexes Indexes 3.0/3.5 Collection d'index associés à l'objet TableDef Properties Propriétés 3.0/3.5 Collection d'objets Property

266 Objet TableDef 259 Méthodes Méthode Paramètres Retourne Version Description CreateField [Name], [Type], [Size] Field 3.0/3.5 Crée un nouvel objet Field Createlndex [Name] Index 3.0/3.5 Crée un nouvel objet Index CreateProperty [Name], [Type], [Value], [DDL] Property 3.0/3.5 Crée un nouvel objet Property défini par l'utili sateur OpenRecordset [Type], [Options] Recordset 3.0/3.5 Crée un nouvel objet Recordset RefreshLink Sub 3.0/3.5 Met à jour l'information sur la liaison pour une table rattachée Propriétés Propriété Type Version Description Attributes Long 3.0/3.5 Caractéristiques diverses de l'objet TableDef ConflictTable String 3.0/3.5 Nom de table contenant des enregistrements qui entrent en conflit durant une replication synchro nisée Connect String 3.0/3.5 Source de données pour TableDef DateCreated Variant 3.0/3.5 Date et heure de création de la table LastUpdated Variant 3.0/3.5 Date et heure du dernier changement de TableDef Name String 3.0/3.5 Nom de TableDef RecordCount Long 3.0/3.5 Nombre d'enregistrements ReplicaFilter Variant 3.5 Indique quels enregistrements à inclure dans une copie partielle SourceTableName String 3.0/3.5 Nom de la table source origine d'une table liée Updatable Boolean 3.0/3.5 Indique si la définition de TableDef peut être modi fiée ValidationRule String 3.0/3.5 Évaluation de l'expression à True pour valider la réussite de la mise ValidationText String 3.0/3.5 Message à afficher si ValidationRule échoue

267 260 Annexe A : DAO Collections, Propriétés et Méthodes Objet User Collections Propriété Type Version Description Groups Groups 3.0/3.5 Collection d'objets Group dans un objet User Properties Propriétés 3.0/3.5 Collection d'objets Property Méthodes Méthode Paramètres Retourne Version Description CreateGroup [Name], [PID] Group 3.0/3.5 Crée un nouvel objet Group NewPassword Propriétés bstrold As String, bstrnew As String Sub 3.0/3.5 Modifie le mot de passe d'un compte utilisateur existant Propriété Type Version Description Name String 3.0/3.5 Le nom de l'objet User Password String 3.0/3.5 Mot de passe du compte de l'utilisateur PID String 3.0/3.5 Identifiant personnel (PID) pour un compte d'utilisateur ou de groupe Objet Workspace Collections Propriété Type Version Description Connections Connections 3.5 Collection d'objets Connection Databases Databases 3.0/3.5 Collection d'objets open Database Groups Groups Collection d'objets Group dans un objet Workspace Users Users 3.0/3.5 Collection d'objets User pour un objet Workspace

268 Obiet Workspace 261 l1/f, thnilvc Méthode Paramètres Retourne Version Description BeginTrans Sub 3.0/3.5 Commence une nouvelle transaction Close Sub 3.0/3.5 Ferme l'objet Works pace CommitTrans Sub 3.0/3.5 Termine la transac tion et sauvegarde les changements CreateDatabase CreateGroup CreateUser OpenConnection OpenDatabase Rollback Name As String, Connect As String, [Option] Database 3.0/3.5 Crée une nouvelle base de données Microsoft jet data base (.mdb) [Name], [PID] Group 3.0/3.5 Crée un nouvel objet Group [Name], [PID], [Password] Name As String, [Options], [ReadOnly], [Connect] Name As String, [Exclusive], [ReadOnly], [Connect] User 3.0/3.5 Crée un nouvel objet User Connection 3.5 Ouvre une liaison vers une base de données Database 3.0/3.5 Ouvre une base de données Sub 3.0/3.5 Annule les change ments depuis le dernier BeginTrans Propriétés Propriété Type Version Description DefaultCursorDriver Long 3.5 Sélectionne la librairie de curseurs ODBC IsolateODBCTrans Integer 3.0/3.5 Indique si des transactions multiples sont isolées (ODBC uniquement) LoginTimeout Long 3.5 Nombre de secondes allouées pour le logging dans une base de données ODBC Name String 3.0/3.5 Nom de cet objet Workspace UserName String 3.0/3.5 Utilisateur ayant créé l'objet Workspace

269 B Le quotient de deux tables n'est pas souvent utilisé, mais il a un usage très spécifique. Il intervient lorsque l'on veut sélectionner les lignes d'une table qui fournissent toutes les valeurs possibles dans certaines colonnes. Comme exemple, imaginons une entreprise qui fabrique des meubles. La base de données de cette entreprise contient une table des types de bois utilisés et et une table des fournisseurs avec le type correspondant. Voici un exemple (naturellement, ces tables comporteraient davantage de colonnes, mais c'est juste pour illustrer le propos) Table B-1. BOIS Type Mahogany Red oak Poplar Walnut Table B-2. FOURNISSEUR/TYPE Snom Jones Wood Supply Austin Hardwoods Orange Coast Jones Wood Supply West Lumber Jones Wood Supply Austin Hardwoods Jones Wood Supply Type mahogany red oak mahogany poplar poplar walnut walnut red oak 263

270 264 Annexe B : Le Quotient : une opération complémentaire de l'algèbre Relationnel Table B-2. FOURNISSEUR/TYPE(suite) Snom Orange Coast West Lumber Orange Coast Orange Coast Fred's Woods walnut red oak poplar red oak walnut Type Noter qu'il y a quatre types de bois. Supposons que nous voulions savoir quels fournisseurs livrent les quatre types-une question sensée. La réponse dans ce cas est Table B-3. FOURNISSEUR/TYPE - BOIS Sname Jones Wood Supply Orange Coast et est appelée le quotient de la table FOURNISSEUR/TYPE par BOIS, écrit FOURNISSEUR/TYPE _ BOIS. Comme vous pouvez le voir, le quotient peut refléter des situations de la vie réelle. La définition d'une opération spécifique dans ce but trouve sa raison d'être dans la difficulté à exprimer le quotient en termes de relations. Essayons d'illustrer les vertus du quotient. L'idée est en fait relativement simple. Prenons une table, appelée T, contenant toutes les lignes qui ne sont pas dans la table FOURNISSEUR/TYPE. Cette nouvelle table va concerner uniquement ceux des fournisseurs qui n'ont pas livré tous les types de bois (si un fournisseur livre les quatre types de bois, il y aura alors quatre lignes dans la table FOURNISSEUR/TYPE et de ce fait aucune ligne dans la table T). Nous soustrayons alors ceci d'une table contenant tous les fournisseurs (effectifs). Voici la procédure étape par étape Etape 1: Former la table R = [projsnom(fournisseur/type) H BOIS] - FOURNISSEUR/TYPE C'est la table contenant toutes les lignes de la forme (SNom,Type) qui ne sont pas dans la table FOURNISSEUR/TYPE. Autrement dit, c'est le jeu des "possibilités

271 Le Quotient : une opération complémentaire de l'algèbre Relationnel 265 manquantes" du produit cartésien (qui est le jeu de toutes les possibilités). Voici la table R Table B4. R Snom Austin Hardwoods West Lumber Austin Hardwoods West Lumber Fred's Woods Type poplar walnut mahogany mahogany walnut Etape 2: Former la table projsnom(r) C'est-à-dire, projeter la table R sur la colonne SNom, pour donner les FOURNIS- SEURS qui ne livrent pas tous les types de bois. Table B-5. projsnom(r) SNom Austin Hardwoods West Lumber Fred's Woods Etape 3: Finalement, former la table pro]snom(fournisseur/type)-projsnom (R) C'est-à-dire, soustraire la table de l'etape 2 de la première colonne de la table FOURNISSEUR/TYPE. Ceci donne les fournisseurs qui fournissent les quatre types de bois. Table B-6. FOURNISSEUR/TYPE - BOIS SNom Jones Wood Supply Orange Coast

272 C Consulter ou créer la base de données échantillon Le fichier brut "base de données," de même que la base de données Access correspondante et les programmes exemple qui l'accompagnent, sont disponibles sur le site Internet d'o'reilly (hhp:// Pour l'édition française de l'ouvrage, seuls les exemples pour Access 97 ont été placés sur le CD-Rom. Ils se trouvent dans le répertoire Exemples. Si vous n'avez pas de lecteur de CD-Rom et si voulez récupérer la version américaine des exemples pour Access 95 et pour Access 97, vous devez vous connecter au site d> O'Reilly. Deux méthodes sont disponibles pour télécharger les données qui accompagnent cet ouvrage Via le World Wide Web. Les fichiers sont disponibles depuis ftp:// ftp.oreilly.com/ published/oreilly/windows/access.design/example.tip. Via un programme client ftp. Vous pouvez utiliser un client tel que WS_ PTP32. Connectez-vous à ftp.oreilly.com, puis changez de répertoire published/ oreilly/windows/ access.design, et récupérez le fichier example. ip. Dans chaque cas, les fichiers sont archivés dans un fichier compressé à l'aide de PKZip. Si vous ne possédez pas d'utilitaire capable de décompresser les software (ou si vous accomplissez cette tâche depuis la ligne de commande), nous vous recommandons vivement de télécharger une version d'évaluation de l'utilitaire WinZip, de Nico Mak Computing, Inc. Il est disponible à EXAMPT.F.ZIP contient LIBRARY FLAT.DOC la base de données brute créée à l' aide de Microsoft Word, de même que LIBRARY95.MDB, la base de données échantillon Access pour Office 95, et LIBRARY97.MBD, la base de données Access pour Office 97 (les deux versions ont un fonctionnement optimal dans leur 267

273 268 Annexe C : Consulter ou créer la base de données échantillon format de fichier natif). Le fichier MDB lui-même contient les composants suivants Les quatre tables (BOOKS, AUTHORS, PUBLISHERS et BOOK/ AUTHOR) et leurs indexes primaires Un module de code, Samples, qui contient tous les exemples de programmes du livre. Les exemples du CD-Rom sont identiques, mais ont été francisés : la base de données est LIBRARYMDB. Les quatre tables ci-dessus ont été renommées : LIVRES, AUTEURS, EDI- TEURS et LIVRE/AUTEUR Les en-têtes de colonne de ces tables ont été également renommés pour une meilleure compréhension de leur contenu Dans sa version américaine, la base ne contient pas de définitions de relations, ni de définitions de requêtes. Le livre admet que vous les créerez vous-même. Dans la version française, les liaisons et les requêtes ont été ajoutées lorsque cela paraissait souhaitable. De plus, le contenu des tables peut être visualisés dans des formulaires. Sur le CD-Rom, le contenu de la base de données est adapté aux exemples de chaque chapitre, de sorte qu'un exemplaire de la base figure dans tous les sous répertoires. Ainsi, lorsque des tables doivent être créées pour certains exemples, elles figurent déjà dans la base correspondante. Les exemples sont commentés et illustrés à l'aide de documents HTML. Vous devez donc utiliser un navigateur pour les visualiser. Les exercices proposés sont décrits avec leurs réponses. Ils doivent être exécutés avec la base library.mdb correspondante. Bien que les exemples se trouvent sur le CD-Rom, vous pourriez à titre d'exercice reconstituer la base de données vous-même. Il est très facile de créer les différentes tables en partant des exemples et des écrans du livre. Dans le reste de cette section, nous allons vous guider pas à pas dans la création de chacune de ces tables de la base de données Library, LIBRARY.MDB.

274 Propriété scréation de la base de données 269 Création de la base de données La première étape consiste à créer la base de données elle-même en procédant de la manière suivante 1. Démarrez Microsoft Access. 2. Lorsque la boîte de dialogue Microsoft Access apparaît dans la fenêtre principale Access, comme le montre la figure C-1, sélectionnez l'option Nouvelle base de données et cliquez sur OK. Access ouvre la boîte de dialogue Fichier Nouvelle base de données. Figure C-1. Boîte de dialogue Microsoft Access 3. Parcourez le disque à la recherche du répertoire dans lequel vous voulez sauvegarder le fichier de la base de données. Si le répertoire n'existe pas, vous pouvez le créer en cliquant sur le bouton Créer un nouveau dossier (troisième bouton à gauche sur la barre d'outils); vous devriez naviguer vers ce répertoire. Dans la champ Nom de fichier, tapez library.mdb. Cliquez ensuite sur le bouton Créer. Access crée la nouvelle base de données et ouvre la fenêtre de base de données Library, qui devrait ressembler à la figure C-2. C'est une base de données complètement vide; elle ne contient même pas de tables capables de contenir des données. Notre première étape sera donc de définir chacune de ces tables et d'y entrer des données.

275 270 Annexe C : Consulter ou créer la base de données échantillon La livres97 : Base de données Figure C-2. L a fenêtre Base de données Library Création de la table LIVRES Pour définir la conception de la table LIVRES, suivez ces étapes Cliquez sur le bouton Nouveau dans la fenêtre de la base de données Library. Access ouvre la boîte de dialogue Nouvelle table, qui contient une liste de différentes options. Sélectionnez Vue conception et cliquez sur OK. Access ouvre la fenêtre table Tablel, comme le montre la figure C-3, qui vous permet de définir les champs d'une nouvelle table de la base de données. Figure C-3. La fenêtre Table 1

276 Création de la table LIVRES 271 Entrez l'information affichée à la table C-1 dans les colonnes Nom de champ et Type de données de la fenêtre table de la Tablel. Notez que vous pouvez sélectionner le type de donnée depuis une liste déroulante. Table C-1. Champs de la table LIVRES Nom de champ ISBN Titre PubID Prix Type de données Texte Texte Texte Monétaire Lorsque vous sélectionnez un champ, ses propriétés sont affichées dans la zone inférieure de la boîte de dialogue. Ensuite, entrez les propriétés du champ individuel affichées à la table C-2 dans la zone Propriétés des champs de la boîte de dialogue. Notez que vous n'avez pas à ajouter ou modifier les propriétés du champ Prix. Désignez ISBN comme la clé primaire de la table. Pour cela, cliquez sur le bouton Clé primaire de la barre d'outils (11 ème bouton à partir de la gauche de la barre d'outils, immédiatement à la gauche du bouton Défaire), ou cliquez avec le bouton droit sur le sélecteur de ligne (le champ ombré en gris à la droite de la colonne champ ISBN) et sélectionnez Clé primaire dans le menu déroulant. Sauvegardez la conception de la table. Cliquez sur le bouton Enregistrer sur la barre d'outils (le second bouton à partir de la gauche) ou sélectionnez l'option Enregistrer du menu Fichier. Lorsque Access ouvre la boîte de dialogue Enregistrer sous..., tapez LIVRES dans le champ Nom de table et cliquez sur OK. Fermez la table LIVRES dans la Vue conception.

277 272 Annexe C : Consulter ou créer la base de données échantillon Table C-2. Propriétés de la table LIVRES Nom du champ Propriété Valeur ISBN Indexé Oui (Sans doublons) Titre Taille de champ 200 Indexé Oui (Avec doublons) PubID Indexé Oui (Avec doublons) Prix Format Monétaire Vous êtes prêt à entrer des données dans la table. Sélectionnez la table LIVRES dans la fenêtre base de données et cliquez sur le bouton Ouvrir. Access ouvre la table LIVRES dans la Vue feuille, qui permet d' entrer des informations dans la base de données. Entrez les données affichées à la table C-3. Lorsque vous avez terminé, fermez la table. Notez que vous n'avez pas à sauvegarder de manière explicite les données que vous avez entrées dans la table; Access prend en charge automatiquement l'écriture sur le disque des enregistrements que vous avez saisis. Table C-3. Données de la table LIVRES ISBN Titre PubID Prix Macbeth Faerie Queene Emma Hamlet Main Street Visual Basic On Liberty Iliad C Balloon Ulysses King Lear Jane Eyre Moby Dick

278 Création de la table AM E URS 273 Création de la table A UTE URS Pour créer la table AUTEURS, suivez les étapes décrites à la section précédente, " Création de la table LIVRES". Les définitions de champs pour la table AUTEURS sont énumérées à la table C-4. Table C-4. Champs de la table AUl '' URS Nom du champ AuID AuNom AuPhone Type de données Texte Texte Texte Il y a une seule propriété à spécifier Nom du champ: Propriété Valeur AuID Indexé Oui (Sans doublons) Lorsque vous avez achevé la création des champs et que vous avez assigné leurs attributs, définissez AuID comme clé primaire de la table. Sauvegardez la table, en lui attribuant le nom AUTEURS. Entrez ensuite les données sur les auteurs dans la table; le résultat figure à la table C5. Table C-5. Données de la table AU'J FURS AuID AuNom AuPhone 1 Austen Grumpy Homer Jones Joyce Meville Mill Roman Shakespeare Sleepy Smith

279 274 Annexe C : Consulter ou créer la base de données échantillon Table C-5. Données de la table AM E URS(suite) AuID AuNom AuPhone 11 Snoopy Spenser Création de la table EDIT E UR.S Suivez à nouveau les étapes listées plus haut à la section "Création de la table LIVRES" pour créer la table EDITEURS. Les définitions de champs de la table EDITEURS figurent à la table C-6. Table C-6. Champs de la table A Ul E URS Nom du champ PubID PubNom PubPhone Type de données Texte Texte Texte Là aussi, il n'y a qu'une seule propriété à spécifier Nom du champ Propriété Valeur PubID Indexé Oui (Sans doublons) Désignez PubID comme clé primaire, et sauvegardez la table sous le nom EDITEURS. Une fois la création de la table EDITEURS achevée, vous pouvez y entrer des données. La table EDITEURS contient les enregistrements de trois éditeurs seulement à la table C-7. Table C-7. Données de la table EDITEURS PubID PubNom PubPhone 1 Big House Alpha Press Small House

280 Création de la table LIVREIAUTEUR 275 Création de la table LIVREIAUTEUR La table LIVRE/AUTEUR est la table finale nécessaire pour nos exemples. Créezla en suivant de nouveau les mêmes étapes de base décrites plus haut "Création de la table LIVRES". Elle comprend deux champs seulement, comme le montre la table C- 8. Après avoir entré les noms de champ et les types de données dans la définition de la table, modifiez les deux propriétés énumérées à la table C-9 et sauvegardez la table avec le nom LIVRE/AUTEUR. Lorsque vous sauvegardez la table, Access ouvre la boîte de dialogue de la figure C-4. La table n'a pas de clé primaire, aussi cliquez sur le bouton Non; Access sauvegardera la table sans désigner de clé primaire. Table C-8. Champs de la table LIVREIAU'I i UR Nom du champ ISBN AuID Type de données texte texte Table C-9. Propriétés de la table LIVREIAUTEUR Nom du champ Propriété Valeur ISBN Indexé Oui (Avec doublons) AuID Indexé Oui (Avec doublons) Figure C-4. La boîte d'alerte `pas de clé primaire"

281 276 Annexe C : Consulter ou créer la base de données échantillon Lorsque vous avez créé LIVRE/AUTEUR, vous pouvez entrer les données affichées à la table C-10. Table C-10. Données pour la table LIURE/AUI E UR ISBN AuID Lorsque vous aurez terminé l'entrée des données, il vous restera à définir les relations entre les tables. Ceci est abordé en détail à la section "Définir les relations dans Access" du chapitre 3, Implémentation de modèles relationnels : bases de données relationnelles. Ce détail étant pris en compte, vous pouvez utiliser les tables pour créer les requêtes et lancer les programmes examinés dans le corps du livre. Sauvegarde de la base de données Une fois que vous avez créé la base de données LIBRARY, il est judicieux de faire une copie de sauvegarde de chacune des tables. De cette manière, vous pouvez vous sentir libre d'effectuer des modifications dans les tables individuelles, pour essayer les programmes de démonstration du livre, faire des essais sur les données, les tables et la base de données, sans avoir à vous préoccuper d'une détérioration éventuelle des données. Vous pouvez faire une copie de sauvegarde en suivant la procédure cidessous pour chacune des quatre tables de la base de données

282 Sauvegarde de la base de données Activez la table que vous voulez sauvegarder. 2. Sélectionnez l'option Enregistrer sous. depuis le menu Fichier. Access ouvre la boîte de dialogue Enregistrer sous... illustrée à la figure C Sélectionnez le bouton Dans la base de données en cours comme. Access suggère un nom de fichier pour votre copie de sauvegarde, telle que Copie de LIVRES, comme l'illustre la figure C Cliquez sur le bouton OK pour créer la copie de sauvegarde. Elle apparaîtra dans la feuille de propriétés des tables de la boîte de dialogue Base de données. Figure C-5. L a boîte de dialogue Enregistrer sous., Si les données de l'une de vos tables se perdent ou sont endommagées, vous pouvez restaurer la table de la manière suivante 1. Activez la copie de sauvegarde de la table dans la fenêtre Base de données. 2. Sélectionnez l'option Enregistrer sous... depuis le menu Fichier. Access ouvre de nouveau la boîte Enregistrer sous... illustrée à la figure C Sélectionnez le bouton Dans la base de données en cours comme 4. Remplacez le nom de fichier suggéré par Access (Copie de...) avec le nom de la table d'origine et cliquez sur OK. 5. Access affiche un message d'avertissement vous prévenant que le nom a déjà été affecté à une autre table et vous demande si vous voulez la remplacer. Cliquez sur OK.

283 278 Annexe C : Consulter ou créer la base de données échantillon NO"1 E Avant de remplacer une table reliée à d'autres tables, vous devez effacer les relations de cette table avec les autres tables. Pour ce faire, sélectionnez l'option Relations depuis le menu Outils. Lorsqu'Access ouvre la fenêtre Relations, cliquez avec le bouton droit sur la ligne symbolisant la relation à laquelle une table participe, puis sélectionnez l'option Effacer depuis le menu déroulant. Entrer et lancer les programmes échantillon L'exemple de base de donnée présente sur le CD-Rom (ou téléchargée depuis le site d>o'reilly &Associates), inclut un module de code, Exemples, contenant tous les exemples de programmes VBA du livre. Vous pouvez créer un module de code vous-même et y entrer des programmes. Pour créer le module de code 1. Sélectionnez l'onglet Modules lorsque la base de données Library est ouverte dans la fenêtre Base de données. 2. Cliquez sur le bouton Nouveau pour créer un nouveau module de code. 3. Quand Access ouvre un nouveau module de code (qu'il appelle généralement Modulel, à moins que votre base de données contienne déjà des modules de code sauvegardés avec leur nom par défaut), cliquez sur l'icone Enregistrer sous de la barre d'outils. 4. Lorsqu'Access affiche la boîte Enregistrer sous..., entrez le nom de votre nouveau module de code, Exemples, dans le champ Nom de module et cliquez sur OK. Vous pouvez alors commencer à entrer du code pour chacun des exemples de programmes. Pour chaque exemple de code suivez les étapes ci-après 1. Sélectionnez l'option Procédure dans le menu Insertion. 2. Lorsqu'Access ouvre la boîte de dialogue Insérer une procédure, entrez le nom de la procédure dans le champ Nom. Comme tous les programmes listés dans le livre sont des sous-programmes, vous n'avez pas à vous préoccuper des autres options de la boîte de dialogue. Cliquez juste sur OK. Pour lancer un programme

284 Entrer et lancer les programmes échantillon Sélectionnez l'onglet Modules dans la fenêtre Base de données et ouvrez le module Exemples. 2. Sélectionnez l'option Fenêtre Déboguage du menu Affichage. 3. Lorsqu'Access ouvre la Fenêtre de déboguage, tapez simplement le nom du programme que vous voulez lancer.

285 D Suggestions de lecture Voici une brève liste d'ouvrages sur la théorie des bases de données Atzeni, P. et De Antonellis, V., Relational Database Theory, Benjamin Cummings, 1993, 389 pages. Un traitement théorique et mathématique de haut niveau sur le sujet. Codd, E. F., The Relational Model for Database Management: Version 2, Addison-Wesley, 1990, 538 pages. L'exposition classique du modèle relationnel par un de ses créateurs et principaux promoteurs. Date, C.J., An Introduction to Database Systems, 6th Edition, Addison-Wesley, 1995, 839 pages. Un ouvrage moins formel et d'une lecture accessible. Simovici, D. and Tenney, R., Relational Database Systems, Academic Press, 1995, 485 pages. Cet ouvrage offre un traitement très mathématique du sujet. Bien mieux écrit que le livre de Atzeni et De Antonellis. Ullman, J., Principles of Database and Knowledge-Base Systems, Volume 1: Classical Database Systems, Computer Science Press, 1988, 631 pages. Ouvrage offrant un point de vue quelque peu différent. Pas aussi mathématique que Atzeni ou Simovici, mais plus mathématique que Date. 68

286 ! (bang) opérateur, 175 (dot) opérateur, 175 {THETA}- jointures, 84, 89, 107 1NF ( première forme normale), 46 2NF ( seconde forme normale), 46 3NF ( troisième forme normale), 46 A AbsolutePosition : propriété, 231 Access (Voir Microsoft Access) Access SQL,67, DDL composant de, DML composant de, raisons d'utiliser, 99 conventions syntaxiques, 100 Add: méthode, 180 ajout d'enregistrements à des jeux, 238 ajouter des colonnes à une table, 105 AddNew: méthode, 238 adresse mémoire, 165 algèbre relationnel, et opérations sur les tables, ALL: option, instruction SELECT, 109 instruction UNION, 121 AllowZeroLength : propriété, 213 ALTER TABLE : instruction, 105 Append: méthode, 179 anomalies d' insertion, 7 architecture client/ serveur, 143 assurer l'intégrité référentielle (boite), 36 attributs indivisibles, 47 attributs strictement informatifs, 44, 49 attributs structurés, 47 auto-jointures, 108 autorisations d'accès, 194 attributs, 14-16, 24 noms pleinement qualifiés, 74 indivisible, 47 pour objets Relation, 217 renommer des, 67 super-clés, 16 schémas de table, 22, 26 types d', 44 attributs atomiques, 47 attributs scalaires, 47 B bases de données, 11 relationnelles, 3-9, 26 création dans DAO de, CurrentDb : fonction de,

287 284 DAO DDL, DAO DML, Database : objets, normalisation de: obtention/création de, 211 ouverture de, 211 programmation de, 9 sauvegarde de, 276 systèmes de, 135 bases de données à plat, 3 base de données conceptuelle, 136 base de données physique, 135 portée limitée à la procédure, 154 BCNF (forme normale Boyce-Codd), 52 BOF : propriété, 229 boucle Do, 161 boucle For, 161 Boyce-Codd : forme normale, 52 C calcul relationnel, catalogue de données, 137 chaînes vides, 40 champs, 37 création de (dans des tables): objets Field, 199 propriétés des, 212 classes, 14 classes d'entités, 12 classes DAO : liste de, clés, 16, 25 candidates, 17 étrangères, dépendance fonctionnelle et, 49 NULLs apparaissant dans, 40 référencées, 29 super-clés, 16, 25 index uniques, 39 clés étrangères Index intégrité référentielle et, 31 clés primaires, 17, 38 clés référencées, 28 Close : méthode, 190 collections, 171, collections Access, 179 collections DAO, 179 collections par défaut (DAO), 177 collections définies par l'utilisateur, 180 collections Properties (DAO), colonnes, définitions de, 102 colonnes, en-têtes de, 23 colonnes, ajout/ suppression de, 105 Container : objets, 172, , 245 Containers : collections, 172 constantes (VBA), 149 constantes littérales (VBA), 149 constantes symboliques (VBA), 149 contraintes CONSTRAINT : clause, 103 contraintes multi-colonnes, 105 contraintes référentielles, 31 contraintes sur une colonne, 103 Controls : collection, 179 Count : propriété, 179 créer une base de données, 210 créer une table et ses champs, 211 créer un index, 215 créer une relation, 217 créer un objet QueryDef, 219 CREATE INDEX: instruction, CREATE TABLE: instruction, CreateDatabase : méthode, CreateField : méthode, 212 Createlndex : méthode, 215 CreateQueryDef : méthode, 219 CreateRelation : méthode, 217 CreateTableDef : méthode, 211 création d'une base exemple, CurrentDb : fonction, 173,

288 Index 285 D DAO (Data Access Objects), 133, 137 liste de classes, fermeture d'objets, 190 collections, création d'objets QueryDefs, création de relations, création de tables, création/ouverture d'une base de données dans, modèle objet, liste d'objets, collection Properties, objets de référence, data types (Voir types) Database : collections, 170, 191, 195 Databases : conteneur,197 DBEngine : objet, 192 DBEngine : objets, DBMS (database management system), 137 architecture client/serveur de, 143 Jet DBMS: DDL (data definition language) instructions Access SQL, Jet DBMS : composant de, 140 décomposition sans perte, 58 décomposition de schémas de table, décomposition et conservation des dépendances, 58 défaut collections par, 177 types d'enregistrements par, 228 DefaultValue : propriété, 213 degré d' une table, 23, 69 DELETE : instruction, 123 dépendances fonctionnelles, 47 décomposition et, 56 déplacement dans des jeux d'enregistre ments, diagramme E/R, 18 dictionnaire de données, 137 différence de tables, Dim : mot-clé (VBA), 150 DISTINCT : option (instruction SE LECT), , DistinctCount : propriété, 216 DISTINCTROW : option (instruction SELECT), DLL (langage de définition de données) composant Access SQL, DAO DDL, DML (langage de manipulation de don nées) composant Access SQL, DAO DML, composant jet DMBS, 141 Documents : collection, 172, 198, 249 domaines, 23 données édition de : à l'aide d'un jeu d'enre gistrements, perte de, 8 valeurs NULL, 40 persistence de, 12 visualisatüon de, 8 données, dictionnaire/catalog de, 137 DROP : instruction, 106 duplication de données (Voir redondan ces) dynaset : objets Recordset de type, 226, 234 E édition de données à partir de jeux d'en registrements, entités, 12-16, 24 diagrammes E/R d', 18 implanter des, relations entre, 18

289 Index entités: classes d', 12, 25, 29 attributs de, implanter des, 22 super-clés de, 16, 25 entités: jeux d', 13, 25 implanter des, 22 super-clés et, 17 enregistrements, 37 espaces de travail, 193 F fenêtre de débogage, 154 fermeture d'objets (DAO), 190 fichiers index, Fields : collection, 174 Field: objets, 250 fichiers (voir tables) Find : méthode 234 fonctions: VBA, 147, fonctions chaîne ( VBA), Forms : collection, 173 Form : objets, 173, 179 Forms : conteneur, 197 formes normales, 46 dépendance fonctionnelle, 47 FROM : clause (instruction SELECT), 119 G GROUP BY : option (de l'instruction SELECT), 120 Group : objets, 194, 251 H HAVING: option (de l'instruction SELECT), 120 I implémentation de jointures, index primaire, 38 index secondaire, 38 index unique, 38 instructions de contrôle : VBA, intégrité référentielle, 8, 31 If-Then : instruction, 160 IgnoreNulls : propriété, 216 Index : propriété, 230 Index : objets, 252 Index : boîte de dialogue, 39 index : table, Index objets, 200 indices : colonne de table,105 Inherited : propriété héritée, 187 INNER JOIN : clause, 107 InputBox : fonction, 157 INSERT INTO : instruction, 123 Instr : fonction, 159 Internal ISAM Component, 138 intersection de tables, 71 ISAM (Indexed Sequential Access): thode, 138 Item : méthode, 180 J jeux secondaires de tables projection et, 76 sélection de: Jet DBMS, JOIN : instruction, 107 jointures de tables, 80-87, implanter dans Access des, auto-jointures, 108 équi-jointures, 80-81, 87 semi-jointures, semi-jointures droites, 91 semijointures gauches, 91

290 Index 287 jointures externes, 85-86, 90, 107 jointures externes droites, 85, 91 jointures externes gauches, 73, 85, 90 jointures imbriquées, 107 jointures internes, 80-85, 107 jointures naturelles, 81-84, 87 jointures SQL, 107 L langage de manipulation de données (Voir DML) langage de définition de données (Voir DDL) langage jet de définition de données, 140 langage jet de manipulation de données, 142 langages hôte, 138, 139, 143 langages de requêtes, 62 langages de requête algébriques, langages non-procéduraux, 64 langages procéduraux, 64 LCase : fonction, 158 LEFT : fonction, 158 Len : fonction, 158 lignes insertion de, 123 ordre des, 23 M Macros conteneur, 197 metadonnées, 138 méthodes pour des objets spécifiques, methods: objet, 169, 171 de collections DAO, 171, 179 de collections définies par l'utilisa teur, 180 Microsoft Access collections, 179 fonction CurrentDb, modèle objet, 173 Mid : fonction, 158 mise à jour anomalies diverses, 6-7 en cascade, 31 record, 236 requêtes de, 106, 106, 122 mises à jour/suppressions en cascade, 31 modèle de base de données distant, 144 modèle distribué client/serveur, 144 modèles sémantiques, 19 modules, 147 modules collection, 173 portée limitée au module, 154 modules container, 197 modules de gestion jet DBMS, Move : méthodes (objet Recordset), MsgBox : instruction, 156 N Name : propriété, 187 naviguer dans des jeux d'enregistre ments, niveau externe d'une base de données, 136 niveau interne d'une base de données, 136 noms d'attributs pleinement qualifiés, 74 noms d'objets pleinement qualifiés, 174 nom d'attribut qualifié, 74 noms semiqualifiés, 175 normalisation, NULL : valeurs, 40 O Object Browser : utilitaire, 241 objet : types, 164

291 Index objets, Access modèle objet, 173 fermeture d', 190 collections (Voir collections) DAO : modèle, DAO : liste d', collections par défaut, 177 noms pleinement qualifiés d', 174 Property : objet, 187 Properties : collection d', de référence, 169, objets Collection, DAO : liste de, par défaut, 177 Properties (collection), rafraîchissement de, 180, 207 pour objets spécifiques, types de, 177 définies par l'utilisateur, 180 objets Container (DAO), objet Databses Qet), 196 objet Tables Qet), 197 objet Relations Qet), 197 objet Forms (Access), 197 objet Reports (Access), 197 objet Macros (Access), 197 objet Modules (Access), 197 objets Error, 192, 250 obtenir une base échantillon, OpenDatabase : méthode, 211 OpenRecordset : méthode, 226 opérateurs (VBA,) 155 opérateurs arithmétiques VBA, 155 opérateur bang (!), 175 opérateurs de comparaison (VBA),156 opérateur de concaténation (VBA),156 opérateur de concaténation (VBA), 156 opérateurs logiques (VBA), 156 opérateur dot (.), 175 optimisation: table, OPTION EXPLICIT: option (VBA), 150 ORDER BY: clause (instruction SE LECT), 110, 121 ordre des colonnes d'une table, 24 ordre des lignes d'une table, 24 ouverture de jeu d'enregistrements, ouvrir une bases de données, 211 P paramètres objets Parameter, 200, 253 requêtes paramétrées, 98, 130 PARAMETERS : instruction, 130 Parameters : collection, 200 PercentPosition : propriété, 231 persistence des données, 12 perte de données, 8 position/enregistrement courant dans un jeu, 228 première forme normale, 46 Private : mot-clé, 154 Primary : propriété, 216 problèmes des valeurs multiples, 6 produit de tables cartésien, propriété EOF, 229 propriétés définies par l'application, 186 propriétés objet, 173 procédures, 147 programmes: VBA, 147, 154, 278 projection, (Voir aussi instruction SELECT) propriétés, 171 de collections DAO, 171, 179 des champs, 212 des index, 216 de collections Access, 179 collection Properties, des objets Property, 253 des objets QueryDef, 221 référencer les, 169

292 Index 289 d'objets spécifiques, types de, 186 définies par l'utilisateur, 180, 189 (Voir aussi formes normales) propriétés natives, 186 propriétés écriture seule, 187 propriétés lecture seule, 187 propriétés lecture/ écriture, 187 Public : mot-clé, 154 Q QueryDef : objets, 195, création d'objets, quotients, 93 quotients de tables, R rafraîchissement de collections, 183, 207 recherche de jeu d'enregistrements, RecordsAffected : propriété, 222 Recordset : objets, 191, 195, , navigation dans, recherche dans, redondances, 3-6, références boiteuses, 31 References : collection, 173 Refresh : méthode, 179 Relation : objets, 258 requêtes make-table, 63, 97, 124 relations un-à-un, 19, 26-29, 29 relations plusieurs-à-plusieurs, 19, 29 Relations : collection, 197, Relations : conteneur, 197 relations entre entités, 18 implanter des, intégrité des (Voir intégrité réfé rentielle) types de, 19 Remove : méthode, 180 renommage d'attributs (de tables), 67 Replication Engine jet DBMS), 139 Reports : collection, 173, 179 Reports : conteneur, 197 requêtes, 62, 220 Access : conception de, 96 paramétrées, 98, 130 langages de, 62 sous-requêtes, 98, types de, 97 de mise à jour, 97, 106, 122 Requête : fenêtre, 67, 96 requête Append, 97 requête Action, 97, 220 requêtes croisées, 98, requête Crosstab, 98 requête Datadefinition, 98 requête Delete, 97 requête Make-Table, 97 requête Parameter, 98 requête Passthrough, 98 requête SQL, 97 requête Select, 97 requête Update, 97 Required : propriété, 213, 217 restrictions de tables (sélection), Right : function, 158 S sauvegarde de base de données, 276 structure logique d'une base de donnée 136 système de gestion de bases de donnée 1 schéma de table référencée, 28 NULL dans des clés et, 40 seconde forme normale, 49-50

293 Seek : méthode, 232 SELECT- INTO instruction, 124 SELECT : instruction, option DISTINCTROW, sous-requêtes, sélection, critères de, 77 requêtes select, 220 (Voir aussi instruction SELECT) Set : mot-clé (DAO), 164 snapshot : objets Recordset de type, 226, 234 SQL (Structured Query Language), 67, 99 DAO et, 134 (Voir aussi Access SQL) Str : fonction, 159 sous-requêtes, 98, sous-programmes, 147 schémas de tables, 22, 26 décomposition de, forme normales des, schémas secondaires (Voir vues) structure à trois niveaux, 137 suffixes: type-declaration (VBA), 152 superclés, 16, 25 dépendance fonctionnelle et, 49 suppression en cascade, 31 méthode Delete de, 179, 237 requêtes de (Delete), 97, 123 instruction DELETE de, 123 anomalies de, 7 d' enregistrements, 237 de colonnes de table, 105 de tables, 106 Systèmes de bases de données, Systèmes de gestion de bases de don nées, T TableDef : objets, 182, 195, 258 table : objets Recordset de type, 225, 232 tables, 22, 25 ALTER TABLE : instruction, 105 produit cartésien de, CREATE TABLE : instruction, création dans DAO de: degré de, 69 différence de, index de: insertion de données dans d'autres, 124 insertion de lignes, 124 intersection de, 71 jointures, 80-91, optimisation de, 93 projection de, 76 quotients de, sélection de sous-ensembles: semi-jointures de, suppression dans des, 106, 123 union de, 68-69, 98, 121 mise à jour de, 122 tables conteneur, 197 tables de bases de données, 63 tables résultat, 62 tables virtuelles, 63 tableaux (VBA), 152 taille (d'une table), 23 theta-jointures, 84, 89, 107 TOP : option (instruction SELECT), 110 TRANSFORM : instruction, troisième forme normale, trouver des enregistrements dans un jeu de type Table, 232 trouver des enregistrements dans un jeu de type Dynaset, 234

294 Index 291 types d'attributs, 44 de données objet, 164 de propriétés, 186 de requêtes, 97 de jeux d'enregistrements, 228 de librairies, 173 propriété, 187 suffixes type-declaration (VBA) 152 de variables (VBA): de données VBA, 150 U UCase : fonction, 158 union de tables, 68-70, 98, 121 union : requêtes, 98 UNION : instruction, 121 Unique : propriété, 217 Update : méthode, 236 UPDATE : instruction, 122 User : objets, 194, 260 lancement du programme échan tillon, 278 convention de nommage des varia bles, 153, 167 vues, 9, 136 vue conception de requêtes, 96 vue relations, 35 vue SQL, 96 Visual Basic for Applications (Voir VBA) w WHERE : clause SELECT (instruction), 109,119 UPDATE (instruction), 122 Workspace : collections, 170, 191, 193, 260 V Val : fonction, 159 ValidationRule : propriété, 213 ValidationText : propriété, 213 Value : propriété, 188 variables, nommage de, 153,167 objet, , 176 pointeur, 165 portée des, 154 tableau, 152 VBA (Visual Basic pour Applications), 133, 138, instructions de contrôle, opérateurs, 155 lancement de programmes, 154

295 A propos de l'auteur Steven Roman est professeur de mathématiques à l'université d'etat de Californie, à Fullerton. Il a enseigné dans un certain nombres d'autres universités, dont le MIT, l' Université de Californie à Santa Barbara et l'université de Floride du Sud. Le Dr. Roman est diplomé de l'université de Californie à Los Angeles et a passé son doctorat à l'université de Washington. Auteur de 28 livres, dont un certain nombre d' entre eux sur les mathématiques, tels que Coding and Information Theory, Advanced Linear Algebra et Field Theory, publiés par Springer Verlag, il a écrit également 15 petits opuscules intitulés Modules in Mathematics, à l'intention des étudiants des beauxarts de niveau universitaire. Le Dr. Roman a écrit deux autres livres d'informatique Concepts of Object-Oriented Programming with Visual Basic (Springer Verlag, éditeur), et Understanding Personal Computer Hardware, une étude en profondeur du fonctionnement du PC (non encore publié). Il travaille actuellement sur un ouvrage intitulé Visual Basic 5 and the Coponent Object Model Les sujets qui passionnent le Dr. Roman sont l'analyse combinatoire, l'algèbre et l'informatique. Colophon L'animal figurant sur la couverture de Bases de données MS Access Conception d~ Programmation est un tamanoir, l'une des trois espèces constituant la famille des fourmilliers. Edie Freedman a utilisé, pour réaliser la couverture de ce livre, une gravure ancienne du 19e siècle provenant du fonds de la Dover Pictorial Archive. La mise en page de la couverture a été réalisée à l'aide de Quark XPress 3.5. La mise en page du livre a été conçue par Edie Freedman, Nancy Priest et Hanna Dyer et a été implantée dans FrameMaker 5.0 par Mike Sierra. Le texte et les titres utilisent une police Garamond. Les illustrations apparaissant dans le livre ont été créées par Chris Reilley dans Macromedia Freehand 5.0. Les captures d'écran ont été effectuées dans la version MS Access de la suite Office 97. Ce colophon a été écrit par Clairemarie Fisher O'Leary.