Envoyé par
SQLpro
La normalisation s’applique donc aux vues.
Non, non et non... je ne peut pas passer cela...
Vous ne m’avez pas compris. Je reprends donc les choses un peu différemment.
Tout d'abord, à moins d'être en total désaccord avec Ted Codd et Chris Date, auquel cas on en restera là — on sortirait en effet du cadre du Modèle relationnel de données —, on doit convenir qu'une vue est bien une table. Je cite Date à nouveau (Cf. "Date on Database - Writings 2000-2006", page 440) :
Une vue est une table... Et n’importe quel motif avancé selon lequel les vues sont différentes des "tables", trahit une profonde méconnaissance du modèle relationnel. Malheureusement, cette méconnaissance est trop largement répandue (elle foisonne par exemple dans la norme SQL).
Je cite aussi Ted Codd ("The Relational Model for Database Management - Version 2" page 18) : Une vue est une R-table virtuelle, définie en termes d'autres R-tables, et représentée seulement par l'expression qui la définit.
Qui plus est, une vue représente un opérande pour chaque opérateur relationnel, au même titre que n'importe quelle table.
Je poursuis à mon tour, en restant dans le cadre du Modèle relationnel : considérons les deux types non scalaires suivants : table de base et table dérivée (ou vue). Toujours d'un point de vue relationnel, on peut considérer ces deux types comme étant en fait des sous-types d’un type plus général appelé table (terme qu'il faudrait remplacer selon le contexte par ceux de variable relationnelle (relvar) et relation, mais peu importe ici).
Supposons maintenant — en utilisant le langage Tutorial D — que l’on définisse deux tables, disons de base :
VAR Fournisseur BASE RELATION {FourId, FourNom}
KEY {FourId} ;
VAR Commande BASE RELATION {NoCde, FourId, DateCde}
KEY {NoCde}
FOREIGN KEY {FourId} References Fournisseur ;
Par définition, et en vertu de la propriété de fermeture, on sait que par jointure naturelle des deux tables on obtient une table dérivée T qui a pour schéma :
T {NoCde, FourId, DateCde, FourNom}
Cette table (dans laquelle {NoCde} est clé candidate) enfreint la 3NF parce que, le déterminant FourId de la DF {FourId} → {FourNom} n’est pas clé candidate.
Considérons maintenant l’instruction :
VAR FourCom VIEW Commande JOIN Fournisseur ;
Nous définissons ainsi une table dérivée FourCom ayant pour en-tête :
FourCom (NoCde, FourId, DateCde, FourNom)
et pour clé {NoCde}, et dans laquelle traîne évidemment la DF {FourId} → {FourNom}, faisant que FourCom enfreint elle aussi la 3NF.
Ça n’est pas pour autant qu’il faille se sentir coupable et s’interdire de créer des vues de ce type !
Je répète une fois de plus que la théorie relationnelle n’impose pas mais encourage seulement à ce qu'on respecte la 2NF et ses suivantes. En l’occurrence, il n’y a pas péril en la demeure à les enfreindre, puisque même si l’on effectue l’insert d’une ligne dans la table dérivée FourCom, un système conforme à la théorie relationnelle sait parfaitement mettre à jour les tables de base Fournisseur et Commande.
Envoyé par
SQLpro
De plus vous confirmez que pour la vue :
Toujours dans le cadre de la théorie relationnelle, ceci est la conséquence de ce qui précède.
Envoyé par
SQLpro
Ce qui est contraire au règles d'établissement d'un modèle conceptuel de données puisque chaque information ne doit jamais figurer qu'une seule fois dans le modèle
Il y a erreur de casting. Nous nous situons dans le cadre de la théorie relationnelle mais pas dans celui de l’approche entité-relation. Mais puisque vous y tenez... Je présume que lorsque vous utilisez le mot "information", il faut le traduire par "propriété" dans le contexte d’un MCD en Merise. Que Merise énonce — je cite la documentation officielle, validée par le ministère de l’industrie (Centre technique informatique. "Méthode de définition d’un système d’informations, fascicule 4, Guide pratique pour l’élaboration des modèles de données et de traitements". Juin 1979) :
Une propriété ne peut qualifier qu’un seul objet ou une seule relation
Ça reste du Merise, méthode dont l'utilité n'est plus à démontrer, mais qui ne propose pas d’algèbre, ce qui change bien des choses.
Considérez par exemple l’opérateur JOIN, utilisé pour la jointure naturelle :
a JOIN b
a et b étant des relations ayant n attributs en commun (même nom, même type). Si l’on suivait Merise à la lettre, n devrait être égal à 0 et la jointure naturelle dégénèrerait alors en produit cartésien (lequel peut du reste être perçu comme n’en étant qu’un cas particulier).
De la même façon, il faudrait évacuer de la norme la version SQL de la jointure naturelle :Table1 NATURAL JOIN Table2
Toujours dans le même sens, aucune clé étrangère ne pourrait plus porter le même nom que la clé de la table de référence, etc.
Bref, si Merise a ses lois concernant la construction des MCD, nous n'avons pas à les imposer à la théorie relationnelle : pas de mélange SVP.
Envoyé par
SQLpro
J'avoue cependant qu'une certains confusion règne sur le concept de vue.... Il y a, au nom de la théorie, le schéma externe qui correspond à un assemblage de vues et de table destinées aux utilisateurs finaux...
Pour ma part, je ne sors pas du Relationland. Que l’ANSI/SPARC traite le sujet à sa façon, cela ne concerne absolument pas la théorie relationnelle, avec laquelle il n’y a aucune confusion possible quant au concept de vue. Qu’ensuite on mette des vues à la disposition de l’utilisateur Tartempion, si celles-ci sont conformes à la théorie relationnelle, il n'y a aucun problème, puisque, à l'instar de Monsieur Jourdain faisant de la prose, Tartempion utilise en fait des tables au sens générique évoqué plus haut et que nous maîtrisons parfaitement le sujet. Pour l'anecdote, j'avais en revanche essayé en son temps d'utiliser le mécanisme des vues d'IDMS, lorsque celui-ci s'était vu affubler du suffixe /R par les gens du marketing : je n'ai jamais vraiment compris le film et vite lâché prise (quant à Codd, il avait attribué un zéro pointé à IDMS/R au sujet des fameuses 12 règles...)
Envoyé par
SQLpro
Ceci étant totalement contradictoire, il est normal de penser que les vues ont été faites pour introduire sciemment une redondance calculée et donc échapper à la normalisation.
Je ne sais pas ce que vous considérez précisément comme étant contradictoire avec quoi.
En tout état de cause, rappeler que les vues sont faites pour simplifier la vie des utilisateurs en général et des développeurs en particulier, en encapsulant la complexité, comme vous l’avez judicieusement illustré avec la vue réalisée à partir de la table T_TARIF_TRF, rappeler que les vues sont utilisées pour cacher certaines données, qu’elles permettent de normaliser la présentation du catalogue relationnel (comme vous l'avez signalé à propos du schéma INFORMATION_SCHEMA), qu’elles servent pour assurer l’indépendance logique, j’en passe en des meilleures, voilà un bon argumentaire pour justifier l'utilisation des vues. Mais avancer comme argument qu’il s’agit au départ "d’échapper à la normalisation" (2NF et au-delà ajouterai-je), voilà qui relève d'une démarche surprenante et non conforme à l'esprit du Modèle relationnel de données. Il s'agit d'un sophisme, car ce modèle n’impose le respect que de la 1re forme normale et elle seule, selon laquelle :
Vu du SGBD, les valeurs des domaines sur lesquels chaque relation est définie doivent être atomiques.
Et à cela on ne peut échapper. A cette occasion, je redis encore que cette définition de la 1NF, due à Ted Codd, impliquée directement ou indirectement par les définitions des formes normales suivantes, n’a bien entendu strictement rien à voir avec, par exemple, la définition fausse et absconse à la sauce DB2 (Cf. DB2 Version 9.1 for z/OS, Administration Guide, "Entity normalization" (sic) que je traduis) :
Une entité relationnelle satisfait à la contrainte de première forme normale si chaque instance d’entité contient une seule valeur, jamais d’attributs qui se répètent. Les attributs répétitifs, souvent appelés groupes répétitifs, sont des attributs distincts, mais il s’agit fondamentalement du même. Dans une entité conforme à la première forme normale, chaque attribut est indépendant et unique quant à sa signification et à son nom.
Je note au passage que, à supposer qu'elle viole la 1NF de Codd, si une table (ce que le rédacteur nomme "entité relationnelle") respecte la 1NF fausse et absconse, elle peut indûment et en toute impunité subir allègrement l’épreuve de la 2NF et suivantes : "Une table est en 2NF si elle est en 1NF et si, etc."), mais ce genre de bug logique nous entraîne vers des terrae incognitae fort éloignées du Relationland. Au contraire, si une table respecte la 1NF de Codd et enfreint la 1NF fausse et absconse, on lui interdit de subir l'épreuve de la 2NF : au lieu de dériver, cette fois-ci on marche sur la tête.
Comme je vous l'ai déjà dit, je vous accorde qu'il faut faire attention à ce qu’un ensemble de colonnes d’une table de base ne puisse constituer une liste, mais ceci relève du savoir-faire dans la conception des MCD et MLD et ne concerne en rien le Modèle relationnel de données.
Partager