diseño de base de datos SQL

Question

Estoy haciendo una base de datos para un programa en el que se supone que debo modelar algunas relaciones en la familia. por ejemplo: X es padre de Y, Y es el hijo de X

Por lo tanto, tengo un Usuarios mesa con toda la información sobre cada miembro, así que pensé en hacer una de muchos a muchos relación entre el Usuarios mesa y sí de modo que el < strong> Member_Member mesa puente va a tener las columnas "FK_FromID, FK_ToID" como clave compuesta (¿es esto correcto?) y < como una clave strong> "FK_RelationType" / extranjera RelationTypes tabla que tendrá el tipo de relación "padre, madre, hijo, hija", y dos relaciones de ir a muchos como uno de los miembros de la mesa a estas dos claves externas

Mi problema es : cuando se elimina si decido en cascada a continuación, voy a hacer ciclos, porque si elimino un miembro continuación, habrá dos pases de eliminación en los registros relacionados en Member_Member puente, sabiendo que en el programa cada vez que inserto una relación padre voy a insertar una relación de hijo, así como en la tabla Member_Member, ¿hay una forma o una solución posible habilitar en cascada de manera que cada vez que elimino un miembro voy a borrar los registros relacionados en Member_member independientemente de que se está grabando ya sea en una o una de la columna de clave externa

Por lo tanto, no sé qué hacer, se trata de un diseño correcto en el primer lugar o qué? , ¿Qué debo hacer sobre el ciclismo, también ¿qué te parece un mejor diseño para el mismo problema se debe saber que necesito para especificar qué tipo de relación entre las dos partes

Muchas gracias por cualquier ayuda, y lo siento por mala Inglés Bishoy

Answer 1

SQL no maneja los problemas de "red" como esto muy bien.

La mesa de bridge miembro de miembros es un nombre terrible. Es un "miembro-padre" (o "padre-hijo") puente. cuadros puente no deben disponer de una "compuesto". tablas de puente tienen una clave sustituta (sólo un número secuencial) y un par de referencias a otras tablas FK. Los dos de FK debe tener nombres como "miembro" y "padre" para que sea perfectamente claro cuál es la relación de esta tabla.

Todo el mundo tiene un padre. No todo el mundo tiene hijos. Algunos padres no tienen los padres en esta base de datos; ellos son los padres "top".

Es más fácil si los mejores padres tienen filas en el puente entre padres e hijos con un padre FK es NULL. De esa manera a evitar súper complejo externa se une - cada miembro tiene al menos una fila miembro de padres; idealmente dos.

Se pueden encontrar muchos "ciclismo" cuestiones ya que las relaciones son transitivos.

Tenga en cuenta que no se puede - en una sola consulta SQL estándar - Encontrar todos los miembros de la familia, o de todos los padres de nuevo a la parte superior de la familia, o de todos los niños y nietos. Hay extensiones de SQL que hacen esto posible, pero el estándar no maneja bien.

La eliminación en cascada no funciona bien porque las relaciones en una familia se ha dirigido en dos maneras (padres a hijos, a los padres del niño), pero SQL sólo tiene un tipo de dirección (referencia FK).

Se puede tratar de asegurar que cada miembro debe tener al menos una (y como máximo dos) filas de "miembro-padres" y el borrado de un miembro borra las dos filas de "Miembro- padre" y las teclas tienen los nombres propios, es posible hacer que las partes de este trabajo.

Tenga en cuenta que cuando se elimina un miembro, esto va a romper sus relaciones padre. Se elimina la fila miembro-matriz. Eso es bueno. ¿Qué pasa con sus hijos? Las otras filas que tienen miembros y los padres en referencia a este padre eliminados se ha roto. ¿Qué significa esto? ¿Lo que debe hacerse?

  

No hay estándar respuesta. Extracción de filas de una gráfica conexa hojas de los elementos   desconectado. Hay que trabajar a cabo algunas reglas sensatas para eso.

Desde SQL no lo hace así, todos los diseños se parecen tener problemas.

Answer 2

1. Suponiendo que cada miembro sólo puede tener una madre y un padre, que sería capaz de derivar todas las relaciones por el simple hecho de mantener un campo mother_id y father_id en la tabla members.

   Información Sin embargo, esto sólo funcionan si la base de datos no han desaparecido. Por ejemplo, si el miembro de X es el hermano del miembro Y, no habría manera de saber esto a menos que los padres de X e Y se almacenan en la base de datos.

   Si su base de datos no va a tener la información que falta, lo anterior podría ser más fácil de gestionar la integridad de los datos. Las consultas pueden ser un poco compleja, sin embargo.

2. El puente member_member sugeriste tiene un problema grave, ya que implica un sentido de la relación, por lo que si X es el padre de Y, Y es también el hijo de X. sugerido para definir la relación de dos veces en ambas direcciones, pero en general esto no se recomienda. Esta es una forma de duplicación de datos, y se puede luchar para exigir la integridad referencial con la duplicación de datos. Recuerde que el DBMS no sabe que X es padre de Y es el mismo que Y es el hijo de X.

Soy consciente de que esto no es una respuesta completa, pero sólo algunas observaciones. Estoy totalmente de acuerdo con la S. Lott respuesta como en que no hay manera estándar de "resolver "esto con bases de datos relacionales.