私は実際にEER図を関係に変換するという考え方を頭に入れようとしています。私は単純な属性を関係に直接マップする必要があることを理解しています。私の問題は、コンポジット属性とマルチ値属性を扱うときに発生します。あなたはどちらかの新しい関係を作りますか？例えば、顧客エンティティは、名前、住所、および郵便番号を有することができる。 address属性には、street、city、state、およびaddressが含まれます。これは、新しいリレーションを作成するか、すべてのコンポーネントアトリビュートをカスタマリレーションにリストする必要があることを意味しますか？最後に、多値属性はどのように適切にマップされているのですか？EER図からの関係の形成
ありがとうございました。
多値属性は、ほぼ確実に別の関係に削除される方が良いです。それはファーストノーマルフォームと呼ばれ、1NFに違反する行為が正当化され得る例を見つけるためにかなり努力する必要があります。
複合属性の新しいリレーションを作成する理由はありません。カーディナリティとプライマリキーと候補キーへの依存性のために、属性を新しいリレーションに分割します。
コンポジットアトリビュートは、自然界には実際には存在しません。コンポジットアトリビュートは、概念的モデリング想像力の要素です。 OK、このステートメントは少し面倒です。要するに、概念モデルを物理モデルにした場合、実際のビジネス要件を決定することになります。複合アトリビュートがphyisically持続される細かさのレベルは、データをどのように使用するかによって異なります。封筒や出荷ラベルを印刷するアドレスをトラッキングする場合は、アドレス要素を2つの列に折り畳むことをお勧めします。一方、ビジネス要件ではアドレス要素分析が必要なので、住所の各部分をそれぞれの列に保持する方が理にかなっています。