0

これがBCNFにあるかどうかはわかりませんが、先生はINSTRUMENTがBCNFにあると教えてくれました。彼は私をいじっていますか?先生は何が正しくて何が間違っているのか私の心を混乱させ続け、私を不安にさせます。彼は私がすでに考えていることをはっきりと言い続けており、私は彼が言っていることすら理解していません。

INSTRUMENTInstrumentID,InstrumentType、Tune、Performer、Adr、Phone、Availability) TitleNr,Tune,Composer、Copies、Title、Performer)

それで、これは正規化されていますか?BCNFで:

InstrumentInstrumentID、InstrumentType、Tune、Availability、PerformerID *)
TitleNr, Title,Tune、Composer、Copies、PerformerID *)
PERFORMERPerformerID、Name、Adr、Phone)

TuneはINSTRUMENTとNOTESの両方にあります。それは両方にあることができますか?

4

3 に答える 3

1

正規化は個々のテーブルに適用されます。それは機能的な依存関係に基づいています。

機能の依存関係は、列名ではなく、データによって決定されます。講師はデータを提供しませんでした。列名だけで機能の依存関係を判断しようとするのは、たとえ列の名前が適切であっても、危険なビジネスです。列の名前が適切ではありません。

想像力に富んだデータベース設計者であれば、BCNF を示す最初の "Instruments" テーブルの述語とサンプル データを考え出すことができます。

多分あなたのインストラクターもこのことを理解していないでしょう。最初ではないでしょう。

于 2011-01-14T21:17:40.267 に答える
1

各標準形には、その前に標準形が必要です。

1 NF - テーブルにはアトミック値しかありません。つまり、セットはありません。

2 NF - 非キー属性では、キーのすべての部分を決定する必要があります。

3 NF - 非キー属性は、決定されるキー以外は何も必要としません。

3.5 NF - 非キー属性がキー属性を決定できる場合、一意のタプルを作成する必要があります。

私の最初の関心事は、TitleNr の略です。それが一意の ID である場合、非キー属性ではタイトルを決定する必要がないため、2 NF ではありません。

私の 2 番目の懸念は、Tune が含まれている場合、InstrumentID が適切な候補キーではないことです。Instrument.Tune がその特定の楽器で演奏された曲を表す場合、1 つの楽器で複数の曲を演奏できます。これらの属性を別のテーブルに分割することをお勧めします。そうしないと、他の非キー属性によって 2 つの NF にならなくなります。

使用可能なチューンを表すだけの場合は、Instrument のキーの一部ではない PerformerID によってすでに判別できます。それでは3NFではありません。

于 2010-08-03T16:11:46.937 に答える