エンジニア募集
これまで、一人ですべてをやってきましたが、
プロジェクト現場を見ていると、「チーム」「職人集団」の必要性を強く感じるようになりました。
Business Intelligence,Big Data,情報系といった領域は、
Web系や基幹系といったシステムとは異なる技術志向が必要になります。
すべてをデータ・データベースを中心に考える必要があり、なおかつ、
各社のBIツールは、背景とする「システムモデル」に則して作られているので、
「システムモデル」を理解して設計・製造を行う必要があります。
しかし、最近のプロジェクトでは、この「システムモデル」や「データモデル」といった
技術というより「理論」を理解していないSIerやソフトハウスが受注しているケースが多く、途中から参画すると「これじゃぁダメだ」という場合が見受けられます。
逆に言うと、「システムモデル」や「データモデル」を理解してプロジェクトを進めれば、かなりの低工数で高度・大規模なシステムも組み上げることができます。
つまり、「職人集団」（BIのプロ集団）が開発に携われば、高い生産性を実現できるのです。
募集といっても、自社はバーチャルオフィスで、あちこちの顧客オフィスを
渡り歩いている当社ですので、「社員募集」というより「職人募集」または、経験が浅ければ「弟子募集」と考えていただください。
バーチャルオフィスの凄く”怪しい”会社ですが、「正社員」を希望される方であれば、弊社社員として採用します。
「フリー」で仕事をされている方であれば、弊社パートナーとしてお仕事をしていただきたいです。
（本音としては、「フリー」の方とゆるーい結びつきの「職人集団」が理想なんですけどね。）
興味があれば< kayano@infospire.co.jp >までご連絡ください。
【勤務地】中心は、品川・目黒・田町近辺の弊社緊密お取引先オフィス
【待遇】応相談 （最初はあまり期待しないでください。学んでいただきたいので。）
【条件】基本週休二日
分析ニーズと定型ニーズ
BIの提案・構築へのコンサルティングをしていて、ちょっと説明した内容を
備忘録的に書いておこうかと思います。
BIの利用・活用では、大きく分けて３つの用途を意識的に分けて考える方が、
システム全体の構成がうまくまとまります。
ひとつ目は、定型分析
ふたつ目が、自由分析
最後には、業務との連携
定型分析
これは、経理財務でいうところの、制度会計帳票＝損益計算書と貸借対照表を
思い描いてもらえればいいと思います。
一般的に経理をある程度わかっているという程度の人（部門の長や経営TOPなど）は、
『自分の管轄している組織は、儲かってるのか・損してるのか』
『経費は適切に使われているか』
といった課題に対して、損益計算書と貸借対照表といった定型の帳票（集計）で把握します。
問題点があれば、これを伝票レベルまで掘り下げて、
『どの取引が問題の原因か』
を突き止めようとします。
これは、
☆☆決まったレポートで全体を俯瞰する☆☆
☆☆定型的な分析ルートで原因を調査する☆☆
というプロセスになります。
このように「決まったレポート」「定型的な分析ルート」を実現するニーズが定型分析ニーズです。
自由分析
制度会計帳票に対して、キャッシュフロー（一般的なCFはすでに定型化されていますが）などは、
定型的な分析ではなく、制度会計のいくつかの科目を、独自の計算式で割り出して計算します。
一般的なCFでは、含めるルールとなっている科目であっても、会社の特性として
含めるべきではないと判断できれば、含めないで計算したくなります。
このように『データの内容を熟知している人』が、『全体の中から、都度、目的・意図・思考を持ってデータを集計する』という業務が、自由分析です。
これは、
☆☆目的を持ってデータ集計ルールを考える☆☆
☆☆集計されたデータから問題点や特異点を見つけ出す☆☆
☆☆問題点・特異点に対して様々な角度から原因の仮説を立てる☆☆
☆☆立てた仮説を検証するために新たなデータ集計ルールを考える☆☆
といったプロセスとなります。
業務との連携
分析のニーズは、BIシステムに閉じた世界の話です。
しかし、分析により得られるデータは、別のシステムや業務にフィードバックされて
初めてその価値が発生します。
予算を立てても、それを眺めているだけでは、『とらぬ狸の皮算用』であって意味がありません。
予算を達成するために頑張る人（営業担当や店長さんたち）に提示して、その予算を目標に
努力してもらって、初めて意味が出てきます。
業務活動で、必要となる情報を適切に提供するニーズが業務との連携ニーズです。
システムへのニーズをこの３つの観点で整理し、それぞれをどのような形で実装・提供していくかという
システム（思想）設計を最初に検討しておくことは、BI成功へのひとつの秘訣といえます。
SQLServerBIでの設計を考えると
定型分析ニーズには・・・ReportingServicesが最適
自由分析ニーズには・・・AnalysisServicesが最適
業務との連携は・・・ReportingServicesが最適だが、自動化は決して得意ではない
という特徴があります。
このニーズを見誤ると・・・
ニーズは自由分析なのに、ReportingServicesだけでやろうとすると・・・
何とか別ごとに数十〜数百もの似たようなレポートを作成することになります
ニーズは定型分析なのにAnalysisServicesを使おうとすると・・・
細かな、（下手をすると各レポートごとの）キューブが量産されて、工数も嵩みますし、
統合された情報活用が阻害されることになります。
最初のニーズを、（ユーザーの意見を鵜呑みにせず）見極めて、ニーズを整理しましょう。
ではでは
SQLServer2012をいじってみた
今頃かい！！
という突っ込みをものともせず、リリース後、今更のように2012をいじってみました。
どう変わっているのか。。。BIって視点で。。。
結論をいうと、「既存機能はあまり変わっていない」です。
大きく違うのは
- SSASにTablerモードがついた
- SharePointからの利用に、PowerViewが追加された
という２点です。
このうち、PowerViewは、SharePoint統合でのレポーティングなので
個人的には興味がありません。
大事なのは、SSASのTablerモードです。
SSASのTablerモードについては、別エントリで紹介する予定ですが、
特徴としては
従来のSSASのように厄介なキューブデザインがいらない。
従来のDatabase（DWH)と比べて、BI特化での検索性能（集計速度）が段違いに速い
というもので、従来のSSASとDWHの中間的なDBエンジンです。
個人的見解ですが、
製品としては、ClickViewなどのお手軽なんちゃってOLAP製品や
Neteeza・SybaseIQのようなBI特化型DBエンジンへの対抗製品と言えるでしょう。
まぁ。。。
Tablerモードは、SQLServerファミリーにとって、まだまだ出たばかりで統合への
道の途中といったもので、実用するかは要検討といったものですね。
ただ、MSとしてはSSASは難しすぎて普及しにくいから、Tablerにシフトしていくのかも
しれません。
M-OLAP・キューブという観点からは「後退」とおもえるけど。
ではでは。
準加法メジャー 在庫残とか（LastNonEmpty)
キューブに作成するメジャーは、通常はすべてのディメンジョンに対して、「加法」で集計されます。
私がこれまでぶつかってきた案件（DB）でもほとんどは「加法」です。
では、加法にならないメジャーを考えましょう。
例えば、平均単価とか、ｘｘ率とかはどうなのでしょう。
こういった値は通常、「積み上げて計算する値ではない」ものです。
積み上げた値を使って計算するものです。
「積み上げて計算する値ではない」値は、「計算されるメンバー」を使って定義します。
損益計算書や貸借対照表の金額はどうでしょう。
売上100万 返品20万 純売上80万 経費50万 経常利益30万
などと、単純合算にはなりません。
科目と集計科目の関係については後日エントリーを上げるとして、
ここでは経理・財務系での扱い方を考えます。
経理・財務を扱ったことのある方ならわかると思いますが、
【借方】【貸方】のプラスマイナスをひっくり返して縦持ちさせるのが一般的です。
詳しくは、これも別エントリーにて。。。
ということで、結論だけ言うと
この金額も「加法」で定義して積み上げた数値の表示時に、借方・貸方を判定してプラスマイナスを調整する「計算されるメンバー」で対応できます。
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
特殊と言えるのが【在庫残】や【受注残】といった「残データ」です。
これらは、商品とか在庫場所など普通のディメンジョンに対しては「加法」でいいのですが、年月日（時間ディメンジョン）に対してだけは「加法」を使ってはいけません。
この、特定ディメンジョンにだけ集計方法が違うというメジャーに対応する機能が【準加法メジャー】です。
はっきり言って、実際のビジネスケースとしては、これで十分です。
例外が出てくることもあるかもしれませんが。
【準加法メジャー】とおおげさに言っていますが、設定はメジャー項目の集計方法を選択するだけです。
集計方法で、「First Child」「FirstNonEmpty」「Last Child」「LastNonEmpty」そして「ByAccount」を選択すると、準加法となります。
【参照】
http://technet.microsoft.com/ja-jp/library/ms175356(SQL.90).aspx
特に「残」で使うのが
- LastChild
- LastNonEmpty
です。この２つでは扱いに注意が必要です。・・・やっと今日の本題
・・・ByAccountは別の機会に・・・
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
LastChildは、時間ディメンジョンの最後の「子」の値が採用されます。
つまり２０１２年の値は２０１２年１２月の値が採用されます。
値がなくてもです。
２０１２年の在庫残が、１月、２月・・・と登録され１１月まで登録されていても、「２０１２年１２月」はデータがないので、２０１２年の残は「なし」となります。
これでは困るので、値がある月までの数字をとるのがLastNonEmptyです。
これは、値がなければ子を遡っていって、見つかった値をとります。
前記例では、２０１２年１２月は値がないので１１月分が２０１２年残となります。
ところが・・・
LastNonEmptyも、別のディメンジョンをドリルダウンすると問題が生じます。
Ａ商品は、１０月残５個 １１月残 なし
Ｂ商品は、１０月残３個 １１月残 ４個
とすると、全体の１１月残は 「４個」になります。
しかし、
Ａ商品の残は、（１１月データがないので、１０月が選択され）５個
Ｂ商品の残は、４個
と、合計と明細が合わなくなります。
これを回避するには、Ａ商品の１１月残をなし(NULL)ではなく、１１月残０個
としなければなりません。
（１２月もなければ、１１月残０個が選択されればいいので、１２月残なしで構いません）
残データは、時点データなのでデータ量が膨らみがちです。
このためＤＢでは、「データなし」のレコードは登録しないケースが多いのですが、レコードがない（なし）はこのような弊害があるため、０になった時だけでも明確に０と登録する必要があるんですね。
ではでは。
（ブログは向かない・・・怠惰なオイラ）計算されるメンバー MSDNネタ
思い立った時が、書くとき。。。おいらの基本方針としよう。
SSASは、自動で事前集計データを内部で保持してくれるから、集計検索が高速におこなえる。
RelationalDatabaseは、クエリ発行時に集計操作を行うので、これほど高速にはならない。
でも、スタンダードな使い方ではないケースも出てくるわな。そりゃ。
で今回MSDNに出ていた質問が、「メジャーについて、全体集計が表示されなくしたい」という特異なケース。
【数量は「全組織合計」を出したいけど、金額は「全組織合計」を空欄にしたい】
というご要望でした。（金額・数量ではそんなことはレアなんだけど、例として）
こういう時に使えるのが、「計算されるメンバー」です。
MDXの式を定義しておくことで、出力される値を制御できます。
今回の要望だと
CASE WHEN [«dimension»].[«Hierarchy»].CurrentMember IS [«dimension»].[«Hierarchy»].[All]
THEN Null
ELSE [Measures].[«Target Measure»]
END
てな感じの式で 実現できます。
MDX式は、取り付きにくいし、解説本もレアだというのが難点ですが、
製品のヘルプ（MSのサイト）がよくできているので、挑戦してみる価値はあります。
メジャーのNULLと０の扱い。 『書きかけ』
今日は、キューブの話です。
またもや、プチはまったので、備忘録として。
ＤＷＨ（データベース）時点で、データをサマリテーブルとして保持している場合、
メジャーの値がNULLとなることがあります。
例えば、
日付・取引先をキーに、「売上」「値引」を持たせたテーブルとする場合
などです。
このようなテーブルでは、値引きをしなかった取引については、「値引」を０とする持ち方とNULLとする持ち方ができます。
どっちがいいのだろうか？というのが今回の命題です。
ケース想定として、ある日にＡ、Ｂ、Ｃの３社と取引があり、うちＡ、Ｂ２社にだけ値引きをしたとします。その日に取引のないＤ社というのもあるとします。
その日をフィルタし、縦軸に取引先を並べ、横に値引だけを表示したとき、
＜ケース１＞全取引先が出てほしい
取引先 値引
Ａ社 50,000
Ｂ社 30,000
Ｃ社 0
Ｄ社 0
＜ケース２＞取引のあった取引先だけ出てほしい
取引先 値引
Ａ社 50,000
Ｂ社 30,000
Ｃ社 0
＜ケース３＞値引きのあった取引先だけ出てほしい
取引先 値引
Ａ社 50,000
Ｂ社 30,000
と３つのニーズが想定できます。
【ここからは、書きかけメモ】
今回はまったのは、ケース３にするニーズへの対応です。
ＥＸＣＥＬ上で０をフィルタしてもらうという方法もありますが、
複雑になってくると、そうも言ってられません。
で、ＤＢ上「データをNull」にしました。
しかし、キューブでは、C社が0となってしまうのです。
なんでだーーーーー！
で、ポイント
「キューブのメジャー」のプロパティで、
NullProcessingが「Automatic」になっているのが悪かった。
このせいで、Nullを０とみなされていた様だ。
「Preserve」 に変えて対応できた。
正確な挙動と、Automatiのときのデフォルト動作の精査ができていないので「書きかけ」だわなまだ。
でも、完成しないかもしんない。。。弱気なおいら。（笑
メジャーのNULLと０の扱い。 『書きかけ』
今日は、キューブの話です。
またもや、プチはまったので、備忘録として。
ＤＷＨ（データベース）時点で、データをサマリテーブルとして保持している場合、
メジャーの値がNULLとなることがあります。
例えば、
日付・取引先をキーに、「売上」「値引」を持たせたテーブルとする場合
などです。
このようなテーブルでは、値引きをしなかった取引については、「値引」を０とする持ち方とNULLとする持ち方ができます。
どっちがいいのだろうか？というのが今回の命題です。
ケース想定として、ある日にＡ、Ｂ、Ｃの３社と取引があり、うちＡ、Ｂ２社にだけ値引きをしたとします。その日に取引のないＤ社というのもあるとします。
その日をフィルタし、縦軸に取引先を並べ、横に値引だけを表示したとき、
＜ケース１＞全取引先が出てほしい
取引先 値引
Ａ社 50,000
Ｂ社 30,000
Ｃ社 0
Ｄ社 0
＜ケース２＞取引のあった取引先だけ出てほしい
取引先 値引
Ａ社 50,000
Ｂ社 30,000
Ｃ社 0
＜ケース３＞値引きのあった取引先だけ出てほしい
取引先 値引
Ａ社 50,000
Ｂ社 30,000
と３つのニーズが想定できます。
【ここからは、書きかけメモ】
今回はまったのは、ケース３にするニーズへの対応です。
ＥＸＣＥＬ上で０をフィルタしてもらうという方法もありますが、
複雑になってくると、そうも言ってられません。
で、ＤＢ上「データをNull」にしました。
しかし、キューブでは、C社が0となってしまうのです。
なんでだーーーーー！
で、ポイント
「キューブのメジャー」のプロパティで、
NullProcessingが「Automatic」になっているのが悪かった。
このせいで、Nullを０とみなされていた様だ。
「Preserve」 に変えて対応できた。
正確な挙動と、Automatiのときのデフォルト動作の精査ができていないので「書きかけ」とします。
