Dev Diary.

1번만에 붙어서 다행ㅠㅠ

이제 알고리즘, 스프링공부 집중!

가답안기준 평균 95점으로 합격!!!!! 

책 배송오는대로 실기합격까지 달려보자

5. 정보시스템 구축 관리

 5.3 소프트웨어 개발 보안 구축

  5.3.1 소프트웨어 개발 보안 구축 능력 단위 정의

  5.3.2 SW개발 보안 설계

- SW개발 보안 구축 능력 단위 정의

SW개발 보안 구축이란 정의된 보안 요구사항에 따라 SW의 보안 요구사항을 명세하고 이에 따라SW에 대한 보안을 설계, 구현, 테스트하는 능력이다.

- SW개발 보안 설계

1 Secure SDLC

1.1 Secure SDLC

SW개발과정에서 개발자의 실수, 논리적 오류 등으로 인해 발생될 수 있는 보안 취약점, 보안약점들을 최소하하여 사이버 보안위협에 대응할 수 있는 안전한 SW를 개발하기 위한 일련의 보안활동을 의미한다.

목적은 각 단계별로 요구되는 보안활동을 수행함으로써 안전한 소프트웨어를 만들 수 있도록 한다.

1.2 소프트웨어 개발 보안 생명주기 

시큐어 코딩을 위한 개발방법론은 기존의 SW개발 생명주기에서 보안활동을 추가하는 것으로 기존의 SDLC는 폭포수 모델, 프로토 타입, 나선형 모델 등이 존재한다.

2. 소프트웨어 개발 보안 생명주기 방법론 유형

2.1 MS-SDL

MS에서 보안수준이 높은 안전한 소프트웨어를 개발하기 위해 자체수립한 SDL이다

방법론이 적용되기 전 버전보다 50% 이상 취약점 감소한다.

교육부터 대응까지 총 7단계로 구분

2.2 Seven Touchpoint

실무적으로 검증된 개발보안 방법론 중 하나로써 SW 보안의 모범 사례를 SDLC에 통합한 방법론이다.

7개의 보안강화 활동을 정의

2.3 CLASP

소프트웨어 개발 생명주기 초기단계에 보안강화를 목적으로 하는 정형화된 프로세스로써, 활동중심 역할기반의 프로세스로 구성된 집합체이다.

이미 운영중이 시스템에 적용하기 좋음

개념, 역할기반, 활동평가, 활동 구현, 취약성의 5가지 관점에 따라 개발보안 프로세스를 수행할 것을 제안

2.4 CWE

SW 보안약점은 7개의 큰 항목과 47개의 세부 항목으로 구분된다

1. 입력데이터검증 및 표현 : XSS, SQL삽입, 버퍼오버플로우 등

2. 보안기능 : 중요정보 평문저장, 하드코딩된 패스워드

3. 시간 및 상태 : Deadlock자원에 대한 경쟁조건, 세션고착

4. 에러처리 : 처리루틴 누착, 정보 노출

5. 코드품질 : 널 포인트 역참조, 부적절한 자원 해제

6. 캡슐화 : 디버거 코드, 시스템 데이터 정보

7. API악용 : DNS Lookup에 의존한 보안 결정

보안 약점은 SW결함의 한 종류로 보안취약점을 유발하는 원인이다.

보안 취약점은 해커가 시스템 접근 권한 획득 등 직접 이용할 수 있는 SW 상의 결함이다.

3. 입력데이터 검증 및 표현

프로그램 입력 값에 대한 부적절한 검증 등으로 인해 발생할 수 있는 보안약점

1.1 SQL삽입

데이터베이스와 연동된 웹 어플리케이션에서 입력된 데이터의 유효성 검증을 하지 않은 경우 발생

공격자가 입력 폼 및 URL 입력란에 SQL 문을 삽입하여 DB로부터 정보를 열람하거나 조작할 수 있는 약점을 말함

1.2 크로스사이트스크립트

웹페이지에 악의적인 스크립트를 포함시켜 사용자측에서 실행되게 유도하여, 정보유출 등의 공격을 유발할 수 있는 취약점

1.3 크로스사이트 요청 위조(CSRF)

서버로 요청하는 쿼리를 임의로 조작하여 실행하게 하는 공격으로 피해자의 권한을 이용하여 공격도 가능

CSRF XSS 차이점

CSRF는 피해자의 권한을 이용하여 피해자가 조작된 패킷을 전송하여 이 결과로 공격자가 이득을 얻는 형태의 공격

XSS는 악성 스크립트가 실행되어 클라이언트를 공격하는 것이다.

1.4 위험한 형식 파일 업로드

서버측에서 실행될 수 있는 스크립트 파일이 업로드 가능하고, 이파일을 공격자가 웹을 통해 직접 실행시킬 수 있는 경우, 시스템 내부명령어를 실행하거나 외부와 연결하여 시스템을 제어할 수 있는 취약점으로 대표적으로 웹셸을 이용한 업로드 공격이 있다.

1.5 디렉토리 경로 조작

외부의 입력을 통하여 디렉토리 경로 문자열 생성이 필요한 경우, 외부입력값에 대해 경로 조작에 사용될 수 있는 문자를 필터링하지 않으면, 예상 밖의 접근 제한 영역에 대한 경로 문자열 구성이 가능해 시스템 정보누출, 서비스 장애 등을 유발 가능, 즉 , 경로 조작을 통해서 공격자가 허용되지 않은 권한을 획득하여 설정에 관계된 파일을 변경하거나 실행 시 킬 수 있다.

4. 보안기능

인증, 접근제어, 권한 관리 등을 적절하지 않게 구현시 발생할 수 있는 보안약점

4.1 사용자 중요정보 평문 저장

프로그램이 보안과 관련된 민감함 데이터를 평문으로 통신채널을 통해서 송/수신 할 경우, 통신채널 스니핑을 통해 인가되지 않은 사용자에게 민감한 데이터가 노출될 수 있음

4.2 하드코드로 되어있는 패스워드

프로그램 코드 내부에 하드코드로 되어 있는 패스워드를 포함하고, 이를 이용하여 내부 인증에 사용하거나 외부 컴포넌트와 통신을 하는 것은 위험하다 또한 코드 내부에 하드코드로 되어 있는 패스워드가 인증실패를 야기하는 경우, 시스템관리자가 그 실패의 원인을 탐지하는 것도 용이하지 않다.

5. 에러처리

불충분한 에러 처리로 중요정보가 에러정보에 포함되어 발생할 수 있는 보안약점

5.1 오류 메시지를 통한 정보노출

SW가 실행환경, 사용자, 관련데이터에 대한 민감한 정보를 포함하는 오류메시지를 보여줌으로써 공격자의 악성 행위를 도와줄 수 있다.

6. 세션통제

다른 세션간 데이터 공유금지, 세션 노출금지, 재로그인시 세션ID변경, 세션종료 처리 등 세션관리로 발생할 수 있는 보안약점

6.1 불충분한 세션관리

인증시 일정한 규칙이 존재하는 세션ID가 발급되거나 세션 타임아웃을 너무 길게 설정한 경우 공격자에 의해 사용자 권한이 도용될 수 있는 취약점이다.

5. 정보시스템 구축 관리

 5.1.1 소프트웨어 개발 방법론 활용 능력 단위 정의

 5.1.2 소프트웨어 개발 방법론 선정

- 소프트웨어 개발 방법론 활용 능력 단위 정의

소프트웨어 개발 방법론 활용이란 응용소프트웨어 특성에 따라 정형화된 개발방법론을 선정하고, 프로젝트 특성에 맞도록 테일러링 하여 응용소프트웨어 개발에 활용하는 능력이다.

- 소프트웨어 개발 방법론 선정

1. 소프트웨어 개발 생명 주기 모델 

1.1 소프트웨어 개발 생명주기 정의

소프트웨어를 어떻게 개발할 것인가에 대한 추상적 표현으로 순차적 또는 병렬적 단계로 구성되며 개발 모델 또는 소프트웨어 공학 패러다임으로 정의한다.

SDLC는 타당성검토 -> 분석 -> 설계 -> 개발 -> 테스트 -> 운영 -> 유지보수 -> 폐기단계로 생명주기를 가진다.

1.2 소프트웨어 개발 생명주기 특징

개발 생명주기의 각 단계에 관련된 활동들이 정의되어 있음

단계별 활동들을 통해 다음 단계에 활용될 수 있는 산출물이 작성됨

전체 프로젝트의 비용 산정과 개발 계획을 수립할 수 있는 기본 골격제시

참여자들 간에 의사소통의 기준과 용어의 표준화를 가능하게 함

문서화가 충실한 프로젝트 관리를 가능하게 함

1.3 소프트웨어 개발 생명주기 모델의 유형

1. 폭포수 모델

정의 : 검토 승인을 거쳐 순차적 하향식으로 개발이 진행되는 생명주기 모델

장점 : 이해하기 쉬움

단점 : 요구도출 어려움

2. 프로토타입 모델

정의 : 핵심적인 기능을 먼저 만들어 평가한 후 구현하는 점진적 개발 방법

장점 : 요구사항 도출용이, 시스템 이해용이, 의사소통 향상

단점 : 사용자의 오해, 폐기되는 프로토타입 존재

3. 나선형 모델

정의 : 폭포수와 프로토타입 모델 장점에 위험분석을 추가한 모델

장점 : 점증적인 개발로 실패할 위험감소, 테스트 용이

단점 : 관리가 복잡

4. 반복 점증적 모델

정의 : 시스템을 여러번 나누어 Release 하는 방법

장점 : 위험의 조기 발견 및 최소화 전략 구현 가능

단점 : 관리 어려움

5. RAD

정의 : 짧은 개발주기 동안 소프트웨어를 개발하기 위한 순차적 프로세스 모델

장점 : 요구사항 이해와 범위의 명확한 설정 시 신속하고 완전한 기능 구현 가능

단점 : 기술적 위험 높을 경우 부적합, 적절한 모듈화 필수, 책임감 있는 구성원 필요

2. 소프트웨어 개발 방법론

소프트웨어 공학 원리를 소프트웨어 개발 생명주기에 적용한 개념으로 정보시스템 개발을 위한 작업 활동, 절차, 산출물, 기법 등을 체계적으로 정리한 것을 의미한다.

2.1 SW개발 방법론의 구성

SW개발방법론은 시스템의 종류, 프로세스, 조직, 사람, 문화에 따라 다르게 선정되어야 한다.

2.2 SW개발 방법론의 유형

1. 전통적인 개발 방식

정의 : 검토/승인을 거쳐 순차적 하향식으로 개발이 진행되는 생명주기 모델

장점 : 이해하기 쉬움, 다음단계 진행 전에 결과 검증, 관리용이

단점 : 요구도출 어려움, 설계/코딩/테스트 지연가능 , 문제발견 지연

2. Agile방법론

정의

절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응, 효율적인 개발, 주위 변화수용, 능동적으로 대응하는 개발 방법론

특징 

변화대응 : 계획준수 보다 환경 변화에 즉시 대응

동작소프트웨어 : 포괄적인 문서화, 정형적 프로세스를 지향

고객협력 : 계약협상 중심에서 탈피

개인과 상호작용 : 프로세스나 도구보다는 구성원간의 의사소통 중시

프로세스의 핵심활동

제품 Backlog를 일정 타임박스기간 동안 설계, 개발, 테스트를 수행, 구현된 소프트웨어를 고객에게 시연하며 이해하기 힘든 산출물이 아닌 경우 동작하는 소프트웨어에 의한 확인 수행을 통해 고객 요구사항을 조기에 명확히 하는 활동을 반복 수행한다.

3. 전통적인 소프트웨어 개발 방식과 Agile 개발 방식의 비교

전통적인 개발방식  : 엄격한 프로세스 기반 정형화된 역할 및 활동 강조

Agile 개발 방식 : 프로젝트 관계자간 상호 작용을 중심으로 반복적인 점검과 테스트

3. 소프트웨어와 시스템

3.1 소프트웨어

하드웨어를 동작 시켜 사용자가 작업을 편리하게 수행하도록 하는 프로그램과 자료구조를 의미하는 것으로 프로그램 개발, 운용, 유지보수 관련된 모든 문서와 정보를 포함한다.

소프트웨어 분류

기능에 의한 분류 : 시스템 소프트웨어, 응용 소프트웨어 

사용 분야에 의한 분류 : 프로그래밍, 문서, 통신, 분산처리, 멀티미디어, 개발 인공지능

개발 과정 성격에 따른 분류 : 프로토타입, 프로젝트 산출물, 패키지

정보처리 방법에 따른 분류 : 일괄처리, 온라인, 실시간

3.2 시스템

전체적으로는 통일된 하나의 개체를 형성하면서 각각의 고유기능을 수행하고 그들의 공통적 목표를 달성하기 위해 상호 작용하는 요소들의 집합이다.

시스템의 특성

구조적 측면

시스템은 입력 처리 출력의 구조를 갖는다.

시스템은 피드백 구조를 갖는다

시스템은 계층적 구조를 갖는다.

기능적 측면

시스템은 목표 지향적이다

시스템은 상승 작용적이다.

시스템은 자기 제어적이다.

4. 소프트웨어 공학

4.1 소프트웨어 위기

여러가지 원인에 의해 개발 속도가 하드웨어 개발속도를 따라가지 못해 소프트웨어에 대한 사용자들의 요구사항을 처리할 수 없는 문제가 발생함을 의미한다.

1. 소프트웨어 위기의 발생원인

소프트웨어 특징에 대한 이해 부족 : 논리적인 소프트웨어 특징을 이해하지 못함

소프트웨어 관리 부재 : 소프트웨어 관리를 소홀히 하여 효율적인 자원 통제가 이루어지지 못했음

프로그래밍에만 치중 : 소프트웨어 품질이나 유지보수는 고려하지 않고, 프로그램만 하려해서 다양하고 복잡해지는 소프트웨어의 요구사항을 처리하지 못함

2. 소프트웨어 문제점

개발 인력 부족과 그로 인한 인건비 상승

성능 및 신뢰성 부족

개발 기간 지연 및 개발 비용 증가

유지보수가 어려워져 비용 증가

소프트웨어의 생산성 저하

소프트웨어 품질 저하

4.2 소프트웨어 공학의 필요성

소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문으로 소프트웨어의 품질과 생산성 향상을 목적으로 한다.

소프트웨어 공학의 정의

IEEE 정의 : 소프트웨어의 개발 운용, 유지보수, 폐기 처분에 대한 체계적인 접근 방안

Fairly 정의 : 지정된 비용과 기간 내의 소프트웨어를 체계적으로 생산하고 유지보수 하는 데 관련된 기술적이고 관리적인 원리

Boehm 정의 : 과학적인 지식을 소프트웨어 설계와 제작에 응용하는 것이며 이를 개발 운용, 유지보수 하는데 필요한 문서 작성 과정

4.2 소프트웨어 공학의 기본 원칙

현대적인 프로그래밍 기술을 계속적으로 적용해야 한다.

개발된 소프트웨어 품질이 유지되도록 지속적으로 검증해야 한다.

소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야 한다.

4. 프로그래밍 언어 활용

 4.1 서버프로그램 구현

  4.1.4 서버 프로그램 구현

  4.1.5 배치 프로그램 구현

1. 보안 취약성 식별

1.1 정의 및 개념

취약점은 공격자가 시스템의 정보 보증을 낮추는데 사용되는 약점이다.

시스템 민감성 또는 결함, 공격자가 결함에 대한 접근 그리고 공격자가 결함에 대한 익스플로잇 가능성

취약점을 익스프로잇하기 위해서, 공격자는 반드시 시스템의 약점에 접속할 수 있는 적어도 하나의 툴이나 기법을 가져야 한다.

이 경우에, 취약점은 또한 공격 영역이라고도 불린다.

1.2 취약점 식별과 제거

컴퓨터 시스템에서 취약점들을 발견할 수 있게 도와주는 많은 소프트웨어 툴들이 존재한다.

비록 이러한 툴들이 감시관에게 현재 존재할 수 있는 취약점들에 대한 좋은 개요를 제공할 수 있지만, 인간의 판단을 대체하지는 못한다.

단지 스캐너에게만 의존하는 것은 현재 시스템에 존재하는 문제들에 대한 제한된 관점과 긍정 오류를 만들 수 있다.

취약점들은 모든 주요 운영 체제들에서 발견되고 있다.

이러한 시스템들을 사용하면서 취약점들의 확률을 줄일 수 있는 유일한 방법은 감사와 최적의 배치, 세심한 시스템 관리를 포함한 꾸준한 조심을 통해서 가능해 진다.

1.3 취약점 사례

1. 시스템의 물리적 환경 취약점

직원, 관리, 조직 내에서 관리 절차와 보완 방식, 경영 활동과 서비스 전달, 하드웨어, 소프트웨어, 통신 장비와 시설, 그리고 이들의 조합

1,4 취약점 익스플로잇의 절차

공격자는 오버플로우 취약점을 찾아서 민감한 데이터를 내보내는 악성코드를 설치한다.

공격자는 사용자가 악성코드가 들어있는 이메일 메시지를 열게 만든다.

내부인이 보호되고 암호화된 프로그램을 USB에 담아와서 집에서 크랙한다.

1층에 설치된 컴퓨터 시스템에 수해로 인한 피해가 발생한다.

1.5 취약점 결과

보안 위반의 영향은 매우 크다. IT 관리자나 높은 관리직이 취약점이 있는 IT 시스템과 애플리케이션에 대해 쉽게 알 수 있는 것과 IT 위험에 대해 어떤 조치도 취하지 않는 것은 대부분의 경우에 좋지 않은 행위이다.

프라이버시 법은 관리자들이 보안 위험에 대한 영향과 가능성을 줄이는 것을 강요한다.

모의 해킹은 조직에 의해 채택된 약점과 대응책을 확인하는 형태이다.

1.6 소프트웨어 개발 보안

소프트웨어 개발 보안의 개념은 SW 개발 과정에서 개발자의 실수, 논리적 오류 등으로 인해 SW에 내포될 수 있는 보안취약점의 원인, 즉 보안 취약점을 최소화하고, 사이버 보안 위협에 대응할 수 있는 안전한 SW를 개발하기 위한 일련의 보안 활동이다.

2. API

2.1 API 정의

API는 응용프로그램에서 사용할 수 있도록, 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게만든 인터페이스를 말한다.

주로 파일 제어, 창 제어, 화상 처리, 문자 제어 등을 위한 인터페이스를 제공한다.

2.2 절차적 언어에서의 API

대부분의 절차적 언어에서 API는 특정한 작업을 수행할 함수들의 집합을 규정하며, 특정 소프트웨어 구성 요소와 상호 작용할 수 있게 한다.

2.3 Window API

윈도우 API는 마이크로소프트 윈도 운영 체제들이 사용하는 API이다.

C/C++ 프로그램에서 직접 운영 체제와 상호 작용할 수 있도록 만들어졌으며, 그보다 더 낮은 수준의 제어는 Ntdll.dll을 사용한 낮은 수준의 DLL로 가능하다.

2.4 단일 유닉스 규격

단일 유닉스 규격은 컴퓨터의 운영체제가 유닉스란 이름을 사용하기 위해 지켜야 하는 표준 규격의 총칭이다.

SUS는 전기 전자 기술자 협회와 오픈크룹의 표준화 작업 결과물에 바탕을 두고 있으며 , 오스틴 그룹이 개발 및 유지 관리를 담당하고 있다.

단일 유닉스 규격 이전에 존재하였던 POSIX는 ISO/IEC JTC1에서의 작업은 종료되어, 오스텐 그룹이 유지 관리 작업에 관여하고 있다.

2.5 Java API

자바 API는 자바를 사용하여 쉽게 구현할 수 있도록 한 클래스 라이브러리의 집합이다.

자바라는 언어를 사용하여 사용자의 부담을 최소화하는 반면에 입출력, 화면 구성, 이미지, 네트워크와 같이 복잡하지만 필요한 클래스들을 미리 구현하여 사용자가 쉽게 구현하도록 하는 API이다.

이러한 자바 API는 하나의 커다란 클래스 계층구조로 설계되어 있다.

2.6 웹 API

웹 API는 웹 애플리케이션 개발에서 다른 서비스에 요청을 보내고 응답을 받기 위해 정의된 명세를 일컫는다.

예를 들어 블로그 API를 이용하면 블로그에 접속하지 않고도 다른 방법으로 글을 올릴 수 있다.

그 외에 우체국이 우편번호, API, 구글과 네이버의 지도, API등 유용한 API들이 많으므로 요즘은 홈페이지 구축이나 추가개편 시 따로 추가로 개발하지 않고 이런 오픈 API를 가져와 사용하는 추세다.

-배치 프로그램 구현

1. 배치 프로그램의 이해

1.1 배치 프로그램의 개념

배치 프로그램이란 사용자와의 상호 작용 없이 일련의 작업들을 작업 단위로 묶어 정기적으로 반복 수행하거나 정해진 규칙에 따라 일괄 처리하는 것이다.

1.2 배치 프로그램의 필수 요소

대용량 데이터 : 대용량의 데이터를 처리할 수 있어야 한다.

자동화 : 심각한 오류 상황 외에는 사용자의 개입 없이 동작해야 한다.

견고함 : 유효하지 않은 데이터의 경우도 처리해서 비정상적인 동작 중단이 발생하지 않아야 한다.

안정성 : 어떤 문제가 생겼는지, 언제 발생했는지 등을 추적할 수 있어야 한다.

성능 : 주어진 시간 내에 처리를 완료할 수 있어야 하고, 동시에 동작하고 있는 다른 애플리케이션을 방해하지 말아야 한다.

2. 배치 스케줄러

2.1 배치 스케줄러의 개념

배치 스케줄러는 일괄 처리를 위해 주기적으로 발생하거나 반복적으로 발생하는 작업을 지원하는 도구이다.

2.2 배치 스케줄러의 종류

1. 스프링 배치

스프링 배치는 Spring Source사와 Accenture사의 공동 작업으로 2007년에 탄생한 배치기반 오픈소스 프레임워크이다.

2. Quartz 스케줄러

Quartz 스케줄러란 Spring Framework에 플러그인되어 수행하는 job과 실행 스케줄을 정의하는 Trigger를 분리하여 유연성을 제공하는 오픈소스 스케줄러이다.

3. 배치프로그램 구현

3.1 애플리케이션 설계를 기반으로 배치 프로그램을 확인한다.

프로그램 관리 대상을 확인한다.

배치 설계서를 확인한다.

3.2 프로그램 관리 대장의 ID와 일치하는 배치 설계를 확인한다.

3.3 애플리케이션 설계를 기반으로 배치 프로그램을 구현한다.

배치프로그램을 구현하기 위한 SQL을 작성한다.

배치프로그램을 구현하기 위한 I/O 오브젝트를 정의한다.

배치 프로그램을 구현하기 위한 데이터 접근 오브젝트를 작성한다.

배치 프로그램을 구현하기 위한 스케줄러 클래스를 작성한다.

4. 프로그래밍 언어 활용

 4.1 서버프로그램 구현

  4.1.1 서버프로그램 구현 능력단위 정의

  4.1.2 개발환경구축

  4.1.3 공통모듈구축

- 서버프로그램 구현 능력단위 정의

서버프로그램 구현이란 애플리케이션 설계를 기반으로 개발에 필요한 환경을 구성하고, 프로그래밍 언어와 도구를 활용하여 공통모듈, 업무프로그램 배치 프로그램을 구현하는 능력이다.

1.개발환경 구축

1.1 개발환경 구축의 이해

서버프로그램 구현을 위한 첫번째 시작은 개발에 필요한 환경을 구성하는 일이다. 개발환경 구성 시 구현될 요구사항의 명확한 이해가 필요하며, 이에 맞는 개발도구 및 서버의 선정이 이루어져야 한다. 또 개발에 사용되는 도구들의 사용 편의성과 성능, 라이선스 등에 대한 내용도 파악해야 한다.

1.2 개발을 위해 사용되는 도구의 분류와 특성

개발 환경 구성을 위한 도구들의 분류는 아래와 같이 크게 4가지로 가능하며 각각의 내용과 사용되는 도구들을 이해해야 한다. 

구현도구 Eclips ,visual studio cade

테스트도구 xUnit, Spring teset

형상관리도구 CVS, Subversion, Git

빌드도구 Ant, Maven, Gradle

1. 구현 도구

코드의 작성과 디버깅, 수정 등과 같은 여러가지 작업이 가능하며 구현해야 할 소프트웨어가 어떤 프로그래밍 언어로 개발되는지에 따라 선택하여 사용하며 프로그램을 개발할 때 가장 많이 사용되는 도구이다.

2. 빌드 도구

작성한 코드에 대한 빌드 및 배포를 수행하며, 각각의 구성 요소들과 모듈들에 대한 의존성 관리를 지원하는 도구이다.

3. 테스트 도구

코드의 기능 검증과 전체의 품질을 높이기 위해 사용되는 도구들로 코드의 테스트, 테스트에 대한 계획, 수행 및 분석 등의 작업이 가능하다.

4. 형상관리 도구

개발자들이 작성한 코드와 리소스 등 산출물에 대한 버전 관리를 위해 형상관리 도구가 사용된다. 프로젝트 진행시 필수로 포함되는 도구들이다.

1.3 개발환경 구축 시 구성 요소

개발환경 구성은 크게 하드웨어와 소프트웨어 환경으로 구성되며 형상관리 등 다양한 요소로 되어있다. 하드웨어와 소프트웨어 구성 시 유의점은 추후 운영할 환경도 고려하여 구성해야 한다는 것이다.

1. 하드웨어 환경

서버 환경 : 프로젝트 및 개발 구성에 따라 애플리케이션 서버, 데이터베이스 서버, 파일 서버 등으로 구분한다.

웬 서버 

HTTP를 이용한 요청/응답을 처리 하기 위한 미들웨어를 설치하는 서버이다. 주로 웹 브라우저 화면에서 요청하는 서비스를 처리하기 위해 ,HTML,CSS 이미지 등을 제공하는 웹 서버 애플리케이션의 처리를 담당한다.

웹애플리케이션 서버

웹 서비스를 동적으로 제공하기 위해 WAS의 형태인 Resin, Tomcat등 과 서비스에 관련된 애플레케이션이 설치되는 서버이다.

데이터베이스 서버

데이터의 수집, 저장을 위한 용도로 MySQL., Oracle, Ms-SQL 등 데이터베이스의 SW에 설치되어 있다.

파일 서버

파일 저장 하드웨어로 물리적 저장장치를 활용한 서버이다. 대용량 HDD,SDD 등 장치가 주요 요소이다.

클라이언트 환경 : 위의 서버환경에서 제공되는 서비스를 사용하기 위해 유저의 인터페이스를 제공하는 하드웨어 이다.

Client Server 화면

주로 설치를 통해 사용자와 커뮤니케이션 하는 화면들이다. Visual Basic, C#,Delphi 등으로 개발되어 사용자에게 배포된다.

웹브라우저 화면

웹서비스의 형태로 서버에서 웹 어플리케이션을 응답시 브라우저를 통해 사용자와 커뮤니케이션을 한다.

스마트폰

CS화면과 유사하지만 모바일 디바이스에 설치되어 사용자가 활용한다. 웹앱의 경우 웹브라우저와 동일한 형태로 모바일 상 웹브라우저를 통해 서비스를 받는다.

2. 소프트웨어 환경

개발을 위한 기본적인 소프트웨어 환경을 선택 및 구성한다. 프로젝트의 성격과 요구사항에 부합한 운영체제, 언어의 선택에 적절한 미들웨어, 그리고 데이터베이스시스템을 설치한다.

운영체제 

운영체제는 서버의 하드웨어를 사용자 측면에서 편리하고 유용하게 사용하기 위한 SW이다.

미들웨어

개발을 위한 보조 SW로서 웹서버나 JVM 같은 개발환경의 구성요소로 활용한다. 웹서비스 경우 웹서버를 설치하여 사용자 요구사항에 적합한 웹서비스를 제공한다. JAVA를 활용한 개발의 경우 JVM을 설치하여 컨테이너로의 기능을 이용한다.

DBMS

데이터의 저장과 활용을 위해 데이터베이스 시스템을 설치하고 고객사의 요청과 요구사항에 따라 제품을 선택한다.

3. 형상관리

형상관리란 소프트웨어의 개발을 위한 전체과정에서 발생하는 모든 항목의 변경 사항을 관리하기 위한 활동이다.

형상 식별

형상관리 대상을 정의, 식별하고 해당 항목에 추적성을 부여하기 위해 ID와 관리번호를 부여한다. 추후 변경에 관련된 이슈 발생 시 ID와 관리번호를 이용하여 추적한다. 이러한 활동은 베이스라인의 기준이 된다.

변경 제어

형상항목으 버전관리를 위해 형상통제위원회를 두어 변경요구, 영향도분석, 검토, 승인 등 변경절차를 통한 통제를 수행하여 베이스라인에 대한 관리와 형상에 대한 통제를 수행할 수 있도록 한다.

형상 상태 보고

형상의 통제와 관련된 결과를 관리하고 보고서로 작성하는 활동이다. 베이스라인의 상태에 대한 판단의 기준이 된다.

형상 감사

감사활동을 통해 형상 통제의 확인, 검증과 베이스라인의 무결성을 평가하는 활동을 말한다.

1.4 개발환경 구축 순서

프로젝트 요구사항 분석

개발환경 구성을 위한 필요 도구 설계

개발 대상에 따른 적정한 개발 언어 선정

개발 언어와 하드웨어를 고려한 구현도구 구축

빌드와 테스트 도구 구축

1. 개발환경 준비를 위해 프로젝트의 요구사항을 분석한다.

대상이 되는 시스템의 요구사항을 분석하여 어떠한 도구들이 필요한지 준비하는 과정이다.

시스템의 환경을 분석하여 개발환경 구축에 필요한 도구에 대해 파악한다.

2. 개발 환경 구성을 위한 필요도구를 설계한다.

개발을 해야할 구현도구, 빌드도구, 테스트도구, 형상관리도구 등 요구사항에 맞는 시스템을 구축하기 위한 환경을 설계한다.

3. 개발 대상에 따른 적절한 개발 언어를 선정한다.

적정성 : 개발하고자 하는 시스템이나 응용 프로그램의 목적에 적합한가

효율성 : 개발 대상을 효율적으로 구현이 가능한가

이식성 : 여러가지 디바이스와 운영체제에 적용 가능한가

친밀성 : 대중의 프로그래멍가 사용 가능한 언어인가.

범용성 : 다수의 시스템에서 사용중이며 많은 과거의 사례가 존재하는가

사용자의 요구사항과 개발 대상의 업무의 성격에 적합한 특성을 확인하고 컴파일러의 사용성을 고려하여 적합한 언어를 선정한다.

개발 대상의 업무의 성격에 적합한 특성을 확인하고 적합한 언어를 선정한다. 예로 대상업무가 웹을 이용한 고객 서비스의 경우 적합한 JAVA,JSP 및 JavaScript/HTML을 server와 client 개발언어로 선정한다.

4. 프로젝트의 성격과 개발자 편의성을 위한 구현도구를 선정한다

위의 선정된 개발언어에 따라서 적합한 구현도구를 선정한다. 예로 Java로 개발언어가 선정되었다면 이클립스를 주로 이용하여 구현하며 C# VB등의 경우 비쥬얼 스튜디오를 활용할 수 있다.

5. 프로그램의 배포 및 라이브러리 관리, 테스트를위한 빌드 테스트 도구를 선정한다.

프로젝트 팀원의 빌드 도구의 친밀도와 숙련도를 고려하여 빌드 도구와 형상관리 도구를 고려하고 통합 개발 도구와 호환이 가능한 도구를 선정한다.

테스트도구의 경우 MTP에 적합하게 계획에 따라 필요한 도구를 선정한다. 온라인 트랜잭션이 빈번한 개발 대상인 경우 테스트자동화 도구를 고려하여 품질 향상에 기여한다.

2. 서버 개발 프레임워크

2.1 프레임워크에 대한 이해

소프트웨어 프레임워크는 효율적인 정보 시스템 개발을 위한 코드 라이브러리, 애플리케이션 인터페이스, 설정 정보 등의 집합으로서 재사용이 가능하도록 소프트웨어 구성에 필요한 기본을 제공하며 정보시스템의 개발 및 운영을 지원하는 도구 및 가이드 등을 포함한다.

2.2 프레임워크의 특징

프레임워크는 모듈화, 재사용성, 확장성 ,제어의 역흐름이라는 대표 4가지 특징을 보유한다.

모듈화 : 인터페이스에 의한 캡슐화를 통해 모듈화를 강화하고 설계와 구현의 변경에 따르는 영향을 극소화하여 소프트웨어의 품질을 향상시킨다.

재사용성 : 프레임워크가 제공하는 인터페이스는 반복적으로 사요할 수 있는 컴포넌트를 정의할 수 있게하여 재사용성을 높여준다.

확장성 : 프레임워크는 다형성을 통해 애플리케이션이 프레임워크의 인터페이스를 확장할 수 있게 한다.

제어의 역흐름 : 프레임워크 코드가 전체 애플리케이션의 처리 흐름을 제어하여 특정한 이벤트가 발생할 때 다형성을 통해 애플리케이션이 확장한 메소드를 호출함으로써 제어가 프레임워크로부터 애플리케이션으로 거꾸로 흐르게 한다.

2.3 서버 프로그램을 구현하기 위한 서버개발 프레임워크

서버 개발 프레임워크는 대표적인 예로 Java를 이용하는 Spring 프레임워크가 있으며 Python의 diango, Javascript의 Node.js 등이 있다.

목표 대상 시스템의 하드웨어와 요구사항을 분석하여 개발 언어와 구현도구를 선정함과 유사하게 서버 개발 프레임워크를 선정한다.

-공통 모듈 구현

1. 재사용

기존의 소프트웨어 또는 소프트웨어 지식을 활용해, 새로운 소프트웨어를 구축하는 일이다.

1.1 재사용의 이해

1. 재사용의 개념

재사용가능한 소프트웨어나 소프트웨어 지식은 재사용 가능한 자산이다. 자산에는 설계, 요구명세, 검사, 아키텍처 등도 포함된다.

2. 코드 재사용

가장 잘 알려져 있는 재사용 가능 자산은 코드이다. 코드 재사용은 어떤 시점에 쓰여진 프로그램의 일부 또는 전부를 이후의 다른 프로그램을 만들때 사용하는 것이다. 코드의 재사용은 장황한 작업에 소비하는 시간과 에너지를 절약하는 전형적 기법이다.

3. 재사용 프로그래밍 기법

재사용을 빠르고 용이하게 하기 위해 프로그래밍 정식 절차의 일부로서 보다 체계적으로 실시할 수 있도록하는 연구가 많이 이루어져 왔다.

객체지향 프로그래밍 기법

객체 단위로 재사용이 이루어지도록 설계하여 구조화된 구현이 가능하다.

제네릭 프로그래밍 

데이터 형식에 의존하지 않고, 하나의 값이 여러 다른 데이터 타입들을 가질 수 있는 기술에 중점을 두어 재사용성을 높일 수 있는 프로그래밍 방식이다.

자동프로그래밍

프로그램이 사용자가 설정한 일련의 변수에 근거하여 어떤 종류의 프로그램을 생성하는 것이다.

메타프로그래밍

자기 자신 혹은 다른 컴퓨터 프로그램을 데이터로 처리함으로써 프로그램을 자성, 수정하는 프로그램을 작성하는 것을 말한다.

1.2 재사용의 유형

1. 편의점 재사용

프로젝트를 시작할 때 재사용가능한 컴포넌트가 있는지를 찾아보고 재사용한다.

편의적 재사용은 다음으로 더 세분화할 수 있다.

내부 재사용

팀내에서 만든 콤포넌트를 재사용한다. 어디까지나 편의상이며 계획적인 것이 아니기 때문에, 인터페이스의 조정 등에 추가적인 비용이 발생할 수 있다.

외부 재사용

서드파티에서 만든 콤포넌트를 구하여 사용한다. 유상인 경우, 조달비용을 자신이 직접 개발할 때 드는 비용이 20%이하로 잡는 것이 일반적이다. 또, 조달한 콤포넌트를 학습하여 활용하는데 걸리는 시간도 고려해야한다.

2. 계획적 재사용

컴포넌트를 차후에 재사용가능하도록 전략적으로 설계해 나간다.

1.3 재사용의 사례 

1. 소프트웨어 라이브러리

코드 재사용의 매우 일반적인 예로서 라이브러리를 사용하는 것이다.

2. 디자인 패턴

디자인 패턴은 비슷한 문제를 풀기 위한 범용적인 해법이다.

3. 프레임 워크

개발자는 일반적으로 타사 응용 프로그램 및 프레임 워크를 통해 많은 소프트웨어를 재사용한다.

프레임워크는 대개 도메인 마다 다르고 응용 프로그램 그룹에 적용 할 수 있다.

2. 모듈화

2.1 모듈의 개요

프로그램을 구성하는 구성 요소의 일부로 관련도니 데이터와 함수들이 묶여서 모듈을 형성한다. 주로 파일 단위로 구성된다.

2.2 모듈화의 원리

1. 분할과 지배

복잡한 문제를 분해, 모듈 단위로 문제 해결한다.

2. 정보 은폐

어렵거나 변경 가능성이 있는 모듈을 타모듈로부터 은폐한다.

3. 자료추상화

각 모듈 자료구조를 액세스하고 수정하는 함수내에 자료 구조의 표현 내역을 은폐한다.

4. 모듈의 독립성

낮은 결합도와 높은 응집도를 가진다.

2.3 모듈화 측정 척도

모듈화는 공통모듈의 구현을 위해 재사용성 강화를 위한 중요한 개념이다. 모듈은 내부처리요소간의 독립성을 나타내며 응집도가 높을수록 좋고 모듈간의 연관성은 루즐리커플로 구현할 수 있는 결합도가 낮을수록 좋다.

2.4 모듈화의 종류

1. 설계측면

모듈 

설계 시 관련이 있는 기능을 모아 한 부분에 모아놓고 라이브러리 형태로 사용된다.

컴포넌트

바이너리형태의 재사용 가능한 형태로 인터페이스에 의해 로직을 수행 할 수있는 모듈단위를 말한다.

소프트웨어 재사용과 관련하여 객체들의 모임, 대규모 재사용 단위이다.

서비스

기존 컴포넌트 보다는 루즐리 커플드 한 형태의 기능을 제공하는 모듈단위 이다.

2. 구현 측면

매크로 

프로그램 구현 시 반복되는 부분을 특정 이름을 부여하고 이름을 호출하여 실행할 수 있도록 하는 프로그래미이 기법, 단 전처리기는 매크로가 사용된 모든 곳에 코드를 대체해 놓는다.

함수

프로그램 구현시 커더란 프로그램의 일부코드로 특정한 작업을 수행하고 상대적으로 다른 코드에 비해 독립적인 모듈이다.

인라인

프로그램 구현 시 반복되는 부분을 특정 이름을 부여해 놓고 이름을 호출하여 실핼 할 수있도록 하는 프로그램 기법. 단 컴파일러는 이 inline이 사용된 모든 곳에 코드를 복사한다.

3. 결합도

3.1 결합도의 개요

모듈내부가 아닌 외부의 모듈과의 연관도이다.

소프트웨어 구조에서 모듈간의 관련성을 측정하는 척도이다.

3.2 결합도의 특징

서로 다른 상위 모듈에 의해 호출되어 처리 상 연관성이 없는 서로 다른 기능을 수행한다.

3.3 결합도 단계

자료 : 모듈들이 간단히 변수를 파라미터로 교환한다.

스탬프 : 모듈 사이에 자료구조 교환한다.

제어 : 제어용 신호를 주고 받는다.

외부 : 모듈들이 소프트웨어의 외부환경과 연관되는 사용된다.

공통 : 많은 모듈들이 전역변수를 참조할 때 발생한다.

내용 : 한 모듈이 다른 모듈의 내부자료나 제어정보를 사용한다. 

결합도는 낮을수록 좋다.

4. 응집도

4.1 응집도의 개요

정보은닉 개념의 확장개념으로, 하나의 모듈은 하나의 기능을 수행하는 집적성을 지칭한다.

모듈의 독립성을 나타내는 개념으로 모듈내부 구성원간의 연관도이다.

4.2 응집도의 특징

클래스 목적에 부합하는 같은 기능영역의 함수들로 구성되어 있다.

함수의 개수가 상대적으로 적으며 오로지 자신만이 할 수 있는 책임을 부여 받는다.

하나의 함수에 많은 기능을 부여 하지 않고 다른 함수와 협력한다.

4.3 응집도의 단계

우연적 : 아무 관련성 없는 작업을 한 모듈에서 모음

논리적 : 유사한 성격의 작업들을 모음

시간적 : 같은 시간대에 처리되어야 하는 것들을 모음

절차적 : 모듈진행 요소들이 서로 관계되어지고 순서대로 진행

교환적 : 동일한 입출력 자료를 이용하여 서로 다른 기능을 수행하는 기능

순차적 작업의 결과가 다른 모듈이 입력자료로 사용

기능적 : 하나의 기능만 수행하는 모듈

응집도는 높을수록 좋다.

모듈내부의 독립성을 보장하기 위해 단 하나의 기능만을 구현하는 것을 말한다.

 3.5 데이터 전환

  3.5.3 데이터 전환 수행

  3.5.4 데이터 정제

1. 데이터 전환 수행 계획

1.1 데이터 전환 절차

데이터 전환 수행 계획서를 만들기 위해서는 전체적인 데이터 전환 방법론을 이해해야 한다.

데이터 전환 절차는 요구사항 분석단계, 설계 단계, 구현단계, 테스트 단계, 데이터 전환으로 구분한다.

1.2 데이터 전환 수행 계획

데이터 전환 수행 계획 작성을 위해서는 데이터 전환 범위, 일정, 전환절차를 명확히 해야한다.

1. 데이터 전환 범위 선정

전환 대상의 상세 내용, 데이터 형식, 대상 건수를 파악한다.

전환 제외 대상을 기록한다.

2. 데이터 전환 일정 선정

팀별 업무를 분장하여 팀별 역할과 납기를 기록한다. 전환 차수의 결정은 통합 전환 계획 및 테스트 계획에 의해 결정된다.

3. 데이터 전환 절차

현행 시스템에서 목표 시스템으로 데이터 전환을 위한 단계를 구분하고 각 단계별 작업 내용과 사용되는 도구를 별도로 기록한다.

원천 데이터베이스의 데이터는 백업하여 스테이징 데이터베이스로 복구한 후 정비 및 변환 작업을 수행한다. 이는 원천 데이터베이스의 손상과 변형을 막기 위한 방법이다.

데이터 전환이 완료된 후 검증단계에서는 스테이징 데이터베이스가 아닌 원천 데이터베이스와 비교하여 데이터 오류를 확인해야 한다.

4. 데이터 전환 계획서 작성

데이터 전환을 위해 여러 단계를 거치는 전환 계획서를 작성하여 데이터 전환 시 발생할 수 있는 리스크를 사전에 예방한다.

2. 체크리스트

전환 프로그램의 에러, 시간의 제약, 업무 프로세스의 변경, 빈번한 데이터 요건 변경, 하드웨어 장애 등의 위험 요소에 최대한 대응하기 위해 체크리스트를 작성한다.

체크리스트에는 데이터 전환 수행자가 수행할 작업의 상세항목, 작업 내용, 예정 시작, 종료 시각, 작업 담당자를 기재한다.

3. 데이터 검증

데이터 검증 방법으로 추출 검증, 전송 검증, 전환 검증, 적재 검증, 통합 검증 방법이 있다.

3.1 추출 후 검증

현행 시스템에서 최초 원시 데이터에 대한 검증을 수행한다.

3.2 전송 검증

전송된 추출 파일의 코드 전환 후 검증한다.

3.3 전환 검증

Tool을 이용해서 데이터를 추출하여 Staging DB를 구성한 후 검증한다.

3.4 적재 검증

목적 테이블에 대해 데이터를 검증한다.

데이터 전환이 완료되었다 하더라도 데이터 전환 과정에서 수행한 검증 작업은 단순 매핑 결과에 대한 검증 역할 밖에 할 수 없는 한계가 있다.

목적 테이블에 대한 데이터를 검증함으로 오류 및 데이터 누락 손실 등을 찾을 수 있다.

3.5 통합 검증

매핑 후 검증을 의미한다.

오류 데이터를 분석하여 사전 정비 또는 전환 규칙 오류를 수정 반영한다.

- 데이터 정제

1. 데이터 정제

1.1 단계별 데이터 정제 방안

데이터 정제 항목을 정제 시점에 따라 전환 테스트 전, 전환 테스트 중, 최종 전환 중 3단계로 구분하여 데이터 정제작업을 수행한다.

2. 데이터 품질 분석

2.1 데이터 품질 관리의 정의

기관이나 조직 내외부의 정보시스템 및 DB 사용자의 기대를 만족시키기 위해 지속적으로 수행하는 데이터 관리 및 개선활동

2.2 원천 데이터 품질 분석

원천 데이터의 품질이 보장되지 않으면 전환 후의 데이터도 정확하지 않으며, 전환 후의 데이터 정합성 검증시 오류가 발생할 때 그 원인을 찾기도 어렵다.

따라서 전환 전에 원천 데이터의 품질을 검증함으로써 전환의 정확성을 보장할 수 있으며

이전에 미처 발견하지 못한 데이터의 오류도 찾아낼 수 있다.

2.3 목적 데이터 품질 분석

원천 데이터와 목적 데이터베이스의 속성 간 대응 관계를 1대1 대응 보다 n대m 대응 관계까 더 많기 때문에 양자 간의 대응 관계를 정확히 표현하기 위해서는 데이터 레이아웃을 정확하게 파악하고 품질 검증을 진행해야 한다.

1. 목적 데이터베이스의 전환 데이터 검증을 위한 고려 사항

현재 업무에서 사용하는 보고서나 통계용 정보를 사전에 조사하여 검증에 필요한 내용을 선정하고 현재의 원장을 바탕으로 검증용 정보를 도출한다.

전환 데이터의 검증은 데이터전환 팀 인원뿐만 아니라, 현업 인원도 함께 검증을 수행함으로써 검증의 정확성을 높이고 시간을 단축시키는 것이 중요하다.

2. 전환 데이터의 대표적인 정합성 검증 항목

과목별 좌수 및 잔액

특정 기준으로 분류된 좌수 및 잔액

보고서 항목 또는 통계 수치

계좌 및 고객을 Sampling 하여 해당 사항을 모두 검증

특수항 관계가 있는 고객을 추출하여 관련된 데이터가 정확한지 검증

3. 오류 데이터 측정

3.1 정량적 측정

데이터 품질 기준에 따라 정상 데이터와 오류 데이터를 분리하고, 그 수향을 정확히 측정하여 오류 관리 목록에 기재한다.

1. 정상 데이터의 건수를 정량적으로 측정한다.

전환 대상 범위의 데이터를 업무 영역별, 테이블 별로 세분화하여 정상 데이터의 수량을 정확히 측정하고 기록한다.

2.오류 데이터의 유형과 건수를 정량적으로 측정한다.

원천 데이터의 정합성 기준을 근거로 업무별로 오류 위치와 유행을 파악하고 그 수량을 정확히 측정하여 기록한다.

3.2 오류 원인 파악 및 정제여부 결정

오류 목록의 내용을 확인하고 오류 해결 방안을 참조하여 원천 데이터의 정제를 요청할 것인지 아니면 전환 프로그램을 수정할 것인지 데이터 정제 여부를 결정한다.

1. 발견된 데이터 오류를 분석하고 원인을 파악한다.

오류 관리 목록에 기록된 오류 내용을 확인하고 오류의 상태와 심각도를 결정한 후 오류원인을 파악한다.

2. 파악된 원인을 기반으로 원천데이터와 전환 프로그램의 정제 필요 여부를 결정한다.

3. 데이터베이스

 3.4 물리 데이터베이스 설계

  3.4.6 물리데이터 모델 품질검토

 3.5 데이터 전환

  3.5.1 데이터 전환 능력 단위 정의

  3.5.2 데이터 전환 기술

1. 물리데이터 모델 품질 기준

1.1 물리데이터 모델 품질 검토의 필요성

물리데이터모델은 시스템 성능에 대해 직접적인 영향을 미치기 때문에 향후에 발생할 수 있는 성능 문제를 최소하하는 노력이 필요하다.

1.2 물리 데이터 모델 품질 기준

정확성 : 데이터 모델이 표기범에 따라 정확하게 표현되었고, 업무 영역 또는 요구사항이 정확하게 반영되었음을 의미함

완전성 : 데이터 모델의 구성 요소를 정의하는데 있어서 누락을 최소화하고, 요구사항 및 업무 영역 반영에 있어서 누락이 없음을 의미함.

준거성 : 제반 준수 요건들이 누락 없이 정확하게 준수되었음을 의미함

최신성 : 데이터 모델이 현행 시스템의 최신 상태를 반영하고 있고, 이슈사항들이 지체없이 반영되고 있음을 의미

일관성 : 여러 영역에서 공통 사용되는 데이터 요소가 전사 수준에서 한 번만 정의되고, 이를 여러 다른 영역에서 참조 활용되면서 모델 표현상의 일관성을 유지하고 있음을 의미함

활용성 : 작성된 모델과 그 설명내용이 이해관계자에게 의미를 충분하게 전달할 수 있으면서, 업무 변화시에 설계 변경이 최소화되도록 유연하게 설계되어 있음을 의미

2. CRUD 분석

2.1 CRUD 정의

기본적인 데이터 처리기능 4가지 Create, Read, Update, Delete

2.2 CRUD 분석의 정의

프로세스와 엔티티의 상관관계를 이용하여 구축된 데이터베이스 시스템을 검증하는 방법이다.

2.3 CRUD 분석 절차

1. 모든 엔티티 목록을 나열하고 각각의 프로세스가 해당 엔티티에 대하여 생성 조회 변경 삭제 하는가에 대한 여부를 표기한다.

2. CRUD 매트릭스작성 후 아래 항목들을 점검한다.

모든 엔티티 타입에 CRUD가 한번 이상 표기되었는가?

모든 엔티티 타입에 C가 한번 이상 존재하는가?

모든 엔티티 타입에 R이 한번 이상 존재하는가?

모든 단위 프로세스가 하나 이상의 엔티티 타입에 표기가 되었는가?

두 개 이상의 단위 프로세스가 하나의 엔티티 타입을 생성하는가? 이 경우 반드시 잘못되었다기 보다 로직의 검토 대상이 된다.

2.4 CRUD MATRIX 상관 모델링 

1. 모든 엔티티 타입은 CRUD가 한 번 이상 표기되었는가?

쓸모없는 엔티티타입이 도출되는 경우, 적절한 단위 프로세스가 도출되지 않는 경우, 단위 프로세스의 CRUD가 아직 충분히 정의되지 않는 경우인지를 판단하여 적절한 조치를 취한다.

2. 모든 엔티티타입에 C가 한번 이상 존재하는가?

CRUD MATRIX에는 C가 한번 이상 있어야 한다. 

3. 모든 엔티티타입에 R이 한번 이상 존재하는가?

4. 모든 단위 프로세스는 하나 이상의 엔티티타입에 표기가 되었는가

단위프로세스와 관련된 엔티티타입이 누락된 경우 추가한다.

5. 두개 이상의 단위 프로세스가 하나의 엔티티타입을 생성하는가?

관련된 프로세스를 검토하여 수정한다.

2.5 CRUD MATRIX를 이용함으로써 프로젝트에서 얻을 수 있는 장점

분석 단계의 데이터 모델과 프로세스 모델에 대한 작업을 검증할 수 있으며, 시스템 구축 단계에서 애플리케이션을 개발하는데 필요한 중요 산출물로 사용된다.

테스트 단계에서 개발한 애플리케이션을 테스트할 때도 사용할 수 있다

전체 업무간 인터페이스를 파악할 수 있다.

3. SQL 성능 튜닝

3.1 SQL 성능 튜닝의 정의

튜닝 대상이 되는 SQL을 이해하고, SQL이 가진 정보를 분석하여 성능을 개선하는 활동이다.

최소한의 CPU, I/O, 메모리를 사요하여 최대한 빠른 시간내에 원하는 작업을 수행하도록 SQL문을 수정한다.

3.2 SQL 성능 튜닝 방법

튜닝 대상 SQL 수집

1. 문제가 있는 SQL

SQL 실행에 필요이상의 자원을 사용하는 경우

서버의 자원을 독점하여 다른 SQL의 성능에 영향을 끼치는 경우

2. 향후 문제가 될 가능성이 있는 SQL

데이터 증가 및 사용자가 증가 할 경우, 서버의 자원을 대량으로 점유할 가능성이 있는 SQL

SQL 문제점 분석 및 개선사항 도축

1. 데이터가 운영 환경과 유사한 경우

수집된 SQL 수행정보가 분석을 위한 정보로 가치가 있기 때문에 이력정보를 이용함

TRACE 파일 분석이나 DBMS_XPLAN 패키지를 활용한 분석 방법 등 사용

2. 데이터가 운영환경에 비해 적거나 다른 경우

해당 SQL의 실행계획을 중심으로 튜닝대상 SQL을 판단하고 분석함

개선사항 적용 및 개선 효과 확인

1. 성능 튜닝을 수행하는 담당자들은 개발자들에 비해 제한된 정보만으로 SQL을 검토할 가능성이 높기 때문에, 개발자 차원에서의 검토가 충분히 이루어져야함

2. 개발자와 튜너 사이의 상호검증을 통해 SQL의 성능 최적화 필요

3. 개선 사항 적용 후에는 튜닝을 통해 목표하는 결과에 도달했는지 확인하고, 그렇지 못한 경우 추가적인 분석 및 튜닝 필요

3.3 SQL 튜닝 기초 지식

1. Where 안에서 연산자의 처리 성능을 숙지한다.

2. 조건절 컬럼에 함수는 사용하지 않는다

3. 조건절에 NOT 사용은 자제한다.

4. 조건절에서 범위를 다룰때는 가급적으로 BETWEEN문을 사용한다.

5. IN이나 EXISTS의 다음에 오는 SELECT 문의 결과내용이 많을수록 JOIN형태인 EXISTS문이 적당하다.

6. FROM절에 나열되는 테이블들의 순서는 기준이 되는 테이블일수록 뒤쪽에 위치시키는것이 속도에 좋다.

7. JOIN만 한 것이 OUTER JOIN을 한 것보다 속도가 더 빠르다. OUTER JOIN은 되도록 피하고 대신 UNION을 사용하는 것을 고려한다.

8. 인라인뷰를 사용하기 전에 JOIN을 사용하여 처리가능한지 확인한다. 인라인뷰를 사용하게 될 경우 SELECT문의 결과가 최소가 되도록 한다. JOIN하는 테이블이 많을 경우에 인라인뷰를 고려한다.

- 데이터 전환 능력 단위 정의

데이터 전환일나 원천의 데이터베이스, 파일, 문서로부터 목적 데이터베이스 구축에 필요한 데이터를 추출하고 목적 시스템의 데이터 모델에 적합하게 변환, 정제하여 목적 데이터베이스에 적재한 후 그 결과를 검증하여 운영 가능한 데이터베이스를 구축하는 능력이다.

- 데이터 전환 기술

1. 데이터 전환 개요

1.1 데이터 전환 개념

데이터 전환은 데이터 이행으로도 불리기도 한다. 데이터 전환은 새로운 정보 시스템을 개발하거나 기존의 시스템을 재구축한 경우 기존의 시스템에서 사용하던 데이터를 새로운 시스템으로 이행하기 위해 이전 시스템에서 데이터를 추출, 변환, 하여 새로운 시스템으로 적재하는 일련의 작업을 말한다.

1.2 데이터 전환 절차

데이터 전환 절차는 일반적으로 원천 데이터의 추출과 정체, 변환, 목표 시스템으로의 적재 및 검증 단계로 구성된다.

1.3 초기 데이터 구축

 초기 데이터 구축은 단시일에 대량의 데이터를 전환함에 있어 발생할 수 있는 위험을 최소화하고 신속하고 안정적인 이행 작업을 수행하기 위해 원천시스템에서 특정 데이터들을 사전에 추출 및 변환해서 적재할 수 있도록 데이터베이스 혹은 데이터 파일로 구축해 두는 것을 말한다.

1.4 초기 데이터 구축을 통한 기대효과

데이터 이관 시 업무 중단을 최소화하고 안정성을 확보할 수 있는 방안 마련

데이터 이관 정합성 검증 방안과 오류 데이터에 대한 정비 방안 마련

데이터 이관 완료 후 데이터의 품질 검증 방안 마련

암호화된 개인정보에 대한 처리 방안 마련

2. ETL

2.1 ETL의 정의

조직 내외부의 복수의 데이터 소스들로부터 분석을 위한 저장소로 데이터를 이동시키는 프로세스이다.

다양한 소스시스템으로부터 필요한 데이터를 추출하여 변환작업을 거쳐 타겟 시스템으로 전송 및 로딩하는 모든 과정을 말한다.

2.2 ETL프로세스

ETL의 변환 작업은 특수한 엔진에서 진행되며, 종종 변환 중인 데이터가 준비 테이블에서 임시로 보유되었다가 대상에 로드된다.

일반적으로 발생하는 데이터 변환에는 필터링, 정렬, 집계, 데이터 조인, 데이터 정리, 중복 제거 및 데이터 유효성 검사 등의 작업이 포함된다.

3. 파일 처리 기술

자료구조이론에서 파일 처리 기술은 많은 양의 자료를 각종 매체에 저장하는 기법을 말한다.

즉 파일을 하드 디스크에 저장할 때 기억공간을 효율적으로 사용하고, 필요한 자료의 탐색을 쉽게하기 위해 파일을 효율적으로 처리하는 기술이다.

3.1 순차파일

순차파일은 입력되는 데이터들을 논리적인 순서에 따라 물리적 연속 공간에 순차적으로 기록하는 방식이다.

3.2 색인 순차 파일

색인 순차 파일은 순차 처리와 랜덤처리가 모두 가능하도록 레코드들을 키 값 순으로 정렬시켜 기록하고, 레코드의 키 항목만을 모은 색인을 구성하여 편성하는 방식이다.

3.3 VSAM 파일

VSAM파일은 동적 인덱스 방법을 이용한 색인 순차 파일이다.

동적 인덱스는 인덱스 파일 또는 데이터 파일을 블록으로 구성하고 블록은 추가적인 삽입 레코드를 감안하여 빈 공간을 준비해 둔 인덱스 방법이다.

정적 인덱스는 데이터파일 또는 레코드가 삽입되어도 인덱스의 구조가 변하지 않는 인덱스 방법이다.

4. 직접파일

직접 파일은 파일을 구성하는 레코드를 특정 순서 없이 임의의 물리적 저장공간에 기록하는 것으로 랜덤파일, DAM파일이라고도 한다.

3. 데이터베이스

 3.4 물리 데이터베이스 설계

  3.4.3 데이터베이스 물리속성 설계

  3.4.4 데이터베이스 모델링

  3.4.5 데이터베이스 반정규화

1. 파티셔닝

1.1 파티셔닝의 정의

큰 table  이나 인덱스를 관리하기 쉬운 단위로 분리하는 방법이다.

1.2 파티셔닝의 장점

가용성 : 물리적인 patitioning으로 인해 전체 데이터의 훼손 가능성이 줄어들고 데이터 가용성이 향상

관리용이성 : 큰 table들을 제거하여 관리를 쉽게 함

성능 : 특정DML과 Query의 성능을 향상시킴, 주로 대용량 Data Write 환경에서 효율적이며 많은 insert가 있는 OLTP 시스템에서 Insert 작업들을 분리된 파티션들로 분산시켜 경합을 줄임

1.3 파티셔닝의 단점

Table 간의 join에 대한 비용이 증가한다.

테이블과 인덱스를 별도로 파티션 할 수는 없다. 테이블과 인덱스를 같이 파티셔닝 하여야 한다.

1.4 파티셔닝의 범위

1. Range partitioning

연속적인 숫자나 날짜 기준으로 파티셔닝 한다

손쉬운 관리 기법 제공에 따른 관리 시간을 단축한다

2. List partitioning

특정 파티션에 저장될 Data에 대한 명시적 제어 가능하다.

분포도가 비슷하며, 많은 SQL에서 해당 Column의 조건이 많이 들어오는 경우 유용하다.

Muti-Column partition key 제공하기 힘들다.

3. Composite partitioning

파티션의 sub-partitioning을 말한다.

큰 파티션에 대한 I/O 요청을 여러 파티션으로 분산한다.

Range partitioning 할 수 있는 Column이 있지만, Partitioning 결과 생성된 파티션이 너무 커서 효과적으로 관리할 수 없을때 유용하다.

4. Hash partitioning

파티션 키의 해시 값에 의한 partitioning

select시 조건과 무관하게 병령 Degree 제공

특정 데이터가 어느 해시 파티션에 있는지 판단 불가

Hash Partition은 파티션을 위한 범위가 없는 데이터에 적합

1.5 파티셔닝 방법

1.Horizontal Partitioning

장점

데이터의 개수를 기준으로 나누어 파티셔닝 한다

데이터의 개수가 작아지고 따라서 인덱스의 개수도 작아지게 된다. 자연스럽게 성능은 향상된다

단점

서버간의 연결과정이 많아진다

데이터를 찾는 과정이 기존보다 복잡하기 때문에 latency가 증가하게 된다

하나의 서버가 고장나게 되면 데이터의 무결성이 깨질 수 있다.

2. Vertical Patitinoning

테이블의 컬럼을 기준으로 나누어 파티셔닝 한다.

정규화하는 과정도 이와 비슷하다고 볼 수 있지만 Vertical Patitioning은 이미 정규화된 Data를 분리하는 방법이다.

자주 사용하는 컬럼등을 분리시켜 성능을 향상시킬 수 있다.

2. 클러스터링

2.1 클러스터 정의

어떤 정해진 컬럼 값을 기준으로 동일한 값을 가진 하나 이상의 테이블의 로우를 같은 장소에 저장하는 물리적인 기법

디스크로부터 데이터를 읽어오는 시간을 줄이기 위해서 조인이나 자주 사용하는 테이블의 데이터를 디스크의 같은 위치에 저장시키는 방법

2.2 클러스터의 장점

그룹된 컬럼 데이터 행들이 같은 데이터 Block에 저장되기 때문에 디스크 I/O를 줄여 준다. 

클러스터된 테이블 사이에 조인이 발생할 경우 그 처리 시간이 단축된다.

클러스터키 열을 공유하여 한번만 저장하므로 저장 영역의 사용을 줄인다.

2.3 테이블 클러스터링의 특징

클러스터는 데이터 조회 성능을 향상시키지만 데이터 저장, 수정, 삭제 또는 한 테이블 전체 Scan의 성능을 감소시킨다.

1. 클러스터 하기 좋은 테이블

주로 조회가 자주 발생하고 수정이 거의 발생하지 않는 테이블

컬럼안의 많은 중복 데이터를 가지는 테이블

자주 join되는 테이블

2. 클러스터 key가 되기 좋은 컬럼

데이터 값의 범위가 큰 컬럼

테이블 간의 조인에 사용되는 컬럼

3. 클러스터 key가 되기 나쁜 컬럼

특정 데이터 값이 적은 컬럼

자주 데이터 수정이 발생하는 컬럼

LONG,LONG RAW 컬럼은 포함할 수 없다.

2.4 단일테이블 클러스터링

하나의 클러스터에 하나의 테이블만 생성시킨다.

2.5 다중테이블 클러스터링

하나의 단위 클러스터에 여러 개의 테이블을 생성한다.

기준되는 컬럼의 값이 동일한 각각의 테이블의 로우들이 하나의 단위클러스터에 저장되므로 기준 컬럼값으로 관련 테이블을 조인할 경우 추가적인 각 테이블들의 로우들이 흩어져 저장되는 경우 발생하는 추가적인 액세스가 불필요하여 높은 성능의 조인이 가능하다.

3. 데이터베이스 백업

3.1 데이터베이스 백업의 정의

DB의 고장, 데이터의 손실 등으로 인한 피해를 최소화하기 위하여 현재의 데이터를 저장하는 활동

3.2 백업의 종류

1. 백업을 받는 대상에 따라서 분류

시스템 백업 : 운영체제와 같은 시스템 백업을 말한다.

데이터 백업 : 데이터베이스 백업과 같은 파일 시스템 백업을 말한다.

2. 구성 방식에 따른 분류

직접연결 백업 : 서버와 백업장비를 일대일 관계로 직접연결하여 백업

네트워크 백업 : LAN을 통해서 백업장비와 서버를 접속하는 개념

SAN 백업 : 백업받을 데이터 용량이 증가함에 따라 백업용 테이프 장치를 SAN을 통해 인식시켜서 FC를 통해서 백업장치로 직접 백업받는 방식

3. 백업 방식에 따른 분류

핫백업 : DB서버를 온라인 상태로 유지한 채 데이터 백업

콜드백업 : DB서버를 중지한 후 데이터 백업

물리백업 : 파일 자체를 그대로 백업

논리백업 : 각 오브젝트를 SQL문 등으로 저장

3.3 데이터 백업시 대상 파일

Data file : 데이터를 저장한 파일

Control file : 데이터베이스 구조나 정보에 대한 상태를 저장한 바이너리 파일

Redo log file : 데이터 변경 처리사항을 저장한 파일

여기서 Redo log file은 데이터베이스 백업시 사용되는 파일이다.

핫백업이 진행되면 수많은 Redo log가 작성되어 디스크 용량을 차지하지만 이 파일을 사용하여 백업 이후 발생한 데이터의 변경 사항을 유연하게 처리할 수 있게 된다. 반대로 콜드 백업시에는 Redo log가 작성되지 않는다.

3.4 백업방법

1. phpMyAdmin

관리 패널에서 버튼 클릭만으로 콜드 백업 가능한 툴(Mysql)

4. 테이블 저장 사이징

데이터 예상치, 보관주기 및 각 컬럼사이즈 및 테이블 스토리지 옵션 등에 따라서 테이블의 크기를 예측해야 스토리지 용량산정이 가능하다.

4.1 사전 정보

테이블 크기 산정에 필요한 사전 정보로 Row의 데이터 길이와 항목별 크기 정보가 필요하다.

1. Row의 데이터 길이

테이블 크기를 산정하기 위해서는 컬럼의 데이터 타입별 실제 소비 크기와 저장되는 길이를 산정해야 한다. 이 정보는 테이블 크기를 산정하기 위한 항목별 크기 산정방법에 사용된다.

크기산정 테이블은 5개의 컬럼으로 구성되었다. 데이터 타입별 크게 산정은 DB의 종류에 따라 다를 수 있으므로 가정치로 수치를 조정한다.

4.2 테이블 크기 산정방법

한 Row 저장에 필요한 공간, 한블록의 데이터 공간, 한블록에 들어갈 수 있는 Row 개수, 총 데이터 Row 개수를 차례로 구하면서 필요한 총 데이터 공간을 산정한다.

5. 데이터 지역화

데이터베이스의 저장 데이터를 효율적으로 이용할 수 있도록 저장하는 방법이다.

물리적 데이터베이스의 설계에서 데이터 지역화를 고려한 보조 기억 장치의 설계는 중요하다

물리적 데이터베이스 설계, 보조 기억 장치의 역할, 디스크상의 파일의 배치를 지역화 관점에서 검토한다.

5.1 물리적 데이터베이스 설계

논리적인 설계에 데이터 구조를 보조 기억 장치상의 파일로 사상한다.

하나의 파일에 여러 릴레이션이 저장될 수 있다.

예상 빈도를 포함하여 데이터베이스 질의와 트랜잭션들을 분석한다.

데이터에 대한 효율적인 접근을 제공하기 위하여 저장 구조와 접근 방법들을 다룬다.

질의를 효율적으로 지원하기 위해서 인덱스 구조를 적절히 사용한다.

5.2 보조 기억 장치의 역할

각 파일은 고정된 크기의 블록들로 나누어져서 저장된다. 즉 ,여러 개의 블록들에 파일의 데이터가 분산되어 저장된다.

디스크는 데이터베이스를 장기간 보관하는 주된 보조 기억 장치이다.

-물리 데이터베이스 모델링

1. 물리 E-R 다이어그램

1.1 논리 데이터모델의 물리 데이터 모델로 변환

엔티티는 테이블, 속성은 컬럼 등으로 변환한다.

1.2 슈퍼 타입 기존 엔티티 통합

슈퍼 타입 엔티티를 중심으로 서브 타입 엔티티와 단일 테이블로 통합한다.

1.3 서브 타입 기준 엔티티 통합

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

1.4 개별 타입 기준 변환

1.슈퍼타입과 서브타입을 각각 테이블로 변환한다.

슈퍼타입과 서브 타입 각각의 테이블 사이에는 1대1 관계가 형성된다.

2. 개별 타입 기준 테이블 변환을 사용하는 경우

전체 데이터에 대한 처리가 자주 발생하는 경우 사용한다.

서브 타입 처리가 대부분 독립적으로 발생하는 경우 사용한다.

통합하는 테이블의 컬럼 수가 지나치게 많은 경우 사용한다.

서브 타입 컬럼 수가 다수인 경우 사용한다.

1.5 속성 및 컬럼 변환

1. 일반 속성 변환

2. Primary UID 기본 키 변환

논리 모델링에서의 Primary UID는 물리 모델링에서 기본 키로 생성된다 DDL에서는 오브젝트가생성되어 기본 키 제약 조건의 속성을 갖는다.

3. Primary UID 기본 키 변환

Primary UID의 속성 중에는 해당 엔티티에서 생성된 속성도 존재하지만 다른 엔티티와의 관계로 인해 생성되는 UID 속성도 존재할 수 있다. 이러한 관계 속성 UID의 변환은 일반적인 속성 UID 변환과는 차이가 있따.

4. Secondary UID 유니크 키 변환

논리 모델링에서 정의된 Secondary UID 및 Alternate key들은 해당 엔티티와 상대 앤티티의 선택적 관계를 갖는데 중요한 역할을 한다. 이러한 Secondary UID 들은 물리 모델에서는 유니크 키로 생성된다.

1.6 관계 변환

1. 1대M 변환

논리 데이터 모델의 관계에서 가장 보편적 형태의 관계이며 M측의 관계 컬럼에 선택사항이 결정되게 된다.

2. 변환

논리 데이터 모델에서 1대1 관계는 일반적이지 않은 형태의 관계로 1대1 관계를 물리 모델링에서 변환하는 과정은 관계의 기수성으로 인해 다른 방법이 적용된다.

3. 1대M 순환 관계 변환

일반적으로 데이터 계층 구조의 표현에 주로 사용하는 관계의 형태로 특성상 최상위관계속성은 항상 Optional의 형태를 보여야 한다. 그러나 경우에 따라 최상위 관계에 특정 값을 설정하는 경우도 있다.

4. 배타적 관꼐 변환

실제 데이터 환경에서는 빈번하게 등장하는 논리 데이터 모델의 배타적 관계 모델은 물리 모델링에서 생성하는 방법이 일반적인 관계 변환 방법과는 차이가 있다.

외래키 분리 

관계별로 관계 컬럼을 생성하는 방법으로 실제 외래 키의 제약 조건이 생성 가능하다는 장점이 있으나 키 컬럼들이 각각 Optional 의 형태여야 한다 또한 체크 제약 조건의 추가적 생성이 필요하다.

외래키 결합

관계들을 하나의 관계 컬럼으로 통합 생성하는 방법으로 실제 외래 키 제약 조건의 생성은 불가능 하고 다수의 관계를 선별하여 구분하기 위한별도의 컬럼이 필요하다.

1.7 관리 목적의 컬럼의 추가

논리모델링에서는 필요가 없으나 관리 또는 데이터베이스를 이용하는 프로그래밍의 수행 속도를 향상을 위해 추가되는 테이블인 ㅏ컬럼으로 관리상 필요한 데이터를 등록한 일자, 시스템 번호 등을 추가한다.

1.8 데이터 타입 선택

데이터 형식을 설정하는 것은 논리 모델링에서 정의된 논리적인 데이터 타입을 물리적인 DBMS 특성과 성능의 고려를 통해 최적 데이터 타입을 선택하는 작업이다.

주요 타입은 문자타입, 숫자타입, 날짜타입으로 구분할 수 있다

1.9 데이터 표준화

명명규칙 및 표준 용어 사전을 활용하여 각 객체의 데이터 표준화를 수행한다.

표준화 적용 대상은 데이터베이스, 스토리지 그룹, 테이블 스페이스, 테이블, 컬럼, 인덱스, 뷰이다.

2. 컬럼 속성

2.1 컬럼 속성 정의

정보를 나타내는 최소의 단위로써 앤티티의 성질, 분류, 수량, 상태, 특성 등을 나타내는 세부항목을 말한다.

2.2 속성의 유형

기본속성 : 해당 엔티티가 원래 가지고 있는 속성

실제속성 : 원래 업무에는 조냊하지 않지만시스템의 효율성을 위해 임의로 추가되는 속성

파생속성 : 다른 속성으로부터 계산이나 변형되어 생성되는 속성

               데이터 중복성 및 무결성 확보를 위해 가급적 적게 정의

2.3 속성 정의시 고려 사항

1. 앤티티가 관리할 특성들인가?

주문자 성명이란 속성은 주문 앤티티에 별도로 있어야 할까?

고객 엔티티와 관계만을 맺으면 될까를 확인해야 한다.

2. 의미적으로 독립된 최소단위인가?

속성은 멀티 파트가 되어서는 안된다. 멀티 파트라는 의미는 속성이 여러 개의 부분들로 이루어져 있는 경우와 하나의 의미를 가지는 여러 개의 속성이 존재하는 경우이다.

3. 하나의 값만을 가지고 있는가?

속성의 111워칙 : 엔티티 타입내에서 하나의 속성은 한시점에 한 개의 값만을 가져야 한다. 하나의 속성이 시간에 따라 여러 개의 값을 가지면 그 값을 해당업무에서 관리해야 할 필요가 있으면 새로운 엔티티를 생성한다.

- 데이터베이스 반정규화

1. 반정규화

1.1 반정규화의 정의

정규화된 엔티티, 속성, 관계를 시스템의 성능 향상, 개발과 운영일 단순화하기 위해 데이터 모델을 통합하는 프로세스 이다.

즉 데이터의 정합성과 무결성을 우선으로 할지 데이터베이스 구성의 단순화와 성능을 우선으로 할지를 결정한다.

1.2 반정규화 절차

1. 반정규화 대상 조사

범위 처리 빈도수 조사 : 자주 사용되는 테이블에 접근하는 프로세스 수가 많고, 항상 일정한 범위만을 조회하는 경우

대량의 범위 처리 조사 : 대량이 데이터 범위를 자주 처리하는 경우

통계성 프로세스 조사 : 별도의 통계 테이블 고려

테이블 조인 개수 : 지나치게 많은 조인이 걸려 데이터 조회 작업이 어려운 경우

2. 다른 방법 유도 검토

뷰테이블 : 지나치겜 낳은 조인이 걸려 데이터 조회 작업이 어려운 경우

클러스터링 또는 인덱스 적용 : 대량의 데이터는 PK의 성격에 따라 부분적인 테이블로 분리할 수 있다.

어플리케이션 : 로직을 변경함으로써 성능을 향상시킬 수 있다.

3. 반정규화 적용

테이블 반정규화

속성의 반정규화

관계의 반정규화

1.3 반정규화 방법

반정규화 방법은 반정규화 대상에 따라 테이블 반정규화, 컬럼 반정규화, 관계 반정규화로 나눈다.

1. 테이블 반정규화

테이블 반정규화 방법은 테이블 병합과 분할의 방법이 있다.

테이블 병합

조인되는 경우가 많아서 테이블을 합치는 것이 성능에 유리할 경우 병합

테이블 분할

테이블에서 특정 속성들만 집중적으로 접근할 경우 테이블을 분할

테이블 추가

중복테이블 추가 : 다른업무이거나 서버가 다른 경우 동일한 테이블 구조를 중복하여 우너격조인을 제거하여 성능 향상

통계테이블 추가 : SUM, AVG등을 미리 수행하여 자동계산해둠으로써 조회시 성능 향상

이력테이블 추가 : 마스터 테이블에 존재하는 레코드를 중복하여 이력테이블에 존재하는 방법

부분테이블 추가 : 하나의 테이블의 전체 컬럼 중 자주 이용하는 집중화된 컬럼들이 있을때  디스크의 I/O를 줄이기 위해 해당 컬럼 들을 모아 놓은 별도의 반정규화 된 테이블

2. 컬럼 반정규화

중복컬럼 추가

조인에 의한 성능저하를 예방하기 위해 즉 조인을 감소시키기위해 중복된 컬럼을 추가한다.

파생컬럼 추가

트랜잭션이 처리되는 시점에 계싼에 의해 발생되는 성능저하를 예방하기 위해 미리 값을 계산하여 컬럼에 보관

이력 테이블 컬럼 추가

대량의 데이터를 처리할 때 불특정 날 조회나 최근 값을 조회할 때 나타날 수 있는 성능저하를 예방하기위해 이력테이블에 가능성 컬럼을 추가함

PK에 의한 컬럼 추가

복합의미를 갖는 PK을 단일 속성으로 구성하였을 경우 발생됨 단일 PK안에서 특정 값을 별도로 조회하는 경우 성능저하가 발생될 수 있음. 이때 이미 PK안에 데이터가 존재하지만 성능향상을 위해 일반속성으로 포함하는 방법이 PK에 의한 컬럼추가이다.

응용시스템 오동작을 위한 컬럼 추가

업무적으로는 의미가 없지만 사용자가 데이터를 처리하다가 잘못 처리하여 원래 값으로 복구하기 원하는 경우 이전 데이터를 임시적으로 중복하여 보관하는 기법

3. 관계 반정규화

데이터를 처리하기 위한 여러 경로를 거쳐 조인이 가능하지만 이 때 발생할 수 있는 성능 저하를 예방하기 위해 중복 관계를 추가하는 방법

테이블과 컬럼의 반정규화는 데이터 무결성에 영향을 미치게 되나 관계의 반정규화는 데이터 무결성을 깨뜨릴 위험을 갖지 않고서도 데이터처리의 성능을 향상시킬 수 있음

3. 데이터베이스

 3.4 물리 데이터베이스 설계

 3.4.1 물리 데이터베이스 설계 능력 단위 정의

 3.4.2 물리요소 조차 분석

 3.4.3 데이터베이스 물리속성 설계

- 물리 데이터베이스 설계 능력 단위 정의

물리 데이터베이스 설계란 논리 데이터베이스 구조, 처리요구 조건, 데이터베이스, 하드웨어, 운영체제 특성을 기반으로 물리 데이터베이스의 저장 형식을 분석, 설계, 접근 경로를 물리적으로 설계하는 능력이다.

- 물리요소 조사 분석

1. 스토리지

1.1 스토리지 시스템의 정의

대용량 데이터를 저장하기 위하여 구성된 시스템

1.2 스토리지 시스템의 종류

1. DAS

서버와 저장 장치를 전용 컨트롤러와 케이블을 이용하여 연결하는 방식

2. NAS

서버와 저장 장치를 network로 연결하는 방식이다.

3. SAN

DAS의 빠른 처리와 NAS의 스토리지 공유 장점을 합친 방식

2. 분산 데이터베이스

2.1 분산 데이터베이스의 정의

하나의 데이터베이스 관리 시스템이 여러 CPU에 연결된 저장장치들을 제어하는 형태의 데이터베이스이다.

논리적으로 같은 시스템에 속하지만, 컴퓨터 네트워크를 통해 물리적으로 분산되어 있는 데이터들의 모임이다.

데이터베이스를 연결하는 빠른 네트워크 환경을 이용하여 데이터베이스를 여러 지역 노드로 위치시켜 사용성/성능 등을 극대화시킨 데이터베이스이다.

2.2 분산 데이터베이스의 목표

분할 투명성 : 하나의 논리적 Relation이 여러 단편으로 분할되어 각 단편의 사본이 여러 사이트에 저장

위치 투명성 : 사용하려는 데이터의 저장 장소 명시 불필요. 위치정보가 System Catlog에 유지되어야 함

지역사상 투명성 : 지역DBMS와 물리적 DB사이의 Mapping 보장. 각 지역시스템 이름과 무관한 이름 사용 가능

중복 투명성 : DB 객체가 여러 site에 중복되어 있는지 알 필요가 없는 성질

장애 투명성 : 구성요소의 장애에 무관한 Transaction의 원자성 유지

병행 투명성 : 다수 Transaction 동시 수행시 결과의 일관성 유지, Time Stamp, 분산 2단계 Locking을 이용 구현

2.3 분산 데이터베이스의 장단점

장점 

지역 자치정, 점증적 시스템 용량 확장

신뢰성과 가용성

효용성과 융통성

빠른 응답 속도와 통신비용 절감

데이터의 가용성과 신뢰성 증가

시스템 규모의 적절한 조절

각 지역 사용자의 요구 수용 증대

단점

소프트웨어 개발 비용

오류의 잠재성 증대

처리 이용의 증대

설계, 관리의 복잡성과 비용

불규칙한 응답속도

통제의 어려움

데이터 무결성에 대한 위협

2.4 분산 데이터베이스의 적용 기법

데이터베이스의 분산의 종류에는 테이블 위치 분산과 테이블 분할 분산, 테이블 복제 분산, 테이블 요약 분산 전략이 있다.

가장 많이 사용하는 방식은 테이블의 복제 분할 분산의 방법이고 이방법은 검색 성능 저하가 많은 데이터베이스에서 가장 유용하게 적용할 수 있는 기술적인 방법이 된다.

1. 테이블 위치 분산

테이블 위치 분산은 테이블의 구조는 변하지 않는다 또한 테이블이 다른 데이터베이스에 중복되어 생성되지도 않는다. 다만 설계된 테이블의 위치를 각각 다르게 위치시키는 것이다.

2. 테이블 분할 분산

단순히 위치만 다른 곳에 두는 것이 아니라 각각의 테이블을 쪼개어 분산하는 방법이다.

수평 분할

지사에 따라 테이블을 특정 컬럼의 값을 기준으로 로우를 분리한다. 컬럼은 분리되지 않는다. 모든 데이터가 각 지사별로 분리되어 있는 형태를 가지고 있다.

수직 분할

지사에 따라 테이블 컬럼을 기준으로 컬럼을 분리한다. 로우 단위로는 분리되지 않는다 모든 데이터가 각 지사별로 분리되어 있는 형태를 가지고 있다.

3. 테이블 복제 분산

테이블 복제 분산은 동일한 테이블을 다른 지역이나 서버에서 동시에 생성하여 관리하는 유형이다.

4. 테이블 요약 분산

지역간에 도는 서버 간에 데이터가 비슷하지만 서로 다른 유형으로 존재하는 경우가 있다.

2.5 데이터베이스 분산 구성의 가치

통합된 데이터베이스에서 제공할 수 없는 빠른 성능을 제공한다는 것

원거리 또는 다른 서버에 접속하여 처리하므로 인해 발생되는 네트워크 부하 및 트랜잭션 집중에 따른 성능 저하의 원인을 분산된 데이터베이스 환경을 구축하므로 빠른 성능 제공 가능

2.6 NoSQL

1.NoSQL

NoSQL은 수평적 확장이 가능하며 다수 서버들에 데이터 복제 및 분산 저장이 가능한 데이터베이스이다.

2. NoSQL의 데이터 저장 구조

key/value store

가장 기본적인 패턴으로 대부분의 NoSQL은 다른 데이터모델을 지원 하더라도 기본적으로 key/value의 개념을 지원함

ordered key/value stre

key/value store 의 확장된 형태로 key/value store와 저장 방식은 동일하나, 데이터가 내부적으로 key 순서로 sorting되어 저장됨

document key/value store

key/value store의 확장된 형태로, key에 해당하는 value 필드에 데이터를 저장하는 구조는 같으나 저장되는 value의 데이터 타입이 document 타입을 사용

3, 모델별 주요 NoSQL 제품

key/value store 모델

키기반의 get, put, delete 기능을 제공하며 메모리 기반에서 성능을 우선하는 시스템과 빅데이터를 저장 처리할 수 있는 방식으로 구분함

column family data store 모델

테이블 기반, 조인 미지원, 컬럼 기반으로 구글의 BigTable의 영향을 받음

document store 모델

JSON, XML 형태의 구조적 문서 저장에 용이하며 조인은 미지원

graph datadase 모델

그래프로 데이터를 표현하는 DB로서, 시맨틱 웹과 온톨로지 분야에서 활용되고 발전된 특화된 데이터베이스

3. 데이터베이스 이중화 구성

3.1 이중와의 정의

물리적으로 떨어져 있는 여러 개의 데이터베이스에 대하여 로컬 데이터베이스의 변경된 내용을 원격데이터베이스에 복제하고 관리하는 것이다.

3.2 이중화 목적

데이터베이스의 무정지 서비스를 가능하게 한다.

3.3 이중화의 형태 

DB 서버가 2대 있지만 이 2대가 동시에 동작하는 것을 허락할지에 따라 Active-Active 와 Active-Standby로 나뉜다.

3.4 Active-Standy 의 종류

Hot Standby : Standby 쪽 장비 기동 후 즉시 사용이 가능하고 failover 소요시간은 필요하다.

Warm Standby : Standby 쪽 장비 기동 후 이용하기 위하여 어느정도 설정 및 준비가 필요하다.

Cold Standby : Standby 측을 평소 정지시켜두며 필요에 따라 직접 켜서 구성한다.

Failover 소요시간은 Hot < Warm < Cold 순이다. 

3.5 이중화의 활용 

1. 장애

장비에 장애가 발생하여 1대가 죽을시, 준비된 장비를 서비스에 투입함으로써 짧은 시간내에 서비스복구가 가능하다.

2. 웹서비스의 배포

두대의 서버가 LB에 의하여 Active-Active로 운영되고 있는 경우, 한대를 LB에서 제거 한 뒤 배포 및 미들웨어 재기동 후 LB에 붙이고 다시 나머지 한대도 똑같이 작업하는 경우 서비스의 다운타임 없이 온라인 배포가 가능하다.

3. 장비의 점검

서버 혹은 네트워크장비를 운영시 OS나 Software Stack등을 보안이나 기능 추가 등의 이유로 업데이터 및 설정 변경 시 이중화를 이용하면 서비스의 다운타임 없이 점검이 가능하다.

4. 데이터베이스 암호화

4.1 데이터베이스 암호화 개요

1. 데이터베이스 보안과 데이터 암호화

데이터베이스 보안은 데이터베이스의 일부분 또는 전체에 대해 권한이 없는 사용자가 액세스하는 것을 금지하기 위해 사용되는 접근 통제 기술과 기밀 데이터에 접근하더라도 비밀성을 보장할 수 있도록 데이터를 암호화한다.

2 데이터 암호화 개념

외부로부터의 공격 또는 내부자의 불법행위로 인한 데이터 유출을 방지하기 위해 DB내에 저장된 데이터를 해독 불가능한 형식의 암호문으로 저장하는 행위이다.

4.2 DB 암호화 방식

디스크 전체를 암호화하거나 암호화 대상이 되는 기밀정보를 담고 있는 컬럼 레벨로 암호화 하는 경우가 있다.

컬럼 레벨 암호화의 경우 기존 Legacy 애플리케이션의 수정이 필요 없는 plug-in 방식과 애플리케이션의 수정이 필요한 API 방식이 널리 사용되고 있다.

1. 디스크 전체 암호화

DB 파일을 보호하고 비인가 사용자에 의한 불법적인 파일 열람을 제한하는 것이다. 인가된 서버만이 정상적인 암호화된 데이터를 해독하고 열람할 수 있게 하는것으로 DB암호화 중 가장 편한 방법이다.

하지만 DB파일을 암호화하는 것은 인가된 DB호스트 서버에 접속하는 다양한 시스템들과 사용자들을 식별하지 못하므로 이를 위해 컬럼 레벨의 암호화가 요구된다.

2. 컬럼 암호화

개인정보나 기업의 민감함 정보를 담고있는 특정 테이블의 컬럼만을 암호화하는 것

DB 서버에 접속하는 사용자들을 구분하고 정의된 암복호화 정책에 따라 데이터를 제공하므로 DB 암호화 솔루션 중에 현장에서 가장 널리 쓰이는 솔루션이다.

컬럼 암호화 종류는 Plug-In 방식과 API 호출방식이 있다.

5. 접근통제

5.1 DB 접근통제개요

데이터베이스에 저장된 데이터에 대해 사용자별 접근권한에 따라 접근을 제한하기 위한 기술이다.

1. 접근 통제 개념

데이터베이스의 보안을 구현하는 방법으로 접근 제어 방벙을 사용한다.

접근 통제는 보안 정책에 따라 접근 객체에 대한 접근 주체의 접근 권한 확인 및 이를 기반으로 한 접근 제어를 통해 자우너에 대한 비인가된 사용을 방지하는 기능을 말한다.

2. 접근 통제 정책

접근 통제 정책에는 크게 다음과 같은 3가지 유형이 있다.

DAC 

시스템 객체에 대한 접근을 사용자 개인 또는 그룹의 식별자를 기반으로 제한하는 방법

MAC

정보시스템 내에서 어떤 주체가 특정 객체에 접근하려 할때 양쪽은 보안 레이블에 기초하여 높은 보아 수준을 요구하는 정보가 낮은 보안 수준의 주체에게 노출되지 않도록 접근을 제한하는 통제 방법

RBAC

사용자가 주어진 역할에 대한 접근 권한을 부여받는 방식

사용자가 바뀌어도 역할에는 변함 없음

3. 접근 통제와 DCL 관계

접근 통제 정책 간운데 DBMS에서 채택한 접근 통제 정책은 DAC이다.

접근 통제 용도로 SQL에서 사용하는 명령어가 DCL이다.

5.2 DB접근 통제 구성방법

DB 접근제어를 구축하는 방법은 에이전트 방법, 게이트웨이 방법, 스니핑 방법으로 나눌수 있다.

DB 접근제어는 하나의 단일 방식으로 구성하기도 하지만 각 방식마다 장점을 취하고 단점을 보완하기 위하여 여러 방식을 혼합한 하이브리드 방식을 많이 사용한다. 일반적인 하이브리드 구성방식은 에이전트+스니핑 , 게이트웨이 + 스니핑,

게이트웨이+에이전트+스니핑 등이 있다.

1. 게이트웨이 방식

DBMS에 접속하기 위한 통로를 별도로 설치한 후 DB사용자가 해당 통로를 통해서만 접근하도록 하는 방식

게이트웨이를 거치도록 하는 기술에 따라 프록시 게이트웨이 방식과 인라인 게이트웨이 방식으로 구분된다.

프록시 게이트웨이 방식

별도의 서버를 설치한 후에 독립적인 IP 포트를 부여하고 DB로그인 시 해당 IP 및 포트로 로그인 하도록 한다.

인라인 게이트웨이 방식

별도의 장치에 의해 모든 패킷이 자동으로 게이트웨이를 거치는 방식

애플리케이션 서버에서 오는 패킷도 게이트웨이를 거치게 되어 속도 저하가 발생하고, 장애 발생 시 업무 시스템에 대한 영향이 있을 수 있다.

2. 스니핑 방식

DB 사용자와 DBMS 서버간에 주고받는 패킷을 복사하여 DB접근 제어 서버에 전달하는 방식이다.

스니핑 방식은 DBMS 서버의 패킷흐름에 전혀 영향을 주지 않아 성능 저하 등의 문제가 발생하지 않는다.

3. 에이전트 방식

DB서버에 접근제어를 설치하는 방식

4. 하이브리드 방식

별도의 구성방식이 아니라, 스니핑, 게이트웨이, 에이전트를 모두 혹은 이부를 사용하여 혼합한 방식이다.