IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Petit guide d'analyse des données à l'aide de la méthode MERISE

Petit guide d'analyse des données à l'aide de la méthode MERISE


précédentsommairesuivant

5. De la théorie à la pratique

Ce que nous venons de voir concerne l'analyse conceptuelle des données, c'est à dire un niveau d'analyse qui s'affranchi de toutes les contraintes de la base de données sur lequel va reposer l'application. Une fois décrit sous forme graphique, ce modèle est couramment appelé MCD pour "Modèle Conceptuel des Données".

Dès lors, tout MCD peut être tansformé en un MPD ("Modèle Physique des Données") c'est à dire un modèle directement exploitable par la base de données que vous voulez utiliser...

Tout l'intérêt de cet outil d'analyse est de permettre de modéliser plus aisément les relations existant entre les entités et d'automatiser le passage du schéma muni d'attributs aux tables de la base de données pourvues de leurs champs.

Voici maintenant les règles de base nécessaire à une bonne automatisation du passage du MCD au MPD :

5.1. Transformation des entités (passer de l'entité à la table)

Règle n°1 : toute entité doit être représentée par une table.

5.1.1. Relation de type 1:1 (la voix de la simplicité)

Règle n°2 : Dans le cas d'entités reliées par des associations de type 1:1, les tables doivent avoir la même clef.

Exemple :

Image non disponible

NOTA : on aurait pu choisir l'autre clef comme clef commune, à savoir le n° d'appartement.

Bien que certains systèmes proposent une autre solution :

Image non disponible

Dans ce cas une étude approfondie de la solution à adopter est nécessaire, mais ce type de relation est en général assez rare et peu performante...

5.1.2. Relation de type 1:n (maître et esclave)

Règle n°3 : Dans le cas d'entités reliées par des associations de type 1:n, chaque table possède sa propre clef, mais la clef de l'entité côté 0,n (ou 1,n) migre vers la table côté 0,1 (ou 1,1) et devient une clef étrangère (index secondaire).

Exemple :

Image non disponible

5.1.3. Relation de type n:m (plusieurs à plusieurs)

Règle n°4 : Dans le cas d'entités reliées par des associations de type n:m, une table intermédiaire dite table de jointure, doit être créée, et doit posséder comme clef primaire une conjonction des clefs primaires des deux tables pour lesquelles elle sert de jointure.

Exemple :

Image non disponible

5.2. Ou placer les attributs d'association ?

Règle n°5 : Cas des associations pourvues d'au moins un attribut :

  • si le type de relation est n:m, alors les attributs de l'association deviennent des attributs de la table de jointure.
  • si le type de relation est 1:n, il convient de faire glisser les attributs vers l'entités pourvue des cardinalités 1:1.
  • si le type de relation est 1:1, il convient de faire glisser les attributs vers l'une ou l'autre des entités.

Pour synthétiser toutes ces règles, voici un exemple de modélisation d'une application. En l'occurrence il s'agit d'un service commercial désirant modéliser les commandes de ses clients.

Exemple :

Image non disponible

précédentsommairesuivant

Copyright © 2003 Frédéric Brouard. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.