Esta es una buena pregunta. No entiendo por qué alguien te ha marcado. (Así que te marqué una copia de seguridad, porque todos estamos aquí para aprender). De todos modos, esta pregunta muestra que no entiendes completamente las relaciones de la entidad (sin rudeza). De los cuales hay cuatro tipos (técnicamente solamente 3) a continuación:
One to One
One to Many
Many to One
Many to Many
uno a uno (1: 1): En este caso una mesa se ha roto en dos partes a fin de cumplir con la normalización , o más generalmente el principio abierto abierto.
Normalisation conformidad: es posible que tenga una regla comercial que indique que cada cliente tiene una sola cuenta. Técnicamente, en este caso podría decir que el cliente y la cuenta podrían estar todos en la misma tabla, pero esto rompe las reglas de normalización, por lo que los divide y hace un 1: 1.
Open-Close principle conformidad: Una tabla de clientes, podría tener identificación, primero & apellidos y dirección. Más tarde, alguien decide agregar una fecha de nacimiento y con ella la capacidad de calcular la edad junto con otros campos muy necesarios. Este es un ejemplo simplificado de uno a uno, pero se obtiene el uso principal para extender su base de datos sin romper el código existente. Gran parte del código escrito (por desgracia) está estrechamente vinculado a la base de datos, por lo que los cambios en la estructura de una tabla romperán el código. Agregar un 1: 1 como este extenderá la tabla para cumplir con los nuevos requisitos sin modificar el original, lo que permite que el código viejo continúe funcionando normalmente y el nuevo código para hacer uso de las nuevas características de db.
La desventaja de la normalización y la extensión de tablas usando relaciones 1: 1 de esta manera es el rendimiento. Muchas veces en sistemas muy usados, el primer objetivo para aumentar el rendimiento de la base de datos es la des-normalización y la combinación de dichas tablas en una sola tabla, y la optimización de los índices eliminando así la necesidad de utilizar combinaciones y leer desde múltiples tablas. La normalización/des-normalización no es algo bueno o malo, ya que depende de las necesidades del sistema. La mayoría de los sistemas generalmente comienzan el cambio normalizado cuando es necesario, pero este cambio debe hacerse con mucho cuidado, como se mencionó, si el código está estrechamente vinculado a la estructura de la base de datos, es casi seguro que hará que el sistema falle. es decir, cuando combina 2 tablas, una deja de existir, todo el código que incluye esa tabla ahora inexistente falla hasta que se modifique (en términos db, imagine relaciones de conexión con cualquiera de las tablas en 1: 1, cuando elimina esas tablas , esto rompe las relaciones, por lo que la estructura tiene que ser modificada en gran medida para compensar.Desafortunadamente, esos diseños malos son mucho más fáciles de detectar en el mundo de DB que en el mundo del software en la mayoría de los casos y normalmente no se nota que algo salió mal en el código hasta que se deshace) a menos que el sistema esté diseñado correctamente con separation of concerns en mente .
Es lo más parecido que se puede obtener a la herencia en la programación orientada a objetos. Pero no es lo mismo.
uno a muchos (1: M)/Muchos a Uno (M: 1): Estas dos relaciones (4 HENSE por qué se hacen 3), son los tipos de relaciones más populares. Ambos son del mismo tipo de relación, lo único que cambia es tu punto de vista. Un ejemplo Un cliente tiene muchos números de teléfono o, alternativamente, muchos números de teléfono pueden pertenecer a un cliente.
En la programación orientada a objetos esto se consideraría composición. No es herencia, pero estás diciendo que un ítem está compuesto de muchas partes. Esto generalmente se representa con matrices/listas/colecciones, etc. dentro de las clases en lugar de una estructura de herencia.
Many to Many (M: M): Este tipo de relación con la tecnología actual es imposible. Por esta razón, necesitamos dividirlo en dos relaciones de uno a muchos con una tabla de "asociación" uniéndolas. Los muchos lados de las dos relaciones de uno a muchos siempre están en la tabla de asociación/enlace.
Para su ejemplo, la persona que dijo que necesita muchos para muchos es correcta. Porque de dos a muchos es efectivamente una relación de muchas (es decir, más de una) a muchas. Esta es la única forma en que lograría que su sistema funcione. A menos que tenga la intención de investigar el campo de relational calculus para encontrar algún tipo nuevo de relación que lo permita.
También para esas relaciones (m2m) tiene dos opciones, cree una clave compuesta en la tabla del enlazador para que la combinación de campos se convierta en una entrada única (si está interesado en la optimización de db ésta es la opción más lenta, pero menos espacio). Alternativamente, puede crear un tercer campo con una columna de identificación generada automáticamente y convertirla en la clave principal (para la optimización de BD, esta es la opción más rápida, pero requiere más espacio).
En su ejemplo específicamente arriba ...
Un ejemplo del mundo real sería números de teléfono, los usuarios y empresas. Una empresa puede tener muchos números de teléfono, un usuario puede tener muchos números de teléfono, pero idealmente el usuario no debe proporcionar el mismo número de teléfono que la empresa, ya que habría contenido duplicado en la base de datos.
Esta sería una relación de muchos a muchos con la tabla de números de teléfono como tabla de enlaces entre las empresas y los usuarios. Como se explicó, para asegurarse de que no se repita ningún número de teléfono, simplemente configúrelo como la clave principal o use otra clave principal y establezca el campo del número de teléfono como único.
Para ese tipo de preguntas, realmente se trata de cómo las frasee. Lo que está causando que te confundas al respecto, y cómo superas esta confusión para ver que la solución es simple. Reformule el problema de la siguiente manera. Comience preguntando si es uno a uno, si la respuesta es no, continúe. Luego pregunte si es uno a muchos, si la respuesta es no seguir adelante. La única otra opción restante es de muchos a muchos. Tenga cuidado, asegúrese de haber considerado las 2 primeras preguntas cuidadosamente antes de continuar. Muchas personas con poca experiencia en bases de datos a menudo complican los problemas definiendo de uno a muchos tantos como muchos. Una vez más, el tipo de relación más popular de lejos es de uno a muchos (yo diría que el 90%) con muchos a muchos y uno a uno dividiendo el 10% restante 7/3 respectivamente.Pero esas cifras son solo mi perspectiva personal, así que no las cite como estadísticas estándar de la industria. Mi punto es hacer un extra extra seguro de que definitivamente no es uno para muchos antes de elegir de muchos a muchos. Vale la pena el esfuerzo adicional.
Ahora, para encontrar la tabla de encuadernadores entre las dos, decida cuáles son sus dos tablas principales y qué campos deben compartirse entre ellas. En este caso, tanto la empresa como las tablas de usuarios deben compartir el teléfono. Hense necesita hacer una nueva tabla de teléfono como el enlazador.
La alarma de advertencia de un malentendido debe aparecer tan pronto como decida que ninguno de los 3 está trabajando para usted. Esto debería ser suficiente para decirte que simplemente no estás formulando la pregunta de relación correctamente. Lo mejorarás a medida que pase el tiempo, pero es una habilidad esencial y realmente debes dominarlo lo antes posible para tu propio sanaty.
Por supuesto, también podría ir a una base de datos orientada a objetos que permitirá un rango de otras relaciones llamadas relaciones "jerárquicas". Eso es genial si estás pensando en convertirte en un programador también. Pero no recomendaría esto, ya que te hará doler la cabeza cuando comiences a encontrar maneras de combinar los diversos tipos de relaciones. Especialmente dado que no hay mucha necesidad ya que casi todas las bases de datos en el mundo consisten solo de esos 3 tipos de relaciones a menos que sean algo súper especial.
Espero que esta fue una respuesta razonable. Gracias por tomarse el tiempo para leerlo.
En su ejemplo del "mundo real", ¿no sería mejor simplemente poner una restricción ÚNICA en la columna del número de teléfono? – David
Esto parece espurio. Si un niño solo está relacionado con los padres, y solo uno de ellos, es de varios a uno. – Patrick87
Espere un minuto: trabajé en un centro de llamadas donde TODOS teníamos el mismo número de teléfono, al menos en lo que respecta al mundo exterior, así que si tenía que completar un pedido, y mi compañero de trabajo tenía que llenar uno También deberíamos proporcionar el mismo número de teléfono porque de eso nos llamaría su empresa. – David