데이터 모델링

데이터 모델링(Data Modeling)이란 주어진 개념으로부터 논리적인 데이터 모델을 구성하는 작업을 말한다. 여기서 데이터 모델(Data Model)이란 데이터(data)의 관계, 접근과 흐름에 필요한 처리 과정을 추상화한 모형이다. 일반적으로 물리적인 데이터베이스 모델 구현, 시스템 데이터베이스 반영 과정을 포함한다. 데이터 모델링은 단순 데이터를 다루는 것뿐만 아니라 시스템의 구체적인 흐름을 정의하는데도 매우 큰 영향을 끼친다.

개요

일상생활에서 어떤 사물을 제작, 설계할 때 참고하는 본보기, 예시, 모형 등을 모델이라고 하는데, 데이터에 있어 모델은 현실 세계에 대해 우리가 관심 있어 하는 대상을 데이터베이스화하기 위한 개념적 도구라 정의할 수 있다. 그런 데이터 모델을 단순 표현과 명확하게 나타내기 위해 설계하고 구현하는 과정을 데이터 모델링이 된다. 모델링 과정 중 설계에서 중요한 개념을 구분 하여 개념적 설계를 하는 '개념적 모델링', 그렇게 구현된 기초 모델링을 상세화하는 과정을 '논리적 모델링', 논리적 모델링에서 완성된 데이터 모델은 데이터베이스에 적용하는 과정을 '물리적 모델링'으로 나뉜다. 초창기 데이터의 저장 매체가 존재하지 않아, 기업의 정보시스템은 저장 매체가 없는 단지 배치(batch) 프로그램 위주의 정보 시스템이다. 하지만 정보 기술의 발전에 따라 배치 위주의 정보시스템은 한계가 있었으며 이후 파일이나 데이터베이스 관리 시스템(DBMS, DataBase Management System)과 같은 저장 매체의 발전과 더불어 온라인 데이터 처리 정보시스템이 등장하게 되었다. 현재의 관계형 데이터베이스 관리 시스템이 아닌 이러한 시기의 파일이나 데이터베이스 관리 시스템의 데이터 중심의 관리 기법이 아니라 배치 프로세스에서 태동한 프로세스 중심의 데이터 관리 기법(구조적 방법론)에 의하여 정보의 고립화라는 현상을 초래하게 되었으며, 많은 기업들은 정보시스템을 유지관리하는데 막대한 비용을 투자해야만 하는 문제점이 생겼다. 이에 많은 학자들은 프로세스 중심의 정보 시스템 분석, 설계 기법에 문제점이 있다고 생각하게 되었고, 진정 기업 정보시스템의 핵심은 데이터(정보)를 어떻게 하면 중복 없이 정확하게 유지 관리할 수 있을까에 대한 보다 근본적인 안을 제시하게 되었다. 기업의 경영 정보 시스템의 근본적인 문제가 설계나 개발의 문제보다는 정확한 업무 파악이 선결돼야 한다는 결론에 이르러 보다 현실적인 관계형 데이터베이스나 개체 관계 모델링 기법(ERD:Entity Relationship Diagram)이 발전하게 되었다.

기본 개념

모델링

모델링(Modeling)은 현실 세계에 있는 사람, 사물, 개념 등을 단순화 표현하는 것이다. 모델링은 추상화, 단순화, 명확화로 세가지 특징으로 나뉜다. 추상화(Abstraction)는 복잡한 상황을 간결하고 명확하게 핵심 위주로 단순화가 목적이며, 구체적인 상황은 되도록 생략하고, 핵심 요소와 원리만 추구하는 것이다. 단순화(simplification)는 복잡한 현실 세계를 약속된 규약이나 제한된 표기법이나 언어로 표현하여 쉽게 이해할 수 있도록 하는 것을 말한다. 명확화(clarification)란 누구나 이해하기 쉽도록 대상에 대한 애매모호함을 제거하고 보다 정확하게 기술하는 것을 의미한다.

ER 모델

ER 모델(Entity Relation Model)은 데이터베이스를 구축하기 위해, 먼저 구축하고자 하는 데이터 베이스의 목적에 맞도록 현실 세계에 존재하는 많은 데이터들을 개념적으로 파악한 후 논리적으로 체계화하여 정리하고, 최종적으로 이를 기반으로 하여 데이터베이스를 구현하는데 현실 세계에 존재하는 객체들과 그들 간의 관계를 개념적으로 변환하여 표현하기 위해 ER 모델이 사용된다. 데이터 모델링에 있어서 개념 모델링에 사용되고 있다. ER 모델의 기본적 구성요소는 개체, 개체 간의 관계, 개체를 구성하는 속성 등으로 구성되어 있다.

개체

개체(entity)는 현실 세계에서 조직을 운영하는 데 꼭 필요한 사람이나 사물과 같이 구별되는 모든 것을 의미한다. 즉, 개체는 저장할 만한 가치가 있는 중요 데이터를 가지고 있는 사람이나 사물 등이며, 개념적 모델링을 하는 데 가장 중요한 요소다. 예를 들어 중요 데이터를 가지고 있고 꼭 필요한 사람인 고객과, 꼭 필요한 사물인 책이 현실 세계의 서점을 개념적으로 모델링하여 얻을 수 있는 개체가 된다. 개체는 사람과 사물처럼 물리적으로 존재하는 것만을 의미하지는 않는다. 개념이나 사건처럼 개념적으로만 존재하는 것도 개체가 될 수 있다. 예를 들어 학교 운영에 필요한 데이터를 가지고 있는 학과나 과목이 물리적으로 존재하지 않지만 반드시 필요한 개념이기 때문에 개체가 될 수 있는 것이다. 개체는 다른 개체와 구별되는 이름을 가지고 있고, 각 개체만의 고유한 특성이나 상태, 즉 속성을 하나 이상 가지고 있다. 개체를 고유의 이름과 속성들로 정의한 것을 개체 타입(entity type)이라 한다. 개체를 구성하고 있는 속성이 실제 값을 가짐으로써 실체화된 개체를 개체 인스턴스(entity instance) 또는 개체 어커런스(entity occurrence)라 한다. 고객 개체 타입을 구성하는 각 속성에 구체적인 값을 가지는 개체 인스턴스가 여러 개 존재할 수 있다. 특정 개체 타입에 대한 개체 인스턴스들을 모아놓은 것을 개체 집합(entity set)이라 한다. 데이터베이스에서 실제로 저장하고 관리하는 것이 이 개체 인스턴스들의 모임인 개체 집합이라 할 수 있다. 개체와 속성은 파일 구조에서의 레코드(record)와 필드(field) 용어에 대응된다. 그리고 개체 타입은 레코드 타입(record type)에, 개체 인스턴스는 레코드 인스턴스(record instance)에 대응된다. E-R 다이어그램에서는 개체를 사각형으로 표현하고 사각형 안에 개체의 이름을 표기한다.

속성

속성(attribute)은 개체가 가지고 있는 고유의 특성이다. 속성은 자체만으로는 의미가 없지만 관련 있는 속성들을 모아 개체를 구성하면 하나의 중요한 의미를 표현할 수 있다. 속성은 일반적으로 의미 있는 데이터의 가장 작은 논리적 단위로 인식된다. E-R 다이어그램에서 속성은 타원으로 표현하고, 타원 안에 속성의 이름을 표기한다.

• 단일값 속성 및 다중값 속성 : 특정 개체를 구성하는 속성의 값이 하나면 단일 값 속성(single-valued attribute)으로 분류한다. 예를 들어 고객 개체를 구성하는 이름·적립금 등의 속성은 한 명의 고객 인스턴스에 대해 하나의 값만 가지므로 단일 값 속성이다. 이와 달리 속성이 값을 여러 개 가질 수 있으면 다중 값 속성(multi-valued attribute)으로 분류한다. 고객 개체를 구성하는 연락처 속성은 한 명의 고객 인스턴스에 대해 집 전화번호와 휴대폰 전화번호 등 값을 여러 개 가질 수 있으므로 다중 값 속성이다. 책 개체를 구성하는 저자 속성도 한 권의 책 인스턴스에 저자가 여러 명일 수 있기 때문에 다중 값 속성으로 분류한다. 다중 값 속성은 이중 타원으로 표현한다.
• 단순 속성 및 복합 속성 : 단순 속성(simple attribute)은 의미를 더는 분해할 수 없는 속성이다. 즉, 단순 속성의 값은 의미가 하나다. 고객 개체를 구성하는 적립금 속성은 의미가 더는 분해되지 않기 때문에 단순 속성이 된다. 책 개체를 구성하는 이름·ISBN·가격 등의 속성도 의미를 나눌 수 없으므로 단순 속성으로 분류한다. 반면, 복합 속성(composite attribute)은 의미를 분해할 수 있어 값이 여러 개의 의미를 포함한다. 고객 개체를 구성하는 주소 속성은 도·시·동·우편번호 등으로 의미를 나눌 수 있다. 고객 개체의 생년월일 속성도 연·월·일로 의미를 세분화할 수 있으므로 복합 속성이다. 복합 속성은 단순 속성이 여러 개 모여 만들어진 속성으로 볼 수 있다. 하지만 일반적으로 주소나 생년월일 속성은 값을 전체 단위로 입력하거나 검색하고 의미를 세부적으로 나누지 않는다. 그러므로 주소나 생년월일 속성은 하나의 단순 속성으로 처리하는 것도 괜찮다.
• 유도 속성 : 값이 별도로 저장되는 것이 아니라 기존의 다른 속성의 값에서 유도되어 결정되는 속성을 유도 속성(derived attribute)으로 분류한다. 책 개체를 구성하는 가격과 할인율 속성으로 계산되는 판매가격 속성이 유도 속성이다. 그리고 판매가격 속성을 계산하는 데 사용되는 가격과 할인율 같은 속성을 저장 속성(stored attribute)이라고 한다. 저장 속성인 출생연도로부터 나이 속성을 유도하는 것도 이 예에 속한다. 실제로 값을 저장하고 있는 것은 저장 속성이고 유도 속성은 필요할 때마다 계산되므로 값을 따로 저장할 필요가 없다. 유도 속성은 E-R 다이어그램에서 점선 타원으로 표현한다.
• 널 속성 : 널(null) 값은 데이터베이스에서 여러 가지로 중요한 의미를 지니므로 의미를 정확히 이해해야 한다. 널 값은 아직 결정되지 않거나, 모르는 값(unknown value)을 의미한다. 또는 해당되는 값이 없는, 즉 존재하지 않는 값의 경우도 널 값이라 한다. 이처럼 널 값은 값을 아직 갖지 않은 것이므로 공백(blank)이나 0(zero)과는 다르다. 널 값이 허용되는 속성을 널 속성(null attribute)이라 한다. 한 명의 고객 개체 인스턴스의 등급 속성 값이 널이라면 고객의 등급이 아직 결정되지 않았음을 의미한다. 또 고객 개체 인스턴스의 취미 속성이 널 값이면 가입 시 고객이 취미를 입력하지 않았음을 의미한다. 다른 예로, 사원 개체를 구성하는 병역 속성은 사원 개체 인스턴스의 성별이 여자인 경우에 해당 사항이 없으므로 널 값을 가질 수밖에 없다.
• 키 속성 : 개체를 구성하는 속성들 중에서 특별한 역할을 하는 속성이 있는데 바로 키 속성(key attribute)이다. 모든 개체 인스턴스의 키 속성 값이 다르므로 키 속성은 개체 집합에 존재하는 각 개체 인스턴스들을 식별하는 데 사용한다. 고객 개체의 고객아이디 속성은 고객마다 다르기 때문에 고객아이디가 고객 개체의 키 속성이 될 수 있다. 책 개체에서는 ISBN 속성이 키 속성으로 사용될 수 있다. 키 속성은 간단히 키라고도 한다. 어떤 경우에는 키를 둘 이상의 속성들로 구성하기도 한다. 예를 들어 고객 개체에 고객아이디 속성이 없는 경우에는 고객명과 집전화번호 속성을 조합하여 키를 구성할 수도 있다. 함께 사는 가족의 집전화번호가 같을 수는 있지만 가족들 중에서 이름이 같은 사람은 없으므로 고객명과 집전화번호 속성을 조합하면 고객들을 구별할 수 있기 때문이다. 개체 타입을 정의할 때 중요한 제약조건은, 키 속성의 값이 개체 인스턴스마다 달라서 이 값으로 개체 인스턴스를 식별할 수 있어야 한다는 것이다. 만약 키 속성으로 적합한 속성이 여러 개면 이 중 하나를 키로 사용하면 된다. 키 속성은 E-R 다이어그램에서 밑줄을 그어 표현한다.

관계성

하나의 개체는 다른 어떤 개체와 연관을 가질 수 있는데 그것을 관계(Relationship)라 한다. 개체들 사이에서 존재하는 연관이나 연결로서 두 개 이상의 관계 타입들 사이의 사상이며 개체 타입이 동일하거나 서로 다른 개체 타입일 수 있다. 관계 집합은 동질 관계들의 집합이다. 관계 타입은 동질 관계들의 틀로서 하나의 관계와 구분해야 한다.

• 1:1 관계: 하나의 개체가 하나의 개체만이 관계를 맺는 경우를 뜻한다. 예를 들어, 각 사원에 대하여 한 pc가 배정받는 경우 1 대 1관계이다. 각 pc는 한 명의 사원만이 사용한다면 성립이 된다.
• 1:N 관계: 하나의 개체가 여러 개의 개체 타입이 관계를 맺는 경우를 뜻한다. 현실 세계에서 학과와 학생의 관계를 예를 들 수 있다. 한 특정 학과에 대해 여러 학생이 전공학과로 선택할 수 있고, 학생은 반드시 하나의 전공학과를 선택하게 됨에 있다.
• N:M관계: 관계에 참여하는 각 개체가 관계를 맺는 다른 여러 개체에 대하여 관계가 성립하고, 이것은 양쪽의 개체 타입에서 마찬가지이다. 학생들이 과목을 수강 신청하는 경우, 학생들은 여러 과목을 신청하게 되고, 과목은 여러 학생들이 존재하게 되는 것을 예로 들 수 있다.

관계형 데이스베이스

관계형 데이터베이스(RDB : relational database)는 데이터 항목 간에 관계가 존재할 때 데이터 항목들의 모음을 열과 행으로 이루어진 테이블로 구성된다. 구성된 테이블이 다른 테이블들과 관계를 맺고 모여있는 집합체로 이해할 수 있다. 테이블의 각열은 특정 종류의 데이터를 수록하며 필드는 속성의 실제 값을 저장한다. 테이블의 행은 한 객체 또는 개체와 관련된 값들의 모음을 나타낸다 테이블의 각 행은 기본키(primary key)라 부르는 고유 식별자로 표시하며 여러 테이블에 있는 외래키(foreign key)를 사용하여 테이블끼리의 상호 연결을 할 수도 있다. 데이터베이스 테이블 자체를 재구성하지 않고도 여러 방법으로 표현 가능하며 쉽게 확장할 수 있는 장점을 가지고 있다.

필요성

데이터 모델링이 중요한 이유는 파급효과(Leverage), 복잡한 정보 요구사항의 간결한 표현(Conciseness), 데이터 품질(Data Quality)로 정리할 수 있다.

파급효과

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

간결한 표현

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

데이터 품질

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

유의점

데이터 품질의 문제가 야기되는 중대한 이유 중 하나가 바로 데이터 구조의 문제이다. 중복 데이터의 미정의, 데이터 구조의 비즈니스 정의의 불충분, 동일한 성격의 데이터를 통합하지 않고 분리함으로써의 나타나는 데이터 불일치 등의 데이터 구조의 문제로 인한 데이터 품질의 문제는 치유하기에 불가능한 경우가 대부분이다. 데이터 모델링을 할 때 유의점은 다음과 같다.

• 중복(Duplication) : 데이터 모델은 같은 데이터를 사용하는 사람, 시간, 장소를 파악하는 데 도움을 준다. 이러한 지식 응용은 데이터베이스의 여러 장소에 같은 정보를 저장하는 잘못을 하지 않도록 한다.
• 비 유연성(Inflexibility) : 데이터 모델을 어떻게 설계했느냐에 따라 사소한 업무 변화에도 데이터 모델이 수시로 변경됨으로써 유지 보수의 어려움을 가중시킬 수 있다. 데이터의 정의를 데이터의 사용 프로세스와 분리함으로써 데이터 모델링은 데이터 혹은 프로세스의 작은 변화가 애플리케이션과 데이터베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄인다.
• 비 일관성(Inconsistency) : 데이터의 중복이 없어도 비 일관성이 발생하는데, 예를 들면 신용 상태에 갱신 없이 고객의 납부 이력정보를 갱신하는 것이다. 개발자가 다른 데이터와 모순된다는 고려 없이 일련의 데이터를 수정할 수 있기 때문이다. 데이터 모델링을 할 때 데이터와 데이터 간의 상호 연관관계에 대한 명확한 정의는 이러한 위험을 사전에 예방할 수 있게 해준다.

단계

특별히 데이터 모델은 데이터베이스를 만들어내는 설계서로서 분명한 목표를 가지고 있다. 현실세계에서 데이터베이스까지 만들어지는 과정은 시간에 따라 진행되는 과정으로서 추상화 수준에 따라 개념적 데이터 모델, 논리적 데이터 모델, 물리적 데이터 모델로 정리할 수 있다. 처음 현실세계에서 추상화 수준이 높은 상위 수준을 형상화하기 위해 개념적 데이터 모델링을 전개한다. 개념적 데이터 모델은 추상화 수준이 높고 업무 중심적이고 포괄적인 수준의 모델링을 진행한다. 참고로 EA 기반의 전사적인 데이터 모델링을 전개할 때는 더 상위 수준인 개괄적인 데이터 모델링을 먼저 수행하고 이후에 업무영역에 따른 개념적 데이터 모델링을 전개한다. 엔터티(Entity)중심의 상위 수준의 데이터 모델이 완성되면 업무의 구체적인 모습과 흐름에 따른 구체화된 업무 중심의 데이터 모델을 만들어 내는데 이것을 논리적인 데이터 모델링이라고 한다. 논리적인 데이터 모델링 이후 데이터베이스의 저장 구조에 따른 테이블스페이스 등을 고려한 방식을 물리적인 데이터 모델링이라고 한다.

개념-논리-물리데이터 모델

데이터 모델링	내용
개념적 데이터 모델링	추상화 수준이 높고 업무중심적이며 포괄적인 수준의 모델링을 진행한다. 전사적 데이터 모델링과 EA 수립 시 많이 이용한다.
논리적 데이터 모델링	시스템으로 구축하고자 하는 업무에 대해 키, 속성, 관계 등을 정확하게 표현한다. 재사용성이 높다.
물리적 데이터 모델링	실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격을 고려하여 설계한다.

요구 사항 분석

데이터베이스를 사용할 주요 사용자를 결정하고, 사용자가 수행하는 업무를 분석하는 단계로 업무에 관련된 문서를 분석하거나 면담, 설문 조사 등의 방법을 이용해 요구 사항을 파악 후 분석 결과를 요구 사항 명세서로 작성한다. 업무 분석에 있어 관련 분야에 기본적 지식과 상식을 요구하게 되는데 문서를 이용하여 데이터로 관리되는 항목들을 파악하고 세부적인 프로세스 정의를 위해 담당자와의 인터뷰를 진행하여 기본 지식에 대한 도움을 얻는다. 업무분석할 회사에 순수한 업무 자체와 업무 프로세스에 초점을 두고 분석하고 현재 업무를 어떤 방법으로 효율적으로 했으면 좋겠다는 요구 사항을 조사한다. 요구 사항의 분석 및 파악은 처음 단계에서 끝내는 것이 아닌 개발하면서도 필요한 단계이다. 개발을 하며 요구 사항에 대한 솔루션을 정교화 한다면 성공적인 개발에 가까워지기 때문이다.

개념적 설계

핵심 개체와 그들 간의 관계를 발견하고, 그것을 표현하기 위해 개체 관계 다이어그램을 생성하는 것으로 조직과 데이터 베이스 사용자에게 전반적인 구조를 쉽게 표현하여 어떠한 데이터가 중요한지를 나타내기 위해서 사용된다. 또한 어떠한 자료가 중요하고, 어떠한 자료가 유지되어야 하는지 결정하는 내용도 포함된다. 기초 모델링은 전체 시스템의 골격을 잡고 구체적인 모델 상세화 작업을 시작하기 전 시스템의 큰 그림을 파악할 수 있는 모델링 과정이므로 해당 단계에서 정확한 핵심 개체들을 파악하는 것이 중요하다. 데이터 모델링 과정이 전 조직에 걸쳐 이루어진다면, 그것은 전사적 데이터 모델(Enterprise Data Model)이라고 불리며 EA(Enterprise Architecture)수립 시에도 많이 이용된다. 개념적 모델링을 통해 조직의 데이터 요구를 공식화하는 것은 두 가지의 중요한 기능을 지원한다. 첫째, 개념 데이터 모델은 사용자와 시스템 개발자가 데이터 요구 사항을 발견하는 것을 지원한다. 개념 데이터 모델은 추상적이다. 그렇기 때문에 그 모델은 상위의 문제에 대한 구조화를 쉽게 하며, 사용자와 개발자가 시스템 기능에 대해서 논의할 수 있는 기반을 형성한다. 둘째, 개념 데이터 모델은 현 시스템이 어떻게 변형되어야 하는가를 이해하는데 유용하다. 일반적으로 매우 고립된(Stand Alone) 시스템도 간단하게 추상적 모델링을 통해서 좀 더 쉽게 표현되고 설명된다.

논리적 설계

데이터 모델링 프로세스의 입력 단계로써 비즈니스 정보의 논리적인 구조와 규칙을 명확하게 표현하는 기법 또는 과정이라 할 수 있다. 논리 데이터 모델링의 결과로 얻어지는 논리 데이터 모델은 데이터 모델링이 최종적으로 완료된 상태라고 정의할 수 있다. E-R 다이어그램으로 표현된 개념적 구조를 데이터베이스에 저장할 형태로 표현한 논리적 구조이며 물리적인 스키마 설계의 전 단계의 데이터 모델 상태를 나타낸다. 논리 데이터 모델의 상세화는 식별자 확정, 정규화, M:M 관계 해소, 참조 무결성 규칙 정의 등을 들 수 있으며, 추가적으로 이력 관리에 대한 전략을 정의하여 이를 논리 데이터 모델에 반영함으로써 데이터 모델링을 완료하게 된다. 논리적 설계에서 중요한 활동인 정규화(Normalization)를 통하여 논리 데이터 모델의 일관성을 확보하고 중복을 제거하여 속성들이 가장 적절한 엔터티에 배치되도록 함으로써 좀 더 신뢰성있는 데이터 구조를 얻는데 목적이 있다.

물리적 설계

물리 모델링은 논리 모델링 과정에서 완성된 데이터 모델을 실 데이터베이스에 맞게 적용하는 과정을 의미한다. 논리 모델명에서 작성된 데이터 타입들을 실제 데이터베이스에서 지원하는 타입에 맞게 변환하고, 데이터 관의 관계에서 구현되기 어려운 부분을 적절한 형태로 변환하는 과정을 말한다. 환경에 의한 차이를 제외한 전체 모델링 구조가 논리 모델링과 동일해야 하며, 물리 모델링 과정에서 논리 모델링 과정에 없던 (데이터베이스 환경으로 인해 생성되는 테이블이 아닌) 새로운 개념의 테이블이 생성되거나, 새로운 관계가 추가돼서는 안된다. 계층적 데이터베이스 관리 시스템 환경에서는 데이터베이스 관리자가 물리적 스키마를 설계하고 구현하기 위해서 보다 많은 시간을 투자하여야 한다. 관계형 데이터 베이스의 등장으로 계층적 데이터 베이스 관리 시스템이 중요로 하는 하드웨어의 관계(물리 데이터베이스)가 개념 및 논리 데이터베이스 설계로 이동하고 있다. 관계형 데이터베이스 관리 시스템을 사용하는 조직에서는 데이터베이스 관리자가 잘 유지해야 하는 데이터 항목의 발견과 데이터 항목 간에 존재하는 논리 관계를 이해하는데 더 많은 시간을 할애한다. 관계형 데이터베이스 관리 시스템의 출현으로 인하여 물리적 데이터베이스 설계와 관련된 문제들은 많은 부분 관계형 데이터베이스 관리 시스템 소프트웨어에서 처리되고 있다.

원칙

모델링의 방법론, 기법, 도구와 같은 개발 보조 수단 사용 없이 시스템이 잘 설계될 수 없을 거라 생각하게 된다. 하지만 과거 수많은 시스템들은 이러한 개발 보조 기구의 사용 없이 성공적으로 개발됐다. 프로젝트의 어려움 정도 또는 도구와 기술에 상관없이 좋은 설계를 포함한 훌륭한 시스템 개발은 해결해야 하는 문제점의 구체화, 시스템 구축, 구현을 통한 단계로부터 시작된다. 시스템의 개발되기 위해서는 요구 사항을 완전하고 정확하게 식별, 분석해야 하고, 논리 데이터 모델링은 조직이 사용하는 물리적 설계 구조에 관계없이 기업의 비즈니스에 존재하는 데이터의 명확한 구조 및 정의를 제시해야 한다. 사용자 관점에서 바라보는 정보구조를 개념화하고 추상화시킨 데이터의 구조이기에 다음의 설명할 세 가지 최우선 원칙이 데이터 모델링의 접근 방식을 성공적으로 이끄는 토대이다.

커뮤니케이션의 원칙

커뮤니케이션의 원칙(Communication Principle)이란 최종 사용자 및 이해 당사자들에게 시스템의 지향점을 분명하게 설명하기 위함을 전제로 한 원칙이다. 요구 사항을 모든 사람들이 이해할 수 있도록 명확하게 공표됨은 물론 최종 사용자 지향적으로 분명하게 파악되는 수준으로 작성되어야 한다. 논리 데이터 모델링의 주목적은 최종 사용자 데이터에 대한 뷰(View)를 개념화하고 추상화하여 시스템 설계자들에게 전달하는 것이다. 물론 커뮤니케이션의 원칙이 최종 사용자들에게 국한되는 것은 아니다. 시스템 분석가(System Analyst)에는 사용될 정확한 데이터의 구조 및 데이터가 갖는 업무의 규칙 이해를 도우며 데이터 베이스 관리자(DBA, database administrator)에 있어 논리 데이터 모델의 구조 물리 스키마(schema)의 차이점을 이해하고 최종 사용자에게 데이터의 제공, 시스템 분석가에게는 물리 스키마의 제공을 위한 데이터의 구조의 이해를 돕는다. 타 프로젝트에서 작업하는 분석가일 경우, 관련 프로젝트가 데이터를 어떻게 정의하고 있는지를 알아낼 수 있으며, 인터페이스가 개발되고 데이터가 애플리케이션 또는 시스템 간에 공유되기 위한 데이터 구조 및 업무 규칙의 이해를 돕는다. 논리 데이터 모델의 문서와 그림들 작성할 때 그 목적을 명확히 하여 모델을 보는 사람들에게 기술적으로 알아보기 힘든 혼란을 주어서는 안된다. 이 와 같이 명확한 정의를 통해 개발 관련자와 최종 사용자 간의 요구 사항이 전달이 정확히 전달되도록 해야 한다.

모델링 상세화 원칙

모델링 상세화의 원칙(Granularity Principle)은 데이터의 본질과 잠재적으로 사용을 이해할 수 있을 만큼 상세화되어야 한다는 원칙이다. 복잡한 구조는 요소적인 부분들로 쪼개야 하며 불필요한 구조와 중복을 제거함으로 상세화한다. 설계의 분석 단계(논리 데이터 모델)을 위한 상세 수준이 다른 단계(물리 데이터 모델)에서 선택된 수준만큼 상세화되어야 좋은 설계를 의미한다. 많은 모델러들이 겪는 논리적 데이터 모델에서 물리적 데이터 모델로의 이동이 분해 과정이라 오해하는데 사실 논리 데이터 모델에서 물리 데이터 모델로의 이동은 분해가 아니라 보통 수준의 상세화에서 발생하는 변환이다.

논리적 표현 원칙

논리적 표현 원칙(Logical Representation Principle)은 조직의 데이터에 대한 논리적 측면을 최대화하여 표현하고, 모델은 물리적 제약 조건 없이 비즈니스를 그대로 반영해야 한다는 원칙이다. 즉, 논리 데이터 모델은 특정 아키텍처, 기술 또는 제품과 독립적이어야 한다는 것이다. "요구의 이해 부족"은 최종 사용자들이 항상 시스템 개발자들에게 가지는 주요 불만 사항이다. 또한 요구 사항의 분석 단계와 논리적 설계를 대수롭게 여기지 않아 성급하게 물리적 설계 단계로 들어갈려 하는 분석가들의 성향으로 인해 애플리케이션에 대한 빈약한 문서화의 중요 원인이 되었다. 논리적 설계와 물리적 설계를 구별하지 못하면 추구하고자 하는 물리적 선택 사항을 제한하거나 잘못된 방향으로 진행된다. 구체적으로 문제에 대한 솔루션을 섣불리 구체화하는 것은 잘못된 것이다. 문제를 해결할 수 있는 데이터를 확보하여 문제로부터의 솔루션을 발견할 수 있기 때문이다. 즉, 개발 과정에서 발생할 수 있는 모든 것을 알 수 없기 때문에 솔루션의 구체화전에 문제와 요구 사항에 중점을 두어 충분한 생각을 한 후에 솔루션에 대한 좋은 생각이 표현화되었을 때 그것을 기록하여 논리 설계 다음 물리 설계자에게 전달해야 한다는 것이다.

요소

데이터 모델링을 구성하는 중요한 개념 세 가지가 있는데 이것은 데이터 모델에 대한 이해의 근간이 된다.

• 업무가 관여하는 어떤 것(Things)
• 어떤 것이 가지는 성격(Attributes)
• 업무가 관여하는 어떤 것 간의 관계(Relationships)

이 세 가지는 데이터 모델링을 완성해 가는 핵심 개념으로서 결국 엔터티, 속성, 관계로 인식되는 것이다. 사물이나 사건 등을 바라 볼 때 전체를 지칭하는 용어를 어떤 것(Things)이라 하고, 그 어떤 것이 가지는 세부적인 사항을 성격(Attributes)이라고 할 수 있다. 또한 각각의 어떤 것은 다른 어떤 것과 연관성을 가질 수 있는데 이것을 관계(Relationship)라고 표현한다. 이 세상의 모든 사람, 사물, 개념 등은 어떤 것, 어떤 것 간의 관계, 성격의 구분을 통해서 분류할 수 있다. 바로 이러한 원리, 즉 자연계에 존재하는 모든 유형의 정보들을 세 가지 관점의 접근 방법을 통해 모델링을 진행하는 것이다. 데이터 모델링에서는 이 세 가지 개념에 대해서 단수와 복수의 개념을 분명하게 구분하고 있고 실제로 데이터 모델링을 할 때 많이 활용되는 용어이다.

용어의 구분정의

개념	복수/집합개념 타입/클래스	개별/단수개념 어커런스/인스턴스
어떤 것(thing)	엔터티 타입(entity type)	엔터티(entity)
	엔터티(entity)	인스턴스(instance), 어커런스(occurrence)
어떤 것간의 연관 (association between things)	관계(relationship)	페어링(pairing)
어떤 것의 성격 (characteristic of a thing)	속성(attribute)	속성값(attribute value)

어떤 것의 전체를 지칭하는 것을 영문으로 엔터티 세트(Entity Set), 엔터티 타입(Entity Type)의 복수의 의미를 가지는 세트(Set)나 타입(Type)을 포함하여 표현하기도 한다. 그래서 엔터티 타입으로 표현하기도 하는데 실제 실무 현장에서는 엔터티로 짧게 명명한다. 즉 엔터티를 어떤 것에 대한 집합을 명명하여 지칭한다. 어떤 것에 대한 개별 지칭으로 엔터티가 단수명사로서 단어의 의미가 있지만, 엔터티를 집합개념으로 사용하는 경우에는 개별요소에 대해서는 인스턴스/어커런스를 단수의 개념으로 사용하여 부른다. 관계(Relationship)도 이를 복수로 통칭하여 관계로 표현하고 관계에 포함된 개별 연관성을 패어링이라고 부르기도 한다. 그러나 패어링이라는 용어는 실제 데이터 모델링을 할 때는 잘 사용하지 않으며 그냥 일반적으로 단수든 복수든 관계라고 표현하는 경우가 많다. 어떤 것이 가지는 성격(Attribute)에 대한 집합개념이 속성이고 그 안에 개별 값들을 속성값으로 구분하여 복수와 단수의 개념으로 구분할 수 있다. 본 가이드에서는 현장 통용성을 반영하여 국내외적으로 가장 범용적으로 명명되고 있는 용어인 엔터티를 집합의 개념으로 지칭하고 인스턴스를 단수의 개념으로 명명하도록 한다. 데이터 모델의 핵심 요소인 이 세 가지를 이용하여 일정한 표기법에 의해 데이터 모델을 만들어 낼 수 있다. 다음은 좋은 데이터 모델을 만들기 위해 고려될 평가 요소이다. 완정성, 중복 배제, 업무 규칙, 데이터 재사용, 의사 소통, 통합성이 있다.

• 완전성(Compeleteness): 업무에서 필요로 하는 모든 데이터가 데이터 모델에 정의되어 있어야 한다는 것이다. 데이터 모델을 검증하기 위해 가장 먼저 확인해야 할 부분이며, 이 기준이 충족되지 못한다면 다른 평가 기준도 의미가 없어진다.
• 중복 배제(None-Redundancy): 하나의 데이터베이스 내에 동일한 사실은 반드시 한 번만 기록하여야 한다는 것으로 예를 들어, 하나의 테이블에서 '나이'속성과 '생년월일'속성이 동시에 존재하면 이것이 데이터 중복이라 볼 수 있다. 이러한 형태의 데이터 중복 관리로 인하여 여러 가지 바람직하지 않은 형태로 데이터 관리 비용을 지불할 수 있다.
• 업무 규칙(Business Rules): 데이터 모델에서 매우 중요한 요소 중 하나가 데이터 모델링 과정에서 도출되고 규명되는 수만은 업무규칙을 데이터 모델에 표현하고 이를 해당하는 데이터 모델을 활용하는 모든 사용자가 공유할 수 있도록 제공하도록 하는 것이다. 데이터 아키텍처에서 언급되는 논리 데이터 모델에서 이러한 요소들이 매우 중요하다.
• 데이터 재사용(Data Reusability): 데이터의 통합성과 독립성에 대해서 충분히 고려가 된다면 데이터 재사용성을 향상시킬 수 있는 것이다. 데이터 재사용을 높임으로써 시스템 유지 보수 뿐 아니라, 신규 시스템을 구축하는 데에 있어도 매우 유리하게 작용될 수 있다. 데이터가 애플리케이션에 대해 독립적으로 설계되어야만 재사용성을 향상시킬 수 있으며, 최대한 단순하게 적은 데이터로 분류하는 것이 확장성과 유연성을 고려했을 때 좋은 방법이다.
• 의사소통(Communication): 데이터 모델의 역할 중 중요한 것이 데이터 모델의 의사소통 역할이다. 대상으로 하는 업무를 데이터 관점에서 분석하고 설계하는 과정에서 많은 업무 규칙들이 도출된다. 그러한 업무 규칙들에 대해서 해당 정보 시스템을 운용, 관리하는 많은 관련자들이 설계자가 정의한 업무 규칙들을 동일한 의미로 받아들이고 정보시스템을 활용할 수 있도록 의사소통의 도구로써 역할을 하는 것이 데이터 모델이다.
• 통합성(Integration): 기업들이 과거부터 정보시스템을 구축해 왔던 방법은 개별 업무별로의 단위 정보시스템을 구축하여 현재까지 유지 보수를 해오고 있는 것이 보통이다. 점진적인 확장과 보완의 방법으로 정보시스템을 구축해 왔기 때문에 동일한 성격의 데이터임에도 불구하고 전체 조직 관점에서 보면 여러 곳에서 동일한 데이터가 존재하기 마련이다. 특히 이러한 데이터 중에서도 고객, 상품 등과 같이 마스터 성격의 데이터들이 분할되어 관리됨으로 인해 전체 조직 관점에서 데이터 품질, 관리, 활용 관점에서 많은 문제점들이 나타나고 있는 것이 현실이다. 따라서 데이터 모델링을 진행하는 동안 동일한 성격의 데이터를 한 번만 정의함으로써 공유 데이터에 대한 구조를 여러 업무 영역에서 공동으로 사용하기 용의하도록 해야 한다.

참고자료

• 〈데이터 모델링〉, 《위키백과》
• syp, 〈데이터모델링〉, 《인코덤》, 2020-05-06
• 〈데이터모델링의 개요〉, 《티스토리》, 2018-08-02
• axiom, 〈권순용의 데이터모델링 이야기〉, 《구루비》, 2014-03-11
• 나는연어다, 〈DAsP - 데이터 모델링 이해 (데이터 모델링 개요)〉, 《티스토리》, 2017-11-10
• 비니아니아빠 Augustine™, 〈데이터 모델링(데이터 모델링 이해)〉, 《티스토리》, 2018-06-06
• jihoson94, 〈(SQLD) 데이터 모델링의 이해〉, 《velog》, 2020-01-13
• 원모어찬스, 〈1-1-1(10) 좋은 데이터 모델의 요소〉, 《네이버 블로그》, 2019-11-22
• 열정적인 Logan Moon, 〈(SQL) 데이터 모델의 이해 - TIL -〉, 《티스토리》, 2020-05-18
• Tigercow.Door, 〈(DB 이론) #3_데이터 모델링(Data Modeling)〉, 《티스토리》, 2020-01-17
• 공구일일, 〈24.ER모델〉, 《네이버 블로그》, 2009-07-16
• 예비개발자, 〈엔티티-관계 모델(E-R Model) 1 - 엔티티와 속성〉, 《네이버 블로그》, 2018-03-12
• TableTurner, 〈카디널리티 비율(1:1 , 1:N , M:N 관계) (in오용철의 데이터모델링)〉, 《티스토리》, 2017-07-19
• 〈관계형 데이터베이스란 무엇입니까?〉, 《Amazon》
• 끔맹, 〈(Database) 업무 및 요구사항 분석〉, 《티스토리》
• 김연희 작가, 〈데이터베이스 개론 : 기초 개념부터 빅 데이터까지 큰 흐름이 보이는 데이터베이스 교과서〉, 《한빛아카데미㈜》, 2013-06-30
• admin, 〈데이터 모델의 이해〉, 《데이터온에어》, 2021-02-15

같이 보기

• 관계형 데이터베이스
• 데이터
• 데이터베이스
• 릴레이션
• ER 모델

이 데이터 모델링 문서는 데이터에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.

개발 : 프로그래밍, 소프트웨어, 데이터 □■⊕, 솔루션, 보안, 하드웨어, 컴퓨터, 사무자동화, 인터넷, 모바일, 사물인터넷, 게임, 메타버스, 디자인 데이터 ACID • CRUD • CSV • DAO • DB • DBMS • DB 명령어 • DCL • DDL • DML • DTO • ERD • ETL • JDBC • LOD • MDM • ODBC • RDBMS • RDF • SQL • 가상 데이터베이스 • 관계형 데이터베이스 • 그래프 • 기본키(PK) • 내부조인 • 널 • 노드 • 다이어그램 • 대리키 • 대체키 • 데이터 • 데이터댐 • 데이터마트 • 데이터 모델링 • 데이터뱅크 • 데이터베이스(DB) • 데이터베이스 언어 • 데이터 사이언스 • 데이터 사전 • 데이터 웨어하우스 • 데이터 정의어(DDL) • 데이터 제어어(DCL) • 데이터 조작어(DML) • 데이터 클러스터 • 데이터 토큰 (문자열) • 데이터 통합 • 덱 • 디비서버 • 라이트조인 • 락 • 레코드 • 레프트조인 • 로그 • 로그파일 • 로깅 • 롤백 • 리두로그 • 릴레이션 • 마스터데이터 • 마스터데이터관리(MDM) • 마이그레이션 • 메타데이터 • 배열 • 뷰 • 빅데이터 • 서브쿼리 • 수퍼키 • 순차리스트 • 스키마 • 스택 • 슬로우쿼리 • 엔티티 • 역정규화 • 연결리스트 • 외래키(FK) • 외부조인 • 인덱스 • 인덱싱 • 인젝션 • 자료구조 • 정규화 • 정보 • 조인 • 커밋 • 쿼리 • 큐 • 키 • 타깃 • 테이블 • 튜플 • 트랜잭션 • 트리 • 트리거 • 티비마이그레이터 • 풀조인 • 프로시저 • 필드 • 해시 • 해시맵 • 해시태그 • 해시테이블 • 해시함수 • 해싱 • 후보키 데이터베이스 관리 시스템 (DBMS) 관계형 데이터베이스 관리 시스템(RDBMS) • 노에스큐엘(NoSQL) • 데이터베이스 관리 시스템(DBMS) • 더비 • 디비투(DB2) • 레디스 • 마리아디비(MariaDB) • 마이에스큐엘(MySQL) • 몽고디비 • 빅테이블 • 사이베이스 • 선디비 • 알티베이스 • 액세스 • 에스큐엘(SQL) • 에스큐엘라이트(SQLite) • 에이치베이스 • 엠에스에스큐엘(MS-SQL) • 오라클(Oracle) • 인터베이스 • 인포믹스 • 카산드라 • 카우치디비 • 큐브리드 • 티베로 • 파이어버드 • 포스트그레스큐엘(PostgreSQL) • 하이퍼테이블 DB 명령어 alter • array • create • delete • drop • from • full join • grant • inner join • insert • join • left join • null • order by • outer join • rename • revoke • right join • select • truncate • update • where 시스템 연계 API • CGI • EAI • ESB • JPA • RSS • SOA • SOAP • SSL • SSO • web3.js • XML • 디비투디비(DB-to-DB) • 레스트풀(RESTful) • 상호운용성 • 시스템 인터페이스 • 신디케이션 API • 오픈 API • 웹 API • 웹개방성 • 윈도우 API • 자바 API • 크롤링 • 프라이빗 API 위키 : 자동차, 교통, 지역, 지도, 산업, 기업, 단체, 업무, 생활, 쇼핑, 블록체인, 암호화폐, 인공지능, 개발, 인물, 행사, 일반