ルックアップ テーブルがあり、ケース 12 と 20 のような値の組み合わせを挿入しました。心配ですが、これが悪い習慣なのかどうかはわかりません。では、これがどのように有害になる可能性があるのでしょうか?
PK.........Name
1.............A
2.............B
4.............C
8.............D
12............C&D
16............E
20............C&E
ルックアップ テーブルがあり、ケース 12 と 20 のような値の組み合わせを挿入しました。心配ですが、これが悪い習慣なのかどうかはわかりません。では、これがどのように有害になる可能性があるのでしょうか?
PK.........Name
1.............A
2.............B
4.............C
8.............D
12............C&D
16............E
20............C&E
あなたの説明からは、何が問題なのかを正確に判断することはできません。ただし、[名前] 列に単なる名前ではない値が含まれている場合、設計は正規化規則に違反しています。
一意性の定義はあいまいになります。あなたの例では、リストのどこに重複が存在するかをどのように判断できますか (E、C&E、E&C、C)? (C&E) は (E&C) と同じですか?
あなたの例を拡張すると、Name 列もタイトルと組み合わされていると仮定すると、「Alex」と「Mrs」を探すのは難しい場合があります。たとえば、クエリをどのように記述しますか? 「Ale Mrs」または「Mrs Alex」のようなものですか? 「Mrs」という名前を持っている人が実際には Mr である場合はどうなりますか?. 列区切りはどうですか?
正確なクエリを作成できない場合、更新も問題を引き起こします。(C&E) のような値を (C) または (E) に更新することは有効ですか? すべて (C&E) を (C&D) に変更するクエリを実行できますか? (C&D) が既に存在する場合、この場合 (C&D&D) を許可しますか?
そうは言っても、結合された列の両方が必須であり、データがルックアップに厳密に使用される場合 (たとえば、単純な連絡先フォームの Country-State)、特に場合によっては、この設計はうまく機能する可能性がありますが、個人的には好きではありません。そこから得られる真の価値はないからです。
C
、 、D
などの値がデータ管理の観点からアトミックであるE
必要があるかどうかによって異なります。
たとえば、PK = 12 の場合、D
個別に照会または変更する必要がありますかC
(またはその逆)? はいの場合、D
内部に格納することは原子性C&D
の原則に違反するため、1NF に違反します。この場合、テーブルを 1:N の関係に分割する必要があります。
「1」テーブル:
ID
--
12
"N" テーブル ({ID, Name} がキー):
ID Name
-- ----
12 C
12 D