Una clave externa es un conjunto de atributos en una tabla que hace referencia a la clave principal de otra tabla, vinculando estas dos tablas. En el contexto de las bases de datos relacionales , una clave externa está sujeta a una restricción de dependencia de inclusión de que las tuplas que consisten en los atributos de la clave externa en una relación , R, también deben existir en alguna otra relación (no necesariamente distinta), S; además, esos atributos también deben ser una clave candidata en S. [1] [2] [3]
En otras palabras, una clave foránea es un conjunto de atributos que hace referencia a una clave candidata. Por ejemplo, una tabla llamada EQUIPO puede tener un atributo, MEMBER_NAME, que es una clave externa que hace referencia a una clave candidata, PERSON_NAME, en la tabla PERSON. Dado que MEMBER_NAME es una clave externa, cualquier valor que exista como nombre de un miembro en TEAM también debe existir como nombre de una persona en la tabla PERSON; es decir, cada miembro de un EQUIPO es también una PERSONA.
Puntos importantes a tener en cuenta: -
La tabla que contiene la clave externa se denomina tabla secundaria y la tabla que contiene la clave candidata se denomina tabla referenciada o principal. [4] En el modelado e implementación relacional de bases de datos, una clave candidata es un conjunto de cero o más atributos, cuyos valores se garantiza que serán únicos para cada tupla (fila) en una relación. El valor o la combinación de valores de los atributos clave candidatos para cualquier tupla no se pueden duplicar para ninguna otra tupla en esa relación.
Dado que el propósito de la clave externa es identificar una fila particular de la tabla a la que se hace referencia, generalmente se requiere que la clave externa sea igual a la clave candidata en alguna fila de la tabla principal o, de lo contrario, no tenga ningún valor (el valor NULL ) . 2] ). Esta regla se denomina restricción de integridad referencial entre las dos tablas. [5] Debido a que las violaciones de estas restricciones pueden ser la fuente de muchos problemas de bases de datos, la mayoría de los sistemas de administración de bases de datos proporcionan mecanismos para garantizar que cada clave externa no nula corresponda a una fila de la tabla a la que se hace referencia. [6] [7] [8]
Por ejemplo, considere una base de datos con dos tablas: una tabla CLIENTE que incluye todos los datos del cliente y una tabla PEDIDO que incluye todos los pedidos de los clientes. Supongamos que la empresa requiere que cada pedido se refiera a un solo cliente. Para reflejar esto en la base de datos, se agrega una columna de clave externa a la tabla ORDER (por ejemplo, CUSTOMERID), que hace referencia a la clave principal de CLIENTE (por ejemplo, ID). Debido a que la clave principal de una tabla debe ser única, y debido a que CUSTOMERID solo contiene valores de ese campo de clave principal, podemos suponer que, cuando tenga un valor, CUSTOMERID identificará al cliente particular que realizó el pedido. Sin embargo, esto ya no se puede asumir si la tabla PEDIDO no se mantiene actualizada cuando se eliminan filas de la tabla CLIENTE o se modifica la columna ID, y trabajar con estas tablas puede volverse más difícil. Muchas bases de datos del mundo real solucionan este problema "inactivando" en lugar de eliminar físicamente las claves externas de la tabla maestra, o mediante complejos programas de actualización que modifican todas las referencias a una clave externa cuando se necesita un cambio.
Las claves externas desempeñan un papel esencial en el diseño de bases de datos . Una parte importante del diseño de una base de datos es asegurarse de que las relaciones entre entidades del mundo real se reflejen en la base de datos mediante referencias, utilizando claves externas para hacer referencia de una tabla a otra. [9] Otra parte importante del diseño de una base de datos es la normalización de la base de datos , en la que las tablas se dividen y las claves externas hacen posible su reconstrucción. [10]
Varias filas en la tabla de referencia (o secundaria) pueden hacer referencia a la misma fila en la tabla de referencia (o principal). En este caso, la relación entre las dos tablas se denomina relación de uno a muchos entre la tabla de referencia y la tabla referenciada.
Además, la tabla secundaria y principal pueden, de hecho, ser la misma tabla, es decir, la clave externa hace referencia a la misma tabla. Esta clave externa se conoce en SQL:2003 como clave externa autorreferenciada o recursiva. En los sistemas de gestión de bases de datos, esto suele lograrse vinculando una primera y una segunda referencia a la misma tabla.
Una tabla puede tener varias claves externas y cada clave externa puede tener una tabla principal diferente. El sistema de base de datos aplica cada clave externa de forma independiente . Por lo tanto, se pueden establecer relaciones en cascada entre tablas utilizando claves externas.
Una clave foránea se define como un atributo o conjunto de atributos en una relación cuyos valores coinciden con una clave primaria en otra relación. La sintaxis para agregar dicha restricción a una tabla existente se define en SQL:2003 como se muestra a continuación. Omitir la lista de columnas en la REFERENCEScláusula implica que la clave externa hará referencia a la clave principal de la tabla a la que se hace referencia. Asimismo, las claves foráneas se pueden definir como parte de la CREATE TABLEdeclaración SQL.
CREAR TABLA child_table ( col1 CLAVE PRIMARIA INTEGER , col2 CARACTER VARIABLE ( 20 ), col3 INTEGER , col4 INTEGER , CLAVE EXTRANJERA ( col3 , col4 ) REFERENCIAS parent_table ( col1 , col2 ) EN ELIMINAR CASCADA ) Si la clave externa es una sola columna, la columna se puede marcar como tal usando la siguiente sintaxis:
CREAR TABLA child_table ( col1 INTEGER CLAVE PRIMARIA , col2 CARACTER VARIABLE ( 20 ), col3 INTEGER , col4 INTEGER REFERENCIAS parent_table ( col1 ) AL ELIMINAR CASCADA ) Las claves externas se pueden definir con una declaración de procedimiento almacenado .
sp_foreignkey tabla_niño , tabla_padre , col3 , col4 Debido a que el sistema de gestión de bases de datos impone restricciones referenciales, debe garantizar la integridad de los datos si se van a eliminar (o actualizar) filas en una tabla referenciada. Si todavía existen filas dependientes en las tablas de referencia, se deben considerar esas referencias. SQL:2003 especifica 5 acciones referenciales diferentes que tendrán lugar en tales sucesos:
Siempre que se eliminen (o actualicen) filas de la tabla principal (referenciada), las filas respectivas de la tabla secundaria (de referencia) con una columna de clave externa coincidente también se eliminarán (o actualizarán). Esto se denomina eliminación (o actualización) en cascada.
Un valor no se puede actualizar ni eliminar cuando existe una fila en una tabla secundaria o de referencia que hace referencia al valor en la tabla a la que se hace referencia.
De manera similar, una fila no se puede eliminar siempre que haya una referencia a ella desde una tabla secundaria o de referencia.
Para comprender mejor RESTRICT (y CASCADE), puede resultar útil notar la siguiente diferencia, que puede no quedar clara de inmediato. La acción referencial CASCADE modifica el "comportamiento" de la propia tabla (secundaria) donde se usa la palabra CASCADE. Por ejemplo, ON DELETE CASCADE dice efectivamente "Cuando la fila a la que se hace referencia se elimina de la otra tabla (tabla maestra), elimínela también de mí ". Sin embargo, la acción referencial RESTRICT modifica el "comportamiento" de la tabla maestra, no de la tabla secundaria, ¡aunque la palabra RESTRICT aparece en la tabla secundaria y no en la tabla maestra! Entonces, ON DELETE RESTRICT dice efectivamente: "Cuando alguien intenta eliminar la fila de la otra tabla (tabla maestra), evite la eliminación de esa otra tabla (y, por supuesto, tampoco la elimine de mí, pero ese no es el punto principal). aquí)."
RESTRICT no es compatible con Microsoft SQL 2012 y versiones anteriores.
NO ACCIÓN y RESTRICCIÓN son muy parecidos. La principal diferencia entre NO ACTION y RESTRICT es que con NO ACTION la verificación de integridad referencial se realiza después de intentar alterar la tabla. RESTRICT realiza la verificación antes de intentar ejecutar la instrucción ACTUALIZAR o ELIMINAR . Ambas acciones referenciales actúan de la misma manera si falla la verificación de integridad referencial: la declaración ACTUALIZAR o ELIMINAR resultará en un error.
En otras palabras, cuando se ejecuta una declaración ACTUALIZAR o ELIMINAR en la tabla referenciada usando la acción referencial NO ACCIÓN, el DBMS verifica al final de la ejecución de la declaración que no se viola ninguna de las relaciones referenciales. Esto es diferente de RESTRICT, que supone desde el principio que la operación violará la restricción. Al usar NO ACTION, los desencadenantes o la semántica de la declaración en sí pueden producir un estado final en el que no se violan relaciones de clave externa cuando finalmente se verifica la restricción, permitiendo así que la declaración se complete exitosamente.
En general, la acción realizada por el DBMS para SET NULL o SET DEFAULT es la misma tanto para ON DELETE como para ON UPDATE: el valor de los atributos de referencia afectados se cambia a NULL para SET NULL y al valor predeterminado especificado para SET DEFAULT .
Las acciones referenciales generalmente se implementan como activadores implícitos (es decir, activadores con nombres generados por el sistema, a menudo ocultos). Como tales, están sujetas a las mismas limitaciones que los activadores definidos por el usuario y es posible que sea necesario modificar su orden de ejecución en relación con otros activadores. consideró; en algunos casos, puede ser necesario reemplazar la acción referencial con su activador equivalente definido por el usuario para garantizar el orden de ejecución adecuado o para solucionar las limitaciones de la tabla de mutación.
Otra limitación importante aparece con el aislamiento de transacciones : es posible que sus cambios en una fila no puedan implementarse en cascada por completo porque la fila está referenciada por datos que su transacción no puede "ver" y, por lo tanto, no puede aplicar en cascada. Un ejemplo: mientras su transacción intenta renumerar la cuenta de un cliente, una transacción simultánea intenta crear una nueva factura para ese mismo cliente; si bien una regla CASCADE puede corregir todas las filas de la factura que su transacción puede ver para mantenerlas consistentes con la fila del cliente renumerada, no afectará a otra transacción para corregir los datos allí; Debido a que la base de datos no puede garantizar datos consistentes cuando se confirman las dos transacciones, una de ellas se verá obligada a retroceder (a menudo por orden de llegada).
CREAR TABLA cuenta ( acct_num INT , monto DECIMAL ( 10 , 2 )); CREAR DISPARADOR ins_sum ANTES DE INSERTAR EN la cuenta PARA CADA FILA SET @ sum = @ sum + NUEVO . cantidad ; Como primer ejemplo para ilustrar las claves foráneas, supongamos que una base de datos de cuentas tiene una tabla con facturas y cada factura está asociada con un proveedor en particular. Los detalles del proveedor (como el nombre y la dirección) se guardan en una tabla separada; A cada proveedor se le asigna un 'número de proveedor' para identificarlo. Cada registro de factura tiene un atributo que contiene el número de proveedor de esa factura. Entonces, el 'número de proveedor' es la clave principal en la tabla de proveedores. La clave externa en la tabla Factura apunta a esa clave primaria. El esquema relacional es el siguiente. Las claves primarias están marcadas en negrita y las claves externas están marcadas en cursiva.
Proveedor ( Número de proveedor , Nombre, Dirección) Factura ( Número de Factura , Texto, Número de Proveedor )
La declaración del lenguaje de definición de datos correspondiente es la siguiente.
CREAR TABLA Proveedor ( Número de proveedor INTEGER NO NULO , Nombre VARCHAR ( 20 ) NO NULO , Dirección VARCHAR ( 50 ) NO NULO , CONSTRAINT proveedor_pk CLAVE PRIMARIA ( Número de proveedor ), CONSTRAINT número_valor VERIFICAR ( Número de proveedor > 0 ) ) Crear factura de tabla ( InvoicEnumber entero no nulo , Text Varchar ( 4096 ), Integer de Suppernumber no NULL , restricción Invoice_PK Clave primaria ( InvoiceEnumber ) , restricción inumber_value check ( InvoicEnumber > 0 ) , Restrict Suppery_FK Clave extranjera ( proveedor de proveedores ) REFER ACTUALIZAR CASCADA AL ELIMINAR RESTRICCIÓN )