Discussion :

[jpastier]

Bonjour à tous,

J'ai un petit problème avec l'interprétation d'une dépendance fonctionnelle.
Je m'explique :

J'ai une entité client et une entité devis.
Le client peut être un prospect ou un véritable client.
Si c'est un prospect, il n'existe pas de devis concernant ce client, si c'est un client il existe un et un seul devis le concernant.

J'ai bien compris qu'il existait une dépendance fonctionnelle entre le code devis et le code client puisqu'on peut retrouver un et un seul code client à partir du code devis.
Mais le contraire est-il vrai également ?
En effet, il existe des client auxquels on ne peut pas faire correspondre de code devis puisqu'il n'existe pas dans la base.

Ma question : dans ce cas là, as-t-on tout de même une dépendance fonctionnelle entre code client et code devis ?

Merci de vos réponses.

Jean-Pierre

[fsmrel]

Bonjour,

J'ai bien compris qu'il existait une dépendance fonctionnelle entre le code devis et le code client puisqu'on peut retrouver un et un seul code client à partir du code devis.
Mais le contraire est-il vrai également ?

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}

il existe des client auxquels on ne peut pas faire correspondre de code devis puisqu'il n'existe pas dans la base. [...] dans ce cas là, as-t-on tout de même une dépendance fonctionnelle entre code client et code devis ?

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 :

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
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)) ;

[jpastier]

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 :

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
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)) ;

Merci beaucoup de cette réponse claire et précise !!!!
Jean-Pierre