<PL/SQL 구문의 구조>

PL/SQL은 다음과 같은 구조를 가지고 있다.

DECLARE (선언부)

프로그램에서 사용하는 객체 정의

BEGIN (실행부)

프로그램의 구체적인 실행 내용

EXCEPTION (예외처리부)

프로그램에서 예외 발생 시 처리할 내용

END;

/

위 구문에서 DECLARE 나 EXCEPTION 등은 로직에 따라서 생략도 가능하며, BEGIN과 END 사이에 다시 중첩으로 실행 블록을 넣는 것도 가능하다.

<변수>

변수의 선언은 var1 NUMBER; 와 같이 앞쪽에 변수명을 적고 뒤쪽에 데이터 타입을 적는다. 선언 시 var1 NUMBER DEFAULT 20;과 같이 기본값을 설정할 수 있다.

변수의 대입은 var1 := 10; 과 같이 := 연산자를 사용해야 한다.

변수의 타입은 크게 스칼라, 콤포지트, 참조 3가지로 나눌 수 있다.

 - 스칼라 타입 : 오라클에 의해 미리 정의된 데이터 타입이다. NUMBER, CHAR, VARCHAR2, DATE, BOOLEAN이 있다.

 - 콤포지트 타입 : 사용자에 의해 정의되어야 하는 타입이다. RECORD, TABLE, Nested TABLE, VARRAY가 있다.

 - 참조 타입 : 사용자가 정의하는 타입으로 처리 대상 데이터를 참조할 수 있는 특징이 있다. REF CURSOR가 있다.

이 외에 특수한 속성으로 %TYPE과 %ROWTYPE이 있다. 이 둘은 미리 정의된 변수의 데이터 타입을 참조할 때 사용한다.

먼저, %TYPE은 특정 컬럼의 데이터 타입을 참조할 때 쓰인다.

DECLARE

var1 dept.deptno%TYPE

BEGIN

SELECT deptno INTO var1 FROM dept WHERE location='KOREA'

END;

위와 같은 프로그램에서는 var1이 dept 테이블의 deptno 컬럼의 타입을 따라가는 것이다.

다음으로 %ROWTYPE은 특정 행 구조를 참조할 때 쓰인다.

DECLARE

row1 dept%ROWTYPE

BEGIN

SELECT deptno, dname, location INTO row1 FROM dept WHERE deptno=10;

END;

위와 같은 프로그램에서는 row1이 dept테이블의 특정 row의 구조(deptno, dname, location)의 데이터 타입을 모두 가져간다.

<욕심쟁이 수량자> 

전체 문자열을 가져온 다음 제일 뒤 문자부터 시작하여 하나씩 백트래킹하며 일치하는지 검사한다. 때문에 시스템 자원 소비가 크다.

욕심쟁이 수량자는 ?, +, *, {n, m} 와 같이 찾고자 하는 문자열 뒤에 사용한다.

예를 들어 원본 텍스트가 99999 인 경우, 9+로 검색하면 뒤에서 부터 찾는 방향으로 탐색하기 때문에 99999가 선택된다.

<게으른 수량자>

문자열을 처음 위치부터 시작하여 일치하는 문자가 등장할 때 까지 하나씩 탐색해 나간다. 

게으른 수량자는 ??, +?, *?, {n, m}? 와 같이 욕심쟁이 수량자 뒤에 ?를 붙인다.

원본 텍스트 99999에서 9+?로 검색하면 앞에서 부터 찾는 방향으로 탐색하기 때문에 9가 선택된다.

이 외에 독점적 수량자가 있다. 욕심쟁이 수량자처럼 최대한 많이 찾지만 백트래킹이 없고 찾은 내용을 표시하지 않는 특징이 있다. 

수량자 뒤에 +를 붙여서 사용한다. 

아직은 업무에서 쓰일 만한 때가 없었기 때문에 생략...

PL/SQL은 오라클에서 SQL을 확장하여 만든 프로그래밍 언어로 SQL에는 없는 반복문이나 분기문 등을 사용할 수 있다. 

시스템 운영을 하면서 자질구레한 데이터 조작 업무가 많은데, SQL로만 하기에는 너무 공수가 많이 들고 

그렇다고 JAVA나 Pro* C로 짜자니 과한 것 같은 경우가 있다. 이럴 때 적합한 것이 PL/SQL이지 않을까 싶어 기초정도만 배워두려 한다.

사내 정보자료실에서 <전문가를 위한 오라클 PL/SQL 입문> (저: 어시스트 교육부)라는 책을 빌렸다. 

Today I wrote English business mail for the first time.

I was a bit nervous because it can be rude if I made mistakes.

However I could write well thanks to one of my chatting friends who I met here.

And I learned new expression 'go through'.

 * go through : 

   1) 읽다 - I'm going through the news.

   2) 겪다 - I just want to let people know what I went through.

해쉬 인덱스는 해쉬 함수(Hash function)을 기반으로 인덱스의 엔트리를 구성한다. 인덱스 엔트리는 아래 그림과 같이 버켓(bucket)이라고 불리는 공간에 저장되며 각 버켓에 해쉬 함수에 의해 생성된 버켓 번호가 부여된다. 바로 이 버켓들의 집합이 해쉬 인덱스인 것이다. 

해쉬 인덱스를 생성하면 인덱스로 구성하려는 필드 값들을 해쉬 함수로부터 버켓 번호를 부여받아 해당 버켓에 엔트리를 저장한다. 해쉬 인덱스를 사용하여 검색을 할 때도 인덱스를 구성한 필드 값을 해쉬 함수에 적용하여 버켓 번호를 알아낸 뒤 해당 버켓 번호를 가진 버켓 엔트리 중에서 추출하는 것이다.

해쉬 함수는 대규모 데이터 키 집합에 대해서 적은 범위의 데이터 집합으로 대응시키는 함수를 말한다. 대응되는 함수 값(=해쉬 값)은 입력 값의 분포와 상관 없이 균등하게 분포되어야 한다. 가장 간단한 예로는 모듈러 연산을 들 수 있겠다. 예를 들어 해쉬함수 H(X) = X % 3이라고 정의한다면, 인덱스를 구성하고자 하는 컬럼의 값을 3으로 나누어 나머지에 해당하는 값을 버켓 번호로 지정하는 것이다.(아래 예시 참조)

해쉬 함수는 인덱스 엔트리들 각 버켓에 균등하게 할당되도록 짜여져 있겠지만, 입력 값에 따라서 완전히 동일할 수는 없기 때문에 특정 버켓이 오버플로가 발생할 수 있다. 이 경우 버켓의 개수를 늘리고 해쉬 함수를 변경 하는 등의 인덱스 재구성 작업이 필요하다. 

해쉬 인덱스는 B+트리 인덱스에 비해 등동조건 검색(ex select * from 테이블 where A컬럼 ='1001')에 유리하다. B+트리 인덱스는 트리의 높이만큼 검색을 해야하지만, 해쉬 인덱스는 해당 버켓을 찾는데 한 번의 검색이면 되기 때문이다. 하지만 데이터가 순차적으로 저장되지 않고 각 버켓에 나누어 저장되기 때문에 범위조건 질의(ex select * from 테이블 where A컬럼 between '1001' and '2001')에는 효과가 없다.

아래와 같이 두 개 이상의 필드를 이용해서 인덱스를 구성하는 것을 복합 인덱스(Composite index)라고 한다. 인덱스는 검색키와 주소의 쌍으로 구분되며 이를 인덱스 엔트리(Index Entry)라 부르는데, 복합인덱스는 검색키 N개와 주소의 쌍이 인덱스 엔트리가 되는 것이다.

이 때, 인덱스는 대소관계에 의해 검색키1을 우선 정렬하고 검색키1에 대해여 검색키2를 정렬하는 방식으로 구성된다. 예를 들어, 아래 좌측과 같은 테이블이 있고 A와 B컬럼을 복합 인덱스로 하면,  아래 우측과 같이 인덱스가 만들어 지는 것이다.

A컬럼과 B컬럼의 인덱스가 각각 만들어져 있다면,  select * from 테이블 where A컬럼='1001' and B컬럼='2' 라는 질의를 날렸을 때, A컬럼='1001'의 조건으로 참조된 결과와 B컬럼='2'의 조건으로 참조된 결과를 비교하여 중첩된 레코드를 찾을 것이다. 하지만 복합 인덱스로 구성했을 경우에는 두 조건을 만족하는 레코드를 하나의 인덱스로 처리할 수 있어서 효율적이다. 

또한 select B컬럼 값 from 테이블 where A컬럼='1001' 처럼 원본 데이터에 접근하지 않고도 복합 인덱스내에서 바로 질의 처리가 가능해지는 경우도 있다.

단, 필드의 순서에 따라 인덱스 효과가 달라지기 때문에 주의를 요한다. 

예를 들어,

select * from 테이블 where  A컬럼 = '1001' and B컬럼 > '2' 와 

select * from 테이블 where  A컬럼 > '1001' and B컬럼 = '2'라는 질의를 날린다고 해보자. 

첫 번째 질의는 A컬럼 키 1001을 찾은 뒤 제한 된 B 컬럼의 검색키를 검색하면되지만, 두 번째 질의는 A컬럼 > '1001'을 만족하는 검색키를 모두 검색하면서 B컬럼='2' 조건을 조회하기 때문에 효율적으로 동작하지 않는다. 따라서 두번째 질의를 잘 처리하기 위해서는 (B컬럼, A컬럼)의 순서로 구성된 필드 집합으로 복합 인덱스를 생성해야 한다.

결국 복합 인덱스를 만들 때는 자주 사용되는 질의 유형을 사전에 분석하여 결정해야 하는 것이다.

DB에서 데이터에 대한 접근은 결국 디스크 I/O라는 뜻이다. 디스크를 헤드를 위치시키고, 디스크를 회전하고, 데이터를 전송하고... CPU만큼이나 빠르게 작동하지 않는다. 때문에 검색의 효율을 높이기 위해서 인덱스를 설정한다. 이 인덱스의 방식 중 가장 널리 사용되는 방식이 B+트리 인덱스이다.

차수가 N인 B+트리의 노드 구조는 위와 같이 N개의 포인터와 N-1개의 검색키의 집합으로 구성되어 있다.  

키는 Key i-1 < Key i < Key i+1 ... 의 관계를 가지고 있으며, Key i와 Key i+1 사이에 있는 포인터인 P i+1이 가리키는 하위 노드 집합에는 Key i보다는 크고 Key i+1보다는 작거나 같은 검색키들이 위치해 있다. 

레코드가 10만 개인 테이블에서 특정 레코드를 검색한다고 했을 때, 인덱스가 구성되어 있지 않다면 최악의 경우 10만 건을 전부 스캔해야 한다. 반면, 차수가 10인 B+트리로 구성했을 경우 아래와 같이 구조가 형성되기 때문에 최악의 경우에도 10개의 키를 4번 검색하는 것만으로 원하는 레코드를 찾을 수 있다. 

대략적으로 시간복잡도가, O(N)에서 O(logN)으로 향상되는 셈이다.

라우팅이란 라우터가 자신과 연결된 다른 라우터를 찾아 최종 목적지까지 연결하는 과정이다. 라우팅에는 동적 라우팅과 정적 라우팅이 있다. 

정적 라우팅은 네트워크 관리자가 경로를 목적지별로 직접 지정해 두는 것인데, 경로가 미리 입력되어 있기 때문에 CPU 부담이 적고 라우터 간 대역폭을 낭비하지 않는 다는 장점이 있지만, 어떤 라우터간에 연결되어 있는지 파악해야하는데다 추가 회선이 필요할 때 새로 설정해주어야 하는 불편함과 현재 설정한 회선에서 연결이 불능에 빠지는 경우 자동으로 새로운 경로를 찾지 않는다는 단점이 존재한다.

반면, 동적 라우팅은 라우팅 프로토콜을 사용하여 자동으로 경로를 수집하여 라우팅 테이블을 설정하는 것이다. 이 프로토콜에는 여러가지가 있다.

그 중 하나는 RIP(Routing Information Portocal)로, 목적지까지의 거리를 살펴보고 홉(hop)수가 적은 경로를 선택한다. 구성이 간단한 LAN과 같은 네트워크에 적합하다. 아래 그림에서 데이터가 도착해야 하는 목적지가 라우터5라면, 라우터1을 거쳐 라우터3, 라우터5로 가는 것이 가장 유리한 경로라고 할 수 있다.

다음은 OSPF(Open Shortest Path First)로, 통신상태 정보를 맵(map)으로 관리하면서 상태가 좋은 경로를 선택하는 방식이며, 복잡하고 변화가 다양한 네트워크에 적합한 형태다. 만일 아래와 같이 라우터2번과 라우터4번 사이에 고속회선이 적용되어 있다면 데이터는 라우터1, 라우터2, 라우터4를 거쳐 라우터5로 향하는 것이 유리할 수 있다. 즉, 라우터1은 라우터2의 상태가 '좋다'라는 정보를 보유하고 있어야 한다.

마지막으로 BGP(Border Gateway Protocol)가 있는데, 경로의 거리뿐만 아니라 경유 AS(Autonomous System 자율시스템)를 포함하여 경로 정보를 생성하는 형식으로 규모가 큰 네트워크에서 몇 개의 네트워크를 묶어 AS단위로 관리하는 것이다. 네트워크 전체 경로를 탐색하는 것이 아니라 AS같이 큰 덩어리 단위로 이동하여 원거리 컴퓨터와 빠르게 통신하는 것이 목적이다. 

정렬 중 O(nlogn)의 시간복잡도를 가진 방법으로, 개인적으로는 퀵소트나 힙정렬 보다는 구현이 간단하다. 

정렬해야하는 원소가 적다면(정확한 것은 모르겠지만 5개 이하) 삽입정렬이 더 낫다고도 한다.

스택오버플로우를 보면 퀵 정렬이 최악의 경우 O(n^2)임에도 여러가지 이유로 

병합 정렬보다 나은 성능을 보인다고 하는데, 확인해보아야 할 듯 싶다.

C++ std library에는 퀵 정렬과 힙 정렬을 적당히(?) 활용한 Intro sort라는 게 쓰이는 듯 하다.

(http://stackoverflow.com/questions/70402/why-is-quicksort-better-than-mergesort)

https://gist.github.com/woo972/0924604b96188cb78b9cf8b1a34fbd19

sed -E '1s/^(.*)/<!Doctype html>\

<head>\

<title>\1</title>\

</head>\

/;q' test.txt

1. -E 옵션 : sed가 확장정규표현식을 사용할 수 있게 해준다. 만약 이 옵션이 없다면 괄호를 표기할 때 \(\) 처럼 처리해 주어야 한다.

2. s : 1행에서 뒤에 나오는 패턴으로 검색하여 치환한다.

3. (^(.*)$) : 참조그룹으로 행 전체를 선택.  \1로 재참조한다.

4. \ : 행 끝에 \를 붙여서 개행문자의 특수의미를 무효화한다. (=> 명령어를 여러줄에 걸쳐 입력할 수 있다)

5. q : 화면에 텍스트 나머지를 출력하지 않고 sed를 종료한다.

결과 : test.txt파일의 첫 행의 내용을 html형식으로 맞추어 title 태그안에 넣는다.