[DB] 데이터 모델과 모델링

안녕하세요. 바른 호랑이입니다.

이번 게시글에서는 데이터 모델링에 대하여 알아볼 예정입니다. 
모델은 모형, 축소형의 의미로 현실의 여러가지 개념과 현상들을 특정한 표기법에 맞춰 표현해놓은 모형으로 특정한 목적 달성을 위해 커뮤니케이션의 효율성을 극대화한 고급화된 표현방법이라고 할 수 있고, 모델을 만들어가는 일 자체를 모델링이라고 할 수 있으며, 모델링에 대한 보다 다양한 정의로는 아래와 같은 내용들이 있습니다.

 

1. 가설적 또는 일정 양식에 맞춘 표현(a hypothetical or stylized representation)

2. 복잡한 현실세계를 추상화, 단순화, 명확화하기 위해 일정한 표기법에 의해 표현하는 기법

 

모델링의 특징으로는 추상화, 단순화, 명확화가 있으며, 해당 개념들의 의미는 아래와 같습니다.

 

1. 추상화 : 현실세계를 일정한 형식에 맞춰 표현

2. 단순화 : 현실세계를 약속된 규약에 의해 제한된 표기법이나 언어로 표현하여 쉽게 이해할 수 있도록 하는 것

3. 명확화 : 애매모호함을 제거하고 정확하게 현상을 기술하는 것

 

모델링을 진행하는 과정에서 고려해야하는 관점은 3가지 있으며, 자세한 내용은 아래와 같습니다. 

 

1. 데이터 관점 : 업무가 어떤 데이터와 관련있는지 또는 데이터간의 관계는 무엇인지에 대해 모델링

2. 프로세스 관점 : 업무상 실제하고 있는 일은 무엇이고 무엇을 해야하는지를 모델링하는 방법

3. 데이터와 프로세스의 상관관점 : 일의 방법에 따라 데이터가 어떻게 영향을 받고 있는지 모델링하는 방법

 

위와 같은 모델링의 개념과 데이터의 개념이 결합된 개념을 데이터 모델링이라고 할 수 있으며, 데이터 모델과 데이터 모델링은 DB에 대한 이해와 SQL을 효율적으로 작성하기 위해서 필요한 핵심요소라고 할 수 있고, 아래와 같은 내용으로 데이터모델링을 요약할 수 있습니다. 

 

1. 업무에서 필요로하는 데이터를 시스템 구축 방법론에 의해 분석하고 설계하여 정보시스템을 구축하는 과정

2. 정보시스템 구축을 위한 데이터 관점의 업무 분석 기법

3. 현실세계의 데이터(what)에 대해 약속된 표기법으로 표현하는 과정

4. DB구축을 위한 구축, 설계 과정

 

데이터 모델링을 통해 구축된 데이터 모델은 아래와 같은 기능들을 제공할 수 있습니다.

 

1. 시스템 가시화 및 구조, 행동의 명세화

2. 시스템을 구축하는 구조화된 틀 제공 및 구충 중 결정된 사항들에 대한 문서화

3. 특정 목표에 따른 구체화된 표현방법 제공

 

이와 같은 데이터 모델링이 중요한 이유로는 파급효과, 요구사항에 대한 간결한 표현, 데이터 품질이 존재하며, 구체적인 내용은 아래와 같습니다.

 

1. 파급효과(Leverage)

: 시스템 개발과정에서는 서비스 및 프로그램의 품질을 평가하고 개발에 반영하기 위해서 단위, 통합, 시스템, 인수 테스트와 같은 다양한 테스트들이 수행되는데, 수많은 테스트들을 수행한 개발 후반부 단계에서 발생하는 데이터 변경은 엄청난 변경작업들을 발생시키게 되며, 이와 같은 변경작업들은 시스템 구축 프로젝트에서 큰 위험요소로 작용하기에 이를 사전에 방지할 수 있게 하는 데이터 설계는 매우 중요함.

2. 요구사항에 대한 간결한 표현(Conciseness)

: 데이터 모델은 추상화, 단순화, 명확화 과정을 거쳐 만들어지기에 업무에 필요한 핵심사항들을 간결하게 표현하고 있고, 이는 건축물에 있어서 설계도면과 비슷함. 데이터 모델을 통해 시스템의 이해관계자들은 정보요구사항을 공유하고 소통할 수 있으며, 이를 통해 애플리케이션 개발과 데이터 정합성 유지라는 목표들을 달성할 수 있음.

3. 데이터 품질(Data Quality)

: 조직은 자신들의 비전을 실현하고 추구해나가기 위해 필요한 데이터들을 DB안에 모으기에 데이터는 조직의 중요한 자산이며, 일반적으로 기간이 지날수록 희소성과 활용가치는 높아짐. 이는 새로운 비즈니스 기회의 발견과 직, 간접적으로 연관되며, 초기설계과정에서 중복 데이터 미정의, 비즈니스 정의의 불충분와 같은 문제들을 제대로 해결하지 않고 넘어가게되면 치유할 수 없는 경우가 많으므로 초기단계부터 데이터 품질을 확보하는 것은 중요함.

 

이처럼 중요한 데이터 모델링을 할때 유의해야하는 점들은 크게 3가지로 볼 수 있으며, 세부적인 내용은 아래와 같습니다.

 

1. 중복(Duplication)

: 같은 정보를 여러장소에 저장해서는 안됨.

2. 비유연성(Inflexibility)

: 데이터 정의와 사용 프로세스를 분리하여 업무 및 요구사항의 변화에 유연하게 대응할 수 있어야함.

3. 비일관성(Inconsistency)

: 데이터 간의 상호 연관 관계에 대한 명확한 정의를 통해 데이터 수정시에 발생할 수 있는 모순점들을 차단할 수 있어야함.(신용상태에 대한 갱신없이 고객의 납부 이력 정보를 수정한다면 모순이 발생할 수 있음)

 

DB를 만들어내는 설계서라는 분명한 목표를 가진 데이터 모델은 일반적으로 3가지 단계를 거쳐 만들어지게 되며, 시간과 추상화 수준에 따라 개념적, 논리적, 물리적 데이터 모델로 정리할 수 있습니다.

 

과 정	내 용
개념적 데이터 모델링	추상화 수준 높은 업무중심적이며, 포괄적인 수준의 데이터 모델링으로 전사적 데이터 모델링에 해당함. EA 수립시에 많이 사용하며, ERD를 활용하여 핵심 엔터티와 관계를 규명하고 표현함.
논리적 데이터 모델링	업무에 대해 Key, 속성, 관계 등을 정확하게 표현하며, 재사용성이 높음. 비즈니스 정보의 논리적 구조와 규칙을 명확하게 표현하는 모델링으로 정규화, 식별자 확정, M:M 관계 해소, 참조 무결성 규칙 정의등을 통해 데이터 모델의 일관성을 확보하고 중복을 제거하여 신뢰성있는 데이터 구조를 얻을 수 있음.
물리적 데이터 모델링	DB에 이식할 수 있도록 성능, 저장 등 물리적인 성격을 고려하여 설계함. 물리적으로 컴퓨터에 어떻게 저장될 것인가에 대해 다루는 모델링으로 물리적 저장구조와, 저장 장치, 자료 추출을 위한 접근 방법 등이 주로 다루어지게 됨.

 

데이터 모델링을 프로젝트 생명주기 개념에 대입해서 보면 5단계를 거쳐 정보시스템 구축이 이루어지게 되며, 각각의 과정들은 DB와 애플리케이션의 상호교차검증을 거쳐서 진행됩니다.

 

	정보시스템 구축			↑ 개 발 순 서
전환 / 이행	DB 전환		AP 설치
테스트	DB 튜닝	검 증	AP 테스트
개발	DB 구축, 변경, 관리		AP 개발
설계	물리데이터 모델링	상관모델링	AP 설계
분석	개념 / 논리 데이터 모델링		프로세스 모델링
	정보전략 계획(ISP) / 프로세스 개선(PI) / EA

 

서비스 개발과정에서는 일반적으로 객체지향의 개념을 사용하여 개발을 진행하게 되는데, 이 과정에서 데이터와 프로세스를 한꺼번에 바라보며 모델링을 전개하게 되며, 이에 따라 일체적인 구성으로 정보시스템 개발이 이루어지게 됩니다. 이와 같은 기능화된 구성의 가장 큰 목적은 각각의 고유기능들은 유지시키면서 기능은 극대화시키는 것이며, 이는 컴포넌트 기반의 모듈 구성의 컴포넌트의 개념과 SOA(Service-Oriented Architecture)의 서비스의 개념과 일맥상통하게 됩니다. 즉, 특정 단위에 대해 독립적인 의미를 부여하고 고유기능들을 각각 구현함으로써 변화에 대한 유연한 대응이라는 강점을 가질 수 있게 되기에 데이터 모델링에 있어서 데이터 독립성은 중요한 의미를 가진다고 할 수 있습니다.

데이터 독립성에 대한 이해를 위해서는 해당 개념이 출현하게된 배경에 대한 이해가 필요합니다. 데이터 독립성의 반대말은 데이터 종속성으로 사용자 요구사항을 처리하는 사용자 접점의 인터페이스 오브젝트인 애플리케이션을 주체로 하여 독립여부를 판단합니다. 파일방식으로 데이터를 구성하던 시기에는 파일과 데이터에 접근하기 위한 인덱스를 별도로 구현하였으며, 이는 사용자가 접근하는 방법(트랜잭션의 유형)에 따라 파일의 정렬순서, 인덱스의 정렬순서, 파일 구성 등을 제공하기 쉽게 하기 위함이었습니다. 해당 방식은 사용자의 접근하는 유형에 따라 데이터를 구성하는 방법에 영향을 미쳤고, 이는 데이터 종속성을 유발시켰었습니다. 이와 같은 데이터 종속성은 유지보수 비용증가, 데이터 중복성 증가, 데이터 복잡도 증가, 요구사항 대응 저하와 같은 부정적인 효과를 발생시킬 수 있기에 화면과 DB간의 독립성을 유지하기 위한 목적으로 데이터 독립성의 개념이 출현하였습니다.

데이터 독립성은 미국 표준 협회(ANSI : American National Standards Institute) 산하 X3 위원회(컴퓨터 및 정보처리)의 특별연구분과위원회에서 1978년에  DBMS와 인터페이스를 위해 제안한 'three-schema architecture'로 정의할 수 있으며, 데이터 독립성 확보를 통해 얻을 수 있는 효과는 아래와 같습니다.

 

1. 각 View의 독립성을 유지하고, 계층별 View에 영향을 주지않고 변경이 가능함.

2. 단계별 Schema에 따라 데이터 정의어(DDL)와 데이터 조작어(DML)가 다름을 제공함.

 

미국 표준 협회(ANSI)는 데이터 독립성을 설명하기 위해서 구조, 독립성, 사상이라는 3가지 요소를 제공하였고, 이에 대한 구체적인 내용은 아래와 같습니다.

 

외부단계	외부 스키마 #1		외부 스키마 #2		외부 스키마 #3
			↕		논리적 데이터 독립성
개념적단계			개념 스키마
			↕		물리적 데이터 독립성
내부적단계			내부 스키마

항 목	내 용
외부스키마 (External Schema)	- 개별 사용자가 보는 개인적 DB 스키마 - DB의 개별 사용자나 응용프로그래머가 접근하는 DB 정의
개념스키마 (Conceptual Schema)	- 모든 사용자 관점을 통합한 조직 전체의 DB를 기술하는 것 - 조직 전체의 DB를 기술한 것으로 DB에 저장되는 데이터와 그들간의 관계를 표현하는 스키마
내부스키마 (Internal Schema)	- DB가 물리적으로 저장되는 형식 - 물리적 장치에서 데이터가 실제적으로 저장되는 방법을 표현하는 스키마

항 목	내 용	특 징
논리적 독립성	- 개념 스키마가 변경되어도 외부 스키마에는 영향을 미치지 않도록 지원하는 것 - 논리적 구조가 변경되어도 응용 프로그램에 영향 없음	- 사용자 특성에 맞는 변경가능 - 통합 구조 변경가능
물리적 독립성	- 내부 스키마가 변경되어도 외부/개념 스키마는 영향을 받지 않도록 지원하는 것 - 저장장치의 구조변경은 응용프로그램과 개념스키마에 영향 없음	- 물리구조 영향없이 개념구조 변경가능 - 개념구조 영향없이 물리구조 변경가능

항 목	내 용
외부적/개념적 사상(논리적 사상)	- 외부적 뷰와 개념적 뷰의 상호 관련성을 정의함
개념적/내부적 사상(물리적 사상)	- 개념적 뷰와 저장된 DB의 상호관련성을 정의

 

데이터 모델에 대한 보다 정확한 이해를 위해서는 추가적으로 데이터 모델링의 엔터티(Entity), 속성(Attribute), 관계(Relationships)라는 3요소에 대한 이해가 필요하며, 이들을 지칭하는 용어들로는 아래와 같은 것들이 존재합니다.

 

개 념	복수/집합개념	개별/단수개념
업무에 관여하는 어떤 것 (Things)	엔터티 타입(Entity Type), 엔터티(Entity)	엔터티(Entity), 인스턴스(Instance), 어커런스(Occurrence)
어떤 것의 성격 (Characteristic of a Thing)	속성(Attribute)	속성값(Attribute Value)
어떤 것간의 연관 (Association between Things)	관계(Relationship)	페어링(Pairing)

 

위와같은 개념들을 활용하고 과정들을 거쳐서 진행되는 데이터 모델링에는 다양한 이해관계자가 존재하며, 데이터 모델링도 결국 다양한 개체들이 모여 이룬 집단에서 진행되는 것이기에 이해관계자들이 데이터 모델링의 중요성을 인식하고 그에 필요한 지식과 기술들을 함양하는 것은 중요하다고 할 수 있습니다.

실무에서는 DBA(Database Adminstrator)가 데이터 모델링을 전적으로 하는 경우는 드물며, 업무시스템 개발자가 데이터 모델링을 같이 진행하는 경우가 일반적입니다. 데이터 모델링은 DB를 설계하는 측면과 더불어 업무 이해, 분석, 표현하는 것이 중요하고, 이를 바탕으로 프로젝트 담당자와 의사소통하는 과정이 필수적이기 때문에 정보시스템을 구축하는 모든 사람들은 데이터 모델링에 대해 연구하고 학습해야 합니다. 그런 의미에서 프로젝트 개발자, DBA, 전문 모델러, 현업업무전문가와 같은 데이터 모델링의 이해관계자들은 각각의 역할에 맞는 지식과 기술을 함양하는 것은 매우 중요한 의미를 가진다고 할 수 있습니다. 

이해관계자들의 보다 원활한 의사소통을 돕기 위해 대표적으로 활용되는 도구로는 데이터 모델 표기법인 ERD(Entity-Relationship Diagram)이 있으며, 이에 대한 자세한 내용은 아래 사이트를 참조하시기 바랍니다.

 

ERD - 해시넷

 

ERD를 작성하는 순서는 일반적으로 6단계로 이루어지며, 세부적인 내용은 아래와 같습니다.

 

1. 엔터티를 그린다.

2. 엔터티를 적절하게 배치한다.(가장 중요한 엔터티를 왼족 상단에 배치)

3. 엔터티간의 관계를 설정한다.(Primary Key로 속성이 상속되는 식별자 관계 설정, 중복 및 순환관계 유의)

4. 관계명을 기술한다.(현재형을 사용하고, 지나치게 포괄적인 용어는 사용 X)

5. 관계의 참여도를 기술한다.(관계차수 Cardinality 를 표기)

6. 관계의 필수여부를 기술한다.

 

앞서 알아본 모델링의 개념, 기법, 도구들은 결국 좋은 데이터 모델을 만들기 위한 하나의 과정이며, 이를 통해 데이터 모델의 품질을 적절히 평가하고 개선점을 파악하여 시스템을 발전시키는 것이 이루어져야합니다. 데이터 모델의 품질을 평가하는 것은 객관적으로 평가할 수 있는 기준들이 존재하지 않기 때문에 매우 어려운 과제라고 할 수 있으나 대체적으로 좋은 데이터 모델로 분류하는 몇 가지 요소들은 존재하기에 이를 활용하여 데이터 모델을 평가하고 결과를 활용할 수 있습니다. 구체적인 요소들은 아래와 같습니다.

 

1. 완전성(Completeness)

: 업무에서 필요로하는 데이터(예 : 병원에서 환자의 질병과 건강상태를 관리하기 위한 속성)들이 정확히 정의되어있어야 함.

2. 중복배제(Non-Redundancy)

: 동일한 내용의 정보는 저장공간의 낭비, 데이터 일관성 유지를 위한 추가 데이터 조작 비용 발생등과 같은 부정적 효과를 유발하므로 DB내에 한번만 존재해야함.('나이'와 '생년월일'이 동시에 존재하는 경우 데이터 중복이 발생한 것임)

3. 업무규칙(Business Rules)

: 직급기준과 수당기준과 같은 업무규칙들이 모델에 표현되고 사용자들끼리 해당 규칙을 공유할 수 있어야 의사소통과 판단의 용이성을 획득할 수 있기에 업무규칙이 적절하게 데이터 모델에 반영되어야 함.

4. 데이터 재사용(Data Reusability)

: 통합되지 않은 모델로 인해 발생하는 데이터 중복들은 급변하는 환경에 대해 적절한 대처를 하는데 어려움을 주며, 데이터 모델은 최대한 중복을 줄이고 같은 내용의 정보를 한번만 표현하여 해당 정보들이 다양한 애플리케이션에 재사용될 수 있게 해야함. 이는 변화에 대한 유연성에 큰 영향을 미치기에 초기단계부터 해당 부분을 반드시 고려해야함.

5. 의사소통(Communication)

: 데이터 분석과정에서 도출된 업무규칙들이 엔터티, 서브타입, 속성, 관계등의 형태로 적절하게 표현되어 정보시스템을 운영, 관리, 이용하는 관련자들이 원활하게 의사소통할 수 있어야 함.

6. 통합성(Integration)

: 소규모 조직단위로 개별 정보시스템을 구축하게 되면 데이터 중복 등과 같은 문제점들로 인해 비용이 증가하고 유지보수 및 개선이 어려워지는 등의 문제들이 발생할 수 있기에 이를 예방하기 위해 전사적인 데이터 모델을 통해 데이터들 통합하는 것이 필요함.

 

P.S 더 나은 개발자가 되기위해 공부중입니다. 잘못된 부분을 댓글로 남겨주시면 학습하는데 큰 도움이 될 거 같습니다.

+ 본 글은 「SQL 전문가 가이드, 한국 데이터베이스 진흥원」참고하여 작성하였습니다.