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.

Envoyé par
elsuket
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é.

Envoyé par
elsuket
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. »

Envoyé par
elsuket
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) ?

Envoyé par
elsuket
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).

Envoyé par
elsuket

Envoyé par
TeK55
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 :
Dans le cas du Modèle SQL, la réponse est aujourd’hui négative, mais un jour peut-être ?
Partager