データベースの正規化

データベースの正規化とは、データの冗長性を削減し、データの整合性を向上させるために、いわゆる正規形と呼ばれる一連の形式に従ってリレーショナルデータベースを構造化するプロセスです。これは、イギリスのコンピュータ科学者エドガー・F・コッドが、彼のリレーショナルモデルの一部として初めて提案しました。

正規化とは、データベースの列（属性）とテーブル（リレーション）を整理し、それらの依存関係がデータベース整合性制約によって適切に適用されるようにすることです。これは、統合（新しいデータベース設計の作成）または分解（既存のデータベース設計の改善）というプロセスを通じて、いくつかの正式な規則を適用することで実現されます。

目的

1970年にコッドが定義した第一正規形の基本的な目的は、一階述語論理に基づく「普遍的なデータサブ言語」を用いてデータの問い合わせや操作を可能にすることであった。[1]そのような言語の例としてSQLがあるが、コッドはSQLに重大な欠陥があるとみなしていた。[2]

1NF (第 1 正規形) を超える正規化の目的は、Codd によって次のように述べられました。

  1. 関係のコレクションを、望ましくない挿入、更新、削除の依存関係から解放します。
  2. 新しいタイプのデータが導入されたときに、関係のコレクションを再構築する必要性を減らし、アプリケーション プログラムの寿命を延ばします。
  3. リレーショナル モデルをユーザーにとってより有益なものにします。
  4. クエリ統計に対して中立な関係のコレクションを作成します。これらの統計は時間の経過とともに変化する可能性があります。

— EF Codd、「データベースリレーショナルモデルのさらなる正規化」[3]

挿入異常。新任教員のニューサム博士が少なくとも1つのコースを担当するよう任命されるまで、その詳細は記録できません。
更新の異常。従業員 519 は、異なるレコードで異なる住所として表示されます。
削除の異常。ギデンス博士が一時的にどのコースにも割り当てられなくなると、ギデンス博士に関するすべての情報が失われます。

リレーションを変更 (更新、挿入、または削除) しようとすると、十分に正規化されていないリレーションでは次のような望ましくない副作用が発生する可能性があります。

挿入異常
状況によっては、特定の事実を全く記録できない場合があります。例えば、「教員とそのコース」リレーションの各レコードには、教員ID、教員名、教員採用日、コースコードが含まれている場合があります。そのため、少なくとも1つのコースを担当する教員の詳細は記録できますが、まだコースを担当する教員が割り当てられていない新規採用教員は、コースコードをnullに設定しない限り記録できません。
更新異常
同じ情報が複数の行に記述される可能性があるため、リレーションを更新すると論理的な矛盾が生じる可能性があります。例えば、「従業員のスキル」リレーションの各レコードには、従業員ID、従業員の住所、スキルが含まれる場合があります。そのため、特定の従業員の住所変更は、複数のレコード（スキルごとに1つ）に適用する必要がある場合があります。更新が部分的にしか成功しない場合（一部のレコードでは従業員の住所が更新され、他のレコードでは更新されない場合）、リレーションは矛盾した状態になります。具体的には、このリレーションでは、この特定の従業員の住所が何であるかという質問に対して矛盾した回答が提示されます。
削除異常
状況によっては、特定の事実を表すデータを削除すると、全く異なる事実を表すデータも削除する必要が生じることがあります。前述の例で説明した「教員とそのコース」関係は、この種の例外的な状況に陥ります。教員が一時的にどのコースにも割り当てられなくなった場合、その教員が記載されている最後のレコードを削除する必要があり、実質的に教員も削除されることになります（ただし、コースコードフィールドがnullに設定されている場合を除く）。

データベース構造を拡張する際の再設計を最小限に抑える

完全に正規化されたデータベースでは、既存の構造を大きく変更することなく、新しいタイプのデータに対応するために構造を拡張できます。その結果、データベースとやり取りするアプリケーションへの影響は最小限に抑えられます。

正規化された関係、および 1 つの正規化された関係と別の正規化された関係の関係は、現実世界の概念とそれらの相互関係を反映しています。

正規形

コッドは1970年に正規化の概念と現在では第一正規形（1NF）として知られているものを導入しました。[4]コッドは1971年に第二正規形（2NF）と第三正規形（3NF）を定義し、[5]コッドとレイモンド F. ボイスは1974年にボイス・コッド正規形（BCNF）を定義しました。 [6]

ロナルド・フェイギンは1977 年に第4 正規形(4NF)を導入し、1979 年には第 5 正規形(5NF) を導入しました。クリストファー・J・デイトは 2003 年に第6 正規形(6NF) を導入しました。

非公式には、リレーショナルデータベースの関係は、第3正規形を満たす場合、「正規化されている」と表現されることが多い。[7]ほとんどの3NF関係には、挿入、更新、および削除の異常がない。

正規形（最も正規化されていないものから最も正規化されているものまで）は次のとおりです。

制約
（括弧内は非公式な説明）		UNF
（1970）		1NF
（1970年）		2NF
（1971）		3NF
（1971）		EKNF
（1982）		BCNF
（1974）		4NF
（1977年）		ETNF
（2012）		5NF
（1979）		DKNF
（1981）		6NF
（2003）
一意の行（重複レコードなし）[4]多分はいはいはいはいはいはいはいはいはいはい
スカラー列（列にはリレーションや複合値を含めることはできません）[5]いいえはいはいはいはいはいはいはいはいはいはい
すべての非プライム属性は、各候補キーに完全な機能的依存関係を持つ（属性はすべてのキー全体に依存する） [5]いいえいいえはいはいはいはいはいはいはいはいはい
すべての非自明な関数従属性は、スーパーキーで始まるか、プライム属性で終わる（属性は候補キーのみに依存する） [5]いいえいいえいいえはいはいはいはいはいはいはいはい
すべての非自明な関数従属性は、スーパーキーで始まるか、基本プライム属性で終わる（3NFのより厳密な形式）いいえいいえいいえいいえはいはいはいはいはいはい—
すべての非自明な関数従属性はスーパーキー（3NFのより厳密な形式）で始まるいいえいいえいいえいいえいいえはいはいはいはいはい—
すべての非自明な多値依存関係はスーパーキーから始まるいいえいいえいいえいいえいいえいいえはいはいはいはい—
すべての結合依存関係にはスーパーキーコンポーネントがあります[8]いいえいいえいいえいいえいいえいいえいいえはいはいはい—
すべての結合依存関係にはスーパーキーコンポーネントのみが含まれますいいえいいえいいえいいえいいえいいえいいえいいえはいはい—
すべての制約はドメイン制約とキー制約の結果であるいいえいいえいいえいいえいいえいいえいいえいいえいいえはいいいえ
すべての結合依存関係は些細なものであるいいえいいえいいえいいえいいえいいえいいえいいえいいえいいえはい

段階的な正規化の例

正規化は、リレーショナルデータベースのテーブルを高次の正規形まで設計するために使用されるデータベース設計手法です。 [9]このプロセスは段階的であり、前のレベルが満たされない限り、より高いレベルのデータベース正規化を達成することはできません。[10]

つまり、正規化されていない形式（最も正規化されていない形式）のデータを使用して、最高レベルの正規化を目指す場合、最初のステップでは第 1 正規形への準拠を確認し、2 番目のステップでは第 2 正規形が満たされていることを確認し、というように、データが第 6 正規形に準拠するまで、上記の順序で処理が行われます。

しかし、 4NFを超える正規形は、その存在目的である問題が実際にはほとんど現れないため、主に学術的な関心の対象となっている。[11]

以下の例のデータは、ほとんどの正規形と矛盾するように意図的に設計されています。実際には、データはすでにある程度正規化されているため、正規化手順の一部を省略できる場合がよくあります。ある正規形の違反を修正すると、より高次の正規形の違反も修正されることがよくあります。この例では、各手順で1つのテーブルが正規化対象として選択されているため、最終的に一部のテーブルが十分に正規化されていない可能性があります。

初期データ

次のような構造のデータベーステーブルがあるとする: [10]

タイトル著者著者国籍形式価格主題ページ厚さ出版社出版社の国ジャンルIDジャンル名
MySQLデータベース設計と最適化入門チャド・ラッセルアメリカ人ハードカバー49.99
MySQL
データベース
デザイン
520厚いアプレスアメリカ合衆国1チュートリアル

この例では、各書籍には著者が 1 人だけいるものと想定します。

リレーショナルモデルに準拠したテーブルには、行を一意に識別する主キーがあります。この例では、主キーは{Title, Format}の複合キーです（下線で示されています）。

タイトル著者著者国籍形式価格主題ページ厚さ出版社出版社の国ジャンルIDジャンル名
MySQLデータベース設計と最適化入門チャド・ラッセルアメリカ人ハードカバー49.99
MySQL
データベース
デザイン
520厚いアプレスアメリカ合衆国1チュートリアル

1NFを満たす

第一正規形では、各フィールドには単一の値が含まれます。フィールドには、値の集合やネストされたレコードを含めることはできません。Subjectにはsubject値の集合が含まれているため、この正規形には準拠していません。この問題を解決するために、subjectは別のSubjectテーブルに抽出されます。[10]

本
タイトル著者著者国籍形式価格ページ厚さ出版社出版社の国ジャンルIDジャンル名
MySQLデータベース設計と最適化入門チャド・ラッセルアメリカ人ハードカバー49.99520厚いアプレスアメリカ合衆国1チュートリアル
タイトル - 件名
タイトル件名
MySQLデータベース設計と最適化入門MySQL
MySQLデータベース設計と最適化入門データベース
MySQLデータベース設計と最適化入門デザイン

非正規化形式の 1 つのテーブルの代わりに、1NF に準拠する 2 つのテーブルが存在するようになりました。

2NFを満たす

下のBookテーブルには{Title, Format}という複合キーがありますが、そのキーの一部が行列式である場合、2NF を満たしません。設計のこの時点では、このキーは主キーとして確定していないため、候補キーと呼ばれます。次のテーブルを考えてみましょう。

本
タイトル形式著者著者国籍価格ページ厚さ出版社出版社の国ジャンルIDジャンル名
MySQLデータベース設計と最適化入門ハードカバーチャド・ラッセルアメリカ人49.99520厚いアプレスアメリカ合衆国1チュートリアル
MySQLデータベース設計と最適化入門電子書籍チャド・ラッセルアメリカ人22.34520厚いアプレスアメリカ合衆国1チュートリアル
データベース管理のためのリレーショナルモデル: バージョン 2電子書籍EFコッドイギリス13.88538厚いアディソン・ウェズリーアメリカ合衆国2ポピュラーサイエンス
データベース管理のためのリレーショナルモデル: バージョン 2ペーパーバックEFコッドイギリス39.99538厚いアディソン・ウェズリーアメリカ合衆国2ポピュラーサイエンス

候補キーに含まれない属性はすべてTitleに依存しますが、PriceのみFormatにも依存します。2NFに準拠し、重複を排除するために、候補キーに含まれないすべての属性は、候補キーの一部ではなく、全体に依存する必要があります。

このテーブルを正規化するには、{Title}を (単純な) 候補キー (主キー) にして、候補キー以外のすべての属性が候補キー全体に依存するようにし、Priceを別のテーブルに移動して、 Formatへの依存関係を維持できるようにします。

本
タイトル著者著者国籍ページ厚さ出版社出版社の国ジャンルIDジャンル名
MySQLデータベース設計と最適化入門チャド・ラッセルアメリカ人520厚いアプレスアメリカ合衆国1チュートリアル
データベース管理のためのリレーショナルモデル: バージョン 2EFコッドイギリス538厚いアディソン・ウェズリーアメリカ合衆国2ポピュラーサイエンス
価格
タイトル形式価格
MySQLデータベース設計と最適化入門ハードカバー49.99
MySQLデータベース設計と最適化入門電子書籍22.34
データベース管理のためのリレーショナルモデル: バージョン 2電子書籍13.88
データベース管理のためのリレーショナルモデル: バージョン 2ペーパーバック39.99

これで、Book テーブルとPriceテーブルの両方が2NFに準拠するようになりました。

3NFを満たす

Bookテーブルには依然として推移的な関数従属関係が存在します（{Author Nationality}は{Author}に依存し、{Author}は{Title}に依存しています）。出版社（{Publisher Country}は{Publisher}に依存し、{Publisher}は{Title}に依存しています）とジャンル（{Genre Name}は{Genre ID}に依存し、{Genre IDは{Title}に依存しています）にも同様の違反があります。したがって、Bookテーブルは3NFではありません。これを解決するには、{Author Nationality}、{Publisher Country}、{Genre Name}をそれぞれ独立したテーブルに配置することで、推移的な関数従属関係を排除できます。

本
タイトル著者ページ厚さ出版社ジャンルID
MySQLデータベース設計と最適化入門チャド・ラッセル520厚いアプレス1
データベース管理のためのリレーショナルモデル: バージョン 2EFコッド538厚いアディソン・ウェズリー2
価格
タイトル形式価格
MySQLデータベース設計と最適化入門ハードカバー49.99
MySQLデータベース設計と最適化入門電子書籍22.34
データベース管理のためのリレーショナルモデル: バージョン 2電子書籍13.88
データベース管理のためのリレーショナルモデル: バージョン 2ペーパーバック39.99
著者
著者国籍
チャド・ラッセルアメリカ人
EFコッドイギリス
出版社
出版社国
アプレスアメリカ合衆国
アディソン・ウェズリーアメリカ合衆国
ジャンル
ジャンルID名前
1チュートリアル
2ポピュラーサイエンス

EKNFを満たす

基本キー正規形（EKNF）は、厳密には3NFとBCNFの中間に位置し、文献ではあまり議論されていません。EKNFは、「3NFとBCNFの両方の顕著な特性を捉える」と同時に、両方の問題点（つまり、3NFは「許容度が高すぎる」、BCNFは「計算量が膨大になりやすい」）を回避することを目的としています。文献ではほとんど言及されていないため、この例では含まれていません。

4NFを満たす

データベースは、複数のフランチャイズ店がそれぞれ異なる場所に店舗を構える書籍販売店のフランチャイズによって所有されていると仮定します。そこで、この小売業者は、異なる場所における書籍の在庫状況に関するデータを格納するテーブルを追加することにしました。

フランチャイズ - 予約 - 場所
フランチャイズ加盟店IDタイトル位置
1MySQLデータベース設計と最適化入門カリフォルニア
1MySQLデータベース設計と最適化入門フロリダ
1MySQLデータベース設計と最適化入門テキサス
1データベース管理のためのリレーショナルモデル: バージョン 2カリフォルニア
1データベース管理のためのリレーショナルモデル: バージョン 2フロリダ
1データベース管理のためのリレーショナルモデル: バージョン 2テキサス
2MySQLデータベース設計と最適化入門カリフォルニア
2MySQLデータベース設計と最適化入門フロリダ
2MySQLデータベース設計と最適化入門テキサス
2データベース管理のためのリレーショナルモデル: バージョン 2カリフォルニア
2データベース管理のためのリレーショナルモデル: バージョン 2フロリダ
2データベース管理のためのリレーショナルモデル: バージョン 2テキサス
3MySQLデータベース設計と最適化入門テキサス

このテーブル構造は複合主キーで構成されているため、キー以外の属性は含まれず、既にBCNF形式になっています（したがって、前述のすべての正規形も満たしています）。しかし、各エリアで入手可能なすべての書籍が提供されていると仮定すると、タイトルは特定の場所に明確に結び付けられず、したがってこのテーブルは4NF形式を満たしていません。

つまり、第4 正規形を満たすには、この表も分解する必要があります。

フランチャイズ - 予約
フランチャイズ加盟店IDタイトル
1MySQLデータベース設計と最適化入門
1データベース管理のためのリレーショナルモデル: バージョン 2
2MySQLデータベース設計と最適化入門
2データベース管理のためのリレーショナルモデル: バージョン 2
3MySQLデータベース設計と最適化入門
フランチャイズ - 所在地
フランチャイズ加盟店ID位置
1カリフォルニア
1フロリダ
1テキサス
2カリフォルニア
2フロリダ
2テキサス
3テキサス

これで、すべてのレコードはスーパーキーによって明確に識別されるため、4NFが満たされます。

満足のいくETNF

フランチャイズ加盟店が複数の供給元から書籍を注文できると仮定します。この関係には以下の制約も課されます。

  • 特定のサプライヤーが特定のタイトルを供給している場合
  • そしてそのタイトルはフランチャイジーに提供される
  • フランチャイジーはサプライヤーから供給を受けている。
  • その後、サプライヤーはフランチャイジーに権利を付与します。[12]
サプライヤー - 書籍 - フランチャイズ
サプライヤーIDタイトルフランチャイズ加盟店ID
1MySQLデータベース設計と最適化入門1
2データベース管理のためのリレーショナルモデル: バージョン 22
3SQLの学習3

この表は4NFですが、サプライヤーIDはその射影の結合に等しくなります: {{サプライヤーID, タイトル}, {タイトル, フランチャイズID}, {フランチャイズID, サプライヤーID}}。この結合依存関係のどの要素もスーパーキーではありません（唯一のスーパーキーは見出し全体です）。そのため、この表はETNFを満たしておらず、さらに分解することができます: [12]

サプライヤー - 書籍
サプライヤーIDタイトル
1MySQLデータベース設計と最適化入門
2データベース管理のためのリレーショナルモデル: バージョン 2
3SQLの学習
予約 - フランチャイズ
タイトルフランチャイズ加盟店ID
MySQLデータベース設計と最適化入門1
データベース管理のためのリレーショナルモデル: バージョン 22
SQLの学習3
フランチャイジー - サプライヤー
サプライヤーIDフランチャイズ加盟店ID
11
22
33

分解により ETNF コンプライアンスが生成されます。

5NFを満たす

5NF を満たさない表を見つけるには、通常、データを徹底的に調べる必要があります。4NF の例の表に少しデータ変更を加えて、5NF を満たすかどうかを調べてみましょう。

フランチャイズ - 予約 - 場所
フランチャイズ加盟店IDタイトル位置
1MySQLデータベース設計と最適化入門カリフォルニア
1SQLの学習カリフォルニア
1データベース管理のためのリレーショナルモデル: バージョン 2テキサス
2データベース管理のためのリレーショナルモデル: バージョン 2カリフォルニア

このテーブルを分解すると冗長性が減り、次の 2 つのテーブルが生成されます。

フランチャイズ - 予約
フランチャイズ加盟店IDタイトル
1MySQLデータベース設計と最適化入門
1SQLの学習
1データベース管理のためのリレーショナルモデル: バージョン 2
2データベース管理のためのリレーショナルモデル: バージョン 2
フランチャイズ - 所在地
フランチャイズ加盟店ID位置
1カリフォルニア
1テキサス
2カリフォルニア

これらのテーブルを結合するクエリは次のデータを返します。

フランチャイズ - 予約 - 場所 JOINed
フランチャイズ加盟店IDタイトル位置
1MySQLデータベース設計と最適化入門カリフォルニア
1SQLの学習カリフォルニア
1データベース管理のためのリレーショナルモデル: バージョン 2カリフォルニア
1データベース管理のためのリレーショナルモデル: バージョン 2テキサス
1SQLの学習テキサス
1MySQLデータベース設計と最適化入門テキサス
2データベース管理のためのリレーショナルモデル: バージョン 2カリフォルニア

JOIN は、必要以上に 3 行多く返します。関係を明確にするために別のテーブルを追加すると、3 つの別々のテーブルが作成されます。

フランチャイズ - 予約
フランチャイズ加盟店IDタイトル
1MySQLデータベース設計と最適化入門
1SQLの学習
1データベース管理のためのリレーショナルモデル: バージョン 2
2データベース管理のためのリレーショナルモデル: バージョン 2
フランチャイズ - 所在地
フランチャイズ加盟店ID位置
1カリフォルニア
1テキサス
2カリフォルニア
場所 - 予約
位置タイトル
カリフォルニアMySQLデータベース設計と最適化入門
カリフォルニアSQLの学習
カリフォルニアデータベース管理のためのリレーショナルモデル: バージョン 2
テキサスデータベース管理のためのリレーショナルモデル: バージョン 2

JOINは今何を返すでしょうか？実際には、これら3つのテーブルを結合することはできません。つまり、Franchisee - Book - Locationをデータ損失なしで分解することは不可能であり、したがって、このテーブルは既に5NFを満たしています。

免責事項- 使用したデータは原則を示していますが、必ずしも真実とは限りません。この場合、データは「ストアID」と呼ぶ代替キーを使用して、以下のように分解するのが最適でしょう。

ストア - 書籍
店舗IDタイトル
1MySQLデータベース設計と最適化入門
1SQLの学習
2データベース管理のためのリレーショナルモデル: バージョン 2
3データベース管理のためのリレーショナルモデル: バージョン 2
店舗 - フランチャイズ - 所在地
店舗IDフランチャイズ加盟店ID位置
11カリフォルニア
21テキサス
32カリフォルニア

JOIN は期待どおりの結果を返します。

店舗 - 書籍 - フランチャイズ - 場所 JOINed
店舗IDタイトルフランチャイズ加盟店ID位置
1MySQLデータベース設計と最適化入門1カリフォルニア
1SQLの学習1カリフォルニア
2データベース管理のためのリレーショナルモデル: バージョン 21テキサス
3データベース管理のためのリレーショナルモデル: バージョン 22カリフォルニア


CJ Dateは、5NF形式のデータベースだけが真に「正規化」されていると主張した。[13]

満足のいくDKNF

前の例のBookテーブルを見て、ドメインキーの正規形を満たしているかどうかを確認しましょう。

本
タイトルページ厚さジャンルID発行者ID
MySQLデータベース設計と最適化入門520厚い11
データベース管理のためのリレーショナルモデル: バージョン 2538厚い22
SQLの学習338スリム13
SQL クックブック636厚い13

論理的には、厚さはページ数によって決まります。つまり、キーではないページ数に依存します。例として、350ページまでの本は「薄い」、350ページを超える本は「厚い」とみなすという規則を設定してみましょう。

この規則は技術的には制約ですが、ドメイン制約でもキー制約でもありません。したがって、データの整合性を維持するためにドメイン制約とキー制約に依存することはできません。

言い換えれば、たとえば 50 ページしかない本に「厚い」と表示することを妨げるものは何もありません。これは、表がDKNF に違反することを意味します。

これを解決するには、厚さを定義する列挙を保持するテーブルを作成し、その列を元のテーブルから削除します。

厚さ列挙型
厚さ最小ページ数最大ページ数
スリム1350
厚い351999,999,999,999
書籍 - ページ数 - ジャンル - 出版社
タイトルページジャンルID発行者ID
MySQLデータベース設計と最適化入門52011
データベース管理のためのリレーショナルモデル: バージョン 253822
SQLの学習33813
SQL クックブック63613

これにより、ドメイン整合性違反が排除され、テーブルはDKNFになります。

正規化によって、不可能／矛盾／予測不可能な出力が全て防止されるわけではありません。この例では、最小ページ数／最大ページ数を1／350、200／999,999,999,999とした場合、予測不可能な結果となります。したがって、最小ページ数のみを指定して使用することをお勧めします。

6NFを満たす

第6正規形のシンプルで直感的な定義は、「行に主キーと最大で1つの他の属性が含まれている場合、テーブルは6NFである」というものです。[14]

つまり、たとえば、1NF の作成中に設計されたPublisherテーブルは次のようになります。

出版社
発行者ID名前国
1アプレスアメリカ合衆国

さらに 2 つのテーブルに分解する必要があります。

出版社
発行者ID名前
1アプレス
出版社の国
発行者ID国
1アメリカ合衆国

6NFの明らかな欠点は、単一のエンティティの情報を表すために必要なテーブルが急増することです。5NFのテーブルに主キー列が1つと属性がN個ある場合、6NFで同じ情報を表すにはN個のテーブルが必要になります。単一の概念レコードに対する複数フィールドの更新には複数のテーブルの更新が必要になり、挿入と削除も同様に複数のテーブルにまたがる操作が必要になります。このため、オンライントランザクション処理（OLTP）のニーズに対応するデータベースでは、6NFは使用すべきではありません。

しかし、インタラクティブな更新を許可せず、大量のデータに対する高速クエリに特化したデータウェアハウスでは、一部のDBMSは内部的に6NF表現（列指向データストアと呼ばれる）を使用します。列の一意の値の数がテーブルの行数よりもはるかに少ない場合、列指向ストレージはデータ圧縮によって大幅なスペース節約を実現します。また、列指向ストレージは範囲クエリ（例えば、特定の列がXとYの間、またはX未満であるすべてのレコードを表示するなど）の高速実行も可能にします。

しかし、これらすべてのケースにおいて、データベース設計者は個別のテーブルを作成して6NF正規化を手動で行う必要はありません。Sybase IQなど、ウェアハウスに特化した一部のDBMSは、デフォルトで列指向ストレージを使用しますが、設計者には単一の複数列テーブルしか見えません。Microsoft SQL Server 2012以降などの他のDBMSでは、特定のテーブルに対して「列ストアインデックス」を指定できます。[15]

参照

注釈と参考文献

  1. ^ 「リレーショナルデータモデルの採用により、応用述語論理に基づく汎用データサブ言語の開発が可能になります。関係の集合が正規形であれば、一階述語論理で十分です。このような言語は、提案されている他のすべてのデータ言語の言語力の尺度となり、適切な構文修正を加えることで、様々なホスト言語（プログラミング言語、コマンド指向言語、問題解決型言語）に組み込むための有力な候補となるでしょう。」Codd、「大規模共有データバンクのためのリレーショナルデータモデル」、2007年6月12日アーカイブ、Wayback Machine、381ページ
  2. ^ Codd, EF 第23章「SQLの重大な欠陥」『リレーショナル・モデル・データベース管理：バージョン2』Addison-Wesley (1990)、371～389ページ
  3. ^ Codd, EF「データベースリレーショナルモデルのさらなる正規化」、34ページ
  4. ^ ab Codd, EF (1970年6月). 「大規模共有データバンクのためのリレーショナルデータモデル」Communications of the ACM . 13 (6): 377– 387. doi : 10.1145/362384.362685 . S2CID  207549016.
  5. ^ abcd Codd, EF「データベース・リレーショナル・モデルのさらなる正規化」。（Courant Computer Science Symposia Series 6「データベース・システム」、ニューヨーク市、1971年5月24～25日発表）IBM Research Report RJ909（1971年8月31日）。Randall J. Rustin編『データベース・システム：Courant Computer Science Symposia Series 6』、Prentice-Hall、1972年に再掲載。
  6. ^ Codd, EF「リレーショナル・データベース・システムに関する最近の調査」IBMリサーチ・レポートRJ1385（1974年4月23日）。Proc . 1974 Congress（ストックホルム、スウェーデン、1974年）に再掲載。NY: North-Holland（1974年）。
  7. ^ Date, CJ (1999). 『データベースシステム入門』Addison-Wesley. p. 290.
  8. ^ Darwen, Hugh; Date, CJ; Fagin, Ronald (2012). 「リレーショナルデータベースにおける冗長タプルの防止のための正規形」(PDF) .第15回国際データベース理論会議議事録. EDBT/ICDT 2012 合同会議. ACM 国際会議議事録シリーズ. Association for Computing Machinery . p. 114. doi :10.1145/2274576.2274589. ISBN 978-1-4503-0791-8. OCLC  802369023. 2016年3月6日時点のオリジナルよりアーカイブ（PDF） 。 2018年5月22日閲覧。
  9. ^ Kumar, Kunal; Azad, SK (2017年10月). 「データベース正規化デザインパターン」. 2017年第4回IEEEウッタル・プラデーシュ支部国際電気・コンピュータ・エレクトロニクス会議 (UPCON) . IEEE. pp.  318– 322. doi :10.1109/upcon.2017.8251067. ISBN 9781538630044. S2CID  24491594。
  10. ^ abc 「MySQLでのデータベース正規化：4つの簡単な手順」ComputerWeekly.com . 2017年8月30日時点のオリジナルよりアーカイブ。 2021年3月23日閲覧。
  11. ^ 「データベースの正規化：第5正規形とそれ以降」MariaDBナレッジベース。 2019年1月23日閲覧。
  12. ^ ab Date, CJ (2015年12月21日). 『新リレーショナルデータベース辞典：用語、概念、および例』O'Reilly Media, Inc.. p. 138. ISBN 9781491951699。
  13. ^ Date, CJ (2015年12月21日). 『新リレーショナルデータベース辞典：用語、概念、および例』O'Reilly Media, Inc.. p. 163. ISBN 9781491951699。
  14. ^ 「正規化 - 例を使って6NFを理解したい」。Stack Overflow 。 2019年1月23日閲覧。
  15. ^ Microsoft Corporation. 列ストアインデックス：概要. https://docs.microsoft.com/en-us/sql/relational-databases/indexes/columnstore-indexes-overview. 2020年3月23日にアクセス。

さらに読む

  • Date, CJ (1999)、『データベースシステム入門』（第8版）Addison-Wesley Longman. ISBN 0-321-19784-4。
  • ケント、W.（1983）リレーショナルデータベース理論における5つの正規形の簡単なガイド、Communications of the ACM、第26巻、pp.120-125
  • H.-J. Schek、P. Pistor 統合データベース管理および情報検索システムのためのデータ構造
  • ケント, ウィリアム (1983年2月). 「リレーショナルデータベース理論における5つの正規形への簡単なガイド」Communications of the ACM . 26 (2): 120–125 . doi : 10.1145/358024.358054 . S2CID  9195704.
  • データベース正規化の基礎 2007年2月5日アーカイブ、Wayback Machineマイケル・チャップル (About.com)
  • データベース正規化入門 2011年9月28日アーカイブ、Wayback Machine、パート2 2011年7月8日アーカイブ、Wayback Machine
  • Mike Hillyer 著「データベース正規化入門」。
  • Fred Coulsonによる最初の3つの正規形に関するチュートリアル
  • Microsoftによるデータベース正規化の基礎の説明
  • Chaitanya 著「DBMS における正規化」（beginnersbook.com）
  • データベース正規化のステップバイステップガイド
  • ETNF – 基本タプル正規形 2016年3月6日アーカイブ、Wayback Machine
「https://en.wikipedia.org/w/index.php?title=データベース正規化&oldid=1321404470」より取得