문서요약 - 데이터웨어하우스 구축 시 마주치는 에러 by LGI System

제목: 데이터웨어하우스 구축 시 마주치는 에러(What Data Errors You May Find When Building A Data Warehouse)

저자: LGI Systems Incorporated

문서유형: 웹문서(http://www.dwinfocenter.org/errors.html)

 

데이터웨어하우스(DW) 개발 시 많은 시간을 들여 정제 해야만 하는 더티 데이터 에러를 4개 범주로 구분해 기술한 자료

---

불완전 에러(Incomplete errors)

• 분실된 레코드(Missing records): 소스 시스템이 있어야 할 레코드가 있지 않음. 대개 프로그래머가 파일에 손을 댄 후 완전하게 정리를 안 해서 야기됨. 연결 지을 또 다른 시스템이나 과거 보고서가 있지 않는 한 이런 타입의 에러는 알아채지 못 할 수도 있음
• 분실된 필드(Missing fields): 그 자리에 있어야 할 필드가 있지 않음
• 설계에 따라 미기록된 레코드/필드: DW에 저장하고자 하는 어떤 데이터가 어디에도 기록되어 있지 않음(설계가 부주의해서거나 또는 설계가 실제 이를 의도했을 수도 있음). 이 상황은 아래 3가지 범주로 세분될 수 있다.
  1) 기록하려는 디멘젼 테이블 애트리뷰트가 DW에 공급되는 어떤 시스템에도 있지 않음
  2) 다수의 시스템으로부터 동일 타입의 데이터가 공급되는 경우 소스 시스템들 중 하나가 DW에 저장하고자 하는 어떤 필드를 기록 안 함
  3) DW에 저장할 필요가 있지만 명백한 방식으로 기록되지는 않는 트랜잭션이 있음(예, 소스 시스템을 업데이트 하는 것이 반드시 트랜잭션의 기록을 야기하지는 않음)

부정확 에러(Incorrect errors)

• 잘못된(하지만 때때로 올바른) 코드: 예, 오래된 수리 부품 주문 시스템(모든 트랜잭션에 제품 코드 100을 할당하도록 1968년에 프로그래밍된 시스템)으로부터 데이터를 추출해야만 함. 하지만 현재는 제품 코드 100이 수리 부품이 아닌 다른 것을 나타냄
• 잘못된 계산, 집계(Wrong calculations, aggregations): DW 환경 밖에서 이미 계산된/집계된 데이터를 로드 할 때의 이슈. 즉, 이 데이터를 체크할지 여부를 결정해야 함. 오로지 이 계산 체크를 허용하기 위해서 데이터를 DW 환경으로 가져오는 것이 필수적으로 될 수도 있음
• 중복 레코드(Duplicate records): 대개 두 가지 상황을 다루어야 함(DW로 데이터를 공급하는 어떤 한 시스템 내에 중복 레코드가 있거나, 또는 동일 타입의 정보를 DW에 공급하는 다수 시스템에 중복된 정보가 있음). 예, ‘제품 주문 입력 시스템’과 ‘서비스 주문 입력 시스템’의 데이터를 DW에 공급하는 경우, 어떤 지점이 실수로 제품 주문 입력 시스템과 서비스의 주문 입력 시스템 모두에 서비스를 예약함. 양쪽 경우 모두 이미 집계된 데이터를 DW에 공급한다면 이 중복을 놓칠 수도 있다.
• 소스 시스템의 잘못된 정보: 소스 시스템이 단순히 부정확하게 입력된 데이터를 포함하고 있을 수 있다. 예, 누군가 키를 잘못 눌러 6/9/96을 9/6/96으로 입력. 이 때 당연한 행동은 소스 시스템을 수정하는 것이지만 간혹 여러 이유로 소스 시스템이 수정되지 못할 수도 있음. 소스 시스템에 이렇게 수정될 수 없는 에러가 많아지면 레코드 신뢰성에 대한 더 큰 이슈가 생긴다.
• 부정확한 코드 쌍(Incorrect pairing of codes): 예, “부품 번호가 XXX로 끝나면 카테고리 코드가 A 또는 B 또는 C 이어야 한다” 같은 규칙이 있을 수 있다. 즉, 애트리뷰트 간 비연산적 관계(non-arithmetic relationship)가 존재하는데 이것이 깨짐

불가해성 에러(Incomprehensibility errors)

• 하나의 필드 내 다수 필드(Multiple fields within one field): 소스 시스템이 하나의 필드에 담고 있는 정보가 DW에서는 여러 필드에 담긴다. 예) 이름 "Joe E. Brown"이 소스 시스템에서는 단일 필드에 보관되지만 DW에서는 3개 필드로 파싱되어야 함
• 디스크 공간을 아끼기 위한 이상한 포매팅: 소스 시스템의 프로그래머가 디스크 공간을 절약하기 위해 일상적이지 않은 방법에 의존함. 이상하게 포맷된 필드에 더불어 프로그래머가 레코드 레이아웃도 다양화 시켰을 수 있음
• 알려지지 않은 코드(Unknown codes): 대개의 경우 코드의 99%는 의미를 알 수 있지만 알려지지 않은 코드를 가진 몇몇 레코드가 발견되기도 함
• 스프레드시트와 워드프로세싱 파일: DW에 최초 로드를 하기 위해 스프레드시트 파일(또는 병합 리스트 파일)에 담겨 있는 중요 데이터를 추출하는 것이 종종 필수적인데, 이런 파일은 어떤 것이든 담고 있을 수 있다.
• 다 대 다 관계와 다수 부모를 허용하는 계층 파일: 소스 시스템의 이런 아키텍쳐에 주의해야 함. 이런 식으로 조직된 데이터는 부정확하게 이전되기 쉽다.

불일치 에러(Inconsistency errors)

• 코드의 일관성 없는 사용(Inconsistent use of different codes): 성별 구분을 위해 한 시스템은 "M"과 "F"를 다른 시스템은 "1"과 "2"를 사용
• 코드의 의미에 일관성 없음(Inconsistent meaning of a code): 엔터티의 정의가 시간 경과에 따라 변할 때의 이슈. 예, 1995년에 고객 A, B, C, D가 있었음. 1996년 A가 B를 사들였고, 1997년 A가 C를 사들임. 1998년 A가 A와 C의 일부분이었던 것을 D에게 매각. 1999년 DW 구축 시 고객 A, B, C, D의 과거 매출을 어떻게 식별할지 딜레마에 빠짐
• 중복된 코드(Overlapping codes): 한 소스 시스템이 고객 A의 모든 매출을 3개의 고객 번호를 가지고 기록하고, 또 다른 소스 시스템은 A의 매출을 2개의 다른 고객 번호를 가지고 기록함. 쉬운 해결책은 하나의 고객 번호를 사용하는 것이지만, 문제는 이렇게 5개의 고객 번호가 있는 데는 대개 그럴만한 사업적 이유가 있다는 점이다.
• 동일한 의미를 가지는 다른 코드(Different codes with the same meaning): 예, 일부 레코드는 보라색(violet)을 나타내고 또 일부는 자주색(purple)을 나타내는데 DW 사용자가 이것들을 하나의 색으로 보고자 함. 더 성가시게는 때때로 공백(spaces)과 기타 관련 없는 정보가 코드에 일관성 없이 끼어 있기도 함
• 일관성 없는 이름과 주소(Inconsistent names and addresses): 엄격히 말하면 ‘동일한 의미를 가지는 다른 코드’의 한 경우이다. 실질적인 크기의 데이터베이스에서 이름과 주소 정보를 100% 일관되게 만드는 것을 거의 불가능
• 일관성 없는 업무 규칙(Inconsistent business rules): 계산 값이 다른 방식으로 계산되었거나(보통은 계산된 값을 DW에 로딩하는 것을 피하지만 때때로 불가피한 상황이 있음), 또는 두 필드 간의 비연산적 관계(예, 부품 번호가 XXX로 끝나면 카테고리 코드가 A 또는 B 또는 C 이어야 한다)가 일관성 없이 준수됨
• 일관성 없는 집계(Inconsistent aggregating): 엄격히 말하면 ‘일관성 없는 업무 규칙’의 한 경우이다. 집계된 데이터의 여러 셋을 비교할 필요가 있는데 이 데이터가 소스 시스템들에서 다른 방식으로 집계됨
• 최소 단위 정보의 일관성 없는 입자(Inconsistent grain of the most atomic information): 동일한 입자로 가용하지 않은 여러 정보 셋을 비교해야 하는 경우가 있음
• 일관성 없는 타이밍(Inconsistent timing): 엄격히 말하면 ‘최소 단위 정보의 일관성 없는 입자’의 한 경우이다. 데이터 구매 시 특히 문제가 됨. 예, 한 피클 회사가 식품점의 피클오이 매출에 대한 정밀 조사 자료를 구매해 분석하고자 함. 주 별 수치 데이터를 구매했는데, 누군가가 내부 시스템으로부터 나온 매월 비용 데이터를 포함하는 월례 보고서 생성을 요구하면 곤란해짐
• 애트리뷰트의 일관성 없는 사용(Inconsistent use of an attribute): 예, 주문 입력 시스템이 ‘선적 지시(shipping instructions)’라고 이름 붙은 필드를 가지는데, 이 필드가 ‘고객 구매 대리인의 이름’, ‘고객의 이메일 주소’ 등을 포함함. 더 어려운 상황은 여러 다른 비즈니스 정책이 필드를 채우는데 사용될 때이다. 예, 원장 계정 번호를 가진 사실 테이블에서 관리비(administrative expenses)를 위해 엔터티 A는 계정 ‘1000’을 사용하고 엔터티 B는 ‘1500’을 사용
• 일관성 없는 날짜 기입(Inconsistent date cut–offs): 엄격히 말해 ‘애트리뷰트의 일관성 없는 사용’의 한 경우이다. 트랜잭션 날짜 기입(dating transactions)에 있어서 다른 정책을 따르는 두 개 시스템으로부터의 데이터를 합병 시 판매 및 반품 일자 결정에 대한 이슈가 생긴다.
• 널(nulls), 공백(spaces), 값 없음(empty values)의 비일관적 사용: DW에서 수정하기가 아주 어려운 문제는 아니지만 최악의 순간에 발견될 때까지 쉽게 잊고 있는 경우가 많다.
• 참조 무결성 결여(Lack of referential integrity): 이 기본적 체크도 없이 구축된 소스 시스템이 놀랍게도 많음
• 맞지 않는 사실 데이터(Out of synch fact data): 특정 요약 정보가 여러 다른 사실 테이블의 데이터로부터 독립적으로 도출될 수 있음. 예, 총 판매 수량이 ‘원장 차/대변 사실 테이블’에 있는 트랜잭션을 더하거나 또는 ‘매출 송장 사실 테이블’에 있는 트랜잭션을 더함으로써 도출될 수 있음. 한 테이블이 다른 테이블보다 늦게 업데이트 되므로 당연히 차이가 있을 수 있지만, 종종 이 차이가 더 깊은 문제의 징후일 수 있다.