SQL trata NULL especialmente por sua versão de 3VL (lógica de 3 valores). A normalização e outras teorias relacionais não. No entanto, podemos traduzir designs SQL em designs relacionais e vice-versa. (Assuma que não há linhas duplicadas aqui.)
A normalização acontece com relações e é definido em termos de operadores que não tratam NULL especialmente. O termo "normalização" tem dois significados distintos mais comuns:colocar uma tabela em "1NF" e em "NFs superiores (formas normais)". NULL não afeta a "normalização para 1NF". "Normalização para NFs mais altas" substitui uma tabela por tabelas menores que se unem naturalmente a ela. Para fins de normalização, você pode tratar NULL como um valor permitido no domínio de uma coluna anulável, além dos valores de seu tipo SQL. Se nossas tabelas SQL não tiverem NULLs, então podemos interpretá-las como relações e junção SQL etc como junção, etc. colunas com o mesmo nome sendo iguais ou ambas NULL . E você não vai querer essas CKs (chaves candidatas) em um banco de dados SQL. Por exemplo, você não pode declará-lo como um SQL PK (chave primária) porque isso significa UNIQUE NOT NULL. Por exemplo, uma restrição UNIQUE envolvendo uma coluna anulável permite várias linhas que tenham um NULL nessa coluna, mesmo que as linhas tenham os mesmos valores em todas as colunas. Por exemplo, NULLs em SQL FKs fazem com que eles sejam satisfeitos (de várias maneiras por modo MATCH), para não falharem por não aparecerem na tabela referenciada. (Mas os DBMSs diferem idiossincraticamente do SQL padrão.)
Infelizmente, a decomposição pode levar a uma tabela com todos CKs contendo NULL, para que não tenhamos nada a declarar como SQL PK ou UNIQUE NOT NULL. A única solução segura é converter para um design livre de NULL. Após a normalização, podemos querer reintroduzir alguma nulidade nos componentes.
Na prática, conseguimos projetar tabelas para que haja sempre um conjunto de colunas livres de NULL que podemos declarar como CK, via SQL PK ou UNIQUE NOT NULL. Então podemos nos livrar de uma coluna anulável, removendo-a da tabela e adicionando uma tabela com essa coluna e as colunas de algum CK livre de NULL:Se a coluna não for NULL para uma linha no design antigo, uma linha com seu valor de sub-linha e coluna CK vão para a tabela adicionada; caso contrário, é NULL no design antigo e nenhuma linha correspondente está na tabela adicionada. (A tabela original é uma junção natural à esquerda das novas.) É claro que também temos que modificar as consultas do design antigo para o novo design.
Sempre podemos evitar NULLs por meio de um design que adiciona uma coluna booleana para cada coluna anulável antiga e tem a coluna antiga NOT NULL. A nova coluna informa para uma linha se a coluna antiga era NULL no design antigo e, quando true, a coluna antiga é algum valor que escolhemos para esse propósito para esse tipo em todo o banco de dados. Claro, também temos que modificar as consultas do design antigo para o novo design.
Se você deseja evitar NULL é uma questão separada. Seu banco de dados pode, de alguma forma, ser "melhor" ou "pior" para seu aplicativo com qualquer design. A ideia por trás de evitar NULL é que ele complica os significados das consultas, portanto, complica a consulta, de uma maneira perversa, em comparação com a complicação de mais junções de mais tabelas livres de NULL. (Essa perversidade é normalmente gerenciada removendo NULLs em expressões de consulta o mais próximo possível de onde eles aparecem.)
PS Muitos termos SQL, incluindo PK e FK, diferem dos termos relacionais. SQL PK significa algo mais como superchave; SQL FK significa algo mais como superchave estrangeira; mas nem faz sentido falar de uma "superchave" no SQL:
Devido à semelhança das tabelas SQL com as relações, os termos que envolvem relações são aplicados de forma descuidada às tabelas. Mas embora você possa emprestar termos e dar a eles significados SQL - valor, tabela, FD (dependência funcional), superchave, CK (chave candidata), PK (chave primária), FK (chave estrangeira), junção e predicado, NF (forma normal), normalizar, 1NF, etc - você não pode simplesmente substituir esses significados SQL por essas palavras em definições de RM, teoremas ou algoritmos e obter algo sensato ou verdadeiro. Além disso, apresentações SQL de noções de RM quase nunca na verdade, dizer a você como aplicar as noções de RM a um banco de dados SQL . Eles apenas repetem apresentações de RM, ignorando se o uso de significados SQL para termos torna as coisas sem sentido ou inválidas.
