このパブリケーションには、データベースの「正規化」(Normalization)が含まれています.
「組織と整理は巨大なテレスゲームのようだ」
                                                                                 --アレクサンドラ・コストロ

[Intro]

引き出しを整理するとき、電子機器は2番目の引き出しに入れます.
最初の引き出しに白いものを入れることにしたら
白い電子機器はどの引き出しに入れたらいいですか?

この現象をデータベースでは「異常現象」(Anomaly)と呼ぶ.
データの整合性を確保するために明確な基準を提供し、
データベースを標準化と呼びます.

[Anomaly異常現象]

이상 현상 

불필요한 데이터 중복으로 인해 릴레이션에 대한 데이터 삽입, 수정, 삭제 연산을 

수행할 때 발생할 수 있는 부작용

종류

- 삽입 이상 : 새 데이터를 삽입하기 위해 불필요한 데이터도 함께 삽입해야 하는 문제
- 갱신 이상 : 중복 튜플 중 일부만 변경하여 데이터가 불일치하게 되는 모순의 문제
- 삭제 이상 : 튜플을 삭제하면 꼭 필요한 데이터까지 함께 삭제되는 데이터 손실의 문제

データベースの設計が正しくないと、不要な重複データストレージが発生する可能性があります.
この場合、リソースが浪費され、運用上の予期せぬ副作用が生じる可能性があります.

Insertion Anomaly

	: 데이터를 저장할 때 원하지 않는 정보가 함께 삽입되어야 하는 경우

上図のように、表に値を入力したいのですが、これまでのレッスンでは
存在しない場合はありません.
新しいデータを挿入するには、次のコード名を入力します.
作り直す必要があります.これを「挿入」異常と呼びます.

Update Anomaly

	: 중복된 튜플 중 일부의 속성만 갱신 시킴으로써 정보의 모순성이 발생하는 경우

519号の従業員が引っ越した後、木工の技能を身につけて新しい関連情報を入力すると、
アドレスが更新されていないと、「更新」またはそれ以上のバージョンと呼ばれるデータにエラーが発生します.

Deletion Anomaly

	: 튜플을 삭제함으로써 유지되어야 하는 정보까지도 연쇄적으로 삭제되는 경우

389号教職員の英語課程が廃止され、この課程が削除された場合、その教職員の名前と雇用日、
IDとともにパターン単位で連鎖して削除され、情報が失われる可能性があります.
これを「削除」例外と呼びます.

なぜこのような問題が発生したのでしょうか。

上記の異常は表設計が規範化されていないためである.データベース設計では、コードの再利用性とメンテナンス性を向上させるために、コードを符号化する際に興味点を分離するなど、同様の原則がデータベース設計にも適用されます.データベース設計では、コードの問題よりも、興味が分離されていないための問題がずっと深刻です.
理論的には,正規化には属性間の相関性を理解する必要がある.
これらのアトリビュート間の相関함수적 종속성(Functional Dependency)です
通常、あるバージョンでは、
これにより、関数の依存関係が正規化されます.

[Purpose]

そのため、これらの異常を排除し、冗長データを最小限に抑えます.
正規化の目的といえる.また、データベース構造を拡張する場合、
クエリーを最小化し、複数の角度からクエリーをサポートできます.

[Target]

オンライン取引処理(OLT P)データベース、例えば大型オンラインチケットシステム.
CRUD(Create、Read、Update、Delete)は非常に多く、正規化に適しています.
逆に、分析レポートなどのデータベースのオンライン分析処理
分析とレポートに使用するため、半正規化を使用して演算速度を速めることをお勧めします.

반정규화 : 정규화된 시스템을 성능 향상 및 개발과 운영의 단순화를 위해 역으로 정규화를 수행하는 것. 
		  일반적으로 Join을 많이 사용해야 하거나, 대량의 범위를 자주 처리하는 경우와 
		  같이 Select 작업의 중요도가 높다고 판단될때 반정규화를 수행합니다.

[Step of Normalization]

正規化段階は大きく7段階に分けられる.

現実のほとんどのバージョンでは、BCNFを標準化すると
実際の異常現象がないため、BCNFは通常正規化される.

[Type of Key]

正規化を行う前に、後述する鍵のタイプについて簡単に説明します.

一意性:キー値は1つのtupleしか認識できません.

最小:すべてのレコードは、一意の識別に必要な属性から構成される必要があります.(鍵値が一意に識別された鍵でない限り、鍵は削除される)

1.スーパーキー：一意性O/最小性X

[身分証明書番号、氏名]→🟢
名前→🔴
身分証明書番号→🟢

2.候補鍵（Candidate Key）：一意性O/最小性O

簡単に言えば、いつでもプライマリ・キーになれるキーです.
ID→🟢
I-pin → 🟢
アカウント→🟠
テーブルがどのようなテーブルであるかは、候補キーであってもよいし、そうでなくてもよい.
(どのテーブルかによっては、ユニークかもしれないし、そうではないかもしれない)
ex)「顧客表」、「一意性満足/支払情報」表で同じ勘定科目を使用して複数の取引を行う

3.プライマリーキー(Primary Key):候補キーリストから選択したキー

1. Null(결측값)이 없어야함
2. 자주 변경되는 속성이 포함되어있으면 부적절
3. 가급적 단순한 후보키를 선택

4.外部キー:他のバージョンのプライマリ・キーを参照してください

1.第一正規化（1 NF）

バージョン内のすべての属性の値が원자성(Atomic)の場合、1 NFに属します.

左側のバージョンは1 NFを満たしていません.興味は原子性ではなく複数の値を持つ
なぜなら.したがって,右側に示すように原子値を1番目の正規化に変更する.

2.第2正規化（2 NF）

リリース版が最初の一般的なフォーマットを満たし、プライマリ・キーではなく属性がプライマリ・キーに完全に依存していることを示します.

つまり,鍵でない列は鍵によって決まる.

部分関数依存

属性セットXのすべてではなく、属性セットYが関数依存であることを示す.
下図に示すように、学生番号とカリキュラム名がプライマリキー(Primary Key、以下PK)である場合、教室
PKに従属することもできますが、PKセクションの集合に従属するカリキュラム名(確定)から従属することもできます.
この場合,部分関数依存関係といえる.

*意思決定者、従属者

次の図に示すように、どの属性(キー値、矢印の始点)を決定するかを決定します.
意思決定者が意味を決定する属性を従属者と呼ぶ.

したがって、下図に示すように、すべての非プライマリ・キー属性がプライマリ・キーに完全に依存している場合は、2 NFに属する.

3.第3正規化（3 NF）

このバージョンが2 NFを満たし、依存関係が存在しないことを示します(<->直接依存関係).

動的従属関係:A->B、B->Cが成立した場合、A->Cが成立した関数従属関係を指す.

このような場合、501人の学生がデータベース課程をスポーツ経営学課程に変更すると、
2万の学費スポーツ経営学もちろん、カリキュラム名に基づいて
変更は可能ですが、2回の変更が必要です.こんな面倒.
問題を解決するのは3番目の正規化だ.
既存の表では、学生番号がカリキュラム名を決定し、カリキュラム名が授業料を決定します.この2つの関係は、次のように分けなければなりません.

4. BCNF(Boyce–Codd Normal Form)

このバージョンが関数依存関係X->Yを満たす場合、すべての決定者Xは候補キーの正規バージョンである.

プライマリ・キーは(学生番号、テーマ名)、教授は(学生番号、テーマ名)の完全な関数依存項目です.また、教授も講座の名称を決め、決定者の役割を果たしている.
次に、すべての意思決定者が候補鍵であることを確認します.(学生番号、テーマ名)はプライマリ・キーであり、もちろん意思決定者と候補キーである.ただし、教授は意思決定者であり、候補鍵ではないため、バージョンを上図と区別する必要があります.

ほとんどのバージョンでは、BCNFを標準化すると、実際の異常現象が解消され、BCNFが標準化されます。

[pros and cons]

正規化のメリットとデメリットは次のとおりです.
🟢 異常現象による問題を解決することができる.
🟢 ユーザーに標準化されたテーブルとテーブルの関係を提供できます.
🔴 複数バージョン間の演算(JOIN).
🔴 これにより、クエリの応答時間が遅くなる可能性があります.

[半正規化(De-normalization,非正規化)]

半標準化は、パフォーマンスの向上、開発、操作の簡素化のために、重複する標準化データベースを統合します.
データモデリング技術、例えば分離.
ディスクI/O数が増加したり、テーブル間のパスが遠すぎたりして、大量の結合が発生し、パフォーマンスが低下します.
必要に応じて、逆正規化を実行できます.通常、Selectの処理能力
これが重要だと思ったら、局所的などうせの規則化を考えます.

どうせ正規化された対象

共通テーブルにアクセスするプロセスが最も多い.
常に一定の範囲のみを表示している場合は、

テーブルに大量のデータがあり、頻繁に大量の範囲を処理している場合、パフォーマンスの問題が発生する可能性があります.

テーブルの結合が多すぎるため、技術的にデータのクエリーが困難です.

半正規化の欠点

の半標準化を過度に適用すると、データの整合性が損なわれ、入力/変更/削除クエリへの応答時間が遅延する可能性があります.

[Summary of Nomalization]