애자일 개발 프로세스의 개념
애자일 개발 프로세스란, 어느 특정 개발 방법론을 가리키는 말은 아니고, "애자일(Agile=기민한, 좋은것을 빠르고 낭비없게 만드는 것) 개발을 가능하게 해주는 다양한 방법론 전체를 지칭하는 말이다. 예전에는 애자일 개발 프로세스는 "경량(Lightweight)"프로세스로 불렸다. 익스트림 프로그래밍 (XP:eXtreme Programming)이 애자일 개발 프로세스의 대표적인 방법이라 볼수 있다.


애자일 개발 프로세스의 배경
애자일 프로세스의 배경에는 소프트웨어 개발 자체가 과거와 양상이 바뀌었다는 전제가 있다. 90년대 후반까지의 소프트웨어 개발은 장기간에 걸쳐 많은 사람들을 투입하고 충분한 비용을 투입하여 진행하는 것이었다. 소프트웨어 공학이나 많은 관리 방법론들이 모두 이러한 종류의 프로젝트를 대상으로 삼고 있다.

그러나 지금의 소프트웨어는 개발기간이 짧고 적은 비용을 투입한다. 게다가 매우 복잡하고 개방적이다. 또한, 사회의 상황이나 시장의 변동에 따라 변화가 심하고 요구사항도 시시각각 변해가고 있다. 그래서 이미 고전적인 소프트웨어 공학이나 관리 기법 만으로는 대처할수 없게 되었다.

이런 문제에 대한 기술적인 해결책으로 "객체지향(OO:Object Oriented)"이 있다. 객체지향 기술은 그동안의 개발 문제를 적절하게 대처해 주었다. 그리고, 객체지향 개발을 하기 위해서는 그에 적합한 개발 프로세스가 필요했다. 그래서 수많은 애자일 개발 프로세스가 이러한 필요에 따라 만들어졌다. 따라서, 애자일 개발 프로세스의 상당수는 객체지향 기술을 기반으로 한다.

애자일 개발 프로세스는, 제한된 시간과 코스트 안에서 정보는 불완전하고 예측은 불가능 하다는 전제를 가진다.그리고 그 전제아래에서 합리적인 답을 내도록 하는 것이 애자일 개발 프로세스이다.


애자일 개발 프로세스와 전통적인 개발 프로세스와의 차이
전통적인 개발 프로세스들은 폭포수 모델과 계획 기반 개발을 따르는 반면, 애자일 개발 프로세스는 그에 반한다는 점에서 가장 큰 차이를 가진다.
폭포수 모델과 계획 기반 개발 기법들은, 일련의 차례와 탄탄한 계획을 기반으로 하여 개발을 진행시킨다. 이것은, 이해하기도 쉽고 사용하기도 쉬운 바람직한 기법이기도 하지만, 이로 인해서 많은 부작용이 생길 수 있다. 가장 큰 부작용이 발생할 때는, 계획대로 진행되지 않을 경우이다. 이럴경우에는 다음과 같은 부작용이 발생하게 된다.

• 납기일 전 철야
• 철야에도 불구하고 납기일 지연
• 지연에 따른 비난과 스트레스가 개발자에게 향하여 에너지 소진
• 결국 납기된 솔루션은 고객의 요구를 충족하지 못함

이런 부작용은 근본적인 개발 프로세스 접근법의 차이에서 나타난다. 전통적인 개발 프로세스들은 공업에서 사용하는 정형적 프로세스 제어 모델을 따르고 있다. 정형적 프로세스 제어모델은, 동일한 입력에 대해서 동일한 결과가 기대 될 경우에 적합하다. 하지만, 소프트웨어를 포함한 IT의 개발은 경험적 프로세스 제어 모델로 접근할 필요가 있다. 경험적 프로세스 제어 모델은 항상 불확실성을 수반하고 포용하고 있다. 애자일 개발 프로세스는 경험적 프로세스 제어모델로 개발을 관리한다.


애자일 개발 프로세스의 종류
애자일 개발 프로세스로 불리우는 개발 방법론에는 다음과 같은 것들이 있다.

• 익스트림 프로그래밍, XP - 애자일 개발 프로세스의 대표자로 애자일 개발 프로세스의 보급에 큰 역할을 하였다. 이 방법은 고객과 함께 2주 정도의 반복개발을 하고, 테스트와 우선 개발을 특징으로 하는 명시적인 기술과 방법을 가지고 있다.

• 스크럼 - 30일마다 동작 가능한 제품을 제공하는 스플린트를 중심으로 하고 있다. 매일 정해진 시간에 정해진 장소에서 짧은시간의 개발을 하는 팀을 위한, 프로젝트 관리 중심의 방법론이다.

• 크리스탈 패밀리 - 이 방식은 프로젝트의 규모와 영향의 크기에 따라서 여러종류의 방법론을 제공한다. 그중에서 가장 소규모 팀에 적용하는 크리스탈 클리어는 익스트림 프로그래밍 만큼 엄격하지도 않고 효율도 높지 않지만, 프로젝트에 적용하기 쉬운 방법론이다.

• Feature-Driven Development - feature마다 2주정도의 반복 개발을 실시한다. Peter Coad가 제창하는 방법론으로써, UML을 이용한 설계 기법과도 밀접한 관련을 가진다.

• Adaptive Software Development, ASD - 소프트웨어 개발을 혼란 자체로 규정하고, 혼란을 대전제로 그에 적응할 수 있는 소프트웨어 방법을 제시하기 위해 만들어진 방법론이다. 내용적으로는 다른 방법론들과 유사하지만, 합동 어플리케이션 개발(Joint Application Development, 사용자나 고객이 설계에 참가하는 개발 방법론)을 사용하고 있는것이 조금 다르다.

• 익스트림 모델링 - 익스트림 모델링은 UML을 이용한 모델링 중심 방법론이다. 다만, 여타 모델링 방법들과는 달리, 항상 실행가능 하고 검증가능한 모델을 작성하는 공정을 반복해서, 최종적으로는 모델로부터 자동적으로 제품을 생성하게 한다.

설명

나선형 모형은 Boehm이 제안한 것으로, 폭포수 모형과 프로토 타입 모형의 장점에 위험 분석 기능을 추가한 모형이다. 

• 나선을 따라 돌듯이 여러 번의 소프트웨어 개발 고정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것으로, 점진적 모형이라고도 한다.
• 소프트웨어를 개발하면서 발생할 수 있는 위험을 관리하고 최소화하는 것을 목적으로 한다.
• 프로젝트 총 예산이 1~5%정도 더 증가한다.
• 각각의 사이클 별로 지속기간이 한계가 있다.
  

개발 순서

• 가장 현실적인 모형으로, 대규모 프로젝트나 큰 시스템에 적합하다
• 점진적으로 개발 과정이 반복되므로 누락되거나 추가딘 요구사항을 첨가할 수 있고, 정밀하며, 유지보수 과정이 필요 없다.
• 위험분석 단계에서 기술과 관리의 위험 요소들을 하나씩 제거해 나감으로써 완성도 높은 소프트웨어를 만들 수 있다.
• 각 단계에 적당한 테스팅이 이루어져 개발과정에 발생하는 여러 문제점의 해결방안을 찾기 때문에 테스팅 비용 및 개발지연등의 문제를 해결할 수 있다.

단점

• 위험성 평가에 크게 의존하기 때문에 이를 발견하지 않으면 반드시 문제가 된다.
• 위험요인을 추출하고 분석하는데 많은 비용이 소요되고 초기의 요구분석 결과 자체가 불완전한 경우, 위험분석의 의미가 없다.
• 위험분석 결과가 불완전한 경우, 사용자의 요구충족에 의미가 없고, 개발비용만 낭비하게 된다.
• 상대적으로 복잡하여 프로젝트 관리 자체가 어렵게 될 수도 있다.
  

RDBMS 이론이 소개 된 지 어느덧 30년이 지났다. 30년의 긴 세월이 흐르면서 RDBMS는 우리의 일상에도 많은 부분을 차지하게 된 것 같다. 우리가 사용하는 대부분의 웹 사이트에서 RDBMS를 사용하고 있으며 이로 인해 우리의 정보는 체계적으로 관리되고 있을 것이다. RDBMS의 보급화와 함께 RDBMS의 기술은 계속 향상되고 있지만 이 중에서 RDBMS의 탄생과 함께 태어난 조인은 그 중요성에 비해 많은 천대를 받는 것 같다. 이제라도 우리는 RDBMS의 꽃인 조인을 정확히 이해해 보자.

권순용 | kwontra@hanmail.net

지금도 수많은 사이트에서 데이터 연결에 대한 불신을 가지고 있는 것이 현실이다. 어떤 사이트에 가보면 데이터 연결 방법 중에 하나인 조인을 사용하지 못하게 하고 또 어떤 사이트에 가보면 서브쿼리를 사용하지 못하게 하는 것을 지켜보는 경우가 있었다. 물론, 서브쿼리도 데이터 연결의 한가지 방법이며 조인과 거의 유사하게 수행된다.

분명 조인은 RDBMS의 꽃이며 이러한 핵심 기술을 이용하지 않는다면 RDBMS를 이용해서 무슨 효과를 기대할 수 있겠는가? 조인의 실제 수행 방식을 이해하지 않으려 하고 조인을 잘못 사용했기 때문에 나타나는 현상을 그대로 받아들이고 그것만을 가지고 모든 것을 평가하는 것이 현실인 것 같다.

조인의 수행 방식을 정확히 이해했다면 우리는 이와 같은 성능 저하 현상을 바로 잡을 수 있다는 사실을 명심해야 할 것이다. ‘조인은 성능을 저하시킨다’는 잘못 알고 있는 사실을 다시 확인해 보는 기회로 삼아보았으면 좋겠다.

조인은 데이터를 감소시킨다

조인은 현재 데이터베이스의 크기를 감소시킬 수 있는 유일한 방법이다. 이와 같이 이야기한다면 의아해 할 것이다. 조인이 어떻게 데이터베이스의 크기를 감소시킬 수 있겠는가? 당연히 조인을 이용하여 데이터베이스의 크기를 감소시킬 수는 없다.

여기서 말하는 것은 데이터베이스의 정규화를 거치게 되면 데이터베이스에 존재하는 테이블은 분리되며 테이블이 분리된다면 일반적으로 데이터베이스의 크기는 감소하게 된다. 이와 같이 테이블을 분리하여 두 개 이상의 테이블에서 우리가 원하는 데이터를 추출하기 위해서는 조인을 이용해야 한다는 것이다.

이와 같기 때문에 정확히 이야기한다면 데이터를 감소시키기 위해 조인을 사용한다기 보다는 크기가 감소된 데이터에 대해 조회를 수행하기 위해 조인을 사용한다는 것이다.

예를 들어, 어느 회사에 직원 테이블이 존재하며 또 하나의 경우는 사원 테이블과 부서 테이블이 별도로 존재한다고 가정하자. 회사에는 1,000,000명의 직원이 존재하며 해당 회사에는 1,000개의 팀이 존재한다고 가정하자. 그렇다면 아래와 같이 구성될 수 있을 것이다.

<그림>처럼 테이블을 구성했다고 가정하자. 그렇다면 각각의 테이블의 크기는 어떻게 되겠는가? 먼저, 직원 테이블을 확인해 보자. 직원 테이블의 하나의 데이터의 길이는 1055Byte의 길이이다. 또한, 직원 테이블에는 1,000,000건의 데이터가 저장되므로 해당 테이블의 전체 크기는 데이터만 1,000,000건*1055Byte=1055MB가 되므로 약 1GB 정도의 크기가 된다. 그렇다면 위의 그림에서 밑에 존재하는 사원 테이블과 부서 테이블을 분리한 경우는 어떠한가?

<그림> 조인이 필요없는 테이블과 조인이 필요한 테이블

사원 테이블은 1,000,000건의 데이터가 저장되어 있으며 하나의 데이터의 길이는 535Byte가 된다. 사원 테이블의 전체 데이터 건수는 1,000,000건이므로 1,000,000*535 Byte = 535MB가 되므로 사원 테이블의 크기는 535MB 정도가 된다. 그렇다면 부서 테이블의 크기는 어떠한가? 부서 테이블의 하나의 데이터의 길이는 525 Byte가 된다.

부서 테이블에는 1,000건의 데이터가 존재하므로 테이블의 전체 크기는 1,000*530Byte이므로 530KB의 크기가 된다. 따라서 위의 그림의 아래와 같이 부서 테이블과 사원 테이블로 구성한다면 두 테이블의 크기를 모두 합해도 535MB 정도의 크기가 될 것이다.

그렇다면 위의 테이블 크기 및 구조를 통해 우리는 무엇을 알 수 있겠는가? 우리가 유추해 낼 수 있는 항목은 크게 두 가지이다.

첫 번째로 두 가지 경우에 대해 모든 데이터를 추출하기 위해 액세스해야 하는 데이터의 양이다. 위의 그림에서 직원 테이블로만 구성되어 있는 경우를 확인해 보자. 직원 테이블의 데이터를 모두 추출하고자 한다면 직원 테이블의 크기만큼 디스크 I/O가 발생하게 된다. 따라서, 직원 테이블의 크기인 1055MB만큼의 디스크 I/O가 발생하게 된다.

반면에 위의 그림에서 사원 테이블과 부서 테이블을 분리한 경우는 어떠한가? 사원 테이블과 부서 테이블을 액세스하여 모든 데이터를 추출해야 한다면 각각의 테이블을 모두 액세스해야 할 것이다. 그렇기 때문에 위에서 계산한 것과 같이 535MB의 디스크 I/O가 발생하게 된다.

이와 같다면 과연 어떻게 테이블을 구성해야 하겠는가? 물론, 위의 그림에서 테이블을 어떻게 구성하는가에 상관 없이 결과는 동일한 데이터가 추출될 것이다. 직원 테이블로만 구성한 경우에는 1055MB의 디스크 I/O를 발생시키게 되며 사원 테이블과 부서 테이블로 분리하여 모든 데이터를 액세스한다면 535MB의 디스크 I/O를 발생시키게 된다.

디스크 I/O를 통해 확인한다면 직원 테이블로 구성하는 것보다는 사원 테이블과 부서 테이블로 분리하는 형태를 선택해야 할 것이다. 사원 테이블과 부서 테이블로 분리하는 형태를 선택한다면 우리는 더 적은 디스크 I/O를 통해 원하는 모든 데이터를 추출할 수 있을 것이다.

두 번째로 원하는 데이터를 추출하기 위한 데이터의 액세스 방법을 예상할 수 있을 것이다. 직원 테이블 하나로 구성하는 경우에는 하나의 테이블만 존재하게 되므로 하나의 테이블을 통해 모든 데이터를 액세스할 수 있게 된다.

그렇기 때문에 인덱스가 존재한다면 인덱스를 이용하는 수행 방식을 이용하거나 또는 인덱스가 존재하지 않는다면 인덱스를 이용하지 않고 테이블을 처음부터 끝까지 액세스하게 될 것이다. 반면에 사원 테이블과 부서 테이블로 분리하는 경우는 두 테이블의 데이터를 동시에 추출하기 위해서는 조인을 사용해야 할 것이다.

이와 같이 테이블을 분리한다면 전체 데이터의 크기는 감소한다. 데이터의 감소는 우리에게 많은 혜택을 주게 된다. 이러한 데이터의 감소를 위해서는 테이블을 분리해야 하며 분리된 테이블에서 원하는 데이터를 추출하기 위해서는 조인을 이용해야 한다. 이처럼 대용량 데이터베이스의 데이터를 감소시키기 위해서는 조인은 필수 불가결할 것이다.

조인을 수행하기 위한 경우의 수를 이해하자

조인을 수행하기 위해서는 다양한 경우의 수가 존재한다고 것을 이해하겠는가? 그렇다면 과연 조인 방식에는 어느 정도 다양한 경우의 수가 존재하는 것일까? 그 중 어떤 조인 방식이 최적의 성능을 보장하겠는가? 이제부터 조인을 수행하기 위한 경우의 수에 대해 확인해 보자.

SQL> SELECT COL1, COL2, COL3
FROM TAB1, TAB2, TAB3
WHERE TAB1.KEY1 = TAB2.KEY2
AND TAB2.KEY2 = TAB3.KEY3;

위와 같은 기본적인 조인 SQL을 수행한다고 가정하자. SQL은 데이터베이스에 존재하는 테이블의 데이터를 액세스하는 언어이다. 그렇다면 위의 조인 SQL이 수행될 수 있는 경우의 수에는 어떤 경우가 존재하는가? 여기서 말하는 경우의 수는 조인이 수행되는 방법을 의미한다. 조인이 수행될 수 있는 경우의 수는 아래와 같은 두 가지 요소에 의해 다양하게 발생할 수 있다.

·테이블의 조인 순서-먼저 액세스되는 테이블과 뒤에 액세스되는 테이블

·조인 방식-중첩 루프 조인, 해쉬 조인, 소트 먼지 조인

첫 번째로 위의 요소 중 테이블의 조인 순서를 확인해 보자. 조인은 두 개 이상의 테이블에서 필요한 데이터를 추출하게 되므로 먼저 액세스하는 테이블과 뒤에 액세스하는 테이블이 존재하게 된다. 그렇기 때문에 세 개의 테이블에 대해 조인을 수행하게 된다면 조인 순서는 3*2*1=6의 경우의 수가 존재하게 된다.

예를 들어, TAB1 테이블이 먼저 액세스되고 뒤에 TAB2 테이블이 액세스되며 마지막에 TAB3 테이블이 액세스되는 조인 순서도 이 경우의 수에 포함이 될 것이다. 결국, 테이블 조인 순서에 의해 발생할 수 있는 경우의 수는 6개가 된다.

두 번째로 조인 방식에 의한 경우의 수를 확인해 보자. 조인 방식은 조인을 수행하는 내부 수행 방법을 의미한다. 앞서 언급했듯이 조인은 세 가지 방식이 존재하게 된다. 따라서, 조인 방식은 세 가지의 경우의 수가 존재할 것이다.

이와 같다면 해당 조인 SQL에서 최종적으로 발생하는 경우의 수는 어떻게 되겠는가? 두 가지 경우의 수의 곱이 전체 경우의 수가 될 것이다. 그렇기 때문에 전체 경우의 수는 6*3=18가지의 경우의 수가 존재하게 된다.

예를 들어, TAB1 테이블, TAB2 테이블 및 TAB3 테이블 순으로 조인이 수행되며 TAB1 테이블과 TAB2 테이블은 해쉬 조인을 사용하고 그 결과 값과 TAB3 테이블은 중첩 루프 조인을 수행하는 경우도 18가지의 경우의 수에 포함될 것이다.

이와 같이 하나의 조인 SQL은 우리가 생각지도 않은 다양한 경우의 수가 존재하며 해당 조인 SQL이 수행될 경우에는 18가지 경우의 수 중 하나의 방법을 선택하여 조인 SQL을 수행하게 된다.

그렇다면 조인 SQL의 수행을 위한 경우의 수와 성능은 어떤 관계를 가지게 되는가? 이는 성능과 매우 밀접한 관계를 가지게 된다. 위의 예제에서 18가지의 경우의 수중 최적의 성능을 보장하는 경우는 몇 가지 안 된다. 나머지 경우의 수는 성능을 저하시키는 경우에 해당된다. 이제부터 우리는 이러한 조인의 경우의 수를 고려하여 조인 SQL을 작성해야만 성능을 보장 받을 수 있을 것이다.

조인의 성능은 다양하다

전체 데이터를 액세스하는 경우에는 하나의 테이블을 액세스하는 경우보다는 분리된 테이블의 데이터를 액세스하는 경우에 디스크 I/O가 감소했다. 디스크 I/O만 고려한다면 성능과 관련된 모든 항목은 고려된 것인가? 그것만은 아닐 것이다. 그렇다면 성능 관련해서 과연 무엇을 고려해야 하는가?

그것은 분리된 테이블에서 원하는 데이터를 추출하기 위해 사용하는 조인의 수행 방식이다. 하나의 테이블을 액세스한다면 인덱스를 이용한 테이블 액세스 방식 또는 테이블을 처음부터 마지막까지 액세스하는 테이블 전체 스캔 방식이 존재하게 된다. 이와 같이 하나의 테이블을 액세스한다면 매우 단순한 액세스가 발생하게 된다.

하지만, 조인을 이용한다면 이와 같이 단순한 방식으로만 수행되는 것은 아니다. 조인을 수행하기 위한 조인 방식이 존재하며 이와 같은 조인 방식을 이용하여 조인을 수행하게 된다.그렇다면 조인 방식에는 어떠한 것이 존재하는가?

·중첩 루프 조인(NESTED LOOP JOIN)

·해쉬 조인(HASH JOIN)

·소트 머지 조인(SORT MERGE JOIN)

위와 같은 조인 방식이 존재한다는 것은 무엇을 의미하는가? 하나의 조인은 위의 방법 중 하나의 조인 방식을 이용할 수도 있으며 경우에 따라서는 위의 조인 방식 중 하나의 조인 방식이 아닌 두 개 이상의 조인 방식을 이용할 수도 있다.

이는 무엇을 의미하는가? 경우의 수가 많다는 것은 다양한 처리 방법이 존재하는 것이며 이와 같이 모든 경우의 조인 방법이 동일한 성능을 보장할 수는 없을 것이다. 그렇기 때문에 어떻게 수행되는가에 따라 성능을 보장할 수도 있고 성능을 저하시킬 수도 있을 것이다.

결국, 하나의 테이블을 액세스하는 경우에는 SQL의 실행 계획이 매우 단순하기 때문에 거의 예외가 없지만 두 개 이상의 테이블에서 데이터를 추출하는 조인의 경우에는 위와 같이 많은 경우의 수가 존재하게 된다.

이와 같이 존재하는 많은 경우의 수에는 하나의 테이블로 구성하여 데이터를 액세스하는 경우보다 성능이 저하되는 경우도 존재하며 또는 하나의 테이블로 구성하여 데이터를 액세스하는 경우보다 성능이 더 좋아지는 경우도 존재하게 된다. 일반적으로 많은 경우의 수는 하나의 테이블로 구성하여 데이터를 액세스하는 경우보다 성능이 저하된다.

문제는 여기에 존재하게 된다. 조인을 수행하는 많은 경우의 수가 단일 테이블을 액세스하는 경우보다 성능이 저하될 수 있으며 이와 같은 경우 중 하나의 수행 방식이 선택된다면 우리는 조인이 항상 성능을 저하시킨다는 고정관념에 빠지게 된다. 그렇게 된다면 이와 같은 성능 저하를 경험한 사람은 다시는 조인을 사용하지 않고 단일 테이블로 구성하여 조인을 사용하지 않으려 할 것이다.

이와 같다면 데이터는 자연스럽게 증가하게 된다. 과연, 이것이 올바른 방법인가? 조인을 사용하는 경우에 다양한 수행 방식 중 가장 최적의 조인 방식을 선택한다면 어떻게 되겠는가? 이와 같다면 단일 테이블을 액세스하는 경우보다 조인을 이용하는 경우가 더 좋은 성능을 보장할 수 있을 것이다. 여기서 우리는 결론을 내릴 수 있을 것이다.

테이블을 분리함으로써 우리는 조인을 사용해야 하며 조인을 수행하기 위한 방식에는 다양한 경우의 수가 존재하게 된다. 다양한 경우의 수 중 우리는 최적의 조인 방식을 찾아야만 한다는 것이다. 이 것이 조인을 효과적으로 사용하면서 데이터를 감소시킬 수 있는 유일한 방법이 될 것이다.

조인은 다양하게 표현된다

앞에서 언급한 SQL의 경우는 누가 보더라도 조인이라는 것을 이해할 것이다. 과연, 분리된 테이블에서 원하는 데이터를 추출하는 방법에는 위와 같이 FROM 절에 필요한 테이블을 나열하는 방법밖에는 존재하지 않는 것일까? 이와 같은 방법 외에도 여러 가지 방법으로 분리된 테이블의 데이터를 연결할 수 있다.

·스칼라 서브쿼리-SELECT 절에 SELECT 절을 사용하는 데이터 연결

·서브쿼리-WHERE 절에 SELECT 절을 사용하는 데이터 연결

위와 같은 종류가 중요한 것은 아니다. 이와 같은 종류도 모두 조인에 해당하기 때문에 두 개 이상의 테이블에서 필요한 데이터를 추출하게 되며 그렇기 때문에 먼저 액세스되는 테이블과 뒤에 액세스되는 테이블이 존재하게 된다.

물론, 조인 방식도 앞서 언급한 세 가지 방식 중 하나를 이용하게 된다. 이와 같기 때문에 데이터 연결을 수행하는 대부분의 방식은 다양한 경우의 수가 존재하며 이 중 성능을 보장하는 경우는 몇 가지 존재하지 않게 된다.

결국, 테이블 분리에 의한 데이터의 연결을 수행하는 방식은 다양한 형태로 존재한다. 하지만, 대부분의 데이터 연결 방식이 다양하게 수행된다. 여기서 중요한 것은 다양한 경우의 수에서 성능을 보장하는 경우의 수는 많지 않다는 것이다. 그렇기 때문에 우리의 역할은 다양한 경우의 수에서 최적의 경우의 수를 찾아야 한다는 것이다. 이와 같이 최적의 경우의 수를 찾지 못한다면 우리는 평생 조인을 사용하지 말고 단일 테이블로 구성하여 단순 액세스를 수행해야 한다고 주장하게 될 것이다.

하지만, 최적의 성능을 보장하는 경우의 수를 찾아냈다면 드디어 조인의 혜택을 제대로 누릴 수 있게 되는 것이다. 조인은 절대 성능 저하의 아키텍처를 가지고 있지 않다. 단지, 우리가 모르고 사용하기 때문에 성능 저하를 발생시킨다고 생각하게 되는 것은 아닌가 생각한다.

제공 : DB포탈사이트 DBguide.net

설명
원형모델의 주목적은 원형을 가능한 빨리 개발한 후 고객과 검증하는 것이다. 고객으로부터 피듭백을 받은 후에는 원형을 폐기하는 경우도 있고 중요 부분만 구현하여 피드백을 얻은 후 지속적으로 발전시켜 완제품을 만들어 낼 수도 있다.

• 프로토 타입 모형은 사용자의 요구사항을 정확하게 파악하기 위해서 미리 실제로 개발할 소프트웨어의 시제품을 만들어서 최종 결과물을 예측하는 모형이다.
• 시스템의 모형을 만드는 과정으로 초기 요구사항에 대한 소프트웨어를을 구현하는데 이는 추후 구현단계에서 사용될 골격이 된다.
• 성능, 보안, 신뢰도와 같은 소프틍웨어의 특성을 무시한다.
• 변경이 체계적으로 이루어지지 않기 때문에 유지보수가 힘들다.
• 폭포수 모델에서 발견되는 개발이 완료된 시점에서 오류가 발견되거나 요구사항과 맞지 않는 단점을 해결하기 위한 모형이다.

개발 순서

Define objectives
프로토타입을 정의해야할 부분을 고객과 상의하여 진행. 이부분을 잘해야 어떻게 프로토타입의 구조를 결정할지 정의할 수 있다.

Specify
순차적 디자인 원칙에 의거하여  모델을 정의하고 수정한다. 사용자 인터페이스에 초점을 맞춘다.

Construct
프로토타입으로 정해진 모델을 빠르게 개발한다. 고객이 요구하는 기능을 구현하고 필요한 요소를 파악하는데 중점을 둔다. 중요한 것은 프로그램의 신뢰도나 품질이 아니라 빨리 만드는 것이다.

Evaluate
가장 중요한 단계로 프로토타입을 고객과 같이 평가하고 고객이 원하는 요구사항과 맞는지 확인한 후 다시 정의 단계로 넘어간다.

장점

• 요구사항을 충실히 반영하며, 요구사항의 변경이 용이하다.
• 사용자 요구사항이 불명확할 때 사용하는 것이 좋다
• 제품의 추적성과 시험가능성이 확보된다.
• 최종 결과물이 만들어지기 전에 의뢰자가 최종 결과물의 일부 또는 모형을 볼 수 있다.
• 시스템의 이해와 품질향상에 도움이 된다.
• 고객과 개발자 모두에게 공동의 참조 모델을 제공한다.

단점

• 프로토 타입의 결과를 최종 결과물이라고 고객에게 혼란을 줄 수 있다.
• 단기간에 제작해야 하기 대문에 비효율적인 언어나 알고리즘을 사용할 수 있다.
• 소프트웨어 개발에 많은 시간이 소요되며 산출물이 많아진다.
• 중간과정을 점검할 수 있는 일정표와 산춤물이 없기 때문에 관리 통제가 어렵다.
• 실제 프로토타입을 검수하고 확인할 고객이 그리 많지 않다. (자기 업무도 많은데 어떻게 신경쓰냐..)

설명

폭포수 모형은 소프트웨어 개발에서 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하며 이전 단계로 넘어갈 수 없는 방식이다.

• 폭포수 모형은 소프트웨어 공학에서 가장 오래되고 가장 폭넓게 사용하며 고전적 생명 주기 모형이라고도 한다.
• 소프트웨어 개발 과정의 앞 단계가 끝나야만 다음단계로 넘어갈 수 있는 선형 순차적 모형이다
• 각 단계별로 산출물이 나오며 단계별 평가서가 존재한다.
• 두개 이상의 과정이 병행하여 수행되지 않는다

개발 순서

System engineering
높은 수준의 구조 명세서를 작성한다. 모델에 사용할 각종 문서를 정의한다.

Requirements Analysis
요구사항을 수집하고 문제를 이해, 분석하는 단계이다. 분석가는 고객의 요구사항을 기능, 성능, 인터페이스 등으로 파악하고 문서화 한다. 이 단계에서 산출물은 요구사항 명세서, 기능 명세서, 인수 테스트 명세서등이 있다.

Disign
소프트웨어 아키텍처 명세서, 시스템 테스트 명세서, 디자인 명세서, 서브시스템 테스트 명세서, 단위 테스트 명세서등 모든 시스템 구조를 결정하게 된다.

Construction
설계명세서를 토대로 실제 프로그래밍을 하게 된다.

Testing
단위 테스트 레포트, 서브 시스템 테스트 레포트, 시스템 테스트 레포트, 인수테스트 레포트등의 산출물이 나오며 프로그램이 입력에 따라 제대로 작동하는지 여부와 오류를 발견하기 위해 수행된다.

Installation
시스템에 인스톨해야할 소프트웨어라면 인스톨 작업을 하게 된다.

Maintenance
요구사항 정의 변경에 따른 유지보수 및 산출물 변경을 하게 된다. 유지보수를 하게 되는 이유는 여러가지 인데 고객이 성능향상이나 기능 추가를 요구할 경우, 새로운 운영체제나 주변장치등이 바뀌는 경우, 테스팅 단계에서 미리 체크하지 못한 오류등을 수정할 경우가 있다. 실제 프로젝트 예산의 70%가 유지보수단계에 쓰일 정도로 시스템이 제대로 구축이 안되어있다면 엄청난 예산을 잡아먹는다.

장점

• 모형의 적용 경험과 성공사례가 많다.
• 단계별 정의가 분명하고, 각 단계별 평가가 확실하게 이루어진다.
• 각 프로세스 단계의 역할 이해가 용이하다.
• 단계별 산출물이 정확하여 개발공정의 기준점을 잘 제시한다.
• 프로젝트의 관리가 용이하다.

단점

• 프로젝트 초기, 요구사항을 정의할 때 정확한 요구사항을 제시하지 않을 경우 프로세스의 각 단계가 진행될 수록 요구사항의 변경, 추가가 매우 어렵다. (고객의 feedback 반영이 어려움)
• 각 단계별로 다음 단계로 진행될 때 오류 없이 진행되어야 하지만 현실적으로 오류없이 다음단계로 진행되기 어렵다.
• 만약 계획대로 진행되지 않을 경우 납기일 전 철야, 납기일 지연, 지연에 따른 비난과 스트레스가 개발자에게 향하여 에너지 소진, 고객의 요구를 충족하지 못하는 등의 부작용이 발생한다.
• 고객은 개발된 제품이 자신이 원하는 것인지 알기 위해서 프로젝트 후반까지 기다려야만 한다.
• 만약 고객이 요구한 시스템이 아니면 최악의 경우 프로젝트가 실패하게 될 수도 있다.
  

지난 몇 년 동안 XML은 데이터 전송을 위한 새로운 표준으로 각광 받아 왔으며, 기업의 XML 기반 솔루션 도입 사례가 증가하면서 그 영향력 또한 증가하고 있습니다. 전체 데이터 전송 작업에 XML 표준을 적용하는 기업의 사례가 늘고 있으며, 이로 인해 사용되는 XML 포맷 또한 복잡해지고 있습니다. 이 과정에서 XML 포맷 내에 여러 개의 네임스페이스, 수천 개의 엘리먼트, 재귀적 정의 등이 사용되기도 합니다. 이러한 포맷을 통해 생성된 XML 문서의 규모와 복잡성 역시 증가하고 있으며, 따라서 컨텐트의 관리가 한층 까다로운 과제로 부각되고 있습니다. 하지만 이러한 문제를 해결하는데 도움이 될만한 정보는 부족한 것이 현실입니다.

본 문서에서는 Oracle Database 11g에 포함된 XML DB 기능을 이용하여 복잡한 XML 컨텐트를 관리하는 방법, 그리고 Oracle XML DB가 다른 상용 ETL 제품과 비교했을 때 제공하는 이점에 대해 설명하고 있습니다. 본 문서에서 설명되는 XML 스키마 예제는 아래와 같은 내용을 포함하고 있습니다:

 •  복잡한 XML 스키마의 등록
 •  데이터베이스에 XML 파일을 삽입
 •  관계형 쿼리를 통해 XML 데이터를 조회
 •  XML 스키마 수정을 위한 In-Place Evolution 활용

그 밖에도, Oracle XML DB 솔루션의 성능과 처리 속도를 극대화하기 위한 전략과 복잡한 XML 포맷의 실제 활용 방안 등에 대한 설명이 제공됩니다.

Oracle XML DB 배경 정보

구조형 스토리지를 이용한 처리 속도의 극대화

Oracle XML DB와 상용 패키지 제품의 비교

복잡한 XML 컨텐트의 처리 문제

Oracle XML DB 솔루션

XML 스키마 변경 내역의 관리

실제 적용

제공 : DB포탈사이트 DBguide.net

파티션 테이블의 사용이 많아지면서 파티션 테이블의 인덱스에 관심이 높아지는 것은 당연한 일일 것이다. 테이블만 파티션 테이블로 생성한다면 이는 생각만큼의 효용가치는 없게 된다. 테이블을 생성하면서 해당 테이블에 인덱스가 존재하지 않는 경우는 그렇게 많지 않을 것이다. 대부분 테이블에 인덱스를 하나 이상 생성하여 조회 속도의 향상을 기대할 것이다. 이런 이유에서 파티션 테이블에서 파티션 인덱스의 생성은 매우 중요한 역할을 수행하게 된다. 지난 호에서는 로컬 인덱스와 글로벌 인덱스에 대해 언급을 하였다. 파티션 테이블의 인덱스는 로컬 인덱스와 글로벌 인덱스만이 존재하는 것은 아니다. 로컬 인덱스와 글로벌 인덱스가 가용성 등의 관리의 목적이었다면 PREFIX 인덱스와 NONPREFIX 인덱스는 성능 관점에서의 파티션 인덱스의 종류이다.

PREFIX 인덱스와 NONPREFIX 인덱스를 생성하자

PREFIX 인덱스 또는 NONPREFIX 인덱스 또한 로컬 인덱스 또는 글로벌 인덱스와 마찬가지로 가장 기본적인 사항이 인덱스의 생성일 것이다. 가장 먼저 PREFIX 인덱스와 NONPREFIX 인덱스를 생성하는 방법을 확인해 보자.

===============================
CREATE TABLE TEST
(YYYYMMDD VARCHAR2(6) NOT NULL.
ID CHAR(12) NOT NULL,
PHONE_NUMBER CHAR(11))
PARTITION BY RANGE(YYYYMM)
(PARTITION PART_200801 VALUES LESS THAN (‘200802’),
PARTITION PART_200802 VALUES LESS THAN (‘200803’));
CREATE INDEX TEST_IDX ON TEST(YYYYMM, ID)
LOCAL
(PARTITION PK_200801 VALUES LESS THAN (‘200802’),
PARTITION PK_200802 VALUES LESS THAN (‘200803’));
===============================

와 같이 인덱스를 생성한 경우를 확인해 보자. 위의 인덱스는 PREFIX 인덱스가 된다. 물론, 해당 인덱스는 로컬 인덱스이기도 한다. 위의 SQL을 수행한다면 로컬 인덱스이면서 PREFIX 인덱스가 생성이 될 것이다. 이미 로컬 인덱스는 지난 호에서 자세히 언급하였다. 그렇다면 위의 인덱스는 어떤 이유에서 PREFIX 인덱스가 되는가? 그 이유는 간단하다. PREFIX 인덱스는 파티션 인덱스의 파티션을 구분하는 컬럼이 인덱스의 첫번째 컬럼으로 생성하는 경우이다. 위의 예제에서 인덱스는 로컬 인덱스이므로 파티션 테이블을 구성한 파티션 키 컬럼인 YYYYMM 컬럼이 인덱스의 파티션 키 컬럼이 된다. 또한, 해당 인덱스의 첫 번째 컬럼이 YYYYMM 컬럼이므로 해당 인덱스를 PREFIX 인덱스라고 부르게 된다. 따라서, PREFIX 인덱스는 아래와 같이 정의할 수 있을 것이다.

PREFIX 인덱스 - 인덱스의 파티션 키 컬럼과 인덱스를 구성하는 첫 번째 컬럼이 동일한 파티션 인덱스

그렇다면 위와 같이 PREFIX 인덱스가 아닌 경우를 우리는 NONPREFIX 인덱스라고 부르게 될 것이다. 아래에서 NONPREFIX 인덱스를 생성하는 SQL을 확인해 보자.

===============================
CREATE INDEX TEST_IDX ON TEST( ID)
LOCAL
(PARTITION PK_200801 VALUES LESS THAN (‘200802’),
PARTITION PK_200802 VALUES LESS THAN (‘200803’));
===============================

위와 같이 파티션 인덱스를 생성한다면 어떻게 되겠는가? 파티션 테이블은 앞서 예제와 동일한 테이블이라고 가정하자. 해당 인덱스는 로컬 인덱스이기 때문에 인덱스는 YYYY MM 컬럼으로 분리되어 있을 것이다. 인덱스 컬럼은 ID 컬럼으로 구성되므로 인덱스의 파티션 키 컬럼과 인덱스를 구성하는 첫 번째 컬럼이 다르게 된다. 이와 같은 구조로 인덱스가 생성된다면 해당 인덱스를 NONPREFIX 인덱스라고 한다.

NONPREFIX 인덱스 - 인덱스의 파티션 키 컬럼과 인덱스를 구성하는 첫 번째 컬럼이 동일하지 않은 파티션 인덱스

결국, 위와 같은 형태의 인덱스를 NONPREFIX 인덱스라고 하게 된다. 그렇다면 이와 같은 PREFIX 인덱스와 NONPREFIX 인덱스의 차이는 무엇인가? 보기에는 단지 인덱스를 구성하는 컬럼의 위치에 따라 인덱스의 종류가 결정되는 형태이다. 이제부터 PREFIX 인덱스와 NONPREFIX 인덱스의 차이를 확인해 보자.

PREFIX 인덱스는 성능을 위한 보호 장치를 가지고 있다

PREFIX 인덱스가 성능에 대해 보호 장치를 가지고 있다는 것은 무엇을 의미하는가? 그렇다면 NONPREFIX 인덱스는 성능을 위한 보호 장치를 가지고 있지 않은 것인가? NONPREFIX 인덱스는 성능에 대해 보호 장치를 가지고 있지 않게 된다. 그렇다고 NONPREFIX 인덱스가 반드시 성능 문제를 발생시킨다는 의미는 아니다.
앞서 언급한 예제에서 PREFIX 인덱스의 경우를 확인해 보자. 해당 인덱스를 이용하기 위해서는 아래와 같은 SQL이 수행되어야 할 것이다.

===============================
SELECT * FORM TEST
WHERE YYYYMM = ‘200708’
AND ID = ‘200’;
===============================

위와 같이 SQL을 수행한다면 해당 SQL은 테이블이 YYYYMM 컬럼으로 분리되어 있기 때문에 YYYYMM 컬럼의 값이 ‘200708’인 데이터만 저장되어 있는 파티션만을 엑세스하면 원하는 데이터를 모두 추출할 수 있게 된다. WHERE 조건에서 ID 컬럼이 생략되더라도 YYYYMM 컬럼의 값이 ‘200708’인 데이터가 저장되어 있는 파티션만을 엑세스하게 될 것이다.
이처럼 PREFIX 인덱스의 첫 번째 컬럼에 대해 WHERE 조건에서 동일 조건(=)로 조회를 수행한다면 하나의 파티션만 엑세스하여 원하는 결과를 모두 추출할 수 있게 되므로 테이블을 전체 엑세스하는 최악의 경우를 방지할 수 있을 것이다. 이와 같기 때문에 PREFIX 인덱스는 성능을 위한 보호 장치를 가지고 있다고 하게 된다.
하지만, NONPREFIX 인덱스를 이용하는 SQL의 경우에는 이와 같이 하나의 테이블 파티션만을 엑세스하여 원하는 데이터를 모두 추출할 수는 없게 된다. 이 뜻은 NOPREFIX 인덱스를 이용하는 SQL은 전체 인덱스 파티션을 엑세스하여야만 원하는 데이터를 모두 추출할 수 있다는 의미가 된다. 이에 대한 자세한 내용은 다음 호에서 언급하도록 하겠다.

제공 : DB포탈사이트 DBguide.net

이번에 디지털 영상 컨텐츠라는 수업을 듣는데 중간고사로 30초짜리 동영상을 만드는 것이 있어서
해봤다.

기말고사에도 동영상 제작 후 제출 하는 것이라 그냥 기말고사 때 만들 동영상의 에고편으로 만들었다.

대략 줄거리는 라이언 일병 구하기 영화에서 스쳐지나가는 전쟁신에 대한 조명 같은 것이다.

그러니까 주인공들이 잠깐 지나가는 곳을 배경으로 그 곳의 전투를 외전처럼 만들 생각이다.

뭐.. 만드는 툴은 프리미어2.0이랑 Company of hero의 시네마 모드를 이용해서 만든 것이고 사운드는 라이언 일병 구하기 영화에서 일부 가져왔다.

Company of hero의 카메라 앵글 및 조작기능이 제한적인데다가 한번 플레이하면 뒤로 돌리는 기능이 없어서 잘못 찍으면 다시 플레이를 봐야한다. 한번 플레이 시간이 1시간 정도 되니 토나온다..ㅋ

음.. 감상해봅시다~!

 

View는 사용자가 실제로 테이블을 만들고 데이터를 집어넣어서 사용하는 것이 아니라 이미 만들어진 Table에서 자신이 원하는 일부를 마치 테이블 처럼 정의 한 것이다.

뷰를 만드는 형식은 아래와 같다.

CREATE [OR REPLACE] [FORCE|NOFORCE] VIEW viewname  [(alias[, alias..)]
AS subqurey
[WITH CHECK OPTION [CONSTRAINT constraint]]
[WITH READ ONLY [CONSTRAINT constraint]];
     
각각의 옵션을 보자

OR REPLACE : 만약에 기존에 만들어 놓은 똑같은 이름의 View가 있다면 덮어 써라.
         FORCE : DB에 View로 사용할 테이블이 존재하지 않더라도 View를 만들어라.
     NOFORCE : DB에 View로 사용할 테이블이 존재하지 않으면 만들지 말아라.
WITH CHECK OPTION : View에서 insert, update 작업을 할때 사용되는 제약사항을 기술한다.
WITH READ ONLY : 이 옵션을 사용하면 View는 오직 읽기만 가능하다.      


ex) EMPLOYEE 테이블의 EMPNO와 NAME을 VIEW로 만들고 싶은 경우
    1. 기본 문법
      CREATE VEIW EMPLOYEE_VIEW AS
      SELECT EMPNO, NAME
         FROM EMPLOYEE;

사용방법은 SELECT 문과 같다.
 
     SELECT *
        FROM EMPLOYEE_VIEW;

  2. 옵션을 사용한 문법
      CREATE OR REPLACE VIEW EMPLOYEE_VIEW AS
      SELECT EMPNO, NAME
         FROM EMPLOYEE
           WITH READ ONLY;

이 문제는 윈도우용 오라클 사용자들에게 일어나는 문제다.

Oracle10g를 예로 들어서 설명하겠다.

EM으로 들어가서 어떠한 설정을 할 경우 저장을 하기 위해 시스템을 shutdown하거나 restart해야한다. 이때 EM에서 아래와 같은 화면을 만나게 된다.

1. C:\WINDOWS\system32\drivers\etc\hosts 파일을 notepad로 open한다.

맨 아래 보면 이런 형식이 있다.

   (형식) 
   자신의 DB서버IP주소  HOSTNAME

여기다가 자기 컴퓨터의 IP와 컴퓨터 이름을 입력한다.
컴퓨터 이름은 "내 컴퓨터->마우스오른쪽->속성->컴퓨터 이름"에서 확인할 수 있다.

(내 컴퓨터 이름이 havana 라면..)
   (예) 
   172.16.5.205    havana   <--추가  (자신의 컴퓨터가 유동IP라면 IP대신 localhost라고 쓰자)

2. 시작-->실행-->regedit 엔터

[내컴퓨터]-> [HKEY_LOCAL_MACHINE]->[SOFTWARE]->[ORACLE]-> [KEY_OraDB10g_home1]

오른쪽 창에서 마우스 오른클릭 후, [새로만들기]-> [문자열값] TNS_ADMIN 입력 후, [엔터]-> 생성된 TNS_ADMIN 항목을 더블클릭

--> 나타나는 박스의 값에  C:\oracle\product\10.2.0\db_1\NETWORK\ADMIN 입력 후, 엔터
(여기에 입력하는 값은 자기가 인스톨한 오라클의 경로로 해야 한다.)
                     
3. OS 로그인계정(administrator) 비번 설정

제어판->사용자계정에 들어가서 자신의 계정에 비밀번호를 넣어준다.

4. 권한 부여

[제어판]--> [관리도구] --> [로컬보안정책] 실행

왼쪽 창에서 [로컬정책] 더블클릭 --> [사용자 권한할당] 선택
오른쪽 창에서 [일괄 작업으로 로그온] 더블클릭 후 실행되는 등록정보 창에서 다음 수행

 [사용자 또는 그룹추가] 버튼 클릭 --> [고급] --> [지금찿기]--> [administrator] 선택 --> [확인]
 --> [고급] --> [지금찿기] -->[SYSTEM] 선택 --> [확인]--> [확인] --> [확인]

5. db console 재기동

cmd 창 실행

c:\>set ORACLE_SID=oracle ('oracle'은 자신의 오라클 SID임 **10g default는 orcl임**)

C:\>emctl stop dbconsole

C:\>emctl start dbconsole

이렇게하면 문제가 해결된다.

참고로 유닉스 계열의 OS에서는 일어나지 않는다.