sql - tipos - ¿Hay alguna vez donde el uso de una relación de base de datos 1: 1 tenga sentido?

relacion varios a varios (25)

Estaba pensando el otro día en la normalización, y se me ocurrió, no puedo pensar en un momento en el que debería haber una relación 1: 1 en una base de datos.

Nombre: SSN? Los tendría en la misma tabla PersonID: AddressID? De nuevo, la misma mesa.

Puedo proponer un trillón de ejemplos de 1: muchos o muchos: muchos (con tablas intermedias apropiadas), pero nunca uno 1: 1.

¿Me estoy perdiendo algo obvio?

Con mayor frecuencia es más una construcción física que lógica. Se utiliza comúnmente para particionar verticalmente una tabla para aprovechar la división de E / S entre dispositivos físicos u otras optimizaciones de consultas asociadas con la segregación de datos o datos a los que se accede con menos frecuencia que deben mantenerse más seguros que el resto de los atributos en el mismo objeto (SSN, Salario, etc.)

La única consideración lógica que prescribe una relación 1-1 es cuando ciertos atributos solo se aplican a algunas de las entidades. Sin embargo, en la mayoría de los casos hay una forma mejor / más normalizada de modelar los datos a través de la extracción de entidades.

El escenario más común que puedo pensar es cuando tienes BLOB. Digamos que desea almacenar imágenes grandes en una base de datos (por lo general, no es la mejor manera de almacenarlas, pero a veces las restricciones lo hacen más conveniente). Normalmente, desearía que el blob estuviera en una tabla separada para mejorar las búsquedas de los datos no blob.

En SQL, es imposible aplicar una relación 1: 1 entre dos tablas que es obligatoria en ambos lados (a menos que las tablas sean de solo lectura). Para la mayoría de los propósitos prácticos, una relación "1: 1" en SQL realmente significa 1: 0 | 1.

La incapacidad de soportar la cardinalidad obligatoria en las restricciones referenciales es una de las serias limitaciones de SQL. Las restricciones "diferibles" en realidad no cuentan porque son solo una forma de decir que la restricción no se aplica algunas veces.

En cualquier lugar, dos entidades totalmente independientes compartían una relación uno a uno. Debe haber muchos ejemplos:

persona <-> dentista (es 1: N, ¡entonces está mal!)

persona <-> doctor (es 1: N, ¡entonces también está mal!)

persona <-> cónyuge (¡es 1: 0 | 1, por lo que es sobre todo errónea!)

EDITAR: Sí, esos fueron ejemplos bastante malos, particularmente si siempre estaba buscando un 1: 1, no un 0 o 1 en ambos lados. Supongo que mi cerebro estaba disparando mal :-)

Entonces, intentaré de nuevo. Resulta, después de pensarlo un poco, que la única forma en que puede tener dos entidades separadas que deben (en lo que respecta al software) estar juntas todo el tiempo es que ellas existan juntas en categorías superiores. Entonces, si y solo si cae en una descomposición más baja, las cosas son y deberían estar separadas, pero en el nivel superior no pueden vivir juntas. Contexto, entonces es la clave.

Para una base de datos médica, es posible que desee almacenar información diferente sobre regiones específicas del cuerpo, manteniéndolas como una entidad separada. En ese caso, un paciente tiene solo una cabeza, y la necesitan, o no son pacientes. (También tienen un corazón y otros órganos necesarios). Si está interesado en rastrear cirugías, por ejemplo, cada región debe ser una entidad separada única.

En un sistema de producción / inventario, si está rastreando el ensamblaje de vehículos, entonces ciertamente desea ver el progreso del motor de forma diferente a la carrocería del automóvil, sin embargo, existe una relación de uno a uno. Un cuidado debe tener un motor y solo uno (o ya no sería un "automóvil"). Un motor pertenece a solo un auto.

En cada caso, podría producir las entidades separadas como un gran registro, pero dado el nivel de descomposición, sería incorrecto. Son, en estos contextos específicos, entidades verdaderamente independientes, aunque es posible que no aparezcan en un nivel superior.

Pablo.

En lugar de usar vistas para restringir el acceso a los campos, a veces tiene sentido mantener los campos restringidos en una tabla separada a la que solo ciertos usuarios tienen acceso.

En mi opinión, una relación 1: 1 mapea una herencia de clase en un SGBDR. Hay una tabla A que contiene los atributos comunes, es decir, el estado de la clase partent. Cada estado de clase heredado se mapea en el RDBMS con una tabla B con una relación 1: 1 con una tabla A, que contiene los atributos especializados. El nombre de la tabla A también contiene un campo "tipo" que representa la funcionalidad "fundición"

Adiós Mario

En términos de ciencia pura, sí, son inútiles.

En las bases de datos reales, a veces es útil mantener un campo poco utilizado en una tabla separada: para acelerar las consultas con este y solo este campo; para evitar bloqueos, etc.

Escasez. La relación de datos puede ser técnicamente 1: 1, pero las filas correspondientes no tienen que existir para cada fila. Entonces, si tiene veinte millones de filas y hay un conjunto de valores que solo existe para el 0.5% de ellos, el ahorro de espacio es enorme si las inserta en una tabla que puede estar escasamente poblada.

He descubierto que cuando hago una relación 1: 1 es totalmente por una razón sistémica, no por una razón relacional.

Por ejemplo, descubrí que poner los aspectos reservados de un usuario en 1 tabla y colocar los campos editables del usuario en una tabla diferente permite lógicamente escribir esas reglas sobre permisos en esos campos mucho más fácilmente.

Pero tienes razón, en teoría, las relaciones 1: 1 son completamente artificiales, y son casi un fenómeno. Sin embargo, lógicamente, permite que los programas y optimizaciones resuelvan la base de datos más fácilmente.

La mayoría de las respuestas altamente clasificadas dan una base de datos muy útil y razones de optimización para las relaciones 1: 1, pero quiero centrarme en nada más que ejemplos "en la naturaleza" donde las relaciones 1: 1 ocurren naturalmente.

Tenga en cuenta una característica importante de la implementación de la base de datos de la mayoría de estos ejemplos: no se conserva información histórica sobre la relación 1: 1. Es decir, estas relaciones son 1: 1 en cualquier punto dado en el tiempo. Si el diseñador de la base de datos desea registrar los cambios en la relación participantes a lo largo del tiempo, entonces las relaciones se convierten en 1: M o M: M; pierden su naturaleza 1: 1. Con eso entendido, aquí va:

"Is-A" o supertipo / subtipo o herencia / relaciones de clasificación : esta categoría es cuando una entidad es un tipo específico de otra entidad. Por ejemplo, podría haber una entidad Empleado con atributos que se apliquen a todos los empleados, y luego diferentes entidades para indicar tipos específicos de empleados con atributos únicos para ese tipo de empleado, por ejemplo, Doctor, Contador, Piloto, etc. Este diseño evita nulos múltiples desde muchos empleados no tendrían los atributos especializados de un subtipo específico. Otros ejemplos en esta categoría podrían ser Producto como supertipo y ManufacturingProduct y MaintenanceSupply como subtipos; Animal como supertipo y Perro y Gato como subtipos; etc. Tenga en cuenta que cada vez que intenta mapear una jerarquía de herencia orientada a objetos en una base de datos relacional (como en un modelo relacional de objetos), este es el tipo de relación que representa dichos escenarios.
Relaciones "jefe" , como gerente, presidente, presidente, etc., donde una unidad organizativa puede tener solo un jefe y una persona puede ser jefe de una sola unidad organizativa. Si esas reglas se aplican, entonces usted tiene una relación 1: 1, como un gerente de un departamento, un CEO de una compañía, etc. Las relaciones de "jefe" no solo se aplican a las personas. El mismo tipo de relación ocurre si hay una sola tienda como la sede de una empresa, o si solo una ciudad es la capital de un país, por ejemplo.
Algunos tipos de escasa asignación de recursos , por ejemplo, a un empleado se le puede asignar un solo vehículo de la empresa a la vez (por ejemplo, un camión por camionero, un taxi por conductor de taxi, etc.). Un colega me dio este ejemplo recientemente.
Matrimonio (al menos en jurisdicciones legales donde la poligamia es ilegal): una persona puede casarse con una sola persona a la vez. Obtuve este ejemplo de un libro de texto que usó esto como un ejemplo de una relación única de 1: 1 cuando una empresa registra matrimonios entre sus empleados.
Reservas coincidentes : cuando se realiza una reserva única y luego se cumple como dos entidades separadas. Por ejemplo, un sistema de alquiler de automóviles puede registrar una reserva en una entidad, y luego una renta real en una entidad separada. Aunque dicha situación podría diseñarse alternativamente como una sola entidad, podría tener sentido separar las entidades ya que no todas las reservas se cumplen, y no todos los alquileres requieren reservas, y ambas situaciones son muy comunes.

Repito la advertencia que hice anteriormente de que la mayoría de estos son relaciones 1: 1 solo si no se registra información histórica. Entonces, si un empleado cambia su rol en una organización, o un gerente se responsabiliza de un departamento diferente, o un empleado es reasignado a un vehículo, o alguien queda viudo y se vuelve a casar, entonces los participantes de la relación pueden cambiar. Si la base de datos no almacena ningún historial previo sobre estas relaciones 1: 1, entonces siguen siendo relaciones legítimas 1: 1. Pero si la base de datos registra información histórica (como agregar fechas de inicio y finalización para cada relación), entonces casi todos se convierten en relaciones M: M.

Hay dos excepciones notables a la nota histórica: en primer lugar, algunas relaciones cambian tan raramente que la información histórica normalmente no se almacena. Por ejemplo, la mayoría de las relaciones IS-A (por ejemplo, tipo de producto) son inmutables; es decir, nunca pueden cambiar. Por lo tanto, el punto de registro histórico es discutible; estos siempre se implementarían como relaciones naturales 1: 1. En segundo lugar, las fechas de la tienda de relaciones de alquiler de reservaciones por separado, ya que la reserva y el alquiler son eventos independientes, cada uno con sus propias fechas. Como las entidades tienen sus propias fechas, en lugar de la relación 1: 1 que tiene una fecha de inicio, estas permanecerán como relaciones 1: 1 aunque se almacene información histórica.

La mayoría de las veces, se cree que los diseños son 1: 1 hasta que alguien pregunte "bueno, ¿por qué no puede ser 1: muchos"? El divorcio de los conceptos el uno del otro prematuramente se realiza en anticipación a este escenario común. Persona y Dirección no se unen tan fuertemente. Mucha gente tiene varias direcciones. Y así...

Por lo general, dos espacios de objetos separados implican que uno o ambos pueden multiplicarse (x: muchos). Si dos objetos fueron verdaderamente, verdaderamente 1: 1, incluso filosóficamente, entonces es más una relación de is. Estos dos "objetos" son en realidad partes de un objeto completo.

La mejor razón que puedo ver para una relación 1: 1 es un subtipo SuperType de diseño de base de datos. Creé una estructura de datos MLS inmobiliaria basada en este modelo. Hubo cinco feeds de datos diferentes; Residencial, Comercial, MultiFamily, Hoteles y Terrenos.

Creé una propiedad llamada SuperType que contenía datos comunes a cada una de las cinco fuentes de datos separadas. Esto permitió realizar búsquedas "simples" muy rápidas en todos los tipos de datos.

Creo cinco subtipos separados que almacenan los elementos de datos únicos para cada uno de los cinco feeds de datos. Cada registro SuperType tenía una relación 1: 1 con el registro SubType apropiado.

Si un cliente deseaba una búsqueda detallada, tenía que seleccionar un tipo Súper Sub, por ejemplo, PropertyResidential.

Las relaciones 1-1 también son necesarias si tiene demasiada información. Existe una limitación de tamaño de registro en cada registro de la tabla. A veces, las tablas se dividen en dos (con la información más comúnmente consultada en la tabla principal) solo para que el tamaño del registro no sea demasiado grande. Las bases de datos también son más eficientes al consultar si las tablas son estrechas.

Las relaciones 1: 1 realmente no tienen sentido si estás en la normalización, ya que cualquier cosa que sea 1: 1 se mantendría en la misma tabla.

En el mundo real sin embargo, a menudo es diferente. Es posible que desee dividir sus datos para que coincidan con su interfaz de aplicaciones.

Los uso principalmente por algunas razones. Una es la diferencia significativa en la tasa de cambio de datos. Algunas de mis tablas pueden tener pistas de auditoría donde rastrear versiones anteriores de registros, si solo me importa rastrear versiones anteriores de 5 de 10 columnas dividir esas 5 columnas en una tabla separada con un mecanismo de seguimiento de auditoría es más eficiente. Además, puedo tener registros (por ejemplo, para una aplicación de contabilidad) que solo son de escritura. No puede cambiar los montos en dólares o la cuenta para la que estaban, si cometió un error, entonces necesita hacer un registro correspondiente para ajustar el registro incorrecto y luego crear una entrada de corrección. Tengo restricciones en la tabla que imponen el hecho de que no pueden ser actualizadas o eliminadas, pero puedo tener un par de atributos para ese objeto que son maleables, que se guardan en una tabla separada sin la restricción de la modificación. Otra vez que hago esto es en aplicaciones de registros médicos. Hay datos relacionados con una visita que no pueden modificarse una vez que se inicia sesión, y otros datos relacionados con una visita que se pueden cambiar después del cierre de sesión. En ese caso, dividiré los datos y pondré un disparador en la mesa bloqueada que rechace las actualizaciones de la tabla bloqueada cuando se cierre la sesión, pero permitiendo actualizaciones a los datos que el médico no está desactualizando.

Otro afiche comentó que 1: 1 no está normalizado, no estoy de acuerdo con eso en algunas situaciones, especialmente en la subtipificación. Digamos que tengo una tabla de empleados y la clave principal es su SSN (es un ejemplo, vamos a guardar el debate sobre si esta es una buena clave o no para otro hilo). Los empleados pueden ser de diferentes tipos, por ejemplo temporales o permanentes, y si son permanentes, tienen más campos para completar, como el número de teléfono de la oficina, que no debería ser nulo si el tipo = ''Permanente''. En una tercera base de datos de forma normal, la columna debe depender solo de la clave, es decir, del empleado, pero en realidad depende del empleado y del tipo, por lo que una relación 1: 1 es perfectamente normal y deseable en este caso. También evita tablas demasiado dispersas, si tengo 10 columnas que normalmente están llenas, pero 20 columnas adicionales solo para ciertos tipos.

No es necesario para fines de seguridad, pero hay mejores formas de realizar comprobaciones de seguridad. Imagina, creas una llave que solo puede abrir una puerta. Si la llave puede abrir cualquier otra puerta, debe hacer sonar la alarma. En esencia, puede tener "CitizenTable" y "VotingTable". Citizen One vote por Candidate One que se almacena en la Tabla de votación. Si el ciudadano uno aparece nuevamente en la mesa de votación, entonces debería ser una alarma. Sea un consejo, esta es una relación de uno a uno porque no nos referimos al campo de candidato, nos estamos refiriendo a la mesa de votación y la tabla de ciudadanos.

Ejemplo:

Citizen Table id = 1, citizen_name = "EvryBod" id = 2, citizen_name = "Lesly" id = 3, citizen_name = "Wasserman" Candidate Table id = 1, citizen_id = 1, candidate_name = "Bern Nie" id = 2, citizen_id = 2, candidate_name = "Bern Nie" id = 3, citizen_id = 3, candidate_name = "Hill Arry"

Entonces, si vemos la mesa de votación así:

Voting Table id = 1, citizen_id = 1, candidate_name = "Bern Nie" id = 2, citizen_id = 2, candidate_name = "Bern Nie" id = 3, citizen_id = 3, candidate_name = "Hill Arry" id = 4, citizen_id = 3, candidate_name = "Hill Arry" id = 5, citizen_id = 3, candidate_name = "Hill Arry"

Podríamos decir que el ciudadano número 3 es un mentiroso en el fuego que engañó a Bern Nie. Solo un ejemplo.

Posiblemente si tiene algún tipo de objetos tipeados en su base de datos.

Diga en una tabla, T1, que tiene las columnas C1, C2, C3 ... con una relación de uno a uno. Está bien, está en forma normalizada. Ahora diga en una tabla T2, usted tiene las columnas C1, C2, C3, ... (los nombres pueden diferir, pero dicen que los tipos y el rol es el mismo) con una relación de uno a uno también. Está bien para T2 por las mismas razones que con T1.

Sin embargo, en este caso, veo un ajuste para una tabla T3 separada, manteniendo C1, C2, C3 ... y una relación de uno a uno de T1 a T3 y de T2 a T3. Incluso veo más un ajuste si existe otra tabla, con la que ya existe una a varias C1, C2, C3 ... digamos de la tabla A a múltiples filas en la tabla B. Entonces, en lugar de T3, usa B y tiene una relación de uno a uno de T1 a B, lo mismo para de T2 a B, y sigue siendo la misma relación de uno a múltiples de A a B.

Creo que la normalización no concuerda con esto, y eso puede ser una idea fuera de él: identificar tipos de objetos y mover objetos de un mismo tipo a su propio grupo de almacenamiento, usando una relación uno a uno de algunas tablas, y una a múltiples relación de algunas otras tablas.

Puede crear una tabla de relaciones uno a uno si hay algún beneficio de rendimiento significativo. Puede poner los campos poco utilizados en una tabla separada.

Si está utilizando los datos con uno de los ORM populares, es posible que desee dividir una tabla en varias tablas para que coincida con su Jerarquía de objetos.

Su pregunta se puede interpretar de varias maneras, debido a la forma en que la redactó. Las respuestas muestran esto.

Definitivamente, puede haber relaciones 1: 1 entre elementos de datos en el mundo real. Sin dudas al respecto. La relación "es una" generalmente es uno a uno. Un auto es un vehiculo Un carro es un vehículo. Un vehículo podría ser un automóvil. Algunos vehículos son camiones, en cuyo caso un vehículo no es un automóvil. Varias respuestas abordan esta interpretación.

Pero creo que lo que realmente estás preguntando es ... cuando existen relaciones 1: 1, ¿deberían dividirse las tablas alguna vez? En otras palabras, ¿debería tener alguna vez dos tablas que contengan exactamente las mismas claves? En la práctica, la mayoría de nosotros solo analizamos claves primarias, y no otras claves candidatas, pero esa pregunta es ligeramente diferente.

Las reglas de normalización para 1NF, 2NF y 3NF nunca requieren descomponer (dividir) una tabla en dos tablas con la misma clave principal. No he resuelto si poner un esquema en BCNF, 4NF o 5NF puede dar como resultado dos tablas con las mismas claves. Fuera de mi cabeza, voy a adivinar que la respuesta es no.

Hay un nivel de normalización llamado 6NF. La regla de normalización para 6NF definitivamente puede dar como resultado dos tablas con la misma clave primaria. 6NF tiene la ventaja sobre 5NF de que NULLS se puede evitar por completo. Esto es importante para algunos, pero no para todos, los diseñadores de bases de datos. Nunca me he molestado en poner un esquema en 6NF.

En 6NF, los datos faltantes pueden representarse por una fila omitida, en lugar de una fila con un NULL en alguna columna.

Hay razones distintas a la normalización para dividir tablas. A veces, las tablas divididas dan como resultado un mejor rendimiento. Con algunos motores de base de datos, puede obtener los mismos beneficios de rendimiento dividiendo la tabla en lugar de dividirla. Esto puede tener la ventaja de mantener el diseño lógico fácil de entender, mientras proporciona al motor de base de datos las herramientas necesarias para acelerar las cosas.

También es una forma de ampliar una tabla que ya está en producción con menos riesgo (percibido) que un cambio de base de datos "real". Ver una relación 1: 1 en un sistema heredado a menudo es un buen indicador de que los campos se agregaron después del diseño inicial.

También puedo pensar en situaciones en las que tiene un modelo OO en el que usa herencia, y el árbol de herencia debe persistir en la base de datos.

Por ejemplo, tienes una clase de Pájaro y Pez que ambos heredan de Animal. En su DB puede tener una tabla ''Animal'', que contiene los campos comunes de la clase Animal, y la tabla Animal tiene una relación uno-a-uno con la tabla Bird, y una relación uno-a-uno con el Fish mesa.

En este caso, no es necesario tener una tabla Animal que contenga una gran cantidad de columnas con nulos para albergar las propiedades Bird y Fish, donde todas las columnas que contienen Fish-data se establecen en NULL cuando el registro representa un pájaro.

En cambio, tiene un registro en la tabla Birds que tiene una relación de uno a uno con el registro en la tabla Animal.

Una razón es la eficiencia de la base de datos. Tener una relación 1: 1 le permite dividir los campos que se verán afectados durante un bloqueo de fila / tabla. Si la tabla A tiene muchas actualizaciones y la tabla b tiene toneladas de lecturas (o tiene toneladas de actualizaciones de otra aplicación), el bloqueo de la tabla A no afectará lo que está sucediendo en la tabla B.

Otros plantean un buen punto. La seguridad también puede ser una buena razón dependiendo de cómo las aplicaciones, etc. están llegando al sistema. Tiendo a tomar un enfoque diferente, pero puede ser una manera fácil de restringir el acceso a ciertos datos. Es realmente fácil negar el acceso a una determinada tabla en caso de apuro.

La entrada de mi blog al respecto.

Una relación 1: 1 típicamente indica que ha particionado una entidad más grande por alguna razón. A menudo se debe a razones de rendimiento en el esquema físico, pero también puede ocurrir en el lado lógico si se espera que una gran parte de los datos sea "desconocida" al mismo tiempo (en cuyo caso tiene un 1: 0 o 1: 1, pero no más).

Como ejemplo de una partición lógica: tiene datos sobre un empleado, pero hay un conjunto más grande de datos que deben recopilarse, si y solo si seleccionan tener cobertura de salud. Mantendría los datos demográficos con respecto a la cobertura de salud en una tabla diferente para dar una partición de seguridad más fácil y evitar transportar esos datos en consultas no relacionadas con el seguro.

Un ejemplo de una partición física sería la misma información alojada en múltiples servidores. Es posible que mantenga los datos demográficos de cobertura de salud en otro estado (por ejemplo, la oficina de recursos humanos) y la base de datos primaria solo puede vincularse a ella a través de un servidor vinculado ... evitando replicar datos confidenciales a otras ubicaciones, pero haciéndolo disponible para (asumiendo aquí raras) consultas que lo necesitan.

La partición física puede ser útil siempre que tenga consultas que necesiten subconjuntos consistentes de una entidad más grande.

información extendida que solo es necesaria en ciertos escenarios. en aplicaciones heredadas y lenguajes de programación (como RPG) donde los programas se compilan sobre las tablas (por lo que si la tabla cambia, debe recompilar el programa o programas). Tag along files también puede ser útil en casos en los que tenga que preocuparse por el tamaño de la tabla.