Principes de base de la gestion de schéma PostgreSQL

Vous vous demandez ce que sont les schémas Postgresql et pourquoi ils sont importants et comment vous pouvez utiliser des schémas pour rendre vos implémentations de base de données plus robustes et maintenables ? Cet article présentera les bases des schémas dans Postgresql et vous montrera comment les créer avec quelques exemples de base. Les prochains articles se pencheront sur des exemples de sécurisation et d'utilisation de schémas pour des applications réelles.

Tout d'abord, pour dissiper une éventuelle confusion terminologique, comprenons que dans le monde Postgresql, le terme "schéma" est peut-être un peu malheureusement surchargé. Dans le contexte plus large des systèmes de gestion de bases de données relationnelles (RDBMS), le terme « schéma » peut être compris comme faisant référence à la conception logique ou physique globale de la base de données, c'est-à-dire la définition de toutes les tables, colonnes, vues et autres objets. qui constituent la définition de la base de données. Dans ce contexte plus large, un schéma peut être exprimé dans un diagramme entité-relation (ER) ou un script d'instructions en langage de définition de données (DDL) utilisé pour instancier la base de données d'application.

Dans le monde Postgresql, le terme « schéma » pourrait être mieux compris comme un « espace de noms ». En fait, dans les tables système Postgresql, les schémas sont enregistrés dans des colonnes de table appelées "espace de noms", qui, à mon humble avis, est une terminologie plus précise. En pratique, chaque fois que je vois "schéma" dans le contexte de Postgresql, je le réinterprète silencieusement comme disant "espace de noms".

Mais vous pouvez demander :"Qu'est-ce qu'un espace de noms ?" Généralement, un espace de noms est un moyen assez souple d'organiser et d'identifier les informations par leur nom. Par exemple, imaginez deux ménages voisins, les Smith, Alice et Bob, et les Jones, Bob et Cathy (cf. Figure 1). Si nous n'utilisions que des prénoms, il pourrait être difficile de savoir de quelle personne nous parlions en parlant de Bob. Mais en ajoutant le nom de famille, Smith ou Jones, nous identifions de manière unique de quelle personne nous parlons.

Souvent, les espaces de noms sont organisés dans une hiérarchie imbriquée. Cela permet une classification efficace de vastes quantités d'informations dans une structure très fine, comme par exemple le système de noms de domaine Internet. Au niveau supérieur, ".com", ".net", ".org", ".edu", etc. définissent de larges espaces de noms dans lesquels sont enregistrés des noms pour des entités spécifiques, par exemple, "severalnines.com" et "postgresql.org" sont définis de manière unique. Mais sous chacun d'entre eux, il existe un certain nombre de sous-domaines communs tels que "www", "mail" et "ftp", par exemple, qui seuls sont dupliqués, mais dans les espaces de noms respectifs sont uniques.

Les schémas Postgresql ont le même objectif d'organisation et d'identification, cependant, contrairement au deuxième exemple ci-dessus, les schémas Postgresql ne peuvent pas être imbriqués dans une hiérarchie. Bien qu'une base de données puisse contenir de nombreux schémas, il n'y a jamais qu'un seul niveau et donc dans une base de données, les noms de schéma doivent être uniques. De plus, chaque base de données doit inclure au moins un schéma. Chaque fois qu'une nouvelle base de données est instanciée, un schéma par défaut nommé "public" est créé. Le contenu d'un schéma inclut tous les autres objets de la base de données tels que les tables, les vues, les procédures stockées, les déclencheurs, etc. Base de données Postgresql.

En plus d'organiser simplement les objets de base de données en groupes logiques pour les rendre plus faciles à gérer, les schémas ont pour objectif pratique d'éviter les collisions de noms. Un paradigme opérationnel consiste à définir un schéma pour chaque utilisateur de base de données afin de fournir un certain degré d'isolement, un espace où les utilisateurs peuvent définir leurs propres tables et vues sans interférer les uns avec les autres. Une autre approche consiste à installer des outils tiers ou des extensions de base de données dans des schémas individuels afin de conserver logiquement tous les composants associés. Un article ultérieur de cette série détaillera une nouvelle approche de la conception d'applications robustes, utilisant des schémas comme moyen d'indirection pour limiter l'exposition de la conception physique de la base de données et présentera à la place une interface utilisateur qui résout les clés synthétiques et facilite la maintenance à long terme et la gestion de la configuration. à mesure que les exigences du système évoluent.

Faisons un peu de code !

La commande la plus simple pour créer un schéma dans une base de données est

CREATE SCHEMA hollywood;

Cette commande nécessite des privilèges de création dans la base de données, et le schéma nouvellement créé "hollywood" appartiendra à l'utilisateur appelant la commande. Une invocation plus complexe peut inclure des éléments facultatifs spécifiant un propriétaire différent, et peut même inclure des instructions DDL instanciant des objets de base de données dans le schéma en une seule commande !

Le format général est

CREATE SCHEMA schemaname [ AUTHORIZATION username ] [ schema_element [ ... ] ]

où « nom d'utilisateur » est le propriétaire du schéma et « schema_element » peut être l'une de certaines commandes DDL (reportez-vous à la documentation de Postgresql pour plus de détails). Les privilèges de superutilisateur sont requis pour utiliser l'option AUTORISATION.

Ainsi, par exemple, pour créer un schéma nommé "hollywood" contenant une table nommée "films" et afficher les "gagnants" en une seule commande, vous pouvez faire

CREATE SCHEMA hollywood
    CREATE TABLE films (title text, release date, awards text[])
    CREATE VIEW winners AS
        SELECT title, release FROM films WHERE awards IS NOT NULL;

Des objets de base de données supplémentaires peuvent ensuite être créés directement, par exemple une table supplémentaire serait ajoutée au schéma avec

CREATE TABLE hollywood.actors (name text, dob date, gender text);

Notez dans l'exemple ci-dessus le préfixe du nom de la table avec le nom du schéma. Ceci est nécessaire car par défaut, c'est-à-dire sans spécification de schéma explicite, de nouveaux objets de base de données sont créés dans le schéma actuel, que nous aborderons ensuite.

Rappelez-vous comment dans l'exemple d'espace de prénom ci-dessus, nous avions deux personnes nommées Bob, et nous avons décrit comment les dissocier ou les distinguer en incluant le nom de famille. Mais au sein de chacun des ménages Smith et Jones séparément, chaque famille comprend « Bob » comme faisant référence à celui qui va avec ce ménage particulier. Ainsi, par exemple, dans le contexte de chaque foyer respectif, Alice n'a pas besoin de s'adresser à son mari comme Bob Jones, et Cathy n'a pas besoin de se référer à son mari comme Bob Smith :ils peuvent chacun dire simplement "Bob".

Le schéma actuel de Postgresql est un peu comme le ménage dans l'exemple ci-dessus. Les objets du schéma actuel peuvent être référencés sans qualification, mais la référence à des objets portant le même nom dans d'autres schémas nécessite de qualifier le nom en préfixant le nom du schéma comme ci-dessus.

Le schéma actuel est dérivé du paramètre de configuration "search_path". Ce paramètre stocke une liste de noms de schéma séparés par des virgules et peut être examiné avec la commande

SHOW search_path;

ou définir une nouvelle valeur avec

SET search_path TO schema [, schema, ...];

Le premier nom de schéma de la liste est le "schéma actuel" et c'est là que les nouveaux objets sont créés s'ils sont spécifiés sans qualification de nom de schéma.

La liste de noms de schéma séparés par des virgules sert également à déterminer l'ordre de recherche selon lequel le système localise les objets nommés non qualifiés existants. Par exemple, dans le quartier Smith and Jones, une livraison de colis adressée uniquement à "Bob" nécessiterait une visite dans chaque foyer jusqu'à ce que le premier résident nommé "Bob" soit trouvé. Notez que ce n'est peut-être pas le destinataire prévu. La même logique s'applique pour Postgresql. Le système recherche des tables, des vues et d'autres objets dans les schémas dans l'ordre du search_path, puis le premier objet de correspondance de nom trouvé est utilisé. Les objets nommés qualifiés par le schéma sont utilisés directement sans référence au search_path.

Dans la configuration par défaut, l'interrogation de la variable de configuration search_path révèle cette valeur

SHOW search_path;
 Search_path
--------------
 "$user", public

Le système interprète la première valeur indiquée ci-dessus comme le nom d'utilisateur actuellement connecté et prend en charge le cas d'utilisation mentionné précédemment où chaque utilisateur se voit attribuer un schéma nommé par l'utilisateur pour un espace de travail séparé des autres utilisateurs. Si aucun schéma nommé par l'utilisateur n'a été créé, cette entrée est ignorée et le schéma "public" devient le schéma actuel où de nouveaux objets sont créés.

Ainsi, revenons à notre exemple précédent de création de la table "hollywood.actors", si nous n'avions pas qualifié le nom de la table avec le nom du schéma, alors la table aurait été créée dans le schéma public. Si nous prévoyons de créer tous les objets dans un schéma spécifique, il peut être pratique de définir la variable search_path telle que

SET search_path TO hollywood,public;

facilitant la sténographie de la saisie de noms non qualifiés pour créer ou accéder à des objets de base de données.

Il existe également une fonction d'informations système qui renvoie le schéma actuel avec une requête

select current_schema();

En cas d'orthographe grossière, le propriétaire d'un schéma peut changer le nom, à condition que l'utilisateur ait également des privilèges de création pour la base de données, avec le

ALTER SCHEMA old_name RENAME TO new_name;

Et enfin, pour supprimer un schéma d'une base de données, il existe une commande drop

DROP SCHEMA schema_name;

La commande DROP échouera si le schéma contient des objets, ils doivent donc être supprimés en premier, ou vous pouvez éventuellement supprimer récursivement un schéma tout son contenu avec l'option CASCADE

DROP SCHEMA schema_name CASCADE;

Ces bases vous aideront à comprendre les schémas !