Llave sustituta

Las claves subrogadas normalmente no cambian mientras la fila existe. Esto tiene las siguientes ventajas:

• Las aplicaciones no pueden perder su referencia a una fila en la base de datos (ya que el identificador no cambia).
• Los datos de la clave primaria o natural siempre se pueden modificar, incluso con bases de datos que no admiten actualizaciones en cascada a través de claves foráneas relacionadas .

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:

El nombre de usuario de red de un empleado se elige como clave natural. Al fusionarse con otra empresa, se deben agregar nuevos empleados. Algunos de los nuevos nombres de usuario de red generan conflictos porque se crearon de forma independiente (cuando las empresas estaban separadas).

En estos casos, generalmente se debe agregar un nuevo atributo a la clave natural (por ejemplo, una columna llamada `original_company` ). Con una clave subrogada, solo se debe modificar la tabla que la define. Con las claves naturales, todas las tablas (y posiblemente otro software relacionado) que las utilicen deberán modificarse.

En algunos dominios problemáticos no se identifica claramente una clave natural adecuada. Las claves sustitutas evitan elegir una clave natural que podría ser incorrecta.

Las claves subrogadas suelen ser de un tipo de dato 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 (que a menudo son de texto, lo cual es aún más lento). Además, una distribución no redundante de claves hace que el índice B-tree resultante esté completamente equilibrado. Las claves subrogadas también son menos costosas de unir (menos columnas para comparar) que las claves compuestas .

Al utilizar diversos sistemas de desarrollo de aplicaciones de bases de datos, controladores y sistemas de mapeo objeto-relacional , como Ruby on Rails o Hibernate , resulta mucho más sencillo utilizar claves sustitutas enteras o GUID para cada tabla en lugar de claves naturales, con el fin de admitir operaciones independientes del sistema de base de datos y el mapeo de objetos a filas.

Cuando todas las tablas tienen una clave subrogada uniforme, algunas tareas se pueden automatizar fácilmente escribiendo el código de forma independiente de la tabla.

Es posible diseñar pares clave-valor que sigan un patrón o estructura bien definidos y que puedan verificarse automáticamente. Por ejemplo, las claves destinadas a una columna de una tabla podrían diseñarse para que tengan un aspecto diferente al de las destinadas a otra columna o tabla, simplificando así la detección de errores en la aplicación causados ​​por la ubicación incorrecta de las claves. Sin embargo, esta característica de las claves sustitutas nunca debe utilizarse para controlar la lógica de las aplicaciones, ya que esto infringiría los principios de normalización de bases de datos .

Las claves subrogadas simplifican la creación de relaciones de clave externa, ya que solo requieren una columna (a diferencia de las claves compuestas, que requieren varias). Al crear una consulta en la base de datos, olvidar incluir todas las columnas de una clave externa compuesta al unir tablas puede generar resultados inesperados, como un producto cartesiano no deseado .

Los valores de las claves subrogadas generadas no guardan 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 mediante una clave subrogada, el significado de la fila de la clave subrogada no se puede discernir a partir de la clave misma. Es necesario unir cada clave externa para visualizar el elemento de datos relacionado. Si no se han establecido las restricciones de base de datos adecuadas, o si se han importado datos de un sistema heredado donde no se empleaba la integridad referencial , es posible que un valor de clave externa no se corresponda con un valor de clave primaria y, por lo tanto, sea inválido. (En este sentido, CJ Date considera que la falta de significado de las claves subrogadas es una ventaja. ^{[ 9 ]} )

Para detectar estos errores, es necesario realizar una consulta que utilice una combinación externa izquierda entre la tabla con la clave externa y la tabla con la clave primaria, mostrando ambos campos clave además de cualquier otro campo necesario para distinguir el registro; todos los valores de clave externa no válidos tendrán la columna de clave primaria como NULL. La necesidad de realizar esta comprobación es tan común que Microsoft Access ofrece un asistente de "Buscar consultas sin coincidencia" que genera la consulta SQL adecuada tras guiar al usuario a través de un cuadro de diálogo. (Sin embargo, no es demasiado difícil crear estas consultas manualmente). Las consultas de "Buscar consultas sin coincidencia" se suelen emplear como parte de un proceso de limpieza de datos al heredar datos heredados.

Las claves subrogadas no son adecuadas para datos que se exportan y comparten. Una dificultad particular radica en que las tablas de dos esquemas idénticos (por ejemplo, un esquema de prueba y uno de desarrollo) pueden contener registros equivalentes desde el punto de vista empresarial, pero con claves diferentes. Esto se puede mitigar evitando la exportación de claves subrogadas, salvo como datos transitorios (principalmente en aplicaciones en ejecución con conexión directa a la base de datos).

Cuando las claves sustitutas reemplazan a las claves naturales, la integridad referencial específica del dominio se ve comprometida. Por ejemplo, en una tabla maestra de clientes, un mismo cliente puede tener varios registros con diferentes identificadores, aunque la clave natural (una combinación de nombre, fecha de nacimiento y dirección de correo electrónico) sea única. Para evitar esta vulnerabilidad, la clave natural de la tabla no debe ser reemplazada: debe conservarse como una restricción de unicidad , implementada como un índice único en la combinación de campos de clave natural.

Las bases de datos relacionales asumen que se aplica un índice único a la clave primaria de una tabla. Este índice único cumple dos funciones: (i) garantizar la integridad de la entidad, ya que los datos de la clave primaria deben ser únicos en todas las filas, y (ii) facilitar la búsqueda rápida de filas al realizar consultas. Dado que las claves sustitutas reemplazan los atributos identificativos de una tabla (la clave natural ) y que es probable que estos atributos sean los que se consultan, el optimizador de consultas se ve obligado a realizar un escaneo completo de la tabla al procesar consultas probables. La solución a este escaneo completo consiste en aplicar índices a los atributos identificativos, o a conjuntos de ellos. Cuando dichos conjuntos constituyen una clave candidata , el índice puede ser un índice único.

Sin embargo, estos índices adicionales ocuparán espacio en disco y ralentizarán las inserciones y eliminaciones.

Las claves subrogadas pueden generar valores duplicados en las claves naturales . Para evitar la duplicación, es necesario preservar la función de las claves naturales como restricciones únicas al definir la tabla mediante la instrucción SQL CREATE TABLEo ALTER TABLE ... ADD CONSTRAINTla instrucción, si las restricciones se agregan posteriormente.

Dado que las claves sustitutas no son naturales, pueden surgir fallos al modelar los requisitos del negocio. Estos requisitos, que dependen de la clave natural, deben entonces traducirse a la clave sustituta. Una estrategia consiste en establecer una clara distinción entre el modelo lógico (en el que no aparecen claves sustitutas) y la implementación física de dicho modelo, para garantizar que el modelo lógico sea correcto y esté razonablemente bien normalizado, y que el modelo físico sea una implementación correcta del modelo lógico.

La información confidencial puede filtrarse si las claves subrogadas 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. Esto podría revelar, por ejemplo, el número de transacciones o cuentas nuevas por período. Véase, por ejemplo, el problema del tanque alemán .

Hay varias maneras de superar este problema:

• aumentar el número secuencial en una cantidad aleatoria;
• generar una clave aleatoria como un UUID .

Las claves subrogadas 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, ya que dichos valores no garantizan la secuencia temporal, pues es posible que las inserciones fallen y dejen huecos que podrían rellenarse posteriormente. Si la cronología es importante, la fecha y la hora deben registrarse por separado.