5.7. Schémas

Pour créer un schéma, utilisez la commande CREATE SCHEMA. Donnez au schéma un nom de votre choix. Par exemple :

CREATE SCHEMA mon_schema;

Pour créer ou accéder aux objets dans un schéma, écrivez un nom qualifié qui consiste en le nom du schéma et le nom de la table séparés par un point :

schema.table

Ceci fonctionne partout où un nom de table est attendu, donc en incluant les commandes de modification de la table et les commandes d'accès aux données discutées dans les chapitres suivants (nous parlons uniquement des tables mais les mêmes idées s'appliquent aux autres genres d'objets nommés, comme les types et les fonctions).

En fait, la syntaxe encore plus générale

basededonnees.schema.table

peut être utilisé aussi mais, pour le moment, ceci n'existe que pour être conforme au standard SQL. Si vous écrivez un nom de base de données, il devrait être celui de la base auquel vous êtes connecté.

Donc, pour créer une table dans le nouveau schéma, utilisez

CREATE TABLE mon_schema.ma_table (
 ...
);

Pour effacer un schéma vide (tous les objets qu'il contient ont été supprimés), utilisez

DROP SCHEMA mon_schema;

Pour effacer un schéma avec les objets qu'il contient, utilisez

DROP SCHEMA mon_schema CASCADE;

Lisez la Section 5.11, « Gestion des dépendances » pour une description du mécanisme général derrière tout ceci.

Souvent, vous voudrez modifier le schéma utilisé par quelqu'un d'autre (puisque c'est l'une des méthodes par lesquelles on peut restreindre l'activité de vos utilisateurs à des espaces de nom définis). La syntaxe pour ceci est :

CREATE SCHEMA nom_schema AUTHORIZATION nom_utilisateur;

Vous pouvez même omettre le nom du schéma auquel cas, le nom du schéma sera le même que le nom d'utilisateur. Voir la Section 5.7.6, « Méthodes d'utilisation » pour voir comment cela peut être utilisé.

Les noms de schéma commençant par pg_ sont réservés pour les besoins du système et les schémas commençant ainsi ne peuvent pas être créés par les utilisateurs.

Dans les sections précédentes, on créait des tables sans spécifier un nom de schéma. Par défaut, ces tables (et autres objets) sont automatiquement placées dans un schéma nommé « public ». Toute nouvelle base de données contient un tel schéma. Donc, ces instructions sont équivalentes :

CREATE TABLE produits ( ... );

et

CREATE TABLE public.produits ( ... );

Les noms qualifiés sont pénibles à écrire et il est, de toute façon, préférable de ne pas coder un nom de schéma dans une application. Donc, les tables sont souvent appelées par des noms non qualifiés qui s'apparentent souvent au nom de la table lui-même. Le système détermine la table appelée en suivant un chemin de recherche qui est une liste de schémas à vérifier. La première table correspondante est considérée comme la table voulue. S'il n'y a pas de correspondance, une erreur est remontée, même si des noms de table correspondants existent dans d'autres schémas de la base.

Le premier schéma dans le chemin de recherche est appelé le schéma courant. En plus d'être le premier schéma parcouru, il est aussi le schéma dans lequel de nouvelles tables seront créées si la commande CREATE TABLE ne précise pas de nom de schéma.

Pour voir le chemin de recherche courant, utilisez la commande suivante :

SHOW search_path;

Dans la configuration par défaut, ceci renvoie :

 search_path
--------------
 $user,public

Le premier élément précise qu'un schéma avec le même nom que l'utilisateur en cours doit être parcouru. Le deuxième élément renvoie au schéma public que nous avons déjà vu.

Le premier schéma existant dans le chemin de recherche est l'endroit par défaut pour la création de nouveaux objets. Ceci est la raison pour laquelle les objets sont créés dans le schéma public. Quand les objets sont liés dans tout autre contexte sans une qualification de schéma (modification de table, modification de données ou requête de commande), le chemin de recherche est traversé jusqu'à ce qu'un objet correspondant soit trouvé. Donc, dans la configuration par défaut, tout accès non qualifié ne peut que se référer au schéma public.

Pour mettre notre nouveau schéma dans le chemin, nous utilisons

SET search_path TO mon_schema,public;

(nous ne mettons pas le $user ici car nous n'en avons pas besoin pour l'instant). Et nous pouvons pas accéder à la table sans qualification de schéma :

DROP TABLE ma_table;

Aussi, puisque mon_schema est le premier élément dans le chemin, les nouveaux objets seront créés dans ce schéma.

On pourrait aussi écrire

SET search_path TO mon_schema;

Dans ce cas, nous n'avons pas accès au schéma public sans qualification explicite. Il n'y a rien de spécial à propos du schéma public hormis le fait qu'il existe par défaut. Il peut aussi être effacé.

Voir aussi la Section 9.19, « Fonctions d'informations système » qui détaille les autres façons de manipuler le chemin de recherche des schémas.

Le chemin de recherche fonctionne de la même façon pour les noms de type de données, les noms de fonction et les noms d'opérateur que pour les noms de tables. Les types de données et de fonctions peuvent être qualifiés de la même façon que les noms de table. Si vous avez besoin d'écrire un nom d'opérateur qualifié dans une expression, il y a une condition spéciale : vous devez écrire

OPERATOR(schéma.opérateur)

Ceci est nécessaire afin d'éviter une ambiguïté syntaxique. En voici un exemple

SELECT 3 OPERATOR(pg_catalog.+) 4;

En pratique, on dépend souvent du chemin de recherche pour les opérateurs, afin de ne pas avoir à écrire quelque chose d'aussi peu présentable.

Par défaut, les utilisateurs ne peuvent pas accéder aux objets présents dans les schémas qui ne leur appartiennent pas. Pour leur permettre, le propriétaire du schéma doit donner le droit USAGE sur le schéma. Pour autoriser les utilisateurs à manipuler les objets d'un schéma, des droits supplémentaires devront peut-être être accordés, suivant l'objet.

Un utilisateur peut aussi être autorisé à créer des objets dans le schéma de quelqu'un d'autre. Pour permettre ceci, le droit CREATE doit être accordé. Notez que, par défaut, tout le monde a les droits CREATE et USAGE sur le schéma public. Ceci permet à tous les utilisateurs qui sont capables de se connecter à une base de données de créer des objets dans son schéma public. Si vous ne souhaitez pas ce comportement, vous pouvez révoquer ce droit :

REVOKE CREATE ON SCHEMA public FROM PUBLIC;

Le premier « public » est le schéma, le second « public » veut dire « chaque utilisateur ». Dans le premier cas, c'est un identifieur. Dans le second, c'est un mot clé, d'où la casse différente. Souvenez-vous des règles de la Section 4.1.1, « Identifieurs et mots clés ».

En plus du schéma public et de ceux créés par les utilisateurs, chaque base de données contient un schéma pg_catalog, qui contient les tables systèmes et tous les types de données, fonctions et opérateurs intégrés. pg_catalog fait toujours partie du chemin de recherche. S'il n'est pas nommé explicitement dans le chemin, il est parcouru implicitement avant la recherche dans les schémas du chemin. Ceci garantie qui les noms internes seront toujours trouvables . Par contre, vous pouvez explicitement placer pg_catalog à la fin si vous préférez que les noms définis par les utilisateurs surchargent les noms internes.

Dans les versions de PostgreSQL™ antérieures à la 7.3, les noms de table commençant par pg_ étaient réservés. Ceci n'est plus vrai : vous pouvez créer une telle table si vous le voulez dans n'importe quel schéma non système. Par contre, il vaut mieux continuer d'éviter de tels noms pour garantir que vous n'aurez pas de conflit si une prochaine version définit une table système qui porte le même nom que votre table (avec le chemin de recherche par défaut, une référence non qualifiée à votre table pointera au lieu vers la table système). Les tables systèmes continueront de suivre la convention de porter des noms commençant par pg_ pour qu'ils n'aient pas de conflit avec des noms de table non qualifiés tant que les utilisateurs éviteront le préfixe pg_.

Les schémas peuvent être utilisés pour organiser vos données de plusieurs manières. Plusieurs sont recommandés et sont facilement supportés par la configuration par défaut :

Dans le standard SQL, la notion d'objets du même schéma appartenant à des utilisateurs différents n'existe pas. De plus, certaines implémentations ne vous permettent pas de créer des schémas qui ont un nom différent de celui de leur propriétaire. En fait, les concepts de schéma et d'utilisateur sont presque équivalents dans un système de base de données qui n'implémente que le support basique des schémas spécifiés dans le standard. À partir de ce constat, beaucoup d'utilisateurs considèrent les noms qualifiés comme correspondant réellement à utilisateur.table. C'est comme cela que PostgreSQL™ se comporte si vous créez un schéma par utilisateur pour chaque utilisateur.

De plus, il n'y a aucun concept d'un schéma public dans le standard SQL. Pour plus de conformité au standard, vous ne devriez pas utiliser (et sans doute effacer) le schéma public.

Bien sûr, certains systèmes de bases de données n'implémentent pas du tout les schémas. ou donnent le support d'espace de nommage en autorisant (peut-être de façon limité) des accès sur plusieurs bases de données. Dans ce cas, la portabilité maximale sera obtenue en n'utilisant pas du tout les schémas.