Esquema en estrella

De Wikipedia, la enciclopedia libre
Saltar a: navegación, búsqueda
Ejemplo de modelo de datos 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 a la transaccion 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]

La tabla de hechos registra medidas o metricas de un Evento específico. (definicion 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, numero: 42, color: gris y negro, el dia: 25 de mayo de 2010 a la hora: 19:48 Hs en la Sucursal: Acoite 1200, Caballito, Capital Federal Argentina, el Vendedor fue: Romulo Perez. Esto es un evento, o sea un suceso (una venta) que se da en un punto determinado del tiempo.

La tablas de hechos generalmente consisten de valores numericos (datos asociados específicamente con el evento), y claves foráneas que referencian a tablas de datos dimensionales que guardan informacion descriptiva. (en el ejemplo de la transaccion 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 direccion de la sucursal donde tuvo lugar el evento, en su lugar, se poner un identificador de sucursal y ese identificador es una clave foranera, 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 foranea de la tabla de hechos. Adicionalmente, en caso de que la sucursal se mude, solo sera necesario hacer un solo cambio en la base de datos -en la tabla de dimensiones, donde figura la direccion de la sucursal que se muda- y no hay que hacerlo en la tabla de hechos, en cada transaccion que se efectuó en esa sucursal)

Las tablas de hechos se designan 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 medicion sobre la entidad objeto de observacion- (por ejemplo, Detalles de una cuenta al final del mes)
  • Tablas Snapshot Acumulativas registran hechos agragados -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]

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

  • Tablas de tiempo, describen el tiempo al mas pequeño nivel de granularidad de tiempo para el cual los eventos se registran en el esquema estrella.
  • Tablas de dimension Geograficas describen datos de localizacion, tales como pais, region, provincia, estado, o ciudad.
  • Tablas de dimension de Productos describen los productos
  • Tablas de dimensions de Empleados describen los empleados, por ejemplo, los vendedores
  • Tablas de dimensión de Rangos, describen rangos de tiempo, valores de dolar, 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 combinacion 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 sólo 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 y 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

Referencias[editar]

Véase también[editar]

Enlaces externos[editar]