2002年11月16日 更新者・更新日の扱い >> 目次 （作成日順）
　　●　QUESTION 　　データ を更新したとき、更新者と更新日は、どのように扱えばよいのか。
　　▼　ANSWER 　　アトリビュート として扱うこともあれば、VE として扱うこともある。
2007年12月 1日 補遺 　



　Ｔ字形 ER手法は、事業のなかで扱われた実 データ を使って、事業の 「事実を記述する」 手法なので、事業の実態を解析することを第一義にしている。したがって、（コンピュータ のなかで追加される） 更新者と更新日は、[ データ 解析法としての ] Ｔ字形 ER手法の直接的対象ではない。

　しかし、いっぽうでは、Ｔ字形 ER手法は、（データ を解析した後で） ほぼ、そのままの構造を実装してデータ 設計法としても使うことができるので、当然ながら、（コンピュータ のなかで追加される） 更新者と更新日は、[ データ 設計法としての ] Ｔ字形 ER手法の記述対象となる。

　更新者を管理対象とする目的は以下の 2つを考慮できる。
　　（1） 更新の アクセス （authorization） を管理する。
　　（2） 更新の ログ （履歴） として保管する。

　更新の対象となるのは、「resource」 であろう--「event」 を更新するなら、エンドユーザ が 「修正」 トランザクション を再入力して、監査証跡を遺す形態にしている、と思われる。
　「resource」 を更新するための アクセス （authorization） を管理するのなら、おそらく、更新者に対しては パスワード を付与されていると想像できるので、以下のような構造になる。

　（1） 従業員　｛従業員番号、名称、...｝ [ R ]
　（2） パスワード　｛パスワード、権限 レベル、...｝ [ R ]
　（3） [ resource ]　｛ [ resource ] コード、名称、更新日 (D)、...｝ [ R ]
　（4） 従業員. パスワード. 対照表　｛従業員番号 (R)、パスワード (R)、...｝
　（5） 従業員. [ resource ]. 対照表　｛従業員番号 (R)、[ resource ] コード (R)、...｝
　（6） 従業員. [ resource ]. 対照表　｛従業員番号 (R)、[ resource ] コード (R)、更新日、更新理由、...｝

[ 参考 ]
[ resource ]　｛ [ resource ] コード、名称、 更新日、...｝ [ R ] には、最新状態と履歴が co-located されている。最新状態と履歴状態をべつべつにしたければ、以下のようにすればよい。

　　　　[ resource ] （セット）
　　　　　　　　｜
　　　　　　　　×　null （更新日）
　　　　　　　　│
　　　　　　　　├｛[ resource ] コード、名称、...｝ [ 最新状態 ]
　　　　　　　　│
　　　　　　　　└｛[ resource ] コード、名称、更新日 (D)、...｝ [ 履歴状態 ]

　ちなみに、上述の サブセット は 「状態の推移」 を記述している。
　なお、更新日に附与されている (D) は、derivated の意味である。この例では、replicated に近い。

　
　上述の [ resource ] の欄には、個々の 「resource」 名称が記述される。
　以上の管理体系は、それぞれの 「resource」 ごとに、以下の項目を管理している 「緻密な」 管理体系である。

　（1） だれが、どの更新権限を付与されているのか （「従業員. パスワード. 対照表」）。
　（2） だれが、どの「resource」を更新できるのか （更新日のない「従業員. [ resource ]. 対照表」）。
　（3） だれが、どの 「resource」 を更新したのか （更新日のある「従業員. [ resource ]. 対照表」）。

　以上のような 「緻密な」 体系を導入しないで、更新状態を管理しながら更新権限を備考として遺すなら--「resource」 の更新状態を管理することが目的であって、「だれ」 が更新したかという情報が備忘記録であるならば--、以下のようになる。

　（1） 従業員　｛従業員番号、名称、...｝ [ R ]
　（2） 従業員. 更新権限　｛従業員番号 (R)、権限 レベル、...｝ [ VE ]
　（3） [ resource ]　｛ [ resource ] コード、名称、更新日、...｝ [ R ]
　（4） [ resource ]. 更新者　｛ [ resource ] コード (R)、従業員番号 (R)、更新日 (D)、...｝ [ VE ]

　「[ resource ]. 更新者」 （VE） のなかで、従業員番号 (R) を （identifier としないで） 「備考」 として扱っている点に注意されたい （「データ 解析に関する FAQ」 の 21ページ を参照されたい）。

　さて、上述のような権限 レベル を管理しないで、更新者の ログ を備考として遺すためなら、以下の扱いでよい。

　（1） 従業員　｛従業員番号、名称、...｝ [ R ]
　（2） [ resource ]　｛ [ resource ] コード、名称、更新日、...｝ [ R ]
　（3） [ resource ]. 更新者　｛ [ resource ] コード (R)、従業員番号 (R)、更新日 (D)、...｝ [ VE ]

　以上のように、更新者の扱いは、更新を、どのように管理するか、という点から判断して、さまざまな構造になる。以上に示した例は、典型的な・ほんの数例に過ぎない。逆に言えば、作図された構造から判断して、更新を、どのように考えているか、という点を見て取ることができる。

　


[ 補遺 ] （2007年12月 1日）

　本 エッセー で綴った例に関連して、応用問題を一つやってみましょう。
　以下を前提にします。

　（1） 案件番号を認知番号にして、「案件」 が管理対象になっている。
　（2） 「案件」 は、「resource」 として管理されている。
　（3） 「案件」 について、社員が交渉した推移を管理する。
　（4） 社員番号を認知番号にして、「社員」 が管理対象になっている。
　（5） 1つの 「案件」 に対して、交渉した社員と、記録を入力する社員は、内部統制上、それぞれ、べつである。
　（6） 「交渉した社員」 と 「交渉を記録する社員」 は、つねに、「対」 になって入力される。
　　　言い換えれば、どちらかが null になることはない。

　さて、もし、「交渉した社員」 と 「交渉を記録する社員」 が、事前に組まれていれば--すなわち、制約・束縛 （ビジネス・ルール） として、「対」 が事前に きまっていれば--、以下のように、「社員」 を 「再帰」 的に構成します。

　┌─────────────────┐　　　　　┌─────────────────┐
　│　　　　　　　社　員　　　　　　Ｒ│　　　　　│　　　　社員. 社員. 再帰表　　　　│
　├────────┬────────┤　　　　　├────────┬────────┤
　│社員番号　　　　│社員名称　　　　│　　　　　│社員番号（Ｒ）　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　├┼─○─＜│社員番号（Ｒ）　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　│　　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　├──┘　　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　  　　　　　│　　　　　　　　│
　└─────────────────┘　　　　　└────────┴────────┘
　　　　　　　　　　∨
　　　　　　　　　　｜　　　　　　　　　　　　　　┌─────────────────┐
　　　　　　　　　　｜　　　　　　　　　　　　　　│　　　　社員. 案件. 対照表　　　　│
　　　　　　　　　　｜　　　　　　　　　　　　　　├────────┬────────┤
　　　　　　　　　　｜　　　　　　　　　　　　　　│社員番号（Ｒ）　│交渉日　　　　　│
　　　　　　　　　　○──────────────┤案件番号（Ｒ）　│交渉事項　　　　│
　　　　　　　　　　｜　　　　　　　　　　　　　　│　　　　　　　　│　　　　　　　　│
　　　　　　　　　　｜　　　　　　　　　　　　　　│　　  　　　　　│　　　　　　　　│
　　　　　　　　　　∧　　　　　　　　　　　　　　└────────┴────────┘
　┌─────────────────┐
　│　　　　　　　案　件　　　　　　Ｒ│
　├────────┬────────┤
　│案件番号　　　　│案件名称　　　　│
　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│
　└────────┴────────┘

　
　もし、社員どうしのあいだに制約・束縛がないのであれば、「対」 は、「構文論上」、多値関数 （MAND） になるので、以下の構成になるでしょう。

　┌─────────────────┐
　│　　　　　　　社　員　　　　　　Ｒ│
　├────────┬────────┤
　│社員番号　　　　│社員名称　　　　│
　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│
　└─────────────────┘
　　　　　　　　　　∨
　　　　　　　　　　｜　　　　　　　　　　　　　　┌─────────────────┐
　　　　　　　　　　｜　　　　　　　　　　　　　　│　　　　社員. 案件. 対照表　　　　│
　　　　　　　　　　｜　　　　　　　　　　　　　　├────────┬────────┤
　　　　　　　　　　｜　　　　　　　　　　　　　　│　　　　　　　　│　　　　　　　　│
　　　　　　　　　　○──────────────┤　　　　　　　　│　　　　　　　　│
　　　　　　　　　　｜　　　　　　　　　　　　　　│　　　　　　　　│　　　　　　　　│
　　　　　　　　　　｜　　　　　　　　　　　　　　│　　  　　　　　│　　　　　　　　│
　　　　　　　　　　∧　　　　　　　　　　　　　　└────────┴────────┘
　┌─────────────────┐　　　　　　　　　　　　　　│
　│　　　　　　　案　件　　　　　　Ｒ│　　　　　　　　　　　　　　× 概念的スーパーセット
　├────────┬────────┤　　　　　　　　　　　　　　│
　│案件番号　　　　│案件名称　　　　│　　　　　　　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　　　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　┌───────────┘
　│　　　　　　　　│　　　　　　　　│　　｜
　│　　　　　　　　│　　　　　　　　│　　｜
　└────────┴────────┘　　｜
　　　　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　　　　　　　　　　↓
　　　　　　　　　　┌───────────┴───────────┐
　　　　　　　　　　｜　　　　　　　　　　　　　　　　　　　　　　　｜
　┌────────┴────────┐　　　　　┌────────┴────────┐
　│　　　　　　　ＨＤＲ　　　　　　　│　　　　　│　　　　　　　　ＤＴＬ　　　　　　│
　├────────┬────────┤　　　　　├────────┬────────┤
　│案件番号（Ｒ）　│交渉日　　　　　│　　　　　│案件番号（Ｒ）　｜社員種別コード　│
　│　　　　　　　　｜交渉事項　　　　├┼───＜│社員番号（Ｒ）　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　  　　　　　│　　　　　　　　│
　└────────┴────────┘　　　　　└────────┴────────┘

　
　「社員種別 コード」 は、社員番号を 「並べる」 ための コード です--たとえば、付値として、「1」 が 「交渉社員」 を意味し、「2」 が 「入力社員」 を意味するというように。




　 << もどる HOME すすむ >>
　 データ解析に関するＦＡＱ