[데이터베이스] 아는만큼 보이는 데이터베이스(4) - 엔티티타입 통합/분리 선택

엔티티타입, 통합할 것인가/분리할 것인가

---

It시스템의 패러다임 정보시스템 초기에는 개별 파일에 대해 처리하는 분리로부터 출발했다가 메인프레임 환경으로 모든 정보와 자원들이 집약적으로 한군데서 처리되는 통합의 개념으로 발전했습니다. 이후 오픈 환경의 C/S환경으로 시스템이 내려가면서 다시 분리의 개념으로 적용했다가 웹환경의 인터페이스를 적용하게 되면서부터 다시 통합된 흐름으로 시스템이 모여드는 통합과 분리의 순환현상을 보이고 있습니다.

데이터 모델링을 하다보면 1:1관계, M:M관계, 1:M관계를 통한 엔티티타입 간의 분리된 형태의 많은 엔티티타입들이 도출됩니다. 반대로 하나의 엔티티타입 안에 비슷하지만 트랜잭션의 처리 패턴에 따라 다르게 처리되는 컬럼들이 뭉쳐서 설계되는 경우도 있습니다. 

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

* 무조건 통합하지 마라

많은 구성에 대해 엔티티타입을 통합한다면 데이터모델이 단순해지고 구축하면 많을것 같았던 테이블의 개수가 줄어들어 관리하기가 편리하다고 판단할 수 있습니다. 그러나 시스템구축이 끝나고 1년 정도의 시간이 지났을때 해당 업무에서 아주 많은 트랜잭션이 발생하여 주요 테이블의 데이터가 집중되는 현상이 발생하게 될 수 있습니다.

동일한 테이블에 트랜잭션이 집중되면 성능이 느려질 수 있습니다. 이른바 블록에서 순차적으로 데이터를 처리할 수 있도록 하는 옵션이 있는데, 특정 블록에 트랜잭션이 집중되면 Hot Block 발생으로 Waiting이 발생할 수 있습니다. 또한 동일 자원을 여러 트랜잭션에서 사용하려 하면 Lock, Latch 등 자원을 이용하려는 이벤트가 많아져 대기현상을 피할 수가 없습니다.

비슷한 유형의 테이블들에 많은 트랜잭션이 집중될 것으로 예상되면 미리 테이블을 분리하여 집중되는 트랜잭션을 분산할 수 있도록 설계하는 것이 좋습니다.

* 엔티티 통합의 장단점

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

* 엔티티타입 통합과 성능

엔티티타입이 통합된 유형에서 성능은 정보를 집약적으로 조회함으로써 향상될 수 있습니다. 물리적으로 데이터가 집약되고 업무상 처리해야하는 트랜잭션이 하나의 테이블로 집중되는 현상이 생겨나 성능이 저하되는 문제가 발생할 수도 있습니다.

트랜잭션 집중과 용량 증가에 따른 데이터 집중에 의한 성능저하 현상이 발생 가능합니다.

엔티티타입을 통합하든 분리하는 데이터베이스에서 성능을 처리하는데 있어 항상 성능 저하 요인이 있음을 인지하고 있어야 합니다. 이를 고려했을때 어떻게 하는 것이 효과적인 통합과 분리의 방법인지 알아야하는데 이에대한 가이드는 아래와 같습니다.

먼저 트랜잭션 양이 적고 해당 테이블에 저장되는 데이터가 많지 않으면 통합이든 분리든 성능에 크게 영향을 미치지 않습니다. 다만, 속성의 제약사항이나 데이터모델의 유연성 측면에서 문제가 되기때문에 이 두가지를 기준삼아 엔티티타입의 통합과 분리를 결정하면 됩니다.

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

  → 트랜잭션이 특정 테이블의 일정한 컬럼군에 집중될 것으로 예상되면 1:1 관계로 모델링

반대로 분리되어있는 테이블에서 데이터를 처리할때 항상 같이 처리하는 경우가 예상되면 엔티티타입을 통합하여 설계하는 것이 성능상 유리합니다.

  → 전체 컬럼에 대해 트랜잭션이 일괄 처리되는 경우가 많으면 하나로 통합하여 설계

막상 실전 프로젝트에서 데이터 모델링을 전개할때는 판단이 쉽지 않습니다. 그 이유는 엔티티 타입의 통합과 분리에 대한 명확한 기준이 없기 때문입니다.

* 속성의 제약

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

  → 독립되어 있을때는 컬럼에 Not Null 지정이 가능했으나 통합되고 나면 Not Null을 지정할 수 없게 됩니다.

프로젝트 업무 특성에 따라 컬럼의 제약 조건을 지정하는 부분은 향후 데이터를 무결성있게 유지시키는 부분에서 상당히 중요한 의미를 가집니다. 따라서 상기 제약 조건에 대한 지정을 가능하게 하는 모델이 좋습니다. 속성에 대한 제약 조건을 명확하게 지정해야 하는 중요한 데이터값을 입력해야 한다면, 가급적 개별적으로 엔티티타입을 유지시키는 모델로 데이터모델을 만들어가는 것이 좋습니다.

* 유연성과 업무 이해도

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

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

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

* 복잡도와 유지보수성

데이터 모델에 많은 수의 관계가 있다는 것은 업무의 이해를 명확히 하는 측면이 있지만, 관계가 거미줄같이 엉켜버리면 데이터 모델이 너무 복잡해질 수 있습니다. 또한 엔티티타입이 너무 많아지면 향후 유지보수를 할때 테이블 개수가 많아져 관련된 인덱스, 뷰, 테이블 스페이스 등 오브젝트 증가에 따른 관리포인트가 증가하므로 유지보수성이 저하될 수 있습니다.

이러한 측면을 고려하면 데이터 모델을 단순하게 설계하여 전체적인 복잡도를 감소시키고 유지보수 시점의 관리포인트를 감소시킬 수 있는 방안을 선택하는 것도 하나의 방법이 됩니다.

비슷한 유형의 엔티티타입이 분리되면 복잡성이 증가하고 엔티티타입이 통합되면 복잡성이 감소되는데, 관련된 테이블의 수가 적고 연관된 FK 수가 적기때문에 유지보수 시점에 고려할 것이 적아집니다. 이것이 엔티티타입 통합의 장점입니다.

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

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

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

2) 통합 고려 단계: 물리적 데이터모델링 단계에서는 성능을 고려하여 데이터모델통합을 유도하되 성능의 Trade Off(조인성능 개선 vs 데이터 집약 성능 저하)를 분석하여 통합과 분리를 결정한다. 

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

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