 |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
デシジョン・メーカ、ビジネス・データとRISQL® |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
背景 変化する状況とさらに激化する競争環境にあって、デシジョン・メーカには絶えず企業の軌道修正が 求められています。的確な意思決定を行うためには、デシジョン・メーカが、ビジネス環境、競合および社内の業務進行状況について正確で意味のある情報を持たなくてはなりません。 ビジネス上必須の意思決定を導き出すために必要な事実の多くは、企業のデータベース管理システム (DBMS)中に存在するわけですが、そのデータ内に潜んでいる情報は、検索するにはコストがかかり過ぎるか、 または単にアクセス不能であるかのいずれかです。 たとえば、企業トップが情報システム(IS)部門から地域別の売上げ明細、セールスマン配置や 製品について報告を求めるのはごく普通のことですが、多くの場合これらのレポートは就業時間外に
作成されなければなりません。 何億というレコード数をもつ企業データベース上で、単純なものから複雑なものまで、 たった一つの検索を実行するだけで、完了までには数分から数時間もの時間がかかってしまい、そのためにコンピュ−ティングおよびネットワーク性能が、かなりの劣化を余儀なくされることになります。 通常、レポートはトータル・データのサブセットに基づいて作成されますが、DBMSはほとんどのレコード内コンテンツをチェックしていくため、
検索の範囲は狭くなります。さらに問題となるのは、企業トップが企業のデータを見ている方法と、 それに基づいてデータベース・プログラマがデータを構成した方法が違うことです。 戦略立案の障害となるもの SQLの長所は、多くのデータベース管理パッケージで使用できること、 それにデータに依存しないことです。すなわち、ユーザはデータへの物理的アクセス方法の 子細を気にする必要はありません。理論上は、SQLはデバイス非依存でもあり、 メインフレーム、ミニコン、パソコンのどのデータベースへのアクセスにも使用可能です。 しかし、短所もあります。 SQLはコンピュ−タ化されたデータベース管理用の業界標準言語ですが、デシジョン・メーカが 通常投げかける多くの問い（質問）を表現するには不向きなため、通常ビジネス分析アプリケーションに使用することはできません。 また、ほとんどのRDBMSは、コンピュ−タ化されたオンライン・トランザクション処理(OLTP)に 最適化されています。OLTPでは、航空会社のフライト予約、ATMトランザクション、販売受発注業務処理など プールされたデータの頻繁な個別変更を追跡処理します。OLTPシステムは日常業務処理を対象に設計されており、 ビジネス上の分析用にデータを供給してくれるものではなく、データにアクセスして分析を行うという企業トップの 新しい行動・機能要件に十分対応できるようなものでもありません。 分析目的でビジネス・データを操作するための、実用的なコスト効率のよい方法に対するデシジョン ・メーカのニーズが引金となって、1991年、IBMは「データ・インフォメーション・アプリケーション」 というツールセットを使用した「データ・インフォメーション」と呼ばれる新しいデータ管理手法を開発しました。 戦略立案の障害を克服 データ・ウェアハウス・アプリケーションは、特に検索処理を念頭において設計されています。 その結果、その作成アーキテクチャは、OLTP用に設計されたシステムより本質的に効率が高く考案されています。
システム内に格納されているデータを利用できること、およびそれを検索する方法が各種存在することが、 戦略立案過程でデシジョン・メーカから信頼される基盤を成しています。 Red Brick Warehouseは、情報システムおよび自社のビジネス管理アプリケーションの品質・ 性能を改良したいと願う企業トップ向けのクライアント/サーバ型データ・ウェアハウス用RDBMSです。
データの抽出ツールが既存のアプリケーションから必要なデータを検索し、整合性を確保するためにそのデータを 「洗浄」し、そして企業デシジョン・メーカが理解・使用可能な形式に変換します。 SQLがあきらめたところからスタートしたRISQL レッドブリックのシステムの中心となるのが、特に企業トップ向けに設計されたRISQL (Red Brick
Intelligent SQL)アーキテクチャです。RISQLはSQLのビジネス分析拡張機能セットであり、 ランク付け、移動平均、比較、市場占有率、今年度／昨年度間比較などデータ分析および意思決定支援
アプリケーションに適した各種の強力な演算または拡張機能でSQLを強化したものです。 SQLクエリーだけでは、意思決定にごくありふれた質問でも投じることができませんから、 しばしばRDBMSデータにアクセスできません。 レッドブリックRISQL拡張機能およびそのビジネス・アプリケーション Cume-カラム内の値のランニング・トータルまたは累計を算出。 例:「各製品の月次売上げと月別当年累計の数字を示せ」 MovingAvg(n)-カレント行とそれ以前のn-1行を使用してカラムの移動平均を算出。 例:「過去2年分の製品売上げの6ヶ月間の移動平均を示せ」 MovingSum(s)-カレント行とそれ以前のn-1行を使用してカラムの移動和を算出。 例:「月別売上とその月までの過去12ヶ月分総売上を示せ」 Rank...When-カラムの値のソートに基づき結果行に連続する数値を割り当てる。 WHEN節を使用した場合は結果を「上位n」または「下位n」に制限する。 例:「昨年度売上げに基づき上位50の顧客をリストせよ。顧客名でリストをソートせよ」 RatioToReport-全行について、カラム合計に対する各行のカラム値の百分率を算出する。 例:「製品種別毎の売上げと販売合計の百分率を示せ」 Tertile-カラムの値に基づき、結果の各行に値「高」「中」「低」を割り付けて3階層のランク付けを実行する。 例:「昨年度分として作成した収益に基づき製品を3グループ分けよ」 Create Macro-普段使用するクエリーまたはサブクエリーのパラメータ化、および 1回の書き込みにより多数ユーザ間での共有を可能にする。 例:「今年度の売上げをリストし、過去5年間の各年度の売上げと比較せよ」 データベースのクエリーに使用されるSQL語彙をRISQL用途に拡張したことにより、 ウェアハウス・システムはビジネスに必須な質問のフレーム化を容易にしています。 結果として、データ・ウェアハウスは、デシジョン・メーカが自社にとって必要なビジネス情報を取得するために 利用可能な、最高速で最も自由度の高い手段となりました。 レッドブリックのデータ・ウェアハウス手法は、オープンな標準ベース環境で動作します。レッドブリック のアプリケーションは明らかに他を上回るクエリー、ロードおよびインデックス性能を発揮し、サポートも管理も容易です。 デシジョン・メーカにとって、RISQLを使用したデータ・ウェアハウスは、豊富なファクト（事実）へ 高速で簡単にアクセスする方法を提供してくれるシステムです。ファクトは整合性を保ち、完全で、 扱いやすく分かりやすい形式で格納されます。オープンな標準環境でデータ・ウェアハウジングが実現されていれば、 複数企業がグループとして、任意のクライアント・ツール、統計パッケージ、ワークステーションやデスクトップ・ システムを使用し独力でデータを検索、分析、フォーマット化することができます。これでユーザは必要なデータの提供を、わざわざ情報システム部門に依頼する必要はなくなります。 RISQLを使用した問題解決例 アロマ・データベース クエリー:「1993年度のサンフランシスコ地区のコロンビア・コーヒーの月別ランニング・トータルは?」 この情報を得るには、RISQLのCUME機能を使用することになります。クエリー1つを実行するだけで複数の都市に ついてランニング・トータルを算出できます。 結果は以下のような表示になるでしょう。
クエリー:「季節変動性を度外視した場合、1993年度のマイアミ地区におけるExpresso XOの販売状況は?」 この結果を求めるには、 RISQLのMOVINGAVG機能を使用します。月次平均は一般に時間経過と共に変動し、大きく変動した場合、 その奥にある長期傾向は見えなくなります。移動平均を出せばこれらの変動を小さくする、緩和する、 または季節変動の影響を除去することができます。 結果は以下のようになります。
クエリー:「1993年の米国のLotta Latteコーヒー月別売上の上位10ヶ月は? 各月に対応する売上量ランクは?」 RISQLでは、RANK機能を使用すれば数値の任意の組み合わせをランク付けし、 次いで関心のあるレコードだけを選択することができます。この例では、データベース内の全コーヒー製品の 売上げをランク付けできるわけですが、上位10、下位10だけを表示することも、検索条件で表現可能な任意の 他の組み合わせで表示することも可能です。 結果は以下のようになります。
クエリー:「1992年第3および第4四半期のサンフランシスコと ロサンゼルスのXalapa Lapaコーヒーの販売で、どの月のシェアが一番大きい?」 月別の数値、移動平均、および年間ランクを見るとき、ある月が1年間の数値の中で占める割合 （分数値）を知る必要があることがよくあります。RISQLのRATIOTOREPORT機能を使用すればこれらの分数値を算出し、 以下のような結果を得ることができます。
クエリー:「1992年第1および第2四半期のサンフランシスコ地区の Aroma Romaのドル単位売上げ金額および売上量のサブトータルは?」 RISQLのORDER BY小節を使用すれば、クエリーのORDER BY節にBREAK BY SUMMING小節を 含めることでコントロール・ブレークが発生するたびにサブトータルをリクエストできます。 下記の例では、1992年第1および第2四半期のサンフランシスコ地区のAroma Roma売上げの四半期毎の サブトータルを算出しています。 このクエリーの解答は以下のようになります。
クエリー:「1993年6月、フェニックスを除く西部都市での個々の製品売上げの互いの比較は?」 通常、表計算フォーマットで数字をDECODE関数またはselectリスト・サブクエリーを使って比較する必要が生じます。 DECODE関数で表示された各カラムを下記の情報で定義しなければなりません。
このクエリー例では、フェニックスを除く全西部都市での全コーヒー製品の売上げを表示しています。
クエリー:「1993年のどの月においてサンフランシスコ地区の Lotta Latte売上げが1992年の同地区での平均月次売上げを下回ったか?」 サブクエリーとは、別のクエリー内で発生するクエリーで、あるテーブルから、 別のテーブルで得た情報に基づいて情報を検索可能です。この例では、
1993年の月別売上げだけを検索しており、それを1992年の売上げ平均と比較しています。 以下に1992年平均に対するサブクエリーを示します。
クエリー:「1992年6月のサンフランシスコ地区のコーヒー売上げは、1993年売上げと比較してどうか?」 多くの場合、クエリーは基本命令ブロックにマイナーな変更を加えてそれを数回繰り返して使用します。 これらのバリエーションは都合の良いパラメータ候補になります。たとえば、当年のコーヒー売上げと 前年とを比較するクエリーには、類似した2つの命令ブロックが含まれます。その1つは当年の売上げを検索し、 もう1つは前年分を検索します。「年」のパラメータを含むマクロは、手動で入力しなければならない命令数を 減らしてくれます。 この例では、親クエリーが1992年6月の月別コーヒー製品売上げを検索し、マクロにより1993年の対応部分を取得します。
自由度・信頼性の高いデータ・ハンドリング 貴社のアプリケーションおよびニーズが、ここに示したものと類似したものであれ、 もっと複雑なものであれ、RISQLの柔軟性と信頼性は実証されており、 貴社が信頼し確信をもって使用できる情報を、必ず入手可能にするでしょう。
|
