ER 다이어그램 결함

Question

다음과 같은 은행 데이터베이스의 ER 다이어그램이 있습니다 - 고객은 여러 계정을 가질 수 있으며 여러 고객이 공동으로 보유 할 수 있으며 각 고객은 계정 집합과 연결되며 계정은 하나 이상의 계정 세트. 어떤 디자인 규칙을 위반 했습니까? 어떤 수정을해야하며 그 이유는 무엇입니까?

지금까지, 나는 확실하지 않다 몇 가지 결함은 다음과 같습니다 AcctSets 엔티티에

1) 중복 소유자 주소 속성.

2)이 ER에는 주소가 다른 여러 소유자가있는 계정이 포함되어 있지 않습니다.

내 질문 : 분석에서 누락 된 이러한 결함 및/또는 다른 결함을 수정하는 방법은 무엇입니까? 감사!

Answer 1

은 내가 AccountSet 실체가 무엇 확실하지 않다.

고객 및 계정과의 관계가 많습니다. 따라서 하나 이상의 계정에 고객을 연결하는 CustomerAccount 엔터티와 하나 이상의 고객에게 계정을 필요로합니다.

CustomerAccount 
--------------- 
CustomerAccountKey 
CustomerKey 
AccountKey 

이 기업은 고객의 계정, 또는 AccountKey를 얻을 수있는 계정의 고객을 얻기 위해, 어느 CustomerKey에 액세스 할 것이다. CustomerAccountKey는 데이터베이스의 데이터를 클러스터링하는 데에만 사용됩니다.

CustomerAccount 엔터티의 CustomerKey - AccountKey 조합은 고유합니다.

고객에 대해 둘 이상의 주소가 필요하다면 고객 엔터티와 주소 엔터티 간의 일대 다 관계가됩니다. 이를 통해 고객은 하나의 실제 사례로서 여름 주소와 겨울 주소를 가질 수 있습니다.

Answer 2

추상화가 적용되는 이유가 명시되지 않았습니다. Account Sets. Customer과 Account 사이의 교차점이 필요합니다. 비즈니스 규칙이 여러 가지에서 많은 것을 말하지만 중재 추상화가 필요한 이유는 무엇입니까?

심지어 당신이 그것을 유지하는 가정, 속성 owner address는 Account 및 Customer (즉 Account Set) 사이의 추상화/교차 실체에 속하지 않습니다. 그것은 단지 의미가 없습니다. 고객 주소에 계정과 고객 간의 관계에 대한 기능적 종속성이 있음을 제안하는 것은 명시된 규칙이나 공통된 경험에 아무것도 없습니다. 무엇보다도 기능적으로 고객에게만 의존적입니다. 현재이 종속성을 다중 값으로 모델링하고 있기 때문에 주소가 완전히 기능적으로 고객에게 종속되어 있지는 않습니다. 그것을 놓을 수있는 유일한 3NF 장소는 Addresses 엔티티 유형입니다.

Addresses보다 나은 이름을 고려해야합니다. 먼저 엔티티 이름이 나타내는 객체의 이름을 지정해야합니다. 복수 명사를 사용하려는 충고에 저항하십시오. 엔티티 유형이 콜렉션이 아닙니다. 엔티티 유형을 구현하는 테이블은 엔티티 인스턴스의 콜렉션이 될 것이지만, 복수 명사 명명은 당신이 관계의 카디널리티에 대해 생각할 때 혼란을 일으킬 것입니다. 엔티티 유형 이름으로 Location을 제안하고 속성으로 address을 제안합니다. 당신이 개념적 수준을 넘어 서면 address은 거의 반드시 분해되어야 할 것입니다.

그 외에도 귀하는 귀하가 언급 한 비즈니스 규칙에 따라 꽤 좋은 길을 걷고 있습니다.