主キーと外部キーは、複数のテーブルを効率的なリレーショナル データベースに編成するための接着剤です。主キーと外部キーの設計は、物理データベースのパフォーマンスと可用性に決定的な影響を与えます。
データベース スキーマは、理論上の論理設計から実際の物理設計に変換する必要があります。主キーと外部キーの構造は、この設計プロセスの核心です。設計したデータベースが本番環境で使用されると、これらのキーを変更するのは困難になるため、開発段階で主キーと外部キーを設計することは非常に必要であり、価値があります。
主キー:
リレーショナル データベースは、データベースの物理スキーマの基礎である主キーに依存します。主キーには物理レベルで 2 つの目的しかありません。
1. 行を一意に識別します。
2. 外部キーによって効果的に参照できるオブジェクトとして。
上記の 2 つの用途に基づいて、物理レベルで主キーを設計するときに私が従ういくつかの原則を以下に示します。
1. 主キーはユーザーにとって無意味である必要があります。多対多の関係を表す結合テーブル内のデータをユーザーが見て、それがほとんど役に立たないと不満を言う場合、それは主キーが適切に設計されていることを証明します。
2. 結合およびフィルタ操作の効率を向上させるために、主キーは単一列である必要があります。
注: 複合キーを使用する人は通常 2 つの理由を言い訳しますが、どちらも間違っています。 1 つは、主キーに実際の意味がある必要があるということですが、主キーを意味のあるものにすることは、データベースを人為的に破壊するための便宜を提供するだけです。 2 つ目は、この方法を使用して、多対多の関係を記述する結合テーブルで 2 つの外部キーを主キーとして使用できることです。次の理由から、私もこのアプローチには反対です。複合主キーは不正な外部キーを引き起こすことがよくあります。つまり、テーブルを結合する場合、上記の 2 番目の方法に従って、別のスレーブ テーブルのマスター テーブルになり、このテーブルの主キーの一部になります。ただし、このテーブルは、他のスレーブ テーブルのマスター テーブルおよびその主キーになる可能性があります。この方法で渡された場合、他のスレーブ テーブルのマスター テーブルになる可能性があり、スレーブ テーブルに含まれる列の数が増えます。
3. 主キーは決して更新しないでください。実際、主キーには行を一意に識別する以外の目的がないため、更新する理由はありません。主キーを更新する必要がある場合、主キーはユーザーにとって無意味であるべきであるという原則に違反します。
注: この原則は、データ変換または複数のデータベースの結合中に整理する必要があることが多いデータには適用されません。
4. 主キーには、タイムスタンプ、作成時刻列、変更時刻列など、動的に変化するデータを含めないでください。
5. 主キーはコンピュータによって自動的に生成される必要があります。主キーの作成に人間が介入すると、行を一意に識別する以外の意味を持つことになります。この境界を超えると、主キーを変更する動機が生じる可能性があり、このシステムがレコードの行をリンクして管理するために使用する主要な手段が、データベース設計を理解していない人々の手に渡ってしまう可能性があります。
外部キーとはデータベースレベルでの整合性制約であり、データベース基礎理論の本で述べられている「参照整合性」のデータベース実装方法です。
もちろん、この制約を使用したくない場合は外部キー属性を削除できますが、プログラミングに影響はありませんが、データを入力するときに、入力されたデータに対して「参照整合性」チェックが実行されません。 。
たとえば、テーブルが 2 つあるとします。
A(a,b): a は主キー、b は外部キー (Bb から)
B(b,c,d): b は主キーです
フィールド b の外部キー属性を削除しても、プログラミングには影響しません。
上記のように、A の b は空であるか、B の b に存在する値です。外部キーがある場合、データベースは A の b が B の b に存在するかどうかを自動的にチェックします。
1. 外部式は参照整合性を表します。これはデータに固有のものであり、プログラムとは関係ありません。したがって、DBMS に任せる必要があります。
2. 外部データベースの使用はシンプルで直感的であり、データ モデルに直接反映できます。特に既存のデータベースを分析する場合、その利点は非常に明白です。かなり前に、既存のエンタープライズ データベースを見つけました。その中の参照整合性制約の一部は外部キーによって記述されており、一部はトリガーを使用して実装されています。もちろん、ドキュメントに含まれていても完全ではない可能性がありますが、外部キーは非常に明白で直感的です。
3. トリガーまたはプログラムを使用してこの作業 (参照整合性制約を参照) を完了できるため、DBMS がその手段を提供しているのに、なぜ自分で行う必要があるのでしょうか?そして、私たちがやっていることは RDBMS ほど優れたものではないと言わなければなりません。実際、初期の RDBMS には外部キーがありませんでしたが、現在ではすべての RDBMS が外部キーを備えているため、データベース ベンダーがこの機能を追加するのは理にかなっていると思います。この観点からすると、外部キーの方が便利です。
4. 利便性に関しては、私が主導したプロジェクトに基づいて、プログラマはデバッグ中にデータを入力するのが主に面倒であると報告しました。データが参照整合性に違反する可能性がある場合、現時点では、参照整合性自体はレピュテーション ビジネスと矛盾しません。トリガー先物プログラムは使用しないでください。そうでない場合は、データが間違っているため、データベースにまったく入力しないでください。さらに、不正なデータをブロックすることもテスト システムの一部である必要があります。実際、フロントエンド プログラムはこの送信失敗を処理する必要があります。データはプログラムではなく企業に属し、保存されたプログラムはできる限りデータから分離する必要があります。また、その逆も同様です。
最後に、キーを構築するためのいくつかの原則について説明します。
1. 関連フィールドの外部キーを作成します。
2. すべてのキーは一意である必要があります。
3. 複合キーの使用は避けてください。
4. 外部キーは常に一意のキー フィールドに関連付けられます。
この記事は CSDN ブログからのものです。転載する場合は出典を明記してください: http://blog.csdn.net/c04s31602/archive/2009/12/30/5107568.aspx