태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

표준 단어와 표준 도메인, 표준 용어는 서로 엮어 있어 각자 별개의 것으로 설명하기 힘듭니다. 하지만 각자의 내용이 길고, 구분이 필요하기 때문에 별도의 장에서 설명하고 있습니다. 서로 밀접하게 연관되다 보니 중복 설명이 될 수 있습니다.

 

도메인의 의미는 다소 포괄적입니다. 데이터 모델링에서 도메인(domain)의 일반적인 의미는 데이터 타입과 길이, 포멧 등이 같은 값의 집합입니다. 이는 표준 도메인에도 유사하게 적용되는 의미입니다. 결국 의미가 같고, 데이터 타입과 자릿수가 같은 것을 표준 도메인이라고 합니다. 실제로 표준 도메인은 속성 명의 끝에 붙는 것으로 사용되고 있습니다. 분류어라는 용어로도 사용됩니다.

 

 

표준 도메인의 역할

 

표준 도메인의 사용 목적은 크게 세가지 정도가 있습니다. 하나는 데이터 값의 일관된 사용을 위해서입니다. ‘~일자라는 속성은 Date 타입이나 Varchar(8) 타입을 사용하도록 하는 것이 주된 목적입니다. ‘주문일자속성의 데이터 타입이 Varchar(6)이 되는 것을 방지하는 것이죠. 이 목적은 현재 필수적이어서 제대로 사용되고 있습니다.

 

또 하나의 목적이 일관된 사용을 위해서인데요. 이 기능을 제대로 사용하지 못하는 경우가 많습니다. 일관된 사용에는 여러 가지가 있습니다. 데이터 타입과 길이가 같아야 하는 것은 기본이고요. 영문의 형태도 같아야 합니다. 무엇보다 의미가 같아야 합니다. 논리적인 개념이 포함돼서 정확히 사용하지 못하는 면이 있습니다. 데이터 타입이나 길이를 일치시키기 위한 첫 번째 목적은 물리적 개념이라 정확히 사용되는 편이죠.

 

예를 들어, 고객 엔터티의 주 식별자인 고객번호속성은 표준 도메인이 돼야 합니다. 모든 고객번호 Varchar(8)로 사용해야 하니, 첫 번째 목적을 만족하기 위해 표준 도메인으로 사용돼야 합니다. 또한 고객번호속성은 영문을 ‘CNO’로 사용하기 위해 표준 도메인으로 사용합니다. 우리회사의 고객에 대한 번호를 의미하기 위해서는 고객번호를 표준 도메인으로 사용해야 하는 것입니다.

 

만약 외부 고객을 의미하는 번호가 필요하면 외부고객번호 속성을 사용해야 하는데요. 이때는 영문을 ‘ECNO’처럼 달리 사용해야 데이터 타입이 Varchar(10)으로 달라져도 사용에 문제가 없습니다. 데이터 타입이 Varchar(8)로 고객번호와 같더라도 영문의 형태가 달라져야 의미가 혼란스럽지 않게 됩니다.

 

고객번호를 표준 도메인으로 사용하지 않고 일반 용어처럼 사용하면 영문이 ‘CU_NO’가 되고, 외부고객번호 속성은 ‘ET_CU_NO’가 돼서 두 속성의 의미가 동일한지 그렇지 않은지 알 수 없게 됩니다.

 

고객번호를 표준 도메인으로 사용할 때, 외부고객번호 속성에 대한 도메인을 고객번호로사용해도 안 돼죠. 영문이 ‘ET_CNO’가 돼 우리 고객인지 혼동되고, 외부 고객 번호와 우리 고객 번호의 자릿수가 다를 때는 당장 문제가 됩니다.

 

우리회사 고객을 의미하는 관계고객번호란 속성에 대한 영문 역시 ‘RL_CNO’로 사용하는 것과 ‘RL_CU_NO’로 사용하는 것은 차이가 있습니다. 컬럼 명으로 데이터 타입은 물론 의미까지 구분할 수 있어야 합니다. 표준 도메인에는 이렇게 중요한 의미가 있습니다. 결국 속성의 일관된 사용을 돕는 것이 표준 도메인입니다.

 

표준 도메인의 마지막 역할은 컬럼 명을 줄이는 것입니다. 고객번호 속성이 표준 도메인일 때는 컬럼 명을 ‘CNO’로 사용할 수 있습니다. 그렇지 않다면 단어를 연결한 형태의 ‘CU_NO’ 정도로 사용할 수밖에 없게 됩니다. 컬럼 명이 짧아지는 것은 그 자체로도 의미가 있지만, 30자리가 넘는 컬럼 명이 생길 경우를 대비하는 차원에서도 의미가 있습니다. 흔치는 않지만 최대 길이를 초과하는 컬럼 명이 종종 생깁니다.

 

 

표준 도메인 유형

 

표준 도메인의 종류는 크게 두 가지로 구분할 수 있습니다. 대표적인 표준 도메인은 속성 명 뒤에 붙이는 기본 도메인입니다. 예를 들면, 일자, 금액, 내용, 코드 등이 있습니다. 이런 기본 도메인은 하나의 도메인에 여러 가지 데이터 타입과 길이를 지정할 수 있습니다. 데이터 타입과 길이를 합쳐서 흔히 인포타입(Infotype)이라고 합니다.

 

주문일자라는 속성 명을 표준 용어로 등록할 때, ‘일자라는 기본 도메인을 지정하고 Varchar(8)이나 Date 인포타입 중에서 선택할 수 있는 것입니다. ‘주문금액도 마찬가지로 금액이란 기본 도메인을 사용합니다. 표준 도메인인 기본 도메인이 사용되는 대표적인 경우입니다.

 

다른 한 가지는 대표 속성을 의미하는 속성 도메인입니다. 속성 도메인의 대표적인 예에는 식별자 속성이 있습니다. 고객번호, 계좌번호, 사원번호 등의 인조 식별자는 속성 도메인입니다. 이런 인조 식별자는 나름의 고유한 의미가 있으면서, 주로 다른 엔터티의 관계 속성으로 사용됩니다. 관계 속성으로 사용될 때는 수식어와 함께 사용되는 경우가 많습니다. 입금+계좌번호 등이 그렇습니다.

 

이때 계좌번호를 대표 속성으로 등록하면, 즉 속성 도메인으로 등록하면 수식어+속성 도메인형식으로 사용할 수 있습니다. 이렇게 지정하면 계좌번호의 데이터 타입과 길이를 그대로 따르게 됩니다. 더욱이 ‘ACNO’라는 컬럼 명도 그대로 사용할 수 있습니다.

 

만약 속성 도메인인 계좌번호 자체를 도메인으로 지정하지 않고, 기본 도메인인 번호를 지정하면 데이터 타입과 길이가 계좌번호 속성과 달라질 수 있으며, 컬럼 명도 ‘AC_NO’ 형태가 되니 달라지게 됩니다. 이렇게 되면 같은 성격의 계좌번호를 의미하는 것인지조차 확신할 수 없게 됩니다.

 

속성 도메인을 사용하는 이유는 컬럼 명을 일치시키기 위한 목적도 큽니다. 만약 외부 계좌번호를 나타내는 속성이라면 계좌+번호로 사용해야 컬럼 명이 내부 계좌번호와 구분됩니다. 계좌 엔터티의 주 식별자인 계좌번호에 해당하는 속성만 속성 도메인을 지정해서 사용하는 것입니다. 이런 대표 속성을 속성 도메인으로 등록하면 데이터 무결성이 좋아지고, 혼선이 없이 일관되게 사용할 수 있습니다.

 

대표 속성에는 주 식별자에 포함된 속성도 해당됩니다. 예를 들어 계좌거래내역 엔터티의 주 식별자가 계좌번호+거래일련번호라고 가정하면, 이때는 거래일련번호 속성도 대표 속성이 됩니다. 이 엔터티와 관계가 존재하는 다른 엔터티에서 관계 속성을 사용할 때, 수식어가 필요한 경우에는 거래일련번호 속성을 속성 도메인으로 지정해서 사용할 수 있습니다.

 

그밖에 전화번호, 주민등록번호, 사업자등록번호 등의 식별 번호도 도메인 속성입니다. 마찬가지로 수식어를 포함해서 사용할 때 속성 도메인을 지정할 수 있습니다. 속성 도메인을 지정해서 사용하지 않으면 같은 성격의 속성인데, 데이터 타입이나 길이, 컬럼 명의 형식이 달라질 수 있습니다. 이를 일치시키는 게 속성 도메인의 주된 목적입니다. 기본 도메인과 같은 역할을 합니다.

 

속성 도메인(대표 속성)의 대부분은 주 식별자를 의미하기 때문에 속성 도메인은 엔터티 설계가 끝난 후에 모델러가 등록하게 됩니다. ‘전화번호와 같은 일부 속성 도메인만 미리 등록할 수 있습니다.

 

기본 도메인과 달리 속성 도메인은 속성 그 자체를 의미합니다. 반면에 금액, 내용, 여부 등의 기본 도메인은 속성이 아니므로 속성으로 그대로 사용하면 안 됩니다. 앞에 반드시 수식어를 사용해서 구체적인 의미로 사용해야 합니다. 속성 도메인이 관계 속성에 사용될 때는 관계를 서술하는 수식어와 함께 사용할 수 있습니다.

 

속성의 데이터 성격이 고정적일수록 속성 도메인으로 적절합니다. , , 금액 보다는 번호나 ID, 코드 등의 데이터가 강결합입니다. 즉 번호, ID, 코드 등이 속성 도메인으로 적합하다는 것입니다. 다만 코드 속성은 속성 도메인에서 제외됩니다. 이는 별도로 설명하겠습니다.

 

기본 도메인과 속성 도메인을 등록할 때, 영문은 단어의 조합이 아니라 ‘_’ 없는 약어로 만드는 게 바람직합니다. 데이터 타입과 길이를 일치시키는 목적도 크지만, 영문의 길이를 짧게 만드는 목적도 크기 때문입니다.

 

기본 도메인은 단일어일 수도 있지만, 속성 도메인은 복합어입니다. 즉 둘 다 표준 단어에 속합니다. 전화번호, 사업자등록번호 등의 복합 명사는 복합어입니다. 인조 식별자이면서 업무적으로 복합 명사에 해당하는 계좌번호, 고객번호 등도 복합어로 등록하는 게 좋습니다.

 

기본 도메인과 속성 도메인의 성격을 이해하셨는지요? 모델링 노트 책에서는 기본 도메인은 물리 도메인(일반 도메인)으로 속성 도메인은 논리 도메인(대표 속성)으로 설명했습니다.

 

마지막으로 표준 용어를 등록하는 예를 들겠습니다. 계좌 엔터티의 주 식별자인 계좌번호 속성을 표준 용어로 등록할 때는, ‘번호라는 기본 도메인(물리 도메인)을 지정하게 됩니다. 인포타입은 ‘VC12’ 정도로 정하고요. 영문은 ‘AC_NO’가 아니라 ‘ANO’가 돼야 하니 복합어로 만듭니다.

 

우리 계좌번호를 의미하는 출금계좌번호 속성을 표준 용어로 등록할 때는, ‘계좌번호라는 속성 도메인(논리 도메인)을 지정하면 끝입니다. ‘출금+계좌번호형태가 되는 것이죠. 별도로 기본 도메인을 지정할 필요가 없습니다.

 

반면에 외부 계좌번호를 의미하는 입금계좌번호 속성을 표준 용어로 등록한다면, ‘계좌번호라는 속성 도메인(논리 도메인)을 지정하면 안 되고, ‘번호라는 기본 도메인(물리 도메인)을 지정해야 합니다. 인포타입은 ‘VC20’ 정도가 될 것입니다. ‘입금+계좌+번호형태가 돼야 인포타입도 자유롭게 지정할 수 있고, 영문도 구분이 됩니다.

 

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

두 가지 종류의 표준 도메인  (0) 2017.12.23
복합어에 대한 정리  (0) 2017.12.10
표준 단어에 대해서  (0) 2017.11.19
속성 명 정하는 방법  (0) 2017.10.22
도메인 개념과 대표 속성  (0) 2017.09.09
화면 용어를 관리하려면  (0) 2017.06.18
블로그 이미지

블루퍼필

댓글을 달아 주세요

이번 글은 복합어에 대한 내용입니다이미 복합어에 대한 글을 게시한 적이 있지만, 이번 기회에 더 자세하게 설명하겠습니다먼저 표준 단어에 대한 이전 글을 읽어보시길 권합니다.


http://dataprofessional.tistory.com/172

 

위 글에서 설명했지만 복합어는 표준 단어의 일종입니다표준 단어는 단일어와 복합어로 나눌 수 있습니다.

 

복합어가 필요한 이유를 간단히 설명한다면, 애매한 사용을 줄이고 컬럼 명을 줄이기 위해서라고 하겠습니다표준화지침서에 복합어의 사용을 지양하라는 지침이 많은데제 생각은 반대입니다애매한 사용을 줄이고 컬럼 명을 줄이기 위해서는 복합어가 많아야 한다고 생각하기 때문입니다.

 

 

복합어를 사용해야 하는 경우

 

그럼어떤 경우에 복합어를 만들면 될까요크게 보면 앞서 밝혔듯이 애매하게 사용되지 않게 하고컬럼 명을 짧게 해야 하는 경우에 만들게 됩니다주요한 몇 가지 경우가 있습니다.

 

우선 업무에서 사용하는 복합 명사는 복합어로 만들어야 합니다다시 말해 속성에 사용된 복합 명사는 복합어가 돼야 하는 것이죠복합 명사 성격의 단어는 많을 것입니다명사와 명사가 결합된 형태니까요부가가치세자동이체한국은행약속어음수수료, 전자보증서 등 많습니다.

 

여기에는 명사가 결합돼 의미가 다소 변하는 성격의 단어도 포함됩니다별도의 의미가 있는 '계정'이나 '과목'이란 단어를 ‘계정과목’으로 합치면 의미가 달라집니다‘고객센터’도 여기에 속하죠.

 

의미가 달라지는지 여부와 무관하게 명사와 명사가 합쳐진 단어가 자주 사용된다면 복합어로 등록하는 게 좋습니다복합 명사 자체가 복합어이기 때문이기도 하지만컬럼 명을 줄이기 위해서입니다왜 줄여야 하는지는 나중에 자세하게 설명하겠습니다.

 

한 글자 단어도 복합어로 만들어야 하는 경우입니다표준 단어 글에서 밝혔듯이 원(), (), (), (), (), (), (), (), (등의 접사나 관형사(), (등의 명사 등 한 글자 단어는 표준 단어로 등록하지 않아야 한다고 생각합니다.

 

실생활에서 단독으로 사용하면 의미가 통하지 않으니 단어로 보기 힘들고요무엇보다 잘못 사용될 수 있고, 혼동될 수 있습니다모든 복합어 사용 목적은 컬럼 명을 줄이려는 의도가 크다는 점은 재차 강조합니다한 글자 단어가 사용되면 컬럼 명이 길어진다는 의미입니다.

 

만약에 '()'를 표준 단어로 등록하면 ‘재+발급+신청+일자’로 사용할 텐데요‘재’가 ''의 의미인지 확실하지 않을 때는 ‘재발급+신청+일자’로 사용할 수 있습니다대개는 상식적으로 판단하기 쉬울 테지만, 그렇지 않은 경우도 많을 것입니다.

 

‘율/률’도 혼란스러운 대표적인 한 글자 단어입니다. ‘율’이나 ‘률’이 표준 단어로 등록되면 모음이나 ‘ㄴ’ 받침 뒤에는 ‘율’로 나머지의 경우는 ‘률’로 사용해야 하는데정확하게 사용하기 쉽지 않습니다. ‘수익율’과 ‘수익률’이 둘 다 사용되는 이유입니다.

 

‘율/률’은 표준 단어로 등록하지 않고‘수익률’을 복합어로 ‘수익율’은 금칙어로 생성하면 사용에 혼선이 없게 됩니다.

 

접미사로 주로 사용되는 '()'가 표준 단어일 경우에는 ‘사업+비’ 대신 ‘사업+비용’으로 쓸 수 있습니다‘사업비’를 복합어로 생성한다면 ‘사업비용’이 사용될 가능성이 줄어듭니다.

 

속성 개수가 적다면 위와 같은 한 글자 단어로 인한 오류를 최소화할 수 있는데, 속성 개수는 압도적으로 많습니다오류를 알아서 잘 피하도록 하는 것보다 가능한 오류가 원천봉쇄되도록 하는 게 좋습니다.

 

표준 용어를 신청할 때 판단할 필요가 없도록 ‘재’나 ‘비’가 표준 단어에 없는 게 명확합니다. 재발급, 사업비 등만 있으니 달리 선택할 방법이 없는 것이죠. 잘못 사용되지 않도록 하는 게 표준화의 가장 큰 목적입니다.

 

한 글자 단어를 복합어로 사용하면 품질이 높아지는 경향도 있습니다. ‘고객명’, ‘사원명’ 등으로 한정해서 사용하면 오히려 더 정확하게 사용되는 것이죠. ‘관리+사원명’처럼 사용돼 ‘관리자명’ 등으로의 사용을 방지할 수 있고, 중요한 부분은 아니지만 데이터 타입의 자리수도 나름대로 의미 있게 정해서 일관되게 사용할 수 있습니다. 외국인이 포함된 ‘고객명’은VC100으로 정하고 ‘파일명’은 VC500으로 사용할 수 있는 식이죠.

 

이렇게 한 글자 단어를 포함한 복합어를 사용할 경우에 단점은 복합어가 많아진다는 것입니다대부분의 한 글자 단어에 대해서는 복합어가 많이 생기지 않는데()과 수()의 경우는 복합어가 다소 많이 생깁니다.

 

사실 복합어가 많은 게 특별히 문제가 되진 않습니다혼란도 방지할 수 있고 컬럼 명까지 줄일 수 있으니 한 글자 단어는 표준 단어로 등록하지 않고, 복합어로 사용하도록 하는 게 좋습니다.

 

한 글자 단어가 표준 단어로 존재하는 상태에서다수의 모델러가 표준 용어를 등록하면 아무리 승인 과정이 있더라도 오류는 피할 수 없습니다아예 잘못 사용할 원인을 제거하는 게 바람직합니다표준화는 매우 섬세한 작업이기 때문에 사소한 위반이라도 쌓이면 품질 저하를 일으킬 수 있습니다.

 

품질 저하가 특정 지점을 넘어가면 표준화에 대한 의미가 없어져 유명무실해집니다쓸모도 적으면서 괜한 통제로 인식되면 부작용만 커집니다정확히 사용돼야 명분이 있는 것이기 때문에 DA는 원칙을 사수해야 합니다작은 구멍에 둑이 무너지는 법입니다.

 

명사로 정해진 고유한 영문 명을 사용하기 위해서도 복합어를 사용합니다예를 들어 ‘감가상각비’의 영문은 VAT’인데‘감가상각비’를 복합어로 등록하지 않으면 표준 용어를 등록할 때 ‘감가+상각+비’, ‘감가+상각비’처럼 사용될 수 있습니다그러면 영문인 VAT’를 사용할 수 없게 됩니다고유한 영문이 존재하는 경우는 복합어로 등록해야 합니다.

 

기관 명 등의 고유 명사도 복합어로 등록해서 사용해야 하는 경우입니다‘한국은행’을 ‘한국+은행’으로 사용하지 않도록 하는 것입니다원래 하나의 단어로 사용하니 의미 상으로도 복합어로 등록해야 하는 것입니다.

 

1분기’, 1학기’ 등 숫자와 한글이 결합된 경우도 복합어로 등록합니다숫자 자체를 단어로 사용할 수 없기 때문에 이렇게 숫자와 결합된 복합어는 상당히 많습니다복합어가 많아져서 한 글자 단어를 복합어로 만들지 않는다면 숫자 역시 단어가 돼야 하는 것이죠.

 

주 식별자 속성도 복힙어로 등록하는 게 좋습니다계좌 엔터티의 주 식별자인 ‘계좌번호’고객 엔터티의 주 식별자인 ‘고객번호’는 복합어로 등록해서 사용하는 게 좋습니다이는 도메인과 연관돼 있는데도메인은 별도로 설명하겠습니다.

 

마지막으로 구분코드, 유형코드, 종류코드 등은 컬럼 명을 줄이기 위해 복합어로 등록합니다. TP_CD 대신 TC로 사용하기 위해서죠업무 용어는 아니지만 속성에 자주 사용되는 복합 명사로 볼 수 있습니다‘사원명’의 경우와 마찬가지로 사용 범위를 축소시켜 강제하기 때문에 품질이 높아지는 효과가 있기도 합니다.

 

저는 공통 코드에 대해서는 '코드' 앞에 구분어를 꼭 사용하고구분어는 유형종류구분으로 한정합니다이를 복합어로 등록하면 사용이 획일적이어서 잘못 사용되는 경우가 줄어듭니다.

 

이상으로 복합어로 등록해야 하는 경우에 대해 자세하게 설명했습니다모든 경우에 공통적으로 해당하는 목적이 컬럼 명을 짧게 만들기 위함인데요개인적으로 민감하게 생각하는 부분이라 이것이 복합어를 만드는 주요 기준이 됩니다.


 

복합어가 생기는 시점

 

위와 같은 경우에 복합어가 생성되는데요. 그럼 복합어를 생성하는 시점은 언제일까요? 크게 두 가지로 구분할 수 있습니다. 우선, 개발 프로젝트일 때를 기준으로 설명하겠습니다. 프로젝트 시작 전에 사전 구축하는 방법이 있고, 표준 용어를 등록할 때 복합어를 생성하는 방법이 있습니다.

 

나중에 설명할 표준 용어는 모델러가 신청하는 게 일반적이지만, 복합어는 DA나 표준담당자가 생성합니다. 개발 프로젝트라면 표준담당자가 존재할 것이라서 표준담당자가 복합어를 생성합니다. 표준담당자는 표준 컨턴츠가 어느 정도 구축된 프로젝트 중반에는 없을 수도 있습니다. 이때는 DA가 복합어를 생성합니다.

 

복합어는 단어에 포함되고, 단어는 일반적으로 사전에 구축하기 때문에 복합어 또한 사전에 구축하는 방법을 많이 사용하고 있습니다. 위의 절에서 설명한 복합어 생성 대상에 해당되는 복합어를 도출해서 사전에 구축하는 것입니다.

 

이 방법의 단점은 대량 작업으로 인한 컨텐츠의 품질 저하라고 생각합니다. 연관되는 얘기인데, 표준담당자가 표준 용어의 의미를 정확히 알 수 없어 복합어 선정에 어려움을 겪을 수 있습니다. 이런 문제에 대량 작업을 해야 하는 문제가 겹쳐 결국 품질에 문제가 생길 수 있습니다.

 

두 번째 방법은 표준 용어를 등록하는 시점에 복합어를 생성하는 것입니다. 이때는 복합어에 대한 일차적인 판단을 모델러가 하게 됩니다. 위에서 설명한 복합어가 필요한 상황이면, 표준 용어를 신청하면서 복합어를 동시에 신청하는 것입니다. 물론 승인은 표준담당자나 DA가 하게 됩니다. 복합어가 필요한 상황인데 모델러가 인지하지 못하고 신청하지 않을 수도 있습니다. 이때는 복합어를 등록하고 사용하도록 가이드하게 됩니다.

 

이 방법이 표준 용어를 등록하는데 시간이 조금 더 걸릴 수는 있지만, 복합어나 표준 용어의 품질은 더욱 높아지게 됩니다. 모델러가 표준 용어의 의미를 정확히 알기 때문에 복합어를 더욱 잘 선정할 수 있다고 생각합니다.

 

표준담당자나 DA가 복합어를 미리 생성하는 것은 힘듭니다. ‘주민등록번호등 일부 도출하기 쉬운 복합어는 미리 생성해 놓을 수 있지만, 모든 복합어를 사전에 생성하긴 힘듭니다. 표준 단어와 복합어는 결국 ASIS 속성 명에서 도출되는데, 의미를 모르는 상태여서 작업도 힘들고 결과도 만족스럽지 못하게 됩니다.

 

주요 복합어만 사전에 등록하고 표준 용어를 등록하면서 복합어를 도출하는 게 좋습니다위에서 설명한 복합어를 생성하는 명확한 기준이 있다면 품질이 높은 표준 컨텐츠를 구축할 수 있습니다.

 

표준 단어나 복합어가 완전하게 구비되지 않은 상태에서 표준 용어를 신청하는 것에 대한 우려를 많이 하는데표준 단어와 복합어가 대한 정책만 제대로 존재있다면 복합어를 그때그때 생성하는 게 문제가 되진 않습니다.

 

대량 작업에는 오류가 뒤따르게 마련이니 소량의 작업을 확실하게 하는 게 바람직합니다. 초반에 다소 느리지만 나중에 재작업이 줄어드는 걸 생각하면 결코 느리다고 할 수 없습니다.

 

빨리 구축하고 계속 수정하는 것과 천천히 구축하고 수정을 안 하는 것의 차이입니다이는 IT에 종사하는 사람이면 누구나 아는 차이입니다길을 잘못 든 사람이 걸음을 재촉하는 법이라고 합니다걸음을 재촉하면 길을 잘못 들 수 있습니다.

 

 

복합어의 사용 형태

 

표준 용어를 신청할 때 복합어가 존재하는지 여부에 따라 상황이 달라집니다. 복합어가 있는 상태에서 복합어가 표준 용어에 포함된 경우는 문제가 없습니다복합어가 분리된 표준 단어가 존재해도 복합어를 사용해야 합니다.

 

이는 시스템에서 간단하게 적용할 수 있는 경우입니다예를 들어 ‘한국은행(BOK)’이란 복합어가 있다면 ‘한국(KOR)’과 ‘은행(BNK)’이라는 표준 단어가 있어도 ‘한국은행(BOK)’을 사용하는 것입니다.

 

문제는 복합어가 없는 상태에서 복합어 후보가 생겼을 때입니다이 때도 두 가지 경우가 있는데요복합어를 분리한 형태로 사용하고 있지 않을 때와 분리한 형태로 사용하고 있을 때입니다.

 

복잡할 수 있으니 그림으로 설명하겠습니다. [그림 1] 1번은 앞서 설명한 대로 아무 문제가 없는 경우입니다. ‘한국은행(BOK)’이란 복합어가 있다면 그 복합어를 사용하면 됩니다.



[그림 1] 표준 용어 등록 시 복합어의 사용 형태

 

1번 경우도 문제가 될 수 있는데예를 들면 ‘전자보증서발급일자’ 용어를 신청할 때 ‘전자보증서’라는 복합어를 사용하지 않고 ‘전자+보증서+발급+일자’로 등록할 때입니다물론 오류에 해당합니다.

 

모델러가 ‘전자+보증서+발급+일자’로 신청했다고 해도 메타 시스템에서 ‘전자보증서+발급+일자’로 바로잡아줘야 합니다. 복합어가 있는 상태라면 복합어의 사용이 원칙이며, 시스템에서 강제해야 하는 원칙입니다.

 

2번의 경우가 ‘전자보증서’라는 복합어가 없으면서, ‘전자+보증서’로 사용하고 있는 표준 용어가 없는 상태입니다이때도 문제 없이 간단하게 처리힐 수 있습니다‘전자보증서’를 복합어로 등록한 후에 ‘전자보증서+발급+일자’를 표준 용어로 등록하면 됩니다.

 

3번과 4번은 다소 복잡합니댜‘전자보증서’라는 복합어가 없는데‘전자+보증서’로 사용하고 있는 표준 용어가 있는 상태입니다. 3번은 ‘전자+보증서’로 사용하고 있는 표준 용어의 개수가 많은 경우이고요.  4번은 개수가 적은 경우입니다.

 

3번의 경우는 어쩔 수 없이 ‘전자보증서’를 복합어로 등록하고‘전자보증서+발급+일자’로 용어를 등록하게 됩니다그런데 ‘전자+보증서’로 사용하고 있는 표준 용어가 이미 많기 때문에 ‘전자보증서’라는 복합어는 예외로 사용한다는 것을 의미합니다.

 

위와 같은 경우는 컬럼 명이 길어질 때 발생하는데요컬럼 명의 길이 제한이 있는 DB에서만 발생합니다예를 들면 오라클은 30자리까지 허용합니다반복 속성이 10개 이상 생길 수 있어 끝에 두 자리 숫자를 여분으로 두면 28자리가 촤대 길이가 됩니다표준 정책을 잘못 정하고 속성 명을 구체적으로 정하면 이 최대 길이를 넘어가는 속성이 생각보다 많아질 수 있습니다.

 

어쩔 수 없이 컬럼 명을 줄여야 할 때, ‘전자+보증서’라고 사용하고 있는 표준 용어가 많은데도 불구하고 ‘전자보증서’라는 복합어를 나중에 만들게 되는 상황입니다나중에 만든 복합어는 예외로 사용하도록 처리하는 것이고요혹시 다른 컬럼의 길이가 길어져서 다시 ‘전자보증서’라는 복합어를 사용하게 될 수는 있지만그렇지 않을 경우에는 ‘전자+보증서’를 사용하는 것입니다.

 

이렇게 사용하기 위해서는 나중에 만들어진예외로 사용하게 될 복합어에 대해서는 따로 구별을 해야 합니다그래야 시스템에서 지속적으로 사용되지 않고 예외 처리를 할 수 있습니다. 1, 2번 경우와 비교하면 구분이 필요한 상황입니다.

 

4번은 약간 다른데요나중에 ‘전자보증서’라는 복합어를 만든 상황은 3번과 같습니다그런데 ‘전자+보증서’로 사용하는 용어가 1~2개로 매우 적은 것입니다이때는 오히려 ‘전자보증서’라는 복합어를 계속 사용하도록 할 수 있습니다물론 일관된 사용을 위해 이 경우에도 3번과 마찬가지로 ‘전자+보증서’를 사용하는 게 좋다고 생각합니다.

 

여담이지만 오래 전에 3, 4번 경우가 빈번히 발생하는 프로젝트가 있었는데요그때는 예를 들면 ‘전자+보증서’로 사용하던 속성을 전부 ‘전자보증서’로 수정하도록 했습니다제가 아니라 PM이요개발 중이었으니 여러 군데서 소심한 곡소리가 들렸죠.

 

위와 같이 처리하는 게 가장 깔끔하긴 한데 파장이 큰 거 같습니다매우 빈번하다면 어쩔 수 없지만흔치 않다면 복합어를 사용한 경우를 예외로 처리하는 게 차선책입니다‘전자보증서’가 포함되고 28자리가 넘는 용어가 드물 것이라 계속 ‘전자+보증서’로 사용하도록 하는 게 부작용도 최소화되고 일관적이라고 생각합니다물론 ‘전자+보증서’로 사용된 용어가 적을 때는 이를 ‘전자보증서’로 수정하는 것은 좋은 방법입니다.

 

일관되게 적용하려면 ‘전자+보증서’와 같이 단어의 조합으로 사용 중일 때 생긴 복합어는 예외 처리를 해서 다시 사용되지 않도록 하는 게 좋습니다시스템에 적용하려면 한 방향을 정해야 합니다.

 

어쨌든 3, 4번은 용어에 ‘전자보증서’와 ‘전자+보증서’가 동시에 사용되는데이는 컬럼 명이 달라지게 된다는 것을 의미합니다이런 상황이 자주 발생하면 품질이 떨어질 수 있습니다.

 

이와 같은 현상은 복합어가 나중에 생겨서 발생합니다. 이 말은 결국 복합어로 생성해야 할 대상을 단어의 조합으로 사용했을 때 생길 수 있습니다. 복합어를 생성하는 시점의 문제보다는 대상을 도출하지 못하고 지나쳤을 때 생길 수 있습니다.

 

컬럼 명이 길어지는 것 자체가 좋지 않고, 간혹 컬럼 명의 길이 제한 때문에 3, 4번 상황이 발생하니 애초부터 복합어에 대한 설계를 제대로 해야 합니다. 복합어만 적절하게 생성해도 3, 4번 경우는 발생하지 않습니다. 위에서 설명한 복합어 생성 후보에 대해서는 그때그때 복합어로 등록하는 게 좋습니다.

 

3, 4번이 안 생기도록 하는 또 한가지 비법은 단어의 영문 약어를 짧게 만드는 것입니다. ‘계좌’라는 단어의 영문 약어명을 ‘ACCT’라고 하지 않고 ‘AC’라고 하는 것이죠. 길게 만드는 장점은 가독성입니다. 하지만 표준 용어가 4~5개의 단어로 구성되면 영문의 가독성이 좋아진다고 볼 수 없습니다. 게다가 컬럼 명이 길어지는 것에 대한 단점이 너무나 큽니다.

 

속성 명을 구체적으로 정해야 할 때가 많아 용어가 4~5개의 단어로 구성되는 경우가 많습니다. 단어의 영문 약어가 4글자라면 단어 사이의 ‘_’까지 감안했을 때 25자리 정도가 되는데, DB에 생성이 가능해도 매우 긴 상태입니다.

 

길어도 15~20자리가 넘지 않는 게 좋습니다. 28자리가 넘어가는 문제로 생기는 복합어와 관련된 혼란도 없고 사용하기도 편합니다. AC’처럼 짧더라도 자주 보면 익숙해지고 익히게 됩니다. 단어의 영문 약어명은 2~3자리가 좋습니다.

 

실제로 [그림 1]3, 4번처럼 긴 컬럼 명을 줄여야 할 상황이 발생하면, 연관성이 있는 단어를 복합어로 만드는 게 좋습니다. 연관되는 단어가 없을 때는 영문이 긴 단어를 묶는 것이 좋습니다.

 

복합어의 영문 약어명은 당연히 ‘_’ 없이 정하는 게 바람직합니다. ‘계좌번호’라는 복합어를 ‘AC_NO’로 하기보다 ‘ANO’로 하는 것입니다. 이는 사실 필연적인데, AC_NO’로 사용한다면 복합어인지 두 단어를 합친 것인지 알 수 없게 됩니다. 영문을 줄이기 위해 복합어를 사용하는데, ‘AC_NO’로 사용하면 복합어를 사용할 이유가 없게 되는 것입니다. 복합어라면 영문이 줄어야 합니다. 복합어인데 영문 약어명에 “_”가 포함돼 있다면 잘못된 것입니다.

 

표준 용어를 등록할 때 문제가 발생할 수 있는 부분은 크게 이음동의어와 동음이의어를 어떻게 처리하는지, 그리고 복합어를 어떻게 처리하는지 정도입니다. 나머지 문제는 지엽적입니다표준 용어에 대해서는 별도의 장에서 자세하게 설명하겠습니다.

 

전사 데이터베이스에 오라클이 포함될 확률이 높기 때문에 컬럼 명 길이 제약을 대비해서라도 복합어에 대한 정책을 제대로 세워야 합니다. 그렇지 않으면 나중에 수정해야 할 작업이 많아지거나, 수정조차 못하고 표준이 없는 것이나 마찬가지인 상태로 사용하게 될 수 있습니다.

 

 

마직막으로 언급할 것은 복합어의 구성 단어를 무조건 표준 단어로 등록하는 것은 지양해야 한다는 것입니다. 해당 단어가 별도로 사용될 때 등록하는 게 바람직합니다. 사용되지 않는데도 불구하고 복합어를 분리한 단어가 각자 등록되면 복합어와 혼란만 생깁니다.

 

고객센터가 단어라면 복합어인 고객센터를 사용할 때 고객+센터로 사용될 수 있는 것이죠. 물론 대부분의 단어는 사용될 것입니다. 무의미할 수 있는 고객센터센터’, ‘랩어카운트이나 어카운트’, ‘벤처기업벤처등의 단어를 무조건 등록하는 것을 지양하면 됩니다.

 

이상으로 복합어에 대한 설명을 끝마치겠습니다. 표준 단어에 대해서는 어느 정도 설명을 마친 것 같습니다다음 기회에는 표준 도메인에 대해 자세하게 설명하겠습니다.



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

두 가지 종류의 표준 도메인  (0) 2017.12.23
복합어에 대한 정리  (0) 2017.12.10
표준 단어에 대해서  (0) 2017.11.19
속성 명 정하는 방법  (0) 2017.10.22
도메인 개념과 대표 속성  (0) 2017.09.09
화면 용어를 관리하려면  (0) 2017.06.18
블로그 이미지

블루퍼필

댓글을 달아 주세요

제가 최근에 표준화에 대한 글을 간혹 올리는데요잠깐 언급한 적도 있지만그동안 표준화에 대한 내용은 자세히 다루지 않았습니다여러 이유가 있었지만, 어쨌든 최근 생각은 제 경험을 공유하는 게 좋겠다고 생각해서 하나씩 공유하고 있습니다.

 

그동안 속성 명을 정한 게 10만 개는 훌쩍 넘는 거 같습니다모델링할 때 아직까지는 속성 명 정하는 게 재미있습니다재미 없으면 힘들 텐데재미 있으니 누가 뭐라 하든 열심히 정하고 있습니다. 다만 개수에 압도당할 뿐이죠.

 

모델링 자체로만 봤을 때 재미 없는 게 한 가지 있습니다양이 압도적으로 많고중요한 부분이지만 정성을 들이기 쉽지 않은 부분인데요눈치 채셨을 거 같은데속성 설명 적는 것입니다가끔 50자 이상 적으라는 식의 가이드가 있으면 정말그렇습니다.

 

어쨌든 재밌으면 힘들지 않죠속성 명 정하는 데 한참을 몰두하면 눈이 뒤집어지는 거 같지만 재밌으니 많을 양을 하게 됩니다하나라도 허투로 정하지 않으려 노력하고요그러면서 노하우도 상당히 쌓였다고 생각합니다모델 구조 설계에 비하면 특별하진 않지만요.

 

데이터 표준은 데이터 아키텍처(DA)의 한 부분입니다. 표준 데이터에 대한 정책을 만들고 표준 데이터를 등록해서 운영하는 것을 표준화라고 할 수 있습니다. 표준화를 하는 목적을 쉽게 얘기하면 속성 명을 제대로 정하기 위해서라고 할 수 있고요. 속성 명을 모델러가 정하기 때문에 표준화 영역이 모델러와 직결되죠.

 

표준에 대한 정책이나 원칙이 잘못 됐다거나, 사용해야 할 컨텐츠(단어, 도메인)가 잘못되면 모델러가 혼란스럽게 됩니다. 양이 압도적으로 많기 때문에 재작업을 최소화할 수 있도록 해야 합니다.

 

모델러는 표준에 대한 정책이나 원칙에 대한 의견을 적극적으로 제시해야 합니다. 역할이 구분돼 있다면 결정권이 없다고 생각해 방관할 수 있지만, 주 식별자 등과 엮이기 때문에 깊이 관여하게 되며, 표준담당자는 일정 부분에서 모델러의 의견을 따르게 됩니다.

 

모델 구조가 더욱 중요하지만, 표준에 대한 내용을 간과하면 품질이 저하될 수 있습니다. 사소한 게 쌓이면 커지게 됩니다. 표준화에 신경써야 합니다.

 

 

단어 사전

 

사설이 길어졌는데, 이번 글의 주제는 표준 단어입니다. 표준 단어는 표준화 작업에서 가장 기초적인 부분이죠.

 

표준 단어는 속성 명과 컬럼 명을 구성하는 요소입니다. 속성 명은 반드시 표준 단어의 조합으로 이루어져야 합니다. 예를 들어, ‘주문결제금액이란 속성은 주문결제’, ‘금액이란 단어로 이루어집니다. 세 단어가 없다면 주문결제금액이란 속성 명을 사용할 수 없습니다.

 

주문에 해당하는 영문 명은 ‘ODR’이며, ‘결제‘SM’, ‘금액‘AMT’이므로 속성 명이 정해지면 자연스럽게 컬럼 명(ODR_SM_AMT)이 정해집니다. 속성 명과 컬럼 명에 사용되기 때문에 표준 단어는 매우 중요합니다.

 

단어는 메타 시스템에 표준 단어로 등록됩니다. 메타 시스템에 등록된 전체 표준 단어를 단어 사전(Word Dictionary)이라고 하고요. 단어 사전은 시스템마다 많이 달라질 수 있습니다. 금융업의 단어 사전과 제조업의 단어 사전은 다릅니다.

 

 

표준 단어의 정의

 

단어의 사전적인 의미는 분리해서 자립적으로 사용할 수 있는 말입니다. 반면에 메타 시스템에서 사용하는 표준 단어는 국어 문법의 단어와는 다소 다릅니다.

 

표준 단어는 실생활에서 사용되는 의미가 있는 명사를 의미합니다. 명사이기 때문에 ‘~’, ‘~등의 형용사는 당연히 표준 단어가 아닙니다. 또한 원(), (), (), (), (), (), (), (), (등의 접사나 관형사도 표준 단어가 아닙니다. (), (등의 한 글자 명사도 마찬가지고요. 단독으로 사용되면 의미를 알 수 없으니 실생활에서 단독으로 사용되지 않습니다.

 

이런 한 글자 단어를 표준 단어로 등록하는 것은 주의해야 합니다. 장점에 비해 단점이 뚜렷해서 저는 한 글자 단어는 표준 단어로 등록하지 않아야 한다고 생각합니다. 한 글자 단어는 의미가 명확하지 않기 때문에 잘못 사용될 가능성이 있습니다.

 

예를 들어 주()라는 한 글자 관형사를 표준 단어로 등록하면 주채무를 하나의 표준 단어로 사용할지 +채무로 나눠서 사용할지 혼동될 수 있습니다. 결국 표준 용어에 주채무+채무가 둘 다 사용될 수 있습니다.

 

주채무가 하나의 단일어인지 접사가 포함된 복합어인지를 판단해야 하는데, 왠만한 국어 실력이 아니고서는 쉽게 판단하기 힘듭니다. 대부분은 정확하게 사용해도 그렇지 않은 단어가 있을 수 있습니다. ‘()’를 표준 용어로 등록했는데, ‘+채무로 사용하지 않고 주채무로 사용하면 오류입니다.

 

간혹 +채무주채무를 둘 다 허용하기도 하는데, 이는 매우 느슨한 표준화 정책입니다. 해당하는 대상이 많아질 때는 표준화를 안 한 것과 비슷한 상태가 됩니다. 가능한 엄격한 원칙을 정해야 하는 게 표준화입니다. 사소한 예외가 쌓이지 않도록 하는 게 표준화의 가장 중요한 원칙입니다. 한 글자 단어를 표준 단어로 허용하지 않으면 +채무는 원천적으로 사용하지 못하게 되죠. 생각할 필요도 없습니다.

 

() 또한 유사한데요. ‘를 허용하면 비용과 혼용해서 사용할 수 있습니다. ‘사업+사업+비용이 같이 사용되는 것이죠. ‘관리+관리+비용’, ‘감가+상각+감가+상각+비용등 많이 발생할 수 있습니다. 이런 현상도 ()’를 단독으로 사용하지 못하게 하면 다소 해소됩니다. 대신 관리비라는 복합어를 등록해야 됩니다.

 

한 글자 단어를 허용하면 또한 컬럼 명의 길이가 길어집니다. 더 많은 단어로 분할되면서 구분자(“_”)가 포함되기 때문에 컬럼 명이 자연히 길어질 수밖에 없습니다. 저는 이것이 한 글자 단어를 피해야 하는 가장 커다란 이유라고 생각합니다. 이 현상에 대해서는 복합어를 설명할 때 자세하게 언급하겠습니다.

 

사용의 혼란스러움을 원천봉쇄하거나 줄일 수 있으면서, 골치 아픈 문제인 컬럼 명이 길어지는 현상도 억제할 수 있기 때문에 한 글자 단어를 표준 단어로 등록하지 않는 게 바람직합니다.

 

()’()’ 등은 실생활에서도 단독으로 사용하지 않고, 명사와 합쳐져서 사용됩니다. 단독으로는 존재 의미가 없기 때문에 표준 용어가 아닙니다. 더군다나 위와 같은 문제를 일으키니 허용하지 않는 것이 좋습니다.

 

 

표준 단어의 다양한 분류

 

표준 단어는 단일어와 복합어로 나눌 수 있습니다. 단일어는 쪼갤 수 있는 단어가 아니기 때문에 판단이 쉽습니다. 계좌, 고객, 거래 등이 단일어입니다. 의미 상 더 분해되지 않는 단순 명사로 표준 단어의 대부분을 차지합니다.

 

복합어는 두 단어가 합쳐진 단어입니다. 두 단어가 합쳐진 형태도 크게 두 가지로 나눌 수 있습니다. 앞서 설명한 것과 같이 한 글자 단어가 다른 명사에 합쳐져서 복합어가 되고요. 이는 부작용을 피하기 위해 편의를 따른 것일 수 있습니다. 한 글자 단어를 표준 단어로 등록하는 정책이 더 많지만, 바람직하지 않다고 생각합니다.

 

다른 한 가지는 주민등록번호’, ‘한국은행과 같이 여러 명사가 합쳐진 순수한 복합 명사입니다. 이와 같이 여러 명사가 합쳐진 복합어는 생각보다 많을 수 있습니다. 부가가치세와 같이 업무에서 사용되는 복합 명사 성격의 단어는 표준 단어로 등록하는 게 좋습니다.

 

복합어를 최소한으로 사용해야 한다는 정책 때문에 복합 명사를 복합어로 등록하지 않는 경우가 더 많은데요. 복합 명사는 그 자체로 복합어이고, 하나의 의미를 가지는 단어이기 때문에 표준 단어로 등록하는 게 바람직합니다. 그래야 의미도 명확해지고, 컬럼 명이 짧아지게 됩니다. 컬럼 명을 줄이기 위해 불가피하게 복합어를 사용하는 경우도 피하게 되고요. 복합어에 대해서는 별도의 장에서 자세하게 설명하겠습니다.

 

표준 단어는 표준어와 금지어로 구분할 수도 있습니다. 금지어의 어감이 좋지 않아 유사어나 대체어라는 용어를 사용하기도 합니다. 사실 이런 금지어는 대개 사전적으로는 표준어인데 일관되게 사용하려고 시스템에서 금지시킨 단어입니다. 어쨌든 저는 명확하게 금지어란 용어를 사용하겠습니다.

 

표준어가 아닌 유사어가 금지어가 됩니다. 금지어는 당연히 사용을 금지하게 됩니다. ‘사원을 표준어로 정하면 직원은 금지어가 됩니다. ‘휴대전화가 표준어이면 휴대폰이나 모바일폰은 금지어가 되는 식입니다. 이음동의어일 때 표준어를 하나 정하면, 나머지는 모두 금지어가 됩니다. 이것이 표준화의 가장 근본적인 원칙입니다.

 

직원을 금지어로 정했지만, 직원 단어가 필요할 때가 있습니다. 예를 들면 고유 명사에 포함된 경우입니다. 이때는 직원이 포함된 복합어를 만들어서 사용하면 됩니다.

 

금지어도 표준어와 마찬가지로 메타 시스템에서 관리하게 됩니다. 그래야 사용을 원천봉쇄할 수 있습니다. 또한 금지어에 대한 표준화를 보여줘서 사용을 유도해야 합니다. 표준어 하나에 금지어가 여러 개 존재할 수도 있고요.

 

금지어는 대부분 임금(급여에 대한 금지어)과 같은 이음동의어가 지정되며, 사번(사원번호)과 같은 축약어나 수익율(수익률)과 같은 문법에 어긋나는 단어, 결제인(결제자)과 같이 특정하게 정해 놓은 단어, 영문 단어(CRM)에 대한 한글 단어(고객관계관리) 등이 될 수 있습니다.

 

마지막으로 표준 단어는 도메인(분류어)과 비도메인으로 구분할 수 있습니다. 금액, 번호 등의 표준 단어는 도메인이 될 수 있지만, 결재, 사원 등의 표준 단어는 도메인이 될 수 없습니다. 도메인에 대해서도 별도의 장에서 자세하게 설명하겠습니다.

 

 

표준 단어의 구성 요소

 

표준 단어는 단어명, 영문, 영문약어, 정의 등으로 구성됩니다. 단어명은 한글, 영어 알파벳, 숫자만 사용할 수 있습니다. ‘고객’, ‘CRM’, ‘1주일등과 같습니다. 영어 알파벳은 대문자만 허용되고요. 특수 문자는 허용하지 않는 것이 원칙이지만 ‘S&P’와 같이 고유 명사에 포함된 경우 허용할 수 있습니다.

 

영어 단어는 그대로 쓰지 않고 한글화해서 사용합니다. ‘EMAIL’ 보다는 이메일로 쓰는 식이죠. 물론 ‘CRM‘처럼 영어 단어가 표준어이고 한글 단어가 금지어인 경우도 있습니다. 그리고 약어나 비표준어는 가능한 사용하지 않아야 하고요. 당연히 단수 형태로 사용합니다.

 

영문약어(이하 약어)는 중요합니다. 영문을 바탕으로 줄여서 사용하는데요. 약어는 2~3자리로 정하는 게 좋습니다. 4자리도 가능하지만 가능한 짧은 게 좋습니다.

 

컬럼 명이 길어지면 좋지 않은데요. 오라클의 경우처럼 28자리로 한정돼 있지 않더라도 25자 가까이 된다면 불편합니다. 컬럼 명을 줄이는 두 가지 주요 방법 중 하나가 단어의 약어를 짧게 만드는 것입니다. ‘코드라는 단어의 경우 ‘CODE’보다는 ‘CD’가 낫습니다. 나머지 한 가지 방법은 복합어를 사용하는 것입니다. ‘유형+코드(TY_CD)’로 사용하기 보다 유형코드(TCD)로 사용하면 컬럼 명이 짧아집니다.

 

약어는 영문의 축약어입니다. 일부 약어는 약어만으로 의미가 통하는 것이 있습니다. ‘부가가치세의 약어인 ‘VAT’가 이에 해당합니다. 이렇게 통상적으로 의미가 통하는 약어는 사용하는 게 바람직합니다.

 

하지만 대부분은 한국인이 보기에 통상적으로 의미가 통한다고 볼 수 없습니다. 간혹 축약규칙에 국제 표준을 적용하거나, 약어의 의미를 지나치게 집착하는 경우도 있는데 큰 의미는 없을 거 같습니다. 물론 약어가 많이 길어지지 않고 정하기 어렵지 않다면, 미국인이 보기에도 의미가 통하는 약어를 사용하는 게 좋지만요.

 

약어는 유일해야 하는 게 원칙인데요. 중복되는 약어가 있다면 이음동의어 형태가 됩니다. 사실 이는 크게 불편하지 않을 수 있습니다. 컬럼 명을 보고 속성 명을 추측할 때 다소 혼란스러울 수는 있지만, 이 경우는 속성 명을 보고 정확히 이해하게 되니까요. 대략의 규칙을 정해서 약어를 생성하는데 불가피하게 중복되는 경우가 발생한다면 중복을 허용할 수 있다고 생각합니다.

 

약어는 보통 4자리 이하로 정하기 때문에 그 이하의 영문이 있다면 영문을 그대로 약어로 사용할 수 있습니다. 예를 들어 나이의 영문이 ‘AGE’라면 약어도 ‘AGE’로 사용할 수 있습니다. ‘AG’로 사용할 수도 있고요.

 

‘1주일처럼 숫자가 포함되는 표준 단어의 경우, 컬럼 명으로 사용되는 점을 고려해서 약어는 숫자를 뒤에 사용합니다. ‘1W’가 아니라 ‘WK1’‘W1’ 등으로 정합니다.

 

약어는 반드시 대문자로 사용하고 약어에는 당연히 ‘_’가 사용되지 않습니다. 예를 들어 복합어인 국내총생산‘G_D_P’ 등으로 사용하지 않습니다. 약어에는 ‘_’가 없어야 합니다.

 

이상으로 표준 단어에 대한 설명을 마치겠습니다. 단어에 대한 개략적인 부분을 포함했습니다. 속성 명과 연관된 다른 부분도 시간이 되면 공유하겠습니다.

 

 

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

두 가지 종류의 표준 도메인  (0) 2017.12.23
복합어에 대한 정리  (0) 2017.12.10
표준 단어에 대해서  (0) 2017.11.19
속성 명 정하는 방법  (0) 2017.10.22
도메인 개념과 대표 속성  (0) 2017.09.09
화면 용어를 관리하려면  (0) 2017.06.18
블로그 이미지

블루퍼필

댓글을 달아 주세요

엔터티 명은 상당히 중요합니다.

제가 매우 강조하는 부분이에요.

속성 명도 중요하긴 한데, 중요하게 취급하기에는 개수가 너무 많고 잘못됐을 때 치명적이지 않습니다.

 

그래도 잘못 정했을 때의 부작용이 없는 건 아닙니다.

속성 명과 데이터가 전혀 다른 경우가 많습니다.

변용해서 사용했거나 처음부터 잘못 사용한 경우죠.

 

제 책에서 속성 명에 대한 설명은 많지 않습니다.

더욱이 방법을 소개하진 않았는데, 이 글에서 간단한 방법을 소개하겠습니다.

 

속성은 도메인 자체가 중요합니다.

금액, 날짜, 내용, , 번호, 여부, 코드 등의 도메인이 속성의 성격을 바로 나타내죠.

속성에서 관리하는 데이터의 성격을 구분하게 하는 게 도메인입니다.

그래서 우선 도메인의 종류와 의미를 파악해야 합니다.

도메인은 사이트마다 조금씩 다를 수 있습니다.

 

도메인이 금액, 날짜, 내용 등이면 아래와 같이 정할 때 의미가 통해야 합니다.

 

~ + 금액

 

주문한 금액, 취소한 일자 등처럼 의미가 통하면 주문금액, 취소일자 등으로 사용합니다.

 

반면에 도메인이 명, 번호 등이면 ‘~를 붙여 의미가 통하는지를 봅니다.

 

~ +

 

고객의 이름, 보증서의 번호 등으로 통하기 때문에 고객명, 보증서번호로 사용하면 되고요.

 

도메인이 정해지면 위와 같이 ‘~‘~를 붙여 의미가 통하도록 정하는 게 우선입니다.

100%는 아니지만 매우 정확하며, 무엇보다 익숙해지면 쉽게 붙일 수 있습니다.

 

위와 같은 규칙은 도메인의 앞에 붙이는 단어를 결정합니다.

‘~앞에 붙는 전체 속성 명에 해당하는 규칙은 아래와 같습니다.

 

~() + ~한 일자

~() + ~ + ~한 일자

~+ ~() + ~ + ~한 일자

 

첫 번째 규칙의 예는, 계좌가 거래한 금액(계좌거래금액)과 같습니다.

두 번째 규칙도 자주 나오는데, 고객이 입금을 취소한 금액(고객입금취소금액)과 같이 쓰이고요.

외부의 고객이 상품을 주문한 금액(외부고객상품주문금액)은 세 번째 규칙에 해당합니다.

 

위의 규칙이 중요한 건 아닙니다.

의미가 중요합니다.

누가 무엇을 ~한 도메인식으로 의미가 통하도록 정한다는 게 핵심입니다.

 

‘~앞에 붙는 규칙도 유사합니다.

 

~ + ~의 번호

~ + ~ + ~의 번호

 

주문한 담당자의 번호(주문담당자번호), 고객이 주문한 상품의 이름(고객주문상품명) 등처럼 사용됩니다.

 

속성 명을 정할 때, 대부분 풀어서 말이 되는지를 볼 것입니다.

고객명 속성은 고객의 이름으로, 거래수수료원화금액 속성은 거래한 수수료의 원화 금액으로 풀어서 의미가 통하면 속성 명으로 적절한 것입니다.

이를 나타낸 게 위에서 설명한 ~, ~의 등을 붙이는 방법입니다.

 

위의 몇 가지 규칙을 오래 연습하면 자연적으로 속성 명을 붙일 수 있습니다.

물론 자신만의 법칙을 만들면 더 좋습니다.

자신만의 법칙을 사용하면서 다른 사람들도 이해하는지를 살핀 다음에 법칙을 개선한다면 좋은 방법론이 생기는 것입니다.

 

속성 명이 한 두 개 이상한 거면 대세에 지장은 없는데요.

전반적으로 이상하면 엔터티도 이상해질 수 있고 모델의 가독성과 품질이 떨어집니다.

대개의 경우 위의 규칙만 지켜도 이상한 의미가 되지 않으니 참고하세요.

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

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

블루퍼필

Tag 속성명

댓글을 달아 주세요

표준화 관련된 글을 간혹 올릴 생각입니다.

티가 안 나서 그렇지 제 책에 표준화에 대한 내용이 다소 있습니다.

 

표준화에 대한 언급을 자제한 이유가 있는데요.

그렇지 않아도 속성 표준화 위주로 모델링을 하는 실정이라 더 그렇게 될까 우려되기 때문입니다.

 

하지만 어차피 표준화는 모델링에서 빠질 수 없는 부분입니다.

잘 하면 본전이고, 제대로 못 하면 타격을 받을 수 있는 부분이라 중요합니다.

표준화에만 매달리는 것도 문제지만, 표준화를 가볍게 보는 것도 문제입니다.

 

사설이 길어지고 있는데, 표준화는 속성 명을 정하는 것과 연관되기 때문에 숙고해야 하니다.

댱연히 모델러도 양질의 표준 컨텐츠를 만들기 위해 노력해야 합니다.

 

표준화는 메타시스템과 연관될 수밖에 없어 매타시스템 기능을 일부 언급했지만, 모델러가개념을 이해하고 잘 사용했으면 하는 게 목적입니다.

분야가 다소 달라서 표준화에 대한 언급을 자제한 면도 있지만, 연관될 수밖에 없네요.

 

오늘은 도메인 개념에 대해 잠시 설명하겠습니다.

 

우선 메타시스템의 도메인 개념이 광범위한 거 같습니다.

대표적으로 ‘~코드속성을 도메인으로 분류하는데, 일반 속성(용어)으로 분류하는 게 좋습니다.

‘~코드속성은 일반 도메인과 성격이 많이 다릅니다.

코드 인스턴스도 관리해야 하고요. 오너십도 관리하는 게 좋습니다.

무엇보다 속성 자체니까요.

 

도메인이라 용어 자체가 애매하기도 합니다.

타입과 자릿수, 포멧 등이 동일한 것을 의미하는데요.

넓게 보면 모든 속성은 도메인이 될 수 있죠.

다소 포괄적인 개념이라 ‘~코드속성이나 계좌번호같은 주 식별자 속성도 도메인에 포함된 거 같아요.

 

하지만 도메인은 용어의 뒤에 붙는 단어로 보는 게 명확합니다.

가격, 금액, 내용, , , 일자 등이 도메인인 것이죠.

그리고 이는 단어를 의미합니다.

단어 중에서 속성(용어)의 뒤에 붙는 단어가 도메인입니다.

 

도메인을 사용하는 목적은 데이터 품질을 향상시키기 위함입니다.

간단히 타입과 길이를 맞추는 역할을 합니다.

일자라는 도메인을 사용하면서 어떤 속성에는 ‘30’을 의미하고, 다른 속성에서는 년월일을 의미하고, 또 다른 곳에서는 년월일시분초를 의미하는 등으로 사용하지 못하도록 하는 것이죠.

도메인은 데이터의 성질을 일치시키는 역할을 합니다.

 

계좌번호고객번호와 같은 주 식별자 속성도 도메인이 아닙니다.

저는 이를 대표 속성이라고 구분하는데요.

일반 속성인데, 대표로 사용될 수 있는 속성이죠.

대표로 사용되는 성격 때문에 도메인으로 구분되는 거 같습니다.

속성(용어)과 도메인(단어)은 구분하는 게 좋습니다.

 

대표 속성에는 크게 두 가지가 있습니다.

단독 주 식별자 속성은 모두 대표 속성입니다.

‘~번호’, ‘~ID’가 대표적이죠.

 

그리고 속성 앞에 이전, 이후, 최종 등의 접두어를 붙일 때, 원천 속성도 대표 속성이 됩니다.

예를 들어 주문금액이란 속성 앞에 변경전을 붙여 변경전주문금액속성을 만들 때, 주문금액 속성은 대표 속성이 됩니다.

앞에 수식어가 붙었지만 원천 속성과 같은 의미를 나타내면, 그 원천 속성은 대표 속성이 됩니다.

의미가 동일하니 데이터의 타입이나 길이, 포멧 등도 같아지겠죠.

 

도메인을 사용하는 목적이 데이터 타입이나 길이를 일치시는 것인 반면에, 대표 속성을 사용하는 이유는 몇 가지가 있습니다.

원론적으로는 같은 의미를 나타내는 역할을 합니다.

계좌번호입금+계좌번호속성은 같은 것을 의미합니다.

만약 전자가 우리의 수신 계좌를 나타내는 계좌번호라면 후자도 우리 수신 계좌를 나타내는 계좌번호입니다.

우리의 외환 계좌번호도 아니며 다른 은행의 수신 계좌번호도 아닙니다.

우리의 수신 계좌번호인데 입금할 때 사용한다는 걸 의미할 뿐이죠.

 

따라서 입금계좌번호속성을 등록할 때 대표 속성으로 계좌번호를 지정하면 위와 같이 의미가 같아지는 것입니다.

데이터의 타입과 길이가 일치되는 것은 기본이고요.

 

위와 같이 대표 속성을 지정하면 또 다른 효과가 있습니다.

계좌번호에 대한 컬럼 명이 달라지지 않습니다.

계좌번호의 컬럼 명이 ‘ACNO’라면, ‘입금+계좌번호의 컬럼 명은 ‘DP_ACNO’가 됩니다.

 

만약 대표 속성으로 지정하지 않으면 ‘DP_AC_NO’가 될 수 있습니다.

그렇게 되면 다른 것을 의미한다고 생각할 수 있게 됩니다.

데이터 타입이나 길이가 달라질 수도 있고요.

같은 것을 의미하는데도 컬럼 명이 달라졌다면 표준을 위배한 것이 되고요.

 

대표 속성을 사용해야 하는 이유는 영문이 달라지지 않도록 하는 게 큽니다.

입금계좌번호송신계좌번호수수료이체계좌번호든 우리 수신 계좌를 의미하면 대표 속성으로 계좌번호를 지정해야 컬럼 명의 뒷 부분이 동일해집니다.

 

대표 속성을 등록할 때 주의해야 할 점이 있습니다.

우선 주 식별자를 의미하는 대표 속성의 영문 명, 즉 컬럼 명은 단어의 조합이 아니라 ‘_’가 없는 약어로 만드는 게 바람직합니다.

 

매우 자주 쓰이고 다양한 역할로 쓰일 것이기 때문에 영문을 간략하게 만드는 게 좋습니다.

부가가치세‘VL_AD_TX’로 하지 않고 ‘VAT’로 하는 것과 같습니다.

계좌번호를 단어의 조합인 ‘AC_NO’로 하지 않고 ‘ACNO’ 또는 ‘ACN’으로 만드는 것입니다. ‘고객번호‘CT_NO’가 아닌 ‘CTN’으로 만드는 것이죠. 컬럼 명을 줄이는 효과가 있습니다.

 

오라클은 컬럼 명을 30자리까지 만들 수 있는데, 30자를 초과하는 컬럼 명이 생각보다 많이 나옵니다.

비율로는 1%도 안 될 것이지만 개수로는 수십 개가 되는데, 생각보다 처리하기 골치 아픕니다.

길이 제한이 없어도 가능한 짧은 게 좋습니다.

 

단독 주 식별자와 같이 생성 시점부터 알 수 있는 대표 속성은 “_”없이 컬럼 명을 정할 수 있는데요.

변경전+주문금액처럼 생성 시점에는 대표 속성이 아니었지만, 수식어가 붙을 때 대표 속성이 되는 경우에는 위와 같이 미리 정할 수가 없습니다.

이 때는 당연히 주문금액‘OD_SM’으로 쓰이고 있을 것이기 때문에, ‘변경전주문금액‘BC_OD_SM’이 될 것입니다.

 

단독 주 식별자 대표 속성은 모델러가 해당 엔터티를 설계한 후에 등록하는 게 특징입니다. 일반 속성 중에 의미가 명확하다면 모델링 전에 미리 등록할 수 있지만, 주 식별자 대표 속성은 모델링이 끝난 후에 등록하는 게 바람직합니다.

의미 파악이 정확히 끝난 후에 속성 명을 메타시스템에 등록하는 게 원칙입니다.

 

표준화도 내용이 많아서 정리가 안 되네요.

정리하면서 가끔씩 올리겠습니다.

 

'데이터 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
블로그 이미지

블루퍼필

댓글을 달아 주세요

엔터티에 속할 속성 명에 사용되는 용어를 소위 표준화하는 것은 이제 일반적이다. 표준 용어를 정해 속성 명으로 사용한다. 표준 용어는 메타 시스템에서 관리한다.

 

최근에는 속성에 사용될 표준 용어 외에도 화면 용어를 관리하려는 요건이 있다. 10년 전에도 들었지만 그 당시에는 바람 정도였다. 하지만 지금은 구현하려는 시도를 한다. 아마 지금은 DA라면 듣게 되는 것 중의 하나일 것이다.

 

화면 용어이기 때문에 AP 영역(AA)에서 이 기능을 구축해야 할 거 같지만, DA 영역에서 이 기능을 구축할 수 있다. 속성 명과 연관이 돼서 메타 시스템에서 구현하는 게 가장 효과적이다.

 

다만 실제 컨텐츠(화면 용어)DA에서 관리할 수 없다. 메타 시스템과 연동돼서 DA에서 기능은 구현하지만 컨텐트는 사용하려는 각 업무 담당자가 관리해야 한다.

 

화면 용어는 속성 명과 연관된다는 것이 핵심이다. 속성 명은 메타 시스템에서 용어로 관리된다. 따라서 화면 용어도 메타 시스템에서 관리되는 게 바람직하다. 메타 시스템은 DA 전용 시스템이 아니라 업무에서도 사용하는 통합 시스템이다.

 

화면 용어는 속성 명(용어)과 일대다(1:M)의 관계라는 것도 중요하다. 속성 명은 고객명이지만 화면에 따라 고객명으로 그대로 쓸 수도 있지만, ‘고객 성명’, ‘고객 이름등으로 가독성이 좋은 용어를 사용하거나, ‘계약자 이름’, ‘WM 고객 이름등 업무에 더 적절하게 사용할 수 있기 때문에 속성 명에 대한 화면 용어는 여러 개가 될 수 있다. 속성 용어와 화면 용어의 관계는 아래와 같다.

 

[그림1]

 

요건의 상세화에 따라 추가 속성이나 엔터티가 생길 수 있지만, 기본 토대는 위의 모델과 같다. 깊이 고려하진 않았지만 화면 용어는 화면과 연동될 것이어서 설계가 더 이어질 것이다.

 

메타 DB에 등록된 화면 용어를 업무 DB에서 사용하는 방법은 통합코드를 사용하는 방법과 같다. 통합코드는 메타 시스템에서 관리하는데, 메타 DB와 업무 DB는 다르기 때문에 메타 시스템에 등록된 통합코드가 승인될 때마다 EAI 등을 통해 실시간으로 업무 DB에 데이터를 전송해야 한다.

 

메타 시스템에서 등록한 용어와 화면 용어 데이터를 업무 DB에 있는 [그림1] 모델로 가져와서 사용하면 된다. 화면에서 필요한 용어가 있다면 [그림1] 화면용어 엔터티에서 해당 데이터를 찾아서 사용한다.

 

화면 용어는 AA에서 기능을 만들고, 속성 명과 연동되도록 사용할 수도 있다. 메타 시스템의 표준 용어를 가져와서 화면 2~3개로 구현할 수 있을 것이다. DA 영역을 잘 알기 때문에 메타 시스템에서 구현하는 것으로 설명했지만, 기능을 어디에서 구현하는 것은 추후의 문제다. 중요한 것은 속성 명과 화면 용어는 논리적으로 일대다(1:M) 관계라는 것이다. [그림1] 모델처럼 구현돼야 한다.

 


'데이터 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
블로그 이미지

블루퍼필

댓글을 달아 주세요

복합어를 사용하는 이유는 크게 두 가지입니다.

 

첫째, 관용화된 용어를 사용하기 위해서입니다. 대상이 많지는 않지만 단어와 단어가 합쳐져서 뉘앙스가 달라지는 경우가 있습니다. 용어에 민감한 사람들은 이를 관리하고 싶어 합니다.

 

여기서, ‘용어란 주로 영문 단어를 의미할 것입니다. 한글 단어 조합의 의미를 따지기도 하지만 주로 영문 조합의 의미를 따집니다. 예를 들어, 부가가치세는 부가+가치+이지만 영문은 ‘VAT’로 쓰는 게 명확하다는 것이죠.

 

복합어를 사용하는 둘째 이유는 영문(컬럼 명)의 길이가 길어지는 것을 막기 위해서입니다. ‘부가가치세를 복합어로 만들지 않으면 영문이 ‘VL_AD_TX’ 정도가 됩니다. 단어별로 두 자리의 약어를 사용해도 8자리가 되죠. 이를 복합어로 만들어 ‘VAT’로 정하면 3자리니 훨씬 짧죠.

 

부가가치세에 대한 영문이 꼭 ‘VAT’여야 한다는 것보다는 길어지기 때문에 ‘VAT’를 사용합니다. 이는 현실적인 이유죠. 다시 말해 전자의 이유보다는 후자 때문에 복합어가 많이 쓰입니다.

 

기업에서 주로 사용되는 복합명사는 복합어로 등록해서 영문명이 길어지는 것을 방지할 필요가 있습니다. 도메인 성격의 대표 속성이기도 한 고객번호, 계좌번호, 상품번호 등과 주민등록번호, 전화번호 등은 자주 사용되는 복합명사이기 때문에 복합어로 등록하는 것이 좋습니다. 단어 조합인 ‘CUST_NO’로 하기보다는 복합어인 ‘CUNO’, ‘ACCT_NO’ 보다는 ‘ACNO’로 정하는 게 효과적이죠.

 

복합어를 사용하는 문제는 복합어를 나중에 만들 때 발생합니다. 예를 들어 모두 단어로 구성된 +어카운트+계좌+개설+확인+사원+번호는 영문으로 변환하면 매우 길어집니다. 만약 DBMS에서 30자라까지 허용한다면, 영문을 줄이기 위해 단어를 적절하게 합쳐서 복합어를 만들어야 합니다.

 

(오라클은 컬럼 명을 30글자까지 허용하는데, 30자면 매우 길어서 그렇게 긴 컬럼 명이 있을까 싶지만 비교적 빈번하게 발생한다. 이를 방지하는 두 가지 방법은 이 글의 주제인 복합어를 활용하는 것과 단어의 영문 약어를 짧게 정하는 것이다.

 

후자의 경우, 가독성 때문에 단어의 영문 약어를 자세히 정한다면 컬럼 명이 매우 길어질 수 있다. 단어에 대한 영문 약어를 일괄 4글자로 정하기도 하는데 바람직하지 않다. 2~3글자로 정하는 것이 좋다.)

 

컬럼 명을 줄이기 위해 복합어를 만들지 않으려면 속성 명을 수정해야 하는데, 이는 당연히 의미가 손상되지 않는 경우에만 허용됩니다. 하지만 속성 명에는 생략해도 의미가 통하는 단어만 사용하는 게 원칙이기 때문에, 이렇게 정해진 속성 명에서 특정 단어를 생략하면 의미가 통하지 않는 게 당연합니다. 속성 명을 임의로 줄여서 컬럼 명의 길이를 줄이는 방법은 사용하기 어렵습니다.

 

이렇게 뒤늦게 복합어(‘랩어카운트’)가 생기면 이전에 사용하던 것(‘+어카운트’)과의 혼선이 발생합니다. 위의 경우 랩어카운트라는 복합어를 만들어서 해결했다면, 이미 사용되던 +어카운트와 영문이 달라지게 됩니다. ‘WAC’‘WR_AC’ 정도로 다르게 쓰이죠. 이는 큰 문제는 아니지만 어쨌든 표준을 해치는 일입니다.

 

이런 표준화 위배를 최소화하기 위해서는 복합어 랩어카운트랩어카운트계좌개설확인사원번호속성에만 사용해야 합니다. 그리고 추후에 +어카운트로 인해 길이 제약이 생기는 속성이 생긴다면 그 경우에 사용해야 합니다.

 

불가피한 경우만 나중에 생긴 복합어 랩어카운트를 허용하고 표준은 애초의 표준인 +어카운트가 돼야 하는 것이죠. 이를 피하기 위해서는 애초에 복합어를 제대로 등록하는 게 중요합니다.

 

모델 구조에 비하면 위와 같은 표준화 문제는 크지 않을 수 있습니다. 하지만 원칙을 정했다면 원칙에 맞도록 사용하는 것이 바람직합니다. 잘못된 원칙은 개선하는 게 맞고요.

 

제대로 된 원칙을 지킬 의지가 없거나, 제대로 되지 않은 원칙을 개선할 의지가 없다면 좋은 시스템이 되기 힘들 것입니다. 시스템뿐만 아니라 모든 분야가 마찬가지겠죠.



'데이터 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
블로그 이미지

블루퍼필

댓글을 달아 주세요

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

 

반면에 테이블 명을 정하는 방법은 간단합니다. 대개 두 가지 방법 중에서 하나를 택해서 사용합니다. 방법을 결정하는 것은 대개 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 보면서 개발하는 것입니다.
      이게 지켜지면 테이블 명이 어떻든 그다지 중요하진 않을 거 같습니다.

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