Esquema en estrella

En las bases de datos usadas para data warehousing, un esquema en estrella es un modelo de datos que tiene una tabla de hechos (o tabla fact) que contiene los datos para el análisis, rodeada de las tablas de dimensiones. Este aspecto, de tabla de hechos (o central) más grande rodeada de radios o tablas más pequeñas es lo que asemeja a una estrella, dándole nombre a este tipo de construcciones.

Las tablas de dimensiones tendrán siempre una clave primaria simple, mientras que en la tabla de hechos, la clave principal estará compuesta por las claves principales de las tablas dimensionales.

Modelo editar

El esquema estrella separa los datos del proceso de negocios en: hechos y dimensiones. Los hechos contienen datos medibles, cuantitativos, relacionados con la transacción del negocio, y las dimensiones son atributos que describen los datos indicados en los hechos (una especie de meta-datos, o sea datos que describen otros datos).

Tabla de Hechos editar

Artículo principal: Tabla de hechos

La tabla de hechos registra medidas o métricas de un evento específico. (definición de evento: suceso que se da en un punto determinado del tiempo). Por ejemplo un evento puede ser: Un cliente compra: 5 pares de zapatillas marca: Nike, modelo: Pegasus II, número: 28, color: gris y negro, el día: 25 de mayo de 2010 a la hora: 19:48 h en la Sucursal: Acoite 1200, Caballito, Capital México, el Vendedor fue: Romulo Pérez. Esto es un evento, o sea un suceso (una venta) que se da en un punto determinado del tiempo.

Las tablas de hechos generalmente consisten de valores numéricos (datos asociados específicamente con el evento), y claves foráneas que referencian a tablas de datos dimensionales que guardan información descriptiva. (en el ejemplo de la transacción de venta de zapatillas, hay datos que, por ser repetitivos, es necesario proyectar la tabla y hacer una tabla aparte -tabla de dimensiones- que mantengan estos datos, pues es redundante poner en cada evento, los datos completos de la dirección de la sucursal donde tuvo lugar el evento, en su lugar, se pone un identificador de sucursal y ese identificador es una clave foránea, que hace referencia a una tabla de dimensiones, donde se guardan los datos de todas las sucursales, cada una con una clave primaria, a la cual hace referencia la clave foránea de la tabla de hechos. Adicionalmente, en caso de que la sucursal se mude, solo será necesario hacer un solo cambio en la base de datos -en la tabla de dimensiones, donde figura la dirección de la sucursal que se muda- y no hay que hacerlo en la tabla de hechos, en cada transacción que se efectuó en esa sucursal)

Las tablas de hechos se diseñan para contener detalles uniformes a bajo nivel (referidos como "granularidad" o "grano"), o sea que los hechos pueden registrar eventos a un gran nivel de atomicidad. Esto puede resultar en la acumulación de un gran número de registros en la tabla de hechos, a lo largo del tiempo. Tablas de hechos se definen como una de los siguientes tres tipos:

Tablas de hechos transaccionales registran hechos relativos a eventos específicos (por ejemplo, el evento de una venta)
Tablas de hechos Snapshot registran hechos en un punto dado en el tiempo -con un intervalo específico para realizar la medición sobre la entidad objeto de observación- (por ejemplo, Detalles de una cuenta al final del mes)
Tablas Snapshot Acumulativas registran hechos agregados -acumulados- a un punto dado en el tiempo (por ejemplo, ventas totales mensuales para un producto dado)

Las tablas de hechos generalmente tienen asignada una surrogate key para asegurar que cada fila puede ser identificada de forma unívoca.

Ejemplos de datos hechos incluyen: precio de venta, cantidad vendida, fecha y hora de venta, distancia, velocidad, y medidas de peso. Ejemplos de atributos dimensionales relacionados incluyen: modelo de producto, color del producto, tamaño del producto, localización geográfica y nombre del vendedor que realizó la venta.

Tabla de dimensiones editar

Artículo principal: Tabla de dimensión

Las tablas de dimensiones generalmente tienen un bajo número de registros, en comparación a las tablas de hechos, pero cada registro puede tener un gran número de atributos para describir los datos del hecho. Las Dimensiones pueden definir una amplia variedad de características, algunos de los atributos más comunes definidos en las tablas de dimensiones incluyen:

Tablas de tiempo, describen el tiempo al más pequeño nivel de granularidad de tiempo para el cual los eventos se registran en el esquema estrella.
Tablas de dimensión Geográficas describen datos de localización, tales como país, región, provincia, estado, o ciudad.
Tablas de dimensión de Productos describen los productos
Tablas de dimensiones de Empleados describen los empleados, por ejemplo, los vendedores
Tablas de dimensión de Rangos, describen rangos de tiempo, valores de dólar, u otras cantidades medibles para simplificar los reportes.

La tablas de Dimensiones generalmente tienen asignada una surrogate primary key, usualmente una columna simple de tipo de dato entero, que mapea a la combinación de atributos de dimensiones que forman la clave natural.

Razones a favor del esquema en estrella editar

Este esquema es ideal por su simplicidad y velocidad para ser usado en análisis multidimensionales (OLAP, Datamarts, EIS, ...). Permite acceder tanto a datos agregados como de detalle.

El diseño de esquemas en estrella permite implementar la funcionalidad de una base de datos multidimensional utilizando una clásica base de datos relacional (más extendidas que las multidimensionales).

Otra razón para utilizar los esquemas en estrella es su simplicidad desde el punto de vista del usuario final. Las consultas no son complicadas, ya que las condiciones y las uniones (JOIN) necesarias solo involucran a la tabla de hechos y a las de dimensiones, no haciendo falta que se encadenen uniones y condiciones a dos o más niveles como ocurriría en un esquema en copo de nieve. En la mayoría de los casos son preferibles los de estrellas por su simplicidad respecto a los de copo de nieve por ser más fáciles de manejar.

Finalmente, es la opción con mejor rendimiento y velocidad pues permite indexar las dimensiones de forma individualizada sin que repercuta en el rendimiento de la base de datos en su conjunto.

Ejemplo editar

Considerar una base de datos de 'ventas' (de una cadena de grandes almacenes) clasificados por fecha, almacén y producto.

TH_ventas es la tabla de hechos, y tiene tres dimensiones, representadas por la tablas D_fecha, D_almacen, y D_producto.

Cada tabla de dimensión tiene una clave primaria denominada id. En la tabla de hechos TH_ventas los campos clave de las tablas de dimensión aparecerán como clave ajena (id_fecha, id_almacen e id_producto) y todos juntos formarán la clave principal de dicha tabla.

Otras columnas de datos incluidas en las tablas descritas serían:

TH_ventas.unidades_vendidas
D_fecha.año
D_almacen.país
D_producto.categoría
D_producto.marca

La siguiente instrucción SQL obtendría cómo han sido vendidos algunos conjuntos de televisores, para cada marca y país, en el año 2006.

SELECT
  P.marca, A.pais, SUM(TH.unidades_vendidas)
FROM
  TH_ventas TH
  INNER JOIN D_fecha F ON F.id = TH.id_fecha
  INNER JOIN D_almacen A ON A.id = TH.id_almacen
  INNER JOIN D_producto P ON P.id = TH.id_producto
WHERE
  F.anyo = 2006 
  AND 
  P.categoria = 'tv'
GROUP BY
  P.marca, A.pais

Este ejemplo ilustra cómo se realizaría un análisis de datos a partir del esquema diseñado

Véase también editar

Referencias editar

Darmawikarta, Djoni (2007); Dimensional Data Warehousing with MySQL, Pub. BrainySoftware. ISBN 0-9752128-2-6.

Datos: Q1331138