はじめに
データモデリングのある側面は主観的になります。実際、データモデリングのほとんどの側面は主観的であると言っても過言ではありません。情報表現の方法に関する質問には多くの答えがあり、どの答えがコンテキストに最適であるかが常に明確であるとは限りません。実装の詳細に入る前に、そのコンテキストと要件を可能な限り理解するように努める必要があります。これには時間と、他の人々の時間、そして多くの質問が必要です。調査とインタビューは、ユーザーエクスペリエンスデザインと同じくらいデータベース設計にとって重要です。不完全、詳細すぎ、侵襲的、または構造が不十分なデータは、システムの保守担当者だけでなく、ユーザーと対象者にとっても少なくとも同じくらい苦痛な生活を送る可能性があります！要件を渡されて実行するように指示されている場合でも、問題とその起こりうる結果を完全に考える最初の人物である可能性が非常に高いです。
データモデリング問題の核心は、有用なエンティティを定義し、それらがウェブまたは接続のグラフで相互にどのように関連しているかを特定することです。これらのエンティティは、物理オブジェクトまたは無形の概念のクラスを表します。また、場所、出荷、割り当てなど、その中間の多くのものも表します。しかし、この記号論的空間を占める表現は物理法則に縛られておらず、記号表現と記号内容の間に必ずしも厳密な一対一の対応関係があるとは限りません。単一のエンティティは、作業している概念の多くで共有される側面、またはサブシステム全体を表す場合があります。あるいは、単一の概念のように見えるものが、より有用またはより管理しやすいように、多くに分割される方が良い場合があります。
エンティティ単独では、それほど多くの意味しか持ちません。ズールー族のことわざ「人は他の人を通して人である」は、抽象的な表現にとっても間違いではありません。データモデルは、孤立した事実の単一のカテゴリを表すことはめったにありません。むしろ、システムを表すことが多く、システムの正確で有用な表現にとって、わずか数個のコンポーネントの関係と相互作用は、コンポーネント自体と同じくらい重要です。
主観性のため、これらの質問に抽象的に答えることは不可能です。これは、データを収集する利害関係者に質問することで、考え抜き、積極的に調査するための演習です。それでも、最初に作成する答えはせいぜい暫定的なものになります。リリースまで変更されずに残るデータモデルはまれです。
エンティティとして資格を得るのに十分重要なものは何ですか？
「本当に気にするカテゴリは何ですか？」は、当たり前すぎて、 assumptions を石に刻む直前であっても、質問することを忘れてしまう可能性がある質問です。システムの主題とオブジェクトを定義することは、使用しているデータベースに関係なく、最初に考えるべきことです。また、データストアの選択にも関連しています。たとえば、更新頻度よりも読み取り頻度がはるかに高い、大量の計測器の読み取り値やその他の簡単な事実を気にする場合は、CassandraやHBaseのような列指向データベースに向かう必要があります。
リレーショナルデータベースは複雑です。システムについて話す場合、複雑なものと複雑なものを区別する必要があります。複雑なシステムには、ニューラルネットワーク、経済、言語、生命自体が含まれます。各コンポーネントは、限られたコンテキスト情報に基づいて他の多くのコンポーネントと相互作用し、システム全体はその環境と相互作用し、歴史と動作が出現します。
一方、複雑なシステムは、多くの個々の部品で構成されているだけであり、各部品は時計やエンジンのリズムで作用し、作用を受けます。データベースに履歴をエンコードし、動作を定義することは可能ですが、そうすることは厳密にトップダウンの演習です。データモデルの見かけ上出現的な特性は、決定論的なバグに過ぎません。データモデルの要素は他の要素と相互作用しますが、常に同じ要素と常に同じ方法で相互作用します。そして、一部の要素はデータベースの表現にとって、網戸が潜水艦にとってそうであるように、せいぜい機械的な故障点を追加するだけです。
エンティティ間のどの接続が重要ですか？
複数のユーザーベースとそのデータが同じテーブルに格納されているデータモデルを設計する方法は2つあります。マルチテナントの問題については後で詳しく説明しますが、共有スキーマモデルには、モデリングにおける主要な懸念事項を例示する特定の選択肢があります。すべてのレコードにtenant_id値を含める必要がありますか、それともテナントに直接的で意味のある接続があるレコードのみを含める必要がありますか？
概念的には、外部キー制約が適用されている限り、行がどのテナントに属しているかを識別することはそれほど難しくありません。テーブルからtenantsに向かって関係をたどってJOINすると、どの結合積に探しているtenant_id値が含まれているかが、そのテナントに属しているかがわかります。ただし、スキーマがさらに進化するにつれてSQLの管理が非常に厄介になる可能性があり、システムに十分なデータがある場合、パフォーマンスが懸念事項になり始める可能性があります。これは、より遠いテーブルで追加のtenant_id列を管理することが自動的に価値があるという意味ではありませんが、それが合理的な決定になるようにするには、それほど時間はかかりません。
エンティティと関係は、ノードとエッジの有向グラフを構成します。「有向」とは、エッジが一方向の接続であることを意味します。tenant_id値を持つレコードは、tenantsテーブルの存在と、その中の特定のレコードの両方を暗示しています（適切な外部キー制約が設定されている場合、暗示するのではなく保証します！）。ただし、tenantsからのレコード自体は、それに属する可能性のある他のデータについて何も暗示していません。
ノードまたはエッジを追加するたびにグラフが複雑になり、その結果、データモデルの保守と改善にはさらに多くの労力が必要になります。ただし、この複雑さは、グローバルな懸念事項であると同時にローカルな懸念事項でもあります。エンティティのセットは、管理と使用の両方が困難な、十分に重要な関係の絡み合いで接続できます。これらのサブシステムは、PostgreSQLのようにビューやテーブル継承などのメカニズムによってある程度シールドされることが多く、その正味の効果は、オブジェクト指向ソフトウェア開発におけるファサードパターンに似ています。
組織単位はどのように相互作用しますか？
モデルの任意の要素（エンティティ、関係、または複数のエンティティと関係で構成されるサブグラフ）は、設計対象の組織の一部、またはそのような単位間の相互作用の場所を表す場合があります。在庫は、製造とロジスティクス、またはロジスティクスと販売を結び付けます。経費記録は、財務と人事、および人事と会社全体の部門を結び付けます。一部のアクターは、主に端にある少数のエンティティを通じてモデルと相互作用する場合があります。これは、システムのより深い仕組みへの洞察がほとんどない場合、または組織全体の機能を改善する機会を、残りの部分との可視性と接触を増やすことで提供できる場合に、課題となる可能性があります。
コンウェイの法則のように、永続的な観察はほとんどありません。組織は、システム設計、およびデータベースも例外ではない、コミュニケーション構造を再現することを運命づけられています。一部のデータモデリングの問題は、全体として、または部分的に、データベースがほとんど役に立たないコミュニケーションの問題です。
どのくらいの詳細さが必要ですか？
最初の2つの質問を逆にするのも役立ちます。この可能性のあるエンティティまたはその関係を完全に無視した場合、データモデルのユーザーは何を見逃しますか？もちろん、最初に重要であると特定した要素のほとんどはそうです。しかし、最初はそれほど重要ではないものもあり、それらを省略または簡略化すると、モデル全体の機能と保守性が向上する可能性があります。
重要性の問題には、「はい」と「いいえ」以上の答えがあります。問題領域のある側面をエンティティとして独自に表現する必要はないかもしれませんが、存在や数量のような一般的で管理しやすい事実を依然として気にする可能性があります。製造業では、部品番号は、校正、プロセス履歴、サブコンポーネント、容量、公差、およびさまざまな部品タイプに重要なさまざまな特性に関する豊富な情報への鍵となります。倉庫業では、部品番号はSKU（「stock keeping unit」の略）になり、重要な詳細ははるかに単純になります。数量、色、重量、場所はどこですか？
一部の情報も役立ちますが、すでに独自の内部構造があり、エンティティと関係に変換するのはそれほど便利ではありません。階層、ハイパーテキストドキュメント、部品表、さらにはデータベースの他の場所にあるエンティティ関係サブグラフの一時的な「ワーキングコピー」。これらまたはそれらに含まれる情報は、関係的に表現できますが、外部構造と内部構造の境界を越える重要な関係がない限り、それらを開く労力は価値がない可能性があります。この種の情報が主な関心事である場合は、（階層型ドキュメントの場合は）CouchDBやMongoDBのような特殊なデータベースが適切である可能性があります。それらがそれ以外の場合はリレーショナルモデルの例外である場合、JSONやXMLなどのデータ型は、モデルを2つ以上のデータベースに分割するのを避けるのに役立ちます。追加のデータストアはそれぞれ、保守と調整に多くの労力がかかるだけでなく、関係が基づいている情報が消えることのない保証である参照整合性は、単一のデータベース内でのみ保持されます。
どのサブグラフ、集計、および統計が役立ちますか？
リレーショナルデータベースのクエリには時間がかかります。具体的にどのくらいの時間がかかるかは、ディスク速度やCPUパワーなどのホストコンピュータの物理的特性、キャッシングや最適化などのRDBMSの運用能力、そして最後にクエリ自体の構成という、さまざまな要因によって異なります。データモデルは、最初の2つのクラスによって設定された制限に対応する必要がありますが、その成功の主な決定要因の1つは、3番目の問題、つまりクエリの構成の問題をどれだけ予測できるかです。
スパンされる関係の数は、パフォーマンスと保守性の両方にとって、クエリ構成の最も重要な側面の1つです。特に結合されるエンティティが小さいか、適切にインデックスが付けられている場合、高いJOIN数が必要以上にパフォーマンスが低いとは限りませんが、最良の場合でも、それぞれがクエリ作成者の認知負荷を増やします。ユーザー、バックエンド開発者、およびその他のデータベースユーザーが、一般的に必要な結果セットをできるだけ簡単に組み立てられるようにする必要があります。
データベースには、これを実現するためのツールがいくつか用意されています。ビューは、一般的に使用されるサブグラフとその計算をカプセル化し、ユーザーとアプリケーションから複雑さをシールドするのに役立ちます。データベースで2次表現を一元化することで、たとえば、すべての付随情報を含む発注書や、倉庫の一般的な統計情報など、単一の規範的な表現を保証することもできます。通常のビューは、実行中のステートメントに統合される格納されたクエリであるため、パフォーマンスには何も影響しません。ただし、ほとんどのリレーショナルデータベースは、「マテリアライズド」ビューをサポートしています（MySQLとMariaDBは注目すべき例外です）。これらは、テーブルのようにデータをディスクに永続化するため、検索がはるかに高速になりますが、そのデータは古くなり、更新する必要があります。
ここでの最後の手段は、非正規化です。エンティティのデータまたはカウントや合計などの有用な集計を、別のエンティティのプロパティとしてインラインで格納することです。正規形については、今後の章で詳しく説明しますが、これは軽々しく行うべき手順ではないと言えば十分でしょう。それでも、必要なデータを組み立てるのに時間がかかりすぎる場合は、高レベルの正規化を放棄することが、追加の管理労力に見合う価値がある場合があります。ここで極端なことをする必要がある場合は、再び列指向データベースについて考える時が来ました。
何を保存すべきでないですか？
あなたは持っていない情報に責任を負いません。データを保護するために構築された業界全体がありますが、セキュリティ対策は完璧ではありません。非常に厄介な種類の問題を回避する最も簡単な方法は、そのような種類の問題を引き起こす可能性のあるデータを収集しないことです。ただし、これはデータベースだけにとどまらないことに注意してください。機密情報は、ログ、レポート、ソース管理、その他のシステムに表示される可能性があります。
最も深刻な情報クラスで、最も大きな影響を及ぼすのは、間違いなく人に関するものです。人に関する情報は必然的に政治的であり、人間が参加するシステムをモデル化することは、モデラーの政治を反映し、強化します。誰がシステムに入力されるか、または入力されるか、どのような能力で、どの特性が重要または重要でないと想定されるか、誰に可視であるか：政治、そのすべてです。私たちは、ぞんざいな、または侵略的な個人データの扱いの影響をようやく見始めたばかりです。ますます多くの人々の情報がデータモデルに絶えず投入されており、これらのモデルは、それに見合った注意を払って開発されているとは限りません。いくつかのケースでは、それらの情報を搾取するために明示的に設計されています。
個人を特定できる情報、またはPIIは、他のデータが誰に関連しているかを示します。PIIがない場合、ランダムな医療記録は真空状態の履歴です。どこかの誰かが、番号でのみ知られていますが、これらの子供時代の予防接種を受け、ここで肺炎を発症し、そこで軽度の皮膚がんを発症し、ある時点で薬物依存症を発症し、インフルエンザに数回かかり、双極性障害を発症しました。その医療記録番号を名前と住所に関連付けると、突然、あなた（またはそれを見ることができる人）は、特定の人の人生について、他の人が知ることを意図または望んでいるよりもはるかに多くを知ることになります。収集したデータが保護に成功するよりも多い場合の結果は、データが誰のものであるかによって、短い不快な会話から、失業、ID盗難、恐喝、およびさまざまなヘイトクライムに至るまで多岐にわたります。
医療記録に関しては、多くの国がアクセスと開示を管理する厳格な法律を持っています。ほとんどの他のコンテキストの情報は、法的規制が厳しくないか、まったくないため、名前と住所、生年月日、バイオメトリクス、母親の旧姓、パスポートや納税者ID番号などの政府が割り当てたID値をどれだけ厳重に保護する必要があるかを検討するのはあなたの責任です。PIIは、2004年にAOLが匿名化された検索ログを公開したと考えたときにも発生したように、予期しない場所にポップアップ表示される可能性もあります。さらに悪いことに、識別できない事実であっても、十分な量になると識別できるようになります。あなたと同じ居住地、性別、役職、電話モデル、およびお気に入りのレストランを持っている他の人は何人いますか？その事実の組み合わせに関連付けられる可能性のある他のものは何ですか？
別の種類の機密情報は、他の誰かの代わりに行動することを可能にします。ソーシャルメディアやその他のWeb資格情報、銀行のルーティングと口座情報、クレジットカード番号はすべて、信頼して提供されます。場合によっては、特に支払いに対処する場合、この信頼の負担を軽減するサードパーティサービスが存在します。自分で負担する非常に正当な理由がない限り、それらを使用してください。
次に何が起こるのですか？
データモデルは静的ではありません。要件は進化します。ビジネスは方向転換します。外部の情報源は出現、変化、消滅します。これは、アプリケーション開発によって設定された活発なペースと同じペースでは発生しませんが、大きな変化、小さな微調整、およびその間のすべてが発生します。注意深い設計は、より遅く、より小さな変更に向けてバランスを保つのに役立ちますが、データモデルで大規模な手術を実行する必要がある時点が来るのを防ぐ保証はありません。また、一見小さな変更であっても、展開に予期せぬ困難をもたらす可能性があります。たとえば、PostgreSQL 11までは、非NULLデフォルト値を持つ新しい列を追加するには、テーブル内のすべてのレコードを書き換える必要がありました。数百万行ではあまり楽しくありません！
現在が未来よりも重要です。モデルが今役に立たない場合、後で役に立つようになるのを見る機会はなさそうです。自然または不自然な選択の力が常に働いていますが、これらの圧力に適応できないデータベースは滅びます。将来の可能性の計画については後で詳しく説明しますが、自分自身を追い込むことができる隅があることを知っているだけでも、その運命を回避するのに役立ちます。
