.png)
前号からの続きです。
概念データモデリングとは、エンティティ名の裏側に隠れている本質的な意味内容が、人によってずれていることを修正する作業です。
このずれを修正する作業は意外と苦労します。たとえば、次のような会話になります。
Aさん「あなたの言う顧客と私の言う顧客はどこか違う感じですね」
Bさん「私が言う顧客は出荷先のことですよ」
Aさん「ああそうですか。私は受注先と納品先の両方を指していました」
Bさん「なるほど、では、あなたの言う納品先は私の言う出荷先と同じですね」
Aさん「いや、ちょっと待ってください。納品というのはお客様への納品を意味しているので、単に商品を出す先＝出荷先という意味ではありません」
Bさん「そこで登場したお客様とはなんですか？また、単に商品を出すのであれば、出庫と言うのではありませんか？」
・・・・
・・・・
こうしたやりとりが延々と続いたとしても、どちらが正しいかということに決着はつきません。
要するに人によってずれている「言葉」と「対象（意味）」の対応関係を、別な「言葉」を使って説明しようと試みるところに、この作業の本質的な難しさがあります。
概念データモデルはこの作業を次のように助けてくれます。
エンティティはKEY（厳密には識別子）を持っています。従って、KEYが発番される範囲に「対象（意味）」が限定されます。ここが1つのポイントです。顧客エンティティは顧客IDというKEYを持ちます。顧客IDが受注先と請求先に発番されていて、出荷先に発番されていなければ、顧客とは受注先と請求先を意味し、出荷先は顧客と呼ぶべきではないという結論になります。AさんとBさんが議論して、どちらが正しいか決められないとしても、実際に業務で使っている帳票や画面のデータ項目が、正しい答えを語ってくれます。
また、概念データモデルではエンティティとエンティティの関係をKEYとRKEY（KEYを参照するデータ項目）で表現します。実は、受注先や請求先は、顧客IDが受注イベントや請求イベントの中で担うロール（役割）を表す言葉です。我々は、顧客エンティティのサブタイプとして受注先エンティティや請求先エンティティを位置づけることで、それぞれの「言葉」がもつ相対的な意味関係を図示することができるのです。これによって、我々は、空中戦ではない議論を可能とする、指さし確認ができる武器を手にします。
概念データモデルは、業務を実施する人たちの「概念」をデータ項目を使ってモデル化したものですが、「言葉」の意味を相対的に位置づけていることから業務用語マップと言い換えても良いでしょう。
