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]
Hay al menos dos definiciones de madre sustituta:
La definición de sustituto (1) se relaciona con un modelo de datos en lugar de un modelo de almacenamiento y se utiliza a lo largo de este artículo. Ver Fecha (1998).
Una distinción importante entre una clave sustituta y una clave primaria 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 sólo datos actualmente válidos, existe una correspondencia uno a uno entre un sustituto en el mundo modelado y la clave primaria 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 muchos a uno entre las claves primarias y la sustituta. Dado que puede haber varios objetos en la base de datos correspondientes a un único sustituto, no podemos utilizar el sustituto como clave principal; Se requiere otro atributo, además del sustituto, para identificar de forma única cada objeto.
Aunque Hall et al. (1976) no dicen nada al respecto, otros [ especificar ] 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 aplicación en la base de datos. El único significado de la clave sustituta es actuar como clave principal. También es posible que exista la clave sustituta además del UUID generado por la base de datos (por ejemplo, un número de recursos humanos para cada empleado que no sea el UUID de cada empleado).
Una clave sustituta es frecuentemente un número secuencial (por ejemplo, una "columna de identidad" de Sybase o SQL Server , un PostgreSQL o Informix serial , un Oracle o SQL Server SEQUENCE o una columna definida AUTO_INCREMENTen MySQL ). Algunas bases de datos proporcionan UUID / GUID como posible tipo de datos para claves sustitutas (por ejemplo, PostgreSQL UUID o SQL Server UNIQUEIDENTIFIER).
Tener la clave independiente de todas las demás columnas aísla las relaciones de la base de datos de cambios en los valores de los datos o en el diseño de la base de datos (haciendo 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 un segmento de tiempo que contiene todos los atributos de la entidad durante un período de tiempo definido. Esas porciones representan toda la vida útil 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 sustitutos incluyen:
IDENTITY OIDENTITY(n,n)SEQUENCE , o GENERATED AS IDENTITY(a partir de la versión 12.1) [3]SEQUENCE (a partir de SQL Server 2012) [4]AUTO_INCREMENTINTEGER PRIMARY KEY (si AUTOINCREMENTse utiliza evitará la reutilización de números que ya se han utilizado pero que están disponibles) [5]AS IDENTITY GENERATED BY DEFAULTen IBM Db2 y PostgreSQL .Las claves sustitutas normalmente no cambian mientras existe la fila. Esto tiene las siguientes ventajas:
Los atributos que identifican de forma única una entidad podrían 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 empresa_original ). 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 tendrán que cambiar.
Algunos dominios problemáticos no identifican claramente una clave natural adecuada. Las claves sustitutas evitan elegir una clave natural que pueda ser incorrecta.
Las claves sustitutas tienden a ser un tipo de datos compacto, como un entero de cuatro bytes. Esto permite que la base de datos consulte una sola columna de clave más rápido que varias columnas. Además, una distribución no redundante de claves hace que el índice del árbol b resultante esté completamente equilibrado. Las claves sustitutas también son menos costosas de unir (menos columnas para comparar) que las claves compuestas .
Si bien se utilizan 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 de números enteros o GUID para cada tabla en lugar de claves naturales para respaldar la base de datos. operaciones independientes del sistema 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 valores-clave que sigan un patrón o estructura bien conocido que pueda verificarse automáticamente. Por ejemplo, las claves que se pretenden utilizar en alguna columna de alguna tabla podrían diseñarse para "verse diferentes" de aquellas que se pretenden utilizar en otra columna o tabla, simplificando así la detección de errores de aplicación en los que las claves han sido extraviados. Sin embargo, esta característica de las claves sustitutas nunca debe usarse para controlar la lógica de las aplicaciones mismas, 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 mantenidos en una fila. Al inspeccionar una fila que contiene una referencia de clave externa a otra tabla usando 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 estar unida para ver el elemento de datos relacionado. Si no se han establecido las restricciones adecuadas de la base de datos, o si no se han importado datos de un sistema heredado donde no se empleó la integridad referencial , es posible tener un valor de clave externa que no corresponda a un valor de clave primaria y, por lo tanto, no sea válido. (En este sentido, CJ Date considera que la falta de sentido de las claves sustitutas es una ventaja. [6] )
Para descubrir tales errores, se debe realizar una consulta que utilice una combinación externa izquierda entre la tabla con la clave externa y la tabla con la clave principal, mostrando ambos campos 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 dicha verificación es tan común que Microsoft Access proporciona un asistente para "Buscar consulta 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 redactar dichas consultas manualmente). Las consultas "Buscar no coincidentes" generalmente se emplean 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 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 NO exportando claves sustitutas, excepto como datos transitorios (más obviamente, al ejecutar aplicaciones que tienen una conexión "activa" a la base de datos).
Cuando las claves sustitutas reemplazan a las claves naturales, la integridad referencial específica del dominio se verá comprometida. Por ejemplo, en una tabla maestra de clientes, el mismo cliente puede tener varios registros con ID de cliente separados, aunque la clave natural (una combinación de nombre del cliente, fecha de nacimiento y dirección de correo electrónico) sea única. Para evitar compromisos, la clave natural de la tabla NO debe ser reemplazada: debe preservarse 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 consultan. 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 cuando cumple con las 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 papel de las claves naturales como restricciones únicas al definir la tabla utilizando una CREATE TABLEdeclaración o ALTER TABLE ... ADD CONSTRAINTuna declaración de SQL, si las restricciones se agregan como una ocurrencia tardía.
Debido a que las claves sustitutas no son naturales, pueden aparecer fallas al modelar los requisitos comerciales. Los requisitos comerciales que dependen de la clave natural deben traducirse a la clave sustituta. Una estrategia es 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 razonablemente bien normalizado, y para garantizar que el modelo físico sea correcto. una correcta implementación del modelo lógico.
La información de propiedad puede filtrarse si las claves sustitutas se generan secuencialmente. Al restar una clave secuencial generada previamente de una clave secuencial generada recientemente, se podría conocer el número de filas insertadas durante ese período de tiempo. Esto podría exponer, por ejemplo, el número de transacciones o cuentas nuevas por período. Por ejemplo, consulte el problema de los tanques alemanes .
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 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 que pueden llenarse más adelante. Si la cronología es importante entonces la fecha y la hora deben registrarse por separado.