Diseo de un Data Mart

Objetivos:

Entender los principios de diseo de bases de datos OLAP.

Comprender los conceptos de tablas de dimensin y tablas de
hechos.
Comprender los modelos STAR y SNOWFLAKE.

Temas
1. Diferencias de diseo entre los sistemas OLTP y los sistemas
OLAP.
2. Principios de diseo de bases de datos OLAP.

Captulo 2

Data Warehouse & Olap

Data Warehouse & Olap

1.

Diferencias de diseo entre los sistemas OLTP

y los sistemas OLAP

El diseo de
fundamentales
datos OLTP.
caractersticas

las bases de datos OLAP presenta diferencias

respecto de los principios de diseo de las bases de
La siguiente tabla muestra las principales
de ambos tipos de almacenamiento de datos:

Transaccionales: OLTP
Bases de datos altamente
normalizadas

Anlisis: OLAP
Bases de datos a-normalizadas

Se normaliza hasta la
tercera forma

Se normaliza hasta la primera

forma.

Diseos complejos de base Diseos sencillos de base de

de datos
datos.
Almacena informacin
detallada

Almacena informacin
totalizada

Alto nmero de joins para

acceder a la informacin

Bajo nmero de joins.

Dinmico (nmero alto de

modificaciones)

Esttico (slo lectura)

Data Warehouse & Olap

El objetivo de las bases de datos OLAP es responder a las

preguntas clave del negocio. Estas preguntas suelen la siguiente
apariencia:

2.

Cul es el volumen de ventas de impresoras en el Cusco

durante el primer trimestre del ao 2005?
Cul fue la contribucin de las ventas por marketing
directo, respecto de las ventas totales?
Cul fue el producto de mayor venta en el sur del pas
durante el ao pasado?

Principios de diseo de bases de datos OLAP

La informacin proporcionada por un sistema OLAP debe cumplir

las siguientes caractersticas:
1. Presentacin en un formato intuitivo y fcil de usar para el
usuario.
2. Alta performance para acceder a bsquedas complejas que
involucren grandes cantidades de informacin.
3. Modelo multidimensional
El modelo dimensional de los data marts complementa el modelo
normalizado entidad relacin, optimizando la generacin de
reportes complejos de alta performance.
Los elementos fundamentales del diseo de un data mart son:

Fact table (tabla de hechos): Almacena eventos (por

ejemplo, las ventas). Contiene las mtricas que miden la
efectividad de las operaciones del negocio.
Fact (hecho): Es una fila de la fact table. Representa un
evento especfico.
Measures (medidas): Valores cuantitativos que almacenan
las mtricas del negocio. Estn representados por columnas
numricas en la fact table.
Dimensin: Es una entidad de negocios respecto de la cual
se deben calcular las mtricas. Ejemplos: clientes,
productos, tiempo.
Dimension Table (tabla de dimensin): Tablas que
almacenan las dimensiones.

Data Warehouse & Olap

2.1

El modelo Estrella (STAR)

La tcnica ms popular para disear un data mart es el esquema

STAR (Estrella). Esta estructura asocia una tabla de hechos (Fact
Table) con mltiples tablas de dimensin (dimension tables).
Este modelo incrementa la performance de las consultas, al
reducir considerablemente el nmero de lecturas efectuadas sobre
el disco.

Data Warehouse & Olap

A continuacin se listan los componentes de un esquema STAR:

Fact Table
Un data mart implementado con Analysis Services est orientado a
brindar a los usuarios informacin numrica, que contribuya a
entender el comportamiento del negocio y tomar mejores
decisiones. Esta informacin numrica recibe el nombre de
medida (measure). Algunos ejemplos de medidas comnmente
utilizadas por todo tipo de negocio son: ventas, unidades vendidas,
costo, gasto, etc.
Las medidas se almacenan en una o ms tablas de hechos (fact
tables). Toda tabla de hechos contiene una cantidad variable de
columnas numricas, que almacenan los valores de las medidas.
Tablas de dimensin
Para entender el negocio, es fundamental conocer los valores de
las ventas, los costos y los gastos. Sin embargo, estos nmeros son
de escasa utilidad si no se definen los criterios que se usarn para
cruzar la informacin.

Data Warehouse & Olap

Por ejemplo, la medida Ventas, por s sola, no brinda suficiente

informacin. En un reporte, estamos visualizando el total de
ventas desde que se fund la empresa? O las ventas para un
determinado perodo 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 terminologa de Business
Intelligence, se denomina dimensiones. Las dimensiones
contienen las descripciones de las entidades principales del
negocio, respecto de las cuales se calcularn las medidas.
Las dimensiones tienen mltiples criterios de agrupacin. Por
ejemplo, una dimensin de ubicacin geogrfica puede agrupar su
informacin en continentes, regiones, pases y ciudades. Estos
criterios de agrupacin se denominan niveles (levels). La
principal caracterstica de los niveles es que cada nivel se
encuentra contenido en su nivel superior: una ciudad est
contenida en un pas, dicho pas en una regin, y la regin en un
continente.
Las dimensiones se almacenan en tablas de dimensin. Las
caractersticas de una tabla de dimensin son:

Tienen una relacin uno muchos con la tabla de hechos

(fact table).
Incluyen una clave primaria, de preferencia numrica y auto
incrementada.

El diseo de las tablas de dimensin es, generalmente, sencillo y

de fcil comprensin. Sea, por ejemplo, la dimensin 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
mltiples presentaciones de productos. El diseo de la tabla de
dimensin PRODUCTO_DIM es:
PRODUCTO_DIM
Producto_Key
IDProducto
Familia
Subfamilia
Marca
Presentacin

Data Warehouse & Olap

El campo Producto_Key es la clave primaria de la tabla de

dimensin. Una buena prctica es establecer un tipo de dato
entero y auto generado para las claves de las tablas de dimensin,
pues esto incrementar la velocidad de las consultas (si se
efectan directamente sobre el modelo STAR) o de los
procesamientos de informacin (si las consultas se efectan a
travs de un cubo).
El campo IDProducto sirve para conocer el identificador del
producto en su sistema de origen (recurdese que la informacin
del Data Mart puede tener mltiples orgenes). Este campo ser
til durante la escritura de los procesos de poblacin del Data
Mart.
En este ejemplo, los niveles de la dimensin Producto son:
Familia, Subfamilia, Marca y Presentacin. En un modelo
STAR, los niveles de la dimensin estn representados por
columnas en la tabla de dimensin. Obsrvese, 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
dimensin. Cada tabla de hechos est enlazada con mltiples
tablas de dimensin. El siguiente diseo corresponde con una
tabla de hechos que almacena informacin de ventas:
VENTAS_FACT
Tiempo_Key
Producto_Key
Cliente_Key
Monto
Cantidad
Una tabla de hechos tiene las siguientes caractersticas:

Posee una clave primaria compuesta por los campos que

representan sus relaciones con las tablas de dimensin.
Posee columnas numricas 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 forneas que
enlazan la tabla de hechos con las tablas de dimensin 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.

Data Warehouse & Olap

Obsrvese el siguiente diagrama. Este modelo consta de cinco

tablas de dimensin: Employee, Product, Customer, Shipper y
Time, circundando a una tabla de hechos llamada Sales_Fact.

Cada registro de la tabla Sales_Fact representa un hecho de

ventas. Sus cinco primeros campos constituyen la clave primaria, y
provienen de su relacin con cada una de las tablas de dimensin.
Las columnas restantes representan las medidas relacionadas con
las ventas. A partir de este modelo, es fcil comprender que las
mtricas de ventas (almacenadas en Sales_Fact) se computan por
producto, empleado, cliente, proveedor y tiempo (almacenados en
las tablas de dimensin).

Ejercicio 1: Diseo de un data mart para tarjetas de

crdito.

El rea de tarjetas de crdito de un banco desea implementar un

data mart. Se desea visualizar la informacin de crditos
concedidos y pagos hasta llegar a cada tarjeta. Las tarjetas pueden
ser de dos tipos: VISA y MASTERCARD. Tambin se desea
visualizar los crditos 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 mtricas

Data Warehouse & Olap

deben visualizarse como totalizados anuales, semestrales,

trimestrales y mensuales. Disee las dimensiones, las medidas y el
modelo de datos.
Solucin:
El primer paso en la construccin de un data mart es la definicin
de las medidas. Del enunciado del problema, puede deducirse que
existen dos medidas en este data mart: crditos concedidos y
pagos.
A continuacin, se deben establecer las dimensiones del data
mart. Se desea visualizar la informacin por cliente y vendedor.
Esto sugiere la existencia de dos dimensiones: Cliente y
Vendedor. Para cada dimensin, se deben establecer los niveles.
Cada cliente est en un distrito, cada distrito en una provincia y
cada provincia en un departamento. Por tanto, la dimensin
Cliente tiene los siguientes niveles:
Dimensin Cliente
. Departamento
.. Provincia
Distrito
. Nombre cliente
Obsrvese el uso de la notacin de puntos para representar a los
niveles. El nivel ms superior se representa por un punto al lado
izquierdo, el nivel siguiente por dos puntos, y as sucesivamente.
Respecto de la dimensin Vendedor, se sabe que cada vendedor
est en una agencia, cada agencia en un distrito, cada distrito en
una provincia y cada provincia en un departamento. Por tanto, los
niveles de la dimensin Vendedor son:
Dimensin Vendedor
. Departamento
.. Provincia
Distrito
. Agencia
.. Nombre Vendedor
Por otro lado, las tarjetas de crdito pueden ser de dos tipos:
VISA y MASTERCARD. Esto sugiere la existencia de la
dimensin Tipo Tarjeta, con un solo nivel.
Dimensin Tipo Tarjeta
. Tipo Tarjeta
.. Nro. Tarjeta

Data Warehouse & Olap

Por ltimo, las medidas deben visualizarse como totalizados

anuales, semestrales, trimestrales y mensuales. Por lo general,
todo data mart tiene una dimensin que representa las escalas
temporales. En este caso, existe una dimensin llamada Tiempo,
que tiene la siguiente estructura:
Dimensin Tiempo
. Ao
.. Semestre
Trimestre
. Mes
El modelo del STAR para este data mart es:

TIEMPO_DIM
Tiempo_Key
Ao

TARJETAS_FACT
Tiempo_Key
Cliente_Key
VENDEDOR_DI
M
Vendedor_Key
IdVendedor

Vendedor_Key
TipoTarjeta_Key
Creditos
concedidos
Pagos

Semestre
Trimestre
Mes

TIPOTARJETA_D
IM
TipoTarjeta_Key
IdTipoTarjeta

Departamento
Provincia
Distrito
TipoTarjeta
Agencia
NumeroTarjeta
Nombre
vendedor
2.2
El modelo Copo de Nieve (SNOWFLAKE)

En el modelo STAR, cada nivel es representado por una columna

en la tabla de dimensin. En el modelo SNOWFLAKE, cada nivel
est representado por una tabla. Por tanto, en este modelo una
dimensin puede estar formada por varias tablas.

Data Warehouse & Olap

La siguiente tabla modela la entidad PRODUCTO, en un modelo

STAR tpico:
PRODUCTO_DIM
Producto_Key
IDProducto
Familia
Subfamilia
Marca
Presentacin

En un modelo SNOWFLAKE, esta tabla se partira en cuatro:

FAMILIA_DIM
Familia_Key
IdFamilia
Familia
SUBFAMILIA_DI
M
SubFamilia_Key
Familia_Key
IdSubFamilia
SubFamilia
MARCA_DIM
Marca_Key
SubFamilia_Key
IdMarca
Marca
PRESENTACION_D
IM
Presentacion_Key
Marca_Key
IdPresentacion
Presentacion

Data Warehouse & Olap

El siguiente
diagrama
muestra otro
ejemplo de
modelo
SNOWFLAKE.
Obsrvese que
nicamente la
tabla que
representa el
nivel ms
detallado
(Product) est
unida con la
tabla de
hechos.

2.3

El modelo STAR vs. el modelo SNOWFLAKE

La siguiente tabla muestra una comparacin de

caractersticas de los modelos STAR y SNOWFLAKE:
Entendimiento
del
modelo
Nmero de tablas
Complejidad
de
la
consulta
Performance
de
las
consultas
y
el
procesamiento del cubo

STAR
Sencillo

diversas

Menor
Baja

SNOWFLAKE
Mayor
dificultad
Mayor
Alta

Rpida

Lenta

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

procesamiento del Data Mart mejora considerablemente debido a
que el nmero de joins necesario para obtener los datos es menor.
En cambio, el modelo SNOWFLAKE, debido al alto nmero de
tablas que produce, tiene un tiempo de procesamiento y respuesta
ms alto.
Por otro lado, un modelo STAR es baDE DDE VDSVxed31qstante
ms sencillo que un modelo SNOWFLAKE. El modelo

Data Warehouse & Olap

SNOWFLAKE es ms difcil de entender, y sus procesos de carga

de datos son ms complejos.

2.4

Clculos 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 numricas. Existen dos enfoques para generar
los preclculos de informacin:

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 operacin
aritmtica
efectuada
con
las
columnas
Precio
y
PorcentajeDescuento.
Precalculado mltiple: 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

Debido a que una Fact Table puede almacenar grandes volmenes

de informacin, se debe eliminar de ella cualquier dato no
relevante: informacin redundante, operaciones no necesarias,
eventos que no representan una operacin del negocio.
Es una buena prctica estimar desde la fase de diseo el tamao
que tendr una Fact Table. Este clculo puede efectuarse con base
en el ancho (en bytes) de cada fila, y el nmero de transacciones
esperadas por unidad de tiempo.

Data Warehouse & Olap

Data Warehouse & Olap

Laboratorio 2:

Caso: empresa de transportes

Una empresa de transportes desea implementar un data mart. Se

desea visualizar la informacin de ventas hasta llegar a cada
boleto. Cada boleto pertenece a una ruta, por ejemplo: Lima
Ica, Arequipa Puno, etc. Tambin 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
mtricas deben visualizarse como totalizados anuales, semestrales,
trimestrales y mensuales. Disee las dimensiones, las medidas y
los modelos de datos STAR y SNOWFLAKE.