다음과 같은 데이터 소스를 선택하는 다양한 기준이 있습니다 -
데이터 접근성 − 데이터에 대해 두 가지 가능한 피드가 존재하는 경우, 하나는 가장 어린 프로젝트 팀원이 태어나기 전에 작성된 일련의 프로그램에서 유지 관리하는 이진 파일에 저장되고 다른 하나는 이진 문서를 읽고 더 많은 처리를 지원하는 시스템에서 가져온 것입니다. 결정은 뻔합니다.
데이터 정확도 − 데이터가 시스템에서 시스템으로 전달되면서 많은 수정이 이루어집니다. 때로는 다른 시스템의 데이터 요소가 추가되고 때로는 기존 요소를 처리하여 새로운 요소를 생성하고 다른 요소는 삭제됩니다.
각 시스템은 기능을 잘 수행합니다. 그러나 원본 데이터를 인식하기 어렵거나 불가능해질 수 있습니다. 어떤 경우에는 데이터가 더 이상 비즈니스가 분석에 원하는 것을 나타내지 않습니다. 이러한 다운스트림 시스템의 데이터를 제공하면 사용자가 정확성에 의문을 가질 수 있습니다.
프로젝트 일정 − 많은 조직에서 데이터 웨어하우스 프로젝트는 기존 OLTP 시스템 재작성의 일부로 시작됩니다. 새로운 시스템 개발 프로젝트가 본격적으로 시작되면서 데이터 웨어하우스의 가치를 확실하게 확신하는 비즈니스 사용자들이 머지 않아 데이터 웨어하우스를 구현해야 한다고 주장하기 시작하는 경우가 있습니다.
기록 데이터를 제공하려면 기존 시스템의 데이터를 데이터 웨어하우스에 포함해야 합니다. 이전 시스템의 다시 쓰기가 보류되면 데이터 웨어하우스는 현재 시스템을 계속 사용할 수 있습니다. 새 시스템이 프로덕션용으로 출시되면 데이터 피드를 해당 시스템으로 전환할 수 있습니다. 많은 경우 새 운영 체제가 완성되기 전에 데이터 웨어하우스를 제공할 수 있습니다.
일부 차원 정보는 일반적으로 거래 또는 사실 데이터와 함께 제공되지만 일반적으로 최소한이며 종종 코드 형태로만 제공됩니다. 사용자가 원하고 요구할 수 있는 추가 속성은 여러 시스템 또는 공동 마스터 파일에서 제공됩니다.
많은 경우, 특히 고객 차원에 대해 여러 마스터 파일이 있을 수 있습니다. 조직 전체에서 사용되는 별도의 파일이 있는 경우가 많습니다. 영업, 마케팅 및 재무 부서에는 고객 마스터 파일이 있을 수 있습니다.
먼저 두 가지 어려운 문제가 있습니다. 이 파일에 포함된 고객이 다를 수 있고 각 고객에 대한 속성이 다를 수 있습니다. 둘째, 공통 정보가 일치하지 않을 수 있습니다. 시간과 비용이 무제한이라면 모든 소스에서 풍부한 데이터를 가져온 다음 이를 고객에 대한 개별적인 포괄적인 관점으로 결합할 수 있습니다.
대부분의 경우 한 번에 모든 작업을 수행할 시간이나 돈이 충분하지 않습니다. 이러한 경우 사용자가 정보를 우선시하고 내가 할 수 있는 것부터 시작하여 앞으로 확장하는 것이 좋습니다.