제1장 데이터 이해

제1절 데이터 품질 관리 프레임워크

제2절 표준 데이터

제3절 모델 데이터

제4절 관리 데이터

제5절 업무 데이터

 

제2장 데이터 구조 이해

제1절 개념 데이터 모델

제2절 데이터 참조 모델

제3절 논리 데이터 모델

제4절 물리 데이터 모델

제5절 데이터베이스

제6절 사용자 뷰

 

제3장 데이터 관리 프로세스 이해

제1절 데이터 관리 정책

제2절 데이터 표준 관리

제3절 요구 사항 관리

제4절 데이터 모델 관리

제5절 데이터 흐름 관리

제6절 데이터베이스 관리

제7절 데이터 활용 관리

 

1.데이터 이해

1.1데이터 품질 관리 프레임워크

가.데이터 품질 관리 프레임워크

-데이터 품질 관리: 조직 내외부의 지식 노동자와 최종 사용자의 기대를 만족시키기 위한 지속적인 데이터 및 데이터 서비스 개선 활동

 

-데이터 품질 요소: 데이터 값, 데이터 구조, 데이터 관리 프로세스

1.2표준 데이터

가.정의 및 관리 목적

-정보시스템에서 사용되는 용어 및 도메인, 코드, 기타 데이터 관련 요소에 대해 공통된 형식과 내용으로 정의하여 사용하는 표준 관련 데이터

 

나.세부 관리 대상

표준단어,도메인,코드,용어

1)표준단어 사전(표참일대)

-기업이나 기관에서 업무상 사용되며 일정한 의미를 갖고 있는 최소 단위의 단어를 정의한 사전

#기준

*표준성: 대상업무 범위에서 사용, 사전적 의미의 단어, 약어 사용 최소화

*참조가능성: 새로운 업무에서 참조

*일반성: 일반인도 이해 가능

*대표성: 비슷한 의미의 동의어들을 대표

 

2)표준도메인 사전(표유업)

-전사적으로 사용되고 있는 데이터 중에서 논리적, 물리적으로 유사한 유형의 데이터를 그룹화하여 해당 그룹에 속하는 데이터의 유형과 길이를 정의한 사전

#기준

*표준성: 공통적으로 사용되는 속성이 대상

*유일성: 동일한 도메인의 다른 이름 선언 방지

*업무지향성: 업무의 특성을 반영

-여러개의 하위도메인으로 구성되거나 하나의 도메인이 여러개의 도메인에 중복 사용 가능

 

3)표준용어 사전(표일업)

-전사적으로 사용하는 엔터티와 속성을 대상으로 표준 단어 사전에 정의된 단어를 조합하여 정의

#기준

*표준성: 동일한 의미의 서로 다른 용어를 표준화

*일반성: 일반적인 의미와 비슷하게

*업무지향성:지나친 약어 사용 자제. 보유중인 표준 단어를 조합하여 생성

-기업의 업무범위내에서 약어를 사용하거나 내부에서 별도로 정의하여 사용가능.

 

4)표준코드(재일정)

-각 산업별로 법적, 제도적으로 사용하는 코드, 내부에서 정의하여 사용하는 코드

#기준

*재사용성: 정부, 기관에서 정의한 코드를 재사용하는게 효과적

*일관성: 업무범위내에서 유일하게 정의

*정보분석성: 가능한 범위의 데이터는 모두 코드화, 임의 텍스트 입력 최소화

 

5)데이터 표준 요소(통일)

-시스템을 설계하고 구축하는데 필요한 데이터 관련 요소의 표준

-데이터 관련 요소 표준 대상은 논리 데이터 모델의 주제 영역, 엔터티, 속성, 관계명을 포함하여 물리적 객체 대상인 Subject Areas, Relationships, Database & Instance, Indexes, Constraints, Sequences, 사용자 정의 Procedures & Functions, Synonyms, Views, Rollback Segments, Tablespaces, File Names, Script Names 등의 명명 규칙을 포함

#기준(통일성, 일관성

*통합성: 전사적으로 통합 관리 및 적용

*일관성: 데이터 모델 및 DB 스키마의 전 영역에 걸쳐 일관되게 적용

 

다.표준 데이터 상관도

1.3모델 데이터

가.정의 및 관리 목적

-데이터 모델을 운용 관리하는데 필요한 데이터

난.세부 관리 대상

-DRM, 개념/논리/물리 데이터 모델에 대한 메타 데이터 및 DBMS 객체 정보

#기준(완일추상최호)

*완전성: 개념, 논리, 물리 데이터 모델에 대한 모든 메타 데이터를 포함

*일관성: 단어, 용어, 도메인 및 데이터 관련 요소 표준을 준수

*추적성: 데이터 모델의 변경 이력에 대한 추적 용이

*상호연계성: 데이터 모델간의 상호 연관 관계를 표현

*최신성: 단계별 데이터 모델과 업무규칙은 물론, 물리 데이터와도 논리적으로 일치

*호환성: 다른 종류의 관리 데이터와도 상호 호환 가능

1.4관리 데이터

가.정의 및 관리 목적

-DB를 효과적으로 운영, 관리하기 위해 필요한 데이터

나.세부 관리 대상

-사용/ 장애 및 보안/ 성능/ 흐름/ 품질

 

1)사용 관리 데이터

-사용자가 DB를 효과적으로 사용할 수 있도록 지원하고 문제를 해결하는데 필요한 관리 데이터

#기준(활만소)

*데이터 활용도: 주기적으로 데이터 사용 추세를 파악하여 데이터 활용 가치 평가

*사용자 만족도: 제공되는 데이터에 대한 만족과 유지되는 데이터의 품질을 보증

*문제해결 소요기간: 문제 발생에서 확인까지 소요되는 시간과 문제 확인 후 해결까지 소요되는 시간을 점검

 

2)장애 및 보안 관리 데이터

-DB의 정상적인 상태 유지나 효과적인 사용을 방해하는 사건을 사전에 예방하거나 사건 발생시에 신속한 복구가 이루어지도록 하는 데이터

#기준(상복통)

*주기적인 상태 기록: 백업주기, 백업방법, 백업데이터의 안전한 보관과 정상적인 복구 여부의 관리

*복구 절차와 규칙: 복구 절차와 적용되는 규칙의 완전성

*접근통제: 사용자 관리와 사용자 접근권한의 관리

 

3)성능 관리 데이터

-DB의 성능을 향상시키는데 필요한 관리 데이터

#기준(점수)

*주기적 성능 점검: 성능 측정 기준과 측정 주기

*성능 향상 수단:성능향상을 위한 절차와 규칙

 

4)흐름 관리 데이터

-하나의 정보시스템 데이터를 다른 정보시스템으로 이동할 때 사용하는 소스 데이터와 타깃 데이터 간의 매핑 정보를 관리하는 데이터

#기준(안유정)

*안전성: 데이터 이동이 필요한 모든 소스와 타겟을 정의, 소스와 타깃간 매핑규칙 정의

*유효성: 매핑규칙 준수, 위배되는 데이터에 대한 클린징 규칙 정의

*데이터 정합성: 매핑규칙을 준수하여 데이터의 정합성 보장

 

5)품질 관리 데이터

-데이터의 정합성을 확보하고 데이터 품질의 유지, 개선을 위한 데이터

#기준(기주검개)

*품질기준: 데이터의 품질 기준 정의, 데이터의 중요도에 따라 등급부여

*품질 점검주기: DB성능과 데이터 품질 등에 대한 측정 주기 설정

*품질 검증 절차와 규칙: 정의된 품질 기준을 적용하기 위한 데이터 품질 검증 절차와 규칙

*품질 개선 절차: 측정된 품질 평가 결과를 반영하여 데이터의 품질을 향상시키고 고품질 데이터를 유지할 절차와 방법

1.5업무 데이터

가.정의 및 관리 목적

-기관이나 기업의 업무 및 비즈니스를 수행하는데 필요한 데이터

나.세부 관리 대상

-원천, 운영, 분석

 

1)원천 데이터

-운영 업무 데이터의 원천이 되는 현실세계의 데이터(일반 문서, PC에 저장된 데이터 파일 등)

#기준(보안신)

*보안성: 허용되지 않은 사용자에게 노출될 위험이 높음

*안전성: 재해발생시 데이터 손실률이 높고 손실된 데이터의 복구가 어려움

*신뢰성: 정확성과 신뢰성을 판단하기 위한 근거

 

2)운영 데이터

-기업 및 기관의 목표 달성을 위해 DB에서 저장, 관리하여 활용하는 데이터. 임시데이터는 제외

#기준(완일최정검사)

*정확성: 원천데이터와 동일하게 오류가 없음

*일관성: 용어 정의, 규정, 표준, 속성 정의, 데이터 형식등과 일치

*최신성: 가장 최근 형태로 갱신. 데이터 최신성 등급(매우중요, 중요, 보통) 부여

*완전성: 완전한 형태, 조직의 목표 달성을 위해 요구되는 충분한 데이터 보유

*사용용이성: 인터페이스, 도움말, 고객지원 기능 등 제공

*검색용이성: 원하는 데이터를 추출하기위한 검색 관련 제반 기능 

 

3)분석 데이터

- 운영 데이터의 추출, 변환, 적재 등의 과정을 통해 생성되는 데이터

#기준(분마요 주통시비)

*분석주기: 운영데이터의 분석 및 변환 주기 결정

*마감기한: 분석용 데이터로 변환하기 위해 이용하는 운영 데이터의 특정 시점

*요약레벨: 요약 수준

*주제지향성: 주제 영역별로 분류

*통합성: 일관된 표준에 따라 분류

*시계열성: 다양한 시점별로 정의

*비휘발성: 검색위주의 데이터로 구성

2.데이터 구조 이해

2.1개념 데이터 모델

가.정의 및 관리 목적

-업무 요건을 충족하는 데이터의 주제 영역과 핵심 데이터 집합을 정의하고 관계를 정의한 모델

나.세부 관리 대상

-주제영역,핵심엔티티,핵심관계

 

1)주제영역

-업무상 친밀도가 높은 데이터 집합을 하나의 주제 영역으로 정의

#기준(원집업)

*원자성: 다른 주제영역의 엔티티나 관계의 영향을 받지 않은 엔티티 집합

*집중성: 단위 주제영역내의 엔티티와 관계는 단위 주제 영역 내에 집중

*업무지향성: 업무적 명확성을 나타내는 단수 단위로 명명

 

2)핵심 엔티티

-업무 영역 내에서 관리하고자 하는 데이터 집합

#기준(집식영사관)

*집합성: 두 개 이상의 속성과 두 개 이상의 데이터 인스턴스를 갖는 데이터 집합

*식별성: 하나 이상의 속성으로 엔티티의 데이터 인스턴스를 유일하게 구분

*영속성: 업무의 활동 주기에 따라 영속적으로 존재

*사용성: 업무 범위내에서 반드시 사용

*관계성: 다른 엔티티와의 관계가 존재

 

3)핵심 관계

-핵심 엔터티 간의 논리적인 관계를 나타낸 것

#기준(선형업)

*선택성: 관계는 필수와 선택을 구별

*형태성: 1:1, 1:M, MM

*업무지향성: 두 엔티티간의 상호 영향을 명확히 표현

2.2데이터 참조 모델

가.정의 및 관리 목적

-업무 영역별, 주제 영역별 표준 데이터 집합, 관리 항목들이 표기되어 재사용이 가능한 데이터 모델

나.세부 관리 대상

1)데이터 참조 모델

-재사용이 가능한 형태의 데이터 모델로 속성 단위, 엔터티, ERD, 전체 업무 영역 단위

#기준(범단표정이분)

*범용성: 범용적으로 다양한 업무 영역에서 참조

*단순성: 비즈니스의 복잡성을 나타낸 데이터 모델은 특정 업무에 국한될 가능성이 높음

*표준성: 데이터 용어는 상식적이고 일반적인 수준에서 이해가능한 용어 사용

*정확성: 참조의 성격

*정보이용성: 엔터티 간의 관계뿐만 아니라 엔터티와 엔터티 간의 정의, 엔터티의 데이터 관리 규칙, 속성 정의도 함께 저장

*분류성: 업무영역과 업종, 데이터 구조 각 단계와 데이터 참조모델의 범위내에서도 분류

2.3논리 데이터 모델

가.정의 및 관리 목적

-개념 데이터 모델을 상세화 하여 논리적인 데이터 집합, 관리 항목, 관계를 정의한 모델

-완전성: 다루는 대상에 대한 데이터 구조정의시 상세하게 정의될 수 있는 모든 정보를 포함

-구체성: 업무에서 다루는 모든 데이터 구조를 구체적으로 정의

-최신성:업무에서 다루는 모든 데이터 구조를 최신의 내용을 관리

나.세부 관리 대상

-주제영역,엔티티,관계,속성

1)주제 영역

-업무상 친밀도가 높은 데이터 집합을 하나의 주제 영역에서 선언

2)엔티티

- 개념 데이터 모델의 정의를 포함하고 이력 관리와 동질성, 독립성 정보가 보다 더 상세히 파악된 서브타입 정보가 추가 가능

#기준(완영식동화)

*완전성:두 개 이상의 속성과 두 개 이상의 인스턴스를 유지

*영속성:현재부터 미래까지 관리할 데이터 집합

*식별성: 엔티티의 인스턴스를 유일하게 구별할 수 있는 하나 이상의 속성 존재

*동질성: 동질의 데이터가 모인 데이터 집합

*정규화: 3차 정규화 권장

 

3)관계

- 개념 데이터 모델의 정의를 포함하고 상세 논리 데이터 모델 단계에서 모든 M:M 관계는 해소

#기준

*선택성: 필수, 선택

*관계형태: 1:1, 1:M, M:M

*관계명칭: 엔티티와 엔티티간의 관계 설정시 관계명 필수

 

4)속성

- 엔터티 내에서 관리하고자 하는 정보의 항목

#기준(원일무보)

*원자성: 의미있는 최소단위까지 분할, 하나의 속성은 한 상태의 정보만 포함

*일관성: 하나의 속성은 하나의 데이터 유형을 가리키며 하나의 데이터만 관리

*무결성: 참조되는 속성의 데이터는 해당 속성을 참조하는 속성의 데이터와 일치

*정보성: 업무와 관련해 의미 있는 범위 내에서 상세화의 수준이 결정

2.4물리 데이터 모델

가.정의 및 관리 목적

-논리 데이터 모델을 DBMS의 특성 및 성능을 고려하여 구체화시킨 모델

나.세부 관리 대상
-주제영역, 테이블, 관계, 컬럼

1)주제 영역

-분산 DBMS의 고려나 업무 영역에 따라 다른 스키마의 설계로 대응을 고려. 

-논리 데이터 모델에서 정의한 주제 영역은 물리 데이터 모델에서 스키마나 서버로 분산될 수도 있으나 경우에 따라서는 하나의 서버에 하나의 스키마 내에서 테이블의 명명 관례에 의하여 물리적 주제 영역을 구분하여 관리 가능

2)테이블

-데이터의 물리적 특성과 DBMS의 특성에 따라 하나의 물리적 저장 장소인 테이블 혹은 서브타입이나 업무적 특성에 따라 하나 이상의 물리적 테이블로 분할 가능

#기준(영식)

*영속성: 현재부터 미래까지 관리

*식별성: 레코드들은 하나 이상의 컬럼 데이터에 의해 구별 가능

 

3)관계

-부모 테이블과 자식 테이블 간의 데이터 생성, 삭제, 변경 규칙을 정의

#기준(생변삭)

*생성규칙: 자식 테이블의 데이터 생성시 부모 테이블에 참조되는 데이터가 반드시 존재

*변경규칙: 부모 테이블의 키 데이터가 변경되면 참조하는 자식 테이블의 참조 데이터는 같이 변경되거나 혹은 자식 데이터가 존재하면 부모 테이블의 키 데이터는 변경 불가

*삭제규칙: 부모 테이블의 데이터가 삭제되면 해당 데이터를 참조하는 자식 테이블의 데이터가 함께 삭제되거나 혹은 자식 데이터가 존재하면 부모 테이블의 데이터는 삭제 불가

4)컬럼

-표준화된 도메인 내에서 업무 규칙이 반영된 데이터를 저장하도록 정의

-하나의 컬럼 데이터는 같은 데이터 유형

2.5데이터베이스

가.정의 및 관리 목적

-물리 데이터 모델을 구현한 결과물이며 구축된 실제 데이터가 저장되는 데이터 저장소

나.세부 관리 대상

-저장공간,테이블,제약조건,인덱스,트리거,DB링크,프로시저,뷰,동의어,Role

1)저장공간

-DB에서 데이터를 저장할 공간을 필요로 하는 테이블과 인덱스를 정의하는 영역

#기준(안보확성)

*안전성: 시스템의 다른 프로그램 수행 영역으로부터 분리되어 안전하게 보호

*보안성: 허가 받지 않은 프로그램이나 사용자에 대하여 접근 제어

*확장성: 저장 공간의 확장과 물리적 디스크 영역의 할당이 충분하고 편리하게 수행

*성능보장: 물리적 디스크는 빠른 성능을 유지할 수 있는 제품과 구조적 배치

 

2)테이블

-엔터티와 속성으로 정의

#기준(주다보논)

*주기성: 테이블내 데이터는 일정한 주기에 따라 백업되거나 성능을 위하여 재생성 가능

*다양성: 적절한 분산 전략과 테이블 저장 공간 정의 방식에 따라 파티션, 클러스터, 인덱스 구성 테이블 등 여러 형태로 정의

*보안성: 권한과 사용에 따라 제한된 범위의 사용자에게 테이블 단위, 칼럼 단위로 접근, 생성, 변경, 삭제 규칙 정의

*논리성: 테이블 추가와 칼럼 추가는 반드시 논리 데이터 모델을 참조하여 반영

 

3)제약 조건

-NOT NULL, DEFAULT, FOREIGN KEY CONSTRAINT, CHECK 조건 등의 비즈니스 규칙은 칼럼에 정의할 것을 권장하나 테이블 간의 관계 적용 제약 규칙은 애플리케이션과 병행하여 적용

*NOT NULL: 데이터가 반드시 존재

*DEFAULT: 데이터가 반드시 존재해야하는 컬럼의 기본값

*FOREIGN KEY: 물리 데이터 모델에서 정의한 관계의 입력, 삭제, 생성 규칙을 정의

*CHECK: 특정 칼럼에는 미리 정의한 데이터 종류 혹은 범위 내의 데이터만 존재하도록 정의

 

4)인덱스

-논리 데이터 모델에는 반영되어 있지 않으나 데이터의 접근 속도를 빠르게 하기 위한 데이터 저장소

5)트리거

-테이블과 연계되어서 미리 규정된 함수를 수행

6)DB link

-원격지에 있는 데이터베이스를 연결하여 한 곳의 서버에서 다른 서버에 있는 데이터를 하나의 SQL문 내에서 다룰 수 있음

7)프로시저

-프로그램 SQL 문으로 작성

8)뷰

-사용자가 정의한 SQL문의 수행 결과를 보여주는 가상 데이터 영역. 

-중요한 데이터에 대한 접근 제한과 DB 복잡 완화, 

-복잡한 데이터베이스 디자인 숨김, 

-이질 데이터에 대한 분산 질의를 포함한 복잡한 질의 단순화, 

-사용자 접근 관리 단순화

 

9)동의어

-테이블에 대한 별명

10)Role

-DB 객체에 대하여 생성, 삭제, 읽기 변경 권한에 대한 그룹을 생성

 

2.6사용자 뷰

가.정의 및 관리 목적

-데이터를 제공하는 정보시스템상의 화면이나 출력물

나.세부 관리 대상

1)화면

-정보시스템이 생성한 최종 산출물의 제공 인터페이스로 최종 사용자 화면과 시스템 관리자용 화면

#기준(편검지성)

*편의성: 모든 작업 절차는 직관적이고 편리해야함

*검색성: 원하는 정보를 신속 정확하게 검색

*지원성: 도움말 적절히 제공

*시스템 성능: 적정한 속도와 성능 유지

2)출력물

-정보시스템을 통해 생성되는 산출물.보고서, 장표, 전표 등과 같은 산출물은 물론 해당 출력물을 생성하는 응용 프로그램까지 포함

 

3.데이터 관리 프로세스 이해

3.1데이터 관리 정책

가.정의 및 관리 목적

-기업의 비전과 목표 달성에 필요한 데이터의 확보 계획과 확보된 데이터의 효과적인 운영 관리 체계 및 계획을 정의하는 작업

 

*DA의 역할

-사업계획을 바탕으로 데이터 확보계획을 정의

-확보된 데이터를 효과적으로 관리*유지하기 위한 체계를 정의

-DB 품질과 관련된 작업을 원활하게 수행하기 위한 교육체계를 수립

나.세부 관리 대상

-데이터 관리 원칙, 데이터 관리 조직, 데이터 관리 프로세스에 대한 체계 및 계획 을 수립

1)데이터 관리 원칙

-고품질 데이터 서비스를 지원하기 위한 관리기준, 조직, 프로세스에 대한 계획, 규정, 지침

-데이터의 효과적인 확보, 유지관리를 위해 수립된 규정이나 계획, 지침등에 포함된 데이터 관리방향

 

#기준(준불이완일)

*준수성: 기업의 비전과 목표에 맞는 데이터를 확보하고 데이터 관리 목적을 달성할 수 있도록 정의

*불가변성: 아키텍처 원칙 변화에 의한 불가피한 경우를 제외하고는 쉽게 바뀌지 않도록 정의

*이해성:  쉽게 이해할 수 있어야 하며, 의미가 불분명하여 발생하는 혼란을 최소화

*완전성: 정책 수립에 필요한 모든 사항을 정의

*일관성: 원칙간의 충돌이 없도록 정의하고, 충돌이 발생한 경우에는 분명한 의사결정을 할 수 있도록 명시

 

2)데이터 관리 프로세스

-고품질의 데이터를 지속적이고 안정적으로 서비스하기 위해 각 기관의 특성에 맞게 정의한 프로세스간의 연관 관계를 정의한 프로세스

#기준(준완상)

*준수성: 데이터 관리 원칙에 맞게 정의

*완전성: 각 기관의 기존 프로세스에 대한 특성을 고려하여 정의하고 정의된 메인 프로세스는 데이터와 관련된 모든 요소를 빠짐없이 정의

*상호운용성: 기존의 다른 프로세스(변화 관리, 프로젝트 관리 등)와 상호 연관관계가 명확하게 정의

 

3)데이터 관리 조직

-각 기관에서 정의한 데이터 관리 프로세스를 지원하고 담당할 담당자와 조직을 정의

#기준(명운)

*명확성: 담당자와 역할이 명확하게 정의 

*운영성: 조직 구성원은 해당 역할 및 업무를 수행하는데 필요한 능력을 갖추어야 함

다.데이터 관리 프로세스

1)데이터 관리 프로세스(요구,변경,정책,표준,모델,흐름,DB,활용)

 

2)데이터 관리 정책 수립 프로세스(수검표)

3.2데이터 표준 관리

가.정의 및 관리 목적

-데이터 표준화 원칙에 따라 정의된 표준 단어 사전 및 도메인 사전, 표준 용어 사전, 표준 코드, 데이터 관련 요소 표준 등을 기관에 적합한 형태로 정의하고 관리하는 작업

-표준의 적용은 신규 개발시점에서 이루어지고 기존 시스템과 중복 표준 허용 가능.

 

나.세부 관리 대상

-표준 데이터(데이터이해, 데이터구조이해에서 다룸)

 

#표준관리 조직 역할

 

다.데이터 표준 관리 프로세스

1)데이터 표준 관리 프로세스(요구,원칙,단어,데이터표준 정의,검토,공표, 변경요구,영향도,변경,공표)

 

2)데이터 표준 개선 프로세스(매핑,준수,영향도,원인,정제)

 

표준 단어/용어/도메인 변경 프로세스

 

표준 코드 변경 프로세스

 

데이터 표준 점검 프로세스

3.3요구 사항 관리

가.정의 및 관리 목적

- 데이터를 비롯하여 관련 애플리케이션 및 시스템 전반에 걸친 사용자의 요구를 수집하고 분류하여 반영하는 작업

나.세부 관리 대상

-외부인터페이스/기능/성능/보안 개선 요건

1)외부 인터페이스 요건(중표)

-외부 기관이나 외부 시스템과의 사이에서 발생되는 모든 입/출력에 대한 요건

#기준

*중복성: 동일한 형태의 인터페이스가 중복정의되지 않도록 정의

*표준준수도: 국제 표준 및 국가 표준이 존재할 경우 그에 적합한 형태로 제공

2)기능 개선 요건(불범)

-애플리케이션에서 입력 발생되는 출력에 대한 요건

#기준

*불가변성: 기능 개선 요건이 향후에 재변경되지 않도록 근본적인 개선 방안을 요청

*범용성: 많은 사용자가 편리하게 사용할 수 있는 요건을 우선적으로 요청

3)성능 개선 요건(실측)

-해당 기관의 사용자가 필요로 하는 성능 개선 사항

#기준

*실현가능성: 해당 성능 개선 요구 사항이 현행 기술 수준과 서비스 특성을 고려할 때 구현 가능한 요건인지를 확인한 후 제시

*측정가능성: 측정이 불가능한 모호한 형태로 요건이 제시되면 안됨

4)보안 개선 요건(불실)

-중요 데이터에 대한 훼손, 변조, 도난, 유출에 대한 물리적 접근 통제(제한 구역, 통제 구역 등) 및 사용 통제(인증, 암호화, 방화벽 등)에 대한 요건

#기준

*불가변성: 보안 개선 요건이 향후에 재변경되지 않도록 근본적인 개선 방안을 요청

*실현가능성: 해당 보안 개선 요구 사항이 현행 기술 수준과 서비스 특성을 고려할 때 구현 가능한 요건인지를 확인한 후 제시

 

다.요구사항 관리 프로세스(요청,수렴,검토,영향도,공식화,계획)

-‘데이터 요건 분석’과목에서 다루는 내용과는 차이가 있음.

- ‘데이터 요건 분석’과목에서의 요건 분석은 사전 요구 사항 분석을 의미하며, 

여기서는 사후 요구 사항 변경 관리를 의미

 

3.4데이터 모델 관리

가.정의 및 관리 목적

-데이터 요구 사항 관리에 의해 변경되는 데이터 구조를 모델에 반영하는 작업 절차와 데이터베이스 시스템 구조와 동일하게 데이터 모델을 유지하도록 하는 작업 절차

나.세부 관리 대상

-DRM, 개념/논리/물리 데이터 모델(2장 데이터 구조이해에서 다룸)

 

데이터 모델관리 조직 역할

#역할

다.데이터 모델 관리 프로세스

1)데이터 모델 관리 프로세스(DRM,개념,논리,물리,개변,논변,물변)

 

2)데이터 모델 개선 프로세스(개논매핑,논물매핑,물D매핑,개논얼,논물얼,물D얼)

 

주제영역 관리 프로세스

데이터 주제 영역을 추가하거나 기존 주제 영역을 삭제 또는 수정하는 업

 

 

개념 데이터 모델 관리 프로세스

-데이터 주제 영역 추가／삭제 및 핵심 엔터티의 변경 시 개념 데이터 모델의 변경 관리가 필요하며, 개념

데이터 모델 관리 프로세스는 개념 데이터 모델에 대한 변화 관리를 위한 프로세스

 

논리/물리 데이터 모델 관리 프로세스

-논리/물리 데이터 모델 관리 프로세스는 요구 사항을 분석하여 논리와 물리 데이터 모델의 생성·변경·삭제가 발생하게 되는 경우 데이터 모델의 변화 관리를 수행하는 프로세스

 

 

데이터 모델 점검 프로세스

 

 

3.5데이터 흐름 관리

가.정의 및 관리 목적

-소스 데이터(문서, Text, DB 등)를 수기로 생성하거나 추출, 변환, 적재를 통해 생성하여 타겟 데이터베이스에 저장·가공하는 것을 관리하는 절차

나.세부관리 대상(원본이 잘못됨)

-데이터추출, 변환, 적재

 

#데이터 흐름 관리 방법

～소스 데이터와 타깃 데이터 간의 매핑 리스트를 작성하고, 타깃 시스템에서 필요로 하는 소스 데이터가

모두 포함되어 있는지 확인

~ 데이터 이동이 필요 없는 소스와 타깃의 매핑 여부를 검사

～삭제된 소스를 매핑 소스로 사용하고 있는지를 검사

~ 소스와 타깃의 데이터 구조가 동일한지 조사, 동일하지 않은 경우 변환 규칙을 적용하고 있는지 조사

~ 변환 규칙이 데이터 무결성 규칙을 준수하는지 검사. 그 결과가 데이터 정합을 보장하는지 검사

 

다.데이터 흐름 관리 프로세스

1)데이터 흐름 관리 프로세스 (요건,분석,설계,테스트,검증,모듈반영,모니터링,점검기준,점검지표,정합성,오류,영향도,정제)

 

3.6데이터베이스 관리

가.정의 및 관리 목적

-원활한 데이터 서비스를 위해 필요한 데이터베이스를 안정적으로 운영, 관리하는 데 필요한 작업을 체계화

나.세부 관리 대상(원본 오류)

다.데이터베이스 관리 프로세스

1)데이터베이스 관리 프로세스 (생성,스케줄,백업,보안대상,보안적용,보안교육,성능개선,보안개선,복구,변경,이관)

 

2)데이터베이스 개선 프로세스(효율성,원인,영향도)

 

3.7데이터 활용 관리

가.정의 및 관리 목적

-데이터의 활용 여부를 점검하거나 활용도를 높이기 위해 측정 대상 데이터와 품질 지표를 선정하여 품질을 측정하고 분석하여 품질을 충족시키지 못하는 경우, 원인을 분석하여 담당자로 하여금 조치하도록 하는 작업

나.세부 관리 대상

1)핵심 데이터(최완일유명유)

-회사의 고객, 프로세스, 시장 환경, 재무 정보 등에 직접적으로 영향을 미치는 중요성이 높은 데이터

-해당 테이블의 컬럼수준으로 관리.

#기준

*완전성:데이터의 모든 값은 의미 있게 채워져야 함.

*일관성:데이터의 값은 동일하게 관리

*최신성:데이터의 값은 실제 세계의 객체들이 가지고 있는 값과 같아야 함

*유효성:데이터의 값은 업무 규칙을 준수

*유일성:데이터의 값은 동일 테이블에서 중복 관리되어서는 안됨

*명확성:데이터의 의미가 혼동되지 않도록 분명해야 함.

2)측정 방법

-데이터의 업무적인 규칙 및 물리적 특성(도메인, 유효성 등)을 반영한 데이터 품질 측정 기준

 

#역할

 

다.데이터 활용 관리 프로세스

1)데이터 활용 관리 프로세스(핵심,측정기준,측정,요인분석,개선방안,수행,평가)

 

*사용자 활용 관리

-사용자의 요구에 적합한 형태의 서비스를 제공하고 있는지에 대해 확인함으로써 고객의 서비스 만족을 도모하는 작업으로 서비스 만족에 대한 검토는 신규 시스템 개발 내역과 변경 처리내역뿐만 아니라 서비스 되는 모든 시스템에 대한 분석이 정기적/비정기적인 계획을 통해 이루어져야 한다.

====2021 교재 추가 내용

데이터 품질 관리 프레임워크

-데이터 표준, 데이터 모델, 데이터 값, 데이터 활용 등의 4가지 영역으로 구분

-데이터 표준은 표준 단어, 표준 용어,표준 도메인, 표준코드 등으로 구성 

-데이터 모델은 모델링 도구를 활용하여 개념모델, 논리모델, 물리모델, DB Catalog로 구성

-데이터 값은 데이터 품질 지표(DQI), 핵심 정보(CTQ), 기술적 분석의 데이터 프로파일링, 비즈니스적 분석의 업무규칙으로 구성

-데이터 활용은 원천데이터와 타겟데이터의 데이터 매핑 정보, 데이터의 연관 관계, Map 형태의 데이터 흐름으로 구성

 

3.8 데이터 값(Value) 품질관리 프로세스

1. 정의 및 관리 목적

데이터 값에 대한 신뢰성, 정확성 확보를 위해 데이터 값 관점의 품질 진단 및 개선을 위한 절차로 오류데이터의 유입을 방지하기 위한 작업 절차

 

2. 세부 관리 대상

세부 관리 대상으로 값 관점 데이터 품질이 있음.

 

#품질 기준

· 품질 관리 대상 : 품질 측정 대상 시스템 및 테이블 관리

· 데이터 품질 지표 : 완전성, 유효성, 일관성, 정확성

· 핵심 정보 항목 : 가장 중요한 데이터 정보 항목(예시 : 고객연락처정보, 매출정보 등)

 

#프로파일링

-데이터 현황 분석을 위한 자료 수집, 데이터 통계, 패턴 등을 수집하여 잠재적 오류 징후를 발견하는 방법

-기법: 칼럼 프로파일링, 싱글 테이블 프로파일링, 크로스 테이블 프로파일링

#프로파일링 분석기법

 

#업무 규칙

-데이터 사용자가 요구하는 수준을만족시키기 위하여 업무적으로 규정된 기준에 맞도록 데이터 값을 관리

하기 위한 조건에 대한 일반적인 표현

· Inside-Out 도출 방법 : 데이터의 통계적인 분석(Data Profiling, Master Data 분석 등)을 통하여 오류데이터 잠재원인을 파악하고 업무규칙을 도출하는 방법. 업무적인 지식이 없는 경우에도 오류 징후를

발견하고 Low-Level의 필수성, 유효성 등의 업무규칙을 자동으로 생성 가능

· Outside-In 도출 방법 : 비즈니스 이슈, 외부고객의 소리-VOC(Voice Of Customer), 내부고객의 소리-VOB(Voice Of Business), 설문조사, 인터뷰 등의 분석을 통하여 오류 잠재원인을 파악하고 업무규칙을 도출하는 방법

· 근거규정 도출 방법 : 기관의 법령을 기초로 설계된 데이터 모델을 기준으로 표준 데이터 항목에 대하여

관련 규칙(업무정의, 근거규정 등)을 통합하여 서술적 업무규칙을 작성하고 매핑되는 실제 운영 시스템

칼럼의 데이터 품질 검증을 위한 업무규칙을 생성 가능

 

#품질 측정

진단 대상으로 선정된 데이터에 대하여 설정되어 있는 프로파일링, 업위규칙 등을 지속적, 정기적으로

수행하기 위해 데이터베이스 성능과 측정가능 시간 등을 고려하여 측정 주기(일일/주간/월간/분기/반기/연간 점검)를 설정. 품질 점검 주기는 사용자의 요구 수준을 반영하여 결정

#품질 개선

오류추정 데이터에 대해 개선 담당자, 오류 원인, 개선내용 등을 지속적으로 관리할 수 있도록 절차와

방법을 정의

 

값 관점 품질 측정 방법

측정기준 : 프로파일링, 업무규칙을 통해 값에 대한 품질을 측정

측정산식:

오류율(%) = 오류 데이터 건수 / 진단대상DB 전체 데이터 건수 x 100

 

=====

#데이터 값 관리 조직 역할

 

4. 데이터 값 품질 관리 프로세스

가. 데이터 값 품질 관리 체계도

나. 데이터 값 품질 진단 프로세스

-오류데이터 유입을 방지하기 위해 데이터의 신뢰성, 정확성 확보를 위해 지속적으로 수행하기 위한 프로세스로서 크게 데이터 값 품질 진단 계획 수립 프로세스와 데이터 값 품질 진단 실시 프로세스

 

1) 데이터 값 품질 진단 계획 수립 프로세스

 

2) 데이터 값 품질 진단 실시 프로세스

 

나. 업무규칙 관리 프로세스

-기업에서 데이터 품질 검증을 위해 관리하는 규칙. 이것은 데이터 값이 정확성을 높이기 위해 수행하는 프로세스로 크게 업뮈子칙 도출 프로세스와 업위子칙 변경 프로세스

1) 업무규칙 도출 프로세스

 

2) 업무 규칙 변경 프로세스

 

다. 데이터 값 품질 개선 프로세스

1) 데이터 값 품질 개선 프로세스

 

맨 위로 이동

 

DAP 1장 전사아키텍처 이해

 

DAP 2장 데이터 요건 분석

 

DAP 3장 데이터 표준화

 

DAP 4장 데이터 모델링

 

DAP 5장 데이터베이스 설계와 이용

 

제1장 데이터베이스 설계

제1절 저장공간 설계

제2절 무결성 설계

제3절 인덱스 설계

제4절 분산 설계

제5절 보안 설계

 

제2장 데이터베이스 이용

제1절DBMS

제2절 데이터 액세스

제3절 트랜잭션

제4절 백업 및 복구

 

제3장 데이터베이스 성능 개선

제1절 성능 개선 방법론

제2절 조인(Join)

제3절 애플리케이션 성능 개선

제4절 서버 성능 개선

 

 

1.데이터베이스 설계

1.1저장공간 설계

컬럼>테이블>tablespace> 데이터 파일

 

가.테이블

-행(Row)과 열(Column)으로 구성되는 가장 기본적인 데이터베이스 객체

1)테이블

-데이터의 저장 형태, 파티션 여부, 데이터의 유지 기간 등에 따라 다양하게 분류

-Heap, Clustered, Partitioned(Range, List, Hash, Composite), external, temporary

*Heap-organized table: 표준 테이블 형태. 로우의 저장 위치는 로우가 삽입될때 결정

-입력 시 정렬을 하지 않으므로 입력에 대한 부하가 적음

-인덱스와 데이터 저장 공간이 분리

-대량의 트랜잭션이 발생하는 로그성 테이블

-Oracle, PostgreSQL

*Clustered index table: 

-Primary Key 값이나 인덱스 키 값의 순서로 데이터가 저장되는 테이블 

-B-tree 구조의 Leaf Node에 데이터 페이지가 존재함

-입력시 정렬에 대한 부하 발생

-인덱스 저장 공간에 데이터 함께 저장

-prefetch가 가능

-PK를 조건으로 사용되는 경우 더 빠르게 데이터에 접근 가능

-크기가 작고 자주 액세스 되는 코드성 테이블

-칼럼 수가 작고 행의 수가 많은 테이블 (주로 통계성 테이블)

-소량의 랜덤엑세스에 유리
-넓은 범위를 조회해야 하는 테이블에 적합

-MySQL, MariaDB, SQL Server

*Partitioned table: 

-파티셔닝: 대용량의 테이블을 파티션이라는 논리적인 단위로 나눔으로써 성능이 저하  방지, 관리 용이

-대용량I/O 성능, 가용성, 확장성

-유형: 범위 분할(Range), 해시 분할(Hash), 결합 분할(Composite) 등

#범위(Range) 파티션 테이블
-주로 날짜 컬럼을 기준으로 데이터를 월, 일, 년 등의 기준으로 파티셔닝할때 사용
-범위를 너무 세분화하여 파티션의 개수가 지나치게 많아지는 것을 지양

#목록(List) 파티션 테이블
-미리 정해진 코드성 칼럼의 값을 키로 파티셔닝(지역을 기준으로 파티셔닝)
-데이터 분포도를 파악하여 데이터를 각 파티션에 고루 분산

#해시(Hash) 파티션 테이블
-관리상의 이점보다는 성능상의 이점
-대용량 데이터 처리 시 데이터 블록(페이지)의 경합 감소

#복합(Composite) 파티션 테이블
-파티션의 순서가 중요 (뒤에 분할된 파티션을 서브파티션이라고 함)

 

*external table: 외부 파일을 마치 DB안에 존재하는 일반 테이블 형태로 이용할 수 있는 DB 객체

-DW의 ETL 작업에 유용

*temporary table: 트랜잭션이나 세션별로 데이터를 저장하고 처리할 수 있는 임시 테이블

 

2)컬럼

-테이블을 구성하는 요소로, 데이터 타입과 길이로 정의 

#컬럼 데이터 타입에 따라 물리적인 칼럼 순서 조정

-고정 길이 칼럼이고 NOT NULL인 칼럼은 선두에 정의

-가변 길이 칼럼을 뒤편으로 배치

-NULL 값이 많을 것으로 예상되는 칼럼을 뒤편으로 배치

#데이터 타입과 길이 지정 시 고려사항

-가변 길이 데이터 타입은 예상되는 최대 길이로 정의

-고정 길이 데이터 타입은 최소 길이로 지정

-소수점 이하 자리 수의 정의는 반올림되어 저장되므로 정확성을 확인하고 정의

 

#컬럼값비교

-양쪽 모두 CHAR 타입: 두 칼럼 중 길이가 짧은 쪽 칼럼에 공백을 추가하여 길이를 맞춘 후 비교

-문자열비교에서 어느 한쪽이 VARCHAR 타입이면 각각의 문자를 비교하여 서로 다른 값이 나타나면 문자 값이 큰 칼럼이 크다고 판단

-NUMBER.와 CHAR타입을 비교할때 CHAR을 NUMBER타입으로 변환하여 비교, 변환이 불가한 경우 NUMBER를 CHAR로 변환후 비교

-각 문자타입이 상수값과 비교될때는 결정되어 있는 칼럼의 데이터 타입과 같도록 변환된 후 비교

 

3)테이블 설계시 고려사항

-칼럼 데이터 길이 합이 1 블록 사이즈보다 큰 경우 수직 분할

-칼럼 길이가 길고 특정 칼럼의 사용 빈도 차이가 심한 경우 수직분할

-테이블과 인덱스는 분리하여 저장하면 I/O병목을 최소화 

-임시세그먼트는 독립적인 공간을 사용이 좋음: DB내부에서 객체 생성

 

나.테이블과 테이블 스페이스

-테이블은 테이블스페이스라는 논리적인 단위를 이용하여 관리
-테이블스페이스는 물리적인 데이터 파일을 지정하여 저장

#데이터용/인덱스용 테이블스페이스 설계 유형

-테이블이 저장되는 테이블 스페이스는 업무별로 지정

대용량 테이블은 독립적인 테이블 스페이스 지정

테이블과 인덱스는 분리 저장

LOB 타입 데이터는 독립적인 공간 지정

 

다.용량설계

#목적

-정확한 데이터 용량을 예측하여 저장공간을 효과적인 사용과 저장 공간에 대한 확장성을 보장하여 가용성을 높이기 위함

-H/W 특성을 고려하여 디스크 채널 병목을 최소화

-디스크 I/O를 분산하여 접근 성능을 향상

-테이블이나 인덱스에 맞는 저장 옵션 지정

#테이블 저장 옵션에 대한 고려사항

-초기 사이즈, 증가 사이즈

-트랜잭션 관련 옵션

-최대 사이즈와 자동 증가

#저장 용량 설계 절차

-용량 분석: 데이터 증가 예상 건수, 주기, 로우 길이 등을 고려함

-오브젝트별 용량 산정: 테이블, 인덱스에 대한 크기

-테이블스페이스별 용량 산정: 테이블스페이스별 오브젝트 용량의 합계

-디스크 용량 산정: 테이블스페이스에 따른 디스크 용량과 I/O 분산 설계

 

1.2무결성 설계

가.데이터 무결성

-데이터의 정확성, 일관성, 유효성, 신뢰성을 위해 무효 갱신으로부터 데이터를 보호

-종류에 따라 장단점이 존재하므로 선택적인 적용 필요

1)데이터 무결성 종류

-실체/영역/참조/사용자 정의 무결성

2)데이터 무결성 강화 방법

#애플리케이션: 데이터를 조작하는 프로그램 내에 데이터 생성, 수정, 삭제 시 무결성 조건을 검증하는 코드를 추가

#DB 트리거: 트리거 이벤트 시 저장 SQL을 실행하여 무결성 조건을 실행함

-트랜잭션이 실패할 확률이 높아짐

#제약조건: 데이터베이스 제약 조건 기능을 선언하여 무결성을 유지함

-기본적인 DB요건은 쉽게 무결성 유지 가능

 

 

나.엔터티 무결성

-실체에서 개체의 유일성을 보장하기 위한 특성

-기본키 제약을 정의하면 해당 테이블은 Clustered Index Table로 변경되어 데이터가 키값순으로 재배열됨

-1대다 관계에서 1쪽의 유일성을 보장

#PK 제약:NOT NULL, UNIQUE

#Unique 제약: 경우에 따라 NULL 가능

#식별자 설계-채번: DBMS에서 제공하는 일련번호를 발생시키는 시퀀스같은 객체나 시리얼같은 데이터 타입을 이용 

 

다.영역 무결성(도메인)

-칼럼에 적용되어 단일 로우의 칼럼 값만으로 만족 여부를 판단

#데이터 타입 & 길이

#유효값(CHECK)

#NOT NULL

 

라.참조 무결성

-두 실체 사이의 관계 규칙을 정의하기 위한 제약 조건으로 데이터가 입력, 수정, 삭제될 때 두 실체의 튜플들 사이의 정합성과 일관성을 유지

 

#입력 참조 무결성: 애플리케이션에서 구현(자식테이블 입력)

DEPENDENT: 참조되는(부모) 테이블에 PK 값이 존재할 때만 입력을 허용

AUTOMATIC: 참조되는(부모) 테이블에 PK 값이 없는 경우는 PK를 생성 후 입력

DEFAULT: 참조되는(부모) 테이블에 PK 값이 없는 경우 자식의 FK를 지정된 기본값으로 입력

CUSTOMIZED: 특정한 조건이 만족할 때만 입력을 허용

NULL: 참조되는(부모) 테이블에 PK 값이 없는 경우 외부키를 NULL 값으로 처리

NO EFFECT: 조건 없이 입력을 허용

 

#수정/삭제 참조 무결성: 부모 식별자가 변경되었을 경우(부모테이블 수정)

RESTRICT: 참조하는(자식) 테이블에 PK 값이 없는 경우 삭제/수정 허용

CASCADE: 참조되는(부모) 테이블과 참조하는 (자식)테이블의 FK를 연쇄적 삭제/수정

DEFAULT: 참조되는(부모) 테이블의 수정을 항상 허용하고 참조하는(자식) 테이블의 FK를 지정된 기본값으로 변경

CUSTOMIZED: 특정한 조건이 만족할 때만 수정/삭제 허용

NULL: 참조되는(부모) 테이블의 수정을 항상 허용하고 참조하는(자식) 테이블의 FK를 NULL 값으로 수정

NO EFFECT: 조건 없이 삭제/수정 허용

#디폴트 규칙 정의의 필요성: NULL 조건은 DEFAULT 조건으로 설계

#모델상에서 슈퍼타입(SUPER-TYPE)-서브타입(SUB-TYPE) 관계

 

*삽입 시에는 DEPENDENT, AUTOMATIC 조건을 적용하고, 삭제나 변경 시에는 CASCADE 조건을 적용

 

1.3인덱스 설계

가.인덱스 기능

-인덱스: DB 테이블의 ROW 키값과 데이터의 물리적주소를 매핑한 테이블을 저장하는 영역

 

나.인덱스 설계 절차

-최소의 인덱스 구성으로 모든 접근 경로를 제공할 수 있어야 전략적인 인덱스 설계

-접근경로수집>후보결정>접근경로설정>칼럼조합 및 순서결정>적용시험

 

1)접근경로 수집

-테이블에서 데이터를 검색하는 방법. 테이블스캔. 인덱스스캔

-조인,분포도,조회,결합,정렬,그룹핑,일련번호,통계

#반복 수행되는 접근 경로: 대표적인 것이 조인 칼럼

#분포도가 양호한 칼럼: 주민번호 등은 단일 칼럼 인덱스로도 충분한 수행 속도를 보장 받을 수 있는 후보

#조회 조건에 사용되는 칼럼

#자주 결합되어 사용되는 칼럼

#데이터 정렬 순서와 그룹핑 칼럼

#일련번호를 부여한 칼럼: 이력관리용

#통계 자료 추출 조건

#조회 조건이나 조인 조건 연산자

 

2)분포도 조사에 의한 후보 칼럼 선정

-수집된 접근 경로 칼럼들을 대상으로 분포도를 조사. 설계단계에서는 현재 데이터를 참고하거나 예상한 상황을 고려하여 예측

-분포도=데이터별 평균 로우 수 / 테이블의 총 로우 수 x 100

*분포도가 10 ~ 15% 정도이면 인덱스 칼럼 후보. 인덱스를 통한 액세스는 싱글 블록으로I/O을 하고, 테이블 스캔은 멀티 블록으로 I/O

*분포도는 단일 칼럼을 대상으로 조사

*단일 칼럼으로 만족하지 않는 경우 결합 칼럼들에 대한 분포도 조사

*분포도 조사 결과를 만족하는 칼럼은 인덱스 후보로 선정

*기형적으로 분포도가 불규칙한 경우는 별도 표시하여 접근 형태에 따라 대책을 마련

*빈번히 변경이 발생하는 칼럼은 인덱스 후보에서 제외

 

3)접근경로 결정

-인덱스 후보 목록을 이용하여 접근 유형에 따라 어떤 인덱스 후보를 사용할 것인지 결정

 

4)칼럼 조합 및 순서 결정(항등분정)

-단일 칼럼의 분포도가 양호하면 단일 칼럼 인덱스로 확정

#항상 사용되는 컬럼을 선두 칼럼

#등치( = )조건으로 사용되는 컬럼을 선행 칼럼

#분포도가 좋은 컬럼을 선행 칼럼

#ORDER BY, GROUP BY 순서를 적용

 

*드라이빙 조건: 인덱스 탐색범위를 대폭 축소하는 조건, 보통 범위검색은 인덱스 탐색 효율을 떨어뜨림.

*매칭도: 드라이빙 조건으로 사용된 컬럼수

*선택도: 전체레코드중 조건절에 의해 선택되는 비율

 

#항상 등치조건으로만 사용하면 인덱스 수 증가

#NOT IN, <>, NOT LIKE, NOT IN등 부정 연산은 인덱스 사용 불가

or 연산 이후는 인덱스 매칭도 계산 안함

 

-between, like, <, > 조건은 해당 컬럼은 인덱스를 사용하지만, 이후 인덱스 컬럼은 인덱스를 사용하지 않음.

-in, = 컬럼은 이후 컬럼도 인덱스를 사용.

-in의 인자로 서브쿼리가 들어가면 서브쿼리가 먼저 실행되어 in은 체크조건이 됨.

-값을 가공하면 인덱스 사용불가.

-인덱스 구성컬럼 중 하나라도 NOT NULL이면, IS NULL 조회에 인덱스 사용 가능.

 

5)적용시험

-설계된 인덱스를 적용하고 접근 경로별로 인덱스가 사용되는지 시험

 

다.인덱스 구조

-트리,해시,비트맵,함수,조인,도메인, 클러스터, 파티션 인덱스

 

1)트리기반 인덱스

-상용 DBMS에서는  B+ 트리 인덱스를 주로 사용. 

-루트에서 리프 노드까지 모든 경로의 깊이가 같음

-데이터 삽입과 삭제 성능 우수
-모든 키값은 리프노트에 존재하며, 양방향 연결됨

-범위검색시 성능 우수

-B+트리 각 노드는 최소한 반이상 차 있어야 함

-B*트리 각 노드는 최소한 2/3 이상 차 있어야 함

-처리 범위가 넓으면 수행속도 저하

-인덱스를 생성한 컬럼을 가공하면 인덱스 사용 불가

-인덱스를 생성한 컬럼순으로 정렬됨

-분포도가 나빠지면 수행속도 저하

 

2)해쉬 기반 인덱스

-키 값에 대응하는 버킷을 식별하고 탐색

 

3)비트맵(BITMAP) 인덱스

-B+트리는 키 값에 Rowid 리스트를 저장

-비트맵에서 비트의 위치는 테이블에서 로우의 상대적인 위치를 의미하므로 해당 테이블이 시작되는 물리적인 주소만 알면 실제 로우의 물리적인 위치를 계산

-데이터 분포도가 나쁜 칼럼에 적합 예)성별

-저장공간과 I/O를 감소

 

3)함수기반 인덱스

-함수나 수식(expression)으로 계산된 결과에 대해 B+ 트리 인덱스나 Bitmap Index를 생성, 사용할 수 있는 기능 제공

4)비트맵 조인 인덱스

-단일 객체로만 구성되었던 기존 인덱스와 달리 여러 객체의 구성 요소(칼럼)로 인덱스 생성
-물리적인 구조는 비트맵 인덱스와 완전히 동일. -인덱스의 구성 컬럼이 베이스 테이블의 컬럼 값이 아니라 조인된 테이블의 컬럼 값

5)도메인 인덱스

-개발자가 자신이 원하는 인덱스 타입을 생성

6)Cluster Index

-인덱스부와 데이터부로 나누어져 있으며, 인덱스부는 일반적인 B*tree 인덱스로 구성

-데이터 삽입시 키순서에 따라 지정된 위치에 저장되어야 하므로 데이터 페이지의 유지비용이 매우 높음(데이터 페이지의 Spit 발생 가능성 높음)

-Cluster Index가 존재할 경우 Non Cluster Index는 RID대신 Cluster Index의 키값을 가짐

-운영중에 Cluster Index를 생성하면 구조적으로 데이터 페이지의 개편이 일어나므로 많은 오버헤드 발생

7)파티션 인덱스

-각 인덱스 파티션이 담당하는 테이블의 파티션 범위에 따라 글로벌 파티션 인덱스와 로컬 파티션 인덱스로 구분

#비 파티션 인덱스

-파티션 테이블에 생성된 비 파티션 인덱스는 글로벌 인덱스라 부르며 파티셔닝되지 않은 인덱스가 파티셔닝된 전체 테이블과 대응되는 구조

#로컬 파티션 인덱스(많이 사용)

-테이블이 파티셔닝된 기준 그대로 파티셔닝된 파티션 인덱스. 

-인덱스 파티션과 테이블 파티션이 1:1로 대응되는 구조

-테이블 파티션키가 조건절에 없으면 비효율

-테이블 파티션에 작업시, 인덱스 파티션 자동관리

#글로벌 파티션 인덱스

-테이블의 파티션과 독립적으로 인덱스 파티션을 구성하는 것

-파티셔닝되지 않은 테이블에도 적용

-인덱스 파티션키가 인덱스 선두 컬럼이어야 함.

#인덱스 재생성 작업을 고려중에 우선순위가 높은 작업 대상은 빈번한 수정이 발생하는 컬럼을 포함한 인덱스임

 

#인덱스를 사용할 수 없는 경우

-컬럼 가공

-NULL 비교

-부정 비교

-like는 인덱스 사용가능

 

#테이블/인덱스 파티셔닝 이유

-가용성, 조회성능, 경합 분산

-단, 저장 효율은 나빠질 수 있음.

1.4분산 설계

가.분산 DB개요

-하나의 논리적 DB가 네트워크상에서 여러 컴퓨터에 물리적으로 분산되어 있지만 사용자가 하나의 DB처럼 인식할 수 있도록 논리적으로 통합된 DB

-원격 데이터에 대한 의존도 감소

-단일 서버에서 불가능한 대용량 처리가 가능

-기존 시스템에 서버를 추가하여 점진적 증가가 용이

-장애전파가 안되어 신뢰도와 가용성이 향상

 

나.분산 DBMS 투명성

#분할 투명성:  전역 스키마가 어떻게 분할되어있는지를 알 필요가 없음

#위치 투명성: 데이터의 물리적인 위치도 알 필요가 없음

#중복 투명성: 어떤 데이터가 중복되었는지, 어디에 중복 데이터를 보관하고 있는지 알 필요가 없음

#장애 투명성: DB가 분산되어 있는 시스템이나 네트워크에 장애가 발생하더라도 데이터의 무결성 보장

#병행 투명성: 다수 트랜잭션이 동시에 수행되어도 결과의 일관성 유지 (Locking, Timestamp)

 

다.분산 설계 전략

-중앙 집중형 DB처럼 한 컴퓨터에서만 DB를 관리하고 여러 지역에서 접근할 수 있도록 하는 방식

-지역 DB에 데이터를 복제하고 실시간으로 복제본을 갱신하는 방식

-지역 DB에 데이터를 복제하고 주기적으로 복제본을 갱신하는 방식

-데이터 분할 시 전체 지역 DB를 하나의 논리적 DB로 유지하는 방식

-데이터 분할 시 각각의 지역 DB들을 독립된 DB로 유지하는 방식

 

라.분산 설계 방식

1)테이블 위치 분산

-테이블이 전역적으로 중복되지 않음. 테이블마다 위치를 다르게 지정 > 테이블마다 존재할 서버를 결정

2)분할(Fragmentation)

#완전성: 분할 시에 전역 릴레이션 내의 모든 데이터가 어떠한 손실도 없이 분할로 매핑

#재구성: 관계 연산을 사용하여 원래의 전역 릴레이션으로 재구성이 가능

#상호 중첩 배제: 분할 시 하나의 분할에 속한 데이터 항목이 다른 분할의 데이터 항목에 속하지 않아야 함

#수평분할: 특정 속성의 값을 기준으로 분할(동일한 속성)

#수직분할: 속성을 기준으로 분할

 

3)할당(Allocation)

-동일한 분할을 복수 서버에 생성하는 분산 방법, 

-분할의 중복이 존재하는 할당 방법과 중복이 존재하지 않는 할당 방법으로 구분

#부분 복제: 전역 서버 테이블의 일부 데이터를 지역 서버에 복제

#광역 복제: 전역 서버 테이블의 전체를 지역 서버에 복제

 

마.데이터 통합

-통합 방식은 DW를 이용하는 방법과 EAI를 이용하는 방법. 혼합 방법

1.5보안 설계

-DB 보안: DB정보가 비인가자에 의해 노출, 변조, 파괴되는 것을 막는 활동

-신분,역할,위치,시간,서비스 제한 등의 요건을 이용하여 설계

-뷰를 사용하여 데이터 접근을 이중화

-터미널 혹은 네트워크 주소등 확인이 가능한 접근 위치나 경로만 접근 허용

-일과 시간, 마감시간 등 특정시간에 대하여 접근 허용

 

가.접근통제 기능

-접근통제는 보안시스템의 중요한 기능적 요구 사항. 

-임의의 사용자가 어떤 데이터에 접근하고자 할 때 접근을 요구하는 사용자를 식별하고, 사용자의 요구가 정상적인 것인지를 확인, 기록하고 보안 정책에 근거하여 접근을 승인하거나 거부함으로써 비인가자의 불법적인 자원 접근 및 파괴를 예방하는 보안 관리의 모든 행위

#DAC

-임의적 접근 통제는 사용자의 신원에 근거를 두고 권한을 부여하고 취소하는 메커니즘을 기반. Grant, Revoke

#MAC

-강제적 접근 통제는 주체와 객체를 보안 등급 중 하나로 분류하고, 주체가 자신보다 보안 등급이 높은 객체를 읽거나 쓰는 것을 방지

 

나.보안모델

1)접근 통제 행렬(Access Control Matrix)

-임의적 접근 통제를 위한 보안 모델

-행은 주체, 열은 객체, 행&열은 주체와 객체가 가지는 권한의 유형

-주체: DB에 접근할 수 있는 조직의 개체. 일반적으로 객체에 대하여 접근을 시도하는 사용자

-객체: 보호되고 접근이 통제되어야 하는 DB의 개체. 테이블, 칼럼, 뷰, 프로그램, 논리적인 정보의 단위

-규칙: 주체가 객체에 대하여 수행하는 DB의 조작. 입력, 수정, 삭제, 읽기와 객체의 생성과 파괴 등

 

2)기밀성 모델: Bell-Lapadula 

-군사용 보안 구조의 요구 사항을 충족시키기 위하여 정보의 불법적인 파괴나 변조 보다는 기밀성 유지에 초점을 둔 최초의 수학적인 모델

-단순 보안 규칙: No-Read-Up. 주체는 자신보다 높은 등급의 객체를 읽을 수 없음

-*(스타)-무결성 규칙: No-Write-Down. 주체는 자신보다 낮은 등급의 객체에 정보를 쓸 수 없음

-강한 *(스타) 보안 규칙: 주체는 자신과 등급이 다른 객체에 대하여 읽거나 쓸 수 없음

 

2)무결성 모델: Biba(BLP의  반대)

-정보의 일방향 흐름 통제를 이용하여 정보의 비밀성을 제공하는 기밀성 모델에서 발생하는 정보의 부당한 변경 문제를 해결하기 위해 개발된 무결성 기반의 보안 모델

-단순 보안 규칙: No-Read-Down. 주체는 자신보다 낮은 등급의 객체를 읽을 수 없음

-*(스타)-무결성 규칙: No-Write-Up. 주체는 자신보다 높은 등급의 객체에 정보를 쓸 수 없음

 

다.접근 통제 정책

#신분-기반 정책(DAC)

*개인 또는 그들이 속해 있는 그룹들의 신분에 근거하여 객체에 대한 접근을 제한하는 방법. IBP, GBP

#규칙-기반 정책(MAC)

-강제적 접근 통제와 동일한 개념, 주체가 갖는 권한에 근거하여 객체에 대한 접근을 제한. MLP, CBP

#역할-기반 정책(RBAC)

-GBP의 한 변형된 형태. 정보에 대한 사용자의 접근이 개별적인 신분이 아니라 개인의 직무 또는 직책에 의해 결정

 

라.접근통제 메커니즘

-패스워드: 데이터 및 프로그램 접근권한 확인

-암호화

-접근통제목록(ACL): 객체를 기준으로 접근 통제 정보를 저장. 어떤 사용자들이 객체에 대하여 어떤 행위를 할 수 있는지를 나타냄. 주체의 수가 많아지면 관리 어려움

-CL(Capability List): ACL 문제해결. 주체가 접근할 수 있는 객체와 접근 권한을 주체에 저장하는 방식

-보안등급:  주체나 객체 등에 부여된 보안 속성의 집합

-통합 정보 메커니즘: 두가지 이상의 복합된 특성으로 구현

 

마.접근통제 조건

#값 종속 통제 

-객체에 저장된 값에 따라 접근 통제 허가. 예)계약금액에 따른 기밀 수준 차등

#다중 사용자 통제

-지정된 객체에 대해 다수의 사용자가 연합하여 접근. 예)두명이상 다수결

#컨텍스트 기반 통제

-특정 시간, 네트워크 주소등 확인이 가능한 접근 경로나 위치, 인증 수준 등과 같은 외부적인

요소에 의존하여 객체의 접근을 제어하는 방법

 

바.감사 추적

-애플리케이션 및 사용자가 DB에 접근하여 수행한 모든 활동을 일련의 기록으로 남기는 기능

 

2.데이터베이스 이용

2.1DBMS

가.개념적 DBMS 아키텍처

-DBMS 서버는 인스턴스와 데이터베이스로 구성. 

-인스턴스는 메모리 부문과 프로세스 부문으로 구성. 

-그 외 DB의 기동과 종료를 위하여 DBMS 환경을 정의한 매개변수 파일과 파일 목록(데이터 파일, 로그 파일)을 기록한 제어 파일이 있음

-구성요소: 데이터베이스 파일, 데이터 저장관리자, 질의처리기, 트랜잭션관리자.

나.데이터베이스 서버 시작과 종료

-데이터베이스 관리자가 DBMS 인스턴스를 시작. 인스턴스 시작은 매개변수 파일을 읽음

#초기화 매개변수

-파일과 같은 항목에 이름을 지정

-최대 값과 같은 한계를 설정

-메모리 크기와 같은 용량에 영향을 주는 매개변수(가변 매개변수)

-인스턴스를 시작할 데이터베이스 이름

-로그 파일의 처리 방법

-DB 제어 파일의 이름과 위치

 

1)DB 서버 시작

#인스턴스 시작: 매개변수 파일을 읽어 초기화 매개변수 값을 결정하고 프로세스를 구동

#DB 마운트: 데이터베이스의 제어파일을 오픈

#DB 오픈: 데이터파일, 로그파일을 오픈 

#DB 닫기: 메모리에 있는 모든 DB 데이터와 로그를 데이터 파일과 리두 로그 파일에 각각 기록하고 온라인 데이터 파일과 온라인 로그 파일을 닫음

#DB마운트 해제: DB 마운트를 해제하여 DB와 인스턴스 간의 관계를 끊고 DB의 제어 파일을 닫음

#인스턴스 종료: 할당된 공유 영역이 메모리에서 제거되고 백그라운드 프로세스가 종료

가.DBMS 추상화

-메타데이터 관리: 데이터의 값뿐만 아니라 그 데이터의 정의나 설명, 파일의 구조, 데이터 항목의 유형과 저장 형식, 제약조건과 같은 메타 데이터를 시스템 카탈로그 또는 데이터 사전에 저장, 관리

-데이터 독립성: 데이터의 파일 구조가 프로그램으로부터 분리되어 시스템 카탈로그 또는 데이터 사전으로 관리

-데이터 추상화: 사용자에게 데이터에 대한 개넘적인 접근만을 제공. 물리구조 알필요 없음

-트랜잭션과 동시성제어: 여러 사용자가 동시에 동일한 데이터베이스에 접근

 

나.DBMS 사상

-외부, 개념, 내부 스키마

-개념적 단계: 추상화의 최상위 단계로 최종 사용자들이 관심을 갖는 데이터베이스의 부분만을 정의

-논리적 단계: 데이터베이스의 전체 구조를 추상화하는 단계로 데이터베이스에 저장된 데이터와 데이터 간의 관계, 권한(보안), 무결성과 같은 부가적인 정보를 정의

-물리적 단계: 가장 낮은 추상화 단계로 데이터가 실제 어떻게 저장되어 있는지 원시 수준의 데이터 구조를 정의. 저장된 데이터의 유형, 인덱스의 종류, 칼럼의 표현/순서, 각 레코드의 물리적 순서 등

 

-개념적－논리적 사상: 논리적 단계의 데이터 독립성

-논리적－물리적 사상: 물리적 단계의 데이터 독립성

 

다.DBMS 구성요소

-DB 파일: 데이터 사전을 저장하는 파일과 사용자의 데이터를 저장하는 파일

-데이터 저장 관리자: 데이터 사전과 사용자 데이터 파일에 접근하여 데이터를 읽고 쓰는 책임을 가진 구성요소

-질의 처리기:DB 사용자가 물리적인 단계의 지식이 없어도 개념적인 단계에서 SQL을 이용하여 스키마를 정의하고 해당 스키마에 데이터를 저장, 변경, 조회

-트랜잭션 관리자: DB파일에 여러 명의 사용자가 동시에 접근하여 데이터를 처리하더라도 데이

터에 이상 현상이 없도록 데이터의 일관성을 유지

 

2.DBMS의 종류

-Oracle, IBM DB2, MSSQL Server, MySQL, MariaDB, PostgreSQL

 

다.데이터베이스 구조

1)데이터 사전(DD, Data Dictionary)

-연관된 DB정보를 제공하는 읽기전용 테이블 또는 뷰 집합

#포함내용

-데이터베이스의 모든 스키마 객체 정보

-스키마 객체에 대해 할당된 영역의 사이즈와 현재 사용 중인 영역의 사이즈

-열에 대한 기본 값

-무결성 제약 조건에 대한 정보

-사용자 이름, 사용자에게 부여된 권한과 역할

-기타 일반적인 데이터베이스 정보

 

2)데이터베이스, 테이블 스페이스 및 데이터 파일

-데이터는 테이블을 통해서 논리적으로는 테이블스페이스에 물리적으로는 해당 테이블스페이스와 연관 데이터 파일에 데이터를 저장

 

3)데이터 블록, 확장 영역 및 세그먼트 간의 관계

-DBMS는 데이터베이스의 모든 데이터에 대한 논리적 데이터베이스 영역을 할당

-DB영역의 할당 단위는 데이터 블록, 확장영역, 세그먼트

 

#데이터 블록

*데이터를 저장하는 가장 작은 단위

*하나의 데이터 블록은 디스크상의 물리적 DB영역의 특정 바이트 수에 해당(2K, 4K, 8K) 테이블스페이스별로 사이즈 결정가능.

*1회 물리적인 디스크 I/O량을 결정

*데이터베이스의 용도(OLTP, DW)에 따라 적절한 사이즈 설정

*데이터 블록 체인을 최소화

*데이터블록의 구성

Header: 블록 주소와 세그먼트 유형 등 블록정보

Row directory: 램 데이터 영역에 있는 각 행 조각의 주소를 포함하여 블록에 있는 실제 행에 대한 정보

Free space: 새로운 행을 삽입하거나 후행 null을 null이 아닌 값으로 갱신할 때와 같이 추가 영역이 필요한 행을 갱신할 때 할당

Row data: 실제 데이터 저장

 

#데이터 확장 영역(EXTENT)

*특정 유형의 정보를 저장하기 위해 할당된 몇 개의 연속적인 데이터 블록

*데이터 블록의 초기 확장역영을 세그먼트에 할당, 할당된 데이터 블록이 모두 채워지면 새로운 확장영역을 자동 할당

*저장공간 낭비를 줄이고 무한정 확장되는 것을 방지

*데이터를 삭제하여도 확장된 영역을 반환하지 않음. 생성된 객체를 Drop하거나 Truncate해야 테이블스페이스로 반환

 

#세그먼트(SEGMENT)

*테이블스페이스 내에 어떤 논리적인 구조를 정의하기 위해 할당한 확장 영역의 집합으로, 테이블, 인덱스, 임시용 세그먼트가 지원

*특정 테이블의 데이터 세그먼트를 형성

*특정 테이블의 인덱스 세그먼트를 형성

 

라.메모리 구조

#DBMS 정보 저장

-실행되는 프로그램 코드

-현재 사용하지 않더라도 접속되어 있는 세션 정보

-프로그램 실행되는 동안 필요한 정보

-프로세스 간에 공유하거나 교환되는 정보(예 : Locking 정보)

-보조 메모리에 영구적으로 저장된 캐시 데이터

#데이터베이스 버퍼(BUFFER)

*데이터 파일로부터 읽어 들인 데이터 블록의 복사본을 저장

-먼저 프로세스에서 요구한 데이터를 버퍼에서 검색

-버퍼에 없으면 데이터파일에서 로드

-전체 테이블을 스캔한 경우 테이블 블록을 버퍼로 읽어들여 LRU목록의 MRU끝에 놓고, 자주사용되는 블록이 남아있도록 신속히 제거

-버퍼크기는 데이터 요구에 대한 적중률에 영향

*버퍼는 더티 목록과 LRU(Least Recently Used) 목록을 저장

#로그 버퍼(LOG BUFFER)

*데이터베이스의 변경 사항 정보를 유지하는 것으로 일반적으로 원형 버퍼를 사용

#공유 풀(SHARED POOL)

*라이브러리 캐시, 딕셔너리 캐시, 제어 구조 등으로 구성. 라이브러리 캐시는 SQL 영역, 저장 SQL 프로시저 영역, 제어 구조 등을 공유하고, 딕셔너리 캐시는 데이터 사전 정보를 공유

#정렬 영역(SORT AREA)

*인덱스를 생성하거나 SQL문에 GROUP BY 연산, ORDER BY가 있을 경우 정렬 작업을 수행

 

마.프로세스 구조

#사용자 프로세스

*애플리케이션이나 데이터베이스 도구를 실행할 때 생성

#서버 프로세스

*사용자 프로세스와 통신을 하는 역할. 다중 스레드 서버 방식과 단일 서버 프로세스 방식

#백그라운드 프로세스

*데이터베이스가 동작하기 위한 프로세스들로 구성

 

2.2데이터 액세스

가.실행 구조

-사용자는 데이터베이스를 이용할 수 있는 사용자 인터페이스에서 명령어를 입력하고 DB에 결과를 요청하면 네트워크 서비스를 통하여 DB인스턴스(엔진)에 전달
-전달된 명령어는 문법적인 오류나 의미적인 오류를 확인하고 옵티마이저에 의해 SQL로 요구된 결과를 최소의 비용으로 처리할 수 있는 최적의 처리 경로를 결정하여 실행 계획을 작성
-실행 계획에 의해 DB엔진은 실행 과정을 반복
-사용자에게 전달될 데이터 결과가 있으면 네트워크 서비스를 통하여 정해진 버퍼 사이즈만큼씩 전달 (Fetch)

 

*실행계획: SQL을 처리하기 위한 실행절차와 방법. 

-데이터베이스 엔진이 쿼리에서 요청한 데이터를 검색하고 처리하기 위해 수행하는 단계를 설명하는 로드맵

-조인방법/순서, 엑세스 기법

-대소문자 구분: SQL이 조금이라도 다르면 다른 것임

1)옵티마이저

-SQL의 실행계획을 작성(SQL을 어떻게 처리할 것인가를 결정)

-최적의 실행 계획을 찾는 과정을 최적화

-비용 기준 최적화(CBO): 비용을 우선순위로 실행계획을 작성. 비용 산정은 데이터베이스 내의 데이터들에 대해 갖고 있는 통계 정보와 비용을 예측하는 모델을 이용하여 비용을 계산

-규칙 기준 최적화(RBO):일정한 액세스 방법에 따라 정해진 우선순위로 실행 계획을 작성

2)SQL 실행 단계

#파싱(Parser)

-SQL의 구문과 의미가 정확한지 검사하고, 참조된 테이블에 대해 사용자가 접근 권한을 가지고 있는지를 검사

-라이브러리 캐시에서 같은 SQL 문장이 존재하는지 검색

SQL튜닝: SQL재작성, 힌트사용, 새로운 인덱스추가, 통계 데이터의 추가/갱신

#옵티마이저(Query Optimizer)

-앞에서 넘겨받은 결과 정보(parsed query)를 이용해 최적의 실행 계획을 선택

-실행계획의 실행 순서는 동일 레벨인 경우에 위에서 아래로, 레벨이 다른 경우에는 안에서 바깥으로 처리

#로우 소스 생성(Row Source Generator)

-옵티마이저에서 넘겨받은 실행 계획을 내부적으로 처리하는 자세한 방법을 생성

-로우 소스: 실행 계획을 실제로 구현하는 각 인터페이스를 지칭. 테이블 액세스 방법, 조인 방법, 정렬 등

#SQL 실행(SQL Execution Engine)

-생성된 로우 소스를 SQL 수행 엔진에서 수행한 결과를 사용자에게 돌려주는 과정

-소프트 파싱: 이미 최적화를 한 번 수행한 SQL 질의에 대해 옵티마이저 단계와 로우 소스 생성 단계를 생략
-하드 파싱: 이 두 단계를 새로 수행

 

나.명령어

-DDL, DML, 제어명령어

1)데이터 정의 언어(DDL, Data Definition)

-스키마 객체를 생성하고, 구조를 변경하고, 삭제, 명칭을 변경하는데 사용. CREATE, ALTER, DROP, RENAME,Truncate

-데이터베이스, 사용자, 테이블, 컬럼, 데이터 타입, 참조 무결성 제약 정의, 영역 무결성 제약 정의, 인덱스 등 관리

- 현재 진행되는 트랜잭션에 대해 암시적으로 COMMIT을 실행

2)데이터 조작 언어(DML, Data Manipulation)

-데이터베이스에 있는 데이터를 조작할 수 있게 해주는 명령어로 DELETE, INSERT, SELECT, UPDATE 등

#DML 처리 단계

*1단계 커서 생성: SQL문에 대해 독립적으로 생성. 모든 SQL문에 사용될 수 있도록 생성

*2단계 명령문 구문 분석: SQL문을 변화하여 유효한 명령문인지 검증

*3단계 질의 결과 설명(SELECT): 데이터 유형, 길이, 이름 등 질의 결과의 특성을 판별

*4단계 질의 결과 출력 정의(SELECT): 질의에 대한 정의 단계에서 위치, 크기, 인출한 각 값을 받기 위해 정의된 변수의 데이터 유형을 지정

*5단계 변수 바인드: 값을 찾을 수 있는 메모리 주소를 지정

*6단계 명령문 병렬화(병렬처리): 다중 서버 프로세스로 하여금 동시에 SQL문의 작업을 수행

*7단계 명령문 실행: SELECT나 INSERT문이면 잠금 불필요. UPDATE, DELETE문에 영향을 받는 모든 행은 트랜잭션에 대한 다음 처리까지 잠금

*8단계 질의 로우 인출(SELECT): 인출 단계에서 행이 선택되고 정렬

*9단계 커서 닫기

 

3)제어 명령어(Control Statement), DCL, TCL

-트랜잭션 제어문은 1개 이상의 SQL문을 논리적으로 하나의 처리 단위로 적용하기 위해 사용하는 명령어. Commit, Rollback

-세션 제어문은 실행하고 저장하는 SQL문에는 사용할 수 없으며 사용자 세션의 특성을 정의하는 명령어

-시스템 제어문은 시스템이나 데이터베이스 레벨에서 재기동 없이 환경 변수 등을 조정

 

다.트랜잭션 제어

-한 개 이상의 SQL문을 논리적으로 하나의 처리 단위로 적용하기 위해 사용하는 명령어

-COMMIT: 트랜잭션이 시작되고 현재 시점까지 변경/저장된 모든 데이터를 DB에 영구적으로 반영

-ROLLBACK: 트랜잭션이 시작되고 현재 시점까지 변경/저장된 모든 데이터를 무효화하고 트랜잭

션이 시작되기 전의 상태로 되돌림

-SAVEPOINT: 트랙잭션이 시작되고 데이터의 변경/저장이 진행되는 중간 지점마다 위치를 저장하여 ROLLBACK 명령 수행 시 ROLLBACK 지점을 명시하여 해당 지점까지만 ROLLBACK할 수 있음

 

2.뷰(View)의 활용

-하나 이상의 기본 테이블(또는 뷰)에서 원하는 데이터를 선택하여, 미리 SQL로 정의하여 놓은 가상 테이블

～기본 테이블로부터 유도된 가상의 테이블이므로 물리적인 저장 공간을 가지지 않음

～물리적인 공간을 가지지 않으므로 인덱스를 생성할 수 없음

~ 정의된 뷰가 기본 테이블의 기본 키를 포함하지 않으면 뷰를 통한 데이터의 입력, 수정, 삭제 작업 불가

～ALTER VIEW 명령문을 이용하여 정의를 수정할 수 없음

~ 기본 테이블로부터 논리적 데이터 독립성을 제공할 수 있음

～이미 정의된 뷰를 이용한 다른 뷰를 정의할 수 있어, SQL의 재사용성을 높일 수 있음

~ 기본 테이블에 대한 권한은 제거하고 제공 가능한 칼럼만 뷰로 제공함으로써 보안성 확보

-특정 DBMS(티베로)는 실체화된 뷰를 제공: 정의된 뷰를 이용하여 실행된 결과를 저장하고 있어 데이터를 저장하는 공간이 존재. 주로 DW에서 성능 향상 목적, OLTP에서 데이터의 복제와 같은 목적

 

3.사용자 관리

-DCL: 사용자를 생성, 삭제하고 권한을 제어할 수 있는 명령어

～사용자 생성 : CREATE USER

～사용자 삭제 : DROP USER

~ 권한 부여 : GRANT 〈권한 목록〉 TO 〈사용자ID>

～권한 회수 : REVOKE〈권한 목록〉 FROM〈사용자ID>

 

다.저장 프로시저

-DML은 비절차적 언어(PL/SQL, Transaction-SQL)을 이용해 저장 프로시저 생성

1)저장 프로시저 설계 지침

-높은 응집도와 낮은 결합도를 유지한 설계. 하나의 작업을 중점적으로 완료하도록 프로시저를 정의

2)저장 프로시저의 장점(생성무보메)

-보안: 사용자는 작성자의 권한으로 실행되는 프로시저와 함수를 통해서만 데이터에 액세스하도록 데이터베이스 작업 제한 가능

-성능: 네트워크를 통해 보내야 하는 정보의 양을 현격하게 감소

메모리 할당: 많은 사용자의 실행을 위해 프로시저의 단일 복사본만이 메모리에 로드

-생산성:  프로시저 집합으로 애플리케이션을 설계하여 불필요한 코딩을 피하고 생산성을 증가

-무결성: 애플리케이션의 무결성과 일관성을 향상

 

라.트리거

-접속된 사용자나 사용되는 애플리케이션에 관계없이 트리거 이벤트가 발생되면 DBMS에 의해 암시적으로 실행

1)트리거 사용

-파생값,무결성제약,권한,업무규칙,이벤트로깅,감사,테이블복제,엑세스통계

-자동적으로 파생된 열 값 생성(예 : 합계, 잔액, 재고량 등)

-잘못된 트랜잭션 방지(예 : 무결성 제약 구현)

-복잡한 보안 권한 강제 수행

-분산 데이터베이스의 노드상에서 참조무결성 강제 수행

-복잡한 업무규칙 강제 수행

-이벤트 로깅 작업이나 감사 작업

-동기 테이블 복제 작업

-테이블 액세스에 대한 통계 수집

 

2)트리거 유형

#행 트리거 및 명령문 트리거
-행 트리거: 테이블이 트리거링 명령문에 의해 영향을 받을 때마다 실행
-명령문 트리거: 테이블에서 트리거링 명령문에 의해 영향을 받는 행 수에 관계없이 한 번 실행

#BEFORE 및 AFTER 트리거

-BEFORE 트리거는 명령문이 실행되기 전에 트리거 작업을 실행

-AFTER 트리거는 명령문이 실행된 후에 트리거 작업을 실행

3)트리거링 이벤트와 제한 조건

 

2.3트랜잭션

- 더 이상 나눌 수 없는업무 처리 단위( 자기완결성)

가.트랜잭션 관리

-트랜잭션은 하나의 논리적 작업 단위를 구성하는 하나 이상의 SQL문으로 구성
-Commit: 실행한 논리적 작업 단위 전체가 성공적으로 종료되면 그 트랜잭션은 영구적으로 데이터베이스에 저장
-Rollback:  실행한 SQL 중 하나라도 정상 종료되지 않으면 논리적인 작업 단위 전체를 이전 상황으로 회복

-다중 사용자 환경에서 트랜잭션은 동시성 제어와 고장 회복(Recovery) 기법에 의하여 관리

 

나.트랜잭션 특징(ACID)

원자성(ATOMICITY): 트랜잭션은 완전히 수행하거나 전혀 수행되지 않은 상태로 회복

일관성 유지(CONSISTENCE): 트랜잭션을 실행하면 데이터베이스를 하나의 일관된 상태에서 또 다른 일관된 상태로 변경

고립성(ISOLATION): 하나의 트랜잭션은 완료될 때까지 자신이 갱신한 값을 다른 트랜잭션들이 보게 해서는 안됨

영속성(DURABILITY): 한 트랜잭션이 DB를 변경시키고 그 변경이 완료되면 결과는 이후의 어떠한 고장에도 손실되지 않아야 함. 회복기법으로 보장

 

다.트랜잭션의 일관성

-트랜잭션 수준 읽기 일관성은 트랜잭션이 시작된 시점을 기준으로 일관성 있게 데이터를 읽는 특성

-다른 트랜잭션에 의한 변경사항은 무시. 자신이 발생시킨 변경사항은 읽어야 함

1)낮은 단계 트랜잭션 고립화 수준에서 발생할 수 있는 현상들

#DIRTY READ(= UNCOMMITTED DEPENDENCY)

-다른 트랜잭션이 변경 중인 데이터를 읽었는데, 그 트랜잭션이 최종 롤백됨으로써 현재 트랜잭션이 비일관성 상태에 놓이는 현상

#NON-REPEATABLE READ(= INCONSISTENT ANALYSIS)

-한 트랜잭션 내에서 같은 쿼리를 두 번 수행할 때 그 사이에 다른 트랜잭션이 값을 수정 또는 삭제 함으로써 두 쿼리의 결과가 상이하게 나타나는 현상

#PHANTOM READ

-한 트랜잭션 내에서 같은 쿼리를 두 번 수행할 때 첫 번째 쿼리에서 없던 유령 레코드가 두 번째 쿼리에서 나타나는 현상

 

2)트랜잭션 고립화 수준(Transaction Isolation Level)

#레벨 0(= READ UNCOMMITTED), DNP

-트랜잭션에서 처리 중인 아직 커밋되지 않은 데이터를 다른 트랜잭션이 읽는 것을 허용
-Dirty Read, Non-Repeatable Read, Phantom Read 현상 발생

#레벨 1(= READ COMMITTED), NP

-트랜잭션이 커밋되어 확정된 데이터만 읽는 것을 허용
- Non-Repeatable Read, Phantom Read 현상 발생

#레벨 2(= REPEATABLE READ), P

-선행 트랜잭션이 읽은 데이터는 트랜잭션이 종료될 때까지 후행 트랜잭션이 갱신하거나 삭제하는 것을 불허
-Phantom Read 현상 발생

#레벨 3(= SERIALIZABLE READ)

-선행 트랜잭션이 읽은 데이터를 후행 트랜잭션이 갱신하거나 삭제하지 못할 뿐만 아니라 중간에 새로운 레코드를 삽입하는 것도 불허. 완벽한 읽기 일관성 제공

 

라.동시성 제어

-다수의 사용자가 데이터베이스에 동시에 접근하여 같은 데이터를 조회 또는 갱신을 할 때 데이터 일관성을 유지하기 위한 일련의 조치

-갱신손실, 모순판독문제를 방지하기 위함

#갱신손실(Lost Update)

-트랜잭션A와 트랜잭션B가 동시에 값을 읽어들인 후 수정하면 값이 두 트랜잭션 중 하나가 처리한 값이 되어 나머지 한 트랜잭션의 값이 반영되지 않는 현상

#모순 판독 문제

-한 트랜잭션이 값을 갱신중인데 다른 트랜잭션이 값을 읽어서 합계를 계산

 

1)낙관적 동시성 제어

-사용자들이 같은 데이터를 동시에 수정하지 않을 것이라고 가정

-읽는 시점에는 잠김을 사용하지 않지만 데이터를 수정하고자 하는 시점에 앞서 읽은 데이터가 다른 사용자에 의해 변경되었는지를 반드시 검사

-데이터를 읽을 때는 잠김을 설정하지 않음. 잠김이 유지되는 시간이 매우 짧아져 동시성을 높이는데 유리

2)비관적 동시성 제어

-사용자들이 같은 데이터를 동시에 수정할 것이라고 가정

-한 사용자가 데이터를 읽는 시점에 잠김을 걸고 조회 또는 갱신 처리가 완료될 때까지 이를 유지

-시스템 동시성이 심하게 떨어질 수 있으니  wait 또는 nowait 옵션을 함께 사용

-Locking, Timestamp Ordering

 

마.동시성 제어기능

-Locking, 2PC, Timestamp 등의 기법

-잠김은 암시적인 잠김 (Implicit Locking)과 명시적인 잠김(Explicit Locking)

#잠김 단위(LOCK GRANULARITY 또는 ISOLATION LEVEL)

-잠김 단위는 잠김 대상의 크기를 뜻하며, 단위가 커지면 관리해야 하는 대상의 수가 적어지므로 DBMS가 관리하기 쉬워지지만 동일한 잠김 대상에 동시 액세스할 확률이 높아져 충돌이 자주 발생

-잠김의 단위가 작아지면 관리해야 하는 대상의 수가 많아져 관리하기는 어려워지지만 동일한 잠김 대상에 동시 액세스할 확률이 낮아져 충돌 횟수는 적어짐

#잠김 확산(LOCKING ESCALATION)

-관리해야 하는 잠금 단위의 개수가 미리 설정한 임계치에 도달하게 되면 잠김의 단위를 현재 관리하고 있는 단위보다 하나 높은 수준으로 올리는 기능

#잠김(LOCKING)의 유형

-읽기 작업에서는 공유 잠금(Shared lock)을 필요로 하고 쓰기 작업에서는 배타적 잠금(Exclusive lock)

 

RS: row share(or SS: sub share)

RX: row exclusive(or SX: sub exclusive)

S: share

SRX: share row exclusive(or SSX: share/sub exclusive)

X: exclusive

#2PC(2 PHASE COMMIT)

-2개 이상의 트랜잭션들이 병행적으로 처리되었을 때의 데이터베이스 결과는 그 트랜잭션들을 임의의 직렬적인 순서로 처리했을 때의 결과와 논리적으로 일치해야 함.
-병렬로 수행되는 트랜잭션의 직렬 가능성을 보장하는 방법

-트랜잭션은 Locking을 거는 성장 단계(Growing Phase)와 Locking을 푸는 축소 단계(Shrinking Phase)의 2단계로 구성. 분산DB에서도 동일

 

#교착 상태(DEAD LOCK)

-다른 사용자가 잠근 자원이 해제되기를 기다리면서 자신이 잠근 자원을 해제하지 않는 상태

-상호배제: 어느 자원에 대해 한 프로세스가 이미 사용 중이면 다른 프로세스는 기다림

-점유와 대기: 한 프로세스가 자원을 할당받은 채로 다른 프로세스가 할방받은 자원이 해제되기를 기다림

-비선점: 자원을 할당 받은 프로세스로부터 자원을 빼앗지 못함

-환형대기: 자원할당 그래프 상에서 환형 사슬이 존재

 

바.동시성 구현 사례

-선분이력:

 

사.고장 회복

-트랜잭션 처리 중 장애가 발생했을 경우 데이터를 트랜잭션이 시작되기 이전 상태로 회복. UNDO로 롤백

 

아.잠김 지속 시간(Locking duration)

-Locking에 의한 경합은 식별자 번호를 얻기 위한 채번 로직에서 많이 발생. 따라서 채번은 트랜잭션 종료 시점에 실시하여 locking duration을 최소화하거나 시퀀스나 데이터 타입으로 자동 번호 발생 객체를 사용

 

#채번 설계

-오브젝트나 데이터 타입을 이용하여 자동으로 발생하는 DB기능을 이용하면 잠김 현상에 의한 지연 최소화

-잠김지속시간 단축을 위해 장기 트랜잭션을 최소화

-채번 테이블은 최적화된 액세스를 위해서 인덱스 전략이 필요.

 

2.4백업 및 복구

-전산 장비의 고장이나 사고에 대비하여 주기적인 백업을 실시하고 장애의 원인을 해결한 후 데이터베이스를 복구해야함

가.장애유형

#사용자 실수: 테이블의 삭제하거나 잘못된 트랜잭션 처리로 데이터의 일관성에 문제가 되는 경우

#미디어 장애: 하드웨어 장애는 CPU, 메모리, 디스크 등 다양하게 발생. 하드웨어 장애는 하드웨어 교체로 문제를 해결할 수 있지만 미디어 장애는 데이터가 파손되는 장애

#구문 장애: 프로그램 오류나 사용 용량이 부족하거나 여유 공간이 부족하여 발생하는 장애

#사용자 프로세스 장애: 사용자 프로그램이 비정상 종료되거나 네트워크 이상으로 세션이 종료되므로 발생

#인스턴스 장애: 시스템이 비정상적인 요인으로 메모리나 데이터베이스 서버 프로세스가 중단된 경우

 

나.로그 파일

#로그파일 기록 시기

-트랜잭션 시작시점

-데이터의 입력, 수정, 삭제 시점

-트랜잭션 rollback 시점

#로그 파일 내용

:트랜잭션이 발생할 때마다 COMMIT이나 ROLLBACK에 관계없이 모든 내용을 기록

-트랜잭션 식별자

-트랜잭션 레코드

-데이터 식별자

-갱신 이전 값(Before Image)

-갱신 이후 값(After Image)

#로그 파일 보관

로그 파일은 로그 버퍼 내용을 Flat-file 형식으로 기록.  로그 파일을 저장 매체(테이프)로 영구 보관

 

다.데이터베이스 복구 알고리즘

-동기적 갱신(Synchronous I/O): 트랜잭션 실행 내용인 DB버퍼를 저장매체에 동기적으로 기록하는 기법.
-비동기적 갱신(Asynchronous I/O): 트랜잭션이 완료된 내용을 일정 시간이나 작업량에 따라 시간 차이를 두고 DB버퍼 내용을 저장 매체에 기록하는 기법

 

#NO-UNDO/REDO

-데이터베이스 버퍼의 내용을 비동기적으로 갱신. 트랜잭션이 성공적으로 수행되어 완료점에 도달할 때까지 DB 변경 내용이 기록되지 않음.
-트랜잭션이 완료된 후 DB버퍼에 기록되고 저장 매체에 기록되지 않는 상태에서 시스템이 파손되었다면 트랜잭션의 내용을 재실행

#UNDO/NO-REDO

-DB 버퍼의 내용을 동기적 갱신. 트랜잭션이 완료되기 전에 DB버퍼 내용을 모두 동시적으로 기록하므로 완료된 트랜잭션들은 어떤 연산도 재실행할 필요가 없음
-트랜잭션들이 완료되기 이전에 시스템 파손이 발생할 경우 변경된 내용을 취소

#UNDO/REDO

-데이터베이스 버퍼의 내용을 동기/비동기적으로 갱신할 경우 모든 갱신이 DB에 기록되기 전에 트랜잭션이 완료될 수 있으므로 완료된 트랜잭션이 DB에 기록되지 못했다면 재실행

#NO-UNDO/NO-REDO

-DB 버퍼 내용을 동시적으로 저장 매체에 기록하나 DB와는 다른 영역에 기록 하는 경우
-항상 트랜잭션의 실행 상태와 데이터베이스의 내용이 일치하므로 데이터베이스 버퍼의 내용을 취소하거나 재실행할 필요가 없음

 

-복구작업은 DB오픈전인 마운트 상태에서 진행

 

라.백업 종류

-물리백업: 로그파일 백업 실시(완전복구), 로그파일 백업 없음(백업시점까지 복구)

-논리백업: DBMS 유틸리티

 

마.데이터베이스 백업 가이드 라인

#정기적인 Full-backup

#DB 구조 변화 전후 Full-backup

-테이블 스페이스의 생성 또는 삭제

-테이블 스페이스에 데이터 파일을 추가하거나 변경했을 때

-Log 파일을 변경했을 때

-Archive Log Mode로 전환 시 Control 파일만이라도 백업 

-No-archive log mode로 전환할 때는 Full backup

#Read-write 수행이 많은 테이블스페이스는 자주 온라인 백업

#백업 파일은 2본 이상을 보유. Incomplete Recovery를 용이하게 함

#논리 백업은 특정 데이터 또는 특정 테이블 오류 시 복구가 용이함

#분산 데이터베이스는 동일 모드에서 백업을 수행함

#Read-only테이블스페이스는 온라인 백업 불필요

 

#로그파일 없이는 완벽한 복구 불가능.

#논리백업에 의한 복구는 백업시점상태로 데이터를 생성하는 것으로 UNDO/REDO 작업이 없음

 

3.데이터베이스 성능 개선

3.1성능 개선 방법론

가.성능 개선 목표

-처리능력, 처리시간, 응답시간, 로드 시간

#처리 능력(THROUGHPUT)

-해당 작업을 수행하기 위해서 소요되는 시간으로 수행되는 작업량을 나눔으로써 정의
처리능력 = 트랜잭션 수 / 시간

#처리 시간(THROUGHPUT TIME)

-작업이 완료되는데 소요되는 시간

*배치작업 수행시간 단축을 위한 고려사항

-병행 처리

-인덱스 스캔보다 Full 테이블 스캔

-Nest-Loop 조인보다 Hash 조인

-대량 작업을 하기 위한 SORT_AREA, HASH_AREA 의 메모리 확보

-병목을 없애기 위해서 작업 계획

-대형 테이블인 경우는 파티션으로 생성

#응답 시간(RESPONSE TIME)

-입력을 위해 사용자가 키를 누른 때부터 시스템이 응답할 때까지 시간

*응답시간 향상을 위한 고려사항

-인덱스를 이용하여 액세스 경로를 단축

-부분범위 처리를 실시

-Sort-Merge 조인이나 Hash 조인을 사용하지 않고 Nest-Loop 조인으로 처리

-잠김(Locking) 발생을 억제. 예:시퀀스 오브젝트 이용

-하드 파싱을 억제(옵티마이저, 로우 소스 생성 단계 생략)

#로드 시간(LOAD TIME)

-정기적이거나 비정기적으로 발생되는 DB에 데이터를 로드하는 작업 수행 시간

*로드시간 단축을 위한 고려사항

-로그 파일을 생성하지 않는 Direct Load를 사용

-병렬 로드 작업을 실시.

-DISK IO 경합이 없도록 작업을 분산

-인덱스가 많은 테이블인 경우는 인덱스를 삭제하고 데이터 로드 후 인덱스를 생성

-파티션을 이용하여 작업을 단순화

 

나.성능개선 절차

1)분석

#자료수집

-DB 모니터링

-데이터베이스 객체 현황 파악

-물리 설계 요소에 대해 성능과 관련된 지표

#목표설정

-수집된 기초 자료를 통해 데이터 모델 분석, 액세스 패스 분석, 시스템 자원 현황 분석, SQL 성능 분석, SQL 효율 분석 등을 종합하여 성능상에 병목이나 지연 등과 같은 문제 요소 등을 구체적으로 파악하고 성능 튜닝의 대상이 되는 목표들을 구체화하여 방향을 설정

2)이행

-성능상의 문제 요소로 파악된 대상에 대해 최적화 방안을 수립하고 적용

-DB 파라미터 조정

-전략적인 저장 기법 적용을 위한 물리 설계 및 디자인 검토

-비효율적으로 수행되는 SQL 최적화

-네트워크 부하 등을 고려한 DB분산 구조 최적화

-적절한 인덱스 구성 및 사용을 위한 인덱스 설계 등의 최적화 작업

3)평가

-분석 단계에서 진단을 통해 분류된 문제 요소들에 대해 설정된 개선 목표와 이행단계에서 구체적인 튜닝 작업을 수행한 후의 성과를 비교 측정

 

다.성능 개선 접근방법

-SQL(애플리케이션)>DB Object> DBMS Instance(메모리, 프로세스)> DBMS 환경(서버, 디스크)

-DB와 애플리케이션(SQL)의 비효율로 발생

-문제점의 튜닝을 통한 DB 최적화

-문제가되는 SQL을 튜닝

 

라.SQL 성능 분석

-실행 계획: SQL이 실행되기 위해서는 실행 가능한 소스코드로 변환되어야 하는데 이 소스코드를 생성하기 위한 실행 전략을 말함

-옵티마이저는 실행 계획을 수립하기 위해 SQL을 관계 대수 형태로 변환하고 개별 연산자의 알고리즘을 다양한 방법으로 결합해 이들을 트리 형태로 표현

1)실행계획분석사례

 

마.성능 개선 도구

-DBMS에서는  서버 상태, Trace, Dictionary 정보, 실행 계획을 제공

*SQL Trace 분석

 

SQL 수행시간: 

-total cpu / total count = 0.016 / 9 = 0.0013

-total elaspse / exectue count = 0.203 / 7 = 0.029  (0.03 초 이내)

parse 오버헤드: parse elapsed / execute elapsed = 0.147 / 0.015 = 0.01 (10% 이내)

Block I/O : total disk / total rows = 58 / 560 = 0.1 (1미만)

Disk 병목: total elpased / total cpu = 0.203 / 0.016 = 0.01, 100% 이상이면 병목현상(풀스캔)

Array Processing: fetch rows / fetch count = 560/7 = 80, 1보다 큰 10배수면 O, 1에 가까우면 X

recursive overhead: recursive execute / non-recursive  execute

 

#call : 커서 상태에 따라 Parse, Execute, Fetch 세 개의 Call로 나누어 각각에 대한 통계정보를 보여준다.

 -Parse : 커서를 파싱하고 실행계획을 생성하는데 대한 통계이다.

 -Execute : 커서의 실행 단계에 대한 통계이다.

 -Fetch : 레코드를 실제로 Fetch하는 데 대한 통계이다.

#count :: Parse, Execute, Fetch 각 단계가 수행된 횟수이다.

#cpu :: 현재 커서가 각 단계에서 사용한 cpu time이다.

#elapsed :: 현재 커서가 각 단계를 수행하는 데 소요된 시간이다. Call 단위로 측정한다.

  Elapsed Time = CPU Time + Wait Time = Response시점 - Call 시점

   -하나의 SQL을 수행할 때 Total Elapsed Time은 수행 시 발생하는 모든 Call의 Elapsed Time을 더해서 구한다.

#disk : 디스크로부터 읽은 블록 수

#query : Consistent 모드에서 읽은 버퍼 블록 수

#current : Current모드에서 읽은 버퍼 블록수

#rows :: 각 단계에서 읽거나 갱신한 처리건수

3.2조인(Join)

-카티션 프로덕트를 수행 후 셀렉션과 프로젝션을 수행하는 데이터베이스의 연산

-Nested loops 조인, Sort merge 조인, Hash 조인. Hybrid 조인, Star 조인과 Semi 조인

-조인 조건이 (=)로 정의되었다 면 equi 조인이라 하며, >=, <=, between 등이 조인 조건에 기술되었다면 between 조인

-조인의 결과가 Outer 집합에 의하여 결정되는 Outer 조인(합집합)과 Inner 집합에 의하여 결정되는 Inner 조인(교집합)

-Oter 집합: 바깥쪽 루프에서 엑세스 되는 집합

-Inner 집합: 안쪽 루프에서 엑세스되는 집합

-Inner Join = B

-Outer Join = A

-드라이빙테이블: 먼저 액세스되는 테이블, outer table

-드리븐테이블: 나중에 액세스되는 테이블, inner table

 

가.Nested-Loop 조인

-조인 연산은 두 집합을 카티션 프로덕트 형태로 모든 튜플을 열거한 다음, 조인에 만족하지 않는 튜플을 제거하는 두 가지 알고리즘으로 구성

-Outer table처리범위에 따라서 Inner 테이블 처리 범위 결정

-처리하는 데이터 양이 많을 경우 과도한 Random I/O 엑세스 발생. 

-적은 규모의 데이터 조인에 유리하기 때문에 OLTP환경에서 비교적 많이 사용.

-조인칼럼의 인덱스 유무가 조인의 순서와 성능에 영향

-결과를 하나씩 받아서 순차적으로 조인하는 형태이므로 부분범위 처리 가능

 

#조인조건

-Indexed nested-loop 조인으로 수행되려면 Inner 테이블에 조인 조건으로 사용된 칼럼에 반드시 인덱스가 존재해야함

-드라이빙 행수에 따라서 조인 행수가 결정됨.

#조인순서

-옵티마이저는 조인 시 먼저 드라이빙 테이블을 결정하고 나머지 집합의 조인 순서를 결정

-드라이빙 테이블은 드라이빙의 범위가 가장 작은 집합, 즉 가장 작은 작업량을 가지고 드라이빙할 수 있는 집합을 선정하고 조인의 순서를 정할 때에는 조인의 효율이 좋은 집합을 먼저 조인에 참여

 

나.Sort-Merge 조인

-조인하려는 두 집합을 조인 속성으로 정렬 sorted lists를 만든 후 이들을 merge하는 조인

-동등 조인(=, equi), 비동등 조인에서도 사용이 가능.

 

#출력 및 연결 순서

-정렬된 결과를 순차적으로 비교하여 머지를 수행하므로 Outer 집합의 정렬 순서와 Inner 집합의 정렬 순서가 머지되어 출력

#조건절

-정렬에 참여하는 로우의 수에 의해 수행 속도 결정

#이용

-독립적으로 처리 범위를 줄인 후 조인에 참여하므로 테이블 각각의 조건에 의해 대상 집합을 줄일 수 있을 때 유리

-처리 대상이 전체 테이블일 때 랜덤 IO 부하가 큰 Nested-Loop 조인보다 유리

-조인 속성에 인덱스가 없을 때 Simple Nested-Loop 조인보다 성능이 우수

-효과적인 수행을 위해서는 적정한 SORT AREA 사이즈 확보 필요. Sort Area Size가 부족하면 디스크에서 정렬작업 수행하기 때문에 많은 오버헤드 발생.

-정렬에 대한 부하가 많이 발생하므로 대용량 처리 시 수행 속도 저하 가능.

 

다.Hash 조인

-관계형 데이터베이스에서 비용이 가장 많이 들어가는 조인 방법이지만 대용량의 데이터 조인 시에 Sort-merge 조인이나 Nested-Loop 조인보다 더 좋은 성능

-조인 컬럼에 인덱스가 없어서 Natural Join이 비효율일때

-Natural Join시 드라이빙 집합 쪽으로 조인 엑세스량이 많아 Random 엑세스 부하가 심할때

-equi join 조건이 하나라도 있어야 함.

- 랜덤액세스 없음

-정렬작업 없음

-조인에 참여한 두 집합 중에서 작은 집합의 해쉬 테이블을 메모리상에 만들고 큰 집합은 조인을 위해 해쉬 테이블을 탐침

-아주 큰 테이블과 아주 작은 테이블의 조인에 적합하며 Hash Area Size에 따라 성능 편차가 심함

 

#조인 수행 단계

STEP 1 - 파티션 수: 파티션의 개수가 많으면 I/O 효율 떨어짐

STEP2 - 해쉬 함수: 조인에 참여한 두 집합 중에서 작은 집합을 드라이빙 테이블로 선택하여 메모리로 읽어 들임. 해쉬되는 로우가 파티션에 골고루 분산되게 하기 위해 해쉬 함수1을 사용하여 해당 파티션에 매핑하고, 해쉬 함수2를 사용하여 생성된 해쉬 값은 다음 단계를 위하여 조인키와 함께 저장

STEP3 - 비트맵 벡트: 비트맵은 2차원 버켓으로 이루어져 있으며 해쉬 함수 1,2를 통과하여 생성

STEP 4 - 디스크에 파티션 쓰기: Hash area가 모두 차면 가장 큰 파티션이 디스크로 내려감

STEP5 - 메모리에 적재 가능한 최대 파티션
최대 파티션 수를 정하고 크기순으로 파티션을 정렬
파티션 번호가 가장 작은 것부터 선택하여 메모리에 로드
나머지는 디스크에 저장

STEP6 - 작은 집합의 해시 테이블 생성: 이미 생성된 해쉬 값을 사용하여 해시 테이블을 생성

STEP7 - 비트 벡터 필터링: 조인 수행 시 비트맵과 대조하여 1이면 조인을 해야 하는 로우로 인식하고 아니면 조인이 필요 없는 로우이므로 버림

STEP8 - 처리되지 않은 파티션 쌍을 디스크로부터 읽어오기: 큰 집합의 파티션이 끝나면 작은 집합의 수행되지 않은 파티션들이 최대한 메모리로 올려지고 해쉬 테이블이 생성. 그에 대응되는 큰 집합의 파티션이 다시 읽혀져 메모리 조인이 실행

 

라.Hybrid 조인

-Nested-Loop 조인과 Sort-merge 조인의 알고리즘을 혼합

-Inner 테이블의 인덱스를 탐침할 때마다 테이블을 검색하는 것이 아니라 Inner 테이블의 인덱스를 탐침한 후 그 결과를 중간 집합으로 생성하여 중복이 없는 Rowid 리스트를 만들고, 그 결과를 가지고 Inner 테이블의 페이지를 탐침하는 조인 방식

 

*Star 조인

-여러 개의 작은 테이블을 Cartesian product 조인한 결과와 대용량 테이블과 조인

-DW환경에서 큰 팩터 테이블과 아주 작은 디멘전 테이블이 조인할때 유리

-랜덤 엑세스 감소

-/*+ start */ 힌트 사용

 

-조인조건은 연산자로 표시하기도 하는데 조인조건이 등호(=)로 정의되어 있다면 Natural 조인을 의미

-조인 조건으로  =, <=, >=, between 등의 연산자 모두 사용 가능

-Inner join(교집합)은 inner table에 조인 조건을 만족하는 집합이 존재하는 경우에만 결과집합에 참여

-Outer join(합집합)은 Outer table에 존재하는 집합중에서 Inner table join 조건을 만족하는 집합이 존재하지 않더라도 결과집합에 참여

3.3애플리케이션 성능 개선

가.온라인 프로그램 성능 개선

-성능 개선 목표는 응답시간 단축

#온라인 프로그램의 특징

-화면 조회가 가능할 정도로 1회 조회 데이터가 소량

-신속한 트랜잭션 처리가 요구

-조회 조건이 단순

-업무 형태에 따라 데이터 액세스 패턴이 고정됨

*온라인 프로그램 성능 개선 작업 고려사항

-사용 빈도가 높은 SQL 문을 개선

-인덱스를 이용하여 데이터 액세스 범위를 감소

-부분범위 처리로 응답 시간 단축

-부분 범위 처리를 하기 위해서 Nested-Loop 조인과 인덱스를 이용한 정렬을 유도

-장기 트랜잭션 처리를 억제

 

#부분범위처리

-논리적으로 전체범위를 읽지 않고 결과를 얻을 수 없는 경우를 제외하고 부분범위처리 가능

-UNION을 포함한 SQL은 전체범위 처리를 통해서만 결과를 얻을 수 있음

-ORDER BY를 사용하여도 동일한 순서의 인덱스가 존재하면 부분범위 처리로 수행

-조회조건이 여러 테이블에 분산되어 있거나 정렬 또는 집계가 필요한 경우에는 부분범위 처리가 어려움

 

나.온라인 프로그램의 성능 개선 사례

1)상수 바인딩에 의해 발생되는 파싱 부하

:상수는 하드 파싱, 변수는 소프트 파싱.

2)웹게시글 형태의 인터페이스 시 부분 범위 처리

3)과다한 함수 사용으로 인한 부하 발생

 

다.배치 프로그램의 성능 개선

- 처리시간의 최소화에 가장 큰 목적

-전체 처리 시간을 개선하기 위해 전체 범위 처리, 병렬처리, 조인 방식(Nested-loop조인을 Hash join으로 변경) 등의 개선 필요

-자원의 경합 감소를 위해서 작업계획을 실시

#배치 작업 서버 이슈

-절대 수행 시간 부족

-수행 결과 검증 시간 확보의 어려움

-오류에 따른 재처리 시간 확보가 불가능

-미완료 시 대안 제시에 어려움

-미처리 또는 지연으로 파급되는 문제 해결에 장시간 소요됨

-일배치 작업은 익일 영업시간 전에 월배치 작업은 익월전에 작업이 완료되어야 Racing현상이 발생하지 않음.

-작업계획 시 오조작이나 장애 등을 대비하여 여유 수행시간을 확보해야 함

-재작업에 따른 절대시간이 필요함

 

1)절차적인 처리 방식의 비효율

-SQL이 루프 내에서 반복적으로 수행되는 구조이므로 DBMS call이 과도하게 발생.

-단위 SQL이 반복적으로 수행되는 구조이므로 Random I/O 발생이 증가

-동일 데이터를 반복해서 읽음

-업무 규칙을 절차적으로 구성하였기 때문에 업무 규칙이 변경되면 프로그램 구조의 수정이 불가피.

-다수의 단위 SQL로 구성되어 있어 개별적인 단위 SQL의 개선만 가능.

 

2)절차적인 처리방식의 보완 요소

-이중 커서 사용을 하지 않고 조인을 이용하여 단일 커서를 사용

-동일 모듈내에서는 같은 데이터를 2회 이상 읽지 않게 프로그램을 구조화

-최소한 개별적인 SQL 단위 비효율을 제거

 

3)집합적인 처리방식의 고려사항

-집합적 처리: 사용자가 기술한 SQL을 1번의 DBMS Call로 Result Set을 생성하는 DBMS 연산

-SQL 작성 후 원하는 방식으로 실행 계획이 수립되었는지 반드시 확인

-대량 배치 처리와 같이 대용량 데이터를 처리해야 하는 경우는 Hash 조인이 유리

-분포도가 나쁘면 Random IO 비효율이 급속도로 증가하므로 인덱스 스캔보다 Table full scan 이 유리

-대용량 데이터 처리 시 병렬처리를 사용하여 처리 시간을 단축

-Hash 조인이나 집계를 위한 정렬작업을 고려하여 추가 메모리를 세션에 할당

-집합 처리에 의한 작업은 병행 처리, Full scan, 메모리 영역 확보 등으로 짧은 시간에 DB의 자원을 확보하여 처리
-작업의 종속성을 고려하여 배치 프로그램 작업 계획을 수립하여 자원의 경합을 낮춤.

 

4)분석 함수를 통한 성능 개선 방안

-업무 분석 요구를 수용하기 위해 포인터와 오프셋의 개념을 추가시킨 다양한 분석 함수의 다양한 기능을 포함

*장점

-쿼리 속도 향상

-셀프조인, 절차적 로직을 Native SQL에서 바로 적용하여 Join 및 프로그램 오버헤드 감소

-유지보수 용이, 생산성 향상

 

#오라클함수

-RANKING FAMILY:대상 집합에 대하여 특정 칼럼(들) 기준으로 순위나 등급을 매기는 분석 함수 그룹

-WINDOW AGGREGATE FAMILY:현재 행을 기준으로 지정된 window 내의 행들을 대상으로 집단화 (aggregation)를 수행하여 여러 가지 유용한 집계 정보(running summary, moving average 등)를 구하는 분석 함수군

-REPORTING AGGREGATE FAMILY: 서로 다른 두 가지의 집계 레벨을 비교하고자 하는 목적으로 사용하는 분석 함수군

-LEAD/LAG FAMILY:서로 다른 두 행 값을 오프셋으로 비교하기 위한 분석 함수응

-Rollup: 시간 및 지역처럼 계층적 분류를 포함하고 있는 데이터의 설계에 적합

-Cube: Group by의 확장. 디멘전 그룹에 대해 가능한 모든 값에 대하여 Cross-tabulation Values를 생성

 

5)파티션 스토리지 전략을 통한 성능 향상 방안

-파티셔닝은 대용량의 큰(지속적으로 증가하는) 테이블을 파티션이라는 보다 작은 단위로 나눔으로써 성능이 저하되는 것을 방지하고 관리를 보다 수월하게 하고자 하는 개념
-컬럼단위 수직 파티션, 범위 파티션(Range)

-데이터 액세스 시에 파티션 단위로 액세스 범위를 줄여 I/O에 대한 성능 향상

-여러 분할 영역으로 나눔으로써 전체 데이터의 훼손 가능성이 감소하고 데이터의 가용성이 향상

-각 분할 영역을 독립적으로 백업하고 복구

-디스크 스트라이핑으로 I/O 성능을 향상

 

3.4서버 성능 개선

가.객체 튜닝

-테이블, 인덱스, 세그먼트에 관련한 사항이 대상

-객체는 성능을 고려하여 설계

-저장 장치를 이루는 블록, 확장 영역, 세그먼트에 관련된 사항을 튜닝

-인덱스는 삭제, 갱신으로 스큐 현상이 심한 경우는 재구성 작업이 필요

-I/O 병목이 발생하지 않게 물리적인 배치를 실시

 

나.인덱스 튜닝

-메모리 부분과 프로세스가 튜닝 대상

#메모리

-메모리는 Buffer 캐시, library 캐시 등의 히트율에 의해서 평가하여 조정

-Sort area, Hash area는 스와핑 발생 여부에 따라 사이즈를 결정

#프로세스

대부분의 DBMS가 다중 프로세스 시스템이고 필요에 따라서 추가적인 프로세스 가동이 가능

#LATCH 경합

-트랜잭션 처리를 위한 경합이 발생

-객체 생성이나 변경 등으로 경합이 발생 가능

 

다.환경 튜닝

-하드웨어나 운영체제 관점에서의 튜닝

#CPU

CPU 사용율:성능을 평가하기 위한 기준

-SAR(System Activity Report)로 모니터링 했을 때 CPU 사용이 %usr > %sys > %wio 순으로 되는 것이 바람직

-%idle이 일반적으로 20~30%을 유지하는 것이 바람직하며, 0%인 상태가 지속적으로 유지되면 증설 고려

-Sun - ps, HP - top 또는 glance, IBM - monitor 등의 프로세스별 모니터링이 가능

#Memory 튜닝

-Paging(page-in, page-out)과 프로세스 단위의 Paging 현상인 Swapping 발생 상태를 확인

-DBMS를 포함한 사용자 사용 메모리 크기가 전체 크기의 40 ~ 60%를 유지하는 것이 바람직

 

#I/O 튜닝

-데이터베이스 병목은 I/O에 의해서 발생

-물리적인 디스크와 디스크 채널을 분산하므로 성능을 개선 가능

-읽기/쓰기 작업에 따른 분산이 필요

-Block (File System)보다는 Raw Device가 I/O 성능에 유리

-고가용성을 위한 시스템구성, RAID구성, 버전 등에 따른 패치 적용이 정상적이지 않을 경우 성능상 결정적인 영향을 줄 수 있음

-DB 가 사용하는 메모리 영역에 따라서 Hit율을 일정수준 이상으로 유지한다면 메모리 용량에 따른 성능 개선은 영향이 없음

 

#네트워크 튜닝.

-대용량 데이터 전송이 빈번하다면 전송속도와 대역폭 증가 고려

 

#튜닝계획

1단계: Access Path를 조사하여 인덱스 디자인 실시

2단계: 실행계획을 이용한 SQL 튜닝

3단계: Trace를 이용한 SQL 튜닝

4단계: 통합테스트를 통한 성능검증 및 튜닝

-온라인 프로그램은 응답속도 단축이 목표

-온랑인 프로그램은 효과적인 인덱스 디자인없이 성능향상 불가능

-잠재된 문제 SQL을 튜닝하기 위해서 Trace분석에 의한 접근방법이 효과적

-온라인 프로그램은 실행횟수가 많은 프로그램부터 튜닝을 진행하는 것이 전체 시스템의 성능 향상

 

#성능개선작업 목표설정 기준

-SQL 처리시간

-응용프로그램에서 측정된 DB 응답시간

-데이터 이행을 위한 로드 시간

 

#성능 개선 방법

-성능 개선 목표에 따라서 개선대상과 범위를 설정. 개선대상은 트레이스 기능이나 모니터링 도구를 이용하여 실행시간, 실행횟수, 대기시간, 발생 I/O 등을 고려하여 시스템 자원을 많이 사용하는 순으로 선정.

-가장 많이 실행되는 SQL문

-트랜잭션 처리에 의한 지연현상도 개선 대상

-SQL 성능 개선은 처리 프로그램의 특성에 따라 다른 개선안에 제시

 

#모니터링도구 장단점

-성능개선작업에 상위대기이벤트를 수집하여 정보로 제공하는 도구가 많이 사용.

-모니터링은 문제를 발견하기 위한 도구, 복합적인 문제를 해결하는 것은 사람

-단위SQL의 문제점을 제시할 수 있으나 그 SQL이 실행하는 프로그램 구조에 대한 개선점을 제시하는데 한계

 

#컬럼 null 연산

col1 col2 col3

============================

10 20 null

15 null null

50 70 20

 

select sum(col2+col3) 는 90

-컬럼간 연산에 null이 포함되면 결과는 null

-행간 연산에 null이 포함되면 결과는 null 아님

 

맨 위로 이동

 

DAP 1장 전사아키텍처 이해

 

DAP 2장 데이터 요건 분석

 

DAP 3장 데이터 표준화

 

DAP 4장 데이터 모델링

 

DAP 6장 데이터 품질 관리 이해

 

제1장 데이터 모델링 이해

제1절 데이터 모델링 개요

제2절 데이터 모델링 기법 이해

제3절 데이터 모델링 표기법 이해

 

제2장 개념 데이터 모델링

제1절 개념 데이터 모델링 이해

제2절 주제 영역 정의

제3절 후보 엔티티 선정

제4절 핵심 엔티티 정의

제5절 관계 정의

제6절 개념 데이터 모델 작성

 

제3장 논리 데이터 모델링

제1절 논리 데이터 모델링 이해

제2절 속성 정의

제3절 엔티티 상세화

제4절 이력관리 정의

제5절 논리 데이터 모델 품질 검토

 

제4장 물리 데이터 모델링

제1절 물리 데이터 모델링 이해

제2절 물리 요소 조사 및 분석

제3절 논리-물리 모델 변환

제4절 반정규화

제5절 물리 데이터 모델 품질 검토

 

 

1장데이터 모델링 이해

1절데이터 모델링 개요

1.데이터 모델링 정의

가.데이터 모델링 탄생 배경

2)모델 정의

-데이터 모델은 현실 세계에 대해 우리가 관심있어 하는 대상을 데이터베이스화 하기 위한 개념적 도구

-물리적 모델: 현실에 실재하는 것이 아닌 복잡한 자동차의 모형, 대형 선박의 스케치 또는 설계도, 자동차의 모의 실험용으로 사용되는 바람 터널에서의 자동차 축소 모형 등

-개념적 모델: 특정 시점에 맞게 기상을 예측하기 위해서 사용되는 수리적 공식이나 원형을 파괴하지 않고 조작·수정·변경시키기 위한 경제 모형 등

3)모델링 정의

-모델링: 실체를 나타내는 일과 모형화라는 의미로 해석

-데이터 모델링이란 사용자의 요구사항으로부터 데이터의 실체를 나타내는 일
-기업 업무에 대한 종합적인 이해를 바탕으로 데이터에 존재하는 업무 규칙에 대하여 참 또는 거짓을 판별할 수 있는 사실을 어떻게, 누가 접근하는지 또한 이에 대한 전산화와는 별개의 관점에서 이를 명확하게 표현하는 추상화 기법

 

4)데이터 모델이 제공하는 것

-시스템을 현재 또는 원하는 모습으로 가시화
-시스템의 구조와 행동을 명세화
-시스템을 구축하는 틀을 제공
-우리가 결정한 것을 문서화
-다양한 영역에 집중하기 위해 다른 영역의 세부 사항은 숨기는 다양한 관점을 제공
-특정 목표에 따라 다양한 상세 수준을 제공

 

*본질적 데이터 요구사항

-이름: 모든 속성은 고유하게 식별할 수 있는 이름이 주어져야함

-명세(Description): 모든 실체는 명세가 있어야 함. 모형을 검토하는 누구든지 실체를 정확히 해석할 수 있어야 함.

-유형(Type): 속성은 Key 속성 또는 Non-Key 속성중 하나로 구분되어야 함.

 

2.데이터 모델링의 중요성

-프로세스 중심의 분석/설계 방법을 통해 설계한 데이터 모델은 업무 프로세스의 변화에 따라 영향을 많이 받기 때문에 상대적으로 업무 변화에 대한 영향을 적게 받으면서 유연한 시스템을 만들기 위해 데이터 중심의 설계 필요성 대두

*파급효과(Leverage): 시스템구축이 완성되어 가는 시점에서 데이터 모델이 변경되면 많은 영향을 미침.

*복잡한 정보요구사항의 간결한 표현: 데이터 모델은 구축할 시스템의 정보 요구 사항과 한계를 가장 명확하고 간결하게 표현할 수 있는 도구

*데이터 품질: 낮은 품질의 데이터는 활용가치가 떨어짐

 

1)애플리케이션과 데이터의 통합

-데이터를 기반으로 한 통합이 효과적이며 저비용

2)개발자들의 시스템 이해

-사용자관점 데이터: 사용자가 원하는 것의 논리적 개념과 시스템이 어떻게 그것을 제공하는지의 물리적 개념이 명확

-물리적 표현 또는 사용에 관계없는 데이터 그 자체의 본질: 변화되는 물리적인 것으로부터 독립

-애플리케이션간 데이터 사용: 데이터 정의, 생명주기 정보(CRUD) 그리고 언제 어떻게 데이터가 사용되었는지를 추적할 수 있는 방법 제공(매트릭스)

3)데이터 모델링시 주의점

-중복: 중복저장 문제 해결

-비유연성: 프로세스와 분리하여 프로세스 변화에 대한 영향 감소

-비일관성: 데이터와 데이터간 상호관계에 대한 명확한 정의로 모순을 제거

 

2절 데이터 모델링 기법 이해

1.엔터티-관계 데이터 모델

가.추상화

-현실세계에 존재하는 개체 또는 객체들의 공통된 특징, 즉 추상적 특징을 파악하여 인식의 대상으로 삼는 행위

#유형화: 현실세계에 존재하는 같은 성질을 갖는 멤버들을 타입 또는 유형이라는 하나의 개념으로 정의

#집단화: 값을 유형화하면 속성이라는 타입이 됨

#일반화: 여러 엔터티 타입 간의 공통적인 특성을 파악하는 과정

 

나.타입과 인스턴스

타입(Type): 실제 발생된 사례들을 추상화한 집합

인스턴스(Instance): 현실세계에서 실제로 발생된 사례(타입의 멤버)

2.엔터티-관계 데이터 모델 구성요소

-엔터티, 관계, 속성,도메인, 식별자

가.엔터티

-조직의 업무를 수행하는데 필요로하는 사물, 사건 또는 개념을 나타내는 어떤 것.

-동일한 업무 행위나 유사한 속성을 갖는 단일 개념으로 정의한 멤버들의 집합체

나.관계

-하나 또는 두 개의 엔터티에서 인스턴스를 연관시키는 업무적인 이유. 관계도 집합

다.속성과 도메인

-속성: 엔터티에 저장되는 인스턴스들의 특성을 설명하는 항목. 값을 추상화한 타입. 동일한 특성을 갖는 값의 집합.

-도메인: 하나의 속성이 갖는 같은 종류의 모든 값들의 집합

라.식별자

-엔터티에 저장되는 특정 인스턴스 하나를 식별할 수 있는 하나 또는 하나 이상의 속성.

Not Null, 유일성, 대표성, 최소성

 

다.데이터 모델링 단계

1)개념 데이터 모델링

-주제별로 분류 가능한 업무를 분석한 후 핵심 엔터티를 추출하고, 그들 간의 관계를 정의하여 전체 데이터 모델의 골격을 생성

-개념ERD 작성

2)논리 데이터 모델링

-개념 데이터 모델링 단계에서 정의한 핵심 엔터티와 관계를 바탕으로 상세 속성을 정의하고 식별자를 확정하며 정규화를 수행

-논리데이터 모델의 상세화는 식별자 확정, 정규화, M:M 관계 해소, 참조무결성 규칙 정의 등을 하고, 이력 관리에 대한 전략을 정의하여 논리 데이터 모델에 반영

3)물리 데이터 모델링

- 논리 데이터 모델을 기반으로 목표 DBMS의 특성 및 구현 환경 등을 감안한 스키마를 일정한 기준과 규칙에 의해 도출하고 컬럼의 데이터 타입과 크기를 정의
-데이터 사용량을 분석 예측하는 과정을 통해 효율적인 데이터베이스가 될 수 있도록 인덱스의 정의 및 반정규화를 수행

 

라.모델링 기본원칙

-커뮤니케이션,모델링 상세화 원칙,논리적 표현

1)커뮤니케이션 원칙

-모든 사람들이 이해할 수 있도록 명확하게 공표됨은 물론 최종 사용자 지향적으로 분명하게 파악되는 수준으로 작성.
-논리데이터모델:  비즈니스 지향적인 최종 사용자 데이터 모델과 기술적인 상세 데이터 모델

#데이터 모델의 이해를 필요로하는 그룹

-최종사용자:개념화, 추상화, 정규화 기법을 통하여 중복없고 데이터의 정확성을 보장하는 데이터 구조의 이해 및 사용

-시스템분석가:시스템에서 사용되어질 정확한 데이터의 구조 및 데이터가 갖는 업무 규칙의 이해

-DBA: 논리 데이터 모델의 구조와 물리 스키마의 차이점을 이해하고 최종 사용자에게는 데이터의 제공, 시스템 분석가에게는 물리 스키마의 제공을 위한 데이터 구조의 이해

-타프로젝트 분석가: 관련 프로젝트가 데이터를 어떻게 정의하고 있는지를 알아냄. 인터페이스가 개발되어지고 데이터가 애플리케이션 또는 시스템 간에 공유되기 위한 데이터 구조 및 업무 규칙의 이해

2)모델링 상세화 원칙

-데이터의 상세화 정도를 제시하고 조직이 사용하는 정보 구조의 ‘최소 공통 분모’를 제시
-복잡한 구조는 요소적인 부분들로 쪼개야 하며 불필요한 구조와 중복은 제거

3)논리적 표현 원칙

-조직의 데이터에 대한 논리적 측면을 최대한 표현
-모델은 물리적 제약 조건 없이 비즈니스를 그대로 반영

 

마.좋은 데이터 모델의 요소(완중업재 안의간통)

1)완전성: 업무에서 필요로 하는 모든 데이터가 데이터 모델에 정의

2)중복배제:하나의 DB내에 동일한 사실은 반드시 한번만 기록

3)비즈니스 룰: 수많은 업무 규칙을 데이터 모델에 표현하고 이를 해당 데이터 모델을 활용 하는 모든 사용자가 그 규칙을 공유하도록 제공

4)데이터 재사용: 데이터의 통합성과 독립성에 대해서 충분히 고려. 통합모델을 구축하고, 애플리케이션에 대해 독립적으로 설계

5)안정성 및 확장성

-현재의 데이터 구조를 거의 변화하지 않고도 변화에 대응할 수 있는 데이터 구조

-아주 적은 확장을 통해 이러한 변화에 대응

-정보시스템에서의 ‘행위의 주체’가 되는 집합의 통합,‘행위의 대상’이 되는 집합의 통합, ‘행위 자체’에 대한 통합 

6)간결성: 데이터를 합리적으로 균형있고 단순하게 분류

7)의사소통: 많은 업무 규칙은 해당 정보시스템을 운용*관리하는 많은 관련자들이 설계자가 정의한 업무규칙들을 동일한 의미로 받아들이고 정보시스템을 활용

8)통합성: 조직의 전체에서 한 번만 정의되고 이를 여러 다른 영역에서 참조

 

1.2데이터 모델링 기법 이해

가.데이터 모델 목적

-데이터 모델은 데이터베이스 설계에 대한 계획 또는 청사진

-데이터 모델링 단계에서 업무를 잘못 이해했거나 관계를 잘못 정의한 것이 발견되었다면 해당하는 다이어그램과 일부 관련된 문서만 변경하면 됨.
-데이터베이스와 응용 프로그램 개발이 완료된 후 이러한 오류를 발견하여 수정하려면 이와 관련된 많은 프로그램과 SQL문이 변경되어야 할 뿐만 아니라 데이터가 새로운 구조로 옮겨져야 하는 등 이러한 변경을 반영하는 데 많은 비용과 시간이 필요하게 됨

 

나.개체-관계 모델 기법

-데이터에 대해 관리자, 사용자, 개발자들이 서로 다르게 인식하고 있는 뷰들을 하나로 통합할 수 있는 단일화된 설계안

-서로 다른 뷰를 충족시킬 수 있는 데이터 처리와 제약 조건 등의 요구 사항을 정의

다.개체-관계 모델 구성요소

-엔터티, 속성, 식별자, 관계, 카디날리티, 존재종속, 서브타입

1)엔터티

-업무 활동상 지속적인 관심을 가지고 있어야 하는 대상으로서, 그 대상들 간에 동질성을 지닌 것으로 볼 수 있는 개체 집합이나 그들이 행하는 행위의 집합

2)속성

- 엔터티에 저장되는 개체 집합의 특성을 설명하는 항목

-실체내에서 관리하고자 하는 정보들의 항목

-도메인: 속성이 가질 수 있는 값의 범위

-단일치 속성: 하나의 값만 존재

-다중치 속성: 여러개의 값이 존재

3)식별자

-엔터티의 각 개체들은 인스턴스라고 하는데, 인스턴스는 그들을 지칭하거나 식별해 주는 속성인 식별자를 가짐

-복합 식별자: 두 개 이상의 속성으로 이루어진 식별자

4)관계

-엔터티와 엔터티 간 연관성을 표현

-하나 또는 두 개의 실체를 연관시키는 업무와 관련된 중요한 사항.

-식별성, 선택성, 기수성, 비전이성

-매핑 카디날리티는 ERD에서 개체와 연결될 때 나타나는 대응되는 수로 대응수. 최대대응수, 최소대응수로 구분

5)카디날리티(기수성)

-- 한 개체가 관계를 통하여 다른 개체와 관련된 개체들의 수(관계에 참여하는 엔터티의 개수)

-1:1 : X에 속하는 한 개체는 Y에 속하는 한 개체에만 연결되며, Y에 속하는 한 개체도 X 에 속하는 한 개체에만 연결.

-1:M : X에 속하는 한 개체는 Y에 속하는 한 개체에만 연결되며, Y에 속하는 한 개체는 X에 속하는 여러 개체와 연결

-M:M: X에 속하는 한 개체는 Y에 속하는 여러 개체와 연결가능, Y에 속하는 한 개체도 X에 속하는 여러 개체와 연결가능

6)존재 종속

-한 엔터티의 존재가 다른 엔터티(들)의 존재에 영향을 받는 경우. 전체참여, 부분참여

7)서브타입

-엔터티의 하위 집합(부분집합). 속성을 상속함

예)학생(슈퍼) > 학부학생, 대학원생(서브)

-배타적: 슈퍼타입은 많아야 1개의 서브타입관 관련. (돔안에 X표시)

-포괄적: 슈퍼타입은 1개 또는 그 이상의 서브타입과 관련

-모든 슈퍼타입이 구분자를 가지고 있는 것은 아님.

-서브타입은 그것의 슈퍼타입이라 불리는 다른 개체의 특별한 경우

 

라.객체지향 모델링

-객체지향 방법론
-객체지향 분석
-객체지향 설계
-객체지향 모델링
-객체지향 프로그래밍
-객체지향 DBMS

1)객체지향 개념

-객체는 속성과 메소드로 구성. 속성은 객체 클래스의 성질. 메소드는 하나 이상 의 속성을 접근, 조작, 수정, 삭제, 생성하는 프로세스

-연관 또는 상속을 통해서 다른 객체들에 연결, 연관은 객체 간의 자연적 관계

2)객체 모형

-주제에 연관된 기본 객체 식별,  객체간의 연관을 식별

3)객체 모형 데이터

-객체-관계 다이어그램에 모형화

4)객체 모형의 메소드

-단순한 메소드는  설명부 또는 구조화된 기법 사용

-복잡한 메소드는 정교한 문서화 접근 방식이 필요
-이벤트 지향적인 프로세스는 상태 전이 모델링과 같은 동적 프로세스 모델링 기법이 필요
-정적인 프로세스는 데이터 흐름 다이어그램이나 기능 분해와 같은 기법을 사용

5)불명료한 객체 접근 방식

-객체지향 개발의 가장 단순화된 표현: 객체지향 개발을 분명하게 이해하는데 필요한 많은 객체지향 특징을 무시하는 것

-객체지향 모델링의 미성숙: 객체가 어떻게 표현되고 기호가 어떻게 사용되어야 하는가 등의 정의는 아직까지 초기단계.

 

객체지향 모델링과 논리 데이터 모델링간의 관계

객체-엔터티, 속성-속성, 연결-관계, 객체클래스-엔터티유형

 

6)객체지향 모델링 장점

-재사용 코드, 모든 비즈니스 규칙 표현, 프로세스와 데이터 모델링을 함께 운영

-객체가 다른 객체와 연결되는 방법은 연관 또는 상속

3절 데이터 모델링 표기법 이해

가.바커 표기법

1)엔터티

-엔터티는 네 부분의 모서리가 둥근 형태인 소프트-박스(Soft-box)로 표현. 실체명은 박스안에 작성.

2)속성

-해당 속성에 어떤 값을 반드시 저장해야 하는 경우에는 * (Mandatory)를 표시하며 해당 속성에 어떤 값이 존재할 수도 있고 존재하지 않을 수도 있는 경우에는 o (Optional)를 표시

3)관계

-두 개의 엔터티간에 CONDITIONAL을 표기한 후 해당 엔터티의 가까운 위치에 관계 명칭을 표기하고 관계는 실세계의 해당 엔터티에서 발생하는 동사적 단어들을 표기

 

#엔터티간의 관계

1:1 관계 : A 엔터티에 존재하는 데이터 1개와 관계되는 B 엔터티에 존재하는 데이터의 개수도 1개인 엔터티간의 관계

1:M 관계 : A 엔터티에 존재하는 데이터 1개와 관계되는 B 엔터티에 존재하는 데이터의 개수가 여러 개인 엔터티 간의 관계

M:M 관계 : A 엔터티에 존재하는 데이터 1개와 관계되는 B 엔터티에 존재하는 데이터의 개수가 여러 개이며, B 엔터티에 존재한 데이터 1개와 관계되는 A 엔터티에 존재하는 데이터의 개수도 여러 개인 엔터티 간의 관계

 

2)관계 선택성 표기법

#필수관계: 엔터티 A,B관계에서 B에 인스턴스를 입력할때 A에 하나의 인스턴스를 입력해야 하는 경우, A의 선택성은 필수

#선택관계: 엔터티 A,B관계에서 B에 인스턴스를 입력할때 A에 하나의 인스턴스를 입력할 필요가 없는 경우, A의 선택성은 선택

-선택성(Optional): 페어링의 존재여부. 하나 또는 두개의 엔터티간에 관계가 설정될때, 모든 인스턴스간에 페어링이 존재해야 하는지(Mandatory), 아니면 모든 인스턴스에 대하여 페어링이 존재할 필요가 없는지(Optional) 표시

-선택성 결정방법

->필수: 다른 엔터티에 어떤 행을 입력하기 전에 상대 엔터티에 적어도 한 건의 행이 반드시 있어야 하는 경우

->선택: 다른 엔터티에 어떤 행을 입력하기 전에 상대 엔터티에 어떤 행이 존재할 필요가 없는 경우

 

3)관계 식별성 표기법

#식별관계: 부모 엔터티의 식별자가 자식 엔터티의 식별자의 일부분이 되는 관계(주문-주문상품)

자식엔터티는 부모엔터티에 대해 존재종속이며, 식별종속임.

 

#비식별관계: 부모 엔터티의 식별자가 자식 엔터티의 일반 속성으로 표현되는 관계(부서-사원)

자식엔터티는 부모 엔터티에 대해 존재 종족이지만 식별종속은 아님

 

#엔터티와 엔터티간 상관 관계의조건

필수 조건: 필수 사항은 실선으로 표시하고 상대 엔터티에 대해 해당 엔터티에 조건을 만족하는 엔터티가 반드시 존재할 경우에 표시

선택 조건: 선택 사항은 점선으로 표시하고 상대 엔터티에 대해 해당 엔터티에 조건을 만족하는 엔터티가 존재할 수도, 존재하지 않을 수도, 있을 경우 표시

4)식별자

-하나의 엔터티에 구성되어 있는 여러 개의 속성 중에 엔터티를 대표할 수 있는 속성

-엔터티에 저장되는 특정 인스턴스 하나를 식별할 수 있는 하나 또는 하나 이상의 속성

#식별자의 유형

*본질 식별자: 집합의 본질을 명확하게 설명할 수 있는 의미상의 주어

*후보 식별자: 각 인스턴스를 유일하게 식별할 수 있는 속성 또는 속성들의 조합

*대체(보조) 식별자: 원래의 식별자를 대신할 수 있는 또 다른 속성들이나 릴레이션십

*인조 식별자: 식별자 확정시 기존의 본질 식별자를 그대로 실질 식별자로 인정할 수 없는 여러 가지 상황이 발생했을 때, 전부 혹은 일부를 임의의 값을 가진 속성들로 대체하여 새롭게 구성한 식별자

*실질 식별자: 인스턴스를 식별하기 위해 공식적으로 부여된 식별자. 본질, 인조

-식별자 앞에는 # 기호를 표시하고 여러개 # 기호를 반복적으로 표시

5)서브타입

-슈퍼타입 안에 서브타입을 상자로 나타냄

6)관계의 표현 비교

 

나.IE 표기법(정보공학)

1)엔터티

-사용자가 추적하고자 하는 어떤 사물. 사각박스로 표현. 엔터티명은 박스 밖에 기재.

2)속성: 엔터티의 특징을 기술

3)관계

필수는 세로선(|), 선택은(o)

 

4)식별자

- 수평선이 식별자 밑에 그려짐

5)서브타입

배타적이라면 슈퍼타입은 많아야 1개의 서브타입과 관련(동시에 1개, 사원=정규 or 계약)
포괄적이라면 슈퍼타입은 1개 또는 그 이상의 서브타입과 관련(동시에 1개이상 가능, 연예인=가수&배우)

 

4절 관계형 모델 이론

1.릴레이션 개념

-관계형 모델에서 테이블을 의미. 테이블의 열은 애트리뷰트, 행은 튜플

#릴레이션 정의: 집합x와 집합y 사이에 관계 R을 만족하는 모든 순서쌍(곱). 수학적 정의로 보면 주어진 도메인들의 카티션 프로덕트의 부분집합

 

#속성과 도메인의 개념

-애트리뷰트(속성) 값은 업무에서 의미를 갖는 더 이상 분해할 필요가 없는 값, 즉, 원자값

-원자값: 업무를 수행하는데 의미 있는 데이터의 최소 단위

-도메인: 하나의 애트리뷰트(속성)가 갖는 같은 타입(유형)의 모든 원자 값들의 집합

애트리뷰트와 도메인은 프로그래밍 언어에서 변수와 데이터 타입에 비유

 

2.관계형 모델 이론

-데이터 구조: 사용자가 인식하는 데이터의 구성

-데이터 조작: 사용자가 관계형 데이터 구조에 행하는일련의 연산(처리)형태

-데이터 무결성: 사용자가 일련의 관계형 연산을 수행할때 테이블의 데이터 값이 어떻게 되야 하는지를 통제하는 일련의 업무 규칙

 

가.데이터 구조

#릴레이션의 6가지 특성

1)각 열은 하나의 값. 애트리뷰트의 원자성

2)각 열의 값은 동일한 종류. 도메인 무결성

3)각 행은 유일. 튜플의 유일성> 엔터티 무결성

4)열의 순서는 무의미. 애트리뷰트의 무순서성

5)행의 순서는 무의미. 튜플의 무순서성

6)각 열은 유일한 이름을 갖는다. 

 

나.데이터 조작

-집합(SET)처리

-관계연산자: 조회

*Select(or Restrict): 열에 의거한 행의 부분집합

-- Example: Select all employees from the "Employee" table with a salary greater than 50000

SELECT * FROM Employee WHERE Salary > 50000;

 

*Project(π): 열의 부분집합(subset)

-- Example: Project only the "EmployeeID" and "Name" columns from the "Employee" table

SELECT EmployeeID, Name FROM Employee;

 

*Product(×): 두 관계 테이블간 행의 조합을 묶음

-- Example: Find the Cartesian product of the "Employee" and "Department" tables

SELECT * FROM Employee, Department;

 

*Join(⨝): 열의 기준에 의거하여 각 행을 수평적으로 묶음

-- Example: Inner join "Employee" and "Department" tables on the "DepartmentID" column

SELECT * FROM Employee INNER JOIN Department ON Employee.DepartmentID = Department.DepartmentID;

 

*Union(∪): 중복없이 각 행을 수직적으로 묶음(합집합)

-- Example: Combine the names of employees from "Dept_A" and "Dept_B" without duplicates

SELECT Name FROM Employee WHERE Department = 'Dept_A'

UNION

SELECT Name FROM Employee WHERE Department = 'Dept_B';

 

*Intersection(∩): 관계 테이블간의 공통된 행(교집합), 테이블 구조는 동일

-- Example: Find employees who are in both "Dept_A" and "Dept_B"

SELECT Name FROM Employee WHERE Department = 'Dept_A'

INTERSECT

SELECT Name FROM Employee WHERE Department = 'Dept_B';

 

*Difference(- 또는 제외): 하나의 관계 테이블에만 있는 행(차집합), intersection의 반대

-- Example: Find employees in "Dept_A" but not in "Dept_B"

SELECT Name FROM Employee WHERE Department = 'Dept_A'

EXCEPT

SELECT Name FROM Employee WHERE Department = 'Dept_B';

 

*Division(¼): 다른 관계 테이블의 모든 행에 대응하는 열을 제외한 열. (R에서 S의 레코드를 다가진 레코드)

-- Example: Find employees who have worked on all projects

SELECT EmployeeID FROM WorksOn

WHERE ProjectID IN (SELECT ProjectID FROM Project);

 

-처리연산자: 관계 테이블의 내용에 변화

*Insert: 행의 삽입

*Update: 행의 수정

*Delete: 행의 삭제

 

다.데이터 무결성

-업무규칙에 따라 데이터의 일관성과 정확성을 유지하는 특성

-사용자가 일련의 관계형 처리(입력, 수정, 삭제, 조회)를 수행할 때 관계형 엔터티의 데이터값이 어떻게 작용해야 하는지 통제하는 일련의 업무규칙

 

1)엔터티(실체) 무결성

-두 개의 똑같은 튜플은 한 릴레이션에 포함불가

*유일식별자: 엔터티 내 특정 인스턴스를 다른 것과 구별할 수 있도록 식별해주는 하나 이상의 속성과 관계의 집합

-식별자를 구성하는 각 속성이 NOT NULL

-엔터티내 특정 인스턴스의 유일성 보장

-최소한의 속성 집합

 

2)참조무결성

-데이터가 하나 또는 두 개의 관계있는 엔터티에 입력, 수정, 삭제될때 데이터가 어떻게 반응해야 하는가에 대한 업무 규칙

*엔터티의 주키와 마찬가지로 외래키도 데이터 무결성에 관한 규칙을 내포

*참조무결성규칙: 엔터티의 모든 외래키 값은 관계 있는 엔터티에 주 키 값으로 존재해야함

*DB설계관점에서 선택하지 말고, 현업의 업무규칙에 따라 적절한 규칙을 선택.

#입력규칙: 자식 엔터티의 행이 입력될때

#삭제규칙: 부모 엔터티의 행을 삭제할때 (또는 행의 주키를 수정할때)

 

3)도메인 무결성(길이, 허용값, 범위)

-엔터티 내의 모든 열에 관한 무결성 규칙으로 데이터 타입, 길이, 허용값, 기본값, 유일성, 널 여부 등에 관한 업무규칙

-도메인: 속성이 가질 수 있는 값의 전체 집합

-같은 도메인의 값들끼리만 비교 가능

-속성이 취할 수 있는 값의 제한

 

4)연쇄작용 또는 업무규칙

-연쇄작용: 입력,수정,삭제 또는 조회 등의 작업이 동일 엔터티 혹은 다른 엔터티의 속성에 영향을 미치는 업무 규칙

-업무규칙은 조직이 데이터를 인식하고 사용하는 방법에 기초 

 

2.개념 데이터 모델링

2.1개념 데이터 모델링 이해

데이터 분류/관리 체계 필요

-중복배제, 확장성, 효용성

 

가.개념 데이터 모델 정의

-핵심 엔터티들로 구성된 모델

-핵심엔터티: 행위의 주체나 목적물이 되는 개체 집합에 해당하는 엔터티

 

나.개념데이터 모델 의의

-개념적 모델은 개괄적 모델을 좀더 상세화된 형태로 진화시키거나 중요 엔터티만 선정하여 모델링

-사용자가 요구하는 데이터의 범위 및 구조 확인을 돕고, 개발범위 결정을 지원

-선진사례 적용 용이

 

다.데이터아키텍처 프레임워크 상에서 개념 데이터 모델

-개념 데이터 모델은 개괄 데이터 모델과 논리 데이터 모델 사이에 존재하는 모델

-개괄데이터 모델은 데이터 아키텍처상에서 최상위 수준의 관점을 정의

-개념데이터모델링은 분석초기에 수행되어 본질적으로 기술과 무관한 사양들의 집합을 형상화하여 데이터 요구사항을 정의하고 비즈니스 이해관계자들과 초기 요구사항을 논의하는데 사용

-개념데이터모델에서부터 출발하여 다른 데이터요소와 그 상호관계가 무언인지를 상위레벨에서 이해하는 것이 바람직

개념모델링 구성요소

주제영역>핵심엔터티>관계>핵심속성>식별자

2.2주제 영역 정의

가.주제영역 개념

-기업이 사용하는 데이터의 최상위 집합
예)제조의 경우, 인사,생산,자재,판매

-시스템의 대상이 되는 업무를 명백하게 구분이 가능한 단위업무로 분리하는 개념

-주제영역 내부에 존재하게될 개체들이 높은 결합성을 유지하게 해야함.

-프로세스 모델링의 기능과 매핑

 

*주제영역의 역할

-전사 업무를 위한 전체 데이터 구성에 대한 청사진

-전사 표준 주제 영역을 기반으로 데이터 오너쉽을 부여하고, 해당 영역 데이터에 대한 표준 및 활용/품질에 대한 권리를 수행하는 기준단위 영역

-전사 통합/단위 개념 모델 수립시 참조정보로 활용

 

나.주제영역 분류 원칙 및 기준

1)주제영역 분류 원칙

*데이터 중복 최소화

*데이터 확장성 보장

*데이터 관련성 및 편의성 확보: 타자원과의 인접성 고려, 고객 편의를 고려

2)주제영역 분류 기준

#데이터 관점의 분류

*업무를 발생시키는 주체, 대상 및 행위 등 데이터 관점에서 데이터를 생성시키고 사용하는 유형에 근거하여 분류

*장기적이고 전사적인 관점에서 데이터 유사성을 고려

*시스템이나 애플리케이션이 다르더라도 동일한 유형의 데이터를 유사한 방식으로 활용한다면 이를 동일한 영역으로 분류

 

#업무 요건 추가에 대한 유연성 보장

*업무 요건의 변경이나 추가 시 유연성을 보장할 수 있도록 전사 분류 체계를 설정

*업무 요건 변경에 대해서 데이터 구조의 변경을 최소화하려면 동일한 유형의 데이터를 본질이 희석되지 않는 한도내에서 최대한 집합으로 통합

*새로운 영역이 필요한 상황이 발생한다면 전사적인 협의를 통하여 적절한 계층의 분류 구조를 조정

 

#주제영역 간 균형 유지

*데이터 분류는 일부분에 국한된 것이 아니고 전체적인 균형을 유지하는 것이 중요

*특정 부분을 너무 상세하게 분류하거나, 분류 방식이 타 영역과 다른 방식으로 되어 있으면 전체적인 혼란

*데이터 분류에 대한 추가나 변경이 발생할 경우 해당 부문만을 고려하여 수행하기보다는 타 영역의 분류 체계와의 형평성 및 균형을 고려하여 분류 구조를 관리

 

3)주제영역 명명

-실 업무에서 보편적으로 사용하는 업무 용어 예)인사분야, 판매분야 

-유일한 단수형 명사

-데이터의 그룹을 의미하는 이름 사용 업무활동을 의미하는 이름 배제

예)재무관리(기능), 재무시스템>재무분야(데이터)

4)주제영역 정의 절차

5)주제영역 분류방법

#1차분류: 주요 데이터 집합의 유형 정의

*기존의 시스템별로 제공되는 데이터의 성격 및 특성을 고려하여 영역을 분류

*업무의 변화에 민감하지 않도록 정의

*분류 예시
- 데이터를 발생시키는 주체로서의 분류 >>관계자, 상품/서비스, 자산, 채널 등
- 데이터를 발생시키는 주체 간의 상호작용으로 발생하는 대상으로서의 분류 

>> 계약, 리스크, 상품, 조건
- 공통 및 관리 성격의 상위 개념으로서의 분류 >>경영 관리(정보, 방침, 지원 등)

 

#2차분류: Biz 활동에 필요한 데이터 분류

*Biz 활동에 필요한 분석 주제와 현황 등의 영역으로 분류

*기본(정보), 상세(정보), 관계(정보) 등과 같은 데이터의 기능적 구성 관점에서 접근하여 1차 분류를 세분화

*업무 변화 수용의 융통성을 반영하여 정의

*분류예시
- 관계자 : 관계자 기본, 관계자 상세, 관계자 관계, 관계자 분류 등

 

#3차분류: 2차 영역의 세부 주제 영역 분류

*Biz 활동에 필요한 분석 주제와 현황 등의 영역으로 분류

*사용자에게 제공되는 실제 데이터로서의 관점에 근거하여 정의

*업무적인 관점에서 분류

*분류예시
- 관계자(기본) : 고객, 법인, 조직, 직원 등
- 계약(기본) : 수신계약, 예금계약, 신탁계약 등

#데이터의 그룹을 의미하는 이름을 부여

 

다.주제영역 활용

1)목적

-데이터의 계층적 구조를 파악

-점진적인 상세화로 상위 수준에서 모델의 안정성 유지

-업무 기능과 병행하여 분석하는 경우에 분석의 최상위 단위 역할을 하여 품질 확보에 기여

-주제 영역 계층과 업무 기능 계층 간의 대응 관계를 확인

-기업의 전사 업무를 위한 전체 데이터 구성에 대한 청사진을 제공

-데이터 구성 및 통합에 대한 방향 제시

-효율적 데이터 관리를 위한 기준을 제공

2)장점

-데이터 및 업무 활동 모델의 품질 보증

-프로젝트 관리 용이

-모델 개발 조정 용이

-레파지토리 관리 용이

-상세 사항의 전개 혹은 축약 가능

-요구사항 검증 기준

 

라.주제영역 도출

1)업무에서 사용하는 데이터의 명사형 도출

-정보수집소스에서 명사형 찾기

2)업무 기능의 이름으로부터 도출

-데이터와 업무 활동의 상호 보완 관계

3)하향식 접근방법

-주제 영역에서 출발하여 엔터티 타입으로 전개

4)상향식 접근방법

-엔터티 타입을 그룹핑하여 주제 영역 도출

5)분석 단계에서의 도출

아키텍처 모델을 정련하는 과정에서 도출

데이터 모델을 상세화하는 과정에서 도출

 

마.주제 영역 정의 내용

1)주제 영역 목록

레벨 : 주제 영역의 계층 수준(1차, 2차, ... 단위)

주제 영역명

설명(단위 주제 영역의 경우)

대표 엔터티 : 해당 주제 영역 내에서 대표적인 엔터티를 기술

 

2.3후보 엔터티 선정

가.개념

-엔터티 정의: 엔터티의 개념 정의에 적합한 대상을 찾아 후보 검증을 거쳐 엔터티로서 확정하고, 데이터 집합으로서 해당 엔터티의 성격을 규명하는 것.

-엔터티 후보를 찾아서 검증 및 판명

절차: 엔터티 후보 선정>엔터티 형태별 분류>엔터티 자격 검증>엔터티 형태 결정>본질식별자 확정>엔터티 정의서 작성

 

나.엔터티 후보 수집

#기존 시스템 도큐먼트

-데이터 구조 및 프로세스 명세들이 나타나 있는 설계 자료에서부터 사용자를 위한 지침서

#현업 장표/보고서

업무의 효과적인 처리를 위하여 많은 장표, 처리된 업무의 집계·분석·관리를 위해서 많은 종류의 보고서

#현업 인터뷰

-현업 담당자들과 같이 시작

#관련 전문 서적

-현실에 적용하기 위해 고민하고 있는 문제를 해결하는 데 필요한 아이디어나 힌트

#데이터 흐름도

-데이터 저장소와 데이터 사전에 있는 정보를 이용

#타시스템 자료

-타 시스템이 가지고 있는 엔터티를 면밀히 조사해 차이점 분석

#현장 조사

-현장을 답사

 

다.엔터티 후보 선정시 유의사항

-엔터티 가능성이 있다고 예상되면 일단 검토 대상에 올려라

-너무 깊게 들어가지 마라

-동의어처럼 보이더라도 함부로 버리지 마라

-개념이 모호한 대상은 일차로 그 개념을 상식화하여 이해

-프로세스에 너무 연연해 하지마라

-예외 경우에 너무 집착하지마라

-단어 하나하나에 집중해서 판단

-후로를 선정했으면 핵심적인 특징 파악

-사용자에게 의존말고 자신의 이해를 바탕

-구현할 시스템의 업의 본질 염두

 

라.엔터티 후보 식별

1)엔터티 후보의 개념 정립

-후보 검토 대상의 최초 상태인 단어의 구체적인 집합을 정의

2)관리 대상 판정

-단어에 대해 관리하고자하는 대상이 맞는지 확인

3)집합 여부 확인

-검토 대상이 집합이 되는지 확인(가로와 세로가 각각 2개이상인가)

-가로는 속성, 세로는 개체(인스턴스:구체화한 대상)

 

마.수집된 엔터티 분류

-개념 데이터 모델링에서는 데이터 모델의 골격을 잡는 일부터 철저하게 수행. 

-엔터티 후보를 분류하는 작업부터 수행

-개체집합, 행위집합

 

1)우선 적용 대상 분류

-모델링의 골격에 해당하는 주요 엔터티를 먼저 도출하여 이를 명확히 정의함으로써 모델링의 기초를 단단히 함

#키 엔터티

*자신의 부모를 가지지 않는 엔터티

예)사원, 부서, 고 객, 상품, 자재

#메인 엔터티

-키 엔터티를 제외한 다른 모든 엔터티는 부모 엔터티를 가지고 있어야만 태어남.

-업무의 중심에 해당하는 엔터티를 메인 엔터티라 정의하고, 나머지를 액션 엔터티로 정의
메인 엔터티 예) 주문, 예산편성, 매출

#액션 엔터티

-키엔터티와 메인엔터티가 아닌 엔터티. 수행된 업무를 포함

예)상태 이력, 차량 수리 내역, 상세 주문 내역

2)우선적용 대상 분류 사례

3)데이터 영역별 분류

-데이터 영역을 정의하는 방법은 접근 방법별로 볼 때 크게 하향식과 상향식 접근 방법

예)모델(사람)-엔터티후보(사원,가입자,회원,고객,협력사 직원..)

 

#데이터 성격에 따른 분류

-엔터티 후보들간 미묘한 차이 분석

-엔터티 통합 여부 판단

-엔터티 정의 견고하게

 

다.코드성 키 엔터티 선정기준

-개념모델링 단계에서는 도출하지 않아도 무관

 

#다음 4가지 기준에 해당하면 미리 도출

이 엔터티가 자식 엔터티를 가지는가?

이 엔터티가 자신만의 다양한 속성을 가질 것인가?

이 엔터티가 여러 엔터티에 관계를 가질 것인가?

이 엔터티가 다양한 종류의 관계를 가질 것인가?

1)자식 엔터티 유무 확인

2)속성 존재 여부 확인

3)관계 존재 여부 확인

 

2.4핵심 엔터티 정의

가.개념

1)엔터티란

-업무 활동상 지속적인 관심을 가지고 있어야 하는 대상으로서 그 대상에 대한 데이터를 저장할 수 있고 대상들 간의 동질성을 지닌 개체 또는 행위의 집합

-다른 것과 구별되어 식별될 수 있는 사물

-구별가능한 사람, 장소, 물건, 행위 또는 개념 등에 대하여 정보가 유지되어야 하는 것.

 

2)엔터티 정의의 요건

-우리가 관리하고자 하는 것인지를 확인

-가로와 세로를 가진 면적(집합)인지를 확인

-대상 개체들 간의 동질성이 있는지를 확인

-다른 개체와 확연히 구분되는 독립성을 가지는지를 확인

-순수한 개체이거나 개체가 행위를 한 행위 집합인지를 확인

 

나.의미상 주어 정의

누가,언제,무엇을,어디서에 해당

-본질 식별자

1)본질 식별자 정의의 의의

-집합의 의미를 명확하게 함
-내용(의미)상의 진정한 식별자

-누가+무엇을+언제

-직접종속이면서 절대종속

-특별한 하자가 없다면 이것이 곧 실질식별자

 

2)본질 식별자 정의 예

-신용카드 엔터티의 본질 식별자인 고객 번호와 상품 코드는 부모에게서 상속받은 관계 속성이며, 이 부모들은 바로 키 엔터티

-신용카드 카드번호는 인조식별자, 실질식별자에 해당.

-고객번호, 카드상품코드, 카드발급일시 등이 본질식별자.

-본질식별자를 이루는 속성이 없을때 자신이 절대로 태어날 수 없는 경우에만 해당

-인조식별자는 본질식별자가 될 수 있음

 

#실질식별자

-최종 확정된 공식적인 식별자

-본질식별자의 전부나 일부를 인조속성으로 치환하여 실질식별자를 생성할 수 있음

-관계를 통해 상속되는 식별자

 

다.코드성 키 엔터티

 

라.집합 순수성

1)집합 순수성 의미

-엔터티는 반드시 순수한 본질 집합이 되어야 함. 개체집합, 행위집합

-

2)집합 순수성 예

-개체집합은 고객, 상품

-행위집합은 입금, 계약

-납입자는 고객이라는 본질집합과 납입이 결합되어 만들어진 관계 집합

 

3)집합 순수성 적용 예외 사항

#관계의 엔터티화

-관계가 M:M이 되면 릴레이션 엔터티로 바뀜
예)피보험자=피보험+자, 보험계약 이라는 관계 엔터티 도출

#일부 집합 정의

-전체 논리적인 집합 중에서 관리하고자 하는 일부의 집합만을 엔터티로 정의
예)금융기관=금융+기관, 금융은 기관이라는 큰집합의 부분집합

#배타적 관계 대체

-엔터티가 여러 엔터티와 동일한 내용의 관계를 갖는 배타적 관계를 가질 때 배타적 관계에 있는 것들만 모아서 별도의 엔터티를 구성
예)배송처=배송+처, 처에는 여러 집합이 존재하고 앞으로 늘어날 가능성이 높음.

 

마.집합 동질성

1)집합 동질성 의미

-동질성: 대상들 간에 하나의 동등한 본성 또는 본체나 본질, 성질 등을 공유하고 있다는 의미

-집합에 들어갈 개체들의 동일한 성질을 어디까지로 한정할 것인가를 결정하는 것

2)집합 동질성 부여의 예

 

바.엔터티 명칭

1)적절한 엔터티 명칭

-엔터티를 함축시킨 의미를 포함. 의사소통시 의미를 명확히 전달

 

사.서브타입

1)서브타입 지정 의의

-엔터티내에 들어가는 부분집합(서브타입)의 종류를 명시

예)고객 : 개인,법인

2)서브타입 지정시 고려사항

#교집합 허용 불가

-남자와 여자의 교집합은 불가

#서브타입의 합이 전체집합

-서브타입을 모두 결합하면 반드시 전체 집합

#서브타입 표현의 기준

-물리모델에서 테이블 분할의 기준 역할

*개별 속성을 가지는 경우

*개별 관계를 가지는 경우

*가독성을 증진시키고자 하는 경우

#하나의 엔터티에 서브타입 유형은 하나만 존재해야 함(최종 모델)

>바커표기법에서는 멀티 서브타입 표현이 가능

 

#적용기준

-분류속성에 따라 엔터티의 정보가 차별화되는 경우

-서브타입으로 분할함으로써 관계가 필수관계로 변하는 경우

 

3)서브타입 도출

#분류 속성

-분류 속성에 따라 엔터티의 정보가 차별화되는 경우

#다수의 선택적 속성

#선택적 관계가 존재하는 경우

*서브타입을 분할하여 관계가 필수적으로 변하는지 확인

 

#도출 절차

*분류 속성을 확인(엔터티의 발생이 차별화되는 경우).

*분류 속성값에 의해 분류되는 서브타입을 파악

*분류 속성에 따라 필수적/선택적 분할을 정의

*서브타입별 속성을 할당

*슈퍼타입의 관계를 해당 서브타입에 정의

 

#서브타입의 활용

*엔터티의 정의를 좀더 구체화하여 데이터 모델에 대한 가독성을 향상

*속성의 선택성 제거

*관계의 선택성 제거

 

아.엔터티 통합과 분할

1)엔터티 독립성

-우리가 새롭게 정의하고자 하는 엔터티가 앞서 정의해 둔 어떤 엔터티에도 포함되지 않는 독립적인 집합인지를 확인

 

2)엔터티 분할/통합

-확장 교차된 부분을 어느 한쪽 집합에서만 가지도록 해, 둘 사이를 완전 분리하는 방법

-교차되는 부분이 있더라도 두 집합을 별개의 집합으로 간주하고 필요시 이들 간에 관계를 맺어 주는 방법

-엔터티 통합은 유연성 향상

-하위엔터티를 위해 최대한 통합을 유도

-무리한 통합은 집합의 독립성 저해

-통합을 통해 배타적관계의 가능성 감소

-키엔터티는 가능한 통합

 

#엔터티 분할

-한 테이블의 데이터가 많고, 특정범위만 주로 엑세스하면 수평분할

-수평분할시 각 테이블을 서로 다른 디스크에 위치하면  물리적디스크의 효용성 극대화

-테이블 컬럼수가 많고 조회위주컬럼과 갱신위주 컬럼이 구별되면 수직분할

-특정컬럼의 크기가 큰경우 수직분할

 

자.엔터티 정의 기술과 엔터티 정의서 작성

-데이터 집합의 개념 및 성격
-집합 구성상의 특징
-데이터 생성, 변경, 삭제 시의 특이사항 또는 데이터 오너쉽 등 기타 특이사항 등

 

2.엔터티 분류

가.일반적인 엔터티 분류

1)유형 엔터티: 물리적으로 존재하는 대상(고객, 상품)

2)활동 엔터티: 어떤 사건에 관한 정보(주문, 계약)

3)개념 엔터티:관리할 정보가 있는 무형의 개념(성적)

 

나.모델관점의 엔터티 분류

#독립 엔터티: 인스턴스를 식별하는데 있어서 어떤 다른 인스턴스에 의존하지 않는 엔터티 (고객, 제품, 사원)

#종속 엔터티: 인스턴스를 식별하는데 있어서 하나 또는 하나 이상의 다른 인스턴스에 의존하는 엔터티 (사원가족, 주문상품)

-특성 엔터티: 하나의 인스턴스에 여러 번 발생하는 속성의 그룹, 다른 인스턴스에 의하여 직접적으로 인식되지는 않는 엔터티(사원경력)

-연관 엔터티: 두개 이상의 연관된 다른 엔터티로부터 식별자를 상속받는 엔터티(다대다 관계 해소시 생성됨)

-서브타입 엔터티: 다른 부분집합과 구별되는 공통속성이나 관계를 공유하는 엔터티의 부분집합

 

다.발생 시점 엔터티 분류

1)키 엔터티: 자신의 부모를 가지지 않는 엔터티

-사원,부서,고객,상품,자재..

2)메인 엔터티: 키 엔터티를 제외한 엔터티 중에서 업무의 중심에 해당하는 엔터티

-주문, 매출, 사고, 청구

3)액션 엔터티: 키와 메인 엔터티가 아닌 것. 수행된 업무를 담고 있으며, 반드시 부모를 갖는다.

-상태 이력, 상세 주문내역

 

3.엔터티 도출

-도출방법: 기업의 전략*목표 분석, 사용자 인터뷰, 현시스템 분석, 정보요구분석, 문서*보고서 분석

가.현행 DB로부터 엔터티 도출

#현행DB분석이유

 -ASIS DB가 조직의 정보요구사항을 빠짐없이 정확하게 지원하는지 확인

-ASIS DB의 구조적인 문제점 및 해결방안 도출

-목표 정보요구사항을 지원하기 위해 논리 데이터모델을 어떻게 생성할지 결정

-데이터 이행이 필요한 경우, 원천데이터 파악

 

나. 정보요구 분석

-정보요구: 부서가 주어진 목적을 달성하고 기능을 수행하기 위해서 필요로 하는 정보

 

다. 업무에서 사용하는 문서로부터 도출

-현업에서 사용하고 있는 실 데이터 값이 보이는 문서

 

라.사용자 인터뷰로부터 도출

-현업 업무 전문가와 인터뷰를 통해 업무규칙을 명확히 이해하는 것이 좋지만 현실은 그렇지 못함

 

마.아키텍처 모델로부터 도출

-ISP, EAP 의 전사 개념 데이터 모델

 

바.업무를 수행하는 프로세스로부터 도출

-프로세스 중심 데이터 모델링로 고려

 

사.엔터티 분류 기법을 활용하여 도출

-독립>종속.

 

4.엔터티 검증

가.조직의 업무를 수행하는데 필요한 의미있는 정보를 나타내야 함

나.특정 사례가 아닌 유사한 사물들을 대표하는 집합체 (구매부서 > 부서)

다.인스턴스가 포함할 내부 연관성 있는 속성에 의해 결정된 단일개념을 대표해야함.

라.엔터티내 인스턴스의 출현을 구별할 수 있는 능력을 제공해야 함.엔터티 무결성

마.정규화 규칙을 만족해야함.

 

5.엔터티 정의사항

가.엔터티명

-명명규칙 준수한 고유한 이름

1)엔터티명은 현실 세계의 인스턴스 및 정보를 대표

2)엔터티명 자체로 의미를 표현

3)물리적인 사항을 개념화한 논리적 사물을 반영

4)최소한의 어휘를 사용하여 의미를 전달

나.엔터티설명

다.엔터티분류

라.현재 발생 건수

마.발생 건수 변화

바.권한

사.식별자 속성

자.식별자 이외 속성

 

6.엔터티 일반화

가.일반화 정의

-현실세계의 사물, 사건을 단순화하여 표현하는 추상화 기법 중 하나로 엔터티의 부분집합 정의

#슈퍼타입: 일반화 계층의 가장 상위에 있는 엔터티

#서브타입: 다른 부분집합과 구별되며, 공통의 속성이나 관계를 공유하는 인스턴스들의 부분집합

 

나.일반화 특성

-슈퍼타입은 두 개이상의 독립적인 서브타입으로 구성

-슈퍼타입은 각 서브타입들의 공통적인 속성과 관계를 가짐

-서브타입은 자신의 속성이나 독립적인인 관계를 가짐

-자신의 속성이나 관계를 가지지 않는 서브타입도 존재할 수 있으나 이런 경우는 일반적인 속성으로 처리하는 것이 좋음

- 슈퍼타입과 서브타입은 결코 부모-자식 관계가 아니다

- 슈퍼타입의 인스턴스는 서브타입 중 단 하나와 반드시 연결되어야 한다．

- 서브타입은 서로 중첩되지 않아야 하며(교차 불가) 그 전쳬집합은 슈퍼타입과 1:1이다. 전체집합에 확신이 없다면 '기타' 구분을 생성

 

#배타적: 슈퍼타입은 많아야 1개의 서브타입관 관련. 돔안에 X표시. (사원=정규 또는 계약)

#포함적(포괄적):슈퍼타입은 1개 또는 그 이상의 서브타입과 관련(연예인=가수&배우)

다.일반화 시점

1)인스턴스가 공통적인 속성 집합을 가질때(고객=개인or법인)

2)인스턴스가 공통적인 관계 집합을 가질때

 

라.일반화 장단점

 

관계

2.5관계 정의

가.관계란

-두 엔터티 간에 존재하는 업무적 연관성을 표현하는 것

:관계 표현을 통해 업무 규칙을 정의

:직접적인 관계

 

나.관계 이해

1)관계도 집합. 관계도 속성

-두 엔터티 사이에 그 목적과 내용이 다른 여러 개의 관계가 동시에 존재 가능

- 릴레이션 엔터티, 교차 엔터티, 제휴 엔터티

2)직접 관계를 관계라고 함

-직접 종속인 것만 관계로 봄

3)두 엔터티 간에는 하나 이상의 관계 존재 가능

4)외래키로 정의

-관계는 외래키로 구현되어 참조무결성으로 데이터 정합성을 유지

5)관계의 관점

항상 두 엔터티 간에 존재

항상 두개의 관점을 가짐

데이터의 양방향 업무 규칙을 표현

관계를 통하여 정보로서의 활용가치 상승

 

다.관계 표현

식별성, 선택성, 기수성

1)관계 형태

#하나 이상(many)

-하나 이상인 것이 적어도 한가지는 존재

까마귀발가락 모양

#단 하나(only one)

-단 하나임, 수평선

2)선택사양

-직선은 반드시 존재해야 함을 의미(필수)

-점선은 존재하지 않을 수도 있음(옵션)

#일반적인 형태

*주로 참조하는 엔터티(M쪽)는 참조되는 엔터티(1쪽)가 반드시 존재해야 하는 경우
*반대로 1쪽 엔터티는 M쪽 엔터티와 반드시 관계를 맺지 않아도 되는 경우

#바람직한 형태

-M쪽(자식) 관계의 선택사양을 직선관계로 만들려고 노력

3)관계명

#두 개의 관계 멤버십에 각각 부여

#현업에서 사용하는 간결한 동사형으로 표현

-두 엔터티 타입 간의 업무적 연관성을 나타내는 이름 부여
-현재 시제를 사용
-다른 관계명과의 유일성은 확보되지 못함
-능동/수동형의 사용은 가급적 배제

#업무적 의미가 없거나 애매모호한 용어는 배제

 

라.관계 정의 방법

-한쪽 엔터티를 기준으로 상대 엔터티와의 관계를 규명하고 다시 반대 방향으로 관계를 규명 

1)관계구문 이해

 

2)관계정의 절차

마.관계 형태

1)1:1 관계

-반드시 단 하나씩과 관계를 가짐

#특징

*현실에서 매우 드물게 나타나는 형태

*업무의 흐름에 따라 데이터가 설계된 형태에서 많이 나타남.

*엔터티 수직분할시에 많이 나타남.

#필수-선택 형태

*한쪽은 실선이고 다른 쪽은 점선이 되는 모습. 좌측에 있는 엔터티의 개체는 대응되는 우측 엔터티의 개체가 반드시 존재해야 하지만 우측 엔터티의 개체와 대응되는 좌측 엔터티의 개체는 없을 수도 있음

-좌측 엔터티가 우측 엔터티에 집합적으로 포함되는 형태.

-예)학생-학생 프로파일(성적)

#필수-필수 형태

*양쪽 모두 실선인 모습

-예)고객-신분증(여권)

#선택-선택 상태

*양쪽 모두가 점선인 모습 (수직분할)

-예) 직원-직원의 세부정보

 

2)M:1 관계

-부모와 자식관계, 계층적

#특징

*내가 참조할(부모쪽) 정보는 나에 대해서 반드시 하나만 존재해야만 참조(join)할 때 내 집합에 변화가 생기지 않으므로 내가 참조하는 엔터티는 반드시 1쪽이 될 수 밖에 없음

*1:M (양쪽 필수)
예)주문-주문상품. 모든 주문에는 주문상품이 필수이며, 주문없은 주문상품은 없다.

*1:M (1측 옵션, M측 필수):
예)교사-학급, 교사는 최소 하나의 학급에 배정되나 일부 학급에 교사가 없을 수 있다.

*1:M (1측 필수, M측 옵션):
예)카테고리-책,

*1:M (양쪽 옵션): 선택성이 증가하면 모델의 모호성이 증가하므로 선택성을 해소해야 함

예)고객-주문

 

3)M:M 관계

#특징

*관계를 가진 양쪽 당사자 모두에서 1:M 관계가 존재할 때

4)다중 관계 처리

#특징

*다중 관계란 어떤 두 엔터티의 사이에 하나 이상의 관계를 가지고 있는 상태

여러 개의 관계로 나누어 관리하는 것을 병렬식이라고 하고, 하나로 묶어서 관리하는 것을 직렬식 관계라고 함

 

#병렬식 관계

*두 엔터티 사이에 존재하는 관계들을 별도의 관계로 간주

#병렬식 관계 특징

*테이블이 될 때 여러 개의 컬럼으로 나열

 

*하나의 행(ROW)에서 관리되므로 새로운 테이블을 추가할 필요가 없음

*인덱스 수가 증가되고 SQL이 복잡해짐

*새로운 관계의 추가, 관계 형태의 변경 등에 매우 취약한 형태

*관계 내용별로 상세 정보를 관리 불가

 

#직렬식 관계

*두 엔터티 사이에 존재하는 몇 개의 관계를 모아 상위 개념으로 통합함으로써 하나의 관계로 관리하는 방법

#직렬식 관계의 특징(병렬의 반대)

*관계들을 관리하는 새로운 엔터티가 추가

*관계들이 행(ROWS) 형태로 나타남

*인덱스 수가 감소하고 SQL이 단순해짐

*새로운 관계의 추가, 관계 형태의 변경 등에 매우 유연한 형태

*관계 내용별로 상세 정보를 관리가능

*관계 내용별로 자식 엔터티를 가질 수 있음.

 

5)특수한 형태 관계

#순환 관계

* 하나의 엔터티가 자기 자신과 관계를 맺는 관계

*특징
-하나의 순환 엔터티는 각 엔터티의 모든 속성을 포함
-각 계층에 있는 속성은 동일하게 함
-순환 모델은 필수(직선) 관계로 취급될 수 없고(무한 LOOP 발생), 반드시 선택사양 관계
-조직의 변경(추가/삭제)에 쉽게 대응

 

#BOM(BILL OF Materials) 관계

*BOM 관계의 모델을 네트워크 구조(전철 노선이나 하이퍼링크를 갖는 웹 도큐먼트 같은)
M:M 순환구조: 상세 모델링 과정에서 새로운 관계 엔터티를 추가하여 두 개의 일대다(1:M) 관계로 구성된 모델로 구체화

 

#ARC(Mutally Exclusive)관계

*어떤 엔터티가 두 개 이상의 다른 엔터티의 합집합과 관계를 가지는 것을 배타적(Exclusive) 관계 혹은 아크(Arc) 관계라 함

*아크관계의 특징
-아크 내에 있는 관계는 보통 동일.
-아크 내에 있는 관계는 항상 필수이거나 선택.
-아크는 반드시 하나의 엔터티에만 속해야 함(하나의 아크가 여러 엔터티를 가질 수 없음)
-어떤 엔터티는 다수의 아크를 가질 수 있음. 지정된 관계는 단 하나의 아크에만 사용되어야 함

-논리적으로 엔터티간의 업무적 연관성을 명확하게 표현

-실제 DB로 구현시 엔터티를 하나로 통합할 수도 있음.

 

2.6개념 데이터 모델 작성

가.개념 데이터 모델의 구성요소

-개념데이터 모델은 핵심 엔터티(키엔터티, 메인엔터티)와 핵심 엔터티 사이의 관계 도출을 통해 핵심 구조라 할 수 있는 데이터 모델의 골격을 정의

-현행 시스템의 프로세스프로세스와 DB를 분석하여 분류가능한 업무를 분석

 

나.개념 데이터 모델의 작성 방법

1)개괄 데이터 모델로부터 상세화하는 경우

-개괄 데이터 모델 또는 전사 개념 데이터 모델로부터 개념 데이터 모델을 작성할 단위 주제영역을 결정

-도출된 핵심 엔터티를 주제영역과 매핑

-주제영역별로 해당 엔터티들 간의 관계를 정의하여 개념 데이터 모델을 작성

-개념 데이터 모델을 상위 수준의 어플리케이션 모델이나 프로세스 모델과 비교하여 검증

 

2) 수집된 엔터티 후보로부터 작성하는 경우

-수집된 엔터티 후보들을 검토하고 분류하여 핵심 엔터티를 도출

-수집된 엔터티 후보들과 핵심 엔터티들을 분류하여 데이터 주제영역을 정의

-데이터 주제영역별로 해당하는 핵심 엔터티들을 배치하고 이들 간의 관계를 정의하여 개념 데이터 모델을 작성

-개념 데이터 모델을 상위 수준의 어플리케이션 모델이나 프로세스 모델과 비교하여 검증

 

3)현행 데이터 리버스를 통해 작성하는 경우

-현행 물리 데이터 모델을 생성하고 상세화 및 논리화를 거쳐 현행 논리 데이터 모델을 작성

-현행 논리 데이터 모델의 엔터티들을 분류하여 핵심 엔터티를 도출하고 현행 데이터 주제영역 에 매핑

-현행 논리 데이터 모델로부터 현행 핵심 엔터티 간의 관계를 정의하여 현행 개념 데이터 모델을 작성

-사용자 요구사항이나 현행 시스템 분석 결과 또는 선진 사례 등을 검토하여 개선 사항을 반영함으로써 현행 개념 데이터 모델로부터 목표 개념 데이터 모델을 생성

-목표 개념 데이터 모델을 상위 수준의 어플리케이션 모델이나 프로세스 모델과 비교하여 검증

 

3.논리 데이터 모델링

3.1논리 데이터 모델링 이해

가.논리 데이터 모델링 정의

-데이터베이스 설계 프로세스의 Input으로써 비즈니스 정보의 구조와 규칙을 명확하게 표현하는 기법

-비즈니스 데이터에 존재하는 사실을 인식/기록하는 기법

*논리: 현실세계를 추상화, 개념화.

 

나.논리데이터 모델링 목적 및 효과

-해당 비즈니스에 대한 데이터 관점에서의 명확한 이해

-전사적인 통합 데이터 체계 확립

-데이터의 일관성 및 정확성 유지를 위한 규칙 도출

-안정적인 데이터베이스 설계의 토대 마련

-사용자와의 명확한 의사소통을 위한 수단으로 활용

 

다.논리 데이터 모델링 필수 성공요소

-업무에 능통한 현업 사용자와 함께 데이터 모델링을 진행

-절차보다는 데이터에 초점을 두고 모델링을 진행

-데이터의 구조와 무결성을 함께 고려

-개념화와 정규화 기법을 적용

-가능하면 다이어그램을 이용하여 업무를 표현

-데이터 모델링을 지원하는 데이터 사전을 구축

 

3.2속성 정의

가.속성 개념

1)속성 정의

-엔터티에서 관리되는 구체적인 정보 항목으로 더 이상 분리될 수 없는 최소의 데이터 보관 단위

 

2)속성 특징

-속성도 일종의 집합

-관계도 속성

-속성들간은 서로 독립적, 식별자에만 종속

 

나.속성 후보 도출

-다양한 후보를 준비하고 이들 중에서 속성의 검증 규칙에 부합하는 것을 속성으로 최종 결정

1)속성 후보 수집처

-구시스템의 문서자료

-현업 장표/보고서

-사용자와 협의

-DFD의 DD

-전문 서적 및 자료

-다른 시스템 자료

 

2)후보 속성 선정 원칙

-원시 속성으로 보이는 후보는 버리지 않음

-소그룹별로 후보군을 만들고 가장 근접한 엔터티에 할당

 

3)속성의 기본 구성 요소

#속성명

-속성의 의미를 명확히 표현하는 함축성 있는 명사 혹은 명사구를 사용(명료,간결,자명)
-해당 업무에서 일반적으로 사용하는 용어를 사용
-실체명은 사용하지 말것
-필요시 표준 약어를 제정하여 속성명을 생성하고 그 속성명을 단 하나의 실체에만 속하도록 할 것

 

#도메인

-속성이 지닐 수 있는 값에 대한 업무적인 제약 조건으로 파악된 일련의 특성

-데이터 타입
-길이
-허용 값: 속성에 지정할 수 있는 모든 값들의 집합
-디폴트 값 및 디폴트 알고리즘

#선택성

선택성 조건 => 선택성이 다른 속성 값에 의해 영향을 받는 경우
필요조건 / 금지조건 / 무관계조건

 

다.속성 검증 및 확정

-최소단위분할, 하나의값, 추출속성

1)최소단위까지 분할(원자단위)

#검증방법

-집합 개념의 속성은 단순 개념으로 분할
-가능한 최소 단위까지 분할한 후 관리 필요에 따라 통합
-일자, 시간, 성명, 주민등록번호, 우편번호 등은 일반적으로 분할하지 않음
-분할 및 통합의 기준은 업무의 요구 사항에 따름

2)하나의 값만을 가지는지 검증(유일값)

#검증방법

-여러 값을 가지거나 반복되는 속성은 잘못된 속성
-반복되는 속성은 새로운 엔터티로 분할해야 할 1차 정규화의 대상임

3)추출 속성인지 검증(가공값)

-속성이 원천적인 값인지, 다른 속성에 의해 가공되어서 만들어진 값인지를 검증

4)관리수준 상세화 검토

-더 상세한 정보관리가 필요한지 검토

 

라.추출속성 규칙

-기업의 관리자들이 관심을 가지고 보는 속성으로 데이터 모델 내 반드시 기술

-추출속성은 하나 이상의 다른 데이터 속성에 축적된 여러 사례의 값을 토대로 어떤 추가 계산 작업을 수행함으로써 선택적으로 주제를 도출하는 속성에 대하여 새로운 값을 창출

-계산속성은 엔터티의 단일 사례에 대한 어떤 특성을 기술하며, 일반적으로 관련 속성의 또다른 단일 사례로부터 계산

-추출속성은 경영층이 진실로 원하고 필요로 하는 정보를 대표

-추출속성은 사용자들의 데이터 요구 사항을 나타냄

-데이터 모델에 추출 속성을 포함시키는 것은 그들의 물리적 구현에 대한 어떤 것도 내포하지 않음

-추출속성은 기본키가 되면 안됨

*추출속성 예: 최초가입일, 고객활동상태, 현주소

 

라.속성 정의시 유의사항

1)의미가 명확한 속성 명칭을 부여

2)유일한 복합명사 사용

3)단수형을 사용

4)표준단어제정

5)작의적인 전용 금지

-예정되어 있는 곳에 쓰지 않고 다른 데로 돌려서 쓰는 않아야 함

# 작의적인 전용 발생 케이스 3가지

*모델러가 속성의 의미를 매우 추상적이고, 모호하게 정의하여 그것을 적용하는 개발자들이 각기 다르게 이해함으로써 나타나는 경우

*개발이 막바지에 도달했거나 이미 운용 중인 시스템에서 새로운 사용자 요구 사항으로 인해 새로운 속성의 추가가 필요할 때 나타나는 경우

*ERP 패키지에서 자주 나타나는 형태로써 미리 전용의 용도로 속성을 정의해 두는 경우

 

3.속성 정의 사항

가.속성명

-엔터티명을 포함해서 쓰는 것을 추천. 전체 데이터 모델 내에서 유일하게

1)의미가 명확한 속성명칭 부여

2)유일한 복합명사 사용

3)단수형으로 속성명 사용

4)표준 단어 및 용어 제정

 

나.속성설명

다.선택성 및 선택성 조건

-필수 속성: 모든 인스턴스가 속성값을 가짐

-선택 속성: 속성값을 가지지 않을 수도 있음ㄴ

-선택성 조건: 속성의 선택이 다른 속성 값에 의하여 영향 받음

 

라. 속성 유형

-기본속성: 속성값이 해당 인스턴스에 원래 존재하며, 다른 속성 값으로부터 유도될 수 없는 속성.

-유도속성: 속성 값이 항상 다른 속성의 값으로부터 유도되거나 계산되는 속성

-설계속성: 업무 제약사항을 반영하거나 시스템 운영을 단순화하기 위하여 생성하는 속성

-기본과 설계 속성은 동일하게 다룸

-유도속성은 유도 알고리즘을 이용해 계산된 값을 유도 속성의 값으로 함

 

마. 유도 알고리즘

바.도메인

사.허용값

아.기본값

자.소유 권한

-데이터 거버넌스 차원의 속성 정의 및 승인에 대한 권한을 가지는 개인, 기능 또는 조직에 대한 기록 관리

-데이터(속성 값)를 생성하고 사용하는 것에 대한 권한을 가지는 개인, 기능 또는 조직에 대한 기록을 관리

 

4.속성 검증 및 확정

가.원자값 단위까지 분할

-더이상 분해할수 없는 값.

나.하나의 값만을 가지는지 검증

다.유도 속성인지 검증

-다른 속성에 의해 가공되어서 만들어진 값인지를 검증

 

5.유도 속성 규칙

-유도된 속성이나 계산된 속성은 반드시 기술

-유도된 속성: 하나 이상의 다른 데이터 속성에서 축적된 여러 사례의 값을 토대로 어떤 추가 계산 작업을 수행함으로써 선택적으로 주제를 도출하는 속성에 대하여 새로운 값을 창출

-계산 속성: 엔터티의 단일 사례에 대한 어떤 특성을 기술하며, 일반적으로 관련 속성의 또다른 단일 사례로부터 계산

-경영층이 진실로 원하는 정보

-사용자들의 데이터 요구사항

-식별자로서의 역할은 안됨

 

#속성분류

-기본 속성(Basic)

-설계 속성(Design): 업무규칙

-파생 속성(Derived): 계산 

3.3엔터티 상세화

가.식별자 확정

1)본질 식별자(업무에 의해 생성)

#키 엔터티의 본질 식별자

#절대종속/상대종속

*절대종속: 내가 태어나기 위해서 절대적으로 존재했어야 하는지, 아니면 그것이 없어도 내가 태어날 수가 있는지를 확인

#직접종속/간접종속 의미

*부모 엔터티와의 관계가 1촌이면 직접 종속이고 1촌 이상이면 간접 종속

#행위 엔터티의 본질 식별자

*절대종속이면서 직접종속인 것. 자신을 태어나게 한 근본을 찾음

 

2)후보 식별자 도출

-각 인스턴스를 유일하게 식별

-나머지 속성들을 직접 식별

-NOT NULL

-후보 식별자로 속성 집합을 선택하는 경우에는 개념적으로 유일해야 함

-후보 식별자의 데이터는 자주 변경되지 않아야 함

3)대체(보조) 식별자

-원래의 식별자를 대신할 수 있는 또 다른 속성들이나 관계(관계속성)

4)인조식별자 지정

-식별자 확정시 기존의 본질 식별자를 그대로 실질 식별자로 인정할 수 없는 여러가지 상황이 발생했을 때, 전부 혹은 일부를 임의의 값을 가진 속성들로 대체하여 새롭게 구성한 식별자

#인조식별자 지정 기준

-최대한 범용적인 값을 사용

-유일한 값을 만들기 위한 인조식별자를 사용

-하나의 인조식별자 속성으로 대체할 수 없는 형태를 주의

-편의성 ·단순성 확보를 위한 인조 식별자를 사용가능

-의미의 체계화를 위한 인조 식별자를 사용가능

-내부적으로만 사용하는 인조 식별자

 

4)식별자 확정

#UID BAR의 두 가지 의미

-식별자로서의 역할

-정보로서의 역할

#UID상속과 단절의 원리

#식별자 확정 절차

*키 엔터티 식별자 확정

*메인 엔터티 식별자 확정

*하위 엔터티 식별자 확정

 

나.정규화

1)정규화의 의미

#이상현상을 해결(입력/수정/삭제 이상)

*입력이상:어떤 데이터를 삽입하려고 할 때 불필요하게 원하지 않는 데이터도 함께 삽입

*삭제이상: 일부 정보를 삭제함으로써 유지되어야 할 정보까지도 삭제되는 현상

*갱신이상: 일부 속성 값을 갱신 함으로써 원하지 않는 정보의 이상 현상(무결성 파괴, 정보의 모순성)이 발생

 

2)정규화의 장점

-중복값 최소화

-NULL값 최소화

-복잡한 코드로 데이터 모델을 보완할 필요가 없음

-새로운 요구 사항의 발견 과정을 도움

-업무 규칙의 정밀한 포착을 보증

-데이터 구조의 안정성을 최대화

 

3)정규화 단계

#1차 정규형(원자값)

*모든 속성은 반드시 하나의 값을 가져야 함. 반복 형태가 있어서는 안됨(다중값 속성, 반복그룹 제거)

*각 속성의 모든 값은 동일한 형식

*각 속성들은 유일한 이름

*레코드들은 서로 간에 식별 가능

#2차 정규형(부분함수종속제거)

식별자가 아닌 모든 속성들은 식별자 전체 속성에 완전 종속(식별자에 부분종속하면 안됨)

물리 데이터 모델의 테이블로 말하면 기본키가 아닌 모든 컬럼들이 기본키에 종속적이어야 2차 정규형을 만족

#3차 정규형(이행함수종속제거)

*2차 정규형을 만족하고 식별자를 제외한 나머지 속성들 간의 종속이 존재하면 안됨

#BCNF 정규형(3정규화후 2정규화를 다시 수행)

*모든 결정자가 키인 릴레이션이 BCNF. 반대로 어떠한 결정자 하나라도 키가 아닌 릴레이션이라면 BCNF가 될 수 없음

*기존의 2차 정규형과 3차 정규형을 보완하려는 목적. 즉 부분 종속이나 이행 종속이 없는 3차 정규형도 변경 이상 현상이 나타날 수 있기 때문이고, 이것은 어떤 NON-KEY 속성이 결정자로 동작하기 때문에 발생

 

*엔터티 통합의 필요성

-유사성을 가진 데이터 집합에 대한 인수분해>복잡도 감소

-구조 단순화 > 유지보수

-데이터 오너십

-일관된 뷰 처리 가능

-데이터 품질 향상

-성능 및 관리 

 

접근방법>개체의 본질/행위/ 관계에 대한 유사성

 

*엔터티의 분리

다.M:M 관계 해소

1)M:M 관계의 의미

-M:M 관계는 최종적으로 완성된 데이터 모델에는 존재할 수 없는 형태

2)M:M 관계 해소의 의의

-M:M 릴레이션십은 새로운 릴레이션 엔터티를 추가하여 M:1 관계로 변경

#즉시1:M관계 엔터티로 분해해야 하는 경우

-자식을 가져야 하는 경우

-추가적인 속성을 가져야 하는 경우

-이외에는 논리모델링 상세화 단계에서 해소.

 

라.참조무결성 규칙 정의

-관계 테이블의 모든 외부 식별자 값은 관련 있는 관계 테이블의 모든 주 식별자 값이 존재

-실체의 주 식별자(PK)와 마찬가지로 외부 식별자(FK)도 데이터 무결성에 관한 업무 규칙을 내포함

-데이터베이스 설계 관점에서 선택하지 말고, 사용자의 업무 규칙에 따라 적절한 규칙을 선택

1)입력규칙

-자식 엔터티의 인스턴스를 입력할 때 

# DEPENDENT

대응되는 부모 실체에 인스턴스가 있는 경우에만 자식 실체에 입력을 허용

# AUTOMATIC

자식 실체 인스턴스의 입력을 항상 허용하고, 대응되는 부모 건이 없는 경우 이를 자동 생성

# NULLIFY

자식 실체 인스턴스의 입력을 항상 허용하고, 대응되는 부모 건이 없는 경우 자식 실체의 참조키 (FK)를 Null 값으로 처리

# DEFAULT

자식 실체 인스턴스의 입력을 항상 허용하고, 대응되는 부모 건이 없는 경우 참조키(FK)를 지정된 기본 값으로 처리

# CUSTOMIZED

특정한 검증 조건이 만족되는 경우에만 자식 실체 인스턴스의 입력을 허용

# NO EFFECT

자식 실체 인스턴스의 입력을 조건 없이 허용

 

2)삭제규칙

-부모 엔터티의 인스턴스를 삭제 또는  주식별자를 수정할 때

# RESTRICT

대응되는 자식 실체의 인스턴스가 없는 경우에만 부모 실체 인스턴스 삭제를 허용

# CASCADE

부모 실체 인스턴스의 삭제를 항상 허용하고, 대응되는 자식 실체의 인스턴스를 자동 삭제

# NULLIFY

부모 실체 인스턴스의 삭제를 항상 허용하고, 대응되는 자식 실체의 인스턴스가 존재하면, 그것의 참조키(FK)를 Null 값으로 수정

# DEFAULT

부모 실체 인스턴스의 삭제를 항상 허용하고, 대응되는 자식 실체의 인스턴스가 존재하면, 그것의 참조키(FK)를 기본값으로 수정

# CUSTOMIZED

특정한 검증 조건이 만족되는 경우에만 부모 실체 인스턴스의 삭제를 허용

# NO EFFECT

부모 실체 인스턴스 삭제를 조건 없이 허용

 

3.4이력관리의 정의

가.이력관리란

-이력은 선분이고 현재의 순간은 점

나.이력관리 대상 선정

1)사용자 조사

변경 내역을 감시할 필요가 있는가?

시간의 경과에 따라 데이터가 변할 수 있는가?

시간의 경과에 따라 관계가 변할 수 있는가?

과거의 데이터를 조회할 필요가 있는가?

과거 버전을 보관할 필요가 있는가?

 

#이력 관리 대상 예

-부서와 사원의 관계,

-상품단가

-금융상품이자율

-환율

 

2)이력 데이터의 종류

#발생 이력

-데이터가 발생할 때마다 이력 정보를 저장

#변경 이력

-데이터가 변경될 때마다 변경 전과 후의 차이를 확인하기 위해 이력 정보를 남김

#진행 이력

-업무의 진행에 따라 이 데이터를 이력 정보로 남김

3)이력관리 형태

시점 이력 : 

-데이터의 변경이 발생한 시각만을 관리

-로그성 데이터

-임의 시점 이력 조회시 비효율

-특정 시점의 환율 관리.

 

선분 이력 : 

-데이터 변경의 시작 시점부터 그 상태의 종료 시점까지 관리.

-일정기간동안 해당 정보가 유효하다는 의미

-임의시점의 데이터 조회시 유용

-특정 기간의 환율 관리.(시점별 환율 관리)

 

#이력관리 모델로 변환시 나타나는 상황

-관계의 형태를 변화: 속성이나 관계의 카디날리티 증가

-하나의 엔터티에 일반 속성 이력을 관리하면 1:M 관계의 하위 엔터티를 생성

-M:M 관계인 상태에서 해당 관계에 대한 이력을 관리하면 기존의 관계 엔터티에 추가적인 식별자 속성을 발생

-1:M 관계의 이력관리시 M:M관계로 변하여 새로운 관계 엔터티 생성

 

4)선분 이력 관리 유형

#인스턴스 레벨 이력 관리

*하나의 인스턴스의 어떤 변경이라도 발생하면 전체 인스턴스를 새롭게 생성하는 방식

*특징
-한번의 액세스로 스냅샷을 참조하는 것이 가능. 즉, 한번의 액세스로 해당 시점의 모든 데이터를 참조
-로그성 데이터를 저장할 목적인 경우 적당한 방법
-다른 이력 관리 유형에 비해서 저장 용이
-가장 큰 단점 중에 하나는 하나 이상의 컬럼에 변경이 발생했을 때 이벤트가 모호
-이벤트가 자식 정보를 가지게 된다면 매우 치명. 즉, 각각의 변경 이벤트가 하위의 데이터(엔터티)를 가지게 된다면 해당 이벤트를 찾기가 매우 어려움
-이력 관리의 다른 유형들에 비해서 저장 공간의 낭비를 초래
-실제 어떤 데이터가 변경된 것인지를 찾기 위해서는(즉, 이벤트를 찾기 위해서는) 과거의 데이터를 Merge해서 비교를 해야만 가능
-특정 순간의 스냅샷만 보는게 아니라면 처리가 복잡
-변화가 빈번하게 발생하는 상황이라면 고려(관리대상속성이 적은 경우)

 

#속성 레벨 이력 관리

*이력을 관리할 대상 속성에서 변화가 생길 때만 이력을 생성

*특징
-변경 이벤트가 매우 분명하게 관리. 즉, 실제 어떤 데이터가 변경되었는지가 분명
-하나의 이력 관리 엔터티에서 다른 엔터티와 통합 이력 관리가 가능
-변경된 것만 처리하기 때문에 독립적 처리가 가능
-변화가 발생할 가능성은 매우 낮으면서 이력 관리 대상 속성은 매우 많은 경우에 사용
-특정 속성들에 변화가 집중되는 경우에 해당 속성에 대해서만 이력을 관리 가능
-여러 속성에 대한 이력이 필요할 때 많은 Merge가 발생
-이력 관리의 다른 유형들에 비해서 향후 사용될 데이터 액세스 쿼리에서 조건 검색이 조금 어려움
-변화가 너무 많은 경우에는 적용이 곤란

 

#주제 레벨 이력 관리

*내용이 유사하거나 연동될 확률이 높은 것별로 인스턴스 레벨 이력을 관리

*특징
-인스턴스 레벨과 속성 레벨의 장점을 모두 수용하는 형태
-목적이 분명한 엔터티를 생성함으로써 확장성을 확보
-변경 부분만 처리가 가능.(독립적 처리 가능)
-다른 엔터티와 통합 이력 관리가 가능
-속성 레벨의 단점을 해소
-전체를 참조할 때 인스턴스 레벨에 비해 Merge가 발생하는 문제점이 존재.
-부문에 따라 변경 정도의 차이가 심한 경우 유리

 

다.선분 이력관리용 식별자 확정

1)선분 이력에서 식별자 결정 시 고려사항

-엔터티의 UID를 확정하는 것은 향후에 테이블로 만들어지고 사용될 때의 성능 측면도 고려

2)선분 이력에서 종료점 처리 시 주의사항

#종료점이 미정이므로 NULL

*논리적으로는 타당하지만 비교가 불가능

*인덱스를 사용하지 못하므로 수행 속도 저하

#수렴하므로 최대치 부여

*아직 종료되지 않았으므로 무한히 계속되는 것으로 간주

*최대치 부여 (예; 일자라면 9999/12/31)

*가능한 TABLE creation 시 Default constraints 부여

*수행 속도에 유리

 

*이력관리 엔터티 구성방식

-통합엔터티: 현재+과거

 

-분리엔터티: 현재와 과거를 분리

:단일엔터티, 주제중심 엔터티

3.5논리 데이터 모델 품질 검토

가.논리 데이터 모델 품질 검토 개요

#기준항목(물리모델과 동일)

-정확성:데이터 모델이 표기법 준수, 업무영역 또는 요구사항이 정확하게 반영

-완전성:데이터 모델의 구성 요소를 정의하는데 있어서 누락을 최소화, 요구사항 및 업무영역 반영에 누락이 없음

-준거성:제반 준수 요건들이 누락 없이 정확하게 준수

-최신성:데이터 모델이 현행 시스템의 최신 상태를 반영, 이슈사항들이 지체없이 반영

-일관성:여러 영역에서 공통 사용되는 데이터 요소가 전사 수준에서 한 번만 정의, 이를 여러 다른 영역에서 참조·활용되면서 모델 표현상의 일관성을 유지

-활용성:작성된 모델과 그 설명 내용이 이해관계자에게 의미를 충분하게 전달할 수 있으면서, 업무 변화 시에 설계 변경이 최소화되도록 유연하게 설계되어 있음

 

나.논리 데이터 모델 품질 검토 체크리스트의 활용

#검토대상

엔터티: 엔터티명, 엔터티정의, 통합수준, 권한, 발생건수/빈도, 다른 엔터티와의 관계

속성: 속성명, 속성정의, 속성설명, 속성유형, 식별자 정의, 법규 준수

관계: 관계명, 관계정의, 관계설명,관계표현, 식별자 상속, 요구사항 추적가능, 외래키, 참조무결성

모델전반: 주제영역 적절성, 논리모델 상세화

 

4.물리 데이터 모델링

4.1물리 데이터 모델링 이해

가.물리 데이터 모델 정의

-물리테이터 모델: 논리적 모델을 특정 데이터베이스로 설계함으로써 생성된 데이터를 저장할 수 있는 물리적인 스키마

-하나의 논리 모델의 엔터티는 경우에 따라 여러 개의 테이블로 생성 가능(성능 문제 고려)

-하나의 논리데이터 모델은 여러 개의 물리데이터 모델로 생성가능

-논리데이터 모델의 일부 속성만으로 물리 데이터 모델에서 테이블로 설계하는 경우도 발생

-물리 데이터 모델링: 논리 데이터 모델을 사용하고자 하는 각 DBMS의 특성을 고려하여 데이터 베이스 저장 구조로 변환

 

나.물리 데이터 모델 의의

-논리적 데이터 모델을 각각의 관계형 DBMS의 특성, 기능, 성능 등을 고려하여 DB의 물리적인 구조를 작성해가는 과정
-논리 데이터 모델에서 도출된 내용 변환을 포함하여 데이터의 저장공간, 데이터의 분산, 데이터 저장 방법 등을 함께 고려하는 단계

 

다.논리 데이터 모델-물리 데이터 모델을 여러개 구성하는 이유

1)분산DB 구축시

-노드별로 원하는 형태의 물리적 모델 생성

2)물리 데이터 모델 비교

3)물리적 환경의 변화

4)물리적 모델의 형상관리

 

4.2물리 요소 조사 및 분석

가.시스템 구축 관련 명명 규칙

나.하드웨어 자원 파악

-CPU: 성능과 집중적인 부하가 발생하는 시간

-Memory: 전체 메모리의 규모 및 시스템이 사용하는 메모리 영역을 포함하여 사용 가능한 메모리 영역

-Disk: 전체 디스크의 크기, 분할된 형태, 현재 디스크 활용률 등을 파악하고 사용 가능한 공간을 확인

-I/O Controller

-Network
현재 처리 가능한 속도
집중적인 부하가 발생하는 시간대
동시 접속 최대 가용 사이트 수

 

다.운영체제 및 DBMS 버전 파악

라.DBMS 파라미터 정보 파악

마.데이터베이스 운영과 관련된 관리요소 파악

-사용자 관리 기법 및 정책

-백업/복구 기법 및 정책

-보안 관리 정책

 

4.3논리-물리 모델 변환

가.논리 데이터 모델-물리 데이터 모델 변환 용어

엔터티->테이블

속성->컬럼

Primary UID -> 기본키

Secondary UID -> 유닉키

관계 -> 외래키

비즈니스 규칙 -> 제약조건

 

나.엔터티-테이블 변환

1)테이블 설명

-데이터를 저장하기 위해서 생성된 데이터베이스에서의 가장 기본적인 오브젝트.

-Rows: 테이블의 한 로우에 대응. 튜플, 인스턴스, 어커런스

-컬럼:  지정된 유형의 데이터 값을 저장

-기본키: 하나 혹은 몇 개의 컬럼 조합으로 테이블내에 동일한 값을 갖는 튜플은 존재하지 않음

-외래키: 외부 데이터 집합과의 관계를 구현

 

2)서브타입 변환(원본 참조해서 내용 파악 필요)

-서브타입의 서브타입을 별개의 테이블로 변환하는 것은 비추천

#슈퍼타입 기준 테이블 변환

-서브타입을 슈퍼타입에 통합하여 하나의 테이블로 생성

-통합된 테이블에는 모든 서브타입의 데이터를 포함

-주로 서브타입에 적은 양의 속성이나 관계를 가진 경우에 적용

-엑세스 간편, SQL단순, 속도 향상

-인덱스의 크기 증가

-서브타입의 Not Null 제약 생성 어려움.

-서브타입별 엑세스 불편

 

 

#서브타입 기준 테이블 변환

-슈퍼 타입 속성들을 각 서브타입에 추가하여 각각의 서브타입마다 하나의 테이블로생성

-분할된 테이블에는 해당 서브타입의 데이터만 포함

-주로 서브타입에 많은 양의 속성이나 관계를 가진 경우에 적용

 

 

#개별타입 기준 테이블 변환

-슈퍼타입과 서브타입을 각각 테이블로 생성

-슈퍼타입과 서브타입 테이블 간에는 1:1 관계가 생성(한 쪽을 모두 합치면 전체와 같게 된다는 면에서 개념적으로 아크 관계와 유사)

~ 전체 데이터 처리가 빈번하게 발생할 경우에 적용

~ 서브타입의 처리는 주로 독립적으로 발생할 경우에 적용

~ 테이블을 통합했을 때 칼럼의 수가 너무 많아지는 경우에 적용

～서브타입의 칼럼 수가 많은 경우에 적용

～트랜잭션이 주로 공통 부분（슈퍼타입）에서 발생

～슈퍼타입의 처리 범위가 넓고 빈번하여 단일 테이블 클러스터링을 해야 할 때 적용

 

다.속성-컬럼 변환

1)일반 속성 변환

-엔터티에 있는 각 속성들에 대한 컬럼명을 사례 데이터 표의 컬럼명란에 기록

-컬럼의 명칭은 속성의 명칭과 반드시 일치할 필요는 없으나 프로그래머와 사용자의 혼동을 피하기위해 가능한 표준화된 약어 사용

-표준화된 약어의 사용은 SQL 해독 시간을 감소

-SQL 예약어의 사용을 지양

-컬럼 명칭은 짧은 것이 좋으며, 짧은 명칭은 개발자의 생산성 향상

-필수 입력 속성은 Nulls/Unique 란에 NN을 표시

-실제 테이블에 대한 설계를 검증하기 위한 목적으로 가능하다면 표본 데이터를 입력

 

2)Primary UID 기본키 변환

#변환절차

*사례 데이터 표의 키 형태란에 엔터티의 Primary UID에 속하는 모든 속성에 PK를 표시

*PK로 표시된 모든 컬럼은 Nulls/Unique 란에 반드시 NN,U로 표시

*여러 개의 컬럼으로 UID가 구성되어 있는 경우는 각각의 컬럼에 NN,U1을 표시

*또 다른 Unique Key(Secondary UID)가 있다면 U2로 표시

 

3)Primary UID(관계의 UID Bar) 기본키 변환

#변환절차

*테이블에 외래키 컬럼을 포함

*PK의 일부분으로 표시

-Nulls/Unique 란에 각각 NN,U1을 표시

-키 형태란에 PK, FK를 표시

-여러 UID BAR가 있는 경우는 (PK, FK1), (PK, FK2), …

-여러 컬럼으로 구성된 경우 PK,FK1을 각각 표시

*추가된 FK 컬럼에 표본 데이터를 추가

 

4)Secondary(Alternate) UID Unique Key 변환

-Primary UID 변환 절차와 동일

 

5)테이블 정의서

 

라.관계변환

-관계도 속성, 관계도 집합

-선분이력을 관리하는 상위 엔터티와 관계에서는 상위 엔터티의 식별자 전체를 하위 엔터티에서 상속받지 않아도 데이터적인 연결을 수행할 수 있으므로 식별자 상속을 시키지 않을 수 있음

 

1)1:M관계 변환

1(One) 에 있는 PK를 M(Many)의 FK로 변환

- FK의 명칭 결정

- 키 형태 란에 FK 표시

- Nulls/Unique 란에 NN 표시(Must Be 관계시)

- 필수 관계가 아닌 경우에는 NN를 체크하지 않음

표본 데이터 추가

UID BAR 가 있는 경우는 전단계에서 실시

# 1:M 관계에서 1 쪽이 MANDATORY 관계일 때의 변환시 주의사항

-자식 쪽의 레코드(Row)가 반드시 하나 이상은 되어야만 부모쪽의 레코드 생성 가능

-자식 쪽의 레코드를 삭제할 경우에는 전체를 다 삭제할 수는 없고 반드시 하나 이상의 자식 레코드를 남겨두거나 자식과 부모 레코드를 동시에 삭제

 

2)1:1관계 변환

#변환절차

-Mandatory 반대쪽에 있는 테이블의 기본키를 Mandatory 쪽 테이블의 외래키로 변환

-NN 표시

#변환시 주의사항

-1:1 관계에 의해서 생긴 모든 외래키 부분은 Unique Key가 필수

-한쪽이 Optional이고 다른 한쪽이 Mandatory라면 Mandatory쪽의 테이블에 외래키 생성

-양쪽다 Mandatory라면 변환시에 어떤 테이블에 외래키를 생성할 것인지를 선택

 

3)1:M 순환 관계 변환

#변환절차

-해당 테이블 내에 외래키 컬럼 추가. 외래키는 같은 테이블 내의 다른 로우의 기본키 컬럼을 참조

-외래키 컬럼 명칭은 가능한 한 관계 명칭을 반영. -외래키는 결코 NN(Not Null) 불가

 

4)배타적 관계 변환

#외래키 분리 방법

*각각의 관계를 관계 컬럼으로 생성하는 방법.  실제 외래키 제약조건을 생성. 각각의 키컬럼이 Optional이어야 함.

-새로운 관계를 추가할때 구조 변경 필요.

-비즈니스 규칙으로 구현하기 위해 별도의 제약조건 생성 필요.

 

#외래키 결합 방법

*각각의 관계를 하나의 관계 컬럼으로 생성하는 방법. 실제 외래키 제약조건을 생성불가, User-Defined Trigger 방법을 통해 해결.

 

 

마.관리상 필요한 컬럼 추가

1)개념

-관리상의 이유로 혹은 데이터베이스를 이용하는 프로그래 밍이 좀더 빠르게 수행되도록 하기 위해서 테이블이나 컬럼을 추가

2)시스템컬럼 추가 예

-예)생성일시, 프로세스ID

 

바.데이터 타입 선택

1)개념

-논리 데이터 모델에서 정의된 논리적인 데이터 타입을 물리적인 DBMS의 특성과 성능 등을 고려하여 최적의 데이터 타입을 선택하는 작업

2)문자타입

#세부 문자 타입 선택을 위한 기준

*영문만 사용? 유니코드는 NARCHAR

* 4000자 혹은 8000자 이상의 문자열이 포함? 큰 데이터는 TEXT 

*입력되는 값의 길이가 일정한가?

3)숫자 타입

#세부 숫자 타입 선택을 위한 기준

*정말 숫자 데이터인지 판단

*세부 숫자 타입 결정

Boolean, Integer, 소수(Decimal), 화폐(Money)

4)날짜 타입

# 세부 날짜 타입 선택을 위한 기준

*일반적인 시간까지를 저장할 것이냐 아니면 정밀한 시간을 저장할 것이냐에 따라 날짜 타입을 결정

 

사.데이터 표준 적용

1)개념

-논리데이터모델을 물리데이터모델로 변환하는 과정에서 전사적으로 생성된 데이터 표준을 준수
표준용어, 표준도메인, 표준 명명규칙

 

2)데이터 표준 적용 대상

-DB, 스토리지그룹, 테이블스페이스, 테이블, 컬럼, 인덱스, 뷰

# DB

테이블의 집합으로 통합 모델링 단계의 주제 영역이나 애플리케이션 모델링 단계의 업무 영역에 대응되는 오브젝트

# 스토리지 그룹

DASD(Direct Access Storage Device) 즉, 물리적인 디스크를 묶어서 하나의 그룹으로 정의해 놓은 것이며 테이블스페이스, 인덱스 스페이스 생성시 스토리지 그룹명을 지정하여 물리적인 영역을 할당

# 테이블스페이스

테이블이 생성되는 물리적인 영역이며, 하나의 테이블 스페이스에 하나 또는 그 이상의 테이블을 저장

# 테이블

논리 설계 단계의 엔터티에 대응하는 객체

#컬럼

논리 설계 단계의 속성에 대응하는 객체

# 인덱스

테이블에서 특정 조건의 데이터를 효율적으로 검색하기 위한 색인 데이터. 대표적인 인덱스 대상으로는 기본키, 외래키등

# 뷰

테이블에 대한 재정의로서 물리적으로 테이블의 특정 컬럼, 특정 로우를 가상의 테이블로 정의 

-특정 사용자만 접근이 가능하도록 설정 가능

 

3)데이터 표준 적용 방법

#명명 규칙에 의한 표준화 적용

-예)테이블 명명규칙

#표준 용어집에 의한 표준화 적용

-사전에 사용될 모든 객체명과 해당 객체에 대한 데이터 타입, 길이 등의 표준을 정의해 놓고 이 표준들을 적용하는 방식

4.4반정규화

-정규화된 엔터티, 속성, 관계에 대해 성능향상과 개발과 운영의 단순화를 위해 중복, 통합 등을 수행하는 기법

-테이블: 테이블병합/분할/추가

-컬럼: 중복/계산/이력 컬럼추가

-관계: 중복관계

 

가.테이블 분할

1)개념

-하나의 테이블을 수직 혹은 수평 분할하는 것. 파티셔닝

-파티셔닝을 고려할때 물리적인 요소중에서 DBMS 벤더와 버전을 파악하는 것이 우선(벤더별로 파티셔닝 기법이 상이함)

 

2)수평분할

-레코드를 기준으로 테이블을 분할

-하나의 테이블에 데이터가 너무 많이 있고, 레코드 중에서 특정한 범위만을 주로 액세스 하는 경우에 사용

-분할된 각 테이블은 서로 다른  디스크에 위치시켜 물리적인 디스크의 효용성을 극대화

-현재는 이러한 수평 테이블의 분할은 DBMS 차원에서 제공

 

3)수직분할

-하나의 테이블이 가지는 컬럼의 개수가 많을때 수행

-조회 위주의 컬럼과 갱신 위주의 컬럼으로 나뉘는 경우

-특별히 자주 조회되는 컬럼이 있는 경우

-특정 컬럼 크기가 아주 큰 경우

-특정 컬럼에 보안을 적용해야 하는 경우

 

나.중복 테이블 생성

1)개념

-많은 양의 정보들을 자주 Group By, Sum 등과 같은 집계 함수를 이용해서 실시간으로 통계 정보들을 계산하는 경우 특정 통계 테이블을 두거나 중복 테이블을 추가 

2)중복테이블 생성 판단 근거

-정규화에 충실하면 종속성, 활용성은 향상되나 수행 속도가 느려지는 경우

-많은 범위를 자주 처리해야 하는 경우

-특정 범위의 데이터만 자주 처리되는 경우

-처리 범위를 줄이지 않고는 수행 속도를 개선할 수 없는 경우

-요약 자료만 주로 요구되는 경우

-추가된 테이블의 처리를 위한 오버헤드를 고려하여 결정

-인덱스의 조정이나 부분 범위 처리 유도 -클러스터링을 이용하여 해결할 수 있는지를 철저히 검토한 후 결정

 

3)중복테이블 유형

#집계(통계) 테이블 추가

-단일 테이블의 GROUP BY

-여러 테이블의 조인 GROUP BY

-넓은 범위 자주 처리하여 수행속도가 저하되는 경우

# 진행(이력) 테이블 추가

-여러 테이블의 조인이 빈번히 발생하며 처리 범위도 넓은 경우

-M:M 관계가 포함된 처리의 과정을 추적, 관리하는 경우

-검색 조건이 여러 테이블에 걸쳐 다양하게 사용되며 복잡하고 처리량이 많은 경우

 

#이력관리 테이블 추가

#인덱싱 테이블 추가

#Statement 테이블 추가

-여러 테이블의 조인이 빈번

 

다.중복 컬럼 생성

1)개념

2)중복 컬럼 생성 상황

-빈번하게 조인을 일으키는 컬럼

-조인의 범위가 다량인 경우를 온라인화해야 하는 경우처럼 속도가 중요한 컬럼

-액세스의 조건으로 자주 사용되는 컬럼

-자주 사용되는 액세스 조건이 다른 테이블에 분산되어 있어 상세한 조건 부여에도 불구하고 액세스 범위를 줄이지 못하는 경우

-복사된 컬럼의 도메인은 원본 컬럼과 동일

-접근 경로의 단축을 위해서 부모 테이블의 컬럼을 자식 테이블에 중복

-상위 레벨의 테이블에 집계된 컬럼을 추가(M:1 관계)

-하위 레벨의 테이블로 중복 컬럼을 복사(M:1 관계)

-연산된 결과를 주로 사용하는 경우에도 미리 연산

-여러 컬럼들의 수 밖에 없는 값이 검색의 조건으로 사용되는 경우에는 연산의 결과

여러 개의 로우로 구성되는 값을 하나의 로우에 나열하는 경우

-기본키의 컬럼이 길거나 여러 개의 컬럼으로 구성되어 있는 경우 인위적인 기본키를 추가

-계산된 값 이용이 빈번한 경우

 

4.5물리 데이터 모델 품질 검토

가.물리 데이터 모델 품질 검토 개요

#기준항목(최완일정준활)

-정확성:데이터 모델이 표기법 준수, 업무 영역 또는 요구사항이 정확하게 반영

-완전성:데이터 모델의 구성요소를 정의하는데 있어서 누락을 최소화하고, 요구사항 및 업무 영역 반영에 있어서 누락이 없음

-준거성:제반 준수 요건들이 누락 없이 정확하게 준수되었음

-최신성:데이터 모델이 현행 시스템의 최신 상태를 반영하고 있고, 이슈사항들이 지체없이 반영되고 있음

-일관성:여러 영역에서 공통 사용되는 데이터 요소가 전사 수준에서 한 번만 정의되고 이를 여러 다른 영역에서 참조·활용되면서, 모델 표현상의 일관성을 유지하고 있음

-활용성:작성된 모델과 그 설명 내용이 이해관계자에게 의미를 충분하게 전달할 수 있으면서, 업무 변화 시에 설계 변경이 최소화되도록 유연하게 설계되어 있음

 

나.물리 데이터 모델 품질 검토 체크리스트의 활용

#검토대상

테이블: 테이블명, 테이블설명, 테이블 정의, 통합 수준, 권한, 발생건수/빈도, 법규준수, 요구사항 추적가능성

컬럼: 컬럼명, 컬럼 정의, 컬럼 설명, 기본키, 유닉키, 법규준수, 도메인 정의, 추출컬럼의 정의, 요구사항 추적가능성, 오너쉽 정의

외래키: 참조무결성 규칙 정의, 요구사항 추적가능성, 외래키 일관성

모델전반: 반정규화, 인덱스 정의, 스토리지 정의

맨 위로 이동

 

DAP 1장 전사아키텍처 이해

 

DAP 2장 데이터 요건 분석

 

DAP 3장 데이터 표준화

 

DAP 5장 데이터베이스 설계와 이용

 

DAP 6장 데이터 품질 관리 이해