2015年10月25日

IoTなんて流行らない

たまにはIT絡みのエントリを。
たまには挑発的なエントリを。

IoT(モノのインターネット)や
インダストリー4.0というキーワードが
世間では話題になっているようですが、
早々に廃れていくことになると思います。
最近聞かなくなったビッグデータと同じで、
言葉自体がソリューションでは無いからです。

IoT、インダストリー4.0、ビッグデータ、
これらの言葉は全てデータを集めることに
関連しています。でも、いくらデータを集める
努力をしても、それを使いこなせないのであれば、
リソースの無駄遣いでしかありません。

ビジネスはデータから始まるのではありません。
きちんとしたビジネスの設計図があって、
その肉付けを行うためにデータを集めるのです。
主客逆転してはお話になりません。

例えばFacebookは、精度の高い広告を打つという
ソリューションを高く販売できることが
見えていたため、その土台となる個人情報を
集めることに邁進し、業績も好調です。
逆にTwitterは、一日に膨大なテキストデータが
投稿されるものの、それをお金に変えるための
ソリューションの設計が甘く、赤字に苦しんでいます。

上記を踏まえると、経営者が先ず取り組むべきは、
自分が何をしたいのか、何が社会にインパクトを
与えるのかという洞察ではないでしょうか。
その次が、攻め入りたいマーケットに届く
メッセージを考えることであり、これらが整わずに
データを集めても、恐らく只の徒労と終わります。

だから、嫌なんですよね。
無責任な人たちがIoTだインダストリー4.0だと
騒ぎ立てるのは。もっと本質的なところに
目を当てるようにしないと、日本の競争力は
どんどん蝕まれてしまうような気がします。
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2014年11月16日

ムーアの法則の舞台裏

久々に技術者モードでClubDB2に行ってきました。
テーマはテープデバイスの技術的な話。
テープはお客様の環境で触らせて貰ったことが
一度だけあるんですが、全然知識が無かったので
扱うのが怖かった思い出があり、機会があれば
勉強しないといけないなと考えていました。

追記ベースのシーケンシャルアクセスに特化した
ストレージであり、ブロックサイズが大きいほど
転送速度が良いというのはイメージ通りでした。
しかし、テープの長さが800mもあって、
8m/sでアクセスが行われているとか、
一本のテープをY軸に60分割して記憶域を
稼いでいるため、容量をフルに使ったときは
テープが60往復しているというのは驚きでした。

ドライブが高いのはネックですが、
カートリッジを20本以上使うような用途であれば、
HDDよりも容量あたり単価は安くなるそうです。
また、HDDと違って駆動装置と記憶域が
分離しているので、衝撃に強かったり、
保管が便利というのも大きなメリットとなります。

と、技術的な話をサクっとまとめてみましたが、
実は僕が最も感動したのはマインドの話でした。
「コンピュータの性能は一年半に倍になる」という
ムーアの法則なる経験則がIT業界にはあるのですが、
テープ一本当たりの容量も概ね当てはまっていたので、
この傾向は将来も成り立つのかと質問したところ、
以下のような答えが返ってきました。

「成り立つ成り立たないではなく、成り立たせる」

おおおっ、これがIT革命を生み出してきた
本物の技術者の心意気なのですね!
つまり、結果は後から付いてきたのです。
まずは理想を強くイメージし、そこから逆算で
アプローチを組み立てたということなのです。
…オッサンも大志を抱くべしってことだなあ。
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2012年11月10日

オプティマイザの功罪

いや、ぶっちゃけ功の方が遥かに大きいんですが、
罪にフォーカスした勉強会に行ってきたわけです。
はい、いつものClubDB2です。内容濃かったです。

インデックスに余分な列が入っていたことにより
マッチングスキャンがレンジスキャンになった事例や、
データ移行後に統計情報を取ったところ
新業務で使う列に値が入っていなくて
インデックスが無視されちゃった事例や、
新しく入ってきた月またぎのデータが
レアデータと判断されて月が検索用の
インデックスとして使われてしまった事例や、
先頭100行しか取らないで良いSQLなのに
裏では全件取得が走っていた事例が紹介され、
データベース屋としては心温まる二時間でした。

オプティマイザが判断ミスを犯して
クエリが遅くなってしまった場合、
表側からは理由が分かり辛いので厄介ですよね。
ここらへん、まだまだデータベース屋は
アプライアンスに駆逐されないぞと安心しましたw

あと、今IBMって三種類も分散DBを持ってるんですね。
OLAP用のNetezza(DWHアプライアンス)、
OTLP用のPureScale(シェアードディスク)、
両方ともイケるPureData(シェアードナッシング)
といった具合で、さすが巨人と呻ってしまいました。
…こういう製品を提案できるくらい偉くなりたいなあ。
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2012年07月14日

こんなESB設計は嫌だ

「達人が語る こんなデータベース設計は嫌だ!」に
参加したので、感想をまとめようと思ったのですが、
出遅れて書くことが無くなってしまったので、
「変人が語る こんなEssbase設計は嫌だ!」という
誰得なエントリでお茶を濁してみることにします。

<Essbaseサーバとサイジング>
「そもそもサイジングできない奴、一歩前に出ろ」
-----------------------------------------------------------
せめて次元数とメンバ数でサイジングをしてから
プロジェクトの規模やハードウエアの見積って欲しいですね。
開発着手の前に既にPJTが崩壊してるとか泣きたくなる(死
 →参考01

<Essbaseの性能はスケールするか>
「EssbaseはRDBに比べスケールアウトが困難」
-----------------------------------------------------------
Essbaseはシェアード・エブリシング型のアーキテクチャで、
最近になってHA構成が辛うじて可能になった程度です。
しかも制限が多い。シングルインスタンス構成で
ディスクをパーティショニングくらいが限界かも(汗
ここらへんが改善されると、個人的には夢が広がります。
 →参考02
 →参考03
 →参考04

<ストレージネックを解消しましょう>
「とは言ってもEssbase側で可能なことは少ない」
-----------------------------------------------------------
先述のパーティショニングや、ディスクボリュームの
割り当てを分散させるくらいしかできないので、
頼むからRAIDで早いストレージを入れてください(泣
 →参考05

<オンメモリの時代>
「やっぱりディスクに触ったら負けかなと思ってる」
-----------------------------------------------------------
計算キャッシュ、インデックスキャッシュ、
データファイルキャッシュ、データキャッシュ
(直接入出力がONのときのみ有効)と
ディスクに触らせない諸々の設定があるのに、
メモリをケチって失敗するとか問題外。
 →参考06

<32bit OSはオワコン>
「64bit OSでもオワコンなケースに注意」
-----------------------------------------------------------
MEMSCALINGFACTORという、4GB以上のメモリを
キャッシュに設定できるオプションがあったのですが、
とあるバージョンでは設定が効かないというバグがあり、
64bit OSでもメモリを4GBまでしか使えないという
悲しい事態が発生したことがあります(吐血
最新のEssbase 11.1.2.2ではオプション自体が廃止されて、
最初からメモリを潤沢に使えるようになった模様。
 →参考07
 →参考08

<手続き型の呪い>
「手続き型でロジックが書けたら苦労しない」
-----------------------------------------------------------
EssbaseのDSLは手続き型のロジックを(基本的に)
記述できません。なので、ピヨピヨじゃないエンジニアも
開発現場で頻繁に爆死します。しかも、次元の疎密
(≒インデックスとエクステント)の違いと計算方法の
相性を理解したうえでロジックを記述できないと
パフォーマンスが劇的に劣化するので、
開発をクリアできてもシステムテストで爆死します。
というか、基本的に皆揃って爆死します。
ここでのアドバイスとしては、メンバ式的にロジックを
実装すると逃げ道があるとだけ言っておきます。
 →参考09

<Essbaseはガツンと一発で操作>
「常に必要なブロックを一度に操作する意識を持つ」
-----------------------------------------------------------
計算スクリプトはロジックを逐次で記述する形式に
なっていますが、逐次実行の数が増えるとパフォーマンスは
当然悪化します。データの並列処理に強いという特性を
活かせなければ、Essbaseを導入する意味など無いに等しい
ということを、某社の営業も知って欲しいと思います。

<Essbaseはテーブルじゃねえんだよ>
「人は何故データベースといえばRDBと考えるのか」
-----------------------------------------------------------
EssbaseはRDBと違い、データが丸ごと一つのファイルに
格納されていて、@XWRITE関数と@XREF関数が使える
場合を除いて、データ連携はエクスポートとインポートで
行わなくちゃいけない作りになっています。
なので、無駄な部分にアクセスさせずにロジックを
記述しないと、膨大なアクセス待ちが発生して死にます。
言い方を変えると、FIXステートメント超重要。
更新フラグの付いた部分だけを計算対象にする
高機能計算は、計算バグの元凶となるのでOFFを推奨。
 →参考10
 →参考11
 →参考12
 →参考13
 →参考14

<Essbase技術者からの反論>
「でもさ、Essbaseには利点もあるんじゃないの?」
-----------------------------------------------------------
この意見には一理ある。オプティマイザが存在しない
Essbaseでは計算処理のパフォーマンスに揺れが無い。
ただ、パフォーマンスを考えられる技術者は極めて少ない。
(僕を月300万以上で雇って貰えるならOKだけど。)
というか、Essbaseは更新系の処理をさせるのに
向いたアーキテクチャじゃないような…。
(OLAP用のDBなんで、OLAP用に使っていただきたく。)

<垂直分割と水平分割>
「理論と実践のトレードオフ」
-----------------------------------------------------------
現場レベルにおいて、垂直分割と水平分割を
提案できるエンジニアは一人もいない。
(ソース:@Bizuayeuの経験)

<物理の犠牲になる論理>
「物理と論理が喧嘩すると、物理が勝つ」
-----------------------------------------------------------
しかし、物理側が問題を解決できるわけでもないので、
最終的にプロジェクトそのものが犠牲になる。

<アウトラインはいつ崩すべきか>
「アウトラインの変更は手戻りのコストが大きい」
-----------------------------------------------------------
性能が出る出ない以前にアウトライン(≒マスタ)を
変更しないとデータそのものが入らないというのが
Essbaseのデータモデルなので、仕方ないね。
だからプロトタイプのフェーズが必須と小一時間(略

<Essbaseの理想と現実>
「Essbaseエンジニアはどこまで物理を意識するべきか?」
-----------------------------------------------------------
ぶっちゃけ物理を意識できないエンジニアは
Essbaseでは役に立たんのですよ。
それがEssbaseの最大の弱点だと真面目に思う。
残念ながら物理に至れるエンジニアが少ない現状、
ベンダーの甘言に乗ってEssbaseを導入するのは
相当なリスクじゃないかな。20年以上前から
OLAP用途には愛されている=アーキテクチャ自身は
優れているという証拠で、キチンと使えたときの
パフォーマンスは素晴らしいし、知れば知るほど
洗練された作りになっていると僕も感じるので、
非常に寂しいのだけどね。
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2012年06月23日

遂に基礎知識になった

現金なもので、これからもITのスキルを
自分の強みとして活かせることが分かると、
勉強にモチベーションが湧いてきますw
ということで、今日はこんな本を読んでみました。

<NOSQLの基礎知識>


ビッグデータはクラウドの次のバズワードと
なっているようで、最近は大きなSIerも
盛んに喧伝をしているようなのですが、
その技術的基盤であるNOSQLについては
ピンと来ない方も多かったのではないでしょうか。

そこに真っ向勝負を挑んでいるのが紹介の本で、
NOSQLのデータモデル、アーキテクチャの基本概念、
NOSQL-DBMSの類型と代表製品の紹介、性能評価、
ユーザ事例などが平易にまとめられています。

しかも、平易なだけでなく、
ところどころ切れ味も鋭いです。
「HadoopはNOSQL-DBMSじゃない」とか、
「現時点で最初に検討すべきNOSQL-DBMSは
CassandraとHBaseだ」など、実際に数々の
NOSQL-DBMSを比較検討し、システム開発に
適用している著者たちにしか書けない言葉は、
それだけで2520円以上の価値があるでしょう。

こういう分かり易い基礎知識の本が出てくれると、
真面目にビッグデータの提案ができる雰囲気が
いよいよ形作られていくのかなと思いますね。
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2012年06月02日

Essbaseで突き抜ける

なんかEssbaseに関しては、
我ながら一歩突き抜けた感じがするので、
ちょっと自慢がてらに計算部分のTipsについて
少しまとめちゃおうかなと思います。

<ドライバは配列に入れて計算すべし>
通貨換算なんかはパフォーマンスが出ない計算の
典型例だったりしますが、これは違うブロックに
格納されているレートを取りにいくための
コストの大きさが主な要因と言えます。
しかし、必ずメモリに配置される配列を宣言し、
そこに事前にレートを入れてしまえば、
改めてブロックを舐める必要がなくなります。

<データブロックを@XWRITEで作る>
等式によるブロックの生成をONにすると
パフォーマンスの面で色々と終わりますし、
かといって事前にブロックが存在しないと
計算が行われないというお約束のせいで、
ワリと困ることがしばしばあります。
そんなときはDATACOPYで何とかするんですが、
込み入った状況になると関数を組み合わせられない
DATACOPYでは実装の限界が出てきちゃいます。
そうなると、@XWRITEの出番です。
@XWRITE(SOURCE,@LOOPBACK,TARGET)で、
同一キューブ内にブロックを書き込めます。

<配賦するなら@ALLOCATEや@MDALLOCATE>
慣れないと使い方が難しく見える配賦関数ですが、
これを使わないと計算式がダラダラ続くことになり
全く配賦のパフォーマンスが出ないので、
Essbaseでマトモなシステムを組みたいのなら
頑張って使い方を覚えましょう。
ただし、きちんと直接入出力を有効にして、
インデックスキャッシュ、データキャッシュ、
データファイルキャッシュ、計算キャッシュを
潤沢に設定しないと期待する効果は出ないかもです。

…しかし、このエントリ誰得(汗
posted by ビズアイユ at 00:00 | Comment(2) | TrackBack(0) | 備忘録@IT

2012年04月28日

新機能にワクワクする

商用のデータベースの中で、
僕が初めて触ったのがIBM DB2でした。
その頃はまだバージョン7で、
UDB(Universal DataBase)なんて
製品名で売られていました。

で、10年あまり経った今、
遂にバージョンが二桁の大台に乗りました。
DB2 10が4月30日に出荷開始となります。
それに先駆けて、v10の新機能紹介が
ClubDB2DB2の勉強会)で行われたので、
そのときの内容を列記してみようと思います。

-----------------------------------------------------------
1. GUIツールのコントロールセンターが
お亡くなりになり、GUIを使いたいなら
Optim Data Studioというツールを
別途ダウンロードすることになった。

2. テーブル圧縮とページ圧縮の併せ技
(アダプティブ圧縮)でデータの圧縮率が
更に上がったり、オプティマイザが賢くなって
DISTINCTやGROUP BYやJOINが早くなったり、
インデックスが今まで以上に使われて
I/Oが削減されたり、動的にパラレルクエリが
可能になったり、Hadoopと連携できる関数が
加わったりで、大量データ対応へのコストが
色々と下がった模様。

3. ストレージグループという概念が追加になり、
表スペースに紐付くストレージを動的に
変更できるようになった。新しくて参照頻度の
高い表を持つ表スペースは早いディスクで
構成されたストレージグループに配置し、
参照頻度が落ち着いたら遅いディスクで構成された
ストレージグループに移すという運用がオススメ。

4. HADRやpureScaleといったクラスタ系の機能が
高価でないエディションでも使えるようになり、
災害対策やスケールアウトがより身近になった。
(HADRではMySQLのシャーディングっぽいことも可能。
参照対象にするとライセンス料が発生するけど。)

5. データの履歴管理ができる時系列DBの機能が
全エディション共通で追加された。履歴を持つので
データ量が膨らんだり、履歴表の削除や更新が
不可能な部分については、頭を使う必要性がありそう。
(次のバージョンで改善が入ることを期待。)

6. Oracleみたいに行列でセキュリティを
かけることが全エディション共通で可能になった。

7. INGESTという簡易ETLツールが加わった。
(でも今のところ上級エディション専用…。)
-----------------------------------------------------------

ざっとこんなものですかね?
細かいところは書き漏らしがあると思いますが、
雰囲気は伝わるのではないでしょうか。
いわゆる分かり易い新機能というのが
5番目の時系列DBくらいで、後は地味に色々な改善が
盛り込まれているというのが非常にDB2らしいですw
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2011年10月28日

RACとpureScaleの違い

Oracle RACとDB2 pureScaleはどちらも
shared disk型のcluster RDBなのですが、
違いが理解できていなかったので
今日のClubDB2でお勉強してきました。

結論から言うと、クラスタ内の各DBノードの
整合性を取る部分(OracleではCash Fusion、
DB2ではCaching Facility)の置き場所が
違うってことが、最大のポイントでした。

両製品ともに、あるインスタンスが落ちても、
クラスタ内の他のインスタンスが生きていれば
無停止でDBが稼動するというのがウリです。
ですが、そのためには、落ちたインスタンスが
掴んでいた情報を誰かが持っている必要があります。

ここで、誰か=CFとなるわけですが、
RACの場合は各DBノード自体にCFが分散配置され、
pureScaleの場合はCF専用のノードを複数持ちます。

RACの方はCF専用のノードを持たないぶん
ノードの総数を減らせますが、インスタンスが
落ちたときにCFの再配置が起こるので、
その間は実は無停止ではありません。

pureScaleの場合はCF専用のノードを持つぶん
ノードの総数は増えますが、インスタンスが
落ちてもCFは無事なので、無停止で乗り切れます。

こう書くとOracleをdisってるように見えますが、
pureScaleの方はCF専用のノードをInfiniBandで
繋いで独自プロトコルで通信をさせるという
コアな仕様になっているので、そこらへんで
問題が起こると結構大変な気がします。

まあ、一つだけ言えるのは、
cluster RDBの導入にはインフラ構築の能力が
強く求められるので、RDBに詳しいだけの人が
手を出すと痛い目に合うってことでしょう。
そのせいで、RAC技術者急募って案件多いもんねw
posted by ビズアイユ at 00:00 | Comment(2) | TrackBack(0) | 備忘録@IT

2011年10月21日

データベースが鬼熱い

10月19日から今日まで、ちょっと遅い夏休みを
取っていました。INSIGHT OUTなるイベントに
参加するためです。データベースの話題だけの
ベンダフリーな技術カンファレンスが
日本で開かれるって聞いたこと無かったので、
これは参加すべきだと判断しました。
http://www.insight-tec.com/insight-out-2011.html

色々なセッションをハシゴしてみましたが、
最高に刺激的だったのが @kouji_s_0808 氏の
列指向DBのパフォーマンス検証のくだり。
現場ではデータのカーディナリティとか諸々を
考えなくちゃいけないのはあるのでしょうが、
行指向DBの1/16のパフォーマンスを弾き出した
という内容には相当驚きました。データを集計して
ナンボのBIの世界に生きている人間としては、
実案件に適用できないか調査したくなりますね。

他にも、クラウド化が進むとプラットフォームを
選ばないことが競争力に繋がる(=有利な条件の
クラウドインフラに移し易い)ため、今まで以上に
SQLの標準化が威力を発揮するなど、熱い話が
たくさんありました。こういう機会を設けてくれた
Insight Technologyさんには大感謝です。

ただ、次回の開催を期待して要望も何点か
挙げさせていただきます。実現の難しいものも
あるかもしれませんが、ご容赦ください。
 ・土日開催
  (平日参加はやっぱり辛いです…)
 ・アジェンダの事前公開
  (タイトルだけではセッションを選びにくく)
 ・議論形式のセッションの追加
  (繋がるためにはインタラクティブでしょう)

最後になりますが、三日間お疲れ様でした!
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2011年09月09日

トレンドを追ってみる

ここ最近、技術的なエントリが続きますね。
個人的には自己啓発になって良いと思うのですが、
僕のブログの読者層的には食べ物の話が
一番盛り上がるということが分かっているので、
そろそろウマいものを食べに行かないとダメだなw

そんなわけで、今日はClubDB2に参加してきました。
テーマは「IBMのテクノロジートレンド」と、
ミーハーな自分には超魅力的なテーマでした。
実際、とってもエキサイティングな内容で、
無理して定時退社した価値があったってものです。
http://twilog.org/Bizuayeu/date-110909

二時間の勉強会の中で言及された分野は以下の三つ。
詳細は後で書きますが、これだけ高度な話題を
コンパクトに分かり易く披露できるって、
エバンジェリストって凄いんだなと思いました。
 ・Hybrid IT
 ・NLP + Big data
 ・Smart Analytics

<Hybrid IT>
クラウドの本質はオフプレミスだと喝破されているのが
印象的でした。(レイテンシ的な意味で)遅かったり
(24*365だと)高かったりするのに何でクラウドが
注目されるかというと、一時利用のし易さに尽きると。
今まではシステムのデモ環境を作るのに、
ハード調達の稟議から始まってインストールだ何だで
一ヶ月仕事だったのが、今はインスタンスを作って
ちゃちゃっと設定して三時間もあれば終わり、
しかも会社に行く必要も無かったりするそうです。
このスピード感こそ今のビジネスですよね…。
そのうえで、経済性と利便性を重視する部分は
従来からの社内システムを組んだら良いというのが
Hybrid ITの思想ってわけです。クラウドクラウドって
騒いでいれば良い時代は既に終わっていました。

<NLP + Big data>
最近流行のワトソン君に絡む話です。
http://www-06.ibm.com/ibm/jp/lead/ideasfromibm/watson/
自然言語処理+大量データ+テキストマイニングで
有意性のある答えを抽出するという枠組みなんですが、
これが最近はTwitterのつぶやきに対して
機能してたりするそうです。Twitterのつぶやきって
非常にトレンド性があるから、そこから何らかの事実を
容易に発見できる機構があると、マーケティングの人とか
相当喜びそうですよね。実際、3月の大震災のときの
分析結果をデモとして見せて貰えたのですが、
どんな物資がいつ不足していたのかというタイムラインが
一目瞭然になっていて、とても驚きました。
ただ、NLP用の日本語辞書を作るのは一筋縄ではない模様。
(例:おつあり、カワユス、wktk)

<Smart Analytics>
新世代のデータ分析基盤についての考察でした。
簡単にまとめると以下のような感じ。
 ・低遅延小スループットの分析:ストリーミング処理
 ・高遅延大スループットの分析:並列分散データ処理
電力のデマンドレスポンス http://s.nikkei.com/e48Kq0
なんかは、スマートメーターを介したストリーミング処理が
前提になってます。リアルタイムに電力使用量を割り出し、
リアルタイムに電力料金をコントロールするのだから、
レイテンシが低くないとお話になりませんからね。
逆に、さっきのTwitter分析なんかは標本が多いほど
正確な分析ができるし、さほどリアルタイム性が
必要なわけではないから、分散データ処理がハマります。
中遅延中スループットなRDBでは、DWHアプライアンスで
インプリを楽にする方向だったり、ストリーミング処理や
並列分散データ処理との連携強化がトレンドみたいです。

あと、個人的に面白いなと思ったのは、
講師がオフプレミスな意味でのクラウドと
並列分散データ処理な意味でのクラスタを
きちんと使い分けて話を進めていたところ。
これから僕もそこは混同しないように心掛けますw

(追記)
@k0usukeさんと@sakaikさんもClubDB2の
参加記をブログにまとめてらっしゃいます。
僕の記事より230%ほど分かり易い感じなので、
お二方の記事の方がむしろ必読です。
http://d.hatena.ne.jp/k_masu/20110909/1315724732
http://d.hatena.ne.jp/sakaik/20110909/clubdb2_130
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(1) | 備忘録@IT

2011年09月03日

知識労働者のプライド

仕事と学校の二正面作戦は
確実に僕の体力を奪っていきつつありますが、
それでも技術への投資は続けないと
エンジニアとして食っていけなくなります。
ということで、久しぶりに勉強会で
LTの発表者になってみようと思います。
アウトプット無しではインプットの質が落ちますし。

テーマは、CTE(共通テーブル式)について。
この前のプロジェクトではシステムの裏側を
主に担当したわけですが、ETLとかI/Fといった
RDB周りの部分も久しぶりに触れたわけですよ。
で、その際にCTEがかなり役に立ったので、
Tipsをまとめてみようと考えたわけです。
ちなみに、CTEって何?って方は以下を参照あれ。
http://www.atmarkit.co.jp/fnetwork/tokusyuu/01sql99/sql99_1b.html

発表内容は以下のような感じにしようと
思案していますが、まだ具体的なテストデータとか
SQLは用意していないので、どうなることか…。
ただ、10月のClubDB2には間に合わせたいですね。

<あなたも惚れる!CTE>
 ・CTEって何?
 ・普通に使ってみる
 ・再帰してみる
 ・色々な場所で使ってみる
 ・ネストしてみる
 ・僕が惚れた!CTE

さて、DB2 Express-Cも9.7.4に上げたし、
地道に準備していきますか。日々努力ですわ。
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2011年08月28日

経験≒技術+教訓+勘

タイトルに書いた式が正しいと仮定すると、
技術と教訓についてはまとめておこうと思った、
Essbaseプロジェクト終盤の休日なのでした。
Yahhhh, Let's Go!

<要件定義>
・必要なのはスコープでウィッシュリストではない
・データのINとOUTを捉えずにシステムは作れない
・要件定義はレポートの一覧を作るフェーズではない
・業務と技術方式の両者を整理できてコンサルである

<プロマネ>
・ウォーターフォールはBIの自立を奪う
・最初から大きく作ろうとすると大きな困難を招く
・裾野の関係者を最後の仕様変更者にしてはいけない
・業務分掌のギリギリアウトに踏み込む勇気を持とう

<基盤/運用>
・基盤パフォーマンスの担保無くして実装無し
・ETLは複雑になるので最初から仕組みを用意する
・運用を後回しにすると無理な実装に逆襲される
・律儀に訂正で0を入力するユーザは稀である

<設計/実装/テスト>
・インプリを導けてこそ設計である
・データを入力前に初期化できると自由度が増す
・面倒なSQLもCTEで見易く読み易くテストし易く
・正解無しで値のテストなどナンセンスだ

帳票作りからは最近離れているので、
そのへんのことは微妙に書けなかったですが、
レポーティングツールが職種別じゃなく
用途別に分かれちゃうのは良くないかもですね。
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2011年06月26日

ペーパープロマネ試験

震災で延期になっていた
情報処理技術者試験を受けてきました。
科目はプロジェクトマネージャです。
昨秋合格したITストラテジストに続き、
二つ目の論述式試験にチャレンジです。

午前Tは免除、午前Uは解答速報を信じれば
21/25で通過なので、問題はやはり午後ですね。
午後Tではパッケージ導入に関する問2と
テスト計画に関する問3を選択したのですが、
両方とも今のプロジェクトで担当している
部分なので、埋めるのは簡単でした。
ただ、採点がどうなるかは未知数です(汗

そしてメインイベントの午後U論文。
僕はシステムの品質確保について書いてみました。
管理会計システムで、予算と納期の制約のもと、
以下の品質目標を達成するための工夫を論じました。
 ・Excel帳票による業務を100%新システムに移植
 ・ユーザが行う全ての処理で10秒以内の応答
 ・ブラウザ上の帳票を会議資料として印刷可能
はい、今のプロジェクトの要件をパクりました(爆

身近なネタがあったおかげで筆はスムーズに滑り、
ギリギリではありましたが所定の文字数を
クリアして答案を提出できたので、
合格の可能性は決して低くないと希望的観測。

とはいえ、仮に試験に受かったとしても、
一人前に実務でプロマネができるかというと、
それは別の問題。資格認定の紙切れ一枚で
渡り歩けるほど、世の中は甘くないのです…。
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2011年06月24日

久々に勉強会に行った

MBAとか言って技術がスカスカになったら
IT屋としては失格以下(ウザいだけで役に立たない)
ですから、なんとか時間を見つけて技術の
キャッチアップをしなきゃと思っているんですが、
今日は何とかその機会を持てました。

はい、例によってClubDB2に出席してみました。
今回のテーマは「ワークロード管理」ということで、
重いSQLを止めたり優先度を下げて実行する機能について
色々な解説がありました。まあ、こういう機能が
必要だから追加費用を払っても良いと考える所だと、
逆に有効活用の機会は少なそうですけど(爆

で、詳しい内容は公開資料を見てもらうとして、
僕の方は好き勝手にコメントを垂れ流してみます。
----------
 SQLの中身を見て自動で最適な資源配分をしてくれる
 GOALモードという機能もあるらしい。すげえ。
----------
 設定した閾値を超えたSQLの中身を記録できるので、
 誰がDBを重くしたのか犯人探しが容易になるw
----------
 低優先度なSQLの同時実行数を制御する施策が、
 一番パフォーマンスの改善に効くっぽい。
----------
 オプティマイザが処理の重さを見積もった結果
 (=コスト)はI/O(=ページ数)にほぼ等しい。

実際、僕は開発側の人間だし、同日行われていた
DevOpsのイベントでも「インフラと運用は別部隊」
という発言があったみたいだから、僕がこういう
運用ツールをガッツリ扱う事は少ないのだろうけど、
いざ立場が変わったら日々の運用こそ重要に
なってくるのだろうから、備え有れば…ですよねー。
posted by ビズアイユ at 00:00 | Comment(2) | TrackBack(0) | 備忘録@IT

2011年06月11日

PM試験のネタを一覧化

6月26日に情報処理技術者試験の
PMの部が開催されるわけですが、
少し前に模試を受けた後は
からっきし勉強してないんですよね(汗

論文は前日にもう一度書いてみるとして、
そのためのネタを事前にまとめておかないと
グデグデになることが確定なので、
ブログに整理してみようと思います。
ただ、今までの経験から論じられる
ネタというと、情報系システムに関するものしか
出せないのが自分の限界を物語っている気が…。

・要件定義でタスクを前倒しする
 →レポート要件と一緒にDBも定義する
  (設計段階でDBが変わると大惨事)
 →BIツールは要件定義で決める
  (設計段階でBIツールが変わると大惨事)
・真のステークホルダーを把握する
 →レポートを見るのは一般層の人たち
  (偉い人だけを見ていると最後に仕様が覆る)
・工数をなだらかに配分する
 →BIツールを使うので開発の工数は少ない
  (でも他のシステムとの連携でバグが出る)
・要員アサイン時に力量を測る
 →口述試験で任せられるタスクを見極める
  (BIツールが違うとベテランでも失敗する)
・機能別にメンバーを割り振る
 →業務はリーダに任せてPMは管理に徹する
  (業務が違ってもBIでやることは同じ)
・早い段階で実データをテストに用いる
 →実データを使わないと検出しにくいバグがある
  (受入テストで問題が発覚してもリカバリは至難)
・パフォーマンス測定の手順と基準を明確にする
 →方針の決定にはユーザも巻き込む
  (レポートが使い易くないとExcelが蔓延する)

ここらへんの話を題意に合わせて具体的かつ
読み手にキャッチーな感じにまとめられれば、
箸にも捧にも引っかからないってことは
無いと思うんですが、やっぱり偏っているなあ。
もっと守備範囲を広げないと先は無いかも(嘆
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2011年06月03日

古式床しきバッチ開発

DB屋ってのはアプリとインフラの
中間にいるような存在なので、
自然とシステム運用の調整役に
なってしまうことが往々にしてあります。
ただ、運用で使うバッチを書くのも
僕の仕事になるってのはどうなのだろう…。

ともあれ、そんな感じだったので、
最近はバッチ屋になっていたのですが、
それはそれで有用なネタを仕入れられたので、
ちょっとシェアしてみたいと思います。

<バックアップに超便利なrobocopy>
あるフォルダより下のある拡張子のファイル
(何個あるか分からない)を全部コピーという
処理を書こうとすると、激しく面倒臭かったり
するわけなんですが、robocopyコマンドだと
それを1行で実現できちゃいます。
そもそもファイルパスが長いとxcopyを
使えなかったりするし、導入して損は無いです。

<バッチのリモート実行ならpsexec>
結構大きめなシステムを作っているので、
サーバが複数台構成になってたりするんですね。
で、サーバを跨ってサービスを順番に
起動/停止させなきゃいけないって場面があり、
リモートからバッチを起動できる簡単な方法を
探してたんですが、そんなときはpsexecを
使うのが一番手っ取り早いっぽいです。
WSHとかPowerShellを使わずに、バッチだけで
処理を完結できるになるのは非常に有難いです。

【参考】
http://ziomatrix18.blog68.fc2.com/blog-entry-518.html
http://www.computerworld.jp/topics/mws/191815.html
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2011年02月25日

Netezzaって凄いのね

何とか18時半に仕事を切り上げられたので、
19時スタートのClubDB2に向かうため、
新橋から渋谷に猛ダッシュしました。
今日のテーマはDWHアプライアンスの
Netezzaという、BI屋的には外せないネタ。
http://db2.jugem.cc/?eid=2328

大量データ処理と言えば最近はHadoopが
業界を賑わせていますが、やはり運用の難易度が
まだまだ高いことを考えると、アプライアンスが
選択される場面ってのは結構多いのではと思います。

で、講演の内容はと言うと、非常に面白かった!
講師の方のサービスが旺盛で、相当深いところの
技術的ブレークスルーを語ってくれたので、
一夜にしてNetezzaの概観を掴めちゃった感じです。

いやあ、ハードに関してもソフトに関しても、
凄まじい黒魔術が仕掛けられてましたよ。
その一端が知りたい方は、僕の当日のTwilogや
k_masuさんの日記を見ると良いかもしれません。
http://twilog.org/Bizuayeu/date-110225
http://d.hatena.ne.jp/k_masu/20110301/1298989810

ディスクI/Oが早くなる魔法のチップが付いている、
SQLが通るHadoopのようなもの…マジチートw
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2011年02月14日

クラスチェンジ成功か

僕は、データベースに強いBIコンサルという
ニッチな役回りで仕事を貰っているわけですが、
きちんとした専門があるのは好ましいとして、
分野を絞り過ぎていることで変化に対応できない
というリスクを強く意識していました。

なので、データベースの外側だけでなく、
内側技術も勉強してみたり、ネットワークや
OSについても積極的に知識の体系化を
図っていたわけですが、その成果が遂に
目に見える形になったようです。

すなわち、インフラもできるBIコンサルと
職場の人に評価され、他の案件の本番環境構築を
僕が担当することになりました。
純粋にインフラな仕事を振られたというのは
初めてなので、非常に嬉しかったです。
(同時に、更なる激務が約束されましたが…。)

BIを皮切りにデータベースへ領域を広げ、
今度はインフラを攻める。このルート、
工作セットを用意して開拓しまくるぜ!
(↓左から初心者向け〜中級者向け)

posted by ビズアイユ at 00:00 | Comment(5) | TrackBack(0) | 備忘録@IT

2010年12月28日

iStudy Web版の注意点

年末にやらかしてしまいました。
Oracleの資格をゲットするための教材として
iStudyのWeb版を購入していたのですが、
有効期限が終わり、使えなくなっていました。
一度も勉強していないのに(汗

実は、今まではDL版を使っていたのですが、
9月のキャンペーンで安かったので、
Web版を初めて購入してみたのですね。
で、DL版はサポート期間だけが90日で、
模擬試験自体は以降も解けるものだから、
Web版も同じと安心してシリアル登録を
済ませていたら、今日になって使用不可に
なっていたことが判明したという…。

同じものを再度購入となると、
15000円×2コースで30000円の出費です。
これは流石に痛い! 事情を連絡して救済を
お願いしてみましたが、果たしてどうなるか。

何にせよ、年末年始の休みに資格試験の勉強を
ガッツリ行う予定だったのは頓挫しましたね。
御用納めの今日に出したメールが処理されるのは、
おそらく正月明けでしょう。ああ、僕の馬鹿(泣
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2010年12月12日

MongoとCouchな一日

MongoDBがアツイということがTwitter
遊んでいるうちに分かってきたので、
コチラの勉強会に参加してきました。
7時間も発表&交流の時間があるとか、
大盤振る舞い過ぎて素晴らしいです!

で、肝心の内容はというと、
既に主催者の@doryokujinさんが
完璧にまとめておられますので、
僕からは特に何も無いです(爆
 ・勉強会はうちに帰っても勉強会
 ・gihyo.jpの活動報告

ただ、つぶやいたりしてみましたが、
XMLDBの狙ってたところをMongoDBが
殆ど持っていったというのは印象的でした。
何と言っても、「半構造化データを柔軟に
スキーマレスで扱えます」ですからね。

XMLは、XML自体のスキーマとか、
属性と値を区別する必要がある点とか、
タグが冗長な点とか、頭の良い人が仕様を
決めた故の難しさが仇になった気がします。

MongoDBのデータ保存形式であるJSONは、
XMLに比べて非常にシンプルだし、
それでも全然実用には問題ないわけで、
時代の風は間違いなくMongoDBの方に
吹いている気がします。クエリだって
XQueryと比べて簡単なんだもんなー。

いやあ、実案件でMongoDBを使う機会が
非常に待ち遠しくなってきました。そして、
CouchDBの方はRelaxの精神で、趣味で何かを
開発するときに使わせてもらおうと思います。
DBもApp鯖も一緒に配布&デプロイできるって、
果てしなく便利で楽しそうでした。
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2010年11月26日

データベースパーティ

仕事が立て込んでいる予定だったので
諦めていたのですが、幸運にも手持ちのタスクを
消化できてしまったので、今年最後のClubDB2
参加していまいました。日頃の行いの良さですねw

で、今回は一足早いクリスマスパーティということで、
特例でお酒やケーキ付きの立食勉強会だったわけですが、
内容はいつも以上に濃かった! こんな感じでした。
 ・DataSharing環境でのRead/Write方法
 ・Hadoop/BigInsightの紹介
 ・DB2のデータベース最新トレンド

<DataSharing環境でのRead/Write方法>
DB2 for z/OSの機能についての説明だったんですが、
複数インスタンスで共有ディスクって…と思っていたら、
これがpureScaleの元となった機能でした。
インスタンス間で高速にロック情報を交換する
仕組みについて、@k0usukeさんに解説して貰いました。
詳しくはコチラへどうぞ!

<Hadoop/BigInsightの紹介>
これが僕にとって一番インパクトのある話でした。
BigInsightは、IBMが開発した、Hadoopを一発で
利用できるようにしたミドルウエア一式だそうです。
これを利用すると、DB2のユーザ定義関数から
Hadoopの処理を呼び出すことができ、結果をRDBに
戻すことができるそうです。RDB屋の俺歓喜w
加えて、BigSheetなるGUIが入ってまして、
これはスプレッドシートにHadoop上のデータの
一部を読み込んでExcelライクに行った処理を、
Hadoopの処理に変換できるという代物です。
…凄くない!? プログラマ要らないね(泣

<DB2のデータベース最新トレンド>
DB2の中の人は以下のようなことを考えてるそうです。
実際に実装されるかどうかは分かりませんが、
RDBの世界もまだまだフロンティアがあるですね!
 ・データの更新履歴の保持(タイムマシンクエリ
 ・ストレージの動的再配置(DB2版EasyTier
 ・ファイングレイン監査のようなもの

いやあ、RDBが元気だと僕の技術者としての
寿命が伸びますからね。これからもガッツリと
進化していただいて、食い扶持を確保の方向でw
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(1) | 備忘録@IT

2010年11月12日

ざっくりなモデリング

仕事が空いてたので年次休暇を取りました。
仕事以上に緊張感のあるイベントが待っているので、
それに向けて準備が必要だったわけです。
そう、今日はClubDB2データモデリングの話
行ってきました。いやあ、無事に終わって良かった!
ClubDB2_116.jpg

なんてったって、僕の2〜3倍のキャリアを持つ
データベースエンジニアの方々も参加する中で、
重要かつ抽象度の高いトピックを説明しなくちゃ
いけないわけですから、僕にとってはカイジの
鉄骨渡り級の冒険だったわけで、怪我をせずに
セッションを完走できたのは僥倖だったのですよw

しかし、おかげでデータモデリングについての
体系的な知識が自分の中に定着したので、
これはメチャクチャ大きな収穫になりました。
データモデリングとパフォーマンス保障の能力は
データベースエンジニアにとっての最大の武器だと
思っているので、その片方の完成度が上がるって
凄いことなわけです。つまり、今回一番得したのは
参加者の皆さんよりも僕自身ということですねw

と、そんなオレオレ自慢は置いておいて、
ここに来てくれた方は発表資料やUst動画を
お求めなのだろうと思います。ダウンロードは
以下のリンクから可能にしていますので、
ジャンジャンバリバリ持っていってください☆
 ・ざっくり始めるデータモデリング(PDF)
 ・ClubDB2:第116回Ust動画(FLV)
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(1) | 備忘録@IT

2010年11月03日

DBやクラウド的な備忘

なんか、ブログにまとめておいた方が良いことが
溜まってきた感があるので、放置プレイになる前に
手を打っておこうと思います。久々のオフ日だし。

<オープンソースでクラウド>
IPAが、「社内向けクラウド構築のために活用できる
ソフトウェアカタログ
」なる資料を公表しています。
クラウドの基盤となる技術やソフトウエアを
俯瞰するには非常に良い資料だと思います。
目を通してみてはいかがでしょうか?
http://ossipedia.ipa.go.jp/doc/209

<列指向DBとクラスタ索引>
エンタープライズなRDBに実装されているクラスタ表が、
実は列指向DBと似ている技術なのではとTwitterで
つぶやいたところ、全然違うというツッコミを
多方面から受けましたw クラスタ索引によって、
物理的にまとめて配置された列の値を一気に
引っ張れるという点で勘違いしたのですが、
クラスタ表のデータ格納単位はRDBらしく
あくまでもレコードであり、列指向DBのように
列で絞ってブロックを取得できるという話では
ありませんでした。@sumi_chanさん、@Key_boさん、
@eller86さん、@yutuki_rさん、ご指導THXです!

<ClubDB2でセッションします!>
いつもデータベースの濃い話題が満載の勉強会である
ClubDB2ですが、次の第116回は僕が講師ですw
お前のクオリティで大丈夫か?みたいな声も
あると思いますが、「ざっくり」レベルであれば
破綻していない内容に仕上がっている…はず。
データモデリングに興味のある方は、
11月12日(金)に渋谷に遊びにきてください☆
http://db2.jugem.cc/?eid=2270
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2010年10月08日

麹町でブレークスルー

予定をやりくりして、久しぶりに仕事場から
早く出たのには訳がありました。こんなイベントに
参加してきました。【スタートアップ・デイティング

僕は社内では技術の人(≒変な人)みたいな
認定を受けていて、色々と頼りにされることも
あったりなかったりなんですが、外の勉強会に
参加すると、自分の技量や知識が足りないことを
痛感させられる場面に頻繁に遭遇します。
このギャップを埋めて本当の技術者となるため、
世間でも一流と認められている技術者の話を
今回のイベントに聞きにきたわけです。

で、「エンジニアはどうやって成長するか?」
というテーマのパネルディスカッションが
始まったわけですが、僕の中で刺さった発言の
キーワードを箇条書きにしてみようと思います。
 ・デキるエンジニアには得意技(技術領域)がある
 ・コードを見せないエンジニアは伸びない
 ・本質を理解すれば色々なことに応用できる
 ・成功体験、会社員経験、技術のある社長を探せ
 ・発散するのが好きな人はアプリ系がマッチする
 ・勉強するのが好きな人はインフラ系がマッチする
 ・環境を変える、勉強する≒ブレークスルーの答え
 ・挨拶、礼儀、会話が重要(凄い人との出会いを生かす)

こうしてみると、あまり技術寄りの話ではないですね。
「良きお手本を見つけ、本質的なところまで勉強して、
得意技を身に付けて、色々な人と関わって、
必要とされる辺縁部分のスキルも磨いていく。」
…これって、別にITの世界に限らないですもん。
だから、こういう成長モデルを一度実感できると、
その後の展開は難しくないのかもしれません。

パネルディスカッションが終わると、
今度は立食パーティ形式っぽい懇親会に移りました。
ここではAmazon Web Serviceのタダ券を貰えたり、
JAWSのコアメンバーの方と連絡先交換できたりと、
追っかけないといけないなーと思っている
クラウド周りで素敵な収穫がありました。
これはもう、早く動けという神様からの命令ですねw

このブログを読んでいて、勉強会やイベントには
参加したことがないというITエンジニアの皆さん、
外に出ると必ず何らかの発見や収穫がありますよ!
ぜひぜひ足を運んでみてください☆
(データベースな方はコチラへ:【Club DB2】)
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2010年10月03日

ST午後U論文のネタA

舞台:
ヘルスケア用品の製造販売を行う老舗S社

役割:
経営企画室に所属するITストラテジスト

状況:
近年業績は低迷している。特に、最近は主力の
口中清涼剤の売上も振るわなくなりつつあり、
早急な対策を打つ必要に迫られている。
業績低迷の主な理由は以下の通りである。
 @主な販売チャネルだったタバコ屋や小規模薬局の相次ぐ閉店
 A二十代から三十代の若い層(以下、ヤング層)への認知度不足

経営戦略:
口中清涼剤の売上を回復し、業績の低迷を
打破するため、以下の経営戦略が決定された。
 @新たな販売チャネルを開拓する
 A製品の認知度を強化する

システム戦略:
経営戦略を実現させるため、
以下の仕組みを企画した。
 @BtoCを実現する仕組み
  ・インターネット直販体制の構築(ECサイト)
   →既存の通販事業との統合
  ・草の根代理店網の構築(アフィリエイト)
   →ASPの利用、代理店審査
 Aプロモーションを効率化する仕組み
  ・インターネット検索に対する広告(リスティング広告)
   →広告効果の可視化
   →ポートフォリオの柔軟な切替
 Bマーケティングデータを活用する仕組み
  ・購買履歴に対する分析(ビジネスインテリジェンス)
   →商品と顧客属性のマッピング
   →優良顧客の育成

工夫した点:
経営戦略とシステム戦略の適合性を高めるため、
以下の点を工夫した。
-----------------------------------------------------------
【インターネット直販体制の構築】
S社には通信販売部門が存在したが、
定期購入を行うお客様向けのサービスとなっており、
新たなお客様を呼び込める仕組みにはなっていなかった。
そこで、新たにECサイトを構築することを企画した。
S社のホームページにアクセスした人が、
そのホームページ上でS社商品を注文できるように、
商品案内の充実とショッピングカートの設置を図った。
本来であれば、受注や物流の仕組みなども同時に
整備する必要があったが、既存の通信販売用の枠組みを
極力そのまま活用することで、低コスト短期間での
体制構築を目論んだ。
-----------------------------------------------------------
【草の根代理店網の構築】
S社のホームページだけでは販売チャネルが
十分ではないと考え、アフィリエイトによる
草の根代理店網を構築することも企画した。
アフィリエイトとはホームページを運営する
法人や個人に商品の宣伝を行ってもらい、
そのホームページ経由で商品が売れた場合に
成功報酬を支払うという仕組みである。
自社でアフィリエイトを実現しようとすると
コストが嵩むことが分かったので、外部のASPを
利用する方針となったが、代理店の質を保つため、
ホームページの審査はS社が行うこととした。
-----------------------------------------------------------
【インターネット検索に対する広告】
従来から新聞や雑誌への広告は行っていたが、
その費用対効果を適切には測定できていなかった。
これが、ヤング層への認知度不足という問題を
引き起こした大きな原因の一つだと考えた。
そこで、インターネット検索に対する広告の
利用を企画した。インターネット検索に対する
広告を利用した場合、@広告の表示回数、
A広告経由でS社のホームページを訪れた人数、
B広告の表示回数に対する訪問率の把握などが
可能なので、広告効果を明確に測定できる。
また、広告を出す検索ワードや予算は自由に
設定することが可能であり、ポートフォリオを
柔軟かつ素早く切り替えられることも利点だった。
-----------------------------------------------------------
【購買履歴に対する分析】
ECサイトやプロモーション施策の継続的な改善を促すため、
分析ツールの導入を企画した。インターネット直販を
行った場合、お客様の情報と購買の履歴を結び付けることが
容易に可能であり、それらを分析することで有用な知見を
得ることができると判断したためである。具体的には、
@ある商品を買ったお客様の属性は広告を打つ際の
参考となる、Aお客様を優良顧客にするための施策を
RFM(Recency Frequency Monetary)分析に基づいて
検討できるといったことが挙げられる。
-----------------------------------------------------------

問題が起こった点と解決策:
システムの稼動にあたっては以下のような問題が
起こったため、解決策を練る必要があった。
-----------------------------------------------------------
【代理店経由での売上が伸びない】
当初の想定よりも代理店経由での売上が伸びなかったため
原因を調査したところ、売上の低い代理店ではS社商品を
実際に利用せずに宣伝のみを行っていることが多かった。
そこで、代理店向けの安価な商品サンプルを期間限定で用意し、
利用を促したところ、上記の問題は解決していった。
さらに、サンプルを利用した代理店が商品のファンとなり、
優良顧客となる事例も発生した。
-----------------------------------------------------------
【広告予算に上限を定めると売上が下がる】
インターネット検索に対する広告では、広告に対して
クリックが行われたタイミングで課金が行われる。
そのため、広告予算に上限を設定し、それを超えた場合は
広告を表示させないようにすることができる。
広告費をコントロールするため、当初は予算上限を
設定していたが、広告の表示がされなくなると、
ECサイトの売上が目に見えて低下するという事実が判明した。
そこで、広告に対する一回のクリックで得られる
平均利益を計算し、その額が広告の課金額を上回っている場合、
広告費の上限は設けないこととした。逆に、平均利益額が
広告の課金額を下回っている場合、広告対象となった
検索ワードは適切ではないと判断し、撤退することとした。
-----------------------------------------------------------
【優良顧客を正しく定義できない】
RFM分析は、顧客の一定期間内における最終購買日(R)、
購買頻度(F)、購買金額(M)を分析する手法である。
当初、RFMの全ての評価軸で一定以上のスコアとなっている
お客様を優良顧客と定義していたが、その優良顧客の
約40%は一年後に優良顧客と判定されなくなることが分かった。
しかも、その中には商品を一年間隔で定期的に購入する
大口のお客様なども含まれており、RFMのスコアで
一律に優良顧客を判定するのは危険という意見が出された。
そこで、LTV(Life Time Value:顧客生涯価値)の
考え方に基づいて、累積購入金額の高いお客様は
優良顧客であるという定義に変更した。RFM分析は、
LTVで設定されたお客様グレードごとの販売施策のうち、
どれを採用するか見極めるために用いることとした。
-----------------------------------------------------------

参考となったサイト:
http://www.affiliatesogo.com/
http://ameblo.jp/powervision/entry-10636804387.html
http://techtarget.itmedia.co.jp/tt/news/0609/21/news02.html
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2010年09月26日

ST午後U論文のネタ@

舞台:
品質の高さを重視した食品スーパーのS社

役割:
経営企画室に所属するITストラテジスト

状況:
順調な成長を続けていたが、
近年は以下の理由から売上が低迷していた。
 @景況感の悪化
 A同様の業態の食品スーパーの増加

経営戦略:
売上の低迷を打破するため、
以下の経営戦略が決定された。
 @売れ筋商品のバリエーションを増やす
  (商品総数は増やさない)
 A売れ筋商品の売り込みを強化する

システム戦略:
経営戦略を実現させるため、
以下の仕組みを企画した。
 @商品の検証を精緻に行う仕組み
  ・POSデータを用いた商品分析(分析ツール)
   →ABC分析、クロスABC分析など
  ・分析結果レポートの共有(グループウエア)
   →本部と店舗で売れ筋を共有する
 A売れ筋商品をお客様に目立たせる仕組み
  ・POSデータを用いたバスケット分析(分析ツール)
   →併売傾向にあるものを強くオススメする
   →主力動線を把握して売れ筋商品を配置する
 B売れ筋商品の欠品を防ぐ仕組み
  ・POSデータと連携した発注(在庫管理)
   →定量発注点を監視して自動的に発注書を作る

工夫した点:
経営戦略とシステム戦略の適合性を高めるため、
以下の点を工夫した。
-----------------------------------------------------------
【POSデータを用いた商品分析】
売れ筋商品を明確化するため、ABC分析のAグループを
更に細かく分割した。具体的にはAグループの上位1/3
(全体の約10%)をSグループと設定した。
Sグループ商品群の売上構成比は50%弱に上るため、
欠品を確実に防げるように定量発注点を調整した。
更に、Sグループの中の上位10%(全体の約1%)の
商品数は約150であったが、売上構成比は20%弱にまで
達するため、これらの商品群は「売り込み商品」として
各店舗に通達し、売り場作りを工夫させるようにした。
-----------------------------------------------------------
【分析結果レポートの共有】
売れ筋商品のバリエーションを増やすため、
本部だけでなく各店舗でも分析ツールを使えるようにした。
本部の想定する売れ筋商品と店舗で確認された売れ筋商品に
大きな違いがあった場合、グループウエアを用いて
分析レポートとコメントを店舗から本部に共有してもらい、
新たな売れ筋商品の候補を見つけたり、
その売り方の検討ができるようにした。
-----------------------------------------------------------
【POSデータを用いたバスケット分析】
売れ筋商品の売り込みを強化するため、売れ筋商品が
お客様に目立つような売り場を作れるようにした。
具体的には、POSデータをバスケット分析という手法に
かけることで、同時に売れる傾向が特異的に強い
売れ筋商品の組み合わせを発見し、それぞれを近くに
陳列できるようにした。また、お客様が購入した商品を
手に取るための最短経路をレシート毎に求め、
それを重ね合わせることで店舗の主力動線を明確にした。
こうして明確になった主力動線に沿って売れ筋商品を
配置することで、売れ筋商品のお客様への露出を高めさせた。
-----------------------------------------------------------
【POSデータと連携した発注】
売れ筋商品の欠品を防ぐため、POSデータと在庫データを
突き合わせて定量発注点を監視させるようにした。
在庫が定量発注点を下回った売れ筋商品の発注数量が
自動的に発注書に入力されるようにすることで、
発注漏れによる欠品が起こらないようにした。
ただし、店舗によって商品の売れ方が異なることを想定し、
発注担当者も発注数量を編集できるようにした。
-----------------------------------------------------------

問題が起こった点と解決策:
システムの稼動にあたっては以下のような問題が
起こったため、解決策を練る必要があった。
-----------------------------------------------------------
【分析結果の出力に時間が掛かる】
当初、POSデータは関係データベースに格納していたが、
ABC分析もバスケット分析も集計を基本とした分析のため、
関係データベースを分析基盤にすると処理時間が
長引いてしまうことが分かった。ロックを始めとする
トランザクション機能のオーバーヘッドが理由であるが、
POSデータは参照のみで更新を行わないデータなので、
トランザクション機能は本来必要ない。
そこで、POSデータは生データの形でそのまま保存し、
LinuxのOSコマンド(シェル)で生データを直接分析する、
ユニケージという方法でシステムの一部を改修した。
これにより、分析の処理時間は大幅に短縮された。
-----------------------------------------------------------
【分析結果の共有が進まない】
各店舗でも分析ツールが使えるようになった結果、
売れ筋商品の分析は現場でも行われるようになったが、
本部との情報共有は進まなかった。店舗にヒアリングを
行ったところ、コメントの入力に時間が掛かるので
本来業務に手が回らなくなる、どういった情報を
共有すれば良いのか分からないという意見が得られた。
そこで、店舗のスタッフではなくエリアを巡回する
マーケティング担当者が入力を代行する運用に変更した。
これにより、各店舗に固有の売れ筋商品に関する情報が
順調に集まるようになった。
-----------------------------------------------------------
【在庫処分した商品が発注されてしまう】
不人気や販売シーズン終了のため在庫処分を行った
商品にも関わらず、勝手に発注が行われたという報告が
店舗からしばしば上がるようになった。定量発注点を
下回った商品に関しては、発注数量が自動的に
発注書に入力されることが原因であった。このため、
ABC分析のCグループの商品および販売シーズンが
終了した商品に関しては、発注数量の自動入力が
行われないようにシステムを調整した。
-----------------------------------------------------------

参考となったサイト:
http://www.shoninsha.co.jp/modules/merchant12/index.php?cat=4
http://www.kktisc.co.jp/?p=71
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2010年09月03日

俺が第六正規形だ(謎

タイトルは検索エンジン対策なんですが、
それは今日の資料を色々な人に見て欲しいから。
ということで、ClubDB2で高次正規形の
LT(ライトニングトーク)を行ってきました。

一つ前のエントリにも書いていたように、
ドメイン/キー正規形や第六正規形といった
マイナーな(だけど興味深い)正規形について
五分間で説明してみたわけですが、実はLTでは
語れなかったことも結構あったりしました。
内容を盛り込み過ぎて時間が足りなかったの(汗

そこで、LT用に削ったスライドも復活させた、
完全版の資料を公開させていただきます!
こちらは第一正規形から第五正規形までの
おさらいに加え、ちょっと驚く小ネタも
随所に挟んだ豪華な仕様となっております。
HigherNormalization.pdf

これからも正規化理論について深堀りできたらと
思っているので、何かあったら質問とか提案を
コメントいただけると超嬉しいです♪
あ、Twitterの方のアクションも大歓迎ですw

そしてメイントピックである遠山先生の
SuperSQLのお話でしたが、やはり面白かった!
個人的には“文脈依存の集約”で窓関数と
同じようなことが自然にできちゃう部分とか、
RDBの中身をSQL/XMLより遥かに簡単に
XML出力可能だったりとかが凄いと思いました。

また、SuperSQLという実装の背景にある
情報容量論、ネスト方法による結合結果の違い
(合成ネスト操作と射影ネスト操作)といった
アカデミックな話題には、知的好奇心を刺激
されまくりでした。時間的財政的な余裕があれば、
いつか先生の研究室で勉強したいなあ…。

午前の定期健康診断の人間ドックで飲んだ
バリウムが体に残ってる感は少々萎えますが、
それでも今日は非常に有意義な一日でした。
やっぱり技術者のコミュニティ活動って良いよ☆

追記:
デスペの午前対策になるよって紹介した、
情報処理技術者試験は俺に聞け”への
リンクを張っておきます。ぶっちゃけ午前は
量稽古だと思うので、多答するのが重要かと。
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2010年08月28日

高次正規形を語ります

データベースの話題続きで一般の方には
???な状態だと思いますが、またもやですw
食べ歩きな記事を読みたい場合はTwitterの方が
そんな感じになっていたりもするので、そちらを
チェックして貰えると良さそうと宣伝してみるテスト。

さて、来る9月3日の金曜日ですが、
またもやClubDB2でライトニングトークします。
テーマは高次正規形。第四正規形や第五正規形は
もちろんのこと、日本では存在自体がマイナーな
ドメイン/キー正規形や第六正規形も解説します。

英語の文献でも今回ほど簡潔にまとまったものは
無かったと個人的には思っているので、
第三正規形より上の正規形の存在について
不思議に感じたことのあるITエンジニアの方は、
是非ともClubDB2に遊びに来てください☆

しかも、更に凄いことに、今回はSuperSQLの
遠山先生がメインの発表者だったりもします。
SuperSQLの話は、僕のブログ記事を眺めるより、
遠山先生ご本人から伺った方が絶対面白い!
間違いなく好奇心を刺激される内容だと思うので、
この機会を逃すのは勿体無いですよー。
…渋谷のIBMイノベーション・センターで僕と握手(謎
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(1) | 備忘録@IT

2010年08月21日

Goldは一つだけでなく

なんだかOracle Masterの受験料が10月から
値上がりするらしいので、開発者トラックの
Goldもそれまでに取っておこうと決心し、
黒本とiStudyに手を付け始めました。

が、覚えることの多さとややこしさが
今まで以上にパワーアップしているような…。
模擬試験問題の数も300問に届いてるし(汗
合格ラインが66%と高くないのが唯一の救いか?

かなり頑張って300問全て解いてみたところ、
結果は正解率50%ジャスト。うん、初回でこれなら
9月末までの受験にギリギリで間に合いそうです。
あとは、試験日まで反復練習の繰り返しだ!

そうそう、DBAの方のGold有資格者ロゴが
ダウンロードできるようになっていたので、
自己満足のためにブログに貼ってみますw
これくらいしか使い道が無いしね(爆
OCP11g.png
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2010年07月09日

SuperSQLをLTしてみた

TwitterSuperSQLのことを呟いてみたら、
興味を持ってくれる人が多い雰囲気なので、
ClubDB2の前座でSuperSQLの紹介
することになりました。…思い切っちゃったぜ☆

ライトニングトークという形式で、
5分間で内容をしゃべりきる必要があったので、
発表資料をコンパクトにまとめて
事前にリハーサルもして頑張ったんですが、
結果として本番は時間が余りまくり。
何故か質疑応答まで出来ちゃいましたw
ClubDB2_01.jpg

あ、発表資料を見たい方は以下からどうぞ。
SuperSQLの本質については他のWebの記事を
漁った方が有意義だと思いますが、Windows環境の
DB2と動作させた事例ってのはレアだと思います。
http://sasurahi.up.seesaa.net/docs/SuperSQL.pdf

最後に、ClubDB2の皆さんに感謝を致します。
私のようなヒヨッコを演台に上げてくれたり
MySQLのユーザ会と合同でイベントを開いたりと
懐が広いし、基礎を重視したうえで面白いテーマを
展開してくれるし、飲み会の内容まで濃いし、
本当にDBエンジニアなら参加しないと損だよー。
(今回も非常にエキサイティングでした!)
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2010年06月30日

やっとデスペ取れたよ

データベーススペシャリスト試験に
やっと合格しました。本当なら5年前には
取れてたと思うんですが、不勉強の至りですな。

ただ、試験対策の付け焼刃ではない知識が、
回り道をしたおかげで養われた気はします。
集合論や関係代数といった根幹部分とか、
句の評価順やCASE式や窓関数といった
SQLの使いこなしとか、バッファやログや
チェックポイントといったDBMSの挙動とか、
統計取得やパーティショニングといった
パフォーマンスチューニングの進め方とか…。

ClubDB2など、色々な勉強会に積極的に
参加したおかげで、ミックさん坂井さん
遠山教授といった大御所と知り合えたことも
非常に大きかったです。先を進む人の
考え方を聞くことで、ますますRDBの世界の
奥深さを実感しつつあります。

さて、今後も頑張って勉強を続けねば!
とりあえず、第六正規形と第七正規形を
理解したいところです。特に第六正規形は
Domain Key Normal Formで検索すると
情報がいっぱい出るから、読み込まないと。

(参考)
http://d.hatena.ne.jp/tgk/20060425
http://d.hatena.ne.jp/winplus/20070311/1173576253
http://en.wikipedia.org/wiki/Domain/key_normal_form
http://www.google.com/search?q=Domain+Key+Normal+Form
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2010年06月19日

SuperSQLが凄かった件

三週間くらい前から計画していた
SuperSQLの遠山先生への訪問ですが、
想像以上に楽しい時間になって最高でした!
とっても内容の濃い話を聞けたので、
備忘的にメモを残してみることにします。

SuperSQLについて>
・JDBCを介してRDBの上に乗っけて使う
・クエリ言語ではなく、レポーティング言語
・属性の組み合わせ(情報)をネスト(構造化)して
 文書の型(メディア)を適用するという仕組み
 →情報を取得する際には簡単な標準SQLが生成される
 →構造化と文書の型の適用がSuperSQL独自の仕事
 →クエリ結果のラッパーと考えるとBIツールに似ている
・文書構造の概念が非常に高度に抽象化されている
 →単純に関係二つを左右に並べて表示することが可能
 →属性の組み合わせに直積を取ることも可能
 →Z軸や時間の移り変わりまで表現できる
Activiewというレイアウト変換アドオンがある
 →Webの解像度に合わせてネストの方向が変わる
   (横を縦に、あるいは別ページ=奥行きに)

<SuperSQL以外の研究内容について>
情報の三元分解と再合成
 →SuperSQLの考え方の根本にあるもの
 →プレゼンテーションの観点から考えると、
   情報の過小はサマリと取れることもあるが、
   情報の過大は嘘でしかないと分かった
   (結合従属性って重要なんですね!)
 →情報容量の具体的な解説はコレを読むべし
RMX
 →Rule-based Mail eXchangeの略
 →メールアドレスがRDBへの問い合わせと結び付き、
   動的に送信先の集団を設定できる仕組み
 →複数のMLを管理する場合などに超便利
   (メルアドを個々のMLに設定しなくて良いから)
 →詳しい説明は特許のページを参照
Web Index
 →リンクを貼るのではなくマッチさせる技術
 →単語とURLのテーブルを作成し、
   それをテキストにアタッチすることで
   動的にリンクが作成される
 →古いコンテンツから新しいコンテンツに
   リンクを繋げたり、一つのリンクから
   関連ページを一気に拾えるようになる
RBIM
 →RDBにセル単位で読み書き権限を付ける仕組み
 →XML向けの拡張もされている

「データモデルや検索言語については述語論理や
代数に基づく美しい理論が行われている」、
「データベースの基本技術との融合によって
新たな研究分野が無限に誕生する」という
言葉の意味が十二分に掴めた六時間でありました。
遠山先生、本当に有難うございました!
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2010年06月12日

遠山先生宛質問事項案

来週の土曜日にSuperSQLの遠山先生
お話を伺える機会を作ることができたので、
事前に質問事項をまとめてみたんですが、
何か書いててワクワクがあったので、
ブログの方に転載しちゃうことにしますw

一応、Googleで読めるSuperSQLな論文には
一通り目を通したのだけど、更にDMBOK
ウィトゲンシュタインの論理的哲学考からも
ネタを仕入れられそうなんだよなー。
うーん、読書の時間を確保したいぜ!

<SuperSQLについて>
・SuperSQLを開発した目的は?
 →研究目的で開発されたとはどういうことか?
・SuperSQLが目指すものは?(SuperSQLの本質とは?)
 →「ワンソースマルチユース」?
 →テンプレートエンジンでは駄目なのか?
・SuperSQLのGUIを確認させて欲しい
・SuperSQLを使ったRDB→LDAP同期のデモを見たい

<SuperSQL以外の研究内容について>
・近傍連鎖点列集合とは?
・芸術とデータベースの関連とは?
・検索言語の分野における研究成果は?
・質問処理の分野における研究成果は?
・これ以外に研究していることは?
 →SuperSQLを開発するためには文書の構造について
  認識・定義するプロセスが最低限必要に思える
 →SuperSQLで文書の出力の研究を行っているが、
  逆に文書のRDBへの入力もアリなのでは?

<問い合わせ言語について>
・一般的なSQLは今後どのような進化をしていくと思うか?
 →水平反復子、垂直反復子、深度反復子、時間反復子は
  一般的なSQLにあっても面白そう
 →ユーザ定義関数やプラグインの統一プラットフォーム?
  (SuperSQLのLDAP同期機能などを他のRDBで使いたい)
 →クエリの速度が実行前に分かる機能?
  (SuperSQLには情報容量の提示機能がある嘘でした…)
・SQL以外の問い合わせ言語に可能性はあるか?

<データベース一般について>
・様々なデータベース(XMLDB、OODB、MDB、
 KVS、VOLTなど)についてどう考えているか?
 →RDBと比較した利点や欠点、位置付けは?
 →DBMSにおける評価軸には何が考えられるか?
・データベースと言えばRDBの時代は続くか否か?
・論理データモデルがエンティティとリレーションを
 完全に分けるべきか否か?
 →(参考)T字型ER手法SuperSQLのサンプルスキーマ
・「データモデルや検索言語については述語論理や
 代数に基づく美しい理論が行われている」とは?
・「データベースの基本技術との融合によって
 新たな研究分野が無限に誕生する」とは?
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2010年05月28日

リレーショナルな一日

データベース技術者であるという自覚のある人は、
是非Club DB2に足を運んでみましょう。
大手商用DBの会社なのに、こんな運営方針
勉強会を開催してくれるなんて、前衛的過ぎて
参加者の方が大丈夫なのかと思うくらいなのでw

ということで、今日もIBM箱崎に行ったわけですが、
今回はあのミックさんがゲスト講師ということで、
会場は超大入りでした。「リレーショナルとは
どんなことか」 という抽象的なテーマを語れる
エンジニアなんて、本当にレアですからねー。

さて、ミックさんのサイトに講演資料が
アップされているので、内容に興味のある人は
そちらを読んでいただくとして、以下は僕が
衝撃を受けたことをまとめていこうと思います。

<僕とミックさんのキャリアが似てた>
入社して初めて触った言語がSQLで、
その後はBI畑を歩いていたという共通点が
分かって驚きました。しかも、もしかしたら
同学年かもしれないということが判明。
いやあ、自分のサボリ具合がバレますな(滝汗

<QAのレベルがメチャクチャ高かった>
類は友を呼ぶというのか、PostgreSQLや
MySQLの開発者とか、DB一筋40年の社長さんが
参加されてまして、最後のQAが濃かったです。
特に僕が面白いと思ったものはこんな感じ。
 ・RDBにアクセスする言語はSQLだけで良いのか?
  →CとかJAVAみたいに特徴別の言語があって良い
 ・専門DBの軸としては何が考えられるか?
  →モデルの柔らかさとか、扱える情報の種類とか…
 ・インメモリDBって効果あるの?
  →OLAPだと検索が非定型だからキャッシュに当たらない
  →OLTPだと普通にメモリを積んでおけば問題無い
  →使いどころが限定されている印象

<ミックさんが初学者向けの本を執筆中>
しかも、初学者向けなのに窓関数も扱うらしいw
これは必ず購入して後進の育成のために
宣伝しないとダメですね。CodeZine
SQLアタマアカデミーRDBの世界にある
中級者向けの記事とは違う書き下ろしの
内容になるのではと思っているので、
読める日が来るのが非常に待ち遠しいです。
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2010年05月19日

新しい技術にワクワク

今日初めて知ったんですが、
文書を直接発行できちゃうSuperSQLなんていう
拡張SQL言語があるんですね。慶應大の教授が
研究開発に携わってるそうです。
 SuperSQLオフィシャル
 SuperSQLが拓く次世代IT

コレを使いこなせると、MVCの実装を
全部SQLで済ませられるのかもw
データベース側の人間としては、
非常に面白さを感じる一品であります。

でもって、Oracle RACの勉強を始めた僕は、
シェアード○○って概念も調べていたんですが、
最近ではMySQLでもシェアードナッシングが
実現できちゃうみたいですね。
 SPIDERストレージエンジン
 SPIDERに関する記事の一覧

KVSだかNoSQLだか分からないですけど、
RDBの良い所を豪快に犠牲にしている
アーキテクチャより、こっちの方が
全然クールに思えるのは僕だけじゃないはず。

いやあ、やっぱり新しい技術って
ワクワクするよなー。是非とも技術調査の
タスクを僕に振って欲しいものですw
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2010年04月23日

本当の技術者って何だ

もはや常連となりつつありますが、
また例のClub DB2に参加してきました。
今回のテーマはDB技術の未来ということで、
IBMの技術理事と言われる偉い人が
滅茶苦茶濃い話をしてくれました。

最初のパートはソフト寄りの話で、
「ストリーム・コンピューティング」という
テクノロジの紹介でした。雰囲気としては
概ねこんな感じでしょうか。
 ・膨大なリアルタイムデータを分析する
 ・正常値ではなく異常値に着目する
 ・分析ロジックを処理するための言語がある
 ・データのパース技術も求められる

例えば、テキサスに台風が近付いています。
このとき、石油産業全体の株価が下がりますが、
台風の直撃コースから外れることが分かった
会社の株価は反転して上がります。
こういうことを素早く検知するための技術が
ストリーム・コンピューティングってわけですね。

過去のデータから知見の発見をするのではなく、
現在のデータを踏まえて判断を導くことも
ITを活かせる領域になっているというのは、
時代が進んでいることを痛感しますね。
データマイニングだ!とか言って誰かを
唆している業界が滑稽に思えてきます(汗

しかし、何をデータソースにして、
どうやって信頼度の高いデータをパースして、
どんなロジックで事実を検知するのか?
これを実装しようと思ったときに求められる
技術力を想像すると、自分の未熟さが
浮き彫りになります。…うん、やっぱり僕は
技術者を自称するには全然足りていません。

と、色々とヘコみつつ、次のパートは
ハード寄りの話です。IBMのハイエンドな
ハードウエア技術について、資料としては
出せないものまで紹介して貰えました。

ハードウエアの方は専門ではないので、
これが凄いみたいな解説はご容赦ですが、
面白かったことを断片的に書いてみます。
 ・SRAMではなくeDRAMを使った大容量CPUキャッシュ
 ・In-Memoryデータの圧縮による主記憶領域拡張
 ・起動モードによって最適化されるアプリを変更可能

何にせよ一つ言えることは、
こういう本当の技術を扱える人のいる会社が
最終的に残っていくんだろうなと。
御用聞きのSEも、デジドカのPGも、
このままじゃ未来は無いっすよ、日本じゃ。
ちくしょー、勉強あるのみ!努力するのみ!
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2010年03月29日

都心に住んでいる利益

…というのは間違いなく大きいなと
エンジニア(?)的にも思います。
何故なら勉強会とか無料セミナーの数が
半端じゃないんですもの。試しに
IT勉強会カレンダ」を見てみると、
ほぼ毎日何らかのイベントがあるでしょ?
スキルアップの機会満載です☆

そんなわけで、最近は主に以下の二つの
イベントに顔を出すことが多いです。
 ・Club DB2
 ・データベース友の会
忘れてる人も多い気がしますが、
僕は一応データベース屋さんなんでね。

何故か同郷の友人たちは東京でSEを
やっている率が高かったりするので、
こういう機会に顔を合わせられると
一石二鳥なんですが、どうでしょうw

そうそう、OracleのDeveloperの方の
Silverも取得できたので、次はいよいよ
GoldのDBAに挑もうと思います。
6月の土曜開催の認定講座を社費で
受けさせて貰えるよう、5月中旬を
期限で合格を目指してやるぜー!
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2010年03月10日

これぞタイミングが妙

業務でPL/SQLを使う雰囲気になってきたので、
Amazonで非常に評価の高かった
プロとしてのOracle PL/SQL入門」を
購入して読んでみました。

実際、分かりやすくて内容も網羅的で、
机の中に入れておくには申し分ない本かなと
思ったわけですが、一点だけ問題が…。

11gに対応した改訂版が発刊予定だったし(泣


まあ、PL/SQLの内容は10gでも11gでも
特に変わらないそうで、Oracle社自身が
資格のバージョンを上げなかったことからも
大局に影響は無い感じがするんですが、
リファレンスとして使うことも考えると、
やっぱり新しい方を買っておきたかったなー。
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2010年03月06日

いい加減に受かろうぜ

ということで、春の情報処理技術者試験の
季節が近付いてきました。足踏みが続いてる
DBスペシャリスト試験を今年こそ受からないと、
そろそろ各方面からアホと言われそうなので、
必要な知識を微妙にまとめてみようと思います。

正規化を行う理由:
テーブルの冗長性を排し、更新時異状を防ぐ
(事前登録不能、重複更新、関係喪失)

非正規形:
属性に単一でない値が含まれている

第一正規形:
全ての属性が単一値である

第二正規形:
非キー属性が候補キーの真部分集合に
部分関数従属しない(=候補キーが
単一キーの場合は必然的に第二正規形)

第三正規形:
非キー属性が候補キーに
推移的関数従属しない
(=非キー間の関数従属が存在しない)

ボイス・コッド正規形
候補キーの真部分集合が
非キー属性に関数従属しない
(=ボイス・コッド正規化を考慮するのは
候補キーが複合キーのときだけで良い)

第四正規形:
テーブルが候補キーのみで構成され、
自明でない多値従属性を含まない
(=多値従属性が一つの場合はOK)

第五正規形:
テーブルが候補キーのみで構成され、
自明でない結合従属性を含まない
(=結合従属性が一つの場合はOK)

普通は第三正規化までで良い理由:
テーブル構造からビジネスルールを排除すると、
第三正規化までで正規化は完了する
素早く正規形を見抜く実践テクニックより)

おまけ:
 ・トランザクション分離レベル
 ・分散問い合わせ処理
 ・コミットメントプロトコル
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

2010年02月24日

Kiva Linuxベータ版

久々にLinux系のエントリです。
いやあ、サラリーマン始めると開発時間を
全然取れなくてダメダメですなー(汗

で、ダメダメな感じなんですが、
以前記事にしていたKiva Linuxの
ベータ版が完成?したので報告でーす。
http://sasurahi.seesaa.net/article/133166628.html
http://sasurahi.seesaa.net/article/135749625.html

結局、最新版のPuppy Linux 4.3.1を
元にして作ることはできなくて、
去年のTOP Linux 4.2.1をベースとして、
Kiva Japanから提供していただいた
起動画面やら壁紙やらブクマやら
Kivaのシステム説明を単純にマージしました。
Kiva Linux ダウンロードページ

更なる軽量化のため、SquashFS4な
LZMAでSFSを作れるよう、カーネルの
バージョンアップはしたかったんですが、
これはゴールデンウイークの課題かな…。
posted by ビズアイユ at 00:00 | Comment(0) | TrackBack(0) | 備忘録@IT

Puppiest.png

×

この広告は180日以上新しい記事の投稿がないブログに表示されております。