Discussion :

[Nico128]

Hello !

Je suis en train de lire un cours que mon prof nous a passé sur les règles de transformation du MCD en MLD.

Il y a un cas qui me surprend un peu, c'est lorsqu'on a les cardinalité 0,1 - 1,n on créé une table associative :



Est-ce que c'est correcte ? Jusqu'à présent j'ai toujours pensés qu'on créait une table associative lorsqu'on avait un n au 2 cardinalités (0,n - 0,n)

avec les cardinalité 0,1 - 1,n on pourrait pas mettre la clé étrangère du côté du 0,1 ? C'est comme ça que j'aurais toujours fait.

Merci d'avance!

[SmileSoft]

..
Il y a un cas qui me surprend un peu, c'est lorsqu'on a les cardinalité 0,1 - 1,n on créé une table associative :

http://www.fsmwarden.com/developpez/Nico128(Assoc_01_0N).jpg

Est-ce que c'est correcte ? ...

Merci d'avance!

non, ce n'est pas juste.

toute association binaire de type père-fils {(1-n)/(0-n),(1-1)/(0-1)} est caractérisé par l'existence d'une dépendance fonctionnelle entre l'identifiant de l'entité fils et l'identifiant de l'entité père.

[fsmrel]

Bonsoir,

Il y a un cas qui me surprend un peu, c'est lorsqu'on a les cardinalité 0,1 - 1,n on créé une table associative
Merci d'avance!

Voyons la représentation proposée par votre professeur :



Du point de vue du Modèle Relationnel de Données (MRD), votre professeur a raison à 100% de mettre en oeuvre une table associative. Selon ce modèle, NULL est en effet interdit. Passons maintenant au modèle SQL (qui autorise NULL) : si l’on se passait de la table ASSOCIATION, alors on devrait prévoir une clé étrangère (donc un attribut E2_IDENTIFIANT_2) lors de la définition de la table ENTITE_1, afin d’établir le lien avec la table ENTITE_2. Dans ces conditions, pour être en accord avec cardinalité 0,1 du MCD, on serait malheureusement obligé d’autoriser la présence de NULL pour l’attribut E2_IDENTIFIANT_2 de la table ENTITE_1. Je vous recommande de suivre votre professeur. (edit du 14/08/2009, suite à coquille.)

Au-delà de la théorie, disons d’un point de vue pratique, d’autres éléments peuvent militer en faveur de la mise en œuvre de la table ASSOCIATION.
Supposons en effet qu'une certaine entreprise XYZ gère des articles, mais qu’elle n’en fabrique jamais. Dans la réalité des entreprises, il se trouve qu’il y a toujours des exceptions et en l’occurrence XYZ a pu fabriquer quelques articles, répertoriés dans un stock particulier (histoire vécue plus d’une fois).

Remplaçons ENTITE_1 par ARTICLE, ENTITE_2 par STOCK_PARTICULIER et supposons que 500 000 articles soient répertoriés dans la table ARTICLE. Si seulement une cinquantaine d'entre eux sont impliqués dans une relation avec la table STOCK_PARTICULIER, il y aura une diarrhée de nulls dans la table ARTICLE, et cela fait un peu désordre, surtout quand ce genre de situation se répète, c'est-à-dire quand l’entité-type ARTICLE entretient des relations de type 0,1-0,N avec de nombreuses autres entités-types du genre de STOCK_PARTICULIER. Exemple : présence d’une relation de type 0,1-0,N entre ARTICLE et une entité-type ART_TARENTAISE utilisée pour des surcoûts liés au contexte géographique particulier (quelques occurrences encore une fois), etc.

Quand vous scrutez la table ARTICLE, vous ne voyez pratiquement que du blanc à l’écran...

Par ailleurs, toujours dans la réalité des entreprises, à supposer que vous n’utilisiez pas de table associative, NULL vaudra non seulement pour la clé étrangère liant ARTICLE et STOCK_PARTICULIER, mais aussi pour les éventuels attributs qui l’accompagnent (dates, statuts, ...) Un problème de troisième forme normale (3NF) risque bien de se poser.

Descendons dans la soute, mettre du charbon. Du point de vue de la performance, les accès nécessitant la présence d’index vont faire que ces derniers viendront s’agglutiner sur la table ARTICLE, alors qu’il serait infiniment préférable que tous ces index soient dispatchés, chacun sur la table associative qui convient. Mieux vaut un index par table, et outre une meilleure performance, on éliminera des problèmes de contention en mise à jour.

Attention Nico128, dans votre table associative ASSOCIATION, vous avez souligné les attributs #E1_Identifiant_1 et #E2_Identifiant_2 : si c’est pour signifier que cette paire d’attributs constitue la clé de la table, alors cette clé ne peut être constituée que de #E1_Identifiant_1. Ceci est la conséquence de la règle d’irréductibilité (ou minimalité) des clés candidates d’une part, et d’autre part de l’existence de la dépendance fonctionnelle

#E1_Identifiant_1 -> #E2_Identifiant_2.

[JPhi33]

Bonjour à tous,

Au-delà de la théorie, disons d’un point de vue pratique, d’autres éléments peuvent militer en faveur de la mise en œuvre de la table ASSOCIATION.
Supposons en effet qu'une certaine entreprise XYZ gère des articles, mais qu’elle n’en fabrique jamais. Dans la réalité des entreprises, il se trouve qu’il y a toujours des exceptions et en l’occurrence XYZ a pu fabriquer quelques articles, répertoriés dans un stock particulier (histoire vécue plus d’une fois).

Remplaçons ENTITE_1 par ARTICLE, ENTITE_2 par STOCK_PARTICULIER et supposons que 500 000 articles soient répertoriés dans la table ARTICLE. Si seulement une cinquantaine d'entre eux sont impliqués dans une relation avec la table STOCK_PARTICULIER, il y aura une diarrhée de nulls dans la table ARTICLE, et cela fait un peu désordre [...]

Dans l'entreprise XYZ, le concepteur chevronné aura pu flairer l'embrouille et modéliser la situation de la manière suivante :

[ Article ] <=== [ Article_à_stock_particulier ]--1,1----( )----1,n--[ Stock_particulier ]

mettant en évidence une sous-population d'articles fabriqués (une cinquantaine) parmi les 500 000 article répertoriés. La représentation :

[ Article ] <=== [ Article_à_stock_particulier ]

modélise un lien de généralisation-spécialisation. Les articles constituant l'entité spécialisée Article_à_stock_particulier ont toutes les caractéristiques des Articles (entité généralisée) plus la particularité d'être répertoriés dans un Stock_particulier. Cette entité spécialisée n'a pas besoin de propriété (attribut) spécifique, l'association avec l'entité Stock_particulier justifie à elle seule son existence.

La dérivation en MLD produit exactement le même schéma que le MRD représenté, avec la correspondance :

• ENTITE_1 = Article
• ASSOCIATION = Article_à_stock_particulier
• ENTITE_2 = Stock_particulier

Cette modélisation s'impose d'autant plus que la cardinalité 0 de la patte "Entité 1----Association" est la règle (499 950 articles sur 500 000) et donc que la cardinalité 1 est l'exception. Dans le cas inverse, on pourrait (peut-être) conserver le MCD d'origine et accepter la présence de quelques 50 NULL dans la colonne de clé étrangère (bien que je laisse le droit au DBA de me contredire sur ce point )


JPhi33

[fsmrel]

Bonsoir JPhi33,

Cela faisait longtemps que je n'avais pas eu le plaisir de vous lire. Permettez-moi quelques remarques à mon tour.

Dans l'entreprise XYZ, le concepteur chevronné aura pu flairer l'embrouille

Certes, mais la réalisation des MCD n’est pas toujours confiée à des concepteurs chevronnés. Je ne peux malheureusement pas parler des audits que j’ai effectués concernant des bases de données en production, où j’ai eu à attirer l’attention (euphémisme) sur ce point particulier (parmi d’autres de la même farine). Et croyez moi, j’ai vu des tables de l’ordre de 500 millions de lignes, bourrées de nulls, ras la gueule...

Les articles constituant l'entité spécialisée Article_à_stock_particulier ont toutes les caractéristiques des Articles (entité généralisée) plus la particularité d'être répertoriés dans un Stock_particulier. Cette entité spécialisée n'a pas besoin de propriété (attribut) spécifique, l'association avec l'entité Stock_particulier justifie à elle seule son existence.

Une entité-type démunie de propriétés, dont l’identifiant est hérité d’une entité-type généralisée pour laquelle il n’existe pas d’autre entité-type spécialisée ressemble furieusement à une association-type pudiquement voilée... « Cachez ce sein que je ne saurais voir »...

Dans le cas inverse, on pourrait (peut-être) conserver le MCD d'origine et accepter la présence de quelques 50 NULL dans la colonne de clé étrangère (bien que je laisse le droit au DBA de me contredire sur ce point )

Tous les fans du Sorry Query Language abonderont dans ce sens, mais le Modèle SQL n’est pas le Modèle relationnel de Données. La théorie relationnelle serait mise en échec si l’on y acceptait le Bonhomme NULL, lequel est accessoirement un inhibiteur pour l’optimiseur d’un SGBDR, car les lois de transformation utilisées pour rendre les requêtes plus performantes sont mises en échec (une équivalence telle que r JOIN r ≡ r qui est au cœur de ces lois ne vaut plus ; A = B et B= C n’implique plus que A = C, etc.) Vous comprendrez que je respecte scrupuleusement la théorie relationnelle...

Dans le cadre de la normalisation, prenons par exemple le cas du théorème de Heath (1971) dont l’énoncé est le suivant :

Soit la relation R {X, Y, Z} dans laquelle X, Y et Z sont des ensembles d’attributs de R. Si R satisfait à la dépendance fonctionnelle X → Y, alors R est égale à la jointure de ses projections sur {X, Y} et {X, Z}.

C’est le théorème qui prouve qu’une relation (au sens du Modèle relationnel) qui ne respecte pas la deuxième forme normale, la troisième forme normale ou la forme normale de Boyce-Codd, peut être décomposée sans perte. Mais si les attributs de R acceptent NULL, alors le théorème ne vaut plus : c’est pour le moins gênant...
Personne ne connaît Heath, mais sans le savoir, tous ceux qui normalisent utilisent son théorème, tout comme M. Jourdain disait de la prose...

fsmrel

[JPhi33]

La théorie relationnelle serait mise en échec si l’on y acceptait le Bonhomme NULL, lequel est accessoirement un inhibiteur pour l’optimiseur d’un SGBDR, car les lois de transformation utilisées pour rendre les requêtes plus performantes sont mises en échec (une équivalence telle que r JOIN r ≡ r qui est au cœur de ces lois ne vaut plus ; A = B et B= C n’implique plus que A = C, etc.)

Je subodorais cette conclusion.
Merci pour votre éclairage.

[wafiwafi]

fsmrel a dit

Du point de vue du Modèle Relationnel de Données (MRD), votre professeur a raison à 100% de mettre en œuvre une table associative. Selon ce modèle, NULL est en effet interdit ; Or, la mise en œuvre d’une clé étrangère pour traduire une cardinalité 0,1 ne pourra jamais empêcher la présence de NULL dans la table ASSOCIATION.

Il y a un truc que je ne comprends pas. Prière d'éclairer mes lanternes.
Dans la table d'association, je n'écris que si une relation est; je peux donc éviter les NULL alors que dans la citation on en fait référence.

Sinon, très enrichissante comme discussion même si des fois, il faut décoder. En tout cas, un grand Merci à vous.

[fsmrel]

Bonjour wafiwafi œil-de-lynx,



Votre remarque est tout à fait pertinente, car une coquille s’est glissée dans ce que j’ai écrit. En effet, il faut lire :

« Du point de vue du Modèle Relationnel de Données (MRD), votre professeur a raison à 100% de mettre en oeuvre une table associative. Selon ce modèle, NULL est en effet interdit ; Or, la mise en œuvre d’une clé étrangère pour traduire une cardinalité 0,1 ne pourra jamais empêcher la présence de NULL dans la table ENTITE_1. »

Pour éviter que d’autres se posent des questions à leur tour, je remplace ce paragraphe par le suivant dans le message en cause :

« Du point de vue du Modèle Relationnel de Données (MRD), votre professeur a raison à 100% de mettre en oeuvre une table associative. Selon ce modèle, NULL est en effet interdit. Passons maintenant au modèle SQL (qui autorise NULL) : si l’on se passait de la table ASSOCIATION, alors on devrait prévoir une clé étrangère (donc un attribut E2_IDENTIFIANT_2) lors de la définition de la table ENTITE_1, afin d’établir le lien avec la table ENTITE_2. Dans ces conditions, pour être en accord avec cardinalité 0,1 du MCD, on serait malheureusement obligé d’autoriser la présence de NULL pour l’attribut E2_IDENTIFIANT_2 de la table ENTITE_1. Je vous recommande de suivre votre professeur. »

Je suis désolé pour les questions que vous avez pu vous poser suite à cette fâcheuse coquille...

[wafiwafi]

Entièrement d'accord fsmrel.
Bien à toi