Discussion :

[nicofromChina]

Bonjour,

Je souhaiterais avoir vos avis/conseils concernant mon schéma entité association.

Là où j'aurais des doutes c'est concernant la clé primaire pour la table "PERSON". Est-elle nécessaire sachant que les tables qui l'héritent ont toutes une clé primaire. J'ai ce doute là car lorsque je passe au model physique des données avec Power Designer, j'ai une clé primaire composée de 2 attributs.
Un autre endroit où je ne suis pas sûr concerne la table "ADDRESS" qui stocke donc les adresses de "PERSON" mais aussi de "REAL_ESTATES" et donc j'ai un doute sur les 2 cardinalités partant de "ADDRESS". J'ai mis des cardinalités de 0,1 car une ligne de cette table ne peut concerner soit que la table "PERSON" soit que la table "REAL_ESTATE". Vaut-il mieux peut-être garder l'association entre les tables "PERSON" et "ADDRESS", supprimer celle entre "ADDRESS" et "REAL_ESTATE" et dans ce cas là rajouter les attributs de la table "ADDRESS" dans la table "REAL_ESTATE"?

Si je n'ai pas été très clair n'hésitez pas.

Bonne soirée.

[ylarvor]

Avec quel outil as tu généré ton schéma entité/relation ?

[nicofromChina]

J'ai fait ça avec Power Designer.

[ylarvor]

Je pense que la cle primaire de la personne est utile mais est ce que POWER DESIGNER ne genere pas une cle primaire automatiquement ?

Quel est la cle primaire dans le modele physique ?

[ylarvor]

Un autre endroit où je ne suis pas sûr concerne la table "ADDRESS" qui stocke donc les adresses de "PERSON" mais aussi de "REAL_ESTATES" et donc j'ai un doute sur les 2 cardinalités partant de "ADDRESS". J'ai mis des cardinalités de 0,1 car une ligne de cette table ne peut concerner soit que la table "PERSON" soit que la table "REAL_ESTATE". Vaut-il mieux peut-être garder l'association entre les tables "PERSON" et "ADDRESS", supprimer celle entre "ADDRESS" et "REAL_ESTATE" et dans ce cas là rajouter les attributs de la table "ADDRESS" dans la table "REAL_ESTATE"?

Je ne pense pas qu'il est souhaitable de rajouter les attribut de adress dans la table real_estate.

il faut simplement que ta cle etrangère vers la table person et vers la table real_estate dans le modele physique accepte la valeur null.
Il semble que ce soit le cas puisque la cardinalite est 0,1

[nicofromChina]

Bonsoir,

Bon je l'ai un peu modifié maintenant.
Qu'en pensez-vous ?

Une petite question:
En fait l'héritage n'est utile que pour le MCD non ? Pour le MPD et le script sql ça n'est pas utile n'est ce pas ?

[nicofromChina]

Au passage il y a un truc que je ne comprend pas, lorsque je passe du MCP au MPD via Power Designer, j'ai le schéma en pièce jointe.
Ce que je ne comprend pas c'est pourquoi il y a la table "REAL_ESTATES". La table "PERSONS" a bien disparu. Pourquoi pas la table "REAL_ESTATES" ?

Merci pour votre aide encore une fois

[Soutou]

Tu dois avoir une option "Generer la classe parent sous forme de table" pour chaque association d'héritage. Tu as du en cocher une et pas l'autre.

[nicofromChina]

Ok mais dans le cas où elle est générée est-ce un problème ou c'est juste pour le schéma ?
La question serait en fait, que vaut-il mieux faire ? Les générer ou ne pas les générer ? Et quelle est la différence au final ?

[Soutou]

ça dépend du type d'héritage (partition, exclusion...). Par exemple si il existe des personnes ni admin, ni tous les autres sous-types, avoir une table personne convient bien.
Essaye d'emprunter

http://www.editions-eyrolles.com/Liv...46255e02c84c24

j'y décris la classification de l'héritage.

[nicofromChina]

Houlà pour l'emprunt ça va être dur car je ne quitte pas mon bureau là car je suis un peu à la bourre dans mon projet alors ...

En fait c'est un héritage "complet", c'est à dire qu'il n'y a pas de personne "PERSON", seulement des personnes correspondant aux tables filles. Dans ce cas là, il y aurait une redondances des données si je les laissais non ?

[Soutou]

Et oui bien sûr. Tu peux faire glisser les colonnes de la sur-tables vers les sous-tables si il n'y a pas d'intersection (admin à la fois register ou autre...).

[nicofromChina]

En fait un OWNER peut aussi être un REGISTERED_USER mais un ADMIN ou AGENT ne peuvent pas être autre chose. Mais dans ce cas si je ne génère pas la sur-table, n'y aura-t-il pas de problème (risque de redondance des données si un owner est aussi un registered user, les infos d'une même personne dans chacune de ces tables quoi) ?

Une question pour être sûr d'avoir compris ce qu'est l'héritage. En fait l'héritage n'est utile que pour le MCD non ? Pour le MPD et le script sql ça n'est pas utile n'est ce pas ?

Merci pour ton aide

[nicofromChina]

Bon voici ce que je pense être ma dernière version. Si vous y voyer une quelconque erreur n'hésitez pas

Voici le MCD:



Voici le MPD:

[Soutou]

L'héritage permet de classifier davantage et de récupérer des colonnes automatiquement.
Une fois fait au conceptuel, plusieurs modèles logiques peuvent être définis.
Ton MLD est OK pour ce que tu as a en faire.
Il faudrait par la suite programmer des décelencheurs sur Admin et Agent en insertion et modification (de l'ID) qui assurereont qu'un ID donné n'est pas dans les 2 tables.

[nicofromChina]

Bah en fait je ne m'y connais pas du tout en trigger. Si je me débrouille bien pour que dans mon code Java un admin ne soit qu'un admin et de même pour un agent, je ne devrais pas avoir de problème non ?

[Soutou]

Oui mais un déclencheur a l'avantage qu'il est indépendant de l'applicatif. Tu le compiles en base et quelque soit l'INSERT fait par telle ou telle classe Java, il assurera la cohérence. Sans ça tu devras, dans tout ton code l'assurer.