Cours de la méthode Merise : le MCD et le MLD

Analyse des données

Analyse des traitements

Niveau conceptuel

Quelles informations manipule-t-on ?

Que veut-on faire ?

Niveau logique

Comment structurer ces données ?

Qui fait quoi, où, quand ?

Niveau physique

Où les stocker ?

Comment ?

Analyse des données

Analyse des traitements

Niveau conceptuel

Modèle conceptuel des données  (M. C. D.)

Modèle conceptuel des traitements (M. C. T.)

Niveau logique

Modèle logique des données  (M. L. D.)

Modèle organisationnel des traitements (M.O.T.)

Niveau physique

Tables et index

Procédures

But :

• Il s’agit de représenter, par un formalisme précis et en grande partie standardisé, l’ensemble des informations que l’on doit traiter pour répondre aux attentes du projet défini en amont de l’analyse (dans le schéma directeur).

principes :

• IL FAUT OUBLIER LES MOYENS QUI SERONT MIS EN ŒUVRE POUR

LA RÉALISATION. (il s’agit uniquement de décrire le problème à traiter, et pas du tout de préciser, simplifier ou guider les choix qu’on sera plus tard amenés à faire)

But :

• collecter l’ensemble des données (ou attributs) manipulées par le système. Accessoirement (mais à long terme cet accessoire sera souvent plus stratégique que le DDD), faire apparaiître dans” l’Univers du discours” (en abrégé UDD) la liste des questions qui auront émergé dans ce collectage, et des réponses qui y ont été amenées.

Moyens :

• collecter au moins deux occurence de chacun des documents, écrits ou non, manipulés par chacun des acteurs.

• Pour chaque type de document, analyser l’ensemble de ses occurences, en repérant chaque zone dont le contenu peut être amené à varier d’une occurence de ce document à l’autre.

• Pour chaque type de document, analyser l’ensemble de ses occurences, en repérant chaque zone dont le contenu peut être amené à varier d’une occurence de ce document à l’autre, et qui doit être mémorisé. Une telle zone sera qualifiée de donnée. Donner un nom à chacune de ces zones, et l’ajouter dans le dictionnaire des données. Chacun de ces noms sera qualifié d’ “attribut”.

précautions :

•  Il s’agit uniquement de collecter des données. Le seul impératif est de ne pas oublier une donnée. Tout classement, toute simplification, toute optimisation est à proscrire.

Limites :

•  Ce n’est qu’à la validation du M.C.D. à l’aide du M.C.T. qu’on peut être sûrs d’avoir effectivement obtenu le M.C.D. correspondant au problème. Autrement dit, cette première étape du M.C.D. ne peut être automatisée.

•  On ne connaît pas de moyens de définir d’une façon non ambigüe l’univers du discours (UDD), c’est-à-dire les concepts (et par conséquences les données) qui font ou ne font pas partie du problème à traiter.

•  Un MCD ne vaut que par la qualité de l’UDD qui le sous-tend. Se rappeler qu’à chaque question concernant l’UDD, on a 5 réponses possibles à chaque point dont un se demande s’il doit être traité :

-     il doit être traité, c’est suffisamment évident pour ne pas le signaler

-     il est supposé être traité, mais il est prudent de signaler qu’il a été intégré

-     il est supposé ne pas être traité, mais il est prudent de le signaler

-     il ne doit pas être traité, c’est suffisamment évident pour ne pas le signaler - On ne peut trancher : faire remonter la question au commanditaire, et faire figurer dans l’UDD la question et la réponse fournie.

But :

• Epurer l’ensemble des attributs obtenus à l’étape précédente, en vérifiant que chaque donnée correspond à un “atome” d’informations, indivisible et indépendant des autres données.

IL NE FAUT AUCUNE REDONDANCE (DIRECTE OU INDIRECTE) DANS UN DDD ÉPURÉ.

Moyens :

• Vérifier les synonymes : la même donnée utilisée sous deux termes différents par deux acteurs différents.

• Vérifier les homonymes : deux données différentes utilisées sous le même terme par deux acteurs différents.

• Vérifier les dépendances directes : une donnée qui peut être obtenue à partir d’autres données (exemple : prix unitaire HT, TVA, prix unitaire TTC : une de ces données doit être épurée).

• Vérifier les dépendances indirectes et les données calculées : une donnée obtenue comme totalisation ou comptage d’autres données (exemple : nombre de factures, ou chiffre d’affaires d’un client).

• Epurer les paramètres qui ne sont pas des données  (exemple : la date de début et la date de fin d’un état récapitulatif sur une période).

précautions :

•  La principale difficulté concerne les difficultés de communication. Est-on bien sûr que ce qu’on a entendu a le même sens pour nous et pour notre interlocuteur ?

•  Se méfier des données du genre “Nombre de “ ou “Totalisation” : elles peuvent presque toujours être calculées à partir d’autres données plus élémentaires, et doivent de ce fait être épurées.

Limites :

•  Fondamentalement, les mêmes que pour l’étape 1.2.A.

•  On est obligés de s’en remettre à son bon sens pour déterminer si oui ou non une donnée est un atome d’information indivisible dans l’univers du discours considéré.

Total facture

Prix unitaire HT

Désignation

Montant TVA Prix unitaire TTC

Taux TVA

Adresse du client  ->

1° ligne adresse

CP Ville

But :

Moyens :

précautions:

Limites :

•   Découper l’ensemble des attributs du dictionnaire des données épuré en différentes unités logiques, ici appelées “Objets du M.C.D”.

•   Reporter dans l’ébauche du M.C.D, l’un après l’autre et sans ordre préétabli, chacun des attributs du DDD, en l’attachant si possible avec l’un des objets déjà reconnus. Si cela n’est pas possible, créer un nouvel objet composé (pour l’instant) de ce seul attribut.

•   Pour savoir si un attribut peut être attaché un objet, décrire dans un gand tableau l’ensemble des occurences des différents attributs correspondant à l’état du système à un instant t1, à un instant t2…

Vérifier si le nombre d’occurences de l’attribut en cours de traitement est, pour chacun de ces instants, le même que le nombre d’occurences du premier objet déjà reconnu. Si ce n’est pas le cas, se poser la même question pour le même attribut et l’objet suivant.

•   Faire preuve de modestie et SE FIER À LA TECHNIQUE PLUTÔT QU’AU BON SENS : l’expérience montre que celui-ci est souvent mis endéfaut au cours de cette étape, et qu’il peut souvent amener à regrouper dans des objets des attributs ayant un nombre d’occurences plus élevé que celui de l’objet, et parfois à dissocier des attributs qui ont tous le même nombre d’occurences.

•   Une erreur courante consiste à choisir l’attribut qu’ on analysera au lieu de prendre le premier qui vient : ce choix “innocent” de l’attribut à traiter consiste en fait à considérer le problème du regroupement de cet attribut comme déjà réglé avant même de l’attaquer.

•   Chaque attribut doit figurer une fois et une seule dans le M.C.D.

•   Une difficulté particulière : deux occurences d’un attribut ayant la même valeur. S’agit-il d’une seule occurence utilisée 2 fois ou de deux occurences distinctes ? A un niveau théorique, on pourrait toujours affirmer que deux valeurs semblables concernent toujours une seule occurence. Mais c’est souvent improductif. Il faut amener cette téponse dans le cadre de notre univers du discours, et reformuler la question de la manière suivante : si à deux occurences d’un attribut A correspond la même valeur pour l’attribut B, est-ce que, de ce fait, à ces deux occurences de l’attribut A correspondra la même valeur d’un autre attribut C ? Si oui, on a affaire à une seule occurence de l’attribut B, et le nombre d’occurences de A et B n’est donc pas le même (cf exemple :  à 2  “n° séquentiel” distincts correspond  la même année de facturation. Mais 

ceci n’impose aucune valeur commune aux autres attributs du dictionnaire. On peut donc considérer qu’on a deux occurences distinctes de “Année de facturation” qui se trouvent avopir la même valeur, et donc que le nombre d’occurences  de  “n° séquentiel”  est le même que  le nombre d’occurences de  Année de facturation”

VOIR SYNOPTIQUE PAGE SUIVANTE POUR S’AIDER DANS C ETTE ÉTAPE.

•   pas de limites : A partir de cette étape commence une démarche rigoureuse, qui nous permettra de systématiser l’analyse. A partir d’un dictionnaire des données épuré exact, tout merisien pourra obtenir un M.C.D, puis un M.L.D juste.

Ebauche du M.C.D :

Nom

Prénom

1° ligne adresse

2° ligne adresse

CP Ville

Qantité

JourMois facture

Année facture

N° séquentiel

Réf. produit Désignation

Prix unitaire HT

Mode règlement

Exemple :           Nom         Prénom

                                           Dupont     Alfred

                                           Durand     Alfred

Peut-on regrouper Nom et Prénom dans le même objet ?

Il est facile de répondre Oui à la questions 1 en considérant les personnes physiques : chaque fois qu’il apparaît une occurence de Nom dans le système, on peut l’associer à une personne physique, et donc au prénom de cette personne. Même raisonnement pour la question 2.

Lé réponse à la question 3 est Oui : Deux occurences de Nom (corespondant à deux personnes différentes) peuvent être associées au même prénom (ex : Dupont Alfred et Durand Alfred). Il est donc nécessaire de poser la question 4 : deux noms différents, s’ils sont associés au même prénom, auront-ils d’autres éléments en commun ? La réponse n’est jamais évidente, elle dépend évidemment de l’univers du discours, et donc du dictionnaire des données retenu. Si on gère juste un fichier d’interlocuteurs, il se peut que le partage d’un prénom par deux personnes n’ait pas de conséquences, et on pourra affirmer que chacune cde ces deux personnes a son propre prénom, et que leur valeur commune n’est que le fruit du hasard. Mais si, dans notre U.D.D., nous avons précisé que la date de fête doit être mémorisée (par exemple pour envoi de mail de souhait de bonne fête au jour dit) il est évident que deux personnes partageant le même prénom pourront être amenées, DE CE FAIT, à partager d’autres informations, ici la date de fête. Selon la réponse à cette question, en étudiant les contraintes de l’égalité des prénoms sur chacun des autres attributs du D.D.D

But :

• Reconnaître ceux qui, parmi les objets obtenus à l’étape précédente, peuvent être “identifiés en interne”, c’est-à-dire tous les objets dont les occurences pourront être repérées sans ambiguïté par le simple examen des occurences de leurs attributs.

Moyens :

•  Pour qu’un objet soit identifiable, il faut et il suffit qu’ il ne puisse pas y avoir deux occurences de cet objet pour lesquelles tous les attributs auront les mêmes valeurs (on pourra donc reconnaître chaque occurence en examinant les valeurs portées par ses attributs puisque l’ensemble de ces valeurs est distinct d’une occurence à l’autre).

•  Un objet identifiable à partir de ses attributs est appelé une entité. Choisir un nom pour cette entité. L’entourer d’un rectangle surmonté du nom choisi.

• Pour cette entité, il faudra ensuite déterminer un sous-ensemble le plus limité possible de ses attributs (sous-ensemble souvent, mais non nécessairement limité à un seul attribut), sur lequel deux occurences de l’objet ne pourront avoir  des valeurs distinctes (voir exemples). La concaténation de cas attributs pourra donc servir à identifier chaque occurence de l’entité. Cette concaténation sera appelée “Identifiant”. Le ou les attributs omposant cet identifiant seront soulignés et placés en début d’entité.

précautions :

• Ici aussi, SE FIER À LA TECHNIQUE PLUTÔT QU’AU BON SENS : il arrive qu’un choix d’identifiant paraisse évident et soit erronné.

ARTICLE

Réf. produit

Désignation

Prix unitaire HT

But :

Moyens :

• L’étape précédente a permis de définir un identifiant pour chaque entité. Parmi les objets non identifiés, il faudra reconnaître ceux qui seraient identifiables si on essayait, à l’aide d’une redondance, de leur adjoindre un ou des identifiants déjà reconnus.

• Trois cas de figure se présentent :

-

L’objet est identifiable par deux ou plusieurs identifiants externes : l’objet est alors une relation porteuse de données. On reconnaît cette propriété de la manière suivante : si l’on dupliquait ces identifiants externes dans l’objet considéré, il y aurait, pour chaque occurence de l’objet, une seule occurence de chaque identifiant externe, et l’ensemble de ces identifiants externes est discriminant i.e : il n’y a pas deux occurences de l’objet pour lesquelles l’ensemble de ces identifiants prend les mêmes valeurs). Pour nommer cette relation, on choisit un verbe correspondant à l’action qui lie les entités ayant fourni les identifiants de la relation. On surmonte la relation de son nom, puis on l’entoure  d’un cercle, et on relie cette relation à chacune des entités ayant fourni leur identifiant. 

-

L’objet est identifiable par la combinaison d’un identifiant externe, et un ou plusieurs attributs internes : l’objet est alors une entité relative (à la fois une entité et une relation), qu’on nomme, et qu’on entoure d’un rectangle en pointillés, relié à l’entité identifiante par une flèche partant de la sous-entité. La reconnaissance de la part externe de l’identifiant se fait comme pour l’alinéa précédent (cf exemple en I.2.I ci-dessous).  Cas particulier  : l’objet

est identifiable à partir d’un seul identifiant externe : il existe alors une relation (0,1) à (1,1) entre cet objet et un objet déjà identifié : cf § I.2.J.a cidessous

-

précautions :

• Ne créer d’identifiant supplémentaire dans le DDD que dans le cas où il est impossible d’identifier un objet ni en interne, ni en externe.

• Bien vérifier qu’il n’existe qu’une occurence d’un identifiant externe pour une occurence de l’objet.

• Dans le cas où plusieurs objets ne sont identifiables ni en interne, ni en externe, ne pas créer plus d’un identifiant à la fois dans le DDD (car un identifiant créé peut servir à identifier en externe d’autres objets que celui dans lequel il a été intégré).

• A chaque ajout d’identifiant, il est indispensable de refaire l’épuration du dictionnaire des données, car l’identifiant créé peut rendre caducs certains attributs initialement retenus.

But :

• Décrire l’existence d’autres relations, non porteuses de données, décrivant la dépendance, en particulier les contraintes d’existence, entre les entités.

Moyens :

• Réaliser un tableau carré présentant en absisse et en ordonnée la liste des entités. Pour chaque case de ce tableau, déterminer les relations de dépendances susceptibles d’exister entre ce couple d’entités.

• Choisir un verbe pour représenter chaque relation reconnue. Placer la relation dans le M.C.D, et la relier à chacune des entités mises en jeu dans cette relation.

précautions :

• S’il existe à la fois une relation entre un objet A et un objet B, entre B et C et entre A et C, vérifier :

-  si l’une des relations peut être une conséquence immédiate des deux autres. Dans ce cas, la supprimer. 

-  si l’on est en présence d’une seule relation entre trois entités. 

-  ou s’il existe bien deux manières différentes d’associer des occurences de C à des occurences de A, auquel cas il existera une boucle dans le MCD.

But :

• Décrire la nature de chaque relation.

Moyens :

• Etudier à tour de rôle chaque patte de chaque relation, c’est à dire chaque patte reliant une relation à une entité (ou une entité relative à une entité).

• Pour chaque patte, poser les deux questions :

-  Pour n’importe laquelle des occurences de l’entité, peut-il y avoir 0 occurences de la relation, ou doit-il y en avoir au moins une ? 

-  Pour n’importe laquelle des occurences de l’entité, peut-il y avoir n occurences de la relation, ou doit-il y en avoir au plus une ? 

• surmonter chaque patte du couple de réponses apportées : selon le cass, (0,1)  ou (0,n) ou (1,1) ou (1,n).

précautions :

• Ne pas oublier les entités relatives.

• Ne pas pervertir les questions pour en faire par exemple “Pour n’importe laquelle des occurences de l’entité, peut-il y avoir 0 occurences de l’autre entité (ou des autres entités) concourant à la relation, ou doit-il y en avoir au moins une

?

•  En pratique : remettre en cause toutes les relations n’ayant aucun “n” comme cardinalité maximale (en théorie, ceci peut exister, mais en pratique, il y aura souvent intérêt à remplacer cette relation par la notion de sous-entité - voir exemples du cours). En conséquence, on pourra en pratique se permettre de négliger les cardinalités minimum. Une relation à deux pattes ayant une patte (0,1) ou (1,1) et une patte (0,n)  ou (1,n) sera dite “relation 1-N”. Une relation à deux pattes ayant deux pattes (0,n) ou (1,n) sera dite “relation N-N”.

• Sauf cas très tatillons de relations ayant des cardinalités (0,1) à (0,1) remis en cause dans l’alinéa précédent, une relation porteuse de données aura toujours des cardinalités maximum de n sur toutes ses pattes (sinon, les attributs de la relation auraient pu être reportés dans l’entité reliée par cette patte). La réciproque n’est pas vraie : une relation non porteuse de données peut être du type 1-N ou N-N

But :

• Modifier la présentation des relations les plus simples afin de représenter MIEUX et plus vite la complexité réelle du M.C.D.

Moyens :

• En théorie : Toute relation à deux pattes ayant sur une patte une cardinalité (1,1) sera remplacée par une simple flèche partant de l’entité reliée par la patte (1,1) et aboutissant à l’autre entité concourant à la relation. Chacune de ces relations est appelée “contrainte d’intégrité fonctionnelle”, ou “CIF”.

• En pratique : Toute relation à deux pattes ayant sur une patte une cardinalité (0,1) ou (1,1) sera remplacée par une simple flèche partant de l’entité reliée par la patte (0,1) ou (1,1) et aboutissant à l’autre entité concourant à la relation.

précautions :

• Ne pas oublier les entités relatives.

But :

• S’assurer que le modèle obtenu a bien tenu compte des évolutions susceptibles d’évoluer dans le temps.

Moyens :

• Vérifier, pour chaque attribut de chaque objet, s’il y a conjonction des deux points suivants :

-  La valeur d’une occurence au moins de cet attribut peut être modifiée au cours de la vie du système.

-  Il faudra avoir accès à la fois à l’ancienne valeur et à la nouvelle valeur de cette occurence 

• S’il existe des attributs pour lesquels la réponse à ces deux questions est simultanément positive, nous sommes en présence d’un M.C.D. qui “ne résiste pas au temps”, et qui est donc basé sur un DDD erronné. Les corrections à apporter peuvent être de deux ordres :

- Il existe une donnée cachée qui n’a pas été repérée dans le DDD  (par exemple, la donnée “Date de modification” de l’attribut concerné”). Il faut

précautions :

alors ajouter cette donnée cachée dans le DDD et refaire tout le processus 1. à pârtir de l’étape 1.2.B (en effet, l’ajout de ce nouvel attribut peut amener à épurer d’autres attributs devenus redondants). cf exmeple 1 en regard

- Le nombre d’occurences de l’attribut a été sous-évalué : les valeurs différentes attribuées à cet attribut au cours du temps sont en fait des occurences différentes de cet attribut. Il faut alors reconsidérer le regroupement des attributs de l’étape 1.2.C

•  Vérifier, pour chaque cardinalité maximale égale à 1, si la prise en compte des variations dans le temps pourrait amener à reconsidérer cette cardinalité maximum à n : dans ce cas, il conviendra d’ajouter une date de changement, portée par une entité relative de l’entité “du côté 1”. Lé relation 1-n estr alors déplacée à partir de l’entité exmeple 2 en regard

regard

•  En résumé, un problème de résistance au temps se résoud presque systématiquement par l’ajoutd’une entité relative, ou la transformation d’une relation en entité relative, et dans tous les cas la date de prise en compte comme partie interne de l’identifiant de cette entité relative.

•  Il ne faut pas de remise en cause du M.C.D. obtenu à une réponse positive à seulement la première des deux questions (i.e. “La valeur d’une occurence au moins de l’attribut variera au cours du temps”) : si une valeur change mais qu’on n’a pas besoin d’accéder à l’ancienne valeur, on a alors une seule occurence de l’attribut.

ARTICLE

Réf. produit

Désignation

PU achat

FOURNIT N° Fournisseur           Réf. produit   DEVIENT : N° Fournisseur

Nom                         Désignation                         Nom                        Date change

                                                PU achat                                                                 PU Achat

EXEMPLE 3  : On veut ajouter la gestion des fournisseurs, et le prix d’achat des articles au fournisseur. On suppose que chaque article a plusieurs fournisseurs, chacun avec son propre PUachat. Une première analyse a négligé le fait que le prix peut changer : on avait alors une n-n entre article et fournisseur. Les vérifications de la résistance au temps contredisent ce point, et la n-n est remplacée par une relative :

                          FOURNISSEUR   0,n      FOURNIT       1,n ARTICLE

N° Fournisseur            PU achat            Réf. produit

Nom                                                 Désignation PU achat

DEVIENT :

FOURNISSEUR

FOURNIT

N° Fournisseur

                       Nom                        Date change

PU Achat

I.2.J     Cas particuliers

On peut, dans certaines études, se trouver confrontés à des cas “limites”, qui ne seraient pas traités d’une manière assez efficace par la méthode présentée ci-dessus :

  1.2.J.a : Sous-entités :

•  Lorsqu’il existe entre deux entités une relation dont les cardinalités sont (0,1) à (1,1), on ne peut pas, en théorie regrouper ces deux objets en un seul (on ne peut faire ce regroupement que lorsque les cardinalités sont (1,1) à (1,1), et en principe on obtient un seul objet dès l’étape 3)

•  Lorsqu’on a reconnu une entité E1, identifiée par un attribut A1, et qu’on a un objet non identifiable E2, dont l’identification est externe, et complètement réalisée en associant l’identifiant A1 à l’objet E2, on a alors une “entité relative sans identifiant interne”, et les cardinalités de la relation identifiante sont alors (1,1) à (0,1)

Dans ces deux cas, il est peu rentable de manipuler deux entités et une relation, alors qu’en fait il suffirait de regrouper malgré tout ces deux objets en un seul, en précisant que les attributs du 2° objet ne seront pas toujours renseignés (au prix d’une contrainte : Tous les attributs provenant de ce deuxième objets devront être simultanément renseignés ou non)

Sur le terrain, je réalise systématiquement cette optimisation au niveau du MLD, mais ON NE PEUT PAS OPTIMISER UN MCD.

C’est ici qu’on peut faire apparaître la notion de sous entité : on dit que E2 est une sous-entité de E1, sans identifiant. UN SGBD intégrant le concept d’héritage pourra manipuler les occurences de E1 qui ne correspondent à aucune occurence 1. de E2 dans une table E1, et les occurences de E1 qui correspondent à une (et donc une seule) occurence de E2 dans une table enrichie E1+E2. Ceci correspond à peu près à la notion d’enregistrement avec partie variante du langage Pascal : Record Case )

Remarques :