Database Reference
In-Depth Information
Le schéma SQL est un conteneur logique pour les objets d'une base. Il n'a donc rien
à voir avec un stockage physique. Si votre SGBDR gère correctement les espaces de
stockage, vous pouvez avoir n tables toutes créées dans un schéma S1 et chacune de ces
tables peut stocker ses données où bon lui semble et pourquoi pas un espace de stockage
spéciique à chaque table.
Répartir les objets d'une base de données dans différents schémas SQL est une excellente
approche, car cela permet d'organiser la base en différents pans sémantiques ou fonc-
tionnels. En revanche, répartir les objets d'une même application dans différentes bases,
pose des problèmes impossibles à résoudre.
• On ne peut pas faire de contraintes SQL d'une base à une autre. En revanche, au sein
d'une même base et même si les objets sont dans différents schémas SQL c'est possible.
• On ne peut pas sauvegarder les données de deux bases différentes de manière syn-
chrone alors que la sauvegarde d'une base emporte la sauvegarde de tous les schémas
d'un seul coup au même point de synchronisation.
• La gestion des privilèges est spéciique à une base. Elle couvre les schémas, mais elle
ne peut passer de base en base (MS SQL Server est le seul SGBDR à permettre cette
fonction, mais elle s'avère complexe à mettre en œuvre).
Schémas et propriétaires
Comme tout objet de la base, un schéma est créé par un utilisateur, ce qui confère à cet
utilisateur d'être le propriétaire du schéma, à moins qu'il ne spéciie un autre utilisateur
dans l'ordre SQL
CREATE SCHEMA
.
Le propriétaire d'un schéma est un peu comme un châtelain du Moyen Âge… Il a le droit
de vie ou de mort sur ses sujets, je voulais dire « ses objets », tout le temps qu'il est respon-
sable de la création des objets igurant à l'intérieur de son schéma. Mais rien n'empêche
de créer au sein du schéma de Pierre un objet dont le propriétaire est Paul (une sorte de
concession en somme) !
Il y a longtemps eu une confusion au sein des éditeurs de SGBDR entre la notion de
propriétaire (la norme SQL parle d'« autorisé ») et la notion de schéma. C'est ainsi que
dans certains SGBDR le schéma par défaut porte le même nom que l'utilisateur qui en est
propriétaire, histoire d'entretenir la confusion !
Les contraintes
Les objectifs des contraintes au niveau des tables sont multiples : renforcer l'intégrité de la
base, programmer des règles de gestion élémentaires et alléger la programmation côté client.
