エンティティの見出し方・属性の割り振り方 - 伝統的設計・T字形ER手法・ABD
非正規形の表が与えられたときに、その表を出力できるDBをどうやって設計するか。
伝統的DB設計法・T字形ER手法・ABDのやり方を並べて書いてみる。
伝統的DB設計法
伝統的なDB設計では、非正規形の表を正規化する過程で、エンティティを切り出していく。
また正規化しながら、関数従属性に従って属性を割り振っていく。
データ項目の意味は考えず、データ項目の重複が最小になるように分解するので、m:nの関係の時以外は交差エンティティは発生せず、「社員マスタに所属部門コードがある」といった結果になる。
T字形ER手法
上記を問題視したのがT字形ER手法。
T字形ER データベース設計技法 P-26
ER手法が大きく勘違いされた点は、データを正規化してから、ER手法を使ってデータ構造を表現する、という点にある。
つまり、ER手法が表現手段に成り下がってしまったのである。ER手法は、思考手段(解析手法)である。表現手段ではない。
この点を確かに理解しないから、「従業員ファイル」の中に部門コードを挿入する、という愚行をやらかすのである。
正規化してからER図を描くんじゃない。ER図を使って「あるべき正規形」を発見せよ、という話。
T字形ではコード体系からresource／eventを割り出し、4つの推論ルールに従って追加的な対照表／再帰表を生成する。器を切ったあとは関数従属性に従って属性を割り振る。
ABD
ABDの場合、エンティティを切る基準として、関数従属性にもコード体系にも全面的に寄りかかることはない。ではどうするか。
エンティティは resource/event/IRE(activity) の3種類。
資料によれぱ、resource/event の切り出し方はこう：
- 「ｘｘする」「ｘｘ日」といえる --> event
- 「ｘｘ名」といえる --> resource
ここまでは普通。変わっているのは属性の割り振りで、IDに関数従属しているデータ項目であっても、それが外部キーであれば、IREを生成してそこに追放する。
IREの一部は activity と呼ばれる（多分、全部が全部 activity にはならないと思う）。activity は業務ごとに＝「同じタイミングで使うもの」ごとに切る。つまりDB設計の開始時点で業務フローが見えている必要がある。
