データベース設計の原則を要約する

元のドキュメントとエンティティの間の関係は、1 対 1、1 対多、または多対多の場合があります。一般に、これらは 1 対 1 の関係です。つまり、1 つの元の文書は 1 つのエンティティのみに対応します。 特殊な場合には、1 対多または多対 1 の関係になる場合があります。つまり、1 つの元のドキュメントが複数のエンティティに対応するか、複数の元のドキュメントが 1 つのエンティティに対応します。

1. 元のドキュメントとエンティティ
の関係は、1 対 1、1 対多、または多対多の関係になります。一般に、これらは 1 対 1 の関係です。つまり、1 つの元の文書は 1 つのエンティティのみに対応します。
特殊なケースでは、1 対多または多対 1 の関係になる場合があります。つまり、1 つの元のドキュメントが複数のエンティティに対応するか、複数の元のドキュメントが 1 つのエンティティに対応します。
ここでのエンティティは基本的なテーブルとして理解できます。この対応関係を明確にしておくことは、入力インターフェースの設計に非常に役立ちます。

〖例 1〗: 従業員履歴書情報は、人事情報システムの 3 つの基本テーブル (従業員基本情報テーブル、社会関係テーブル、職務経歴書テーブル) に対応します。
これは「一つの原本が複数の実体に対応する」という典型的な例です。

2. 主キーと外部キー
一般的に、エンティティは主キーと外部キーの両方を持つことはできません。 E-R 図では、リーフ位置のエンティティには主キーが定義されていてもいなくても (子孫がないため)、外部キーが必要です (親があるため)。

主キーと外部キーの設計は、グローバルデータベースの設計において重要な役割を果たします。グローバル データベースの設計が完了した後、アメリカのデータベース設計専門家は次のように述べました。「キーはどこにでもあり、キー以外には何もありません。」情報システムの中核（データモデル）。主キーは非常に抽象的なエンティティであり、主キーと外部キーのペアはエンティティ間の接続を表すためです。


3. 基本テーブルのプロパティ

基本テーブルは、次の 4 つの特徴を持つため、中間テーブルや一時テーブルとは異なります: (1) アトミック性。ベース テーブルのフィールドは分解できません。
（２）原始性。実表のレコードは、元のデータ（基データ）のレコードである。 （３）演繹的。すべての出力データは、基本テーブルとコード テーブルのデータから派生できます。
（4）安定性。基本テーブルの構造は比較的安定しており、テーブル内のレコードは長期間保存する必要があります。
基本テーブルの性質を理解すると、データベースを設計する際に、基本テーブルと中間テーブルや一時テーブルを区別できるようになります。


4. 正規形の標準

基本テーブルとそのフィールドの関係は、第3正規形
を満たすように努めるべきです。ただし、3 番目のパラダイムを満たすデータベース設計は、多くの場合、最適な設計ではありません。 データベースの運用効率を向上させるためには、多くの場合、空間を時間と交換するという目的を達成するために冗長性を適切に高めるというパラダイム基準を下げる必要があります。 〖例2〗: 表1に示すように、商品を保管するための基本的なテーブルがあります。 「金額」フィールドの存在は、テーブルの設計が第 3 正規形を満たしていないことを示しています。「金額」は「単価」に「数量」を乗算することで取得できるため、「金額」が冗長フィールドであることを示しています。 。ただし、冗長フィールド「amount」を追加すると、時間とスペースを交換してクエリ統計の速度を向上させることができます。
Rose 2002 では、データ列と計算列の 2 種類の列があります。 「金額」などの列を「計算列」、「単価」や「数量」などの列を「データ列」と呼びます。
表1 製品表のテーブル構造
製品名 製品型番 単価 数量
TV 29インチ 2,500 40 100,000


5. 3つのパラダイムを一般的な方法で理解する

3つのパラダイムの共通理解は非常に重要ですデータベース設計にメリットをもたらします。データベース設計において、3 つのパラダイムをより適切に適用するには、一般的な方法で 3 つのパラダイムを理解する必要があります (一般的な理解は十分な理解であり、最も科学的で正確な理解ではありません):

最初のパラダイム
: 1NF は属性に対する原子性制約であり、属性が原子的であり、分解できないことが必要です。 第 2 正規形
: 2NF はレコードの一意性制約であり、レコードが一意の識別子、つまりエンティティの一意性を持つ必要があります。
第 3 正規形: 3NF はフィールドの冗長性に関する制約です。つまり、フィールドが他のフィールドから派生できないことを要求します。
冗長なデータベース設計ではこれを実現できません。ただし、冗長性のないデータベースは最適なデータベースではない場合があります。場合によっては、運用効率を向上させるために、パラダイム基準を下げて冗長データを適切に保持する必要があります。具体的なアプローチは、概念データ モデルを設計するときは 3 番目のパラダイムに従い、物理データ モデルを設計するときはパラダイム標準を下げる作業を考慮することです。通常の形式を下げるということは、フィールドを追加して冗長性を可能にすることを意味します。
6. 多対多の関係を識別し、正しく処理することに優れる
2 つのエンティティ間に多対多の関係がある場合、この関係を削除する必要があります。解決策は、2 つの間に 3 番目のエンティティを追加することです。このようにして、それが判明しました
1 つの多対多の関係は、2 つの 1 対多の関係になりました。元の 2 つのエンティティの属性は、3 つのエンティティに合理的に割り当てられる必要があります。ここでの 3 番目のエンティティは本質的にはより複雑なリレーションシップであり、基本的なテーブルに対応します。一般に、データベース設計ツールは多対多の関係を認識できませんが、多対多の関係は処理できます。

〖例３〗：「図書館情報システム」では、「本」も実体であり、「読者」も実体である。これら 2 つのエンティティ間の関係は、典型的な多対多の関係です。つまり、1 つの本を複数の読者が異なる時間に借りることができ、1 人の読者が複数の本を借りることができます。このために、この 2 つのエンティティの間に 3 番目のエンティティを追加する必要があります。このエンティティは「本の貸し出しと返却」という名前で、その属性は次のとおりです: 貸し出しと返却の時間、貸し出しと返却のフラグ (0 は本の貸し出しを意味し、1 は本の返却を意味します)。 book) , さらに、
「Book」と「Reader」に接続できるように、2 つの外部キー (「Book」の主キーと「Reader」の主キー) も必要です。


7. 主キーPKのvalueメソッド

PKはプログラマ向けのテーブル間接続ツールで、プログラムが自動的に1を加算することで実装される、物理的な意味を持たないデジタル文字列にすることができます。物理的な意味を持つフィールド名またはフィールド名の組み合わせを使用することもできます。しかし、前者の方が後者よりも優れています。 PK がフィールド名の組み合わせである場合、フィールドを多すぎないことをお勧めします。フィールドが多すぎると、インデックスが多くのスペースを占有するだけでなく、速度も低下します。

8. データの冗長性を正しく理解する
複数のテーブルで主キーと外部キーが繰り返し出現することは、データの冗長性ではないということ、実はこの概念はまだ明確ではないはずです。非キー フィールドが繰り返し発生するのはデータの冗長性です。これは、一種の低レベルの冗長性、つまり反復冗長性です。高レベルの冗長性は、フィールドの繰り返しの出現ではなく、フィールドの派生的な出現です。

〖例4〗：商品には「単価、数量、金額」の3つのフィールドがあり、「金額」は「単価」×「数量」で求められます、
となります。一種の高度な冗長性が残ります。冗長性の目的は、処理速度を向上させることです。同じデータが異なる時間、場所、役割から複数回入力される可能性があるため、低レベルの冗長性のみがデータの不整合を増大させます。したがって、私たちは高レベルの冗長性 (派生的冗長性) を支持し、低レベルの冗長性 (反復的冗長性) に反対します。
9. E--R図には標準的な答えはありません
情報システムのE--R図には、設計や描画方法が独特ではないため、標準的な答えはありません。システム要件の業務範囲と機能内容を網羅しており、
実現可能です。それ以外の場合は、E--R ダイアグラムを変更します。単一の標準的な答えはありませんが、自由に設計できるという意味ではありません。優れた E-R 図の基準は、
明確な構造、簡潔な関連付け、適度な数のエンティティ、合理的な属性割り当て、低レベルの冗長性がないことです。


10. ビューテクノロジーはデータベース設計に非常に役立ちます
基本テーブル、コードテーブル、中間テーブルとは異なり、ビューはデータソースの実際のテーブルの存在に依存する仮想テーブルです。ビューは、プログラマがデータベースを使用するためのウィンドウであり、ベース テーブル データ合成の形式であり、データ処理方法であり、ユーザー データの機密性を保つ手段です。複雑な処理を実行し、計算速度を向上させ、ストレージ領域を節約するには、通常、ビューの定義の深さは 3 レベルを超えてはなりません。 3 層ビューでもまだ不十分な場合は、ビュー上に一時テーブルを定義し、その一時テーブル上にビューを定義する必要があります。このように定義を繰り返し重ねることで、ビューの深さが制限されなくなります。
国の政治的、経済的、技術的、軍事的、安全保障上の利益に関連する特定の情報システムでは、ビューの役割はさらに重要です。これらのシステムの基本テーブルの物理設計が完了すると、このビュー層の数と構造は基本テーブルの数と構造とまったく同じになります。
そして、すべてのプログラマーはビューに対してのみ操作できると規定されています。基本テーブルを直接操作できるのは、複数人で共有する「セキュリティキー」を持つデータベース管理者だけです。読者は次のように考えてください。なぜそうなるのか?


11. 中間テーブル、レポート、および一時テーブル
中間テーブルは、データウェアハウス、出力レポート、またはクエリ結果を格納するテーブルです。倉庫 除く）。一時テーブルは、個人使用のために一時的なレコードを保存するためにプログラマによって設計されています。基本テーブルと中間テーブルは DBA によって保守され、一時テーブルはプログラマが独自のプログラムを使用して自動的に保守されます。


12. 整合性制約は 3 つの側面で表現されます

ドメイン整合性: 制約を実装するためにチェックを使用します。データベース設計ツールでは、フィールドの値の範囲を定義するときに、
を介して値を定義します。フィールドの。
参照整合性: PK、FK、およびテーブルレベルのトリガーを使用して実装されます。
ユーザー定義の整合性: ストアド プロシージャとトリガーを使用して実装される一部のビジネス ルールです。

13. データベース設計のパッチ適用を防ぐ方法は「3 つの少ない原則」です (1) データベース内のテーブルの数は少ないほど良いです。テーブルの数が減った場合にのみ、システムの E-R 図が小さくて正確であり、繰り返して冗長なエンティティが削除され、客観的な世界の高度な抽象化が形成され、パッチ適用を防ぐために体系的なデータ統合が実行されていることを示すことができます。 (2) テーブル内の結合された主キー フィールドの数は少ないほど良いです。主キーの役割により、1 つは主キー インデックスの構築、もう 1 つはサブテーブルの外部キーとして機能するため、主キーを結合するフィールドの数が減ります。実行時間を節約しますが、インデックスの保存スペースも節約します
(3) テーブル内のフィールドは少ないほど良いです。フィールドの数が減った場合にのみ、システム内にデータの重複がなく、冗長なデータがほとんど存在しないことを意味します。さらに重要なのは、読者が「列を行に変更する」方法を学習する必要があり、その結果、フィールドが減少するのを防ぐことができます。サブテーブルが変更されないようにするため、メイン テーブルに多くの空のフィールドを残しておきます。いわゆる「列から行」とは、メインテーブルの内容の一部を取り出して、別のサブテーブルを作成することです。この方法は非常に簡単ですが、慣れていない、採用しない、実行しない人もいます。
データベース設計の実際的な原則は、データの冗長性と処理速度の適切なバランスを見つけることです。 「三人の若き巨匠」は全体的な概念、包括的な視点であり、1 つの原則を分離することはできません。この原則は相対的なものであり、絶対的なものではありません。 「あと3回」という原則は明らかに間違っています。想像してみてください。システムの同じ機能がカバーされている場合、100 個のエンティティ (合計 1,000 個の属性) の E-R 図は、200 個のエンティティ (合計 2,000 個の属性) の E-R 図よりも確実に優れています。もっと。
「Three Less」原則の提唱は、体系的なデータ統合のためのデータベース設計技術の使い方を読者に教えることです。データ統合の手順は、ファイル システムをアプリケーション データベースに統合し、アプリケーション データベースをサブジェクト データベースに統合し、サブジェクト データベースをグローバル包括データベースに統合することです。統合の度合いが高くなるほど、データの共有が強化され、情報アイランドが少なくなり、企業情報システム全体のグローバル E-R 図におけるエンティティの数、主キーの数、および属性の数が増加します。少し。
「Three Less」原則を提唱する目的は、読者がパッチ技術を使用してデータベースを継続的に追加、削除、変更し、エンタープライズ データベースをデータベース テーブルのランダム設計の「ゴミ山」、つまり「データベーステーブルの「雑多な中庭」が発生し、最終的にはデータベース内の基本テーブル、コードテーブル、中間テーブル、一時テーブルが無数に乱雑になり、企業や機関の情報システムが維持できなくなり、麻痺してしまいました。
「パッチ手法」を用いたデータベース設計の倒錯理論である「Three More」原則は誰でもできます。 「Three Less」原則は、「パッチ手法」の使用を排除するため、高度なデータベース設計スキルと芸術を必要とする原則です。に従って。


14. データベースの運用効率を改善する方法

与えられたシステムハードウェアとシステムソフトウェアの条件の下で、データベースシステムの運用効率を改善する方法は次のとおりです。
(1) データベースの物理設計において、パラダイムを減らし、冗長性を高めます。さらに、使用するトリガーを減らし、ストアド プロシージャを増やします。
(2) 計算が非常に複雑で、レコード数が非常に多い場合 (たとえば、1,000 万レコード)、複雑な計算は、まずファイル システム内の C++ 言語を使用してデータベースの外部で計算および処理され、その後で実行される必要があります。最終的にデータベースに保存されます。通信料金システム設計の経験です。
(3) あるテーブルのレコード数が多すぎる、例えば1000万件を超えていることが判明した場合は、テーブルを水平に分割する必要があります。水平分割の方法は、テーブルの主キー PK の一定の値を境界として、テーブルのレコードを 2 つのテーブルに水平分割します。テーブルにフィールドが多すぎる (たとえば、80 を超える) ことが判明した場合は、テーブルを垂直に分割し、元のテーブルを 2 つのテーブルに分解します。
（4）データベース管理システムDBMSのシステム最適化、つまりバッファ数などの各種システムパラメータの最適化。
(5) プログラミングにデータ指向 SQL 言語を使用する場合は、最適化アルゴリズムを採用するようにしてください。
つまり、データベースの運用効率を向上させるには、データベースシステムレベルの最適化、データベース設計レベルの最適化、プログラム実装レベルの最適化の3つのレベルからの取り組みを同時に行う必要があります。

上記の14のスキルは、数多くのデータベース分析や設計実践を通じて、多くの人によって徐々にまとめられてきました。これらの経験の応用については、読者は機械的に丸暗記するのではなく、咀嚼して理解し、事実から真実を探り、柔軟に捉える必要がある。そして徐々に、アプリケーションで開発し、開発で適用することを達成します。


他の原則を見てみましょう:

1) データベース設計はシステム全体ではなく、システムアーキテクチャのコンポーネント分割に基づいて行う必要があり、コンポーネント単位のデータベース設計は、各コンポーネントが処理する業務の相関関係に基づいて行う必要があります。異なるコンポーネント間の対応するデータベース テーブルは、可能な限り最小限に抑える必要があります。異なるコンポーネント間のテーブルに外部キーの関連付けが必要な場合は、外部キーの関連付けを作成せず、関連付けられたテーブルの主キーのみを記録して、コンポーネント間の独立性を確保してください。コンポーネントに対応するテーブルを作成し、システムまたはテーブル構造の再構築を容易にします。

2) データベース設計にドメイン モデル駆動のアプローチとトップダウン アプローチを採用し、まずシステム ビジネスを分析し、責任に従ってオブジェクトを定義します。オブジェクトはカプセル化の特性に準拠し、責任に関連するデータ項目がオブジェクト内で定義され、責任の記述が欠けていないことを保証する必要があります。また、オブジェクトが 2 つ以上の責任を負う場合は、分割する必要があります。

3) 確立されたドメイン モデルに従ってデータベース テーブルをマップします。このとき、データベース設計の 2 番目のパラダイムを参照する必要があります。つまり、テーブル内のすべての非キーワード属性はキーワード全体に依存します。キーワードは、属性または複数の属性のコレクションにすることができます。いずれの場合も、キーワードは一意であることが保証される必要があります。キーワードを決定するときは、キーワードがビジネスに関与せず、更新例外が発生しないことを確認する必要があります。この場合、最適な解決策は、キーワードとして自動インクリメント数値属性またはランダムな文字列を使用することです。テーブル。

4) 最初のポイントで述べたように、データベースのテーブル構造はドメイン モデル駆動の方法で設計されているため、ドメイン モデル内の各オブジェクトは 1 つの責任しか持たず、オブジェクト内のデータ項目には推移的な依存関係がありません。 、このアイデア データベースのテーブル構造設計は、最初から第 3 正規形を満たす必要があります。テーブルは第 2 正規形を満たす必要があり、属性間に推移的な依存関係があってはなりません。

5) 同様に、オブジェクトの責任の統一とオブジェクト間の関係がビジネス ロジック間の関係を反映するため、ドメイン モデル内のオブジェクトはマスター オブジェクトとスレーブ オブジェクトに分割されます。スレーブ オブジェクトは 1 ～ N または です。 N-N パースペクティブはメイン オブジェクトのビジネス ロジックを強化するため、オブジェクトとオブジェクトの関係からマップされたテーブルとテーブルの関連付けからの削除と挿入の例外はありません。

6) マッピング後に得られたデータベース テーブル構造は、複数値の依存関係がないことを確認するために、第 4 正規形に従ってさらに変更する必要があります。このとき、リバースエンジニアリングの考え方に基づいてドメインモデルにフィードバックを与える必要があります。テーブル構造に複数の値の依存関係がある場合、ドメイン モデル内のオブジェクトには少なくとも 2 つ以上の責任があることが証明されており、最初の記事に従って設計を修正する必要があります。第 4 正規形: テーブルが BCNF を満たす場合、複数値の依存関係は存在しないはずです。

7) 分析後、すべてのテーブルが第 2、第 3、および第 4 正規形を満たすことが確認され、テーブル フィールドとテーブル構造の調整と再構築を容易にするために、テーブル間の関連性は可能な限り弱くする必要があります。さらに、データベース内のテーブルは、特定の時間および特定の条件下でオブジェクト インスタンスの状態を保持するために使用されると思います。したがって、ビジネスを表現するためにテーブル間に強い関連付けがあるべきではありません。データ間の一貫性）、この責任はシステムの論理層によって保証される必要があります。このアプローチにより、不正なデータ（ダーティ データ）とのシステムの互換性も保証されます。もちろん、システム全体の観点から言えば、ダーティデータが発生しないように最大限の努力をしなければなりません。別の観点から言えば、ダーティデータの発生はある程度避けられません。システムがこの状況に対するフォールト トレランスを生成しないこと。これは妥協です。

8) 検索効率を向上させるために、すべてのテーブルの主キーと外部キーにインデックスを確立する必要があり、結合された属性のインデックスをターゲットを絞った方法で (一部の大量のデータと一般的な取得方法に対して) 確立する必要があります。インデックスの構築にはシステム リソースがある程度消費されますが、特にテーブル内のデータ量が多い場合の、取得中にテーブル全体のデータを検索するパフォーマンスへの影響は、インデックスがない場合の並べ替え操作のパフォーマンスへの影響と比較されます。 、このアプローチは依然として提唱する価値があります。

9) ストアド プロシージャの使用はできるだけ少なくする 現在、バージョンに関係なく、データベース内のデータの一貫性を確保するために、「オブジェクト/リレーショナル マッピング」など、ストアド プロシージャの機能を置き換えることができるテクノロジが多数あります。管理、開発、展開、そしてデータベースの移行は大きな影響を及ぼします。ただし、ストアド プロシージャがパフォーマンス上の利点があることは否定できません。そのため、システムで使用できるハードウェアが改善されず、パフォーマンスが非常に重要な品質特性である場合は、バランスのとれた考慮事項を通じてストアド プロシージャを選択できます。

10) テーブル間の関連付け制約を処理するコスト (多くの場合、使いやすさのコスト) が、変更、削除、変更例外が発生しないことを保証するコストを超えており、データの冗長性が大きな問題ではない場合、現時点では、テーブルの設計は 4 つの正規形に準拠する必要はありません。 4 つのパラダイムは例外が発生しないようにするものですが、純粋になりすぎてテーブル構造が使いにくくなる可能性があるため、設計時には総合的な判断が必要ですが、まず 4 つのパラダイムに準拠していることを確認し、これは、データベース設計の分野に参入したばかりの場合に実行できる最良のアプローチです。

11) 設計されたテーブルは優れた使いやすさを備えていなければなりません。これは主に、複数のテーブルを関連付ける必要があるかどうか、クエリ中に複雑な SQL スキルを使用する必要があるかどうかに反映されます。

12) データの正確性を確保するために、設計されたテーブルではデータの冗長性を可能な限り削減する必要があり、冗長性を効果的に制御することでデータベースのパフォーマンスを向上させることができます。 (もちろん、パラダイムを下げる必要がある場合もあります)

【関連する推奨事項】

1. 特別な推奨事項: 「php Programmer Toolbox」V0.1 バージョンのダウンロード

2. 無料の mysql オンライン ビデオ チュートリアル

3. データベース設計について

以上がデータベース設計の原則を要約するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。