본문 바로가기

데이터 Story/데이터 표준

도메인 개념과 대표 속성

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

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

 

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

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

 

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

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

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

 

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

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

 

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

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

 

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

 

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

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

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

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

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

 

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

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

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

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

 

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

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

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

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

 

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

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

일자라는 도메인을 사용하면서 어떤 속성에는 ‘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
속성 명 정하는 방법  (2) 2017.10.22
화면 용어를 관리하려면  (0) 2017.06.18
복합어에 대한 상념(想念)  (0) 2017.05.14
테이블 명을 정하는 방법  (2) 2017.05.03