태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

공통 코드 데이터를 통합 관리하는 엔터티를 설계할 때, 코드 유형과 코드 인스턴스를 같이 관리할 수 있도록 한 개의 엔터티로 설계한다.

 

[그림 통합코드] 통합코드 엔터티는 코드 유형과 코드를 통합 관리할 수 있도록 설계한 엔터티다.

 

[그림 통합코드]

 

유형통합코드 속성은 해당 코드에 대한 코드 유형이 무엇인지를 관리하는 속성이다. 통합코드 엔터티에 대한 릴레이션은 아래와 같다.

 

[통합코드]

#통합코드

통합코드명

유형통합코드

001

매수매도구분코드

{null}

002

직급종류코드

{null}

00101

매수

001

00102

매도

001

00201

사원

002

00202

대리

002

00203

과장

002

 

[그림 통합코드-릴레이션]

 

유형통합코드 속성 값이 널(null)인 인스턴스는 코드 유형을 의미한다. 즉 통합코드 값이 ‘001’매수매도구분코드‘002’직급종류코드코드 유형을 의미하고 나머지는 코드 인스턴스를 의미한다.

 

통합코드 속성 값에도 규칙이 있다. 통합코드 속성 값의 앞 세 자리의 값과 유형통합코드 속성 값이 같으면 해당 코드 유형에 속한 코드의 인스턴스를 의미한다. 따라서 통합코드 속성 값만으로도 해당하는 코드 인스턴스를 알 수 있다. 그러므로 통합코드 속성 값의 앞의 세 자리가 유형통합코드 속성 값과 일치하도록 관리해야 한다.

 

이는 중복 데이터로 볼 수도 있고 주 식별자 값에 의미를 부여하는 것은 일반적으로 바람직하지 않지만, 코드 데이터는 어플리케이션에서 사용하기 편리하도록 관리하는 게 중요하다.

 

이 방법은 코드 유형과 코드 인스턴스를 한 엔터티에서 관리하면서 데이터에 임의의 의미를 부여함에 따라 엔터티의 성격이 분명하지 않아 잘못 사용될 수 있다는 단점이 있다. 또한 많은 엔터티에 사용되는 코드 속성에 5bytes의 값이 저장된다는 점은, 2bytes의 값을 사용하는 일반적인 방법에 비해 저장 공간 차원에서도 단점이다.

 

하지만 이 방법은 조회 쿼리를 매우 단순하게 만든다. 예를 들어 [그림 통합코드-릴레이션] 릴레이션에서 코드에 해당하는 리스트를 보여주는 쿼리는 아래와 같아서 다른 방법과 크게 다르지 않다.

 

Select 통합코드, 통합코드명

From [통합코드]

Where 유형통합코드 = ‘001’ /* 매수매도구분코드 */

 

반면에 목록화면이나 상세화면에서 해당 엔터티에 사용된 코드값을 보여주는 쿼리는 아래와 같다.

 

Select A.계좌번호, B.통합코드명

From [거래내역] A, [통합코드] B

Where A.매수매도구분코드 = B.통합코드

 And A.계좌번호 = ‘1234567890’

 

코드 인스턴스를 조회하는 특별히 다르지 않지만 상세화면에서 사용하는 이 쿼리는 코드 유형을 나타내는 구문이 조건절에 없는 게 특징이다. 이는 속성 값에 코드 유형까지 포함된 코드를 저장했기 때문에 코드 엔터티와의 조인을 통해 바로 코드명을 알 수 있기 때문이다. 즉 거래내역 엔터티의 매수매도구분코드 속성 값에 ‘00101’ 등이 입력돼 있어 조인을 통해 바로 알 수 있다.

 

반복적으로 사용되는 쿼리 패턴이 단순해지는 것은 커다란 장점이다. 쿼리에 상수가 쓰이지 않아 실수를 방지할 수 있다는 점은 부수적인 장점이다.

 

또 다른 장점은 모든 코드를 통합 관리하는 통합코드 엔터티와 거래내역 엔터티처럼 코드를 사용한 엔터티 간의 관계선을 표현하기 수월하다는 점이다. 이는 참조 무결성 제약을 생성할 수 있다는 것을 의미하며, 데이터 무결성을 높일 수 있다는 것을 의미한다.

 

공통 코드 데이터는 중요하므로 데이터 품질에 특별히 신경 써야 한다. [그림 통합코드-관계] 모델처럼 코드를 사용하는 거래내역 엔터티와 통합코드 엔터티와의 관계선을 표현하고, 참조 무결성 제약을 생성해서 데이터 무결성을 보장할 수 있다는 점은 가장 커다란 장점이다.


 [그림 통합코드-관계]

 

코드 모델은 공통 코드 데이터를 제대로 관리할 수 있으면서 사용하기 편하도록 설계하는 것이 중요하다. 전자를 만족시키는 것이 코드를 통합하는 것이고, 후자를 만족시키는 것이 코드값에 대한 규칙을 부여한 것이다.



블로그 이미지

블루퍼필

댓글을 달아 주세요

개인적으로는 속성 명이 길어나는 건 반대입니다.

하지만 통합 코드를 구분하는 게 의미가 있어 매뉴얼에 포함시켰습니다.


--


통합코드 엔터티에서 관리되는 코드를 사용하는 속성 명은 ‘~통합코드로 정하며, 구분/종류/유형과 같은 구분자를 붙여서 정한다. 따라서 일반 코드 속성 명은 ‘~구분통합코드’, ‘~종류통합코드’, ‘~유형통합코드와 같이 사용한다.

 

코드 속성은 비코드 속성과 성격이 다르기 때문에 속성 명을 구분해서 정하는 것이 좋다 속성 명을 구분하면 사용법이 자연스럽게 구분되기도 한다.

 

주 식별자 속성과 같은 비코드 속성은 하나의 인스턴스가 하나의 실체(개체)를 의미하므로 구분/유형/종류 등을 사용하는 것이 적절하지 않지만, 일반 코드는 하나의 개체를 의미하는 것이 아니라 범주를 의미하므로 구분/종류/상태/등급/방법/단위 등과 같이 구분자(Discriminator) 역할을 하는 용어와 함께 사용하는 것이 적절하다.

 

다만 이런 구분자의 종류가 많을 경우 분별하려는 의도가 퇴색될 수 있으며, 선택할 때 복잡할 수 있다. 또한 상태 등과 같은 구분자는 그 자체로 의미가 있기 때문에 구분/종류/유형으로 구분하는 게 간명하다.

 

또한 통합 관리하는 코드를 의미하도록 속성 명에 ‘~통합코드로 사용해서 혼란이 없도록 할 수 있다.

 

‘~구분통합코드는 코드 인스턴스가 향후에도 거의 늘어나지 않을 만큼 고정적인 코드를 나타낸다. 이런 코드 중에서 코드 인스턴스가 두 개뿐일 때 ‘~여부로 사용하는 경우가 있지만, 코드로 정의해서 코드 인스턴스를 명확히 구분하는 것에 바람직하다. 그래야 대비되는 값을 알 수 있다. 예를 들어 남자여부보다는 남녀구분코드가, ‘매수여부보다는 매수매도구분코드가 더욱 명확하다.

 

‘~종류통합코드는 고정적이지 않고 지속적으로 늘어날 수 있는 코드명을 나열할 때 사용한다. 기업에서 제공하는 서비스를 코드로 설계할 때는, 사업을 하면서 계속 늘어날 수 있으므로 서비스종류코드로 정한다.

 

‘~유형통합코드는 성질이나 특징이 유사한 것끼리 묶을 때 사용한다. 큰 묶음이므로 코드 인스턴스가 종류코드보다 코드 인스턴스가 많지 않고 거의 늘어나지 않는다. 개인과 법인을 나타내는 고객유형코드가 이에 해당한다.

 

이렇게 일반 코드의 속성 명을 구별해 사용할 때의 장점은 비코드 속성과 분명하게 구분할 수 있다는 점이다. 또한 크진 않겠지만 코드 속성 명을 정하는 시간을 줄여주며, 의사소통을 원활하게 하는 데 도움을 주고 가독성을 높여준다. 속성 명이 길어진다는 것은 단점이 될 수 있지만 구분하는 장점이 크다고 생각한다.

 

다른 문제는 일반 코드로 사용하다 식별자 코드가 될 때 속성 명이 바뀐다는 것이다. 예를 들어 일반 코드 속성으로 국가종류통합코드를 사용하다 식별자 코드로 사용할 때는 국가번호가 돼서 속성 명이 바뀌게 된다. 이를 방지하는 방법은 처음부터 코드 속성 설계를 제대로 하는 것이다. 즉 하나의 개별 개체를 의미하는 데이터에 대해서는 범주를 의미하는 일반 코드로 정의하지 않는 것이다.

 

국가는 하나의 인스턴스가 실제의 한 실체를 의미하기 때문에 애초부터 국가 엔터티로 설계해야 하는 후보다. ‘대한민국이라는 인스턴스는 아시아와 같은 묶음을 의미하는 유형이 아니며 개별 개체다.

 

식별자 코드와 일반 코드에 대해서 명명 규칙을 정해 사용하는 것은 의미가 있다. 이 둘을 유사하거나 같은 것으로 생각하는 것도 명명법과 무관하지 않기 때문에 구분하는 것이 좋다.

 

블로그 이미지

블루퍼필

댓글을 달아 주세요

내부에서 생성하는 일반 코드는 코드별 개별 코드 엔터티로 설계하지 않고 하나의 통합 코드 엔터티를 설계해서 통합 관리한다.

 

예를 들어 관리하려는 데이터가 개인, 법인 등의 고객 유형을 나타내면 이는 코드 성격의 데이터다. 이 코드 인스턴스를 관리하기 위해 엔터티를 설계할 때, 고객유형만을 관리하는 엔터티를 설계하는 것이 아니라 [그림1] 모델처럼 다른 유형의 코드까지 관리하는 엔터티를 설계해서 모든 내부 코드를 통합 관리하도록 한다.

 



[그림1]

 

코드 성격의 데이터는 해당하는 인스턴스를 별도의 시스템에서 관리하는 게 일반적이다. 코드를 통합 관리하는 시스템에서 코드 인스턴스를 등록하고, 등록된 코드 인스턴스를 업무 시스템에서 사용하는데, 업무 시스템에서 사용할 엔터티가 [그림1] 모델과 같다.

 

코드유형 엔터티에서는 코드 유형이 무엇인지를 관리하고 코드 엔터티에서는 해당 유형에 포함된 코드 인스턴스가 무엇인지를 관리한다. 이에 대한 릴레이션은 아래와 같다.

 

[통합코드유형]

#통합코드유형번호

통합코드유형명

001

고객유형코드

 

[통합코드]

#통합코드유형번호

#통합코드번호

통합코드명

001

01

개인

001

02

법인

 

[그림2]

 

만약 내부에서 관리하는 코드를 통합 관리하지 않고 [그림3] 고객유형 엔터티와 같이 각 코드를 관리하기 위한 엔터티를 개별적으로 설계한다면 많은 코드 엔터티가 생기게 된다.

 


[그림3]

 

엔터티가 많아지는 것은 단점이 될 수 있어서 주의해야 한다. 코드 엔터티가 많아지면 많은 관계로 인해 모델 가독성이 나빠진다. 고객 엔터티 같은 주요 엔터티는 코드 속성이 매우 많을 수 있는데, 고객 엔터티가 많은 코드 엔터티에 둘러쌓이면서 관계선을 표현하면 모델은 상당히 복잡해질 수 있다.

 

또한 코드 데이터만을 관리하는 시스템이 있다면 많은 코드 엔터티와 연동해서 값을 관리하기가 쉽지 않다. 통합 코드 엔터티를 관리하는 것에 비하면 매우 비효율적이다.

 

개별 코드 엔터티로 설계하면 저장 공간 낭비 측면에서 비효율이 발생한다. 한 종류의 코드 인스턴스는 몇 개 안 되므로 한 블록에 저장하면 많은 공간이 쓰이지 않고 낭비되는데, 이는 데이터를 조회할 때 많은 블록이 사용된다는 것을 의미하므로 비효율이 발생된다.

 

만약 모든 내부 코드 데이터를 하나의 통합 엔터티에서 관리하면 한 블록에 많은 종류의 코드 데이터를 저장할 수 있다. 그리고 이 블록이 메모리에 한 번 상주하면 디스크 I/O 없이 메모리 I/O가 발생해 블록이 다시 사용될 가능성이 커진다. 메모리 적중률(Hit Ratio)이 높아져 성능이 좋아진다.



블로그 이미지

블루퍼필

댓글을 달아 주세요