1

私はテーブルの正規化をチェックしていて、私が来たものを見てください:

この表に示されているデータを第 3 正規形 (3NF) に正規化するプロセスを説明し、図解します。

BRANCH_NO(PK)  BRANCH_ADDRESS    TELL_NO    MANAGER_ID    MANAGER_NAME
B001           ADDRESS 1         TELL 1     S1500         TOM DANIELS
B002           ADDRESS 2         TELL 2     S0010         MARY MARTINEZ
B003           ADDRESS 3         TELL 3     S0145         ART PETERS
B004           ADDRESS 4         TELL 4     S2250         SALLY STEM

変換後、次の 2 つのテーブルが作成され、両方とも 3NF にあると主張されます。

BRANCH_NO(PK)  BRANCH_ADDRESS    TELL_NO    MANAGER_ID(FK)
B001           ADDRESS 1         TELL 1     S1500     
B002           ADDRESS 2         TELL 2     S0010     
B003           ADDRESS 3         TELL 3     S0145     
B004           ADDRESS 4         TELL 4     S2250

と

 MANAGER_ID(PK)    MANAGER_NAME
    S1500             TOM DANIELS
    S0010             MARY MARTINEZ
    S0145             ART PETERS
    S2250             SALLY STEM

最初のテーブルが 3NF でないことは明らかだと思います。例: tell_no は、主キーではない branch_addres に依存していますが、主キーは機能的に branch_address を識別します。これは、移行的な機能依存関係と矛盾しています。

4

1 に答える 1

2

正規化とは、データベース スキーマが特定の一連の依存関係を正確に表すようにすることです。最初に依存関係が与えられていない場合、そのような演習は、属性名のセットとサンプル データのいくつかの行に基づく当て推量と推測に帰着します。したがって、何が正しくて何が間違っているかについて、決定的な答えはありません。それは、どのような仮定がなされ、その結果がどうなるかを理解するためのケースです。適用すると予想される依存関係を書き留めてから、それらの依存関係に関してスキーマが正規化されていることを確認します。

各支店が一意の支店番号と一意の住所を持つ必要があるため、これらの FD を強制したいとします。

BRANCH_NO -> BRANCH_ADDRESS
BRANCH_ADDRESS -> BRANCH_NO
BRANCH_NO -> TEL_NO
BRANCH_NO -> MANAGER_ID -> MANAGER_NAME

BRANCH_NO と BRANCH_ADDRESS の両方が候補キーになると仮定すると、2 つのテーブルの設計はこれらの依存関係に関して 3NF を満たします (1 つの主キーだけでなく、すべてのキーを考慮する必要があります)。

ここで、BRANCH_ADDRESS に対する暗黙の依存関係が正確であり、BRANCH_ADDRESS の一意性を強制するのに十分なほど重要であると想定しています。そうである場合とそうでない場合がありますが、そのため、質問に答える前にそのようなことを判断する必要があります。

于 2014-06-09T09:10:46.273 に答える