표준 단어에 대해서

데이터 Story/데이터 상념(想念) 2017.11.19 22:52

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

 

그동안 속성 명을 정한 게 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.11.19
[worst practice 4]  (0) 2017.11.04
worst practice  (0) 2017.10.28
속성 명 정하는 방법  (0) 2017.10.22
[worst practice 2]  (3) 2017.09.30
모델러의 상처  (0) 2017.09.25
Trackback 0 : Comment 0

지나가기만 하고 되돌아오지 않는 과거는 없다

일상 Story/좋은글 2017.11.15 21:07

"지나가기만 하고 되돌아오지 않는 과거는 없다."


주역에 나오는 문장이다.

과거는 지나갔지만 되돌아온단다.

과거는 시간이 아닌가. 어떻게 되돌아오지.

역사는 반복된다고 하는데... 반복되니 과거에서 배워야겠다.


저작자 표시 비영리 변경 금지
신고
Trackback 0 : Comment 0

[worst practice 4]

데이터 Story/데이터 상념(想念) 2017.11.04 10:49

요건은 아래와 같습니다.

 

-부서명, 전화번호, 부서장 등의 부서에 대한 기본 정보를 관리한다.

-전화번호, 부서장 등의 데이터는 변경될 수 있어 이력 관리한다.

 

위의 요건을 설계한 모델이 아래와 같습니다.

잘못된 부분을 생각해 보세요.

 

 


[그림 1]

 

 

--

 

이력 데이터를 어떻게 설계할지에 대한 문제입니다.

 

이력 데이터를 원천 엔터티에 통합해서 관리하면 좋을 때가 있고 그렇지 않을 때가 있습니다. [그림 1]은 그렇지 않을 때에 해당돼서 아래와 같이 관리하는 게 바람직합니다.

 


[그림 2]

 

실체를 관리하는 엔터티나 기본 정보를 관리하는 엔터티, 기준 정보를 관리하는 엔터티는 이력 데이터를 원천 데이터와 같이 관리하지 않는 것이 좋습니다.

 

실체 데이터는 한 번 생기면 그대로 존재하는 것이어서, 특성(속성)이 바뀐다고 새로운 인스턴스로 생성하면 데이터 성격을 반영하지 못 한 것이라 하나의 인스턴스로 존재해야 하고요. 기본 정보나 기준 정보 또한 실체 성격을 포함하고 있기도 하고, 참조하기 좋아야 하기 때문에 그렇습니다.

 

행위 엔터티가 아닌데 일자 속성이 주 식별자에 존재하면 한번 더 고민하셔야 됩니다. 대개 이력 데이터를 포함시켜서 그렇게 되는데 바람직하지 않습니다.

 

쉽게 생각해서 참조되는 엔터티는 관계선을 표현할 수 있도록 설계해야 합니다. 조인해서 사용한다는 의미니까요. [그림 1]이라면 다른 엔터티와 조인해서 사용하기 매우 어려운 상태입니다. 약간씩 다르지만 [그림 3]도 역시 마찬가지로 모두 바람직하지 않습니다.

 

   

  

[그림 3]

 

일부 기본 정보를 관리하는 엔터티는 [그림 1]처럼 원천 데이터와 이력 데이터를 같이 관리할 수 있습니다. 굳이 나눠서 관리하면 엔터티 개수만 늘어나서 같이 관리할 수 있는데, 조인해서 사용하지 않을 때만 가능합니다.

 

[그림 4] 모델도 간혹 보는데, 많이 참조되는 주요 엔터티가 이렇게 설계되면 매우 난감해집니다. 어떻하든 사용은 가능하지만요.

 


[그림 4]



저작자 표시 비영리 변경 금지
신고

'데이터 Story > 데이터 상념(想念)' 카테고리의 다른 글

표준 단어에 대해서  (0) 2017.11.19
[worst practice 4]  (0) 2017.11.04
worst practice  (0) 2017.10.28
속성 명 정하는 방법  (0) 2017.10.22
[worst practice 2]  (3) 2017.09.30
모델러의 상처  (0) 2017.09.25
Trackback 0 : Comment 0

티스토리 툴바