Cómo funciona una herramienta de BI: conexión, modelo y dimensiones

Ya conoces QUÉ herramientas existen: Power BI, Tableau, Looker Studio, Qlik, Metabase, Superset, cada una con su precio, su público y su ecosistema. Saber cuál usa cada empresa te evita sorpresas el primer día de trabajo. Pero conocer los nombres no basta. Cuando abras cualquiera de ellas por primera vez, vas a encontrarte con las mismas cinco decisiones: de dónde salen los datos, cómo se relacionan las tablas, qué se agrupa y qué se suma, cómo se calcula lo que no viene en la fuente, y cada cuánto se refrescan los números. Estas decisiones no cambian de una herramienta a otra: cambian los botones y los nombres, no los conceptos. Esta lección te da ese mapa mental — el vocabulario común que te sirve con cualquier herramienta que te pongan delante.

Y no partes de cero. Ya sabes escribir SQL: agrupar con GROUP BY, cruzar tablas con JOIN, filtrar con WHERE. Resulta que una herramienta de BI hace exactamente esas tres cosas por debajo, solo que con clics en vez de código. Cuando entiendas que una "dimensión" es la columna por la que agrupas y que una "relación" es un JOIN que defines una vez y se reutiliza, vas a sentir que ya conocías la mitad de la herramienta antes de abrirla. Ese es el objetivo: que el BI no te parezca magia, sino SQL con una interfaz encima.

### El mapa: las cinco capas de cualquier herramienta de BI

Toda herramienta de BI, por distinta que parezca su interfaz, está construida sobre las mismas cinco capas apiladas. Los datos entran por abajo y suben hasta convertirse en un gráfico que alguien mira. Si entiendes qué hace cada capa, entiendes cualquier herramienta.

### Capa 1: conexión a fuentes — traer el dato o consultarlo en vivo

La primera decisión que toma cualquier herramienta de BI es de dónde saca los datos y, sobre todo, si se los queda dentro o los consulta cada vez. Esto tiene dos modos, y la diferencia entre ellos define el rendimiento y la frescura de todo lo que construyas encima. Los nombres cambian según la herramienta, pero los dos modos son universales.

El primer modo se llama importación o extracción — en inglés import o extract. La herramienta se conecta a la fuente una vez, copia los datos DENTRO de sí misma, y a partir de ahí trabaja con esa copia. Power BI lo llama "Import mode", Tableau lo llama "Extract" (un fichero .hyper que vive en tu ordenador o en el servidor). Piensa en ello como hacer la compra del mes: vas al supermercado una vez, llenas la despensa, y durante semanas cocinas con lo que tienes en casa sin volver a la tienda. Es rápido porque todo está a mano, pero lo que tienes en la despensa es lo que compraste el día que fuiste — no lo que hay hoy en las estanterías del súper.

El segundo modo se llama consulta en vivo o consulta directa — live connection o direct query. La herramienta NO copia nada: cada vez que alguien abre el dashboard o cambia un filtro, la herramienta lanza una consulta a la fuente en ese instante y muestra lo que devuelve. Power BI lo llama "DirectQuery", Tableau lo llama "Live". Siguiendo la analogía: es cocinar yendo al supermercado a por cada ingrediente en el momento de necesitarlo. Siempre cocinas con lo más fresco que hay, pero cada plato tarda más porque hay que ir y volver de la tienda cada vez.

La regla práctica que usan los profesionales: si los datos cambian una vez al día (ventas de ayer, facturación cerrada del mes), importar es casi siempre mejor — el dashboard vuela y da igual que los números sean de esta mañana. Si los datos cambian a cada minuto y necesitas verlos en vivo (stock disponible ahora mismo, incidencias abiertas en este segundo), la consulta directa es la única opción, aunque pagues el precio en velocidad. La mayoría de los dashboards de negocio funcionan perfectamente en modo importación con un refresco nocturno.

### Capa 2: el modelo de datos — los JOIN que ya sabes, pero dibujados

Aquí es donde tu SQL empieza a pagar dividendos. Cuando escribías consultas, cruzabas tablas con JOIN cada vez que necesitabas datos de dos sitios: la tabla de ventas tiene el id del cliente, la tabla de clientes tiene su nombre y su región, y unías ambas por ese id. Tenías que reescribir ese JOIN en cada consulta que lo necesitara.

Una herramienta de BI hace lo mismo, pero con una diferencia clave: defines las relaciones UNA sola vez, en una pantalla donde arrastras una línea desde la columna "cliente_id" de la tabla de ventas hasta la columna "id" de la tabla de clientes. A partir de ese momento, la herramienta sabe cómo cruzarlas y lo hace sola cada vez que combinas un dato de ventas con un dato de clientes. A esa pantalla se la llama modelo de datos, y a cada línea que dibujas, una relación. Es un JOIN reutilizable, dibujado en vez de escrito.

Esta capa recibe nombres distintos según la herramienta pero es la misma idea. En Power BI se llama literalmente "modelo" y tiene su propia vista con las tablas y las flechas entre ellas. En Tableau se habla de "relationships" y del "data model". En Looker existe la capa semántica definida en su lenguaje LookML, donde se declaran las uniones. En Qlik, su motor asociativo descubre parte de esas relaciones solo. El concepto transversal es siempre el mismo: un sitio donde se declara cómo encajan las tablas para no repetirlo en cada gráfico.

Fíjate en la forma del diagrama y reconócela: es el esquema en estrella que estudiaste al aprender a leer el modelo de datos que te dan. La tabla de hechos en el centro (VENTAS, la que guarda los eventos y sus números) rodeada de las tablas de dimensiones que la describen (CLIENTES, PRODUCTOS, CALENDARIO: el contexto de quién, qué y cuándo). Lo que allí viste desde el lado de quien CONSULTA el almacén, aquí lo ves desde el lado de la herramienta de BI: es exactamente ese modelo en estrella el que conectas, y por eso la herramienta te pide que dibujes las relaciones entre esas tablas antes de poder cruzarlas en un gráfico.

### Capa 3: dimensiones y métricas — la distinción que lo ordena todo

Si te quedas con una sola idea de esta lección, que sea esta. Y ya te suena del modelo de datos: allí separabas el contexto (las dimensiones: quién, qué, cuándo) de los números que se agregan (las medidas de la tabla de hechos). Toda herramienta de BI hace esa misma división con tus columnas, y entender la diferencia es la mitad del trabajo. Una columna o es una dimensión o es una métrica, y cada una hace un papel distinto en un gráfico.

Una dimensión es una columna por la que AGRUPAS: la región, el mes, la categoría de producto, el canal de venta. Son las etiquetas, los "por" de una frase de negocio: ventas POR región, pedidos POR mes, clientes POR segmento. Son casi siempre texto o fechas, y sus valores se repiten (hay muchas ventas en "Norte", muchos pedidos en "enero"). Una métrica — también llamada medida — es una columna que se AGREGA: el importe, la cantidad, el número de pedidos. Son los números que sumas, promedias o cuentas. Son las respuestas: cuánto, cuántos, qué media.

Y aquí viene la conexión directa con lo que ya sabes. Recuerda cómo escribías un GROUP BY en SQL: `SELECT region, SUM(importe) FROM ventas GROUP BY region`. La columna que ponías en el GROUP BY (region) es la dimensión. La función de agregación (SUM(importe)) es la métrica. La herramienta de BI hace exactamente esa consulta cuando arrastras "region" a un eje y "importe" al otro — solo que en vez de escribirla, la construyes con clics. Cada gráfico que montes es, por debajo, un GROUP BY que la herramienta genera por ti.

1-- Lo que TÚ escribirías en SQL:
2SELECT region, SUM(importe) AS ingresos
3FROM ventas
4GROUP BY region;
5
6-- Lo que hace la herramienta cuando arrastras
7-- "region" al eje X e "importe" al eje Y:
8--   dimensión  -> GROUP BY region
9--   métrica    -> SUM(importe)
10-- Genera la misma consulta. Tú solo arrastras.

Con esto tienes las tres capas de abajo: de dónde entran los datos, cómo se relacionan las tablas, y qué papel juega cada columna. Lo que falta son las dos de arriba: cómo se calcula lo que no viene en la fuente, y cada cuánto se refrescan los números. De eso va la lección siguiente.