ECMAScript는 Ecma international에 의해 표준화된 스크립트 언어의 명세서다
이 명세서는 웹 브라우저별로 달랐던 클라이언트 기반 스크립트의 구현을 표준화시키기 위해 만들어 졌음

html5덕에 스마트폰 애플리케이션마저도 자바스크립트로 개발할 수 있게 되었음

node.js라는 실행엔진
node.js는 웹서버처럼 네트워크 프로그래밍을 위해 개발된 자바스크립트 실행 환경이다.
그 심장부에는 구글 크롬에 탑재된 자바스크립트 엔진 V8이 있다
V8의 가장 큰 특징은 고속 수행능력이다
웹브라우저의 자바스크립트가 보안 때문에 파일처리 등이 불가능한 것에 반해 node.js를 사용하면 파일처리부터 네크워크 처리까지 다양한 작업을 소화가능
패키지 매니저인 npm을 사용하면 다양한 확장기능을 쉽게 도입 가능

Rhino와 Nashon
이들 자바스크립 엔진은 자바로 구현되어 있다.
그래서 자바의 가상머신위에서 자바스크립트를 실행가능
이들 자바스크립트 엔진의 최대 장점은 자바스크립트로 자바의 기능에 접근할 수 있는 것
즉 자바스크립트로 자바의 방대한 api나 라이브러리를 이용가능

이 책에서도 자바의 라이브러리를 이용한 프로그래밍을 소개하는데 이것이 가능한 것은 자바스크립트 엔진이 자바의 가상머신 위에서 수행되기 때문

Rhino는 자바 1.4이후에
그리고 Nashon은 자바 8이후에 이용할 수 있는 자바스크립트 엔진이다

기본적인 기능은 같으나 Nashon은 최신 자바버젼에 맞게 다시 작성되어서 jvm의 새로운 기능을 이용한 고속 수행이 가능하다 그리고 에러메시지가 친절하게 나와 디버깅이 쉽다는 특징이 있다

===
자바스크립트가 데이터 수집에 적합한 이유
코드 작성이 쉬운점을 들 수 있다
자바 스크립트를 위한 풍부한 라이브러리가 준비되어 있다

===
데이터 활용법에 관하여
크롤링하여 얻은 데이터를 활용하는 방법으로는 예측과 분류 그리고 연관 규칙 추출 등을 생각해 볼 수 있다

데이터마이닝
대량의 데이터를 분석하여 그안에서 가치 있는 정보를 발굴하는 것을 말한다
특히 지금까지 알려지지 않은 정보를 대량의 데이터에서 추출하는 기술체계를 가리킨다.
데이터를 조사할때는 통계학, 패턴 인식, 인공지능 등의 데이터 분석 기법을 사용한다.

원래 마이닝이란 채광이라는 뜻이다. 넓은 광산에서 숨겨진 금맥을 채굴하는 것처럼 대량의 데이터를 분석하여 가치 있는 정보를 찾아내는 것이 데이터 마이닝이다

데이터 마이닝에서 텍스트를 대상으로 하는 것을 텍스트 마이닝, 웹 페이지를 대상으로 하는 것을 웹마이닝이라고 한다

데이터마이닝의 기본은 예측, 분류, 연관 규칙 추출
데이터 마이닝의 어려운 점은 단순히 데이터를 넣으면 결과가 나오는 것이 아니라는 점에 있다.
대량의 데이터에서 지식을 찾아내기 위해서는 가설을 세우는 것이 좋다.
마케팅 분야에서는 가설을 세우고 검증하기 위해 예측, 분류, 연관 규칙 추출 기법을 검토한다.

예측:
장래 발생할 일이나 상태의 변화를 어떠한 근거에 기반을 두고 헤아려 보는 것을 말한다
비슷한 의미를 가지는 예상이라는 단어도 있지만, 예측이 예상과 다른 점은 보다 논리적인 근거에 기초하고 있다는 점
일반적으로 예측을 할때는 어떤 일이 발생활 확률을 계산하게 된다

분류:
많은 물건이나 현상들을 어떤 기준에 따라 체계적으로 구분하여 정리하는 것을 말한다.
분류를 하면 정보가 정리되어 사람이 파악하기 쉽게 된다.
방대한 장서를 분류함으로써 독자가 책을 찾기 쉬워진다.

연관 규칙 추출:
연관 규칙이란 어떤 일과 다른 일사이에 연결고리가 있음을 말한다
데이터베이스에 쌓인 데이터를 조사해보면 빈번하게 동시에 일어나는 경우를 발견할 수 있다.
이러한 정보는 전략에 활용될 수 있을 것이다

데이터 마이닝(특히 텍스트를 분석하는 텍스트 마이닝)의 순서
1)대상 데이터 수집
2)형태소 분석등으로 데이터 분할
3)데이터 클린징(이상치, 결손치, 노이즈 제거)
4)데이터 요약(차원 축소, 특징 선택 등)
5)데이터 마이닝(통계나 다른 데이터와 조합)
6)평가와 검증

대상 데이터를 수집하면
형태소 분석으로 텍스트를 이용하기 쉬운 최소단위(형태소)로 분할한다
그런 다음 클린징을 통해 이상치 및 결손치, 노이즈 등을 제거한다.
그리고 어떻게 활용할지를 고려하여 데이터를 요약한다. 예를들면 수치화하거나 의미있는 집합으로 모은다.
마지막으로 평가와 검증을 실시한다

대표적인 데이터 마이닝 기법
1)연관성 분석:X가 발생하면 Y도 발생할 가능성이 높다
2)회귀 분석:X의 속성으로부터 수치 변수 Y를 예측
3)클래스 분류:X의 속성으로부터 속하는 클래스 C를 예측
4)클러스터링:비슷한 것들 서로 묶는다

1)의 연관성 분석은 연관성 규칙 추출이라고 한다
대표적인 활용 예는 소매업의 POS시스템이다
예를 들어 편의점에서 빵과 야채 주스를 사는 사람은 요쿠르트도 같이 산다와 같은 분석을 하는 것을 말한다
이는 쇼핑 바구니속의 조합을 빠짐없이 조사하여 그중에서 흥미로운 결과를 찾아내는 분석이다

2)의 회귀분석은 상관 관계나 인과 관계가 있다고 생각되는 두 개의 변수 중 하나의 변수를 통해 미래의 값을 예측하기 위한 예측식을 구하는 방법이다
데이터 추세를 분석함으로써 예측을 할 수 있다

3)의 클래스 분류는 보다 정확하게 분류하는 모델을 만드는 것을 목적으로 한다
방정식이나 규칙, 확률, 매칭 등 다양한 기법이 있다

4)의 클러스터링은 데이터 집합을 공통의 특징을 갖는 부분 집합(클러스터)으로 나눈다
거리가 근접한 유사성을 기준으로 클러스터링을 한다


조사확인
phantomjs를 pdf를 다운받아보기
자바환경에서 pdf를 다운로드 받도록 하는 방법

d3.js에서 파생된 라이브러리(javascript graph comparison-www.jsgraphs.com)
NVD3.js. c3.js가 대표적 특히 c3가 예제가 많아 서 좋다

엣지 로케이션 - CDN서비스
가용영역(AZ)는 데이터센터이며 분리되어 있음

과금 옵션 비용 최적화 관련 자료
-온디맨드
-리저브
-스팟

autoscaling
-ELB, Cloudwatch, ec2, autoscaling

glacier
백업용 스토리지
액세스 시간이 있다

s3
정적 웹 사이트 호스팅 가능 -> github가 좋다

RDS
설정, 백업, os패치 자동화, DB이중화, Replica, 인스턴스 확장 장동으로

다이나믹DB - nosql
일라스틱캐시 - 인메모리DB

Internet gateway는
1)인터넷이 되는 용도말고는 없다
2)IP가 없다
3)내부적으로 여러대이다
4)자동으로 오토 스케일링 된다
5)VPC마다 존재

NAT gateway는
1) EIP가 자동으로 부여된다
2) nat ec2 vs nat gateway로 검색
3) 원래는 인스턴스였다
4) AZ마다 존재

EC2 인스턴스
생성하면 기본적으로 public ip가 생기는데 인스턴스 재부팅을 하면서 바뀌지 않지만 중지하면 pulbic ip가 없어진다.
그리고 시작하면 새로운 public ip를 받게 된다

우발적 종료를 풀려면 setting를 change해야 한다

public subnet은 internet gateway가 연결된 것을 말하는가?
--> ig + subnet + router table

앤드포인트로 된 RDS는 IP를 고정으로 해줄 수 없으므로
SG설정시 outbound all로 해준다
SG설정시 inbound가 훨씬 중요함

ADM
1)general - 빌드 안함
2)소스코드관리 - perforce / cvs
perforce credential / cvs credential
manual
character set - none
workspace name -
options - clobber / rmdir
line endings - local
type - writable
view mappings -

populate options - auto cleanup and sync
replace missing/modified files
delete generated files
quiet perforce messages

Polling build filters - add new build filter
Repository browser - (자동)

Build
root pom - pom.xml
Goals and options - clean verify

Build
root pom - pom.xml
Goals and options - clean install -Dbuild.number=${CHNAGELIST}


빌드 유발
build whenever a SNAPSHOT dependency is built

Post steps
Run only if build succeeds
send files or execute commands over SSH
name - DEV_USR
Transfers
source files - deploy/target/*.ear
remove prefix - deploy/target/
remote derectory - /adm
exec commnad - python *.py

<select parameterType="map" resultType="Integer">
SELECT IFNULL((SELECT IFNULL(CNT, 0) FROM TABLE), 0)
</select>

<beans xmlns:util="http://www.springframework.org/schema/util"
xsi:schemaLocation="http://www.springframework.org/schema/util http://www.springframework.org/schema/spring-util.xsd">


http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx.xsd


<!-- properties -->
<util:properties id="api" location="file:${home.dir}/api${server.type}.properties" />

<!-- db transcation -->
<bean id = "dataSource" class="org.springframework.jndi.JndiObjectFactoryBean" scope="singleton">
<property name="jndiName" value="java:/DDDS" />
<property name="resourceRef" value="true" />
</bean>

<bean id = "transcationManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource" />
</bean>

<tx:advice id="txAdvice" transaction-manager="transactionManager">
<tx:attributes>
<tx:method name="check*"/>
<tx:method name="insert*"/>
<tx:method name="update*"/>
</tx:attributes>
</tx:advice>

<aop:config>
<aop:advisor id="txAdvisor" advice-ref="txAdvice" pointcut="execution(* *..service..*.*(..))" />
</aop:config>

<!-- mybatis -->
<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="configLocation" ref="classpath:config/mybatis/mybatisConfig.xml" />
<property name="mapperLocations" ref="classpath:com/**/dao/sql/*.xml" />
</bean>
<bean id="sqlSessionTemplate" class="org.mybatis.spring.SqlSessionTemplate">
<constructor-arg ref="sqlSessionFactory" />
</bean>

<select id="xxx" parmeterType="map" resultType="hashmap">
SELECT
CAST(COUNT(CASE WHEN ABC.YN ='N' THEN 1 END) AS CHAR)AS N_CNT
,CAST(COUNT(CASE WHEN ABC.YN='Y' THEN 1 END) AS CHAR) AS Y_CNT
FROM ABC AS ABC;
</select>


public HashMap<String, String> getCount(){
Map<String, String> paramMap = new HashMap<String, String>();
paramMap.put("key","value");
      return sqlSessionTemplate.selectOne("xxx", paramMap);
}

16 성능 데이터 모델링
데이터 모델의 성능이 저하되는 원인
-데이터 모델구조
-데이터가 대용량
-인덱스 특성을 고려 못함

성능 데이터 모델을 수행하는 방법의 단계
첫째, 정규화를 정확하게 수행
둘째, 데이터베이스 용량 산정을 수행한다
셋째, 데이터베이스에 발생하는 트랜잭션의 유형을 파악한다
넷째, 용량과 트랜잭션의 유형에 따라 반정규화를 수행한다.
다섯째, 이력모델 조정, PK/FK 조정, 수퍼타입/서브타입 조정 등을 수행한다
여섯째, 데이터 모델을 검증한다

17 정규화를 통한 데이터베이스 성능 향상
정규화 수행과 성능의 관계
정규화 수행 -> 조회 기능 -> 성능이 향상되거나 저하될 수 있음
정규화 수행 -> 입력수정삭제기능 ->성능이 향상됨

18 반정규화를 통한 데이터베이스 성능 향상
반정규화는 비정규화, 역정규화라고 함
반은 반대하다의미이다

반정규화란 시스템의 성능 향상과 개발 및 운영의 단순화를 위해 정규화된 엔티티타입, 속성, 관계에 대해 중복, 통합, 분리 등을 수행하는 데이터 모델링 기법을 의미한다
좁은 의미의 반정규화는 데이터 중복하여 성능을 향상시키는 기법을 의미하며
더 넓은 의미의 반정규화는 성능을 향상시키기 위해 정규화된 데이터 모델에서 중복, 통합, 분리 등을 수행하는 모든 과정을 의미한다
반정규화를 적용할때는 데이터 무결성이 깨질 가능성이 많기 때문에 반드시 데이터 무결성을 보장할 수 있는 방법을 고려한 이후에 적용해야 한다

반정규화를 적용의 단계
첫째, 반정규화의 대상을 조사
전체 데이터양을 조사하고 그 데이터가 해당 프로세스를 처리할 때 성능 저하가 나타날 것인지 검증해야 한다
데이터가 대량이고 성능이 저하될 것으로 예상될때 다음 네가지 경우 중 하나에 해당하면 반정규화를 고려
-자주 사용되는 테이블에 접근하는 프로세스의 수가 많고 항상 일정한 범위만을 조회하는 경우
-테이블에 대량의 데이터가 있고 대량의 데이터 범위를 자주 처리하는 경우에 처리범위를 일정하게 줄이지 않으면 성능을 보장할 수 없는 경우
-통계성 프로세스에 의해 통계 정보를 필요로 하는 경우(이때는 반정규화된 별도의 통계 테이블을 생성한다)
-테이블에 지나치게 많은 조인이 걸려 데이터를 조회하는 작업이 기술적으로 어려울 경우

둘째, 반정규화의 대상에 대해 다른 방법으로 처리할 수 있는지 검토
-지나치게 많은 조인이 걸려 데이터를 조회하는 작업이 기술적으로 어려울 경우 뷰를 사용하면 이를 해결할수도 있다
뷰가 조회 성능을 향상시키는 역할을 수행하지는 않는다. 다만 개발자별로 SQL문장을 만드는 방법에 따라 성능 저하가 나타날 수 있으므로 성능을 고려한 뷰를 생성하여 개발자가 뷰를 통해 접근하게 함으로써 성능 저하의 위험을 예방하는 것도 좋은 방법이 된다.
-대량의 데이터 처리나 부분 처리에 의해 성능이 저하되는 경우 클러스터링을 적용하거나 인덱스를 조정함으로써 성능을 향상시킬 수 있다.
클러스터링을 적용하는 방법은 대량의 데이터를 특정 클러스터링 팩트에 의해 저장 방식을 다르게 하는 방법이다
이 방법은 데이터 입력/수정/삭제할때 성능이 많이 저하되므로 조회 중심의 테이블이 아니라면 생성하면 안되는 오브젝트이다
다만 조회가 대부분이고 인덱스를 통해 성능 향상이 불가능하다면 클러스터링을 고려할 만하다
인덱스를 통해 성능을 충분히 확보할 수 있다면 인덱스를 조정하여 반정규화를 회피하도록 한다
-대량의 데이터는 PK의 성격에 따라 부분적인 테이블로 분리할 수 있다
즉 파티셔닝 기법의 적용으로 성능 저하를 방지할 수 있다
인위적인 테이블을 통합/분리하지 않고 물리적인 저장기법에 따라 성능을 향상시키는 파티셔닝을 고려해 볼 수 있다
이 경우는 데이터가 특정기준(파티셔닝 키)에 의해 다르게 저장되고 파티셔닝 키에 따른 조회가 될때 성능이 좋아지는 특성이 있다.
따라서 특정 기준에 의해 물리적인 저장 공간이 구분될 수 있고 트랜잭션이 일정한 기준에 의해 들어온다면 파티셔닝 테이블을 적용하여 조회 성능을 향상시키는 것도 좋은 방법이 될 수 있다.
-응용 애플리케이션에서 로직을 구사하는 방법을 변경함으로써 성능을 향상시킬수 있다.
응용 메모리 영역에 데이터를 처리하기 위한 값을 캐쉬하거나 중간 클래스 영역에 데이터를 캐쉬하여 공유하게 하는 것도 성능을 향상시키는 방법이 될 수 있다.

셋째, 다른 방법이 없다면 반 정규화를 적용한다.

반정규화의 기법들
테이블관련 반정규화 방법
테이블 병합 기법
1)1:1관계 테이블 병합 -> 1:1관계를 통합하여 성능 향상
2)1:M관계 테이블 병함 -> 1:M관계를 통합하여 성능 향상
3)수퍼/서브타입 테이블 병합 -> 수퍼/서브 관계 통합하여 성능 향상

테이블 분할 기법
1)수직 분할 - 컬럼단위의 테이블을 디스크 I/O를 분산 처리하기 위해 테이블 1:1로 분리하여 성능 향상(트랜잭션이 처리되는 유형 파악이 선행되어야 함)
2)수평 분할 - 로우 단위로 집중 발생하는 트랜잭션을 디스크 I/O 및 데이터 접근의 효율성을 높여 성능을 향상시키기 위해 로우 단위로 테이블을 쪼깸(관계가 없음)

테이블 추가 기법
1)중복 테이블 추가 - 다른 업무이거나 서버가 다른 경우 동일한 테이블 구조를 중복하여 원격 조인을 제거하여 성능 향상
2)통계 테이블 추가 - SUM, AVG등을 미리 수행하여 계산해 둠으로써 조회 성능 향상
3)이력 테이블 추가 - 이력 테이블 중에서 마스터 테이블에 존재하는 레코드를 중복하여 이력 테이블에 존재하는 방법은 반정규화의 유형
4)부분 테이블 추가 - 하나의 테이블의 전체 컬럼 중 자주 이용하는데 자주 이용하는 집중화된 컬럼들이 있을 때 디스크 I/O를 줄이기 위해 해당 컬럼들을 모아놓은 별도의 반정규화된 테이블을 생성

컬럼관련 반정규화 방법
1)중복 컬럼 추가 - 조인에 의해 처리할 때 성능 저하를 예방하기 위해 즉 조인을 감소시키기 위해 중복된 컬럼을 위치시킴
2)파생 컬럼 추가 - 트랜잭션이 처리되는 시점에 계산에 의해 발생되는 성능 저하를 예방하기 위해 미리 값을 계산하여 컬럼에 보관함(Derived Column이라고 함)
3)이력 테이블 컬럼 추가 - 대량의 이력 데이터를 처리할 때 불특정 날 조회나 최근 값을 조회할 때 나타날 수 있는 성능 저하를 예방하기 위해 이력 테이블에 기능성 컬럼(최근값 여부, 시작과 종료일자 등)을 추가함
4)PK에 의한 컬럼 추가 - 복합 의미를 갖는 PK를 단일 속성으로 구성하였을 경우 발생이 됨. 단일 PK 안에서 특정값을 별도로 조회하는 경우 성능 저하가 발생될 수 있음. 이때 이미 PK안에 데이터가 존재하지만 성능 향상을 위해 일반 속성으로 포함하는 방법이 PK에 의한 컬럼 추가 반정규화임
5)응용 시스템 오작동을 위한 컬럼 추가 - 업무적으로 의미가 없지만 사용자가 데이터 처리를 하다가 잘못 처리하여 원래 값으로 복귀하기를 원하는 경우 이전 데이터를 임시적으로 중복하여 보관하는 방법. 컬럼으로 이것을 보관하는 방법은 오작동 처리를 위한 임시적인 기법이지만 이것을 이력 데이터 모델로 풀어내면 정상적인 데이터 모델의 기법이 될 수 있음

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

20 데이블 수직/수평 분할에 의한 성능 향상
트랜잭션의 집중 -> 수평분할/수직분할
대량의 데이터가 존재하는 테이블에 많은 트랜잭션이 발생하여 성능이 저하되는 구조의 테이블을 수평/수직분할 설계하면 성능 저하를 예방할 수 있다

수평분할 : 컬럼단위로 분할하여 I/O 경감
수직분할 : 로우단위로 분할하여 I/O 경감

테이블의 많은 양의 데이터가 예상될 경우 파티셔닝을 적용하거나 PK에 의해 테이블을 분할하는 방법을 적용할 수 있다
Rage partition적용(가장 많이 사용하는 파티셔닝의 기준)
요금일자+요금번호->요금일자의 년+월을 이용하여 12개의 파티션 테이블을 만들었음

List partition적용
지점, 사업소, 사업장, 핵심적인 코드값으 로 PK가 구성되어 있고 대량의 데이터가 있는 테이블이라면 적용할 수 있다.
List partition은 대용량 데이터를 특정값에 따라 분리 저장할 수 있으나 range partition과 같이 데이터 보관주기에 따라 쉽게 삭제하는 기능은 제공하지 않는다.

테이블을 수평분할할 것인지, 수직분할할 것인지 정하려면 두가지를 적용하면 된다
첫째, 데이터 모델링을 완성한다
둘째, 데이터베이스 용량 산정을 한다


21 수퍼타입/서브타입 모델의 성능 고려방법
Extended ER 모델이라고 불리우는 이른바 수퍼/서브 타입 데이터 모델은 최근 데이터 모델링을 할때  매우 자주 쓰이는 모델이다
이 모델이 자주 쓰이는 것은 업무를 구성하는 데이터의 특징을 공통점과 차이점을 고려하여 효과적으로 표현할 수 있기 때문
즉, 공통의 부분을 수퍼타입으로 모델링하고 공통으로부터 상속받아 다른 엔티티타입과 차이가 있는 속성에 대해서는 별도의 서브 엔티티타입으로 구분하여 업무의 모습을 정확하게 표현하면서 물리적인 데이터 모델로 변환을 할 때 선택의 폭을 넓힐 수 있다는 장점이 있다.

수퍼/서브 타입의 데이터 모델은 논리적인 데이터 모델에서 이용되는 형태이다

22 인덱스 특성을 고려한 PK/FK 데이터베이스 성능 향상
데이터 조회가 가장 효과적으로 처리될 수 있도록 접근 경로를 제공하는 오브젝트가 바로 인덱스이다
PK/FK컬럼 순서는 간단해 보이지만 실전프로젝트에서 아주 중요하다

물리적인 테이블에  FK를 사용하지 않아도 데이터 모델 관계에 의해 상속받은 FK속성들은 SQL Where 절에서 조인으로 이용되는 경우가 많이 있다.
따라서 FK 인덱스를 생성해야 성능이 좋은 경우가 많다.
그러므로 물리적인 테이블에 FK 제약을 걸었을 때는 반드시 FK 인덱스를 생성하도록 해야 한다.


23 효율적인 채번 방식을 통한 성능 향상
업무적으로 의미있는 식별자와 일련번호 형식의 시스템적 식별자에는 장단점이 존재

채번의 방법
-채번 테이블을 이용하여 일련번호를 증가시키는 방법 -> 채번구분컬럼, 채번컬럼
장:중복에러 없음, 순차적 데이터 입력 가능
단:잠금 현상 유발, 성능저하, 관리 항목 증가

-해당 테이블에 일련번호에 최대값+1을 바로 가져오면서 입력하는 방법 -> max(번호+1)
장:빠른 성능, 순차적 데이터 입력 가능, 관리항목 증가 없음
단:중복 에러 가능

-DBMS에서 제공하는 일련번호 증가 오브젝트(오라클의 시퀀스 오브젝트)를 이용하여 처리하는 방법
장:빠른 성능, 중복에러 없음, 잠금 현상 없음
단:순차적 데이터 입력 불가능, 관리 항목 증가

해당 테이블에 최대값을 처리하는 방법이 가장 권할 만하다 + PK중복 안되게 설계
예를 들어 구분자에 지역구분코드, 사업소구분코드, 업무구분코드 등을 포함하여 데이터 입력시 이코드에 따라 채번할 수 있게 하면 중복에러가 거의 발생하지 않게 되는 것

24 FK를 이용할 것인가?
FK를 생성하지 않을 때 발생하는 문제는 한가지 뿐이다
데이터의 참조 무결성이 깨지는 것이다

나중에 FK를 반영할때는 다음의 단계를 거쳐야 한다
1단계 데이터 베이스에 FK 제약 조건 생성
2단계 데이터 전환을 수행할 때 데이터의 문제점 검증(null값, 기존에 입력된 값의 FK규칙 만족성)
3단계 참조무결성으로 인해 입력되지 않은 데이터를 수정하여 전환
4단계 프로그램에 데이터 입력/수정/삭제 검증(에러가 발생하는 프로그램들을 추출하여 데이터 처리의 순서 등을 조정해야 함)
5단계 프로그램에서 데이터처리 성능 검증


25 데이터베이스 분산 설계를 활용
분산데이터의 정의
-여러곳으로 분산되어 있는 데이터베이스를 하나의 가상 시스템으로 사용할 수 있도록 한 데이터베이스
-논리적으로 동일한 시스템에 속하지만, 컴퓨터 네트워크를 통해 물리적으로 분산되어 있는 데이터들의 모임, 물리적 site분산, 논리적으로 사용자 통합 및 공유

분산데이터베이스가 되기 위한 6가지 투명성
-분할 투명성(단편화):하나의 논리적 relation이 여러 단편으로 분할되어 각 단편의 사본이 여러 site에 저장
-위치 투명성:사용하려는 DATA의 저장 장소 명시 불필요. 위치정보가 system catalog에 유지되어야 함
-지역사상 투명성:지역 DBMS의 물리적 DB 사이의 Mapping 보장, 각 지역시스템 이름과 무관한 이름 사용 가능
-중복 투명성:DB객체가 여러 site에 중복되어 있는지 알 필요가 없는 성질
-장애 투명성:구성요소(DBMS, computer)의 장애에 무관한 transaction의 원자성 유지
-병행 투명성:다수 transaction 동시 수행시 결과의 일관성 유지, timestamp, 분산2단계 locking을 이용하여 구현

분산 설계의 방법
-테이블의 복제
-분할 분산

분산환경에서의 데이터 동기화
-트랜잭션의 동기화
-배치작업 처리
-DBMS 기능 활용

언제 적용하면 효과적일까?
성능이 중요한 사이트에 적용해야 한다
공통코드, 기준 정보, 마스터 데이터 등에 대해 분산환경을 구성하면 성능이 좋아진다.
또한 실시간 동기화가 요구되지 않을때 좋다.
거의 실시간의 업무적인 특징을 가지고 있을때도 분산환경을 구성할 수 있다.
특정 서버에 부하가 집중이 될때 부하를 분산시키는 목적으로도 좋다
백업사이트(Disaster Recovery Site)를 구성할때도 간단하게 분산 기능을 적용하여 구성할 수 있다

26 데이터베이스 진단의 핵심 원리
설계단계의 진단
1) 데이터베이스 설계 - 물리적 데이터 모델, 데이터 무결성, 오브젝트설계, 테이블스페이스 설계, 데이터베이스 환경(파라미터설계), 가용성 설계
데이터 무결성을 유지할 수 있도록 비즈니스 규칙에 따른 참조 무결성 졔약 조건, 체크값, 디폴트 값들이 적절한지 진단함
오브젝트의 크기 및 성능을 고려한 인덱스의 설계 등을 진단함
세션의 수, 사용자 수, 메모리 사용량, 업무 증가량 등을 고려하여 데이터베이스 파라미터를 설계하였는지 진단

2) 표준 설계 - 명명규칙 설계,  SQL 작성 규칙 설계
데이터베이스 오브젝트(테이블, 테이블스페이스, 데이터파일, 인덱스, 뷰, 시퀀스, 컬럼명 등)에 대한 명명규칙이 존재하는지 진단
SQL 문장 작성에 대한 규칙은 존재하는지, SQL 문장에 대한 작성 규칙은 성능을 고려하여 반영되어 있는지 진단
개발자에게 SQL 튜닝, SQL 작성 가이드를 교육하였는지를 진단

3) 데이터 전환 - 현행 데이터 분석, 데이터 전환 계획서
전환 설계에는 데이터양, 전환 절차 및 방법, 데이터 검증 절차 및 방법, 테스트 일정이 포함되어 있는지 진단

4) 데이터베이스 운영 관리 - DB 변경 관리절차, DB 성능관리 절차, 백업/복구 절차
운영환경의 DB변경 절차가 있는지, 변경 절차에 관리자의 합의/검토/조정이 포함되었는지 진단
고객의 성능에 대한 요구 사항을 도출하였는지, 적절한 성능 모니터링 방안/툴이 있는지 진단
인덱스 생성/변경/삭제의 영향 분석을 위한 방안이 있는지 진단
DB 장애/백업/복구에 대한 고객의 요구 사항을 도출하였는지 진단

5) 분산 설계 - 분산 구조, 분산 구조에 따른 모델
업무별, 지역별, 서버별 프로세스 데이터 모델의 트랜잭션이 분석되었는지 업무별, 지역별, 서버별 분산 환경에 따라 트랜잭션을 고려한 분산 데이터 모델이 작성되었는지 진단함

6) 데이터베이스 보안 설계 - 데이터베이스 보안 정책, 접근 제어 설계, 암호화 필드
DB개발자 계정과 관리자 계정은 분리하여 관리하는지 진단
패스워드 컬럼에 대한 암호화 규칙은 설계되어 있는지 진단
DBMS의 기본계정(sys, system)에 대한 패스워드는 변경되어 있는지 진단

구축단계의 진단
1) 데이터베이스 성능 - 애플리케이션 성능, 데이터베이스 구조 성능
수행 애플리케이션에 대한 성능이력을 관리하는지 진단(성능 모니터링에 의거한 지속적인 튜닝작업을 하고 있는지, 성능 점검 프로세스를 준수하고 있는지 진단)
애플리케이션성능 기준을 설정하였는지, 운영 환경 데이터베이스에 실제 환경과 유사한 테스트 데이터가 입력되어 있는지 진단함
데이터베이스 메모리의 크기를 업무, 데이터양, 시스템의 물리 메모리를 고려해 산정하였는지 진단
데이터베이스의 동시 세션수, 세션 메모리, 세션 연결 방법에 대해 적절히 산정하였는지 진단
트랜잭션양을 고려해서 redo log의 크기를 산정하였는지 진단
인스턴스 복구 시간과 성능을 고려한 체크포인트 발생 주기를 설정하였는지 진단
데이터 정렬을 위한 메모리 크기는 적절한지를 진단

2) DB 오브젝트 관리 - 인덱스 추가 설계, 명명규칙
3) 데이터 전환
4) 데이터베이스 운영 관리, 변경 관리, 백업/복구, 운영 환경 준비
컨트롤 파일과 redo log에 대한 미러링이 되어 있는지 진단
운영자 가이드 작성을 위한 준비가 되어 있는지 진단

시스템 운영시점의 진단
1) 데이터베이스 구성 - 오브젝트, 테이블 스페이스, 이중화/분산 구성
인덱스의 데이터 분포도는 인덱스 효율을 보장할 수 있는지 진단
대용량 테이블은 적절한 방법으로 파티셔닝 되어 있는지 진단
VIEW, LOB, PL/SQL은 성능 고려하여 적절하게 구현되어 있는지 진단
테이블과 인덱스의 테이블스페이스를 분리하였는지 진단
트랜잭션양을 고려하여 redo log 크기를 산정하였는지 진단
데이터베이스 클러스터링(HA, RAC)에 대한 구성은 적합한지 진단

2) 데이터베이스 성능 - SQL 성능, 데이터베이스 구조 성능
3) 데이터베이스 관리 - 변경관리, 인시던트/문제관리, 데이터관리, 용량 관리
변경 실행전 원상복구 방안이 준비되고 충분한 테스트가 이루어지고 있는지 진단
장애 시나리오별 대응 방안이 수립되어 있는지, 이를 바탕으로 장애처리 하고 있는지, 장애 시나리오별 가용성 테스트를 주기적으로 수행하고 있는지 진단
version upgrade 및 patch 적용이 적절히 이루어지고 있는지 진단
테이블 및 인덱스에 대한 reoranization작업은 주기적으로 적절하게 수행되고 있는지 진단
데이터 보관주기에 따라 데이터 purge작업이 주기적으로 적절하게 이루어지고 있는지 진단

4) 데이터 품질
PK, FK, CK등 데이터 정합성이 유지되고 있는지 진단
비즈니스적 데이터 오류, 사용자의 데이터 입력 오류가 사전에 차단되고 있는지 진단

조인을 할때
각각 테이블에 ON절에 조인조건을 쓰게 되어 있음
보통의 개발자는 각각 테이블이 조인되는 ON절과 조인이 된 후의 WHERE절의 조건을 혼용해서 쓰게 되어서 어떨때는 쿼리의 성능이 많이 떨어질 경우가 있음
게다가 INNER JOIN을 할 경우 ON절을 쓰지 않고 WHERE절에 ON절의 내용을 쓰는 경우가 종종 있음

조인튜닝을 할때
1)ON절을 반드시 쓰도록 함
2)ON절에 해당 테이블과의 조인될때 필요한 조인조건과 연산되어야 하는 조건을 모두 써줌
EX)A와 B테이블의 조인한다면
ON절에 A테이블.조인컬럼 = B테이블.조인컬럼 이것도 써줘야 하지만 A테이블.DEL_FG = 'N' 이나 B테이블.DEL_FG = 'N' 등과 같은 WHERE절 써줘야 할것도 해당 조인시에는 ON절에 모두 기록함
3)조인쿼리의 WHERE절에는 모든 테이블과 조인이 된 후에 필터링할 조건을 써줘야 함

이렇게만 해도 조인 성능이 많이 올라감
왜냐면 조인쿼리에는 1)ON절이 실행 2)WHERE절이 실행 되기 때문임