ビジネスの視点でデータを整理する

連載 :

2010年10月14日(木)

一般的な正規化手法の課題を改善する"正規化簡便法"

一般的な正規化手法における課題の1つは、作業効率です。例えば、第三正規化では、すべての属性の従属関係を総当たりで確認しなければなりません。また、エンティティを分離する際には、リレーションシップの定義も行われることになります。つまり、複数の作業が同時に行われることになります。この結果として、データの抜けや漏れ、重複が生じたり、リレーションシップの定義に必要なビジネス・ルールの確認を忘れるなど、属人的なデータ・モデルとなります。

これらの課題を改善するものが、ここで紹介する正規化簡便法^*1です。

[*1] アシストの4つのモデリング・メソッド「Tetra-Method」に基付く正規化手法。SDIの佐藤正美氏によるTM（T字型ER手法）を参考にしている。

正規化簡便法の大きな特徴は、ビジネス・ルールを抜け漏れなく反映したER図を作成できる点です。複数の作業や曖昧な作業をなくすために、1つの作業を1つの手順として詳細化しているほか、フォーリン・キー設定ルールなどを明示しています。単純なミスが減り、正規化作業の品質が高まります。

正規化簡便法では、表2に示す11の手順に従って作業を行うことで、第3正規化まで完了させることができます。

表2: 正規化簡便法11の手順

手順	作業項目	作業内容
1	識別子の洗い出し	企業が管理対象としたビジネス上の事物や事象、概念を表す識別子を洗い出す。
2	エンティティ名称の決定	識別子から「コード」「番号」「ID」「SEQ」などを除外した属性名をエンティティ名とする。
3	属性の洗い出し	識別子に従属する属性を洗い出す。従属しない属性は、いったんDUMMYエンティティに従属させる。
4	繰り返し項目の確認	手順3で抽出した属性から繰り返し項目群を見つけ出し、新たなエンティティとして分離する。
5	属性間の確認	手順3で抽出した属性間に従属関係がないかチェックし、あれば新たなエンティティとして分離する。
6	導出項目の確認	手順3で抽出した属性が、導出項目（計算結果）かどうかを確認し、導出項目であれば（D）を記入する。
7	エンティティ・タイプの識別	エンティティがリソース系かイベント系かを識別し、リソース系は（R）、イベント系は（E）を記入する。
8	独立性の識別	識別子がエンティティ内で一意性を保証しているかを識別し、一意性がある場合は（U）、一意性がない場合は（N）を記入する。
9	リレーションシップの定義	手順9と手順10は同時に実施する。リレーションシップの定義は、親エンティティのプライマリ・キーを、子エンティティのフォーリン・キーとして設定する。フォーリン・キーは「フォーリン・キー設定ルール」に従って設定する。エンティティ・タイプと、カーディナリティにより設定ルールが異なる。
10	フォーリン・キーの設定
11	DUMMYエンティティの解決	手順3でDUMMYエンティティに従属させた属性の従属先エンティティを決める。

11のステップで、誰でも高品質なデータ・モデルを作成可能

（1）手順1と手順2:「識別子の洗い出しとエンティティ名称の決定」

正規化簡便法の中で最も特徴的な手順が、識別子の洗い出しです。プライマリ・キーではなく、識別子という考え方でデータを整理します。このため、複合キーに悩まされることがありません。

識別子は、多くのデータ群の中からエンティティを識別するIDです。1つの属性だけで構成され、1つの識別子をもとに、1つのエンティティが生成されます。企業が管理対象としたビジネス上の事物や事象、概念には、すべてこの識別子が存在します。

識別子の探し方は簡単です。既存のファイルや帳票／画面の属性名に「コード」や「番号」「ID」「SEQ」などが含まれるものが候補となります。例えば、識別子対象は、「部門コード」や「受注番号」「請求No」「社員ID」「工程SEQ」などであり、「コード」「番号」「ID」「SEQ」を削除してエンティティ名にします。図3の「（2）エンティティ名称の決定」では、「顧客」、「従業員」、「受注」、「商品」がエンティティ名です。

（2）手順3と手順4:「属性の洗い出しと繰り返し項目の確認」

次は、識別子に従属する属性を見つけます。この時、どの識別子にも従属しない属性は、いったん「DUMMYエンティティ」というものを作成して、そこに移動します。DUMMYエンティティには、複合キーにしか従属できない属性が従属します。

例えば、図3の「（3）属性の洗い出し」と「（4）DUMMYエンティティ」における受注数量と商品小計は、どの識別子にも従属しないので、DUMMYエンティティに移動します。これらは、受注番号と商品番号があって初めて一意になるからです。

次に、属性の中から繰り返し項目を見つけ、新たなエンティティとして分離します（この例では、対象がありません）。ほとんどの繰り返し項目には、それを識別するための識別子があります。手順1の段階で概ね分離されるので、ここでは他にも繰り返し項目がないかどうかをチェックします。

（3）手順5と手順6:「属性間の確認と導出項目の確認」

手順3で洗い出した属性間に従属関係がないかを確認し、あれば新たなエンティティとして分離します（この例では、対象がありません）。ここも、手順1の段階で概ね分離されるので、作業に抜けや漏れがないかをチェックするだけです。

また、手順3で洗い出した属性が、導出項目（計算結果）かどうかを確認し、導出項目であれば属性に（D）というマークを記入します。図3の「（5）導出項目の確認」では、商品小計、受注合計が該当します。

（4）手順7と手順8:「エンティティ・タイプの識別と独立性の識別」

エンティティはリソース系（顧客、商品といった事物）かイベント系（発注、受注、請求といった行為）に大別されます。手順1で洗い出したエンティティがリソース系であれば（R）を、イベント系であれば（E）を記入します。さらに、エンティティの背景色を分けるなどして識別します。図3の「（6）エンティティ・タイプの識別」では、顧客、従業員、商品が（R）、受注は（E）です。

次に、手順1で洗い出した識別子が、そのエンティティ内において一意であれば（U)を、一意でなければ（N）を記入します。今回の例では、すべてが一意性を保証するため、（U）が記入されています。通常は、ほとんどのエンティティが（U）となるため、（N）のみを記入するようにします。図3の「（7）独立性の識別」では、すべてが（U）となります。