Discussion :

[Chabanus]

Bonsoir,
Je n'ai aucune idée du comment faire pour joindre une table dont la clé étranger peut être celle de n'importe quelle table. Voici un exemple :

J'ai la table "ABONNEE" :

ID_ABONNEE
ID_ACTIVITE

La table "ACTIVITE" :

ID_ACTIVITE
ID_ABONNEE
ID_????

l'ID_???? peut être ID_HOTEL ou ID_RESTAURANT ou ID_TAXI, etc.

L'abonnée peut être un hôtel, un taxi, un restaurant, etc. Et je ne sais pas comment faire cette liaison, devrais-je faire ça :

ID_ACTIVITE
ID_ABONNEE
ID_HOTEL
ID_RESTAURANT
ID_TAXI
ID_...
ID_N

Si l'abonnée est un hôtel alors les autres ID seront Null, mais ce n'est pas de la bonne pratique je présume.
PS : en java se serait, @ManyToOne (N à 1) entre ABONNEE et ACTIVITE et @OneToOne (1 à 1) entre ACTIVITE et Hotel/Restaurant/Agence_Taxi ... etc.
Si quelqu'un peut m'aider s'il vous plait, merci.
Cordialement.

Edit : Puisque personne ne sait pour le moment, je vais proposer une solution.

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
 
CREATE TABLE "CHABANE"."ACTIVITE"
  (
    "ID_ACTIVITE"   NUMBER(20,0) NOT NULL ENABLE,
    "ID_ABONNEMENT" NUMBER(20,0) NOT NULL ENABLE,
    "NOM_ACTIVITE"  VARCHAR2(20 BYTE) NOT NULL ENABLE,
    CONSTRAINT "ACTIVITE_PK" PRIMARY KEY ("ID_ACTIVITE") USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "USERS" ENABLE,
    CONSTRAINT "ACTIVITE_CAMPAGNIE_AERIEN_FK1" FOREIGN KEY ("ID_ACTIVITE") REFERENCES "CHABANE"."CAMPAGNIE_AERIENNE" ("ID_CA") ON
  DELETE CASCADE ENABLE,
    CONSTRAINT "ACTIVITE_HOTEL_FK1" FOREIGN KEY ("ID_ACTIVITE") REFERENCES "CHABANE"."HOTEL" ("ID_HOTEL") ON
  DELETE CASCADE ENABLE,
    CONSTRAINT "ACTIVITE_LOCATION_VOITURE_FK1" FOREIGN KEY ("ID_ACTIVITE") REFERENCES "CHABANE"."LOCATION_VOITURE" ("ID_LOCATION_VOITURE") ON
  DELETE CASCADE ENABLE,
    CONSTRAINT "ACTIVITE_TAXI_FK1" FOREIGN KEY ("ID_ACTIVITE") REFERENCES "CHABANE"."TAXI" ("ID_TAXI") ON
  DELETE CASCADE ENABLE
  )
  PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING STORAGE
  (
    INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT
  )
  TABLESPACE "USERS" ;

[Invité]

S'il vous est impossible de savoir d'où provient cette clé étrangère, votre modèle est mal fait.
Une clé étrangère ne peut que référencer une table.
Sinon, comment savoir d'où provient l'id numéro 122313 ???
Corriger ça au plus vite !

[Chabanus]

La bonne pratique dit que je dois créer une table intermédiaire entre chaque tables c'est à dire :

abonnée - activité_hotel - hotel
abonnée - activité_restaurant - restaurant
...
au lieu de abonnée - activité - (hotel, restaurant,...) la clé primaire de la table activité sera la clé étrangère de toutes les autres tables.

La première solution n'est pas de la répétition ? Je me suis dit que peut être y a une solution particulière avec Oracle.

Sinon, comment savoir d'où provient l'id numéro 122313 ???

Vous avez lu la requête SQL ? NOM_ACTIVITE fera la différence entre les tables référencés, enfin c'est mon point de vue.

[Chabanus]

Y a-t-il une solution quelconque ? Ou devrais-je créer une table pour chaque service ?

[boutade80]

Une solution pourrait etre de t'inspirer de ce que font les ORM en langage objet.
Ton problème est en fait une modélisation d'un héritage.
Il existe trois possibilités pour modeliser un héritage.
- Tous ds une table avec une colonne de type varchar pour le type.
- Une table par classe. Avec la pb que tu as levé.
- Une table par classe enfant de l'héritage. Ex:
B(idB) herite de A(idA)
C(idC) herite de A(idA)
Dans ta BD tu auras deux tables B (idB,idA) et C (idC,idA)

Le choix depend du nb de tables que tu aurais a modéliser, du contenu des tables, de la fréquence de remplissage, du tps que tu aurais à modeliser ou non des contraintes etc...

Des pistes:
http://sqlpro.developpez.com/cours/m...tion/heritage/

Ajout:
J'ai testé la solution "tous ds une table" ds le cadre de mon projet. Pour les raisons suivantes:
- Bcp de colonnes communes (genre chat et chien hérite d'animal) donc très peu de colonnes avec des valeurs null.
- Peu de données( 100 000 environs et ca ne grossira pas)
- Grande facilité de gestion pour créer des relations avec d'autres tables. tu n'as pas pour gerer un histo de type "une table histo par table" à créer autant de tables histo que tu as de tables heritant d'animal.
etc...

[Chabanus]

Merci, je pense que je vais opter pour un héritage. Je posterais la solution lorsque j'aurais essayé

[pachot]

Bonjour,

Pour moi si les différents concepts de HOTEL, TAXI, RESTAURANT, ... sont des concepts bien séparés, dont le nombre est relativement fixe, et qui ont chacun des attributs (et associations) très différents, alors une table pour chacun, et une foreign key pour chacun (+ contraint d'intégrité pour dire que un seul n'est pas null) me paraît juste.

Mais je ne pense pas que ce soit le cas pour 3 raisons:
- d'une part parce que son sont tous des ACTIVITES
- qu'ils ont au moins quelque chose d'important en commun: ils ont des ABONNES
- et parce qu'il y en a un grand nombre, puis que du dis '...' , 'N'

Et dans ce cas, je verrais plutôt une seule table ACTIVITE avec des champs communs (probablement une adresse, un no de téléphone, un prix ...), et des champs spécifiques (pouvant être nulls suivant le type d'activité - et les contraintes d'intégrité qui vont bien)

La question clé:

Est que tu vois ton système d'information
- plutôt comme une gestion d'abonnes, pouvant s'abonner à tout un tas de types d'activités,
- ou bien comme un ensemble de systèmes de gestion de restaurant, de gestion de taxi, ... qui ont tous un référentiel d'abonnés commun ?

Cordialement,
Franck.