3.2.3.1 Le SCHEMA, ou module d'une base de données
La notion de SCHEMA permet de modulariser une base de données. En fait, une base de données (donc un CATALOG selon la norme) comporte au moins un schéma dans lequel on trouvera les objets de la base (tables, vues, routines...). Comprenez qu'il n'est pas possible de créer une table directement dans le CATALOG, mais qu'il faut passer par le schéma. Ainsi, une base de données peut posséder autant de SCHEMA qu'on le désire, chaque schéma pouvant correspondre à un module dans le sens que l'on donne à ce mot pour désigner une bibliothèque de code ou un espace de nom dans un langage itératif. Seule différence avec ces derniers, SQL ne permet qu'un seul niveau de schéma.
Ainsi, dans l'exemple donné ci-avant, la base de données créée comporte automatiquement un schéma. Dans MS SQL Server, le schéma par défaut porte le nom dbo, c'est pourquoi à défaut de spécifier différents schémas, tous les objets créés sont préfixé par dbo pour signifier leur appartenance à ce schéma.
De fait, une base de données comporte toujours au moins un schéma par défaut. Nous verrons que de manière similaire, tout utilisateur SQL est associé à un schéma par défaut qui peut être différent du schéma par défaut de la base de données.
Les avantages de la notion de SCHEMA sont considérables : outre la modularisation des objets de la base (permettant de la répartir dans différentes "unités"), le schéma permet de gérer des privilèges (autorisations) de manière souple et efficace, mais aussi de créer de toutes pièces tous les éléments d'une base de données sans que l'ordre ait une importance.
En fait, un SCHEMA est un nom logique d'une subdivision d'une base de données et tout objet d'une base devrait être systématiquement préfixé par le schéma dans lequel il repose.
Notons enfin qu'un schéma appartient toujours à un utilisateur, celui qui l'a créé.
Ainsi, à l'aide d'une spécification de schéma, on peut commencer par créer un utilisateur et ses privilèges sur une vue qui sera créée après, vue qui elle même peut précéder la création des tables sur laquelle elle repose. Cette particularité peut paraître surprenante, mais elle possède deux avantages :
• ne pas se soucier de l'ordre de dépendance des objets, et par ce fait permettre de créer des contraintes mutuellement dépendantes;
• résoudre de fait un problème auquel se heurtent les développeurs débutants : celui de connaître l'ordre de création des tables liées par l'intégrité référentielle…
L'ordre SQL de création d'un schéma revêt la syntaxe suivante :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| CREATE SCHEMA { nom_schéma |
AUTHORIZATION propriétaire |
nom_schéma AUTHORIZATION propriétaire }
[ DEFAULT CHARACTER SET jeu_de_caractères ]
[ PATH nom_schéma {, nom_schéma ... } ] ]
[ <objet> | <privilège> [, <objet> | <privilège> ...] ]
<objet> ::=
CREATE { DOMAIN | TABLE | VIEW | ASSERTION |
CHARACTER SET | COLLATION |
TRANSLATION | TRIGGER | TYPE |
PROCEDURE | FUNCTION | ROLE } définition_objet
<privilège> ::=
GRANT définition_privilège |
Le propriétaire est en fait l'utilisateur qui créé les objets dans le schéma. Un schéma a toujours un propriétaire.
La clause PATH permet de définir les schémas dans lesquels il faudra rechercher, dans l'ordre de spécification, les différentes routines à utiliser (fonctions, procédures).
...
