1-1 데이터 모델의 이해

데이터 모델링의 정의

업무에 필요로 하는 데이터를 시스템 구축 방법론에 의해 분석/설계하여 정보시스템(DB)을 구축하고 개발 및 데이터 관리에 사용한다.

데이터 모델링의 3대 특징

특징	설명
추상화	현실세계를 간략하게 표현한다
단순화	누구나 쉽게 이해할 수 있도록 표현한다
명확화	명확하게 한 가지 의미로 해석되어야 한다

좋은 모델링의 3대 요건

1. 중복배제
2. Business Rule
3. 완전성

모델링의 세 가지 관점

1. 데이터 관점

• 비즈니스 프로세스에서 사용되는 데이터를 의미
• 업무가 어떤 데이터와 관련이 있으며 무슨 관계인지에 대해 모델링 (What, Data)
• 구조 분석, 정적 분석

2. 프로세스 관점

• 비즈니스 프로세스에서 수행하는 작업을 의미
• 업무가 실제하고 있는 일은 무엇이며 어떻게 해야 하는지에 대해 모델링 (How, Process)
• 시나리오 분석, 도메인 분석, 동적 분석

3. 데이터와 프로세스의 상관 관점

• 프로세스와 데이터 간의 관계를 의미
• 업무를 처리하는 방법에 따라 어떤 영향을 받는지에 대해 모델링 (Interaction)
• CRUD(Create Read Update Delete) 분석

데이터 모델이 제공하는 기능

• 시스템을 원하는 모습으로 가시화
• 시스템의 구조와 행동을 명세화
• 시스템을 구축하는 구조화된 틀 제공
• 시스템을 구축하는 과정에서 결정된 것을 문서화
• 다양한 영역에 집중하기 위해 타 영역의 세부 사항을 숨겨, 다양한 관점을 제공
• 특정 목표에 따라 구체화된 상세 수준의 표현방법 제공

데이터 모델링의 고려사항

1. 데이터 모델의 독립성

• 독립성이 확보되어야 업무 변화에 능동 대응이 가능하다.
• 정규화를 통해 중복된 데이터를 제거해야 한다. 잘못된 데이터 모델링 이후의 변경 작업은 파급효과가 크다.

2. 고객 요구사항의 표현

• 데이터 정합성을 유지하며 정보요구사항을 이해하고 정확, 간결하게 표현해야 한다.

3. 데이터 품질 확보

• 데이터 표준을 정의하고 표준 준수율을 관리해 데이터 품질을 향상시켜야 한다.
• 중복/비유연성/비일관성을 주의한다.

중복 주의: 여러 장소에 같은 정보를 저장하지 않아야 한다.

비유연성 주의: 데이터의 정의를 데이터의 사용 프로세스와 분리하여 유연성을 높인다.

비일관성: 다른 데이터의 모순된다는 고려없이 데이터 수정을 하지 않고, 모델링 시 데이터 사이 상호연관관계에 대해 명확하게 정의하여 일관성을 높인다.

데이터 모델링 단계

1. 개념적 데이터 모델링Conceptual Data Modeling

• 전사적 관점에서 기업의 데이터를 모델링
• 추상화 수준이 가장 높은 모델링
• 계층형 데이터/네트워크/관계형 모델에 관계없이 업무 관점에서 모델링
• 엔터티와 속성을 도출하고 개념적 ERD를 작성
• 추상화. 업무중심적. 포괄적. 개념적 ERD

2. 논리적 데이터 모델링Logical Data Modeling

• 특정 데이터베이스 모델에 종속
• 식별자를 정의하고 관계, 속성 등을 모두 표현
• 정규화를 통해 재사용성을 높임
• 정규화. 재사용성. 신뢰성.

3. 물리적 데이터 모델링Physical Data Modeling

• 성능, 보안, 가용성등을 고려하여 데이터베이스를 실제 구축(테이블, 인덱스, 함수 등을 생성)
• 성능. 보안. 가용성. DB 구축.

프로젝트 생명주기Life Cycle에서의 데이터 모델링

Waterfall 기반에서는 데이터 모델링의 위치가 분석 - 설계 단계로 명확하게 구분된다. 정보공학이나 구조적 방법론에서는 보통 분석 단계에서 논리적 데이터 모델링(업무중심)을 수행하고 설계 단계에서 물리적 데이터 모델링(하드웨어나 성능을 고려)을 수행한다. 

나선형 모델(RUP, 마르미 등)에서는 업무 크기에 따라 논리적 데이터 모델, 물리적 데이터 모델이 분석 - 설계 단계 양쪽에서 수행되며 분석단계에서의 논리적 데이터 모델링의 비중이 더 큰 형태다.

일반적으로는 계획/분석 단계에서 개념적 데이터 모델링, 분석 단계에서 논리적 데이터 모델링, 설계 단계에서 물리적 데이터 모델링이 수행된다. 하지만 현실 프로젝트에서는 개념적 데이터 모델링이 생략되어 대부분 분석 단계에 개념/논리 데이터 모델링이 수행된다.

데이터축과 어플축으로 구분되어 프로젝트가 진행되면서 각각에 도출한 사항은, 상호 검증을 지속적으로 수행해서 단계별 완성도를 높인다. 단, 객체지향 개념은 데이터와 프로세스를 한번에 바라보며 모델링하므로 데이터 모델링과 프로세스 모델링을 구분하지 않고 일체형으로 진행한다. 가장 대표적인 예시로, 데이터(속성)와 프로세스(Method)가 같이 있는 클래스이다.

데이터독립성

데이터의 독립성이란 특정 스키마를 변경해도 상위 수준의 스키마 정의에 영향을 주지 않는 성질이다.

데이터 독립성을 확보했을 때 얻는 효과는 다음과 같다.

• 데이터복잡도 증가
• 데이터 중복 제거
• 사용자 요구사항 변경에 따른 대응력 향상
• 관리 및 요지보수 비용 절감

3층 스키마3-Level Schema

• 사용자, 설계자, 개발자가 데이터베이스를 보는 관점에 따라 데이터베이스를 기술하고 이 관계를 정리한 ANSI 표준
• 3층 스키마는 데이터베이스의 독립성을 확보하는 방법이다.

3층 스키마의 독립성

독립성	설명
논리적 독립성	저장구조가 변경돼도 응용 프로그램 및 개념 스키마에 영향이 없음
물리적 독립성	데이터베이스 논리적 구조가 변경돼도 응용 프로그램에 변화가 없음

3층 스키마의 구조

1. 외부 스키마

• 사용자 관점, 관련이 있는 데이터 접근
• 관련 데이터베이스의 뷰를 표시한다
• 응용 프로그램이 접근하는 데이터베이스를 정의
• 사용자 개개인의 관점(View 단계)으로 구성된 개인적 DB 스키마
• 접근하는 특성(Transaction 등)에 따라 구성

2. 개념 스키마

• 설계자 관점, 사용자 관점을 통합한 조직 전체 관점의 데이터베이스 구조
• 전체 데이터베이스 내의 규칙과 구조를 표현
• 통합 데이터베이스 구조
• 개념 단계 하나의 개념적 스키마로 구성되어 있다
• 필요한 데이터를 통합한 조직 전체의 DB를 기술하는 것으로 DB에 저장되는 데이터와 그들 간의 관계를 표현하는 스키마

3. 내부스키마

• 개발자 관점, 데이터베이스의 물리적 저장 구조
• 데이터 저장 구조, 레코드 구조, 필드 정의, 인덱스 등을 의미
• 내부 단계, 내부 스키마로 구성
• DB가 물리적으로 저장된 형식으로, 물리적 장치에서 데이터가 실제로 저장되는 방법을 표현하는 스키마

사상Mapping

이렇게 각 계층구조를 유기적으로 연결해주는 매핑을 통해 3층 스키마는 데이터 독립성을 가진다. 특정 스키마가 바뀌더라도 매핑을 다시 해서 다른 계층 스키마 내용은 변하지 않아도 된다.

1. 논리적 사상 = 외부적/개념적 사상 = 논리적 데이터 독립성

• 논리 스키마가 변하더라도 상위 단계에 존재하는 외부스키마(서브스키마)가 영향을 받지 않는 성질
• 외부적 뷰와 개념적 뷰의 상호 관련성을 정의
• 사용자가 접근하는 형식에 따라 다른 타입의 필드를 가질 수 있고 개념적 뷰의 필드 타입은 변화가 없는 것과 같다
• "외부 인터페이스를 위한 스키마 구조는 전체가 통합된 개념적 스키마와 연결된다"

2. 물리적 사상 = 개념적/내부적 사상 = 물리적 데이터 독립성

• 데이터베이스 관리 시스템의 성능 향상을 위해 시스템을 바꾸거나 물리스키마 구조를 변경하는 경우에 물리 스키마가 바뀌더라도 개념스키마나 사용자가 이용하는 응용 프로그램은 영향을 받지 않는다
• 개념적 뷰와 저장된 DB의 상호 관련성을 정의
• 만약 저장된 DB 구조가 바뀌면 개념적 스키마는 그대로 남아있게 개념적/내부적 사상이 바뀌어야 함
• "통합된 개념적 스키마 구조와 물리적 테이블 스페이스(물리 저장된 구조)가 연결되는 구조"

데이터독립성 보장을 위해서는 매핑하는 스크립트(DDL)를 DBA가 필요할 때마다 변경해주어야 하는데 각 단계(외부/내부/개념적 스키마)의 독립성을 보장하기 위해 변경사항이 생겼을 때 DBA가 적절한 작업을 해주기 때문에 독립성이 보장된다고도 할 수 있다.

데이터 모델링의 세 가지 요소

1. 업무가 관여하는 어떤 것 Things
2. 어떤 것이 가지는 성격 Attributes
3. 업무가 관여하는 어떤 것 간의 관계 Relationships

위 세 가지는 데이터 모델링을 완성하는 핵심 개념으로, 결국 엔터티, 속성 관계로 인식된다. 자연계에 존재하는 모든 유형의 정보들을 위 세 가지 관점의 접근 방법을 통해 모델링한다.

단수와 집합(복수)의 명명

데이터 모델링에서는 위 세 가지 개념의 단수/복수를 분명하게 구분한다.

데이터 모델링의 이해관계자

1. 이해관계자의 데이터 모델링 중요성 인식

데이터 모델링이라는 과정이 단지 DB 설계의 측면보다 업무를 이해/분석하여 표현하는 것이 중요하고, 표현된 내용을 바탕으로 프로젝트 관련자와 의사소통을 하기도 하며 프로그램이나 다른 표기법과 비교/검증하는 일을 수행하는 등 많은 시간을 업무를 분석하고 설계하는데 할애하기 때문에, 보통 데이터 모델링은 전문 DBA가 아닌 업무영역별 개발팀에서 진행하게 된다. 

2. 데이터 모델링의 이해관계자

그럼 데이터 모델링을 연구하고 학습하는 사람은 누구일까? 정보시스템을 구축하는 모든 사람(코딩 전문가 포함)은 데이터 모델링을 전문적으로 할 수 있거나 적어도 완성된 모델을 정확하게 해석해야 한다. 즉 프로젝트에 참여한 모든 IT 기술자들은 데이터 모델링에 대해 정확하게 알아야 한다. 또 IT 비종사자, 비전공자도 해당 업무에서 정보화를 추진하는 위치에 있다면 데이터 모델링에 대한 개념 및 세부사항에 대해 알아야 한다. 서로가 프로젝트 중 원활하게 의사소통하며 오해로 인해 잘못된 시스템을 구축하는 리스크를 줄여야 하기 때문이다.

ERD 표기법 작업순서

데이터 모델에 대한 표기법으로 1976년 피터첸(Peter Chen)이 Entity-relationship model(E-R Model)이라는 표기법을 만들었다. 엔터티는 사각형으로, 관계를 마름모로, 속성은 타원으로 표기한다.

관계 표현에 있어서 관계의 명칭은 매우 중요하며, 가장 중요한 엔터티를 왼쪽 상단에 배치하고 이를 중심으로 추가 엔터티들을 배치한다.

좋은 데이터 모델의 요소

1. 완전성Completeness: 업무에서 필요로 하는 모든 데이터가 데이터 모델에 정의되어 있어야 한다.
2. 중복배제Non-Redundancy: 한 DB 내에 동일한 사실은 한 번만 기록해야 한다.
3. 업무규칙Business Rules: 데이터 모델링 과정에서 도출되는 업무규칙을 데이터 모델에 표현하고 이를 다루는 모든 사용자가 공유할 수 있도록 한다.
4. 데이터 재사용Data Reusability: 데이터 중복/일관성 문제를 위해 데이터가 각 어플리케이션에 대해 독립적으로 설계되며 이를 통합적으로 다루는 모델이어야 한다.
5. 의사소통Communication: 데이터 모델은 업무를 분석하고 설계하여 나오는 최종 산출물이다. 표현된 정보를 해당 환경에서 운용, 관리하는 많은 관련자들이 정의한 동일 의미로 표현하고, 받아들여 진정한 의사소통의 도구로 사용할 수 있게 한다.
6. 통합성Integration: 동일 데이터는 전체 조직에서 한 번만 정의되고 다른 영역에서 이를 참조, 활용하는 것이다. 한 번만 정의하기 위해서는 공유 데이터의 구조를 여러 영역에서 공동으로 사용하기 용이하게 해야 한다.