[3] 데이터베이스 개념적 모델링

대출금 상환 프로그램 - 개념적 모델링 

 

데이터베이스 설계는 보통 3단계를 거칩니다.

 

개념적 모델링

 

비지니스 요구사항을 보면서 엔티티 , 엔티티의 속성 , 엔티티의 관계를 정의하는 단계 입니다.

특정 데이터베이스 기술은 고려하지 않고 , ERD 로 핵심 구조를 표현하는 것이 목표 입니다. 

 

논리적 모델링

 

ERD 를 관계형 데이터베이스에 맞게 구체화 합니다.

테이블 , 컬럼 , 기본키 , 외래키를 정의하고 정규화를 진행 합니다. 

 

물리적 모델링 

 

실제 사용할 데이터베이스(MySQL , Oracle 등)의 특성에 맞게 인덱스 , 데이터 타입 , 파티셔닝 등 성능과 저장 방식을 결정 합니다. 

 

이 글은 그 첫번째 단계인 개념적 모델링을 다룹니다. 

대출 실행은 이미 완료된 상태라고 가정하고 , 대출금 상환 과정에서 필요한 엔티티와 관계를 하나씩 도출해 나간 과정을 담았습니다. 

---

뿌리 엔티티 1 - 회원과 주 계좌 

 

요구사항 

 

• 회원은 회원 ID , 로그인 ID , 비밀번호 , 이름 , 가입일시 정보를 가집니다. 
• 계좌는 계좌 ID , 계좌번호 , 잔액 , 생성일시 정보를 가집니다. 
• 회원은 가입 시 반드시 하나의 주 계좌를 가져야 합니다. 

 

관계

 

한 명의 회원은 반드시 하나의 주 계좌를 가지고 , 계좌는 반드시 한 명의 회원에 속합니다.회원과 계좌는 1:1 필수 관계 입니다.

 

ERD 

 

---

뿌리 엔티티 2 - 대출상품 , 이자종류 , 상환방법

 

요구사항 

 

• 대출상품은 상품 ID, 상품명, 가산금리 정보를 가집니다.
• 이자종류는 종류 ID, 이자종류명 정보를 가집니다. 이자종류는 고정금리, 변동금리, 혼합금리 3가지로 구분됩니다.
• 상환방법은 방법 ID, 상환방법명 정보를 가집니다. 상환방법은 원리금균등상환, 원금균등상환, 만기일시상환 3가지로 구분됩니다.
• 대출상품은 반드시 하나의 이자종류와 상환방법을 가져야 합니다. 

 

관계

 

하나의 대출상품은 반드시 하나의 이자종류를 가집니다. 하나의 이자종류는 여러 대출상품에 적용될 수 있습니다.

따라서 이자종류와 대출상품은 1:N 관계이며, 대출상품 입장에서 이자종류는 필수입니다.

하나의 대출상품은 반드시 하나의 상환방법을 가집니다. 하나의 상환방법은 여러 대출상품에 적용될 수 있습니다.

따라서 상환방법과 대출상품은 1:N 관계이며, 대출상품 입장에서 상환방법은 필수입니다.

 

ERD

 

---

M:N 해소 - 대출계약 

 

요구사항 

 

• 한명의 회원은 동시에 여러 대출상품에 가입할 수 있습니다. 
• 하나의 대출상품은 여러 회원에게 가입될 수 있습니다. 

M:N 관계

 

위 요구사항을 ERD 로 표현하면 회원과 대출상품 사이에 M:N 관계가 생깁니다. 

 

 

M:N 관계는 2가지 문제를 가집니다. 

 

첫째, 관계형 데이터베이스에서 물리적으로 구현할 수 없습니다. 

둘째, 관계 속에서만 의미를 갖는 데이터를 저장할 곳이 없습니다. 

 

대출계약 엔티티 도입

 

이 문제를 해소하기 위해 대출계약 엔티티를 도입합니다. 

대출계약은 회원과 대출상품 사이의 M:N 관계를 2개의 1:N 관계로 풀어줍니다. 

 

---

대출계약과 대출계좌

 

 

요구사항 

 

• 대출계약은 대출 주기에서 변하지 않는 정보인 계약 ID , 계약일 , 만기일 , 계약대출 원금 정보를 가집니다. 
• 대출계좌는 대출 주기에서 변하는 정보인 계좌 ID , 계좌번호 , 대출원금잔액 , 상환계좌번호 , 매달 상환일 , 현재 회차를 가집니다. 
• 대출계약이 체결되면 반드시 하나의 대출계좌가 생성되어야 합니다. 

관계

 

대출 계좌는 대출 계약에서 파생된 엔티티 입니다.

하나의 대출계약은 반드시 하나의 대출계좌를 가져야 합니다. 

따라서 대출계약과 대출계좌는 1:1 필수 관계 입니다.

 

ERD

 

 

 

---

대출계좌와 대출상태 

 

요구사항

 

• 대출계좌는 상환이 진행되면서 상태가 변하는데 상태 변화 이력을 추적해야 합니다. 
• 대출상태는 상태 ID, 상태명 정보를 가집니다.
• 대출상태 이력은 이력 ID, 시작일, 종료일 정보를 가집니다.
• 대출계좌는 여러 개의 대출상태 이력을 가질 수 있으며, 하나의 대출상태 이력은 반드시 하나의 대출계좌에 속합니다.
• 하나의 대출상태는 여러 대출상태 이력에 연결될 수 있으며, 하나의 대출상태 이력은 반드시 하나의 대출상태를 가집니다.

 

관계

 

대출계좌와 대출상태 이력은 1:N 필수 관계입니다.

대출상태와 대출상태 이력은 1:N 관계이며, 대출상태 이력 입장에서 대출상태는 필수입니다.

반면 대출상태는 아직 어떤 이력에도 연결되지 않을 수 있으므로 선택적 관계입니다.

 

ERD

 

---

대출계좌에서 파생 - 상환스케줄 

 

요구사항

 

• 대출 계좌에 대해 언제 , 얼마를 상환 할지에 대한 상환 스케줄 데이터가 필요합니다. 
• 상환 스케줄은 스케줄 ID , 예정일 , 상환금(원금,이자) , 적용금리 정보를 가집니다.
• 하나의 대출 계좌에 대해 1개 이상의 상환 스케줄을 가질 수 있으며 , 하나의 상환 스케줄은 반드시 하나의 대출계좌에 속합니다. 

 

관계

 

 

하나의 대출계좌는 여러 개의 상환 스케줄을 가질 수 있으며, 하나의 상환 스케줄은 반드시 하나의 대출계좌에 속합니다.

따라서 대출계좌와 상환 스케줄은 1:N 필수 관계입니다.

 

ERD

 

---

상환스케줄에서 파생 - 상환이력 / 연체

 

 

요구사항

 

• 상환 스케줄에 대해 연체할 경우 이에 대해 매일 이력을 기록할 데이터가 필요합니다. 
• 연체 이력은 연체 ID, 연체 종류, 연체 일시, 연체 이자율, 연체금 정보를 가집니다.
• 상환 스케줄과 연체 이력에 대해 실제로 얼마를 상환했는지 기록할 데이터가 필요 합니다.
• 상환 이력은 이력 ID, 납부 원금, 납부 이자, 납부 연체금, 납부 일시 정보를 가집니다.

 

관계

 

상환 스케줄과 상환 이력은 1:N 선택적 관계입니다. 하나의 상환 스케줄에 대해 여러 번 나눠서 납부할 수 있으며, 정상 납부된 스케줄은 상환 이력이 없을 수도 있습니다.

 

상환 스케줄과 연체 이력은 1:N 선택적 관계입니다. 정상 납부된 스케줄은 연체 이력이 없으며, 미납 시 매일 연체 이력이 쌓입니다.

 

연체 이력과 상환 이력은 1:N 선택적 관계입니다. 연체금을 납부할 때 어떤 연체 이력에 대한 납부인지 연결됩니다. 연체금 납부가 없으면 상환 이력과 연결되지 않을 수 있습니다.

 

ERD 

 

 

---

최종 ERD

지금까지 요구사항을 바탕으로 엔티티를 하나씩 도출하고, 관계를 연결해왔습니다.

뿌리 엔티티에서 시작해 M:N 관계를 해소하고, 대출계약에서 대출계좌, 상환 스케줄, 상환 이력과 연체 이력까지 파생되는 흐름을 따라가다 보면 아래 ERD가 완성됩니다.

 

 

 

 

개념적 모델링 단계에서는 특정 데이터베이스 기술에 종속되지 않고, 비즈니스 요구사항을 중심으로 데이터의 구조와 관계를 정의하는 것이 목표였습니다.

다음 글에서는 이 개념적 모델을 바탕으로 논리적 모델링을 진행해보겠습니다.