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

Garantir a integridade dos dados, significa termos dados confiáveis armazenados no Banco de Dados, em resumo, dados de qualidade. No Books OnLine, encontramos a seguinte definição de integridade de dados:

“Integridade dos dados é um estado no qual todos os dados armazenados no Banco de Dados, estão corretos. Se valores incorretos foram armazenados no Banco de Dados, dizemos que o banco de dados perdeu a Integridade dos dados.”

Por exemplo, não devemos permitir que sejam inseridos dois pedidos com o mesmo número de pedido ou dois funcionários com o mesmo número de matrícula. Também não devemos aceitar que sejam cadastrados produtos para uma categoria de produtos que não existe na tabela Categorias. Outro exemplo de dado incorreto é um dado que está fora de uma faixa permitida. Por exemplo, a entrada de um valor um 1.000.000.000 em um campo valor da hora extra.

Para garantir que estes tipos de incorreções não aconteçam, é que o SQL Server 2005 disponibiliza uma série de elementos que nos ajudam a garantir a Integridade dos dados.

No SQL Server 2005, temos os seguintes tipos de Integridade de dados:

• Integridade de Domínio (Domain Integrity): Este tipo de integridade também é conhecido como Integridade de Coluna e define o conjunto ou faixa de valores que são aceitáveis para um determinado campo de uma tabela. Temos vários mecanismos para impor este tipo de integridade. Por exemplo, ao definirmos o tipo de um campo como sendo numérico, já estamos impedindo que sejam digitados valores de texto neste campo. O tipo de campo – integer, double, etc. – também define uma faixa de valores aceitáveis. Também podemos utilizar Constraints para impor Integridade de Domínio. Podemos definir uma Constraint que somente aceita, os valores 1, 2 ou 3 em um determinado campo. O conceito de Constraint é semelhante ao conceito de regra de validação, o qual é utilizado no Microsoft Access.
• Integridade de Entidade (Entity Integrity): Este tipo de integridade está relacionada com a definição de uma Chave Primária para a tabela. Lembrando que um campo do tipo Chave Primária não pode conter valores repetidos. Por exemplo, se definimos o campo CPF como sendo a Chave Primária da tabela Clientes, não podemos cadastrar dois clientes com o mesmo número de CPF, isto é, não podemos ter valores repetidos neste campo.
• Integridade Referencial: Conforme explicamos no Capítulo 1, a Integridade Referencial faz com que o SQL Server impeça que algumas ações sejam executadas e força a execução de outras ações. Para clarear este conceito, vamos considerar o exemplo da Figura 9.5.

Figura 9.5 Relação entre as tabelas Pedidos, Clientes e Detalhes do pedido.

Temos dois relacionamentos. Um relacionamento do tipo Um para Vários entre as tabelas Pedidos e Detalhes do pedido, ou seja, Um pedido pode conter Vários itens. Temos um outro relacionamento do tipo Um para Vários entre as tabelas Clientes e Pedidos, ou seja, Um cliente pode fazer vários pedidos. A Integridade Referencial pode evitar as seguintes situações:

• Que sejam adicionados registros em uma tabela relacionada (lado Vários), sem que tenha sido adicionado o registro relacionado na tabela primária (lado Um). No nosso exemplo, isto evita que sejam adicionados itens na tabela Detalhes do pedido, para um pedido que ainda não tenha sido cadastrado na tabela Pedidos. Ou que seja adicionado um pedido para um Cliente que ainda não foi cadastrado na tabela Clientes.
• Alteração de valores na tabela primária (lado Um), deixando “registros órfãos” na tabela relacionada (lado Vários). No nosso exemplo, ao alterarmos o número do pedido na tabela Pedidos, o campo NúmeroDoPedido dos itens relacionados, na tabela Detalhes do pedido, será também atualizado. Este mecanismo é conhecido como Atualização em Cascata, no Microsoft Access. Ou ao alterarmos o código do cliente, na tabela Clientes, o respectivo código também será atualizado em todos os pedidos efetuados pelo cliente, na tabela Pedidos.
• Impedir que sejam excluídos registros na tabela primária (lado Um), se existirem registros correspondentes na tabela relacionada (lado Vários). Por exemplo, impedir que seja excluído um pedido na tabela Pedidos, para o qual ainda existam itens na tabela Detalhes do pedido. No Microsoft Access, existe um mecanismo chamado Exclusão em Cascata. Quando este mecanismo é ativado, se excluirmos o registro na tabela primária, todos os registros correspondentes, na tabela relacionada serão também excluídos.

Uma outra característica interessante é que a integridade pode ser definida pelo usuário. O usuário pode definir regras personalizadas de integridade, em atendimento às necessidades de uma ou mais aplicações. Por exemplo, podemos definir uma regra que impeça funcionários de uma determinada categoria, de aprovarem parcelamentos acima de um determinado valor. Estas regras podem ser implementadas com o uso de Constraints, Stored Procedures e Trigguers. Aprenderemos sobre Constraints e Triggers neste capítulo e sobre Stored Procedures no próximo capítulo.

Know-how em: Criação e Teste de Constraints no SQL Server 2005

Pré-Requisitos:

• Fundamentos apresentados na Parte I.
• Saber utilizar a janela de execução de comandos T-SQL.
• Noções sobre Integridade de dados e os tipos de integridade de dados existentes no SQL Server 2005.

Metodologia:

• Apresentação do conceito de Constraint e dos procedimentos para a criação e teste de Constraints.

Técnica:

• Utilização da janela de execução de comandos T-SQL para a criação e teste de Constraints.

A utilização de Constraints, para garantir a Integridade dos dados, é o método recomendado pela própria Microsoft. Com a utilização de Constraints, a Integridade dos dados é garantida automaticamente. Podemos utilizar Constraints para limitar os valores que podem ser inseridos em uma determinada coluna (Integridade de domínio) e também para garantir o relacionamento entre tabelas (Integridade referencial). Uma Constraint que atua somente sobre uma coluna, é chamada de “column Constraint”, já uma Constraint que atua sobre duas ou mais colunas, é conhecida como “table Constraint”.

Na Tabela 9.2, temos um resumo dos diversos tipos de Constraints.

Tabela 9.2 - Tipos de Constraints e utilização de cada uma delas.

Agora vamos a alguns exemplos práticos de criação dos diversos tipos de Constraints.

Podemos criar Constraints no momento de criação de uma tabela, quando utilizamos o comando CREATE TABLE. Também podemos criar Constraints em uma tabela já existente, utilizando o comando ALTER TABLE. Constraints podem estar associadas com uma ou mais colunas. Considere os seguintes fatos:

• Uma Constraint associada com uma única coluna é conhecida como “column-level Constraint”.
• Uma Constraint associada com múltiplas colunas é conhecida como “table-level Constraint”.
• DEFAULT Constraints somente podem ser associadas com um único campo, isto é, são column-level Constraints.
• Constraints não são definidas na tabela do Banco de Dados, isto é, uma Constraint não pode referenciar colunas de outras tabelas. Por exemplo, não podemos definir uma Constraint para um campo da tabela Clientes, a qual acessa valores em outras tabelas.
• Podemos adicionar, alterar e excluir Constraints, sem termos que excluir e recriar a tabela.
• Quando adicionamos uma Constraint, o SQL Server 2005 verifica se os dados da tabela se enquadram na Constraint que está sendo adicionada. Por exemplo, se tentarmos adicionar uma Constraint do tipo UNIQUE, em um campo onde existem valores repetidos, a Constraint não será adicionada e uma mensagem de erro será emitida.

Ao criar uma Constraint, devemos definir um nome para a constraint, pois caso contrário o SQL Server 2005 irá gerar um nome. O problema é que o nome gerado, automaticamente, pelo SQL Server 2005, não é nada amistoso e, tampouco, indicativo da função da Constraint.