[데이터 모델링]DB 모델링 절차

데이터 모델링은 쉽게 말하면 현실의 사건들을 어떻게 체계적으로 DB에 넣을지 설계를 하는 것입니다.

 

기존의 DB에서 관계형DB로 넘어오면서 가장 중요한 개념은 정규화입니다. 복잡하게 생각할 것은 없고, 데이터의 중복이 일어나지 않도록 하는 것을 말합니다.

 

특정 개인의 전화번호를 여러 테이블에서 저장을 하고 있는데, 프로그램을 하면서 한 테이블에서만 전화번호를 수정하고 다른 테이블에서는 수정하지 않으면, 여러가지 혼란을 줄 것입니다. 그렇다고 어떤 테이블들을 수정해야되는지 일일이 기록을 남기고, 그것을 전부 수정한다고 한다면, 이 또한 유지보수와 확장에 많은 장애를 줍니다. 이러한 이유 때문에 관계형 DB로 넘어오게 되었고, 데이터 모델링은 그래서 정확히 관계형 DB를 설계하는 방법입니다.

 

만약 유지보수가 필요치 않다면, 굳이 복잡한 데이터 모델링을 하지 않아도 될지도 모릅니다. 오류없이 제대로 구축을 하고 더 추가적인 수정사항이 앞으로 영원히 나오지 않는다면 그냥 빠르게 결과만 나오게 하면 최고일 것입니다. 하지만, 유지보수, 추가 사항은 지속적으로 나오게 되어 있습니다.

 

객체지향모델링 뿐만 아니라 데이터 모델링도 이것이 필요한 가장 큰 이유는 바로 유지보수 생산성 때문입니다. 그리고 두번째가 성능입니다. 이를 위해 객체지향모델링에서 제일 중요한 것은 책임이라면, 데이터 모델링에서는 제일 중요한 것은 관계입니다.

 

데이타 모델링을 제대로 하려면, 프로그램에 대한 경험 뿐만 아니라 해당 업무에 대한 이해도가 높아야 합니다. 실제 구현과 운영과정에서 발생될만한 일들을 미리 예측을 하여서, 해당 업무의 담당자가 이야기 하지 않은 부분도 찾아내어서 질문을 던지고 할 수 있어야 합니다. 그러기 위해서는 많은 시행착오가 필요로 하겠죠.

 

너무 많은 확장성을 고려하여서 설계를 하면 성능이 문제가 되고, 필요없이 프로그램만 복잡해 질 수 있습니다. 또 너무 간단하게 만들면 업무 자체가 수행이 불가능해질 수도 있고, 수많은 수정사항과 부딪치게 될 가능성이 높습니다. 성능과 확장성에 조율을 하면서, 복잡도를 조절하여야 합니다.

 

데이타 모델링의 첫번째 절차는 업무를 꼼꼼히 파악하는 것입니다. 최대한 요구사항을 모두 적고, 관련된 개념들을 모두 적습니다.

 

두 번째 단계는 Entity와 속성을 구분하여서 정리를 합니다. 그러면서 Key 값을 무엇으로 할지 결정을 합니다.

 

세 번재 단계는 관계를 정리하는 것입니다. 1:1, 1:다, 다:다 의 관계를 정리를 합니다. 여기서도 추가적으로 꼭 필요로하는 것은지, 없어도 되는 것인지를 정리합니다.

 

네 번째 단계는 다:다 관계를 풀고, 여러가지 성능적인 부분을 고려해서 수정을 합니다. 다:다는 논리적으로는 가능하지만, 물리적으로는 불가능하기 때문에 풀어주어야 합니다.

 

 

실제로 예를 든다면, 다양한 회원들이 있는데, 회원별로 사이트의 특정 메뉴들이 보이거나, 접근이 가능하도록 하는 것을 만든다고 합시다. 요구사항을 물어보면 아마 이정도로 이야기를 하겠죠.

 

여기서 좀 더 나가면 메뉴는 몇 단계로 할 것인가를 추가적으로 질문을 할 수 있을 것입니다. 2단계로 한다고 하죠.

그럼 회원별로 모두 권한이 다른가? 아니면 몇 가지 그룹으로 나뉘는가? 즉 관리자, 일반회원 2단계면 되는가? 등을 질문을 할 수 있을 것입니다. 여러가지 관리자와 일반회원 뿐만 아니라 다양한 역할이 존재할 수 있으며, 회원들은 다양한 역할을 가질 수 있다고 합시다. 즉 관리자는 특정 메뉴별로 관리자가 될 수 있는데, 여러가지 권한을 동시에 가질 수 있다고 합시다.

 

그 다음으로 생각할 수 있는 질문은 권한의 종류가 다른가? 입니다. 읽기만 가능한가? 쓰기만 가능한가? 그런 것을 나눌 수 있겠죠. 여기서는 메뉴에 접근이 가능하면 모두 읽기, 쓰기가 가능을 하고, 권한이 필요로 하는 메뉴는 별도로 만든다고 합시다.

 

여기서 Entity 후보로는 회원, 메뉴, 역할로 뽑을 수 있습니다. 그럼 ERD를 다음과 같이 그릴 수 있습니다.

 

다음으로 속성들을 생각해서 채워넣을 수 있습니다. 그리고 각각 키 값을 정의합니다. 그 다음에 관계를 정의하는데, 회원은 다양한 역할을 가질 수 있으며, 역할을 담당하는 회원도 여럿 일 수 있으므로 다:다 관계가 됩니다. 그 다음 역할별로 다양한 메뉴를 가질 수 있으며, 어떤 메뉴를 사용할 수 있는 역할도 다양할 수도 있습니다. 그러므로 이것도 다:다 관계입니다. 메뉴는 1단계 메뉴가 밑에 여러 개의 2단계 메뉴를 가질 수 있으므로, 1:다의 관계이고 재귀적인 관계가 됩니다. 여기까지를 ERD로 그리면 다음과 같습니다.

 

 

 

ERWin을 많이들 사용해서 ERWin으로 저렇게 그렸는데, Encore의 DA#이 개인적으로 논리 모델링에는 더 나은 듯합니다. 재귀적인 관계도 보기 좋게 만들 수 있고, 각설하고 다:다는 프로그래밍을 할 수 없으므로 1:다로 풀어주어야 합니다. 회원이 다양한 역할을 수행하는 것으로 하여서 관계를 풀 수 있습니다. 특정 회원은 다양하게 수행을 할 수 있으며, 특정 역할을 다양하게 수행할 수 있으므로 아래와 같이 풀리게 됩니다. 역할과 메뉴의 관계도 권한으로는 개념으로 해서 다:다를 풀 수 있습니다. 메뉴에서 재귀적인 개념을 추가하려면 상위코드라는 값이 하나가 더 있어야 하겠죠. ERWin이 이 부분이 조금 아쉽습니다.

 

 

 

 

 

여기서 좀 더 복잡해지면 이력관리를 어떻게 할 것인가? 성능은 어떻게 풀 것인가? 정말 관계가 맞는가? 속성은 더 필요한가? 등등 하나하나 따지면서 전체적인 그림을 계속해서 수정을 해나갑니다. 이력관리 부분은 제대로 설명을 하려면 또 한참을 해야합니다. 다른 부분들은 경험이 필요로 합니다. DBA라면 실제 코딩단계에서의 성능은 고려하지 않겠지만, 프로그램 코딩 경험까지 있는 사람이면, 일정 부분 정규화를 포기하면서 코딩에서의 성능을 높이려고 하기도 합니다.