In Front of an Unfamiliar System
Quiz: terms and identifiers
한국어 원문으로 표시합니다.
회의에서 '활성 고객 수' 를 묻자 세 담당자가 3만 4천·3만 1천·2만 6천을 각각 답했다. 이 상황의 원인으로 가장 알맞은 것은?
- 세 시스템의 동기화가 늦어 같은 표의 숫자가 시점마다 달라진 것이다
- 세 시스템이 활성을 각자의 업무 기준으로 정의하고 있고, 한 낱말이 세 정의를 담고 있다
- 집계 쿼리 중 하나가 중복 행을 제거하지 않아 숫자가 부풀려진 것이다
- 고객 표의 기본키가 시스템마다 달라 조인에서 행이 누락된 것이다
용어-식별자 대조표를 만들 때 표와 칼럼만 적고 조건을 빼면 어떤 일이 생기는가?
- 같은 표를 쓰는 용어들을 구별할 수 없어 활성과 고객이 같은 줄이 된다
- 칼럼 이름이 시스템마다 달라 집계 도구가 대조표를 읽지 못한다
- 표의 행 수가 시점마다 달라져 대조표를 다시 만들어야 한다
- 식별자를 정규화할 기준이 사라져 겹침을 계산할 수 없게 된다
영업 시스템에는 User07@Example.com, 청구 시스템에는 user07@EXAMPLE.COM 이 들어 있다. RFC 5321 2.4 절을 따를 때 옳은 설명은?
- 도메인과 로컬 파트 모두 대소문자를 가리지 않으므로 두 주소는 같은 주소다
- 메일 주소는 전부 소문자로 정규화하도록 규격이 정하고 있으므로 두 주소는 같다
- 도메인은 대소문자를 가리지 않지만 로컬 파트는 가리므로 규격상 두 주소는 다르다
- 로컬 파트의 대소문자 구별은 구현에 맡겨져 있어 규격으로는 판단할 수 없다
식별자 정규화를 규격대로(도메인만 소문자) 하면 세 시스템의 고객 집합이 거의 겹치지 않고, 전부 소문자로 눕히면 거의 다 겹쳤다. 첫 주에 할 일로 가장 알맞은 것은?
- 규격이 정한 쪽이 옳으므로 규격대로 계산한 결과만 보고서에 싣는다
- 겹침이 크게 나오는 쪽이 현실에 가까우므로 전부 소문자로 눕힌 값만 쓴다
- 두 결과가 다르므로 이 데이터로는 결론을 내릴 수 없다고 보고하고 추가 추출을 요청한다
- 그 고객의 시스템이 실제로 어떻게 다루는지 확인해 규칙을 정하고, 정한 규칙을 문서에 적어 모든 집계에 똑같이 쓴다
두 집합의 자카드 계수가 0.0 으로 나왔다. 이 값이 뜻하는 것과 그다음 행동으로 알맞은 것은?
- 한쪽 집합이 비어 있다는 뜻이므로 추출 과정에서 데이터가 빠졌는지 먼저 확인한다
- 두 집합에 겹치는 원소가 없다는 뜻이고, 같은 이름을 쓰는 것이 위험하므로 다른 낱말로 부르자고 제안한다
- 두 집합의 크기가 크게 달라 비교가 무의미하다는 뜻이므로 크기를 맞춘 뒤 다시 잰다
- 식별자 정규화가 잘못됐다는 신호이므로 정규화 규칙을 바꿔 다시 계산한다
세 시스템의 활성 정의가 서로 다르다는 것을 확인했다. 첫 주에 권하는 대응은?
- 세 정의를 하나로 통일하는 변경을 설계해 다음 주 배포 일정에 넣는다
- 가장 넓은 정의를 표준으로 삼고 나머지 두 시스템의 집계를 그 기준으로 다시 계산한다
- 활성이라는 낱말을 회의에서 쓰지 못하게 하고 시스템 이름으로만 부르게 한다
- 보고서와 대시보드마다 어느 시스템의 어느 정의로 센 숫자인지 함께 적게 한다