2

アプリケーションに次のシナリオがあります。

Structure と呼ばれるエンティティ、Customer と呼ばれる別のエンティティ、および Organization と呼ばれる別のエンティティ。このすべてのエンティティにはオプションの 0->N Telephones があるため、4 つのテーブルを作成しました

Structure 
ID_STRUCTURE (PK)
NAME VARCHAR

Customer
ID_CUSTOMER (PK)
RGI VARCHAR

Organization
ID_ORGANIZATION (PK)
ALIAS VARCHAR

Telephone
ID_TELEPHONE
NUMBER
ID_STRUCTURE (FK)
ID_CUSTOMER (FK)
ID_ORGANIZATION (FK)

3 つの外部キーの 1 つには常に値があり、別の 2 つには常に null が入力されます。

レジスタの例:

ID_TELEPHONE NUMBER ID_STRUCTURE ID_COSTUMER ID_ORGANIZATION
      1       1234        1         null         null
      2       4322        null       1           null 
      3       4333        null      null         2
      4       4233        null      null         2

私のDBAは、それは間違ったアプローチであり（そして正規化されていません）、このnullables fk を避けるためにN：Nテーブルを提案すると言います。しかし、ビジネス ルールでは、N:N の提案は許可されていません。しかし、この議論は正規化に関するものです。

私は間違っていて、このアプローチは正規化されていませんか? それとも、それは正しく、概念上の問題はありませんか?

4

1 に答える 1

2

ID_STRUCTURE ID_COSTUMER ID_ORGANIZATION の値はお互いの値に依存しているため、正規化されていません。3 つのプロパティのうち 1 つだけが null でないことを確認する必要があります。また、null 値を格納するためにスペースを浪費します。

このアプローチを試すことができます

TelephoneOwner
ID_Owner (PK)

Telephone
ID_TELEPHONE
NUMBER
ID_Owner (FK)

Structure 
ID_STRUCTURE (PK)
ID_Owner (FK)

Customer
ID_CUSTOMER (PK)
ID_Owner (FK)

Organization
ID_ORGANIZATION (PK)
ID_Owner (FK)

新しい talbe TelephoneOwner を追加します。Structure、Customer、Organization のすべてのエンティティが所有者であるため、ID_Owner フィールドを追加します。各電話は 1 人の所有者が所有できるため、ID_Owner フィールドも追加します。

Structure などの新しいエンティティを追加する場合は、新しい TelephoneOwner と新しい Structure を追加します。エンティティが電話を取得したら、電話の ID_Owner をエンティティの ID_Owner に設定します。

TelephoneOwner テーブルに入れる有効期限など、所有権に関するその他の特定の情報がない場合は、TelephoneOwner テーブルを無視して、エンティティの ID_Owner フィールドを ID_TELEPHONE に置き換えることができます。

Telephone
ID_TELEPHONE
NUMBER

Structure 
ID_STRUCTURE (PK)
ID_TELEPHONE (FK)

Customer
ID_CUSTOMER (PK)
ID_TELEPHONE (FK)

Organization
ID_ORGANIZATION (PK)
ID_TELEPHONE (FK)
于 2013-06-28T06:29:49.230 に答える