Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Conférences Microsoft : Visionnez les sessions et interviews du MS TechNet Tour 2008

Le , par SQLpro

0PARTAGES

0  0 
La prochaine version de MS SQL Server sortira en 2008. Son nom de code est katmai.
Parmi les nouveautés :
1) types SQL date et time (date, time, datetime2, datetimeoffset) avec rajout de la semaine iso et gestion des fuseaux horaires
2) compression des données pour le Data Warehouse
3) ordre SQL MERGE (INSERT et UPDATE combiné)
4) possibilité d'implanter des règles de securité (par exemple respect d'une police de nommage - à l'instar des GPO de Windows)
5) module de géolocalisation spatial (SIG)
6) creation possible de nouveaux roles de serveur
7) nouveau type "hiérarchie" (arbres)
8) nouveau type filestream (proche du datalink de la norme SQL, permettant de considérer un fichier comme une donnée d'une colonne d'une table
9) ajout du type table
10) ajout du paramétrage de nom de table pour les requêtes (exemple : SELECT * FROM @MaVariableTable)
11) sauvegardes compressées
12) possibilité de definir des groupes pour gérer les ressources physiques, par exemple pour avantager les requêtes de production au détriment des requêtes d'admin (Resource Gouvernor)
13) intégration du langage d'interrogation LINQ (Language Integrated Query) permettant de faire des requêtes d'interrogation évoluées
14) Ajout du GROUPING SETS pour les fonctions OLAP des bases OLTP
15) tracabilité des données (accès asynchrone au données modifiées dans les tables)
16) Intégration plus forte avec Office
17) Nombreuses avancées pour BI.
Et encore bien d'autres choses !

Annonce MS :
http://www.microsoft.com/presspass/p...9KatmaiPR.mspx

Site MS du produit :
http://www.microsoft.com/sql/prodinf...n/default.mspx

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de fsmrel
Expert éminent sénior https://www.developpez.com
Le 09/06/2008 à 1:00
Citation Envoyé par SQLpro Voir le message
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.

Citation Envoyé par SQLpro Voir le message
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 ?)

Citation Envoyé par SQLpro Voir le message
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.

Citation Envoyé par SQL pro Voir le message
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.

Citation Envoyé par SQLpro Voir le message
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.

Citation Envoyé par SQLpro Voir le message
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...
2  0 
Avatar de fsmrel
Expert éminent sénior https://www.developpez.com
Le 08/05/2008 à 17:12
Bonjour,

A propos de la 1NF.

Citation Envoyé par SQLpro Voir le message
Cette table :
Code : Sélectionner tout
1
2
3
4
5
6
7
8
TIERS_ST_Adresses (les adresses postales)
    TIERS_ST_Adresses uniqueidentifier
    FK_TIERS_MT_Tiers uniqueidentifier
    txtAdresse1 nvarchar(50)
    txtAdresse2 nvarchar(50)
    txtAdresse3 nvarchar(50)
    txtCP nvarchar(10)
    txtVille nvarchar(50)


Ne respecte pas la 1ere forme normale.
Je m’inscris en faux contre cette affirmation et m’appuie pour cela sur des références incontestables et incontournables comme Codd, Date, Silberschatz et Korth, Maier, Gardarin et Cie, pour affirmer à mon tour que la table en cause respecte bien la 1re forme normale.

Je cite (et traduis) Codd qui a écrit en 1971 :
Une table est en première forme normale si aucune de ses colonnes ne peut prendre de valeur qui soit elle-même un ensemble.
Et en 1990, il apporte cette précision :
Vu du SGBD, les valeurs des domaines sur lesquels chaque relation est définie doivent être atomiques.
Ce qui veut dire que, vu du SGBD, ces valeurs ne sont pas décomposables.

A l’instar par exemple de David Maier et de quelques autres, on peut encore apporter cette précision si besoin était :
Les valeurs des domaines ne sont ni des listes, ni des ensembles.


Notez encore le "si et seulement si" de Date :
A relation R is in first normal form if and only if underlying domains contain atomic values.


Concernant la table TIERS_ST_Adresses :

Les colonnes txtAdresse1, txtAdresse2, txtAdresse3 font référence au domaine nvarchar(50) dont les valeurs sont par définition atomiques au sens SQL ; la table TIERS_ST_Adresses est donc en 1NF. Sinon, si les valeurs du domaine nvarchar(50) ne sont pas atomiques, la colonne txtAdresse de la table TIERS_ST_AdresseLignes y faisant référence elle aussi, elle viole à son tour la 1NF (et donc la 2NF, etc.)

Outre ceux que j’ai cités, ce ne sont pas non plus des ténors du Relationnel comme Ullman, Miranda, Delobel et Adiba qui me contrediront.
1  0 
Avatar de fsmrel
Expert éminent sénior https://www.developpez.com
Le 09/05/2008 à 3:50
Citation Envoyé par SQLpro Voir le message
je ne suis pas du tout d'accord avec ton interprétation trop littérale.

Je n’interprète rien du tout. Je ne fais que citer les auteurs de référence, au sujet de la définition de la 1NF, notamment le père du Modèle relationnel, qui se trouve avoir aussi inventé la 1NF (et qui du reste, n’était pas obligé de le faire : en 1969 il était muet sur le sujet (Cf. E.F. Codd - Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks. IBM Research Report RJ599 (August 19th, 1969)).

Vous avez le droit d’être en désaccord avec Codd, mais alors n’appelez pas Première Forme Normale la contrainte que vous préconisez — au demeurant tout à fait pertinente — à savoir qu’un ensemble de colonnes d’une table ne puisse constituer une liste.

Citation Envoyé par SQLpro Voir le message
nous savons que cela n'est pas du pur relationnel et nous connaissons les problèmes que cela pose en général d'un point de vue requête comme au sujet des performances
Certes, il y a un problème relevant de la modélisation conceptuelle, mais le Modèle relationnel de données n’a rien à voir avec cela. Que les requêtes soient beaucoup plus balourdes, c’est certain, mais ça n’est pas non plus le problème du Modèle relationnel qui en l’occurrence n’a pas à se prononcer. Quant aux performances, elles sont l’affaire du SGBD car elles relèvent de la réalisation et non pas des concepts.

Citation Envoyé par SQLpro Voir le message
Je suis même encore plus méchant que cela, car dans les cours de modélisation que je donne, je considère comme faute le motif suivant :

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
CREATE TABLE T_CLIENT_CLI
( 
...
CLI_TELEPHONE_DOMICILE   VARCHAR(20),
CLI_TELEPHONE_BUREAU   VARCHAR(20),
CLI_TELEPHONE_PORTABLE   VARCHAR(20),
CLI_TELECOPIE_BUREAU   VARCHAR(20),
...
)
En effet cela devrait être traduit en une table de téléphones avec des types de téléphone (GSM, Fixe, FAX...) et des localisations (Domicile, bureau..)

Bien entendu, cette liste de colonnes dénote une maladresse évidente dans la conception de la table et il faut renvoyer à l’école celui qui en est l’auteur. Mais je répète que, stricto sensu, ceci ne concerne pas la première forme normale.

J’ai eu, moi aussi, bien souvent à expliquer à des concepteurs peu aguerris les risques de ce genre de modélisation. Par exemple, l’un d’eux était très fier de son MCD concernant les statistiques du réseau (le produit final devait être vendu chez nos clients...) Mais une entité-type comportait une liste d’attributs, un pour chaque jour de la semaine, une deuxième liste était du même tonneau, ainsi qu’une troisième liste... Je lui ai posé la question suivante : "Que feras-tu de ton système le jour où certains de tes clients voudront des statistiques non pas sur 7 jours, mais sur 10 ou 15 jours ?", "Crois-tu que SQL est fait pour sommer un nombre fixe de colonnes ?", etc. Il a tout de suite compris l'enjeu et s’est empressé de revoir sa copie.

Je vous donne matière à être très, mais alors très méchant, concernant une table qui est en première forme normale, mais qui mérite une fort mauvaise note par ailleurs...


Cette image date de quelques années. Pour avoir quelque chose de plus frais (mais toujours aussi mal modélisé) :
1  0 
Avatar de fsmrel
Expert éminent sénior https://www.developpez.com
Le 29/05/2008 à 2:23
Citation Envoyé par SQLpro Voir le message
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.

Citation Envoyé par SQLpro Voir le message
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.

Citation Envoyé par SQLpro Voir le message
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.
1  0 
Avatar de fsmrel
Expert éminent sénior https://www.developpez.com
Le 04/06/2008 à 2:31
Citation Envoyé par SQLpro Voir le message


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.

Citation Envoyé par SQLpro Voir le message

De plus vous confirmez que pour la vue :
Citation Envoyé par

La redondance est licite

Toujours dans le cadre de la théorie relationnelle, ceci est la conséquence de ce qui précède.

Citation Envoyé par SQLpro Voir le message

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.

Citation Envoyé par SQLpro Voir le message

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...)

Citation Envoyé par SQLpro Voir le message

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.
1  0 
Avatar de Ekimasu
En attente de confirmation mail https://www.developpez.com
Le 10/07/2007 à 9:30
les points 3,7,8 et 9 sont de grandes avancées.
ça va facilité la vie de bcp de programmeur.

ces fonctionnalités existent chez les autres SGBD concurrents ?
0  0 
Avatar de Bousseliou
Candidat au Club https://www.developpez.com
Le 25/07/2007 à 17:32
Bonjour,
Perso j'attends avec impatience l'option 10, que de temps passé avec les Sp_ExecuteSQL pour quelque chose d'approchant.
Merci pour l'info et longue vie au Forum.
Alain
0  0 
Avatar de Yann
Membre du Club https://www.developpez.com
Le 28/07/2007 à 7:57
C'est sûr que de nouveaux types de données évolués, c'est tjs appréciables. Mais je suis surtout curieux de découvrir Link, en relation avec C# 3.0.

Par contre, je ne comprend pas bien ce qu'un SIG vient faire dans un SGBDR.
0  0 
Avatar de The eye
Membre averti https://www.developpez.com
Le 30/07/2007 à 10:33
Le point 8) manquait cruellement à SQL Server! Content de voir qu'ils comblent cette lacune!
0  0 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 09/08/2007 à 22:25
Pour le SIG, c'est dans la norme SQL...

ISO/IEC 13249:2003 Part 3: Spatial
ISO/IEC 13249-3:2003:
• introduces the Spatial part of ISO/IEC 13249 (all parts);
• gives the references necessary for ISO/IEC 13249-3:2003;
• defines notations and conventions specific to ISO/IEC 13249-3:2003;
• defines concepts specific to ISO/IEC 13249-3:2003;
• defines spatial user-defined types and their associated routines.
The spatial user-defined types defined in ISO/IEC 13249-3:2003 adhere to the following.
• A spatial user-defined type is generic to spatial data handling. It addresses the need to store, manage and retrieve information based on aspects of spatial data such as geometry, location and topology.
• A spatial user-defined type does not redefine the database language SQL directly or in combination with another spatial data type.
Implementations of ISO/IEC 13249-3:2003 may exist in environments that also support geographic information, decision support, data mining and data warehousing systems.
Application areas addressed by implementations of ISO/IEC 13249-3:2003 include, but are not restricted to, automated mapping, desktop mapping, facilities management, geoengineering, graphics, multimedia and resource management applications.
A +
0  0