[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.

USE DBExame70461
GO
— Cria a tabela de candidatos
CREATE TABLE dbo.Candidato
( CODIGO INT,
NOME VARCHAR(50),
DT_NASCIMENTO DATETIME);
GO

INSERT dbo.Candidato VALUES(1, ‘Mariana Pereira da Silva’, ‘19801224’);
GO

— Cria a view
CREATE VIEW dbo.vwCandidatos
AS
SELECT Codigo, Nome, Dt_Nascimento
FROM dbo.Candidato;
go

— Cria uma sp para consumir a view
CREATE PROCEDURE dbo.uspObterCandidatos
AS
SELECT Codigo, Nome, Dt_Nascimento FROM dbo.vwCandidatos;
GO

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:

EXEC dbo.uspObterCandidatos;

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

— Renomeando a coluna na tabela
EXEC sp_rename ‘dbo.Candidato.DT_NASCIMENTO’, ‘DATA_NASCIMENTO’;

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.

— Renomeando na view
ALTER VIEW dbo.vwCandidatos
AS
SELECT Codigo, Nome, Data_Nascimento
FROM dbo.Candidato;
go

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:

exec dbo.uspObterCandidatos
Invalid column name ‘Dt_Nascimento’

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.

— Criando ALIAS para as colunas diretamente na lista do SELECT
ALTER VIEW dbo.vwCandidatos
AS
SELECT
Codigo As Codigo,
Nome as Nome,
Data_Nascimento As Dt_Nascimento
FROM dbo.Candidato;
go

— Declarando externamente os ALIAS para as colunas
ALTER VIEW dbo.vwCandidatos (Codigo, Nome, Dt_Nascimento)
AS
SELECT
Codigo,
Nome,
Data_Nascimento
FROM dbo.Candidato;
go

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

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á.



Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s