Discussion :

[Potter89]

Bonjour

Actuellement je m'occupe d'importation des données dans une base Postgresql
J'ai préparer mon schéma conceptuelle relatif à mes données par la suite j'ai utilisé les règles ci-dessous pour faire le passage du modèle conceptuelle au modèle logique:

• Règle 1 : Toute entité devient une relation ayant un identifiant nommé clé primaire. Chaque propriété se transforme en attribut.

• Règle 2 : Toute association hiérarchique (de type [1, n]) se traduit par une clé étrangère. La clé primaire correspondant à l'entité père (côté 1) migre comme clé étrangère dans la relation correspondant à l'entité fils (côté n).

• Règles 3: Toute association non hiérarchique (de type [n, n] ou de dimension > 2) devient une relation. La clé primaire est formée par la concaténation (juxtaposition) l'ensemble des identifiants des entités reliées. Toutes les propriétés éventuelles deviennent des attributs qui ne peuvent pas faire partie de la clé.

Malheureusement, lorsque j'ai terminé tous les importations j'ai installée l'outil SQL power Architect pour faire interfaçage entre ma base Postgresql et modèle conceptuelle je me suis rendu compte que réellement que j'ai inversé le sens de migration de clé pour la règle 2 comme l’indique la figure ci-dessous normalement pour une parcelle j'ai plusieurs coordonnées GPS et non pas l'inverse.



SVP pouvez vous me suggérer une solution pour corriger ce problème?

[JPhi33]

Bonjour Potter89,

• Règle 2 : Toute association hiérarchique (de type [1, n]) se traduit par une clé étrangère. La clé primaire correspondant à l'entité père (côté 1) migre comme clé étrangère dans la relation correspondant à l'entité fils (côté n).

L'inversion vient du fait que dans le modèle EA, l'entité père se situe du côté des cardinalités (*,n) et non pas du "côté 1" (nous reviendrons sur cette notation / terminologie).

Un exemple sera plus parlant. Considérons l'association triviale qui relie un père et ses fils (pas conceptuellement mais dans la vie des humains). On établit les règles de gestion suivantes :

R1. Un père peut avoir plusieurs fils
R2. Un fils a un et un seul père

La règle R1 se traduit par des cardinalités 0,n du côté de l'entité PERE
La règle R2 se traduit par des cardinalités 1,1 du côté de l'entité FILS

Ce qui donne le schéma :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
[ FILS ]--1,1----( )----0,n->[ PERE ]

Lors de la transformation du modèle EA en modèle relationnel, la clé primaire de l'entité PERE (devenue table PERE) migre en tant que clé étrangère dans la table FILS.

Donc la règle est la suivante : La clé primaire de la table correspondant à l'entité père (côté *,n) migre comme clé étrangère dans la table correspondant à l'entité fils (côté 1,1).

La confusion est également possible en raison de l'inversion des cardinalités de la plupart des notations par rapport au modèle EA ou au MCD Merise. Exemple : notation Microsoft Access

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
[ FILS ]--∞--------1--[ PERE ]

Pour terminer, parler du "côté 1" ou du "côté n" est inapproprié s'agissant du modèle EA. En effet, une patte d'association porte toujours un couple de cardinalités.