En complément
Citation:
Envoyé par
Kropernic
Ne retenez cependant que la première solution. La 2e et la 4e me semblent caduque quant à la 2e, il faudrait voir ce que l'auteur veut dire par partition...
De fait, quand on utilise l'héritage et qu'on passe du MCD au MLD il ne faut retenir que la 1re solution, voyez ci-dessous les éventuels problèmes que les autres solutions peuvent à l’occasion provoquer, bien inutilement.
Citation:
Envoyé par la FAQ Merise
Ne dupliquer dans les tables sous-type que l'identifiant.
Cette solution ne pose aucun problème de redondance. Elle est celle qui minimise la place. On peut "reconstituer" les héritages par des vues SQL.
Attention à la représentation graphique, car à droite (en vert) figurent manifestement des vues de jointure, permettant d’avoir une vision « objet » des imprimantes et des lecteurs de CD :
http://www.fsmwarden.com/developpez_...ge_MLD_Vue.png
A signaler que si l’attribut Type prend les valeurs "imprimante", "lecteur CD", etc., alors il est redondant et n’a pas lieu d’être, ce que montrent bien les vues. Par ailleurs, dire que la place est minimisée n’est pas le rôle du concepteur : c’est au professionnel des bases de données, le DBA, d’apprécier cela, en fonction du SGBD, des volumétries calculées autrement qu’au pifomètre, et en fonction des résultats du prototypage des performances. A titre indicatif, ayant pour ma part utilisé DB2 depuis la V1, il se trouve que, même pour des tables de plusieurs dizaines de millions de lignes, après moult prototypages serrés, je n’ai jamais eu à remplacer cette solution par une autre.
Citation:
Envoyé par la FAQ Merise
Dupliquer la totalité du surtype dans les sous types
On a certes une redondance à gérer mais l'accès est plus facile car on a l'intégralité des informations d'un périphérique spécifique dans une table.
Cette 2e solution est génératrice de redondances inutiles, elle est à fuir ! C’est ce que dit de façon moins triviale la théorie relationnelle (The Principle of Orthogonal Design). La FAQ Merise a tout bonnement oublié de prendre en compte les mises à jour des tables. Prenons l’exemple de la modification de l’état d’une imprimante : les deux tables PERIPHERIQUE et IMPRIMANTE sont à mettre à jour et dont il faut garantir l’égalité des valeurs prises sur l’attribut redondant, d’où triggers pas simples en perspective... Quant à obtenir la « facilité d’accès » il suffit d’en passer par des vues de jointure. Si l’on veut tout savoir sur l’imprimante 24, on code (en SQL) :
Code:
1
2
3
| SELECT PeriphId, ImprimanteEtat, ImprTypeEncre, ImprNiveauPapier
FROM IMPRIMANTE_V
WHERE PeriphId = 24 ; |
Ou IMPRIMANTE_V est une vue, c'est-à-dire une table virtuelle définie au moyen de l’instruction qui va bien, par exemple :
Code:
1
2
3
| CREATE VIEW IMPRIMANTE_V (PeriphId, ImprimanteEtat, ImprTypeEncre, ImprNiveauPapier) AS
SELECT x.id_periph, état, type_encre, niveau_papier
FROM PERIPHERIQUE AS x JOIN IMPRIMANTE AS y ON x.id_periph = y.id_periph ; |
Et qu’on ne vienne pas m’opposer l’argument éculé, obsolète mais sans cesse ressorti — depuis qu’existent les moteurs relationnels — par certains qui n’ont jamais été DBA, argument selon lequel la jointure engendre des accès supplémentaires au disque, donc qu’elle est un facteur de dégradation de la performance : la jointure est l’opération relationnelle par excellence et un SGBD relationnel digne de ce nom se doit de la faire cartonner. A titre d’exemple, voyez ici, quand les gens de la banque se proposaient naïvement de remplacer une jointure par un accès à une seule table, sans se douter qu’ils ne gagneraient que quelques secondes sur une durée inacceptable de 9 heures, ce que montrait un simple prototypage des performances.
Citation:
Envoyé par la FAQ Merise
Ne conserver que les sous-types après avoir dupliqué le contenu du surtype
Conserve les avantages de la solution 2.2 en supprimant la redondance; mais cela exige que l'héritage est un soit une partition.
Hum... Partons du MCD :
http://www.fsmwarden.com/developpez_...s_four_MCD.png
Le MLD dérivé est le suivant :
http://www.fsmwarden.com/developpez_...s_four_MLD.png
Une incidente à l’attention de Krop : vous savez que des sous-types (ou sous-classes) peuvent être soumis à des contraintes d’exclusion ou de totalité :
Exclusion : une imprimante ne peut pas être un lecteur de CD, un écran, etc. ;
Totalité : il n’y a pas d’autres types de matériel que les imprimantes et les lecteurs de CD les écrans et les disques externes.
Si l’exclusion et la totalité sont vérifiées simultanément, alors il y a partitionnement des sous-types IMPRIMANTE, ECRAN, LECTEUR_CD, DISQUE_EXTERNE (comme en mathématiques, lorsque l’union des sous-ensembles disjoints d’un ensemble E est égal à E). — Fin de l’incidente.
Cette 3e solution n’est pas recommander dans la mesure où les structures ne sont pas figées et peuvent évoluer au fil du temps. Supposons que la base de données soit en production et qu’on ait retenu cette solution. Or voilà qu’un beau jour on veut établir une association entre les périphériques et les fournisseurs (voire encore d’autres entités-types à mettre elles aussi en relation avec PERIPHERIQUE, par exemple COMMANDE ou LIVRAISON, etc.) Le MCD évolue ainsi :
http://www.fsmwarden.com/developpez_...c_four_MCD.png
Tandis que MLD doit subir une maintenance pour devenir le suivant :
http://www.fsmwarden.com/developpez_...c_four_MLD.png
On observera qu’au lieu d’établir une seule contrainte d’intégrité référentielle entre les tables FOURNISSEUR et PERIPHERIQUE, comme cette dernière table n’existe pas, il faudra établir autant de contraintes qu’il y a de tables issues des sous-types : une contrainte ça va, deux contraintes ça va, trois contraintes... (et encore ceci n’est que la partie émergée de l’iceberg : si N est le nombre de sous-types, il y a des travaux en N exemplaires à réaliser : index à créer, déchargements/rechargements des tables, des requêtes en N exemplaires au lieu d’une seule, etc., la production informatique appréciera moyennement, tout comme celui qui tient les cordons de la bourse...)
Par comparaison, le MLD de la solution 1 évolue ainsi :
http://www.fsmwarden.com/developpez_...c_four_MLD.png
Seule la table PERIPHERIQUE est touchée par la prise en compte des fournisseurs.
Citation:
Envoyé par la FAQ Merise
Tout remonter dans le surtype
Solution de facilité, une seule table; mais sûrement un grand nombre de valeurs "à vide"; ça dépend comment la base de données gère ces vides.
Cette solution est une cata, un bug conceptuel, je dirais que c’est la solution « asile de fous... » Si vraiment on veut ne voir qu’une table, il suffit de mettre en œuvre une vue de jointure entre le surtype et des sous-types.
____
Si JPhi33 passe par là...
En complément sur ce qui est écrit dans la FAQ à propos de l’héritage et de la dérivation du MCD et MLD :
J’ai l’impression que quelqu’un a modifié ce qu’a écrit l’auteur de la FAQ, D. Nanci, car on ne reconnaît pas sa patte, il suffit de se référer au remarquable ouvrage de référence qu’on lui doit (coécrit avec Bernard Espinasse) : Ingénierie des systèmes d'information : Merise deuxième génération (3e édition) où l’on peut lire, je cite :
Solution 1 :
On exprime les sous-types par des tables spécifiques, correspondant en fait à des relations (0,1)-(1,1). Il y a ainsi migration de l’identifiant du surtype dans les sous-types.
Solution 2 :
Comme dans la solution précédente, on exprime les sous-types par des tables spécifiques. Il y a duplication des attributs du surtype dans les sous-types associés, dont la mise à jour simultanée peut être réalisée à travers un mécanisme automatique implémentant l’héritage, par exemple par triggers.
Solution 3 :
Dans cette solution, on duplique la totalité du contenu du surtype dans les sous-types associés et on supprime le surtype. Cette solution n’est pas conseillée dans le cas où il existe, dans le modèle conceptuel (entité-relation), des relations portant sur le surtype.
Solution 4 :
On transfère la totalité des propriétés des sous-types dans la table correspondant au surtype. On exprime ensuite les sous-types par des vues relationnelles d’une table globale. Les sous-types sont exprimés par des vues relationnelles de la table [globale] rassemblant l’ensemble des propriétés spécifiques aux sous-types. »
Ce que je viens de citer est quand même d’une autre tenue que ce qu’on lit dans la FAQ où l’on trouve cette horreur (outre les observations sans intérêt sinon trompeuses ayant trait à la jointure ou à la l’économie de place) :
« cela exige que l'héritage est un partition »
Je constate non seulement que la langue française est mise à mal, mais je relève aussi la présence d’un non-sens : l’héritage est une technique ou un processus (cf. le document Journée Afcet, 15 novembre 1990) tandis qu’une partition est représentée par un sous-type d’entité-type. Je ne reconnais donc pas la patte et la rigueur de D. Nanci, très chatouilleux sur toutes ces choses-là : visiblement quelqu’un s’est permis de bricoler son énoncé.
