태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

오늘은 비전에 대한 글을 짧게 써보려고 합니다.

저의 비전이니 데이터인들의 비전일 수 있다고 생각합니다.

 

차세대 등의 개발 프로젝트에서 소프트웨어를 분리 발주하듯이, 데이터 분야도 분리 발주해야 한다는 것이 제 생각입니다.

발주사 입장에서 모델링, 표준화, 이행, 튜닝 등의 DA 영역은 별도로 계약하는 것입니다.

 

데이터 분리 발주를 주장하는 이유는 바로 아시겠죠?

시스템의 토대가 되는 데이터 구조를 제대로 구축하기 위함이고, 사업의 근간이 되는 데이터를 제대로 관리하기 위함입니다.

 

현재는 수행사가 발주사와 전체 계약을 하고, 필요 시 데이터 분야에 대해서는 수행사가 데이터 전문 업체와 계약을 합니다.

 

이런 방식으로라도 데이터 전문 업체를 참여시키면 좋을 텐데 현실은 그렇지 않은 경우가 많습니다.

수행사에는 코디네이터 역할을 할 데이터 아키텍트만 있고, 개발자가 모델링, 표준화, 튜닝을 다 하는 게 현실입니다.

 

개발자는 자신이 개발할 영역에 대해서 모델링부터 개발, 튜닝까지 모든 부분을 다 해야 하니 기술적으로 벅찰 수밖에 없습니다.

수많은 개발자가 각자의 방식으로 하니 일관성도 떨어지고, 품질이 떨어집니다.

 

데이터 영역을 분리 발주했을 때, 발주사 측이 얻게 될 가장 커다란 장점은 데이터 산출물에 대한 품질입니다.

모델 구조가 제대로 설계되고, 그에 맞게 데이터가 제대로 관리돼 사업하기 좋은 데이터를 확보하게 되는 것입니다.

좋은 모델을 운영하면 여러 가지로 효율적입니다.

 

수행사 입장에서의 장점은 중복 개발을 방지하고 개발을 효과적으로 할 수 있다는 점입니다.

모델의 잦은 변경으로 인한 개발 비효율이 많이 개선됩니다.

매번 느끼는 것이지만 이 부분이 가장 큰 거 같습니다.

지출하지 않아도 되는 비용을 소비해 적자가 되는 것을 방지할 수 있습니다.

 

또한 골치 아픈 데이터 영역은 신경 쓰지 않을 수 있다는 점도 장점입니다.

잘 아는 부분이 아니라서 간혹 큰 곤혹을 당하기고 하고요.

전문가 집단이 고객을 상대하니 일이 수월해지기도 합니다.

 

데이터 영역이 이슈도 많아서 처음부터 전문 업체와 계약하는 수행사도 많은 편입니다.

이슈가 생긴 후에 전문 업체를 찾는 경우도 많지만요.

수행사 입장에서는 거추장스러운 혹을 떼고, 우왕좌왕하지 않을 수 있다는 점이 장점입니다.

 

데이터 분리 발주를 하면 발주사 측이 느낄 가장 큰 불편함은 관리일 것입니다.

 

계약을 나눠서 하는 것이니 행정적으로 불편할 것이고요.

프로젝트 수행 시에는 애플리케이션과 데이터 양쪽을 관리한다고 생각할 수 있습니다.

 

수행사 측의 단점은 생각하기 나름일 거 같지만, 몫이 줄어든다는 점일 거 같습니다.

 

관리하기 힘들 수 있다는 발주사 측의 단점은 크지 않을 수 있습니다.

 

분리 계약이 돼도 어차피 수행사가 전체 프로젝트를 이끄는 것입니다.

사업관리나 QA도 역할을 해야 하고요.

PMO나 감리도 있기 때문에 관리 차원에서 우려할 것은 크지 않을 것입니다.

 

발주사가 수행사와 계약할 때, 데이터 분야에 대한 관리를 일임하게 될 것입니다.

데이터 영역을 분리 발주한다고 데이터 영역 내에 사업관리나 QA 등이 있는 건 아니니까요.

데이터 전문 업체는 산출물을 만드는 역할만 하게 됩니다.

프로젝트 관리에 대한 계약은 수행사가 하는 것이니, 데이터 영역 관리는 자연스럽게 포함됩니다.

 

또한 계약이 어떤 형식이든, 발주사 내에도 DA가 있기 때문에 데이터 영역에 대한 관리는 유사하게 이루어집니다.

수행사 내에서도 관리나 코디네이터 역할을 하는 DA는 필요하고요.

 

데이터 분리 발주가 법으로 정해진다면, 위에서 언급한 대로 가장 중요하고 어려운 데이터를 전문가에게 맡기는 것이니 시스템이 제대로 구축되는 기반이 생기는 것입니다.

 

전문적인 일은 전문가에게 맡겨야 자잘한 사고도 급격히 줄어듭니다.

준전문가나 비전문가에게 전문적인 일을 맡기는 방식은 이제 지양해야 합니다.

대형 사고 발생 확률은 높지 않고, 발생 시 땜질하면 된다는 사고는 후진적입니다.

 

그리고 현재처럼 데이터 전문 업체가 수행사에 종속된 형태로 일을 하면 생존 자체를 보장할 수 없습니다.

30~40년 전부터 한 번도 중요하지 않은 적이 없었던 데이터이지만 데이터 전문 업체의 성장은 한계가 있었는데, 데이터 분리 발주 법이 제정된다면 데이터 전문 업체도 성장하고 시스템도 한 단계 성장할 것이라고 생각합니다.

 

지금도 데이터를 중시하는 고객은 분리 발주와 유사한 방식으로 데이터 전문 업체에게 데이터 영역을 맡기고 있습니다.

최소한 수행사에 데이터 전문 업체 참여를 필수 조건으로 제시하고 있죠.

 

하지만 미약합니다.

법으로 정해져야 진정한 효과가 생길 것입니다.

시스템에 혁명이 이루어진다고 확신하고 있습니다.

 

데이터 업체들과 데이터인들이 합심하면 이런 꿈을 이룰 수 있다고 생각합니다.

최소한 데이터를 근간으로 이루어지는 시스템 구축에 데이터 전문가가 참여하는 것이 상식인 시대가 될 것입니다.

후대에라도 이룰 수 있었으면 좋겠습니다.

 

부족한 글이지만, 이 글이 제대로 된 데이터 여건을 만드는 마중물 역할을 했으면 좋겠습니다.


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

데이터에 대한 개인적인 비전  (0) 2018.06.23
데이터 아키텍트 프레임웍  (0) 2018.03.31
[worst practice 4]  (0) 2017.11.04
worst practice  (0) 2017.10.28
[worst practice 2]  (3) 2017.09.30
모델러의 상처  (0) 2017.09.25
블로그 이미지

블루퍼필

댓글을 달아 주세요

아래 그림은 데이터 아키텍트가 해야 할 일에 대한 프레임웍입니다. 프레임웍(Framework)이란 전체가 어떻게 구성됐는지를 보여주는 논리적인 틀입니다.



데이터 아키텍트가 해야 할 일은 크게 표준, 구조, 품질 영역으로 구분할 수 있습니다. 각 영역은 업무의 종류에 따라 원칙, 설계, 관리, 시스템으로 구분할 수 있습니다.

 

표준 영역은 데이터에 대한 표준화를 의미합니다. 표준 지침서가 있어야 하고, 표준 단어와 표준 용어와 같은 표준 컨텐츠가 있어야 합니다. 그리고 이런 컨텐츠를 관리하는 메타 시스템이 필요합니다.

 

구조 영역은 데이터 모델을 의미합니다. 마찬가지로 모델링 지침서가 있고, 데이터 주제 영역, 개념 모델, 논리 모델 등이 있습니다. 모델링은 표준 데이터를 이용해서 수행합니다. 모델은 저장소에 저장돼 메타 시스템과 연동되고요.

 

품질 영역은 표준과 구조, 데이터 값에 대한 품질 관리를 의미합니다. 품질을 높일 수 있는다양한 기준(지표)을 관리해서 잘못된 부분을 개선해서 표준, 구조, 값에 대한 품질을 높이기 위한 활동을 하게 됩니다. 이런 활동을 원활하게 하기 위해서는 DQ시스템을 사용하게 됩니다.

 

세로 축인 원칙과 설계, 관리, 시스템은 서로 유기적으로 엮여 있습니다. 원칙에 따라 설계를 해야 하고, 설계 결과를 시스템에 반영해야 합니다. 또한 설계된 결과물은 검토나 승인 과정이 필요하며, 지속적으로 관리돼야 합니다.

 

가로 축인 영역 또한 서로 엮여 있습니다. 데이터 표준에 맞게 데이터 구조를 설계하게 되고, 데이터 구조를 구현한 DB에 저장된 데이터 값과 표준 콘텐츠, 모델 구조 자체에 대한 품질을 높이기 위한 활동을 하게 됩니다.

 

위의 데이터 아키텍트 프레임웍은 DA가 수행해야 할 핵심 요소만을 포함시켰습니다. 데이터 아키텍트는 위에 표현된 일 외에도 많은 역할을 하게 됩니다. 이해 관계자 사이의 의견을 조율하고 DA 조직을 관리하는 일도 하게 됩니다. 데이터와 관련된 각종 이슈를 해결해야 하는 것은 당연한 업무입니다.

 

데이터와 관련된 모든 지식을 총괄하는 사람이 데이터 아키텍트며, 총괄해야 하는 지식을 간단하게 표현한 것이 위의 표입니다.



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

데이터에 대한 개인적인 비전  (0) 2018.06.23
데이터 아키텍트 프레임웍  (0) 2018.03.31
[worst practice 4]  (0) 2017.11.04
worst practice  (0) 2017.10.28
[worst practice 2]  (3) 2017.09.30
모델러의 상처  (0) 2017.09.25
블로그 이미지

블루퍼필

댓글을 달아 주세요

매우 유명한 책인 데이터 모델 리소스 북을 번역했습니다.

모델러라면 한 번쯤은 들어보셨을 것입니다.


미국 업무 설명이 많아 번역하기 힘들었지만, 타우랑가(뉴질랜드) 도서관에서 재미있게 번역했습니다.

아름다운 도시에서 멋진 책을 번역해서 행복했습니다.


참조 모델이 많기 때문에 책상 위에 두고 참고하기 좋은 책입니다.






블로그 이미지

블루퍼필

댓글을 달아 주세요

데이터 모델링 노트의 개정판이 나오게 됐습니다.

이번 책은 회사를 만들고 내는 처음 책이라 감회가 남다릅니다.

많은 관심 부탁드리겠습니다.

 

책의 서문으로 책 소개를 대신하겠습니다.

감사합니다. ㅎ


[서문]

 

관계형 데이터 모델링 프리미엄 가이드에 이어 관계형 데이터 모델링 노트(이하 모델링 노트) 또한 많은 사랑을 받았습니다. 강의를 시작하게 해 준 책이고, 더 큰 도전을 할 수 있는 토대를 마련해 준 책입니다.

 

회사를 나오고 모델링 노트가 품절됐습니다. 여러 가지 일 때문에 일정을 세우지 못하면서 개정판의 출판이 늦어졌습니다. 생각보다 더 늦어졌지만, 직접 설립한 회사 이름으로 나오는 첫 책이어서 더욱 감회가 깊습니다.

 

이번 개정판에서 바뀐 부분은 크게 두 가지입니다.

 

추가된 장이 있습니다.

 

2.15(반복 속성으로 인한 1정규형 위반 사례)에서는 실무에서 많이 발생하는 1정규형의 위반 사례에 대해 설명했습니다. 당연히 지양해야 할 사례이고, 왜 지양해야 하는지에 대한 설명을 강화할 목적으로 추가했습니다.

 

3.6(통합을 고려하지 않아도 되는 경우)에서는 통합을 위한 통합이 되지 않도록 통합하지 않아도 되는 몇 가지 조건을 설명했습니다. 이 조건에 해당되지 않는다면 통합해야 한다는 것을 강조한 것이기도 합니다.

 

4.16(부분 인조 식별자를 사용할 수 있는 경우)은 부분 인조 식별자인 ‘~순번’을 사용할 수 있는 경우에 대해 설명했습니다. 부작용이 심해서 개인적으로 ‘~순번’ 속성을 사용하지 못하도록 합니다. 모델링 노트에서는 일부러 설명하지 않았지만, 질문을 많이 받는 것이기 때문에 추가했습니다.

 

5.20(관계 존재성과 관계 속성의 널(Null) 제약) 5.19장에 대한 보강 설명입니다. 관련 내용을 좀 더 자세하게 적을 수 있었던 것은 ERWIN 9버전의 영향이 컸습니다. ERWIN 7버전까지는 관계 존재성과 관계 속성의 널 제약을 연동시켰는데, 9버전에서는 다른 툴과 마찬가지로 연동되지 않도록 했습니다. 각 개념을 조금 더 잘 이해할 수 있는 환경이 조성돼서 추가했습니다.

 

그 밖에 3.20, 5.17, 5.19장은 내용을 재구성했습니다. 나머지 장은 문장만 다듬었습니다.

 

전반적으로 초판과 비교해 개념이나 이론이 바뀐 부분은 없습니다. 대신 용어가 다소 바뀌었습니다. 우리말로 사용하는 게 적절하다고 느꼈습니다.

 

 -(Role) 이름 ⇒ 수식어

 -디멘젼(Dimension) ⇒ 집계 기준

 -카디널러티(Cardinality) ⇒ 관계비

- 옵셔널러티(Optionality) ⇒ 관계 존재성

 -디그리(Degree) ⇒ 참여수

 -1촌 관계 ⇒ 1차 관계

 -순환 관계(Recursive Relationship) ⇒ 재귀 관계(Recursive Relationship)

- 원형 관계(Circular Relationship) ⇒ 순환 관계(Circular Relationship)

 

마지막 부분은 부연 설명이 필요할 것 같습니다. 모델링 노트에서는 자기 참조 관계를 순환 관계로 표현했고, 세 엔터티 이상의 관계가 원형으로 도는 형태의 관계를 원형 관계라고 표현했습니다. 순환 관계와 원형 관계가 다소 혼동이 돼서 자기 참조 관계를 재귀 관계로, 원형 관계를 순환 관계로 재정의했습니다. 초판에서도 고민한 부분인데, 개정판에서 반영했습니다.

 

모델링 노트 개정판이 다시 개정될 때, 더 많은 내용을 보강할 수 있도록 연구하겠습니다. 모델링 이론이 더욱 견고해질 수 있도록 노력하겠습니다. 다시 한 번 독자 여러분의 관심과 격려에 감사 드립니다.

 

-2018년 겨울 범박동에서

 

 

블로그 이미지

블루퍼필

댓글을 달아 주세요


ㅁ DA 실무와 모델링 교육 (총 20시간) 


1. 개요

 

DA 업무 전반에 대해 소개하며, 표준화에 대한 지침을 상세하게 설명합니다.

DA의 핵심인 모델링의 이론을 모델링 노트 책으로 설명합니다.

총 20시간 교육이며, 신청자에 한해 설계한 모델을 검토하는 3시간이 추가됩니다.

  

2. 내용

 

-DA 실무 4시간

DA일반

표준화

품질

 

-모델링 16시간 + 2주간씩 1.5시간

모델링이론(모델링 노트 내용 전체)

모델링실습(DAP 시험 난이도 2문제 실습. 사전 설계 후 전체 리뷰)

  

3. 인원/수강료

 

-토요일 5주 연속(DAP 시험 포함 시 건너뜀)

-9시~13시(1주~3주), 9시~15시(4주~5주)

-수강료: 20만원

-인원 20명 이내(교육장에 따라 변동)

 

 

 

ㅁ 모델링 심화 교육 (총 30시간)

  

1. 개요

 

모델러로 활동할 수 있도록 모델링에 대한 이론만을 심화 학습하며, 많은 실습을 통해 모델 설계에 익숙해지도록 합니다.

모델링 이론은 모델링 노트 책으로 설명하며, 강의 시간에 약간의 실습을 하고 4주 동안 사전에 주어진 요건을 설계한 후 같이 리뷰하는 과정을 가집니다.

  

2. 내용

 

-모델링 30시간

모델링이론 심화(모델링 노트 내용 전체)

모델링실습(4문제 실습. 사전 설계 후 전체 리뷰)

  

3. 인원/수강료

 

-토요일 5주 연속(DAP 시험 포함 시 건너뜀)

-9시~13시(1주), 9시~17시(4주~5주)

-수강료: 30만원

-인원 10명 이내

 

 

블로그 이미지

블루퍼필

댓글을 달아 주세요


"위즈덤마인드"는 아래와 같은 업무를 수행하는 데이터 모델링 전문 업체입니다.

업계 최고의 품질을 제공해 드립니다.


문의: bluepupi@gmail.com, 010-6320-2229

무료 방문 컨설팅 가능(시간 조정 후 방문)


ㅁ 신규 모델링 구축

 

-기존 ERD의 부분 수정으로는 효과가 없을 시 전면 재구축을 목표로 신규 ERD 설계

-차세대나 고도화와 같이 화면이나 소스까지 변경 필요

-규모에 맞게 모델러가 다수 투입돼 분석/설계 기간에 설계

 

 

ㅁ 리모델링 구축

 

-기존 ERD의 부적절한 부분만을 찾아 재설계

-기존 ERD에 반영 못했던 업무가 반영될 수 있도록 재설계

-소수의 전문 모델러가 길게 수행

-유지보수하면서 반영 가능한 범위 내에서 시행

-유지보수 때보다는 소스 수정이나 데이터 이행이 더 많이 발생

-전면 재개발처럼 한꺼번에 변경하는 게 아니라 점진적으로 변경

-대대적으로 고도화할 수 없는 경우 적절

 

 

ㅁ 데이터 아키텍트(DA) 수행

 

-DA 조직을 이끄는 사람으로 데이터 전체적인 아키텍처를 설계

-표준화. 모델링, 품질, 이행. 튜닝, DBA 등의 데이터 관련 당사자가 많을 경우 반드시 필요한 사람

-작은 프로젝트에서는 표준화와 모델링을 수행하는 사람 중에 리더를 의미

 

 

ㅁ 데이터 모델링 컨설팅

 

-데이터 모델링을 검토하고 가이드하는 통합 모델러 역할

-업무 분석 설계자나 개발자가 모델 설계를 할 경우, 모델을 검증하여 검토 결과서를 작성하고 모델 변경 권유

-소수의 통합 모델러가 통합이나 정규화 위배. 주 시별자 등 핵심적인 부분만을 검토

-데이터 모델링 표준 수립하여 제시

 

 

DA(데이터 아키텍처) 컨설팅

 

-DA 조직 구축이나 DA 업무 범위에 대한 가이드

-단어, 용어 등의 표준 데이터나 ERD에 대한 진단

-ERD와 연관된 표준화나 데이터 값에 대한 진단

 

 

ERD 관리

 

-계정계/업무계 전체 ERD를 통합 관리

-신규 업무에 대해서 TOBE 모델 제시

-엔터티 무결성, 참조 무결성, 도메인 무결성 등 모델의 품질을 높이기 위해 ASIS 모델에 대한 개선 모델 제안

-최소한의 모델링 툴 라이선스로 ERD 관리 가능

 

 

ㅁ 데이터 표준 컨설팅

 

-데이터 모델링과 연관된 표준화 컨설팅 수행

-표준지침. 표준단어. 표준도메인, 표준용어 등 구축 및 가이드

 

 

ㅁ 데이터 품질 컨설팅

 

-표준단어표준도메인 등 표준 컨텐츠 품질 점검

-데이터 모델 구조 품질 점검

-데이터 값 품질 점검

 

 

ISP 컨설팅

 

-EA DA 영역에 대한 컨설팅

-주제 영역 구축, 영역별 개념 모델 설계

-데이터 관리체계 정책 수립

 


블로그 이미지

블루퍼필

댓글을 달아 주세요

위즈덤마인드 대표 컨설턴트 & 데이터 모델러

 

김기창은 데이터 분야에서 15년 이상 일하고 있으며, 현재는 위즈덤마인드에서 대표 컨설턴트로서 데이터 모델링(Data Modeling) DA(Data Architecture) 컨설팅을 하고 있다. 특별히 풍부한 실전을 바탕으로 데이터 모델링을 직접 수행하며, 실무에 적절한 DA 컨설팅을 하는 것이 강점이다.
저서로는 [데이터베이스 활용을 위한 SQL Server 2000], [관계형 데이터 모델링 프리미엄 가이드], [관계형 데이터 모델링 노트]가 있으며, 2007년에는 [전사적 데이터 아키텍처 프레임웍에 대한 개념 모델 개발] 논문을 발표했다.


모델러가 기업에게 제공할 최고의 가치는 좋은 모델을 제공하는 것이라고 생각하고 있다. 소명을 갖고 많은 기업에서 진짜 모델이 운영되는 것을 꿈꾸고 있으며, 그런 모델을 설계하는 진짜 모델러가 많아질 수 있도록 노력하고 있다.

 

 

ㅁ 주요 경력

 

산업은행 차세대 DA

한전 차세대 모델링

미래에셋증권 차세대 모델링

KT OSS 차세대 모델링

기업은행 차세대 DA

농협 시스템분리 ISP DA

삼성증권 차세대 모델링

신한카드 CRM 고도화 DA

한국투자증권 차세대 모델링

SK증권 차세대 모델링

대신증권 차세대 DA

SK증권 ISP DA

서울보증보험 차세대 모델링

LG필립스 EA DA

 

 

ㅁ 저서/저술

 

관계형 데이티 모델링 노트 개정판 (2018)

한국데이터진흥원 전문가 컬럼 연재 (2017~2018)

관계형 데이티 모델링 노트 (2014)

관계형 데이터 모델링 프리미엄 가이드 (2010)

전사적 데이터 아키텍처 프레임웍에 대한 개념 모델 개발 (2007)

데이터베이스 활용을 위한 SQL Server 2000 (2004)

 

 

ㅁ 강의 이력

 

데이터 모델링 & DA(Data Architecture) 강의 200시간 수행



블로그 이미지

블루퍼필

댓글을 달아 주세요

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

 

도메인의 의미는 다소 포괄적입니다. 데이터 모델링에서 도메인(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
블로그 이미지

블루퍼필

댓글을 달아 주세요