intevalmatch successifs

[flochi75]

bonjour à toutes et à tous,

j'ai un problème de calendrier que je vais tenter de vous exposer clairement.

je veux calculer un nb de journées de présence, sur des dossiers sur plusieurs années.

j'ai donc construit un calendrier maitre, avec un interval match sur les dates de mouvements du dossier :

CAL_CHAMBRES_BASE:

load IterNo() + num('01/01/2008')-1 as CAL_DATE ,

  month(IterNo() + num('01/01/2008')-1) as CAL_MOIS,

  Year(IterNo() + num('01/01/2008')-1)as CAL_ANNEE,

  day(IterNo() + num('01/01/2008')-1) as CAL_JOURS

  AutoGenerate (1)

while 

  IterNo() + num('01/01/2008')-1 <= num(Today());

REF_CHAMBRE:

SQL SELECT

...

NUMEDOS,

NUMEDOS as CLEGIR,

    NUMEDOS as CLEDMT,

DENTSJL,

DSORSJL,

...

FROM

  SIL.NCV_PRS:

CAL_CHAMBRES:

NoConcatenate LOAD * Resident CAL_CHAMBRES_BASE;

IntervalMatch (CAL_DATE) load DENTSJL, DSORSJL Resident REF_CHAMBRE ;

ensuite, j'ai aussi d'autre dates dans 2 autres tables concernant une évolution de type de PeC et d'une évolution de Tarifs

ces dates sont toutes différentes et ne sont pas liées entre elle :

GIR:

SQL SELECT CODEGIR,

    DAEFGIR,

    DAFIGIR,

       NUHOGIR as CLEGIR

FROM MAL.GIR;

DMT:

SQL SELECT COTASE,

    DATESE,

    DATSSE,

        NUHOSE as CLEDMT

FROM MAL.SEJ;

y a t'il possibilité de lier tous ces intervalles au calendrier, pour pouvoir compter sur une année donnée, le nb de journées de présence par type de PEc et par tarif ?

merci pour votre aide.

Florent

[flochi75]

ci-joint l'appli,

qui me donne en plus des résultats incohérents, lorsque je filtre sur les codes départements...

[flochi75]

elle n'est pas passée, je refais un envoi...

[sfatoux72]

Bonjour Florent,

Avant d'essayer de comprendre ton problème d'intervalmatch, voici déjà la raison des incohérences.

ATTENTION, lorsque tu utilises un AGGR il doit contenir les dimension que tu as besoin pour tes calculs (ici

NUHOHO), mais également les dimensions que tu utilises dans ton graphe (ici DEPT) afin que l'AGGR puisse s'intégrer parfaitement dans ton graphe sans incohérence.

Pour de meilleur performance, évite au maximum les dimensions calculées et les count(DISTINCT if...)

Pour ce petite tableau, j'utiliserai directement la dimension DEPT (le filtre TYPE_UF = 'EHPAD' est réalisé dans l'expression) et l'expression suivante :

sum(aggr(count({$<TYPE_UF={'EHPAD'}>} DISTINCT CAL_DATE),NUHOHO, DEPT))

[flochi75]

Merci Sébastien,

j'ai toujours du mal avec les aggr...

dans l'expression, on n'a pas besoin du set sur le type UF, car il est dans la dimension ; ceci dit, ça fonctionne parfaitement.

Par contre, j'ai un delta entre le nb de journées par dépt et par UF d'EHPAD (avec la même formule et le même if type_UF dans la dimension)

[flochi75]

J'ai trouvé pour le delta : pour certains NUHOHO, plusieurs DEPT étaient existant à tord : les obsolètes et l'actuel, du coup, les mêmes journées étaient additionnées par code DEPT.

j'ai trouvé le champ me permettant de ne charger que les DEPT  "valides".

Je retombe sur mes pieds 😉

me reste le pb des "périodes"...

[sfatoux72]

Cool

Est-ce que CLEDOS, CLEGIR, CLEDMT sont toujours identiques ?

Si oui, pourrait-on utiliser qu'un seul champ CLEDOS qui ferait le lien entre les tables ?

[flochi75]

elles correspondent à un champ commun pour joindre différentes tables.

CLEDOS m'a permis de remonter le mode de sortie du dossier, j'y ai fait un left join.

pour résumer : chaque table non concaténée mais avec un champ clé commun possède par dossier des intervalles de dates différentes : mouvements (REF_CHAMBRE), position tarifaire (DMT), et GIR (GIR)

ce sont des séjours courant sur plusieurs années, et ce qui m'est demandé, c'est, pour 1 années, le Nb de jours de présence par position tarifaire et par GIR...

[flochi75]

c'est de toute façon exactement le même champ (valeurs de NUHOHO en l'occurence)

pour le modèle de donnée, techniquement c'est possible, pour le reste (la solidité des calculs attendus et la stabilité du système), j'attends humblement ton avis  ;-))

[sfatoux72]

J'essayerai d'arriver au résultat suivant:

En partant de tes table de base (bleu), je commencerai par créer la table Link dans laquelle il y aura un champ CLELINK pour chaque combinaison existante de CLEDOS, CODEGIR et COTAS:

• De la table GIR, je récupère les champs CLEGIR as CLEDOS et CODEGIR
• De la table DMT, je récupère les champs CLEDMT as CLEDOS et COTASE
• De la table REF, je récupère CLEDOS qui ne figure pas déjà dans Link

Création de la table IntervalLink :

• De la table GIR, je récupère les champs CLELINK, DateDébut, DateFin et 'GIR' as Type
• De la table DMT, je récupère les champs CLELINK, DateDébut, DateFin et 'DMT' as Type
• De la table REF, je récupère CLELINK, DateDébut, DateFin et 'REF' as Type

Utilisation de IntervalMatch pour lier IntervalLink à CAL_CHAMBRE et joindre le résultat à IntervalLink.