엔티티타입, 통합과 분리의 기준

엔티티 타입 어떻게 관리할까?

데이터 모델링을 하다보면, 여러 엔티티 타입 간의 관계가 도출 되고, 반대로 하나의 엔티티 타입 안에 비슷하지만 트랜잭션의 처리 패턴에 따라 다르게 처리되는 컬럼들이 뭉쳐져 설계되기도 한다

그러면 어떻게 해야 할가?

엔티티 타입의 통합과 분리도 단순하게 엔티티 타입의 모습 만을 보고 결정하는 것이 아니다
분석의 대상이 되는 업무 패턴은 먼저 이해하고 해당 업무에서 날아오는 트랜잭션의 패턴을 분석한 다음 엔티티 타입의 통합과 분리의 결정을 해야 한다

무조건 통합하지 말어라

엔티티 통합을 하면 일단 뭐가 좋을까?

복잡도가 낮아지고, 유지보수의 용이함이 생긴다

여기저기 비슷한 정보가 흩어져 있어 복잡해 보이는 데이터 모델을 단순하게 유도할 수 있고,
관리해야 할 테이블의 개수가 줄어들어 유지보수가 용이하다

정보가 한군데 집약 되어 있으므로 조인 발생을 최소화하여 성능 저하를 예방 할 수 있다

하지만, 모든 것은 Trade-off

반대로, 대량의 데이터가 한 군데 존재할 경우 트랜잭션의 집중 현상과 데이터량 증가로 인한 성능저하가 나타날 수 있다

1. 속성의 제약이 생겨 고유한 속성의 제약 조건을 걸지 못하거나, 고유한 컬럼 규칙을 지정하기 애매하다
2. 유연성도 떨어진다.
   1. 분리되어 있을 때 각 엔티티 별로 가질 수 있던 테이블 관계를 통합하면 관계가 모호해짐
   2. 정확한 관계를 설정 할 수 없게 되는 경우가 발생한다
3. 업무 이해도 저하
   1. 고유한 관계 해석이 안되므로 데이터 모델만을 보고 업무 파악에 어려움이 있다

엔티티 통합과 성능

확실히 엔티티 타입을 분리하였을 때 조인 관계가 증가해 성능 저하가 발생 할 수 있다
자주 사용 되는 쿼리가 Join을 남발한다면, 좋다고 할 수 없다

반대로, 엔티티 타입 통합으로 물리적 데이터가 집약 되고, 업무상 처리해야 하는 트랜잭션이 하나의 테이블로 집중 되는 현상이 생겨나 성능이 저하되는 문제가 발생 할 수 있다
트랜잭션 집중과 데이터 용량 증가는 성능 저하로 이어진다.

속성의 제약

속성의 제약이란, 데이터 모델링을 할 때, 엔티티 타입의 속성별로 각각이 가지는 고유한 특징에 따라 기본 값이나 Null 값에 대한 설정 그리고, Chek Constraint를 걸게 된다
이 때 2개 이상의 다른 유형의 엔티티 타입을 통합하면 각각이 가지는 고유한 속성의 제약 조건을 지정할 수 없게 된다.

즉 속성의 제약이 걸린다

프로젝트 업무 특성에 따라 컬럼에 제약 조건을 지정하는 부분은 향후 데이터를 무결성 있게 유지시키는 부분에서 상당히 중요하다

유연성과 업무 이해도

하나의 엔티티 타입은 다른 엔티티 타입과의 사이에서 여러 개의 관계가 발생 할 수 있다
각각의 관계는 업무적인 의미를 가지고 있으며, 업무적인 구성을 보여주거나 업무의 흐름을 표현해주는 데이터 모델의 혈맥과 같은 역할을 하게 된다

그런데 비슷한 유형의 엔티티 타입을 통합하게 되면, 이런 정확한 관계의 흐름이 데이터 모델 상에서 모호해질 수 있다
즉 PK 체계가 다르게 통합 될 경우 원래 가지고 있었던 관계를 설정할 수 없는 경우가 나타나게 된다

복잡도와 유지 보수성

데이터 모델에 많은 수의 관계가 있다는 것은 업무의 이해를 명확하게 하는 측명이 있지만, 관계가 복잡해질수도 있다

엔티티 타입이 너무 많아지면, 향후 유지보수를 할 때 테이블 개수가 많아져 관련된 인덱스, 뷰, 테이블 스페이스 등 오브젝트 증가에 따른 관리 포인트가 증가한다
즉, 유지보수하는데 에너지를 더 사용하게 도니다

통합과 분리의 기준, 그렇다면 어떻게 선정해야 하는가?

1. 상세 표현 단계 : 논리적 데이터 모델링 단계에서는 가능한 엔티티 타입을 상세하게 표현한다
2. 통합 고려 단계 : 물리적 데이터 모델링 단계에서 Trade-off(조인 성능 개선 vs 데이터 집약 성능 저하) 고려
3. 트랜잭션 고려 : 트랜잭션이 해당 엔티티 타입에 통합하여 발생하는지, 분리되어 발생하는지 (업무 패턴 고려)
4. 데이터량과 트랜잭션 빈도에 따른 결정 단계 :
   • 데이터 량과 트랜잭션 빈도가 많지 않은 경우 가급적 통합 된 데이터 모델을 구성하여 단순성을 확보한다
   • 데이터량과 트랜잭션 빈도가 많은 경우 : DB 성능을 고려하여 통합과 분리를 고려한다