Discussion :

[endworld]

Bonjour voila lors de la conception de mon MCD j'ai rencontré une difficulté car je ne sais pas si on a le droit de metre une donnée dans une relation de type 0-1 0-n car je n'est vue aucune règle qui l'interdit :S

je vous remercie d'avance pour votre aide

[Fleur-Anne.Blain]

Bonjour,

Le 0.X et 0.X est un cas disons impossible. Qui créer qui? quelle entité est créée avant l'autre? tu ne peux le savoir il te faut un 1 en minimum.

@+

[endworld]

en fait dans mon cas un membre pouvait noter une vente (mais n'est pas obligé de la noter) et une vente pouvait etre noté par un seul membre

et j'ai mis cette cardinalité (0-1 0-n) car cette fonctionnalité est optionnel

[Fleur-Anne.Blain]

Ta vente est notée obligatoirement? Sinon tu mets: 1.1 pour les ventes, notées par un et un seul membre( mais obligatoire) par contre le fait qu'un membre note peut etre "optionnel" avec 0.n il ne pas noter ou noter plusieurs ventes.

[endworld]

c'est la le problème car une vente n'est pas obligatoirement notée et dans la relation "Membre - Vente" j'avais mis des données tel que "Note et Commentaire"

[Fleur-Anne.Blain]

Peux-tu mettre ton modèle en pièce jointe? il doit y avoir un moyen de contourner ce problème en déplaceant les champs ou autres...

[endworld]

http://img72.imageshack.us/img72/4645/sanstitreuh7.jpg

voila ^^ en tout cas je te remerci pour ton aide car la je bloc un peut :S

[Fleur-Anne.Blain]

Il y a une association noter vendeur...c'est le vendeur ou la vente que tu notes??? tu peux peut-être créer une table note au lieu de ton association entre membre et vente et dans ce cas tu pourras mettre du 0.n coté membre et 1.n côté vente ( ou tu peux mettre en hypothèse plus probable qu'une vente a au moins eu un vote). Je ne vois pas d'autres solutions...

@+

[endworld]

en fait c'est plus noter une "vente" que "vendeur" mais j'ai préférer mettre "vendeur" car par l'intermédiaire de la vente il note le "vendeur"

sinon pour ta proposition j'y avais pas penssé ^^ en tout cas j'y avait pas pensé ^^

[fsmrel]

Bonjour EndWorld

Concernant le Modèle Entité-relation, il n’y a pas de standard comme il peut y en avoir un concernant SQL.

Au sens Merise, une relation-type R à cardinalités 0,n/0,n peut-être porteuse de données, car cela a un sens sémantique. Si l’on considère que la configuration 0,1/0,n est un cas particulier du précédent, toujours au nom de la sémantique, il n’y a aucune raison pour que soudain un règlement dise : « la relation-type R ne peut plus être porteuse de données ». Cela tiendrait de l’incantation, de l’arbitraire.

Maintenant, il faut voir ce qui se passe au niveau où l’on opère, disons tabulaire. Pour prendre votre MCD, lors de la dérivation de celui-ci sous forme de tables, votre AGL logera par exemple la propriété (devenue colonne) Noter_Note_VenAch dans la table Ventes. Tout se passe donc comme si vous aviez donc déjà déporté de vous-même cette propriété dans l’entité-type Ventes.

Le débat est donc un peu stérile, sinon que la dimension sémantique doit être respectée lors de la modélisation.

Le vrai problème est qu’une fois logées dans Ventes, les colonne Noter_Note_VenAch (et autres Noter_xxx) et Mbr_CBNum (clé étrangère) vont pouvoir prendre la valeur nulle, facilité qui met en danger une base de données relationnelle, SQL étant défaillant en ce qui concerne la manipulation de la logique à trois états (vrai, faux, inconnu) induite par les valeurs nulles (je vous renvoie aux écrits de C.J. Date, H. Darwen et D. McGoveran).

Personnellement, si vous me prouvez que la cardinalité 0,1 que vous avez définie est pertinente et ne correspond pas à une faiblesse, à une approximation dans la modélisation, je vous recommande alors de provoquer la mise en œuvre d’une table Noter_Acheteur en sorte que les valeurs nulles soient bottées en touche. En plus la dimension sémantique est alors préservée (une table est un prédicat ! elle ne l’est plus dès qu’il y a du "peut-être"...) En plus, la table Ventes ne devient pas obèse du fait des colonnes telles que Noter_Note_VenAch et autres Noter_xxx. Si très peu de notations sont effectuées, votre table Ventes sera polluée d’un nombre inversement proportionnel de valeurs nulles... Accessoirement, le jour où une notation pourra faire l’objet de plus d’une vente, les modifications du système en place seront très minimes. L’inconvénient de mon approche : une table de plus. Et alors ? Encore de l’incantation, de l’émotionnel. Un SGBDR est fait pour qu’on définisse des tables. Il y a de la jointure dans l’air ? Il s’agit de l’opérateur fondamental. A la limite, pour les grincheux, vous définissez une vue donnant l’illusion qu’au lieu de trois tables il n’y en a que deux...

[Soutou]

Bonjour voila lors de la conception de mon MCD j'ai rencontré une difficulté car je ne sais pas si on a le droit de metre une donnée dans une relation de type 0-1 0-n car je n'est vue aucune règle qui l'interdit

Aucune règle ne l'interdit mais cela n'a pas de sens de mettre un attribut dans une association un-à-plusieurs. Chaque attribut que tu as mis dans l'association devrait en fait se trouver soit dans une entité soit dans l'autre. Si un attribut ne peut pas se trouver dans une des 2 entités connectée alors tu t'es trompé sur le type de ton association, et il y a de fortes chances qu'elle soit de type plusieurs-à-plusieurs.
Cela vient de la deuxième forme normale (dépendances fonctionnelles élémentaires).

Bonne année à tous

[fsmrel]

Cela vient de la deuxième forme normale (dépendances fonctionnelles élémentaires).

De quelle 2e forme normale parlez-vous ? Quel est son rôle dans cette affaire ?

En passant, la définition donnée par Codd 1971 est la suivante :

"A relation R is in second form normal if it is in first normal form and every non-prime attribute of R is fully dependant on each candidate key of R."

Définition dans laquelle une relation est en l’occurrence ce que l’on nomme informellement une table en SQL.

On observera que pour prouver de manière formelle qu’une table est en 2e forme normale, il faut commencer par dresser la liste complète des clés candidates, ce qui suppose que l’on a d’abord calculé la fermeture des dépendances fonctionnelles, donc que l’on dispose des 3 premiers axiomes d’Armstrong. Or, le 2e axiome, celui d’augmentation est —j’ai cru comprendre— sans objet en Merise...

Remarque subsidiaire :

Dans le Modèle relationnel, une DF est une contrainte d’unicité entre deux sous-ensembles d’attributs au sein d’une même relation (table).

Le concept de DF en Merise (Cf. "La méthode Merise" Tome 1, de Tardieu, Rochfeld, Coletti) est un faux-ami puisqu’il s’agit d’une contrainte d’unicité entre entités-types. Les auteurs auraient pu laisser à Codd ce qui est à Codd...

[Soutou]

Il y a les chercheurs qui pondent des définitions, et les praticiens qui les utilisent. Je dis que cela vient de la 2eme forme normale car supposons les entités E1 et E2 liées par une association et identifiées respectivement par a et b. Tu mets l'attribut c dans l'association et tu regardes la dépendance fonctionnelle induite : a,b -> c

Si la DF est élémentaire, l'asso est N-N et le schéma en 2eme forme normale.
Si la DF n'est pas élémentaire, tu trouves soit a->c ou b->c et alors, c est dans E1 ou E2. Là l'asso peut être ce qu'elle veut mais c n'y est pas.

En ce moment Je remets à jour
http://www.eyrolles.com/Informatique..._UML_a_SQL.php

qui explique les analogies de la théorie relationnelle avec les modèles conceptuels qu'ils soient sémantique ou objet.

[fsmrel]

Bonsoir,

Je dis que cela vient de la 2eme forme normale car supposons les entités E1 et E2 liées par une association et identifiées respectivement par a et b. Tu mets l'attribut c dans l'association et tu regardes la dépendance fonctionnelle induite : a,b -> c

Pour que Endworld arrive à suivre, je pense qu’il est utile de ne pas mélanger les concepts de Merise avec ceux du Modèle relationnel. Parlons donc de cardinalité maximale 1 au niveau conceptuel et de 2e forme normale au niveau du Modèle relationnel.

Au niveau conceptuel (Merise)

Considérons donc les entités-types E1 et E2, ayant pour identifiants respectifs les propriétés A et B.

Appelons R l’association à laquelle participent E1 et E2.

Supposons que E1 ne participe qu’une fois à l’association R (cardinalité 0,1).

Supposons encore que l’association R soit porteuse d’une propriété C.
Quelqu’un comme Yves Tabourier ne semble pas y voir d’inconvénient ("De l’autre côté de MERISE", Les Éditions d’organisation. 1986, Cf. page 104) et un AGL tel PowerAmc non plus.

Au niveau Modèle relationnel

Utilisons une table pour traduire l’association R. La table R comporte la dépendance fonctionnelle DF1 : {A, B} -> C.

Étant donné qu’au niveau conceptuel E1 ne participe qu’une fois à l’association R, on infère une contrainte d’unicité qui au niveau relationnel se traduit par une dépendance DF2 : A -> C.

Du fait de DF2, C ne dépend que d’une partie de DF1, qui est dite en l’occurrence partielle. A contrario, DF1 n’est pas une DF élémentaire (ou totale).

Pour autant, la table R (A, B, C) dérivée du modèle conceptuel est-elle en 2e forme normale ?

Si tel n’est pas le cas, c’est qu’il existe une DF partielle dont la partie gauche est une clé candidate de R.

Puisque l’on parle de clé candidate et de 2NF, il nous faut donc découvrir l’ensemble des clés candidates de R, ce qui nécessite de faire référence à la définition qui en est donnée dans le Modèle relationnel :

Une clé candidate est un sous-ensemble d’attributs K d’une relation R (informellement table) respectant les deux contraintes suivantes :

— Unicité. Deux tuples distincts de R ne peuvent avoir même valeur de K.

— Irréductibilité (ou minimalité). Il n’existe pas de sous-ensemble strict de K garantissant la règle d’unicité.

(En notant qu’en vertu de la propriété d’unicité, la DF : K -> X est vérifiée pour chaque attribut X de R.)

Posons-nous la question de la candidature du couple K = {A, B}. En vertu de DF1, K vérifie la propriété d’unicité. A son tour, la propriété d’irréductibilité est-elle vérifiée ?

Du fait qu’au niveau conceptuel, E1 ne participe qu’une fois à l’association R, on infère la règle :

Pour une valeur de la propriété A de E1 il y a au plus une valeur de la propriété B de E2.

Cela se traduit au niveau du Modèle relationnel par la dépendance fonctionnelle dans R, DF3 : A -> B.

En conséquence, le couple K = {A, B} est réductible et n’est pas clé candidate pour R .

Par contre, A détermine fonctionnellement chaque attribut de R :

A -> A (DF triviale)
A -> B (cf. DF3)
A -> C (cf. DF2)

Donc l’attribut A est clé candidate.

Au niveau conceptuel, on sait seulement que pour une valeur de B on peut avoir N valeurs de B et de C. Comme il n’existe pas a priori de règle de gestion interdisant l’existence des triplets de valeurs pour {A, C, B} tels que :

<a1, c1, b1>
<a2, c1, b1>
<a3, c2, b1>
<a4, c1, b2>

alors, au niveau relationnel, sans même avoir à en passer par les axiomes d’Armstrong, on infère à partir de ces exemples qu’il n’existe pas de DF telle que

B -> {A, C}, {B, C} -> A, C -> {A, B}.

Ce qui revient à dire que l’attribut A constitue donc la seule clé candidate K de R.

Et comme A est singleton, les DF : A -> B et A -> C sont élémentaires (mon cher Watson) :

R est en 2e forme normale. CQFD.

Conclusion :

D’après la théorie relationnelle, la présence de l’attribut C dans la table R est non seulement légale, mais elle peut être tout à fait légitime (par exemple, quand il y a des problèmes de contention en production et que les mises à jour portent essentiellement sur C, on peut souhaiter que les utilisateurs puissent tranquillement consulter E1).

Qui plus est, si au niveau conceptuel, la cardinalité est 0,1 alors au niveau du Modèle relationnel (qui n’est pas SQL !) migrer les attributs C et B tels quels dans la table E1 est interdit car engendrant un mal qui s’appelle valeur nulle, entraînant comme je l’ai déjà précisé l’utilisation obligée d’une logique à 3 états (vrai, faux, inconnu) avec laquelle SQL se prend les pieds sans le tapis (je vous renvoie aux ouvrages et articles de Date & Darwen à ce sujet). De son côté, PowerAmc procède malheureusement à l’absorption de R par E1, mais il y a des solutions de contournement. Évidemment, pour retrouver une logique binaire, il y a ces cache-misères que sont les valeurs par défaut (mais qui ne résolvent pas tout...)

Remarque subsidiaire concernant le niveau relationnel : que penser d’une DF telle que A -> C au sein de E1, quand C prend la valeur nulle ?

Et maintenant, une histoire vécue que je transpose. La table E1 a donc absorbé les attributs B et C et elle contient 50 millions de lignes. Le nombre de lignes ayant des valeurs non nulles pour B et C est seulement de l’ordre de la centaine. En fait, les attributs B et C ont été phagocytés en même temps qu’une dizaine d’autres, représentant quelque chose comme 200 octets : les valeurs nulles occupent une dizaine de gigaoctets. Aujourd’hui c’est peu de chose, mais quand la table n’est pas seule dans ce cas, ça finit par faire désordre. En l’occurrence, réintégrer B, C et consorts dans la table R est certainement loin d’être idiot.

Pour remonter au niveau conceptuel et répondre à la question initiale, dans le cas d’une cardinalité (0,1) faut-il automatiquement migrer C de R vers E1 ?

Je préfère répondre négativement car que ce qui vaut pour le niveau relationnel est peut-être bon en amont. Plus précisément, le concepteur peut se préoccuper au niveau conceptuel des conséquences en aval de ses choix : Merise ne propose pas d’algèbre et n’est donc pas concernée par les logiques n-valentes dues aux valeurs nulles, mais les développeurs le sont et l'on doit s'en préoccuper.

Pour finir, si au niveau conceptuel, l’association R est porteuse de la propriété C, je répète que sémantiquement cela a un sens, cette propriété étant explicitée par le couple E1, E2, par leur rencontre, et non pas seulement par l’une ou l’autre de ces entités-types. Pourquoi ce qui est vrai sémantiquement pour une cardinalité (0,N) ne le serait pas pour le cas particulier (0,1) ? Par ailleurs, le jour où les règles de gestion évolueront et qu’il faille transformer la cardinalité (0,1) en cardinalité (0,N), le coût de l’opération sera incomparablement moindre au niveau de la base de données, si dès le départ on a mis en œuvre la table R. Maintenant, si l'on me prouve que j'ai tort, je le reconnaîtrai volontiers, mais je lirai attentivement la démonstration...

Tout ceci est le point de vue d’un praticien vigilant, qui n’est absolument pas un théoricien de Merise, mais qui a bien donné et pense avoir compris quels trésors recèle la théorie relationnelle et les conseils précieux qu’elle donne.

Fsmrel