2013-04-26 4 views
2

persons에 대한 정보가 들어있는 데이터베이스에서 spouse에 대한 정보를 표준화하는 가장 좋은 방법은 무엇입니까?자체 참조 속성 정규화

데이터가 포함되어 있습니다 : 나는 모든 persons (다른 배우자를) 간주하고 해당 행이 다른 personperson_id의 값을 갖는 경우 spouse을 구별하는 하나의 테이블을 유지 생각했다

person_id 
first name 
middle name 
last name 
phone number 
address 
vehicle 
house 
health 
destiny 
items 
spouse first name 
spouse middle name 
spouse last name 
spouse phone number 
spouse address 

. 이런 종류의 자기 참조가 권장 할만한가?

또한 데이터 반복을위한 테이블을 만들려고했습니다. health, vehicle

+0

난 당신이 참조 할 수있는'lead_id' 열을 볼 수 없습니다를 수정하는 것이 좋습니다. – J0e3gan

+0

실수를 저질렀습니다. –

답변

3

배우자 정보 정규화에는 spouse * 열 제거가 포함됩니다. 자체 참조 테이블을 원하면 person_id을 참조하는 spouse_id 열이 있어야합니다. 이름, 주소 및 전화 번호와 같은 모든 배우자 정보를 반복하지 마십시오.

개인 대 차량과 같은 일대 다 관계의 경우 네, person_id FK 열이있는 "many"끝 (예 : vehicle)의 표를 원할 것입니다.

또한 address을 자체 테이블로 분리하는 것이 좋습니다. 이 한 열에 주소의 모든 요소를 ​​저장하려는 경우 매우 비정규 화됩니다 (< 3NF).이 열은 별개의 열로 구분해야합니다 (예 : street, municipality, region 등). 그리고 이것들은 별개의 테이블에 있어야한다.

자체 참조 테이블을 권장합니까? 상황에 따라 다릅니다. 내 경험에 따라 데이터가 자연스럽게 나오는지 이해할 수 있습니다. 일반적으로 생각한대로 일반적인 "사람"시나리오가 적합하다고 생각합니다. 대조적으로 다소 고의적 인 "그림"시나리오 - 테이블 picture을 포함하여 of_picture_id 열을 포함하여 그림의 사진을 ... 포함합니다. ... (흠, 이제는 내게 그렇게 큰 소리로 들리지 않습니다 ...;하지만 잘하면 당신은 아이디어를 얻는다.)

3

배우자는 또한 "사람"이기 때문에 배우자의 세부 사항은 별도의 기록으로 캡처해야한다. 수행 할 수있는 유일한 방법은 spouse_id을 자체 참조 키로 도입하는 것입니다. 위 테이블은 사용자의 테이블에 다른 사람의 세부 정보가 포함되어 있기 때문에 정규화되지 않았습니다. 난 당신이 '사람'스키마를 다음과 같은 방법

person_id 
first_name 
middle_name 
last_name 
phone_number 
address 
vehicle 
house 
health 
destiny 
items 
spouse_id 
+0

몇 가지 이유로 (적어도 3NF까지) 정규화되지 않았습니다. 내가 설명한 몇 가지 이유가 있습니다. '배우자 *'를 없애고'spouse_id '를 추가하는 것은 거의 30 분 전에 분명했습니다. :) 질문은 또한'spouse_id'가 관련 될 것 같은 자기 참조 관계의 타당성에 관해 질문합니다. – J0e3gan

+1

오른쪽. 나는 이미 @ J0e3gan 대답을 upvoted했습니다. 내 요점은 수정 된 테이블이 어떻게 보일 것인가를 OP에게 명확히 밝히는 것이 었습니다. – Vineeth

+0

Clarity는 가치가 있으며, 적어도 'spouse *'및 'spouse_id'와 관련하여 열 목록이 명확하다는 것을 인정합니다. – J0e3gan

0
PARTY 
id 
name 

PARTY_RELATIONSHIP 
from_party_id not null references party(id) 
to_party_id not null references party(id) 
from_date not null 
to_date null 
primary key (from_party_id, to_party_id, from_date) 
check (from_party_id <> to_party_id)