¿Hay una matriz de respuesta que puedo utilizar para decidir si necesito una clave externa o no?
-
22-09-2019 - |
Pregunta
Por ejemplo, tengo una tabla que almacena las clases, y una tabla que almacena class_attributes. class_attributes tiene un class_attribute_id y una id-clase, mientras que las clases tiene una id-clase.
supongo que si un conjunto de datos es "un niño únicamente" o "pertenece únicamente a" o "es propiedad exclusiva de", entonces necesito una FK a identificar al padre. Sin id_clase en la tabla class_attributes nunca pude averiguar a qué clase pertenece a este atributo.
Tal vez hay una matriz de respuesta es útil para esto?
Solución
Wikipedia es útil.
En el contexto de relacional bases de datos, una clave externa es una restricción de referencia entre dos Tablas. 1 en la clave, extranjeros una columna o un conjunto de columnas en uno (Referencia) de tabla que se refiere a una columna o conjunto de columnas en otro (Referencia) tabla. Las columnas de la tabla de referencia debe ser el principal o la tecla de otro candidato en el tabla de referencia.
(y va en en más y más detalle)
Si desea aplicar la restricción de que cada fila de class_attributes aplica a exactamente una fila de clases, se necesita una clave externa. Si no se preocupan por hacer cumplir esta (es decir, usted está muy bien tener los atributos de las clases inexistentes), que no es necesario un FK.
Otros consejos
No tengo una matriz de respuesta, pero sólo con fines de aclaración, estamos hablando de Bata normalización
http://en.wikipedia.org/wiki/Database_normalization
Y en cierta medida Desnormalización
Yo diría, que es el otro alrededor de camino. En primer lugar, diseñar qué tipo de objetos que necesita tener. Para aquellos creará una mesa.
Parte de esta fase es el diseño de las teclas, es decir las combinaciones de atributos (columnas) que identifican de manera única el objeto. Usted puede o no añadir una clave artificial o clave sustituta por conveniencia o por razones de rendimiento. A partir de estas teclas, por lo general elige una clave canónica, la clave principal, que intenta utilizar constantemente para identificar objetos en dicha tabla (que mantienen las otras llaves también, sirven para garantizar la unicidad como una regla de negocio, no tanto por identificattion propósitos.)
A continuación, piense lo que existen relaciones entre los objetos. Un objeto que está 'propiedad' de otro objeto, o un objeto que hace referencia a otro objeto necesita alguna manera de identificar su objeto relacionado. En la tabla (tabla secundaria) que corresponde agregar columnas para hacer una clave externa a punto a la clave primaria de la tabla referenciada.
Este se encarga de todo relaciones uno a muchos.
A veces, un objeto puede estar relacionado varias veces a otro objeto. Por ejemplo, una orden se puede utilizar para ordenar productos múltiples, sino un producto puede aparecer en varios pedidos también. Para esas relaciones, diseña una tabla (tabla de intersección - en este ejemplo, order_items) separada. Esta tabla tendrá una clave única creada de dos claves externas: uno que señalan a los padres de un (órdenes), uno para el otro padre (productos). Y de nuevo, se agrega las columnas a la tabla de intersección que se necesita para crear esas claves externas.
Así que en resumen, que las primeras claves de diseño y las claves externas, sólo entonces empezar a añadir columnas para ponerlas en práctica.
No se preocupe con el tipo de relación -. Que tiene más que ver con la cardinalidad de la relación
Si usted tiene una relación uno-a-muchos, entonces lo que desee asignar una clave principal a la menor de las mesas, y almacenarlo como una clave externa en la tabla más grande.
También lo haría con las relaciones uno-a-uno, pero algunas personas argumentan que se debe evitar.
En el caso de una relación de muchos a muchos, que querría hacer una tabla de unión y, a continuación, tienen cada una de las tablas originales tienen una clave externa a la tabla de unión.