Oracle Direct Seminar...- SQLパフォーマンスチューニング手法が豊富・格納データの量と柔軟性、トランザクションに強い書き込みと参照の排他制御技術など、オンライン処理と集計

<Insert Picture Here>

Oracle Direct Seminar

入門の方も歓迎！多次元データベースの考え方からノウハウ教えます

日本オラクル株式会社Fusion Middleware事業統括本部 EPM/BI第一SC部2010年4月6日

Copyright© 2010, Oracle. All rights reserved. 2

本日の内容

• 多次元とは・・・

• Essbase 多次元データベースの構造

• Essbase キューブ作成ノウハウ

・SQL Serverからの移行アセスメント・MySQLからの移行相談

・PostgreSQLからの移行相談・Accessからの移行アセスメント

・Oracle Database バージョンアップ支援・Oracle Developer/2000 Webアップグレード相談

・パフォーマンス・クリニック・Oracle Database 構成相談

・Oracle Database 高可用性診断・システム連携アセスメント・システムセキュリティ診断

・簡易業務診断

無償技術サービスOracle Direct Concierge

http://www.oracle.com/lang/jp/direct/services.html



多次元とは・・・


多次元とは・・・

• そもそも、「次元」とは・・・

• データの切り口、分析の視点

• 時間、科目、組織、商品、シナリオ、バージョン、得意先 etc ・・・

• 世の中にある多くの業務データは多次元で定義されています

• 例えば、どこの企業でもありがちな以下の財務帳票は・・・

勘定科目次元

時間次元組織次元

シナリオ次元

時間次元

「9月累計」（時間次元）の

「事業部計」（組織次元）の

「売上原価」（勘定科目次元）の

「計画」（シナリオ次元）の数値は、

48,000でした


多次元分析とは・・・

全社半期売上高 (百万)

実績予算予実

ゴルフ 6,592 6,248 344

テニス 2,973 3,455 -482

スキー 2,526 2,399 127

野球 4,613 4,439 174

全商品 16,705 16,540 165

製品詳細

�S �Ð

�À �Ñ �\ �Z �\ �ÀºÞÙÌ¸×ÌÞ(W) 2,274 2,053 221ºÞÙÌ¸×ÌÞ(I) 2,027 2,053 -26ºÞÙÌ³ª± 2,117 1,991 126±̧¾»Ø 175 151 24 �S ��t 6,592 6,248 344

支店別 �e �j �X

�À �Ñ �\ �Z �\ �À

�� 1,440 1,542 -102

�å �ã 761 694 67

�¼ �Ã �® 376 386 -10

��ª 396 833 -437

�S �Ð 2,973 3,455 -482

時系列

全社実績

１月２月３月４月５月６月半期ゴルフ 1,023 977 1,237 1,027 1,098 1,230 6,592テニス 510 462 604 487 420 491 2,973スキー 421 369 501 397 385 454 2,526野球 705 697 957 763 726 766 4,613全商品 2,659 2,504 3,299 2,673 2,628 2,941 16,705

マウス操作でドリルダウン/視点切り替え（ピボット）が可能

ゴルフの内訳は？地域別での予実は？月次ベースでは？


多次元型データベースの概念

地区A

地区B

地区C

4月 5月 6月

160 290 225

120 90 200

115 123 190

ｶﾃｺﾞﾘC

地区A

地区B

地区C

4月 5月 6月

110 80 145

120 90 220

115 123 146

ｶﾃｺﾞﾘB

地区A

地区B

地区C

4月 5月 6月

150 140 145

120 170 200

115 123 154

ｶﾃｺﾞﾘA

地区A

地区B

地区C

4月 5月 6月

150 140 145

120 170 200

115 123 154

店舗A

店舗B

店舗C

40 55 80

50 65 65

30 50 55

ダイス（軸の切替）スライス

ドリルダウン/ドリルアップ

地区A

地区B

地区C

4月 5月 6月

420 510 515

500 550 620

450 550 490

時間次元

地域次元

地区A

地区B

地区C

ｶﾃｺﾞﾘA

420 510 515

500 550 620

450 550 490

製品次元

地域次元

ｶﾃｺﾞﾘCｶﾃｺﾞﾘB

ｶﾃｺﾞﾘA

4月 5月 6月

720 700 850

400 450 470

500 490 530

時間次元

商品次元ｶﾃｺﾞﾘC

ｶﾃｺﾞﾘB

地区E

カテゴリBカテゴリA

カテゴリC

地区D

地区C

地区B

地区A

4月

5月

6月

7月

地区B

店舗Ａ

店舗Ｂ

店舗Ｃ


多次元分析に便利なツールが OLAP(BI) ツールです

OLAP/BIツール

M-OLAP• OLAP側でキューブを作り、バッチでの事前データ取込・集計が必要• 事前集計のため、集計済のデータアクセスは早い• キューブあたりに保持できるデータ量には制限がある（明細よりも集計データ向き）• ライトバック（書込）機能に対応している製品も多く、豊富な財務関数と組み合わせてシミュレーション・予測・計画策定業務に活用されることも多い

R-OLAP• RDBに直接アクセスしてデータを検索するため、リアルタイム分析が可能であり、明細の扱いにも強い• 検索パフォーマンスが遅い場合には、集約テーブルをDB側に事前に作り対応することが多い• BIツールまたはDBでスタースキーマを生成する

多次元に特化した

物理DBを利用

擬似的にRDBを組み合わせM-OLAP生成

Oracle Essbase

OLAP方式 DB実装方式代表的ツール名

COGNOS Power Play

Oracle BIEE

Business Objects

SAP BW

クライアントにて検索スキーマ作成（2層：EUC型）

Oracle Discoverer

Hyperion Interactive Reporting （BRIO）

Micro Strategy

BIサーバ上で検索スキーマを設定し、ユーザーはWebから利用（3層：統合型）


M-OLAP と R-OLAP

より集計されたデータ

明細に近いデータ

情報の量・粒度

多・細尐・大

販売分析店舗情報

売上・在庫分析顧客分析

ﾃﾞｰﾀﾍﾞｰｽﾏｰｹﾃｨﾝｸﾞ異常値管理

明細に近い情報非財務情報

部門（店舗収益）損益管理月次決算

予算実績管理予算編成原価管理管理会計

参照

検索

分析集約情報

財務・会計情報予測・シミュレーション

データ要件

M-OLAP（MDDB）

R-OLAP（RDB+BI）

・多次元“Cube(キューブ)”と呼ばれるバイナリー形式で格納- ユーザが必要とする集計値を予めバッチで計算し格納

・優れたクエリーに対するパフォーマンス- 集計済みデータを検索するので、R-OLAPと比べ非常に処理が速い- 必要な情報の切り口について、「次元」により実アドレスからアクセスできるため、データアクセスが非常に早い

・格納データのサイズ/形式の制限- 大量の更新トランザクションには向かず、明細データの管理には複数キューブを作る事や、ドリルスルーの機能でRDBと組み合わせ対応

・Excelとの親和性／書込（ライトバック）機能- Excelとの高い親和性と書込み機能によりシミュレーション、予測・計画策定業務にも活用可能

・複数の表を組み合わせでリレーショナルDBに格納- 多種ベンダーが出すＢＩツールとRDBMSとの組み合わせ- SQLパフォーマンスチューニング手法が豊富

・格納データの量と柔軟性、トランザクションに強い- 書き込みと参照の排他制御技術など、オンライン処理と集計処理の混在など、汎用的に利用が可能

・集計/計算ロジックに対するパフォーマンスの課題- 複雑な分析→操作都度計算のため、性能劣化の懸念- Excelなどからの書込み、データ修正の実装が困難

・マスタ設計の自由度- 複数のテーブルを組み合わせることで、様々なデータ要件に柔軟に対応可能

どちらが良い悪いではなく、システムの目的・要件に応じて活用


Essbaseの開発コンセプト

Oracle の M-OLAP製品 Essbase とは？OLAPの概念を生み出した分析志向の多次元データベース

Essbase = Extended Spreadsheet Server Database

RDB,OLAPの生みの親E.F.Ted.Codd

1970 1991

Essbase登場

1994

EssbaseとRDBとの差異を明確にするためにOLAPの概念を提唱

Relational DBのモデル提唱

EssbaseとOLAPの関係

・高々２次元での情報分析・財務モデルの計算が不向き

・多次元データを分析モデルの構造のままDBとして格納

・財務モデルを想定した機能搭載

EssbaseSpreadsheet


分析用次元の設定例（登録数は上限なし※）

会社勘定科目事業 BU 製品地域シナリオ

Essbase

Webでのレポーティング（BIツールとの組合せ）

Excelでの分析（標準インタフェースとして提供）

1.高いユーザ操作性Excelとの高い親和性ビジネス階層構造でのマスタ管理VB,C,Javaによるアプリ開発も可能

2.高度な計数処理能力ライトバック機能による予算・予測策定、シミュレーションへの応用豊富な関数ライブラリの提供

3.豊富な分析基盤を提供会計・財務に特有の機能を搭載ビジュアル分析機能も搭載

Essbaseの主な特長

膨大な計数情報をマウス操作で自由に抽出

多次元のデータを視覚的に表現（Visual Explorer）

分析用途の情報を「次元」として登録

各次元項目は「階層構造」で事前に集計

※但しパフォーマンス・セキュリティ等の問題とのトレードオフ（10次元前後の利用実績が通常）。DBの構築数にも制限はなし。

Oracle Essbase の特長多次元データベース（M-OLAP）の草分け的存在、市場シェアNo1


明細データの取扱いにも強い Essbase オプション強力な集計アルゴリズムを持つ ASO オプション

• 財務系データに強みを持つ従来の集計アルゴリズム(BSO)に加えて、新たな分析ストレージ「集計ストレージ（ASO）」も具備し、これにより大規模データセットでも高速に取り扱えます。

• 従来のキューブ作成時間が大幅に減尐（時間単位が分単位に）

• 更にキューブサイズも大幅縮小（10分の1以下）

• 100万超のメンバ項目数でも十分対応可能

Analytic Services(Essbase Server)

顧客分析物流・調達分析予算 &

財務連結予測・

収益性分析

大量の積み上げ計算を高速に行う場合はASO

大量の明細が必要となる分析はASO

シミュレーションや書込みが必要な分野もBSO

計算の複雑性

BSO適性 ASO適性

データボリューム

データ特性に応じた最適なローディングを実現

BSO(Block Storage Option) ASO(Aggregate Storage Option)

単純(但し高度な集計)

複雑

疎

密

集計ストレージ

双方のストレージを結合

データセット

計算

ブロックストレージ

BSOとASOの適性領域とキューブの統合

パーティショニング技術により、両タイプのストレージを密結合し一つの仮想キューブとして提供

Essbase Analytics（基本） Enterprise Analytics（拡張）

配賦計算や財務分析に特有の複雑な計算はBSO

BSOとASOの使い分け（イメージ）


Essbase 活用シナリオ例BIの分野だけでなく、財務・管理会計、生産管理の分野でも多くの実績

①【計画系】

予算管理、実績管理シミュレーション

②【損益管理系】

売上/見込み管理機種・顧客別損益管理

④【原価管理系】

原価企画・ライフサイクルコスティング

③【生産管理系】

製販売在庫(PSI)調整、需給調整

「予算編成はエクセルでの力作業になり非常に負荷がかかる」「予実差異分析はやっているけど、そもそも当初予算の精度が低くて困っている」

「分析、シミュレーションが中々手付かずの状態」

「組織別の損益管理は出来ているが、製品別や機種別、顧客別、ルート別管理が行えていない」

「精度の高いフォーキャストを行いたい」「営業部門で計数データを早く還元したい」

「在庫や生産拠点の稼働率状況が見えないため、生産計画を勘や経験に頼ってしまう」

「計画業務を基幹システムと別に、Excelを駆使して遂行」「部材の納期確認に時間が要する」

「財務報告用途の原価計算に閉じてしまい、意思決定に活用出来ていない」

「原価シュミレーションができていない」「明細データへのトレースが出来ない」

経理部財務部経営企画部販売統括部

経理部原価企画部原価管理部企画・設計部

生産管理部営業管理部経営企画部

⑤【エクセル統制系】

計数データの集中管理

「会社の重要な意思決定を行う計数データはエクセルで管理されていて、属人化している」

「データの確認や検証作業ができていない」「二重管理が多く、負荷が大きい」

Excel利用者全体

シナリオ該当部門想定課題

経営層（CXO）経営企画部経理部各部の予算担当者


BIEE/Essbase : Management Excellence

【経営企画・財務経理】

損益計算書

貸借対照表

C/F計算書

管理会計

予算編成

【生産・出荷担当】

需給調整

在庫・出荷計画在庫実績

【原価企画】

原価ｼﾐｭﾚｰｼｮﾝ

想定原価標準原価・実態ｺｽﾄ

Essbaseを中核に据えたマネジメント・エクセレンス

【販社・営業】

【代理店】

会計受発注人事・

給与・勤怠生産

物流・在庫

販売・顧客

販売計画・予測

需要・見通

ERPOperational Excellence

【営業統括】

販売計画策定

売上

スプレッドシート統制

Data Warehouse

BI-EE

BI Apps

ダッシュボード

KPIKPIベースの

予算策定



Essbase 多次元データベースの構造


次元の疎密設定

Block

Block

Block

データファイル(.pag)

インデックスファイル (.ind)

各ブロックのポインタを持つ

Year次元

Acco

un

t

次元

疎次元を構成

密(Dense)次元 –データ・ブロック内のセル（データ）を構成する次元疎(Sparse)次元 –データ・ブロックを構成する次元

Year 時間Account 会計

Scenario

Product

Market

密

疎

メンバ数保管メンバ数

２０１０２０１０２０１０

１データ・ブロックのセル数 = 密次元の保管メンバ数の組み合わせ=１０×１０×１０＝１０００セル

１セル＝８バイト１データ・ブロックのサイズ＝１０００セル×８バイト＝８０００バイト

＝７．８ＫＢ

※Scenario次元は疎にするケースも多い

データ・ブロック

各疎次元のメンバの組み合わせ毎に作成される

セル

Block

Scenario次元密次元を構成


疎密設定について

次元の疎密設定は、Essbaseデータベース（=キューブ）の計算・データ取得のパフォーマンスに大きく影響するため、大変重要です。

• 疎密設定の方法（EAS管理コンソール）• アウトラインの[プロパティ]タブ

• データ・ストレージ自動構成→false に変更(デフォルトは true)

• 次元ストレージタイプで各次元の「疎」・「密」を選択

• ブロックサイズの確認（EAS管理コンソール）• データベースを右クリック→[プロパティ]の[統計]タブ

• [ブロック]セクションの[ブロックサイズ]

• あくまで目安であるが、100KBを超えない程度に設定するのがよい• 大きすぎてもデータブロックがメモリに載るスピードが遅くなり、小さすぎてもデータブロックを跨る計算が多く発生してしまうので問題

疎密の設定

自動構成をFalseにしてそれぞれの次元に対して、疎・密を設定

ブロックサイズの確認

自分で保管メンバ数を掛け合わせて算出するのではなく、データベースの統計タブで確認が可能



Essbase キューブ作成ノウハウ


キューブをどの単位で作成するか

• キューブを分けることのメリット• 保持するメンバ数が限定でき、計算・データ取得パフォーマンスが向上

• 他グループ・事業部ユーザの処理に影響を受けにくくなる

• アプリケーションごとに設定できるメモリ容量に上限がある

• ログはアプリケーションごとに出力されるため、ログ解析がしやすい

• キューブを分けることのデメリット• 標準機能のレポートの表（グリッド）は1データベースから出力される

• 1つの表に対して複数のキューブからデータを取得する必要がある場合、開発が必要

• データの集約するためのキューブを作成する必要がある

• 運用対象のキューブが増えるため、管理工数が増大する傾向にある

1つのキューブに全ての項目を定義できるのが理想ですが、キューブのサイズが大きくなりすぎるとパフォーマンスの劣化が生じてしまうため、キューブ分割を検討します。


キューブを分けるときのポイント

• 次元メンバ数 = データ量• 特に計算パフォーマンスに影響

• 計算内容・分析項目を分けられるかどうか

• レポートレイアウト• 1レポートとして見たいかどうか

• 管理・運用面• 管理するキューブが増える = 運用負荷増

• キューブが増えるとインタフェース本数が増える傾向にある

• キューブ分割例• 組織の違いによる分析項目・処理の違いを意識

• 事業部別キューブ, 全社集計キューブ

• データ粒度の違いを意識

• 実績キューブ, 予実管理キューブ

• 業務（管理科目）の違いによる分析項目・処理の違いを意識

• 販売分析キューブ, 損益管理キューブ, PSI キューブ

キューブを分けるのかどうかは、お客様の要件に応じた判断が必要になります。その際のポイントを挙げておきます。


• キューブ間連携方法• パーティションニング（複製・透過・リンク）

• @XREF関数によるデータ参照

• データのエクスポート + インポート

• バッチジョブ化が可能

• 他システム連携• ODI（ETLツール）, Essbase ルールファイルによるデータ連携

• RDBMS への明細ドリルスルー

• ERP にある仕訳、明細データにリンクさせたいときに効果的

• Essbase Studio, Essbase Integration Services により設定

• XOLAP

• Ver11 の新機能、Essbase Studio により設定

• Essbase キューブにはデータを持たず、ソースシステムにのみデータを保持する

キューブ間のデータ連携方法

キューブ分割したら、多くの場合はキューブ間の連携が必要になることが多いです。ここではキューブ間の連携方法について挙げておきます。

全社Cube

A事業Cube

・・・

B事業Cube

Z事業Cube


よく定義される次元例（データの切り口）

• 勘定科目,会計次元（売上高, 売上原価, 利益, 利益率・・・）

• 売上,原価などの金額だけでなく、数量,人数などの項目も定義可能

• 「会計」タグを付けることで、タイム・バランスなどの会計情報の設定が可能に

• KPI はここで定義されることが多い

• 組織次元（全社計, 経理部, 東京支店・・・）

• 会社組織, 事業部などを定義

• シナリオ次元（実績, 予算, 予測・・・）

• 業務シナリオを定義

• 予実管理をする場合は必ず定義

• バージョン次元（確定, 作業用, シミュレーション）

• シナリオ次元と組み合わせて使うことが多い

• 予算編成等、ステップごとに数値を保存しておき比較したいケースに使われる

Essbaseでは自由に次元が定義できます。但し、お客様の分析したいデータの切り口・軸は、Essbaseで管理される業務ごとに大体決まってきます。また、出力レポートの中から切り口（軸）の洗い出しをすると、定義する次元を決めていくことができます。



• 会計年度次元（2009年度, 2010年度・・・）• 期間次元（1月, 2月, 3月, 第1四半期, 上期）

• 会計年度次元と合わせて時間次元として定義し、年の下に半期→四半期→月メンバを配置することもある

時間次元

2009年度

2009年上期

2009年第1四半期

2009年1月

2009年2月

2009年3月


2010年度

2010年上期


会計年度と期間を1つの次元で定義するパターン

2011年度

・・・

・・・

会計年度次元

2009年度

上期

第1四半期

1月

2月

3月

第2四半期

2010年度

下期

第3四半期

会計年度次元と期間次元を別々に定義するパターン

2011年度

・・・

年計

第4四半期

期間次元

2012年度

・・・

時間軸を表す次元の定義方法には、「会計年度」と「期間」を分けるパターンと、一緒に定義をするパターンがあります。どちらが正しいということはなく、お客様の要件・管理のしやすさなどの観点から決定されます。



• 商品次元

• 顧客（得意先）次元• 商品, 顧客次元は販売・売上管理で定義されることが多い

• 単位次元（1, 千, 百万・・・）• メンバ計算式+動的計算を組み合わせて作成

• 通貨次元（JPY, USD, EUR・・・）• 通貨換算が必要な場合に定義

• プロジェクト

・・・etc


アウトラインの並び順を意識する

• アウトラインの推奨される並び順序• 保管メンバの多い密次元• 保管メンバの尐ない密次元• 保管メンバの尐ない疎次元• 保管メンバの多い疎次元

• 疎次元の計算を実行してしまうと、データブロックが先に数多く作成されてしまい、計算対象のデータブロックがメモリに存在しない確率が高くなり、ディスクIOが発生しやすくなります。

• 先にデータブロック内の計算である密次元の計算を実行し、ブロックの数が尐ない疎次元から計算を実行した方がより高い計算パフォーマンスが得られます。

• 但し、計算スクリプトの記述の仕方で計算の順序付けはできるので、レポーティングを重視した並びにすることもあります。

特に計算スクリプトで計算順序を指定しなければ、アウトラインでの次元の並び順に計算が実行されます。そのため、アウトラインの並び順は重要です。

密

疎

保管メンバの多い密次元↓

保管メンバの尐ない密次元

保管メンバの尐ない疎次元↓

保管メンバの多い疎次元


次元階層の設計テクニック

• 集計→明細階層（計算結果メンバ→計算元メンバ）• メンバの集計記号（+,-,*,/など）を活用し、集計メンバが親、集計メンバの計算の元となる明細メンバを子として定義

• グルーピング階層• メンバのグルーピングに活用（レポーティング・計算・メンバ項目の整理など）

• その他、計算のためのメンバのグルーピング（フラグ付け）には UDA（ユーザ定義属性）も便利• メンバをまとめるというだけの用途なので、親メンバには通常「ラベルのみ」を使用• @DESCENDANTS(子孫), @CHILDREN(子)などの関数を使い、グルーピング階層での計算範囲指定も可能

集計メンバ（親）→明細メンバ（子）で階層を作ると、階層の並びでの積上計算を活用できますし、レポーティングでのドリルダウンによる明細遡及・ドリルアップによる集計がきれいに定義できます。

集計→明細階層例：

売上総利益（親）

= + 売上高（子）

-売上原価（子）

グルーピング階層例：

Ratios メンバ（親）で比率関連メンバをまとめる


メンバ定義のテクニック（データストレージ）

• データの保管• デフォルトでの設定• レベル0 メンバ、疎次元メンバは保管メンバが多い

• 動的計算• メンバ計算式が定義されているメンバ、密次元での集計（親）メンバで使うと効果的（積上計算をスクリプトで実行する必要がなくなるだけでなく、ブロックサイズの削減にも繋がります）

• 子の多い疎次元メンバに使うとデータ取得のパフォーマンスが劣化する

• 共有しない• Hyperion Planning でのデフォルト設定• 親と子メンバが1対1のときに暗黙の共有関係として同じデータが保持されるが、親と子でデータを共有させたくない場合に使用• 暗黙の共有とは、Essbase により勝手に共有関係が設定される状態のこと

暗黙の共有例：

親メンバである「コーヒー飲料」と子メンバである「BASSコーヒー」は1:1であるため、子である「BASSメンバ」の値が親である「コーヒー飲料」に自動的に格納されている

メンバのタイプに応じたデータストレージの設定が必要です。データストレージの設定によりデータベースのブロックサイズ、データベース関連ファイルのサイズも大きく変わってきますので、注意が必要です。


• ラベルのみ• メンバのグルーピングに使用

• 共有メンバ

• 共有メンバを活用することで、データを2重持ちすることなく、別の分析用の階層を作成することが可能

地域別顧客分析階層

（「データの保管」メンバで作成）

販売チャネル別顧客分析階層

（「共有メンバ」（レベル0のみ）で作成）

メンバ定義のテクニック（データストレージ）

共有メンバの活用例

分析用階層の作成


メンバ定義のテクニック（会計次元編）

• タイムバランス（TB）の活用• B/S科目, 人員数などバランスでデータを持ちたいときに活用• #Missing値, 0 のスキップを活用すると時間タグの付いた次元の集計メンバにバランス値が格納される

• タイムバランスの設定方法（EAS管理コンソール）• [会計タグ]の設定されている次元（通常、勘定科目次元）のメンバに設定が可能• メンバの設定の[会計情報]のところでタイムバランス・スキップオプションの設定可能

データを積上後、集計メンバである「第1四半期」の結果が・・・

•「期首在庫」メンバは「TB期首」に設定されているため、1月の値である 100 になる

•「追加在庫」メンバは何も設定されていないので、そのまま1～3月が足され 330 になる

•「期末在庫」メンバは「TB期末」に設定されているため、3月の値である 120 になる

•「期末在庫その2」メンバは「TB期首」・「Missingのスキップ」に設定されているため、Missing

である3月の値がスキップされ、2月の値の 110 になる

バランスデータに対しては、タイムバランス設定の活用を検討します。


累計データの算出に動的時系列を活用する

• 累計データの自動算出• 動的時系列機能を使うと、設定1つでEssbaseの側で自動的に累計計算をしてくれます（メンバ計算式・スクリプトを記述する必要はない）。

• 動的時系列の設定方法（EAS管理コンソール）• 「時間」タグを付けた次元メンバを右クリック→[動的時系列]を選択、[動的時系列メンバーの定義] 画面により設定

• 動的時系列の使い方• Excelアドイン, FR, WA など Essbase のレポーティングツールにより累計データが取得できます。

レポート要件に多い累計の算出ですが、Essbaseでは設定ひとつで対応が可能です。

動的時系列の設定

使いたい系列メンバにチェックをし、どの世代単位で累計を出すかを選択

また、別名を入れることも可能累計データの取得

特に計算を記述することなく、左記メンバの定義で選択した系列メンバ、または、別名と累計を出したい月を半角括弧でくくると、累計が自動算出されます


OTN×ダイセミでスキルアップ!!

※OTN掲示版は、基本的にOracleユーザー有志からの回答となるため100%回答があるとは限りません。ただ、過去の履歴を見ると、質問の大多数に関してなんらかの回答が書き込まれております。

Oracle Technology Network(OTN)を御活用下さい。

・一般的な技術問題解決方法などを知りたい！・セミナ資料など技術コンテンツがほしい！

一般的技術問題解決にはOTN掲示版の

「データベース一般」をご活用ください

http://otn.oracle.co.jp/forum/index.jspa?categoryID=2

過去のセミナ資料、動画コンテンツはOTNの

「OTNセミナーオンデマンドコンテンツ」へ

http://www.oracle.com/technology/global/jp/ondemand/otn-seminar/index.html

※ダイセミ事務局にダイセミ資料を請求頂いても、お受けできない可能性がございますので予めご了承ください。ダイセミ資料はOTNコンテンツオンデマンドか、セミナ実施時間内にダウンロード頂くようお願い致します。

http://otn.oracle.co.jp/forum/index.jspa?categoryID=2


OTNセミナーオンデマンドコンテンツ期間限定にて、ダイセミの人気セミナーを動画配信中!!

ダイセミのライブ感はそのままに、お好きな時間で受講頂けます。

※掲載のコンテンツ内容は予告なく変更になる可能性があります。期間限定での配信コンテンツも含まれております。お早めにダウンロード頂くことをお勧めいたします。

OTN オンデマンド


オラクルクルクルキャンペーン

32

Enterprise Editionはここが違う!!

• 圧倒的なパフォーマンス!

•データベース管理がカンタン!

•データベースを止めなくていい!

• もちろん障害対策も万全!

Oracle Databaseのライセンス価格を大幅に抑えて

ご導入いただけます

詳しくはコチラ

http://www.oracle.co.jp/campaign/kurukuru/index.html

あのOracle Database Enterprise Editionが超おトク!!

お問い合わせフォームhttp://www.oracle.co.jp/inq_pl/INQUIRY/quest?rid=28

多くのお客様でサーバー使用期間とされる

5年間にライセンス期間を限定

•期間途中で永久ライセンスへ差額移行

• 5年後に新規ライセンスを購入し継続利用

• 5年後に新システムへデータを移行


http://www.oracle.co.jp/inq_pl/INQUIRY/quest?rid=28

Oracle Direct 検索

あなたにいちばん近いオラクル

Oracle Directまずはお問合せください

Web問い合わせフォームフリーダイヤル

専用お問い合わせフォームにてご相談内容を承ります。

※フォームの入力には、Oracle Direct Seminar申込時と同じログインが必要となります。

※こちらから詳細確認のお電話を差し上げる場合がありますので、ご登録されている連絡先が最新のものになっているか、ご確認下さい。

0120－155－096

※月曜~金曜 9:00~12:00、13:00~18:00

（祝日および年末年始除く）

システムの検討・構築から運用まで、ITプロジェクト全般の相談窓口としてご支援いたします。

システム構成やライセンス/購入方法などお気軽にお問い合わせ下さい。

http://www.oracle.co.jp/inq_pl/INQUIRY/quest?rid=28

Documents

Oracle Direct Seminar...- SQLパフォーマンスチューニング手法が豊富 ・格納データの量と柔軟性、トランザクションに強い 書き込みと参照の排他制御技術など、オンライン処理と集計

Oracle Direct Seminar...- SQLパフォーマンスチューニング手法が豊富・格納データの量と柔軟性、トランザクションに強い書き込みと参照の排他制御技術など、オンライン処理と集計