#title 데이터 품질-성공으로 가는 열쇠 [[TableOfContents]] ==== 장의 목표 ==== * DW에서 데이터 품질이 왜 중요한지 분명히 이해한다. * 훼손된 데이터에 의해 제기된 난제들을 주시하고 그것들을 처리하는 방법들을 배운다. * 품질 좋은 데이터의 장점들을 인지한다. * 데이터 품질 도구들의 다양한 범주들을 검토하고 그것들의 사용법을 검사한다. * 데이터 품질 주도가 내포하는 것들을 연구하고 데이터 품질에 관한 실제적인 조언들을 배운다. 오류코드 하나가 사용자들에 의해 수행된 모든 분석들은 심각한 허위 설명이 될 것이다. 운영계의 그다지 중요하지 않게 보이던 오류는 DW로부터 나온 결과에 엄청난 왜곡을 가져오는 원인이 될 수 있다. 이는 사용자의 잘못된 결정을 가져오고, 결국은 비용의 낭비를 초래하게 된다. 데이터 품질 문제는 DW프로젝트의 가장 큰 실패 원인 중 하나다. 사용자들은 데이터가 받아들일 수 없는 수준이라는 것을 감지하자마자 DW에 대한 신뢰를 잃는다. ==== 데이터 품질은 왜 중대한가? ==== 데이터 품질이 중요한 이유 * 의사 결정에서 신뢰를 부양시킨다. * 더 나은 고객 서비스를 가능하게 한다. * 서비스에 더 좋은 가치를 부가할 기회를 증가시킨다. * 손해가 큰 의사결정들로부터의 위험을 감소시킨다. * 비용, 특히 마케팅 캠페인 비용을 감소시킨다. * 전략적인 의사결정을 증진시킨다. * 간결한 처리들로 생산성을 향상시킨다. * 데이터 오염의 혼합효과를 피한다. ===== 데이터 품질은 무엇인가? ===== 대부분의 데이터 클린징 작업은 정확성에만 집중한다. 하지만 DW의 데이터는 데이터 정확성을 능가해야 할 필요가 있다. 다음은 데이터 품질에 대한 간단한 물음이다. 다음의 물음에 '예'라고 답한다면 해당되는 데이터 항목은 데이터 품질의 표준에 적합하다. * 개체 안의 데이터 항목이 사용자가 관찰하려는 것을 정확히 반영하는가? * 데이터 항목이 사용자들에 의하여 정의된 목적의 적합성을 소유하는가? DW에서 데이터 품질은 단지 각각의 데이터 항목들의 품질만이 아니라 완전히 통합된 전체로서의 시스템의 품질이다. 다음은 데이터 품질을 측정하는 참고할 만한 리스트다. {{{#!html

데이터 품질 측정 항목	설명
정확성(accuracy)	데이터 구성요소로서 시스템에 저장된 값은 그 데이터 요소의 어커런스에 대한 올바른 값이다. 고객ID 'databaser'의 거주지가 '서울'이 맞다면 정확한 값이다.
도메인 무결성(domain integrity)	한 속성의 데이터 값은 허용되고, 정의된 값들의 범위 안에 속한다.
데이터 유형(data type)	데이터 유형이 1byte 숫자형이라면, SQL Server에서는 tinyint로 정의된다.
일치성(consistency)	데이터 필드의 포맷과 내용은 여러 소스 시스템걸쳐 같아야 한다. 예를 들어, 제품 ABC에 대한 제품코드가 1234라면, 그 제품에 대한 코드는 모든 시스템에서 1234이어야 한다.
중복성(redundancy)	같은 데이터는 두 개 이상의 장소에 저장되어서는 안 된다. 효율성 때문이라면 그 데이터 요소는 두 개 이상의 장소에 의도적으로 저장되어 그 중복이 분명히 확인되어야 한다.
완정성(completeness)	시스템 주어진 속성에 대하여 누락된 값들이 없어야 한다. 예를 들어, 주문 상세 항목에 대한 파일에서 주문에 대한 모든 상세 레코드는 완전히 채워져야 한다.
복제(deplication)	시스템에서 레코드의 복제는 완벽하게 결정된다. 만일 제품 파일이 복제 레코들을 가지 것으로 알려지면, 각 제품에 대한 모든 복제 레코드들은 확인되어 교차 참조(cross-reference)가 생성된다.
업무 규칙에 일치하기(conformance to business rules)	각 데이터 항목의 값은 규정된 업무 규칙을 준수해야 한다. 예를 들어, 경매 시스템에서 경매 혹은 판매 가격은 제한 가격보다 작아서는 안 된다.
구조적 명확성(structural definiteness)	데이터 항목이 자연스럽게 각각의 구성 요소로 구조화 되어 질 때마다 이 항목은 잘 정의된 구조를 포함해야 한다.
데이터 변칙(data anomaly)	필드는 그것이 정의된 목적으로만 사용되어야 한다.
명확성(clarity)	데이터 요소는 품질 좋은 데이터의 모든 다른 특성들을 가질 수 있다. 그러나 만일 사용자들이 그 의미를 분명하게 이해하지 못하면 그 데이터는 사용자들에게 가치가 없다. 적당한 명명 관례는 데이터 요소들이 사용자들에게 잘 이해되어지도록 도와준다.
적시성(Timely)	사용자들은 데이터의 적시성(알맞은 시간)을 결정한다. 만일 사용자들이 고객 차원 데이터가 하루 이상 지난 것이 되지 않기를 기대한다면 소스 시스템에서 고객 데이터에 관한 변경들은 DW에 매일매일 적용되어야만 한다.
유용성(usefulness)	DW에서의 모든 데이터 요소는 사용자들 모임의 어떤 요구사항들을 만족시켜야만 한다. DW의 데이터가 사용자들에게 가치가 없다면 그 데이터 요소가 DW에 있는 것은 전혀 필요가 없다
데이터 무결정 규칙 준수(adherence to data integrity rules)	개체 무결성, 참조 무결성 규칙을 준수해야 한다. 기본키로 널 값을 가지는 것은 어떤 테이블도 개체 무결성을 가지지 못한다.

}}} ===== 향상된 데이터 품질의 이점 ===== * 적시성 향상 * 고객 서비스 향상 - 완전하고 정확한 정보는 고객 서비스를 엄청나게 향상시킨다 * 새로운 기회 - 교차 분석 등 * 비용과 위험의 감소 * 생산성 향상 * 신뢰성이 있는 전략적 의사결정 ===== 데이터 품질 문제들의 유형 ===== 예제 * 20억달러 규모의 회사의 청구서 작성 시스템에서 판매금액 4%가 잘못되었다면 세입에 있어서 추정된 손실은 8000만 달러 * 큰 카탈로그 판매회사가 카탈로그를 고객들과 유망 고객들에게 부칠경우 데이터의 중복이 있다면 중복된 만큼 카탈로그가 더 보내질 것이다. DW의 가장 큰 난제는? attachment:데이터품질-성공으로가는열쇠/dw_challenges.jpg 위의 조사 결과처럼 데이터 품질이 DW 프로젝트의 가장 큰 난제이다. 다음은 데이터 품질 문제 유형 리스트다. * 필드들의 더미 값 - 값이 '9999999999'와 같은 형식의 의미 없는 숫자로 채워져 있다. * 데이터 값들의 부재 - 우편번호 또는 기타 필드의 값이 없다. * 필드들의 비공식적인 사용 - 고객의 주소란에 상담내용을 적는 등의 행위 * 숨겨진 값 - 시간이 흘러 같은 값이 다른 의미를 가지거나 아예 모를 수도 있다. * 모순되는 값 - 제품 AAA의 제품코드는 1234인데, 다른 값이 사용될 수 있다. * 업무규칙 위반 - 휴가는 1년에 365일을 넘길 수 없음에도 불구하고 390과 같은 숫자가 입력되어 있다. * 재용된 기본키 - 새로운 고객들의 고객번호를 1로 새롭게 시작한다. (이전 데이터는 아카이빙하고 키 값을 재할당) * 유일하지 않은 식별자 - Row를 유일하게 구분할 수 없다. * 일치하지 않는 값 - 성별을 A시스템에서는 1,0과 같이 구분하고, B시스템에서는 'm', 'f'로 구분한다. * 부정확한 값 - A제품의 실제 Height는 100인데, 데이터는 110로 입력되어 있다. * 다목적 필드 - 필드의 원래 목적이 아닌 다른 용도로 사용된다. (특정 응용프로그램에만 종속적) * 잘못된 통합 - 시스템의 고립된 개발로 각 시스템의 고객번호 5555는 각각 다른 고객을 가리킨다. ==== 데이터 품질에서의 난제 ==== 다음에 대해서 알아본다. * 데이터 오염의 소스 * 이름과 주소의 정당성 인정 * 불충분한 데이터 품질에 대한 비용 ===== 데이터 오염의 소스 ===== * 시스템 전환 - 시스템이 과거로부터 발전하면서 시스템을 옮겨다닌 데이터가 오염 * 데이터 노화 - 데이터의 값들이 오래되면서 발생하는 문제. 오래된 데이터는 의미나 중요성을 잃는다 * 이질적 시스템 통합 * 서투른 데이터베이스 설계 - 개체무결성, 참조무결성 등의 규칙들이 없다. * 데이터 입력에서 불완전한 정보 * 입력 오류 * 국제화/지역화 * 사기 * 데이터 품질 유지를 위한 정책들의 결여 ===== 이름과 주소의 정당성 인정 ===== 이름들과 주소들을 입력하는 것과 관련된 몇 가지 본질적인 문제점 * 유일한 키의 부재 * 한 줄에 여러 이름들 * 두 줄에 한 이름 * 한 줄에 이름과 주소 * 혼합된 개인과 회사 이름들 * 같은 사람에 대한 다른 주소들 * 같은 고객에 대한 서로 다른 이름과 절차들 고객 데이터 정제를 위해 준비해야 하는 단계 * 이름과 주소 데이터를 복수 필드 포맷으로 고쳐 만들 필요가 있다 * 고객 레코드들을 매칭하는 알고리즘들을 고안하여 중복들을 발견해야 한다. ===== 불충분한 데이터 품질에 대한 비용 ===== * 판에 박힌 분석에 근거한 나쁜 결정들 * 사용할 수 없는 혹은 '오손' 데이터로 인한 사업상 좋은 기회의 손실 * 재실행의 원인이 되는 훼손된 데이터로의 소스 시스템에 대한 부담과 비용 * 법규의 불일치나 위반으로 인한 정부 기관들로부터의 벌금 * 감사(audit) 문제의 해결 * 불필요하게 자원을 사용하는 중복된 데이터 * 일치하지 않는 보고서들 * 데이터 훼손이 발견될 때마다 데이터를 수정해야 하는 시간과 노력 ==== 데이터 품질 도구 ==== 데이터 품질 도구의 기본적인 기능 * 데이터 오류 발견(data error discovery) - 틀림과 불일치 판정 * 빨리 그리고 쉽게 중복 레코드들을 확인 * 합법적인 도메인 값들의 범위를 벗어난 값을 가진 데이터 항목들을 확인 * 불일치한 데이터를 발견 * 허용 값들의 범위를 체크 * 닮지 않는 소스들로부터 데이터 항목들같의 불일치성들을 간파 * 사용자들이 데이터 품질 문제를 확인하고 양을 측정할 수 있도록 한다 * 시간이 지남에 따라 데이터 품질의 경향을 감시 * 분석을 위하여 사용된 데이터의 품질에 관한 사용들에게 보고 * RDBMS 참조 무결성 문제를 조정 * 데이터 교정(data correction) - 훼손된 데이터 수정(parse, 변환, 매치, 통합, 수정하는 일련의 알고리즘) * 불일치한 데이터를 정규화 * 다른 데이터 소스로부터의 데이터 합병을 향상 * 같은 그룹에 속하는 고객 레코드들을 그룹화하고 연관시킴 * 데이터 품질의 측정법을 제공 * 허용 값들에 대하여 확인 품질 관리를 위한 DBMS * 도메인 무결성 * 갱신 보안 * 개체 무결성 체크 * 분실 값들의 최소화 * 참조 무결성 체크 * 업무 규칙에 일치하기 ==== 데이터 품질 발의 ==== 데이터 정제에 대한 무관심과 반대 요인들 * 데이터 정재는 지루하고 시간이 오래 걸린다. 정제 활동은 벤더 도구들의 사용, 기업내부의 코드의 작성, 그리고 확인과 검사의 끈질긴 수작업들의 조합을 요구한다. 많은 회사들은 이 노력을 유지할 수 없다. 이것은 많은 IT 전문가들이 즐기는 종류의 작업이 아니다. * 많은 소스 시스템에 대한 메타데이터가 분실되었거나 존재하지 않는다. 문서화 없이 오손된 데이터를 조사한다는 것은 어렵거나 불가능하기조차 하다. * 데이터 품질을 확인하도록 되어 있는 사용자들은 많은 다른 업무 책임들을 맡고 있다. 데이터 품질이 아마도 최하위의 관심을 받을 것이다. * 때때로 데이터 정제 활동은 너무 엄청나고 도저히 맞설 수 없는 것처럼 보여서 회사들은 데이터 정제 발의(data cleansing initiative)에 착숙하는 것을 두려워 한다. 두 가지 접근 방법 * 100% 품질을 가진 데이터만 DW로 적재될 수 있다는 것. 데이터 품질 관점에서보면 이상적이나 모든 데이터가 적재를 위해 정화되기 전까지 매우 오랜 시간이 걸릴 것이다. * 진행하면서 적재하기(clean as you go). 일단 있는 그대로 DW에 적재하고나서 정제 작업을 수행. 데이터를 적제하지만 데이터가 정제되기 전까지는 어떠한 질의도 의심스러움 ===== 데이터 정제 결정 ===== 완전 무결한 데이터 품질이 현실 세계에서는 실제적이 아니라는 것을 깨닫고, 실제적이고 현실적이 되도록 해야한다. 목적에 대한 적합성(fitness for purpose)원리를 추구해야 한다. 목적에 대한 적합성(fitness for purpose) * 고객 상위 25명에 대한 정확한 판매 금액을 원한다면 데이터 품질은 우수해야 한다. * 고객 인구통계가 마케팅 캠페인에 대한 전망을 선택하는데 사용된다면 데이터 품질은 낮은 수준이 될 것이다. 정제의 기본적인 결정 * 어떤 데이터를 정제하는가? (which data to cleanse) * 어디에서 데이터를 정제하는가? (where to cleanse) * 어떻게 정제하는가? (how to cleanse) * 어떻게 데이터 오염의 정도를 발견하는가? (how to discover the extent of data pollution) * 데이터 품질 프레임워크 결정하기 (setting up a data quality framwork) ===== 누가 책임을 져야하는가? ===== * 데이터 소비자 - 질의, 보고서, 분석을 위한 DW를 사용. 데이터 품질을 받아들일 만한 수준들로 확립 * 데이터 생산자 - 소스 시스템들에 데이터 입력의 품질에 책임이 있다. * 데이터 전문가 - 소스 시스템들의 주제와 데이터 그 자체에 대한 전문가. 소스 시스템들에서 데이터 오염을 확인하는 책임 * 데이터 정책 관리자 - 데이터가 변환되어 DW로 옮겨감에 따라, 궁극적으로 데이터 훼손을 해결하는 책임 * 데이터 무결성 전문가 - 소스 시스템에서 데이터가 업무 규칙에 일치하는지를 보증하는 책임 * 데이터 교정 권위자 - 도구들이나 기업 내부 프로그램들을 통하여 실제적으로 데이터 정제 기법들을 적용하는 책임 * 데이터 일치성 전문가 - DW(다양한 DM) 안에 있는 모든 데이터가 완전히 일치하는지를 보증하는 책임 ===== 정화처리 ===== 모든 데이터 품질이 100% 수준이 될 때까지 DW의 적재를 보류한다는 것은 비현실적이다. 그렇다면 얼마나 많은 데이터를 당신은 정재하려고 시도하겠는가? 정화 처리(purification process)를 언제 멈추어야 하는가? 다시, 우리는 누가 데이터를 사용할 것이고, 어떤 목적으로 사용할 것인지에 관한 이슈들에 도달한다. 각 부정확한 데이터로 인한 손실과 위험들을 추정하라. 오류들이 심한 결과를 가져오지 않는다는 가정 하에, 사용자들은 보통 어느 정도의 오류들에 동의한다. 다음은 정화 처리의 내용 요약이다. * 데이터 품질의 중요성을 확립하라. * 데이터 품질 추진 위원회를 형성하라. * 데이터 품질 프레임워크를 만들라. * 역할들과 책임들을 부여하라. * 데이터 정화 처리를 도울 수 있는 도구들을 선택하라. * 필요한대로 기업 내부 프로그램을 준비하라. * 데이터 정제 기법들에서 참여자들을 훈련시켜라. * 데이터 표준들을 검토하고 거기에 일치시켜라. * 데이터를 높음, 중간, 낮음의 범주로 우선순위를 정하라. * 중복 레코드들을 교정하고, 외부 데이터를 감사할 기법들이 사용 가능하다는 것을 확인하라. * 정해진 스케줄에 따라 정화 처리를 진행하라. ===== 데이터 품질에 관한 실질적인 조언 ===== * 높은 영향혁의 오염 소스들을 확인하고, 이것들로부터 당신의 정화처리를 시작하라. * 모든 것을 기업 내부 프로그램들로 하려고 하지마라. * 도구들은 좋고 유용하다. 올바른 도구들을 선택하라. * 표준에 동의하고, 이것들을 재확인하라. * 데이터 품질을 특정 업무 목적들과 관련시켜라. 데이터 품질 작업, 그것만으로도 매력 있는 일이 아니다. * DW 프로젝트 팀의 고위 임원 후원자를 데이터 정화 발의를 지지하는데 적극적으로 관련시키도록 하라. * 사용자들 전체가 관여하도록 하고, 그들이 이 개발에 관해 끊임없이 계속 정보를 갖도록 하라. * 어디든지 필요한 곳에, 외부 전문가들을 특정 과제에 끌어들이도록 하라. ==== 참고자료 ==== * [http://www.ciobiz.co.kr/news/articleView.html?idxno=4084 BI 도입의 걸림돌은 데이터품질] * attachment:데이터품질-성공으로가는열쇠/DQ_Framework_Packet_v3.0.zip