달력

32024  이전 다음

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31

‘6개의 열쇠’로 데이터 모델링의 고수가 되자

이춘식

 

현업에 종사하는 질문자가 제기한 6개의 주요 질문에 답하는 형식으로 30일간의 여행을 정리하고자 한다. 실전에서 발생하는 데이터 모델의 1:1 관계에 대한 처리 방법과 이력 데이터 모델, 우편번호 데이터 모델에 대한 내용과 오라클 RAC과 배치 처리에 대한 질문과 답변 내용이 포함됐다.

신행정수도 이전 문제로 사회가 온통 떠들썩하다. 수도 이전에 대해 찬성과 반대 여부를 떠나 근본적으로 서울은 조선시대 도시 구조를 이어받아 발전한 곳이다. 도보와 마차가 중심인 조선시대의 도시 설계가 되어 있던 곳에 현대 문명을 담아내고자 이리 고치고 저리 고치면서 서울은 난잡한 도시의 형태를 가지게 됐다. 인구 집중과 함께 복잡성의 증가 등 많은 문제로 인해 새로운 행정수도를 모색하다보니 이전 비용이나 지역별 이해 관계 등의 여러 가지 골칫거리가 대두되고 있다.
기업의 데이터베이스를 분석하고 설계·구축하는 것은 단순히 건물 하나를 만드는 것이 아니라 도시의 근간을 만들어내는 것과 같다. 데이터베이스를 이용하는 방법, 사용하는 양 등을 고려하여 종합적이고 안정적으로 데이터 모델링부터 데이터베이스 관리까지 돼야 한다.
이번 질문과 답변은 데이터베이스 담당자가 오라클 기반의 업무를 수행할 때 발생하는 이슈 중 데이터 모델링을 중심으로 서술되어 있다. 시간과 분량의 제약으로 많은 내용은 담지 못했지만 서상현씨가 프로젝트에서 빈번하게 나타나는 문제에 대해 적절하게 질문함으로써 이 글을 읽는 독자에게도 유익한 간접 체험이 될 것이다.

 

1:1 관계와 과도한 반정규화의 해결 방안

 

질문 1) <그림 1>과 같이 현재 고객을 기준으로 모델이 구성되어 있다. 그리고 모든 관계는 1:1로 되어 있다. 문제는 이러한 모델이 논리적 모델의 확정 없이 프로세스 관점으로 데이터의 구분에 따라 분리되어 있는 상태라는 점이다. 이러한 테이블을 통합하거나 논리적 관점에서 재구성하려면 어떤 검토 과정을 거쳐야 하는지 궁금하다.

 

<그림1> 1:1 관계의 초기 데이터 모델


일단 구 데이터 모델을 완벽하게 리모델링하려면 ‘1단계 : 업무 구성과 흐름 분석’, ‘2단계 : 구 모델을 기준으로 논리 모델 작성’, ‘3단계 : 물리 모델 작성’의 형식으로 작업하면 된다. 이때 논리 모델은 최대한 업무 구성과 흐름에 적합한 데이터 모델을 만들어야 하고, 물리 모델은 데이터베이스에 적합한 모델, 즉 데이터베이스 중심의 모델을 만들어야 한다. 논리 모델은 업무 구성과 흐름에 따라 데이터 모델이 적절하게 표기된 모습, 즉 업무 거울이라고 할 수 있다. 물리 모델은 PK 순서, 반정규화 등이 고려돼야 한다. 1단계인 업무 흐름 분석이 어느 정도 됐다고 가정하고 2단계로 구 모델을 논리적인 데이터 모델로 일단 표현한 다음 3단계인 물리 모델로 만들어 보겠다.


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)도 좋아지고 데이터베이스 성능도 향상된다.

 

질문 1-1) 책을 보면서 어렵게 여겼던 슈퍼-서브 타입간의 관계 해결 방안에 대한 내용이 이 예를 통해 많은 도움이 됐다. 정확한 업무의 흐름과 데이터를 이해하기 위해서는 논리 모델이 제대로 되어 있어야 업무가 추가·변경되더라도 쉽게 적응할 수 있을 것 같다. 그러나 현재 우리 회사 시스템의 경우 최종적인 물리 모델의 결과만 가지고 있어 이를 해소하기 위해 현행 물리 모델을 분석하여 논리 모델화하고 그 논리 모델을 이용해서 물리 모델을 재구성해야 할 것 같은데 이런 경우에는 어떤 진행 단계와 방법을 거치는지 알고 싶다.

 

좋은 질문이다. 논리 모델을 정확하게 만들기 위해서는 업무의 이해가 선행돼야 하고 업무에 따라 논리 모델을 만들어 내는 것이다. 이미 완성되어 있는 모델에서 논리 모델을 만드는 방법은 다음과 같이 적용하면 어렵지 않게 만들 수 있다. 엔티티 타입, 관계, 속성 등이 존재하기 때문에 존재하는 내용을 근간으로 다음 순서로 적용해 보자.

1. 업무의 기본이 되는 엔티티 타입의 관계, 속성을 나열한다. 기본이 되는 엔티티 타입이란 복잡한 업무의 흐름이 없이도 존재할 수 있는 엔티티 타입, 관계, 속성이다. 예를 들어 고객, 부서, 회원 등이 여기에 해당된다. PK와 FK도 기본적인 업무 구조를 바탕으로 적용한다.


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


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


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

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

 

효과적인 우편번호 관리 모델 설계하기

 

질문 2) 일반적으로 우편번호는 하나의 독립적인 엔티티 타입으로 만들어서 관리하고 있는 것 같다. 현재 우리 모델 역시 <그림 8>과 같이 독립적인 테이블로 만들어서 관리하고 있다. 실제 업무를 해보니 우편번호는 너무나 다양한 형태로 변하고 있어서 관리하기가 쉽지 않다. 그래서 현재는 수시로 전체 데이터를 받아서 지우고 입력하는 형태로 하고 있다.

<그림8> 우편번호 테이블


첫째, 우편번호의 변경에 대한 작업은 앞의 방법 외에는 없는 건지 아니면 테이블의 설계 변경을 통해 더욱 효율적인 관리 방법이 있는지 알고 싶다. 둘째, 우편번호에 대한 변경이 일어나면 우편번호를 이용한 회원 정보의 반정규화된 우편번호 속성 값에 대한 수정이 이루어져야 하는데 변경된 경우의 수가 많아서 쉽게 적용할 방법이 없는데 이를 효과적으로 할 수 있는 방법이 있는지 알고 싶다.

<그림9> 세분화해 관리하는 우편번호 주소 체계


첫번째 질문인 효율적인 우편번호 관리에 대한 답변이다. 업무 시스템에서 우편번호 관리에 대한 특징은 반정규화와 데이터 소유권의 두 가지가 있다. 우편번호에 관련된 정보는 반정규화가 기본이다. 우편번호에 대상 테이블을 공통으로 가지고 있지만 대부분 다른 업무 테이블에서는 우편번호와 주소 내용을 반정규화하여 사용하고 있는 것이 특징이다. 즉 원하는 우편번호와 주소를 복사해서 업무 테이블에 입력하는 형태이다. 이러한 특징은 공통으로 관리하는 우편번호 데이터가 변할 경우 데이터 무결성이 일치하지 않는 현상이 발생할 수 있는 구조이다.


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


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

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


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


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


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

 

질문 2-1) 현재의 우편번호 관리 체계가 단순히 우편번호/주소1/주소2로 되어 있다. 이 부분에 변경된 모델을 적용하는 이유는 하위 주소가 변경 혹은 삭제되었을 경우 수정의 용이성이나 우편번호의 분리와 통합에 따른 유연성이 확보될 것이기 때문이다. 물론 앞의 형태에서 주소 부분을 더 세분화할 수도 있을 것 같다.


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

 

맞다. 기존에 업무 테이블에 있는 우편번호 주소 정보를 세부적으로 하려면 많은 노력이 필요하다. 그래서 데이터 정련(data cleansing) 작업을 하는데 만약 할 수만 있다면 데이터 정련 작업과 함께 우편번호 주소 정보를 세분화하는 것을 권고한다.

 

데이터의 이력 관리를 위한 이력 모델 설계하기

 

질문 3) 데이터의 이력 관리를 위한 이력 모델 설계는 어떻게 해야 하는지 궁금하다.

하나의 업무 단위가 시간 흐름에 따라 발생하는 과거와 현재 데이터를 지속적으로 유지하는 관리 방법을 이력(history) 관리라고 한다. 이력 관리에 대한 내용을 ‘데이터베이스 설계와 구축’에 있는 내용을 기준으로 설명하겠다.


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


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


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


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


그리고 엔티티 타입의 구성을 결정한다. 이력이 발생한다는 것은 동일한 엔티티 타입에 대해 시간에 따라 데이터가 발생하는 것이므로 시간을 나타내는 속성이 필요할 것이다. 이 때 엔티티 타입을 한 개로 유지할 것인지 두 개로 분리할 것인지를 결정해야 한다. 시간에 따라 속성의 일부만 변하는지 아니면 모든 속성이 변하는지 파악하고, 일부 속성만 변할 경우 데이터의 중복(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%를 수정해야 했지만 막대한 공수를 투입하여 데이터 모델과 응용 프로그램을 수정해 성능 저하를 예방한 것이다.

 

진행 이력

 

진행 이력의 경우는 발생 이력과 변경 이력과 다르게 발생된 시점 이외에도 데이터 조회가 빈번하게 이루어진다. <그림 13>에 있는 기관 정보 테이블은 어떤 시점에 따라 해당 기관이 가지고 있는 기관 거래 등급을 가지고 있으면서 다른 테이블에서 기관거래 등급 정보를 참조하여 업무를 처리하는 경우이다. 2004년 7월 1일자에 해당하는 기관 코드와 기관 거래 등급을 조회하는 SQL은 다음과 같이 복잡한 SQL 구문이 작성된다.

<그림13> 진행 이력에 상태 관련 종료 값이 없는 경우


<그림14> 진행 이력에 상태 관련 종료 값이 있는 경우


<그림 13>의 기관 정보 테이블에서는 지정된 날짜인 2004년 7월 1일에 기관 코드에 따른 기관 거래 등급 데이터를 가져오기 위해 ‘SELECT 기관 코드, MAX(적용일자) ~ GROUP BY 기관 코드’의 형식으로 먼저 지정된 날과 같거나 작은 적용일자를 가져와야 한다. 그리고 다시 메인 쿼리에서 적용일자를 비교해야 데이터를 가져올 수가 있다. 실행 계획을 보면 인라인 뷰를 사용했으므로 VIEW라고 하는 단어가 있고 SORT(GROUP BY)가 있어 데이터를 가져오기 위해 중간 단계에서 정렬 작업이 발생되었음을 알 수 있다. 적용일자에 인덱스가 있어도 범위가 넓어 성능 저하가 예상된다. 그래서 기관 정보 테이블에 기간을 알 수 있도록 적용 종료일자를 나타내는 기능성 컬럼을 포함하면 <그림 13>과 같이 간단한 SQL 구문이 작성될 것이다.


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

 

OPS를 RAC으로 마이그레이션하기

 

질문 4) 현재 사용 중인 오라클8의 OPS의 결함과 성능상의 문제로 오라클9i RAC으로의 업그레이드를 고려하고 있다. RAC으로 업그레이드시 OPS와 비교했을 때 얻을 수 있는 이점과 RAC 구성을 위한 시스템적 측면은 무엇인지 그리고 효과적인 업무 파티셔닝(partitioning)을 위한 방안은 무엇인지 궁금하다.

 

먼저 OPS와 RAC을 사용하는 두 가지 이유는 첫번째가 장애 복구(fail over)이고 두번째가 부하 분산(load balancing)을 하기 위한 것이다. 장애 복구를 용이하게 한다는 것은 시스템의 고가용성(high availability)을 확보한다고 할 수 있으며 두 대 이상의 데이터베이스 서버가 정보를 공유(노드간 일관성과 데이터 무결성을 보장)하고 있다가 한 대의 서버에 장애가 발생하여 다운되었을 때 즉각적으로 다른 서버가 동일한 서비스를 할 수 있는 환경 구성이다.


또한 부하 분산이 된다는 것은 하나의 데이터베이스 서버로 처리했을 때 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)를 그려서 업무간의 밀집도를 파악하여 배치하는 것이 좋은 방법이다. 테이블과 단위 프로세스에 대한 상관 매트릭스를 작성하면 업무적으로 밀집되어 있는 프로세스와 테이블을 한 눈에 파악할 수 있다. 이에 따라 업무를 쪼개어 배치할 수 있다. 업무 단위가 크고 트랜잭션이 많은 경우 이러한 노드별 분산 방법을 하면 좋은데, 업무 단위가 큰 금융권에서 많이 이용한다.


세번째는 시스템에 대한 업무 처리 방식에 따라 구분하는 방법이다. 노드1에는 즉각적으로 응답하는 온라인 업무 처리를 하는 테이블들을 위치시키고 노드2에는 통계성이나 배치 처리가 많이 발생하는 업무 영역을 배치하는 것이다. 공장의 생산 라인에서 초당 수만 건의 데이터를 처리하고 그 데이터의 결함율을 분석하여 모니터링하는 시스템인 생산관리시스템(MES)에서 이 방법을 많이 이용한다. 부하 분산의 중요성보다는 온라인 서비스를 하는 하나의 노드에 대한 장애 대응이 주 목적인 경우이다.

질문 4-1) 업무 파티셔닝과 관련하여 상관 매트릭스 작성에 대해 좀 더 실제적인 예를 들어 설명해주기 바란다.

 

상관 매트릭스는 작은 업무 그룹인 서브젝트 에어리어 단위로도 나눌 수 있고 아주 세부적으로는 속성 단위까지도 나누어 표현할 수 있다. 가장 많이 사용하는 매트릭스는 엔티티 타입과 단위 프로세스 상관 매트릭스이다. 참고로 단위 프로세스는 논리적인 작업 처리의 단위(logical unit of work)이다. 즉 트랜잭션을 보장하기 위한 단위로서 하나의 트랜잭션의 처리는 업무적으로 의미있어야 한다.

<그림16> 단위 프로세스와 엔티티 타입의 상관 매트릭스


<그림 16>처럼 상관 매트릭스를 표현하기 위해서는 X축과 Y축을 지정한 후 X축에는 단위 프로세스를 나열하고 Y축에는 엔티티 타입을 지정한다. 그리고 각각의 단위 프로세스가 엔티티 타입에 입력이면 C(Create), 조회면 R(Read), 수정이면 U(Update), 삭제이면 D(Delete)를 입력한다. 그림의 간단한 예제에서 보면 대체로 고객과 주문에 관련된 단위 프로세스는 고객 엔티티 타입과 주문 엔티티 타입류에 C, R, U, D가 발생되고 납품 회사에 관련된 단위 프로세스들은 납품 회사, 정산, 입고류에 C, R, U, D가 발생되어 두개의 노드로 분리될 수 있는 기준을 찾을 수 있다.


<그림 16>에서 나타나듯이 각각의 프로세스에 대해 엔티티 타입과 C, R, U, D를 체크하다 보면 엔티티 타입에 밀집도가 분석되고 이 밀집도에 따라 RAC 노드가 두 개이면 밀집도가 높은 엔티티 타입을 묶어 두 개로 나누어 각각의 노드에 배치하면 된다. 물론 <그림 16>처럼 다른 영역의 엔티티 타입과도 C, R, U, D가 발생할 수 있다. 그러나 단위 프로세스가 모든 엔티티 타입에 트랜잭션을 유발하는 것은 아니므로 업무 구분에 따라 대체적으로 밀집도 구분은 가능하게 된다. 밀집도 높은 것을 기준으로 분리하면 각 노드에 트랜잭션이 분리되어 발생되므로 잠금 현상을 경감시킬 수 있게 되는 것이다.

질문 4-2) OPS에서 오라클9i RAC으로의 전환할 때 이미 개발된 프로그램의 변경이 예상된다. 그럴 경우 가장 고려해야 할 사항이 무엇인지 알고 싶다.

 

OPS와 RAC은 클러스터링 아키텍쳐 구성이 변경됐고 성능이 향상됐지만 근본적으로 처리 방식이 달라지지 않았기 때문에 OPS에서 오라클9i RAC으로의 전환할 때 개발된 프로그램의 소스에서 추가적으로 고려해야 할 사항은 없다. 다만 환경이 OPS에서 RAC으로 변경됐기 때문에 개발된 프로그램이 정상적으로 성능을 발휘하고 있는지 성능 테스트를 하는게 가장 고려해야 할 사항이다.

 

배치 작업의 성능 이슈와 마스터 테이블 관리

 

질문 5) 일반적으로 배치 작업은 대량의 데이터를 일괄적으로 처리하기 위한 작업이다. 그래서 여러 배치 작업이 동시에 실행될 때는 자원의 경합을 해결하는 것이 가장 큰 문제라고 생각한다. 본인의 경우에도 현재 업무 중 가장 중요한 배치 업무의 성능 저하로 인해 어려움을 겪고 있는 상황이다.
첫째, 현재 가장 중요한 배치를 처리하는 업무는 주로 1:1 모델링 내용에서 자문했던 그 테이블을 위주로 데이터를 처리한다. 그 중에서도 항상 트랜잭션 테이블을 참조해서 데이터가 있으면 무시하고 없거나 다르면 입력이나 수정하는 작업이 있다 보니 같은 업무(불량 내역)를 처리할 때는 경합이 발생하지 않으나, 서로 다른 업무(불량 내역, 대출 내역)를 동시에 처리하면 경합이 발생하여 배치 작업 시간이 늘어나게 된다. 그래서 마스터 테이블인 트랜잭션 테이블에 대해 경합이 발생하지 않도록 모델을 재설계하는 방법이나 처리 방식 변경 방법에 대해 질문한다.


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


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


셋째, 데이터 50~100만 건을 처리하는데 3~5개로 분할해서 처리하는 경우에 시간이 3~6시간 정도가 걸린다. 물론 시스템 리소스의 문제도 있겠지만 배치 처리 대상 테이블에 거의 트리거가 걸려 있다. 이럴 경우 트리거가 배치 처리의 시간이나 시스템 부하에 미치는 영향이 어느 정도인지 알고 싶고, 사후 처리하는 것 역시 하나의 방법이 될 것 같은데 각각의 경우에 대해 고려해야 할 사항을 알고 싶다.

첫번째 질문인 트랜잭션 테이블에 대해서 경합이 발생하지 않도록 모델을 재설계하는 방법이나 처리 방식 변경 방법에 대해 설명하겠다. 데이터 모델을 보면 트랜잭션 테이블이 배치 처리의 대상이 되는 마스터 테이블이다. 그러므로 트랜잭션 테이블을 이용하여 특정 배치 작업이 처리되고 다른 유형의 배치 작업이 수행되면 로우가 겹치지 않으므로 당연히 잠금이 발생하지 않지만 만약 동일한 사람에 대해 불량과 대출에 대한 배치 작업을 처리하다 보면 동일 구조의 거래 식별 테이블을 참조하여 처리해야 하므로 잠금 현상이 발생할 수밖에 없다. 이런 경우는 PK 구조를 바꾸어도 업무적으로 마스터 테이블의 PK를 이용할 수밖에 없으므로 잠금 현상이 발생한다.


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


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


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


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


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


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

 

질문 5-1) 첫번째 질문에서 잠금 현상을 회피하기 위한 방법으로서 커밋하는 것은 적용 가능한 부분인 것 같다. 그런데 정렬을 하기 위해서는 몇 가지 단계를 거쳐야 하고 소스 파일의 구조도 달라서 쉽지 않을 것 같다.

 

만약 인위적인 정렬이 어렵다면 반복문(LOOP문) 안에서 SAM 파일을 읽을 때 하나의 작업은 1..전체로우의 순으로 진행하고 다른 작업은 전체로우..1까지 처리하는 방법이 있다. 즉 100개의 로우를 가진 SAM 파일이 있다면 하나의 작업은 for i=1 to 100 { 작업1 } 또 하나의 작업은 for i=100 downto 1 { 작업2 } 형식으로 진행하면 처리되는 데이터가 겹칠 가능성이 적어지므로 잠금 현상을 최소화할 수 있다.

질문 5-2) 마스터 테이블에 대한 변경이 일어나지 않도록 업무별로 서로 다른 TEMP성 마스터 테이블을 가지고 마스터 테이블에 대한 변경 건이 발생하면 TEMP에 넣었다가 배치 작업이 완료된 후에 TEMP 데이터를 마스터에 일괄 반영하는 방법을 고려하고 있다. 이럴 경우 마스터 테이블은 오로지 SELECT만 일어나므로 서로 다른 업무를 동시에 진행할 수 있고 TEMP에 들어간 데이터는 적절한 업무 규칙을 적용하면 되지 않을까 한다.

 

TEMP에 배치 작업을 처리할 때는 잠금 현상 문제가 발생되지 않지만 TEMP에 들어간 데이터를 다시 마스터 테이블에 반영할 때 순차적으로 처리하지 않고 동시에 처리한다면 이 방법도 역시 동일한 형태의 잠금 현상이 발생할 가능성이 있다. 오히려 배치 작업이 두번 수행되는 형태가 되므로 시스템의 자원을 많이 사용하는 형태가 된다. 그러므로 커밋 주기를 단축시키고 배치 작업간 정렬 순서를 변경해 적용하여 잠금 현상을 피하는 것이 가장 좋은 방법이 될 수 있다.

 

모델러와 DA의 전망 및 비전

 

질문 6) 앞으로의 모델러 및 DA의 전망 및 비전은?

데이터를 다루는 데이터 아키텍트(Data Architect, DA)의 전망은 매우 밝다. 9년 전에 IT 기술 분야 중 가장 유망한 분야는 데이터베이스 분야와 네트워크 분야라는 이야기를 들은 적이 있다. 9년이 지난 지금 그 말은 사실이었고 데이터베이스 분야는 기업의 모든 IT 정책의 핵심을 이루고 있다. 지금도 필자가 속해있는 LG CNS에서는 데이터 분야의 기술을 가진 인재들이 여러 프로젝트와 시스템에서 중요한 역할을 수행하고 있다. 이제 유비쿼터스 환경이 되면 더욱 많은 데이터들이 온라인에서 움직이게 될 것이고 따라서 데이터의 중요성과 설계, 구축, 관리 전문가에 대한 요구가 더 늘어날 것이다.


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

 

데이터 모델의 핵심은 방향 설정

 

서울의 지하철 중 1호선은 구로역에서 인천 방향과 수원 방향으로 방향이 바뀐다. 인천에 살고 있는 필자가 1년에 한 번 정도 정신없이 수원행을 탄 적이 있다. 잘못 승차한 전철에서 바깥 풍경을 보고 있으면 ‘아차 잘못 탔구나!’ 느낀다. 그러면 가장 가까운 역에서 내려 다시 갈아타야 한다. 계속 머뭇거리고 결정을 내리지 못하면 목적지인 인천에서 더 먼 곳으로 자꾸 이동하게 된다. 데이터베이스의 방향은 데이터 모델이 결정한다. 데이터 모델이 잘못되었다는 것을 인지하면 신속하고 정확하게 방향을 잡아가는 것이 데이터 모델에서 제일 중요한 요소가 된다. 데이터 모델링을 할 때 논리 모델은 업무 중심으로 물리 모델은 데이터베이스 중심으로 전개하는 것을 꼭 잊지 말길 바란다.

출처 : 마이크로소프트웨어[2004년도 7월호]

Posted by tornado
|