태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

엔터티에 반복되는 속성은 정규화를 하는 것이 원칙이며, 특히 속성이 묶음으로 반복된다면 정규화를 한다.

 

단독 속성이 반복되면, 추가되지 않고 고정적인지를 고려해서 정규화를 하지 않을 수 있지만 묶음 속성이 반복되면 정규화를 하는 것이 원칙이다.

 

[그림 1] 모델은 주문상품에 대한 속성(상품번호/상품가격/상품수량)이 반복된 비정규형 모델이다.



[그림 1]

 

주문상품에 대한 속성인 상품번호, 상품가격, 상품수량 속성이 묶여서 세 번 반복됐기 때문에 비정규형 모델이다. 이 모델은 세 개의 속성이 묶여서 반복됐기 때문에 정규화를 해야 한다. [그림 2] 모델이 [그림 1] 모델에 대한 정규형 모델이다.


 

[그림 주문정규화]

 

정규화를 한 주문상품 엔터티는 주문과는 다른 의미를 나타내는 별도의 엔터티다. 즉 엔터티의 성격에 맞도록 엔터티가 도출된 것이다.

 

[그림 3] 년간상품주문집계 엔터티는 주문수량과 그에 대한 주문금액을 1월부터 12월까지 관리하는 엔터티다.


 

[그림 3]

 

위 모델도 수량과 금액이 묶음으로 반복됐기 때문에 [그림 4] 모델과 유사한 정규형 모델로 설계해야 한다.


 

[그림 4]

 

위와 같이 묶음으로 속성이 반복될 때는 [그림 1] 모델처럼 함께 관리되는 속성이 묶음이 되도록 표현하는 게 좋다. 아래 모델처럼 관리하면 가독성이 많이 떨어진다.


 

[그림 5]

 

위의 모델은 함께 관리되는 속성이 무엇인지 명확하지 않다. 예를 들어 상품번호 속성이 주문수량 속성과 별개로 반복되는 것으로 잘못 이해될 수도 있다. 같이 관리되는 속성은 같이 위치하도록 해야 가독성도 좋아지고 정규화하기도 좋다.

 

묶음 속성이 반복되면 반복 속성이 많아지는 것도 문제지만, 묶음 속성 값이 정확하게 관리되지 않을 가능성이 커지기 때문에 정규화하는 것이 원칙이다. 만약 [그림 1] 주문 엔터티의 상품번호 속성 값과 상품가격 속성 값이 쌍을 이루지 않는다면 데이터가 훼손된 것이다. 묶음 번호를 잘못 사용하거나, 묶음 속성이 떨어져 있거나 하는 이유로 잘못 사용할 가능성이 있다. 모델이 복잡해서 가독성이 떨어지는 것은 당연하다. 묶음을 이룬 속성의 개수가 많다면 이런 문제는 더욱 증폭된다.

 

기본적으로 속성이 묶음으로 관리된다는 것은 다른 성격의 데이터임을 의미한다. 원천 엔터티와 다른 성격의 데이터인데 종속 관계의 데이터라서 한 엔터티에서 관리해도 무난하게 보이는 것일 뿐이다. 묶음 속성이 반복되는 것은 바람직하지 않으므로 정규화를 해야 한다.

 

블로그 이미지

블루퍼필

댓글을 달아 주세요

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

 

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

 

[그림 통합코드]

 

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

 

[통합코드]

#통합코드

통합코드명

유형통합코드

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) 역할을 하는 용어와 함께 사용하는 것이 적절하다.

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

블로그 이미지

블루퍼필

댓글을 달아 주세요

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

 

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

 

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


  

[그림1]

 

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

 

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

[교육과정]

#교육과정번호

교육과정명

교육기관코드값

001

데이터 모델링

01

002

데이터 품질

02

003

오라클

03

 [그림2]

 

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


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

 

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

 


블로그 이미지

블루퍼필

댓글을 달아 주세요

외부 코드를 내부 코드와 통합 관리할 때, 외부에서 받은 코드 값을 그대로 사용하지 않아도 된다면 외부 코드 값을 내부 코드 표준에 맞게 관리한다.

 

외부 기관과 데이터를 주고받을 때, 외부 기관에서 정한 코드 값이 데이터에 포함되는 경우가 많다. 이때 외부 코드 값이 많이 사용되지 않고 간혹 사용된다면 외부 코드를 내부 코드 표준에 맞게 통합 관리할 수 있다.

 

[그림1] 모델은 코드를 관리하는 일반적인 모델에, 외부 코드를 관리할 수 있도록 설계한 모델이다.

 


[그림1]

 

외부에서 받은 코드 값은 ‘KOR’이지만 내부에서는 ‘01’ 등 내부 표준을 정해 관리한다면, 통합코드 엔터티의 외부코드값 속성에는 ‘KOR’ 값으로 관리하고, 통합코드번호 속성에는 내부 표준에 맞춰서 ‘01’로 관리한다.

 

외부에서 받은 코드는 길이가 일정치 않기 때문에 외부코드값 속성의 데이터 타입 길이는 충분히 크게 정한다. 이 속성은 내부 코드일 때는 널 값이기 때문에 널 허용이어야 한다.

 

통합코드유형 엔터티의 내부외부구분코드 속성은 중복 속성으로 삭제할 수 있지만 구분해 주는 것이 좋다. 원칙적으로 통합코드 엔터티의 외부코드값 속성 값이 널 값이면 내부 코드고, 값이 존재하면 외부 코드다.

 

[그림1] 모델에 대한 릴레이션은 아래와 같다.

 

[통합코드유형]

#통합코드유형번호

통합코드유형명

내부외부구분코드

001

고객유형코드

내부

002

국가구분코드

외부

 

[통합코드]

#통합코드유형번호

#통합코드번호

통합코드명

외부코드값

001

01

내국인

{null}

001

02

외국인

{null}

002

01

대한민국

KOR

002

02

아르헨티나

ARG

002

03

독일

GER

002

04

미국

USA

 

[그림2]

 

통합코드유형 릴레이션에서 내부와 외부 코드인지를 구분한다. 통합코드 릴레이션의 통합코드번호 속성에는 내부에서 정한 값(01)으로 관리하고, 외부에서 받은 코드값(KOR)은 외부코드값 속성에서 관리한다.

 

만약 외부에서 받은 코드 값을 내부 시스템에서 그대로 사용한다면, 외부 코드 값을 내부 코드 표준을 따르지 않고 그대로 코드 값으로 사용한다.

 

[그림3] 통합코드 엔터티의 통합코드 속성은 내부와 외부 코드를 통합 관리하는 속성이다.

 

[그림3]

 

외부에서 정한 코드까지 포함되므로 통합코드 속성의 데이터 타입 길이는 충분히 길게 정한다. 코드가 외부인지 내부인지는 통합코드유형 엔터티의 내부외부구분코드 속성으로 관리한다.

 

[그림3] 모델에 대한 릴레이션은 아래와 같다.

 

[통합코드유형]

#통합코드유형번호

통합코드유형명

내부외부구분코드

001

고객유형코드

내부

002

국가구분코드

외부

 

[통합코드]

#통합코드유형번호

#통합코드

통합코드명

001

01

내국인

001

02

외국인

002

KOR

대한민국

002

ARG

아르헨티나

002

GER

독일

002

USA

미국

 

[그림4]

 

통합코드 릴레이션의 세 번째 인스턴스와 같이 외부 코드에 대한 코드 값을 외부에서 정한 값 그대로 관리한다. 외부에서 받은 코드 값을 내부 코드 값과 같이 관리한다.

 

이처럼 외부 코드값을 그대로 사용하면 내부 코드 값과 혼합되어 일관성 없이 사용되는 단점이 있다. 내부 코드값은 표준에 따라 두 자리로 관리되고, 외부 코드 값은 자릿수가 제각각이 된다.

 

하지만 외부 코드값을 사용할 때 받은 값 그대로 사용하기 때문에 그 값을 코드로 관리하면 사용할 때 혼동되지 않는다. 또한 자주 사용하는 값을 그대로 코드로 사용하기 때문에 더 직관적이다.



블로그 이미지

블루퍼필

댓글을 달아 주세요

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

 

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

 



[그림1]

 

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

 

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

 

[통합코드유형]

#통합코드유형번호

통합코드유형명

001

고객유형코드

 

[통합코드]

#통합코드유형번호

#통합코드번호

통합코드명

001

01

개인

001

02

법인

 

[그림2]

 

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

 


[그림3]

 

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

 

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

 

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

 

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



블로그 이미지

블루퍼필

댓글을 달아 주세요

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

 

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

 


[그림 거래매체유형]

 

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

 

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

 

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

 

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

 


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

 

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

 

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



블로그 이미지

블루퍼필

댓글을 달아 주세요

엔터티의 인스턴스가 개별 개체를 의미하면 코드 속성으로 설계하지 않고 엔터티로 설계한다. 개별 개체를 의미한다는 것은 묶이기 전, 변형되기 전의 순수 데이터를 의미한다.

 

예를 들어 국가 집합에 속한 인스턴스가 대한민국, 호주, 일본 등이라면 각각은 개별 개체를 의미하기 때문에 엔터티로 설계한다.

 

만약 외국인 고객을 관리하는 엔터티에서 해당 고객의 국적을 관리한다면 [그림1] 모델처럼 국가 엔터티를 별도로 설계하여 외국인고객 엔터티와 관계선을 표현한다.

 


[그림1]

 

위와 같이 개별 개체를 의미하는 국가를 엔터티로 설계해서 관리하지 않고, [그림2] 모델과 유사하게 국가 엔터티 없이 통합 코드 엔터티나 별도의 시스템에서 관리하는 국가코드 속성으로 설계하는 것은 바람직하지 않다.

 


[그림2]

 

국가 데이터는 데이터 성격 상 코드 성격이 아니기 때문에 현재는 국가명 밖에 관리하지 않는다고 하더라도 나중에 관리해야 할 속성이 다양하게 존재할 수 있다.

 

반면에 엔터티의 하나의 인스턴스가 개별 개체를 의미하지 않고 개별 개체를 묶은 개념을 의미한다면 코드 속성으로 설계해야 한다. 예를 들어 어떤 집합이 아시아, 유럽, 오세아니아 등이라면 데이터 성격 상 개별 개체라고 볼 수 없으며, 이는 어떤 개체를 묶은 개념이므로 엔터티로 관리하는 게 아니라 코드 속성으로 관리하는 것이 원칙이다.

 

데이터를 설계할 때 엔터티로 설계해야 할 것을 코드로 설계하면 추후에 문제가 발생할 수 있다. 이런 문제를 사전에 방지할 수 있는 것은 애초에 데이터 성격에 맞게 엔터티를 도출하는 것이다. 데이터가 실제의 개체를 의미하는지, 개체의 묶음을 의미하는지에 따라 판단하면 적절하다.

 

만약 인스턴스 성격이 개별 실체를 의미하지만 관리하고자 하는 특성이 명()뿐이어서 코드 속성으로 관리할 수 있다. 하지만 이 경우라도 추후에 부가 속성이 생길 가능성이 조금이라도 있기 때문에 실체를 의미하면 엔터티로 설계하는 것이 원칙이다.

 

간혹 어떤 집합은 실체를 의미하지만 개체 전체를 관리하지 않을 수 있다. 즉 집합 인스턴스가 대한민국/중국/일본 등으로 동북아시아 국가만 관리하면서 명()만 관리한다면, 인스턴스가 개체를 의하지만 동북아시아국가코드 등의 코드로 관리할 수 있다.



블로그 이미지

블루퍼필

댓글을 달아 주세요

원천 엔터티가 실체 엔터티일 때는 변경이력 데이터를 별도의 엔터티에서 관리하도록 설계한다.

 

[그림1고객실체 엔터티는 실체인 고객 데이터를 관리하는 실체 엔터티다.

 

[그림1]

 

만약 고객명 속성이나 전화번호 속성의 변경이력 데이터를 관리할 때, 고객은 실체이기 때문에 아래 모델처럼 별도의 엔터티에서 변경이력 데이터를 관리하도록 설계한다.

 

[그림2]

 

고객실체 엔터티의 속성 중에서 하나라도 변경되면, 그 시점의 고객실체 엔터티 인스턴스는 고객실체이력 엔터티로 이동한다.

 

고객실체이력 엔터티는 변경된 과거 데이터이므로 주로 사용되지 않으며, 필요 시에만 참고 용도로 사용하기 위해 보관하는 역할을 한다.

 

실체 엔터티는 실체에 대한 개별 인스턴스를 관리하는 엔터티다. 실체 엔터티에서 실체의 변경된 데이터까지 관리한다면, 이미 실체 자체를 의미하는 것이 아니라서 엔터티의 정의가 달라진다.

 

실체 엔터티에서는 실체의 존재 자체를 관리해야 하므로 실체 엔터티의 인스턴스 개수와 실제 실체의 개수가 같아지도록 관리하는 게 바람직하다.

 

없어진 실체에 대해서는 해당 인스턴스를 삭제하지 않기 때문에 인스턴스 개수와 현재 존재하는 실체의 개수가 달라질 수 있지만, 이를 감안해서 존재했던 실체의 개수와 엔터티의 인스턴스 개수는 일치해야 한다.

 

대부분의 데이터가 그렇지만 특히 실체를 관리하는 데이터는 현재의 최종 데이터를 주로 사용하기 때문에 변경된 과거 데이터를 함께 관리하지 않는다. 자주 사용하지 않는 데이터를 실체 엔터티에 포함시키는 것은 효율적이지 않다.

 

더구나 실체 엔터티는 하위 엔터티가 많기 때문에 실체 엔터티에 변경이력 엔터티를 포함시키면 하위 엔터티와의 관계 때문에 데이터를 관리하기 복잡해진다.

 

만약 실체 엔터티임에도 불구하고 변경이력 데이터를 최종 데이터와 함께 자주 사용하거나, 변경된 인스턴스에 대해서도 하위 인스턴스와 관계가 필요하다면 실체 엔터티에 변경이력 데이터를 포함시킬 수 있다.



블로그 이미지

블루퍼필

댓글을 달아 주세요

엔터티 간의 관계에서 생기는 관계 속성은 한 엔터티에 여러 개가 있을 수 있으며, 그 관계 속성 중에는 유사한 성격의 속성이 있을 수 있다. 이때 유사한 관계 속성이 두 개 이상이며, 추가될 가능성이 조금이라고 있다면 별도의 관계 엔터티로 설계한다.

 

[그림1] 보험계약 엔터티에는 세 개의 관계 속성이 존재한다.

 


[그림1]

 

보험을 계약한 고객과 보험의 피보험자 고객, 보험의 연대보증 고객이 누구인지를 관리하는 속성이 관계 속성이다. 따라서 계약고객번호/피보험고객번호/연대보증고객번호 속성은 관계 속성이며, 관계선이 세 개이므로 관계 속성과 마찬가지로 관계 명에도 역할(Role) 이름을 사용한 모델이다.

 

이미 세 개의 관계 속성이 존재하지만 연대 보증인의 경우에는 여러 명을 관리할 수도 있어서 관계 속성이 더 늘어날 가능성이 있다. 이렇게 관계 속성이 늘어날 가능성이 있을 때는 아래 모델처럼 별도의 엔터티에서 관계를 관리한다.

 

[그림2]

 

보험계약당사자 엔터티는 관계(역할) 엔터티(Relationship Entity). [그림1] 보험계약 엔터티에 있던 관계 속성을 관리하는 엔터티다.

 

이와 같이 엔터티에서 관계를 관리하면 관계가 늘어나더라도 보험계약당사자 엔터티의 인스턴스만 늘어나므로 모델에는 영향을 미치지 않는다. 계약자/피보험자/연대보증인 이외의 다른 유형이 생겨도 당사자유형코드에 인스턴스만 추가하면 된다.

 

[그림2] 모델은 매우 유연한 모델이다. 업무 자체가 변경되지 않는 경우를 제외하면 관계 엔터티와 같은 정규형 엔터티를 사용해야 한다.

 

만약 관계 속성의 수가 완전히 고정적이라면 [그림1] 모델과 같이 관계 속성으로 관리할 수 있다. 업무가 변하지 않아서 계약자/피보험자/연대보증인 고객이 각각 한 명이고, 다른 유형의 고객은 생길 수 없다면 관계 속성으로 관리하는 게 바람직하다.

 


블로그 이미지

블루퍼필

댓글을 달아 주세요

  • 최상운 2017.03.22 01:12  댓글주소  수정/삭제  댓글쓰기

    머라고 불러야 하나...김이사는 좀 그렇고...그냥 이름 부를게 기창!!

    1년만에 소속을 듣네...뉴질랜드에 갔군...

    우리 나이가 되면 '내가 잘 살고 있나?' 라고 한 번쯤은 생각을 하지...삶에 터닝 포인트를 만들고 싶지만 운신의 폭은 그리 넓지 않지...가진건 별로 없지만 그나마 있는 것이라도 지키고 싶어서...

    자네의 결정이 좋을 결정이 되길 바래. 돌아 오는 날까지 자네와 집 사람 그리고 아이들 건강하고

    난 여전히 회사에 있어...나에게도 좀 작은 변화를 주려고 노력 하고 있고...시간되면 연락줘 이메일이 좋겠군 samuelc@empal.com