J'avais l'habitude de penser que le schéma était l'objet "wrapper supérieur" avant la base de données elle-même. Je veux dire DB.schema.<what_ever_object_name_under_schema>.
Eh bien, le catalogue "wrapper" est maintenant assez déroutant. Pourquoi devrions-nous avoir besoin d'un catalogue? Dans quel but, précisément le catalogue doit-il être utilisé?
Du point de vue relationnel:
Le catalogue est le lieu où - entre autres - sont conservés tous les différents schémas (externes, conceptuels, internes) et toutes les mappings correspondants (externe / conceptuel, conceptuel / interne).
En d'autres termes, le catalogue contient des informations détaillées (parfois appelées informations de descripteur ou métadonnées ) concernant les différents objets qui présentent un intérêt pour le système lui-même.
Par exemple, l'optimiseur utilise des informations de catalogue sur les index et autres structures de stockage physique, ainsi que de nombreuses autres informations, pour l'aider à décider comment implémenter les demandes des utilisateurs. De même, le sous-système de sécurité utilise des informations de catalogue sur les utilisateurs et les contraintes de sécurité pour accorder ou refuser ces demandes en premier lieu.
An Introduction to Database Systems, 7e éd., CJ Date, p 69-70.
Les catalogues sont des collections nommées de schémas dans un environnement SQL. Un environnement SQL contient zéro ou plusieurs catalogues. Un catalogue contient un ou plusieurs schémas, mais contient toujours un schéma nommé INFORMATION_SCHEMA qui contient les vues et les domaines du schéma d'informations.
Database Language SQL , (Texte révisé proposé du DIS 9075), p 45
Un catalogue est souvent synonyme de base de données . Dans la plupart des bases de données SQL, si vous interrogez les vues information_schema, vous constaterez que les valeurs de la colonne "table_catalog" sont mappées au nom d'une base de données.
Si vous trouvez que votre plate-forme utilise le catalogue d'une manière plus large que l'une de ces trois définitions, cela peut faire référence à quelque chose de plus large qu'une base de données - un cluster de bases de données, un serveur ou un cluster de serveurs. Mais j'en doute un peu, car vous auriez trouvé cela facilement dans la documentation de votre plate-forme.
Mike Sherrill «Cat Recall» a donné une excellente réponse . J'ajouterai simplement un exemple: Postgres .
Lorsque vous installez Postgres sur une machine, cette installation est appelée un cluster . «Cluster» ici n'est pas entendu dans le sens matériel de plusieurs ordinateurs travaillant ensemble. Dans Postgres, le cluster fait référence au fait que vous pouvez avoir plusieurs bases de données indépendantes toutes opérationnelles en utilisant le même moteur de serveur Postgres.
Le mot cluster est également défini par le SQL Standard de la même manière que dans Postgres. Suivre de près le standard SQL est un objectif principal du projet Postgres.
La spécification SQL-92 dit:
Un cluster est une collection de catalogues définie par l'implémentation.
et
Un seul cluster est associé à une session SQL
C'est une manière obtuse de dire qu'un cluster est un serveur de base de données (chaque catalogue est une base de données).
Donc, à la fois dans Postgres et dans SQL Standard, nous avons cette hiérarchie de confinement:
Ce diagramme représente un seul cluster. Dans le cas de Postgres, vous pouvez avoir plus d'un cluster par ordinateur hôte (ou système d'exploitation virtuel). Plusieurs clusters sont couramment utilisés pour tester et déployer de nouvelles versions de Postgres (ex: 9.0 , 9.1 , 9.2 , 9.3 , 9.4 , 9.5 ).
Si vous aviez plusieurs clusters, imaginez le diagramme ci-dessus dupliqué.
Différents numéros de port permettent aux multiples clusters de vivre côte à côte, tous opérationnels en même temps. Chaque cluster se verrait attribuer son propre numéro de port. L'habitude 5432n'est que la valeur par défaut et peut être définie par vous. Chaque cluster écoute sur son propre port attribué les connexions entrantes à la base de données.
Par exemple, une entreprise peut avoir deux équipes de développement logiciel différentes. L'un écrit des logiciels pour gérer les entrepôts tandis que l'autre équipe construit des logiciels pour gérer les ventes et le marketing. Chaque équipe de développement a sa propre base de données, ignorant parfaitement celle de l'autre.
Mais l'équipe des opérations informatiques a pris la décision d'exécuter les deux bases de données sur un seul ordinateur (Linux, Mac, peu importe). Donc, sur cette boîte, ils ont installé Postgres. Donc, un serveur de base de données (cluster de bases de données). Dans ce cluster, ils créent deux catalogues, un catalogue pour chaque équipe de développement: un nommé «entrepôt» et un nommé «ventes».
Chaque équipe de développement utilise plusieurs dizaines de tables avec des objectifs et des rôles d'accès différents. Ainsi, chaque équipe de développement organise ses tables en schémas. Par coïncidence, les deux équipes de développement effectuent un suivi des données comptables, de sorte que chaque équipe a un schéma nommé «comptabilité». L'utilisation du même nom de schéma n'est pas un problème car les catalogues ont chacun leur propre espace de noms donc pas de collision.
En outre, chaque équipe crée finalement un tableau à des fins comptables appelé «grand livre». Encore une fois, pas de collision de noms.
Vous pouvez considérer cet exemple comme une hiérarchie…
Postgres 9.2 cluster (installation)
warehouse catalogue (base de données)
inventory schéma
accounting schéma
ledger tablesales catalogue (base de données)
selling schéma
accounting schéma (même nom coïncident que ci-dessus)
ledger table (même nom que ci-dessus)Postgres 9.3 grappe
Le logiciel de chaque équipe de développement établit une connexion au cluster. Ce faisant, ils doivent spécifier le catalogue (base de données) qui leur appartient. Postgres nécessite que vous vous connectiez à un catalogue, mais vous n'êtes pas limité à ce catalogue. Ce catalogue initial est simplement un catalogue par défaut, utilisé lorsque vos instructions SQL omettent le nom d'un catalogue.
Donc, si l'équipe de développement a besoin d'accéder aux tables de l'autre équipe, elle peut le faire si l'administrateur de la base de données leur a donné les privilèges pour le faire. L'accès se fait avec un nom explicite dans le modèle: catalog.schema.table . Donc, si l'équipe «entrepôt» a besoin de voir le grand livre de l'autre équipe (équipe «ventes»), elle écrit des instructions SQL avec sales.accounting.ledger. Pour accéder à leur propre registre, ils écrivent simplement accounting.ledger. S'ils accèdent aux deux registres dans le même morceau de code source, ils peuvent choisir d'éviter toute confusion en incluant leur propre nom de catalogue (facultatif), warehouse.accounting.ledgerpar opposition à sales.accounting.ledger.
Au fait…
Vous pouvez entendre le mot schéma utilisé dans un sens plus général, signifiant la conception entière de la structure de table d'une base de données particulière. En revanche, dans la norme SQL, le mot signifie spécifiquement la couche particulière de la Cluster > Catalog > Schema > Tablehiérarchie.
Postgres utilise à la fois la base de données de mots et le catalogue à divers endroits, comme la commande CREATE DATABASE .
Tous les systèmes de base de données ne fournissent pas cette hiérarchie complète de Cluster > Catalog > Schema > Table. Certains n'ont qu'un seul catalogue (base de données). Certains n'ont pas de schéma, juste un ensemble de tables. Postgres est un produit exceptionnellement puissant.
...Catalog > Schema..., quelqu'un peut-il me dire pourquoi les nœuds "Catalogue" et "Schema" dans pgAdmin (interface utilisateur PostgreSQL) sont des nœuds frères, au lieu du nœud Schema en tant que nœud enfant de Catalog?PostgreSQL (pg_catalog), le catalogue du système, les dizaines de tables de « pg_ » qui stockent les définitions de métadonnées de vos bases de données, telles quepg_index,pg_triggeretpg_constraint. (2)ANSI (information_schema), la vue en lecture seule de ce même catalogue système défini par la norme SQL commeinformation_schema. Un meilleur nom pour le nœud "Catalogues" dans pgAdmin pourrait être "System" ou "System Tables".