このテーブルはどの正規化ルールを壊しますか
以前のDBAは、データベーススキーマを変更して列を追加および削除するという開発チームの頻繁な要求にうんざりしていました。次に、次の定義で単純なテーブルを作成することを開発者にアドバイスしました。
+---------------+---------+
| Record Number | VarChar |
+---------------+---------+
| Column Name | VarChar |
+---------------+---------+
| Column Value | VarChar |
+---------------+---------+
したがって、開発者が通常のテーブルを次のようにしたい場合
+-------------+---------------+-----------------+
| Employee ID | Employee Name | Employee Salary |
+-------------+---------------+-----------------+
| 0001 | John Doe | 100000.00 |
+-------------+---------------+-----------------+
| 0002 | Jane Doe | 110000.00 |
+-------------+---------------+-----------------+
| 0003 | Jack Doe | 120000.00 |
+-------------+---------------+-----------------+
次の方法で行を追加できます
+---------------+-----------------+--------------+
| Record Number | Column Name | Column Value |
+---------------+-----------------+--------------+
| 1 | Employee ID | 0001 |
+---------------+-----------------+--------------+
| 1 | Employee Name | John Doe |
+---------------+-----------------+--------------+
| 1 | Employee Salary | 100000.00 |
+---------------+-----------------+--------------+
| 2 | Employee ID | 0002 |
+---------------+-----------------+--------------+
| 2 | Employee Name | Jane Doe |
+---------------+-----------------+--------------+
| 2 | Employee Salary | 110000.00 |
+---------------+-----------------+--------------+
| 3 | Employee ID | 0003 |
+---------------+-----------------+--------------+
| 3 | Employee Name | Jack Doe |
+---------------+-----------------+--------------+
| 3 | Employee Salary | 120000.00 |
+---------------+-----------------+--------------+
これは明らかににおいのテストを満たしていません、そして データベースの正規化 がそのようなセットアップの失敗を分析したいと思います。
これは壊れますか 1NF ？ 2NF ？ NF ？ [〜＃〜] bcnf [〜＃〜] ？説明はいいでしょう。
これはひどいパターンですが、実際には正規化規則に違反していません。その理由は、それが実際にモデリングしているwhatの変更だからです。データベースのモデリング、たとえばEmployeesの代わりに、エンティティ、属性、値をモデル化します。
David Browneの回答とLamakのコメントに同意します。彼らは私の分析をするのに大いに役立ちました。
Lamakがコメントで述べたように、そのようなモデルは EAVモデル として知られています。 EAVモデルは正規化ルールに違反しない可能性がありますが、主に、エンティティの記述に使用できる属性（プロパティ、パラメーター）の数が膨大であるエンティティをモデル化するために使用する必要がありますが、実際に特定のエンティティは比較的控えめです。 EAVモデルはデータを保存する効率的な方法ですが、非効率的でクエリが困難です。
ドメインのエンティティに明確に定義された属性がある状況では、 リレーショナルモデル がはるかに優れており、望ましいです。このようなモデルが [〜＃〜] rdbms [〜＃〜] で実装されている場合、ユーザーは効率的なストレージ技術や強力なクエリ機能などの強力なRDBMS機能を活用できます。
私にとって、それは最初の通常形を壊します。
どうして？ "Column Value"は値の一意のドメインを表しません（この場合、ID、nameとsalaryは異なるデータ型です：int、文字と小数）。
したがって、例は給与のSUM()を計算するだけの簡単なものになります。これには複雑なクエリを実行する必要があります。