Data Warehouse & Olap 1

Capítulo 2
Diseño de un Data Mart

Objetivos:

 Entender los principios de diseño de bases de datos OLAP.

 Comprender los conceptos de tablas de dimensión y tablas de hechos.
 Comprender los modelos STAR y SNOWFLAKE.

Temas
1. Diferencias de diseño entre los sistemas OLTP y los sistemas OLAP.
2. Principios de diseño de bases de datos OLAP.
Data Warehouse & Olap 2

1. Diferencias de diseño entre los sistemas OLTP y los sistemas

OLAP

El diseño de las bases de datos OLAP presenta diferencias fundamentales respecto de

los principios de diseño de las bases de datos OLTP. La siguiente tabla muestra las
principales características de ambos tipos de almacenamiento de datos:

Transaccionales: OLTP Análisis: OLAP

Bases de datos altamente Bases de datos a-normalizadas
normalizadas
Se normaliza hasta la tercera Se normaliza hasta la primera forma.
forma
Diseños complejos de base de Diseños sencillos de base de datos.
datos
Almacena información detallada Almacena información totalizada
Alto número de joins para acceder Bajo número de joins.
a la información
Dinámico (número alto de Estático (sólo lectura)
modificaciones)
Data Warehouse & Olap 3

El objetivo de las bases de datos OLAP es responder a las preguntas clave del
negocio. Estas preguntas suelen la siguiente apariencia:

 ¿Cuál es el volumen de ventas de impresoras en el Cusco durante el primer

trimestre del año 2005?
 ¿Cuál fue la contribución de las ventas por marketing directo, respecto de las
ventas totales?
 ¿Cuál fue el producto de mayor venta en el sur del país durante el año
pasado?

2. Principios de diseño de bases de datos OLAP

La información proporcionada por un sistema OLAP debe cumplir las siguientes

características:

1. Presentación en un formato intuitivo y fácil de usar para el usuario.

2. Alta performance para acceder a búsquedas complejas que involucren
grandes cantidades de información.
3. Modelo multidimensional

El modelo dimensional de los data marts complementa el modelo normalizado

entidad – relación, optimizando la generación de reportes complejos de alta
performance.

Los elementos fundamentales del diseño de un data mart son:

 Fact table (tabla de hechos): Almacena eventos (por ejemplo, las ventas).
Contiene las métricas que miden la efectividad de las operaciones del
negocio.
 Fact (hecho): Es una fila de la fact table. Representa un evento específico.
 Measures (medidas): Valores cuantitativos que almacenan las métricas del
negocio. Están representados por columnas numéricas en la fact table.
 Dimensión: Es una entidad de negocios respecto de la cual se deben calcular
las métricas. Ejemplos: clientes, productos, tiempo.
 Dimension Table (tabla de dimensión): Tablas que almacenan las
dimensiones.
Data Warehouse & Olap 4

2.1 El modelo Estrella (STAR)

La técnica más popular para diseñar un data mart es el esquema STAR (Estrella).
Esta estructura asocia una tabla de hechos (Fact Table) con múltiples tablas de
dimensión (dimension tables).

Este modelo incrementa la performance de las consultas, al reducir

considerablemente el número de lecturas efectuadas sobre el disco.
Data Warehouse & Olap 5

A continuación se listan los componentes de un esquema STAR:

Fact Table

Un data mart implementado con Analysis Services está orientado a brindar a los
usuarios información numérica, que contribuya a entender el comportamiento del
negocio y tomar mejores decisiones. Esta información numérica recibe el nombre de
medida (measure). Algunos ejemplos de medidas comúnmente utilizadas por todo
tipo de negocio son: ventas, unidades vendidas, costo, gasto, etc.

Las medidas se almacenan en una o más tablas de hechos (fact tables). Toda tabla
de hechos contiene una cantidad variable de columnas numéricas, que almacenan los
valores de las medidas.
Tablas de dimensión

Para entender el negocio, es fundamental conocer los valores de las ventas, los costos
y los gastos. Sin embargo, estos números son de escasa utilidad si no se definen los
criterios que se usarán para cruzar la información.

Por ejemplo, la medida Ventas, por sí sola, no brinda suficiente información. En un

reporte, ¿estamos visualizando el total de ventas desde que se fundó la empresa? ¿O
Data Warehouse & Olap 6

las ventas para un determinado período de tiempo? ¿Es necesario ver las ventas
desglosadas por cliente y producto? ¿Se desea visualizar las ventas por distribuidor?

En este caso, tiempo, cliente, producto y distribuidor constituyen ejemplos de lo

que, en la terminología de Business Intelligence, se denomina dimensiones. Las
dimensiones contienen las descripciones de las entidades principales del negocio,
respecto de las cuales se calcularán las medidas.

Las dimensiones tienen múltiples criterios de agrupación. Por ejemplo, una

dimensión de ubicación geográfica puede agrupar su información en continentes,
regiones, países y ciudades. Estos criterios de agrupación se denominan niveles
(levels). La principal característica de los niveles es que cada nivel se encuentra
contenido en su nivel superior: una ciudad está contenida en un país, dicho país en
una región, y la región en un continente.

Las dimensiones se almacenan en tablas de dimensión. Las características de una

tabla de dimensión son:

 Tienen una relación uno – muchos con la tabla de hechos (fact table).
 Incluyen una clave primaria, de preferencia numérica y auto incrementada.

El diseño de las tablas de dimensión es, generalmente, sencillo y de fácil

comprensión. Sea, por ejemplo, la dimensión Producto. Los productos de la empresa
se agrupan por familias, las cuales contienen subfamilias de productos. Cada
subfamilia consta de varias marcas de productos. Finalmente, cada marca contiene
múltiples presentaciones de productos. El diseño de la tabla de dimensión
PRODUCTO_DIM es:

PRODUCTO_DIM
Producto_Key
IDProducto
Familia
Subfamilia
Marca
Presentación

El campo Producto_Key es la clave primaria de la tabla de dimensión. Una buena

práctica es establecer un tipo de dato entero y auto generado para las claves de las
tablas de dimensión, pues esto incrementará la velocidad de las consultas (si se
efectúan directamente sobre el modelo STAR) o de los procesamientos de
información (si las consultas se efectúan a través de un cubo).
El campo IDProducto sirve para conocer el identificador del producto en su sistema
de origen (recuérdese que la información del Data Mart puede tener múltiples
orígenes). Este campo será útil durante la escritura de los procesos de población del
Data Mart.

En este ejemplo, los niveles de la dimensión Producto son: Familia, Subfamilia,

Marca y Presentación. En un modelo STAR, los niveles de la dimensión están
Data Warehouse & Olap 7

representados por columnas en la tabla de dimensión. Obsérvese, en la tabla

PRODUCTO_DIM, las columnas que representan los niveles anteriormente
mencionados.

Un data mart está constituido por tablas de hechos y tablas de dimensión. Cada tabla
de hechos está enlazada con múltiples tablas de dimensión. El siguiente diseño
corresponde con una tabla de hechos que almacena información de ventas:

VENTAS_FACT
Tiempo_Key
Producto_Key
Cliente_Key
Monto
Cantidad

Una tabla de hechos tiene las siguientes características:

 Posee una clave primaria compuesta por los campos que representan sus
relaciones con las tablas de dimensión.
 Posee columnas numéricas para las medidas.

En el ejemplo anterior, las columnas Tiempo_Key, Producto_Key y Cliente_Key

constituyen la clave primaria de la tabla de hechos Ventas_Fact. Estas columnas
contienen claves foráneas que enlazan la tabla de hechos con las tablas de dimensión
Tiempo, Producto y Cliente. Las columnas Monto y Cantidad corresponden con
las medidas de la tabla de hechos, y representan, respectivamente, el monto vendido
y la cantidad vendida.

Obsérvese el siguiente diagrama. Este modelo consta de cinco tablas de dimensión:

Employee, Product, Customer, Shipper y Time, circundando a una tabla de hechos
llamada Sales_Fact.
Data Warehouse & Olap 8

Cada registro de la tabla Sales_Fact representa un hecho de ventas. Sus cinco

primeros campos constituyen la clave primaria, y provienen de su relación con cada
una de las tablas de dimensión. Las columnas restantes representan las medidas
relacionadas con las ventas. A partir de este modelo, es fácil comprender que las
métricas de ventas (almacenadas en Sales_Fact) se computan por producto,
empleado, cliente, proveedor y tiempo (almacenados en las tablas de dimensión).

 Ejercicio 1: Diseño de un data mart para tarjetas de crédito.

El área de tarjetas de crédito de un banco desea implementar un data mart. Se desea

visualizar la información de créditos concedidos y pagos hasta llegar a cada tarjeta.
Las tarjetas pueden ser de dos tipos: “VISA” y “MASTERCARD”. También se desea
visualizar los créditos y pagos por cada vendedor y cada cliente. Cada cliente
pertenece a un distrito, cada distrito a una provincia y cada provincia a un
departamento. Cada vendedor pertenece a una agencia, y cada agencia pertenece a un
distrito, cada distrito a una provincia y cada provincia a un departamento. Las
métricas deben visualizarse como totalizados anuales, semestrales, trimestrales y
mensuales. Diseñe las dimensiones, las medidas y el modelo de datos.

2.2 El modelo STAR vs. el modelo SNOWFLAKE

La siguiente tabla muestra una comparación de diversas características de los

modelos STAR y SNOWFLAKE:
Data Warehouse & Olap 9

STAR SNOWFLAKE
Entendimiento del modelo Sencillo Mayor dificultad
Número de tablas Menor Mayor
Complejidad de la consulta Baja Alta
Performance de las consultas y Rápida Lenta
el procesamiento del cubo

En un modelo STAR, la performance de las consultas y del procesamiento del Data

Mart mejora considerablemente debido a que el número de joins necesario para
obtener los datos es menor. En cambio, el modelo SNOWFLAKE, debido al alto
número de tablas que produce, tiene un tiempo de procesamiento y respuesta más
alto.

Por otro lado, un modelo STAR es baDE DDE VDSVxed31qstante más sencillo que
un modelo SNOWFLAKE. El modelo SNOWFLAKE es más difícil de entender, y
sus procesos de carga de datos son más complejos.

2.3 Cálculos definidos en la tabla de hechos

La tabla de hechos almacena resultados consolidados en las columnas que

representan las medidas (measures). Dichas columnas deben ser numéricas. Existen
dos enfoques para generar los precálculos de información:

 Precalculado sencillo: En la tabla de hechos pueden existir columnas que se

calculen a partir de los datos de otras columnas en la misma fila. Por ejemplo,
una columna que exprese el precio descontado, a partir de una operación
aritmética efectuada con las columnas Precio y PorcentajeDescuento.
 Precalculado múltiple: Puede definirse una columna que almacene un valor
acumulado a partir de varias filas. Por ejemplo, una columna que almacene el
total de ventas para el producto cuya clave es 2.
Data Warehouse & Olap 10

Debido a que una Fact Table puede almacenar grandes volúmenes de información, se
debe eliminar de ella cualquier dato no relevante: información redundante,
operaciones no necesarias, eventos que no representan una operación del negocio.

Es una buena práctica estimar desde la fase de diseño el tamaño que tendrá una Fact
Table. Este cálculo puede efectuarse con base en el ancho (en bytes) de cada fila, y el
número de transacciones esperadas por unidad de tiempo.
Data Warehouse & Olap 11

Laboratorio 2: Caso: empresa de transportes

Una empresa de transportes desea implementar un data mart. Se desea visualizar la

información de ventas hasta llegar a cada boleto. Cada boleto pertenece a una ruta,
por ejemplo: “Lima – Ica”, “Arequipa – Puno”, etc. También se desea visualizar las
ventas, costos y gastos asociados con cada bus, empleado y agencia. Cada bus ha
sido producido por un fabricante, por ejemplo, “Mercedes Benz”. Cada empleado
puede ser “piloto”, “asistente de servicio en bus” o “administrativo”. Cada agencia
pertenece a una ciudad, y cada ciudad a un departamento. Las métricas deben
visualizarse como totalizados anuales, semestrales, trimestrales y mensuales. Diseñe
las dimensiones, las medidas y los modelos de datos STAR y SNOWFLAKE.