^{BETTER WAY} 7 테이블 간 관계를 명확히 하자

이론적으로는 관련 컬럼의 데이터 타입이 같으면 테이블 간에 어떤 관계든 맺을 수 있다. 하지만 뭔가 할 수 있다는 이유만으로 반드시 해야 하는 것은 아니다. 그림 1-9에서 판매 주문 정보를 담는 데이터베이스의 스키마 다이어그램을 살펴보자.

언뜻 보았을 때 특별히 이상한 점은 없다. 테이블이 여러 개 있고 각 테이블은 단일 주제를 포함한다. Employees, Customers, Vendors 테이블에 집중해 보자. 이 세 테이블을 유심히 보면 테이블 간에 비슷한 컬럼이 많음을 알 수 있다. 이 세 테이블에 있는 데이터 자체는 유일하므로 비슷한 컬럼이 있다고 해서 문제가 되지는 않는다.

하지만 고객 일부가 공급처이거나 이 회사의 임직원이라면, 이 모델은 ‘BETTER WAY 2. 중복으로 저장된 데이터 항목을 제거하자’에서 살펴본 중복 데이터 규칙을 위반하게 된다. 모든 종류의 연락처 정보를 담은 Contacts라는 단일 테이블을 생성해서 이 난관을 극복할 수 있다고 생각하는 사람도 있을 것이다. 하지만 이 방법도 문제가 있다. 하나만 예를 들면 EmployeeID, CustomerID, VendorID는 이제 단일 기본키인 ContactID로 통합될 텐데, 해당 ID가 실제로는 고객이자 공급처인지 판별할 방법이 없다.

▲ 그림 1-9 판매 주문 정보 데이터베이스의 스키마 다이어그램