銀行データベースの次の ER ダイアグラムがあります。顧客は複数の口座を持っている場合があり、口座は複数の顧客によって共同で保持されている場合があり、各顧客は口座セットに関連付けられており、口座は 1 つ以上の口座セットのメンバーです。どの設計規則に違反していますか? どのような変更を行う必要があり、その理由は何ですか?
これまでのところ、よくわからないいくつかの欠陥は次のとおりです。
1) AcctSets エンティティの冗長な所有者アドレス属性。
2) この ER には、複数の所有者が異なる住所を持つアカウントは含まれません。
私の質問は次のとおりです。これらの欠陥および/または分析で見逃している可能性のあるその他の欠陥を修正するにはどうすればよいですか? ありがとう！
あなたは抽象化を持っている理由を述べていませんAccount Sets。あなたのビジネスルールは多対多を言っているので、Customerとの間の交差点が必要ですが、なぜ介在する抽象化があるのですか？Account
あなたがそれを保持していると仮定しても、属性はとowner addressの間の抽象化/交差エンティティに属していません（すなわち）。それは意味がありません。記載されているルールにも一般的な経験にも、顧客の住所がアカウントと顧客の関係に機能的に依存していることを示唆するものはありません。どちらかといえば、それは機能的に顧客だけに依存するでしょう。現状では、この依存関係を複数値になるようにモデル化しているため、アドレスは完全に機能的に顧客に依存しているわけではありません。それを置く唯一の3NFの場所は、エンティティタイプになります。AccountCustomerAccount SetAddresses
よりも良い名前を検討する必要がありAddressesます。まず、エンティティは、それらが表すオブジェクトにちなんで名前を付ける必要があります。複数名詞を使用したいという衝動に抵抗してください。エンティティタイプはコレクションではありません。エンティティタイプを実装するテーブルはエンティティインスタンスのコレクションになりますが、言うまでもなく、複数形の名詞の命名は、関係のカーディナリティについて考えるときに混乱を招くだけです。Location属性として、エンティティタイプ名として提案しaddressます。概念レベルを超えると、addressほぼ確実に分解する必要があります。
それ以外は、引用したビジネスルールに基づいて、かなり順調に進んでいます。
AccountSet エンティティが何をするのかわかりません。
顧客およびアカウントと多対多の関係があります。したがって、顧客を 1 つ以上のアカウントに関連付ける CustomerAccount エンティティと、アカウントを 1 つ以上の顧客に関連付けるエンティティが必要です。
CustomerAccount
---------------
CustomerAccountKey
CustomerKey
AccountKey
このエンティティは、CustomerKey によってアクセスされて顧客のアカウントを取得するか、AccountKey によってアクセスされてアカウントの顧客を取得します。CustomerAccountKey は、データベース上のデータをクラスター化するためにのみ使用されます。
CustomerAccount エンティティの CustomerKey - AccountKey の組み合わせは一意です。
顧客に複数の住所が必要な場合、それは Customer エンティティと Address エンティティの間の 1 対多の関係になります。これにより、実際の例の 1 つとして、顧客は夏季の住所と冬季の住所を持つことができます。