En la anterior entrega de esta serie sobre cómo no construir un datawarehouse ya introducía el concepto de las “claves subrogadas”.
Una clave subrogada es un identificador único que se asigna a cada registro de una tabla de dimensión. Esta clave, generalmente, no tiene ningún sentido específico de negocio. Son siempre de tipo numérico. Preferiblemente, un entero autoincremental.
Habitualmente, el sistema operacional ya utiliza sus propias claves, aunque suelen ser de tipo carácter y tienen un sentido específico para los empleados de la compañía. Por ejemplo, el código BCN puede utilizarse para referirse a Barcelona, o el DNI de cada empleado puede ser la clave única de la tabla de empleados. O el código de barras para referirse a un producto. ¿Por qué necesitamos, entonces, crear unos nuevos identificadores en el sistema Business Intelligence? Por varios motivos:
- Fuentes heterogéneas. El DWH suele alimentarse de diferentes fuentes, cada una de ellas con sus propias claves, por lo que es arriesgado asumir un código de alguna aplicación en particular. ¿Qué ocurriría si en el futuro se añade información de una aplicación que tiene su propio maestro de ciudades? Seguro que nos generará un problema, aparecerán ciudades que no existían en nuestro maestro…¿Cómo lo gestionaríamos? No sé. Lo mejor es crear nuestras propias claves subrogadas desde el inicio del proyecto.
- Cambios en las aplicaciones origen. Puede ocurrir que cambie la lógica operacional de alguna clave que hubiésemos supuesto única, o que siempre debería estar informada. ¿Qué pasará cuando llegue un empleado sin DNI? ¿Qué pasará cuando se de de alta una ciudad extranjera con el código BCN? Prefiero no saberlo. Lo mejor es crear nuestras propias claves subrogadas desde el inicio del proyecto.
- Rendimiento. En la base de datos, ocupa menos espacio un entero que una cadena. Identificar una ciudad con 5 bytes, o una persona con 9 bytes es un desperdicio considerable de espacio. De hecho, no debe preocuparnos el espacio que ocupa, sino el tiempo que se pierde en leerlo… Recordad que las claves subrogadas las llevaremos a las tablas de hechos, por lo que cada código es susceptible de repetirse cientos de millones de veces. Conviene optimizarlo al máximo. Lo mejor es crear nuestras propias claves subrogadas desde el inicio del proyecto.
Por supuesto, también se pueden cometer errores al generar una clave subrogada…
Error 8: Crear “smart keys” para relacionar una tabla de dimension con una tabla de hechos.
En ocasiones, nos puede parecer útil aprovechar la lógica que subyace a los elementos para generar nuestras propias claves. Por ejemplo, si queremos crear una jerarquía de ciudades, nunca debemos caer en la tentación de crear una simple concatenación (y generar el código ESP-CAT-BCN para referirnos a Barcelona)… También es un error crear una clave compuesta de varios campos. Aunque en el operacional la terna país-CCAA-ciudad sea única, en el DWH debemos crear una clave subrogada formada por un solo campo entero autoincremental.
Recuerda: Sustituye cualquier clave física por una clave entera numerada secuencialmente desde 1 hasta N.
