엔티티타입, 통합? 분리?

데이터 모델링을 하다보면 1:1관계 1:M 관계, M:M 관계를 통한 엔티티타 간에분리된 형태의 많은 엔티티타입들이 도출된다.

반대로 하나의 엔티티타입 안에 비슷하지만 트랜잭션의 ㅓ리 패턴에 따라 다르게 처리되는 컬럼들이 뭉쳐서 설계되는 경우도 있다.

통합과, 분리는 결정하는 기준은 무엇인가?

적절한 기준에 따라 엔티티타입의 통합과 분리를 결정하는 것은 전문적인 모델링을 전개하는 사람에게 매우 필요한 기술이다.

엔티티타입의 통합과 분리도 단순하게 엔티티타입의 모습만을 보고 결정하는 것이 아니다.

분석의 대상이 되는 업무 패턴을 먼저 이해하고 해당 업무에서 날아오는 트랜잭션의 패턴을 분석한 다음 엔티티타입의 통합과 분리를 결정해야 한다.

■ 무조건 통합하지 말라

통합을 하다보면 데이터 모델이 단순해지고 구축하면 많을 것 같았던 테이블의 개수가 줄어들어 관리하기가 편해진다.

그러나 시간이 흐르면 흐를수록, 해당 업뭉에서 아주 많은 트랙잭션이 발생하여 주요 테이블에 데이터가 집중되는 현상이 발생한다.

- 자주이용하는 트랜잭션이 한 테이블에 통합되어 있다 보니 모두 똑같이 참조해서 그렇다.

○특징

항목	효과	특징	고려요소
성능	성능 좋아짐, 성능 나빠짐	-장점 : 정보가 한군데 집약되어 있으므로 조인 발생을 최소화하여 성능이 향상될 수 있음 - 단점 : 대량의 데이터가 한 군데 존재할 경우 트랜잭션의 집중 현상과 데이터 량 증가로 인한 서능 저하가 나타날 수 있음	정보의 양이 대용량이거나, 트랜잭션이 집약된 정보에 집중될 것으로 옛아된다면엔티티타입 분리가 바람직함
속성제약	나빠짐	- 고유한 속성의 제약 조건을 걸지 못하는 현상이 발생함 - Default, Check Constraint, Null 등 고유한 컬럼 규칙을 지정하지 못하게 됨	애플리케이션에서 모두 체크 해야함
유연성	나빠짐	- 분리되어 있을 때 각각의 엔티티타입 별로 다른 엔티티타입과 가질 수 있는 관계를 통합하면 관계가 모호해지거나 정확한 관계를 설정할 수 없게 되는 경우가 발생함	논리적인 데이터 모델의 경우 유연성이 중요함
업무 이해도	나빠짐	- 고유한 관계의 해석이 안되므로 데이터 모델만을 보고 업무 파악에 어려움이 발생함	논리와 물리 데이터 모델을 구분하여 생성할 수 있음
복잡도	낮아짐	- 여기저기 비슷한 정보가 흩어져 있어 복잡해 보이는 데이터 모델을 단순하게 유도할 수 있음
유지 보수성	좋아짐	- 관리해야 할 테이블의 개수가 줄어들어 유지보수가 용이해짐

엔티티타입을 통합하든 분리하든 데이터베이스에서 성능을 처리하는 데 있어 항상 성능 저하 요인이 있음을 우선은 인지해야함.

이를 고려한뒤 어떻게 하는 것이 효과적인 통합과 분리의 방법인지 알아야 함

트랜잭션 양이 적고 해당 테이블에 저장되는 데이터가 많지 않으면  통합이든 분리든 성능에 크게 영향을 미치지 않는다.

데이터량이 만ㅇ흘 때는 통합과 분리가 성능에 영향을 미치므로 해당 테이블에 발생하는 트랜잭션의 특성을 보고 판단 해야한다.

■ 속성의 제약

데이터 모델링을 할 때 엔티티타입의 속성별로 각각이 가지는 고유한 특징에 따라 Default, Null에 대한 설정, 그리고 Check Constraint를 걸게되는데 이때 두 개 이상의 다른 유형의 엔티티타입을 통합하면 각각이 가지는 고유한 속성의 제약 조건을 지정할 수 없게 되는 성질을 가지는 것을 속성제약이 걸린다고 표현한다.

■ 유연성과 업무 이해도

엔티티가 가지는 관계는 업무적인 의미를 가지고 있으며, 업무적인 구성을 보여주거나 업무의 흐름을 표현해주는 데이터 모델의 혈맥과 같은 역활을 하게 됨.

비슷한 유형의 엔티티타입을 통합하게 되면 이런 정확한 관계의 흐름이 데이터 모델 상에서 모호해줄 수 있으며 PK체계가 다르게 토압횔 경우 원래 가지고 있었던 관계를 설정 할 수 없는 경우가 발생하게 된다.

업무적인 의미를 명확하게 하기 위한 논리적인 데이터 모델 단계에서는 가급적 엔티티타입을 독립적 의미가 명확한 분리된 형식의 데이터 모델을 권장하고, 물리적인 데이터 모델의 경우는 트랜잭션의 성격에 따라 성능저하를 예방하기 위해 엔티티타입을 통합을 고려해야 한다는 말은 이런  특징 때문에 나오게 된다.

■ 복잡도와 유지보수성

데이터 모델에 많은 수의 관계가 있다는 것은 업무의 이해를 명확하게 하는 측면이 있지만, 관계가 거미줄 같이 엉켜버리면 데이터 모델이 너무 복잡해질 수도 있다,

데이터 모델을 단순하게 설계하여 전체적인 복잡도를 감소시키고, 유지보수 시점에 관리 포인트를 감소 시킬 수 있는 방안을 모색하는것도 하나의 방법이다.

■ 통합과 분리, 선택의 기준

프로젝트 수행 중에는 분석 단계와 설계 단계가 구분되는 경우가 많으므로 논리적 데이터 모델과 물리적 데이터 모델의 특징에 따라 엔티티타입의 통합과 분리를 가져가는 것이 좋다.

- 상세 표현 단계 : 논리적 데이터 모델링 단계에서는 가능한 엔티티타입을 상세하게 표현

- 통합 고려 단계 : 물리적 데이터 모델링 단계에서는 성능을 고려하여 데이터 모델 통합을 유도하되 성능의 Trade Off 를 분석하여 통합과 분리르 결정한다.

- 트랜잭션 고려 단계 : 트랜잭션이 해당 엔티티타입에 통합하여 발생하는지 분리되어 발생하는지를 분석하고 업무적 중요성을 갖는 트랜잭션의 발생 패턴에 따라 통합과 분리를 결정한다.

- 데이터량과 트랜잭션 빈도에 따른 결정 단계 : 데이터량과 트랜잭션 빈도가 많지 않은 경우 가급적 통합된 데이터 모델을 구성하여 단순성을 확보한다. 데이터량과 트랜잭션 빈도가 많은 경우 데이터베이스 성능을 충분히 고려하여 통합과 분리를 결정.

데이터 모델링을 진행 할 경우 통합과 분리를 어떻게 하는지에 따라

유지보수및, 활동에도 많은 영향을 끼칠 수 있다.