실체유형(Entity Type) 정의 사항 및 도출

009. 실체유형(Entity Type) 정의에서는 실체유형 정의, 특성 및 분류를 알아보았고, 이번에는실체유형에 정의할 내용과 도출 방법 및 사례를 살펴보기로 하겠다.

실체유형(Entity Type) 정의 사항

실체유형 정의 사항은 데이터 모델 구축 팀이 수집 및 기록해야 하는 것들이다. 실체유형 정의의 목적은 고품질 데이터 모델의 특성에서 보는 바와 같이, 정보 요구사항에 대하여 빠짐없이 정확하게 업무 규칙을 표현하는 것이다. 그림 실체유형 정의 사항에는 논리 데이터 모델링시 실체유형이 식별되면 실체유형에 기록해야 할 정의 사항들을 보여주고 있다.

실체유형 명

실체유형은 일련의 설정된 명명 규칙을 따르는 고유한 이름을 부여 받아야 한다.

논리 데이터 모델링 단계에 실체유형 명을 결정하는데 많은 시간을 할애하는 것은 속성 명과 마찬가지로 명칭을 통해 업무를 이해하는 것이 매우 중요하기 때문이다.

수백 수천 심지어 수만 개의 실체유형을 포함하고 있는 논리 데이터 모델의 실체유형 명이 업무를 이해하기 어렵게 매우 잘 못 만들어 졌다면, 이것은 논리 데이터 모델의 가치를 현저히 떨어트리고, 프로젝트에 참여하는 많은 팀원들 사이의 의사소통을 방해하는 장애물이 되어 생산성의 저하를 불러올 것이다.

그림 실체유형 명을 보면 지켜야 할 명명규칙과 지키지 말아야 할 명명규칙을 설명하고 있다.

지켜야 할 명명규칙.

1) 실체유형 명은 현실 세계의 실체 및 정보를 대표하도록 한다.
실체유형 명은 논리 데이터 모델과 관계된 모든 이해 관계자들과의 의사소통을 위한 의미있는 것이어야 하며, 업무 개념을 명확하게 반영할 수 있는 이름이어야 한다. 좋은 실체유형 명은 업무 전문가의 도움을 받아 될수 있으면 현업에서 사용하는 용어를 이용하여 만드는 것이 좋다. 이렇게 하여 만는 실체유형 명은 업무를 이해하고, 의사소통하는데 있어서 매우 좋은 이름이 될 것이다.

2) 실체유형 명 자체로 의미를 표현하도록 한다.
“부서”, “사원”, “상품”, “주문”, “계약” 등과 같이 논리 데이터 모델을 활용하는 사람들이 그 실체유형이 표현하고자 하는 것이 무엇인지를 직관적으로 이해할 수 있는 명칭을 사용하는 것이 좋다. 앞에서도 얘기한 파티(Party)라는 실체유형 명은 사람(Person)과 조직(Organization)을 포함하는 개념이며, 이러한 용어는 외산 패키지(Package) 제조 업체가 향후의 업무 변화에 대한 유연성을 확보하기 위하여 상당히 추상화 수준을 높인 모델링 기법에 의해서 생성된 용어로 현실세계 업무에서는 잘 사용 안하는 용어이며, 이 용어로 논리 데이터 모델과 관계된 이해 관계자와 의사소통을 하기에는 많은 어려움이 있을 것이다.

3) 물리적인 사항을 개념화한 논리적 사물을 반영하도록 한다.
구매주문서라는 것은 현실세계의 구매주문에서 발생하는 하나의 물리적인 실체로 구매주문서에는 구매주문의 주체인 고객, 구매주문의 대상인 상품 등이 포함되어 있을 수 있다. 가능하면 물리적인 표현을 피하고, 순수한 구매주문 사항만을 표현할 수 있는 논리적인 표현을 사용하여 실체유형 고유의 특성을 나타낼 수 있도록 한다.

4) 최소한의 어휘를 사용하여 의미를 전달할 수 있도록 한다.
수식어가 너무 많으면 실체유형을 잘못 표현할 수 있다. “국내 업무용 주식종목”이란 이름을 보면, 분명 “해외 업무용 주식종목”이라는 것이 떠오를 것이다. 하나의 주식이 국내, 해외 주식시장에서 모두 사고 팔 수 있는데, 이렇게 두 개의 실체유형으로 나누어 데이터를 관리 한다면, 양 쪽에 데이터가 발생하여 데이터 중복을 초래할 수도 있을 것이다.

지키지 말아야 할 명명규칙.

1) 데이터 관리자의 승인을 받지 않은 약어 또는 두문자어(Acronym).
이러한 약어 또는 두문자어의 사용은 모델을 보는 사람으로 하여금 정확한 업무 이해를 저해할 수 있으며, 심지어 업무를 잘 못 해석할 수도 있다.

예를 들어 “규손금”이라는 실체유형 명을 보면, 이 이름으로는 무슨 얘기인지 전혀 감이 안 잡힐 것이다. 이 용어는 리스 업무에서 사용하는 용어로 “규정 손해금”을 말한다. 규정 손해금이란 리스회사와 계약한 사람이나 조직이 리스 계약의 체결이후 리스기간 종료 전에 이 계약의 해제 또는 해지를 하는 경우, 현재 또는 장래에 발행할 리스회사의 손해액 일체를 배상해야 한다는 규정이 있다. 이러한 손해액을 규정손해액이라 하는데 이를 약어로 보통 규손금으로 사용한다. 리스 업무를 처음 분석, 설계, 개발 하려는 여러 이해 관계자들한테는 매우 생소한 약어가 될 것이다.

실체유형 명명 규칙뿐만 아니라 앞으로 얘기할 속성 명명 규칙에서도 마찬가지인데 손해 보험업무 같은 데서는 매우 많은 약어를 사용한다. 예를 들어 “납방”이라는 단어는 “납입방법”의 약어이고, “납주”라는 단어는 “납입주기”의 약어로 이러한 약어들은 업무 경험이 많은 사람들에게는 익숙하겠지만, 프로젝트에는 업무에 익숙하지 않은 새로운 사람들이 참여하는 경우도 허다하다. 새로운 사람들이 이러한 용어에 대한 개념을 물어볼 때마다 그 프로젝트의 시간을 낭비하는 것이라 할 수 있겠으니 약어의 사용은 매우 신중을 기해야 하는 사항이다.

2) 테이블, 파일, 메뉴, 보고서, 입력화면 같은 정보시스템 구성요소.
이 사항은 앞에서도 얘기한 논리 데이터 모델에 표현되는 사항은 현실 세계 물리적인 것들을추상화하여 개념화한 논리적인 어떤 것이어야 한다는 것과 일맥상통하는 얘기다.

3) 두 가지 이상의 개념을 동시에 사용하는 표현.
“개인 또는 법인 고객”과 같은 명칭은 수퍼/서브타입 실체유형을 섞어 놓은 것처럼 보인다. 만약에 개인이나 법인 이외에 임의단체 같은 고객이 생긴다면, 실체유형 명칭에 문제가 있다는 것을 인식하게 될 것이다.

실체유형 설명

실체유형 설명은 논리 데이터 모델링 과정에서 속성 설명과 마찬가지로 매우 중요한 사항이다.



실체유형 설명은 해당 업무에서 일반적으로 사용하고 있는 용어를 이용하여 기술한다. 실체유형에 속하는 실체들이 무엇인지(범위), 어떻게 다른 실체와 구별되는지를 정확하게 설명해야 한다. 관계명과 다른 실체유형의 이름이 정의에 나타날 수도 있으나, 단순히 실체관계도(ERD: Entity Relationship Diagram)를 말로 재지정하는 일은 피해야 한다. 예를 들어 “고객”이라는 실체유형의 정의는 “어떤 부서(실체유형)가 판매(관계)하고 있는 제품(실체유형)을 구매(관계)하는 개인 또는 조직(범위).”이라고 할 수 있다. 설명은 결코 실체에 대해 기록된 상세한 데이터를 설명해서는 안 된다.

실체유형 분류

실체유형 분류는 방법론 종속적인 사항으로 위에서도 설명한 바와 같이 반드시 해야만 하는사항은 아니며, 업무를 좀 더 잘 이해하기 위한 개념이라는 것만 기억했으면 한다.

현재 발생 건수

논리 데이터 모델링의 후속 단계인 데이터베이스 설계 단계의 설계자 및 운영자를 돕기 위하여 그리고 데이터 이행과 관계된 사람들에게 저장 공간 사용 계획을 위한 정보를 제공하기 위하여 현재 발생 건수를 파악하는 것이 유용한 정보가 될 것이다.

발생 건수 변화

설계 및 구현 단계를 위하여 현재 발생 건수의 변화되는 증가 또는 감소 건수를 기록관리한다.

권한

실체유형 권한은 두 가지 관점에서 정의한다. 첫째 실체유형, 속성, 관계 및 기타 모델 구성요소를 생성 또는 변경하는 것에 대한 권한을 갖는 것이며, 둘째는 실체유형의 사례(Instance or Occurrence)를 입력, 수정, 삭제, 조회할 수 있는 권한을 말한다.

기본키(Primary Key) 속성

실체유형의 실체를 인식할 수 있는 일련의 속성을 정의한다.

외부키(Foreign Key) 속성

실체유형 내 속성들로서 그들의 값이 다른 실체유형에 대한 관계를 지원하는 어떤 다른 실체유형의 기본키값과 합치될 것이 요구되는 속성들이 외부키로서 지정된다.

키 이외 속성

이 속성들은 정규화 규칙에 따라 실체유형 안에 놓이게 되었고, 이들 속성들은 실체유형의 양적 또는 질적 특징이나 성질을 기술하지만, 이 또는 다른 실체유형의 기본키로서 역할을 하지 않는 속성들이다.

실체유형(Entity Type) 도출

실체유형 도출은 다양한 방법을 이용하여 수행될 수 있다. 그림 실체유형 도출에는 여섯 가지 정도의 대표적인 실체유형 도출 방법을 보여주고 있다. 물론 다른 방법을 이용하여 실체유형을 도출하여도 상관은 없다. 실체유형 도출의 가장 큰 목적은 업무를 빠짐없이 정확하게 표현하기 위한 것이기 때문에 어떠한 방법을 사용하여도 이 목적을 이루기만 하면 될 것이다. 물론 업무분석 초창기부터 모든 실체유형을 빠짐없이 정확하게 파악하기란 힘들 것이다. 논리 데이터 모델링이 진행되면서 점차적으로 업무가 빠짐없이 정확하게 파악될 것이다.



현행 데이터베이스 시스템이 존재하는데 이알디(ERD: Entity Relationship Diagram)를 보유하고 있지 않은 경우는 현행 데이터베이스 시스템으로부터 역공학(Reverse Engineering) 기법으로 테이블(Table)을 추출하여 실체유형을 생성할 수 있고, 이전에 보았던 구매주문서와 같이 업무에서 사용하는 문서로부터 실체유형을 도출할 수 있고, 논리 데이터 모델링 전 과정에 걸쳐 사용자 인터뷰를 수행하면서 실체유형을 도출할 수 있고, 주제영역을 정의할 때 그 조직의 기능(Function)을 살펴보면서 주제영역을 정의했듯이 업무를 수행하는 프로세스로부터 실체유형을 도출할 수 있고, 정보전략계획(ISP: Information Strategic Planning)이나 전사아키텍쳐계획(EAP: Enterprise Architecture Planning)으로부터 생성된 자료를 통하여 실체유형을 도출할 수 있으며, 마지막으로 위에서 살펴본 실체유형 분류 기법을 활용하여 실체유형을 도출할 수 있다

실체유형 도출이 어려운 이유는

논리 데이터 모델링에 대한 경험이 부족한 사람들은 논리 데이터 모델링 과정중에 실체유형도출을 가장 어려워하는 경향이 있다. 이러한 원인에는 여러 가지가 있겠으나 가장 중요한 원인은

첫번째, 논리 데이터 모델링의 대상이 되는 업무에 대한 경험 내지는 이해도 부족이라 할 수 있겠다. 필자가 논리 데이터 모델링 또는 정보 시스템 구축 과정에서 가장 중요하게 생각하는 것은 업무에 대한 경험 내지는 이해도이다. 대학에서 경제학을 전공하고 처음으로 정보 시스템 회사에 입사할 때도 컴퓨터 경험이 없는 전산 비 전공자를 뽑는 이유가 업무를 아는 사람한테 컴퓨터 언어를 가르치면 1년이면 정보 시스템을 구현할 수 있지만, 컴퓨터 전공자에게 정보 시스템 구현을 맏기면 업무를 익히는데 드는 시간이 1년 이라는 시간보다 더 오래 걸린다는 논리로 비 전공자를 선발하여 컴퓨터 언어를 가르치곤 하였다. 물론 이러한 논리가 절대적이라는 것은 아니다. 이렇듯 경영 정보 시스템의 프로그램을 작성하지 못하는 이유는 컴퓨터 언어보다도 업무를 이해하지 못하거나 업무가 어려워서 작성하기 어렵다는 것이지 컴퓨터 언어를 몰라서 프로그램을 작성하지 못하는 경우는 거의 없다는 것이다. 이런 이유로 필자는 업무를 빠짐없이 정확하게 분석해 내는 일에 많은 시간과 노력을 들여왔다.

두번째, 집합이론과 1차 술어 논리에 따른 관계형 모델 이론의 정확한 이해에 대한 부족이라 할 수 있겠다. 집합이란 특정 조건에 맞는 동일한 특성을 갖는 원소들의 모임이다라고 하였다. 이러한 개념을 바탕으로 업무에서 발생하는 인스턴스(Instance: 발생 사례)들을 동일한 성격을 갖는 단위로 구분하여 부르면 이것이 실체유형이 되는 것인데, 이러한 단위가 인스턴스 단위인지, 집합 단위인지, 관계 단위인지, 속성 단위인지가 명확하지 못하기 때문이라 할 수 있다. 다시 한번 강조하자면 실체유형이란 현실세계 업무에서 발생하는 공통된 특성을 갖는 실 사례들의 집합을 칭하는 용어라는 것을 상기했으면 한다.

세번째, 논리 데이터 모델링을 배울 수 있는 곳은 많아도, 익힐 수 있는 기회는 별로 많지가않다는 것이다. 정보 시스템을 구현함에 있어서 많은 사람들이 강조하는 것은 개발 생산성이다. 그러다 보니 프로젝트가 프로그램 구현에 많은 부분 인적, 물적 자원을 쏟아 부으면서 논리 데이터 모델링은 소수의 전문가에게 맡기는 것이 대부분이며, 전문가에게 맡기지 않는다면 개발 경험이 매우 많은 고참이 논리 데이터 모델링을 수행하는 경우가 다반사이다. 이렇다 보니 논리 데이터 모델링을 수행해 보고 싶어도 기회가 잘 주어지지 않는 것이 현실이다. 공자님께서학이시습지(學而時習之)면 불역열호(不亦說乎)라 하였다. 배우고 때때로 익히면 그 또한 기쁘지 아니한가 여기서 중요한 것이 배우는 것도 중요하지만 그만큼 익히는 것도 중요한데 논리 데이터 모델링을 배우는 것에 비해 익힐수 있는 기회가 적으니 그 만큼 실체유형 도출에도 어려움을 느낄 수 있다는 것이 필자의 논리인 것이다.

비록 프로젝트 초기에 실체유형 도출에 어려움을 겪을 수 있겠지만 지금부터 살펴보는 자세한 내용을 기초로 실체유형을 도출하는데 많은 도움이 되었으면 한다.

현행 데이터베이스로부터 도출

필자가 기업 정보 시스템 구현 현장에서 처음 사회 생활을 시작할 때는 정보 시스템을 구축하지 않은 조직들도 상당히 많았을 때이고, 정보 시스템이 구현되어 있다해도 계층형 데이터베이스나 파일 시스템을 사용하고 있었던 때이다. 하지만 현재는 대부분의 조직에서 관계형 데이터 베이스를 근간으로 하는 정보 시스템을 보유하고 있다. 이러한 상황에서 현행 데이터베이스는 목표 실체유형을 도출하는데 있어서 매우 의미있는 정보라 할 수 있다.



현행 데이터베이스를 정밀하게 분석해야 하는 이유는 현행 데이터베이스가 조직의 정보 요구 사항을 빠짐없이 정확하게 지원하고 있는지를 알기 위해, 현행 데이터베이스의 구조적인 문제점 및 해결 방안을 도출하기 위해, 목표 정보 요구 사항을 지원하기 위하여 논리 데이터 모델을 어떻게 생성할 지를 결정하기 위해, 마지막으로 현행 데이터베 필요한 경우 이에 대한 원천 데이터를 정확하게 파악하기 위해 서이다.

대부분의 차세대 정보 시스템 구축 프로젝트에서 현행 데이터베이스의 분석은 매우 미미하게 행해지고 있는 것이 현실이다. 이러한 이유는 현행 데이터베이스의 분석에서 수행해야 할 과업의 규모를 적절하게 인식하지 못하는 경우가 있을 수 있고, 전체 프로젝트의 기간을 적절하게 산정하지 않고 매우 짧은 기간을 수행하려고 하다보니 상대적으로 현행 데이터베이스 분석 기간을 짧게 하는 경우도 있으며, 기존의 프로젝트에서 개발 기간이 부족하다 보니 개발 기간을 길게하고, 현행 데이터 분석 기간은 짧게 하는 경우 등 다양한 경우가 있겠으나 무엇보다도 현행 데이터베이스 기간을 짧게 가지고 가는 이유는 앞에서 얘기한 과업의 규모에 대한 적절한 판단을 못하고 있기 때문이라 할 것이다.

논리 데이터 모델링의 핵심은 속성이 갖는 모든 업무 규칙을 빠짐없이 정확하게 파악하는 것이라 강조하였다. 하지만 대부분의 프로젝트에서 현행 데이터베이스 파악은 디스크를 사용하고 있는 용량산정이나 상위의 업무 차원에서 현행 데이터베이스의 및 목표 개념 데이터 모델을 생성하기 위한 개선사항의 반영 방향 정도에서 현행 데이터베이스를 파악하는 수준이라 할 수 있다.

업무에서 사용하는 문서로부터 도출

논리 데이터 모델링을 수행 하는데 있어서 가장 좋은 자료중에 하나가 현업에서 사용하고 있는 실 데이터 값이 보이는 문서이다. 여기에는 현업의 업무에서 발생하는 데이터와 관계된 업무 사실을 가감없이 볼 수 있다는 장점이 있기 때문이다. 논리 데이터 모델링을 수행한 후 논리 데이터 모델이 잘 되었는지 안 되었는지를 검토할 때는 항상 현업에서 발생하는 문서를 이용하는 방법을 취하는 것을 기본으로 할 것을 추천하는 바이다.

예전에 어떤 프로젝트에서 현업 업무 전문가와 함께 논리 데이터 모델링을 진행한 적이 있었다. 논리 데이터 모델을 만들고는 항상 사례 데이터를 가지고 점검을 해야 하는데 정보 보안이나 시간상의 제약 때문에 업무 전문가의 말만 듣고서 논리 데이터 모델을 만들었다. 아뿔사 문서로부터 실제 데이터 값을 확인하니 많은 부분 속성의 도메인이 잘못된 것을 알 수 있었다.

이전에 본 구매주문서와 같은 자료는 논리 데이터 모델링을 수행하는데 있어서 더 없이 좋은 자료인 것이다.

사용자 인터뷰로부터 도출

사용자 인터뷰는 프로젝트의 전 기간에 걸쳐서 수행하는 논리 데이터 모델링의 전부라고 해도 과언이 아닌 방법이다. 데이터 모델러는 처음부터 끝까지 업무를 현업 사용자와의 인터뷰를 통해서 명확하게 이해해야만 좋은 모델을 만들 수 있는 것이다. 물론 데이터 모델러가 그 업무에 능통하여 먼저 좋은 방법을 제시할 수도 있지만, 각 조직만의 특별한 업무 규칙들이 있기 때문에 이것마저도 데이터 모델에 잘 표현하려면 업무 전문가의 도움은 좋은 데이터 모델을 생성하는데 있어서 매우 중요한 사항이다.

하지만 현실에 있어서 많은 조직에서 현업 업무 전문가가 논리 데이터 모델링의 목적, 수행 방법, 수행 역할 등을 이해하고, 논리 데이터 모델링 과정에 참여하여 업무 규칙을 설명하는 곳은 생각보다 많지 않은 것이 현실이라 하겠다. 이렇게 된 데에는 여러가지 원인이 있겠지만 언제인가부터 데이터와 관계된 일들이 프로젝트의 인프라 영역에 속해 논리 데이터 모델링도 그져 데이터베이스를 구축하는 매우 단순한 일로 여겨지게 된 것이 가장 큰 원인이라 할 수 있겠다.

통상 프로젝트에 많은 인원이 참여하게 되는데 업무 아키텍쳐(BA: Business Architecture) 영역이나 응용 아키텍쳐(AA: Application Architecture) 영역에는 매우 많은 인원이 참여하나, 데이터 아키텍쳐(DA: Data Architecture) 영역에는 두 개의 영역에 비해서는 상대적으로 매우 적은 인원이 투입되는 것이 현실이라 하겠다. 이러다 보니 한 사람의 데이터 모델러가 담당하는 업무 영역이 매우 많아 좋은 데이터 모델을 만드는 것 자체가 힘들고, 또한 훌륭한 데이터 모델러를 보유하기도 어려운 상황에서 프로젝트를 진행하다보니 좋은 데이터 모델을 생성하는 것이 매우 어려운 상황이다.

업무를 수행하는 프로세스로부터 도출

업무 프로세스는 ‘잘 정의된 목적을 달성하기 위하여 업무 입력요소를 받아 업무 산출요소로 변환시키는 일련의 작업 활동들의 집합’으로 정의될 수 있다. 예를 들어 주문접수를 받는데 주문접수를 전화, FAX, 직접 방문 등 여러가지 방법(How)으로 주문접수를 받더라도 주문접수라는 프로세스는 현실세계의 일련의 주문접수라는 작업 활동들을 추상화한 그 조직이 무슨(What) 일을 한다는 것을 나타내는 것이다. 보통의 서적에서는 프로세스를 How(어떻게)로 정의하고 있는데 프로세스는 How가 아니라 그 조직에서 무슨 일을 한다는 What(무엇)이라는 것이다.

통상적으로 정보 시스템을 구축하는 사람들의 프로세스는 데이터를 입력, 수정, 삭제, 조회를 수행하는 업무 단위를 프로세스라고 한다. 이러한 이유로 프로세스를 유심히 살펴보면 정보가 관리되는 어떤 구별 가능한 개체, 사건, 개념이 떠오를 것이다. 물론 프로세스를 중심으로 데이터 모델링을 수행하다 보면, 중복 데이터가 발생할 수 있지만 향후 논리 데이터 모델 통합 과정이나 정규화를 제대로 수행한다면, 프로세스로부터 실체유형을 도출하여 논리 데이터 모델링을 진행하는 것도 그리 잘못된 방법은 아니라 할 것이다.

아키텍쳐 모델로부터 도출

차세대 정보 시스템 구축 프로젝트전에 정보 전략 계획(ISP: Information Stragegic Planning)이나 전사 아키텍쳐 계획(EAP: Enterprise Architecture Planning) 프로젝트를 수행하여 전사 개념 데이터 모델을 생성하였다면, 이러한 개념 데이터 모델을 이용하여 실체유형을 도출할 수 있을 것이다. 물론 필자는 실체유형과 관계만을 표현하고, 추상화 수준이 매우 높은 개념 데이터 모델은 선호하지 않는다고 하였다. 하지만 논리 데이터 모델링을 수행하기 전에 따로 이러한 개념 모델이 잘 만들어져 있다면 업무 전체를 이해하면서 실체유형을 도출하는데 많은 도움이 될 것이다.

실체유형 분류 기법을 활용하여 도출

위에서도 잠깐 설명하였지만 실체유형의 분류 기법을 이용하여 실체유형을 도출하는 방법 또한 매우 유용한 실체유형 도출 방법이라 할 수 있겠다. 업무의 중심이 되는 실체유형이면서 독립 실체유형으로부터 하나의 주제영역에 근간이 되는 실체유형을 도출한 이후 그 업무와 관계된 독립 실체유형 및 데이터의 종속성에 맞춰서 종속 실체유형들을 하나씩 찾아 나간다면 이 또한 훌륭한 데이터 모델을 생성하는 하나의 방법일 수 있는 것이다.

실체유형(Entity Type) 도출 사례

실제로 사용하는 대출 신청서를 가지고 대출 신청에 대한 실체유형을 도출하고, 실체유형이 무엇인지를 정의하는 단계까지만 살펴보기로 하겠다.





여신 주제영역 중 대출신청에 대한 문서를 바탕으로 대출신청 주제영역에 대한 실체유형 정의에 대한 사례를 살펴보기로 하겠다.

대출의 신청 및 접수는 고객과의 대출상담, 대출 신청서 작성 및 대출 취급과 관련한 필요서류 징구 등의 절차를 거치게 된다. 대출 신청 접수 시에는 자금용도와 상환계획을 명확하게 상담한 후 적정한 대출 상품, 거래 및 상환방식, 금액, 금리 등을 구체적으로 협의하여야 하며, 대출 신청 서류를 징구하고 채무 관계인에 대한 조사를 실시하여야 한다.

이러한 대출 신청 업무에서 우리가 찾아야할 실체유형들을 도출해 보기로 하겠다. 실체유형이란 조직에서 업무를 수행하는데 필요로 하는 사물(Thing: 사원, 고객, 상품 등), 사건(Event: 계약, 주문, 납품 등), 개념(Concept: 부서, 계정과목 등)을 나타내는 어떤 것으로, 동일한 업무 행위나 유사한 속성을 갖는 단일 개념으로 정의한 실체들의 집합체를 말한다고 하였다.

대출신청 업무의 중심이 되는 실체유형은 “대출신청”이다. 이러한 대출신청의 주체는 고객이라는 개체집합일 것이다. 이러한 고객에게 대출을 해주기 위해서는 고객의 상환능력을 알아보아야 할 것이다. 그래서 고객의 인적사항, 직업정보 사항, 재무사항 및 담보사항이 필요할 것이다. 대출 신청서로부터 도출할 수 있는 실체유형은 “대출신청”, “고객”, “고객직업”, “고객재무현황”, “담보” 및 “자동이체계좌” 정도라 할 수 있다.

실체유형 정의고객

대출의 채무자와 보증인의 신청, 심사를 위한 추가 정보를 관리한다. 고객정보가 갱신 되는 때는 대부분 신청이 이루어 질 때이다. 고객단위의 정보의 개념이 아닌 신청과 보증 발생 단위의 집합이다. 예를 들면 동일인에 대해 신청서가 두개가 작성되면 서로의 내용이 달라질 수 있다. 그러므로 각 속성정보가 최신의 정보로 관리되지 않을 수 있다.

개인의 주민등록지 주소, 현주소, 직장주소, 자택전화, 휴대폰, 사무실 전화, 사무실 팩스와 기업은 담당자명, 담당자전화, 사업장주소, 기타주소, 직장전화, 직장팩스, 기타전화 등은 통합고객에서 관리한다. 통합고객에서 주민번호가 정정되거나 사업자번호가 정정,변경되면 정정작업은 가능하다.

해당 사업자가 다는 사업자번호로 변경했다는 것을 인식하지 못하고 다른 고객번호를 생성했다면 다른 고객으로 인식한다. (추가적인 UPDATE작업 없음)

※ 융자의 고객 생성룰

융자에서는 고객번호를 생성하는 것은 채무자, 보증인, 협력업체인데 협력업체는 공통코드와 고객번호를 생성한다. 협력업체에 대해 코드로 생성할 때는 비용을 지불하거나 주소를 관리하지 않고 단순 참조용일 때 이며 고객번호를 생성할 때는 반대의 경우이다. 동일 협력업체이지만 고객번호로 생성한 것과 코드로 생성한 것은 동일하다고 인식할 방법이 없다.

고객재무정보

대출고객의 재무사항을 나태낸다. 채무자와 보증인의 결산월별 요약된 재무사항을 입력한다.

개인고객의 직장근무이력을 관리 회사가 관리하는 사업자/법인번호검증 엔티티에 존재하는 회사의 경우에는 사업자법인번호로 관계를 맺고 그렇지 않은 경우에는 직장명을 입력한다. 고객에 대한 직장의 사업자/법인번호를 관리함으로서 동일한 직장에 근무하는 고객그룹을 추출할 수 있거나 동일직장에 근무한 경력이 있는 개인고객들간의 관계를 추정하는 근거로 활용할 수 있다.

대출신청

고객의 대출 신청건에 대해 대출신청서를 기준으로 대출조건 및 자금신청 정보를 관리하고, 이후 신청진행상태에 대한 정보를 관리한다.

대출상품 선택 옵션 정보(대출종류, 상환방법), 채무자 인적 정보, 직업 및 재력 정보 등 대출심사의 기초가 되는 정보를 포함하여 관리하며 신청단계에서는 각 항목은 이력관리 없이 수정되며 대출지급이 이루어 지면 신청정보는 변경 없이 관리한다. 즉, snapshot 관리한다.

일반대출중 최초대출, 연장, 추가대출, 대환대출(자사, 타사)의 경우에도 모두 신청데이터가 발생한다. 또한 신청시 지급관련 사항은 지급품의, 지급품의 지급처에서 관리한다.

대출결재

결재주체가 System 혹은 심사역인지를 구분하여 승인자구분코드(시스템심사, 인적심사)로 나누어진다. 그리고 승인업무는 두 심사주체가 혼용하여 처리된다. 예 : 자동심사판정(판정결과 '가') --> 출납, 자동심사판정(판정결과 '부') --> 심사역심사(특별심사) --> 출납/부결

담보

담보는 크게 인적담보와 물적담보가 있으며 채무자의 채무불이행에 대비하여 채권자에게 채권의 확보를 위하여 제공되는 수단 또는 장차 타인이 입게 될 수 있는 불이익에 대한 보전으로서 부동산담보, 보증보험증권, 지급보증, 유가증권, 기타, 보증인이 있다.

담보구분코드에 따른 담보의 단위는 부동산은 담보주소단위이다. 즉, 하나의 담보는 하나이상의 대출과 연결될 수 있다. 보증보험증권, 지급보증 단위로 하나의 담보대출번호 생성한다.

유가증권은 종목코드(KR코드임)변경에 따라서 대출담보번호가 달라진다. 유가증권은 대출신청을 위한 최초사항이다. 실 변경내용은 해당 증권사를 통해서 관리한다. 보증인은 계약에 따라 보증이 발생되는 개념으로 대출번호가 달라지면 동일인이라도 대출담보번호를 새롭게 생성한다. 기타담보는 하나의 질권등에 의한 사건을 하나의 담보번호로 생성한다.

대출에 따라 대출담보구분코드, 대출담보물종류코드가 지정되지는 않는다. 즉, 신용대출이라고 하더라도 담보물이 부동산이고 아파트라면 담보구분이 부동산담보이며 담보물이 아파트이다. 또한 기타담보의 경우에는 채무자의 부동산담보물의 근저당설정을 질권설정 할 수 있다. 이럴 때는 담보물구분을 기타라고 하며 해당질권을 담보물이라고 하고 부동산의 정보는 참조정보로 부동산담보에 해당하는 속성에 입력할 수 있다. 신청과 대출시에 담보의 정보를 공유하여 관리한다. 신청과 대출의 담보를 공유하여 사용하는 이유는 동일 담보에 대해 신청이나 타 대출에 의해 변경이 일어났을 때 동일 담보를 보유하고 있는 대출건에서도 담보내용의 변경을 인식하고자 함이다. 변경이 발생하면 변경이력과 배서로 반영한다. 하나의 담보가 하나의 대출에 연결이 되어 있다는 것은 대출신청담보에서 관리한다.

자동이체계좌

대출신청 건의 이체방법을 코드화하여 관리하는 실체유형이다. 이체방법은 자동이체, 지로이체, 보통예금등이 있으며 기업의 경우 보통예금의 이체방법을 주로 사용한다. 이 경우 실명확인이나 이체계좌번호등은 불필요하며 종목별 회계처리를 위해 수납계좌별로 수납한다.

출처 : 마이크로소프트웨어 4월호

제공 : 데이터전문가 지식포털 DBguide.net