SQLD 자격증 공부 데이터 모델링의 이해-데이터 모델의 이해(SQL 전문가가이드)

*본 게시물은 2013년도 SQL 전문가 가이드 교재(일명 '노랭이')를 참고하여 공부하고 정리한 게시물입니다

 

1과목 데이터 모델링의 이해: 제1장 데이터 모델링의 이해

1. 모델링의 이해

1) 모델링의 정의

• 모델: 사람이 살아가면서 나타날 수 있는 다양한 현상을 일정한 표기법으로 표현한 모형
• 모델링: 사람이 어떤 목적을 달성하기 위해 커뮤니케이션의 효율성을 극대화한, 고급화된 표현방법
  => 모델을 만들어가는 일 자체를 모델링으로 정의할 수 있음

2) 모델링의 특징

(1) 추상화(모형화, 가설적)

• 일정한 형식에 맞추어 표현

(2) 단순화

• 약속된 규약에 의해 제한된 표기법이나 언어로 표현

(3) 명확화

• 누구나 이해하기 쉽도록 표현

-> 모델링을 '현실세계를 단순화하여 표현하는 것'으로 정리할 수 있음

 

3) 모델링의 세 가지 관점

(1) 데이터 관점(Data, What)

• 업무와 데이터의 관계 및 데이터 사이의 관계 

(2) 프로세스 관점(Process, How)

• 진행되고 있거나 진행되어야 하는 업무

(3) [데이터-프로세스 간의] 상관 관점(Data vs Process)

• 데이터에 대한 업무 처리 방식의 영향(Interaction)

 

2. 데이터 모델의 기본 개념의 이해

1) 데이터 모델링의 정의

(1) 데이터 모델링

• 정보 시스템 구축을 위한 데이터 관점의 업무 분석 기법
• 정보에 대한 표기법을 통일하여 업무 내용 분석 정확도 증대
• 데이터 모델을 기초로 DB 생성

(2) 데이터 모델링을 하는 주요한 이유 

• 정보시스템 구축의 대상이 되는 업무 내용을 정확하게 분석해야 함
• 정확하게 분석된 모델을 실제 데이터베이스를 개발 및 관리하는 데 사용해야 함

-> 데이터베이스를 구축하는 것 뿐만 아니라, 데이터 모델링 자체의 업무를 설명하고 분석하는 것도 매우 중요

 

2) 데이터 모델이 제공하는 기능

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

 

3) 데이터 모델링의 중요성 및 유의점

(1) 파급효과(Leverage)

시스템 구축 시 대규모의 데이터 이행을 성공적으로 수행하기 위한 단위 테스트들이 반복되는데,
각 단위 테스트들이 성공적으로 완료되면 이를 하나로 묶어 병행테스트(통합테스트) 진행
-> 데이터 구조의 변경으로 인한 수많은 영향 분석을 진행한 후에 해당 분야의 실제적인 변경 작업을 진행해야 함
=> 전체 시스템 구축 프로젝트에서 큰 위험요소가 될 수 있음

(2) 간결한 표현(Conciseness)

• 복잡한 정보 요구사항과 한계를 간결하게 표현 
  -> 복잡한  정보 요구사항 파악 시, 간결하게 그려진 데이터 모델을 리뷰하며 파악하는 것이 빠름
• 데이터 모델은 시스템을 구축하는 관련자들이 설계자의 정보요구사항을 이해하고,
  이를 운용할 수 있는 애플리케이션을 개발하고 데이터 정합성을 유지할 수 있도록 해야 하기 때문

(3) 데이터 품질(Data Quality)

데이터베이스에 담겨 있는 데이터는 기간이 오래되면 될수록 활용가치가 높아지는 특성이 있음

-> 데이터 구조의 문제로 정확성이 떨어지는 데이터라면 중복 데이터 미정의/데이터 구조의 비즈니스 정의의 불충분/동일한 성격의 데이터를 통합하지 않고 분리하여 나타나는 데이터 불일치 등의 문제가 발생하게 되어 활용가치 감소

 

1. 유일성: 여러 장소에 데이터를 중복으로 저장하지 않도록 함

2. 유연성: 데이터 정의를 데이터 사용 프로세스와 분리

3. 일관성(Inconsistency): 데이터와 데이터 간 상호 연관 관계에 대해 명확히 정의

 

4) 이해관계자

• 프로젝트 개발자(가장 중요), DBA, 전문 모델러. 현업업무전문가
  -> 완성된 모델을 정확히 해석할 수 있어야 함

 

3. 데이터 모델링의 3단계 진행

* 개념-논리-물리데이터 모델 요약

*실제 프로젝트에서는 개념적 -> 논리적 -> 물리적 모델링을 순서대로 수행하는 경우는 드뭄

데이터 모델링	내용	수준	사용 목적
개념적 데이터 모델링	- 추상화 수준이 높고, 업무중심적이고 포괄적인 수준의 모델링 진행 - 엔터티와 속성을 도출하고 ERD를 작성함 - 전사적 데이터 모델링(데이터 모델링 과정이 전 조직에 걸쳐 이루어지는 것) - 조직/사용자의 데이터 요구사항을 찾고 분석하는데서 시작	추상적	- EA(전사아키텍처, Enterprise Architecture)수립 시 많이 이용 - 어떠한 자료가 중요하고 유지되어야 하는지 결정 - 조직과 다양한 데이터베이스 사용자에게 중요한 데이터를 나타내기 위해 사용됨(데이터 요구 사항을 발견할 수 있게 함) - 현 시스템이 어떻게 변형되어야하는가를 이해함
논리적 데이터 모델링	-  정규화를 수행하여 데이터 모델의 독립성과 재사용성 높임 - 식별자를 도출하고 속성과 관계 등을 정의   -> 시스템으로 구축하고자 하는 업무에 대해 Key, 속성, 관계 등을 정확하게 표현 - 논리 데이터 모델은 데이터 모델링 최종 완료 상태라 할 수 있음	중간	- 데이터베이스 설계에서 비즈니스 정보의 논리적인 구조와 규칙을 명확하게 표현하기 위함 - 누가 어떻게 데이터에 엑세스하며, 비즈니스 데이터에 존재하는 사실들을 인식하여 기록 - 물리적인 스키마 설계를 하기 전 단계의 '데이터 모델' 상태로, 데이터 모델링 과정에서 가장 핵심이 되는 부분
물리적 데이터 모델링	- 실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격을 고려하여 DB 설계(=구축)  - 테이블, 칼럼 등으로 표현되는 물리적인 저장구조와 사용될 저장 장치, 자료를 추출하기 위해 사용될 접근 방법 등을 이 단계에서 결정	구체적	- 논리 데이터 모델을 데이터 저장소로써 어떻게 물리적으로 컴퓨터 하드웨어에 표현할지 정의 - 계층적 데이터베이스 관리 시스템 환경에서는, 데이터베이스 관리자가 물리적 스키마를 설계하고 구현하기 위해 보다 많은 시간을 투자해야 함

 

※ 프로젝트 생명주기(Life Cycle)에 따른 데이터 모델

• 프로젝트 생명주기: 계획 > 분석 > 설계 > 개발 > 테스트 > 전환/이행 단계로 구성됨
• 계획과 분석 단계는 개념적 모델링, 분석 단계는 논리적 모델링, 설계 단계는 물리적 모델링에 해당

• Waterfall 기반 : 데이터 모델링의 위치가 분석과 설계단계로 구분되어 명확하게 정의
• 정보공학, 구조적 방법론 : 분석단계에서 논리적 데이터 모델링, 설계단계에서 물리적인 데이터 모델링을 수행
• 나선형 모델(RUP, 마르미) : 업무 크기에 따라 분석, 설계단계 양쪽에서 수행

 

4. DB의 3단계 구조

• DB 독립성 확보를 목표로 함
  -> 데이터의 중복성과 데이터 복잡도 증가로 인한 유지보수 비용 증가 + 요구사항 대응 저하

1)  3층 스키마(3-level Schema)

• 외부 스키마: 각 사용자 단계의 개인적 DB 스키마, 사용자 관점, 응용 프로그램이 접근하는 DB를 정의함
• 개념 스키마: 조직 전체의 통합된 DB 스키마, 설계자 관점 데이터 모델링의 지향점
• 내부 스키마: 물리적으로 데이터가 저장되는 방법을 표현하는 스키마, 개발자 관점, 물리적 저장 구조임

 

2) 데이터 독립성

• 논리적 독립성: 외부 스키마가 개념 스키마의 변화에 무관함, 논리적 사상 없음
  -> 사용자 특성에 맞게 변경 가능, 통합 구조 변경 가능
• 물리적 독립성: 개념 스키마가 내부 스키마의 변화에 무관함, 물리적 사상 없음
  -> 물리적 구조 영향 없이 개념구조 변경 가능, 개념구조 영향 없이 물리적 구조 변경 가능

 

*사상(Mapping): 상호 독립적인 개념을 연결하는 다리를 의미함

사상	내용	예
외부적/개념적 사상(논리적 사상)	외부적 뷰와 개념적 뷰의 상호 관련성을 정의	- 사용자가 접근하는 형식에 따라 다른 타입의 필드를 가질 수 있음 - 개념적 뷰의 필드 타입은 변화가 없음
개념적/내부적 사상(물리적 사상)	개념적 뷰와 저장된 데이터베이스의 상호 관련성을 정의	만약 저장된 데이터베이스 구조가 바뀐다면 개념적/내부적 사상이 바뀌어야 함 -> 그래야 개념적 스키마가 그대로 남아있게 됨

 

5. 데이터 모델링 3요소: 엔터티, 관계, 속성

• 용어의 구분, 정의

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

 

6. ERD(Entity Relationship Diagram)

• 엔터티는 사각형, 관계는 마름모, 속성은 타원형으로 표현
  -> 현실의 데이터 모두 표현 가능
• ERD 설계 과정
  1. 엔터티 도출
  2. 엔터티 배치
  3. 엔터티 간 관계 설정
  4. 관계명 기술
  5. 관계차수 표현: 1:1, 1:N, M:N
  6. 관계선택사양 표현: 선택, 필수(O 유무로 표현)

• 표기법: IE/Crow's Foot(가장 많이 사용하는 까마귀발 모양 표기법)

7. 좋은 모델링의 요건

• 완전성(Completeness): 필요로 하는 모든 데이터가 데이터 모델에 정의되어 있어야 함
• 중복 배제(Non-Redundancy): 하나의 데이터베이스 내에 동일한 사실은 반드시 한 번만 기록 
• 업무 규칙(Business Rules): 모델링 과정에서의 수많은 업무규칙을 데이터 모델에 표현하고, 데이터 모델을 활용하는 모든 사용자가 공유할 수 있도록 제공
• 데이터 재사용(Data Reusability): 통합 모델이어야만 데이터 재사용성을 향상시킬 수 있음 
• 의사소통(Communication): 정보시스템을 운용/관리하는 사람들이 업무 규칙들을 동일한 의미로 받아들이고, 정보시스템을 활용할 수 있게 함
• 통합성(Integration): 동일한 성격의 데이터를 한 번만 정의하기 위해서는, 공유 데이터에 대한 구조를 여러 업무 영역에서 공통으로 사용하기 용이하게 정의할 수 있어야 함