이 글은 '관계형 데이터 모델링 프리미엄 가이드, 김기창 저' 책에 대한 공부 목적의 정리입니다.
1.1 데이터 모델링이 왜 어려운가.
1. 모델링은 데이터의 본질을 통찰해야 하는 추상적인 개념부터 DBMS의 구체적인 특징과 기능까지 알아야 제대로 수행할 수 있음
2. 0점짜리 모델링과 100점짜리 모델링은 존재하지 않지만, 10점에 가까운 모델링과 90점에 가까운 모델링은 존재한다. 그리고 우리는 90점에 가까운 모델링을 지향해야 한다.
1.2 데이터 모델링의 매력
데이터 모델링은 백지상태에서 시작해 데이터 구조가 생성되는, 즉 창작의 과정과 흡사하다는 점이다.
우리가 사랑하는 애인에게 글을 쓸 때도 지웠다 썻다를 반복하듯, 데이터 모델링 과정도 마찬가지이다.
데이터 모델링을 하는 과정에는 관련자에게 구조를 설명하고 논의한다. 이 과정에서 많은 업무 지식을 습득할 수 있다.
하지만 예전에는 데이터 모델이나 데이터베이스를 블랙박스 정도로 생각하는 경향이 컸다. 아무렇게나 집어넣고 아무렇게나 꺼내 와도 사용할 수만 있다면 된다는 식이었다. 하지만 지금은 그렇지 않다. 데이터 표준화에 대한 구축이 됨으로써 DA에 대한 수요가 늘어나고, 많은 프로젝트에서 DA를 채용하고 있으며, 이는 앞으로 더욱 늘어날 조짐이다.
EA(Enterprise Architecture)나 DQ(data Quality), 마스터 데이터, ISP(Information Strategic Planning), PI(Process Innocation)등과 같은 프로젝트에서도 데이터 전문가가 필요하다.
1.3 모델링은 상식적이다
모델링과 관련된 내용은 두 가지로 나눌 수 있다.
하나는 이론이고 하나는 경험이다
모델링 이론이 다른 분야와 비교해서 어렵지 않다고 느껴지는 것은 상식적이기 떄문이다. 이론은 상식적이지만 모델링을 하면 어렵게 느껴진다.
엔터티를 구성하는 기초는 어디까지나 이론에 근거하지만, 데이터의 정체성에 대한 판단이나 데이터를 통합하는 기준은 개인마다 다를 수 있고 이 부분을 경험이라고 말 하는 것이다.
데이터 모델링은 상식적인 이론이 토대가 돼야 하며 상식을 기반으로 한 경험이 축적돼야 좋은 모델을 만들 수 있다. 이론을 바탕으로 통찰력과 분석력, 경험이 조화를 이룬다면 데이터 모델링은 어렵지 않으며 상식적인 것이 된다.
1.5 좋은 모델은?
좋은 모델 = 단순하고 명확한 모델
명확한 모델 = 명확한 정의에서 비롯된다.
데이터 무결성이 보장되는 모델
1. 무결성이 훼손된 데이터는 비즈니스 요구사항을 충족한다 해도 좋은 모델이라 칭할 수 없다.
2. 중복 제거가 데이터 무결성 보장의 핵심이다.
성능이 보장되는 모델
1. 대개 원칙을 지켰을 때 성능이 따라오지만, 성능만을 고려해 모델을 구현해야 할 때도 존재한다.
2. 데이터 무결성을 다소 포기해야 하는 상황도 발생한다.
3. 사용자나 고객은 빠른 결과를 원하므로 성능을 무시한 모델은 좋은 모델이 아니다.
비즈니스를 효율적으로 표현한 모델
1. 비즈니스를 구행하는 데 필요한 데이터 요소들이 결여된 모델을 지양하고, 꼼꼼한 모델링이 필요하다.
표현이 정확한 모델
1. ERD의 표기법에 맞게 정확하게 표현돼야 좋은 모델
2. 이론적, 가독성 둘 다 챙겨야 한다.
사용자가 원하는 데이터를 정확하고 빠르게 보여줄 수 있는 단순한 모델
1.6 모델링의 필요성
개념, 논리, 물리 등의 모델링 단계 없이 데이터베이스에 스키마를 바로 생성할 수는 없다.
뼈대인 모델 구조는 그대로이며 속성 변경만 발생할 수 있도록 모델이 구축돼야 한다.
프로젝트가 클수록 구현 단계의 위험을 최소화 하기 위해 모델링이 필요하다.
1.7 좋은 모델러란?
1. 기술력
모델링의 이론을 깊게 알아야 한다.
RDBMS에 대해서도 깊게 알아야 한다.
RDBMS를 많이 아는것과 별개로 튜닝을 할 줄 알아야 한다.
2. 분석력, 설득력, 발표력
정확한 분석을 통해 모델의 기반이 되는 엔터티가 정의된다.
속성 하나의 쓰임새로 업무와 연관지을 수 있는 분석력이 없다면 좋은 모델러가 되기 어렵다.
자신이 구축한 모델을 많은 사람에게 설명해주고 이해시키면서 모델링을 수행해야 한다.
1.8 모델링 목표
1. 데이터의 무결성을 높이는 것이 모델링의 최우선 목표이다.
가장 큰 결점은 데이터 자체가 틀린 것이지만 데이터가 서로 일치하지 않는 것 또한 큰 결점이므로 데이터 중복을 제거해 정합성이 유지될 수 있도록 해야한다.
2. 중복 데이터가 없도록 하는 것
중복에는 두 가지 의미가 있다.
첫 번째는 데이터 값의 중복이다. 중복 속성, 중복 엔터티, 추출 속성 등이 중복 데이터 값을 관리하는 방법이다.
같은 값을 의미하면서 여기저기에 존재하면 데이터 정합성이 문제 될 수 있고 때에 따라서는 어떤 값이 맞는지 모르게 되는 근복적 문제가 일어날 수 있다.
두 번째는 유사한 속성이 여기저기에 사용 되는 것
예를 들어 고객의 이름을 관리하는 고객이름 속성이 개인고객/법인고객/사업자고객/외국인고객 등의 엔터티에 사용되면 모델 구조적으로 속성이 중복된 것이다.
고객이라는 엔터티 하나로 통합해 고객이름 속성은 하나만 사용되도록 하는 것이 바람직하낟.
중복을 제거하면 성능 문제가 발생할 수 있지만 (정규화를 한다고 해서 성능이 나빠지는 것은 아니다)
OLTP시스템에서 심각하게 성능을 고려해야 하는 예는 드물고 배치 작업과 관련된 성능 문제가 다소 발생한다.
생각보다 많은 성능 문제는 심각하지 않은 경향이 있어 지나치게 성능 문제에 매달리는 것도 바람직하지 않다.
모델이 어플리케이션에 종속되지 않아야 한다.
데이터 성격에 맞는 엔터티가 정의됐다면 애플리케이션이 수정됨에 따라 데이터 모델이 크게 바뀌는 일은 없다.
이것은 실제 내 사례인데, 이전에 근무했던 회사에서 새로운 서비스를 구축하는 경험이 있었는데, 기획안에 나온 퍼블리싱 페이지를 따라 엔터티를 구축하다 보니 페이지 명세가 바뀌거나, 페이지가 삭제되는 등의 변화가 있을 때마다 엔터티 자체를 수정해야 하는 경험이 빈번했고, 하나를 수정하면 연관된 다른 것들도 줄줄이 바뀌는 문제가 존재했다.
그렇기에 엔터티와 애플리케이션의 독립성은 상당히 중요한 것 같다.
엔터티를 강력하게 구축하고, 애플리케이션에는 뷰로 전달하는 과정을 통해서 엔터티의 변화를 최소화 할 수 있고 즉 독립성을 향상 시킬 수 있을 것 같다.