Envoyé par
Jay13mhsc
d'après ce que disent certaines théories sur la manière de modéliser la même chose en relationnel, l'une des solutions est la suivante :
Document (Id_Doc, Id_Type, Titre, Auteur, Ville)
TypeDocument (Id_Type, Libelle)
La solution (sic) que vous présentez est à rejeter. En effet, elle revient à amalgamer dans la table Document des données qui n’ont rien à voir entre elles, à savoir des auteurs de livres et des villes couvertes par des journaux. C’est le mariage de la carpe et du lapin. Et last but not least, NULL s’invite à la fête.
Au niveau relationnel, il est préférable de voir les choses différemment :
1) Soit vous définissez deux tables :
Table Livre {IdLivre, TitreLivre, Auteur, ...}
Key {IdLivre}
Table Journal {IdJnal, TitreJournal, Ville, ...}
Key {IdJnal}
2) Soit vous préférez rester dans une logique de spécialisation et d’héritage :
Table Document {IdDoc, Titre, ...}
Key {IdDoc}
Table Livre {IdDoc, Auteur, ...}
Key {IdDoc}
Foreign Key {IdDoc} References Document
Table Journal {IdDoc, Ville, ...}
Key {IdDoc}
Foreign Key {IdDoc} References Document
Et vous définissez ensuite deux vues permettant à l’utilisateur de manipuler des entités Livre et Journal :
View Livre2 {Document JOIN Livre}
Key {IdDoc}
View Journal2 {Document JOIN Journal}
Key {IdDoc}
En l’état, c'est-à-dire en l’absence d’autres attributs qui pourraient influer, les tables et vues que je vous propose sont en 5e forme normale.
Envoyé par
Jay13mhsc
En quelle forme normale ma base est-elle ?
La normalisation ne s’applique pas à une base de données, mais aux tables qui en sont les éléments (qu’il s’agisse des tables de base ou des tables dérivées que sont les vues).
Vu sa structure (deux attributs seulement), il est facile de montrer que la table TypeDocument est en 3e forme normale : en effet, les déterminants des seules dépendances fonctionnelles qu'elle comporte sont des surclés. Pour affirmer qu’elle est en 5e forme normale, il suffit d’utiliser un théorème de Fagin et Date, selon lequel lorsqu’une table est en 3NF, si chacune de ses clés candidates ne comporte qu’un seul attribut, alors cette table est en 5NF.
Pour la table Document, la présence systématique de NULL ne simplifie pas la tâche (si l’on à affaire à un livre, la colonne Ville est à NULL et si l’on a affaire à un journal, c’est la colonne Auteur qui est à NULL, conséquence du mariage de M. Lapin et de Mme Carpe).
Dans le cas général, NULL empêche de prouver qu’une table est normalisée en ce sens que certains théorèmes fondamentaux ne fonctionnent plus. C’est le cas par exemple du théorème de Heath, selon lequel si la table T(A, B, C) satisfait à la dépendance fonctionnelle A → B, alors T peut être décomposée sans perte selon ses projections T1(A, B) et T2(A, C). (A, B et C représentent ici des ensembles d’attributs de T). Même conséquence funeste pour un théorème de Fagin qui est une extension du précédent quand on raisonne non plus en termes de dépendances fonctionnelles, mais multivaluées.
J’utiliserai donc des valeurs par défaut à la place de NULL.
Dans ces conditions, en considérant que {IdDoc} et {Titre} sont des clés candidates et en considérant que {Auteur} et {Ville} (ainsi que leurs combinaisons) ne peuvent pas faire l’objet de telles clés, on montre facilement que la table Document est en 3NF, puis on montre qu’elle est en 5NF, toujours à l’aide du théorème de Fagin et Date.
Conclusion :
Les deux tables que vous avez présentées sont en 5e forme normale, mais elles sont bonnes pour la poubelle.
Gestion de l'heritage
Répondre avec citation
Partager