Access : Les Bases

15/07/2004

[ Précédent ] [ Sommaire ] [ Télécharger ]

3. Conception de la base de données
3.1. Pourquoi c'est faire un SGBDR ?
3.2. La méthode merise
3.2.1. Principes Fondamentaux
3.2.2. Le modèle Entité-Association (MEA)
3.2.2.1. Définition des Entités
3.2.2.2. Définition des Associations
3.2.2.3. En résumé ...
3.2.3. A vous de jouer ...

3. Conception de la base de données

3.1. Pourquoi c'est faire un SGBDR ?

La première chose à savoir sur Access, c'est qu'il s'agit d'un SGBDR/RAD.

Un SGBDR est un 'Système de Gestion de Bases de Données Relationnelles'.

Examinons ce nom dans le détail :

Access est un 'Système de Gestion'. C'est donc un logiciel. En aucun cas, il ne s'agit d'une base de données ! C'est un 'Système' qui sert à 'Gérer', et à 'Gérer' des 'Bases de données Relationnelles'. La 'Base de Données Relationnelle' est donc le type de fichiers gérés par Access, au même titre que Word gère des documents et Excel des classeurs.

Sur Access, les documents gérés ont une extension en .mdb (ou .mde) . Il s'agit des bases de données accessibles à travers le moteur de base de données utilisé nativement par Access, moteur qui porte le doux nom de JET.

RAD est l'acronyme de 'Rapid Application Development'

La seconde question qu'on pourrait se poser est : pourquoi utiliser un SGBDR ? Après tout, ne peut-on pas faire beaucoup de choses avec Excel ?

Prenons un exemple. Nous serait-il possible de saisir les commandes dans Excel, pour permettre leur suivi et d'utiliser Word pour faire un mailing pour les imprimer et de les envoyer à mes clients ?

Examinons les faits. Si nous voulons faire un tableau dans Excel à cette fin, nous nous dirigerons vraisemblablement vers quelque chose de semblable à ceci :

Nous avons bien l'ensemble des informations relatives à notre client, toutes celles propres à la commande de ce client, ainsi que tout ce qui concerne les produits commandés.

Nous saisissons la première ligne de notre première commande, et tout va pour le mieux.

MAIS, notre client n'a pas commandé qu'un seul produit. Et là, intervient le premier soucis : qu'allons-nous faire du deuxième produit ? Nous allons l'écrire sur la ligne du dessous, en prenant bien soin de recopier chaque information relative au client et à la commande car, sans cela, le moindre tri risque d'être fatal. Nous risquons de perdre la relation existant entre mon produit et ma commande, donc mon client…

Cela nous oblige à dupliquer la plupart des informations que nous avons déjà saisies, mais, quoi qu'il en soit, nous pouvons donc arriver à ce résultat, qui nous donnent une certaine satisfaction :

A partir de là, d'autres soucis peuvent intervenir : Comment savoir combien de commande sont enregistrées ? Nous ne pouvons plus compter les lignes. Certaines commandes feront une seule ligne, d'autres cinquante (nous l'espérons). Nous serons donc amené à faire un traitement d'extraction pour récupérer chaque N° de facture sans ses doublons, pour ensuite compter le nombre de lignes ainsi récupérées. Mais cela reste faisable avec Excel.

Puis les commandes s'enchaînent et nous en arrivons à nous poser des questions d'analyse. Par exemple, nous aimerions, partant du tableau suivant :

Connaître le CA pour le produit TOMATES. Combien cela atteint-il ? Il est vrai qu'il est très simple d'utiliser Excel pour faire des calculs. Il est fait pour cela. Mais en l'occurrence, le résultat renvoyé par Excel sera de xxxxx et non de xxxxx car, lors de ma saisie, nous avons fait une erreur : une ligne indique TOMATES et l'autre TOMATE. Or pour Excel, il y a une grosse différence entre TOMATE et TOMATES. Cela pour indiquer que, même si la recopie est un outils aisé, il n'en reste pas moins source d'erreurs. Nous ne parlons même pas de la limite physique de ce tableau qui ne pourra jamais excéder les 65535 lignes. Et, dans ce cas, les temps de latences seront extrêmes, notamment dans le cas de calculs analytiques complexes.

En résumé, même si on peut s'en sortir par la technique Excel, de nombreux problèmes peuvent venir s'interposer :

Redondance des données. Cette réécriture étant source d'erreurs
Limitation du nombre de lignes
Le mélange des divers 'ensembles de données' (Client / Commande / Produit / …) dans un seul et même tableau ne facilite pas les analyses statistiques.

Il faut donc trouver un autre système. C'est là qu'interviennent les Bases de Données Relationnelles, dont Access fait partie.

3.2. La méthode merise

L'idéal, pour construire une base de données est de connaître la méthode merise. Si vous décidez de faire de la conception/réalisation de bases de données votre métier, commencez par cela. Sinon, les méthodes que je vais vous donner par la suite devraient être suffisante pour faire face à la majorité des cas.

Voici quelques livres que vous pourrez consulter pour vous documenter sur cette méthode :

3.2.1. Principes Fondamentaux

Repartons de notre cas précédent, celui des commandes.

L'idée est de réussir à rassembler les informations, comme sur des fiches types.

Par exemple, un client est un client. Quel que soit le client, nous allons systématiquement avoir besoin d'informations qui lui sont propres. Nous pouvons gérer ce client, l'enregistrer sur une fiche. D'ailleurs, ne parle-t-on pas de fiche client, et même, de fichier client.

Nous pourrions même imaginer 'préformater' des feuilles ainsi, nous n'aurions plus qu'à les remplir et à les mettre dans notre fameux 'fichier client'.

En fait, cette 'fiche préformatée', on pourrait l'appeler 'entité'. Tout le jeu va donc être, maintenant, de repartir de données que nous avons dans notre tableau de départ, et de les rassembler par 'fiche type' et de faire autant de 'fiche type' ou 'entité' que nous avons d'éléments distincts à gérer. C'est le point de départ du Modèle Entité-Association (MEA)

3.2.2. Le modèle Entité-Association (MEA)

3.2.2.1. Définition des Entités

Sur notre problématique, nous avons repéré trois entités : Client, Commande et Produit.

Nous pourrions les dessiner ainsi :

Chose importante, dans chaque entité, nous devons créer une zone qui contiendra une valeur obligatoire et unique à travers toutes les fiches tirées de cette entité. On appelle cela un identifiant. Dans le cas du client, ce sera le N° de client. Pour la commande, le N° de Commande. Pour les produits, la référence produit fera l'affaire (un code barre par exemple). Après avoir ajouté nos identifiants, nous obtenons ceci :

Maintenant, on va pouvoir ajouter toutes les informations que l'on souhaite enregistrer dans chaque fiche. Le résultat obtenu doit ressembler à ceci :

Nous avons maintenant une série de fiches type, et nous sommes capable, dans chaque fiche, de stocker toute l'information qui nous intéresse.

De plus, comme les identifiants sont uniques, on peut très facilement retrouver un client, une commande ou un produit, simplement par son identifiant. Enfin, rien ne m'empêchera d'avoir deux clients ayant le même nom mais étant localisés dans des villes différentes par exemple. Nous ne risquons pas de les mélanger, puisqu'ils ont des identifiants différents.

Cependant rien ne nous permet de déterminer ce qui se passe entre ces fiches type. Par exemple, si nous lisons bien la fiche des Commandes, nous n'avons aucun moyen de savoir quel client l'a passé. Nous avons donc un peu de mal à exploiter les fiches en l'état actuel des choses. Il va falloir déterminer les actions se passant entre les fiches, et savoir en garder trace. C'est tout l'objet de la deuxième étape

3.2.2.2. Définition des Associations

L'association sert à définir l'action qu'exercent les entités entre elles. C'est pour cela qu'on les désigne souvent par un verbe.

Que fait le client ? Il passe des commandes. Il existe donc une action que fait le client sur les commandes, et cette action est décrite par le verbe 'passer'. On peut donc tracer l'association entre le client et la commande comme ceci :

Maintenant, on peut aussi dire que les commandes regroupent des produits. Encore une fois, le verbe regrouper décrit ici l'action qui se passe entre les commandes et les produits.

Cette étape importante étant terminée, il faut déterminer COMMENT ces associations s'exercent. Il s'agit de déterminer les cardinalités.

Pour cela, on se sert s'une petite phrase magique que voici :

" Est-ce que un(e) {ENTITE} peut {ACTION} plusieurs {AUTRE ENTITE} "

Application : Occupons-nous de la relation 'passer' entre Client et Commande, et posons-nous cette question de l'une des entité vers l'autre, puis vice-versa :

" Est-ce que un {Client} peut {passer} plusieurs {Commandes} "

La réponse est OUI, bien sûr, et heureusement !

" Est-ce que une {Commande} peut {être passée par} plusieurs {Clients} "

Cette fois la réponse est NON. Chaque commande n'est passée que par un seul client.

Comme nous ne pouvons donner qu'une seule réponse positive, nous avons une association 1-n (un à plusieurs).

A partir de là, tout est simple.

Lorsque nous sommes en présence d'une relation un à plusieurs, il faut reproduire l'identifiant de l'entité côté 1 dans l'entité côté plusieurs :

Et là, la raison devient évidente :

Si nous lisons la fiche commande, nous voyons que la commande dont le numéro est 12345, a été passée à une date donnée, livrée à une autre date précise, chez un destinataire clairement identifié. Mais maintenant, apparaît aussi sur cette fiche le numéro du client (C987) qui a passé la commande. Et si l'envie nous prenait de savoir de quel client il s'agissait, il suffirait alors d'aller trouver, parmi les fiches des clients, la fiche dont le numéro est C987. Ce numéro étant unique parmi toutes les fiches, nous sommes certains qu'il ne pourrait s'agir QUE de Dupont & Co.

Passons maintenant à la deuxième association, l'association 'regrouper'

" Est-ce que une {Commande} peut {contenir} plusieurs {Produits} "

La réponse est OUI, bien sûr, et heureusement !

" Est-ce que un {Produit} peut {être contenu dans} plusieurs {Commandes} "

Cette fois encore la réponse est OUI. Il est évident que le produit TOMATE peut apparaître dans plusieurs commandes.

Comme nous pouvons donner deux réponses positives, nous avons une association n-n (plusieurs à plusieurs).

Dans ce cas, on 'étend' l'association et on y place les deux identifiants, comme ceci :

Mais surtout, il va falloir penser à toutes les informations que nous n'avons pas pu stocker jusqu'à présent. Par exemple, si nous nous référons au tableau Excel que nous avions fait au départ, et le comparons aux données présentes dans nos entités, on peut se demander ce qu'il est advenu des quantités !

En réfléchissant, on comprend bien que ces quantités ne peuvent être présentes dans les produits, car il ne s'agit pas de 'quantité de produits' mais de 'quantité de produits dans les commandes'. De même pour l'entité des commandes. En aucun cas il ne s'agit de la quantité de commandes n'est-ce pas !

La place de cette valeur est donc maintenant toute trouvée : dans l'association 'regrouper'. Maintenant, si je faisais ceci, que penseriez-vous :

Certains diront certainement que, vu que nous cherchons à éviter la duplication des données, il est inutile de reproduire le PrixUnitaireHT et la TVA qui sont déjà présents dans l'entité Produit, mais que la Quantité et la Remise sont bien placées.

Partagez-vous ce point de vue ?

C'est probable. Pourtant, même si ces informations ont le même nom, elles n'emportent pas la même signification :

Les PrixunitaireHT et TVA de l'entité Produit ont rapport avec le prix et le taux actuels. Ceux qui sont appliqués pour la facture qu'on est en train de faire.

Les PrixUnitaireHT et TVA de l'association Regrouper ont, quant à eux, rapport avec les données historiques. Chaque ligne de commande étant enregistrée ici, nous gardons une trace de l'historique des prix. Ce que nous ne trouvons nulle part ailleurs. Nous avons donc aussi bien les prix des commandes de Janvier 2003 que ceux d'avril 2004. Et sans ces données, nous serions dans l'impossibilité de calculer l'évolution du chiffre d'affaire, car le seul prix et le seul taux disponibles concerneraient l'instant présent.

Donc, lorsque nous sommes en présence d'une association plusieurs à plusieurs, il convient de toujours se poser les questions relatives aux données complémentaires, et tout particulièrement les données historiques.

3.2.2.3. En résumé ...

Après avoir posé la question magique, vous retiendrez 3 situations au maximum. Nous n'avons pas encore parlé de la troisième, mais nous y viendrons plus tard… beaucoup plus tard tellement elle est rare :

Un-à-plusieurs	Plusieurs-à-Plusieurs	Un-à-un
Ce cas est extrêmement courant. Il est très facilement géré également. dans ce cas, il faut reproduire l'entité qui est du côté un dans l'entité côté plusieurs (à noter que le nom même est peu important, mais que l'information qu'on va y mettre, elle, l'est)	Ce cas aussi est très fréquent. Il est un peu plus complexe à mettre en œuvre. Il correspond en fait à 2 associations un-à-plusieurs " reproduire les identifiants des deux entités dans l'association " Réfléchir à l'ensemble des données annexes (y compris historiques)	Ce cas est extrêmement rare. Si une entité ne peut être liée qu'à une seule autre entité et réciproquement, il est fort probable qu'il s'agisse en fait de la même entité

3.2.3. A vous de jouer ...

Nous allons passer maintenant à la mise en application. Voici un petit exercice que vous avez essayé de résoudre par vous-même. Je commence par mettre en situation.

Imaginez que vous intervenir pour une société de prestations de services informatiques, a fin de concevoir une base de données permettant le suivi et la facturation des interventions réalisées chez les clients. La société est susceptible de réaliser n'importe quelle intervention. Il faut impérativement que le modèle que vous allez concevoir à répondre aux questions suivantes, sans en oublier une partie :

quel employé et dans quel service, et qui le dirige ?
quel employé travaille pour quel client et à quelles dates ?
quels clients a demandé quelle intervention ?
quels matériels sont à facturer, pour qu'elles intervention, et en quelque quantité ?
quels matériels composent quels autres matériels ?

Voici quelques informations supplémentaires que vous devez connaître :

un employé ne peut appartenir qu'un seul service même si chaque service pour une multitude d'employés.
à aucun moment mon client ne peut prendre contact directement avec mon employé. Il serait d'ailleurs tout aussi en convenant que mon employé prenne directement contact avec mon client.
une intervention peut nécessiter plusieurs jours, et la présence de plusieurs employés. Il est tout aussi possible qu'une intervention ne nécessite que la présence d'un seul employé pour une seule journée. La présence de mes employés pour une intervention peut-être discontinue (vacances, week-end,...).

Essayez de réaliser une solution par vous-même. Vous pourrez retrouver la correction de cet exercice en annexe A du présent manuel, à l'entrée 'Solution du MEA'

[ Précédent ] [ Sommaire ] [ Télécharger ]

Ce document est issu de http://www.developpez.com et reste la propriété exclusive de son auteur. La copie, modification et/ou distribution par quelque moyen que ce soit est soumise à l'obtention préalable de l'autorisation de l'auteur.