데이터이야기
DB 노하우, 데이터직무, 다양한 인터뷰를 만나보세요.
프로파일링이 뭔가요 프로파일링을 이야기하기에 앞서 데이터 품질진단 접근방법부터 이야기하려합니다. 데이터 품질진단은 단위 컬럼에서 시작해서 테이블, 데이터베이스, 시스템, 업무로 접근하는 상향식 방법과 업무에서부터 컬럼까지 내려가는 하향식 방법이 있습니다. 상향식 방법에는 프로파일링과 업무규칙으로 구분이 됩니다. 이번회에는 프로파일링에 대해서 알아보려 합니다. 이상으로 프로파일링의 테이블 단위에서 수행하는 유일성 측면의 중복 분석과 일관성 측면의 관계 분석에 대해 이야기 했습니다. 다음 회에서는 컬럼 단위에서 수행에 대한 이야기를 하려합니다. 위 내용과 관련하여 아래의 내용을 참고하시는 것도 좋을 듯 합니다. 감사합니다.프로파일링이 뭔가요
프로파일링이란 흔히 범죄 수사기법 중의 하나인 범죄유형분석법을 연상하기도 합니다. 범죄 현장을 분석해 범인의 습관, 나이, 성격, 직업, 범행 수법을 추론한 뒤 이를 바탕으로 범인을 찾아내는 수사 기법이며, 의료용어로서는 임상에서 장기장애의 종류, 합병증, 경과관찰, 예후판정의 목적으로 알고 싶은 정보를 검출할 수 있는 특징있는 검사법을 조합해서 검사 하는 것을 지칭하기도 합니다. 하지만, 여기에서는 데이터품질진단기법 중에 하나인 ‘데이터 프로파일링(이하 프로파일링)’에 대하여 이야기하도록 하겠습니다.
프로파일링이란 데이터 품질 측정 대상 데이터베이스의 데이터를 읽어 컬럼, 테이블의 데이터 현황정보를 통계적으로 분석하는 것을 의미합니다. 프로파일링을 통하여 오류 데이터 후보 선정과 업무규칙 대상 선정을 하게 됩니다. 프로파일링의 절차는 기준이 되는 메타데이터의 수집, 대상 컬럼, 테이블 선정, 프로파일링 수행, 결과 검토 및 확정의 순으로 진행하게 됩니다. 검토결과에 따라 오류 데이터 후보와 업무규칙을 선정하게 됩니다. 이 과정은 다음 회에서 상세하게 이야기하기로 하고, 프로파일링에 대해 이야기를 시작하겠습니다.
프로파일링은 테이블 단위와 컬럼 단위로 구분하게 됩니다. 이번 회에는 테이블 단위의 프로파일링에 대해서 이야기하려 합니다. 테이블 단위의 프로파일링에는 유일성 측면의 중복 분석과 일관성 측면의 관계분석이 있습니다.
첫번째, 유일성 측면의 중복 분석은 Primary Key(이하 PK) 를 기준으로 중복데이터가 있는지 분석하는 방법입니다. 쉽게 말씀드려서 PK를 기준으로 count를 했을 때 1보다 큰 데이터는 중복이라고 간주합니다. 실제 기관이나 기업에 가서 중복 분석을 해보면 예상외로 자주 발견이 되고 있습니다. 이유를 살펴보면 프로파일링 절차에 따라 메타데이터, Entity Relational Diagram(이하 ERD), 테이블 정의서를 기준으로 수행하게 되는데 업무에 변경에 따른 현행화가 되어 있지 않은 경우가 많았으며, 실제 PK가 정의 되어 있지 않은 경우도 있었습니다.
데이터가 중복되면 어떠한 일이 발생하는지 예를 들어 보겠습니다. 몇 년전 A기관에서 운영하는 시설관련 시스템 데이터를 프로파일링했었습니다. ERD와 테이블 정의서에는 FAC_ID와 SUB_FAC_ID는 복합키 구조로 되어 있었습니다. 유일성 측면의 중복 분석 프로파일링을 해보니, 복합키 구조로 되어있는 특정 데이터의 count가 1이 아닌 2가 나타나 해당 데이터를 확인해 보았습니다. 아래 그림은 테이블의 중복 데이터가 어떻게 들어 있었는지 알아보기 쉽게 재구성하였습니다. 원인은 과거 데이터를 대량 적재하는 과정에서 업무의 편의성을 위해 PK를 정의하지 않아 그 상태가 그대로 유지된 것이었으며, 입력단계에서 검증되지 않아 복합키가 중복으로 들어간 경우였습니다. 이로 인해 설비자재의 사용연한에 따른 교체시 서로 다른 장소에 위치한 두 가지의 구분이 불분명하여 모두 교체한 경우가 발생하였습니다. 고장이나 파손이 발생했을 경우 즉시 대응에 문제가 있으며, 더 큰 재해를 초래할 수도 있습니다. 물론, 당시 발견하고 오류 데이터에 해당하는 설비는 전수실사 및 검사를 통하여 바로잡았습니다.
두번째, 일관성 측면의 관계 분석은 참조무결성을 확인하는 방법입니다. 데이터 모델링 단계에서부터 참조무결성을 정의하도록 되어 있고, 메타데이터, ERD, 테이블 정의서에 정의되어 있습니다. 실제 기관이나 기업에서 참조무결성을 확인하는 관계분석을 수행하면, 의외로 부모 없는 자식이나 반드시 자식이 있어야 하는 부모가 자식이 없는 경우가 상당히 많이 발견되고 있습니다. 이유를 살펴보면 차세대나 신규 시스템 구축시 대량으로 데이터를 적재하는 과정에서 참조무결성을 감안하여 적재 순서를 조정하거나 검증을 해야하는데 과거 데이터의 경우 손대지 못하는 경우가 많으며, 적재의 편의성을 위해서 관계를 끊어 놓고 적재 후 다시 연결하지 못하는 경우가 대부분입니다. 드물게 응용프로그램상에서 데이터 삭제시 참조무결성을 감안하지 않고 해당 데이터만 삭제하는 경우에도 발생하기도 합니다.
데이터의 참조무결성이 유지되지 못하면 어떤 일이 발생하는지 예를 들어 보겠습니다. 몇 년전 B기관에서 운영하는 시스템을 프로파일링했었습니다. 일반적으로 마스터 데이터는 하나여야 하나 업무 단계별 특성과 시스템의 노후화로 성능이 보장되지 않아 아래 그림과 같이 구성되어 있었습니다. 그러다 보니 주 마스터와 각 업무별 마스터간 참조무결성이 유지되지 않을 뿐만 아니라 각 업무별 마스터에서는 업무를 수행하는데 필요한 데이터만 관리하며, 업무가 단계별로 이관되면 해당 데이터를 업무별 마스터에서만 삭제하고 관련 자식 데이터는 남겨 놓습니다. 그러다보니 각 업무별 마스터와 해당 업무별 상세내역 간에도 참조무결성이 유지되지 않습니다. 문제는 이렇게 되면 해당 K라는 데이터의 업무별 상세내역을 찾으려면 주 마스터와 해당 업무별 자식 데이터들을 대부분 참조하여야 합니다. 예전에는 그런 업무가 거의 없었으나 시대의 요구에 따라 업무들을 연결해서 봐야하는 등 계속 변하고 있습니다. 업무의 특성과 성능의 이슈로 인하여 당시에는 나름대로의 고민을 해결한 것처럼 보이나 참조무결성이 유지되지 않아 일관성 측면에서 재검증에 대한 더 많은 노력들이 필요하게 됩니다. 다행히 문제점을 인식하고 뒤이어 신규 구축하면서 하나의 마스터로 구성하고 참조일관성을 유지하여 관리하고 있습니다. 
참고)
＊ 데이터베이스품질인증 : http://www.dqc.or.kr
＊ DQ방법론>데이터 품질 가이드라인 : http://www.dqc.or.kr/guideline/4-0-0.html
＊ DQ방법론>데이터 품질진단 절차 및 기법 : http://www.dqc.or.kr/guideline/3-2-0.html