SQL Server: Integridade

Este artigo mostra ao leitor onde começa a integridade de dados, e a importância de cada uma delas para a criação de um banco de dados confiável e seguro.

por Thiago Pastorello Gervazoni

O banco de dados evoluiu muito desde a sua descoberta, passamos por várias etapas até chegarmos hoje no banco de dados relacional como o SQL Server.

Os benefícios de um banco de dados deste porte são muitos, mas para se obter os benefícios propostos por ele é preciso seguir algumas normas, como garantir a integridade dos dados e a normalização, a normalização é um assunto para uma coluna no mínimo, porque se trata de um aspecto por que não dizer, fundamental para o sucesso do projeto.

Quando falamos em integridade do SQL Server, pensamos em proteção contra hackers e ataques do gênero, ou até mesmo backup, mas a integridade começa em um nível muito mais baixo que isto, começa na criação e projeto do banco de dados, como segue:

Integridade de Domínio

A integridade de domínio nada mais é do que a integridade do campo como o tipo de dados correto, se permite null ou not null, default´s, check´s constraints, estes mecanismos foram criados para dar integridade aos campos. Os tipos de dados também são caracterizados como integridade de domínio, se o tipo de dado estiver incorreto, ou com mais posições que o necessário, pode haver ali um risco que quebre a integridade. O check aqui é em nível de campo apenas por exemplo: Tenho um campo Meses e quero que entre valores de 1 até 12 somente.

Integridade de Entidade

A integridade de entidade nada mais é que a integridade da tabela, isto é conseguido através das Primary Keys ou Uniques, uma tabela sem PK ou Unique é uma tabela sem integridade de entidade, é muito comum pegarmos tabelas sem PK, alguns colocam campo identity e não se preocupam com as PK´s, mas esquecem que o campo identity não garante a não duplicidade.

Integridade Referencial

A integridade referencial é mais conhecida, são as Foreign Keys, nada mais é que eu aceitar valores em minha entidade que estão em outra entidade, isto é possível a partir da integridade de entidade, eu apenas consigo criar Foreign Keys a partir de uma Primary Key ou uma Unique, a integridade referencial consiste também em check em nível de tabela e não em nível de campo, no ato da criação da tabela crio um check, por exemplo:

Tenho uma tabela com 2 campos Medico1, Medico2, e quero que um dos campos sempre seja preenchido não importa qual, para isto preciso de um check em nível de tabela.

Segue tabela de tipos de integridade :

Tipos de integridade	Tipo de constraint
Domínio	DEFAULT CHECK REFERENCIAL
Entidade	PRIMARY KEY UNIQUE
Referencial	FOREIGN KEY CHECK

Tabela 1 - Tipos de integridade e constraints

Para se adicionar integridade a uma tabela é possível fazê-lo de duas maneiras CREATE TABLE ou ALTER TABLE.

É possível aplicar integridade de duas maneiras : Declarativa e Procedural

Declarativa: É declarado como parte da definição do objeto, e o SQL automaticamente assume o critério, é o método preferido pela maioria, para se determinar esta integridade basta usar os check´s constraints, default´s e os rules.

Procedural: É definido com o script do objeto, é utilizado mais para lógicas muito complexas e exceções, um bom exemplo de integridade procedural é um delete em cascata, a integridade procedural pode ser realizada no cliente ou no servidor, é conseguida através de stored procedures e triggers.

Integridade	Funcionalidade	Custo em performance	Modificação Antes/Depois
Constraints	Médio	Baixo	Antes
Defaults e Roles	Baixo	Baixo	Antes
Triggers	Alto	Médio-Alto	Depois
Tipo de dados	Baixo	Baixo	Antes
Null, Not Null	Baixo	Baixo	Antes

Tabela 2 - Tipos de constraints e custos em performance

Obs : As rules estão na versão do SQL 2000 por compatibilidade, não são recomendados, a constraint Default, veio para substituí-la porque exige menos recurso para ser executada.

A integridade dos dados é algo muito importante e existem recursos para certificar isto, porém existem meios melhores que outros de se prover de integridade em meio aos recursos, é totalmente errado transferir esta funcionalidade para a aplicação, por exemplo, criar uma procedure ou function na aplicação para checar se já existe algum valor antes de inserir, porque a tabela não possui chave primária, aplicações são sempre refeitas ou alguma nova é criada que utilize um mesmo banco de dados, por isto estas regras pertinentes a dados devem permanecer na base de dados e não na aplicação.

E uma tabela sem chave primária está sem integridade de entidade, e pode sofrer falhas pertinentes a este tipo de falta de integridade, falhas esta que podem ser vistas somente depois de muito tempo que o banco está em funcionamento, causando um enorme transtorno para corrigir lacunas que estão vazias e não poderiam, valores duplicados e não poderiam, valores inválidos inseridos. Isto sim dá trabalho de se corrigir.

Sempre os recursos de integridade que tem baixo custo de performance (tabela 2), e sua modificação ocorrem antes do valor ser inserido são as melhores para se aplicar ao banco, porque exigem pouco do banco e são rápidos. Você pode perguntar, então nunca usarei triggers? As triggers porém tem seu espaço, triggers são um tipo de stored procedures que são bastante utilizadas em lógicas muito complexas, que as constraints não cobrem como: Emitir mensagens customizadas, verificar valores em outras tabelas no ato do update/insert, executar antes das constraints (instead off) e execução em cascata.

Até mais