論理モデルを作る

🌐 ほかに 28 言語で読めます

English · Español · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

AI で生成した画像

このページはAIで翻訳されています。コミュニティによるレビューはまだ行われていません。 英語で読む

モジュール3／6：Data Architectコース第2章「意味のあるデータモデリング」。各モジュールは単独でも読めます。 前へ：関係を描く · 次へ：データをあるべき場所に置く

このモジュールが答える問い： 概念モデルを論理データモデルにするにはどうすればよいか？

概念モデルは、Steve Truckingに何が存在し、それがどう関係しているかを教えてくれました。小売パートナーとその物流センター、積荷目録と配送、受取人、ルートと停車地、クルー、トラック、クルー割り当て。ビジネスととても実りある会話をするには、それで十分です。しかしいずれ、もっと詳細が必要になります。配送について何を知る必要があるか？　ある物流センターを別の物流センターと区別するものは何か？　受取人をどう識別するか？　クルーやトラックではなく、クルー割り当てに属するものは何か？　こうした問いが、概念モデルから論理データモデルへと私たちを進めます。そして、まだSalesforceを作ってはいません。

おすわり、まて、モデル

まずは犬に戻りましょう。箱と線はそろいました。ここで新しい問いが2つあります。それぞれのものについて何を知っているのか。そして、どうやって一つひとつを見分けるのか。

何がそれを記述するか？ 犬には名前と誕生日があります。飼い主には名前、電話番号、住所があります。芸には名前と難易度があります。それぞれの事実は、それが記述する箱に置きます。

次に連結です。ベラがどれくらい上手におすわりができて、いつ覚えたか。それはベラを記述しているでしょうか？　少し違います。ベラには得意な芸もあれば、そうでない芸もあります。おすわりを記述しているでしょうか？　いいえ。おすわりのやり方は犬ごとに違います。それはベラとおすわりを一緒に記述しているので、犬の芸に置きます。習熟度と習得日です。だからこそ連結が存在するのです。ペアにしか属さない事実があるからです。

どの犬がどれか？ まず名前を試してみましょう。マックスという名前の犬はたくさんいるので、名前は一意ではありません。飼い主の電話番号は？　マーカスは同じ電話番号で2匹を飼っていますし、人は番号を変えますし、それは誰かの個人データです。犬を指し示すあらゆるシステムにコピーされてしまいます。マイクロチップの番号はよさそうに見えます。一意で、変わりません。でも、新しい子犬にはまだチップが入っていないかもしれず、キーは空欄にできません。だからマイクロチップは、その犬を別の形でも識別するものとして残し、犬には独自の犬IDを与えます。1匹の犬を別の犬と見分けるという、地味な仕事を一つだけする番号です。

Click to enlarge

これらは、これからSteve Truckingにも投げかける問いと同じです。そして、名前、電話番号、マイクロチップがそれぞれキーとして足りない理由は、私が何年も守ってきたルールにつながります。

概念は何が存在するかを、論理はそれがデータとして何を意味するかを教える

トラックを例にとりましょう。トラックについて何を知る必要があるでしょうか？　車両番号、VIN（車台番号）、メーカー、モデル、年式、ナンバープレート、現在の走行距離、ステータスかもしれません。これらはトラックの属性です。

次は配送です。小売パートナーの注文番号、配送日、約束した時間帯、実際の到着時刻、ステータス、設置や引き取りを含むかどうかかもしれません。これも属性です。

概念モデルは、配送が存在することを教えてくれました。論理モデルは、配送がデータとして何を意味するのかを教え始めます。トラックや配送のようなシンプルな箱が、ひとまとまりの項目全体を表していることもあります。

Click to enlarge

それでも、ほとんどの図では箱をシンプルなままにします。理由は3つあります。項目の数は増えていきます。項目はすぐに古くなります。そして、各項目には、オブジェクトモデルでは示しにくい詳細があります。API参照名、表示ラベル、データ型、長さです。そうした詳細は必ず記録しますが、最初のデータモデルには載せません。いくつかの主要な項目を見せることが話を伝えるのに本当に役立つときは、詳細データモデルを描きます。要点に関係する項目だけを載せた、焦点を絞った一部分です。

属性はエンティティを記述するべき

属性を見るときに使うシンプルな問いがあります。これは何を記述しているのか？　トラックのメーカーは明らかにトラックを記述しています。では、配送に載っているクルーメンバーの名前はどうでしょう？　それは配送を記述しているのでしょうか？　それとも、クルー割り当てを持ち、そのクルー割り当てがルートを担当し、そのルートにこの停車地が含まれていた、というクルーを記述しているのでしょうか？

ここでデータモデルは、画面上ではまったく妥当に見えるものをあらわにし始めます。コーディネーターが「配送にクルーの名前を表示したい」と言います。それは正当なユーザー体験の要件です。でも、クルーの名前を配送に保存する要件だとは限りません。この二つは別のことで、正規化のところで改めて取り上げます。今は、この事実が実際に記述しているのは何かを問う習慣をつけましょう。その問いが、多くのトラブルからあなたを救ってくれます。

そして一意のIDの話をしなければならない

属性はものを記述します。しかし、解かなければならない問題がもう一つあります。どれがどれなのかを、どうやって知るのか？

ジョン・スミスという名前の受取人が2人います。同じ人でしょうか？　そうかもしれないし、そうでないかもしれません。名前だけでは足りません。住所は？　人は引っ越します。電話番号は変わります。メールアドレスも変わります。小売パートナーの名前でさえ変わることがあります。

ここでキーの話になります。モデルの中で何かを一意に識別できるようにするものです。これは私が長年かけてかなり強い意見を持つようになった分野です。識別子には4つのことを求めます。

一意。変わらない。意味を持たない。決して個人情報ではない。

一意。 識別子は、ちょうど一つのものを識別しなければなりません。2つの配送が同じ値を持ち得るなら、それは信頼できる配送の識別子ではありません。名前はたいてい一意ではなく、住所も一意とは限らず、電話番号は共有されます。今日は一意に見える値でも、データが十分たまると一意でなくなるかもしれません。ですから問いましょう。このうちの2つが同じ値を持つことはあり得るか？　答えがイエスなら、それをレコードの一意のIDとして使うことにはとても慎重になりましょう。

変わらない。 これは見落とされがちです。小売パートナーを名前で識別していて、そのパートナーが社名を変えたら、新しいパートナーができたのでしょうか？　いいえ。ビジネス上のエンティティは同じままで、属性の一つが変わっただけです。レコードの一意のIDは、それが識別するものの変化を乗り越えて残るべきです。つまり名前、メールアドレス、電話番号、住所、ユーザー名は除外されます。システムを作り始めたときにどれほど便利に見えても、です。

意味を持たない。 初めて聞くと奇妙に聞こえます。なぜ識別子に意味を持たせたくないのでしょう？　意味は変わるからです。誰かが、物流センター、小売パートナー、配送日、連番を埋め込んだ配送IDを作ったと想像してください。PHX-KEY-20261002-0042。賢そうに見えます。そこで受取人が金曜日に配送日を変更します。識別子を変えるでしょうか？　変えなければ、識別子は嘘をつきます。変えれば、属性の一つが変わったせいで配送の一意のIDを変えたことになり、古いIDを保存していたすべてのシステムがその配送を見失います。その識別子は2つの仕事をしようとしていたのです。配送を識別することと、配送を記述すること。記述は属性に任せ、識別子には退屈な一つの仕事、識別することだけをさせたいのです。退屈な識別子はよい識別子です。

決して個人情報ではない。 これは十分に重要なので、別に扱っています。一意に見えるからといって、個人を特定できる情報を識別子として使わないでください。Steve Truckingでは、受取人を電話番号で識別したくなります。しかしキーは、システムがレコードをつなぐ必要のあるあらゆる場所にコピーされます。連携、エクスポート、ログ、小売パートナーに返すステータスファイル、データウェアハウス、テストデータ。電話番号をキーにすれば、受取人の個人データをアーキテクチャ全体にばらまいたことになります。

キーはまた、すべてのレコードに存在しなければなりません。決してnullや空欄にならないこと。 値を渡そうとしない人、あるいは渡す必要のない人がいるなら、その値はキーにはなれません。だからシステムは独自の内部識別子を発行し、個人データは、そもそも必要であれば、保護された属性になるのです。

ですから私のルールは、一意、変わらない、意味を持たない、決して個人情報ではないです。

自然キーと代理キー

データベースの専門家は、このいくつかに名前を付けています。自然キーはビジネスデータの中にすでに存在するものです。トラックのVINはよい例です。私たちのアプリケーションが発明したものではなく、すでに意味を持っています。代理キーは、レコードを識別するために特別に作られるものです。何も記述せず、ただ識別します。

ほとんどのアーキテクチャで、私は代理キーを内部のレコードIDにし、重要な自然の識別子は属性として持っておくほうを好みます。自然の識別子が悪いわけではありません。とても重要なことも多いのです。ただ、自動的にそれをレコードの一意のIDにはしないということです。その値が訂正されたら、形式が変わったら、置き換えられたら、再利用されたら、欠けていたら、複数のソースシステムから届いたら何が起きるかを問いましょう。そこで、単純に見える判断がアーキテクチャ上の判断になるのです。

一つのものが、役に立つ識別子を複数持つことがある

内部のレコードIDが、ほかのすべてのシステムが使う識別子だとは限りません。Steve Truckingは、配送を内部では生成されたIDで識別するかもしれません。各小売パートナーは、同じ配送を自社の注文番号で知っています。KeystoneはCSVの積荷目録で、RedrockはAPIで、BrightwaveはEDIメッセージで。そして、従来の配車ツールRouteDeskにある8年分の履歴は、RouteDesk独自の配送IDを使っています。

そうした識別子は重要です。ステータスの更新は、それぞれのパートナーにそのパートナーの番号で返さなければならないので、保持し、正しく対応づける必要があります。しかし、すべてを配送の一意のIDにする必要はありません。「そのIDは何か？」には複数の答えがあり得るのです。そしてアーキテクトは、どの文脈でどのIDが権威あるものなのかを知っていなければなりません。マスターデータと連携のところで改めて取り上げます。

関係は一意のIDに依存する

描いた線に戻りましょう。積荷目録には配送が並ぶ。受取人は配送を受け取る。クルーにはクルー割り当てがある。これらの関係が機能するのは、両端にあるものを確実に識別できるからにすぎません。

Steve Truckingでこれが問題になる場面があります。小売パートナーが当日に積荷目録を修正します。注文のキャンセル、品目の差し替え、新しい住所。修正された行を、すでにある配送とパートナーの注文番号で照合できなければ、同じ冷蔵庫について2つ目の配送を作ってしまい、クルーが2回現れるかもしれません。箱、属性、キー、関係は別々の考えではありません。すべて同じモデルの部品なのです。

Click to enlarge

ここで、「SalesforceはすべてのレコードにIDを付けてくれる」と思っているかもしれません。その通りで、いずれそこに行き着きます。データがSalesforceにあるなら、すべてのレコードにSalesforceが生成したIDが付きます。暗号のようで読みにくいので、たいていは人が使えるID項目も見せます。配送番号D-000184227のような、自動採番項目です。その番号がレコードのIDだと思われがちですが、そうではありません。その下にはやはりSalesforceのIDがあります。外部システムやデータベース、OracleやSQL Serverにも独自の一意のIDがあります。しかしアーキテクチャには、いずれSalesforce、財務ERP、Snowflake、Data 360、パートナーのシステム、そしてまだ存在しないシステムが含まれるかもしれません。論理モデルは、すべての判断を一つのテクノロジーに依存させることなく、ビジネスデータを記述します。Salesforceがそれを物理的にどう実装するかは、後のステップです。

ここでアーキテクトが決めること

概念モデルを論理モデルにするとき、私が決めているのは次のことです。

• それぞれのエンティティを実際に記述している属性はどれか。
• それぞれのエンティティをどう一意に識別するか、そしてその識別子が一意のIDになれるほど安定しているか。
• どのビジネス上の識別子（パートナーの注文番号、従来システムのID）を保持し、対応づける必要があるか。
• 機密情報がキーとして使われていないか。
• 関係が、信頼できる一意のIDを通じてエンティティをつないでいるか。

これでエンティティ、関係、属性、一意のIDがそろいました。本物の論理データモデルの始まりです。しかし、まだ問題があります。まったく正当なデータを、間違った場所に置いてしまうのはとても簡単なのです。そこで正規化の出番です。

さらに学ぶ

• Custom Field Types (opens in a new tab)、Salesforceヘルプ（英語、2026-10-09確認）：自動採番は、接頭辞や先頭のゼロなどの表示形式で各レコードに一意の番号を割り当てる。それはレコードのSalesforce IDではない。Auto-Number Fields Are Not Always Sequential (opens in a new tab)（英語、2026-10-09確認）も参照。