SQL trata NULL especialmente por su versión de 3VL (lógica de 3 valores). La normalización y otras teorías relacionales no lo hacen. Sin embargo, podemos traducir diseños SQL a diseños relacionales y viceversa. (Suponga que no hay filas duplicadas aquí).
La normalización ocurre en las relaciones y se define en términos de operadores que no tratan NULL de forma especial. El término "normalización" tiene dos significados distintos más comunes:colocar una tabla en "1NF" y en "NF superiores (formas normales)". NULL no afecta la "normalización a 1NF". La "normalización a NF más altos" reemplaza una tabla por tablas más pequeñas que se unen naturalmente a ella. Para fines de normalización, puede tratar NULL como un valor permitido en el dominio de una columna anulable además de los valores de su tipo SQL. Si nuestras tablas SQL no tienen valores NULL, entonces podemos interpretarlas como relaciones y combinación SQL, etc. como combinación, etc. las columnas del mismo nombre son iguales o ambas NULL . Y no querrá tales CK (claves candidatas) en una base de datos SQL. Por ejemplo, no puede declararlo como SQL PK (clave principal) porque eso significa ÚNICO NO NULO. Por ejemplo, una restricción ÚNICA que implica una columna anulable permite múltiples filas que tienen un NULL en esa columna, incluso si las filas tienen los mismos valores en cada columna. Por ejemplo, los NULL en SQL FK hacen que se satisfagan (de varias maneras según el modo MATCH), para que no fallen por no aparecer en la tabla a la que se hace referencia. (Pero los DBMS difieren idiosincrásicamente del SQL estándar).
Desafortunadamente, la descomposición podría conducir a una tabla con todos CK que contienen NULL, de modo que no tenemos nada que declarar como SQL PK o UNIQUE NOT NULL. La única solución segura es convertir a un diseño libre de NULL. Después de normalizar, es posible que deseemos reintroducir algo de nulabilidad en los componentes.
En la práctica, logramos diseñar tablas para que siempre haya un conjunto de columnas libres de NULL que podemos declarar como CK, a través de SQL PK o UNIQUE NOT NULL. Luego, podemos deshacernos de una columna anulable soltándola de la tabla y agregando una tabla con esa columna y las columnas de algún CK libre de NULL:si la columna no es NULL para una fila en el diseño anterior, entonces una fila con su subfila CK y su valor de columna van en la tabla añadida; de lo contrario, es NULL en el diseño anterior y no hay ninguna fila correspondiente en la tabla agregada. (La tabla original es una unión izquierda natural de las nuevas). Por supuesto, también tenemos que modificar las consultas del diseño antiguo al nuevo diseño.
Siempre podemos evitar NULL a través de un diseño que agrega una columna booleana para cada columna anulable anterior y tiene la columna anterior NOT NULL. La nueva columna dice para una fila si la columna anterior era NULL en el diseño anterior y, cuando es verdadero, la columna anterior tiene un valor que elegimos para ese propósito para ese tipo en toda la base de datos. Por supuesto, también tenemos que modificar consultas del diseño antiguo al nuevo diseño.
Si desea evitar NULL es una pregunta aparte. Su base de datos podría ser de alguna manera "mejor" o "peor" para su aplicación con cualquier diseño. La idea detrás de evitar NULL es que complica los significados de las consultas y, por lo tanto, complica las consultas de una manera perversa, en comparación con la complicación de más combinaciones de más tablas sin NULL. (Esa perversidad generalmente se maneja eliminando NULL en las expresiones de consulta lo más cerca posible de donde aparecen).
PS Muchos términos de SQL, incluidos PK y FK, difieren de los términos relacionales. SQL PK significa algo más como superclave; SQL FK significa algo más como una superclave externa; pero ni siquiera tiene sentido hablar de una "superclave" en SQL:
Debido a la semejanza de las tablas de SQL con las relaciones, los términos que implican relaciones se aplican de manera descuidada a las tablas. Pero aunque puede tomar prestados términos y darles significados SQL:valor, tabla, FD (dependencia funcional), superclave, CK (clave candidata), PK (clave principal), FK (clave externa), unión y predicado, NF (forma normal), normalizar, 1NF, etc. No puede simplemente sustituir esos significados de SQL por esas palabras en definiciones, teoremas o algoritmos de RM y obtener algo sensato o verdadero. Además, las presentaciones SQL de las nociones de RM casi nunca decirte cómo aplicar correctamente las nociones de RM a una base de datos SQL . Simplemente repiten como un loro las presentaciones de RM, ajenos a si su uso de significados SQL para los términos hace que las cosas no tengan sentido o no sean válidas.
