Table des matières
IV.1 Le modèle logique de données
IV.1.1 Le modèle relationnel du point de vue MERISE
Dans le jargon de la méthode MERISE, le modèle relationnel est équivalent au Modèle logique de données (MLD). Un modèle logique de données est la représentation des données d’un système d’information réalisé en vue d’une mise en oeuvre au sein d’un système de gestion de base de données relationnel (SGBD-R).
Les données sont représentées sous forme de tables et de relations entre tables. Le modèle logique est le modèle conceptuel plus la réponse aux contraintes d’organisation des données. En autre, il nous permet de préfigurer le temps d’accès et l’espace nécessaire
La différence entre un modèle conceptuel de données (MCD) et un modèle logique de données (MLD) relève du niveau d’abstraction à l’image d’une carte de géographie et d’un plan de ville.
Le MCD est la représentation la plus abstraite que l’on réalise de la structure des données d’un système d’information. Il est constitué d’entités qui représentent des ensembles de données de même nature et d’associations entre entités.
Le MLD est une représentation qui prend en compte le choix technologique de la réalisation de la future base de données. C’est une étape intermédiaire pour passer du modèle Entité-Associations, qui est un modèle sémantique, vers une représentation physique des données (fichiers de la base de données).
IV.2 Le passage du MCD vers le MLD
Nous abordons maintenant la traduction d’un MCD en un MLD. Il s’agit essentiellement de définir une méthode qui permet de représenter les ensembles d’entités et de liens par des tables.
IV.2.1 Règle de base
Chaque ensemble d’entités doit être traduit en une table distincte, dotée d’une clé primaire.
La première règle du passage du MCD au MLD est résumé dans les étapes suivantes :
· Une entité du MCD devient une table/relation .
- Le nom de l’entité devient le nom de la table
· Son identifiant devient la clé primaire de la table don’t la valeur est unique pour chaque tuple (ligne) .
· Les autres propriétés deviennent les attributs de la table.
Exemple
IV.2.2 Association binaire (1.1) – (0.n) ou (1.1) – (1.n)
L’entité ayant la cardinalité de type 1,1 ou 0,1 absorbe l’identifiant de l’entité la plus forte (0, n ou 1, n). Cet identifiant est alors appelé la clé étrangère.
Autrement dit, on ajoute une clé étrangère (identifiant de l’entité ayant la cardinalité (0.n)) à la table provenant de l’entité dont la cardinalité est (1.1)
La clé étrangère doit correspondre à une clé primaire déja existante.
IV.2.3 Association binaire (1.1) – (0.1)
L’entité ayant la cardinalité de type (1,1) absorbe l’identifiant de l’entité (0.1). Cet identifiant est alors appelé la clé étrangère.
Autrement dit, on ajoute une clé étrangère (identifiant de l’entité ayant la cardinalité (0.1)) à la table provenant de l’entité dont la cardinalité est (1.1)
La clé étrangère doit correspondre à une clé primaire déja existante.
IV.2.4 Association binaire (1.1) – (1.1) ou (0.1) – (0.1)
Dans ce cas, On duplique la clé d’une des tables dans l’autre. Lorsque la relation contient elle même
des propriétés, celles-ci deviennent également attributs de la table dans laquelle a
été ajoutée la clé étrangère.
IV.2.5 Association binaire (x.n) – (x.n)
Ici, x prend la valeur 0 ou 1. Dans ce cas, on crée une table supplémentaire ayant comme clé primaire une clé composée des clés primaires des deux tables. Lorsque la relation contient elle-même des propriétés, celles-ci deviennent attributs de la table supplémentaire. Une propriété de la relation qui est soulignée devra appartenir à la clé primaire composée de la table supplémentaire.
Ainsi, l’association se traduit par la création d’une table dont la clé primaire est composée des clés étrangères référençant les relations correspondant aux entités liées par l’association . Les éventuelles propriétés de l’association deviennent des attributs de la relation.
IV.2.6 Plusieurs associations entre deux entités
Dans ce cas, les règles générales s’appliquent séparement pour chaque association.
La relation habiter du type (1,n)-(1,1), est traduite par la migration de l’attribut Adresse dans la table Personne. La relation posséder du type (1,n)-(1 ,n) est traduite par la création d’une table supplémentaire du même nom. Cette table contient comme clé primaire composée, les clés des deux tables reliées Personne et Maison. On a donc simplement appliqué deux fois de façon indépendante les règles de transfert MCD vers le MLD.
IV.2.7 Association n-aire
On crée une table supplémentaire ayant comme clé primaire une clé composée des clés primaires de toutes les tables reliées. Cette règle s’applique de façon indépendante des différentes cardinalités. Lorsque la relation contient elle-même des propriétés, celles-ci deviennent attributs de la table supplémentaire. Une propriété de la relation qui est soulignée devra appartenir à la clé primaire composée de la table supplémentaire.
IV.2.8 Association réflexive
Nous appliquons les règles générales avec la seule différence que la relation est deux fois reliée à la même entité. Les règles de passage du MCD au MLD s’appliquent toujours aussi mécaniquement. L’entité ayant la cardinalité la plus faible absorbe l’identifiant de l’entité reliée. Ici, nous n’avons qu’une seule entité, mais le principe est le même nous devons donc dupliquer l’identifiant NO_SOCIETE
