편집 : 다른 속성의 값에 따라 적용되는 변수 속성에 대한 설명은 비 관계형이며 비 정규화 된 디자인입니다. RDBMS는 이러한 종류의 데이터를 저장하는 최상의 솔루션이 아닐 수도 있습니다. 아마도 RDF는 이러한 유연성 수준을 요구하는 데이터를위한 좋은 솔루션이 될 것입니다. Entity-Attribute-Value 디자인
어떤 사람들 모델 유연한 특성, 그러나 이것은 종종 너무 구조화 그리고 당신은 데이터 무결성 문제와 싸우고 결국 :
내 이전 대답은 RDBMS 솔루션에 관한, 다음과 같습니다. 사실상 무한한 수의 엔티티 하위 유형이 필요한 경우에만 이것을 사용하십시오.
다른 사람들은 모든 하위 유형에 사용 된 모든 속성 열을 하나의 매우 넓은 테이블에 넣고 그 속성이 하위 유형과 관련이없는 행에 NULL을 남겨 두는 Single Table Inheritance을 사용합니다. 그러나 테이블이 너무 커질 수 있고 모든 속성을 필수로 만들 수 없기 때문에이 제한이 있습니다. 왜냐하면 모두 null을 허용해야하기 때문입니다.
상대적으로 적은 수의 엔티티 하위 유형이있는 경우 필수 속성의 각 그룹에 대해 종속 테이블을 만드는 것이 좋습니다. 종속 테이블의 기본 키를 상위 테이블에 대한 외래 키로 정의하여 일대일 관계를 얻습니다.
상위 테이블의 기본 키에 하위 유형을 인코딩하여 데이터 무결성을 조금 더 제공 할 수도 있습니다. Automobiles의 행이 Vehicles에 오토바이를 참조 할 수 없도록해야합니다.
CREATE TABLE Vehicles (
vehicle_id INT,
vehicle_type VARCHAR(10),
...attributes common to all vehicles...
PRIMARY KEY (vehicle_id, vehicle_type),
FOREIGN KEY (vehicle_type) REFERENCES VehicleTypes (vehicle_type)
);
CREATE TABLE Automobiles (
vehicle_id INT,
vehicle_type VARCHAR(10) CHECK (vehicle_type = 'Automobile'),
...attributes specific to autos...
FOREIGN KEY (vehicle_id, vehicle_type)
REFERENCES Vehicles(vehicle_id, vehicle_type)
);
은 물론, 새 종속 테이블을 새 하위 유형을 정의 할 때마다 작성해야하지만,이 디자인 등등 데이터 무결성, NULL NOT 속성을 적용 할 많은 당신에게 더 많은 구조를 준다, 그리고 .
= '자동차'인 Vehicles의 각 행에 Automobiles 행을 만들어야한다는 점만 애플리케이션 논리에서 적용해야합니다.