Eu costumava pensar que o esquema era o objeto de "invólucro superior" antes do próprio banco de dados. Quero dizer DB.schema.<what_ever_object_name_under_schema>.
Bem, o "invólucro" do catálogo agora é bastante confuso. Por que precisamos de um catálogo? Para que propósito, exatamente o catálogo deve ser usado?
Respostas:
Do ponto de vista relacional:
O catálogo é o lugar onde - entre outras coisas - todos os vários esquemas (externo, conceitual, interno) e todos os mapeamentos correspondentes (externo / conceitual, conceitual / interno) são mantidos.
Em outras palavras, o catálogo contém informações detalhadas (às vezes chamadas de informações do descritor ou metadados ) sobre os vários objetos de interesse do próprio sistema.
Por exemplo, o otimizador usa informações de catálogo sobre índices e outras estruturas de armazenamento físico, bem como muitas outras informações, para ajudá-lo a decidir como implementar as solicitações do usuário. Da mesma forma, o subsistema de segurança usa informações de catálogo sobre usuários e restrições de segurança para conceder ou negar tais solicitações em primeiro lugar.
An Introduction to Database Systems, 7ª ed., CJ Date, p 69-70.
Os catálogos são coleções nomeadas de esquemas em um ambiente SQL. Um ambiente SQL contém zero ou mais catálogos. Um catálogo contém um ou mais esquemas, mas sempre contém um esquema denominado INFORMATION_SCHEMA que contém as visualizações e domínios do Esquema de Informações.
Linguagem de banco de dados SQL , (texto revisado proposto do DIS 9075), p 45
Um catálogo geralmente é sinônimo de banco de dados . Na maioria dos dbms SQL, se você consultar as visualizações information_schema, você encontrará que os valores na coluna "table_catalog" são mapeados para o nome de um banco de dados.
Se você encontrar sua plataforma usando catálogo de uma forma mais ampla do que qualquer uma dessas três definições, pode estar se referindo a algo mais amplo do que um banco de dados - um cluster de banco de dados, um servidor ou um cluster de servidor. Mas eu meio que duvido disso, já que você teria encontrado isso facilmente na documentação da sua plataforma.
Mike Sherrill 'Cat Recall' deu uma resposta excelente . Vou adicionar apenas um exemplo: Postgres .
Quando você instala o Postgres em uma máquina, essa instalação é chamada de cluster . 'Cluster' aqui não significa no sentido de hardware de vários computadores trabalhando juntos. No Postgres, cluster se refere ao fato de que você pode ter vários bancos de dados não relacionados, todos ativos e em execução, usando o mesmo mecanismo de servidor Postgres.
A palavra cluster também é definida pelo SQL Standard da mesma forma que no Postgres. Seguir de perto o padrão SQL é o objetivo principal do projeto Postgres.
A especificação SQL-92 diz:
Um cluster é uma coleção de catálogos definida pela implementação.
e
Exatamente um cluster está associado a uma sessão SQL
Essa é uma maneira obtusa de dizer que um cluster é um servidor de banco de dados (cada catálogo é um banco de dados).
Portanto, tanto no Postgres quanto no SQL Standard, temos esta hierarquia de contenção:
Este diagrama representa um único cluster. No caso do Postgres, você pode ter mais de um cluster por computador host (ou sistema operacional virtual). Geralmente, vários clusters são feitos para testar e implantar novas versões do Postgres (ex: 9.0 , 9.1 , 9.2 , 9.3 , 9.4 , 9.5 ).
Se você tiver vários clusters, imagine o diagrama acima duplicado.
Números de porta diferentes permitem que vários clusters vivam lado a lado, todos ativos e em execução ao mesmo tempo. Cada cluster teria seu próprio número de porta atribuído. O usual 5432é apenas o padrão e pode ser definido por você. Cada cluster está escutando em sua própria porta atribuída para conexões de banco de dados de entrada.
Por exemplo, uma empresa pode ter duas equipes de desenvolvimento de software diferentes. Um escreve software para gerenciar os depósitos, enquanto a outra equipe desenvolve software para gerenciar vendas e marketing. Cada equipe de desenvolvimento tem seu próprio banco de dados, felizmente inconsciente do outro.
Mas a equipe de operações de TI decidiu executar os dois bancos de dados em uma única caixa de computador (Linux, Mac, qualquer que seja). Então, naquela caixa, eles instalaram o Postgres. Portanto, um servidor de banco de dados (cluster de banco de dados). Nesse cluster, eles criam dois catálogos, um catálogo para cada equipe de desenvolvimento: um denominado 'warehouse' e outro denominado 'vendas'.
Cada equipe de desenvolvimento usa muitas dezenas de tabelas com diferentes propósitos e funções de acesso. Portanto, cada equipe de desenvolvimento organiza suas tabelas em esquemas. Por coincidência, as duas equipes de desenvolvimento fazem algum rastreamento dos dados contábeis, de modo que cada equipe possui um esquema denominado 'contabilidade'. Usar o mesmo nome de esquema não é um problema porque cada um dos catálogos tem seu próprio namespace, portanto, nenhuma colisão.
Além disso, cada equipe eventualmente cria uma tabela para fins contábeis denominada 'razão'. Novamente, nenhuma colisão de nomenclatura.
Você pode pensar neste exemplo como uma hierarquia ...
Postgres 9.2 cluster (instalação)
warehouse catálogo (banco de dados)
inventory esquema
accounting esquema
ledger tabelasales catálogo (banco de dados)
selling esquema
accounting esquema (coincidente com o mesmo nome acima)
ledger tabela (coincidente com o mesmo nome acima)Postgres 9.3 grupo
O software de cada equipe de desenvolvimento faz uma conexão com o cluster. Ao fazer isso, eles devem especificar qual catálogo (banco de dados) é deles. O Postgres requer que você se conecte a um catálogo, mas você não está limitado a esse catálogo. Esse catálogo inicial é apenas um padrão, usado quando suas instruções SQL omitem o nome de um catálogo.
Portanto, se a equipe de desenvolvimento precisar acessar as tabelas da outra equipe, ela poderá fazê-lo se o administrador do banco de dados tiver concedido privilégios para isso. O acesso é feito com nomenclatura explícita no padrão: catalog.schema.table . Portanto, se a equipe de 'warehouse' precisar ver o livro razão da outra equipe (equipe de 'vendas'), ela escreverá instruções SQL com sales.accounting.ledger. Para acessar seu próprio livro-razão, eles simplesmente escrevem accounting.ledger. Se eles acessarem ambos os livros contábeis na mesma parte do código-fonte, eles podem escolher evitar confusão incluindo seu próprio nome de catálogo (opcional), warehouse.accounting.ledgerversus sales.accounting.ledger.
A propósito…
Você pode ouvir a palavra esquema usada em um sentido mais geral, significando todo o design da estrutura de tabela de um banco de dados específico. Em contraste, no SQL Standard a palavra significa especificamente a camada particular na Cluster > Catalog > Schema > Tablehierarquia.
O Postgres usa tanto o banco de dados de palavras quanto o catálogo em vários lugares, como o comando CREATE DATABASE .
Nem todo sistema de banco de dados fornece essa hierarquia completa de Cluster > Catalog > Schema > Table. Alguns possuem apenas um único catálogo (banco de dados). Alguns não têm esquema, apenas um conjunto de tabelas. Postgres é um produto excepcionalmente poderoso.
PostgreSQL (pg_catalog), o catálogo do sistema, as dezenas de tabelas "pg_" que armazenam as definições de metadados de seus bancos de dados, tais como pg_index, pg_trigger, e pg_constraint. (2) ANSI (information_schema), a visualização somente leitura desse mesmo catálogo de sistema definido pelo padrão SQL como information_schema. Um nome melhor para o nó "Catálogos" no pgAdmin pode ser "Sistema" ou "Tabelas do sistema".
...Catalog > Schema..., alguém pode me dizer por que os nós "Catálogo" e "Esquema" no pgAdmin (IU PostgreSQL) são nós irmãos, em vez de nó Esquema como um nó filho do Catálogo?