데이터웨어 하우징 : ODS 예제 - 더미

ODS (운영 데이터 저장소)를 이해하는 데 도움이되는 데이터웨어 하우징 예제가 있습니다. 전 세계의 엘리트 회사 및 개인에게 다양한 서비스를 제공하는 대형 금융 회사에서 일한다고 가정 해보십시오.

귀사는 지난 25 년간 일련의 합병 및 인수로 현재의 형태로 성장했습니다. 최근 은행 및 증권 서비스의 융합에 대한 추세로 인해 귀사는 고객에게 완벽한 서비스 제공 업체가 될 수있는 기회를 얻었습니다.

귀사의 평균 고객이 다음과 같은 유형의 활동에 참여할 가능성이 높습니다.

기존 주식 중개 (마진 계정 활동을 포함하여 주식 공유 구매 및 판매)
채권 투자 (기업 및 정부 채권)
위험 중재 조치를 포함한 옵션 거래 계좌
현금 자산 관리
단기 대출 및 기타 채무 상품
중장기 대출 및 기타 채무 상품
벤처 캐피탈 투자
- 많은 돈이 들어간 쇼핑을 중단하십시오. 그러나 회사의 상황은 조금 복잡합니다. 특히 두 영역에서 매우 복잡합니다.

합병 및 인수로 인해 IT 인프라에 많은 수의 솔로 응용 프로그램 (응용 프로그램이 통합되지 않은 응용 프로그램이 많았습니다. 해야한다).

고객의 정의는 다소 흐릿합니다. 개인은 사업 거래를위한 투자 또는 대출을 통해 기업 및 파트너십을 수립합니다. 귀하의 법인 고객은 다른 회사의 자회사가 될 수 있으며 귀하의 고객 일 수도 있습니다.
귀하의 비즈니스 관행은 모든 고객과의 모든 신용 활동이 승인되기 전에 일련의 품질 보증 검사를 통과해야합니다.
귀하 또는 개인의 모든 고객은 부채 활동에 대한 몇 가지 상한을가집니다. 하나의 한도액은 주어진 시간에 총 미 지불 부채 금액입니다. 고객이 1 단계 천장에 도달 할 때까지 사람이 개입하지 않아도 자동으로 신용 대출에 대한 새로운 대출 또는 행동을 취하거나, 여백에 따라 주식을 구매하거나, 부채를 늘리는 다른 유형의 활동을 수행 할 수 있습니다.

모든 고객은 회사 임원 중 한 사람의 승인을받은 후 첫 번째 한도를 초과 할 수 있습니다. 경영진이 첫 번째 천장을 지나서 두 번째 천장까지 신용 활동을 승인하려면 일련의 조치를 확인해야합니다.

예를 들어 고객은 특정 자산 잔고를 보유하고 있어야합니다. 고객은 지난 30 일 동안 모든 유형의 모든 계좌 (예: 현금, 주식 및 채권)의 총 자산을 15 % 이상 줄 였을 수는 없습니다. 은행은 각 국가에서 보유하고있는 자산에 따라 조정 된 각 국가의 총 부채에 대한 최대 금액을 보유하고 있습니다.
위험 통제를 돕기 위해 회사는 모든 고객 간의 관계를 추적하여 고객의 재무 상태를 실제로 파악합니다. 예를 들어, 개인은 일련의 기업을 관리 할 수 있습니다. 일련의 기업은 각각 자신의 자산과 부채를 포함하여 개인 고객으로 취급합니다.
회사 임원이 추가로 천장 초과 채무를 승인하면 (예를 들어 해당 개인을 포함하는 부동산 파트너십의 경우) 경영진은 해당 개인의 활동과 관련된 전반적인 상황을 평가해야합니다 재정 문제의 경우에 너무 많은 위험 노출을 피하십시오. 앞서 언급 한 품질 보증 검사는 개념적으로 간단하지만 구현하기가 매우 복잡합니다. 그 이유는 많은 다른 시스템에서 기업의 시스템 전반에 걸친 데이터가 필요하기 때문입니다.

이 데이터에는 모든 자산 활동, 모든 부채 액티비티 및 현재 대출금 및 하루 중 빠른 시점에 대출금에 대한 정보가 포함됩니다.
시도 할 수있는 한 가지 방법은 회사의 임원 (대출 승인 결정을 내려야하는 임원)에게 필요한 데이터를 찾을 수있는 모든 시스템의 인터페이스를 제공하는 것입니다. 그런 다음이 경영진은 긴 일련의 쿼리를 실행하여 (지원할 수있는 경우) 적절한 값을 추출하여 스프레드 시트 프로그램에 붙여넣고 결정을 내릴 수 있습니다. 이 접근법에는 두 가지 문제점이 있습니다.: 인간의 실수 가능성이 높으며, 이러한 유형의 활동이 발생해야하는 속도는 "평범한"시기에만 괜찮습니다.

금융 위기가 발생했을 때 많은 또는 대부분의 회사 고객이 주식을 매매하고 마진, 옵션 매매, 헤지 어카운트 처리, 크레딧 한도 대출 및 기타 모든 종류의 거래를 할 때 활동이 매우 신속하게 이루어지면 귀사의 직원은 계속 따라갈 수 없습니다.

이 상황에서 ODS가 구조에옵니다. 이 그림은 비즈니스 임무를 충족시키는 ODS를 구현하는 데 사용할 수있는 개념적 아키텍처를 보여줍니다. 첫째, ODS는 첫 번째 천장에서 자동 대출 처리를위한 고객 잔액의 통합 된 그림을 제공합니다. 다음으로, ODS를 통해 경영진은 두 번째 천장까지 대출 요청에 대해 예 또는 아니오 결정을 내릴 수 있습니다.

ODS는 특정 비즈니스 임무를 지원하기 위해 사용자에게 서로 다른 데이터에 대한 거의 즉각적인 통합 된 그림을 제공합니다.

ODS 환경 내의 데이터 흐름을보다 자세히 보려면이 그림을 참조하십시오.이 그림에서는 데이터 소스 중 하나 (미국 부채를 처리하는 시스템)에 대한 업데이트가 ODS 환경으로 전파됩니다.

ODS는 가능한 빨리 기업 전체의 데이터 상태를 반영해야합니다.

다음 단계는 ODS 환경에서 일어나는 일을 나타냅니다.

고객이 정기적으로 예정된 대금 지불을하고 미국 대부 및 신용 한도에서 지불을 처리하는 시스템이 대금을 처리합니다.

대출 지불 애플리케이션은 지불을 반영하여 데이터베이스를 업데이트합니다.

대출 지불 애플리케이션은 업데이트 된 데이터를 즉시 ODS에 푸시합니다.

ODS는 업데이트를 수신하여 처리하고 데이터베이스 내용을 업데이트합니다 (이 예에서는 고객의 총 미 지불 부채 금액 감소).

ODS는 내부 처리, 통합, 경고 또는 기타 필요한 기능을 수행합니다. 앞의 목록에있는 것과 같은 환경은 모든 것이 적절하게 설계된 경우 회사의 위험 관리 임무를 지원하는 모든 곳에서 모든 관련 데이터의 그림을 제공 할 수 있습니다.

ODS에 대한 실시간 업데이트의 필요성을 검증해야합니다. 왜냐하면 이러한 업데이트는 다음 섹션에서 설명하는 것처럼 복잡하기 때문입니다.
계속해서 가정에 도전하고 질문합니다. "하루가 끝날 때까지 기다려야한다면 어떻게됩니까? 업데이트가 하루에 두 번 있다면 어떻게 될까요? 매시간? "ODS를 작성하는 데 데이터웨어 하우스보다 시간이 오래 걸리므로 임무가 실시간 업데이트를 요구한다는 점을 확신하십시오.