一般に、正規化するとデータ項目は１つのエンティティに従属します。
しかし、時間の経過を考慮すると、そのデータ項目が複数の値をもつこともありえます。
つまり、厳密にはこの正規化は正しくないと言えるでしょう。履歴エンティティは、そのような時間軸をモデル上で捌く方法の一つです。主要なリソースエンティティ、たとえば取引先、社内組織、商品などは、履歴エンティティをもつケースが多いでしょう。
一方で、履歴エンティティを持たずに時間軸を扱う方法も存在します。たとえば、イベントエンティティのなかにリソースエンティティのデータ項目をJOINしておく方法です。受注エンティティの中に受注顧客コードだけでなく、顧客名、顧客住所、顧客電話番号を持たせます。データモデリングの教科書には、このような正規化は第三正規形でないと記述されますが、時間軸を考慮すると半分正しい正規化と言えるでしょう。残り半分は正しくないわけですが、それは変更が発生しないリソースデータもイベントエンティティ側に持つことが無駄である点です。やはり、変更分だけを履歴的に管理したいものです。
別な捌き方としては、リソースエンティティのＫＥＹに、時間軸を表すデータ項目を追加することです。通常“商品エンティティ：［商品コード］”とするところを、→［商品コード．バージョン番号］あるいは［商品コード．適用開始年月日］とします。これは、もとのエンティティと履歴エンティティを一体化する捌き方です。
現時点の私なりの正解は、リソースエンティティに履歴エンティティをもち、時間軸を考慮して、イベント側からこれらを参照する捌き方です。
