최근에 OLAP에 대해 많은 글이 작성되었습니다. 우리는 이러한 기술 주위에 약간의 붐이 있다고 말할 수 있습니다. 사실, 우리에게 이 붐은 다소 늦었지만 이것은 물론 국가의 일반적인 상황 때문입니다.

엔터프라이즈 규모의 정보 시스템에는 일반적으로 데이터, 역학, 추세 등의 복잡한 다차원 분석을 위해 설계된 응용 프로그램이 포함됩니다. 이러한 분석은 궁극적으로 의사 결정을 지원하기 위한 것입니다. 종종 이러한 시스템을 의사결정 지원 시스템이라고 합니다.

의사결정 지원 시스템에는 일반적으로 초기 세트의 다양한 샘플에 대한 집계 데이터를 지각 및 분석에 편리한 형태로 사용자에게 제공하는 수단이 있습니다. 일반적으로 이러한 집계 함수는 다차원(따라서 비관계형) 데이터 세트(하이퍼큐브 또는 메타큐브라고도 함)를 형성하며, 축에는 매개변수가 포함되고 셀에는 매개변수에 종속되는 집계 데이터가 포함됩니다. 관계형 테이블에 저장되지만 이 경우 스토리지의 물리적 구현이 아니라 데이터의 논리적 구성에 대해 이야기하고 있습니다. 각 축을 따라 데이터를 다양한 세부 수준을 나타내는 계층 구조로 구성할 수 있습니다. 이 데이터 모델을 사용하여 사용자는 다음을 공식화할 수 있습니다. 복잡한 쿼리, 보고서 생성, 데이터 하위 집합 가져오기

복잡한 다차원 데이터 분석 기술을 OLAP(On-Line Analytical Processing)라고 합니다.

OLAP는 데이터 웨어하우징의 핵심 구성 요소입니다.

OLAP의 개념은 잘 알려진 데이터베이스 연구원이자 관계형 데이터 모델의 저자인 Edgar Codd가 1993년에 설명했습니다.E.F. 코드, S.B. Codd 및 C.T.Salley, 사용자 분석가에게 OLAP(온라인 분석 처리) 제공: IT 의무.기술 보고서, 1993).

1995년에 Codd가 요약한 요구 사항을 기반으로 다차원 분석 응용 프로그램에 대한 다음 요구 사항을 포함하는 소위 FASMI 테스트(공유 다차원 정보의 빠른 분석 - 공유 다차원 정보의 빠른 분석)가 공식화되었습니다.

· 사용자에게 허용 가능한 시간(보통 5초 이하)에 분석 결과를 제공하는 것, 비록 덜 상세한 분석을 희생하더라도

· 논리적 및 통계적 분석 특성을 수행할 가능성 이 신청서최종 사용자가 액세스할 수 있는 형식으로 보존

· 적절한 잠금 메커니즘 및 승인된 액세스 도구를 지원하는 데이터에 대한 다중 사용자 액세스

· 계층 및 다중 계층에 대한 완전한 지원을 포함하여 데이터의 다차원 개념 표현(OLAP의 핵심 요구 사항)

· 볼륨 및 저장 위치에 관계없이 필요한 정보에 액세스할 수 있는 기능.

OLAP 기능을 구현할 수 있습니다. 다른 방법들, 사무용 애플리케이션의 가장 단순한 데이터 분석 도구에서 시작하여 서버 제품을 기반으로 하는 분산 분석 시스템으로 끝납니다.사용자는 자신의 작업에 적용된 다차원 구조의 데이터를 쉽게 볼 수 있습니다.

2. OLAP이란?

OLAP - English On-Line Analytical Processing의 약자 -는 특정 제품의 이름이 아니라 전체 기술의 이름입니다. 러시아어에서는 OLAP 운영 분석 처리를 호출하는 것이 가장 편리합니다. 일부 간행물에서는 분석 처리를 온라인 및 대화식이라고 부르지만 형용사 "온라인"은 OLAP 기술의 의미를 가장 정확하게 반영합니다.

경영 관리 결정의 개발은 자동화하기 가장 어려운 영역의 범주에 속합니다. 그러나 오늘날에는 결정 개발 과정에서 관리자를 지원할 수 있는 기회가 있으며 가장 중요한 것은 결정 개발 프로세스, 선택 및 채택 속도를 크게 높일 수 있습니다. 이를 위해 OLAP를 사용할 수 있습니다.

솔루션 개발 프로세스가 일반적으로 어떻게 발생하는지 고려하십시오.

역사적으로 운영 활동을 자동화하는 솔루션이 가장 많이 개발되었습니다. 우리는 단순히 운영 시스템이라고 하는 OLTP(트랜잭션 데이터 처리) 시스템에 대해 이야기하고 있습니다. 이러한 시스템은 특정 사실의 등록, 아카이브의 단기 저장 및 보존을 보장합니다. 이러한 시스템의 기반은 관계형 데이터베이스 관리 시스템(RDBMS)에 의해 제공됩니다. 전통적인 접근 방식은 의사 결정 지원을 위해 이미 구축된 운영 시스템을 사용하는 것입니다. 일반적으로 그들은 운영 체제에 대한 쿼리의 개발된 시스템을 구축하고 결정을 지원하기 위해 직접 해석 후 받은 보고서를 사용하려고 합니다. 보고서는 사용자 정의 기반으로 작성할 수 있습니다. 관리자는 보고서를 요청하고 정기적으로 특정 이벤트 또는 시간에 도달하면 보고서가 작성됩니다. 예를 들어, 기존의 의사 결정 지원 프로세스는 다음과 같습니다. 관리자가 정보 전문가에게 가서 질문을 공유합니다. 그런 다음 정보 전문가는 운영 시스템에 대한 요청을 작성하고 전자 보고서를 수신하여 해석한 다음 관리 담당자에게 알려줍니다. 물론 이러한 방식은 어느 정도 의사결정 지원을 제공하지만 효율성이 매우 낮고 많은 단점이 있습니다. 중요한 결정을 지원하는 데 소량의 데이터가 사용됩니다. 다른 문제도 있습니다. 이러한 절차는 요청을 작성하고 전자 보고서를 해석하는 과정이 길기 때문에 매우 느립니다. 리더가 지금 당장, 즉시 결정을 내려야 하는 시기에 여러 날이 걸립니다. 보고를 받은 후 관리자가 다른 문제에 관심을 가질 수 있다는 점(예: 다른 컨텍스트에서 데이터를 명확히 하거나 고려해야 함)을 고려할 때 이 느린 주기를 반복해야 하며 데이터 분석 프로세스가 운영체제반복적으로 발생하면 더 많은 시간이 소요됩니다. 또 다른 문제는 전문가의 다양한 활동 영역의 문제입니다. 정보 기술그리고 서로 다른 범주로 생각할 수 있고 결과적으로 서로를 이해하지 못하는 관리자. 그런 다음 추가 정제 반복이 필요할 것이며, 이것은 항상 충분하지 않은 시간입니다. 또 다른 중요한 문제는 이해해야 할 보고서의 복잡성입니다. 관리자는 보고서에서 관심 있는 숫자를 선택할 시간이 없습니다. 특히 숫자가 너무 많을 수 있기 때문입니다(실제로 여러 페이지를 사용하고 나머지는 만일을 대비하여 사용하는 거대한 다중 페이지 보고서를 기억하십시오). 우리는 또한 통역 작업이 정보 부서의 전문가에게 가장 자주 맡겨진다는 점에 주목합니다. 즉, 유능한 전문가는 다이어그램 그리기 등에 대한 일상적이고 비효율적인 작업으로 인해 산만 해지며 물론 그의 자격에 유리하게 영향을 줄 수 없습니다. 또한, 들어오는 정보의 의도적인 왜곡에 관심이 있는 통역 체인에 선의를 가진 사람들이 있다는 것은 비밀이 아닙니다.

위의 단점은 운영 시스템을 만드는 데 드는 비용이 작업의 효율성에 의해 적절한 정도로 보상되지 않기 때문에 운영 시스템의 전반적인 효율성과 그 존재와 관련된 비용에 대해 생각하게 합니다.

사실, 이러한 문제는 운영 체제의 품질이 좋지 않거나 성공적이지 못한 구성의 결과가 아닙니다. 문제의 뿌리는 운영 시스템에 의해 자동화되는 운영 활동과 개발 및 의사 결정 활동 간의 근본적인 차이에 있습니다. 이러한 차이점은 운영 체제의 데이터가 단순히 발생한 일부 이벤트의 기록, 즉 사실일 뿐 일반적인 의미의 정보가 아니라는 사실에 있습니다. 정보는 모든 영역에서 불확실성을 줄이는 것입니다. 그리고 정보가 결정 준비의 불확실성을 줄인다면 매우 좋을 것입니다. 악명 높은 E.F. 1970년대에 관계형 데이터베이스 관리 시스템 기술을 개척한 Codd는 다음과 같이 말했습니다. ". 우리는 정보의 합성, 운영 체제의 데이터를 정보로, 심지어는 정성적 평가로 바꾸는 방법에 대해 이야기하고 있습니다. OLAP를 사용하면 이 변환을 수행할 수 있습니다.

OLAP은 다차원 데이터 모델의 아이디어를 기반으로 합니다. 인간의 사고는 정의상 다차원적입니다. 사람이 질문을 할 때 그는 제한을 부과하여 다차원의 질문을 공식화하므로 다차원 모델에서의 분석 과정은 인간 사고의 현실에 매우 가깝습니다. 다차원 모델의 차원에 따라 기업 활동에 영향을 미치는 요소(예: 시간, 제품, 회사 부서, 지리 등)가 연기됩니다. 따라서 하이퍼 큐브가 얻어집니다 (물론 큐브는 일반적으로 동일한 모서리를 가진 그림으로 이해되기 때문에 이름은별로 좋지 않습니다.이 경우에는 그렇지 않음) 표시기로 채워집니다. 기업 활동(가격, 판매, 계획, 이익, 손실 등) 등). 이 채우기는 운영 체제의 실제 데이터로 수행할 수 있으며 과거 데이터를 기반으로 예측할 수 있습니다. Hypercube 차원은 복잡하고 계층적일 수 있으며 차원 간에 관계를 설정할 수 있습니다. 분석하는 동안 사용자는 데이터에 대한 관점을 변경할 수 있습니다(소위 논리적 관점을 변경하는 작업). 따라서 다른 섹션에서 데이터를 보고 특정 문제를 해결할 수 있습니다. 예측 및 조건부 스케줄링(가정 분석)을 포함하여 큐브에서 다양한 작업을 수행할 수 있습니다. 또한 작업은 큐브에서 한 번에 수행됩니다. 예를 들어, 제품은 하이퍼큐브 제품을 생성하며, 각 셀은 해당 승수 하이퍼큐브의 셀의 제품입니다. 당연히 차원 수가 다른 하이퍼큐브에 대한 작업을 수행하는 것이 가능합니다.

3. OLAP 기술 창조의 역사

다차원 배열에서 데이터를 처리한다는 아이디어는 새로운 것이 아닙니다. 사실, Ken Iverson이 그의 책 APL(프로그래밍 언어)을 출판한 1962년으로 거슬러 올라갑니다. APL의 첫 번째 실제 구현은 60년대 후반 IBM에서 이루어졌습니다. APL은 다차원 변수와 처리된 연산이 있는 매우 우아하고 수학적으로 정의된 언어입니다. 다른 실용적인 프로그래밍 언어와 비교하여 다차원 변환 작업을 위한 원래의 강력한 도구를 의도했습니다.

그러나 그래픽 인터페이스, 고품질 인쇄 장치 및 그리스 문자 표시에는 특수 화면, 키보드 및 인쇄 장치가 필요한 시대가 아직 오지 않았기 때문에 아이디어는 오랫동안 대중적인 응용을 받지 못했습니다. 나중에 영어 단어가 그리스어 연산자를 대체하는 데 사용되기도 했지만 APL 순도 전투기는 그들이 가장 좋아하는 언어를 대중화하려는 시도를 좌절시켰습니다. APL은 또한 기계 자원을 소비했습니다. 그 당시에는 비용이 많이 들었습니다. 프로그램은 실행 속도가 매우 느리고 실행 비용도 매우 비쌌습니다. 많은 메모리가 필요했으며 당시에는 엄청난 양(약 6MB)에 불과했습니다.

그러나 이러한 초기 실수의 성가심은 아이디어를 죽이지 못했습니다. 70년대와 80년대에 많은 비즈니스 애플리케이션에서 사용되었습니다. 이러한 응용 프로그램의 대부분은 현대적인 분석 처리 시스템의 기능을 가지고 있습니다. 예를 들어 IBM이 개발한 운영 체제 VSPC라고 하는 APL용으로 일부 사람들은 스프레드시트가 보편화될 때까지 개인용으로 이상적인 매체라고 생각했습니다.

그러나 APL은 사용하기가 너무 어려웠습니다. 특히 언어 자체와 이를 구현하려는 하드웨어 간에 불일치가 발생할 때마다 특히 그렇습니다.

1980년대에 APL은 개인용 컴퓨터에서 사용할 수 있게 되었지만 시장에서 사용되지는 않았습니다. 대안은 다른 언어의 배열을 사용하여 다차원 응용 프로그램을 프로그래밍하는 것이었습니다. 이것은 전문 프로그래머에게도 매우 어려운 작업으로 차세대 다차원 소프트웨어 제품을 기다려야 했습니다.

1972년에는 이전에 교육 목적으로 사용되었던 여러 다차원 소프트웨어 응용 프로그램인 Express가 상업적으로 사용되었습니다. 그것은 지금도 완전히 다시 쓰여진 형태로 남아 있지만, 70년대의 원래 개념은 더 이상 관련이 없습니다. 오늘날, 90년대에 Express는 가장 인기 있는 OLAP 기술 중 하나이며 Oracle(r)은 계속해서 이를 추진하고 새로운 기능을 추가할 것입니다.

80년대에는 더 다차원적인 제품이 등장했습니다. 10년 초반에 Stratagem이라는 제품이 나중에 Acumate(현재는 Kenan Technologies 소유)라고 불리며 90년대 초반까지 계속 홍보되었지만 오늘날에는 Express와 달리 거의 사용되지 않습니다.

Comshare System W는 다른 스타일의 다차원 제품이었습니다. 1981년에 도입된 이 제품은 최종 사용자와 금융 애플리케이션 개발에 더 중점을 둔 최초의 제품입니다. 완전히 비절차적 규칙, 다차원 데이터의 전체 화면 보기 및 편집, 자동 재계산 및 관계형 데이터와의 일괄 통합과 같이 잘 적용되지 않은 많은 개념을 도입했습니다. 그러나 Comshare System W는 당시의 다른 제품들에 비해 하드웨어적으로 상당히 무거웠고, 미래에는 덜 쓰이고 덜 팔리며 제품에 대한 개선도 이루어지지 않았습니다. 오늘날에도 여전히 UNIX에서 사용할 수 있지만 클라이언트-서버가 아니기 때문에 분석 제품 시장에서 제공하는 제품을 늘리는 데 도움이 되지 않습니다. 80년대 후반에 Comshare는 DOS용 제품과 나중에 Windows용 제품을 출시했습니다. 이 제품들은 Commander Prism이라고 불리며 System W와 같은 개념을 사용했습니다.

80년대 후반의 또 다른 창의적인 제품은 Metaphor라고 불렸습니다. 전문 마케터를 위한 것이었습니다. 그는 또한 클라이언트-서버 컴퓨팅, 관계형 데이터에 대한 다차원 모델 사용, 객체 지향 응용 프로그램 개발과 같이 이제 막 널리 사용되기 시작한 많은 새로운 개념을 제안했습니다. 그러나 당시 표준 PC 하드웨어는 Metaphor를 실행할 수 없었고 공급업체는 PC 및 네트워크에 대한 자체 표준을 개발해야 했습니다. 점차적으로 Metaphor는 직렬 개인용 컴퓨터에서 성공적으로 작동하기 시작했지만 제품은 OS/2 전용으로 만들어졌으며 자체 그래픽 사용자 인터페이스가 있었습니다.

그런 다음 Metaphor는 IBM과 마케팅 제휴를 맺었고 나중에 흡수되었습니다. 1994년 중반 IBM은 Metaphor 기술(DIS로 개명)을 미래 기술과 통합하여 별도의 자금 지원을 중단하기로 결정했지만 고객은 불만을 표시하고 제품에 대한 지속적인 지원을 요구했습니다. 나머지 고객에 대한 지원은 계속되었고 IBM은 DIS라는 새 이름으로 제품을 다시 출시했지만 인기를 얻지는 못했습니다. 그러나 Metaphor의 창의적이고 혁신적인 개념은 잊혀지지 않았고 오늘날 많은 제품에서 볼 수 있습니다.

80년대 중반 EIS(Executive Information System)라는 용어가 탄생했습니다. 이 방향을 명확하게 보여주는 첫 번째 제품은 조종사의 지휘 센터였습니다. 그것은 오늘날 우리가 클라이언트-서버 컴퓨팅이라고 부르는 협업 컴퓨팅을 가능하게 하는 제품이었습니다. 80년대 개인용 컴퓨터의 힘은 ​​제한적이었으므로 이 제품은 매우 "서버 중심적"이었지만 이 원칙은 오늘날에도 여전히 인기가 있습니다. Pilot은 오랫동안 Command Center를 판매하지 않았지만 자동 타이밍 지원, 다차원 클라이언트-서버 컴퓨팅 및 단순화된 분석 프로세스 제어(마우스, 민감한 화면 등)를 포함하여 오늘날의 OLAP 제품에서 인식할 수 있는 많은 개념을 제공했습니다. ). 이러한 개념 중 일부는 나중에 Pilot Analysis Server에서 다시 적용되었습니다.

1980년대 후반에 스프레드시트는 최종 사용자를 위한 분석 도구 시장을 지배했습니다. Compet 제품은 최초의 다차원 스프레드시트를 도입했습니다. 이 제품은 전문가용으로 매우 고가의 제품으로 판매되었지만 공급업체는 제품이 시장을 장악할 수 있는지 확인하지 못했고 Computer Associates는 Supercalc 및 20/20을 비롯한 다른 제품과 함께 이 제품에 대한 권리를 획득했습니다. CA Compete 인수의 주요 효과는 가격의 급격한 하락과 복제 방지의 제거였으며 자연스럽게 배포에 기여했습니다. 그러나 그는 성공하지 못했습니다. 경쟁은 Supercalc 5의 핵심이지만 다차원적 측면은 홍보되지 않습니다. 한 번에 많은 돈이 투자되었다는 사실 때문에 오래된 경쟁은 여전히 ​​때때로 사용됩니다.

다음으로 Lotus는 NeXT 머신에서 실행되는 Improv 제품으로 다차원 스프레드시트 시장에 진입하려고 했습니다. 이것은 최소한 1-2-3의 판매가 떨어지지 않도록 보장했지만 결국 Windows용으로 출시되었을 때 Excel은 이미 큰 시장 점유율을 차지하여 Lotus가 시장 배포를 변경할 수 없었습니다. Lotus는 Compete가 있는 CA와 마찬가지로 Improv를 시장 바닥으로 옮겼지만 이것이 시장에서 성공적인 판촉의 조건이 되지 않았고 이 분야의 새로운 개발이 계속되지 않았습니다. 개인용 컴퓨터 사용자는 1-2-3 스프레드시트를 선호하고 이전 스프레드시트와 완전히 호환되지 않는 한 새로운 다차원 기능에 관심이 없는 것으로 나타났습니다. 마찬가지로 개인용 응용 프로그램으로 제공되는 작은 데스크탑 스프레드시트의 개념은 실제로 편리함이 입증되지 않았으며 실제 비즈니스 세계에 적용되지 않았습니다. Microsoft(r)는 Excel에 피벗 테이블을 추가하여 이 경로를 밟았습니다. 이 기능을 사용하는 Excel 사용자는 거의 없지만 전 세계에 Excel 사용자가 너무 많기 때문에 다변량 분석 기능이 전 세계적으로 널리 사용되는 유일한 사실일 것입니다.

4. OLAP, ROLAP, MOLAP…

Codd가 1985년에 관계형 DBMS 구축에 대한 규칙을 발표했을 때 강력한 반응을 일으켰고 이후 DBMS 산업 전반에 큰 영향을 미쳤다는 것은 잘 알려져 있습니다. 그러나 1993년 Codd가 "분석 사용자를 위한 OLAP: What It Should Be"라는 작업을 출판했다는 사실을 아는 사람은 거의 없습니다. 그 책에서 그는 온라인 분석 처리의 기본 개념을 설명하고 제품이 온라인 분석 처리를 제공하기 위해 충족해야 하는 12가지 규칙을 식별했습니다.

다음은 규칙입니다(가능한 경우 원본 텍스트가 유지됨).

1. 개념적 다차원 표현. 분석가 사용자는 엔터프라이즈 세계를 본질적으로 다차원으로 봅니다. 따라서 OLAP 모델은 기본적으로 다차원적이어야 합니다. 다차원 개념 다이어그램 또는 사용자 정의 표현은 계산뿐 아니라 모델링 및 분석을 용이하게 합니다.

2. 투명성. OLAP 제품이 사용자 도구의 일부인지 여부에 관계없이 이 사실은 사용자에게 투명해야 합니다. OLAP가 클라이언트-서버 컴퓨팅에 의해 제공되는 경우 이 사실도 가능하면 사용자에게 보이지 않아야 합니다. OLAP는 사용자가 어디에 있든 분석 도구를 사용하여 서버와 통신할 수 있도록 하는 진정한 개방형 아키텍처의 컨텍스트에서 제공되어야 합니다. 또한 분석 도구가 동종 및 이종 데이터베이스 환경과 상호 작용할 때 투명성도 확보되어야 합니다.

3. 가용성. OLAP 분석가 사용자는 관계형 데이터베이스의 전사적 데이터와 레거시 레거시 데이터베이스의 데이터, 공통 액세스 방법 및 공통 분석 모델을 포함하는 공통 개념 스키마를 기반으로 분석을 수행할 수 있어야 합니다. 즉, OLAP는 이기종 데이터베이스 환경에서 액세스하기 위한 자체 논리를 제공하고 적절한 변환을 수행하여 사용자에게 데이터를 제공해야 합니다. 또한 물리적 데이터 조직이 실제로 어디에, 어떻게, 어떤 유형으로 사용될 것인지에 대한 사전 주의가 필요하다. OLAP 시스템은 실제로 필요한 데이터에만 액세스해야 하며 적용되지 않아야 합니다. 일반 원칙불필요한 입력을 수반하는 "주방 깔때기".

4. 보고서 개발의 일관된 생산성. 차원의 수나 데이터베이스의 크기가 증가하더라도 분석가 사용자는 성능이 크게 저하되지 않아야 합니다. 일관된 성능은 최종 사용자의 사용 편의성을 유지하고 OLAP 복잡성을 제한하는 데 매우 중요합니다. 분석가 사용자가 차원 수에 따라 성능에서 상당한 차이를 경험하는 경우 분석가는 이러한 차이를 개발 전략으로 보상하는 경향이 있으며, 이는 데이터가 실제로 필요한 방식과 다른 방식으로 데이터를 제시하게 합니다. 제시된다. 시스템의 부적절함을 보완하기 위해 시스템을 우회하여 시간을 낭비하는 것은 분석 제품이 설계된 목적이 아닙니다.

5. 클라이언트-서버 아키텍처. 오늘날 온라인 분석에 필요한 대부분의 데이터는 PC를 통해 액세스되는 메인프레임에 있습니다. 따라서 OLAP 제품은 클라이언트-서버 환경에서 작동할 수 있어야 합니다. 이러한 관점에서 분석 도구의 서버 구성 요소는 실질적으로 "지능적"이어야 여러 클라이언트가 최소한의 번거로움과 통합 프로그래밍으로 서버에 참여할 수 있습니다. "지능형" 서버는 부적절한 논리적 및 물리적 데이터베이스 스키마를 매핑하고 통합할 수 있어야 합니다. 이것은 투명성과 공통의 개념적, 논리적, 물리적 체계의 구성을 보장할 것입니다.

6. 일반적인 다차원성. 각 차원은 구조 및 운영 능력에 관계없이 적용되어야 합니다. 선택한 차원에 추가적인 운용 능력을 부여할 수 있으며, 차원이 대칭적이기 때문에 어떤 차원에든 단일 기능을 부여할 수 있다. 기본 데이터 구조, 수식 및 보고 형식은 어떤 차원에도 편향되어서는 안 됩니다.

7. 희소 행렬의 동적 제어. OLAP 도구의 물리적 설계는 희소 행렬을 최적으로 관리하기 위해 특정 분석 모델에 완전히 적응할 수 있어야 합니다. 주어진 희소 행렬에 대해 최적의 물리적 체계는 단 하나뿐입니다. 이 방식은 물론 전체 데이터 세트가 메모리에 맞지 않는 한 최대 메모리 효율성과 매트릭스 운용성을 제공합니다. OLAP 도구의 기본 물리적 데이터는 대규모 분석 모델을 사용한 실제 작업을 위해 순서에 관계없이 차원의 모든 하위 집합으로 구성되어야 합니다. 물리적 액세스 방법은 또한 동적으로 변경되어야 하며 직접 계산, B-트리 및 파생 상품, 해싱, 필요한 경우 이러한 메커니즘을 결합하는 기능과 같은 다양한 유형의 메커니즘을 포함해야 합니다. 희소성(가능한 모든 셀에 대한 빈 셀의 백분율로 측정)은 데이터 전파의 특성 중 하나입니다. 희소성을 제어할 수 없으면 작업의 효율성을 달성할 수 없습니다. OLAP 도구가 분석된 데이터 값의 분포를 제어하고 규제할 수 없는 경우 많은 통합 경로와 차원을 기반으로 실용적이라고 주장하는 모델은 실제로 불필요하고 희망이 없을 수 있습니다.

8. 다중 사용자 지원. 종종 여러 분석가 사용자가 동일한 분석 모델에서 함께 작업하거나 동일한 데이터에서 다른 모델을 만들어야 합니다. 따라서 OLAP 도구는 공유(쿼리 및 추가), 무결성 및 보안 기능을 제공해야 합니다.

9. 무제한 교차 작업. 계층적 특성으로 인해 서로 다른 롤업 수준과 통합 경로는 OLAP 모델 또는 응용 프로그램에서 종속 관계를 나타냅니다. 따라서 도구 자체는 적절한 계산을 암시해야 하며 분석가 사용자가 이러한 계산 및 작업을 재정의할 것을 요구하지 않아야 합니다. 이러한 상속된 관계에서 따르지 않는 계산은 일부 적용 가능한 언어에 따라 다른 공식으로 정의해야 합니다. 이러한 언어는 모든 차원의 데이터로 계산 및 조작을 허용할 수 있으며 데이터 셀 간의 관계를 제한하지 않으며 특정 셀의 공통 데이터 속성 수에 주의를 기울이지 않습니다.

10. 직관적인 데이터 조작. 통합 경로의 방향 변경, 상세화, 확대 및 통합 경로에 의해 규제되는 기타 조작은 분석 모델의 셀에 대한 별도의 작업을 통해 적용해야 하며 메뉴 시스템 또는 기타 다중 작업을 사용할 필요가 없습니다. 사용자 인터페이스. 분석 모델에 정의된 차원에 대한 분석가 사용자의 보기에는 위의 작업을 수행하는 데 필요한 모든 정보가 포함되어야 합니다.

11. 유연한 보고 옵션. 시각적으로 서로 비교할 데이터의 행, 열 및 셀이 서로 가깝거나 기업에서 발생하는 일부 논리적 기능에 따라 데이터의 분석 및 표시가 간단합니다. 보고 도구는 가능한 모든 방향에서 데이터 모델의 결과로 합성된 데이터 또는 정보를 나타내야 합니다. 이는 행, 열 또는 페이지가 0에서 N 차원까지 동시에 표시되어야 함을 의미합니다. 여기서 N은 전체 분석 모델의 차원 수입니다. 또한 단일 레코드, 열 또는 페이지에 표시된 각 콘텐츠 차원은 차원에 포함된 요소(값)의 하위 집합을 임의의 순서로 표시할 수도 있어야 합니다.

12. 무제한 차원 및 집계 수준 수. 해석 모델에 필요한 필요한 측정의 가능한 수에 대한 연구에 따르면 최대 19개의 측정을 동시에 사용할 수 있습니다. 따라서 분석 도구는 동시에 최소 15개의 차원을 제공할 수 있고 가급적이면 20개의 차원을 제공할 수 있도록 강력히 권장합니다. 또한 각 공통 차원은 분석 사용자가 정의한 집계 수준 및 통합 경로의 수로 제한되어서는 안 됩니다.

사실, 오늘날 OLAP 제품 개발자는 이러한 규칙을 따르거나 최소한 따르기 위해 노력합니다. 이러한 규칙은 운영 분석 처리의 이론적 기초로 간주될 수 있으며 이에 대해 논쟁하기가 어렵습니다. 그 후 12가지 규칙에서 많은 결과가 도출되었지만, 불필요하게 이야기를 복잡하게 만들지 않기 위해 제공하지는 않습니다.

OLAP 제품의 물리적 구현이 어떻게 다른지 자세히 살펴보겠습니다.

위에서 언급했듯이 OLAP는 다차원 구조에서 데이터를 처리한다는 아이디어를 기반으로 합니다. OLAP이라고 하면 논리적으로 분석 제품의 데이터 구조가 다차원적이라는 의미입니다. 그것을 구현하는 방법은 다른 문제입니다. 특정 제품을 포함하는 분석 처리에는 두 가지 주요 유형이 있습니다.

몰랍 . 실제로 다차원(다차원) OLAP. 이 제품은 데이터의 다차원 저장, 처리 및 표시를 제공하는 비관계형 데이터 구조를 기반으로 합니다. 따라서 데이터베이스를 다차원이라고도 합니다. 이 클래스의 제품에는 일반적으로 다차원 데이터베이스 서버가 있습니다. 분석 프로세스의 데이터는 다차원 구조에서 독점적으로 선택됩니다. 이러한 구조는 매우 생산적입니다.

롤랩 . 관계형 OLAP. 이름에서 알 수 있듯이 이러한 도구의 다차원 구조는 관계형 테이블로 구현됩니다. 그리고 분석 프로세스의 데이터는 각각 분석 도구에 의해 관계형 데이터베이스에서 선택됩니다.

일반적으로 각 접근 방식의 단점과 장점은 분명합니다. 다차원 OLAP 제공 더 나은 성능, 그러나 구조는 많은 양의 데이터를 처리하는 데 사용할 수 없습니다. 큰 차원은 큰 하드웨어 리소스를 필요로 하고 동시에 하이퍼 큐브의 희소성이 매우 높을 수 있으므로 하드웨어 용량의 사용은 정당화. 이에 반해 관계형 OLAP는 저장 데이터의 큰 배열에 대한 처리를 제공하는데, 그 이유는 보다 경제적인 저장을 제공할 수 있기 때문이지만 동시에 다차원 OLAP의 속도에서 크게 떨어집니다. 이러한 추론은 새로운 종류의 분석 도구인 HOLAP을 선택하게 되었습니다. 이것은 하이브리드(하이브리드) 운영 분석 처리입니다. 이 클래스의 도구를 사용하면 관계형 접근 방식과 다차원 접근 방식을 모두 결합할 수 있습니다. 다차원 데이터베이스의 데이터와 관계형 데이터 모두에 액세스할 수 있습니다.

또 다른 다소 이국적인 유형의 온라인 분석 처리인 DOLAP이 있습니다. 이것은 "데스크탑" OLAP입니다. 우리는 하이퍼 큐브가 작고 치수가 작고 요구 사항이 적당하며 이러한 분석 처리를 위해서는 데스크탑의 개인용 컴퓨터로 충분한 분석 처리에 대해 이야기하고 있습니다.

운영 분석 처리는 관리 직원이 준비하고 결정을 내리는 프로세스를 크게 단순화하고 가속화할 수 있습니다. 온라인 분석 처리는 데이터를 정보로 전환하는 목적을 제공합니다. 이는 대부분 구조화된 보고서를 고려하는 기존의 의사 결정 지원 프로세스와 근본적으로 다릅니다. 유추해 보면 구조화된 보고서와 OLAP의 차이점은 트램과 자동차로 도시를 운전하는 것과 같습니다. 트램을 타면 레일을 따라 움직이기 때문에 멀리 있는 건물이 잘 보이지 않고 가까이에 있는 건물이 훨씬 더 많이 보입니다. 반대로 자가용을 운전하면 완전한 이동이 가능합니다(물론 교통 규칙을 준수해야 함). 아무 건물까지 차를 몰고 트램이 다니지 않는 곳까지 갈 수 있습니다.

구조화된 보고서는 의사 결정의 자유를 가로막는 레일입니다. OLAP은 정보 고속도로에서 효율적인 이동을 위한 자동차입니다.

데이터 웨어하우스의 주요 특성.

• 과거 데이터를 포함합니다.
• 세부 정보는 물론 부분적으로 또는 완전히 요약된 데이터를 저장합니다.
• 데이터는 대부분 정적입니다.
• 규제되지 않고 구조화되지 않고 휴리스틱한 데이터 처리 방식
• 중간 및 낮은 강도의 거래 처리;
• 예측할 수 없는 데이터 사용 방식
• 분석을 위해 설계되었습니다.
• 에 초점을 맞춘 주제 영역;
• 전략적 의사결정 지원;
• 상대적으로 적은 수의 경영진에게 서비스를 제공합니다.

OLAP(On-Line Analytical Processing)이라는 용어는 데이터 프레젠테이션 모델을 설명하고 이에 따라 데이터 웨어하우스에서 처리하는 기술을 설명하는 데 사용됩니다. OLAP는 집계된 데이터의 다차원 보기를 사용하여 빠른 접근전략적으로 중요한 정보심층 분석을 위해. OLAP 응용 프로그램에는 다음과 같은 기본 속성이 있어야 합니다.

• 다차원 데이터 표현;
• 복잡한 계산 지원;
• 시간 요소의 올바른 고려.

OLAP의 장점:

• 프로모션 성능제작진, 개발자 응용 프로그램. 전략적 정보에 대한 적시 액세스.
• 사용자에게 스키마를 변경할 수 있는 충분한 권한을 부여합니다.
• OLAP 애플리케이션이 의존하는 데이터 웨어하우스및 OLTP 시스템에서 최신 데이터를 수신하여 무결성 제어기업 데이터.
• OLTP 시스템의 부하를 줄이고 데이터 웨어하우스.

OLAP 및 OLTP. 특성 및 주요 차이점

OLAP 시스템에 대한 Codd 규칙

1993년 Codd는 분석 사용자를 위한 OLAP: What It Should Be Like를 발표했습니다. 그 책에서 그는 온라인 분석 처리의 기본 개념을 설명하고 제품이 온라인 분석 처리를 제공하기 위해 충족해야 하는 12가지 규칙을 식별했습니다.

1. 개념적 다차원 표현. OLAP 모델은 핵심이 다차원이어야 합니다. 다차원 개념 다이어그램 또는 사용자 정의 표현은 계산뿐 아니라 모델링 및 분석을 용이하게 합니다.
2. 투명도. 사용자는 출처를 의심하지 않고도 OLAP 시스템에서 필요한 모든 데이터를 얻을 수 있습니다. OLAP 제품이 사용자 도구의 일부인지 여부에 관계없이 이 사실은 사용자에게 보이지 않아야 합니다. OLAP가 클라이언트-서버 컴퓨팅에 의해 제공되는 경우 이 사실도 가능하면 사용자에게 보이지 않아야 합니다. OLAP는 실제 컨텍스트에서 제공되어야 합니다. 열린 건축, 사용자가 어디에 있든 분석 도구를 사용하여 서버와 통신할 수 있습니다. 또한 분석 도구가 동종 및 이종 데이터베이스 환경과 상호 작용할 때 투명성도 확보되어야 합니다.
3. 유효성. OLAP는 자체적으로 제공해야 합니다. 논리도이기종 데이터베이스 환경에 접근하고 적절한 변환을 수행하여 사용자에게 데이터를 제공합니다. 또한 물리적 데이터 조직이 실제로 어디에, 어떻게, 어떤 유형으로 사용될 것인지에 대한 사전 주의가 필요하다. OLAP 시스템은 실제로 필요한 데이터에만 액세스해야 하며 불필요한 입력을 수반하는 일반적인 "주방 깔때기" 원칙을 적용하지 않아야 합니다.
4. 일정한 성능보고서를 개발할 때. 성능차원 수와 데이터베이스 크기의 증가에 따라 보고가 크게 떨어지지 않아야 합니다.
5. 클라이언트-서버 아키텍처. 제품은 클라이언트/서버 제품이어야 할 뿐만 아니라 서버 구성 요소도 최소한의 노력과 프로그래밍으로 서로 다른 클라이언트가 연결할 수 있을 만큼 지능적이어야 합니다.
6. 일반적인 다차원성. 모든 차원은 동일해야 하며, 각 차원은 구조 및 운영 능력 면에서 동일해야 합니다. 사실, 개별 차원에 대해 추가 작동 기능이 허용되지만(분명히 시간이 암시됨) 이러한 추가 기능은 모든 차원에 제공되어야 합니다. 기본이 되어서는 안된다. 데이터 구조, 계산 또는 보고 형식이 한 차원에 더 구체적이었습니다.
7. 동적 제어 희소 행렬. OLAP 시스템은 모델 유형, 데이터 볼륨 및 데이터베이스 희소성을 기반으로 물리적 스키마를 자동으로 조정해야 합니다.
8. 다중 사용자 지원. OLAP 도구는 다음 기능을 제공해야 합니다. 나누는(요청 및 추가), 무결성 및 보안.
9. 무제한 교차 작업. 모든 측정에는 모든 종류의 작업이 허용되어야 합니다.
10. 직관적인 데이터 조작. 데이터 조작은 메뉴와 여러 작업을 사용하지 않고 보기 모드에서 셀에 대한 직접 작업을 통해 수행되었습니다.
11. 유연한 보고 옵션. 측정은 사용자가 원하는 방식으로 보고서에 배치되어야 합니다.
12. 제한 없는

4. OLAP 제품의 분류.

5. OLAP 클라이언트의 작동 원리.

7. OLAP 기술 적용 분야.

8. 판매 분야에서 분석을 위해 OLAP 기술을 사용하는 예.

1. 기업의 정보 구조에서 OLAP의 위치.

"OLAP"이라는 용어는 "데이터 웨어하우스"(데이터 웨어하우스)라는 용어와 불가분의 관계에 있습니다.

스토리지의 데이터는 비즈니스 프로세스를 자동화하도록 설계된 운영 체제(OLTP 시스템)에서 가져옵니다. 또한 리포지토리는 통계 보고서와 같은 외부 소스에서 보충할 수 있습니다.

리포지토리의 임무는 분석을 위한 "원료"를 한 곳에서 간단하고 이해하기 쉬운 구조로 제공하는 것입니다.

별도의 저장소의 출현을 정당화하는 또 다른 이유가 있습니다. 운영 정보에 대한 복잡한 분석 쿼리는 회사의 현재 작업을 늦추고 오랫동안 테이블을 차단하고 서버 리소스를 점유합니다.

스토리지 아래에서 반드시 거대한 데이터 축적이 아님을 이해할 수 있습니다. 가장 중요한 것은 분석에 편리하다는 것입니다.

중앙 집중화와 편리한 구조화는 분석가가 필요로 하는 모든 것과는 거리가 멉니다. 결국 그는 여전히 정보를 보고 시각화하는 도구가 필요합니다. 단일 리포지토리를 기반으로 구축된 기존 보고서에도 유연성이 부족합니다. 원하는 데이터 보기를 얻기 위해 "꼬임", "확장" 또는 "축소"할 수 없습니다. 데이터를 간단하고 편리하게 확장 및 축소할 수 있는 도구가 있었으면 좋겠습니다! OLAP는 그러한 도구 중 하나입니다.

OLAP는 데이터 웨어하우스의 필수 속성은 아니지만 이 데이터 웨어하우스에 축적된 정보를 분석하는 데 점점 더 많이 사용됩니다.

기업의 정보 구조에서 OLAP의 위치(그림 1).

그림 1. 장소OLAP 기업의 정보 구조에서

운영 데이터는 다양한 소스에서 수집되고 정리되고 통합되어 관계형 저장소에 저장됩니다. 동시에 이미 다음을 사용하여 분석에 사용할 수 있습니다. 다양한 수단건물 보고서. 그런 다음 OLAP 분석을 위해 데이터(전체 또는 부분)가 준비됩니다. 특수 OLAP 데이터베이스에 로드하거나 관계형 저장소에 둘 수 있습니다. 가장 중요한 요소는 메타데이터, 즉 데이터의 구조, 배치 및 변환에 대한 정보입니다. 덕분에 다양한 스토리지 구성 요소의 효과적인 상호 작용이 보장됩니다.

요약하면 OLAP를 웨어하우스에 축적된 데이터의 다차원 분석을 위한 도구 세트로 정의할 수 있습니다.

2. 운영 분석 데이터 처리.

OLAP의 개념은 다차원 데이터 표현의 원리를 기반으로 합니다. 1993년 EF Codd는 관계형 모델의 단점을 언급하면서 "다차원, 즉 기업 분석가가 가장 이해할 수 있는 방식으로 데이터를 결합, 보기 및 분석할 수 없음"을 지적하고 관계형 DBMS의 기능을 확장하고 다차원 분석을 특징으로 포함하는 OLAP 시스템.

Codd에 따르면 데이터에 대한 다차원적 개념적 관점은 특정 데이터 집합을 분석할 수 있는 여러 독립적인 차원으로 구성된 다중 관점입니다.

다차원에 대한 동시 분석을 다변량 분석이라고 합니다. 각 차원에는 일련의 연속적인 일반화 수준으로 구성된 데이터 통합 ​​방향이 포함되며, 각 상위 수준은 해당 차원에 대한 더 높은 수준의 데이터 집계에 해당합니다.

따라서 계약자 차원은 "엔터프라이즈 - 세분화 - 부서 - 직원" 일반화 수준으로 구성된 통합 방향으로 결정할 수 있습니다. 시간 차원은 두 개의 통합 방향인 "년 - 분기 - 월 - 일" 및 "주 - 일"을 포함할 수도 있습니다. 월과 주를 기준으로 계산하는 시간은 호환되지 않기 때문입니다. 이 경우, 각각의 측정에 대해 원하는 정보 상세 수준을 임의로 선택하는 것이 가능해진다.

하강(드릴다운) 작업은 더 높은 수준의 통합에서 더 낮은 수준으로의 이동에 해당합니다. 반대로 들어 올리는 동작(롤업)은 낮은 수준에서 높은 수준으로 이동하는 것을 의미합니다(그림 2).

그림 2.데이터 통합의 차원 및 방향

3. 운영 분석 처리 수단에 대한 요구 사항.

다차원적 접근은 관계적 접근과 거의 동시에 그리고 병렬적으로 발생했습니다. 그러나 90년대 중반부터 시작하여
1993, 관심 MDBMS일반화되기 시작했다. 관계적 접근의 창시자 중 한 사람의 새로운 정책 기사가 등장한 것은 올해였습니다. E. 코다, 그는 구현 수단에 대한 12가지 기본 요구 사항을 공식화했습니다. OLAP(1 번 테이블).

1 번 테이블.

OLAP 클래스 소프트웨어 제품 평가 규칙

OLAP의 사실상 정의가 된 이러한 요구 사항 집합은 권장 사항으로 간주되어야 하며 모든 요구 사항을 이상적으로 완전하게 준수하는 정도에 따라 개별 제품을 판단해야 합니다.

나중에 Codd의 정의는 OLAP 애플리케이션이 공유된 다차원 정보를 신속하게 분석할 수 있는 기능을 제공해야 하는 이른바 FASMI 테스트로 재작업되었습니다.

Codd의 12가지 규칙을 기억하는 것은 대부분의 사람들에게 너무 부담스럽습니다. 5개의 키워드만으로 OLAP 정의를 요약할 수 있다는 것이 밝혀졌습니다. 공유된 다차원 정보의 빠른 분석 - 또는 간단히 - FASMI(영어에서 번역됨:에프 엉덩이 ㅏ 의 분석 에스 공유 중 초차원 나 정보).

이 정의는 1995년 초에 처음 공식화되었으며 그 이후로 개정이 필요하지 않았습니다.

빠른 ( 빠른 ) - 시스템이 약 5초 이내에 사용자에게 대부분의 응답을 제공해야 함을 의미합니다. 동시에 가장 간단한 요청은 1초 이내에 처리되며 20초 이상은 매우 적습니다. 연구에 따르면 최종 사용자는 30초 후에 결과가 수신되지 않으면 프로세스가 실패하는 것으로 인식합니다.

언뜻 보기에는 며칠이 걸리지 않은 1분 만에 보고서를 받으면 사용자가 기다리는 동안 매우 빨리 지루해 하고 프로젝트의 성공률이 덜 상세한 분석을 하는 경우에도 즉각적인 응답이 가능합니다.

분석(분석)이는 시스템이 주어진 애플리케이션에 특정한 논리적 및 통계적 분석을 처리할 수 있고 최종 사용자가 액세스할 수 있는 형식으로 유지되도록 보장한다는 것을 의미합니다.

이 분석이 공급업체의 자체 도구에서 수행되는지 아니면 스프레드시트와 같은 관련 외부 소프트웨어 제품에서 수행되는지 여부는 그다지 중요하지 않으며, 단순히 필요한 모든 분석 기능이 최종 사용자에게 직관적인 방식으로 제공되어야 합니다. 분석 도구에는 시계열 분석, 비용 할당, 통화 전송, 대상 검색, 다차원 구조 변경, 비절차적 모델링, 예외 감지, 데이터 추출 및 기타 애플리케이션 종속 작업과 같은 특정 절차가 포함될 수 있습니다. 이러한 기능은 대상 방향에 따라 제품마다 크게 다릅니다.

SHARED(공유) 이는 시스템이 모든 기밀 보호 요구 사항(아마도 셀 수준까지)을 시행하고 다중 쓰기 액세스가 필요한 경우 적절한 수준에서 수정 잠금을 시행함을 의미합니다. 모든 애플리케이션이 데이터를 다시 쓸 필요는 없습니다. 그러나 그러한 응용 프로그램의 수가 증가하고 있으며 시스템은 시기 적절하고 안전한 방식으로 여러 수정 사항을 처리할 수 있어야 합니다.

다차원 - 이것이 핵심 요구 사항입니다. OLAP를 한 단어로 정의해야 한다면 선택하겠습니다. 시스템은 계층 및 다중 계층에 대한 완전한 지원을 포함하여 데이터의 다차원 개념 표현을 제공해야 합니다. 이것이 비즈니스 및 조직을 분석하는 가장 논리적인 방법이기 때문입니다. 응용 프로그램에 따라 다르기 때문에 처리해야 하는 최소 차원 수는 없으며 대부분의 OLAP 제품은 목표로 하는 시장에 충분한 차원을 가지고 있습니다.

정보 - 다야. 필요한 정보는 필요한 곳에서 얻어야 합니다. 그러나 많은 것은 응용 프로그램에 따라 다릅니다. 다양한 제품의 성능은 저장할 수 있는 기가바이트가 아니라 처리할 수 있는 입력의 측면에서 측정됩니다. 제품의 성능은 매우 다양합니다. 가장 큰 OLAP 제품은 가장 작은 제품보다 최소 천 배 많은 데이터를 처리할 수 있습니다. 이와 관련하여 데이터 복제, 필요한 RAM, 디스크 공간 사용량, 성능, 정보 저장소와의 통합 등을 포함하여 고려해야 할 많은 요소가 있습니다.

FASMI 테스트는 OLAP이 초점을 맞추고 있는 목표에 대한 합리적이고 이해할 수 있는 정의입니다.

4. 분류OLAP- 제품.

그래서 OLAP의 본질은 분석을 위한 초기 정보가 다차원 입방체 형태로 제공되고 임의로 조작하여 필요한 정보 섹션인 보고서를 얻을 수 있다는 사실에 있습니다. 동시에 최종 사용자는 큐브를 다양한 섹션(차원)의 데이터(팩트)를 자동으로 요약하는 다차원 동적 테이블로 보고 계산 및 보고서 형식을 대화식으로 관리할 수 있습니다. 이러한 작업이 수행됩니다 OLAP 기계(또는 기계 OLAP 컴퓨팅).

현재까지 전 세계적으로 많은 제품이 개발되었습니다. OLAP -기술. 더 쉽게 탐색하려면 분류를 사용하십시오. OLAP - 제품 : 분석을 위한 데이터를 저장하는 방식 및 위치별 OLAP - 자동차. 각 카테고리에 대해 자세히 살펴보겠습니다. OLAP 제품.

데이터 저장 방식에 따른 분류

다차원 큐브는 소스 및 집계 데이터를 기반으로 작성됩니다. 큐브의 원본 데이터와 집계 데이터는 모두 관계형 데이터베이스와 다차원 데이터베이스에 모두 저장할 수 있습니다. 따라서 현재 데이터를 저장하는 세 가지 방법이 있습니다. MOLAP(다차원 OLAP), ROLAP(관계형 OLAP) 및 HOLAP(하이브리드 OLAP) ). 각기, OLAP -데이터 저장 방법에 따라 제품은 세 가지 유사한 범주로 나뉩니다.

1. 몰랩의 경우 , 소스 및 집계 데이터는 다차원 데이터베이스 또는 다차원 로컬 큐브에 저장됩니다.

2. 롤랩에서 - 제품, 소스 데이터는 관계형 데이터베이스 또는 플랫에 저장됩니다. 로컬 테이블파일 서버에서. 집계 데이터는 동일한 데이터베이스의 서비스 테이블에 배치할 수 있습니다. 요청 시 관계형 데이터베이스에서 다차원 큐브로의 데이터 변환이 발생합니다. OLAP 도구.

3. 사용하는 경우헉 아키텍처에서 소스 데이터는 관계형 데이터베이스에 남아 있는 반면 집계는 다차원 데이터베이스에 배치됩니다. 건물 OLAP -요청 시 큐브 수행 OLAP - 관계형 및 다차원 데이터를 기반으로 하는 도구.

위치 분류 OLAP- 자동차.

이를 바탕으로 OLAP - 제품은 다음과 같이 나뉩니다. OLAP 서버 및 OLAP 클라이언트:

· 서버 OLAP에서 - 집계 데이터의 계산 및 저장 수단은 별도의 프로세스인 서버에서 수행됩니다. 클라이언트 응용 프로그램은 서버에 저장된 다차원 큐브에 대한 쿼리 결과만 받습니다. 일부 OLAP -서버는 관계형 데이터베이스에서만 데이터 저장을 지원하며 일부는 다차원 데이터베이스에서만 지원합니다. 많은 현대 OLAP -서버는 데이터를 저장하는 세 가지 방법을 모두 지원합니다.MOLAP, ROLAP 및 HOLAP.

몰랩.

몰랩은 다차원 온라인 분석 처리,즉, 다차원 OLAP.즉, 서버는 다차원 데이터베이스(MBD)를 사용하여 데이터를 저장합니다. MDB를 사용하는 의미는 분명합니다. 다차원 데이터를 효율적으로 저장할 수 있어 데이터베이스 쿼리를 신속하게 처리할 수 있는 수단을 제공합니다. 데이터는 데이터 원본에서 다차원 데이터베이스로 전송된 다음 데이터베이스가 집계됩니다. 사전 계산은 요약 데이터가 이미 계산되었기 때문에 OLAP 쿼리의 속도를 높이는 것입니다. 쿼리 시간은 특정 데이터에 액세스하고 계산을 수행하는 데 필요한 시간만으로 함수가 됩니다. 이 방법은 작업이 한 번 완료되고 그 결과가 계속해서 사용된다는 개념을 지원합니다. 다차원 데이터베이스는 비교적 새로운 기술입니다. MDB를 사용하면 대부분의 새로운 기술과 동일한 단점이 있습니다. 즉, 관계형 데이터베이스(RDB)만큼 안정적이지 않고 동일한 정도로 최적화되어 있지 않습니다. 다른 약점 MDB는 데이터 집계 과정에서 대부분의 다차원 데이터베이스를 사용할 수 없기 때문에 새로운 정보를 분석에 사용할 수 있게 되기까지 시간이 걸립니다.

롤.

롤랩은 관계형 온라인 분석 처리,즉, 관계형 OLAP입니다.ROLAP이라는 용어는 OLAP 서버가 관계형 데이터베이스를 기반으로 함을 의미합니다. 소스 데이터는 검색 시간을 줄이기 위해 일반적으로 별 모양 또는 눈송이 스키마로 관계형 데이터베이스에 입력됩니다. 서버는 최적화된 SQL 쿼리를 사용하여 다차원 데이터 모델을 제공합니다.

다차원 데이터베이스보다 관계형 데이터베이스를 선택하는 데에는 여러 가지 이유가 있습니다. RDB는 최적화의 기회가 많은 잘 정립된 기술입니다. 실제 사용으로 인해 더 성숙한 제품이 탄생했습니다. 또한 RDB는 MDB보다 더 많은 양의 데이터를 지원합니다. 그들은 단지 그러한 볼륨을 위해 설계되었습니다. RDB에 대한 주요 주장은 SQL을 사용하여 대규모 데이터베이스에서 정보를 검색하는 데 필요한 쿼리의 복잡성입니다. 경험이 없는 SQL 프로그래머는 MDB에서 수행하기가 훨씬 쉬운 이러한 쿼리를 실행하려고 시도함으로써 귀중한 시스템 리소스에 쉽게 부담을 줄 수 있습니다.

집계/사전 집계 데이터.

빠른 쿼리 구현은 OLAP에 필수적입니다. 이것은 OLAP의 기본 원리 중 하나입니다. 직관적으로 데이터를 조작할 수 있으려면 빠른 정보 검색이 필요합니다. 일반적으로 정보를 얻기 위해 수행해야 하는 계산이 많을수록 응답이 느려집니다. 따라서 쿼리 구현 시간을 줄이기 위해 일반적으로 가장 자주 액세스하지만 계산이 필요한 정보 조각을 미리 집계합니다. 즉, 카운트된 다음 새 데이터로 데이터베이스에 저장됩니다. 미리 계산할 수 있는 데이터 유형의 예로는 월별, 분기별 또는 연간 판매 수치와 같은 요약 데이터를 들 수 있으며 실제 입력된 데이터는 일일 수치입니다.

공급업체마다 매개변수를 선택하는 방법이 다르므로 사전 집계 및 사전 계산된 여러 값이 필요합니다. 집계 접근 방식은 데이터베이스와 쿼리 실행 시간 모두에 영향을 줍니다. 더 많은 값이 계산되면 사용자가 이미 계산된 값을 요청할 확률이 증가하므로 초기 값을 계산을 위해 요청할 필요가 없기 때문에 응답 시간이 단축됩니다. 그러나 가능한 모든 값을 계산하면 이것은 최고의 솔루션- 이 경우 데이터베이스의 크기가 크게 증가하여 관리할 수 없게 되고 집계 시간이 너무 길어집니다. 또한 데이터베이스에 수치가 추가되거나 변경되는 경우에는 새로운 데이터에 의존하는 미리 계산된 값에 이 정보를 반영해야 한다. 따라서 미리 계산된 값이 많은 경우 데이터베이스 업데이트에도 오랜 시간이 걸릴 수 있습니다. 데이터베이스는 일반적으로 집계 중에 오프라인으로 작동하므로 집계 시간이 너무 길지 않은 것이 바람직합니다.

OLAP 클라이언트가 다르게 구성됩니다. 다차원 큐브의 구성 및 OLAP -계산은 클라이언트 컴퓨터의 메모리에서 수행됩니다.OLAP -고객도 다음과 같이 나뉩니다. ROLAP 및 MOLAP.그리고 일부는 두 데이터 액세스 옵션을 모두 지원할 수 있습니다.

이러한 접근 방식에는 각각 장단점이 있습니다. 많은 경우에 클라이언트 도구보다 서버 도구의 장점에 대한 일반적인 믿음과는 달리 OLAP -사용자를 위한 클라이언트는 사용하기에 더 효율적이고 수익성이 있을 수 있습니다. OLAP 서버.

클라이언트 OLAP 도구를 사용한 분석 응용 프로그램의 개발은 빠른 프로세스이며 수행자에 대한 특별한 교육이 필요하지 않습니다. 데이터베이스의 물리적 구현을 ​​알고 있는 사용자는 개발할 수 있습니다. 분석적 응용 IT 전문가의 개입 없이 독립적으로.

OLAP 서버를 사용할 때 서버에 큐브를 만들고 클라이언트 응용 프로그램을 개발하려면 때때로 다른 공급업체로부터 2개의 다른 시스템을 배워야 합니다.

OLAP 클라이언트는 큐브를 설명하고 큐브에 대한 사용자 인터페이스를 사용자 정의하기 위한 단일 시각적 인터페이스를 제공합니다.

그렇다면 어떤 경우에 사용자에게 OLAP 클라이언트를 사용하는 것이 OLAP 서버를 사용하는 것보다 더 효율적이고 유익할 수 있습니까?

· 적용의 경제성 OLAP - 서버는 데이터 양이 너무 많아 감당할 수 없을 때 발생 OLAP -client, 그렇지 않으면 후자의 사용이 더 정당합니다. 이 경우 OLAP -고객은 고성능 특성과 저렴한 비용을 결합합니다.

· 강력한 분석가 PC는 다음을 지지하는 또 다른 주장입니다. OLAP - 클라이언트. 적용시 OLAP -server 이 용량은 사용되지 않습니다.

OLAP 클라이언트의 다른 이점은 다음과 같습니다.

· 구현 및 유지 관리 비용 OLAP - 고객은 비용보다 현저히 낮습니다. OLAP 서버.

· 사용 OLAP - 네트워크를 통한 머신 데이터 전송이 내장된 클라이언트는 한 번만 수행됩니다. 함으로써 OLAP - 작업 새 데이터 스트림이 생성되지 않습니다.

5. 운영 원칙 OLAP- 클라이언트.

클라이언트 도구를 사용하여 OLAP 응용 프로그램을 만드는 프로세스를 고려하십시오(그림 1).

그림 1.ROLAP 클라이언트 도구를 사용하여 OLAP 응용 프로그램 만들기

ROLAP 클라이언트의 작동 원리는 소스 데이터의 물리적 구조가 숨겨져 있는 의미 계층에 대한 예비 설명입니다. 이 경우 데이터 소스는 로컬 테이블, RDBMS일 수 있습니다. 지원되는 데이터 소스 목록은 특정 소프트웨어 제품에 따라 결정됩니다. 그 후 사용자는 주제 영역 측면에서 자신이 이해하는 개체를 독립적으로 조작하여 큐브 및 분석 인터페이스를 생성할 수 있습니다.

OLAP 서버 클라이언트의 작동 원리는 다릅니다. OLAP 서버에서 큐브를 생성할 때 사용자는 데이터베이스의 물리적 설명을 조작합니다. 이렇게 하면 큐브 자체에 사용자 정의 설명이 생성됩니다. OLAP Server 클라이언트는 큐브용으로만 구성됩니다.

의미 계층을 생성할 때 데이터 소스(판매 및 거래 테이블)는 최종 사용자가 이해할 수 있는 용어로 설명되고 "제품" 및 "거래"로 바뀝니다. "제품" 테이블의 "ID" 필드는 "코드"로, "이름"은 "제품" 등으로 이름이 바뀝니다.

그런 다음 판매 비즈니스 개체가 생성됩니다. 비즈니스 개체는 다차원 큐브가 형성되는 기반이 되는 플랫 테이블입니다. 비즈니스 개체를 생성할 때 "제품" 및 "거래" 테이블은 제품의 "코드" 필드로 결합됩니다.테이블의 모든 필드가 보고서에 표시되어야 하는 것은 아니므로 비즈니스 개체는 "항목", "날짜" 및 "금액" 필드만 사용합니다.

이 예에서는 비즈니스 개체 "Sales"를 기반으로 월별 상품 판매에 대한 보고서가 생성되었습니다.

대화형 보고서로 작업할 때 사용자는 동일한 간단한 마우스 움직임으로 필터링 및 그룹화 조건을 설정할 수 있습니다. 이 시점에서 ROLAP 클라이언트는 캐시의 데이터에 액세스합니다. OLAP 서버의 클라이언트는 다차원 데이터베이스에 대한 새 쿼리를 생성합니다. 예를 들어, 판매 보고서에 제품 필터를 적용하면 관심 있는 제품의 판매에 대한 보고서를 얻을 수 있습니다.

OLAP 응용 프로그램에 대한 모든 설정은 전용 메타데이터 저장소, 응용 프로그램 또는 다차원 데이터베이스 시스템 저장소에 저장할 수 있습니다.구현은 특정 소프트웨어 제품에 따라 다릅니다.

이러한 응용 프로그램에 포함된 모든 것은 인터페이스의 표준 보기, 미리 정의된 기능 및 구조, 다소 표준적인 상황에 대한 빠른 수정입니다. 예를 들어, 금융 패키지가 인기가 있습니다. 사전 구축된 금융 애플리케이션을 통해 전문가는 데이터베이스 구조나 공통 양식 및 보고서를 설계하지 않고도 친숙한 금융 상품을 사용할 수 있습니다.

인터넷은 새로운 형태의 고객입니다. 또한 새로운 기술의 도장을 찍습니다. 한 무리의 인터넷 솔루션일반적으로 기능과 특히 OLAP 솔루션의 품질이 크게 다릅니다. 인터넷을 통해 OLAP 보고서를 생성하면 많은 이점이 있습니다. 가장 중요한 것은 정보 액세스를 위한 특수 소프트웨어가 필요하지 않다는 것입니다. 이것은 회사에 많은 시간과 비용을 절약합니다.

6. OLAP 애플리케이션 아키텍처 선택.

정보 분석 시스템을 구현할 때 OLAP 애플리케이션의 아키텍처를 선택하는 데 실수를 하지 않는 것이 중요합니다. 온라인 분석 프로세스("온라인 분석 처리")라는 용어를 문자 그대로 번역하면 시스템에 입력되는 데이터가 신속하게 분석된다는 의미에서 문자 그대로 해석되는 경우가 많습니다. 이것은 망상입니다. 분석의 효율성은 시스템의 데이터를 실시간으로 업데이트하는 것과 전혀 관련이 없습니다. 이 특성은 사용자 요청에 대한 OLAP 시스템의 응답 시간을 나타냅니다. 동시에 분석된 데이터는 예를 들어 스토리지의 데이터가 하루에 한 번 업데이트되는 경우 "어제" 정보의 스냅샷인 경우가 많습니다.

이러한 맥락에서 OLAP를 "대화형 분석 처리"로 번역하는 것이 더 정확합니다. 규제 보고서를 준비하는 시스템과 OLAP 시스템을 구별하는 것은 대화식 모드에서 데이터를 분석하는 기능입니다.

OLAP의 조상인 E. Codd의 공식화에서 대화형 처리의 또 다른 기능은 "다차원, 즉 기업 분석가가 가장 이해할 수 있는 방식으로 데이터를 결합, 보기 및 분석"하는 기능입니다. Codd 자신에게 OLAP라는 용어는 개념적 수준(다차원)에서 데이터를 표시하는 매우 구체적인 방법을 나타냅니다. 물리적 수준에서 데이터는 관계형 데이터베이스에 저장될 수 있지만 실제로 OLAP 도구는 데이터가 하이퍼큐브 형태로 구성된 다차원 데이터베이스에서 작동하는 경향이 있습니다(그림 1).

그림 1. OLAP- 큐브(하이퍼큐브, 메타큐브)

동시에 이러한 데이터의 관련성은 하이퍼큐브가 새 데이터로 채워지는 순간에 결정됩니다.

다차원 데이터베이스를 구축하는 시간은 데이터가 적재되는 양에 따라 크게 달라지므로 이 양을 제한하는 것이 합리적입니다. 그러나 분석 가능성을 좁히고 사용자가 관심 있는 모든 정보에 액세스하지 못하도록 하는 방법은 무엇입니까? 두 가지 대체 경로가 있습니다. 분석 후 쿼리("먼저 분석 - 추가 정보 요청") 및 쿼리 후 분석("먼저 데이터 쿼리 - 다음 분석")입니다.

첫 번째 경로의 추종자는 일반화된 정보를 다차원 데이터베이스에 로드할 것을 제안합니다(예: 부서에 대한 월별, 분기별, 연간 결과). 데이터를 구체화해야 하는 경우 사용자는 필수 선택 항목이 포함된 관계형 데이터베이스에 대한 보고서를 생성하라는 메시지가 표시됩니다(예: 주어진 부서의 일별 또는 선택한 부서의 월 및 직원별).

반대로 두 번째 방법의 지지자는 사용자가 우선 분석할 데이터를 결정하고 작은 다차원 데이터베이스인 마이크로큐브에 로드할 것을 제안합니다. 두 접근 방식 모두 개념 수준에서 다르며 장단점이 있습니다.

두 번째 접근 방식의 장점은 사용자가 "마이크로큐브"라는 다차원 보고서 형태로 수신하는 정보의 "신선함"을 포함합니다. 마이크로큐브는 실제 관계형 데이터베이스에서 방금 요청한 정보를 기반으로 형성됩니다. 마이크로큐브 작업은 대화식 모드로 수행됩니다. 마이크로큐브 프레임워크 내에서 정보 조각과 세부 정보를 얻는 것이 즉시 수행됩니다. 또 다른 긍정적인 점은 구조 설계와 마이크로큐브 채우기가 데이터베이스 관리자의 참여 없이 "즉시" 사용자에 의해 수행된다는 것입니다. 그러나 이 접근 방식은 심각한 단점도 있습니다. 사용자는 큰 그림을 보지 않고 연구 방향을 미리 결정해야 합니다. 그렇지 않으면 요청된 마이크로큐브가 너무 작아 관심 있는 모든 데이터가 포함되지 않을 수 있으며 사용자는 새 마이크로큐브를 요청한 다음 새 마이크로큐브를 요청한 다음 새 마이크로큐브를 요청해야 합니다. 쿼리 분석 접근 방식은 같은 이름의 회사의 BusinessObjects 도구와 Company Contour 플랫폼의 도구를 구현합니다.인터소프트랩.

분석 후 쿼리 접근 방식을 사용하면 다차원 데이터베이스에 로드되는 데이터 양이 상당히 많을 수 있으며 규칙에 따라 채우기를 수행해야 하며 많은 시간이 소요될 수 있습니다. 그러나 이러한 모든 단점은 사용자가 어떤 조합으로든 필요한 거의 모든 데이터에 액세스할 수 있게 되면 나중에 보상을 받습니다. 관계형 데이터베이스의 원본 데이터에 대한 참조는 예를 들어 특정 송장에 대한 자세한 정보가 필요한 경우 최후의 수단으로만 수행됩니다.

단일 다차원 데이터베이스의 작동은 실제로 액세스하는 사용자 수에 영향을 받지 않습니다. 제한된 경우의 마이크로큐브 수가 사용자 수와 동일한 속도로 증가할 수 있는 쿼리 후 분석 접근 방식과 달리 사용 가능한 데이터만 읽습니다.

이 접근 방식을 사용하면 IT 서비스에 대한 부하가 증가하고 관계형 서비스와 함께 다차원 데이터베이스도 제공해야 합니다.적시에 책임이있는 것은 이러한 서비스입니다. 자동 업데이트다차원 데이터베이스의 데이터.

"분석 후 쿼리" 접근 방식의 가장 유명한 대표자는 Cognos의 PowerPlay 및 Impromptu 도구입니다.

접근 방식과 이를 구현하는 도구의 선택은 주로 추구하는 목표에 따라 달라집니다. 예산 절약과 최종 사용자 서비스 품질 향상 사이에서 항상 균형을 유지해야 합니다. 동시에 전략 계획에서 정보 및 분석 시스템의 생성이 자동화 비용을 피하지 않고 경쟁 우위를 달성한다는 목표를 추구한다는 점을 고려해야 합니다. 예를 들어, 기업 정보 및 분석 시스템은 회사에 대한 필요하고 시기적절하며 신뢰할 수 있는 정보를 제공할 수 있으며, 이 정보를 공개하면 잠재적 투자자를 위해 이 회사의 투명성과 예측 가능성을 보장할 수 있으며 이는 필연적으로 투자 매력의 조건이 됩니다.

7. OLAP 기술 적용 분야.

OLAP는 다인자 데이터를 분석하는 작업이 있는 모든 곳에서 적용할 수 있습니다. 일반적으로 하나 이상의 설명 열(차원)과 숫자(측정값 또는 사실)가 있는 열이 있는 데이터가 있는 테이블이 있는 경우 일반적으로 OLAP 도구는 보고서를 분석하고 생성하는 데 효과적인 도구입니다.

실생활에서 가져온 OLAP 기술의 일부 응용 분야를 고려하십시오.

1. 판매.

판매 구조 분석을 기반으로 상품 범위 변경, 가격 변경, 매장 폐쇄 및 개설, 딜러와의 계약 해지 및 서명, 광고 캠페인 수행 또는 종료 등 경영상의 의사 결정에 필요한 문제를 해결합니다.

2. 구매.

작업은 판매 분석의 반대입니다. 많은 기업이 공급업체로부터 부품과 재료를 구매합니다. 상인은 재판매를 위해 상품을 구매합니다. 계획부터 조달 분석까지 가능한 많은 작업이 있습니다. 돈과거 경험을 바탕으로, 관리자에 대한 통제공급자 선택.

3. 가격.

구매 분석은 시장 가격 분석과 병합됩니다. 이 분석의 목적은 비용을 최적화하고 가장 유리한 제안을 선택하는 것입니다.

4. 마케팅.

마케팅 분석이란 서비스의 구매자 또는 고객-소비자 분석 영역만을 의미합니다. 이 분석의 임무는 상품의 올바른 위치 지정, 타겟 광고를 위한 구매자 그룹 식별 및 구색 최적화입니다. 이 경우 OLAP의 임무는 사용자에게 데이터 분석 과정에서 직관적으로 발생하는 질문에 대한 답을 생각의 속도로 빠르게 얻을 수 있는 도구를 제공하는 것입니다.

5. 창고.

조직에 창고 회계가 있는 경우 상품, 창고 유형별 창고의 재고 잔액 구조 분석, 상품의 유통 기한 분석, 수취인별 선적 분석 및 기업에 중요한 기타 여러 유형의 분석이 가능합니다.

6. 현금 흐름.

이것은 많은 학교와 방법이있는 전체 분석 영역입니다. OLAP 기술은 이러한 기술을 구현하거나 개선하기 위한 도구 역할을 할 수 있지만 대체할 수는 없습니다. 비현금 및 현금 자금의 현금 흐름은 흐름을 최적화하고 유동성을 보장하기 위해 비즈니스 운영, 거래 상대방, 통화 및 시간의 맥락에서 분석됩니다. 측정 구성은 비즈니스, 산업, 방법론의 특성에 크게 좌우됩니다.

7. 예산.

OLAP 기술의 가장 비옥한 응용 분야 중 하나입니다. 아무 이유 없이 현대 시스템구성에 예산 분석을 위한 OLAP 툴킷이 없으면 예산 편성이 완전한 것으로 간주되지 않습니다. 대부분의 예산 보고서는 OLAP 시스템을 기반으로 쉽게 작성됩니다. 동시에 보고서는 비용 및 수입 구조 분석, 다른 부서의 특정 항목에 대한 비용 비교, 특정 항목에 대한 비용의 역학 및 추세 분석, 비용 및 수입 분석과 같은 매우 광범위한 질문에 대한 답변을 제공합니다. 이익.

8. 회계 계정.

계정 번호로 구성되고 들어오는 잔액, 회전율 및 나가는 잔액을 포함하는 고전적인 대차 대조표는 OLAP 시스템에서 완벽하게 분석할 수 있습니다. 또한 OLAP 시스템은 다중 지점 조직의 통합 잔액, 월별, 분기별 및 연간 잔액, 계정 계층별 집계 잔액, 분석 특성에 따른 분석 잔액을 자동으로 매우 빠르게 계산할 수 있습니다.

9. 재무 보고.

기술적으로 구축된 보고 시스템은 특정 보고서를 얻기 위해 다양한 섹션에서 그룹화하고 요약해야 하는 날짜 값이 있는 명명된 지표 세트에 불과합니다. 이 경우 보고서 표시 및 인쇄는 OLAP 시스템에서 가장 쉽고 저렴하게 구현됩니다. 어쨌든 기업의 내부 보고 시스템은 보수적이지 않으며 보고서를 작성하고 다차원적 운영 분석 기능을 확보하는 기술적 작업에 드는 비용을 절약하기 위해 재설계될 수 있습니다.

10. 사이트 트래픽.

인터넷 서버 로그 파일은 본질적으로 다차원적이므로 OLAP 분석에 적합합니다. 사실은 방문 횟수, 조회수, 페이지에서 보낸 시간 및 로그에서 사용할 수 있는 기타 정보입니다.

11. 생산량.

이것은 통계 분석의 또 다른 예입니다. 따라서 재배된 감자, 제련된 철강, 공산품의 양을 분석할 수 있습니다.

12. 소모품의 소비.

냉각수, 세척액, 오일, 걸레, 사포 등 수백 가지의 소모품을 소비하는 수십 개의 작업장으로 구성된 공장을 상상해 보십시오. 정확한 계획과 비용 최적화를 위해서는 소모품의 실제 소비에 대한 철저한 분석이 필요합니다.

13. 구내 사용.

또 다른 유형의 통계 분석. 예: 교실, 임대 건물 및 건물의 작업량 분석, 회의실 사용 등

14. 기업의 직원 이직률.

지점, 부서, 직업, 교육 수준, 성별, 연령, 시간의 맥락에서 기업의 직원 이직률 분석.

15. 여객 운송.

계절별, 목적지별, 객차종류(클래스), 열차종류(항공기)별 판매매수 및 금액분석.

이 목록은 적용 분야에 국한되지 않습니다. OLAP - 기술. 예를 들어 기술을 고려하십시오. OLAP - 판매 분석.

8. 사용 예 OLAP - 판매 분야의 분석을 위한 기술.

다차원 데이터 표현 설계 OLAP - 분석은 측정 맵의 형성으로 시작됩니다. 예를 들어, 매출을 분석할 때 개별 시장 부문(개발 중인, 안정적, 크고 작은 고객, 신규 고객 가능성 등)을 식별하고 제품, 지역, 고객, 시장 부문, 유통별로 판매량을 평가하는 것이 유용할 수 있습니다. 채널 및 주문 크기. 이러한 방향은 판매의 다차원 표현, 즉 차원의 구조의 좌표 그리드를 형성합니다.

모든 기업의 활동이 제 시간에 진행되기 때문에 분석에서 발생하는 첫 번째 질문은 비즈니스 개발의 역학에 대한 질문입니다. 시간 축의 올바른 구성은 이 질문에 대한 질적 답변을 제공할 것입니다. 일반적으로 시간 축은 년, 분기 및 월로 나뉩니다. 아마도 더 많은 주와 일로 나눌 수 있습니다. 시간 차원의 구조는 데이터 수신 빈도를 고려하여 형성됩니다. 정보를 요청하는 빈도에 따라 결정될 수도 있습니다.

"상품군" 차원은 판매되는 상품의 구조를 최대한 반영하도록 설계되었습니다. 동시에 과도한 세부 사항(그룹 수가 표시되어야 함)을 피하고 다른 한편으로 중요한 시장 부문을 놓치지 않기 위해 일정한 균형을 유지하는 것이 중요합니다.

"고객" 차원은 지역별 판매 구조를 반영합니다. 각 차원은 고유한 계층을 가질 수 있습니다. 예를 들어, 이 차원에서 구조는 국가 - 지역 - 도시 - 클라이언트일 수 있습니다.

부서의 성과를 분석하려면 자신만의 차원을 만들어야 합니다. 예를 들어, 두 가지 수준의 계층 구조를 구별할 수 있습니다. 부서와 여기에 포함된 부서는 "Subdivisions" 차원에 반영되어야 합니다.

사실 "시간", "제품", "고객"이라는 차원은 주제 영역의 공간을 완전히 정의합니다.

또한, 이 공간을 조건부 영역으로 나누는 것이 유용하며, 계산된 특성을 기준으로 예를 들어 가치 측면에서 거래량의 범위를 사용합니다. 그런 다음 전체 비즈니스를 수행되는 여러 비용 범위로 나눌 수 있습니다. 이 예에서는 상품 판매 금액, 판매 상품 수, 소득 금액, 거래 수, 고객 수, 제조업체의 구매 수량과 같은 지표로 자신을 제한할 수 있습니다.

OLAP - 분석용 큐브는 다음과 같습니다(그림 2).

그림 2.OLAP– 판매량 분석을 위한 큐브

큐브라고 하는 OLAP의 관점에서 바로 이러한 3차원 배열입니다. 사실, 엄격한 수학의 관점에서 이러한 배열은 항상 큐브가 아닙니다. 실제 큐브의 경우 모든 차원의 요소 수가 같아야 하지만 OLAP 큐브에는 이러한 제한이 없습니다. OLAP 큐브는 3D일 필요가 전혀 없습니다. 해결되는 문제에 따라 2차원 및 다차원이 될 수 있습니다. 심각한 OLAP 제품은 약 20차원으로 설계되었으며, 단순한 데스크탑 애플리케이션은 약 6차원을 지원합니다.

큐브의 모든 요소에서 멀리 채워야합니다. 3 분기에 고객 3에 대한 제품 2 판매에 대한 정보가 없으면 해당 셀의 값이 단순히 결정되지 않습니다.

그러나 큐브 자체는 분석에 적합하지 않습니다. 3차원 입방체를 적절하게 표현하거나 묘사하는 것이 여전히 가능하다면 6에서 19차원상황이 훨씬 더 나쁩니다. 따라서 사용하기 전에 다차원 큐브에서 일반 2차원 테이블을 추출합니다. 이 작업을 큐브 "절단"이라고 합니다. 분석가는 말하자면 관심있는 표시에 따라 큐브의 치수를 가져 와서 "자릅니다". 이러한 방식으로 분석가는 큐브(보고서)의 2차원 조각을 받아 작업합니다. 보고서의 구조는 그림 3에 나와 있습니다.

그림 3분석 보고서 구조

OLAP - 큐브를 자르고 3/4 분기에 대한 판매 보고서를 얻습니다. 다음과 같이 보일 것입니다(그림 4).

그림 43분기 매출 보고서

다른 축을 따라 큐브를 자르고 해당 연도의 제품 그룹 2 판매에 대한 보고서를 얻을 수 있습니다(그림 5).

그림 5제품 판매 분기별 보고서 2

마찬가지로 클라이언트 4와의 관계를 분석할 수 있으며, 클라이언트 레이블에 따라 큐브 절단(그림 6)

그림 6고객에 대한 재화 공급에 대한 보고 4

보고서를 월별로 자세히 설명하거나 클라이언트의 특정 지점에 대한 제품 공급에 대해 이야기할 수 있습니다.

최근에 출판된 "데이터베이스 소개" 시리즈에서(ComputerPress No. 3'2000 - 3'2001 참조) 정보 시스템- 데스크탑 및 서버 DBMS, 데이터 설계 도구, 응용 프로그램 개발 도구 및 비즈니스 인텔리전스 - 현재 우리나라를 포함하여 세계에서 점점 더 대중화되고 있는 전사적 데이터 분석 및 처리 도구. 그러나 이 클래스의 응용 프로그램을 만드는 데 사용되는 비즈니스 인텔리전스 도구 및 기술을 사용하는 문제는 아직 국내 문헌에서 충분히 다루지 않습니다. 새로운 시리즈의 기사에서 우리는 이 격차를 메우고 이러한 애플리케이션의 기반이 되는 기술에 대해 이야기할 것입니다. 구현 예로서 주로 Microsoft의 OLAP 기술(주로 Microsoft의 Analysis Services SQL 서버 2000) 그러나 대부분의 자료가 다른 도구 사용자에게도 유용하기를 바랍니다.

이 시리즈의 첫 번째 기사에서는 다차원 데이터 분석을 위한 기술인 OLAP(On-Line Analytical Processing)의 기본 사항을 다룹니다. 여기에서 우리는 데이터 웨어하우징과 OLAP의 개념, 데이터 웨어하우징과 OLAP 도구에 대한 요구 사항, OLAP 데이터의 논리적 구성, 다차원 분석을 논의할 때 사용되는 기본 용어와 개념을 다룰 것입니다.

데이터 웨어하우스란?

엔터프라이즈 규모의 정보 시스템에는 일반적으로 데이터, 역학, 추세 등의 복잡한 다차원 분석을 위해 설계된 응용 프로그램이 포함됩니다. 이러한 분석은 궁극적으로 의사 결정을 지원하기 위한 것입니다. 종종 이러한 시스템을 의사결정 지원 시스템이라고 합니다.

이에 필요한 정보(보통 정량적)를 보유하지 않고는 경영상의 결정을 내리는 것이 불가능합니다. 이를 위해서는 데이터 웨어하우스(Data Warehouse)의 생성, 즉 수집, 선별 및 전처리통계 분석(및 종종 분석 보고서 작성)을 위해 사용자에게 결과 정보를 제공하기 위한 데이터.

데이터 웨어하우스 개념의 창시자 중 한 명인 Ralph Kimball은 데이터 웨어하우스를 "사람들이 데이터에 액세스할 수 있는 장소"로 설명했습니다(예: Ralph Kimball, "The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses ", John Wiley & Sons, 1996 및 "데이터 웹하우스 툴킷: 웹 기반 데이터 웨어하우스 구축", John Wiley & Sons, 2000). 그는 또한 데이터 웨어하우스에 대한 기본 요구 사항을 공식화했습니다.

• 스토리지에서 고속 데이터 검색 지원;
• 내부 데이터 일관성 지원
• 소위 데이터 조각(슬라이스 및 주사위)을 얻고 비교하는 기능;
• 스토리지의 데이터를 보기 위한 편리한 유틸리티의 가용성;
• 저장된 데이터의 완전성과 신뢰성;
• 양질의 데이터 보충 프로세스를 지원합니다.

동일한 제품의 프레임워크 내에서 나열된 모든 요구 사항을 충족하는 것은 종종 불가능합니다. 따라서 데이터 웨어하우스를 구현하기 위해 일반적으로 여러 제품이 사용되며, 그 중 일부는 실제로 데이터를 저장하는 수단이고, 나머지는 추출 및 보기 수단이며, 나머지는 보충 수단 등입니다.

일반적인 데이터 웨어하우스는 일반적으로 일반적인 관계형 데이터베이스와 다릅니다. 첫째, 기존 데이터베이스는 사용자가 일상적인 작업을 수행하는 데 도움이 되도록 설계되었으며 데이터 웨어하우스는 의사 결정을 내리도록 설계되었습니다. 예를 들어, 제품 판매 및 송장 발행은 거래를 처리하도록 설계된 데이터베이스를 사용하여 이루어지며 수년간의 판매 역학을 분석하여 데이터 웨어하우스를 사용하여 공급업체와의 작업을 계획할 수 있습니다.

둘째, 일반 데이터베이스는 사용자의 작업 과정에서 지속적으로 변경되며 데이터 웨어하우스는 상대적으로 안정적입니다. 일반적으로 그 안의 데이터는 일정에 따라 업데이트됩니다. 필요). 이상적으로, 보충 프로세스는 이미 스토리지에 있는 이전 정보를 변경하지 않고 일정 기간 동안 새 데이터를 추가하는 것입니다.

셋째, 기존 데이터베이스는 웨어하우스에 들어오는 데이터의 소스인 경우가 가장 많습니다. 또한 리포지토리는 통계 보고서와 같은 외부 소스에서 보충할 수 있습니다.

OLAP이란?

의사결정 지원 시스템에는 일반적으로 초기 세트의 다양한 샘플에 대한 집계 데이터를 지각 및 분석에 편리한 형태로 사용자에게 제공하는 수단이 있습니다. 일반적으로 이러한 집계 함수는 축에 매개변수가 포함되고 셀에 매개변수에 의존하는 집계 데이터가 포함되는 다차원(따라서 비관계형) 데이터세트(하이퍼큐브 또는 메타큐브라고도 함)를 형성합니다. 각 축을 따라 데이터를 다양한 세부 수준을 나타내는 계층 구조로 구성할 수 있습니다. 이 데이터 모델 덕분에 사용자는 복잡한 쿼리를 공식화하고 보고서를 생성하며 데이터의 하위 집합을 받을 수 있습니다.

복잡한 다차원 데이터 분석 기술을 OLAP(On-Line Analytical Processing)라고 합니다. OLAP는 데이터 웨어하우징의 핵심 구성 요소입니다. OLAP의 개념은 1993년 저명한 데이터베이스 연구원이자 관계형 데이터 모델의 저자인 Edgar Codd에 의해 설명되었습니다. 위임장, 기술 보고서, 1993). 1995년에 Codd가 요약한 요구 사항을 기반으로 다차원 분석 응용 프로그램에 대한 다음 요구 사항을 포함하는 소위 FASMI 테스트(공유 다차원 정보의 빠른 분석 - 공유 다차원 정보의 빠른 분석)가 공식화되었습니다.

• 사용자에게 허용 가능한 시간(보통 5초 이하)에 분석 결과를 제공하는 것, 비록 덜 상세한 분석을 희생하더라도
• 이 응용 프로그램과 관련된 논리적 및 통계적 분석을 수행하고 최종 사용자가 액세스할 수 있는 형식으로 저장하는 기능
• 적절한 잠금 메커니즘 및 승인된 액세스 도구를 지원하는 데이터에 대한 다중 사용자 액세스
• 계층 및 다중 계층에 대한 완전한 지원을 포함하여 데이터의 다차원 개념 표현(OLAP의 핵심 요구 사항)
• 볼륨 및 저장 위치에 관계없이 필요한 정보에 액세스할 수 있는 기능.

OLAP 기능은 사무용 애플리케이션의 가장 단순한 데이터 분석 도구에서 서버 제품을 기반으로 하는 분산 분석 시스템에 이르기까지 다양한 방식으로 구현될 수 있다는 점에 유의해야 합니다. 그러나 이 기능의 다양한 구현에 대해 이야기하기 전에 논리적인 관점에서 OLAP 큐브가 무엇인지 살펴보겠습니다.

다차원 큐브

이 섹션에서는 OLAP 및 다차원 큐브의 개념을 자세히 살펴보겠습니다. OLAP의 원칙을 설명하는 데 사용할 관계형 데이터베이스의 예로 Microsoft SQL Server 또는 마이크로소프트 액세스식품 도매업에 종사하는 회사의 거래 정보를 저장하는 일반적인 데이터베이스입니다. 이러한 데이터에는 공급자, 고객, 배송 회사, 공급된 상품 목록 및 해당 범주, 주문 및 주문한 상품에 대한 데이터, 회사 직원 목록에 대한 정보가 포함됩니다. 상세 설명 Northwind 데이터베이스는 참조에서 찾을 수 있습니다. 마이크로소프트 시스템 SQL Server 또는 Microsoft Access - 공간 부족으로 인해 여기에 표시하지 않습니다.

OLAP의 개념을 탐색하기 위해 Northwind 데이터베이스의 송장 보기와 제품 및 범주 테이블을 사용하여 주문한 모든 상품 및 발행된 송장의 세부 정보를 반환하는 쿼리를 만들어 보겠습니다.

SELECT dbo.Invoices.Country, dbo.Invoices.City, dbo.Invoices.CustomerName, dbo.Invoices.Salesperson, dbo.Invoices.OrderDate, dbo.Categories.CategoryName, dbo.Invoices.ProductName, dbo.Invoices.Shipper .Invoices.ExtendedPrice FROM dbo.Products INNER JOIN dbo.Categories ON dbo.Products.CategoryID = dbo.Categories.CategoryID INNER JOIN dbo.Invoices ON dbo.Products.ProductID = dbo.Invoices.ProductID

Access 2000에서 유사한 쿼리는 다음과 같습니다.

SELECT Invoices.Country, Invoices.City, Invoices.Customers.CompanyName AS CustomerName, Invoices.Salesperson, Invoices.OrderDate, Categories.CategoryName, Invoices.ProductName, Invoices.Shippers.CompanyName AS ShipperName, Invoices.ExtendedPrice FROM 카테고리 INNER JOIN(송장 INNER JOIN 제품 ON Invoices.ProductID = Products.ProductID) ON Categories.CategoryID = Products.CategoryID;

이 쿼리는 발행된 모든 송장에 대한 정보가 포함된 송장 보기와 주문된 제품 범주 및 제품 자체에 대한 정보가 각각 포함된 범주 및 제품 테이블에 액세스합니다. 이 요청의 결과로 주문한 항목의 범주와 이름, 주문한 날짜, 청구서를 발행한 사람의 이름, 도시, 국가 및 이름을 포함한 일련의 주문 데이터를 받게 됩니다. 주문 회사 및 배송을 담당하는 회사의 이름.

편의를 위해 이 요청을 Invoices1이라고 하는 보기로 저장하겠습니다. 이 표현에 액세스한 결과는 그림 1에 나와 있습니다. 하나 .

이 보기를 기반으로 얻을 수 있는 집계 데이터는 무엇입니까? 일반적으로 다음과 같은 질문에 대한 답변입니다.

• 프랑스 고객이 주문한 총 금액은 얼마입니까?
• 프랑스 고객이 주문하고 Speedy Express에서 배송한 총 주문 금액은 얼마입니까?
• 1997년에 고객이 프랑스에서 주문하고 Speedy Express가 배달한 총 주문 금액은 얼마입니까?

이러한 질문을 SQL 쿼리로 변환해 보겠습니다(표 1).

위 쿼리의 결과는 숫자입니다. 첫 번째 쿼리의 'France' 매개변수를 'Austria' 또는 다른 국가 이름으로 바꾸면 이 쿼리를 다시 실행하여 다른 번호를 얻을 수 있습니다. 모든 국가에서 이 절차를 수행하면 다음 데이터 세트를 얻을 수 있습니다(스니펫은 아래에 표시됨).

집계 값의 결과 집합(이 경우 합계)은 1차원 데이터 집합으로 해석될 수 있습니다. 다음 형식의 GROUP BY 절이 있는 쿼리의 결과로도 동일한 데이터 세트를 얻을 수 있습니다.

국가 선택, 송장에서 SUM(ExtendedPrice)1 GROUP BY 국가

이제 WHERE 절에 두 가지 조건이 포함된 위의 두 번째 쿼리를 살펴보겠습니다. Country 및 ShipperName 매개변수의 가능한 모든 값을 대체하여 이 쿼리를 실행하면 다음 형식의 2차원 데이터 세트가 생성됩니다(스니펫은 아래에 표시됨).

이러한 데이터 세트를 피벗 테이블 또는 크로스 테이블(크로스 테이블, 크로스탭)이라고 합니다. 많은 스프레드시트와 데스크탑 DBMS를 사용하면 Paradox for DOS에서 다음과 같은 테이블을 만들 수 있습니다. 마이크로 소프트 엑셀 2000. 예를 들어 유사한 쿼리가 Microsoft Access 2000에서 다음과 같이 보입니다.

TRANSFORM Sum(Invoices1.ExtendedPrice) AS SumOfExtendedPrice SELECT Invoices1.Country FROM Invoices1 GROUP BY Invoices1.Country PIVOT Invoices1.ShipperName;

이러한 피벗 테이블에 대한 집계 데이터는 일반적인 GROUP BY 쿼리를 사용하여 얻을 수도 있습니다.

SELECT Country,ShipperName, SUM (ExtendedPrice) FROM invokes1 GROUP BY COUNTRY,ShipperName 그러나 이 쿼리의 결과는 피벗 테이블 자체가 아니라 구성을 위한 집계 데이터 집합일 뿐입니다(조각은 아래에 표시됨). ):

위의 세 번째 쿼리에는 WHERE 절에 이미 세 개의 매개변수가 있습니다. 그것들을 변화시킴으로써 우리는 3차원 데이터 세트를 얻을 것입니다(그림 2).

그림에 표시된 큐브의 세포. 2 큐브 축에 위치한 WHERE 절의 쿼리 매개 변수 값에 해당하는 집계 데이터를 포함합니다.

면과 평행한 평면으로 큐브를 자르면 2차원 테이블 세트를 얻을 수 있습니다(단면 및 슬라이스라는 용어로 표시됨).

분명히 큐브의 셀에 포함된 데이터는 GROUP BY 절과 함께 해당 쿼리를 사용하여 얻을 수도 있습니다. 또한 일부 스프레드시트(특히 Microsoft Excel 2000)를 사용하면 3차원 데이터 세트를 작성하고 통합 문서(통합 문서) 시트에 표시된 모서리와 평행한 큐브의 다양한 섹션을 볼 수도 있습니다.

WHERE 절에 4개 이상의 매개변수가 포함된 경우 결과 값 집합(OLAP 큐브라고도 함)은 4차원, 5차원 등이 될 수 있습니다.

다차원 OLAP 큐브가 무엇인지 고려한 후 다차원 데이터 분석에 사용되는 몇 가지 주요 용어와 개념으로 넘어가 보겠습니다.

일부 용어 및 개념

합계와 함께 OLAP 큐브의 셀에는 다른 작업을 수행한 결과가 포함될 수 있습니다. 집계 함수 SQL 언어, MIN, MAX, AVG, COUNT 및 경우에 따라 기타(분산, 표준 편차 등). 요약이라는 용어는 셀의 데이터 값을 설명하는 데 사용됩니다(일반적으로 하나의 큐브에 여러 개 있을 수 있음). 측정값이라는 용어는 계산의 기준이 되는 초기 데이터를 나타내는 데 사용됩니다. , 그리고 차원(러시아어로 번역됨)이라는 용어는 쿼리 매개변수를 나타내는 데 사용됩니다. 일반적으로 OLAP 큐브를 언급할 때는 "차원"으로, 데이터 웨어하우스를 언급할 때는 "차원"이라고 합니다. 축에 그려진 값을 차원의 구성원이라고 합니다.

치수에 대해 말하자면, 축에 표시된 값의 세부 수준이 다를 수 있다는 점을 언급해야 합니다. 예를 들어 고객이 주문한 총 비용에 관심이 있을 수 있습니다. 다른 나라, 또는 시외 고객 또는 개인 고객이 주문한 총 비용. 당연히 두 번째 및 세 번째 경우의 결과 집합 데이터는 첫 번째 경우보다 더 상세합니다. 다양한 세부 정보로 집계 데이터를 얻을 수 있는 가능성은 데이터 웨어하우스의 요구 사항 중 하나인 비교 및 ​​분석을 위한 다양한 데이터 조각의 가용성 요구 사항에 해당합니다.

고려된 예에서 일반적으로 각 국가에는 여러 도시가 있을 수 있고 도시에는 여러 고객이 있을 수 있으므로 차원의 값 계층에 대해 이야기할 수 있습니다. 이 경우 국가는 계층 구조의 첫 번째 수준에 있고 도시는 두 번째 수준에 있으며 고객은 세 번째 수준에 있습니다(그림 3).

계층 구조는 예를 들어 그림 4에 표시된 계층 구조와 같이 균형을 이룰 수 있습니다. 3 , 날짜-시간 데이터 및 불균형 데이터를 기반으로 하는 계층도 있습니다. 불균형 계층 구조의 일반적인 예는 "상사 종속" 유형의 계층 구조입니다(예: 위에서 고려한 예에서 원래 데이터 세트의 Salesperson 필드 값을 사용하여 작성할 수 있음). 그림에서 4 .

때때로 부모-자식 계층이라는 용어는 이러한 계층에 사용됩니다.

균형과 불균형 사이의 중간 위치를 차지하는 계층도 있습니다(비정형 - "불균등"이라는 용어로 표시됨). 여기에는 일반적으로 논리적 "상위"가 바로 상위 수준이 아닌 구성원이 포함됩니다(예: 지리적 계층 구조에는 국가, 도시 및 시/도 수준이 있지만 데이터 집합에는 두 국가 사이에 주 또는 지역이 없는 국가가 있습니다. 국가 및 도시 수준). ; 그림 5).

모든 OLAP 도구에서 불균형 및 "균등하지 않은" 계층이 지원되지는 않습니다. 예를 들어 Microsoft Analysis Services 2000에서는 두 가지 유형의 계층 구조가 모두 지원되지만 Microsoft OLAP Services 7.0에서는 균형이 잡힌 유형만 지원됩니다. 서로 다른 OLAP 도구는 계층 구조 수준의 수, 한 수준의 최대 허용 가능한 구성원 수 및 가능한 최대 차원 자체 수에 따라 다를 수 있습니다.

결론

이 기사에서는 OLAP의 기본 사항에 대해 알아보았습니다. 우리는 다음을 배웠습니다.

• 데이터 웨어하우스의 목적은 사용자에게 통계 분석 및 관리 의사 결정을 위한 정보를 제공하는 것입니다.
• 데이터 웨어하우스는 데이터의 일관성, 완전성 및 신뢰성뿐만 아니라 고속 데이터 수집, 소위 데이터 조각을 얻고 비교할 수 있는 기능을 제공해야 합니다.
• OLAP(On-Line Analytical Processing)는 데이터 웨어하우스 구축 및 사용의 핵심 구성 요소입니다. 이 기술은 다차원 데이터 세트의 구성을 기반으로 합니다. OLAP 큐브는 축에 매개변수를 포함하고 셀에는 매개변수에 의존하는 집계 데이터가 포함됩니다.
• OLAP 기능이 있는 응용 프로그램은 사용자에게 합리적인 시간 내에 분석 결과를 제공하고, 논리적 및 통계적 분석을 수행하고, 데이터에 대한 다중 사용자 액세스를 지원하고, 데이터의 다차원 개념 표현을 구현하고, 필요한 정보에 액세스할 수 있어야 합니다.

또한 OLAP 큐브의 논리적 구성의 기본 원리를 살펴보고 다차원 분석에 사용되는 기본 용어와 개념을 학습했습니다. 마지막으로 OLAP 큐브 차원에서 다양한 유형의 계층 구조가 무엇인지 배웠습니다.

이 시리즈의 다음 기사에서는 데이터 웨어하우스의 일반적인 구조를 살펴보고 클라이언트와 서버 OLAP를 구성하는 요소에 대해 설명하고 다차원 데이터 저장의 몇 가지 기술적인 측면에 대해서도 설명합니다.

ComputerPress 4 "2001

보고서의 목적

이 보고서는 편리한 분석 도구인 지능형 기술 범주 중 하나인 OLAP 기술에 중점을 둘 것입니다.

보고서의 목적: 2가지 문제를 밝히고 강조하기 위해: 1) OLAP의 개념과 재무 관리에 적용되는 중요성; 2) 소프트웨어 솔루션의 OLAP 기능 구현: 차이점, 기회, 장점, 단점.

OLAP은 다양한 방법의 데이터 분석이 필요한 금융(보고서 제목에서 알 수 있듯이)뿐만 아니라 모든 응용 분야에서 사용할 수 있는 보편적인 도구라는 점을 바로 말씀드리고 싶습니다.

재무 관리

재무관리는 그 어떤 분석보다 분석이 중요한 영역입니다. 모든 재무 및 관리 결정은 특정 분석 절차의 결과로 발생합니다. 오늘날 재무 관리는 기업의 성공적인 기능을 위해 중요한 역할을 합니다. 재무 관리는 기업의 보조 프로세스라는 사실에도 불구하고 잘못된 재무 및 관리 결정은 큰 손실을 초래할 수 있으므로 특별한주의가 필요합니다.

재무 관리는 최적의 분배를 통해 사용 효과를 극대화하기 위해 필요한 양, 적시 및 장소에서 기업에 재정 자원을 제공하는 것을 목표로 합니다.

"자원 사용의 최대 효율성"의 수준을 결정하는 것은 아마도 어려울 수 있지만, 어쨌든,

CFO는 항상 다음 사항을 알고 있어야 합니다.

• 얼마나 많은 재정 자원을 사용할 수 있습니까?
• 자금은 어디에서, 얼마나 올까요?
• 어디에 더 효율적으로 투자해야 하며 그 이유는 무엇입니까?
• 그리고 어느 시점에 해야 합니까?
• 기업의 정상적인 운영을 보장하기 위해 얼마가 필요합니까?

이러한 질문에 대한 합리적인 대답을 얻으려면 충분히 많은 수의 성과 지표를 보유하고, 분석하고, 분석하는 방법을 알아야 합니다. 또한 FI는 현금 흐름 분석(현금 흐름), 자산 및 부채 분석, 수익성 분석, 마진 분석, 수익성 분석, 구색 분석과 같은 방대한 영역을 다룹니다.

지식

따라서 재무 관리 프로세스의 효율성에 대한 핵심 요소는 다음에 대한 지식입니다.

• 금융가/재무 이사의 경험, 직관을 포함한 주제 영역의 개인 지식(이론적 및 방법론적이라고 할 수 있음)
• 기업의 금융 거래 사실에 대한 일반(기업) 지식 또는 체계화된 정보(즉, 기업의 과거, 현재 및 미래 상태에 대한 정보, 다양한 지표 및 측정으로 표시됨)

첫 번째가이 금융가 (또는이 직원을 고용 한 HR 이사)의 행동 분야에 있다면 두 번째는 재무 및 정보 서비스 근로자의 공동 노력으로 기업에서 의도적으로 생성되어야합니다.

지금 무엇

그러나 이제는 기업에서 흔히 볼 수 있는 역설적인 상황이 발생합니다. 정보가 있고 정보가 너무 많고 너무 많습니다. 그러나 그것은 혼돈 상태에 있습니다. 구조화되지 않고, 일관성이 없고, 파편화되어 있고, 항상 신뢰할 수 있는 것은 아니며 종종 오류가 발생하기 때문에 그것을 찾고 받는 것이 거의 불가능합니다. 길고 종종 쓸모없는 재무 제표 생성이 생성됩니다. 이는 재무 분석에 불편하고 내부 관리가 아니라 외부 규제 기관에 제출하기 위해 생성되기 때문에 인식하기 어렵습니다.

회사에서 실시한 연구에 따르면 로이터 1,300명의 해외 관리자 중 38%가 필요한 정보를 찾는 데 많은 시간을 할애한다고 말했습니다. 우수한 자격을 갖춘 전문가는 데이터 분석이 아니라 이 분석에 필요한 정보를 수집, 검색 및 체계화하는 데 높은 급여를 받는 시간을 보내는 것으로 나타났습니다. 동시에 관리자는 종종 사례와 관련이 없는 많은 양의 데이터 로드를 경험하여 효율성을 다시 떨어뜨립니다. 이 상황의 이유는 정보의 과잉과 지식의 부족입니다.

해야 할 일

정보는 지식으로 전환되어야 합니다. 현대 비즈니스에 있어서 가치 있는 정보, 그 체계적인 획득, 합성, 교환, 사용은 일종의 화폐이지만 그것을 받기 위해서는 모든 비즈니스 프로세스와 마찬가지로 정보 관리가 필요합니다.

정보 관리의 핵심은 올바른 형식으로 올바른 정보를 적절한 시간에 조직 내 적절한 사람들에게 전달하는 것입니다. 이 관리의 목적은 사람들이 점점 더 많은 양의 정보를 사용하여 더 잘 협력하도록 돕는 것입니다.

이 경우 정보 기술은 기업의 정보를 체계화하고 특정 사용자에게 해당 정보에 대한 액세스 권한을 제공하며 이 정보를 지식으로 전환할 수 있는 도구를 제공하는 수단 역할을 합니다.

OLAP 기술의 기본 개념

OLAP 기술(English On-Line Analytical Processing)은 특정 제품의 이름이 아니라 스토리지에 축적된 다차원 데이터의 운영 분석을 위한 전체 기술입니다. OLAP의 본질을 이해하기 위해서는 의사결정을 위한 정보 획득의 전통적인 프로세스를 고려할 필요가 있습니다.

전통적인 의사결정 지원 시스템

물론 여기에는 많은 옵션이 있을 수 있습니다. 완전한 정보 혼돈 또는 가장 일반적인 상황(기업에 특정 작업의 사실을 기록하고 데이터베이스에 저장하는 운영 시스템이 있는 경우)입니다. 분석 목적으로 데이터베이스에서 데이터를 추출하기 위해 특정 데이터 샘플에 대한 쿼리 시스템이 구축되었습니다.

그러나 이러한 의사 결정 지원 방법에는 유연성이 부족하고 다음과 같은 많은 단점이 있습니다.

• 의사 결정에 유용할 수 있는 무시할 수 있는 양의 데이터를 사용합니다.
• 때때로 복잡한 다중 페이지 보고서가 생성되며 그 중 1-2줄이 실제로 사용됩니다(나머지는 경우에 따라 다름) - 정보 과부하
• 변경에 대한 프로세스의 느린 반응: 데이터의 새로운 표현이 필요한 경우 프로그래머가 요청을 공식적으로 설명하고 코딩한 다음 실행해야 합니다. 대기 시간: 시간, 일. 그리고 아마도 지금, 즉시 결정이 필요할 것입니다. 그러나 새로운 정보를 받은 후 새로운 질문이 생길 것입니다(해명)

쿼리 보고서가 1차원 형식으로 표시되는 경우 비즈니스 문제는 일반적으로 다차원적이고 다면적입니다. 회사의 비즈니스에 대한 명확한 그림을 얻으려면 다양한 섹션의 데이터를 분석해야 합니다.

많은 회사에서 사용하지 않는 정보를 완벽하게 분류하여 훌륭한 관계형 데이터베이스를 생성합니다. 이 정보만으로는 시장 이벤트에 신속하거나 적절하게 대응할 수 없습니다. 예 - 관계형 데이터베이스는 기업 데이터를 저장하는 데 가장 적합한 기술이었으며 앞으로도 그럴 것입니다. 이건 ~에 대한 게 아닙니다 새로운 기술 DB가 아니라 기존 DBMS의 기능을 보완하고 OLAP에 내재된 다양한 유형의 지능적 분석을 제공하고 자동화할 수 있을 정도로 유연한 분석 도구에 관한 것입니다.

OLAP 이해하기

OLAP는 무엇을 제공합니까?

• 고급 스토리지 데이터 액세스 도구
• 동적 대화형 데이터 조작(회전, 통합 또는 드릴다운)
• 데이터의 명확한 시각적 표시
• Fast - 실시간으로 분석이 이루어집니다.
• 다차원 데이터 표시 - 다차원에 걸친 여러 지표의 동시 분석

OLAP 기술 사용의 효과를 얻으려면 다음이 필요합니다. 1) 기술 자체의 본질과 기능을 이해합니다. 2) 어떤 프로세스가 분석되어야 하는지, 어떤 지표로 특징지어질 것인지, 어떤 차원에서 프로세스를 보는 것이 바람직한지 명확하게 정의합니다. 즉, 분석 모델을 만듭니다.

OLAP 기술이 작동하는 기본 개념은 다음과 같습니다.

다차원성

데이터의 다차원성을 이해하려면 먼저 예를 들어 경제 요소 및 사업부별 기업 비용의 성과를 보여주는 표를 제시해야 합니다.

이 데이터는 두 가지 차원으로 표시됩니다.

• 기사
• 사업 부문

이 표는 특정 기간의 매출을 보여주기 때문에 정보를 제공하지 않습니다. 다른 기간에 대해 분석가는 여러 테이블(각 기간에 대해)을 비교해야 합니다.

그림은 처음 2개에 추가하여 3차원인 시간을 보여줍니다. (기사, 사업부)

다차원 데이터를 표시하는 또 다른 방법은 큐브 형태로 표시하는 것입니다.

OLAP 큐브를 사용하면 분석가가 다양한 조각에서 데이터를 가져와 비즈니스에서 묻는 질문에 답할 수 있습니다.

• 어떤 사업부에서 어떤 비용이 중요합니까?
• 사업부 비용은 시간이 지남에 따라 어떻게 변합니까?
• 비용 항목은 시간이 지남에 따라 어떻게 변경됩니까?

이러한 질문에 대한 답변은 관리 결정을 내리는 데 필요합니다. 특정 비용 항목 감소, 구조에 영향, 시간 경과에 따른 비용 변경 원인 식별, 계획 이탈 및 제거 - 구조 최적화.

이 예에서는 3차원만 고려합니다. 3차원 이상은 표현하기 어렵지만 3차원의 경우와 같은 방식으로 작동합니다.

일반적으로 OLAP 애플리케이션을 사용하면 3개 이상의 차원에 대한 데이터를 수신할 수 있습니다. 예를 들어 다른 차원을 추가할 수 있습니다. 계획-실행, 비용 범주: 직접, 간접, 주문별, 월별. 추가 차원을 통해 더 많은 분석 조각을 얻고 여러 조건의 질문에 대한 답변을 제공할 수 있습니다.

계층

또한 OLAP를 사용하면 분석가가 각 차원을 조직 전체의 메트릭을 반영하는 그룹 및 하위 그룹 및 합계의 계층 구조로 구성할 수 있습니다. 이는 비즈니스를 분석하는 가장 논리적인 방법입니다.

예를 들어 비용을 계층적으로 그룹화하는 것이 좋습니다.

OLAP를 사용하면 분석가가 전체 요약 측정값(가장 높은 수준에서)의 데이터를 얻은 다음 가장 낮은 수준과 후속 수준으로 드릴다운하여 측정값 변경에 대한 정확한 이유를 찾을 수 있습니다.

분석가가 계층적으로 구축된 차원의 가능성과 함께 데이터 큐브에서 여러 차원을 사용할 수 있도록 함으로써 OLAP를 사용하면 정보 웨어하우스의 구조에 의해 압축되지 않은 비즈니스의 그림을 얻을 수 있습니다.

큐브에서 분석 방향 변경(데이터 회전)

일반적으로 열, 행(여러 개 있을 수 있음)에 지정된 차원, 나머지 양식 조각, 테이블 형식 차원(매출, 비용, 현금)의 내용과 같은 개념으로 작동합니다.

일반적으로 OLAP를 사용하면 큐브 차원의 방향을 변경할 수 있으므로 데이터를 다른 보기로 표시할 수 있습니다.

큐브 데이터 표시는 다음에 따라 다릅니다.

• 차원 방향: 행, 열, 조각에 지정되는 차원;
• 행, 열, 조각으로 강조 표시된 표시기 그룹.
• 측정값 변경은 사용자 작업 범위 내에 있습니다.

따라서 OLAP를 사용하면 다양한 유형의 분석을 수행하고 결과와의 관계를 이해할 수 있습니다.

• 편차 분석 - 지표를 자세히 설명하여 편차 원인에 대한 요인 분석으로 보완되는 계획 실행 분석.
• 종속성 분석: OLAP를 사용하면 다양한 변경 간의 다양한 종속성을 식별할 수 있습니다. 예를 들어 맥주가 범위에서 제거되었을 때 바퀴벌레 판매가 처음 두 달 동안 감소한 것으로 나타났습니다.
• 비교(비교 분석). 다른 지역 등에서 주어진 상품 그룹에 대해 시간 경과에 따른 지표 변경 결과 비교
• 역학 분석을 통해 시간 경과에 따른 지표 변화의 특정 추세를 식별할 수 있습니다.

능률: 우리는 OLAP가 심리학의 법칙을 기반으로 한다고 말할 수 있습니다. 즉, 사용자가 데이터를 분석적으로 이해하는 프로세스의 속도로 "실시간"으로 정보 요청을 처리하는 능력입니다.

관계형 데이터베이스에서 초당 약 200개의 레코드를 읽고 20개를 쓸 수 있는 경우 계산된 행과 열을 사용하는 우수한 OLAP 서버는 초당 20,000-30,000개의 셀(관계형 데이터베이스의 한 레코드에 해당)을 통합할 수 있습니다.

시계: OLAP는 최종 사용자에게 데이터를 그래픽으로 표현하는 고급 수단을 제공한다는 점을 강조해야 합니다. 인간의 두뇌는 영숫자 형태로 표시되는 정보보다 몇 배나 큰 볼륨으로 기하학적 이미지 형태로 표시되는 정보를 인식하고 분석할 수 있습니다. 예시: 백 장의 사진 중 낯익은 얼굴을 찾아야 한다고 가정해 봅시다. 나는 이 과정이 1분도 걸리지 않을 것이라고 믿습니다. 이제 사진 대신 같은 사람에 대한 100개의 구두 설명이 제공될 것이라고 상상해 보십시오. 나는 당신이 제안된 문제를 전혀 해결할 수 없다고 생각합니다.

간단: 이 기술의 주요 특징은 IT 전문가가 아닌 전문 통계 전문가가 아닌 응용 분야의 전문가인 신용 부서장, 예산 부서장, 그리고 마지막으로 감독. 분석가가 컴퓨터가 아니라 문제와 통신하기 위한 것입니다..

OLAP의 큰 가능성에도 불구하고(게다가 아이디어는 비교적 오래됨 - 60년대), 우리 기업에서는 실제로 사용되지 않습니다. 왜요?

• 정보가 누락되었거나 가능성이 명확하지 않음
• 2차원적으로 생각하는 습관
• 가격 장벽
• OLAP에 대한 기사의 과도한 제조 가능성: 생소한 용어는 겁을 줍니다. - OLAP, "데이터의 발굴 및 조각", "임시 쿼리", "중요한 상관 관계 식별"

OLAP의 적용에 대한 우리의 접근 방식과 서양

또한 OLAP의 기술적 능력을 이해하면서도 OLAP의 응용 유틸리티에 대해 구체적으로 이해하고 있습니다.

OLAP에 관한 다양한 자료의 우리 및 러시아 저자는 OLAP의 유용성과 관련하여 다음과 같은 의견을 표현합니다. 대다수는 OLAP를 간단하고 편리하게 데이터를 확장 및 축소할 수 있는 도구로 인식하고 마음에 오는 조작을 수행합니다. 분석 과정의 분석가. 분석가가 보는 데이터의 "슬라이스"와 "슬라이스"가 많을수록 그는 더 많은 아이디어를 갖게 되며 검증을 위해 더 많은 "슬라이스"가 필요합니다. 옳지 않다.

OLAP의 유용성에 대한 서구적 이해의 중심에는 OLAP 솔루션을 설계할 때 설정해야 하는 분석 방법론적 모델이 있습니다. 분석가는 OLAP 큐브를 가지고 놀아서는 안 되며 목적 없이 차원과 세부 정보 수준, 데이터 방향, 데이터의 그래픽 표시를 변경해서는 안 됩니다. 하지만 실제로 필요한 뷰가 무엇인지, 어떤 순서로, 왜 필요한지 명확하게 이해해야 합니다(물론 , "발견" 요소가 있을 수 있지만 이것이 OLAP의 유용성의 기본 요소는 아닙니다).

OLAP의 애플리케이션 사용

• 예산
• 자금의 흐름

OLAP 기술의 가장 비옥한 응용 분야 중 하나입니다. 구성에 예산 분석을 위한 OLAP 툴킷이 없으면 현대 예산 시스템이 완전한 것으로 간주되지 않는 것은 아닙니다. 대부분의 예산 보고서는 OLAP 시스템을 기반으로 쉽게 작성됩니다. 동시에 보고서는 비용 및 수입 구조 분석, 다른 부서의 특정 항목에 대한 비용 비교, 특정 항목에 대한 비용의 역학 및 추세 분석, 비용 및 수입 분석과 같은 매우 광범위한 질문에 대한 답변을 제공합니다. 이익.

OLAP을 사용하면 자금 흐름을 최적화하기 위해 비즈니스 운영, 거래 상대방, 통화 및 시간의 맥락에서 자금의 유입 및 유출을 분석할 수 있습니다.

• 재무 및 관리 보고(관리에 필요한 분석 포함)
• 마케팅
• 균형 성과표
• 수익성 분석

적절한 데이터가 있는 경우 OLAP 기술의 다른 응용 프로그램을 찾을 수 있습니다.

OLAP 제품

이 섹션에서는 소프트웨어 솔루션으로서의 OLAP에 대해 설명합니다.

OLAP 제품에 대한 일반 요구 사항

OLAP 응용 프로그램을 구현하는 방법에는 여러 가지가 있으며 특정 기술이 필수이거나 권장되어서는 안 됩니다. 다른 조건과 상황에서 한 접근 방식이 다른 접근 방식보다 더 나을 수 있습니다. 구현 기술에는 클라이언트-서버 아키텍처, 시계열 분석, 객체 지향, 데이터 저장 최적화, 병렬 프로세스 등 공급업체가 자랑스러워하는 다양한 독점 아이디어가 포함됩니다. 그러나 이러한 기술은 OLAP 정의의 일부가 될 수 없습니다.

모든 OLAP 제품(OLAP 제품인 경우)에서 반드시 지켜져야 하는 특성이 있는데, 이는 기술의 이상입니다. 다음은 OLAP(소위 FASMI 테스트)를 특징짓는 5가지 주요 정의입니다. 공유된 다차원 정보의 빠른 분석.

• 빠른(FAST) - 시스템이 약 5초 이내에 사용자에게 대부분의 응답을 제공해야 함을 의미합니다. 시스템에서 프로세스가 훨씬 더 오래 걸릴 것이라고 경고하더라도 사용자는 주의가 산만해지고 정신을 잃을 수 있으며 분석 품질이 저하될 수 있습니다. 이 속도는 특히 즉각적인 특별 계산이 필요한 경우 많은 양의 데이터로 달성하기 쉽지 않습니다. 공급업체는 특수한 형태의 데이터 저장, 광범위한 사전 계산 또는 하드웨어 요구 사항 강화를 포함하여 이 목표를 달성하기 위해 다양한 방법을 사용합니다. 그러나 현재 완전히 최적화된 솔루션은 없습니다. 언뜻 보기에는 며칠이 걸리지 않은 1분 만에 보고서를 받으면 사용자가 기다리는 동안 매우 빨리 지루해 하고 프로젝트의 성공률이 덜 상세한 분석을 하는 경우에도 즉각적인 응답이 가능합니다.
• 공유시스템이 모든 데이터 보호 요구 사항을 충족하고 다양한 수준의 사용자를 위해 데이터에 대한 분산 및 동시 액세스를 구현할 수 있음을 의미합니다. 시스템은 시기 적절하고 안전한 방식으로 여러 데이터 변경 사항을 처리할 수 있어야 합니다. 이것은 모든 OLAP 응용 프로그램에 읽기 전용이 필요하고 단순화된 보호 기능을 제공한다고 가정하는 경향이 있는 많은 OLAP 제품의 주요 약점입니다.
• 다차원는 핵심 요구 사항입니다. OLAP를 한 단어로 정의해야 한다면 선택했을 것입니다. 시스템은 계층 및 다중 계층에 대한 완전한 지원을 포함하여 데이터의 다차원 개념 표현을 제공해야 합니다. 이것이 비즈니스를 분석하는 가장 논리적인 방법을 결정하기 때문입니다. 처리해야 하는 최소 차원 수는 응용 프로그램에 따라 다르며 대부분의 OLAP 제품에는 대상 시장에 충분한 차원이 있습니다. 다시 말하지만, 사용자가 정보의 진정한 다차원 개념 표현을 얻으려면 어떤 기본 데이터베이스 기술을 사용해야 하는지 지정하지 않습니다. 이 기능은 OLAP의 핵심입니다.
• 정보.필요한 정보는 양과 위치에 관계없이 필요한 곳에서 얻어야 합니다. 그러나 많은 것은 응용 프로그램에 따라 다릅니다. 다양한 제품의 성능은 저장할 수 있는 기가바이트가 아니라 처리할 수 있는 입력의 측면에서 측정됩니다. 제품의 성능은 매우 다양합니다. 가장 큰 OLAP 제품은 가장 작은 제품보다 최소 천 배 많은 데이터를 처리할 수 있습니다. 이와 관련하여 데이터 복제, 필요한 RAM, 디스크 공간 사용량, 성능, 정보 저장소와의 통합 등을 포함하여 고려해야 할 많은 요소가 있습니다.
• 분석이는 시스템이 주어진 애플리케이션에 특정한 논리적 및 통계적 분석을 처리할 수 있고 최종 사용자가 액세스할 수 있는 형식으로 유지되도록 보장한다는 것을 의미합니다. 사용자는 프로그래밍 없이 분석의 일부로 새로운 특수 계산을 정의할 수 있어야 합니다. 즉, 필요한 모든 분석 기능은 최종 사용자에게 직관적인 방식으로 제공되어야 합니다. 분석 도구에는 시계열 분석, 비용 할당, 통화 전송, 타겟팅 등과 같은 특정 절차가 포함될 수 있습니다. 이러한 기능은 대상 방향에 따라 제품마다 크게 다릅니다.

즉, 이 5가지 핵심 정의는 OLAP 제품이 달성하도록 설계된 목표입니다.

OLAP의 기술적 측면

OLAP 시스템에는 특정 구성 요소가 포함됩니다. 특정 제품이 구현할 수있는 다양한 작업 계획이 있습니다.

OLAP 시스템의 구성 요소(OLAP 시스템은 무엇으로 구성됩니까?)

일반적으로 OLAP 시스템에는 다음 구성 요소가 포함됩니다.

• 데이터 소스
  분석을 위해 데이터를 가져오는 소스(데이터 웨어하우스, 운영 회계 시스템 데이터베이스, 테이블 세트, 위의 조합).
• OLAP 서버
  소스의 데이터는 OLAP 서버로 전송되거나 복사되며, 여기에서 쿼리에 대한 응답을 보다 빠르게 생성할 수 있도록 체계화되고 준비됩니다.
• OLAP 클라이언트
  사용자가 작동하는 OLAP 서버에 대한 사용자 인터페이스

모든 구성 요소가 필요한 것은 아닙니다. 사용자의 컴퓨터에 직접 저장된 데이터를 분석할 수 있고 OLAP 서버가 필요하지 않은 데스크탑 OLAP 시스템이 있습니다.

그러나 필수 요소는 데이터 소스입니다. 데이터의 가용성은 중요한 문제입니다. 어떤 형태로든 Excel 테이블, 회계 시스템의 데이터베이스, 지점의 구조화된 보고서 형태인 경우 IT 전문가는 OLAP 시스템과 직접 또는 중간 변환을 통합할 수 있습니다. OLAP 시스템에는 이를 위한 특별한 도구가 있습니다. 이 데이터를 사용할 수 없거나 완전성과 품질이 부족하면 OLAP가 도움이 되지 않습니다. 즉, OLAP는 데이터에 대한 부가 기능일 뿐이며, 없으면 쓸모없는 것이 됩니다.

OLAP 응용 프로그램에 대한 대부분의 데이터는 다른 시스템에서 시작됩니다. 그러나 일부 응용 프로그램(예: 계획 또는 예산 책정용)에서는 OLAP 응용 프로그램에서 직접 데이터를 생성할 수 있습니다. 데이터가 다른 응용 프로그램에서 가져온 경우 일반적으로 데이터를 OLAP 응용 프로그램에 대해 별도의 복제 양식에 저장해야 합니다. 따라서 데이터 웨어하우스를 만드는 것이 좋습니다.

"OLAP"이라는 용어는 "데이터 웨어하우스"(데이터 웨어하우스)라는 용어와 불가분의 관계에 있다는 점에 유의해야 합니다. 데이터 웨어하우스는 관리 의사 결정을 지원하기 위한 도메인별, 시간 제한, 변경할 수 없는 데이터 모음입니다. 스토리지의 데이터는 비즈니스 프로세스를 자동화하도록 설계된 운영 체제(OLTP 시스템)에서 가져오고 스토리지는 통계 보고서와 같은 외부 소스에서 보충할 수 있습니다.

이미 운영 체제의 데이터베이스나 파일에 분명히 중복되는 정보가 포함되어 있음에도 불구하고 데이터 저장소는 다음과 같은 이유로 필요합니다.

• 데이터 단편화, 다양한 DBMS 형식으로 저장
• 향상된 데이터 검색 성능
• 기업의 모든 데이터가 중앙 데이터베이스 서버에 저장되어 있는 경우(매우 드물지만) 분석가는 복잡하고 때로는 혼란스러운 구조를 이해하지 못할 수 있습니다.
• 운영 정보에 대한 복잡한 분석 쿼리는 회사의 현재 작업 속도를 늦추고 장기간 테이블을 차단하고 서버 리소스를 점유합니다.
• 데이터 정리 및 조정 기능
• 운영 체제의 데이터를 직접 분석하는 것이 불가능하거나 매우 어렵습니다.

리포지토리의 임무는 분석을 위한 "원료"를 한 곳에서 간단하고 이해하기 쉬운 구조로 제공하는 것입니다. 즉, 데이터 웨어하우스의 개념은 데이터 분석의 개념이 아니라 분석을 위한 데이터를 준비하는 개념입니다. 여기에는 단일 통합 데이터 소스의 구현이 포함됩니다.

OLAP 제품: 아키텍처

OLAP 제품을 사용할 때 두 가지 질문이 중요합니다. 방법과 위치 유지하다그리고 핸들데이터. 이 두 가지 프로세스가 구현되는 방식에 따라 OLAP 아키텍처가 구별됩니다. OLAP용 데이터를 저장하는 3가지 방법과 해당 데이터를 처리하는 3가지 방법이 있습니다. 많은 제조업체가 여러 옵션을 제공하며 일부 제조업체는 해당 접근 방식이 가장 신중한 접근 방식임을 증명하려고 합니다. 물론 이것은 터무니없는 일입니다. 그러나 질적으로 둘 이상의 모드에서 작동할 수 있는 제품은 거의 없습니다.

OLAP 스토리지 옵션

이 컨텍스트에서 스토리지는 데이터를 지속적으로 업데이트된 상태로 유지하는 것을 의미합니다.

• 관계형 데이터베이스: 기업이 자격 증명을 RDB에 저장하는 경우 일반적인 선택입니다. 대부분의 경우 데이터는 비정규화된 구조로 저장되어야 합니다(스타 스키마가 가장 적합함). 정규화된 데이터베이스는 OLAP에 대한 집계 값을 생성할 때 매우 열악한 쿼리 성능으로 인해 허용되지 않습니다(종종 요약 데이터는 집계 테이블에 저장됨).
• 클라이언트 컴퓨터의 데이터베이스 파일(키오스크 또는 데이터 마트): 이 데이터는 클라이언트 컴퓨터에서 요청 시 미리 배포하거나 생성할 수 있습니다.

다차원 데이터베이스: 데이터가 서버의 다차원 데이터베이스에 저장되어 있다고 가정합니다. 여기에는 다른 시스템 및 관계형 데이터베이스, 최종 사용자 파일 등에서 추출 및 요약된 데이터가 포함될 수 있습니다. 대부분의 경우 다차원 데이터베이스는 디스크에 저장되지만 일부 제품에서는 RAM도 사용하여 가장 자주 사용되는 데이터를 계산합니다. 날아." 다차원 데이터베이스를 기반으로 하는 제품은 여러 데이터 편집을 허용하는 제품이 거의 없으며 단일 수정만 허용하지만 데이터를 여러 번 읽을 수 있는 제품이 많은 반면 읽기 전용으로 제한되는 제품도 있습니다.

이 3개의 저장 위치는 저장 용량이 서로 다르며 용량 내림차순으로 정렬되어 있습니다. 또한 쿼리 성능 특성이 다릅니다. 관계형 데이터베이스는 마지막 두 옵션보다 훨씬 느립니다.

OLAP 데이터 처리 옵션

동일한 데이터 처리 옵션이 3가지 있습니다.

• SQL 사용: 이 옵션은 물론 RDB에 데이터를 저장할 때 사용됩니다. 그러나 SQL은 단일 쿼리에서 다차원 계산을 수행하는 것을 허용하지 않으므로 일반적인 다차원 기능 이상을 달성하려면 복잡한 SQL 쿼리를 작성해야 합니다. 그러나 이것이 개발자의 시도를 멈추지는 않습니다. 대부분의 경우 다차원 데이터 처리 또는 클라이언트 시스템에서 얻을 수 있는 결과와 함께 제한된 수의 관련 SQL 계산을 수행합니다. 사용하는 것도 가능합니다 랜덤 액세스 메모리, 하나 이상의 요청을 사용하여 데이터를 저장할 수 있습니다. 이렇게 하면 응답이 크게 향상됩니다.
• 다차원 클라이언트 측 처리: 클라이언트 측 OLAP 제품은 자체적으로 계산을 수행하지만 이 처리는 사용자가 상대적으로 강력한 PC를 가지고 있는 경우에만 사용할 수 있습니다.

서버 다차원 처리: 클라이언트-서버 OLAP 응용 프로그램에서 다차원 계산을 수행하는 데 널리 사용되며 많은 제품에서 사용됩니다. 대부분의 계산이 이미 완료되었기 때문에 일반적으로 성능이 높습니다. 그러나 이것은 많은 디스크 공간을 필요로 합니다.

OLAP 아키텍처 매트릭스

따라서 저장/처리 옵션을 결합하여 OLAP 시스템용 아키텍처 매트릭스를 얻을 수 있습니다. 따라서 이론적으로 이러한 방법의 조합은 9가지가 될 수 있습니다. 그러나 그 중 3개는 상식이 통하지 않기 때문에 실제로 OLAP 데이터를 저장하고 처리하는 옵션은 6개뿐입니다.

처리를 결정하는 것은 스토리지이므로 스토리지 옵션별로 그룹화하는 것이 일반적입니다.

• 섹터 1, 2, 3의 ROLAP 제품
• 데스크탑 OLAP - 섹터 6

MOLAP 제품 - 섹터 4 및 5

HOLAP 제품(다차원 및 관계형 데이터 저장 옵션 모두 허용) - 2 및 4(이탤릭체로 강조 표시)

OLAP 제품 카테고리

40개 이상의 OLAP 공급업체가 있지만 기능이 매우 다르고 실제로 서로 다른 시장 부문에서 운영되기 때문에 모든 공급업체가 경쟁자로 간주될 수는 없습니다. 그것들은 4가지 기본 범주로 그룹화할 수 있으며, 그 차이점은 개념을 기반으로 합니다: 복잡한 기능 - 단순 기능, 성능 - 디스크 공간. 범주 간의 관계를 명확하게 보여주기 때문에 사각형의 형태로 범주를 그리는 것이 편리합니다. 각 범주의 구별되는 특징은 측면에 표시되고 다른 범주와의 유사성은 인접한 측면에 표시되므로 반대 측면의 범주는 근본적으로 다릅니다.

Microsoft Analysis Services, OracleExpress, Crystal Holos, IBM DB2 OLAPServer와 같이 ROLAP 및 MOLAP 모드를 선택할 수 있는 하이브리드 제품의 고객은 거의 항상 MOLAP 모드를 선택합니다.

제시된 각 범주에는 고유한 강점과 약점이 있으며 단일 항목이 없습니다. 최적의 선택. 선택은 3가지 중요한 측면에 영향을 줍니다. 1) 성능; 2) 데이터 저장을 위한 디스크 공간; 3) 특징, 기능, 특히 OLAP 솔루션의 확장성. 동시에 처리되는 데이터의 양, 기술의 힘, 사용자의 요구를 고려하고 단순하고 다기능적인 데이터베이스가 차지하는 디스크 공간의 중복성과 속도 사이의 절충안을 찾아야 합니다.

대상 데이터베이스의 볼륨에 따른 데이터 웨어하우스 분류

OLAP의 단점

모든 기술과 마찬가지로 OLAP에도 단점이 있습니다. 하드웨어에 대한 높은 요구 사항, 관리 인력 및 최종 사용자에 대한 교육 및 지식, 구현 프로젝트 구현을 위한 높은 비용(금전적 및 시간적, 지적).

OLAP 제품 선택

올바른 OLAP 제품을 선택하는 것은 어렵지만 프로젝트가 실패하지 않도록 하려면 매우 중요합니다.

보시다시피 제품 간의 차이점은 기능, 아키텍처, 기술 등 많은 영역에 있습니다. 일부 제품은 설정이 매우 제한적입니다. 일부는 마케팅, 영업, 재무와 같은 전문 주제 영역을 위해 설계되었습니다. 충분히 유연해야 응용 프로그램 사용이 없는 범용 제품이 있습니다. 일반적으로 이러한 제품은 전문 제품보다 저렴하지만 구현 비용이 더 많이 듭니다. OLAP 제품의 범위는 사무용품의 일부인 피벗 테이블 및 차트를 구성하는 가장 간단한 도구부터 수만 달러의 비용이 드는 데이터 분석 및 패턴 검색 도구에 이르기까지 매우 광범위합니다.

다른 분야와 마찬가지로 OLAP 분야에서도 도구 선택에 대한 명확한 권장 사항이 있을 수 없습니다. 몇 가지 핵심 사항에만 집중하고 조직의 요구 사항과 함께 제공되는 소프트웨어 기능을 비교할 수 있습니다. 한 가지 중요합니다. OLAP 도구를 사용하는 방법에 대해 신중하게 생각하지 않으면 심각한 골칫거리가 될 위험이 있습니다.

선택 과정에서 다음 두 가지 질문을 고려해야 합니다.

• 기업의 필요와 능력 평가
• 현재 시장 제안을 평가하고 개발 동향도 중요합니다.

그런 다음이 모든 것을 비교하고 실제로 선택하십시오.

평가 필요

제품의 용도를 이해하지 못한 채 합리적인 제품 선택은 불가능합니다. 많은 기업들이 어떻게 사용해야 하는지에 대한 명확한 이해 없이 "최고의 제품"을 원합니다.

프로젝트가 성공적으로 구현되기 위해서는 재무 이사가 자동화 서비스의 책임자 및 전문가에게 자신의 희망과 요구 사항을 최소한 정확하게 공식화해야 합니다. OLAP 선택에 대한 준비와 인식 부족으로 인해 많은 문제가 발생하고, IT 전문가와 최종 사용자는 대화에서 서로 다른 개념과 용어를 조작하고 상충되는 선호도를 제시하기 때문에 의사 소통에 어려움을 겪습니다. 회사 내에서 목적의 일관성이 있어야 합니다.

OLAP 제품 범주의 개요를 읽은 후 다음과 같은 몇 가지 요소가 이미 분명해졌습니다.

기술적 측면

• 데이터 소스: 기업 데이터 웨어하우스, OLTP 시스템, 테이블 형식 파일, 관계형 데이터베이스. 조직에서 사용하는 모든 DBMS와 OLAP 도구를 연결하는 기능. 실습에서 알 수 있듯이 이기종 제품을 안정적인 작업 시스템으로 통합하는 것은 가장 중요한 문제 중 하나이며, 경우에 따라 솔루션은 큰 문제와 관련될 수 있습니다. OLAP 도구가 조직의 기존 DBMS와 얼마나 쉽고 안정적으로 통합될 수 있는지 이해해야 합니다. 데이터 소스뿐만 아니라 데이터를 내보내야 할 수 있는 다른 응용 프로그램(이메일, 사무용 응용 프로그램)과의 통합 가능성을 평가하는 것도 중요합니다.
• 중요한 데이터의 변동성
• 서버 플랫폼: NT, Unix, AS/400, Linux - 그러나 OLAP 사양에 지정된 제품이 여전히 사용 중인 모호하거나 죽어가는 플랫폼에서 실행되도록 주장하지 마십시오.
• 클라이언트 측 및 브라우저 표준
• 배포 가능한 아키텍처: 로컬 네트워크및 PC 모뎀 연결, 고속 클라이언트/서버, 인트라넷, 엑스트라넷, 인터넷
• 국제 기능: 다중 통화 지원, 다국어 작업, 데이터 공유, 현지화, 라이선스, Windows 업데이트

사용 가능하고 앞으로 나타날 입력 정보의 양

사용자

• 적용 범위 : 영업/마케팅 분석, 예산/기획, 성과지표 분석, 회계보고서 분석, 정성분석, 재무상태, 분석자료(보고서) 작성
• 이용자 수 및 위치, 데이터 및 기능에 대한 접근권한 분리 요구사항, 정보의 비밀성(비밀성)
• 사용자 유형: 고위 경영진, 재무, 마케팅, HR, 영업, 제조 등
• 사용자 경험. 사용자 기술 수준. 교육 제공을 고려하십시오. OLAP 클라이언트 응용 프로그램은 사용자가 자신감을 느끼고 효과적으로 사용할 수 있도록 설계하는 것이 매우 중요합니다.

주요 기능: 데이터 쓰기 저장, 분산 컴퓨팅, 복잡한 통화 변환, 보고서 인쇄 요구 사항, 스프레드시트 인터페이스, 응용 프로그램 논리 복잡성, 필요한 차원, 분석 유형: 통계, 목표 검색, 가정 분석

구현

• 구현 및 운영 대상: 외부 컨설턴트, 내부 IT 또는 최종 사용자
• 예산: 소프트웨어, 하드웨어, 서비스, 데이터 전송. OLAP 제품에 대한 라이선스 비용을 지불하는 것은 총 프로젝트 비용의 작은 부분일 뿐입니다. 구현 및 하드웨어 비용은 라이선스 비용보다 많을 수 있으며 장기 지원, 유지 관리 및 관리 비용은 거의 확실히 훨씬 더 많습니다. 또한 더 저렴하기 때문에 잘못된 제품을 구매하기로 잘못된 결정을 내리면 더 높은 유지 관리, 관리 및/또는 하드웨어 비용으로 인해 더 높은 전체 프로젝트 비용으로 끝날 수 있지만 더 낮은 수준의 제품을 얻을 가능성이 높습니다. 비즈니스 혜택. 총 비용을 추정할 때 다음 질문을 해야 합니다. 구현, 교육 및 지원을 위한 소스 선택의 폭은 어느 정도입니까? 잠재적인 일반 기금(직원, 계약자, 컨설턴트)이 증가했습니까 아니면 감소했습니까? 귀하의 산업 전문 경험을 어느 정도 사용할 수 있습니까?

오늘날에도 분석 시스템의 비용이 상당히 높고 이러한 시스템을 구현하기 위한 방법론과 기술이 아직 초기 단계에 있음에도 불구하고 오늘날에도 분석 시스템이 제공하는 경제적 효과는 기존 운영 시스템의 효과를 훨씬 능가합니다.

~의 효과 적절한 조직, 사업 개발의 ​​전략 및 운영 계획은 숫자로 미리 예측하기 어렵지만 그러한 시스템을 구현하는 비용을 수십 배, 심지어 수백 배 초과할 수 있다는 것은 분명합니다. 그러나 하나라도 실수해서는 안됩니다. 그 효과는 시스템 자체가 아니라 시스템과 함께 일하는 사람들에 의해 제공됩니다. 따라서 "데이터 웨어하우스 및 OLAP 기술 시스템은 관리자가 올바른 결정을 내리는 데 도움이 됩니다."라는 형식의 선언이 완전히 정확하지는 않습니다. 현대의 분석 시스템은 시스템이 아닙니다. 인공 지능그들은 결정을 돕거나 방해할 수 없습니다. 그들의 목표는 적시에 편리한 방법으로 결정을 내리는 데 필요한 모든 정보를 관리자에게 제공하는 것입니다. 그리고 어떤 정보를 요청하고 어떤 결정을 내릴지는 그 정보를 사용하는 특정인에게만 달려 있습니다.

남은 말은 이러한 시스템이 많은 비즈니스 문제를 해결하는 데 도움이 될 수 있고 광범위한 긍정적인 효과를 가져올 수 있다는 것입니다. 이 접근 방식의 장점을 가장 먼저 깨닫고 다른 사람들보다 앞서 나갈 사람을 기다리는 것만 남아 있습니다.