데이터 모델링은 데이터 포인트 간의 연결 관계 및 구조를 알리기 위해 정보 시스템 전체나 그 일부를 시각적으로 표현하는 프로세스입니다. 시스템 내에서 사용되고 저장되는 데이터의 유형, 이 데이터 유형 간의 관계, 데이터를 그룹화하고 조직화하는 방식, 그 형식과 특성을 나타내는 데 그 목적이 있습니다.

데이터 모델은 비즈니스 요구 사항을 중심으로 빌드됩니다. 초기에 비즈니스 이해 관계자의 피드백을 바탕으로 규칙과 요구 사항을 정의합니다. 따라서 신규 시스템의 설계에 적용하거나 기존 시스템의 새 버전에 변경하여 적용할 수 있습니다.

데이터는 다양한 추상화 수준에서 모델링할 수 있습니다. 이 프로세스는 이해 관계자 및 최종 사용자로부터 비즈니스 요구 사항에 관한 정보를 수집하면서 시작합니다. 그런 다음 이 비즈니스 규칙을 데이터 구조로 변환하면서 구체적인 데이터베이스 설계를 완성합니다. 데이터 모델은 도로 지도, 건축가의 청사진, 또는 설계 대상을 더 정확히 이해하는 데 도움이 될 기타 공식적인 다이어그램에 비유할 수 있습니다.

데이터 모델링에서는 표준화된 스키마 및 공식적인 기법을 사용합니다. 그러면 전사적 범위에서 또는 그 이외의 영역에서도 공통적이고 일관성 있는, 그리고 예측 가능한 방식으로 데이터 리소스를 정의하고 관리할 수 있게 됩니다.

이상적으로, 데이터 모델은 비즈니스 요구 사항의 변화에 따라 진화하는 살아 있는 문서라 할 수 있습니다. 이는 비즈니스 프로세스를 지원하고 IT 아키텍처 및 전략을 계획하는 데 중요한 역할을 합니다. 데이터 모델은 벤더, 파트너, 또는 동종 업계 기업과도 공유할 수 있습니다.

데이터베이스 및 정보 시스템 설계는 여느 설계 프로세스와 마찬가지로, 고도의 추상화 수준에서 시작했다가 점점 더 구체화되고 특화됩니다. 일반적으로 데이터 모델은 3가지 범주로 나눌 수 있는데, 이는 추상화 수준에 따라 달라집니다. 이 프로세스는 개념 모델에서 시작하고 논리적 모델로 진화하며 물리적 모델로 마무리됩니다. 데이터 모델의 각 유형에 관해서는 아래에서 더 자세히 살펴보겠습니다.

• 개념적 데이터 모델. 도메인 모델이라고도 하며, 시스템에 무엇이 포함되고 시스템이 어떻게 구성되며 어떤 비즈니스 규칙이 사용될 것인지를 거시적으로 보여줍니다. 개념적 모델은 대개 초기 프로젝트 요구 사항을 수집하는 과정에서 생성됩니다. 일반적으로, 이 모델에는 엔터티 클래스(비즈니스에 중요하고 데이터 모델에 반영되어야 할 요소들의 유형 정의), 이러한 엔터티 클래스의 특징 및 제약 조건, 이들 간 관계, 그리고 관련 보안 및 데이터 무결성 요구 사항이 포함됩니다. 일반적으로 모든 표기법은 간단합니다.

   

• 논리적 데이터 모델. 덜 추상적이며, 해당 도메인의 개념 및 관계에 관한 더 구체적인 정보를 제공합니다. 여러 공식적인 데이터 모델링 표기 체계 중 하나를 따릅니다. 이들은 데이터 유형과 길이 등의 데이터 속성을 표시하고 엔터티 간의 관계를 보여줍니다. 논리적 데이터 모델에서는 기술적 시스템 요구 사항을 지정하지 않습니다. 애자일 또는 DevOps  프랙티스에서는 이 단계를 생략할 때가 많습니다. 논리적 데이터 모델은 고도의 절차적 구현 환경에서, 또는 근본적으로 데이터 지향적인 프로젝트에서 유용할 수 있습니다. 데이터 웨어하우스 설계 또는 보고 시스템 개발을 예로 들 수 있습니다.

   

• 물리적 데이터 모델. 데이터베이스 내에서 데이터가 물리적으로 저장되는 방식에 관한 스키마를 제공합니다.  따라서 추상화 수준이 가장 낮습니다.  관계형 데이터베이스로 구현 가능한 최종 버전의 설계를 제공합니다. 여기에는 엔티티 간의 관계를 나타내는 연관 테이블, 그리고 이러한 관계를 유지하는 데 쓰이는 기본 키와 외래 키가 포함됩니다. 물리적 데이터 모델은 데이터베이스 관리 시스템(DBMS)별 속성, 이를테면 성능 튜닝을 포함할 수 있습니다.

원칙적으로 데이터 모델링에는 이해 관계자가 참여하여 데이터 처리 및 저장을 매우 상세히 평가해야 합니다. 데이터 모델링 기법에서는 저마다 다른 규칙을 통해 어떤 기호를 사용하여 데이터를 나타낼지, 어떤 식으로 모델을 배치할지, 어떻게 비즈니스 요구 사항을 전달할지를 결정합니다. 모든 접근 방식에서는 공식화된 워크플로우가 있습니다. 이는 반복적으로 수행할 일련의 태스크로 구성됩니다. 일반적으로 이 워크플로우는 다음과 같습니다.

1. 엔터티 식별 데이터 모델링 프로세스는 모델링할 데이터 세트에 의해 표현되는 사물, 이벤트, 개념을 식별하는 것으로 시작합니다. 각 엔티티는 결합적이며, 논리적으로 다른 엔티티와 구별됩니다.
2. 각 엔티티의 주요 속성 식별 각 엔티티 유형은 특성(attributes)이라고 하는 고유한 속성을 하나 이상 갖고 있기 때문에 다른 엔티티 유형과 구별할 수 있습니다. 예를 들어, "고객"이라는 엔티티는 이름, 성, 전화 번호, 호칭과 같은 특성을 가질 수 있습니다. "주소"라는 엔티티는 도로명과 번지, 시, 도. 국가, 우편 번호 등을 포함할 수 있습니다.
3. 엔티티 간의 관계 식별 데이터 모델의 1차 초안에서는 각 엔티티와 다른 엔티티 간 관계의 속성을 지정합니다. 위의 예에서 각 고객은 어떤 주소에 "거주하고" 있습니다. 이 모델을 확장하여 "주문"이라는 엔티티를 포함할 경우, 각 주문은 주소로 배송되고 청구될 것입니다. 이러한 관계는 대개 통합 모델링 언어(UML)를 통해 문서화됩니다.
4. 엔티티에 완전히 특성 매핑 이제 모델은 비즈니스에서 그 데이터를 사용하는 방법을 반영하게 됩니다. 몇 가지 공식적인 데이터 모델링 패턴이 널리 사용되고 있습니다. 객체 지향 개발자는 대개 분석 패턴이나 설계 패턴을 적용합니다. 하지만 다른 비즈니스 도메인의 이해 관계자가 다른 패턴을 사용할 수도 있습니다.
5. 필요에 따라 키 지정, 중복성을 줄일 필요성과 성능 요구 사항을 균형적으로 조정하는 정규화 수준 결정 정규화란 데이터 모델(및 데이터 모델에서 나타내는 데이터베이스)을 구조화하는 기법입니다. 키라고 부르는 숫자 식별자가 데이터 그룹에 지정되므로, 데이터를 반복하지 않고도 그 관계를 나타낼 수 있습니다. 예를 들어 각 고객에게 키가 지정된 경우, 이 키를 고객의 주소 및 주문 이력과 연결할 수 있습니다. 고객 이름 테이블에서 이 정보를 반복하지 않아도 됩니다. 정규화를 통해 데이터베이스에 필요한 저장 공간이 줄어들지만, 그로 인해 쿼리 성능이 저하될 수 있습니다.
6. 데이터 모델 완결 및 유효성 검사 데이터 모델링은 반복적인 프로세스입니다. 즉, 비즈니스 요구 사항의 변화에 따라 반복하고 개선해야 합니다.

데이터 모델링은 데이터베이스 관리 시스템과 함께 진화했습니다. 비즈니스의 데이터 스토리지 요구 사항이 늘면서 모델 유형도 더욱 복잡해졌습니다. 몇 가지 모델 유형을 소개합니다.

• 계층적 데이터 모델 트리와 비슷한 형식으로 일대다 관계를 나타냅니다. 이 모델 유형에서는 각 레코드에 하나의 루트 또는 부모가 있으며, 이는 하나 이상의 자식 테이블에 매핑됩니다. 1966년에 등장하여 특히 금융권에서 빠른 속도로 널리 보급된 IBM Information Management System(IMS)에서 이 모델을 구현했습니다. 이 방식은 최근에 개발된 데이터베이스 모델에 비해 효율성이 떨어지는 편이지만, 여전히 XML(Extensible Markup Language) 시스템 및 지리 정보 시스템(GIS)에 쓰이고 있습니다.
• 관계형 데이터 모델 IBM 연구원인 E.F. Codd가 1970년에 처음으로 제안했습니다. 오늘날에도 다양한 관계형 데이터베이스에 구현되어 있는데, 주로 엔터프라이즈 컴퓨팅에 쓰입니다. 관계형 데이터 모델에서는 사용되는 데이터 스토리지의 물리적 속성을 상세히 알 필요가 없습니다. 그 안에서는 테이블을 사용하여 데이터 세그먼트를 명시적으로 조인하면서 데이터베이스 복잡성을 줄입니다.

관계형 데이터베이스에서는 대개 데이터 관리를 위해 SQL(structured query language)을 사용합니다. 이 데이터베이스는 데이터 무결성을 유지하고 중복성을 최소화하는 데 효과적입니다. POS(point-of-sale) 시스템 및 그 밖의 트랜잭션 처리 유형에 많이 쓰입니다.

• 엔티티 관계(ER) 데이터 모델 공식적인 다이어그램을 사용하여 데이터베이스의 엔티티 간 관계를 나타냅니다. 데이터 아키텍트가 데이터베이스 설계의 목적을 전달하는 비주얼 맵을 생성하는 데 쓰이는 몇 가지 ER 모델링 툴이 있습니다.
• 객체 지향 데이터 모델 객체 지향 프로그래밍과 함께 주목받았고 1990년대 중반에 널리 보급되었습니다. 여기서 "객체"란 현실의 엔티티를 추상화한 것입니다. 객체는 클래스 계층 구조에서 그룹화되며, 연관된 특징이 있습니다. 객체 지향 데이터베이스에서는 테이블을 포함할 수 있으나, 더 복잡한 데이터 관계도 지원할 수 있습니다. 이러한 접근 방식은 멀티미디어 및 하이퍼텍스트 데이터베이스를 비롯한 여러 활용 사례에 쓰입니다.
• 차원 데이터 모델 Ralph Kimball이 개발한 이 모델은 데이터 웨어하우스에서 분석을 위해 데이터 검색 속도를 최적화하도록 설계되었습니다.  관계형 모델과 ER 모델은 스토리지 효율성에 중점을 두는 반면, 차원 모델은 보고 및 검색을 위해 더 쉽게 정보를 찾을 수 있도록 중복성을 늘립니다. 이 모델링은 일반적으로 OLAP 시스템에서 쓰입니다.

특히 많이 쓰이는 2가지 차원 데이터 모델 중 하나가 스타(star) 스키마입니다. 여기서는 데이터를 사실(측정 가능한 항목)과 차원(참조 정보)으로 구성합니다. 각 사실은 연관된 차원에 둘러싸여 별 모양의 패턴으로 나타납니다. 다른 하나는 스노우플레이크(snowflake) 스키마입니다. 스타 스키마와 비슷하지만, 추가적인 연관 차원 계층이 있어 분기 패턴이 더 복잡해집니다.

데이터 모델링 덕분에 개발자, 데이터 아키텍트, 비즈니스 분석가, 기타 이해 관계자가 데이터베이스나 데이터 웨어하우스의 데이터 간 관계를 더 쉽게 조회하고 이해할 수 있습니다. 그와 더불어 다음과 같은 이점을 제공합니다.

• 소프트웨어 및 데이터베이스 개발의 오류 감소
• 전사적 범위에서 문서화 및 시스템 설계의 일관성 향상
• 애플리케이션 및 데이터베이스 성능 향상
• 전사적 범위에서 수월하게 데이터 매핑
• 개발자와 비즈니스 인텔리전스 팀간의 소통 향상
• 개념 단계, 논리적 단계, 물리적 단계에서 더 쉽고 빠르게 데이터베이스 설계 프로세스 진행

데이터 모델링 툴

오늘날 수많은 상용 및 오픈 소스 CASE(computer-aided software engineering) 솔루션이 광범위하게 사용되고 있습니다. 여기에는 다양한 데이터 모델링, 다이어그램, 시각화 툴이 포함됩니다. 그중 몇 가지 예를 들면 다음과 같습니다.

• erwin Data Modeler IDEF1X(Integration DEFinition for information modeling) 데이터 모델링 언어 기반의 데이터 모델링 툴입니다.
• Enterprise Architect 현재는 차원 방식과 같은 다른 표기 방법론을 지원합니다. Enterprise Architect 비주얼 모델링 및 설계 툴로서 엔터프라이즈 정보 시스템 및 아키텍처뿐만 아니라 소프트웨어 애플리케이션 및 데이터베이스의 모델링도 지원합니다. 객체 지향 언어 및 표준을 기반으로 합니다.
• ER/Studio 현재 가장 많이 쓰이는 몇 가지 데이터베이스 관리 시스템과의 호환성을 제공하는 데이터베이스 설계 소프트웨어입니다. 관계형 데이터 모델링 및 차원 데이터 모델링을 모두 지원합니다.
• 무료 데이터 모델링 툴 Open ModelSphere와 같은 오픈 소스 솔루션도 여기에 포함됩니다.