대량의 대상을 수행하려면 전체적인 관점에서 접근해야 합니다.
그러므로 전체를 아우르는 틀을 갖춘 상태에서 표준화를 수행합니다.
아래는 데이터 표준화 프로젝트 수행 시 설계했던 리파지토리 테이블입니다.
리파지토리 (*리파지토리: 대상의 테이블 정보를 담는 저장소)
소량의 테이블은 정밀한 방법론이 없어도 괜찮습니다.
한 땀 한 땀 정성스럽게 단어/용어/도메인/코드를 정의하면 되니까요.
대량의 대상을 수행하려면 하나씩 수행하는 방법으로는 비용과 물량을 감당하기 어렵습니다.
그래서 대량의 대상은 방법론이 필요합니다.
대량의 대상 즉, 속성을 표준화하는 방법론을 구체적으로 설명겠습니다.
표준화 절차
표준화 절차
1. 분석 대상 수집
표준화의 결과물인 단어/용어의 재료가 되는 대상을 수집합니다.
가장 유력한 후보는 테이블이나 칼럼의 코멘트입니다.
이와 같은 정보를 딕셔너리 정보라고 합니다.
이러한 코멘트는 표준화가 안된 정보입니다.
하지만 단어나 용어를 만들어내는 매우 유용한 재료이니 최대한 수집해야 합니다.
그리고 업무 관련 문서도 중요한 단서가 될 수 있습니다.
표준화라는 것이 업무적으로 사용하는 단어나 용어로 구성되기 때문입니다.
가능하다면 업무 관련 문서도 수집합니다.
2. 형태소 분석
수집한 정보 목록은 다음과 같습니다.
- 테이블/칼럼 코멘트
- 업무 관련 문서
이제 위 대상으로부터 ‘단어’를 도출하기 위한 형태소를 분석합니다.
형태소를 국어사전에서는 ‘뜻을 가진 가장 작은 말의 단위’라고 정의합니다.
즉, 형태소 분석을 하면 ’단어’의 후보를 도출하게 됩니다.
재료가 많을수록 후보를 많이 도출할 수 있습니다.
그러므로 후보 중에서 쓸만한 단어를 선정하는 것이 매우 중요합니다.
이러한 판단이 품질의 차이를 만듭니다.
형태소 분석 예시
3. 단어 선정
쓸만한 단어를 선정하였다면 이제 용어에서 사용할 단어를 결정합니다.
이 단계에서는 유사한 단어들을 분류합니다.
예를 들면, ‘변경’, ‘수정’이라는 단어가 도출되었다고 가정하겠습니다.
이 두 개의 단어를 각각 인정할지 아니면 둘 중 하나만 인정할지를 결정합니다.
하지만 이후의 단계에서 죽었던 단어가 다시 살아날 수 있으니 실수를 너무 걱정 안 하셔도 됩니다!
단어 선정 예시
4. 용어 표준화
용어를 표준화하는 재료는 칼럼의 코멘트입니다.
테이블의 칼럼에 속성의 명칭과 정의를 작성하는 작업이 핵심 업무이기 때문입니다.
그런데 칼럼의 코멘트가 부실하거나 없다면 어떨까요?
이 질문에 대한 대답이 프로젝트의 성패를 좌우합니다.
왜냐하면 칼럼의 코멘트가 없이는 칼럼의 의미를 알 수 없기 때문입니다.
해당 테이블을 운영하는 담당자가 아닌 이상 정확한 의미를 파악하기는 어렵습니다.
그러므로 데이터 표준화 프로젝트에서는 칼럼의 코멘트를 고객사에 요구합니다.
칼럼의 코멘트가 성실히 기입된 만큼 품질은 올라갑니다.
그러므로 평소 칼럼의 코멘트를 채우는 것을 적극 권장합니다.
칼럼의 코멘트는 굳이 표준을 지키지 않아도 됩니다.
해당 칼럼이 어떤 역할을 하는지 이해할 수 있는 수준이면 충분합니다.
예를 들면, CUST_INV_ADDR 이라는 칼럼이 있다고 가정하겠습니다.
해당 칼럼에 ‘고객의 주소’로 코멘트를 입력하였다면 일반적으로 ‘고객주소’로 표준화합니다.
그런데 무언가 이상하지요? ‘INV’는 없어도 되는 건가요?
무언가 중요한 의미를 가진 약어일 텐데 코멘트에 정보가 없으니 누락될 수 있습니다.
그러므로 코멘트에는 ‘INV’를 표현하는 ‘청구’ 정도의 의미가 포함되어야 합니다.
‘고객의 청구지 주소’라고 코멘트에 기입되었다면 ‘고객청구지주소’로 누락된 정보 없이 표준화를 할 수 있습니다.
꼭 기억해 주십시오!
Good 코멘트는 Good 품질을 보장합니다!
속성 표준화 절차
5. 도메인 결정
경험상 가장 어려운 단계입니다.
기존에 어떤 표준도 없는 상태라면 난이도는 더욱 어려울 수밖에 없습니다.
동일한 의미의 속성을 어떤 테이블은 숫자로, 어떤 테이블은 문자로, 어떤 테이블은 날짜로 쓰고 있을지 모릅니다.
도메인을 결정할 때는 동일한 의미의 속성이라면 하나의 도메인을 부여해야 합니다.
그러므로 여러가지 데이터 타입과 길이를 쓰고 있는 상황이라면 단 하나의 도메인을 결정하기가 어렵습니다.
- 데이터 타입 우선순위 선정
여러 데이터 타입 중 우선순위를 결정해야 합니다.
우선순위는 절대적인 것이 아니라 고객사마다 다를 수 있습니다.
예를 들면 어떤 고객사는 날짜 타입을 DATETIME 보다 VARCHAR를 선호할 수 있습니다.
그러므로 고객사마다 우선순위가 다를 수 있다는 점을 감안하여 다음의 예시를 참고하시기 바랍니다.
데이터 타입 우선순위 예시
- 용어 도메인 후보 선정
동일한 용어의 타입이 여러 개인 경우 최적의 도메인을 선정합니다.
일반적으로 최적의 도메인이란 나머지 도메인을 아우르는 도메인을 말합니다.
예를 들어보겠습니다.
‘FAQ 제목 명’이라는 용어에 데이터 타입과 길이가 다양합니다.
VARCHAR(255), VARCHAR(100), VARCHAR(400) 세 가지의 데이터 타입과 길이가 있다고 가정하겠습니다.
‘FAQ 제목 명’에 적합한 데이터 타입과 길이는 무엇일까요?
네, 상식적으로 접근하면 답은 쉽게 찾을 수 있지요? VARCHAR(400) 입니다.
그림으로 표현하면 다음과 같습니다.
도메인 결정 예시
여러 데이터 타입과 길이를 사용하는 용어라면 위의 개념을 적용하여 최적의 도메인을 선정합니다.
고려 사항
여러 표준화 프로젝트를 수행하면서 유의해야 할 사항을 정리하면서 글을 마무리합니다.
참고 글:
동음이의어, 이음동의어, 한 글자 단어, 금칙어, 동의어/유사어 관리노하우
공공데이터 표준화 프로젝트- 최소 인원으로 수행해야 하는 이유
- 한 단어/복합단어 구성
- 한 단어 구성 용어는 의도한 의미인지 확인 필요
- 예) ‘구 명칭’ – ‘시군구’의 ‘구’인지 ‘OLD’의 ‘구’인지?
- 복합단어가 존재하는 경우는 가급적 복합단어 사용
- 예) ‘사원번호’ 복합단어가 있다면 ‘사원’ + ‘번호’보다는 ‘사원번호’ 사용
- 한 단어 구성 용어는 의도한 의미인지 확인 필요
- 단어 조합 순서 차이 대상
- 단어 조합 순서로 의미가 달라지지 않는다면 하나의 순서만 허용
- 예) ‘희망 배송 일자’, ‘배송 희망 일자’가 모두 동일한 의미라면 둘 중 하나만 표준으로 허용
- 주의) ‘계약 고객 번호’, ‘고객 계약 번호’가 ‘계약의 고객번호’와 ‘고객의 계약번호’로 의미가 다르다면 둘 다 표준으로 허용
- 단어 조합 순서로 의미가 달라지지 않는다면 하나의 순서만 허용
- 동음이의어 구성
- 용어 작성 시 실수를 줄이기 위해 동음이의어는 허용하지 않음
- 예) ‘구’ 단어 – ‘시군구’의 ‘구’인데 ‘OLD’의 ‘구’로 잘못 사용할 수 있음
- 용어 작성 시 실수를 줄이기 위해 동음이의어는 허용하지 않음
- 이음동의어 구성
- 가급적 이음동의어 중 하나만 허용하여 용어의 일관성 향상
- 예) ‘휴대전화’, ‘핸드폰’ 중 하나만 표준으로 허용
- 가급적 이음동의어 중 하나만 허용하여 용어의 일관성 향상
다음 글에서는 데이터 표준화 정말 필요한지 생각해 보겠습니다!
다음 글: 데이터 표준화를 꼭 해야만 하는 이유
