복합키 정리하기

오늘은 여러개의 속성이 모여서 식별자를 구성하고 있는 경우를 살펴보겠습니다. 

사족인데요,

음 이 말을 다시하면 여러개의 컬럼이 모여서 Primary Key를 구성하고 있는 경우를 살펴보자는 말이죠. 논리 모델과 물리 모델에서 사용하는 용어차이가 있다는 얘긴데요. 개인적으론 조금 고민입니다. 대체로 Database와 통용되는 물리모델의 용어에 더 익숙하실거라 그 용어를 사용해서 설명하고 대화하긴 하지만, 분석하는 입장에서 모델을 말하자면 사실 논리 모델 용어가 더 의미상 정확한 경우가 많거든요. 

흠.. 이래저래 저는 지금까지 섞어써왔을것 같네요. 이해를 위한 최선의 선택이었다는 변명을...;-)

예를들어 어느 보험회사의 보험계약내역 이라는 테이블의 키가 다음과 같이 구성되어 있다고 하겠습니다.

그림1. 보험계약내역 

총 다섯개의 컬럼이네요. 키 속성이 많아지면 분석하는 입장에서는 눈에 거슬리기 시작합니다.

일단 컬럼숫자가 너무 많거든요. 

보험계약내역 테이블 자체 보다도 이것과 관계가 있는 다른 테이블들이 그렇습니다.

예를들어 보험계약 번호가 바뀌는 경우 이 전후 컬럼을 관리하면 이렇게 됩니다. 

그림2. 보험계약내역 + 보험계약내역번호변경내역

복합키를 가진 테이블이 중요한 핵심 테이블일 경우 이러한 현상이 일파만파로 퍼져나가게 됩니다. 지금 예로든 보험계약 내역도 핵심 테이블인 경우구요.

그리고, 데이터를 조회하기 위한 SQL 문이 복잡해집니다. 보험계약내역과 다른 테이블을 join 하고자 할때, where 절에 5개의 조건이 기술되어야 할 경우가 매우 많을 테니까요.

그럼 어떻게 하는게 좋을까요? 

이럴때 생각할 수 있는것이 키를 인공적으로 만드는 것입니다. 위에 보셨던 다섯개 컬럼의 키는 업무가 그대로 드러나 있기 때문에 업무키 (Business Key) 라고 하구요, 이에 비해 앞으로 설명할 키를 인조키(Artificial Key)라고 합니다. 

음.. 인조키를 만드는 데는 대표적으로 두가지 방법을 생각해 볼 수 있습니다. 

하나는 비즈니스키를 이어붙여서 (concatenate) 하나의 컬럼으로 만들어 사용하는 것이구요,

만약 원래 컬럼들의 길이가 다음과 같다면요.

지점코드(4) + 팀코드(3) + 보험유형구분(1) + 계약연도(4) + 일련번호(4)

인조키의 킬이는 이렇게 되겠지요

보험계약내역식별번호(16)

다른 하나는 아예 시퀀스와 같은 충분히 긴 길이의 일련번호를 만들어 사용하는 겁니다. 

보험계약내역식별번호(10)

실제 데이터 예제는 이렇겠네요.

- 복합키  : "AAA" + "T10" + "3" + "2013" + "0130"

- 인조키1 : "AAAT10320130130"

- 인조키2 : "0000000240"

이제 하나의 컬럼이 키가되어 모델이 깔끔해 졌습니다. 보험계약내역 테이블 자체도 그 키를 Foreign Key로 가지고 있는 다른 테이블 들도 그렇지요. SQL 문을 작성해도 조건절 한줄로 join을 걸 수 있게 됐네요.

그럼 이제 모두 해피? ;)

그렇진 않습니다. 모든일에는 장단점이 있는데요. 인조키의 대표적 한계점 개별적 컬럼들이 의미 있는 조건인 경우가 많아 완전히 없애긴 어렵다는 것입니다. 

예제에서는 지점코드나 보험 유형이 조회를 위한 조건으로 빈번하게 사용된다는 점을 생각해 보면 이해하실 수 있을거에요. 보험유형을 조회 조건으로 사용하려면 하나의 컬럼으로 묶어버린 인조키에서는, substr 과 같은 함수를 사용해서 보험유형 부분을 잘라내서 비교해야 하구요. 이렇게 조건절에 키 컬럼에 대해 함수를 사용한 조건을 걸면 인덱스를 사용하지 않기 때문에 검색속도가 상당히 떨어집니다.

어쩔수없이 조회조건으로 많이 사용되는 컬럼은 추가로 가지고 있어야 합니다. 모든 내용이 조합된 인조키에 일부로 포함되어 있더라도 말이죠. 

그림3. 조회조건용 컬럼중복 설계

오늘은 복합키를 가진 테이블의 키를 재설계하는 방법을 살펴봤습니다. 도움이 되셨으면 좋겠네요.