Una clave sustituta (o clave sintética , pseudoclave , identificador de entidad , clave generada por el sistema , número de secuencia de la base de datos , clave sin hechos , clave técnica o identificador único arbitrario ) 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 ) que se deriva de los datos de la aplicación. [1]
Definición
Hay al menos dos definiciones de sustituto:
- Sustituto (1) - Hall, Owlett y Todd (1976)
- Un sustituto representa una entidad en el mundo exterior. El sustituto es generado internamente por el sistema pero, no obstante, es visible para el usuario o la aplicación. [2]
- Sustituto (2) - Wieringa y De Jonge (1991)
- Un sustituto representa un objeto en la propia base de datos. El sustituto es generado internamente por el sistema y es invisible para el usuario o la aplicación.
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. Véase Date (1998).
Una distinción importante entre un sustituto 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 actualmente válidos, existe una correspondencia uno a uno entre un sustituto en el mundo modelado y la clave principal de la base de datos. En este caso, el sustituto se puede utilizar como clave principal, lo que da como resultado el término clave sustituta . En una base de datos temporal, sin embargo, existe una relación de varios a uno entre las claves primarias y el sustituto. Dado que puede haber varios objetos en la base de datos correspondientes a un solo sustituto, no podemos usar el sustituto como clave primaria; Se requiere otro atributo, además del sustituto, para identificar de forma única cada objeto.
Aunque Hall et al. (1976) no dicen nada sobre esto, otros [ especifican ] han argumentado que un sustituto debe tener las siguientes características:
- el valor es único en todo el sistema, por lo que nunca se reutiliza
- el valor es generado por el sistema
- el valor no es manipulable por el usuario o la aplicación
- el valor no contiene significado semántico
- el valor no es visible para el usuario o la aplicación
- el valor no está compuesto por varios valores de diferentes dominios.
Sustitutos en la práctica
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 la clave sustituta exista además del UUID generado por la base de datos (por ejemplo, un número de HR 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_INCREMENT
en MySQL ). Algunas bases de datos proporcionan UUID / GUID como un posible tipo de datos para claves sustitutas (por ejemplo, PostgreSQLUUID
o SQL ServerUNIQUEIDENTIFIER
).
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 el diseño de la base de datos (lo que hace que la base de datos sea más ágil ) y garantiza la singularidad.
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 durante un período de tiempo definido. Esas secciones 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.
Clave sustituta | BusinessKey | Nombre de empleado | WorkingHoursPerWeek | RowValidFrom | RowValidTo |
---|---|---|---|---|---|
1 | BOS0120 | John Smith | 40 | 2000-01-01 | 2000-12-31 |
56 | P0000123 | Bob Brown | 25 | 1999-01-01 | 2011-12-31 |
234 | BOS0120 | John Smith | 35 | 2001-01-01 | 2009-12-31 |
Algunos diseñadores de bases de datos utilizan claves sustitutas de forma sistemática independientemente de la idoneidad de otras claves candidatas , mientras que otros utilizarán una clave ya presente en los datos, si existe.
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:
- Identificadores únicos universales (UUID)
- Identificadores únicos globales (GUID)
- Identificadores de objeto (OID)
- Columna de identidad de Sybase o SQL Server
IDENTITY
OIDENTITY(n,n)
- Oracle
SEQUENCE
, oGENERATED AS IDENTITY
(a partir de la versión 12.1) [3] - SQL Server
SEQUENCE
(a partir de SQL Server 2012) [4] - PostgreSQL o IBM Informix serie
- MySQL
AUTO_INCREMENT
- SQLite
AUTOINCREMENT
- Tipo de datos Autonumérico en Microsoft Access
AS IDENTITY GENERATED BY DEFAULT
en IBM DB2- Columna de identidad (implementada en DDL ) en Teradata
- Secuencia de tabla cuando la secuencia se calcula mediante un procedimiento y una tabla de secuencia con campos: id, sequenceName, sequenceValue e incrementValue
Ventajas
Estabilidad
Las claves sustitutas normalmente no cambian mientras existe la fila. 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 principal o natural siempre se pueden modificar, incluso con bases de datos que no admiten actualizaciones en cascada entre claves externas relacionadas .
Cambios en los requisitos
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 la red de un empleado se elige como clave natural. Al fusionarse con otra empresa, se deben insertar nuevos empleados. Algunos de los nuevos nombres de usuario de la red crean conflictos porque sus nombres de usuario se generaron 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 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 usen la clave natural tendrán que cambiar.
Algunos dominios de problemas no identifican claramente una clave natural adecuada. Las claves sustitutas evitan elegir una clave natural que pueda ser incorrecta.
Actuación
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 la columna de clave única más rápido de lo que podría hacerlo con varias columnas. Además, una distribución de claves no redundante 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 .
Compatibilidad
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 enteros o GUID para cada tabla en lugar de claves naturales para admitir la base de datos. operaciones independientes del sistema y mapeo de objeto a fila.
Uniformidad
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.
Validación
Es posible diseñar pares clave-valor que sigan un patrón o estructura bien conocidos que se puedan verificar automáticamente. Por ejemplo, las claves que se pretenden utilizar en alguna columna de alguna tabla pueden estar diseñadas para "tener un aspecto diferente" de las 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 impulsar la lógica de las aplicaciones mismas, ya que esto violaría los principios de normalización de la base de datos .
Desventajas
Disociación
Los valores de las claves sustitutas generadas no tienen relación con el significado real de los datos almacenados 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 de la clave en sí. Cada clave externa debe unirse para ver el elemento de datos relacionado. Si no se han establecido las restricciones de base de datos adecuadas, o si no se han importado datos de un sistema heredado donde no se utilizó la 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 sentido de las claves sustitutas es una ventaja. [5] )
Para descubrir tales errores, se debe realizar una consulta que use 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 campo requerido 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 una verificación de este tipo es tan común que Microsoft Access en realidad proporciona un asistente para "Buscar consultas no coincidentes" 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 estas consultas manualmente). Las consultas "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 idénticos (por ejemplo, un esquema de prueba y un esquema de desarrollo) pueden contener registros que son equivalentes en un sentido comercial, pero 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 "en vivo" 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 independientes, 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 compromisos, la clave natural de la tabla NO se debe suplantar: debe conservarse como una restricción única , que se implementa como un índice único en la combinación de campos de clave natural.
Optimización de consultas
Las bases de datos relacionales asumen 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 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 se cumplen las consultas probables. El remedio para el escaneo completo de la tabla es aplicar índices en 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 disco y ralentizarán las inserciones y eliminaciones.
Normalización
Las claves sustitutas pueden dar como resultado 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 usando la instrucción CREATE TABLE de SQL o la instrucción ALTER TABLE ... ADD CONSTRAINT, si las restricciones se agregan como una ocurrencia tardía.
Modelado de procesos de negocio
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 consiste en establecer 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 asegurar que el modelo lógico sea correcto y razonablemente bien normalizado, y para asegurar que el modelo físico sea correcto. una correcta implementación del modelo lógico.
Divulgación involuntaria
Se puede filtrar información patentada si las claves sustitutas se generan secuencialmente. Al restar una clave secuencial generada previamente de una clave secuencial generada recientemente, uno podría aprender el número de filas insertadas durante ese período de tiempo. Esto podría exponer, por ejemplo, el número de transacciones o nuevas cuentas por período. Por ejemplo, vea el problema del tanque alemán .
Hay algunas formas de superar este problema:
- aumentar el número secuencial en una cantidad aleatoria;
- generar una clave aleatoria como un UUID .
Supuestos inadvertidos
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 tales valores no garantizan la secuencia de tiempo, ya que es posible que las inserciones fallen y dejen huecos que pueden llenarse en un momento posterior. Si la cronología es importante, la fecha y la hora deben registrarse por separado.
Ver también
- Clave natural
- Identificador de objeto
- Identificador de objeto persistente
Referencias
Citas
- ^ "¿Qué es una clave sustituta? - Definición de Techopedia" . Techopedia.com . Consultado el 21 de febrero de 2020 .
- ^ PAV Hall, J Owlett, SJP Todd, "Relaciones y entidades", Modelado en sistemas de gestión de bases de datos (ed. GM Nijssen) , Holanda del Norte 1976.
- ^ http://docs.oracle.com/database/121/SQLRF/statements_7002.htm#SQLRF01402
- ^ https://msdn.microsoft.com/en-us/library/ff878091.aspx
- ^ Fecha de CJ. La primacía de las claves primarias. De "Escritos de bases de datos relacionales, 1991-1994. Addison-Wesley, Reading, MA.
Fuentes
- Este artículo se basa en material extraído del Diccionario de Computación en línea gratuito antes del 1 de noviembre de 2008 e incorporado bajo los términos de "renovación de licencias" de la GFDL , versión 1.3 o posterior.
- Nijssen, GM (1976). Modelado en sistemas de gestión de bases de datos . Pub de Holanda Septentrional. Co. ISBN 0-7204-0459-2.
- Engles, RW: (1972), Tutorial sobre organización de bases de datos , Revisión anual de programación automática, Vol.7, Parte 1, Pergamon Press, Oxford, págs. 1-64.
- Langefors, B (1968). Archivos elementales y registros de archivos elementales , Actas del archivo 68, un seminario internacional IFIP / IAG sobre organización de archivos, Amsterdam, noviembre, págs. 89–96.
- Wieringa, R .; de Jonge, W. (1991). "La identificación de objetos y roles: Identificadores de objetos revisados". CiteSeerX 10.1.1.16.3195 . Cite journal requiere
|journal=
( ayuda ) - Fecha, CJ (1998). "Capítulos 11 y 12". Escritos de bases de datos relacionales 1994–1997 . ISBN 0201398141.
- Carter, Breck. "Inteligente versus llaves sustitutas" . Consultado el 3 de diciembre de 2006 .
- Richardson, Lee. "Crear desastre de datos: evitar índices únicos - (error 3 de 10)" . Archivado desde el original el 30 de enero de 2008 . Consultado el 19 de enero de 2008 .
- Berkus, Josh. "Sopa de base de datos: Keyvil principal, parte I" . Consultado el 3 de diciembre de 2006 .