次のようなエネルギー消費のファクト テーブルがあります。
f_meter_data:
utc_calendar_id
local_calendar_id
meter_id
reading
timestamp
カレンダー テーブルは Kimball の推奨事項に従って構造化されており、ユーザーがローカル時間と UTC 時間でクエリできるように 2 つのカレンダー ID を用意している理由は、データ ウェアハウス ツールキットの推奨事項です。
これで問題はありませんが、夏時間が始まると問題が発生します。
粒度が 30 分単位であるため、時計が変わるとファクト レコードが重複します。
また、クロックが逆方向に変化すると、データにギャップが生じます。
どうすればこの状況に対処できますか?
重複した値を平均して代わりに保存する必要がありますか?
また、データにずれがある場合は、ずれの直前と直後の平均をとればいいのでしょうか？
これをビジネスで単純化する必要があると思います。つまり、クロックが戻されると、古いレコードを警告テーブルまたはエラー テーブルにプッシュし、新しいレコードを同じ間隔で配置することで、レコードを元に戻します。
マットが示唆したように、現地時間で実行された場合、とにかくレポートは真実を伝えません. それでは、なぜレポートに間違ったデータを与えるのでしょうか。
または、Matt のアドバイスをフォローアップするには、間隔の記録をもう一度変更してください。その場合、時間間隔を local_id にバインドしないでください。代わりに、地域に応じて、特定の日に 48 レコード (1-48)、50 レコード (1-50)、または 52 (1-52) レコードを含む 30 分の間隔で実行される Interval_seq_id を使用します。これにより、Local_Int_starttime と Time_interval_Endtime の重複した問題が技術的に解消され、時間間隔に依存したり結合したりすることはなくなります。
ただし、これは問題をレポート/クエリツールに移して、現地時間で重複しているグラフに時間を表示する方法を解決します。特に、現地時間とメーターの読み取りに基づいて分析を行いたい場合. ただし、この方法では、データベース設計は、時間間隔を使用せずに Interval_Seq_id によってレコードを区別するようになりました。