database - ver - ¿Cuál es la diferencia entre un catálogo y un esquema en una base de datos relacional?

tablas catalogo sql server (2)

Desde el punto de vista relacional:

El catálogo es el lugar donde, entre otras cosas, se guardan todos los diversos esquemas (externo, conceptual, interno) y todos los mapeos correspondientes (externo / conceptual, conceptual / interno).
En otras palabras, el catálogo contiene información detallada (a veces llamada información del descriptor o metadatos ) con respecto a los diversos objetos que son de interés para el sistema en sí.
Por ejemplo, el optimizador usa información de catálogo sobre índices y otras estructuras de almacenamiento físico, así como mucha otra información, para ayudarlo a decidir cómo implementar las solicitudes de los usuarios. Del mismo modo, el subsistema de seguridad usa información de catálogo sobre usuarios y restricciones de seguridad para otorgar o denegar dichas solicitudes en primer lugar.

Una Introducción a los Sistemas de Bases de Datos, 7ma ed., CJ Date, p 69-70.

Desde el punto de vista estándar de SQL:

Los catálogos se denominan colecciones de esquemas en un entorno SQL. Un entorno SQL contiene cero o más catálogos. Un catálogo contiene uno o más esquemas, pero siempre contiene un esquema llamado INFORMATION_SCHEMA que contiene las vistas y los dominios del esquema de información.

Lenguaje de la base de datos SQL , (Texto revisado propuesto de DIS 9075), p 45

Desde el punto de vista de SQL:

Un catálogo es a menudo sinónimo de base de datos . En la mayoría de SQL dbms, si consultas las vistas de información_schema, encontrarás que los valores en el mapa de la columna "table_catalog" corresponden al nombre de una base de datos.
Si encuentra su plataforma utilizando el catálogo de una manera más amplia que cualquiera de estas tres definiciones, podría estar refiriéndose a algo más amplio que una base de datos: un clúster de base de datos, un servidor o un clúster de servidores. Pero lo dudo, ya que lo encontraría fácilmente en la documentación de su plataforma.

Solía pensar que el esquema era el objeto "envoltorio superior" antes de la base de datos. Quiero decir DB.schema.<what_ever_object_name_under_schema> .

Bueno, el "envoltorio" del catálogo ahora es bastante confuso. ¿Por qué deberíamos necesitar un catálogo? ¿Para qué propósito, exactamente debe usarse el catálogo?

dio una excelente respuesta . Añadiré simplemente un ejemplo: Postgres .

Cluster = Una instalación de Postgres

Cuando instala Postgres en una máquina, esa instalación se llama clúster . ''Clúster'' aquí no se refiere al sentido del hardware de múltiples computadoras trabajando juntas. En Postgres, el clúster se refiere al hecho de que puede crear múltiples bases de datos no relacionadas, todas funcionando con el mismo motor de servidor de Postgres.

La palabra cluster también está definida por el SQL Standard de la misma manera que en Postgres. Seguir de cerca el estándar SQL es un objetivo principal del proyecto Postgres.

La especificación SQL-92 dice:

Un clúster es una colección de catálogos definidos por la implementación.

Exactamente un clúster está asociado a una sesión de SQL

Esa es una forma obtusa de decir que un clúster es un servidor de base de datos (cada catálogo es una base de datos).

Clúster> Catálogo> Esquema> Tabla> Columnas y filas

Entonces, tanto en Postgres como en el Estándar SQL tenemos esta jerarquía de contención:

Una computadora puede tener un clúster o múltiple.
Un servidor de base de datos es un clúster .
Un clúster tiene catalogs . (Catálogo = Base de datos)
Los catálogos tienen schemas . (Esquema = namespace de namespace de tablas y límite de seguridad)
Los esquemas tienen tables .
Las tablas tienen rows .
Las filas tienen valores , definidos por columns .
Esos valores son los datos comerciales que a sus aplicaciones y usuarios les importan, como el nombre de la persona, la fecha de vencimiento de la factura, el precio del producto y el puntaje más alto del jugador. La columna define el tipo de datos de los valores (texto, fecha, número, etc.).

Múltiples clusters

Este diagrama representa un solo grupo. En el caso de Postgres, puede tener más de un clúster por computadora host (o sistema operativo virtual). Generalmente, se realizan varios clústeres para probar e implementar nuevas versiones de Postgres (por ejemplo, 9.0 , 9.1 , 9.2 , 9.3 , 9.4 , 9.5 ).

Si tienes múltiples clusters, imagina el diagrama de arriba duplicado.

Los diferentes números de puerto permiten que los múltiples clústeres vivan uno al lado del otro y estén funcionando al mismo tiempo. A cada grupo se le asignaría su propio número de puerto. El 5432 habitual es solo el predeterminado, y usted puede configurarlo. Cada clúster está escuchando en su propio puerto asignado para conexiones de base de datos entrantes.

Ejemplo de escenario

Por ejemplo, una empresa podría tener dos equipos de desarrollo de software diferentes. Uno escribe software para administrar los almacenes mientras que el otro equipo crea software para administrar las ventas y el marketing. Cada equipo de desarrollo tiene su propia base de datos, felizmente ajena a la del otro.

Pero el equipo de operaciones de TI tomó la decisión de ejecutar ambas bases de datos en una sola caja de computadora (Linux, Mac, lo que sea). Entonces en esa caja instalaron Postgres. Entonces un servidor de base de datos (clúster de base de datos). En ese clúster, crean dos catálogos, un catálogo para cada equipo de desarrollo: uno llamado ''almacén'' y otro llamado ''ventas''.

Cada equipo de desarrollo usa muchas docenas de tablas con diferentes propósitos y roles de acceso. Entonces cada equipo de desarrollo organiza sus tablas en esquemas. Por coincidencia, ambos equipos de desarrollo hacen un seguimiento de los datos contables, por lo que cada equipo tiene un esquema llamado ''contabilidad''. Usar el mismo nombre de esquema no es un problema porque los catálogos tienen cada uno su propio namespace para que no haya colisión.

Además, cada equipo finalmente crea una tabla para fines contables denominada ''libro mayor''. De nuevo, no hay colisión de nombres.

Puedes pensar en este ejemplo como una jerarquía ...

Computadora (caja de hardware o servidor virtualizado)
- Clúster Postgres 9.2 (instalación)
  - catálogo de warehouse (base de datos)
    - esquema de inventory
      - [… algunas mesas]
    - esquema accounting
      - mesa de ledger
      - [... algunas otras tablas]
  - catálogo de sales (base de datos)
    - esquema de selling
      - [… algunas mesas]
    - esquema accounting (el mismo nombre coincidente que el anterior)
      - tabla de ledger (coincidente mismo nombre que el anterior)
      - [... algunas otras tablas]
- Clúster de Postgres 9.3
  - [... otros esquemas y tablas]

El software de cada equipo de desarrollo establece una conexión con el clúster. Al hacerlo, deben especificar qué catálogo (base de datos) es suyo. Postgres requiere que te conectes a un catálogo, pero no estás limitado a ese catálogo. Ese catálogo inicial es simplemente un valor predeterminado, que se usa cuando las instrucciones SQL omiten el nombre de un catálogo.

Entonces, si el equipo de desarrollo alguna vez necesita acceder a las tablas del otro equipo, puede hacerlo si el administrador de la base de datos les ha otorgado privileges para hacerlo. El acceso se realiza con nombres explícitos en el patrón: catalog.schema.table . Entonces, si el equipo de ''almacén'' necesita ver el libro mayor del otro equipo (''equipo de ventas''), escriben declaraciones de SQL con sales.accounting.ledger . Para acceder a su propio libro mayor, simplemente escriben accounting.ledger . Si acceden a ambos libros en el mismo código fuente, pueden optar por evitar confusiones incluyendo su propio nombre de catálogo (opcional), warehouse.accounting.ledger versus sales.accounting.ledger .

Por cierto…

Puede escuchar la palabra esquema utilizado en un sentido más general, es decir, todo el diseño de la estructura de la tabla de una base de datos en particular. Por el contrario, en el estándar SQL, la palabra significa específicamente la capa particular en la jerarquía Cluster > Catalog > Schema > Table .

Postgres usa tanto la base de datos de palabras como el catálogo en varios lugares, como el comando CREATE DATABASE .

No todo el sistema de base de datos proporciona esta jerarquía completa de Cluster > Catalog > Schema > Table . Algunos tienen solo un catálogo (base de datos). Algunos no tienen esquema, solo un conjunto de tablas. Postgres es un producto excepcionalmente poderoso.