2001年 8月15日 | 「カレンダー」 の扱い | >> 目次 (テーマごと) |
● QUESTION | Identifier の附番されていない「カレンダー」は、どう扱えば良いのか。 | |
▼ ANSWER | VE (「みなし entity」) として扱えばよい。 | |
2006年 9月16日 補遺 |
1. 具体例 (その 1 ) [ 部門単位に カレンダー が設定されている ]
┌───────────────────────┐ │ 部 門 R│ ├───────────┬───────────┤ │部門コード │部門名称 │ │ │ │ └───────────┴───────────┘ ┌───────────────────────┐ │ 部門. カレンダー VE│ ├───────────┬───────────┤ │部門コード(R) │年月日 │ │ │ │ └───────────┴───────────┘ |
□ もし、カレンダー のなかに 「稼働日・非稼働日区分 コード」 があれば、VE のなかで、「稼働日」 と 「非稼働日」 の
サブセ ット を生成すればよい。 |
2. 具体例 (その 2) [ 個人単位に カレンダー が設定されている ]
┌───────────────────────┐ │ 従業員 R│ ├───────────┬───────────┤ │従業員番号 │従業員名称 │ │ │ │ └───────────┴───────────┘ ┌───────────────────────┐ │ 従業員. カレンダー VE│ ├───────────┬───────────┤ │従業員番号(R) │年月日 │ │ │ │ └───────────┴───────────┘ |
□ もし、カレンダー のなかに 「稼働日・非稼働日区分 コード」 があれば、VE のなかで、「稼働日」 と 「非稼働日」 の
サブセ ット を生成すればよい。 |
[ 補遺 ] (2006年 9月16日)
「日付」 が認知番号 (identifier) にならないことは、かつて、述べた (29ページ 参照)。 ┌───────────────────────┐ │ 従業員 R│ ├───────────┬───────────┤ │従業員番号 │従業員名称 │ │ │ │ └───────────┴───────────┘ ┌───────────────────────┐ │ 従業員. カレンダー VE│ ├───────────┬───────────┤ │従業員番号(R) │年月日 │ │ │ │ └───────────┴───────────┘ ┌───────────────────────┐ │ 従業員. 出勤簿 VE│ ├───────────┬───────────┤ │従業員番号(R) │年月日 │ │ │ │ └───────────┴───────────┘ ┌───────────────────────┐ │ 従業員. 出勤簿. 就業時間 MO│ ├───────────┬───────────┤ │従業員番号(R) │時刻 │ │ │ │ └───────────┴───────────┘ちなみに、「従業員. 出勤簿. 就業時間」は、MO (Multi-value OR、多値の 「OR」 関係) として、2つ以上の時刻 (少なくとも、出社時刻と退社時刻) が記録される。 以上に述べた 「出勤簿」 は、あくまで、「出勤簿」 を扱うザッとした考えかたを示しているにすぎない。というのは、私は、いくつかの企業 (clients) で 「出勤簿」 を観てきたが、それぞれの企業が 「出勤簿」 を工夫していて、「出勤簿」 の データ 構造に関して、同一の構造を観たことがない。(「パターン」 で割り切れるほどに 「出勤簿」 の構造は単純ではないのであって、) それぞれの事実に即して データ 構造を作るしかない。 |
<< もどる | HOME | すすむ >> | |
データ解析に関するFAQ |