Integridade do Banco de Dados

• Restrição de domínio

• Restrição de chave primária

• Restrição de chaves externas

Restrição de domínio

Significa restringir o conteúdo dos campos a valores válidos. Domínio é um conjunto de valores possíveis. Por exemplo, para entrar com um código de cliente em uma fatura, você precisa verificar se aquele código existe na tabela de clientes.
 

Restrição de chave primária

Precisa apresentar 2 propriedades: Exclusividade e minimalidade.
 

Exclusividade: significa que se x (uma ou uma combinação de campos) é a chave primária, não poderá haver, em hipótese alguma, mais de um registro com o mesmo valor de x.
 

Minimalidade: é um pouco mais difícil de explicar. Significa que nada que viole sua exclusividade pode ser descontado da classe primária. Por exemplo, a combinação de campos (numero_peca, nome_peca) pode ser uma chave exclusiva. Dois registros não poderão ter os mesmos valores em ambos os campos, mas não é o 'mínimo'. Você pode retirar o nome da peça da chave e ela ainda será exclusiva. O número da peça é o mínimo necessário para identificar o registro.
Observe que você só pode selecionar uma chave primária após um amplo estudo dos dados.
 

* Restrição de chaves externas

Você define as relações entre tabelas usando o mesmo campo em duas tabelas diferentes.

O 'pai' estabelece a relação baseado em suas chaves primárias. Na relação Cliente->Fatura, por exemplo, a tabela de clientes é o pai, e a relação está baseada em Num_cliente, chave primária da tabela Clientes. Esta chave também existe na tabela filho e, nesta tabela, ela é chamada 'chave externa'. Ela é uma chave primária de uma tabela, mas não desta. Ela é um campo, ou uma combinação de campos, cujos valores precisam corresponder a uma chave primária definida em outra tabela.

Ao incluir registros em uma tabela, você precisa assegurar que as chaves externas correspondam a uma chave primária definida no banco de dados-pai. Por exemplo, ao incluir uma fatura no sistema, você deve garantir que o campo Num_cliente na tabela Faturas corresponda a um cliente inserido na tabela Clientes. Para impor esta 'integridade referencial', é preciso determinar p/ cada relação, o que fazer quando uma chave primária for modificada ou seu registro for eliminado. Existem 3 métodos de ação:

 Addendum 28/06/2002:
 

Foi constatado que a corrupção nos arquivos de índices do RDD DBFNTX pode ser reduzida quando se abre todos os índices do arquivo DBF sempre em uma mesma ordem e só depois você determina o índice ativo com DBSETORDER(), por exemplo. Se você tem muitos problemas com corrupção dos índices .NTX, faça um teste e dê o seu depoimento, ok?! Aliás, sempre abra todos os índices de cada banco de dados junto senão eles ficarão desatualizados e não servirão.

Não seria por isso que o RDD DBFCDX é mais consistente?! Os índices deste RDD podem ser criados em um único arquivo .CDX, ou seja, vários índices (chamados de "bolsa") criados em um único arquivo de índice e toda vez que você abre este arquívo, todos os índices estarão abertos e disponíveis sempre na mesma ordem...

O RDD Comix mais o ClipMore (extensão .CDX) é uma dupla muito bem falada pela maior robustez e velocidade dos seus arquivos de índices que os índices RDD DBFCDX naturais do Clipper.

O RDD SixDrive (extensão .NSX) é clamado o melhor que existe por várias pessoas, os arquivos de índice são menores que os .CDX e, também, são mais rápidos ainda, sem embargo, há depoimentos que seus arquivos se corrompem muito facilmente. Seria viável?!

------------------
Fonte: Clipper 5.2 - Rick Spence, Makron Books, p.244-249.