SQL Server 2008 : les nouveautés . . .

[SQLpro]

Sauf que de manière générale les "tables" systèmes sont rarement des tables, mais plutôt des vues, et généralement des vues qui ne sont pas toujours bâties sur des tables (mais sur des données hétérogènes).
En tout cas en matière de vues, je préconise la remise à plat. Donc cette vue me parait parfaite !

A +

[fsmrel]

Bonsoir SQLpro,


Je suis navré, mais il y a quelque chose que je trouve paradoxal dans ce que vous dites.

D’une part, vous estimez qu’une table comportant une liste d’attributs n’est pas en première forme normale (ce qui est faux si l’on se réfère à la théorie relationnelle). Peu importe, au-delà de la 1NF, vous avez raison de dire que la structure d’une table comportant une liste de colonnes est à revoir. En effet, cette liste est figée et en plus, je vous cite :

nous connaissons les problèmes que cela pose en général d'un point de vue requête comme au sujet des performances.

Mais d’autre part, vous considérez la table Sysindexes aux 16 colonnes à laquelle j’ai fait allusion (et dans la documentation il y a bien écrit "table") comme une vue et vous la jugez en conséquence comme parfaite : bizarre, car cette mutation ne change rien aux problèmes que vous avez soulevés.

Pour sa part, le catalogue de DB2 for z/OS est constitué de tables de base (y-compris une Sysindexes), hébergées dans des tablespaces bien concrets, elles sont bardées d’index bien concrets eux aussi, et je ne vois pas en quoi considérer ces tables comme des vues les rendraient "parfaites", pour reprendre l’adjectif que vous utilisez.

Que tel ou tel SGBD fournisse une Sysindexes sous forme de vue parce que sous le capot on ne sait pas ce qu’il y a, ça ne me dérange pas, mais il ne faut pas inférer le général à partir de cas particuliers.

Quant à la phrase suivante : "En tout cas en matière de vues, je préconise la remise à plat", merci à vous de nous en fournir la clé de lecture, car en l’état elle n’a strictement aucun sens.

[SQLpro]

Mais d’autre part, vous considérez la table Sysindexes aux 16 colonnes à laquelle j’ai fait allusion (et dans la documentation il y a bien écrit "table") comme une vue et vous la jugez en conséquence comme parfaite : bizarre, car cette mutation ne change rien aux problèmes que vous avez soulevés.

Selon les règles de l'art le catalogue de méta données devrait être constitué de vue et non de tables. C'est en particulier ce qu'affirme la norme SQL depuis l'origine (schéma INFORMATION_SCHEMA). Ceci étant donné la nécessité de portabilité. Cela est d'ailleurs réalisé dans une majorité de SGBDR.

Quant à la phrase suivante : "En tout cas en matière de vues, je préconise la remise à plat", merci à vous de nous en fournir la clé de lecture, car en l’état elle n’a strictement aucun sens.

Très simplement : les formes normales ne s'applique pas aux vues et heureusement. Les vues permettent de simplifier le monde relationnel afin de le rendre plus palpable et plus facile à manipuler.
Lorsque je parle de remise à plat, cela signifie la mise en relation de l'ensemble des tables décrivant un même objet, par des relations naturelles.

Exemples :
Soit la table T_TARIF_TRF (TRF_DATE, TRF_PRIX) avec les données suivantes :

Code :

1
2
3
4
5
6
TRF_DATE     TRF_PRIX
----------   ----------
21/12/1988   125,00
16/03/1992   134,25
02/05/1997   145,21
12/11/2000   189,21

Trouver le bon prix à appliquer au 13 janvier 1994 n'est pas lisible. En revanche présenté de cette façon :

Code :

1
2
3
4
5
6
TRF_DEBUT    TRF_FIN      TRF_PRIX
----------   ----------   --------
21/12/1988   15/03/1992   125,00
16/03/1992   01/05/1997   134,25
02/05/1997   11/11/2000   145,21
12/11/2000   NULL         189,21

La recherche devient triviale !
La vue permet cela mais introduit une forme de redondance. La lisibilité est assuré et les requêtes facilitées.

De la même manière lorsque l'on veut obtenir TELEPHONE_1, TELEPHONE_2, TELEPHONE_3, rien n'empêche le développeur de créer une vue reproduisant cette approche et conserver un modèle fortement normalisé. Au final on
obtient le meilleur des deux mondes...

A +

[fsmrel]

Envoyé par SQLpro

Selon les règles de l'art le catalogue de méta données devrait être constitué de vue et non de tables. C'est en particulier ce qu'affirme la norme SQL depuis l'origine (schéma INFORMATION_SCHEMA). Ceci étant donné la nécessité de portabilité

Je suppose que par portabilité, vous sous-entendez qu’une application Tartempion à vocation générale, de type progiciel puisse fonctionner sur le SGBD X et sur le SGBD Y avec un strict minimum d’aménagements. Si tel est le cas, en édictant les règles de structuration de vues telles que INFORMATION_SCHEMA.TABLES et suivantes, la norme a fait œuvre utile.

Cela dit, bien que le catalogue de DB2 for z/OS ne fournisse pas ces vues (et qu'il soit par ailleurs constitué de tables), il n’en demeure pas moins qu’un DBA doit savoir les créer rapidement et sans difficulté, tout du moins pour les plus fondamentales : types, tables, colonnes, vues, contraintes (clés primaires et étrangères, contraintes de colonnes...). En effet, un DBA DB2 est rompu à ce genre d’exercice, car une des premières choses qu’il entreprend lors de l’installation d'un nouvel environnement, est la création des vues sur le catalogue dont les utilisateurs ont besoin, en restreignant bien entendu ceux-ci à ne voir que ce qui leur appartient. Le DBA DB2 connaît pratiquement par cœur la plupart des tables du catalogue (une soixantaine).

Pour en revenir à la portabilité de l’application, au nom du principe de l’indépendance physique, je suppose que la norme SQL n’est pas concernée par ce qui se passe sous le capot mais qui représente la partie la moins triviale du travail, à savoir le choix de l’organisation des espaces physiques, des index, des plans d’application et packages, la préparation de l’exploitation ses données statistiques du catalogue, etc.

Envoyé par SQLpro

les formes normales ne s'applique pas aux vues.

Au nom du principe d’interchangeabilité, du point de vue du l’utilisateur, une table ou une vue c’est bonnet blanc et blanc bonnet, tant pour Codd que pour Date (C.J. Date, The Relational Database Dictionary) :

«The principle that there should be no arbitrary and unnecessary distinctions between base and virtual relvars : i.e., virtual relvars should "look and feel" just like base ones as far as users are concerned.»

La normalisation s’applique donc aux vues. Et n’oublions pas que la théorie relationnelle n’impose pas mais encourage seulement à respecter la 2NF et ses suivantes.

Envoyé par SQLpro

La vue permet cela mais introduit une forme de redondance.

On est bien d’accord. La redondance est licite, mais au nom du principe de fermeture, ce que demande la théorie relationnelle est qu’une table ne soit pas un sac (qu’il s’agisse d’une table de base ou d’une vue), donc en l’occurrence qu’il n’y ait pas de tuples en double, ce qui se règle par la présence d’une clé candidate (disons primaire) pour une table (ou vue) définie par l’instruction VAR (en Tutorial D tout du moins), ou par inférence de la part du système.

Exemple : Si T_TARIF_TRF n’est pas un sac mais une table, alors elle est dotée d’une clé candidate, laquelle est préservée dans la vue associée (du moins selon la théorie relationnelle).
Même chose pour les téléphones, un système est à même d’inférer la clé de la vue. A noter que la mise en place d’une liste de colonnes pour les téléphones n’entraîne pas de viol de 1NF.

[SQLpro]

La normalisation s’applique donc aux vues.

Non, non et non... je ne peut pas passer cela...
De plus vous confirmez que pour la vue :

La redondance est licite

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, ce qui à l'évidence n'est pas le sens à donner aux vues !

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.....
Ce que d'ailleurs vous confirmez :

du point de vue du l’utilisateur, une table ou une vue c’est bonnet blanc et blanc bonnet

Et il y a les vues SQL.

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.

D'ailleurs les SGBDR sont plus permissifs encore puisque certains acceptent de créer des colonnes calculées (persistante ou non) qui constituent en fait des ersatz de vue incorporées à des tables !

A +

[fsmrel]

Envoyé par SQLpro

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.

[SQLpro]

Vous partez d'un postulat faux au départ qui est qu'une table est une relation. Ceci est faux....
Certes nous somme d'accord pour dire qu'une vue n'est en fait qu'un type de table (et la norme SQL les considère ainsi à juste titre puisque les vues sont recensées dans la vue INFORMATION_SCHEMA.TABLES)...

Néanmoins une table n'a rien à voir avec une relation (au sens algébrique du terme) et s'accrocher à tout prix à la notion de relation n'a pas de sens. Le fait que Codd admet le NULL pour les tables et l'interdit dans l'algèbre relationnel nous montre que la différence est en fait très importante.

Or dans vos débats vous tentez d'imposer une vision trop proche de l'algèbre relationnel, qui n'est en fait qu'un support (et non la vérité) des tables d'un SGBDR.

En fait, c'est toute la différence entre la théorie et la pratique, et c'est un vieux débat, initié par Codd lui même (exemple la 6e forme normal : toute table se représente par un ensemble de colonne formant la clef assortie d'au plus une unique colonne non clef), puis repris par Chris Date, Pascal Fabian, Hugh Darwen (pour le côté pro relationnel) ou Joe Celko, Peter Chen et bien d'autres (pour le côté SQL / SGBDR)...

A +

[fsmrel]

Envoyé par SQLpro

Vous partez d'un postulat faux au départ qui est qu'une table est une relation. Ceci est faux....

Jamais je ne "postulerai" une chose pareille ! Qu’une table soit une relation est évidemment faux, il n’y a pas d’équivalence à établir entre ces deux concepts, bien au contraire, ne serait-ce que, parce que contrairement à une relation, une table n’a pas nécessairement de clé (primaire au sens SQL), parce qu’elle peut comporter des doublons, parce que le résultat d’un SELECT peut avoir des colonnes non nommées ou ayant des noms en double, etc. Je dis simplement que le pendant d’une table au sens SQL, peut être soit une relvar (variable relationnelle) soit une relation (valeur) au sens du Modèle Relationnel de Données, mais ça n’est pas pour autant qu’une table serait une relvar ou une relation.

Tout au plus, une table peut-elle être perçue comme l’avatar d’une relation (ou d’une relvar), elle en est une image, elle en a le goût mais ça n’en est pas, etc. Évitons soigneusement tout amalgame.

Envoyé par SQLpro

une table n'a rien à voir avec une relation (au sens algébrique du terme)

Comme on vient de le voir, une table ressemble tout au plus à une relation. Quant à l’algèbre relationnelle, elle utilise les opérateurs RESTRICT, PROJECT, JOIN, RENAME, EXTEND, etc., dont les opérandes sont exclusivement des relvars (de base ou dérivées) : en vertu de la propriété de fermeture, les opérations relationnelles produisent de nouvelles relvars dont les valeurs (relations) peuvent à leur tour être utilisées à volonté pour de nouvelles opérations. Pour sa part, SQL permet d’utiliser plus ou moins nommément et laborieusement ces opérateurs appliqués cette fois-ci à des tables, mais sans garantie que les résultats soient eux-mêmes des tables : ça peut être des sacs, ou encore des choses qui ne peuvent pas être dotées de clés primaires à cause du bonhomme NULL, etc., cf. le paragraphe précédent) et le principe de fermeture peut être facilement mis en échec. Comme vous dites, au sens algébrique, une relation et une table ne sont pas comparables, ne serait-ce qu’en raison des faiblesses inhérentes à cette dernière (Mais nom d’une pipe, pourquoi IBM n’a-t-elle pas confié la direction du projet SEQUEL à Codd ?)

Envoyé par SQLpro

s'accrocher à tout prix à la notion de relation n'a pas de sens

Plaît-il ? Quand on veut travailler le sujet des bases de données relationnelles avec une grande rigueur, on ne peut que faire référence au Modèle Relationnel de Données, comme l’ont fait Codd, Date, Darwen et McGoveran, Fagin, Rissanen, Maier, Delobel et Adiba, Ullman, Valduriez et compagnie. Je suis navré, mais la relation est au coeur de ce modèle. Ni vous ni moi n’y pouvons rien, il en est ainsi depuis 1969 et les gens que j’ai cités sont des êtres sensés. Bien sûr, le Modèle relationnel a régulièrement évolué et continuera à le faire (heureusement, il n’est pas figé), mais en raison de ce qui différencie une relation d’une table, c’est "s’accrocher" à tout prix à l’avatar de la relation qui serait dénué de sens. Au fait, quel est l’objet de votre remarque ? Que reprochez-vous aux relations, c'est-à-dire au Modèle Relationnel de Données ? Qu’elles soient fidèles au principe de fermeture ? Qu’elles soient toujours identifiées ? Qu’elles ne puissent pas donner lieu à des sacs ? Que leur en-tête soit systématiquement un ensemble d’attributs et toujours formé de façon régulière ? Que le Modèle relationnel ne soit pas laxiste ? Que seul le Sorry Query Language et ses tables seraient sensés et dignes d’intérêt ? Quelque chose m’échappe. J’ai l’impression d’assister à une inversion des valeurs.

Envoyé par SQL pro

Le fait que Codd admet le NULL pour les tables et l'interdit dans l'algèbre relationnel nous montre que la différence est en fait très importante

Tout ceci est nul (sic) et non avenu. En effet, Codd n’a absolument rien interdit de tel ! Je vous renvoie au paragraphe 2.3 de son article de 1979 : Extending the Database Relational Model to Capture More Meaning, dans lequel il étend en réalité l’algèbre relationnelle pour prendre en compte NULL (à noter que dans son ouvrage de 1990 il abandonne NULL au bénéfice des marques A-mark et I-mark). Maintenant, chacun peut avoir ses raisons d’être d’accord ou non avec Codd quant à la façon de traiter l’information absente, mais c’est un autre débat.

Envoyé par SQLpro

Or dans vos débats vous tentez d'imposer une vision trop proche de l'algèbre relationnel, qui n'est en fait qu'un support (et non la vérité) des tables d'un SGBDR.

Vous semblez avoir une bien piètre opinion de l’algèbre relationnelle, sans laquelle SQL ne serait pourtant qu’un sac vide. Qui plus est, ne limitons pas notre vision à l’algèbre relationnelle, il faut considérer le Modèle Relationnel de Données dans sa totalité, c'est-à-dire prendre aussi en compte ses aspects qui touchent à la structure des données et à leur intégrité ; tout cela se tient et se complète. A défaut, nous ne ferions que dans le bricolage et la recette de cuisine, mais là je dis : stop !
Je ne veux pas non plus mélanger modèle (c'est-à-dire le Modèle Relationnel de Données) et implémentation (c'est-à-dire les SGBD dits relationnels). Et puis, si je ne faisais pas référence ici à la matrice relationnelle, qui donc le ferait ? Je ne cherche pas à imposer quoi que ce soit, mais à montrer aux plus jeunes l'intérêt, la nécessité qu'il y a à connaître un minimum de théorie autrement que d’un point de vue strictement scolaire et sec. Libre à eux ensuite de se désintéresser des aspects théoriques.
Quant à prétendre que l’algèbre relationnelle n’est qu’un support, voulez-vous dire qu'elle ne serait qu'un faire-valoir, un impedimentum qu'il faudrait supporter bon gré mal gré ? Qu’elle peut être remplacée par autre chose ? Mais dans ce cas, il faudra supprimer la lettre R du terme SGBDR. Quant à votre énoncé "l’algèbre relationnelle n’est pas la vérité des tables", qu’entendez-vous par là ? L’algèbre relationnelle serait-elle coupable de faire mentir les tables ? J’avoue rester perplexe face à cette affirmation pour le moins bizarre.

Envoyé par SQLpro

En fait, c'est toute la différence entre la théorie et la pratique, et c'est un vieux débat, initié par Codd lui même (exemple la 6e forme normal : toute table se représente par un ensemble de colonne formant la clef assortie d'au plus une unique colonne non clef), puis repris par Chris Date, Pascal Fabian, Hugh Darwen (pour le côté pro relationnel) ou Joe Celko, Peter Chen et bien d'autres (pour le côté SQL / SGBDR)

Décidemment, il est bien difficile de suivre votre discours. Codd a initié (entre autres) Date et Boyce au Modèle Relationnel de Données, et qu’il ait entamé un "vieux débat", c’est possible, mais alors merci d’en fournir la référence, que l’on puisse savoir de quoi vous voulez parler. S’il s’agit du fameux débat de mai 1974 à Ann Arbor "Interactive support for non-programmers: The relational and network approaches", celui-ci illustre magistralement le fait que l’absence de la théorie est particulièrement préjudiciable à l’art de traiter les données. A cette occasion, face à Codd, Bachman (récipiendaire de la Turing Award l’année précédente) a fini K.O. debout, au 1er round.

Et voilà que maintenant vous attribuez à Codd une 6e forme normale. Décidemment... Quoi qu’il en soit, quelque chose ne va pas dans la définition que vous donnez. Je la reproduis donc (tout en conservant le terme "table", ça n’est pas un problème) :

Toute table se représente par un ensemble de colonne formant la clef assortie d'au plus une unique colonne non clef

1) Considérons en ce sens une table T1 dont l’en-tête est composé de trois attributs A, B et C et dont la clé est composée du couple {A, B} :

T1 {A, B, C}

Supposons que la couverture minimale des dépendances fonctionnelles de T1 soit représentée par l’ensemble de dépendances fonctionnelles suivant :

DF1 : {A, B} → {C}
DF2 : {C} → {B}

Du fait de DF2, T1 viole la BCNF, donc la 6NF, ce qui invalide votre définition.

2) Considérons le cas d’une table T2 dont tous les attributs font partie de la clé :

T2 {A, B, C}

Cette fois-ci, toutes les dépendances fonctionnelles sont triviales, en vertu de quoi T2 respecte la BCNF. Supposons maintenant qu’il existe la dépendance multivaluée :

DM1 : {A} →→ {B} | {C}

Alors T2 viole la 4NF, ce qui invalide à nouveau votre définition.

3) Et si l’on suppose que DM1 n’existe pas et que T2 respecte la 4NF, mais qu’en revanche il existe la dépendance de jointure :

DJ1 : * {{A, B}, {B, C}, {C, A}}

Alors cette dépendance de jointure n’est pas triviale et T2 viole la 5NF.

Ainsi, on voit bien qu'on ne peut pas faire l'économie de la théorie qui, en plus de permettre de faire avancer les choses, sert aussi de garde-fou. Faire du trapèze volant c'est chouette, mais sans filet ça craint.

Bien qu’elle ne soit pas valide, votre définition est toutefois intéressante dans la mesure où elle est facile à comprendre, donc à retenir, tout comme l’énoncé proposé par Kent, synthétisant fort élégamment la 2NF et 3NF (pour une table respectant bien entendu la 1NF) :

Un attribut non clé doit représenter un fait concernant la clé, toute la clé et rien que la clé.

Mais il est évident que, si cette définition vaut elle aussi par son côté didactique, elle n’en demeure pas moins incomplète et il est facile à son tour de l’invalider.

Pour faire fonctionner correctement votre définition, il faudrait donc préciser que la table respecte d’abord la 5NF.
A l'instar de Date, vous pourriez aussi la reformuler ainsi, à la façon de la 5NF :

Une table est en 6NF si et seulement si elle ne satisfait à aucune dépendance de jointure non triviale.

Et pour ne pas effrayer les gens avec des gros mots du genre "5NF", "dépendance de jointure", vous pourriez écrire par exemple :

Si une table comporte une clé simple et au plus un attribut non clé, alors cette table est en 6NF (par clé simple, j’entends clé mono-attribut).

Ça n’est jamais qu’un prolongement d’une des définitions de la 5NF, fournie par Fagin et Date pour un cas particulier :

Si une table est en 3NF et si chacune de ses clés candidates est simple, alors cette table est en 5NF.

Évidemment, ces définitions sont très spécifiques car elles ne prennent pas en compte les tables dont une clé est composée de plus d'un attribut, mais c’est toujours ça de pris comme disait ma grand-mère.

Puisque vous parlez de la 6NF et pour essayer d'en terminer, commentons la définition qu’en donne Chris Date dans son ouvrage "An Introduction to Database Systems" (et déjà proposée ci-dessus) :

Une relvar est en 6e forme normale (6NF) si et seulement si elle ne satisfait à aucune dépendance de jointure non triviale — sachant qu’une dépendance de jointure est triviale si et seulement si au moins une de ses projections (éventuellement U_projections) met en jeu l’ensemble des attributs de la relvar.

Pour être un peu plus précis, les dépendances de jointure dont il est question sont en fait des dépendances de jointure généralisées et ainsi définies :

Soit R une relvar, soit A, B, ..., Z des sous-ensembles d’attributs de R, et ACL une liste d’attributs de R, dont les valeurs sont des intervalles. On dit alors que R satisfait la dépendance de jointure généralisée (JD) :

USING (ACL) * {A, B, ..., Z}

si et seulement si l’expression

USING (ACL) ◀ R = R’ ▶

est vraie pour toute valeur de R. (R’ est la U_jointure des U_projections de R sur A, B, ..., Z, et cette U_jointure et les U_projections en question mettent en jeu une spécification USING de la forme USING (ACL)).

Etc. Évidemment, ça devient un peu difficile, mais tant qu’à traiter de la 6NF, autant le faire avec rigueur. Je ne chercherai pas à commenter outre mesure, car il faudrait d'abord expliquer à ceux qui ne la maîtrisent pas ce qu’est la 5NF, puis reproduire le chapitre 23 de l’ouvrage susmentionné, et cela représente indéniablement trop de conditions préalables pour aller plus avant.

Je rappellerai quand même que l’expression

USING (ACL) ◀ R = R’ ▶

est un raccourci pour

(UNPACK r1 ON (ACL)) = UNPACK r2 ON (ACL))

Sachant que chaque attribut figurant dans ACL doit être un attribut de type intervalle.

Dans tout cela, le but de la manœuvre n’est pas de produire systématiquement des tables ayant au plus un attribut non clé, ça serait particulièrement inefficace et coûteux, voire dangereux (comme dans le cas des bases de données dans lesquelles les relations ne seraient que binaires, voir à ce sujet le paragraphe 30.3 de l’ouvrage de 1990 de Codd). Pour passer au plan pratique, le but visé avec la 6NF est clairement la simplification des tables dans lesquelles, pour faire (très !) court, on a essentiellement des dates de début et de fin (en théorie représentées sous forme intervallaire). Autrement dit, il s’agit de simplifier la programmation de la gestion des historiques et apparentés, en isolant dans des tables normalisées en 6NF les données évoluant dans le temps, à leur rythme propre. Ceux qui conçoivent les MCD et les MLD dans les établissements financiers, dans la distribution, etc., diront que, comme pratiquement chaque donnée est datée, cela aurait pour effet de multiplier le nombre de tables, mais après mûre réflexion de leur part, ils y regarderont peut-être à deux fois. Mais il s’agit encore là d’un autre débat, chaque chose en son temps.

C’est tout pour cette fois-ci...

[zoltix]

Je suis entrain de regarder sql 2008 mais je ne vois ou je ne comprends l'évolution du point
7) nouveau type "hiérarchie" (arbres).

C'est quoi ?

[ylarvor]

http://technet.microsoft.com/fr-fr/m.../cc434692.aspx

[Baquardie]

Bonjour,

Je n'arrive pas à retrouver de l'information concernant le point 10. Savez vous ou je pourrais en trouver?

10) ajout du paramétrage de nom de table pour les requêtes (exemple : SELECT * FROM @MaVariableTable)

Merci !

[SQLpro]

Je me suis mal exprimé... Regardez du côté de CREATE TYPE

Exemple :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
CREATE TYPE T AS TABLE (CLEF INT, VALEUR VARCHAR(50))
GO
 
DECLARE @T T
 
INSERT INTO @T VALUES (1, 'uneValeur')
 
SELECT * FROM @T
 
CLEF        VALEUR
----------- --------------------------------------------------
1           uneValeur

A +