Alimenter la dimension Temps => Schéma en Flocon

[info3licen]

Salut
J'espère que je poste dans le bon forum

Voila Mon probleme :

je fait une modélisation multidimensionnelle en utilisant le modèle en Flocon, donc j'ai une Table de dimension Temps
TD_Temps(Date,mois,annee)
Et puisque c'est en flocon alors j'aurais 3 tables :
Les deux autres c'est :
TD_Mois(mois,annee)
TD_Annee(annee)

Pour alimenter la Table de dimension Temps : il faut que j'alimente TD_annee au début puis TD_Mois c'est apres que j'alimente TD_Temps

Donc j'ai alimenté TD_annee normale avec une requête SQl mais lors de l'alimentation de TD_Mois j'aurais l'erreur :
"Violation de la contrainte Primary key" => Impossible d'inséré

Bon c'est une erreur logique!

Moi ce que je voudrais savoir est-ce que il y a une solution pour ce genre de probleme?!
Puisque la dimension Temps est utilisé souvent, Donc est-ce que sa existe une chose qui peut réglé ce genre de probleme ?!

Voila, jesper que c un peu claire

Je vous remercié d'avance

[Ecosmose]

Salut,

Je pense que ton problème est purement lié aux contraintes logiques de l'unicité de ta clef primaire. Dans une année il y a douze mois. Si tu as décidé d'inséré un mois de plus il faut t'assurer qu'il n'y a pas un doublon.

Comme c'est une erreur assez classique, je suppose que tu as du vouloir insérer un mois qui existait déjà...du style Janvier 2010 et Janvier 2011 ... puisque le mois de Janvier existe déjà pour 2010 , il ne peut pas être inséré pour 2011.

Il te faut donc t'assurer d'une unicité dans la table des mois en combinant l'ID de l'année et le mois (les ID de la Primary Key du moi avec celui de la Foreign Key de l'année par exemple) (tu peux aussi utiliser cetrte unicité comme clef primaire ) et non pas seulement l'unicité sur le champ métier du métier (que tu as du placer certainement que sur le numéro du mois comme 1 = Janvier).

J'ai bon ?

[info3licen]

Merci Ecosmose pour votre réponse

Comme c'est une erreur assez classique, je suppose que tu as du vouloir insérer un mois qui existait déjà...du style Janvier 2010 et Janvier 2011 ... puisque le mois de Janvier existe déjà pour 2010 , il ne peut pas être inséré pour 2011.

Oui c'est le cas!

Il te faut donc t'assurer d'une unicité dans la table des mois en combinant l'ID de l'année et le mois (les ID de la Primary Key du moi avec celui de la Foreign Key de l'année par exemple) (tu peux aussi utiliser cetrte unicité comme clef primaire ) et non pas seulement l'unicité sur le champ métier du métier (que tu as du placer certainement que sur le numéro du mois comme 1 = Janvier).

Vous voulez dire que dans ma table Mois je combine (Mois, Annee) Comme clé primaire ?!

Si elle ne pose pas de probleme sur mon schéma en flocon je le ferais sans probleme

Merci

[Feyrehr]

Bonjour,
La modélisation en flocon sur une table de temps n'a aucun interet, sinon celui de se compliquer la vie.
Je te conseille de modéliser en étoile, et de créer une seule table MesDates avec les infos optimisées :
date, jour semaine, n° de semaine, année, mois, jour dans le mois, jour ouvré, jour férié france, pleine lune, coéfficent de marée, etc, etc. (j'ai peut-être exagéré sur les champs, mais n'hésite pas à renseigner toute info utile).
Tu la remplis à la main, pour 100 ans si nécessaire. C'est fait une fois pour toutes et on n'y revient pas.

[Ecosmose]

Bonjour Info3licien,

Oui, pardon pour le tutoiement pressé,

Concernant les clefs primaires , Choisissez les champs qui vous jugez pertinents pour fabriquer cette contrainte d'unicité obligatoire au sein d'un SGBD relationnel. Cette clef primaire sert à identifier chaque tuple d'une table pour le différencier d'un autre. Elle permettera ensuite de fabriquer les index utilisés par le SGBD pour optimiser son fonctionnement.

Cette clef peut être créer à partir de données métiers (une année, un mois dans votre exemple) mais dans ce cas elles devront être forcément renseignées pour que le tuple (la ligne) existe.

Cependant, on préfère en général créer cette clef primaire sur un ID numérique pour s'isoler totalement du métier et entretenir le relationnel entre les table techniquement. On créé ensuite une autre contrainte d'unicité uniquement métier que l'on pourra changer à volonté (création de champ, changement des critères d'unicité etc...).? Ainsi on peut changer l'intérieur de la table et son comportement sans altérer le relationnel. En effet, il me semble qu'en changer de clef primaire, les indexs sont reconstruits (précision nécessaire d'un admin DB svp ?). Sur des grosses tables (comme les tables en flocons ou étoile) , ce point est primordiale pour les performances...

Voila, avec tout ça je pense que aurez compris la logique...vous comprendrez alors ma proposition de créer une clef primaire sur un champ ID de vos tables. Vous lierez les clefs étrangères (Foreign Key) des autres tables à cette ID pour créer le relationnel de votre schéma. Ensuite, créez une contrainte d'unicité sur les champs qui vous paraissent pertinents (ici couplet semaine, mois , année) (cette contrainte sera vérifiée qu'à l'insertion des données, et non à la lecture, ni suppression voila une parti de l'optimisation).

[Ecosmose]

Je serais moins strict que Feyrehr en répondant que cela va dépendre de vos besoins, d'où l'importance de vos recueils des exigences, puis de votre conception qui va générer le schéma conceptuel de la BD.

Travaillant dans le domaine du renouvelable, nous étudions des phénomènes temporels mais pas forcément sur un axe linéaire de temps. Nous étudions par exemple les phénomènes des alizés qui apparaissent par exemple aux Caraïbes les mois de Février et Mars. Je pense qu'un schéma en flocon serait plus adapté qu'en étoile sur ce besoin précis. Pour agréger ces données , en flocon nous ne travaillerons que sur les tables des mois (donc quelques soient l'année sans jointures),les jointures pour récupérer les informations sur la dimension du temps sera donc faite à partir de la table des mois (en utilisant les indexs, ce qui est optimisés). Dans le cas de l'étoile, une requête SQL introduira un calcul algorithmique sur les champs fonctionnels qui risquent d'amoindrir les performances (un testera tous les tuples de la table des temps pour vérifier si les mois sont Février ou Mars).

Bon, je ne suis pas admin DB mais je pense que je suis pas loin de la vérité... Après les performances avec les systèmes actuels, je ne sais pas si c'est pertinent, ça le devient quand la volumétrie gonfle... Il est cependant toujours intéressant de prendre de suite les automatismes et une logique. Ce forum est fait aussi pour ça.

En étoile, Feyrehr vous l'a correctement expliquée. En flocon, je résonnerais selon vos besoins. Avec une structure différente à chaque besoin ^^ . par exemple vos tables de données temporelles avec deux clefs étrangères , une liée à une table JOUR_SEMAINE (si vous voulez décliner vos analyses par Jour, du style les nombre de gens en congés le mercredi, etc...), l'autre parrallèllement liée une table MOIS elle-même liée à une table ANNEE. La liaison entre ces tables ce fait par des ID numérique (-> génération d'index simple) et une contrainte d'unicité sur chaque table temporelle...

Voila en gros, vous avez les éléments de décision, à vous d'en faire la critique selon vos besoins...