Modèle Merise le MCD, MLD et le MPD support de cours
Modèle conceptuel de données
Il s’agit de la représentation schématique des données, et des liens entre elles. Le MCD est également appelé schéma conceptuel.
Le MCD est un outil de communication, tant interne qu’externe à l’organisation.
Notion d’entité
Il s’agit d’un individu (ensemble de client) ou objet, concret (produit fini) ou abstrait (bon de commande), pourvu d’une existence propre.
Notion d'entité faible
Il s'agit d'une entité dépendant d'une autre entité.
L'identifiant de l'entité "forte" (père) intervient dans l'identifiant de l'entité "faible" (il s'agit généralement de code articulé)
Notion d’occurrence d’entité
Un ensemble de valeur prise par les propriétés de l’entité (1 client, 1 produit...) La notion d'occurrence n'apparaît pas dans le MCD.
Notion de propriété
Information élémentaire (indécomposable) qui décrit un caractère de l’entité (ou den l’association).
On considère que les adresses, dates ou codes comme étant un élément élémentaire.
Un nom de propriété est unique et atomique (n’admet qu’une valeur à la fois).
On ne donne pas de nom d'entité à des propriétés.
Notion d’identifiant
Une (ou plusieurs) propriété(s) permettant de distinguer chaque occurrence de l’entité. L’identifiant est souligné dans le MCD ; chaque entité possède un identifiant.
Notion d’association
Il s’agit d’un lien entre entité(s). Une association porte toujours le nom d’un infinitif.
Notion de cardinalité
Couple de valeurs (Cm, CM)[Cardinalité minimale, Cardinalité Maximale] quantifiant chaque "patte" d’une association. La cardinalité définie le nombre de fois que chaque occurrence de l'entité participe aux occurrences de l'association.
...
Association
Dimension d'une association
Nombre d'occurrences d'entités qui participe à une occurrence de l'association (~nombre de patte). Dans l'exemple ci-dessus, PASSER est de dimension 2.
Une association de dimension 2 est binaire, dimension 3 est ternaire et dimension 4 est quaternaire.
Classification en fonction des cardinalités
Si présence du couple de cardinalité (1,1) sur une des pattes, l'association est alors appelée Contrainte d'Intégrité Fonctionnelle (ou association hiérarchique [père-fils]). Une CIF est toujours binaire et n'est jamais porteuse d'information.
Association multiple
Sur chacune des pattes se trouvent des couples tels que (0,n), (1,n)... différents de (1,1). Lorsqu'elles ne sont pas porteuses d'informations, il s'agit de Contrainte d'Intégrité Multiple.
On exprime les cardinalités dans un tableau tel que ci-dessous
Cas particulier : association réflexive
Association de dimension 2, ou plus, reliant une entité à elle-même.
Dépendance fonctionnelle forte
Notion fondamentale en conception des systèmes d'information.
a b avec a,b des propriétés
dF a détermine b, ou b dépend fonctionnellement a.
C'est à dire que si on a connaissance d'une valeur de la propriété a alors on connaît une valeur de la propriété b.
Propriétés :
Ø Réflexivité : a a
Ø Transitivité : a b et b c alors a c
Ø Augmentation : a b alors a,c b
Ø Dépendance fonctionnelle directe : dF non obtenue par transitivité a b dF direct il n'existe pas c tel que a c et c b
Ø Dépendance fonctionnelle élémentaire : dF non obtenue par augmentation a,c b dF élémentaire il n'existe pas a b ou c b
Dépendance fonctionnelle faible
a --> b est faible si quand on a connaissance d'une valeur de a alors on a, au plus, une valeur de b.
Ce type de dépendance fonctionnelle est repéré par l'encerclement en pointillé dans la matrice.
Règles concernant le MCD
Ø Chaque propriété d'une entité est une dépendance fonctionnelle est en dépendance fonctionnelle avec l'identifiant de l'entité
Ø A chaque fois qu'on a une dépendance fonctionnelle entre identifiant d'entité, alors on a une association binaire sur le MCD entre ces deux entités
Méthode de conception du MCD
Dictionnaire des Données Règles de
Gestion
Exemple :
Un examen n°question libellé question n°réponse libellé réponse
n°élève nom, prénom, adresse
n°question, n°réponse @ (signifie qu'il n'y a pas de donnée cible)
Matrice des dépendances fonctionnelles
On crée un tableau à double entrée ; on place en colonne TOUTES les propriétés (entité et information des associations porteuses), et en ligne on reporte le numéro des propriétés qui sont source de dépendance fonctionnelle. On place une étoile à l'intersection entre cette propriété en ligne et celle en colonne, et un 1 pour les propriétés que l'on obtient à partir de cette dernière.
Numéro 1
n°personne 1 *
n°nom 2 1
prénom 3 1
Ce tableau correspond à n°personne → nom, prénom
Dictionnaire des données et des règles de gestion
Grille d'analyse
Document conçu pour recenser l'ensemble des données du système d'information. Le dictionnaire des données contient les données à mémoriser.
Données Documents Catégories Dictionnaire Longueur Nature Type Commentaires
D1 D2 ...Dn P A L
Règles
Ø Une donnée par ligne dans la grille
Ø Une donnée doit être élémentaire (exception : date, adresse, CP, code articulé)
Ø Pas de synonyme (propriétés ayant même sens mais dénommées différemment) ni de polysème (propriétés ayant le même nom mais n'ayant pas le même sens)
Les cases "Documents" cochés indiquent le(s) document(s) dans le(s)quel(s) se trouvent les données correspondantes.
Catégories de propriété
Ø Paramètre : donnée dont la valeur est constante et/ou prévisible et dont l'utilité est ponctuelle
Ø Arithmétique : résultat d'un calcul
Ø Logique : résultat d'une règle de gestion
Nature de propriété
Ø Numérique ; si décimal, préciser la position de la virgule dans les commentaires
Ø Alphanumérique
Ø Booléen
Type de propriété
Ø Signalétique : propriété renseignant sur l'identification d'une entité (information permanente)
Ø Situation : propriété renseignant sur une entité en activité (données en mouvement)
Ø Historique : renseigne sur le passé d'une entité
Ø Commande : renseigne sur la gestion d'une entité
Modèle relationnel
Modèle de base du modèle logique des données.
Notion de domaine
Ensemble de valeurs.
Notion de produit cartésien
Le produit cartésien de plusieurs domaines, notés D1*D2...*Dn, est l'ensemble des valeurs de D1 concaténées à chaque valeur de D2, D3...Dn
Notion de relation
Une relation est sous-ensemble du produit cartésien de plusieurs domaines. Une relation est un tableau à 2 dimensions.
Notion d'attribut
Il s'agit du nom donné à une colonne ; en général, il correspond au nom du domaine.
Notion de tuple
Cela correspond à une ligne de la table (~ nuplet).
Clé d'une relation
Il s'agit d'un ou plusieurs attributs permettant de distinguer chaque tuple de la relation. Chaque attribut d'une relation est en dépendance fonctionnelle avec sa clé. Quand plusieurs attributs peuvent être clé, il s'agit de clés candidates ; celle qui sera choisie sera la clé primaire.
Exemple :
Ø Domaine couleur = {bleu, rouge, vert}
Ø Produit cartésien
D1 = {bleu, blanc, rouge}
D2 = {vrai, faux}
D1 * D2 =
D1 D2
Bleu Vrai
Bleu Faux
Blanc Vrai
Blanc Faux
Rouge Vrai
Rouge Faux
Ø Relation
Couleur de vin =
D1 D2
Bleu Faux
Blanc Vrai
Rouge Vrai
Règles de passage du MCD au MLD
Définition du MLD
Ensemble de relations qui sera traduit physiquement par une base de données.
Règle 1
Chaque entité se traduit par une relation
Entité Relation
Identifiant Clé
Propriété Attribut
Règle 2
L'identifiant de l'entité "père" migre dans la relation qui traduit l'entité "fils". Ce qui constitue une clé étrangère. On l'indique dans la relation avec un #.
...
Relation n-aire (quelles que soient les cardinalités).
Il y a création d'une table supplémentaire ayant comme Clé Primaire la concaténation des identifiants des entités participant à la relation.
Si la relation est porteuse de donnée, celles ci deviennent des attributs pour la nouvelle table.
S.I. :
Un étudiant parle une ou plusieurs langues avec un niveau. Chaque langue est donc parlée par 0 ou n étudiants avec un niveau. Pour chaque niveau, il y a 0 ou plusieurs étudiants qui parlent une langue.
Association Réflexive.
La Clé Primaire de l'entité se dédouble et devient une Clé Etrangère dans la relation ou nouvelle table. Exactement comme si l'entité se dédoublait et était reliée par une relation binaire (X,1) - (X,n) (Cf règle 2).
S.I. :
Prenons l'exemple d'une société organisée de manière pyramidale : chaque employé a 0 ou 1 supérieur hiérarchique direct. Simultanément, chaque employé est le supérieur hiérarchique direct de 0 ou plusieurs employés.
...
Modèle Physique de Donnée :
Une fois le système d'information analysé et modélisé en Modèle Conceptuel de Donnée (MCD), et après être passé par le Modèle Logique de Donnée Relationnel (MLDR), nous arrivons au Modèle Physique de Donnée (MPD). Il s'agit maintenant de créer la base correspondante à l'étude entamée. C'est à ce stade seulement que la base de donnée choisie intervient.
Le SQL (Structured Query Language), ou Langage d'Interrogation Structuré, a été reconnu en tant que norme officielle de langage de requête relationnelle par l'institut ANSI (American National Standards Institute) et par l'organisme ISO (International Standards Organization). Malgré cela, les syntaxes d'extractions des données et de créations des tables varient quelques peux d'une base à l'autre. En particulier, si la base de donnée utilisée pour le développement n'est pas véritablement relationnelle (cas de MySql dans sa version actuelle), il appartiendra au développeur de prendre lui-même en charge les limitations rencontrées, afin de s'assurer que sa base ne puisse JAMAIS être corrompue, c'est à dire contenir des données aberrantes.
APPLICATION SUR UN MODELE PHYSIQUE CONCRET :
Prenons l'exemple du schéma de base (MPD) suivant :
...
O Pour les bases non totalement relationnelles : Il appartiendra au développeur de vérifier lors de chaque insertion dans ABONNES que l'ID_MOTIVATIONS fournis fais partie des valeurs existantes de ID_MOTIVATIONS de MOTIVATIONS. De même, lors de chaque suppression d'un enregistrement de MOTIVATIONS, il faudra vérifier qu'aucun enregistrement d'ABONNES n'utilise la valeur d'ID_MOTIVATION correspondante.
Une telle table est communément appelée "Table de Lien". L'intérêt d'une telle table est que pour chaque ID_ABONNES donné, il est aisé de retrouver tous les ID_RUBRIQUE associés, et vice et versa.
O Pour les bases non totalement relationnelles : Il faudra vérifier lors de chaque insertion dans S_INSCRIT que le couple (ID_ABONNES,ID_RUBRIQUE) n'existe pas déjà dans la table S_INSCRIT, que ID_ABONNES existe dans ABONNES et que ID_RUBRIQUE existe dans RUBRIQUE. De même, pour chaque suppression d'un abonné, il faudra supprimer tous les couples (ID_ABONNES,ID_RUBRIQUE) ayant l'ID_ABONNE correspondant. Pareil pour toute suppression de RUBRIQUE.
O Pour les bases non totalement relationnelles : Il faudra vérifier lors de chaque insertion dans NEWSLETTER que ID_RUBRIQUE existe dans RUBRIQUE. De plus, pour chaque suppression d'une rubrique, il faudra s'interroger sur le sort réservé à chaque newsletter de cette rubrique : les détruire ou les archiver.
APPLICATIONS AUX BASES RELATIONNELLES :
Les vérifications détaillées précédemment n'ont lieu que pour assurer la cohérence de la base. Il est donc logique, si celle ci le permet, de déléguer et d'automatiser ces taches au niveau ce celle-ci. Généralement, les vérifications afférentes à une clé étrangère sont confiées à un Trigger (un Trigger est un ensemble d'instruction SQL s'effectuant avant ou après un événement donné, par exemple une insertion ou une suppression). Ainsi, lors de chaque commande d'insertion sur la table désignée au Trigger préalablement correctement programmé, celui ci va vérifier AVANT l'insertion que la clé étrangère est valable. Dans le cas ou elle ne le serait pas, le Trigger renvoie un message d'erreur et l'insertion ne s'effectue pas, évitant ainsi de corrompre la base. De même, certains traitements automatisés pourront être réalisés directement à l'aide de procédures stockées. Exemple : un devis validé qui entraîne la création de la facture correspondante. Et surtout, les Trigger et Procédures Stockées étant compilées directement par la Base de Donnée, leur exécution est beaucoup plus rapide qu'une série d'instruction SQL envoyées par le programme attaquant la base.
Une base de donnée correctement pensée est à envisager comme un contenant d'information "vivant", forcement cohérent, aux réactions automatisées. Une telle base se suffirait presque à elle-même pour gérer un Système d'Information. Le développement ne consisterait alors plus qu'à afficher son contenu en temps réel, et à fournir les outils d'insertion appropriés. Le rêve...
SECOND EXEMPLE : MODELISER UN DOCUMENT
Il est courant, lors du développement d'un site Web ou de l'informatisation d'un système d'information, de démarrer son analyse par un document. Captures d'écrans, photocopies, sont parfois les principales pièces jointes à la demande de devis, accompagnés du commentaire suivant :
"Je veux faire ça !!!". Bien. Alors, faisons ça...
Système d'Information :
L'entreprise "WebCash" de vente par correspondance désire ajouter à son site un système de consultation de factures visible en ligne pour ses clients. Chaque client, après authentification, pourra accéder à toutes les factures le concernant, qu'elles soient anciennes ou en cours de traitement indifféremment. Pour être sur de bien se faire comprendre, "WebCash" fournis une copie d'une facture type en disant :
"C'est ça qu'on veut sur l'écran !"
