データ・モデルを安定させる

「最適化」は全体をみて整理する

正規化では、1ファイルずつデータを整理します。このため、正規化されたデータ構造を全体的に見直すと、顧客エンティティが複数個存在することや、顧客エンティティと取引先エンティティが、名称は異なるが実は同じものだった、ということに気づきます。

この問題を解決するため、「最適化」と呼ぶ工程で、システム内で重複する属性（データ項目）を排除し、ビジネス・ルールや業務プロセスの全体像を確認します。

最適化の手順は、以下の通りです。

1. 同一のプライマリ・キーを統合
2. 属性を1つのエンティティに統合
3. リレーションシップを再設定

1. 同一のプライマリ・キーを統合

名称が同じものや、データの意味が同じものに着目して、同一のものは1つにまとめます。

例えば、「取引先番号」と「顧客番号」のように、名前が異なっても同じ意味内容を持つ"シノニム（異音同義語）"、同じ「担当者名」であっても「社内担当者名」の場合と「顧客担当者名」の場合がある"ホモニム（同音異義語）"、「製造番号」という標準名のほかに「製番」という短縮名などの"エリアス（別名）"、に注意してデータを整理します。

• シノニム（異音同義語）
• ホモニム（同音異義語）
• エリアス（別名）

2. 属性を1つのエンティティに統合

属性（アトリビュート）が重複しないように、各属性を1つのエンティティに従属させます。ここでは、プライマリ・キーと同様、属性の名称や意味にシノニム、ホモニム、エリアスが存在しないかどうかを確認します。

例えば、製品エンティティと商品エンティティがある場合、製品番号と商品番号を同一キーとみなし、製品エンティティに商品名という属性と製品名という属性を従属させるとします。製品名と商品名が同じデータ値を管理しているのであれば統合できますが、製品名が英数字の型番で、商品名がカタログ上の日本語であれば、統合することはできません。

3. リレーションシップを再設定

エンティティを統合する前から存在しているリレーションシップを、抜け漏れなく再定義します。図2の例は、エンティティを統合した結果、顧客と受注、顧客と請求という2つのリレーションシップが発生してしまったケースです。

リレーションシップが冗長であれば、削除します。しかし、図2の例で「請求先と受注先は異なる」というビジネス・ルールがあった場合は、削除できません。このように、自社のビジネス・ルールと合っているかどうかを検証する必要があります。

ビジネス・ルールと照らし合わせる際には、図3のようにイベント系エンティティを左から右に時系列で配置すると、後でだれがみても分かりやすいデータ・モデルになります。

「一般化」によって、運用できる形に直す

一般化は、類似するものを無理に統合するのではなく、ビジネスの実態に応じて変更していく作業です。自社のビジネス・ルールに応じて、エンティティの汎化または特化を検討します。

例えば、同じ顧客でも、提供するサービスが違うのであれば、サブタイプとして「法人顧客」と「個人顧客」に具体化して管理する、といった具合です。また、「顧客」という上位タイプ（スーパータイプ）に抽象化して管理した方がよい場合もあります。

一般化により、特定のエンティティやビジネス・ルールを、より分かりやすく表現できます。

例えば、図4の左側に示したデータ・モデルでは、店舗にどのような運用形態があるのか分かりません。さらに、すべての店舗がFC（フランチャイズ）と関連があるように見えます。一方、図4の右側に示した、一般化作業を経た後のデータ・モデルでは、店舗には直営店舗とFC店舗があり、直営店舗は本部にのみ関係することが分かります。

一般化を経ることによって、データの自立性が高まります。これにより、店舗網全体の情報活用が進むだけでなく、直営店舗はアンテナ・ショップとしてのマーケティング情報を、FC店舗はローコスト・オぺレーションとしての管理情報を、具体的に活用できるようになります。

一般化の対象は、リソース系エンティティだけでなく、イベント系エンティティにも適用できます。さらに、サブタイプ化の数や階層の数には制限がありません。

「安定性検証」によって、将来の変更に対して脆弱な点を分析する

一度構築したデータベース・システムに対する変更は、極力避けたいところです。しかし、ビジネスは変化するものであり、構築時にその変化を完全に予測することはできません。

安定性検証では、正規化、最適化、一般化の順に作成したデータ構造を検証し、ビジネスの変化に対して可能な限り柔軟に対応可能な、安定したデータ構造にします。つまり、この段階で、ビジネスの変化に強いデータ構造にするのです。

具体的には、プライマリ・キーやリレーションシップの変更をシミュレーションし、データ構造の脆弱点を発見し、対処します。検証すべき対象は、データ・モデルを構成する各要素（エンティティ、属性、リレーションシップ）です。技術や社会の変化などの外的要因や組織変更などの内的要因によってビジネスが変化した場合や時間が経過した場合にも影響を受けにくいデータ構造になっているかどうかを検証します。

安定性検証で最も重要な要素は、プライマリ・キー

プライマリ・キーを変更すると、エンティティの内容を識別できなくなるだけではありません。プライマリ・キーをフォーリン・キーとする他のエンティティにも影響します。

プライマリ・キーの安定性は、以下の3つの観点でチェックします。

• （1）データ（値、属性）
• （2）複合キー
• （3）有意コード

（1）データ（値、属性）

データの値やデータ属性（データ型、桁数、精度）に、変更される可能性があるかどうかを検証します。例えば、「仕入先製品コード」のように、自社ではコントロールできない項目が該当します。

このようなキーは、プライマリ・キーではなく非キーとして定義することで、変化の影響を最小限にできます。もっとも、「非キーにすると、データ値の一意性が損なわれる」と心配する方もいるでしょう。このような場合は、自社でコントロールできる代理キーを定義することで、一意性を保証できます（図5の右上）。

図5の左下に示した例では、現在の組織しか管理できません。現在の組織だけでなく過去の組織も管理する必要がある場合は、「組織」と「前組織」の間にエンティティを定義します。

（2）複合キー

複合キーの場合、構成するキー項目の組み合わせや構成数に、変更の可能性があるかどうかを検証します。

例えば、「大分類」と「中分類」という2つの分類コードを合わせた複合キーで商品を識別する場合、新たに「小分類」を増やしたら、このエンティティのデータ構造だけでなく、商品を参照する様々なエンティティのフォーリン・キーの数にも影響が生じます。アプリケーションの改修などの工数を考えると、運用後に大きな変更が生じないようにしなければなりません。

また、プライマリ・キーにはNULL値が許されません。このため、小分類が不要であれば、ダミーで「99」などの値が必要です。図6の右上に示したように、複合キーを単一キーにすることによって変化の影響を抑制できますが、フォーリン・キーの付け替え作業は避けて通れません。

そもそも、「分類は、階層構造ではなく、異なる粒度の組み合わせである」と考えれば、商品分類のすべての粒度（大分類、中分類、小分類）を表すことができます（図6の右下）。

（3）有意コード

頭3桁が商品コード、残り2桁が部門コード、といったように、個々の桁に意味を持たせるのが「有意コード」です。「部門の統合で、部門コードが変更になる」、「時間の経過とともに、関係する部門が増える」、「有意コードの組み合わせが変わる」、といったように、有意コード内の桁の組み合わせや構成数、桁数が変わるかどうかを検証します。

また、有意コードでは、1つのコードで様々な情報を管理します。このため、情報分析用のシステムにおいては、扱いづらい存在になります。有意コードの一部を抽出する際に、索引が利用できないため、レスポンスも劣化してしまいます。

このような項目は、プライマリ・キーではなく非キーとして定義し、代わりに連番などの代理キーをプライマリ・キーとして定義するとよいでしょう。

非キーについても、変更の可能性があるかどうかを検証する

プライマリ・キーの変更ほどには大きな影響はありませんが、非キーについても、データ値や属性に変更の可能性があるかどうかを検証します。

（1）データ（値、属性）

製品の特徴（色やサイズ）を「有意コード」で持つ場合、ビジネス変化への対応力が脆弱で、有意コード内の部分抽出に索引が指定できず、パフォーマンスにも影響が出る、という問題があります。また、独立したデータ項目ではなく備考として情報を保持している場合は、入力ルールが明確でないため、「Lサイズ」、「Large」、「L」などと、登録内容がばらばらになります。

このため、後々「登録内容からデータを抽出し、製品の販売傾向を知りたい」といった分析作業を行いたくとも、すぐにデータを活用できる状態ではありません。この場合、将来的に情報分析の軸になりそうな属性は、コード化を検討します（図8の左）。

また、製品名や単価の変更履歴情報を管理したい場合は、後でデータ構造を変更すると、それを利用している他のエンティティへの影響だけでなく、アプリケーションの改修にもつながってしまいます。改修コストを抑制するには、ビューを新たに用意する、といったことも必要になります。

製品名や単価の履歴情報が必要になるなど、新たに属性が増える場合は、製品名の履歴や製品単価の履歴を管理するエンティティを追加することが有効です。これにより、データ構造を変更せずに対応できます。また、属性数が多いエンティティの場合は、属性の定義先を厳密に振り分ける、といったパターンを検討するとよいでしょう（図8の右）。

（2）未使用属性

データの抜けや漏れの検証も必要ですが、現在使用されていない属性も、将来的に利用する予定がないのであれば、削除しておくことが重要です。未定義の曖昧さを持った属性を次期システムへと持ち越すと、データ分析が困難になったり、パフォーマンスに影響を及ぼしたりする可能性があるからです。

エンティティとリレーションシップもチェックが必要

（1）エンティティの安定性阻害要因

エンティティに、抜けや漏れがあるかどうかを確認します。例えば、CRUD図^*1を利用して、エンティティの漏れや、不要なものの存在を検証します。

• [*1] CRUD図: エンティティとプログラムのマトリックスで、データのライフサイクルを表す。どのエンティティのデータにどのプログラムからどのような操作（Create、Read、Update、Delete）を行うかの関係を把握できる。

（補足）CRUD図の参照方法

－縦（エンティティ）の視点

・どのプロセスからもアクセスがない

エンティティが不要なのか、プロセスが欠落しているのか、を確認できる。

・「C」が存在しない

データ生成プロセスが存在しないのか、管理すべきデータが存在しないのか、を確認できる。

・「C」、「R」、「U」、「D」のいずれかが欠落している

エンティティのライフサイクルに必要なプロセスが欠落しているかどうか、を確認できる。

・「C」、「U」、「D」が重複している

プロセスが重複している可能性、および資源競合（ロック）が発生する可能性、を確認できる。

－横（プロセス）の視点

・アクセス・パスが分断されている

ビジネスからの要求仕様通りに、リレーションシップに沿って各エンティティにアクセスできるかどうかを確認できる。

・「C」が重複している

整合性を保つために複数エンティティ（親子エンティティなど）に対しデータを生成しているのか、それともプロセスの細分化ができていないのか、を確認できる。

・どのエンティティにもアクセスしていない

エンティティが捕捉できていないのか、そのプロセスが不要なのか、を確認できる。

（2）リレーションシップの安定性阻害要因

図10の左に示した、顧客と請求のリレーションシップに着目してください。この情報が、現在も将来的にも冗長であれば、削除します。しかし、将来的に「請求先は、受注先と異なる」というビジネス・ルールになる可能性があるのであれば、これは将来を見据えた柔軟なデータ構造といえます。なお、一見して冗長と判断できる場合は、フォーリン・キーに対して「請求先番号」のようなロール名を定義するとよいでしょう。

また、カーディナリティの最大値と最小値の検証が重要です（図10の右）。まずは、最大値に着目します。例えば、納品と請求は、「1:1」の関係であれば、「納品の都度請求される」というビジネス・ルールになります。この関係が「1:N」や「N:1」になる、つまり「分割請求」や「一括請求」になるのかどうかを、検証する必要があります。

次に、最小値について検証します。例えば、納品からみて請求は「0」、つまり「請求しない納品がある」ことを意味します。また、請求からみて納品は「1」、つまり、「請求時に、対応する納品が必ず存在する」ということになります。将来的に「納品を伴わない請求が存在する」可能性があるのであれば、そのビジネス・ルールに対応するリレーションシップを定義します。

以上、将来的にビジネスが変化しても転ばないデータ構造の作り方について、簡単に紹介しました。次回は、データ・モデルを維持する必要性と、活用方法について紹介します。