Clave sustituta
Una clave sustituta o clave artificial en una base de datos es un identificador único para una entidad en el mundo real o modelado o para un objeto en la base de datos. Al contrario que la clave natural, la clave sustituta no deriva de los datos de una aplicación.
Definición
Hay al menos dos definiciones de una sustituta:
- Sustituta (1) – Hall, Owlett y Todd (1976)
- Una sustituta representa una entidad en el mundo exterior. La sustituta se genera internamente por el sistema pero nunca es visible para el usuario o la aplicación.[1]
- Sustituta (2) – Wieringa y De Jonge (1991)
- Una sustituta representa un objeto en la propia base de datos. La sustituta se genera por el sistema y es invisible al usuario o la aplicación.
La definición Sustituta (1) hace referencia al modelo de datos más que a un modelo de almacenamiento y es el utilizado en este artículo.
Una importante diferencia entre una sustituta y una clave primaria depende de si la base de datos es actual o temporal. Si una base de datos actual sólo almacena información válida actual, hay una correspondencia uno-a-uno entre la sustituta del mundo modelado y la clave primaria de la base de datos. En este caso, la sustituta puede utilizarse como clave primaria, resultando en el término clave sustituta. Sin embargo, en una base de datos temporal, hay una relación de muchas-a-una entre claves primarias y la sustituta. Desde que puede haber varios objetos de la base de datos correspondiendo a una única sustituta, no se puede utilizar la sustituta como clave primaria; necesitando otro atributo a añadir a la sustituta para identificar de forma única cada objeto.
Aunque Hall et al. (1976) no dice nada sobre esto, otros han argumentado que una sustituta debería tener las siguientes características:
- El valor es único en el sistema y por lo tanto, nunca reutilizado
- El valor está generado por el sistema
- El valor no es manipulable ni por el usuario ni por la aplicación
- El valor no contiene ningún significado semántico
- El valor no es visible para el usuario o la aplicación
- El valor no se compone de varios valores de diferentes dominios
Sustitutas en la práctica
En una base de datos actual, la clave sustituta puede ser la clave primaria, generada por el sistema de gestión de bases de datos y no deriva de los datos de ninguna aplicación. La única misión de la clave sustituta es actuar como clave primaria. También es posible que una clave sustituta exista como adición a una UUID generada por la base de datos.
Frecuentemente, una clave sustituta es un número secuencial (p.ej. una columna de identidad de Sybase o SQL Server, un número de serie en PostgreSQL o Informix, una SEQUENCE en Oracle o una columna definida con AUTO_INCREMENT en MySQL). Algunas bases de datos proporcionan UUID como tipo de datos posible para claves sustitutas (p.ej. PostreSQL UUID (inglés)).
Tener una clave independiente de todas las demás columnas, aísla las relaciones de la base de datos de los cambios en los valores de la información o del diseño de la base de datos (haciendo que sea más ágil) y garantizando la singularidad.
| ClaveSustituta | ClaveNegocio | NombreEmpleado | HorasPorSemana | Desde | Hasta |
|---|---|---|---|---|---|
| 1 | BOS0120 | John Smith | 40 | 01-01-2000 | 31-12-2000 |
| 56 | P0000123 | Bob Brown | 25 | 01-01-1999 | 31-12-2011 |
| 234 | BOS0120 | John Smith | 35 | 01-01-2001 | 31-12-2009 |
Algunos diseñadores de bases de datos utilizan claves sustitutas de forma sistemática sin tener en cuenta la idoneidad de otras claves candidatas, mientras que otros usarán una clave ya existente en los datos, si existe.
Una clave sustituta también puede llamarse una clave sintética, un identificador de entidad, una clave generada por el sistema, un número secuencial de base de datos, una clave técnica, un identificador único arbitrario. Algunos de estos términos describen la forma en la que se generan nuevos valores de sustitución más que la naturaleza del concepto de sustitución.
Aproximaciones de generación de sustitutas incluyen:
- Universally Unique Identifier (UUIDs)
- Globally Unique Identifier (GUIDs)
- Identificador de Objeto (OIDs)
- Columna de identidad de Sybase o SQL Server
IDENTITYoIDENTITY(n,n) - Oracle
SEQUENCE, oGENERATED AS IDENTITY(desde la versión 12.1)[2] - Número de serie en PostgreSQL o IBM Informix
- MySQL
AUTO_INCREMENT - Tipo de dato AutoNumber en Microsoft Access
AS IDENTITY GENERATED BY DEFAULTen IBM DB2- Columna Identity (implementado en DDL) en Teradata
- Tabla Sequence cuando la secuencia se calcula mediante un procedimiento y una tabla de secuencia con campos: id, sequenceName, sequenceValue y incrementValue
Ventajas
Inmutabilidad
Las claves sustitutas no cambian mientras la fila de datos exista. Esto tiene las siguientes ventajas:
- Las aplicaciones no pueden perder su referencia a una fila de la base de datos.
- La información de la clave primaria o natural siempre pueden ser modificadas, incluso con bases de datos que no soportan actualizaciones en cascada a través de claves foráneas relacionadas.
Cambios de requisitos
Los atributos que identifican únicamente a una entidad pueden cambiar, lo que invalidarían la idoneidad de las claves naturales. Considerando el siguiente ejemplo:
- El nombre de usuario de red de un empleado se elige como clave natural. Cuando se fusiona con otra compañía los nuevos empleados se tienen que añadir. Algunos de los nombres de usuario nuevos crean conflictos porque sus nombres se generaron de forma independiente (cuando las compañías estaban separadas).
En estos casos, generalmente se ha de añadir un nuevo atributo sobre la clave natural (por ejemplo, una columna compañía_original). Con una clave sustituta, sólo la tabla que define la clave sustituta tendría que ser cambiada. Con claves naturales, tendrían que ser cambiadas todas las tablas que usan la clave natural (y posiblemente otro software relacionado).
En algunas ocasiones es difícil encontrar una clave natural apropiada. Las claves sustitutas evitan elegir una clave natural que podría ser incorrecta.
Rendimiento
Las claves sustitutas tienden a ser de un tipo de datos compacto, como un entero de 4 bytes. Esto permite a la base de datos realizar consultas de una sola columna más rápido que con múltiples columnas. La distribución no-redundante de claves causa que el índice en árbol-B esté completamente balanceado. Las claves sustitutas tienen mejor rendimiento (menos columnas a comparar) que las claves compuestas.
Compactabilidad
Cuando se utilizan varios sistemas de desarrollo de aplicaciones de base de datos, drivers, y sistemas de mapeo objeto-relacional, como Ruby on Rails o Hibernate, es más fácil utilizar un tipo entero o claves sustitutas GUID para cada tabla en lugar de claves naturales.
Uniformidad
Cuando cada tabla tienen una clave sustituta uniforme, se pueden automatizar fácilmente algunas tareas escribiendo código de forma independiente para cada tabla.
Validación
Es posible diseñar claves-valores que sigan patrones bien conocidos o estructuras que pueden ser verificadas automáticamente. Por ejemplo, las claves creadas para ser usadas en algunas columnas de una tabla podrían ser diseñadas para "parecer diferente de" aquellas que han sido creadas para utilizarse en otras columnas de la tabla, simplificando la detección de errores de aplicación en las cuales las claves están fuera de lugar. Sin embargo, esta característica de las claves sustitutas no deberían usarse nunca para guiar cualquier lógica de las aplicaciones, ya que violaría los principios de la normalización de bases de datos.
Desventajas
Disasociación
Los valores de las claves sustitutas generadas no tienen relación con el significado en el mundo real de los datos contenidos en una fila. Cuando se inspecciona una fila que contiene una referencia de una clave foránea a otra tabla usando una clave sustituta, e significado de la fila de la clave sustituta no se puede discernir por la propia clave. Toda clave foránea debe unirse para ver la información del ítem relacionado. Esto puede complicar la auditoría ya que la información incorrecta no es obvia.
Las claves sustitutas no son naturales para la información que se exporta y comparte. Una dificultad particular es que las tablas de dos, por otro lado, esquemas idénticos (por ejemplo, un esquema de prueba y un esquema de desarrollo) pueden contener registros que son equivalentes en un contexto de negocios pero tener claves diferentes. Esto se puede mitigar no exportando claves sustitutas, excepto los datos transitorios (más obviamente, en aplicaciones que tienen una conexión activa con la base de datos).
Optimización de consultas
Las bases de datos relacionales asumen que un índice se aplica a la clave primaria de una tabla. El índice único sirve para dos propósitos: (1) para aumentar la integridad de la entidad, ya que la clave primaria debe ser única en todas las filas y (2) para buscar rápidamente filas cuando se realiza una consulta. Desde que las claves sustitutas reemplazan a los atributos identificativos de una tabla—la clave natural—y desde que los atributos identificativos son los que van a ser consultados, el optimizador de consultas se ve forzado a realizar escaneos de tablas completas para rellenar las consultas. Para evitar el escaneo completo de una tabla, se aplica índices sobre los atributos identificativos, o conjuntos de ellos. Dichos conjuntos son por sí mismos 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 los borrados.
Normalización
Las claves sustitutas pueden resultar en valores duplicados en cualquier clave natural. Es parte de la implementación asegurar que esos duplicados no tengan lugar.
Modelado de procesos de negocio
Debido a que las claves sustitutas no son naturales, pueden aparecer defectos en los requerimientos de modelado de negocios. Los requerimientos de negocios, que recaen en claves naturales, necesitan trasladarse a claves sustitutas. Una estrategia es dibujar una distinción clara entre el modelo lógico (en el que la clave sustituta no aparece) y la implementación física de ese modelo, para asegurar que el modelo lógico es correcto y razonablemente bien normalizado, y para asegurar que el modelo físico es una implementación correcta del modelo lógico.
Divulgación inadvertida
La información propietaria podría filtrarse si se utilizan generadores de claves secuenciales. Sustrayendo una clave secuencial previamente generada, se podría conocer el número de filas insertadas durante ese periodo de tiempo. Esto podría exponer, por ejemplo, el número de transacciones o nuevas cuentas por periodo. Hay pocas formas de afrontar este problema:
- Incrementar el número secuencial en una cantidad arbitraria
- Generar una clave aleatoria tal como una uuid
Asunciones inadvertidas
Las claves sustitutas generadas secuencialmente pueden implicar que los eventos con un valor de clave mayor ocurran después de eventos con un valor menor. Esto no es necesariamente cierto, ya que tales valores no garantizan una secuencia temporal, y podría hacer que las inserciones fallaran y dejaran huecos que pudieran llenarse en posteriormente. Si la cronología es importante, entonces deberían registrarse por separado la fecha y la hora.
Véase también
Referencias
- P A V Hall, J Owlett, S J P Todd, "Relations and Entities", Modelling in Data Base Management Systems (ed GM Nijssen), North Holland 1976.
- http://docs.oracle.com/database/121/SQLRF/statements_7002.htm#SQLRF01402