TL;RD No necesitas para declarar una "relación", es decir, clave externa (FK) para consultar. Pero es una buena idea . Cuando lo hace, un FK puede hacer referencia a una clave principal (PK) o cualquier otra columna ÚNICA.
Las PK y FK se denominan erróneamente "relaciones" en algunos métodos y productos. Las relaciones de aplicación están representadas por tablas . (Tablas base y resultados de consultas). Las PK y FK son restricciones:le dicen al DBMS que solo pueden surgir ciertas situaciones, para que pueda notar cuándo comete ciertos errores. No son relaciones, son declaraciones verdaderas en y de cada estado de la base de datos y situación de la aplicación. No necesita conocer las restricciones para actualizar y consultar una base de datos.
Simplemente sepa lo que cada tabla significa . Las tablas base tienen significados dados por DBA que le indican qué significan sus filas. Las consultas también tienen significados que le indican qué significan sus filas. Los significados de las consultas se combinan a partir de los significados de la tabla base en paralelo con la forma en que sus valores de resultado se combinan a partir de los valores y condiciones de la tabla base.
image_tbl-- la imagen [Id] está en un álbum llamado [nombre del álbum], se llama [nombre], tiene fecha [fecha y hora] y tiene un comentario [comentario]album_tbl-- el álbum [ID del álbum] se llama [nombre del álbum]
No tienes para declarar cualquier PK/ÚNICO o FK! Pero es una buena idea porque entonces el DBMS puede rechazar actualizaciones imposibles/erróneas. Un PK/UNIQUE dice que un valor de subfila para sus columnas debe aparecer solo una vez. Un FK dice que un valor de subfila para sus columnas debe aparecer como un valor de sufila PK/ÚNICO en su tabla de referencia. El hecho de que estas limitaciones se mantengan en las tablas base significa que ciertas limitaciones se mantienen en los resultados de las consultas. Pero los significados de esos resultados de consulta son según las combinaciones de tabla y condición de la consulta, independientemente de esas limitaciones. Por ejemplo, si los nombres de los álbumes son únicos o no,
image_tbl JOIN album_tbl USING albumName-- la imagen [Id] está en un álbum llamado [albumName], se llama [name], tiene fecha [dateTime] y tiene un comentario [comentario] Y el álbum [albumID] se llama [albumName]
El único problema aquí es que si los nombres de los álbumes no son únicos, saber el nombre del álbum de una imagen no le dirá en qué álbum está; solo sabes que está en un álbum con ese nombre. Por otro lado, si los nombres de los álbumes son únicos, no necesita album_tbl albumID.
Entonces, si los nombres de los álbumes son únicos, declare albumName UNIQUE en album_tbl. Luego, en image_tbl identifique el álbum por alguna columna PK/ÚNICA de album_tbl. Dado que album_id presumiblemente está presente solo con el propósito de identificar álbumes, normalmente esperaríamos que se elija. Luego, en image_tbl declare esa columna como un FK que hace referencia a album_tbl.
Los índices PS generalmente aceleran las consultas a costa de algo de tiempo y espacio. Una declaración de clave principal en una declaración de tabla declara automáticamente un índice. Es una buena idea indexar conjuntos de columnas PK, UNIQUE y FK.
