Implementar una relación de uno a cero o una en SQL

Digamos que estoy diseñando una base de datos para un escenario donde existe una relación de uno a cero o uno (1-0..1). Por ejemplo:

• Hay un conjunto de usuarios , y algunos usuarios también pueden ser clientes .

Por lo tanto, creé las dos tablas correspondientes usersy customers, pero ...

... ¿Cuál es la mejor manera de representar e implementar esta situación en una plataforma SQL dada? He considerado dos posibles soluciones:

1. En la userstabla, agregue la customercolumna que puede ser una referencia de CLAVE EXTRANJERA customerso una NULLmarca.

2. En la customerstabla, incluya una usercolumna (establecida con una UNIQUErestricción) que apunte a la userstabla.

Ya he hecho una pregunta similar en algunos foros, pero la respuesta fue básicamente "lo que necesites", "lo que creas conveniente". No me gusta este tipo de respuesta. En cambio, quiero una pieza seria de teoría DB, una respuesta bien fundada. ¿Dónde puedo leer sobre las relaciones 1-0..1?

Quiero una pieza seria de teoría DB

La teoría relacional moderna rechaza los valores nulos , lo que parece invalidar inmediatamente su opción 1. Sin embargo, este hombre de paja puede eliminarse reemplazando el valor nulo predeterminado con un valor predeterminado, por ejemplo, un cliente "falso" creado únicamente para modelar explícitamente "no es un cliente" correspondencia.

Creo que su opción 2 es la más sólida teóricamente porque, a diferencia de la opción 1 modificada, las relaciones pueden estar en la sexta forma normal (6NF), siendo una forma normal de unión por proyección y la forma normal más alta posible.

También he oído hablar de una regla general de diseño que establece que una relación debe modelar ya sea una entidad O la relación entre entidades pero nunca ambas, lo que me parece razonable. Nuevamente, esto favorecería la opción 2. Sin embargo, escuché sobre esta regla general hace muchos años, no recuerdo dónde y no puedo ofrecer una base teórica seria (aparte de 6NF como se mencionó anteriormente).

Se le ha dado la respuesta correcta en parte. La respuesta real proviene de su modelo de datos y de cómo se normalizó. Una clave es cómo llegar a la relación:

• La customerstabla consta de varios campos considerados para la userstabla que pertenecen al concepto de cliente y son nulos a menos que el usuario también sea un cliente (subtipo de usuario). En este caso, la customerstabla hereda la clave primaria de la userstabla. (Es posible que haya varios subtipos que pueden superponerse o no).

• La customerstabla consta de varios campos relacionados con el concepto de cliente, pero no necesariamente con el concepto de usuario. El cliente es una mesa sólida y no depende del concepto de usuario. (La eliminación de la userstabla no afectaría significativamente el diseño de la tabla de clientes). En este caso, la tabla de clientes obtiene su propia clave principal.

Lo que tiene es un caso especial de relación opcional de uno a muchos donde el límite superior es 1. Considérelo desde ambos lados: ¿Sería posible que un usuario tenga múltiples clientes o un cliente tenga múltiples usuarios? Si es así, deberá remodelar sus datos.

Agregar la user-idclave externa a la customerstabla podría considerarse una mejor opción, ya que asigna correctamente la relación uno a muchos (límite superior 1) y evita un campo anulable. Para imponer el límite superior, el índice de clave externa debe ser único. Esto ocurrirá automáticamente si la clave principal es user-id.

Agregar customer-idcomo una clave externa opcional a la userstabla impone el límite superior de 1 en la relación pero revierte la dependencia.

¿Has considerado un enfoque un poco más complejo pero flexible? La tabla principal es "persona" (o "entidad" dependiendo de lo complejo que desee ser). Luego, la tabla de clientes y la tabla de usuarios tienen un FK para la tabla de personas. La tabla de persona contiene detalles personales, mientras que las tablas de cliente y usuario contienen solo atributos asociados con un usuario o cliente. A menudo, las direcciones (correo electrónico y correo postal), números de teléfono, etc. también se representan en tablas separadas con tablas de mapeo para permitir situaciones de muchos a muchos. Este es un modelo relativamente común que puede encontrar en varios sitios de referencia.