SQL Domain-chave Forma Normal (DK / NF) e formulário anormal
Depois de um banco de dados SQL está em terceira forma normal, você eliminou a maioria, mas não todos, as chances de anomalias de modificação. formas normais além do terceiro são definidas para esmagar esses poucos erros restantes.
forma normal Domain-chave (DK / NF)
formulário de Boyce-Codd normal (BCNF), a quarta forma normal (4FN) e quinta forma normal (5NF) são exemplos de tais formas. Cada formulário elimina uma possível anomalia modificação, mas não garante a prevenção de todas as anomalias de modificação possíveis. forma normal chave domínio de, no entanto, oferece tal garantia.
Uma relação está em domain-chave forma normal (DK / NF) se cada restrição sobre a relação é uma consequência lógica da definição de chaves e domínios. UMA limitação nesta definição é qualquer regra que é preciso o suficiente para que você possa avaliar se é ou não é verdade. UMA chave é um identificador exclusivo de uma linha em uma tabela. UMA domínio é o conjunto de valores permitidos de um atributo.
Olhe para esta base de dados, que está na 1NF, para ver o que você deve fazer para colocar esse banco de dados em DK / NF.
Mesa: VENDAS (Identificação do Cliente, Produto, Preço)
Chave: Identificação do Cliente
restrições:
Identificação do Cliente determina Produto
Produto determina Preço
Identificação do Cliente deve ser um número inteiro> 1000
Para impor restrição 3 (que Identificação do Cliente deve ser um número inteiro maior que 1000), você pode simplesmente definir o domínio de Identificação do Cliente para incorporar essa restrição. Isso faz com que a restrição de uma consequência lógica do domínio da Identificação do Cliente coluna. Produto depende de Identificação do Cliente, e Identificação do Cliente é uma chave, então você não tem problema com restrição 1, que é uma consequência lógica da definição da chave.
restrição 2 é um problema. Preço depende (é uma consequência lógica) Produto, e Produto não é uma tecla. A solução é dividir a tabela SALES em duas tabelas. Um usa a tabela Identificação do Cliente como uma chave, e as outras utilizações Produto como uma chave. O banco de dados, além de estar em 3NF, também está em DK / NF.
Projete seus bancos de dados para que eles estejam em DK / NF, se possível. Se você pode fazer isso, impondo restrições de teclas e de domínio faz com que todas as restrições a serem cumpridas, e as anomalias modificação não são possíveis. Se a estrutura de um banco de dados é projetado para impedir que você colocá-lo em DK / NF, então você tem que construir as restrições no programa aplicativo que usa o banco de dados. O banco de dados em si não garante que as restrições serão cumpridos.
forma anormal
Como na vida, por isso, nas bases de dados: Às vezes, ser anormal compensa. Você pode se deixar levar com normalização e ir longe demais. Você pode acabar com um banco de dados em tantas mesas que toda a coisa torna-se difícil e ineficiente. O desempenho pode despencar. Muitas vezes, a estrutura ideal para o seu banco de dados é um pouco desordenado.
Na verdade, os bancos de dados práticos (os realmente grandes, pelo menos) quase nunca são normalizados todo o caminho para DK / NF. Você quer normalizar os bancos de dados que você cria, tanto quanto possível, no entanto, para eliminar a possibilidade de corrupção de dados que resulta de anomalias de modificação.
Depois de normalizar o banco de dados, tanto quanto possível, fazer algumas consultas como uma corrida seca. Se o desempenho não for satisfatório, examine seu projeto para ver se desnormalização seletiva iria melhorar o desempenho sem sacrificar a integridade. Ao adicionar cuidadosamente redundância em locais estratégicos e desnormalizar Apenas o suficiente, você pode chegar a um banco de dados que é tanto eficiente e seguro de anomalias.