FAQ Merise et modélisation de donnéesConsultez toutes les FAQ

Les règles basique sont les suivantes:

• Pour les entités
  
  
  • Toute entité devient une table.
  • L'identifiant de l'entité devient une clé primaire de cette table.
  • Les propriétés de l'entité deviennent des attributs
    
• Pour les relations, cela dépend de la dimension et des cardinalités
  
  
  • Relation binaire avec une cardinalité *,1
    
    
    • La relation devient un lien référentiel avec une clé étrangère dans la table correspondant à l'entité coté cardinalité *,1
      
  • Relation binaire avec des cardinalités *,n -*,n
    
    • La relation devient une table et des liens référentiels vers les tables correspondant aux entités composant la relation. La clé primaire de cette table est composée des clés étrangères référant aux clés primaires.
      Les éventuelles propriétés de la relation deviennent des attributs de la table.
      
  • Relation ternaire ou plus : Idem 2.2
    
  
  
  

Soit le MCD suivant :


La théorie nous indique qu'il existe 4 possibilités de transformation

• Ne dupliquer dans les tables sous-type que l'identifiant
  
  • Cette solution ne pose aucun problème de redondance. Elle est celle qui minimise la place. On peut "reconstituer" les héritages par des vues SQL.
    
    Le MLD suivant est UNE solution possible :
    
  
  
  

• Dupliquer la totalité du surtype dans les sous types
  
  • On a certes une redondance à gérer mais l'accès est plus facile car on a l'intégralité des informations d'un périphérique spécifique dans une table.
    
• Ne conserver que les sous-types après avoir dupliqué le contenu du surtype
  
  • Conserve les avantages de la solution 2.2 en supprimant la redondance; mais cela exige que l'héritage est un partition.
    
• Tout remonter dans le surtype
  
  • Solution de facilité, une seule table; mais sûrement un grand nombre de valeurs "à vide"; ça dépend comment la base de données gère ces vides.
    
  
  
  

Les relations réflexives suivent les mêmes règle de base que les autres relations. Pour une relation réflexive 0n – 0,1
Elle devient un attribut clé étrangère dans la table transformée, attribut éventuellement suffixé par le rôle de la patte 0,1. Cette clé étrangère réfère à la clé primaire de cette même table.
Attention certains SGBD (Access par exemple) ne supportent pas cette modélisation, il faut alors dédoubler ces tables.
Pour une relation réflexives 01 – 0,1
Il y a alors deux clés étrangères(donc deux liens référentiels) nommées sur le principe ci-dessus. L'optimisation conduira certainement à la suppression d'une d'entre elles. Pour une relation réflexives 0n – 0,n
Elle devient une table, avec les éventuels attributs appartenant à la relation, dont la clé primaire est composée des deux attributs clé étrangères, référant respectivement à la clé primaire de la table (ex-entité). Ces attributs sont suffixés (ou renommés) par le rôle de chacune des pattes correspondantes (d'où l'importance de définir ces rôles dans les outils ).

Pour éviter d'obtenir des noms d'attributs quasi identiques dans chaque table (MPD) ou entité (MLD) lors d'une génération automatique (PowerAMC par exemple), il faut préciser les rôles sur chaque patte de la relation.
Ainsi, le MCD suivant :


La transformation en MLD donne automatiquement le résultat suivant