데이터 모델링

[420px|섬네일|데이터 모델링 프로세스. 이 그림은 오늘날 데이터 모델이 개발되고 사용되는 방식을 보여준다. [개체-관계 모델|개념 데이터 모델은 개발 중인 애플리케이션의 데이터 요구사항을 기반으로 개발되며, 아마도 활동 모델의 맥락에서 이루어질 수 있다. 데이터 모델은 일반적으로 엔티티 유형, 속성, 관계, 무결성 규칙 및 해당 객체의 정의로 구성된다. 이는 인터페이스 또는 데이터베이스 설계의 시작점으로 사용된다.]]

소프트웨어 공학에서 **데이터 모델링**(data modeling)은 특정 정형 기법을 적용하여 정보 시스템을 위한 데이터 모델을 생성하는 프로세스다. 이는 더 광범위한 모델 기반 개발(MDE) 개념의 일부로 적용될 수 있다.

## 개요
데이터 모델링은 조직 내 해당 정보 시스템의 범위 내에서 비즈니스 프로세스를 지원하는 데 필요한 데이터 요구사항을 정의하고 분석하는 데 사용되는 소프트웨어 개발 프로세스다. 따라서 데이터 모델링 프로세스에는 전문 데이터 모델러가 비즈니스 이해관계자 및 정보 시스템의 잠재적 사용자와 긴밀히 협력하는 과정이 포함된다.

요구사항에서 정보 시스템에 사용될 실제 데이터베이스로 진행되는 동안 세 가지 유형의 데이터 모델이 생성된다. 데이터 요구사항은 처음에 개념 데이터 모델로 기록되는데, 이는 본질적으로 데이터에 대한 기술 독립적인 사양 세트이며 비즈니스 이해관계자와 초기 요구사항을 논의하는 데 사용된다. 그 후 개념 모델은 데이터베이스에서 구현될 수 있는 데이터 구조를 문서화하는 논리 데이터 모델로 변환된다. 하나의 개념 데이터 모델을 구현하는 데 여러 개의 논리 데이터 모델이 필요할 수 있다. 데이터 모델링의 마지막 단계는 논리 데이터 모델을 데이터를 테이블로 구성하고 액세스, 성능 및 저장 세부 사항을 고려하는 물리 데이터 모델로 변환하는 것이다. 데이터 모델링은 데이터 요소뿐만 아니라 그 구조와 요소 간의 관계도 정의한다.

데이터 모델링 기법과 방법론은 데이터를 자원으로서 관리하기 위해 표준적이고 일관되며 예측 가능한 방식으로 데이터를 모델링하는 데 사용된다. 데이터 모델링 표준의 사용은 다음과 같이 조직 내에서 데이터를 정의하고 분석하는 표준 수단이 필요한 모든 프로젝트에 강력히 권장된다.

* 비즈니스 분석가, 프로그래머, 테스터, 매뉴얼 작성자, IT 패키지 선택자, 엔지니어, 관리자, 관련 조직 및 고객이 조직의 개념과 이들이 서로 어떻게 관련되어 있는지를 포괄하는 합의된 준정형 모델을 이해하고 사용할 수 있도록 지원한다.
* 데이터를 자원으로서 관리한다.
* 정보 시스템을 통합한다.
* 데이터베이스/데이터 웨어하우스(데이터 저장소)를 설계한다.

데이터 모델링은 다양한 유형의 프로젝트와 프로젝트의 여러 단계에서 수행될 수 있다. 데이터 모델은 점진적이다. 비즈니스나 애플리케이션을 위한 최종 데이터 모델이라는 것은 존재하지 않는다. 대신 데이터 모델은 변화하는 비즈니스에 대응하여 변화하는 살아있는 문서로 간주되어야 한다. 데이터 모델은 이상적으로 저장소에 저장되어 시간이 지남에 따라 검색, 확장 및 편집될 수 있어야 한다. 제프리 L. 위튼 등(2004)은 데이터 모델링의 두 가지 유형을 정의했다.
* 전략적 데이터 모델링: 이는 정보 시스템에 대한 전반적인 비전과 아키텍처를 정의하는 정보 시스템 전략 수립의 일부다. 정보기술 공학은 이러한 접근 방식을 수용하는 방법론이다.
* 시스템 분석 중의 데이터 모델링: 시스템 분석에서 논리 데이터 모델은 새로운 데이터베이스 개발의 일부로 생성된다.

데이터 모델링은 특정 데이터베이스에 대한 비즈니스 요구사항을 상세화하는 기법으로도 사용된다. 데이터 모델이 결국 데이터베이스에서 구현되기 때문에 때로는 데이터베이스 모델링이라고도 불린다.

## 주제

### 데이터 모델

섬네일|320px|데이터 모델이 이점을 제공하는 방식.
데이터 모델은 구체적인 정의와 형식을 제공함으로써 정보 시스템 내에서 사용될 데이터를 위한 프레임워크를 제공한다. 데이터 모델이 시스템 전반에 걸쳐 일관되게 사용되면 데이터의 호환성을 달성할 수 있다. 데이터를 저장하고 액세스하는 데 동일한 데이터 구조가 사용되면 서로 다른 애플리케이션이 데이터를 원활하게 공유할 수 있다. 그 결과는 다이어그램에 표시되어 있다. 그러나 시스템과 인터페이스는 구축, 운영 및 유지 관리하는 데 비용이 많이 드는 경우가 많다. 또한 비즈니스를 지원하기보다는 제약할 수도 있다. 이는 시스템과 인터페이스에 구현된 데이터 모델의 품질이 낮을 때 발생할 수 있다.

데이터 모델에서 발견되는 몇 가지 일반적인 문제는 다음과 같다.
* 특정 장소에서 업무가 수행되는 방식에 특화된 비즈니스 규칙이 데이터 모델의 구조에 고정되어 있는 경우가 많다. 이는 비즈니스 방식의 작은 변화가 컴퓨터 시스템과 인터페이스의 큰 변화로 이어진다는 것을 의미한다. 따라서 비즈니스 규칙은 복잡한 의존성을 초래하지 않는 유연한 방식으로 구현되어야 하며, 데이터 모델은 비즈니스의 변화를 상대적으로 빠르고 효율적으로 구현할 수 있을 만큼 충분히 유연해야 한다.
* 엔티티 유형이 식별되지 않거나 잘못 식별되는 경우가 많다. 이는 데이터, 데이터 구조 및 기능의 중복을 초래할 수 있으며, 개발 및 유지 관리 비용의 중복을 수반한다. 따라서 오해와 중복을 최소화하기 위해 데이터 정의는 가능한 한 명시적이고 이해하기 쉽게 만들어져야 한다.
* 서로 다른 시스템에 대한 데이터 모델이 임의로 다르다. 그 결과 데이터를 공유하는 시스템 간에 복잡한 인터페이스가 필요하게 된다. 이러한 인터페이스는 현재 시스템 비용의 25~70%를 차지할 수 있다. 데이터 모델은 서로 다른 시스템 내의 인터페이스 없이는 그 자체로 사용 가능하지 않으므로, 데이터 모델을 설계할 때 필요한 인터페이스를 본질적으로 고려해야 한다.
* 데이터의 구조와 의미가 표준화되지 않았기 때문에 고객 및 공급업체와 데이터를 전자적으로 공유할 수 없다. 구현된 데이터 모델에서 최적의 가치를 얻으려면 데이터 모델이 비즈니스 요구를 충족하고 일관성을 유지하도록 보장하는 표준을 정의하는 것이 매우 중요하다.

### 개념, 논리 및 물리 스키마
섬네일|320px|ANSI/SPARC 3단계 아키텍처. 이는 데이터 모델이 외부 모델(또는 뷰), 개념 모델 또는 물리 모델일 수 있음을 보여준다. 이것이 데이터 모델을 보는 유일한 방법은 아니지만, 특히 모델을 비교할 때 유용한 방법이다.

1975년 ANSI는 세 가지 종류의 데이터 모델 인스턴스를 설명했다.

* 개념 스키마: 도메인의 의미론(모델의 범위)을 설명한다. 예를 들어, 조직이나 산업의 관심 영역에 대한 모델일 수 있다. 이는 도메인에서 중요한 의미를 갖는 사물의 종류를 나타내는 엔티티 클래스와 엔티티 클래스 쌍 간의 연관성에 대한 관계 주정으로 구성된다. 개념 스키마는 모델을 사용하여 표현할 수 있는 사실이나 명제의 종류를 지정한다. 그런 의미에서 이는 모델의 범위에 의해 제한된 범위를 갖는 인공 "언어"에서 허용되는 표현을 정의한다. 간단히 설명하면 개념 스키마는 데이터 요구사항을 구성하는 첫 번째 단계다.
* 논리 스키마: 정보 도메인의 구조를 설명한다. 이는 예를 들어 테이블, 컬럼, 객체 지향 클래스 및 XML 태그에 대한 설명으로 구성된다. 논리 스키마와 개념 스키마는 때때로 하나로 구현되기도 한다.
* 물리 스키마: 데이터를 저장하는 데 사용되는 물리적 수단을 설명한다. 이는 파티션, CPU, 테이블스페이스 등과 관련이 있다.

ANSI에 따르면 이 접근 방식을 통해 세 가지 관점은 서로 상대적으로 독립적일 수 있다. 저장 기술은 논리 또는 개념 스키마에 영향을 주지 않고 변경될 수 있다. 테이블/컬럼 구조는 (반드시) 개념 스키마에 영향을 주지 않고 변경될 수 있다. 물론 각 경우에 구조는 동일한 데이터 모델의 모든 스키마에서 일관성을 유지해야 한다.

### 데이터 모델링 프로세스

[섬네일|360px|[비즈니스 프로세스 통합 맥락에서의 데이터 모델링.]]

비즈니스 프로세스 통합의 맥락에서(그림 참조) 데이터 모델링은 비즈니스 프로세스 모델링을 보완하며 최종적으로 데이터베이스 생성으로 이어진다.

데이터베이스를 설계하는 프로세스에는 앞서 설명한 세 가지 유형의 스키마(개념, 논리, 물리)를 생성하는 과정이 포함된다. 이러한 스키마에 문서화된 데이터베이스 설계는 데이터 정의 언어를 통해 변환되어 데이터베이스를 생성하는 데 사용될 수 있다. 완전히 속성이 부여된 데이터 모델에는 모델 내의 모든 엔티티에 대한 상세한 속성(설명)이 포함된다. "데이터베이스 설계"라는 용어는 전체 데이터베이스 시스템 설계의 여러 부분을 설명할 수 있다. 주로, 그리고 가장 정확하게는 데이터를 저장하는 데 사용되는 기본 데이터 구조의 논리적 설계로 생각할 수 있다. 관계형 모델에서 이는 테이블과 뷰다. 객체 지향 데이터베이스에서 엔티티와 관계는 객체 클래스와 명명된 관계에 직접 매핑된다. 그러나 "데이터베이스 설계"라는 용어는 기본 데이터 구조뿐만 아니라 데이터베이스 관리 시스템(DBMS) 내에서 전체 데이터베이스 애플리케이션의 일부로 사용되는 폼과 쿼리를 설계하는 전체 프로세스에도 적용될 수 있다.

이 과정에서 시스템 인터페이스는 현재 시스템의 개발 및 지원 비용의 25%에서 70%를 차지한다. 이 비용의 주된 이유는 이러한 시스템들이 공통 데이터 모델을 공유하지 않기 때문이다. 데이터 모델이 시스템별로 개발되면 겹치는 영역에서 동일한 분석이 반복될 뿐만 아니라, 시스템 간의 인터페이스를 만들기 위해 추가적인 분석이 수행되어야 한다. 조직 내의 대부분의 시스템은 특정 목적을 위해 재개발된 동일한 기본 데이터를 포함하고 있다. 따라서 효율적으로 설계된 기본 데이터 모델은 조직 내 다른 시스템의 목적에 맞게 최소한의 수정을 거침으로써 재작업을 최소화할 수 있다.

### 모델링 방법론

데이터 모델은 관심 있는 정보 영역을 나타낸다. 데이터 모델을 만드는 방법은 많지만, 렌 실버스톤(1997)에 따르면 상향식(top-down)과 하향식(bottom-up)이라는 두 가지 모델링 방법론이 두드러진다.
* 하향식 모델 또는 뷰 통합 모델은 종종 소프트웨어 재공학 노력의 결과다. 이들은 일반적으로 기존 데이터 구조 폼, 애플리케이션 화면의 필드 또는 보고서에서 시작한다. 이러한 모델은 대개 물리적이고 애플리케이션에 특화되어 있으며, 엔터프라이즈 아키텍처 관점에서는 불완전하다. 특히 조직의 다른 부분을 참조하지 않고 구축된 경우 데이터 공유를 촉진하지 못할 수 있다.
* 반면, 상향식 논리 데이터 모델은 주제 영역을 잘 아는 사람들로부터 정보를 얻어 추상적인 방식으로 생성된다. 시스템이 논리 모델의 모든 엔티티를 구현하지는 않을 수 있지만, 이 모델은 참조 지점이나 템플릿 역할을 한다.
때때로 모델은 애플리케이션의 데이터 요구사항과 구조를 고려하고 주제 영역 모델을 일관되게 참조하는 두 방법의 혼합으로 생성되기도 한다. 많은 환경에서 논리 데이터 모델과 물리 데이터 모델의 구분은 모호하다. 또한 일부 컴퓨터 지원 소프트웨어 공학(CASE) 도구는 논리 모델과 물리 데이터 모델을 구분하지 않는다.

### 개체-관계 다이어그램

[섬네일|550px|right|IDEF1X 자체를 모델링하는 데 사용된 [IDEF1X 개체-관계 다이어그램의 예. 뷰의 이름은 mm이다. 도메인 계층 구조와 제약 조건도 제공된다. 제약 조건은 메타 모델의 정형 이론 내에서 문장으로 표현된다.]]
데이터 모델링을 위한 여러 표기법이 있다. 실제 모델은 데이터에 설명된 엔티티와 관계의 측면에서 데이터를 묘사하기 때문에 자주 "개체-관계 모델"이라고 불린다. 개체-관계 모델(ERM)은 구조화된 데이터의 추상적인 개념적 표현이다. 개체-관계 모델링은 관계형 스키마 데이터베이스 모델링 방법으로, 소프트웨어 공학에서 시스템(종종 관계형 데이터베이스)의 개념 데이터 모델(또는 시맨틱 데이터 모델)과 그 요구사항을 상향식 방식으로 생성하는 데 사용된다.

이러한 모델은 요구사항 분석 중에 정보 시스템 설계의 첫 단계에서 정보 요구사항이나 데이터베이스에 저장될 정보의 유형을 설명하는 데 사용된다. 데이터 모델링 기법은 특정 논의 영역(관심 영역)에 대한 온톨로지(즉, 사용되는 용어 및 그 관계의 개요 및 분류)를 설명하는 데 사용될 수 있다.

데이터 모델 설계를 위해 여러 기법이 개발되었다. 이러한 방법론이 데이터 모델러의 작업을 안내하지만, 동일한 방법론을 사용하는 두 사람이 매우 다른 결과를 내놓는 경우가 많다. 가장 주목할만한 것은 다음과 같다.

* 바흐만 다이어그램
* 바커 표기법
* 첸 표기법
* 데이터 볼트 모델링
* EBNF
* IDEF1X
* 객체 관계 매핑
* 객체-역할 모델링 및 완전 통신 지향 정보 모델링
* 관계형 모델
* 관계형 모델/타즈매니아

### 일반 데이터 모델링

섬네일|320px|일반 데이터 모델의 예.
일반 데이터 모델은 전통적인 데이터 모델의 일반화다. 이들은 표준화된 일반 관계 유형과 그러한 관계 유형에 의해 연관될 수 있는 사물의 종류를 정의한다.
일반 데이터 모델의 정의는 자연어의 정의와 유사하다. 예를 들어, 일반 데이터 모델은 개별 사물과 사물의 종류(클래스) 사이의 이항 관계인 '분류 관계', 그리고 두 사물 사이의 이항 관계로서 하나는 부분의 역할, 다른 하나는 전체의 역할을 하며 관계된 사물의 종류에 관계없는 '부분-전체 관계'와 같은 관계 유형을 정의할 수 있다.

확장 가능한 클래스 목록이 주어지면, 이를 통해 모든 개별 사물을 분류하고 개별 객체에 대한 부분-전체 관계를 지정할 수 있다. 확장 가능한 관계 유형 목록을 표준화함으로써 일반 데이터 모델은 무제한의 사실을 표현할 수 있게 하며 자연어의 능력에 근접하게 된다. 반면, 전통적인 데이터 모델은 고정되고 제한된 도메인 범위를 갖는데, 이는 그러한 모델의 인스턴스화(사용)가 모델에 미리 정의된 종류의 사실만을 표현할 수 있게 하기 때문이다.

### 시맨틱 데이터 모델링

DBMS의 논리적 데이터 구조는 계층형, 네트워크형, 관계형 중 어느 것이든 데이터의 개념적 정의에 대한 요구사항을 완전히 충족할 수 없다. 그 범위가 제한되어 있고 DBMS에서 채택한 구현 전략에 편향되어 있기 때문이다. 이는 성능에 약간의 영향을 줄 수 있지만 일반적으로 생산성을 크게 향상시키는 선택인 시맨틱 데이터 모델을 의도적으로 데이터베이스에 구현하지 않는 한 그러하다.
섬네일|320px|시맨틱 데이터 모델.
따라서 개념적 관점에서 데이터를 정의할 필요성 때문에 시맨틱 데이터 모델링 기법이 개발되었다. 즉, 다른 데이터와의 상호 관계라는 맥락 내에서 데이터의 의미를 정의하는 기법이다. 그림에서 보듯이 자원, 아이디어, 사건 등의 측면에서 실세계는 물리적 데이터 저장소 내의 설명을 통해 상징적으로 정의된다. 시맨틱 데이터 모델은 저장된 기호가 실세계와 어떻게 관련되는지를 정의하는 추상화다. 따라서 모델은 실세계를 진실되게 표현해야 한다.

시맨틱 데이터 모델링의 목적은 "논의 영역"이라 불리는 실세계의 일부분에 대한 구조적 모델을 만드는 것이다. 이를 위해 세 가지 근본적인 구조적 관계가 고려된다.
* 분류/인스턴스화: 일부 구조적 유사성을 가진 객체들을 클래스의 인스턴스로 설명한다.
* 집합/분해: 구성된 객체들은 그 부분들을 결합함으로써 얻어진다.
* 일반화/특수화: 일부 공통 속성을 가진 서로 다른 클래스들을 공통 속성을 가진 더 일반적인 클래스에서 재고려한다.

시맨틱 데이터 모델은 다음과 같은 많은 목적으로 사용될 수 있다.
* 데이터 자원 계획
* 공유 가능한 데이터베이스 구축
* 벤더 소프트웨어 평가
* 기존 데이터베이스 통합

시맨틱 데이터 모델의 전반적인 목표는 관계형 개념과 인공지능 분야에서 알려진 더 강력한 추상화 개념을 통합하여 데이터의 더 많은 의미를 포착하는 것이다. 아이디어는 실세계 상황의 표현을 용이하게 하기 위해 데이터 모델의 필수적인 부분으로서 고수준 모델링 프리미티브를 제공하는 것이다.

## 같이 보기
* 정보 관리
* 아키텍처 패턴
* 데이터 사전
* 빌딩 정보 모델링
* 자크만 프레임워크

## 각주