1 데이터의 중복과 고립화

2 정보계의 데이터 중복

데이터의 중복과 고립화를 없애는 일은 데이터베이스로 밥벌이 하는 주요 수단이다. 그러므로 이 부분을 잘 이해해야 하는데, 그게 쉽지 않다. 왜냐하면 제대로 설명하려면 책 한 권 가지고도 부족하기 때문이다. 앞서 데이터베이스의 정의에서 ‘최소한의 중복’이라는 글을 보았을 것이다. 무분별한 데이터의 중복을 없애고 정당화된 데이터의 중복이 필요하다. 여기에서는 데이터의 중복과 고립화가 왜 문제가 되는지만 정확하게 알면 된다.

Data federation은 여러 데이터 저장소에 존재하는 데이터의 물리적 요소를 추상화하여, 단일 액세스 채널을 통해 조회하고 메모리 상에서 통합하는 가상적 통합하는 방식(Gartner)을 말한다. 데이터를 액세스하는 사용자는 가상환경에서 표준화된 단일 뷰(single view)를 제공받음으로써 데이터 통합의 이점(비용감소, 효율성 등)을 얻게 된다. Data Consolidation은 크게 단순한 물리적인 통합과 ETL(Extract, Transform, Load)과정을 거쳐 사용자에게 데이터를 전달하는 2가지 방식이 있다. 당연히 ETL방식이 훨씬 어렵고 복잡하지만, 단순한 물리적인 통합만으로도 매우 큰 효과가 있다. 그 이유는 시너지(시너지는 다음의 게시물인 데이터베이스 시스템에서 다룬다)가 발생하기 때문이다.

독립적인 정보시스템 내부의 데이터 중복은 필연적으로 성능과 데이터 무결성에 해를 끼치는 현상을 경험하게 해준다. 정보시스템의 최대 성능은 정보시스템을 구성한 하드웨어의 한계를 뛰어 넘지 못한다. 최적화라고 해봐야 데이터 처리 알고리즘에 대한 조정뿐이다. 그러므로 데이터의 중복이 성능 저하를 가져오는 것은 명확한 결론을 내릴 수 있게 해준다.

위의 그림과 같이 디스크에 100MB의 데이터가 중복되어 있다고 가정하자. 그러면 100MB 만큼의 저장공간을 낭비해야 한다. 데이터를 처리할 때는 200MB를 읽어야 한다. 즉, 100MB만큼 더 읽어야 한다. 메모리는 100MB 더 필요하고, CPU는 100MB 만큼을 더 처리해야 한다. 만약 메모리가 여유롭지 않다면 공용으로 사용하는 데이터베이스 시스템은 필히 자원의 경합을 불러 일으킨다. 데이터 중복은 비용증가, 성능저하를 반드시 가져오게 된다.

데이터 중복은 데이터의 결함을 유발할 수 있다. 예를 들어 A시스템에서 고객번호 111인 고객의 성명은 '홍길동'이다. B시스템도 마찬가지다. 하지만 시간이 흘러 고객번호 111인 사람이 '홍수환'으로 개명신청을 하였다면 A시스템과 B시스템 모두 '홍수환'으로 갱신되어야 할 것이다. 하지만 데이터의 불일치를 관리하는 장치가 마련되지 않았거나, A시스템과 B시스템이 고립화되었다면 데이터는 불일치 될 것이다. 특히, 이러한 분산 데이터베이스 환경에서는 성능 요소가 중요하다는 이유로 데이터의 중복을 많이 허용한다. 하지만 데이터의 중복에 의한 데이터 품질 저하를 막는 장치는 필요하다.

또 다른 예로 물리적으로 다른 데이터베이스 시스템이 아닌 같은 데이터베이스 시스템에서의 데이터 중복도 마찬가지다. 아래의 그림을 보자.

고객명, 상품명 이 중복되어 있는 것을 볼 수 있다. 마찬가지로 "고객"의 "홍길동"을 "홍수환"으로 변경하면 "주문"의 "홍길동"도 갱신해 주어야 데이터의 불일치가 발생하지 않는다.

그렇다면 데이터의 중복을 없애는 방법이 없느냐? 있다. 데이터베이스 공부를 해본 사람이라면 다 아는 "정규화"다. 데이터의 중복을 없애는 것은 비용 절감, 성능향상, 무결성 확보라는 3마리 토끼를 잡는 아주 중요한 작업이 된다. 하지만 분산 데이터베이스 환경에서는 쉽지만은 않다. 분산환경에서는 전체중복, 부분중복도 충분히 고려해야 한다. 데이터의 중복을 없애는 일은 우리의 궁극적인 목표인 좋은 정보의 질을 만들어내는 일 중 가장 신경을 많이 써야 하는 어려운 작업이다.

정보계에서는 데이터의 중복이 필연적으로 일어난다. 데이터의 필연적 중복의 원인은 대량의 Join문제나 데이터 웨어하우스의 구조적인 특성 때문이다. Join 문제는 대용량 데이터의 정규화로 인해 발생되는데, 이는 데이터의 사용패턴이나 하드웨어의 처리량에 따라서 비정규화 되어 발생하는 문제다. 그러므로 비교적 데이터의 중복은 해결될 수 있다. 하지만 데이터 웨어하우스의 경우 데이터의 흐름이란 것이 있다. 데이터가 운영계로부터 추출되고 최종 사용자에 이르기까지 각 단계별로 데이터의 중복이 발생한다. 아래의 그림은 전통적인 DW의 구조다. (DM이 먼저다 뭐다 이런거 따지지 말자)

고객, 상품/서비스가 각 단계별로 중복되어 저장되는 것을 볼 수 있다. 물론 데이터의 형태는 달라질 수 있다. 운영계로부터 데이터가 추출되면 데이터는 각각의 서비스나 업무 관점의 데이터에서 전사적인 관점의 데이터로 통합/변환 된다. 데이터의 형태는 다르지만 본질은 같은 데이터가 중복되는 것이다. 구조적인 데이터의 중복도 물론 피할 수는 있다. 하드웨어의 성능이 비약적으로 발전하였으므로 실제 물리적인 데이터를 1개로 하고, 논리적인 개체(뷰, 스토어드 프로시저 등)로 각각의 서비스나 업무 관점에 맞게 데이터를 제공하면 된다. 물론 ROI를 잘 따져봐야 하는데 그게 쉽지 않다.

먼가 저도 같이 고립되는 느낌.... -- 김현섭 2011-08-02 12:55:51

df -- df 2017-02-27 15:24:37