SQL에서 일대일 또는 하나의 관계 구현

일대일 (1-0..1) 관계가있는 시나리오를 위해 데이터베이스를 설계한다고 가정 해 봅시다. 예를 들면 다음과 같습니다.

• 사용자 집합이 있으며 일부 사용자 도 고객 일 수 있습니다 .

따라서, 나는이 개 해당 테이블을 생성 users하고 customers,하지만 ...

… 주어진 SQL 플랫폼에서 이러한 상황을 표현하고 구현하는 가장 좋은 방법은 무엇입니까? 가능한 두 가지 해결책을 고려했습니다.

1. 에서 users테이블, 추가 customer로 FOREIGN KEY 참조 이어도 열 customers또는 NULL마크.

2. customers테이블 에서 테이블 을 가리키는 user열 ( UNIQUE제약 조건으로 설정 )을 포함 users하십시오.

이미 일부 포럼에서 비슷한 질문을했지만 그 대답은 기본적으로 "필요한 것", "편리한 것"입니다. 나는 이런 종류의 대답을 좋아하지 않습니다. 대신 DB 이론의 진지한 부분을 원합니다. 1-0..1 관계는 어디에서 읽을 수 있습니까?

나는 DB 이론의 진지한 부분을 원한다

현대의 관계 이론 은 널 (null )을 거부 하여 옵션 1을 즉시 무효화하는 것처럼 보입니다. 그러나이 짚맨은 기본 널을 기본값으로 대체하여 제거 할 수 있습니다. 통신.

수정 된 옵션 1과 달리 관계가 6 번째 정규 형식 (6NF) 일 수 있으며 투영 결합 표준 형식과 달성 가능한 최고 표준 형식이기 때문에 옵션 2가 이론적으로 가장 좋습니다.

나는 또한 관계가 하나의 개체 또는 하나의 개체 사이의 관계를 모델링해야하지만 두 가지를 절대로 표현해서는 안된다는 설계 경험 법칙에 대해 들었다. 다시 말하지만, 이것은 옵션 2를 선호 할 것입니다. 그러나 몇 년 전이 경험에 대해 들었습니다. 위에서 언급 한 6NF 이외의 이론적 근거를 제시 할 수없는 곳을 기억하지 마십시오.

당신은 부분적으로 정답을 받았습니다. 실제 답변은 데이터 모델과 정규화 방법에서 비롯됩니다. 열쇠는 당신이 관계를 얻는 방법입니다.

• customers표 고려 다수의 필드로 구성 users하여 고객의 개념에 속하는 사용자는 고객 (사용자의 서브 타입)가 아니면 널 표. 이 경우 customers테이블 은 테이블에서 기본 키를 상속 users합니다. (겹치거나 겹치지 않을 수있는 여러 하위 유형이 가능합니다.)

• 이 customers테이블은 고객 개념과 관련된 여러 필드로 구성되지만 반드시 사용자 개념은 아닙니다. 고객은 강력한 테이블이며 사용자 개념에 의존하지 않습니다. ( users테이블을 제거해도 customers 테이블의 디자인에는 큰 영향을 미치지 않습니다.)이 경우 customers 테이블은 고유 한 기본 키를 얻습니다.

당신이 가진 것은 상한이 1 인 선택적 일대 다 관계의 특별한 경우입니다. 그렇다면 데이터를 리모델링해야합니다.

user-id외래 키를 customers테이블에 추가하는 것은 일대 다 (상한 1) 관계를 올바르게 매핑하고 널 입력 가능 필드를 피하므로 더 나은 선택으로 간주 될 수 있습니다. 상한값을 적용하려면 외래 키 인덱스가 고유해야합니다. 기본 키가 키인 경우 자동으로 발생합니다 user-id.

추가 customer-id받는 옵션 외래 키로 users테이블은 관계 (1)의 상한을 적용하지만 의존성을 반전시킵니다.

좀 더 복잡하지만 유연한 접근 방식을 고려해 보셨습니까? 부모 테이블은 "person"(또는 얼마나 복잡한 지에 따라 "entity")입니다. 그런 다음 customer 테이블과 user 테이블에는 person 테이블에 대한 FK가 있습니다. 개인 테이블에는 개인 세부 사항이 포함되고 고객 및 사용자 테이블에는 사용자 또는 고객과 연관된 속성 만 포함됩니다. 주소 (이메일 및 스 네일 메일), 전화 번호 등은 여러 대 상황을 허용하기 위해 매핑 테이블이있는 별도의 테이블에 표시되기도합니다. 여러 참조 사이트에서 찾을 수있는 비교적 일반적인 모델입니다.