Essbase 애플리케이션 분석 및 계획

Essbase 애플리케이션이 비즈니스 정보를 효율적으로 분석하도록 하기 위해 데이터 소스, 사용자 요구 사항 및 예상 데이터베이스 요소를 요약하는 상세 계획을 공식화합니다. 이 설계 단계에 주의하면 개발 및 구현 시간을 절약할 수 있습니다.

계획 및 분석 단계에는 다음 작업이 포함됩니다.

다차원 응용 프로그램을 설계할 때는 다음 요소를 고려하십시오.

  • 기업 내 정보의 흐름 - 어떤 용도로 어떤 데이터를 사용하는지

  • 회사에서 수행하는 보고 유형 - 사용자 보고 요구 사항을 충족하기 위해 아웃라인에 포함되어야 하는 데이터 유형

    주:

    애플리케이션당 하나의 데이터베이스만 정의하면 메모리 사용량과 데이터베이스 관리의 용이성이 향상됩니다.

소스 데이터 분석

Essbase 데이터베이스에 포함할 데이터를 평가합니다. 업데이트의 출처와 필요한 빈도 및 크기를 고려하십시오. 피벗 보고 및 드릴스루에 필요한 항목만 Essbase로 로드해야 합니다. 나머지는 파티션 또는 드릴스루를 통해 액세스할 수 있는 관계형 소스에 머무를 수 있습니다.

데이터베이스의 범위를 결정합니다. 조직에 다수의 제품이 포함된 여러 제품군이 있는 경우 제품군에 대해서만 데이터 값을 저장할 수 있습니다. 각 사용자 부서의 인터뷰 멤버는 자신이 처리하는 데이터, 현재 데이터를 계산 및 보고하는 방법, 향후 데이터를 어떻게 처리해야 하는지 알아봅니다.

보고 및 분석 요구 사항을 신중하게 정의합니다.

  • 사용자가 데이터를 보고 분석하는 방법

  • 데이터베이스에 포함되는 세부 정보는 얼마입니까?

  • 데이터가 원하는 분석 및 보고 목표를 지원합니까?

  • 그렇지 않은 경우 필요한 추가 데이터는 무엇이며 어디에서 찾을 수 있습니까?

현재 데이터의 위치를 확인합니다.

  • 현재 각 부서에서 데이터를 저장하는 위치는 어디입니까?

  • Essbase에서 사용할 수 있는 양식의 데이터가 있습니까?

  • 부서는 Windows 또는 UNIX 서버의 관계형 데이터베이스 또는 Excel 스프레드시트에 데이터를 저장합니까?

  • 누가 데이터베이스를 업데이트하고 얼마나 자주 업데이트합니까?

  • 데이터를 업데이트해야 하는 사용자가 데이터에 액세스할 수 있습니까?

데이터를 Essbase로 로드할 준비가 되었는지 확인합니다.

  • 데이터가 단일 소스에서 제공됩니까, 아니면 여러 소스에서 제공됩니까?

  • Essbase에서 사용할 수 있는 형식의 데이터가 있습니까? Essbase로 로드할 수 있는 적합한 데이터 소스 목록은 데이터 소스를 참조하십시오.

  • 사용하려는 모든 데이터를 쉽게 사용할 수 있습니까?

사용자 요구사항 식별

Essbase 데이터베이스를 계획할 때 데이터의 현재 사용자와 정보 요구 사항을 논의하고 샘플 보고서를 요청합니다. 사용하는 정보와 다른 사람이 검토하기 위해 생성해야 하는 보고서를 검토합니다.

다음 요구 사항을 확인합니다.

  • 사용자에게 필요한 분석 유형은 무엇입니까?

  • 사용자에게 임시(피벗 스타일) 보고 및 구조화된 보고서가 필요합니까?

  • 사용자에게 필요한 요약 및 세부 정보 수준은 무엇입니까?

  • 일부 유저는 다른 유저가 볼 수 없는 정보에 액세스해야 합니까?

다중 사용자 환경의 보안 계획

Essbase 보안 권한을 설정하는 방법을 계획할 때 여러 레벨의 사용자 정보 요구 사항을 식별합니다. 분석이 끝나면 사용자 목록과 필요한 권한이 있어야 합니다.

이 체크리스트를 사용하여 보안을 계획합니다.

  • 사용자는 누구이며 데이터베이스에서 데이터를 읽거나 쓸 수 있는 권한은 무엇입니까?

  • 누가 데이터 로드 권한을 가져야 합니까?

  • 계산을 실행할 수 있는 권한이 있는 사람은 누구입니까?

  • 어떤 사용자를 그룹화하고 비슷한 권한을 할당할 수 있습니까?

또한 사용자 및 역할 관리를 참조하십시오.

데이터베이스 모델 생성

Essbase 데이터베이스의 모델을 생성합니다. 모델을 구축하려면 비즈니스에 중요한 관점과 관점을 파악해야 합니다. 이러한 뷰는 데이터베이스 모델의 차원으로 변환됩니다.

많은 기업에서 다음과 같은 뷰를 분석합니다.

  • 기간

  • 측정항목

  • 시나리오

  • 제품

  • 고객

  • 지리적 지역

  • 업무 단위

다음으로, 정보를 수집하고 결정을 내릴 수 있도록 데이터 분석 목표를 식별하고, 데이터베이스 차원 및 멤버를 결정하고, 데이터베이스 설계를 분석해야 합니다.

분석 목표 식별

비즈니스의 주요 정보 뷰를 식별한 후 Essbase 데이터베이스 설계의 다음 단계에서는 데이터베이스가 데이터 분석을 사용으로 설정하는 방법을 결정합니다. 예를 들어, 기간, 지역 또는 제품 유형별로 데이터를 확인해야 할 수 있습니다.

  • 시간별로 분석하는 경우 어떤 기간이 필요합니까? 분석에 현재 연도 또는 다중 연도만 포함해야 합니까? 분석에 분기별 및 월별 데이터가 포함되어야 합니까? 시즌별로 데이터를 포함해야 합니까?

  • 지리적 영역별로 분석하는 경우 영역을 어떻게 정의합니까? 판매 구역별로 지역을 정의하시겠습니까? 지역 경계(예: 시/도 및 구/군/시)별로 지역을 정의합니까?

  • 제품 라인별로 분석하는 경우 각 제품에 대한 데이터를 검토해야 합니까? 데이터를 제품 분류로 요약할 수 있습니까?

비즈니스 뷰에 관계없이 분석에 필요한 관점과 세부 사항을 결정해야 합니다. 분석하는 각 업무 영역은 데이터에 대해 서로 다른 뷰를 제공합니다.

차원 및 멤버 결정

선택한 Essbase 차원에 따라 수행할 수 있는 분석 유형이 결정됩니다. 각 차원 내에서 멤버 계층은 비즈니스 측면을 나타냅니다. 예를 들어, 시간 계층은 분기 및 월을 포함할 수 있습니다. 제품 계층은 제품을 분류합니다. 지역 계층은 지리적 시장을 기반으로 합니다.

각 비즈니스 뷰를 데이터베이스에서 별도의 표준 차원으로 나타낼 수 있습니다. 비즈니스 분석가가 제품별, 지역별, 기간별 비즈니스의 'bys'를 언급한다고 들 수 있습니다. 제품 크기 또는 색상과 같은 분류 또는 속성별로 비즈니스 뷰를 분석해야 하는 경우 속성 차원 또는 속성을 사용하여 분류 뷰를 나타낼 수 있습니다.

분석에 필요한 만큼 차원을 사용할 수 있습니다. 필요한 차원과 멤버를 대략적으로 알고 있는 경우 임시 데이터베이스 설계를 개발합니다.

데이터베이스 모델의 차원을 확인한 후 각 차원 내의 요소를 선택합니다. 이러한 요소는 해당 차원의 계층 및 멤버가 됩니다. 예를 들어, 시간 계층에는 분기와 같은 분석하려는 기간과 분기, 월이 포함될 수 있습니다. 각 분기와 월은 시간에 대해 생성하는 차원의 멤버가 됩니다. 분기 및 월은 멤버와 해당 1차 하위 구성요소의 2단계 계층을 나타냅니다. 분기 내의 월은 각 분기의 합계로 통합될 수 있습니다.

차원 간의 관계

차원 간의 관계를 고려합니다. Essbase 데이터베이스의 구조를 사용하면 사용자가 여러 관점에서 정보를 쉽게 분석할 수 있습니다. 예를 들어 재무 분석가는 다음과 같은 질문을 할 수 있습니다.

  • 특정 월의 매출액은 얼마입니까? 이 수치는 지난 5년간 동월의 매출과 어떻게 비교됩니까?

  • 수익 마진은 몇 퍼센트로 증가합니까?

  • 실제 값이 예산 책정된 값에 얼마나 가깝습니까?

즉, 분석가는 시간, 계정 및 시나리오의 세 가지 차원에서 정보를 검사할 수 있습니다. 아래 그림의 샘플 데이터베이스는 이러한 세 개의 차원을 나타내며 세 개의 축 각각에 하나의 차원이 표시됩니다.

  • 1월, 2월, 3월 및 Qtr1에 대한 합계로 구성된 시간 차원이 X축을 따라 표시됩니다.

  • 판매, 매출원가, 마진 및 마진%와 같은 회계 수치로 구성된 계정 차원이 Y축을 따라 표시됩니다.

  • 예산 값에 대한 예산 및 실제 값에 대한 실제와 같이 다른 POV를 제공하는 다른 차원이 Z축을 따라 표시됩니다.

그림 1-1 세 개의 데이터베이스 치수를 나타내는 큐브


이 이미지는 이미지 앞의 텍스트에 설명된 대로 세 개의 차원을 나타내는 큐브를 보여줍니다.

멤버가 교차하는 큐브 내의 셀에는 세 개의 교차 멤버(예: 1월의 실제 판매)와 관련된 데이터가 포함됩니다.

예제 차원-멤버 구조

아래 테이블은 TBC 차원의 요약을 보여줍니다. 애플리케이션 디자이너는 왼쪽 열에 차원이 있고 오른쪽 두 열에 멤버가 있는 세 개의 열을 생성했습니다. 열 3의 멤버는 열 2의 멤버 하위 범주입니다. 경우에 따라 열 3의 멤버가 다른 레벨의 하위 범주로 구분됩니다. 예를 들어, 측정항목 차원의 마진은 Sales 및 COGS로 나뉩니다.

표 1-1 TBC 샘플 치수

차원 멤버 하위 멤버

Year

Qtr1

1월, 2월, 3월

Year

Qtr2

4월, 5월, 6월

Year

Qtr3

7월, 8월, 9월

Year

Qtr4

10월, 11월, 12월

측정항목

수익

마진: 판매, COGS

총 비용: 마케팅, 급여, 기타

측정항목

인벤토리

재고 개설, 추가, 재고 종료

측정항목

비율

마진 %, 이익 %, 온스당 이익

제품

콜라 (100)

콜라(100-10), 다이어트 콜라(100-20), 카페인 프리 콜라(100-30)

제품

루트 맥주 (200)

구형(200‑10), 다이어트 루트 맥주(200‑20), 사르사파릴라(200‑30), 버치 맥주(200‑40)

제품

크림 소다 (300)

다크 크림(300‑10), 바닐라 크림(300‑20), 다이어트 크림 소다(300‑30)

제품

과일 소다 (400)

포도(400‑10), 주황색(400‑20), 딸기(400‑30)

Market

동쪽

코네티컷, 플로리다, 매사추세츠, 뉴햄프셔, 뉴욕

Market

West

캘리포니아, 네바다, 오레곤, 유타, 워싱턴

Market

South

루이지애나, 뉴멕시코, 오클라호마, 텍사스

Market

센트럴

콜로라도, 일리노이, 아이오와, 미주리, 오하이오, 위스콘신

Scenario

실제

N/A

Scenario

Budget

N/A

Scenario

편차

N/A

Scenario

편차 비율(%)

N/A

또한 애플리케이션 디자이너는 크기 및 패키징을 기반으로 제품을 분석할 수 있도록 다음 속성 차원을 추가했습니다.

표 1-2 TBC 샘플 속성 차원

차원 멤버 하위 멤버

온스

큼

작음

64, 32, 20

16, 12

패키지 유형

병

가능

N/A

차원 및 멤버 결정에 대한 체크리스트

모델 데이터베이스의 차원 및 멤버를 결정할 때는 다음 체크리스트를 사용하십시오.

  • 차원 후보자는 무엇입니까?

  • 차원 중 다른 차원을 분류하거나 설명하는 차원이 있습니까? 이러한 차원은 속성 차원의 후보입니다.

  • 사용자가 차원에 대한 뷰를 한정하시겠습니까? 차원에 적합한 범주는 속성 차원에 대한 후보입니다.

  • 멤버의 후보자는 무엇입니까?

  • 데이터에 필요한 레벨은 몇 개입니까?

  • 데이터는 어떻게 통합됩니까?

데이터베이스 설계 분석

차원 수, 결합된 분석 값 및 반복 회피에 대한 지침에 따라 초기 Essbase 차원 설계를 검토합니다. 이 선행 분석을 수행하면 데이터 통합 및 계산 목표를 충족하는 효율적인 데이터베이스 설계를 달성하는 데 도움이 됩니다.

잠재적 데이터 포인트를 설명하는 데 필요한 멤버 수는 차원 수를 결정해야 합니다. 차원을 삭제해야 할지 여부가 확실하지 않으면 차원을 유지한 후 삭제하거나 유지할 수 있을 때까지 더 많은 분석 규칙을 적용합니다.

밀집 및 희소 치수

희소 차원과 조밀 차원은 성능에 영향을 줍니다. 다음을 참조하십시오.

표준 및 속성 차원

단순성을 위해 이 항목의 예에서는 처음에 두 차원으로 설계된 항목에 대한 대체 배열을 보여줍니다. 모든 차원 조합에 동일한 논리를 적용할 수 있습니다.

여러 시장에 걸쳐 여러 고객에게 제품을 판매하는 회사의 디자인을 고려하십시오. 시장은 각 고객에게 고유합니다.

             Cust A  Cust B  Cust C
New York     100     N/A     N/A
Illinois     N/A     150     N/A
California   N/A     N/A     30

고객 A는 뉴욕에만 있고 고객 B는 일리노이에만 있으며 고객 C는 캘리포니아에만 있습니다. 회사는 하나의 표준 차원에서 데이터를 정의할 수 있습니다.

Market
  New York
    Cust A
  Illinois
    Cust B
  California
    Cust C

그러나 더 큰 데이터 샘플링을 살펴보면 많은 고객이 각 시장에 진출할 수 있음을 알 수 있습니다. Cust A 및 Cust E는 뉴욕에 있고 Cust B, Cust M 및 Cust P는 일리노이에 있으며 Cust C 및 Cust F는 캘리포니아에 있습니다. 이 경우 회사는 일반적으로 큰 차원인 Customer를 표준 차원으로 정의하고 더 작은 차원인 Market을 속성 차원으로 정의합니다. 회사는 Market 차원의 멤버를 Customer 차원의 멤버의 속성으로 연결합니다. Market 차원의 멤버는 고객의 위치를 설명합니다. 각 고객은 정확히 하나의 시장을 가집니다.

Customer (Standard dimension)
  Cust A (Attribute:New York)
  Cust B (Attribute:Illinois)
  Cust C (Attribute:California)
  Cust E (Attribute:New York)
  Cust F (Attribute:California)
  Cust M (Attribute:Illinois)
  Cust P (Attribute:Illinois)
Market (Attribute dimension)
  New York
  Illinois
  California

다른 상황을 고려하십시오. 다시 말하지만, 회사는 여러 시장에 걸쳐 여러 고객에게 제품을 판매하지만, 회사는 다른 시장에 위치가있는 고객에게 판매 할 수 있습니다 :

             Cust A  Cust B  Cust C
New York     100      75     N/A
Illinois     N/A     150     N/A
California   150     N/A      30

Cust A는 뉴욕과 캘리포니아에 있습니다. Cust B는 뉴욕과 일리노이에 있습니다. Cust C는 캘리포니아에만 있습니다. 이 경우 속성 차원을 사용할 수 없습니다. 고객 멤버는 다중 속성 멤버를 가질 수 없습니다. 따라서 회사는 다음과 같은 두 가지 표준 차원으로 데이터를 설계합니다.

Customer
  Cust A
  Cust B
  Cust C
Market
  New York
  Illinois
  California

차원 조합

두 차원의 각 조합을 2차원 행렬로 나눕니다. 예를 들어, TBC에서 제안된 차원에는 다음 조합이 포함됩니다.

  • 연도 전체 측정

  • 상품간 연도

  • 연도 전체 시장

  • 시나리오간 연도

  • 상품간 측정

  • 시장간 측정

  • 시나리오간 측정

  • 상품간 시장

  • 시나리오간 시장

  • 상품간 시나리오

  • 패키지 유형간 온스

제품 차원과 연계된 속성 차원인 온스 및 패키지 유형은 제품 차원에서 고려할 수 있습니다.

각 차원을 시각화하기 위해 매트릭스를 그리고 몇 개의 1세대 멤버를 포함합니다. 다음 이미지는 세 차원에 대한 단순화된 행렬 집합을 보여줍니다.

그림 1-2 치수 관계 분석


이 이미지는 차원 관계를 분석하는 방법을 보여주는 세 차원에 대한 단순화된 매트릭스 세트를 보여줍니다.

차원의 각 조합에 대해 다음 세 가지 질문을 합니다.

  • 분석 가치가 추가됩니까?

  • 보고용 유틸리티를 추가합니까?

  • 사용되지 않은 조합의 과잉을 피할 수 있습니까?

각 조합에 대해 질문에 대한 답변은 조합이 데이터베이스에 적합한지 여부를 결정하는 데 도움이 됩니다. 이상적으로 각 질문의 대답은 예입니다. 그렇지 않은 경우 데이터를 보다 의미 있는 차원으로 재배열하는 것이 좋습니다. 이 과정을 진행하면서 유저와 정보 요구 사항에 대해 논의합니다.

아웃라인에서 반복

아웃라인에서 요소를 반복하면 치수를 분할해야 하는 경우가 많습니다. 다음 예에서는 반복을 피하는 방법을 보여줍니다.

이 예에서 "반복"이라는 레이블이 붙은 왼쪽 열은 계정 차원의 예산 및 실제에서 반복되는 이익, 마진, 판매, COGS 및 비용을 보여줍니다. "반복 없음"으로 레이블이 지정된 오른쪽 열은 예산 및 실제를 다른 차원(시나리오)으로 구분하여 계정 차원에서 수익, 마진, 판매, COGS 및 비용 멤버 세트를 하나만 남깁니다. 이 접근 방식은 아웃라인을 단순화하고 데이터베이스의 다른 차원에 대한 예산 및 실제 수치를 더 간단하게 보여줍니다.

그림 1-3 시나리오 치수를 작성하여 반복 제거의 예


이 이미지는 이미지 앞의 텍스트에 설명된 대로 반복 문제에 대한 하나의 해결책을 제공합니다.

이 예에서 "반복"이라는 레이블이 붙은 왼쪽 열은 다이어트 차원의 공유 멤버를 사용하여 다이어트 음료를 분석합니다. 회원 100-20, 200-20 및 300-20이 반복됩니다 : 한 번 다이어트, 한 번 각각의 부모 아래. "반복 없음"이라는 레이블이 지정된 오른쪽 열은 부울(True 또는 False) 유형의 다이어트 속성 차원을 생성하여 아웃라인을 단순화합니다. 모든 멤버는 해당 상위 멤버 아래에 한 번만 표시되며 적절한 속성("Diet: True" 또는 "Diet: False")으로 태그 지정됩니다.

그림 1-4 속성 치수를 작성하여 반복 제거의 예


이 이미지는 이미지 앞의 텍스트에 설명된 대로 반복 문제에 대한 하나의 해결책을 제공합니다.

속성 차원은 추가 분석 기능도 제공합니다. Essbase 속성의 이점을 참조하십시오.

차원간 관련성

차원 간 관련성은 차원의 많은 멤버가 다른 차원에서 관련이 없는 경우 발생합니다. Essbase는 Essbase가 요약(차원) 레벨에서만 저장하는 데이터로 관련 없는 데이터를 정의합니다. 이러한 경우 데이터베이스에서 차원을 제거하고 해당 멤버를 다른 차원에 추가하거나 모델을 별도의 데이터베이스로 분할할 수 있습니다.

예를 들어, TBC는 급여 분석을 측정항목 차원의 멤버로 간주했습니다. 그러나 급여 정보는 종종 회사 데이터베이스의 맥락에서 관련이 없음을 입증합니다. 대부분의 급여는 기밀이며 개인에게 적용됩니다. 개인 및 급여는 일반적으로 다른 차원과 교차할 이유 없이 하나의 셀을 나타냅니다.

TBC는 직원을 별도의 차원으로 구분하는 것을 고려했습니다. 다음 표에서는 TBC가 다차원 불일치로 제안된 직원 차원을 분석한 방법의 예를 보여줍니다. 제안된 직원 차원(테이블 헤더 행에 표시됨)의 멤버는 측정 차원(가장 왼쪽 열에 표시됨)의 멤버와 비교됩니다. 측정항목 차원 멤버(예: 매출)는 모든 직원에게 적용되고, 임금 측정항목만 개별 직원과 관련이 있습니다.

표 1-3 치수간 관련성 예

빈 thead 셀에 사용되는 공간 이미지 Joe Smith Mary Jones Mike Garcia 모든 사원

Revenue

관련성

관련성

관련성

관련성

변동 비용

관련성

관련성

관련성

관련성

COGS

관련성

관련성

관련성

관련성

보급 중

관련성

관련성

관련성

관련성

급여

관련성

관련성

관련성

관련성

고정 비용

관련성

관련성

관련성

관련성

Expenses

관련성

관련성

관련성

관련성

수익

관련성

관련성

관련성

관련성

데이터베이스 분할 이유

개별 사원 정보는 데이터베이스의 다른 정보와 관련이 없으며 Employee 차원을 추가하면 데이터베이스 저장 영역 요구 사항이 크게 증가하기 때문에 TBC는 별도의 HR(Human Resources) 데이터베이스를 생성했습니다. 새 HR 데이터베이스에는 관련 차원 그룹이 포함되어 있으며 급여, 복리후생, 보험 및 401(k) 제도가 포함되어 있습니다.

데이터베이스를 분할하는 이유는 여러 가지가 있습니다. 예를 들어, 회사가 여러 시간대에 여러 국제 자회사를 포함하는 조직 데이터베이스를 유지 관리하는 경우가 있습니다. 각 자회사는 시간에 민감한 재무 계산에 의존합니다. 재무 계산이 적시에 이루어지도록 동일한 시간대의 자회사 그룹에 대해 데이터베이스를 분할할 수 있습니다. 분할된 애플리케이션을 사용하여 자회사별로 정보를 구분할 수도 있습니다.

데이터베이스 설계 분석 체크리스트

다음 점검 목록을 사용하여 데이터베이스 설계를 분석합니다.

  • 차원 수를 최소화했습니까?

  • 각 차원 조합에 대해 다음을 요청했습니까?

    • 분석 가치가 추가됩니까?

    • 보고용 유틸리티를 추가합니까?

    • 사용되지 않은 조합의 과잉을 피할 수 있습니까?

  • 개요에서 반복을 피했습니까?

  • 다차원적 불일치(interdimensional irrelevance)를 피했습니까?

  • 데이터베이스를 필요에 따라 분할했습니까?