창고의 데이터 품질

웨어하우스에 있는 데이터의 품질은 귀중한 정보를 얻기 위한 중요한 전제 조건입니다. 품질이 좋지 않으면 장기적으로 부정적인 연쇄 반응이 발생합니다.
첫째, 제공된 정보에 대한 신뢰가 상실됩니다. 사람들은 비즈니스 인텔리전스 응용 프로그램을 덜 사용하기 시작했으며 응용 프로그램의 잠재력은 여전히 ​​활용되지 않고 있습니다.
결과적으로 분석 프로젝트에 대한 추가 투자에 의문이 제기됩니다.

데이터 품질에 대한 책임

BI 프로젝트에서는 데이터 품질 향상과 관련된 측면이 매우 중요합니다. 그러나 이는 기술 전문가만의 특권이 아닙니다.
데이터 품질은 다음과 같은 측면에도 영향을 받습니다.

기업 문화

• 근로자 자신이 좋은 품질을 생산하는 데 관심이 있습니까?
• 그렇지 않다면 왜 안 됩니까? 이해상충이 있을 수 있습니다.
• 품질 책임자를 결정하는 기업 규칙이 있을까요?

프로세스

• 이 체인의 끝에서는 어떤 데이터가 생성되나요?
• 아마도 운영 체제는 현실에서 특정 상황을 반영하기 위해 "비틀어"야 하는 방식으로 구성되었을 수 있습니다.
• 운영 체제가 데이터 확인 및 조정을 자체적으로 수행합니까?

조직의 모든 사람은 보고 시스템의 데이터 품질에 대한 책임이 있습니다.

정의와 의미

품질은 고객 기대에 대한 입증된 만족입니다.

그러나 데이터 품질에는 정의가 포함되어 있지 않습니다. 이는 항상 사용 상황을 반영합니다. 데이터 웨어하우스와 BI 시스템은 데이터가 나오는 운영 체제와 다른 용도로 사용됩니다.

예를 들어 운영 체제에서는 고객 속성이 선택적 필드일 수 있습니다. 저장소에서 이 속성은 차원으로 사용될 수 있으며 해당 속성을 채워야 합니다. 결과적으로 기본값을 입력해야 합니다.

데이터 스토리지 요구 사항은 지속적으로 변화하며 일반적으로 운영 체제 요구 사항보다 높습니다. 그러나 운영 체제의 세부 정보를 스토리지에 저장할 필요가 없는 경우에는 그 반대일 수도 있습니다.

데이터 품질을 측정 가능하게 만들려면 해당 표준을 설명해야 합니다. 업무에 정보와 수치를 활용하는 사람들이 기술 과정에 참여해야 합니다. 이러한 개입의 결과는 오류가 있는지 여부를 표를 통해 한눈에 알 수 있는 규칙이 될 수 있습니다. 이 규칙은 후속 확인을 위해 스크립트/코드 형식으로 지정되어야 합니다.

데이터 품질 개선

데이터를 웨어하우스에 로드하는 과정에서 모든 가상 오류를 정리하고 수정하는 것은 불가능합니다. 좋은 데이터 품질은 모든 참가자 간의 긴밀한 협력을 통해서만 달성될 수 있습니다. 운영 체제에 데이터를 입력하는 사람들은 어떤 작업이 오류로 이어지는지 알아야 합니다.

데이터 품질은 프로세스입니다. 불행하게도 많은 조직에는 지속적인 개선을 위한 전략이 없습니다. 많은 사람들이 데이터 저장에만 국한하고 분석 시스템의 잠재력을 최대한 활용하지 않습니다. 일반적으로 데이터 웨어하우스를 개발할 때 예산의 70~80%가 데이터 통합 ​​구현에 사용됩니다. 모니터링 및 개선 프로세스는 전혀 불완전한 상태로 유지됩니다.

도구

소프트웨어 도구를 사용하면 데이터 품질 개선 및 모니터링 프로세스를 자동화하는 데 도움이 될 수 있습니다. 예를 들어 필드 형식, 기본값 존재, 테이블 필드 이름 준수 등 스토리지 구조의 기술적 검증을 완전히 자동화할 수 있습니다.

내용 확인이 더 어려울 수 있습니다. 스토리지 요구 사항이 변경되면 데이터 해석도 변경될 수 있습니다. 도구 자체는 지원이 필요한 거대한 프로젝트가 될 수 있습니다.

이사회

일반적으로 매장을 설계하는 관계형 데이터베이스에는 뷰를 생성하는 놀라운 기능이 있습니다. 내용의 구체적인 내용을 알면 빠르게 데이터를 확인할 수 있습니다. 데이터에서 오류나 문제점을 발견한 각 사례는 데이터베이스 쿼리 형식으로 기록될 수 있습니다.

이런 방식으로 콘텐츠에 대한 지식 기반이 형성됩니다. 물론 그러한 요청은 빨라야 합니다. 뷰는 일반적으로 테이블 기반 도구보다 유지 관리하는 데 더 적은 시간이 필요합니다. 뷰는 항상 테스트 결과를 표시할 준비가 되어 있습니다.
중요한 보고서의 경우 보기에는 수신자가 포함된 열이 포함될 수 있습니다. 동일한 BI 도구를 사용하여 웨어하우스의 데이터 품질 상태를 보고하는 것이 합리적입니다.

예

쿼리는 Oracle 데이터베이스에 대해 작성되었습니다. 이 예에서 테스트는 원하는 대로 해석될 수 있는 숫자 값을 반환합니다. T_MIN 및 T_MAX 값을 사용하여 경보 수준을 조정할 수 있습니다. REPORT 필드는 이메일을 올바르게 보내는 방법을 모르는 상업용 ETL 제품에서 메시지로 사용되었으므로 rpad는 "버팀목"입니다.

큰 테이블의 경우 예를 들어 AND ROWNUM <= 10을 추가할 수 있습니다. 10개의 오류가 있으면 경보가 발생하기에 충분합니다.

CREATE OR REPLACE VIEW V_QC_DIM_PRODUCT_01 AS
SELECT
  CASE WHEN OUTPUT>=T_MIN AND OUTPUT<=T_MAX
  THEN 'OK' ELSE 'ERROR' END AS RESULT,
  DESCRIPTION,
  TABLE_NAME, 
  OUTPUT, 
  T_MIN,
  T_MAX,
  rpad(DESCRIPTION,60,' ') || rpad(OUTPUT,8,' ') || rpad(T_MIN,8,' ') || rpad(T_MAX,8,' ') AS REPORT
FROM (-- Test itself
  SELECT
    'DIM_PRODUCT' AS TABLE_NAME,
    'Count of blanks' AS DESCRIPTION,
    COUNT(*) AS OUTPUT,
    0 AS T_MIN,
    10 AS T_MAX
  FROM DIM_PRODUCT
  WHERE DIM_PRODUCT_ID != -1 -- not default value
  AND ATTRIBUTE IS NULL ); -- count blanks

출판물은 책의 자료를 사용합니다.
로널드 바흐만 박사 귀도 켐퍼
Raus aus der BI-Falle
Wie Business Intelligence zum Erfolg wird

출처 : habr.com