Modelado dimensional (DM en inglés) nombra a un conjunto de técnicas y conceptos utilizados en el diseño de almacenes de datos. Se considera que es diferente del Modelo entidad-relación. El modelado de dimensiones 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, tal como archivos de base de datos multidimensional o planas. Según el consultor de almacenamiento de datos Ralph Kimball,[1] el modelado dimensional es una técnica de diseño de bases de datos destinadas a apoyar a las consultas de los usuarios finales en un almacén de datos. Se orienta en torno a la comprensibilidad y rendimiento. Según él, aunque el modelo entidad relacional orientado a transacciones es muy útil para la captura de transacción, se debe evitar en la entrega al usuario final.
El modelado dimensional siempre utiliza los conceptos de hechos (medidas) y dimensiones (contexto). Los hechos son normalmente (pero no siempre) los valores numéricos que se pueden agregar, y las dimensiones son grupos de jerarquías y descriptores que definen los hechos. Por ejemplo, la cantidad de ventas es un hecho; marca de tiempo, producto, NoRegistro, NoTienda, etc., son elementos de dimensiones. Los modelos dimensionales son construidos por el área de proceso de negocio, por ejemplo, las ventas en tiendas, inventarios, reclamaciones, etc. Debido a que las diferentes áreas de proceso de negocio comparten algunas pero no todas las dimensiones, la eficiencia en el diseño, la operación y la coherencia, se logra usando tablas de dimensión, es decir, utilizando una copia de la dimensión compartida. El término "tablas de dimensión" se originó por Ralph Kimball.
Proceso de modelado dimensional
El modelo tridimensional se construye sobre un esquema de estrella, con dimensiones de la tabla de hechos[2][3] para construir el esquema, el siguiente modelo de diseño se utiliza:
- Escoger el proceso de negocio
- Declarar el "grain"
- Identificar las dimensiones
- Identificar los hechos
Escoger el proceso de negocio
El proceso de modelización dimensional se basa en un método de diseño de 4 pasos que ayuda a asegurar la facilidad de uso del modelo dimensional y el uso del almacén de datos. Los fundamentos del diseño se basan en el proceso de negocio real que debe cubrir el almacén de datos. Por lo tanto el primer paso en el modelo es describir el proceso de negocio en él se basa el modelo. Esto podría ser por ejemplo una situación de ventas en una tienda al por menor. Para describir el proceso de negocio, se puede optar por hacer esto en texto plano o utilizar Notación de Modelado de Procesos de Negocio (BPMN en inglés) u otras guías de diseño, como el Lenguaje Unificado de Modelado (UML en inglés).
Declarar el "grain"
Después de describir el Proceso de Negocio, el siguiente paso en el diseño es declarar el "grain" del modelo. El "grain" del modelo es la descripción exacta de lo que el modelo dimensional debería concentrarse. Para aclarar lo que significa el "grain", usted debe escoger el proceso central y describirlo con una sola oración. Además el "grain" (oración) es a lo que se le va a construir sus dimensiones y tabla de hechos. Puede que le resulte necesario volver a este paso para alterar el "grain" debido a nueva información obtenida en lo que su modelo supone entregar.
Identificar las dimensiones
El tercer paso en el proceso de diseño es definir las dimensiones del modelo. Las dimensiones deben ser definidas dentro del "grain" de la segunda etapa del proceso de modelado dimensional de 4 pasos. Las dimensiones son la base de la tabla de hechos, y es donde se recogen los datos de la tabla de hechos. Normalmente las dimensiones son sustantivos, como fecha, tienda, inventario, etc. Estas dimensiones son donde se almacenan todos los datos. Por ejemplo, la dimensión fecha podría contener datos tales como año, mes y día de la semana.
Identificar los hechos
Después de definir las dimensiones, el siguiente paso en el proceso es crear las llaves de la tabla de hechos. Este paso es identificar los hechos numéricos que poblarán cada fila de la tabla de hechos. Este paso está estrechamente relacionado con los usuarios de negocio del sistema, ya que es donde consiguen el acceso a los datos almacenados en el almacén de datos. Por lo tanto la mayor parte de las filas de la tabla de hecho son cifras numéricas, aditivos tales como cantidad o costo por unidad, etc.
Normalización de Dimensión
La Normalización de Dimensión elimina atributos redundantes . Las dimensiones están estrictamente unidas en las sub-dimensiones.
La Normalización de Dimensión tiene una influencia en la estructura de datos que difiere de muchas filosofías de almacenes de datos.[3]
Los desarrolladores a menudo no normalizan las dimensiones debido a varias razones:[4]
- La normalización hace la estructura de datos más compleja
- El tiempo de ejecución puede ser más lento, debido a las muchas uniones entre tablas
- El ahorro de espacio es mínimo
- Los Mapeados de bits de índices no pueden utilizarse
- El rendimiento de consultas, bases de datos 3NF sufren de problemas de rendimiento cuando se agregan o recuperar muchos valores dimensionales que pueden requerir análisis.
Hay algunos argumentos sobre por qué la normalización puede ser útil.[3] 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 las dimensiones de los clientes y los proveedores la utilizan.
Beneficios del modelado dimensional
Los beneficios del modelado dimensional son los siguientes:[5]
- 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 dimensiones coherentes , por lo que es más fácil de leer e interpretar. La simplicidad también permite al software navegar las bases de datos de manera eficiente. En los modelos normalizados, los datos se divide en muchas entidades discretas e incluso un proceso de negocio simple podría resultar en docenas de tablas unidas entre sí de una manera compleja.
- El rendimiento de consultas - Los modelos dimensionales están más desnormalizados y optimizados para las consultas de datos, mientras que los modelos normalizados buscan eliminar redundancias de datos y están optimizados para la carga de transacciones y actualización. El marco predecible de un modelo dimensional permite a la base de datos hacer fuertes supuestos sobre los datos, por lo que puede tener un impacto positivo en el rendimiento. Cada dimensión es el equivalente a un punto de entrada en la tabla de hechos, y esta estructura simétrica permite un manejo eficaz de consultas complejas. La optimización de consulta se hace simple, predecible y controlable.
- Extensibilidad - Los modelos dimensionales son escalables y fácilmente acomodados a nuevos datos inesperados. Las tablas existentes pueden ser cambiados, ya sea por la simple adición de nuevas filas de datos en la tabla o ejecutar en SQL algún comando de tipo "Alter Table". Las consultas o aplicaciones montadas sobre el almacén de datos no necesitan ser reprogramadas para acomodarse a los nuevos cambios. Las consultas y aplicaciones antiguas continúan funcionando sin producir resultados diferentes. Pero en los modelos normalizados cada modificación se debe considerar cuidadosamente, debido a las complejas dependencias entre las tablas de bases de datos.
Referencias
- ↑ Kimball 1997.
- ↑ Ralph Kimball, Margy Ross, Warren Thornthwaite, and Joy Mundy (10 de enero de 2008). The Data Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing, and Deploying Data Warehouses (Second edición). Wiley. ISBN 978-0-470-14977-5.
- ↑ a b c Matteo Golfarelli, Stefano Rizzi (26 de mayo de 2009). Data Warehouse Design: Modern Principles and Methodologies. McGraw-Hill Osborne Media. ISBN 978-0-07-161039-1.
- ↑ Ralph Kimball, Margy Ross (26 de abril de 2002). The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling (Second edición). Wiley. ISBN 0-471-20024-7.
- ↑ Ralph Kimball, Margy Ross,Warren Thornthwaite, Joy Mundy, Bob Becker (enero de 2008). The Data Warehouse Lifecycle Toolkit (Second edición). Wiley. ISBN 978-0-470-14977-5.
Bibliografía