본문 바로가기

Data Architecture

좋은 데이터 모델의 요소


[ link : http://www.dbguide.net/db.db?cmd=view&boardUid=12733&boardConfigUid=9&boardIdx=31&boardStep=1 ]


좋은 데이터 모델의 요소

일반적으로 시스템 구축 과정에서 생성되는 데이터 모델은 품질을 평가하는 것이 매우 어렵다. 사실은 특정 데이터 모델이 업무 환경에서 요구하는 사항을 얼마나 잘 시스템적으로 구현할 수 있는가를 객관적으로 평가할 수 있다면 가장 좋은 평가 방법일 것이다. 하지만 이것을 객관적으로 평가할 수 있는 기준이 존재하지는 않는 것이 현실이다. 다음에서는 이러한 상황에서 대체적으로 좋은 데이터 모델이라고 말할 수 있는 몇 가지의 요소를 설명한다.


완전성(Completeness)


업무에서 필요로 하는 모든 데이터가 데이터 모델에 정의되어 있어야 한다. 완전성은 데이터 모델을 검증하기 위해서 가장 먼저 확인해야 할 부분이다. 이 기준이 충족되지 못하면 다른 어떤 평가 기준도 의미가 없어진다. 만약 보험사의 데이터 모델에 고객의 직업을 관리하기 위한 속성이 존재하지 않는다면 어떻겠는가? 이것은 심각한 데이터 모델의 문제점이다.


중복 배제(Non-Redundancy)


하나의 데이터베이스 내에 동일한 사실은 반드시 한 번만 기록하여야 한다. 예를 들면, 하나의 테이블에서‘나이’칼럼과‘생년월일’칼럼이 동시에 존재한다면 이것은 데이터 중복이라고 볼 수 있다. 이러한 형태의 데이터 중복 관리로 인해 여러 가지의 바람직하지 않는 형태의 데이터 관리 비용을 지불하고 있다. 예를 들면, 저장 공간의 낭비, 중복 관리되고 있는 데이터의 일관성을 유지하기 위한 추가적인 데이터 조작 등이 대표적으로 낭비되고 있는 비용이라고 볼 수 있다.


비즈니스 룰(Business Rules)


데이터 모델에서 매우 중요한 요소 중에 하나가 데이터 모델링 과정에서 도출되어 지고 규명되어지는 수많은 업무 규칙(Business Rules)을 데이터 모델에 표현하고 이를 해당 데이터 모델을 활용 하는 모든 사용자가 그 규칙을 공유할 수 있게 제공하는 것이다. 


특히 데이터아키텍처에서 언급되는논리 데이터 모델(Logical Data Model)에서 이러한 요소들이 포함되어야 함은 매우 중요한 요소라고 할 수 있다. 예를 들면, 보험사의 사원들은 매월 여러 가지 항목에 대해 급여를 지급받고, 이를 데이터로 관리하고 있다. 각 사원들은 월별로 하나 이상의 급여 항목(기본급, 상여금, 수당, 수수료, 등등)에 대해 급여를 지급받는다. 여기에 더 나아가 각 사원은 사원 구분별(내근, 설계사, 계약직, 대리점 등)로 위의 급여 항목을 차등적으로 지급받는다는 업무 규칙이 존재한다. 이러한 내용을 데이터 모델에 나타내어야 한다


이렇게 함으로써 해당 데이터 모델을 사용하는 모든 사용자(개발자, 관리자등)가 해당 규칙에 대해 동일한 판단을 하고 데이터를 조작할 수 있게 되는 것이다.



데이터 재사용(Data Reusability)


데이터의 재사용성을 향상시키고자 한다면 데이터의 통합성과 독립성에 대해서 충분히 고려해야 한다. 무슨 이야기인가? 과거에 정보시스템이 생성되고 운영되던 형태를 되짚어보면 철저하게 부서 단위의 정보시스템으로 설계되고 운용되어 왔다. 현재 대부분의 회사에서 진행하고 있는 신규 정보 시스템의 구축 작업은 어떻게 이루어지고 있는가? 회사 전체 관점에서 공통 데이터를 도출하고 이를전 영역에서 사용하기에 적절한 형태로 설계하여 시스템을 구축하게 된다. 이러한 형태의 데이터 설계에서 가장 중요하게 대두되는 것이 통합 모델이다. 통합 모델이어야만 데이터 재사용성을 향상시킬 수 있다. 또 다른 측면에서 보면 과거 정보시스템의 데이터 구조의 가장 큰 특징은 데이터 모델이 별도로 존재하지 않고 애플리케이션의 부속품 정도로 인식되어져 왔던 것이 사실이다. 이러한 환경에서의 데이터는 프로세스의 흐름에 따라 관리되게 마련이다. 이러면 데이터 중복이 많이 발생하고 데이터의 일관성 문제가 심각하게 초래된다. 데이터가 애플리케이션에 대해 독립적으로 설계되어야만 데이터 재사용성을 향상시킬 수 있다.


안정성 및 확장성(Stability and Flexibility)


정보 시스템은 비즈니스의 변화에 대해 최적으로 적응하도록 끊임없이 요구 받고 있다. 하지만 정보시스템의 데이터 모델은 이러한 변화에 대해 어떻게 대응할 수 있는가? 현재의 데이터 구조를 거의 변화하지 않고도 변화에 대응할 수 있는 데이터 구조도 있을 것이고, 아주 적은 확장을 통해 이러한 변화에 대응하는 것도 있을 것이다. 하지만 이러한 변화에 대응하기 위해 데이터 구조적으로 아주 많은 변화를 주어야만 한다면 변화의 대상이 되는 부분뿐만 아니라 정보시스템의 나머지 부분들도 많은 영향을 받게 될 것이다. 그래서 많은 기업이 정보시스템을 구축하는 과정에서 데이터 구조의 확장성, 유연성에 많은 노력을 기울이고 있다. 그렇다면 어떤 데이터 모델이 이러한 확장성을 가진 데이터 모델인가?


현대의 기업들이 동종의 타 기업으로부터 경쟁 우위에 자리매김하려고 한다면 구축하는 데이터 모하게 대응할 수 있어야 한다. 특히 근래의 많은 패키지 시스템이 가지고 있는 데이터 모델들은 확장성을 강조하기 위해서 많은 부분을 통합한 데이터 모델 형태를 가지고 있는 것을 볼 수 있다. 여기에서도 잘 나타나듯이 확장성을 담보하기 위해서는 데이터 관점의 통합이 불가피하다. 특히 정보시스템에서의 ‘행위의 주체’가 되는 집합의 통합,‘ 행위의 대상’이 되는 집합의 통합, ‘행위 자체’에 대한 통합 등은 전체 정보시스템의 안정성, 확장성을 좌우하는 가장 중요한 요소라 할 수 있다.


간결성(Elegance)


데이터 모델이 갖추어야 하는 중요한 요소 중 하나는 기업이 관리하고자 하는 데이터를 합리적으로 균형이 있으면서도 단순하게 분류하는 것이다. 아무리 효율적으로 데이터를 잘 관리할 수 있더라도 그것의 사용, 관리 측면에서 복잡하다면 잘 만들어진 데이터 모델이라고 할 수 없다. 동종의 비즈니스를 영위하는 기업이라고 하더라도 각 회사의 데이터 모델을 비교해 보면 복잡도에는 많은 차이가 있는 것을 볼 수 있다. A 보험사는 계약 업무를 수행하기 위해 10개의 테이블을 정의해 업무를 수행하는 반면에 B 회사는 100개의 테이블을 정의해 동일한 업무를 수행하고 있다. 두 회사의 데이터 모델의 차이점은 무엇인가? 10개의 테이블을 가지고 업무를 수행하고 있는 A 회사의 데이터 모델은 간결하지만 새로운 업무 환경의 변화에 대해 확장성을 가지고 있다. B 회사는 겉으로는 새로운 업무 환경의 변화(신규 상품의 출현 등)에 능동적으로 대처하고 있는 것처럼 보이지만 사실은 보유하고 있는 데이터 모델의 한계로 인해 테이블의 수가 지속적으로 증가해 왔다. 이렇게 됨으로써 데이터 모델은 간결하지 못하고 동일한 형태로 관리되어야 하는 데이터가 복잡한 형태로 관리되어지고, 그들과의 관계를 갖고 있는 다른 여러 가지의 데이터나 복잡한 형태의 관계들이 불가피해 복잡성을 증가시켜왔다. 결국 간결한 모델의 기본적인 전제는 통합이다. 합리적으로 잘 정돈된 방법으로 데이터를 통합하여 데이터의 집합을 정의하고, 이를 데이터 모델로 잘 표현하여 활용한다면 웬만한 업무 변화에도 데이터 모델이 영향을 받지 않고 운용될 수 있게 된다.



의사소통(Communication)


데이터 모델의 역할이 많다. 그 중에서도 중요한 것이 데이터 모델의 의사소통 역할이다. 데이터 모델은 대상으로 하는 업무를 데이터 관점에서 분석하고 이를 설계하여 나오는 최종 산출물이다. 데이터 분석 과정에서는 자연스럽게 많은 업무 규칙이 도출된다. 이 과정에서 도출되는 많은 업무 규칙은 데이터 모델에 엔터티, 서브타입, 속성, 관계 등의 형태로 최대한 자세하게 표현되어야 한다.


예를 들면,‘ 사원’테이블에는 어떠한‘사원구분’을 가지는 사원들이 존재하는가? ‘ 정규직’,‘ 임시직’ 사원들이 같이 존재하는가? 아니면 또 다른 형태의 사원들이 존재하는지를 표현해야 한다. 더 나아가서‘호봉’이라는 속성은‘정규직’일 때에만 존재하는 속성인데, 이러한 업무 규칙이 데이터 모델에 표현되어야 한다. 또한 관리하는 사원 중에서‘정규직’사원만이‘급여’테이블과 관계를 가진다. 이러한 부분은 개별 관계로 데이터 모델에 표현되어야 한다. 이렇게 표현된 많은 업무 규칙은 해당 정보시스템을 운용, 관리하는 많은 관련자들이 설계자가 정의한 업무 규칙들을 동일한 의미로 받아들이고 정보시스템을 활용할 수 있게 하는 역할을 한다. 즉, 데이터 모델이 진정한 의사소통 (Communication)의 도구로서의 역할을 하게 된다.



통합성(Integration)


기업들이 과거로부터 정보시스템을 구축해왔던 방법은 개별 업무별로의 단위 정보 시스템을 구축하여 현재에까지 유지 보수를 해오고 있는 것이 보통이다. 점진적인 확장과 보완의 방법으로 정보시스템을 사용해 왔기 때문에 동일한 성격의 데이터임에도 불구하고 전체 조직 관점에서 보면 여러 곳에서 동일한 데이터가 존재하기 마련이다. 특히 이러한 데이터 중에서도 고객, 상품 등과 같이 마스터 성격의 데이터들이 분할되어 관리됨으로 인해 전체 조직 관점의 데이터 품질, 관리, 활용 관점에서 많은 문제점이 나타나고 있는 것이 현실이다.


 가장 바람직한 데이터 구조의 형태는 동일한 데이터는 조직의 전체에서 한 번만 정의되고 이를 여러 다른 영역에서 참조, 활용하는 것이다. 물론 이때에 성능 등의 부가적인 목적에 따라 의도적으로 데이터를 중복시키는 경우는 존재할 수 있다. 동일한 성격의 데이터를 한 번만 정의하려면 공유 데이터에 대한 구조를 여러 업무 영역에서 공동으로 사용하기 용이하게 정의할 수 있어야 한다. 이러한 이유로 데이터 아키텍처의 중요성이 한층 더 부각되고 있다.