データベース内の1対多の関係とは何ですか？例を挙げた説明

1対多の関係は、最も一般的なデータベースの関係の1つです。 1対多の関係をいつどのように使用するかを知りたい場合は、この記事が出発点として最適です。

エンタープライズレベルのソフトウェアを設計する場合でも、叔父の切手収集を追跡するための単純なデータベースを作成する場合でも、必ず1対多の関係を使用して情報をリレーショナルデータベースに保存します。

リレーショナルモデルの簡単な紹介

リレーショナルデータベースは、最新のトランザクションアプリケーションのコアコンポーネントです。リレーショナルモデルは、各行を識別する少なくとも1つの一意のキーを持つテーブル（行と列で編成されたデータ）で構成されます。各テーブルはエンティティを表します。これを次の例に示します。これは、顧客の注文を表す非常に単純なバージョンのテーブルです。

Vertabeloを使用してオンラインで作成した上記の図には、単一のテーブルがあります。表の各行は1つの順序を表し、各列（属性とも呼ばれます） ）は、注文に含まれる個々の情報を表します。

Vertabelo設計ツールにまだ精通していない人のために、記事「ER図で使用される記号は何ですか？」使用される記号と規則について説明します。また、データベースモデリングコースを使用して、リレーショナルモデルとデータベースについて詳しく知ることもできます。

関係とは何ですか、なぜそれらが必要なのですか？

前の例で使用したテーブルを詳しく見ると、実際には完全な順序を表していないことがわかります。それはあなたがそれが持っていると期待するであろうすべての情報を持っているわけではありません。注文した顧客に関連するデータが含まれておらず、注文した製品やサービスに関するデータも含まれていないことに気付くでしょう。

注文データを保存するためにこの設計を完了するにはどうすればよいですか？ 注文に顧客と製品の情報を追加する必要があります テーブル？そのためには、以下に示すように、顧客名、納税者番号、住所などの新しい列（属性）を追加する必要があります。

そうすると、すぐに問題が発生します。ほとんどの顧客は複数の注文を行うため、このシステムは、顧客ごとに1回ずつ、顧客情報を何度も保存します。それは賢明な動きではないようです。

また、お客様が電話番号を変更するとどうなりますか？誰かが顧客に電話する必要がある場合、誰かが新しい情報で数百（または数千）の既存の注文を更新しない限り、以前の注文で古い番号を見つける可能性があります。そして、他の変更についても同じことが言えます。

リレーショナルモデルでは、各エンティティを個別のテーブルとして定義し、それらの間の関係を確立する必要があります。すべての情報を1つのテーブルに保存するだけでは機能しません。

テーブル間の関係にはいくつかの種類がありますが、おそらく最も一般的なのは1対多の関係であり、多くの場合1：Nと記述されます。この種の関係は、テーブル内の1つの行（通常は親テーブルと呼ばれる）が別のテーブル（通常は子テーブルと呼ばれる）の多くの行と関係を持つことができることを意味します。 1対多の関係の一般的な例は次のとおりです。

• 自動車メーカーはさまざまなモデルを製造していますが、特定の自動車モデルは1つの自動車メーカーによってのみ製造されています。
• 1人の顧客が複数の購入を行う場合がありますが、各購入は1人の顧客によって行われます。
• 1つの会社に多数の電話番号を設定できますが、電話番号は1つの会社に属します。

テーブル間には他のタイプの関係もあります。それらについて詳しく知りたい場合は、多対多の関係についてのこの記事を参照してください。

最初の注文の例に戻ると、Customer テーブルは親テーブルであり、Orderになります 子供をテーブルに置く;顧客は多くの注文を持つことができますが、注文は1人の顧客に属することができます。

1対多の定義では、親テーブルの行を各子テーブルの多くの行に関連付けることができますが、必須ではないことに注意してください。実際、この設計では、顧客はゼロの注文（つまり、まだ最初の購入を行っていない新規顧客）、1つの注文（1回の購入を行った比較的新しい顧客）、または多数の注文（頻繁な顧客）を持つことができます。

ER図に1対多の関係を表示する

ER（またはエンティティ関係）図を使用した単純な顧客注文システムのより完全な例を見てみましょう。 （これらの図について詳しく知りたい場合は、Vertabeloの機能：論理図が出発点として最適です。）モデルは次のとおりです。

これはより現実的なデザインです。ダイアグラムに新しいエンティティ（テーブル）があり、テーブル Customerが含まれていることがわかります。 、Order 、Order Detail 、およびProduct 。ただし、気付く最も重要なことは、現在関係があることです。 テーブル間 。

データベースモデルでは、関係は2つのエンティティを結ぶ線で表されます。これらの関係の特徴は、さまざまなコネクタで表されます：

• 垂直線が1つある場合、そのコネクタに最も近いエンティティには、関係の影響を受ける行が1つだけあります。これは1対多の「1つ」です。
• カラスの足のように見える複数行のコネクタがある場合、そのコネクタに最も近いエンティティには、関係の影響を受ける複数の行があります。それは「多く」です。

画像を見て表記法を知っていると、図が各Orderを定義していることを理解するのは簡単です。 多くのOrder Detailを持つことができます そして、それぞれのOrder Detail 単一のOrderに属します 。

テーブル間の1対多の関係の実装

2つのテーブル間の1対多の関係を定義するには、子テーブルが親テーブルの行を参照する必要があります。それを定義するために必要な手順は次のとおりです。

1. プライマリ識別子の値を格納する列を子テーブルに追加します。 （実際、ほとんどのデータベースエンジンでは、主キーだけでなく、親テーブルの任意の一意のキーにすることができます。）ビジネスニーズに応じて、列を必須として定義できます。それでも、外部キー列は通常作成されます

注： 参照する列の名前を、参照される（親）テーブルと同じに保つことをお勧めします。これにより、関係をさらに簡単に理解できます。

2. 外部キーを追加します 子テーブルの制約。これは、この新しい列に格納されている各値が親テーブルの行を参照していることを示しています。

外部キー制約は、リレーショナルデータベースで利用可能な機能であり、次のことを強制します。

1. 子テーブルに行を追加する場合、参照する列の値は、親テーブルの1つ（および1つのみ）の値と一致する必要があります。 （そのため、主キーまたは一意キーを構成する列または列のセットを参照する必要があります）。
2. 誰かが親テーブルから行を削除しようとした場合、または参照として使用された一意/主キーの値を変更しようとした場合および その行を参照する子テーブルがある場合、操作は失敗します。

これらの2つの機能により、データベースの整合性が維持されます。存在しない顧客を参照する注文を作成したり、すでに注文を持っている顧客を削除したりする可能性はありません。

外部キーの作成

外部キー構文は通常、ターゲットデータベースエンジンに依存します。論理モデルを定義したら、Vertabelo論理図の「物理モデルの生成…」機能を使用して、（データベースに依存しない）モデルをデータベースプロバイダーに一致する物理モデルに変換できます。 Vertabeloは、ターゲットデータベースにテーブルとリレーションシップを作成できるようにする必要なSQLスクリプトも生成します。

1：N関係のいくつかの実用的な例

それでは、実際の1対多の関係の例をいくつか見てみましょう。

主キーを使用した1対多の関係

これは、1対多の関係を定義するときにおそらく最も一般的なシナリオです。子テーブルは、親テーブルの主キー値を使用して関係を確立します。

この例では、基本的なオンラインストリーミングサービスについて説明します。各テーブルに何が格納されているか、モデル内の他のテーブルとどのように関連しているかを確認しましょう。

1. 各ServiceType アカウントの「動作」を定義します（たとえば、アカウントでフルHDが有効になっている場合、同時にシステムに接続できるユーザーの数など）。他のエンティティとは1つの関係があります：
   • Accountとの1対多の関係 、つまり、各サービスタイプは、そのタイプの多くのアカウントを持つことができます。
2. 各Account 1人の顧客に関する情報を格納します。他のエンティティとは2つの直接的な関係があります。
   • 各アカウントは単一のServiceTypeに属しています 、上記で説明したように。
   • このテーブルは、Profileと1対多の関係にあります テーブル。つまり、複数のユーザーが同じアカウントを使用してシステムに接続できます。
3. 各Profile システム内のユーザーを表します。他のエンティティとは2つの関係があります：
   • 各プロファイルは単一のAccountに属しています 。これにより、すべての家族（または友人のグループ）が同じアカウントを共有できるようになりますが、各メンバーには独自の個人属性（プロファイル名など）があります。
   • 各プロファイルには固有のAvatarがあります 。
4. 各Avatar は、各アカウントユーザーをすばやく特定できる画像です。別のエンティティと1つの関係があります：
   • Profileとの1対多の関係 、つまり、1つのアバターを異なるアカウントのプロファイルに割り当てることができます。

自然または代理の一意のキーとの1対多の関係

代理主キーの使用は、テーブルをモデル化するための広く受け入れられている方法です。 （代理主キーはデータベースによって生成され、実際のビジネス価値はありません。）この方法では、使用が簡単で、変更が必要な場合にある程度の柔軟性が追加されたキーが生成されます。

ただし、状況があります。外部システムと対話する必要がある場合–データベースで生成されたキーを使用することは悪いアプローチです。これらのシナリオでは、通常、保存されているエンティティの一部であり、データベースによって自動的に生成されない一意の値である自然キーを使用することをお勧めします。

次の例は、車両（つまり、車のメーカー、モデル、色、年式）、その所有者、および関連する交通違反を追跡する組織の基本的なデータモデルを表しています。定義したとき、これらの情報はすべてシステムによって内部的に処理されるため、代理の主キーを使用して、車両とメーカー、モデル、所有者の間の関係を確立しました。

このシステムでは、別の都市の警察官が、車両の主キー（VehicleID）を使用して違法に駐車された車を報告するにはどうすればよいですか。 ）？このような情報は、駐車中の車両では自然に利用できませんが、ナンバープレートはあります。つまり、外部ソース（この例では、国内の警察署）から情報を受信して​​関連付ける最も簡単な方法は、代理の主キーの代わりに自然な一意のキーを使用することです。

SQL Serverのこの論理図の物理的な実装は、次の場所にあります：

同じテーブル上の1対多の関係

前の例では、2つ以上のテーブル間の関係に焦点を当てていましたが、同じテーブルの行間で関係が発生するシナリオもあります。このような1対多の関係は、階層関係とも呼ばれます。多くのシステムで、組織図、総勘定元帳、または製品とその構成部品など、ツリーのような構造を表すために使用されます。

この種の構造を初めて作成する必要があるときは、次の図に示すように、階層内の各レベルのテーブルを定義したくなるでしょう。

このアプローチには多くの問題があります：

• すべてのテーブルはほぼ同一であり、同一の情報を格納します。
• 組織が新しいレベルを追加する場合は、データモデルを変更し、新しいテーブル、新しい外部キーなどを追加する必要があります。
• 従業員が昇進を受け取った場合は、あるテーブルからそれらを削除して、別のテーブルに挿入する必要があります。

したがって、この種の構造をモデル化する最良の方法は、次の図に示すように、それ自体を参照する単一のテーブルを使用することです。

ここに、単一のEmployeeが表示されます。 テーブルとEmployeeID_Managerという名前の列 。その列は、現在の従業員のスーパーバイザー/マネージャーである同じ組織内の別の従業員を参照しています。

_Managerを追加しました 現在の行のIDとマネージャーのIDを区別するためのサフィックス。 （ManagerIDを使用できます 代わりに、参照される列の元の名前を保持し、両方が同じテーブルにある場合は、実際に持つ役割を説明するサフィックスを追加することをお勧めします。

階層関係の理解は、他の1対多の関係よりも複雑です。ただし、すべての情報が格納されているテーブルを忘れて、実際には異なるテーブルがあり、それぞれが階層内のレベルを表していると想像すると、視覚化が少し簡単になります。 2つのエンティティ間の関係を作成し、それらを1つのエンティティに結合するとします。

次は何ですか？

提供されている例は、1対多の関係を必要とするさまざまなシナリオを特定するのに役立ちます。 Vertabelo Database Modelerを使用して、独自のデータベース構造の設計を開始できます。これは、論理モデルを生成するだけでなく、必要なデータベースプロバイダー用にその物理バージョンを作成できるWebベースのツールです。

今度はあなたの番です。コメントセクションを使用して、この記事に対するあなたの考えを伝えたり、追加の質問をしたり、データベースモデリングの経験を共有したりしてください。