sql 데이터베이스 : 2 열 (id 이름) 및 기본 키 2 개가있는 테이블 세 번째 표준 양식 보이스 코드 테이블 일반 양식

Question

다음 표를 상상해보십시오. 제 경우에는 name이 unique과 not null [unique + not null = 기본 키]가되어야한다고 완전히 확신합니다. 따라서 name은 기본 키입니다. 몇 가지 이유로 (아마도 습관에 의해), 나는 자연스럽게 int 타입의 기본 키 id 컬럼을 만들었습니다.

다른 가정 : 나는 절대적으로 내 테이블에 name을 유지해야하며 name (유형은 varchar)이 결코 20자를 초과하지 않을 것이라고 확신합니다.

내 첫 번째 질문은 [예 또는 아니오 예상되는 가까운 질문 일 가능성이 높습니다.] : 이러한 테이블을 만들면 BCNF Boyce-Codd 표준 양식을 존중합니까?

두 번째 선택형 질문 [아마도 공개 질문] :이 경우 열 id을 만드는 것이 좋습니다. 두 속성을 포함하는 관계가 BCNF에 항상 있지만

CREATE TABLE Y (
    id int, 
    name varchar(20), 
    PRIMARY KEY(id, name) 
    ); 

Answer 1

각 열이 고유 경우, 당신은 아마 여기

CREATE TABLE Y (
    id int primary key, 
    name varchar(20) not null unique, 
); 

또는

CREATE TABLE Y (
    id int not null unique, 
    name varchar(20) not null unique 
); 

FDS는 ID- 있습니다> 이름과 이름 -> ID를 원한다.

FD의 모든 화살표가 후보 키 밖의 화살표 인 경우 비공식적으로 BCNF를 만족하게됩니다. 그래서 이것은 BCNF를 만족시킵니다.

버릇이 아닌 대리 ID 열 을 만드는 것은 좋지 않습니다. 먼저 생각하고 트레이드 오프 및 부작용을 인식하십시오.

Answer 2

, 당신의 질문은 텍스트가 테이블 디자인과 일치하지 않는 답변을 조금 어렵다.

나는 첫 번째 질문에 대답하기위한 기초로 테이블 디자인을하는 경우 : 당신은 Y이 Y의 유일한 속성입니다 함께 유일한 키를 형성 두 속성 id 및 name을 포함하는 테이블을 생성, 그것은 항상 BCNF. (? 또는 키) 나는 당신이 name이 (관계형 모델의 핵심 측면에서) 고유한지 상태 당신의 텍스트 설명을 촬영하면

, 다음 하나는 대리 속성의 의미를 생각하는 id :

a. id도 키인 경우 FD는 id->name; name->id입니다. id 은 키이고 name은 키이므로 모든 FD는 왼쪽에 키가 있습니다. BCNF가 성취됩니다.

b. id이 자체적으로 키가 아니지만 name->id이 들어있는 경우 BCNF에서 (여전히 FD에는 LHS에 키가 있으므로)입니다. 비록 내가 이겠지만 추가 속성이 왜 id 인 지 이해할 수 없으므로 입니다.

중요한 것은입니다, 그러나, 데이터베이스 방식은 단순히 텍스트에 명시된 규칙을 준수하지 않는 : 당신이 id 1 차 키와 name 같은 고유 제한 조건이 있어야하기 때문에 (id, name)와 유일한 키를 단순히 잘못된 표현이다 (즉, 대체 키) 또는 그 반대의 경우. 그런 다음 BCNF에서 명확하게 나타나며 위에서 언급 한 옵션 (a)에 해당합니다.

BCNF의 질문이 아니라 "올바른 표현 체계"에 관한 질문입니다.