물리 모델 이외에 또 다른 데이터 모델이 있다는 것을 아는가?

데이터 모델은 크게 개념 모델(Conceptual Model), 논리 모델(Logical Model), 물리 모델(Physical Model) 세 가지로 분류된다. 개념 모델과 논리 모델을 물리 데이터 모델을 만들기 위한 중간 단계의 산출물로 생각할 수도 있으나 사실은 각각 독립된 산출물로서 고유한 역할이 있다.

개념 데이터 모델은 모델링의 시작

개념 데이터 모델링은 데이터 모델의 첫 단계이다.

주로 고객과의 인터뷰 등을 통해 고객이 필요로 하는 요구사항을 수집, 분석해 데이터 모델의 전체적인 모양을 결정짓게 된다.

이 단계에서는 전체 모델에서 중요한 골격이 되는 엔터티(Entity)와 릴레이션십(Relationship) 위주로 모델링이 이뤄진다.

세부적인 속성이나 정확한 식별자는 이후 논리 모델링 단계에서 정해진다. 필요한 엔터티나 릴레이션십을 전부 도출할 필요는 없지만, 중요한 부분에 대해서는 개념적으로 명확하게 정의할 필요가 있다.

필자가 데이터 모델을 검증하는 작업을 수행하다 보면 개념 모델링을 업무 분석이 덜 된 상태에서 고객과의 구체적인 협의 없이 대강의 내용을 기술하는 단계 정도로만 생각하는 경우를 보게 된다.

하지만, 개념 모델링이 세부적인 내용을 정하지 않는다고 해서 명확하지 않은 내용을 채우고 방치해도 된다는 것은 아니다.

개념 모델의 가장 큰 목표는 프로젝트의 비즈니스적인 내용에 대해 고객과 모델러가 합의를 이루는 것이다.

예를 들어, 고객이 건축가에 의뢰해 집을 짓는다고 가정해 보자. 고객은 큰 거실과 조용한 서재가 있었으면 좋겠다는 식의 구조와 관련된 구체적인 요구를 할 수 있다.

또는 집이 따뜻했으면 좋겠다거나 어린 자녀들이 안전하게 지낼 수 있으면 좋겠다는 요구사항을 내놓을 수도있다. 건축가는 이에 맞춰 다양한 스타일의 스케치를 제시할 수 있다.

거실이나 서재의 대강의 모양을 보여줄 수도 있고, 난방과 안전을 위한 다양한 방법들을 제시할 수도 있다. 고객이 제시한 다양한 요구 중 수용하기 어렵거나 너무 많은 비용이 들어가는것에 대해서도 다른 대안을 제시할 수 있다. 훌륭한 건축가라면 고객이 요구하지 않은 사항 중 꼭 필요한 부분에 대해서는 먼저 제시할 수도 있다.

이 과정에서 고객은 자신이 지으려는 집의 모양이 원래 생각과 일치하는지를 미리 확인할 수 있다. 건축가는 각 창문이나 벽의 정확한 크기, 마룻바닥의 무늬, 벽지 색상을 정하진 않았지만 전체적인 집의 구조나 모양에 대해서는 명료하게 정의된 상태가 된다.

우리가 흔히 말하는 컨셉(Concept)이 정해진 상태가 되는 것이다.

이처럼 개념 모델은 무(無)에서 유(有)를 창조해내야 하며, 이런 이유로 초보 모델러나 비전문 모델러가 수행하기 어려운 단계이다.

경험이 많은 노련한 데이터 모델러의 경우 고객의 요구중 중요한 것과 그렇지 않은 것을 가려내는 일에 능숙하며 이것들을 어떻게 다뤄야 좋은 개념 모델을 만들 수 있는지를 알고 있다.

이런 방법들이 일정한 형태로 정리되면 이른바 데이터 모델 패턴(Data Model Pattern)이 된다. 이것은 프로그램 설계에 사용하는 디자인 패턴(Design Pattern)과 유사한 것이라고 생각하면 된다.

논리 데이터 모델을 이해하자

논리 데이터 모델은 개념 모델을 기반으로 논리적인 구성 요소를 빠짐없이 정의하는 단계이다. 여기서 '빠짐없이'라는 단어를 강조하는 것은 논리 모델에 대한 일반적인 오해 때문이다.

많은 사람들이 논리 모델에서는 주요 속성이나 식별자만을 정의하는 것으로 생각하는 경향이 있다. 좀 더 자세하고 정확한 것은 물리 데이터 모델 단계에서 정의한다고 생각하는 것은 논리 데이터 모델에 대한 잘못된 이해이다.

논리 모델링 단계에서는 모든 엔터티(테이블이 아니라), 관계, 속성, 식별자가 빠짐없이 정의되어야 한다. 즉, 비즈니스에 필요한 모든 내용이 명확히 정의되어야만 논리 모델이 완료되었다고 할 수 있다.

정의된 모든 내용들은 정규화(Normalization)라는 단계를 통해 정제된 상태여야 한다.

데이터 모델의 정규화가 완료되고 나면 전체 모델 내에 중복된 내용이 단 하나도 없게 된다. 논리 데이터 모델에 대해 개발자나 전산 담당자와 리뷰를 거치다 보면 반드시 나오는 질문이 하나 있다. 바로 하나 이상의 박스로 표현된 서브 타입의 처분에 대한 것이다.

예를 들어 고객 엔터티가 개인 고객과 기업 고객의 서브타입으로 이뤄진 경우 고객테이블 하나로 할 것인지, 개인과 기업 고객을 각각 별도로 분리된 2개의 테이블로 할 것인지, 또는 고객을 부모 테이블로 하고 개인 고객, 기업 고객 3개의 테이블로 할 것인지를 가장 궁금해한다.

이런 경우 필자가 할 수 있는 대답은 딱 하나이다.

"아직 고민할 단계가 아닙니다."

논리 모델링에서 비즈니스와 관련된 모든 내용을 빠짐없이 정의해야 하지만, 물리적인 내용과 관련된 어떠한 내용도 미리 정할 필요가 없다. 아니 미리 정하면 안 된다.

논리 단계에서 물리 단계를 고민하는 것은 아직 무엇을 할지도 정하지 않았는데 어떻게 할지를 결정하는 것과 같다.

구현이나 성능에 관련된 고민은 논리 데이터 모델에 불필요한 압박을 가하게 되고, 이로 인해 비즈니스를 제대로 표현하지 못하고, 데이터 모델의 유연성을 해치는 결과를 가져온다.

논리 모델은 물리적인 내용이 포함되지 않으므로 DBMS와 관련된 내용은 포함되지 않는 것이 정상이다.

예를 들어 특정 속성이 '50자 길이의 문자열'이라는 것은 정의될 수는 있지만 VARCHAR2(50)과 같이 특정 DBMS에 종속적인 데이터 타입으로 표현되어서는 안 된다는 것이다.

50자 길이 문자열은 DBMS나 기타 환경에 따라 가변 길이나 고정 길이 데이터 타입이 되거나, 서로 다른 데이터 타입으로 변환될 수도 있다. 때로는 데이터베이스에서 사용하는 CHARACTER SET에 따라서 다르게 정의될 수도 있다.

만일 논리 단계에서부터 물리 정보를 고정시켜 버리면, 차후에 DBMS 등이 변경될 때에는 논리 단계의 원래 의도를 이해하는 데 많은 어려움을 겪게 된다.

모델링의 마지막은 물리 모델이다

개념 모델을 거쳐 논리 모델까지 완료되면 고객의 비즈니스적인 요구사항은 모두 데이터 모델에 반영된 상태이다. 이제부터는 구현을 위한 물리적인 구성과 실제 구현을 위한 설계를 해야 할 물리 모델링 단계이다.

논리 단계를 충실히 이행했다면 여기서부터는 비즈니스적인 고민을 떨치고 기술적인 부분에 대해 충분히 고려할 수 있다.

위에서 고민했던 서브타입의 테이블 변환은 물론이고 엔터티를 일반 테이블로 변환할 수도 있고, Partition이나 Index Organized Table 등의 특수한 형태로 디자인할 수도 있다. 아직 개발이 진행되지 않은 상태이지만 Foreign Key 등을 참조해 다소의 인덱스를 추가할 필요도 있다.

간혹 여러 개의 DBMS에서 구현되어야 하는 솔루션 등의 경우 하나의 논리 모델에 여러 개의 물리 모델이 생성될 수도 있다. 이 경우 각 DBMS에 적합하게 물리화할 수 있으며 이 경우 순수한 논리 데이터 모델이 비즈니스의 기준으로서 큰 역할을 한다.

만일 데이터 모델의 변경 없이 해결할 수 없는 성능 문제가 발생하거나, 쿼리의 작성이 불가능할 정도로 복잡한 상황이라면 논리 모델을 기준으로 반정규화 작업을 수행해야 한다.

반정규화 작업은 가급적 최소화해 데이터 정합성이 훼손될 수 있는 가능성을 줄여야 한다. 또한 물리 모델에만 반정규화된 내용을 적용하고 논리 모델은 정규화된 상태를 유지해야만 원래의 비즈니스 정의가 유실되지 않는다.

개념-논리 모델링과 물리 모델링은 비슷하지만 서로 다른 영역임에 틀림없다.

IT 업계의 사정상 2명 또는 두 그룹의 모델러를 두기 어려운 현실로 인해 데이터 모델러가 논리와 물리 모델링 모두를 수행하는 경우가 대부분이다.

하지만 별도의 모델러도 없이 프로젝트를 진행하던 시절이 있던 것을 생각하면 몇 년 후에는 논리 모델러와 물리 모델러가 각각 전문화되는 때가 올 것으로 예상된다.

이제 우리는 개념, 논리, 물리 데이터 모델이 각각 서로 다른목표를 가지고 있음을 알 수 있다.

모델링을 수행하는 사람은 당연히 각 단계의 목표에 맞춰 데이터 모델링을 해야 할 것이며, 데이터 모델을 이용하는 DBA나 개발자는 물리 모델만을 보던 습관을 버리고 논리 모델을 통해 개발하려는 시스템의 비즈니스적인 관점을 이해해야 한다.

이 글이 그 계기가 되길 기대한다.