Microsoft AccessMCD Access
Le Modèle Conceptuel de Données
Le modèle conceptuel des données (MCD) fait référence à la méthode Merise qui est une méthodes d'analyse, de conception et de gestion de projet informatique (il existe d'autre méthode comme SDM/S ou Axial).
Définition des Tables (entités)source: tutoriel de Maxence HUBICHE sur Developpez.com
Par exemple, nous avons repéré trois tables :
- Client
- Commande
- Produit
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. Sous access (MLD) on appel cet identifiant une clé primaire. Vous noterez la convention qui consiste à souligner l'identifiant:
Maintenant, on va pouvoir ajouter toutes les informations (on les appelle ici 'attributs' et 'champs' sous access) que l'on souhaite enregistrer dans chaque fiche. Le résultat obtenu doit ressembler à ceci :
Comme les identifiants sont uniques, on peut retrouver un client, une commande ou un produit, simplement par son identifiant. Enfin, rien ne nous 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.
Mais comment savoir ce qui se passe entre ces fiches type. Par exemple, quel client a passé une commande.
Définition des Associations et de leurs cardinalitéssource: tutoriel de Maxence HUBICHE sur Developpez.com
L'association sert à définir l'action qu'exercent les tables entre elles. C'est pour cela qu'on les désigne souvent par un verbe. Il sagit d'un CIF (Contrainte d'Intégrité Fonctionnelle).
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 d'une petite phrase magique que voici :
Est-ce que une {TABLE} peut {ACTION} plusieurs {AUTRE TABLE}
Application :
Occupons-nous de la relation "passer" entre Client et Commande, et posons-nous cette question de l'une des tables 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 sur les deux question, 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 la clé de la table côté 1 dans la table 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.
On appel cette clé, une clé etrangère. Elle est souvent précédée du signe diese (#).
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, le traitement va se faire en plusieurs phases.
Tout d'abord, nous allons reproduire les 2 identifiants dans l'association (qu'il va falloir agrandir pour l'occasion). Nous obtenons donc ceci :
Mais surtout, il va falloir penser à toutes les informations que nous n'avons pas pu stocker jusqu'à présent. Par exemple, 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.
On appel cette new table une "patate" ou "une relation porteuse d'information" (Merise). Cette "patate" comporte 2 clés étrangère.
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 2006 que ceux d'avril 2007. 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.
source: tutoriel de Maxence HUBICHE sur Developpez.com
