Download El modelo estrella

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 más rápido y hace
que el servidor trabaje menos.
El concepto de Estrella es bastante sencillo. Hay que diseñar las tablas usando una
tabla central para los hechos, tablas para los catálogos y una tabla de tiempo.
El modelo del diseño de las tablas en el modelo estrella está en los catálogos. Tiene
que poner en una sola tabla todo aquello que se pueda deducir del elemento más granular de
la tabla y que está más abajo en la jerarquía.
Por ejemplo, si usted tiene un catálogo de productos, el elemento más granular es el
producto ¿qué se puede deducir del producto? Pues la marca, el empaque, la presentación
(botella de cristal, PET no retornable, lata, etc.), la familia (bebidas), la subfamilia, la categoría,
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 más abajo en la jerarquía. Vealo de esta forma: una marca tiene productos, la
familia agrupa productos, la subfamilia igual, la categoría 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 catálogo de productos el resultado sería 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 región los pongo en la
misma tabla que tienda.
Para mejorar todavía más 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 véz de:
where
Brand = ‘Washington’
Tendrá un mejor tiempo de respuesta si usa llaves. Entonces siempre en los catálogos
ponga además de los descriptores el campo llave de cada descriptor.
La tabla de hechos
Cuando estamos construyendo nuestro Data Warehouse tenemos que diseñar 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) están en una única tabla.
Para aclarar la palabra hechos: ¿qué sucedió en mi compañia? 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 están 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 explotación de Data Warehouse permiten hacer reportes
o informes tomando información de 2 o más tablas de hechos; es por esto que a veces en un
DWH se suelen encontrar cosas extrañas 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 caótico: 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 dimensión Tiempo
Cuando estamos diseñando las estrellas de tiempo. Hay varias formas de hacerlo y
para mi gusto unas mejores que otras. La forma más común de encontrar es una en la que el
campo llave es la fecha.
Aquí a la arriba está el típico diseño. El problema aquí es que a las bases de datos les
cuesta trabajo hacer búsquedas por campos datetime o date, al menos más que un campo
entero. Otro punto es que el campo fecha ocupa más 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 diseño cambiando el campo llave por un campo entero como en la
figura de la derecha. Esto hará que:
Las búsquedas sean más rápidas sobre todo en la tabla de hechos. Esto por que a las
bases de datos les cuesta menos trabajo manejar números que fechas, o sea
ocuparemos menos el procesador y ocuparemos menos memoria.
Que el tiempo de respuesta sea más rápido. No es redundancia, este punto es una
consecuencia de lo anterior.
Que físicamente los datos ocupen menos espacio. De nuevo, el servidor trabaja menos
con menor volumen de información y se requieren menos procesador y menos
memoria o sea que la ganancia es doble.
En este diseño 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,4…34560,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
más legible que un simple 1-2-3. Con solo ver que valor tiene el campo TiempoID puedo saber
a que fecha corresponde el registro. Además 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 haciéndole la vida más fácil al servidor.
En bases de datos pequeñas 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.