TABLA DE HECHOS

Introducción

En las bases de datos, y más concretamente en un data warehouse, una tabla de hechos (o tabla fact) es la tabla central de un esquema dimensional (en estrella o encopo de nieve) y contiene los valores de las medidas de negocio. Cada medida se toma mediante la intersección de las dimensiones que la definen, dichas dimensiones estarán reflejadas en sus correspondientes tablas de dimensiones que rodearán la tabla de hechos y estarán relacionadas con ella.

En la figura de la derecha, la tabla central (Ventas) es la tabla de hechos de un diseño de modelo de datos en estrella, las cinco tablas que la rodean (Producto,Tiempo, Almacén, Promoción y Cliente) son las cinco dimensiones de que consta esta tabla de hechos, en dicha tabla se almacenan, en este caso, las unidadesvendidas y el precio obtenido por dichas ventas, estos son los hechos o medidas de negocio almacenados y que, gracias al diseño multidimensional en estrella, podrán ser analizados de forma exhaustiva, típicamente mediante técnicas OLAP (procesamiento analítico on-line).

[editar]

Las medidas del negocio (hechos)

Las medidas más útiles para incluir en una tabla de hechos son los aditivos, es decir, aquellas medidas que pueden ser sumadas como por ejemplo la cantidad de producto vendido, los costes de producción o el dinero obtenido por las ventas; son medidas numéricas que pueden calcularse con la suma de varias cantidades de la tabla. En consecuencia, por lo general los hechos a almacenar en una tabla de hechos van a ser casi siempre valores numéricos, enteros oreales.

[editar]

Cardinalidad de la tabla de hechos

Las tablas de hechos pueden contener un gran número de filas, a veces cientos de millones de registros cuando contienen uno o más años de la historia de una gran organización, esta cardinalidad estará acotada superiormente por la cardinalidad de las tablas dimensionales, Por ejemplo, si se tiene una tabla de hechos "TH" de tres dimensiones D1, D2 y D3, el número máximo de elementos que tendrá la tabla de hechos TH será:

Card(TH) = Card(D1) x Card(D2) x Card(D3)

Donde 'Card(x)' es la cardinalidad de la tabla 'x'

Naturalmente, estas cardinalidades no son fijas, ya que, por ejemplo, si una de las dimensiones se refiere a los clientes de la empresa, cada vez que se dé de alta un nuevo cliente se estará aumentando la cardinalidad de la tabla de hechos. Una de las dimensiones suele ser el tiempo, éste puede medirse de muy distintas formas (por horas, días, semanas, ...), pero lo cierto es que transcurre continuamente, y para que el sistema funcione se deben añadir registros periódicamente a la tabla de esta dimensión (tabla de tiempos) y esto también produce un aumento de la cardinalidad de la tabla de hechos, ésta es la principal causa de que las tablas de hechos lleguen a tener una cantidad de registros del orden de millones de elementos.

[editar]

Granularidad

Una característica importante que define a una tabla de hechos es el nivel de granularidad de los datos que en ella se almacenan, entendiéndose por 'granularidad' el nivel de detalle de dichos datos, es decir, la granularidad de la tabla de hechos representa el nivel más atómico por el cual se definen los datos. Por ejemplo, no es lo mismo contar el tiempo por horas (grano fino) que por semanas (grano grueso); o en el caso de los productos, se puede considerar cada variante de un mismo artículo como un producto (por ejemplo, en una empresa textil, cada talla y color de pantalón podría ser un producto) o agrupar todos los artículos de una misma familia considerándolos como un único producto (por ejemplo, el producto pantalón genérico).

Como se puede observar, la granularidad afecta a la cardinalidad, tanto de las dimensiones como de la tabla de hechos, a mayor granularidad (grano más fino) mayor será el número de registros final de la tabla de hechos.

Cuando la granularidad es mayor, es frecuente que se desee disponer de subtotales parciales, es decir, si tenemos una tabla de hechos con las ventas por días, podría interesar disponer de los totales semanales o mensuales, estos datos se pueden calcular haciendo sumas parciales, pero es frecuente añadir a la tabla de hechos registros donde se almacenan dichos cálculos para no tener que repetirlos cada vez que se requieran y mejorar así el rendimiento de la aplicación. En este caso se dispondrá en la misma tabla de hechos de datos de grano fino y de grano más grueso aumentando aún más la cardinalidad de la tabla.

[editar]

Agregación

La agregación es un proceso de cálculo por el cual se resumen los datos de los registros de detalle. Esta operación consiste normalmente en el cálculo de totales dando lugar a medidas de grano grueso. Cuando se resumen los datos, el detalle ya no está directamente disponible para el analista, ya que este se elimina de la tabla de hechos.

Esta operación se realiza típicamente con los datos más antiguos de la empresa con la finalidad de seguir disponiendo de dicha información (aunque sea resumida) para poder eliminar registros obsoletos de la tabla de hechos para liberar espacio.

[editar]

Tipos de datos adecuados

Como ya se ha comentado, es normal que las tablas de hechos almacenen muchos millones de registros, por esta razón es muy importante que no se despilfarre memoria, hay que procurar utilizar los tipos de datos adecuados, si una medida a almacenar puede guardarse en un campo de tipo entero, no debemos definir ese campo como de tipo entero largo o como tipo real. Del mismo modo, si una magnitud necesita decimales, si las características de ésta lo permiten, será mejor utilizar un tipo real simple que un tipo real de doble precisión. Nótese que elegir uno u otro de estos campos, en principio sólo supondría una diferencia de unos pocos bytes en un registro, pero dado que en una tabla de hechos estamos hablando de cientos de millones de registros, en realidad, esa diferencia no es despreciable (1 byte x 1000 millones de registros = 1GB de memoria).

TABLA DIMENSIONAL

En un almacén de datos o un sistema OLAP, la construcción de Cubos OLAP requiere de una tabla de hechos y varias tablas de dimensiones, éstas acompañan a la tabla de hechos y determinan los parámetros (dimensiones) de los que dependen los hechos registrados en la tabla de hechos.

[editar]Introducción

En la construcción de cubos OLAP, las tablas de dimensiones son elementos que contienen atributos (o campos) que se utilizan para restringir y agrupar los datos almacenados en una tabla de hechos cuando se realizan consultas sobre dicho datos en un entorno de almacén de datos o data mart.

Estos datos sobre dimensiones son parámetros de los que dependen otros datos que serán objeto de estudio y análisis y que están contenidos en la tabla de hechos. Las tablas de dimensiones ayudan a realizar ese estudio/análisis aportando información sobre los datos de la tabla de hechos, por lo que puede decirse que en un cubo OLAP, la tabla de hechos contiene los datos de interés y las tablas de dimensiones contienen metadatos sobre dichos hechos.

[editar]Granularidad de dimensión y jerarquías

Cada dimensión puede referirse a conceptos como 'tiempo', 'productos', 'clientes', 'zona geográfica', etc. Ahora bien, cada dimensión puede estar medida de diferentes maneras según la granularidad deseada, por ejemplo, para la dimensión "zona geográfica" podríamos considerar 'localidades', 'provincias', 'regiones', 'países' o 'continentes'.

Granularidad de la dimensión Zona geográfica, con una jerarquía de cinco niveles.

Detalle de una tabla de dimensión de un cubo OLAP con un esquema en estrella.

Detalle de una tabla de dimensión de un cubo OLAP con un esquema en copo de nieve.

La unidad de medida (por localidades, provincias, etc.) determinará esa granularidad, cuanto más pequeña sea esta unidad de medida más fina será esta granularidad (grano fino); si las unidades de medida son mayores, entonces hablaremos de granularidad gruesa (grano grueso).

En muchas ocasiones interesa disponer de los datos a varios niveles de granularidad, es decir, es importante para el negocio poder consultar los datos (siguiendo el ejemplo de las zonas) por localidades, provincias, etc., en estos casos se crea una jerarquía con la dimensión, ya que tenemos varios niveles de asociación de los datos (con otras dimensiones como el tiempo, se podrían crear niveles jerárquicos del tipo 'días', 'semanas', 'meses', ...).

Cuando las tablas de dimensión asociadas a una tabla de hechos no reflejan ninguna jerarquía (por ejemplo: Las zonas siempre son 'provincias' y sólo provincias, el tiempo se mide en 'días' y sólo en días, etc.) el cubo resultante tendrá forma de estrella, es decir, una tabla de hechos central rodeada de tantas tablas como dimensiones, y sólo habrá, además de la tabla de hechos, una tabla por cada dimensión.

Cuando una o varias de las dimensiones del cubo refleja algún tipo de jerarquía existen dos planteamientos con respecto a la forma que deben ser diseñadas las tablas de dimensión. El primero consiste en reflejar todos los niveles jerárquicos de una dimensión dentro de una única tabla, en este caso también tendríamos un esquema en estrellacomo el que se ha descrito anteriormente.

El otro planteamiento consiste en aplicar a las dimensiones las reglas de normalización de las bases de datos relacionales. Estas normas están ideadas para evitar redundancias en los datos aumentando el número de tablas, de esta forma se consigue almacenar la información en menos espacio. Este diseño da como resultado en esquema en copo de nieve. Este modo de organizar las dimensiones de un cubo OLAP tiene un inconveniente respecto al modelo en estrella que no compensa el ahorro de espacio de almacenamiento. En las aplicaciones OLAP el recurso crítico, no es tanto el espacio para almacenamiento como el tiempo de respuesta del sistema ante consultas del usuario, y está constatado que los modelos en copo de nieve tienen un tiempo de respuesta mayor que los modelos en estrella.

Ejemplo de Cubo OLAP modelo de datos en estrella de 5 dimensiones.

Ejemplo de Cubo OLAP modelo de datos en copo de nieve de 5 dimensiones.

[editar]La dimensión "tiempo"

En cualquier Dataware house se pueden encontrar varios cubos con sus tablas de hechos repletas de registros sobre alguna variable de interés para el negocio que debe ser estudiada. Como ya se ha comentado, cada tabla de hechos estará rodeada de varias tablas de dimensiones, según que parámetros sirvan mejor para realizar el análisis de los hechos que se quieren estudiar. Un parámetro que casi con toda probabilidad será común a todos los cubos es eltiempo, ya que lo habitual es almacenar los hechos conforme van ocurriendo a lo largo del tiempo, obteniéndose así una serie temporal de la variable a estudiar.

Tabla de tiempos (1) Fecha (PK) datetime Año char(4) Trimestre char(6) Mes char(10)

Tabla de tiempos (2) TiempoID (PK) integer Fecha datetime Año char(4) Trimestre char(6) Mes char(10)

Dado que el tiempo es una dimensión presente en prácticamente cualquier cubo de un sistema OLAP merece una atención especial. Al diseñar la dimensión tiempo (tanto para un esquema en estrellacomo para un esquema en copo de nieve) hay que prestar especial cuidado, ya que puede hacerse de varias maneras y no todas son igualmente eficientes. La forma más común de diseñar esta tabla es poniendo como clave principal (PK) de la tabla la fecha o fecha/hora (tabla de tiempos 1). Este diseño no es de los más recomendables, ya que a la mayoría de los sistemas de gestión de bases de datos les resulta más costoso hacer búsquedas sobre campos de tipo "date" o "datetime", estos costes se reducen si el campo clave es de tipo entero, además, un dato entero siempre ocupa menos espacio que un dato de tipo fecha (el campo clave se repetirá en millones de registros en la tabla de hechos y eso puede ser mucho espacio), por lo que se mejorará el diseño de la tabla de tiempos si se utiliza un campo "TiempoID" de tipo entero como clave principal (tabla de tiempos 2).

A la hora de rellenar la tabla de tiempos, si se ha optado por un campo de tipo entero para la clave, hay dos opciones, la que quizá sea más inmediata consiste en asignar valores numéricos consecutivos (1, 2, 3, 4, ...) para los diferentes valores de fechas. La otra opción consistiría en asignar valores numéricos del tipo "yyyymmdd", es decir que los cuatro primeros dígitos del valor del campo indican el año de la fecha, los dos siguientes el mes y los dos últimos el día. Este segundo modo aporta una cierta ventaja sobre el anterior, ya que de esta forma se consigue que el dato numérico en sí, aporte por si solo la información de a que fecha se refiere, es decir, si en la tabla de hechos encontramos el valor 20040723, sabremos que se refiere al día 23 de julio de 2004; en cambio, con el primer método, podríamos encontrar valores como 8456456, para saber a que fecha se refiere este valor tendríamos que hacer una consulta sobre la tabla de tiempos.

Además del campo clave TiempoID, la tabla de hechos debe contener otros campos que también es importante estudiar. Estos campos serían:

Tabla de tiempos (3) TiempoID (PK) integer Fecha datetime Año char(4) Trimestre char(6) TrimestreID int Mes char(10) MesID int Quincena char(10) QuincenaID int Semana char(10) SemanaID int Día char(10) DíaID int DíaSemana char(10) DíaSemanaID int

• Un campo "año".- Para contener valores como '2002', 2003, '2004', ...

• Un campo "mes".- Aquí se pueden poner los valores 'Enero', 'Febrero', ... (o de forma abreviada: 'Ene', 'Feb', ...), esto no está mal, pero se puede mejorar si el nombre del mes va acompañado con el año al que pertenece, es decir '2004 Enero', '2004 Febrero', ... de esta forma se optimiza la búsqueda de los valores de un mes en concreto, ya que con el primer método, si se buscan los valores pertenecientes al mes de "Enero de 2003", toda esa información está contenida en un sólo campo, el "mes", no haría falta consultar también el campo año.

• Un campo "mesID".- Este campo tendría que ser de tipo entero y serviría para almacenar valores del tipo 200601 (para '2006 Enero') o 200602 (para '2006 Febrero'), de esta forma es posible realizar ordenaciones y agrupaciones por meses.

De forma análoga a como se ha hecho con el campo mes, se podrían añadir más campos como "Época del año", "Trimestre", "Quincena", "Semana" de tipo texto para poder visualizarlos, y sus análogos de tipo entero "Época del año_ID", "TrimestreID", "QuincenaID", "SemanaID" para poder realizar agrupaciones y ordenaciones. En general se puede añadir un campo por cada nivel de granularidad deseado.

Otro campo especial que se puede añadir es el "Día de la semana" ('lunes', 'martes', ...), este campo se suele añadir para poder hacer estudios sobre el comportamiento de los días de la semana en general (no del primer lunes del mes de enero de un año concreto, este tipo de estudio no suele tener interés), por esta razón, este campo no necesita ir acompañado del mes o del año como los campos anteriores. También se puede añadir su campo dual "ID" de tipo entero para poder ordenar y agrupar si fuera necesario.

Con los añadidos descritos podríamos tener una tabla de tiempos como la de la figura "Tabla de tiempos (3)". Esta sería válida para un diseño en estrella, para un diseño en copo de nieve habría que desglosar la tabla de tiempos en tantas tablas como niveles jerárquicos contenga. Obsérvese que los campos de tipo "ID" son todos de tipo entero, ya que será sobre estos campos sobre los que se realizarán la mayoría de las operaciones y estas se realizarán más eficientemente sobre datos enteros.

PROCESO DE NEGOCIO

Un proceso de negocio es un conjunto de tareas relacionadas lógicamente llevadas a cabo para lograr un resultado de negocio definido. Cada proceso de negocio tiene sus entradas, funciones y salidas. Las entradas son requisitos que deben tenerse antes de que una función pueda ser aplicada. Cuando una función es aplicada a las entradas de un método, tendremos ciertas salidas resultantes.

Es una colección de actividades estructurales relacionadas que producen un valor para la organización, sus inversores o sus clientes. Es, por ejemplo, el proceso a través del que una organización ofrece sus servicios a sus clientes.

Un proceso de negocio puede ser parte de un proceso mayor que lo abarque o bien puede incluir otros procesos de negocio que deban ser incluidos en su función. En este contexto un proceso de negocio puede ser visto a varios niveles de granularidad. El enlace entre procesos de negocio y generación de valor lleva a algunos practicantes a ver los procesos de negocio como los flujos de trabajo que efectúan las tareas de una organización. Los procesos poseen las siguientes características:

1. Pueden ser medidos y están orientados al rendimiento
2. Tienen resultados específicos
3. Entregan resultados a clientes o “stakeholders”
4. Responden a alguna acción o evento específico
5. Las actividades deben agregar valor a las entradas del proceso.

Los procesos de negocio pueden ser vistos como un recetario para hacer funcionar un negocio y alcanzar las metas definidas en la estrategia de negocio de la empresa. Las dos formas principales de visualizar una organización, son la vista funcional y la vista de procesos.

[editar]

Definiciones

La norma internacional ISO-9001 define un proceso como “una actividad que utiliza recursos, y que se gestiona con el fin de permitir que los elementos de entrada se transformen en resultados” (ISO, 2000; pp. 6). Oscar Barros hace una importante distinción, al introducir el concepto de valor agregado en la definición de proceso, señalando que “un proceso es un conjunto de tareas lógicamente relacionadas que existen para conseguir un resultado bien definido dentro de un negocio; por lo tanto, toman una entrada y le agregan valor para producir una salida. Los procesos tienen entonces clientes que pueden ser internos o externos, los cuales reciben a la salida, lo que puede ser un producto físico o un servicio. Éstos establecen las condiciones de satisfacción o declaran que el producto o servicio es aceptable o no” (Barros, 1994; pp.56). Thomas Davenport, uno de los pioneros de la reingeniería, señala que un proceso, simplemente, es “un conjunto estructurado, medible de actividades diseñadas para producir un producto especificado, para un cliente o mercado específico. Implica un fuerte énfasis en CÓMO se ejecuta el trabajo dentro de la organización, en contraste con el énfasis en el QUÉ, característico de la focalización en el producto” (Davenport, 1993; pp. 5).

Hammer (1996) por su parte, establece la diferencia sustancial entre un proceso y una tarea, señalando que una tarea corresponde a una actividad conducida por una persona o un grupo de personas, mientras que un proceso de negocio corresponde a un conjunto de actividades que, como un todo, crean valor para el cliente externo. Al hacer esta comparación, Hammer hace la analogía con la diferencia que existe entre las partes y el todo. Por su parte, Ould (1995) lista una serie de características que deben cumplir los procesos de negocio y que refuerzan la posición de Hammer; según este autor, un proceso de negocio contiene actividades con propósito, es ejecutado colaborativamente por un grupo de trabajadores de distintas especialidades, con frecuencia cruza las fronteras de un área funcional, e invariablemente es detonado por agentes externos o clientes de dicho proceso.

[editar]

Tipos

Hay tres tipos de procesos de negocio:

1. Procesos estratégicos - Estos procesos dan orientación al negocio. Por ejemplo, "Planeacion estrategica", "Establecer objetivos y metas".
2. Procesos sustantivos– Estos procesos dan el valor al cliente, son la parte principal del negocio. Por ejemplo, “Repartir mercancías”
3. 'Procesos de apoyo vertical u horizontal – Estos procesos dan soporte a los procesos centrales. Por ejemplo, “Registrar los hechos económicos”, “Dar Soporte/Servicio técnico”.

Acorde a la filosofía planteada en el libro Sistema Empresa inteligente los procesos se dividen en: Procesos sustantivos, procesos de apoyo vertical y procesos de apoyo horizontal

Los procesos de negocio consisten en subprocesos, decisiones y actividades.

Un subproceso es parte de un proceso de mayor nivel que tiene su propia meta, propietario, entradas y salidas.

Las actividades son partes de los procesos de negocio que no incluyen ninguna toma de decisión ni vale la pena descomponer (aunque ello sea posible). Por ejemplo, “Responde al teléfono”, “Haz una factura”

Un proceso de negocio es usualmente el resultado de una Reingeniería de Procesos. El modelado de procesos es usado para capturar, documentar y rediseñar procesos de negocio.

Vamos a decir que en la época de Taylor un operario realizaba una tarea específica, y luego se cambió esa perspectiva en torno a los procesos que son realizados por un trabajo en equipo teniendo en cuenta al cliente el cual fija los ritmos de los resultados.

Esto facilita el acercamiento y el acuerdo con los clientes, mejora la motivación de los empleados y existe una mayor facilidad para responder a cambios en el contexto.

Para aplicar los procesos se deben tener claras las tareas, una estructura jerárquica y una tendencia a la interacción y comunicación vertical.

1. Visión funcional: descansa en el organigrama de la empresa como modelo fundamental del negocio; las actividades que debe ejecutar la organización, para cumplir con su misión, se estructuran en conjuntos de funciones relativamente homogéneas (por ejemplo, todas las actividades que tienen que ver con las finanzas de la organización, se unen bajo un mismo ‘techo’). Y así, los recursos pertenecen a los departamentos y la especialización funcional y el expertizaje, son las principales consideraciones a la hora de formar los departamentos, los cuales se relacionan a través de una jerarquía de estructuras de autoridad.

2. Visión de procesos: se orienta al trabajo mismo que se debe desarrollar en la organización, para que el negocio funcione y entregue un producto o servicio, por el cual un cliente externo está dispuesto a pagar. La vista de procesos es una manera tan poderosa de visualizar y analizar un negocio, porque provee de la lógica con la cual los clientes lo miran; los clientes interactúan con la empresa, a través de los procesos del negocio, contratando un servicio, recibiendo dicho servicio, pagándolo y recibiendo atención de post venta. Cuando se entiende el negocio desde esta perspectiva, es posible evaluar.

Lo que realmente ocurre cuando se mira la firma como un conjunto lógico e integrado de procesos, es que resulta posible percatarse que los procesos reales, cruzan las estructuras organizacionales de manera longitudinal; por ejemplo, si consideramos el proceso ‘diseñar nuevos productos’, éste pasa por el área funcional de Marketing (que identifica los requerimientos del mercado), Investigación y Desarrollo (que diseña el producto de acuerdo a las especificaciones entregadas por Marketing), Ingeniería (que diseña los componentes), Operaciones (que evalúa la factibilidad de fabricar el producto, con las instalaciones existentes) y Finanzas (que evalúa la factibilidad económica y financiera de llevar a cabo el proyecto). Sin embargo, en el enfoque funcional, el proceso se hace invisible y por lo tanto, nadie se responsabiliza por su desempeño de manera integral y cada unidad funcional que tiene la responsabilidad de una parte solamente de este proceso, intenta optimizarlo, suboptimizando el proceso propiamente tal. Cuando una organización cambia de un enfoque basado en funciones a una lógica de procesos, lo que hace es pasar de enfatizar el quién hace qué, al qué se debe hacer para lograr cierto resultado.

MODELO DIMENSIONAL

El modelado dimensional es una forma de acercar los datos a la manera en que estos serán convertidos en información útil para los usuarios del negocio. El objetivo final es que estos puedan encontrar de manera intuitiva y rápida la información que necesitan.
La aplicación del modelo dimensional tiene lugar en la fase de diseño lógico, lo que permite la traducción del esquema resultante del diseño conceptual al plano lógico. El modelo dimensional se describe en el año 1996 por Ralph Kimball, como propuesta para el diseño de almacenes de datos (Data Warehouses), partiendo de la visión multidimensional que los usuarios tienen de los datos empresariales cuando se enfrentan a ellos con propósito de análisis (de análisis multidimensional –OLAP– en concreto).
El análisis multidimensional consiste en analizar los datos que hacen referencia a hechos, sean económicos o de otros tipos, desde la perspectiva de sus componentes o dimensiones (utilizando para ello algún tipo de métrica o medida de negocio).
Este modelo tiene en cuenta que para el análisis multidimensional los datos se representan como si estuvieran en un espacio n-dimensional (cubo de datos), permitiendo su estudio en términos de hechos sujetos al análisis (facts, en inglés) y dimensiones que permiten diferentes puntos de vista por los que analizar esos hechos.
La analogía del cubo (recuerde el cubo de Rubik) con la visión multidimensional es válida para comprender el concepto desde un punto de vista gráfico, pero sólo es válido para un modelo de tres dimensiones. Un modelo de más de tres dimensiones suele denominarse hipercubo, y ya resulta más difícil su representación gráfica.

El modelo dimensional distingue tres elementos básicos:

• Hechos: es la representación en el data warehouse de los procesos de negocio de la organización. Por ejemplo: una venta puede identificarse como un proceso de negocio. Los hechos se podrán reconocer además porque siempre tienen asociada una fecha, y una vez registrados no se modifican ni se eliminan (para no perder la historia).
• Métrica: son los indicadores de negocio de un proceso de negocio. Aquellos conceptos cuantificables que permiten medir nuestro proceso de negocio. Por ejemplo, en una venta tenemos el importe de la misma y la cantidad vendida. Existen métricas derivadas, como el precio unitario, que se obtiene al dividir el importe total por las unidades vendidas.
• Dimensión: es la representación en el data warehouse de un punto de vista para los hechos de cierto proceso de negocio. Si regresamos al ejemplo de una venta, para la misma tenemos el cliente que ha comprado, la fecha en la que se ha realizado, el producto vendido,… Estos conceptos pueden ser considerados como vistas para este proceso de negocio. Puede ser interesante recuperar todas las compras realizadas por un cliente, o para un producto o familia de productos, o para un lapso determinado.

Pero ¿qué hay de su representación? Igual que sucede en el modelo relacional, el modelo dimensional adopta el concepto de relación (tabla) como estructura básica del modelo. Pero a diferencia del modelo relacional, que no hace distinción entre relaciones, el modelo dimensional distingue entre relaciones de hecho (tablas de hecho) y relaciones de dimensión (tablas de dimensión).
Los conceptos básicos – hechos, métricas y dimensiones (facts, measures y dimensions) – se representan en el modelo como relaciones (tablas) dentro de un esquema dimensional. Según las técnicas de modelado utilizadas, ese esquema dimensional puede adoptar forma de estrella o de copo de nieve.
El siguiente, es un ejemplo de esquema en estrella para el caso de las ventas diarias en un conjunto de tiendas:

Vemos que existe una tabla de hechos en el centro (h_ventas_diarias), y una tabla de dimensión para cada dimensión de análisis que participa de la descripción de ese hecho (dim_xxx).
Las columnas de la tabla de hechos incluyen las dimensiones que identifican el hecho, y los hechos o medidas del negocio. Las columnas en las tablas de dimensión incluyen atributos asociados a cada posible valor de la dimensión.
Los atributos de una dimensión permitirán agrupar los hechos jerárquicamente, para poder consolidar y desagregar las mediciones según se desee. Como ejemplos tenemos:

• Para la dimensión fecha: año, mes, día, nombre del mes, día de la semana, trimestre, …
• Para la dimensión producto: tipo de producto, familia, unidad de medida, …

Cuando a una dimensión no se le pueden asociar múltiples atributos, se dice que tenemos una dimensión degenerada, y solo aparecerá como una columna en la tabla de hechos. Por ejemplo, si tuviéramos en nuestro ejemplo una dimensión “Estado de la Venta”, con los posibles valores: “Confirmada”, “Pendiente”, “Cancelada”; en este caso la dimensión serviría solo para separar las ventas según su estado, y no se requieren atributos adicionales.
Eventualmente, pudiera surgir un esquema en estrella integrado solo por una tabla de hechos con dimensiones degeneradas.
Por otro lado, cuando se decide normalizar las tablas de dimensiones para eliminar campos redundantes, tenemos lo que se conoce como esquema en copo de nieve.

El Copo de Nieve es una generalización de la Estrella, por lo que no es necesario tratar de diferenciar uno de otro.
La decisión de normalizar, o no, una tabla de dimensión corresponde a los diseñadores, quienes deberán tener presente que el objetivo es dar respuesta rápida a las consultas de los usuarios, no ahorrar espacio. Generalmente, el espacio que se logra ahorrar al normalizar la dimensión, es insignificante comparado con el volumen de la tabla de hechos, mientras el impacto en los tiempos de respuesta es apreciable.

[editar]