엔티티 통합 대상

 

엔티티 통합은 개념 모델링 단계에서 주로 이뤄지며 가능한 초반에 통합된 모습이 좋습니다.

논리, 물리 모델링 단계에서도 엔티티는 통합될 수 있습니다.

 

실무에서 기본적인 통합 대상은 엔티티를 구성하는 데이터 성격이 유사할 때 입니다.

고객, 계좌, 상품 등과 같은 핵심 실체 엔티티에서 주로 발생합니다.

 

1. 주식을 거래하는 계좌 2. 선물옵션을 거래하는 계좌 3. 수익증권을 거래하는 계좌가 별도로 존재한다면 이것을 통합할 수 있습니다. 계좌는 계약을 통해 개설이되고 거래를 위해 사용되는 매개입니다. 계좌라는 데이터의 성격이 유사한데 거래되는 자산에 따라 계좌를 분리할 이유는 별로 없습니다. 일부 다른 속성이 존재할 수 있지만 이것은 서브타입으로 해결할 수 있습니다. 근본 데이터가 유사해 통합을 고려할 대상이 됩니다. 앞서 이야기한 것처럼 기초 속성으로 데이터의 유사성을 판단하는 것이 적절합니다.

 

실무에서는 일반적으로 업무 구분에 따른 단위 시스템별 계좌 엔티티가 하나씩 존재하게 됩니다. 주식 업무 엔티티, 수익증권 업무 엔티티, 수익증권 계좌 엔티티가 존재합니다. 업무나 시스템으로 분리된 엔티티를 통합하는 것은 현실적으로 쉽지 않습니다. 불가능 할 수도 있습니다.

 

데이터 통합에 최종 결정은 사용자가 하기 때문에 엔티티 통합이 무산되기도 합니다. 하지만 계좌와 같이 관리할 데이터도 유사하며 통합하면 장점은 극대화할 수 있습니다.

 

고객 데이터도 1순위 통합 후보입니다. 개인 고객, 법인 고객 등 고객 데이터의 성격은 유사합니다. 고객의 이름, 연락처 등의 기본 데이터 관리하는 속성을 통합하고 차변화된 개별 속성은 별도로 관리합니다. 비즈니스를 제대로 수행하기 위해서 고객 통합은 선택이 아니라 필수 조건이 되어가고 있습니다. 업무적으로 개인 고객과 법인고객이 같이 사용되지 않으면 모든 애플리케이션이 화면이 분리돼 사용되고 조회나 집계 등도 개별로 이루어지면 통합하지 않는 것을 고려해 볼 수 있습니다. 하지만 그런 업무는 거의 없습니다.

 

계좌 - 계좌번호

계좌관계사원 - 계좌번호(FK) / 관계사원구분코드 / 사원번호 (FK)

사원 - 사원번호

 

위 관계도는 고객에게 알림 서비스를 신청받는 엔티티입니다. '고객알림서비스' 엔티티는 고객별 알림 서비스를 신청받아 관리하는 엔티티고 '계좌알림서비스' 엔티티는 계좌별 알림 서비스를 신청받아 관리하는 엔티티입니다.

 

고객 알림서비스 - 고객번호(FK) / 알림종류코드 / 알림방법코드 / 신청일자 / 알림반복횟수

계좌 알림서비스 - 계좌번호(FK) / 알림종류코드 / 알림방법코드 / 신청일자 / 알림반복횟수

 

어떤 종류의 알림 서비스를 원하는지와 어떻게 알림 서비스를 받는지 서비스 신청 일자와 알림을 몇 번 반복 하는지 등의 데이터 성격은 두 엔티티 모두 동일합니다. 주 식별자가 달라 엔티티가 통합하지 못하는 예입니다. 이때는 주 식별자를 하나의 속성으로 통합해 사용하는 방법을 사용할 수 있습니다. 왼쪽 모델의 고객계좌통합번호 속성과 같이 고객번호화 계좌번호를 통합한 번호를 의미하는 속성을 두어 고객번호와 계좌번호 중 하나의 값을 사용할 수 있도록 합니다. 고객계좌구분코드는 해당 인스턴스가 고객번호에 해당하는 데이터인지 계좌번호에 해당하는 인스턴스인지 구분하기 위한 속성입니다. 만약 고객번호와 계좌번호가 중복되는 값이 발생할 수 있다면 고객계좌구분코드 속성이 주 식별자에 포함돼야 합니다.

 

1) 알림서비스 - 고객계좌통합번호 / 고객계좌구분코드 / 알림종류코드 / 알림방법코드 / 신청일자 / 알림반복회수

2) 알림서비스 - 알림서비스번호 / 고객계좌통합번호 / 고객계좌구분코드 / 알림종류코드 / 알림방법코드 / 신청일자 / 알림반복회수

 

두번째 모델과 같이 인조 식별자를 사용해 통합할 수도 있습니다. 이때 고객계좌통합번호가 업무 식별자라는 것을 유니크 인덱스로 관리해야 합니다. 인조 식별자는 데이터 모델을 유연하게 만듭니다. 첫번째 모델을 사용하면 계약별로도 알림 서비스를 제공할 수 있다고 업무가 바뀌면 주 식별자에 변화가 발생합니다. 하지만 두번째 모델은 속성의 변화만 발생해 파급 효과는 덜 하게 됩니다. 모델은 유사한 성격의 데이터를 한번 더 일반화해 통합할 수 있는 대상입니다. 고객우편주소 엔티티 주소유형코드 속성은 집주소, 회사주소 등을 의미하며 고객전자주소 엔티티의 전자주소유형코드 속성은 개인 이메일, 회사 이메일, 홈페이지, 메신저 등을 의미하고 고객 전화번호 엔티티 전화유형코드 속성은 집전화, 회사전화, 휴대전화, 팩스 등을 의미합니다.

 

일반화해 통합할 수 있는 대상

고객 우편주소 - 고객번호 / 주소유형코드 / 현재 사용여부 / 우편번호 / 우편주소

고객 전자주소 - 고객번호 / 전자주소유형코드 / 현재 사용여부 / 전자주소

고객 전화번호 - 고객번호 / 전화유형코드 / 현재 사용여부 / 전화번호

 

위와 같이 일반주소와 전자 주소, 전화번호를 개별적으로 관리하는 것은 연락처라는 데이터 통합 차원에서 바람직하지 않습니다. 일반적으로 고객의 전화번호와 주소가 별도로 사용되지는 않을 것입니다. 또한 고객이 연락받기 원하는 연락처가 휴대전화인지 이메일인지 관리하려고 해도 위 같은 모델은 불편합니다. 그래서 고객 연락처 엔티티로 통합할 수 있습니다.

 

연락처를 통합한 엔티티

1) 고객연락처 - 고객번호 / 연락처 유형코드 / 현재 사용여부 / 우선연락처 지정여부 / 우편번호 / 연락처내용

2) 고객연락처 - 고객번호 / 연락처 유형코드 / 현재 사용여부 / 우선연락처 지정여부 / 우편번호 / 우편주소 / 전화번호 / 전자주소

 

연락처 유형코드 속성은 집,회사 주소, 개인, 회사 이메일, 홈페이지, 메신저, 집전화, 회사전화, 휴대전화, 팩스 등을 의미하며 고객의 연락처 데이터는 유형별로 별도 인스턴스에서 관리합니다. 첫 번째 엔티티 연락처내용 속성에는 실제 주소와 전화번호, 전자주소 데이터를 관리하며 값이 항상 존재해야 하므로 Null이 허용되지 않아야 합니다. 만약 연락처 내용 속성에 숫자 데이터 문자 데이터를 함께 사용하는 등의 이유로 사용을 꺼리면 2번 엔티티처럼 속성을 분리할 수 있습니다. 우편주소, 전화번호, 전자주소 속성은 배타 속성이으모 연락처유형 코드 속성에 따라 세 개 중 하나의 값만 발생합니다. 따라서 우편주소, 전화번호, 전자주소 속성에 널이 허용돼야 합니다.

 

 

1) 매출전표 - 전표번호 / 발행일자 / 발행금액

2) 매입전표 - 전표번호 / 발행일자 / 발행금액

3) 전표 - 전표번호 / 전표구분코드 / 발행일자 / 발행금액

 

대칭적인 업무에 의해 발생하는 엔티티는 서로 다른 속성이 일부 존재해도 데이터 성격은 유사하여 통합의 대상입니다. 매도와 매입, 입고와 출고 등도 이에 해당됩니다. 엔티티 주 식별자가 동일할 때도 통합을 고려해 볼 수 있습니다. 업무 식별자가 유사하면 유사한 성격의 데이터 입니다. 데이터 성격도 유사하고 주 식별자도 동일하면 통합을 안 할 이유가 없습니다. 반면에 인조 식별자가 주 식별자면 유사한 데이터가 아닐 수 있습니다. 주 식별자를 단순화시키기 위해 포괄적으로 사용한 인조 식별자는 유사해질 수 있어 주의가 필요합니다.

 

주식종목, 선물옵션종목, CP 종목 엔티티는 거래 대상으로서 '종목' 이라는 유사성이 존재하며 주 식별자가 같아 통합의 대상입니다. 종목별로 관리되는 개별 속성이 공통 속성보다 많이 존재하므로 서브타입별로 개별 속성을 관리하는 것이 적합합니다.

 

공통 속성과 주 식별자가 같은 통합 대상 엔티티

1) 주식종목 - 종목코드 / 종목명 / 표준종목코드 / 거래소구분코드 / 액면가 / 발행가격 / 결산월 / 업종분류코드

2) 선물옵션종목 - 종목코드 / 종목명 / 표준종목코드 / 상장일자 / 행사가격 / 만기일자 / 기초자산코드

3) CP종목 - 종목코드 / 종목명 / 표준종목코드 / 발행일자 / 만기일자 / 할인일자 / 할인율

 

개별 종목(상품) 엔티티 속성이 많이 다르다는 이유로 통합하지 않으면 추후 시장에서 거래되는 새로운 종류의 종목이 생길 때마다 엔티티가 늘어나게 됩니다. 관계가 늘어나고 복잡해지고 통합 조회에도 복잡해집니다. 

 

식별자와 기초 속성이 유사한 통합 대상 엔티티

담보대출 - 대출번호 / 대출금액 / 이자율 / 만기일자 / 담보종목코드 / 담보수량

신용대출 - 대출번호 / 만기일자 / 종목코드 / 대출수량

청약자금대출 - 대출번호 / 대출금액 / 이자율 / 만기일자

 

모델은 대출의 종류를 나타냅니다. 담보, 신용, 청약자금 대출은 기초 속성도 유사하고 주 식별자가 동일해 하나의 엔티티로 통합될 수 있습니다. 엔티티 데이터 성격은 조금 다르지만 엔티티 속성이 유사한 예도 통합의 대상입니다. 특히 기초 속성이 유사하면 통합하는게 바람직합니다.

 

성격이 다소 다르지만 통합 대상인 엔티티

1) HTS 서비스 - 계좌번호 / HTS구분코드 / HTS아이디 / 신청일자 / 해지일자 / 신청사원번호 / 신청부서코드

2) 계좌이체서비스 - 계좌번호 / 이체은행 / 이체계좌은행 / 신청일자 / 해지일자 / 신청사원번호 / 신청부서코드

 

고객이 약정한 서비스가 같이 사용되지 않으면 통합할 이유가 없을 수 있습니다. 하지만 고객이 약정한 서비스 전체를 조회하는 요건이 빈번하면 서비스 성격이 다소 다르더라도 통합하는 것이 효율적입니다. 엔티티 사이에 계츨 관계가 존재해도 통합의 대상입니다. 대부분 엔티티 통합은 수평적 관계에서 통합돼 서브타입이 발생하지만 계층 관계의 엔티티 통합은 수직적 통합으로 순환 관계가 발생합니다.

 

계층 관계에 대한 수직 통합

(1) 

본사 - 본사코드 / 본사명 

부서 - 부서코드 / 본사명 / 본사코드 (FK)

팀 - 팀코드 / 팀명 / 부서코드 (FK)

 

(2) 부서 - 부서코드 / 부서명 / 부서구분코드 / 상위부서코드(FK)

 

유사한 속성이 여러 엔티티에 존재하고 그 속성이 별도 데이터 성격을 지닌다면 해당 속성만을 통합할 수 있습니다.

 

공통 속성만을 별도로 통합한 모델

(1)

주식계좌 - 계좌번호 / 계좌명 / 개설일자 / 증거금구분코드

선물옵션계좌 - 계좌번호 / 계좌명 / 개설일자 / 옵션전용계좌여부

수익증권계좌 - 계좌번호 / 계좌명 / 개설일자 / 만기일자

 

(2) 계좌통보처 - 계좌번호 / 통보우편번호 / 통보상세주소 / 통보이메일주소 / 통보전화번호

 

1번 엔티티는 2번 엔티티 참조 내용 속성과 유사한 속성을 통합해 관리하는 엔티티입니다. 2번 계좌 엔티티의 참조내용 속성과 같은 긴 텍스트 내용을 관리하면 인스턴스가 길어져 한 블록에 많은 인스턴스를 저장하지 못합니다. 이런 텍스트 내용을 관리하는 속성을 별도로 분리하면 인스턴스 길이는 축소돼 핵심 속성으로 구성된 많은 인스턴스를 한 블록에 효율적으로 저장할 수 있습니다. 텍스트 내용은 보통 상세 조회 화면에서 보여주므로 인스턴스별 조회가 이루어질 것입니다. 비록 하나의 엔티티에 존재할 때보다 많은 I/O가 발생하겠지만 단 건이므로 성능에 영향을 미치지 않습니다. 하지만 텍스트 내용을 대량으로 조회하는 요건이 있다면 두번째 모델은 성능에 악영향을 미치게 됩니다.

 

내용 속성만을 통합한 모델

(1)

계좌 - 계좌번호 / 계좌명 / 개설일자 / 텍스트 번호

내용 텍스트 -텍스트번호 / 텍스트내용

 

(2)

계좌 - 계좌번호 / 계좌명 / 개설일자 / 참조내용

 

1번 엔티티에서 내용 텍스트 엔티티의 주 식별자를 계좌 엔티티로 상속받는 점이 모델과 다릅니다.