Problème de conception de tables suivant les intégrités réferentielles. [Résolu]

[Anne1969]

Hello,

je me permets de vous soumettre mon souçi de conception...

J'ai 4 entités : Département (Id-Dep, Nom-Dep), Bassin (Id-Bas, Nom-Bas), Piste (Id-Piste, Nom-Piste), Segment (Id-Sed, Nom-Seg)

Un Département contient plusieurs Bassin (1-n)
Un Bassin contient plusieurs Piste (1-n)

Jusque là, pas de souçi : je me retrouve déjà avec 2 tables :
Département (Id-Dep, Nom-Dep)
Bassin (Id-Bas, Nom-Bas, Id-Dep)

Une Piste contient plusieurs Segment ou n'en contient aucun ! Dans ce dernier cas, ce sera le Bassin qui contiendra directement plusieurs Segment....Que faire pour ces 2 tables et leurs intégrités référentielles ?

Merci beaucoup

Anne

[Médiat]

Héritage : une entité générale avec deux spécialisations : Piste et Segment.

cf. http://www.developpez.net/forums/sho...d.php?p=994717

Dans ton cas, je conseillerais le point 4).

[Anne1969]

Merci, je vais regarder ça

[Anne1969]

Euh, en fait je ne vois pas trop comment faire et je me suis mal exprimée...

Dans la plupart des cas une Piste contient plusieurs Segment....comment les transformer en options possibles dans ces cas là....

En fait, un Bassin contient directement des Segments...
...ou bien...
un Bassin contient des Pistes qui contiennent des Segments...

[Médiat]

C'est bien ce que je disais, voici trois modèles (il faudrait trouver un nom plus intelligent pour l'entite "PisteOuSegment" et Pour BassinPiste)
Ce qui donne les tables suivantes (PK souligné, FK en italique) :
V1 :
table DEPARTEMENT (IDDEPARTEMENT);
table BASSIN (IDBASSIN, IDDEPARTEMENT);
table PISTEOUSEGMENT ( IDPISTEOUSEGMENT, IDBASSIN);
table PISTE (IDPISTEOUSEGMENT, DESCRIPTIONPISTE);
table SEGMENT (IDPISTEOUSEGMENT, IDPISTE, DESCRIPTIONSEGMENT );


V2 :
table DEPARTEMENT (IDDEPARTEMENT);
table BASSIN (IDBASSIN, IDDEPARTEMENT);
table PISTE (IDPISTE, IDBASSIN);
table SEGMENT (IDSEGMENT, IDBASSIN, IDPISTE);

V3 :
table DEPARTEMENT (IDDEPARTEMENT);
table BASSINPISTE (IDBASSINPISTE);
table BASSIN (IDBASSINPISTE, IDDEPARTEMENT, DESCRIPTIONBASSIN);
table PISTE (IDBASSINPISTE, IDBASSIN, DESCRIPTIONPISTE);
table SEGMENT (IDSEGMENT, IDBASSINPISTE);

La V3 est la solution qui permet de gérer au mieux l'intégrité : toutes les FK sont NOT NULL, ce qui n'est pas le cas de la V1 ni de la V2 (du coup ce sont d'assez mauvaises solutions...)
A toi d'ajouter les autres attributs...

[Anne1969]

Ouaouh Merci beaucoup

[Anne1969]

Pardon, juste un truc :

table DEPARTEMENT (IDDEPARTEMENT);
table BASSINPISTE (IDBASSINPISTE);
table BASSIN (IDBASSINPISTE, IDDEPARTEMENT, DESCRIPTIONBASSIN);
table PISTE (IDBASSINPISTE, IDBASSIN, DESCRIPTIONPISTE);
table SEGMENT (IDSEGMENT, IDBASSINPISTE);

Il y a IDBASSIN dans la table PISTE en FK mais elle n'est pas dans BASSIN...
je pige pas trop.. ...en fait IDBASSINPISTE serait, selon le cas, soit IDBASSIN dans le cas où on zappe PISTE pour aller à SEGMENT, soit IDPISTE pour passer par le chemin "normal" ??

[Médiat]

Pour être plus clair (mais c'est dans le schéma ;-)

SEGMENT.IDBASSINPISTE = BASSINPISTE.IDBASSINPISTE (puisqu'un SEGMENT est rattaché soit à un BASSIN soit à une PISTE)
BASSIN.IDBASSINPISTE = BASSINPISTE.IDBASSINPISTE (pour exprimer l'héritage)
PISTE.IDBASSINPISTE = BASSINPISTE.IDBASSINPISTE (pour exprimer l'héritage)
PISTE.IDBASSIN = BASSIN.IDBASSINPISTE (puisque qu'une PISTE est toujours rattaché à un BASSIN)

[Anne1969]

Merci Mediat