2014-05-12 2 views
0

eye_colourhair_colour의 두 가지 특성을 가진 person 테이블이 있습니다. 내가 맞다면 DKNF로 정규화하고 싶다면 person_eye_colourperson_hair_colour의 2 개의 속성 테이블이 필요합니다. 각 테이블에는 원래 person_id에 대한 열과 속성 값에 대한 열이 있습니다. 다른 테이블 (. 예를 들어 hair_colour_value) 같은 ID를 매핑 할 때, 하나 개의 테이블 (말 hair_colour_version가) 값으로 ID를 매핑하는 것이다 : 나는 버전으로 hair_colour 속성을 원하는 경우DKNF 속성 버전 지정

그러나, 나는 두 개의 별도의 테이블에있을 필요가 ~ 값. 이 경우 person_hair_colour 테이블에는 색상 값 대신 hair_colour id이 필요합니다.

물론 다른 선택은 속성 값을 버전 화하지 않고 사람과 속성 간의 관계를 버전 화하는 것입니다. 별도의 person_hair_colour_valueperson_hair_colour_version 테이블을 만듭니다.

질문 : 위의 가정이 정확하면 어떤 버전 선택이 더 합리적입니까? 속성의 버전을 지정하거나 속성과 소유자 객체 사이의 관계를 변경해야합니까?

+0

"eye_colors"및 "hair_colors"가 눈에 대한 모든 유효한 값과 머리카락 색상을 각각 포함하는 추가 테이블을 기대하고 싶습니다. –

+0

예, 유한 값 세트가있는 속성을 선택하면 예제에 결함이 있습니다 (따라서 값은 ID가 될 수 있음). –

+0

"속성 테이블"에 "person_id"속성이 있기 때문에 예제에 결함이 있다고 말할 수 있습니다. –

답변

0

당신은 (Fagin 's) DKNF와 (Date 's) 6NF를 혼란스럽게 보입니다. 버전을 지정하는 경우 테이블이 항상 작은 테이블의 조인이 아니라는 6NF가 필요합니다. DKNF는 열 유형과 해당 키로 인해 테이블에 대한 유일한 제한 조건이 있음을 의미합니다. 특히 소스 테이블에 FK 대 대상 테이블이있는 경우 정의에 의한 소스 테이블은 DKNF에 없습니다. DKNF는 버전 관리 자체와 아무 관련이 없으며 5NF 및 6NF를 통한 정규화의 일부가 아닙니다.

'6NF'의 위키에서는 DKNF 6NF를 호출하기 때문에 혼란 스러울 수도 있습니다. 그러나 아무도 6NF DKNF를 요구하지 않습니다. 'Domain/key normal form'에 대한 wiki를 제외하고 다른 말도 안되는 것을 포함합니다. 그래서 당신의 버전 정보를 위해 다른 곳으로 가십시오.

어쨌든 예제에는 person_id 및 version 속성이 포함되어 있지만 명확하지 않습니다. 귀하의 옵션 표를 전체적으로 설명하십시오.