¿Estrella o Copo de Nieve?

22 10 2007

Plato

Cada vez que comenzamos un proyecto nuevo siempre es lo mismo ¿Estrellas o copos de nieve?¿que es mejor? Es una decisión dificil de tomar.

A mi me gusta trabajar más con estrellas. El tiempo de respuesta del servidor es más rápido debido a que se involucran menos tablas en los querys. Sin embargo tienen la desventaja que hay que programar más. Los programas que se encargarán de estar manteniendo los catálogos (o puntas de la estrella) al día son más complejos.

La ventaja que yó le veo a los copos de nieve es que la información se puede pasar casi siempre tal cual viene. O sea que en un 2×3 podemos tener lista la parte del modelo referente a los catálogos.

Respecto al trabajo que se requiere para llenar la tabla de hechos no hay diferencia entre un modelo y el otro.

No son verdades absolutas. En un modelo estrella, cuando el catálogo que representa una dimensión que tiene demasiados registros, involucrar esta tabla no es tán eficiente. No se requiere ser un genio para darse cuenta que si tengo una estrella donde se usa la dimensión cliente con 500,000 registros y si el sexo de nuestro cliente es una columna más de la tabla de clientes, entonces hacer un query que nos dé las compras por el sexo del cliente (¿quién compra más, las mujeres o los hombres?) hará que la base de datos recorra 500,000 registros del catálogo para sacar los valores diferentes de sexo. Esto hará que el servidor trabaje más; aquí el modelo copo de nieve sería más eficiente.

Si usted tiene Redbrick, entonces no se preocupe, puede hacer todo como una estrella perfecta y crearle agregados a los catálogos. Sí, Redbrick recorre las tablas de la estrella y coloca en una tabla de agregados los valores diferentes de las dimensiones (sexo) dentro de la grán dimension (clientes). Si no estoy mal, lo mismo debe suceder con Oracle.

Lo siento, no he tenido la oportunidad de verificar si otras marcas de base de datos tienen esta capacidad.

Si usted tiene el tiempo suficiente para hacer todo como debe de ser digamos que la regla sería: 

Si los valores de las dimensiones son pocos (los catálogos) use el modelo estrella. Para dimensiones gigantescas use el modelo copo de nieve.

¿qué es gigantesco y qué no lo es? La experiencia y el hardware de su servidor lo dirán.

Como vé, en muchos proyectos no se pueden tener estrellas ó copos de nieve. A veces lo que se requieren son híbridos, mitad y mitad.

About these ads




¿Qué es un cubo?

14 09 2007

 

Si alguna vez les ha tocado programar un reporte o informe que tome la información de una base de datos sabrán que es un dolor de cabeza. Para hacerlo hay que definir de que tabla, de qué campo y con qué condiciones se saca cada cosa que muestra el reporte. Ahora piense que ese reporte que tanto trabajo le costó en vez de tener cortes o subtotales por cliente ahora lo quieren por tienda o producto, el de al lado lo quiere por familia y el departamento de compras lo quiere por proveedor con el añadido que lo quiere en dólares o Euros y con información de Costos y Margen.

Usted tendría prácticamente que hacer un nuevo reporte para cada caso, esto debido a la complejidad (que es normal) en las bases de datos transaccionales. Así es como nació la necesidad de las herramientas donde la información mostrada en el informe o reporte fuera manipulada dinámicamente.

Eso es lo que es OLAP.

No era fácil hacer que el reporte fuera manipulado dinámicamente debido a la complejidad de donde se sacaban los datos. Hacer un cambio de variables implicaba en vez de 1 tabla acceder a 4 o más. Para resolver esta situación los fabricantes de este tipo de software idearon extraer la información de la base de datos transaccional y colocarla en una base de datos que tuviera una estructura estándar para almacenar las diferentes variables de la información. De esta forma el reporte podía ser cambiante debido a que la estructura donde se almacenaba el dato siempre era conocida.

Como en el fútbol, se pusieron los datos “de pechito”.

Esto es lo que son los cubos. No son otra cosa que esas “bases de datos” de donde las herramientas OLAP toman la información que muestran; bases de datos que están diseñadas especialmente para que las herramientas puedan hacer esos cruces espectaculares de información en su pantalla.

Note que hacer cubos tiene un costo. Hay que tomar los datos de los sistemas transaccionales y llevarlos a esa base de datos. Esto se hace a lo mejor una vez al día, una vez cada hora o a lo mejor una vez al mes. Todo depende de la frecuencia con la que quiere que la información esté actualizada.

Es debido a esto que los cubos se procesan.

Hay muchas herramientas para hacer cubos y explotarlos, yo uso las herramientas de BITAM, uso Artus.

¿Todavía quedaron dudas, verdad? Hay más cosas que saber de un cubo…¿cuales son las que estarían interesados en conocer?

Technorati tags:




¿qué es un data warehouse?

23 08 2007

almacen

Para aquellos que les haya tocado la época en donde todas las consultas se resolvían con reportes o queries se acordarán de los problemas más comunes de aquellos tiempos.

  • Cientos de tablas de donde sacar la información ¿cuál era la buena?
  • El reporte solo se podía ejecutar por las noches o los fines de semana
  • 20 sistemas diferentes en diferentes lenguajes y diferentes bases de datos
  • la información estaba en 20 servidores distintos
  • varias versiones de la verdad
  • mil problemas más

Ahora cuando recuerdo las petición “necesito un reporte consolidado de las operaciones de la empresa” puedo entender mi stress.

Debo corregir el texto. Esos problemas no forman parte del pasado. Como consultor de BI me los encuentro cada día en cada una de las empresas que visito.

Alguien sugirió para resolver todos esos problemas relacionados con la consulta y análisis de información crear una base de datos que contuviera toda la información histórica de la compañía. De esta forma si necesitaba un dato, ese dato estaría ahí. En un solo lugar. En un solo sistema. En una sola marca de base de datos. En un solo lenguaje de consulta y con una sola verdad.

Regresando a la pregunta ¿qué es un data warehouse o bodega de información? Pues es eso, una base de datos o bodega e información que almacena los datos históricos de los diferentes sistemas en un solo lugar. Y sirve, están diseñado y está hecho para ser consultado y para analizar información. Todo esto de una manera fácil.

—¿base de datos histórica?¿ Entonces si levanto un respaldo de mi sistema en otro servidor es un data warehouse?

No se emocione Nerd. Si usted levanta el respaldo de los 5 años anteriores del sistema de facturación en otro servidor eso NO es un datawarehouse.

Así como en las bodegas tradicionales se utilizan tarimas de varios niveles, carritos y grúas para acomodar grandes cantidades de artículos, en un data warehouse las tablas que almacenan información se diseñan de una manera especial pensando en que almacenarán cantidades gigantescas de información.

Esas maneras especiales o modelos son el copo de nieve y estrella. Cada uno tiene sus ventajas y desventajas.

He visto data warehouses diseñados como si fueran el sistema de facturación o el de producción. Desde mi punto de vista son inservibles todos ellos. Hay un excelente documento llamado Drawing the line between Dimensional Modeling and ER Modeling Techiques by Ralph Kimball que pinta la línea perfectamente.

¿y los cubos? Eso es punto y aparte. No són la misma cosa, se complementan y a menudo se traslapan. He estado en empresas con data warehouses explotados con SQL y Excel, sin cubos. Lo platicamos después.

Otro punto que debe de considerar es que la información que contiene por lo general debe estar trasformada y limpia ( usted no tiene una columna total_documentos; en el DWH tiene métricas que se llaman Ventas, Ventas en dólares, Devoluciones, mermas, etc.).

Todavía hay más cosas como los agregados, pero creo que con todo lo anterior queda un poco más claro qué es un data warehouse.

Technorati tags:




El modelo estrella

1 08 2007

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 los catálogos y una tabla de tiempo.

ModeloEstrellaSales

El meollo 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 presentacion (botella de cristal, PET no retornable, aluminio, 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 o más granular. 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.

ResultSetEstrella

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.

ResultSetEstrella1

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.

TIP: Si está pensando crear un cubo con los Analysis Services de Microsoft usando esta estrella, el poner la llave en la estrella hace que el cubo se reduzca de tamaño y el tiempo de respuesta se acelere. Solo tenga cuidado de que al crear la dimensión, en propiedades de la dimensión ubique y use la propiedad “llave de la dimensión”.

TIP: Para las llaves trate de que siempre sean numéricas y de no usar llaves compuestas.

TIP: Si va a seguir el tip anterior, puede ayudarse poniendo en los catálogos además de la nueva llave inventada por usted, la llave original para la dimensión. Yo siempre las identifico con Id y Cve, la que termina en ID es inventada por mí y la que termina o comienza en CVE es la original.

¿A partir del producto yo puedo deducir en que tienda se vendió? Suponiendo que hablamos de supermercados y en cada tienda se pueden vender los mismos productos entonces la respuesta es NO, no se puede deducir qué tienda vendió qué producto. Esto se resuelve en la tabla de hechos poniendo ahí que producto se vendio (producto_id), en que tienda (store_id) y en que día (time_id).

Esto es el modelo estrella.

IMPORTANTE: No se quede con la idea que al hacer los catálogos redundantes va a desperdiciar todo el disco duro. La redundancia es solo en los catálogos no en los hechos, usted puede tener un catálogo de 100,000 productos pero millones y millones de transacciones. Lo que hace que un datawarehouse crezca normalmente es la tabla de hechos. Si todavía está renuente y saca a relucir las reglas de Codd de normalizacion, para no entrar en polémica digamos que este es uno de los extraños casos donde lo que aprendió en la universidad lo puede tirar a la basura Big Grin.

Para complentar esto puede consultar los posts La tabla de hechos y Algunas recomendaciones para la tabla de hechos. Respecto a la tabla de tiempo (TimeDim) puede leer La dimensión tiempo y los otros campos de la tabla de tiempo.

Si quiere ver como convertir una estrella a un cubo puede consultar como hacer un cubo con Artus.








Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 28 seguidores