데이터 모델링25 - 데이터 집합의 분리, 확장, 통합1

집합의 통합과 분리에 대한 기초적 이해

그림 12-1 데이터의 성격, 정체성, 주제가 동일하지만 별도 엔티티로 분리된 모델

주변에서 흔히 볼 수 있는 개별 구체적 집합으로 분리된 엔티티들을 통해 집합의 통합과 분리에 대한 기본적인 이해를 도우려한다. [그림 12-1]은 실제 업무에서 작성된 모델을 데이터 아키텍트(DA)가 검증 후 정제하도록 가이드한 사례다.

 

이 사례는 기업 간 기술 인수 혹은 이전을 위한 거래 정보를 대시보드 형태로 관리하는 모델이다.  거래할 기술을 등록하여 수요 기업과 공급기업이 정보를 공유하기 위함인데, 구조를 살펴보면 엔티티 사이에 배타적 관계가 존재함을 쉽게 확인할수 있다. 쉽게 말해 하위 엔티티가 개체화 되었을때 실제 부모로 가질수 엔티티는 부모로 가지고 있는 여러 엔티티중 하나라는 것이다. [그림 12-1]의 모델에서는 <흥미도>,<댓글>, <첨부_파일> 등과 <구매_기술>, <판매_기술>, <묶음_기술> 등의 관계가 배타적 관계에 해당한다.

 

그림 12-2 흥미도 중심으로 단순화한 모델

<흥미도> 엔티티를 중심으로 모델을 단순화해보자 (그림 12-2). <흥미도> 엔티티의 인스턴스(개체) 하나는 <구매_기술>,<판매_기술>,<묶음_기술> 중 하나의 엔티티와 관계가 존재하는 배타적 관계에 있다.

 

<댓글>과 <첨부_파일> 역시 기술 관련 엔티티들과 배타적 관계에 있으므로 [그림 12-1]의 ERD에서 관계선이 굉장히 복잡하게 그려진 것이다. 배타 관계는 모델의 구조를 복잡하게 만들고, 복잡한 조인이 발생하게 하는 등 일반적으로 바람직하지 않다. 통상적으로 배타 관계 데이터 모델은 개발시 배타관계 조인 문제 때문에 매우 나쁜 결과를 초래할 가능성이 높으니 주의해서 사용해야 한다. [그림 12-1]을 기준으로 작성한 다음의 SQL문은 배타 관계를 구현하기 위해 외부 조인(outer join)

 

💡 tip) 오라클 OUTER JOIN

아우터 조인을 사용하는 이유는 기준테이블의 데이터가 모두 조회(누락 없이)되고, 대상 테이블에 데이터가 있을 경우 해당 컬럼의 값을 가져오기 위해서이다. 핵심은 조인을 하더라도 기준 테이블의 데이터가 누락되지 않도록 하는 것이다.

💡 tip) 오라클 OUTER JOIN 시 활용되는 '(+)'

'(+)'기호의 위치의 반대쪽 테이블이 OUTER JOIN의 기준이 되는 테이블이다.

💡 tip) 오라클 DECODE

DECODE함수는 오라클 쿼리에서 많이 사용되는 함수이나 표준 SQL 함수는 아니다. DECODE함수는 프로그래밍에서 if else와 비슷한 기능을 수행한다. 
예) DECODE(컬럼, 조건1, 결과1, 조건2, 결과2, 조건3, 결과3....)

 

SELECT ~~
FROM 댓글 x, 구매_기술 a, 판매_기술 b, 묶음_기술 c
WHERE a.기술_번호(+) = decode(x.기술_종류_코드,'1',x.기술_번호)
    and b.기술_번호(+) = decode(x.기술_종류_코드,'2',x.기술_번호)
    and c.기술_번호(+) = decode(x.기술_종류_코드,'3',x.기술_번호)
    and x.내용 LIKE :keyword || '%';

중접된 루프 Nested Loop(NL)조인은 그 특성상 외부 조인을 할때 방향이 한쪽으로 고정되며, 외부 조인 기호(+)가 붙지 않은 테이블이 항상 드라이빙 테이블로 선택된다. 즉, 인덱스가 있어도 드라이빙 테이블이 아니므로 무용지물이 되어 전체 테이블 스캔(full table scan)으로 실행 계획이 풀려 엄청난 성능 저하를 가져올 수 있다. 이런 이유로 외부 조인이 사용되는 경우는 세심한 주의가 필요하다.

 

앞의 SQL문에서 외부 조인을 제거하기 위해 아래와 같이 UNION ALL로도 분할할 수 있다.

 

SELECT ~~
FROM 댓글 x, 구매_기술 y
WHERE x.기술_종류_코드 = '1' AND x.기술_번호 = y.기술_번호
    and x.내용 LIKE :keyword || '%'
UNION ALL
SELECT ~~
FROM 댓글 x, 판매_기술 y
WHERE x.기술_종류_코드 = '2' AND x.기술_번호 = y.기술_번호
    and x.내용 LIKE :keyword || '%'
UNION ALL
SELECT ~~
FROM 댓글 x, 묶음_기술 y
WHERE x.기술_종류_코드 = '3' AND x.기술_번호 = y.기술_번호
    and x.내용 LIKE :keyword || '%'

이 형태는 코딩량이 늘어나 SQL 파싱 부하 증가는 물론이며, 인덱스 구성에 따라 처리 주관 범위가 반복 수행되는 등 여전히 성능 이슈가 존재한다. 이처럼 단점이 많은 배타 관계 모델로 설계된 원인은 무엇일까? 기술 관련 엔티티 데이터의 성격이 유사한, 본질적으로 동질한 집합임에도 불구하고 개별 엔티티로 분할되었기 때문이다.

 

그림 12-3 데이터 성격이 동질한 집합은 통합하는 것이 좋다.

데이터 모델링은 단순한고 명확한 관계를 가지도록 하는 것이 바람직하다. 이를 위해서 유사한 엔티티를 가능한 한 통합하는 것이 유리하다. 데이터의 성격이 유사한 엔티티가 분할되어 있으면 특정 트랜잭션 처리는 약간 단순해질지 모르지만, 앞서 언급했듯이 매우 많은 엔티티를 복잡하게 연결해야 하는 경우가 훨씬 많다. 앞의 모델은 데이터 정체성이 본질으로 유사한 기술 관련 엔티티들을[그림 12-3]처럼 통합하는 것이 유리하다. 엔티티가 계층구조상 상위 엔티티일 경우에 더욱 그러하다.

 

사실 <구매_기술>,<판매_기술>,<묶음_기술> 엔티티의 속성이 90%이상 동일하다는 것과 배타적 관계가 존재한다는 것은 이들 엔티티가 본질적으로 동질한 집합임을 반증하는 것이기도 하다. 통합된 모델에 맞게 앞의 SQL을 다시 작성해보면 다음과 같이 단순해진다.

 

SELECT ~
FROM 댓글 x, 통합_기술 y 
WHERE x.기술번호 = y.기술_번호
    and x.내용 LIKE :keyword || '%'

이처럼 동질의 엔티티를 통합함으로써 다음과 같은 장점을 얻을 수 있다.

• 데이터 모델의 구조가 단순하고 명확해진다.
• SQL이 단순해지고 코딩량이 줄어 개발 생상성이 좋아진다.
• 조인이 최소화되어 성능 이슈도 없어진다.
• 통합되지 않은 모델과 비교해서 요건 변경에 따른 유연성이 극대화된다.

 

[출처 - 프로젝트의 성패를 결정짓는 데이터 모델링 이야기 , 김상래 저]