제1절 데이터 모델링 개요
모델링의 정의
모델링
- 모형(模型), 축소형(縮小型)
- 가설적 OR 일정 양식에 맞춘 표현(a hypothetical or stylized representation)
- 사건에 관한 양상(aspect)/ 관점(perspective)을 연관된 사람 OR 그룹 위해 명확하게 하는 것
- 모델 = 현실 세계의 추상화된 반영
- 현실세계 - 추상화(모형화)/ 단순화/ 명확화 -> 모델(model)
모델링의 특징
추상화(모형화, 가설적)
현실세계를 일정한 형식에 맞추어 표현을 한다는 의미
= 다양한 현상 -> 일정한 양식인 표기법에 의해 표현
단순화
복잡한 현실세계 -> 약속된 규약에 의해 제한된 표기법 OR 언어로 표현 -> 쉽게 이해할 수 있도록 하는 개념
명확화
누구나 쉬운 이해 -> 대상에 대한 애매모호함 제거 + 정확하게 현상 기술하는 것
모델링의 3가지 관점
모델링 = 데이터관점(Data, What) + 상관관점(Data vs. Process) + 프로세스 관점(Process, How)
데이터관점(Data, What)
업무가 어떤 데이터와 관련 있는지 OR 데이터간의 관계 무엇인지에 대해 모델링하는 방법
데이터와 프로세스의 상관관점(Data vs. Process)
업무가 처리하는 일의 방법 -> 데이터는 어떻게 영향 받고 있는지 모델링하는 방법
프로세스관점(Process, How)
업무가 실제하고 있는 일은 무엇인지 OR 무엇을 해야 하는지를 모델링하는 방법
데이터모델링의 정의
- 정보시스템 구축 -> 해당 업무에 어떤 데이터가 존재하는지 OR 업무가 필요로 하는 정보는 무엇인지 분석하는 방법
- 기업 업무에 대한 종합적인 이해 -> 데이터에 존재하는 업무 규칙(Business Rule) 대해 참(True) OR 거짓(False)을 판별할 수 있는 사실(사실명제)을 데이터에 접근하는 방법(How), 사람(Who), 전산화와는 별개의(독립적인) 관점 -> 명확하게 표현하는 추상화 기법
- 현실세계의 데이터(What) -> 약속된 표기법에 의해 표현하는 과정
- 데이터베이스를 구축하기 위한 분석/설계의 과정
데이터모델링의 특징
- 시스템을 현재 OR 원하는 모습으로 가시화
- 시스템의 구조와 행동 명세화
- 시스템을 구축하는 구조화된 틀 제공
- 시스템을 구축하는 과정에서 결정한 것을 문서화
- 다양한 영역 집중 위해 다른 영역의 세부 사항은 숨기는 다양한 관점 = 추상화
- 특정 목표 -> 구체화된 상세 수준의 표현방법 제공
데이터모델링의 중요성
중요성 | 설명 |
파급효과(Leverage) | 프로젝트 초기에하는 Task 중 가장 중요한 작업 프로젝트 후반부에서 데이터모델 변경시 변경으로 인한 비용손실 및 납기지연가능성 ↑ |
복잡한 정보 요구사항의 간결한 표현(Conciseness) | 정보 요구사항과 한계를 가장 명확하고 간결하게 표현할 수 있는 도구 ex. 건축물; 설계도면 |
데이터 품질(Data Quality) | 데이터품질의 값, 구조, 프로세스 3대 영역 중 구조에 대한 품질에 핵심적인 영향도 = 데이터모델 중복(Duplicaiton), 비유연성(Inflexibility), 비일관성(Inconsistency)의 문제 해결 중요 도구 |
데이터모델링의 3단계
데이터 모델링 | 내용 | 수준 |
개념적 데이터 모델링 | 추상화 수준 ↑/ 업무중심적/ 포괄적인 수준의 모델링 진행 전사적 데이터 모델링 EA 수립시 이용 ↑ |
구체적 \ 추상적 |
논리적 데이터 모델링 | 시스템으로 구축하고자 하는 업무에 대해 Key, 속성, 관계 등 정확하게 표현 재사용성 ↑ |
|
물리적 데이터 모델링 | 실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격 고려하여 설계 |
프로젝트 라이프사이클에서 데이터모델링
일반적으로는 계획 OR 분석단계에서 개념적 데이터 모델링 분석단계에서 논리적 데이터 모델링 설계단계에서 물맂거 데이터 모델링 수행
단, 현실 프로젝트에서는 개념적 데이터 모델링 생략된 개념/ 논리 데이터 모델링이 분석단계 때 수행
3단계 데이터베이스 구조
스키마 구성
항목 | 내용 | 비고 |
외부 스키마(External Schema) | View 단계 여러 개의 사용자 관점으로 구성 = 개개 사용자 단계로서 개개 사용자가 보는 개인적 DB 스키마 / DB 개개 사용자 OR 응용프로그래머가 접근하는 DB 정의 |
사용자 관점 접근하는 특성에 따른 스키마 구성 |
개념 스키마(Conceptual Schema) | 개념 단계 하나의 개념적 스키마로 구성 모든 사용자 관점 통합한 조직 전체 DB 기술하는 것 / 모든 응용시스템들 OR 사용자들이 필요로 하는 데이터 통합한 조직 전체의 DB를 기술한 것으로 DB에 저장되는 데이터와 그들 관계를 표현하는 스키마 |
통합 관점 |
내부 스키마(Inernal Schema) | 내부단계, 내부 스키마로 구성, DB가 물리적으로 저장된 형식 / 물리적 장치에서 데이터가 실제적으로 저장되는 방법을 표현하는 스키마 |
물리적 저장구조 |
독립성
독립성 | 내용 | 특징 |
논리적 독립성 | 개념 스키마가 변경 -> 외부 스키마에는 영향 미치지 X 지원 / 논리적 구조 변경 -> 응용 프로그램 영향 X |
사용자 특성에 맞는 변경 가능 / 통합 구조 변경 가능 |
물리적 독립성 | 내부 스키마 변경 -> 외부/ 개념 스키마 영향 X / 저장장치의 구조변경 -> 응용프로그램과 개념 스키마에 영향 X |
물리적 구조 영향 X 개념 구조 변경 가능 / 개념구조 영향 X 물리적 구조 변경 가능 |
사상
사상 | 내용 | ex. |
외부적/ 개념적 사상 (논리적 사상) |
외부적 뷰와 개념적 뷰의 상호 관련성 정의 | 사용자가 접근하는 형식 -> 다른 타입의 필드 가질 수 O 개념적 뷰의 필드 타입 변화 X |
개념적/ 내부적 사상 (물리적 사상) |
개념적 뷰와 저장된 데이터 베이스의 상호관련성 정의 | 만약 저장된 데이터베이스 구조 변경 -> 개념적/ 내부적 사상 변경 => 개념적 스키마가 그대로 남아있게 됨 |
데이터 모델링의 3가지 개념
- 업무가 관여하는 어떤 것(Things)
- 업무가 관여하는 어떤 것 간의 관계(Relationships)
- 어떤 것이 가지는 성격(Attributes)
데이터모델링의 단수/복수 개념
개념 | 복수/ 집합 개념 타입/ 클래스 |
개별/ 단수 개념 어커런스/ 인스턴스 |
어떤 것(Thing) | 엔터티 타입(Entity type) | 엔터티(Entity) |
엔터티(Entity) | 인스턴스(Instance), 어커런스(Occurrence) |
|
어떤 것 간의 연관 (Associaton between Things) |
관계(Relationship) | 패어링(Pairing) |
어떤 것의 성격 (Characteristic of a Things) |
속성(Attribute) | 속성값(Attribute Value) |
데이터 모델링의 이해관계자
- 정보시스템을 구축하는 모든 사람들(전문적으로 코딩만하는 사람 포함); 데이터 모델링도 전문적으로 할 수 있거나 적어도 완성된 모델을 정확하게 해석할 수 있어야 = 프로젝트에 참여한 모든 IT 기술자들; 데이터 모델링에 대해 정확하게 알아야
- IT 기술에 종사하거나 전공X 해당 업무에서 정보화 추진하는 위치 사람; 데이터 모델링에 대한 개념 및 세부사항에 대해 어느 정도 지식 O
데이터모델링표기법
ERD작업순서
ERD
각 업무분석에서 도출된 엔터티와 엔터티간의 관계를 이해하기 쉽게 도식화된 다이어그램으로 표시하는 방법
/ 실제 프로젝트; 도식화된 그림 정도 X 해당 업무에서 데이터의 흐름과 프로세스와의 연관성을 이야기하는 데 가장 중요한 표기법
엔터티 배치
엔터티를 처음에 어디에 배치하는지는 데이터 모델링 툴 상관 없이 중요
일반적으로 사람의 눈 왼 -> 오/ 위 -> 아래 => 데이터 모델링; 가장 중요한 엔터티를 왼쪽 상단 배치
관계의 연결
엔터티에 배치가 되면 관계를 정의한 분석서 보고 서로 관련있는 엔터티간의 관계 설정
초기) 모두 PK로 속성이 상속되는 식별자 관계 설정/ 중복되는 관계가 발생 X, Circle 관계 발생 X 유의
관계명 표시
관계 설정 -> 연결된 관계에 관계이름 부여
관계이름; 현재형 사용, 지나치게 포괄적인 용어(ex. 이다, 가진다 등) 사용 X
관계차수와 선택성 표시
관계에 대한 이름 지정 -> 관계차수(Cardinality; 관계가 참여하는 성격 중 엔터티내에 인스턴스들이 얼마나 관계에 참여하는 지) 표현
좋은 데이터모델의 요소
완전성(Completeness)
업무에서 필요로 하는 모든 데이터가 데이터 모델에 정의
중복배제(Non-Redundancy)
하나의 데이터베이스 내에 동일한 사실은 반드시 한 번만 기록하여야 함
업무규칙(Business Rules)
무규칙(Business Rules)을 데이터 모델에 표현하고 이를 해당 데이터 모델을 활용하는 모든 사용자가 공유
데이터 재사용(Data Reusability)
데이터의 통합성과 독립성에 대해 충분히 고려
의사소통(Communication)
정보시스템에서 운용, 관리하는 많은 관련자들이 설계자가 정의한 업무 규칙들을 동일한 의미로 받아들이고 정보시스템을 활용할 수 있게 하는 역할
통합성(Integration)
가장 바람직한 데이터 구조의 형태 = 동일한 데이터는 조직의 전체에서 한 번만 정의/ 이를 여러 다른 영역에서 참조, 활용
'Computer Science > 데이터베이스' 카테고리의 다른 글
[Structured Query Language] SQL 개발자 자격증/ 핵심정리/ PDF 첨부 (0) | 2022.10.27 |
---|---|
[Structured Query Language] 1과목: 데이터 모델링 이해_제2절 엔터티/ 제3절 속성/ 제4절 관계 (0) | 2022.10.09 |
[Oracle-SQL] 회사 데이터베이스3 (0) | 2022.06.13 |
[Oracle-SQL] 회사 데이터베이스2 (0) | 2022.06.13 |
[Oracle-SQL] 회사 데이터베이스 (2) | 2022.06.07 |