본문 바로가기

데이터 Story/데이터 표준

테이블 명을 정하는 방법

엔터티 명을 정하는 것은 사실 매우 어렵습니다. 상황에 맞는 수 많은 방법을 정해 놓고 따라야 해서 쉽지 않습니다. 그래서 논란이 많은 부분이기도 합니다. 엔터티 명만 정말 잘 정해도 좋은 모델러라고 할 수 있습니다.

 

반면에 테이블 명을 정하는 방법은 간단합니다. 대개 두 가지 방법 중에서 하나를 택해서 사용합니다. 방법을 결정하는 것은 대개 DBA가 합니다. 테이블 명은 DB 오브젝트에 포함되는데 전체 오브젝트를 감안해야 하기 때문에 DBA가 큰 틀을 정하는 것이죠.

 

차세대 프로젝트에서도 대개 DBA 쪽에서 테이블 명을 정하는 규칙을 정합니다. 이 과정에서 DA나 모델러에게 조언을 구하기도 하지만, 그렇지 않은 경우도 많죠.

 

테이블 명을 정하는 방법은 크게 두 가지입니다. 하나는 영역별 번호를 사용하는 것이고, 다른 하나는 영문 약어를 사용하는 것입니다.

 

다들 너무 잘 아실텐데 이 글에서는 두 번째 방법의 문제점에 대해 설명하고, 아무래도 개발을 하지 않는 필자의 입장에서 뭔가 빠트리는 것이 있는지 의견을 구하고 싶습니다.

 

번호를 사용하는 방법도 다양할 수 있지만, 대개 아래와 같은 방법을 많이 사용합니다.

 

T(오브젝트약어) + CS(영역약어) + 번호(영역별 순번)

 

맨 앞의 ‘T’‘X(인덱스)’‘V()’ 등 다른 오브젝트와 구분하기 위해 필요할 것이라 생각됩니다. 하나의 SQL 안에도 테이블, 인덱스, , Alias, Synonym 등 다양한 유형의 이름이 사용될 수 있는데 구분이 되면 좋을 것이고, 목록 등에서도 구분하기 편할 것입니다. 테이블 명이 길어지는 것은 피해야 하지만 한 글자 추가되는 것이라 영향이 미미할테고요.

 

두 번째 영역 약어를 사용하는 것도 큰 이견은 없죠. 두 글자가 추가됐지만 테이블의 오너십과도 연관되고, 큰 단점이 없기 때문에 사용하는 게 좋을 거 같습니다.

 

이 방법을 사용할 때만 해당하는 것은 아니며, 이슈 또한 아니지만 생각해야 할 게 영역이 무엇을 의미하는지입니다. 데이터 주제영역으로 모델링 되는 경우는 매우 드물어서 이 영역 약어는 AP 영역의 약어가 됩니다.

 

끝에 붙는 번호는 순번으로 붙입니다. 의미가 없다는 것이죠. 영역별 엔터티가 1,000개가 넘는다면 4자리여야 되고 그렇지 않다면 3자리 정도면 되고요. 간혹 번호에 나름의 체계를 사용하기도 하는데 큰 의미 없어 보입니다.

 

위 방법을 사용할 때 맨 뒤에 기본등의 엔터티 유형을 의미하도록 ‘BS’ 등을 추가하기도 하는데 아래에서 사용할 방법과 연관된 단점이 있습니다. 또한 이 방법을 사용하는 이유는 테이블 명을 길지 않게 하려는 것도 있기 때문에 대개 뒤에 다른 걸 붙이지는 않습니다.

 

이렇게 테이블 명을 정하면 고객(또는 고객기본)’ 엔터티는 ‘TCU0001’ 등이 됩니다. ‘고객서비스변경요청진행상태이력엔터티는 ‘TCU0101’ 등이 되겠죠.

 

두번째 방법은 오늘 집중적으로 논할 방법입니다. 대략 아래와 같이 사용합니다.

 

T(오브젝트약어)_CU(영역약어)_CUST(영문약어)_BS(유형)

 

위와 같이 사용하는 이유는 하나입니다. 테이블 명을 보고 어느 정도 이해할 수 있게 하기 위함입니다.

 

이 방법은 우선 구분자(“_”)가 있다는 게 다릅니다. 표준용어인 영문 약어를 사용하기 때문에 단어 사이에 구분자가 있어야 이해할 수 있게 됩니다. 자리수를 줄이가 위해 앞 글자만 대문자를 쓰는 것으로 구분하기도 하지만 많이 불편합니다. 컬럼 명을 붙이는 것과 유사합니다.

 

이처럼 테이블 명을 정하면 테이블명이 매우 길어질 수 있어 T_CUST_BS, CU_CUST_BS, T_CUST_BS, CUST_BS, CUST 또는 TCU_CUST 등처럼 다양한 변형이 있지만, 핵싱은 표준용어인 영문 약어를 사용한다는 것입니다.

 

이 방법을 사용하는 이유는 테이블 명을 보고 바로 이해할 수 있도록 하기 위한 것이라 표준용어 자리에 임의의 영단어를 사용하는 것은 의미가 없습니다. 그 약어가 무엇을 의미하는지 붙인 사람만 안다거나 사람마다 의미를 다르게 받아들인다면 애초의 의도에 혼란을 보텐 거라 바람직하지 않습니다.

 

따라서 메타에 등록된, 고객이란 단어에 해당하는 표준어의 영문 약어를 사용해야 됩니다. 엔터티 명과 테이블 명이 연동되는 것입니다. 둘 사이가 강 결합인 상태죠. 강 결합(Tightly Coupled)인 것을 약 결합(Loosely Coupled)으로 관리하면 문제가 생길 수 있고, 약 결합인 것을 강 결합으로 관리하면 커다란 문제가 생깁니다. 엔터티 명과 테이블 명은 약 결합이어야 하는 사이입니다.

 

이 방법의 첫 번째 문제는 테이블 명이 길어진다는 것입니다. 엔터티 명이 여러 단어로 구성되는 경우는 흔합니다. 보통 단어의 영문 약어가 2~4 글자이므로 5 단어로 구성된 테이블 명을 위와 같이 붙이면 38자리 정도까지 됩니다. ‘고객서비스변경요청진행상태이력엔터티 경우에는 40 글자는 너끈하게 넘깁니다.

 

DW 테이블은 엔터명이 심하게 길어질 수 있고, 인덱스 명까지 고려하면 DB에 거부당할 수도 있습니다. DB가 허용해도 알아보기 쉽게 하려 이 방법을 사용하는데, 평균 20자리 정도가 될 터이블 명이 보기도 싫어지는 게 아닌지 모르겠습니다.

 

DB에서 허용하지 않는 긴 테이블 명을 처리할 방법은 두 가지입니다. 엔터티 명을 임의로 줄이든지, 복합어를 만드는 것입니다. 전자는 당연히 바람직하지 않습니다. 후자인 복합어 문제는 길게 쓸 내용이라 자세한 설명은 생략하겠지만, 운영 중에 생기는 복합어는 어쨌든 바람직하지 않습니다.

 

’, ‘등의 한글자 단어는 표준어가 아닐 수 있는데 엔터티 명에는 자주 사용되는 단어입니다. 영문 약어가 없으니 당연히 표준화를 할 수 없는데, 이 때도 역시 복합어를 만들어서 해결할 수 있죠. 고객별이란 복합어를 만들고 영문 약어를 CUSTBY 정도로 등록해 사용합니다. ‘~이 필요할 때마다 복합어를 만드는 것입니다.

 

본격적인 내용은 지금부터인데 글이 길어지네요.

 

고객엔터티의 테이블 명을 ‘T_CU_CUST_BS’와 같이 사용하는 두 번째 방법의 가장 큰 문제점은 엔터티 명이 바뀔 수 있다는 것입니다. 엔터티 명이 바뀌었다고 테이블 명을 바꿀 수 없다는 게 문제입니다. 소스를 바꿀 수 없기 때문이죠.

 

개발 중에는 카리스마 있는 PM 때문에 엔터티 명에 맞게 테이블 명도 바꾸고, 소스를 수정하도록 할 수 있을지 모겠지만 운영 중에는 불가능한 상황입니다. 개발 중이라도 현실적으로 그렇게 할 정도의 카리스마가 있는 PM은 없을 듯 합니다.

 

엔터티 명은 자주 바뀔 수 있습니다. 특히 차세대 개발 기간 중에는 꽤 바뀌게 됩니다.

 

엔터명이 바뀌는 이유는 대략 아래와 같습니다.

 

-분석/설계 단계에서 업무 요건이 명확하지 않아 엔터티 설계가 제대로 되지 않음

-신규 요건으로 인한 통합으로 인해 엔터티의 의미가 넓어짐

-엔터티 명이 실수로 인해 표준화 가이드에 적합하지 않도록 정해짐

-테스트 단계에서 업무가 바꿔서 엔터티의 정의가 바뀜

 

실수로 엔터티 명을 잘못 정한 경우도 있지만, 실수가 없는 경우에도 엔터티 명은 바뀔 수 있다는 게 문제입니다. 운영 중에도 위와 같은 일은 생길 수 있습니다.

 

엔터티는 데이터를 일반화해서 정한 논리적인 이름이기 때문에 일반화 정도에 따라 연터티의 성격이 바뀔 수 있습니다. 이는 매우 자연스러운 상황입니다. 온라인 서점의 경우 처음에는 요건에 맞게 서적이란 엔터티를 설계했지만, 문구류도 팔게 되면 상품으로 엔터티 명를 바꿔야 합니다.

 

엔터티 명과 테이블 명을 연동시키지 않으면 아무 문제가 없습니다. 엔터티 명만 서적에서 상품으로 바꾸면 그만입니다.

 

반면에 엔터티 명과 테이블 명을 연동시키면 어떻게 처리할까요? 둘 중의 하나입니다. 엔터티 명을 아예 바꾸지 않거나, 테이블 명은 그대로 두고 엔터티 명만 바꾸는 것입니다.

 

전자처럼 처리하면 엔터티의 쓰임새(정의)와 엔터티 명이 달라지게 되죠. 이렇게 되면 엔터티가 잘못 사용될 수도 있습니다. 예를 들면 문구류를 관리하는 엔터티를 새로 만들 수 있습니다. 이 사례는 누구나 알 정도로 너무 뻔해서 실제 그런 일이 발생하지는 않을테지만 특정인만 아는 사례에서는 충분히 발생할 수 있습니다.

 

이런 상황이 발생하지 않더라도 이해하기 쉽게 하려고 영문 약어명을 사용한 애초의 의도와는 다르게 이미 많이 헷갈리게 됩니다.

 

테이블 명은 그대로 두고 엔터티 명만 바꾼 후자의 경우도 마찬가지입니다. 둘의 의미가 다르니 애초의 의도와는 다르게 실질적인 가독성이 좋아졌다고 볼 수 없습니다. 원칙이 깨진 것은 두말할 것도 없고요.

 

‘TCU0001’처럼 사용하는 첫 번째 방법에서 ‘TCU0001BS’처럼 사용하지 않는 이유도 마찬가지입니다. 엔터티 유형도 바뀔 수 있기 때문이죠. 비록 의미 없는 번호를 사용하지만 의미 있는 유형이 바뀐다면 위와 같은 현상은 그대로 발생합니다. 이도저도 아닌 게 됩니다.

 

길게 썼지만 간략하게 요약하면 아래와 같습니다.

 

-테이블 명을 정하는 방법은 크게 두 가지다. ‘TCU0001’이거나 ‘T_CU_CUST_BS’. 후자와 같이 정하는 이유는 가독성을 위해서다.

 

-두 번째 방법(T_CU_CUST_BS)에는 단점이 있다. DB가 거부할 정도로 길어질 수 있고, 엔터티 명이 바뀔 수 있다.

 

-엔터티 명이 바뀌는 경우, 가독성을 좋게 하려는 애초 의도에 부합하게 처리할 방법이 없다. 따라서 특별한 단점이 없는 첫 번째 방법(TCU0001)을 사용해야 한다.

 

개인적으로는 최근에 영문 약어를 사용하는 두 번째 경우는 못 봤지만, 한정된 경험이라 추세가 어떤지도 궁금합니다. 또한 개발을 하지 않는 입장이라 놓친 부분이 있을 수도 있습니다. 여러분의 의견은 어떠신지요?



'데이터 Story > 데이터 표준' 카테고리의 다른 글

표준 단어에 대해서  (0) 2017.11.19
속성 명 정하는 방법  (2) 2017.10.22
도메인 개념과 대표 속성  (0) 2017.09.09
화면 용어를 관리하려면  (0) 2017.06.18
복합어에 대한 상념(想念)  (0) 2017.05.14