Discussion :

[andy888]

Bonjour,
Ayant toujours travaillé avec des bases de données transactionnelles, j'ai du mal a assimiler le concept de base de données multidimensionnelles...

voici l'existant:
on cherche à calculer le Coût des incidents mensuel pour cela j'ai comme table de dimensions:

Dim Temps
ID_temps
granularité jour

DimLieu ( Lieu de l'incident, une ville par exemple )
ID_lieu
Nom_Lieu

Dim_Incident
ID_Incident
Code_Incident


Table_De_Fait_Incident
ID_Temps, ID_Lieu, ID_Incident ( FK)
(Mesure) Nombre_des_incident ( Mensuel)
(Mesure ) Cout_des_incidents (Mensuel )

Fichier Source ( xls)
Code_Incident || Date_Ouverture || Date_Cloture || Cout || Lieu

1-Est ce qu'il n'y aurai pas de dependance fonctionnelle entre mes dimensions ?
2-Comment faire pour calculer le cout, puisque le cout unitaire n'apparait pas sur la table de fait ?
3-A quel niveau se fera le calcul des indicateurs ( mesures ) mensuelle ? analyse ? Reporting ? Integration ?

Merci

[grodeg]

tu es toujours dans le besoin sur le sujet

[doc malkovich]

hello

A ce que je comprends ta table de faits est agrégée, et non au détail.

1/ tu veux dire quoi par dependance fonctionnelle ?
2/ le cout = la somme des couts unitaires en source
3/ à l'intégration et aussi en reporting

A+

[IMPRO]

Bonjour,
cette modélisation, à mon sens, est fausse.
parce que la 2ème étape de la démarche de conception dans la modélisation multidimensionnelle est la définition du grain. Or, il est mal définit dans ce cas, car le niveau le plus bas de la dimension Temps est le jour mais un tuple dans la table de fait correspond au mois (Cout_des_incidents)
donc de préférence, c'est enregistré les incidents un par un, et comme sa tu pourra assurer un suivi des couts par jour, et tu enlevés la mesure (Nombre_des_incident) car la fonction COUNT sur les tuples de la table de fait te donnera le nombre d'incident.
Et si tu veux garder tes mesures, il faut changer le grain de la dimension Temps et de le rendre mensuel.

[doc malkovich]

Bien vu pour le jour

Par contre pour le détail des incidents il faut voir. C'est vrai qu'il est nécessaire, mais il est conseillé d'avoir un modèle en étoile avec des données agrégées pour des questions de performance !

[IMPRO]

Oui c'est bien d'agréger mais il faut faire attention aux grains des tables de faits et dimensions.

Et Ralf Kimball recommande, dans son livre THE DATAWAREHOUSE TOOLKIT [1], d’enregistrer les données dans un niveau atomique, pour des recherche poussées de datamining.

[1] Kimball, Ross, M., 2002. The Data Warehouse Toolkit. WILEY, United States of America.

[doc malkovich]

Oui, c'est ce que je disais avec "c'est nécessaire"
Mais il dit aussi de faire des tables agrégées à côté.