통합이 대세인가? 통합 시 주의할 점

데이터(엔터티) 통합이 대세지만 통합 시 주의할 점이 있습니다.

 

일반적으로 많이 언급되는 것은 성능입니다.

 

데이터를 통합하면 데이터는 많아질 수밖에 없습니다.

A집합과 B집합의 인스턴스 개수가 합쳐지기 때문에 데이터가 늘어납니다.

 

데이터가 증가하는 것과 성능은 유관합니다.

요건에 따라 때론 큰 차이가 생기고, 때론 미미한 차이가 생깁니다.

때론 성능이 좋아지기도 하고요.

 

통합해야 성능이 좋아지는 요건도 많아 저는 통합을 우선적으로 고려합니다.

그러면서 성능이 나빠질 수 있다는 점을 염두에 두죠.

 

흔하지는 않지만 대기 현상으로 인한 인서트 성능 저하를 고려할 때도 있습니다.

인서트가 많이 발생하는 엔터티에 어떤 엔터티를 통합하는 것은 바람직하지 않습니다.

 

인서트가 많다는 기준이 애매한데요. 참고로 말씀드리면 제 기준으로 이제껏 경험한 엔터티는 다섯 개 이하입니다.

 

데이터 통합 시 실무자들이 가장 우려하는 것이 성능입니다.

성능 문제만 없다면 데이터 통합을 그다지 반대하지 않았습니다.

 

성능 다음으로 많이 언급되는 것이 지나친 일반화입니다(지나치다는 판단 또한 개인마다 기준이 다를 수 있습니다).

 

맞긴 하지만 뭔가 좀 그런 느낌이 들 때가 있습니다.

 

최근 파티(Party)라는 개념이 간혹 사용되고 있습니다.

간단히 설명하면 고객·사원·부서·거래처 등 행위의 모든 주체를 통합하는 것인데요.

 

상황에 따라 판단해야 하지만 저는 일반적으로 반대하는 개념입니다.

고객 데이터와 부서 데이터는 다른 성격의 데이터라고 보기 때문에요.

 

‘~명'이 존재하는 데이터를 한 엔터티에서 관리한다는 생각은 지나칠 수 있습니다.

그중에는 사람도 있을 수 있고 상품도 있을 수 있으므로 성격에 맞게 구분하는 것이 바람직합니다.

 

이와 같이 성격이 다른 데이터를 지나치게 일반화해서 통합한 사례는 흔치 않습니다(초기 개념 모델 혹은 개괄 모델에서는 지나친 통합이 사용되기도 합니다).

 

이런 통합은 의도된 통합이라 장점도 있을 것입니다.

하지만 의도되지 않은 지나친 통합이 있습니다.

 

유사하지 않은 데이터인데 유사하게 선언해 통합할 때, 이때는 통합의 적정성을 판단하기 어렵습니다.

데이터 정의에 근본적인 문제가 있기 때문에 분간이 힘듭니다.

 

다른 데이터라도 정의만 유사하게 선언하면 그럴듯한 통합처럼 보입니다.

 

파티(Party)와 같은 지나친 일반화는 개념은 맞지만 좀 꺼림칙한 것인데 반해 이건 아예 틀린 것입니다.

 

이에 대한 해법은 우선 데이터 정의를 제대로 하는 것인데요. 먼저 정규화가 진행돼야 합니다.

 

정규화는 정의를 하는 단계에서 사용하기 때문에, 근본적인 것이기 때문에 아무리 강조해도 부족함이 없습니다. 선택 사항이 아닙니다.

 

그리고 통합 시 주의할 할 점 중에 실전에서 많이 볼 수 있는 것이 있습니다.

 

엔터티는 어떤 기준에 의해 구분할 수 있는데요.

저는 주로 실체·행위·기준·가공 엔터티로 나눕니다

 

엔터티 분류

 

이때 실체 엔터티와 행위 엔터티 간에 통합이 발생하면 안 됩니다.

그게 현재 일대일 관계고 미래에도 계속 일대일 관계라고 해도요.

 

실무에서 실체와 행위, 실체와 기준, 실체와 가공, 기준과 행위 데이터가 합쳐진 엔터티를 자주 보게 됩니다.

합쳐서 사용이 가능하고, 당장 보이는 부작용이 없다고 할지라도 분리하는 것이 바람직합니다.

 

최근 데이터 통합이 대세입니다.

누구나 통합을 얘기하고 서브타입을 얘기합니다

 

통합을 위한 통합을 하지 않도록 주의해야 합니다.

 

대세를 따르는 것은 좋지만 생각하고 따르는 것이 중요합니다.

실익이 있는지 따져보고 숙고해야 합니다.