귀하의 사양에 대한 나의 해석에 따르면, 두 개의 서로 다른 (그러나 연결된 ) 수퍼 타입 서브 타입 구조 를 구현하는 방법을 찾고 싶습니다 .
앞서 언급 한 과제를 달성하기위한 접근 방식을 폭로하기 위해 and 라는 두 가지 고전적인 가상 엔티티 유형 을 발행하는 시나리오에 추가 하겠습니다.FooBar
비즈니스 규칙
다음은 논리 모델을 만드는 데 도움이되는 몇 가지 설명입니다.
A Foo is either one Bar or one CA Foo is categorized by one FooTypeA Bar is either one A or one CA Bar is classified by one BarType
논리 모델
그런 다음 결과 IDEF1X [1] 논리 모델이 그림 1에 표시됩니다 (그리고 Dropbox에서 PDF로 다운로드 할 수도 있음 ).
푸와 바 추가
나는 추가하지 않은 Foo및 Bar더 나은 모델 보이게하지만 더 표현하기 위해. 나는 그들이 다음과 같은 이유로 중요하다고 생각합니다.
따라 A와 B라는 이름의 속성을 공유하는 E이 기능은 제시 가의 subentity 유형 것을 별개의 (그러나 관련) 종류의 개념 , 이벤트 , 사람 , 측정 나는에 의해 표현 등, Barsuperentity 유형 차례로하다는 것을 하위 엔터티 유형의이며 Foo,이 D속성은 계층의 맨 위에 특성 을 보유합니다 .
C논의중인 나머지 엔티티 유형과 하나의 속성 만 공유 하므로 D,이 측면 은 다른 유형의 개념 , 이벤트 , 사람 , 측정 등의 하위 엔티티 유형이라는 것을 암시 하므로이 상황을 다음과 같은 이유로 설명했습니다 . 슈퍼 개체 유형.Foo
그러나 이것은 가정 일 뿐이며 관계형 데이터베이스는 특정 비즈니스 컨텍스트 의 의미를 정확하게 반영하기 위해 특정 도메인에서 관심 있는 모든 사항 을 식별하고 분류 하여 더 많은 의미를 포착 할 수 있도록해야합니다. .
디자인 단계에서 중요한 요소
모든 용어를 제외하고 배타적 인 수퍼 타입-서브 타입 클러스터는 일반적인 관계라는 사실을 알고있는 것이 매우 유용합니다. 다음과 같은 방식으로 상황을 설명하겠습니다.
- 각 독점적 슈퍼 엔티티 유형 발생은 하나의 하위 엔티티 유형 보완 에만 관련됩니다 .
따라서 이러한 경우 일대일 (1 : 1)의 대응 (또는 카디널리티)이 있습니다.
이전 게시물에서 알 수 있듯이 판별 기 속성 (구현시 열) 은 이러한 유형 의 연관 을 작성할 때 수퍼 타입이 연결된 올바른 하위 유형 인스턴스를 나타 내기 때문에 가장 중요한 역할 을합니다 . 마이그레이션 (I) 상위 유형에서 PRIMARY KEY의 (ii)는 하위 유형은 또한 주요 의미입니다합니다.
콘크리트 DDL 구조
그런 다음 위에 제시된 논리 모델을 기반으로하는 DDL 구조를 작성했습니다.
CREATE TABLE FooType -- Look-up table.
(
FooTypeCode CHAR(2) NOT NULL,
Description CHAR(90) NOT NULL,
CreatedDateTime DATETIME NOT NULL,
CONSTRAINT PK_FooType PRIMARY KEY (FooTypeCode),
CONSTRAINT AK_FooType_Description UNIQUE (Description)
);
CREATE TABLE Foo -- Supertype
(
FooId INT NOT NULL, -- This PK migrates (1) to ‘Bar’ as ‘BarId’, (2) to ‘A’ as ‘AId’, (3) to ‘B’ as ‘BId’, and (4) to ‘C’ as ‘CId’.
FooTypeCode CHAR(2) NOT NULL, -- Discriminator column.
D INT NOT NULL, -- Column that applies to ‘Bar’ (and therefore to ‘A’ and ‘B’) and ‘C’.
CreatedDateTime DATETIME NOT NULL,
CONSTRAINT PK_Foo PRIMARY KEY (FooId),
CONSTRAINT FK_from_Foo_to_FooType FOREIGN KEY (FooTypeCode)
REFERENCES FooType (FooTypeCode)
);
CREATE TABLE BarType -- Look-up table.
(
BarTypeCode CHAR(1) NOT NULL,
Description CHAR(90) NOT NULL,
CONSTRAINT PK_BarType PRIMARY KEY (BarTypeCode),
CONSTRAINT AK_BarType_Description UNIQUE (Description)
);
CREATE TABLE Bar -- Subtype of ‘Foo’.
(
BarId INT NOT NULL, -- PK and FK.
BarTypeCode CHAR(1) NOT NULL, -- Discriminator column.
E INT NOT NULL, -- Column that applies to ‘A’ and ‘B’.
CONSTRAINT PK_Bar PRIMARY KEY (BarId),
CONSTRAINT FK_from_Bar_to_Foo FOREIGN KEY (BarId)
REFERENCES Foo (FooId),
CONSTRAINT FK_from_Bar_to_BarType FOREIGN KEY (BarTypeCode)
REFERENCES BarType (BarTypeCode)
);
CREATE TABLE A -- Subtype of ‘Bar’.
(
AId INT NOT NULL, -- PK and FK.
X INT NOT NULL, -- Particular column.
CONSTRAINT PK_A PRIMARY KEY (AId),
CONSTRAINT FK_from_A_to_Bar FOREIGN KEY (AId)
REFERENCES Bar (BarId)
);
CREATE TABLE B -- (1) Subtype of ‘Bar’ and (2) supertype of ‘A’ and ‘B’.
(
BId INT NOT NULL, -- PK and FK.
Y INT NOT NULL, -- Particular column.
CONSTRAINT PK_B PRIMARY KEY (BId),
CONSTRAINT FK_from_B_to_Bar FOREIGN KEY (BId)
REFERENCES Bar (BarId)
);
CREATE TABLE C -- Subtype of ‘Foo’.
(
CId INT NOT NULL, -- PK and FK.
Z INT NOT NULL, -- Particular column.
CONSTRAINT PK_C PRIMARY KEY (CId),
CONSTRAINT FK_from_C_to_Foo FOREIGN KEY (FooId)
REFERENCES Foo (FooId)
);
이 구조를 사용하면 기본 테이블 (또는 relations ) 에 NULL 마크를 저장하지 않아도되므로 데이터베이스에 모호함이 생길 수 있습니다.
무결성, 일관성 및 기타 고려 사항
데이터베이스를 구현 한 후에는 (a) 각 배타적 슈퍼 타입 행이 항상 해당하는 서브 타입 대응 항목으로 보완되고 (b) 해당 서브 타입 행이 슈퍼 타입 판별 자 열에 포함 된 값과 호환되는지 확인해야합니다. . 따라서 TRANSACTIONS이러한 조건이 데이터베이스에서 충족되도록 ACID를 사용하는 것이 매우 편리 합니다.
데이터베이스의 논리적 건전성, 자기 표현성 및 정확성을 포기해서는 안됩니다. 이는 데이터베이스를보다 견고하게 만드는 측면입니다.
이전에 게시 된 두 가지 답변에는 데이터베이스 및 해당 응용 프로그램을 디자인, 작성 및 관리 할 때 고려해야 할 관련 사항이 이미 포함되어 있습니다.
VIEW 정의를 통한 데이터 검색
다른 supertype-subtype 그룹 의 열 을 결합 하는 일부 뷰를 설정하여 매번 필요한 JOIN 절을 작성하지 않고도 데이터를 검색 할 수 있습니다. 이러한 방식 으로 관심 있는 VIEW ( 파생 관계 또는 테이블 ) 에서 직접 쉽게 선택할 수 있습니다 .
보시다시피“테드”코드는 의심 할 여지없이 천재였습니다. 그가 맡은 도구는 매우 강력하고 우아하며 물론 서로 잘 통합되어 있습니다.
관련 자료
수퍼 타입-서브 타입 관계가 포함 된 광범위한 데이터베이스를 분석하려는 경우 @PerformanceDBA 에서 다음 스택 오버 플로우 질문에 제안한 특별한 답변 을 소중히 찾을 수 있습니다 .
노트
1. 정보 모델링 통합 정의 ( IDEF1X )는 1993 년 12 월 미국 표준 기술 연구소 ( NIST ) 에서 표준 으로 확립 한 권장 데이터 모델링 기법입니다 . 그것은 단단하게 기반으로 (a)는 초기 이론적 인 물질이 박사 EF 커드에 의해 작성된; 의 (b) 개체 - 관계 에 의해 개발 된 데이터의 뷰 박사 PP 첸 ; 또한 (c) Robert G. Brown이 만든 논리적 데이터베이스 디자인 기법. IDEF1X가 1 차 로직으로 공식화되었다는 점은 주목할 가치가 있습니다.