Una clave sustituta (o clave sintética , pseudoclave , identificador de entidad , clave sin hechos o clave técnica [ cita requerida ] ) en una base de datos es un identificador único para una entidad en el mundo modelado o un objeto en la base de datos. La clave sustituta no se deriva de los datos de la aplicación, a diferencia de una clave natural (o comercial ) . [1]
Existen al menos dos definiciones de madre sustituta:
La definición de Surrogate (1) se relaciona con un modelo de datos más que con un modelo de almacenamiento y se utiliza en todo este artículo. Véase Date (1998).
Una distinción importante entre una clave sustituta y una clave principal depende de si la base de datos es una base de datos actual o una base de datos temporal . Dado que una base de datos actual almacena solo datos válidos actualmente , existe una correspondencia uno a uno entre una clave sustituta en el mundo modelado y la clave principal de la base de datos. En este caso, la clave sustituta se puede utilizar como clave principal, lo que da como resultado el término clave sustituta . Sin embargo, en una base de datos temporal, existe una relación de varios a uno entre las claves principales y la clave sustituta. Dado que puede haber varios objetos en la base de datos que correspondan a una sola clave sustituta, no podemos utilizar la clave sustituta como clave principal; se requiere otro atributo, además de la clave sustituta, para identificar de forma única cada objeto.
Aunque Hall et al. (1976) no dicen nada al respecto, otros [ especifican ] han argumentado que una madre sustituta debe tener las siguientes características:
En una base de datos actual , la clave sustituta puede ser la clave principal , generada por el sistema de gestión de la base de datos y no derivada de ningún dato de la aplicación en la base de datos. El único significado de la clave sustituta es actuar como clave principal. También es posible que la clave sustituta exista además del UUID generado por la base de datos (por ejemplo, un número de RR.HH. para cada empleado que no sea el UUID de cada empleado).
Una clave sustituta es con frecuencia un número secuencial (por ejemplo, una "columna de identidad" de Sybase o SQL Server , una de PostgreSQL o Informix serial , una de Oracle o SQL Server SEQUENCEo una columna definida con AUTO_INCREMENTen MySQL ). Algunas bases de datos proporcionan UUID / GUID como un posible tipo de datos para claves sustitutas (por ejemplo, PostgreSQL UUID[3] o SQL Server UNIQUEIDENTIFIER[4] ).
Tener la clave independiente de todas las demás columnas aísla las relaciones de la base de datos de los cambios en los valores de los datos o en el diseño de la base de datos [5] (lo que hace que la base de datos sea más ágil ) y garantiza la unicidad.
En una base de datos temporal , es necesario distinguir entre la clave sustituta y la clave comercial . Cada fila tendría una clave comercial y una clave sustituta. La clave sustituta identifica una fila única en la base de datos, la clave comercial identifica una entidad única del mundo modelado. Una fila de la tabla representa una porción de tiempo que contiene todos los atributos de la entidad para un período de tiempo definido. Esas porciones representan la vida útil completa de una entidad comercial. Por ejemplo, una tabla EmployeeContracts puede contener información temporal para realizar un seguimiento de las horas de trabajo contratadas. La clave comercial para un contrato será idéntica (no única) en ambas filas, sin embargo, la clave sustituta para cada fila es única.
Algunos diseñadores de bases de datos utilizan claves sustitutas sistemáticamente independientemente de la idoneidad de otras claves candidatas , mientras que otros utilizarán una clave ya presente en los datos, si la hay.
Algunos de los nombres alternativos ("clave generada por el sistema") describen la forma de generar nuevos valores sustitutos en lugar de la naturaleza del concepto sustituto.
Los enfoques para generar madres sustitutas incluyen:
IDENTITYOIDENTITY(n,n)SEQUENCE , o GENERATED AS IDENTITY(a partir de la versión 12.1) [6]SEQUENCE(a partir de SQL Server 2012) [7]AUTO_INCREMENTINTEGER PRIMARY KEY (si AUTOINCREMENTse utiliza evitará la reutilización de números que ya se han utilizado pero que están disponibles) [8]AS IDENTITY GENERATED BY DEFAULTen IBM Db2 y PostgreSQL .Las claves sustitutas normalmente no cambian mientras la fila existe. Esto tiene las siguientes ventajas:
Los atributos que identifican de forma única a una entidad pueden cambiar, lo que podría invalidar la idoneidad de las claves naturales. Considere el siguiente ejemplo:
En estos casos, generalmente se debe agregar un nuevo atributo a la clave natural (por ejemplo, una columna original_company ). Con una clave sustituta, solo se debe cambiar la tabla que define la clave sustituta. Con claves naturales, todas las tablas (y posiblemente otro software relacionado) que utilicen la clave natural deberán cambiar.
Algunos dominios problemáticos no identifican claramente una clave natural adecuada. Las claves sustitutas evitan elegir una clave natural que podría ser incorrecta.
Las claves sustitutas suelen ser un tipo de datos compacto, como un entero de cuatro bytes. Esto permite que la base de datos consulte la columna de clave única más rápido que si consultara varias columnas. Además, una distribución no redundante de claves hace que el índice de árbol b resultante esté completamente equilibrado. Las claves sustitutas también son menos costosas de unir (menos columnas para comparar) que las claves compuestas .
Al utilizar varios sistemas de desarrollo de aplicaciones de bases de datos, controladores y sistemas de mapeo relacional de objetos , como Ruby on Rails o Hibernate , es mucho más fácil usar claves sustitutas GUID o enteras para cada tabla en lugar de claves naturales para soportar operaciones independientes del sistema de base de datos y mapeo de objeto a fila.
Cuando cada tabla tiene una clave sustituta uniforme, algunas tareas se pueden automatizar fácilmente escribiendo el código de forma independiente de la tabla.
Es posible diseñar claves-valores que sigan un patrón o una estructura bien conocidos que puedan verificarse automáticamente. Por ejemplo, las claves que se pretende utilizar en alguna columna de alguna tabla pueden diseñarse para que "parezcan diferentes" a las que se pretende utilizar en otra columna o tabla, simplificando así la detección de errores de aplicación en los que las claves se han colocado incorrectamente. Sin embargo, esta característica de las claves sustitutas nunca debe utilizarse para controlar la lógica de las propias aplicaciones, ya que esto violaría los principios de normalización de bases de datos .
Los valores de las claves sustitutas generadas no tienen relación con el significado real de los datos contenidos en una fila. Al inspeccionar una fila que contiene una referencia de clave externa a otra tabla utilizando una clave sustituta, el significado de la fila de la clave sustituta no se puede discernir a partir de la clave misma. Cada clave externa debe unirse para ver el elemento de datos relacionado. Si no se han establecido restricciones de base de datos adecuadas, o se han importado datos de un sistema heredado donde no se empleó integridad referencial , es posible tener un valor de clave externa que no corresponda a un valor de clave principal y, por lo tanto, no sea válido. (En este sentido, CJ Date considera que la falta de significado de las claves sustitutas es una ventaja. [9] )
Para descubrir estos errores, se debe realizar una consulta que utilice una unión externa izquierda entre la tabla con la clave externa y la tabla con la clave principal, mostrando ambos campos de clave además de cualquier campo requerido para distinguir el registro; todos los valores de clave externa no válidos tendrán la columna de clave principal como NULL. La necesidad de realizar esta comprobación es tan común que Microsoft Access proporciona un asistente de "Consulta de búsqueda no coincidente" que genera el SQL apropiado después de guiar al usuario a través de un cuadro de diálogo. (Sin embargo, no es demasiado difícil componer estas consultas manualmente). Las consultas de "Buscar no coincidentes" se emplean normalmente como parte de un proceso de limpieza de datos cuando se heredan datos heredados.
Las claves sustitutas no son naturales para los datos que se exportan y comparten. Una dificultad particular es que las tablas de dos esquemas que de otro modo serían idénticos (por ejemplo, un esquema de prueba y un esquema de desarrollo) pueden contener registros que son equivalentes en un sentido comercial, pero que tienen claves diferentes. Esto se puede mitigar al no exportar claves sustitutas, excepto como datos transitorios (más obviamente, al ejecutar aplicaciones que tienen una conexión "en vivo" a la base de datos).
Cuando las claves sustitutas sustituyen a las claves naturales, se pone en peligro la integridad referencial específica del dominio . Por ejemplo, en una tabla maestra de clientes, el mismo cliente puede tener varios registros con identificaciones de cliente distintas, aunque la clave natural (una combinación de nombre de cliente, fecha de nacimiento y dirección de correo electrónico) sea única. Para evitar que se ponga en peligro la integridad, no se debe sustituir la clave natural de la tabla: se debe conservar como una restricción única, que se implementa como un índice único en la combinación de campos de clave natural.
Las bases de datos relacionales suponen que se aplica un índice único a la clave principal de una tabla. El índice único tiene dos propósitos: (i) hacer cumplir la integridad de la entidad, ya que los datos de la clave principal deben ser únicos en todas las filas y (ii) buscar filas rápidamente cuando se realizan consultas. Dado que las claves sustitutas reemplazan los atributos de identificación de una tabla (la clave natural ) y dado que es probable que los atributos de identificación sean los consultados, el optimizador de consultas se ve obligado a realizar un escaneo completo de la tabla al satisfacer consultas probables. La solución al escaneo completo de la tabla es aplicar índices a los atributos de identificación, o conjuntos de ellos. Cuando dichos conjuntos son en sí mismos una clave candidata , el índice puede ser un índice único.
Sin embargo, estos índices adicionales ocuparán espacio en el disco y ralentizarán las inserciones y eliminaciones.
Las claves sustitutas pueden generar valores duplicados en cualquier clave natural . Para evitar la duplicación, se debe preservar el rol de las claves naturales como restricciones únicas al definir la tabla mediante CREATE TABLEla declaración de SQL o ALTER TABLE ... ADD CONSTRAINTla declaración, si las restricciones se agregan como una idea de último momento.
Como las claves sustitutas no son naturales, pueden aparecer errores al modelar los requisitos empresariales. Los requisitos empresariales, que dependen de la clave natural, deben traducirse a la clave sustituta. Una estrategia consiste en trazar una distinción clara entre el modelo lógico (en el que no aparecen claves sustitutas) y la implementación física de ese modelo, para garantizar que el modelo lógico sea correcto y esté razonablemente bien normalizado, y para garantizar que el modelo físico sea una implementación correcta del modelo lógico.
La información confidencial puede filtrarse si se generan claves sustitutas de forma secuencial. Al restar una clave secuencial generada previamente de una clave secuencial generada recientemente, se podría conocer la cantidad de filas insertadas durante ese período de tiempo. Esto podría exponer, por ejemplo, la cantidad de transacciones o cuentas nuevas por período. Por ejemplo, consulte el problema del tanque alemán .
Hay algunas formas de superar este problema:
Las claves sustitutas generadas secuencialmente pueden implicar que los eventos con un valor de clave más alto ocurrieron después de los eventos con un valor más bajo. Esto no es necesariamente cierto, porque dichos valores no garantizan la secuencia temporal, ya que es posible que las inserciones fallen y dejen espacios vacíos que pueden llenarse en un momento posterior. Si la cronología es importante, la fecha y la hora deben registrarse por separado.