데이터 모델링

사용자의 요구사항을 분석해서 IT시스템을 구축하기 위하여 ‘데이터’ 요건을 형상화하는 작업 (테이블을 만들어놓고 데이터를 잘 모델링한 후, 그 데이터에 사용자가 쉽게 접근하게 하기 위해 프로그래밍을 하는 순서다)

• 프로그램에 데이터 모델링이 필요한 이유
  • 소프트웨어의 본질은 동작과 데이터다
    • 소프트웨어는 프로그래밍 언어를 이용해서 데이터를 제어하는 수단
    • 소프트웨어의 가장 중요한 요소인 데이터를 얼마나 잘 이해하는지가 중요하다
  • 소프트웨어는 데이터를 제어하기 위한 언어나 도구를 사용한다
    • CRUD로 대표되는 다양한 기능들을 구현한다. CRUD는 결국 데이터를 제어하는 과정이다
  • 데이터모델링의 본질 또한 데이터다
    • 추상화하고, 단순화하고, 명확하게 만들어가는 과정이다
  • 소프트웨어의 본질인 데이터가 얼마나 잘 만들어졌는가가 소프트웨어의 품질에 많은 영향을 미친다.

필요성

• 요구사항은 보통 애매한 것이 많다
• 사용자는 여러 사람이 있다
• 데이터는 여러 업무에서 사용된다

→ 어떤 데이터가 필요한지를 정리하고 명확히 커뮤니케이션 할 필요가 있다.

→ 개별업무 시각에서 벗어나 전체 시각에서 일관된 개념 하에 일관된 방법으로 분석하고 정리해야 한다

모델링은 데이터를 잘 정의해 놓은 것이고, 그것을 사용하기 위해 DML을 사용한다.

DDL : 데이터 정의어
DML : 데이터 조작어

중요성

파급효과 Leverage

1. 데이터 모델 변경
2. 표준 영향 분석, 응용 변경 영향 분석 등
3. 해당 분야의 실제적인 변경 작업
4. 전체 시스템 구축 프로젝트에서 큰 위험요소

복잡한 정보 요구사항의 간결한 표현 Conciseness

구축할 시스템의 정보 요구사항과 한계를 가장 명확하고 간결하게 표현할 수 있는 도구 (데이터 모델은 건축물의 설계도면 같은 것이다)

ERD 개체-관계 다이어그램(Entity-Relationship Diagram): 전략적 계획이나 또는 하향식 계획에서 자주 사용되며, 개략적인 상부계층의 데이터 다이어그램

데이터 품질 Data Quality

데이터 품질의 문제가 야기되는 중대한 이유 중 하나가 데이터 구조의 문제다

데이터 정규화

데이터 모델의 종류

데이터 모델 level 통상적인 구분

1. ⛱️ Conceptual 개념

2. ⛱️ Logical 논리

3. ⛱️ Physical 물리

데이터 모델 level 세분화된 구분

1. 데이터 개념

   정보를 추상화하여 단순화된 개념으로 분류한 것

2. 개념모델

   핵심엔티티 및 핵심엔티티간의 관계를 표현한 모델 (key 속성만 포함. ERD와 다름)

3. 논리모델

   어플리케이션에 의한 데이터 사용 형태 및 구현상의 제약 사항을 고려하지 않고 작성된 모델

4. 업무 논리모델

   어플리케이션에 의한 데이터 사용 형태 및 구현상의 제약사항을 고려하여 도출 (비즈니스적으로 분류를 함)

5. 물리모델

   시스템의 기술 요건 및 운영 요건을 반영한 모델 (테이블에 해당)

데이터 모델 접근 방법론

• Top-down
  • 데이터 개념부터 시작하여 상세 모델 작성
  • 가장 기본적인 방법
  • (개념) → 개념 → 논리 → (업무논리)→ 물리모델
• Bottom-up
  • 데이터 베이스를 reverse하는 방식으로 작업
  • 데이터베이스 → 물리모델 → 논리 데이터 모델 → 개념 모델 단계로 작업
• Hybrid
  • Top-down과 Bottom-up을 혼용
  • Top-down approach로 일관된 개념을 가진 통합데이터 모델을 작성
  • Bottom-up approach로 누락 없는 상세 모델 작성

데이터 모델링의 구성요소와 개념

데이터 모델링의 3요소: Entity, Relationship, Attribute

Entity - Relationship

개체들의 관계를 중심으로 기술하는 이론

Entity, Entity Occurrence, Attribute, Cardinality, Relation, Normalization, Sub-Type

해당 용어들은 물리 DBMS까지 나온다.

Entity

• 엔티티를 정의한다는 것 : 데이터 관리 대상이 되는 것(사물)의 종류(유형)을 도출하는 작업
• 엔티티는 개념 모델. 엔티티는 반드시 반드시 하나의 테이블로 만들어지는 것(1:1매칭x, 1:n매칭 가능)은 아니다. 복수의 테이블이 될 수도 있다. 테이블과 엔티티는 다른 개념이다.

Entity Type

• Entity의 원래 용어는 Entity Type
• Entity Type : Entity를 분류하는 작업을 통해 도출된다.

사물의 종류 예시 : 계좌를 만들 때의 계좌, 요구불 상품, 여신 상품 등의 상품

• Entity를 얼마나 추상화하여 보느냐에 따라서 같은 Entity Type이 되기도 하고, 다른 타입이 되기도 한다.

특징

• 업무에서 필요한 정보를 갖는 것이어야 한다
• 업무를 수행함에 있어서 지속적으로 중요한 의미를 가진 것이어야 한다
• 구성 엔티티 어커런스를 식별자에 의해 유일하게 구별 Uniquely Identified 할 수 있어야 한다
• 궁극적으로는 속성 값으로 표현되는 관찰 가능한 특성을 갖고 있어야 한다

엔티티를 식별하는 곳 : 업무기술서, 규정집, 업무관련 장표, 현 전산시스템, Use Case, 회의

명명규칙

• 현장에서 보편적으로 사용하는 업무용어를 사용한다
• 명사 또는 명사구를 사용한다
• 모델에서 유일한 이름이어야 한다
• 뜻이 보존되는 한 이름을 짧게 해야 한다
• 기본/상세/내역/이력/관계 등으로 엔티티의 성격에 따라 명칭을 통일하는 경우도 있다

Entity Occurrence

• 엔티티에 소속된 사물의 예를 의미
• Entity Instance 라고도 한다
• 간혹 Entity라고도 한다. Entity Type이 엔티티이고, Entity는 엔티티 어커런스를 의미한다

Super Type Entity & Sub Type Entity

여러 개의 엔티티가 공통 속성이 있고, 일부의 속성이나 관계만 다를 경우

공통 속성을 위한 하나의 엔티티 super type와

개별 속성을 위한 복수개의 엔티티 sub type을 정의한다

• super type key와 sub type key는 동일하다
• sub type의 엔티티 어커런스는 반드시 super type에 속해야 한다
• 잠재적으로 null값을 가지는 속성은 sub type으로 정의된다

객체 지향적 개념으로 생각해보면, super type - sub type의 관계는 class의 상속과 비슷하다. super type은 추상 클래스인 super class, sub type은 sub class로 super class를 상속받은 객체와 같은 개념이다

• Super-Sub관계를 좀 더 확장하여 정의할 수도 있으며, 이 경우 super - sub type관계가 포함관계/ 중복 여부에 따라 세분된다.
• 포함관계 : Super Type의 어커런스가 반드시 Sub Type의 어커런스로 존재하는지 여부
  • Exhaustive(total) : 반드시 sub type에 있다
  • Non-Exhaustive(Partial) : sub type 에 없을 수도 있다
• 중복여부 : super type의 어커런스가 2개 이상의 sub type어커런스가 될 수 있는지 여부
  • Disjoint(Exclusive) : 중복 불가능 → sub type판단을 위한 attribute가 하나다
  • Overlap : 중복 가능 → sub type 판단을 위한 attribute가 복수이다

객체지향 설계 5 원칙 SOLID

1. SRP (단일 책임 원칙)
2. OCP (개방-폐쇄 원칙)
3. LSP (리스코프 치환 원칙)
4. ISP (인터페이스 분리 원칙)
5. DIP (의존 역전 원칙)

Relationship

엔티티 간에 존재하는 상호간의 연관성을 Cardinality와 Relationship Name 으로 표기한다

행위에 의한 관계 예시 ) 고객(신규한다) - 계약(신규된다) 소유에 의한 관계 예시 ) 상품(갖는다) - 조건(속한다)

• 관계는 업무 규칙 (business rule)을 기술한다

  ex) 1개의 계좌는 1명의 고객에게만 소유됨

• 관계는 데이터 상으로 관리 대상이 되는 관계를 의미한다
• 두 엔티티 간의 관계는 2개 이상일 수 있다

관계명 Relationship name

• 두 엔티티 사이의 관계는 선으로 표시함
• 관계선의 좌우 또는 상하에 관계명을 기록한다
• 통상 application 데이터 모델(c level)이하 단계에서는 크게 의미가 없어 표기하지 않는다

관계명 명명규칙

• 애매한 동사는 사용하지 않아야 한다
• 현재형으로 표현한다

기수 Cardinality발생 유형

최대 기수 - 3가지 유형

• 두 개의 엔티티 간 관계에서 한 엔티티의 한 어커런스를 기준으로, 상대 엔티티의 관계가 있는 어커런스가 최대로 몇 개까지 있을 수 있는가를 표현 - 1 : 1관계 - 1 : m 관계 - m : m 관계

관계의 기수

• ex) 각 고객은 때때로 하나 이상의 주문을 발주한다. (때때로: 할 수도 있고 안 할수도 있다) 고객이 주문을 발주한다 주문은 고객에 의해서 발주된다 각 주문은 항상 한 고객에 의해 발주된다

관계 검증 - 중복제거

원형관계 제거 : 무한루프에 빠질 수 있기 때문에 끊어주어야 한다.

• ex) 제품 >-< 창고>-< 재고가 다대다 관계(제품-창고, 창고-재고, 제품-재고)로 얽혀있으면 창고에 어떤 물건이 몇 개 남았는지 한번에 알기 힘들다. 다대다로 얽힌 관계는 나쁘다. 다대다 관계를 끊어주어야 한다.

사슬관계 제거

• ex) 부서 - 사원 - 기술(부서와 연결) → 기술-부서 연결을 끊어주어야 한다. 사원이 기술을 가지고 있는거지, 부서는 기술을 쌓을 수 없다.

관계 검증 - M:N 관계 단순화

• 관계를 별도 엔티티로 분리 : 숨겨진 정보로부터 연관 엔티티를 추출
  • ex) 고객 -< 상품 관계를 아래와 같이 바꿔야한다 (정규화과정) 고객 - < 계약 > - 상품 고객, 상품은 unique한 값이고, 계약은 unique하지 않기 때문에 다대다로 연결 복잡도는 올라가지만 보다 바람직한 방법이다

관계 검증 - 1:1 관계 정제

• 데이터 모델링 과정에서 엔티티 간의 관계가 1:1로 대응되었다는 사실은 해당 엔티티들의 기본키가 동일하다는 뜻
• 1:1 관계를 가진 모델은 3가지 방법으로 표현할 수 있다
  1. 하나로 통합
     • mandatory 관계
     • 기본키가 동일
     • 대부분의 속성과 관계가 통일
  2. 그대로 유지
     • optional관계이면서 대부분의 속성 및 관계가 상이한 경우
     • 대응되는 속성의 값이 서로 상이한 경우
  3. 새로운 Super Type 엔티티 추가
     • 기본키가 동일하고 속성의 일부만 상이한 경우

관계를 기준으로 나눈 엔티티 분류

1. 기본형 엔티티 Fundamental Entity

   상품 엔티티

2. 속성형 엔티티 Attributive Entity

   상품 -< 상품명 → 상품명은 부적절한 엔티티. 상품명과 같은 속성은 entity가 아니라 column으로 존재해야한다.

   index란 데이터를 빠르게 찾을 수 있는 수단으로, 테이블에 조회 속도를 높여주는 자료 구조다.

3. 관련형 엔티티 Associative Entity

   상품-< 상품관련지점 >- 지점

Attribute

엔티티가 관리해야하는 데이터항목

더 이상 분리될 수 없는 최소의 데이터 보관 단위

향후 물리 데이터 모델링 작업을 통해 컬럼으로 변환됨

속성 명명규칙

• 해당 업무에서 사용하는 이름을 부여한다
• 엔티티에서 유일하게 식별가능하도록 지정해야 한다
• 약어를 사용하지 않는 경우가 거의 없다
• 속성은 전체 데이터모델에서 하나의 의미만을 가져야한다

• “수식어 + 도메인명” 형식을 사용하여 표준화한다

  데이터 항목 이름이 다르고 의미가 다른 경우 : *계좌개설*일, *계좌신규*일 데이터 항목 이름이 같고 의미가 다른 경우 : 일자(*계좌신규*일, *계좌해지*일)

속성 타입 Attribute Type

• 근본적으로는 속성 Attribute 와 같은 의미다

• 엔티티가 갖는 속성의 유형을 의미한다

  고객의 성명, 주소, 소속회사명, 전화번호 등

속성 인스턴스 Attribute Instance

• 속성 타입의 값 Value을 의미한다

도메인 Domain

어떤 한 속성 attribute에 허용되는 업무적으로 의미 있는 인스턴스 값의 집합

• 속성이 가질 수 있는 값에 대한 업무적 제약요건으로부터 파악된 특성
• 속성에 대한 데이터type과 크기, 제약사항을 지정한 것
  • 항목 표준화에 따르는 사항으로, 데이터 관리자가 결정
  • 모든 업무영역에서 같은 도메인 집합을 사용

속성 배치1

• 기본키에 종속되는 속성을 해당 엔티티에 배치

• 가능한 범위 내에서 부모 엔티티 쪽으로 배치

• 속성이 여러 개의 값을 가질 수 있는 경우, 새로운 자식 엔티티를 만들어 자식 엔티티의 속성으로 배치

속성 배치2

• 관계를 구체화 시켜주는 속성이 존재할 경우 관계를 엔티티로 전환시켜 해당 속성 배치

  상품 >-< 지점 (판매라는 행위를 표현하기 위해 만드는 attribute : 판매시작일, 판매종료일)

속성 배치3

• Super Type엔티티, Sub Type엔티티 내의 속성 배치

  • Super Type 엔티티에 Sub Type 엔티티의 구분항목을 속성으로 등록
  • Sub Type 엔티티 모두에 포함되는 속성을 Super Type 엔티티로 이동

속성에서의 기수 표현

Key 식별자

한 엔티티 내에서 각각의 어커런스를 유일하게 구분할 수 있는 단일 속성 또는 속성 그룹

후보키 candidate key 기본키 primary key 주요키, 일차키 대체키 alternate key 복합키 concatenate key 연결키 외부키 foreign key : 테이블과 테이블을 연결할 때 합성키 compound key

후보키 Candidate key

• 엔티티 내에서 각각의 어커런스를 유일하게 구분할 수 있는 속성. 하나 또는 하나 이상의 속성으로 구성된다.
• 기본키가 될 수 있는 후보 속성이다.

기본키 Primary key

• 어느 엔티티 어커런스를 식별하기 위한 속성을 의미한다
• 조건
  • 유일하게 구분이 되어야 한다 Unique
  • 반드시 데이터 값이 존재해야 한다 Not Null
  • 가능하면 변하지 않아야 한다 Never change
  • 가능하면 업무적으로 활용도가 높은 것으로 정의하여야 한다
  • 가능하면 길이가 짧은 것을 선정해야 한다

대체키 Alternate key

• 후보키 중에서 기본키로 선정되지 않은 키
• primary key이외에 엔티티 인스턴스를 unique하게 식별하는 key

복합키 Concatenate key

• 2개 이상의 속성으로 primary key를 구성한 key

외부키 Foreign key

• 어떤 엔티티 A가 다른 엔티티 B와 관계를 갖는 경우 B엔티티와의 관계 때문에 속성으로 갖게 되는 B 엔티티의 primary key를 말한다
• pk, fk 구분해서 이해하는 것이 중요하다

합성키 Compound key

• 엔티티와 엔티티의 관계가 Many to Many일 때 그 관계를 나타내는 엔티티의 key

주제 영역 subject area

• 엔티티를 도출하고 관리하는 단위 영역
• 일반적으로 데이터 중심으로 정의하나, 경우에 따라서 업무 흐름 중심으로 정의되기도 한다
• 계층이 있다
• 최하위 주제영역은 ER Diagram의 작도 단위다

ER 모델 표기법

• Peter Chen 표기법을 가장 보편적으로 사용한다.

논리 데이터모델링 절차

1. 주제 영역 정의
   1. 주제 영역 도출
   2. 주제 영역 명확화
2. 실체 정의
   1. 실체 도출 Entity
   2. 실체 명확화
   3. 식별자 정의 Primary key
3. 속성 정의 Attribute
   1. 속성 도출
   2. 속성 명확화
   3. 정규화 (나누는 것) ↔ 반정규화 (합치는 것)

4. 관계 정의 Relationship

   1. 관계 도출
   2. 관계 명확화
   3. 특수유형관계 정의

   Entity가 만들어진다

5. 업무 규칙 정의
   1. 키 업무규칙 정의
   2. 속성 업무규칙 정의
6. 이력 관리
   1. 시점이력 관리
   2. 기간이력 관리
7. 모델 통합
   1. 수평적 통합
   2. 수직적 통합
   3. 전사 모델 통합

데이터 모델링의 작업 흐름

작업 흐름

1. 데이터 개념 정의 : 전사 통합 데이터 모델과 같은 대규모의 데이터모델을 개발할 때 선행 필요
2. 개념 모델 개발 : 대규모 통합 데이터 모델 개발시, 전체 모델의 구조 및 핵심 엔티티간 관계 정의
3. 논리 데이터 모델 개발 : 개념 모델을 상세화하고 As-Is모델을 통한 보완 작업을 거쳐 완성
4. 업무 논리 모델 개발
5. 물리 모델 개발

개념 데이터 모델링 작업 절차

데이터 개념

1. Sub-Type 도출

• 데이터 개념별로 sub-type을 도출한다

1. 핵심 엔티티 도출

• sub-type을 핵심 엔티티로 도출한다

1. 핵심 엔티티간 관계 정의

• 핵심 엔티티간 관계를 분석한다
• 필요시 Relationship Entity를 도출한다

1. ERD 작성

• 데이터 개념별로 Sub-Type Entity, Relationship Entity간 관계를 ERD로 작성한다

1. 주요속성 도출 및 Entity 정제 → 분할/병합 단계를 거쳐 2. 핵심 엔티티 도출로 돌아간다

• 엔티티의 key 및 주요 속성을 정의한다
• 필요시 속성형 엔티티를 도출한다 (주요 속성형 엔티티로 한정한다)

논리 데이터 모델링

논리 데이터 모델링 작업 절차

개념 데이터 모델

1. 속성도출

• 상세 속성을 도출한다
• 필요시 속성형 엔티티를 도출한다

1. 정규화 검토
   1. 정규화 검토
   2. 엔티티 분할
   3. 엔티티 재정의

• 제 1,2,3 정규화를 수행함
• 필요시 엔티티를 분리함

1. 속성정의
   1. 속성 정의
   2. 도메인 지정
   3. 속성 정비

• 속성의 의미를 정의하고 도메인을 지정 또는 생성함

1. 현행 시스템 정보 분석, 반영 → 1. 속성도출로 돌아간다

• 현행 시스템 정보 반영 여부 검토
• 필요시 엔티티/속성 보완

업무 데이터 모델

데이터 개념의 필요성

개념 데이터를 정의하지 않고 엔티티를 도출하면 고품질의 데이터 모델을 작성할 수 없다

• 업무 처리 흐름을 기술한 문서로부터 명사를 찾아서 엔티티 후보를 도출한다.

• ex) FSDM Financial Services Data Model

  9 concept : 이해관계자, 계약, 조건, 상품, 장소, 분류, 경영방침, 이벤트, 자원 은행을 만들기 위해서 필요한 요소를 정의해놓은 것 기본적으로 금융 it는 기본적으로 이 모델을 기반으로 만든다 9가지 data 개념과 data 개념간의 관계에 관한 정보로 구성된다

• ex) HL7 Reference Information Model

• Previous
  Spring - 객체지향 SOLID 5원칙
• Next
  DB - ANSI-SQL & T-SQL