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

連載 :

2010年10月14日(木)

論理データ・モデリングでデータを細かく整理

論理データ・モデリングでは、前工程で作成した概念データ・モデルをベースに、システム化の対象範囲にあるデータを細かく整理していきます。ビジネスの進む方向に沿って、決まったルールに則ってデータを整理し（正規化）、重複を排除し（最適化）、誰でも使えるように項目を直し（一般化）、さらに将来的なビジネスの変化に迅速に対応できるよう「安定性検証」を行います。

図1: 論理データ・モデリングの流れ（クリックで拡大）

（1）正規化

正規化とは、「One Fact in One Place（1つの事実は1つの場所に）」の考えに基づいて、論理的に矛盾のないデータ構造を構築するために、段階的にデータの関係を検証していく作業です。正規化は、1ファイルずつ実施するため、整理対象の数が膨大になることもあります。

正規化で重要なポイントは、誰が実施しても均一な品質を維持できるようにすることです。データの標準化がなされていれば最善ですが、そのようなことは稀なので、事前準備をしっかりしておくことが必要です。例えば、「データを整理する前に、業務が分かるユーザーにデータの意味をヒアリングするか、そのユーザーを設計工程に参画させる」などです。

（2）最適化

正規化は、帳票や既存ファイルなどに対して、1ファイルずつ実施します。このため、全体的にデータ・モデルを見直した場合、「顧客エンティティが複数個存在している」ことや「顧客エンティティと取引先エンティティが、名称は異なれど実は同じものだった」ことに気付きます。

最適化とは、ファイル単位で正規化されたデータ構造について、全体最適を考慮して見直す作業です。最適化によって、システム内で重複するデータを排除し、ビジネス・ルールや業務プロセスの全体像を確認することができます。

（3）一般化

ある企業において、法人顧客と個人顧客によってサービスが異なるとします。このような場合、法人顧客と個人顧客を同じ扱いにするか、それとも別々に管理するか、といった判断が必要になります。一般化では、最適化によって重複を排除したデータ構造を、よりビジネスの実態に合ったデータ・モデルに変更し、データの独立性を高めます。

（4）安定性検証

安定性検証では、正規化、最適化、一般化の順に構築されたデータ構造を検証し、ビジネス変化に対して柔軟に対応できる安定したデータ構造になるように変更します。つまり、この段階で、ビジネスの変化に耐えられる、強いデータ構造にするのです。

正規化技法により、データを管理すべき最小限の単位へ

正規化の目的は、エンティティの独立性を最大限に高めると同時に、エンティティのデータを挿入、更新、削除した場合に「データ間に不整合が生じないようなデータ構造にする」ことです。

一般的な正規化手法では、第1正規化、第2正規化、第3正規化と進めながら、エンティティの分離と、リレーションシップやフォーリン・キーの設定を繰り返すことで、重複がない最小限の単位にデータを整理していきます。

表1: 一般的な正規化手法

	ポイント	説明
第一正規化（1NF）	プライマリ・キーの設定繰り返し項目の分離	繰り返し項目をキーとともに別エンティティとして分離する
第二正規化（2NF）	キー:非キー=1:1	複合キーの中の一部にのみ従属しているアトリビュートを別エンティティとして分離する
第三正規化（3NF）	非キー:非キー=1:1 導出項目の排除	アトリビュート間の従属関係を排除する導出項目を抽出する

（1）第一正規化: 対象となるデータ群のプライマリ・キーを決め、繰り返し項目を、そのプライマリ・キー（複写）とともに、別のデータ群として分離します。図2の例では、繰り返し項目は、商品番号、商品名、商品単価、受注数量、商品小計です。これらの項目を、元のキーの「受注番号」とともに分離しています。
（2）第二正規化: 分離したデータ群の複合キーに、他のデータ群が完全に従属するかどうかを検証します。完全に従属しない、つまり、部分的に従属する場合は、さらに別のデータ群として分離します。例えば、受注番号が決まっても、商品名や商品単価は分かりません。しかし、商品番号が決まれば商品名や商品単価は決まります。従って、商品番号に従属している商品名、商品単価を、別のエンティティとして分離します。
（3）第三正規化: 第二正規化で整理対象とならなかったデータ群の中に、キー以外に従属する属性（アトリビュート）があるかを検証し、別のデータ群として分離します。例えば、第一正規化後の受注エンティティにある顧客名や顧客住所は、受注番号ではなく顧客番号に従属するため、顧客エンティティとして分離します。

図2: データの正規化手順（クリックで拡大）

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

一般的な正規化手法における課題の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）となります。

図3: 正規化簡便法のステップ（クリックで拡大）

エンティティは一定のルールで関連付け可能

（5）手順9と手順10:「リレーションシップの定義とフォーリン・キーの設定」

手順9と手順10は、同時に行います。エンティティ間のリレーションシップは、フォーリン・キーの設定ルールをもとに設定します。親エンティティの識別子を子エンティティのフォーリン・キーとして設定することで、関連付けを行います。

この「フォーリン・キー設定ルール」は、手順7で識別したエンティティ・タイプと、エンティティ間の多重度を表すカーディナリティ（「1:N」、「N:N」）の組み合わせによって異なります。ここでは、いくつかの例を紹介します（図4）。

（1）「リソース:イベント」が「1:N」の場合: 「イベントがリソースを参照する」パターンは、最も多く見受けられます。図の例では、「顧客」と「受注」がこのパターンです。なお、フォーリン・キーの挿入先は、エンティティの独立性が「（N）」の場合にはプライマリ・キー側、「（U）」の場合には非キー側となります。
（2）「イベント:イベント」が「1:1」の場合: イベント同士の場合、参照関係は時系列順になります。つまり「受注」が「請求」を参照するという関係になります。
（3）「イベント:イベント」が「N:1」の場合: カーディナリティだけに着目して誤ってリレーションシップを定義することのないように注意します。時系列を正しく捉えれば、ビジネスの流れと参照関係が逆転したデータ・モデルを作ることはありません。