Je concevons un entrepôt de données et j'ai un problème collant avec le temps. Le grain dont j'ai besoin est horaire (pour calculer les nombres d'événements globaux par heure) et je dois également accueillir un modèle de décalage qui ne correspond pas facilement à une période de 24 heures (en fait, il est possible que le changement «bleu» ne couvre pas la même chose heure de la journée pendant plusieurs jours).
Dans cet esprit, je contemplé l'une des 3 approches
J'envoie une approche 3, car elle permet de référencer la petite dimension calendaire séparément dans les jointures, mais j'apprécierais toutes les pensées.
3 Réponses :
Mon £ 0,02 pour ce qu'il vaut:
Si l'on suppose qu'il n'y a pas de problème supplémentaire découlant de l'examen du changement (la question de @Andriy M):
Je aurais tendance à l'option d'actualisation 2 à moins d'un avantage spécifique (performance, simplification d'une classe de requête, etc.) vous pouvez le voir adopter. Vous ne décrivez pas un tel avantage, il semble donc que vous ajoutez la complexité pour elle-même.
Ma préférence personnelle serait pour l'option 1 - conceptuel le plus simple, le plus direct et le meilleur ajustement (OMI) à des approches entrepôt de données.
L'option 3 présente les avantages que vous évoquez, mais je le soupçon lancinant qu'il couvre deux alternatives: à la fois la dimension civile est que vous décrivez, mais les choix de la dimension temporelle sont 175K lignes ou 24. Je ne peux pas à l'heure actuelle des arguments pour l'une de ces alternatives, seulement un sentiment de l'intestin que deux tels choix. Si la question du changement est pertinente, il pourrait influencer le choix entre ces solutions de rechange (si elles sont de véritables alternatives).
Si vous souhaitez prendre l'option 2 plus loin, les alternatives prévues pour l'option 3 sont également pertinents.
Le principal avantage que je vois de l'option 2 serait d'avoir une table calendrier complexe manuellement maintenue qui reste au niveau de la date tout en ayant une dimension temporelle plus simple qui comporte 24 rangées par date (25 ou 23 sur ces horribles jours d'équinoxes). Le gain de temps devra rejoindre la dimension temporelle à chaque fois que vous souhaitez des informations de calendrier. Il devrait donc y avoir une option 1.5 qui utilise une vue sur une table de calendrier et une table de temps pour fournir une dimension de date consolidée.
Si le modèle de décalage est un problème, il existe un troisième choix pour les dimensions de l'heure mentionnées pour l'option 3. Il s'agit d'avoir n lignes, où n est le nombre d'heures qu'il prend le motif de décalage pour le cycle total - par exemple, des démarrages de quart de travail À 09h00 le lundi au changement commence à 09h00 lundi. Ceci est soumis aux mêmes mises en garde que dans ma réponse originale.
Oui, les changements de fabrication sont délicats et changent au fil du temps, souvent un quart de travail commence la veille, etc.
Gardez à l'esprit qu'il existe Deux calendriers ici. L'un est le calendrier standard Par exemple: partie produite le lundi 2011- 02-07 23:45 peut ressembler à donc, ma suggestion est: Donc, l'étoile peut ressembler à quelque chose comme ça
dimension de date (une ligne par date)
Dimension de décalage - Type 2 Dimension avec rw_validfrom, (rw_validto), rw_iscurrent
DateKey dans ProductionDateKey
TIMEKEKE dans un ProductiontitionKey et ShiftTimeKey .
(DateTime) dans la table des faits aussi.
ProductionDateKey, ProductionTyTimeKey, TeatThey, ShiftTimeTeyKey à chaque ligne du FACTPART TABLE.
Je choisirais l'option 3. - Dimensions distinctes. Avantages:
SIMPLICITÉ - Deux tables relativement petites - avec une dimension temporelle chargée une seule fois comme il y a un nombre fixe de minutes en une journée.
réutilisation - deux dimensions de séparation sont plus susceptibles d'être partagées avec d'autres tables de faits pouvant avoir seulement une dimension de date ou de temps
Partitionnement facile en ayant un attribut séparé pour la dimension de la date dans une table de fait
Extensibilité - pensez attributs que vous pouvez ajouter aux dimensions de date et l'heure de vos besoins de reporting croître. Pour une dimension de date, cela pourrait être (pour éviter d'extraire ces informations à chaque fois à partir de la date): année, quart, mois, jour, semaine, étiquette de date (comme «12 septembre 2011»), Nom du mois, Nom de la semaine, Divers indicateurs (Vacances Indicateur, fin du quart, fin du mois, etc.). Pour une dimension temporelle (qui pourrait - pour la précision - contenir chaque seconde de la journée), cela pourrait être: heure, minute, deuxième, étiquette de la pièce de jour (comme "le matin", "soir"), indicateur de temps de travail (secondes de 8: 00h00 à 17h00:00), etc. Mais tout cela ne signifie qu'une seule dimension signifierait beaucoup de redondance.
Les quarts de travail qui ne sont pas alignés avec le début de la journée / la fin m'améliorent comme un bon candidat pour un mode d'enregistrement de fable distinct Start and Timestamp pour chaque quart de travail - je veux dire (sans faits) Table de fait avec les clés étrangères suivantes: id_date_start, id_time_start , id_date_end, id_time_end. Ensuite, vous pouvez « drill-travers » des événements table de faits à la table des quarts de travail pour obtenir des résultats globaux pour chaque quart de travail.
éditer: ou le modèle se déplace comme une autre dimension - qui dépend du fait que si vous changez est un processus métier important que vous souhaitez suivre indépendamment avec ses attributs (mais pour le moment je peux 't penser à tout autre attributs puis date et heure ... Emplacement, peut-être?) ou s'il s'agit simplement d'un contexte d'un événement (et devrait donc être juste une dimension).
Comment vos chiffres sont-ils dérivés: j'aurais pensé que toute dimension de calendrier serait de 8766 ou 8784 (selon que vous utilisez 365,25 * 24 ou 366 * 24); De même, je ne comprends pas vos lignes de 175k pour la dimension temporelle - elle ne se présente pas naturellement de n'importe quelle vue du temps que j'ai examiné?
J'étais approximativement à 365 jours * 20 ans = 7300 rangées, puis le 175k était d'environ 24 heures * 7300 rangées.
Désolé, si ma question a l'air stupide, mais ... Qu'est-ce que
'Blue' Shift ? Ou du moins quel est le problème avec la probabilité de ne pas couvrir la même heure de la journée pendant plusieurs jours?C'est un nom arbitraire donné à un «changement». Vous avez appelé facilement échanger le mot «changement» pour «équipe». Nos équipes ont une rotation complexe de l'horaire de sorte qu'aucune équipe ne fait la même heure de la journée quotidienne.