Archivo

Posts Tagged ‘modelo en estrella’

Modelo en Estrella

mayo 5, 2010 2 comentarios

El Modelo en Estrella es un tipo de Modelo Dimensional, y por lo tanto, tiene como elementos una tabla de Hechos y tablas de Dimensiones. Lo que caracteriza al Modelo en Estrella, y lo diferencia de otros modelos dimensionales como el Modelo de Copo-de-Nieve, es cómo se lleva a cabo la relación entre las tablas de Dimensiones, más en concreto, como se construye la relación entre los distintos niveles dentro de una Dimensión. En el Modelo en Estrella, cada dimensión utiliza únicamente una tabla, en el Modelo en Copo-de-Nieve, una dimensión es representada en varias tablas.

La tabla de Hechos es una tabla que contiene dos tipos de campos: por un lado, las Medidas, que no son más que los datos que vamos a analizar. En un datawarehouse (DW) de ventas, pues serían las ventas. En un DW financiero, serían elementos del Balance (Activo a Corto Plazo, Pasivo Circulante, Acreedores, etc.). En nuestro DW para análisis bursátil, serían los conceptos de Precio de Apertura, Precio de Cierre, etc. El otro tipo de campos incluídos en la tabla de Hechos son las claves que apuntan a los registros de las tablas de dimensiones, y que permiten relacionar los datos con los niveles de las dimensiones. Los valores que forman conjunto de claves forma la Clave Primaria de la tabla de Hechos.

Pongamos un ejemplo de Modelo en Estrella. Un DW de ventas de una distribuidora de productos electrónicos. Tendríamos un modelo dimensional en Estrella como éste:

Ejemplo de Esquema en Estrella

Como vemos, tenemos una tabla de Hechos, cuya clave primaria es id_producto, id_tienda, id_tiempo, y tres dimensiones: dim_producto, dim_tienda, dim_tiempo, es decir, para una tienda, un día del año y un producto solo puede haber un valor para las medidas PRECIO y UNIDADES:

Diseño de la Tabla "HECHOS"

Si ejecutamos una instruccion SQL contra esta tabla ” Hechos” de la forma

SELECT * FROM HECHOS;

obtendríamos

Resultado de una query SELECT en la tabla HECHOS

Veamos ahora las tablas de dimensiones. Cada una de las tres dimensiones de nuestro análisis (“Producto”, “Tienda”, “Tiempo”) son representadas en nuestro Modelo en Estrella en una única tabla. Esta es la característica diferencial con respecto a los Modelos en Copo-de-Nieve.

Entrando en detalle, veamos una dimensión, en concreto la dimensión”Producto”:

Diseño de la tabla de "DIM_PRODUCTO"

y si ejecutamos una consulta SQL contra ella

SELECT * FROM DIM_PRODUCTO;

obtendríamos datos como estos (como el SELECT no filtra la tabla, y ésta tiene más registros, solo mostramos un extracto de los mismos):

Resultado de una query SELECT en la tabla "DIM_PRODUCTO"

Como observamos, en esta tabla hay campos que tienen el mismo valor una y otra vez, por ejemplo, el campo fabricante es “BLUSENS” (que es una marca española de Tecnología).

Si nos desplazamos unos registros más hacia abajo en esa tabla, tendríamos en este campo”Fabricante” otros valores como “TOSHIBA”, “PHILIPS”, etc., es decir, todos los fabricantes que están en el católogo de la empresa distribuidora. Lo que llama la atención es que hay valores que se repiten una y otra vez en la tabla (no solo en el campo “Fabricante”, también en los campos “Categoría” y “Subcategoría”).

Esto contradice las reglas de Normalización de Codd. Si nos ponemos en el caso de que una empresa compra a otra (como ha ocurrido con la compra por parte de HP a Palm) tendríamos que modificar esta tabla DIM_PRODUCTO tantas veces como productos de ese fabricante tengamos en la tabla de dimensión “Producto”, de manera que ahora el fabricante de cualquier producto “Palm” sería a partir de ese momento “HP_Palm”. Si tenemos un amplio catálogo de productos de “Palm”, tendríamos que actualizar uno por uno cada registro de la tabla de dimensión “Producto”, de manera que se generarían transacciones para actualizar esos registros de la tabla “Producto”. Esto podría evitarse mediante un proceso de “Normalización de Tablas”: para evitar que cada cambio en un atributo genere transacciones, lo que hacemos es que en la tabla de Producto, en lugar de poner el nombre del Fabricante, utilicemos el ID de otra tabla “Fabricante” (con solo 2 columnas, “ID” y “Nombre_Fabricante”). En la tabla “Fabricante” tendríamos un registro  con valores:

(ID=”25″, Nombre_Fabricante=”Palm”)

y en la tabla “Producto” únicamente almacenemos la ID del registro en la tabla “Fabricante” (es decir ID=”25″), de manera que, si se modifica el nombre del fabricante, y ahora “Palm” se llama “HP_Palm” en la tabla “Fabricante”

(ID=”25″, Nombre_Fabricante=”HP_Palm”)

, solo haya que cambiarlo una vez en la tabla “Fabricante”, porque la ID del registro en la tabla “Producto” no se modifica (sigue siendo ID=”25″).

Con ello, normalizamos la dimensión “Producto” y sus valores estarían incluídos en varias tablas (“Producto”, “Fabricante”). Lo mismo para cada uno de los campos en los que se almacenan valores duplicados una y otra vez.

Ahora, nuestra base de datos está normalizada (tendríamos 2 tablas para la dimensión “Producto”, una tabla “PRODUCTO” y otra tabla “FABRICANTE”), y estaríamos de acuerdo con las Reglas de Codd, pero ya no tendríamos un Modelo en Estrella.Porque el Modelo en Estrella es un modelo “Desnormalizado”, es decir, que no tiene en cuenta las bondades del proceso Normalizador de Codd, ya que éste busca mejorar el rendimiento de una base de datos operacional, donde se utilizan toda una variedad de instrucciones SQL (INSERT, UPDATE, DELETE). Una característica del DW es que es “No-Volátil”, por lo que sus datos no suelen ser actualizados o borrados. Una vez que se inserta una venta en la tabla “Hechos”, no se modifica. De ahí que ya no necesitemos normalizar las tablas: mayoritariamente, el tipo de instrucciones SQL que los usuarios ejecutan contra un DW son del tipo SELECT  porque queremos acceder a la información (los usuarios no modifican los datos, solo los leen en sus informes y análisis). Por eso, no es necesario normalizar las tablas, ya que buscamos mejorar el rendimiento de instrucciones SELECT, y los Gestores de las bases de datos, suelen penalizar los JOIN utilizados para recuperar la información mediante SELECT entre las distintas tablas que forman la dimensión (es decir, en el modelo normalizado, donde la dimensión “Producto” consta de dos tablas, “PRODUCTO” y “FABRICANTE”, si el usuario del DW quiere mostrar el nombre del fabricante, que es más descriptivo que su ID, como en la tabla “PRODUCTO” solo guardamos los ID del fabricante, estamos obligados a introducir un Join entre ambas tablas “PRODUCTO” y “FABRICANTE”, y en el resultado del SELECT obtendremos el valor Fabricante=”Palm”.

Este caso de dimensiones en varias tablas, es el Modelo en Copo-de-Nieve que veremos más adelante.

Por lo tanto, un modelo Dimensional en Estrella, es un modelo en el cuál todas las dimensiones que utilicemos en nuestro análisis están almacenadas en una única tabla.

Seguir

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