[DAP 요약] 제 1장 데이터 모델링 이해 - (1/5)

(오프라인 강의 내용을 정리 및 요약하는 자료임)

제 1장 데이터 모델링 이해

데이터 모델링 이란?

데이터베이스 생성을 위한 업무 규칙과 정보의 구조를 표현하는 방법이다. 

 

데이터 모델링 절차

1. 개념 데이터 모델링

비즈니스의 정보 구조를 요약한다. 보통 전체 Entity 개수의 약 10%로 요약된다.

결론적으로 주제 영역으로만 구성된 ERD가 된다.

개념 데이터 모델링만 보면 전체 비즈니스의 요약을 한 눈에 알 수 있다.

 

2. 논리 데이터 모델링

업무 규칙을 전부 표현한다.

개념 모델링에서 정보 구조만 요약한다면 논리 데이터에서 해당 비즈니스의 규칙을 전부 표현한다.

다만, 성능을 고려하지 않고 비즈니스를 완벽하게 표현하는 것을 목표로 한다.

성능은 물리 데이터 모델링에서 반정규화 등을 통해 해소한다.

 

3. 물리 데이터 모델링 

DBMS에 맞춰 "변환" 한다. 물리 데이터 모델링에서 해당 DBMS에 맞춰 성능을 최적화 한다.

 

1. 개념 데이터 모델링

주제영역을 정의하고 주제영역 내의 핵심 엔터티를 도출하여, 그들간의 관계를 정의하는 것.

 = 포인트는 세 가지 이다.

주제영역, 핵심 엔터티, 관계.

1-1. 주제영역

부서를 분류하는 것과 유사하다.

예를들어, 고객/승인/청구,결제/인사/재무,회계 등으로 구분될 수 있다.

1-2. 핵심 엔터티

데이터를 담는 그릇이다. 물리모델에서의 table과 같다.

엔터티 예시. 서브타입을 잘 도출해야 한다.

엔터티는 3가지로 분류된다.

Key 엔터티, Main 엔터티, Action 엔터티

 

1. Key 엔터티

부모가 없는 엔터티. 강사님은 신 엔터티라고 부르셨다.

부모 없이 스스로 생성되는 엔터티이다. 

예를들어 위의 "고객" 엔터티의 경우 다른 엔터티에서 파생되어 부모가 있는 형태가 아닌, 스스로 생성된다.(사용자와 고객을 분리하는 등의 구조가 아닐 때)

2. Main 엔터티

부모는 있으나 자식이 많은(해당 엔터티를 부모로 하는 엔터티가 많은 비즈니스의 핵심이 되는 엔터티) 경우이다.

3. Action 엔터티

이력, 사용 등등 행위에 대한 엔터티이다.

 

이 셋 중에 Key 엔터티, Main 엔터티 두 개를 묶어서 핵심 엔터티로 부르며, 이 두 핵심 엔터티를 도출 하는 것이 개념 데이터 모델링의 목적이다.

 

1-3. 관계

 는 이후 자세히 다룰 예정이다. 일단 관계를 맺는 다는 것만 알고 있자.

 

* 각 데이터 모델 단계에서 하는 일 (외우기)

1. 개념 데이터 모델

주제영역을 정의하고 주제영역 내에서 핵심 엔터티를 도출하여 그들간의 관계를 도출한다(외움)

- 주제 영역 정의

- 엔터티 후보 식별

- 핵심 엔터티 정의

- 관계 정의

2. 논리 데이터 모델

- 속성 정의

- 엔터티 상세화

    - 식별자 확정

    - 정규화

    - M:M 관계 해소

    - 참조무결성 정의

- 이력관리 정의

(논리데이터 모델은 속엔이, 엔터티 상세화는 식정M참!)

3. 물리데이터 모델 

- 논리 물리 데이터 모델 변환

- 반정규화

- 컬럼의 데이터 타입 및 크기 정의, 데이터 사용량 분석 / 인덱스 정의  등등

데이터 표준화

데이터 표준화 구성요소

표준 단어

표준 용어

표준 도메인

 

표준 단어/용어

속성명과 컬럼명의 표준화.

컬럼명이 동일한 의미의 단어(입력, 등록, 기록 등)를 하나의 표준 단어(전부 입력으로)로 통합 하는 등의 작업.

표준 도메인

데이터 타입과 length, value를 표준화 하여 일관된 Data 생성을 유도하는 것.

보통 표준 코드 또한 도메인 표준화에 합하여 정의하기도 한다.

 

따라서 표준화는 표준 단어/용어/도메인(+코드)를 정의하는 것으로 알면 된다.

 

전사 아키텍처

항상 나오던 그림이다.

전사 아키텍처의 목표는 현재의 모습을 가시화 하여 관리하는 것이다.

현행 아키텍터를 현행화하고, 아키텍처가 승인해야 변경되는 프로세스를 반영할 수 있도록 하는 등의 프로세스 및 시스템을 구축하는 것이 전사아키텍처 관리가 되겠다.

 

데이터 모델링

데이터 모델링이란?

정보시스템의 핵심인 데이터를 중복없이 정확하게 유지 관리 할 수 있는 방법

정확한 업무 파악이(데이터에 대한 정확한 분석)이 선결되야 한다

현식세계를 좀 더 잘 표현(Subtype을 잘 정의!)할 수 있는 ERD로 발전했다

 

모델링의 정의

- 기업 업무에 대한 이해를 바탕으로 데이터에 존재하는 업무 규칠에 대해 참 또는 거짓을 판별할 수 있는 사실을 정의

- 현재 업무를 파악하여 문제접을 인식하고, 개선사항을 도출하며, 미래에 적합한 설계를 이끌어 내기 위해 하는 결정들을 내리는 단계까지를 모두 포함하는 것이다

(..? 말이 너무 복잡하고)

 

프로세스 중심적인 시스템의 단점

정보 공유의 문제점이 다수 발생한다.

데이터 무결성에 좋지 않은 영향(각각의 프로세스 마다 중복되는 Data 존재하게 된다)

따라서, 데이터 통합이 중요하다

 

데이터 모델은 의사 소통 수단으로 활용이 가능 해야 한다.

따라서 Entity 등의 명칭을 반드시 직관적으로 명명해야 한다. (중요!)

 

* 데이터 모델링 시 주의할 점

1. 중복(Duplication)

2. 비유연성(Inflexibility)

3. 비일관성(Inconsistency)

 

* 모델링 기본 원칙

가. 커뮤니케이션 원칙

나. 모델링 상세화 원칙

다. 논리적 표현 원칙

 

나. 모델링 상세화 원칙

데이터는 데이터의 본질과 잠재적 사용을 이해할 수 있을 만큼 상세화 되어야 한다.

ㄴ 명확하게 정의해야 하며, 개념과 실체를 구분해야 한다.

개념과 실체란..

도서 엔터티와 보유도서 엔터티가 있을 때 

도서 엔터티는 도서에 대한 모든 정의이고 도서 자체 각각에 대한 의미가 아니므로 개념!

보유도서은 해당 도서를 실제로 보유하고 있어 실체화 되었으므로 실체 이다.

 

* 헷갈리는 사항

사원 엔터티와 부서 엔터티가 있을 때 부서는 사원에 창조관계일 뿐이며 1:M 관계라고 해서 M 쪽이 Key 엔터티가 아닌 것이 아니다..

다만, 부서는 개념 엔터티이고 사원은 실체 엔터티로 구분될 뿐이며 사원과 부서 모두 Key 엔터티 이다.

(나는 부모가 있으므로 Main 엔터티 인 줄 알았다.)

 

실체와 개념 추가 설명

도서 엔터티에 다음 속성이 있을 때

도서명

저자

출판사

도서보관위치

구매일자

도서상태(대출중, 대출가능, 예약) 

파란색(도서명, 저자, 출판사) 는 개념 속성이며

주황색(도서보관위치, 구매일자, 도서상태)는 실체 속성이다.

 

만약 여기에 보유권수 속성이 추가된다면?

보유권수 속성은 개념이다.

실체는 무조건 1개다.

 

다. 논리적 표현 원칙

물리적 제약 조건 없이 비지니스를 그대로 반영 해야 한다.

ㄴ 물리적 제약과 성능 때문에 비즈니스를 잘못 표현하면 안된다! 성능 등은 물리 모델링에서!

따라서 논리 모델은 특정 아키, 기술, 제품과 독립적이어야 한다.

논리적 설계와 물리적 설계를 구분하지 못하면 프로젝트가 추구하고자 하는 선택사항이 물리적 사항에 제한되거나 잘못된 방향으로 갈 수 있다!

 

추상화

1. 집단화(상향식)

- 값을 유형화 하면 속성임

- 속성들의 집합체인 엔터티 타입을 도출해냄

- 값들에서부터 속성 -> 엔터티 타입 -> 엔터티를 도출해내는 방식이 집단화임

2. 일반화(하향식)

- 서브세트(부분집합)을 정의하는 개념

여러 엔터티 타입 간의 공통적인 특성을 파악하는 과정이다.

집단화와 반대 방향으로 엔터티 타입에서 속성을 도출해 내는 방식이다.

 

관계형 모델 이론

데이터 무결성(도참연엔)

1. 도메인 무결성 

데이터 타입, 길이,  Null 여부 등에 대한 제한

2. 참조 무결성

모든 외래 키 값은 관련 있는 엔터티의 모든 주 키 값이 존재해야 함

3. 연쇄 작용

CRUD 등의 작업이 동일 또는 다른 엔터티의 속성에 영향을 비치는 업무 규칙을 정의해야 함

4. 엔터티 무결성

주 키는 행을 유일하게 식별해야 하며, Null 값을 포함하지 않는다.

 

개념 데이터 모델링

1. 개념 데이터 모델 정의

주요 핵심 엔터티 들로 구성됨

ㄴ 핵심 엔터티 : 주체나 목적물이 되는 개체 집합에 해당하는 엔터티

    ㄴ 부모가 존재하지 않는 창조된 집합 > Key Entity

    ㄴ 다른 집합의 존재 유무에 상관없이 독립적으로 탄생

    ㄴ 핵심 엔터티는 대체적으로 여러가지 행위 엔터티를 탄생시킨다

 

개념 데이터 모델링도 주요 엔터티로 한정 지을 뿐, 논리모델링 기법과 동일하다

또한, 개념 데이터 모델링도 논리 모델링처럼 상세화 할 수 있으나! 

상세화를 하더라도 전체적인 골격의 개념 모델링을 벗어나면 안된다.

 

주제영역 개념

기업에서 데이터의 최상위 집합이다.

계획 수립 단계에서는 하향식 분석을 원칙으로 하며, 검증 단계에선 상향식을 원칙으로 한다.

하향식 분석을 위한 개념으로 주제영역이 아주 유용함.  

주제영역은 계층적으로 표현이 가능하며, 보통 2~3depth 정도로 구분 가능하다.

(3 Depth 정도 나오려면 1000억대 정도.. 보통 2 Depth 안에 다 정리 된다고 한다)

주제영역을 분리하면 하위수준의 주제영역 또는 엔터티가 나타난다

 

주제영역 분류 원칙

1. 데이터 중복 최소화

2. 데이터 확장성 보장

3. 데이터 관련성 및 편의성 확보

 

주제영역을 명명할 시에는 반드시 실 업무에서 사용하는 보편적인 용어를 사용할 것!

단수형 명사를 사용!

 

* 주제영역은 데이터의 계층적 구조 파악에 도움이 된다

주제영역은 업무 생산성과 전혀 연관이 없다!

 

엔터티 후보 수집 

(타 시스템 자료도 후보 수집 대상이다)

엔터티 후보 식별 간에는 우리가 관리 하고자 하는 것인지 확실히 구분해라

(필요 없는 것까지 상상해서 관리하지 말아라)

가로와 세로의 면적을 가진 집합인지를 확인하라 

 

1. 엔터티

엔터티의 정의 요건

관리하고자 하는 것인가?

면적(집합) 인가?

대상 개체 간의 동질성(통합하기 위한)이 있는가?

다른 개체와 확연히 구분되는 독립성(분할하기위한)이 있는가?

순수한 개체이거나 행위 집합인가?

 

집합과 동질성의 의미

동일한 성질을 어디까지로 한정할것인지??

ex) 사원 집합을 정직원까지? 아니면 알바나 협력업체도 통합할 것인지?

ex) 개인과 법인 고객을 통합할 것인지 분리할 것인지?  

 

집합의 순수성 의미

개체집합이 되던가, 아니면 활동을 위한 행위 집합 이어야 한다. 충돌이 있어서는 안된다.

ex) 개체집합 : 고객, 상품 등

행위집합 : 입금, 계약 등

충돌의 경우 : 납입자, 입금자

납입자 등의 경우 납입과 고객으로 분리해야 한다.

고객은 개체집합, 납입은 행위집합!

 

* 집합 순수성의 예외 사항

1. 릴레이션쉽의 엔터티 화 : ex) 피보험자!

2. 일부 집합을 별도로 정의 하는 경우 : 금융기관(금융+ 기관으로 묶음. 금융기관의 경우 납부 관계로 인한 릴레이션이 너무 많아서 별도로 정의할 수 있다)

3. 배타적 관계 : 배송처를 고객, 공사현장, 물류센터 등으로 구분하는 경우. (근데 실제 현장에선 거의 없다 한다..)

 

* 코드성 키 엔터티 모델링

코드성 엔터티를 별도로 빼는 경우와 공통 코드에 넣는 경우를 구분할 때 기준은 다음과 같다

1. 이 엔터티(생성할 코드 엔터티)가 자식 엔터티를 가지는가?

2. 그러면서 여러 엔터티에 관계를 가지는가?

3. 다양한 자신만의 속성을 가지는가?

 

*서브타입의 활용

1) 업무 규칙을 명확히 표현할 수 있음

2) 단, 업무 규칙의 명확성과 표현의 복잡성의 트레이드 오프 관계이다

     > 적당한 조화가 필요하다

 

엔터티 통합과 분할

나쁜 형태의 통합은 본질의 희석을 가져와, 집합의 모호성이 증대된다

(= 너무 막 합치면 뭐가 뭐였는지 모른다)

 

* 상위 엔터티(키 엔터티)일수록 통합의 효과가 높다

(= 부모가 여럿으로 나뉘어 있을 때보다 통합되어 있을 때 업무 복잡성이 줄어들지)