第3正規形まで設計し、それから戻す
ほかに 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)
モジュール5／6：Data Architectコース第2章「意味のあるデータモデリング」。各モジュールは単独でも読めます。 前へ：データをあるべき場所に置く · 次へ：モデルをSalesforceにする
このモジュールが答える問い： きれいに正規化されたモデルから、いつ意図的に離れるべきか？
前のモジュールでは、第3正規形を目指して設計するように言いました。
今度は、それを崩すように言います。
ときには。
これは大切な区別です。うっかり散らかったデータモデルを作ってしまうことと、きれいなモデルを意図的に非正規化することとの間には、大きな違いがあります。そもそもデータがどこに属するのかを理解していないなら、それをどこか別の場所にコピーするのはアーキテクチャではありません。ただの重複です。
しかし、きれいな論理モデルを理解したら、それを使う人やシステムのために、データを別の形にするという意識的な判断を下せます。
可能なところでは第3正規形まで設計する。そして、必要なときには戻す。
この言葉が言っていないことに注目してください。第3正規形のほうが理解しやすいとは言っていません。ときにはより難しくなります。完全に正規化されたモデルは、一つのビジネスの考えを5つのオブジェクトに散らばらせることがあり、使う人はそれを頭の中で組み立て直さなければなりません。正規化は、それぞれの事実がどこに属するかを教えてくれます。それが読み、使い、レポートするのに最も簡単な形であるとは約束しません。だからこそ、戻すことは失敗ではなく設計のスキルなのです。
まず真実をモデリングしましょう。それから、その真実をどう届ける必要があるかを決めるのです。
おすわり、まて、モデル
Section titled “おすわり、まて、モデル ”犬に戻りましょう。今回は、いくつか意図的な選択をします。
犬種：選択リストか、独自のテーブルか？ このモジュールの後半で紹介する問いに通してみましょう。情報の列は1つより多いか？ はい。少なくとも大きさがあります。値はいくつあるか？ ケネルクラブは数百の犬種を公認していて（アメリカン・ケネル・クラブだけで205）、私の目安である約20をはるかに超えています。だから犬種は独自のテーブルに値し、各犬は自分の犬種を指し示します。これで、モジュール1から持ち越してきた問いに決着がつきます。犬種はそれ自体の箱です。
習熟度：選択リスト。 練習中、良好、上級。3つのラベルがあるだけで、それ以外に言うことはなく、変わることもありません。まさに選択リストの出番です。
それぞれの犬はいくつ芸を覚えているか？ 答えはすでにモデルの中にあります。その犬の犬の芸レコードを数えればよいのです。でもトレーナーは、2つのテーブルにまたがるレポートを作らずに、その数をすべてのレポートに載せ、それで並べ替えたり絞り込んだりしたいと考えています。そこで私は一歩戻り、覚えた芸の数（Tricks Known）を犬そのものに持たせます。これはコピーです。真実は依然として犬の芸の中にあり、この数はその表現にすぎず、歩調を合わせ続けなければなりません。Salesforceには、まさにそれをきれいに行う方法があります。モジュール6で見ていきます。
ここでひとひねり：ドッグスクールが猫も受け入れ始めます。 どうしましょう？ 一つの選択肢は、犬のテーブルの隣に猫のテーブルを、犬の芸の隣に猫の芸を追加することです。すべてが2倍になります。どの画面も2つ、どのレポートも2つ。そしてウサギを受け入れる日には3つです。もう一つの選択肢は、一歩下がって気づくことです。猫にも飼い主がいて、ブリーダーがいるかもしれず、品種があり、誕生日があり、根気よく教えれば芸の1つや2つも覚えます。犬と同じ事実、同じ関係です。そこで一般化します。ペット（Pet）に、犬か猫かを表す種（Species）を持たせます。各品種もまた種に属していて、種が本当に存在するのはそこです。ラブラドールは犬です。ペットは意図的にそのコピーを持ちます。そうすれば、どの画面もレポートも、品種を参照せずに「犬か猫か？」から始められます。これもまた意図的なコピーで、モジュール6ではそれ自体の役目を与えられます。
これが変化に備えた設計であり、トレードオフです。早すぎる一般化をすると、すべてが、誰も理解できない種類の項目を持った曖昧な「モノ」になってしまいます。私が一般化するのは、ビジネスが実際に2つ目の種類を持ち込んできて、その2つがほとんどすべてを共有しているときです。ここでの犬と猫のように。もし猫にまったく違う事実が必要なら、よく考え直すでしょう。
では、同じ種類の選択を、より大きなものがかかっているSteve Truckingで見てみましょう。
最もきれいなモデルが最良のシステムとは限らない
Section titled “最もきれいなモデルが最良のシステムとは限らない ”停車地にいるクルーを思い浮かべてください。配送には品目があります。設置にはチェックリストがあります。各手順で写真が必要です。受取人が署名します。
正規化されたモデルは美しいものです。配送 → 配送品目 → 設置チェックリスト → 写真。それぞれがあるべき場所にあります。
そこで、実際にそれを使う人たちと一緒に座ります。クルーは1日に約10か所の停車地を、家の前の車寄せで、しばしば電波のない場所で完了させます。私の美しいモデルが、一つの停車地を終えるために画面と関連リストの迷路を通らせるなら、アーキテクチャの問題を抱えていることになります。
私たちが設計しているのは、データモデルだけではありません。
システムを設計しているのです。
ユーザー体験が勝つこともある
Section titled “ユーザー体験が勝つこともある ”完璧に正規化されたモデルから私がときどき離れる理由の一つが、ユーザー体験です。
ある概念は技術的にはそれ自体のエンティティになり得るけれど、分けることでほとんど価値のない複雑さが加わるかもしれません。何階層もの子を持つ親は、学術的にはきれいでも、入力も保守も悲惨かもしれません。その概念は小さく安定していて、主に選択肢として使われるのかもしれません。
ここで私は、**「この事実は理論上どこに属するのか？」だけを問うのをやめ、「このシステムは実際にどう使われるのか？」**と問い始めます。
クリックが一つ増えるという不満のたびにモデルをフラットにするという意味ではありません。使いやすさは、アーキテクチャへの正当なインプットだという意味です。
レポートが勝つこともある
Section titled “レポートが勝つこともある ”レポートもよくある理由の一つです。
各小売パートナーはスコアカードをほしがります。地域別、月別の時間通りの配送です。きれいなモデルでは、配送は自分の物流センターを知っていて、物流センターは自分の地域を知っています。技術的には、それをたどれます。
でも、レポートツールはたどれるでしょうか？ 自分でレポートを作る人たちはどうでしょう？ 問いそのものより複雑なレポートアーキテクチャなしに、その問いに答えられるでしょうか？
そういうとき、私は地域を配送にコピーしたり導出したりして、使われる場所の近くに置くかもしれません。
これで重複を持ち込みました。ですから、もう一つの問いが必要です。真実を所有しているのは誰か？
元の値が変わったら、コピーはどうなるでしょう？ 変わるべきでしょうか？ それとも配送が行われた時点で正しかった値を保つべきでしょうか？ それは別々の要件です。
非正規化は複雑さをなくしはしません。
複雑さを移動させるのです。
参照関係か、選択リストか？
Section titled “参照関係か、選択リストか？ ”Salesforceの管理者がいつも出会う、もっと小さな例があります。ユーザーが値の集合から選ぶ必要がある。別のエンティティを作って関連づけるべきか、選択リストを使うべきか？
配送のステータスを例にとりましょう。予定済み、積み込み済み、配送中、到着間近、配送済み、設置済み、例外、返品。短く安定したラベルのリストです。選択リストこそ私がほしいものです。
次に停車地の種類です。配送のみ、設置付き配送、引き取り付き配送。こちらはそれ自体の情報を持っています。その停車地にどれくらい時間がかかるか、クルーにどんなスキルが必要か、どの設置チェックリストを使うか。独立して変わり、ビジネスが管理します。それはラベルではなくエンティティです。
理論上正規化できるすべての概念にオブジェクトを作れば、技術的には美しいけれど誰も使いたがらないシステムができあがります。簡単だからといってすべての概念を選択リストにすれば、あっという間に自分を追い詰めてしまいます。
そこで私は問います。それ自体の情報を持っているか？ 関係を持っているか？ 独立して変わるか？ データとして管理する必要があるか？ ビジネスがいずれラベル以上のものを必要とする可能性はあるか？
設計セッションで実際に私が尋ねる問いを紹介します。
情報の列が2つ以上あるか？ 値に説明、所要時間、スキルの一覧、所有者が必要なら、それはもうラベルではありません。
値はいくつあるか？ 私の目安はおよそ20です。値が20を超えると選択リストは破綻し始め、オブジェクトを考える時期です。50ある米国の州は、我慢して付き合っている例外です。国はもっとひどい。正直なところ、国の選択リストが大好きな人なんているでしょうか？ 私はうっとうしいと思います。
値は時間とともに作られるか、そして誰が作るか？ 選択リストの値を追加するのは設定の変更であり、つまり管理者が必要です。ビジネスが毎週値を追加し、追加する人が管理者でないなら、選択リストは新しい値のたびにチケットを立てさせることになります。
人がそれで絞り込んだりレポートしたりする必要があるか？ 選択リストはそれが得意です。参照関係はそれほどすっきりしません。参照関係のたびに一段増えます。レポートタイプがたどれるのは短い関連オブジェクトの鎖だけで（カスタムレポートタイプで使えるオブジェクトの関係は最大4つまで）、画面は関連リストの中の関連リストになり、コードは複雑になります。
値のリストは選択リストとして生まれ、時間とともに独立したオブジェクトになる資格を得ることがよくあります。資格を得るまで待ちましょう。
規模が答えを変えることもある
Section titled “規模が答えを変えることもある ”数千件のレコードでは見事に機能する設計も、数百万件ではまったく違う振る舞いをすることがあります。
ですから、図だけを見ないでください。数字を知りましょう。
Steve Truckingの配送は年に約100万件で、年30パーセントで成長しています。配送1件につき約8回のステータス更新があります。今年は800万件のステータスレコード、3年目には年約1,350万件です。そこに年400万〜500万枚の写真が加わります。
同じモデル。まったく違うアーキテクチャ。
大規模に向けた設計の章でずっと深く掘り下げます。今は、ボリュームはデータモデリングの判断を変え得ることを覚えておいてください。論理的に正しい関係が、どの規模でも自動的に最良の物理設計であるとは限りません。
利用者によってほしい形は違う
Section titled “利用者によってほしい形は違う ”ここまで、業務システムについて考えてきました。コーディネーターが配送のルートを組み、クルーが停車地を完了させ、ビジネスが動くにつれてシステムが変わります。
しかしビジネスは、何年分もの履歴を分析したいとも思っています。どのパートナーや地域が遅れがちか？ 配送時間はどう変わってきたか？ 設置で2回目の訪問が必要になる頻度は？
分析システムは、同じ情報を別の形で整理したいかもしれません。データウェアハウス、ファクト、ディメンション、スタースキーマといった用語を耳にするでしょう。ここでは解説しません。Steve TruckingではそれはSnowflakeのウェアハウスであり、コースの後半で改めて取り上げます。
今は、利用者によって、同じ真実の異なる形が必要になり得るとだけ覚えておきましょう。
AIがもう一つの利用者を加える
Section titled “AIがもう一つの利用者を加える ”そして今、もう一つの利用者がいます。AIです。
受取人が「荷物はどこ？」とメッセージを送ってきます。AIアシスタントはこれを調べられます。
配送10427、ルート3312、停車地7、トラック117、時間帯13:00〜15:00。
従来のアプリケーションは、そうした関係をたどることに何の不満もありません。しかし受取人に答えるには、アシスタントは複数の場所から組み立てたコンテキストが必要です。
お客様のRedrockの食器洗い機は、フェニックス物流センターから出発する今日のルートで7番目の停車地です。トラックはあと3か所で到着し、ご指定の午後1時〜3時の時間帯内です。
複数の関連エンティティから情報を取り出し、特定の一つの利用者のために、よりフラットでコンテキストの豊かな表現を組み立てたのです。
これは正規化されたモデルを壊すという意味ではありません。そして決して、「AIはフラットなデータが好きだから、すべてを一つの巨大なオブジェクトに入れよう」という意味ではありません。それはやめてください。
真実の源はきれいなままにしておきます。AIには、それがしている仕事のために作られた表現を渡します。分析で見たのと同じ考え方です。
一つの真実の源が、利用のための複数の形を支えられる。
グラウンディングと検索については、コースの後半でずっと深く扱います。
複数の真実を作らない
Section titled “複数の真実を作らない ”ここには危険があります。
レポートのために地域を配送にコピーし、フラットにしたものをSnowflakeに送り、AIアシスタントのためにコンテキストの豊かなものを作ったら、どれが正しいのでしょう？
その問いには答えが必要です。権威ある値がどこにあるのかを知りたいのです。それ以外はすべて、目的のためにその真実を表現したものです。
その場所が記録システムです。非正規化されたコピーはよいものになり得ます。停車地の画面、スコアカード、Snowflake、AIのコンテキストは、それぞれ自分のために作られた形があるほうが仕事をうまくこなしますし、それらを参照するのはかまいません。しかし何かが変わるとき、変更は記録システム、典型的にはリレーショナルモデルから始まり、外側へ、すべてのコピーへと流れていきます。誰もSnowflakeで地域を直したり、AIのコンテキストを手で編集したりはしません。源で直し、変更を流しましょう。
そして、これが最も重要になるのはデータが変わるときです。今日、ある物流センターが別の地域に移ったら、先月の配送は新しい地域を表示すべきでしょうか？ そうかもしれないし、そうでないかもしれません。履歴のためには、配送が行われた時点で正しかった地域が必要かもしれません。それはもはや同期の問題ではありません。ビジネスの判断です。
だから非正規化は、決して偶然に起きてはいけないのです。重複した事実の一つひとつが、所有、同期、履歴、信頼についての問いを生みます。第1章のトレードオフの考え方です。何を買っているのか（より簡単な画面、よりシンプルなレポート、AIのためのよりよいコンテキスト）と、何を支払っているのか（重複したデータ、同期、より複雑な真実の所有）を知りましょう。そして、きれいな論理モデルから始めたからこそ、それぞれのコピーを指して、**「これがあちらに属することはわかっている。この要件のために、ここにその表現を置いている」**と言えるのです。それは、レビューし、異を唱え、書き残せる判断であり、次のアーキテクトがその理由を知ることができます。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”非正規化を検討するとき、私が決めているのは次のことです。
- それぞれのビジネス上の事実の、権威ある源がどこにあるか。
- きれいなモデルが、ユーザー、レポート、規模、性能に本当の問題を生んでいるか。
- よりシンプルな表現が重複に見合うか、そしてコピーをどう信頼できる状態に保つか。
- 現在の源が変わったとき、過去の値も変わるべきか。
- 分析やAIが、業務システムとは違う形のデータを必要としているか。
出発点は決して変わりません。真実がどこに属するかを知ること。そして要件がそれを正当化するときに、届けるための形を整えるのです。
次はSalesforceが再び登場します。設計してきたものを物理データモデルにしていきます。
さらに学ぶ
Section titled “さらに学ぶ ”- Build Powerful Reports with Custom Report Types (opens in a new tab)、Salesforce Admins、2019年6月24日（英語、2026-10-12確認）：カスタムレポートタイプは「最大4つのオブジェクトリレーションにまたがることができる」。
- Unleash the hounds, terriers and lapdogs: American Kennel Club recognizes 3 more breeds (opens in a new tab)、PBS NewsHour、2026年1月2日（英語、2026-10-12確認）：「AKCは、これら3つの新顔を含む205の犬種を公認している」。
- おまけ：FCI Breeds Nomenclature (opens in a new tab)、国際畜犬連盟（Fédération Cynologique Internationale）（英語、2026-10-12確認）：10のグループに分けられた、国際連盟の犬種リスト。ざっと眺めてみれば、犬種が独自のテーブルに値した理由がわかるでしょう。