Modelo Estrella 673s2j

Modelo Estrella

En el diseño de un data warehouse hay que partir de una serie de características:  istra

grandes cantidades de información

 Guarda

histórico de datos

 Condesa  Integra

y agrega información

y asocia información de varias fuentes



Para ello, hay que cambiar de los modelos E/R usuales en los operacionales, ya que de tipo de modelo de dato es complejo obtener datos acumulados e históricos. Usualmente se realizan una serie de procesos ETL, para obtener un modelo multidimensional y así poder realizar consultas analíticas de manera más optima.



Normalmente las consultas de análisis, se realizan sobre un hecho esencial a partir de una serie de parámetros. Un ejemplo serían las ventas con una serie de variables como tiempo, localización y producto.



Número de ventas en un periodo determinado



Evolución de las ventas



Previsiones de venta



Productos más vendidos en una zona determinada



Este tipo de modelo de datos principalmente de dos tipos de elementos:

consta



DIMENSIONES: Representan factores por lo que se analiza un determinado área del negocio. Son pequeñas y usualmente están no normalizadas.



HECHOS: Son el objeto de los análisis y están relacionados con las dimensiones. Son tablas muy grandes y suelen estar no normalizadas. Se a menudo incluyen diferentes agregaciones como máximo, mínimo, media, …

MODELO ESTRELLA

 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.

TABLA DE HECHOS 

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:



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:



y si ejecutamos una consulta SQL contra ella:



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):



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).



Tendría que hacerse una normalización de las tablas mediante la reglas de Codd.



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 “No normalizado”, 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 s ejecutan contra un DW son del tipo SELECT  porque queremos acceder a la información (los s 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 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 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 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.