논리 모델링
논리 모델링은 비즈니스에서 필요로 하는 데이터를 명확하고 구체적으로 정의하는 과정으로, 비즈니스 전체 영역에 대한 상세한 수준의 데이터 구조를 설계한다
출처 : 핵심 데이터 모델링 (저자 : 유동오)
이 단계에서는 DBMS의 물리적 특성까지 고려할 필요는 없다
개념 모델링과 구조적 일관성을 유지하면서 진행한다
엔티티 정의 및 상세화
핵심 엔티티(Key Entity)
핵심 엔티티 : 전체 시스템이나 도메인(업무 영역)에서 핵심이 되는 주요 엔티티를 의미
특징
- 모든 업무 행위는 핵심 엔티티에 의해 정의되거나 핵심 엔티티 간의 관계에 의해 정의된다.
업무 행위의 주체가 되거나 혹은 행위의 대상이 되는 경우가 대부분이다 - 타 엔티티 유형의 존재 유무와 관계없이 독립적으로 존재하며 식별할 수 있다
데이터 성격에 따른 핵심 엔티티 분류
- 유형 및 분류 : 고객유형코드, 상품분류코드 등
- 업무규칙 및 지식 : 직급별 연봉, 보험료 조건, 지역별 담당자 등
- 업무주체 및 대상 : 부서, 사원, 고객, 상품 등
- 장소 : 물류창고, 공장, AS센터, 도로, 채널, 지역, 좌표 등
중요 엔티티(Main Entity)
중요 엔티티 : 업무 행위를 대표하는 엔티티.
즉, 특정 화면, 업무 흐름, 서비스, 기능 단위에서 가장 중심이 되는 엔티티
특징
- 핵심 엔티티 간의 관계 엔티티
- 업무영역 내에서는 비교적 독립적인 성격을 가짐
- 상위 엔티티의 주 식별자를 상속받지 않고 독립적인 주 식별자를 가지고 있음
행위 엔티티(Action Entity)
행위 엔티티 : 어떤 이벤트, 동작, 상태 변화(=행위)를 나타내는 엔티티.
즉, 사용자의 요청, 시스템의 처리, 업무상의 사건 등을 기록하거나 추적하기 위한 동사적 성격의 엔티티
행위 엔티티 유형
- 상세/내역 : 주문내역, 예산 내역 등
- 상태 : 주문상태 등
- 이력
- 변경 항목에 따른 분류
- 전체 속성에 대한 이력 : 고객 정보 변경 이력
- 일부 속성에 대한 이력 : 고객 연락처 변경 이력
- 변경 시점에 따른 분류
- 점 이력 : 변경 일자 하나만 기록
- 선분 이력 : 변경 시작 일자, 변경 종료 일자 두 가지를 통해 구간으로 기록
- 변경 항목에 따른 분류
- 기타 : 거래로그 데이터, 시스템 로그, 연계 데이터, 집계 데이터 등
이후 과정
- 엔티티 도출 및 식별 : 관심 대상이 되는 데이터를 분석하여 엔티티로 구체화
- 엔티티 명명 : 전체 주제영역 내에서 유일하게 부여, 관리하는 데이터를 가장 명확히 표현할 수 있게 명명
- 엔티티 정의 : 엔티티에 대한 설명. 관리하는 데이터 집합을 규정. 데이터에 대한 발생 규칙 및 업무 규칙 등을 기술.
- 엔티티 통합 : 일반화 및 특수화
관계 도출 및 정의
관계 도출
관계의 종류
- 주체 : 핵심 엔티티와 중요 엔티티 간의 관계에서 업무 행위의 주체
- 대상 : 핵심 엔티티와 중요 엔티티/행위 엔티티 간의 관계에서 업무 행위의 대상
- 상세 : 중요 엔티티와 행위 엔티티 간의 관계에서 행위 엔티티가 중요 엔티티에 대한 상세를 나타낼 때. 중요 엔티티를 세분화할 때
- 인과 : 중요 엔티티/행위 엔티티와 중요 엔티티/행위 엔티티 간의 관계에서 업무 행위의 원인이나 근거를 나타낸다
- 역할/자격 : 핵심 엔티티와 다른 엔티티 간의 관계에서 업무 행위에 대해 특정 역할을 나타낸다
- 구성 : 핵심 엔티티와 핵심 엔티티 간의 관계에서 구성/포함 관계를 나타낸다
- 참조 : 핵심 엔티티와 다른 엔티티 간의 관계에서 엔티티 고유 정보에 부속한 정보들을 참조한다. 구성이나 상세와 혼동될 수 있는데, 참조는 핵심 엔티티의 부분에 대한 상세라고 보면 된다 (예 : 고객주소-도로명주소코드)
관계 정의
- Cardinality
- Optionality
- Identifier Inheritence
위 세가지를 정의한다
관계명(동사) 부여
관계를 직관적으로 알 수 없는 경우에만 부여하면 된다
양쪽의 의미가 많이 다를 때만 양쪽 각각 부여하면 된다
동사보다 명사가 적합할 때는 명사로 부여하면 된다
결론적으로 관계명은 이해를 돕기 위한 것이기 때문에 업무에서 이해가 될 정도로만 기술하면 된다
속성 도출 및 정의
속성 도출
- 핵심 엔티티 속성
- 식별자 및 명칭
- 특성/특징/제원
- 접촉정보
- 위치정보
- 약관/정책
- 관계 속성
- 중요 엔티티/행위 엔티티 속성
- 참조 식별자
- 거래 정보, 업무처리정보 등
속성명 부여
속성을 가장 명확하게 설명할 수 있는 명칭을 부여해야 한다
- 속성 명칭은 표준단어의 조합으로 구성된 표준 용어를 사용하며, 반드시 도메인으로 끝나야 한다
속성 = (수식어) + (주제어) + (수식어) + ... + 도메인 - 경우에 따라 도메인 명으로만 정의할 수 있다
- 엔티티명과 동일할 수 없다
- 수식어는 엔티티명이 주어졌을 때 의미를 파악할 수 있는 정도로만 부여한다
- 용어를 축약하지 않는다
속성 정의
속성에 대한 설명이나 데이터 발생 규칙 등을 기술
관계명 부여와 동일하게 상세하게 작성해야 할 부분만 상세하게 작성한다. 전부 상세하게 작성하면 시간이 너무 많이 든다
식별자 지정
- Uniqueness
- Minimality
- Not Null(Existence)
위 세 조건을 만족하는 속성(들)을 식별자로 지정한다
인조 식별자 정의
- 엔티티 통합 시 식별자가 서로 다르거나 데이터 집합 단위가 다른 경우
- 본질 식별자에 비해 데이터 모델을 단순화하고, 개발 편의성 및 성능적 이점을 가져갈 수 있는 경우
- 본질 식별자가 개인정보인 경우
- 본질 식별자에 대한 데이터가 들어 오지 않은 상태에서 업무를 처리해야 하는 경우
도메인 및 데이터타입 지정
데이터 표준에서 정의한 도메인으로 값의 범위와 데이터타입을 지정할 수 있다
예) 고객유형코드, 주문상태코드 등 "코드"가 도메인인 속성들의 값의 범위와 데이터타입은 "코드"라는 도메인에 정의된 값의 범위와 데이터타입을 따른다
이후 과정
- 옵셔널리티(Not Null) 지정 : 반드시 값을 가져야 하는지 지정한다
"NULL을 0으로 해도 되는지 NULL로 해도 되는지"와 같은 문제를 현업 담당자와 검토하여 결정한다 - Default 값 지정
- 데이터 모델 검토 : 검토를 통해 데이터 모델의 완성도를 높인다
- 자체 검토
- 동료 검토
- 이해관계자 리뷰
- 산출물을 통한 검토
데이터 표준화
데이터 항목에 대한 명칭과 의미를 정하고 실제 저장하고 활용하는 데이터 값에 대한 형식과 범위를 규정
→ 의사소통을 원활히 하게 해준다
일반적으로 데이터 모델링을 진행하면서 표준화를 먼저 수행하는 경우가 대부분이다
단어 표준화
- 기본단어
- 분류단어 : 표준도메인으로 정의해야 한다
- 유사어(금칙어) : 예를 들어, 협력업체와 하청업체가 있다면 협력업체를 기본 단어로 선택하고 하청업체는 금칙어로 지정한다
일반적으로 동음이의어와 이음동의어는 허용하지 않는다
영문약어는 4~6자리로 한다
도메인 표준화
분류단어로 정의된 단어를 대상으로 한다
예) 고객번호, 번호, 코드, 여부, 명, 내용, 일자, 수 등
코드 표준화
| 코드 유형 | 정의 | 예시 | 특징 |
|---|---|---|---|
| 분류형 | 계층 구조를 가진 코드 체계로, 상위-하위 개념이 명확히 구분됨 | 01(제조업) → 011(식료품 제조) → 0111(육류 가공업)KSIC, ICD, ISIC | - 코드 자체에 상하위 분류 정보 내포 - 통계/분석에 적합 - 범주화 및 Drill-down 용이 |
| 일련번호형 | 의미 없는 순차적 번호로, 식별 목적의 코드 | 0001, 1001, A023 등 | - 코드 자체에 의미 없음 - 단순 식별용 - 시스템 관리에 유리 |
| 약어형 | 의미 있는 단어나 명사를 약어로 표현한 코드 | KR(Korea), NY(New York), ENG(English) | - 사람이 이해하기 쉬움 - 국가, 언어, 부서 등 명칭 중심 항목에 사용 |
| 차용형 | 외부 시스템에서 사용하는 코드 체계를 그대로 가져옴 | 외부 ERP 코드, 정부기관 코드, 연계 시스템 코드 등 | - 연계 용이 - 내부 표준화 어려움 - 변경 시 영향도 큼 |
용어 표준화
표준단어의 조합으로 표준용어를 지정한다
분류어가 가장 마지막에 온다
