●　提示されたテーマは ... 　以下の問題を材料にして、Ｔ字形ＥＲ図の作成手順を、佐藤正美が実演する。 　テクニカル・エンジニア（データベース）の試験問題 [ 平成13年度、春期 午後�T問題 ] 　 　●　Ｔ字形ＥＲ図は、いったん、作成したあとで、丁寧に、推敲する ... 　Ｔ字形ＥＲ図を効率的・効果的に作成するには、まず、（生成規則にしたがって、） ざっと、素描して、それから、丁寧に、推敲する、というやりかたが良い。言い換えれば、entity を、１つずつ、丁寧に、作成しないで、まず、「ルール・ベース（生成規則）」にしたがって、まとまった「構造」を作ることが、作成のコツである。 　というのは、データの「意味」は、「構造」（「全体と個」という関係） のなかで--言い換えれば、実際に使用されている文脈のなかで--成立するので、つねに、「全体と個」という関係を意識していなければ、「意味」を把握できない。データ項目を、１つずつ、検討しながら、「意味」を理解しようとしても、むずかしい。 　したがって、Ｔ字形ＥＲ図を作成するためには、以下の手順をとる。 　１. まず、生成規則にしたがって、作成する （構文論的な tentative modeling）。 　　　　１-１. entity を作る。 　　　　１-２. relationship を作る。 　２. 次に、指示規則にしたがって、推敲する （意味論的な proofreading）。 　　　　２-１. entity を検証する。 　　　　２-２. relationship を検証する。 　 　●　コンサルタントは、命題論理方式を使う ... 　Ｔ字形ＥＲ図の作成方法として、以下の２つがある。 　（１） 命題論理方式 　（２） コード体系方式 　命題論理方式は、「情報（画面や帳票など）」を、１つの単位にして、「１つの複文（情報）を、いくつかの単文（entity）として、ばらす」やりかたである。そして、データ項目を、「しかるべき（due）」 entity のなかに、順次、割り振る やりかた である。 　コード体系方式は、データ項目を、１つずつ、検討して、entity を生成しながら、同時に、データ項目を収録する やりかた である。 　いずれの やりかた も、最終的には、同じアウトプットを生成する。 　それらの やりかた の性質を鑑みれば、ユーザ企業のＤＡは、（データの「意味」を、すでに、或る程度、知っているので、） コード体系方式を使うほうが、やりやすいし、いっぽう、（ユーザ企業のシステム作りを請け負う--したがって、システム作りを依頼されるつど、データ項目を初見で「理解」しなければならない） ソフトウェアハウスは、命題論理方式を使ったほうが、やりやすい。 　小生自身は、実際に作図する際--めったにないことだけれど（笑）--、命題論理方式を使っている。今回の実演では、命題論理方式を使う。 　 　●　まず、１つの情報を単位にして、Ｔ字形を作る ... 　１つの情報を、１つの単位にして、以下のように、Ｔ字形を作る。

	ご利用控え
	店コード	店名称
	利用番号	利用日
	会員番号	品目名称
	品目コード	単価 　　┐
		数量 　　┝ × Ｎ
		利用額　┘
		利用額合計
		消費税
		請求額
		獲得ポイント

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

▲ ページのトップ

▼ このウインドウを閉じる