En esta entrada revisaremos el Modelado Dimensional desde los conceptos más generales.

mapamental

Conceptos generales de modelado dimensional

Habitualmente estamos acostumbrados a utilizar aplicaciones donde hay varios o muchos usuarios concurrentes, leyendo y escribiendo datos en sus bases de datos.

“Imagínate por ejemplo, un supermercado, donde muchas cajeras están atendiendo simultáneamente a los clientes, los encargados de almacén están introduciendo información de recepción de pedidos, en atención al cliente están creando una tarjeta de fidelización a un cliente y rellenando todos sus datos, en la oficina el departamento de administración está introduciendo facturas y contabilizándolas y los responsables de tienda están consultando información de ventas de ese momento para potenciar las ventas. Hay muchas personas leyendo y escribiendo información en esa base de datos, por ello debe tener un diseño que soporte ese acceso concurrente.”

Estas aplicaciones son sistemas transaccionales o sistemas OLTP (por sus siglas en inglés, OnLine Transaction Processing), y aunque constan de consultas e informes, no están diseñados para responder a las preguntas analíticas de los usuarios de negocio. Almacenan los datos en Sistemas Gestores de Bases de Datos Relacionales (SGBDR), allí dichos datos están altamente normalizados, optimizados para concurrencia de muchos usuarios y de muchas escrituras y lecturas simultáneas.

Veamos en la siguiente imagen un ejemplo de tablas de una base de datos relacional normalizada:

normalizada

Encontrar estos esquemas normalizados es algo habitual y lógico para cualquier persona que haya estudiado sobre Bases de Datos Relacionales y diseño de sistemas transaccionales, pero quien no lo haya hecho, lo primero que hace cuando le muestran y explican un diagrama de este tipo es plantearse una serie de preguntas como:

  • ¿Por qué la información del cliente está en 18 tablas y no toda en una sola tabla?
  • ¿Por qué no está toda la información de una factura en una misma tabla? Tengo ir a la tabla ‘CabeceraFra’ para ver datos del cliente, a ‘DetalleFra’ para ver unidades y productos vendidos’, a ‘PieFra’ para ver detalles de impuestos, “vaya lío”.
  • Está todo disperso, y me decís que hay que unirlo cada vez que quiero consultarlo. ¿Por qué no está todo unido y nos evitamos estarlo uniendo continuamente para consultarlo?
  • Lo tenéis todo dividido en procesos de negocio, muy desmenuzado, no entendéis que para los análisis necesitamos obtener una visión global.
  • Entiendo que un informe de muchas páginas sea lento, Pero ¿Por qué van tan lentos algunos que no sacan más que unas poquitas líneas? Como ocurre con el informe de comparativa de ventas anuales, que tan sólo ocupa 7 líneas (una línea por año), y 4 columnas (ventas año actual, ventas año anterior, diferencia y % diferencia).

La respuesta está en que estos sistemas transaccionales están enfocados a gestionar un gran número de transacciones concurrentes, hay mucha gente escribiendo simultáneamente, y estos además escriben pequeñas cantidades de filas (dar de alta un cliente, hacer un pedido de 14 líneas, modificar los datos de un proveedor, un apunte contable, etc.) y una poquitas personas consultando datos, además de que la mayoría de las consultas son operativas (¿cuánto llevamos vendido hoy?, ¿se ha enviado ya el pedido XXXXX?, etc.). Por tanto se centran en optimizar estas situaciones. Pero cuando alguien va a hacer un análisis a partir de información de la empresa, su situación ideal sería que nadie estuviese escribiendo y que la estructura estuviese optimizada para consultas (sólo lecturas de datos) y análisis de éstos.

Los sistemas analíticos están enfocados al análisis de grandes cantidades de información, proporcionando respuestas rápidas y complejas.

Veamos una comparativa en la siguiente tabla entre Transaccional y Analítico:

transVSans

Por tanto la solución pasa por emplear un enfoque totalmente diferente, el Data Warehousing y el Modelado Dimensional.

 

Te invito a seguir in hasta los detalles de conceptos como Data Warehouse y Data Marts, dimensiones y hechos y todos los detalles para llegar a la comprensión de el modelado dimensional que es la clave de un sistema BI. Con ello conseguimos reducir la carga transacciones (escritura), y utilizar esquemas diseñados especialmente para la consulta y análisis.

¿Quieres aprender Power BI? Infórmate sobre nuestros cursos de 0 a experto y suscríbete a nuestro blog para estar al día de todas las novedades.

0 Shares:
Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You May Also Like