제1절 데이터 모델의 이해
2014.03.04 06:42
1. 모델링의 이해
가. 모델링의 정의
모델(Model) : 모형(模型), 축소형(縮小型)의 의미로서 사람이 살아가면서 나타날 수 있는 다양한 현상에 대해 일정한 표기법으로 표현해 놓은 모형. => 커뮤니케이션의 효율성을 극대화한 고급화된 표현방법
모델링(Modeling) : 표기법에 따른 규칙을 가지고 표기하는 것 자체를 의미함. 즉, 모델을 만들어가는 일 자체(행위)
모델링에 대한 다양한 정의
1) Webster 사전
가설적 또는 일정 양식에 맞춘 표현(a hypothetical or stylized representation)
어떤 것에 대한 예비표현으로 그로부터 최종대상이 구축되도록 하는 계획으로서 기여하는 것
2) 복잡한 ‘현실세계’를 단순화시켜 표현하는 것
3) 모델이란 사물 또는 사건에 관한 양상(Aspect)이나 관점(Perspective)을 연관된 사람이나 그룹을 위하여 명확하게 하는 것
4) 모델이란 현실 세계의 추상화된 반영
나. 모델링의 특징
모델링의 3대 특징 | 설명 |
추상화(모형화, 가설적) | 현실세계를 일정한 형식에 맞추어 표현을 한다는 의미로 정리할 수 있음. |
단순화 | 복잡한 현실세계를 약속된 규약에 의해 제한된 표기법이나 언어로 표현하여 쉽게 이해할 수 있도록 하는 개념 |
명확화 | 누구나 이해하기 쉽게 하기 위해 대상에 대한 애매모호함을 제고하고 정확하게 현상을 기술하는 것을 의미함 |
모델링의 재 정의 : 현실세계를 추상화, 단순화, 명확화하기 위해 일정한 표기법에 의해 표현하는 기법
다. 모델링의 세 가지 관점
![SQL_002.jpg](http://bysql.net/files/attach/images/34446/640/034/121503bb5ed1c1d722480a89fad96cad.jpg)
관점 | 모델링하는 방법 | 키워드 |
데이터관점 | 업무가 어떤 데이터와 관련이 있는지? 데이터간의 관계는 무엇인지? | What, Data |
프로세스관점 | 업무가 실제하고 있는 일은 무엇인지? 무엇을 해야하는지를 모델링하는 방법 | How, Process |
데이터와 프로세스의 상관관점 | 업무가 처리하는 일의 방법에 따라 데이터는 어떻게 영향을 받고 있는지? | Interaction |
2. 데이터 모델의 기본 개념의 이해
가. 데이터 모델링의 정의
나. 데이터 모델이 제공하는 기능
- 시스템의 구조와 행동을 명세화 할 수 있게 한다.
- 시스템을 구축하는 구조화된 틀을 제공한다.
- 시스템을 구축하는 과정에서 결정한 것을 문서화한다.
- 다양한 영역에 집중하기 위해 다른 영역의 세부 사항은 숨기는 다양한 관점을 제공한다.
- 특정 목표에 따라 구체화된 상세 수준의 표현방법을 제공한다.
3. 데이터 모델링의 중요성 및 유의점
가. 파급효과(Leverage)
변경을 해야 하는 데이터의 모델의 형태에 따라서 그 영향 정도는 차이가 있지만 데이터 구조의 변경으로 인한 일련의 변경작업은 제체 시스템 구축 프로젝트에서 큰 위험요소
나. 복잡한 정보 요구사항의 간결한 표현(Conciseness)
데이터 모델의 특징 : 구축할 시스템의 정보 요구사항과 한계를 가장 명확하고 간결하게 표현할 수 있는 도구
데이터 모델은 건축물로 비유하자면 설계 도면에 해당한다. 이것은 건축물의 설계 도면이 건축물을 짓는 많은 사람들이 공유하면서 설계자의 생각대로 일사불란하게 움직여서 아름다운 건축물을 만들어 내는 것에 비유할 수 있다. 데이터 모델은 시스템을 구축하는 많은 관련자들이 설계자의 생각대로 정보요구사항을 이해하고 이를 운용할 수 있는 애플리케이션을 개발하고 데이터 정합성을 유지할 수 있도록 하는 것이다. 이렇게 이상적으로 역할을 할 수 있는 모델이 갖추어야 할 가장 중요한 점은 정보 요구사항이 정확하고 간결하게 표현되어야 한다는 것이다. 우리가 활용하고 있는 데이터 모델이 이와 같은 요소들이 충족된 모델인지를 확인해 볼 필요가 있다.
다. 데이터 품질(Data Quality)
- 데이터 품질의 문제가 중요한 이유
- 데이터 품질의 문제는 데이터 구조가 설계되고 초기에 데이터가 조금 쌓일 때에는 인지하지 못하는 경우가 대부분
- 데이터의 문제는 오랜 기간 숙성된 데이터를 전략적으로 활용하려고 하는 시점에 문제가 대두됨
- 데이터 품질의 문제는 데이터 구조가 설계되고 초기에 데이터가 조금 쌓일 때에는 인지하지 못하는 경우가 대부분
- 데이터 품질의 문제가 야기시키는 원인
- 데이터 구조의 문제 : 중복 데이터의 미정의, 데이터 구조의 비즈니스 정의의 불충분, 동일한 성격의 데이터를 통합하지 않고 분리함으로써의 나타나는 데이터 불일치 등
- 데이터 구조의 문제 : 중복 데이터의 미정의, 데이터 구조의 비즈니스 정의의 불충분, 동일한 성격의 데이터를 통합하지 않고 분리함으로써의 나타나는 데이터 불일치 등
- 데이터 모델링을 할 때 유의점
- 중복(Duplication) : 데이터베이스가 여러 장소에 같은 정보를 저장하는 것을 유의
- 비유연성(Inflexibility) : 데이터의 정의를 데이터의 사용 프로세스와 분리하여 유연한 데이터 모델을 설계하여 유지보수의 어려움을 사전에 예방한다.
- 비일관성(Inconsistency) : 데이터와 데이터간 상호 연관 관계에 대한 명확한 정의를 통해 일관성있는 데이터 모델을 작성하도록 한다.
- 중복(Duplication) : 데이터베이스가 여러 장소에 같은 정보를 저장하는 것을 유의
4. 데이터 모델링의 3단계 진행
![SQL_004.jpg](http://bysql.net/files/attach/images/34446/640/034/a5f358d2d27a6706531b858a6b4b38da.jpg)
- 개념적 데이터 모델
- 현실 세계에 대한 인간의 이해를 돕기 위해 현실 세계에 대한 인식을 추상적 개념으로 표현하는 과정
- 속성들로 기술된 개체 타입과 이 개체 타입들 간의 관계를 이용하여 현실 세계 표현
- 현실 세계에 존재하는 개체를 인간이 이해할 수 있는 정보 구조로 표현 = 정보 모델
- 개념적 데이터 모델의 종류
- E-R 모델(Entity-Relationship Model)
- 이진 모델(Binary Model)
- 의미적 데이터 모델(Semantic Data Model)
- 정보 논리 모델(Information Logical Model)
- 함수적 데이터 모델(Functional Data Model)
- 논리적 데이터 모델
- 개념적 모델링 과정에서 얻은 개념적 구조를 컴퓨터가 이해하고 처리할 수 있는 컴퓨터 세계의 환경에 맞도록 변환하는 과정
- 필드로 기술된 데이터 타입과 이 데이터 타입들 간의 관계를 이용하여 현실세계 표현
- 단순히 데이터 모델이라고 하면 논리적 데이터 모델을 의미
- 특정 DBMS는 특정 논리적 데이터 모델 하나만 선정하여 사용
- 논리적 데이터 모델의 종류
- 관계형 데이터 모델(Relational Data Model)
- 계층형 데이터 모델(Hierarchical Data Model)
- 네트워크형 데이터 모델(Network Data Model)
- 객체 지향형 데이터 모델(Object-Oriented Data Model)
![SQL_005.jpg](http://bysql.net/files/attach/images/34446/640/034/b5edfd503845d6526da72becb9a96f84.jpg)
- Waterfall 기반 : 데이터 모델링의 위치가 분석과 설계단계로 구분되어 명확하게 정의
- 정보공학이나 구조적 방법론 :
- 보통 분석단계에서 업무중심의 논리적인 데이터 모델링을 수행
- 설계단계에서 하드웨어와 성능을 고려한 물리적인 데이터 모델링을 수행
- 나선형 모델, 예를 들어 RUP(Rational Unified Process나 마르미)
- 업무크기에 따라 논리적 데이터 모델과 물리적 데이터 모델이 분석, 설계단계 양쪽에서 수행
- 비중은 분석단계에서 논리적인 데이터 모델이 더 많이 수행되는 형태
- 데이터축과 애플리케이션축으로 구분되어 프로젝트가 진행되면서 각각에 도출된 사항은 상호 검증을 지속적으로 수행하면서 단계별 완성도를 높이게 된다.
![SQL_006.jpg](http://bysql.net/files/attach/images/34446/640/034/433eeadfaa4aceb3d5ee592021473734.jpg)
가. 데이터독립성의 필요성
- 상호간 영향에서 벗어나 개별 형식이 가지는 고유의 기능을 유지시키며 그 기능을 극대화하는 것
- 컴포넌트 기반의 모듈 구성도 각각이 고유한 기능을 가지면서 다른 기능을 가지고 있는 컴포넌트와 인터페이스를 가지게 하는 모습으로 정의
- SOA의 ‘서비스’라고 하는 단위도 독립적인 비즈니스로 처리 가능한 단위를 서비스로 정의
그것이 다른 서비스에 비해 독립성을 구성하여 개별로도 의미
다른 서비스와 결합하여 프로세스로 제공해도 의미가 있는 단위(예, BPM)로 제공
이와 같이 어떤 단위에 대해 독립적인 의미를 부여하고 그것을 효과적으로 구현하게 되면 자신이 가지는 고유한 특징을 명확하게 할 뿐만 아니라 다른 기능의 변경으로부터 쉽게 변경되지 않고 자신의 고유한 기능을 가지고 기능을 제공하는 장점
데이터독립성 출현 배경
- 끊임없이 요구되는 사용자 요구사항에 대해 화면과 데이터베이스 간에 서로 독립성을 유지하기 위한 목적
- 데이터독립성의 반대말은 데이터종속성 (여기에서 종속의 주체는 보통 응용(Application)을 지칭하는 경우)
응용(Application)은 사용자 요구사항을 처리하는 사용자 접점의 인터페이스 오브젝트
과거에 파일방식으로 데이터를 구성할 때는 데이터가 있는 파일과 데이터에 접근하기 위한 인덱스를 별도로 구현하여
접근하게 하였는데 사용자가 접근하는 방법(트랜잭션의 유형)에 따라 파일의 정렬순서, 인덱스의 정렬순서, 파일 구성 등을
제공하기 쉽게 별도로 구성 ☞ 즉, 사용자 접근하는 유형에 따라 데이터를 구성하는 방법이 영향
- 데이터독립성은 지속적으로 증가하는 유지보수 비용을 절약
- 데이터 복잡도를 낮추며 중복된 데이터를 줄이기 위한 목적
- 미국 표준 협회(ANSI) 산하의 X3 위원회(컴퓨터 및 정보 처리)의 특별연구분과위원회에서 1978년에 DBMS와 그 인터페이스를 위해 제안한 ‘three-schema architecture’로 정의
데이터 독립성의 효과
- 각 View의 독립성을 유지하고 계층별 View에 영향을 주지 않고 변경이 가능하다.
- 단계별 Schema에 따라 데이터 정의어(DDL)와 데이터 조작어(DML)가 다름을 제공한다.
데이터독립성을 이해하기 위해서는 3단계로 표현된 ANSI 표준 모델을 살펴보면 되는데 특히 3단계인 구조, 독립성, 사상(Mapping) 3가지를 이해하면 된다.
나. 데이터베이스 3단계 구조
ANSI/SPARC의 3단계 구성의 데이터독립성 모델 : 외부단계, 개념적 단계, 내부적 단계로 서로 간섭되지 않는 모델을 제시
다. 데이터독립성 요소
데이터베이스 스키마 구조
- 3단계로 구분, 각각은 상호 독립적인 의미와 고유한 기능 소유
※ 참고 : 데이터 모델링은 통합관점의 뷰를 가지고 있는 개념 스키마를 만들어가는 과정
라. 두 영역의 데이터독립성
논리적인 독립성 & 물리적인 독립성 : 3단계로 개념의 각 영역에 대한 독립성을 지정하는 용어
논리적인 데이터독립성 : 외부의 변경에도 개념스키마가 변하지 않는 특징
마. 사상(Mapping)
영어로 ‘Mapping’은 우리말로 ‘사상’이라고 번역되는데 이것은 상호 독립적인 개념을 연결시켜주는 다리를 뜻함
데이터독립성에는 크게 2가지의 사상 도출
논리적 사상 : 외부 화면이나 사용자에게 인터페이스하기 위한 스키마 구조는 전체가 통합된 개념적 스키마와 연결된다는 것
물리적 사상 : 통합된 개념적 스키마 구조와 물리적으로 저장된 구조의 물리적인 테이블스페이스와 연결되는 구조
7. 데이터 모델링의 중요한 세 가지 개념
가. 데이터 모델링의 세 가지 요소데이터 모델링을 구성하는 중요한 개념 세 가지가 있는데 이것은 데이터 모델에 대한 이해의 근간이 되므로 반드시 기억할 필요가 있다.
이 세 가지는 데이터 모델링을 완성해 가는 핵심 개념 ☞ 결국 엔터티, 속성, 관계로 인식
사물이나 사건 등을 바라 볼 때 전체를 지칭하는 용어를 어떤 것(Things)이라 하고, 그 어떤 것이 가지는 세부적인 사항을 성격(Attributes)이라고 할 수 있다. 또한 각각의 어떤 것은 다른 어떤 것과 연관성을 가질 수 있는데 이것을 관계(Relationship)라고 표현한다. 예를 들어 ‘이주일과 심순애가 존재하고 둘 사이는 서로 사랑하는 연인사이이다. 이주일은 키가 180cm에 성격은 친절하고 심순애는 키가 165cm에 세심하며 활달한 성격을 가지고 있다’는 시나리오를 살펴보자. 여기에서 ‘이주일, 심순애’는 어떤 것(Things)에 해당하고 ‘사랑하는 연인사이’가 어떤 것 간의 관계(Relationships)에 해당하며 ‘180cm에 성격은 친절, 세심하며 활달함’이 어떤 것이 가지는 성격(Attributes)에 해당한다. 위의 예와 같이 이 세상의 모든 사람, 사물, 개념 등은 어떤 것, 어떤 것 간의 관계, 성격의 구분을 통해서 분류할 수 있다. 바로 이러한 원리, 즉 자연계에 존재하는 모든 유형의 정보들을 세 가지 관점의 접근 방법을 통해 모델링을 진행하는 것이다.
나. 단수와 집합(복수)의 명명
- 어떤 것 : 실제 실무 현장에서는 복수/집합개념도 엔터티로 짧게 명명
엔터티를 집합개념으로 사용하는 경우, 개별요소에 대해서는 인스턴스/어커런스를 단수의 개념으로 사용
- 관계(Relationship) : 일반적으로 단수든 복수든 대부분 관계라고 표현
- 성격(Attribute) : 속성과 속성값으로 구분
※ 교재에서의 용어 구분 사용 ☞ Thing : 복수 - 엔터티, 단수 - 인스턴스 라 표기
8. 데이터 모델링의 이해관계자
가. 이해관계자의 데이터 모델링 중요성 인식
- 실질적으로 DBA보다 업무시스템을 개발하는 응용시스템 개발자가 데이터 모델링도 같이하는 경우가 많음
- 원인 데이터 모델링이라는 과정의 특징
1) 단지 데이터베이스를 설계한다는 측면 < 업무를 이해하고 분석하여 표현하는 것
2) 표현된 내용을 바탕으로 프로젝트 관련자와 의사소통
3) 프로그램이나 다른 표기법과 비교 검증하는 일을 수행
∴ 많은 시간을 업무를 분석하고 설계하는데 할애하기 때문에 업무영역별 개발팀에서 보통 데이터 모델링을 진행
단, 시스템이 대형화되면 모델링만을 전문적으로 담당하는 모델러를 투입하여 진행
but, 실제 모델링 작업은 응용개발을 하는 사람이나 업무분석가(역할분담이 잘되어 있을 경우)가 담당
모델러나 DBA는 정확하게 모델링이 진행될 수 있도록 교육하고 제시하며 현안별로 직접 모델링을 진행하는 역할을 수행
![](http://www.dbguide.net/publishing/img/knowledge/SQL_014.jpg)
우리가 구축하려는 시스템 대부분을 데이터에 기반한, 데이터가 중심에 있는 정보시스템을 구축하기 때문에 정보시스템의 핵심에 있는 데이터베이스 설계를 잘못했을 때 미치는 영향력은 모든 프로그램, 시간에 따라 입력되는 모든 데이터, 그리고 그 데이터베이스에 발생되는 모든 트랜잭션에 영향을 미칠 수 밖에 없게 된다. Bachmann은 ‘프로그래머는 데이터집합의 탐색자이다’라고 하였다. 그만큼 데이터에 대한 중요성을 높게 평가하는 것이다.
나. 데이터 모델링의 이해관계자
데이터 모델링에 대해 연구 및 학습 담당자
첫 번째는 정보시스템을 구축하는 모든 사람 (전문적으로 코딩만하는 사람 포함)
→ 데이터 모델링도 전문적으로 할 수 있거나 적어도 완성된 모델을 정확하게 해석가능 해야 함
☞ 프로젝트에 참여한 모든 IT기술자들은 데이터 모델링에 대해 정확하게 알고 있어야 함
두 번째는 IT기술에 종사하거나 전공하지 않았더라도 해당 업무에서 정보화를 추진하는 위치에 있는 사람
→ 데이터 모델링에 대한 개념 및 세부사항에 대해 어느 정도 지식이 있어야 함
☞ 서로가 프로젝트 수행 중에 의사소통을 잘 할 수 있고 업무를 잘못 해석하여 잘못된 시스템을 구축하는 위험(Risk)을 줄일 수 있음. 업무를 가장 잘 알고 있는 사람이 가장 훌륭한 모델러가 될 수 있음
![](http://www.dbguide.net/publishing/img/knowledge/SQL_015.jpg)
9. 데이터 모델의 표기법인 ERD의 이해
가. 데이터 모델 표기법
1976년 피터첸(Peter Chen)이 Entity-relationship model(E-R Model)이라는 표기법
![](http://www.dbguide.net/publishing/img/knowledge/SQL_016.jpg)
※ 교재의 표기법
데이터아키텍처 전문가(DAP) 관련 자격에서는 바커(Barker) 표기법을 적용하여 설명
본 가이드에서는 범용적인 Information Engineering(이하 IE) 표기법과 바커 표기법 모두 적용
나. ERD(Entity Relationship Diagram) 표기법을 이용하여 모델링하는 방법
ERD
- 각 업무분석에서 도출된 엔터티와 엔터티간의 관계를 이해하기 쉽게 도식화된 다이어그램으로 표시하는 방법
- 해당 업무에서 데이터의 흐름과 프로세스와의 연관성을 이야기하는 데 가장 중요한 표기법이자 산출물
UML 표준 표기법을 사용하는 오브젝트 모델링
해당 업무에 가장 적절한 클래스다이어그램을 그려내는 것이 가장 중요
정보공학을 기반으로 하는 모델링
해당 업무에 가장 적절한 ERD를 그려내는 것이 프로젝트의 지상과제
데이터베이스를 생성할 수 있는 데이터 모델 생성이 프로젝트에서 아주 중요한 작업
이론 : 데이터분석이 어느 정도 완료되면 즉 엔터티, 관계, 속성 등이 데이터사전이나 각종 산출물에 의해 분석된 상태에서 ERD 그리기
현실 : 프로젝트에서는 분석된 엔터티와 관계, 속성 정보가 바로 ERD에 표현되며 내부 프로젝트 인원이나 해당 업무고객과 대화할 때 핵심 업무산출물로 이용
1) ERD 작업순서 ERD를 작성하는 작업순서
① 엔터티를 그린다. ② 엔터티를 적절하게 배치한다. ③ 엔터티간 관계를 설정한다. ④ 관계명을 기술한다. ⑤ 관계의 참여도를 기술한다. ⑥ 관계의 필수여부를 기술한다.
![](http://www.dbguide.net/publishing/img/knowledge/SQL_017.jpg)
ERD는 엔터티와 엔터티 사이의 관계가 있는 정보를 나타내므로 두 개를 이용하여 작성
☞ Primary Key와 Foreign Key를 ERD 규칙에 따라 기술, 엔터티는 사각형으로 표기하여 기술
2) 엔터티 배치 엔터티를 처음에 어디에 배치하는지는 데이터 모델링 툴을 사용하든 사용하지 않던 중요한 문제이다. 일반적으로 사람의 눈은 왼쪽에서 오른쪽, 위 쪽에서 아래쪽으로 이동하는 경향이 있다. 따라서 데이터 모델링에서도 가장 중요한 엔터티를 왼쪽상단에 배치하고 이것을 중심으로 다른 엔터티를 나열하면서 전개하면 사람의 눈이 따라가기에 편리한 데이터 모델링을 전개할 수 있다. 해당 업무에서 가장 중요한 엔터티는 왼쪽 상단에서 조금 아래쪽 중앙에 배치하여 전체 엔터티와 어울릴 수 있도록 하면 향후 관계를 연결할 때 선이 꼬이지 않고 효과적으로 배치할 수 있게 된다.
![](http://www.dbguide.net/publishing/img/knowledge/SQL_018.jpg)
"그림 Ⅰ-1-10"의 데이터 모델에서도 가장 중요한 엔터티인 고객과 주문을 왼쪽 상단에 배치하여 다른 엔터티를 연결하는 방식으로 엔터티를 배치하였다. 주문에 따라 출고가 이루어졌으므로 주문이 위에 출고가 아래에 위치해 있다. 두 번째 업무흐름에 중심이 되는 엔터티, 보통 업무 흐름에 있어서 중심이 되는 엔터티는 타 엔터티와 많은 관계를 가지고 있으므로 중앙에 배치하도록 한다. "그림 Ⅰ-1-10"에서는 주문, 출고, 주문목록, 출고목록이 업무의 중심엔터티에 해당한다. 세 번째는 업무를 진행하는 중심엔터티와 관계를 갖는 엔터티들은 중심에 배치된 엔터티를 주위에 배치하도록 한다. "그림 Ⅰ-1-10"에서는 창고, 고객, 사원, 재고가 이에 해당한다.
3) ERD 관계석서를 보고 서로 관련있는 엔터티간에 관계를 설정하도록 한다. 초기에는 모두 Primary Key로 속성이 상속되는 식별자 관계를 설정하도록 한다. 중복되는 관계가 발생되지 않도록 하고 Circle 관계도 발생하지 않도록 유의하여 작성하도록 한다.
![](http://www.dbguide.net/publishing/img/knowledge/SQL_019.jpg)
4) ERD 관계명의 표시 관계설정이 완료되면 연결된 관계에 관계이름을 부여하도록 한다. 관계이름은 현재형을 사용하고 지나치게 포괄적인 용어(예, 이다, 가진다 등)는 사용하지 않도록 한다.
![](http://www.dbguide.net/publishing/img/knowledge/SQL_020.jpg)
실제 프로젝트에서는 관계의 명칭을 크게 고려하지 않아도 무방하다. 왜냐하면 관계의 명칭이 나타나지 않아도 ERD의 흐름이 명확하게 드러나기 때문이다. 대부분의 관계는 엔터티의 성질과 주식별자를 보고 유추가 가능하다.
5) ERD 관계 관계차수와 선택성 표시 관계에 대한 이름을 모두 지정하였으면 관계가 참여하는 성격 중 엔터티내에 인스턴스들이 얼마나 관계에 참여하는 지를 나타내는 관계차수(Cardinality)를 표현한다. "그림 Ⅰ-1-13"은 관계의 관계차수를 지정한 ERD의 모습을 보여준다. 관계설명에서도 언급하겠지만 IE표기법으로는 하나(1, One)의 관계는 실선으로 표기하고 Barker표기법으로는 점선과 실선을 혼합하여 표기한다. 다수참여(Many)의 관계는 까마귀발과 같은 모양으로 그려준다. 또한 관계의 필수/선택표시는 관계선에 원을 표현하여 ERD를 그리도록 한다.
![](http://www.dbguide.net/publishing/img/knowledge/SQL_021.jpg)
10. 좋은 데이터 모델의 요소
가. 완전성(Completeness)
업무에서 필요로 하는 모든 데이터가 데이터 모델에 정의
이 기준이 충족되지 못하면 다른 어떤 평가 기준도 의미가 없어짐
만약, 보험사의 데이터 모델에 고객의 직업을 관리하기 위한 속성이 존재하지 않는다면 어떨까?
나. 중복배제(Non-Redundancy)
하나의 데이터베이스 내에 동일한 사실은 반드시 한 번만 기록
저장공간의 낭비, 중복 관리되고 있는 데이터의 일관성을 유지하기 위한 추가적인 데이터 조작 등이 대표적으로 낭비되는 비용
다. 업무규칙(Business Rules)
업무규칙(Business Rules)을 데이터 모델에 표현하고 이를 해당 데이터 모델을 활용하는 모든 사용자가 공유할 수 있도록 제공
특히, 데이터 아키텍처에서 언급되는 논리 데이터 모델(Logical Data Model)에서 이러한 요소들이 포함되어야 함
예를 들면, 보험사의 사원들은 매월 여러 가지 항목에 대해서 급여를 지급받고 있고 이를 데이터로 관리하고 있다. 각 사원들은 월별로 하나 이상의 급여 항목(기본급, 상여금, 수당, 수수료, 등등)에 대해서 급여를 지급받는다. 여기에 더 나아가 각 사원은 사원 구분별(내근, 설계사, 계약직, 대리점 등)로 위의 급여 항목을 차등적으로 지급받는 다는 업무규칙이 있다. 이러한 내용을 데이터 모델에 나타내야 한다.
☞ 해당 데이터 모델을 사용하는 모든 사용자(개발자, 관리자 등)가 해당 규칙에 대해서 동일한 판단을 하고 데이터를 조작 가능
라. 데이터 재사용(Data Reusability)
데이터의 통합성과 독립성에 대해서 충분히 고려
과거 정보시스템의 데이터 구조의 가장 큰 특징은 데이터 모델이 별도로 존재하지 않고 애플리케이션의 부속품 정도로 인식
☞ 데이터 중복이 많이 발생하고 데이터의 일관성 문제가 심각하게 초래
해결 : 데이터가 애플리케이션에 대해 독립적으로 설계되어야만 데이터 재사용성을 향상
데이터 구조의 확장성, 유연성에 많은 노력을 기울이고 있음 → 업무 환경 변화에 대해서 유연하게 대응
근래의 많은 패키지 시스템들이 가지고 있는 데이터 모델들은 확장성을 강조하기 위해서 많은 부분을 통합한 데이터 모델의 형태
확장성을 담보하기 위해서는 데이터 관점의 통합이 불가피함
특히 정보시스템에서의 ‘행위의 주체’가 되는 집합의 통합, ‘행위의 대상’이 되는 집합의 통합, ‘행위 자체’에 대한 통합 등은 전체 정보시스템의 안정성, 확장성을 좌우하는 가장 중요한 요소
기업이 관리하고자 하는 데이터를 합리적으로 균형이 있으면서도 단순하게 분류하는 것
마. 의사소통(Communication)
데이터를 분석 과정에서는 자연스럽게 많은 업무 규칙들 도출
☞ 도출되는 많은 업무 규칙들은 데이터 모델에 엔터티, 서브타입, 속성, 관계 등의 형태로 최대한 자세하게 표현되어야 함
예를 들면, ‘사원’ 테이블에는 어떠한 ‘사원구분’을 가지는 사원들이 존재하는지, ‘정규직’, ‘임시직’ 사원들이 같이 존재하는지, 아니면 또 다른 형태의 사원들이 존재하는지를 표현해야 한다. 더 나아가서 ‘호봉’이라는 속성은 ‘정규직’일 때에만 존재하는 속성인데 이러한 업무 규칙이 데이터 모델에 표현되어야 한다. 또한, 우리가 관리하는 사원들 중에서 ‘정규직’ 사원들만이 ‘급여’ 테이블과 관계를 가진다. 이러한 부분은 개별 관계로 데이터 모델에 표현되어야 한다.
표현된 많은 업무 규칙들을 해당 정보시스템을 운용, 관리하는 많은 관련자들이 설계자가 정의한 업무 규칙들을 동일한 의미로 받아들이고 정보시스템을 활용할 수 있게 하는 역할
☞ 즉, 데이터 모델이 진정한 의사소통(Communication)의 도구로서의 역할
바. 통합성(Integration)
동일한 데이터는 조직의 전체에서 한번 만 정의되고 이를 여러 다른 영역에서 참조, 활용하는 것
단, 물론 이 때에 성능 등의 부가적인 목적으로 의도적으로 데이터를 중복시키는 경우 존재가능
☞ 해결 : 동일한 성격의 데이터를 한 번만 정의하기 위해서는 공유 데이터에 대한 구조를 여러 업무 영역에서 공동으로 사용하기 용이하게 정의. 즉, 데이터 아키텍처의 중요성
자료 출처 : DBguide.Net ( 데이터 모델링의 이해 - 데이터 모델의 이해 )
관련 링크 :
- SQL 전문가 개발자 자격증 스터디 (bysql.net 2014년 1차 스터디)
- 작성자: 최동권
- 최초작성일: 2014년 03월 02 일
- 본문서는 bysql.net 스터디 결과입니다 .본 문서를 인용하실때는 출처를 밝혀주세요. http://www.bysql.net
- 문서의 잘못된 점이나 질문사항은 본 문서에 댓글로 남겨주세요. ^^
댓글 0
번호 | 제목 | 글쓴이 | 날짜 | 조회 수 |
---|---|---|---|---|
9 | 제6절 분산 데이터베이스와 성능 | 정희수 | 2014.03.31 | 72004 |
8 | 제5절 데이터베이스 구조와 성능 | 정희수 | 2014.03.31 | 4137 |
7 | 1.1.장 연습문제 | bydavid | 2014.03.05 | 3708 |
6 | 제5절 식별자 | bydavid | 2014.03.05 | 5067 |
5 | 제4절 관계(Relationship) | bydavid | 2014.03.05 | 3930 |
4 | 제3절 속성(Attribute) | bydavid | 2014.03.05 | 4150 |
3 | 제2절 엔터티(Entity) | bydavid | 2014.03.05 | 3675 |
» |
제1절 데이터 모델의 이해
![]() | bydavid | 2014.03.04 | 12356 |
1 |
SQL 전문가
![]() | darkbeom | 2014.02.17 | 140141 |