DW Data Conversion

1999, 한 만호

Data Warehouse Architect

원본출처 : http://bora.dacom.co.kr/~mhan/dw/dataconv.html

데이타 웨어하우스를 위한 데이타 변환 작업은 복잡하고, 시간이 많이 필요한 즐겁지 않는 과정이다. 그러나 데이타 변환은 제대로 된 데이타 웨어하우스의 근간이 되는 것으로써, 데이타는 데이타 웨어하우스에서 핵심이 되는 것이다. 데이타 웨어하우스는 조직의 의사결정을 위한 중요한 정보를 유지하는 것이기 때문에, 데이타 변환이 정말 중요한 작업이라고 강조하는데 의의가 없을 것이다. 데이타 웨어하우스의 궁극적인 목적을 달성하기 위하여는 데이타 변환작업이 얼마나 중요한지를 이해하여야만 한다.

데이타 변환 팀

데이타 변환을 하기 전에 데이타 웨어하우스 설계와 물리적 데이타 모델이 완성되어 있어야 하며, 타겟 스키마가 생성을 완료하고 있어야 한다. 데이타 변환 팀은 웨어하우스 구조를 설계, 소스데이타를 분석, 데이타 매핑 정의, 외부데이타 수집및 생성, 데이타변환 로직 결정, 변환 루틴 계획, 데이타 품질을 보증하는 업무 및 기술 전문가로 구성된다. 이 팀은 또한 데이타 이행이나 변환을 위하여 사용할 툴을 선정하는 임무를 가지기도 한다.

변환계획

데이타 변환작업 성공을 위한 가장 중요한 요소는 변환팀의 모든 멤버들이 변환요구사항과 그 절차를 충분히 숙지하여야 하는 것이다. 웨어하우스를 위한 데이타 변환은 보통 대규모이고 그래서 변환시간을 가능한 단축하기 위하여 동시에 진행하여야할 여러가지 작업단위가 필요하게 된다. 따라서 데이타 변환 요구사항이나 흐름을 잘못 숙지한다면 그 연결된 작업들이 원활히 연결되지 않게 되는 것이다.

변환계획은 소스 데이타를 데이타 웨어하우스로 이행하기 위한 최선의 방안을 결정한다. 이용할 수 있는 자원과 소스 테이타 규모, 스키마가 다른 소스 갯수, 액세스 방법과 플랫폼 종류, 데이타 웨어하우스 구조등을 고려하여 변환계획이 결정되어야 한다.

변환계획은 소스 시스템의 플랫폼, 액세스 방법, 데이타 추출을 위한 프로그램 언어에 대하여 문서화한다. 만일 여러 시스템에 탑재된 많은 소스 시스템으로부터 데이타를 추출해야 한다면, 데이타 변환 계획은 데이타를 통합하고 정제하고 변환하기 위한 중간 단계(Common Staging Area)까지 데이타를 추출할 전략을 세우는것이 바람직하다. <그림 1 참조>

일반 정차 영역(Common Staging Area)으로 데이타를 이동하기 위한 전략에는 이용가능한 기계들, 데이타 변환팀이 보유한 데이타 수집 기술, 소스 데이타 규모등이 고려되어야 한다. 예를 들어 소스 시스템이 MVS 이고, 데이타 변환팀이 보유한 기술이 MVS와 COBOL이고, 데이타는 대규모라는 경우를 생각하여 보자. 이 경우 MVS 시스템을 이용한 컴먼 스테이징 에어리어 사용이 권고될수 있다. 그렇지만 MVS 시스템 용량이 빠듯하고, 변환팀이 유닉스와 C언어에 강하다고 할때는 유닉스 기반의 컴먼스테이징 에어리어가 적합하고, 아마도 실제 데이타 웨어하우스가 탑재될 플랫폼에 컴먼스테이징 에어리어를 설정하는 계획이 세워질 수 있을 것이다.

또한 데이타 변환계획에는 데이타 웨어하우스 구조와 목표 데이타베이스 스키마들이 고려되어야 한다. 일반적으로 데이타는 소스 데이타 스키마로 부터 정차영역(Staging Area)의 스키마로 이동된다. 스테이징 에어리어의 스키마는 추출되는 모든 소스 시스템과 인터페이스되는 공통 인터페이스 이다. 이 중간 스키마는 소스 스키마나 목표 스키마와 같은 모양이 아니다. 보통 계산에 사용되는 페센티지 같은 추가된 필드 또는, 참조 테이블이나 테이블을 찾기 위한 키 필드를 추가함으로써, 데이타 조건성을 향상시키고 데이타 변환을 용이하게 한다. 마지막으로 데이타 변환 계획에는 다음과 같은 데이타 변환 흐름이 고려되어야 한다.

소스 시스템으로부터 스테이징 에어리어로 데이타를 어떻게 이행할 것인가?

정차 영역(Staging Area)에 데이타를 어떻게 집합하고, 변환하고 분류할것인가?

데이타 웨어하우스의 주키와 외래키를 어떻게 관리할 것인가?

정차 영역으로부터 데이타 웨어하우스 서버로 데이타를 어떻게 이행할 것인가?

메타 데이타를 어떻게 저장하고 갱신하고 추출할것인가?

데이타 웨어하우스 서버에 데이타를 어떻게 탑재하고 색인을 만들것인가?

데이타 웨어하우스의 다음 단계에서 추가되는 데이타를 어떻게 취합할 것인가?

데이타 변환과정에서 데이타 품질을 어떻게 보증할 것인가?

변환 정의서 생성

계획을 수립한 다음 단계는 소스 데이타를 신중히 분석하는 것이다. 데이타 속성을 분석하여 소스 데이타를 어떻게 목표 데이타와 일치시키는가? 그리고 그 변환을 위하여 어떤 로직이 필요한가를 결정하여야 한다. 또한 산업표준 코드 테이블같이 연결하여 참조하는 외부 정보도 정의하여야 한다.

흔히 고객이 검토하고 OK하기 위하여 워드 프로세서나 스프레드 시트로 변환 정의를 문서화하여 인쇄하곤 한다. 그러나 데이타 이행도구를 사용한다면 툴로서 변환정의를 직접 문서화 할수있고 고객이 검토하기 위한 인쇄물을 바로 출력할 수있다.

어쨌든 변환정의서는 데이타 웨어하우스를 위한 매우 중요한 메타데이타 이다. 데이타 이행 도구들은 변환 메타데이타를 자동으로 중앙 스토리지에 저장시키고, 메타데이타 변환시간을 추적하며, 변환 메타데이타를 추출하여 데이타 웨어하우스의 메타데이타 리포지터리에 저장한다. 변환 절차를 수작업으로 작성하였다면 그 메타데이타도 수작업으로 작성하여야 한다. 데이타 변환 계획은 메타데이타를 추출하고 저장하고 갱신하는 변환 메타데이타 형태를 정의한다.

변환 정의를 프로그래밍 가능한 코드로 생성하기 위하여 수작업으로 하던 아니면 툴을 이용하여 자동으로 하던간에, 데이타 매핑과 필요한 프로세스를 이해하기 위하여는 변환정의서를 반드시 작성하여야 한다. 프로그래밍 가능한 코드는 다음 기능을 수행하는 6개 유형의 루틴으로 구성된다.

. 소스 시스템으로부터 중간 스키마로 데이타 추출

. 중간 스키마를 탑재 데이타로 변환

. 탑재 데이타 수집

. 정차 영역의 탑재 데이타를 데이타 웨어하우스 서버로 이행

. 탑재 데이타를 데이타 웨어하우스 DBMS로 집단 이동

. 데이타 정합성 검사

소스 데이타를 중간 스키마로 추출

데이타 추출 루틴은 소스 데이타를 읽어서 그것을 중간 스키마로 변환한 다음 일반 정차 영역(Common Staging Area)으로 이동시키는 것이다. 이렇게 일반 정차 영역으로 데이타를 추출하게되면 프로그램된 루틴들의 재사용성을 크게 향상시키게 된다. 어떤 프로그램은 소스 시스템의 검색방법이나 플랫폼 또는 언어때문에 재사용 할수 없는 유니크한것이 될수도 있다. 그렇지만 데이타가 일단 중간 영역으로 추출이 되면 프로그램에서의 조건, 변환, 통합등이 모든 소스 코드에 적용될 수 있는 효과가 있다.

데이타 추출은 데이타 웨어하우스로 이행되어야 할 데이타만을 대상으로 하도록 설계되어야 한다. 데이타 웨어하우스의 초기 데이타 탑재와 후에 발생하는 갱신에 효과적이도록 설계되어야 하며, 이것은 데아타 웨어하우스로 이행되어야 할 데이타 량을 최소화하고 데이타 이행을 위하여 필요한 컴퓨터나 네트워크의 자원을 최소화 하는 효과가 있으므로 매우 중요한 요인이 되는것이다.

타임 스템프를 찍거나 일정한 주기로 추출하는 방안은 데이타 추출을 손쉽게 정의할 수 있고 갱신 데이타와 새로운 데이타를 구분시킬수 있으므로 매우 효과적인 방안이 된다. 소스 시스템이 갱신 또는 새로운 데이타를 인식하여 주지 않는다면, 갱신 또는 새로운 데이타를 인지하기 위하여는 소스 데이타를 데이타 웨어하우스의 마스타 파일과 비교한다.

데이타 추출 프로그램은 보통 소스 시스템 환경에서 수행되는데, 이진수 변환, 팩데시말 데이타 변환, 비교, 결합같은 변환기능을 수행한다. 이러한 변환 조건들은 이런 유형의 데이타가 생성되는 소스 시스템에서 보다 쉽게 수행될것이다. 이러한 조건 처리는 데이타 소스에 대한 지식, 운영시스템 또는 데이타 웨어하우스에 탑재된 데이타 구조, 최종 사용자 또는 데이타 웨어하우스 적용업무가 필요로 하는규칙같은 것들에 대한 노우하우에 크게 의존하게 된다.

중간 스키마를 탑재 데이타로 변환

소스 데이타가 정차 영역으로 집합되면, 데이타를 정제하기 위한 변환 프로그램을 수행하여야 한다. 데이타 정제는 특별한 프로그램을 이용하여 데이타 무결성을 보장하는것이다. 데이타 정제 프로그램은 기존 배치 작업과는 별도로써, 배치 작업이나 온라인 작업에서 호출하여 수행시키거나 기존 작업과는 별도로 특멸히 수행하게 된다.

데이타 정제를 수행하는 데이타 변환팀으로서는 데이타 웨어하우스 구조 설계가 데이타 정제 프로그램의 제약규칙에 반영되도록 하여야 한다. 이 프로그램은 소스 시스템에서 데이타를 정제하지 못하였을 경우에만 사용하게 된다. 또한 데이타 변환 계획에는 모든 데이타 정제 요건이 정의되어야 한다.

다음은 데이타 정제를 위한 주요한 내용들이다.

. 데이타 시험 : 데이타 질, 데이타 패턴, 필드들의 카디널리티를 결정한다.

. 데이타 파싱 : 각 필드의 각 내용의 목적지를 결정한다.

. 데이타 대사 : 데이타를 이미 알려진 리스트와 대조하여서 모든 필드에 통과, 불량, 자동수정등의 꼬리표를 붙인다.

. 레코드 대사 : 두개의 레코드가 같은 객체에 속하는지 판별한다.

데이타를 여러개의 주제 영역에서 또는 서로 다른 버전으로부터 가져왔다면 이들을 통합하여 하나의 단일 뷰로 만들어야 한다. 또한 데이타를 이행하고 탑재하기 전에 데이타의 비정상과 그 해결방안이 도출되어야 한다.

데이타 조건정의, 정제, 전달, 통합등은 대화식으로 조작되어야 한다. 변환팀과 고객이 데이타 상황에 만족한 이후에 탑재할 데이타를 생성하여야 한다.

스타 조인 스키마의 각 디멘존을 위한 키를 추적하고 생성하기 위햐여 키 관리 응용프로그램이 있어야 한다. 키 생성과 관리를 위한 전략은 다양하다. 데이타 웨어하우스에서 키들은 통합된다. 시스템적으로 생성되는 키들은 변환 시스템이나 RDBMS자체에서 생성한것이다.

탑재 데이타 집합

탑재 데이타는 정렬 프로그램 수행이라든가 앞서 언급한 키 관리 프로그램 수행으로 모아진다. 일반적으로 이 작업은 RDBMS 내부 처리보다는 순차적인 외부처리를 하는데 그 이유는 다음과 같은 3가지 정도때문이다. 첫째, 특별한 정렬전용 소프트웨어가 훨씬 빠르다. 둘째, 새로운 탑재 데이타는 손상복구용의 한부분으로 ㅔ이타웨어하우스에 저장된다. 셋째, 내재된 SQL보다는 대량 탑재 유틸리티를 이용하는것이 훨씬 빠르고 효과적이다.

데이타 품질 보증

별도의 과정이 아니라 데이타 변환 과정을 통하여 데이타 품질이 보증되어야 한다. 변환 계획은 고객이나 최종 사용자의 리뷰와 확인절차, 데이타 검증및 수정 절차등을 정의하고 있다.

변환 계획이나 정의를 작성할때는 고객이나 최종사용자와 밀착되어 진행하여야 한다. 앞서 언급하였듯이 소스 시스템에서 데이타 웨어하우스로 데이타를 변환하기 위한 최적의 경로를 계획하기 위하여 기존 처리 환경을 실사하여야 하고, 그 계획은 문서화되어 고객이 검토하도록 하여야 한다. 이 과정에서 고객은 변환 처리 과정의 선행과제를 알게된다. 계획을 이해하였다는것을 알리기 위하여 고객은 공식적으로 이 변환계획에 서명하여야 한다.

효과적인 변환정의를 위하여 그 구조와 각 필드의 의미를 망라하여 소스 데이타를 가능한 많이 파악하여야 한다. 또한 소스 데이타가 어떻게 목표 데이타로 전이되는지 자신이 이해한바를 문서화하고 이것을 고객과 같이 리뷰하여야 한다. 고객은 소스 데이타의 의미를 검증하여 줄뿐 아니라, 소스 데이타가 데이타 웨어하우스와 어떻게 관련이 되는지 보다 잘 파악할 수 있다. 고객이 동의하였다는 금거를 남기도록 고객이 변환정의서에 서명하도록 한다.

지름길은 없다

각 데이타 웨어하우스로의 데이타 변환 처리 과정은 데이타 웨어하우스 설계, 소스 시스템 구조, 소스 데이타의 정확성 정도, 소스 시스템 통합 요구등의 변수에 따라 복잡도가 달라진다. 그러나 데이타 변환 행위 자체는 거의 변하지 않는다. 데이타 변환 순서를 필요에 따라 다르게 선택할 수 있지만, 그 과정의 하나라도 삭제하여서는 안된다.

데이타 웨어하우스의 품질은 데이타 변환 과정의 각 단계에 얼마나 세심한 주의를 기울였느냐에 좌우된다.

그림 1