¿Hay siempre un momento en que el uso de una base de datos 1: 1 relación tiene sentido?

https://stackoverflow.com/questions/517417

21-08-2019
|

Pregunta

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

Nombre: SSN? Tendría ellos en la misma mesa PersonaID: AddressID? Una vez más, la misma tabla.

I puedo llegar a un trillón de ejemplos de 1: muchos o muchos: muchos (con tablas intermedias apropiadas), pero nunca una 1:. 1

Me estoy perdiendo algo obvio?

Solución

Una relación 1: 1 por lo general indica que se ha repartido una entidad más grande por alguna razón. A menudo es debido a razones de rendimiento en el esquema físico, pero puede ocurrir en el lado de la lógica, así si se espera que una gran parte de los datos a ser "desconocido" al mismo tiempo (en cuyo caso usted tiene un 1: 0 o 1:. 1, pero no más)

Como ejemplo de una partición lógica: tiene datos acerca de un empleado, pero hay un conjunto mayor de datos que necesitan ser recogidos, si y sólo si se selecciona para tener cobertura de salud. Me gustaría mantener los datos demográficos con respecto a la cobertura de salud en una tabla diferente para ambos dan más fácil de partición de seguridad y para evitar que los datos transportar alrededor de consultas no relacionadas con los seguros.

Un ejemplo de una partición física sería el mismo datos que están siendo alojados en varios servidores. Me permite mantener los datos demográficos de cobertura médica en otro estado (donde la oficina de recursos humanos es, por ejemplo) y la base de datos primaria sólo se puede enlazar con él a través de un servidor vinculado ... evitando la replicación de datos sensibles a otros lugares, sin embargo, su puesta a disposición de (suponiendo que aquí rara) consultas que lo necesitan.

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

Otros consejos

Una de las razones es la eficiencia de la base de datos. Tener una relación 1: 1 permite dividir los campos que se verán afectadas durante un bloqueo de registro / mesa. Si la tabla A tiene un montón de cambios y la Tabla B tiene un montón de lecturas (o tiene un montón de cambios desde otra aplicación), a continuación, bloqueo de tablas de A no afectará a lo que está pasando en el cuadro B.

Otros traen un buen punto. La seguridad también puede ser una buena razón dependiendo de cómo las aplicaciones etc. están golpeando el sistema. Yo tiendo a adoptar un enfoque diferente, pero puede ser una manera fácil de restringir el acceso a ciertos datos. Es muy fácil simplemente negar el acceso a una determinada tabla en caso de apuro.

Mi Blog entrada sobre él.

poca densidad. La relación de datos puede ser técnicamente 1: 1, pero filas correspondientes no tienen que existir para cada fila. Así que si usted tiene veinte millones de filas y hay un conjunto de valores que sólo existe para el 0,5% de ellos, el ahorro de espacio son muy amplias si se le empuja a cabo esas columnas en una tabla que puede ser escasamente poblada.

La mayoría de las respuestas altamente clasificados en-dan sintonización base de datos y optimización razones muy útiles para el 1: 1 de las relaciones, pero yo quiero centrar en nada más que "en la naturaleza" ejemplos en 1:. Ocurren naturalmente 1 relaciones

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

"Is-A" o supertipo / subtipo o las relaciones de herencia / clasificación : Esta categoría es cuando una entidad es un tipo específico de otra entidad. Por ejemplo, podría haber una entidad Employee con los atributos que se aplican a todos los empleados, y luego diferentes entidades para indicar tipos específicos de los empleados con atributos únicos a ese tipo de empleado, por ejemplo, Médico, contable, Piloto, etc. Este diseño evita múltiples nulos ya que muchos empleados no tendrían los atributos especializados de un subtipo específico. Otros ejemplos de esta categoría podrían ser producto como supertipo, y ManufacturingProduct y MaintenanceSupply como subtipos; Animales como supertipo y de perros y gatos como subtipos; etc. Tenga en cuenta que cada vez que se intenta asignar una jerarquía de herencia orientada a objetos en una base de datos relacional (por ejemplo, en un modelo relacional de objetos), este es el tipo de relación que representa este tipo de escenarios.
relaciones "jefe" , como gerente, presidente, presidente, etc., donde una unidad organizativa puede tener un solo jefe, y una persona puede ser el jefe de una sola unidad organizativa . Si se aplican esas reglas, entonces usted tiene una relación 1: 1, como un gerente de un departamento, un CEO de una empresa, etc. relaciones "jefe" no sólo se aplican a las personas. El mismo tipo de relación se produce si sólo hay una tienda como la sede de una empresa, o si sólo una ciudad es la capital de un país, por ejemplo.
Algunos tipos de asignación de recursos escasos , por ejemplo, un empleado se le puede asignar un único vehículo de la empresa a la vez (por ejemplo, un camión al camionero, uno de taxis por conductor de taxi, etc.). Un colega me dio este ejemplo recientemente.
Boda (al menos en las jurisdicciones legales donde la poligamia es ilegal): una persona puede estar casado con una sola persona a la vez. Tengo este ejemplo de un libro de texto que utiliza esto como un ejemplo de un 1:. 1 relación unaria cuando una empresa registra los matrimonios entre sus empleados
reservas a juego : cuando se hace una reserva única y luego cumplió como dos entidades separadas. Por ejemplo, un sistema de alquiler de coche podría registrar una reserva en una sola entidad, y luego un alquiler real en una entidad separada. A pesar de esta situación, alternativamente, podría ser diseñado como una sola entidad, podría tener sentido para separar las entidades ya no se cumplen todas las reservas, y no todos los alquileres requieren reservas, y ambas situaciones son muy comunes.

repito la advertencia que hice antes de que la mayoría de estos son 1: 1 relaciones sólo si no se ha registrado la información histórica. Por lo tanto, si un empleado cambia su rol en una organización, o un gerente asume la responsabilidad de un departamento diferente, o un empleado se reasigna un vehículo, o alguien que es viuda y se vuelve a casar, a continuación, los participantes relación puede cambiar. Si la base de datos no almacena ningún historial previo de estas relaciones 1: 1, a continuación, siguen siendo legítima 1: 1 para las relaciones. Pero si la base de datos registra información histórica (por ejemplo, agregar las fechas de inicio y fin para cada relación), entonces prácticamente todos se convierten en M:. Relaciones M

Hay dos excepciones notables ala 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 IS-A relaciones (por ejemplo, tipo de producto) son inmutables; es decir, que nunca pueden cambiar. Por lo tanto, el punto de registro histórico es discutible; estos siempre se implementan como naturales las relaciones 1: 1. En segundo lugar, la tienda de la relación reserva-alquiler de las fechas por separado, ya que la reserva y el alquiler son eventos independientes, cada uno con sus propias fechas. Dado que las entidades tienen sus propias fechas, en lugar de la relación 1: 1 con que tiene una fecha de inicio, éstos quedarían como 1: 1. Relaciones a pesar de que la información histórica se almacena

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

No puede sin duda ser de 1: 1 relaciones entre los elementos de datos en el mundo real. No hay duda al respecto. El "es una" relación es generalmente uno a uno. Un coche es un vehículo. Un coche es un vehículo. Un vehículo podría ser un coche. Algunos vehículos son camiones, en cuyo caso un vehículo no es un coche. Varias respuestas frente a esta interpretación.

Pero creo que lo que realmente está pidiendo es ... cuando 1: 1 existen relaciones, deben ser divididos tablas vez? En otras palabras, si alguna vez tiene dos tablas que contienen exactamente las mismas claves? En la práctica, la mayoría de nosotros sólo analizar las claves principales, y no otras claves candidatas, pero esa pregunta es un poco diferent.

Las reglas de normalización para 1NF, 2NF y 3NF nunca requieren descomposición (división) de una tabla en dos tablas con la misma clave primaria. No he trabajado a cabo ya sea poniendo un esquema en BCNF, 4NF o 5NF vez puede dar lugar a dos tablas con las mismas teclas. De la parte superior de mi cabeza, voy a suponer que la respuesta es no.

Hay un nivel de normalización denominado 6NF. La regla de normalización para 6NF sin duda puede resultar en dos cuadros con la misma clave primaria. 6NF tiene la ventaja sobre 5NF que NULLS pueden evitarse por completo. Esto es importante para algunos, pero no todos, los diseñadores de bases de datos. Nunca he tomado la molestia de poner un esquema en 6NF.

En 6NF datos que faltan pueden ser representar por una fila omitido, en lugar de una fila con un valor NULL en alguna columna.

Hay razones distintas de la normalización para las tablas de división. A veces las tablas divididas dan como resultado un mejor rendimiento. Con algunos motores de bases de datos, puede obtener los mismos beneficios de rendimiento mediante la partición de la tabla en lugar de realmente su división. Esto puede tener la ventaja de mantener el diseño lógico fácil de entender, al tiempo que el motor de base de datos de las herramientas necesarias para acelerar las cosas.

Los utilizo principalmente por algunas razones. Una de ellas es una diferencia significativa en la tasa de cambio de datos. Algunos de mis tablas pueden tener pistas de auditoría en el que realizar un seguimiento de las versiones anteriores de los registros, si sólo se preocupan de seguimiento de las versiones anteriores de 5 de cada 10 columnas que dividen las 5 columnas en una tabla separada con un mecanismo de seguimiento de auditoría en él es más eficiente. Además, es posible que tenga registros (digamos para una aplicación de contabilidad) que son de sólo escritura. No se puede cambiar la cantidad en dólares, o en la cuenta de que eran, si ha cometido un error, entonces usted necesita para hacer un registro correspondiente a escribir ajustar fuera del registro incorrecto, a continuación, crear una entrada de corrección. Tengo restricciones en la tabla hacer cumplir el hecho de que no pueden ser actualizados o borrados, pero puede tener un par de atributos para ese objeto que son maleables, aquellos se mantienen en una tabla separada sin la restricción de la modificación. Otra vez que hago esto es en aplicaciones de historia clínica. No hay datos relacionados con una visita que no se puede cambiar una vez que se firmó en, y otros datos relacionados con una visita que se puede cambiar después de visto bueno. En ese caso, voy a dividir los datos y poner un gatillo de la tabla bloqueada rechazar cambios a la tabla bloqueada cuando se firmaron, pero que permiten cambios a los datos que el médico no está firmando fuera de.

Otro cartel comentado en 1: 1 no se normaliza, no estoy de acuerdo con que en algunas situaciones, especialmente subtipificación. Decir que tengo una tabla de empleados y la clave principal es su número de seguro social (que es un ejemplo, vamos a guardar el debate sobre si esta es una buena clave o no para el otro hilo). Los empleados pueden ser de diferentes tipos, por ejemplo temporal o permanente y si son permanentes tienen más campos a rellenar, como el número de teléfono de la oficina, que sólo debe ser no nulo si las type = 'permanente'. En una tercera base de datos de forma normal la columna debería depender sólo de la clave, lo que significa que el empleado, pero en realidad depende de los empleados y el tipo, por lo que una relación 1: 1 es perfectamente normal y deseable en este caso. También evita que las tablas excesivamente escaso, si tengo 10 columnas que normalmente están llenos, pero 20 columnas adicionales sólo para ciertos tipos.

El escenario más común que se me ocurre es cuando se tiene BLOB de. Digamos que desea almacenar grandes imágenes en una base de datos (por lo general, no es la mejor manera de almacenarlos, pero a veces las limitaciones que sea más conveniente). Que normalmente se desea que la burbuja esté en una tabla separada para mejorar las búsquedas de los datos no blob.

En cuanto a la ciencia pura, sí, son inútiles.

En las bases de datos reales que a veces es útil para mantener un campo rara vez se utiliza en una tabla separada: a acelerar las consultas que utilizan este y sólo este campo; para evitar bloqueos, etc.

En lugar de utilizar vistas a restringir el acceso a los campos, a veces tiene sentido para mantener los campos restringidos en una tabla diferente a la que sólo ciertos usuarios tienen acceso.

También puedo pensar en situaciones donde se tiene un modelo orientado a objetos en los que se utiliza la herencia, y el árbol de herencia tiene que ser mantenido a la base de datos.

Por ejemplo, usted tiene un pájaro de clase y pescado uno de ellos heredando del animal. En su base de datos que podría tener una tabla de 'animal', que contiene los campos comunes de la clase de animal, y la mesa animal tiene una relación de uno a uno con la tabla de aves, y una relación de uno a uno con el pescado mesa.

En este caso, usted no tiene que tener una tabla de animales que contiene una gran cantidad de columnas anulables sostener al ave y pescado de propiedades, donde todas las columnas que contienen datos de Pescado-se establecen en NULL cuando el registro representa una pájaro.

En su lugar, usted tiene un registro de la Pájaro-tabla que tiene una relación uno-a-uno con el registro de la tabla de animales.

1-1 relaciones también son necesarios si tiene demasiada información. Hay un límite de tamaño de registro en cada registro de la tabla. A veces se dividen las tablas en dos (con la información más comúnmente consultado en la tabla principal) sólo para que el tamaño del registro no será demasiado grande. Bases de datos también son más eficientes en la consulta de si las tablas son estrechas.

Es también una manera de extender una tabla que ya está en producción con un menor riesgo (percibido) que un cambio de base de datos "real". Ver a un 1:. Relación 1 en un sistema de legado es a menudo un buen indicador de que los campos se añadieron después el diseño inicial

En SQL es imposible de hacer cumplir una relación 1: 1 entre dos tablas que es obligatorio en ambos lados (de sólo lectura a menos que las mesas están). A efectos prácticos un "1: 1" relación en SQL significa realmente 1: 0 | 1

La incapacidad para soportar cardinalidad obligatoria en las restricciones de referencia es una de las serias limitaciones de SQL. restricciones "DEFERRABLE" no cuentan realmente, ya que son simplemente una forma de decir que la restricción no se aplica una parte del tiempo.

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

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

Por ejemplo, he encontrado que poniendo los aspectos reservados de un usuario en la tabla 1 y poniendo los campos editables de usuario del usuario en una tabla diferente lógicamente permite escribir esas normas sobre permisos en los campos tanto mucho más fácil.

Pero estás en lo correcto, en teoría, 1: 1 relaciones son completamente artificial, y son casi un fenómeno. Sin embargo, lógicamente, que permite a los programas y optimizaciones abstraer la base de datos más fácil.

La mayoría de las veces, se cree que los diseños a ser de 1: 1 hasta que alguien le pregunta: "bueno, por qué no puede ser de 1: muchos"? Divorciarse de los conceptos entre sí antes de tiempo se hace en previsión de este escenario común. Persona y dirección no se unen tan fuertemente. Una gran cantidad de personas que tienen múltiples direcciones. Y así sucesivamente ...

Por lo general, dos espacios de objetos separados implica que uno o ambos se puede multiplicar (x: muchos). Si dos objetos eran realmente, realmente 1: 1, incluso filosóficamente, entonces es más de una es-relación. Estos dos "objetos" son realmente partes de un objeto entero.

información ampliada que sólo se necesita en ciertos escenarios. en las aplicaciones heredadas y lenguajes de programación (como RPG), donde los programas se compilan sobre las mesas (por lo que si la tabla cambia usted tiene que volver a compilar el programa (s)). Tag largo de archivos también puede ser útil en los casos en que usted tiene que preocuparse por el tamaño de la tabla.

Lo más frecuente es que es más de un físico que la construcción lógica. Se utiliza comúnmente para verticalmente particionar una tabla para tomar ventaja de la división de E / S a través de dispositivos físicos u otras optimizaciones de consulta asociada con la segregación de datos o datos que necesita ser mantenido más seguro que el resto de los atributos en el mismo objeto con menos frecuencia visitada (SSN, salario, etc.).

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

La mejor razón que puedo ver por una relación 1: 1 es un subtipo supertipo de diseño de base de datos. He creado una estructura de datos Inmobiliaria MLS basado en este modelo. Había cinco datos diferentes alimentos; Residenciales, comerciales, multifamiliares, hoteles y tierra.

He creado un supertipo llamada propiedad que contenía datos que eran comunes a cada uno de los cinco canales de datos por separado. Esto permitió búsquedas muy rápidas "simples" en todos los tipos de datos.

Creo cinco subtipos diferentes que almacenan los elementos de datos únicos para cada uno de los datos se alimenta cinco. Cada registro tenía un supertipo. 1: 1 relación al registro apropiado Subtipo

Si un cliente quería una búsqueda detallada tuvieron que seleccionar un tipo Super-Sub por ejemplo PropertyResidential.

En mi opinión una relación 1: 1 asigna una herencia de clases en un RDBMS. Hay una mesa de A que contiene los atributos comunes, es decir, el estado de la clase partent Cada estado de clase heredada se mapea en el RDBMS con una mesa de B con una relación 1: 1 a una tabla, que contiene los atributos especializados. La tabla namend A contiene también un campo de "tipo" que representa la funcionalidad "casting"

Adiós Mario

1: 1 relaciones realmente no tienen sentido si usted está en la normalización como cualquier cosa que sería de 1: 1. Se mantiene en la misma mesa

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

Es posible que si tiene algún tipo de objetos escritos en su base de datos.

Say en una tabla, T1, que tiene las columnas C1, C2, C3 ... con una una a una relación. Está bien, está en forma normalizada. Ahora decir en una tabla T2, tiene columnas C1, C2, C3, ... (los nombres pueden diferir, pero dicen que los tipos y el papel es el mismo) con una una a una relación demasiado. Está bien para T2 para las mismas razones que con T1.

En este caso sin embargo, veo un ajuste para una T3 tabla separada, la celebración de C1, C2, C3 ... y una una a una relación de T1 a T3 y de T2 a T3. incluso más veo un ataque si existen otra mesa, con los que ya existen de uno a múltiples C1, C2, C3 ... decir del cuadro A de múltiples filas de la tabla B. Entonces, en lugar de T3, se utiliza B, y tienen una una a una relación de T1 a B, el mismo para de T2 a B, y sigue siendo el mismo a la relación múltiple de a a B.

Creo que la normalización no está de acuerdo con esto, y que puede ser una idea fuera de ella: la identificación de los tipos de objetos y mover objetos de un mismo tipo para su propia agrupación de almacenamiento, utilizando una relación de uno a otro de algunas mesas, y una uno a la relación múltiple a partir de algunas otras tablas.

Puede crear una tabla de relación uno a uno si hay algún beneficio significativo del rendimiento. Usted puede poner los campos rara vez se utiliza en la tabla separada.

no es necesario grandes para fines de seguridad pero mejores maneras de realizar los controles de seguridad. Imagínese, se crea una clave que sólo puede abrir una puerta. Si la llave puede abrir cualquier otra puerta, que debe sonar la alarma. En esencia, se puede tener "CitizenTable" y "VotingTable". Un ciudadano de votar por un candidato que se almacena en la mesa de votación. Si es ciudadano de uno aparece en la mesa de votación una vez más, entonces su debe haber una alarma. Sé consejos, se trata de una relación uno a uno, porque no estamos refiriendo al campo de candidatos, nos estamos refiriendo a la mesa de votación y la mesa de los 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 como 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"

Se puede decir que el número de los ciudadanos 3 es un pantalón del mentiroso en el fuego que engañaron Berna Nie. Sólo un ejemplo.

En cualquier lugar eran dos entidades completamente independientes comparten una relación uno-a-uno. Debe haber un montón de ejemplos:

persona <-> dentista (! Su 1: N, por lo que su mal)

persona <-> médico (! Su 1: N, así que también es equivocado)

persona <-> cónyuge (! El 1: 0 | 1, por lo que su mayoría mal)

EDIT: Sí, esos eran bastante malos ejemplos, sobre todo si yo siempre estaba buscando una relación 1: 1, no un 0 o un 1 a cada lado. Creo que mi cerebro estaba mal tiro: -)

Por lo tanto, voy a intentarlo de nuevo. Resulta que, después de un poco de pensamiento, que la única forma en que puede tener dos entidades separadas que deben (por lo que el software va) estar juntos todo el tiempo es que ellos existen juntos en una mayor categorización. Entonces, si y sólo si se encuentra en una descomposición más baja, las cosas son y deben ser separados, pero en el nivel superior que no pueden vivir el uno sin el otro. Contexto, a continuación, 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éndolos como una entidad separada. En ese caso, un paciente tiene una sola cabeza, y tienen que tener, o no son un paciente. (También tienen un corazón, y un número de otros órganos individuales necesarias). Si usted está interesado en el seguimiento de las cirugías por ejemplo, a continuación, cada región debe ser una entidad separada única.

En un sistema de producción / inventario, si realiza un seguimiento del montaje de vehículos, a continuación, que sin duda quiere ver el progreso del motor diferente a la carrocería del vehículo, sin embargo hay una relación uno a uno. Un cuidado debe tener un motor, y sólo uno (o no sería un 'coche' ya no). Un motor pertenece a un solo coche.

En cada caso se podría producir las entidades separadas como un registro grande, pero dado el nivel de descomposición, que sería un error. Ellos son, en estos contextos específicos, entidades verdaderamente independientes, a pesar de que no aparezcan por lo que en un nivel más alto.

Paul.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow