DATOR


숨어 있는 주요 엔터티 찾기2 - 필요성 실전모델링


앞 글에서 모델을 검토하여 숨어 있는 '고용' 엔터티를 도출함으로써 좀 더 유연한 모델이 됨을 설명하였다. 정상적인 모델링 절차에 의해 모델링이 진행된다면 이렇게 숨어 있는 엔터티가 도출될 가능성은 크지만, 주요 엔터티일수록 빠르게 도출하는 것이 여러 가지 면에서 효과적이다. 특히 정상적으로 모델링을 진행하고 있더라도 무엇인가 좀 더 나은 모델을 만들 수 있지 않을까 하는 상황이라면 새로운 엔터티의 도출을 시도해 보는 것이 경험적으로 의미가 있었다.


숨어 있는 엔터티의 도출의 필요성을 공감하기 위해 지금은 당연히 존재하는 은행의 계좌 개념이 최초의 수신 업무를 시작할 시점에는 없었다고 가정해 보자. 계좌가 없으므로 최초의 은행에서는 아마도 고객별 거래내역을 수기로 작성하는 수준이 아니었을까? 그렇다면 다음의 업무기술서의 내용에 큰 오류는 없을 것이다.


고객에게 예금을 받아서 잔고로 관리하며 월말이 되면 정해진 금리로 이자를 계산하여 잔고에 포함시킨다.


위 내용을 바탕으로 애써서 계좌엔터티를 무시하고 모델을 설계하면 다음과 유사할 것이다.


Account 공감하기.png


고객엔터티의 현재잔고 속성 뒤에 (d)라고 되어 있는 것은 거래내역의 거래금액을 거래유형에 따라 가감한 값을 의미한다. (d)는 추출속성(derived attribute)를 의미하는 DA#의 기호이다. 이렇게 설계하고 보니 그냥 고객별로 거래내역을 기준으로 현재 잔고를 관리하는 수준으므로 아직까지는 계좌의 필요성은 없어 보인다.


시간이 지나면서 은행 서비스가 확대되어 다음과 같은 업무 요건이 추가되었다.


고객이 정기적금 서비스에 가입하면 금리를 1% 인상해서 이자를 계산한다.


일단, 위 모델에 속성만 추가해서 위 업무요건을 소화해 보자. 인상 금리가 1%인 것은 고객마다 다르지 않으므로 아직까지는 별도의 엔터티나 속성으로 도출하지 않았다. 


Account 공감하기_2.png


거래내역 엔터티에 정기적금여부 속성을 추가하여 해당금액은 금리를 다르게 지급하는 구분으로 활용하고, 고객 엔터티의 현재잔고 속성은 정기적금잔고와 자유입출금잔고로 분리하였다. 현재잔고 속성이 2개가 되었지만 아직은 프로그램 작성이 그렇게 어렵지 않은 수준이다. 그런데, 고객에게 대출서비스도 시작하기로 하였다.


고객의 현재잔고 존재와는 별도로 1000만원까지는 대출서비스를 제공한다.


Account 공감하기_4.png


거래내역 엔터티에 여수신구분 속성과 고객 엔터티에 여신현재잔고 속성이 추가되었다. 한도가 1000만원이라는 정보는 아직까지는 고객별 정보가 아니라 전체 고객에게 동일하게 적용되는 형태이므로 별도의 엔터티나 속성을 도출하지는 않았다. 위 모델을 기반으로한 어플리케이션 프로그램은 거래내역을 거래유형별, 여수신구분별, 정기적금여부별 로직을 분리하여 수행해야 하며, 각각 고객의 현재잔고 속성들을 적절하게 업데이트하여야 한다. 이런 방식으로 추가된 업무요건을 계속해서 반영한다면 유지보수 불가능까지는 아니더라도 데이터 모델과 어플리케이션 프로그램 모두 매우 복잡해 질 것이다.


아마도 이러한 업무적 복잡도를 낮추기 위해 계좌라는 개념을 누군가 제안했고, 그 효과를 관련자가 공감하여 계좌에 적합한 업무규칙을 발전시켜 현재의 계좌 개념이 정착되었을 것이다.


  Account 공감하기_6.png


어플리케이션 프로그래머는 계좌 엔터티에서 여수신구분과 정기적금여부 컬럼을 참고하여 이자를 계산할 수 있다. 거래내역 엔터티는 이제 단순히 거래의 일시와 형태 및 금액만 관리하면 된다.


지금까지 계좌가 없는 상태의 데이터 모델이 업무 요건이 추가됨에 따라 얼마나 복잡해질 수 있는지를 설명함으로써 계좌 엔터티와 같이 중요한 엔터티가 보다 빠른 시점에 설계되어야 함을 설명하였다. 특히 업무가 복잡한 상황일수록 숨어 있는 주요 엔터티를 찾으려고 하는 노력은 다음과 같은 효과를 얻을 수 있다.

첫번째 효과는 적절한 주요 엔터티를 찾는데 따른 효과이다. 추가된 엔터티를 통하여 모델러와 개발자가 쉽게 이해할 수 있고, 업무요건의 변화를 보다 쉽게 수용할 수 있게 하는 것은 어떤 모델링의 작업보다 큰 의미를 갖는다.

두번째 효과는 복잡한 데이터 모델에 대해서 그 복잡함을 공유하고 특별 관리가 될 수 있도록 하는 근거가 만들어 질 수 있게 하는 점이다. 주요 엔터티를 찾지 못한다 해도 찾으려는 노력을 통하여 해당 모델이 왜 그렇게 복잡하게 설계되어야 하는지에 대해 모델러는 자신있게 설명할 수 있으며, 이를 통하여 프로젝트 및 향후 유지보수 단계에서도 해당 모델과 프로그램이 어려운 부분을 주의깊게 관리하도록 강조할 수 있다.


일반적인 모델링 이론과 절차에 따르는 것은 복잡한 업무요건을 쉽게 이해할 수 있는 모델로 설계할 수 있게 하지는 못한다. 대부분 업무 요건을 충실히 도출하고 지키면서도 데이터 모델은 더 이상 복잡해지지 않도록 유지하는 의미 정도이다. 따라서, 다양하고 복잡한 업무요건을 보다 쉬운 데이터 모델로 설계하고 어플리케이션을 작성하도록 하는 것은 어떤 데이터 모델링 작업 단계보다 가치 있는 활동이다. 그 활동의 출발은 지금까지 설계된 데이터 모델에 대한 의심에서 출발하며, 생각보다 복잡한 모델해진 모델이라면 아직 설계하지 못한 엔터티를 가시적으로 표현하려는 노력이 큰 도움이 될 것이다. 


TAG

Leave Comments