DATOR


키엔터티의 식별자 Data Modeling


키엔터티에 대한 식별자는 가끔 고민하는 부분입니다.

지금 진행하고 있는 프로젝트에서 키엔터티에 해당하는 사원, 상품에 대한 식별자를 무엇으로 지정할지에 관해 계속 논의하고 있습니다.

 

과연 업무상 사용하고 있는 사원번호를 식별자로 가지고 가는 것이 옳은 판단일까요?

공인기관에서 만든 ESN, 바코드 등을 상품의 식별자로 가지고 가는 것이 옳은 판단일까요?

 

한가지 예를 들어보겠습니다.

온라인쇼핑몰에서 고객엔터티를 설계하려고 합니다. 고객이 회원가입할 때 쓰는 고객ID는 식별자로 쓰기에 상당히 매력적입니다. 상품주문서나 게시글에 기재된 고객ID를 보고 누구나 고객을 구별할 수 있기 때문입니다.

하지만 고객ID를 식별자로 쓴 오픈마켓에서는 다음과 같은 문제가 발생했습니다.

어느 한 사용자가 고객ID를 해킹당하였습니다. 이미 해당 고객의 개인정보가 모두 유출되어 비밀번호를 변경하여도 다시 알아낼 수 있었기 때문에 비밀번호 변경으로는 문제를 해결할 수 없었습니다. 오픈마켓은 개인정보가 유출된 고객의 ID를 변경해야했지만 할 수 없었습니다. 모든 데이터들이 이미 관계때문에 만들어진 속성으로 다른 데이터에 다 들어 있었기 때문입니다. 고객엔터티를 설계할 당시에 고객ID는 무슨일이 있어도 변경될 일이 없을 것이라면 식별자를 써도 무방합니다. (※보안의 문제는 제외하겠습니다)

그러나 위와 같이 고객ID를 변경해야 하는 일이 발생할 경우에는 위의 예에서와 같이 매우 심각한 문제가 생길 수 있습니다.

 

다른 예를 살펴보겠습니다.(이와 같은 경우는 어떠할까요?)

병원에서는 환자의 고객번호 식별자로써 개인의 주민등록번호를 사용하였습니다. 하지만 병원에서 출생한 신생아의 경우 출생기록 등의 많은 데이터를 저장해야함에도 식별자로 사용하는 주민등록번호가 존재하지 않아 데이터를 저장하는데 많은 문제가 발생합니다. 따라서 임의로 번호를 채번하여 이를 고객번호로 하여 많은 데이터를 만들었습니다. 이후 시간이 지나 그 아이가 5살정도 되었을 때 다시 병원에 방문하여 다른 데이터를 만들어야 하는 경우 무엇을 식별자로 삼아가야 할까요?

아이의 주민등록번호로 고객번호를 새로 생성하고 그전에 있던 데이터들은 모두 변경을 해야 할까요?

아니면 처음 태어날 때 사용한 번호로 고객번호를 삼아야 할까요? 아니면 다른 고객으로 판단하여야 하나요?

 

또한 이런 경우도 있습니다.

어느 회사에서는 직원들에게 업무상의 고유의 번호를 부여합니다. 이 경우 업무상의 직원번호는 매력적인 식별자 후보에 올라 데이터 모델 설계시에 식별자로 확정하여 사용하고 있습니다. 그러나 직원번호 자릿수마다 의미를 부여하다보니 더 이상 새로운 직원에게 부여할 수 있는 자리가 없게되었습니다.

결국 회사측은 직원번호체계를 변경하기로 하였습니다. 이에 따라 그 시점에 새로 입사한 직원은 직원번호도 못 받는 일이 생겼습니다.

그런데 월급지급에 문제가 생겼습니다. 자녀가 있는 직원에게는 가족급을 주어야 하는데 직원번호가 없어서 데이터를 못넣었으므로, 해당 직원의 월급은 수동으로 계산하여 지급하여야 하니 인사팀에서 IT부서는 돈만 쓰는 부서라고 험담을 합니다. 또한 의미를 부여하여 사용하다보니 해당 직원의 직종이 바뀌어서 직원번호를 바꾸는 일이 발생을 하게 되자 모든 데이터를 변경해야 하는 문제가 발생하게 됩니다. 월말이 되면 직종이 변경되는 사람들이 10명정도 되는데 이 때문에 월말만 되면 IT부서는 데이터 변경하느라 너무 바쁩니다.

 

다른 한 회사에서는 들어오는 물품재고파악 식별자로써 상품 뒤에 찍혀있는 바코드를 사용하기로 했습니다.

번호를 일일이 부여하는 것 때문에 고민할 필요도 없고 있는 것이니 다들 아무 고민없이 쓰기로 정했습니다.

바코드는 그 자체로써 각자 구별이 되므로 특별한 문제 없는 듯 보입니다.

그러나 과연 무슨 문제가 발생할까요?

예를 들어 검정볼펜에 대해 수량 또는 재고관리를 할 경우 물품제조(또는 공급처)회사가 동일하거나 같거나 전체 수량에 대해서만 파악할 수 있습니다.

하지만 이제는 바코드로 물품관리를 하게 되니 바코드별로 검정볼펜의 수량을 관리해야 합니다.

그렇지 않으면 물품재고수량을 정확하게 파악할 수 없게 됩니다.

그리고 검정볼펜을 낱개로 사용하는 문제가 발생하니 바코드를 어찌 해야될까 고민합니다.

또한 각 부서간의 물품에 대해 신청을 받으려고 하는데 납품계약을 받기 전이라 신청을 못받는 일이 발생하게 됩니다.

 

바로 이와 같은 경우들로 인해 기업체 내의 IT부서들의 효용성은 평가절하됩니다.

 

제가 곰곰이 생각하다보니 원인은 예전부터 존재하던 종이문서에서 시작이 된것 같습니다. 아직도 문서로 업무를 처리하는 곳을 예로 들어 보겠습니다.

공장에서는 출고를 하기 위해 출고명세서를 관리 합니다. 출고명세서의 출고번호를 떠올려보면 ‘주문날짜 - 주문자번호 - 출고지번호 - 순번’ 이런 방식으로 되어 있습니다. 종이방식의 문서에서는 유용한 것이 업무를 하는 사람이라면 누구든지 이 출고번호를 보고 ‘이 날짜에 주문이 발생한 것이구나’ 라고 판단을 할수 있게 됩니다. 그리고 종이방식의 문서에는 표시해야 하는 정보가 많기 때문에 최대한 함축적인 방법으로 만들어내야 합니다. 그냥 의미뿐인 출고번호는 어떻게 보면 자리만 차지하는 골치덩어리가 될수 있습니다.

 

IT부서는 기관내에서 다른 부서를 지원하는 역할을 합니다.

따라서 우선 모델링 이전에 현실세계에서 정의되어 있는 것을 키엔터티에 식별자로 사용할 때에는 많은 고민이 뒤따라야 합니다.

현실세계는 변경을 불러올 수 있는 많은 요소들이 존재하고 그에 따라 위의 예와 같은 문제들이 발생할 수 있으며 그로 인해 업무상 강한 제약이 발생하게 됩니다.

다음으로 속성 무결성을 해치는 경우가 발생합니다.

속성 무결성이란 정의한 속성에 들어올수 있는 값의 집합인것이다. 단순하게 데이터타입만을 말하는 것은 아니라는 것입니다.

병원에서 태어난 신생아의 경우와 같이 누구에게나 당연히 부여되어 있는 것으로 여겼던 주민등록번호를 사용할 수 없을 경우 새롭게 채번한 채번번호를 쓰게 됩니다.

그렇다면 모두가 주민등록번호인줄 알았던 고객번호가, 모두가 바코드인줄 알고 바코드인식기롤 찍던 번호가 룰이 깨지게 되면서 상당히 많은 에플리케이션에 영향을 미치게 됩니다.

참... 슬픈 현실이 되어 버렸습니다.

 

그렇다면 어떻게 해야 할까요?

쇼핑몰의 경우 고객번호, 고객아이디로 가야하는 것이 옳습니다. 그렇다면 고객번호는 다른 테이블에 대해 관계를 갖는 속성으로 갖게 되니 변경시에도 영향이 적게 됩니다.

그리고 고객아이디는 전체 고객에 대해서 유일하다. 하는 것을 지키기위해 고객아이디에는 Unique한 인덱스를 생성해 주는 것이 옳은 표현입니다.

 

환자는 무의미하게 환자를 채번하고 주민등록번호는 따로 가지고 가는 것이 옳은 방안입니다. 다시 말씀드리지만 보안문제는 지금 문제와 별개입니다.

이렇게 된다면 주민등록번호가 없는 신생아, 외국인등에 대해서도 유연하게 대처가 가능합니다.

직원의 경우는 어떠할까요? 업무적인 직원번호, 그리고 무의미한 식별자를 따로 가지고 가면 직원번호가 없더라도 데이터를 넣는 것에는 문제가 없습니다.

또한 직원번호체계를 바꾼다고 인사부서에서 하더라도 IT부서에서는 한마디 해줄수 있습니다.

" 무슨 회의를 할려고 하세요? 알아서 바꾸시고 결과만 알려주세요. 바로 바꿔드릴께요 " 라고 할수 있습니다.

업무적인 직원번호 하나의 컬럼만 값을 바꾸면 되기 때문입니다.

물품의 경우는 어떠한가요?

역시 마찬가지 입니다. 유통회사와 같은 경우에는 바코드를 사용하는 경우도 있겠지만 사용하고자 하는 입장에서는 A사든, B사든 상관이 없습니다.

단지 검정볼펜은 검정볼펜일뿐입니다.

 

약간만 생각을 바꾸면 현재 하고 있는 일이 편해질수 있습니다. 기초적인 관점에서 접근해보면 식별자는 변경이 되지 않는 요소라는 것을 우리는 반드시 알아야 합니다.

모델링 이전에 정의되어 있는 데이터를 식별자로 쓸때 이 식별자가 변경될 가능성이 있는지, 부여받지 못하는 경우가 있는지를 반드시 확인해야 합니다.

 

우리는 이러한 개념이 녹아있는 데이터 모델을 어디서 볼수가 있을까요?

바로 가장 가까이에 있습니다. 바로 오라클에 있는 딕셔너리입니다.

오라클 딕셔너리 조회하다 보면 그러한 식별자는 없다라고 생각하실껍니다.

ALL_TABLES, ALL_TAB_COLUMNS 등은 모두 VIEW이지요. 즉 SQL덩어리 라는 것입니다.

그렇다면 바로 COL$, USER$ OBJ$등의 데이터를 보시면 PK값들은 모두 의미라고는 눈씻고 찾아봐도 의미라고는 하나도 없는 NUMBER타입의 숫자들만 있을 뿐입니다.

그래서 테이블명을 바꾸거나 컬럼명을 바꾸는 경우에도 상당히 빠르게 작동이 되지요. 지금 한번 $뷰를 조회해보시기 바랍니다.

 

TAG

Leave Comments


profile우리는 하나님을 믿는다. 다른 모든 것들은 데이터로 검증해야 한다. 

Recent Trackback