데이터 모델링 정의

데이터 모델링 탄생 배경

현재의 기업 정보시스템은 데이터베이스 관리 시스템(DBMS, DataBase Management System)을 논외로 하고는 설명할 수 없을 것이다. 하지만 초창기에는 데이터의 저장 매체가 존재하지 않았으며, 기업의 정보시스템은 저장 매체가 없는 단지 배치(Batch) 프로그램 위주의 정보시스템이었다. 이후 파일이나 데이터베이스 관리 시스템과 같은 데이터 저장 매체의 발전과 더불어 온라인(Online) 데이터 처리 정보시스템이 태동하게 되었다. 현재의 관계형 데이터베이스 관리 시스템이 아닌 이러한 시기의 파일이나 데이터베이스 관리 시스템(대표적인 예로 IBM의 계층형 데이터베이스 - HDB, Hierarchical Database)의 데이터 중심 관리 기법이 아니라 배치 프로세스에서 태동한 프로세스 중심의 데이터 관리 기법(구조적 방법론)에 의하여 정보의 고립화라는 현상을 초래하게 되었으며, 많은 기업들은 정보시스템을 유지 관리하는 데 막대한 비용을 투자해야만 했던 것이다. 이에 많은 학자들은 프로세스 중심의 정보시스템 분석, 설계 기법에 문제점이 있다고 생각하게 되었고, 진정 기업 정보시스템의 핵심은 데이터(정보)를 어떻게 하면 중복없이 정확하게 유지 관리할 수 있을까에 대한 보다 근본적인 안을 제시하게 되었다. 이와 함께 기업의 경영 정보시스템에 근본적인 문제가 설계나 개발의 문제보다는 정확한 업무의 파악(데이터에 대한 정확한 분석)이 선결되어야 한다는 결론에 이르렀으며, 이러한 환경에서 보다 현실적(실세계를 좀 더 잘 표현할 수 있는)인 관계형 데이터베이스나 개체 관계 모델링 기법(ERD, Entity Relationship Diagram)을 발전시켜 왔던 것이다.

모델 정의

일상생활에서 많이 접할 수 있는 단어인 모델(Model)은 다양한 현장에서 사용된다. 예술 분야에서 그림, 사진 등과 같은 작품의 대상이 되는 인물이나 대상을 보통 모델이라고 한다. 또한 아파트 분양을 할때 시공 회사에서 제공하는 모델 하우스는 분양을 원하는 사람들에게 아직 아파트 자체가 현존하지는 않지만 어떤 모습과 환경으로 시공자가 아파트를 건설할 것인가에 대한 정보를 제공한다. 이와 같이 모델이란 어떤 대상을 의미하는 포괄적 의미를 가지고 있다고 할 수 있으며, 특히 데이터 모델은 현실 세계에 대해 우리가 관심있어 하는 대상을 데이터베이스화 하기 위한 개념적 도구라고 정의할 수 있다.

아래는 모델의 일반적 의미를 실례로 설명한 내용이다.

1) 물리적 모델

현실에 실재하는 것이 아닌 복잡한 자동차의 모형, 대형 선박의 스케치 또는 설계도, 자동차의 모의 실험용으로 사용되는 바람 터널에서의 자동차 축소 모형 등이 물리적 모델의 실례이다.

2) 개념적 모델

특정 시점에 맞게 기상을 예측하기 위해서 사용되는 수리적 공식이나 원형을 파괴하지 않고 조작·수정·변경시키기 위한 경제 모형 등을 들 수 있다.

모델링 정의

모델링이라는 단어는 실체를 나타내는 일과 모형화라는 의미로 해석된다. ‘실체를 나타낸다’의 의미는 ‘대상을 나타낸다’라는 말로 해석될 수도 있다. 모형화라는 의미는 ‘형태를 만드는 일’ 혹은 ‘대상을 만드는 일’이라고 해석할 수 있다. 따라서 데이터 모델링이란 사용자의 요구사항으로부터 데이터의 실체를 나타내는 일이라고 해석할 수 있을 것이다.

다음은 데이터 모델링의 다양한 관점에 대한 일반적 정의 사례이다.

• Webster 사전
  - 가설적 또는 일정 양식에 맞춘 표현(a hypothetical or stylized representation).
  - 어떤 것에 대한 예비 표현으로, 그로부터 최종 대상이 구축되도록 되어있는 계획으로 기여하는 것
• 복잡한 ‘현실 세계’를 단순화시켜 표현하는 것이다.
• 모델이란 사물 또는 사건에 관한 양상(Aspect)이나 관점(Perspective)을 연관된 사람이나 그룹을 위하여 명확하게 하는 것이다.
• 모델이란 현실 세계의 추상화된 반영이다.

데이터 모델링을 다시 정의하면 기업 업무에 대한 종합적인 이해를 바탕으로 데이터에 존재하는 업무 규칙(Business Rule)에 대하여 참(True) 또는 거짓(False)을 판별할 수 있는 사실(사실명제)을 어떻게(How), 누가(Who) 접근하는지 또한 이에 대한 전산화와는 별개의 관점에서 이를 명확하게 표현하는 추상화 기법이라 할 수 있다. 즉, 현재 업무를 파악하여 문제점을 인식하고 개선 사항을 도출하며 미래에 적합한 설계를 이끌어 내기 위해 인간이 해야 할 대부분의 결정들을 내리는 단계까지를 모두 포함하는 것이 데이터 모델링이다.

데이터 모델이 제공하는 것

• 시스템을 현재 또는 원하는 모습으로 가시화하도록 도와준다.
• 시스템의 구조와 행동을 명세화 할 수 있게 한다.
• 시스템을 구축하는 틀을 제공한다.
• 우리가 결정한 것을 문서화한다.
• 다양한 영역에 집중하기 위해 다른 영역의 세부 사항은 숨기는 다양한 관점을 제공한다.
• 특정 목표에 따라 다양한 상세 수준을 제공한다.

데이터 모델링 필요성

데이터 모델링은 프로세스 모델링과 함께 시스템 개발에 있어서 중요한 두 개의 축을 이룬다. 프로세스 중심의 분석/설계 방법을 통해 설계한 데이터 모델은 업무 프로세스의 변화에 따라 영향을 많이 받기 때문에 상대적으로 업무 변화에 대한 영향을 적게 받으면서 유연한 시스템을 만들기 위해 데이터 중심의 설계에 많은 관심이 모아지고 있다. 개발 방법론에 따라 다소간 차이는 있으나 데이터 모델링과 프로세스 모델링은 상호 보완적인 관점에서 이해되어야 하며 특히 데이터 모델은 시스템의 뼈대가 되기 때문에 데이터 모델링의 결과에 따라 시스템의 안정성은 많은 영향을 받게 된다고 할 수 있다. 고품질의 데이터 모델은 시스템의 안 정성과 유연성, 성능 등에 미치는 영향이 크기 때문에 고품질의 데이터 모델을 확보하기 위한 데이터 모델링은 시스템 개발에 있어서 가장 핵심적인 과정이라 할 수 있다. 과거의 시스템 구축 방법의 주를 이루는 프로세스 중심적인 시스템 구축 방법에서는 위와 같이 데이터와 관련한 정보 공유의 문제점이 다수 발생하게 된다. 이러한 요인들은 결국 데이터의 무결성에 좋지 않은 영향을 주게 된다. 이러한 문제점들은 데이터 품질에도 악영향을 미치게 된다. 이러한 문제점들을 해소하기 위한 방안으로 기업들은 데이터 품질 툴을 고려하고 있다. 많은 기업이 데이터 품질 툴을 이미 도입하였거나 또는 도입을 검토하고 있다. 하지만 데이터 품질 툴 도입과 같은 일회성의 데이터 품질 향상 방안으로는 문제점을 근본적으로 치유하기에는 무리가 있다.

근본적인 조치로는 난로 연통형의 개별 업무 영역을 초월하여의 설계가 근본적인 해결 방안이다. 이러한 통합 데이터 구조의 가장 큰 특징은 데이터 의 중복이 최소화되어 있다는 점이다.

데이터 모델링이 중요하다고 한다. 시스템 구축 과정 중에는 여러 설계 과정이 존재한다. 그 중에서도 특히 데이터 설계가 중요한 이유를 다음과 같이 정리할 수 있다.

파급 효과(Leverage)

시스템 구축이 완성되어 가는 시점에서는 많은 애플리케이션이 테스트를 수행하고, 대규모의 데이터 이행을 성공적으로 수행하기 위한 많은 단위 테스트가 수행되고, 이러한 과정이 반복된다. 각 단위 테스트가 성공적으로 수행되고 완료되면 전체를 묶어 병행 테스트, 통합 테스트를 수행하게 된다. 만약 이러한 시점에 데이터 모델을 불가피하게 약간 변경해야 하는 상황이 발생한다고 가정해 보자. 이를 위해서 많은 영향 분석 과정이 일어나야 한다. 데이터 구조의 변경에 따른 표준 영향 분석, 응용 변경 영향 분석 등 많은 영향 분석이 일어난다. 그 이후에 해당 분야의 실제적인 변경 작업이 발생하게 된다. 변경을 해야 하는 데이터 모델의 형태에 따라 그 영향 정도는 차이가 있겠지만 이 시기의 데이터 구조의 변경으로 인한 일련의 변경 작업은 전체 시스템 구축 프로젝트에서 큰 위험 요소가 아닐 수 없다. 이러한 이유로 인해 시스템 구축 작업 중에서 다른 어떤 설계 과정보다 데이터 설계가 더 중요하다고 볼 수 있다.

복잡한 정보 요구 사항의 간결한 표현(Conciseness)

데이터 모델은 구축할 시스템의 정보 요구 사항과 한계를 가장 명확하고 간결하게 표현할 수 있는 도구이다. 정보 요구 사항을 파악하는 가장 좋은 방법은 수많은 페이지의 기능적인 요구 사항을 파악하는 것보다 간결하게 그려져 있는 데이터 모델을 리뷰하면서 파악하는 것이 훨씬 빠른 방법이다. 데이터 모델은 건축물로 비유하면 설계 도면에 해당한다. 이것은 건축물의 설계 도면이 건축물을 짓는 많은 사람이 공유하면서 설계자의 생각대로 일사불란하게 움직여서 아름다운 건축물을 만들어 내는 것에 비유할 수 있다. 데이터 모델은 시스템을 구축하는 많은 관련자가 설계자의 생각대로 정보 요구 사항을 이해하고 이를 운용할 수 있는 애플리케이션을 개발하고 데이터 정합성을 유지할 수 있도록 하는 것이다. 이렇게 이상적으로 역할을 할 수 있는 모델이 갖추어야 할 가장 중요한 것은 정보 요구 사항이 정확하고 간결하게 표현되어야 한다는 점이다. 활용하고 있는 데이터 모델이 이와 같은 요소들을 충족한 모델인지를 확인해 볼 필요가 있다.

데이터 품질(Data Quality)

데이터베이스에 담겨 있는 데이터는 기업의 중요한 자산이다. 이 데이터는 기간이 오래되면 될수록 활용가치는 훨씬 높아진다. 그런데 오랫동안 저장된 데이터가 그저 그런 데이터, 정확성이 떨어지는 데이터라면 어떨까? 이것은 일부 시스템의 기능이 잘못되어 수정하는 성격의 일이 아니다. 이것은 해당 데이터로 얻을 수 있었던 소중한 비즈니스의 기회를 상실할 수도 있는 문제이다. 데이터 품질의 문제가 중요한 이유가 여기에 있다. 데이터 품질의 문제는 데이터 구조가 설계되고 초기에 데이터가 조금 쌓일 때에는 인지하지 못하는 경우가 대부분이다. 이러한 데이터의 문제는 오랜 기간의 숙성된 데이터를 전략적으로 활용하려고 하는 시점에 대두되기 때문이다. 데이터 품질의 문제를 야기시키는 중대한 이유 중 하나가 바로 데이터 구조의 문제로 인해 야기된다. 중복 데이터의 미정의, 데이터 구조의 비즈니스 정의의 불충분, 동일한 성격의 데이터를 통합하지 않고 분리함으로써 데이터 불일치 등등 데이터 구조의 문제로 인한 데이터 품질의 문제는 치유하기에 불가능한 경우가 대부분이다.

데이터 모델링의 필요성은 다음과 같은 관점에서 설명될 수 있다.

애플리케이션과 데이터의 통합

현재 기업에서는 진정한 정보 인프라 구축을 위해 데이터와 애플리케이션의 통합에 많은 노력을 기울이고 있다. 데이터 기반의 통합이 아닌 애플리케이션 코딩 차원의 통합 시도에는 너무나 많은 비용과 시간이 소요된다. 데이터를 기반으로 한 통합은 효과적이면서 동시에 저비용으로 통합 프로젝트를 안정적으로 수행하면서 성공적으로 완수하기 위한 필요조건이 되고 있다. 이로 인해 데이터 기반 통합의 핵심 요소인 데이터 모델링의 중요성은 날로 부각되고 있다.

개발자들의 시스템 이해

개발자들은 하나의 애플리케이션에서 사용되는 데이터가 어떤 것인지 파악하고 이해하는 것뿐만 아니라 전체 시스템에서 데이터가 어떻게 상호 연관성을 가지고 유기적으로 움직이고 있는가에 대해 명확하게 이해하는 데 많은 어려움을 겪고 있다. 개발자들은 그들이 개발할 시스템과 데이터를 좀 더 확실하게 이해하기 위해 데이터의 모형화를 필요로 한다.

1) 사용자 관점 데이터

프로세스 모델링과 같이 데이터 모델링은 사용자가 원하는 것의 논리적 개념과 시스템이 어떻게 그것을 제공하는지의 물리적 개념을 명확하게 나타낸다.

2) 물리적 표현 또는 사용에 관계없는 데이터 그 자체의 본질

물리적인 것과 논리적인 것을 구별함으로써 저장 기법, 데이터와 파일 접근 방법 그리고 데이터를 사용하는 사람과 사용법에 대한 내역 등 변화되는 물리적인 것으로부터 독립되어 조직과 사용자가 필요로 하는 필수적이고 기본적인 데이터를 정의할 수 있다.

3) 애플리케이션간 데이터 사용

데이터 모델링은 데이터 정의, 생명주기 정보(CRUD) 그리고 언제 어떻게 데이터가 사용되었는지를 추적할 수 있는 방법(매트릭스 분석 기법을 이용한 상호작용 분석) 등을 제공함으로써 애플리케이션을 통해 데이터가 어떻게 사용되는지를 개발자들이 쉽게 이해할 수 있도록 한다.

데이터 모델링시 주의점

1) 중복(Duplication)

데이터 모델은 같은 데이터를 사용하는 사람, 시간, 그리고 장소를 파악하는데 도움을 준다. 이러한 지식 응용은 데이터베이스의 여러 장소에 같은 정보를 저장하는 잘못을 하지 않도록 한다.

2) 비유연성(Inflexibility)

데이터 모델을 어떻게 설계했느냐에 따라 사소한 업무 변화에도 데이터 모델이 수시로 변경됨으로써 유지보수의 어려움을 가중시킬 수 있다. 데이터의 정의를 데이터의 사용 프로세스와 분리함으로써 데이터 모델링은 데이터 혹은 프로세스의 작은 변화가 애플리케이션과 데이터베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄인다.

3) 비일관성(Inconsistency)

데이터의 중복이 없더라도 비일관성은 발생한다. 예를 들어 신용 상태에 대한 갱신 없이 고객의 납부 이력 정보를 갱신하는 것이다. 개발자가 다른 데이터와 모순된다는 고려 없이 일련의 데이터를 수정할 수 있기 때문이다. 데이터 모델링시 데이터와 데이터간 상호연관 관계에 대한 명확한 정의는 이러한 위험을 사전에 예방할 수 있도록 해준다.

데이터 모델링 단계

데이터 모델링은 현실 세계의 기업 업무에서 발생하는 데이터에 대하여 물리적으로 데이터베이스화하기 위해 이루어지는 과정 중의 한 단계이다. 이 데이터 모델링은 개념 데이터 모델링, 논리 데이터 모델링, 물리 데이터 모델링 등 3단계로 나눌 수 있으며, 엄밀한 의미에서범주로 보기도 한다.

개념 데이터 모델링 단계에서는 주제별로 분류 가능한 업무를 분석한 후 핵심 엔터티(Entity)를 추출 하고 그들 간의 관계를 정의하여 전체 데이터 모델의 골격을 생성한다. 이렇게 도출된 엔터티(업무) 간 의 관계를 표현하기 위해 개체-관계 다이어그램(ERD, Entity-Relationship Diagram)을 작성한다.

논리 데이터 모델링 단계에서는 개념 데이터 모델링 단계에서 정의한 핵심 엔터티와 관계를 바탕으로 상세 속성을 정의하고 식별자를 확정하며 정규화와 같은 상세화 과정을 수행한다. 마지막으로 물리 데이터 모델링 단계에서는 논리 데이터 모델을 기반으로 목표하는 DBMS의 특성 및 구현 환경 등을 감안한 스키마(데이터 구조)를 일정한 기준과 규칙에 의해 도출하고 칼럼(Column)의 데이터 타입과 크기를 정의한다. 또한 데이터 사용량을 분석 예측하는 과정을 통해 효율적인 데이터베이스가 될 수 있도록 인덱스의 정의 및 역정규화 작업을 수행한다.

이러한 단계별 내용은 프로젝트 진행과도 일치한다. 물리 데이터 모델링 단계 후에 얻어진 스키마를 실제 데이터베이스로 생성하면 본격적인 애플리케이션 개발 단계로 넘어가게 된다. 각 단계에 대해 상세히 알아보면 다음과 같다.

개념 데이터 모델링(Conceptual Data Modeling)

개념 데이터 모델링은 조직, 사용자의 데이터 요구 사항을 찾고 분석하는 데서 시작한다. 이 과정은 어떠한 자료가 중요하며 또 어떠한 자료가 유지되어야 하는지를 결정하는 것도 포함한다. 이와 같이 데이터 요구 사항은 분석 과정의 초기에 본질적으로 기술과 무관한 사양들의 집합인 개념 데이터 모델로 형상화되고, 비즈니스 이해 관계자들과 초기 요구 사항을 논의하기 위해 사용된다. 이 단계에 있어서의 주요한 활동은 핵심 엔터티와 그들 간의 관계를 발견하고, 그것을 표현하기 위해서 개체-관계 다이어그램을 생성하는 것이다. 개체-관계 다이어그램은 조직과 다양한 데이터베이스 사용자에게 어떠한 데이터가 중요한지를 나타내기 위해서 사용된다. 데이터 모델링에서 다루는 범위와 수행 과정이 전 조직에 걸쳐 이루어진다면, 그것은 전사적 데이터 모델(Enterprise Data Model)이라고 불린다.

개념 데이터 모델을 통해 조직의 데이터 요구를 공식화하는 것은 두 가지의 중요한 기능을 지원한다. 첫째, 개념 데이터 모델은 사용자와 시스템 개발자의 데이터 요구 사항 발견을 지원한다. 개념데이터 모델은 추상적이다. 그렇기 때문에 그 모델은 상위의 문제에 대한 구조화를 쉽게 하며, 사용자와 개발자가 시스템 기능에 대해서 논의할 수 있는 기반을 형성한다. 둘째, 개념 데이터 모델은 현 시스템이 어떻게 변형되어야 하는가를 이해하는 데 유용하다. 일반적으로 매우 고립된(StandAlone) 시스템도 간단하게 추상적 모델링을 통해서 좀 더 쉽게 표현되고 설명된다.

논리 데이터 모델링(Logical Data Modeling)

논리 데이터 모델링은 데이터 모델링 프로세스의 Input으로써 비즈니스 정보의 논리적인 구조와 규칙을 명확하게 표현하는 기법 또는 과정이라 할 수 있다. 논리 데이터 모델링의 결과로 얻어지는 논리 데이터 모델은 데이터 모델링이 최종적으로 완료된 상태라고 정의할 수 있다. 즉, 물리적인 스키마 설계를 하기 전 단계의‘데이터 모델’상태를 일컫는 말이다. 논리 데이터 모델링의 핵심은 어떻게 데이터에 액세스하고 누가 데이터에 액세스하며, 그러한 액세스는 전산화와는 독립적으로, 다시 말해서 누가(Who), 어떻게(How), 그리고 전산화는 별개로 비즈니스 데이터에 존재하는 사실들을 인식하여 기록하는 것이며, 이것은 기법으로서의 의미를 넘어 하나의 철학이라고도 할 수 있다.

특히 데이터 모델링 과정에서 가장 핵심이 되는 부분이 논리 데이터 모델링이라고 할 수 있다. 데이터 모델링이란 모델링 과정을 통해서 조사하고 결정한 사실을 단지 개체-관계 다이어그램이라는 그림으로 그려내는 과정을 말하는 것이 아니다. 시스템 구축을 위해서 가장 먼저 시작할 기초적인 업무 조사를 하는 초기 단계부터 인간이 결정해야 할 대부분의 사항을 모두 정의하는 시스템 설계의 전 과정을 지원하는‘과정의 도구’라고 해야 할 것이다.

이 단계에서 수행하는 또 한 가지 중요한 활동은 정규화이다. 정규화는 논리 데이터 모델 상세화 과정의 대표적인 활동으로 논리 데이터 모델의 일관성을 확보하고 중복을 제거하여 속성들이 가장 적절한 엔터티에 배치되도록 함으로써 좀 더 신뢰성있는 데이터 구조를 얻는 데 목적이 있다. 논리데이터 모델의 상세화는 식별자 확정, 정규화, M:M 관계 해소, 참조 무결성 규칙 정의 등을 들 수 있으며, 추가적으로 이력 관리에 대한 전략을 정의하여 이를 논리 데이터 모델에 반영함으로써 데이터 모델링을 완료하게 된다. 이에 대한 상세한 내용은 제3장 논리 데이터 모델링에서 다룬다.

물리 데이터 모델링(Physical Data Modeling)

데이터 모델링 과정의 세 번째 단계인 물리 데이터 모델링은 논리 데이터 모델이 데이터 저장소로서 어떻게 컴퓨터 하드웨어에 표현될 것인가를 다룬다. 데이터가 물리적으로 컴퓨터에 어떻게 저장될 것인가에 대한 정의를 물리적 스키마라고 한다. 이 단계에서 결정되는 것은 테이블, 칼럼 등으로 표현되는 물리적인 저장 구조와 사용될 저장 장치, 자료를 추출하기 위해 사용될 접근 방법 등이 있다.

계층적 데이터베이스 관리 시스템 환경에서는 데이터베이스 관리자가 물리적 스키마를 설계하고 구현하기 위해서 보다 많은 시간을 투자하여야 한다. 계층적 데이터베이스 관리 시스템 환경에서의 물리적 스키마 설계의 예는 데이터의 디스크상의 위치, 색인화할 레코드, 다양한 최적화 문제 등이다.

이에 비해, 논리 데이터 모델은 매체에 물리적으로 구현되는 것과는 독립적으로 여겨진다. 현실적으로 물리 데이터 모델을 계층적 데이터베이스 관리 시스템에 구현하는 것은 그것이 구현될 하드웨 어와 밀접한 관계를 맺고 있다. 그러나 관계형 데이터베이스 관리 시스템의 출현으로 인해 그 초점이 개념 및 논리 데이터베이스 설계로 이동하고 있다. 그래서 관계형 데이터베이스 관리 시스템을 사용하는 조직에서는 데이터베이스 관리자가 잘 유지해야 하는 데이터 항목의 발견과 데이터 항목 간에 존재하는 논리 관계를 이해하는데 더 많은 시간을 할애한다. 관계형 데이터베이스 관리 시스템의 출현으로 인하여 물리적 데이터베이스 설계와 관련된 문제들은 많은 부분 관계형 데이터베이스 관리 시스템 소프트웨어에서 처리되고 있다.

모델링 기본원칙

일반적으로 모델링의 방법론, 기법, 도구와 같은 개발 보조 수단의 사용 없이는 시스템이 잘 설계될 수 없을 것이라 생각하게 된다. 하지만 과거의 수많은 시스템들은 이러한 개발 보조기구의 사용없이 성공적으로 개발됐다. 물론 과거의 시스템들은 단순해서 그러할 수 있었다고 주장한다면 그 말 역시 맞는 말이다. 그러나 이러한 사실들은 여기에서 말하려는 모델링의 핵심 사항은 아니다. 프로젝트의 어려움 정도 또는 도구와 기술에 상관없이 좋은 설계를 포함한 훌륭한 시스템 개발은 다음의 단순한 단계로부터 시작한다.

• 해결해야 하는 문제점들을 선별, 결정한다.
• 해결책을 위한 문제점들을 구체화한다.
• 시스템을 구축한다.
• 실제로 구현한다.

시스템 개발 실패의 주요 요인을 무엇이라 생각하는가? 그것은 처음의 요구 사항을 충족시키지 못하는 설계자의 무능력을 들 수 있다. 즉 적절한 시스템이 개발되기 위해서는 요구 사항을 완전하고 정확하게 식별해야 한다. 논리 데이터 모델링은 기능 또는 조직이 사용하는 물리적 설계 구조에 관계없이 기업의 비즈니스에 존재하는 데이터의 명확한 구조 및 정의를 제시한다. 이는 최종 사용자 관점에서 바라보는 정보구조를 개념화하고 추상화시킨 데이터의 구조이다. 다음에 설명할 세 가지 최우선 원칙들은 논리 데이터 모델링의 접근 방식을 성공적으로 이끄는 토대이다.

커뮤니케이션 원칙(Communication Principle)

요구 사항은 모든 사람들이 이해할 수 있도록 명확하게 공표됨은 물론 최종 사용자 지향적으로 분명하게 파악되는 수준으로 작성되어야 한다. 논리 데이터 모델링의 주목적은 최종 사용자 데이터에대한 뷰(View)를 개념화하고 추상화하여 시스템 설계자들에게 전달하는 것이다. 물론 커뮤니케이션 원칙이 최종 사용자들에게만 적용되는 것은 아니다. 다른 배경과 기술을 가진 많은 사람들도 논리 데이터 모형의 이해를 필요로 한다.

[표 5-1-1] 데이터 모델의 이해를 필요로 하는 그룹

그룹명	필요성
최종 사용자	개념화, 추상화, 정규화 기법을 통하여 중복없고, 데이터의 정확성을 보장하는 데이터 구조의 이해 및 사용
시스템 분석가	시스템에서 사용되어질 정확한 데이터의 구조 및 데이터가 갖는 업무 규칙의 이해
데이터베이스 관리자	논리 데이터 모델의 구조와 물리 스키마(데이터의 구조)의 차이점을 이해하고 최종 사용자에게는 데이터의 제공, 시스템 분석가에게는 물리 스키마의 제공을 위한 데이터 구조의 이해
타 프로젝트에서 작업하는 분석가	관련 프로젝트가 데이터를 어떻게 정의하고 있는지를 알아냄. 인터페이스(Interface)가 개발되어지고 데이터가 애플리케이션 또는 시스템 간에 공유되기 위한 데이터 구조 및 업무 규칙의 이해

[표 5-1-1]의 그룹 구성원들과의 커뮤니케이션을 용이하게 하기 위해서는 두 가지의 논리 데이터 모델을 생각해 볼 수 있다. 그것은 비즈니스 지향적인 최종 사용자 데이터 모델과 기술적인 상세 데이터 모델이다. 논리 데이터 모델의 문서와 그림을 작성할 때 그 목적을 명확히 해야 한다. 왜냐하면 모델을 보는 사람들에게 기술적으로 알아보기 힘든 혼란을 주는 것은 곤란하기 때문이다. 이와 같은 명확한 정의를 통해 시스템 개발 관련자와 최종 사용자들간에 비즈니스 요구 사항이 정확히 전달되어야 한다.

모델링 상세화 원칙(Granularity Principle)

데이터의 상세화 정도를 제시하고 조직이 사용하는 정보 구조의‘최소 공통 분모’를 제시해야 한다. 또한 복잡한 구조는 요소적인 부분들로 쪼개야 하며 불필요한 구조와 중복은 제거되어야 한다. 일반적으로 논리 데이터 모델은 너무 상세화될 필요가 없다든지 애플리케이션에 대한 상세화는 물리 데이터 모델에서 이룰 수 있다는 생각은 위험한 태도이다. 모델링의 상세화 원칙은“데이터는 데이터의 본질과 잠재적 사용을 이해할 수 있을 만큼 상세화되어야 한다”는 것을 의미한다. 사실 좋은 설계는 분석 단계(논리 데이터 모델)를 위한 상세 수준이 다른 단계(물리 데이터 모델)에서 선택된 수준만큼 상세화되어야 한다는 것을 의미한다.

많은 모델러(Modeler)가 겪는 문제는 논리 데이터 모델에서 물리 데이터 모델로의 이동이 분해 과 정이라고 오해하는 것이다. 하지만 논리 데이터 모델에서 물리 데이터 모델로의 이동은 분해가 아니 라 보통 수준의 상세화에서 발생하는 변환(Transformation)이다. 즉, 물리 데이터 모델링은 논리 데이터 모델에 대한 변환 과정이다. [그림 4-1-3]을 참조한다.

논리적 표현 원칙(Logical Representation Principle)

조직의 데이터에 대한 논리적 측면을 최대한 표현해야 한다. 모델은 물리적 제약 조건 없이 비즈니스를 그대로 반영해야 한다. 즉, 논리 데이터 모델은 특정 아키텍처, 기술 또는 제 사용자들이 항상 시스템 개발자들에게 가지는 주요 불만 사항은 바로 ‘이해의 부족’이다. 사용자가 원하는 것에 근거를 두지 않은 프로젝트는 실패할 확률이 높다. 또한 기존 애플리케이션에 대한 빈약한 문서화의 주요 원인 중 하나는 성급하게 물리적 설계 단계로 들어가려 하는 분석가들의 성향 때문이다. 논리적 설계와 물리적 설계를 구별하지 못하면 프로젝트가 추 구하고자 하는 물리적 선택 사항을 제한하거나 잘못된 방향으로 진행하게 된다. 이러한 문제들을 예를 통해 이해해 보자.

1) 웬만한 분석의 결과는 잘 알고 있다(지름길을 좋아하는 것)

어떤 이들은 여러 가지 이유(예를 들어, 자명하게 보이는 분석을 수행하는 데 시간 낭비를 줄이기 위해 또는 결과가 이미 정해져 있어서)때문에 분석을 생략하는 경우가 많다. 대부분의 경우에서 모델러들은 애플리케이션 개발 과정에서 발생할 수 있는 모든 것들을 알 수 없다. 또한 모델러들은 몇 십년내에 시스템에서 발생할 수 있는 것에 대해서도 확신하지는 못한다. 결론적으로 최적의 행동은 솔루션에 독립적인 방식으로 규칙을 따르고 문제를 문서화하는 것이다.

2) 조급하게 솔루션을 구체화하는 것

문제를 조사할 때 데이터베이스가 어떻게 구현되어야 하는가에 관한 기발한 아이디어가 나오기란 어렵다. 이러한 점에서 섣불리 솔루션을 구체화하는 것은 잘못된 것이다. 그 이유는 문제의 일부분만을 파악했을 때 이를 해결할 수 있는 모든 데이터가 확보된 것은 아니며, 나중에 인식한 문제로부터 다른 솔루션을 발견할 수도 있기 때문이다. 또한 문제가 정확히 진술된 것이 아니기 때문에 작업물을 검토하는 다른 사람들은 솔루션이 문제를 해결하는 이유를 이해할 수 없을 것이다. 이것은 분석가들이 솔루션을 그들의 머리에서 없애야 한다는 것이 아니라 솔루션에 대한 좋은 생각이 표면화되었을 때 그것을 기록하여 논리적 설계 다음에 물리 데이터 모델 설계자에게 전달하여야 한다는 것을 의미한다.

논리적 설계의 컴포넌트가 부정확하거나 빼먹었을 때 물리 데이터 모델에서 논리 데이터 모델로의 회귀는 피할 수 없다. 물리 데이터 모델 제약 조건이 명시된 경우 조차도 논리 데이터 모델은 제약 조건이 없는 것처럼 진행해야 한다. 그럼에도 불구하고 이러한 경우들이 논리적 표현 원칙을 변화시키지는 않는다. 논리 데이터 모델링이 2년짜리 프로젝트의 첫 단계이든지 수많은 2주 짜리의 반복 과정이든지에 상관 없이 원칙은 솔루션을 구체화하기 전에 문제를 이해해야 한다는 것이다.

좋은 데이터 모델의 요소

일반적으로 시스템 구축 과정에서 생성되는 데이터 모델은 품질을 평가하는 것이 매우 어렵다. 사실은 특정 데이터 모델이 업무 환경에서 요구하는 사항을 얼마나 잘 시스템적으로 구현할 수 있는가를 객관적으로 평가할 수 있다면 가장 좋은 평가 방법일 것이다. 하지만 이것을 객관적으로 평가할 수 있는 기준이 존재하지는 않는 것이 현실이다. 다음에서는 이러한 상황에서 대체적으로 좋은 데이터 모델이라고 말할 수 있는 몇 가지의 요소를 설명한다.

완전성(Completeness)

업무에서 필요로 하는 모든 데이터가 데이터 모델에 정의되어 있어야 한다. 완전성은 데이터 모델을 검증하기 위해서 가장 먼저 확인해야 할 부분이다. 이 기준이 충족되지 못하면 다른 어떤 평가 기준도 의미가 없어진다. 만약 보험사의 데이터 모델에 고객의 직업을 관리하기 위한 속성이 존재하지 않는다면 어떻겠는가? 이것은 심각한 데이터 모델의 문제점이다.

중복 배제(Non-Redundancy)

하나의 데이터베이스 내에 동일한 사실은 반드시 한 번만 기록하여야 한다. 예를 들면, 하나의 테이블에서‘나이’칼럼과‘생년월일’칼럼이 동시에 존재한다면 이것은 데이터 중복이라고 볼 수 있다. 이러한 형태의 데이터 중복 관리로 인해 여러 가지의 바람직하지 않는 형태의 데이터 관리 비용을 지불하고 있다. 예를 들면, 저장 공간의 낭비, 중복 관리되고 있는 데이터의 일관성을 유지하기 위한 추가적인 데이터 조작 등이 대표적으로 낭비되고 있는 비용이라고 볼 수 있다.

비즈니스 룰(Business Rules)

데이터 모델에서 매우 중요한 요소 중에 하나가 데이터 모델링 과정에서 도출되어 지고 규명되어지는 수많은 업무 규칙(Business Rules)을 데이터 모델에 표현하고 이를 해당 데이터 모델을 활용 하는 모든 사용자가 그 규칙을 공유할 수 있게 제공하는 것이다. 특히 데이터아키텍처에서 언급되는논리 데이터 모델(Logical Data Model)에서 이러한 요소들이 포함되어야 함은 매우 중요한 요소라고 할 수 있다. 예를 들면, 보험사의 사원들은 매월 여러 가지 항목에 대해 급여를 지급받고, 이를 데이터로 관리하고 있다. 각 사원들은 월별로 하나 이상의 급여 항목(기본급, 상여금, 수당, 수수료, 등등)에 대해 급여를 지급받는다. 여기에 더 나아가 각 사원은 사원 구분별(내근, 설계사, 계약직, 대리점 등)로 위의 급여 항목을 차등적으로 지급받는다는 업무 규칙이 존재한다. 이러한 내용을 데이터 모델에 나타내어야 한다. 이렇게 함으로써 해당 데이터 모델을 사용하는 모든 사용자(개발자, 관리자등)가 해당 규칙에 대해 동일한 판단을 하고 데이터를 조작할 수 있게 되는 것이다.

데이터 재사용(Data Reusability)

데이터의 재사용성을 향상시키고자 한다면 데이터의 통합성과 독립성에 대해서 충분히 고려해야 한다. 무슨 이야기인가? 과거에 정보시스템이 생성되고 운영되던 형태를 되짚어보면 철저하게 부서 단위의 정보시스템으로 설계되고 운용되어 왔다. 현재 대부분의 회사에서 진행하고 있는 신규 정보 시스템의 구축 작업은 어떻게 이루어지고 있는가? 회사 전체 관점에서 공통 데이터를 도출하고 이를전 영역에서 사용하기에 적절한 형태로 설계하여 시스템을 구축하게 된다. 이러한 형태의 데이터 설계에서 가장 중요하게 대두되는 것이 통합 모델이다. 통합 모델이어야만 데이터 재사용성을 향상시킬 수 있다. 또 다른 측면에서 보면 과거 정보시스템의 데이터 구조의 가장 큰 특징은 데이터 모델이 별도로 존재하지 않고 애플리케이션의 부속품 정도로 인식되어져 왔던 것이 사실이다. 이러한 환경에서의 데이터는 프로세스의 흐름에 따라 관리되게 마련이다. 이러면 데이터 중복이 많이 발생하고 데이터의 일관성 문제가 심각하게 초래된다. 데이터가 애플리케이션에 대해 독립적으로 설계되어야만 데이터 재사용성을 향상시킬 수 있다.

안정성 및 확장성(Stability and Flexibility)

정보 시스템은 비즈니스의 변화에 대해 최적으로 적응하도록 끊임없이 요구 받고 있다. 하지만 정보시스템의 데이터 모델은 이러한 변화에 대해 어떻게 대응할 수 있는가? 현재의 데이터 구조를 거의 변화하지 않고도 변화에 대응할 수 있는 데이터 구조도 있을 것이고, 아주 적은 확장을 통해 이러한 변화에 대응하는 것도 있을 것이다. 하지만 이러한 변화에 대응하기 위해 데이터 구조적으로 아주 많은 변화를 주어야만 한다면 변화의 대상이 되는 부분뿐만 아니라 정보시스템의 나머지 부분들도 많은 영향을 받게 될 것이다. 그래서 많은 기업이 정보시스템을 구축하는 과정에서 데이터 구조의 확장성, 유연성에 많은 노력을 기울이고 있다. 그렇다면 어떤 데이터 모델이 이러한 확장성을 가진 데이터 모델인가?

현대의 기업들이 동종의 타 기업으로부터 경쟁 우위에 자리매김하려고 한다면 구축하는 데이터 모하게 대응할 수 있어야 한다. 특히 근래의 많은 패키지 시스템이 가지고 있는 데이터 모델들은 확장성을 강조하기 위해서 많은 부분을 통합한 데이터 모델 형태를 가지고 있는 것을 볼 수 있다. 여기에서도 잘 나타나듯이 확장성을 담보하기 위해서는 데이터 관점의 통합이 불가피하다. 특히 정보시스템에서의 ‘행위의 주체’가 되는 집합의 통합,‘ 행위의 대상’이 되는 집합의 통합, ‘행위 자체’에 대한 통합 등은 전체 정보시스템의 안정성, 확장성을 좌우하는 가장 중요한 요소라 할 수 있다.

간결성(Elegance)

데이터 모델이 갖추어야 하는 중요한 요소 중 하나는 기업이 관리하고자 하는 데이터를 합리적으로 균형이 있으면서도 단순하게 분류하는 것이다. 아무리 효율적으로 데이터를 잘 관리할 수 있더라도 그것의 사용, 관리 측면에서 복잡하다면 잘 만들어진 데이터 모델이라고 할 수 없다. 동종의 비즈니스를 영위하는 기업이라고 하더라도 각 회사의 데이터 모델을 비교해 보면 복잡도에는 많은 차이가 있는 것을 볼 수 있다. A 보험사는 계약 업무를 수행하기 위해 10개의 테이블을 정의해 업무를 수행하는 반면에 B 회사는 100개의 테이블을 정의해 동일한 업무를 수행하고 있다. 두 회사의 데이터 모델의 차이점은 무엇인가? 10개의 테이블을 가지고 업무를 수행하고 있는 A 회사의 데이터 모델은 간결하지만 새로운 업무 환경의 변화에 대해 확장성을 가지고 있다. B 회사는 겉으로는 새로운 업무 환경의 변화(신규 상품의 출현 등)에 능동적으로 대처하고 있는 것처럼 보이지만 사실은 보유하고 있는 데이터 모델의 한계로 인해 테이블의 수가 지속적으로 증가해 왔다. 이렇게 됨으로써 데이터 모델은 간결하지 못하고 동일한 형태로 관리되어야 하는 데이터가 복잡한 형태로 관리되어지고, 그들과의 관계를 갖고 있는 다른 여러 가지의 데이터나 복잡한 형태의 관계들이 불가피해 복잡성을 증가시켜왔다. 결국 간결한 모델의 기본적인 전제는 통합이다. 합리적으로 잘 정돈된 방법으로 데이터를 통합하여 데이터의 집합을 정의하고, 이를 데이터 모델로 잘 표현하여 활용한다면 웬만한 업무 변화에도 데이터 모델이 영향을 받지 않고 운용될 수 있게 된다.

의사소통(Communication)

데이터 모델의 역할이 많다. 그 중에서도 중요한 것이 데이터 모델의 의사소통 역할이다. 데이터 모델은 대상으로 하는 업무를 데이터 관점에서 분석하고 이를 설계하여 나오는 최종 산출물이다. 데이터 분석 과정에서는 자연스럽게 많은 업무 규칙이 도출된다. 이 과정에서 도출되는 많은 업무 규칙은 데이터 모델에 엔터티, 서브타입, 속성, 관계 등의 형태로 최대한 자세하게 표현되어야 한다. 예를 들면,‘ 사원’테이블에는 어떠한‘사원구분’을 가지는 사원들이 존재하는가? ‘ 정규직’,‘ 임시직’ 사원들이 같이 존재하는가? 아니면 또 다른 형태의 사원들이 존재하는지를 표현해야 한다. 더 나아가서‘호봉’이라는 속성은‘정규직’일 때에만 존재하는 속성인데, 이러한 업무 규칙이 데이터 모델에 표현되어야 한다. 또한 관리하는 사원 중에서‘정규직’사원만이‘급여’테이블과 관계를 가진다. 이러한 부분은 개별 관계로 데이터 모델에 표현되어야 한다. 이렇게 표현된 많은 업무 규칙은 해당 정보시스템을 운용, 관리하는 많은 관련자들이 설계자가 정의한 업무 규칙들을 동일한 의미로 받아들이고 정보시스템을 활용할 수 있게 하는 역할을 한다. 즉, 데이터 모델이 진정한 의사소통 (Communication)의 도구로서의 역할을 하게 된다.

통합성(Integration)

기업들이 과거로부터 정보시스템을 구축해왔던 방법은 개별 업무별로의 단위 정보 시스템을 구축하여 현재에까지 유지 보수를 해오고 있는 것이 보통이다. 점진적인 확장과 보완의 방법으로 정보시스템을 사용해 왔기 때문에 동일한 성격의 데이터임에도 불구하고 전체 조직 관점에서 보면 여러 곳에서 동일한 데이터가 존재하기 마련이다. 특히 이러한 데이터 중에서도 고객, 상품 등과 같이 마스터 성격의 데이터들이 분할되어 관리됨으로 인해 전체 조직 관점의 데이터 품질, 관리, 활용 관점에서 많은 문제점이 나타나고 있는 것이 현실이다. 가장 바람직한 데이터 구조의 형태는 동일한 데이터는 조직의 전체에서 한 번만 정의되고 이를 여러 다른 영역에서 참조, 활용하는 것이다. 물론 이때에 성능 등의 부가적인 목적에 따라 의도적으로 데이터를 중복시키는 경우는 존재할 수 있다. 동일한 성격의 데이터를 한 번만 정의하려면 공유 데이터에 대한 구조를 여러 업무 영역에서 공동으로 사용하기 용이하게 정의할 수 있어야 한다. 이러한 이유로 데이터 아키텍처의 중요성이 한층 더 부각되고 있다.