태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

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

 

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

 

[그림 통합코드]

 

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

 

[통합코드]

#통합코드

통합코드명

유형통합코드

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’ 등이 입력돼 있어 조인을 통해 바로 알 수 있다.

 

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

 

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

 

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


 [그림 통합코드-관계]

 

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



블로그 이미지

블루퍼필

댓글을 달아 주세요

외부에서 받은 코드를 관리할 때, 코드 값에 대한 명()을 알 필요가 없다면 통합코드 엔터티에서 관리하지 않고 속성에서 값만 관리하며 속성 명은 ‘~코드값’으로 정한다.

 

외부에서 데이터를 받을 때, ‘01’ 등의 코드가 포함됐지만 해당 값이 무엇을 의미하는지, 즉 코드명을 알 필요가 없을 때가 있다. 이때는 해당 코드를 통합코드 엔터티에 등록하지 않는다. 코드 형태라고 모두 통합코드 엔터티에서 관리하는 것은 아니다.

 

[그림1] 교육과정 엔터티는 외부에서 받은 교육 과정 정보를 관리하는 엔터티다.


  

[그림1]

 

교육 기관을 의미하는 교육기관코드에 대해서 ‘01’ 등의 값을 받지만 해당 값이 무엇을 의미하는지, ‘A기관인지 ‘B기관인지 알 수가 없다. 이는 해당 코드명이 사용되지 않는다는 것이다.

 

이렇게 코드명을 알 필요가 없을 때는 ‘01’이라는 값만 받아서 속성에 저정하면 되기 때문에 교육기관코드에 대한 코드 인스턴스를 통합코드 엔터티에서 관리하지 않아도 된다. 아래 릴레이션처럼 ‘01’이라는 값만 관리한다.

[교육과정]

#교육과정번호

교육과정명

교육기관코드값

001

데이터 모델링

01

002

데이터 품질

02

003

오라클

03

 [그림2]

 

교육기관코드값 속성에는 외부에서 받은 코드 값을 그대로 관리하며, 통합코드를 관리하는 엔터티에는 해당 코드를 등록하지 않는다. 교육기관코드값 속성은 일반 코드와 다르기 때문에 속성 명을 ‘~코드값으로 정한다. ‘코드값이라는 도메인이 필요하다.


전문 데이터를 사용할 때 위와 같이 코드명을 모르는 코드를 관리하는 경우가 있다. 이는 받은 데이터를 그대로 관리하기 때문에 발생하는 현상이다.

 

전문 데이터는 별도 시스템이나 텍스트 원문으로 관리하고, 엔터티로 설계할 때는 사용 용도에 맞게 설계하는 것이 원칙이다. 사용하지 않는 데이터, 사용할 수 없는 데이터는 설계하지 않는 것이 좋다.

 


블로그 이미지

블루퍼필

댓글을 달아 주세요

엔터티의 하나의 인스턴스가 개별 개체를 의미하지 않고 개별 개체를 묶은 개념이더라도 명() 외의 다른 속성도 관리해야 한다면, 코드 속성으로 설계하지 않고 개별 엔터티로 설계한다. 즉 개별 개체를 묶은 개념이라도 고유 속성이 필요하다면 엔터티로 설계한다.

 

만약 종합카드/체크카드/신용카드/신탁통장 등 거래 매체의 유형을 관리한다면, 데이터가 개별 개체가 아니라 묶은 개념인 유형을 의미하므로 코드 속성으로 설계해야 한다. 하지만 재발급기간, 발급가능고객종류 등과 같이 매체 유형에 따라 관리해야 할 속성이 존재한다면 [그림 거래매체유형] 거래매체유형 엔터티처럼 별도의 엔터티로 설계한다.

 


[그림 거래매체유형]

 

해당 매체 유형의 재발급 기간을 관리해야 한다면 속성이 필요한 것이어서 위와 같이 엔터티로 설계할 수 밖에 없다.

 

설계 당시에는 관리할 속성이 명() 밖에는 없지만 향후 추가될 가능성이 있을 때도 엔터티로 설계해서 확장 가능하도록 해야 한다. 추가될 가능성이 있는데도 엔터티로 설계하지 않고 코드 속성으로 설계하면 나중에 수정하기 매우 어렵게 된다.

 

비록 하나의 코드 유형에서만 관리된다고 해도 추가해야 할 속성이 일반적인 의미를 나타내는 속성이라면 코드 속성으로 설계해서 코드를 관리하는 엔터티에 필요한 속성을 추가할 수 있다.

 

예를 들어 추가해야 할 속성이 정렬 순서를 의미한다면 이는 다른 코드 유형에도 적용될 수 있는 일반적인 속성이라 코드 엔터티에 추가해도 부작용이 줄어든다. 아래와 같이 일반적인 속성인 정렬순서 속성을 모든 코드를 관리하는 통합코드 엔터티에 추가할 수 있다.

 


[그림 코드엔터티정렬순서]

 

1~2개의 코드유형에 대해서만 정렬순서 속성에 값을 관리하고 나머지 코드유형에는 정렬순서 속성 값을 관리하지 않아 널(Null)이 되더라도 정렬순서 속성은 어느 코드 유형에든 관리할 수 있는 일반적인 속성이라 부작용이 적다.

 

하지만 위와 같이 모든 코드에 적용 가능한 일반적인 속성은 매우 드물다. 코드유형에 따라 고유한 속성이 대부분이다. 어떠한 고유한 속성이라도 한번 허용하면 지속적으로 늘어날 수 있다는 것에 주의해야 한다.



블로그 이미지

블루퍼필

댓글을 달아 주세요