인조 식별자는 영어로 surrogate key, synthetic key, pesudokey, entitiy identifier, factless key, technical key 등 다양한 용어로 쓰이며 뭔가 인공적이고 가짜, 대용, 대체물이라는 어감으로 쓰인 것 같다. 그리고 이와 대비되는 용어로는 natrual key, business key 로서 자연스럽고, 비지니스와 직접적으로 연관된 어감이다.
인조식별자를 사용하는 이유는 서로 다른 PK를 가질 수 밖에 없는 엔티티를 통합할 때 이 2개의 PK를 복합키로 사용하게 되면 이후에 구현된 물리테이블은 해당 PK 2개를 인덱스로 쓰기 때문에 값을 수정할 수 없게 되어버리고, NULL값도 들어올수 없게 되어버린다.
그리고 이 PK 중 하나라도 변경하게 된다면, 이 키를 FK로 사용하는 다른 엔티티에도 영향을 미치기 때문에 해당 엔티티도 함께 고려해야되는 상황이 생긴다.이처럼 PK이자 FK인 키가 생기게 되면 뭔가 유연하지 못한 모델링이 되어버린다. 만약 징검다리 식으로 테이블 간의 의존성이 10개 20개 30개가 되어서 30개 테이블의 구조를 전부 바꿔야된다면 상상만 해도 끔찍하다.
이를 피하기 위해 새로운 인조키를 정의해서 다른 엔티티에 미치는 영향을 줄이고, 보다 유연한 논리모델을 설계할 수 있는 경우가 있다.
참고한 서적에 따르면 4가지 경우에 적용할 수 있다고 설명한다.
1. 엔티티를 통합할 때 통합 대상 엔티티 식별자가 서로 다르거나, 데이터 집합 단위가 다른 경우에 본질 식별자 대신 인조 식별자를 정의할 수 있다. <복잡한 본질 식별자 대체>. 참고서적에서는 법인(법인등록번호)와 개인(주민등록번호) 같이 집합단위가 다른 유형의 데이터를 통합할 때, 혹은 사업자(사업자등록번호)와 사업장(사업자등록번호, 사업자소재지) 과 같이 식별자 구조가 다를 경우, 새로운 인조식별자를 주는 예시를 소개하고 있다.
내 프로젝트의 논리모델링 중 게시글의 댓글 변경로그를 기록하는 테이블이다. user_id와 comment_id를 FK로 받아 PK로 쓰는 테이블이였는데, 이를 auto-increment 제약조건의 새로운 인조키인 내용변경_num으로 추가해서 로그번호로서 활용하고 있다. 이런 방식의 사용이 제일 쉽게 적용할만한 방식인 것 같다.
2. 여러 단계의 슈퍼-서브 엔티티가 있는 구조일 경우, 식별자를 계속 상속 받기 때문에, 하위엔티티로 내려갈수록 식별자 속성 갯수가 많아져서 복잡해지는데, 이를 단순화해서 물리 모델로 변환 했을 때, 개발이 편리해지고, 성능이슈를 해결하기 위해서 인조키를 사용할 수 있다. <복잡한 본질 식별자 상속 대체>
3. 개인정보 같이 암호화를 해야되는 속성의 경우 PK로 사용할 수 없는 경우가 있는데, 계좌, 카드, 주민번호정보 같은 경우이다. 이를 대체하는 계좌관리번호, 카드관리번호 같은 인조식별자를 사용하는 케이스다. <암호화 식별자 대체>
4. 서비스 중에 PK로 사용하는 속성에 대한 데이터가 들어오지 않았는데, 업무처리를 해야되는 상황이 있을 수 있다. (예시를 생각해보면, 서비스 중에 후불결제를 하게 되서 아직 결제에 대한 정보들을 받을 수 없는데 처리하는 경우도 있을 수 있겠고, 서적에서는 거래처의 사업자등록번호를 알지 못하는데 업무를 처리해야되는 경우를 예시로 든다.) 이 때 인조키를 사용하면 해당 값들을 NULL 처리 해두고, 나중에 값들을 넣어줄 수 있다. <초기 NULL값이 있는 본질 식별자 대체>
'Database' 카테고리의 다른 글
| 데이터 모델링 - 3. 논리 모델링 (0) | 2022.08.02 |
|---|---|
| 데이터 모델링 - 2. 개념 모델링 (0) | 2022.08.02 |
| 데이터 모델링 - 1. 이론 (0) | 2022.08.02 |
