データベース内のテーブル間の依存関係

4.1 はじめに

データベース テーブルを通常のテーブルに変換することで、データベース テーブル間の関係を分析できるようになります。関連する 2 つのテーブル間で相互作用する要素の数は、カーディナリティと呼ばれます。カーディナリティは、データをテーブルにどのように効率的に分割するかを制御するのに役立ちます。

理論的には、すべてのエンティティは相互の関係を維持できますが、実際には、エンティティ間には 3 種類の関係があります。

• 1対1
• 1 対多
• 多対多

4.2 1対1のコミュニケーション

エンティティ B の各インスタンスに対してエンティティ A のインスタンスが 1 つだけある場合、それらは 1 対 1 の関係 (多くの場合「1:1」と示されます) があると言われます。ER 図では、このような関係は、両端に小さなバーが付いた線で示されます。

1 対 1 の関係は、一般に、それらを別々にしておく正当な理由がない限り、2 つのテーブルのデータを 1 つに結合するのが最適であることを示します。

ただし、状況によっては、1 対 1 の関係を持つテーブルを使用することが合理的です。テーブルに説明などのオプションのデータを含むフィールドがあり、多くの場合それらが空である場合、すべての説明を別のテーブルに移動することが理にかなっています。これにより、頻繁に発生するギャップがなくなり、データベースの効率が向上します。 。

次に、データを適切にマップするには、各テーブルに少なくとも 1 つの同一の列を含める必要があります (これには主キーを選択するのが最善です)。

4.3 1対多の関係

このタイプの関係は、あるテーブルのレコードが別のテーブルの複数のエンティティに関連付けられている場合に発生します。たとえば、同じ顧客が複数の注文をしたり、図書館の訪問者が 1 回の訪問で複数の本を借りることができます。1 対多の関係 (略して 1:M) は、以下の例に示すように、カラスの脚表記を使用して図で表現されます。

データベースの計画時に 1:M 関係を適用するには、「1 つの」テーブルの主キーを属性として「多数の」テーブルに追加するだけです。主キーが別のテーブルにある場合、それは「外部キー」と呼ばれます。「1 つの」テーブルは親テーブルとみなされ、「多数」のテーブルは子テーブルとみなされます。

4.4 多対多の関係

1 つのテーブル内の複数のエンティティが別のテーブル内の複数のエンティティに接続できる場合、それらのエンティティには多対多 (または M:M) の関係があるとみなされます。たとえば、各生徒は複数の異なるクラスに参加することができ、したがって各クラスに多くの生徒が来る可能性があるため、このような関係が生徒とクラスの間に存在します。

ER 図では、このタイプの関係は次のように表示されます。

残念ながら、このような関係をデータベースに直接実装することは不可能です。したがって、2 つの 1 対多の関係に分割する必要があります。

これを行うには、2 つのテーブルの間に新しいエンティティを作成する必要があります。販売と製品の間に M:M 関係が確立されている場合、新しいエンティティは各販売の内容を表すため、「販売された製品」と呼ぶことができます。

「販売商品」とテーブル「売上」とテーブル「商品」はタイプ1:Mで紐付けられます。モデルが異なると、このような中間エンティティは「接続テーブル」、「関連エンティティ」、「ノード テーブル」などと呼ばれます。

各リンク テーブル エントリは、隣接するテーブルの 2 つの異なるエンティティを接続します (追加情報も含まれる場合があります)。たとえば、学生とクラス間のリンク テーブルは次のようになります。

4.5 必須か否か?

リンク分析の別のアプローチは、接続されたエンティティのうちのどれが別のエンティティの存在の前提条件であるかを判断することです。オプションのリンク側はトランクに丸印が付いています。

たとえば、国家が国連に独自の代表者を置くためには、その国家が世界地図上に存在する必要がありますが、次のような反対の記述は誤りになります。

2 つのエンティティは相互依存することができます (つまり、一方が他方なしでは存在できません)。

再帰的リンク

場合によっては、テーブルがそれ自体を参照することがあります。たとえば、従業員テーブルには、同じテーブル内の別の従業員を参照する「マネージャー」属性がある場合があります。これが再帰的な関係です。

追加の接続

リンクが複数回表現される場合、リンクは冗長であるとみなされます。原則として、そのうちの 1 つを削除しても、重要な情報は失われません。たとえば、エンティティ「生徒」がエンティティ「教師」に直接的にだけでなく、「クラス」を通じて間接的にも接続されている場合、エンティティ「生徒」と「教師」の間の関係を削除することは理にかなっています。この決定は、クラスを通じてのみ生徒を教師に割り当てることができるという事実によって正当化されます。

4.6 データの参照整合性

主キーと外部キーを変更するときは、データの参照整合性などの側面を観察する必要があります。その主なアイデアは、同じデータを格納するデータベース内の 2 つのテーブルの一貫性を保つことです。

データの整合性は、テーブル間に適切にリンクされ、テーブル間に適切に構築された関係を表します。データの整合性が侵害される可能性があるのはどのような場合ですか:

• 削除の異常。メインテーブルから行が削除されるときに発生します。この場合、従属テーブルの外部キーは、マスター テーブルから削除された行を参照し続けます。
• 挿入異常。行が依存テーブルに挿入されるときに発生します。この場合、従属テーブルの外部キーは、マスター テーブルのどの行の主キーとも一致しません。
• アップデート異常。このような異常により、1 つのテーブルの複数の行に同じオブジェクトに属するデータが含まれる可能性があります。1 つの行のデータを変更すると、別の行のデータと競合する可能性があります。

削除異常

削除の異常を解決するには、外部キーを次の 2 つの制約のいずれかに設定する必要があります。

依存テーブルの行に必ずマスター テーブルの行が必要な場合、外部キーはカスケード削除に設定されます。つまり、マスターテーブルから行が削除されると、関連する行が従属テーブルから削除されます。

依存テーブルの行がメイン テーブルの行との関係を許可しない場合 (つまり、そのような関係はオプションです)、関連する行がメイン テーブルから削除されるときに、外部キーは NULL に設定されます。外部キー列は NULL 可能である必要があります。

挿入異常

依存データ テーブルに追加する際の挿入異常を解決するには、外部キーを表す列が NULL 可能である必要があります。したがって、追加されるオブジェクトがメインテーブルと接続していない場合、外部キー列は NULL 値になります。

異常を更新する

更新異常の問題を解決するには、前に説明した正規化が適用されます。