-
데이터 모델링9 - 현실적인 논리 모델Data Base/관계형 데이터 모델링 2023. 9. 19. 13:04
개념 모델, 논리 모델, 물리 모델, 그리고 현실적인 논리 모델
본격적인 엔티티 모델링데 들어가기 전에 데이터 모델을 보는 3가지 관점인 개념 모델, 논리 모델, 물리 모델에 대해 좀 더 살펴보기 위해 모델링에서 다소 논쟁거리가 될 수 있는 주제 몇가지를 알아보자 이것에 대해 논의 하다 보면 자연 스럽게 이 모델들의 깊이를 이해하게 될 것이다.
3가지 모델의 교과서적 정리
'개념적'이라는 말의 뜻 때문에 오해할 여지가 있으나, 개념 모델은 개괄적이고 추상적인 모델이 아니다. 개념 모델은 모델을 상세화 하기 전에 1)주요 엔티티를 정의하고, 2)엔티티의 주 식별자와 주요 속성O(모든 속성X)까지 도출하여 3)엔티티 간의 관계까지 정리한 수준의 모델을 의미한다.
💡 tip) 목차의 존재이유
보고서나 책등 무언가에 대한 내용을 담고 있는 서술물에는 이를 간략화해서 목차화한 페이지가 간행물의 맨 앞페이지에 오기 마련이다. 이런 목차의 존재 이유는 복잡하고 상세한 내용은 나중에 보고 당장은 핵심적인 것을 파악하는 것을 용이 하게 하기 위함이다.개념 모델도 목차와 비슷하다. 개념 모델은 모델러에게 업무의 복잡도에 압도되지 않고 중요한 뼈대 부터 설계하고 구성할 수 있도록 해준다. 상세하고 복잡한 것들은 핵심적인 것들이 결정된 후로 미루는 도구 역할을 한다. 마치 일목요연하게 정리된 목차 처럼 이해관계 자에게 데이터 모델의 큰 틀(big picture)을 제공한다.
개념 모델은 구체적인 트랜잭션 관리를 위해 필요한 엔티티가 모두 도출되고, 엔티티에 정체성에 해당하는 주 식별자는 물론 엔티티 간의 관계가 지어진 구체적인 모델이다. 데이터 모델에서 핵심적인 것들은 모두 그려진 구체적인 모델이다. (상대적으로 논리모델 보다는 덜 구체적이다.) 개념 모델이 충실하게 나왔으면 데이터 모델리의 절반은 끝난 것이나 다름없다.
논리 모델은 개념 모델에 살을 붙여 더 상세화 한 것이다. 주요 엔티티뿐만 아니라 모든 엔티티와 개별 엔티티의 속성이 모두 도출된 가장 구체적이고 정규화된 모델이다.
개념 모델을 겨울 나무에 비유한다면, 논리 모델은 잎이 풍성한 여름 나무라고 할수 있다. 나무잎은 뿌리, 줄기, 가지가 없으면 존재 할 수 없기 때문이다.
물리 모델은 DBMS가 데이터를 담는 논리적구조이다. DBMS의 내부는 고도로 최적화된 형태로 데이터를 저장한다. 성능과 자원 효율성, 유지보수성, 보안 등 여러 복잡 난해한 문제들을 신경 쓰지 안고도 여전히 테이터 구조를 테이블 형태로 인식하고 사용할 수 있는 것이 바로 DBMS 덕분이다.
모델링 논쟁
1. 논리 모델에서 물리적 요소인 인덱스, 파티션, 클러스터 , 뷰 등을 고려하는 것은 적합하지 않다. 이런 물리적 요소는 데이터 구조에 종속적이며 대부분 성능과 밀접한 것이라 물리 모델 단계로 그 고김은 미뤄두는 것이 맞다. 논리 모델은 앞서 설명한 데이터 독립성 스티마 중 '개념 스키마'에 집중하는 단계다.
2. 그러나 데이터 모델의 전체 구조를 결정짓게되는 주요 엔티티에 관련된 대부분의 결정은 논리 모델 단계에서 해야한다. 주요 엔티티의 통합과 분리, 서브타입의 구현 등은 하위의 비지니스 트랜잭션 엔티티에 여향을 미치며 이에 대한 결정이 늦어질 수록 나중에 전체 구조를 변경해야 될 여지가 생기는 리스크가 증가한다. 따라서 성능에 이슈가 발생하는 것은 아니지만, 전체 구조에 영향을 미치는 요소들은 좀 더 일찍 구체 사항을 결정짓는 것이 짓는 것이 바람직하다.
3. 속성의 데이터 타입은 물리 모델 단계에서 정의해야 한다는 주장도 있지만, 논리 모델 단계에서 정의하는 것이 바람직한다. 데이터 타입과 데이터 길이 같은 것은 업무 규칙이라고 봐야하는것이 적절하기 때문이다.
데이터 모델링 마인드
그림 3-2 애플리케이션 화면에 보이는 데이터가 RDB에 저장되는 모습
위 그림은 앞선 게시물에 '애플리케이션의 화면과 RDB의 테이블은 다르다'에 대한 예시가 된 자료이다. 주문서는 사용자가 필요로 하는 형태(뷰)로 조직화된 하나의 집합체로 보이지만, 그 내부의 데이터 연관성을 고려하여 여러 테이블로 구조를 쪼개 놓은 그림이다.
그림 6-3 모든 속성을 한 테이블로 모든 주문서 엔티티
하나의 테이블에 모든 정보가 모여 있는 위 테이블에는 중대한 문제가 여럿 존재한다. 그 중 대표적인것 세 가지를 살펴보자
첫째, 나중에 주문서에 포함된 상품의 이름이 바뀌면 해당 상품과 관련된 주문서를 모두 찾아서 상품명을 수정해야 한다.
둘째, 주문을 단 한 번도 하지 않은 고객은 관리 자체가 불가능한다. 주문을 해야 주문서를 통해 고객의 정보가 들어올 수 있는 구조이기 때문이다.
셋째, 주문한 상품을 배송하려면 관련 애플리케이션은<주문배송주소>데이터를 참조해야 하는데, 주문서에 포함된 불필요한 다른 속성들 때문에 대량 주문 처리시 시스템 성능에 악영향을 줄 수 있다.
정보의 집합과 분할 측면에서 사례
사례1
배송 업무는 업무 처리의 효율을 위해 배송 주소가 인접한 주문서들을 그룹화 하기위해 수시로 배송주소를 탐색하기 마련이다. 그런데 모든 정보가 집합된 테이블은 배송에 대한 정보만을 분리된 테이블과 비교할 때, 배송 주소라는 한의 속성만을 조회할지라도 해당 속성을 담고 있는 하나의 개체(인스턴스)에 데이터 양이 많아서 성능에서 손해를 보게 된다. 이는 대다수의 DBMS에서 데이터의 읽고 쓰기는 메모리와 디스크를 분주히, 큰 볼륨으로 움직이게 하는 처리 과정을 수반하면,테이블의 행 단위로 저장된 블록을 읽고 쓰기 때문이다. 즉, 주문서 한 건에 포함된 열(속성)이 많아 주문서 한 행(개체)이 비대해지면 <주문배송주소>만 필요하더라도 같은 행의 나머지 속성도 쓸데없이 읽어야한다.
사례2
[그림 6-4]의 모델은 신용카드 회사에서 사용하는 카드원장(계약) 테이블에서 주소지와 사용 가능 금액을 업무 트랙재션 처리 방시 때문에 분리했다. 카드 쇠사라면 월별로 카드 사용내역을 집계해서 청구하는 일이 전체 시스템 설계에 큰 영향을 줄 것이다. 또한 매순간 발생하는 카드 사용 트랜잭션도 시스템에 많은 영향을 미칠 것이다.
그런데 이러한 두 업무 처리가 동시다발적으로 대량의 데이터에서 발생한다면 , 게다가 <카드원장>테이블이 [그림6-4]와 달리 청구서 발행을 위한 <카드주소지>와 카드 사용을 위한 <카드사용가능금액> 테이블로 분리되지 않고 하나의 테이블로 존재한다면 어떤 문제가 생길까?
서로 다른 트랜잭션이 동일한 블록을 읽고 쓰려하기 때문에 경합과 락lock이 발생하면서 업무는 지연될 것이다.
데이터 모델링은 앞서 언급한 첫째와 둘째 문제점에서 언급한 데이터 이상현상이 발생하지 않도록, 즉 정상적으로 관리할 수 있돌고 데이터의 저장 구조를 모델로 도식과하는 과정이다. 이때 데이터베이스가 최상의 선을을 내는 구조를 도출해야 한다. 모델링은 단순히 데이터의 저장구조를 그려내는 것이 아니다.
1)업무의 유형, 2)데이터 사이의 종속성, 3)업무 처리 방식 등을 고려하여 테이블을 쪼개는 것이 데이터 정규화다. 정규화를 통과한 데이터 모델은 앞선 데이터 이상 현상과 같은 문제점이 대부분 제거 된다.
최종 사용자가 보는 UI수준의 뷰에서 데이터 관련성을 중심으로 정보를 분리하는 사고방식과 안목을 키워야 한다.
[출처 - 프로젝트의 성패를 결정짓는 데이터 모델링 이야기 , 김상래 저]
'Data Base > 관계형 데이터 모델링' 카테고리의 다른 글
데이터 모델링11 - 정규화 이론(2정규화, 3정규화) (0) 2023.09.20 데이터 모델링 10 - 정규화 이론(1정규화) (0) 2023.09.19 데이터 모델링8 - 데이터 모델링은 2차원 표에 어떻게 데이터를 담을 것인지 고민하는 과정 (1) 2023.09.18 데이터 모델링7 - 범주화와 추상화 (0) 2023.09.18 데이터 모델링6 - 엔티티의 본질 (0) 2023.09.18