Modelado de la bóveda de datos

Modelo simple de bóveda de datos con dos centros (azul), un enlace (verde) y cuatro satélites (amarillo)

La bóveda de datos intenta resolver el problema de tratar con el cambio en el entorno separando las claves de negocio (que no mutan tan a menudo, porque identifican de forma única una entidad de negocio) y las asociaciones entre esas claves de negocio, de los atributos descriptivos de esas claves.

Las claves de negocio y sus asociaciones son atributos estructurales, formando el esqueleto del modelo de datos. El método de la bóveda de datos tiene como uno de sus principales axiomas que las claves de negocio reales sólo cambian cuando el negocio cambia y, por tanto, son los elementos más estables de los que derivar la estructura de una base de datos histórica. Si se utilizan estas claves como columna vertebral de un almacén de datos, se puede organizar el resto de los datos en torno a ellas. Esto significa que la elección de las claves correctas para los núcleos es de suma importancia para la estabilidad de su modelo. Las claves se almacenan en tablas con algunas restricciones en la estructura. Estas tablas de claves se llaman hubs.

HubsEdit

Los hubs contienen una lista de claves comerciales únicas con baja propensión a cambiar. Los Hubs también contienen una clave sustituta para cada elemento del Hub y metadatos que describen el origen de la clave de negocio. Los atributos descriptivos de la información del Hub (como la descripción de la clave, posiblemente en varios idiomas) se almacenan en estructuras denominadas tablas Satélite que se discutirán más adelante.

El Hub contiene al menos los siguientes campos:

• una clave sustituta, utilizada para conectar las otras estructuras a esta tabla.
• una clave de negocio, el conductor de este hub. La clave de negocio puede consistir en múltiples campos.
• la fuente del registro, que puede utilizarse para ver qué sistema cargó primero cada clave de negocio.
• opcionalmente, también puede tener campos de metadatos con información sobre las actualizaciones manuales (usuario/hora) y la fecha de extracción.

No se permite que un hub contenga múltiples claves de negocio, excepto cuando dos sistemas entregan la misma clave de negocio pero con colisiones que tienen significados diferentes.

Los hubs deben tener normalmente al menos un satélite.

Ejemplo de hubEditar

Este es un ejemplo para una tabla hub que contiene coches, llamada «Coche» (H_CAR). La clave de manejo es el número de identificación del vehículo.

LinksEdit

Las asociaciones o transacciones entre claves de negocio (relacionando por ejemplo los hubs de cliente y producto entre sí a través de la transacción de compra) se modelan utilizando tablas de links. Estas tablas son básicamente tablas de unión de muchos a muchos, con algunos metadatos.

Los enlaces pueden enlazar con otros enlaces, para hacer frente a los cambios en la granularidad (por ejemplo, la adición de una nueva clave a una tabla de base de datos cambiaría el grano de la tabla de base de datos). Por ejemplo, si se tiene una asociación entre cliente y dirección, se podría añadir una referencia a un enlace entre los núcleos de producto y empresa de transporte. Este podría ser un enlace llamado «Entrega». Hacer referencia a un enlace en otro enlace se considera una mala práctica, porque introduce dependencias entre enlaces que dificultan la carga en paralelo. Dado que un enlace a otro enlace es lo mismo que un nuevo enlace con los hubs del otro enlace, en estos casos crear los enlaces sin referenciar otros enlaces es la solución preferida (ver la sección de prácticas de carga para más información).

Los enlaces a veces enlazan hubs con información que no es por sí misma suficiente para construir un hub. Esto ocurre cuando una de las claves de negocio asociadas por el enlace no es una clave de negocio real. Como ejemplo, tomemos un formulario de pedido con «número de pedido» como clave, y líneas de pedido que tienen como clave un número semi-aleatorio para hacerlas únicas. Digamos, «número único». Esta última clave no es una clave comercial real, por lo que no es un eje. Sin embargo, necesitamos utilizarla para garantizar la granularidad correcta del enlace. En este caso, no utilizamos un concentrador con clave sustituta, sino que añadimos la propia clave empresarial «número único» al enlace. Esto se hace sólo cuando no hay posibilidad de utilizar nunca la clave de negocio para otro enlace o como clave para atributos en un satélite. Esta construcción ha sido denominada «enlace con patas de palo» por Dan Linstedt en su foro (ya desaparecido).

Los enlaces contienen las claves sustitutas para los hubs que están enlazados, su propia clave sustituta para el enlace y metadatos que describen el origen de la asociación. Los atributos descriptivos de la información de la asociación (como la hora, el precio o el importe) se almacenan en estructuras denominadas tablas satélite que se comentan a continuación.

Ejemplo de enlaceEditar

Este es un ejemplo para una tabla de enlace entre dos hubs para coches (H_CAR) y personas (H_PERSON). El enlace se llama «Conductor» (L_DRIVER).

SatellitesEdit

Los hubs y los links forman la estructura del modelo, pero no tienen atributos temporales y no contienen atributos descriptivos. Se almacenan en tablas separadas llamadas satélites. Estos constan de metadatos que los vinculan a su centro o enlace principal, metadatos que describen el origen de la asociación y los atributos, así como una línea de tiempo con las fechas de inicio y fin del atributo. Mientras que los hubs y los enlaces proporcionan la estructura del modelo, los satélites proporcionan la «carne» del modelo, el contexto para los procesos de negocio que se capturan en los hubs y los enlaces. Estos atributos se almacenan tanto con respecto a los detalles del asunto como a la línea de tiempo y pueden ir desde bastante complejos (todos los campos que describen el perfil completo de un cliente) hasta bastante simples (un satélite en un enlace con sólo un indicador de validez y una línea de tiempo).

Usualmente los atributos se agrupan en satélites por sistema de origen. Sin embargo, los atributos descriptivos como el tamaño, el coste, la velocidad, la cantidad o el color pueden cambiar a diferentes velocidades, por lo que también se pueden dividir estos atributos en diferentes satélites en función de su tasa de cambio.

Todas las tablas contienen metadatos, describiendo mínimamente al menos el sistema de origen y la fecha en que esta entrada se hizo válida, dando una visión histórica completa de los datos a medida que entran en el almacén de datos.

Ejemplo de satéliteEditar

Este es un ejemplo para un satélite en el enlace de conductores entre los hubs de coches y personas, llamado «Seguro del conductor» (S_DRIVER_INSURANCE). Este satélite contiene atributos específicos del seguro de la relación entre el coche y la persona que lo conduce, por ejemplo, un indicador de si se trata del conductor principal, el nombre de la compañía de seguros de este coche y de la persona (también podría ser un hub distinto) y un resumen del número de accidentes en los que está implicada esta combinación de vehículo y conductor. También se incluye una referencia a una tabla de búsqueda o referencia llamada R_RISK_CATEGORY que contiene los códigos de la categoría de riesgo en la que se considera que se encuentra esta relación.

(*) al menos un atributo es obligatorio.(**) el número de secuencia se convierte en obligatorio si es necesario para reforzar la unicidad para múltiples satélites válidos en el mismo hub o enlace.

Tablas de referenciaEditar

Las tablas de referencia son una parte normal de un modelo de bóveda de datos saludable. Están ahí para evitar el almacenamiento redundante de datos de referencia simples que se referencian mucho. Más formalmente, Dan Linstedt define los datos de referencia de la siguiente manera:

Cualquier información que se considere necesaria para resolver las descripciones de los códigos, o para traducir las claves en (sic) una manera consistente. Muchos de estos campos son de naturaleza «descriptiva» y describen un estado específico de la otra información más importante. Como tal, los datos de referencia viven en tablas separadas de las tablas de la Bóveda de Datos en bruto.

Las tablas de referencia se referencian desde los Satélites, pero nunca se vinculan con claves externas físicas. No hay una estructura prescrita para las tablas de referencia: utilice lo que mejor funcione en su caso específico, desde simples tablas de búsqueda hasta pequeñas bóvedas de datos o incluso estrellas. Pueden ser históricas o no tener historia, pero se recomienda ceñirse a las claves naturales y no crear claves sustitutas en ese caso. Normalmente, las bóvedas de datos tienen muchas tablas de referencia, como cualquier otro Data Warehouse.

Ejemplo de referenciaEditar

Este es un ejemplo de tabla de referencia con categorías de riesgo para conductores de vehículos. Se puede referenciar desde cualquier satélite de la bóveda de datos. Por ahora la referenciamos desde el satélite S_DRIVER_INSURANCE. La tabla de referencia es R_RISK_CATEGORY.

(*) al menos un atributo es obligatorio.