Esse artigo faz parte da revista SQL Magazine edição 57. Clique aqui para ler todos os artigos desta edição
di-font-style: normal">schema, em inglês).
O termo “esquema” já é bastante usado no universo da modelagem de dados (relacional ou não). Mas esta expressão aparece com significados muito diversos, o que torna as coisas um tanto confusas. De qualquer modo, o SQL SERVER usa o termo “esquema” para identificar um recurso semelhante ao que existe no DB2 e no ORACLE.
Apesar desta questão de nomenclatura, não dá para negar que esta abstração do conceito de esquema é extremamente útil, pelas razões que veremos neste artigo. Além disso, o uso de esquemas veio para ficar: o SQL Server 2008 também usará o mesmo conceito.
Vamos, a seguir, explorar os detalhes desta idéia.
O que é Esquema
A palavra esquema faz parte do universo de bancos de dados e tem múltiplos usos.
Quando falamos “esquema do banco de dados” estamos nos referindo aos documentos que mapeiam o projeto do banco de dados em si. Temos o esquema conceitual, o esquema lógico e esquema físico, por exemplo. Eles definem os objetos do banco de dados (tabelas, visões, campos, processos e relacionamentos) e fazem parte do dicionário de dados da base.
Apoiado nesta definição, temos o conceito do objeto esquema (ou Schema, se preferir). Este objeto diz respeito à “estrutura lógica de armazenamento de dados”, como se pode ver na Wikipedia. Praticamente todos os principais sistemas gerenciadores de bancos de dados (SGBDs) incorporam objetos deste tipo. É importante destacar que este conceito de esquema é parte do padrão ANSI-SQL.
Neste sentido, um esquema diz respeito a uma coleção de objetos normalmente associados pelas características de negócio para as quais se destinam.
Por exemplo: podemos ter dentro de um banco de dados um esquema Vendas. Este esquema incluirá tabelas, visões, gatilhos, funções e procedimentos armazenados relacionados às operações comerciais da empresa (ou seja, operações de vendas).
Assim, o objeto esquema procura representar uma coleção de objetos prevista no modelo (físico e/ou lógico) do banco de dados. Em outras palavras, o objeto esquema ajuda a agrupar objetos que dizem respeito a áreas de interesse comum dentro do modelo do banco de dados.
A propósito, existem também os esquemas XML. Estes representam um mapeamento das marcações (tags) e tipos de dados aceitos dentro de um arquivo XML. Quando um arquivo XML faz referência a um esquema XML específico, este último ajudará a validar o conteúdo do arquivo. A idéia do esquema XML é muito semelhante ao conceito de esquema físico do banco de dados.
Estes exemplos mostram os diversos usos da palavra esquema. Mas não vamos nos estender sobre detalhes de cada um destes conceitos.
Na realidade, eu os apresentei para justificar minha opinião: considero o nome “esquema” inapropriado para a funcionalidade que veremos a seguir. O recurso é muito importante, mas este nome causa confusão com conceitos e funcionalidades muito diferentes dentro do universo dos bancos de dados.
Conceito de Esquema no SQL Server
A partir deste ponto, usaremos o termo “esquema” para nos referirmos especificamente a um objeto esquema.
Em vários SGBDs (como SQL Server 2000 e Oracle), a idéia de esquema se confunde com o usuário proprietário do esquema. Na verdade, o esquema tem o nome do usuário a quem ele pertence. Por exemplo: ao usarmos um qualificador completo para o objeto, devemos usar a sintaxe:
NomeDoServidor.NomeDoBanco.NomeDoEsquema.NomeDoObjeto
Mas o que realmente fazemos nestes bancos é trocar o nome do esquema pelo nome do proprietário do objeto (owner).
Esta estratégia causa alguns problemas para os DBAs. Em primeiro lugar, um usuário nunca pode ser excluído se ele for proprietário de objetos do banco. Portanto, é preciso identificar todos os objetos que o usuário possui, transferi-los para outro usuário/esquema e só depois disso pode-se excluir o usuário da base.
Outro problema: é muito mais intuitivo reconhecer para que serve um objeto com o nome ...
