Analyse des données par la méthode Merise
Présentation
La méthode d’analyse Merise est apparue en France dans les années 1970. Elle sert à concevoir et réaliser des systèmes d’information. Elle a 2 objectifs :
Elle est constituée sur la base d’un modèle entité – relation.
Le Modèle Conceptuel des Données (MCD) permet de décrire la structure des données manipulées par l’entreprise ainsi que les liens qui les unissent.
Le Modèle Conceptuel des Traitements (MCT) décrit les traitements à réaliser en réponse à divers évènements (passage d’une commande).
Le Modèle Logique des Données (MLD) décrit les données telles qu’elles se présenteront dans le système d’information final sans avoir encore choisi le logiciel qui sera utilisé.
Nous nous intéresserons uniquement au MCD dans la suite du cours. Pour passer aux données réelles sur MySQL, nous décrirons également le Modèle Physique des Données (MPD) qui est la traduction du MCD en langage informatique selon le logiciel retenu.
Les Entités et attributs
Il s’agit d’un regroupement d’informations. Une entité est une population d’individus homogènes (ex : clients).
Une entité est dotée d’attributs. L’attribut est le plus petit élément d’information manipulé possible.
Ainsi l’entité Clients d’une entreprise contiendra les attributs Nom_Client, Prenom_Client, Adresse, Code_Postal, Commune etc.
Il est possible de définir un attribut Nom_Prenom. Cela pose le problème de la manipulation de cet attribut. Pour un tri par ordre alphabétique, il faut bien mettre en premier le nom puis le prénom. En revanche, les règles de courtoisie nous imposent d’écrire en positionnant le prénom avant le nom (j’écris à M. Xavier Durand). On voit toute la difficulté d’un attribut Nom_Prénom regroupé.
A contrario il ne faut pas tomber dans l’excès qui voudrait par exemple décomposer la date de naissance en 3 attributs Jour_Naissance, Mois_Naissance, Annee_Naissance. Les logiciels interprètent très bien les dates et des fonctions permettent d’extraire les parties de dates souhaitées.
Il n’est pas non plus nécessaire, sauf cas rare, de décomposer excessivement une adresse. Le bon niveau de découpage dépend de l’utilisation ultérieure de la base de données.
L’intérêt d’une base de données est d’éviter les redondances. On pourrait imaginer que, dans le cas d’une entité client évoquée ci-dessus, un nombre important de clients sont regroupés sur un petit nombre d’adresses (quelques immeubles). Dans ce cas on s’interrogera sur la pertinence de définir une entité Immeubles. Dans la pratique ce cas est rare.
Une entité est identifiable et dotée d’une existence propre. Elle est schématisée par un rectangle.
Les attributs sont les caractéristiques qui permettent de décrire les entités. On précise le type de données pour chaque attribut. Les noms doivent être simples et significatifs autant que faire se peut.
Identifiant d’une entité
Chaque occurrence d’une entité doit pouvoir être identifiée de manière sûre et certaine. Il ne doit exister aucune ambiguïté par rapport aux autres. L’identifiant est un attribut particulier d’une entité.
L’identifiant est un attribut ou un ensemble d’attributs permettant de caractériser de manière unique chaque occurrence d’une entité.
En informatique la recherche sur l’identifiant permet d’accélérer considérablement le traitement des données. Il fiabilise et assure la cohérence des données.
L’identifiant détermine l’ensemble des attributs d’une occurrence au sein d’une entité.
La représentation de l’identifiant se fait en soulignant cet attribut et en le plaçant en tête de l’entité.
S’agissant de l’exemple Clients ci-dessus, on pourrait choisir l’attribut Nom_Client comme identifiant. Comme cet attribut détermine de manière sûre et unique l’occurrence au sein de l’entité, cela suppose alors qu’il n’y ait aucune homonymie. Le problème n’est pas résolu en concaténant le nom et le prénom puisque 2 clients peuvent avoir le même nom et prénom. On comprend bien que si l’on prolonge en complexifiant l’identifiant, les données deviennent difficiles à manipuler.
Il se trouve que les logiciels sont plus à l’aise dans la manipulation de données numériques que de données alphanumériques. Il est fortement conseillé d’utiliser des identifiants numériques à de très rares exceptions près. Il n’est toutefois pas interdit d’utiliser des chaînes de caractères.
Dans la plupart des SGBD, il est possible d’utiliser un identifiant numérique automatique. Outre le confort d’utilisation, cette technique permet d'optimiser les ressources.
L’identifiant est unique, obligatoire et invariable (une occurrence ne change pas d’identifiant). Il permet d’assurer l’intégrité référentielle de la base de données.
Les relations (ou associations)
Les relations décrivent les liaisons entre entités. Dans le MCD elles sont représentées par une ellipse reliée à au moins 2 entités. Elles sont désignées par un verbe.
Dans l’exemple ci-dessus, sont décrites les relations qui existent entre l’entité Personne et l’entité Ville. Ainsi un individu au sein de l’entité Personne peut habiter une ville quelconque de l’entité Ville, être né dans une autre ville et travailler dans une troisième ville.
Ex : M. Martin est né à Nantes, habite Rennes et travaille à Bruz.
M. Jacques est né à Rennes, habite Rennes et travaille à Cesson.
Les cardinalités
Les cardinalités permettent de dénombrer les occurrences d’une entité de départ en relation avec les occurrences d’une entité d’arrivée et inversement. Autrement dit, c’est le nombre d’occurrences possibles de la relation pour une occurrence de l’entité.
Pour cela on se place sur une occurrence de l’entité de départ et on se pose la question de savoir à combien d’occurrences de l’entité d’arrivée est elle reliée au minimum et à combien au maximum.
Exemple ci-dessus du côté de l’entité Personne : M. Martin est né au minimum dans une ville et au maximum dans une ville. Il travaille au minimum dans 0 ville (chômage) et au maximum dans plusieurs villes (dans ce cas, la cardinalité maximale est n sans chercher un nombre précis qui est ignoré à priori et de toute façon n’a pas d’intérêt). Il habite au minimum dans une ville et au maximum dans plusieurs villes (résidence secondaire).
Selon ce que nous souhaitons faire de notre base de données les réponses ne seront pas forcément les mêmes. Si je ne veux pas forcément enregistrer la ville de naissance d’une personne, je peux concevoir que la cardinalité minimale de la relation naître est 0.
Exemple du côté de l’entité Ville : 1 ville peut avoir au minimum 0 habitant et au maximum plusieurs habitants, le nombre de personnes nées dans cette ville varie de 0 à plusieurs et le nombre de personnes y travaillant varie également de 0 à plusieurs.
Traduction sur le MCD
Dans la plupart des cas, les relations sont binaires. Elles relient deux entités. C’est le cas des trois relations ci-dessus.
Attributs de relation
Considérons la quantité d’articles commandée par un client.
La question posée est de savoir où positionner l’attribut quantité commandée dans chaque commande pour chaque article.
Si la quantité est un attribut de l’entité Article, cela signifie que toutes les commandes contiendront la même quantité d’un article donné. Par exemple, il ne sera pas possible de commander autre chose que 5 Stylos bleus ou 8 stylos rouges.
Si la quantité est un attribut de l’entité commande, chaque ligne de la commande contiendra la même quantité d’articles. Par exemple 8 stylos rouges et 8 stylos rouges.
Pour résoudre le problème la seule solution consiste à positionner l’attribut quantité dans la relation Contenir.
Relations particulières
Relations n-aires (à éviter)
Il peut arriver qu’une relation concerne plus de deux entités.
Dans ce cas il faudra ramener cette relation à trois relations binaires pour pouvoir transcrire le modèle informatiquement
La relation réflexive
Supposons que nous ayons à gérer une base de données d’animaux pour lesquels on enregistrera la généalogie (Pédigrée pour les chiens). Le problème est le même en généalogie humaine.
Il nous faut donc connaître les chiens mais également leurs pères et mères. En première intention, on serait tenté de créer une entité Pères et une entité Mères. Cela étant quand un chien devient lui-même parent, il faut le basculer dans une des 2 tables selon son sexe et monter d’un cran son père et sa mère. Le problème devient vite insoluble.
Le problème est pourtant facilement résolu grâce à la relation réflexive. On construit une relation sur la table elle-même.
Les cardinalités se lisent de la façon suivante :
Un chien a au minimum 0 et au maximum 2 parents. Le 0 signifie que l’on accepte de démarrer les enregistrements avec des chiens dont on ne connaît pas la parenté, il faut bien un début. Un chien est parent d’au minimum 0 et au maximum n autres chiens.
La construction du MCD
Illustration des différentes étapes au travers de la base de données d'un logiciel de gestion d'un collège.
Le MCD peut être réalisé sur papier ou avec un logiciel dédié (il en existe bien d'autres, payants ou pas).
Construire le catalogue des données
Il s'agit de réaliser l'inventaire de toutes les données du système d'information.
Épuration, suppression de tous les synonymes et polysémies
Il se peut que dans le catalogue des données, on trouve des synonymes (plusieurs mots désignent le même attribut ou la même entité) ou des polysémies (un même mot désigne plusieurs attributs ou entités différents). Il convient de résoudre ces problèmes.
Construction des entités
Mise en place dans un premier temps des entités naturelles.
Rattachement des attributs à chaque entité.
Préciser l’identifiant de chaque entité.
L'attribut "Note" ne peut être rattaché à aucune entité, puisqu'il dépend à la fois d'un contrôle et d'un élève.
Recherche des relations entre entités
L'attribut "Note" est rattaché à la relation participer.
Etude des cardinalités
Vérification des relations vides d’attributs, sont elles opportunes ?
Simplification des relations n-aires
Normalisation du MCD
Il s'agit de renommer entités et attributs afin de faciliter l'utilisation ultérieure de la base de données : il convient de supprimer les accents, les espaces, ... Par convention, les noms des entités et attributs sont en minuscules.
Passage du MCD au MPD
Les entités deviennent des tables
Les attributs deviennent des champs
Les occurrences constituent des enregistrements.
Lors de la construction du MCD nous avons pu remarquer qu’il existait 2 grands types de relations en examinant la cardinalité maximale de chaque côté de la relation :
- Les relations de type N/N (1,n / 1,n) (0,n / 1,n) ou (0,n / 0,n)
- Les relation de type 1/N (1,1 / 1,n) (0,1 / 0,n) (0,1 /1,n) (0,1 / 0,1)
Selon le type de relation, il y aura création ou non d’une nouvelle table.
Les relations de type N/N
Une relation se transforme en table et sa clé primaire est composée des identifiants des entités qui lui sont liées. Les éventuelles propriétés des relations deviennent des champs de la table.
Les cardinalités maximales de chaque côté de la relation basculent vers la nouvelle table. Cela signifie qu’à chaque enregistrement d’une entité mère peuvent correspondre 0 ou plusieurs enregistrements de la nouvelle table. Pour une valeur donnée de identA et une valeur donnée de identB, il ne peut exister qu’une seule valeur du couple identA, identB dans la table Relation.
Pour une valeur du couple identA, identB de la table Relation, il n’existe qu’une seule valeur identA dans la table Entité A et une seule valeur identB de la table Entité B. Une valeur donnée de IdentA peut être liée à plusieurs valeurs de identB pour former des couples uniques identA, identB au sein de la table Relation.
C’est l’application de la règle de l’intégrité référentielle. Par construction, une clé primaire ne peut pas avoir de doublon. La règle de l’intégrité référentielle assure qu’il est impossible de créer un enregistrement dans une table fille s’il n’existe pas au préalable un enregistrement en relation dans la table mère. Cela signifie par exemple qu’il est impossible de créer une commande pour un client qui n’existe pas dans la table clients. L’application de cette règle est fondamentale pour assurer la cohérence d’une base de données.
Les relations de type 1/N
Il s’agit d’une relation hiérarchique (Mère-fille)
Les cardinalités maximales de chaque côté de la relation sont basculées vers l’autre table. L’identifiant de la table du côté 1 de la relation est ajouté comme champ de la table du côté n de la relation et devient ce qu’on appelle une clé étrangère de cette table
Pour chaque occurrence de IdentB, il existe 0 ou n occurrences liées dans Entité A. De même que dans le cas précédent, la règle de l’intégrité référentielle permet de s’assurer qu’il n’est possible de créer un enregistrement dans la table EntitéA lié à un enregistrement de l’entité B que s’il existe au préalable une valeur correspondante d’identB dans l’entité B. Par exemple dans une association, il sera impossible d’enregistrer le paiement d’une cotisation pour un adhérent qui n’a pas été au préalable entré dans la table des adhérents.
Remarques
L’application de l’intégrité référentielle impose un ordre de saisie. Il faut d’abord saisir les données dans les tables mères pour pouvoir générer un enregistrement dépendant dans une table fille.
Cas de la relation réflexive
L’identifiant sera répliqué autant de fois que nécessaire dans la table sous un autre nom. Le MCD de l’exemple avec les chiens donnera la table ci-dessous :
Les champs Num_pere et Num_mere seront mis en relation avec l’identifiant en répliquant la table pour simuler une table Chiens Pères et une table Chiens mères. On utilise un alias pour renommer les duplicata de la table.
MPD du logiciel de gestion d'un collège
