Tutorial Access 2007 gratuit en pdf


Télécharger Tutorial Access 2007 gratuit en pdf
44 étoiles sur 5 a partir de 1 votes.
Votez ce document:

Télécharger aussi :


Guide d'introduction a access 2007 de A a Z

...

Présentation de notre cas pratique de base de données relationnelle

Restons dans le milieu de la montagne : après la liste de données de matériel d’alpinisme, nous voici chargés de bâtir une base de données relationnelle sous Access ou Base dans une école d’alpinisme, à Chamonix. Cette base aura pour objectif de gérer les inscriptions et les activités de l’école :

  • manipuler les informations relatives aux stagiaires et à leurs inscriptions aux différentes activités (les lister, savoir qui fait quoi, etc.) ;
  • manipuler les informations relatives aux guides chargés d’animer les activités (les lister, savoir qui encadre qui, etc.).

Cette base devra pouvoir lister les stagiaires d’une activité, les stagiaires d’un guide, les activités d’un stagiaire, ainsi que d’autres éléments statistiques, comme tous les stagiaires inscrits à plusieurs activités.

Bien évidemment, l’organisation de l’école est déterminante dans la structure des futures tables de notre base. Nous réunissons ainsi les éléments suivants au cours des rencontres avec les différents responsables de l’école :

  • Les stagiaires peuvent s’inscrire à des activités encadrées par des guides.
  • Chaque activité a un et un seul guide attitré.
  • Il existe des guides sans affectation auxquels l’école fait appel en cas de défaillance du titulaire (guide de secours).

Tous ces éléments sont indispensables et influent d’une façon déterminante sur l’organisation des tables à adopter. Il est très important à ce niveau de l’étude d’être exhaustif sur les détails de l’organisation de cette école. Cela ne posera aucun problème si nous sommes nous mêmes le directeur de cette école, mais ce sera plus délicat si nous en sommes totalement extérieur. En effet, si nous omettons ou négligeons un élément quelconque lors de cette phase, la solution à laquelle nous arriverons pourrait ne pas fonctionner. À titre d’exemple, et sans entrer trop dans le détail, notre future base ne comportera pas le même nombre de tables s’il n’y a qu’un et un seul guide par activité ou si, au contraire, une activité peut être encadrée par plusieurs guides ; si nous choisissons la mauvaise hypothèse, il ne sera pas possible de revenir en arrière, et nous aurons travaillé pour rien.

L’ensemble des informations que nous venons ainsi de réunir constitue ce qu’on appelle un cahier des charges. Il est ici très simplifié mais, dans la réalité, il n’est pas nécessairement plus complexe. Même si cet ouvrage n’est pas spécifique à ce thème, nous pouvons tout de même noter quelques points importants. Un cahier des charges comprend d’abord un descriptif détaillé de ce qu’on appelle l’existant, c’est-à-dire l’organisation. Il comprend ensuite un exposé exhaustif de ce que la base de données relationnelle devra permettre de réaliser. Il est important de noter à cette étape qu’une erreur ou une omission dans l’une ou l’autre de ces parties peut conduire à un échec du projet.

Bâtir le schéma théorique de la base de données relationnelle

Le schéma théorique de notre future base découle directement d’une information que nous avons recueillie : les stagiaires s’inscrivent à des activités encadrées par des guides. Cette phrase peut se décomposer comme suit : « les stagiaires » « s’inscrivent à » « des activités » « encadrées par »

« des guides ». Ce schéma est illustré par la figure 6–1. Nous le qualifions de « théorique » parce qu’il ne correspond pas, comme nous le verrons par la suite, au schéma réel, mais il en est le point de départ.

Les éléments de modélisation que nous présentons ici sont inspirés de la méthode Merise, référence en la matière. Si vous souhaitez plus de précisions, reportez-vous à l’annexe spécifique page 333.

6 – La modélisation d’une base de données relationnelle

D’Excel à Access

Stagiaires Activités Guides

S’inscrivent Encadrées

Figure 6–1 à par

Les stagiaires s’incrivent à des activités encadrées par des guides

Vous remarquez que ce schéma théorique comporte des rectangles et des cercles. Pourquoi cette distinction ? Parce que comme nous le verrons dans l’étude du schéma réel, tous les rectangles deviendront des tables, alors que ce ne sera le cas que pour certains cercles.

L’établissement de ce schéma théorique présente quelques difficultés que nous allons lever.

Déterminer les éléments du schéma théorique avec la phrase clé

Il n’est pas évident, quand on débute en modélisation, de trouver tout de suite le bon schéma théorique. Nous venons dans notre cas pratique de le déduire de la phrase « les stagiaires s’inscrivent à des activités encadrées par des guides ». Cette phrase est ce que nous allons appeler la phrase clé ; elle caractérise l’organisation des éléments dont nous devons nous occuper et ne peut s’établir qu’après avoir pris en compte le fonctionnement du système à modéliser. Listons-en d’autres dans des contextes différents :

  • Pour un vidéo club : « Les clients empruntent des DVD appartenant à différentes catégories (humour, action, thriller...) ».
  • Pour une banque : « Les clients possèdent des comptes dans lesquels ils réalisent des opérations financières ».
  • Pour un théâtre : « Les spectateurs réservent des places pour la représentation d’un spectacle ».

La plupart du temps, une phrase clé bien formulée alterne des mots ou groupes de mots (« stagiaires », « activités » et « guides ») avec des formulations verbales (« s’inscrivent à », « encadrées par »).

En général, la phrase clé s’énonce facilement et logiquement. Mais ce n’est pas toujours le cas. Prenons l’exemple de la banque. On pourrait formuler la phrase clé comme suit : « Les clients réalisent des opérations financières qui s’enregistrent sur des comptes » au lieu de « Les clients possèdent des comptes dans lesquels ils réalisent des opérations financières ». Ces deux formulations aboutiraient à deux schémas théoriques différents. La première est erronée, car elle sous-tend que les clients sont titulaires des opérations (alors qu’ils ne sont titulaires que des comptes). Il est difficile de contourner ce type de difficulté si on n’en a pas l’habitude. La seule règle qu’on pourrait donner en la matière est de rester logique et de remarquer, dans l’exemple, que le client est titulaire du compte et que le client n’est destinataire du mouvement que parce que ce mouvement est affecté à un compte dont le client est le titulaire.

Individualiser les éléments de la phrase clé

L’individualisation des éléments de la phrase clé, qui va permettre de déduire les éléments du schéma théorique, consiste au découpage de cette phrase.

Ce découpage est en général facile. Il suffit de mettre en valeur l’articulation syntaxique de la phase clé en groupant les mots comme nous venons de le faire : « les stagiaires » « s’inscrivent à » « des activités » « encadrées par » « des guides ».

Pour les deux premiers exemples complémentaires, le découpage devient respectivement :

  • « Les clients » « empruntent » « des DVD » « appartenant à »

« différentes catégories (humour, action, adulte...) » ;

  • « Les clients » « possèdent » « des comptes » « dans lesquels ils réalisent » « des opérations ».

Le découpage de la phrase clé du théâtre est, lui, un peu plus compliqué. La solution est « les spectateurs » « réservent » « des places » « pour »

« une représentation » « d’un » « spectacle ». Un mauvais découpage serait par exemple « les spectateurs » « réservent » « des places » « pour »

« une représentation d’un spectacle », en groupant « représentation » et

« spectacle », ce qui aurait pour conséquence de n’autoriser d’une seule représentation de tout spectacle.

Caractériser les éléments de la phrase clé

Certains éléments précédemment individualisés vont devenir des rectan-gles de notre schéma théorique, d’autres deviendront des cercles :

  • Les mots ou groupes de mots (dans notre cas pratique « stagiaires », « activités » et « guides ») vont devenir les rectangles du schéma théo-rique. Tous deviendront donc des tables dans le schéma réel.

Éviter les principaux pièges du schéma théorique

L’expérience prouve que deux erreurs type sont à l’origine des schémas théoriques faux, à savoir ajouter des éléments inutiles ou créer un schéma en boucle.

Ne pas créer d’élément inutile

Le désir de bien faire et d’ajouter des éléments inutiles peut entraîner des erreurs de conception du schéma théorique.

Dans notre cas pratique, intéressons-nous aux guides de secours. Vous avez certainement remarqué que notre schéma théorique de la figure 6–1 ne comporte qu’un seul élément Guide, sans aucune référence visible aux guides de secours. Nous serions-nous trompés ?

Heureusement, non. À bien y réfléchir, un guide de secours est avant tout un guide ; sa seule caractéristique est de ne pas avoir d’affectation. Les guides de secours seront donc enregistrés dans la même table que leurs collègues, il sera ainsi facile de lister tous les guides de l’association. Le seul inconvénient de cette solution serait de ne pas pouvoir retrouver les guides de secours au milieu des guides ayant une affectation ; nous verrons plus loin (page 262) que cette crainte n’a pas lieu d’être  puisqu’une simple requête (de non correspondance en l’occurrence) liste sans difficulté ces guides sans affectation.

Si nous différenciions, à tort, les guides normaux des guides de secours dans notre schéma théorique, nous serions confrontés à plusieurs incohé-rences. Tout d’abord, comment rattacher l’élément Guides de secours au reste du schéma, en particulier aux Activites puisque, justement, ils n’en encadrent pas ? La seule solution serait d’utiliser un nouveau lien verbal abstrait (un cercle) qui pourrait se formuler ainsi : « Pourraient être enca-drées par », ce qui manque pour le moins de précision (figure 6–3) !

Cette solution obligerait à passer constamment les guides d’une table à l’autre. Dès qu’un guide de secours trouverait une affectation, il faudrait le supprimer de la table Guides de secours pour le saisir dans les Guides et inversement. Il serait alors techniquement très difficile d’obtenir une liste complète de tous les guides de l’association.

ALLER PLUS LOIN  D’autres exemples d’éléments inutiles dans un schéma théorique

 Le risque de créer des éléments inutiles dans un schéma théorique de modélisation de base de données relationnelle se rencontre fréquemment.

Prenons l’exemple d’une banque dans laquelle les clients possèdent des comptes. Supposons que ces comptes soient de deux types : les comptes rémunérés et ceux qui ne le sont pas. Il est tentant ici aussi de créer deux éléments distincts dans notre schéma théorique, Comptes rémunérés et Comptes non rémunérés, sous prétexte que les caractéristiques des uns ne sont pas celles des autres.

Mais à bien y réfléchir, ce n’est pas exact. Ces deux types de comptes ont tous deux un titulaire, un numéro, une adresse fiscale, etc. De plus, on peut très bien considérer que les comptes non rémunérés sont en fait rémunérés à 0%. Cette solution permet de mélanger dans le même élément Comptes les deux types de comptes ; le champ Pourcentage de rémunération permettant alors de les distinguer. Inversement, créer deux éléments distincts dans le schéma théorique générera de multiples difficultés de programmation, comme lister tous les comptes rémunérés ou non d’un même client.

Ne pas créer un schéma théorique en boucle

Il peut être tentant, en voulant bien faire, de construire le schéma théo-rique de la figure 6–4. Le lien complémentaire entre Stagiaires et Guides, servant à bien matérialiser qu’un guide est en relation avec un stagiaire.

Figure 6–4

Un schéma théorique en boucle est le plus souvent erroné.

C’est là encore inutile : les stagiaires sont déjà en relation avec les guides, parce qu’ils sont inscrits à une activité qui est encadrée par un guide.

De plus, la programmation du schéma en boucle pourrait parfaitement autoriser l’incohérence suivante : affecter, d’un côté, un stagiaire (par exemple Amélie) à une activité qui est animée par tel guide (Paul), en même temps que l’on déclare, de l’autre, que le guide qui s’occupe d’Amélie est Pierre. La porte serait alors ouverte à toutes les confusions.

Vous trouverez en annexe dans l’exercice de l’école de parapente (page 334) un contre-exemple à cette règle (comme on dit, l’exception fait la règle !).

Déduire le schéma réel du schéma théorique

Le schéma théorique comporte certains éléments qui ne deviendront pas des tables dans le schéma réel. Cela se fait bien entendu selon des règles précises que nous allons expliquer ici. Ensuite, nous construirons nos tables en déterminant les différents champs, parmi lesquels nous choisirons bien évidemment une clé primaire, et organiserons les relations les unissant. Nous obtiendrons alors le schéma réel définitif qui pourra servir de socle à la programmation de notre base.

Déterminer définitivement les tables du schéma réel

Quels sont les éléments du schéma théorique qui vont devenir des tables dans le schéma réel et quels sont ceux qui n’en deviendront pas ? La réponse à ces questions passe par une notion qui peut sembler bien mystérieuse, le nombre clé. Pourtant, il vous faudra moins de temps pour l’appliquer que pour assimiler les explications qui suivent.

La figure 6–5 illustre le nouveau schéma intégrant ces nombres clés pour notre cas pratique. Les nombres clés sont les nombres figurant à côté de chaque trait unissant un rectangle à un cercle. Ils peuvent avoir deux valeurs, 1 ou N (c’est-à-dire supérieur à 1). Le tableau suivant résume la signification de chaque nombre clé dans notre cas pratique.

Figure 6–5

Le schéma théorique complété des nombres clé

ALLER PLUS LOIN  D’autres nombres clés

Quelle serait la signification d’autres nombres clés dans le schéma de la figure 6–5 ?

  • Si le nombre clé entre Stagiaires et S’incrivent à était 1, cela signifierait qu’un sta-giaire ne peut s’inscrire qu’à une seule activité.
  • Si le nombre clé entre Activités et S’incrivent à était 1, cela signifierait qu’une activité ne peut compter qu’un seul inscrit et qu’il s’agit donc d’un cours particulier.
  • Si le nombre clé entre Activités et Encadrées par était N, cela signifierait qu’une acti-vité peut être encadrée par plusieurs guides en même temps.
  • Si le nombre clé entre Guides et Encadrées par était 1, cela signifierait qu’un guide ne peut encadrer qu’une et une seule activité.

Ces différences auront un impact immédiat sur le dessin final de la structure des tables de la base.

...

Établir les relations entre les tables

L’établissement des relations entre les tables est la dernière étape dans la transformation de notre schéma théorique en schéma réel, celui qui ser-vira de socle à la programmation de notre base de données relationnelle.

Lorsque nous avions réfléchi sur la relation à établir entre les tables Ventes et Représentants (page 95), nous avions conclu qu’il suffisait d’ajouter le champ Représentant (clé primaire de la table Représentants) à la table Ventes créant ainsi la relation entre la table maître Représen-tants et son esclave Ventes.

Dans une base de données relationnelle, il est en général possible d’ajouter des champs à des tables existantes. Cet ajout est tout de même à éviter, parce qu’il obligera à reprendre les différents formulaires, requêtes et états/rapports qui dépendent de la table ainsi modifiée. C’est pourquoi il vaut mieux créer ces champs dès le début.

Par contre, il est toujours plus compliqué d’ajouter des tables. Dans le pire des cas, par exemple si nous oublions la table Inscriptions dans notre cas pratique, il sera impossible de l’insérer sans supprimer une bonne partie de ce que nous aurons déjà fait. Et dans un cas plus simple, comme l’ajout d’une table spécifique pour les bureaux des guides (ce que nous serons d’ailleurs obligés de faire si nous travaillons avec Base, voir page 164), il faudra de toutes façons reprendre toute la hiérarchie des formulaires, requêtes et états / rapports déjà créés qui dépendront de cette nouvelle table.

D’où l’importance de la phase de modélisation que nous menons actuellement.

6 – La modélisation d’une base de données relationnelle

 Le schéma est exactement le même pour les trois relations à établir entre les quatre tables de notre cas pratique :

  • Pour lier Stagiaires et Inscriptions, il suffit d’ajouter le champ NumSta-giaire (clé primaire de la table Stagiaires) à la table Inscriptions. La table Inscriptions devient alors esclave de la table Stagiaires, ce qui corres-pond à la réalité logique : on ne peut inscrire un stagiaire que s’il existe.
  • Pour lier Activites et Inscriptions, il suffit d’ajouter le champ NomActivite (clé primaire de la table Activites) à la table Inscrip-tions. Inscriptions devient alors esclave d’Activites, ce qui correspond à la réalité logique : on ne peut inscrire un stagiaire à une activité que si cette dernière existe dans la table Activites.
  • Pour lier Activites et Guides, il suffit d’ajouter le champ NumGuide (clé primaire de la table Guides) à la table Activites. Activites devient alors esclave de Guides, ce qui correspond à la réalité logique : on ne peut affecter à une activité qu’un guide existant dans la table Guides.

Nous arrivons ainsi au schéma réel définitif de la figure 6–11.

La plupart du temps, comme dans notre exemple, il est aisé de déter-miner quel champ intégrer à une table pour la relier à une autre. La simple logique suffit. Il existe cependant deux règles simples pour s’y retrouver à coup sûr dans des cas plus complexes :

  • Toutes les tables issues d’un cercle (avec des nombres clés valant N) deviennent esclaves des tables issues des rectangles auxquels elles

Figure 6–11

Le schéma réel définitif de notre cas pratique comporte les quatre tables (avec leurs champs dont un est clé primaire) et les relations qui les unissent.

Notre méthode de modélisation fonctionne pour n’importe quelle problématique de base de données relationnelle, quelque soit le SGBDR qui servira de support à la programmation : Access, Base, ou autre.

étaient reliées. Les relations s’établissent alors en intégrant dans ces tables les champs clé primaire de leurs maîtres. Dans notre cas pratique, la table Inscriptions, issue d’un cercle, devient esclave de Stagiaires et d’Activites et la relation s’établit en insérant dans cette table les champs clé primaire des deux tables maîtres.

  • Dans le cas d’un cercle (un des nombres clés vaut 1), la relation s’éta-blit directement entre les deux tables issues des rectangles auxquels il est relié. C’est le cas pour le cercle Encadrées par : la relation s’établit entre Activites et Guides. C’est alors la table issue du rectangle du côté duquel le nombre clé est 1 qui devient esclave de l’autre table ; et c’est le champ clé primaire de cette autre table qui est inséré dans la table esclave pour créer la relation. Dans l’exemple, c’est le champ clé primaire de la table Guides qui est inséré dans la table esclave Activites, issue du rectangle du côté duquel le nombre clé était 1.

L’élaboration du schéma réel clôt la phase de modélisation. Nous sommes maintenant armés pour aborder sereinement la phase de développement de notre projet sous Access ou Base.

Les principales étapes de la programmation d’Access et de Base

L’étude des techniques de modélisation vous a certainement convaincu, si ce n’était déjà fait, de la nécessité d’adopter une méthode de travail structurée pour concevoir et programmer une base de données relationnelle sous un SGBDR comme Access ou Base. La programmation proprement dite de la base de données relationnelle qui va faire l’objet des chapitres suivants doit également être structurée. Avant de nous y attaquer, profitons de l’occasion pour en présenter l’articulation générale. La figure 6–12 détaille le schéma général de cette méthode de travail.

Étape 1 : programmer les tables

Cette phase est essentielle, elle conditionne la réussite de l’ensemble du projet (rappelez-vous la comparaison que nous avons faite entre une base de données relationnelle et un château de cartes). Disons-le tout net : des tables mal conçues ne vous poseront que des problèmes.

La création de chaque table implique bien évidemment celle de chacun de leurs champs et de leurs caractéristiques (type du champ, format, liste de choix, valeur par défaut, etc.) ainsi que la détermination de sa clé primaire.

Étape 2 : établir les relations

L’établissement des relations entre les tables maîtres et leurs esclaves permet d’assurer le bon fonctionnement du modèle relationnel du SGBDR. Elle comprend aussi l’établissement de l’intégrité référentielle. Ce concept un peu mystérieux est en réalité très simple ; il ne s’agit que de s’assurer que chaque enregistrement d’une table esclave est toujours en relation avec l’enregistrement correspondant de la table maître. Dans notre cas pratique, l’intégrité référentielle interdira par exemple de supprimer l’enregistrement d’un guide de la table Guides s’il encadre une activité.

Cette étape est absolument fondamentale. L’expérience prouve que toutes les difficultés que l’on peut y rencontrer sont, presque toujours, la conséquence directe d’une erreur de conception ou de programmation des tables (qui trouve sa source dans un schéma réel erroné). L’établissement des relations et de l’intégrité référentielle peut ainsi être considérée comme une validation de la structure des tables d’une base de données relationnelle.

Étape 3 : saisir les données

Une erreur classique en matière de programmation de SGBDR consiste à saisir des données dans les tables au fur et à mesure de leur création. Par saisir directement les données de cette table pour « voir si ça marche ». C’est une mauvaise pratique. Imaginez si, lors de la construction d’une maison, le peintre venait peindre un pan de mur alors que les maçons n’ont pas encore terminé de monter les autres murs ? L’établissement des relations valide la création des tables et constitue en quelque sorte, pour rester dans notre métaphore, la mise hors d’eau de notre maison.

Il est donc très vivement conseillé de ne commencer la saisie des données d’une base que lorsque l’ensemble des tables et relations ont été validées. Cela dit, vous trouverez peut-être des personnes qui vous diront qu’elles n’en ont rien fait et que tout s’est très bien passé.

Étape 4 : programmer formulaires, requêtes et états/rapports

Pour un peintre, la dernière touche de pinceau met un point final au tableau. Sans cet ultime détail, il est inachevé. Est-ce à dire que toute l’œuvre s’y trouve résumée ? Non, bien entendu. Ce coup de pinceau ne fait que parachever tout le travail, toutes les émotions, toute la force que l’artiste a voulu transcrire. Et la cohérence même de l’œuvre rend cette dernière touche presque naturelle, inévitable, simple.

C’est la même chose pour une base de données : avec des tables et des relations correctement bâties et validées, les requêtes, les formulaires et les états, sauf dans quelques cas très complexes, ne seront la plupart du temps qu’un jeu d’enfant.

ET SI... Et si je ne suis pas l’ordre logique de ces phases ?

Prendre le problème dans le désordre, c’est un peu comme essayer de monter un château de cartes en Camargue un jour de mistral : il vous faudra plus d’une fois tout reprendre à zéro.

Synthèse : modélisation et méthode de programmation d’un SGBDR

La phase initiale de modélisation, préalable et indispensable à la programmation d’un SGBDR, permet de déterminer la structure des tables de la base de données, avec leurs champs et leur clé primaire, et des relations qui les unissent.

 Elle passe par l’élaboration successive d’un schéma théorique puis d’un schéma réel. Les principales phases en sont rappelées ci-dessous :

1 Schéma théorique :

– formalisation de la phrase clé, par exemple « les stagiaires s’inscrivent à des activités encadrées par des guides » ;

– création du schéma théorique, composé de rectangles (dans l’exemple, Stagiaires, Activites et Guides) et de cercles (toujours dans l’exemple, S’inscrivent à et Encadrées par).

2 Schéma réel :

– détermination des nombres clés 1 ou N ;

– tous les rectangles du schéma théorique deviennent des tables ;

– seuls les cercles dont tous les nombres clés sont N deviennent des tables ;

– détermination des champs des tables et choix d’une clé primaire ;

– établissement des relations par l’intégration dans les tables esclaves des champs clé primaire de leurs maîtres.

Cette phase de modélisation précède obligatoirement celle de program-mation proprement dite. Pour cette dernière, on peut distinguer les étapes suivantes :

1 programmation de toutes les tables (avec leurs champs et leur clé pri-maire), établissement de toutes les relations de maîtres à esclaves et établissement de l’intégrité référentielle ;

2 programmation des formulaires et saisie des données ;

3 programmation des requêtes et états/rapports.



604
x