우리가 테이블 B와 일대일 관계를 갖는 테이블 A를 가지고 있다면, 그것들을 분리하는 것이 합리적입니까? 아니면 그것들을 단일 테이블로 결합하는 것이 결코 아프지 않습니까? 이 시나리오 중 하나 (두 테이블과 하나의 결합 된 테이블)가 일반적인 형식 (1NF, 2NF, 3NF 등)과 관련하여 어떤 영향을 미칩니 까?
답변:
예, 이것이 더 나은 디자인이 될 수있는 많은 이유가 있습니다.
상속 / 확장 관계가있을 수 있습니다. 예를 들어 User테이블과 Administrator필드가 더 많은 테이블이있을 수 있습니다. 두 테이블 모두 기본 키 사용자 ID (따라서 1 : 1 관계)를 가질 수 있지만 모든 사용자가 Administrator테이블에 레코드를 갖지는 않습니다 . 워크 플로우 (예 : ScheduledTask테이블 및 CompletedTask테이블)를 지원하는 경우 비슷한 것이 필요 합니다.
일반적으로 사용되는 데이터에 대한 간단한 테이블을 User만들고 자주 필요하지 않은 세부 사항에 대한 더 큰 테이블을 원할 수 있습니다 UserDetails. 단일 데이터 페이지에 더 많은 레코드를 넣을 수 있으므로 성능을 향상시킬 수 있습니다.
당신은 테이블, 예를 들어 서로 다른 권한을 할 수 User및UserCredentials
당신은 다른 백업 전략을 원하는 따라서 예를 들면 서로 다른 파티션에 두 테이블을 넣을 수 Transaction및TransactionArchive
단일 테이블에서 지원할 수있는 것보다 많은 열이 필요할 수 있습니다. 예를 들어 인덱싱해야하는 큰 텍스트 열이 많고 DB 플랫폼이 4K 데이터 페이지 또는 사용자 행동으로 제한되는 경우.
일대일 관계는 표 B의 관련 레코드를 선택적으로 사용 하려는 경우에만 의미가 있습니다 .
때때로 당신이 원하는 것은 변형 레코드 또는 Tagged Union 입니다. 즉, 서로 다른 정보를 포함하는 여러 테이블이 있지만 모두 일대일 관계로 테이블 A와 관련됩니다. 그런 다음 표 A의 필드를 기준으로 연결할 테이블을 선택하십시오.
예를 들면 다음과 같습니다.
type Transaction(The_Type: PaymentType := Cash) is record
Amount: Integer;
case The_Type is
when Cash =>
Discount: boolean;
when Check =>
CheckNumber: Positive;
when Credit =>
CardNumber: String(1..5);
Expiration: String(1..5);
end case;
end record;
비즈니스 모델링에서 비즈니스 관점에서 논리적으로 분리 된 두 엔티티 A와 B는 일반적으로 다른 테이블에 맵핑됩니다.
예를 들어, 객체 지향 수단으로 비즈니스 모델링을 수행 할 때는 일반적으로 일종의 객체 관계형 매핑이 있습니다. 객체 모델로 시작하여 그로부터 관계형 모델을 도출 할 수 있습니다. 따라서 객체 모델에서 클래스 A와 B를 만들었으나 객체는 1 : 1로 대응되지만 단일 책임 원칙 때문에 분리되어 있어야합니다 . 오브젝트 모델에서이 클래스는 속성이있는 테이블이 아니라 메소드로 구현 된 일부 동작과 함께 비즈니스 오브젝트를 나타낼 수 있습니다. 그리고 이러한 클래스를 이제 관계형 모델에 간단하게 매핑하면 1 : 1 관계로 별도의 테이블 A와 B가 제공됩니다.
필자의 경험에 따르면 비즈니스 또는 OO 데이터 모델을 만들 때 이러한 논리적 분리는 성능, 개별 보안 또는 파티셔닝과 같은 "물리적"이유보다 1 : 1 관계에서 훨씬 더 일반적입니다.