Bonsoir kaalii,
Envoyé par
kaalii
J'ai essayé de traduire ce que vous avez écrit dans le message précédent sans être sur du travail que j'ai effectué.
Pour y voir plus clair, je surcharge les noms de vos associations par ceux que j’ai utilisés dans le MCD que j’avais présenté. Manifestement votre traduction est fidèle, sauf que les CIF sont absentes, c'est-à-dire que certaines dépendances fonctionnelles non inférables ne sont pas représentées. Mais la mise en œuvre des CIF n’étant pas prévue par l’outil AnalyseSI, il vous reste seulement vos yeux pour pleurer (vous pouvez tout du moins surcharger la représentation graphique et dessiner des flèches avec un outil comme PAINT).
MCD surchargé des noms d’associations :
La bonne nouvelle est qu’en fait on peut faire l’économie de certaines CIF, à condition de tenir compte du fait que certaines dépendances fonctionnelles sont inférables (application des axiomes d’Armstrong).
Je reprends leur liste, complétée avec DF13 et en coloriant en bleu celles qui ne sont pas inférables des autres (a ceci près que des DF non inférables peuvent l’être, mais à condition que d’autres qui sont inférables ne le soient plus, toutefois on n’insistera pas sur ce point qui dans votre contexte n’est pas primordial...) :
DF01 : R -> C
DF02 : R -> P
DF03 : R -> S
DF04 : R -> H
DF05 : H,S -> R
DF06 : H,S -> C
DF07 : H,S -> P
DF08 : H,P -> S
DF09 : H,G -> S
DF10 : H,G -> P
DF11 : H,P -> C
DF12 : H,G -> C
DF13 : H,P -> R
Comme DF10 est inférable, l’association HGP (Association 23 dans votre MCD) peut disparaître. Par ailleurs, étant donné qu’au niveau MLD (puis SQL) on aura une table R porteuse des attributs R, S, P, H,C, celle-ci pourra être porteuse de DF08, c'est-à-dire qu’on peut faire l’économie de l’association HPS ; de la même façon la table R pourra être porteuse de DF05, on pourra donc faire l’économie de l’association HSR. Reste donc une seule CIF, portée par l’association HGS (Association 24).
Si l’on retouche votre MCD, on arrive à ceci (j’ai renommé les attributs identifiants) :
Par raffinements successifs, on arrive à un MCD sans CIF, à condition de disposer du mécanisme de l’identification relative, mais la mauvaise nouvelle est qu’AnalyseSI ne connaît pas ce type d’identification, et il faut donc en passer par PowerAMC ou WinDesign (payants tous les deux) ou Open ModelSphere (gratuit). Néanmoins ces AGL ne permettent pas de rendre compte exactement de la situation à cause de l’attribut H.
Exemple, MCD avec PowerAMC :
Par identification relative on entend que l’identifiant de l’entité-type R est composé de l’association R_S et d’un l’attribut de R (H en l’occurrence). Cela veut dire qu’au niveau du MLD, la clé primaire de la table R sera la paire {S, H} où S est l’attribut provenant de la table S. En procédant ainsi, on peut établir l’association HGS_R connectant les entités-types R et HGS.
De la même façon, l’identifiant de l’entité-type HGS est composé de l’association HGS_G et d’un l’attribut de R (H en l’occurrence). Seul problème : au niveau MLD, la table HGS comportera deux fois l’attribut H qui est donc redondant, et il faudra procéder à un nettoyage manuel en supprimant l’un des deux dans la table HGS du MLD.
Ce MLD nettoyé est le suivant :
Où R a pour clé primaire {S, H} et pour clés alternatives {R} et {P, H} respectivement symbolisées par les mickeys <ak1> et <ak2>. HGS a pour clé primaire {G, H}.
Les dépendances fonctionnelles non inférables sont-elles ainsi préservées ?
Au sein de la table R, {R} est clé alternative, c'est-à-dire clé candidate, en vertu de quoi on vérifie :
{R} -> {S}
{R} -> {P}
{R} -> {H}
{R} -> {C}
On retrouve DF01, DF02, DF03, DF04.
Au sein de la table R, {S, H} est clé primaire, c'est-à-dire clé candidate, en vertu de quoi on vérifie :
{S, H} -> {R}
{S, H} -> {P}
{S, H} -> {C}
On retrouve , DF05, DF06, DF07.
Au sein de la table R, {P, H} est clé alternative, c'est-à-dire clé candidate, en vertu de quoi on vérifie :
{P, H} -> {R}
{P, H} -> {S}
{P, H} -> {C}
On retrouve DF08, DF11, DF13.
Au sein de la table HGS, {G, H} est clé primaire, c'est-à-dire clé candidate, en vertu de quoi on vérifie :
{G, H} -> {S}
On retrouve DF09.
Les DF non inférables DF01, DF02, DF03, DF04, DF05, DF06, DF07, DF08 et DF09 sont préservées, en conséquence de quoi les règles de gestion qui en sont à la source sont garanties elles aussi.
Reste à mettre en œuvre une base de données de test pour vérifier tout cela. Le script SQL de création de cette base de données est généré par l’AGL à partir du MLD et dans le cas de PowerAMC il est le suivant (dans le style du SGBD MS SQL Server) :
TABLE S
1 2 3 4 5
| CREATE TABLE S (
S INT NOT NULL,
Snom VARCHAR(64) NOT NULL,
CONSTRAINT S_ID PRIMARY KEY (S)
); |
TABLE C
1 2 3 4 5
| CREATE TABLE C (
C INT NOT NULL,
Cnom VARCHAR(64) NOT NULL,
CONSTRAINT C_ID PRIMARY KEY (C)
); |
TABLE P
1 2 3 4 5
| CREATE TABLE P (
P INT NOT NULL,
Pnom VARCHAR(64) NOT NULL,
CONSTRAINT P_ID PRIMARY KEY (P)
); |
TABLE G
1 2 3 4 5
| CREATE TABLE G (
G INT NOT NULL,
Gnom VARCHAR(64) NOT NULL,
CONSTRAINT G_ID PRIMARY KEY (G)
); |
TABLE R
1 2 3 4 5 6 7 8 9 10 11 12 13 14
| CREATE TABLE R (
R INT NOT NULL,
Rnom VARCHAR(64) NOT NULL,
S INT NOT NULL,
P INT NOT NULL,
H INTERVAL NOT NULL,
C INT NOT NULL,
CONSTRAINT R_ID UNIQUE (R),
CONSTRAINT R_SH PRIMARY KEY (S, H),
CONSTRAINT R_PH UNIQUE (P, H),
CONSTRAINT R_P FOREIGN KEY (P) REFERENCES P,
CONSTRAINT R_S FOREIGN KEY (S) REFERENCES S,
CONSTRAINT R_C FOREIGN KEY (C) REFERENCES C
) ; |
TABLE HGS
1 2 3 4 5 6 7 8
| CREATE TABLE HGS (
G INT NOT NULL,
S INT NOT NULL,
H INTERVAL NOT NULL,
CONSTRAINT HGS_ID PRIMARY KEY (G, H),
CONSTRAINT HGS_G FOREIGN KEY (G) REFERENCES G,
CONSTRAINT HGS_R FOREIGN KEY (S, H) REFERENCES R (S, H)
); |
On observera qu’il n’y a pas de table H (HORAIRE) : Le temps n’a en réalité pas à faire l’objet d’une entité-type au niveau du MCD, mais plutôt d’un type du genre INTERVALLE (INTERVAL), qui reste à définir de façon précise : JOUR plus tranche horaire.
Bilan :
La modélisation de l’énoncé initial n’est pas triviale, car les AGL ne permettent pas de produire les tables ci-dessus sans intervention manuelle (le coup de l’attribut H). Par ailleurs, sans une connaissance suffisante de la théorie relationnelle (dépendances fonctionnelles, axiomes d’Armstrong, théorème de Heath, clé candidate, BCNF...), la mise en évidence et le respect des DF énumérées relève d’une mission quasi impossible. Sans la mise en œuvre d’un type de la famille INTERVAL, la bilocation et le surbooking sont garantis...
Le temps est décidemment quelque chose de bien compliqué à maitriser, et même des cracks se font piéger et retoquer...
On peut dire qu'avec un tel exercice, vous avez été particulièrement gâté
Partager