2003年 2月16日 履歴 データ の扱い >> 目次 (作成日順)
  ● QUESTION   履歴 データ は、どのようにして記述すればよいか。
  ▼ ANSWER   entity、サブセット あるいは VE のいずれか、を判断しなければならない。
2008年 3月 1日 補遺  



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

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

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

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

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

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

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

  「更新日 + 部品番号」

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

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

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

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

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

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

 
3. VE として扱う

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

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

 



[ 補遺 ] (2008年 3月 1日)

 データ の状態を時間軸のなかで把握するには、「共時的(synchronique)」 と 「通時的(diachronique)」 という概念がありますが、「履歴」 は、「来歴」 という意味ですから、当然ながら、「通時的」 な概念です。「通時的」 な概念であっても、「履歴」 データ を どのように認知しているか によって、以下の 2つの対応が考えられます。

 (1) 「履歴」 そのものを、単独の管理対象 (entity) にしている。
   すなわち、「更新」 という できごと を管理している。

 (2) 「履歴」 は、しかじかの entity の状態が推移すると考える。
   すなわち、しかじかの entity の 「通時的」 状態の記録として管理している。

 
 「来歴」 という意味は、しかじかの 「entity」 そのもの-の性質が時間軸のなかで変化することを示しているのだから、「履歴」 の記述は、基本的には、以上の 2つのいずれかを使うことになるでしょう。

 ただ、本文のなかで述べたように、しかじかの 「entity」 の性質が変化することを管理しないのであれば、「entity」 のなかに、「履歴」 データ をふくめる意味はないでしょうね。したがって、そういう事態であれば、「履歴」 を VE として扱っても良いでしょう。

 なお、本文を読んだあとで、169 ページ の 「更新者・更新日の扱い」 も読んで下さい。




  << もどる HOME すすむ >>
  データ解析に関するFAQ