2018년 11월 30일
데이터 모델링 (Data Modeling)
I. 데이터 표현 추상화, 데이터 모델링
가. 데이터 모델링 (Data Modeling)의 개념
- 현실 세계의 업무 프로세스를 추상화하여 데이터베이스의 데이터로 표현하기 위한 설계 과정
나. 데이터 모델링의 필요성
- DBMS 구축에 필요한 제반 기술들의 효율적 적용 방안 제시
- 업무 조직과 기술 조직 간 의사소통 및 중재
- 잠재적 위험 요소 조기 발견 및 해결 방안 제시
- 기존 설계 사항의 추후 변경에 따른 사업 일정 지연 방지
다. 데이터 모델링의 단계
| 구분 | 단계 | 설명 |
|---|---|---|
| 아키텍처 관점 | 개념적 설계 | – DB에 저장 데이터를 모형으로 표현 – 핵심엔티티 추출, 전체 데이터 골격 – ERD(Entity Relationship Diagram)작성 |
| 논리적 설계 | – 엔티티와 어트리뷰트 관계 구조 설계 – 스키마, 식별자 설계, 정규화 수행 | |
| 구체화 관점 | 물리적 설계 | – 데이터베이스 스키마 물리 설계 – 사용할 DBMS, 데이터 타입, 크기 선정 – 데이터 사용량 분석, 비(반) 정규화 |
| 구현 | – DBMS Software 설치 및 환경 구성 – DB 및 테이블 생성, 환경 구성 |
II. 데이터 모델링의 개념도 및 단계
가. 데이터 모델링의 개념도
 |
나. 데이터 모델링의 3가지 관점
| 관점 | 핵심기술 | 설명 |
|---|---|---|
| 데이터 관점 | Entity Type | – 업무와 데이터 간 관계 모델링 – 데이터와 데이터 간 관계 모델링 |
| 프로세스 관점 | SQL | – 업무를 통해 처리하는 양식 모델링 – 무엇을 어떻게 관점으로 모델링 |
| 데이터 프로세스 | Relation -ship | – 업무에서 처리 방법에 따른 영향 – 데이터가 받는 영향도 분석 |
| 상관 관점 | CRUD | – 상관 관계에 따른 모델링 – CRUD Matrix 기법 적용 |
III. 요구사항 분석
가. 요구사항 분석 개념
- 현재 및 미래의 업무처리를 위해 데이터베이스 내 존재해야 하는 데이터 정의 및 문서화 과정
나. 요구사항 분석 단계
| 단계 | 설명 |
|---|---|
| 설계 범위 정의 | – 업무 영역의 설계 범위 포함 요건 정의 |
| 메타데이터 표준안 | – 메타데이타 지침 마련, 표준안 수립 |
| 사용자뷰 및 자료 수집 | – 업무 수행 위한 자료 집합, 외부 스키마 |
| 자료사전 구축 | – 자료 및 정보의 본질에 대해 기술 |
| 사용패턴 조사 | – 트랜잭션 처리를 위한 논리적인 경로 |
| 운영 요구 조사 | – 운영 시 보안, 백업, 복구 사항 등 조사 |
IV. 개념적 데이터 모델링
가. 개념적 데이터 모델링의 개념
- 업무 요건 충족 위해 주제 영역과 핵심 데이터 집합 간의 관계를 정의하는 상위 수준 데이터 설계
나. 개념적 데이터 모델링의 절차
 |
– 데이터 집합 간 관계 정의하는 상위 수준 데이터 모델 설계
| 절차 | 기법/종류 | 설명 |
|---|---|---|
| 주제영역 도출 | – 상향식, 하향식 – Inside-out,혼합 | – 하위 주제 영역 or 데이터 집합들로 구성, 업무/대응 |
| 핵심데이터 집합도출 | – 독립, 의존중심 – 의존특성 | – 데이터 보관 단위로 주제 영역 중심데이터 집합 정의 |
| 관계 설정 | – 1:1, 1:N, M:N – 순환 관계 | – 업무적 연관성에 따라 개체 간 갖는 연관 설정 |
| 핵심속성 정의 | – 원자단위검증 – 유일값, 상세화 | – 데이터 집합 특성을 나타내는 항목 |
| 식별자 정의 | – PK, CK, AK – FK로 구분 | – 데이터 집합 식별해주는 속성(PK로 구현) |
- 위 절차로 ERD(Entity-Relation Diagram) 작성
다. 개념적 데이터 모델링의 핵심 엔티티 도출
- 업무에서 관리하려는 데이터 형태로 가장 중심이 되는 데이터 집합, 핵심 업무 프로세스와 대응
- 데이터 집합 중 독립 중심 데이터 집합이나 의존 중심 데이터 집합이 핵심 데이터 집합의 대상
라. 개념적 데이터 모델링 기법
| 구분 | 개체분석(Entity Analysis) | 속성합성(Attib. Synthesis) |
|---|---|---|
| 개체 식별 | – 뷰 통합 방식(Top-down) – 개체 → 속성/키 식별 | – Bottom-up 반식 – 속성/키 → 개체 도출 |
| 장점 | – 부작용 없음 | – 초기 설계자 부담 적음 |
| 단점 | – 설계자 업무 통달 필요 | – 중복/재구성 필요 발생 |
마. 트랜잭션 모델링
- 트랜잭션을 개념적 시스템 독립적으로 정의
- 트랜잭션의 입출력 기능, 형태만 정의
- 응용 및 트랜잭션 필요 데이터 식별 확인
V. 논리적 데이터 모델링
가. 논리적 데이터 모델링의 개념
- 업무를 모델링 표기법으로 형상화하여 직관적이며, 특정 DB 모델 기반 논리적 스키마로 변환하는 과정
나. 논리적 데이터 모델링의 주요 Task
| 순서 | Task | 설명 |
|---|---|---|
| 특정 순서 없이 진행 | 엔티티타입 도출 | – 기본, 중심, 행위 엔티티 도출 |
| 관계 도출 | – 엔티티 타입 간 관계 도출 | |
| 식별자 도출 | – PK, FK, UK, AK 등 정의 | |
| 속성 도출 | – 기본, 설계, 파생 속성 정의 | |
| 세부사항 도출 | – 용어사전, 도메인, 속성 규칙 | |
| 정규화 | – 1, 2, 3, BCNF, 4, 5차 정규화 | |
| 통합/분할 | – 엔티티 성격 기반 통합/분할 | |
| 단계말 | 데이터모델 검증 | – 엔티티타입, 속성, 관계 적합성 |
다. 개념적 모델과 논리적 DB 모델의 속성 맵핑
VI. 물리적 데이터 모델링
가. 물리적 데이터 모델링의 개념
논리 데이터 모델을 특정 DBMS에 맞는 물리적 스키마로 만드는 과정
나. 물리 모델로 변환 주요 Task
| 단계 | 과정 | 고려사항 |
|---|---|---|
| 일괄 전환 | 엔티티별 테이블 전환 | – Sub Type 설계 방안 |
| 식별자 Primary Key 정의 | – Artificial Key 검토 – PK 컬럼 순서 검토 | |
| 속성의 컬럼 전환 | – 영문 컬럼명 맵핑 – 데이터 타입/길이 도메인 결정 | |
| Relationship의 컬럼으로 전환 | – 참조 무결성 규칙 및 구현 방안 결정 | |
| 구조 조정 | 수퍼타입/서브타입 모델 전환 | – 트랜잭션 성격 전체/부분 통합 – 데이터 모델 조정 |
| 성능 향상 | 성능 고려한 반정규화 | – SQL 활용 능력 미흡으로 인한 빈번한 비정규화 배제 |
VII. 구현 단계의 모델링
가. 구현 단계 수행 내용
구현 단계는 물리 설계에서 구현된 내용 기반 실질적 데이터베이스를 구축하며 데이터 적재, 이관 수행
나. 구현 단계 주요 과정
| 과정 | 고려사항 |
|---|---|
| 데이터 적재 | – DDL로 생성된 테이블에 데이터 적재 |
| 데이터 변환/이관 | – 기존 DB 변환, 새 테이블에 적재 |
| 데이터 검증 | – 적재 데이터 값 및 구조 검증 수행 |
| APP 연계 | – 주요 APP과 DB 연계 검증 |
| 성능 검증 | – 테이블 접근, 데이터 쿼리 성능 평가 |
| 튜닝 | – APP, 스크립트, 주요코드 변경 튜닝 |
- 개념→논리→물리→구현 단계까지 완료되면 운영 DB완성
About The Author
