대리키 사용과 정규화

Question

정규화와 정규형을 생각할 때는 자연키를 사용한다는 것을 가정해야할까요? 예를 들어, 회원 테이블을 회원id (대리키), 아이디(자연키), 비밀번호, 이메일 속성으로 정의할 때, 회원id 는 아이디를 결정하고 (회원id -> 아이디), 아이디는 비밀번호, 이메일을 결정하므로 (아이디 -> 비밀번호, 아이디 -> 이메일) 이행함수 종속이 발생하는 것처럼 보입니다.   이처럼 정규화와 정규형을 생각할 때에는 대리키 개념을 배제하고, 자연키를 기준으로 생각해야할까요?

yh · Answer

안녕하세요. 강일모님 제3 정규형을 일반적으로 설명하다보니, 설명이 부족한 부분이 있었네요. 다음 내용을 메뉴얼에 보충해 두었으니 참고해주세요 🙂 감사합니다.   제3 정규형 심화: 후보 키와 이행 종속 여기서 실무에서 많이 헷갈려 하는 부분을 하나 짚고 넘어가겠다. member 테이블을 생각해 보자. member_id PK, login_id UK, password , email UK) 이 테이블에는 다음과 같은 종속 관계가 있다. * member_id → login_id * login_id → password , email 이 관계가 member_id → login_id → password 처럼 보여서 이행적 함수 종속으로 오해할 수 있다. 결론부터 말하면, 이것은 제3 정규형 위반이 아니다. "왜?" 제3 정규형이 막으려는 진짜 문제는, '키가 아닌 일반 속성' 이 '다른 일반 속성' 을 결정하는 상황이다. 앞선 orders_2nf 예시 order_id → member_id → member_name )에서는 member_id 가 orders_2nf 테이블의 키가 아닌 '일반 속성'이면서 member_name 이라는 '일반 속성'을 결정했기 때문에 문제가 되었다. 하지만 member 테이블의 login_id 는 '일반 속성'이 아니다. #### 후보 키 (Candidate Key) 데이터베이스에는 행을 유일하게 식별할 수 있는 여러 '키'들이 있다. * 후보 키 (Candidate Key) : 튜플(행)을 유일하게 식별할 수 있는 속성. * 기본 키 (Primary Key) : 여러 후보 키 중 대표로 선택한 키. member 테이블에서 member_id , login_id , email 은 모두 UNIQUE 하므로 행을 유일하게 식별할 수 있다. 따라서 이 셋은 모두 후보 키 다. login_id 는 '일반 속성'이 아니라 당당한 '후보 키' 자격을 가지고 있다. 키(후보 키)가 다른 속성을 결정하는 것은 지극히 정상적이고 바람직한 관계다. 따라서 login_id → password 관계는 후보 키가 일반 속성을 결정하는 것이므로, 제3 정규형에 전혀 위배되지 않는다. 이 테이블은 이미 제3 정규형을 만족하는, 잘 설계된 테이블이다.

communityai8509 · Answer

안녕하세요, 인프런 AI 인턴입니다. 강일모님. 정규화와 정규형을 고려할 때 대리키와 자연키 사이의 관계와 역할에 대해 궁금하신 점이군요. 데이터베이스 설계에 있어 정규화는 데이터 중복을 최소화하고 데이터 무결성을 확보하는 중요한 과정입니다. 대리키와 자연키 모두 이 과정에서 중요한 역할을 합니다. 정규화 과정을 통해 우리는 함수적 종속성을 분석하고, 그에 따라 테이블을 분리하여 데이터 중복을 최소화하는 방식으로 테이블을 정의합니다. 여기서 함수적 종속성은 대리키나 자연키 모두에 적용될 수 있습니다. 일반적으로, 데이터 무결성과 일관성을 유지하기 위해 대리키를 사용하는 것이 표준화된 접근 방식입니다. 대리키 사용 시 : 회원 ID와 같은 대리키는 시스템 내에서 고유하게 행을 식별하는 데 사용됩니다. 이는 변화 가능성이 없는 고유 식별자를 제공하므로, 데이터의 무결성과 효율성을 유지하는 데 유리합니다. 자연키 사용 시 : 자연키는 비즈니스 로직이나 의미 있는 데이터를 기준으로 행을 식별합니다. 하지만 이 경우, 자연키가 변경될 가능성이 있거나 여러 속성으로 구성된다면 함수적 종속성이 복잡하게 형성될 수 있습니다. 따라서, 정규화 과정에서 대리키를 사용하는 것이 일반적으로 권장되며, 자연키는 유니크 제약 조건(UNIQUE CONSTRAINT)을 통해 유일성을 보장하는 열로 관리하면 좋습니다. 이러한 유니크 제약을 통해 자연키는 여전히 비즈니스 로직에서 중요한 역할을 할 수 있습니다. 관련 내용에 대해 더 많이 알고 싶으시다면 아래의 유사한 질문과 답변을 참고하시면 도움이 될 것입니다: 대리키와 복합키 관련하여 질문 있습니다. 저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.