Discussion :

[cryptom]

Bonjour,
j'imagine que la réponse se trouve quelque part, mais je ne pense pas trouver la bonne formulation pour la trouver.

J'aimerai savoir comment réaliser proprement l'association (binaire dans le principe), en bénéficiant de la cohérence assurée par les clés étrangères.
J'ai :
- une table "propriétaires"
- une table "chiens"
- une table "chats"
- une table "alligators"
Les 3 dernières ne pouvant pas être fusionnées, ni reliées par une héritage.

Imaginons l'association "dresser", à savoir :
Un propriétaire - dresse - un chat, un chien ou un alligators

Pas de soucis pour le propriétaire on intègre son id en clé étrangère.
Mais pour le deuxième élément, comment indiquer que la clé étrangère dépend de la nature de l'animal : c'est à dire id du chat, id du chien, ou id de l'alligator.

Pour le moment, je crée un champ nature de l'animal (chat, chien ou alligator) et un autre champ pour l'id, et je recherche dans la table correspondante. Mais je n'intègre pas de clé étrangère et je suis obligé de faire un contrôle à priori (liste fermée) ou à postériori (vérification de l'existence de l'enregistrement).
Je me dis qu'il doit y avoir une manière plus propre de faire : au niveau modèle ? au niveau contraintes ? ou selon le SGBD (en l'occurrence, je travaille sur du postgres) ?

Je suis preneur de vos conseils, pratiques ou renvois vers "la question déjà posée".

Merci d'avance.

[Waldar]

En effet votre modèle est erroné, il vous manque une table animaux dont les tables chiens chats et alligator hériteraient (soit avec l'héritage de postgresql, soit à la mano).

[escartefigue]

Bonjour,

Cette question concerne la modélisation, or pour bien modéliser il faut connaitre les règles de gestion.
Il faut les rédiger sous la forme (exemple)

R001 : un propriétaire possède un ou plusieurs animaux
R002 : un animal est possédé par un et un seul propriétaire
R003 : un animal est d'un et un seul type
R004 etc...

Questions à poser ici : forum MCD/MLD/MPD

[cryptom]

En effet votre modèle est erroné, il vous manque une table animaux dont les tables chiens chats et alligator hériteraient (soit avec l'héritage de postgresql, soit à la mano).

Je ne souhaite pas faire appel à l'héritage, sauf si pas d'autres solutions (en tout cas pour le moment...)

Bonjour,

Cette question concerne la modélisation, or pour bien modéliser il faut connaitre les règles de gestion.
Il faut les rédiger sous la forme (exemple)

R001 : un propriétaire possède un ou plusieurs animaux
R002 : un animal est possédé par un et un seul propriétaire
R003 : un animal est d'un et un seul type
R004 etc...

Questions à poser ici : forum MCD/MLD/MPD

Pour les règles de gestion, en voici :
Un animal ne peut être dressé que par un propriétaire
Un propriétaire peut dresser 1 ou plusieurs animaux (du même type ou de types différents)
Et un animal est d'un seul type

Mon message a été déplacé ici par un modérateur...

[escartefigue]

Si les attributs des chiens, chats, aligators et autres animaux sont strictement identiques (ce qui est peu probable), inutile d'utiliser l'héritage, dans le cas contraire c'est fortement recommandé

Dans le 1er cas
PROPRIO 1,n --- dresser --- 1,1 ANIMAL 1,1 --- typer --- 0,n TYPE

Ce qui donne 3 tables : PROPRIO, ANIMAL (avec une FK vers l'id proprio et une FK vers le type) et TYPE

[cryptom]

Si les attributs des chiens, chats, aligators et autres animaux sont strictement identiques (ce qui est peu probable), inutile d'utiliser l'héritage, dans le cas contraire c'est fortement recommandé

Dans le 1er cas
PROPRIO 1,n --- dresser --- 1,1 ANIMAL 1,1 --- typer --- 0,n TYPE

Merci pour la réponse, mais en effet les attributs sont différents (ici les animaux ne sont qu'un exemple pour la question), on ne peut fusionner en une seule table.

Et donc l'héritage est la seule alternative ?
Va falloir que je me repenche sur la question, je l'avais un peut éludée, parce qu'il me semblait que cela entraînait des complications (contrôle d'unicité, suppression en cascade, ... je ne sais plus...)

[escartefigue]

Merci pour la réponse, mais en effet les attributs sont différents (ici les animaux ne sont qu'un exemple pour la question), on ne peut fusionner en une seule table.

Et donc l'héritage est la seule alternative ?
Va falloir que je me repenche sur la question, je l'avais un peut éludée, parce qu'il me semblait que cela entraînait des complications (contrôle d'unicité, suppression en cascade, ... je ne sais plus...)

Pas du tout, aucune complication : avec l'héritage, les sous-types héritent de l'identifiant du sur-type l'unicité est donc implicite (fort heureusement du reste )

Il y a des infos sur l'héritage dans ce forum, par exemple ici

[fsmrel]

cryptom,

Comme l’écrivent Waldar et escartefigue, la spécialisation du type ANIMAL en CHIEN, CHAT, ALLIGATOR ne pose pas de problème particulier. En passant, notez l’emploi au singulier du nom de chaque type.

Puisque vous vous situez au niveau tabulaire, vous pouvez vous reporter à l’article consacré à la modélisation avec MySQL Workbench, plus précisément ici.

[CinePhil]

Merci pour la réponse, mais en effet les attributs sont différents (ici les animaux ne sont qu'un exemple pour la question), on ne peut fusionner en une seule table.

Alors expliquez-nous votre cas concret !
Sinon c'est difficile de vous aider.

[cryptom]

Les réponses sont très claires merci.

Je cherchais une réponse pour le cas général.

En l'occurrence, actuellement ce sera pour de l'affectation de matériel (équipement de chantier, chacun avec des caractéristiques très spécifiques). En définitive, peu importe le type d'objet, au pire on fait une table mère "CHOSES", avec juste un ID et on crée les enfants qu'on veut.

N'ayant pas encore implémenté de l'héritage dans mes bases de données, j'en étais resté à ce que j'ai décrit plus haut. Et pour le moment je ne peux aller plus loin dans l'échange. Je tague le post comme résolu et je travaille mon héritage.

Merci encore pour les réponses données.

[CinePhil]

En l'occurrence, actuellement ce sera pour de l'affectation de matériel (équipement de chantier, chacun avec des caractéristiques très spécifiques).

Donc vous pouvez avoir par exemple ce type d'héritages :
grue -(1,1)----être----0,1- equipement_chantier
bungalow -(1,1)----être----0,1------|
container -(1,1)----être----0,1-------|

Ensuite, vous pouvez avoir des héritages multiples, par exemple :
vestiaire -(1,1)----être----0,1- bungalow
sanitaire -(1,1)----être----0,1--------|
bureau -(1,1)----être----0,1----------|

Et du coup vous pouvez faire des associations générales à tous les équipements de chantier (livrer, installer...) ou spécifiques à des entités-types filles (vérifier une grue, raccorder le vestiaire au réseau d'eau propre et d'eaux usées...).