El modelo estrella

Hay 2 modelos para crear un Data Warehouse, el modelo estrella o el copo de nieve.
Yo prefiero el modelo estrella, ya que el tiempo de respuesta que provee es ms rpido y hace
que el servidor trabaje menos.
El concepto de Estrella es bastante sencillo. Hay que disear las tablas usando una
tabla central para los hechos, tablas para los catlogos y una tabla de tiempo.

El modelo del diseo de las tablas en el modelo estrella est en los catlogos. Tiene
que poner en una sola tabla todo aquello que se pueda deducir del elemento ms granular de
la tabla y que est ms abajo en la jerarqua.
Por ejemplo, si usted tiene un catlogo de productos, el elemento ms granular es el
producto qu se puede deducir del producto? Pues la marca, el empaque, la presentacin
(botella de cristal, PET no retornable, lata, etc.), la familia (bebidas), la subfamilia, la categora,
la subcategoria, el color, la talla si aplica, etc.
Bueno pues todo esto se coloca en la misma tabla.
El campo llave de esa tabla es el product_id (la llave de producto) por que producto (product)
es el elemento ms abajo en la jerarqua. Vealo de esta forma: una marca tiene productos, la
familia agrupa productos, la subfamilia igual, la categora igual, el color igual. El producto es el
nico que no agrupa a nadie, entonces esa es la la llave.
Si usted le hiciera un select a ese catlogo de productos el resultado sera el siguiente.

Puede ver que en el mismo registro se almacena el producto, la marca, la subcategoria,

el departamento, la familia, la categoria. Todo lo que se puede deducir del producto est ah.
Lo mismo pasa con las tiendas. De la tabla de tiendas (ver tabla Stores en el diagrama)
se puede deducir la region y el pais al que pertenece. Entonces pais y regin los pongo en la
misma tabla que tienda.
Para mejorar todava ms el tiempo de respuesta coloque en la tabla el campo llave y
el descriptor como se muestra en la siguiente imagen.

Si hace esto en el query SQL que escriba para obtener datos de la estrella podr usar:

where
IdBrand = 15
en vz de:
where
Brand = Washington
Tendr un mejor tiempo de respuesta si usa llaves. Entonces siempre en los catlogos
ponga adems de los descriptores el campo llave de cada descriptor.

La tabla de hechos

Cuando estamos construyendo nuestro Data Warehouse tenemos que disear la tabla
central que es la que guardar los hechos. A diferencia de un sistema transaccional donde en
una tabla tenemos el total de la factura, en otra el total de la orden de compra, en otro el tipo
de cambio (y as sucesivamente) en un Data Warehouse (DWH) los hechos (las cosas que
sucedieron) estn en una nica tabla.
Para aclarar la palabra hechos: qu sucedi en mi compaia? Pues vend, compr,
vend en unidades, tuve un # de empleados. Entonces en la tabla de hechos se guardan las
ventas, las ventas en unidades, las compras, etc..Todo lo que sean indicadores.
Tampoco se trata de hacer una tabla gigantesca que tenga lo de recursos humanos + lo
de ventas + lo de produccion + lo de telemarketing + todo!
Normalmente las cosas que estn en la tabla de hechos tienen afinidad entre s. De
esta forma tendremos una tabla de Hechos de Ventas, una de inventario, una de Recursos
Humanos, una de produccion, etc.
No todas las herramientas de explotacin de Data Warehouse permiten hacer reportes
o informes tomando informacin de 2 o ms tablas de hechos; es por esto que a veces en un
DWH se suelen encontrar cosas extraas como las ventas y el # de empleados en la misma
tabla de hechos ( para hacer el calculo de Ventas/#Personas). El problema de esto es que el
DWH vuelve catico: cada vez que necesite hacer un calculo entre 2 tablas de hechos hago un
nueva table de hechos que junte las 2 y entonces me lleno de tablas de hechos o cubos ( si
trabaja con cubos Rolap a esto se le llama cubitis).

La dimensin Tiempo

Cuando estamos diseando las estrellas de tiempo. Hay varias formas de hacerlo y
para mi gusto unas mejores que otras. La forma ms comn de encontrar es una en la que el
campo llave es la fecha.

Aqu a la arriba est el tpico diseo. El problema aqu es que a las bases de datos les
cuesta trabajo hacer bsquedas por campos datetime o date, al menos ms que un campo
entero. Otro punto es que el campo fecha ocupa ms espacio que un campo entero. Hay que
tomar muy en cuenta que el campo fecha, que es la llave, formar parte de la tabla de hechos;
y con millones y millones de registros un byte o dos es mundo de espacio, tal vez un disco duro

Podemos mejorar el diseo cambiando el campo llave por un campo entero como en la
figura de la derecha. Esto har que:
Las bsquedas sean ms rpidas sobre todo en la tabla de hechos. Esto por que a las
bases de datos les cuesta menos trabajo manejar nmeros que fechas, o sea
ocuparemos menos el procesador y ocuparemos menos memoria.
Que el tiempo de respuesta sea ms rpido. No es redundancia, este punto es una
consecuencia de lo anterior.
Que fsicamente los datos ocupen menos espacio. De nuevo, el servidor trabaja menos
con menor volumen de informacin y se requieren menos procesador y menos
memoria o sea que la ganancia es doble.
En este diseo hay 2 corrientes, los que usan un numero consecutivo como llave y los que
usamos un numero en el formato yyyyMMdd. Para mi gusto es muy frustrante encontrarse
una estrella donde la llave de la tabla tiempo es un 1,2,3,434560,34561,.@#$%#$$% para
saber a que fecha corresponden el 34561!pues hay que hacerle un query a la tabla de
tiempo.
Yo prefiero de llave un numero con el formato yyyyMMdd, as para el 31 de diciembre del
2007 guardo 20071231 en el campo TiempoID, sigue siendo un numero entero y es mucho
ms legible que un simple 1-2-3. Con solo ver que valor tiene el campo TiempoID puedo saber
a que fecha corresponde el registro. Adems funciona perfectamente en el where con un
between:

SELECT *
FROM HECHOS

WHERE TIEMPOID BETWEEN 20070101 AND 20070131

Hay un punto no tan visible con el campo llave: la tabla de hechos tiene ndices para
acelerar el tiempo de respuesta. Los ndices ocupan espacios y si usamos un campo entero en
vez de un datetime estaremos ahorrando espacio y hacindole la vida ms fcil al servidor.
En bases de datos pequeas 1 a 10 gigas da lo mismo usar uno u otro. En bases de datos
gigantes como las de grandes tiendas departamentales o tiendas de conveniencia donde la
base de datos del data warehouse mide teras usar un campo entero es de vital importancia.