[SQL Server] Exame 70-461 – Tópico 3: Projetando Views – Parte 1

Este tópico possui um enunciado um tanto confuso: ensure code non regression by keeping consistent signature for procedure, views and function (interfaces); security implications. Inicialmente precisamos perceber que o tópico vai além de views, abordando também procedures e functions. Por conseguinte, vale destacar que o conteúdo a ser estudado para o exame 70-461 possui escopo mais amplo que DML, envolvendo temas como objetos programáveis (views, sp, functions, triggers) e assuntos avançados como transações, manipulação de XML, dentre outros. Assim, não se iluda: estude e se prepare para uma prova desafiadora que lhe exigirá além do conhecimento de consultas T-SQL e modificação de dados.

Quanto ao conteúdo do tópico 3 vamos quebrá-lo em duas partes, visando dirimir quaisquer confusões:
1) Não regressão de código mantendo consistentes assinaturas nas interfaces dos objetos (view, sp, function)
2) Implicações de segurança

Não regressão de código mantendo consistentes assinaturas nas interfaces dos objetos (view, sp, function)

Pode até parecer confuso, mas a idéia por trás dessas palavras é bem simples: quebrar a dependência. Imaginemos uma view que retorna 3 colunas: CODIGO, NOME, DT_NASCIMENTO, sendo todas recuperadas a partir de uma tabela de candidatos a ofertas de emprego. Agora imagine que o DBA renomeou na tabela (e também na view) a coluna DT_NASCIMENTO para DATA_NASCIMENTO. Enquanto não forem recompiladas, as aplicações que utilizam a view passarão a apresentar erro, vez que ainda referenciam a coluna como DT_NASCIMENTO. Este é um problema típico de dependência: os nomes expostos pela view para as colunas são exatamente os mesmos utilizados nas tabelas. Sendo assim, tudo o que precisamos fazer é tratar a assinatura do objeto, expondo nomes que serão mantidos independente de quaisquer modificações nas tabelas referenciadas, de modo a garantir a não necessidade de manutenção nas aplicações ou em outros objetos programáveis do BD que consomem a view. Vejamos o exemplo da tabela CANDIDATO.

Neste exemplo criamos uma procedure que consome a view. Note que esta procedure produz um result set, ou seja, apresenta o resultado de uma query. A SP (stored procedure) tem uma dependência direta com a view, enquanto que esta usa os mesmos nomes de colunas da tabela referenciada. Para executarmos a SP basta fazer como abaixo:

Agora vamos renomear a coluna DT_NASCIMENTO para DATA_NASCIMENTO, na tabela.

Observe a mensagem que aparece após a execução desta sp builtin: “Caution: Changing any part of an object name could break scripts and stored procedures”. Neste momento a view não está mais funcionando, sendo necessário alterar a view.

Como consequência a SP também parou de funcionar, sendo necessário recompilá-la de modo a refletir o novo nome da coluna. Tente executar o código abaixo e veja o resultado:

Para evitar essa “regressão de código”, vamos modificar a assinatura da view e quebrar a dependência (pelo menos no nível da interface). Isso pode ser feito de duas maneiras.

Execute novamente a sp abaixo e veja que o problema foi resolvido.

A adoção deste tipo de abordagem diminui intervenções em aplicações e ou objetos que consomem uma view. A mesma estratégia pode ser aplicada em SP’s que retornem  result set ou em TVF’s – Table Valued Functions (funções que retornam tabelas).Ainda vale destacar o uso da opção SCHEMABINDING. Ao usarmos tal opção o DBA simplesmente não conseguiria alterar a estrutura da tabela, vez que a opção SCHEMABINDING “prende” a tabela à view ou a function (não existe opção SCHEMABINDING em SP), produzindo uma dependência que não pode ser quebrada. Neste caso, o DBA precisaria alterar a view/function e remover a opção SCHEMABINDING para, em seguida, alterar a tabela.

Conclusão
No próximo post falaremos a respeito das considerações de segurança no projeto de views. Até lá.