Modelado dimensional

Concepto de modelado de datos

El modelado dimensional ( DM ) es parte de la metodología Business Dimensional Lifecycle 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 . ^{[1] : 1258–1260  [2]} El enfoque se centra en identificar los procesos comerciales clave dentro de una empresa y modelarlos e implementarlos primero antes de agregar procesos comerciales adicionales, como un enfoque de abajo hacia arriba . ^{[1] : 1258–1260} Un enfoque alternativo de Inmon aboga por un diseño de arriba hacia abajo del modelo de todos los datos de la empresa utilizando herramientas como el modelado de entidad-relación (ER). ^{[1] : 1258–1260}

Descripción

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 pueden agregarse, 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. ^{[ cita requerida ]}

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 forma física, como una base de datos multidimensional o incluso archivos planos. Está orientado a la comprensión y el rendimiento. ^{[ cita requerida ]}

Método de diseño

Diseño del modelo

El modelo dimensional se construye sobre un esquema en forma de estrella o de copo de nieve , con dimensiones que rodean la tabla de hechos. ^{[3] [4]} 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 4 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 debe cubrir el almacén de datos . 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 en qué debe centrarse el modelo dimensional. 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 le resulte 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 del proceso de diseño es definir las dimensiones del modelo. Las dimensiones deben definirse dentro del grano del segundo paso del proceso de 4 pasos. Las dimensiones son la base de la tabla de hechos y es donde se recopilan los datos de la tabla de hechos. Por lo general, las dimensiones son sustantivos como fecha, tienda, 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 día de la semana.

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 cantidad o costo por unidad, etc.

Normalización de dimensiones

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 copos de nieve tiene una influencia en la estructura de datos que difiere de muchas filosofías de almacenes de datos. ^[4] Tabla de datos única (hechos) rodeada de múltiples tablas descriptivas (dimensiones)

Los desarrolladores a menudo no normalizan las dimensiones debido a varias razones: ^[5]

1. La normalización hace que la estructura de datos sea más compleja
2. El rendimiento puede ser más lento debido a las numerosas uniones entre tablas.
3. El ahorro de espacio es mínimo.
4. No se pueden utilizar índices de mapa de bits
5. Rendimiento de las consultas. Las bases de datos 3NF sufren problemas de rendimiento al agregar o recuperar muchos valores dimensionales que pueden requerir análisis. Si solo va a realizar informes operativos, es posible que pueda arreglárselas con 3NF porque su usuario operativo buscará datos de granularidad muy fina.

Existen algunos argumentos que demuestran la utilidad de la normalización. ^[4] 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.

Beneficios del modelado dimensional

Los beneficios del modelo dimensional son los siguientes: ^[6]

• Comprensibilidad. En comparación con el modelo normalizado, el modelo dimensional es más fácil de entender y más intuitivo. En los modelos dimensionales, la información se agrupa en categorías empresariales o dimensiones coherentes, lo que facilita su lectura e interpretación. La simplicidad también permite que el software navegue por las bases de datos de manera eficiente. En los modelos normalizados, los datos se dividen en muchas entidades discretas e incluso un proceso empresarial simple puede dar como resultado docenas de tablas unidas de manera compleja.
• Rendimiento de las consultas. Los modelos dimensionales están más desnormalizados y optimizados para la consulta de datos, mientras que los modelos normalizados buscan eliminar las redundancias de datos y están optimizados para la carga y actualización de transacciones. El marco predecible de un modelo dimensional permite que la base de datos realice suposiciones sólidas sobre los datos que pueden tener un impacto positivo en el rendimiento. Cada dimensión es un punto de entrada equivalente a la tabla de hechos, y esta estructura simétrica permite un manejo eficaz de consultas complejas. La optimización de consultas para bases de datos unidas en estrella es simple, predecible y controlable.
• Extensibilidad. Los modelos dimensionales son escalables y se adaptan fácilmente a nuevos datos inesperados. Las tablas existentes se pueden cambiar en el lugar, ya sea simplemente agregando nuevas filas de datos a la tabla o ejecutando comandos SQL alter table. No es necesario reprogramar las consultas o aplicaciones que se encuentran sobre el almacén de datos para adaptarse a los cambios. Las consultas y aplicaciones antiguas continúan ejecutándose sin producir resultados diferentes. Pero en los modelos normalizados, cada modificación debe considerarse con cuidado, debido a las complejas dependencias entre las tablas de la base de datos.

Modelos dimensionales, Hadoop y big data

Aún obtenemos los beneficios de los modelos dimensionales en Hadoop y otros marcos de trabajo de big data similares . Sin embargo, algunas características de Hadoop requieren que adaptemos ligeramente el enfoque estándar para el modelado dimensional. ^{[ cita requerida ]}

• El sistema de archivos Hadoop es inmutable . Solo podemos agregar datos, pero no actualizarlos. Como resultado, solo podemos agregar registros a las tablas de dimensiones. Las dimensiones que cambian lentamente 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 recupere el último registro mediante funciones de ventanas . Segundo, podemos tener un servicio de compactación ejecutándose en segundo plano que recrea el último estado. Tercero, podemos almacenar nuestras tablas de dimensiones en un almacenamiento mutable, por ejemplo, HBase y federar consultas en los dos tipos de almacenamiento.
• La forma en que se distribuyen los datos en HDFS hace que sea costoso unirlos. En una base de datos relacional distribuida ( MPP ), podemos ubicar registros con las mismas claves primarias y externas en el mismo nodo de un clúster. Esto hace que sea relativamente barato unir tablas muy grandes. No es necesario que los datos viajen por la red para realizar la unión. Esto es muy diferente en Hadoop y HDFS. En HDFS, las tablas se dividen en grandes fragmentos y se distribuyen entre los nodos de nuestro clúster. No tenemos ningún control sobre cómo se distribuyen los registros individuales y sus claves en el clúster. Como resultado, las uniones en Hadoop para dos tablas muy grandes son bastante costosas ya que los datos deben viajar por la red. Deberíamos evitar las uniones siempre que sea posible. Para una tabla de hechos y dimensiones grande, podemos desnormalizar la tabla de dimensiones directamente en la tabla de hechos. Para dos tablas de transacciones muy grandes, podemos anidar los registros de la tabla secundaria dentro de la tabla principal y aplanar los datos en tiempo de ejecución.

Literatura

• Kimball, Ralph y Margy Ross (2013). El kit de herramientas para almacenes de datos: la guía definitiva para el modelado dimensional (3.ª edición). Wiley. ISBN 978-1-118-53080-1.
• Ralph Kimball (1997). "Un manifiesto de modelado dimensional". DBMS y sistemas de Internet . 10 (9).
• Margy Ross (Kimball Group) (2005). "Identifying Business Processes". Kimball Group, Consejos de diseño (69). Archivado desde el original el 12 de junio de 2013.

Referencias

1. Connolly, Thomas; Begg, Carolyn (26 de septiembre de 2014). Sistemas de bases de datos: un enfoque práctico para el diseño, la implementación y la gestión (6.ª ed.). Pearson. Parte 9 Inteligencia empresarial. ISBN 978-1-292-06118-4.
2. Moody, Daniel L.; Kortink, Mark AR "De modelos empresariales a modelos dimensionales: una metodología para el diseño de almacenes de datos y marts de datos" (PDF) . Modelado dimensional. Archivado (PDF) del original el 17 de mayo de 2017 . Consultado el 3 de julio de 2018 .
3. Ralph Kimball; Margy Ross; Warren Thornthwaite; Joy ​​Mundy (10 de enero de 2008). El kit de herramientas del ciclo de vida del almacén de datos: métodos expertos para diseñar, desarrollar e implementar almacenes de datos (segunda edición). Wiley. ISBN 978-0-470-14977-5.
4. Matteo Golfarelli; Stefano Rizzi (26 de mayo de 2009). Diseño de almacenes de datos: principios y metodologías modernas . McGraw-Hill Osborne Media. ISBN 978-0-07-161039-1.
5. Ralph Kimball; Margy Ross (26 de abril de 2002). The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling (segunda edición). Wiley. ISBN 0-471-20024-7.
6. Ralph Kimball; Margy Ross; Warren Thornthwaite; Joy ​​Mundy; Bob Becker (enero de 2008). The Data Warehouse Lifecycle Toolkit (segunda edición). Wiley. ISBN 978-0-470-14977-5.