가정하자 내가 두 강한 기업 E1과 E2는 E1 < --------- RER 다이어그램 데이터베이스 변환
많은 관계 R.에 1로 연결되어 -------- - E2
위의 ER 다이어그램을 데이터베이스로 변환 할 때 몇 개의 테이블이 생성됩니까?
나는 E2가 총 참가하게 될 때 대답이 2가 될 것이라는 것을 안다. E2의 기본 키가 완벽하게 합쳐질 것이기 때문이다. 나는 위에 확신하지 못한다. 나는 여러 장소를 보았고 다른 대답을 발견했다. 나는 대답으로 견고한 논증을 찾고있다.
답은 2 또는 3이 될 수 있습니다. 어느 것이 더 정확한지 알고 싶습니다.
Chen의 원래 방법은 모든 엔티티 관계와 관계 테이블을 별도의 테이블에 매핑합니다. 하나 E1 또는 E2에 의해
E1 (e1 PK)
E2 (e2 PK)
R (e2 PK, e1)
전체 참여 FK 제약 조건에 의해 처리 될 수있다 :이 세 테이블을 생성 할 것입니다.
여기서 알 수 있듯이 E2과 R은 같은 결정자/PK를가집니다. 이렇게하면 E2이 부분적으로 관계에 참여하는 경우 null이 허용되는 e1 열을 사용하여 두 관계를 하나의 테이블로 결합 할 수 있습니다.이 테이블이 완전히 참여하는 경우 null이 허용되지 않습니다.
E1 (e1 PK)
E2 (e2 PK, e1)
좀 더 정확 알고 싶어 :
E1으로 전체 참여는 여전히 FK 제약 조건을 필요로한다.
논리적으로는 두 가지 해결책이 거의 같습니다.
3 개의 테이블을 만드는 것은 개념적 (ER) 모델의 구조를 유지하지만 한 가지 방법으로 복잡성을 증가시키는 더 많은 테이블을 생성합니다. 반면에, 그것은 자신의 복잡성을 만드는 null을 피합니다.
2 개의 테이블을 만들면 테이블 수가 줄어들지 만 null이 발생합니다. 또한 단일 개념 (전체 참여)을 구현하기 위해서는 여러 메커니즘 (null 허용 열과 FK 제약 조건)을 사용해야합니다.
기타 요구 사항도 결정에 영향을 줄 수 있습니다. 50 개의 선택적 속성이 있다면 분명히 50 개의 별개의 테이블을 처리하고 싶지 않습니다! 그러나 R에 이미 참여하고있는 E2의 값에만 적용되는 다른 관계 (R2)를 만들려면 FK 제약 조건을 사용하는 첫 번째 디자인에서 해당 제약 조건을 적용 할 수 있습니다 : R2 (e2) referencing R (e2). 두 번째 디자인에서는 null이 아닌 e1 값을 갖는 e2에 대한 참조 만 허용하기 때문에 트리거를 사용해야합니다.
궁극적으로 정답은 없습니다. 개념적, 논리적 및 물리적 모델링은 서로 다른 관심사를 다루며, 아직 알려지지 않은 요구 사항은 모델에 영향을 미치고 의사 결정과 모순됩니다. 프로그래밍과 마찬가지로, 일을 단순하게 유지하고 리팩토링을 지속적으로 수행하고 최선을 기원합니다.