時間模式

時間維度

正如我上面所描述的，時間在建模中是一個相當具有挑戰性的概念。然而，我跳過了時態模型中最尷尬的方面。我們都學過，即使只是從糟糕的科幻小說中，時間是第四個維度。問題在於這是不正確的。

我發現描述這個問題的最佳方法是舉例說明。假設我們有一個薪資系統，該系統知道員工從 1 月 1 日開始的費率為 100 美元/天。2 月 25 日，我們以這個費率執行薪資。3 月 15 日，我們得知員工的費率自 2 月 15 日起變更為 211 美元/天。當我們被問及 2 月 25 日的費率時，我們應該如何回答？

從某種意義上來說，我們應該回答 211 美元，因為現在我們知道那是費率。但我們通常不能忽視在 2 月 25 日我們認為費率是 100 美元，畢竟那是我們執行薪資的時候。我們列印了一張支票，寄給他，他兌現了它。這些都發生在他的費率金額的基礎上。如果稅務機關詢問我們他在 2 月 25 日的費率，這就變得重要了。

事實上，我們可以認為，的確有兩段對我們而言很重要的 Dinsdale 薪資記錄。我們現在知道的記錄，以及我們在 2 月 25 日知道的記錄。的確，一般來說，我們可以說，不僅每一天的 Dinsdale 薪資記錄都有記錄，Dinsdale 薪資記錄的記錄也有記錄。時間不是第四維度，而是第四和第五維度！

我將第一個維度視為實際時間：某件事發生的時間。第二個維度是記錄時間，我們知道它的時間。每當某件事發生時，總會有這兩個時間隨之而來。Dinsdale 的加薪在實際時間是 2 月 15 日，在記錄時間是 3 月 15 日。同樣地，當我們詢問 Dinsdale 的薪資時，我們真的需要提供兩個日期：記錄日期和實際日期。

我們可以這樣思考這兩個維度。實際記錄是回顧實際時間。如果我查看我目前的實際記錄，那麼我看到 Dinsdale 的薪資在 2 月 15 日之前是 100 美元，在那時增加到 211 美元。然而，那是今天在記錄時間的實際記錄。如果我查看 2 月 25 日的實際記錄，那麼 Dinsdale 從 1 月 1 日起以 100 美元支付，而 211 美元從未包含在內。記錄時間中的每一天（嚴格來說，每一個時間點）都有實際記錄。這些記錄是不同的，因為我們發現我們過去認為是真實的事情不再是真實的。

從另一個角度來說，我們可以說實際記錄中的每一天都有記錄記錄。記錄記錄告訴我們我們對那一天的了解如何隨著時間而改變。因此，實際時間中的 2 月 25 日有一個記錄記錄，其中寫道，截至 3 月 15 日，Dinsdale 的薪資為 100 美元，在那時達到 211 美元。

讓我們進一步舉這個例子。假設我們在 3 月 26 日的薪資運行中進行了相應的調整。4 月 4 日，我們被告知員工的先前資訊錯誤，實際上費率在 2 月 15 日變更為 255 美元。現在，我們如何回答「員工在 2 月 25 日的費率是多少？」這個問題。

我看到成長中的開發人員在面對這種事情時會咬掉自己的頭。但是，一旦你意識到一切都歸結為這兩個維度的概念，事情就會變得簡單很多。將這個較早的表格擴充套件，可以視覺化這一點的方法之一

如果我們檢視目前的實際記錄（也就是記錄日期為今天的實際記錄），我們會說 Dinsdale 的薪資從 1 月 1 日開始為 $100，並於 2 月 15 日調漲至 $255。對於目前的實際記錄，$211 的費率完全不會出現，因為這從未發生過。如果我們檢視 3 月 26 日的實際記錄，我們會看到 Dinsdale 的薪資在 2 月 15 日之前為 $100，然後調漲至 $211。在 3 月 26 日的實際記錄中，$255 的費率從未發生過，因為我們還不知道這件事。

我們也可以考慮 2 月 25 日的記錄記錄。現在，這筆記錄記錄表示費率為 $100（在當天），直到 3 月 15 日變更為 $211。然後在 4 月 4 日再次變更為 $255。

一旦你了解這兩個面向，思考問題就會變得容易許多，但想到你必須實作這類事項，就會令人害怕。幸運的是，在實作時，你可以採取許多方法來簡化問題。

第一個簡化方式是，使用 稽核記錄 來因應這些變更並不困難。你所需要做的，就是記錄每個條目的記錄日期和實際日期。這個簡單的練習就足以讓任何記錄在兩個面向都保持有效，而且我相信即使你只煩惱其中一個面向，這也是值得執行的。

第二個簡化方式是，你通常不希望你的模型處理兩個面向。這裡的重要事項是知道你的模型中有哪些，以及你將哪些留給 稽核記錄。

如果我們想要保留事物的記錄，了解事物隨著時間如何變更，但不在乎我們何時得知變更，我們會說這是實際時間。因此，如果我保留員工地址的記錄，我可能會選擇將其保留為實際時間屬性。對於協助線上查詢的資訊系統，這很有效，因為當你存取資料庫時，你通常會想要了解實際記錄。

當您有一個系統會根據物件狀態產生帳單等動作時，就會出現記錄時間事實。這些事情會引發有關帳單如何計算的問題，這會讓您需要知道計算帳單時物件的狀態為何。記錄時間事實通常可以比喻成軟體中的版本控制系統，您可以在其中返回並說「4 月 1 日這個檔案是什麼樣子？」

當然，有時您需要兩個維度同時存在，這稱為雙時間事實。基本上，雙時間資訊總是需要兩個日期。

雙時間性是完整的解決方案，但總是值得思考如何解決它。舉例來說，從帳單計算中得知。如果您想找出帳單為何會變成這樣，其中一種可能性是擁有完全雙時間的資料庫。但是，在計算帳單時儲存計算的詳細追蹤記錄通常會更好。這以比雙時間物件模型更簡單的方式滿足需求。

更新時間記錄

到目前為止，我只在存取資訊的方面討論時間資訊，而不是在更新資訊的方面。您允許更新的方式會導致更多決策，但其中許多涉及有用的簡化。

一般來說，變更時間記錄相當混亂。如果我們有一位員工的費率從 2 月 15 日到 4 月 15 日為 211 美元，完全通用的更新將允許變更開始日期、結束日期和值的任何組合。提供一個介面來執行這項操作很尷尬，因為它要求客戶深入了解時間資訊的運作方式。

第一個簡化是您可能只有附加變更。附加變更總是會加到記錄的結尾。附加變更的範例是「讓員工的費率從 2 月 15 日起為 211 美元」。雖然乍看之下這看起來像是您只從組合中移除一筆資料，但後果實際上會讓更新大幅簡化。實際發生的更新大多是附加的，因此可以大幅簡化客戶端。此外，您可以使用一些附加更新的組合進行任何變更。雖然這會讓具有複雜歷程的物件變得非常混亂，但此屬性可以透過只支援附加介面來簡化具有簡單歷程的物件。

第二個簡化只允許目前的更新。目前的更新只允許記錄在今天生效日期的變更。一般來說，即使是附加變更也可能發生在過去或未來的任何日期。目前的變更完全不需要日期資訊，讓您可以擁有完全非時間性的更新介面。

目前的更新看起來好得令人難以置信，如果只用目前的更新更新，為什麼還要時間資訊？這裏的好消息是，紀錄時間資訊只能用目前的更新更新。不僅追溯變更紀錄時間資訊會破壞紀錄的完整性，而且沒有任何情況需要追溯變更，而無法由實際時間維度處理（除非欺詐是您的需求之一）。這是一大步，因為這表示整個維度都有隱形的更新 - 查詢時您只需要擔心紀錄時間，更新時則不用。

其他讀物

由於這是一個複雜的領域，因此隨著人們探索這些問題，它產生了一些其他著作。這個領域最全面的處理方式是 Snodgrass。他的著作基於關聯式資料庫，書中大部分內容都是關於如何在 SQL 中處理這些問題。然而，問題是一樣的。此外，他提出的許多評論和使用的術語與即將推出的 SQL 標準中關於時間資料庫的內容相同。這本書現在已經絕版，但您可以從 Richard Snodgrass 的出版物頁面 取得 PDF 檔。

術語問題是我仍然不太滿意的地方。他使用與我相同的兩個維度，但他的術語不同。我稱之為實際時間，他稱之為有效時間，我稱之為紀錄時間，他稱之為交易時間。在這些模式的早期版本中，我遵循他的術語，但許多人表示他們發現這些術語很難理解。因此，我決定使用不同的術語。另一個不同之處是他將隨著時間而變化的表格稱為順序。當然，物件一直使用順序，不僅用於時間目的，所以我將隨著時間而變化的東西稱為時間。

[Anderson] 是時間模式的最佳集合之一。我再次掠奪想法，但改變了一些術語。我使用術語版本而不是版本，表示在某個時間段內屬性或物件的值。他的變更記錄和關聯歷史模式與 時間屬性 相同。我認為兩個 Anderson 模式之間的差異更像是實作問題。他的自我的歷史模式與 時間物件 相同。

在同一本 PLoPD 4 書中，您會找到一篇由 Andy Carlson 與我本人以及 Sharon Estepp 合作撰寫的論文 [Carlson et al]。這篇論文提供了 時間屬性 和 快照 的早期描述。它還提到了一個模式時間關聯，我現在將其視為 效力 的一種用法。

也提交給 PLoP，但目前尚未公開的是 [Arnoldi et al]。這引入了許多有趣的點子，我尚未在這裡的模式中完全探討（至少目前還沒有）。

[Anderson] 和 [Arnoldi et al] 都考慮使用 時間點 以外的物件作為時間記錄的索引。[Anderson] 使用（單一時間）事件，而 [Arnoldi et al] 使用觀點：實質上是兩個時間點組合成一個單一物件。雖然這兩種方法都有其可取之處，但我沒有在這裡使用它們，因為我覺得使用時間點可以滿足您的大部分需求，而且解釋起來也比較簡單。