その際、「繰返項目」に対しては、(繰り返されるデータ項目群を単位にして、) 「× N」 というふうに、示す。
そして、データ項目に対する「注釈」を読まないで、いったん、entity を作る。Entity は、認知番号を判断規準にして、以下のように、4つになる。
店 {店コード}.
利用 {利用番号}.
会員 {会員番号}.
品目 {品目コード}.
● 「E」項目と「P」項目を切り離す ...
次に、アトリビュート(データ項目)を、「しかるべき(due)」 entity のなかに転記する。
その際、以下の2点を、おおよそ、判断する。
(1) entity に帰属する性質か。
(2) 「関係」に帰属する性質か。
「関係」に帰属する性質は、entity に帰属しないので、(「構造」を、いったん、生成したあとで、「しかるべき」 うつわのなかに入れなければならないので、) とりあえず、うっちゃっておけば良い。また、「意味」のわからない項目や、「意味」を理解できるが、帰属すべき entity がない項目も、うっちゃっておけば良い。
以後、entity に帰属する性質を「E」項目として、「うっちゃっておけば良い」ということを「P」項目として、略称する。
(1) 「利用日」は、「利用. 日」として、「利用」 entity の「E」項目である。
(2) 「品目名称」は、「品目. 名称」として、「品目」 entity の「E」項目である。
(3) 「単価」「数量」および「利用額」は、「繰返項目」として、1つの単位になっている。
「単価」は、「時価」(同じ品目でも、利用のつど、値段が変わる)である。
かつ、「利用額」は、「利用. 額」として、「利用」 entity の「E」項目である。
したがって、「繰返項目」は、「利用」 entity の「E」項目である。
(4) 「利用額合計」は、「利用」 entity の「利用額」を合計した導出項目である。
したがって、「利用」 entity には帰属しない(「P」項目)。
(5) 「消費税」は、「利用額合計」に対する導出項目である。
「利用額合計」を、「P」項目にしているので、これも、「P」項目にする。
(6) 「請求額」は、(「請求番号」がないので、)帰属する entity がない(「P」項目)。
(7) 「獲得ポイント」の「意味」は、いまの時点では、わからない(「P」項目)。
したがって、現時点では、entity は、以下のようになる。
そして、この時点で、entity を、「event」と「resource」として、仕訳する。
店 {店コード、店名称}[ R ].
利用 {利用番号、利用日、単価、数量、利用額}[ E ].
会員 {会員番号}[ R ].
品目 {品目コード、品目名称}[ R ].
[ 参考 ] もし、日々、変わる単価を記録しておくのであれば、以下のようにすれば良い。
品目{品目コード、品目名称}[ R ]. 品目.単価 {品目コード(R)、単価、年月日}[ VE ].
● relationship を作る ...
とりあえず、entity を作ったら、次に、relationship を作る。
「ご利用控え」を観て、以下の点を判断できる。
(1) 「店」に対して、(クレジットカードを)「利用」する。
(2) 「会員」が、(クレジットカードを)「利用」する。
(3) 「品目」に対して、(クレジットカードを)「利用」する。
したがって、以下の構成となる。
店
{店コード、店名称}[ R ].
利用
{利用番号、店コード(R)、会員番号(R)、品目コード(R)、利用日、単価、数量、利用額}[ E ].
会員
{会員番号}[ R ].
品目
{品目コード、品目名称}[ R ].
● 「P」項目を、「しかるべき」うつわ に入れる ...
いったん、構成が、できたので、「P」項目を、「しかるべき」うつわ に入れる。
まず、「利用額合計」を考える。「利用額合計」は、「利用額」の合計となる導出項目である。したがって、以下のように、「利用」 entity に対する導出VEを考えてみる。
ちなみに、導出項目に対しては、(D) を付与する。
利用の sum
{利用番号(R)、利用額合計(D)}.
利用
{利用番号、店コード(R)、会員番号(R)、品目コード(R)、利用日、単価、数量、利用額}
.
しかし、このままの構成では、「利用」 entity のなかで、店コードと会員番号が、「繰返項目」の数と同じ数で、繰り返されることになってしまう。言い換えれば、構文論的に、妥当ではない。したがって、この時点で、「HDR-DTL」構造になる、ということに気づかなければならない。したがって、以下の構成となる。
利用HDR
{利用番号、店コード(R)、会員番号(R)、利用日、利用額合計(D)}[ E ].
利用DTL
{利用番号、品目コード(R)、単価、数量、利用額}[ E ].
消費税は、「利用額合計」に対する導出項目である。
請求額は、(請求番号が、この資料では指示されていないので、)「利用HDR」に対する「VE」とする。
利用HDR
{利用番号、店コード(R)、会員番号(R)、利用日、利用額合計(D)、消費税(D)}.
利用DTL
{利用番号、品目コード(R)、単価、数量、利用額}.
利用. 請求
{利用番号(R)、請求額}[ VE ].
この時点になっても、「獲得ポイント」の「意味」は、わからない。
Tentative modeling が終わったので--そして、「意味」の把握できないデータ項目があるので--、いよいよ、エンドユーザと面談して、モデルを推敲する。
なお、Tentative modeling では、データ構造は、以下のようになっている。
店
{店コード、店名称}[ R ].
利用HDR
{利用番号、店コード(R)、会員番号(R)、利用日、利用額合計(D)、消費税(D)}.
利用DTL
{利用番号、品目コード(R)、単価、数量、利用額}.
利用. 請求
{利用番号(R)、請求額}[ VE ].
会員
{会員番号}[ R ].
品目
{品目コード、品目名称}[ R ].
● エンドユーザと面談して、モデルを推敲する ...
実際の modeling では、エンドユーザと面談して、いまだ、対応できていない「P」項目に対して、収めるべき場所 (うつわ) を検討する。今回の資料は、試験問題なので、「注釈」が、エンドユーザの代用だと思えば良い。「注釈」を読めば、以下の「新しい」概念が提示されている。
{ポイント区分、ポイント率、基本ポイント率、前回未引落額、年間利用累計額、利用限度額}.
品目には、「ポイント区分」が定められて、通常販売品とバーゲン品と除外品という3種類があるので、以下の構成とする。
品目 [ R ]
|
× (ポイント区分コード)
│
├{通常販売品//品目コード、品目名称、ポイント区分コード}
│
├{バーゲン品//品目コード、品目名称、ポイント区分コード、ポイント率}
│
└{除外品//品目コード、品目名称、ポイント区分コード}
ちなみに、通常販売品のポイント率は、基本ポイント率として、カードの年間利用(20万円未満、50万円未満、100万円未満、100万円以上)を考慮して付与され、除外品は、対象外とされている。基本ポイント率を収める場所を作るために--基本ポイント率を導出するための基礎として--、「前回未引落額」と「年間利用累計額」と「利用限度額」を収めるために、以下のように、「しかるべき」うつわ を作る。
会員
{会員番号}[ R ].
会員. 利用限度額
{会員番号(R)、利用限度額}[ VE ].
会員. 前回未引落額
{会員番号(R)、前回未引落額(D)}[ VE ].
会員. 年間利用累計額
{会員番号(R)、年間利用累計額(D)}[ VE ].
会員. 基本ポイント率
{会員番号(R)、基本ポイント率}[ VE ].
以上の項目が用意されたならば、「獲得ポイント」も計算できるので、以下の構成を作る。
利用HDR
{利用番号、店コード(R)、会員番号(R)、利用日、利用額合計(D)、消費税(D)、獲得ポイント(D)}[ E ].
利用DTL
{利用番号、品目コード(R)、単価、数量、利用額}[ E ].
利用. 請求
{利用番号(R)、請求額}[ VE ].
● Tentative modeling の最終案...
店
{店コード、店名称}[ R ].
会員
{会員番号}[ R ].
会員. 利用限度額
{会員番号(R)、利用限度額}[ VE ].
会員. 前回未引落額
{会員番号(R)、前回未引落額(D)}[ VE ].
会員. 年間利用累計額
{会員番号(R)、年間利用累計額(D)}[ VE ].
会員. 基本ポイント率
{会員番号(R)、基本ポイント率}[ VE ].
品目 [ R ]
|
× (ポイント区分コード)
│
├{通常販売品//品目コード、品目名称、ポイント区分コード}
│
├{バーゲン品//品目コード、品目名称、ポイント区分コード、ポイント率}
│
└{除外品//品目コード、品目名称、ポイント区分コード}
利用HDR
{利用番号、店コード(R)、会員番号(R)、利用日、利用額合計(D)、消費税(D)、獲得ポイント(D)}[ E ].
利用DTL
{利用番号、品目コード(R)、単価、数量、利用額}[ E ].
利用. 請求
{利用番号(R)、請求額}[ VE ].
[ 注意 ] (D)は、アトリビュート・リストを作成するまで、排除しない。
以上の構成が、Tentative Modeling の最終案です。
この程度の(簡単な)問題であれば、実演したような やりかた を、わざわざ、使わないでも、15分くらいもあれば、最終案を作ることができるでしょう(--あるいは、それくらいの実力を養うようにしてください)。
さて、以上の構成を作ることが、T字形ER手法の目的ではない、という点に注意してください。以上の構成は、「T字形ER手法の勝負点」の起点にすぎない。実地のデータ設計では、以上の構成を作ったあとで、いよいよ、以下の2点を狙った勝負がはじまるのです。
(1) 現状の問題点を探す。
(2) 改善案を提言する。
そのためには、T字形ER図を、丁寧に、読まなければならない。
T字形ER図の読みかたを、次回、実演しましょう。