mcd & mpd

UFR de Mathématiques et Informatique [pic]
Réf. BD2Cours.doc *** Module *.* (Partiel et examen)
Date dernière version : Mai 2002 Diffusion : apprenants
Auteur : Stéphane LAMBERT
MERISE : MCD & MPD
APPROCHE THEORIQUE
1°) MCD : Modèle Conceptuel de Donnée
A - Méthodologie de construction du MCD La méthode décrite ici est basée sur MERISE, méthode française qui a plus
de 20 ans. Elle consiste à concevoir un Modèle Conceptuel de Données (MCD),
qui sera transposé en Modèle Logique de Données Relationnelles (MLDR),
lequel générera le Modèle Physique de Données (MPD) correspondant à la Base
choisie. C'est la plus répandue des techniques d'analyse de Base de Donnée.
Elle intègre un formalisme graphique très simple. Nous étudierons plus particulièrement dans cet article la construction du
Modèle Conceptuel de Données et de ses 5 caractéristiques : Entités,
Propriétés, Identifiants, Associations, Cardinalités. Il est intéressant de remarquer qu'à ce stade de la conception, toute la
méthodologie est strictement indépendante du matériel, du système
d'exploitation, ainsi que du système de base de données.
B - Décrire le système d'information Durant la phase d'apprentissage, il est conseillé de transformer ce que
l'on veut analyser en mots simples. L'écriture de cette petite rédaction
permet à elle seule de bien comprendre ce que l'on va modéliser, ce que
l'on appelle le Système d'Information (S.I.). L'analyste passera
directement à la phase de schématisation une fois le processus bien
assimilé. Il s'agit aussi à ce stade d'établir un lien entre l'informaticien et les
utilisateurs, il ne faut donc pas hésiter à faire relire votre petit texte
et à poser toutes les questions qui vous viennent à l'esprit, afin de bien
analyser l'existant. La difficulté principale est d'arriver à faire
abstraction des habitudes de programmation : à ce stade, nous sommes
totalement indépendants du matériel et du logiciel. Il ne faut pas penser
en terme de tables, mais en terme d'entités. Prenons l'exemple très simple d'un logiciel (ou partie de site Web) ayant
pour but de gérer les envois de NewsLetters aux abonnés d'un site ayant
plusieurs rubriques. Le service marketing veut aussi savoir quelle raison a
poussé l'abonné à s'inscrire en lui proposant plusieurs choix de
motivations lors de son inscription. Le système d'information se décrit ainsi : "Un abonné est inscrit à une ou
plusieurs rubrique. Chaque rubrique envoie une NewsLetter chaque semaine,
aux abonnés de la rubrique correspondante. Un abonné a une motivation
d'inscription parmi plusieurs possibles." Ces quelques phrases, si elles sont exactes et validées par le client, sont
suffisantes pour modéliser notre premier modèle. Elles contiennent en effet
toutes les informations nécessaires. La méthode de modélisation comprend 5 étapes simples : 1 - Identifier les entités présentes L'entité ABONNES représente l'ensemble des abonnés.
L'entité RUBRIQUES l'ensemble des rubriques auxquelles l'abonné peux
s'inscrire.
L'entité NEWSLETTERS représente les newsletters envoyées,
MOTIVATIONS l'ensemble des motivations d'inscriptions des abonnés. D'où les 4 entités : [pic]
Une légère analyse grammaticale suffit bien souvent à identifier les
entités présentes : ce sont les verbes et les compléments d'objets de
l'analyse du système d'information. Généralement, une entité est créée dans le système d'information si elle
possède au moins 2 occurrences. Chaque élément d'une entité est appelé une
occurrence de l'entité. 2 - Lister les propriétés des entités Un Abonné est caractérisé par son nom, son prénom, son âge, son sexe, sa
profession, sa rue, son code postal, sa ville, son pays, son téléphone et
son email.
Une Newsletter est caractérisée par son sujet, sa date d'envoi et son
contenu.
Une Motivation est caractérisée par son intitulé.
Une Rubrique est caractérisée par son nom. Les 4 entités deviennent : [pic]
Afin de ne pas en avoir trop, on se limite généralement aux propriétés
nécessaires au développement. Chaque propriété doit avoir une seule valeur
possible pour chaque occurrence, sinon il s'agit d'une entité. Elle doit de
plus être élémentaire et non-décomposable. Par exemple, l'adresse n'est pas
une propriété élémentaire : elle comporte une rue, un Code Postal et une
ville qui elles, sont 3 propriétés élémentaires.
3 - Identifier de manière unique chaque occurrence Imaginons que nous ayons deux abonnés qui s'appellent DUPOND : il est
nécessaire de les distinguer sous peine de les confondre. On rajoute alors
une propriété qui permettra d'identifier de manière unique chaque
occurrence. Cette propriété est appelée l'identifiant de l'entité. Cela
peut être une référence interne, un code, ou plus généralement un nombre
entier. Cette propriété est soulignée afin de mettre en évidence son rôle
d'identifiant. Les 4 entités sont finalement : [pic]
4 - Etablir les relations entre les différentes entités maintenant, il s'agit d'identifier les relations entre les entités.
Généralement, la simple transposition du texte suffit, les sujets et
compléments d'objets étant les entités, et les verbes les relations. Reprenons notre texte initial :
"Un Abonné a une Motivation. Un Abonné s'inscrit à une ou plusieurs
Rubriques. Chaque Rubrique envoie une NewsLetter." Les verbes sont en rouge et relient les entités. Il suffit de les intégrer
au schéma : [pic] 5 - Identifier les cardinalités Il faut maintenant établir le nombre possible d'interactions entre les
entités. Il s'agit d'un couple d'entiers de type (a ; b).
a est la cardinalité minimum, et est égal à 0 ou 1.
b est la cardinalité maximum, et est égal à 1 ou n, n étant plus grand que
1. Continuons notre exemple :
Un Abonné a ici une et une seule Motivation d'inscription, le marketing
ayant imposé un champ obligatoire afin d'avoir cette valeur. On a donc 1
minimum, et 1 maximum. D'où la cardinalité (1 ; 1).
Une Motivation donnée concerne 0 ou plusieurs Abonnés. On a donc 0 minimum,
et n en maximum. D'où la cardinalité (0 ; n).
De même, un Abonné s'inscrit à une ou plusieurs Rubriques : (1 ; n),
Et une Rubrique possède 0 ou plusieurs Abonnés : (0 ; n).
Enfin, une Rubrique envoie 0 ou plusieurs Newsletters : (0 ; n),
Et une Newsletter appartient à une et une seule Newsletter : (1 ; 1). Il suffit maintenant de marquer ces couples sur le schéma, et nous avons
notre Modèle Conceptuel de Donnée (MCD) : [pic]
Et pour finir : Valider le Modèle avec le client A ce stade, il est aisé d'aller voir encore une fois les utilisateurs du
logiciel final, afin de discuter le MCD avec eux. Cela vous permettra
d'entériner les propriétés qu'ils désirent utiliser, d'être bien certain
des cardinalités, et de valider avec eux cette partie de votre travail. Un
MCD doit pouvoir s'expliquer avec des phrases simples et être
compréhensible par tout le monde. Il ne s'agit ni plus ni moins que de
modéliser l'existant. Ainsi, vous serez certain de faire le développement
demandé, et cela vous permettra de vous protéger par la suite en cas de
nouvelles demandes ou de modifications du cahier des charges. Il est important de bien réaliser que jusqu'à ce stade, toute cette analyse
s'est déroulée totalement indépendamment de la machine ou de toute
contrainte logicielle. Ces règles fonctionnent toujours, même s'il peut y avoir parfois plusieurs
solutions pour chaque modèle. Le processus de modélisation, après quelques
tentatives, est très simple à acquérir. Enfin, une fois le Modèle
Conceptuel de Donnée établi, vous aurez fait le plus difficile. La
conception de la base qui en découle est mécanique, et repose sur 6 règles
strictes, nécessaires et suffisantes. Transformer un MCD en Modèle Logique,
puis Physique est tellement standardisé que certains logiciels le font
automatiquement... 2°) MPD : Modèle Physique de Donnée Transformer un Modèle Conceptuel de Données (MCD) en Modèle Physique de
Données (MPD) repose sur 6 règles simples, nécessaires et suffisantes. Que
cette transformation soit manuelle ou assistée par un logiciel de
modélisation, il est utile de posséder les connaissances théoriques sur le
sujet. Auparavant, il faudra bien sûr acquérir les notions de clé primaire,
de clé étrangère, ainsi que quelques termes élémentaires.
Préliminaires : Un peu de vocabulaire : Les données sont stockées dans des relations. Une
relation est un ensemble de T-uple, et un T-uple est défini par un ou
plusieurs attributs. Dans la pratique, la relation est en fait la table, un
T-uple est une ligne (ou enregistrement), et les attributs sont les
colonnes. Les attributs sont aussi appelés champs. Exemple d'une table, appelée NEWSLETTER : [pic]
Cette table est décrite ainsi :
NEWSLETTER (id_newsletter, Sujet, DateEnvoie, Contenu, #id_rubrique)
Exemple d'une autre table, appelée RUBRIQUE : [pic]
Cette table, elle, est décrite ainsi :
RUBRIQUE (id_rubrique, Nom)
Chaque enregistrement doit être identifié de manière unique (voir la notion
d'identifiant abordée dans l'article précédent). L'attribut qui permet
d'identifier de façon unique chaque ligne est appelée la Clé Primaire. Elle
peut être composée, c'est-à-dire comprendre plusieurs attributs. Pour
NEWSLETTER, il s'agit de l'attribut id_newsletter. Pour RUBRIQUE, il s'agit
de l'attribut id_rubrique.
La table NEWSLETTER comprend un attribut provenant de la table RUBRIQUES,
l'attribut id_rubrique. Cet attribut est appelé Clé Etrangère. Ici, il sert
par exemple à retrouver les Newsletters correspondantes à une rubrique
donnée.
Dans le formalisme, la clé primaire est soulignée, et la clé étrangère est
précédée du signe #. D'où l'écriture définitive :
MATABLE (Cle_Primaire, Colonne1, Colonne2, #Cle_Etrangere) Rappel de notre exemple :
NEWSLETT