Bonsoir Chicna,
On ne va peut-être pas trop s’embêter avec cette histoire de pointe de flèche...
N’empêche qu’elle m’entraîne vers un sujet plus vaste et de grande portée, sur lequel je suis intarissable, celui de la dépendance fonctionnelle. Sait-on jamais Chicna, peut-être serez vous intéressé ?
Il est manifeste que la représentation graphique que vous avez utilisée met en évidence le fait qu’une relation binaire dont une des cardinalités est 1,1 induit une dépendance fonctionnelle au sens Merise du terme. Il est bon de noter ce qu’écrit Nanci dans la FAQ Merise à ce sujet : "CIF (ou dépendance fonctionnelle) de A à Z"
http://merise.developpez.com/faq/?pa...CD_CIF#MCD_CIF
Dépendance fonctionnelle et CIF
Dans Merise, ces deux termes recouvrent globalement la même notion. Le terme dépendance fonctionnelle fait référence à une notion mathématique entre ensembles.
On dit que, entre deux ensembles A et B, il existe une dépendance fonctionnelle si à un élément (a) de A ne correspond qu'un élément (b) de B. On note cette dépendance A ---> B. On appelle A l'origine, et B la cible de la dépendance fonctionnelle.
Il existe également des dépendances plus complexes lorsque l'ensemble d'origine est composé de "n-uples" d'éléments A x B ---> C
Dans Merise cette notion s'applique explicitement aux relations; elle ne se modélise pas indépendamment des relations; elle ne prend son sens que dans le cadre d'une relation citée. On dit alors que cette relation est porteuse d'une dépendance fonctionnelle ou d'une CIF (contrainte d'intégrité fonctionnelle).
La mise en oeuvre de la notion dépend de la dimension de la relation.
a/ Dans une relation binaire, une cardinalité maxi à 1 (0,1 ou 1,1) sur l'une des pattes induit obligatoirement une dépendance fonctionnelle.
Dans l'exemple suivant, on dit usuellement que la relation "est située dans" est (porteuse d') une dépendance fonctionnelle. Il est inutile d'utiliser un symbole explicite.
Je ne vois pas de justification autre que graphique à l’ajout de la pointe de flèche (ou bien quand il y a bijection entre 2 entités-types). Mais passons à autre chose. Maintenant que j’ai dégusté un bon petit Lagavulin bien tourbé, il me paraît intéressant de comparer l’usage que l’on fait des dépendances fonctionnelles en Merise d’une part, dans la théorie relationnelle d’autre part.
Comme dit Nanci dans la citation que j’ai faite, "Dans Merise cette notion s'applique explicitement aux relations ; elle ne se modélise pas indépendamment des relations; elle ne prend son sens que dans le cadre d'une relation citée."
On remarquera par ailleurs que la source et la cible sont des entités-types (l’histoire ne dit pas si une DF peut avoir des relations-types pour source/cible, mais peu importe, j’observe quand même que (Roch89) n’est pas contre (pages 192-193)).
J’ai aussi le sentiment que, si je fais référence aux écrits merisiens (notamment (TRC89), (Roch89) et (Tab86)), les cardinalités maximales 1 figurant dans les relations binaires de vos MCD entraînent une transformation de facto de toutes ces relations en DF (dépendances fonctionnelles), lesquelles sont à interpréter au sens merisien et non pas au sens originel, coddien du terme.
De la DF selon Merise à la DF selon Codd.
Je reprends un petit Lagavulin. Pour en venir à la théorie relationnelle, on y utilise les DF dans un but totalement différent, qui n’est pas de définir des contraintes inter-entités. Si l’on passe au niveau tabulaire, les DF sont des contraintes non pas entre tables, mais entre ensembles d’attributs d’une table donnée et elles serviront fondamentalement à déterminer la liste exhaustive des clés candidates de cette table et à la normaliser, c’est-à-dire la casser pour la purifier si cela s’avère nécessaire.
Il y a plus de trente ans, Ted Codd (Codd71) a introduit ainsi le concept de DF : If D,E are distinct collections of attributes of R, E is functionally dependent on D if, at every instant of time, each D-value has no more than one E-value associated with it under R.
R est ce que l’on appelle une relation dans le Modèle Relationnel de Données, ça n’est pas une relation au sens Merise du terme, et c’est ce que l’on appelle informellement une table en SQL (1).
Codd note ainsi la DF : R.D -> R.E
Il donne certaines définitions qui lui seront utiles pour ses travaux sur la normalisation des relations (2e et 3e formes normales) :
Par exemple, si E est un sous-ensemble de D, alors la DF R.D -> R.E est dite triviale.
Ou encore : si pour cette DF, E représente la collection de tous les attributs de R et si l’évacuation de D d’un quelconque attribut fait que la DF perd sa propriété d’unicité, alors D est une clé candidate de R : une clé candidate doit donc vérifier deux propriétés, non seulement celle d’unicité, mais aussi celle — tout aussi capitale — d’irréductibilité, cette dernière étant généralement trop vite oubliée.
Ces deux propriétés sont fondamentales, mais si on se souvient bien de la première, la seconde passe généralement à la trappe. A titre d’exemple, dans (TRC89), paragraphe 5.7.3 "Règles de passage du modèle conceptuel des données au modèle logique dans une représentation relationnelle", l’auteur fournit la liste des relations (au sens relationnel) obtenues par application des règles de passage du MCD au MLD. Le cas traité est celui d’une entreprise de distribution (grande surface).
Selon le MCD, un magasin passe des commandes et une commande est passée par un et un seul magasin :
Figure 1 - Une commande est passée par un seul magasin
Lors du processus de passage du MCD au MLD, la relation binaire ci-dessus fait l’objet d’une table LISTE CDE MAGASIN ayant (selon l’auteur) pour "identifiant relationnel" (terme absent au demeurant de la théorie relationnelle et que l’on assimilera à l’une des clés candidates, à savoir la clé primaire) :
{numéro magasin, numéro commande magasin}
mais je conteste, car il existe la DF : {numéro commande magasin} -> {numéro magasin}
En vertu de quoi ce prétendu "identifiant relationnel" se réduit à : {numéro commande magasin}
L’auteur a ainsi violé le principe d’irréductibilité des clés candidates. En fait, il s’appuie sur une règle trop simple qu’il donne :
Envoyé par
(TRC89)
L’identifiant de la relation au sens relationnel est obtenu en concaténant les identifiants des individus qui participent à la relation au sens individuel.
Il eut été souhaitable qu’il prît connaissance du principe d’irréductibilité. L’oubli de cette propriété peut s’avérer désastreux, puisque rien n’interdira qu’au niveau tabulaire, la table LISTE CDE MAGASIN contienne des numéros de commande faisant référence à plus d’un numéro de magasin.
Quelques précisions. Dans (Roch89), est donnée la définition suivante de la DF :
Envoyé par
(Roch89)
Il existe une DF entre deux propriétés P1 et P2 d’un individu ou d’une relation donnés si à toute valeur de P1 on ne peut associer à tout instant qu’une seule valeur de P2. P1 est alors la source de la DF et P2 le but.
Cette définition est très restrictive, puisqu’elle ne met en jeu que des singletons.
Je fais aussi observer qu’une DF met en jeu non pas des attributs mais des ensembles d’attributs (au sens de la théorie des ensembles) quoique je reconnaisse qu’il m’arrive de parler d’attributs au lieu d’ensembles (cf. ci-dessous...)
Mais, (TRC89) donne une définition supplémentaire de la DF, rejoignant celle de Nanci :
Envoyé par
(TRC89)
La dépendance fonctionnelle ou D.F. inter-individus est un cas particulier de relation binaire. Elle traduit le fait que connaissant une occurrence de l’un des deux individus composant la collection de la relation, on connaît directement une et une seule occurrence de l’autre individu.
Figure 2 - La dépendance fonctionnelle, cas particulier de la relation binaire
Incidemment, (ROCH89) et (TRC89) — en fait le même auteur — donnent deux définitions différentes de la DF, mais la première (qui s’intéresse aux propriétés) sert à introduire la seconde (qui s’intéresse aux relations entre individus), laquelle prévaut donc.
Yves Tabourier émet des réserves quant à l’emploi du terme "Dépendance fonctionnelle" en Merise
Envoyé par
(Tab86)
Cette appellation présente quelque danger, le terme de “dépendance fonctionnelle” étant utilisé dans le formalisme relationnel dans un sens beaucoup plus large.
Prudent, Tabourier parle de "contrainte de cohérence fonctionnelle".
De mon côté, je ne vois pas en quoi la DF est un cas particulier de la relation binaire qui lie Commande Magasin et Magasin (figures 1 & 2). En effet, une commande est en relation (binaire) avec un et un seul magasin et j’aimerais savoir à quelle occasion une relation binaire n’est ni une DF ni une CIF (qui, pour l’auteur, est un cas particulier de la DF).
Après tout, peu importe. Mais si en Merise on met en œuvre un système de dépendances fonctionnelles, alors, soit on précise bien qu’il ne s’agit en aucune façon des DF de la théorie relationnelle, qui leurs sont bien antérieures, soit, comme le laisse entendre Tabourier, on utilise un autre terme, ou bien on précise qu’on les utilise telles qu’elles sont définies dans la théorie relationnelle, dans le but de normaliser les entités-types (et relations-types) très exactement comme on le fait pour des tables.
En effet, de nombreux concepteurs de servent des DF de Codd pour normaliser, voire élaborer leurs entités-types et on ne saurait les en blâmer ! On rencontre souvent sur ce forum l’expression "Graphe de dépendances", manifestement dans le cadre de la normalisation.
Voir par exemple le document ftp://ftp-developpez.com/cyril-gruau/ConceptionBD.pdf
Des axiomes d’Armstrong. Clés candidates, normalisation.
Et encore un petit Lagavulin. La DF au sens de Codd ne se limite pas à l’expression d’une contrainte. Elle permet de mettre en évidence les clés candidates d’une relvar (abréviation de relation variable, informellement table) et de vérifier que celle-ci est normalisée BCNF (forme normale de Boyce-Codd).
Considérons en effet l’énoncé de la BCNF :
Une relvar S est en forme normale de Boyce-Codd (BCNF) si et seulement si
pour chaque dépendance fonctionnelle non triviale X -> Y satisfaite par S, X est une surclé de S.
X et Y sont des ensembles quelconques d’attributs de S.
Une surclé est comme une clé candidate, à ceci près qu’elle n’est pas astreinte à respecter le principe de minimalité énoncé plus haut.
La DF : X-> Y est triviale si et seulement si Y est un sous-ensemble (non nécessairement strict) de X, c’est-à-dire que cette DF est inviolable.
Cf. http://www.developpez.net/forums/sho...d.php?t=281221
Ce qui est important de noter, c’est que dans la définition de la BCNF chaque DF est impliquée. On doit donc dresser la liste complète des DF de la relvar.
Ceci est rendu possible par la mise en œuvre d’algorithmes mettant en jeu les axiomes d’Armstrong.
Soit A, B et C des sous-ensembles quelconques d’attributs de la relvar S. Notons AB l’union de A et de B.
Les axiomes sont les suivants :
Réflexivité : Si B est un sous-ensemble de A, alors A -> B
Augmentation : Si A -> B, alors AC -> BC
Transitivité : Si A -> B et B -> C, alors A -> C
Ces axiomes et les règles inférées permettent d’obtenir l’ensemble complet des DF, que l’on appelle la fermeture F+ et qui est donc l’ensemble des DF impliquées par un ensemble donné de DF de S.
Pour simplifier la mise en évidence de nouvelles DF et calculer F+, on utilise quelques règles couramment utilisées à cet effet et inférées des trois premiers axiomes :
Décomposition : Si A -> BC, alors A -> B et A -> C
Union : Si A -> B et A -> C, alors A -> BC
Composition : Si A -> B et C -> D, alors AC -> BD
Ces règles sont assez faciles à inférer. Par exemple, pour démontrer la règle de décomposition : 1. A -> BC _______(donné)
2. BC -> B _______(réflexivité)
3. A -> B ________(1 et 2, transitivité)
Sans les axiomes d’Armstrong, on est pratiquement dans l’impossibilité de mettre en évidence l’ensemble F+ des DF pour une relvar. Chris Date en donne un exemple.
Désignons par : A : le numéro matricule d’un employé dans une entreprise,
B : le numéro d’un service dans l’entreprise,
C : le numéro matricule du patron du service,
D : le numéro d’un projet,
E : le nom du service,
F : le temps passé par un patron de service sur un projet.
Et considérons les DF suivantes, données : A -> BC
B -> E
CD -> EF
Les algorithmes utilisés pour calculer F+ permettent de produire la DF suivante : AD -> F
En effet : 1. A -> BC _______(donné)
2. A -> C ________(1, décomposition)
3. AD -> CD ______(2, augmentation)
4. CD -> EF ______(donné)
5. AD -> EF ______(3 et 4, transitivité)
6. AD -> F _______(décomposition)
La DF non intuitive AD -> F ne revêt par a priori une importance particulière, mais je rappelle que le but est de dresser la liste de l’ensemble des DF pour pouvoir vérifier qu’une relvar ne viole pas la BCNF (idem en Merise, pour une entité-type ou une relation-type, toutes choses égales par ailleurs).
Il est remarquable que l’axiome d’augmentation soit omniprésent dans les démonstrations (normal, c’est un axiome !) Et on voit à cette occasion combien, à une contrainte d’unicité près, la dépendance fonctionnelle de la théorie relationnelle n’a strictement rien à voir avec celle de Merise où elle est considérée comme n’étant qu’un cas particulier d’une relation binaire (cardinalité 1,1).
Pour l’anecdote, il est amusant de constater que si l’on appliquait les axiomes d’Armstrong à la DF merisienne, celui d’augmentation serait en contradiction avec un des principes fondamentaux de Merise, posé dès l’origine (CTI79) :
Une propriété ne peut qualifier qu’un seul objet ou seule relation.
Imaginez en effet trois entités-types Développeur, Entreprise, SGBD et la contrainte selon laquelle un développeur appartient à une seule entreprise, donc que l’on ait la DF merisienne : Développeur -> Entreprise
Quel sens cela a-t-il d’écrire en Merise : Développeur U SGBD -> Entreprise U SGBD ?
Pour en revenir à votre sujet, quel fichu cocktail je vous ai concocté... Et il faudra que je file du côté de la grande surface me ravitailler en Lagavulin, lequel commence à me faire sérieusement défaut.
Notes
(1) Une relation (R) au sens relationnel est plus proche de la relation (M) au sens mathématique, avec quelques différences, du genre : M ne varie pas dans le temps, R est munie d’un entête (schéma) qui est un ensemble (non ordonné par définition) dont les éléments sont des couples <nom d’attribut, nom de type>, alors que l’hypothétique entête de M est une liste ordonnée de noms de domaines (les termes domaine et type étant interchangeables en ce qui concerne le Modèle relationnel), etc.
Références
(Codd71) E.F Codd : "Further normalization of the data base relational model", document IBM RJ909 (#15857), 1971
(CTI79) 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
(Tab86) Yves Tabourier "De l’autre côté de Merise", Les Éditions d’Organisation, 1986
(TRC89) Hubert Tardieu, Arnold Rochfeld, René Colletti : "La méthode Merise, Tome 1 - Principes et outils" Les Éditions d’Organisation, nouvelle édition 1989
(Roch89) Arnold Rochfeld, José Morejon : "La méthode Merise, Tome 3 - Gamme opératoire" Les Éditions d’Organisation, 1989
Modéliser les recettes de cocktails
Répondre avec citation
Partager