Solía pensar que el esquema era el objeto "contenedor superior" antes de la base de datos. Me refiero DB.schema.<what_ever_object_name_under_schema>.
Bueno, el "contenedor" del catálogo ahora es bastante confuso. ¿Por qué deberíamos necesitar un catálogo? ¿Con qué finalidad, precisamente, debería utilizarse el catálogo?
Respuestas:
Desde el punto de vista relacional:
El catálogo es el lugar donde, entre otras cosas, se guardan todos los esquemas (externos, conceptuales, internos) y todas las asignaciones correspondientes (externas / conceptuales, conceptuales / internas).
En otras palabras, el catálogo contiene información detallada (a veces denominada información descriptiva o metadatos ) sobre los diversos objetos que son de interés para el propio sistema.
Por ejemplo, el optimizador utiliza 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. Asimismo, el subsistema de seguridad utiliza información de catálogo sobre usuarios y restricciones de seguridad para otorgar o denegar tales solicitudes en primer lugar.
Una introducción a los sistemas de bases de datos, 7ª ed., CJ Date, p 69-70.
Los catálogos son colecciones de esquemas con nombre 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 dominios del esquema de información.
Lenguaje de base de datos SQL , (texto revisado propuesto de DIS 9075), p 45
Un catálogo es a menudo sinónimo de base de datos . En la mayoría de las bases de datos SQL, si consulta las vistas de esquema de información, encontrará que los valores de la columna "catálogo_tabla" se asignan al nombre de una base de datos.
Si encuentra que su plataforma utiliza el catálogo de una manera más amplia que cualquiera de estas tres definiciones, puede que se refiera a algo más amplio que una base de datos: un grupo de bases de datos, un servidor o un grupo de servidores. Pero lo dudo un poco, ya que lo habría encontrado fácilmente en la documentación de su plataforma.
Mike Sherrill 'Cat Recall' dio una excelente respuesta . Agregaré simplemente un ejemplo: Postgres .
Cuando instala Postgres en una máquina, esa instalación se denomina clúster . "Clúster" aquí no se entiende en el sentido de hardware de varias computadoras trabajando juntas. En Postgres, clúster se refiere al hecho de que puede tener varias bases de datos no relacionadas en funcionamiento utilizando el mismo motor de servidor de Postgres.
El estándar SQL también define la palabra clúster 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 definida por la implementación.
y
Exactamente un clúster está asociado con una sesión 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).
Entonces, tanto en Postgres como en SQL Standard tenemos esta jerarquía de contención:
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). Se suelen realizar 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 tuvieras varios clústeres, 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, todos en funcionamiento al mismo tiempo. A cada clúster se le asignará su propio número de puerto. Lo habitual 5432es solo el predeterminado y puede configurarlo usted. Cada clúster escucha en su propio puerto asignado las conexiones entrantes de la base de datos.
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 inconsciente de la del otro.
Pero el equipo de operaciones de TI tomó la decisión de ejecutar ambas bases de datos en una sola 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 grupo, 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 realizan 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 espacio de nombres, por lo que no hay colisión.
Además, cada equipo crea finalmente una tabla con fines contables denominada "libro mayor". Una vez más, no hay colisión de nombres.
Puede pensar en este ejemplo como una jerarquía ...
Postgres 9.2 cluster (instalación)
warehouse catálogo (base de datos)
inventory esquema
accounting esquema
ledger mesasales catálogo (base de datos)
selling esquema
accounting esquema (coincidente con el mismo nombre que el anterior)
ledger tabla (coincide con el mismo nombre que el anterior)Postgres 9.3 racimo
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 se conecte a un catálogo, pero no está limitado a ese catálogo. Ese catálogo inicial es simplemente un predeterminado, utilizado cuando sus declaraciones 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 privilegios 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 SQL con sales.accounting.ledger. Para acceder a su propio libro mayor, simplemente escriben accounting.ledger. Si acceden a ambos libros mayores en el mismo código fuente, pueden optar por evitar confusiones al incluir su propio nombre de catálogo (opcional), warehouse.accounting.ledgerversus sales.accounting.ledger.
Por cierto…
Es posible que escuche la palabra esquema utilizada en un sentido más general, es decir, el diseño completo de la estructura de 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 Cluster > Catalog > Schema > Tablejerarquía.
Postgres usa tanto la base de datos de palabras como el catálogo en varios lugares, como el comando CREATE DATABASE .
No todos los sistemas de bases de datos proporcionan esta jerarquía completa de Cluster > Catalog > Schema > Table. Algunos tienen un solo catálogo (base de datos). Algunos no tienen esquema, solo un conjunto de tablas. Postgres es un producto excepcionalmente poderoso.
PostgreSQL (pg_catalog), el catálogo del sistema, las docenas de tablas "pg_" que almacenan las definiciones de metadatos de sus bases de datos, tales como pg_index, pg_trigger, y pg_constraint. (2) ANSI (information_schema), la vista de solo lectura del mismo catálogo de sistema definido por el estándar SQL como information_schema. Un mejor nombre para el nodo "Catálogos" en pgAdmin podría ser "Sistema" o "Tablas del sistema".
...Catalog > Schema..., ¿alguien puede decirme por qué los nodos "Catálogo" y "Esquema" en pgAdmin (interfaz de usuario de PostgreSQL) son nodos hermanos, en lugar del nodo Esquema como nodo secundario del catálogo?