상호 배타적 인 일대일 관계를 여러 개 갖는 것이 좋지 않습니까?

말, 테이블은 car테이블에 일대일 관계를 가지고 electric_car, gas_car하고 hybrid_car. A는 경우 car입니다 electric_car, 더 이상에 표시 할 수 없습니다 gas_car또는 hybrid_car등

그러한 디자인에 문제가 있습니까? 도로에서 발생할 수있는 몇 가지 문제?

여러 유형의 자동차는 데이터 모델링에서 계속해서 반복되는 일반적인 문제의 예입니다. ER 모델링에서는 "일반화 / 전문화", 객체 모델링에서는 "수퍼 클래스 / 서브 클래스"라고합니다.

객체 모델러는 객체 모델에 내장 된 상속 기능을 사용하여 문제를 매우 쉽게 해결합니다. 서브 클래스는 단순히 수퍼 클래스를 확장합니다.

관계형 모델러에 문제가 있습니다. 상속을 통해 얻을 수있는 이점을 모방하도록 테이블을 디자인하는 방법은 무엇입니까?

가장 간단한 기술을 단일 테이블 상속 이라고 합니다 . 모든 유형의 자동차에 대한 데이터는 자동차 용 단일 테이블로 그룹화됩니다. 단일 유형의 모든 자동차를 그룹화하는 car_type 열이 있습니다. 자동차는 하나 이상의 유형에 속할 수 없습니다. 열이 전기 자동차와 관련이없는 경우 전기 자동차 와 관련된 행에는 열이 NULL 로 남습니다 .

이 간단한 솔루션은 더 작고 간단한 경우에 적합합니다. 많은 NULL이 있으면 스토리지 오버 헤드에 약간의 비트가 추가되고 검색 오버 헤드에 약간의 비트가 추가됩니다. 부울 테스트가 널 입력 가능 컬럼에서 수행되는 경우 개발자는 SQL 3 값 논리 를 학습해야합니다 . 처음에는 당황 스러울 수 있지만 익숙해집니다.

클래스 테이블 상속 이라는 또 다른 기술이 있습니다 . 이 설계에는 gas_car, electric_car 및 hybrid_car에 대한 별도의 테이블이 있으며 이들 모두에 대해 결합 된 테이블 car가 있습니다. 특정 종류의 자동차에 대한 모든 데이터를 원할 경우 적절한 특수 테이블로 자동차 테이블을 조인합니다. 이 디자인에는 NULL이 적지 만 더 많은 참여를합니다. 이 기술은 더 크고 복잡한 경우에 더 효과적입니다.

공유 기본 키라는 세 번째 기술이 있습니다. 이 기술은 종종 클래스 테이블 상속과 함께 사용됩니다. 서브 클래스의 특수 테이블에는 기본 테이블로서 car 테이블에있는 해당 항목의 기본 키 사본이 있습니다. 이 ID 열은 기본 키와 외래 키 모두로 선언 될 수 있습니다.

여기에는 새 자동차를 추가 할 때 약간의 추가 프로그래밍이 필요하지만 조인이 간단하고 쉽고 빠릅니다.

수퍼 클래스와 서브 클래스는 실제 세계에서 항상 발생합니다. 두려워하지 마십시오. 그러나 초기 디자인의 성능을 테스트하십시오. 첫 번째 시도가 단순하고 건전한 경우 속도를 높이기 위해 조정할 수 있습니다.

모델링하려는 데이터의 현실을 반영하는 데 필요한만큼의 엔티티 하위 유형을 모델에 포함시키는 데 아무런 문제가 없습니다. 문제는 하위 유형이 나쁜 습관인지 여부가 아닙니다. 문제 수 있을이 그것입니다 좋은 모델 ?

예를 들어, 플러그인 하이브리드 인 Audi A4 eTron과 같은 작업을 어떻게합니까? "전기 자동차"입니까 아니면 "하이브리드 자동차"입니까?

당신이 스스로 물어봐야 할 다른 질문은 왜 당신이 전혀 타이핑을하지 않는 것입니까? 하위 유형에 몇 개의 구별 술어가 있습니까? 이 술어 중 하나가 하위 유형간에 공유되어 있습니까? 상황이 복잡해질 수 있습니다.

하위 타이핑은 데이터베이스 디자인에서 분류를 위해 사용되지 않습니다. 코드, 외래 키에서 코드 테이블로 또는 플래그로 분류 할 수 있습니다. 서브 타이핑은 다양한 유형의 관심 대상에 대해 고유 한 술어 세트를 모델링하는 데 사용됩니다. 분류를 위해 하위 유형을 사용하는 경우 나쁜 습관입니다.

하위 유형이 데이터베이스가 관심있는 대상에 대해 다른 술어 세트를 명확하고 명확하게 모델링하는 경우 필요한 하위 유형 수에 관계없이 완벽하게 권장됩니다.