Forums PostgreSQL.fr

arthurr

Membre

Conception

Bonjour,

Heureux de travailler avec Pg, j'ai une petite question de "savoir faire" concernant vos methodes de modelisations.
Dans le cadre d'un nouveau projet, je dois lier un certain nombre de tables a une seul.
Exemple bidon :
une table voiture
une table maison (0 a n voitures garees dans une maison))
une table proprietaire (qui possede 0 a n voitures et 0 a n maisons)

et pour chacune de ces tables (tres differentes), je dois gerer une nouvelle info. par exemple un historique d'alertes.
j'ai donc une table alerte (avec un id_alerte, une date, un type d'alerte).
je ne vois pas trop comment faire la liaison avec mes alertes et mes autres tables qui ont des PK differentes ...

Les solutions qui me viennent :
- j'ai pense au debut travailler avec des tables heritees (sur maison/voiture/propritaire) , mais j'ai besoin d'identifier facilement le propretaire et de connaitre ses biens (dans notre exemple).
- creer 3 tables : alerte_maison, alerte_voiture, alerte_proprietaire
- creer une table alerte (avec id_alerte, date, type_alerte) puis creer trois tables heritees de celle-ci : alerte_maison (avec la fk id_maison), alerte_voiture, ....

vous avez une solution "magique" ???

merci de votre aide

flo

Membre

Re : Conception

- j'ai pense au debut travailler avec des tables heritees (sur maison/voiture/propritaire)

Que voulez-vous dire ? quelle table hérite de quoi?

arthurr

Membre

Re : Conception

Un truc du style :
table "objet" avec un id_objet et 3 tables heritees de cette meme table : maison, voiture, proprietaire
avec ca, je peux juste creer une table alerte et lier alerte avec ma table objet.

mais ca va complexifier les choses : liaisons entre proprietaire / maison / voiture.

je ne suis pas certain d'etre tres clair dans mes explications ...

Marc Cousin

Membre

Re : Conception

En fait, les relations FK ne marchent pas de façon vraiment correcte sur les tables héritées : si vous déclarez une colonne de la table alerte comme ayant comme FK une colonne de objet, le code de vérification des FK n'ira pas vérifier dans les tables filles que cet objet existe.

Je pense que vous avez plutôt intérêt de vous en tenir à une conception classique : une table propriétaire, une table maison avec le propriétaire et une FK vers propriétaire, une table voiture avec le propriétaire (et FK vers propriétaire) et l'endroit où elle est garée (et FK vers maison).

Pour ce qui est des alertes, là effectivement vous pouvez les éclater entre plusieurs tables filles si les propriétés des alertes sont différentes entre les alertes maison et les alertes voiture, ou sinon dans des tables complètement distinctes (comme on le ferait si il n'y avait pas d'héritage).

---

Marc.

flo

Membre

Re : Conception

Si j'ai bien compris, il y a toujours des propriétés différentes entre les tables alerte : les clés étrangères vers maison ou propriétaire ou voiture. Donc héritage (conceptuel) sur les alertes. Après il y différentes solutions pour représenter l'héritage, dont l'héritage de tables. Le choix doit se faire en fonction de ce que fait l'application.

Sinon attention avec les exemples bidon à ne pas confondre le cas de l'association (comme ici, une voiture peut changer de propriétaire) et celui de la composition (comme avec les lignes de facture par exemple, dans ce cas la première colonne de la clé primaire de la table ligne doit contenir la clé de la table facture...)
un lien fort intéressant là-dessus (merci Marc...)
http://it.toolbox.com/blogs/database-so … ases-32525

arthurr

Membre

Re : Conception

Merci pour vos reponses !
je crois que je vais creer 3 tables (alertes_maison, ....).