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

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

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

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

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

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

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

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

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

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

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

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

図5: データ（値、属性）からプライマリ・キーの安定性を図る（クリックで拡大）

（2）複合キー

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

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

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

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

図6: 複合キーからプライマリ・キーの安定性を図る（クリックで拡大）

（3）有意コード

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

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

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