Discussion :

[alex181]

Bonjour,

Je modélise des tables et j'ai besoin d'aide pour ajouter des contraintes entre elles. Voici en gros à quoi ca ressemble:

• une table CONTRAT avec une clé primaire sur 2 colonnes (contrat_ID, revision)
• une table AVENANT avec une clé primaire (avenant_ID) et la clé étrangère correspondant à la clé primaire de CONTRAT (càd (contrat_ID, revision) )
• une 3eme table LIAISON_ETABLISSEMENT, et c'est là mon problème: je voudrais placer une colonne "contrat_ID" avec une contrainte vérifiant l'existence du contrat mais sans tenir compte de la revision.
  Si je mets une clé étrangère, je dois prendre les 2 colonnes (contrat_ID, revision) mais la colonne revision ne m'interesse pas: la liaison n'est pas propre à une revision donnée d'un contrat.

Je reprend visuellement:

CONTRAT {
PK contrat_ID
PK revision
}

AVENANT {
PK avenant_ID
FK contrat_ID
FK revision
}

LIAISON_ETABLISSEMENT {
PK liaison_ID
FK contrat_ID ==> impossible de faire une foreign key "partielle", sans la colonne revision
}

Précisions: je suis sous SQL Server 2008 R2

Merci d'avance si vous avez une idée

[SQLpro]

Tout dépend quel mode de gestion de l'IRD votre SGBDR supporte.
Avec le mode PARTIAL il suffit de mettre NULL dans la colonne revision de votre table LIAISON_ETABLISSEMENT. mais il faudra quand me^me l'y faire figurer.

A ma lire : http://sqlpro.developpez.com/cours/s...partie2#L7.3.1

A +

[aieeeuuuuu]

Bonjour,

En quoi consistent les révisions ? Est-ce que toutes les données du contrat sont réellement susceptibles d'être modifiées entre les révisions ? Pouvez-vous poster la liste complète des colonnes de la table Contrat ? (je me demande s'il ne serait pas plus opportun d'avoir une table contrat, et une autre table révision)...

[alex181]

merci pour vos retours!

@SQLPro: malheureusement mon SGBDR ne supporte pas la clause "MATCH PARTIAL"

@aieeeuuuuu: c'est un peu compliqué à expliquer, je vais essayer.
Il y a une dizaine de champs dans contrat qui sont tous (sauf un ou deux) potentiellement modifiables par avenant (mais il faut conserver un historique).
Par ailleurs, on peut aussi modifier par avenant 2 autres choses: le contenu des liaisons vers etablissement (chaque "liaison" vers etablissement comporte une dizaine de champs) ainsi que l'ajout/suppression des liaisons en elles-même (là aussi, il faut conserver l'historique).
A vrai dire, j'utilise une 4eme table pour stocker les relations entre un avenant et des liaisons.

[tatayo]

Dans ce cas, pourquoi ne pas partir vers cette piste:
Contrat:
Idcontrat PK
IdcontratOrigine FK, "pointe" vers IdContrat
NoVersion

Ainsi dans le cas d'un avenant, il suffit de renseigner dans IdContratOrigine le contrat d'origine (ou l'avenant précédent, au choix).

Tout ce qui est dans un contrat peut être aussi dans un avenant, l'historique est conservé ainsi que l'ordre des avenants.

Autre solution, mettre le lien entre un contrat et un avenant dans une table de liaison, avec IdContrat et IdAvenant. Ainsi plus de FK null...

Tatayo.

[aieeeuuuuu]

pour ma part, j'opterai effectivement pour une table avenant, contenant toutes les colonnes de votre actuelle table contrat (sauf vos colonnes non modifiables par avenant) et reliée à la table contrat (qui s'offrira au passage une jolie cure d'amaigrissement).
Vous pourrez ensuite créer un vue correspondant à votre table contrat actuelle, voire même une deuxième vue ne reprenant que le dernier avenant de chaque contrat (si les avenants annulent et remplacent les avenants précédents)...

Je n'ai cependant pas bien compris vos "liaisons" avec les établissement...
Est-ce les contrats ou les avenants qui sont reliés aux établissements ?

[alex181]

merci tatayo; ta 1ère solution ne correspond pas vraiment, par contre, la 2ème solution oui!
En tournant bien le pb dans tous les sens, je crois avoir trouvé ce qu'il me faut

Je peux partager si d'autres ont un besoin du même genre:

Je vais utiliser 4 tables:

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
CONTRAT
(
PK contrat_ID
PK index
Data
)

AVENANT
(
PK avenant_ID
FK contrat_ID
FK index
Data
)

AVENANT_ETABLISSEMENT
(
FK avenant_ID
FK etablissement_ID
)

ETABLISSEMENT
(
PK etablissement_ID
Data
)

[alex181]

Je n'ai cependant pas bien compris vos "liaisons" avec les établissement...
Est-ce les contrats ou les avenants qui sont reliés aux établissements ?

Les contrats possèdent des liaisons vers des établissements.
Ces liaisons comportent des informations modifiables par avenant.
Mais on peut aussi ajouter/supprimer complètement une liaison par avenant!

Merci pour vos contributions, mon problème initial est résolu lorsque j'ai réalisé que je n'avais pas besoin d'une contrainte entre 2 tables étant déjà reliées indirectement