현재 회원 데이터에서는 이메일이 모두 달라 이메일을 키로 쓰자는 제안이 나왔습니다. 후보키를 정할 때 관찰한 데이터와 반드시 지켜야 할 제약을 어떻게 구분하나요?

함수 종속 X→Y는 현재 샘플에서 우연히 값이 하나였다는 뜻이 아니라, 같은 X를 가진 모든 유효한 행에서 Y가 하나로 결정된다는 도메인 제약입니다. 이메일이 지금 모두 다르더라도 업무상 이메일 중복 가입을 허용하거나 이메일 변경 이력을 여러 행으로 저장한다면 이메일→회원이라는 종속을 설계의 근거로 삼으면 안 됩니다. 후보키는 데이터가 우연히 유일한 속성이 아니라 시스템이 모든 유효한 상태에서 행을 식별한다는 규칙으로 정하겠습니다.

슈퍼키와 후보키를 계산합니다

슈퍼키는 행을 유일하게 식별하는 속성 집합이고, 후보키는 그중 어느 속성도 제거하면 슈퍼키가 아닌 최소 슈퍼키입니다. 기본키는 후보키 하나를 대표로 선택한 것이며 다른 후보키가 사라진다는 뜻이 아닙니다. 주어진 함수 종속 집합 F에서 속성 집합 X의 폐포 X+를 계산해 F를 반복 적용하고 모든 속성이 나오면 X가 슈퍼키인지 확인합니다. 각 속성을 하나씩 제거해도 전체 폐포가 나오는지 검사해 최소성을 확인합니다.

수강 테이블에서 (학생번호, 강좌번호)가 신청 행을 식별하고 학생번호→학생이름이 성립한다면 학생번호만으로는 강좌별 신청을 구분하지 못합니다. 수강생이 한 강좌를 한 번만 신청한다는 규칙이 있어야 복합키를 후보키로 둘 수 있습니다. 테넌트별 이메일 유일성이라면 이메일 단독이 아니라 (tenant_id, normalized_email)이 후보키 또는 대체 고유키가 됩니다. 시간에 따라 이메일이 바뀌는 회원 이력 테이블은 유효 기간까지 키 의미에 포함될 수 있습니다.

관찰 데이터와 보장 제약을 분리합니다

샘플에서 중복이 없다는 사실은 후보키 후보를 찾는 힌트일 뿐 증명이 아닙니다. 업무 담당자에게 유일성의 범위·기간·대소문자·정규화·탈퇴 후 재사용 규칙을 확인하고, DB의 UNIQUE, 부분/필터 인덱스, 외래키 등으로 실제 상태에 강제합니다. 시스템 생성 ID는 행 식별에는 유용하지만 이메일이나 학생번호의 업무적 유일성·변경 정책을 대신 설명하지 않습니다.

PostgreSQL·SQL Server·MySQL은 NULL, collation, filtered/partial index, generated column의 세부 동작이 다르므로 함수 종속을 코드 문서만으로 두지 않고 DB 제약과 테스트로 확인하겠습니다. 후보키가 정해지면 정규형 판정과 외래키 참조 대상도 안정됩니다. 반대로 잘못된 종속을 가정하면 2NF·3NF·BCNF 분해와 인덱스가 모두 흔들립니다. 검증은 정상 데이터뿐 아니라 같은 이메일의 동시 삽입, 테넌트 경계, 변경 이력과 소프트 삭제를 포함해 제약이 실제로 지켜지는지 확인하는 것입니다.

키를 바꿀 때는 식별자의 안정성도 함께 봅니다. 이메일은 사용자가 변경할 수 있고 외부 시스템·대소문자 규칙과 충돌할 수 있으므로 내부 불변 ID를 참조 키로 쓰고 이메일에는 업무상 필요한 별도 UNIQUE를 둘 수 있습니다. 이때 함수 종속은 테이블의 시간 모델과 일치해야 합니다. 현재 회원 테이블의 email→member_id와 이력 테이블의 (member_id, valid_from)→email은 서로 다른 관계이므로 하나의 키 규칙으로 합치지 않겠습니다.