Las Claves Subrogadas (Surrogate Keys) es un concepto muy utilizado en el diseño de bases de datos, especialmente en entornos de Data Warehouse (DW) y Business Intelligence (BI). Las Clave Subrogadas suelen utilizarse especialmente en tablas de dimensión versionadas o históricas, conocidas como Slowly Changing Dimension (SCD) de tipo 2, es decir, tablas de dimensión que almacenan tanto los datos actuales (versión actual) como los datos históricos (versiones antiguas). El concepto de Clave Subrogada no es único de SQL Server, es decir, las Claves Subrogadas son un concepto general que puede aplicarse a cualquier motor de base de datos (ORACLE, IBM DB2, IBM Informix, MySQL, etc). Sin embargo, antes de poder continuar estudiando el concepto de Clave Subrogada, es importante introducir el concepto de Clave de Negocio y de Tablas Versionadas o Históricas (Slowly Changing Dimension de tipo 2 - SCD Type 2).
¿Qué es una Clave de Negocio (Business Key)?
La mayoría de las tablas de base de datos con que trabajamos, utilizan un campo como clave de acceso, el cual identificará de forma inequívoca a un elemento de negocio, y que en muchos casos tiene significado por sí mismo. Pongamos algunos ejemplos:
- Si estuviéramos hablando de una tabla que almacena Pólizas, la Clave de Negocio podría ser el Número de Póliza (un valor único para cada Póliza, que tiene significado por sí mismo).
- Si estuviéramos hablando de una tabla que almacena vehículos, la Clave de Negocio podría ser la matrícula (o quizás el número de bastidor).
- Si estuviéramos hablando de una tabla que almacena productos comerciales, la Clave de Negocio podría ser el código EAN-13.
- Si estuviéramos hablando de una tabla de facturas, la Clave de Negocio podría ser la composición del Año de Factura y el Número de Factura.
En un principio, podríamos pensar que la Clave de Negocio contiene un valor único para cada fila de la base de datos, sin embargo, el hecho de trabajar con Tablas Versionadas o Históricas (Slowly Changing Dimension de Tipo 2) impide que sea así.
¿Qué es una Tabla Versionada o Histórica (Slowly Changing Dimension de Tipo 2)?
Habitualmente nos encontraremos con tablas de base de datos, para las cuales es posible que se produzcan modificaciones sobre sus datos a lo largo del tiempo, y además es necesario poder realizar un seguimiento de sus cambios a lo largo del tiempo. En entornos de Data Warehouse (DW) y Business Intelligence (BI), este tipo de tablas suelen tratarse de tablas de Dimensión, a las cuales se las denomina Tablas Slowly Changing Dimensions (SCD) o Tablas SCD. En las bases de datos operacionales (OLTP), este tipo de tablas (tablas versionadas) pueden modelarse de diferentes formas (ej: utilizar dos tablas, una para las versiones actuales y otra para las versiones históricas), aunque existen sistemas de gestión que modelan las tablas versionadas del mismo modo que se hace en un Data Warehouse.
Existen diferentes tipos de tablas Slowly Changing Dimension (SCD), en función de cómo se gestionen los cambios sobre los datos de dichas tablas. Principalmente, se pueden identificar los siguientes tipos de tablas Slowly Changing Dimensions (SCD):
- SCD Tipo 1. Los cambios sobre los datos de la tabla, son implementados con sentencias UPDATE, de tal modo, que no se puede realizar un seguimiento de cambios, aunque si resulta posible que dichos cambios se produzcan. En entornos de Data Warehouse en condiciones, las tablas SCD sólo se implementan en aquellos casos que el seguimiento de cambios no es relevante y/o no es frecuente, pues en caso contrario se suele utilizar tablas SCD de Tipo 2 (es lo suyo).
- SCD Tipo 2 (Tablas Versionadas). Los cambios sobre los datos de la tabla, son implementados con sentencias INSERT, es decir, manteniendo múltiples filas en la tabla para cada Clave de Negocio, de las cuales sólo una será la fila actual. En este caso, si es posible realizar un seguimiento de cambios ilimitado, pues podremos insertar ilimitadas filas (salvo que nos quedemos sin espacio en disco, claro ;-). En la práctica, es bastante habitual encontrarse con tablas SCD de Tipo 2.
- SCD Tipo 3. Los cambios sobre los datos de la tabla, son implementados agregando nuevos campos a la tabla, de tal modo que para un campo que pueda cambiar, se pueda utilizar un campo para el valor actual y otro campo para el valor anterior. En este caso, no se utilizan múltiples filas, aunque por el contrario se utilizarán múltiples campos. En consecuencia, es posible realizar un seguimiento limitado de los cambios, y dicho límite será impuesto por el número de campos utilizados para el seguimiento de cambios. En la práctica, es poco habitual encontrarse con tablas SCD de Tipo 3.
Volviendo al ejemplo de las Pólizas, para una empresa de seguros resultará vital poder realizar un seguimiento de una Póliza a lo largo de toda su historia, incluyendo todos los cambios sufridos a lo largo del tiempo sobre todas sus características (Tomador, Riesgos, Garantías contratadas, Capital Asegurado, etc.). Pero ¿Cómo podemos conseguirlo? Existen diferentes alternativas para implementar esta funcionalidad en el OLTP, como por ejemplo, siempre que se realiza un cambio sobre la tabla, en vez de realizar un UPDATE (en cuyo caso perderíamos la información original), se podría hacer un INSERT con la información más actual (esto es algo más complicado, pero quiero explicarlo así por fines didácticos), almacenando en cada fila (es decir, en cada versión) el periodo de tiempo para el cuál es válida la información de dicha fila de la base de datos (por ejemplo, incluyendo dos campos Fecha Desde y Fecha Hasta en la tabla). Evidentemente, estamos hablando de una tabla de Slowly Changing Dimension (SCD) de Tipo 2. En consecuencia, ya no podremos definir la Clave de Negocio como un campo único, ya que pueden existir múltiples filas (es decir, múltiples versiones, tanto la actual como una o varias versiones históricas) con el mismo valor de la Clave de Negocio (Business Key).
Claro está que no todas las tablas son susceptibles de convertirse a Tablas Versionadas (tablas SCD de Tipo 2), pero aún así, esta es una práctica muy habitual en entornos de aplicaciones empresariales y en entornos de Data Warehouse (DW) y Business Intelligence (BI).
Para conocer un mayor detalle de las Tablas Versionadas o Tablas Slowly Changing Dimensions (SCD) de Tipo 2 (cómo trabajar con Tablas Versionadas SCD Tipo 2, como definir un Modelo de Versionado, cómo denormalizar Tablas Versionadas SCD Tipo 2, como comprobar la existencia de versiones solapadas en Tablas Versionadas SCD Tipo 2, etc.), puede consultarse el artículo Trabajar con tablas versionadas (Fecha Desde y Fecha Hasta) en SQL Server, Slowly Changing Dimension (SCD) Tipo 2.
Ahora que ya hemos entendido el concepto de Clave de Negocio (Business Key) y el concepto de Tablas Versionadas o Históricas (Slowly Changing Dimension de Tipo 2), estamos en situación de poder comprender mejor que es una Clave Subrogada (Surrogate Key) y cuál es la función o utilidad de una Clave Subrogada en un entorno de Data Warehouse (DW) y Business Intelligence (BI).
¿Qué es una Clave Subrogada (Surrogate Key)?
Una Clave Subrogada es un campo numérico de una tabla cuyo único requisito es almacenar un valor numérico único para cada fila de la tabla, actuando como una clave sustituta, de forma totalmente independiente a los datos de negocio, que habitualmente no tiene significado por sí misma. En consecuencia, es posible crear una Clave Subrogada en cualquier tabla (se trate de una Tabla Versionada o no), aunque habitualmente resultan especialmente útiles al trabajar con Tablas Versionadas SCD de Tipo 2.
Algunos consultores de Business Intelligence (BI) recomiendan que en los Data Warehouse absolutamente todas las tablas tengan Claves Subrogadas, y en consecuencia la unión entre todas las tablas del Data Warehouse se realice siempre utilizando las Claves Subrogadas (es decir, autonuméricos o IDENTITYs). Yo personalmente no estoy totalmente de acuerdo con dicha afirmación (al menos con tal rigurosidad), ya que las Claves de Negocio será necesario mantenerlas en muchos casos (para incluirla en Reports o acciones de Drillthrough por requisitos de los Usuarios, para facilitar comprobaciones de datos entre el Data Warehouse y las fuentes origen de datos, etc.) y además la utilización de autonuméricos (IDENTITYs) en SQL Server en algunos casos resulta un poco más laborioso de lo deseable. Por ello, bajo mi opinión resulta de gran interés analizar cada caso por separado y tomar la decisión más ventajosa. Por ejemplo, con tablas versionadas puede evaluarse la posibilidad de utilizar Claves Subrogadas o quizás utilizar claves compuestas o concatenaciones de varios campos. Por el contrario, con tablas sin versionado (ej: tablas SCD de Tipo 1) puede plantearse la utilización de la Clave de Negocio (Business Key) exclusivamente.
Un ejemplo de utilización de Claves Subrogadas sobre tablas no versionadas, es el caso de la denormalización. Es decir, si tenemos una tabla en la cual almacenamos una descripción que se repite para muchas filas, es posible crear una nueva tabla que almacene los diferentes valores para dicha descripción asociados a un valor numérico único, y en la tabla inicial sustituir dicha descripción por el valor numérico asociado. Con esto habremos obtenido un menor tamaño de almacenamiento, y una indexación más óptima (es preferible indexar datos numéricos que datos texto de gran longitud).
Un ejemplo de utilización de Claves Subrogadas sobre tablas versionadas de un Data Warehouse (DW), es el caso de tener una Tabla de Dimensión Versionada (es decir, una tabla Slowly Changing Dimension de Tipo 2) como pueda ser nuestro ejemplo de Pólizas, en la cual almacenamos el Capital Asegurado de la Póliza, la Provincia del Tomador, y otros datos asociados a la Póliza que pueden cambiar con el tiempo, y que en cada cambio generarán una nueva fila (es decir, una nueva versión) en la tabla de Pólizas. De este modo, podemos tener una o varias tablas de hechos, como podría ser el ejemplo de Siniestros de las Pólizas o de Pagos de las Primas, pudiendo ahora asociar las tablas de hechos con las Dimensiones (en particular, con la Dimensión Póliza) a través de la Clave Subrogada. Esto nos permitirá poder asociar a cada Siniestro y/o a cada Prima (los ejemplos tomados), la versión correspondiente de la Póliza a la fecha correspondiente (ej: fecha de siniestro o fecha de prima).
Cara al diseño y construcción de nuestro modelo multidimensional (OLAP), como sería el caso del diseño y construcción de un Cubo de Analysis Services (SSAS), en la Dimensión Póliza mantendremos oculto el atributo correspondiente a la Clave Subrogada, construyendo las Jerarquías deseada para dicha Dimensión Póliza empleando los atributos deseados (ej: Nº Póliza, Provincia del Tomador, etc.).
¿Cómo crear una Clave Subrogada?
El caso habitual y natural de creación de una Clave Subrogada es la utilización de campos autonuméricos, como es el caso de los campo IDENTITY de SQL Server (este tipo de campos, si que cumple el requisito de no tener significado por sí mismos… jeje ;-). La teoría dice que una Clave Subrogada está formada por un único campo numérico, es decir, se debe evitar la creación de claves compuestas. Además, las Claves Subrogadas deben ser independientes de los datos de negocio (algo que también cumplen los datos autonuméricos). De hecho, algunos consultores de BI recomiendan que las Claves Subrogadas no se creen como un único campo fruto de concatenaciones de múltiples claves de negocio. Una vez más llevo la contraria (desde mi ignorancia), pues en ocasiones los campos autonuméricos pueden ofrecer grandes ventajas, pero en el caso de un Data Warehouse con complicados procesos de carga que pueden sufrir complejos cambios de diseño con bastante periodicidad, basar las uniones de todas las tablas en campos autonuméricos implica un mayor coste de mantenimiento, y plantearse la eliminación de las Claves de Negocio en el Data Warehouse podría considerarse incluso una aberración (insisto, bajo mi opinión). Por ello, como siempre, mi recomendación será estudiar cada caso por separado, dotando de autonuméricos cuando nos resulte ventajoso, y utilizando otras alternativas (concatenaciones de campos o claves compuestas) cuando su utilización nos resulte de interés.
Y hasta aquí llega este pequeño artículo, que como siempre, espero que os guste.
