Discussion :

[TeK55]

Bonjour à tous,

Je me pose actuellement une question sans trouver ma réponse sur le web ...

J'ai deux base de données différentes mais fonctionnant toutes les deux sous SQL Server 2008, on va dire base1 et base2.

Les données de ma base 2 seront accessibles grâce à l'utilisation de vue au sein de ma base 1.

Mais dans le but d'avoir des données cohérentes dans ma base 1, je voudrais réaliser un clé étrangère sur les données extraites de ma vue (Code de l'élément, etc ...).

Donc, est il possible de réaliser une clé étrangère sur une vue ?

Si vous connaissez un autre moyen, je suis preneur.

Merci d'avance.

[elsuket]

Bonjour,

Les données de ma base 2 seront accessibles grâce à l'utilisation de vue au sein de ma base 1.

Pourquoi ne pas placer la vue dans votre base 1 et la requêter depuis la base 2 ?
Avec un peu de chance vous pourrez probablement l'indexer et gagner en performances ...

Donc, est il possible de réaliser une clé étrangère sur une vue ?

Non, pour la simple et bonne raison qu'une vue n'est pas une table.
Les relations d'une base de données n'existent qu'entre les entités d'un projet de base de données.
Dans le modèle physique, cela se traduit respectivement par des contraintes d'intégrité entre les tables de la base de données.
Une vue n'existe ni dans le modèle conceptuel de toute base de données, ni dans le modèle physique, mais seulement dans le modèle externe de données.

Si vous connaissez un autre moyen, je suis preneur.

Réalisez la vue dans la bonne base de données.
Si une contrainte de clé étrangère doit exister entre vos base de données, c'est qu'il y a une erreur dans votre modèle de données.
Si vous voulez néanmoins réaliser ce contrôle, vous n'aurez pas d'autre choix que d'implémenter un trigger (que vous pouvez attacher à une vue ou une table).

@++

[TeK55]

Merci pour les réponse rapides elsuket,

Comme je m'en doutais, ce n'est pas réalisable, (ca aurait été trop beau ).

Je me suis déjà pencher sur l'utilisation de trigger pour vérifier les données de présentes dans une autre table et je vais donc réutiliser ce système.

Bonne journée à tous.

[SQLpro]

Il serait beaucoup plus simple et performant que vos deux bases n'en fasse qu'une. Pour cela il suffit souvent de placer chacune des bases dans un schéma particulier.

A +

[TeK55]

Le soucis est que l'une des bases de données n'a pas été développé par notre entreprise. Car il s'agit d'une base de donnée pour notre logiciel de paie et cette base a été développé par une grosse entreprise dans le domaine de la gestion.

Donc je ne pense pas pouvoir créer mes différentes tables dans la base de données du logiciel de gestion, ni même la modifier.

De plus les informations que j'ai besoin dans la base de donnée du logiciel de gestion seront vraiment minimes car j'ai seulement besoin de récupérer principalement un code (clients, lieux des clients, etc.)

Donc le trigger va être surement la meilleur solution.

[fsmrel]

Bonsoir,


Avant d’apporter quelques commentaires concernant cette discussion, je fournis quelques précisions ayant trait au vocabulaire. Dans le cadre du Modèle Relationnel de Données, on n’utilise pas le terme table, qui reste du ressort de SQL. En effet, étant mathématiciens, les théoriciens du Modèle relationnel ont toujours utilisé le terme relation (Ted Codd, Ron Fagin, Claude Delobel, Jeff Ullman, David Maier, j'en passe et des meilleurs).

A partir de 1995, Date et Darwen ont utilisé le concept de variable de relation (relation variable, en abrégé relvar) pour que la relation proprement dite conserve strictement sa propriété mathématique d’invariance (alors que 25 ans plutôt, Ted Codd utilisait le terme « time-varying relation » : « The totality of data in a data bank may be viewed as a collection of time-varying relations. »).

Tout comme dans un programme une variable X de type entier peut successivement prendre des valeurs différentes qui sont des entiers, une variable R de type relation peut successivement prendre des valeurs différentes qui sont des relations.

Selon le contexte, la table SQL correspond donc soit à la relvar, soit à la relation.

Par ailleurs, une relvar est soit réelle (ou de base) ou virtuelle (vue). Le terme relvar est donc générique : une relvar réelle est une relvar et une relvar virtuelle est aussi une relvar (en notant que, lorsqu’il n’y a pas d’ambiguïté possible, on abrège le plus souvent relvar réelle en relvar).

Une relvar réelle est une représentation de données physiquement stockées, elle est « matérialisée » si l’on peut dire. Par contraste, une vue n’est pas matérialisée, elle permet simplement de voir les données « matérialisées » de différentes manières. En tout cas, relvar réelle et vue sont des relvars.

De la même façon, on pourrait concevoir qu’au sens générique du terme, une table SQL puisse être spécialisée est soit en une table de base soit en une vue.

une vue n'est pas une table.

Dans le sens de ce qui précède, une vue n’est pas une table de base mais j’ai envie de dire qu’elle est une spécialisation de la table considérée au sens générique. Ainsi, la vue système INFORMATION_SCHEMA.TABLES contient indifféremment les noms des tables de base et des vues, la colonne TABLE_TYPE permettant de savoir quel est le type de chaque « objet » nommé.

Une vue n'existe ni dans le modèle conceptuel de toute base de données, ni dans le modèle physique, mais seulement dans le modèle externe de données.

Faites-vous référence au niveau externe de l’architecture ANSI/SPARC ?
En tout état de cause, je cite et traduis Chris. Date (cf. An introduction to Databases Systems, Chapitre 3, page 74) :

« Dans le contexte relationnel, le terme vue a une signification particulière, différente de celle qu’on lui attribue dans le cadre de l’architecture ANSI/SPARC. Au niveau externe de cette architecture, la base de données est perçue comme une “vue externe”, définie par un schéma externe (et des utilisateurs différents peuvent avoir des vues externes différentes à leur disposition). Par contre, pour les systèmes relationnels, une vue est spécifiquement une relvar virtuelle, dérivée et nommée. Ainsi, l’homologue de la “vue externe” ANSI/SPARC est (typiquement) une collection de plusieurs relvars, où chacune d’elles est une vue au sens relationnel et où le “schéma externe” est constitué des définitions de ces vues. »

Les relations d'une base de données n'existent qu'entre les entités d'un projet de base de données.

Qu’entendez-vous par « Les relations d'une base de données » ? par « entités » ? « par projet de base de données » ?

Par définition, une (valeur de) base de données relationnelle est une collection de relations (time-varying relations comme disait Codd).

Mais comme en français le mot « relation » est ambigu, peut-être voulez-vous parler des associations-types entre entités-types décrites dans un modèle conceptuel de données (MCD) ?

Dans le modèle physique, cela se traduit respectivement par des contraintes d'intégrité entre les tables de la base de données.

Les contraintes d’intégrité relèvent du niveau logique et traduisent de manière formelle les règles de gestion de données du niveau conceptuel. On peut dire que ces contraintes relèvent de la logique formelle, et n’ont donc rien à voir avec le niveau physique où l’on met en œuvre les tablespaces, les index et tous autres objets dont les caractéristiques varient très sensiblement d’un SGBD à l’autre et ne sont évidemment pas définis dans le Modèle Relationnel de Données (dans la norme SQL non plus me semble-t-il).

est il possible de réaliser une clé étrangère sur une vue ?

Non, pour la simple et bonne raison qu'une vue n'est pas une table.

La question posée par TeK55 est pertinente. En effet, dans le cas du Modèle Relationnel de Données la réponse est positive. Date et Darwen précisent bien :

« Referential constraints are usually thought of as applying to real relvars only. In the Manifesto, by contrast, we regard them as to applying to virtual relvars as well. » Cf. Databases, Types, and the Relational Model The Third Manifesto (Third Edition, page 219).

Dans le cas du Modèle SQL, la réponse est aujourd’hui négative, mais un jour peut-être ?

[elsuket]

Bonjour,

Faites-vous référence au niveau externe de l’architecture ANSI/SPARC ?

Pas directement dans ce que j'ai écrit, mais c'est bien ce que je sous-entendais
Je voulais montrer à TeK55 qu'il n'est pas possible de créer des relations entre des vues, parce que je considère les vues comme une abstraction des données : dans la spécification d'une vue, on peut "encapsuler" des calculs d'aggrégats, des appels à des fonctions, des données de tables d'une autre base de données ...

Comme une vue peut faire appel à des tables qui n'appartiennent pas à la même base de données, je trouve logique qu'il ne soit pas possible de spécifier des contraintes d'intégrité sur des vues, puisque celles-ci sont une abstraction des entités du monde réel.

Dans le cas du Modèle SQL, la réponse est aujourd’hui négative, mais un jour peut-être ?

Pourquoi pas mais je n'en vois pas les avantages directs

@++

[fsmrel]

Bonjour,

il n'est pas possible de créer des relations entre des vues, parce que je considère les vues comme une abstraction des données : dans la spécification d'une vue, on peut "encapsuler" des calculs d'aggrégats, des appels à des fonctions, des données de tables d'une autre base de données

Une table de base est une abstraction de données, une vue est une abstraction de données, et les opérations binaires de l'algèbre relationnelle (jointure, union, etc.) permettent d’établir des relations entre ces types d’objets (si c’est le sens que vous donnez au mot relation).

En ce qui concerne le résultat d’un calcul d’agrégat, il suffit de préciser si ce résultat est scalaire ou non scalaire. S’il est scalaire (atomique, ou encapsulé comme vous dites), c’est une valeur qui a un type (entier, caractère, longueur, polygone, etc.) et on est ramené au cas général des valeurs prises par un attribut d’une table. Si ce résultat a une structure de table, il est non scalaire, mais est du type table et il suffit qu’il soit bien formé (colonnes ayant chacune un nom et typées, etc.)

En ce qui concerne les appels à des fonctions, je suppose que vous faites allusion aux opérateurs définis par l’utilisateur. Mais de même que « + », « - », « = », etc. sont des opérateurs fournis par le SGBD (et peuvent être surchargés), dans la mesure où chaque opérateur est défini dans les règles de l’art, c'est-à-dire dans le but de permettre de tricoter sans erreur des données d’un type donné commun (système ou utilisateur), je ne vois pas le problème (en tout cas dans le cadre du Modèle Relationnel de Données, mais je ne prononcerai pas dans le cas de SQL).

Quant aux données appartenant à des bases de données distinctes, peut-être y a-t-il un problème, mais l’avis de SQLpro est à prendre en considération. Sinon, le modèle SQL adhérera peut-être un jour pleinement aux 12 objectifs recensés par Chris Date (An introduction to Databases Systems 8th edition, Chapitre 20 « Distributed Databases »), précédés du principe fondamental :

« Vu de l’utilisateur, il ne doit pas y avoir de différence entre un système distribué et un système qui ne l’est pas. »

Ainsi, j’aurais tendance à interpréter votre phrase de la façon suivante :

Dans le cas de SQL, il est possible que certaines relations entre vues (ou tables ou sacs) ne soient pas possibles, parce qu’elles ne permettent pas de respecter le principe fondamental de fermeture.

Par fermeture, j’entends que le fruit du mariage de deux tables (au sens large, c'est-à-dire tables de base ou vues) est de même nature que ses parents, c'est-à-dire est aussi une table. (Tout comme le résultat de l’addition de deux nombres entiers est un nombre entier). Ainsi, la nouvelle table peut à son tour être mariée sans aucun risque, au nom du principe de fermeture.

Dans le cas du Modèle SQL, la réponse est aujourd’hui négative, mais un jour peut-être ?

je n'en vois pas les avantages directs

Tout d’abord, j’aurais déjà dû préciser : A condition qu’une table SQL soit conforme au Modèle Relationnel de Données.

Quant aux avantages : il est quand même plus simple de n’avoir à mette à jour qu’une table (table de base ou vue) que plusieurs, quand on en est réduit à dispatcher la mise à jour sur d’autres tables, à l’aide de triggers savants qui n’ont pas forcément la même syntaxe selon les SGBD, et peuvent aussi comporter des failles. Il est plus simple d’« encapsuler », de sous-traiter au SGBD la complexité des opérations. Avantage connexe : liberté de changer de SGBD sans avoir à monter une usine à gaz pour la migration (au moins en ce qui concerne cette partie).

Sinon, les chercheurs n’auraient pas pris la peine de creuser le sujet depuis maintenant plus de trente ans en arrivant à prouver « updatable » des vues dont le statut était jusque là « Work is needed to charaterize this set precisely... ». David McGoveran ou le duo Chris Date et Hugh Darwen continuent à explorer (cf. « The Logic of View Updating », plus de 35 pages sur le sujet...) Tout n’est pas simple et les duettistes ne sont pas forcément d’accord sur la façon de résoudre le problème (il y a donc encore du grain à moudre pour les chercheurs). Si le cœur vous en dit...