Bases de données relationnelles avec Accesspasseport.univ-lille1.fr/site/initiatic/BASE_DE_DONNEES-_ACCESS/... · Système de Gestion de Bases de Données Relationnelles (SGBDR)

_________________________________________________________________________

Bases de données relationnelles

avec Access

Jean-Claude Armici

Ce document, ainsi que les fichiers qui lui sont associés, a été créé en 2000 à l'occasion d'un cours donné dans le cadre de l'ISPFP, c'est-à-dire en dehors de ma fonction d'enseignant au CEPTA

_____________________________________________________________________________ J-C Armici www.unvrai.com

1

Contenu Contenu...........................................................................................................................................2 1ère partie: cours d'introduction Introduction......................................................................................................................................5

Avertissements ............................................................................................................................5 Quelques mots sur Access ..........................................................................................................5 Mise en garde ..............................................................................................................................6 Informatique et bases de données ..............................................................................................6 Composants d'Access .................................................................................................................7

Bases de données...........................................................................................................................8 Qu'est-ce qu'une base de données ? ..........................................................................................8 Différence entre bases de données et systèmes de gestion de bases de données....................8 Système de Gestion de Bases de Données Relationnelles (SGBDR) ........................................8 Pourquoi s'intéresser au modèle relationnel ?.............................................................................8

Bases de données simples: basées sur une seule table ..............................................................10 Introduction ................................................................................................................................10

Tables ....................................................................................................................................10 Formulaires ............................................................................................................................10 Requêtes................................................................................................................................11 Etats .......................................................................................................................................11

Tables ........................................................................................................................................12 Lignes et colonnes .................................................................................................................12 Création d'une table ...............................................................................................................13 Choix des noms .....................................................................................................................13 Choix des types de données..................................................................................................14 Sous-types de données .........................................................................................................15 Remarques sur la création de tables .....................................................................................15 Quelques conseils pour la construction d'une table ...............................................................16

Formulaires................................................................................................................................17 Principe d'utilisation des formulaires ......................................................................................17

Requêtes ...................................................................................................................................20 Principe d'utilisation des requêtes..........................................................................................20 Requêtes, tables de résultats et tables de base ....................................................................21 Autres types de requêtes .......................................................................................................21

Etats...........................................................................................................................................23 Principe d'utilisation des états ................................................................................................23

Bases de données composées de plusieurs tables ......................................................................25 Introduction ................................................................................................................................25 Problèmes liés au travail avec une seule table..........................................................................27

Redondance...........................................................................................................................27 Problème des valeurs multiples .............................................................................................28 Problèmes de mises à jour.....................................................................................................29 Anomalies d'insertion .............................................................................................................29 Anomalies de suppression .....................................................................................................29 Conclusion .............................................................................................................................29

Difficultés liées aux bases de données relationnelles ...............................................................30 Eviter la perte d'informations..................................................................................................30 Maintenir l'intégrité relationnelle.............................................................................................30 Crée des vues ........................................................................................................................30 Résumé..................................................................................................................................30

Utilisation de plusieurs tables ....................................................................................................32


2

Stockage des informations ........................................................................................................33 A la recherche d'une méthode ...............................................................................................33 Identification des objets..........................................................................................................33

Relations entre objets du monde réel ........................................................................................34 Types de relations..................................................................................................................34 Relation un à plusieurs...........................................................................................................34 Relation un à un .....................................................................................................................34 Relation plusieurs à plusieurs ................................................................................................34 Aucune relation ......................................................................................................................35

Mise en place des relations .......................................................................................................36 Introduction ............................................................................................................................36 Clés primaires ........................................................................................................................37 Clés étrangères......................................................................................................................39 Relations proprement dites ....................................................................................................41 Chasse aux redondances ......................................................................................................45 Leçons à tirer .........................................................................................................................50

2ème partie: cours avancé

Synthèse....................................................................................................................................52 Introduction ............................................................................................................................52

Intégrité des données ................................................................................................................63 De quoi s'agit-il ?....................................................................................................................63 Problèmes liés à l'intégrité des données................................................................................63 A quel niveau placer les contrôles d'intégrité .........................................................................67

Construction d'une application base de données ......................................................................68 Compléments ................................................................................................................................77

Introduction ................................................................................................................................77 Notion de sauvegarde................................................................................................................77 Contrôle d'accès concurrents aux données...............................................................................77 Problèmes de langue.................................................................................................................79 Générateur d'expressions..........................................................................................................79 Création d'un menu général arborescent...................................................................................80 Champs de type OLE ................................................................................................................83 Et Internet, alors ? .....................................................................................................................86 Tables et autres objets importés................................................................................................89 Tables attachées .......................................................................................................................89 Séparation programme/données ...............................................................................................89 Formulaires indépendants des données....................................................................................90 Runtime Access.........................................................................................................................92 Recherche dans un formulaire...................................................................................................93 Un exemple de "OLE automation": pilotage d'Excel depuis Access..........................................94

Annexe A: PROGRAMMATION DESTRUCTIVE..........................................................................99 Introduction ................................................................................................................................99 L'enfer ........................................................................................................................................99 Le paradis ................................................................................................................................100 Les nuages ..............................................................................................................................103 Conclusion ...............................................................................................................................103


3

1ère partie

Cours d'introduction


4

Introduction

Avertissements Bien que les bases de données relationnelles soient un domaine qui prend ses racines dans les mathématiques (théorie des ensembles, algèbre de Boole, ...), ce cours est en grande partie axé sur la pratique. Certains concepts théoriques pour la compréhension desquels beaucoup plus de temps serait nécessaire sont volontairement laissés pour une autre occasion. Une bonne approche pratique accompagnée de quelques compléments indispensables permet d'aborder les bases de données de manière tout à fait satisfaisante. En effet, une fois quelques notions de base acquises, le bon sens est un bon guide.

Quelques mots sur Access Le logiciel de référence pour ce cours est Access de Microsoft, et plus précisément Access97. Toutefois, les notions abordées sont également valables pour Access 2000. Il est bien entendu que les aspects théoriques des bases de données relationnelles restent également valables pour les autres systèmes de gestion de bases de données. Voici quelques points caractérisant Access:

• Puissant

• relativement répandu dans de grandes sociétés

• Beaucoup utilisé pour les bases de données sur Internet

• Universel

• Mise en œuvre de bases de données

• Utilisation facultative de la programmation

• Possibilités graphiques

• "Fourre tout", logiciel à tout faire

• Outil de développement professionnel

• Accessible

• Assistants et compléments divers pour les personnes inexpérimentées

• Démocratique

• On peut l'utiliser en quelques minutes ("débutants")

• On commence à le connaître en quelques mois ("utilisateurs avertis")

• On croit le maîtriser en quelques années ("développeurs")


5

• Intégré (à Office)

• Liens prévus avec ses frères (Word, Excel, Outlook…), et avec Internet

• Cachottier

• On peut l'utiliser sans rien connaître aux bases de données ni à la programmation Bref historique:

• Fin 1992: annonce discrète par Microsoft

• Microsoft prévoit d'en vendre quelques milliers, mais en vend des millions

• Versions: 1.0, 1.1, 2.0, 7.0 (Access 95), 8.0 (Access 97), 9.0 (Access 2000)

• Le run-time permet de distribuer les applications

• Introduction de ODBC avec Access en 1992:

• Standard d'accès (par drivers) aux bases de données

• Technique de plus en plus utilisée Avec bientôt une dizaine d'années de recul, on peut dire qu'Access n'est pas un phénomène de mode, mais plutôt la réponse au besoin de combler une lacune dans les outils de développement liés aux bases de données.

Mise en garde Il est important de garder à l'esprit qu'une personne maîtrisant parfaitement Access n'est pas forcément et automatiquement un professionnel des bases de données. Access n'est qu'un logiciel parmi beaucoup d'autres. Il est très répandu, il a permis au plus grand nombre d'accéder sans trop de difficultés au monde des bases de données, mais pour des développements importants et complexes il ne peut pas rivaliser avec les géants que sont Oracle, Sybase, SQL Serveur et autres. Dans cette comparaison, les points faibles d'Access sont, entre autres, la limitation de la taille des bases de données, la dégradation des performances lorsque le nombre d'utilisateurs simultanés augmente, le manque relatif de sécurité tant au niveau des utilisateurs que des données. De plus, Access seul n'est pas à proprement parler un système client-serveur, bien qu'il soit possible de travailler en client-serveur avec Access comme application frontale gérant, par exemple, une base de données SQL Serveur.

Informatique et bases de données Le domaine des bases de données est certainement le domaine informatique qui a le moins évolué. C'est un des plus anciens (fin du 19ème siècle), mais très peu de changements sont intervenus depuis. Le plus important étant l'apparition des bases de données relationnelles; le prochain sera probablement l'avènement des bases de données "objet". Même derrière des apparences modernes, des géants comme SQL Serveur laissent entrevoir leur origine ancienne. Dans les dernières versions de SQL Serveur certaines commandes existaient uniquement sous forme cryptique nécessitant forcément un apprentissage de leur syntaxe. Ceci peut sembler paradoxal pour un éditeur qui se veut le champion de l'ergonomie et


6

de l'interface graphique. Ces logiciels sont de monstrueux robots que l'on rend sexy avec des habits de fête.

Composants d'Access Comme nous le verrons Access est constitué de plusieurs "composants". Afin de mieux comprendre leur importance relative, en voici une brève description, avec en note le degré de difficulté pour les maîtriser. Tables:

• Stockage des données C'est ici qu'intervient l'expérience (le "métier") • Définition des relations

Requêtes:

• Extraction des données • Questionnement de la base de données

Formulaires:

• Présentation des données à l'utilisateur (adjonctions, modifications, suppressions, consultations)

Sur la base d'un ensemble de données (1 table, plusieurs tables, requêtes…). Demande un peu d'expérience

Essentiellement esthétique, plus quelques "trucs"

Etats: Esthétique, plus quelques "trucs"

• Analogues aux formulaires, mais destinés à être imprimés • Consultation seulement

Macros:

• "code simplifié" • intermédiaire entre l'interface utilisateur graphique et la programmation

Modules:

• programmation proprement dite Tout au long de l'apprentissage d'Access nous serons concernés par ces six "composants". Bien qu'abordables de manière indépendante, l'ordre dans lequel ils sont présentés est l'ordre logique de leur intervention dans la construction d'une base de données. Parmi ces composants, les tables sont les constituants de base. Et mettre en place une base de données correctement structurée en différentes tables est certainement l'obstacle le plus difficile à surmonter dans l'apprentissage des bases de données. Il repose beaucoup sur l'expérience et, de ce fait, est très peu compressible: l'expérience ne peut pas se résumer. Quelle que soit la méthode utilisée pour approcher les bases de données, l'expérience, donc le temps, est un paramètre essentiel. On ne devient pas facilement spécialiste en bases de données. Certains exemples bien choisis, certains trucs et certains concepts théoriques peuvent accélérer la compréhension. C'est un des buts de ce cours.


7

Bases de données

Qu'est-ce qu'une base de données ? Une base de données est une collection d'informations, informatisée ou non. Pratiquement la seule différence apportée par les ordinateurs est que l'accès aux données se fait de manière très rapide. Une seconde différence découlant en partie de la première est la possibilité d'"interroger" les données de façon complexe, beaucoup trop complexe pour un traitement non informatisé. Exemple d'interrogation complexe: "Quels sont les noms et adresses des femmes de plus de 50 ans en traitement dans un hôpital du pays, ayant des antécédents diabétiques dans leur famille, et ayant plus de deux enfants ?" En fait, actuellement les bases de données sont partout.

Différence entre bases de données et systèmes de gestion de bases de données

Une base de données est un regroupement de données. Mais sans un logiciel adéquat (SGBD, Système de gestion de base de données) il est impossible d'avoir un contrôle sur ces données. Un SGBD est à une base de données ce qu'un traitement de texte est à une lettre.

Système de Gestion de Bases de Données Relationnelles (SGBDR) Parmi les différentes manières de traiter ou de modéliser des données, le modèle relationnel est certainement le plus répandu. Le père des bases de données relationnelles est E. Codd. C'était un théoricien, dont les écrits sont parfois difficiles à suivre. Heureusement d'autres personnes ont vulgarisé le sujet et en ont permis une plus grande compréhension. Le modèle relationnel, bien qu'essentiellement basé sur les mathématiques et la logique, est relativement facile à comprendre, même en abordant les SGBDR par le côté pratique. Cette compréhension peut se faire sans référence au jargon spécifique et hermétique de Codd.

Pourquoi s'intéresser au modèle relationnel ? Il y a 10 à 15 ans la mise en œuvre d'une base de données n'était pas une tâche triviale, et seuls des spécialistes en bases de données pouvaient s'y atteler. Les SGBDR de l'époque étaient tout sauf conviviaux. Avec l'arrivée d'outils modernes comme Access, la possibilité de construire une base de données et de la gérer était à la portée de n'importe qui. Les avantages sont:

• Ouverture du monde des bases de données au plus grand nombre, ou du moins possibilité de découvrir les bases de données

• Possibilité de faire appel à une base de données pour stocker des données même très simples (par exemple une liste de clients)

• Faciliter le développement d'applications bases de données


8

Un inconvénient, inhérent à l'apparition d'outils facilitant le développement en général, est la pagaille pouvant résulter d'une utilisation superficielle et non organisée de ce genre d'outils. On peut donc vraiment parler de démocratisation des bases de données relationnelles. Les outils sont là et le passage de "professionnels des bases de données" à "gens normaux" est bénéfique.


9

Bases de données simples: basées sur une seule table

Introduction Pour bien comprendre en quoi consistent les quatre éléments fondamentaux que sont les:

• tables,

• formulaires,

• requêtes

• états, focalisons-nous sur le cas où les données sont organisées en une seule table. Tables Une table est la structure fondamentale dans laquelle sont stockées les informations d'une base de données. Une table peut contenir, par exemple, des articles de stock.

BA

SE

0.M

DB

No. article Désignation Quantité Prix Date dernière commande 10560 Chapeau à deux places 4 SFr. 44.25 01.08.9810700 Short à col roulé 8 SFr. 56.00 01.09.9810800 Chaussettes à cloux 12 SFr. 4.50 01.09.9812000 Souliers verts 2 SFr. 45.00 12.04.9812000A Souliers gris 126 SFr. 25.50 04.05.57

Fig. 1

Formulaires Un formulaire est une fenêtre permettant à l'utilisateur d'un SGBDR d'effectuer les opérations courantes sur les données:

• Visualisation

• Adjonction

• Modification

• Recherche

• Suppression On peut effectuer ces opérations directement sur une table, mais pour diverses raisons on ne le fait généralement pas. Une des raisons est qu'un formulaire peut présenter les données sous une forme plus agréable et conviviale. Une autre raison est qu'un formulaire peut regrouper des données de plusieurs tables.


10

BA

SE

1.M

DB

Fig. 2

Requêtes Une requête permet de questionner une base de données (en fait une ou plusieurs tables) afin d'obtenir un résultat en fonction de critères donnés.

B

AS

E1.

MD

B

Fig. 3

Etats Un état est un document destiné généralement à être imprimé, permettant de mettre en forme (en page) des données. Cet élément ne doit pas être négligé, car finalement c'est le produit visible d'un SGBDR (factures, relevés de comptes, etc)


11

BA

SE

1.M

DB

Fig. 4

Tables Comme nous l'avons vu, la table est le conteneur des données d'une base de données. Le nom "table" vient de l'aspect tabulaire de la représentation des données:

STOCK ArtNo ArtDesign ArtQte ArtPU ArtDernCom

10560 Chapeau à deux places 4 SFr. 44.25 01.08.9810700 Short à col roulé 8 SFr. 56.00 01.09.9810800 Chaussettes à clous 12 SFr. 4.50 01.09.9812000 Souliers verts 2 SFr. 45.00 12.04.9812000A Souliers gris 126 SFr. 25.50 04.05.57

Fig. 5 Une première constatation est qu'une table contient des éléments de même nature; on ne mélangera pas des articles scientifiques, des meubles et des sujets de dissertation. Lignes et colonnes Comme on peut le voir sur l'exemple, chaque ligne contient les informations concernant un article du stock. Plutôt que de "lignes" on parle souvent d'"enregistrements". Les deux termes sont quasiment synonymes, si ce n'est qu'une ligne se réfère à la table, alors qu'un enregistrement se réfère aux données. Le nombre d'enregistrements d'une table peut être considéré comme illimité, bien que des limites existent et dépendent du logiciel utilisé. Généralement on peut stocker au moins plusieurs milliards d'enregistrements dans une table. Les colonnes d'une table sont également appelées "champs". Leur nombre est généralement limité à des valeurs de l'ordre de 255. Il est clair que chaque colonne doit avoir un nom (nom de champ) et que ce nom doit être unique.


12

En général le nom de la table ainsi que les noms de ses champs donnent une indication sur la nature des données qu'elle contient ainsi que sur son utilisation. Création d'une table Les SGBDR et Access en particulier permettent de construire une table en partant de zéro.

BA

SE

1.M

DB

Fig. 6

Bien que les SGBDR permettent de modifier la structure d'une table (même peuplée de données), après avoir acquis une certaine expérience et surtout après avoir fait une analyse correcte du problème à traiter, il est très rare d'apporter des modifications à la structure d'une table. Signalons enfin qu'en mode création de table on peut définir pour chaque champ une Légende (voir figure 6). Il s'agit d'un nom qui apparaîtra en entête de colonne pour le champ donné, en lieu et place du nom du champ. On préférera, par exemple, spécifier la légende "Désignation" plutôt que le nom "ArtDesign". Choix des noms Le choix des noms des divers objets d'un SGBDR est soumis à des règles objectives et à des règles subjectives. Les règles subjectives relèvent des habitudes ou de l'ergonomie. Ainsi, il n'est pas rare de voir des noms de tables écrits en majuscules et formés d'un seul mot. Les règles objectives dépendent des logiciels utilisés, et interdisent parfois l'utilisation de caractères "spéciaux" (par exemple les lettres accentuées), ou de noms formés de plusieurs mots.


13

Voici quelques conseils pour le choix du nom des champs:

• Eviter des noms trop courts et cryptiques (p.ex. CLI#, FTOT)

• Bien qu'Access le permette, éviter des noms trop longs et avec des espaces ou des caractères accentués (p.ex. Numéro de client, Maîtrise de classe demandée)

• Choisir des noms compacts, significatifs, non-équivoques, de moins de 15 à 20 caractères

• Une bonne habitude consiste à utiliser l'écriture "CamelCaps", en préfixant le nom du champ comme par exemple ArtQte. Ceci donne une indication sur la nature des données (Articles) et sur le nom du champ (Quantité)

Choix des types de données En plus du choix des noms des champs, la création d'une table nécessite également le choix des types de données. Les principaux types utilisables avec Access sont les suivants:

Texte textes courts (maximum 255 caractères). Tous les caractères sont utilisables.

Mémo textes longs

Numérique nombres uniquement

Date/Heure dates, heures ou les deux à la fois

Monétaire nombres accompagnés d'un symbole monétaire, avec 4 décimales au maximum, servant au stockage de montants monétaires

NuméroAuto nombre automatiquement incrémenté par Access à chaque nouvel enregistrement

Oui/Non valeurs booléennes de type Vrai/Faux, Oui/Non ou Actif/Inactif

Objet OLE objets tels que feuilles de calcul (tableur), document (traitement de texte), séquences vidéo, images, etc

On pourrait imaginer un SGBDR dans lequel tous les champs seraient du même type, par exemple texte. Toutefois le choix de type de données présente plusieurs avantages:

• Exclusion de certaines erreurs de saisie (par exemple des lettres dans un champ décrivant un prix)

• Optimisation de l'espace occupé par les données

• Certaines opérations sont spécifiques à des types de champs En général le choix d'un type de données pour un champ s'impose de lui-même, mais parfois certains types sont plus appropriés que d'autres.

• Dans notre exemple la date de la dernière commande aurait pu être de type texte. Tout fonctionnerait correctement jusqu'au moment où l'on veut effectuer des calculs avec le contenu du champ. Imaginons que l'on veut connaître le nombre de jours écoulés depuis la dernière commande.


14

• Dans d'autres circonstances on serait peut-être tenté de stocker un numéro de téléphone sous forme numérique. Ceci peut conduire à des problèmes: certains numéros peuvent comporter plus de chiffres que ne l'autorise le type numérique utilisé, de plus, on saisit souvent les numéros de téléphone avec des espaces ou des parenthèses. Un type texte de longueur 16 ou 20 serait plus adéquat.

• De même on stockera un numéro postal dans un champ de type texte plutôt que numérique, car ce champ peut contenir des lettres.

Sous-types de données Une des préoccupations des SGBDR est de coller le plus près possible à la réalité. Aussi bien pour optimiser l'espace occupé par les données, que pour affiner la diversité des types de base, Access dispose de sous-types. Les plus utilisés concernent le type Numérique et Date/Heure. A titre d'exemple, voici les sous-type numériques:

Octet nombres entiers entre 0 et 255 (1 octet)

Entier nombres entiers entre –32'768 et 32'767 (2 cotets)

Entier Long nombres entiers entre –2'147'483'648 et 2'147'483'647 (4 octets)

Réel simple nombres à virgule avec précision de 6 chiffres (4 octets)

Réel double nombres à virgule avec précision de 10 chiffres (8 octets) Remarques sur la création de tables Dans le domaine des bases de données plus que dans tout autre domaine du développement informatique il est vital de s'attarder le temps qu'il faudra sur l'analyse du problème à résoudre et sur la structure de la base de données. En effet, la mise en œuvre d'une base de données, et à fortiori d'une application bases de données, implique deux étapes:

• La mise en place de la structure de la base de données

• L'implémentation de celle-ci La première étape peut et devrait se faire sans ordinateur, alors que la seconde implique l'utilisation d'un SGBDR. Contrairement à ce que l'on pourrait penser, la première est de loin la plus difficile à mener à bien. Au vu de notre exemple de table, cela peut sembler paradoxal, mais n'oublions pas qu'une base de données n'est presque jamais réduite à une seule table. Et nous verrons plus loin qu'une des difficultés réside dans le fractionnement adéquat des données en plusieurs tables ainsi que dans les relations à établir entre ces tables.


15

Quelques conseils pour la construction d'une table Pour guider le choix de la structure d'une table, il est utile de se poser la question:

Quelle(s) information(s) est-ce que je veux extraire de la table ? Plutôt que la question:

Quelle(s) information(s) est-ce que je veux mettre dans la table ?

Imaginons la création d'une table de personnalités influentes dont les adresses seront utilisées pour envoyer du courrier par e-mails.

• Certaines personnes sont susceptibles à propos de leur titre (Prof, Dr., etc); il serait donc utile de prévoir un champ correspondant.

• Le courrier peut être différent en fonction du revenu. Donc prévoir un champ Revenu.

• Afin d'insérer une référence explicite au conjoint, il serait utile d'avoir un champ PrénomDuConjoint.

Un défaut souvent rencontré dans les bases de données est d'avoir des champs inutilisés dans certaines tables. Parfois la raison en est uniquement que le contenu de ce champ existait déjà sous forme informatique, et donc, pourquoi ne pas l'inclure. Certains SGBDR et Access en particulier permettent de spécifier des contrôles de saisie de données au niveau des champs, au moment de la création des tables. Comme on peut le voir sur la figure 6, certaines propriétés pour chaque type de champ peuvent être utilisées dans ce but. Voici celles concernant le type Texte:

• Masque de saisie

• Valeur par défaut

• Valide si

• Message si erreur D'autres types de champs peuvent avoir des propriétés différentes. Un autre conseil concerne la séparation des entités logiques (noms, adresses…)

• Eviter de stocker dans un champ Nom des informations telles que Prof. Jean Bichon

• Séparer plutôt un nom en Titre (Prof.), Prenom (Jean), Nom (Bichon). De cette manière il est, par exemple, plus facile de faire une liste de tous les Prof. Ou encore de trier une liste de personnes alphabétiquement selon le nom

• Si on suppose qu'une information pourra être manipulée selon une de ses subdivisions possibles, alors il convient de faire la séparation

• Une telle subdivision est également à envisager pour les adresses (séparation des champs Société, Rue, Code postal, Localité, Pays…)


16

Un dernier conseil consiste à supprimer les informations redondantes:

• Lorsqu'un champ pourrait être déduit ou calculé en fonction d'autres champs, il est inutile de l'inclure dans une table. Ainsi, dans une table Factures, il suffit de faire figurer les champs Nombre d'Articles et Prix Article. Le champ Prix total est inutile, car il se calcule par Nombre d'Articles * Prix Article.

• La suppression des redondances permet non seulement un gain de place, mais évite des problèmes de mise à jour des informations

Enfin, bien qu'Access autorise pour la plupart des objets (tables, requêtes, noms de champs, etc) des noms pouvant contenir des caractères accentués et des espaces, ainsi que des noms comportant jusqu'à 64 caractères, il est préférable de rester modeste, ou plutôt rétrograde. Un retour en arrière de 20 ans est de rigueur (ce qui est déplorable) si l'on pense un jour ou l'autre "porter" une base de données Access vers un autre système, Oracle, SQLserver, etc. Ces logiciels étant beaucoup plus restrictifs, il convient de s'en tenir au dénominateur commun pour éviter les problèmes.

Formulaires Principe d'utilisation des formulaires Une table représente une visualisation des données parmi d'autres. Il est possible de gérer les données directement depuis une table. Mais dans la pratique la manipulation des données se fait depuis des formulaires. Un formulaire peut être considéré comme un écran de visualisation ou un filtre placé entre les informations et l'utilisateur de la base de données. Parmi les avantages de l'utilisation des formulaires, le fait de pouvoir travailler sur un seul enregistrement à la fois peut être préférable pour la plupart des gens. Voici un exemple de formulaire agissant sur les mêmes enregistrements que notre table STOCK. Ce formulaire a été généré à l'aide de l'assistant d'Access, mais il aurait aussi pu être construit de toutes pièces.

BA

SE

1.M

DB

Fig.7

Le formulaire de la figure 7 est en mode "utilisation".


17

Voici comment il se présente en mode "construction":

BA

SE

1.M

DB

Fig. 8

Sur la figure 9 on peut voir le même formulaire que sur la figure 7, mais remanié à la main pour ce qui est de son apparence. On peut remarquer que bon nombre de petits détails ont changé. Il est évident que les assistants de création de toutes sortes mis à disposition par Access peuvent rendre de grands services. Mais il est tout aussi évident que l'intervention du développeur, alliée à un brin d'originalité et/ou d'esthétique font souvent une grande différence.

BA

SE

1.M

DB

Fig. 9

On pourrait créer d'innombrables formulaires basés sur la table STOCK, tous différents. On comprend donc bien que le formulaire n'est qu'une interface entre les données de base et l'utilisateur. Si la fantaisie ou l'ergonomie n'ont aucune place dans la structuration des données en tables, elles en ont une dans l'interface utilisateur. Chaque objet (bouton, zone de texte, libellé, etc) d'un formulaire possède des propriétés qu'il est possible de modifier en mode "création", mais également en mode "utilisation" en faisant appel à la programmation. Chaque objet a également la possibilité de répondre à des événements tels que le clic de la souris, la réception ou la perte du focus, la validation, etc. Ceci dans le but d'accroître l'interaction avec l'utilisateur et de mieux s'adapter aux diverses situations qui peuvent se présenter.


18

Voici encore quelques possibilités offertes par les formulaires:

• Spécifier que certains champs sont en lecture seule

• Ne pas faire apparaître dans un formulaire tous les champs de la table correspondante

• Regrouper deux ou plusieurs champs d'une table sous forme d'un seul champ dans le formulaire

• Ajouter des "champs" sur le formulaire qui n'existent pas dans la table. On parle de champs indépendants, qui peuvent aider à la visualisation ou à la manipulation des données. On pourrait, sur notre formulaire de la figure 9 ajouter une zone de texte indiquant le nombre de jours écoulés depuis la dernière commande. Cette information n'est pas directement contenue dans la table STOCK, mais peut être aisément calculée en fonction de la date de la dernière commande.

• Mettre en place des mesures de sécurité interdisant à l'utilisateur l'accès direct aux tables et/ou spécifier des droits d'accès à des utilisateurs ou à des groupes d'utilisateurs. Telle personne pourra modifier l'aspect d'un formulaire, alors que telle autre personne pourra uniquement utiliser le formulaire et, par exemple seulement pour ajouter des enregistrements, mais pas pour les supprimer ou les modifier.


19

Requêtes Principe d'utilisation des requêtes Généralement les requêtes permettent de trouver des sous-ensembles de données ou d'effectuer des opérations sur des données (tri, comptage, regroupement, etc). Une requête est souvent synonyme d'interrogation d'une base de données. Lorsqu'une base de données est constituée son utilisation repose essentiellement sur des requêtes. Reprenons notre table STOCK:

ArtNo ArtDesign ArtQte ArtPU ArtDernCom 10560 Chapeau à deux places 4 SFr. 44.25 01.08.9810700 Short à col roulé 8 SFr. 56.00 01.09.9810800 Chaussettes à clous 12 SFr. 4.50 01.09.9812000 Souliers verts 2 SFr. 45.00 12.04.9812000A Souliers gris 126 SFr. 25.50 04.05.57

Fig. 10 Une requête peut effectuer une extraction par champ. Exemple: "articles avec numéro, désignation et quantité en stock"

BA

SE

2.M

DB

ArtNo ArtDesign ArtQte 10560 Chapeau à deux places 4 10700 Short à col roulé 8 10800 Chaussettes à clous 12 12000 Souliers verts 2 12000A Souliers gris 126

Fig.17

Elle peut effectuer une extraction par enregistrement.

BA

SE

2.M

DB

Exemple: "les deux articles les plus chers"

ArtNo ArtDesign ArtQte ArtPU ArtDernCom 10700 Short à col roulé 8 SFr. 56.00 01.09.9812000 Souliers verts 2 SFr. 45.00 12.04.98

Fig. 12 Elle peut effectuer une extraction par champ et par enregistrement.

BA

SE

2.M

DB

Exemple: "liste des chaussures (désignation et prix)"

ArtDesign ArtPU Souliers verts SFr. 45.00 Souliers gris SFr. 25.50

Fig. 13


20

Les résultats des requêtes des figures 11 à 13 peuvent paraître triviaux, mais il faut garder à l'esprit qu'une requête doit fonctionner de manière analogue avec une table de plusieurs millions d'enregistrements, ce qui est fréquemment le cas. Requêtes, tables de résultats et tables de base Il est important de ne pas confondre une requête et les résultats qu'elle produit. Une requête est simplement une question qui peut être exprimée de plusieurs manières:

• En français

• Sous forme graphique (comme le propose le mode "construction" d'Access)

• Dans un langage informatique normalisé SQL (que nous aborderons plus loin) Le résultat d'une requête est un ensemble de données qui se présente comme une table, avec des lignes et des colonnes. Il est d'ailleurs utilisable comme une table. On l'appelle parfois table de résultats ou table de réponse. Par opposition on appelle les vraies tables tables de base. Nous verrons plus loin qu'une requête peut mettre en jeu plusieurs tables. On comprendra mieux alors un principe fondamental de la théorie des bases de données relationnelles: le résultat d'une requête peut être considéré comme une table et utilisé en tant que tel. Nous avons vu qu'il est possible de modifier les données d'une table, mais qu'en est-il d'une table de résultats d'une requête ? On s'attend à ce que les modifications apportées à une table de résultats comme celles des figures 11 à 13 soient reportées dans la table sous-jacente. La réponse est oui dans la plupart de cas. En fait deux raisons peuvent s'opposer à la modification des données de tables de résultats. La première est que certains SGBDR n'implémentent pas cette possibilité (ce n'est pas le cas d'Access). La seconde est plus compréhensible lorsqu'une requête met en jeu plus d'une table (voir plus loin): il n'est pas possible de modifier les données d'une table de résultats si l'intégrité des données n'est pas préservée. Au cours du temps, les résultats d'une requête évoluent en fonction de l'évolution des tables sous-jacentes. Dans les applications bases de données il est fréquent d'utiliser la même requête plusieurs fois ou à intervalles réguliers; par exemple une requête effectuant la clôture de caisse en fin de journée. Une autre utilité des requêtes est de pouvoir faire une image de l'état d'une ou plusieurs tables à un instant donné. Pour cela il suffit de stocker la table de résultats d'une requête sous forme d'une table au vrai sens du terme. Autres types de requêtes Les requêtes permettant d'interroger une base de données sont aussi appelées requêtes de sélection. Access permet de construire et de travailler avec d'autres types de requêtes:

• Les requêtes de mise à jour permettant de modifier le contenu d'un ou plusieurs champs dans une ou plusieurs tables

• Les requêtes d'ajout permettant d'ajouter des enregistrements à une table, en appliquant éventuellement des critères


21

• Les requêtes de suppression permettant de supprimer des enregistrements d'une table, en appliquant éventuellement des critères

• Les requêtes de création de table permettant de créer une nouvelle table à partir des résultats d'une requête

• Les requêtes d'analyse croisée permettant d'effectuer des regroupements (en ligne et/ou en colonne) ainsi que des calculs (comptage, moyenne, etc)

Un des points forts d'Access est de pouvoir spécifier et construire les requêtes de manière graphique et visuelle. Cette méthode a l'avantage d'éviter l'apprentissage du langage SQL (Structured Query Language). De plus, lorsqu'Access construit graphiquement une requête, il maintient à jour l'équivalent exprimé en SQL. Cette particularité permet de se familiariser petit à petit avec le langage SQL. Le langage SQL s'exprime sous forme de texte ressemblant à du langage naturel (anglais). Nous reviendrons plus loin sur le langage SQL, mais voici un exemple permettant d'en avoir un avant-goût. La figure 14 montre sous forme graphique une requête permettant de sélectionner les articles coûtant moins de 45 Frs:

BA

SE

2.M

DB

fig. 14

Voici la même requête exprimée sous forme SQL:

SELECT ArtNo, ArtDesign, ArtPU FROM STOCK WHERE (STOCK.ArtPU<45) Même en n'ayant jamais entendu parler de SQL on établit facilement la correspondance entre les éléments de la figure 14 et la commande ci-dessus.


22

Etats Principe d'utilisation des états Les états sont le plus souvent utilisés dans les buts suivants:

• Obtenir une vision résumée de certaines informations, éventuellement ordonnées en groupes et sous-groupes

• Présenter des documents sous une forme esthétiquement irréprochable (factures, catalogues, questionnaires, etc)

• Obtenir une (pré)visualisation à l'écran permettant une analyse plus fine qu'avec un formulaire.

Il est relativement rare de rencontrer des états faisant intervenir une seule table, c'est pourquoi une présentation plus détaillée se trouve plus loin dans ce cours. Pour en savoir néanmoins en peu plus sur les états, voici un exemple basé sur notre table STOCK: il s'agit d'une liste d'articles fictive. La figure 15 montre l'état en mode construction.

BA

SE

2.M

DB

fig. 15


23

La figure 16 montre le résultat obtenu

BA

SE

2.M

DB

fig. 16


24

Bases de données composées de plusieurs tables

Introduction

La plupart des bases de données sont constituées de plusieurs tables. Le partage des informations en différentes tables ne s'effectue pas de manière arbitraire, mais au contraire de manière très stricte et réfléchie. Pour mieux le comprendre nous allons prendre comme exemple une bibliothèque contenant 14 livres. Il est évident que tout ce que nous étudierons ici reste valable même dans le cas où le nombre de livres est de quelques milliers ou dizaines de milliers.

Il convient également de préciser que cette base de données est fictive; il manque beaucoup de renseignements.

Le tableau suivant décrit ces 14 livres sous forme d'un tableau:

ISBN Titre AutNo AutNom AutTel EditNo EditNom EditTel Prix 1-1111-1111-1 Delphi 4 Chirac 444-444-4444 1 Micro Applications 123-456-7890 29.95 0-99-999999-9 Rambo 8 1 Knuth 111-111-1111 1 Micro Applications 123-456-7890 20.00 0-91-335678-7 Astérix 7 Mao 777-777-7777 1 Micro Applications 123-456-7890 15.00 0-91-045678-5 Windows 5 Galdo S. 555-555-5555 2 MS Press 999-999-9999 20.00 0-103-45678-9 Intelligence 3 Gainsbourg 333-333-3333 1 Micro Applications 123-456-7890 25.00 0-12-345678-6 CDROM 1 Knuth 111-111-1111 3 Sybex 714-000-0000 49.00 0-99-777777-7 Roi Lear 5 Galdo S. 555-555-5555 2 MS Press 999-999-9999 49.00 0-555-55555-9 La sieste 5 Galdo S. 555-555-5555 2 MS Press 999-999-9999 12.00 0-11-345678-9 Moby Dick 2 Gates 222-222-2222 3 Sybex 714-000-0000 49.00 0-12-333433-3 La liberté 8 PPDA 888-888-8888 1 Micro Applications 123-456-7890 25.00 0-321-32132-1 Natation 13 Newton 321-321-1111 3 Sybex 714-000-0000 34.00 0-321-32132-1 Natation 11 Jensen 321-321-2222 3 Sybex 714-000-0000 34.00 0-321-32132-1 Natation 12 Einstein 321-321-0000 3 Sybex 714-000-0000 34.00 0-55-123456-9 La cuisine 10 Wirth 123-333-3333 3 Sybex 714-000-0000 22.95 0-55-123456-9 La cuisine 9 Malraux 123-222-2222 3 Sybex 714-000-0000 22.95 0-123-45678-0 Ulysse 6 Nixon 666-666-6666 2 MS Press 999-999-9999 34.00 1-22-233700-0 Visual Basic 4 Chirac 444-444-4444 1 Micro Applications 123-456-7890 25.00

Fig 17

Il est utile de prendre conscience que les livres sont bien au nombre de 14. En effet, un livre peut être écrit par plusieurs auteurs et un auteur peut avoir écrit plusieurs livres.

Ce tableau a été créé à l'aide Microsoft Word. Pour une simple base de données telle que celle-ci, Word offre toutes les possibilités de gérer les informations:

• Ajouter un livre

• Supprimer un livre

• Modifier des informations quelconques du tableau

• Effectuer un tri d'après une colonne

• Extraire certains livres du tableau

• Extraire uniquement certaines colonnes (par exemple: ISBN, Titre et Prix)

Pourquoi y aurait-il besoin d'un système sophistiqué de gestion de base de données pour gérer une telle table ? La connaissance de la théorie des bases de données et l'utilisation du modèle de bases de données relationnelles devient indispensable lorsque:

• La complexité

• et la taille

de la base de données augmentent. _____________________________________________________________________________

J-C Armici www.unvrai.com 25

Il suffit de penser à d'immenses bibliothèques telle que la Bibliothèque du Congrès au Etats-Unis (16 millions de livres) pour se convaincre qu'il n'est pas possible de la gérer avec un seul tableau dans Word.

Voyons maintenant quelques problèmes auxquels on doit faire face dans la gestion d'une base de données qui serait mal construite et mal organisée:


26

Problèmes liés au travail avec une seule table Redondance En observant la figure 17 on peut voir qu'une même information apparaît plusieurs fois. Par exemple le numéro de téléphone de l'éditeur Sybex apparaît 6 fois.

Dans certains rares cas la répétition peut se justifier, mais en général on essaie de supprimer le plus possible les redondances. Ceci peut être obtenu en fractionnant les données originales en plusieurs tables. Dans notre cas nous avons 4 tables, dont voici les 3 premières:

• La table LIVRES

• La table AUTEURS

• La table EDITEURS

Les voici telles qu'elles ont été créées dans Access:

LIVRES ISBN Titre EditNo Prix

0-103-45678-9 Intelligence 1 25.00 Frs 0-11-345678-9 Moby Dick 3 49.00 Frs 0-12-333433-3 La liberté 1 25.00 Frs 0-12-345678-9 CDROM 3 49.00 Frs 0-123-45678-0 Ulysse 2 34.00 Frs 0-321-32132-1 Natation 3 34.00 Frs 0-55-123456-9 La cuisine 3 22.95 Frs 0-555-55555-9 La sieste 2 12.00 Frs 0-91-045678-5 Windows 2 20.00 Frs 0-91-335678-7 Astérix 1 15.00 Frs 0-99-777777-7 Roi Lear 2 49.00 Frs 0-99-999999-9 Rambo 8 1 20.00 Frs 1-1111-1111-1 Delphi 1 29.95 Frs 1-22-233700-0 Visual Basic 1 25.00 Frs

AUTEURS

BA

SE

3.M

DB

AutNo AutNom AutTel 1 Knuth 111-111-1111 10 Wirth 123-333-3333 11 Jensen 321-321-2222 12 Einstein 321-321-0000 13 Newton 321-321-1111 2 Gates 222-222-2222 3 Gainsbourg 333-333-3333 4 Chirac 444-444-4444 5 Galdo S. 555-555-5555 6 Nixon 666-666-6666 7 Mao 777-777-7777 8 PPDA 888-888-8888 9 Malraux 123-222-2222

EDITEURS EditNo EditNom EditTel

1 Micro Applications 123-456-7890 2 MS Press 999-999-9999 3 Sybex 714-000-0000

Fig. 18


27

La quatrième table contient des informations concernant les livres et les auteurs. Son utilité sera expliquée plus loin:

LIVRE/AUTEUR

BA

SE

3.M

DB

ISBN AutNo 0-103-45678-9 3 0-11-345678-9 2 0-12-333433-3 8 0-12-345678-9 1 0-123-45678-0 6 0-321-32132-1 11 0-321-32132-1 12 0-321-32132-1 13 0-55-123456-9 9 0-55-123456-9 10 0-555-55555-9 5 0-91-045678-5 5 0-91-335678-7 7 0-99-777777-7 5 0-99-999999-9 1 1-1111-1111-1 4 1-22-233700-0 4

Fig. 19

On peut, par exemple, constater que le numéro de téléphone des éditeurs n'apparaît plus qu'une seule fois. Toutefois des répétitions subsistent (et ne peuvent pas être supprimées). Par exemple, le numéro d'un auteur dans la table LIVRE/AUTEUR peut apparaître plusieurs fois.

La suppression des redondances permet non seulement un gain de place, mais, plus important, un gain en cohérence des données; si un éditeur change de numéro de téléphone, il suffit de le changer à un seul emplacement.

Pour mettre en évidence le gain de place, supposons que la Bibliothèque du Congrès contienne des livres provenant de 10'000 éditeurs. Supposons que l'adresse des éditeurs doive être introduite dans les données.

Dans le cas où la structure est celle de la figure 17, il faudrait ajouter 16'000'000 d'adresses.

Alors que dans le cas de notre décomposition en 4 tables 10'000 adresses suffisent. Si chaque adresse occupe 100 caractères, cela équivaut à une économie d'environ 1600 Mbytes (160'000'000 bytes!!)

Problème des valeurs multiples Dans notre exemple, il peut arriver qu'un livre soit écrit par plusieurs auteurs. Dans le cas d'une gestion à l'aide d'une seule table, comme sur la figure 17 il y aurait plusieurs possibilités pour tenir compte des auteurs multiples:

• On peut prévoir une ligne pour chaque auteur, comme pour les livres "Natation" ou "La cuisine"

• On peut prévoir pour un livre (c'est-à-dire une ligne) plusieurs colonnes (une pour chaque auteur)

• On peut inscrire les différents auteurs dans la même colonne (c'est-à-dire, en fait, dans la même case du tableau)


28

La première solution augmente la redondance des données. La seconde implique de connaître combien d'auteurs au maximum on peut accepter pour un même livre. De plus, cela implique un grand gaspillage de place, car tous les livres écrits par un seul auteur (cas fréquent) auraient des colonnes vides. La dernière solution empêche de faire des recherches dans la base de données concernant un seul auteur. En outre il ne serait pas possible d'établir une liste alphabétique des auteurs de la base de données.

Problèmes de mises à jour Ce genre de problème peut arriver dans le cas de notre table unique (figure 17) si, par exemple, on doit changer le numéro de téléphone d'un éditeur. On peut oublier une ligne ou introduire des fautes de frappe, ce qui conduit à une base de données non fiable.

Anomalies d'insertion Supposons que l'on veuille introduire un nouvel éditeur dans notre base de données (tableau de la figure 17), sans pour autant qu'il y ait déjà des livres à lui attribuer.

On pourrait ajouter une ligne dans laquelle seules les informations concernant l'éditeur seraient indiquées; les autres cellules ne contiendraient rien, ou plutôt la valeur NULL. En termes de bases de données, la valeur NULL dans un champ indique une donnée manquante ou inconnue.

Si plusieurs nouveau éditeurs sont introduits en suivant ce procédé, la colonne ISBN qui est censée contenir des valeurs uniques (chaque livre possède un ISBN unique) contiendra des valeurs NULL multiples.

Anomalies de suppression Ce problème est lié au précédent. Si l'on supprime de la base de données tous les livres d'un certain éditeur, toutes les informations concernant cet éditeur sont également perdues.

Conclusion Au vu de ces problèmes, on comprend facilement que l'organisation d'une base de données sous la forme d'une table unique n'est pas satisfaisante. Une bonne structure de base de données implique que les données soient partagées en différentes tables et que des liens soient établis entre ces tables. Une telle base de données "relationnelle" introduit également des difficultés de conception dont nous allons voir quelques exemples.


29

Difficultés liées aux bases de données relationnelles Eviter la perte d'informations Une des difficultés des bases de données relationnelles consiste à savoir choisir comment fractionner les informations en plusieurs tables. Par exemple, la table LIVRE/AUTEUR de notre exemple est indispensable pour pouvoir déterminer l'auteur de chaque livre. Le seul but de cette table est de ne pas perdre le lien AUTEUR <-> LIVRE. Maintenir l'intégrité relationnelle L'intégrité des différentes relations entre tables doit être maintenue lorsque des modifications de la base de données interviennent. Par exemple, si on veut supprimer un éditeur de la base de données, il ne suffit pas de le supprimer de la table EDITEURS. Cela pourrait créer des références flottantes vers cet éditeur depuis la table LIVRES. Crée des vues Lorsque les informations sont fractionnées en plusieurs tables, il est plus difficile de construire des "vues" sur les données. Par exemple, si on veut établir une liste de tous les éditeurs qui publient des livres dont le prix est inférieur à 15 Frs, plusieurs tables interviennent dans ce processus.

Ceci peut paraître paradoxal: le modèle relationnel implique le fractionnement des données en plusieurs tables, alors que la réalité exige souvent de regrouper à nouveau ces données en fonction des besoins. Résumé Après avoir vu que les constituants fondamentaux d'une base de données sont:

• Les tables

• Les requêtes

• Les formulaires

• Les états


30

voyons de quelles manières ils peuvent être utilisés ensemble. Sur le schéma de la figure 14, une flèche signifie "…peut servir de base à…"

formulaire

rientable

requête

état

état

formulaire

requête

Fig. 20


31

Utilisation de plusieurs tables Comme nous l'avons vu précédemment, le fractionnement de l'information en plusieurs tables résout beaucoup de problèmes et permet un gain de place appréciable. Les bases de données sont faites pour modéliser le monde réel qui est rempli d'objets tels que clients, commandes factures, stock, fournisseurs… Elles doivent donc pouvoir stocker les informations concernant ces objets mais également les relations qui existent entre eux. Avant de construire une base de données il faut tenir compte des points (et des questions) suivants:

• Comment stocker les informations ? En d'autres termes: comment s'assurer que les informations sont dans les bonnes tables ?

• Quels type de relations peuvent exister entre les objets du monde réel ?

• Comment ces relations peuvent-elles être construites et gérées dans une base de données?

• Comment faire interagir les tables, requêtes, formulaires et états dans une base de données ?

• Comment assurer l'intégrité des données ? Nous allons aborder ces différents points dans la suite du cours.


32

Stockage des informations A la recherche d'une méthode Comme nous l'avons déjà dit la création d'une base de données au niveau de sa structure en tables et champs constitue une étape fondamentale et incontournable. Quelles informations stocker dans une table CLIENTS ? Faut-il une seule table ? Avec quels champs ? Si on utilise une base de données pour gérer un magasin qui vend des meubles et que ce magasin se diversifie en vendant également des habits, faudra-t-il stocker les habits dans la même table que les meubles ? Comment décider ? Les réponses à ces questions peuvent être très complexes; elles font intervenir, entre autres, l'expérience du développeur. Mais dans la plupart des cas de petite à moyenne importance on peut généralement se fier à une règle simple:

Il convient de créer une table pour chaque ensemble d'objets du monde réel pour lequel on désire stocker les informations dans la base de données.

Pour la gestion d'une entreprise on trouvera donc très vraisemblablement une table CLIENTS, FACTURES, COMMANDES, EMPLOYES… Il est dès lors facile de savoir dans quelle table placer tel ou tel champ. Pour revenir à la question concernant les meubles et les habits, on pourrait dire que si les renseignements à stocker sont les mêmes (par exemple Numéro d'article, Date d'achat, Couleur) une table suffit. Si, en revanche, on désire stocker d'autres informations pour les habits (par exemple Taille, Sexe, Tissu) la cohabitation dans une seule table semble compromise. On comprend donc qu'il ne peut pas y avoir de règles, de marches à suivre ou de recettes. Identification des objets Pour la suite du cours nous allons prendre comme exemple concret une petite société qui vend des articles à des clients. Elle a des employés, dont certains ont un bureau sur place. On peut imaginer, en première approximation, utiliser cinq tables:

• CLIENTS

• ARTICLES

• COMMANDES

• EMPLOYES

• BUREAUX


33

Relations entre objets du monde réel Types de relations Le mot relation est ici utilisé dans le sens d'association ou d'interdépendance. En cherchant bien il apparaît quatre types de relations possibles entre des objets pris par paire:

• Un à plusieurs

• Un à un

• Plusieurs à plusieurs

• Aucune Comme on pourrait s'y attendre et comme nous le verrons plus loin, ces quatre types de relations se retrouvent dans les bases de données relationnelles. Relation un à plusieurs La relation entre un client et une commande est typiquement une relation de un à plusieurs. Cela signifie qu'un client peut avoir fait aucune, une ou plusieurs commandes. Il convient de remarquer que:

• Il n'est pas nécessaire qu'un client fasse une commande avant qu'il puisse être enregistré en tant que client

• Un client ne doit pas forcément avoir plusieurs commandes; il s'agit simplement d'une possibilité

Ce type de relation est de très loin le plus répandu. Relation un à un Dans notre société on peut imaginer que certains employés peuvent avoir un bureau (dans le sens de local). Pour des raisons d'économie on ne veut pas attribuer plus d'un bureau à un employé. On a affaire à une relation de type un à un entre les employés et les bureaux. Les relations un à un sont extrêmement peu fréquentes. A tel point qu'il est très difficile d'en trouver de bonnes illustrations dans la littérature consacrée aux bases de données. Relation plusieurs à plusieurs Considérons la relation entre les clients et les employés. Au cours du temps un client pourra avoir été servi par plusieurs employés; inversement, un employé peut s'occuper de plusieurs clients. Là encore le terme "plusieurs" n'implique pas une obligation, mais une possibilité. Ce type de relation est relativement courant.


34

Aucune relation Ce n'est pas une relation, mais une absence de relation. Il est vrai qu'il n'y a pas de relation entre les bureaux et les articles vendus par notre société. Ce type de relation n'est quasiment d'aucun intérêt.


35

Mise en place des relations Introduction Nous parlons dès à présent de relations au sens des bases de données. On rencontre également le terme "jointures" pour désigner une relation. Après avoir vu comment exprimer des relations entre nos objets du monde réel, nous allons étudier comment transposer ces relations au niveau des tables d'une base de données. L'établissement de relations entre tables fait intervenir deux notions:

• La relation elle-même (ou lien entre les tables)

• Des clés (primaires et étrangères) Remarque: une des manières (également utilisée par Access) de référencer un champ dans

une table est d'utiliser la notation pointée. Ainsi CLIENTS.CliNom indique le champ CliNom de la table CLIENTS. La raison de cette notation est que le même nom de champ peut se trouver dans plusieurs tables; ainsi l'utilisation du nom de la table comme préfix lève l'ambiguïté.

CLIENTS CliNo CliPrenom CliNom

1 Jo Lee 2 Pierre Lesage 3 Jean Lebon 4 Sandra Bu-Loque

BA

SE

4.M

DB

COMMANDES ComNo EmpNo CliNo ComFournisseur ComPrix Article

1 1 2 Harrison 235.00 Lit 2 4 1 Ford 234.00 Chaise 3 1 3 Harrison 415.00 Table 4 2 4 Ford 350.00 Lampe 5 3 2 Ford 234.00 Chaise 6 2 4 Ford 350.00 Lampe 7 2 2 Harrison 235.00 Lit

EMPLOYES

EmpNo EmpPren EmpNom EmpDateNais EmpDateEntr1 Albertine Jass 12 04 56 01 05 89 2 Guy Li 21 03 67 01 01 90 3 John Hérouge 01 05 67 01 04 92 4 Norma Lisation 03 04 56 01 04 92 5 Berthe Alors 12 04 56 01 04 92 6 Hubert Schneider 01 05 57 01 05 94

Fig. 21

Pour aider à la compréhension les valeurs de certains champs sont en gras (clés primaires) et celles d'autres champs sont en italique (clé étrangères).


36

On peut remarquer sur la figure 21 que les tables CLIENTS et COMMANDES ont un champ appelé CliNo. Il semble donc logique que le 2 dans le premier enregistrement de COMMANDES.CliNo signifie que Pierre Lesage a acheté un lit. Le nombre 2 est utilisé comme un "pointeur". De plus il est facile d'en déduire que l'employée Albertine Jass s'est occupée de la commande de Monsieur Lesage. Dans la théorie des bases de données on donne un nom aux champs comme CliNo qui servent à définir un lien entre des tables: on les appelle des clés. De plus, la relation entre les tables CLIENTS et COMMANDES n'étant pas symétrique, on fait une distinction entre:

• Une clé primaire (c'est le cas de CLIENTS.CliNo)

• et une clé étrangère (c'est le cas de COMMANDES.CliNo) Entre ces deux tables nous avons une relation du type un à plusieurs et on voit que la clé primaire se trouve du côté "un" de la relation. La notion de clé est très importante et nous allons l'étudier plus précisément dans ce qui suit. Clés primaires Plutôt que définir les caractéristiques que doit avoir une clé primaire, essayons de les déduire au travers d'exemples. Que se passerait-il si le champ CLIENTS.CliNo contenait la même valeur (par exemple 1) pour Jo Lee et Pierre Lesage ?



COMMANDES

ComNo EmpNo CliNo ComFournisseur ComPrix Article 1 1 2 Harrison 235.00 Lit 2 4 1 Ford 234.00 Chaise 3 1 3 Harrison 415.00 Table 4 2 4 Ford 350.00 Lampe 5 3 2 Ford 234.00 Chaise 6 2 4 Ford 350.00 Lampe 7 2 2 Harrison 235.00 Lit

Fig. 22

Il serait simplement impossible de savoir à qui envoyer la facture pour la commande no. 2. De plus, cela pose un problème pour les commandes no. 1, 5 et 7, mais nous reviendrons sur ce problème en parlant des clés étrangères. Première règle:

Les valeurs pour une clé primaire doivent être uniques pour chaque enregistrement (pas de doublon autorisé)


37

Examinons maintenant le cas suivant, dans lequel une clé primaire est absente:


1 Jo Lee 2 Pierre Lesage

Jean Lebon 4 Sandra Bu-Loque

COMMANDES


Fig.237

Monsieur Lebon doit-il payer la commande no. 3 ? Ce n'est pas clair; et ce n'est pas plus clair si les informations se présentent de la manière suivante:


1 Jo Lee 2 Pierre Lesage

Jean Lebon 4 Sandra Bu-

COMMANDES

ComNo EmpNo CliNo ComFournisseur ComPrix Article 1 1 2 Harrison 235.00 Lit 2 4 1 Ford 234.00 Chaise 3 1 Harrison 415.00 Table 4 2 4 Ford 350.00 Lampe 5 3 2 Ford 234.00 Chaise 6 2 4 Ford 350.00 Lampe 7 2 2 Harrison 235.00 Lit

Fig. 24

Nous pouvons en déduire la seconde caractéristique d'une clé primaire: Deuxième règle:

Une clé primaire doit toujours avoir une valeur (non NULL) Remarque: dans les bases de données, une valeur manquante dans un champ est appelée

une valeur NULL. Lors de la création d'une table, l'une des tâches consiste à choisir une clé primaire qui respecte ces deux règles.


38

Le fait de définir un champ comme clé primaire suffit à Access pour toujours vérifier que les deux règles ne sont pas enfreintes. Même avec des centaines de milliers d'enregistrements ces vérifications ont lieu de manière quasi immédiate. Clé primaire constituée par plusieurs champs Il est possible de définir une clé primaire comme la combinaison de deux champs. Ainsi, dans une table AGENDA une personne pourrait être définie de manière unique par son nom et son prénom. La clé primaire de cette table pourrait être la combinaison {Nom-Prénom}. Cela exclurait la possibilité d'avoir des homonymes (même nom et même prénom) dans la table. A part quelques rares cas où cela est nécessaire, il vaut mieux éviter ce genre de clé primaire composite. Remarque: il est également déconseillé de choisir comme clé primaire un champ de type

Texte. Choix d'une bonne clé primaire Voici quelques indications (et non obligations) pour le choix d'une clé primaire:

• évitez les clés composites (plusieurs champs)

• évitez les clés sur des champs contenant du texte

• laissez Access gérer automatiquement une clé primaire en tant que champ numérique de type NuméroAuto

Quand c'est possible ce dernier conseil est la meilleure solution. Cela peut paraître frustrant ou réducteur, mais une telle clé primaire est utilisée uniquement pour définir des relations et le contenu de ce champ n'est généralement jamais visible par l'utilisateur. Voici quelques situations pour lesquelles ce conseil peut ne pas être suivi:

• champ ISBN pour des livres

• no. de sécurité sociale dans certains pays pour les personnes

• no. d'article pour un fournisseur Création d'une clé primaire Cette opération s'effectue dans la phase de création d'une table. Il suffit de sélectionner la ligne désirée et de cliquer sur le bouton "clé primaire" de la barre d'outils d'Access. Pour définir une clé composite l'opération est la même, mais il faut sélectionner plusieurs lignes. En principe toute table doit posséder une clé primaire. Access insiste fortement pour qu'une table ait une clé primaire, mais ne l'oblige pas. Clés étrangères Reprenons les tables CLIENTS et COMMANDES de notre exemple _____________________________________________________________________________




COMMANDES


Fig. 25

Le champ COMMANDES.CliNo est une clé étrangère utilisée pour établir la relation entre les deux tables. Imaginons la situation suivante:



COMMANDES


Fig. 26 Visiblement la commande no. 7 ne concerne aucun client. On peut donc énoncer la règle suivante:

Une clé étrangère ne peut contenir que des valeurs qui sont représentées dans la clé primaire correspondante

De plus:

• une clé étrangère fait toujours référence à une clé primaire

• une clé étrangère n'a d'existence qu'implicitement dans une relation. Elle n'est mentionnée nulle part dans Access

• une table peut avoir plus d'une clé étrangère (par exemple la tables COMMANDES)

• une clé étrangère et sa clé primaire correspondante doivent être du même type

• généralement on donne le même nom à une clé étrangère et à sa clé primaire correspondante.


40

Relations proprement dites Après avoir étudié les clés primaires et étrangères, revenons plus en détail sur les divers types de relations. Relations un à plusieurs Une fois les clés primaires définies et les clés étrangères correspondantes créées il est possible de choisir l'option "Outils/Relations" (ou le bouton correspondant de la barre d'outils) prévue dans Access (voir figure 27).

BA

SE

4.M

DB

Fig. 27 Dans un premier temps il faut ajouter les tables désirées dans la fenêtre des relations, puis faire un "drag and drop" du champ CliNo d'une table vers l'autre. A ce moment apparaît la petite fenêtre (à droite de la figure 27) dans laquelle Access a déjà rempli les indications par défaut. Access place également sur le schéma les symboles "1" et "∞" de part et d'autre de la relation (si l'option "Appliquer l'intégrité référentielle" est choisie). Pour le moment on peut ignorer les options concernant l'intégrité référentielle, notion abordée plus loin. En plus de la définition de la relation, Access considère désormais le champ COMMANDES.CliNo comme clé étrangère. De ce fait placer un nombre dans le champ COMMANDES.CliNo qui n'existe pas dans CLIENTS.CliNo sera systématiquement refusé. Au vu de ce mécanisme de construction d'une relation, on comprend mieux que les notions de clé et de lien (relation) sont intimement liées.


41

Il est possible de définir des relations entre tables alors que les tables contiennent déjà des données. D'une manière générale l'établissement d'une relation peut être refusé si:

• le champ utilisé du côté "un" de la relation n'est pas une clé primaire

• les types des deux champs servant à établir la relation sont différents

• des données existent déjà dans la table du côté "plusieurs" mais n'ont pas de correspondance dans la table du côté "un"

Nous avons indiqué précédemment qu'il est très fréquent qu'une clé primaire soit de type NuméroAuto. Quel type faut-il choisir pour la clé étrangère correspondante ? Il faut impérativement choisir le type Numérique/Entier Long. Relations un à un Les relations un à un sont peu fréquentes et leur construction est analogue à celle des relations un à plusieurs. La seule différence est que la clé étrangère de la seconde table ne doit pas admettre de doublons. Il y a deux manières de garantir cette condition:

• s'assurer que la clé étrangère de la seconde table est aussi sa clé primaire. Dans ce cas la relation se fait entre deux clé primaires, une des deux faisant également office de clé étrangère

• faire en sorte que la seconde clé soit un index unique (sans doublons) Considérons le second cas (figure 28) dans lequel le champ BUREAUX.EmpNo est un index unique.

BA

SE

5.M

DB

EMPLOYES EmpNo EmpPren EmpNom EmpDateNais EmpDateEntr

1 Albertine Jass 12 04 56 01 05 89 2 Guy Li 21 03 67 01 01 90 3 John Hérouge 01 05 67 01 04 92 4 Norma Lisation 03 04 56 01 04 92 5 Berthe Alors 12 04 56 01 04 92 6 Hubert Schneider 01 05 57 01 05 94

BUREAUX BureauNo EmpNo

1 212 423 124 6

Fig. 28

La relation un à un entre ces deux tables est construite comme sur la figure 29.


42

Fig. 29 Dans ces conditions le cas suivant n'est pas autorisé, car la valeur 9 n'existe pas dans le champ EMPLOYES.EmpNo:


1 212 423 124 9

Fig. 30

Le cas suivant est également interdit car la valeur 2 est répétée:


1 212 423 124 2

BA

SE

5.M

DB

Fig. 31


43

Relations plusieurs à plusieurs Pour illustrer ce type de relation prenons les tables CLIENTS et EMPLOYES et posons-nous la question suivante:

Qu'est-ce qui définit une interaction entre un client et un employé ? En termes de base de données l'interaction a lieu lorsqu'un client commande un article. Cette interaction passe donc par la table COMMANDES.



BA

SE

5.M

DB

COMMANDES ComNo EmpNo CliNo ComFournisseur ComPrix Article

1 1 2 Harrison 235.00 Lit 2 4 1 Ford 234.00 Chaise 3 1 3 Harrison 415.00 Table 4 2 4 Ford 350.00 Lampe 5 3 2 Ford 234.00 Chaise 6 2 4 Ford 350.00 Lampe 7 2 2 Harrison 235.00 Lit

EMPLOYES


Fig. 32

Mais entre la table CLIENTS et la table COMMANDES on a une relation de un à plusieurs. Il en est de même entre la table EMPLOYES et la table COMMANDES. Donc une relation plusieurs à plusieurs est simplement traduite par deux relations de un à plusieurs avec l'orientation que l'on peut voir sur la figure 33. Il n'y a aucun mécanisme permettant la définition explicite d'une relation de plusieurs à plusieurs. Ce type de relation n'existe pas au sens strict.


44

BA

SE

4.M

DB

Fig. 33

Chasse aux redondances En observant les tables de la figure 32, notamment la table COMMANDES une constatation apparaît. Alors que dans notre base de données aucun nom de client ou d'employé n'apparaît plus d'une fois, dans la table COMMANDES on trouve plusieurs fois une chaise ou une lampe. N'y aurait-il pas lieu de revoir la structure de notre base de données ? La chasse aux redondances est un excellent moteur dans la mise en œuvre de bases de données ayant une structure correcte. De plus il repose essentiellement sur le bon sens. On pourrait transformer notre table COMMANDES (et les tables auxquelles elle est liée) de la manière suivante:

BA

SE

6.M

DB

COMMANDES ComNo EmpNo CliNo ArtNo

1 1 2 1 2 4 1 3 3 1 3 4 4 2 4 2 5 3 2 3 6 2 4 2 7 2 2 1

EMPLOYES


CLIENTS

CliNo CliPrenom CliNom 1 Jo Lee 2 Pierre Lesage 3 Jean Lebon 4 Sandra Bu-Loque


45

ARTICLES ArtNo ArtFourniss ArtPrix ArtDesign

1 Harrison 235.00 Lit 2 Ford 350.00 Lampe 3 Ford 234.00 Chaise 4 Harrison 415.00 Table

Fig. 34

Cette représentation paraît correcte. En réalité elle a un grave problème: une commande ne peut avoir qu'un seul article. On pourrait avoir plusieurs champs indiquant les articles de la commande.

COMMANDES (mauvaise solution) ComNo EmpNo CliNo ArtNo1 ArtNo2 ArtNo3 ArtNo4 ArtNo5

1 1 2 1 4 2 4 1 3 3 1 3 4 3 3 3 34 2 4 2 1 3 5 3 2 3 2 6 2 4 2 4 7 2 2 1 2

Fig. 35

Le problème est que la prochaine fois qu'un client commande 6 articles la structure de la table doit être modifiée, ce qui n'est jamais une bonne initiative en bases de données. De plus, si la plupart des clients achète un ou deux articles à la fois, le gaspillage de place est flagrant. Enfin, essayez d'imaginer comment construire une requête permettant de savoir combien de chaises ont été vendues. Une autre solution pourrait être d'indiquer par des champs la nature des articles vendus, la valeur contenue dans ces champs indiquerait le nombre d'articles vendus.

COMMANDES (mauvaise solution) ComNo EmpNo CliNo Lit Lampe Chaise Table

1 1 2 1 1 2 4 1 1 3 1 3 4 1 4 2 4 1 1 1 5 3 2 1 1 6 2 4 1 1 7 2 2 1

Fig. 36

Cette solution n'est pas viable. Chaque ajout d'un nouvel article dans le stock nécessite une modification de la structure de la table. N'oublions pas que le nombre de champs par table est limité (255 pour Access). Le problème de l'espace perdu n'est pas non plus éliminé par cette solution. La bonne solution découle également du bon sens. La relation entre les commandes et les articles est du type plusieurs à plusieurs:

• un article peut apparaître dans plusieurs commandes

• une commande peut contenir plusieurs articles


46

Il nous faut donc une troisième table que nous appellerons COM/ART. Voici maintenant comment se présentent les trois tables en jeu:

COMMANDES ComNo EmpNo CliNo

1 1 22 4 13 1 34 2 45 3 26 2 47 2 2

BA

SE

7.M

DB

COM/ART ComNo ArtNo NbArt

1 1 11 4 12 3 13 3 43 4 14 1 14 2 14 3 15 2 15 3 16 2 16 4 17 1 1

ARTICLES ArtNo ArtFourniss ArtPrix ArtDesign


Fig. 37

En examinant la table COM/ART on peut voir que la commande no. 4 comprend 3 articles (dont on a le nombre et on peut retrouver la désignation), que la commande no. 7 n'a qu'un article, etc. Avec une telle structure:

• une commande peut contenir un nombre "illimité" d'articles

• les redondances sont éliminées (du moins en ce qui concerne la désignation des articles)

• il n'y pas de place gaspillée (tous les champs sont remplis)

• l'adjonction d'un nouvel article en stock ne concerne que la table ARTICLES Examinons de plus près les clés impliquées dans cette structure:

• COMMANDES.ComNo est une clé primaire

• ARTICLES.ArtNo ets une clé primaire

• ni COM/ART.ComNo ni COM/ART.ArtNo ne peuvent être seuls une clé primaire. Nous devons donc définir une clé primaire composite formée de ces deux champs


47

Voici la version définitive du schéma de notre base de données:

BA

SE

7.M

DB

Fig. 38 Remarque: pour être rigoureux il faudrait également supprimer la redondance sur le champ

ARTICLES.ArtFournisseur en incluant une table FOURNISSEURS liée à la table ARTICLES par une relation de type un à plusieurs.

Voici les modifications apportées à la table ARTICLES:

BA

SE

8.M

DB

Fig. 39 L'ancien champ ArtFournisseur (de type texte) est devenu FourNo (de type Numérique / Entier Long) la nouvelle clé étrangère impliquée dans la relation avec la table FOURNISSEURS. _____________________________________________________________________________


Voici la nouvelle table FOURNISSEURS (structure et données):

BA

SE

8.M

DB

Fig. 40

Fig. 41

Le schéma de la base de données se présente maintenant de la manière suivante:

BA

SE

8.M

DB

Fig. 42


49

Leçons à tirer Notre exemple, bien que simple, met en évidence des problèmes et des solutions tels qu'on les rencontre dans la quasi totalité des cas réels. Notre exemple est proche d'un cas réel, dans lequel l'éventuelle plus grande complexité réside dans le plus grand nombre de tables mises en jeu.

Arrivés à ce stade voici quelques constatations inspirées par l'évolution de notre exemple et par les concepts sous-jacents:

• La dernière étape de notre exemple possède une structure très flexible au niveau du fonctionnement, sans jamais avoir besoin de modifier une structure

• Les SGBDR modernes comme Access permettent facilement de modifier la structure d'une table à n'importe quel moment. Toutefois cette facilité devrait être réservée à la phase de développement. Après cette phase tout changement de structure ne doit se faire que s'il est vital. N'oublions pas que des requêtes, des formulaires, des états et du code de programmation dépendent de la structure des tables et de leurs relations

• Nous avons vu que la plupart des relations mettent en jeu des champs (clés) numériques. Il est clair que l'interface (formulaires) doit autant que possible cacher ces champs et privilégier, par exemple, le choix au travers de listes déroulantes.

• Dans les relations de plusieurs à plusieurs la présence d'une table supplémentaire permettant cette relation (appelée souvent table associative) ne découle pas forcément du bon sens. Elle ne correspond pas forcément à un objet du monde réel.

• Arrivés à ce niveau nous sommes entrés de plein pied dans le monde des bases de données (et dans le monde des spécialistes). Une différence subsiste: le langage (et parfois le jargon) utilisé. Pour ne donner qu'un exemple, on parle souvent de relation père/fils ou plutôt mère/fille lorsque deux tables sont en relation. Ainsi la table EMPLOYES et la table CLIENTS sont des tables mères par rapport à la table COMMANDES. Le parent est toujours du côté "un" d'une relation du type "un à plusieurs"

Un cours sur les bases de données pourrait s'arrêter ici. Comme disent certains spécialistes le reste est sans intérêt, il s'agit essentiellement de cosmétique et ils n'ont pas tort. Mais la cosmétique peut aussi s'apprendre, donc s'enseigner.


50

2ème partie

Cours avancé


51

Synthèse

Introduction Nous avons vu dans ce qui précède pourquoi et comment séparer les informations en plusieurs tables. Voyons les bénéfices que l'on peut tirer d'un tel fractionnement des informations. Mais tout d'abord il convient de mettre l'accent sur un point déjà abordé:

Dans une base de données il est impératif que les tables de résultats générées par des requêtes doivent non seulement ressembler à des tables, mais également se comporter exactement comme des tables de base.

En d'autres termes, des formulaires et des états peuvent être basés sur des requêtes exactement de la même manière qu'ils peuvent être basés sur des tables. Cette propriété est beaucoup plus importante qu'il n'y paraît au premier abord. Ceci implique également qu'une requête peut être basée sur une table de résultats d'une autre requête (on parlera de requête basée sur une requête) et non seulement sur une ou plusieurs tables. De plus, il n'y a pas de limite a une telle imbrication de requête. Toutefois, dans la pratique, il est rare d'avoir un empilement de plus de 4 ou 5 requêtes. Pour illustrer ce qui vient d'être énoncé prenons notre table de commandes

ComNo EmpNo CliNo 1 1 22 4 13 1 34 2 45 3 26 2 47 2 2

Fig. 43 Voici un formulaire permettant de parcourir les commandes:

BA

SE

9.M

DB

Fig. 44 _____________________________________________________________________________


Si les formulaires ne pouvaient être basés que sur des tables de base nous serions limités à des modes de visualisation plutôt anti-ergonomiques et tout sauf conviviaux. Grâce à la propriété énoncée ci-dessus, il est possible de créer une requête fournissant les résultats suivants:

BA

SE

10.M

DB

ComNo Client Employe 1 Pierre Lesage Albertine Jass 2 Jo Lee Norma Lisation 3 Jean Lebon Albertine Jass 4 Sandra Bu-Loque Guy Li 5 Pierre Lesage John Hérouge 6 Sandra Bu-Loque Guy Li 7 Pierre Lesage Guy Li

Fig. 45 Et permettant de construire le formulaire suivant:

BA

SE

10.M

DB

Fig. 46 Si le numéro de commande reste numérique (ce qui est logique), les clients et les employés sont repérés par leur nom et non plus par leur numéro (qui de plus est un nombre arbitraire). Sur la figure 46 on peut voir que le formulaire comprend un sous-formulaire permettant de visualiser le détail de chaque commande. Encore une fois, ceci n'est possible que grâce au fait qu'une table de résultats d'une requête peut être utilisée comme une table de base. Revenons sur les quatre constituants de base d'Access: tables, requêtes, formulaire et états. Voyons les implications d'une base de données faisant appel à plusieurs tables sur ces constituants. Tables L'effet du passage à une base de données multi-tables est évident: il consiste en l'augmentation du nombre de tables. Tout ce qui a été dit précédemment concernant les tables reste valable.


53

Requêtes Avec une base de données mono-table, les requêtes consistent essentiellement en l'extraction de données en fonction de certains critères. Les requêtes peuvent également servir à faire des calculs (comptage, moyenne, etc) ou à concaténer plusieurs champs. C'est dans l'optique d'une base de données multi-tables que les requêtes prennent de l'importance et délivrent toute leur puissance et leur efficacité. Pour l'essentiel les requêtes sont utilisées afin d'extraire des données de plusieurs tables. Si le partage de l'information en plusieurs tables assure un stockage optimal de l'information et une adéquation au modèle relationnel, il conduit au fait que les informations sont moins facilement exploitable dans leur état brut (au niveau des tables). Les requêtes sont essentielles pour redonner une certaine "lisibilité" à l'information, lisibilité qui se répercute sur la qualité fonctionnelle de l'interface-utilisateur. Par exemple la requête de la figure 47 produit une table de résultats que l'on peut voir sur la figure 48. L'utilité d'une telle requête est évidente et on imagine facilement que la flexibilité des requêtes permet une grande diversité "vues" des informations de base. On constate également que les requêtes font automatiquement usage des relations et des clés primaires et étrangères associées, pour autant que les relations entre tables aient été préalablement spécifiées.

BA

SE

10.M

DB

Fig. 47


54

BA

SE

10.M

DB

Fig. 48 Jusqu'ici tout semble parfait, mais une question essentielle subsiste: est-il possible de modifier les données d'une table de résultats d'une requête multi-tables (ou d'un formulaire basé sur cette requête)? La réponse est oui, avec parfois quelques restrictions. Pour y voir plus clair nous allons examiner quelques exemples. Exemple 1 Supposons que nous ajoutons un champ Pays dans notre table CLIENTS, et que nous créons la requête "RequêteSuisse":

BA

SE

11.M

DB

CliNo CliPrenom CliNom CliPays

1 Jo Lee Suisse 2 Pierre Lesage Suisse 3 Jean Lebon France 4 Sandra Bu-Loque Suisse

Fig. 49

_____________________________________________________________________________


Et que nous construisons un formulaire basé sur cette requête:

BA

SE

11.M

DB

Fig. 50 Dans ce cas il est tout à fait possible de modifier les champs d'un client, car on travaille dans un sous-ensemble des enregistrements de la table CLIENTS. Les modifications effectuées sont automatiquement reportées dans la table CLIENTS via la requête sous-jacente. Remarque: si, depuis le formulaire de la figure 50, on ajoute un enregistrement ayant un autre

pays que la Suisse, ou si on change le pays d'un client suisse existant, l'enregistrement sera correctement modifié dans la table CLIENTS, mais restera dans le formulaire des clients suisses jusqu'à la prochaine réactualisation des données (explicite ou suite à la fermeture du formulaire).

Exemple 2 Dans cet exemple, de la mousse synthétique est vendue par unité de volume (m3). Les dimensions des morceaux (paralellépipédiques) de mousse sont stockées dans une table. Le volume n'est évidemment pas un champ de la table puisqu'il peut être déduit (calculé) à partir des champs Longueur, Largeur et Hauteur. Une requête se chargera d'effectuer le calcul. Voici la table MOUSSE:

BA

SE

12.M

DB

element longueur largeur hauteur 1 20 35 15 2 20 50 15 3 25 50 15 4 30 50 20 5 30 40 20 6 40 40 40

Fig. 51 La requête MousseVolume contient le champ Volume sous la forme d'une expression permettant de calculer le volume en mètres cubes.


56

BA

SE

12.M

DB

Fig. 52 Enfin voici le formulaire (sans aucune fioriture) basé sur le requête MousseVolume:

BA

SE

12.M

DB

Fig. 53 Dans ce formulaire tous les champs sont modifiables, sauf le champ Volume. Lors de la modification des dimensions des blocs de mousse le champ Volume est automatiquement mis à jour, un peu à la manière d'un tableur. Toutefois Access ne laisse pas apporter de modifications au champ Volume. Cela est tout à fait logique, car il n'y a aucun critère permettant de déduire les dimensions en partant du volume. Exemple 3 Reprenons le cas équivalent à celui de la requête de la figure 47 et ses résultats (figure 48), mais dans la version où le nom des fournisseurs est intégré à la table ARTICLES. La figure 54 montre la requête utilisée:


57

BA

SE

13.M

DB

Fig. 54 Voici un formulaire basé sur cette requête:

B

AS

E13

.MD

B

Fig. 55 Cet exemple est intéressant car il présente divers comportements face aux modifications des champs qu'il contient.

• Les champs Client et Employé ne sont pas modifiables car ils résultent de la concaténation des champs Nom et Prenom respectifs

• Le champ ArtDesign se comporte de manière surprenante, mais somme toute logique. Si on change le libellé, par exemple de "Table" en "Table basse", tous les enregistrement contenant cet article auront leur champ ArtDesign modifié. En effet l'article est modifié dans la table ARTICLES, mais plusieurs commandes font référence à cet article et intègrent automatiquement la modification effectuée. Cette opération peut également être visualisée en faisant la modification directement sur la table de résultats de la requête sous-jacente


58

• Si on change le nom d'un fournisseur (champ FourNom), le résultat est encore plus surprenant. Partons, par exemple de la requête sur laquelle est basé le formulaire de la figure 55 et changeons le premier fournisseur "Harrison" en "Harrisonne" Voici la table de résultats avant (figure 56) et après (figure 57) la modification

ComNo Client Employé ArtDesign NbArt FourNo ArtPrix

1 Pierre Lesage Albertine Jass Lit 1 Harrison 235.001 Pierre Lesage Albertine Jass Table 1 Harrison 415.002 Jo Lee Norma Lisation Chaise 1 Ford 234.003 Jean Lebon Albertine Jass Chaise 4 Ford 234.003 Jean Lebon Albertine Jass Table 1 Harrison 415.004 Sandra Bu- Guy Li Lit 1 Harrison 235.004 Sandra Bu- Guy Li Lampe 1 Ford 350.004 Sandra Bu- Guy Li Chaise 1 Ford 234.005 Pierre Lesage John Hérouge Lampe 1 Ford 350.005 Pierre Lesage John Hérouge Chaise 1 Ford 234.006 Sandra Bu- Guy Li Lampe 1 Ford 350.006 Sandra Bu- Guy Li Table 1 Harrison 415.007 Pierre Lesage Guy Li Lit 1 Harrison 235.00

Fig. 56 ComNo Client Employé ArtDesign NbArt FourNo ArtPrix

1 Pierre Lesage Albertine Jass Lit 1 Harrisonne 235.001 Pierre Lesage Albertine Jass Table 1 Harrison 415.002 Jo Lee Norma Lisation Chaise 1 Ford 234.003 Jean Lebon Albertine Jass Chaise 4 Ford 234.003 Jean Lebon Albertine Jass Table 1 Harrison 415.004 Sandra Bu- Guy Li Lit 1 Harrisonne 235.004 Sandra Bu- Guy Li Lampe 1 Ford 350.004 Sandra Bu- Guy Li Chaise 1 Ford 234.005 Pierre Lesage John Hérouge Lampe 1 Ford 350.005 Pierre Lesage John Hérouge Chaise 1 Ford 234.006 Sandra Bu- Guy Li Lampe 1 Ford 350.006 Sandra Bu- Guy Li Table 1 Harrison 415.007 Pierre Lesage Guy Li Lit 1 Harrisonne 235.00

Fig. 57

En effet, le nom du fournisseur apparaît plusieurs fois dans la table de base ARTICLES. (figure 58)

ArtNo FourNom ArtPrix ArtDesign


Fig. 58

On voit que les seules les commandes contenant l'article dont le fournisseur a subi la modification ont répercuté le changement. Ce cas nous montre bien à quel point il est préférable de supprimer les redondances lors de la structuration des tables

• Enfin, le champ ComNo n'est pas modifiable, car c'est un champ de type NuméroAuto incrémenté automatiquement par Access.

Ces quelques exemples, qui n'épuisent pas tous les cas possibles, montrent que les SGBDR obéissent à des règles logiques concernant les possibilités de modification des données d'une requête: on peut généralement leur faire confiance. _____________________________________________________________________________


Formulaires Dans l'optique d'une base de données constituée de plusieurs tables, les formulaires que l'on peut créer sont plus riches et offrent plus de possibilités dans leur exploitation. L'exemple de la figure 46 en est une bonne illustration du moins dans les fonctionnalités si ce n'est dans l'ergonomie. Voici un autre exemple plus représentatif de ce que l'on peut trouver dans des applications base de données plus complexes:

Fig. 59

On peut voir sur ce formulaire:

• Un champ de recherche

• Des sous-formulaires

• Des boutons personnalisés

• Des champs calculés

• Des possibilités de filtrage avancées

• Le remplacement des boutons de navigation standard par des boutons "programmés" pour offrir une plus grande sécurité

• L'absence de boutons dans la barre de titre de la fenêtre

• etc


60

Il est clair que de tels formulaires ont pour objectif d'isoler l'utilisateur de la complexité structurelle des tables contenant les données brutes. Cette complexité (pour le néophyte ou l'utilisateur moyen) est inhérente au modèle relationnel et il est bon de passer par des formulaires de regroupement de données afin de travailler de manière naturelle. Etats Les états servent à imprimer des données, mais également à ordonner et à regrouper les informations d'une base de données. Ils sont fréquemment basés sur des requêtes multi-tables. Nous allons voir deux utilisations des états. Dans le premier cas on voudrait savoir par quel(s) client(s) a été acheté tel ou tel article.

BA

SE

14.M

DB

Fig. 60 Dans le second cas on voudrait avoir un résumé des commandes clients, avec des totaux par client ainsi qu'un total global. On peut remarquer que le regroupement des articles par client ne peut pas être effectué par une requête. On utilise donc les possibilités de regroupement offertes par les états.


61

B

AS

E14

.MD

B

Fig. 61 Les états sont généralement bien plus complexes que ces deux exemples. Access a la particularité d'offrir énormément de possibilités de présentation, aspect et regroupements dans les états et il est rare de ne pas réussir à obtenir le résultat désiré. Maîtriser les états dans Access n'est pas simple et nécessite un bon apprentissage. _____________________________________________________________________________


Intégrité des données De quoi s'agit-il ? On peut se demander quel devrait être le degré d'exactitude des informations d'une base de données. 100 % serait souhaitable, mais quel serait le pourcentage, d'un point de vue réaliste, acceptable pour une grande base de données ? 90 %, 95 % ? En fait nous allons voir qu'il est indispensable de tout entreprendre pour que le degré d'exactitude soit très proche de 100 %. Imaginons une base de données de 10'000 patients d'un hôpital pour laquelle 95 % des informations pour chaque patient est exact. Supposons de requêtes du type "Combien de personnes ont plus de 40 ans ?", "Combien de personnes sont-elles sous tranquillisants ? ", etc. Supposons également que le nombre moyen de réponses soit de 200. Dans ces conditions la probabilité qu'une requête retourne une réponse correcte est de 0.95200 soit 0.000035, soit encore 0.0035%, c'est-à-dire que plus de 99 % des réponses peuvent être incorrectes. Pour moduler un peu ces chiffres, on peut dire qu'une requête dont le nombre de réponses est bien plus petit que 200 donnera des résultats ayant un bien plus grand pourcentage d'exactitude. De plus, l'inexactitude relative de certaines requêtes n'est parfois pas un problème trop grave. Si la requête concernant les tranquillisants donne un résultat de 603 au lieu de 605 et sert de base pour savoir la quantité de tranquillisants à commander, l'inexactitude aura peu d'implications. Avec les même suppositions que ci-dessus, il faudrait 99.9 % d'exactitude des informations pour obtenir 82 % de réponses correctes. Il vaut donc la peine d'assurer par tous les moyens disponibles l'intégrité des données. Problèmes liés à l'intégrité des données Voici quelques types d'erreurs pouvant altérer l'intégrité des données, ainsi que des moyens de prévention: Erreurs d'informations courantes Supposons que dans un champ "Formule de politesse" on indique M., Mme, Mlle etc et que malencontreusement des indications "Melle" au lieu de "Mlle" aient été introduites. Une requête qui extrait toutes les demoiselles d'une base de données oubliera les "Melle" si le critère d'interrogation est "Mlle". Généralement les SGBDR offrent des moyens permettant d'éviter ce genre d'inconvénient. Ceci est valable dans les cas où le nombre de valeurs différentes pour un champ est petit. Avec Access il est possible d'intervenir au niveau de la table en utilisant les règles de validation disponibles pour chaque champ. La propriété "Valide si" permet d'indiquer explicitement les valeurs acceptées, alors que la propriété "Message si erreur" permet de spécifier le message qu'Access doit afficher en cas de non-conformité lors de la saisie. Le contrôle est ici effectué au niveau de la table, mais il est également possible d'effectuer ce contrôle au niveau d'un formulaire, comme sur la figure 63. Ce type de contrôle peut fonctionner conjointement ou séparément de celui au niveau de la table.


63

BA

SE

15.M

DB

Fig. 62

BA

SE

15.M

DB

Fig. 63 Il est également possible de placer des contrôles d'intégrité sur des champs de type numérique. Sur la figure 64, le champ Age contient l'âge des clients et le contrôle effectué interdit des âge hors des limites 0 à 150.


64

BA

SE

15.M

DB

Fig. 64 En cas de saisie incorrecte, voici comment Access manifeste son mécontentement:

BA

SE

15.M

DB

Fig. 65 Erreurs sur une valeur donnée pour un champ Supposons qu'on entre "Dupond" au lieu d'entrer "Dupont" dans un champ Nom. Il est évident qu'aucun moyen automatique de prévention ne peut être utilisé. Ce genre d'erreur est néanmoins fréquent et le seul remède efficace est d'être extrêmement attentif lors de la saisie de données importantes (noms, no. de téléphone, no. de compte etc). Erreurs de cohérence entre les données de différents champs Dans le cas d'une table Employés qui contient, entre autres, la date de naissance ainsi que la date d'engagement de l'employé, il faudrait éviter que la date de naissance soit postérieure à la date d'engagement. On peut même supposer qu'un employé doit avoir au moins 15 ans. De telles règles du monde réel permettent d'affiner les contrôle d'intégrité des données. La cohérence des données peut s'effectuer entre deux ou plusieurs champs d'une même table, ou provenant de tables différentes. Ce genre de contrôle d'intégrité ne peut intervenir qu'au niveau d'un formulaire, comme on peut le voir sur la figure 66.


65

BA

SE

16.M

DB

Fig. 66 Erreurs entre des clés de différentes tables Ces erreurs peuvent résulter d'une incohérence entre les valeurs d'une clé primaire et d'une clé étrangère. Si une valeur apparaît dans une clé étrangère, elle doit exister dans la clé primaire correspondante. On peut assurer une telle règle en activant le contrôle de l'intégrité référentielle au moment de définir la relation entre les deux tables concernées:

BA

SE

17.M

DB

Fig. 67 Une fois appliquée, l'intégrité référentielle interdit de supprimer un fournisseur si des articles lui sont encore liés. Dans ce cas deux solutions sont possibles:

• Supprimer d'abord les articles de ce fournisseur dans la table ARTICLES, puis ensuite seulement le fournisseur dans la table FOURNISSEURS

• Activer l'option "Effacer en cascade les enregistrements correspondants" _____________________________________________________________________________


Dans ce dernier cas, lors de la suppression d'un fournisseur, Access prévient de l'existence d'articles liés à ce fournisseur et demande confirmation. En cas d'acceptation tous les articles de ce fournisseur seront également supprimés de la table ARTICLES. Prenons un second exemple, dans lequel un enseignant est référencé par un numéro unique (no. DIP) attribué par le Département de l'Instruction Publique. Supposons qu'une école engage un enseignant n'ayant pas encore reçu de no. DIP et qu'un numéro provisoire lui est attribué. Ce numéro sera utilisé dans des relations avec d'autres tables (CLASSES, ECOLES, HORAIRES, etc); que se passera-t-il lorsque le numéro définitif entre en vigueur ? En vertu du contrôle d'intégrité référentielle, Access refusera de changer le numéro de l'enseignant. L'option "Mettre à jour en cascade les enregistrements correspondants" permet une telle mise à jour automatique dans toutes les tables liées à celle des enseignants, pour autant que cette option ait été activée pour chaque relation. L'utilisation de cette option puissante doit toutefois être réfléchie. Prenons le cas d'une société qui licencie un employé auquel sont encore rattachées des commandes clients traitées par lui. Il ne serait pas souhaitable que la suppression de l'employé provoque la suppression en cascade de ses commandes clients. Ces options liées à l'intégrité référentielle doivent être utilisées avec discernement; la logique de l'application doit permettre de décider de leur utilisation ou non. Autres problèmes L'application de mécanismes visant à assurer l'intégrité des données a pour but de protéger les données vis à vis de l'utilisateur de la base de données. Elle ne constitue par un moyen anti vandalisme. Access et la plupart des SGBDR offrent d'autres mécanismes de sécurité limitant l'accès aux différents objets d'une base de données au niveau des utilisateurs ou des groupes d'utilisateurs. Il est par exemple courant que les utilisateurs d'une application base de données aient uniquement accès aux formulaires et non aux tables ou aux requêtes. A quel niveau placer les contrôles d'intégrité Une base de données possède différentes couches. La plus basse est constituée par les tables, viennent ensuite les requêtes, puis les formulaires. Les contrôles d'intégrité placés au niveau des tables se propagent dans les requêtes et les formulaires. En d'autres termes, une sécurité implémentée au niveau d'une table ne peut pas être contournée à un niveau supérieur (requêtes, formulaires). De plus, le contrôle introduit uniquement au niveau d'un formulaire n'est pas étendu à d'autres formulaires. D'une manière générale on peut dire que le contrôle au niveau des tables est préférable, mais bien entendu ce n'est pas une obligation et le choix varie de cas en cas.


67

Construction d'une application base de données Principales étapes Pour terminer, voici les principales étapes à suivre pour construire une application de base de données:

• Identifier les objets existants du monde réel (factures, salles, enseignants…)

• Identifier les relations existantes entre ces objets

• Créer des tables, une par objet

• Créer les relations entre les différentes tables

• Inventorier les formulaires et les états que l'utilisateur devra utiliser

• Créer les requêtes nécessaires au support des formulaires et des états

• Créer les formulaires et les états

• Ajouter les règles d'intégrité

• Créer une interface utilisateur sobre, ergonomique et cohérente de manière que l'application forme un tout

Ces différentes étapes peuvent varier (en importance) en fonction du type d'application à créer. Le dernier point est celui qui fait la différence entre une "base de données" et une "application base de données". Généralement on crée une base de données pouvant être utilisée avec un minimum d'effort et un maximum d'ergonomie; il s'agit donc le plus souvent d'une "application base de données". Interface utilisateur graphique, macros et modules (programmation) La construction d'une application base de données peut être entreprise à plusieurs niveaux et à différents degrés de maîtrise d'Access. Pour illustrer ces approches, choisissons un exemple pouvant être développé à l'aide des trois méthodes:

• En utilisant uniquement l'interface utilisateur graphique (IUG) d'Access (sans aucune programmation d'aucune sorte)

• En faisant appel à des objets appelés "macros"

• En programmant dans le langage VBA (Visual Basic for Application) Cet exemple consiste à construire un formulaire Clients depuis lequel on veut consulter les commandes existantes pour un client donné. Etant donné deux formulaires, Clients et Commandes, on veut pouvoir passer de l'un à l'autre. Le formulaire Clients doit avoir un bouton permettant d'ouvrir le formulaire Commandes. Ce dernier doit montrer uniquement les commandes du client choisi.


68

Méthode 1: Avec le formulaire Clients ouvert en mode création, cliquer sur l'élément "bouton de commande" de la boîte à outils, en prenant soin de vérifier que le bouton "Assistants contrôle" de cette même boîte à outils soit activé. Voici les étapes successives

BA

SE

18.M

DB

Fig. 68 L'assistant demande ensuite de spécifier quel formulaire doit être ou vert:

BA

SE

18.M

DB

Fig. 69


69

Dans la prochaine étape (figure 70) il faut choisir d'ouvrir le formulaire, mais ne pas visualiser tous les enregistrements. Rappelons que nous voulons voir uniquement les enregistrements en rapport avec un numéro de client.

BA

SE

18.M

DB

Fig. 70 Il suffit de choisir quel champ sert de lien entre les deux formulaires: dans notre cas, le champ CliNo:

BA

SE

18.M

DB

Fig. 71


70

L'assistant demande ensuite si l'on désire un bouton contenant du texte ou une image.

BA

SE

18.M

DB

Fig. 72 Enfin il faut indiquer le nom du bouton. Rappelons que chaque composant d'un formulaire doit porter un nom servant à l'identifier. Ce nom n'est pas visible par l'utilisateur, mais peut intervenir lorsque l'on fait appel à des macros ou à la programmation en VBA.

BA

SE

18.M

DB

Fig. 73


71

Au terme de cette série de questions-réponses, le nouveau bouton IUG (généré à l'aide de l'Interface Utilisateur Graphique) est créé:

BA

SE

18.M

DB

Fig. 74 Voici le formulaire qui apparaît lorsque l'on clique sur le bouton IUG:

Fig. 75

On peut constater l'indication "Filtré" dans la partie inférieure de la fenêtre. Cela traduit le fait que nous avons sous les yeux les articles commandés par un client (Pierre Lesage) et non tous les articles de toutes les commandes clients. Par curiosité on peut examiner le fragment de programme généré automatiquement par l'assistant utilisé:


72

BA

SE

18.M

DB

Fig. 76 Cela peut paraître quelque peu hermétique, mais un esprit éveillé peut se faire une idée de la signification de ces instructions. Méthode 2: Nous allons maintenant placer un deuxième bouton sur le formulaire Clients, qui va nous conduire au même résultat que la méthode 1, mais en faisant appel à une macro. Après avoir créé une macro permettant d'ouvrir le formulaire des articles commandés, nous l'affecterons à l'événement "clic" de notre deuxième bouton. Une macro est constituée d'une ou plusieurs actions, choisie parmi une liste de quelques dizaines proposée par Access. Dans notre cas, il faut choisir l'action "OuvrirFormulaire": Pour chaque action, des propriétés apparaissent dans la partie inférieure de la fenêtre. Comme on peut le voir sur la figure 77 nous indiquons le nom du formulaire à ouvrir (CliCommandes) ainsi que la condition spécifiant le lien entre les deux formulaires:

[CliNo]=[Formulaires]![Clients]![CliNo] Cette syntaxe peu accueillante peut être traduite par: "Nous voulons ouvrir le formulaire CliCommandes avec la condition que son champ CliNo doit contenir la valeur du champ CliNo du formulaire Clients".


73

BA

SE

18.M

DB

Fig. 77 Après avoir sauvegardé cette macro sous le nom OuvrirCommandes, reprenons le formulaire Clients en mode création et ajoutons un bouton portant l'inscription "Macro". Mais cette fois nous ne faisons pas appel à l'assistant.

BA

SE

18.M

DB

Fig. 78 Un simple clic sur le bouton "Macro" du formulaire Clients ouvre, comme précédemment, le formulaire des commandes du client courant.


74

Méthode 3: Access est non seulement un SGBDR, mais un programme fonctionnant dans l'environnement Windows. Dans un tel environnement orienté objet la programmation naturelle est une programmation événementielle. Pour résumer en quelques mots cette manière de programmer, on peut dire que "chaque objet peut répondre à divers stimuli qui peuvent être un clic de souris, un changement de contenu, etc". La réponse est en fait l'exécution d'une ou plusieurs instructions de programmation. C'est un raccourci extrême de ce qu'est la programmation événementielle. Elle s'inscrit dans le courant des nouveaux outils de développement RAD dont on peut se faire une idée en consultant l'annexe A "Programmation destructive". Nous allons donc placer un troisième bouton sur le formulaire Clients. Ce bouton porte l'indication "Code" et, en face de son événement "Sur clic" nous choisissons l'option

BA

SE

18.M

DB

Fig. 79 Après avoir cliqué sur le bouton comportant trois points (au-dessus de la flèche de la figure 79) Access ouvre une nouvelle fenêtre:

BA

SE

18.M

DB

Fig. 80 Le nom du bouton étant Code, on comprend grâce aux indications préparées par Access que l'on s'apprête à écrire les instructions devant être effectuées lorsque l'utilisateur va cliquer sur le bouton Code.


75

La commande permettant d'ouvrir le formulaire CliCommandes s'écrit:

DoCmd.OpenForm "CliCommandes" Après avoir pris connaissance de la syntaxe de la commande DoCmd.OpenForm, nous voyons que pour faire le lien avec le numéro de client dans le formulaire Clients, il faut écrire:

BA

SE

18.M

DB

Fig. 81 On reconnaît la condition déjà utilisée dans la macro définie précédemment. Conclusion Nous venons de voir trois méthodes permettant d'atteindre le même résultat. Laquelle faut-il utiliser ? La réponse n'est pas simple et dépend d'une multitude de facteurs:

• Un néophyte choisira probablement la 1ère, mais optera petit à petit pour la 2ème

• Un programmeur expérimenté se lancera dans la 3ème

• Dans un but de mieux se prémunir contre des erreurs d'exécution la 2ème est à proscrire

• Si on dispose d'un certain nombre de routines de programmation réutilisables, la 3ème permet de gagner du temps

• Utiliser la 1ère pour créer un formulaire est acceptable, mais probablement pas pour créer un état complexe d'un point de vue esthétique

Il est clair que l'utilisation des macros offre plus de souplesse que l'utilisation de l'IUG (avec assistants). Il est également évident que la programmation permet quasiment de tout faire, sans pratiquement aucune limitation, alors que les macros sont plus restrictives. Un bon choix consiste à utiliser les assistants pour ce qu'ils savent faire vite et bien, et ensuite de rectifier le tir manuellement en fonction des besoins particuliers.


76

Compléments

Introduction Jusqu'ici nous avons abordé l'essentiel, le minimum vital, des concepts liés aux bases de données en général ainsi que leur implémentation dans Access. Il faudrait multiplier par dix ou vingt le volume de ce cours pour espérer couvrir toutes les fonctionnalités d'Access. D'une part le temps à disposition ne le permet pas, et d'autre part, comme nous l'avons signalé au début du cours, notre approche se veut pratique et favorise les notions les plus couramment utilisées dans le développement en Access. C'est pourquoi un certain nombre de notions, de fonctionnalités, de conseils et d'astuces ont été regroupés dans cette partie "Compléments". Chaque point abordé est directement en rapport avec un ou plusieurs exercices et ne sera pas traité dans tous les détails.

Notion de sauvegarde Une base de données Access peut contenir des tables, requêtes, formulaires, états, macros et modules. Toutes ces informations sont contenues dans le même fichier (avec extension MDB). Ce fichier peut devenir volumineux de plusieurs manières:

• Par l'adjonction de données dans les tables

• Par modification des données ou de n'importe quel élément en mode création. Ainsi des modifications répétées pour cause de tests peuvent facilement faire doubler ou tripler la taille du fichier de la base de données. Dans ces cas, il convient d'effectuer un compactage. Microsoft conseille des compactages fréquents, mais n'a inclus le compactage automatique que dans la version 2000 d'Access

De plus Access n'offre pas d'option de sauvegarde au niveau de la base de données, ce qui peut étonner certains utilisateurs. Le fait de tout placer dans un même fichier est un choix presque philosophique qui offre des avantages et des inconvénients

Contrôle d'accès concurrents aux données Dans le domaine des bases de données il est essentiel de gérer l'accès de plusieurs utilisateurs à une même donnée. Il est en effet très fréquent qu'une base de données soit exploitée dans un environnement réseau avec un risque de collisions inhérent à cette architecture. Access fait une première distinction entre l'accès en mode exclusif ou en mode partagé au niveau d'une base de données. Comme on peut le voir sur la figure 82, Access permet de déterminer le mode d'ouverture par défaut d'une base de données.


77

Fig. 82

Dans certains cas on veut ou on doit ouvrir une base de données en mode exclusif:

• Lorsqu'un utilisateur désire être le seul à accéder aux informations d'une base de données

• Lors de la réparation et du compactage d'une base de données, aucun autre utilisateur ne doit travailler avec la base. Par sécurité ces opérations doivent se faire en mode exclusif

Fig. 83


78

Access peut également gérer les accès concurrents au niveau du formulaire. Chaque nouveau formulaire créé possède une propriété Verrouillage proposant trois possibilités (voir figure 83):

• Aucun: dans ce cas si deux utilisateurs modifient le même enregistrement le choix suivant est proposé par Access lorsque le second utilisateur s'apprête à valider ses modifications:

Fig. 84

• Enregistrement modifié: dans ce cas, dès qu'un utilisateur commence à modifier un enregistrement, celui-ci est bloqué et aucun autre utilisateur ne pourra le modifier. Cependant l'enregistrement bloqué reste visible.

• Général: dans ce cas, tous les enregistrements de la requête ou de la table sous-jacente sont bloqués

Problèmes de langue Quelle différence y a-t-il entre Access en anglais et Access en français ? Mis à part les libellés des menus, le texte dans les assistants, l'aide et les diverses indications affichées par Access, il n'y pratiquement pas de différence à un détail près, mais un détail lourd de conséquences. Dans les requêtes, les macros ou les propriétés diverses, Access français transforme tout en français. Par exemple, si on écrit dans un critère de requête l'expression "is not null", Access la transforme en "Est Pas Null". Cela paraît anodin, normal et même agréable et intelligent. Jusqu'au jour où l'on aborde la programmation en VBA (modules) et l'on s'aperçoit que tout doit être en anglais, même avec Access version française. Ce double langage est un choix stratégique de Microsoft. Il favorise l'utilisateur débutant, mais peut se révéler très gênant pour l'utilisateur confirmé qui doit parfois faire du copier-coller entre des macros et des modules.

Générateur d'expressions Access met à disposition du développeur un générateur d'expressions lui facilitant le travail dans certaines circonstances. Ce générateur est fonctionnel et efficace, mais il n'intéresse généralement pas le développeur chevronné.


79

Voici comment se présente ce générateur:

Fig. 85

Il peut être invoqué le plus souvent lorsqu'un bouton est disponible et offre plusieurs avantages:

• Il offre une liste exhaustive de fonctions, opérateurs ou constantes

• Il contient automatiquement tous les objets de la base de données (tables, requêtes, etc), ainsi que le contenu de ces objets (champs, propriétés, etc)

Création d'un menu général arborescent Il est possible de construire un menu sous la forme d'un formulaire indépendant des données, dans lequel on place des boutons permettant d'ouvrir d'autres formulaires. Toutefois Access propose une solution bien pratique sous la forme d'un "gestionnaire de menu général". Les menus générés sont arborescents. La figure 86 montre le menu principal d'une application et la figure 87 montre le sous-menu obtenu en choisissant la première option du menu principal.


80

Fig. 86

Fig. 87


81

La construction d'un système de menus est quelque peu déroutante au premier abord, mais, une fois le mécanisme compris, la procédure devient logique et naturelle. Voici quelques étapes montrant l'enchaînement des menus et des options en relation avec l'exemple des figures 86 et 87.

Fig. 88

Fig. 89

Fig. 90

Sur la figure 90 on constate que Texte représente le libellé d'une option de menu, Commande propose diverses possibilités dont "Ouvrir formulaire en mode Modification". Le troisième champ


82

(ici Formulaire) varie en fonction de la commande choisie. Dans notre cas l'option de menu "Gestion des domaines" provoque l'ouverture du formulaire fDomaines.

Champs de type OLE Afin d'illustrer l'utilisation d'objets OLE dans les champs d'une table, prenons une base de données comportant la table CLIENTS et ajoutons-lui un champ CliDoc de type OLE.

BA

SE

19.M

DB

Fig. 91 Après la création d'un formulaire instantané basé sur la table CLIENTS, le champ CliDoc est vide.

BA

SE

19.M

DB

Fig. 92


83

Les champs de type OLE constituent une entorse au modèle relationnel qui voudrait que dans un champ se trouvent des informations de même nature. Ce n'est pas le cas ici, puisqu'on peut aussi bien placer dans ce champ un document Word, une image, une séquence vidéo, une feuille Excel, etc. Exemple 1 On désire placer une image de type BMP dans le champs CliDoc du client Jo Lee. Il faut avant tout faire appel à l'option "Insérer objet…" qui provoque l'affichage de la fenêtre suivante:

BA

SE

19.M

DB

Fig. 93 Choisissons le type BitMap Image et l'option Créer nouveau indiquant que nous voulons créer l'image. Après avoir validé ce choix, voici ce qui apparaît:

BA

SE

19.M

DB

Fig. 94


84

On peut directement dessiner dans le champ CliDoc avec les outils et les menus du programme de dessin à disposition. On reconnaît la fenêtre "Base de données" d'Access en arrière-plan. D'ailleurs si on clique sur cette fenêtre, on obtient:

BA

SE

19.M

DB

Fig. 95 Voici le résultat obtenu:

BA

SE

19.M

DB

Fig. 96


85

Un double-clic sur le champ CliDoc invoque le contexte du programme de dessin et permet de modifier instantanément le dessin. Exemple 2 Pour le client Pierre Lesage nous avons inséré un petit clip vidéo qui se met en marche en double-cliquant sur le champ CliDoc.

BA

SE

19.M

DB

Fig. 97 On pourrait étendre les exemples à l'infini, car les objets OLE n'ont pas de limitation, n'importe qui peut créer un nouvel objet OLE.

Et Internet, alors ? Depuis quelques années tous les produits Microsoft doivent impérativement offrir des fonctionnalités en rapport avec Internet. Access offre de multiples possibilités d'importation, d'exportation et d'envoi d'objets par e-mail. Mais intéressons-nous à un type de champ dont nous n'avons pas encore parlé: le type "Lien hypertexte". Voici comment se présente la table CLIENTS après avoir ajouté le champ CliInternet, de type "Lien hypertexte":

BA

SE

19.M

DB

CliNo CliPrenom CliNom CliDoc CliInternet

1 Jo Lee Delphi2 Pierre Lesage http://www.torry.ru3 Jean Lebon c:\horaires\metiers.xls4 Sandra Bu-Loque Form ARTICLES

Fig. 98 Remarque: lorsque le présent document se trouve dans le traitement de texte (Word en

l'occurrence) les liens dans le champ CliInternet sont vivants et actifs.


86

http://www.torry.ru/

http://www.torry.ru/

Un champ de type "Lien hypertexte" n'affiche pas la même information que celle qui a été introduite originellement. Pour le client 1 l'information entrée était:

#Delphi#http://www.torry.ru# et permet d'ouvrir automatiquement la page Internet indiquée Pour le client 2:

#http://www.torry.ru# et permet d'ouvrir automatiquement la page Internet indiquée Pour le client 3:

#c:\horaires\metiers.xls# et permet d'ouvrir le document Excel indiqué Pour le client 4:

Form ARTICLE Et permet d'ouvrir le formulaire ARTICLE de la base de données en cours. Il est également possible d'ouvrir un formulaire d'une autre base de données Il est également possible de spécifier un lien hypertexte au niveau d'un formulaire en tant que propriété d'un objet "Etiquette"

BA

SE

19.M

DB

Fig. 99 Pour terminer, voici comment envoyer un objet Access, dans notre cas un état, sous forme de courrier électronique. L'exemple utilise une macro, mais on peut également utiliser la programmation. Plusieurs formats sont disponibles: HTML, Microsoft Excel, MS-DOS Text, Rich


87

Text Format et Snapshot Format. Nous avons choisit ce dernier format car il offre les meilleurs résultats à condition que le destinataire possède le programme Snapshot Viewer.

BA

SE

19.M

DB

Fig. 100 Voici comment l'objet envoyé peut être visualisé à l'aide de Snapshot Viewer:

Fig. 101


88

Avec ce petit utilitaire, il est possible d'ouvrir un état ou autre fichier de type SNP, d'effectuer des zooms et des impressions.

Tables et autres objets importés Access permet d'importer n'importe quel objet (table, requête, formulaire, etc) en provenance d'une autre base de données. Dès que l'objet est importé, il fait partie intégrante de la base de données en cours. Si un objet portant le même nom existe déjà, Access renomme le nouvel objet en ajoutant un nombre (en partant de 1) à son nom. L'importation d'objets est très utilisée pour des modules standard, faisant office d'outils personnels du développeur. L'importation de tables est particulièrement intéressante, car Access reconnaît beaucoup de format de fichiers et de bases de données:dBase III, dBase IV, dBase V, Excel, Exchange, FoxPro, FoxPro 3.0, HTML, Lotus 1-2-3, fichiers textes de toutes sortes et bases de données ODBC.

Tables attachées Access permet également d'accéder à des tables externes en les attachant à la base de données en cours. Ces tables peuvent être dans différents formats et peuvent avoir des localisations variées. Il est possible d'attacher une table provenant d'une autre base de données ou d'un autre ordinateur en réseau sans aucune limitation si ce n'est au niveau des droits d'accès. Une table attachée est utilisée exactement de la même manière qu'une table locale, bien qu'elle ne fasse pas partie de la base de données en cours, c'est-à-dire qu'elle ne se trouve pas dans le fichier MDB courant. Au cas où des tables devraient être réattachées par suite de déplacement de fichiers, Access dispose d'un "Gestionnaire de tables attachées" grâce auquel il est possible de spécifier l'emplacement des tables liées.

Séparation programme/données La grande majorité des applications Access travaille en dissociant les données pures (tables) des autres éléments (requêtes, formulaires, états, macros et modules). Cette séparation est essentielle; grâce à elle on peut, par exemple, travailler sur la nouvelle version d'une application tout en laissant fonctionner la version courante. Access dispose d'un assistant de fractionnement de base de données bien que cette opération soit d'une simplicité enfantine. En effet, il suffit de:

• faire une copie du fichier MDB à fractionner

• supprimer toutes les tables de la base de données contenue dans l'un des deux fichiers obtenus

• supprimer tout sauf les tables de l'autre base de données

• réattacher les tables


89

Formulaires indépendants des données Tous les formulaires que nous avons rencontrés jusqu'ici possédaient au moins un champ provenant d'une table, avec ou sans requête sous-jacente. Ce n'est pas une obligation. On peut imaginer construire un formulaire qui soit l'équivalent d'un programme de dessin. On peut également construire un formulaire comportant des champs indépendants, comme dans l'exemple suivant. On voudrait calculer le prix d'un séjour, connaissant la durée en jours, le prix journalier, le prix du transport, l'âge du participant, s'il s'agit d'un homme ou d'une femme. Le calcul doit tenir compte des conditions suivantes:

• Les hommes âgés de plus de 65 ans bénéficient d'un rabais total de 10%

• Les femmes âgées de plus de 60 ans bénéficient d'un rabais total de 8%

• Les personnes de plus de 50 ans bénéficient d'un rabais total de 5%

• On doit également pouvoir modifier le rabais La figure 102 montre le formulaire en mode création:

B

AS

E20

.MD

B

Fig. 102 Tous les champs de ce formulaire sont des champs indépendants. Alors que certains portent la mention "Indépendant", d'autres comportent une formule. Le champ Age est indépendant; on peut entrer n'importe quelle information dans sa zone de saisie. Nous avons décidé de le nommer Age pour plus de clarté, et on voit bien que sa propriété Source contrôle est vide.

BA

SE

20.M

DB

Fig. 103


90

Le champ TotSéjour est un champ calculé. Dans notre exemple il contient le produit des valeurs des deux champs placés à sa gauche. La formule de calcul est spécifiée dans sa propriété Source contrôle. Access ne laisse pas entrer d'informations dans ce champ.

BA

SE

20.M

DB

Fig. 104

Voici le formulaire en action:

BA

SE

20.M

DB

Fig. 105 Afin de calculer le bon rabais en fonction de l'âge et du sexe indiqués, nous avons placé du code en réponse à l'événement "Après MAJ" de ces deux champs

Fig. 106

Pour les deux champs le code est celui de la figure 107. On pourrait bien entendu écrire une procédure unique contenant le code à exécuter, et appeler cette procédure depuis les événements Après MAJ des deux champs. L'événement Après MAJ survient lorsque l'on sort du champs et que sa valeur est validée (mise à jour).


91

BA

SE

20.M

DB

Fig. 107

Runtime Access Si une société développe une application base de données avec Access, chaque client à qui elle la vend doit être en possession d'une licence d'utilisation d'Access. L'autre possibilité est que la société distribue son application sous forme de runtime. Les implications sont les suivantes:

• La société doit acheter MS ODE (Microsoft Office Developer Edition) contenant, en plus d'outils divers et d'objets ActiveX, un assistant de création de disquettes de distribution. Sur ces disquettes on trouve une version bridée d'Access, connue sous le nom de "runtime Access"

• Le client qui installe l'application dispose d'une version d'Access fonctionnant, à quelques détails près, comme Access lui-même. Toutefois certaines options de menu, assistants et autres fonctionnalités ne sont pas disponibles. Et il n'est pas possible d'ouvrir une autre base de données que celle installée.

Les développeurs préfèrent travailler le plus possible avec une version complète d'Access et tester leur application avec le runtime seulement en phase finale des tests. En résumé la version runtime permet une économie financière, mais génère de petits désagréments lors de l'utilisation.


92

Recherche dans un formulaire Access offre plusieurs possibilités de recherche et filtrage de données en passant par des options de menu standard ou par des barres d'outils. Dans l'exemple suivant, nous avons un formulaire concernant des livres et nous avons placé un champ rAuteur de recherche par auteur sous forme de liste déroulante. Nous créons d'abord une requête, en prenant soin d'indiquer dans ses propriétés que seuls les "Valeurs distinctes" nous intéressent:

BA

SE

21.M

DB

Fig. 108 Sur la figure 100 on voit le formulaire avec le champ indépendant rAuteur. On peut observer comment la requête ci-dessus est associée au champ de recherche.

BA

SE

21.M

DB

Fig. 109 Il ne reste qu'à se positionner sur le bon livre lorsqu'un auteur est choisi, ce qui peut être effectué à l'aide de la procédure événementielle suivante, exécutée après la mise à jour du champ de recherche.


93

BA

SE

21.M

DB

Fig. 110 Cette procédure consiste à:

• Se positionner dans le champ Auteur

• Rechercher le premier enregistrement de ce champ contenant la valeur de la 1ère colonne (la seule) de la liste des auteurs

Le procédé décrit dans cet exemple n'est pas l'application d'un filtre montrant uniquement les livres de l'auteur cherché. Il s'agit simplement d'un positionnement dans l'ensemble des enregistrements disponibles. Dans notre cas la recherche se positionne sur le premier auteur trouvé. Il convient donc que les enregistrement du formulaire soient triés par ordre alphabétique du nom de l'auteur. De cette manière, après avoir trouvé le premier livre de l'auteur cherché, il suffit de parcourir les enregistrements suivants pour consulter les autres livres éventuels du même auteur. Il faut également remarquer que la recherche aboutit forcément, car les auteurs contenus dans le champ de recherche proviennent justement de la table des livres. Un exercice vous propose plusieurs autres versions de recherches dans un formulaire.

Un exemple de "OLE automation": pilotage d'Excel depuis Access Attaquons-nous à un exercice consistant à placer des valeurs provenant de champs d'une table Access dans les cellules d'une feuille de calcul Excel. Nous allons être confrontés à quelques nouvelles difficultés, car nous allons procéder par programmation. Access offre, par exemple dans les macros, la possibilité d'importer ou d'exporter des données de ou vers Excel, mais de manière trop limitative à notre goût. Nous voulons piloter Excel de manière personnalisée et en "direct". L'exportation sera déclenchée par un bouton de commande placé sur un formulaire. Afin de travailler de manière plus agréable, il est préférable de configurer Access pour qu'il ait connaissance des objets Excel:

• Créer un formulaire analogue à celui des livres de la figure 109, mais sans champ de recherche

• Placer un nouveau bouton avec une icône figurant l'exportation vers Excel (figure 111)


94

BA

SE

21.M

DB

Fig. 111

• Choisir "[Procedure événementielle]" dans l'événement "Sur clic" du bouton, et cliquer sur le bouton . La fenêtre suivante apparaît:

Fig. 112

• Choisir ensuite l'option "Références…" du menu "Outils", puis chercher la ligne "Microsoft Excel 8.0 Object Library" et la marquer d'une coche. La liste des références peut être plus ou moins grande en fonction de la diversité des logiciels et/ou objets ActiveX installés sur l'ordinateur utilisé


95

Fig. 113

• En vue d'obtenir le résultat suivant:

Fig. 114

_____________________________________________________________________________


Ecrire ensuite les instructions suivantes, ce qui est évidemment un jeu d'enfant Const xlLeft = -4131 Sub PutVal(ByRef xl As Object, Y As Integer, X As Integer, valeur As Variant) If Not IsNull(valeur) Then xl.ActiveWorkbook.Sheets(1).cells(Y, X).Value = valeur End If End Sub Private Sub Export_Click() Dim db As Database Dim livre As Recordset Dim fExcel As Object Dim Sortie As String Dim ligne As Integer Set db = CurrentDb() Set livre = db.OpenRecordset("Stock", DB_OPEN_DYNASET) Set fExcel = CreateObject("Excel.Application") Sortie = "Livres.xls" fExcel.Visible = True ' on veut voir travailler Excel fExcel.Workbooks.Add fExcel.ActiveWorkbook.SaveAs FileName:=Sortie ' on indique le nom du fichier ' Elargissement des 4 première colonnes fExcel.Columns("A:A").Select fExcel.Selection.ColumnWidth = 15 fExcel.Columns("B:B").Select fExcel.Selection.ColumnWidth = 35 fExcel.Columns("C:C").Select fExcel.Selection.ColumnWidth = 25 fExcel.Columns("D:D").Select fExcel.Selection.ColumnWidth = 12 ' Justification à gauche de la 1ère colonne fExcel.Columns("A:A").Select fExcel.Selection.HorizontalAlignment = xlLeft ' Changement d'écriture pour les entêtes de colonnes fExcel.Range("A2:D2").Select fExcel.Selection.font.bold = True fExcel.Selection.font.Size = 11 ' Affichage d'un titre Call PutVal(fExcel, 1, 1, "Liste des livres en provenance d'Access") Call PutVal(fExcel, 2, 1, "ISBN") Call PutVal(fExcel, 2, 2, "Titre") Call PutVal(fExcel, 2, 3, "Auteur") Call PutVal(fExcel, 2, 4, "Prix") ligne = 3 livre.MoveFirst ' 1er enregistrement Do Until livre.EOF Call PutVal(fExcel, ligne, 1, livre!ISBN) Call PutVal(fExcel, ligne, 2, livre!titre) Call PutVal(fExcel, ligne, 3, livre!auteur) Call PutVal(fExcel, ligne, 4, livre![prix de vente]) livre.MoveNext ' enregistrement suivant ligne = ligne + 1 Loop fExcel.Quit ' si on supprimer cette ligne, Excel reste ouvert livre.Close End Sub

Fig. 115


97

Une méthode permet de gagner du temps dans l'écriture de ces instructions. Il suffit d'ouvrir Excel, de créer une nouvelle macro et d'enregistrer les actions désirées. Après arrêt de la macros, il est possible de l'éditer en d'en recopier les instructions dans le module de programmation d'Access. On peut absolument tout faire en pilotant une application externe depuis Access, mais on constate que cela implique la connaissance exacte du fonctionnement de l'application pilotée.

Comme souvent en informatique, on peut tout faire, il suffit d'apprendre à le faire.


98

Annexe A: PROGRAMMATION DESTRUCTIVE

Introduction Il y a quelques années, c'est-à-dire au moment de l'apparition de Visual Basic 1.0, le développement d'applications dans l'environnement Windows a subit de profondes modifications. On est passé de la programmation constructive à la programmation destructive:

Programmation

destructive (paradis)

Programmation constructive

(enfer)

Fig. A.1

Voyons quel était le calvaire réservé au programmeur avant l'apparition des outils magiques qui ont pour nom Visual Basic, Delphi, C++ Builder, Visual Age, Access, PowerBuilder, etc.

L'enfer Quelques faits caractérisant l'enfer:

• Windows est un système d'exploitation complexe (plus complexe que DOS)

• Seuls les programmeurs chevronnés et maîtrisant le langage C peuvent développer des applications Windows

• Ecrire un programme qui affiche "bonjour" dans une fenêtre nécessite plusieurs dizaines de lignes

• Très peu de programmeurs Windows sont capables d'écrire un programme qui ne fait rien (affichage d'une fenêtre uniquement). Car un programme qui ne fait rien est déjà très long

• La programmation dans un environnement de type "objet" à l'aide d'outils qui ne le sont pas tient du paradoxe, que Microsoft à exploité pendant plusieurs années

• Le fonctionnement de Windows est de type multitâches et il est entièrement régi par des événements. La programmation doit être événementielle

• Pour écrire un programme il faut obligatoirement passer par une longue phase d'apprentissage (plusieurs mois dans les meilleurs cas).

• Dès que le programmeur se heurte à un problème, il se peut qu'il soit obligé de compléter sa formation au moyen de documentations adéquates (help, livres, internet, etc)

• Pour programmer dans Windows il faut utiliser les fonctions que Microsoft met à disposition: plusieurs centaines de fonctions ayant une


99

multitude de paramètres, plusieurs centaines de messages, de constantes prédéfinies, de cas particuliers…

• De temps à autre (vers 1985 au rythme d'environ tous les ans) Microsoft offre à ses chers développeurs de nouveaux outils ou de nouvelles technologies (Windows SDK, MAPI, TAPI, FPSDK, MPC, MIDI, WING, GameSDK, RDO, RDC, COM, DCOM, ADO, DDE, OLE, OLE2, ActiveX, Direct 2D, Direct 3D, IIS, IEADK, ISAPI, J++, VBS, et des dizaines d'autres)

• Actuellement, le rythme auquel apparaissent ces nouveauté est infernal: quasiment hebdomadaire

• Chacune de ces nouveautés peut demander des mois de familiarisation à un programmeur. Mais entre temps d'autres nouveautés apparaissent.

• Le système ne pousse pas le programmeur à être curieux et inventif

• Le programmeur maîtrise généralement un sous-ensemble des outils qui lui sont proposés. Lorsqu'il a besoin d'une implémentation qu'il ignore, sont seul recours est la lecture et/ou la recherche pénible d'informations. Il construit son savoir

• Le développement tient plus de l'esclavage que de la création

• Les choix des programmeurs sont:

• Le doute

• La dépression

• Le suicide

• Le changement de profession

• L'acharnement dû à un optimisme démesuré

• Le repentir

• La situation n'est vraiment plus vivable. La programmation n'est plus supportable pour un être humain. Seules certaines grandes sociétés peuvent résister

Le paradis Mais voilà la programmation destructive qui pointe son nez. Une vraie bouée de sauvetage pour le programmeur "normal". Grâce à elle, un débutant peut au bout de quelques minutes, créer un programme avec des caractéristiques qu'un programmeur confirmé mettrait des jours à inclure.

Mais voyons pourquoi et comment ces environnements dits "visuels" ou RAD (Rapid Application Development) permettent de quitter un enfer insupportable et de rejoindre un paradis virtuel, visuel, doré. Nous verrons plus loin que ce paradis a tout de même quelques nuages (Windows oblige).

Un exemple valant mieux qu'un long discours, voici deux listings. Le premier, presque une centaine de lignes, programmation constructive, représente un programme qui ne fait autre qu'afficher une fenêtre. Il est écrit avec Delphi et utilise uniquement des moyens traditionnels. Ce programme est tiré du livre "Delphi 2 secrets d'experts" de Charles Calvert:


100

program Window1; { Standard Windows API application written in Object Pascal. No VCL code included. This is all done on the Windows API level. Note that you need to include both Windows and Messages!} uses Windows, Messages; const AppName = 'Window1'; function WindowProc(Window: HWnd; AMessage, WParam, LParam: Longint): Longint; stdcall; export; begin WindowProc := 0; case AMessage of wm_Destroy: begin PostQuitMessage(0); Exit; end; end; WindowProc := DefWindowProc(Window, AMessage, WParam, LParam); end; { Register the Window Class } function WinRegister: Boolean; var WindowClass: TWndClass; begin WindowClass.Style := cs_hRedraw or cs_vRedraw; WindowClass.lpfnWndProc := @WindowProc; WindowClass.cbClsExtra := 0; WindowClass.cbWndExtra := 0; WindowClass.hInstance := HInstance; WindowClass.hIcon := LoadIcon(0, idi_Application); WindowClass.hCursor := LoadCursor(0, idc_Arrow); WindowClass.hbrBackground := HBrush(Color_Window); WindowClass.lpszMenuName := nil; WindowClass.lpszClassName := AppName; Result := RegisterClass(WindowClass) <> 0; end; { Create the Window Class } function WinCreate: HWnd; var hWindow: HWnd; begin hWindow := CreateWindow(AppName, 'Object Pascal Window', ws_OverlappedWindow, cw_UseDefault, cw_UseDefault, cw_UseDefault, cw_UseDefault, 0, 0, HInstance, nil); if hWindow <> 0 then begin ShowWindow(hWindow, CmdShow); UpdateWindow(hWindow); end; Result := hWindow; end; var AMessage: TMsg; hWindow: HWnd; begin if not WinRegister then begin MessageBox(0, 'Register failed', nil, mb_Ok); Exit; end; hWindow := WinCreate; if hWindow = 0 then begin MessageBox(0, 'WinCreate failed', nil, mb_Ok); Exit; end; while GetMessage(AMessage, 0, 0, 0) do begin TranslateMessage(AMessage); DispatchMessage(AMessage); end; Halt(AMessage.wParam); end.

Fig. A.2


101

Voici maintenant l'équivalent en Delphi version RAD. Pour mieux saisir la différence, le listing est encadré:

Fig. A.3

Oui, vous avez bien vu!! Il n'y a rien. Et ce rien fait la même chose que le premier listing. Si, de plus, on voulait écrire "Bonjour" en fonte Arial 12 pt rouge au centre de la fenêtre et avoir une fenêtre avec fond bleu, sans bord, le premier listing verrait son volume doubler ou tripler, alors qu'en Delphi RAD on n'aurait toujours aucune ligne de code.

Y a-t-il mystère ou miracle ? S'agit-il d'une tromperie ? La complexité est-elle cachée ailleurs ?

En réalité il n'y a aucun miracle. La difficulté de la programmation constructive est déplacée, encapsulée. L'équivalent du code du premier listing est bien entendu contenu dans l'exécutable lié au second listing; il est simplement masqué.

Dans des outils comme Delphi ou Access, le gagnant est le développeur qui peut se concentrer plus efficacement sur l'algorithmique du développement. Toutefois, si le besoin s'en fait sentir, il est toujours possible de programmer, localement ou globalement, à un niveau plus bas.

Voici quelques caractéristiques de la programmation destructive:

• Par défaut chaque objet fonctionne de manière standard, prévue par l'environnement de développement

• Si une caractéristique ne convient pas au programmeur, il peut la changer. Il détruit donc ce qui lui est proposé et le remplace par ce dont il a besoin

• Le programmeur peut enfin devenir créatif, curieux et acteur

• Généralement les propriétés et les méthodes associées aux différents objets sont visibles. Il suffit de regarder autour de soi; tout est disponible. Fini le temps où il fallait des heures pour trouver comment modifier telle ou telle propriété

En conclusion on peut dire que la programmation destructive met fin à une absurdité et rétablit la réalité et le bon sens, à savoir que:

Il est impossible de rechercher quelque chose dont on ignore l'existence.


102

Les nuages La facilité apparente d'utilisation de la programmation destructive à un revers, un prix à payer. Par exemple:

• Un programme en RAD est généralement plus volumineux à fonctionnalités égales. L'exécutable du premier listing fait 9 Koctets, alors que celui du second fait 153 Koctets. La partie programmation d'une base de données Access peut atteindre facilement une taille de quelques Moctets, alors que son équivalent en programmation traditionnelle serait certainement plus compact

• Certains considèrent qu'il peut y avoir perte d'efficacité et de précision

• Le programmeur peut avoir l'impression que le contrôle de son programme lui échappe quelque peu

Conclusion Chacun fait comme il l'entend, mais la programmation destructive (y compris les outils RAD et les L4G) est en marche et ne s'arrêtera que lorsqu'un nouveau concept simplificateur prendra le relais. Il y aura toujours des programmeurs qui regrettent le temps des cartes perforées, car le changement demande évidemment plus d'efforts que l'immobilisme.


103

Documents

Bases de données relationnelles avec Accesspasseport.univ-lille1.fr/site/initiatic/BASE_DE_DONNEES-_ACCESS/... · Système de Gestion de Bases de Données Relationnelles (SGBDR)