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

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

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

（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」、つまり、「請求時に、対応する納品が必ず存在する」ということになります。将来的に「納品を伴わない請求が存在する」可能性があるのであれば、そのビジネス・ルールに対応するリレーションシップを定義します。

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