Discussion :

[escafr]

Bonjour,

j'ai un problème de conception de base de données:

Je veux créer une table Exposure composée des colonnes:
ExposureType (FK on AssetInfo) - ExposureTypeValue(FK à determiner) - ExposureValue (number)- DateVal (date)

ExposureType est une clé étrangère sur une table AssetInfos qui contient:
ID - Value où Value correspond à un type d'exposition possible (CURRENCY, NATURE, etc...)

Il existe n tables Currency, Nature etc qui contiennent aussi ID - Value
Dans Currency il peut y avoir: EUR, GBP, USD etc.
Dans Nature il peut y avoir: EQUITY, BONDS, FX etc..


Je veux que dans ExposureTypeValue je puisse avoir EUR, GBP, USD mais aussi EQUITY, BONDS, FX suivant si ExposureType est de Type CURRENCY ou NATURE.
Je voudrais mettre une contrainte sur ExposureTypeValue pour dire que mes valeurs possible sont celles presentes dans les tables Currency ou Nature ou autres (un nombre de table supposées infinies)

J'avais pensé réalisé une View listant l'ensemble des ExposureTypeValue possible et la mettre en clé étrangère.
Or c'est impossible (enfin d'après ce que j'ai compris)

Donc que faire? Comment puis limiter les valeurs de ExposureTypeValue à des valeurs présentes dans des tables différentes.

PS: Je ne peux modifier la structure des tables existantes.

Merci de votre aide.

[orafrance]

c'est à l'application de gérer ces contraintes complexes, ceci étant un FK sur ExposureTypeValue ne sera de toutes façon pas inutile (même si j'ai bien compris que ça n'était pas suffisamment limitant).

[philcero]

De mon point de vue, revoie la conception et utilise DEUX tables, une pour le enregistrements de type CURRENCY (exposure_cur) et une deuxième pour les enregistrements de type NATURE (exposure_nat). Là tes contraintes sont faciles à mettre en place.

Ensuite rien ne t'empêche de créer une VIEW (exposure) étant la concaténation des deux.

Par définition les champs d'une base sont typés, cela ne veut pas seulement dire que tel ou tel champs est simplement NUMBER ou CHAR, cela veut dire que la logique interne/applicative, que le SGBDR ne peut donc vérifier, doit également répondre de ces mêmes lois à son niveau.

Bref un problème de conception...

[orafrance]

De mon point de vue, revoie la conception et utilise DEUX tables, une pour le enregistrements de type CURRENCY (exposure_cur) et une deuxième pour les enregistrements de type NATURE (exposure_nat). Là tes contraintes sont faciles à mettre en place.

Faut juste pas que le type soit modifiable dans l'appli sinon merci l'usine à mazout

Tout simplement, le SGBD n'a pas à prendre en charge les contraintes fonctionnelles selon moi

[philcero]

Tout simplement, le SGBD n'a pas à prendre en charge les contraintes fonctionnelles

Pas faux, je dirais même pas si injuste que ça...

[escafr]

Je prefere ton idée orafrance, c'est moins compliqués à mettre en place

Je laisse ouvert au cas ou qqun a une autre idée.

[jmguiche]

Fais une table de reference unique.


Table de ref
(code varchar2(..), -- valeurs possible EUR,GBP,USD… EQUITY, BONDS, FX…
ExposureType varchar2(…) -- valeurs possible Nature, Currency,…
-- la primary key est sur les 2 colones
)

Table Exposure
(ExposureType varchar2(..),
Exposure type value varchar2(..)
Exposure value number,
…
)

La clef étrangère est sur code et exposure type de la table de ref.