나는 내 리그에서 벗어난 데이터베이스 디자인 문제를 우연히 발견했으며 DBA 전문가는 소방 훈련을 시작했습니다.
본질적으로, 나는 다음과 같은 기본 키 (간결하게 PK)가있는 테이블이 있습니다.
child_id integer
parent_id integer
date datetime
child_id
및 parent_id
엔티티 테이블에 대한 외래 키입니다. "자식"테이블 자체에는 "부모"테이블에 대한 외래 키도 포함되어 있으며, lo는 child_id
항상 parent_id
위의 테이블에서 예상 한 것과 동일 하게 참조 됩니다. 사실, 두 코드를 동기화시키는 여분의 코드가 있다는 것이 밝혀졌습니다.
이 과도한 열정적 인 정규화 초보자는 "이중화를 대신 제거해야합니다!"라고 말합니다.
나는 다음과 같이 분해한다.
Table_1 PK:
child_id integer
date datetime
Table_2 PK:
parent_id integer
date datetime
Table_3: (already exists)
child_id integer PRIMARY KEY
parent_id integer FOREIGN KEY
그리고이 사람들을 자연스럽게 합치면 원래의 테이블을 복구합니다. 이 5NF를 만드는 것은 내 이해입니다.
그러나 이제 숨겨진 비즈니스 규칙이 있음을 알고 있습니다.
일반적으로 주어진 날짜와 관련된 날짜는 해당와 관련된 날짜 child_id
의 하위 집합이어야합니다 parent_id
. 첫 번째 테이블이이 규칙을 적용 함을 알 수 있습니다.
날짜가 너무 커질 때까지 표 1에 자유롭게 추가 할 수 있기 때문에 분해시 규칙이 적용되지 않습니다.
다음 질문과 함께 여기로 연결됩니다.
이 분해가 5NF입니까? 삽입 예외가 허용되지만 Wiki 예제를 따르는 것 같습니다. 이 예제는 자체적 으로이 가이드를 따릅니다 . "강조 광산"이라는 문구는 " 세 가지 별도의 레코드 유형으로 구성된 정규화 된 양식에서 모든 실제 사실을 재구성 할 수 있습니다"라는 문구 는 특별한 일시 중지를 제공
Table_1
합니다.이 분해가 마음에 들지 않는다고 가정합니다. 실용적인 해결책은 테이블과 코드를 그대로 두는 것입니다. 그러나 이론적으로, 내가 첫 번째 테이블에서 멀리 얻을 수 있도록 및 분해 / 또는 제약 조건을 추가 할 수있는 방법이 와 내 비즈니스 규칙을 보존은?