프로젝트 성패를 결정짓는 데이터 모델링 이야기1

story 01. 데이터 모델링은 일상 가까이 존재한다.

 

- 자동차 동호회 예시를 통한 데이터 모델링

성명	나이	주소	이메일	휴대폰	제조사	차종	색상	배기량	년식
홍길동	35	서울시	hong@naver.com	010-1234-5678	랜드로버	이보크	WHITE	2200	2012
김철수	42	경기도	kim@naver.com	010-9876-5432	현대	벨로스터	RED	1600	2010
고주몽	51	경기도	go@naver.com	010-4569-7825	아우디	A7	SILVER	3000	2013

 

문제1. 만약 회원이 보유한 차량이 두 대 이상인 경우 이메일이나 휴대폰과 같은 개인정보가 차량 대수만큼 반복된다.

해결1. 위와 같은 경우가 발생하면 회원 명부라는 관점보다는 회원의 차량 정보가 우선시 되는 느낌이 들기 때문에, 이를 회원 개인 정보와 보유 차량 정보로 분리한다.

홍길동	35	서울시	hong@naver.com	010-1234-5678	랜드로버	이보크	WHITE	2200	2012
홍길동	35	서울시	hong@naver.com	010-1234-5678	포르쉐	박스터	WHITE	2700	2015

↓

성명	나이	주소	이메일	휴대폰
홍길동	35	서울시	hong@naver.com	010-1234-5678
김철수	42	경기도	kim@naver.com	010-9876-5432
고주몽	51	경기도	go@naver.com	010-4569-7825

성명	제조사	차종	색상	배기량	년식
홍길동	랜드로버	이보크	WHITE	2200	2012
홍길동	포르쉐	박스터	WHITE	2700	2015
김철수	현대	벨로스터	RED	1600	2010
고주몽	아우디	A7	SILVER	3000	2013

 

문제2. 성명이 똑같은 사람이 존재할 수 있기 때문에, 성명 속성만으로는 보유 차량 정보가 어떤 사람의 소유인지 확인이 불가능하다.

해결2. 위 문제를 해결하기 위해 회원을 명확히 구별할 수 있는 회원번호 속성을 추가한다.

회원번호	성명	나이	주소	이메일	휴대폰
10001	홍길동	35	서울시	hong@naver.com	010-1234-5678
10002	김철수	42	경기도	kim@naver.com	010-9876-5432
10003	고주몽	51	경기도	go@naver.com	010-4569-7825
10004	김철수	28	서울시	cheol@naver.com	010-7956-1854

회원번호	제조사	차종	색상	배기량	년식
10001	랜드로버	이보크	WHITE	2200	2012
10001	포르쉐	박스터	WHITE	2700	2015
10002	현대	벨로스터	RED	1600	2010
10003	아우디	A7	SILVER	3000	2013
10004	AUDI	A6	SILVER	3000	2012

 

문제3. 만약 보유 차량을 제대로 분석할 경우 '아우디'와 'AUDI'가 같은 제조사임을 알 수 없게 된다.

해결3. 이를 위해 제조사명을 표준화해서 작성한다.

10003	아우디	A7	SILVER	3000	2013
10004	아우디	A6	SILVER	3000	2012

 

* 동호회 사례와 데이터 모델링의 관계 정리

• 표는 관계형 데이터베이스(RDB; Relational Database)의 릴레이션(relation)을 의미한다.
• 이질적인 정보가 혼재되어 있다면 데이터 간의 종속성을 기준으로 분리, 즉 정규화해야 함을 의미한다.
• '보유 차량 정보'표를 분리하는 것은 1정규화가 적용된 결과이다.
• 표 사이의 연결고리는 데이터 모델의 관계(relationship) 속성에 해당한다.
• 회원번호는 엔디디의 주 식별자(primary identifier)에 해당한다.
• 'AUDI'를 '아우디'로 표기하기로 한 것은 데이터 표준화의 개념 중 코드(code)와 관련있다.

 

story 02. 데이터를 이해한다는 것

 

- 업무를 이해한다는 것과 업무 데이터를 이해한다는 것

• 업무 이해 : 메가 프로세스와 같이 단위 업무의 시작과 끝을 일의 경로나 공정을 중심으로 알아간다는 것을 뜻한다.
• 업무 데이터의 이해 : 기업의 비즈니스를 데이터 측면에서 처음부터 끝까지 조명해보는 것읻. 즉, 업무 프로세스나 프로세스 지원 시스템의 기능과는 완전히 분리해서 생각해야 한다.

 

 

- 상품 주문 데이터를 이해하는 올바른 시선

 

고객과 상품을 주문이라는 관계로 직접 연결한 모습

 

고객과 상품 사이의 M:N관계를 해소한모습

 

* 통상적으로 보아온 상품 주문의 모델링 과정

고객과 상품 사이에는 주문이라는 관계가 있다. 한 고객이 여러 상품을 주문할 수 있고, 하나의 상품을 여러 고객이 주문할 수있는 다대다(M:N) 관계이다. 이를 관계형 데이터베이스로 구현하기 위해 M:N 관계를 해소하면 주문이라는 관계 엔티티로 만들어진다. 그리고 주문과 상품은 여전히 다대다 관계이므로, 이것 역시 풀어주면 고객, 주문, 주문상품, 상품이라는 엔티티가 도출된다.

 

* 다른 방식의 모델링 과정

만약 '고객이 특정 상품을 평생 단 한번만 구매할 수 있다면' 구매는 고객과 상품의 관계 엔티티로 볼 수 있다. 하지만 고객이 같은 상품을 여러 번 살 수 있도록 하려면 시간이라는 개념이 하나 더 관계되어야 한다.

주문을 고객과 상품의 단편적인 관계로 보면 주문이라는 데이터는 고객과 상품에 종속되기 때문에, 키값은 '고객번호'와 '상품번호'가 될 것이다. 이 때 만약 동일한 고객이 동일한 상품을 나중에 구매할 경우, 이전 주문과 구별이 어렵다. 이를 구별하기 위해서 '주문일시'와 같은 시각정보나 '주문일련번호'아 같은 인조 식별자를 추가해야 한다. 이렇게 될 경우 주문을 구별해주는 식별자는 고객과 시각이 된다. 어떤 상품이냐보다 누구와 언제라는 정보가 중요하다. 

 

 

따라서 주문은 상품보다는 오히려 주문 시각이라는 시간 개념이 절대적으로 개입되는 고객 행위로 보아야 한다. 이처럼 비즈니스 행위, 즉 트랜잭션에는 반드시 시간의 개념이 개입되며, 이는 행위 엔티티의 식별자에 타임스탬프와 같은 시각 속성이 존재하는 것에서 확인할 수 있다.

 

story 03. 데이터 저장 구조에 대한 고민을 시작하다.

 

- 애플리케이션 화면과 RDB의 테이블은 다르다.

 

예를들어, 애플리케이션 화면에 있는 하나의 주문서는 체계적으로 조직화된 하나의 집합체로 보인다. 여러 개의 부분이 모여서 전체를 이루고 있지만, 구조적으로는 주문서 한 장으로 보이는 것이다. 데이터 모델링은 최종 사용자에게 보이는 하나의 집합체에서 데이터의 구조적인 부분을 분리하는 작업이다. 하나의 뷰에 포함된 데이터를 여러 테이블로 그리고 다시 여러 행으로 분리하는 이유는 데이터 관리(저장, 수정, 조회 등)에 유리하기 때문이다.

애플리케이션 화면에 보이는 데이터가 RDB에 저장되는 모습

 

 - 올바른 데이터 모델링을 위한 기본기

• 데이터의 근본 성격 파악 -> 데이터 집합과 개체 식별
• 데이터의 종속성 분석 -> 데이터의 독립성 확인과 모델 골격 조망

 

story 04. 데이터를 모델링한다는 것

 

- 디멘션 모델링, 데이터의 관점을 읽어 모델링하다.

 

2014년
지역 중분류	지역 소분류	상품 유형 A		상품 유형 B
		상품번호A0	상품번호A1	상품번호B0	상품번호B1
강원도	춘천시	3	4	1	2
	원주시	43	5	6	87
	…	…	…	…	…
경기도	…	…	…	…	…

 

위 표를 보면 지역, 상품, 기간이라는 3가지 정보가 기준이 되어 판매량을 집계하는 것을 확인할 수 있다. 예를 들어 위 표의 87이라는 값은 상품 B1이 가원도 원주시에서 2014년 한 해 동안 87개 판매되었다는 사실을 나타낸다. 다시 말해 87은 강원도 원주시라는 지역, 상품 유형은 B고 상품 번호는 B1인 상품, 그리고 2014년이라는 기간, 이 세가지 관점(디멘션)이 결합된 값이다.

 

상품 판매량 데이터의 디멘션과 그 계층구조

 

상품 판매량 ERD

 

디멘션이 팩트를 결정하는 기준 정보로서의 부모 역할을 하게 디고, 어떤 팩트를 결정하는 유형과 개념은 반드시 그 책트의 상위로 올라가야한다. 상품 판매량의 데이터를 보면 기간별, 지역별, 상품별 판매량에서 '~별' 디멘션은 데이터를 해당 디멘션으로 한정하는 동시에 구조화할 수 있도록 하고, 지역 중분류, 지역 소분류와 같은 그룹핑 주고는 유형화를 위한 데이터 계층 조직화에 대한 실마리를 제공한다. 데이터를 모델링한다는 것은 이처럼 데이터를 이해하고 유형화하고 구조화하는 과정이다.

 

- OLTP와 OLAP의 서로 다른 세계, 그리고 데이터 모델링의 목표

구분	OLTP	OLAP
목적	비즈니스 활동(거래) 지원	비즈니스 활동에 대한 평가, 예측
트랜잭션 유형	Insert, update, delete, select	Select
데이터 수명 주기	실시간	ETL 일정에 따른 주기
관리 단위	정규화가 수행된 테이블	분석을 위한 관련 정보
시간성	현재 데이터	과거 데이터
설계 기법	정규화에 기반한 ER 모델링	디멘션 모델링
최적화 방향성	데이터 갱신 효율성, 무결성 극대화	조회 성능 사용성, 접근 편의성

 

OLTP의 데이터 관리 단위가 정규화된 테이블이라면, OLAP에서는 분석과 집계를 위한 관련 데이터들의 묶임이 그 단위가 된다. 즉, OLTP는 정규화를 중심으로 OLAP는 분석, 집게의 관점, 디멘션을 중심으로 모델링해야 한다.

 

story 05. 범주화와 추상화, 엔티티의 본질

 

- 범주화 : 유사한 것들을 일정하게 묶는 프로세스

- 추상화 : 문제 영역에서 가장 핵심적인 특성만을 추리는 과정. 구체적 사물들의 공통된 특징, 즉 추상적 특징을 파악하여 인식의 대상으로 삼는 행위이다. 

- 데이터 모델링

• 엔티티란 업무 수행에 필요한 데이터를 성격이 유사한 것끼리 모아놓은 집합니다.
• 모델링이란 정보를 담는 최소 단위인 속성의 종속성을 분석하여 유사한 것끼리 모르고 독립적인 것은 분리하는 과정이다.
• 이러한 과정을 통해 속성의 제 위치(엔티티)를 찾아낼 수 있다.
• 즉, 관계형 데이터 모델은 나의 정보는 내가 집약해서 갖고, 남의 정보는 필요할 때 관계를 통해 찾아서 원하는 뷰를 만들어내는 구조다.
• 데이터 모델링이란 결국 어떤 개체가 속하는 범주를 규명하여 개체 집합을 분리하고 묶는 수준을 고민하는 과정이다.

 

story 06. 데이터 모델링은 2차원 표에 데이터를 어떻게 담는 것이 최선인지 고민하는 과정이다

 

 

- 3단계 스키마 구조

• 외부 스키마 = 사용자 개개인이 보고자 하는 정보 단위의 뷰
• 개념 스키마 = 개별 사용자 관점을 데이터 관점으로 통합한 뷰(DBMS와 무관하다)
• 내부 스키마 = 데이터가 DBMS에 저장되는 논리적 구조(DBMS 종류에 따라 달라질 수 있다. RDB는 2차원 표 구조)

 

- 3가지 모델

• 개념 모델 = 주요 엔티티(주 식별자, 주요 속성)를 도출하고 엔티티 간의 관계를 정의한 모델
• 논리 모델 = 개념 모델을 상세화하여 모든 엔티티와 엔티티별 속성을 도출, 정보 요구사항을 인간이 이해하기 적합한 수준으로 그 구조를 정의하고 정규화한 모델
• 물리 모델 = RDB는 구조를 테이블 형태로 인식한다. 성능 등 현실적인 요소를 고려하는 모델

 

- 현실적인 논리 모델 = 정보 요구사항을 데이터 관점에서 사람이 이해하기 쉬우면서, 가능한 한 테이블과 유사한 형태로 만든 모델

1. 물리적 요소인 인덱스, 파티션, 클러스터, 뷰 등 데이터 구조에 종속적이며 대부분 성능과 밀접한 것을 고려하는 것은 논리 모델이 아닌 물리 모델 단계에서 고민한다. 논리적 모델은 개념 스키마에 집중하는 단계이다.
2. 데이터 모델의 전체 구조를 결정짓는 주요 엔티티에 관련된 모든 결정은 논리 모델 단계에서 해야 한다.
3. 속성의 데이터 타입은 논리 모델 단계에서 정의한다.
4. 논리 모델은 정규화 이론을 기반으로 데이터 중복을 최소화하면서 무결성을 극대화하는 관점이다. 물리 모델은 DBMS가 데이터를 담는 논리적 관점으로, 무결성이 조금 손상되더라도 성능과 같은 현실적 이슈를 최대한 해결하기 위한 뷰라고 할 수 있다.

 

- 데이터 모델링은 2차원 표에 데이터를 어떻게 담는 것이 최적인지, 그 구조를 고민하는 과정이다. 또한 데이터 모델은 단순히 도식화된 모형이 아닌 데이터베이스가 최고의 성능을 낼 수 있는 구조여야 한다. 정규화는 이에 대한 궁극의 기반 이론이다.

 

 

 

책 : 프로젝트 성패를 결정짓는 데이터 모델링 이야기