본문 바로가기
Data Modeling

속성 정련하기

by csk 2013. 7. 30.

오늘은 속성을 가다듬는 방법에 대해서 살펴보겠습니다. 


지금까지는 그저 각 테이블에 속한 정보를 나타내는 수준에서만 속성을 정해왔습니다. 그런데, 이렇게만 진행하다보면 전체적으로 봤을때 통일되지 않아서 부작용이 발생할 수 있습니다.


다음과 같은 상황일때 말이죠.


<그림1> 이름에 대한 개별적 설계 속성


직원의 성명은 10자리이고 고객의 성명은 20자리입니다. 게다가 한쪽은 ~명이고 한쪽은 ~성명이죠. 이렇게 되면 직관적으로도 같은 정보인지 인식하기 어려울 뿐 아니라, Query 문장에서 비교하는데에도 어려움이 발생할 수 있습니다. 

만약에 '홍길동'이라는 사람이 임직원이기도 하고 고객이기도 하다고 해볼께요. 한글 한글자가 3byte를 차지한다고 가정하면 직원에는 '홍길동 '이라 저장되고 고객에는 '홍길동           '이라고 저장됩니다. 이 둘을 비교하면 양끝의 space를 없애주는 trim 등의 함수를 쓰지 않는 이상 직원 홍길동과 고객 홍길동은 서로 같지 않다는 결과를 얻게 됩니다. 


이래서는 안되겠죠. 그래서 도메인(Domain)이라는 개념이 필요합니다. 도메인이란 대상이 가질 수 있는 값들의 집합을 의미하는데요, 쉬운 예를 들자면, 성별 이라는 속성의 도메인을 정한다면 {남, 녀} 가, 나이 라는 속성의 도메인을 정의한다면 {150? 이하의 자연수} 정도가 됩니다.


그럼 성명의 도메인은 어떻게 정할까요? 사람의 이름이 가질 수 있는 값들의 집합이니 매우매우 다양합니다. 이럴때는 일단 문자이다 정도로 정해지게 되구요. 길이는 아무래도 기존 속성들이 있으니 길이가 긴 쪽에 맞추게 됩니다. 사원명이 10이고 고객성명이 20이니 20으로 하는게 좋겠네요. 그리고, 앞서 비교의 문제를 해결하기 위해서 char 보다는 varchar를 사용해서 쓸데없는 space가 들어가지 않도록 하겠습니다.


그럼 도메인은 이렇게 정해지게 됩니다. 

  

도메인 의미 : 사람의 이름

도메인 타입 : VARCHAR(20)   


그럼 이제 이 도메인을 다시 해당하는 속성에 적용해주면 되는데요. 이 작업은 단어의 표준화 작업과도 밀접하게 연관되어 있습니다. 


예제를 다시 보면, 사원의 이름에는 '명' 이라는 단어를 사용했구요, 고객의 이름에는 '성명'이라는 단어를 사용했습니다. 둘 다 이름이라는 의미라고 한다면 같은 단어를 사용하도록 하는것이 시스템을 이해하기에도 좋고 업무를 진행하는데도 편리합니다. 


그럼 우리는 뭘로 할까요? 둘 다 큰 문제는 없는데, 저는 '성명'으로 정해 보겠습니다. 


도메인 명 : 성명  

도메인 의미 : 사람의 이름

도메인 타입 : VARCHAR(20)   


여기서 '성명'은 표준 단어이자, 분류 단어 입니다. 
표준단어란 이렇게 같은 의미를 갖는 여러 단어들 중에서 선정된 단어를 의미하구요, 그 중에서도 도메인과 매핑된 단어를 분류 단어 라고 할 수 있습니다. ( 표준단어니, 분류단어니 하는 부분은 프로젝트마다 사용하는 용어가 다를거라서 개념만 이해하시면 좋겠습니다. ^^) 

각 속성의 명은 선정된 표준 단어의 조합으로 만들어 쓰게 되는데요, 맨끝 단어는 반드시 분류단어 여야 한다는 규칙이 붙게 됩니다. 그래서, 사원(표준단어) + 성명(표준분류단어) 이런 식의 조합이 속성명이 되는거죠. 

분류단어로 끝나도록 해야 도메인이 각 속성에 확실하게 매핑되기때문에 이런 규칙을 적용합니다. 


그럼 최종적으로는 아래와 같이 속성이 정련됩니다.

<그림2> 이름에 대한 표준화된 속성 


추가적으로 고객의 이름을 성명이 아닌 고객성명으로 바꿔준 이유를 설명드릴께요 (안쓰려다가, 눈에 걸려서 쓰고야 마네요. ;-) ) 분류단어로만! 속성명을 정의하는것은 일반적으로 허용하지 않기 때문입니다. 성명은 성명인데 누구의 성명인지, 좀 더 구체화 해주어야 속성으로써 유용하기 때문에 한정하는 수식어를 한 개 이상 붙여주도록 합니다. 


오늘 설명드린 내용은 속성을 정련함에 있어서, 도메인을 결정하고 동시에 단어를 표준화해서 속성명을 보완하는 작업이었습니다. 오늘은 특히나 세부적인 규칙이나 용어등은 프로젝트마다! 사람마다! 다른 부분이 많을것 같습니다. 그러니 상세가아닌 전체적인 맥락과 개념 수준에서 받아들이시면 좋겠습니다.