● 提示されたテーマは ...
以下の問題を材料にして、Ｔ字形ＥＲ図の読みかたを、佐藤正美が実演する。
テクニカル・エンジニア（データベース）の試験問題 [ 平成16年度、午後２ 問題１ ]
この試験問題は、データ構造を作る問題ではないが、「ＴＭの会」のメンバーが、「tentative modeling」として作ったデータ構造を、意味論の観点に立って、proofreading （添削、校正）する やりかた を、佐藤正美が実演する。
なお、前回（２月１７日）の「作成手順」のなかで述べたが、データ構造は、正確な構造を、一気に作ることを考えないで、まず、「ルール・ベース（生成規則）」に従って、骨組みを作って、次第に、整えてゆく、という作りかたが良い。
したがって、正しいデータ構造を作るためには、Ｔ字形ＥＲ図を、（「tentative modeling」を起点にして、）データの「意味」を確認しながら、数回、書き直すことになる。喩えてみれば、画家が、対象を的確に描くために、デッサンのなかで、大まかな骨組みを描いて、次第に、詳細に描いてゆき、「正しい１つの線」を探すために、いくつもの線を試すことに似ている。
● 意味論は、「指示関係」を問う ...
まず、意味論の観点に立って、データ構造を検証する際、注意しなければならない点は、「表現関係（意義）」と「指示関係（意味）」を混同してはいけない、という点である。
ポパー氏が提示した「第３世界のモデル」を、以下に示して、「意義」 と 「意味」 の違いを確認する。
（１） 第１世界（物的世界、現実的事実--経営過程）
（２） 第２世界（心的世界、認識主体の世界）
（３） 第３世界（論理的世界、モデル--データ構造）
第１世界と第２世界のあいだでは、（認識主体が、現実的事実を観て、認識主体のなかに、内的な「像」が描かれ、）「像」が論点になる。そして、第２世界と第３世界とのあいだに成立する関係は、「表現関係」である。「表現関係」では、「意義」が論点になる。たとえば、以下の文が、「意義」を記述している。
（１） 明けの明星は、太陽によって照らされる物体である。
（２） 宵の明星は、太陽によって照らされる物体である。
「明けの明星」と「宵の明星」は、「意義」であって、「意味」ではない。それを論証した人物が、フレーゲ氏である。「明けの明星」も「宵の明星」も、指示している物体は、同じ対象（「金星」）である。すなわち、第３世界と第１世界とのあいだに成立する指示関係を問うのが「意味」であり、指示関係を論点にするのが「意味論」である。「意義」（「表現関係」）を記述するのが「意味論」ではない。
[ 参考 ]
フレーゲ氏の云う「意義」は、現代の通説では、「意味」として理解されている。
ただし、そういう「意味」は、「指示規則」と混同されてはならない。
ポパー氏の「第３世界のモデル」を前提にすれば、以下の３つの認識が論点になる。
（１） 像に関与する。
（２） 意義に関与するが、意味に関与しない。
（３） 意味に関与する。
「意味論」とは、（３）の指示関係を扱う領域であって、「意義」が論点になるのではない。
したがって、「entity」が、まず、定立されて、「entity」の指示関係を検証してあるならば、「entity」を前提にして、導出規則に従って構造を作るならば、認知番号の名称を継承するのが正しい。たとえば、「tentative modeling」では、「顧客」entity の再帰として、「派遣先顧客コード（Ｒ）」 と 「就業先顧客コード（Ｒ）」 というふうに記述されているが、（それらは、「意義」であって、「顧客」entityが、「顧客コード」を使って定立されているのだから、）導出関係のなかで、「意味」を示すためには、いずれも、「顧客コード（Ｒ）」とするのが正しい。
ただし、「意義」を記述してあれば、理解しやすいので、「（派遣先）顧客コード（Ｒ）」とか「（就業先）顧客コード（Ｒ）」というふうに記述してあっても、間違いではない。
「意義」 と 「意味」の関係では、同じようなことが、（「tentative modeling」のなかで記述されているが、）「（就業開始）時刻」 と 「（就業終了）時刻」でも論点になる。「時刻」を、パラメータ（変項）として扱い、２つの「時刻」を「多義」として扱うのが正しい やりかた であるが、以下のように、記述しても、（指示関係を意識しているなら、）小生は、黙認する。
派遣依頼ＤＴＬ ｛派遣依頼番号、...就業開始時刻、就業終了時刻、...｝.
● Ｔ字形ＥＲ図を読む際、まず、「event」の流れを読む ...
「意味論」的な検証をする前に、かならず、以下の形式的な確認をしてください。
（１） 指示規則（認知番号は、「実存する」コードを使っているかどうか）。
（２） 生成規則（ａＲｂのなかで、「event」が時系列に並べられているかどうか）。
往々にして、「実存しない」認知番号を使って、「entity」を生成していることがあるので、注意されたい--「実存しない」認知番号を使って、entity を認知することは、「みなし」entity として扱われているはずである。
形式的に妥当でない構造は、指示関係を検証する際、（ＳＥの恣意性が、多大に混入しているので、「（事業の）事実と（ＳＥの）意見」を切り離すために、）無駄な手数を費やすことになる。形式的に妥当な構造でないなら--「entity」として、指示関係が、まず、検証されていないなら--、「意味論的」な添削をはじめてはいけない。
Ｔ字形ＥＲ図（データベース設計）の勝負点は--事業過程（正確には、管理過程）に対して、代替案・改善案を探すには--、「resource」であるが、「現状を確認するために」、Ｔ字形ＥＲ図を読む際、まず、以下のように、「event」を読んで、事業過程を確認する。
（１） 「event」の流れを検証して、事業構成を確認する。
（２） 「event」に対して、どのような「resource」が関与しているか、という点を確認する。
「Tentative modeling」では、以下の「event」構成になっている。
派遣依頼ＨＤＲ
｛派遣依頼番号、（派遣先）顧客コード（Ｒ）、（就業先）顧客コード（Ｒ）、勤務地コード、
派遣依頼日、開始予定日、終了予定日｝.
派遣依頼ＤＴＬ
｛派遣依頼番号、派遣依頼明細番号、（従事）業務コード（Ｒ）、就業曜日コード、
就業開始時刻、就業終了時刻、休息開始時刻、休息終了時刻、依頼人数｝.
受注ＨＤＲ
｛受注番号、派遣依頼番号（Ｒ）、担当者コード（Ｒ）、
受注日｝.
受注ＤＴＬ
｛受注番号、受注明細番号、派遣依頼番号（Ｒ）、派遣依頼明細番号（Ｒ）、
受注人数｝.
受注ＤＴＬは、さらに、以下のＨＤＲになっている。
受注ＤＴＬ.スタッフ（受注ＤＴＬのＤＴＬ）
｛受注番号、受注明細番号、派遣スタッフ・コード、
就業開始日、就業終了日｝.
さて、まず、「event」の流れを観て、「派遣依頼と受注」に関する領域（区域）を検討対象にしていることを、作成者（たぶん、ユーザ企業のＤＡ）に対して、確認する。どうして、このような確認をするかといえば、たとえば、のちのち、「請求」の区域を扱うとき、「請求」entity が「受注」entity に対して、（ａＲｂのなかで、） なんらかの制約事項を示すかもしれないけれど、（「請求」entity が、確実に、記述されないかぎり、「受注」entity と「請求」entity のあいだに成立する関係のなかで、「前提（baseline）」の網羅性を検証できないので、） 「請求」entity を射程距離のなかに置いた推測的記述を排除するためである。
もし、そういう制約事項があるのなら、「請求」を検討する際、「受注」を修正すれば良い。あるいは、もし、そういう制約事項も、「受注」のなかに記述しなければならない、というのであれば、「請求」も、今回、検討対象にしなければならない。
「Tentative modeling」では、１つの「派遣依頼」に対して、複数の（１つ以上の）「受注」が起こる、というふうに記述されている。すべての「派遣依頼」が、すべて、「受注」されることはない、と想像できるので、「受注」には、「（relationship の）ゼロの cardilality」を示したほうが良いでしょうね--ただ、小生は、「ゼロの cardinality」を観ていないけれど（笑）--データとして、実際には起こらなかった、ということにすぎないのですが--、プログラマが、テスト・データを作る際、参考になるので、記述しておいたほうがいいでしょうね。ちなみに、先行「event」のほうに、「ゼロの cardinality」が起こる際には、後続「event」の（Ｒ）は、null になるので、後続「event」は、サブセット化されているはずです。
言い換えれば、「派遣依頼」がないまま、「受注」が起こりうるか、という点を確認しなければならない。今回は、すべての「派遣依頼」が、「受注」される、とする。
当然ながら、「event」の関係（ａＲｂ）では、「複数の派遣依頼が、１つの受注として、まとめられる」ことがあるかどうか、も確認されなければならない--もし、そうであれば、「対応表」を作らなければならない。
● 「event」を、（時系列に従って、） １つずつ読む。
「resource」が、どのように、関与しているか、という点を確認する。 ...
「event」を、１つずつ、読む際、どのような「resource」が関与しているか、という点を検証しながら読む。まず、「派遣依頼ＨＤＲ」では、認知番号と（Ｒ）を基礎資料にして、以下の点を確認する。
（１） １つの顧客が、複数の派遣依頼をする。
--> 複数の顧客が、共同して、１つの派遣依頼をすることはないのか。
（２） 派遣依頼の時点で、就業先と勤務地が申請される。
--> 同じ就業先で、違う勤務地はないのか。
--> 違う就業先で、同じ勤務地はないのか。
さらに、「派遣依頼ＤＴＬ」を観て、以下の点を確認する。
（１） １つの勤務地に対して、複数の（１つ以上の）従事業務を申請できる。
--> 複数の勤務地に対して、１つの従事業務を申請することはないのか。
（２） 勤務地と従事業務を単位にして、就業曜日を申請する。
--> 同じ勤務地でも、従事業務が違えば、就業曜日は違うことがあるのか。
--> 同じ従事業務でも、勤務地が違えば、就業曜日は違うことがあるのか。
すなわち、１つの entity のなかで、（Ｒ）どうしの関係（ａＲｂ）を検証して、さらに、ＨＤＲとＤＴＬのあいだで、（Ｒ）どうしの関係（ａＲｂ）を確認する。
同じように、「受注」は、以下のように、データを読んで、現実の指示関係を検証しなければならない。
（１） 受注は、担当者が記録する。
（２） 受注では、派遣の人数を、正式に同意する。
（３） 受注では、派遣スタッフごとに、就業日を記録する。
● 「event」を、（時系列に従って、） １つずつ読む。アトリビュートを検証する。 ...
「派遣依頼ＨＤＲ」 と 「派遣依頼ＤＴＬ」には、以下の３つの「日付」が記録されている。
（１） （派遣） 予定日（開始日と終了日）
（２） （就業） 時刻（開始時刻と終了時刻）
（３） （休息） 時刻（開始時刻と終了時刻）
２つの集合があれば、以下の２点を確認することを、以前、述べた。
（１） 並び （大きい [ ＞ ]、等しい [ ＝ ]、小さい [ ＜ ]）
（２） 包摂関係（Ａ⊃Ｂ、Ｂ⊃Ａ、Ａ＝Ｂ、Ａ≠Ｂ）
就業時刻は、１日の時間帯なかでの記述なので、派遣日に対して関係はない。
就業時刻と休息時刻は、包摂関係が論点になる。すなわち、データを記録する際、以下の２つのいずれであるか、という点が論点になる。
（１） 就業時刻（9:00〜17:00）、休息時刻（12:00〜13:00）
（２） 就業時刻（9:00〜12:00）、休息時刻（12:00〜13:00）、就業時刻（13:00〜17:00）
日々の仕事を、派遣として、１つの就業と考えれば--そして、試験問題のなかで示されている「情報」から判断すれば--、（１）が妥当であるが、休息は、１回のみか（昼食休憩）、という点は論点になるでしょうね--午後３時のリフレッシュがあるかもしれない。実地のデータ設計では、関係（ａＲｂ）のなかで起こる・「論理的に考え得る」・すべての事象（並び、と包摂関係）を検証してください。今回は、以下のように、「多義」として扱いましょう。
派遣依頼ＨＤＲ
｛派遣依頼番号、（派遣先）顧客コード（Ｒ）、（就業先）顧客コード（Ｒ）、勤務地コード、
派遣依頼日｝.
派遣依頼ＨＤＲ.予定日種別
｛派遣依頼番号（Ｒ）、種別コード、予定日｝.
派遣依頼ＤＴＬ
｛派遣依頼番号、派遣依頼明細番号、（従事）業務コード（Ｒ）、就業曜日コード、
依頼人数｝.
派遣依頼ＤＴＬ.就業時刻種別
｛派遣依頼番号（Ｒ）、派遣依頼明細番号（Ｒ）、種別コード、就業時刻｝.
派遣依頼ＤＴＬ.休息時刻種別
｛派遣依頼番号（Ｒ）、派遣依頼明細番号（Ｒ）、種別コード、休息時刻｝.
受注ＤＴＬ
｛受注番号、受注明細番号、派遣依頼番号（Ｒ）、派遣依頼明細番号（Ｒ）、
受注人数｝.
受注ＤＴＬ.スタッフ. 就業日種別
｛受注番号、受注明細番号、派遣スタッフ・コード、種別コード、就業日｝.
「スキル要望」は、「派遣依頼」のＶＥとされているので、以下の点を確認する。
（１） 「顧客」 が提示する志望条件である。
（２） 「業務」 の前提条件ではない。
次に、「派遣依頼」と「受注」の関係（ａＲｂ）では、以下の２つが検証対象になります。
（１） 依頼日と受注日
（２） 依頼人数と受注人数
（１）では、「依頼日＜受注日」でしょうね。（２）では、「大きい・等しい・小さい」のすべてが成立するでしょう。したがって、（１）では、「依頼日＜受注日」の validation-rule を記述しなければならないけれど、（２）は、「入力値」として、入力された値を、そのまま、記録することになるでしょう。
次に、「受注ＤＴＬ」と「受注ＤＴＬ. スタッフ」の関係（ａＲｂ）では、（「受注ＤＴＬ」のなかに記述されている） 受注人数と、「受注ＤＴＬ. スタッフ」のデータ件数は、同じになるのかどうか、という点を検証しなければならない。
さて、「event」の読みかたを述べてきたが、以下に、まとめてみる。
（１） 「event」の流れを確認する。
（１）-１ 事業過程（管理過程）の検討区域を確認する。
（１）-２ 認知番号のあいだで成立する関係を確認する。
（「先行『event』が起こらない」ことがあるかどうか、という点に注意する。）
（２） １つの「event」のなかで、
（２）-１ （Ｒ）のあいだで成立する関係を確認する。
（２）-２ アトリビュートのあいだで成立する関係を確認する。
（３） ２つの「event」--先行「event」と後続「event」--のあいだで、
（３）-１ （Ｒ）のあいだに成立する関係を確認する。
（３）-２ アトリビュートのあいだに成立する関係を確認する。
関係の検証とは、「論理的に起こりうる、すべての可能性（網羅性）を検証する」ことを云い、ＳＥが理解した点しか検証されていないのは、思い込みの分析（恣意的）にすぎない。関係（ａＲｂ）を確認する際、関係のなかで、認知番号、（Ｒ）およびアトリビュートに対して、以下の２点を、徹底的に検証すればよい。
（１） 並び （大きい [ ＞ ]、等しい [ ＝ ]、小さい [ ＜ ]）
（２） 包摂関係（Ａ⊃Ｂ、Ｂ⊃Ａ、Ａ＝Ｂ、Ａ≠Ｂ）
次回は、同じ試験問題（「tentative modeling」）を使って、「event」に関与する「resource」の読みかたを実演する。