온톨로지 운영 노트 연작 3/4 · (1) 시스템이 바뀌어도 남아야 하는 데이터의 뜻 · (2) 봉제 전용 데이터 사전의 네 가지 작업 · (3) 키 없는 데이터베이스에서 의미를 찾는 방법 · (4) 의미 계층 위에서 AI가 답하게 하는 방법
핵심 요약
테이블 간 연결 정보가 없는 데이터베이스는 값의 포함 관계로 연결을 추론해 고객·매장·상품·운영 도메인으로 나눴습니다. 보고서 수식에 숨어 있던 계산 규칙은 꺼내서 고객에게 의미를 확인했고 이름은 같아 보이지만 갱신 규칙이 다른 컬럼은 정의를 따로 적었습니다. 시즌 분류, 폐점 매장 포함 여부, 확정 데이터와 잠정 데이터의 경계는 고객과 합의해 기록으로 남겼습니다.
한 패션 브랜드가 오래 써 온 ERP의 데이터베이스를 넘겨받았을 때, 처음 확인한 사실은 테이블끼리 이어 주는 연결 정보가 없다는 점이었습니다. 데이터베이스에는 수많은 테이블이 있었지만 어느 테이블의 어느 컬럼이 다른 테이블의 무엇을 가리키는지 적혀 있지 않았고 ERP 업체는 내부 로직을 공개하지 않아 화면에 보이는 숫자가 어떤 테이블 조합에서 나오는지도 알 수 없었습니다.
“이 데이터베이스로 매장별 판매 실적을 다시 계산할 수 있습니까?”
결론부터 말씀드리면 계산할 수 있었지만 그 전에 데이터의 뜻을 하나씩 복원하는 작업이 필요했습니다. 이번 글에서는 연결 정보가 없는 데이터베이스에서 의미를 찾은 네 가지 작업을 정리합니다. 이번 편은 이미 운영 중인 고객사 시스템에서 데이터의 정의를 거꾸로 찾아낸 과정입니다.
데이터베이스의 상태
작업 전 진단에서 확인한 상태는 다음과 같습니다.
| 진단 항목 | 확인한 상태 |
|---|---|
| 테이블 간 연결 정보 | 외래키 제약 조건이 없어 데이터베이스만으로는 조인 키를 알 수 없음 |
| 화면과 테이블의 대응 | ERP 내부 로직이 공개되지 않아 화면 숫자의 출처 테이블을 알 수 없음 |
| 스키마별 상태 | 계속 갱신되는 스키마와 오래전에 갱신이 멈춘 스키마가 섞여 있음 |
| 잔재 | 임시로 만든 테이블과 일괄 적재 흔적이 남아 있음 |
외래키(Foreign Key)는 한 테이블의 컬럼이 다른 테이블의 어느 행을 가리키는지 데이터베이스에 적어 두는 연결 정보입니다. 판매 테이블의 매장 코드 컬럼에 “이 값은 매장 테이블의 매장 코드를 가리킨다”는 외래키가 걸려 있으면, 사람이 설명하지 않아도 두 테이블의 관계를 알 수 있습니다. 이 정보가 없으면 테이블 사이의 관계를 사람이 따로 찾아야 합니다.
작업 1. 값의 포함 관계로 연결을 추론하기
연결 정보가 적혀 있지 않으면 데이터 값에서 찾아야 합니다. 이때 쓰는 방법이 포함 종속성(Inclusion Dependency) 분석입니다. 한 컬럼에 들어 있는 값이 모두 다른 컬럼의 값 목록 안에 들어 있으면, 앞 컬럼이 뒤 컬럼을 가리킨다고 추론하는 방법입니다.1
출석부에 비유하면 이해가 쉽습니다. 어느 수업의 과제 제출 명단에 적힌 학번이 모두 그 학교 학적부에 있다면, 제출 명단의 학번 칸은 학적부를 가리키는 칸이라고 볼 수 있습니다. 반대로 학적부에 없는 학번이 섞여 있으면 둘은 다른 체계이거나, 어느 한쪽 데이터에 오류가 있다는 뜻입니다.
판단 기준: 컬럼 A의 값 집합 ⊆ 컬럼 B의 값 집합
예시) 판매.매장코드 의 값이 모두 매장.매장코드 안에 있음
→ 판매.매장코드 는 매장.매장코드 를 가리키는 연결로 추론※ 테이블과 컬럼 이름은 설명용 예시입니다.
이 방식으로 추론한 연결을 따라 테이블을 묶자 고객, 매장, 상품, 운영 네 개 도메인이 드러났습니다. 지금 단계의 분류는 전체 테이블을 빠짐없이 나눈 결과이고 분석을 진행하면서 쓰지 않는 컬럼이 확인되면 그때마다 줄여 나가기로 고객과 정했습니다. 값이 우연히 겹치는 경우도 있으므로, 추론한 연결은 업무 담당자에게 확인받은 뒤에 확정합니다.
작업 2. 보고서 수식에 숨은 계산 규칙 꺼내기
연결을 찾은 다음에는 숫자가 어떻게 계산되는지 확인했습니다. 고객사가 쓰던 보고서 도구의 수식을 열어 보니, 확정 매출을 매장 유형에 따라 서로 다른 방식으로 만들고 있었습니다. 대부분의 매장은 판매 기록에 적힌 확정가를 그대로 쓰는데, 일부 온라인 판매 채널은 판매가에 고정 비율을 곱해 확정가를 따로 계산하고 있었습니다.
고객에게 확인해 보니 이유가 있었습니다. 해당 채널은 판매가만 등록되고 마진과 수수료가 입력되지 않아, 보고서에서 추정치를 임의로 만들어 쓰던 것이었습니다. 이 확정가는 유통 수수료와 공헌이익 계산에 그대로 이어지므로, 규칙을 모른 채 새 시스템에서 다시 계산하면 채널별 이익이 다르게 나옵니다.
이런 규칙은 1편에서 본 판단 규칙(SWRL) 형식으로 옮겨 적습니다.3
조건: 판매 채널 = 온라인 채널 그룹 그리고 마진 정보 = 없음
결론: 확정가 = 판매가 × 채널 추정 계수※ 규칙의 형식만 보여 주기 위한 예시입니다. 실제 계수는 적지 않습니다.
규칙을 문서로 꺼내 두면 두 가지가 달라집니다. 시스템을 바꿔도 같은 숫자를 다시 만들 수 있고 추정치로 계산된 매출과 실제 입력된 매출을 구분해서 볼 수 있습니다.
작업 3. 이름은 같아 보이지만 뜻이 다른 컬럼 정리하기
판매 기록에는 반품과 관련된 컬럼이 두 개 있었습니다. 하나는 거래가 판매인지 반품인지 가르는 판매 구분이고 다른 하나는 반품 여부 표시였습니다. 두 컬럼으로 반품 건수를 세자 서로 다른 숫자가 나왔습니다.
원인은 두 컬럼의 갱신 규칙에 있었습니다. 고객사의 설명에 따르면 반품 여부 표시는 판매 건이 나중에 반품되면 원래 판매 건 쪽에 Y가 찍히는 구분자였습니다. 원칙대로라면 반품 전표 자체에는 N이 남아야 하는데 수기 등록 과정에서 반품 전표에 Y가 찍힌 경우가 있었고 온라인 판매와 반품은 각각 따로 등록하는 방식이라 원래 판매 건의 표시가 갱신되지 않았습니다.
| 컬럼 | 실제 뜻 | 반품 건수로 쓸 때 주의할 점 |
|---|---|---|
| 판매 구분 | 해당 전표가 판매인지 반품인지 | 반품 전표의 수를 셀 때 기준으로 씀 |
| 반품 여부 | 원래 판매 건이 나중에 반품됐는지 | 수기 등록 오류와 온라인 채널의 미갱신이 섞여 있음 |
같은 진단에서 교환을 따로 구분하는 컬럼이 없다는 점과, 환불 사유 컬럼이 비어 있다는 점도 확인했습니다. 고객사는 전산상 교환을 별도로 구분하지 않고 판매와 반품으로만 관리했습니다. 이런 내용은 1편에서 본 속성 정의와 제약 조건으로 적어 둡니다.2 “반품 전표는 원래 판매 전표를 가리켜야 한다”는 제약을 걸어 두면, 연결이 끊긴 반품 기록을 자동으로 골라낼 수 있습니다.
작업 4. 분류와 범위를 고객과 합의하기
마지막은 데이터만 봐서는 답이 나오지 않는 질문을 고객과 정하는 일이었습니다.
| 질문 | 합의한 내용 | 온톨로지 기술 대응 |
|---|---|---|
| 시즌 값이 전 시즌으로 적힌 상품은 어디에 넣는가 | 시즌 대분류를 전 시즌(ALL), SS, FW로 따로 둠. 전체 = ALL + SS + FW | 분류 관계(isA) 설계 |
| 폐점한 매장의 과거 데이터를 AI 조회에 넣는가 | 포함함 | 인스턴스 포함 기준 |
| 언제까지의 데이터를 확정으로 보는가 | 이관 시점 기준 2개월 전까지의 월 단위 데이터를 확정분으로, 그 이후는 잠정분으로 봄 | 데이터 버전 관리 |
세 번째 기준이 필요했던 이유는 판매 데이터가 실시간으로 대사(맞춰 보기)되지 않는 구조였기 때문입니다. 판매 관련 데이터는 월 마감 전까지 바뀔 수 있으므로, 최근 두 달 치는 잠정 데이터로 두고 정합성을 다시 확인하기로 했습니다.
이 합의들은 회의에서 말로 끝내지 않고 기록으로 남깁니다. 같은 질문이 나왔을 때 누가 언제 무엇을 기준으로 정했는지 찾을 수 있어야, 담당자가 바뀌어도 숫자의 기준이 유지됩니다.
네 작업의 결과물
네 가지 작업이 끝나면 데이터베이스 바깥에 다음 문서가 남습니다.
| 작업 | 결과물 |
|---|---|
| 값의 포함 관계로 연결 추론 | 도메인별 테이블 연결 구조 |
| 숨은 계산 규칙 꺼내기 | 계산 규칙 문서 |
| 뜻이 다른 컬럼 정리 | 속성 정의와 제약 조건 |
| 분류와 범위 합의 | 분류 체계와 합의 기록 |
이 문서들이 1편에서 말한 의미 계층입니다. 다음 편에서는 이 의미 계층 위에 AI가 질문에 답하는 구조를 어떻게 만들었는지, 그리고 고객사가 ERP를 바꾸면서 생긴 연동 문제를 이 의미 계층으로 어떻게 다시 연결하는지 다룹니다.
👉 온톨로지 운영 노트 (4) : 의미 계층 위에서 AI가 답하게 하는 방법
봉제 생산 용어 노트
외래키(Foreign Key)
한 테이블의 컬럼이 다른 테이블의 어느 행을 가리키는지 데이터베이스에 적어 둔 연결 정보입니다.
포함 종속성(Inclusion Dependency)
한 컬럼의 값이 모두 다른 컬럼의 값 목록 안에 들어 있는 관계로, 연결 정보가 없을 때 테이블 간 연결을 추론하는 근거가 됩니다.
도메인(Domain)
업무상 같은 주제로 묶이는 테이블과 개념의 범위입니다(고객, 매장, 상품 등).
대사(Reconciliation)
서로 다른 기록의 숫자를 맞춰 보고 차이를 확인하는 작업입니다.
확정분 / 잠정분
더 이상 바뀌지 않는 마감된 데이터 / 마감 전이라 바뀔 수 있는 데이터입니다.
참고 자료
- Ziawasch Abedjan, Lukasz Golab, Felix Naumann, Profiling relational data: a survey, The VLDB Journal 24(4), 2015. 포함 종속성을 포함한 데이터 프로파일링 기법의 분류와 탐지 방법. ↩
- W3C, OWL 2 Web Ontology Language Primer (Second Edition), 2012. 클래스 계층과 제약 조건. ↩
- W3C, SWRL: A Semantic Web Rule Language Combining OWL and RuleML, W3C Member Submission, 2004. 조건과 결론으로 이루어진 규칙 표현. ↩
