이번 강의에서는 데이터 모델링에서 Entity의 분할 중 근본 Entity에 의한 분할을 확인해 보자. 근본 Entity의 분할은 정규화의 기본에 해당되며 이와 같은 분할에 의해 테이블의 개수는 증가하지만 데이터양은 매우 감소할 수 있다.

근본 Entity로의 분할

조인은 'RDBMS의 꽃'이라고 불리고 있다. 이제부터 왜 조인이 RDBMS의 꽃인지를 확인해 보자.

[그림1]의 예제에서 좌측은 조인을 사용하지 않기 위해 테이블을 합친 형태다. 예제의 우측은 테이블을 분리해 구성함으로써 두 테이블의 각각 존재하는 데이터를 한번에 추출하기 위해서는 조인을 사용해야 한다.

아직도 많은 사이트에서는 조인을 사용하지 않기 위해 좌측과 같이 구성하는 경우가 많다. 그렇다면 예제의 우측과 좌측의 차이가 무엇인지를 확인해 보자.

• [그림1] 조인 사용 여부에 따른 비교 예제
• 

첫 번째로 테이블을 모두 액세스하는 경우에는 어떠한가? 각각의 경우에 대해 액세스하는 데이터의 양을 확인해 보자

• - 조인을 사용하지 않는 경우의 데이터 액세스 양 : 280MB
• - 조인을 사용하는 경우의 데이터 액세스 양 : 60MB + 115KB = 약 60MB

결국, 테이블의 데이터를 모두 액세스하는 경우에는 조인을 사용하는 구조에서 액세스하는 데이터양이 60MB로, 조인을 사용하지 않는 경우에 액세스해야 하는 데이터양에 비해 배 이상 액세스하는 데이터양이 감소하게 된다.

성능은 액세스하는 데이터양과 비례하므로 조인을 사용하는 경우가 더욱 빠른 성능을 보장할 수 있음은 자명한 사실이다. 물론, 조인을 이용하는 경우가 액세스하는 데이터양이 60MB로 조인을 사용하지 않는 경우에 비해 액세스하는 양은 4배 이상 감소하지만 사용하는 조인 방식에 의해 조인 부하는 발생하게 된다.

두 번째로 적은 데이터를 액세스하는 경우에는 어떠한가? 조인을 사용하지 않는 경우와 조인을 사용하는 경우를 분리해 차이점을 확인해 보자.

• - 조인을 사용하지 않는 경우 : 랜덤 액세스 발생 안 함
• - 조인을 사용하는 경우 : 랜덤 액세스 발생

적은 데이터를 액세스하는 경우에 조인을 사용한다면 랜덤 액세스가 발생하기 때문에 그 양이 많다면 성능은 저하될 수 있다. 하지만 적은 데이터를 액세스하는 경우이므로 랜덤 액세스 또한 적게 발생하게 되며, 조인이 최적화된다면 성능 저하가 발생하지 않을 수도 있다.

또한 조인의 최적화를 통해 액세스하는 랜덤 액세스의 양을 감소시킬 수도 있을 것이다. 랜덤 액세스의 발생은 성능을 저하시키지만 이는 충분히 SQL 최적화를 통해 해결할 수 있다.

이처럼 조인은 효과적으로 사용한다면 테이블의 데이터를 감소시키면서 성능을 보장할 수 있게 된다. 또한 중복된 데이터를 제거할 수 있기 때문에 데이터의 정합성을 보장할 수 있게 된다.

이와 같은 이유로 RDBMS에서 조인은 꽃이라고 한다. 물론, 잘못 사용된 조인은 상상을 초월하는 엄청난 성능 저하를 발생시키게 된다는 것을 명심하길 바란다.

결국 근본 Entity로 분할은 데이터 정합성 및 전체 데이터베이스의 크기 감소를 위해 필요하다. 하지만 조인에 의한 성능 저하에 대해서는 SQL 최적화를 수행해야 할 것이다.

• [표1]통합 Entity와 근본 Entity 분리

• 항목	통합 Entity	근본 Entity 분리	비고
  온라인 처리	유리	불리	- 근본 Entity의 Attribute 추출시 조인 발생으로 성능 저하 가능
  배치 처리	불리	유리	- 근본 Entity를 분할한 경우 크기 가 작아져 유리
  업무 유연성 (Entity 별)	불리	유리	- 별도의 Entity
  업무 유연성 (전체)	-	-
  관리	불리	유리	- 개별 작업 가능
  저장 공간	불리	유리	- Code로 구현
  Data 정합성	불리	유리	- 중복된 데이터 존재
  업무분석	불리	유리	- Entity Name으로 구분가능

• - 온라인 처리 : 근본 Entity 분할은 온라인 업무 처리 시에는 조인해서 조회를 수행해야 하므로 불리할 수 있다. 통합 Entity인 경우에는 온라인 처리를 수행할 경우 조인을 이용하지 않아도 되므로 유리할 수 있다.
• - 배치 처리 : 배치 처리 시에는 근본 Entity로 분할한 경우가 Entity의 Size가 작아지므로 유리하다.
• - 업무 유연성(Entity별) : Entity별로 업무가 변경될 경우에는 해당 Entity만 수정하면 되므로 근본 Entity로 분리한 경우가 유리하다.
• - 업무 유연성(전체) : 전체 업무 유연성은 근본 Entity를 분리하는 것과는 관계가 없으므로 두 가지 모두 동일하다.
• - 관리 : 근본 Entity로 분리하는 경우에는 데이터와 분리해 작업이 가능하기 때문에 근본 Entity를 분리한 경우가 더 유리하다.
• - 저장 공간 : 근본 Entity로 분리한 경우 Entity의 크기가 감소하므로 저장 공간은 감소하게 된다.
• - Data 정합성 : 근본 Entity로 분리한 경우에는 중복된 데이터를 제거하게 되므로 성능은 향상된다.
• - 업무 분석 : 근본 Entity에 의한 분리 Entity인 경우 Entity가 분리되어 있으므로 유리할 수 있다.

근본 Entity로의 분리는 통합 Entity와 비교해 장점이 많으므로 Entity 분할이 유리하며 온라인 처리에 대한 SQL 최적화는 반드시 필요한 단계이다.