Los datos ya están preparados. Ahora necesitas organizar las tablas para que cada campo tenga una función clara. En esta lección vas a construir un modelo pequeño con una tabla de operaciones y otra de descripciones. La meta es poder preguntar por productos sin copiar innecesariamente información en todas las filas.
Separa hechos y descripciones
Ventas contiene acontecimientos: una cantidad de un producto vendida un día mediante un canal. Productos contiene características de los artículos: su nombre y su categoría. A las tablas de operaciones se las suele llamar tablas de hechos. A las descriptivas se las llama dimensiones. Los nombres técnicos son útiles si recuerdas qué representan.
La diferencia no depende del tamaño. Una tabla con doce ventas sigue siendo una tabla de hechos. Un catálogo de miles de referencias puede ser una dimensión. Lo que importa es la función: registrar algo que sucede o describir los elementos con los que analizas lo sucedido.
En nuestro modelo Fecha tendrá después su propia tabla de calendario. Canal permanecerá de momento en Ventas porque solo necesitamos sus dos valores y no tenemos más características del canal. No hace falta convertir cada columna de texto en otra tabla para que el proyecto parezca más avanzado.
Mantén clara la granularidad
La granularidad es el nivel de detalle de una fila. Aquí es una línea de venta de un producto. Si mañana importas una tabla con totales mensuales no puedes colocar sus registros junto a estas líneas y sumar todo. Estarías mezclando operaciones individuales con resultados que quizá ya incluyen esas mismas operaciones.
Escribe sobre el esquema del cuaderno «una fila = una línea vendida». Haz lo mismo para Productos: «una fila = un producto». Esta frase ayuda a decidir dónde colocar nuevos campos. El precio de una transacción pertenece a la línea. La categoría estable que usamos en el ejercicio pertenece al catálogo.
Si un producto cambiara de categoría en el futuro tendrías que decidir si los informes históricos deben mostrar la clasificación antigua o la actual. Ese problema no aparece en los datos didácticos pero conviene reconocerlo. Un modelo no elimina decisiones de negocio: las hace explícitas.
Revisa lo que realmente has cargado
Abre la vista de modelo. Debes ver Ventas y Productos. Si todavía aparecen tablas de ensayo vuelve a Power Query y revisa su carga. Evita continuar con nombres casi iguales como Ventas2, VentasBuena o ProductosCopia porque podrías arrastrar al gráfico un campo de la tabla equivocada.
Coloca Ventas en el centro del lienzo y Productos a un lado. La posición no cambia los cálculos pero facilita leer el esquema. Más adelante situarás Calendario cerca de Ventas. El resultado recordará una estrella sencilla: una tabla de operaciones conectada con tablas que permiten describirlas.
Revisa también los tipos de ProductoID. Debe ser texto en ambas tablas. Comprueba que Productos tiene tres claves únicas y que cada clave utilizada en Ventas aparece en el catálogo. No basta con que los nombres de columna coincidan: sus valores deben ser compatibles.
Establece qué campos verá quien diseña
ProductoID y VentaID sirven para unir o comprobar registros. Producto y Categoria sirven para analizar y presentar. Más adelante puedes ocultar del panel de informe los identificadores que no quieras utilizar en visuales habituales. Ocultar un campo no lo borra del modelo y tampoco impide técnicamente acceder a los datos a quien tenga permisos suficientes.
Durante el aprendizaje mantén VentaID disponible para revisar las líneas. Cuando el informe esté terminado podrás valorar si conviene ocultarlo a los autores ocasionales. No uses la ocultación como una medida de seguridad. Su finalidad aquí es reducir confusiones al elegir campos.
Añade descripciones a las columnas o medidas cuando la interfaz lo permita. Una descripción como «precio unitario sin impuestos registrado en la venta» es más informativa que «precio». Estas notas facilitan retomar el proyecto semanas después sin tener que buscar la definición en conversaciones o recuerdos.
Evita relaciones por comodidad
Dos tablas pueden compartir una palabra sin que exista una relación útil entre ellas. No conectes Canal con Categoria porque ambas columnas son texto. Una relación debe expresar una correspondencia real entre registros. En nuestro caso ProductoID es el campo que identifica el producto vendido.
Tampoco conectes cada tabla con todas las demás «por si acaso». Cuantas más rutas de filtrado añadas más difícil resulta entender qué afecta a una cifra. El modelo inicial debe ser tan sencillo como la pregunta del negocio. Una estructura pequeña permite comprobar sus efectos antes de introducir excepciones.
Si Desktop ha detectado automáticamente una relación revísala. No des por hecho que eligió la combinación que necesitas. En la siguiente lección comprobarás su cardinalidad, su estado y la dirección del filtro. Hoy basta con identificar qué enlace debería existir y por qué.
Un ejemplo de diseño incorrecto
Supón que guardas tres filas de totales por producto dentro de Productos: ciento treinta, cuarenta y ocho y ochenta y ocho euros. Después utilizas esas columnas como si fueran ventas que responden al filtro de fecha. Esos números ya están agregados para los dos meses y no contienen el detalle necesario para separarlos correctamente.
La alternativa es calcular las ventas desde Ventas y usar Productos para decidir qué operaciones entran en cada grupo. De esa forma una misma medida responderá a los meses y a los productos seleccionados. No necesitas mantener totales manuales distintos para cada combinación posible.
Errores habituales
Mezclar distintos niveles de detalle dentro de una tabla produce sumas engañosas. Duplicar catálogos genera relaciones difíciles de interpretar. Guardar como columnas valores que deberían calcularse según filtros limita el análisis. Antes de escribir una fórmula complicada revisa si el problema procede de dónde has colocado los datos.
Ejercicio práctico
Dibuja Ventas y Productos en la hoja 7. Escribe la granularidad de cada tabla, señala ProductoID y separa campos descriptivos de cantidades e importes. Completa «Tablas definitivas», «Detalle de cada fila», «Clave compartida» y «Campos para analizar». Contrasta el dibujo con la vista de modelo y guarda una copia antes de crear relaciones.
Lo que deberías recordar
– Una tabla de operaciones registra hechos a un nivel de detalle definido.
– Un catálogo describe elementos y necesita claves coherentes.
– Los totales variables deben calcularse a partir de las operaciones.
– Un modelo sencillo resulta más fácil de comprobar y mantener.
Siguiente lección: Crea relaciones y comprueba cómo viajan los filtros.
