Creation d'une table TEMPS

[bibouex]

Bonjour,

Je suis sur un projet de mise en place d'un système décisionnel et j'aurais besoins de conseil au niveau de la modélisation des dates dans mon DW.

Je veux constituer une base pour gérer les incidents de paiements des entreprises.
Je voudrais pouvoir, avec SQL sevrer, faire des analyses par période, par secteur professionnel et par secteur géographique !
Pour la partie Secteur professionnel, j'ai crée une dimension avec le code NAF (qui représente les différents secteurs d'activités d'une entreprise), pour la table [GEOGRAPHIE] j'aurais besoin de conseil pour la modélisation...

Mais surtout pour le moment pour la ou les tables de DATE... J'aimerais connaitre la meilleur façon dans mon cas de modéliser les données toujours dans un contexte de schéma en étoile.

Je suis tombé sur un article sur la création d'une table DATE par ElSuket
http://blog.developpez.com/elsuket/p...ates/#more7872

Il m'avait notamment aidé pour supprimer les doublons pour ma table ENTREPRISE.

Est ce que cela peut être géré directement avec SSRS ou SSAS ??

Je m'explique, j'ai dans mon cas un table ENTREPRISES qui contient les champs actuellement :

[Id_entreprise]
,[Id_Naf]
,[Siren]
,[Nom]
,[Adresse]

J'ai une deuxième table INCIDENTS qui contient les champs :

[Id_incident]
,[Id_entreprise]
,[Id_naf]
,[Id_type]
,[Id_geographie]
,[Id_temps]
,[Montant]
,[Date_info]
,[Date_pub]
,[Date_maj]
,[Origine]
,[Reference]


Donc j'ai bien mis mes PK et FK entre toutes les tables (qui sont toutes modifiables si jamais vous voyez un truc qui va pas...)
Ma table des faits est INCIDENTS.

A la base, j'ai un fichier txt que j'ai importé dans sa totalité dans une table temporaire. Ce fichier est constitué de la manière suivante :

[Id_Temp]
,[Siren]
,[Nom]
,[Adresse]
,[Cp]
,[Ville]
,[Type]
,[Montant]
,[Date_info]
,[Date_pub]
,[Date_maj]
,[Origine]
,[Reference]
,[Naf]

Un exemple de données :

000000001, entreprise 1 , adresse1, CP1, ville1, type1, 10/03/2011, 100, A, 458653, 1111Z
000000001, entreprise 1 , adresse1, CP1, ville1, type1, 11/03/2011, 200, B, 456445384874, 1111Z
000000001, entreprise 1 , adresse1, CP1, ville1, type2, 13/06/2011, 50, A, 456986, 1111Z
000000002, entreprise 2 , adresse2, CP2, ville2, type2, 20/02/2011, 158, A, 45645768, 1112Z
000000002, entreprise 2 , adresse2, CP2, ville2, type1, 20/02/2011, 300,B, 456454654, 1112Z
...

La suite c'est la même avec des centaines de milliers de lignes...

Le diagramme en pièce jointes est par nécessairement bon voir même pas bon du tout pour certaines dimension car je ne sais pas comment les traiter.

Merci de votre aide

Cordialement,
Bibouex

[bibouex]

Je me permet de relancer mon post car j'ai l'impression qu'il s'en va aux oubliettes

Personne ne peut me donner un petit conseil ?

Perso, j'ai donc suivi l'aide d'ELSUKET pour la création d'une table [DATES], j'ai donc dans ma BDD, cette nouvelle table rattachée à [INCIDENTS].
Et j'ai l'impression que j'ai pas besoin d'aller plus loin pour cette table... Mes requetes fonctionnent lorsque que je demande a avoir les incidents de paiements de tel date à tel date !

Je n'ai aucune visibilité sur la suite pour l'utilisation de SSAS ou SSRS donc je me demande si c'est bon d'avoir fait ca ou pas ?

Petit ajout du coup, pour la table "GEOGRAPHIE" je voulais faire une seul table regroupant {Pays, Region, Dept, Code_post, ville}, mais ne faut(il pas mieux tout séparer et avoir un table [PAYS], une autre [REGION], [DEPT],...

Merci de votre aide.

Cordialement
Bibouex

[Jinroh77]

Euh.... elle est où la question ?
C'est sur la table temps où l'ensemble du schéma de manière générale ?

[bibouex]

Envoyé par Jinroh77

Euh.... elle est où la question ?
C'est sur la table temps où l'ensemble du schéma de manière générale ?

lol, mes questions se finissent par un point d'interrogation je crois, non ?

Enfin, merci pour la question auquel je vais répondre en regroupant mes questions et mes demandes d'aide :

j'aurais besoins de conseil au niveau de la modélisation des dates dans mon DW

J'aimerais connaitre la meilleur façon dans mon cas de modéliser les données toujours dans un contexte de schéma en étoile ?

Est ce que cela peut être géré directement avec SSRS ou SSAS ??

Pour la fin, c'était pour donner un aperçu visuel, de ce que j'avais fait...

Le diagramme en pièce jointes est par nécessairement bon voir même pas bon du tout pour certaines dimension car je ne sais pas comment les traiter.

Personne ne peut me donner un petit conseil ?

Je n'ai aucune visibilité sur la suite pour l'utilisation de SSAS ou SSRS donc je me demande si c'est bon d'avoir fait ca ou pas ?

Et oui, je cherche à avoir des conseils pour la table [TEMPS] qui s'appelle mnt [DATES] qui comme je le disais dans mon dernier post, me semble meilleur que l'approche que je voulais faire à la base lorsque l'on regarde mon schéma...
Du coup je demande validation de ce que j'ai fait et une aide sur la construction de la/ou des dimension(s) géographique.

Désolé mais c'est pas facile d'expliquer le tout en quelques lignes...Si vous voulez des informations supplémentaire, je suis tout ouïe

Mais merci d'avoir pris le soin de me lire

[Jinroh77]

C'est juste qu'il y avait beaucoup de choses et je ne vois pas trop par où commencer.
On va essayer...

La plupart des données d'un entrepôt décisionnel ont une relation avec une notion de date. Afin de faciliter les requêtes utilisant cette données à différents niveaux, on crée quasi-systématiquement une table de Date.

Que doit-elle contenir ?
l'ensemble des attributs dont vous aurez besoin dans vos requêtes, plus les attributs permettant de définir les liaisons entre ceux-ci.

cad ?
Pour optimiser les choses, vous ne stockez pas une date au format DATE ou DATETIME mais plutôt un INT qui aura au choix un format incrémentiel ou un format ISO (20110725).
c'est dans ce format que vous renseignerez vos dates dans toutes les tables de l'entrepôt.

Ensuite dans votre table de dimension DATE, vous avez donc ce champ qui représentera votre PK, la clef de jointure avec toutes les tables de faits ou autre. Puis vous ajoutez les autres colonnes dont vous aurez besoin comme par exemple :
- la date au format DATE
- le numéro du jour dans la semaine : 4
- le numéro du mois dans l'année : 201107
- le numéro du mois :07
- le libellé du mois : Juillet
- le libellé du mois dans une autre langue
- l'année : 2011
- le numéro de la semaine : 37
- le numéro de la semaine dans l'année : 201137
- un indicateur de jour férié
etc.
Bref, tout ce dont vous aurez besoin.

Ensuite, votre cube SSAS pourra utiliser aisément cette table pour en faire une dimension, et vos requêtes SQL interrogeant votre base pour la restitution dans SSRS pourra également en tirer fortement partie.


Avec cela, dans votre schéma, il vous reste à modifier le format des colonnes de dates votre table de faits en INT et de lier celles-ci à la table de date.

[bibouex]

Merci beaucoup #Jinroh77 de votre aide

Je vais suivre vos conseils et je vous tiens au courant très rapidement des évolutions apportées.

[bibouex]

Juste une autre question #Jinroh77

Pour tout ce qui concerne les données géographique d'une entreprise, à savoir le pays, la région, le code région, le departement, le code département, la ville et le Code postal, il faut tout mettre dans une table ou plutot séparer les éléments en constituant une table pour chaque chose ?

Une table [Pays], une autre [Region], [Departement], [VILLE] le tout par des INT sur chaque table ?!

Enfin je suppose que la deuxième option est bien meilleur en terme de performance...

Merci

[Jinroh77]

Les avis divergent là-dessus...

De toute manière, oui il faut une table pour la géographie.
Maintenant entre faire 1 table géographie avec dedans : ville, département, région, pays ou une table pour chaque niveau de la géographie, je partirai plus sur 1 table globale.
Cella permet une lecture plus aisée des données, la jointure nécessite un peu plus de code (on peut aussi utiliser une vue au-dessus des tables mais bon...)

Ensuite, avez-vous uniquement des données géographiques en France ou sur l'ensemble de l'Europe, du monde ? La question se repose dans ces cas.