데이터베이스에서 상속을 어떻게 표현하나요?

Question

SQL Server 데이터베이스에서 복잡한 구조를 표현하는 방법을 생각하고 있습니다.

일부 속성을 공유하지만 기타 일반적이지 않은 속성이 많이 있는 일련의 개체에 대한 세부 정보를 저장해야 하는 애플리케이션을 생각해 보세요. 예를 들어, 비즈니스 보험 패키지에는 동일한 정책 기록에 책임, 자동차, 재산 및 면책 보장이 포함될 수 있습니다.

예를 들어 C#에서는 이를 달성하는 것이 간단합니다. 다양한 재정의 유형에 대해 필요에 따라 상속된 부분과 함께 부분 컬렉션을 포함하는 정책을 생성할 수 있기 때문입니다. 그러나 관계형 데이터베이스는 이를 허용하지 않는 것 같습니다.

두 가지 주요 옵션이 있습니다.

<올>

전략 테이블을 만든 다음 가능한 모든 변형에 필요한 모든 필드가 포함된 부분 테이블을 만듭니다. 대부분은 비어 있습니다.

각각 보험 유형에 해당하는 정책 테이블과 여러 부분 테이블을 만듭니다.

두 가지 대안 모두 만족스럽지 못한 것 같습니다. 특히 많은 조인이나 많은 Null 검사가 포함되는 모든 부분에 걸쳐 쿼리를 작성해야 하기 때문입니다.

이 시나리오에 대한 모범 사례는 무엇입니까?

Answer 1

세 번째 옵션은 "Policy" 테이블을 만든 다음 "SectionsMain" 테이블을 만들어 다양한 유형의 섹션에 공통된 모든 필드를 저장하는 것입니다. 그런 다음 일반적이지 않은 필드만 포함하는 각 섹션 유형에 대한 추가 테이블을 만듭니다.

어느 것이 가장 좋은지 결정하는 것은 주로 필드 수와 SQL 작성 방법에 따라 달라집니다. 그들은 모두 작동할 것입니다. 필드가 몇 개만 있는 경우 아마도 #1을 선택하겠습니다. "많은" 영역에 대해서는 #2나 #3을 선호합니다.

Answer 2

@Bill Karwin 그의 SQL Antipatterns 책에서 그는 SQL Entity Property Values 안티 패턴을 제안합니다. 간략한 개요는 다음과 같습니다.

단일 테이블 상속(계층 구조별 테이블 상속이라고도 함):

첫 번째 옵션처럼 단일 테이블을 사용하는 것이 아마도 가장 간단한 디자인일 것입니다. 앞서 언급한 것처럼 많은 하위 유형별 속성에는 해당 속성이 적용되지 않는 행에 NULL 값을 주어야 합니다. 이 모델을 사용하면 다음과 같은 전략 테이블이 생성됩니다.

으아악

디자인을 단순하게 유지하는 것이 장점이지만 이 접근 방식의 주요 문제점은 다음과 같습니다.

• 새 하위 유형을 추가할 때 이러한 새 개체를 설명하는 속성을 수용하도록 테이블을 변경해야 합니다. 이는 하위 유형이 많거나 하위 유형을 정기적으로 추가하려는 경우 빠르게 문제가 될 수 있습니다.

• 어떤 속성이 어떤 하위 유형에 속하는지 정의하는 메타데이터가 없기 때문에 데이터베이스는 어떤 속성이 적용되고 어떤 속성이 적용되지 않는지 강제할 수 없습니다.

• 적용해야 하는 하위 유형 속성에는 NOT NULL도 적용할 수 없습니다. 이를 애플리케이션에서 처리해야 하는데 이는 일반적으로 이상적이지 않습니다.

특정 테이블 상속:

상속 문제를 해결하는 또 다른 방법은 각 하위 유형에 대해 새 테이블을 만들고 각 테이블의 모든 공통 속성을 반복하는 것입니다. 예:

으아악

이 디자인은 기본적으로 단일 테이블 접근 방식으로 식별된 문제를 해결합니다.

• 이제 NOT NULL를 통해 필수 속성을 적용할 수 있습니다.

• 새 하위 유형을 추가하려면 기존 테이블에 열을 추가하는 것이 아니라 새 테이블을 추가해야 합니다.

• 속성 정책의 vehicle_reg_no 필드와 같이 특정 하위 유형에 부적절한 속성을 설정할 위험도 없습니다.

• 단일 테이블 방식처럼 type 속성이 필요하지 않습니다. 이제 유형은 메타데이터: 테이블 이름으로 정의됩니다.

그러나 이 모델에는 몇 가지 단점도 있습니다.

• 공용 자산은 하위 유형별 속성과 혼합되어 있으며 이를 식별하는 쉬운 방법이 없습니다. 데이터베이스도 모릅니다.

• 테이블을 정의할 때 각 하위 유형 테이블에 대한 공통 속성을 반복해야 합니다. 이건 절대 dry가 아닙니다.

• 하위 장르에 관계없이 모든 전략을 검색하는 것은 어려워지고 많은 노력이 필요합니다 UNION.

유형에 관계없이 다음을 통해 모든 전략을 쿼리해야 합니다.

으아악

새 하위 유형을 추가하려면 각 하위 유형에 대한 추가 UNION ALL를 사용하여 위 쿼리를 수정해야 합니다. 이 작업을 잊어버리면 응용 프로그램에서 쉽게 오류가 발생할 수 있습니다.

클래스 테이블 상속(일명 유형별 테이블 상속):

이것은 @David가 다른 답변 에서 언급한 솔루션입니다. 모든 공용 속성을 포함하는 기본 클래스에 대한 테이블을 만듭니다. 그런 다음 기본 키가 기본 테이블 역할도 하는 각 하위 유형에 대한 특정 테이블을 생성합니다. 예:

으아악

이 솔루션은 다른 두 디자인에서 발견된 문제를 해결합니다.

• 필수 속성은 NOT NULL을 통해 적용할 수 있습니다.

• 새 하위 유형을 추가하려면 기존 테이블에 열을 추가하는 것이 아니라 새 테이블을 추가해야 합니다.

• 특정 하위 유형에 부적절한 속성을 설정할 위험이 없습니다.

• type 속성이 필요하지 않습니다.

• 이제 공용 속성은 더 이상 하위 유형별 속성과 혼합되지 않습니다.

• 드디어 건조한 상태를 유지할 수 있게 되었습니다. 테이블 생성에는 각 하위 유형 테이블에 대한 공통 속성의 중복이 필요하지 않습니다.

• 정책 자동 증가 관리 id가 독립적으로 생성되는 각 하위 유형 테이블이 아닌 기본 테이블에서 처리할 수 있으므로 더 쉬워집니다.

• 하위 유형에 관계없이 모든 전략을 검색하는 것이 이제 매우 쉽습니다. 필요하지 않습니다 UNION - 只需 SELECT * FROM 策略.

대부분의 경우에는 테이블 형식의 접근 방식이 가장 적합하다고 생각합니다.

---

이 세 가지 모델의 이름은 Martin Fowler책 Enterprise Application Architecture Patterns에서 따왔습니다.