Arquitectura
Relaciones entre entidades
Saber qué campos tiene cada entidad sirve de poco si no se sabe cómo se enganchan entre sí. Esta página es el mapa que hay que tener delante al montar el modelo.
La regla única#
Todas las relaciones funcionan igual:
Un campo
ID_ALGOcontiene el valor del campoIDde la entidadALGOS.
ID_CLIENTE de una tarea contiene el ID de CLIENTES. ID_PARTE de un servicio
contiene el ID de PARTES. No hay claves compuestas, ni convenciones distintas
según la tabla, ni campos de enlace con nombres caprichosos.
Por eso el modelado es mecánico
En Power BI, cada relación es uno a varios, del ID de la entidad maestra al
ID_* de la que la referencia, y en sentido único. No hay que descubrir nada.
La columna vertebral#
Es la cadena que sostiene el 80 % de los análisis:
CLIENTES
│ ID_CLIENTE
▼
PROYECTOS ──────────────┐
│ ID_PROYECTO │ ID_PROYECTO
▼ │
TAREAS ─────────────────┤
│ ID_TAREA │
▼ │
PARTES │
│ ID_PARTE │
├──────────────► SERVICIOS_PARTE (las horas)
├──────────────► MATERIALES_PARTE (el material)
└──────────────► GASTOS_PARTE (dietas y desplazamientos)
Y en paralelo, lo previsto:
TAREAS ── ID_TAREA ──► PLANIFICACIONES_TAREA (lo que se iba a hacer)
Los saltos no siempre son de uno en uno
SERVICIOS_PARTE lleva también ID_TAREA, y varias entidades llevan
ID_PROYECTO aunque cuelguen de una tarea. Es deliberado: permite agrupar por
proyecto sin encadenar tres saltos, y acelera mucho las consultas.
Las dimensiones que cuelgan de casi todo#
| Dimensión | La referencian | Campo |
|---|---|---|
EMPRESAS |
Prácticamente todas | ID_EMPRESA |
ESTADOS |
Proyectos, tareas, partes y documentos de venta | ID_ESTADO |
ACTIVIDADES y SERIES |
Documentos y trabajo | ID_ACTIVIDAD, ID_SERIE |
TARIFAS |
Clientes, proyectos, líneas | ID_TARIFA |
ARTICULOS |
Líneas de venta, materiales, servicios | ID_ARTICULO |
PERSONAS |
Asignaciones, servicios, costes | ID_PERSONA |
TIPOS_PROYECTO, TIPOS_TAREA, TIPOS_PARTE, TIPOS_HORA, TIPOS_TRABAJO |
Cada una a lo suyo | ID_TIPO_* |
Las tablas puente#
Cuando la relación es de varios a varios, hay una entidad intermedia. Todas siguen el mismo patrón: dos identificadores y poco más.
| Puente | Une |
|---|---|
PROYECTOS_PERSONAL · TAREAS_PERSONAL · PARTES_PERSONAL |
El trabajo con las personas |
PROYECTOS_RECURSOS · TAREAS_RECURSOS · PARTES_RECURSOS |
El trabajo con los medios |
TAREAS_ACTIVOS |
Las tareas con los equipos sobre los que actúan |
TAREAS_MANTENIMIENTOS_ACTIVOS |
Las tareas con los mantenimientos que cubren |
PARTES_ESTADILLO |
Los partes con el estadillo que los agrupa |
EMPRESAS_USUARIOS |
Los usuarios con las empresas a las que acceden |
ACTIVOS_CLIENTES · PERSONAS_ARTICULOS · PROMOCIONES_PERSONAS |
Lo que indica su nombre |
En Power BI, los puentes son tablas de hechos sin métricas
Se relacionan en varios a uno con las dos entidades que unen, y sirven para contar asignaciones o para filtrar. No hace falta convertirlos en nada raro.
La venta y la compra#
PROYECTOS / TAREAS
│
▼
PRESUPUESTOS ──► DETALLES_PRESUPUESTO (líneas)
(presupuestos y albaranes, └──► DETALLES_PRESUPUESTO_ALBARANES
distinguidos por su tipo) (enlace presupuesto ↔ albarán)
│
└──► PLAN_PAGOS_PRESUPUESTO
FACTURASCOMPRA ──► DETALLES_FACTURASCOMPRA ──► ID_PROYECTO / ID_TAREA
(aquí vive la imputación del coste)
PRESUPUESTOS contiene dos documentos distintos
Presupuestos y albaranes comparten entidad. Filtra siempre por el tipo de documento o estarás sumando la oferta con lo servido, y el resultado parecerá correcto.
Calidad#
CAL_INCIDENCIAS ──► CAL_ACCIONES ──┬──► CAL_SEGUIMIENTOS_ACCION
└──► CAL_EVALUACIONES_ACCION
Con sus catálogos colgando: CAL_ESTADOS, CAL_CAUSAS_RAIZ, CAL_TIPOS_ACCION,
CAL_ESTADOS_ACCION, TIPOS_INCIDENCIA y TIPOS_IMPACTO.
Tres trampas al modelar#
1. ESTADOS lo comparten cuatro entidades#
Proyectos, tareas, partes y documentos de venta apuntan todos a la misma entidad de estados. Si creas cuatro relaciones activas contra ella, la herramienta no sabrá por cuál filtrar.
Dos salidas, ambas válidas
O duplicas la dimensión —una copia para estados de tarea, otra para estados de parte—, o dejas una relación activa y las demás inactivas y las activas en la medida cuando las necesites. Duplicar es más fácil de explicar a quien herede el informe.
2. Hay muchas fechas, y solo un calendario#
Una tarea tiene fecha de inicio, de fin, prevista… y todas son analizables. Con una sola tabla de calendario hay que decidir cuál manda.
Relaciona el calendario con la fecha que de verdad analizas
Para productividad, la fecha del servicio. Para cartera, la del documento. Las demás, como relaciones inactivas que se activan en medidas concretas.
3. La empresa filtra todo, pero no sola#
En instalaciones multiempresa, ID_EMPRESA está en casi todas las entidades, pero
Power BI no lo aplica solo: hay que relacionar una tabla de empresa y propagar
el filtro, o filtrar en origen al cargar.
Es el error que más informes multiempresa ha estropeado
No da ningún aviso: los totales simplemente salen más altos de lo que deberían.
Un modelo en estrella que funciona#
| Papel | Entidades |
|---|---|
| Hechos | SERVICIOS_PARTE, MATERIALES_PARTE, GASTOS_PARTE, DETALLES_PRESUPUESTO, DETALLES_FACTURASCOMPRA, PLANIFICACIONES_TAREA |
| Dimensiones | CLIENTES, PERSONAS, ARTICULOS, PROYECTOS, TAREAS, ESTADOS, TIPOS_*, ACTIVIDADES, SERIES, EMPRESAS y tu calendario |
| Puentes | Las tablas de asignación de arriba |
Empieza por una sola tabla de hechos
Con SERVICIOS_PARTE y cinco dimensiones tienes el informe de horas y
productividad. Añade DETALLES_PRESUPUESTO cuando quieras ingresos y
DETALLES_FACTURASCOMPRA cuando quieras margen. Montar las seis a la vez el
primer día es la forma más rápida de acabar con un modelo que nadie entiende.
Qué viene después#
El detalle campo a campo está en las páginas de referencia, empezando por Maestros y Trabajo.