Análisis de requerimientos y modelado de datos en Power BI

Transformar un requerimiento real en un modelo de datos funcional es una de las competencias más valoradas en el análisis de información. Aquí se recorre paso a paso cómo recibir la solicitud de un interesado, clasificar los datos correctamente y preparar todo para crear visualizaciones dinámicas tanto en Excel como en Power BI.

¿Cómo se analiza el requerimiento de un interesado?

Todo comienza con un mensaje de un área específica de la organización. En este caso, la interesada —o stakeholder— es Kelly, supervisora del área de bodega de productos [0:20]. A partir de su solicitud se identifican necesidades concretas: visualizar precio de costo, precio de venta, movimiento de inventario y cantidades en existencia.

Un punto clave es que Kelly necesita algo dinámico, no estático [1:07]. Esto significa que la solución debe incluir filtros y gráficas interactivas donde ella pueda ubicar la información rápidamente para responder sus propias preguntas operativas.

¿Por qué importa clasificar al interesado antes de diseñar?

Identificar quién solicita la información y desde qué área lo hace permite anticipar el tipo de datos involucrados. Al saber que se trata de bodega de productos, inmediatamente se entiende que el contexto gira alrededor de ítems, inventario y bodegaje. Esta clasificación del stakeholder orienta las decisiones de diseño desde el inicio.

¿Cómo se importan y validan los datos en Excel?

En lugar de abrir el archivo directamente, la forma correcta es ir a la pestaña Datos → Obtener datos → De un archivo → Excel [1:38]. Este método habilita herramientas de transformación que no estarían disponibles con una apertura convencional.

Al seleccionar el archivo Productos 2024 y hacer clic en Transformar datos, se abre una interfaz idéntica a la que ofrece Power BI [2:22]. Ahí se realiza la validación de tipos de datos: numéricos, decimales, de moneda, booleanos, fechas, geográficos y URLs.

¿Qué errores comunes aparecen al clasificar tipos de datos?

• La columna ID de producto contiene una letra y dígitos (P001), por lo que debe tratarse como texto, nunca como número [3:05].
• Costo producto aparecía como decimal, pero al representar dinero debe configurarse como moneda [3:52].
• Fecha de ingreso incluía hora, pero todas las horas eran idénticas, así que se simplificó dejando solo la fecha [4:23].
• Unidades compradas y despachadas son cantidades enteras: no se compra medio mouse, se clasifican como número entero [4:50].
• El campo tipo de registro (ingreso o salida) se define como texto [5:22].

Una buena práctica mencionada es el doble factor de verificación: revisar los tipos de datos más de una vez, porque el sistema puede revertir configuraciones al guardar [7:08].

¿Cómo se verifica la integridad de los datos?

Desde la pestaña Vista, se activan las opciones de calidad de columnas, distribución de columnas y perfil de columna [5:42]. Cada columna muestra un semáforo con tres indicadores:

• Válido: porcentaje de registros correctos.
• Error: registros con problemas que deben corregirse.
• Vacío: campos sin información.

Lo ideal es que todos los campos estén al 100 % válidos, sin errores ni vacíos [6:18]. Además, se puede elegir entre analizar las primeras mil filas como muestra o el set completo para mayor confianza [6:52].

¿Qué diferencia hay entre una tabla de hechos y una tabla de dimensiones?

La tabla de hechos (fact table) contiene registros con temporalidad: tiene fechas y genera secuencias a medida que el inventario se mueve [7:40]. Cada ingreso o salida crea un nuevo registro con fecha actualizada.

La tabla de dimensiones es finita y describe los atributos de cada producto [8:30]. Por ejemplo, el producto P001 es un altavoz, categoría electrónica, subcategoría audio, con un costo de 2170,37 y un precio de venta de 2821,48. Esos atributos son únicos para ese artículo.

• La tabla de dimensiones filtra la tabla de hechos.
• La tabla de hechos genera N cantidad de registros conforme se mueve el inventario.
• El ID de producto es la columna clave que relaciona ambas tablas [3:00].

En Power BI, al importar ambas tablas se repite el proceso de validación. Es otra buena práctica renombrar las tablas según su rol: anteponer "DM" para dimensión y "Fact" para hechos [12:48]. Power BI detecta automáticamente la relación entre tablas cuando encuentra columnas en común, como el ID de producto [13:20].

El sentido de la relación entre ambas tablas determinará cómo fluye la información y qué resultados se obtienen al responder las preguntas del requerimiento. Si trabajas con modelos de datos por primera vez, practica creando tu propia tabla de dimensiones a partir de un set real y comparte tu experiencia en los comentarios.