Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Get inspired! Check out the entries from the Power BI DataViz World Championships preliminary rounds and give kudos to your favorites. View the vizzies.

Reply
Syndicate_Admin
Administrator
Administrator

Modelado de datos de procesos de negocio secuenciales

Realmente necesito ayuda con el diseño de un esquema de estrella para una serie de eventos secuenciales de procesos de 'negocio'.

Tengo las siguientes dimensiones claras:

  • calendario de fechas,

  • niños

  • tipos de intervenciones,

  • tipos de referencias,

  • Tipos de acciones de referencia

Un niño puede tener múltiples intervenciones, cada una con una fecha de inicio y una fecha de finalización.
Un niño puede tener varias referencias, cada una con una fecha de inicio y finalización
Un niño puede tener varios programas de derivación, cada uno con una fecha de inicio y otra de finalización
Cada programa puede tener múltiples acciones de derivación que son específicas del tipo de programa.

Cada uno de estos procesos es jerárquico, es decir, un niño no puede tener un programa de derivación sin tener primero una derivación, y un niño no puede tener una derivación sin haber tenido primero una intervención.

En última instancia, necesito ser capaz de encontrar todas las intervenciones que finalizan en un período determinado y mostrar todos los datos relacionados con la derivación, los programas de derivación y las acciones de derivación. Idealmente, quiero mostrar todas las acciones posibles del programa y si un niño que tiene una referencia específica ha completado o no estas acciones. No me preocupan las fechas, ya que probablemente usaré Power Query para resolver esto.

Estoy luchando para modelar esto en un esquema de estrella. Supongo que cada uno de los procesos es una tabla FACT. Sé que es una mala práctica enlazar tablas FACT. He pasado a pensar que puede funcionar tener las acciones del programa de derivación de niños como la tabla de datos principal y cada uno de los procesos anteriores como dimensiones, es decir,

  • Dim Intervenciones: clave de intervención, niño, tipo, inicio, fecha de finalización

  • Dim Referrals: Clave de referencia (compuesta por la clave de intervención y el tipo de referencia), clave de intervención, tipo de referencia, inicio, fecha de finalización,

  • Programa de Referencia Dim: Programa de Referencia (compuesto por la clave de Referencia y el tipo de intervención de referencia), clave de intervención de referencia, tipo de intervención de referencia, fecha de inicio y finalización

HECHO: Clave única, clave infantil, clave de fecha, clave de referencia, clave del programa de referencia, acción de referencia.

¿Funcionaría esto? ¿Me relacionaría entonces con las otras dimensiones que dan tipos a la tabla FACT o con estas dimensiones?

El enfoque alternativo sería el siguiente: para crear cada uno de los procesos como un FACT separado y relacionar cada uno con las dimensiones apropiadas y luego construir una medida de dax para resumir todos los detalles (¡no es que esté seguro de que mi dax esté a la altura de eso!).

¿Alguno de estos es viable? ¡Ya me he metido en un par de madrigueras de conejo y descubrí que no podía filtrar mis datos correctamente!

1 ACCEPTED SOLUTION
Syndicate_Admin
Administrator
Administrator

Hola @scoobymoo1 ,

Su escenario es bastante complejo debido a la naturaleza jerárquica de las intervenciones, referencias, programas y acciones. Vamos a desglosarlo y explorar el mejor enfoque.

Consideraciones clave:

  1. Dependencia jerárquica: Un niño primero debe tener una intervención antes de obtener una referencia, luego un programa de referencia y finalmente acciones dentro de ese programa.
  2. Estructura de hechos-dimensiones: Idealmente, las tablas de hechos almacenan eventos medibles, mientras que las tablas de dimensiones proporcionan atributos descriptivos.
  3. Filtrado y agregación: debe ser capaz de analizar las intervenciones y ver todas las referencias, programas y acciones relacionadas.

Opción 1: Tabla de datos única (Fact_ReferralProgramActions)

Este es el enfoque que propuso: tener una tabla de hechos central con cada paso anterior como una dimensión.

Esquema

  • Fact_ReferralProgramActions (Granularidad: una fila por acción del programa de referencia)

    • ReferralProgramActionKey (PK)
    • ChildKey (Llave Infantil)
    • DateKey
    • Clave de referencia
    • ReferralProgramKey
    • ReferralActionTypeKey
    • Completado (Sí/No)
  • Dim_Children (Datos relacionados con niños)

  • Dim_Calendar (Fechas para el análisis)

  • Dim_Interventions (InterventionKey, ChildKey, Type, Start, End)

  • Dim_Referrals (ReferralKey, InterventionKey, Type, Start, Fin)

  • Dim_ReferralPrograms (ReferralProgramKey, ReferralKey, Tipo, Inicio, Fin)

  • Dim_ReferralActions (ReferralActionTypeKey, ReferralProgramKey, nombre de la acción)

Pros

  • Estructura simple, filtrado más fácil.
  • El rendimiento de las consultas puede ser mejor, ya que todo está en una tabla de hechos.
  • Es más fácil garantizar que todas las acciones estén vinculadas a una derivación e intervención específicas.

Contras

  • Podría llegar a ser grande dependiendo del número de acciones del programa de referencia.
  • Es más difícil analizar las intervenciones por separado sin datos de derivación.

Opción 2: Varias tablas de hechos (Fact_Interventions, Fact_Referrals, Fact_ReferralPrograms, Fact_ReferralActions)

Esto sigue un enfoque más tradicional, separando los eventos comerciales medibles.

Esquema

  • Fact_Interventions (Granularidad: Una fila por intervención)

    • IntervenciónKey
    • ChildKey (Llave Infantil)
    • InterventionTypeKey
    • StartDateKey
    • EndDateKey
  • Fact_Referrals (Granularidad: una fila por referencia)

    • Clave de referencia
    • IntervenciónKey
    • ReferralTypeKey
    • StartDateKey
    • EndDateKey
  • Fact_ReferralPrograms (Granularidad: Una fila por programa de referencia)

    • ReferralProgramKey
    • Clave de referencia
    • ProgramTypeKey
    • StartDateKey
    • EndDateKey
  • Fact_ReferralActions (Granularidad: una fila por acción en un programa)

    • ReferralActionKey
    • ReferralProgramKey
    • ReferralActionTypeKey
    • Completado (Sí/No)
  • Dimensiones comunes

    • Dim_Children
    • Dim_Calendar
    • Dim_InterventionTypes
    • Dim_ReferralTypes
    • Dim_ReferralProgramTypes
    • Dim_ReferralActions

Pros

  • Análisis más flexible: puede analizar solo las intervenciones, solo las derivaciones, etc.
  • Es más fácil realizar un seguimiento de la participación en cada etapa de forma independiente.

Contras

  • Se requiere un filtrado más complejo para garantizar que las referencias solo aparezcan si existe una intervención.
  • Es posible que necesite medidas de DAX para relacionar datos en varias tablas de hechos, lo que puede afectar al rendimiento.

Recomendación

  • Si su objetivo principal es realizar un seguimiento de la finalización de las acciones de referencia y siempre necesita analizar en el contexto completo (intervención → referencia → programa → acción), la opción 1 (tabla de datos única) es probablemente la mejor opción.
  • Si necesita un análisis más granular en cada nivel de forma independiente, la opción 2 (varias tablas de hechos) es más flexible, pero requiere un modelado DAX sólido.

View solution in original post

4 REPLIES 4
Syndicate_Admin
Administrator
Administrator

Hola @scoobymoo1 ,

Su escenario es bastante complejo debido a la naturaleza jerárquica de las intervenciones, referencias, programas y acciones. Vamos a desglosarlo y explorar el mejor enfoque.

Consideraciones clave:

  1. Dependencia jerárquica: Un niño primero debe tener una intervención antes de obtener una referencia, luego un programa de referencia y finalmente acciones dentro de ese programa.
  2. Estructura de hechos-dimensiones: Idealmente, las tablas de hechos almacenan eventos medibles, mientras que las tablas de dimensiones proporcionan atributos descriptivos.
  3. Filtrado y agregación: debe ser capaz de analizar las intervenciones y ver todas las referencias, programas y acciones relacionadas.

Opción 1: Tabla de datos única (Fact_ReferralProgramActions)

Este es el enfoque que propuso: tener una tabla de hechos central con cada paso anterior como una dimensión.

Esquema

  • Fact_ReferralProgramActions (Granularidad: una fila por acción del programa de referencia)

    • ReferralProgramActionKey (PK)
    • ChildKey (Llave Infantil)
    • DateKey
    • Clave de referencia
    • ReferralProgramKey
    • ReferralActionTypeKey
    • Completado (Sí/No)
  • Dim_Children (Datos relacionados con niños)

  • Dim_Calendar (Fechas para el análisis)

  • Dim_Interventions (InterventionKey, ChildKey, Type, Start, End)

  • Dim_Referrals (ReferralKey, InterventionKey, Type, Start, Fin)

  • Dim_ReferralPrograms (ReferralProgramKey, ReferralKey, Tipo, Inicio, Fin)

  • Dim_ReferralActions (ReferralActionTypeKey, ReferralProgramKey, nombre de la acción)

Pros

  • Estructura simple, filtrado más fácil.
  • El rendimiento de las consultas puede ser mejor, ya que todo está en una tabla de hechos.
  • Es más fácil garantizar que todas las acciones estén vinculadas a una derivación e intervención específicas.

Contras

  • Podría llegar a ser grande dependiendo del número de acciones del programa de referencia.
  • Es más difícil analizar las intervenciones por separado sin datos de derivación.

Opción 2: Varias tablas de hechos (Fact_Interventions, Fact_Referrals, Fact_ReferralPrograms, Fact_ReferralActions)

Esto sigue un enfoque más tradicional, separando los eventos comerciales medibles.

Esquema

  • Fact_Interventions (Granularidad: Una fila por intervención)

    • IntervenciónKey
    • ChildKey (Llave Infantil)
    • InterventionTypeKey
    • StartDateKey
    • EndDateKey
  • Fact_Referrals (Granularidad: una fila por referencia)

    • Clave de referencia
    • IntervenciónKey
    • ReferralTypeKey
    • StartDateKey
    • EndDateKey
  • Fact_ReferralPrograms (Granularidad: Una fila por programa de referencia)

    • ReferralProgramKey
    • Clave de referencia
    • ProgramTypeKey
    • StartDateKey
    • EndDateKey
  • Fact_ReferralActions (Granularidad: una fila por acción en un programa)

    • ReferralActionKey
    • ReferralProgramKey
    • ReferralActionTypeKey
    • Completado (Sí/No)
  • Dimensiones comunes

    • Dim_Children
    • Dim_Calendar
    • Dim_InterventionTypes
    • Dim_ReferralTypes
    • Dim_ReferralProgramTypes
    • Dim_ReferralActions

Pros

  • Análisis más flexible: puede analizar solo las intervenciones, solo las derivaciones, etc.
  • Es más fácil realizar un seguimiento de la participación en cada etapa de forma independiente.

Contras

  • Se requiere un filtrado más complejo para garantizar que las referencias solo aparezcan si existe una intervención.
  • Es posible que necesite medidas de DAX para relacionar datos en varias tablas de hechos, lo que puede afectar al rendimiento.

Recomendación

  • Si su objetivo principal es realizar un seguimiento de la finalización de las acciones de referencia y siempre necesita analizar en el contexto completo (intervención → referencia → programa → acción), la opción 1 (tabla de datos única) es probablemente la mejor opción.
  • Si necesita un análisis más granular en cada nivel de forma independiente, la opción 2 (varias tablas de hechos) es más flexible, pero requiere un modelado DAX sólido.

¡Gracias, creo que iré con la única tabla FACT y espero que funcione esta vez!

Syndicate_Admin
Administrator
Administrator

Te sugiero que pruebes tu idea y veas si obtienes los resultados de medición correctos que estás buscando. Creo que la gente de aquí puede darte al menos 3-4 variaciones de un diseño (y algo de experiencia con algunas cosas que han fallado). Pero, hasta que no pruebes algo, nunca lo sabrás.

Gracias, lo intentaré. ¡Solo me preocupa pasar demasiado tiempo construyendo modelos fallidos! ¡Ya he creado un par de fracasos!

Helpful resources

Announcements
Las Vegas 2025

Join us at the Microsoft Fabric Community Conference

March 31 - April 2, 2025, in Las Vegas, Nevada. Use code MSCUST for a $150 discount!

FebPBI_Carousel

Power BI Monthly Update - February 2025

Check out the February 2025 Power BI update to learn about new features.

March2025 Carousel

Fabric Community Update - March 2025

Find out what's new and trending in the Fabric community.

Top Solution Authors
Top Kudoed Authors