「TMの会」 プログラム このウインドウを閉じる
/ 2005年 3月17日 / 

 

 ● 提示されたテーマは ...

 以下の問題を材料にして、T字形ER図の読みかたを、佐藤正美が実演する。

 テクニカル・エンジニア(データベース)の試験問題 [ 平成16年度、午後2 問題1 ]

 
 この試験問題は、データ構造を作る問題ではないが、「TMの会」のメンバーが、「tentative modeling」として作ったデータ構造を、意味論の観点に立って、proofreading (添削、校正)する やりかた を、佐藤正美が実演する。

 なお、前回(2月17日)の「作成手順」のなかで述べたが、データ構造は、正確な構造を、一気に作ることを考えないで、まず、「ルール・ベース(生成規則)」に従って、骨組みを作って、次第に、整えてゆく、という作りかたが良い。

 したがって、正しいデータ構造を作るためには、T字形ER図を、(「tentative modeling」を起点にして、)データの「意味」を確認しながら、数回、書き直すことになる。喩えてみれば、画家が、対象を的確に描くために、デッサンのなかで、大まかな骨組みを描いて、次第に、詳細に描いてゆき、「正しい1つの線」を探すために、いくつもの線を試すことに似ている。

 
 ● 意味論は、「指示関係」を問う ...

 まず、意味論の観点に立って、データ構造を検証する際、注意しなければならない点は、「表現関係(意義)」と「指示関係(意味)」を混同してはいけない、という点である。

 ポパー氏が提示した「第3世界のモデル」を、以下に示して、「意義」 と 「意味」 の違いを確認する。
 (1) 第1世界(物的世界、現実的事実--経営過程)
 (2) 第2世界(心的世界、認識主体の世界)
 (3) 第3世界(論理的世界、モデル--データ構造)

 第1世界と第2世界のあいだでは、(認識主体が、現実的事実を観て、認識主体のなかに、内的な「像」が描かれ、)「像」が論点になる。そして、第2世界と第3世界とのあいだに成立する関係は、「表現関係」である。「表現関係」では、「意義」が論点になる。たとえば、以下の文が、「意義」を記述している。

 (1) 明けの明星は、太陽によって照らされる物体である。
 (2) 宵の明星は、太陽によって照らされる物体である。

 「明けの明星」と「宵の明星」は、「意義」であって、「意味」ではない。それを論証した人物が、フレーゲ氏である。「明けの明星」も「宵の明星」も、指示している物体は、同じ対象(「金星」)である。すなわち、第3世界と第1世界とのあいだに成立する指示関係を問うのが「意味」であり、指示関係を論点にするのが「意味論」である。「意義」(「表現関係」)を記述するのが「意味論」ではない。

 [ 参考 ]
  フレーゲ氏の云う「意義」は、現代の通説では、「意味」として理解されている。
  ただし、そういう「意味」は、「指示規則」と混同されてはならない。

 
 ポパー氏の「第3世界のモデル」を前提にすれば、以下の3つの認識が論点になる。
 (1) 像に関与する。
 (2) 意義に関与するが、意味に関与しない。
 (3) 意味に関与する。

 「意味論」とは、(3)の指示関係を扱う領域であって、「意義」が論点になるのではない。
 したがって、「entity」が、まず、定立されて、「entity」の指示関係を検証してあるならば、「entity」を前提にして、導出規則に従って構造を作るならば、認知番号の名称を継承するのが正しい。たとえば、「tentative modeling」では、「顧客」entity の再帰として、「派遣先顧客コード(R)」 と 「就業先顧客コード(R)」 というふうに記述されているが、(それらは、「意義」であって、「顧客」entityが、「顧客コード」を使って定立されているのだから、)導出関係のなかで、「意味」を示すためには、いずれも、「顧客コード(R)」とするのが正しい。
 ただし、「意義」を記述してあれば、理解しやすいので、「(派遣先)顧客コード(R)」とか「(就業先)顧客コード(R)」というふうに記述してあっても、間違いではない。

 「意義」 と 「意味」の関係では、同じようなことが、(「tentative modeling」のなかで記述されているが、)「(就業開始)時刻」 と 「(就業終了)時刻」でも論点になる。「時刻」を、パラメータ(変項)として扱い、2つの「時刻」を「多義」として扱うのが正しい やりかた であるが、以下のように、記述しても、(指示関係を意識しているなら、)小生は、黙認する

   派遣依頼DTL {派遣依頼番号、...就業開始時刻、就業終了時刻、...}.

 
 ● T字形ER図を読む際、まず、「event」の流れを読む ...

 「意味論」的な検証をする前に、かならず、以下の形式的な確認をしてください。

 (1) 指示規則(認知番号は、「実存する」コードを使っているかどうか)。
 (2) 生成規則(aRbのなかで、「event」が時系列に並べられているかどうか)。

 往々にして、「実存しない」認知番号を使って、「entity」を生成していることがあるので、注意されたい--「実存しない」認知番号を使って、entity を認知することは、「みなし」entity として扱われているはずである。
 形式的に妥当でない構造は、指示関係を検証する際、(SEの恣意性が、多大に混入しているので、「(事業の)事実と(SEの)意見」を切り離すために、)無駄な手数を費やすことになる。形式的に妥当な構造でないなら--「entity」として、指示関係が、まず、検証されていないなら--、「意味論的」な添削をはじめてはいけない。

 T字形ER図(データベース設計)の勝負点は--事業過程(正確には、管理過程)に対して、代替案・改善案を探すには--、「resource」であるが、「現状を確認するために」、T字形ER図を読む際、まず、以下のように、「event」を読んで、事業過程を確認する。

 (1) 「event」の流れを検証して、事業構成を確認する。
 (2) 「event」に対して、どのような「resource」が関与しているか、という点を確認する。

 「Tentative modeling」では、以下の「event」構成になっている。

 派遣依頼HDR
 {派遣依頼番号、(派遣先)顧客コード(R)、(就業先)顧客コード(R)、勤務地コード、
  派遣依頼日、開始予定日、終了予定日}.

 派遣依頼DTL
 {派遣依頼番号、派遣依頼明細番号、(従事)業務コード(R)、就業曜日コード、
  就業開始時刻、就業終了時刻、休息開始時刻、休息終了時刻、依頼人数}.

 受注HDR
 {受注番号、派遣依頼番号(R)、担当者コード(R)、
  受注日}.

 受注DTL
 {受注番号、受注明細番号、派遣依頼番号(R)、派遣依頼明細番号(R)、
  受注人数}.

 受注DTLは、さらに、以下のHDRになっている。
 受注DTL.スタッフ(受注DTLのDTL)
 {受注番号、受注明細番号、派遣スタッフ・コード、
  就業開始日、就業終了日}.

 
 さて、まず、「event」の流れを観て、「派遣依頼と受注」に関する領域(区域)を検討対象にしていることを、作成者(たぶん、ユーザ企業のDA)に対して、確認する。どうして、このような確認をするかといえば、たとえば、のちのち、「請求」の区域を扱うとき、「請求」entity が「受注」entity に対して、(aRbのなかで、) なんらかの制約事項を示すかもしれないけれど、(「請求」entity が、確実に、記述されないかぎり、「受注」entity と「請求」entity のあいだに成立する関係のなかで、「前提(baseline)」の網羅性を検証できないので、) 「請求」entity を射程距離のなかに置いた推測的記述を排除するためである。
 もし、そういう制約事項があるのなら、「請求」を検討する際、「受注」を修正すれば良い。あるいは、もし、そういう制約事項も、「受注」のなかに記述しなければならない、というのであれば、「請求」も、今回、検討対象にしなければならない。

 
 「Tentative modeling」では、1つの「派遣依頼」に対して、複数の(1つ以上の)「受注」が起こる、というふうに記述されている。すべての「派遣依頼」が、すべて、「受注」されることはない、と想像できるので、「受注」には、「(relationship の)ゼロの cardilality」を示したほうが良いでしょうね--ただ、小生は、「ゼロの cardinality」を観ていないけれど(笑)--データとして、実際には起こらなかった、ということにすぎないのですが--、プログラマが、テスト・データを作る際、参考になるので、記述しておいたほうがいいでしょうね。ちなみに、先行「event」のほうに、「ゼロの cardinality」が起こる際には、後続「event」の(R)は、null になるので、後続「event」は、サブセット化されているはずです。
 言い換えれば、「派遣依頼」がないまま、「受注」が起こりうるか、という点を確認しなければならない。今回は、すべての「派遣依頼」が、「受注」される、とする。

 当然ながら、「event」の関係(aRb)では、「複数の派遣依頼が、1つの受注として、まとめられる」ことがあるかどうか、も確認されなければならない--もし、そうであれば、「対応表」を作らなければならない。

 
 ● 「event」を、(時系列に従って、) 1つずつ読む。
   「resource」が、どのように、関与しているか、という点を確認する。 ...

 「event」を、1つずつ、読む際、どのような「resource」が関与しているか、という点を検証しながら読む。まず、「派遣依頼HDR」では、認知番号と(R)を基礎資料にして、以下の点を確認する。

 (1) 1つの顧客が、複数の派遣依頼をする。
     --> 複数の顧客が、共同して、1つの派遣依頼をすることはないのか。
 (2) 派遣依頼の時点で、就業先と勤務地が申請される。
     --> 同じ就業先で、違う勤務地はないのか。
     --> 違う就業先で、同じ勤務地はないのか。

 
 さらに、「派遣依頼DTL」を観て、以下の点を確認する。

 (1) 1つの勤務地に対して、複数の(1つ以上の)従事業務を申請できる。
     --> 複数の勤務地に対して、1つの従事業務を申請することはないのか。
 (2) 勤務地と従事業務を単位にして、就業曜日を申請する。
     --> 同じ勤務地でも、従事業務が違えば、就業曜日は違うことがあるのか。
     --> 同じ従事業務でも、勤務地が違えば、就業曜日は違うことがあるのか。

 
 すなわち、1つの entity のなかで、(R)どうしの関係(aRb)を検証して、さらに、HDRとDTLのあいだで、(R)どうしの関係(aRb)を確認する。

 
 同じように、「受注」は、以下のように、データを読んで、現実の指示関係を検証しなければならない。

 (1) 受注は、担当者が記録する。
 (2) 受注では、派遣の人数を、正式に同意する。
 (3) 受注では、派遣スタッフごとに、就業日を記録する。

 
 ● 「event」を、(時系列に従って、) 1つずつ読む。アトリビュートを検証する。 ...

 「派遣依頼HDR」 と 「派遣依頼DTL」には、以下の3つの「日付」が記録されている。

 (1) (派遣) 予定日(開始日と終了日)
 (2) (就業) 時刻(開始時刻と終了時刻)
 (3) (休息) 時刻(開始時刻と終了時刻)

 2つの集合があれば、以下の2点を確認することを、以前、述べた。

 (1) 並び (大きい [ > ]、等しい [ = ]、小さい [ < ])
 (2) 包摂関係(A⊃B、B⊃A、A=B、A≠B)

 就業時刻は、1日の時間帯なかでの記述なので、派遣日に対して関係はない。
 就業時刻と休息時刻は、包摂関係が論点になる。すなわち、データを記録する際、以下の2つのいずれであるか、という点が論点になる。

 (1) 就業時刻(9:00〜17:00)、休息時刻(12:00〜13:00)
 (2) 就業時刻(9:00〜12:00)、休息時刻(12:00〜13:00)、就業時刻(13:00〜17:00)

 日々の仕事を、派遣として、1つの就業と考えれば--そして、試験問題のなかで示されている「情報」から判断すれば--、(1)が妥当であるが、休息は、1回のみか(昼食休憩)、という点は論点になるでしょうね--午後3時のリフレッシュがあるかもしれない。実地のデータ設計では、関係(aRb)のなかで起こる・「論理的に考え得る」・すべての事象(並び、と包摂関係)を検証してください。今回は、以下のように、「多義」として扱いましょう。

 派遣依頼HDR
 {派遣依頼番号、(派遣先)顧客コード(R)、(就業先)顧客コード(R)、勤務地コード、
  派遣依頼日}.

 派遣依頼HDR.予定日種別
 {派遣依頼番号(R)、種別コード、予定日}.

 派遣依頼DTL
 {派遣依頼番号、派遣依頼明細番号、(従事)業務コード(R)、就業曜日コード、
  依頼人数}.

 派遣依頼DTL.就業時刻種別
 {派遣依頼番号(R)、派遣依頼明細番号(R)、種別コード、就業時刻}.

 派遣依頼DTL.休息時刻種別
 {派遣依頼番号(R)、派遣依頼明細番号(R)、種別コード、休息時刻}.

 受注DTL
 {受注番号、受注明細番号、派遣依頼番号(R)、派遣依頼明細番号(R)、
  受注人数}.

 受注DTL.スタッフ. 就業日種別
 {受注番号、受注明細番号、派遣スタッフ・コード、種別コード、就業日}.

 
 「スキル要望」は、「派遣依頼」のVEとされているので、以下の点を確認する。

 (1) 「顧客」 が提示する志望条件である。
 (2) 「業務」 の前提条件ではない。

 
 次に、「派遣依頼」と「受注」の関係(aRb)では、以下の2つが検証対象になります。

 (1) 依頼日と受注日
 (2) 依頼人数と受注人数

 (1)では、「依頼日<受注日」でしょうね。(2)では、「大きい・等しい・小さい」のすべてが成立するでしょう。したがって、(1)では、「依頼日<受注日」の validation-rule を記述しなければならないけれど、(2)は、「入力値」として、入力された値を、そのまま、記録することになるでしょう。
 次に、「受注DTL」と「受注DTL. スタッフ」の関係(aRb)では、(「受注DTL」のなかに記述されている) 受注人数と、「受注DTL. スタッフ」のデータ件数は、同じになるのかどうか、という点を検証しなければならない。

 
 さて、「event」の読みかたを述べてきたが、以下に、まとめてみる。

 (1) 「event」の流れを確認する。
   (1)-1 事業過程(管理過程)の検討区域を確認する。
   (1)-2 認知番号のあいだで成立する関係を確認する。
     (「先行『event』が起こらない」ことがあるかどうか、という点に注意する。)

 (2) 1つの「event」のなかで、
   (2)-1 (R)のあいだで成立する関係を確認する。
   (2)-2 アトリビュートのあいだで成立する関係を確認する。

 (3) 2つの「event」--先行「event」と後続「event」--のあいだで、
   (3)-1 (R)のあいだに成立する関係を確認する。
   (3)-2 アトリビュートのあいだに成立する関係を確認する。

 
 関係の検証とは、「論理的に起こりうる、すべての可能性(網羅性)を検証する」ことを云い、SEが理解した点しか検証されていないのは、思い込みの分析(恣意的)にすぎない。関係(aRb)を確認する際、関係のなかで、認知番号、(R)およびアトリビュートに対して、以下の2点を、徹底的に検証すればよい。

 (1) 並び (大きい [ > ]、等しい [ = ]、小さい [ < ])
 (2) 包摂関係(A⊃B、B⊃A、A=B、A≠B)

 
 次回は、同じ試験問題(「tentative modeling」)を使って、「event」に関与する「resource」の読みかたを実演する。

 

ページのトップ
 
  このウインドウを閉じる