A partir del modelo conceptual, es posible empezar a plantearse cómo será la arquitectura funcional del Data Warehouse. Para ello es necesario contemplar la existencia de una capa intermedia entre los sistemas origen y el DWH. Este estrato servirá de capa de abstracción entre el mundo de los procesos y el mundo analítico, permitiendo optimizar la integración con el modelo definitivo.
Llegados a este punto, se hace, por tanto, necesario definir dos bases de datos:
- ODS (Operational Data Store) o Staging Area: es la capa intermedia que servirá como almacenamiento entre los sistemas fuente y el Data Warehouse. Su misión es ofrecer la posibilidad de gestionar los datos con el formato y estructura de origen para facilitar la integración y transformación hacia el modelo desnormalizado que poseen los Datamarts y el Data Warehouse. Hay que tener en cuenta que los sistemas fuente presentan toda la información separada por tablas, mientras que en destino la información se compila en una estructura común, que facilita en gran medida, no sólo las búsquedas, sino también la comprensión de los datos que contienen.
- Data Warehouse propiamente dicho, cuya función es mucho más compleja que la de un simple almacén de datos, como puede extraerse de la riqueza de su estructura, que se compone de:
- Tablas maestras (denominadas en el mundo analítico "dimensiones conformadas"): son los pilares del Data Warehouse. Hacen posible establecer relaciones entre los distintos Datamarts en base a las dimensiones comunes del negocio.
- Datamarts: que pueden aparecer modelados en estrella (desnormalizados) o en copo de nieve (sin llegar a ser una opción desnormalizada, tampoco se puede hablar de que sea puramente normalizada), siendo mucho más recomendable la primera alternativa salvo escasas excepciones. Los Datamarts se componen de:
* Dimensiones temáticas propias del Datamart, con sus respectivos atributos.
* Tablas de hecho, con sus respectivas métricas:
- Transaction Fact Tables: son las tablas que, en último término, recogerán los datos que tienen que ver con el negocio. Vienen de la mano de transacciones, no sólo económicas, sino también resultado de un proceso de negocio (importe de ventas, cantidad vendida, etc.).
- Factless Fact Tables/Coverage Tables: en este caso, los hechos de negocio no proceden de una transacción, sino de una cuantificación (por ejemplo, cantidad de clientes, cantidad de clases de productos diferentes que se han vendido), y, por eso, resultan en todo caso en hechos cuantitativos.
- Periodic Snapshot Fact Tables: este tipo de tablas son las más utilizadas para hacer seguimiento de stock, ya que, al ser el stock un valor se encuentra en constante dinamismo, es preciso contar con instantáneas que almacenen los diferentes estadios de su evolución ligada a un factor temporal.
- Accumulating Snapshot Fact Table: que satisfacen las necesidades de información en cuanto a acumulados, ya que en muchos casos es preciso conocer los datos agregados, por ejemplo los Balances en el entorno financiero.
- Tablas agregadas: son tablas de hecho también, aunque en su caso prescinden de algunas dimensiones para simplificar el análisis y no penalizar los tiempos de respuesta.
ODS y DWH: cómo llevar a cabo el modelado
Tanto el Operational Data Store (ODS), como el Data Warehouse (DWH) requieren de la definición de un modelo de datos lógico y, posteriormente, de la de un modelo de datos físico.
En ambos casos es preciso realizar:
- Modelos de datos lógicos: su orientación es eminentemente operativa, más que descriptiva de una realidad. En este modelo, es preciso comenzar a definir cada uno de los objetos que conformarán el modelo físico (tablas, campos y relaciones) aunque sin entrar en el detalle técnico del tipo de dato ni el tipo de restricción que deban caracterizar, ni a cada uno, ni a sus relaciones.
- Modelos de datos físicos: se trata de estructuras de datos a bajo nivel cuya implementación se ha producido teniendo en cuenta el propio motor de bases de datos. Esto implica que la definición de cada tabla, campo o relación, tendrá que ser impecable a la hora de reunir las características propias del motor de base de datos que soportará la solución en una vez en marcha.
La gran diferencia entre el modelo de datos lógico y el físico es que, mientras que el primero es todavía un borrador, aunque su esquema ya dibuja la estructura del DWH o de ODS con tablas y con campos interconectados entre sí (fecha de ventas, producto vendido, cliente, cantidad de productos, precio unitario e importe); de momento no entra en mayor detalle acerca de la presentación de los datos.
El modelo físico traslada ese modelo lógico, que ya tiene una estructura definida, determinando físicamente cómo va a ser (entero, decimal, alfanumérico, etc.). Aquí se definen todos los tipos de información en función de las bases de datos que se utilizarán. A la hora de definir el modelo de datos físico es recomendable, aunque no imprescindible, tener en mente contra qué se implantará el DWH, ya que sólo así es posible ser preciso a la hora de conocer el tipo de detalle, de campo y de relaciones que serán necesarias.
El proceso de modelado, que hasta hace unos años se hacía con papel y lápiz, hoy día se lleva cabo a través del lenguaje de definición de datos (DDL: Data Definition Language), que es un lenguaje estándar de definición soportado por todos los motores de bases de datos para construir estructuras de datos y tablas con campos y relaciones. Las tecnologías de hoy en día, permiten “dibujar” tanto el modelo conceptual, como el modelo lógico y realizar la operación de construir el modelo físico, generando las sentencias nativas del motor de base de datos para la creación del modelo definitivo mediante el DDL.
