제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,활용)

요구사항정의 비즈니스의 연속성 및 장애에 따른 위험성을 사전에 제거, 최소화하기 위해 사용자의 요구 사항을 수집·분석
변경계획 수립 기존 시스템의 변경이 필요한 변경 사항인지, 표준 변경 요소인지, 모델 변경 요소인지를 판단하고 해당 작업을 수행하기 위한 작업자 배정 및 일정 계획을 수립
데이터관리정책 수립 사업 계획에 기반을 둔 기업의 비전과 목표를 달성하기 위해 필요한 데이터 확보 계획과 확보된 데이터를 효과적으로 관리, 유지하기 위한 체계 및 계획을 정의
데이터표준 정의 해당 기관에서 사용되는 용어 및 도메인, 코드, 데이터 관련 요소에 대한 표준을 전사적으로 정의
데이터표준 변경 정의된 데이터 표준(단어 표준, 도메인 표준, 코드 표준, 데이터 관련 요소 표준)에 대한 신규 및 추가 요청을 반영
데이터표준 평가 해당 기관에서 전사적으로 정의한 용어, 도메인 및 코드 표준의 준수 현황을 평가
데이터모델 정의 신규 시스템 개발시에 데이터 모델링 작업을 통해 설계된 개념 데이터 모델, 데이터 참조 모델, 논리 데이터 모델, 물리 데이터 모델을 전사적으로 생성, 유지
데이터모델 변경 사용자 요구 사항에 적합한 서비스를 제공하기 위해 데이터 표준 및 참조 모델을 토대로 데이터 모델을 변경
데이터모델 평가 해당 기관에서 전사적으로 관리하고 있는 데이터 모델을 평가
데이터흐름 정의 원천 데이터(문서, Text, DB 등)를 수기로 생성하거나 추출, 변환, 적재, 가공을 통해 목표 데이터베이스에 저장하는 데이터의 라이프사이클을 통제, 관리
데이터흐름 평가 소스 데이터를 생성하여 타깃 데이터로 저장/관리되는 데이터의 정합성을 평가
데이터베이스 정의 데이터베이스를 안정적으로 운영, 유지하는데 필요한 정기적/비정기적 작업
데이터베이스 변경 요구 사항에 따라 변경된 데이터 모델을 토대로 데이터베이스를 변경
데이터베이스 평가 현재 설정된 데이터베이스의 객체에 지정한 제약 조건과 객체 유형을 확인하여 해당 규칙이 최적의 성능을 보장하고 데이터의 오류를 방지하기에 적합한지를 평가
데이터활용도 평가 데이터의 활용도를 높이기 위해 핵심 데이터를 수 집한 후 이를 대상으로 활용도 측정 기준을 마련하여 데이터의 활용도를 측정
데이터활용도 개선 데이터 활용도의 저하 원인과 데이터 품질이 충족 되지 못한 원인을 분석하여 개선 방안을 마련하고, 데이터 품질 개선 활동을 통해 데이터 활용도를 높이기 위한 작업

 

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

데이터 관리 정책 수립 비즈니스나 IT의 환경 변화에 따라 데이터 관 리 정책의 수립 및 변경이 필요한 경우, 필요한 관련 자료를 수집하여 정책 자료를 작성
정책 작성 시에는 데이터 품질 관리 원칙에 대한 수립과 데이터 품질 관리 프로세스 정의, 담당자의 역할 정의 등의 내용 포함
데이터 관리 정책 검토 수립된 정책(안)을 토대로 CIO/EDA 및 관련 사용자, 관련 데이터 관리자 등이 참석하여 정책에 대한 완전성 및 일관성, 실현 가능성 등을 검토 하여 승인 처리
데이터 관리 정책 공표 확정된 데이터 관리 정책을 선포하고, 정책 변 경에 따른 데이터 관리 프로세스의 정의 및 수정이 필요한 경우 이를 수행

3.2데이터 표준 관리

가.정의 및 관리 목적

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

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

 

나.세부 관리 대상

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

 

#표준관리 조직 역할

조직 담당업무
데이터 관리 책임자 데이터 표준관리 정책 수립, 데이터 기능별 담당 관리자 배정, 데이터 관리 향상을 위한 전략 기획 등을 담당
데이터 표준 담당자 데이터 표준 품질 확보를 위해 데이터 표준 정의, 표준 사전 관리, 표준 검토
및 점검 등 데이터 표준관리 활동을 수행
DBA 데이터베이스에 실제 적용 및 확인을 담당
데이터 구조 담당자
(개발자 또는 설계자)
데이터 구조의 신규/변경 시 데이터 표준을 준수하여 모델에 적용
업무 담당자 업무상 필요한 데이터 구조 변경 요건을 데이터 구조 담당자(개발자 또는 설계자)에게 요청

 

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

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

표준화 요구 사항 수집 현업, 모델러, 및 사용자 뷰 운영자를 대상으로 데이터 표준과 관련된 요구 사항을 인터뷰와 설문지 조사를 통해 수집하고, 전사 데이터 표준 대상 후보를 추출하여 개선 방안을 도출
표준화 원칙 수립 현행 정보시스템에서 적용하고 있는 데이터 표준 원칙과 모델 데이터, 업무 데이터를 수집하여 현행 데이터 표준에 대한 개선 방안을 토대로 향후에 적 용할 전사 데이터 표준화 원칙을 수립
표준 단어 사전 정의 기존 모델 데이터 및 용어집을 통해 해당 기관에 서 사용되고 있는 모든 단어를 추출하여 정의된 표준화 원칙에 따라 한글명, 영문명, 영문 약어명 등을 정의하고 단어의 종류와 유형을 분류
표준 도메인 사전 정의 데이터의 물리적 데이터 특성과 사용 빈도, 업 무적 특성을 고려하여 정의된 표준화 원칙에 따라 도메인을 분류하고 도메인별 데이터 타입을 정의
표준 코드 정의 기존 모델 데이터를 통해 코드를 선별하여 현 코드집 에 누락된 코드 정보를 수집하고, 수집된 코드 정보와 표준화 원칙을 바탕으로 표준 코드를 정의
표준 용어 사전 정의 표준 단어, 표준 도메인, 표준 코드를 조합하여 정의된 표준화 원칙에 따라 표준 용어를 정의하고 용어의 설명을 수집
데이터 관련 요소 표준 정의 정의된 표준 데이터와 표준화 원칙을 바탕 으로 업무적 용도와 물리적 특성을 고려하여 데이터 관련 요소 표준을 정의
데이터 표준 검토 데이터 관리자가 정의한 표준 데이터가 업무적 용도 와 물리적 특성을 고려하여 표준화 원칙에 위배됨이 없이 정확하게 정의 되었는지를 확인하고 표준 예외 사항은 표준화 원칙에 피드백하여 처리
데이터 표준 공표 정의된 표준화 프로세스에 따라 전사 시스템에 표준 화 원칙이 적용 가능하도록 확정된 데이터 표준을 배포하고 표준 데이터 관리에 대한 이해 및 적용 을 위한 교육을 실시
변경 요구 사항 검토 요청된 표준 변경 요구 사항이 기존에 정의된 데 이터 표준을 사용해서도 처리 가능한 요건인지를 먼저 검토하고, 추가 및 변경이 필요하다고 판단 되는 경우에만 추가/변경 작업을 요청
표준 변경 영향도 평가 표준의 변경 시에 기존 테이블이나 컬럼에 영 향을 미치므로 해당 표준의 변경으로 인해 변경이 필요한 테이블 및 속성, 기타 요소들을 파악하고 해당 모델러에게 해당 작업을 요청
표준 추가 및 변경 표준 변경 요소에 대한 내역을 데이터 표준화 원칙 에 맞게 추가 및 변경한다. 변경 작업이 완료되면 변경된 사항을 토대로 영향도 평가 작업 및 공표 작업을 요청
표준 등록 및 공표 표준 추가 및 변경 작업을 통해 변경된 데이터 표 준 내역을 공표하여 향후 모델링 작업 및 데이터베이스 관리 작업 시에 활용

 

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

데이터 표준 - 데이터 모델 매핑 용어 표준, 도메인 표준, 명명 규칙 표준을 데이터 모델(개념, 논리, 물리)에 반영
데이터 표준 준수 체크 데이터 표준과 데이터 객체(데이터 모델, DB객체) 간에 데이터 표준 준수 체크
변경 영향도 분석 앞선 체크 과정에서 데이터 표준 미준수 부분에 대한 영향을 분석
데이터 표준 미준수 원인 분석 실 데이터 값에 대해서 데이터 표준을 지키고 있는지를 체크하여 표준 미준수의 원인을 분석
데이터 정제 앞선 데이터 표준을 준수하지 않은 데이터에 대해서 여러 분석 작업을 통하여 데이터를 수정

 

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

업무 요건 발생 업무 요건 변경으로 인하여 데이터 표준의 신규, 변경,삭제 요건이 발생한 경우 데이터 구조 담당자에게 해당 내용을 요청
데이터 표준 요건 접수 업무 부서에서 요청한 데이터 표준의 신규, 변경,삭제 요건을 검토
데이터 표준 조회 및 검토 기존 표준 데이터 목록 중 요건에 부합하는 표준 존재를 확인하여 신규, 변경, 삭제를 검토
변경 영향 협의 / 대안 수립 데이터 표준의 변경, 삭제가 불가능한 경우 관련 담당자와 협의하여 적절한 조치
표준 반영 및 배포 표준 검토 결과 승인된 결과에 대해서 DBA가 데이터베이스에 적용 및 배포

 

표준 코드 변경 프로세스

업무 요건 발생 업무 요건 변경으로 인하여 데이터 코드 신규, 변경, 삭제요건이 발생한 경우 데이터 구조 담당자에게 해당 내용을 요청
데이터 표준 코드 요건 접수 업무 부서에서 요청한 데이터 코드의 신규, 변경, 삭제 요건을 검토
데이터 표준 코드 조회 및 유효값 검토 기존 표준 코드 목록 중 요건에 부합하는 표준 코드 존재 및 통합 가능 여부를 검토
변경 영향 협의 / 대안 수립 표준 코드 변경, 삭제가 불가능한 경우 관련 담당자와 협의하여 적절한 조치
표준 코드 반영 및 배포 표준 코드 검토 결과 승인된 결과에 대해서 DBA가 데이터베이스에 적용 및 배포

 

데이터 표준 점검 프로세스

데이터 표준 진단 표준 진단 기법에 따라 데이터 표준 담당자가 데이터 단어, 용어, 도메인, 코드에 대한 품질을 확보하기 위하여 사후적 조치로 정기 점검을 실시
진단 결과 분석 표준 진단 결과에 대해 데이터 표준 담당자가 데이터 단어, 용어, 도메인, 코드에 대한 진단결과를 분석 
데이터 표준 보완 표준 진단 결과에 따라 데이터 표준 담당자가 데이터 구조에 영향을 미치지 않는 범위를 우선적으로 식별하여 보완하고, 데이터 구조에 영향을 미치는 부분은 구조 변경 가능 여부에 따라 조치
데이터 구조 영향도 분석 데이터 표준 변경 작업 수행시 데이터 구조 변경이 가능하다고 판단되는 경우 데이터 구조 변경 검토 요청
데이터 구조 변경 검토 데이터 구조 변경 영향 여부에 따라 검토가 필요한 경우 데이터 구조 담당자에게 검토 요청
데이터베이스 반영 데이터 구조 변경 검토가 완료되고 변경이 가능한 경우 DBA는 데이터 구조 변경 데이터베이스에 반영

3.3요구 사항 관리

가.정의 및 관리 목적

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

나.세부 관리 대상

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

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

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

#기준

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

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

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

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

#기준

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

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

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

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

#기준

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

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

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

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

#기준

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

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

 

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

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

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

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

변경 요청 사용자가 해당 기관의 시스템을 활용하면서 발생하는 외부 인터페이스 및 기능, 성능, 보안 등의 요건을 요구 사항 변경 신청서를 통해 변경 요청
요구 사항 수렴 사용자로부터 요청된 변경 요청서를 수집하여 변경 신 청서 작성 규칙에 맞게 정확하게 정의했는지를 확인하고 해당 요건을 검토할 처리담당자를 지정
요구 사항 검토 요청된 요구 사항과 관련된 자료 및 기준, 시스템 등을 확인하여 처리 가능 여부를 판단하고 처리 가능한 경우에 데이터 관리자를 통해 공식화를 요청
변경 영향도 분석 변경 요청된 내역을 토대로 변경에 따른 영향이 미 치는 설계서 및 애플리케이션, 데이터베이스 등을 도출하고, 그 결과로 변경 영향도 분석서를 작성
공식화 영향도 분석을 통해 변경 처리가 요구되는 관련 담당자를 소집하여 공식화를 하고 해당 담당자들과의 협의를 통해 승리 방식은 규모 및 기간, 시급성에 따라 결정되며, 처리 방법은 신규 시스템 개발 방식과 기존 시스템 변경 방식
변경 작업 계획 수립 영향도 평가서를 통해 관련된 업무 영역 및 관련 시스템 내역을 토대로 작업 일정 계획을 수립

 

3.4데이터 모델 관리

가.정의 및 관리 목적

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

나.세부 관리 대상

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

 

데이터 모델관리 조직 역할

#역할

조직 담당업무
데이터 관리 책임자 품질 관리 기능별 상호 연관성을 고려하여 데이터 구조 품질 확보를 위한 전략을
수립하고 세부 수행을 위한 검토 및 승인 처리를 담당
데이터 구조 담당자 기업의 데이터 구조 설계자가 여러 명인 경우 상위 수준의 주제영역 및 개념데이터
모델을 관리하고, 주기적인 데이터 모델 점검을 통해 DBMS와 데이터구조 간의
차이를 분석하여 개선하는 등의 모델 검토 및 점검을 수행
DBA 데이터베이스에 테이블 등 데이터베이스 객체를 생성하고 관리하는 담당자로, 데이터 구조 담당부서 또는 데이터 구조 담당자의 대상 DBMS에 DB 객체를 생성
및 변경하며 DB 계정을 관리하고 접근권한 통제 정책을 수립



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

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

개념 데이터 모델 정의 각 기관의 비전을 수립하는 데 필요한 데이터 주제 영역을 정의하고, 세부적인 내역보다는 전사 정보를 중복되지 않고 확장성 있게 설계
데이터 참조 모델 정의 업무 영역별, 주제 영역별 표준 데이터 집합, 관리 항목들이 표기되어 재사용이 가능한 데이터 모델을 정의하는 작업
논리 데이터 모델 정의 비즈니스 규칙을 토대로 업무의 모든 데이터 구조를 상세하고 구체적으로 정의한 모델로, 데이터 참조 모델 및 데이터 표준을 참고하여 설계 작업을 수행
물리 데이터 모델 정의 논리 데이터 모델 및 데이터 표준을 기준으로 대상 데이터베이스의 물리 특성을 고려하여 최적의 성능이 발휘될 수 있도록 상세한 설계 작업을 수행
개념 데이터 모델 변경 사용자 요구 사항의 특성에 따라 모델 변경 요 청 및 표준에 대한 변경 요청으로 분리
논리 데이터 모델 변경 개념 데이터 모델이 변경되거나 개념 데이터 모델의 변경이 없는 작은 규모의 변경(주제 영역 내의 인터페이스 조정 및 엔터티 타입의 변경, 엔터티 타입 간의 관계 변경, 속성 변경)이 요청된 경우, 또는 데이터 표준이 변경된 경우 논리 데이터 모델의 변경 작업이 수행
물리 데이터 모델 변경 변경 요청된 내역을 논리 데이터 모델 및 데이터 표준, 데이터베이스의 물리 특성 등을 참고하여 최적의 성능을 발휘할 수 있도록 물리 데이터 모델 변경 작업을 수행

 

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

개념-논리 데이터 모델 매핑 개념적으로 생성된 데이터 집합 또는 관리 항목과 논리 데이터 모델 사이의 구조적 정렬 정보를 생성하는 작업
논리-물리 데이터 모델 매핑 비즈니스 규칙을 토대로 업무의 모델 데이터 구조와 이를 바탕으로 데이터베이스의 물리적인 특성을 고려하여 정의한 물리 데이터 모델 간의 구조적 연결 정보를 설정
물리 데이터 모델-DB 매핑 물리 데이터 모델(최종 설계 도면)과 DBMS 카탈로그(건축물) 정보와의 구조적 연결 정보를 설정
개념-논리 데이터 모델 얼라인 분석 개념 데이터 모델에 정의된 모델이 실제 논리 데이터 모델에 구체적으로 정의되지 않은 모델이 존재하는지를 체크하는 등의 차이 분석 작업
논리-물리 데이터 모델 얼라인 분석 논리 데이터 모델과 물리 데이터 모델 사이의 차이를 분석
물리 데이터 모델-DB 얼라인 분석 물리 데이터 모델과 실제 DB와의 차이를 분석

 

주제영역 관리 프로세스

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

 

주제영역 변경 요청 데이터 주제영역을 추가·삭제·수정하는 업무로, 주제영역 분류체계 및 데이터 중심의 분류 원칙에 따라 주제영역을 생성·삭제하며, 주제영역 명, 주제영역 코드 등의 관리 항목에 대해 수정
주제영역 변경 검토 및 승인 변경 요청된 주제영역의 적정성을 검토하여 승인/불가 처리를 수행
주제영역 변경 확정 및 반영 주제영역 변경 검토에 따라 승인된 결과를 주제영역 정의서 또는 보유 중인 표준 관리 시스템에 변경사항을 반영. 변경된 주제영역이 테이블명의 생성·삭제에 영향을 주는 경우 DBA에게 관련 사항 통보

 

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

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

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

 

개념 데이터 모델 변경 요청 기업의 업무 요건 변화에 따라 개념 데이터 모델의 신규, 변경, 삭제 요건을 요청
개념 데이터 모델 검토 및 승인 작성된 개념 데이터 모델에 대해 데이터 관리 책임자의 검토 및 승인 처리를 수행

개념 데이터 모델 확정 및 반영 데이터 관리 책임자의 보완 요청 사항을 반영하여 기업의 개념 데이터 모델을 확정하고, 개념 데이터 모델 관리를 위한 산출물 또는 보유중인 표준 관리 시스템에 반영



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

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

 

논리/물리 데이터 모델 변경 요청 업무 요건 변경에 따라 필요 속성(칼럼) 및 관계 등을 정의하여 데이터 표준 담당자에게 데이터 표준 검토 및 반영을 요청
데이터 표준 검토 및 반영 데이터 모델 설계에 따라 단어, 용어, 도메인 정의가 데이터 표준에 맞게 적용되었는지 확인
논리/물리 데이터 모델 검토 및 승인 논리와 물리 데이터의 특성에 맞게 검토를 수행. 논리 데이터 모델은 논리적인 관점에서 엔터티 간의 관계 적정성, 중복 여부, 정규화 위배 등을 검토하고, 물리 데이터 모델은 물리적인 관점에서 적용 
-데이터베이스의 특성 및 데이터 성능에 문제점이 없는지에 대해 상세하게 검토 후 승인
논리/물리 데이터 모델 확정 최종 모델이 확정되는 과정이며, 주요 산출물로는 논리 다이어그램과 물리 다이어그램
객체(테이블) 생성 대상이 되는 데이터베이스에 DB 객체 생성 권한이 있는 DBA가 처리

 

데이터 모델 점검 프로세스

 

논리-물리 데이터 모델 매핑 비즈니스 규칙을 토대로 업무의 모델 데이터 구조와 이를 바탕으로 데이터베이스의 물리적인 특성을 고려하여 정의한 물리 데이터 모델 간의 구조적 연결 정보를 설정
물리-DB 데이터 모델 매핑 물리 데이터 모델(최종 설계 도면)과 DBMS 카탈로그 정보와의 구조적 연결 정보를 설정
논리-물리 데이터 모델 얼라인 분석 논리 데이터 모델과 물리 데이터 모델 사이의 차이를 분석
물리-DB 데이터 모델 얼라인 분석 물리 데이터 모델과 실제 DB와의 차이를 분석
점검 결과 취합 및 보고 데이터 구조 담당자와 DBA가 수행한 데이터 모델 점검 결과를 취합 및 보고
점검 결과 검토 및 승인 데이터 모델 점검 결과에 대해 검토 및 보완 사항을 확인 후 변경 영향도 분석에 따라 데이터 모델 및 데이터베이스 변경을 수행

 

3.5데이터 흐름 관리

가.정의 및 관리 목적

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

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

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

 

#데이터 흐름 관리 방법

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

모두 포함되어 있는지 확인

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

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

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

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

 

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

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

데이터 추출(변환) 요건 검토 현업 업무를 위해 사용자로부터 접수한 요구 사항 중에서 데이터를 추출(변환)하여 해당 데이터베이스에 적재해야 하는 요건을 검토
소스 데이터 분석 모델러는 소스 데이터를 추출(변환)하여 해당 데이터베이스에 적재하기로 결정된 요건에 대해 소스 데이터 관점에서 해당 테이블 및 컬럼에 대한 내용을 분석
소스 데이터 추출(변환) 설계 모델러는 소스 데이터의 변환 로직 및 적재 로직을 설계
소스 데이터 추출(변환) 테스트 모델러는 추출(변환) 설계에 따라 소스 데이터를 테스트 형식으로 타겟 데이터베이스에 적재

소스 데이터 추출(변환) 검증 사용자는 소스 데이터 추출(변환) 테스트에서 작성된 대상 내용을 바탕으로 해당 요건이 타깃 데이터베이스에 정확하게 반영되어 데이터가 적재되었는지를 확인
소스 데이터 추출(변환) 모듈 반영 데이터베이스 관리자는 사용자의 검증이 완료된 소스 데이터 추출(변환) 변화를 운영 환경으로 적용
소스 데이터 추출(변환) 모니터링 모델러는 운영 환경에 적용된 소스 데이터 추출(변환) 모듈을 정해진 규칙에 따라 주기적으로 모니터링하여 그 결과를 데이터 관리자에게 보고
데이터 흐름 점검 기준 도출 데이터 오류를 최소화하기 위해 지속적으로 품질 점검을 통해 관리되어야 할 기준을 도출
데이터 흐름 점검 지표 생성 앞선 데이터 흐름 점검 기준별로 구체적인 데이터 흐름의 정합성을 체크할 수 있는 지표들을 도출
데이터 정합성 체크 앞선 지표에 따른 구체적인 체크 모듈을 실행하여 정합성을 체크
오류 데이터 분석 데이터 정합성 검증을 통하여 추출된 오류 데이터에 대한 분석을 수행
변경 영향 분석 앞선 체크 과정에서 오류 데이터의 원인에 대한 분석 을 통하여 구체적으로는 데이터 표준을 변경할 때의 영향, 데이터 모델을 변경할 때의 영향, 데이터베이스 객체를 변경했을 때의 영향 등을 분석
데이터 정제 데이터 정합성을 지키지 않은 오류 데이터의 원인 분석 결과에 따라 데이터 관리의 각 요소에 적절한 조치를 수행하고, 데이터 값을 수정

 

3.6데이터베이스 관리

가.정의 및 관리 목적

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

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

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

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

데이터베이스 생성 비즈니스 요건에 맞게 설계된 데이터 모델을 토 대로 작성된 DDL문을 가지고 데이터베이스의 물리 특성을 고려하여 데이터베이스를 구성
백업 주기 및 스케줄 정의 어떠한 장애가 발생되더라도 사용 중인 데 이터의 완전 복구가 가능하도록 백업 주기 및 스케줄이 정의
데이터베이스 백업 수행 백업 주기별 스케줄 표를 참고로 하여 백업을 수행
데이터 보안 대상 선정 보호되어야 할 자산의 파악 및 가치에 대한 평가 작업을 수행하고, 시스템에 존재하는 취약점 및 위험 요인에 대한 분석 작업을 수행
데이터 보안 적용 보안 관리 대상별 중요도에 따른 보안을 적용하는 작업으로, 물리적 접근 보안 및 네트워크 보안, 서버 및 운영체제 보안, 데이터베이스 보안, 응용시스템 보안, PC 보안 등 종합적인 보안 적용 필요
데이터 보안 교육 수행 기관별로 수립된 데이터 보안 정책을 년 1회 이상 전 구성원을 대상으로 실시해야 하며, 교육 평가 작업 등을 통한 고품질의 교육이 될 수 있도록 체계화
데이터베이스 성능 개선 해당 기관의 사용자가 필요로 하는 성능 개선 사항
데이터 보안 개선 중요 데이터에 대한 훼손, 변조, 도난, 유출에 대 한 물리적 접근 통제(제한 구역, 통제 구역 등) 및 사용 통제(인증, 암호화, 방화벽 등)에 대한 요건 이 발생되었을 경우 보안 장치를 개선하는 작업
데이터베이스 복구 장애 등으로 인해 데이터에 대한 전반적인 훼손 및 에러로 인해 기존 백업된 데이터로의 복구 작업
테스트 데이터베이스 변경 변경 요청에 의해 제시된 요건에 따라 변 경된 데이터 모델을 토대로 작성된 DDL문을 가지고 데이터베이스의 물리 특성을 고려한 테스트 데이터베이스를 변경된 데이터 모델과 동일한 형태로 변경하는 작업
운영 데이터베이스 이관 테스트 데이터베이스에 변경된 내역을 토대로 해당 애플리케이션에 대한 문제점을 확인하는 단위 테스트와 타 애플리케이션과의 인터페이스 를 테스트하는 통합 테스트, 사용자의 만족도를 확인하는 사용자 테스트 등을 수행한 후 안정성 및 정확성이 확보되면 운영 데이터베이스에 해당 변경 내역을 반영

 

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

DB객체 관리 효율성 체크 현재 설정된 데이터베이스의 객체에 지정한 제약 조건과 객체 유형을 확인하여 최적의 성능을 보장하고 데이터의 오류를 방지하기 위한 객체 관리 규칙들인지 평가
비효율 원인 분석 현재 설정한 객체 관리 유형이나 객체 유형이 비효율적 성능을 보인다면 해당 원인을 분석
변경 영향도 분석 비효율을 개선하기 위하여 DB내에서 제약 조건이나 객체 유형을 변경할 수도 있으나 테이블의 통합/분리의 변경이 요구된다면 물리 데 이터 모델의 변경이 요구 가능

 

3.7데이터 활용 관리

가.정의 및 관리 목적

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

나.세부 관리 대상

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

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

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

#기준

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

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

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

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

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

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

2)측정 방법

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

 

#역할

조직 담당업무
데이터 관리 책임자 데이터 활용 관리 업무를 총괄하며, 데이터 활용도 측정을 위해 활용 관리 계획
및 목표를 수립
데이터 활용 담당자 데이터 활용도 측정 기준에 따라 활용 측정 및 요인을 분석
활용도 측정을 위해 핵심 또는 관련데이터 수집, 활용 측정, 활용 저하 요인 분석
등의 업무를 수행
DBA 데이터 활용도 측정을 위한 기술적인 부분을 담당하며, 데이터 활용 담당자가
데이터 활용자료 요청 시 해당 자료를 제공해주는 역할을 수행

 

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

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

핵심 데이터 수집 개선 대상이 되는 데이터를 선정 기준에 따라 선정 하고, 업무부하 및 시스템 부하를 고려하여 측정 데이터량을 조정
데이터 활용도 측정 기준 수립 데이터별 활용도 측정 기준을 정량적으 로 마련하고 데이터 활용 개선 목표치를 설정하여 향후 개선 작업에 대한 평가 작업 수행 시 활용
데이터 활용 측정 데이터 활용도 측정 기준에 따른 활용도 평가 작업을 수행하고, 데이터 활용도 측정 결과서를 작성
활용 저하 요인 분석 데이터 활용의 저하를 유발한 비즈니스적, IT 적 원인을 데이터의 생성, 갱신, 변환, 활용 관점에서 도출하고, 데이터 활용 저하 원인 분석서를 작성
개선 방안 마련 활용 저하 원인별로 개선 방안을 마련
개선 활동 수행 승인된 개선 방안과 원인별로 도출된 개선 방안의 활동 계획에 따라서 개선 활동을 추진
개선 활동 평가 개선 활동을 평가하는 과정으로, 측정 목표치를 초과한 데이터에 대해서는 개선 항목에서 제외시키거나 목표치를 조정

 

*사용자 활용 관리

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



====2021 교재 추가 내용

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

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

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

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

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

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

 

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

1. 정의 및 관리 목적

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

 

2. 세부 관리 대상

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

 

#품질 기준

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

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

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

 

#프로파일링

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

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

#프로파일링 분석기법

분석기법 설명
칼럼 분석 칼럼 속성에 대한 준수 여부 검증(Mmn/Max, Null/Space)
[측정 가능 도메인 예시]
· 여부 - 여부, 유무 칼럼은 'Y', 'N' 값을 가진다.
· 금액 가입금액은 0보다 크고 1,000,000보다 같거나 작아야 한다.
· 수량 - 재가입횟수는 0보다 크고 5보다 같거나 작아야 한다.
· 율 - 지분율은 0보다 크고 100보다 같거나 작아야 한다
패턴 분석 데이터를 구성하는 값에 대한 패턴을 분석
[측정 가능 도메인 예시]
· 번호 - 주민등록번호는 숫자 13자리로 구성되어야 한다.
우편번호는 숫자 5자리로 구성되어야 한다.
날짜 분석 데이터 타입은Character이나 의미상 날짜/시간 유형 데이터에 대한 유효성 분석
[측정 가능 도메인 예시〕
· 날짜 - 결혼일자는 'YYYYMMDD'의 유효한 날짜이어야 한다.
코드 분석 칼럼 내 코드 값이 정의된 표준에 따라 구성되었는지를 검증
[측정 가능 도메인 예시]
코드 - 고객등급코드는 통합코드 코드ID = 'A00l' 코드 데이터와 일치해야 한다
참조무결성 분석 부모-자식 관계 데이터의 참조무결성 분석
[측정 가능 도메인 예시]
번호 고객주소정보의 고객번호는 고객원장에 반드시 존재해야 한다.

 

#업무 규칙

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

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

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

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

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

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

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

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

 

#품질 측정

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

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

#품질 개선

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

방법을 정의

 

값 관점 품질 측정 방법

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

측정산식:

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

 

=====

#데이터 값 관리 조직 역할

조직 담당업무
데이터 관리 책임자  데이터 품질 관리 업무를 총괄하며, 데이터 값에 대한 품질 확보를 위해 계획 및 목표를 수립
데이터 품질 담당자 -데이터 품질을 진단하고 상시 발생하는 품질 오류를 개선하며, 품질 관련 이슈발생 시 관련 조직과의 의사소통 채널 역할을 수행
-주요 업무로는 데이터 값 진단 및 개선 계획 수립, 프로파일링, 업무규칙 진단 등 데이터 품질 진단, 품질 관리 관련 의사소통, 접수된 데이터 오류 개선방안 수립 및 개선 등의 업무를 수행
DBA 데이터 값 진단을 위한 기술적인 부분을 담당하며, 데이터 품질담당자와의 협업을
통해 데이터 값 진단 수행, 업무규칙 등록 및 모니터링 등의 업무를 수행

 

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

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

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

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

 

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

진단 계획 검토 데이터 값 진단 계획 관련 자료를 수집하고 검토하는 과정이며, 업무부서의 담당자 및 관련자들과 협의 및 검토를 추진하는 작업을 수행
진단 수요 분석 데이터 값 품질 진단 대상 DB 파악을 위해 품질 오류 신고 내용, DB 개선 수요, 품질 이슈 개선 수요 등을 분석하고 파악
진단 대상 선정 수요조사 결과를 분석하여 식별된 DB 중 데이터 값 진단의 중요성, 시급성 관점에서 1차 진단 대상을 선정하고, 중요 마스터 영역, 중요 트랜잭션 영역, 공통 영역 등으로 데이터를 구분하여 2차 진단 대상을 선정
진단 방향 수립 품질 이슈에 대한 다양한 수요 분석 결과를 바탕으로 도메인 (날짜, 코드, 비율 등)과 업무규칙 기반의 프로파일링 기법을 적용하여 구체적인 진단 방향을 정의
진단 일정 및 계획 수립 진단 목적, 수행 방법 및 절차, 일정, 이해당사자 역할 및 책임, 소요 예산 등을 포함하여 진단 추진 계획을 수립
진단 추진 계획 승인 데이터 품질 담당자가 수립한 계획에 대해서 항목별 목적 달성 여부를 검토하고 승인

 

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

프로파일링 기준 제시 데이터 값 진단을 위한 지침 및 방식에 대해서 기준을 마련
도메인 분석 대상 업무의 주요 엔터티 전체를 분석 대상으로 선정하고 엔터티에 대해 프로파일링 대상별 도메인 분석을 실시
-칼럼 분석은 데이터의 타입(Type), 길이(Length), 식별자(PK) 여부, 칼럼 속성 정의 등 기준항목(예 :상태, 여부, 구분, 결과, 유형, 유무 등)이 분석 대상. 
-비정형패턴 분석은 특정한 데이터 패턴(숫자, 문자, 영문자 등)이 정의된 항목(예 : 주민등록번호, 사업자등록번호, 카드번호, 계좌번호, 우편번호, 한글성명 등)이 분석 대상. 
-날짜 유형 분석은 칼럼 속성이 날짜 유형을 제외한 날짜 데이터 항목(예: varchar(8) 최종시설퇴소일자)이 분석 대상. 
-코드 분석은 마스터 코드, 개별 코드(업무적으로 자체 정의) 테이블을 참조하는 칼럼들이 분석 대상.
참조무결성 분석은 데이터 논리, 물리적 관계를 서로 참조하도록 설계(Foreign Key)되었으나 DBMS 생성
시 관계를 생성하지 않은 항목이 분석 대상
프로파일링 수행 -등록된 프로파일링 대상에 대해 각각의 분석 기준별로 데이터 프로파일링을 수행
프로파일링 결과 분석 -프로파일링 결과에 대해 분석 관점별로 데이터의 분포와 오류 여부를 분석
-칼럼 분석은 정의되지 않은 Indicator 데이터 확인, Range를 벗어나는 데이터 확인, Garbage 데이터
확인, 테스트 데이터 확인 등이 중점 분석 관점
-비정형패턴 분석은 정의된 Format을 벗어난 유효하지 않은 Format 데이터 확인, 날짜유형 분석, 정의되지
않은 날짜 유형(YYYYMMDD -p YYYYMM) 데이터 확인 등이 중점 분석 관점
-코드 분석은 통합 코드에 등록되지 않은 코드 데이터 확인이 중점 분석 관점
-참조무결성 분석은 RI 관계가 유효하지 않은 데이터 확인이 중점 분석 관점
프로파일링 결과 배포 프로파일링 분석된 결과를 보고서 형태로 작성하여, 데이터 오너십이 있는 업무부서 및 데이터 관리 책임자에게 전달한다. 전달된 분석 결과는 회의를 통해 공유하고 향후 추진 계획을 논의
오류(추정)데이터 식별 프로파일링 분석 결과를 토대로 오류 또는 오류로 추정되는 데이터를 식별

 

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

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

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

업무규칙 도출 기준 제시 업무규칙 도출 기준 제시는 비즈니스 요구 사항에 따라 지속적으로 관리되어야 하는 데이터 값에 대해 업위규칙을 도출하고 작성하기 위한 가이드 및 규칙을 마련
업무규칙 작성 업무규칙 작성은 비즈니스 요구 사항의 변화, 실행 변환 기준, 이행 기준 등에 따라 업무에 대한 데이터 값 진단을 위해 서술식 형태로 업위규칙을 정의하고 해당 업무규칙을 SQL 스크립트로 작성
업무규칙 검토 요청된 업무규칙에 대한 검토 실시 후 보완 및 부적합한 경우 재작성을 요청하고, 보완이 필요한 부분은 업무부서와 데이터 품질 담당자에게 검토 의견을 제시
업무 규칙 등록 승인이 완료된 업무규칙에 대해 보유중인 품질 관리 시스템 또는 스크립트 방식으로 실행될 수 있도록 등록
업무 규칙 등록 통보 등록이 완료된 업무규칙에 대해서 등록 결과를 통보

 

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

업무 규칙 변경 요청 업무 프로세스 변경 및 데이터 구조 변경 등에 따라 업위 칙 변경을 요청
업무규칙 변경 검토 요청된 업무 규칙에 대해서 변경 내용과 규칙 등을 확인 및 검토
업무규칙 변경(등록) 승인된 업무규칙에 대해 업무규칙 요청 내용을 보유 중인 품질 관리 시스템 또는 스크립트를 반영
업무규칙 변경 통보 업위규칙 변경 통보는 등록이 완료된 업위규칙에 대해서 등록 결과를 통보

 

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

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

데이터 값 개선 대상 정의 프로파일링 및 업위규칙 진단 결과를 토대로 분석한 결과, 오류로 판정된 데이터에 대해서 개선 대상을 선정
개선 추진 계획 마련 오류데이터에 대해 개선을 위해 구체적인 계획을 수립
개선 추진 계획 승인 수립된 계획에 대해서 데이터 관리 책임자가 검토를 통해 승인
오류 원인 분석 오류데이터가 유입된 근본적인 원인을 파악
향후 개선 과제 오류데이터 개선(정제)에 따른 데이터 수치 변화, 통계 불일치 등의 업무에 영향이 큰 경우는 향후 개선 과제로 분류
오류데이터 개선 수행 당장 업무에 영향도가 적고, 우선적으로 개선(정제)이 필요한 데이터 값에 대해서 업무부서와 데이터 품질 담당자가 수행
개선 결과 통보 전체 오류데이터 중에서 개선(정제)된 오류데이터, 향후 추진 가능한 오류데이터, 개선이 불가능한 오류데이터로 분류하여 개선 결과를 통보

 

맨 위로 이동

 

DAP 1장 전사아키텍처 이해

 

DAP 2장 데이터 요건 분석

 

DAP 3장 데이터 표준화

 

DAP 4장 데이터 모델링

 

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

 

Posted by Lumasca
,

제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요건은 쉽게 무결성 유지 가능

 

구분 장점 단점
애플리케이션 사용자 정의 같은 복잡한 무결성 조건을 구현함 -소스코드에 분산되어 관리의 어려움
-개별적으로 시행되므로 적정성 검토에 어려움
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를 감소

 

구분 B-TREE BITMAP
구조 특징 Root block, branch block, leaf block으로 구성되며, 인덱스 깊이를 동일하게 유지하는 트리 구조 키 값이 가질 수 있는 각 값에 대해 하나의 비트맵을 구성
사용 환경 OLTP DW, Mart 등 OLAP
검색 속도 처리 범위가 좁은 데이터 검색 시 유리함 다중 조건을 만족하는 데이터 검색 시에 유리함(특히, 비정형 쿼리)
분포도 데이터 분포도가 좋은 칼럼에 적합 데이터 분포도가 나쁜 칼럼에 적합
장점 입력, 수정, 삭제가 용이함 비트 연산으로 OR 연산, NULL 값 비교 등이 가능함
단점 처리 범위가 넓을 때 수행 속도 저하 전체 인덱스 조정의 부하로 입력, 수정, 삭제가 어려움








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장 데이터 품질 관리 이해

 

Posted by Lumasca
,

제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)연쇄작용 또는 업무규칙

-연쇄작용: 입력,수정,삭제 또는 조회 등의 작업이 동일 엔터티 혹은 다른 엔터티의 속성에 영향을 미치는 업무 규칙

-업무규칙은 조직이 데이터를 인식하고 사용하는 방법에 기초 



구분 관계형 비관계형
구조 -6가지 특성 갖는 테이블
-Post Define Schema
-DB구조변경 용이
-Flat File
-Pre define Schema
-DB구조변경 어려움
조작 -8개 조회/처리 연산자
-집합(SET)처리
-원자값 처리
-READ조회, 처리연산자
-한건씩 처리
-Pointer 처리
무결성 엔터티,참조,무결정,연쇄작용 무결성 개념 없음
접근경로 -Key와 인덱스 별개
-Data에 대한 접근경로 유연

-Key와 인덱스 동일
-Data에 대한 접근경로 제한적




 

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 제약 생성 어려움.

-서브타입별 엑세스 불편

 

하나의 테이블로 통합이 유리한 경우 하나의 테이블로 통합이 불리한 경우
~ 데이터 액세스가 좀 더 간편
~뷰를 활용하여 각 서브타입만을 액세스하거나 수정 가능
~수행 속도가 좋아지는 경우가 많음
~서브타입 구분 없는 임의 집합의 가공 용이
~다수의 서브타입을 통합한 경우 조인 감소 효과가 큼
~복잡한 처리를 하나의 SQL로 통합하기가 용이
~특정 서브타입의 NOT NULL 제한 불가
~ 테이블의 칼럼 수가 증가
~테이블의 블럭 수가 증가
~처리 시마다 서브타입의 구분이 필요해지는 경우가 많음
~ 인덱스 크기가 증가

 

#서브타입 기준 테이블 변환

-슈퍼 타입 속성들을 각 서브타입에 추가하여 각각의 서브타입마다 하나의 테이블로생성

-분할된 테이블에는 해당 서브타입의 데이터만 포함

-주로 서브타입에 많은 양의 속성이나 관계를 가진 경우에 적용

 

여러개 테이블로 분할이 유리한 경우 여러개 테이블로 분할이 불리한 경우
~ 서브타입 속성들의 선택 사양이 명확한 경우에 유리하다.
~ 처리 시마다 서브타입 유형 구분이 불필요
~ 전쳬 테이블 스캔 시 유리
~단위 테이블의 크기가 감소

~서브타입 구분 없이 데이터 처리하는 경우 UNION이 발생
~ 처리 속도가 감소하는 경우가 많다
~트랜잭션 처리 시 여러 테이블을 처리하는 경우가 증가
~복잡한 처리의 SqL 통합이 어려움
~부분 범위 처리가 불가능해질 수 있다.
~ 여러 테이블을 합친 뷰는 조회만 가능
UUID 유지 관리가 어려움

 

#개별타입 기준 테이블 변환

-슈퍼타입과 서브타입을 각각 테이블로 생성

-슈퍼타입과 서브타입 테이블 간에는 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장 데이터 품질 관리 이해

 

Posted by Lumasca
,

제1장 데이터 표준화 개요

제1절 데이터 표준화 필요성

제2절 데이터 표준화 개념

제3절 데이터 표준 관리 도구

 

제2장 데이터 표준 수립

제1절 데이터 표준화 원칙 정의

제2절 데이터 표준 정의

제3절 데이터 표준 확정

 

제3장 데이터 표준 관리

제1절 데이터 표준 관리

제2절 데이터 표준 관리 프로세스

 

 

제1장 데이터 표준화 개요

제1절 데이터 표준화 필요성

1.데이터 관리 현황 및 개선방안

가. 데이터 활용상의 문제점

-데이터의 중복 및 조직,업무,시스템별 데이터 불일치 발생

-데이터에 대한 의미 파악 지연으로 정보 제공의 적시성 결여

-데이터 통합의 어려움

-정보시스템 변경 및 유지보수 곤란

-데이터명칭이나 표준화에 대한 미준수로 동일 데이터의 구별이 어려움

 

나.데이터 문제점의 원인

-동시 다발적인 정보시스템 개발: 시스템간 상호 연관성이 증대되어 단위 시스템 위주의 개발 보다는 관련 정보시스템을 동시에 개발하는 경향이 높음

-전사 데이터 관리 마인드 미형성: 데이터에 관리 주체가 단위 시스템의 개발자, 운영자 중심으로 이루어져 있어 단위 업무 지원에 초점

-전사 데이터 관리 인력 부재: 유지 보수 단계에서는 개별 유지 보수 인력에 의존

-전사 데이터 표준 관리 도구 부재: 정보시스템 개발시에는 수작업으로 데이터 표준의 적용, 준수 체크 등을 수행하였지만 운영 단계에서 수작업에 가까운 표준 관리 방법은 많은 애로사항이 존재

 

다.데이터 관리 개선방안

-데이터 표준화, 규격화를 위한 기본 방침 설정

-전사적인 정보 공유를 위해 유지되어야 할 공통 데이터 요소의 도출

-전사적인 데이터 요소 등록 및 관리 체계 구축

-정보시스템 개발 및 유지보수시 승인된 데이터 요소를 활용함으로써 시스템 개발의 효율성 및 데이터 공유성 향상

 

2.데이터 표준화 기대효과

-명칭의 통일로 인한 명확환 의사소통 증대

-필요한 데이터의 소재 파악에 소요되는 시간 및 노력 감소

-일관된 데이터 형식 및 규칙의 적용으로 인한 데이터 품질 향상

-정보시스템간 데이터 인터페이스 시 데이터 변환, 정제 비용 감소

 

제2절 데이터 표준화 개념

1.데이터 표준화 정의

-시스템별로 산재해 있는 데이터 정보 요소에 대한 명칭, 정의, 형식, 규칙에 대한 원칙을 수립하여 이를 전사적으로 적용하는 것

-코드, 용어, 도메인, 메타데이터, 데이터셋 등의 표준을 수립하여 DB에 일관되게 적용하는 일련의 활동

 

가.데이터 명칭

-데이터 명칭은 해당 기업내에서 데이터를 유일하게 구별해주는 이름

-유일성: 유일하게 구분

-업무적관점의 보편성: 보편적으로 인지

-의미전달의 충분성: 데이터의 의미 및 범위 파악 가능

 

나.데이터 정의

- 데이터 정의는 해당 데이터가 의미하는 범위 및 자격 요건을 규정

#데이터 정의 기술시 고려사항

-제3자의 입장에서 기술

-의미전달이 어려울 경우 실제 데이터 값도 같이 기술

-약어 또는 전문용어 사용 지양

 

다.데이터 형식

데이터 형식은 데이터 표현 형태의 정의

#데이터 타입: Numeric, Text, Date, Char, Timestamp 등

#데이터 길이 및 소수점 자리

#데이터 형식 정의시 고려사항

-도메인을 정의하여 데이터 표준에 적용

-데이터의 최대값 또는 최대 길이가 고정이 아닌 경우 여유있게 정의

-특수 데이터 타입(CLOB 등)은 가급적 사용 안함

 

라.데이터 규칙

데이터 규칙은  발생 가능한 데이터 값을 사전에 정의하여 데이터의 입력 오류와 통제 위험을 최소화

#데이터 규칙의 유형

-기본값: 어떠한 값의 입력도 없는 경우 데이터 타입에 따라 미리 정의된 기본값이 입력

-허용값: 업무 규칙과 일관성을 갖도록 입력이 가능한 데이터 값을 제한

-허용범위: 업무 규칙과 일관성을 갖도록 입력이 가능한 데이터 값을 범위로 제한

2.데이터 표준화 구성요소

가.데이터 표준

#표준용어

-업무에서 자주 사용하는 속성 또는 단어의 조합을 의미

-업무적으로 사용하는 용어에 대한 표준을 정의함으로써 용어 사용 및 적용에 대한 혼란을 방지하고 원활한 커뮤니케이션을 촉진

-업무적 용어:일상 업무에서 사용하는 용어

-기술적 용어:정보시스템에서 사용하는 용어

#표준단어

-전사에서 업무상 사용하며, 일정한 의미를 갖고 있는 최소 단위의 단어

-표준 용어를 구성하는 단어에 대한 표준을 정의함으로써 용어에 대한 한글명과 영문명을 일관되게 정의

-사용빈도가 높은 단어를 우선 정의하고 빈도가 낮은 단어는 다른 단어와 결합해서 정의

-동일한 개념을 의미하는 용어(또는 표준용어)의 생성을 예방

-유의어사용은 금지되며 대응되는 표준단어로 정의

-표준용어의 영문명 작성 기준

#표준도메인

-속성에 정의된 조건을 만족시키는 값의 범위

-칼럼에 대한 성질을 그룹핑한 개념

-문자형, 숫자형, 일자형, 시간형으로 분류

-동일한 성질을 가진 컬럼의 데이터 타입 및 데이터 길이를 일관되게 관리

-금액, 날짜, 내용, 명칭, 수량, 여부, 율, 번호, 코드 등 그룹핑

#표준코드

-도메인의 한 유형, 특정 도메인 값(코드값)이 이미 정의되어 있는 도메인

- 데이터 값, 즉 코드값까지 미리 정의

#기타 데이터 표준관련 요소

-데이터 모델에서 정의하는 주제영역, 관계명과 데이터베이스에서 정의하는 데이터베이스, 데이터베이스 스키마, TABLESPACE, INDEX, CONSTRAINT 등에 대한 표준을 관리

 

나.데이터 표준 관리 조직

-데이터 관리자는 하나의 기업 또는 조직 내에서 데이터에 대한 정의, 체계화, 감독 및 보안 업무를 담당하는 관리자

1)데이터 관리자의 주요 역할

-데이터에 대한 정책과 표준 정의:데이터에 대한 표준화 원칙 및 표준을 정의

-부서간 데이터 구조 조율:전사 데이터 관리 기준에 의거하여 단위 시스템이나 조직 부처에 명확한 데이터 관리 기준을 제시

-데이터 보안관리:데이터에 대한 보안 정책 수립, 보안 정책 준수 여부 체크, 보안 시정 조치 요구등을 수행

-데이터 모델 관리:데이터에 대한 중요한 의사소통의 도구가 되는 데이터 모델을 물리적인 변경 시점에 동일하게 관리

-데이터의 효율적인 활용방안 계획

 

2)데이터 관리자의 세부역할

-전사 데이터관리자

-데이터 표준화에 대한 정책 결정

-검토된 데이터 표준 제안에 대한 승인

-업무 데이터관리자

-담당 업무 기능의 데이터 요구사항 반영을 위해 필요한 데이터 표준 정의

-업무관련 데이터 표준 변경 제안에 대한 합동 검토

-업무시스템 데이터관리자

-시스템 관리목적의 데이터 요구사항을 위해 필요한 데이터 표준 정의

-업무 관련 데이터 표준 변경 제안에 대한 합동 검토

-데이터모델에 대한 데이터 표준 적용 및 준수 여부 체크

 

#DBA와 DA 비교

구분 데이터 관리자(DA) 데이터베이스 관리자(DBA)
관리 대상 데이터 요구 사항을 반영한 데이터 모델 및 각종 표준 데이터 모델을 특정 데이터베이스 제품의 특성에 맞추어 구축한 데이터베이스
주업무 업무에 필요한 데이터의 메타데이터를 정의하고 신규 또는 변경된 요구 사항을 신속하게 데이터 모델에 반영 요구되는 성능 수준을 발휘하면서 안정적 으로 운영되도록 데이터베이스를 관리
품질 수준 확보 데이터 표준의 관리 및 적용을 통해 품질 수준을 확보 데이터의 정합성 관리를 통해 데이터 품질 수준을 확보
전문 기술 담당 업무 분야에 대한 업무 지식과 데이 터 모델링에 대한 전문성이 필요 데이터 모델에 대한 해독 능력 및 특정 데 이터베이스 제품에 대한 전문 지식이 필요



다.데이터표준화 절차

-데이터 표준화 요구사항 수집: 개별시스템 데이터 표준 수집. 데이터 표준화 요구사항 수집. 표준화 현황 진단

-데이터 표준 정의: 표준화 원칙, 데이터 표준 정의( 표준용어, 단어, 도메인, 코드)

-데이터 표준 확정: 데이터 표준 검토 및 확정. 데이터 표준 공표

-데이터 표준 관리: 데이터 표준 이행. 데이터 표준 관리 절차 수립: 데이터 표준 적용, 변경, 준수 검사 절차

 

*표준안 신규적용 절차

-표준화 요구사항과 현행 문서 수집

-표준화 문제점 도출

표준을 정의하기 위한 원칙과 절차 수립

제3절 데이터 표준 관리 도구

-수립된 전사 데이터 표준 정보의 관리, 데이터 표준에 의한 개발 및 유지보수 지원, 데이터 표준 준수 및 변경 영향도 평가를 담당하는 기능으로 구성

1.확장된 데이터 표준 관리도구의 기능

-데이터 모델 관리: 데이터 표준 관리 도구를 이용하여 개념, 개괄, 논리, 물리 모델에 대한 조회 및 변경 관리를 하는 기능

-데이터 표준 관리: 표준 단어, 표준 도메인 등의 표준 관련 사전을 관리하는 기능

-데이터 품질 관리: 데이터 품질 진단 및 분석과 비즈니스 규칙 등을 관리하는 기능

-OLAP 정보 관리: OLAP 시스템에 구현된 메타 정보와 연계하여 관리하는 기능

사용자 권한 관리: 현업 및 IT 사용자에 대한 권한 관리 기능

-변경 영향도 분석: 표준 및 모델 변경에 따른 전체 영향도를 분석하는 기능

-ETL 정보 관리: 계정계부터 최종 사용자까지 데이터 흐름 및 매핑 정보에 대한 관리 기능

표준 요청 관리: 표준의 신규 및 변경에 따른 절차와 승인 관리 기능

-JOB 관리: ETL 프로그램의 정상 및 오류 여부 등을 관리하는 기능

-DB 스키마 관리: 데이터 모델과 실제 DB와의 일치성 등을 관리하는 기능

 

2.데이터 표준 관리 시스템 기능

가.데이터 표준 관리 기능

-단어관리: 전사 관점에서의 단어 사전 관리, 금칙어의 사전 정의 및 관리

-용어관리: 업무적으로 정의된 표준 용어에 대한 관리, 기본 단어의 조합으로 업무 용어를 생성함

-도메인관리:  대표 및 그룹 속성에 대한 데이터 타입, 길이, 소수점 이하 길이 등을 사전에 정의한 도메인 관리

-코드관리:  수집된 코드로부터 코드 통합 과정을 거쳐 전사 표준 코드를 도출한 후 관리, 소스 코드 값과 표준 코드와의 변환 매핑 관리

-멀티표준관리:코드, 칼럼, 테이블, 도메인 등에 대하여 멀티 표준을 관리해서 전사에 존재하는 여러 표준을 지원하고 이후 전사 표준으로 통합 되도록 함

 

나.데이터 구조 관리 기능

-ER 모델 구조 관리: ER 모델 관리,  리포지터리에서 데이터 구조 정보를 추출 및 로드

-DB 스키마 관리: 다양한 DBMS로부터 DB 카탈로그를 추출 및 로드

-가변 속성 관리: 모델 기본 속성 외에 설계 속성을 쉽게 추가

-이력 관리: 데이터 모델 변경 이력, 형상 관리 지원

-모델 비교 관리:  데이터 구조 정보에서 표준화 자동 검사, 표준에 대한 준수도 자동 검사, 데이터 구조 정보 간 비교

 

다.프로세스 관리 기능

-표준등록: 코드, 칼럼, 테이블, 도메인 등에 대한 사용자 요청부터 데이터관리자의 승인/반려 기능 지원

-모델등록: 엔터티, 속성, 테이블, 칼럼 등 데이터 모델에 대한 사용자 요청을 등록하고 관리자의 승인/반려 기능을 지원

 

3.데이터 표준관리시스템 도입시 고려사항

-확장성: 다양한 시스템 및 DBMS의 정보 수집과 OLAP 툴 등의 다양한 데이터 구조 정보를 추출 할 수 있는지 검토

-유연성: 단계적 적용을 위한 여러 개의 통합 표준을 사용할 수 있는 복수 표준 관리가 가능한지와 한글명 및 영문명의 표현 방식, 표준의 변경 용이성을 검토

-편의성: 한글명의 영문명 자동 변환, 표준 검증의 주기적인 작업 수행 기능, 메타 정보 수집시 IMPORT 수작업 최소화 등 사용자 편의성을 검토

 

4.데이터 표준관리 시스템 부재시 관리 방법

가.모델링 도구 사전 활용

나.엑셀 등의 문서로 관리

제2장 데이터 표준 수립

제1절 데이터 표준화 원칙 정의

1.데이터 표준화 요구사항 수집

-현업 및 개발자로부터 데이터 표준과 관련된 요구 사항을 인터뷰 및 설문조사 등을 통하여 조사함으로써 전사 데이터 표준 대상 후보를 식별하고 개선점을 도출하는데 사용할 자료를 마련

 

2.현행데이터 표준 원칙 분석

-현행 정보시스템에서 적용하고 있는 데이터 표준 원칙 및 데이터 표준을 수집하고, 수집된 자료를 통하여 식별된 데이터 표준의 관리 대상 및 현황을 파악

가.현행 데이터 표준 원칙 수집

-현행 정보시스템에 적용되고 있는 데이터 표준에 대한 원칙을 수집

#현 정보시스템 개발 지침 문서 및 데이터 표준의 확보

-현행 데이터 표준 원칙은 기존 정보시스템을 개발할 당시 작성하고 적용되었던 개발 지침 문서 및 데이터 표준을 통하여 수집

#현행 정보시스템 모델의 분석

-현행 데이터 모델 또는 데이터베이스 스키마에서 보여지는 오브젝트의 정의 패턴 분석을 통하여 정보시스템 구축시 적용했던 원칙을 유추

 

나.데이터 표준 원칙 사용 현황 분석

-수집된 데이터 표준 원칙 자료를 토대로 현행 정보시스템에서 적용하고 있는 데이터 표준 대상 및 관리 항목을 도출

 

3.데이터 표준 개선방안 정의

-현행 데이터 표준 사용 현황 명세서와 표준화 요구 사항 정의서를 토대로 하여 데이터 표준 대상별 문제점 및 개선 방안을 도출

 

4.데이터 표준 원칙 수립

-현행 데이터 표준에 대한 개선 방안을 토대로 향후에 적용할 전사 데이터 표준 기본 원칙을 정의하고, 향후 전사 데이터 표준의 생성 및 변경시 참고할 수 있도록 각 데이터 표준 대상별 데이터 표준 원칙을 작성하여 문서화

 

가.데이터 표준 기본 원칙 정의

-데이터 표준 개선 방안을 참고하여 전체적으로 적용할 기본 원칙을 수립함으로써 표준화에 대한 방향을 사전에 정의

 

나.데이터 표준 지침 작성

-모든 사용자들이 참고해야 하는 데이터 표준화에 대한 구체적인 지침 문서를 작성

1)데이터 표준 지침의 기본 구성

-데이터 표준 지침은 데이터 표준 대상별로 어떻게 표준화할 것인가에 대해 구체적으로 정의한 문서

*개요: 데이터 표준화 및 데이터 표준 지침에 대한 목적

*데이터 표준화 관련자의 역할과 책임: 데이터 표준화와 관련된 사용자들을 정의하고 그들의 역할 및 책임을 규정. 전사 데이터 관리자, 데이터 관리자, 모델러

*데이터 표준 관리 절차: 데이터 표준과 관련된 일련의 작업 프로세스를 규정하고, 프로세스별로 데이터 표준화 관련자들의역할을 기술

*데이터 표준 기본 원칙: 데이터 표준 대상 모두에 대해 일반적으로 적용되어지는 기본 원칙

*데이터 표준 대상별 명명규칙: 데이터 표준 대상별로 데이터 표준 명칭을 작성하는 방법에 대해 구체적으로 기술

-사용문자: 알파벳, 한글, 숫자, 특수문자, 전각/반각 등의 허용 여부 또는 사용 조건을 규정

-영문 대소문자: 알파벳을 사용할 경우 대소문자 사용과 관련한 규칙을 규정

-한글명과 영문명 동시 정의 여부: DBMS에 반영되는 객체들은 대부분 알파벳으로 정의하도록 되어 있는 경우가 있기 때문에 이와 관련된 데이터 표준 정의 대상에 대해서는 한글명과 영문명의 정의가 필요, 표준용어, 단어가 해당

-명칭의 구조: 표준 용어를 사용하는 테이블명 및 칼럼명의 경우 명칭을 통하여 그 특성 또는 부가 정보를 표시할 수 있도록 명칭에 대한 단어 표준 조합 구조를 명시. 예) 수식어 + [수식어] + 속성 유형(금액, 건수, 코드 등)

-명칭에 대한 허용길이: 표준 용어를 사용하는 테이블명 및 칼럼명의 경우 DBMS의 물리적 특성으로 길이의 제약을 받기 때문에 표준 용어의 허용 길이를 명시

-명칭 표준화에 대한 기준: 유사한 개념의 단어/용어가 복수개 존재할 경우 어떤 기준으로 표준 단어/ 표준 용어로 선택할 것인가를 결정하는 기준을 정의
예) 일련번호, ID, SEQ --> ID로 표준화

-명칭에 대한 예: 명칭에 대한 허용 길이, 명칭 구조 체계, 명칭 표준화 기준 등을 준수하여 작성된 샘플을 몇 가지 명시

 

*데이터 형식 정의에 대한 기준: 데이터 표현 형태를 정의하는 기준 및 방법

 

2)주요 데이터 표준 대상별 지침의 일반적인 구성

-데이터 표준 대상에 대한 세부 지침은 각 데이터 표준 대상의 특성에 맞게 기술

표준단어:
-한글명 및 영문명에 대한 알파벳, 한글, 숫자, 특수문자, 전각/반각 등의 허용 여부 또는 사용조건
- 대소문자 사용 규칙
- 한글명, 영문명에 대한 허용 길이
- 합성어(단어의 조합으로 이루어진 단어) 정의에 대한 지침
- 접두사에 대한 처리 방안
- 동음이의어/이음동의어 허용 여부 및 처리 방안

표준용어:
- 데이터 명칭에 대한 구조 체계
- 한글명, 영문명에 대한 허용 길이
- 용어를 테이블이나 컬럼명으로 사용할 경우 준수해야 할 특이한 명명규칙
- 용어를 컬럼명으로 사용할 경우 데이터 형식 표준화에 대한 기준 및 표준 도메인 적용 여부

표준도메인:
- 데이터 형식 표준화에 대한 기준

표준코드:
- 데이터 명칭에 대한 구조 체계 및 명명에 대한 기준
- 데이터 형식 표준화에 대한 기준
- 코드번호 체계 정의에 대한 규칙

 

3)데이터 표준 개발 지침 작성 시 유의사항

-DBMS마다 허용하는 테이블 및 칼럼의 물리명 길이가 상이함: 영문명의 허용길이 정의시 고려

-DBMS마다 정의하고 있는 데이터 타입이 각기 상이함

제2절 데이터 표준 정의

1.표준 단어 사전 정의

-기존 데이터 모델 및 용어집을 통해 해당 기관에서 사용되고 있는 모든 단어를 추출

-추출된 단어는 단어 종류와 유형을 분류하고 업무 정의 및 용도를 고려하여 표준 단어를 정의

가.표준 단어 사전

-단어:문법상 일정한 뜻과 구실을 가지는 말의 최소 단위

-표준 단어 사전: 기업에서 업무상 사용하며 일정한 의미를 갖고 있는 최소 단위의 단어를 정의한 사전

1)표준 단어 관리 기준(표일대)

표준성: 정보시스템이나 일반적인 업무에서 사용되는 단어 가운데에서 추출

일반성: 일상적으로 사용하고 있는 사전적 의미의 단어와 의미상 크게 다르지 않아 일반인도 해당 단어의 의미를 이해 가능

대표성: 동의어를 가질 수 있으며 표준 단어로 선언된 단어는 비슷한 의미의 동의어들을 대표

 

2)표준 단어 작성 형식

-표준 단어는 전사적으로 관리하고 있는 엔터티와 속성을 개별 단위로 하여 추출하며, 추출된 단어는 동음이의어와 이음동의어를 정비한 후 논리명(한글명)을 기준으로 물리명(영문명, 영문약어명), 유사 용어까지 함께 정리하여 관리

-표준 단어 사전에는 개별 단어 외에도 동의어, 유의어, 반의어 등과 같은 단어 간의 구조도 함께 정의

이음동의어: 한글명 및 영문명을 분석 후에 업무적으로 가장 대표적인 표준단어를 선택

 

나.표준 단어 정의

1)현행 용어 수집

-기업 내 존재하는 모든 정보시스템에 대한 데이터 모델 또는 테이블 정의서와 칼럼 정의서를 분석하여 현행 용어에 대한 한글명 및 영문명을 수집

2)단어 분할

-수집된 현행 용어에서 업무상 사용되며 일정한 의미를 갖고 있는 최소 단위의 단어로 분할

3)단어 정련

-분할하여 취합된 모든 단어 중에서 의미가 동일한 단어들에 대해 하나의 대표 단어를 표준으로 선정하고 그에 대한 영문 약어명을 선택

4)표준 단어 사전 정의

단어 정련 작업을 통하여 표준으로 선택한 모든 단어들에 대한 한글명 및 영문명을 표준 단어 사전에 등록

 

다.표준 단어 정의시 고려사항

-표준 단어의 단위는 최소 단위를 기준으로 하되 사용 빈도가 높은 단어의 조합 또는 단어의 조합이 하나의 고유한 의미를 가지는 경우 하나의 표준 단어로 정의

-표준 단어의 영문명도 반드시 알파벳으로 시작하도록 정의

-단어는 특히 동음이의어가 많기 때문에 사용빈도가 높은 것을 표준 단어로 사용빈도가 낮은 것은 다른 단어와 조합하여 표준 단어로 정의

 

#접두어/접미어 개별

-단어개수 많지 않음,

-일관된 단어사전,

-물리DB 제약 자리수를 넘는 경우 발생,

처리할 수 없는 경우 발생(물 , 손 )

 

#접두어/접미어 합성

-단어개수 많음, 

-단어의 다용도 사용으로 일관성 떨어짐,

-물리DB 제약 자리수 넘을 가능성 낮음,

-사용자 편의성 높음



2.표준 도메인 사전 정의

-업무적인 용도, 사용 빈도와 데이터의 물리적인 특성 등을 고려하여 도메인을 분류하고 도메인별 데이터 타입을 부여

가.표준 도메인 사전

-도메인:속성에 정의된 조건을 만족시키는 값의 범위
-표준 도메인은 전사적으로 사용되고 있는 데이터 가운데에 논리적, 물리적으로 유사한 유형의 데이터를 그룹화하여 해당 그룹에 속하는 데이터의 유형과 길이를 정의한 것

1)표준 도메인 관리 기준(표유업)

-표준성: 표준 도메인은 전사 차원에서 공통적으로 사용되는 속성을 대상으로 정의

-유일성: 동일한 내용의 중복 도메인이 서로 다른 이름으로 선언되지 않도록 관리

-업무지향성: 업무의 특성을 충분히 반영할 수 있도록 선언하여 관리

 

2)표준 도메인 작성 형식

-전사적으로 관리하고 있는 모든 데이터 속성 혹은 대표 속성 가운데에 DBMS에 동일한 형태로 구현되는 속성들을 추출하여 그룹화

 

나.표준 도메인 정의

-정보시스템별로 혼재되어 사용되고 있는 칼럼의 칼럼명, 데이터 타입, 길이 등을 정리하여 표준 도메인을 정립

1)현행 용어 정보 분석

-기업 내 존재하는 모든 정보시스템에 대한 데이터 모델 또는 칼럼 정의서를 이용하여 현행 용어에 대한 용어명과 데이터 타입 정보를 수집한 뒤 물리적으로 유사한 유형의 용어들을 그룹화

-동일한 정보시스템에 대한 데이터 모델에서 추출된 현행 용어들을 유일하게 추출.
-데이터 타입과 길이가 동일한 용어들을 검색하여 유사한 속성의 용어들을 그룹핑.
-용어명 중에서 끝 쪽 단어를 기준으로 유사한 속성의 용어들을 그룹핑

2)표준 도메인 정의

-그룹핑된 유사 속성 용어의 의미에 따라 표준 도메인명을 정의하고 그에 따른 데이터 타입 및 길이를 정의

- 업무적으로 의미가 있는 도메인명을 부여
- 기존 데이터와의 호환성 및 범용성을 위하여 그룹핑된 용어들에게 부여된 데이터 타입 길이 중 가장 큰 데이터 타입 길이를 표준으로 정함

 

다.표준 도메인 정의시 고려사항

-현실적으로 어느 도메인에도 속하지 않는 칼럼이 있을 수 있기 때문에 모든 용어를 포괄하는 표준 도메인을 생성할 필요는 없음

-표준 도메인에 정의할 데이터 형식을 어떻게 정의하고 각기 다른 DBMS에 어떻게 물리적으로 적용할 것인가에 대한 방안을 고려

-표준 도메인을 도출하면서 동일한 용어로 판명된 현행 용어들을 별도로 기록하여 향후 동일한 데이터 표준 용어로 통일할 때 참고

 

3.표준 코드 사전 정의

-표준 코드 정의는 수집된 용어로부터 코드를 선별하여 현 코드의 코드값을 조사

현 코드를 바탕으로 통합 요구 사항과 통합 필요성에 따라 통합 대상을 파악하고 표준 코드를 정의하고 현 코드와 매핑 설계

가.표준 코드 사전

-표준 코드에는 각 산업별로 법·제도적으로 부여하여 공통적으로 사용되는 코드뿐만 아니라 기업 내부에서 정의하여 사용하는 코드도 포함

1)표준 코드 관리 기준(재일정)

-재사용성: 표준 코드는 기업에서 자체적으로 정의하여 사용하는 것보다 표준화 기구나 정부, 공공기관에서 정의한 코드를 재사용

-일관성: 코드는 업무 범위 내에서 가능한 한 유일하게 정의

-정보분석성: 가능한 범위의 데이터는 모두 코드화하여 관리

 

2)표준코드 작성 형식

-전사적으로 사용하고 있는 코드를 추출하여 정의하고 부여된 코드와 동일한지를 확인하고, 동일한 값을 가지는 코드에 대해서 통합 작업을 수행하여 단일화 작업을 수행

 

나.표준 코드 정의

-표준 코드는 각 정보시스템별로 사용되고 모든 코드들을 수집하여 동일 코드를 파악하고 통합하여 표준 코드를 정의

1)현행 코드 수집

-기업 내 존재하는 모든 정보시스템에서 사용하는 코드 정보를 수집

#코드 관리 형태

-단독 코드 테이블: 하나의 코드를 하나의 테이블에서 관리하는 형태

-통합 코드 테이블: 복수개의 코드를 하나의 통합 관리 테이블에서 관리하는 형태

-애플리케이션 정의: 코드를 데이터베이스에 저장하여 관리하지 않고 애플리케이션에서 정의하여 관리하는 형태

#코드 파악 방법

-코드 데이터 값 수집: 코드를 관리하는 테이블, 통합 코드 테이블, 애플리케이션 사용자 인터페이스를 통하여 코드 정보를 수집

-코드성 칼럼 파악: 각 정보시스템의 테이블에 존재하는 칼럼 중에서 코드 정보를 저장하는 코드성 칼럼을 파악

-수집된 코드에 대한 사용처 파악: 식별한 코드성 칼럼별로 어떠한 코드를 저장하는지를 파악함으로써 누락된 코드를 확인

 

2)현행 코드 상세 분석

-수집된 현행 코드 정보를 상세히 분석함으로써 동일하거나 통합이 가능한 코드를 식별

-코드값이 일치하는 동일한 코드 인스턴스를 가지는 코드를 찾은 뒤 해당 코드의 모든 코드 인스턴스를 확인하고 비교함으로써 통합 가능한 코드를 식별
-분석해야 할 대상 코드가 너무 많을 경우에는 코드를 사용하는 업무 기능별로 코드를 분류한 후, 분류된 단위로 코드를 분석

 

3)표준 코드 정의

-현행 코드 상세 분석을 통하여 식별된 통합 대상 코드의 코드 인스턴스를 정련하여 통합

-통합 대상이 없는 코드는 현행 코드 인스턴스를 그대로 유지하는 것이 일반적
-통합 대상이 존재하고 통합 대상 코드의 코드 번호가 서로 상이할 경우 새로운 코드 번호를 부여함으로써 표준 코드를 정의

 

다.표준 코드 활용

-모든 정보시스템은 표준 코드를 사용

-일부 업무에서 특정 코드의 모든 코드 값을 사용하지 않고 범위를 한정하여 일부 코드값만 사용 할 경우에는 표준 코드로부터 파생된 코드를 정의하여 사용

 

라.표준 코드 정의시 고려사항

-코드값은 향후 확장성을 고려하여 정의하여야 하며, 여러 업무에서 사용할 수 있도록 통합된 코드로서의 일관성을 유지.
-시스템 운영 중에 코드값이 변경되는 경우 해당 코드를 사용한 기존 데이터의 유지를 위해 기존 코드값을 삭제하는 대신 사용 중지 상태로 관리하고 새로운 코드값을 신규로 정의.
-표준 코드를 도출하면서 파악한 표준 코드-현행 코드 간의 변환 매핑 정보를 별도로 기록하여 향후 신규 정보시스템으로의 데이터 이행시 참고

 

*코드표준화순서

-현행코드관련자료수집

-코드도메인 분류 및 중복 제거

-동일 의미 코드의 통합

- ASIS 코드와 TOBE코드 매핑

 

4.표준 용어 사전 정의

-단어, 도메인, 코드 표준이 정의되면 이를 바탕으로 표준 용어를 구성하고, 단어의 조합, 도메인 분류, 데이터 타입 길이, 코드값 등을 기준으로 해서 표준 적용이 업무적으로나 IT적으로 무리가 없는지 검토

가.표준용어사전

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

-단어는 개별적이나 용어는 업무와 조직의 성격에 따라 그 조합이 달라질 수 있음

1)표준 용어 관리 기준(표일업)

-표준성: 용어의 표준화를 통해 용어 사용의 차이에 따라 발생되는 전사 차원 의 혼란을 최소화

-일반성: 용어가 지나치게 업무 관점에서만 정의되어 일반적으로 이해하기 힘들거나 의미상에 혼란을 초래해서는 안됨

-업무지향성:용어는 기업의 업무 범위 내에서 약어를 사용하거나 내부에서 별도로 정의 가능. 지나친 약어 사용은 주의

 

2)표준 용어 작성 형식

-표준 용어는 전사적으로 보유하고 있는 엔터티와 속성을 대상으로 추출된 표준 단어를 조합하여 생성되며 용어 사전은 엔터티 용어 사전과 속성 용어 사전으로 구분하여 정의

-정의된 각각 의 용어는 논리명(한글명)과 물리명(영문명)을 가지며, 용어 범위 및 자격 형식 등을 설명

 

나.표준 용어 정의

-정보시스템별로 사용되고 있는 모든 현행 용어를 수집하고 표준 단어 사전, 표준 도메인 사전, 표준 코드 사전 등을 참조하여 현행 용어에 대한 표준 용어를 도출

1)현행 용어에 대한 표준 단어 도출 및 표준 용어 정의

-현행 용어로부터 표준 용어의 도출은 단어 수준에서의 표준화를 통해 이루어짐

2)표준 단어에 대한 도메인/코드 정의

-표준 도메인을 도출하면서 별도 관리했던 정보를 가지고 표준 단어에 대한 도메인을 정의 가능

 

다.표준 용어 정의시 고려사항

표준 용어 도출시 데이터 표준 원칙에서 정의한 한글명 및 영문명의 허용 길이를 넘지 않도록함

만약 영문명의 허용 길이가 문제가 된다면 한글명을 변경하거나 한글명을 구성하는 표준 단어들 중 일부를 조합하여 하나의 표준 단어를 등록하여 영문명의 길이를 축약

생성된 표준 용어가 너무 길다면 두개의 표준 용어를 복합하여 생성하는 방법도 고려

 

*표준용어변경시 직접적인 영향: 표준단어, 표준도메인, 기존업무용어, 표준코드값은 직접적인 영향이 없음

*표준용어변경시 검토할 문서: 신규로 정의된 코드명칭

제3절 데이터 표준 확정

1.데이터 표준 검토

-데이터 관리자가 정의한 표준단어사전, 표준도메인사전, 표준코드, 표준용어사전 등을 확인하고 해당 용어가 현재 사용되고 있는 용어로 정확하게 정의되어 있는지를 확인하고 승인

가.데이터 표준 검토 계획 수립

-데이터 표준 검토 대상이 되는 자료를 확인

-검토 기준은 전사 데이터 표준 기본 원칙 및 각 대상별 데이터 표준 지침을 근거로 작성

-유일성: 각 데이터 표준이 물리적으로나 의미론적으로나 유일한지 확인

-완전성: 각 데이터 표준 대상별 필수 입력 사항들이 전부 정의되었는지 확인

-정확성: 각 데이터 표준 대상별 입력 사항이 충실히 입력되었는지 확인

-범용성:정의한 데이터 표준이 여러 정보시스템에서 적용이 가능한지 확인하고, 향후 개발할 각 정보시스템에 적용할 수 있도록 검토 계획을 수립

 

나.데이터 표준 검토

-검토 기준 및 검토 대상 산출물을 준비하고 검토에 참여할 대상자에게 배포

-검토 관련 장소, 시간, 준비 장비 등 검토를 실시하기 위한 제반 준비를 수행하며, 검토 담당자별로 검토 세션에서 수행해야 할 역할을 주지시킴

-검토시 진행자는 제기되는 이슈에 대해서 참석자들간에 결론을 도출하기 위한 토론이 발생하지 않도록 이슈 목록으로 정리하고 검토가 정해진 일정 내에 마치도록 주의

-검토 세션이 종료되면 세션별로 그 결과를 정리

-검토 결과가 정리되면 데이터 표준 대상별로 보완 사항을 작성

 

다.데이터 표준 보완 및 승인

-보완 결과에 대해 확인 준비. 검토 결과, 보완 목록, 보완 사항이 반영된 데이터 표준을 준비하고 배포.

-보완 목록에 준하여 데이터 표준 반영 여부를 확인. 반영되지 않은 사항 중 미반영 사유가 존재할 경우에는 미반영 사유가 타당성이 있는지를 검토하고 사유가 타당하지 못한 경우에는 보완.

보안 목록에 있는 보완 사항이 모델에 모두 반영된 것을 확인하면 본 작업을 종료하고 전사 데이터 관리자의 승인을 획득.

 

2.데이터 표준 공표

-확정된 데이터 표준을 배포하여 전사 시스템에 적용 가능하도록 하며, 관련 내역에 대한 이해 및 적용을 위한 교육을 수행

가.데이터 표준 배포

-검토가 종료되고 전사 데이터 관리자의 승인을 득한 데이터 표준은 데이터 표준 관리 도구에 등록하여 전사의 모든 사용자가 데이터 표준을 조회할 수 있도록 조치하고, 정보시스템 개발 관련자들이 데이터 표준을 준수하여 개발할 것을 공지

나.데이터 표준 교육

-데이터 표준에 대한 이해 및 효과적인 적용을 위해 사용자 및 운영자에 대한 교육 훈련 계획을 수립하고, 데이터 표준 지침 및 기타 데이터 표준 관련 교육 교재를 작성하고 교육을 수행

 

제3장 데이터 표준 관리

제1절 데이터 표준 관리

1.데이터 표준 관리 개요

-개별적인 데이터 표준화 요소에 대한 표준화 작업 절차 이후, 데이터 표준 정의 단계에서 수립된 데이터 표준에 근거하여 관리 프로세스를 정립하여 데이터 표준 관리

2.데이터 표준 관리 프로세스 유형

-정의된 데이터 표준이 개발 과정이나 운영 과정에서 발생하는 데이터 표준의 신규 요건이 발생한 경우에 이를 처리하기 위한 프로세스

-데이터 표준이 변경 또는 삭제되는 경우, 관련 데이터 표준화 요소와 데이터 모델, 데이터베이스, 관련 프로그램까지 영향도를 분석할 수 있는 절차와 이를 처리하기 위한 프로세스

-데이터 표준을 잘 준수하고 있는지를 수시로 체크하고 확인할 수 있는 프로세스

 

제2절 데이터 표준 관리 프로세스

1.데이터 표준 관리 프로세스 구성요소

-프로세스, 태스크, 역할과 담당 업무가 명확하게 정의

2.구성요소별 설명

가.프로세스

-데이터 표준이 신규로 발생하거나 변경 사항이 발생하는 경우에 거쳐야 할 전체적인 업무 프로세스

나.태스크

#표준 신규/변경 요청

-업무 담당자는 데이터 관리자에게 표준 단어, 표준 용어, 표준 도메인 등 데이터 표준 대상을 신규 또는 변경 요청

#표준 준수 검토

-요청된 사항에 대해서 데이터 관리는 요청된 사항에 대한 표준 준수 여부를 검토하고 검토 결과를 업무 담당자에게 피드백하며 준수 여부 체크시 요청한 용어가 해당 용어 설명에 부합하는지, 요청한 용어가 기존 용어의 의미와 중복되는지 여부를 체크

다.역할과 담당업무

#업무 담당자
- 표준 신규 및 변경 요청
- 데이터 관리자로부터 지시받은 변경 내용 적용

#데이터베이스 관리자
- 데이터 관리자로부터 변경 표준 사항에 대한 변경 영향 파악 협조 및 평가서 작성
- 데이터 관리자로부터 지시받은 변경 내용 적용
- 테스트 및 검증 

- 사용자 반영 결과 통보

#데이터 관리자
- 업무 담당자로부터 요청받은 신규 및 변경 사항 검토 및 표준 준수 여부 체크
- 변경영향도 분석 및 보고 후 변경 계획 수립
- 준수 여부 체크 후 메타 DB에 표준 등록
- 메타 DB에 등록 완료 후 신규 및 변경 표준 배포
- 업무 담당자 및 데이터베이스 관리자에게 변경 작업 지시 후 변경 작업 수행 결과 확인

#전사 데이터 관리자
- 전사 관점에서의 표준 가이드 자문 및 제시

 

#DA가 이뤄야할 3가지 통합성

-EA범위 전체에 대한 각 모델 내의 불일치성 제거

-관련된 타 도메인과의 불일치성 제거

-관련된 관점간의 불일치성 제거

 

 





 

맨 위로 이동

 

DAP 1장 전사아키텍처 이해

 

DAP 2장 데이터 요건 분석

 

DAP 4장 데이터 모델링

 

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

 

DAP 6장 데이터 품질 관리 이해

 

Posted by Lumasca
,

제1장 정보 요구 사항 개요

제1절 정보 요구 사항

제2절 정보 요구 사항 관리

 

제2장 정보 요구 사항 조사

제1절 정보 요구 사항 수집

제2절 정보 요구 사항 정리

제3절 정보 요구 사항 통합

 

제3장 정보 요구 사항 분석

제1절 분석 대상 정의

제2절 정보 요구 사항 상세화

제3절 정보 요구 사항 확인

 

제4장 정보 요구 사항 명세화

제1절 정보 요구 사항 명세 정의

제2절 정보 요구 사항 명세 상세화

 

제5장 정보 요구 사항 검증 및 변경 관리

제1절 정보 요구 사항 검증 정의

제2절 정보 요구 사항 상관분석 기법

제3절 추가 및 삭제 정보 요구 사항 도출

제4절 정보 요구 사항 변경 관리

 

제1장 정보 요구사항 개요

제1절 정보 요구 사항

가.정의

-정보 요구 사항이란 사용자가 일상적으로 수행하는 업무의 개선 사항이나 신규 개발 사항으로 시스템을 통해 기능상의 목적을 달성하기 위해 요청하는 내용

 

나.정보 요구사항 생명주기 모형

-정보요구사항 도출, 분석 및 정의, 명세화, 검증으로 구성

1)정보요구사항 도출

-사용자의 정보 요구 사항을 도출하는 단계로서 사용자 인터뷰, 설문서, 워크숍, 현행 시스템 분석 등을 통해 도출

2)정보요구사항 분석 및 정의

-사용자로부터 수집된 정보 요구 사항을 정리하고 방법론에서 제시하는 다양한 기법을 이용하여 분석해서 정보 요구 사항을 정의하는 단계

3)정보요구사항 명세화

-확정된 정보 요구 사항의 개별 사항에 대하여 세밀하게 분석하고 기록하는 단계

4)정보요구사항 검증

-사용자의 정보 요구 사항을 비즈니스 관점, 조직 관점, 애플리케이션 관점과 상관분석을 통해 누락 없이 반영되었는지를 검증하는 단계

 

다.정보 요구사항 유형

요구사항분류: 기능, 비기능(성능, 시스템장비구성, 인터페이스, 데이터, 테스트, 보안, 품질, 제약사항, 프로젝트관리, 프로젝트 지원), 기타(유지관리수행, 유지관리인력, 컨설팅, 공사)

 

-유형:외부/기능/성능/보안 요건

1)외부 인터페이스 요건

-시스템의 모든 입·출력에 관한 요건으로서 대외기관으로부터 수신 및 대외기관으로 송신하는 입출력 방식이 추가 및 변경되었을 경우와 각종 제도 및 기준 등이 변경되었을 경우에 발생하는 요건

#관리기준: 중복성, 표준준수도

중복성:기존에 동일한 형태의 인터페이스가 존재하는지 체크

표준준수도:인터페이스와 관련된 국제 표준 및 국가 표준이 존재할 경우, 그에 적합한 형태로 제공

#관리방법:항목 이름, 목적 설명, 입력의 원천 및 출력의 방향, 유효 범위, 시간, 다른 입/출력과의 관계, 데이터 포맷, 최종 메시지 등이 포함되어 관리

 

2)기능 개선 요건

-시스템에서 입력을 받아들여 처리하고 출력을 만들어 내는 주요 활동 및 프로세스에 대한 요건

#관리기준: 불가변성, 범용성

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

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

#관리방법

-입력에 대한 유효 체크, 정확한 처리 순서, 비정상 상태에 대한 반응(오버플로우, 통신 장비, 에러 처리), 매개변수의 기능, 출력과 입력의 관계, 입출력 순서, 입력을 출력으로 변환하는 공식 등이 포함되어 관리

 

3) 성능 개선 요건

-사용자가 원하는 성능 개선 사항으로는 동시 사용자 수, 처리하는 정보의 양과 종류, 트랜잭션 소요시간 등

#관리기준: 실현가능성, 측정가능성

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

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

#관리방법

-각 기관의 서비스 특성을 고려하여 정적, 동적 기준을 마련하고 해당 기준에 맞게 서비스되고 있는지를 모니터링 작업을 통해 항시 관리

 

4) 보안 개선 요건

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

#관리기준: 불가변성, 실현가능성

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

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

#관리방법

-가장 먼저 보안 관리가 필요한 정보에 대한 등급 관리가 필요하며, 해당 등급별로 접근 가능한 이용자 등급 관리가 필요하며 접근 통제 기준 및 사용 통제 기준 제시

제2절 정보 요구 사항 관리

가.정의 및 관리 목적

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

 

나.정보 요구사항 관리 프로세스

1)업무흐름 프로세스

요구사항 발송 사용자가 정보시스템을 활용하면서 발생하는 불편 사항이나 신규 개발 사항 등의 요건을 정보 요구 사항 정의서 양식에 기록하여 정보시스템 담당자에게 발송
요구사항 수렴 사용자로부터 접수한 정보 요구 사항 정의서를 수집하여 규칙에 맞게 정확하게 정의했는지 확인하고, 해당 요건을 검토할 처리 담당자를 지정하여 이송
요구사항 검토 요청된 정보 요구 사항과 관련된 자료 및 작성 기준, 구성요소, 원칙 등을 확인해서 반영 여부를 판단
영향도 분석 요청된 내역을 토대로 신규 개발 및 변경에 따른 영향이 얼마나 되며, 이로 인해 영향을 받는 설계서, 기존 애플리케이션, 데이터베이스 등을 파악
공식화 영향도 분석 후 관련되는 담당자를 소집하여 의견을 공유하고, 담당자들과의 협의를 통해 반영 유형을 결정
반영 작업 계획 수립 영향 분석 결과를 근거로 업무 영역 및 관련 담당자들과의 미팅 후 반영 계획을 수립




2)수행조직 및 수행 업무

#사용자

- 정보 요구 사항 정의 및 상세화
- 정보 요구 사항 변경 요청
- 정보 요구 사항 반영을 위한 미팅
- 정보 요구 사항 반영 여부 확인
- 미결 사항에 대한 의사결정 실시

#담당자

- 사용자 정보 요구 사항 접수
- 사용자 정보 요구사항에 대한 기본적인 검토
- 반영 여부 결정을 위한 사용자와 1차 미팅
- 접수 요건에 대한 처리 방식 및 처리 기한 결정
- 관련 부서별 담당자 수집 및 요건 협의 주도
- 사용자 정보 요구 사항 반영
- 테스트 및 검증
- 사용자 반영 결과 통보

#데이터아키텍처 전문가

- 사용자 정보 요구 사항에 대한 표준/데이터베이스/애플리케이션 차원에 대한 영향도 분석 및 보고
- 접수된 요구 사항에 대한 표준 준수 여부 체크
- 영향도 분석을 통한 수정 및 변경 계획 수립
- 표준 제시 및 준수 여부 검토

-요청사항 내용 중 미결 사항에 대한 검토

제2장 정보 요구 사항 조사

제1절 정보 요구 사항 수집

가.정보요구사항 수집 형태

-관련 문서 수집

-사용자 면담을 통한 수집

-워크샵을 통한 수집

-현행 업무 처리 매뉴얼을 통한 수집

-현행 정보시스템 관련 산출물을 통한 수집

 

*정보시스템 현황조사기법: 경쟁환경분석, SWOT분석, RAEW분석(책임,권한,전문능력,일)

 

나.관련문서 수집

-사용자및시스템관점의 정보요구사항수집시 소스문서: 현행시스템분석서, 현행 사용자 요구사항정리문서, 현행시스템개선과제 및 문제점 정리문서

-관련 문서에는 업종에 대한 이해에 도움이 되는 자료

-기업에 대한 전체적인 상황 이해시 도움이 되는 자료

-사용자가 업무 처리를 위해 참고로 하는 상세한 업무 매뉴얼, 

-업무 처리시 활용하는 정보 처리 매뉴얼, -정보시스템으로부터 산출되는 보고서 및 각종 장표, 

-처리 화면 등이 포함

 

1)문서수집 목적

-구현 시스템의 대상과 범위를 좀더 명확하게 정의하고 기업과 업종에 대해 잘 이해하기 위하여 업종, 경영 전략, 정보시스템 등에 대한 과거 실적 자료 및 향후 계획 등의 자료를 수집

2)문서수집 자료

-경영 계획에 대한 자료

-정보시스템에 대한 자료

-과거 수행한 컨설팅 보고서

-전산처리 업무 매뉴얼

-현업부서 업무 자료

3)문서 수집 원칙

-문서는 기존에 보유하고 있는 문서를 변경하지 않고 수집하고, 정보시스템에 대한 자료는 별도의 정리 양식을 이용하여 작성

-수집된 문서를 바탕으로 경영 및 정보시스템 현황에 대한 요약표를 작성하여 그 내용을 숙지

-수집된 문서들은 계획 수립 기간, 문서 관리자를 지정하여 운영

-유형별 문서를 향후 활용을 위하여 문서 분류 방식을 결정한 후에 일정한 장소에 보관

-수집된 문서는 통상 대외비의 성격이 강하므로 개인별로 보관하는 것을 통제하고 문서 보안 관리에 주의

 

다.사용자 면담

-면담은 분석가가 특정 관점에서의 업무 요건이나 업무 절차를 조사하기 위하여 일반적으로 한 명 (혹은 두 명)의 실무자와 대면하여 질의와 응답을 통해 정보를 수집하는 방법

1)사용자면담종류

면담조사방법

-개인면담: 일대일

-집단면담(워크샵): 일대다

-표준화면담: 동일 내용과 절차 반복

-비표준화면담: 질문 내용이나 순서가 변함

면담조사방식

-피라미드 구조: 구체적 선택형> 일반적 서술형 질문 진행

-퍼널구조: 일반적 서술형> 구체적 선택형 질문 진행

-다이아몬드 구조: 피라미드 + 퍼널

 

1)사용자 면담 진행

-계획및준비, 면담수행, 면담결과분석, 분석결과피드백

 

#계획 및 준비: 면담일정, 면담지침, 면담요지, 기록양식

*면담 주제 선정

-수행 대상 작업과 면담 대상자의 책임 수준에 따라 결정.
면담 대상자 및 대상 작업별 면담 주제에 따라 면담 요지를 작성

-질문 항목은 면담을 통해 얻고자 하는 것이 무엇인지를 명확히 선정

-면담의 취지, 목적, 수행 방법, 시간

-프로젝트의 개요: 목표, 범위, 기간, 조직

-업무의 향후 수행 방향에 대한 의견

-면담 대상자가 소속된 부서의 업무 현황 및 개선 요구 사항

-현재 사용하는 정보시스템에 관한 의견

-프로젝트에 관한 의견 : 요구 사항, 프로젝트 참여 방안 등

 

*전산 부서용 면담 요지
면담의 취지, 목적, 수행 방법, 시간 등
프로젝트의 개요 : 목표, 범위, 기간, 조직
기획 분야 현황 및 계획 : 전산 부서 조직 및 인력, 연혁, 계획, 문제점, 과제 등
시스템 분야 현황 및 계획 : 조직 및 인력, 시스템 구성, 네트워크 구성, 시스템 운영 절차, 향후 계획, 문제점 및 과제 등
애플리케이션 분야 현황 및 계획 : 조직 및 인력, 애플리케이션 구성, 데이터베이스 구성, 진행 중인 개발 업무, 개발 및 유지보수 계획, 문제점 및 과제 등

 

*면담 진행 팀 구성

-가능하면 2~3인으로 구성

-면담팀원간 역할 구분

-기록자나 관찰자는 사전에 업무를 습득

면담자
- 면담을 진행.
- 면담의 취지를 설명하고 면담 대상자에게 질문.

기록자
- 면담 대상자의 답변 내용을 기록.(요약말고 그대로)
- 면담 대상자의 답변 내용을 충분히 이해하고 기록하기 위하여 면담 대상 업무에 대한 사전 지식 보유.
- 면담 종료 시에 기록 내용 중 주요 사항(수치, 업무 분장 및 책임소재 조직 등에 대한 내용)을 확인.

관찰자
- 면담이 수행 의도대로 진행되고 있는가를 관찰.
- 면담이 주제의 범위를 벗어나면 주의 환기
- 면담자가 놓치는 부분에 대하여 보충 질문.
- 최종적으로 면담의 종료에 대해 판단.

 

*면담 대상자 선정

-수행 작업에 따라 면담 대상을 선정
-적절한 대상을 선택하기 위하여 전체 조직 구성도와 프로젝트 범위를 검토하고, 프로젝트 후원자나 사용자측으로부터 추천
-여러 명의 사용자나 조직들이 유사한 업무를 수행하고 있는 경우에는 차이점 파악을 위하여 해당 업무에 대하여 적어도 두 명 이상의 면담 대상자를 선정

 

*면담 일정 수립

-면담 실시가 공표되고 프로젝트 후원자의 지원을 얻은 후 선정된 면담 대상자들에게 프로젝트의 목적과 범위를 통보하고 사용 가능한 관련 문서 자료를 요청
-면담은 초기 단계에서 일정(전체 일정)이 정해져 있어야 하며, 면담 개시 최소 1주일 전에 면담 대상자별로 세부 일정을 확정
-면담 시간은 1.5시간(상위 관리자)에서 3시간(실무자)을 초과하지 않도록 하며, 필요시 집단 면담을 수행

*면담 준비

-면담 수행 전에 모든 이용 가능한 자료를 활용하여 면담 대상자가 담당하는 업무 활동을 검토
-면담 대상자의 업무에 대한 태도나 해당 업무 종사 기간, 경험 등을 알아두고 면담 시나리오를 준비
-도표를 이용할 경우 면담의 효율성 높음
-면담 수행 직전 30분 동안에는 수행될 면담에 관한 최종 준비 상황을 확인

 

2)면담: 핵심사항, 상세면담기록, 책임소재, 분석양식

#면담 시작

-면담 시작 30분 전에 다른 면담 진행팀과 함께 필요한 정보 요구와 진행 순서를 점검하고, 면담 진행팀원들 각자의 역할을 확인
-면담은 정시에 시작. 면담이 시작되면 면담자는 면담 대상자에게 면담 진행팀을 소개하고, 프로젝트의 목적, 범위, 일정 등을 먼저 설명한 후 면담의 목적과 주요 질문 및 진행 방식, 예정 시간, 면담 진행팀원들의 역할을 설명
-면담은 복수의 팀에서 수행될 수 있으므로 면담 진행팀들 간의 수행 방식을 통일하기 위하여 모든 절차가 면담 지침에 세세한 문구까지 모두 반영

 

#면담 주제 토의

-면담자는 준비된 면담 요지에 따라 면담을 진행하고 면담 내용은 모두 면담 기록지에 기록
-질문 시 개방적 질문을 사용하며 면담 주제나 질문지의 순서와 범위를 벗어나지 않도록 노력하고 대화의 흐름이 끊기지 않도록 주의
-기록자는 토의된 내용을 가능한 한 모두 기록
-모든 면담 결과의 후속 분석 작업을 위한 공통의 기준으로 사용될 수 있는 표준 기록 양식이 있어야함
-토의가 진행되는 동안 면담 대상자의 주요 책임 업무를 명확히 정의하고 면담 대상자의 각 업무가 시간과 같은 논리적인 순서에 따라 진행되는지를 확인

 

3)면담 결과 분석: 면담분석결과, 현안정보요구, 정보화과제

-면담 진행팀은 기록된 내용과 면담 중의 응답에 대한 개인적 의견을 고려하여 면담 결과를 정리

-기존의 업무 모델을 틀로서 사용할 수 있으나 현재 업무와의 사이에 발생하는 차이점에 주의하고, 가능하면 면담 대상자의 업무 용어를 사용

-의문 사항이나 추가 사항이 있으면 즉시 면담 대상자에게 확인을 하고, 필요한 경우에 추가 면담을 실시

 

4)분석 결과 피드백: 면담분석결과 승인

-별도의 정리 내용이 없거나, 필요한 경우 면담 기록지 내용 전체에 대하여 확인을 받을수 있음

-면담 대상자는 정리된 내용에 대한 수정 사항을 제시 가능

-일정상 개인별로 결과에 대한 피드백이 곤란한 경우에는 현업실무자 전원을 대상으로 워크숍을 진행 가능

 

4)면담 수행시 고려사항(시비기범 대응문선)

#면담 시간 준수

#비밀보장

#기대수준 설정

#면담 범위 준수

#적절한 대상자 선정

#응답 유도

#면담 내용 문서화

#잘못된 선입견의 배제

 

*질문법

-타이다운(Tie-down) 질문법: 어떤 사항에 대한 승인이나 동의, 사고, 현안점검 등에 대한 반응을 조사하는 질문

-대안진보: 선택사항을 제시하고 어떤 사실을 확인하는데 사용되는 질문

-포커핀/부메랑: 대안의 그래프가 포커핀과 유사하여 이름지어진 질문법, 부메랑은 어떤 질문에 대하여 응답하는 방식

 

다.워크숍

1)워크숍 개요 및 목적

-어떠한 목적을 달성하기 위하여 전문 진행자의 진행 아래 프로젝트의 현업 부서 측과 전산 부서 측의 주요 구성원들이 함께 참여하는 회의

-경영층 또는 현업 부서장의 공통된 의견을 도출.
-유사한 업무 또는 관련된 업무 등을 수행하는 부서에 대한 면담에 드는 노력을 절감
-전문가들의 판단력을 이용하여 최적의 결론을 도출

 

2)워크숍 준비

워크숍 과제 선정과 계획 수립

참가 대상자 선정

참가 대상자에 대한 사전 브리핑 및 교육 훈련

킥오프 모임 수행

워크숍 자료 준비

설비와 물품 준비

워크숍 장소 선정

워크숍 기간 선정 프로그램 준비

 

3)워크숍 수행

-워크숍 개시, 수행준비, 수행, 종료

#워크숍 개시

-워크숍의 시작을 알리고 간략한 인사말, 부수적인 항목들(휴게실 위치, 흡연구역 등)에 대해서 공지
-일정 확인

#워크숍 수행 준비

-워크숍의 목적과 접근방법의 개요를 설명.
-사용자로 하여금 워크숍의 목적을 재확인.
-워크숍 기간 동안 작업을 수행하기 위하여 필요한 기법들을 습득.

#워크숍 수행

-구체적인 워크숍 수행 방식은 형태나 특정 목적에 따라 다르게 수행
-워크숍의 목적에 맞게 진행될 수 있도록 조정하고 관찰
-세부적인 진행 방법 등은 기법을 이용

#워크숍 종료

-종료할 때는 진행 일정을 확인하고 진행사항을 요약
-워크숍 과정에서 도출된 요구 사항을 요약하고 책임자가 전체에게 공유하여 1차적으로 검토받음

 

라.현행 업무조사서

-업무조사는 전체 부서에 대하여 동일한 기준으로 조사

 

마.현행 프로그램/데이터 관련 문서

-현행 시스템에 대한 자료 수집은 향후 사용자 요구 사항을 좀더 세부적으로 진행하기 위한 사전 단계로서 반영되어야 할 현행 시스템의 업무요건을 빠짐없이 파악하기 위한 작업

-현행 시스템 프로세스(프로그램)의 구조

-현행 시스템의 데이터

-현행 데이터 저장소의 구조

 

바.관찰

-관찰하는 대상의 자료를 수집하는 귀납적 방법 피관찰자의 행동이나 태도를 살펴보는 행위

 

사.브레인스토밍

1)브레인스토밍 개요 및 목적

-창의적인 아이디어를 생산하기 위한 학습도구이자 회의기법

-원리: 판단보류, 가능한 많은 아이디어를 이끌어 낼 것

2)브레인스토밍 4가지 기본원칙

-양에 포커스를 맞추기

-비판, 비난 자제

-특이한 아이디어 환영

-아이디어 조합 및 개선

3)진행방법

-목적, 특징, 원칙, 진행방법 설명

-제한시간 정하고 시작

-아이디어는 게시하여 남의 아이디어로 더 참신한 아이디어 도출

 

아.프로토타이핑

-개발접근법의 하나로서 개발초기에 시스템의 모형을 간단히 만들어 사용자에게 보여 주고, 사용자가 정보시스템을 직접 사용해 보게 함으로써 기능의 추가, 변경 및 삭제 등을 요구하면 이를 즉각 반영하여 정보시스템 설계를 다시 하고 프로토타입을 재구축하는 과정을 사용자가 만족할 때까지 반복해나가면서 시스템을 개선시켜 나가는 방식

 

#프로토타이핑 4단계

-1단계: 사용자 요구사항 분석

-2단계: 프로토타입 개발

-3단계: 프로토타입 사용/보완 제안

-4단계: 프로토타입 수정/보완

 

제2절 정보 요구 사항 정리

가.정보 요구사항 정리

1)사용자 면담 정리

-사용자 면담 시 제공된 자료의 샘플이나 관련 문서를 체계적으로 정리 기록

2)업무 조사서 정리

-회사 차원에서 활용하는 업무 문서 및 팀에서 사용하는 업무 문서를 포함하여 전체 리스트를 파악 할 수 있도록 체계적인 양식으로 정리

#수행 중인 프로세스 목록

-대/중/소 분류별 프로세스명
-프로세스 설명 및 수행 빈도
-전산화 정도 / 전산화 필요성

#프로세스의 업무 흐름

-정보시스템을 포함하여 관련 부서 간의 업무 흐름을 시스템 흐름도 형태로 도식화

#타부서 또는 외부 기관으로부터 받은 문서

- 문서명 및 설명
- 접수 부서(기관)
- 접수 주기, 접수 수단
- 활용 형태 / 단위 문서량

#사용 중인 시스템

- 시스템명
- 사용 범위, 사용 방법, 사용 빈도
- 유용성
- 편리성

3)워크숍 정리

워크숍의 목적

워크숍 진행 내용

해결과제에 대한 상태

기타 특이사항

 

나.정보 요구 우선순위 분석

-사용자로부터 수집된 모든 정보 요구 사항을 전부 시스템에 반영할 수 없다면, 필요한 기법을 동원하여 우선순위를 부여하고 부여된 우선순위에 맞게 절차적으로 진행

 

1)화폐가치 산출방법

-최종적으로 구해진 가치가 높을수록 우선순위가 높음

-정보 요구 사항을 전부 나열

-정보 요구 사항에 대하여 기업 차원의 중요성을 평가하여 1점부터 3점까지의 점수를 부여

-정보 요구 사항에 대하여 시스템 차원의 중요성을 평가하여 1점부터 3점까지의 점수를 부여

-정보 요구 사항이 다른 정보 요구 사항에 대해 얼마나 도움을 주는가(상호관련성)를 평가하여 1점부터 5점까지의 점수를 부여

-앞서 부여한 세 가지 점수를 모두 곱함

-전체 정보 요구 사항에 대하여 앞서 계산된 점수를 더하고, 점수 합계를 100으로 하여 각각의 정보 요구 사항 가치를 백분율(%)로 환산

-회사 전체의 이익에 앞에서 구한 백분율을 곱하여 각각의 정보 요구 사항 가치를 금액으로 환산

 

2)상대적 중요도 산정 방법

-정보 요구 사항이 무엇을 지원하느냐에 따라 점수를 부여하고 이를 가중치에 따라 계산하여 중요도를 산정하는 방식

-정보 요구 사항이 업무에 기여하는 수준에 따라 1점부터 5점까지의 점수를 부여. 목적을 지원하면 5점, 목표를 지원하면 4점, 전략을 지원하면 3점 등의 방법으로 업무를 분류한 체계에 따라 결정

-정보 요구 사항 대 정보 요구 사항 매트릭스를 작성하여, 각각의 정보 요구 사항이 다른 정보 요구 사항에 얼마나 관련되어 있는가를 계산.
가장 관련이 큰 정보 요구 사항에 9점을 부여하고, 나머지 정보 요구사항에는 상대 점수를 부여

-정보시스템이 각각의 정보 요구 사항을 얼마나 충족하는가에 대하여 1점에서 3점까지의 점수를 부여. 만족스러운 경우에는 3점, 보통인 경우에는 2점, 지원하지 않는 경우에는 1점 등

-앞서 부여한 세가지 점수에 대하여 가중치를 결정. 예를 들어 업무 지원 정도는 50%, 다른 정보 요구 사항과의 관련도는 20%, 현행 시스템 지원 정도는 30% 등의 방법으로 정하되, 기업의 특성을 감안하여 결정.

-가중치에 따라 앞에서 계산한 세 가지 요인의 가중 평균을 구하여 각각의 정보 요구 사항에 대한 중요도를 평가.

 

제3절 정보 요구 사항 통합

가.정보요구사항 목록 검토

-전사 관점에서 동일한 정보 요구사항을 여러 부서 및 사용자가 제시했는지를 검토하기 위하여 별도의 양식으로 취합 조정한 후 중복 도출 여부를 검토

나.정보 요구사항 목록 통합/분할

-취합된 전체 정보 요구사항을 대상으로 최종 분석할 정보 요구사항을 도출

1)동일 부서 내 중복 요구사항 검토

-부서 내 정보 요구사항 목록을 작성.

-정보 요구사항 제목을 기준으로 부서 내 동일 요건의 요구사항 존재여부 파악.

-정보 요구사항의 세부 요청 내용을 기준으로 세밀하게 중복 여부를 파악

-부서 내 동일 요건이 도출된 경우 관리대상 요구사항에 통합할 정보 요구 번호를 ‘비고’란에 기입.

-동일 부서 내 중복성을 배재한 요구사항 목록을 완성.

 

2)서로 다른 부서간 중복 요구사항 검토

-부서 내 정리된 정보 요구사항 목록과 부서간에 동일한 정보 요구사항 존재여부 파악.

-정보 요구사항의 세부 내용을 세밀하게 검토하여 중복여부를 파악.

-부서 간에 동일 요건이 도출된 경우 관리 대상 요구사항에 통합할 정보 요구 번호를 기입하여 관리.

-최종적으로 전사 관점의 검토된 정보 요구사항 목록을 작성.

 

제3장 정보 요구사항 분석

제1절 분석 대상 정의

-사용자로부터 수집한 정보 요구 사항을 바탕으로 업무 현황을 파악. 이를 근간으로 관련 업무 및 시스템의 문서를 조사, 수집 및 파악함으로써 현행 업무 및 현행 시스템에 대한 분석 대상을 정의

 

가.현행 업무 분석 대상 정의

1)분석 대상 자료

-현행 업무 흐름도, 현행 업무 설명서, 현행 업무 분장 기술서

2)분석 대상 업무 영역 선정

-수집된 사용자의 정보 요구 사항을 바탕으로 현행의 업무흐름 및 관련 데이터를 파악하여 분류기준에 따라 분석 대상 현행 업무 목록을 작성

-작성된 분석 목록을 가지고 정보 요구 사항 분석을 위한 대상으로 선정할 것인지 결정을 하고 분석 대상 업무 목록표에 표기. 

-분류기준: 통상적으로 현행 업무 기능 분해도의 단위 업무 또는 업무분장상의 구분 등

 

나.현행 시스템 분석 대상 정의

1)분석 대상 현행 시스템 선정

-정리된 정보 요구 사항에 대해서 업무 영역별 분석 대상 현행 시스템을 선정하기 위하여 업무 영역/현행 시스템 매트릭스를 작성

-업무 영역/현행 시스템 매트릭스를 바탕으로 업무 영역별 분석 대상 시스템 목록을 작성

 

2)분석 대상 현행 시스템 관련 자료

-현행 시스템 구성도

-현행 시스템의 분석, 설계 및 개발 보고서

-화면, 장표 및 보고서 레이아웃

-현행 시스템 테이블 목록 및 테이블 정의서

-프로그램 목록

-사용자 및 운영자 지침서

-시스템 지원 및 유지보수 이력

-시스템 개선 요구 사항 등

 

*수집된 문서의 평가 기준(완유정효)

-유용성 : 문서의 활용 가능성 여부

-완전성 : 문서의 내용에 누락된 부분이 없는지의 여부

-정확성 : 문서의 내용이 현재의 시스템과 일치하는지의 여부

-유효성 : 문서가 최신의 내용을 반영하고 있는지의 여부

 

3)추가적인 분석 대상

-현행 데이터 측면의 업무 요건 혹은 업무 규칙을 보다 상세하게 분석하기 위하여 사용자 뷰도 분석 대상에 포함

제2절 정보 요구 사항 상세화

-정보 요구 사항 분석 대상이 정의된 현행 업무 영역 관련 자료 및 현행 시스템 관련 자료에 대하여 분석을 하고, 분석 결과인 분석 산출물을 토대로 사용자의 정보 요구 사항을 보완하고 비기능적 정보 요구사항을 포함하여 문서 작업을 통한 정보 요구사항정의서를 보완

 

#비기능적 정보 요구 사항

-시스템이 만족시켜야 하는 제약 조건(기술적 제약 조건, H/W, S/W와 관련된 제약 조건)

-시스템이 반드시 만족시켜야 하는 주요 성능 척도(반응 시간, 저장 능력, 동시 처리 능력)

-신뢰성, 확장성, 이식성, 보안

 

가.프로세스 관점의 정보 요구사항 상세화

1)수행절차

-프로세스 중심으로 정리된 프로세스 목록, 프로세스의 업무 흐름도 내용을 수반하는 업무 조사서를 바탕으로 프로세스계층도, 프로세스정의서를 작성.

-도출된 기본 프로세스를 기준으로 기본 프로세스에서 필요로 하는 정보 항목과 산출되는 정보 항목을 정리하고, 산출되는 정보 항목 중 기본 로직이 필요한 경우 기본 로직을 정리

-표준화 과정을 통하여 해당 정보 항목에 대해서 통합성/분리성 여부를 검토한 후 최종적으로 사용자의 정보 요구 사항을 충족하는 정보 항목 목록을 정의

 

2)수행 작업 내용

#프로세스 분해/상세화

-단위 업무 기능별 하향식으로 프로세스를 분해 및 도출
- 프로세스 계층도 및 프로세스 정의서를 작성

#정보 항목 도출 및 표준화

- 기본 프로세스별 정보 항목을 정리
- 정보 항목에 대한 표준화 정리
- 정보 항목 목록 정의

#정보 항목별 통합성, 분리성 여부 검토

- 프로세스별로 관리되는 정보 항목을 분류
- 정보 항목별 동음이의, 이음동의 존재 여부 파악
- 통합/분리 여부 검토 후 최종 정보 항목 목록 정의

 

기능정의와 하부프로세스를 분해하여 논리적으로 계층화할때 분석기법: 가치사슬, 전문성, 생명주기는 모두 기업의 본원적 활동과 지원활동을 분류하고 체계화.

 

3)수행 작업 지침

#프로세스 분해 / 상세화

*프로세스의 분해

-프로세스의 분해는 단위 업무 기능으로부터 출발하여 점진적으로 수행
-단위 업무 기능은 하위에 더 이상 업무 기능을 포함하지 않고, 프로세스만으로 구성된 업무 기능을 의미

-단위 업무 기능별로 상세하게 프로세스를 분해하지 않고, 해당 업무 영역의 전체 단위 업무 기능에 대하여 프로세스의 분해 수준을 맞추어 점진적으로 분해

-업무 기능 계층도가 단위 업무 기능 수준까지 분해되지 않았을 경우에는 단위 업무 기능 수준까지 더 분해한 후 프로세스를 도출

 

*프로세스 분해 깊이

-프로세스 분해시 업무적인 특성을 고려하여 분해의 수준은 3차 수준까지 분해

-3차 수준까지 프로세스를 도출하는 과정에서 기본 프로세스 수준까지 도출되는 경우도 있음

-대상 범위의 모든 프로세스를 균형 있게 분해

-도출할 프로세스의 대상은 일반적으로 데이터의 상태를 변화시키는(생성, 수정, 삭제) 것만을 프로세스로 정의

 

*프로세스 명칭

-명명규칙을 준수하여 명명하되 업무 용어를 그대로 사용하고 이름만으로도 개략적인 수행 내용의 파악이 가능하도록 함축적이며 유일한 이름을 부여

*프로세스 계층도

-프로세스 계층도를 작성하는 목적이 기본 프로세스의 도출

-프로세스 계층도는 높은 응집도 및 낮은 결합도를 유지하도록 모듈성을 확보

-프로세스정의서(설명)는 업무를 구체적으로 이해할 수 있는 수준으로 상세하게 작성. 기본 프로세스의 경우에는 반드시 작성

-작성된 프로세스 계층도를 재검토해 해당 업무 영역에 포함되는 모든 업무 요건 및 업무 규칙이 반영되었는지 확인하고, 프로세스 계층도를 조정

-현 수준의 프로세스 계층도를 더욱 상세하게 분해하여 업무의 최소 단위인 기본 프로세스까지 도출

 

#정보 항목 도출 및 표준화

-프로세스 분해 및 상세화에서 도출한 기본 프로세스별로 등록(C), 조회(R), 변경(U), 삭제(D) 기능을 구분하여 기술

-기능에 따라 구분된 프로세스별로 정보 요구 분석에서 정의된 정보 요구 사항 정의서 및 업무 조사서 상의 내용을 파악하여 관리하고자 하는 정보 항목을 도출

-도출한 정보 항목은 명명규칙을 준수하여 명명하되, 업무 용어를 그대로 사용하며, 명사형으로 기술

 

#정보 항목별 통합성 검증

-정보 유형별 및 정보 항목별로 전사 관점에서의 통합/분리여부를 검토

*동일한 정보 항목에 대해서 통합시 장점

- 통합 정보 항목으로 도출 시 정보 항목의 관리가 용이함

- 동일한 유형의 정보 항목이 존재 시 통합 정보 유형으로 수용 가능

*단점

- 무리한 통합 작업으로 인한 정보 항목의 애매모호성 존재

-통합 정보 항목에 대한 관리 부족으로 통합의 의미 상실 가능성 존재

통합 작업 후 해당 정보 항목 목록에 대한 통합성 여부를 기재하고 최종 정보 항목 목록을 작성

 

나.객체지향 관점의  정보 요구사항 상세화

-객체지향 방법론에서는 유즈케이스 다이어그램을 중심으로 정보시스템의 기능적 정보 요구 사항을 정의

1)유스케이스 다이어그램

액터(ACTOR)

정보시스템과 상호작용하는 개인, 그룹, 회사, 조직, 장비 등 정보 서비스를 받는 객체

엑터의 이름은 명확하게 액터의 역할을 나타내는 이름으로 정의

유스케이스(USECASE)

도출된 액터별로 개발 시스템에서 제공해야 하는 기능

사건 흐름에 대한 개요를 간략하게 기술

액터(ACTOR)와 유스케이스 간의 관계

-확장(Extend) : 하나의 유즈케이스가 다른 유즈케이스의 행동을 추가함에 따라 나타나는 두 유즈케이스의 관계. 하나의 유스케이스가 다른 유스케이스를 경우에 따라 선택적으로 수행되는 경우에 사용.

-포함(Include) : 하나의 유스케이스가 다른 유스케이스를 사용함을 나타내는 두 유스케이스의 관계. 하나의 유스케이스가 다른 유스케이스를 반드시 수행하는 경우에 사용

-Communicates : 행위자가 어떤 유즈케이스에 참가함을 나타냄. 이것은 행위자와 유스케이스 사이의 유일한 관계

 

2)유스케이스 상세화

-유즈케이스의 사건 흐름을 구조화하는 작업으로 모든 선택 또는 대안 흐름을 기술

-유스케이스에 대한 개략적인 설명

-사건 흐름(Flow or Event)

-사전, 사후 조건

-비기능 정보 요구 사항

-주된 사건 흐름에 대체될 수 있는 대안 흐름

-예외 처리 사항

 

3)클래스 다이어그램 작성

#엔티티 클래스 도출

-유즈케이스 모형을 검토하여 문제 영역 내의 개념을 나타내는 엔터티 클래스를 도출하여 정의

-유즈케이스 다이어그램을 조사하여 명사 및 명사구를 후보 객체로 선정

-의미가 모호한 것은 제거

-이음동의어 및 동음이의어를 고려하여 선정

-문제 영역과 관련이 없는 것은 제거

-유사한 구조와 행위를 가진 객체들을 클래스로 그룹핑

 

#관계 도출 및 클래스 도출

-관계란 의미있고 관심있는 연결을 나타내는 클래스간의 관계. 클래스간의 집단화 관계를 식별하고 명명

 

#속성 정의

-속성이란 클래스가 나타내는 객체의 특성. 유즈케이스 다이어그램을 검토하여 클래스를 구성하는 속성을 도출

 

제3절 정보 요구 사항 확인

-사용자 및 부서로부터 접수해서 최종적으로 작성된 산출물에 대해 정보 요구 사항을 제시한 담당자와 세부 재검토를 통하여 누락 사항 및 보완 사항을 도출하기 위한 계획을 수립하고 재검토를 실시

 

가.수행절차

-분석 결과 도출된 산출물에 대해서 재검토 기준을 정의하고, 재검토 계획 수립

-재검토 대상 산출물의 완전성, 정확성, 일관성, 안정성 등 다양한 측면에서 재검토를 실시

-재검토 결과, 추가 및 보완 사항이 존재하는 경우에 내용을 문서로 정리한 후 해당 산출물에 추가 반영 여부를 확인하고, 미반영시 미반영 사유의 타당성을 검토

 

나.수행작업 내용

#재검토 계획 수립
-재검토의 대상이 되는 분석 결과 및 정보 요구 사항 정의서 산출물 확인
- 대상 산출물별로 재검토 기준(체크리스트) 정의

#재검토 실시
- 재검토 계획서 작성 및 승인
- 재검토 대상 산출물 준비 및 배포와 재검토 담당자별 역할 분담
- 업무 영역별로 재검토 대상 산출물을 재검토

#보완 결과 확인
- 재검토 결과를 토대로 업무 영역별로 산출물 보완
- 재검토 결과 반영 여부 확인 및 미반영 사유 검토
- 정보 요구 사항 정의서의 안정성 분석
- 재검토 결과를 토대로 보완 목록 수정

 

다.수행작업 지침

1)재검토 계획 수립

-재검토 대상이 되는 분석 결과 산출물을 확인

#검증기준(완정일안)

-완전성: 사용자의 정보 요구 사항이 누락없이 모두 정의되었는지 확인

-정확성: 사용자의 정보 요구 사항이 정확히 표현되었는지의 여부

-일관성: 표준화 준수 여부 확인

-안정성: 추가 정보 요구 사항 변경에 따른 영향도 파악

 

#재검토 계획서에 포함되어야 할 사항

-정보 요구 사항 재검토 개요 및 목적

-재검토 일자

-재검토 장소 및 시간 계획

-재검토 참석 대상 및 재검토 업무

-참석 대상별 재검토 세부 시간 계획

-재검토 준비물

-재검토 후 산출물

-재검토 후 지적사항 반영 계획 수립

 

2)재검토 실시

-재검토 기준 및 재검토 대상 산출물을 준비하고 재검토에 참여할 대상자에게 배포

-재검토 관련 장소, 시간, 준비 장비 등 재검토를 실시하기 위한 제반 준비를 수행하며, 재검토 담당자별로 재검토 세션에서 수행해야 할 역할을 충분히 주지시킴

-재검토 세션 실시 이전에 반드시 배포된 산출물을 예습. 실제 재검토 세션에서의 재검토는 재검토한 결과를 토대로 의문사항, 잘못 정의된 사항 등에 대하여 의견을 개진하고 결론을 도출하여 반영 대상을 정리.

-재검토시 진행자는 제기되는 이슈에 대해서 참석자들간에 결론을 도출하기 위한 토론이 발생하지 않도록 이슈 목록으로 정리

-재검토시에는 통합성 검증을 위하여 해당 업무 영역과 관련 있는 업무 영역 담당자가 참여

-재검토는 많은 인원이 함께 작업을 수행하는 경우에, 진행시간이 초과되어 충분한 검증이 이루어지지 못할 수도 있으므로, 진행자는 세션별로 적절한 시간 배분 및 조정

-재검토 세션이 종료되면 세션별로 그 결과를 재검토 결과로 정리

 

3)보완 결과 확인

-재검토 준비와 마찬가지로 보완 결과에 대한 확인 준비. 

-재검토 결과, 보완 목록, 보완 사항이 반영된 정보 요구 사항 정의서를 준비하고 배포

-보완 목록에 준하여 정보 요구 사항 정의서 반영 여부 확인.
-검토 결과 미반영 사유가 업무 규칙이나 정책의 변경을 수반하는 경우에 프로젝트 기간 내에 해결 가능한 것은 개선과제로 정리하여 해당 부서에 의뢰

-보완 목록에 있는 보완 사항이 모델에 모두 반영된 것을 확인하면 본 작업은 종료

 

라.재검토 수행시 고려사항

-일관성 있는 기준 및 명확한 일정을 수립함으로써 모든 참여 인력에 공감대를 형성하는 것이 중요

-재검토는 한번으로 종료되지 않는 것이 보통이므로 두번 이상을 진행하되 세션마다 재검토 기준을 명확히 하여 해당 기준에 초점을 맞추어 수행

-재검토 세션을 수행시 세션 진행의 효율성을 감안하여 적정한 참여 대상을 선정

 

제4장 정보 요구 사항 명세화

제1절 정보 요구 사항 명세 정의

1.정보요구사항명세정의

-정보요구분석명세서는 분석가가 작성하지만 쉽지 않음

2.요구분석명세서작성시 주의사항

-사용자가 쉽게 읽고 이해할 수 있도록 작성

-개발자가 설계와 코딩에 효과적으로 사용할 수 있도록 작성

-비기능적 요구를 명확히 작성

-테스트 기준 용도로 사용할 수 있도록 정량적으로 작성

-품질에 대한 우선순위 명시

 

제2절 정보 요구 사항 명세 상세화

1.요구사항 상세내역 작성

고유번호, 명칭, 분류, 상세설명(정의, 세부내용), 산출정보, 관련요구사항, 요구사항출처

 

2.요구사항 상세내역 작성시 고려사항

-초기 자료구축 및 데이터 이관을 위해서는 데이터의 자료명, 자료내용, 자료의 크기, 건수*주기, 보존기한,예상 자료량, 자료형태, 자료 위치 등을 파악

-대상자료 중 지적재산권 및 보안과 관련된 문제가 수반되는 부분에 대해서 구축 가능 여부를 확인하고, 데이터 전환 시 수행 시간, 데이터 표준화 등 제약사항이 존재하는지 파악

-데이터 요구 사항과 기능 요구 사항 사이에는 추적관리가 되어야 함

제5장 정보 요구 사항 검증 및 변경 관리

제1절 정보요구사항 검증 정의

#요구사항검증활동

-요구사항명세서 검토

-요구사항 용어 검증: 일관성,표준성,이해용이성

-요구사항 베이스라인 설정: 공식검토, 승인

제2절 정보 요구 사항 상관분석 기법

-도출된 정보 요구 사항을 다른 영역(기능, 프로세스, 조직 등)과 비교 분석함으로써 정보 요구 사항의 도출이 완전하게 효과적으로 이루어졌는지를 파악

 

가.주체별 분류

1)요구사항 분석가 수행

-정보 요구 사항을 수집하고 분석한 주 담당자를 기준으로 검토 기준 항목을 마련하고 상관분석을 수행하는 방법

-정보 요구 사항을 도출한 분석가에 의해 수행되므로 자체 분석에 의한 객관성 저하의 문제점 발생가능

-정보 요구 사항의 도출 절차 및 관련 업무팀과의 의사소통이 원활하므로 상관분석에 추가 인력의 투입 없이 원활하게 진행

-요구 사항 분석가의 업무에 대한 이해도가 높으므로 상관분석을 통한 정확한 업무의 분석 가능성이 높음

2)품질보증팀 수행

-프로젝트팀 내의 통합 검토팀이나 품질보증팀의 협조를 얻어 도출된 정보 요구 사항의 상관분석을 수행

-요구 사항 분석가보다 업무에 대한 이해도가 낮으나 상관분석 작업의 수행을 통한 업무 이해도를 높일 수 있으며 전체적인 인터페이스의 검증에 용이

-낮은 업무의 이해도로 인해 일부 사안에 대한 정확한 분석을 통해 단점을 지적하여 수정하기 어려움.

3)외부 감리 수행

-외부 감리 인력을 이용한 정보 요구 사항 상관분석을 수행

-업무 파악의 한계가 있으나 제 3자의 시각으로 검토

-프로젝트 내부 인력이 효과적으로 지원하지 않을 경우 상황에 맞지 않는 분석 결과를 초래

-상관분석의 객관성 극대화

 

나.정보 요구/애플리케이션 상관분석

-정보 요구 사항을 바탕으로 도출된 정보 항목을 애플리케이션 아키텍처에서 정의된 프로세스 모델과 비교하여 상호간의 일관성을 확보하고 품질 수준을 향상시키는 동시에 누락 혹은 중복된 정보 요구 사항을 점검

-정보 요구/애플리케이션 상관분석을 위해 정보 요구 사항을 바탕으로 도출된 정보 항목들과 애플리케이션 영역에서 도출한 기본 프로세스를 사용하여 매트릭스를 작성

-매트릭스 분석은 기본 프로세스와 정보 요구 사항을 기반으로 기본 프로세스의 액션 (C: 생성, R: 조회, U: 수정, D: 삭제)을 빠짐없이 정의

-매트릭스의 각 셀에는 기본 프로세스가 사용하는 정보 항목에 대한 액션이 생성(C), 조회(R), 수정(U), 삭제(D)로 표현되는데, 복수의 액션이 발생할 경우에는 C > D > U > R의 우선순위에 따라 하나만 기록

-모든 정보 항목이 모든 기본 프로세스에서 사용되었는지 혹은 모든 정보 항목을 사용하고 있는지 확인

-정보 요구/애플리케이션 상관분석 매트릭스는 두 가지 객체 중에서 한가지가 누락되거나 잘못 정의된 경우에는 분석이 가능하지만 정보 항목과 기본 프로세스가 모두 누락된 경우에는 분석이 불가능. 사전확인 필요

 

다.정보 요구/업무 기능 상관분석

-정보 요구 사항을 바탕으로 도출된 정보 항목을 비즈니스 아키텍처에서 도출된 업무 기능과 비교하여 상호 간의 일관성을 확보하고 품질수준을 향상시키는 동시에 누락 및 중복된 정보 요구 사항을 점검

-가치 사슬 분석 등의 기법을 통해 도출된 최하위 수준의 전사 업무 기능을 도출하고 이렇게 도출된 업무 기능을 매트릭스의 열에 배치

-정보 요구 사항에 따라 도출된 정보 항목을 매트릭스의 행에 배치

-업무 기능과 정보 항목 간의 상호작용을 정의. C(Create, Change), U(Use)

 

라.정보 요구/조직 기능 상관분석

-정보 요구 사항을 바탕으로 도출된 정보 항목을 비즈니스 아키텍처에서 도출된 조직 단위와의 매트릭스 분석을 통해 정보 항목의 생성 주체 및 활용 부서의 매핑이 가능

-조직 단위명은 기업의 조직도에 나타난 순서로 입력

-정보 요구 사항에 따라 도출된 정보 항목을 매트릭스의 행에 배치

-조직과 정보 항목 간의 상호작용을 정의. C(Create, Change), U(Use)

 

제3절 3추가 및 삭제 정보 요구 사항 도출

가.정보 요구/애플리케이션 상관분석

1)애플리케이션 충족도 분석 매트릭스

#점검 기준

-정보 요구 사항에 따라 발생하는 정보 항목을 생성하는 기본 프로세스가 반드시 존재

-정보 항목의 상태를 종료시키는 기본 프로세스가 존재

-생성된 정보 항목은 조회, 수정, 삭제 액션 중 하나가 발생

-하나의 정보 항목을 생성, 수정, 삭제하는 프로세스의 합은 7개를 초과하지 않는 것이 보통. 이를 초과하는 경우에는 올바르게 정의되었는지를 확인

-수작업으로 정의하거나 조회 전용으로 특별히 정의된 기본 프로세스를 제외한 나머지의 기본 프로세스는 반드시 생성, 수정, 삭제 액션 중의 하나를 수행

 

2)매트릭스 분석

점검내용 분석결과 조치사항
기본 프로세스가 사용 (CRUD)하는 정보 항목이 없음 정보항목 누락 정보항목 도출
기본프로세스 필요없음 기본 프로세스 삭제
기본 프로세스가 분석 대상 업무 영역에 속하지 않음 해당업무영역으로 이동
정보 항목이 7개 이상의 기본 프로세스에서 사용됨 정보항목이 너무 큼 정보항목 세분화
정보 항목을 생성하는 기본 프로세스가 없음 기본프로세스의 누락 기본프로세스 도출
정보항목이 필요없음 정보항목삭제
기본 프로세스가 분석 대상 업무 영역에 속하지 않음 해당업무영역으로 이동
정보 항목을 생성하는 기본 프로세스가 둘 이상 존재 기본 프로세스 중복 기본프로세스 통합
정보 항목을 삭제하는 기본 프로세스가 없음 기본프로세스 누락 기본프로세스도출
업무에 삭제가 존재하지 않음 전산오류시 삭제가 필요한지 확인
기본 프로세스가 분석 대상 업무 영역에 속하지 않음 해당업무영역으로 이동
정보 항목을 삭제하는 기본 프로세스가 둘 이상 존재 기본 프로세스 중복 기본프로세스 통합
정보 항목이 생성만 되고 사용되는 곳이 없음 기본 프로세스 누락 기본프로세스 도출
기본 프로세스가 정보 항목을 조회만 기본 프로세스가 아님 모듈검토
기본 프로세스가 여러 액션을 수행함 정의된 기본 프로세스가 너무 큼 프로세스 추가분해

 

나.정보 요구/업무 기능 상관 분석

#매트릭스 분석

-모든 업무 기능은 정보 항목과 연관이 있는가?

-각 정보 항목은 적어도 한번 이상의‘C’를 갖는가?

-생성된 정보 항목은 다른 업무 기능에 의해 사용( ‘U’)되는가? 이것은 정말 단순조회인가?

#정보 항목과 연관성이 없는 업무 기능은 관련 팀과의 협의 하에 업무 기능 도출의 적절성이나 관련 정보 항목을 다시 파악하고, 이를 바탕으로 매트릭스를 보완

#정보 항목에 매핑이 없는 업무 기능의 경우 관련 팀과 협의하여 정보 요구 사항 보유 여부를 확인한 후 추가적인 정보 요구 사항이 있을 경우 정보 요구 조사 프로세스에 따라 정보 요구 목록에 신규로 추가

 

다.정보 요구/조직 기능 상관분석

#매트릭스 분석

모든 업무 기능은 정보 항목과 연관이 있는가?

각 정보 항목은 적어도 한번 이상의‘C’를 갖는가?

생성된 정보 항목은 다른 업무 기능에 의해 사용( ‘U’)되는가? 이것은 정말 단순조회인가?

#정보 항목의 활용도를 파악할 수 있으며, 정보 항목의 수요가 많은 경우에는 해당 정보 항목의 물리 모델링 단계에 성능/활용 측면의 모델링 기법을 적용함으로써 정보 활용의 효율성 확보

#정보 항목을 생성하는 조직 단위가 복수로 존재할 경우 데이터 관리의 복잡성으로 인해 향후 문제가 발생할 수 있으므로 해당 정보 항목에 대한 데이터 관리 주체의 선정에 주의

제4절 정보요구사항 변경 관리

-프로젝트 진행과정에서 발생하는 요구사항 변경에 대하여 일치성과 무결성을 제공하기 위하여 변경제어와 추적등의 활동을 수행

-요구사항 변경제어: 비용, 일정 등에 따라 변경 식별 및 평가, 제어 및 재설정

-요구사항 추적제어: 요구사항변경에 영향을 받는 요구사항 추적

-요구사항 버전제어: 형상관리 기반으로 요구사항 명세 베이스라인과 요구사항 관리공정 전과정에 걸쳐 축적된 모든 요구사항 정보를 관리

 

1.요구사항 추적

 

2.요구사항 변경요청

-고객이나 사용자, 외부환경의 원인에 의해 발생

-변경요청서를 작성

 

3.변경 영향분석

-변경요청서에 영향분석 기록

 

4.변경 승인/기각

-변경통제위원회(CCB)는 발주자측 사업책임자와 사업자측 PM이 함께 협의하여 수용여부를 최종 결정

-양측간 대립으로 결정이 불가한 경우, 상위 의사결정위원회가 결정

 

맨 위로 이동

 

DAP 1장 전사아키텍처 이해

 

DAP 3장 데이터 표준화

 

DAP 4장 데이터 모델링

 

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

 

DAP 6장 데이터 품질 관리 이해

 

Posted by Lumasca
,

제1장 전사아키텍처 개요

제1절 전사아키텍처 정의

제2절 전사아키텍처 프레임워크

제3절 전사아키텍처 참조 모델

제4절 전사아키텍처 프로세스

 

제2장 전사아키텍처 구축

제1절 전사아키텍처 방향 수립

제2절 전사아키텍처 정보 구성 정의

제3절 전사아키텍처 정보 구축

 

제3장 전사아키텍처 관리 및 활용

제1절 전사아키텍처 관리 체계

제2절 전사아키텍처 관리 시스템

제3절 전사아키텍처 활용

 

 

제1장 전사아키텍처의 개요

제1절 전사아키텍처 정의

가.전사아키텍처 개념

1)전사아키텍처 도입배경

2)전사아키텍처 정의

-기업의 목표와 요구를 잘 지원하기 위해 IT 인프라의 각 부분들이 어떻게 구성되고 작동되어야 하는가를 체계적으로 기술하는 것

-복잡한 기업의 모습을 다양한 측면(비즈니스, 데이터, 애플리케이션, 기술)에서 분석하고 표현하여 이해하기 쉽도록 정보체계를 구축하고 이를 활용하는 것

-EA도입은 IT에 대한 혁신과 관리*통제를 포함하며 시스템의 도입,구축,운영,평가 등을 통합적으로 관리하는 것

-IT와 업무간의 연계뿐만 아니라 현재의 모습과 미래의 모습을 포함

 

#EA의 목적(실제 목적은 다를 수 있음)

- IT투자대비효과 최대화 

-기업의 목적을 잘 달성할 수 있는 방식으로 IT인프라 구성

-비즈니스민첩성

-IT효율성제고

-비즈니스와IT연계

-IT통합성, 상호운용성 제고

 

#EA의 중요성

-기업이나 조직의 경영전략 내지 비즈니스 목표를 달성하기 위한 방향 제시

-정보시스템이나 정보기술체계의 나아갈 방향을 알려주고 모든 구성원이 동일한 모습으로 그 내용을 인식할 수 있도록하여 의사소통의 매개체

-정보시스템이 갖추어야할 품질속성을 정의하고 실현에 도움

-정보시스템이나 정보기술체계의 복잡도를 잘 표현하여 이해관계자의 이해에 도움

 

#EA 기대효과

-정보관리 역량 강화

-의사결정의 정확성과 신속성 제고

-변화에 대한 유연한 대응과 비용절감

-새로운 서비스나 기능 도입에 대해 최적의 대응

 

3)전사개념

-일반적으로 기업 또는 기관을 지칭

-공동의 목표를 추구하기 위해 고객과 상품 또는 서비스가 존재하고 이를 지원하기 위한 조직, 자원, 기술을 보유하며 필요한 업무 프로세스를 수행하는 조직의 집합체

-하나의 기업이나 기관과 정확히 일치하지 않음

-큰기업은 여러 개의 전사로 구성가능, 각각의 전사는 독립적인 운영주체로 구성, 다수의 사업영역으로 구성

-EA수립에 관련된 모든 활동은 정의된 전사의 성과와 목표에 초점

-전사의 범위는 해당 기업 및 기관 뿐만 아니라 기업 및 기관을 둘러싸고 있는 외부객체와의 역학관계를 반드시 고려

-전사는 계층구조 가능

-자회사를 보유하고 있는 모기업의 경우, 전체 그룹사를 전사의 범위로 선정하여 통합적인 EA 프레임워크를 적용가능

 

4)아키텍처 개념

-구성요소의 구조, 구성요소들 사이의 관계, 구성요소의 설계 그리고 시간경과에 따른 구성요소의 발전을 위한 원리와 지침

 

#EA 구성요소

규칙: 전략, 원칙/지침, 표준

모델: BA, AA, DA, TA, 참조모델

계획: 이행계획, 구축계획

 

나.전사아키텍처 추진현황

다.전사아키텍처 관련 DA 역할

-기업이 필요로 하는 고품질의 데이터 모델 또는 데이터아키텍처를 정의

-EA프로젝트의 데이터 아키텍처 정의 담당자로 참여

-구축된 EA원칙과 정보를 준수 및 활용해야 하고, 담당하고 있는 데이터 모델의 변경정보를 EA정보에 반영

-EA프로젝트가 진행되지 않더라도 필요시에 데이터 부문만의 아키텍처 정립 작업을 수행

 



제2절 전사아키텍처 프레임워크

가.전사아키텍처 프레임워크 개념

-전사아키텍처 활동에서 얻어지는 산출물을 분류하고 조직화하고 이를 유지 관리하기 위한 전체적인 틀을 정의하는 것

 

나.전사아키텍처 프레임워크 구성

-구성: EA정책/정보/관리 (기업의 도입목적에 따라 다름)

 

전사아키텍처 정책 기업이 전사아키텍처 수립을 어떻게 할 것인가의 방향을 정의한 것
아키텍처 매트릭스, 전사아키텍처 비전, 전사아키텍처 원칙 등으로 구성
전사아키텍처 정보 기업이 구축하는 전사아키텍처 정보의 구체적인 모습
ASIS 아키텍처, TOBE 아키텍처, 이행계획으로 구성
전사아키텍처 관리 구축된 전사아키텍처를 어떻게 관리하고 활용할 것인가를 정의한 것
전사아키텍처 관리체계, 전사아키텍처 관리시스템, 전사아키텍처 평가 등으로 구성

 

1)전사아키텍처 정책

-기업이 전사아키텍처 수립을 어떻게 할 것인가의 방향을 정의

#아키텍처 매트릭스

-EA의 정보를 체계적으로 분류한 틀

-기업이 관리하려고 하는 EA정보의 수준과 활용계층의 분류를 통해 결정

-아키텍처 정보를 분류하는 차원은 기업의 특성에 맞게 임의로 조정가능

-아키텍처 도메인(View) 구성은 기업이 아키텍처 매트릭스를 어떻게 정의하느냐에 따라 달라짐

-View: 비즈니스, 애플리케이션, 데이터, 기술

-관점: 계획자(개괄), 책임자/분석가(개념), 설계자(논리), 개발자(물리)

관점\뷰 BA AA DA TA
계획자(개괄적) 전체업무, 조직의 구성정보 전체 자원의 응용 시스템 구성정보 전체 자원의 데이터베이스 구성정보 기술요소의 구성을 전체자원에서 정리한 정보
-전사사업모델
-조직모델
-비즈니스전략
-전사 애플리케이션 영역모델
-애플리케이션 원칙
-전사 데이터 영역모델
-데이터 원칙
-전사기술 영역모델
-기술 참조모델
책임자/분석가(개념적) 업무의 세부 구성정보와 업무/조직간 관계정보 상위수준의 기능 구성정보와 응용시스템간 관계정보 데이터베이스의 주요 데이터개체와 개체간 관계 정보기술기반 자원의 유형별 구성과 인터페이스 정보
-업무 기능정보 -애플리케이션 모델
-애플리케이션 표준
-개념데이터 모델
-데이터 표준
-표준 프로파일
설계자(논리적) 업무의 연계성, 흐름정보 응용 시스템의 상세한 기능정보와 물리적 분산정보 데이터베이스의 논리적 데이터 구조 기술기반자원의 도입과 운영을 위한 유형별 구조 및 관리체계 정보
-프로세스 모델 -컴포넌트 모델 -논리 데이터 모델 -기술아키텍처 모델
개발자(물리적) 업무 수행을 위한 구체적 절차, 양식, 업무 관계정보 프로그램의 물리적인 구성체계와 각 프로그램 구현정보 데이터베이스의 물리적 구조정보 도입된 기술기반 자원의 도입,운영,관리에 관한 구체적 정보
-업무 매뉴얼 -프로그램 목록 -물리데이터모델
-DB객체
-기술자원목록
-제품 목록



#EA 비전

- 전사아키텍처 수립을 통하여 기업이 궁극적으로 달성하고자 하는 모습

-EA 구축의 목표와, 그 목표를 효과적으로 달성하기 위한 전략과 방향 등을 포함

# EA원칙

-전사아키텍처 정보를 효율적으로 구축하고, 기업의 목적에 맞게 전사아키텍처 정보를 효과적으로 활용하기 위해서 조직 구성원이 공유해야 할 규범

 

2)전사아키텍처 정보

-기업이 구축하는 전사아키텍처 정보의 구체적인 모습

#현행(ASIS) 아키텍처

-아키텍처 도메인별로 정의된 산출물에 대하여 기업의 현재 상태를 아키텍처 정보로 정의

#목표(TOBE) 아키텍처

-아키텍처 도메인별로 정의된 산출물에 대하여 기업이 궁극적으로 달성하고자 하는 목표 아키텍처의 상태를 아키텍처 정보로 정의

#전사아키텍처 이행계획

아키텍처 도메인별로 현재 모습에서 바람직한 목표 모습으로 이행하기 위한 이행 전략과 이행계획을 정의

 

3)EA 관리

-구축된 전사아키텍처를 어떻게 관리하고 활용할 것인가를 정의

#EA관리체계

-EA거버넌스. 구축된 전사 아키텍처를 유지하고 개선하기 위한 제도적 기반을 수립

#EA 관리시스템(EAMS)

-정보 관리의 효율성을 제고하고 전사아키텍처 정보의 공유를 활성화하기 위해 구축하는 정보시스템

#EA평가(성숙도모형)

-전사아키텍처의 관리와 활용 수준의 제고를 위해서는 전사아키텍처에 대해 주기적으로 평가하고 개선점을 도출하여 반영

 

다.아키텍처 도메인 구성

-비즈니스, 애플리케이션, 데이터, 기술

1)BA

-기업이나 조직의 경영목표를 달성하기 위한 업무구조를 정의한 아키텍처.

-기업의 업무와 서비스의 실체를 명확화

-기업의 사업 모델과 업무 기능을 정의

#전사사업모델(계획자)

전사를 둘러싼 내외부의 이해관계자를 분석, 외부 객체와의 가치사슬을 분석하여 전사 정의

#조직모델(계획자)

기업의 사업 모델을 지원하기 위한 기업의 조직 구조를 정의

#업무기능모델(책임자/분석가)

기업의 업무 기능을 계층적으로 분할하고 기능 내용을 정의

#프로세스 모델(설계자)

업무 기능을 상세화하여 계층적으로 프로세스을 분할하고 프로세스의 활동내용을 정의

#업무매뉴얼(개발자)

업무 기능이나 프로세스별 업무 내역을 상세히 기술한 자료

 

2)AA

기업의 업무를 지원하는 전체 애플리케이션을 식별하고 연관성을 정의하며, 업무와 IT 특성을 고려하여 그룹화하고 범주함으로써 전체 애플리케이션 구조를 체계화

#전사 애플리케이션 영역 모델(계획자)

기업의 업무를 지원하는 애플리케이션을 식별하고 애플리케이션별 특성 분석을 통해 이를 전사 수준에서 구조화

#애플리케이션 모델(책임자/분석가)

각 애플리케이션이 지원하는 기능과 데이터 정보를 정의하고, 애플리케이션이 제공하는 서비스를 도출하며, 이들 간의 연관 관계를 정의

#컴포넌트 모델(설계자)

실제 애플리케이션 개발에 필요한 설계정보를 관리

#프로그램 목록(개발자)

애플리케이션의 최종 단위인 프로그램에 대한 정보

 

3)DA

-기업의 업무 수행에 필요한 데이터의 구조를 체계적으로 정의

-전사 데이터 구성을 분류하고 데이터 모델을 정의

#전사 데이터 영역 모델(계획자)

개괄 데이터 모델. 상위 수준의 전사 데이터 영역을 분류하여 표현한 것이며, 상위 주제 영역 수준의 데이터 구성도

#개념데이터 모델(책임자/분석가)

전사 수준의 데이터 모델로 단위 주제영역 또는 핵심 엔티티 정도를 표현한 데이터 모델

#논리데이터모델(설계자)

개념 데이터 모델에서 정의된 주제영역과 핵심 엔티티를 기본 정보로 하여 업무 요건을 충족시키기 위한 데이터의 상세한 구조를 논리적으로 구체화

#물리데이터모델(개발자)

기술적 환경과 특성DBMS)을 고려하여 물리적 데이터 구조를 설계하고, 데이터베이스 객체를 정의

 

4)TA

-비즈니스, 데이터, 애플리케이션 아키텍처에서 정의된 요건을 지원하는 전사의 기술 인프라 체계를 정의

-전사의 기술 영역을 분류하고 표준 프로파일과 기술 아키텍처 모델을 정의

#전사 기술 영역 모델, TRM(계획자)

-기업이 업무활동에 필요한 정보기술의 영역을 상위 수준에서 분류한 모델

-TRM은 기업이 업무 활동에 필요한 기능들을 수행하기 위해 요구되는 정보기술을 상위 수준에서 논리적으로 분류한 틀

#표준 프로파일(책임자/분석가)

기술 참조 모델에 명시된 서비스를 지원하기 위한 정보기술 표준들의 집합

#기술 아키텍처 모델(설계자)

전사 기술 영역 모델이나 기술 참조 모델에서 정의된 서비스 카테고리별로 아키텍처의 패턴을 정의

#기술 자원 목록, 제품 목록(개발자)

표준 프로파일이나 기술 아키텍처별로 관련된 기술자원 목록이나 제품 목록을 기술 아키텍처 정보로 관리

 

데이터아키텍처

-기업이나 조직의 업무 수행에 필요한 데이터의 구조를 체계적으로 정의하여 구축하고 관리하기 위한 방법.

-다른 아키텍처와 달리 독립적 구축 가능.

전사데이터 영역을 업무Data와 메타Data, 업무Data는 운영계Data와 정보계Data로 구분

 

데이터아키텍처의 주요특징

-비즈니스를 효과적으로 지원하는 데이터 전략

-필수*핵심 데이터에 집중

-명확한 활동과 마일스톤

-변화하는 비즈니스 요구와 새로운 기술을 충족하기 위한 유연성

 

데이터아키텍처 실패요인

-기업이나 조직의 모든 데이터 및 정보 포함시도

-전문성 결여와 내재 기술력에 대한 오해

-IT부서의 독점적 소유 및 조치

-외부 구매에 의존하는 기술적 해결 시도

-이해당사자에 의한 독자적 개발 진행 및 통제 부재

-학술적 접근과 과도한 복잡성

-이상에 치우친 원칙과 정책

-단계적 성과를 고려하지 않는 장기 수행 전략

-변화 수용에 대한 배척

 

데이터아키텍처의 중요성

-전사의 데이터 구성을 용이하게 파악 가능

-데이터 품질 확보 용이

-명확한 의사소통 향상

-신속하고 적절한 의사결정 가능

-데이터 연계 및 상호운용성 향상에 따른 업무 정확성*효율성 향상

 

데이터아키텍처의 구성

전사데이터영역모델(계획자)

개념데이터모델(책임자)

논리데이터모델(설계자)

물리데이터모델(개발자)

 

다.EA 프레임워크 사례

F/W 특징 장점 단점
ZEAF - 1980년대 말 기업활동을 공학적 관점에서 파악하는 아키텍처 개념 최초 소개
- 기업 활동을 5W1H의 관점에서 모델링 관점 제공
- 5W1H에 따라 기업활동을 상세하게 모델링할 수 있는 관점 제공
- Planner, Owner, Designer, Builder, Sub-contractor 관점에서 기업 활동 관심영역을 구체화
- 정보화 측면에서 활용도 떨어지는 부문까지 정의
- 모델링 표현에 지나치게 집중, 실제 아키텍처 활동 계획 및 기반 정의 부족
FEAF - 2003년에 최신 버전 발표, 미연방정부 프레임워크 가이드라인 제공
- 참조 모델 기반의 EAF
- 모델링 관점뿐만 아니라 구체적 이행 계획을 프레임워크에 포함
- BRM, DRM, SRM, TRM, PRM등 다양한 참조 모델 활용
- 아키텍처 모델의 이해 및 진화에 대해 잘 정의되어 있으나, 조직 및 관련 규정등 제반 요소의 진화적 관점부족
TEAF - 미 재무성 EAF 
- FEAF, DoDAF와 함께 대표적 EAF
- How-Where-When을 표현하는 기능, What-How much-How Freq 를 표현하는 정보, Who-Why를 표현하는 조직, Enable를 표현하는 인프라 관점 중시 - 전사아키텍처 산출물 중심의 프레임워크로서 활용에 대한 접근이 부족
- 기업의 계속적인 활동에 대한 관점이 부족
DoDAF .효과적 작전 수행을 위해 무기 체계 간 상호운용성 보장을 위해 도입된 EAF
- 상호운용성 분석과 향상을 위해 LIBI 분석
- 산출물에 대한 템플릿을 상세하게 정의하여 통일되고 검증된 방식으로 모델링 가능
- 운영 모델에 대한 상세한 정의 및 표현 양식 제공
- 일반 기업 현장에서는 과도한 산출물과 정확도를 요구하고 있어 과잉 투자 가능성 있음
TOGAF 민간표준 연합인 오픈그룹 EAF

·구체적 아키텍처 개발 프로세스 제안
·각종 참조모델의 활용 관계를 잘 정의함
·메타 모델에 근거한 연속체 개념을 도입하여 아키텍처를 파악함으로써 조직의 특수성이 프레임워크에 반영되기 어려움
공공부문EAF 정부 공공기관에 전사아키텍처 도입시 참조할수있도록 표준, 가이드 목적으로 추진 ·전사아키텍처 관련된 거의 모든 항목을 프레임워크에 포함해 기본 프레임워크로 활용하기 용이 표준 프레임워크만 제시하여 구체적인 내용들은 참조한 기관에서 작성하도록 권고

-오픈그룹 프레임워크(TOGAF)는 아키텍처를 정의하기 위하여 오픈그룹에서 개발한 아키텍처 개발에 대한 지침인 아키텍처 개발 방법(ADM, Architecture Development Method), 정보기술을 체계적으로 분류한 기술 참조 모델, 표준 요약 정보를 모아놓은 데이터베이스인 표준정보기반(SIB, Standard Information Base)으로 구성



제3절 전사아키텍처 참조 모델

가.참조모델 정의

1)참조모델개념

-아키텍처 구성요소를 식별하여 표준화한 모델

-기관이나 기업의 전사아키텍처 수립시 참조하는 추상화된 모델

2)참조모델현황

성과 참조 모델: 정보화 성과의 측정을 위한 항목과 지표 및 방법을 제시

업무 참조 모델 : 업무아키텍처의 기준이 되며, 아키텍처 대상 기관의 사업 또는 업무 등을 전체적으로 분류하고 정의

서비스 참조 모델 : 응용아키텍처의 기준이 되며, 응용 서비스의 기능을 분류하고 정의

데이터 참조 모델 : 데이터아키텍처의 기준이 되며, 기관 간에 교환되는 주요 데이터 요소를 분석하여 이를 정의하고 표준화

기술 참조 모델 : 기술아키텍처의 기준이 되며, 정보기술을 분류 및 식별

3)참조모델 구축방법

-공통적인 특성을 추출하여 그 산업군에 맞게 범용적으로 만드는 방법(추상화)

-복잡하고 대표적인 기업을 선정하여 그 기업의 아키텍처를 표본으로 비슷한 기업에서 재활용하게 만드는 방법

 

나.참조모델 사례

1)BRM

-특정기관에 독립적으로 업무의 기능을 중심으로 정의한 참조 모델

다른 아키텍처를 정의하는 기준으로 활용

-몇 개의 업무 영역으로 구분. 각 업무 영역은 여러 개의 업무 단위로 구분되고, 각 업무 단위는 세부 업무로 구성

-정부는 정책 분야, 정책 영역, 대기능, 중기능, 소기능 등으로 분류

-기업은 사업 영역, 업무 영역, 업무 기능 등으로 분류

2)SRM

-업무 수행과 목표 달성을 지원하는 서비스 요소를 분류하기 위한 기능 중심의 평가 지향적 참조 모델

-공공 부문의 애플리케이션 서비스에 대한 식별을 통하여 업무와 서비스의 연계 및 재사용을 촉진하고 중복 개발을 방지하기 위한 것으로, 업무 및 조직에 독립적인 표준 서비스 분류 체계

3)TRM

-전사 IT 인프라의 표준화를 가능하게 하고 이는 특정 벤더로부터의 독립성을 제고

-업무와 서비스 구성요소의 전달과 교환, 구축을 지원해주는 표준, 명세, 기술요소를 기술

4)DRM

-기관 간의 공통 정보의 파악과 활용을 지원하기 위한 모델

-기관 간의 정보 공유 및 데이터의 표준화, 재사용을 지원하기 위한 범정부 데이터 분류 및 데이터 표준화와 관리를 위한 기준과 체계를 정의

-데이터 참조모델 프레임워크 구성요소(O) (데분구교관)

#범정부 데이터 모델

-범정부에서 구축 및 활용하고 있는 데이터를 식별하고 데이터 영역 간의 관계를 도식화

#데이터 분류

-데이터에 대한 분류 기준을 정의

#데이터 구조

-범위 내의 모든 데이터 요소와 요소의 소유주, 표준화 항목 정의, 요소 간 관계 및 정보를 저장

#데이터 교환

-데이터 요소의 교환을 위하여 교환 대상 정의 및 메시지 구조, 메시지 방식을 제시하고 교환 내역 을 관리

#데이터 관리

-데이터 품질, 표준화, 보안 등의 유지를 위한 데이터 관리 정책 및 규칙, 프로세스, 조직 구조를 정의

5)PRM

-정보화 성과 관리를 위한 구성 요소와 관계를 정의

-정보화 성과 제고 및 정보화 사업 품질 향상을 위한 기본 틀을 제공

-평가 분류 체계, 표준 가시 경로, 성과 관리 표준 양식으로 구성

 

라.참조모델활용

-다양한 용도로 활용가능하며, 용도에 따르 효과도 다름

#업무참조모델

*활용방안
- 업무 개선의 대상이 되는 관련 업무를 업무 참조 모델을 참조하여 파악
- 개별 기관의 비즈니스 아키텍처를 업무 참조 모델을 참조하여 정의

*기대효과
- 관련 기관 간 업무 흐름 촉진
- 업무 프로세스 혁신을 통한 업무 처리 생산성 제고
- 비즈니스 성과 측정 용이

#데이터참조모델

*활용방안
- 개선 대상이 되는 관련 데이터를 데이터 참조 모델을 참조하여 파악
- 개별 기관의 데이터아키텍처를 데이터 참조 모델을 참조하여 정의

*기대효과
- 정보의 상호운용성과 교환 촉진
- 정부나 기업 또는 산업 차원의 통합된 데이터 활용
-데이터 중복 배제 및 재사용
-데이터에 대한 표준화된 정의

 

데이터참조모델 관리기준

-범용성

-단순성

-표준성

-정확성

-정보이용성

-분류성

 

#서비스참조모델

*활용방안
- 개선 대상이 되는 관련 애플리케이션을 서비스 참조 모델을 참조하여 파악
- 개별 기관의 애플리케이션 아키텍처를 서비스 참조 모델을 참조하여 정의

*기대효과
- 시스템 간 상호운용성 향상
- 신뢰성 있는 시스템 구축 가능
- 변화에 신속한 대응 가능
- 시스템 개발 생산성, 품질 향상 기대

#기술참조모델

-상대적으로 구축 용이하고 기대효과가 커서 가장 먼저 적용하는 영역

-시스템간 상호운용성 증대를 위해 기술표준을 강조하는 구조

-시스템을 구축할때 사용할 기술들에 대한 표준 프로파일을 분류하는 기준

*활용방안
- 기술 참조 모델을 참조하여 개선 대상이 되는 관련 기술 인프라를 파악
- 상위 기술 참조 모델을 참조하여 개별 기관의 기술 아키텍처나 기술 참조 모델을 정의

*기대효과
- 시스템 간 상호운용성 향상
- 이식성 향상
- 시스템 확장성 향상
- 표준화 따른 벤더 독립성
- 재활용과 리소스 공유

#성과참조모델

*활용방안
- 정보화 성과 평가를 위한 평가 체계 및 항목을 성과 참조 모델을 참조하여 파악
- 개별 기관의 성과 평가 체계를 성과 참조 모델을 참조하여 정의

-시스템 변화에 대한 대응속도개선

-개선의 대상이 되는 업무를 쉽게 파악

*기대효과
- 체계적인 정보화 성과 측정 및 관리
- 정보화 사업의 중복 투자 최소화
- 성과 기반의 예산 편성 지원
- IT 자원의 효율적 관리

 


제4절 전사아키텍처 프로세스

가.전사아키텍처 프로세스 개요

-EA를 구축하고 관리하는 전체 절차로 작업의 단계와 공정, 작업내용 등을 정의

-IT관리체계 전반에 걸치 모든 프로세스를 포함하지는 않음

-전사의 특성에 맞게 조정/적용

-EA프레임워크의 구성요소중 하나로 다른 구성요소를 정의하기 위한 절차.

 

나.전사아키텍처 프로세스 구성

#EA 프로세스

단계 공정 내용
EA 비전
수립
EA 방향 수립 - 내외부 EA 환경 분석
- 기업의 EA 목적 및 방향 정의
- 기업의 EA 프레임워크 정의
EA 구축 EA 정보 구성 정의 - 아키텍처 매트릭스 정의
- EA 정보 구성 요소 정의
- EA 참조 모델 정의
- EA 원칙 수립
EA 정보 구축 - EA 자료 수집
- 현행 아키텍처 정보 구축
- 목표 아키텍처 정보 구축
EA 관리
정의
EA 관리 체계 구축 - EA 정보를 운영 및 활용하기 위한 조직 및 프로세스 정의
- 기업 내 EA 홍보 및 내부 추진 체계에 대한 교육 수행
EA 관리 시스템 구축 - EA 정보 관리 도구 선정
- EA 정보 관리하는 시스템 구축
EA 활용
정의
EA 이행 계획 - 목표 아키텍처를 달성하기 위한 중장기적인 계획 수립
EA 정보 활용 - EA 정보를 적용하여 IT 관련 업무를 수행함

-EA구축시에 단계별로 보고회 및 워크샵 형태의 행사를 통해 이해관계자의 지속적인 참여 유도




제2장 전사아키텍처 구축

제1절 전사아키텍처 방향 수립

가.전사아키텍처 방향 수립 개요

-아키텍처가 경영 환경과 경영 전략에 능동적으로 대응하며 발전하기 위하여 전사아키텍처 변화 동인에 대한 분석 작업을 수행하는 과정

 

나.전사아키텍처 환경 분석

-기업의 외부 환경과 내부 환경을 분석하고, 관련된 이해관계자로부터 전사아키텍처 수립을 위한 요건을 도출

#전사아키텍처 환경 분석 수행 과제

전사아키텍처 환경 분석 수행 과제
비즈니스 내/외부 환경 분석
IT 내/외부 환경 분석
전사 범위 정의

다.전사아키텍처 구축 방향 정의

1)목적 및 범위 정의

-전사아키텍처의 일반적 목적과 전사아키텍처 환경 분석 결과를 기반으로 기업의 전사아키텍처 구축 목적을 정의하며, 기업의 전사아키텍처에 대한 이해와 관리 역량을 고려하여 구축 범위를 정의

#목적 예

-상호운용성 증대
-정보화 투자 의사결정 체계 구축
-비즈니스 변화에 대한 신속한 대응체계 구축
-전사적 정보화 표준 정립
-고객 지향의 정보화 체계 구축

2)전사아키텍처 비전 수립

-전사아키텍처 비전: 기업이 전사아키텍처를 통해 실현하고자 하는 미래의 모습과 이를 확보하기 위해 기업이 공유해야 할 가치

#비전의 구성요소

핵심목표:전사아키텍처 도입을 통하여 궁극적으로 달성하고자 하는 기업의 목표 또는 실현하고자 하는 모습

핵심가치:전사아키텍처의 핵심 목표의 달성을 위해 구성원들이 추구하거나 지켜야 하는 신념

EA비전:고객과 성과를 지향하는 업무 중심 전자 정부 통합 관리 체계 구현

*행사목적
- 행정 서비스에 대한 국민 만족
- 고객 중심, 성과 지향, 업무 중심

*핵심가치
- 업무와 정보 기술 연계 노력
- 정보화 비전 및 설계도
- 변화 대응 체계 구축
- 통합 관리 체계 구축
- 정보 자원 표준 및 지식 체계 구축

 

라.전사아키텍처 프레임워크 정의

-기업의 특성에 따라 적합한 형태로 정의

 

공공부분 전사 아키텍처 프레임워크 구성요소

구분 구성요소 설 명
방향/지침 정보기술 정책 - 기업의 기본적인 정책에 부합하도록 정보 기술을 도입하고 적용하기 위한 시스템, 아키텍처, 도구, 제품 등에 독립적인 일관된 목표와 방향을 제시
전사아키텍처 전략 - 기업의 기존 및 신규 도출될 정보 기술 전략과 전사적인 비전, 목적이 정렬된 모습을 반영
- 전사아키텍처 전략은 비전과 목적을 포함하므로 아키텍처 비전 수립에서 작성
아키텍처 원칙 - 원칙은 전사아키텍처 목표를 달성하기 위한 투자 및 의사결정에 객관적 기준을 제시
요구 사항 - 전사아키텍처 전략을 충족시키기 위한 전사적 요구 조건을 의미
- 요구 사항은 전사적 관점에서 작성되어야 함
전사아키텍처 활동 아키텍처 모델 - 전사의 모든 자원을 관점과 시각으로 분류한 아키텍처 모델을 정의
- 아키텍처 모델은 전사의 모든 자원을 관점과 시각으로 분류한 매트릭스로 표현됨
생명주기 - 전사아키텍처를 계획, 개발, 적용, 유지 보수, 통제, 감독하기 위한 일련의 프로세스로 구성
- 계획 : 아키텍처 도입을 위하여 실무자들을 지정하고 EA의 관리 통제 구조를 구성하며, 개발을 위한 프레임워크를 선정하고 접근방법 정의
- 개발 : 아키텍처 목적과 선택된 아키텍처 모델에 기초해 실제 아키텍 처를 구축하는 단계이며, 현행, 목표, 이행 계획 수립으로 이루어짐
- 적용 : 시스템 개발/획득을 위한 프로세스와 정보 기술에 대한 투자 여부를 결정하고 통제하는 정보 기술 투자 프로세스를 포함
- 유지 보수 : 정기적으로 조직 내외부의 상황을 반영하여 지속적으로 변화하는 내용을 반영하는 활동과 개선 작업을 수행함
- 통제와 감독 : 아키텍처 개발과 이행, 유지 보수 활동을 보증하고 문제가 있는 환경인 경우, 이를 해결하기 위해서 지속적으로 통제와 감독을 수행
지원 도구 - 지원 도구는 생명주기의 활동을 체계적, 효율적으로 지원하는 기준, 방법, 도구 등을 의미
- 참조 모형, 자본 투자 연계 절차, 성숙 모델, EA 관리 시스템 등으 로 구성
산출물 아키텍처 산출물 - EA 활동의 결과에 따라 개발된 산출물로서, EA 목적 및 활용을 참조하고, 시각 및 관점별로 업무 및 IT 정보를 활용할 수 있도록 필요한 산출물을 정의
- 범정부 EA 산출물 메타 모델 정의서에서 제시하고 있는 필수 산출물을 반드시 준용하여 정의·행정 서비스에 대한 국민 만족

제2절 전사아키텍처 정보 구성 정의

가.전사아키텍처 정보 구성 개요

-가능한 변화하지 않은 구성요소를 도출하여 정의

-EA산출물과 다른 구조:: 정보구성요소는 EA정보를 구성하는 기초단위, 산출물은 여러 개의 정보구성요소로부터 도출된 복합적인 정보.

-아키텍처 매트릭스를 통하여 정의되고 표현

-기업의 IT능력을 고려하여 적정수준으로 관리

 

나.아키텍처 매트릭스 정의

1)아키텍처 매트릭스 개념

-업무, 응용, 데이터, 기술 뷰별로 계획자, 책임자, 설계자, 개발자 관점에서 산출물을 정의

-조직내 다양한 계층의 사람들이 매트릭스에 포함된 산출물이 범위와 목적에 적합하게 정의되었음을 확신

-IT조직의 성숙도를 고려해서 적용

-EA산출물에 포함된 정보를 중복이 없고 상호관계가 유기적으로 연결될 수 있는 ‘EA정보구성요소’를 추가로 정의

 

2)아키텍처 매트릭스 구성

-의사결정 유형(관점)과 아키텍처 정보 유형(뷰)의 두 축을 기준으로 2차원의 매트릭스 형태

#의사결정 유형

-조직의 의사결정 유형을 계층적으로 구분한 것으로, 조직이 수행하는 업무의 의사결정 특성에 따라 단계를 정의

#아키텍처 정보 유형

- 특성이 비슷한 아키텍처 정보를 그룹화 한 것으로, 기업이 관리하는 모든 아키텍처 정보를 수집하여 분류

3)산출물 정의

-의사결정 유형과 아키텍처정보 유형으로 구성된 매트릭스의 각 셀에 필요한 산출물을 정의

관점\뷰 업무 데이터 응용 기술
계획자 - 조직 구성도/정의서
- 업무 구성도/정의서
- 데이터 구성도/ 정의서 - 응용 시스템 구성도/ 정의서 - 표준 프로파일
- 기반 구조 구성도/ 정의서
- 기술 자원 목록
책임자 - 업무 관계도/기술서
- 업무 기능 분할도/ 기술서
- 개념 데이터 관계도/ 기술서
- 데이터 교환 기술서
- 응용 시스템 관계도/ 기술서
- 응용 기능 분할도/ 기술서
- 기반 구조 관계도/ 기술서
설계자 - 업무 절차 설계서 - 논리 데이터 설계서
- 데이터 교환 설계서
- 응용 기능 설계서
- 응용 분산 시스템 설계서
- 기반 구조 설계서
- 시스템 성능 설계서
책임자/
분석자
(개념적)
업무의 세부 구성 정보와 업무/조직 간 관계 정보 상위 수준의 기능 구성 정보와 응용시스템 간 관계 정보 DB에서 관리되는 주요 데이터 개체와 개체 간 관계 정보 기술 기반 자원의 유형별 구성과 인터페이스 정보

 

관점 산출물명 설명
업무 조직 구성도/정의서 기업의 조직 또는 조직의 유형, 역할 간의 관계를 표현한 것으로 관련된 이해 당사자의 관계와 상위 조직과 하위 조직 간의 관계를 식별함
업무 업무 구성도/정의서 기업 비즈니스 아키텍처의 개념적 모습을 도형으로 묘사한 산출물.
기업의 업무 기능을 사용자가 이해하기 쉽게 도식화하여 표현함으로써 비즈니스 아키텍처에 대한 이해와 이해 당사자 간의 대화 수단으로 활용
업무 업무 관계도/기술서 업무 기능 간에 의존 관계를 도식화하여 표현. 업무 기능 간의 정보 흐름을 추적할 수 있음
업무 업무 기능 분할도/
기술서
조직의 업무 기능을 계층 구조로 분류하여 표현한 것으로, 업무 기능을 식별하여 그 구조와 업무의 활동 내용을 기술함
업무 업무 절차 설계서 업무 활동의 흐름을 기술한 산출물로, 각 업무 활동이 어떤 역할과 이벤트에 의하여 수행되고, 어떠한 정보를 주고받는지 등을 기술함
업무 업무 매뉴얼 업무 기능과 업무 활동별로 세부 내역을 설명한 매뉴얼 정보 또는 그 목록
응용 응용 시스템 구성도/정의서 기업의 응용 시스템을 상위 수준에서 분류하고 표현함으로써 전체적으로 응용 시스템의 구조를 파악할 수 있는 산출물
응용 응용 시스템 관계도/기술서 응용 시스템 상호 간의 연계성을 표현한 것으로 응용 시스템 상호 간의 데이터 흐름을 파악할 수 있음
응용 응용 기능 분할도/
기술서
응용 시스템의 기능을 계층적으로 표현한 것으로, 응용 기능의 업무 연관성과 재사용성을 파악하도록 함
응용 응용 기능 설계서 응용 시스템의 기능을 정의하고 응용 기능 간의 상세 구조와 데이터 흐름을 표현한 것으로, 기능 간의 완전성 확인 가능
응용 응용 분산 시스템
설계서
시스템의 분산 계층을 정의하고 분산 자원을 계층별로 할당하여 표현한 산출물
응용 응용 프로그램 목록 응용 시스템에 정의된 응용 기능을 제공하는 프로그램의 정보 또는 목록. 시스템 개발 비용 산정을 위한 기반 자료로 활용됨
데이터 데이터 구성도/
정의서
기업의 전체 데이터를 상위 수준에서 표현한 것으로 데이터베이스 구성현황을 한눈에파악할수있도록함‘( 개괄데이터모델’과유사함)
데이터 개념 데이터 관계도
/기술서
업무 수행을 위해서 필요한 데이터의 구조를 개념적 수준에서 표현 한 것. 주제 영역 또는 중요 엔터티 수준의 데이터 관계도. 업무 수행 에 필요한 데이터를 통합적으로 파악할 수 있음‘( 개념 데이터 모델’ 과 유사함)
데이터 데이터 교환 기술서 업무 기능 간에 교환되는 데이터 교환 요구 사항을 식별하여 표현한 것
데이터 논리 데이터 설계서 업무를 수행하기 위해서 필요한 데이터의 구조를 논리적 수준에서 충분히 표현한 것으로, 데이터 유형(엔터티 타입), 식별자, 속성, 관계, 데이터 업무 규칙 등을 포함
데이터 데이터 교환 설계서 응용 기능 간의 데이터 교환의 요건을 식별하여 이를 상세화하며 표현한 산출물
데이터 물리 데이터 모델 업무 기능 또는 응용 시스템에 의하여 사용될 데이터를 실제 데이터 베이스로 구축하기 위해 필요한 물리적 특성을 정의한 모델. DBMS의 특성이나 거래 특성, 성능 요건 등을 고려한 설계가 됨
기술 표준 프로파일 기술 참조 모델에서 정의한 기술 요소별로 아키텍처 구현에 적용되어야 하는 표준과 규칙, 제품 평가 기능 등을 기술한 자료
기술 기반 구조 구성도/
정의서
기업의 기반 기술 구조에 대하여 상위 수준에서 그래픽하게 표현한 것으로 기반 기술 아키텍처를 한눈에 파악할 수 있도록 함
기술 기술 자원 목록 기업의 기술 자원에 대해 전체적으로 현황을 파악할 수 있도록 작성된 현 시스템에 대한 현황서
기술 기반 구조 관계도/
기술서
애플리케이션 또는 기술 서비스별 시스템 구성을 표현한 것으로, 시스템 간의 연결 관계 및 시스템 사양을 표현
기술 기반 구조 설계서 시스템의 지리적 분포를 조망할 수 있는 산출물. 하드웨어, 소프트웨어, 네트워크 등이 표현 대상
기술 시스템 성능 설계서 시스템에 요구되는 성능 요건을 충족시키기 위해 어떤 특성이 가장 핵심적인지를 식별하여 표현
기술 제품 목록 정의된 기술 서비스와 표준을 지원하는 제품에 대한 정보 또는 목록



4)전사아키텍처 정보 구성요소 정의

#전사아키텍처 정보 구성요소 식별

-전사아키텍처 산출물에 포함된 정보를 중복이 없고 상호관계가 유기적으로 연결되도록 구성요소를 정의

#전사아키텍처 정보 구성요소 연관관계

 

5)아키텍처 매트릭스 정의시 고려사항

-아키텍처 매트릭스에 정의되는 산출물은 업무와 IT, 관리자와 실무자 사이의 중요한 커뮤니케이션 툴

-조직적, 정치적, 지리적 특성, 조직의 편견 등 다양한 조직 문화와 의사결정 구조가 반영

-아키텍처 매트릭스는 실제 시스템과 아키텍처 개발 표준에 대한 준수성을 높이고 조직별로 통일된 접근이 가능하도록 정의

-각 아키텍처 도메인은 상호 간에 연계성을 가져야 함.

 

다.참조모델 정의

-업무와 정보기술에 대한 체계적인 분류와 표준화를 통하여 정보화의 통합성, 중복 개발 방지, 공유정보의 발견, 상호운용성 향상 등의 목적으로 설계

 

라.EA원칙 수립

-전사아키텍처 목표 달성을 위한 의사결정의 객관적 기준을 제시하여 줌으로써, 의사결정을 효과적으로 지원해 주고 업무 협조와 조정을 위한 의사소통 과정의 투명성을 제공

#EA원칙

-업무지향:기업의 정보화는 업무 개선과 상품 및 서비스 품질 개선에 기여할 수 있는 방향으로 추진

-성과지향:기업의 정보화는 객관적인 성과 지표에 의해 관리되고 평가

-고객지향:기업의 정보화는 고객의 만족도를 개선하는 방향으로 추진

-상호운용:정보화는 전사아키텍처에 정의된 원칙과 아키텍처를 준수하여 시스템 간의 연계성과 운영의 지속성을 확보할 수 있는 방향으로 추진

아키텍처 원칙 의미
비즈니스 범위의 완전성 기업이 수행하는 모든 업무 기능을 누락하지 않고 중복 없이 파악하여 정의
데이터 데이터 표준 준수 정의된 표준에 따라 생성·수정·활용
아키텍처 모델 관리 전사 차원의 아키텍처 데이터 모델을 관리하여 전사적 데이터 통합성을 유지
응용 지원 기능 유일성 응용 시스템의 기능은 유일
기술 기술의 표준화 모든 기술 아키텍처 설계 및 도입 시에는 정의된 TRM/SP를 반드시 준수
운영의 안정성 시스템의 장애에 대한 대응 체계 구축으로 시스템의 안정성, 연속성을 보장

#원칙 수립시 고려사항

-원칙의 의도가 명확하게 제시되어 원칙 적용 시 혼돈의 발생을 최소화
-아키텍처 및 계획 수립과 관련된 의사결정을 효율적으로 할 수 있도록 가이드
-중대한 정보 기술 관련 의사결정 시 규범으로서 활용
-전사아키텍처 조직의 모든 정보 관리 및 기술과 관련된 의사결정은 전사아키텍처 원칙을 기반으로 수행
-원칙 간에 서로 상반되는 지향점을 갖지 않도록 원칙 수립 시 사용되는 용어는 주의하여 선택

-BA원칙: 비즈니스 가치지향, 업무효율성

-AA원칙: 편리성, 유연성, 신속성, 신뢰성

-DA원칙: 정확성, 적시성, 통합성, 보안성

-TA원칙: 운영의 안정성, 상호운영성, 기술의 표준화

-관리원칙: 유지보수성, 효율성, 효과성



제3절 전사아키텍처 정보 구축

가.EA 정보구축 준비

1)자료수집

- 수집해야 할 자료는 정의된 아키텍처 매트릭스에 따라 달라짐

 

2)전사아키텍처 정보 구축 방식

-상향식 구축: 최하위 구성요소들의 공통점을 파악하여 상위 구성요소를 정의

장점: 조직의 모든 업무가 포함

단점: 상위 업무 기능 분류 수준이 다를 수 있음

-하향식 구축: 최상위 구성요소부터 분류기준에 따라 하위 구성요소를 도출

장점: 분류 기준이 명확

단점: 일부 업무 누락 가능

 

나.현행 아키텍처 정보 구축

-현재 업무나 정보시스템에 대하여 기존의 자료를 분석하여 전사아키텍처 정보를 구축

-상위 수준의 업무 기능과 시스템에 대한 분류를 우선 수행하는 방식이 효율적, 하위수준의 정보구축은 병렬적 수행가능

-조직의 EA도입 목적을 고려해서 정의될 정보수준을 결정하는데 현행아키텍처 중심의 프로젝트인 경우, 현행 아키텍처에 대해서는 아키텍처 매트릭스에 정의된 산출물을 모두 정의하는 것이 바람직

 

1)현행 BA 정보 구축

-기업의 비전, 경영목표, 조직 구조 등을 파악하여 정의

#현행 비즈니스 아키텍처 정의 내역

-전사 사업모델 분석
-조직 모델 분석
-업무 기능 모델 정의
-프로세스 모델 정의
-업무 매뉴얼 파악

2)현행 AA 정보 구축

-업무 기능 분류를 기반으로 전사 애플리케이션을 분류하고, 연관관계를 분석. 애플리케이션 구조와 서비스, 응용기능 도출

#현행 애플리케이션 아키텍처 정의 내역

-전사 애플리케이션 영역 식별
-애플리케이션 모델 정의
-컴포넌트 모델 정의
-프로그램 목록 파악
-애플리케이션 원칙, 표준 파악

3)현행 DA 정보 구축

-하향식 : 기업의 업무 수행을 위해 필요한 데이터 요건을 식별하여 데이터 모델로 표현

-상향식:  각 시스템에서 사용하는 데이터 정보를 분석하여 데이터 모델로 정렬하여 표현

-계획자 수준의 상위 정보만을 구축할 경우는 하향식 방식이 적합하며, 실무자 수준의 정보를 구축할 경우에는 상향식 방식이 더 적합

 

#현행 데이터아키텍처 정의 내역

-전사 데이터 영역 식별
-개념 데이터 모델 정의
-논리 데이터 모델 정의
-물리 데이터 모델 정의
-데이터베이스 객체 파악
-데이터 원칙, 표준, 관리 프로세스 파악

4)현행 TA 정보 구축

-기업의 전산 장비, 시스템 소프트웨어, 네트워크 등 기술 인프라의 구성을 체계적으로 분류하여 표현

#현행 기술 아키텍처 정의 내역

-전사 기술영역 식별
-기술 참조 모델 정의
-기술 표준 분석
-기술 아키텍처 요소 식별
-기술자원 목록, 제품 목록 파악

다.목표 아키텍처 정보 구축

-현행 아키텍처에 대한 문제점과 개선사항을 도출하고 이를 목표 아키텍처에 반영하는 방식으로 진행

-비즈니스 아키텍처를 먼저 정의하고 이를 효율적으로 지원하는 아키텍처를 정의

-개념적 수준까지 정의함

 

1)목표 BA 정보 구축

-현행 추가 업무와 개선 요구 사항을 목표 비즈니스아키텍처에 반영

#목표 비즈니스 아키텍처 정의 내역

-전사 사업 모델 정의
-조직 모델 정의
-업무 기능 모델 정의
-프로세스 모델 정의
-업무 매뉴얼 정보 구축

2)목표 AA정보구축

-목표 비즈니스 아키텍처를 지원하는 전사 애플리케이션의 구조를 정의

#목표 애플리케이션 아키텍처 정의 내역

-전사 애플리케이션 영역 모델 정의
-애플리케이션 모델 정의
-컴포넌트 모델 정의
-프로그램 목록 정보 구축

3)목표 DA정보 구축

- 목표 비즈니스 아키텍처를 지원하는 데이터를 식별하여 모델로 표현

#목표 데이터아키텍처 정의 내역

-전사 데이터 영역 모델 정의
-개념 데이터 모델 정의
-논리 데이터 모델 정의
-물리 데이터 모델 정의
-데이터베이스 개체 정보 구축
-데이터 원칙, 표준, 관리 프로세스 정의

 

4)목표 TA정보 구축

-목표 애플리케이션 아키텍처와 데이터아키텍처를 잘 지원할 수 있는 기술 아키텍처를 정의

#목표 기술 아키텍처 정의 내역

-전사 기술 영역 모델 정의
-기술 참조 모델 정의
-표준 프로파일 정의
-기술 아키텍처 모델 정의
-기술자원 목록, 제품 목록 정보 구축

 


 

제3장 전사아키텍처 관리 및 활용

제1절 전사아키텍처 관리 체계

가.전사아키텍처 관리체계 개요

1)EA 관리체계 개념

-전사아키텍처를 유지 관리하기 위한 조직과 프로세스 측면의 기반을 구축하는 것

-EA관리조직, EA관리프로세스, EA관리인력

#IT 관리 체계와 전사아키텍처 관리 체계

-IT 관리 체계: IT거버넌스.  IT 관리의 효율성과 효과성을 증대하기 위한 IT전반에 관한 관리 체계를 정립

-EA 관리체계: EA거버넌스. 전사아키텍처를 유지하고 지속적으로 개선하기 위해 제도적 기반을 구축

2)EA 관리체계 구축 방향

-전사아키텍처 구축의 효과를 높이기 위해서는 EA간의 통합성과 EA내의 통합성이 확보되어야 함

-EA 간의 통합성: 복수 기관 간에 통합적으로 전사아키텍처가 구축

-EA 내의 통합성: 단일 기업 내에서 전사아키텍처 영역 간에 통합적으로 전사아키텍처를 구축

 

#EA관리체계 구축시 고려사항

-정의된 전사아키텍처 조직 체계, 프로세스 체계 등을 문서화하여 전 조직이 준수할 수 있도록 제도화

-전사아키텍처 관련 제반 이해당사자의 전사아키텍처 인지도 향상 및 업무 수행시 전사아키텍처정보 활용도 증진을 위한 적절한 교육 프로그램을 제공

-목표 아키텍처로의 전환, 정보자원 관리의 혁신 등 전사아키텍처 도입에 따른 변화 관리를 위한 종합적인 프로그램을 운영

-전사아키텍처 관리 체계를 주기적으로 점검하여 개선점을 도출하여 반영할 수 있는 제도적 장치를 마련

-EAMS을 활용도와 만족도를 주기적으로 점검하여 시스템의 품질을 지속적으로 개선

 

나.EA 관리 조직 체계

1)EA 관리 조직 개요

-전사아키텍처 관리를 위해 필요한 직무와 직무간의 관계, 업무 분장을 정립

#EA관리조직의 직무 예

-전사아키텍처 담당 임원:전사아키텍처 수립에 대한 투자 의사결정, 전사아키텍처의 주요 추진 과정에 대한 승인, 전사적 지원의 확보

-전사아키텍처 아키텍트:전사아키텍처에 대한 전체적 원칙 및 방향 정의, 전사아키텍처 관리의 총괄, 영역간의 조정

-전사아키텍처 영역별 담당자:비즈니스 아키텍처, 데이터아키텍처, 애플리케이션 아키텍처, 기술아키텍처 등의 전사아키텍처 영역별 원칙과 정보를 관리하는 담당자

-전사아키텍처 관리시스템 관리자 :전사아키텍처 관리 시스템의 구축 및 운영을 담당

-전사아키텍처 추진 위원회 :전사아키텍처 수립 및 적용에 대한 전사적인 중요 의사결정에 대한 승인 또는 자문을 수행하는 그룹

2)전사아키텍처 관리 조직의 정의

-전사아키텍처 정보는 상호연관성을 유지하며 지속적으로 관리

 

#EA관리조직 정의시 고려사항

*IT 조직의 규모(O)

-전사아키텍처 관리 조직을 별도 조직으로 구성할 수 없는 중소규모의 IT 조직은 전사아키텍처 관리 운영위원회(또는 TFT) 중심으로 전사아키텍처 관리 조직을 정의하고 전사아키텍처 전담 인력을 양성.

-전사아키텍처 관리 조직을 별도 조직으로 구성할 수 있는 대규모의 IT 조직은 전사아키텍처 관리 전담 조직을 신설하고, 전사아키텍처 관리 운영위원회를 통해 전사적으로 의사결정을 공유할 수 있는 조직 체계를 정의.

 

*전사아키텍처 관리 조직

-전사아키텍처 구축 목적이 순수하게 아키텍처 관리와 IT 표준화 등을 위한 것이면 전사 아키텍처와 IT 표준을 통합 관리할 수 있는 전사아키텍처 관리 조직을 정의

-전사아키텍처 구축 목적이 신시스템 구축을 위한 계획 수립이면 전사아키텍처 정보 중심으로 프로젝트를 관리할 수 있는 PMO와 전사아키텍처 관리 전담조직을 정의.

-현업과 IT 조직간의 의사소통 문제가 있을 경우 현업의 요건을 종합적으로 관리하는 조직을 추가로 정의


다.EA 관리프로세스

1)EA 관리프로세스의 개요

- 전사아키텍처를 관리하기 위한 활동을 정의

#전사아키텍처 기획

-전사아키텍처 관리의 방향과 전사아키텍처를 효과적으로 적용 및 활용하기 위한 계획을 수립

#전사아키텍처 변경 관리

-영역별 전사아키텍처 정보의 변경에 대한 검토, 승인, 변경 이행 

#전사아키텍처 준수 통제

-각 정보관리 부문이나 관련 현업 부서에서 전사아키텍처 정보를 참조하고 준수하는지 점검하고 지원

#전사아키텍처 활용 지원

-각 정보관리 부문이나 관련 현업 부서에서 전사아키텍처 정보를 잘 활용하도록 전사아키텍처 정보의 공지, 홍보, 교육, 활용사례 전파

#전사아키텍처 관리 시스템 관리

-전사아키텍처 관리 및 활용의 효율성 제고를 위한 정보관리 시스템을 구축하고 운영

#전사아키텍처 평가

-전사아키텍처 관리 및 활용 수준의 제고를 위해 전사아키텍처 평가 모형을 정의하고 주기적으로 평가하여 개선의 기회를 식별

 

2)전사아키텍처 관리 프로세스 구성

-전사아키텍처 구축후 이를 활용하고 통제

 

라.EA관리인력

1)EA관리인력 개요

-전사아키텍처 관리를 담당하는 직무별 역량을 정의하고 이를 확보하기 위한 방안을 정의

-전사아키텍처 관리를 위해 필요한 역량 요소를 분류하고, 역량 요소를 직무별로 할당하고, 이러한 역량 요소를 확보하기 위한 교육 계획을 수립하고 역량 수준을 평가할 수 있는 체계 포함

-전사아키텍처 역량 요소는 리더십 역량, 기술적 역량, 활용 역량으로 구분

2)EA 전문가 육성

-현재 내부 아키텍트가 보유하고 있는 기술 수준을 평가하여 내부 아키텍트가 전사아키텍처 정보를 원활하게 관리할 수 있는 기술 수준으로 도달 할 수 있도록 인력 양성 계획을 수립

 


 

제2절 전사아키텍처 관리 시스템(EAMS)

가.EA 관리 시스템

1)EA 관리 시스템 개요

-전사아키텍처 정보를 구축하여 관리하고 활용하는 모든 전사아키텍처 업무 프로세스에 대한 효율성 제고를 지원하기 위한 정보 시스템

나.EA 정보 정의 도구

-업무, 데이터, 애플리케이션, 기술아키텍처 정보를 도식화하여 표현 할 수 있는 모델링 도구

다.EA 정보 관리 시스템

-아키텍처 정보를 저장하는 레포지터리와 전사아키텍처 정보를 사용자에게 배포하는 포털, 전사아키텍처 정보를 전문적으로 분석할 수 있는 추가적인 도구로 구성

-전사아키텍처 정보에 대한 버전 관리

-전사아키텍처 정보의 현행과 목표의 비교 -아키텍처 매트릭스나 참조 모델과의 연계 

-전사아키텍처 사용자의 권한 관리

-전사아키텍처 정보에 대한 활용 통계 분석 및 의사결정 지원 기능 등을 포함

#도입효과

-아키텍처 정보를 공유할 수 있어 해당 조직의 각 아키텍처 요소에 대해 이해 관계자들이 정확하게 파악

-의사소통 도구로 전사아키텍처 관리 시스템을 활용

-전사아키텍처 관리 시스템을 의사결정 도구로 활용

-업무와 IT서비스간의 차이분석 가능

 


제3절 전사아키텍처 활용

가.EA 활용 개요

#목표아키텍처 이행계획

-주로 새로운 시스템 추진을 목적으로 전사아키텍처를 수립하는 경우

#전사아키텍처 정보 상시 활용

-전사 아키텍처 정립을 통해 기업의 전반적인 IT 관리 수준을 증대하고자 하는 경우

 

나.목표 아키텍처 이행계획

#아키텍처 차이분석

-목표 및 현행 아키텍처 검토, 차이분석

#프로젝트 정의

- 프로젝트 목록 정의, 개별 프로젝트 별 필요 리소스 정의, 프로젝트 우선순위 및 연관성 분석

#이행전략 수립

-프로젝트 이행에 필요한 단계별 이행 전략 대안 수립, 이행 전략별 타당성 분석 및 대안 확정

#이행계획 수립 

-프로젝트별 추진 방법 정의, 프로젝트별 상세 일정 계획 수립

#변화관리계획 수립: 

-변화관리 대상 및 변화 요인 식별, 변화관리 계획 수립, 변화관리 교육 계획 및 자료 작성

 

다.EA정보 상시 활용

IT기획관리

- 업무 프로세스 혁신 : 비즈니스 변화와 정보기술 변화에 따르는 영향을 분석하여 대응하고, 조직 간의 업무 수행 범위 및 중복성 확인으로 업무 프로세스 개선 가능
- 정보화 계획 수립 : 정보화 전략 계획 수립 시에 활용할 수 있으며, 중복을 배제한 효과적인 시스템 투자 계획 수립에 활용

IT구축관리

- 프로젝트 계획 : 정보시스템 구축을 위한 구체적인 프로젝트 계획 수립 및 제안 요청서 작성 시 활용
- 시스템 개발 : 기존 시스템 개선 및 신규 시스템 개발을 위한 기준 및 참조 정보를 제공하며, 시스템 간 연계성 및 재사용 대상을 식별할 수 있음

 

IT운영 및 통제

- 시스템 운영 : 시스템 장애 시에 전체 모습을 쉽게 파악할 수 있어 문제점을 신속 하게 찾아 낼 수 있으며, 시스템의 변경 시에 영향도를 파악할 수 있어 위험을 최소화할 수 있음
- IT 통제 : 도입되는 시스템이 전사 표준을 준수하는지를 통제함으로써 상호운용성, 유지 보수 편리성 등을 확보함

 

1)IT기획관리

-중장기 정보화 계획, 단기 정보화 계획 수립 시 전사아키텍처 정보를 바탕으로 기업의 업무와 전략적 방향에 맞는 목표 시스템을 정의하고 추진계획을 수립

2)IT구축관리

시스템 분석, 설계, 구축, 이행 등의 모든 시스템 구축 생명주기 동안에 전사 아키텍처 정보를 바탕으로 범위를 정의하고, 애플리케이션 시스템을 설계하며, 데이터아키텍처를 정의하고, 기술 체계를 선정

3)IT운영/통제 관리

전사아키텍처의 현행 아키텍처 정보를 바탕으로 시스템을 운영하고, 사용자의 개선 또는 추가 요구 발생시 전사아키텍처 정보를 바탕으로 수용 또는 적용 방안을 결정하여 시스템 변경에 반영

 

라.전사아키텍처 효과적 활용 방안

-전사아키텍처 정보 자체의 품질 보장.
-현행 및 목표 시스템의 상황이 아키텍처 정보에 항상 최신의 상태로 정확히 반영

-전사아키텍처 정보를 관리하고 적용을 통제할 수 있는 전담 조직 구성·운영 

-전사아키텍처 정보를 전사적으로 공유하고 활용할 수 있는 절차와 시스템이 필요

 

라.EA와 DA 전문가 영역

1)EA와 DA 프레임워크

-광의의 데이터아키텍처 영역은 데이터아키텍처 원칙, 데이터아키텍처 정보, 데이터아키텍처 관리 등을 포함

-전사아키텍처에서 정의된 원칙과 정보, 관리 체계를 준수해야 하며 데이터아키텍처 분야에서 더욱 구체화

-데이터아키텍처 정책의 데이터아키텍처 매트릭스, 데이터아키텍처 비전, 데이터아키텍처 원칙 및 표준을 더욱 구체화하고 그 내용을 정의

C2)EA와 DA

DA는 EA와 통합해야 함

#범위통합

전사아키텍처 범위 전체에 대한 각 모델 내의 불일치성을 제거

#수평 통합

관련된 타 영역과의 불일치성을 제거

#수직통합

계획자, 책임자, 설계자, 개발자간의 불일치성을 제거

 

맨 위로 이동

 

DAP 2장 데이터 요건 분석

 

DAP 3장 데이터 표준화

 

DAP 4장 데이터 모델링

 

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

 

DAP 6장 데이터 품질 관리 이해

 

Posted by Lumasca
,

 

갤럭시 스마트폰에는 최신 뉴스들이 노출되는 삼성프리 화면이 있다.

 

이 화면은 홈화면 왼쪽에 존재하므로 화면을 오른쪽으로 밀면 노출된다.

 

별로 궁금한 뉴스도 아니고 홈화면에서 실수로 이동하는 경우도 많아서 불편한 경우가 많다.

 

이 기능을 제거하는 방법은 간단하다.

 

1. 홈화면을 길게 누른다. 빈공간을 1초이상 누르면 된다.

 

2.화면을 오른쪽으로 밀어낸다. 그러면 아래와 같은 화면이 보인다.

 

3.화면의 우측상단에 버튼을 눌러서 해당 기능을 비활성화 시키면 된다.

 

 

'IT Others' 카테고리의 다른 글

ChatGPT 맛보기  (0) 2023.02.09
Mac에서 Karabiner 삭제  (0) 2022.08.25
아이클라우드(iCloud) 사진 전체 다운로드  (1) 2021.02.11
Mac 키노트(Keynote) 슬라이드 세로 레이아웃  (0) 2021.02.04
맥(Mac) 화면 캡쳐  (0) 2020.12.29
Posted by Lumasca
,

여러분은 책을 읽을 때 어떻게 읽으시나요?

혹시, 책을 읽는 속도가 느려서 불만이 생긴 적이 있으신가요?

또, 책을 빨리 읽어서 더 많은 정보를 얻고 싶은 생각을 하신 적이 있으신가요?

 

여기, 세계적인 두뇌 전문가 짐퀵이 제시한 속독법이 있습니다.

 

첫번째는 속발음을 하지 않고 눈으로만 책을 읽는 것입니다.

여러분이 처음 책을 읽을 때 어떤 방식으로 읽었는지 기억하시나요?

아마 대부분 책을 소리내어 읽도록 교육을 받았을 것입니다.

이것이 우리의 독서 습관이 되었고, 눈으로 읽더라도 속으로 발음을 하면서 읽게 된 것입니다.

그런데 속발음을 하지 않는 것은 생각처럼 쉽지 않습니다.

일단, 의식적으로 속발음을 하지 않는다는 생각을 지속적으로 하는 것이 중요합니다.

그리고 책을 읽을 때 눈으로는 글자를 읽으면서 속으로 속발음 대신에 숫자를 세는 겁니다. 하나, 둘, 셋...

그러면 속발음을 거의 안하는 자신을 발견하게 될 겁니다.

 

두번째는 한눈에 보이는 문자나 단어의 범위를 넓히는 것입니다.

우리는 글자 하나를 읽을 자음과 모음을 구분해서 읽지 않습니다.

예를 들어, '' 이라는 글자를 'ㄱ','ㅏ','ㅁ' 으로 구분해서 읽지 않고 '감'으로 읽습니다.

또한, 단어도 마찬가지 입니다.' 감자' 라는 단어를 '감', '자' 로 구분해서 읽지 않고 '감자'로 읽습니다.

이런 원리로 두 단어 이상으로 구성된 구(phrase), 절(Clause), 문장(sentence)도 마찬가지로 단어별로 구분하지 않고 한번에 읽기가 가능합니다. 

 

세번째는 손가락으 짚어가면서 읽는 것입니다.

우리가 책을 읽다 보면 바로 전에 읽었던 문장을 되돌아가서 다시 읽을 때가 있습니다.

여러분도 자주 경험을 했을 겁니다. 눈으로만 책을 읽다 보면 어느샌가 집중력이 흩어져서 종종 이런 현상이 발생합니다.

집중력을 유지하기 위한 방법은 바로 여러분의 손에 있었습니다.

이제 책을 읽을 때는 문장을 손가락으로 짚어가면서 눈으로 읽는 연습을 하세요.

눈은 손가락이 가리키는 문장을 좇느라 이전 문장으로 시선이 되돌아갈 일은 발생하지 않습니다.

 

위에서 제시한 세 가지 행동을 지속적으로 훈련하세요.

이런 의식적인동이 자동화되면 새로운 습관이 형성됩니다.

그러면 여러분은 지금보다 2배이상 책을 빨리 읽을 수 있고, 더 많은 지식을 쌓게 될 겁니다.

 

혹시, 빨리 읽으면 기억이 나지 않을까봐 불안하신가요?

여러분의 뇌는 생각보다 매우 뛰어납니다. 뇌를 믿으세요.

위의 방법으로 독서할 때 집중력을 발휘하게 되면 몰입상태가 되어 그동안 해왔던 독서법보다 훨씬 더 많은 양의 정보를 기억하는 현상을 경험하게 될 겁니다.

Posted by Lumasca
,