関係を描く
ほかに 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)
モジュール2／6：Data Architectコース第2章「意味のあるデータモデリング」。各モジュールは単独でも読めます。 前へ：名詞に耳を傾ける · 次へ：論理モデルを作る
このモジュールが答える問い： 候補エンティティを概念データモデルにするにはどうすればよいか？
ホワイトボードに名詞が並びました。次に知りたいのは箱と箱の間の線です。エンティティを集めただけでは、まだデータモデルとは言えないからです。意味の多くは関係の中にあります。小売パートナーは物流センターを運営している。積荷目録には配送が並ぶ。配送は受取人に届く。クルーがトラックを運転する。どの文もビジネスについて何かを教えてくれ、どの文もまた新しい問いを与えてくれます。
ビジネスの言葉から始める
Section titled “ビジネスの言葉から始める ”まだSalesforceの話はしたくありません。これを参照関係にすべきか主従関係にすべきかを問うことも、Salesforceの連結オブジェクトを考えることも、親レコードが削除されたら何が起きるかを決めることもしません。ビジネス上の関係を理解しようとしているのです。
**「小売パートナーは物流センターを運営している」**を例にとりましょう。シンプルに聞こえます。でも、小売パートナーの物流センターは1つでしょうか、それとも多数でしょうか？ Steve Truckingでは、各小売パートナーが、Steve Truckingがサービスを提供するすべての地域で地域物流センターを運営しています。つまり多数です。1つの物流センターが複数の小売パートナーに属することはあるでしょうか？ 物流センターは独自のスタッフや履歴を持つ、それ自体が重要なものなのか、それとも単なる住所なのか？ 小売パートナーが去ったら、その物流センターにまだ関心があるでしょうか？
これらはSalesforceの問いではありません。ビジネスの問いであり、その答え次第でモデルはまったく変わり得ます。
さらに深く進む前に、ここから先のすべての図で使う言葉を紹介しておきます。小さな言葉です。2つの箱の間の線は、その2つが関係していることを示し、線の端の記号がいくつかを示します。
まずは記号のない、ただの線から。ホワイトボードで私が始めるのはここです。この2つの名詞が関係していることはわかっているけれど、どう関係しているかはまだ尋ねていない。次に、端に記号が付きます。線を横切る1本の棒は1を意味します。鳥の足のように3本に分かれた端、カラスの足（crow’s foot）は多を意味します。このモジュールの後半では、最初の記号の隣に2つ目の記号、棒か丸が現れます。それは別の問いに答えるものです。ゼロのこともあり得るか？
覚えておくべきルールは一つです。それぞれの記号は、それが接している箱の側で読む。 箱に最も近い記号が最大数、その外側の記号が最小数です。
おすわり、まて、モデル
Section titled “おすわり、まて、モデル ”Steve Truckingの前に、モジュール1の犬に戻りましょう。箱は5つありました。飼い主、ブリーダー、犬、犬種、芸。今度は、その間の線について問います。
1つか多数か？ 飼い主は複数の犬を飼えます。アナは2匹飼っています。犬の飼い主は1人です。少なくとも私たちのモデルでは。これが1対多です。飼い主の側に棒、犬の側にカラスの足。ブリーダーも同じ形です。1つのブリーダーが多くの犬を繁殖します。
ゼロはあり得るか？ マックスは保護施設から来たので、ブリーダーはまったくいません。ブリーダーの端には丸が付きます。犬のブリーダーはゼロか1つです。一方、どの犬にも飼い主がいるので、そちらの端には2本目の棒が付きます。ちょうど1人です。
多対多か？ 1匹の犬は多くの芸を覚えていて、1つの芸、たとえばおすわりは、多くの犬が覚えています。これが多対多で、まさにここで私は隠れた概念を探しに行きます。この犬がこの芸を覚えていることについて、何かあるでしょうか？ どれくらい上手にできるか、そしていつ覚えたか。この関係はそれ自体の事実を持っているので、それ自体が一つのものになります。犬の芸（Dog Trick）です。犬の名前が先に来るのは、それを動かしているのが犬だからです。
それぞれの線は何を意味するか？ 飼い主は犬を飼う。ブリーダーは犬を繁殖する。犬は芸を覚えている。線に名前を付ければ、誰でもモデルを読み上げて説明し返せます。
今か、時間を通じてか？ ベラの今日のおすわりの上手さを気にする人はいるでしょうか、それともそこに至るまでの経緯でしょうか？ トレーナーが数か月ごとにベラをチェックするなら、チェックの一つひとつがそれ自体のレコードになります。日付、習熟度、チェックした人を持つ芸の評価（Trick Assessment）で、それが属する犬の芸の下に置かれます。一つのものになった関係でさえ、それ自体の履歴を持てるのです。
犬種は、ひとまずつながないでおきます。モジュール1からの問い、それ自体の箱なのか、犬に書かれた言葉なのか、はまだ残っていて、モジュール4で決着します。
これらの問いはどれも、本物のビジネスにも同じように使えます。では、Steve Truckingに問いかけてみましょう。
「1つか、多数か？」と問う
Section titled “「1つか、多数か？」と問う ”関係について最初に理解したいことの一つがカーディナリティです。データベースの用語ですが、問いはずっとシンプルです。こちらのいくつが、あちらのいくつと関係し得るか？ 概念レベルでは、基本的なパターンは3つです。
これはプロセスの中の大切な一歩です。2つの異なる名詞を取り上げ、その関係を理解します。ほとんどの場合、それは1対多か多対1です。1対1に出会うのはまれな状況だけです。
1対多はいたるところにあります。1つの小売パートナーに多数の物流センター。1つの積荷目録に多数の配送。1つのルートに約10か所の停車地。そうした言葉を聞くと、私は線を引き始めます。
そして線に記号が付きます。それぞれの端が、接している箱がいくつかを示します。棒は1、カラスの足は多です。それぞれの箱から読みましょう。1つの小売パートナーには多数の物流センターがあります。
1対1の関係も存在しますが、まれです。見つけたら、いくつか問いを立てます。これは本当に2つの異なる名詞なのか、それとも同じものなのか？ 異なるなら、両者の1対1の関係とは何か？ そして、それはずっと1対1なのか、それとも今は1対1なだけなのか？ これらはデータモデルを設計するうえでの重要な問いです。クルーとトラックは、ある朝だけを見れば1対1に見えます。2人、1台のトラック、1つのルート。1か月で見ればそうではありません。そしてそこに、このモデルで最も興味深い関係が隠れています。
多対多の関係は特に興味深いものです。ビジネスにもう一つの概念があることを教えてくれることが多いからです。クルーは時間を通じて複数のトラックを運転できるか？ はい。トラックは複数のクルーに運転され得るか？ その生涯を通じれば、もちろんです。ですからクルーとトラックは多対多の関係にあります。でも、もっと知りたくなります。ビジネスは、あるクルーがあるトラックをいつ使っていたかを気にするでしょうか？ どのルートで、どの日に？ 誰が割り当てたのか？ 関係そのものが私たちの気にする情報を持っているなら、もう一つのビジネス概念を発見したことになります。クルー割り当て（Crew Assignment）です。
これは大切なモデリングの習慣です。最も興味深いものが、最初に聞こえた名詞の一つではないことがあります。それは2つの名詞の間の関係の中に隠れているのです。
関係はものになり得る
Section titled “関係はものになり得る ”ここは、管理者の方々に考え方を変え始めてほしいところの一つです。Salesforceではオブジェクトと項目について話すのに慣れているので、箱が大事な部分で、線はただの配管だと扱いがちです。しかし関係そのものがビジネス上の意味を持ち得ます。
配送とそれに載っている製品を考えてみましょう。1つの配送には複数の製品が載ることがあります。たとえば洗濯機と乾燥機です。1つの製品、同じ冷蔵庫のモデルは、何千もの配送に登場します。ここまでは簡単です。しかし、この配送にその製品がいくつ載っているのか、設置するのか、古いものを引き取るのかを知る必要があるとしたら？ もはや配送と製品の関係だけに関心があるのではありません。配送品目（Delivery Item）に関心があり、その概念はそれ自体のエンティティに値します。
Salesforceに慣れている方は、もう「それは連結オブジェクトだ」と考えているかもしれません。間違いではありません。でも、そこから始めたくはないのです。配送品目は、Salesforceの連結オブジェクトである前に、ビジネス概念です。 ビジネスが先、実装は後です。
こうした関係のエンティティについて、最終的にどこで作られるにせよ、私が持っている習慣をいくつか紹介します。
名前を付ける。 ビジネスにすでにそれを指す言葉があるなら、その言葉を使いましょう。なければ、2つの親の名前を組み合わせます。注文と製品を考えてみてください。その間にあるのは注文品目（Order Item）、つまり注文と、注文に載っている品目です。両方の親の子であり、Salesforceでは最終的にSalesforceの連結オブジェクトになるかもしれません。でも、どちらの名前を先にするのでしょう。Item OrderかOrder Itemか？ それぞれの親がどんな種類のデータかを見てください。製品は参照データで、注文はトランザクションデータであり、それを動かしているのは注文です。だからOrder Item、あるいはOrder Productです。Salesforceに商談商品（Opportunity Product）があるのと同じです。Steve Truckingでは配送品目（Delivery Item）です。動かしている側の名前が先に来て、目にするどのリストでも、レコードはその持ち主の隣に並びます。
独自のキーを与える。 配送品目は配送と製品の組み合わせで識別される、と言ってそこで止めたくなります。それは複合キーであり、複合キーはずっと扱いにくいものです。そのレコードを指すすべてのシステムが両方の半分を持ち歩かなければなりません。関係のエンティティには独自の識別子を与え、配送と製品の組み合わせは識別子ではなく、一意性についてのルールとしておきましょう。
そこにないものに注目してください。シリアル番号です。数量とシリアル番号は同じレコードに属しません。数量はあるものが何個あるかを数え、シリアル番号は特定の1個を識別します。ビジネスがシリアル番号を必要とするなら、1台ずつがそれぞれのレコードになり、冷蔵庫5台は5レコードになります。配送品目の下に配送品目明細を置くケースは考えられません。どちらか一方です。数量を持つ集計か、1台につき1レコードか。ここでは数量です。
履歴を必要とする属性に注意する。 関係のエンティティには、作成された時点で落ち着くものもあります。この配送の洗濯機は、ずっとこの配送の洗濯機です。変わり続けるものもあります。あるクルーが今週はトラック117を使い、来週そのトラックは別のクルーに移ります。関係が変わり、以前どうだったかをビジネスが気にするなら、関係のエンティティには日付が必要です。注意すべきなのはクルー割り当てです。ビジネスが気にしているのは今なのか時間を通じてなのかを早めに尋ねましょう。すぐ後で改めて取り上げます。
関係にはカーディナリティ以上の意味がある
Section titled “関係にはカーディナリティ以上の意味がある ”「1対多」だけでは、関係を理解するのに足りません。その関係が何を意味するのかも知りたいのです。
配送には場所があります。どの場所でしょう？ 出発する物流センター？ 届け先の受取人の家？ この二つは入れ替えられません。まったく同じ箱と同じカーディナリティを持つ2つのモデルでも、線がまったく違うことを意味している場合があります。だから、よいモデルはただ箱を線でつないだものではないのです。線には名前が必要です。 私の図を別のアーキテクトに渡したとき、関係が何を意味するのかを推測させてはいけませんし、ビジネスに見せるなら、彼らにわかる言葉を使うべきです。
任意性も重要
Section titled “任意性も重要 ”「いくつか？」の中には、もう一つの問いが隠れています。その関係は必須か？ 配送は、ルートに載る前から存在できるでしょうか？ 存在しなければなりません。積荷目録は配送の1、2日前に届き、ルートは前日の夕方に確定するからです。配送は小売パートナーなしで存在できるでしょうか？ できません。すべての配送はパートナーの積荷目録から来ます。これが任意性です。
ここでもやはり、すぐにSalesforceの必須チェックボックスに飛びつかないでください。「すべての配送には小売パートナーがなければならない」と言うことと、「レコード作成時にSalesforceが小売パートナー項目を必須にすべきだ」と言うことは違います。最終的には同じ実装になるかもしれませんが、同じ主張ではありません。前者はビジネスルールで、後者はそれを強制する方法の一つです。アーキテクトとして、後者を決める前に前者を理解したいのです。
図では、任意性はそれぞれの端の2つ目の記号です。箱に最も近い記号が最大数で、棒なら1、カラスの足なら多です。その外側の記号が最小数で、もう1本の棒なら少なくとも1、丸ならゼロもあり得ます。ですから、すべての配送はちょうど1つの積荷目録に載り、積荷目録には1つ以上の配送が並びます。配送は0か1つの停車地にあり（ルートが組まれるまではなし）、停車地では0個以上の配送が降ろされます。
時間が関係を変える
Section titled “時間が関係を変える ”私がよく尋ねる問いがあります。今のことですか、それとも時間を通じてのことですか？
クルーがトラックを運転する。今？ 今日のルートで？ その2人が一緒に働く間ずっと？ それぞれ違うモデルになります。ビジネスが、今日クルーがどのトラックを使っているかだけを気にするなら、モデルはシンプルなままでかまいません。クルーが運転したすべてのトラックを、いつ、どのルートでかまで必要とするなら、履歴が必要になり、先ほど発見したクルー割り当てが突然とても重要になります。
これはモデリングの誤りのよくある原因です。画面で見えるのは現在の状態なので、現在の状態をモデリングします。そして数週間後、小売パートナーが損傷のクレームを申し立て、誰かが「3月17日にトラック117を使っていたのはどのクルーか？」と尋ねます。そこで、割り当てが変わるたびにその答えを上書きしていたことに気づくのです。
その履歴を残す方法の一つが、割り当てをそれ自体のレコードにすることです。クルーが割り当てられたら、開始日付きのクルー割り当てを作成します。割り当てが変わったら、古いレコードに終了日を入れ、独自の開始日を持つ新しいレコードを作ります。これで「半年前にその割り当てを持っていたのは誰か？」は、項目履歴やデータ変更ログを掘り返すことなく、簡単に答えられる問いになります。そして、クルーに多くの割り当てがたまれば、どれが現在の割り当てかを尋ねる人が出てくるので、私なら有効（Active）フラグも追加します。
ですから、誰かが関係について話してくれたとき、私はものごとがどう関係しているかだけを尋ねるのではありません。**その関係は変わるのか、そしてその履歴を気にするのか？**と尋ねます。
設定する前に描く
Section titled “設定する前に描く ”Steve Truckingのモデルは役に立つものになりつつあります。どの関係が1対多か、どこで多対多が別の概念を隠しているか、どの関係が任意か、どの関係が時間とともに変わるかがわかっています。そして、まだSalesforceのオブジェクトを一つも作っていません。それは意図的です。
この図は、ビジネスの前に出せるものであるべきです。それが正しいかどうかを私に教えるのに、Salesforceを知っている必要があってはいけません。Salesforceの用語だらけでビジネスが検証できないなら、私は物理設計に進むのが早すぎたのです。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”概念モデルの関係を検討するとき、私が決めているのは次のことです。
- 主要なビジネスエンティティが互いにどう関係しているか。
- それぞれの関係が、今そして時間を通じて、1対1、1対多、多対多のどれか。
- それぞれの関係が必須か任意か。
- 多対多の関係が、意味のあるビジネス概念を隠していないか。
- その関係が時間とともに変わるか、そしてその履歴が必要か。
参照関係か主従関係か、連結オブジェクトの構成、連鎖削除の振る舞い、共有は物理的な判断です。いずれそこにたどり着きます。今はまだ、もっと重要な問いに答えているところです。このビジネスは実際にどう動いているのか？ エンティティとその間の関係を理解できたら、それらを記述する詳細を加え始められます。そのとき、概念モデルは論理データモデルになり始めるのです。