Mysql アドバンス - データベース設計仕様 (1)

データベース設計仕様

1. データベース設計が必要な理由

データベース設計とは、データを効率的に整理して管理することです。これは、適切に構造化された、効率的で信頼性の高いデータベースシステムを作成するための重要なステップです。データベース設計が必要な理由は次のとおりです。

データの編成: データベースの設計は、データを簡単に保存、アクセス、管理できるように、特定の構造に従ってデータを編成するのに役立ちます。これにより、データの可用性と信頼性が向上します。
データの一貫性: データベース設計を通じて、データ間の関係と制約を定義し、データの一貫性を確保できます。これにより、データの冗長性とエラーが軽減され、データの精度が向上します。
データセキュリティ: データベース設計では、不正アクセス、損傷、損失からデータを保護するためのアクセス制御、暗号化、バックアップ対策などのデータセキュリティを考慮できます。
データパフォーマンス: 優れたデータベース設計により、データクエリと処理のパフォーマンスが向上します。テーブル構造、インデックス、クエリステートメントを適切に設計することで、データの取得と処理を高速化できます。
データのスケーラビリティ: データベースの設計では、将来のニーズとスケーラビリティを考慮する必要があります。テーブルの構造と関係を適切に設計することで、データベース全体を再構築することなく、新しい関数やデータを簡単に追加できます。

要約すると、データベース設計とは、データの構成、一貫性、セキュリティ、パフォーマンス、およびスケーラビリティを向上させることです。これは、効率的で信頼性の高いデータベースシステムを構築する上で重要なステップです。

2. パラダイム

2.1 パラダイムの概要

リレーショナルデータベースでは、データテーブル設計の基本原則と規則はパラダイムと呼ばれます。

これは、データテーブルの設計構造が満たす必要がある、特定の設計標準のレベルとして理解できます。合理的に構造化されたリレーショナルデータベースを設計するには、特定のパラダイムを満たす必要があります。

2.2 パラダイムには何が含まれますか?

現在、リレーショナルデータベースには 6 つの一般的なパラダイムがあり、パラダイムレベルに応じて、低いものから高いものの順に、第 1 正規形 (1NF)、第 2 正規形 (2NF)、第 3 正規形 (3NF)、バスコード正規形となります。形式 (BCNF) )、第 4 正規形 (4NF)、および第 5 正規形 (5NF、完全正規形とも呼ばれます)。

2.3 キーと関連する属性の概念

ここには 2 つのテーブルがあります。

選手表（選手）：選手番号 | 名前 | ID番号 | 年齢 | チーム番号

チームテーブル (チーム): チーム番号 | ヘッドコーチ | チームの所在地

スーパーキー: プレーヤーテーブルの場合、スーパーキーは、(プレーヤー番号) (プレーヤー番号、名前) (ID 番号、年齢) など、プレーヤー番号または ID 番号の任意の組み合わせです。
候補キー：最小のスーパーキーで、選手テーブルの場合は（選手番号）または（IDカード番号）が候補キーとなります。
主キー: 自分で選択します。つまり、(プレイヤー番号) などの候補キーから 1 つを選択します。
外部キー: プレーヤーテーブルのチーム番号
主属性と非主属性：選手テーブルにおいて、主属性は（選手番号）（IDカード番号）であり、その他の属性（名前）（年齢）（チーム番号）は非主属性である。

2.4 第 1 正規形 (1 次 NF)

MySQL には第一正規形 (1NF) という明示的な概念がありません。1NF はリレーショナルデータベースの基本原則であり、MySQL を含むすべてのリレーショナルデータベースシステムに適用されるからです。

第一正規形は、データベース内のすべての列がアトミックである、つまり細分化できないことを意味します。具体的には、各列には複数の値や重複した値ではなく、1 つの値のみを含める必要があります。これにより、データの一貫性と正確性が保証されます。

MySQL では、次の側面を通じて第 1 正規形の要件を満たすことができます。

各テーブルには、各レコードを一意に識別する主キーが必要です。
各列には 1 つの値のみを含める必要があり、複数の値や重複した値を格納しないでください。複数の値を保存する必要がある場合は、複数のテーブルとリレーションシップを使用してそれらを表すことを検討してください。
重複する列の使用を避け、重複するデータがある場合は、それを別のテーブルに分割することを検討してください。

2.5 第 2 正規形 (第 2 NF)

MySQL では、次の側面を通じて第 2 正規形の要件を満たすことができます。

各テーブルに主キーがあり、主キーが一意の識別子であることを確認してください。
非主キー列と主キーの間に直接の関係を確立します。つまり、各非主キー列は主キーに完全に依存します。非主キー列と主キーの間に部分的な依存関係がある場合、これらの列を独立したテーブルに分割して、各非主キー列が主キーと直接の関係を持つようにすることができます。
冗長なデータをテーブルに保存しないようにします。重複データがある場合は、独立したテーブルに分割し、リレーションシップを通じてメインテーブルにリンクできます。

2.6 第 3 正規形 (3 次 NF)

3NF 準拠後のデータモデル平たく言えば、2NF と 3NF は通常、「すべての非キー属性はキーに依存し、キー全体に依存し、キー以外には何も存在しない」という文で要約されます。

3. 非正規化

3.1 概要

正規化とパフォーマンス

特定のビジネス目標を達成するには、データベースの正規化よりもデータベースのパフォーマンスが重要です。

データの正規化中は、データベースのパフォーマンスを総合的に考慮する必要があります。

フィールドを追加することで、特定のテーブルから情報を検索するのに必要な時間を大幅に短縮します。

クエリを容易にするために、指定されたテーブルに計算列を挿入します。

MySQL では、非正規化はデータベースクエリのパフォーマンスを向上させるために使用される最適化手法です。これは正規化の原則に違反し、冗長データの追加やテーブルの結合によってデータベースクエリの複雑さを軽減し、クエリのパフォーマンスを向上させます。

非正規化は次の状況で使用できます。

複雑な結合操作を頻繁に実行する: データベース内のクエリで複数のテーブル間の結合操作が頻繁に必要になり、これらの結合操作がパフォーマンスの低下を引き起こす場合は、非正規化を検討して結合操作を減らし、クエリのパフォーマンスを向上させることができます。
頻繁な集計操作: データベース内のクエリで集計操作 (SUM、AVG、COUNT など) が頻繁に必要で、これらの操作で大量のデータが計算される場合は、非正規化によって集計結果を事前に計算して保存することを検討できます。クエリのパフォーマンスを向上させます。
書き込み操作よりも読み取り操作の方がはるかに多い: データベース内のデータが主に読み取り操作に使用され、書き込み操作が少ない場合は、読み取り操作のパフォーマンスを向上させるために非正規化を検討してください。関連するデータを 1 つのテーブルにマージすることで、頻繁な結合やクエリ操作を回避できます。

非正規化により冗長データが存在し、データ更新の複雑さとリスクが増大する可能性があることに注意してください。したがって、非正規化を使用する場合は、クエリのパフォーマンスとデータの一貫性の間の関係を比較検討し、データの整合性と精度が確実に維持されるようにする必要があります。

要約すると、非正規化は、特定の状況下でクエリのパフォーマンスを向上させるために使用される手法です。非正規化を使用する場合は慎重に検討する必要があり、クエリのパフォーマンスとデータの一貫性のニーズのバランスを取るようにしてください。

冗長な情報が貴重な場合、またはクエリ効率を大幅に向上させることができる場合は、アンチパラダイム最適化を採用します。

5. 第 4 のパラダイム

リレーショナルデータベースでは、第 4 正規形 (4NF) が、自明ではない多値の依存関係を排除するために使用されるさらなる正規化原理です。ただし、MySQL には、リレーショナルデータベースとして、第 4 のパラダイムを含む正規化の原則に従っているため、第 4 のパラダイムの明示的な概念はありません。

第 4 正規形では、第 3 正規形を満たすことに基づいて、自明ではない多値の依存関係を削除する必要があります。自明ではない多値依存関係とは、テーブルの非主キー列がテーブルの候補キー全体ではなく候補キーの一部に依存する場合、自明ではない多値依存関係が存在することを意味します。

テーブルを 2 つ以上のテーブルに分解し、関連付け関係を通じてそれらのテーブルを接続することで、自明ではない複数値の依存関係を排除します。これにより、データの冗長性が軽減され、データの一貫性と精度が向上します。

MySQL では、第 3 正規形の要件に従うことで、自明ではない多値の依存関係を最小限に抑えることができます。部分的な候補キー間の依存関係を避けるために、主キー以外の各列が主キーに直接依存していることを確認してください。

要約すると、第 4 正規形はリレーショナルデータベースのさらなる正規化原理であり、自明ではない多値の依存関係を排除するために使用されます。MySQL では、第 3 正規形の要件に従うことで、第 4 正規形の要件を最大限に活用し、データの一貫性と精度を向上させることができます。

例 1: 従業員テーブル (従業員番号、従業員の子供の名前、従業員の選択コース)。

このテーブルでは、同じ従業員が複数の従業員の子の名前を持つ場合があります。同様に、同じ従業員が複数の従業員選択コースを受講することもできます。つまり、ここには多値の事実があり、これは 4 番目のパラダイムに準拠しません。

第 4 正規形に準拠する場合は、上記のテーブルを 2 つのテーブルに分割して、多値ファクトを 1 つだけ持つようにするだけです。たとえば、従業員テーブル 1 (従業員番号、従業員の子供の名前)、従業員テーブル2 (従業員番号、従業員選択コース) の場合、両方のテーブルには多値ファクトが 1 つだけあるため、第 4 正規形に準拠します。

6. 第 5 正規形、ドメインキー正規形

第 4 正規形に加えて、より高度な第 5 正規形 (完全正規形とも呼ばれる) とドメインキー正規形 (DKNF) もあります。
第４正規形（４ＮＦ）を満たすことに基づいて、候補キーに含まれない接続依存性が除去される。リレーショナルスキーマ R 内のすべての接続依存関係が R の候補キーによって暗示される場合、リレーショナルスキーマは第 5 正規形に準拠していると言われます。

関数の依存関係は複数値の依存関係の特殊なケースであり、複数値の依存関係は実際には接続の依存関係の特殊なケースです。ただし、セマンティクスから直接派生できる関数依存関係や多値依存関係とは異なり、結合依存関係はリレーショナル結合操作に反映されます。接続依存関係のあるリレーショナルモデルでも、データの冗長性や挿入、変更、削除の例外などの問題が発生する可能性があります。

5 番目のパラダイムは、ロスレス接続の問題を扱います。ロスレス接続はめったに発生せず、検出が難しいため、このパラダイムは基本的に無意味です。ドメインキーパラダイムは、あらゆる種類の依存関係と制約を考慮した究極のパラダイムを定義しようとしますが、実際的な価値は最小限であり、理論的研究にのみ存在します。