クイズ: 「なし」と「同じ」

같은 파일에서 평균 구매액이 46,000원과 57,500원 두 가지로 나왔다. 가장 그럴듯한 원인은?

• 한쪽이 통화 단위를 잘못 읽어 천원과 원을 섞어 계산했다
• 한쪽은 값이 없는 행을 0 으로 채워 전체 행으로 나눴고 다른 쪽은 그 행을 빼고 나눴다
• 한쪽이 중복 행을 제거하지 않아 같은 고객을 두 번 셌다
• 한쪽이 소수점 반올림 자리를 다르게 잡아 값이 벌어졌다

금액 칸에 0 이라고 적힌 행을 어떻게 다루는 것이 옳은가?

• 없음의 한 표기이므로 빈 칸과 똑같이 계산에서 뺀다
• 숫자이므로 아무 조건 없이 평균 계산에 넣는다
• 진짜 0 인지 채워 넣은 0 인지 파일만으로는 알 수 없으므로 건수를 따로 세어 보고하고 업무에 묻는다
• 중앙값으로 대체해 넣으면 분포가 유지되므로 그렇게 채운다

종료일 칸에 9999-12-31 이 섞여 있는 자료로 평균 처리 기간을 냈다. 무슨 일이 생기는가?

• 날짜 파싱이 실패해 예외가 나므로 곧바로 알아챌 수 있다
• 그 행이 자동으로 제외되어 평균에는 영향이 없다
• 몇 건만 섞여도 평균이 크게 부풀지만 오류가 나지 않아 눈에 띄지 않는다
• 날짜 차이가 음수가 되어 평균이 0 아래로 내려간다

중복 판정에서 '완전 중복' 과 '키 중복' 을 굳이 나누어 세는 이유는?

• 키 중복이 더 많아야 정상이므로 비율로 데이터 품질을 판정하기 위해서다
• 처리 방침이 다르기 때문이다. 앞의 것은 하나만 남기면 되고 뒤의 것은 어느 쪽이 맞는지 기계가 모른다
• 완전 중복은 저장 공간 문제이고 키 중복은 성능 문제이기 때문이다
• 완전 중복은 파서가 자동으로 걸러 주지만 키 중복은 SQL 로만 찾을 수 있기 때문이다

정규화한 뒤 이름이 같아진 두 행을 곧바로 병합하면 어떤 위험이 있는가?

• 정규화 함수가 느려져 전체 처리 시간이 크게 늘어난다
• 원본 파일이 덮어써져 되돌릴 수 없게 된다
• 정규화 결과가 실행마다 달라져 병합 결과가 재현되지 않는다
• 지점이 다르거나 상호가 우연히 같은 별개의 대상까지 한 대상으로 합쳐진다

전화번호 뒤 네 자리로 블록을 나눠 후보를 줄였다. 이 설계가 치르는 값은?

• 블록이 다른 두 행은 영원히 견주어지지 않으므로 번호가 바뀐 같은 고객을 놓친다
• 블록 안의 비교가 느려져 전수 비교보다 오래 걸린다
• 블록 키가 개인정보라서 그 자체로 반출 제한에 걸린다
• 블록 수가 늘수록 서로 다른 고객이 한 무리로 합쳐질 위험이 커진다