新著が出ます：『SQL実践入門』
リレーショナルデータベースというのは、SQLという自然言語を模したインタフェースによって、低次のレイヤーを隠蔽する意図で作られたミドルウェアなので、本当は実行計画などという手続レベルの世界をユーザが覗き見るのは、本末転倒なところもあります。ただそうはいっても、現実にSQLが遅かったら原因を解析せざるをえないわけだし、大体本当にブラックボックスにしたいなら、なんでどのDBMSも実行計画を見られる手段なんか用意してるんでしょうね不思議ですね、という理想と現実の狭間で悩むエンジニアの方々に少しでもベターな解に辿りつけるアプローチを提示できれば、と考えております。
以下まえがきと章立てです。
本書の目的は、パフォーマンスの良いSQLの書き方、特に大量データを処理するSQLの性能向上の方法を理解することです。SQLの第一の目的は、ユーザが欲しいと思ったデータを選択すること、あるいは望んだ結果になるようデータを更新することです。通常のプログラミング言語と同様、一つの目的を実現するSQLの書き方は複数あり、それらの間には機能的には差異はなくても、パフォーマンスには大きな差が生じることが頻繁に起こります。したがって、SQLの組み立てを行うにあたっても、効率やパフォーマンスを重視した書き方が求められることが多くあります。
アプリケーション開発者の方の中には、普段あまりDBMSの内部アーキテクチャやストレージといった下位層を意識せず、データベースをブラックボックスとして扱っている人も多いでしょう。実際、データベースの扱うデータ量が少なければ、そのスタンスでも十分実用に堪えるシステムが作れるのが、RDB（リレーショナルデータベース）とSQLの良いところであり、「ブラックボックスとして扱えるデータベース」は、RDBが目指してきた目標の一つとすら言ってよいぐらいです。
しかし近年は、データベースが扱うデータ量は飛躍的な増大を遂げており、「ビッグデータ」という言葉も、IT業界の枠を超え社会全般に広まりました。それと歩調を合わせて、データベースのパフォーマンスに対する要求も高くなる一方です。
データベースのパフォーマンスについて理解するには、SQLだけでなく、データベース内部のアーキテクチャやストレージのようなハードウェアの特性まで含めた総合的な知識が必要となります。あるSQLがなぜ速く、それと同じ結果を得る別のSQLがなぜ遅いのかを理解するには、ブラックボックスの蓋を開けて中を覗のぞいてみることが必要となります。本書は、その中を実行計画を通して覗いてみることで、ブラックボックスをホワイトボックスにすることが目的です。
振り返ってみると、RDBとSQLは、ユーザが直観的に利用できるインタフェースと、大量データの効率的な処理という、2つの相反する命題の間で常に揺れ続けてきたミドルウェアでした。RDBとSQLが、この難問をどのように解決しようと努力してきたか、その成果はどのようなものか──そして今、どのような壁に突き当たっているか──それらを一つ一つ、本書の中で明らかにしていきます。
本書もまた、この難問に対する最終解決を与えるものではありません。しかし、現場で日々データベースのパフォーマンスと戦うエンジニアに、RDBとSQLをブラックボックスとして扱っていたときよりも一歩進んだアプローチを示すことができればと考えています。
- 第1章：DBMSのアーキテクチャ──この世にただ飯はあるか
- 第2章：SQLの基礎──母国語を話すがごとく
- 第3章：SQLにおける条件分岐──文から式へ
- 第4章：集約とカット──集合の世界
- 第5章：ループ──手続き型の呪縛
- 第6章：結合──結合を制する者はSQL を制す
- 第7章：サブクエリ──困難は分割するべきか
- 第8 章：SQLにおける順序──甦る手続き型
- 第9章：更新とデータモデル──盲目のスーパーソルジャー
- 第10章：インデックスを使いこなす──秀才の弱点
- Appendix A：PostgreSQL のインストールと起動
- Appendix B：演習問題の解答
実行計画のサンプルとしてはOracleとPostgreSQLを採用しました。この理由は、実行計画がテキストベースの綺麗な階層構造で表示されるので学習用に向いていることです。
内容的には以前『Web+DB Press』で連載していた「SQL緊急救命室」、「SQLアタマアカデミー」、「DBアタマアカデミー」などをベースに加筆修正を行ったものなので、これらのサイトを見てみるとイメージがつかめると思います（救命室のようなストーリー仕立てではありませんが）。
皆様のお役に立てば幸いです。
不作為の罪：『なぜ、システム開発は必ずモメるのか？』
みんなそれなりに頭もいいし、人間的にもまともな人たちが集まって仕事をしているはずなのに、「なんでこんなことになっちまったのかな・・・オレたちはただ、幸せになりたかっただけなのに」と敗戦後の焼け野原を見たときのような呟きが漏れてしまうことは、日常茶飯事です。
それぞれのプロジェクトには、固有の難しさと失敗の原因が存在するでしょう。いわく、新しい技術にエンジニアが慣れていなかった。いわく、客のキーマンがモンスターカスタマーだった。いわく、オフショア先の品質が低くてメチャクチャなコードが上がってきた――これらはいずれも嘘ではありません。「幸福な家はみな同じように幸福だが、不幸な家の不幸には独自性がある」というトルストイの言葉通りです。
しかし、あたまもやる気も人並みにある人間たちが数十年取り組んできて、それでもなお失敗を繰り返すのだとすれば、それはシステム開発という仕事に何かしら構造的な問題が潜んでいると考えるのが合理的というものです。この問いに対する本書の回答はシンプルです。
作り手の進め方が悪い
「……はい、どうもすいませんでした」。いや、「進め方」という書き方をしましたが、これは別に開発の方法論とかプロジェクトマネジメントの技法に欠陥がある、という意味ではありません。システム屋は、何かと物事を技術論に落として考えようとする癖を持っていますが、本書が指摘するのは、もうちょっと違う、どちらかというとメンタルの問題です。「SIerやベンダは、自分たちの立場を勘違いしている」というのが、本書の中心的なメッセージです。
システム開発がモメる場合、その相手は十中八九が客です。業者間の擦り付け合いというモメ方をすることもありますが、その場合もある程度客が関係しています。開発側と客がモメるとき、開発側は、自分たちは精いっぱいのことはやったのだ、と考える傾向があります。出された要件には従ったし、何度も変更要求を入れてくるワガママにもつきあった。何も分かっていない素人の思いつきに、もう精神と肉体の限界まで付き合った。それなのに何でこれ以上責められなきゃいけないんだよ、と。
しかし、本書が豊富な事例で示す判例は、そのような開発側に対してかなり厳しいものです。
- システムの納入が遅れた原因について要件定義が不十分であったことに対してベンダ責任を認める。（東京地裁 平成16年3月10日）
- ユーザが威圧的なため開発者が離脱したことでシステムを完成させられたなかったことについてユーザ責任はないと認める。（東京地裁 平成19年12月4日）
- パッケージに機能が不足していたことを採用したベンダの責任と認める。（東京地裁 平成22年1月22日）
こうした判例におけるポイントは、「ユーザはシステムに関しては素人なのだから、開発主体はプロとして開発プロジェクトをリードする義務がある。ユーザに言われたことや契約書に書いてあることだけやりました、と言ってもその理屈は通らない」ということです。
開発側は、ともすると「契約書や仕様書に書いてあることだけ満たせばいい」という発想をしがちです（Contract is contract）。しかし、たとえRFP通りのシステムが出来上がったとしても、それが実用に堪えなければ、「常識的にそれはおかしいだろ。プロなんだから、たとえ書面に書かれていなくても柔軟にそこは補えよ」という判断を裁判所は行う、ということです。客の検収が終わった後でも、実用に堪えなかった場合はベンダ側の責任が問われることもある（p.133）。言われてないから知りません、では許されないのです。
このように開発側から見ると厳しい判断が行われる理由は、システムという分野の専門性が高く、買い手と売り手の間に知識の非対称性が大きいからです。いわば、医療や法曹と同じレベルでの注意義務が、作り手には求められるのです（収入は大分違う気がするが、ドンマイ）。
最近も、要求仕様に明記されていないセキュリティ対策を行っていなかったことが開発側の責任として認められる判決が東京地裁から出ました。「たとえ明文化されていなくても、やって当たり前のレベルは言われなくてもやるべきだ」ということです。
確かに、SQLインジェクション対策をやっていないWebシステムを世に送り出したというのは、普通のエンジニアであれば身震いする話ではあります。しかし、ここまで豪快ではなくても、「客は何も言わなかったし、仕様書にも書いていない」という要求を黙って見過ごしたことは、皆さんにもないでしょうか。それは許されない態度だ、と本書は何度も釘を刺します。そこは、プロとして客に注意を促し、コストと便益を情理を尽くして説明し、体を張ってシステムを守らなければならないのだ、と。
刑法の世界には不作為の罪という概念があります。普通、罪というのは何らかの能動的な行為に対して問われます。しかし、よからぬ事態が出来することを知りながら適切な防止策を怠ることも罪なのです。
プロジェクトのリスク管理なんかもそうだけど、ITの世界では何もしないこと自体が問題ってケースがよくあるわ。いろんな問題をただ待つわけじゃなく、積極的に探し回る神経が双方に必要なのかもね。（p.246）
これは、技術論というより、プロとしての自覚というマインドセットの問題です。エンジニアには法律や医療の世界と違って排他的な性格を持つ資格がなく、誰でも「自分はエンジニア／プロマネです」と名乗れてしまうため、人材の品質が安定せず、参入障壁も低いためコスト競争に巻き込まれてしまう、というマクロな構造問題もあるのですが、それはまあ、現場レベルで論じるには大きすぎる話です。
本書は、開発側にとっては耳の痛い紛争の事例が豊富に紹介されています。また、プロジェクト管理やリスク対策にはコストがかかることを理解するべきだ、ということをはじめとして、ユーザ側にとってもSIerやベンダとうまく付き合うためのコツが紹介されており、双方にとって有用な知見が得られます。もっとも、本書をユーザ側が読むと「ふーん、開発サイドってのはそんなに立場が弱いのか・・・なるほどね」と悪用するためのガイドとしても使えそうな予感がするのは・・・気の回しすぎですかね。
新著が出ます：『おうちで学べるデータベースのきほん』
参考に、以下にまえがきと章立てを引用します。
データベースというのは、初心者から見ると具体的なイメージのつかみにくく、それゆえ学習のとっかかりを見つけにくい分野です。プログラミング言語やWeb サイトの作り方が、具体的な目的意識と手触りを持って学べるのとは対照的です。「データを貯める場所なのだろう」ということは想像が付くものの、それ以上何をやっているのかとなると急に曖昧になるのがデータベースの難しさです。本書は、そのような初心者が感じる「イメージの湧きにくさ」を緩和することに重点を置いた入門書です。
対象としては、プログラマーやエンジニアといった「プロ」を目指す人たちだけでなく、営業や一般企業の情報システム部門など、「ユーザ」としてデータベースを扱う方々も含めています。
本書を読むことでデータベースのイメージと役割が以前よりはっきりと結べるようになれば、そして「結構奥が深くて面白いのだな」と思ってもらえれば幸いです。
Chapter List
- Chapter 01 データベースって何だろう
- Chapter 02 リレーショナルデータベースって何だろう
- Chapter 03 データベースにまつわるお金の話
- Chapter 04 データベースとアーキテクチャ構成
- Chapter 05 DBMSを操作する際の基本知識
- Chapter 06 SQL の基本を学ぼう
- Chapter 07 トランザクションと同時実行制御
- Chapter 08 テーブル設計の基礎
- Chapter 09 バックアップとリカバリ
- Appendix パフォーマンスを考えよう
1〜4章で（リレーショナル）データベースの概略や基本的な設計の仕組み、そしてお金のカラクリ（データベースに限らず、システム開発というのは巨額のおカネが動く一大プロジェクトです）について理解し、第5章からMySQLを操作しながらSQLや機能を学んでいくという構成をとっています。これによって、実際にデータベースを触ることになるプログラマから、エンジニアに要求を伝えるユーザ企業の情報システム部門、お金の勘定をしなければならない営業（そして営業と戦うことになる各種の人々）まで、幅広い人たちにとってデータベースの基本を学ぶことができる書籍になったと思います。共著というのは初めてでしたが、一人で書くよりも豊富なアイデアと気づきを盛り込むことができて、個人的にもけっこう勉強になった仕事でした。
なお、現在もう一冊、こちらは中級向けの書籍ですが、刊行に向けた準備が進んでいます。発売時期は春ごろ予定なので、また時期が来たらこのブログで告知します。それまで皆さん、風邪などひかぬよう頑張っていきましょう。
新著が出ます：ジョー・セルコ『プログラマのためのSQL 第4版』
皆さん、お久しぶりです。長らくブログの更新が止まっていたのは、少し大きな仕事をしていたためです。ジョー・セルコ『プログラマのためのSQL 第4版』の翻訳。これに集中するため、ブログもやらずTwitterもやらず（こっちはちょっとやってしまった）頑張っておりました。
長かった。
本当に長かった。
原著が800ページ以上あるうえ内容も簡単ではないので、もともと楽な仕事とは思っていませんでしたが、いや大変でした。ですが無事今月刊行とあいなりました。すでにAmazonはじめオンラインショップでも予約受付を開始しています。あらかじめ言っておきますが「表紙のおっさん誰？」という質問は私にはしないように。私も答えられないので（笑）。
さて、本書の内容を紹介する代わりに、少し長くなりますが訳者前書きを引用します。購入するか判断の参考にしていただければと思います。なお、実行環境としては前書きでも書いていますが、PostgreSQLがおすすめです。
本書は、米国データベース界を代表するエンジニアであるジョー・セルコ氏の著書『JoeCelko’s SQL for Smarties』第4 版の邦訳である。SQLに関して、おそらく世界で最も網羅的かつ体系的に記述された本であり、また高度で実践的なテクニックを満載していることから、英語圏でSQLを学んだり仕事で使う人々にとっては、不動のバイブルとして位置づけられている本である。
原書第2版の邦訳は、2001年にピアソン・エデュケーションから刊行されたが、それから第3版を飛ばして、久々の訳出となる。著者も述べるように、この間のSQLの進歩には目覚しいものがあり、本書もSQLの新機能に対応するべく大幅なアップグレードが行われている。「新しいSQL」を学ぶすべての人にとっての導きの書となるに相応しい重厚な内容であり、本書を訳出できたことは、一人のDBエンジニアとして非常に嬉しく思う。
さて、本書を読む人々のために、ここで本書の内容について簡単なガイドを行いたい。本書は、全39 章からなるが、大きく前半と後半に分けられる。前半は第12章まで、後半は第13章以降である。前半は主にSQLおよびリレーショナルデータベースの基礎的な概念や理論的枠組みについての解説が行われる。後半は、それを踏まえたうえでSQLの持つ多彩な機能の解説と高度な応用テクニックが紹介される。基本的には第1章から順に読んでいくシーケンシャルな読み方でかまわないが、もし読者が手っ取り早くSQLのテクニックを知りたい、あるいは前半をパラパラめくってみて、内容をある程度承知していると感じたならば、第13章から読み始めて、適宜必要な前半を参照する、という読み方をしてもよい。第13章は正確にはSQLのテクニックを解説した章ではないが、必ずすべての読者に読んでもらいたい。「本書の中で最も重要な章は？」と訊ねられたら、迷わず第13章と答えるだろう。
第12章までの前半では、テーブル、ビュー、プロシージャ、トリガーといったデータベースで扱われるオブジェクト、SQLのデータ型、および制約といった概念が扱われる。そのとき核となるのは、リレーショナルモデルと、ファイルシステムや手続き型に基礎を持つ言語との考え方の違いである。私たちはまず、こうした伝統的な言語で身につけた考え方をいったん忘れて、まったく新しい観点で物事を見ることを要求される（SQLに限らず、何の分野であれ、これが一番難しい奥義なのだが）。第13章以降では、EXISTS、LIKE、結合、HAVING、ウィンドウ関数、CASE式といった、SQLの持つ強力な武器の多彩な応用方法を学んでいく。
なお、本書ではいわゆるモデリングや正規化についてはほとんど触れられない。正規化については第9章で取り上げているが、主に理論的解説にとどまり、実践的なケーススタディなどは扱われない。また、トランザクションや同時実行制御についても、第2章で簡単に触れられるのみであるため、こうしたテーマについては別に適切な書籍にあたってもらいたい。
また、本書は原則として標準SQL に準拠する構文で書かれているため、基本的には特定のDBMSに依存しないSQLを学ぶことができる。「基本的には」と留保を付けたのは、標準SQLに対する準拠のレベルは実装によってバラつきがあり、特定のDBMSではそのままの形では使えない構文も含まれているからだ。そのような場合は、適宜訳注にて説明を補っているので参考にしてもらいたい。願わくば、次の版ではこのような訳注の数が減ってほしいものだ。ちなみに、本書のサンプルコードをそのままの形で最も多く実行できる実装は、おそらくPostgreSQLであろう（翻訳時に動作確認環境としてPostgreSQL 9.1.1を使用した）。
ただし、例外的にストアドプロシージャやファンクションについては、Oracle Database のPL/SQLによる構文を掲載している。この理由は、標準SQLによる構文はどの実装でも動作しないため、原著に掲載されているプロシージャやファンクションのサンプルコードを動かせる実装がなかったためである。そこで本書では、動かないコードを載せるよりは実際に動くコードのほうがよいと考え、シェアの高いDBMSであるOracle DatabaseのPL/SQLを採用した（悪いことに、プロシージャやファンクションの構文はDBMS間でもバラバラである）。
最初に述べたように、本書はSQLの教科書としては疑いなく最高峰の水準である。だがそれだけに、本書を読み進めるのに難しさを感じる人もいるかもしれない。その場合は、あわせて読むことを推奨したい本がある。1つは、同じ著者による『SQLパズル 第2版
』（翔泳社、2007）である。これは、さまざまなパズルを通じてSQLのテクニックを身につけるという、いわば「練習問題集」にあたる本である。もう1 つが、拙著『達人に学ぶ SQL徹底指南書
』（翔泳社、2008）である。これは、もともと本書の理解を助けるための「副読本」として書いたものである。肝心の教科書の登場が一番遅れてしまったが、ともあれ、これで教科書、問題集、副読本が揃ったことになる。
最後に、本書を買うかどうか迷っている人に対して、判断の指針を与えたい。もしパラパラとめくってみて、「これはちょっと、まだ歯が立たなそうだ」と感じたならば、いったん本書を棚に戻し力を蓄えてから戻ってくる、というのは賢明な判断である。著者も言うように、本書はお世辞にも初心者に優しい書き方はしていない。だが、もし本書の値段を見て躊躇しているならば、間違いなく本書は「買い」であると背中を押したい。というのも、見かけの値段に反して、実は本書は「安い」本だからだ。その理由は、本書をとことん読み込んでしまえば、あとは中途半端なSQLの参考書など1冊も読む必要がなくなるからだ。その点で、本書は非常に「コスパ」の良い本なのだ。
本書が日本のデータベースエンジニアにとっても導きの書となることを祈っています。
Club DB2 でゲスト講師をしました
昨日 7/13 に渋谷マークウェストで Club DB2 のゲスト講師としてお話をさせていただきました。RDB の設計における物理と論理のせめぎあい（トレードオフ）というテーマで、前回以上に自由に喋らせていただきました。いつもながら運営の寛大な方針に感謝しています。ご参加いただいた皆様、お疲れ様でした。
講演では説明が足りなかった部分、また質問をいただいたことで改めて自分でも考えてみたことを、少しここで補足しておこうと思います。
- ぐるぐる系が悪いケース
まず、前提としてぐるぐる系が猛威を振るうのはバッチです。オンラインでは、そもそもループ回数が少ないので大きな問題にはなりません。講演でも、最初にこのことを明示して話を進めるべきでした。前提をはしょったせいで混乱を招いたかもしれません。
- ぐるぐる系を並列させるのはどうか
ループそのものは直列だとしても、ループ自身をジョブレベルで並列させれば、立派な並列分散になります。私の拙い理解では、Hadoop はまさにそのような仕組みです。
ただし、この並列が有効にスケールするためには、シェアードナッシング的な構成を取る必要があります。ディスクがボトルネックポイントになるケースでのぐるぐるは、どれだけループを並列させてもスケールは難しいでしょう。
- 更新処理が入るとシェアードディスクがスケールしないのはなぜか
同じデータ更新によるロック競合、というお話した問題のほかに、キャッシュの同期更新のオーバーヘッド、という問題もあります。更新が発生すれば各ノードが持っているキャッシュも更新されるため、更新処理が多くなるほどこのオーバーヘッドが多くなり、スケールしなくなっていきます。「更新処理がどの程度含まれているか」というのは業務系ベンチマークを評価するときのポイントの一つなので、皆さんも覚えておいていただければと思います。
