「技術的には」 以下の 3つの扱いを考えることができる。

　　（1） 1つの entity とする。
　　（2） サブセット とする。
　　（3） VE とする。

1. 1つの entity とする例 （「更新日」 が定義されている例）

　「履歴」 として、以下の事象を前提とする。

　（1） データ には 「更新日」 という アトリビュート が定義されている。
　（2） 「更新日」 には、最終更新日が入力される。

　　部品　{ 部品番号、部品名称、・・・、更新日 }.

　更新日が用意されていれば、最新の データ と履歴 データ の間には アトリビュート 構成には相違がないので、1つの entity として扱ってよい。
　そして、最新 データ と履歴 データ の区別は、以下の キー （indexing） を用意すればよい。

　　「更新日 ＋ 部品番号」

　キー の並びを昇順するか降順するかという点は、最新情報から遡って参照するのか、あるいは履歴を時系列のなかで参照するのか、という点次第である。

　こういう例は、たとえば、「適用日」 とか 「有効日」 という日付を定義している データ に多い。
　更新が 「かならず起こる」 データ に対しては、こういう対応をすることが普通である。

　
2. サブセット とする例 （最新情報に対して 「更新日」 を定義していない例）

　履歴 データ に対して 「更新日 （履歴を作成した日）」 を定義しているが、最新情報には、それを定義していないこともある。すなわち、データ に対する更新が 「ほとんど起こらない」 ので、最新 データ には更新日を用意しないで、稀有な更新が起こったときに、履歴 データ に対して日付 （履歴日） を用意する例である。

　最新 データ と履歴 データ では、アトリビュート 構成が相違するので、（「更新日」 が ヌル になる） 「相違の サブセット」 として扱う。

　ちなみに、履歴 データ に対して、「連番」 を附番する やりかた も 「相違の サブセット」 として扱う。
　たとえば、identifier に対して、（履歴の古い順に） 2桁の連番を附番しているなどがそうである。

　
3. VE として扱う

　最新 データ と履歴 データ を、1つの entity とするのであれ、「相違の サブセット」 にするのであれ、いずれも、履歴 データ を参照することが前提になっている。

　ただ、もし、履歴 データ を、ほとんど参照しないのであれば──たとえば、トラブル などに対応するために用意している 「バックアップ」 用の データ としての性質であれば──、履歴 データ を VE としてもよい。