태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

'테이블 명'에 해당되는 글 1건

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

 

반면에 테이블 명을 정하는 방법은 간단합니다. 대개 두 가지 방법 중에서 하나를 택해서 사용합니다. 방법을 결정하는 것은 대개 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
속성 명 정하는 방법  (0) 2017.10.22
도메인 개념과 대표 속성  (0) 2017.09.09
화면 용어를 관리하려면  (0) 2017.06.18
복합어에 대한 상념(想念)  (0) 2017.05.14
테이블 명을 정하는 방법  (2) 2017.05.03
블로그 이미지

블루퍼필

댓글을 달아 주세요

  • yakiuki 2018.01.02 00:36  댓글주소  수정/삭제  댓글쓰기

    모델러의 입장에서 엔터티의 내용을 바꾸는 경우에 대해 초점을 맞추고 생각한다면 분명 2번째 방법의 경우,
    테이블명을 바꿔야 하기 때문에 좋지 않다라는 의견에 공감을 합니다. 테이블명을 바꾸려고 많은 노력을 하게되기도 하죠.
    하지만 현역 SM 개발자의 입장에서 보면, 첫번째 방법이 두번째 방법보다 더 의미가 없어보입니다.
    우선 테이블은 가장 많이 사용하고, 다른 오브젝트들이 별도의 첨두어를 사용하기 때문에 굳이 T라는 타입명을 쓸 필요가
    없구요. 무엇보다도 수많은 테이블들을 관리하고, 사용해야 하는 입장에서 의미없는 001, 002 같은 숫자는 쉽게 머리에 익혀지기 어렵기 때문에 결국 매핑테이블이나 표를 관리해야 하게 되고, 그렇다면 매번 매핑을 확인해야 하는 번거로움으로 개발생산성이 떨어지게 됩니다. 쿼리를 짜게 되는 경우에도 어떤 경우에는 100라인이 넘는 쿼리가 있는데, 이 때 의미없는 테이블명은 가독성이 현저하게 떨어지게 만듭니다. 여기에서 실수를 유발시킬 수도 있구요.
    모델러의 입장에서는 엔터티와 테이블명이 다른게 눈엣가시처럼 보이실 수도 있지만,
    개발을 하는 입장에서는 한번 결정된 테이블명은 이미 머리에 체득된 대상이기 때문에 굳이 변경할건 아닌듯 합니다.
    이론과 실재의 차이지 않을까 싶습니다..

    • 블루퍼필 2018.01.03 21:44 신고  댓글주소  수정/삭제

      숫자를 쓰는 게 이론에 기반한 것은 아니고 실무 경험에 의한 것입니다.
      오히려 테이블 명을 표준화 해야 한다는 게 더 이론적이죠.

      하지만 선택의 문제인 건 확실합니다.

      기존에 어떤 방법을 사용하고 있었냐에 따라 선호가 갈립니다.
      개발자 중에도 영문 방식을 매우 꺼려하는 사람들이 많습니다.
      표준화를 할 수 있어 모델러가 선호하는 방법이기도 하고요.

      SM을 오랫동안 경험한 입장이라면 쓰던 방식을 못 버리게 되고요.
      바꾸는 건 매우 힘듭니다.

      다만 체화된 방법이 없을 때, 엔터티 명을 지킬 수 있고 길지 않은 숫자 방식이 좋을 거 같다는 생각입니다.

      모델러의 입장에서 중요한 건... ERD로 엔터티를 설계하고, 개발할 때는 ERD 보면서 개발하는 것입니다.
      이게 지켜지면 테이블 명이 어떻든 그다지 중요하진 않을 거 같습니다.

      의견 감사합니다.
      덕분에 글이 더 풍요로워질 거 같습니다.