Table de jointure

**sam01** · 27/10/2012, 13h14

Bonjour à tous,

j'ai deux tables :

Une table adherent :

id_adh nom prenom adresse

Une table destination

id_des continent pays ville

En réfléchissant sur la relation entre ces deux tables, j'ai établie la suivante :

Un adhérent choisit au moins une destination et au maximum n destination

Une destination est choisie par au minimum 0 adhérent et au maximum par m adhérents

Je suis donc dans un type de relation n,m

Je créé donc une table de jointure choix_destination qui contient comme cle primaire, une combinaison des deux clés primaires de adherent et destination

table choix_destination
id_adh id_des

J'aimerais savoir si la table de jointure choix_destination peut uniquement contenir les deux clés primaires. est-ce suffisant ? Dois-je ajouter une autre colonne ?

Merci d'avance pour vote aide.

**Richard_35** · 27/10/2012, 15h39

Bonjour Sam01,

Jusque là, tout est parfait !...

Envoyé par Sam01

J'aimerais savoir si la table de jointure choix_destination peut uniquement contenir les deux clés primaires. est-ce suffisant ? Dois-je ajouter une autre colonne ?

==> eh bien, cela dépend si l'association adhérent/ville comporte un (des) attribut(s) propre(s).

Par exemple, si tu veux stocker la date du choix de l'adhérent, la table associative deviendra :

choix_destination(#id_adh, #id_des, DateChoix, ...)

**sam01** · 27/10/2012, 17h48

Bonjour Richard_35 et merci pour ta réponse.

Dans ma table destination, j'ai les attributs :

date_deb date_fin

exemple, un adhérent veut partir à paris du 30 octobre au 30 novembre,

date_deb=30/10/2012

date_fin=30/11/2012

faut-il que je reporte ces deux colonnes dans la table de jointure ?

**Richard_35** · 27/10/2012, 18h00

Envoyé par Sam01

C'est juste que ça me fait bizarre d'avoir une table comportant uniquement deux clés.

==> non, rien de bizarre : ce genre de table court les rues (encombrées) des bases de données.

**sam01** · 27/10/2012, 18h16

Merci Richard_35. Entre-temps j'ai fait une modification de mon post.

**Richard_35** · 27/10/2012, 18h45

Envoyé par Sam01

faut-il que je reporte ces deux colonnes dans la table de jointure ?

==> oui.

**sam01** · 27/10/2012, 19h01

Désolé d'insister mais ç'est ça que je ne comprends pas.

Si je peux reporter mes colonnes :

date_deb et date_fin

qui à la base appartenait à ma table destination, pourquoi ne pas aussi reporter mes colonnes :

continent pays ville

qui appartiennent actuellement à ma table destination.

Merci pour ton aide.

**CinePhil** · 28/10/2012, 09h45

Commence par écrire des règles de gestion claires de tes données.

Choses qui m'étonnent, voire me choquent :

Une table destination

id_des continent pays ville

Il peut y avoir dans cette table une ville nommée Toulouse au Pakistan en Amérique !

Si je choisis Toulouse et que j'habite Paris, je ne vais pas prendre un avion pour le Pakistan puis un autre pour l'Amérique !

Il y a, d'évidence, des associations à faire entre les villes et les pays et entre les pays et les continents.

Un adhérent choisit au moins une destination et au maximum n destination

Une destination est choisie par au minimum 0 adhérent et au maximum par m adhérents

Voilà une règle de gestion correctement exprimée.

Je suis donc dans un type de relation n,m

Je créé donc une table de jointure choix_destination qui contient comme cle primaire, une combinaison des deux clés primaires de adherent et destination

table choix_destination
id_adh id_des

Oui.

Dans ma table destination, j'ai les attributs :

date_deb date_fin

Ce qui veut dire qu'une destination n'est valable que pour certaines dates.

C'est là qu'il faudrait préciser vos règles de gestion parce qu'il semble que ces dates soient en fait celles du séjour choisi pour la destination, si je comprends bien ce que vous exprimez par la suite :

exemple, un adhérent veut partir à paris du 30 octobre au 30 novembre,

**Richard_35** · 28/10/2012, 10h01

Bonjour Sam01 et Philippe,

Sam01, suis le conseil de CinePhil concernant les règles de gestion : en gros, on ne commence pas par construire des tables sans règles de gestion, qui généreront un modèle conceptuel (un schéma), qui, lui-même (le schéma), générera la structure des tables.

Sinon, pour répondre avec un minimum de précision à ta question :

Envoyé par Sam01

Si je peux reporter mes colonnes :

date_deb et date_fin

qui à la base appartenait à ma table destination, pourquoi ne pas aussi reporter mes colonnes :

continent pays ville

qui appartiennent actuellement à ma table destination.

==> parce qu’il ne faut pas de redondance de données, dans une base de données bien construite. Outre le fait que "continent", "pays" et "ville" sont des entités à part entière (qui, en final, seront des tables), le stockage de "id_des" dans la table associative suffit pour retrouver le nom de la destination via des requêtes ou des vues.

**sam01** · 28/10/2012, 16h06

Bonjour,

en ce qui concerne les colonnes:

continent pays ville

le continent, le pays et la ville sont liés, donc pas de confusion.

J'ai créé par ailleurs une table continent, une table pays et une table ville liées entre elles.

Les colonnes :

continent pays ville

de la table destination contiennent chacune les id des tables continent, pays et ville.

Lorsqu'un adhérent choisit une destination, il choisit forcément une date de séjour associée. Soit cette date de séjour est nulle (ce qui signifie qu'il est susceptible de partir n'importe quand), soit il s'agit une date de séjour bien précise. Donc oui, la destination est liée à une date de séjour. Je me demande juste s'il faut que je laisse la date de séjour (date_deb et date_fin) dans table destination ou s'il faut que je la déplace dans la table de jointure :

choix_destination, ce qui donnerait :

#id_des #id_adh date_deb date_fin

Merci pour votre aide.

**CinePhil** · 28/10/2012, 16h47

Envoyé par sam01

en ce qui concerne les colonnes:

continent pays ville

le continent, le pays et la ville sont liés, donc pas de confusion.

J'ai créé par ailleurs une table continent, une table pays et une table ville liées entre elles.

Les colonnes :

continent pays ville

de la table destination contiennent chacune les id des tables continent, pays et ville.

Ou bien j'ai mal compris, ou bien, comme je l'ai écrit dans mon message précédent (bis repetita) :

Envoyé par CinéPhil

Il peut y avoir dans cette table une ville nommée Toulouse au Pakistan en Amérique !

Tu devrais avoir ce MCD :
destination -1,1----situer----0,n- ville -1,1----situer----0,n- pays -1,1----situer----0,n- continent

En considérant que la destination contient des propriétés particulières telles qu'un tarif, une référence.. ou est associée à d'autres entités types telles que voyagiste ou compagnie_aerienne... Tout dépend de ton contexte.

Continue de faire n'importe quoi avec tes modèles de données, ça donnera du boulot à ceux qui devront éteindre les incendies qu'ils auront provoqué plus tard, à l'occasion d'une évolution de l'application ou du branchement d'une autre application sur la même BDD.

Envoyé par sam01

Je me demande juste s'il faut que je laisse la date de séjour (date_deb et date_fin) dans table destination ou s'il faut que je la déplace dans la table de jointure :

Bis repetita :

Envoyé par CinéPhil

Commence par écrire des règles de gestion claires de tes données.

**Richard_35** · 28/10/2012, 19h05

Envoyé par Sam01

J'ai créé par ailleurs une table continent, une table pays et une table ville liées entre elles.

==> ce qui devrait donner, à peu de chose près :

Envoyé par CinePhil

destination -1,1----situer----0,n- ville -1,1----situer----0,n- pays -1,1----situer----0,n- continent

(laissons de côté les villes différentes avec le même nom)

Envoyé par Sam01

Je me demande juste s'il faut que je laisse la date de séjour (date_deb et date_fin) dans table destination ou s'il faut que je la déplace dans la table de jointure :

choix_destination, ce qui donnerait :

#id_des #id_adh date_deb date_fin

==> la date de séjour ne peut pas être dans la table "destination", car cela voudrait dire qu'une destination (id_dest) ne possède qu'une seule période de séjour, pour tous les adhérents !... peu probable. Comme précisé précédemment et, en l'état actuel de tes "règles de gestions supposées" :

Envoyé par Sam01

faut-il que je reporte ces deux colonnes dans la table de jointure ?

==> oui.

Ceci dit :

Envoyé par CinePhil

Commence par écrire des règles de gestion claires de tes données.

==> me paraît être un bon conseil (d'autant que je subodore une histoire de périodes pré-établies par destination...)

**sam01** · 31/10/2012, 09h41

je me permets juste de revenir sur l'histoire des continent et pays.

j'ai une liste déroulante qui d'abord propose le nom des continent.

Ensuite quand l'adhérent choisit son continent, il y a une liste déroulante qui apparaît et qui donne la liste des pays liés au continent.

Ensuite, il y a la liste des villes liée au pays et au contient. Donc pas de confusion possible.

**Richard_35** · 31/10/2012, 11h13

Bonjour Sam01,

Tout est-il OK ?

**CinePhil** · 31/10/2012, 14h04

Envoyé par sam01

je me permets juste de revenir sur l'histoire des continent et pays.

j'ai une liste déroulante qui d'abord propose le nom des continent.

Ensuite quand l'adhérent choisit son continent, il y a une liste déroulante qui apparaît et qui donne la liste des pays liés au continent.

Ensuite, il y a la liste des villes liée au pays et au contient. Donc pas de confusion possible.

Il est donc inutile de reprendre le pays et le continent dans la table des destinations, la ville est suffisante ; comme déjà expliqué précédemment.

**sam01** · 01/11/2012, 10h05

La raison pour laquelle j'ai mis les colonnes continent et pays est que certains adhérents ne choisissent pas forcément une ville de destination, mais un pays, et des fois même un continent.

Un adhérent peut choisir de partir en Asie par exemple.

A ce moment là, tous les adhérents qui vivent dans le continent asiatique le savent et sont susceptibles de lui proposer un logement.

**CinePhil** · 01/11/2012, 10h21

Ce n'est pas l'application qui doit contraindre le modèle de données mais au contraire s'y adapter.

Tu as dit que tu avais une liste déroulante pour le continent, puis une liste corrélée pour le choix du pays puis une autre pour la ville.

Comme le continent est trouvable à partir de la ville de destination, si l'utilisateur s'arrête au choix du continent, il suffit de faire les jointures nécessaires pour obtenir toutes les destinations en Asie.

Ou, plus pratique, faire une vue qui rétablit la description complète destination / ville / pays / continent qui permettra de sélectionner directement les destinations d'Asie.

Encore une fois, mettre le pays et le continent dans la table des destination est une erreur de conception qui peut conduire à des incohérences de données.

**Richard_35** · 01/11/2012, 10h50

Bonjour Sam01 et Philippe,

Philippe, il semble que ce que veux dire Sam1 (qui donne ses règles de gestion au compte-goutte

), c'est que, dans sa table "Destination", Id_Ville et/ou Id_Pays pourra être NULL. Donc, ton MCD est fondamental.

Sam01, il n'est pas conseillé de stocker des valeurs nulles dans des clés étrangères. Suggestion :

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
Ville -1,1---[Situer]---0,n- Pays -1,1---[Situer]---0,n- Continent
  |                            |                            |
 1,1                          1,1                          1,1
  |                            |                            |
[Etre destination]     [Etre destination]           [Etre destination]
  |                            |                            |
 0,1                          0,1                          0,1
  |                            |                            |
  +----------------------------+----------------------------+
                               |
                          Destination
                               |
                              0,n
                               |
                           [Choisir]
                               |
                              0,n
                               |
                           Adhérent

En clair, il faut créer une destination qui doit être, soit une ville, soit un pays, soit un continent et stocker Id_Destination dans la table associative "Choisir".

Sam01, tu peux en déduire les tables.

**CinePhil** · 01/11/2012, 12h25

Moi j'ai plutôt l'impression que les destinations proposées sont précises jusqu'à (au moins) la ville et que son ajout du pays et du continent dans la table des destinations a été guidé par son processus applicatif qui autorise l'utilisateur à ne choisir que le continent ou bien le continent et le pays.

Je maintiens donc mon modèle d'origine qui est plus simple ;

Envoyé par CinéPhil

destination -1,1----situer----0,n- ville -1,1----situer----0,n- pays -1,1----situer----0,n- continent

Il suffit que le programme interroge la vue pour satisfaire tous les cas du choix de l'utilisateur :

Code SQL :

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
CREATE VIEW v_destination AS
SELECT d.dst_id AS id_destination,
	d.dst_nom AS nom_destination,
	v.vil_id AS id_ville,
	v.vil_nom AS nom_ville,
	p.pay_id AS id_pays,
	p.pay_nom AS nom_pays,
	c.cnt_id AS id_continent,
	c.cnt_nom AS nom_continent
FROM destination d
INNER JOIN ville v ON v.vil_id = d.dst_id_ville
	INNER JOIN pays p ON p.pay_id = v.vil_id_pays
		INNER JOIN continent c ON c.cnt_id = p.pays_id_continent;
 
-- Destinations en Asie
SELECT id_destination, nom_destination,
	id_ville, nom_ville,
	id_pays, nom_pays
FROM v_destination
WHERE nom_continent = 'Asie';
 
-- Destinations en Chine
SELECT id_destination, nom_destination,
	id_ville, nom_ville
FROM v_destination
WHERE nom_pays = 'Chine';
 
-- Destinations à Pékin
SELECT id_destination, nom_destination
FROM v_destination
WHERE nom_ville = 'Pékin';

**sam01** · 01/11/2012, 17h07

Bonjour CinePhil,

il y a une chose que je ne parviens à m'expliquer dans ton model.

Prenons le cas ou un adhérent choisit le continent Asie comme destination. Il ne choisit ni pays, ni ville.

Que va contenir la table destination dans un tel cas ? Comment est-ce que cette valeur Asie va apparaître dans la table destination ?

Table de jointure [MLD]

Schéma

Discussions similaires

Partager

Partager