postgresql - ¿Qué hacer con los valores nulos al modelar y normalizar?

null relational-database

Question

Soy nuevo en SQL (todavía estoy aprendiendo) y tengo que crear una base de datos para un lugar. Un libro de cliente para una sala para un evento. El problema es que los clientes no siempre proporcionan su nombre, su correo electrónico y su número de teléfono. La mayoría de las veces es nombre y correo electrónico o nombre y teléfono. Raramente son los 3, pero sucede. Necesito almacenar cada uno de estos en sus respectivos atributos (nombre, correo electrónico, teléfono). Pero por la forma en que me dan su información, tengo muchos valores nulos. ¿Qué puedo hacer con estos nulos? Me han dicho que es mejor no tener nulos. También necesito normalizar mi mesa después de eso. Cualquier sugerencia por favor.

Answer 1

En primer lugar, no hay nada de malo con los valores nulos en una base de datos. Y están hechos exactamente para este propósito donde los atributos son desconocidos. Para evitar nulos en una base de datos es un consejo que tiene poco sentido en mi opinión.

Por lo tanto, tendría tres (o cuatro) valores: nombre (nombre / apellido), dirección de correo electrónico y número de teléfono, que identifican a un cliente. Puede tenerlos en una tabla y agregarle una restricción para asegurarse de que siempre se complete al menos una de estas columnas, por ejemplo, la coalesce(name, email, phone) is not null . Esto asegura que una reserva no se pueda hacer de forma completamente anónima.

Según su explicación, no está claro si siempre tendrá la misma información de un cliente. Entonces, ¿puede suceder que un cliente reserve una habitación con su nombre y luego reserve otra habitación con su teléfono? ¿O se buscará al cliente en la base de datos, se encontrará su nombre y se les asignarán las dos reservas? En el último caso, puede tener una tabla de clientes que contenga toda la información que obtuvo hasta ahora, y la reserva contendrá el ID de registro del cliente como referencia a estos datos. En el primer caso, es posible que no desee tener una tabla de clientes, porque no puede identificar si dos clientes (Jane Miller y [email protected]) son realmente dos clientes diferentes o solo un cliente en realidad.

Las tablas que veo hasta ahora:

• habitación (room_id, ...)
• sede (local_id, ...)
• cliente (client_id, nombre, correo electrónico, teléfono)
• reserva (id_de_cuentro, id_de_habitación, id_de_ cliente, ...)

Answer 2

SQL trata NULL especialmente por su versión de 3VL (lógica de 3 valores). La normalización y otras teorías relacionales no. Sin embargo, podemos traducir diseños SQL en diseños relacionales y viceversa. (Suponga que no hay filas duplicadas aquí).

La normalización sucede a las relaciones y se define en términos de operadores que no tratan NULL especialmente. El término " normalization " tiene dos significados distintos más comunes: poner una tabla en "1NF" y en "NFs superiores (formas normales)". NULL no afecta la "normalización a 1NF". "Normalización a NF más altos" reemplaza una tabla por tablas más pequeñas que se unen 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 NULL, entonces podemos interpretarlas como relaciones y unión SQL, etc. como unión, etc. Pero si descompone donde se compartió una columna anulable entre componentes, tenga en cuenta que para reconstruir el original en SQL debe unir SQL en 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 una PK PK (clave primaria) porque eso significa ÚNICO NO NULO. Por ejemplo, una restricción ÚNICA que involucra 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 valores NULL en las FK de SQL hacen que se satisfagan (de varias maneras por modo MATCH), para no fallar al no aparecer en la tabla referenciada. (Pero los DBMS difieren idiosincráticamente del SQL estándar).

Desafortunadamente, la descomposición puede conducir a una tabla con todas las CK que contienen NULL, por lo 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 la normalización, es posible que queramos reintroducir cierta nulabilidad en los componentes.

En la práctica, logramos diseñar tablas para que siempre haya un conjunto de columnas sin NULL que podamos declarar como CK, a través de SQL PK o UNIQUE NOT NULL. Podemos deshacernos de una columna anulable que no está en todas las CK sin NULL al soltarla de la tabla y agregar una tabla con esa columna y las columnas de alguna CK sin NULL: si la columna no es NULL para un la fila en el diseño anterior y luego una fila con su subcadena CK y el valor de la columna van en la tabla agregada; de lo contrario, es NULL en el diseño anterior y no hay una fila correspondiente en la tabla agregada. Por supuesto, también tenemos que modificar las consultas del diseño anterior al nuevo diseño.

Siempre podemos evitar los nulos a través de un diseño que agrega una columna de bandera que dice para una fila si una columna anulable previamente es NULL en el diseño anterior y, de ser así, tener esa columna es un valor que seleccionamos para ese propósito para ese tipo en todo el base de datos. Por supuesto, también tenemos que modificar las consultas del diseño anterior al nuevo diseño.

Si desea evitar NULL es una pregunta separada. Su base de datos podría de alguna manera ser "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 , por lo tanto, complica las consultas, de manera perversa, en comparación con la complicación de más combinaciones de más tablas sin NULL. (Esa perversidad generalmente se gestiona eliminando NULL en las expresiones de consulta lo más cerca posible de donde aparecen).

PD Muchos términos 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 superclave extranjera; pero ni siquiera tiene sentido hablar de una "superclave" en SQL :

Debido a la semejanza de las tablas SQL con las relaciones, los términos que involucran relaciones se aplican descuidadamente a las tablas. Pero aunque puede tomar prestados términos y darles significados SQL (valor, tabla, superclave, CK, PK, FK, unión y predicado, NF, normalizar, etc.), no puede simplemente sustituir esos significados SQL por esas palabras en Definiciones de RM, teoremas o algoritmos y obtener algo sensible o verdadero. Además, las presentaciones SQL de las nociones de RM casi nunca le dicen cómo aplicar correctamente las nociones de RM a una base de datos SQL . Simplemente repiten las presentaciones de RM, ajenos a si su uso de significados SQL para términos hace que las cosas carezcan de sentido o sean inválidas.