Júlio Battisti Livros e Cursosa sua sala de aula na internet

O SQL Server 2005 introduziu uma importante mudança no modelo de segurança, em relação ao SQL Server 2000: A separação entre usuários e o Schema. Para que o amigo leitor não fique perdido e possa entender bem o que é um Schema e qual foi a mudança introduzida pelo SQL Server 2005, vamos, inicialmente, definir alguns conceitos importantes e, depois, mostrar como estes conceitos se relacionam com a segurança e com a definição de Schema.

O primeiro conceito que temos que conhecer é o conceito de Principal. Um principal é considerado qualquer objeto que possa solicitar acesso a recursos do SQL Server 2005. Sob este ponto de vista, usuários, grupos de usuários e processos podem ser considerados como Principals. Uma outra definição, mais voltada para banco de dados, seria que um Principal é qualquer objeto, para o qual possa se definir permissões de acesso (ou negá-las) para os objetos de um banco de dados. Sob este ponto de vista, seriam Principals, objetos tais como usuários e grupos do Windows, logins e roles do SQL Server 2005, e applications roles. Como eu gosto de simplificar ainda mais, em termos desta discussão, vou considerar como Principals, usuários ou grupos, do Windows ou do SQL Server 2005.

Muito bem. Conhecido o conceito de Principals é hora de conhecermos um pouco mais sobre outro importante conceito: Schema. No SQL Server 2000 o conceito de Schema era praticamente ignorado, já para o modelo de segurança do SQL Server 2005, este conceito é de fundamental importância. Então vamos a ele.

Pelos padrões de definição do Ansi SQL-92, um Schema é um conjunto de objetos, sendo que todos os objetos pertencentes a um Schema, tem como dono o mesmo Principal. Em outras palavras, dentro de um Schema, todos os objetos pertencentes ao schema, tem como dono do objeto, o mesmo usuário ou grupo (roles se for um grupo do SQL Server 2005). De uma maneira ainda mais simples, podemos definir um Schema, como sendo um Container para outros objetos, de tal maneira que todos os objetos contidos em um Schema, tem o mesmo dono. Outra característica importante do Schema, é que ele deve formar um espaço de nomes. O que significa formar um espaço de nomes?? Significa que o nome de cada objeto, dentro do espaço de nomes, deve ser único. Ou traduzindo, não pode haver dois objetos, com o mesmo nome, dentro do mesmo Schema. Por exemplo, duas tabelas somente poderão ter o mesmo nome, se pertencerem a Schemas diferentes.

No SQL Server 2000 não havia uma separação entre o conceito de Usuário e Schema. No SQL Server 2000, todo usuário, é o dono de um Schema, o qual tem o mesmo nome do usuário. Por exemplo, o usuário jsilva, automaticamente, é configurado como dono de um Schema chamado jsilva. O mesmo é válido para todos os usuários do SQL Server 2000. Com esta ligação, o dono de um objeto é exatamente o mesmo dono do Schema que contém o objeto. Por isso que, no SQL Server 2000, antes de poder excluir um usuário, você tinha que excluir todos os objetos dos quais o usuário era o dono ou teria que alterar o dono de todos estes objetos. Por exemplo, considere o objeto a seguir (lê-se de trás para frente: tabela clientes, cujo dono é o usuário jsilva, tabela esta pertencente ao banco de dados vendas, do servidor “servidor”), pertencente a um banco de dados do SQL Server 2000:

servidor.vendas.jsilva.clientes

Neste exemplo, o dono da tabela Clientes é o usuário jsilva. Se o Administrador do banco de dados precisar excluir o usuário jsilva, ele terá que, primeiro, excluir este e todos os demais objetos para os quais o usuário jsilva é o dono ou terá que alterar o dono destes objetos. Um trabalho e tanto, convenhamos. Por exemplo, o Administrador poderia alterar o dono da tabela clientes, para que ao invés do usuário jsilva, o novo dono fosse o usuário pedro. Com isso, o nome completo do nosso objeto, ficaria assim:

servidor.vendas.pedro.clientes

Observe que ao alterar o dono do objeto, o nome completo do objeto também se altera, passando de servidor.vendas.jsilva.clientes para servidor.vendas.pedro.clientes. Este era um problemão que existia no SQL Server 2000. Pois ao alterar o nome completo de um objeto, qualquer programa, cujo código faça referência ao nome completo do objeto, terá que ser alterado. Vejam que uma simples renomeação de objeto, pode gerar uma grande carga de trabalho, com a necessidade de revisão do código das aplicações, geração de novas versões atualizadas e instalação destas versões nos clientes. Um senhor trabalho.

Bem, felizmente isso tudo mudou no SQL Server 2005. No SQL Server 2005 todos os objetos de um banco de dados tem como dono um Schema. Nenhum objeto de banco de dados pode ter como dono, um usuário ou grupo (Principal seria o nome técnico, mas estou utilizando o termo usuário ou grupo). Os usuários são donos de Schemas e não mais diretamente de objetos do banco de dados, tais como tabelas ou views. Lembrando também, que todos os objetos estão dentro de um Schema, ou seja, o Schema é um Container para objetos. Com isso podemos ver que existe uma separação, explícita, entre usuários e schemas, muito diferente do que ocorria no SQL Server 2000. No SQL Server 2005, temos a seguinte sintaxe, para o nome completo de um objeto:

Nome_do_Servidor.Nome_do_Banco_de_Dados.Nome_do_Schema.Nome_do_Objeto

Mas onde está a vantagem desta mudança?? Bem simples. No SQL Server 2005 os objetos do banco de dados estão contidos dentro de um Schema, e não existe nenhuma relação entre o Schema e os usuários. Com isso, posso alterar o dono de um Schema, sem problemas, pois só irá alterar o dono do Schema, mas não será alterado o nome do Schema. Por exemplo, considere o seguinte objeto:

SRVDB.Vendas.Dados.Clientes

No SQL Server 2005 este objeto é a tabela Clientes, a qual pertence ao Schema Dados, do banco de dados Vendas, do servidor SRVDB. Se precisarmos alterar o dono do Schema Dados, não tem problema, pois isso só irá alterar o dono do Schema e não o seu nome. Isso só ocorre porque houve esta separação entre Schema e Usuários, no SQL Server 2005. Com isso, o nome do Schema pode permanecer sempre o mesmo e podemos alterar o seu dono, quando necessário. Com isso, o nome completo do objeto não muda, o que evita a revisão freqüente no código das aplicações, o que ocorria no SQL Server 2000.

Podemos resumir estas mudanças, da seguinte maneira:

1. Um Schema é um container para objetos
2. Todo objeto pertence a um Schema.
3. Todos os objetos de um Schema tem o mesmo dono, que é o dono do Schema.
4. As permissõe podem ser atribuídas para o Schema também para os objetos dentro de um Schema.
5. Principais benefícios da separação entre Usuários e Schemas:

Múltiplos usuários podem ser donos de um Schema, através da definição de uma role ou um grupo do Windows, como dono do Schema. Com isso, todos os usuários que forem membros da role ou do gruopo do Windows, serão donos do Schema. Ou seja, defino uma role ou Grupo do Windows como sendo o dono de um Schema e todos os seus membros, passam a serem donos do Schema.

O processo de exclusão de um usuário ficou bem mais simplificado, conforme descrito anteriormente. Para excluir um usuário, não é mais necessário alterar o dono de todos os objetos cujo usuário era dono, uma vez que no SQL Server 2005 o usuário não é mais dono de objetos e sim de Schema. Isso evita uma série de problemas, conforme descrito anteriormente.

Com a possibilidade de definição de permissões diretamente em um Schema e também nos objetos contidos no Schema, podemos definir um nível de permissões muito mais granular do que no SQL Server 2000.

Outro importante conceito introduzido pelo SQL Server 2005 é o conceito de Default Schema (Esquema padrão). Este conceito é utilizado para definir que nome deve ser utilizado, quando um é feita referência a um objeto, sem utilziar o nome completo. Por exemplo, considere o objeto DBSRV01.vendas.aplicacoes.clientes. Este é o nome completo (Full Qualified Name), da tabela clientes, do schema aplicacoes, do banco de dados vendas, do servidor DBSRV01. No SQL Server 2000, se não for especificado o nome completo, inicialmente será procurado por um nome que inclui um schema com o mesmo nome do usuário que é o dono do objeto. Por exemplo, se o dono da tabela clientes for o usuário jsilva e você especificar apenas o nome da tabela clientes, o SQL Server 2000 irá procurar, inicialmente, por um objeto chamado jsilva.clientes. Se ele não encontrar, ele procura por um shcema chamado dbo, ou seja, irá procurar por dbo.clientes. Já no SQL Server 2005, com a separação entre os usuários e os schemas, o schema definido como default schema, define qual será o primeiro nome de schema a ser utilizado para tentar localizar um objeto, quando não é especificado o nome completo do objeto. Por exemplo, suponha que o schema default para o usuário seja um schema chamado dados. Se o usuário especificar apenas o nome da tabela – clientes, o SQL Server 2005 irá, primeiramente, procurar por um objeto chamado dados.clientes, por que dados é o schema default para o usuário. O schema default pode ser definido e/ou alterado, usando a opção DEFAULT_SCHEMA, do comando CREATE USER ou do comando ALTER USER, comandos estes que você aprenderá a utilizar neste capítulo. Se, por acaso, não fer definido um schema padrão, o banco de dados utilizará, como schema padrão, o schema dbo. O conceito e uso de default schema traz uma série de vantagens, dentre as quais podemos destacar as seguintes:

Diversos usuários podem compartilhar o mesmo default schema, o que facilita a uniformidade e a padronização, na resolução de nomes.

O fato de um schema padrão poder ser compartilhado por vários usuários, permite aos desenvolvedores de aplicação, armazenar os objetos utilizados pela aplicação, em um schema especificamente criado para a aplicação, ao invés de usar o schema DBO.