Este documento describe los principios básicos del diseño de bases de datos OLAP y data marts. Explica las diferencias entre los sistemas OLTP y OLAP, y los principios de diseño de bases de datos OLAP, incluidos los conceptos de tablas de hechos, tablas de dimensión, medidas, y los modelos estrella y copo de nieve. También incluye un ejemplo de diseño de un data mart para una empresa de transporte con dimensiones, medidas y modelos de datos.

1. Data Warehouse & Olap 1
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.
Capítulo
2

2. 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
normalizadas
Bases de datos a-normalizadas
Se normaliza hasta la tercera forma Se normaliza hasta la primera forma.
Diseños complejos de base de
datos
Diseños sencillos de base de datos.
Almacena información detallada Almacena información totalizada
Alto número de joins para acceder
a la información
Bajo número de joins.
Dinámico (número alto de
modificaciones)
Estático (sólo lectura)
El objetivo de las bases de datos OLAP es responder a las preguntas clave del negocio.
Estas preguntas suelen la siguiente apariencia:

3. Data Warehouse & Olap 3
 ¿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.

4. 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.
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.

5. Data Warehouse & Olap 5
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 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).

6. Data Warehouse & Olap 6
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
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.

7. Data Warehouse & Olap 7
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:

8. Data Warehouse & Olap 8
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
el procesamiento del cubo
Rápida Lenta
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.

9. Data Warehouse & Olap 9
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.

10. Data Warehouse & Olap 10
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.