[핵심 데이터 모델링] - 논리 모델링

soon·2023년 3월 14일

데이터 모델링

논리 모델링이란?

📌 개념 모델링의 내용을 구체적으로 정의한다

비즈니스에서 필요로 하는 데이터를 명확하고 구체적으로 정의하는 과정
핵심 엔티티를 중심으로 업무에 필요한 하위 엔티티로 확장하면서 상세화 한다.
엔티티를 정의하고 관계를 명확히 하되, DBMS의 물리적인 특성까지 고려할 필요 X

방법

기초 논리 데이터 모델 설계
- 주제영역별 핵심 엔티티 도출
- 엔티티간 주요 속성 도출

논리 데이터 모델 설계
- 업무영역에 필요한 데이터 모델을 설계
- 시스템 관점 데이터는 반영 X
- 이력관리에 대해 꼭 관리할 필요가 있는지 반영해야함

엔티티 정의 및 상세화

핵심 엔티티 (Key Entity, 기준정보)

유형 및 분류 (Type & Category)
: 각종 코드 정보, 데이터 집합을 유형화 하거나 계층적으로 분류하는 정보
ex 고객유형코드, 상품분류코드 등 각종 코드정보
업무규칙 및 지식 (Rule & Knowledge)
: 업무처리를 위한 각종 규정과 지식
ex 직급별 연봉, 보험료 조건, 지역별 담당자
업무주체 및 대상 (Subject & Object) 핵심 엔티티
: 비즈니스 이벤트의 주체 또는 대상
ex 부서, 사원, 고객, 상품
장소 (Where)
: 비즈니스 이벤트가 발생하는 장소.
ex 물류창고, 공장, AS센터, 도로, 채널, 지역, 좌표 등등

중요 엔티티 (Main Entity, 업무기본)

업무 주체 고객, 직원 와 업무 대상상품 간의거래나 업무 행위에 의해 발생함
주문, 약정, 입출고 처럼 구별 가능한 업무 행위를 대표하는 엔티티

행위 엔티티 (Action Entity, 업무상세)

업무 행위에 대한 상세내역 및 업무 결과에 대한 상태를 나타내는 엔티티
- 상세 / 내역 - 주문 내역, 예산 내역처럼 항목 단위로 분류하거나, 더 작은 단위로 세분화한 엔티티
- 상태 - 시간의 간격을 두고 업무 단계별로 담당자가 처리하는 흐름
  - 시간의 흐름에 따른 정보의 상태, 내용 변경 면에서 이력 엔티티와 유사할 수 있다. but
    이력 : 시간이 흐름에 따른 정보 변경,
    상태 : 업무처리 흐름에 대한 상태 관리
- 이력 - 변경 전 데이터를 추가로 관리하는 엔티티
  - 이력관리가 필요한지 확인해 볼 필요는 있다.
- 이력관리
  - 전체 항목 이력관리
    : from ~ to 방식, 기간을 작성
  - 점 이력 관리
    : 변경 시점시작시점만 관리한다.
    ex 대출같이 언제 빌려갔는지는 점이력으로 관리한다.
  - 선분이력 관리
    : 시작시점과 종료시점을 같이 관리한다.
    ex 가격은 계속 변하기 때문에 from ~ to 선분이력으로 관리
    변경이 발생했을 때 이전 이력 '변경종료일자' -> ('99991231' -> '20190430')로 Update하고,
    새로운 이력에 변경시작일자 ('20190501') 과 변경종료일자 ('99991231') 구간으로 관리한다.

엔티티 도출 및 식별

데이터를 분석하여 엔티티로 구체화하는 과정
현행 데이터 모델이 있는 경우, 불필요한 업무나 기능과 관련된 테이블을 식별 후 삭제
: 이미 그려진 그림을 지우는 건 생각보다 어렵다.
작업이 어느정도 마무리되면 현업과 인터뷰 전에 엔티티명, 관계선, 속성명을 정리하는 것이 좋다.

엔티티 명명

엔티티명은 테이블 내에서 유일하게 부여하며, 데이터를 가장 명확히 표한할 수 있도록 작성한다.
너무 길지 않아야 하고, 구체적인 용어를 사용하는게 좋음
유사한 엔티티를 별도로 설계한 경우 주제영역이나 수식어를 붙여서 구분한다.
ex 여신과 수신업무에서 '계좌'를 정의한 경우 여신계좌, 수신계좌로 명확히 구분 여신:대출업무, 수신:예금업무

엔티티 명명규칙

엔티티 명은 단수형 명사를 사용한다.
ex 고객, 부서, 상품, 주문, 계약
엔티티 범위와 내용을 정의하기 위해 수식어를 사용한다.
ex 주소 -> 고객주소, 입급내역 -> 계약입금내역
교차 엔티티는 양쪽 엔티티명의 조합을 기본 이름으로 한다.
ex 계약 + 상품 -> 계약상품
낱 단어는 정확한 의미를 파악하기 어려우므로 아주 예외적인 경우를 제외하고는 사용 X
ex 고객별실적 -> 고객단위실적, 예산계획및실적 -> 예산계획실적
한글과 알파벳 대문자를 사용, 숫자, 언더바를 허용 O
띄어쓰기, 특수 문자 허용 X

관계 도출 및 정의

속성 도출 및 정의

모든 속성을 도출하고, 속성명, 성성정의, 설명, 필수여부, 데이터타입 등을 정의해야 함

속성 도출

요구사항이나 현행 ERD 등 엔티티를 도출하고 식별하는 과정과 유사함

식별자 지정

식별자는 유일하게 식별 가능하고, 최소 속성으로 구성, 변하지 않으며, 반드시 존재하는 값이어야 함
식별자는 존재하는 속성에 따라 본질 식별자와 대체보조 식별자로 구분한다.
본질식별자
: 엔티티에 원래 존재하는 속성으로 구성된 식별자
ex 사원 엔티티의 사원번호, 주민등록번호
아닌 경우도 있다.
ex 업무처리나 이벤트 성격의 데이터인 회원ID, 계좌번호
인조식별자는 결재번호처럼 결재를 보고할 때 본질식별자(사원번호 + 보고날짜) 대신 인위적으로 부여한 일련번호 형식의 식별자를 의미

인조식별자를 정의하는 경우

논리 데이터 모델은 업무 변경에 유연하게 대응하고 확장성을 가져야 한다.
서로 다른 본질 식별자를 가진 엔티티를 통합할 때 본질식별자를 그대로 사용하면 구조가 복잡해지고 데이터 값이 없는 경우도 발생함
인조식별자를 사용하면 식별자를 변경할 가능성이 낮아지고, 설계 변경을 최소화할 수 있어 유연하고 확장 가능한 모델을 설계할 수 있음

📌
식별관계 : 다른 table의 PK를 내 PK로 가져오는것
요약 : FK면서 PK
FK : 다른 테이블의 PK
식별관계 중 키가 많아지는 걸 방지하기 위해 없는 키를 생성하는데 이게 인조키다.

도메인 및 데이터타입 지정

📌 도메인 : 속성들이 가질 수 있는 값의 범위
속성 : 테이블을 구성하는 컬럼, 속성은 값을 얻는다.
예) 고객 엔티티의 속성은? 이름, 연락처, 주소, 가입일, 등등...

속성에서 도메인을 지정하거나, 데이터타입을 지정하여 속성이 가질 수 있는 데이터 값의 범위를 정의한다.

옵셔널리티(Not Null) 지정

엔티티에 데이터가 입력될 때 속성 값을 반드시 입력해야할 경우 Mandatory(필수, Not Null)지정
값을 가지지 않아도 되는 경우 Optional(선택, Null)로 지정

데이터 표준화

데이터에 대한 명칭과 의미를 정하고 활용하는 데이터에 대한 형식 및 범위를 규정하는 활동
구성원이 같은 용어를 동일한 의미로 사용하기 위함

단어 표준화

표준단어사전 < 블로그 참조

표준단어기준관리예시

영문약어명명기준예시

코드 표준화

업무에서 통계를 내거나 한정된 데이터 값을 목록화하여 관리하고자 하는 대상을 코드로 식별하여 정의
코드는 공통코드로 통합하거나, 개별 테이블 형태로 관리(목록성 코드라고 함)한다.
코드 표준화 대상은 목록성 코드와 공통코드 모두를 포함한다.
코드사전
코드 사전은 코드에 대한 코드유형ID, 코드유형명, 코드, 코드명 등을 정의
업무에서 동일한 의미로 사용하는 코드는 최대한 통합하여 단일 코드유형으로 정의
ex 거래은행("한국은행", "기업은행"), 이체은행("산업은행", "국민은행")이 있다면
은행("한국은행", "기업은행", "산업은행", "국민은행")으로 통합할 수 있음
여기서, 특정 업무에서 은행코드 중 일부만 사용한다고 하면, 코드유형ID를 별도로 등록 가능
- but 이 경우도 코드는 001(한국은행), 002(산업은행) 등 동일하게 부여하는게 좋다.
분류형
: 코드를 대/중/소 분류체계로 계층을 나누고, 상위 코드에 코드를 추가하는 방식
- 코드 구성에 의미를 두어야 함, 직관적이나 코드 추가, 재분류시 관리하기가 어려움
- ex 농업 : 01, 작물 재배업 : 001, 곡물 밑 식량작물 재배업 : 0111, 축산업 : 012
일련번호형
: 의미없이 순차적으로 일련번호를 부여하는 방식
- 코드 추가 시 반영이 쉽다.
- ex 고객유형, 개인 : 01, 법인 : 02, 기타 : 99
약어형
: 성별코드처럼 약어를 그대로 사용하는 방식
- 코드만 보고 무슨 데이터인지 알 수 있게 직관적으로 작성해야 함
- ex 성별, 남자 : M, 여자 : F
차용성
: 업무에서 사용하는 코드를 그대로 쓰는 방식
- 업무적으로 통용되는 코드나, 인터페이스를 위해 사전에 정한 코드를 사용함
- ex 은행코드, 한국은행 : 001, 산업은행 : 002, 기업은행 : 003
'사용여부', '사용유무'는 두가지 값을 가지며 Y/N, 1/0 처럼 코드로 관리하는게 좋다.