私のデータベース設計は現在ステージ 3NF です。懸念される問題は、外部キーと場合によっては複合キーです。
私の質問はこれです：
複合キー/外部キーに関連付けられた属性が主キーに依存しない場合、複合キーや外部キーを移動して他のテーブルを作成できますか?
このリンクのおかげで、答えはイエスだと思います：
外部キーは第 3 正規形に含まれますか?
ベストアンサー: 外部キーだからといって、主キーの属性と見なされないわけではありません。そもそも外部キーであるという事実は、別のテーブルとの関係を定義していることを意味するため、[...] 3NF に違反しません。
-- TheMadProfessor
https://answers.yahoo.com/question/index?qid=20081117095121AAXWBbX#
これは、私が処理している現在の正規化段階が実際に 3NF にあるかどうか疑問に思います。
私は新しく、十分なポイントを持っていないため、この質問に関してテーブルを投稿できません。
純粋なリレーショナル データベース理論では、複合主キー (PK) を持つことを止めるものは何もなく、それらを参照する外部キー (FK) を持つことができ、それらの FK も必然的に複合です。一部のソフトウェアでは複合キーが扱いにくいため、自動生成された番号を含む ID 列を追加し、テーブルの PK として指定することがよくあります。他のテーブルは、(単純な) ID 列を参照する (単純な) FK を持つことができます。珍しくない間違いの 1 つは、元の複合 PK が依然として候補キー (CK) であることを忘れることです。代替キー (AK) になります。
CK、AK、および PK のシステムは次のように機能します。
次の表を検討してください。
CREATE TABLE elements
(
atomic_number INTEGER NOT NULL PRIMARY KEY
CHECK (atomic_number > 0 AND atomic_number < 120),
symbol CHAR(3) NOT NULL UNIQUE,
name CHAR(20) NOT NULL UNIQUE,
atomic_weight DECIMAL(8,4) NOT NULL,
period SMALLINT NOT NULL
CHECK (period BETWEEN 1 AND 7),
group CHAR(2) NOT NULL
-- 'L' for Lanthanoids, 'A' for Actinoids
CHECK (group IN ('1', '2', 'L', 'A', '3', '4', '5', '6',
'7', '8', '9', '10', '11', '12', '13',
'14', '15', '16', '17', '18')),
stable CHAR(1) DEFAULT 'Y' NOT NULL
CHECK (stable IN ('Y', 'N'))
);
atomic_number、 、symbolのそれぞれがname候補キーです。化学では、symbolが主キーとして最も便利です。物理学では、atomic_numberが最も便利です。同位体などに関する表はatomic_number列を参照していますが、化合物に関する表はsymbol列を参照しています。ここにある 3 つの CK はすべて単純です。一方、同位体表には、元素の原子番号（陽子の数）と中性子の数からなる化合物 PK があります。
質問に戻りますが、データは 3NF である可能性が高く、BCNF である可能性が高くなります (正式には 3NF よりも強力です)。
設計を評価する前に、テーブル スキーマを見せて、列に適用される制約 (機能の依存関係など) を指定する必要があります。しかし、先験的に、それが十分に正規化されるのを妨げるものは何もありません。
あなたの質問を理解しているかどうかわかりません。「3NF に違反せずにテーブルに外部キーを保持できますか?」答えは絶対にイエスです。正規化のどの段階についても、外部キーを排除する必要があるとは言いません。実際、外部キーを使用せずに、最も些細なデータを除いてすべてを正規化することはほとんど不可能です。
** アップデート **
さて、あなたの質問を理解したかもしれませんが、あなたは自分で答えたと思います. はい、完全に正規化された DB では、キー以外の依存関係を持つべきではありません。PK に依存しない FK がある場合は、それらを別のテーブルに移動する必要があります。
簡単な例を作るために、人々、彼らが住んでいる都市、およびその都市が属する国を追跡したいとします。したがって、最初のドラフトでは、次の構造を作成します: (アスタリスクは PK を示します)。
Person (person_id*, person_name, city_id, country_id)
City (city_id*, city_name)
Country (country_id*, country_name)
これは正規化されていません。都市は、その都市のどの居住者について話しているかに関係なく、同じ国にあります。パリは、ピエールについて話しているときはフランスではなく、フランソワについて話しているときはドイツにあります。(同じ名前の都市が 2 つある場合、もちろんそれらは異なる都市であり、異なる記録を持つべきです。都市は国境を越えることができると思いますが、ここでの目的のために、そうである場合、それを 2 つの都市と見なします。彼らは確かに異なる市政府、異なる郵便制度などを持っているでしょう.) したがって、非キー依存関係があります. country_id は、person_id ではなく、city_id に依存します。
したがって、このスキーマを正規化するには、country_id を PK のみに依存するテーブルに移動する必要があります。おそらく、City テーブル:
Person (person_id*, person_name, city_id)
City (city_id*, city_name, country_id)
Country (country_id*, country_name)