2010年1月23日土曜日
安全文化
2009年4月19日日曜日
情報工学部会歓迎会

歓迎会の前に理化学研究所の方がHPCに関して講演していました。なんと、格調の高い...すごいですね、Earth Simulator、消費電力6MWって...そういや、学生のとき、Crayのスパコン、液体窒素で冷却してるとか何とか言っていたような。FEMのデータを置きっぱなしにして結構課金されたりしたなぁ...
情報工学部門だからなぁ...ってシリコンバレーのノリで、ちゃらいジャケットにノータイで行ったらみんな(スーツというより)背広だった。皆さん、大手のITや電気メーカーの何とか部長とか室長とかの方もいて、ちょっとビビッてしまいました。でも、とりあえず名刺交換できたし、人脈を広げるという意味では良い経験です。
終って外に出ると、東京タワーのライトアップが...
2009年3月20日金曜日
技術士第二次試験「口頭試験」受験必修ガイド

2009年3月16日月曜日
祝!!技術士二次試験合格
2009年1月8日木曜日
オブジェクト指向を家の奥さんに説明する
「オブジェクト指向を一般の人でも分かるように説明してください」
まあ、ありえる質問ですよね。 Object Maniaを自称する身としては、これは綺麗に回答したい。
(ちなみに、まだ家の奥さんには説明してないです。)
こういうの、割と好きです。
自分の思考パターンとしても、物事を厳密に説明するのには向いていない構造をしている気がする。 なので、厳密性を排除して、分かりやすさを追求して良い説明は楽しい。
オブジェクト指向というのは、プログラミングやデータの表現の方式の一種で、クラスとインスタンス、カプセル化、継承、ポリモルフィズムといった代表的な概念をもっています。 これは、後の文章を読めば分かるように書いたつもりなので、あまり気にしないで読みすすめてください。
最近のソフトウェアは非常に複雑なので、このような考え方が必要になってきたわけですが、どのような場面で使われているか、Excelを例に説明してみます。
(始めに断っておきますが、本当にExcelがこういう実装になっているかは別です。 違うだろうなぁ、と思いつつも概念を理解するためにはこの説明がよいかな?と思いながら書いているところもあります。)
Excelでセルを右クリックしてプロパティを見ると、背景色を変えることができます。 この背景色を赤にすれば画面上でセルは当然赤くなります。 これがプログラムでどのように処理されているのか考える際に、オブジェクト指向でない場合、今選択されたセルの左上と右下の座標をなんらかの形で入手して、その範囲を赤く四角で塗りつぶし、その上にセルに記入されていたテキストを乗せるといったような処理になります。 ただし、実際には罫線であったりテキストのフォントは何か?大きさは?等考えなくてはいけないことは非常に多くなります。 ここで、セルの座標やフォントといった情報をどうやって管理するのか考える必要があるわけですが、配列のようなテーブルを用意してそこに格納しておくといったやり方でも出来るかもしれませんが、非常に複雑です。 オブジェクト指向のプログラムでは、セルに対する処理や処理に必要な情報は、セルと言うプログラムの塊の中に全て隠蔽してしまいます。 どういうことかというと、一つのプログラムの塊の中に、セルの背景色と一緒にセルの座標、フォント、フォントタイプ、フォントの大きさといった情報を全て入れ込んだ状態にしておき、そのプログラムの塊はそのセル以外のことは基本的に考えない形にしておきます。 そして、外部からセルの背景色を変えるよう指示があった場合、その処理はそのプログラムの中で行い、必要な情報もそのプログラムの中から集めて画面上でセルの背景色を変える一連の処理を行います。 このような考え方をカプセル化と言いますが、前の例と比較すると必要な情報の入手は格段に楽になります。
ところが、Excelのセルの場合であれば、セルは大量にあります。 それぞれのセルは背景色もフォントも異なります。 これをどう処理するかといえば、100個セルがあれば、100個似たようなプログラムの塊を作るのです。 しかし、Excelの場合どの程度のセルがあるかはじめから分かっているわけではありません(実際には分かっているのかも知れないけど、まあ突っ込まずに...)から、元となるプログラムの塊があって、それをコピーして100個のセルをつくります。 セルの追加削除があれば元となるプログラムからコピーして、新しいセルのプログラムを作ります。 この時に元となっているプログラムをクラス、100個のコピーで作られたプログラムをオブジェクトと読んでいます。
継承というのはこのクラスを定義する際のテクニックの一つです。 例えばセルで右クリックをすると、そこにはカット、コピー、ペーストといったようなコマンドが並んでいますが、これはテキストボックスでも同じで、行や列を選択しても同じです。 これらのコマンドはオブジェクト指向ではメソッドと呼ばれていますが、この様なExcel上の全ての選択可能な要素のクラス一つ一つにそれぞれメソッドを定義をしていくのは面倒です。 そこで、そういった様々なクラスで共通するメソッドはある抽象的なクラスで定義してしまい、セルやテキストボックスといったそれぞれのクラスはその抽象的なクラスを親としてその定義をコピーし、それぞれのクラスに特化したメソッドだけを差分として定義しようという考え方が継承です。
このようにオブジェクト指向ではプログラム上必要となる様々な要素をクラスとして定義し、それをオブジェクトとしてコピーする(これをインスタンス化するとも言う)ことによってプログラムを成り立たせているわけですが、クラスの種類が多くなってくると、不便なことも起こります。 例えば先の継承の例で、カット、コピー、ペーストは親のクラスで定義したメソッドを子で再利用できるという前提で話をしましたが、もしかするとセルとテキストボックスでは微妙に違った操作が必要になるかもしれません。 カット、コピー、ペーストだと分かりづらいので、削除で考えてみると、セルで削除とすれば上にシフトさせるか左にシフトさせるかといったことを聞いてきますが、テキストボックスで削除すればそんなことはお構い無しに削除です。 つまり同じ様に見えるメソッドでもプログラムとしては全く別物なわけです。 セルとテキストボックスの場合Excelで同時に選択することは出来ませんが、仮に可能だったとしたら、一気に削除!!と、したときにどのように動いて欲しいか...当然、テキストボックスは無条件に削除、セルはシフト方向をユーザーに聞く、という具合にそれぞれ別なプログラムを呼んで欲しいわけです。 プログラマーも同じで「このオブジェクトはクラスが××だから、このメソッド、このオブジェクトはクラスが△△だからこのメソッド...」なんてやっていられない訳です。 この様に、異なるクラスにおいて同じ様に見えて、実際には異なるメソッドを持っていたとしても、同じ様に見えるんだからとにかく実行してしまう。と、いうやり方がポリモルフィズムです。
と...どうでしょう?
正直、Excelの実装とはかなりかけ離れたものになってると思うのですが、一般的なオブジェクト指向の説明だと、車がスポーツカーとSRVに特化されて云々...車も飛行機も右に曲がりたいときは云々...と概念的な話から入って、そこからどうしてプログラムがオブジェクト指向なのかにたどり着く前に飽きちゃうと思うので、こんな説明を考えてみました。
2009年1月5日月曜日
SaaSに関して考える
私はといえば、技術士口答試験に向けて、自宅に篭って悶々と準備中の毎日でございます。
この不景気の中、纏めて休みを取ったものだから、家の奥さんは会社をクビになったんじゃないのかと心配しております。 そして、こうやってブログを書いていることを話したところ、「他の受験生に見られたら自分が不利になるんじゃない?」と。 いや、技術士の試験は絶対評価の筈だから関係ないはずなんだが... (そもそもこのブログ、Googleもヤフーも検索にかかってこないぞ。) そういや大学の時、レポートを書く際に同期にノートをコピーさせてあげたら、同期の方が点数良かったことがあったっけ...
今夜は2008年度技術士二次試験見直し中です。
(もちろん、このブログは模範解答を書いているつもりはなく、自分の考えを纏めるために書いているだけです...)
今日のお題は情報工学部門(午後) 情報システムデータ工学のI-1-1
I-1-1 SaaS(Software as a Service)とは何かを説明し、SaaSを導入することによって企業が得られるメリットと課題を述べよ。
割と興味のある分野なので、書きやすいです。
2008年12月31日に書いたブログに一部僕の考えを書きましたが、ここではASPとの対比で考えてみようと思います。
(ところで、ASPってActive Server PageとApplication Service ProviderでTrigramだぶってますね...同じIT業界の中でなんと言うセンスの無い... もちろんここではApplication Service Providerのことです。)
SaaSとASPの技術的相違
他にも、色々と要素はあるのかも知れませんが、僕が着目したのは以下の点です。
シングルシステム・マルチテナント
Google appsやGmailのようなオフィスアプリケーションでは問題にならないのでしょうけれど、業務システムにおいては、程度の大小はあってもユーザー企業ごとの要件の違いは不可避です。 ASPにおいてはユーザー企業(テナント)ごとの要件の違いはテナントごとにシステムリソースを個別に割り当てることで対応していましたが、結果として利用コストが高くなっていました。 SaaSでは、カスタマイズ要素をアプリケーションから分離することで、シングルシステムマルチテナントでありながら、柔軟なカスタマイズ性を実現しています。 代表的なのはSalesforceでしょう。 2008年12月31日にも予告しましたが、近日中に勝手に技術解説(公知の技術を営業妨害にならない範囲で)したいと思いますのでご期待を。
リッチクライアント
ASPが登場した時点でWebアプリケーションのユーザーインターフェースで使用できる技術は静的HTMLが殆どでした。 静的HTMLは表現力の面でWindowsアプリケーションと比較すると大きく劣るものでした。(だから、僕はWindowsアプリが好き) もう少し具体的に言えば、Webアプリケーション上に何かボタンがあったとして、そのクリックイベントに対して一々サーバーと通信し、結果として画面を再描画するため、レスポンスが遅く、しかも画面がちらつくというものでした。
が、JAVA ScriptとWebサービスによる非同期通信の組み合わせである、AJAX等リッチクライアント技術の登場により、WebアプリケーションであってもWindowsアプリケーションと同等の表現力を実現することが可能となりました。 このAJAXですが、具体的には以下のようなHTMLで実現されています。 分かりやすいように、重要な部分だけを抜き出してみました。

そして、これがAJAXの動きです。

①Button Aがクリックされるとイベントハンドリング関数aaaがコールされる
②aaa内では非同期通信用のオブジェクトxmlReqを生成する。 Internet Explorerの場合は、ActiveX ObjectのMicrosoft.XMLHTTPを、その他のブラウザではXMLHttpRequestというオブジェクトを使用する。 このxmlReqがサーバと通信を開始するが、ブラウザ上でユーザーがこの通信を感知することは無いし、HTMLページに対する更新も起こらない。(これがサーバーのレスポンスを待つことを不要とする操作性を実現しているわけであるが、同時にセキュリティ上のリスクにもなり得る。)
③xmlReq内にonreadystatechangeとしてコールバック関数を定義しておく、サーバーからの応答はここで定義された関数内でハンドリングする。
④コールバック関数からHTML内で更新すべき要素に対して更新処理をかける。 この処理はHTML全体のリフレッシュではなく、HTML内の一部に対するものであるため、画面のチラつきは起こらない。
Webサービス
以前、某学会でSalesforceの社長が言っていたのは、Salesforceの提供するWebサービスを利用することで、ユーザーはマッシュアップにより独自のアプリケーションを創造することができるという。
なるほどー
SaaSの導入によって企業が得られるメリット
1)初期投資の抑制
パッケージソフトウェアの導入では、システム導入に踏み切る際の初期導入コストが大きく、投資対効果を明確にしづらい場合、導入が難しかったわけですが、SaaSはハードウェアを含めて従量制を取ることが出来るため、初期導入コストを抑えることができ、開発リスクを抑えることが出来ます。
2)管理コストの削減
SaaSにおいては、サーバハードウェアのメンテナンス、データのバックアップ、ソフトウェアのパッチ対応等の管理業務がサービス提供側の責務となります。 サービス利用企業毎に専門の管理者を常駐させる場合、定常的に業務量が確保できなければ管理コストが高くつくことになりますが、SaaSの提供者側にとっては、専門の管理者が複数のサービス利用企業を管理することが可能であるため、業務量の平準化とノウハウの蓄積により効率の良い管理が可能であり、結果として質の良いサービスを低コストで提供できると言えるのではないでしょうか。
3)セキュリティの向上
管理コストと同様、セキュリティにおいても管理者の教育等、複数のサービス利用企業を一括で管理する場合、効率が良いと言えるのではないでしょうか。
(AJAXの場合、JAVAスクリプトの使用等、セキュリティ上のリスクが増す面もありますが...)
SaaS導入における課題
SaaS導入における最大の課題は、データや企業の業務プロセスの投影とも言えるアプリケーションが場所的にSaaS提供者側にあることに対する抵抗感の問題でしょう。 特にサービスが取り扱うデータがサービス利用企業の競争力の源泉であれば、その管理を第三者に委ねることに抵抗があるのは当然でしょう。 また、企業活動の根幹に関わる高い可用性を要求されるサービスであれば、そういったサービスを第三者に委ねることにも抵抗があるでしょう。 これらの問題は、技術的にはセキュリティと高可用性の問題であり、SaaS利用の拡大と共に実績によりユーザーの抵抗感が薄れていくことでしょう。
これって、分譲マンションと賃貸マンションの話と似てるなぁ...
キャッシュフロー的には賃貸の方が得な筈なんだが、それでもやっぱりマンションが欲しい。
2008年12月23日火曜日
ソフトウェアトラブル・システム障害について考える
なんか、硬いネタばっかりですね。
別に本質的にそういう人間という訳じゃないんですけど、勉強中なものですから...
今年もソフトウェアトラブル・システム障害に関する話題が豊富だった様です。
ITProで特集してました。
http://itpro.nikkeibp.co.jp/99/trouble/index.html
- 2008年11月4日 JCBのカード関連サービス障害
- 2008年9月14日 全日本空輸(ANA)の空港システム障害
- 2008年7月22日 東証の新派生売買システム障害
- 2008年5月19日 住友信託銀行のシステム障害
- 2008年5月12日 三菱UFJ銀行のシステム統合に伴うトラブル
- 2008年2月25日 信金中央金庫のシステム障害
ここに挙がってくるようなシステムは、それでもお金かけてテストしていると思いますよね。 でも、どんなにお金をかけてもソフトウェアトラブル・システム障害を防ぐことが出来ないことは、マイクロソフトが年間70億ドルの開発予算を掛けてもバグがなくならないWindowsが物語っていると思います。 僕のNote PCは大体週に2回くらいブルースクリーンを見るかな? 何時間もかけて書いた書類が吹っ飛んだりすれば、それは頭にも来るでしょうけれど、幸いにしてそういう経験はあまり無いので、コーヒーブレイクをとれという神のお告げだと思うことにしています。
東京証券取引所のJCOM問題は恐らくソフトウェアトラブルを考える際の最も優れた教材なのかも知れません。 こちらのJCOM問題が実際にどのようにして起こったのかを纏めた情報システム学会の資料です。
http://issj.nuis.jp/renkan.pdf
(去年の技術士二次試験の問題は、ここからの引用だったんですね。)
証券関係のシステムをやっている人がどう捕らえるかは分かりませんが、よくここまで不幸が重なったものだな...というのと、このケースを想定したテストが書けなかったということにどれだけの過失があるのだろうか?この問題を100%防ぐアプローチが存在するのか?と、言うのが率直な感想です。 Windowsなんか、利用シナリオを考えていたらキリがないから、マイクロソフトの場合、Microsoft Solution Frameworkに書かれている手法(つまりバグはあるという前提で、統計的に管理する手法、あるいはプロジェクト管理面に関する議論)とかで品質の向上を狙っているのでしょうかね? それが正しければ、バグがあるという前提のOS上で動いている情報システムにバグフリーを要求すること自体がナンセンスな気もしてしまうわけですが... だからWindowsを使わないんだ!!と、突っ込まれそうですが、本質的にはソフトウェアが複雑になりすぎて統計的手法に頼らざるを得なくなっている、あるいはTQCのようなプロジェクト管理的に品質向上を狙うアプローチにしかなり得ないということだと思います。 簡単な言い方をすると前者はベータテストみたいな形でシナリオフリーでユーザーに使ってもらうか、パイロットプロジェクトを行って、そこで品質を作り上げていくということでしょうし、後者に関しては、こういったソフトウェアトラブルの原因を追究し、どうすれば防げたのか?という問いに対して、本質的に「関係者間のコミュニケーションの改善」という答えに行き着いてしまうということです。 そう考えると、「Programming First Development」や「Test Driven Development」ってソフトウェアの品質向上にどれだけ寄与するのか...
僕は以前、プラントエンジニアリング会社に勤めていたのですが、そこであるシステム構築の計画の際に、部長に「検証はどのようにやるのか」と、聞かれ、答えに窮してしまった経験があります。 システムエンジニアとして何年か経験した今でも、検証プロセスに対してその時からそう成長した感じはしませんが、自分自身がシステムエンジニアとして品質に対するマインドが特段低いとは考えていません。 ハッキリ言ってしまえば、情報システム開発はプラントエンジニアリングほど成熟しておらず、品質管理もプラントエンジニアリングに見習うべきところが多いということです。(もちろん、情報システム開発が進んでいる部分も多々ありますが...) そういった他業種のベストプラクティスの流用に関しては、自動車業界を引き合いにだすことが多いと思いますが、受注産業である点やプロジェクト管理の手法(PMPなんか、元は建設業界の方が盛んでした)など様々な面から情報システム開発はプラントエンジニアリングに似ています。
例えとして、システム開発におけるプログラマとプラント建設における溶接工を比較してみます。 溶接はプラント建設において品質を作りこむための一つの大きな要素ですが、基本的には全ての溶接箇所にたいして、溶接手順やその溶接手順で十分な品質が出たことの証明(WPS/PQRと呼ばれる)が存在します。 この証明(=PQR)はプラントエンジニアリング会社の溶接技術者が確認するのではなく、第三者機関が確認します。 そして、それぞれの溶接手順(WPS)はどの溶接工でも施工して良いわけではなく、それぞれのWPSに対して認定された溶接工のみが施工を許されています。 が、一方システム開発ではどんなことをやっているというのでしょう? 何の認定もないプログラマに実装(=施工)のかなりの部分の裁量が与えられてしまっているのではないでしょうか?
この問題を考え始めたきっかけは、技術士口頭試験で以前題材となったということからなのですが、考えていくと、ちょっと極端に深く広くなっていき、キリが無いので、この辺で止めることにします。 午後はもっと楽しいことを考えることにしよう...
2008年12月22日月曜日
BCP / ISMS / ITIL
今回のネタは...
情報工学部門(午後) 情報システムデータ工学のI-1-4
I-1-4 情報システムに関わる以下の用語を説明せよ。
BCP (Business Continuity Plan), ISMS (Information Security Management System), ITIL (Information Technology Infrastructure Library)
この設問は、どう捕らえてよいのか難しいところですね。正直、よく分かりません。
技術士の試験である以上、単に物知りクイズというのでは無いはずです。
BCP/ISMSとITILだと話のLevelが異なると思うのですが...どう応えればよいのか?
とりあえず、BCPとISMSは綺麗に纏めて、ITILは別な話として考えて見ます。
個人的な考え方では、BCPもISMSも情報システムの問題と言うよりは企業経営・企業統治の問題で、純粋な情報工学の話では無いと思います。とは言え、最終的に情報システムの話も入ってきますし、技術士に求められるものが単なる技術的知識だけでなく、その社会に及ぼす影響や社会的背景といったことが問われてくるので、おさえておくべき内容なのでしょう。
先ず、BCPとISMSですが、背景には企業活動のグローバル化があるのだと考えています。つまり、企業活動に関わる利害関係者が増えるに従って、一つの企業の問題が多くの企業に影響を及ぼすようになってきた。例えばBCPであれば、新潟中越沖地震における、ピストンリングメーカー・リケンの問題が有名です(http://itpro.nikkeibp.co.jp/article/COLUMN/20080723/311320/)。この例は、代替メーカーのいない状態でのリケンへの部品供給の依存により、多くの自動車メーカーがリケンの操業停止の影響を受け減産に追い込まれましたというものです。ISMSは扱うもの自身は情報セキュリティですが、企業活動において取引相手の情報セキュリティの管理体制が自社の経営に影響を及ぼすという点では同じ様な位置付けと考えて良いのではないでしょうか。
両社に共通して言えることは、「取引相手がちゃんとそういったことを考えておいてくれないと、危なくって取引できない」ということです。ですので、BCPもISMSも認証制度があります。ISMSは元はBS7799として英国で、その後ISO/IEC17700としてISOかされています。BCPは2007年末にBS25999として、BS化していますが、未だISO化まではしていません。そういった意味では、ISO9000シリーズやISO14000シリーズと似たような考え方と考えてよいのでしょう。
何れもいっていることは正しいのですが、個人的には、なんでもかんでもこうして認証制度化するというのは、どうなんだろう???という違和感もあります。
では、本題のBCPとISMSに関してですが、いろんなサイトから言葉を繋げると以下のような感じでしょうか?
BCP (Business Continuity Plan)
天災・戦争といった不測の事態に対して、事業を継続するための事前の対策。ここには、そういった事態に対して事業を継続・早期復旧のための対策から、維持・撤退の判断のプロセスも含む。昨今の企業活動において、情報システムは基盤をなすものである為、情報システムの不測の事態におけるサービスの継続、バックアップ・復旧等もBCPの一部として重要である。従来のバックアップを中心としたディザスタリカバリに加えて、事業継続の視点からリカバリにどの程度の時間が許されるのかといった視点や、サービスの継続の観点から、システムの冗長化やASPを利用したアウトソーシングまでを考慮するひつようがある。
ISMS (Information Security Management System)
企業などの組織が情報を適切に管理し、機密を守るための包括的な枠組み。コンピュータシステムのセキュリティ対策だけでなく、情報を扱う際の基本的な方針やそれに基づいた具体的な計画・実施・見直しまでを含むものである。ISMSでは情報の重要性の決定等は企業の判断に委ねられており、組織が情報セキュリティ確保・維持するためのPDCAサイクルに基づいた枠組みであり、第三者機関により、客観的に評価し認証する制度でもある。
ITILはBCPやISMSとは異なり、情報システムの運用のBest Practiceとい位置付けだと思います。先ずは、言葉の定義を各種サイトからの継ぎ接ぎで作っておきます。
ITIL (Information Technology Infrastructure Library)
情報システム運用管理のベストプラクティスの標準であり、サービスサポート・サービスデリバリの2つのカテゴリに対して標準を提供する。サービスサポートはサービスデスクの運用からインシデント管理等のサポート業務の標準であり、サービスデリバリはサービスレベル管理から、財務管理・可用性管理といった、サービスの管理業務の標準である。
ITILにもBS15000およびISO/IEC20000の認証制度があります。ただ、BCP・ISMSの場合、一般的な企業にたいして、「取引相手がちゃんとそういったことを考えておいてくれないと、危なくって取引できない」と、いう意味で必要とされていた認証であるのに対し、ITILの認証は運用まで請け負うSIやASP等の情報システムサービスの提供者が、サービス利用者に対してサービスのレベルを証明するためのもので、ちょっと位置づけが違います。
とは言え、情報システムに関するアウトソーシングという観点から言うと、認証が必要な背景はおなじとも言えなくもありません。
しかし、認証だらけの世の中ですねぇ...
2008年12月21日日曜日
木構造に基づく編成法と動的ハッシュによる編成法
情報工学部門(午後) 情報システムデータ工学のI-1-2は以下の様な問題でした。
I-1-2 関係データベースにおいて、ある関係の属性に索引を設ける場合に、編成法として、木構造にもとづく編成法(B+Treeなど)と動的ハッシュによる編成法(リニアハッシュなど)が選べるとする。それぞれの方法について、他方より有利と予測できる応用例を示し、その理由を述べよ。
実際の答案では、木構造やHashに関して、あまり深く書く紙面はありませんから、以下を参考に特徴的な部分を記述することになるのでしょう...
http://objectmaniacgallery.blogspot.com/2008/12/btree.html
http://objectmaniacgallery.blogspot.com/2008/12/linear-hash.html
そして、Pros & Consですが思うに以下のようなことでしょうか...
動的Hash:
- 圧倒的に検索速度が速い=O(1)。(Synonymによる多少の低下はあっても、Hash空間を拡大することで改善可能でしょう。)
- Indexの更新が起こりにくいので、頻繁にTransactionのある状況でもPerformanceの低下が少ない。(Linear HashではHash空間の拡張の際に多少のCostは掛かるが...)
- 検索条件で、範囲指定がされた場合に有利(<や>等)。HashだとIndexの意味が殆どなくなってしまうのでは?
B+Tree
結構良い問題ですよね...
先日は、Linear Hashを調べるので結構時間が掛かってしまったので、今日はB+Tree。
B-Treeに関しては、「情報処理試験 ソフトウェア開発技術者完全攻略〈2004年版〉」を参考にさせていただきました。(ところで、この本、結構重宝しています。なんで改定版が出ないのでしょうか...)
B+Tree(B+-Treeと書く場合もある)はB-Treeの改良型です。
B-Treeとの大きな違いは、Data自体をNodeに格納せずLeafに全て格納することです。NodeはKeyとPointerのみを持つので、B-Treeと比較するとNode当たりのKeyを大く取れます。この考え方はもとはISMA(http://ja.wikipedia.org/wiki/Indexed_Sequential_Access_Method)から来たもので、B-TreeとISMAを組み合わせた考え方がB+Treeともいえます。
また、B+TreeはLeaf間にPointerを持っており、比較演算子の処理等もB-Treeと比較して容易ともいえるかと思います。
Keyの追加・削除やNodeの分離といった処理は、基本的にB-Treeと同じですので、こちらを参考にして下さい。→(http://www.atmarkit.co.jp/flinux/rensai/fs02/fs02c.html)
リニアハッシュ(Linear Hash)
恥ずかしながら、僕はLinear Hashって分からなかったのですが、Hashに関する一般的な知識から何とか回答することはできました。
木構造との比較でPros & Consを求めた出題ですので、Linear Hashを深追いする必要はないのでしょうけれど、分からなかったことをそのままにしないのが僕のPolicy。なぜかあまり情報が見つからなかったので、Memoっておくことにしました。
Linear HashのHash関数は他にもあるかも知れませんが、調べた感じでは...
h[i](c) = c mod (2^i)N
式の意味は後で分かると思うので、実際の動きを追ってみます。
まず、Hash空間のSizeの初期状態が4だとします。(N=4)
このとき、iは0としておきます。(今は深く考えないでください。)
すると、現時点でのHash関数は
h(c) = c mod 4
ここで、例として5,7,8,14,17,12とIndex化していきます。
この時点で、Hash値とそこにぶら下がった値は下の図のようになります。

この時点でHash値0と1はSynonymが発生し、検索効率が落ちています。
そこで、Hash空間を大きくして、Synonymが極力発生しないようにしたいと思います。
しかし、普通のHashであれば、全ての値に関して、Index化をやりなおす必要がありますのでちょっと大事になってしまいます。Linear Hashでは全ての値についてIndex化を行う必要はありません。
手順を見てみましょう。
そして、ここが面白いところですが、Hash関数は
ですが、この様にすると、例えば、7のHash値は7ですから、Hash空間のSizeを越えてしまいます。そこで、結果として得られた「Hash値がHash空間のSizeを越えるようであれば、前と同じHash関数を使う」と言うことにしておきます。
すると、Hash空間の1~3にぶら下がっている値は、結果としてHash値変更無しと言うことになります。影響を受けるのは、Hash値0にぶら下がっている値だけです。
Hash値0にぶら下がっている、8と12のHashを上に従って計算すると、それぞれ0と4。
ですので、12は4の下に動かします。
さらにHash空間を拡張してみます。これも面白いところですが、Hash関数は h(c) = c mod (2^1)4 = c mod 8


