Esta pregunta muestra que no comprende completamente las relaciones entre entidades (sin intención de mala educación). De los cuales hay cuatro tipos (técnicamente solo 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 tabla se ha dividido en dos partes para cumplir con la normalización, o más generalmente el principio abierto cerrado.
Normalización Cumplimiento:es posible que tenga una regla de negocios que cada cliente tenga solo una 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 una relación 1:1.
Principio de abrir-cerrar Cumplimiento:una tabla de clientes, puede tener identificación, nombre y apellido, y dirección. Más tarde, alguien decide agregar una fecha de nacimiento y, con ella, la capacidad de calcular la edad junto con un montón de otros campos muy necesarios. Este es un ejemplo demasiado simplificado de uno a uno, pero obtiene el uso principal para ampliar su base de datos sin romper el código existente. Gran parte del código escrito (lamentablemente) está estrechamente relacionado con 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 permitirá que el código antiguo continúe funcionando normalmente y que el nuevo código haga uso de las nuevas características de la base de datos.
La desventaja de normalizar y extender tablas usando relaciones 1:1 de esta manera es el rendimiento. A menudo, en sistemas muy utilizados, el primer objetivo para aumentar el rendimiento de la base de datos es desnormalizar y combinar dichas tablas en una sola tabla y optimizar los índices, eliminando así la necesidad de usar uniones y leer de varias tablas. La normalización/desnormalización no es ni buena ni mala, ya que depende de las necesidades del sistema. La mayoría de los sistemas generalmente comienzan con un cambio normalizado cuando es necesario, pero este cambio debe realizarse con mucho cuidado, como se mencionó, si el código está estrechamente acoplado a la estructura de la base de datos, casi definitivamente 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 modifica (en términos de db, imagine conectar relaciones a cualquiera de las tablas en el 1:1, cuando elimina esas tablas , esto rompe las relaciones y, por lo tanto, la estructura debe modificarse mucho para compensarlo. Desafortunadamente, estos malos diseños son mucho más fáciles de detectar en el mundo de la base de datos que en el mundo del software en la mayoría de los casos y, por lo general, no se nota que algo salió mal. en el código hasta que todo se desmorone) a menos que el sistema esté diseñado correctamente con separación de preocupaciones en mente.
Es lo más parecido a la herencia en la programación orientada a objetos. Pero no es exactamente lo mismo.
Uno a muchos (1:M) / Muchos a uno (M:1): Estas dos relaciones (por eso 4 se convierten en 3), son los tipos de relación más populares. Ambos son el 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 elemento se compone de muchas partes. Esto generalmente se representa con matrices/listas/colecciones, etc. dentro de las clases en lugar de una estructura de herencia.
Muchos a Muchos (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. El lado de muchos de las dos relaciones de uno a muchos siempre está en la tabla de asociación/enlace.
Para su ejemplo, la persona que dijo que necesita muchos a muchos tiene razón. Porque una relación de dos a muchos es efectivamente una relación de muchos (es decir, más de uno) a muchos. Esta es la única manera de hacer que su sistema funcione. A menos que tenga la intención de investigar el campo del cálculo relacional para encontrar algún nuevo tipo de relación que permita esto.
También para tales relaciones (m2m) tiene dos opciones, o bien crea 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 la base de datos, esta es la opción más lenta, pero ocupa menos espacio). Alternativamente, crea un tercer campo con una columna de identificación generada automáticamente y la convierte en la clave principal (para la optimización de la base de datos, esta es la opción más rápida, pero ocupa más espacio).
En su ejemplo específicamente arriba...
Esta sería una relación de muchos a muchos con la tabla de números de teléfono como la tabla de enlace entre empresas y 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 configure el campo del número de teléfono como único.
Para ese tipo de preguntas, todo depende de cómo las formules. Lo que te está confundiendo acerca de esto y cómo superas esta confusión para ver 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. La siguiente pregunta es uno a muchos, si la respuesta es no seguir adelante. La única otra opción que queda es muchos a muchos. Sin embargo, tenga cuidado, asegúrese de haber considerado las primeras 2 preguntas cuidadosamente antes de continuar. Muchas personas sin experiencia en bases de datos a menudo complican los problemas definiendo uno a muchos como muchos a muchos. Una vez más, el tipo de relación más popular con diferencia es uno a muchos (yo diría que 90 %) con muchos a muchos y uno a uno dividiendo el 10 % restante en 7/3 respectivamente. Pero esas cifras son solo mi perspectiva personal, así que no las cites como estadísticas estándar de la industria. Mi punto es asegurarme de que definitivamente no es uno a muchos antes de elegir muchos a muchos. Vale la pena el esfuerzo extra.
Ahora, para encontrar la tabla de enlace entre las dos, decida cuáles son sus dos tablas principales y qué campos deben compartirse entre ellas. En este caso, las tablas de empresa y usuario deben compartir el teléfono. Por lo tanto, debe crear una nueva tabla de teléfonos como el enlazador.
La alarma de advertencia de malentendido debería mostrarse tan pronto como decida que ninguno de los 3 está funcionando para usted. Esto debería ser suficiente para decirle que simplemente no está formulando la pregunta de relación correctamente. Mejorarás con el paso del tiempo, pero es una habilidad esencial y deberías dominarla lo antes posible por tu propia salud.
Por supuesto, también puede ir a una base de datos orientada a objetos que permitirá una variedad de otras relaciones llamadas relaciones "jerárquicas". Eso es genial si también estás pensando en convertirte en programador. Pero no recomendaría esto, ya que te dolerá la cabeza cuando comiences a encontrar formas de combinar los diversos tipos de relaciones. Especialmente dado que no hay mucha necesidad, ya que casi todas las bases de datos del mundo consisten solo en esos 3 tipos de relaciones, a menos que sean algo muy especial.
Espero que esta haya sido una respuesta razonable. Gracias por tomarse el tiempo de leerlo.
