CodeZine(コードジン)

特集ページ一覧

Oracle with FileMaker:BIツールとしての可能性

Oracle使いが語る、FileMakerを利用した新たなソリューションの可能性 (3)

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2007/12/21 20:22

目次

現場担当者によるデータの加工/分析

 次に、そもそもの本題であった自分が必要とするデータはエンドユーザーに任せよう(ただし、データの管理はDBAが行ってください)という話に近づけましょう。

 前回のようなテキスト在庫管理は、担当者レベルで管理項目を考え、FileMaker上のテーブルとして管理すればよいであろうという見解を示しましたが、今回は、データソースはOracleにありつつ、そのデータの見方や必要とする項目がユーザーによって異なるという場合を考えてみたいと思います。

極端な値の抽出

 まずは、シンプルなことからはじめましょう。データ分析するときに、しきい値を超えたものを特出させるという方法があります。例えば、極端に多い値や少ない値です。もし、それが商品の注文個数であれば、よく売れている商品、あまり売れてない商品を見つける手がかりになるかもしれません。

 そこで、しきい値を決め、それ以上であればフィールドを「青」にし、逆に極端に少ないものは「赤」にするという設定をして見ましょう。もちろん、エンドユーザーに行ってもらうわけですから、プログラムは書きません。プロパティの設定で行います。

図6 
図6 

 数量(QUANTUTY)フィールドの「条件付書式」から、値が150より大きければ(値>150)、フィールドを「青」、値が40より小さければ(値<40)、フィールドを「赤」にするという設定をしました。

図7 
図7 

データの集計と分析

 商品番号:2289は売れ行き好調のようですが、2274、2276、2278はあまり数量が出ていません。2274、2276は販売価格(UNIT_PRICE)が高いことが要因かもしれません。しかし、2278は2289と価格はほぼ同じなのに、受注数量は少ないことが気になります。売れない理由を分析してみる必要があるでしょう

 ここでは個々の明細行に対して受注数量の多いもの、少ないものに注意を促すためにしきい値を超えた行に対して色を付けて表示させましたが、データの分析と言えば、合計値や平均値、最小値、最大値を求めることが多いでしょう。SQL文ではGROUP BY句を用いて行の集約処理が必要です。次の画面のように商品番号ごとに受注数量の小計を求めてみましょう。

図8 商品番号ごとの数量合計
図8 商品番号ごとの数量合計

 そのためには、先に集計フィールドを定義しておきます。商品(PRODUCT_ID)ごとの数量(QUANTUTY)合計をSUM_QTYと名づけました。

図9 
図9 

 次に、[レイアウト]-[新規レイアウト/レポート]から、[表レイアウト/レポート]を選択します。「集計レポート」レイアウトを選び、区分けフィールドを指定します。この区分けフィールドがSQL文で言うところのGROUP BY句で指定する集約列と思えばよいでしょう。

図10 
図10 

 小計は、先ほど定義したSUM_QTY列を使用します。

図11 
図11 

 SQL文で集約処理を行いたい場合、SELECT句にはグループ関数(SUM、AVGなど)またはGROUP BY句で指定した列で無ければならないなどのルールがあるため、欲しいデータを表示することが難しいことが多いものです。「図8 商品番号ごとの数量合計」のような表示結果をSQL文で求めることは実は難しいのです。

 このように求めた、分析用のデータは、EXCELに落としたいのが一般的なユーザーのニーズでしょう。FileMakerの[ファイル]メニューには、[レコードの保存/送信]があります。求めた結果をそのままEXCEL、またはPDFファイルに変換するメニューです。

 分析用のリポジトリを作る必要があるなら、FileMakerのテーブルをその目的に使えばよいでしょう。エクスポートしたファイルからでも、あるいは前回お話したようにODBC経由でOracleから直接インポートしても良いでしょう。

FileMakerのBIツールとしての可能性

 これで、データウェアハウス並みにデータ分析ができたというのは、おこがましいですが、とっかかりとしては、このようなところから始めていけばよいのだと思います。

 BIを導入しようと考えていても、基幹系システムから、いかにクリーンなデータを抽出・変換・ロードするかに悩んでいることが多いものです。また必要なデータが網羅されているかを考慮し、見せ方についても配慮した開発は、重要ではあるけれど手間のかかるところでしょう。

 「まずは、分析用のリポジトリの設計から」と意気込まずに、ユーザー手動でデータを起こしてみて、要求がどんどん複雑になればそこからリポジトリの構築を検討するというアプローチでも良いのではないか、と感じます。そうしないとBIは導入したいけれど、どう始めたらよいかわからないというままで終わってしまうこともありえます。

 とりあえずユーザー主導で始めた資産だとしても、壊して作り直すのでは、もったいないので、エンドユーザーでも使えて、その後本格的な開発もできるデータベース、そして、OS上のファイルや他のリレーショナルデータベースと連携できるFileMakerは、発想しだいではBIツールとして拡張性のある使い方ができるのではないかと考えます。



  • LINEで送る
  • このエントリーをはてなブックマークに追加

あなたにオススメ

著者プロフィール

  • 林 優子(ハヤシ ユウコ)

    日本オラクル株式会社の教育ビジネスのスタートアップを全面的に支援し、バージョン5の頃からOracleに携わるベテラン講師として知る人も多い。Oracle認定講師を表彰するExcellent Instructorを連続受賞。1ランク上のITスペシャリスト育成を目標に、データベース分野にとどまらず「プレ...

バックナンバー

連載:Oracle使いが語る、FileMakerを利用した新たなソリューションの可能性
All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5