공통코드 테이블 (Code Table) 설계하기

아무리 소규모의 시스템이라도, 데이터 모델에 코드 테이블은 존재합니다. 오늘은 이 코드들이 모여서 어떻게 공통코드 테이블로 만들어 지게되며, 이 공통코드 테이블은 어떤 특징을 가지는지 차분히 살펴보도록 하겠습니다.   

지금까지 자주 살펴본 초간단 쇼핑몰 시스템에도 여기저기 코드가 필요합니다.

<그림1> 모델에 나타나는 코드 성격의 컬럼

고객 테이블의 고객등급은 대표적인 코드 대상입니다. 

코드는 'VIP 등급' 대신에 'V'라는 한 글자를 쓰는것처럼, 매번 한글 또는 영문으로 쓰면 자리를 많이 차지하고 그 코드에 해당하는 데이터를 조회하는 SQL을 작성할때도 귀찮아지기 때문에 만들기 시작하는데요. 만들고 나면 코드로 정하지 않은 값들은 아예 들어가지 않도록 막아줄 수 있다는 꽤 괜찮은 장점이 추가 됩니다.

위 모델에 나타나는 코드 성격의 컬럼들은 이렇게 값들을 결정 할 수 있겠습니다.

<그림2> 각 컬럼들의 코드와 코드값 목록

이렇게 정의된 코드 데이터들은 별도의 테이블로 관리해서 코드 만 사용하도록 모델링합니다. 위 테이블을 사용해서 원래 업무 데이터를 담은 테이블 들을 단순하게 만들어 주기 위한 목적인거죠. 

<그림3> 코드 테이블을 설계 한 후의 모델

 

자 이제는 코드 테이블에 입력된 고객등급만 고객 테이블에 들어갈거고, VIP 등급 고객을 조회하려 할 때의 SQL도 단순하게 되었습니다.

그런데.... 두둥....

어라???.. 이건 좀..... 테이블이 너~무 많아졌지요? 

단순해 지기 보다는 몇 배 더 복잡해 보입니다. 

게다가 각 코드 테이블들은 데이터 건수가 참 변변찮게 작습니다. 그 건수가 늘어날 확률도 매우 낮구요. 고객등급 테이블은 현재 4건인데 앞으로 몇년간 많아져봤자 10개 등급 정도가 될테니까요. 

그럼 이 테이블들을 통합해서 하나에다가 담아두면 어떨까 이런 생각이 들게 되는게 당연합니다. ^^

이렇게 해서 발생하게 되는것이 공통코드 테이블 입니다. 코드와 코드값으로 구성된 다양한 코드들을 모아서 하나의 테이블에서 관리하는 것이지요.   

그런데 이렇게 모을때는 한가지 기준에 의해서 검토를 해야 합니다. 

컬럼이 추가될 일이 없어야 하는거죠. 코드와 코드값 이외에 추가적인 컬럼이 다양하게 필요한 경우는 이렇게 통합 해줄 수가 없습니다. 

예를들어 상품종류 테이블은 상품의 색상, 가격 등의 정보를 추가할 일이 생깁니다. 그럼 이 테이블들은 대상에서 제외됩니다. 그리고 필요한 컬럼들을 추가하면서 사실상! 더이상! 코드 테이블이 아닌 일반 테이블 化 하게 되는 수순을 밟게 됩니다. (아.. 처음부터 속성을 상품종류라 하지말고 상품 이라고 해야할것을... 실수했다는 느낌이 드네요. 그러나 밤이 늦어 앞에서 부터 수정하기에는....그냥 넘어가렵니다. 넓은 마음으로 이해를... ^^;;;;)

그럼 나머지 고객 등급이나 주문처리상태나 환송사유구분과 같은 코드들은 모아서 공통코드 테이블로 관리하게 되겠죠. 그럼 모델이 이렇게 바뀌어 좀 더 정리된 모습이 됩니다. 

<그림 4> 공통 코드 테이블 설계 후의 모델

위에서 보시듯, 공통코드 테이블은 태생 자체가 코드 성격을 가지는 많은 속성들을 모아서 설계한 것이기 때문에, 관계를 모두 맺어주자면 엄청나게 많은 관계가 생기게 됩니다. 그래서 일반적으로 공통코드 테이블은 가독성을 높이기위해 관계를 생략한다고 말합니다. 그래서 대부분의 ERD에서 섬처럼 떨어져 있는 패턴을 보이게 되죠.

흠.. 그런데 사실 여기에는 한가지 이유가 더 있다는걸 알게 되었습니다!!

공통코드 테이블을 구체적으로 설계해 보면 알 수 가 있습니다. 위에서 하나의 테이블인것 처럼 단순하게 그려놨지만 사실은 그렇지가 않습니다. 

공통적인 코드는 일단 코드의 이름이 달라야 등록할 수 있게 설계해야 합니다. 서로다른 여러 업무에서 코드를 모아놓을 것이기 때문에, 코드명 만으로도 무엇을 의미하고 어디서 쓰이는 코드인지 명확해야 비슷비슷한 코드들이 난무하는 것을 막을 수 있으니까요. 그럼 일단 코드명 만을 키로 가지는 테이블을 설계해야 합니다. 그리고 그 코드명을 기반으로 위에서 정의한 코드 별로 그에따른 값을 저장해 두어야 하겠지요. 

지금 설명한 내용을 모델로 그려보면 이렇게 됩니다.

<그림 5> 공통 코드 테이블의 실제 설계 모습

자 이제 다시 공통코드와 일반 테이블의 연결의 관점에서 생각해 보도록 하겠습니다. 주문이나 회원등의 비 코드성  테이블에서 필요한것은 '코드' 컬럼 뿐입니다. 그런데, 그림5의 모델에서 어느 것을 연결해도 코드 컬럼만을 FK로 받아 올 수가없습니다. 코드명까지 따라오기 때문에죠. 그리고 사실 공통코드명은 필요없는것이, 주문이나 회원 등의 일반 테이블에서는 코드가 FK로 전달된 그 컬럼의 속성명 자체가 이 코드가 어떤 코드인지를 나타내 주고 있기도 합니다.

그래서, 공통 코드 테이블의 관계를 표현하지 않는 것은 관계가 많아서 이기 때문이기도 하지만, 코드 컬럼만 상속받을 수는 없도록 되어있는 공통코드 테이블의 모델 구조상의 특징도 있다는 말입니다. 

오늘은 공통코드 테이블의 설계에 대해서 자세히 알아봤습니다. 쓰고보니 제가 조금 욕심을 내어 한번에 너무 많은 내용을 다루지 않았나 싶기도 하지만 이해하면 도움이 되실거에요. 이해가 어려우시면 질문을 남겨주세요. ^^