2단계 논리적 데이터 모델은 트랜잭션이 슈퍼 타입이 되고 나머지 엔티티 타입들이 서브 타입이 되는 슈퍼 타입/서브 타입 데이터 모델로 표현할 수 있다. 다만 대출 내역 상세는 서브 타입이라기보다는 대출 내역의 내용으로, 대출 내역과 1:1 관계로 표시하면 <그림 2>와 같은 모델로 나타난다. 참고적으로 트랜잭션은 엔티티 타입의 업무 단위가 실행되면서 발생되는 모든 데이터의 정보를 담는다.
논리 모델인 슈퍼 타입/서브 타입의 특징은 슈퍼 타입에는 공통적인 속성이 존재하고 각각의 서브 타입에는 서로 다른 유형의 속성이 존재해야 되는데 대출 내역, 채무보증 내역, 금융 내역의 엔티티 타입은 서브 타입의 속성이 모두 거래 총 건수, 변경일자로 동일한 유형을 가지고 있어 서브 타입으로 적절하지 않다. 또한 대출 내역의 상세 엔티티 타입은 업무 흐름상 트랜잭션과 직접 1:1 관계가 있어도 되지만 대출 내역과 연결되는 것이 더 적절한 관계가 될 것이다. 트랜잭션에 추가한 트랜잭션 유형 코드는 하위에 있는 각각의 서브 타입을 구분할 수 있는 구분자 속성이다. 슈퍼 타입/서브 타입 모델링을 할 때 절대적으로 필요한 속성이니 반드시 기억하기 바란다. 이와 같은 내용을 반영하여 정제된 슈퍼 타입/서브 타입 모델을 만들면 <그림 3>과 같이 나타난다.

<그림3> 정제된 슈퍼 타입/서브 타입 모델로 표현


이때 슈퍼 타입인 트랜잭션 엔티티 타입에 거래 유형 코드의 값은 01:불량 내역, 02:대출 내역, 03:채무 보증 내역 04:금융 내역 서브 타입을 구분할 수 있는 형식으로 들어간다. 불량 내역은 워낙 다른 서브 타입과 속성의 차이가 많이 나므로 서브 타입으로 남아있고 대출 내역도 1:1 관계의 대출 내역 상세에 한 개의 속성만이 다른 서브 타입과 차이가 있어 서브 타입으로 남아있는 반면 채무 보증 내역과 금융 내역 서브 타입은 자신만의 속성이 없으므로 슈퍼 타입으로 통합됐다.

이전에 복잡했던 데이터 모델이 아주 간단해졌다. 그리고 슈퍼 타입과 서브 타입 모델을 통해 데이터 모델만 봐도 ‘아 이 업무는 트랜잭션이 유형에 따라서 불량 내역도 있고 대출, 채무보증 등이 있구나!’라고 알 수 있다. 업무 구성과 흐름이 명확해지는 논리 모델의 특징이다. 이제 마지막 3단계로 슈퍼 타입과 서브 타입 모델을 물리 모델로 전환해 보자. 슈퍼 타입/서브 타입 논리 모델은 개별 테이블로 변환, 슈퍼+서브 테이블로 변환, 하나의 테이블로 변환 등 세가지 물리 모델로 전환할 수 있다. <그림 4>는 세가지 형식으로 전환할 수 있는 방법을 나타낸다.

<그림4> 슈퍼 타입/서브 타입 모델 물리 모델 전환 방법 세가지


이와 같이 슈퍼 타입/서브 타입 모델을 세가지 형식의 물리 모델로 전환하는 기준은 트랜잭션의 성격과 양이다. 트랜잭션의 성격은 슈퍼 타입, 서브 타입에 대해 개별로 트랜잭션이 발생하는지 아니면 통합되어 발생하는지를 분석하는 것이다. 또 트랜잭션의 양을 고려한다는 것은 발생 건수가 적을 경우에는 분리하건 통합하건 크게 문제되지 않지만, 발생 건수가 많을수록 성능에 영향을 많이 미치는 점을 고려한다는 것이다. 그러므로 반드시 업무에서 트랜잭션이 발생될 때 슈퍼 타입과 서브 타입에 통합하여 발생되는지, 분리되어 발생되는지 고려해 적용해야 한다.

질문한 업무의 트랜잭션은 아주 빈번하게 발생되므로 트랜잭션의 유형이 고려돼야 하는 경우이고, 구 데이터 모델이 1:1 관계로 모델링된 것으로 보아 불량 내역, 대출 내역 등 개별적으로 트랜잭션이 많이 발생하는 것으로 보인다. 따라서 첫번째 방법인 슈퍼 타입/서브 타입 논리 모델을 개별 테이블로 변환하는 규칙을 적용하면 <그림 5>와 같은 물리적인 데이터 모델이 된다.

<그림5> 슈퍼 타입/서브 타입 모델을 1:1 관계의 물리 모델로 전환


그런데 이렇게 전환하고 보니 불량 내역에 비해 대출 내역의 속성이 너무 빈약하다. 즉 업무적인 트랜잭션이 발생될 때 대출 내역 테이블만을 읽어서 독립적으로 작업할 것 같지는 않다. 대출 내역 테이블은 트랜잭션에 테이블 반정규화를 하도록 한다. 다만 테이블 반정규화를 했기 때문에 대출 거래 총 금액이라는 속성이 반드시 데이터가 들어와야 하는 NOT NULL 속성이라고 해도 다른 서브 타입 유형에는 총 금액 속성이 없다. 그러므로 트랜잭션에 반정규화한 대출 거래 총 금액은 NOT NULL 형식의 컬럼 제약 사항을 걸 수 없다. 이와 같은 내용을 반영한 최종적인 데이터 모델은 <그림 6>과 같다.

<그림6> 반정규화를 적용한 물리 모델


아주 단순해졌지만 업무적인 흐름(논리 모델)이 모두 고려됐고 데이터베이스 성능에 대한 고려(물리 모델)도 되어 체계적이고 안정적인 데이터 모델이 됐다. 초기 모델과 변경된 모델을 비교하면 <그림 7>과 같이 나타난다.

<그림7> 이전 모델과 개선된 모델 비교


초기에 비해 많이 단순해졌다는 것을 알 수 있다. 많은 프로젝트의 데이터 모델이 앞의 경우처럼 불필요한 복잡성을 가지고 있는 경우가 있다. 참고로 데이터 모델이 단순해지면 데이터 모델에 대한 가독성(readablity)도 좋아지고 데이터베이스 성능도 향상된다.

2. 업무 흐름에 따라 발생되는 엔티티 타입을 나열하고 배치한다. ‘금융 거래를 한다’라는 업무 흐름이 있다면 거기에 따른 금융 거래 내역, 트랜잭션, 채무 보증 내역 등의 엔티티 타입과 관계, 속성이 있다. 그와 같은 엔티티 타입을 데이터 모델에 추가한다. 이때 PK와 관계 설정이 아주 중요하게 고려돼야 한다. 특히 가장 중심이 되는 핵심 엔티티 타입의 PK 선정이 제일 중요하다. 그리고 관계를 설정할 때도 무조건 주식별자 관계(부모의 PK가 자식의 PK로 오는 것)로 연결하는데 비식별자 관계(부모의 PK가 자식의 일반 속성으로 오는 것)를 적절하게 활용하면 아주 좋은 데이터 모델을 만들 수 있다.

3. 데이터 모델링의 기법에 따라 모델을 조정한다. M:N 관계를 해소하고 데이터 모델을 통합 또는 분리하는 등의 모델링을 전개한다.

4. 마지막으로 완성된 데이터 모델에 대해 엔티티 타입, 관계, 속성, 도메인을 중심으로 모델 검토를 하면 된다.

이때 코드성과 통계성을 제외한 모든 엔티티 타입은 관계가 존재하도록 모델링해야 한다. 이렇게 완성된 논리적인 데이터 모델은 다시 데이터베이스 무결성과 성능 관점에서 물리적인 데이터 모델로 전환하면 된다. 물리적인 데이터 모델의 최대 관심은 성능 향상이므로 데이터 무결성을 보장할 수 있는 방법을 보완하면서 적절하게 반정규화를 적용하고 PK 순서를 인덱스 구조에 맞게 조정하는 작업을 하면 된다.

두번째는 우편번호에 대한 소유권은 정보통신부 우정사업본부에 있다. 즉 우편번호 데이터에 대한 입력·수정·삭제에 대한 담당은 우리나라 정보통신부의 우정사업본부에서 관할하고 있다. 다시 말해 데이터에 대한 소유권이 우정사업본부에 있으므로 다른 시스템에서는 우정사업본부에서 담당하는 우편번호를 이용(읽기)만 할 수 있다.

우편번호 정보에 대해 데이터를 관리할 때 변경된 데이터만 수정하는 방법이 있고 모든 데이터를 수정하는 방법이 있다. 특정 우편번호에 대한 내용이 바뀌었을 때는 변경된 데이터에 대해서만 수정하는 것은 프로그램을 이용하여 쉽게 변경할 수 있어 효율적일 수도 있으나 우편번호가 추가되거나 변경 또는 삭제가 되었을 경우는 프로그램에 처리하는 것은 불가능하고 사람이 모두 데이터를 확인하여 처리해야 하는 단점이 있다. 반면 새롭게 전체 데이터를 수정하게 되면 데이터 모델이 다른 업무 테이블과 관계를 가질 수 없다는 단점이 있다. 그러나 우편번호 정보 관리의 특징상 데이터의 소유권이 특정 기관에 있고 또한 테이블과 관계를 가지지 않고 참조 형식의 데이터 모델이 되는 구조이므로 우편번호 정보 전체에 대해 데이터를 수정하여 적용하는 것이 가능하고 합리적인 방법이 될 수 있다.

<그림10> 우편번호 변경 내용(http://www.postman.pe.kr 참조)


또한 요즘 주소를 이용한 조회수가 증가하고 있고 향후 DW 유형으로 시스템을 만들어야 할 경우가 있으므로 우편번호 세부 정보를 이용하여 조회하는 경우가 많다. 우편번호를 관리할 때 우편번호와 시도(광역시), 시군구, 읍면동, 번지, 호의 내용을 개별 속성으로 가지고 있는 것이 정보 조회 처리에 아주 효율적인 방법이다.

두번째 질문인 우편번호 변경이 발생하면 우편번호를 이용하는 회원 정보에 대한 수정은 어떻게 하는지에 대한 답변이다. 2004년 5월 17일에 우편번호 변동 내역을 분석해 보면 139건의 변경사항이 있었는데 그 중에 12건만이 우편번호에 대한 변경사항이었고 나머지는 주소 부분에 대한 변경사항이었다. 즉 우편번호 전체 약 4만건 중 139건이 변경되어 0.3%가 변경됐고, 변경된 내용 중 91%는 주소 부분 변경이었고 9%가 우편번호에 대한 변경이었다.

우편번호 정보를 이용하는 업무 테이블에 내용을 쉽게 변경하기 위해서는 프로그램을 이용해 일괄적으로 하면 된다. 그러나 하나의 우편번호에 대해 두 개 이상의 주소가 포함되어 있으므로 사람이 확인하지 않고 프로그램에 의해 100% 변경하는 것은 정보가 잘못 변경될 가능성이 있어 아주 위험한 경우이다. 그렇다고 우편번호 정보 변경 내용을 하나의 레코드씩 업무 테이블에 반영하는 것은 너무 많은 시간이 소요된다. 그러므로 업무 테이블의 우편번호 정보 변경의 효율적인 방법은 우편번호만 변경된 경우와 주소 부분이 변경된 경우를 구분하여 일괄 변경하고 그 내용을 사용자 화면으로 확인하여 저장하는 방식이 될 수 있다.

문제는 업무 테이블의 우편번호에 대한 변경인데, 지금까지 변경 히스토리가 잘 관리되어 왔다면 모르겠지만 그렇지 않은 경우에는 작업하기가 쉽지 않을 것 같다. 우편번호 관리라는 것은 결국은 반정규화되어 여러 테이블에 분리·저장되어 있는 우편번호를 어떻게 효과적으로 관리하는 것인가의 문제인 것 같다.

우리가 데이터 모델링을 진행할 때 이력이라고 하는 기준은 업무 단위의 시작과 끝을 가지고 판단해야 한다. 인사 관리에서 사원은 입사를 하면 반드시 퇴사가 존재한다.

주문 관리에서 상품을 주문하면 배송하든지 취소하든지 업무를 종결할 것이다. 시작과 끝이 존재하는 업무에서 하나의 업무 단위가 진행되는 중에 시간에 따라 변화하는 데이터가 존재하는 경우가 있다. 이때 데이터를 단순히 수정하여 관리한다면 그 데이터는 항상 그 시점의 현재 데이터만을 유지하는 형태가 될 것이며 만약 데이터를 수정하지 않고 계속해서 입력하여 관리한다면 그 시점의 과거 데이터도 유지되면서 현재 데이터도 발생될 것이다. 정보화 시스템을 구축하면서 이력의 대상이 되는 항목은 후자, 즉 하나의 업무 단위가 동일한 관리 항목에 대해 과거 데이터도 유지되면서 현재 데이터도 관리되는 형태를 지칭한다.

이력의 종류는 이력이 발생하는 유형에 따라 세 가지로 구분될 수 있다. 첫번째로 하나의 엔티티 타입에 대한 변경이 있을 때 변경 이전과 이후의 데이터를 모두 관리하는 변경 이력, 두번째로 년월일별로 특정 시점에 발생하는 발생 이력, 그리고 세번째는 어떤 데이터가 시간에 따라 연속성을 가지고 존재하는 형태의 진행 이력이 존재한다.

일단 해당 업무에서 이력 데이터를 관리하고자 했다면 데이터 모델에서 가장 중요하게 고려해야 할 부분이 엔티티 타입에 대한 식별자의 구성과 그 엔티티 타입이 가지는 관계이다. 먼저 엔티티 타입은 변경 이력, 발생 이력, 진행 이력에 따라 세 가지 형태로 구분하여 식별하도록 한다. 세 가지 모두 업무상 꼭 필요한지, 통계 정보나 기업 의사 결정에 필요한 정보인지를 먼저 검토하고 필요한 업무에 대해서만 데이터 모델에 반영하도록 해야 한다.

그리고 엔티티 타입의 구성을 결정한다. 이력이 발생한다는 것은 동일한 엔티티 타입에 대해 시간에 따라 데이터가 발생하는 것이므로 시간을 나타내는 속성이 필요할 것이다. 이 때 엔티티 타입을 한 개로 유지할 것인지 두 개로 분리할 것인지를 결정해야 한다. 시간에 따라 속성의 일부만 변하는지 아니면 모든 속성이 변하는지 파악하고, 일부 속성만 변할 경우 데이터의 중복(redundancy)을 피하기 위해 두 개의 엔티티 타입으로 분리하여 설계한다. 또한 동일 엔티티 타입의 모든 속성이 시간에 따라 같이 변한다고 할지라도 데이터를 조회하는 유형에 따라 엔티티 타입의 분리 여부를 결정해야 한다. 만약 일반적인 업무에서는 현재 유지되는 정보만을 조회하고 과거 데이터에 대해서는 가끔씩 조회한다면 대량으로 존재하는 이력 엔티티 타입을 별개로 구분하기 위해 엔티티 타입을 현재에 해당하는 엔티티 타입과 이력에 해당하는 엔티티 타입으로 분리하여 설계할 수 있다.

일반적으로 업무적인 필요에 따라 모델링을 진행한 접수 통계 테이블은 변경 이력 테이블로서 사업소마다 접수받는 물량에 대한 정보를 가지고 있는 테이블이다. 사업소마다 접수 구분 코드가 ‘01’인 접수 물량을 합한 정보를 가져와야 한다면 <그림 11>과 같이 복잡한 SQL 구문이 작성된다.

<그림11> 발생 이력/변경 이력에서 최신 여부에 컬럼이 없을 경우


SQL 구문 작성시 그룹 함수를 사용하면 그룹의 대상이 많아짐에 따라 성능이 저하되는 것은 당연한 현상이다. <그림 11>의 접수 통계 테이블에서는 사업소 코드에 따른 최근에 변경된 내용에 대해 데이터를 가져오기 위해 ‘SELECT 사업소 코드, MAX(변경일자) ~ GROUP BY 사업소 코드’의 형식으로 SQL문을 작성할 수밖에 없다. 실행 계획을 보면 인라인 뷰를 사용했으므로 VIEW라고 하는 단어가 있고 SORT(GROUP BY)가 있어 데이터를 가져오기 위해 중간 단계에서 정렬 작업이 발생되었음을 알 수 있다. 그래서 접수 통계 테이블에 최신 여부를 나타내는 기능성 컬럼을 포함하면 <그림 12>와 같이 SQL 구문이 작성될 것이다.

<그림12> 발생 이력/변경 이력에서 최신 여부를 생성한 경우


최신 여부 컬럼이 접수통계 테이블에 있으므로 데이터를 조회할 때 별도의 인라인 뷰가 작성될 필요 없이 SQL WHERE 절에 최신여부 = ‘Y’만 있으면 쉽게 데이터를 처리할 수 있고 SQL문의 처리 성능은 향상된다. 단 새로운 데이터가 입력될 때 이전 변경일자에 대한 최신 여부 값을 ‘Y’에서 ‘N’으로 바꾸어야 하는 부가적인 작업은 발생된다. 즉 입력·수정·삭제시 기능성 컬럼에 대한 추가적인 고려가 필요하다.

필자가 경험한 E 프로젝트의 경우는 응용 프로그램의 60%가 이와 같은 발생 이력을 이용하여 업무 처리를 하는 프로세스를 가지고 있었는데 개발된 SQL 구문이 모두 인라인뷰와 그룹 함수까지 사용하여 최근에 발생한 값을 가지고 처리하는 방식으로 되어 있었다. 발생 이력이 업무적으로 중요한 테이블이었기 때문에 웬만한 SQL들은 모두 발생 이력 테이블을 이용할 수밖에 없었던 것이다. 개발 도중에 테스트 데이터가 많지 않았을 때는 별로 문제가 없었지만 개발이 끝나고 어느 정도 데이터를 생성한 이후에 테스트해보니 응용 프로그램에 심각한 성능 저하 현상이 발견됐다. 테이블에 인덱스를 추가하고 SQL 구문의 변경을 아무리 해도 근본적으로 성능이 개선되지 않았다. 그래서 발생 이력 테이블에 기능성 컬럼(최신 여부 컬럼) 하나를 추가하고 데이터 입력·수정·삭제시 이 컬럼을 고려하여 처리함으로써 성능 저하 현상을 막을 수 있었다. 비록 프로젝트 막바지에 개발된 프로그램의 60%를 수정해야 했지만 막대한 공수를 투입하여 데이터 모델과 응용 프로그램을 수정해 성능 저하를 예방한 것이다.

기관 정보 테이블에 적용일자라는 기능성 컬럼이 추가됨으로써 SQL 구문도 단순해지고 이전 모델에 비해 성능도 훨씬 빨라지게 된다. 단 새로운 데이터가 입력될 때 적용 종료일자 컬럼에 업무적으로는 입력되는 데이터가 있을 수 없지만 편의상 최대 값(예를 들어 9999년 1월 1일)을 입력하여 인덱스 이용에 문제가 없도록 해야 한다. 이와 같이 이력 데이터 모델은 발생 이력, 변경 이력, 진행 이력으로 구분하여 각각에 따른 적절한 기능성 컬럼을 부여함으로써 효율적인 데이터베이스 성능을 나타내게 할 수 있음을 기억해야 한다.

또한 부하 분산이 된다는 것은 하나의 데이터베이스 서버로 처리했을 때 CPU, 메모리 같은 자원이 부족하여 성능이 저하될 수 있으므로 두 대 이상의 서버에 데이터베이스를 구현하여 트랜잭션이 각각의 서버로 분산하여 처리됨으로서 성능이 향상되도록 하는 기능이다.

<그림15> OPS와 RAC의 구성 비교


OPS나 RAC은 모두 고가용성과 부하 분산이 가능하지만 고가용성에 더 큰 목적이 있다. OPS에서 RAC으로 전환했을 때 얻을 수 있는 장점은 캐시 퓨전(Cache Fusion)과 TAF이다. RAC에서 노드간 일관성을 유지하기 위해 사용하는 캐시 퓨전은 클러스터를 구성하는 인스턴스에 있는 데이터 블럭을 고속의 InterProcess Communication (IPC) 인터커넥트를 사용해서 캐시-투-캐시(Cache-to-Cache)로 전송할 수 있도록 하는 기술이다. OPS에서는 오라클 SGA의 버퍼캐시에 있는 Dirty Block을 강제로 디스크에 기록(디스크 I/O 발생으로 성능 저하)하고 이것을 다시 읽어오는 형태로 사용했기 때문에 성능이 저하되어 나타났다. 그러나 RAC에서는 디스크에 기록하는 것과 상관없이 RAC으로 구성된 각 노드의 메모리 영역(버퍼캐시)에서 정보를 읽어 통신하게 되므로 OPS보다 빠르게 처리할 수 있다.

OPS에서 RAC으로 전환했을 때 두번째의 장점은 TAF(Transpar ent Application Failover)의 사용이다. RAC에 TAF 옵션을 이용하는 애플리케이션은 연결한 인스턴스에 장애가 발생하면 다른 RAC 노드로 장애를 복구할 수 있다. 현재는 세션 장애 복구와 SELECT 장애 복구가 지원되고 있다(INSERT, UPDATE, DELETE 지원 안됨). 세션이 연결되어 있고 수행 중에 질의는 Failover 인스턴스에서 장애 전의 상태와 마찬가지로 장애 후에도 연결하여 수행이 가능하다.

다음은 효과적인 업무 파티셔닝 방안에 대해 설명하겠다. RAC에서 업무를 파티셔닝하는 이유는 각 노드간 데이터 일관성 유지를 위해 정보를 공유함으로 인해 잠금(lock) 현상이 발생하는데 동일한 테이블에 대해 데이터의 수정이 발생하면 많은 잠금 현상을 유발한다. 따라서 잠금 현상을 최소화하기 위해 데이터의 수정은 가능하면 한쪽 노드에서 발생시키고 다른 쪽에서는 그것을 읽기로 이용하도록 배치하는 방법을 이용한다.

효과적으로 업무를 파티셔닝할 수 있는 기준은 세 가지 방법이 있다. 첫번째는 대상 업무를 구분할 수 있다면 업무 기능 분해에 의해 각 노드에 업무별로 할당하는 것이다. 예를 들어 인사급여 관리 업무가 가동되고 있다면 인사 기본사항 업무는 노드1에 두고 급여에 관련된 업무는 노드2에 위치시키는 형태이다. 웬만한 시스템은 업무 기능에 의해 노드별 배치를 할 수 있다.

두번째는 대상 업무를 구분할 수 없다면, 즉 하나의 업무 영역이 각 노드에 할당될 때는 상관 매트릭스(CRUD MATRIX)를 그려서 업무간의 밀집도를 파악하여 배치하는 것이 좋은 방법이다. 테이블과 단위 프로세스에 대한 상관 매트릭스를 작성하면 업무적으로 밀집되어 있는 프로세스와 테이블을 한 눈에 파악할 수 있다. 이에 따라 업무를 쪼개어 배치할 수 있다. 업무 단위가 크고 트랜잭션이 많은 경우 이러한 노드별 분산 방법을 하면 좋은데, 업무 단위가 큰 금융권에서 많이 이용한다.

둘째, 현재 DB 서버에서 SAM 파일 형태의 데이터를 읽어서 Pro*C로 작업을 하다보니 3~5개의 분할된 작업을 돌리면 서버 CPU 사용률이 평소보다 20~30% 정도 증가한다.

DB 서버 부하를 주지 않도록 배치 작업을 다른 서버로 옮겨서 하는 것을 검토하고 있다. 이런 경우에 DB 서버에서 배치 처리가 좋은지 DB 서버와 배치 수행 서버를 분리하는 것이 적절한지에 대해서 알고 싶다.

이와 같은 경우에 잠금 현상이 발생하지 않고 동시에 처리하기 위해서는 커밋(commit)의 주기를 단축시키고 업무간 배치 처리의 로우가 겹치지 않도록 각각 배치 작업의 정렬(sort)이 배타적으로 되도록 하면 잠금 현상을 최소화할 수 있다. 단 커밋 주기를 단축할 경우는 배치 작업 중간에 에러가 발생하여 전체 롤백이 필요한데, 재처리 로직을 가진 배치 작업이 추가로 필요하다. 많은 프로젝트에서는 이와 같은 방식으로 배치 처리를 하고 있다.

두번째 질문인 DB 서버에서 배치 처리를 하는 것이 좋은지 DB 서버와 배치 수행 서버를 분리하는 것이 적절한지에 대해 설명하겠다. 동일 서버에서 처리하는 방법과 분리하여 처리하는 방법 중 어느 것이 좋다고 단정지어 말하기는 어렵다. 다만 배치 작업의 성능만을 고려한다면 아무래도 동일 서버에서 작업하는 것이 네트워크를 이용하지 않기 때문에 성능면에서 우수하다. 그러나 해당 서버의 자원이 충분하지 않고 배치 작업 중에도 온라인 서비스를 해야 한다면 배치 작업으로 인해 서버 성능이 저하되는 단점이 있다.

데이터가 있는 서버와 로직을 처리하는 서버가 분리되어 네트워크를 이용해 작업을 처리하는 경우에는 온라인 서비스를 하는 데이터베이스 서버에 배치 작업에 의한 부하가 동일 서버에 비해 상대적으로 적어지는 장점이 있다. 반면에 네트워크를 이용하여 배치 작업이 처리되기 때문에 네트워크 환경에 따라 배치 작업의 성능이 저하될 수 있고 네트워크에 문제가 발생할 경우 배치 작업이 영향을 받는 등 안정성이 상대적으로 떨어지는 단점이 있다.

일반적으로는 배치 작업 처리는 동일 서버에서 처리하는 경우가 많다. DW 환경에서도 다른 서버에 있는 배치 작업 대상 데이터 파일을 데이터베이스 서버에 FTP와 같은 형식으로 전송하고 동일 서버에서 로직이 수행되는 배치 프로세스가 가동되는 경우가 많이 있다. 그러므로 배치 작업의 성능과 안정성을 고려하여 가급적 서버의 사양(CPU, 메모리)을 업그레이드하고 배치 작업을 동일 서버에서 처리하도록 하되 업무적으로 사용자가 집중되는 시간(Peak Time)을 피하여 작업하는 것이 좋다.
세번째 질문인 배치 처리 대상 테이블에 트리거가 걸려있는 경우 영향도와 수행 방법에 대해 알아보자. 트리거 성능에 대한 결론부터 말하면 트리거가 수행되는 시간만큼 배치 처리 시간에 영향을 미치고 테이블 각각의 로우에 로직이 수행되므로 CPU 자원 활용률이 많아진다. 따라서 배치 작업 대상 테이블에는 일반적으로 트리거를 이용하지 않도록 한다.

트리거의 목적은 데이터의 동시성을 보장한다는 데 있다. 즉 하나의 테이블에 DML(입력, 수정, 삭제) 작업이 실행되면 동일한 트랜잭션에 의해 트리거 조건에 따라 다른 테이블도 수정하거나 입력해야 하는 작업이 수행되는 경우이다. 만약 A라는 테이블에 데이터를 올바로 입력하고 커밋해도 다른 테이블로 트리거 프로세스가 수행되다가 에러가 발생하면 A에 입력한 데이터도 롤백이 되어 버린다. 데이터의 동시성을 보장하기 위한 것이다. 그러므로 업무적으로 개별 트랜잭션에 따른 동시성을 반드시 보장해야 한다면 성능 문제가 있음에도 불구하고 트리거를 이용할 수밖에 없다. 그러나 배치 작업이 완료된 후에 데이터를 동기화시켜도 무방하다면, 즉 업무적으로 문제없다면 트리거를 이용하지 않는 것이 좋다.

대량으로 데이터를 처리하는 배치 작업의 경우는 보통 배치 작업이 완료된 이후에 다시 배치 처리로 데이터를 동기화하는 경우가 많다. 대신 테이블에 동기화 대상 여부와 같은 기능성 컬럼을 가지고, 배치 작업으로 인해 수정이 발생하면 ‘Y’로 하고 이후에 동기화가 수행되면 ‘N’으로 수정하는 방법을 고려할 수 있다.

데이터 아키텍트는 실무적으로 분석/설계/구축 이행 분야 및 기업의 업무 데이터를 견실하게 세울 수 있도록 하는 일을 수행한다. 실무 전문성을 확보한 이후에는 감리, 평가, 진단, ISP, ITA, SWAT(긴급 문제 해결) 분야에서 전문 데이터 아키텍트로서 활동할 수 있다. IT 정보 시스템 분야에 있거나 앞으로 이 일을 하기를 원하는 분들은 데이터 아키텍트로서 비전을 가지기 바란다.