4 년 전에 어느 손해보험 회사에서 차세대 프로젝트를 진행할 때의 일이다. 갑자기 본사에서 전화가 와서 손해보험사의 직원이 프로젝트에 참여 중인 사람들이 엔코아 컨설팅 직원이 맞느냐고 확인하더라는 것이다. 무슨 일인가해서 그쪽 업무 담당자에게 문의해보니, 오라클 DBMS를 사용하면서 계약일자, 사고발생일자 등의 날짜 타입의 속성을 왜 Varchar2(8)을 사용 안하고, Date 타입을 사용하라는 말에 어이가 없어 엔코아 직원들이 맞는지 물었다는 것이다.
필자가 왜 날짜 타입의 속성을 Varchar2(8)을 사용해야 하냐고 물으니,
1) 본인은 이제까지 프로젝트를 하면서 Date 타입을 사용한 적이 한번도 없었고
2) 대용량 데이터베이스 솔루션 1에 Date 타입보다 Varchar2(8)이 Like 연산자를 사용하는데 유리하다고 쓰여 있으니 그렇게 사용해야 한다고 하면서, 이번 프로젝트에 들어온 엔코아 컨설팅의 컨설턴트들이 사장님 말씀도 안 들으니 엔코아 직원이 맞느냐는 것이고,
3) 대한민국은 날짜 타입을 보여주는 방식이 YYYY/MM/DD인데 오라클의 NLS Date 타입이 이것과 달라 날짜를 보여주기 위해서는 Format을 바꿔야 하므로, 이것이 코딩하는데 시간을 많이 잡아먹는다는 것이다.
이 글을 읽는 분들 중에도 위 답변이 당연한 거 아닌가라고 말할지 모르겠다. 그렇다면 이 이야기도 어떤가?
이전 어느 모은행의 프로젝트에서 중요 업무는 메인프레임 기반에서 계층형 DBMS를 사용하고, 일부 업무를 UNIX에 오라클을 사용했다. 어느 날 본사 직원이 데이터 타입이 안 맞는 속성을 발췌해 왔는데 A4 용지로 약 30장에 달하는 속성들이 데이터 타입이 맞지 않는 경우가 있었다. 사연인 즉, PMO 그룹에서 이 은행의 데이터 표준은 메인프레임의 계층형 DBMS가 표준이니 그것에 맞추라고 한 것 때문이었다. PMO 말을 잘 들은 일부 직원들은 오라클을 사용함에도 불구하고 데이터 타입을 계층형 DBMS의 데이터 타입을 사용했고, 반면 오라클을 잘 아는 일부 직원들은 오라클에서 제공하는 데이터 타입을 사용했기 때문에 이러한 일이 발생했던 것이다.
데이터 무결성이 업무 효율성으로 이어진다
관 계형 데이터베이스의 장점 중 하나는 무결성(Integrity)이라는 개념이다. 무결성이란 관계형 연산자를 이용해 데이터가 입력(Insert), 수정(Update), 삭제(Delete), 조회(Select)될 때 데이터 값이 정확성과 일관성을 가져야 되는 업무 규칙(Business Rule)을 말한다.
이러한 무결성 가운데 하나가 속성 무결성 또는 도메인(Domain) 무결성이라는 것이다. 도메인이란 관계형 테이블에 표현되는 속성이 취할 수 있는 값의 집합을 말한다. 예들 들어, 고객명 속성의 데이터 타입을 Varchar2(30)으로 정했다면, 30자리 내에서 문자 값으로 들어올 수 있는 모든 값의 집합이 고객명의 도메인인 것이고, 계약 일자를 Date 타입으로 잡았다면 이 세상에 존재하는 모든 날짜 값의 집합이 계약일자의 도메인인 것이다. 만약에 우리가 계약일자를 Varchar2(8)로 잡았다면 엄밀히 말해서 이는 8자리 내에서 모든 문자 값의 집합이 이 계약일자의 도메인인 것이다.
이러한 개념은 관계형 데이터베이스 이전에는 없던 개념으로 과거에는 모든 데이터의 무결성을 프로그램 로직으로만 해결했다. 프로그램 로직으로 이러한 것을 체크하다 보니 데이터 값이 안 맞아 고생한 경우가 가끔 있었을 것이다. E.F.CODD 박사는 이러한 문제를 해결하고자 DBMS 내에 무결성이라는 개념을 도입해 데이터의 정확성과 일관성을 유지하려고 했던 것이다.
도메인 무결성을 반드시 지켜야 하는 이유를 살펴보면,
첫째, 우리는 도메인을 보고서 의사 결정을 한다는 것이다.
다 시 말하지만 도메인은 속성이 취할 수 있는 모든 값의 집합이라고 했다. 예들 들어, 계약상태라는 속성이 취할 수 있는 값의 집합은 신청, 취소, 유지, 종결의 네 가지가 있다고 할 때, 이 네 가지가 이 속성의 도메인인 것이다. 계약일자는 업무 규칙에서 모든 날짜 집합이 도메인이 될 수 있지만, 계약상태는 업무 규칙에 의거해 이 네 가지 중에 하나만 선택할 수 있는 것이다. 보통 이런 코드 속성은 코드 도메인을 갖는다고 표현하다. 우리는 계약상태의 네 가지 도메인을 보고서 의사 결정을 할 수 있는 것이다.
둘째, 도메인의 중요성은 같은 도메인끼리 비교가 가능하다는 것이다.
현 실 세계에서 예들 들어 보면 형과 아우를 결정할 때 우리는 서로의 나이를 비교해서 결정한다. 나이와 고향을 비교할 수는 없다. 일본사람, 한국사람, 미국사람을 판단할 때는 국적을 가지고 비교하지 다른 어떤 속성으로 비교하지는 않을 것이다. 데이터 모델링에서 고객 테이블에서는 고객번호 속성을 Varchar2(10)로 하고, 계약 테이블에는 고객번호를 Number(10)로 한다면, 이는 비록 값이 같을지라도 DBMS는 다른 도메인으로 인식한다. 이런 경우, DBMS가 비교를 하기 위해서는 같은 도메인이어야 하기 때문에 두 개의 테이블을 조인하는 경우 한 쪽의 도메인(데이터 타입)을 내부에서 바꾼다. 이렇게 되는 경우 잘못하면 DBMS의 옵티마이져가 ACCESS PATH를 잃어버려 FULL TABLE SCAN을 하게 되어 수행속도상에 엄청난 비효율을 유발할 수 있는 것이다.
글 : 장희식_엔코아정보컨설팅 기술상무
금융(은행, 증권, 보험, 종금, 리스 등), 공공, 유통 등 많은 프로젝트에서 데이터 모델링 컨설턴트로써 역할을 수행해 왔으며, 정보 시스템 구현에 있어서 가장 중요한 업무 분석을 어떻게 하면 잘 할 수 있을까를 늘 고민하면서, 이러한 문제를 해결하는데 미력하나마 공헌하고자 데이터 모델링 책을 집필 중이다. 많은 프로젝트에서 고생 하고 있는 선배, 동료, 후배들에게 조금이나마 기여할 수 있는 컨설턴트가 되기를 기원하며 오늘도 프로젝트를 수행중이다.
