어떤 사람들은 Contacts 테이블과 일대일 관계를 맺은 Customers, Vendors, Employees 테이블을 만들어서 해결할 수 있다고 여긴다. 이렇게 하면 ManagerID나 VendWebPage처럼 엔터티에 특화된 데이터를 다른 고객 로우와 분리해 유지하기가 쉽다는 장점이 있다. 하지만 이렇게 하면 이 데이터베이스 스키마를 사용하는 애플리케이션은 지금보다 훨씬 복잡해진다. 어떤 엔터티이고, 필요한 도메인 특화 데이터는 담았는지 확인해야 하기 때문이다. 결국 애플리케이션이 신규로 입력되는 데이터가 중복 데이터인지 확인하지 않은 채 입력을 허용한다면 추가 테이블은 아무짝에도 쓸모가 없을 것이다. 알다시피 모든 회사가 이런 추가적인 복잡성 문제를 해결하는 데 충분한 시간과 비용을 들이려고 하지 않는다. 공급처나 회사 임직원이 제품을 판매하는 회사의 고객이 될 리는 없으므로, 이렇게 드문 상황에서 가끔 발생하는 중복 데이터를 해결하는 것이 데이터베이스 스키마의 간소화에 비해 비용이 낮기 때문이다.

직원에게 판매 지역을 할당해야 하는 시나리오를 고려해 보면, 결론적으로 판매 지역을 기준으로 고객과 직원을 연결할 수 있다. Customers 테이블의 CustZipCode 컬럼과 Employees 테이블의 EmpZipCode 컬럼 간에 관계를 만드는 것도 이렇게 할 수 있는 한 방법이다. 이 둘은 같은 도메인에 있고 데이터 타입도 동일하다. 두 테이블 간에 관계를 생성하는 대신, Employees와 Customers 테이블의 ZIP 코드 컬럼으로 조인해서 어느 고객이 어느 직원 근처에 사는지 찾아낼 수도 있다.