[목차]
1과목 데이터 모델링의 이해는 2개의 장과 각각의 절로 이루어져 있다.
1장은 1~3절 (1), 4~5절 (2)로 분할했다.
1장 데이터 모델링의 이해
1절 데이터모델의 이해
2절 엔터티
3절 속성
[내용]
1절 데이터모델의 이해
1. 모델링의 특징
1) 추상화
2) 단순화
3) 명확화
* 모델링의 정의 : 현실세계를 추상화, 단순화, 명확화하기 위해 일정한 표기법에 의해 표현하는 기법
2. 모델링의 3가지 관점
1) 데이터 관점(What, Data) : 데이터 중심 모델링
2) 프로세스 관점(How, Process) : 업무 중심. 업무가 실제 하고 있는 일은 무엇인지, 무엇을 해야 하는지를 모델링
3) 상관 관점(Data vs Process) : 업무 처리에 따라 데이터는 어떻게 영향을 받고 있는지 모델링
3. 데이터 모델링의 정의
1) 정보시스템을 구축하기 위한 데이터 관점의 업무 분석 기법
2) 현실 세계의 데이터에 대해 약속된 표기법에 의해 표현되는 과정
3) 데이터베이스를 구축하기 위한 분석/설계의 과정
4. 데이터 모델링의 중요성
1) 파급효과(Leverage)
- 시스템 구축 작업중에서 다른 어떤 설계 과정보다 데이터 설계가 중요함
2) 복잡한 정보 요구사항의 간결한 표현(Conciseness)
- 데이터 모델은 구축할 시스템의 정보 요구사항과 한계를 가장 명확하고 간결하게 표현할 수 있는 도구
3) 데이터 품질(Data Quality)
- 데이터의 중복, 비유연성, 비일관성을 피해야 하는데 이러한 데이터 품질을 저해시키는 경우가 발생할 수 있음.
5. 데이터 모델링시 유의점(피해야 하는 것들)
1) 중복
- 데이터베이스가 여러 장소에 같은 정보를 중복하여 저장하면 안됨(리소스 낭비)
2) 비유연성(Inflexibility)
- 데이터의 정의를 데이터의 사용 프로세스와 분리함으로써 데이터 혹은 프로세스의 작은 변화가 애플리케이션과
데이터베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄인다. 사소한 업무변화에도 데이터 모델이 수시로 변경
됨으로써 유지보수의 어려움을 가중시킬 수 있기 때문에..
3) 비일관성(Inconsistency)
- 개발자가 다른 데이터와 모순된다는 고려없이 일련의 데이터를 수정할 수 있음. 이는 데이터의 중복이 없더라도 발생
할 수 있음. 최대한 일관성있게 데이터 관리 필요..
6. 데이터 모델링의 3단계 진행
1) 개념적 데이터 모델링
- 추상화 수준이 높고 업무중심적, 포괄적 수준의 모델링 진행.
- 전사적 데이터 모델링(Enterprise Data Modeling), EA 수립시 많이 사용
2) 논리적 데이터 모델링
- 시스템으로 구축하고자 하는 업무에 대해 Key, 속성, 관계 등을 정확하게 표현
- 재사용성이 높음.
3) 물리적 데이터 모델링
- 성능, 저장 등 물리적인 성격을 고려 (실제로 데이터베이스에 이식할 수 있도록)
* 프로젝트 생명주기(Life Cycle)에서 데이터 모델링
- 라이프사이클 : 정보전략계획 -> 분석 -> 설계 -> 개발 -> 테스트 -> 전환/이행
- 정보전략계획(또는 분석에서도) 단계 : 개념적 데이터 모델링
- 분석 단계 : 논리적 데이터 모델링
- 설계 단계 : 물리적 데이터 모델링
7. 데이터독립성을 확보하면
1) 각 View의 독립성을 유지하고 계층별 View에 영향을 주지 않고 변경이 가능하다.
2) 단계별 Schema에 따라 데이터 정의어(DDL)와 데이터 조작어(DML)가 다름을 제공한다.
3) 유지보수비용 절감, 데이터 중복성, 복잡도 저하 가능
8. 데이터독립성과 데이터베이스 3단계 구조
1) 외부스키마 (사용자 관점)
- View 단계 여러개의 사용자 관점으로 구성. 개개 사용자가 보는 개인적 DB스키마
- DB의 개개 사용자나 응용프로그래머가 접근하는 DB 정의
2) 개념스키마 (통합 관점)
- 모든 사용자 관점을 통합한 조직 전체의 DB를 기술하는 것
- 모든 응용시스템들이나 사용자들이 필요로하는 데이터를 통합한 조직 전체의 DB를 기술한 것으로
DB에 저장되는 데이터와 그들간의 관계를 표현하는 스키마
3) 내부스키마 (물리적 관점)
- DB가 물리적으로 저장된 방식
- 물리적 장치에서 데이터가 실제적으로 저장되는 방법을 표현하는 스키마
4) 논리적 독립성
- 개념스키마가 변경되어도 외부스키마에는 영향을 미치지 않도록 지원
- 논리적 구조가 변경되어도 응용프로그램에 영향 없음
5) 물리적 독립성
- 내부스키마가 변경되어도 외부/개념스키마는 영향 안받도록 지원
- 저장장치의 구조변경은 응용프로그램과 개념스키마에 영향 없음
9. 사상(Mapping) : 상호독립적인 개념을 연결해주는 다리
1) 외부적-개념적 매핑 (논리적 매핑)
- 외부적 뷰와 개념적 뷰의 상호 관련성을 정의
2) 개념적-내부적 매핑 (물리적 매핑)
- 개념적 뷰와 저장된 데이터베이스의 상호관련성 정의
10. 데이터 모델링의 3가지 요소
1) 업무가 관여하는 어떤 것(Things)
2) 어떤 것이 가지는 성격(Attributes)
3) 업무가 관여하는 어떤것 간의 관계 (Relationships)
* 엔터티 = 릴레이션 = 테이블
속성 = 컬럼
인스턴스 = 어커런스 = 튜플 = 로우
11. ERD
1) 데이터 모델 표기법인 ERD의 이해
- 1976년 피터첸이 Entity-Relationship Model (E-R Model)이라는 표기법을 만들었다.
- ERD : 각 업무분석에서 도출된 엔터티와 엔터티간의 관계를 이해하기 쉽게 도식화된 다이어그램으로 표시하는 방법
- 해당 업무에서 데이터의 흐름과 프로세스와의 연관성을 이해하는데 가장 중요한 표기법이자 산출물
(단순히 도식화된 그림 정도로만 생각하지 않음)
2) 표기법들
3) 작성 순서
- 가장 중요한 엔터티를 왼쪽 상단에 배치하고 이것을 중심으로 다른 엔터티를 나열하면서 전개
(사람의 눈이 따라가기에 편리한 데이터 모델링 전개 가능)
- 가장 중요한 엔터티는 왼쪽 상단에서 조금 아래쪽 중앙에 배치하여 향후 관계 연결시 선이 꼬이지 않게 함.
12. 데이터 모델링의 이해관계자
13. 좋은 데이터 모델의 요소
1) 완전성 : 업무에 필요한 모든 데이터가 데이터 모델에 정의되어 있어야 함.
2) 중복 배제 : 동일한 사실은 한번만 저장해야함.
3) 업무 규칙 : 데이터 모델 분석만으로도 비즈니스 로직이 이해되어야 함.
4) 데이터 재사용 : 데이터 통합성과 독립성 고려해야 함. 가능한 적은 테이블, 간결한 모델
5) 의사소통 : 데이터 모델을 보고 이해당사자들끼리 의사소통이 이루어져야 함.
6) 통합성 : 동일한 데이터는 유일하게 정의해서 다른 영역에서 참조해야 함.
2절 엔터티
14. 엔터티의 개념
1) 엔터티는 사람, 장소, 물건, 사건, 개념 등의 명사에 해당한다.
2) 엔터티는 업무상 관리가 필요한 관심사에 해당한다.
3) 엔터티는 저장이 되기 위한 어떤 것(Thing)이다.
* 즉, 엔터티란 '업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것(Thing)으로 설명할 수 있다.
15. 엔터티의 특징
1) 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.
- 예. 환자, 토익의 응시횟수...
2) 유일한 식별자에 의해 식별이 가능해야 한다.
3) 영속적으로 존재하는 인스턴스의 집합이어야 한다 (2개 이상)
4) 엔터티는 업무 프로세스에 의해 이용(CREATE, READ, UPDATE, DELETE)되어야 한다.
5) 엔터티틑 반드시 속성이 있어야 한다.
- 예외적으로 관계 엔터티는 주식별자 속성만 가지고 있어도 된다
6) 엔터티는 다른 엔터티와 최소 1개 이상의 관계가 있어야 한다.
- 통계 엔터티의 경우는 통계업무만을 위해 정의되므로 관계가 생략될 수 있음,
- 코드 엔터티의 경우는 읽기 효율성이 저하될 수 있어 관계를 설정할 이유가 없음,
- 시스템 처리시 내부 필요에 의한 엔터티(e.g. 트랜잭션 로그 테이블) 의 경우 관계 생략
16. 엔터티의 분류
1) 유무형에 따른 분류
- 유형엔터티 : 사원 물품, 강사
(물리적인 형태가 있고 안정적이며 지속적으로 활용되는 엔터티, 업무로부터 엔터티를 구분하기 가장 용이)
- 개념엔터티 : 조직, 보험상품
(물리적인 형태는 존재하지 않고 관리해야할 개념적 정보로 구분이 되는 엔터티)
- 사건엔터티 : 주문, 청구, 미납
(업무를 수행함에 따라 발생되는 엔터티로서 비교적 발생량이 많으며 각종 통계자료에 이용될 수 있다)
2) 발생시점에 따른 분류
1) 기본엔터티 : 사원, 부서, 고객, 상품, 자재
- 업무에 원래 존재하는 정보로서 다른 엔터티와 관계에 의해 생성되지 않고 독립적으로 생성이 가능
- 자신은 타 엔터티의 부모의 역할을 하게 된다
2) 중심엔터티 : 계약, 사고, 예금원장, 청구, 주문, 매출
- 본 엔터티로부터 발생되고 그 업무에 있어서 중심적인 역할을 한다
- 데이터의 양이 많이 발생되고 다른 엔터티와의 관계를 통해 많은 행위엔터티를 생성
3) 행위엔터티 : 주문목록, 사원변경이력
- 2개 이상의 부모엔터티로부터 발생되고 자주 내용이 바뀌거나 데이터량이 증가
- 상세 설계단계나 프로세스와 상관모델링을 진행하면서 도출
17. 엔터티의 명명
1) 가능하면 현업업무에서 사용하는 용어를 사용한다.
2) 가능하면 약어를 사용하지 않는다.
3) 단수 명사를 사용한다
4) 모든 엔터티중에서 유일한 이름이 부여되어야 한다.
5) 엔터티 생성 의미대로 이름을 부여한다.
3절 속성
18. 속성(Attribute)의 개념
1) 업무에서 필요로 한다
2) 의미상 더 이상 분리되지 않는다.
3) 엔터티를 설명하고 인스턴스의 구성요소가 된다
* 즉, 속성은 업무에서 필요로 하는 인스턴스에서 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위
19. 엔터티, 인스턴스, 속성, 속성값의 관계
1) 1개의 엔터티는 2개 이상의 인스턴스의 집합이어야 한다
2) 1개의 엔터티는 2개 이상의 속성을 갖는다
3) 1개의 속성은 1개의 속성값을 갖는다
* 속성은 엔터티에 속한 엔터티에 대한 자세하고 구체적인 정보를 나타내며 각각의 속성은 구체적인 값을 갖게 된다
* 속성 : 이름, 주소, 생년월일과 같은 각각의 값을 대표하는 이름들
* 속성값 : 홍길동, 서울시 강서구, 1967년 12월 31일과 같이 각각의 이름에 대한 구체적인 값들
20. 속성의 표기법
21. 속성의 특징
1) 엔터티와 마찬가지로 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다
2) 정규화 이론에 근간하여 정해진 후, 주식별자에 함수적 종속성을 가져야 한다
3) 하나의 속성에는 1개의 값만을 가진다.
22. 속성의 분류 1 (특성에 따른 분류)
1) 기본속성 : 업무분석을 통해 바로 정의한 속성
2) 설계속성 : 원래 업무상 존재하지는 않지만 설계를 하면서 도출해내는 속성
3) 파생속성 : 다른 속성으로부터 계산이나 변형이 되어 생성되는 속성
* 예시
23. 속성의 분류 2 (엔터티 구성방식에 따른 분류)
1) PK(Primary Key) 속성 : 엔터티를 식별할 수 있는 속성
2) FK(Foreign Key) 속성 : 다른 엔터티와의 관계에서 포함된 속성
3) 일반 속성 : 엔터티에 포함되어 있고 PK, FK에 포함되지 않은 속성
* 예시
* 복합 속성 : 주소 속성에 시, 구, 동, 번지 등과 같은 여러 세부 속성들로 구성
* 단순 속성 : 나이, 성별 등과 같이 더 이상 다른 속성들로 구성될 수 없는 단순한 속성
* 단일값 속성 : 주민등록번호 처럼 반드시 하나의 값만 존재
* 다중값 속성 : 전화번호라고 하면 집전화, 회사전화, 휴대폰번호 등과 같이 여러개의 값 존재 가능
(하나의 엔터티에 포함될 수 없으므로 1차 정규화와 같은 조치 필요)
24. 도메인
1) 정의 : 각 속성이 가질 수 있는 값의 범위
- 학생 엔터티에서 학점이라는 속성의 도메인은 0.0 ~ 5.0 사이의 실수 값
- 주소라는 속성은 길이가 20자 이내인 문자열
25. 속성의 명명
1) 해당업무에서 사용하는 이름을 부여한다.
2) 서술식 속성명은 사용하지 않는다
3) 약어 사용은 가급적 제한한다.
4) 전체 데이터모델에서 유일성 확보하는 것이 좋다.