DoctorSchedule 테이블의 EquipmentID 컬럼과 부분적으로 겹치는 외래키가 두 개 있다는 점에 주목하자. 이 두 외래키 제약 조건은 어느 특정 장비에서는 유효한 의사와 검사실 조합만 선택할 수 있도록 보장해 프로그래밍 로직을 작성하지 않아도 되므로 데이터 이상을 방지한다. 여기서 테이블 설계를 변경하지 않은 점에 주목하자. 단지 관계만 변경했을 뿐이다.

다시 강조하지만 DoctorSchedule 테이블에 EquipmentID 컬럼이 필요하지 않았다면 그림 1-11의 스키마는 이미 제5정규화가 되었을 것이다. 따라서 예약 과정의 일부로 의사가 장비에 배정되었는지 확인하지 않고 의사를 검사실에 예약하기만 해도 되면, 그림 1-11의 첫 번째 스키마로도 충분할 것이다.

예제에서는 복합키를 사용한다는 점에 주목하자. 연결 테이블 OfficeEquipment와 DoctorEquipment에서 대리키를 생성했다면 EquipmentID 컬럼이 모호해졌을 것이므로 그림 1-12 모델에는 반영할 수 없었다. 따라서 기본 값으로 대리키를 사용한다면 해당 키가 스키마에 있는 핵심 정보를 잠재적으로 숨기는지 반드시 조사해야 한다. 다대다 관계에 참여하는 모든 외래키에 주목하고 분석해서 이들이 해당 관계에 어떤 영향을 주는지 확인해야 한다.