Modelado dimensional

El modelado dimensional (DM) es parte de la metodología del ciclo de vida dimensional empresarial desarrollada por Ralph Kimball, que incluye un conjunto de métodos, técnicas y conceptos para su uso en el diseño de almacenes de datos. El enfoque se centra en la identificación de los procesos empresariales clave dentro de una empresa y en el modelado e implementación de estos primero antes de agregar procesos empresariales adicionales, como un enfoque ascendente. Un enfoque alternativo de Inmon aboga por un diseño descendente del modelo de todos los datos de la empresa utilizando herramientas como el modelado de entidad-relación (ER).

El modelado dimensional siempre utiliza los conceptos de hechos (medidas) y dimensiones (contexto). Los hechos son típicamente (pero no siempre) valores numéricos que se pueden agregar, y las dimensiones son grupos de jerarquías y descriptores que definen los hechos. Por ejemplo, el monto de ventas es un hecho; la marca de tiempo, el producto, el número de registro, el número de tienda, etc. son elementos de las dimensiones. Los modelos dimensionales se construyen por área de proceso de negocios, por ejemplo, ventas en tiendas, inventario, reclamos, etc. Debido a que las diferentes áreas de proceso de negocios comparten algunas dimensiones, pero no todas, la eficiencia en el diseño, la operación y la consistencia se logra utilizando dimensiones conformadas, es decir, utilizando una copia de la dimensión compartida en todas las áreas temáticas.

El modelado dimensional no implica necesariamente una base de datos relacional. El mismo enfoque de modelado, a nivel lógico, se puede utilizar para cualquier formato físico, como una base de datos multidimensional o incluso archivos planos. Está orientado a la comprensión y el rendimiento.

El modelo dimensional se basa en un esquema de estrella o un esquema de copo de nieve, con dimensiones que rodean la mesa de hechos. Para construir el esquema, se utiliza el siguiente modelo de diseño:

1. Elija el proceso de negocio
2. Declarar el grano
3. Identificar las dimensiones
4. Identificar el hecho

Elija el proceso de negocio

El proceso de modelado dimensional se basa en un método de diseño de cuatro pasos que ayuda a garantizar la usabilidad del modelo dimensional y el uso del almacén de datos. Los conceptos básicos del diseño se basan en el proceso empresarial real que el almacén de datos debe cubrir. Por lo tanto, el primer paso del modelo es describir el proceso empresarial en el que se basa el modelo. Esto podría ser, por ejemplo, una situación de ventas en una tienda minorista. Para describir el proceso empresarial, se puede optar por hacerlo en texto simple o utilizar el Modelo y notación de procesos empresariales (BPMN) básico u otras guías de diseño como el Lenguaje de modelado unificado (UML).

Declarar el grano

Después de describir el proceso de negocio, el siguiente paso en el diseño es declarar el grano del modelo. El grano del modelo es la descripción exacta de lo que el modelo dimensional debe enfocar. Esto podría ser, por ejemplo, "Un artículo de línea individual en un recibo de cliente de una tienda minorista". Para aclarar lo que significa el grano, debe elegir el proceso central y describirlo con una oración. Además, el grano (oración) es a partir de lo que va a construir sus dimensiones y tabla de hechos. Es posible que considere necesario volver a este paso para modificar el grano debido a la nueva información obtenida sobre lo que se supone que su modelo puede ofrecer.

Identificar las dimensiones

El tercer paso en el proceso de diseño es definir las dimensiones del modelo. Las dimensiones deben definirse dentro del grano desde el segundo paso del proceso de 4 pasos. Las dimensiones son la base de la tabla de hechos, y es donde se recopilan los datos para la tabla de datos. Por lo general, las dimensiones son sustantivos como la fecha, la tienda, el inventario, etc. Estas dimensiones son donde se almacenan todos los datos. Por ejemplo, la dimensión de fecha podría contener datos como año, mes y lunes a viernes.

Identificar los hechos

Después de definir las dimensiones, el siguiente paso del proceso es crear claves para la tabla de hechos. Este paso consiste en identificar los hechos numéricos que llenarán cada fila de la tabla de hechos. Este paso está estrechamente relacionado con los usuarios comerciales del sistema, ya que aquí es donde obtienen acceso a los datos almacenados en el almacén de datos. Por lo tanto, la mayoría de las filas de la tabla de hechos son cifras numéricas, aditivas, como la cantidad o el costo por unidad, etc.

La normalización dimensional o el efecto de copos de nieve elimina los atributos redundantes, que se conocen en las dimensiones normales y desnormalizadas. Las dimensiones se unen estrictamente en subdimensiones.

El efecto de los copos de nieve tiene una influencia en la estructura de datos que difiere de muchas filosofías de los almacenes de datos. Una única tabla de datos (hechos) rodeada de varias tablas descriptivas (dimensiones)

Los desarrolladores a menudo no normalizan las dimensiones debido a varias razones:

1. La normalización hace que la estructura de datos sea más compleja
2. El rendimiento puede ser más lento, debido a que muchos se unen entre tablas
3. Los ahorros espaciales son mínimos
4. Los índices de mapas de bits no se pueden utilizar
5. Query performance. Las bases de datos 3NF sufren problemas de rendimiento cuando se agregan o recuperan muchos valores dimensionales que pueden requerir análisis. Si usted sólo va a hacer informes operativos entonces usted puede ser capaz de conseguir con 3NF porque su usuario operativo estará buscando datos de grano muy fino.

Existen algunos argumentos que demuestran por qué la normalización puede ser útil. Puede ser una ventaja cuando una parte de la jerarquía es común a más de una dimensión. Por ejemplo, una dimensión geográfica puede ser reutilizable porque tanto la dimensión del cliente como la del proveedor la utilizan.

Los beneficios del modelo dimensional son los siguientes:

• Comprensión. Comparado con el modelo normalizado, el modelo dimensional es más fácil de entender y más intuitivo. En modelos dimensionales, la información se agrupa en categorías o dimensiones empresariales coherentes, facilitando la lectura e interpretación. La simplicidad también permite que el software navegar bases de datos de manera eficiente. En modelos normalizados, los datos se dividen en muchas entidades discretas e incluso un simple proceso de negocio podría dar lugar a decenas de tablas unidas de manera compleja.
• Query performance. Los modelos dimensionales son más denormalizados y optimizados para la búsqueda de datos, mientras que los modelos normalizados buscan eliminar redundancias de datos y están optimizados para la carga y actualización de transacciones. El marco predecible de un modelo dimensional permite a la base de datos hacer fuertes suposiciones sobre los datos que pueden tener un impacto positivo en el rendimiento. Cada dimensión es un punto de entrada equivalente en la tabla de hechos, y esta estructura simétrica permite un manejo eficaz de consultas complejas. Optimización de consultas para bases de datos basadas en estrellas es simple, predecible y controlable.
• Extensibilidad. Los modelos dimensionales son escalables y pueden acomodar fácilmente nuevos datos inesperados. Las tablas existentes se pueden cambiar en su lugar ya sea simplemente añadiendo nuevas filas de datos en la tabla o ejecutando comandos de tabla de alteración SQL. No es necesario reprogramar consultas ni aplicaciones que se encuentren en la parte superior del almacén de datos para adaptarse a los cambios. Las viejas consultas y aplicaciones siguen funcionando sin dar resultados diferentes. Pero en modelos normalizados cada modificación debe ser considerada cuidadosamente, debido a las complejas dependencias entre tablas de bases de datos.

Todavía obtenemos los beneficios de los modelos dimensionales en Hadoop y marcos de big data similares. Sin embargo, algunas características de Hadoop requieren que adaptemos ligeramente el enfoque estándar para el modelado dimensional.

• El sistema de archivos Hadoop es inmutable. Sólo podemos añadir pero no actualizar datos. Como resultado, sólo podemos anexar registros a tablas de dimensiones. Cambiando lentamente Dimensiones en Hadoop se convierten en el comportamiento predeterminado. Para obtener el registro más reciente y actualizado en una tabla de dimensiones tenemos tres opciones. Primero, podemos crear una vista que recupera el último registro usando funciones de ventana. Segundo, podemos tener un servicio de compactación funcionando en el fondo que recrea el último estado. Tercero, podemos almacenar nuestras tablas de dimensión en almacenamiento mutable, por ejemplo. HBase y consultas federadas a través de los dos tipos de almacenamiento.
• La forma en que los datos se distribuyen en HDFS hace que sea caro unir datos. En una base de datos relacional distribuida (MPP) podemos colocar registros con las mismas claves primarias y extranjeras en el mismo nodo en un grupo. Esto hace que sea relativamente barato unirse a mesas muy grandes. No es necesario viajar a través de la red para realizar la unión. Esto es muy diferente en Hadoop y HDFS. En tablas HDFS se dividen en grandes pedazos y se distribuyen a través de los nodos en nuestro clúster. No tenemos ningún control sobre cómo los registros individuales y sus llaves se extienden a través del clúster. Como resultado se une a Hadoop para dos tablas muy grandes son bastante caros ya que los datos tienen que viajar a través de la red. Debemos evitar las uniones cuando sea posible. Para una gran tabla de hecho y dimensión podemos desnormalizar la tabla de dimensión directamente en la tabla de hechos. Para dos tablas de transacciones muy grandes podemos anidar los registros de la tabla infantil dentro de la tabla de padres y aplanar los datos en el momento de ejecución.

• Kimball, Ralph; Margy Ross (2013). The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3a edición). Wiley. ISBN 978-118-53080-1.
• Ralph Kimball (1997). "Un Manifiesto de Modelado Dimensional". DBMS and Internet Systems. 10 (9).
• Margy Ross (Kimball Group) (2005). "Identificar procesos empresariales". Kimball Group, Consejos de diseño (69). Archivado desde el original el 12 de junio de 2013.