태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

'메타시스템'에 해당되는 글 2건

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

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

 

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

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

 

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

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

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

 

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

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

 

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

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

 

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

 

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

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

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

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

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

 

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

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

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

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

 

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

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

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

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

 

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

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

일자라는 도메인을 사용하면서 어떤 속성에는 ‘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
블로그 이미지

블루퍼필

댓글을 달아 주세요