1-1 DW구축개요, DW구축방법론, OLAP

 

- SW개발 방법론

 

 

https://itboan.tistory.com/category/%EC%A0%95%EB%B3%B4%EA%B4%80%EB%A6%AC%EA%B8%B0%EC%88%A0%EC%82%AC/db

'정보관리기술사/db' 카테고리의 글 목록

 

https://niceit.tistory.com/m/266

 

온달의 IT-World

[기술사/토픽-데이터베이스] 데이터웨어하우징-DW(Data-WareHousing)

 

 

https://blog.naver.com/santalsm/110177357897

 

DW (Data Warehouse),Data Mart,OLAP (Online Analytical Processing),Data Mining, DB Marketing

 

 

DW (Data Warehouse),

Data Mart,

OLAP (Online Analytical Processing),

Data Mining,

DB Marketing

 

DW (Data Warehouse) 1. DW (Data Warehouse) 개요 가. DW의 정의 §사용자의 의사결정을 지원하...

blog.naver.com

​

CNS : 기업의 정보자산을 효율적으로 활용하기 위한 하나의 패러다임으로서, 기업전체의 전략적 관점에서 효율적인 의사결정지원을 위한 모든 형태 데이터의 시계열적인 축적과 통합을 목표호 하는 다양한 기술의 구조적이고 통합적인 환경이다.

(Right Information, Right Time, Right Place)

 

DW정의 : 의사결정지원을 위한 주제지향적(Subject-Oriented), 비휘발성(Nonvolatile), 통합적(Integrated), 시변적(Time-Variant) 데이터들의 집합이다.

 

- 주체지향적

  - 분석업무에 적합하도록 주제별로 분류, 저장

    1. 업무 기능별로 관리되는 다수의 운영 시스템 데이터를 전사관점에서 중복을 최소화하고, 모든 업무에서 공유할

       수 있도록 통합

    2. 전사공통 관심 주체를 중심으로 관련 데이터 통합

    3. 특정 업무 기능이나 애플리케이션에 종속되지 않는 데이터 구조

    4. 데이터 활용으로 인한 데이터체계 변경 영향 최소화

 

- 비휘발성

  - DW에 저장된 데이터는 읽기 전용으로 수정 불가능

    1. 일반적으로 데이터갱신 프로세스가 존재하지 않음

    2. 데이터적재와 데이터 액세스만 존재

    3. 운영시스템에서 발생한 변경 데이터를 갱신하지 않고 Snapshot 형태 반영

    4. 설계 시 데이터 액세스 최적화를 위한 정규화 및 비정규화 설계 중요

 

- 통합성

  - 동일한 의미를 갖는 여러 형식을 하나의 형식으로 통합

    1. 전사 데이터 표준화를 통해 데이터 통합성 구축

    2. 운영시스템으로 부터 데이터 획득 시 데이터통합을 위한 일련의 변환 수행

 

- 시계열적

  - 일정한 기간 동안의 데이터를 저장하여 시점별 분석

    1. 일정 기간 동안의 업무변화 내지는 추세 분석

    2. 이력 데이터를 통해 시간경과에 따른 데이터의 변환 파악 가능

    3. 이력데이터는 일련의 Snapshot 으로 구성

​

구축과정

- OLAP의 유형과 비교

구분	ROLAP	MOLAP	HOLAP
기본구조	관계형 DB	Mult-Demensioal DB	다차원 DB, 관계형 DB
대용량데이터	최적화됨	어려움	가능(혼합사용)
고급분석	일부	적합함	혼합사용으로 가능
핵심기술	다차원모데링, 스타 스키마, 눈송이 스키마	다차원, 데이터 큐브 이용	다차원 DB & Modeling

@ DW (Data Warehouse)

​

- 수년간의 (historical data)

- 기업의 운영계 시스템에서 생긴 내부 데이터와 (internal data)

- 외부 데이터를 (external data)

- 주제별로 통합하여 (subject-oriented)

- 별도의 프로그래밍 없이 (end-user computing)

- 즉시 (on-line)

- 여러 각도에서 분석 가능케 하는 (multi-dimensional analysis) 통합 시스템

​

​

* DW 필요성 및 도입배경

​

1) 정보기술에 대한 시대적 요구

l 변화에 민감하고 신속히 대응해야 한다.

l 신제품, 신서비스의 개발과정이 과학적이고 신속해야 한다.

l 고객정보 시스템을 구축해야 한다.

l 사용자 중심의 컴퓨팅 환경으로 바뀌어야 한다.

2) 기존의 전산시스템 환경

l 데이터를 신속하게 분석 예측하기 힘들다.

l 통합된 보고서를 작성하기 힘들다.

l 비정형화된 장표를 만드는 시간이 많이 걸린다.

​

 

* DW 기본 구성도

​

① 데이터는 운영계 시스템에서 추출하여 DW서버로 로드된다.(데이터의 추출과 로드)

② DW에서만 적용되는 다차원 모델링을 한다.(multi-dimensional modeling)

③ 여러 방식과 도구로 사용자 액세스한다. (End user access)

​

 

* DW 구축효과

​

l 정형화된 장표를 빠르고 쉽게 볼 수 있다.

l 비정형화된 장표를 비교적 빠르게 분석할 수 있다.

l 데이터를 분석, 예측할 수 있다.

l 기업의 데이터 인프라로 자리잡는다.

​

* DW 구축순서

​

① 데이터 웨어하우스의 목표를 세운다.

② 전체적 전략을 세운다. ex) cross sell, up sell

③ 전술을 세운다. ex) 우수고객을 구분하기 위한 기준을 세운다.

④ 전술을 성취하기 위한 구체적인 자료를 정의한다. ex) 우수고객 자료, 고객의구매력 등 자료정리.

⑤ 데이터 웨어하우스에 들어갈 데이터를 정의한다.

⑥ 이 데이터를 운영계 시스템에 있는 데이터와 mapping 한다.

​

 

https://m.blog.naver.com/ziko00/20012657142

[펌] DW구축 방법론

DW (Data Warehouse) 구축방법론

DW (Data Warehouse) 구축방법론

 

요건정의 (DW Requirement Definition)
-.사용자 요구사항을 정의하고, 사용자 요구사항에 맞도록 시스템을 설계,구축
-.프로젝트의 추진 방향과 전략을 결정하고 현행 시스템을 분석하여 데이터모델을 정의. DB생성에 대한 준비를 하며, 그 결과를 확인.

데이터 추출 (Data Acquisition)
기존 시스템으로부터 데이터를 추출하고 로딩하기 위한 요건을 분석하고, 설계 및 프로그래밍
Tool을 활용할 경우에는 Tool선정 및 기능검토, 추가개발에 대한 요건 정의.
ETL에 필요한 제반 내용을 정의하고,구현
이 과정은 데이터의 품질에 대한 고려가 필요하며, 부정확한 데이터에 대한 처리과정도 고려


기술환경 (Technical Architecture)
시스템을 구축하기 위해 필요한 기술적 아키텍쳐 정의
시스템 구축 시 상당히 다양한 시스템이나 툴들이 사용될 수 있으며, 현 시스템 기술환경의 확장성 여부 등도 고려


데이터 품질 (Data Quality)
데이터의 품질을 확보할 수 있는 방안을 수립하고, 데이터 정제, 통합규칙, 오류, 예외처리 규칙을 정의
품질검사 및 관리를 위한 모듈을 구현


메타데이터 관리 (Metadata Management)
전사 데이터표준 및 사전을 기반으로 하여 메타 데이터 정의
메타데이터의 요건을 분석, 시스템에서 효율적으로 사용할 수 있도록 구현하며, 메타데이터의 관리방법 정의


데이터베이스 설계 및 구축 (Database Design and Build)
통합 데이터 시스템을 구축하기 위해 필요한 관계형 또는 다차원 데이터베이스에 대한 논리적인 모델을 작성하고, 물리적 구조를 설계
정의된 논리/물리 모델을 바탕으로 DB생성 스크립트를 작성하고, 이를 이용하여 DB를 구축


데이터 액세스 (Data Access)
구축된 시스템을 최종 사용자가 효율적으로 사용할 수 있도록 요건을 정의하고, 설계
데이터 액세스를 위한 Tool을 사용할 경우 이에 대한 화면설계
툴의 기능으로 구현될 수 없는 경우에는 개발여부를 확정하고, 이에 대한 구현작업을 수행


테스트 (Testing)
테스트 환경 준비 (테스트 요구사항, 테스트 일정, 주체, 시나리오 및 관련 환경) , 통합테스트 및 고객 Acceptance Test 등을 시행


적용 (Adoption and Learning)
구축된 시스템을 실제 사용하는 조직에 적용하고 정착시키기 위한 작업을 정의
프로젝트 초반에 운영 및 적용에 필요한 계획을 수립, 시스템 관리 및 운영 절차도 포함하여 정의

 

 

 

----------------------------------------------------------------------------

* OLAP Tool

 

    l Data Warehouse 에 있는 데이터를 사용자가 access 하는 tool 이다.

    l 시간, 비용, 인력을 절감할 수 있다.

    l 비정형화된 장표를 만드는 유일한 수단이 OLAP tool 이다.

    l 사용자 중심의 컴퓨팅을 실현할 수 있다.

 

 

@ OLAP 구현 방식

​

① MOLAP(MDB-based OLAP)

​

초기 OLAP 선구자 등은 column 과 row 형태의 2 차원적인 구조를 가진 관계형 데이터베이스로 다차원 분석을 하는 것이 어렵다(SQL 의 한계)고 생각하여 OLAP 전용의 새로운 형태의 데이터베이스를만들었는데 바로 다차원 데이터베이스 (Multidimensional Database : MDB)이다.

다차원 데이터베이스는 관계형 데이터베이스보다는 덜 복잡하지만 기본적으로 데이터베이스가 가지고있는 구조, 운영, 백업과 복구, 튜닝 등 많은 문제점이 존재한다.

    l 장점 : 다차원적인 분석을 빠르게 할 수 있다.

    l 단점 : 원시 데이터를 볼 수 없다.

              대용량의 데이터를 취급하기에 역부족이다.

              데이터를 로딩하는데 시간이 많이 걸린다.

​

  i) MOLAP 서버에서 사용자의 요구조건에 따라 업무 분석을 한다.

    이때 차원, 각종변수, 함수 등이 정의된다.

  ii) 정의된 형식에 의해 데이터를 운영계 시스템에서 가져온다.

  iii) SAM file 직접 로딩.

  iv) 관계형 DB 를 통한 SQL 로딩.

  v) MOLAP 서버에서 데이터를 각종 차원정의에 따라서 내부적으로 계산하는 roll-up프로세싱을 한다.

  vi) MOLAP Client 가 서버의 데이터를 access.

 

② ROLAP(Relational OLAP, RDB-based OLAP)

​

MOLAP 의 단점인 원시 데이터의 취급과 대용량 데이터를 처리할 수 없는 확장성의 한계를 극복하기위해서 나왔다.

관계형 데이터베이스를 그대로 사용하며 다차원적인 데이터 모델링을 통해서 다차원적인 분석이 가능하도록 하는 방식이다. (Star Schema, Snowflake Schema)

 

  i) 사용자의 요구사항을 도출한다.

  ii) DW 에서 스타 스키마 또는 스노우플레이크 스키마를 사용하여 다차원 모델링을 한다.

  iii) 다차원 모델링을 하면 차원과 사실 테이블이 생긴다.

  iv) 운영계 시스템에서 데이터를 추출하여 두 개의 테이블에 로딩한다.

  v) ROLAP admin tool 을 사용하여 두 테이블에 대한 여러 가지 정의를 입력시킨다.(메타 데이터 입력)

  vi) ROLAP end user tool 을 사용하여 DW 에 login 하면 원하는 데이터들이 나타난다.

 

③ HOLAP(Hybrid OLAP)

​

MOLAP 의 단점을 보강하기 위해 관계형 DB 에 있는 데이터를 access 할 수 있는 기능을 추가하였다.

​

  i) 데이터를 SAM 이나 관계형 DB 테이블을 이용해서 MOLAP 서버에 로딩한다. 이때 관계형 DB 는

     ER 모델링이 아니라 다차원 모델링으로 되어 있다.

  ii) MOLAP 서버 내의 관리자용 소프트웨어가 차원 테이블과 사실테이블에 대한 정보를 입력한다.

  iii) MOLAP client 가 MOLAP 서버에 있는 데이터를 access 할 때, 데이터가 있으면 그대로 보여주고

    없으면관계형 DB 에서 가지고 온다.

​

* 어떤 OLAP 솔루션을 사용할 것인가.​

​

l ROLAP

대용량(전사적) 데이터 웨어하우스를 구축.

원시 데이터(고객 이름, 전화번호 등)를 출력하는 것이 중요한 데이터베이스 마케팅같은 분야.

​

l MOLAP

트랜드 분석, 회귀분석, 각종 변수를 바꾸어가면서 다양한 분석을 하는 것이 중요한 경우.

구축 시간이 없는 경우, 비용의 여유가 없는 경우,

기존의 업무를 분석하는데 일부 추가하고 싶을 경우, 부서 내에서 사용할 경우(데이터 마트)

​

@ ROLAP (Relational OLAP, RDB-based OLAP)

​ROLAP 은 기존의 관계형 데이터베이스에서 다차원적인 분석을 할 수 있다는 생각에서 만들어진 OLAP 이다. ROLAP 은 내부적으로 SQL 을 만들어주는 프로그램이다.

 

* ROLAP 의 구조

​

Step 1 : 메타 데이터를 입력한다.

l 사용자의 요구사항을 분석하고 요구사항에 따라 다차원 모델링을 한다.

l 개발자들이 다차원 모델링에서 정의된 내용에 따라 테이블, 인덱스, key, 제약조건, view 등을 만든다.

l 만든 내용을 ROLAP 관리자용 버전에 입력하고, 사용자들이 보기 원하는 주제영역, 차원, 구체적 정보 등을입력한다.

 

Step 2 : 메타 데이터의 생성과 보관

l ROLAP 관리자용 버전은 입력정보를 받아서 메타 데이터를 생성한다.(메타 데이터 역시 관계형 데이터베이스 테이블이다.)

 

Step 3 : 사용자가 ROLAP 사용자 버전으로 액세스

l 사용자가 원하는 정보를 보기 위해 query 를 던진다.

 

Step 4 : ROLAP 엔진이 메타 데이터를 reference 한다.

l 사용자 화면 인터페이스가 ROLAP 엔진에 사용자의 요구를 알리면 어떤 테이블에서 어떤 컬럼을 가져와야하는지를 결정하기 위해 메타 데이터에 query 를 던진다. 이 query 는 SQL 로 되어 있다.

 

Step 5 : 메타 데이터에서 원하는 정보를 추출한다.

l SQL 로 원하는 정보를 추출한다.

 

Step 6 : ROLAP 엔진에서 다이나믹하게 SQL 을 제작

l 정보를 분석하고 나서 여러 복잡한 법칙에 따라 SQL 을 만든다.

SELECT(column 명), FROM(table 명), WHRER(조건절), GROUP BY(차원들)

l ROLAP 의 핵심은 SQL 문장을 관계형 데이터베이스에 최적으로 만들어졌는가에 달려 있다.

 

Step 7 : 데이터 웨어하우스에서 SQL 프로세싱을 한다.

l 생성된 SQL 을 데이터 웨어하우스로 보낸다.

l 관계형 데이터베이스는 이를 처리하고 엔진은 기계적으로 프로세싱한다.

l 프로세싱이 끝나면 결과를 ROLAP 엔진으로 보내고 ROLAP 엔진은 이 결과를 캐싱(caching) 해준다.

 

Step 8 : 사용자가 원하는 형식으로 포맷

l 결과를 사용자가 보기 좋게 만들어 준다.

 

​

* ROLAP Architecture

l 1 Tier 구조 (ROLAP 클라이언트 + 개인용 관계형 데이터베이스)

l 2 Tier 구조 (ROLAP 클라이언트 + 데이터 웨어하우스 서버)

l 3 Tier 구조 (ROLAP 클라이언트 + ROLAP 서버 + 데이터 웨어하우스 서버)

l 4 Tier 구조 (웹 브라우저 + 웹 서버 + ROLAP 서버 + 데이터 웨어하우스 서버)

 

 

* ROLAP 서버

​

ROLAP 서버는 데이터를 가지고 있지 않다. 모든 데이터는 데이터 웨어하우스에 있다. 많이 access 하는 것을ROLAP 서버가 caching 하는 경우는 있으나 실제 데이터는 모두 데이터 웨어하우스에 있다.

그러나 MOLAP 서버는 그 안에 다차원 데이터베이스가 들어 있기 때문에 반드시 데이터를 가지고 있어야 한다.

l report scheduling and caching

l asynchronous query processing

l monitoring

l query governing

l security

​

​

@ 다차원 모델링

​

다차원 분석은 ROLAP 과 MOLAP 모두 할 수 있다. 그러나 MOLAP 에서는 다차원 데이터베이스 구조 자체에서 지원하기 때문에 다차원 분석을 위한 특별한 모델링이 필요치 않다.

l ER-모델링 : OLTP 시스템에서 빈번한 데이터의 변환에 대한 전체데이터의 무결성에 중점.

l 다차원 모델링 : 사용자의 다양한 요구사항을 충족시키는 복잡한 질의를 신속하게 처리하는 데 목적.

​

* 다차원 모델링 (Multidimensional Modeling)

​

l 차원 : 기간(년/분기/월), 조직(본부/지사/영업소)

l 사실 : 매출액, 매출수량

 

다차원 모델링은 이러한 차원과 사실 컬럼을 복합하여 관계형 데이터베이스 테이블로 만든다.

 

1) 스노우 플레이크 스키마(Snowflake Schema)

 

l 특징 : 차원요소마다 1 개의 차원 테이블을 가지고 있고, 이 차원 테이블에는 차원요소에 대한 정보와 상위차원테이블로 조인하기 위한 Key 를 가지고 있다. 각 차원 테이블은 정규화가 잘 되어 있어 중복이 안 된다. 크기도 작다.

l 스타조인(star join) : 여러 개의 작은 테이블과 한 개의 큰 테이블을 조인하는 것이다.

 

스노우 플래이크 스키마의 단점은 차원 테이블이 많기 때문에 스타 조인을 많이 해야 한다.

 

2) 스타스키마(Star Schema)

 

스타 스키마는 각 차원마다 하나씩 차원 테이블이 있다.

스타스키마의 장점은 조인 수가 적다.

 

​

3) 요약(Summary)

 

많이 사용되는 차원 요소를 결합하여 요약 테이블을 만들어 놓는다면 질의응답 시간이 많이 줄어들게 된다. 이러한 요약과정은 주로 SQL 스크립트를 만들어 정해진 시간에 수행한다.

요약 테이블이 많을수록 관리문제와 요약 테이블간의 데이터의 무결성(integrity) 문제가 생긴다.

요약 테이블을 만드는 기준은 요약을 했을 때 요약 테이블의 크기나 응답시간이 1/10정도로 단축되는 것에 둔다. 왜냐하면 사용자는 1/10 정도로 단축되었을 때만 빠르다고 느낄 수 있기 때문.

 

4) 다차원 모델의 중요한 Tips

 

① 스키마의 무결성에 유의하라.

DW 에서 사용되는 정보는 기존의 여러 시스템에서 나온다. 따라서 동음이의어(Synonym)의 문제가 발생.

만약 A 시스템에서 매출금액은 카드별 매출금액이고, B 시스템에서 매출금액은 고객별 매출금액이라고 할 경우 매출금액은 동음이의어이다.

이것은 정제된 후 DW 에 저장되어야 한다.

 

②Bitmap Index 를 많이 사용하라.

데이터의 변화정도(cardinality)가 크지 않을 경우 반드시 사용해야 한다. 예를 들면, 연령대별, 성별, 직업별, 고객의 구분 등 등급을 나누어 분석할 때 최적이다.

 

③ 뷰(View)를 절제하라.

구축 중에는 테이블의 구조가 바뀔 상황이 많기 때문에 많은 뷰의 남용은 관리와 성능에 문제가 발생한다.

뷰를 계속 만든다면 사용이 편리하다는 이득 외에는 별다른 이득이 없다.

 

④ ROLAP 엔진이 만드는 SQL 의 적합성을 검증하라.

다차원 모델링은 채택하는 ROLAP 도구에 따라 상당히 달라진다. ROLAP 도구가 지원하는 여러 가지 기능을잘 알고 있어야 그 ROLAP 도구에 맞는 최적의 모델링을 할 수 있다.

​

--------------------------------------------------------------------------

@ 데이터 추출, 가공, 로드 (ETT)

​

* ETT의 개념

​

​

ETT 는 데이터의 추출(Extraction), 가공(Transformation), 전송(Transportation)의 약자. 데이터를 소스시스템에서 추출하여 데이터 웨어하우스에 로드시킨 상태에서 정제 작업까지 이르는 전 과정.

​

ETT 의 방법은 소스 시스템의 종류, 데이터의 추출주기, 데이터의 양, 로딩속도, 소스데이터의 질, 과거 데이터의 형식, 사용자의 요구 조건, 소스 시스템의 역할 등에 따라 달라진다.

 

* ETT 의 형태

 

DW 에서 필요한 최종 테이블은 사실 테이블이다. 여기서 여러 가지 요약 테이블을 생성한다. 다른 한 종류의테이블은 차원 테이블인데 용량이 크지 않아 쉽게 데이터를 로딩할 수 있다. 따라서 DW 에서는 사실 테이블과요약 테이블만 있으면 실제 사용자가 데이터를 볼 수 있다.

 

l 사실 테이블과 요약 테이블을 어디서 만들 것인가?

- 소스 시스템 : DW 에서는 할 일이 많지 않다.

- 소스 시스템에서 아무것도 하지 않고 DB 의 로그 파일을 분석하여 바뀐 데이터를 추출, DW 에서 다시 데이터를 재조합.

 

* 데이터의 변환(Transformation)

 

l DW 의 사실 테이블이 특정한 포맷으로 되어 있다.

l 사용자의 요구사항이 간단치 않기 때문에 여러 소스 시스템 테이블을 조합해야만 한다. 예를 들면, 매출이라는 주제 영역에서 총매출액과 신용판매 금액을 보고 싶은데 총매출액은 매출관리 시스템에, 신용판매 금액은 신용판매 시스템에 따로 들어 있다면 당연히 두 시스템을 합쳐야 한다.

l 소스 데이터의 코드가 일치하지 않기 때문이다. 예를 들면, 제품 코드가 매출관리 시스템이나 신용 판매 시스템과 상이하다면 이를 하나로 통합해야 한다.

 

 

* 데이터의 정제(Data Cleansing)

 

DW 에 들어가는 데이터는 100% 정제 되어야 한다.

l 서울지사 코드가 001 인데 소스 시스템에는 0001 이라고 되었을 경우.

l 날짜가 9 월 31 일인 경우.

 

SAM 을 이용한 데이터 정제작업

데이터가 UNIX 파일로 들어올 때, 많은 사용자 프로그램이나 UNIX 스크립트를 사용.

 

ODS(Operational Data Store)를 이용한 데이터 정제

ODS 는 DW 의 사실 테이블로 가는 중간단계의 데이터 저장장소이다.

 

 

* ODS 의 역할

 

l 데이터 가공, 변환, 정제작업을 용이하게 해준다.

l 원시 데이터를 가지고 있어서 사용자의 요구 조건의 변화에 신속히 대응할 수 있도록 해준다.

l 사실 테이블에 문제가 생겼을 때 신속히 복구해 준다.

 

데이터의 가공, 변환, 정제 작업은 일단 데이터를 DB 에 올려놓고 하는 것이 편리하다. 왜냐하면 DB 에 최적화되어 있는 SQL 을 사용할 수 있기 때문이다.

​

​

* ETT 방식

​

1) 오프라인 방식

2) 온라인 방식

 

 

정규화의 절차

 

 

정규화

 

Normalization

- 데이터 이상현상을 제거하기 위해 스키마 변환의 3원칙(정보무손실, 최소중복만허용, 분리원칙)으로 릴레이션을 분해하는 과정

- 정규형 Normal Form(NF)

함수적종속성 제거하는 정규화를 통해 이상현상 제거

구분	단계	내용	특성
기본 정규화	1차 정규화 (1NF)	- 반복되는 속성 제거 → 의존자의 중복을 없애는 작업 - Relation R에 속한 모든 도메인이 원자값(atomic value) 만으로 되어 있는 경우 - 다치속성 : 두개이상의 값을 갖는 속성(취미, 색이 섞인 자동차) - 복합속성 : 쪼갤 수 있지만 묶음으로 사용하는 속성(주소)	데이터간 중복성이 강함 ▲ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ▼ 데이터간 결합성이 강함
	2차 정규화 (2NF)	- 부분 함수 종속성 제거 - 두 개의 결정자(합성키) 존재 - Relation R이 1NF이고 Relation의 기본키가 아닌 속성들이 기본키에 완전히 함수적으로 종속할 경우 - 결정자가 2개 이상일 때, 2개 중에서 하나의 결정자에 의해서만 함수종속성인 경우
	3차 정규화 (3NF)	- 이행함수 종속성 제거 - 의존자에서 FD 관계가 있다면 Table 분리 - Relation R이 2NF이고 기본키가 아닌 모든 속성들이 기본키에 대하여 이행적 함수 종속성(Transitive FD)의 관계를 가지지 않는경우, 즉 기본키외의 속성들간에 함수적 종속적을 가지지 않는 경우
	BCNF (Boyce/Codd NF)	- 결정자 함수 종속성제거 - Relation R의 모든 결정자가 후보키일 경우 - 결정자들 간의 함수적 종속이 있는 경우
고급 정규화	4차 정규화 (4NF)	- 다중값 종속성 제거 - BCNF를 만족시키면서 다중값 종속을 포함하지 않는 경우
	5차 정규화 (5NF)	- 결함 종속성 제거 - 4NF를 만족시키면서 후보키를 통해서만 조인 종속이 성립되는 경우

​

[출처] 정규화|작성자 기술사를위해

 

 

반정규화

 

De-Normalization : 정규화로 분해된 릴레이션을 성능향상, 운영단순화를 위해 중복, 통합, 분리 등을 수행하는 모델링 기법

​

주요기법

필요성	주요 기법	설명
테이블 레벨	테이블 병합	- 1:1관계 테이블 병합, 1:M 관계 테이블 병합 - Super/Sub 타입 관계 테이블 병합
	테이블 분할	- 테이블 수직 분할: 잦은 접근 컬럼과 낮은 접근 컬럼을 분리 - 테이블 수평 분할: 동일한 컬럼을 데이터 기준으로 수평 분할하여 partition 적용으로 성능 향상
	테이블 추가	- 통계 테이블 추가: 통계 정보를 위해 조회 빈도가 높은 컬럼을 테이블로 생성 - 이력 테이블 추가: 이력성 정보 조회를 위한 별도 테이블 생성 - 중복 테이블 추가: 다른 업무이거나 서버가 다른 경우 동일한 테이블 구조를 중복하여 원격 join 제거 - 부분 테이블 추가: 자주 이용하는 컬럼들을 별도의 테이블로 생성
컬럼 레벨	중복 컬럼 추가	- 갱신보다 조회 성능이 더 중요할 때 양쪽 테이블에 중복 저장 - Join 비용은 감소하나, 갱신 비용이 증가함
	PK에 의한 컬럼 추가	- 복합 의미를 갖는 PK를 단일 속성으로 구성할 때, PK 안에서 특정 값을 별도로 조회할 경우 성능 저하 발생 - PK의 데이터를 일반 속성으로 추가하여 성능 향상
	계산 컬럼 추가	- 여러 테이블 join 후 계산이 필요한 경우 계산 결과 컬럼 추가 - Join 비용은 감소하나, 갱신 비용이 증가함
	응용 수준 오작동 대비 컬럼 추가	- 데이터 처리 중 원래 값으로 복구하기 원할 경우를 대비하여 이전 데이터를 임시적으로 중복 보관하는 기법
	이력 컬럼 추가	- 변경 이력, 발생 이력 정보를 위한 최신 정보 컬럼 추가
관계 레벨	중복 관계 추가	- 관계가 먼 데이터 간에 join이 빈번하게 발생할 경우 관계 추가 - 무결성 훼손 없이 반정규화 통한 성능 개선 가능

반정규화 사례

​

[출처] 반정규화|작성자 기술사를위해

 

 

데이터베이스 모델링

정의 - 사용자요구사항 분석, 개념적, 논리적, 물리적 모델링 과정을 수행하여 업무프로세스를 데이터베이스로 추상화하는 기법

​

데이터 모델링 단계

단계	설명	수준
요구사항 수집 및 분석	- 현실세계의 대상 및 사용자의 요구 등을 정리 및 분석 - 사용자식별 - 데이터베이스 용도 식별 - 사용자 요구사항 수집 및 명세	추상적 ↑ | | | | | | | | | | ↓ 구체적
개념적 데이터 모델링	- 해당 조직의 업무요건을 충족하기 위해서 주제영역과 핵심 데이터 집합, 핵심 데이터 집합간의 관계를 정의하는 상위수준의 개략적 데이터 설계작업 - 추상화 수준 높고 업무중심적, 포괄적인 수준 모델링 진행 - 핵심 엔티티 추출, 핵심속성 및 관계 정의
논리적 데이터 모델링	- 업무의 모습을 모델링 표기법으로 형상화하여 사람이 이해하기 쉽게 표현함 - 구축 시스템 업무에 대해 Key, 속성, 관계 등을 정확히 표현, 재사용성을 높임. 식별자 확정, 정규화 수행
물리적 데이터 모델링	- 데이터베이스 이식 가능 하도록 성능, 물리적 성격을 고려하여 설계 - 특정 DBMS의 특성 및 종류, 구현환경을 감안한 스키마 도출 - 컬럼의 데이터 타입과 크기, 제약조건/인덱스 정의

데이터모델링의 3가지 관점

관 점	설 명
데이터 관점	- 업무가 어떤 데이터와 관련이 있는지, 데이터간의 관계는 무엇인 지에 대해 모델링하는 방법
프로세스 관점	- 업무를 통해 어떤 일을 처리하는지, 무엇을 해야 하는지를 모델링하는 방법
데이터와 프로세스의 상관 관점	- 업무에서 처리하는 일의 방법에 따라 데이터가 어떻게 영향을 받는지 모델링하는 방법 (상관모델링, CRUD Matrix 기법) [출처] 데이터베이스 모델링|작성자 기술사를위해

개발 프로젝트 산출물 목록

2018.05.14 21:38

PROJECT, 프로젝트

/*******************************************************************************************************************
-- Title : [PJT] 개발 프로젝트 산출물 목록
-- Reference : baobab.pe.kr/pds/269051
-- Key word : 프로젝트 project 산출물 output
*******************************************************************************************************************/

1. 분석

1.1. 현업요구사항정의서
: 해당 프로젝트를 수행하는 가장 기본이 되며 고객의 needs을 담고 있는 문서입니다.

이를 통해 다양한 스펙산정이 가능합니다. 이부분에서 요구ID를 도출합니다.
1.2. 기능챠트
: 현업요구사항을 근간으로 큰 카테고리를 만들어 한눈에 해당 프로젝트가 무슨 일을 하는

것인지 보여줄 있습니다.
* 이부분은 개발방법론에 따라 유스케이스다이어그램으로 대치할 수도 있을 것으로

판단되어지고, 기능챠트와 같이 가도 무관하다는 판단입니다.
1.3. 프로세스 정의서
: 기능챠트를 기준으로 각각의 프로세스를 보여줍니다. 때에 따라 확대된 프로세스의

표현도 가능합니다.
* 개발방법론에 따라 시퀀스다이어그램을 넣어도 무방하다는 판단입니다.
1.4. 인터페이스정의서
: 상기 현업요구사항정의서,기능챠트,프로세스정의서를 근간으로하여 레가시 및 대외계

시스템, 웹서비스 등 어떤식으로 인터페이스를 해야 한다는 정의를 담고 있습니다.
1.5. 기타

2. 설계
2.1. UI(화면)설계서
: 웹App 혹은 CS App 든 간에 고객이 사용하고자 하는 화면단을 보여주는 문서입니다.
2.2. ERD
: 해당 업무의 DB를 생성하고 테이블관의 상관 관계를 표현하는 문서로 더이상 설명이

필요없으리라 믿습니다.
2.3. 테이블목록
: 테이블정의서도 있지만, 테이블목록은 관리자가 한눈에 시스템을 구성하고 있는 DB

테이블을 보여준다는 측면에서 필수라는 판단입니다.
2.4. 테이블정의서
: 테이블필드 value와 설명, 바이트수 등을 표기합니다.

2.5. 프로그램 목록
: 실직적으로 설계단계에 프로그램목록이 나오지 않지만 일단 설계 단계에 넣는 것이

타당한 것 같습니다.
* 개발방법론에 따라 클래스다이어그램, 컨포넌트명세서, 클래스정의서 등도 포함 될 수

있을 것 같습니다.
2.6. 개발표준 정의서
: 변수명, brace, 클래스네임,파일명,규칙등 코딩관련 규칙을 정의함으로써 일선 담당자가

소스코드를 확인해도 눈에 익숙할 수 있게 하기위한 문서입니다.
2.7. 단위테스트 시나리오
: 분석,설계의 기본적인 요건이 충적되면 이쯤하여 단위테스트시나리오가 나와야 할 것

같습니다. 아마도 고객의 싸인이 필요한 부분일 것입니다.
2.8. 통합테스트 시나리오
: 설계단에서 하기는 많은 어려움이 있지만, 단위테스트를 근간으로 고객의 요청을 좀더

보완하여 통합테스트시나리오를 작성합니다. 고객의 싸인은 필수입니다.
2.9. 기타

3. 개발
3.1. 소스코드(개발원시코드)
: 말그대로 오류수정까지 끝난 원시코드 자체를 말합니다.
3.2. 단위테스트 결과서
: 단위테스트시나리오를 기준으로 테스트한 결과를 보여줍니다. 아마도 많은 문제점을

안고 있고, 이 과정을 통해 고객의 요구사항도 많은 변동이 있는 시점입니다.
* 변경요청서도 필요할 시점입니다.
3.3. 결함/오류보고서
: 단위테스트를 통해 알게된 에러의 원인과 수정에 대한 내용을 나타냅니다.

이를 통해 오류코드정의서를 뽑아내고 보완합니다.
3.4. 오류코드 정의서
: 해당시스템에서 발생할 수 있는 오류들을 코드화하여 보여줍니다.
3.5. 통합테스트 결과서
: 단위테스트를 통해 보완된 내용들을 포함하고, 통합테스트시나리오의 보완을 통해

실시된 통합테스트 결과를 보여줍니다. 개발을 완료했냐 안했냐의 잣대가 되는 문서로서

고객의 싸인이 가장 필요한 부분입니다. 이부분에서 반려가 일어나면 위의과정을 반복해야

합니다.
3.6. 시스템 이행계획서
: 통합테스트가 끝나면 Standby하고 있는 시스템에 소프트웨어,하드웨어 기타 등을 몇월,

며칠, 몇시에 누구누구가 무엇을 가지고 옵져버는 누구이며 어떻게 이행을 할 것인지

등을 표현합니다.
3.7. 기타

4. 구현
4.1. 시스템 이행결과서
: 시스템 이행계획서를 통해 이행된 결과를 확인받는 문서입니다.
4.2. 사용자매뉴얼
: 사용자화면이 있을 경우 나오는 매뉴얼입니다.일반적인 조작법을 기록하며, 화면 등을

예시합니다.
4.3. 운영자매뉴얼
: 시스템전반에 관한 모든 내용을 담고 있습니다. 분석,설계,개발 절차에서 나오는 문서를

담고 있습니다.
4.4. 교육(인수)명세서
: 사용자매뉴얼 및 운영자매뉴얼을 중심으로 해당 담당자 및 사용자에게 시스템전반 및

세부사항을 교육/인수한후 싸인받는 문서입니다.
4.5. 개발산출물별 검사리스트
: 예시된 산출물들이 이상없이 인수되었는지를 개별로 체크한후 고객의 싸인을 받는

문서입니다.
4.6. 프로젝트 완료보고서
: 최종적으로 개발한 내용, 인도물, 하드웨어, 고객대표, 개발자대표싸인을 받음으로써

명실상부한 프로젝트 완료보고서입니다.
4.7. 기타

 

출처: https://dbrang.tistory.com/1351?category=638637 [dBRang [dɪ'·bɪ·raŋ]]