Discussion :

[MacFly58]

Bonjour,

Généralement, avant de bâtir un MCD, je réalise un graphe des dépendances fonctionnelles à partir du dictionnaire de données. Pratiquez-vous de la même manière ?

[lerieure]

Salut,

En générale ce graphe se fait en même temps que je fais mon Mcd (pour moi). Je modifie le graphe et le Mcd jusqu'à satisfaction. Mais je me focalise plus sur mon Mcd pour répondre à ta question.

[CinePhil]

Perso je passe directement au MCD. Je n'ai jamais fait de graphe de dépendances fonctionnelles. En fait je n'ai jamais compris suffisamment les arcanes de ce truc. (fsmrel va hurler ! )

[ok.Idriss]

Bonjour.

Perso je passe directement au MCD. Je n'ai jamais fait de graphe de dépendances fonctionnelles.

Bah dans la plupart des cas, elles sont tellement évidentes, qu'on peut AMHA directement passer au MCD (je fait très rarement un graph des DF lorsque j'ai à concevoir une bdd, dans ma formation ça nous ait parfois demandé).

Dans d'autres cas, elles peuvent nous aider à y voir plus clair pour exprimer certaine contraintes d'agrégation par exemple ...

Imaginons par exemple qu'on ait une entité classe (id_classe), prof (id_prof) et horraire (num_horraire, jour, heure_debut, heure_fin) avec une association ternaire enseigner et des cardinalités 1,n partout.

Cependant, il est à envisager qu'un prof ne peut enseigner sur une plage horraire qu'à une et une seule classe (sinon il aurait la faculté de se diviser en deux ce qui n'est pas très commun ). On a donc une DF id_prof, num_horraire --> id_classe, et le MCD précédent n'exprime pas cette DF qui est pourtant une règle de gestion.

Mais est-ce toujours la peine de faire un graph des DF complet ? Je ne pense pas personnellement (à part peut être au début lorsqu'on est pas habitué à faire des MCD).

Cordialement,
Idriss

[fsmrel]

Perso je passe directement au MCD. Je n'ai jamais fait de graphe de dépendances fonctionnelles. En fait je n'ai jamais compris suffisamment les arcanes de ce truc. (fsmrel va hurler ! )

Pourquoi hurlerai-je ? Je n’utilise pas de graphe de DF.

En effet, là où je vis, dans le Relationland on ne dessine pas, mais on y est équipé pour s’assurer de la normalisation des tables et c’est alors qu’il est nécessaire de savoir ce qu’est une fermeture d’un ensemble de DF, d’un ensemble d’attributs, une couverture irréductible, et autres joyeusetés, sans oublier les axiomes et règles, les algorithmes et théorèmes nécessaires pour faire danser tout ce petit monde, et qui nous permettent de prouver mathématiquement qu’une table est normalisée. Sans cet équipement nous ne pourrions que conjecturer.

Je vous renvoie à ce sujet au paragraphe E de l’article qui décrit tout ça, sans le moindre graphe.

[fsmrel]

Bonjour,

On a donc une DF id_prof, num_horraire --> id_classe, et le MCD précédent n'exprime pas cette DF qui est pourtant une règle de gestion.

A ceci près que, puisqu’il s’agit d’une règle de gestion des données et qu’on sait la prendre en compte dans le MCD, il ne faut pas s’en priver, en mettant en œuvre une CIF.

Dans l’exemple ci-dessous, la flèche qui a pour source l’association-type ENSEIGNER et pour cible l’entité-type CLASSE exprime la CIF :

PROF X HORAIRE → CLASSE

Pour faire bon poids, si deux professeurs ne peuvent pas enseigner en même temps à une même classe (à moins, bien sûr, que le prof p1 qui connaît les deux langues, ne soit là que pour traduire dans la langue l1 connue des élèves, la matière enseignée par le prof p2 qui ne connaît que la langue l2), on peut aussi définir la CIF :

CLASSE X HORAIRE → PROF

D’où le MCD à double CIF :


Du point de vue du Modèle Relationnel de Données, la relvar (variable relationnelle) ENSEIGNER est dotée de l’ensemble suivant de DF :

F = {{P, H} → {C}, {C, H} → {P}}

A partir duquel il est facile de montrer que cette relvar respecte la 6NF.

S’il fallait vraiment faire un graphe de DF, je suppose que celui-ci aurait l’allure amusante suivante (je ne tiens pas compte des attributs tels que ProfNom, etc.) :



Graphe que les « graphistes » auront évidemment bâti avant de passer au MCD et doter en conséquence l'association-type ENSEIGNER des CIF qui vont bien.

[MacFly58]

Bonjour à tous,

Tout d'abord, merci à lerieure pour avoir ressuscité ce topic du 4 juillet dernier

Ensuite, je tiens à ajouter que le graphe des dépendances fonctionnelles me semble être un outil extrêmement précieux pour les néophytes.

Lorsque l'on débute en informatique, concevoir un MCD reste à mon sens l'une des tâches les plus complexes. J'invite donc cordialement tous les débutants à se pencher sur cet outil.

Ce graphe, beaucoup plus simple et abordable qu'un MCD, permet de construire une ébauche de MCD qui sera juste à plus de 80% !
Quelques questions supplémentaires permettent de compléter le MCD et d'obtenir un MCD correcte, ce qui n'est pas une mince affaire pour la cohorte de débutants qui viennent lire ce forum


En espérant que mes obligations me permettront de venir discuter avec vous plus fréquemment, je vous souhaite une bonne journée.

MacFly

[CinePhil]

Ce graphe, beaucoup plus simple et abordable qu'un MCD,

Je pense exactement le contraire !

Je fais des morceaux de MCD sur les forums DVP et j'ai fait des MCD plus complexes avec un logiciel de modélisation mais je serais bien incapable de les traduire en graphes des dépendances fonctionnelles qui restent pour moi un pays étranger donc je ne pratique pas la langue.

Personne -0,n----Diriger----1,1- Projet

C'est quand même super facile à comprendre non ?
A minima, on comprend qu'une personne dirige un projet et on a fait la moitié du chemin. En se faisant expliquer le mécanisme des cardinalités, on établit la règle de gestion complète très facilement :
Une personne peut diriger plusieurs projet et un projet n'est dirigé que par une personne.

Ça donne quoi en graphe de dépendances fonctionnelles ?

[ok.Idriss]

Bonsoir.

Ça donne quoi en graphe de dépendances fonctionnelles ?

ça donne tout simplement :

id_projet --> id_personne

Mais sinon je suis tout à fait d'accord avec toi. Je trouve que le MCD est beaucoup plus significatif et facile à lire qu'un graphe des DF ... c'est peut être une question d'habitude.

De toute façon un graphe des DF ne suffit pas à modéliser une gestion des données de manière suffisamment complète. Pour moi, il s'agit juste d'une étape intermédiaire avant le MCD et facultative (le MCD traduit déjà toutes ces DF qui sont des règles de gestion).

Cordialement,
Idriss

[MacFly58]

Bonsoir,

Pour moi l'intérêt principal du graphe des DF n'est pas qu'il soit facile à lire (ça c'est un des rôles du MCD effectivement) mais qu'il permette de placer les propriétés dans les bonnes entités-types ou associations-types. En outre, le graphe des DF fourni une aide pour trouver les entités-types (ce qui est loin d'être simple pour un débutant).

Une quantité ou un prix est souvent mal placée par un étudiant. Pour le "nom du client" c'est facile il dépend du "n°client", mais le prix de vente... il dépend parfois de plusieurs données, c'est plus compliqué.

Dans tous les cas le graphe des DF permet de se poser de bonnes questions, qui font avancer la réflexion dans le bon sens.

La création directe d'un MCD de manière intuitive à ses limites, certaines personnes n'ont pas suffisamment d'expérience pour le faire.

Même sans parler de faire un graphe des DF complet, je pense qu'un petit graphe sur une partie d'un sujet étudié peut être d'une aide précieuse

[fsmrel]

Même sans parler de faire un graphe des DF complet, je pense qu'un petit graphe sur une partie d'un sujet étudié peut être d'une aide précieuse

Vous suivez ici la sage maxime latine : Utere sed non abutere (user mais ne pas abuser). Sinon, trois verres, bonjour les dégâts comme dit à sa façon le grand Yves Tabourier, qui s’en prend à des mathématiciens comme Zaniolo, Bernstein, Ullman, Maier, Delobel, etc., très au fait de la théorie de la normalisation et dont certains merisiens ont repris l’approche (mais sans les axiomes, théorèmes et algorithmes), je cite (De l’autre côté de Merise, pages 96-97) :

« [Des] propositions très en vogue dans l’approche relationnelle suggèrent de mettre au jour les dépendances entre les informations élémentaires, puis d’appliquer des techniques algorithmiques ou interactives pour rassembler ces informations par “ paquets ” et construire ainsi la structure du modèle... Même en se limitant aux informations dûment répertoriées antérieurement, on dispose souvent de quelques milliers d’informations élémentaires, donc de quelques millions de couples d’informations, ce qui ne représente qu’une partie des dépendances possibles : bon courage ! »

L’expression « par paquets » sous-entend essentiellement l’application — volontaire ou non (façon M. Jourdain) — du théorème de Heath. (Je signale quand même que je ne suis pas forcément d'accord avec Tabourier, algorithmes et théorèmes sont bien pratiques, voyez mon message suivant...)

J’en profite au passage pour vous soumettre une colle. J’ai entre les mains l’ouvrage suivant : Comprendre Merise, outils conceptuels et organisationnels. L’auteur traite de l’utilisation des graphes de DF (paragraphe II.5 de l’ouvrage : Graphe des dépendances fonctionnelles).

Il donne un exemple de cycle, sujet sur lequel je reviens :

Et il écrit :

« Si le graphe obtenu comporte des cycles, on élimine cette anomalie en supprimant une DF.
Le cycle e-f-d-e n’est pas admissible. On supprime par exemple d → e. »

Question : Le cycle e-f-d-e est-il vraiment inadmissible ? La suppression de la DF d → e est-elle sans importance ?

[Oishiiii]

Bonsoir à tous,

J’en profite au passage pour vous soumettre une colle. J’ai entre les mains l’ouvrage suivant : Comprendre Merise, outils conceptuels et organisationnels. L’auteur traite de l’utilisation des graphes de DF (paragraphe II.5 de l’ouvrage : Graphe des dépendances fonctionnelles).

Il donne un exemple de cycle, sujet sur lequel je reviens :

Et il écrit :

« Si le graphe obtenu comporte des cycles, on élimine cette anomalie en supprimant une DF.
Le cycle e-f-d-e n’est pas admissible. On supprime par exemple d → e. »

Question : Le cycle e-f-d-e est-il vraiment inadmissible ? La suppression de la DF d → e est-elle sans importance ?

Il est difficile de répondre à ces questions (pièges ?).

Le cycle e-f-d-e est-il vraiment inadmissible ?

Ces trois attributs ont l'air de bien s'entendre, ils sont très liés. Ça ne pose pas de problème.
L'auteur écrit qu'il s'agit d'une anomalie. Peut-être y-a-t'il des conséquences lors des opérations de mise à jour sur la relvar, mais c'est à prendre en compte au niveau de la définition des contraintes (Trigger en SQL, etc) et non pas lors du travail de conception ou de normalisation.
Passé l'originalité de la représentation graphique, je ne crois pas qu'un cycle soit inadmissible.

La suppression de la DF d → e est-elle sans importance ?

L'ensemble de DF est irréductible, si l'on supprime la DF on perd une règle de gestion et un peu du sens de la relvar, donc ce n'est pas sans importance.

Mais d'un autre côté, lorsque j’essaie de représenter cette relvar de manière tabulaire, j’obtiens ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
	C	D	E	F
	---------------------------
	12	1	2	4
	13	3	6	8
	14	1	2	4

Même en faisant abstraction de la DF d → e, je n'arrive pas à ajouter une ligne qui violerait cette DF.
Une fois que l'on a "valué" E, le reste suit naturellement puisque E détermine fonctionnellement à la fois F et D (par transitivité).
La DF ne semblerait donc pas nécessaire.

Donc j'en conclus qu'en supprimant la DF ont perd une règle de gestion, mais cette règle de gestion semble inutile.

[fsmrel]

Bonsoir,


Merci Oishiiii de vous être lancé dans cette affaire...

Il est difficile de répondre à ces questions (pièges ?)

Effectivement, ça n’est pas si simple. Même dans le contexte de la théorie relationnelle, quand il s’agit de fournir l’inventaire des dépendances fonctionnelles associées à une variable relationnelle, la prise en compte de cycles pose un problème intéressant (et à mon avis sans solution) dès qu’on est aux prises avec une quelconque hiérarchie ou nomenclature, c'est-à-dire quand la récursivité joue les trouble-fête et que l'on s'engage dans une spirale infinie.

Voyez la discussion ouverte par princeau. A mon avis, la seule possibilité au niveau conceptuel pour ce genre de situation : passer directement au MCD. Mais j’ai peut-être raté quelque chose, aussi la collaboration de tous est la bienvenue pour traiter du dilemme récursivité vs fermeture des DF.

lorsque j’essaie de représenter cette relvar de manière tabulaire, j’obtiens ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 C    D   E   F
 --------------- 
 12   1   2   4
 13   3   6   8
 14   1   2   4

Même en faisant abstraction de la DF d → e, je n'arrive pas à ajouter une ligne qui violerait cette DF.

En l'absence de la DF, les deux dernières lignes ci-dessous ne posent-elles donc pas de problème ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 C    D   E   F
 --------------- 
 12   1   2   4
 13   3   6   8
 14   1   2   4
 15   1   7   9
 16   1   0   9

Supposons maintenant que dans l’univers du discours (par exemple l’entreprise Dubicobit) les propriétés c, d, e, f représentent respectivement l’adresse de courriel d’un employé, son matricule, son numéro de sécurité sociale et son pseudonyme.

Si on suit l’auteur, la DF {matricule} → {numéro de sécurité sociale} représenterait une anomalie, ce que je réfute évidemment. Le graphe ne comporte aucune anomalie et l’on ne peut faire l’économie d’aucune des DF qu'il comporte.

Ainsi, la suppression de la DF {matricule} → {numéro de sécurité sociale} relève d’une méthode qui n’est manifestement pas la bonne car ne permettant pas d’obtenir une solution avec laquelle les règles de gestion sont préservées. On doit donc conserver les cycles entre les propriétés, et l’on peut s'appuyer sur un MCD du genre de celui qui suit, selon lequel les règles sont préservées :



MCD (réalisé avec l’outil Power AMC) dans lequel :

Le mickey <pi> symbolise dans l’entité-type RE les dépendances fonctionnelles {E} → {F} et {E} → {D} (« pi » est l’abréviation de primary identifier).
Le mickey <ai1> symbolise les dépendances fonctionnelles {F} → {D} et {F} → {E} (« ai » étant l’abréviation de alternate identifier).
Le mickey <ai2> symbolise les dépendances fonctionnelles {D} → {E} et {D} → {F}.

Peu importe en passant que ce soit D, E ou F qui serve pour être identifiant « primaire ». C'est un peu une histoire de chaises musicales.

Pour aller dans le sens de MacFlight58, ce MCD est en fait la conséquence de l'utilisation de l'algorithme du seau appliqué à l’ensemble initial de DF associé à la relvar R {C, D, E, F} :

{{C} → {E}, {E} → {F}, {F} → {D}, {D} → {E}}.

Par application de l’algorithme, on produit en effet les fermetures :

{C}+ = {C, D, E, F},
{D}+ = {D, E, F},
{E}+ = {D, E, F},
{F}+ = {D, E, F}.

Ce qui permet de constater que seul le singleton {C} est clé candidate de R, qu'il existe des DF dont les déterminants ne sont pas clés, donc que la BCNF est violée, en vertu de quoi il faut appliquer le théorème de Heath permettant de décomposer R en RC et RE :

RC {C, E},
RE {E, F, D}.

RE comporte à son tour les fermetures :

{D}+ = {D, E, F},
{E}+ = {D, E, F},
{F}+ = {D, E, F}.

Et cette fois-ci, {D}, {E} et {F} sont clés candidates de RE, la BCNF est respectée (la 6e aussi d’ailleurs). Il ne reste plus qu’à réaliser une rétro-conception pour obtenir le MCD ci-dessus.

Maintenant, si l’on supprime la DF {D} → {E}, la relvar RE a pour ensemble de DF associé :

{{E} → {F}, {F} → {D}}.

Et par application de l’algorithme du seau, on produit les fermetures :

{D}+ = {D},
{E}+ = {D, E, F},
{F}+ = {D, F}.

Ce qui montre que seul le singleton {E} est clé candidate. Du fait de la DF {F} → {D}, la BCNF est violée et RE doit être décomposée (toujours en appliquant le théorème de Heath) :

RE’ {E, F},
RF {F, D}.

Par rétro-conception, le MCD correspondant est le suivant :


Qui évidemment n’est pas équivalent au précédent. Et comme en plus de la DF {D} → {E} on a aussi perdu la DF {F} → {E}, les dégâts peuvent être importants dans le cas de l'entreprise Dubicobit.


Votre opinion ?


N.B. A cette occasion, je trouve que Tabourier n’a pas spécialement raison d’en vouloir à ceux qui ont pondu des algorithmes tels que celui du seau ou encore des théorèmes tels que celui de Heath (voyez mon message précédent). Pour ma part, je trouve tout cela fort pratique et en sais gré aux chercheurs mis en cause.

[CinePhil]

Pas sûr d'avoir tout compris vu mon niveau voisin de zéro dans cette langue étrangère et quand je ne comprends pas, j'essaie de me rattacher à des choses que je peux comprendre...

Supposons maintenant que dans l’univers du discours (par exemple l’entreprise Dubicobit) les propriétés c, d, e, f représentent respectivement l’adresse de courriel d’un employé, son matricule, son numéro de sécurité sociale et son pseudonyme.

On doit donc conserver les cycles entre les propriétés, et l’on peut s'appuyer sur un MCD du genre de celui qui suit, selon lequel les règles sont préservées :

Si je lis bien ce qui précède, cela voudrait dire que :
1) Une RA {A, B, G} n'est associée qu'à une RC {C (courriel)} et qu'une RC {C (courriel)} peut être associé à plusieurs RA{A, B, G}.

Comme on ne sait pas ce que représente RA ni ses attributs, c'est possible.

2) Une RC {C : (courriel)} n'est associée qu'à une RE {E (n° sécu), F (pseudo), D (matricule)} et une RE {E (n° sécu), F (pseudo), D (matricule)} peut être associée à plusieurs RC {C : (courriel)}.

En clair, une personne peut avoir plusieurs courriels et un courriel n'appartient qu'à une personne. C'est cohérent.

Continuons le parcours tracé par François...

Par rétro-conception, le MCD correspondant est le suivant :

Cette fois, nous avons en 2) :
Un courriel n'est associé qu'à un numéro de sécu et un numéro de sécu peut avoir plusieurs courriels.
Ça reste cohérent.

Et arrive en 3) :
Un numéro de sécu n'est associé qu'à un RF {F (pseudo), D (matricule)} et un RF {F (pseudo, D (matricule)} peut avoir plusieurs numéros de sécu.

Une personne définie par son pseudo et son matricule peut-elle avoir plusieurs numéros de sécu ?

Dois-je alors comprendre que la fin du message, à partir de "Maintenant, si l’on supprime la DF {D} → {E}," cherche justement à démontrer que ce n'est pas acceptable ?

[fsmrel]

Bonjour,

Pas sûr d'avoir tout compris vu mon niveau voisin de zéro dans cette langue étrangère et quand je ne comprends pas, j'essaie de me rattacher à des choses que je peux comprendre...

C’est la langue du Relationland (le pays des bases de données relationnelles) et il ne tient qu’à vous de vous y mettre . La « Méthode à Mimile » ad-hoc n’ayant pas été publiée, je vous suggère de lire l’ouvrage de référence (et pas hermétique pour deux sous) An Introduction to Database Systems de C. J. Date. Vous pouvez aussi relire l’article que j’ai commis, dans lequel je traite de la normalisation, et n’hésitez pas au besoin à poser des questions, je répondrai dans la mesure de mes moyens.

Si je lis bien ce qui précède, cela voudrait dire que :
1) Une RA {A, B, G} n'est associée qu'à une RC {C (courriel)} et qu'une RC {C (courriel)} peut être associé à plusieurs RA{A, B, G}.

Comme on ne sait pas ce que représente RA ni ses attributs, c'est possible.

Bien que le thème qu’il traite soit le dictionnaire des données, l’auteur du graphe cyclique est muet quand à la signification de a, b, c, d, e, f et g. Je considère donc qu’il nous laisse le soin de mettre dans tout ça la sémantique que l'on veut. J’ai commencé le travail, tout y-celui que cela intéresse peut participer au jeu et compléter. Par exemple la propriété a pourrait représenter le numéro de téléphone de l’employé, la date de ses congés, bref tout ce que l'imagination peut suggérer. Si vous avez des idées...

Une personne définie par son pseudo et son matricule peut-elle avoir plusieurs numéros de sécu ?

Dois-je alors comprendre que la fin du message, à partir de "Maintenant, si l’on supprime la DF {D} → {E}," cherche justement à démontrer que ce n'est pas acceptable ?

Bingo ! L’objet est de prouver que l’on ne peut pas affirmer gratuitement et impunément qu’un cycle est inadmissible, simplement en claquant des doigts. Les a priori ne peuvent ni infirmer ni remplacer les théorèmes.

[MacFly58]

Je pense que dans ce cas j'aurai créé 5 entités-types (A C E F D), et que chaque flèche entre les propriétés a c e f d prendrait la forme d'une association-type de la forme "un à plusieurs" (soit 5 associations-types au total). Il me semble qu'ainsi je ne perds aucune règle de gestion.

[fsmrel]

Bonjour,

Je pense que dans ce cas j'aurai créé 5 entités-types (A C E F D), et que chaque flèche entre les propriétés a c e f d prendrait la forme d'une association-type de la forme "un à plusieurs" (soit 5 associations-types au total). Il me semble qu'ainsi je ne perds aucune règle de gestion.

Si j’interprète correctement ce que vous dites, on peut obtenir ceci (les flèches symbolisent les clés étrangères) :



Mais alors pour une valeur de l’attribut f (relvar E), on peut avoir plus d’une valeur de l’attribut e, c'est-à-dire une anomalie.

=> Pas d'accord...

[ablaye_m]

Bonsoir quel logiciel utiliser pour réaliser le Graphe des dépendance fonctionnel.

[fsmrel]

Bonjour Abdul,


Je ne sais pas s’il existe des logiciels pour cela. Pour ma part, j’ai tout fait à la main...

[djoumajac]

avec le dictionnaire de données mais aussi avec les règles de gestion