Essbase 아웃라인 초안 작성

Essbase 데이터베이스 모델의 초안을 작성한 후에는 애플리케이션 및 데이터베이스를 생성하고 아웃라인의 첫 번째 초안을 작성할 수 있습니다. 초안은 모든 차원, 멤버 및 통합을 정의합니다. 개요를 사용하여 통합 요구사항을 설계하고 공식 및 계산 스크립트가 필요한 위치를 식별합니다.

아웃라인은 Essbase 애플리케이션 내에 있는 Essbase 데이터베이스(또는 큐브)의 일부입니다.

이전에 소개된 Beverage Company 예제를 사용하기 위해 TBC 응용 프로그램 설계자는 데이터베이스 아웃라인에 대해 다음 초안을 실행했습니다. 이 계획에서 연도, 측정, 제품, 시장, 시나리오, 패키지 유형 및 온스는 차원 이름입니다. TBC가 어떻게 통합, 계산 및 공식, 보고 요구 사항을 예측했는지 알아봅니다. 또한 응용 프로그램 설계자는 제품 이름 대신 제품 코드를 사용하여 제품을 설명했습니다.

연도입니다. TBC는 매월 데이터를 수집하고 분기 및 연도별로 월별 데이터를 요약해야 합니다. 1월, 2월, 3월 등의 멤버에 저장된 월별 데이터가 분기로 통합됩니다. Qtr1 및 Qtr2와 같은 멤버에 저장된 분기별 데이터가 연도로 통합됩니다.
측정 단위. 판매, 매출 원가, 마케팅, 급여, 기타, 기초 재고, 추가 및 기말 재고는 표준 측정 단위입니다. Essbase는 이러한 측정에서 마진, 총 비용, 이익, 총 재고, 이익 %, 마진 % 및 온스당 수익을 계산할 수 있습니다. TBC는 월별, 분기별 및 연도별로 측정값을 계산해야 합니다.
제품. 제품 코드는 100‑10, 100‑20, 100‑30, 200‑10, 200‑20, 200‑30, 200‑40, 300‑10, 300‑20, 300‑30, 400‑10, 400‑20 및 400‑30입니다. 각 제품은 해당 제품군(100, 200, 300 및 400)에 통합됩니다. 각 제품은 온스 및 패키지 유형 속성 차원의 멤버와 연계되므로 TBC는 각 통합을 통해 크기 및 패키지별로 분석할 수 있습니다.
Market. 여러 주가 하나의 지역을 구성하며, 네 개의 지역이 하나의 시장을 구성합니다. 주에는 코네티컷, 플로리다, 매사추세츠, 뉴햄프셔, 뉴욕, 캘리포니아, 네바다, 오레곤, 유타, 워싱턴, 루이지애나, 뉴멕시코, 오클라호마, 텍사스, 콜로라도, 일리노이, 아이오와, 미주리, 오하이오 및 위스콘신이 있습니다. 각 주가 해당 지역(동부, 서부, 남부 또는 중부)으로 통합됩니다. 각 지역은 시장으로 통합됩니다.
Scenario. TBC는 예산 대 실제 데이터를 도출 및 추적합니다. 관리자는 예산 및 실제 값과 예산 간의 차이 및 차이 퍼센트를 모니터링하고 추적해야 합니다.
패키지 유형입니다. TBC는 제품 패키징이 판매 및 이익에 미치는 영향을 파악하고자 합니다. 패키지 유형 속성 차원을 설정하면 사용자가 제품이 병에 포장되어 있는지 아니면 캔에 포장되어 있는지에 따라 제품 정보를 분석할 수 있습니다.
온스 TBC는 다양한 시장에서 온스의 다양한 크기로 제품을 판매합니다. Ounces 속성 차원을 설정하면 사용자가 어떤 규모가 어떤 시장에서 더 잘 판매되는지 모니터링할 수 있습니다.

다음 항목에서는 차원 및 멤버 등록정보의 기본 사항과 아웃라인 디자인이 성능에 미치는 영향에 대해 설명합니다.

차원 유형입니다.

차원 유형은 차원에 특수 기능을 추가하는 Essbase가 제공하는 등록정보입니다. 특수화되고 일반적으로 사용되는 차원 유형은 시간, 계정 및 속성입니다.

이 항목에서는 TBC 데이터베이스의 다음 차원을 사용하여 차원 유형을 설명합니다.

Database:Design
  Year (Type: time)
  Measures (Type: accounts)
  Product
  Market
  Scenario
  Pkg Type (Type: attribute)
  Ounces (Type: attribute)

다음 표에서는 각 Essbase 차원 유형을 정의합니다.

표 1-4 차원 유형

차원 유형입니다.	설명
없음	특정 치수 유형을 지정하지 않습니다.
시간	데이터를 보고하고 업데이트하는 기간을 정의합니다. 하나의 차원만 시간으로 태그를 지정할 수 있습니다. 시간 차원은 첫 번째 및 마지막 시간 잔액과 같은 여러 계정 차원 기능을 사용으로 설정합니다.
계정	수익 및 재고와 같이 측정하려는 항목을 포함하며 Essbase 기본 제공 회계 기능을 사용할 수 있도록 합니다. 차원은 하나만 계정으로 정의할 수 있습니다.
속성	다른 소위 기본 차원의 멤버를 설명하는 데 사용할 수 있는 멤버를 포함합니다. 예를 들어, 패키지 유형 속성 차원에는 제품 차원의 멤버에 적용되는 각 포장 유형(예: 병 또는 캔)에 대한 멤버가 포함됩니다.
국가(통화 변환 기능에만 사용됨)	비즈니스 활동이 발생하는 위치에 대한 데이터를 포함합니다. 국가 차원에서 각 멤버에 사용되는 통화를 지정할 수 있습니다. 예를 들어, 캐나다에는 밴쿠버, 토론토 및 몬트리올의 세 시장이 있는데 이 시장은 동일한 통화인 캐나다 달러를 사용합니다.

Member Storage Properties

통합 저장 위치 및 시기를 정의할 멤버에 대한 데이터 저장 영역 속성을 지정합니다. 기본적으로 멤버는 저장된 태그로 지정됩니다. Essbase는 해당 값을 합산하고 결과를 상위 레벨에 저장합니다. data storage 속성 태그를 변경하여 각 멤버에 대한 기본 논리를 변경할 수 있습니다.

다음 표에서는 Essbase 데이터 저장영역 등록정보가 멤버에 미치는 영향에 대해 설명합니다.

표 1-5 Essbase 데이터 저장영역 등록정보

데이터 저장 영역 속성	멤버에 대한 영향
데이터 저장	멤버에 대한 데이터는 데이터베이스에 저장되며 저장소 데이터는 기본 저장소 등록 정보입니다. Essbase는 값의 합계를 계산하고 결과를 상위 레벨에 저장합니다.
동적 계산	멤버와 연관된 데이터는 사용자 질의에 의해 요청될 때 계산됩니다. 데이터는 저장되지 않고 질의 요청이 완료된 후에 삭제됩니다.
공유 멤버	멤버와 연결된 데이터는 동일한 이름을 가진 다른 멤버에서 가져옵니다.
공유 안함	암시적 공유 관계가 있는 경우 멤버와 연계된 데이터가 상위 및 해당 하위와 중복됩니다. 데이터는 첫번째 멤버 발생과 함께 아웃라인 순서로 저장됩니다.
레이블 전용	연결된 데이터가 없는 멤버에 대해 저장된 멤버를 레이블로만 변경할 수 있습니다. 레이블 멤버에만 데이터가 있지만 값을 표시할 수 있습니다. 레이블 전용 태그는 멤버를 그룹화하고 탐색 및 보고를 용이하게 합니다. 일반적으로 레이블 전용 멤버는 계산되지 않습니다. 예를 들어 측정항목 차원에서 멤버 비율은 Margin%, Profit%, 온스당 Profit라는 세 개의 하위를 가집니다. 멤버 비율은 멤버의 범주를 정의합니다. 통합된 경우 Margin%, Profit%, Profit% 및 Profit per Ounce는 Ratios에 대한 의미 있는 수치로 롤업되지 않습니다. 따라서 비율은 레이블로만 태그가 지정됩니다.

차원 및 멤버 속성에 대한 체크리스트

시간 차원을 식별할 수 있습니까?
계정 차원을 식별할 수 있습니까?
데이터에 외화가 포함되어 있습니까? 그렇다면 통화 파티션 차원을 식별했습니까?
별도의 속성 차원으로 정의해야 하는 차원의 특성 또는 특성을 식별할 수 있습니까?
특수 데이터 저장 영역 속성이 필요한 멤버는 무엇입니까?

성능 최적화를 위한 개요 설계

Essbase 아웃라인 끝에 속성 차원을 배치하고, 희소 앞에 밀집 차원을 배치하고, 멤버 수가 가장 적은 희소 차원을 먼저 정렬합니다. 아웃라인 내 차원의 위치와 차원의 저장영역 등록정보는 계산 실행 속도와 데이터를 검색하는 데 걸리는 시간에 영향이 있습니다.

쿼리 성능 최적화

Query 성능을 최적화하려면 Outline을 설계할 때 다음 지침을 따르십시오.

아웃라인에 속성 차원이 포함된 경우 아웃라인에서 속성 차원이 유일한 희소 동적 계산 차원인지 확인합니다.
아웃라인에서 더 자주 사용되는 희소 치수를 덜 질의된 희소 치수 앞에 배치합니다.

아래 설명된 개요는 최적의 질의 성능을 위해 설계되었습니다.

아웃라인에는 속성 차원이 포함되므로 표준 차원 및 모든 표준 차원 멤버에 대한 저장 영역 속성이 저장 데이터로 설정됩니다.
가장 자주 사용되는 희소 차원인 Product 차원은 희소 차원의 첫번째 차원입니다. 기본 치수는 일반적으로 다른 치수보다 많이 질의됩니다.

그림 1-5 최적화된 쿼리 시간을 위한 개요 설계

이 이미지는 이미지 앞의 텍스트에 설명된 대로 최적의 질의 성능을 위해 설계된 개요를 보여줍니다.

계산 성과 최적화

계산 성능을 최적화하려면 멤버 수가 가장 적은 차원부터 시작하여 아웃라인의 희소 차원을 순서대로 정렬합니다.

아래 설명된 개요는 최적의 계산 성능을 위해 설계되었습니다.

희소 표준 차원인 마켓(Market)은 아웃라인의 희소 차원 중 첫 번째 차원입니다.
희소인 Product인 가장 큰 표준 차원은 첫번째 속성 차원 바로 위에 있습니다. 아웃라인에 속성 차원이 포함되지 않은 경우 Product 차원은 아웃라인 끝에 있습니다.

그림 1-6 최적화된 계산 시간을 위한 개요 설계

이 이미지는 이미지 앞의 텍스트에 설명된 대로 최적의 계산 성능을 위해 설계된 개요를 보여줍니다.

계산 및 검색의 요구 사항 충족

동일한 차원을 포함하지만 이전에 표시된 예제 아웃라인은 다릅니다. 상황에 가장 적합한 Outline 시퀀스를 결정하려면 데이터베이스에서 계산을 실행하는 데 필요한 시간에 대해 유저의 데이터 검색 요구 사항의 우선 순위를 지정합니다. 얼마나 자주 데이터베이스를 갱신하고 재계산해야 합니까? 유저 query의 특성은 무엇입니까? 예상되는 사용자 쿼리 볼륨은 얼마입니까?

가능한 임시해결책은 처음에 계산 최적화를 위해 차원을 아웃라인에 배치하는 것입니다. 계산을 실행한 후 수동으로 치수의 순서를 재지정하여 검색을 최적화할 수 있습니다. Outline의 차원 위치를 변경한 후 Outline을 저장할 때는 인덱스별로만 데이터베이스를 재구성하도록 선택합니다. 계산을 다시 실행하기 전에 아웃라인에서 치수의 순서를 재지정하여 계산을 최적화합니다.