▲ このウインドウを閉じる |
● QUESTION | 配属は対照表を使って記述できるが、配属されていない従業員はどう扱えばよいか。 |
▼ ANSWER | 対照表の null値として扱えばよい。 |
「配属」 は、以下のように、対照表を使って記述できる。
従業員 {従業員番号、従業員名称、...}. [ R ] 上述した データ 構造は、「配属されている」 従業員の一覧を記述している。さて、問題点は、「配属されていない」 従業員の一覧を記述するという点にある。
[ 注意 ]
従業員 {従業員番号、従業員名称、...}. [ R ]
以上の データ 構造であれば、「配属されていない」 従業員の一覧を得ることはたやすい。 さて、「配属されていない」 従業員を記述するために、リレーションシップ の 「ゼロ の cardinality」 を記述することが多いようである。しかし、リレーションシップ の「ゼロ の cardinality」 を記述したからといって、アルゴリズム が コンパクト になる訳ではない。つまり、従業員の セット (集合) のなかから 「配属されている」 従業員の サブセット (部分集合) の補集合を演算する、という アルゴリズム は コンパクト にはならない (当然ながら、パフォーマンス も悪い)。 対照表は真理値表である。とすれば、以下の 4つの事象が 「可能」 態として考慮される。
(1) (T, T)
T は 「true」 を意味して、F は 「false」 を意味する。言い換えれば、F は 「null」 を意味する。
(1) {従業員番号 (R)、部門 コード (R)、配属日、...}.
とすれば、(2) の サブセット {従業員番号 (R)、...} が 「配属されていない」 従業員を記述している。
さて、ここで論点になるのは {従業員番号 (R)、...} が 「データ の冗長性」 ではないか、という点である。
しかしながら、{従業員番号、...} [ 従業員 entity ] と{従業員番号 (R)、...} [ 配属 ] はちがう。 関係を関数として扱わないT字形 ER手法は、データ の正規形 (標準形) として、主選言標準形を前提にしている。主選言標準形は、以下のように、「恒真」 の連言から導出される。なお、「恒真」 を 「I」 という略語を使って記述する。 I ≡ (p ∨ ¬p) ∧ (q ∨ ¬q) ≡ (p ∧ q) ∨ (p ∧ ¬q) ∨ (¬p ∧ q) ∨ (¬p ∧ ¬q). [ (T ∧ T) ∨ (T ∧ F) ∨ (F ∧ T) ∨ (F ∧ F) あるいは (1 ∧ 1) ∨ (1 ∧ 0) ∨ (0 ∧ 1) ∨ (0 ∧ 0) として考えればよい。] 対照表は真理値表である。主選言標準形は真理値表を使った真偽を検証しやすい。したがって、対照表を使って主選言標準形を形成することができる。
述語論理を使って集合を認知して、関係を関数として扱う前提では、対照表は アルゴリズム のなかで扱うのが正当である。いっぽう、命題論理を使って集合を認知して、関係を関数としない--「個体と関係は同一 レベル にある」 と考える--前提では、対照表は真理値表として作用する。 |
[ 補遺 ] (2007年 7月16日)
「配属されていない従業員」 を 「T之字」 記法で記述すれば以下のようになる。
┌─────────────────┐ │ 従業員. 部門. 対照表 │ ├────────┬────────┤ │従業員番号(R)│ │ │部門コード(R)│ │ │ │ │ └────────┼────────┘ | × null (部門コード) | ┌───────────┴───────────┐ | | ┌────────┴────────┐ ┌────────┴────────┐ │ 配 属 │ │ 配属されていない従業員 │ ├────────┬────────┤ ├────────┬────────┤ │従業員番号(R)│ │ │従業員番号(R)│ │ │部門コード(R)│ │ │ │ │ │ │ │ │ │ │ └────────┴────────┘ └────────┴────────┘ もし、対照表が、認知番号を付与されて event として記述されたとしたら、それでも、件のひとは、以下の構造を 「データ の冗長」 というのかしら。
┌─────────────────┐ │ 配 属 E│ ├────────┬────────┤ │配属番号 │ │ │従業員番号(R)│ │ │部門コード(R)│ │ └────────┼────────┘ | × null (配属番号、部門コード) | ┌───────────┴───────────┐ | | ┌────────┴────────┐ ┌────────┴────────┐ │ 配 属 │ │ 配属されていない従業員 │ ├────────┬────────┤ ├────────┬────────┤ |配属番号 | | |従業員番号(R)| | │従業員番号(R)│ │ │ │ │ │部門コード(R)│ │ │ │ │ │ │ │ │ │ │ └────────┴────────┘ └────────┴────────┘ ただし、「配属」 を言及している対照表は事実的な 「F-真」 ですが、「配属されていない従業員」 は、「配属」 の場合分けであっても、「event」 を示していないので、導出的な 「L-真」 です。したがって、「従業員」 entity のなかから、「配属」 entity に関与している従業員の補集合として計算するのが正当な やりかた です。 なお、「赤本」 のなかで記した 「『event』 の並びの例外」 (158ページ - 159 ページ) に対して--その例題でも、null を扱っていますが--、或る Wiki では、「奇怪だ」 などと非難されていたそうですが (笑) -- 私は、その Wiki に記載された文を読んでいないので、又聞きですが--、その非難も、はたして、TM の前提を理解しているのかどうか疑わしいですね。じぶんが立っている前提で、(それとは前提の違う) TM を憶測して当てずっぽうに批評されるのは、はなはだ迷惑です。 |
▼ このウインドウを閉じる |