Leçon
56 : Initiation au problème de l'utilisation d'une seule table 
Temps
nécessaire pour suivre cette leçon : Entre un quart d'heure
et une grosse demie-heure
Aperçu
de cette leçon| Cette fois, nous allons
aborder un sujet radicamene t différent, puisqu'il va s'agir
de la création d'une base de données totalement multi-tables.
C'est pour cette raison qu'il ne vous est pas proposé de télécharger
la base de données telle qu'elle était à la fin
de la leçon précédente. En effet, maintenant
que vous avez acquis les connaissances générales du
fonctioonnement des différents objets d'Access, vous allez
maintenant commencer à composer votre propre oeuvre. L'imbrication
de plusieurs tables les unes avec les autres est le gros gros point
fort d'Access, et, par extension, de tous les systèmes de gestion
de bases de données relationnelles. L'utilisation d'une 2ème table n'est pas un concept qui vous est parfaitement étranger, car nous avons vu ensemble dans les leçons 16 et 17 la possibilité d'attacher la table T_Pays et T_Client avec intégrité référentielle. Je ne saurais que trop vous recommander de réviser ces 2 leçons avant d'attaquer celle-ci, car nous allons réutiliser ces concepts de manière intensive. |
SommaireOui. Et justement, pour bien vous faire comprendre à quel moment on crée une ou deux tables, nous allons attaquer une petite application de gestion de cours. Au début, elle va être toute simple, et par la suite, elle va se compliquer petit à petit.
J'entends par "Application de gestion de cours" un programme qui va gérer les cours internes d'une entreprise. Nous allons imaginer que vous êtes le responsable des formations des employés de l'entreprise MultiCommerce. C'est donc à vous qu'incombe la tâche d'organiser différents cours pour vos employés : Il va y avoir des cours d'informatique, mais aussi de gestion, de marketing, etc.
Pour faire simple au début, nous allons admettre que les cours donnés se passent systématiquement sur un seul jour, d'une telle heure à une telle heure, et vous disposez d'une seule salle de cours pour tous les cours : Quel que soit le cours suivi, ce sera toujours dans cette salle, pour le moment.
Il s'agit donc de savoir quel prof donne un cours de quoi à qui et quand...
Nous allons essayer de nous poser les bonnes questions : Quels sont les renseignements dont nous avons besoin ?
Oui, pour tout, sauf pour la salle. Comme il n'y a qu'une seule salle, nous n'allons pas l'indiquer, on le sait. A part ça, vous avez raison, on a besoin de :
Est-ce que nous avons oublié quelque chose d'important ?
Oui, c'est vrai. Mais nous allons, toujours pour faire simple, qu'il n'y a pas d'interruption dans le cours. Autre chose ?
Ca, c'est déjà plus important. Si le prof est externe à l'entreprise, il faudra bien le payer. Nous allons donc ajouter le prix du cours. Autre chose ?
Effectivement, c'est important. Mais nous gérerons ça dans un 2ème temps. Nous allons dire que nous nous arrêtons là. Pour stocker ces données dans Access, nous allons avoir besoin d'une nouvelle base de données, donc mainteannt, vous allez créer une base de données que vous appellerez comme vous voulez, mais dans ce cours, nous allons toujours l'appeler ProFrormation : C'est vous qui voyez comment vous voulez vous organiser au niveau des noms des bases de données. La leçon 2 vous rafraîchira la mémoire. Si vous voulez, vous pourriez par exemple appeler cette nouvelle base ProFormationNiveau2.
Dans ce nouveau ProFormation, Vous allez donc créer une nouvelle table, avec les champs suivants : (Les leçons 3, 4, 6, 7 et 8 vous rappelleront comment faire)
Vous l'Enregistrez sous T_Cours, et vous refusez la clé primaire.
Nous allons nous en occuper un peut plus tard. Pour l'instant, vous lancez la table en mode saisie de données, et vous entrez une première ligne :
Est-ce qu'il y a quelque chose qui vous frappe dans cette ligne ?
Non... Un truc plus grave que ça au niveau d'Access : Là, il y a un élève.
Non, mais dans un cours, il y a plusieurs élèves normalement. Si par exemple, il y avait un 2ème ou même un 3ème élève, comment vous allez faire ?
! C'est vachement pratique ce que vous me proposez... Et si par exemple, j'ai tout plein de cours, et que je voulais extraire seulement les cours qu'à suivi Alice Japren, comment allez-vous faire ?
C'est vrai, sur ce coup-là vous vous en sortez bien. Et si maintenant, vous vouliez simplement trier par ordre alphabétique de la colonne IdentiteEleve ?
Bref... Vous constatez bien par vous-même que cette solution est vraiment peu pratique, et en fait quasiment inapplicable. Vous avez autre chose à proposer ?
D'accord, et comment est-ce que vous allez faire pour trier par ordre alphabétique des élèves ?
Ben non ça va pas... D'autant que vous pouvez avoir un même élève à différentes positions, comme ceci :
Et encore, là, on a que 3 élèves maximum par cours... S'il y a 12 places dans la salle, il faudrait créer Eleve1, Eleve2, Eleve3 jusqu'à Eleve12... 12 champs ! Sans compter qu'il est possible qu'une fois, exceptionnellement, il y ait eu une 13ème personne qui assiste au cours, et on lui ajoute une chaise, tout à coup il vous faut un 13ème champ Eleve13, juste pour gérer cette exception... Vous voyez le topo, si par exemple vous avez à organiser disons 200 cours différents, pour chacun des cours, ben il y a 13 champs, JUSTE pour UN malheureux cours ou il y avait une 13ème personne...
Oui, d'accord, c'est vrai que c'est mieux, mais alors quel boulot ! Il faut chaque fois répéter plein d'informations qui sont toujours les mêmes : Par exemple pour le premier cours, il faut répéter trois fois L'identité du prof, le nom du cours, sa date, l'heure de début et de fin, et le prix... Tout ça pour avoir une ligne par élève... Cette répétition inutile d'information s'appelle en terme technique de la REDONDANCE.
Vous vous rendez compte du travail ! Et de la place que ça va prendre ! Et de l'aspect peu esthétique !
Et encore, là on a que 2 ou 3 élèves... Imaginez un instant que nous avons des classes de 12 élèves : Il y aura donc 12 lignes... Et si, en plus, nous avons vraiment pas mal de champs dans notre table, comme par exemple en plus le numéro de portable du prof, le temps de pause à midi, une éventelle 2ème date pour le même cours si par exemple c'est un cours sur 2 jours, etc. Ca en fait de la redondance...
Nous allons voir ça. La première étape est prendre réellement conscience du blocage dans lequel on se trouve :
En fait, c'est systématique : CHAQUE fois que vous avez un objet qui peut contenir un nombre indéterminé de sous-objets, on est bloqué de la même manière. Dans notre exemple, nous avons un objet Cours qui peut contenir on ne sait pas combien de sous-objets Elèves.
On peut trouver plein d'autres exemples :
Chaque fois, le même problème revient inlassablement : Un truc (Repris de justice, CD, Terrain de tennis, voiture) contient un certain nombre d'autres machins, mais on ne sait pas combien (Délit, Chansons, Réservations, Options). Essayez de trouver d'autres exemples par vous-même.
Ca c'est différents, parce que ce sont vraiment des infos uniques et différentes : Dans ce cas, vous pouvez très bien dans votre table avoir un champ TelPrive, TelPro, Natel et Fax. Parce que sinon, on pourrait aussi dire que chacun de vos clients possède un nombre indéterminé de propriétés : Nom, prénom, adresse, code postal et ville... C'est pas la même chose
2, ce n'est pas un nombre vraiment indéterminé... C'est 2. Vous pouvez sans crainte avoir un seul champ TelPro, avec directement écrit dedans par exemple : 022.768.43.90 / 021.445.97.87. C'est vrai qu'on ne peut pas trier par le 2ème numéro, mais est-ce vraiment important ? Autrement, vous faites un champ TelPro1 et TelPro2, et voilà...
Ouais... Vous en connaissez beaucoup, vous, des gens qui ont 18 numéros de téléphone ?
Oui.
Oui, mais je vous vois venir : Déjà là, vous allez-être un peu ennuyé, parce que si vous recherchez par exemple tous les films ou Gérard Depardieu joue, il va vous falloir jouer avec les extractions sur les 2 colonnes : ActeurPrincipal et SecondRole, ce qui va vraiment être gênant...
Donc, dans ce cas, effectivement, nous sommes dans le cas : UN film contient UNE durée, UN titre, mais UN NOMBRE INDETERMINE d'acteurs. C'est toujours le même principe.
Nous allons arrêter cette leçon ici. C'est une leçon un peu frustrante, je vous l'accorde, car nous n'avons fait que soulever un problème sans donner la solution. Mais il est extrêmement important de parfaitement comprendre le problème pour pouvoir le résoudre, car le succès de vos développement Access seront directement liés à la conscience de cet état de fait.
Vous pouvez fermer votre table T_Cours.
Bon...
Hem... On peut résumer ?| Cette leçon était le grand préambule à la philosophie même de SGBDR (Système de gestion de bases de données relationnelles). Il est extrêmement important de comprendre parfaitement le concept d'objets qui contiennent des sous-objets, car cette notion est présente dans à peu près toutes les bases de données. Pas systématiqueemnt, la preuve : Jusqu'à cette leçon, nous avons passé 55 leçons ensemble sans en entendre parler. Par contre, je suis assez persuadé que vous vous êtes déjà cassé les dents sur cette notion si vous êtes déjà en train de développer un projet Access. |
Avez-vous
bien compris ?
Pour voir les solutions, il vous suffit de sélectionner le questionnaire ci-dessus : 3 petites étoiles *** apparaîtront en face des bonnes réponses. |
Si vous n'êtes pas tout à fait certain d'avoir suivi correctement toutes les étapes de cette leçon, vous avez la possibilité de télécharger ici la version de ProFormation.mdb exactement dans l'état ou elle devrait être à la fin de cette leçon.
Avez-vous une question technique
concernant cette leçon ? Cliquez
ici !
Une remarque sur cette leçon ? Un problème
? Une erreur ? une ambiguité ? Soyez
gentil de m'en informer