Subset에 의한 분할

Subset에 의한 분할은 Data만 분리하는 것을 의미한다. 예를 들어 계좌 Entity에서 법인 계좌와 개인 계좌 Data를 분리한다고 가정하자.

• [그림1] 계좌 Entity에서 법인계좌와 개인계좌 Data의 분리 예
• 

그렇다면 [그림1]의 예제와 같이 법인 계좌 Entity와 개인 계좌 Entity를 도출할 수 있을 것이다. 이와 같이 하나의 Entity에 동일한 형태의 Data가 구분돼 저장되어 있을 경우 Subset에 의한 분할을 고려할 수 있게 된다.

이와 같이 Subset에 의한 Entity 분할을 수행한다면 하나의 계좌번호 값에 대해 조회를 수행하는 SQL이 달라질 수 있다. 보통의 경우에는 Entity 분할을 수행하게 되면 해당 Entity를 액세스하는 SQL은 복잡해질 수 있다.

물론 계좌번호 자체로 법인 계좌인지 아닌지를 확인할 수 있다면 굳이 UNION ALL을 이용할 필요 없이 애플리케이션에서 해당 Entity만 액세스하면 될 것이다. 이와 같다면 Entity 분할도 동일해진다. Entity 분할을 통해 [표 1]과 같은 현상이 발생할 수 있다.

• [표1] Entity 분할에 따른 현상

• 항목	통합 Entity	Subset 분리 Entity	비고
  온라인 처리	유리	불리	- 통합 조회 (SQL 복잡/성능 저하 가능)
  배치 처리	불리	유리	- Subset별로 배치 처리할 경우 (Partition Architecture로 해결 가능)
  업무 유연성 (Subset 별)	불리	유리	- 업무 변경으로 Attribute 추가 시
  업무 유연성 (전체)	유리	불리	- Entity 추가 생성 및 Application 변경 필요(Subset 분리)
  관리	불리	유리	- 개별 작업 가능
  저장 공간	-	-
  Data 정합성	-	-
  업무분석	불리	유리	- Entity Name으로 구분가능

• - 온라인 처리 : Subset에 의한 Entity 분할은 온라인 업무 처리 시에는 통합 조회를 수행해야 하므로 불리할 수 있다.
• - 배치 처리 : 배치 처리 시에 Subset에 의한 Entity 분할은 Subset별로 작업을 할 수 있으므로 유리할 수 있다. 물론 전체 Data에 대한 처리라면 동일할 것이다. 또한 통합 Entity인 경우에도 Physical Modeling 시 Partition Architecture 적용으로 각각의 Subset만 액세스할 수 있게 하는 현상을 유도할 수 있다.
• - 업무 유연성(Subset별) : Subset별로 업무가 변경될 경우에는 해당 집합만 수정하면 되므로 Subset에 의한 분리가 유리하다(예 : 컬럼 추가).
• - 업무 유연성(전체) : 새로운 Subset이 추가될 경우에 통합 Entity라면 그냥 사용하면 되나, Subset 분리 Entity인 경우에는 새로운 Entity를 구성해야 하며 이에 따른 애플리케이션 변경 또는 추가가 필요하다.
• - 관리 : Subset 분리 Entity인 경우 Entity가 분리되어 있으므로 각각 작업을 수행할 수 있어 관리에는 유리할 수 있다.
• - 저장 공간 : 통합 Entity나 Subset에 의한 Entity 분리나 동일한 저장 공간을 사용한다.
• - Data 정합성 : 통합 Entity와 Subset에 의한 Entity 분리의 경우 Data 정합성은 유사하다.
• - 업무 분석 : Subset 분리 Entity인 경우 Entity가 분리되어 있으므로 유리할 수 있다.

결국, Subset에 의한 Entity 분리는 통합 Entity와 비교해 장단점이 존재하며 업무 성격 및 해당 Entity에 대한 액세스 유형을 파악하고 그에 맞게 선택해 사용해야 할 것이다.

근본 Entity로의 분할

근본 Entity로의 분할이란 코드화되어 있지 않은 중복된 Code 값을 분리해 근본 Entity로 도출하는 것을 말한다.

• [그림2] 근본 Entity 도출
• 

• - Data 정합성 강화 : 예를 들어, 해당 Entity에 가맹점 코드 대신 가맹점 이름이 저장돼 있다면 해당 가맹점 이름이 변경되는 순간, 해당 Entity에 존재하는 해당 가맹점 데이터에 대해 가맹점 이름을 변경하는 Update문을 수행해야 할 것이다. 이를 근본 Entity로 분리한다면 해당 Entity에는 Code 값으로 표현하고 가맹점 이름의 값을 근본 Entity에서 Unique하게 관리하게 되므로 가맹점 이름이 변경돼도 하나의 값만 Update를 수행하면 되므로 Data 정합성은 강화될 것이다.
• - Entity 크기 감소 : 값으로 저장돼 있던 Attribute를 코드화하므로 Entity의 크기를 감소시킬 수 있다. 이 방법이야말로 대용량 데이터베이스로 변하는 기존 데이터베이스를 억제할 수 있는 유일한 방법이 될 것이다.
• - 조인 증가로 인한 성능 저하 : 근본 Entity로의 분할을 통해 두 Entity의 조인이 증가한다면 성능 저하를 발생시킬 수 있게 된다.
• - 도출된 근본 Entity에 의해 SQL 최적화 수행 가능 : 다음의 SQL을 확인해 보자. 이와 같이 다른 SQL에서 가맹점_이름 값을 임의 값으로 제공해 성능을 향상시키기 위해 사용할 수 있다.

• SELECT * 
    FROM 거래 
    WHERE 거래일자 = '20080330'
      AND 가맹점_이름 IN (SELECT 가맹점_이름 FROM 가맹점);
  

Entity 분할을 수행하는 이유

앞서 살펴본 것처럼 Entity는 여러 가지 형태로 분할할 수 있다. Entity 분할은 하나의 Entity를 작은 Entity로 분리하는 것을 의미하며, 이를 수행하는 이유는 다음과 같다.

• - 중복된 Data 제거 : 중복된 Data 제거를 통해 Data 정합성을 강화시키며 이는 정규화와 유사한 과정이 된다.
• - 자주 사용되지 않는 Attribute 분리 : 자주 사용하지 않는 Attribute를 다른 Entity로 분리해 성능을 향상시킨다.
• - 유사 Data를 분리 : 유사 Data를 별도의 Entity로 분리해 관리 및 성능을 고려한다.