Quelle est la différence entre un catalogue et un schéma dans une base de données relationnelle?


96

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é?

Réponses:


73

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.


Du point de vue standard SQL:

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


Du point de vue SQL:

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.


177

Mike Sherrill «Cat Recall» a donné une excellente réponse . J'ajouterai simplement un exemple: Postgres .

Cluster = Une installation 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).

Cluster> Catalogue> Schéma> Tableau> Colonnes et lignes

Donc, à la fois dans Postgres et dans SQL Standard, nous avons cette hiérarchie de confinement:

  • Un ordinateur peut avoir un cluster ou plusieurs.
  • Un serveur de base de données est un cluster .
  • Un cluster a des catalogues . (Catalogue = Base de données)
  • Les catalogues ont des schémas . (Schéma = espace de noms des tables et limite de sécurité)
  • Les schémas ont des tables .
  • Les tableaux ont des lignes .
  • Les lignes ont des valeurs , définies par des colonnes .
    Ces valeurs sont les données commerciales dont vos applications et vos utilisateurs se soucient, telles que le nom de la personne, la date d'échéance de la facture, le prix du produit, le score élevé du joueur. La colonne définit le type de données des valeurs (texte, date, nombre, etc.).

Diagramme montrant des nichoirs représentant comment la connexion sur un port vous amène à un cluster (un serveur de base de données) qui contient un ou plusieurs catalogues (une base de données) dont chacun contient un ou plusieurs schémas (un espace de noms) dont chacun contient des tables dont chacune a Lignes.

Plusieurs clusters

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.

Exemple de scénario

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…

  • Ordinateur (boîtier matériel ou serveur virtualisé)
    • Postgres 9.2 cluster (installation)
      • warehouse catalogue (base de données)
        • inventory schéma
          • [… des tables]
        • accounting schéma
          • ledger table
          • [… Quelques autres tableaux]
      • sales catalogue (base de données)
        • selling schéma
          • [… des tables]
        • accounting schéma (même nom coïncident que ci-dessus)
          • ledger table (même nom que ci-dessus)
          • [… Quelques autres tableaux]
    • Postgres 9.3 grappe
      • [… Autres schémas et tableaux]

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.


8
Si c'est le cas ...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?
The Red Pea

6
Ce nœud "Schéma" est le vôtre, mais le nœud "Catalogues" ne l'est pas. Le noeud « Catalogs » a exactement deux éléments: (1) 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 que pg_index, pg_triggeret pg_constraint. (2) ANSI (information_schema), la vue en lecture seule de ce même catalogue système défini par la norme SQL comme information_schema. Un meilleur nom pour le nœud "Catalogues" dans pgAdmin pourrait être "System" ou "System Tables".
Basil Bourque

Merci. "Tous les systèmes de base de données ne fournissent pas cette hiérarchie complète de Cluster> Catalogue> Schéma> Table." Je me demande à quoi cela ressemble pour mysql et SQL Server?
Tim

+1. Toutes les tables d'un schéma ont-elles le même schéma relationnel (c'est-à-dire le même ensemble d'attributs et / ou le même ensemble de contraintes)? Pourriez-vous également voir ma question stackoverflow.com/questions/48232448/... ? Merci.
Tim

1
@Tim Un schéma est juste un espace de noms séparant des groupes de tables, comme les dossiers sont un espace de noms organisant les fichiers dans un système de fichiers (sauf pas d'imbrication de schémas). Les tableaux stockent les données de votre application sous forme d'attributs / colonnes par ligne.
Basil Bourque
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.