데이터 통합

 

출처 - 관계형 데이터 모델링

 

데이터 통합의 필요성

데이터 통합은 유사한 성격의 데이터, 동질성을 갖는 데이터를 더 큰 주제로 합치는 것입니다.

 

데이터 성격을 규정해 엔티티 정의하는 것이 모델러의 중요한 역할입니다.

데이터 통합 역시 모델러가 해야할 중요한 일입니다.

 

엔티티 정의가 명확하면 모델 확장성이 좋아집니다.

데이터 통합을 결정하기 전에 정규화가 선행되어야 합니다. 데이터 통합은 일반적으로 단계로 존재하지 않으며 엔티티 정의 과정에서 수행됩니다.

 

엔티티 정의하기 위해선 함수 종속에 기반을 둔 정규화가 선행이 필수입니다.

데이터 통합 전에 완전 정규화가 되어야 하는 의미입니다.

 

완전 데이터 통합 작업을 수행하고 비정규화가 필요시 통합된 모델에서 수행합니다.

비정규화를 수행하고 엔티티를 통합하면 의미가 희석되어 정확한 통합이 어렵습니다.

 

비 정규화 기법 중 데이터 추출 시간을 줄이고 엔티티 합체 방법이 있는데 이것은 데이터 통합과 다릅니다.

데이터 통합은 확장성을 높이기 위해 데이터를 일반화하는 작업입니다.

 

단순히 1:1 관계의 엔티티를 합치는 것과는 다릅니다.

 

데이터를 통합하는 주요 기준은 데이터의 성격입니다.

비슷한 엔티티를 판단하는 기준은 엔티티 기초 속성이 유사한 엔티티로 정합니다.

 

데이터 속성이 유사하나 엔티티 속성이 전혀 다른 경우도 있지만 두 엔티티의 기초 속성이 유사하면 엔티티 정의도 유사한 통합 대상입니다.

엔티티를 제대로 통합하기 위한 조건으로 엔티티 성격을 명확히 정의해야 합니다.

 

업무가 바뀔 가능성이 많다면 일반화가 필요합니다.

핵심 업무일수록 요구 사항이 변동될 가능성이 높습니다.

 

간혹 데이터는 유사한데 업무가 공통적인 부분이 없는 경우가 있습니다.

두 엔티티의 속성이 비슷하면 서로 다른 업무에서 각자 엔티티를 사용해도 저자는 가능한한 통합합니다.

 

데이터가 비슷하면 업무가 다를 수 없다는 것이 이 책의 저자의 생각입니다.

업무를 수행하는 부서나 담당자가 다르거나 프로세스가 다를 뿐, 데이터의 성격이 같다면 가능한 엔티티를 통합합니다.

 

모델은 유연할수록 오래 사용됩니다.

모델 구조는 뼈대와 같아 뼈대가 변하지 않다면 오래 사용이 가능하며 뼈대를 바꿔야 하면 더 사용할 수 없습니다.

 

엔티티 통합시 주의사항

너무 일반적인 개념으로 통합해서는 안됩니다. 사물과 사람 등의 광범위한 개념으로 통합하면 안됩니다.

 

동질성이 약간 데이터 통합은 주의해야 합니다.

상세논리, 물리 단계에서 실익을 충분히 고민해야 합니다.

 

엔티티를 통합하면 데이터가 많아지게 됩니다. 성능의 문제가 발생할 수 있어 이 부분을 고려해야 합니다.

성능 문제만 해결되면 데이터 통합의 이견은 감소합니다.

 

엔티티 통합은 프로젝트 규모가 커질수록 필요성과 중요성이 증가합니다. 프로젝트 규모가 커지면 개발 조직은 단위 업무나 단위 시스템별로 구성되며 운영합니다. 데이터가 통합되기 어려운 이유는 여러 개발 조직이 자신에게 할당된 엔티티만 관심을 갖기 때문입니다.

 

타 영역에 비슷한 엔티티가 있는지 모르며 있는 것을 알아도 통합에 따른 개발 오너십 등 문제로 통합이 어려운 경향이 있습니다.

 

 

장점과 단점

데이터 통합은 모델이 유연해지는 것이 장점입니다. 하지만, 너무 유연해져도 단점이 될 수 있습니다.

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

 

장점

확장성입니다. 변화되는 업무에 빠르게 대응이 가능합니다. 확장성은 좋은 모델을 구분하는 중요한 기준입니다. 정규화를 채택하는 것도 확장성을 높이는 방법입니다.

 

확장성이 좋은 이유는 비슷한 유형의 업무가 추가되는 경우 별도의 엔티티나 관계의 추가 없이 속성, 속성의 값을 추가해서 처리할 수 있습니다. 그만큼 데이터 구조에 큰 영향을 미치지 않게 됩니다.

 

코드 값 등의 인스턴스만 추가하고 엔티티, 속성, 관계 등 스키마는 변경되지 않는 것이 가장 이상적이지만 속성(관계)만 추가해 처리할 수 있더라도 유지, 보수가 수월해집니다.

 

엔티티별 애플리케이션 개발이 진행될 필요가 없어 애플리케이션 유지보수에도 좋습니다.

중복 개발도 방지할 수 있게 되는 것이 장점입니다.

 

> 최근 업무에서 확장성이 좋지 못하여 엔티티가 새롭게 추가되면서 신규 엔티티를 처리하기 위하여 애플리케이션에서 비슷한 로직이 중복해서 코드로 개발되는 아쉬웠던 부분이 있었습니다.

 

데이터를 통합하면 모델 확장성이 좋아진다는 점을 확신하지 못하는 실무 담당자가 많이 있습니다. 보통 기존에 하던 방법에 익숙해져 있어 기존의 형식이 정답이라고 생각하기 때문입니다. 다른 방법은 시도조차 하지 않으려는 태도로 변화를 꺼리는데 통합된 모델에 익숙해지면 그 생각은 바뀌게 될 것입니다.

 

엔티티가 통합되면 하위 배타 관계가 필요하지 않게 됩니다. 이것은 UNION 처럼 복잡한 SQL을 만들어 성능에 나쁜 영향을 주게 됩니다. 결국 배타 관계를 없애는 것은 성능에 도움이 됩니다.

 

단점

엔티티 통합의 단점은 데이터가 변질될 수 있습니다. 성격이 다른 두 개의 데이터를 하나의 엔티티에서 관리하면 두개 중 최소한 하나의 엔티티는 데이터 성격에 맞지 않도록 정의해야 하기 때문입니다.

 

성격이 다른 두 개의 데이터를 하나의 엔티티에서 관리하면 두 개 중 하나는 최소 엔티티 데이터 성격에 맞지 않도록 정의한 것입니다. 실제 데이터가 변질될 정도의 통합은 주의를 갖고 검토해야 합니다.

 

데이터가 변질돼 성격이 희석되는 현상은 엔티티 정의를 명확하지 않아 발생합니다. 정의만 명확하면 데이터 범주가 생기므로 변질은 발생되지 않습니다.

 

데이터를 통합할 때도 성능에 악영향을 줄 수는 있지만, 반대의 경우가 더 많을 것입니다. 통합된 엔티티에 파티션을 적용하면 테이블 풀 스캔도 피할 수 있으며 개별 엔티티와 같아 성능 저하의 근거가 희미해집니다.

 

하지만, 인덱스 깊이가 깊고 null 값이 많이 사용되는 등의 단점은 존재합니다.

 

엔티티가 통합되면 CASE 툴에 따라 모델에 대한 이해도가 낮아질 수 있습니다. 

 

데이터를 통합하면 엔티티 속성이 많아지고 업무에 따라 사용하는 속성이 달라 유지보수가 어려울 수 있지만 개별 엔티티가 여러 개 존재하는 것에 비할 바는 아니라고 생각합니다. 데이터가 통합되면 업무 프로세스나 화면이 통합돼 애플리케이션 로직이 다소 복잡해지고 SQL도 복잡해질 수는 있지만 애플리케이션을 효율적으로 코딩했다면 유지보수는 어렵지 않을 것입니다.

 

정리하면 데이터 통합시 널(null)값의 사용이 늘어나는 단점, 현행 데이터가 존재하면 마이그레이션 이슈가 있을 수 있습니다.

마이그레이션 문제가 없는지도 심도 있게 고려해야 합니다.