Bonjour,
Vous postez dans le forum Merise, mais votre problème relève du niveau tabulaire. En effet ce que l’on appelle dépendance fonctionnelle en Merise est une contrainte entre entités-types, mise en œuvre par le truchement des associations-types (cf. la FAQ Merise
« CIF (ou dépendance fonctionnelle) de A à Z ».
En revanche, la dépendance fonctionnelle (DF) au sens du Modèle Relationnel de Données traduit une contrainte entre attributs au sein d’une table et une seule. A noter que la DF du Modèle Relationnel de Données a été définie et étudiée par Ted Codd en 1971 (E. F. Codd. “Further Normalization of the Data Base Relational Model”. IBM Research Report, RJ909, San Jose (August 31, 1971)), elle est bien antérieure à la DF merisienne, qu’il est plus prudent d’appeler Contrainte d’intégrité fonctionnelle (CIF) (Ministère de l'Industrie, Mission à l'Informatique, Centre Technique Informatique, Méthode de Définition d'un Système d'Informations, Fascicule 4. Juin 1979).
Étant donné que vous évoquez une dépendance fonctionnelle entre les attributs code devis et code client (que je renomme pour la suite en CodeDevis et CodeClient), je pars du principe que la table concernée est DEVIS.
La table CLIENT est étrangère au problème, elle ne doit pas comporter d’attribut CodeDevis. Sa structure est la suivante :
CLIENT {CodeClient, NomClient, AdresseClient, ...}
et elle a pour clé l’attribut CodeClient.
La structure de la table DEVIS est la suivante :
DEVIS {CodeClient, CodeDevis, Attr1, ..., Attrn}
Elle est dotée de deux clés :
K1 : {CodeClient}
K2 : {CodeDevis}.
K2 se justifie ainsi : puisqu’un devis fait référence à un seul client, il existe la dépendance fonctionnelle
DF01 : {CodeDevis} → {CodeClient}
Par construction, les attributs Attr1, ..., Attrn sont spécifiques à la table DEVIS et donc déterminés par l’attribut CodeDevis. Il existe alors la dépendance fonctionnelle
DF02 :{CodeDevis} → {Attr1, ..., Attrn}
K1 se justifie ainsi : puisqu’un client ne peut avoir qu’un seul devis, il existe la dépendance fonctionnelle
DF03 : {CodeClient} → {CodeDevis}
Et par application de la règle de transitivité (cf. Axiomes d’Armstrong), il existe la dépendance fonctionnelle
DF04 :{CodeClient} → {Attr1, ..., Attrn}
En vertu de ce qui précède, la réponse est affirmative. Mais il serait particulièrement maladroit de faire figurer l’attribut CodeDevis dans la table CLIENT, dans la mesure où elle absorberait la table DEVIS. En effet, vous seriez obligé d’utiliser autant de codes devis artificiels qu’il y a de clients, ou bien d’utiliser NULL, et dans ce dernier cas les résultats des opérations de jointure naturelle pourraient être faux.
Pour remonter au niveau conceptuel, le diagramme correspondant est le suivant (Power AMC, style E/R)
Par dérivation du MCD, le diagramme tabulaire est le suivant :
Et le code SQL produit par l'AGL :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
|
Create Table Client (
CodeClient Int Not null,
NomCLient Varchar(48) Not null,
AdresseCLient Varchar(48) Not null,
Constraint Client_PK Primary Key (CodeClient)) ;
Create Table Devis (
CodeClient Int Not null,
CodeDevis Int Not null,
Attr1 Varchar(48) Not null,
Attr2 Varchar(48) Not null,
Etc Varchar(48) Not null,
Constraint K1 Primary Key (CodeClient),
Constraint K2 Unique (CodeDevis),
Constraint Devis_Client Foreign Key (CodeClient)
References Client (CodeClient)) ; |
Partager