Discussion :

[phili_b]

Bonjour,

J'ai un souci d'entité non obligatoire. Je viens d'hériter d'un modèle décisionnel(beaucoup trop dénormalisé à mon goût mais là n'est pas le problème) dont on s'est aperçu après coup que le client voulait absolument voir ses données même si certaines ne sont pas renseignées.

Soit l'exemple suivant:
Entité 1 : Ville
Entité 2 : Société
Entité 3 : Nom du responsable.
Entité 4 : Calendrier

L'association reliant ces 4 entités est le chiffre d'affaire par exemple.

Donc ça nous fait une table de fait FAIT_CA
dont la PK = id_ville, id_société, id_nom, id_date
et l'indicateur CA du jour

Donc le client nous demande que id_nom et id_date puissent être non renseignée

• pour pouvoir voir ces données provenant de la base transactionnelle
• pour pouvoir voir ces donnés en faisant un lien avec d'autres données sans la date renseignée par exemple.

Pour l'instant je n'ai trouvé que 2 solutions pas propres que je ne souhaiterais pas mettre en place:

• enlever la clé primaire
• remplir par une valeur bidon id_date ou id_nom, pour que la clé primaire fonctionne, et indiquer avec un autre attribut que la donnée est bidon.

Petit indication. Le modèle transactionnel dont proviennet les données est un modèle de données certes relationnelles mais qui simule un workflow.
Ville-> Ville, Société -> Ville, Société, nom du responsable -> Ville, Société, nom du responsable, date de validation

Dans la majeure partie des cas je suis pour bien normaliser et mettre des clés primaire mais ce n'est pas un argument pour les utilisateurs finaux évidemment.

Merci de votre aide
PS: exemple fictif mais je ne peux donner d'exemple reconnaissable

[Antoun]

ton "modèle décisionnel" est une étoile ? quel outil décisionnel utilises-tu dessus ?

il faut dans tous les cas différencier l'interrogation du stockage...

- ce que le client demande, ça n'est pas qu'il n'y ait pas de date ou de responsable renseigné, mais de pouvoir obtenir un total "toutes dates" et/ou "tous clients"

- a priori, la réponse à ces deux interrogations s'obtient par une agrégation sur ta table de faits avec sa PK complète

- si tu veux stocker les agrégats plutôt que de les calculer à la volée, ça ne répond donc qu'à une question de perf et non à un besoin fonctionnel

Pour ce faire, tu as deux solutions :

- soit tu fais tes tables d'agrégats à part, avec une colonne de moins et une PK complète ; il te faut dans ce cas un script ou un outil (par ex. sous BO, c'est le @aggregate_aware) qui décide s'il faut requêter la table de fait ou l'une des tables d'agrégats

- l'alternative, c'est effectivement des choisir des valeurs bidon (on dit plutôt "neutres") pour représenter le "toutes dates" et le "tous responsables" ; a priori c'est plus facile à mettre en place et à exploiter, mais ça suppose que tu pré-calcules toutes les combinaisons possibles entre les positions agrégées (avec un GROUP BY... WITH CUBE par exemple)

La première solution est appelée "étoile à coeur multiple" et la seconde "étoile à coeur multi-niveaux".

[phili_b]

Merci

ton "modèle décisionnel" est une étoile ? quel outil décisionnel utilises-tu dessus ?

Oui c'est une étoile. On n'utilises un générateur de rapport pas spécifiquement décisionnel (jasper)

il faut dans tous les cas différencier l'interrogation du stockage...

c'est une très bonne remarque mais....

- ce que le client demande, ça n'est pas qu'il n'y ait pas de date ou de responsable renseigné, mais de pouvoir obtenir un total "toutes dates" et/ou "tous clients"

- a priori, la réponse à ces deux interrogations s'obtient par une agrégation sur ta table de faits avec sa PK complète

- si tu veux stocker les agrégats plutôt que de les calculer à la volée, ça ne répond donc qu'à une question de perf et non à un besoin fonctionnel

Le problème est que j'hérites d'un modèle avec une table de fait sans agrégation !!! De plus le client veut connaître les détails des dimensions associées à chaque valeur unitaire dans la table de fait. Autrement dit l'apport de performance ne se fait que sur la materialisation des jointures complexes provenant du modèle transactionnel mais pas du tout sur l'agrégation. Il y a néanmoins une agrégation dans une 2é table de fait pour pouvoir agréger de jour à mois.

- soit tu fais tes tables d'agrégats à part, avec une colonne de moins et une PK complète ; il te faut dans ce cas un script ou un outil (par ex. sous BO, c'est le @aggregate_aware) qui décide s'il faut requêter la table de fait ou l'une des tables d'agrégats

Je connais très bien BO mais malheureusement on n'utilise pas BO. Mais pour garder ta logique il faudrait avoir autant de table de fait que de niveau d'agrégation (base de principe de tout projet décisionnel) mais ça impliquerait de modifier complétement ce modèle sur lequel on développe. Et surtout je ne suis pas sûr que le client ne sorte de son chapeau une nouvelle colonne non obligatoire. Jamais vu un problème de définition de périmètre tel.

- l'alternative, c'est effectivement des choisir des valeurs bidon (on dit plutôt "neutres") pour représenter le "toutes dates" et le "tous responsables" ; a priori c'est plus facile à mettre en place et à exploiter, mais ça suppose que tu pré-calcules toutes les combinaisons possibles entre les positions agrégées (avec un GROUP BY... WITH CUBE par exemple)

Je viens de me renseigner sur ces fonctions certes très puissantes mais qui ne me seront pas utiles dans ce cas vu qu'il n'y pas d'agrégation (ou presque : au mois) mais le problème resterait entier pour les jours.
Mais comment générer ces valeurs intérmédiaires ? Ah je viens de trouver une idée pour les générer, ce principe pourrait fonctionner avec n'importe quelle table de réference:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
select a.id_ville,a.id_societe,a.id_nom,b.id_date
FROM 
(select id_ville,id_societe,id_nom, rownum numligne FROM Ma_Table_de_Fait)
LEFT JOIN
(select id_date, rownum numligne FROM Ma_Table_de_Temps)
ON a.numligne=b.numligne

avec NOT EXISTS ou un NOT IN des dates déjà inserées pour ce triplet si besoin. et puis un case when pour générer ma colonne m'indiquant si c'est une colonne neutre.

La première solution est appelée "étoile à coeur multiple" et la seconde "étoile à coeur multi-niveaux".

ok je le notes.

Ta réponse m'a permis de mieux cerner et d'avancer dans ce que je voulais mais je crains au vu de ta réponse qu'il n'y ait dont pas de solution miraculeuse MCD->MPD. Seulement une table de fait par agrégation, ou virer les PKs, ou mettre des valeurs neutres.

edit: mais c'est sûr qu'une table de fait sans agrégation ça n'aide pas, alors qu'avec agrégation on n'a beaucoup plus de chance de remplir les dimensions.

[Antoun]

Merci
Je connais très bien BO mais malheureusement on n'utilise pas BO. Mais pour garder ta logique il faudrait avoir autant de table de fait que de niveau d'agrégation (base de principe de tout projet décisionnel)

Pas du tout. Si la table d'agrégats existe pour le niveau demandé, tant mieux, sinon on agrège à la volée à partir de la table de niveau immédiatement inférieur.

Je viens de me renseigner sur ces fonctions certes très puissantes [WITH CUBE] mais qui ne me seront pas utiles dans ce cas vu qu'il n'y pas d'agrégation (ou presque : au mois) mais le problème resterait entier pour les jours.

L'idée serait précisément de générer les agrégats en utilisant le WITH CUBE.

edit: mais c'est sûr qu'une table de fait sans agrégation ça n'aide pas, alors qu'avec agrégation on n'a beaucoup plus de chance de remplir les dimensions.

Est-ce que tu as la main sur l'alimentation de ton étoile, ou bien tu ne peux que la requêter telle qu'elle est ?

[phili_b]

J'ai la main sur l'alimentation mais c'est un ETL (plus exactement un ELT).

[Antoun]

Donc tu as tout ce qu'il faut pour alimenter tes positions neutres avec un WITH CUBE (ou tout autre système).

btw, qu'est-ce qu'un ELT par rapport à un ETL ?

[phili_b]

Donc tu as tout ce qu'il faut pour alimenter tes positions neutres avec un WITH CUBE (ou tout autre système).

J'ai regardé sur internet des exemples qui m'ont l'air puissant, mais je n'ai pas compris comment ça répondrait à ma question ?
Cette commande semble générer les agrégations pour les dimensions manquantes, mais ça ne me génére pas les dimensions manquantes.
Peux-tu me donner un exemple. J'ai l'impression que ça ne réponds pas à mon problème.

btw, qu'est-ce qu'un ELT par rapport à un ETL ?

Les diffèrences sont les suivantes:

• un ETL utilise son propre moteur de données
• un ELT produit du code natif pour chaque SGBD

voir http://www.systemeetl.com/ETL_ELT_ETLT.htm pour plus d'information.

edit 11h:L' interêt de l'ELT dans ce cas est que les colonnes sont écrites en SQL. On peut même dans certains cas écrire des requêtes complète en SQL mais l'intégrer proprement au reste de l'ELT. Et donc utiliser le WITH CUBE ce qu'on n'aurait pas pu faire dans un ETL classique.

[Antoun]

En fait, quand tu dis "pas d'agrégat", est-ce que tu veux dire qu'il n'y a pas d'indicateur numérique du tout, ou bien qu'ils ne sont jamais agrégés ?

[phili_b]

En fait, quand tu dis "pas d'agrégat", est-ce que tu veux dire qu'il n'y a pas d'indicateur numérique du tout, ou bien qu'ils ne sont jamais agrégés ?

Il y a des indicateurs numériques mais ils ne sont pas agrégés.

[phili_b]

Au fait: merci Antoun j'ai résolu mon mon problème à partir de ton idée, ceci en créant des valeurs neutres incrémentales à partir des fonctions analytiques, même si je n'agrèges pas dans la table cible. ça m'a permis de ne pas remettre trop en cause le modèle de données en cours d'utilisation.

L'idée serait précisément de générer les agrégats en utilisant le WITH CUBE.

En gros j'ai fait, sous oracle, sachant que ma clé primaire est (ID_VILLE,ID_SOCIETE,ID_NOM,ID_DATE) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
INSERT INTO MA_TABLE_CIBLE
(ID_VILLE,ID_SOCIETE,ID_NOM,ID_DATE,ID_DATE_NULLABLE)
SELECT a.id_ville,a.id_societe,a.id_nom,nvl(a.id_date,b.id_date),id_date
FROM 
( SELECT id_ville,id_societe,id_nom, id_date,
  row_number() OVER (
    PARTITION BY id_ville,id_societe,id_nom 
    ORDER BY id_ville,id_societe,id_nom) numligne 
  FROM Ma_Table_de_Fait)
a INNER JOIN
( SELECT id_date, rownum numligne FROM Ma_Table_de_Temps)b
  ON a.numligne=b.numligne

Quand ID_DATE_NULLABLE est null c'est que ID_DATE est une valeur "bidon" mais ne faisant pas sauter la PK. Dans le cas contraire la colonne ID_DATE de la clé primaire se remplit normalement de la donnée source.

et ainsi de suite s'il y a plusieurs colonnes ayant le même problème.