Discussion :

[sam01]

Bonjour à tous,

ma question est d'ordre général.

Est-ce qu'une table de jointure ne doit posséder que les deux clefs primaires des deux tables concernées ou peut-elle contenir d'autres champ ?

Voici mon cas

Il y a des personne qui doivent choisir une ou plusieurs destination. Ces destination sont un continent, un pays ou une ville avec les dates de début et de fin désirée du voyages.

J'ai donc une table voyageurs et une tables destination.

La cardinalité est la suivante :

1 voyageur peut choisir une seule ou plusieurs destination.
Une destination peut appartenir à un ou plusieurs voyageurs.
On est donc dans une relation de type n-m.
Il faut donc une table de jointure qui comportera en clef primaire la clef de la table voyageur (id_voyageur) et la clef de la table destination (id_des).

J'ai décidé de basculer les champs date de début et date de fin dans la table de jointure.

Mais je me suis rendu compte que la table de jointure ne peu pas avoir de doublons sur le couple (id_voyageur, id_des), or si un voyageur choisit une destination (londres par exemple) et qu'il désire y aller début octobre 2015 jusqu'aà fin octobre 2015 et aussi début décembre 2015 jusqu'à mi-décembre 2015, ça signifie qu'il y aura 2 ligne dans la table de jointure avec pour chaque ligne un couple (id_voyageur, id_des) identiques. il n'y a que les dates qui changent. or ce n'est pas possible d'avoir des doublons dans une clef primaire...Alors ou est mon erreur ?

Merci d'avance pour votre aide.

[CinePhil]

1 voyageur peut choisir une seule ou plusieurs destination.
Une destination peut appartenir à un ou plusieurs voyageurs.
On est donc dans une relation de type n-m.
Il faut donc une table de jointure qui comportera en clef primaire la clef de la table voyageur (id_voyageur) et la clef de la table destination (id_des).

OK avec ça mais...

Ces destination sont un continent, un pays ou une ville

Comment différencier le fait que ce soit un continent, un pays ou une ville ?
Votre modélisation est probablement plus complexe que cette simple association sur laquelle vous nous interrogez.

J'ai décidé de basculer les champs date de début et date de fin dans la table de jointure.

Mais je me suis rendu compte que la table de jointure ne peu pas avoir de doublons sur le couple (id_voyageur, id_des), or si un voyageur choisit une destination (londres par exemple) et qu'il désire y aller début octobre 2015 jusqu'aà fin octobre 2015 et aussi début décembre 2015 jusqu'à mi-décembre 2015, ça signifie qu'il y aura 2 ligne dans la table de jointure avec pour chaque ligne un couple (id_voyageur, id_des) identiques. il n'y a que les dates qui changent. or ce n'est pas possible d'avoir des doublons dans une clef primaire...Alors ou est mon erreur ?

Il faut donc que au moins la date de début figure dans la clé primaire. À vous de déterminer si c'est suffisant, c'est à dire si un voyageur peut partir vers plusieurs destinations le même jour.

Revenons au cas général :

Est-ce qu'une table de jointure ne doit posséder que les deux clefs primaires des deux tables concernées ou peut-elle contenir d'autres champ ?

La réponse est donc non dans votre cas.

[sam01]

Bonjour CinePhil,

c'est la table destination qui indique si c 'est un continent, un pays ou une ville .

Donc si j'ai bien compris, dans mon cas, il faut que tous les champs de la table de jointure :

Code :

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

1
2
3
4
5
id_adh
id_des
date_deb
date_fin

constituent la clef primaire.

Merci

[CinePhil]

c'est la table destination qui indique si c 'est un continent, un pays ou une ville .

Vous pouvez donner la structure de votre table pour qu'on comprenne mieux ?

Je subodore des problèmes potentiels...

Donc si j'ai bien compris, dans mon cas, il faut que tous les champs de la table de jointure constituent la clef primaire.

Oui... pour autant que ce qui est le plus pertinent soit bien une table de jointure (que je préfère appeler table associative).

[Richard_35]

Bonjour Sam01 et Philippe,

Les traitements avec les dates sont toujours délicats... a fortiori, ceux avec des périodes (date début => date de fin).

Suggestion :




Ensuite, via un trigger, il faut tester que la période saisie (date début => date fin) n'empiète pas sur une période existante. Voici l'exhaustivité des tests à créer :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
S_Deb : Date de début de période saisie
S_Fin : Date de fin de période saisie

S_Deb S_Fin
  |<--->|


A chaque enregistrement :
BdD_Deb : Date de début de période de l'enregistrement
BdD_Fin : Date de début de période de l'enregistrement

BdD_Deb                         BdD_Fin
   |<----------------------------->|


Toutes les possibilités :
                 BdD_Deb                         BdD_Fin
                    |<----------------------------->|

  |<--->|       |<--->|          |<--->|         |<--->|      |<--->|
S_Deb S_Fin   S_Deb S_Fin      S_Deb S_Fin     S_Deb S_Fin  S_Deb S_Fin


                    |<--->|                   |<--->|
                  S_Deb S_Fin               S_Deb S_Fin


              |<--->|                               |<--->|
            S_Deb S_Fin                           S_Deb S_Fin


                    |<----------------------------->|
                  S_Deb                           S_Fin


              |<----------------------------------------->|
            S_Deb                                       S_Fin

[SQLpro]

Les traitements avec les dates sont toujours délicats... a fortiori, ceux avec des périodes (date début => date de fin).

!!! A qui le dite vous....

En effet, votre modèle (DATE_DEBUT, DATE_FIN) nécessite plusieurs contraintes :
1) que DATE_DEBUT < DATE_FIN
2) que DATE_DEBUT soit saisie si DATE_FIN est renseignée, sinon que DATE_DEBUT soit obligatoire

Il est souvent plus intéressant d'utiliser le couple DATE_DEBUT, DUREE (avec une durée à la granularité temporelle voulue, par exemple minutes, jours....).

Les contraintes sont simplifiée par le fait que 1) devient : DUREE >= 0

Rien n'empêche en sus dans une vue de montrer la DATE_FIN par calcul, ni que l'utilisateur saisisse une date de fin qui soit convertie en durée ! => MED (Modèle Externe de Données)

A +

[Richard_35]

Bonjour SQLpro,

En effet, votre modèle (DATE_DEBUT, DATE_FIN) nécessite plusieurs contraintes :
1) que DATE_DEBUT < DATE_FIN
2) que DATE_DEBUT soit saisie si DATE_FIN est renseignée, sinon que DATE_DEBUT soit obligatoire

Il est souvent plus intéressant d'utiliser le couple DATE_DEBUT, DUREE (avec une durée à la granularité temporelle voulue, par exemple minutes, jours....).

==> c'est vrai. Mais le plus délicat reste le contrôle des chevauchement des périodes, autrement plus compliqué que les deux contrôles que vous mentionnez.