En las bases de datos utilizadas en (data warehousing), un esquema en copo de nieve es una estructura algo ms compleja que el esquema

en estrella. Se da cuando alguna de las dimensiones se implementa con ms de una tabla de datos. La finalidad es normalizar las tablas y as reducir el espacio de almacenamiento al eliminar la redundancia de datos; pero tiene la contrapartida de generar peores rendimientos al tener que crear ms tablas de dimensiones y ms relaciones entre las tablas (JOINS) lo que tiene un impacto directo sobre el rendimiento. En las aplicaciones OLAP implementadas sobre bases de datos relacionales (ROLAP), un elemento clave es el Cubo OLAP. Estos cubos (tambin llamados hipercubos) almacenan grandes volmenes de datos que posteriormente deben ser analizados en funcin de unos determinados parmetros. Al disear las tablas en las que se han de almacenar estos datos y parmetros, si se aplican las tcnicas de Normalizacin de bases de datos para optimizar el espacio requerido para guardar estos datos eliminando las redundancias, es habitual que se termine obteniendo un esquema en copo de nieve; en este tipo de esquemas se tiene una tabla central de hechos en la que se guardan las medidas del negocio que se quiere analizar, y en las tablas adyacentes se tendrn las dimensiones (parmetros) de que dependen los datos del negocio. Si por alguna dimensin se requiere ms de una tabla se dice que el esquema resultante es un esquema en copo de nieve. En el ejemplo de la figura adjunto, pese a no estar totalmente normalizada (por ejemplo, la tabla 'Dimension_Almacen' tiene redundancias) se observa como para algunas dimensiones de la tabla de hechos como Producto y Cliente se ha empleado ms de una tabla, dando lugar a una jerarqua de dimensiones. Por ejemplo, los productos se pueden clasificar por marcas, adems, estos mismos productos se pueden agrupar por categoras y subcategoras. Argumentos a favor y en contra del esquema en copo de nieve El nico argumento a favor de los esquemas en copo de nieve es que al estar normalizadas las tablas de dimensiones, se evita la redundancia de datos y con ello se ahorra espacio. Pero si tenemos en cuenta que hoy en da, el espacio en disco no suele ser un problema, y s el rendimiento, se presenta con una mala opcin en Data warehouse, ya que el hecho de disponer de ms de una tabla por cada dimensin de la tabla de hechos implica tener que realizar cdigo ms complejo para realizar una consulta que a su vez se ejecutar en un tiempo mayor, debido en parte al mayor nmero de uniones (JOINS) que habr que realizar. Se puede usar un esquema de copo de nieve en un Data warehouse, aunque estos sean realmente grandes y complejos, pero nunca en sistemas donde el tiempo de respuesta sea un factor crtico para los usuarios. El modelo estrella 1082007 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 los catlogos y una tabla de tiempo.

El meollo 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 presentacion (botella de cristal, PET no retornable, aluminio, 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 o ms granular. 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. 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 tamao y el tiempo de respuesta se acelere. Solo tenga cuidado de que al crear la dimensin, en propiedades de la dimensin ubique y use la propiedad llave de la dimensin. TIP: Para las llaves trate de que siempre sean numricas y de no usar llaves compuestas. TIP: Si va a seguir el tip anterior, puede ayudarse poniendo en los catlogos adems de la nueva llave inventada por usted, la llave original para la dimensin. 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 da (time_id). Esto es el modelo estrella. IMPORTANTE: No se quede con la idea que al hacer los catlogos redundantes va a desperdiciar todo el disco duro. La redundancia es solo en los catlogos no en los hechos, usted puede tener un catlogo de 100,000 productos pero millones y millones de transacciones. Lo que hace que un datawarehouse crezca normalmente es la tabla de hechos. Si todava est renuente y saca a relucir las reglas de Codd de normalizacion, para no entrar en polmica digamos que este es uno de los extraos casos donde lo que aprendi en la universidad lo puede tirar a la basura

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 dimensin 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.
Esquema en estrella: Consiste en estructurar la informacin en procesos, vistas y mtricas recordando a una estrella (por ello el nombre star schema). Es decir, tendremos una visin multidimensional de un proceso que medimos a travs de unas mtricas. A nivel de diseo, consiste en una tabla de hechos (lo que en los libros encontraremos como fact table) en el centro para el hecho objeto de anlisis y una o varias tablas de dimensin (dimension table) por cada dimensin de anlisis que participa de la descripcin de ese hecho. En la tabla de hecho encontramos los atributos destinados a medir (cuantificar) el hecho: sus mtricas. Mientras, en las tablas de dimensin, los atributos se destinan a elementos de nivel (que representan los distintos niveles de las jerarquas de dimensin) y a atributos de dimensin (encargados de la descripcin de estos

elementos de nivel). En el esquema en estrella la tabla de hechos es la nica tabla del esquema que tiene mltiples joins que la conectan con otras tablas (foreign keys hacia otras tablas). El resto de tablas del esquema (tablas de dimensin) nicamente hacen join con esta tabla de hechos. Las tablas de dimensin se encuentran adems totalmente denormalizadas, es decir, toda la informacin referente a una dimensin se almacena en la misma tabla. Esquema en copo de nieve: El esquema en copo de nieve (snowflake schema) es un esquema de representacin derivado del esquema en estrella, en el que las tablas de dimensin se normalizan en mltiples tablas. Por esta razn, la tabla de hechos deja de ser la nica tabla del esquema que se relaciona con otras tablas, y aparecen nuevas joins gracias a que las dimensiones de anlisis se representan ahora en tablas de dimensin normalizadas. En la estructura dimensional normalizada, la tabla que representa el nivel base de la dimensin es la que hace join directamente con la tabla de hechos. La diferencia entre ambos esquemas (star y snowflake) reside entonces en la estructura de las tablas de dimensin. Para conseguir un esquema en copo de nieve se ha de tomar un esquema en estrella y conservar la tabla de hechos, centrndose nicamente en el modelado de las tablas de dimensin, que si bien en el esquema en estrella se encontraban totalmente denormalizadas, ahora se dividen en subtablas tras un proceso de normalizacin. Es posible distinguir dos tipos de esquemas en copo de nieve, un snowflake completo (en el que todas las tablas de dimensin en el esquema en estrella aparecen ahora normalizadas en el snowflake) o un snowflake parcial (slo se lleva a cabo la normalizacin de algunas de ellas).

Tablas de hecho Denominamos hechos a los indicadores de negocio. Por ejemplo, son hechos las ventas, los pedidos, los envos, las reclamaciones, las compras, etc. Es decir, son todas aquellas medidas numricas que incluiremos en nuestro sistema Business Intelligence. Tcnicamente, una tabla de hecho es la tabla central de un modelo en estrella. En el siguiente diagrama, la tabla de ventas es la tabla de hechos:

Una caracterstica importante de las tablas de hecho es el nivel de detalle de la informacin que se almacena. En el anterior ejemplo, las ventas estn guardadas a nivel de cliente, producto, almacn, promocin y fecha. La tabla de hechos contiene las claves subrogadas de aquellas dimensiones que definen su nivel de detalle, y los indicadores. Nada ms. Por lo tanto, antes de crear la tabla de hechos debe entenderse perfectamente la informacin que se guardar, o se estar cometiendo el error nmero 7 de esta serie sobre cmo construir un datawarehouse Error 7: Aadir dimensiones en una tabla de hechos antes de definir su granularidad. De hecho, la creacin de una tabla de hechos es una tarea con poco margen a la imaginacin. Antes que nada, debe localizarse el origen de la informacin que se quiere cargar, debe entenderse perfectamente el significado de estos indicadores, y debe determinarse el nivel de detalle de estos datos. Una vez hecho esto, la creacin de la estructura de la tabla es inmediata. Tal y como comentaba anteriormente:La tabla de hechos contiene las claves subrogadas de aquellas dimensiones que definen su nivel de detalle, y los indicadores. Nada ms. Y nada menos. En particular, es un error desnormalizar cualquier dimensin en la tabla de hechos. Por ejemplo, si la informacin est a nivel de cliente, no necesitamos poner la poblacin o el pas en la tabla de hechos. Resultara redundante e impactara directamente en el tamao de la tabla (y en los tiempos de respuesta).

Un DW requiere de un diseo robusto que apoye la obtencin de informacin en el tiempo preciso y con datos que generen valor al negocio y que ofrezcan una ventaja competitiva.

La arquitectura de un DW consta de 4 niveles, divididos segn su funcionalidad.

1. Transacciones Contempla los manejadores de bases de datos relacionales sobre los que trabajan los sistemas de informacin comunes de la empresa. Es muy comn encontrar en este nivel, manejadores como Sybase, Oracle, SQL Server e IBM DB2 entre otros.

2. Extraccin (Sybase IQ InfoPrimer)

Sybase IQ InfoPrimer extrae datos de diferentes sistemas de la empresa, los transforma y los carga enSybase IQ. Sybase InfoPrimer complementa a Sybase IQ mediante la optimizacin de los datos a granel ycarga incremental en ambientes de Sybase IQ . Es una herramienta muy eficaz que proporciona un rpido retorno de la inversin mediante la entrega de datos rpida y fiable de los sistemas de origen en Sybase IQ y los prepara para la presentacin de informes o anlisis complejos. Ver ms >>

3. Modelado (Sybase PowerDesigner).

Sybase PowerDesigner es la nica herramienta de modelado y administracin de metadatos que soporta el modelado desde las reglas de negocio hasta la implementacin utilizando la tecnologa de Sincronizacin y Enlace (Link and Synch), eliminando las islas de informacin, incrementando la alineacin del negocio y TI y permitiendo respuestas rpidas a cambios tecnolgicos, regulatorios y competitivos. Ver ms >>

4. Servidor de Reportes - Motor Anltico de DW (Sybase IQ) Los beneficios obtenidos a travs de Sybase IQ sobre los DBMS tradicionales son gracias a su tecnologa basada en columnas lo que implica mayor velocidad de acceso a los datos y algoritmos de compresin mucho ms efectivos; como resultado de esto se mejora el rendimiento de las consultas mientras se requiere menor gasto en recursos de almacenamiento. Esto es especialmente evidenciado en consultas que son muy complejas o cuando se requiere manipular tablas de gran tamao.

Sybase IQ responde a las preguntas de los usuarios de 10 a 100 veces ms rpido que las tecnologas para Data Warehouse tradicionales, sin importar la cantidad de usuarios y consultas concurrentes, gracias a su tecnologa patentada de almacenamiento por columnas y mtodos de indexamiento. Los resultados a las consultas ad-hoc son retornados en segundos o minutos en lugar de horas o das como ocurra con las tecnologas tradicionales, permitiendo que el ambiente Data Warehouse ofrezca soluciones en tiempo real. Ver ms >>

5. Herramientas de Visualizacin. stas herramientas van a permitir visualizar la informacin existente en el motor anlitico Sybase IQ a travs de cuadros de mandos, definicin de indicadores de gestin, grficos de tendencia, etc. Sybase IQ es compatible con cualquier tipo de herramienta que soporte conexin ODBC o JDBC, como por ejemplo IBM Cognos. Cognos 8 Business Intelligence ofrece a las organizaciones una solucin completa basada en Web para todos los componentes del ciclo de vida del reporte: reportes colaborativos, reportes empresariales completos, reportes que pueden ser creados una sola vez y consumidos en cualquier sitio y en cualquier momento; y una solucin que es adaptable a cualquier fuente de datos. Ver

ms >>