la matrice des dépendances fonctionnelles

[cedfr]

Bonjour,
Quelqu'un aurait-il un cours sur la matrice des dépendances fonctionnelles car j'ai un peu de mal là dessus.
J'ai un exercice avec comme document un devis pour des travaux, dans ma matrice, j'ai donc les propriétés de mon dictionnaire de données et je dois mettre en avant les dépendances entre elles. Mais, mon problème est qu'avec la propriété "numéro de devis", il y a dépendance avec quasiment toutes les autres propriétés: sur le devis, il y aura une seule date, un seul client (nom, prénom, adresse, ville...), un seul prix total à payer, un seul commercial, un seul chef de travaux...
A la fin, il me reste quasiment plus rien à regrouper, je pense qu'il faudrait faire une dépendance pour tout ce qui est en rapport avec le client, avec le commercial, le chef des travaux... mais par définition, ce que j'ai fais n'est pas faux (enfin il me semble) puisque la dépendance c'est: a A correspond un unique B.

J'espère que vous avez compris mon problème, vous avez un petit cours, une idée sur mon sujet ????

Je vous remercie.

 

[cedfr]

Personne ? :cry:

 

[vestale974]

Salut,
Sur ton document, on doit pouvoir identifier les données relatives :
- devis (Id_devis et Date_devis)
- client (Id_client, nom_cli, etc.)
- cheftravaux (Id_cheftvx, nom_cheftvx, etc.)
- commercial (Id_com, nom_com, etc.)
- produit (Id_prod, désignation_prod, PU_prod, etc.)

Le dictionnaire de données final ne doit contenir que des données élémentaires. Aucunes données "paramétrées" ni "calculées". Donc, je doute que tu puisses avoir dans ta matrice "prix total à payer".

La matrice reprend toutes les données élémentaires retenues dans le dictionnaire finale.

1° étude des DF élémentaires directes (A -> B) où A représente une donnée SOURCE (tête colonne de la matrice) et B une donnée BUT (tête de ligne de la matrice). On interroge la matrice comme suit ; "pour une donnée SOURCE existe-t-il qu'une seule donnée BUT ?" Si OUI, on met une encoche, si NON on ne met rien.
Exp :
Pour un Id_devis (SOURCE) existe-t-il qu'une seule Date_devis (BUT) ? Réponse : OUI

2° étude des DF transitives (A -> B, B -> C) où A représente une donnée SOURCE et C une donnée BUT.
Cette étude s'impose dès lors que l'on retrouve sur des lignes de BUT plusieurs encoches. Il y a là, doublon ou redondance.
On interroge la matrice comme suit ; "Pour une donnée SOURCE existe-t-il une donnée B, et pour cette même donnée B existe-t-il qu'une seule donnée BUT ?" Si OUI, toutes les données BUT qui dépendent de la donnée B devront être supprimées dans la SOURCE.
Exp :
Dans ta matrice tu as forcément des doublons sur les lignes de BUT relative au client ou autre au travers des SOURCES Id_devis et Id_client, parce que tu as du répondre OUI à :
- Pour un Id_devis existe-t-il qu'un seul nomp_cli ?
- Pour un Id_cli existe-t-il qu'un seul nom_cli ?
Donc la donnée BUT Id_cli qui se trouve dans la SOURCE Id_devis est une donnée transitive. Et parce qu'elle est donnée transitive tu supprimeras les données relatives au client se trouvant dans la SOURCE Id_devis.

La définition que je donne pour une donnée transitive est : "c'est une donnée BUT, propriété SOURCE d'une autre propriété SOURCE, à caractère binaire dont les valeurs sont égales à 1". C'est bien le cas pour Id_cli. On le trouve en ligne (donnée BUT), on le trouve en tête de colonne (donnée SOURCE) et appartient à une autre SOURCE (tête de colonne Id_devis). Et une donnée transitive n'est autre qu'une contrainte d'intégrité fonctionnelle (CIF) représentée par la cardinalité (1,1).

3° étude des DF composées (A, B -> C) où A et B représente des données SOURCE et C une donnée non reliée.
Cette étude s'impose dès lors que l'on constate dans la matrice des données BUT sans propriétés SOURCE.
Exp :
la donnée BUT Quantité est une donnée non reliée, elle n'appartient ni à Devis, ni à Produit, mais sera reliée aux deux. Elle se représente sous la forme d'une pseudo-entité (Contrainte d'intégrité multiple CIM)

@+