MySQLパラダイムの使用に関する詳細な説明

MySQLパラダイムの使用に関する詳細な説明

1. パラダイム

このパラダイムの英語名は Normal Form であり、1970 年代にリレーショナル データベース モデルを提案した英国の EF Codd (リレーショナル データベースの祖先) によって要約されました。パラダイムはリレーショナル データベース理論の基礎であり、データベース構造を設計するプロセスで従わなければならない規則とガイドラインでもあります。現在、1NF、2NF、3NF、BCNF、4NF、5NF、DKNF、6NF の 8 つのパラダイムが存在します。通常、最初の 3 つのパラダイム、つまり、最初のパラダイム (1NF)、2 番目のパラダイム (2NF)、3 番目のパラダイム (3NF) のみが使用されます。

第一正規形 (1NF)

最初の正規形は実際にはリレーショナル データベースの基礎であり、つまり、すべてのリレーショナル データベースは最初の正規形に準拠しています。簡単に言えば、第 1 正規形とは、各行のデータが分離不可能であり、同じ列に複数の値が存在することはできず、重複する属性がある場合は新しいエンティティを定義する必要があることを意味します。
次のデータベースは第 1 正規形に準拠していません。

+------------+-------------------+
| 従業員名 | 会社 |
+------------+-------------------+
| ジョン | ByteDance、Tencent |
| マイク | テンセント |
+------------+-------------------+

上記のデータが意味するのは、マイクはテンセントで働いており、ジョンはバイトダンスとテンセントの両方で働いているということです(これが可能であると仮定した場合)。ただし、この式は第 1 正規形に準拠していません。つまり、列内のデータは分離不可能である必要があります。第 1 正規形を満たすには、次の形式にする必要があります。

+------------+------------+
| 従業員名 | 会社 |
+------------+------------+
| マイク | テンセント |
| ジョン | バイトダンス |
| ジョン | テンセント |
+------------+------------+

第2正規形 (2NF)

まず、データベースは、第 2 正規形を満たす前に、第 1 正規形を満たす必要があります。
まずは表を見てみましょう:

+----------+-------------+--------+
| 従業員 | 部門 | 責任者 |
+----------+-------------+--------+
| ジョーンズ | 会計士 | ジョーンズ |
| スミス | エンジニアリング | スミス |
| ブラウン | 会計 | ジョーンズ |
| グリーン | エンジニアリング | スミス |
+----------+-------------+--------+

この表は、従業員、作業部門、リーダーの関係を示しています。この表で表される関係は、現実世界ではまったくあり得ます。では、ブラウンが経理部門のリーダーに就任した場合、この表をどのように変更する必要があるかという質問を考えてみましょう。この問題は非常に厄介になります。なぜなら、データが結合されており、UPDATE ステートメントを実行するために各行を一意に決定できる適切な判断条件を見つけることが困難だからです。データベース内のテーブルの行を一意に表すことができるデータを、このテーブルの主キーにします。 したがって、主キーのないテーブルは 2 番目のパラダイムに準拠していません。つまり、2 番目のパラダイムに準拠するテーブルでは、主キーを指定する必要があります。

したがって、上記の表を第 2 正規形に準拠させるには、2 つの表に分割する必要があります。

+----------+--------------+
| 従業員 | 部門 |
+----------+--------------+
| ブラウン | 会計 |
| グリーン | エンジニアリング |
| ジョーンズ | 会計 |
| スミス | エンジニアリング |
+----------+--------------+

+-------------+--------+
| 部門 | 責任者 |
+-------------+--------+
| 会計 | ジョーンズ |
| エンジニアリング | スミス |
+-------------+--------+

これら 2 つのテーブルでは、最初のテーブルの主キーは従業員であり、2 番目のテーブルの主キーは部門です。この場合、上記の問題を完了するのは非常に簡単です。

第3正規形 (3NF)

リレーショナル データベースは、第 3 正規形を満たす前に、第 2 正規形を満たす必要があります。
3 番目の正規形の前に、次の 2 つの表も見てみましょう。

+-----------+-------------+---------+--------+
| 学生ID | 学生名 | 科目 | スコア |
+-----------+-------------+---------+--------+
| 1 | マイク | 数学 | 96 |
| 2 | ジョン | 中国語 | 85 |
| 3 | ケイト | 歴史 | 100 |
+-----------+-------------+---------+--------+

+-----------+-----------+--------+
| 科目ID | 学生ID | スコア |
+-----------+-----------+--------+
| 101 | 1 | 96 |
| 111 | 3 | 100 |
| 201 | 2 | 85 |
+-----------+-----------+--------+

上記の 2 つのテーブルの主キーは、それぞれ studentid と subjectid です。明らかに、両方のテーブルは第 2 正規形に準拠しています。

ただし、これら 2 つのテーブルには重複した冗長なデータ スコアがあることがわかります。したがって、第 3 正規形は冗長データを排除するためのものです。具体的には、上記の状況では、2 つのテーブルのうち 1 つだけにスコア列データを含めることができます。では、これら 2 つのテーブルをどのように接続するのでしょうか? ここで外部キーが登場します。 2 つのテーブルに重複した列があり、一方のテーブルの非主キー列がもう一方のテーブルの主キーである場合、重複した列を削除するには、この非主キー列を 2 つのテーブルを接続するブリッジ、つまり外部キーとして使用できます。 観察すると、studentid は最初のテーブルでは主キーであり、2 番目のテーブルでは非主キーであることがわかります。つまり、studentid は 2 番目のテーブルの外部キーです。したがって、上記の状況では、第 3 正規形に準拠した次の記述が得られます。

+-----------+-------------+----------+
| 学生ID | 学生名 | 科目 |
+-----------+-------------+----------+
| 1 | マイク | 数学 |
| 2 | ジョン | 中国語 |
| 3 | ケイト | 歴史 |
+-----------+-------------+----------+

+-----------+-----------+--------+
| 科目ID | 学生ID | スコア |
+-----------+-----------+--------+
| 101 | 1 | 96 |
| 111 | 3 | 100 |
| 201 | 2 | 85 |
+-----------+-----------+--------+

外部キーを設定した後、最初のテーブルでスコア列が削除された場合でも、studentid を通じて 2 番目のテーブルで対応するスコア値を見つけることができることがわかります。これにより、検索に影響を与えることなくデータの冗長性が排除され、第 3 正規形が満たされます。

2. パラダイムの利点と欠点

パラダイムの利点

  • 通常、正規化された更新操作は非正規化された更新操作よりも高速です。
  • データが適切に正規化されている場合、データの重複はほとんどまたはまったくないため、変更する必要があるデータが少なくなります。
  • 正規化されたテーブルは通常、サイズが小さくなり、メモリにうまく収まるため、操作が高速になります。
  • 冗長データが少ないということは、表形式のデータを取得するときに DISTINCT または GROUP BY ステートメントの必要性が少なくなることを意味します。

パラダイムの欠点

  • 正規化の欠点は、通常は関連付けが必要になることです。少し複雑なクエリでは、正規化されたデータベース上で少なくとも 1 つの結合 (場合によってはそれ以上) が必要になることがあります。これはコストがかかるだけでなく、一部のインデックス作成戦略が無効になる可能性もあります。

MySQL パラダイムの詳細な使用法に関するこの記事はこれで終わりです。より関連性の高い MySQL パラダイムのコンテンツについては、123WORDPRESS.COM の以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません:
  • データベースの3つのパラダイムの最もシンプルで記憶に残る説明
  • MySQLデータベースパラダイムの詳細な説明
  • データベース設計の3つの主要なパラダイムの簡単な分析
  • MySQL 学習: 初心者のための 3 つのパラダイム

<<:  Vueのライフサイクルについて詳しく説明します

>>:  Tomcat と WebLogic で純粋な HTML ファイルを展開するプロセスの分析

推薦する

nginx proxy_cache バッチキャッシュクリアスクリプトの紹介

前書き: 以前、公式の nginx proxy_cache を CDN 静的キャッシュとして使用して...

MySQL における between の境界と範囲の説明

境界範囲間のmysql間の範囲は両側の境界値を含む例: 3 から 7 までの id は、id >...

Linux シェル環境での Zabbix API の使用

Linux シェル環境で直接呼び出すことができます。公式 Web サイトによると、Zabbix のデ...

一般的なテーブルコンポーネントの Vue カプセル化の完全な手順記録

目次序文テーブル コンポーネントをカプセル化する必要があるのはなぜですか?ステップ1: 共通コンポー...

JS は Web ページナビゲーションバーの特殊効果を実現します

この記事では、ネイティブ JS を使用して実装された実用的な Web ナビゲーション バー効果を紹介...

MySQL で主キーと ROWID を使用する際の落とし穴の概要

序文MySQL の rowid の概念については聞いたことがあるかもしれませんが、テストや実践が難し...

Linux環境変数の設定戦略の詳細な説明

ソフトウェアのインストールをカスタマイズする場合、多くの場合、環境変数を設定する必要があります。以下...

SQL 最適化チュートリアル: IN クエリと RANGE クエリ

序文「High Performance MySQL」では、インデックスでは範囲フィールドの後の部分が...

ReactアプリケーションにおけるDOM DIFFアルゴリズムの詳細な説明

目次序文VirtualDOM とは何ですか? VirtualDOMを使用する理由DOMレンダリングペ...

CSSをインポートする方法に関する詳細な洞察の要約

CSS の開発履歴についてはここでは紹介しません。ブログを書いている理由の 1 つは、フロントエンド...

DockerToolBox ファイルマウント実装コード

docker を使用すると、ファイルをマウントできない場合があります。これは、仮想マシンの共有フォル...

CSSオーバーフローメカニズムについての簡単な説明

CSS オーバーフローのメカニズムを詳細に学ぶ必要があるのはなぜですか?実際の開発プロセスでは、コン...

MySQL 5.7.25 圧縮版のインストールと設定方法のグラフィックチュートリアル

この記事では、MySQL 5.7.25圧縮版のインストールと設定方法を参考までに紹介します。具体的な...

CSS3に基づいてiPhoneを描く

結果:実装コードhtml <div class='iphone'> &l...