RDBMS再入門（WEB+DB PRESS vol.11）を読んだ

同誌vol.33で「構造化プログラミング入門」という記事を読んで（まだ全部読んでないけど）いいこと言ってるなーと思ったのでこっちも読んでみた。ウトウトしながらもがんばって読み切ったのでとりあえずまとめておく。

心得編

そもそもなぜRDBMSというものが使われるようになったのか。そのメリットはなにか。
一般的に言われるのは、

標準化されたSQLの存在

データにアクセスするためにはSQLだけ憶えればいい。

物理情報と論理情報の分離

データがどのように格納されているかを意識する必要がない。そのデータをどうやって識別するのか（テーブル名やカラム名）を知っていればいい。

データ整合性保持の容易性確保

データの一貫性など。

複数ユーザによる同時利用の実現

あるユーザーがDELETE中に他のユーザーがSELECTしたらどうするかとかを管理してくれる

というようなことだが、本当のメリットはこのようなプログラミングに直結した部分での利便性ではなくて、もっとビジネス的なことにある。RDBMSはビジネスのあり方を大きく変える。そのそもRDBMSはビジネスシステムの中でのデータ活用という観点から考えられた仕組み。大事なのはプログラムよりもむしろそれによって処理されるデータの方。一連の業務プロセスのそれぞれにおいて必要なデータを適切に提供できることが大事。それこそがRDBMSの意義。

設計編

データ中心アプローチ(DOA)って単に「データベースの設計を効率的に行うための方法」のことではない。確かにデータ中心アプローチではデータベースの設計を重視するがそれは一部にすぎない。

• データ中心アプローチではまずデータの構造に着目
• データを整理するための考え方が「正規化」
• データにはライフサイクルがあってその状態は大きく４つ。CRUDと呼ばれる。create/reference/update/drop
• そう考えるとデータ構造とそれに対してCRUDを行っている処理との間でテーブルを作れる（処理をまとめたものとしてトランザクションでもいい）
• そうするといろいろなトランザクションで同じデータ構造に対して同じ処理を行っているものってのが明らかになって、無駄なものを排除できる。これは言わばトランザクションの正規化
• この考え方をさらに上位にまで拡げると、
• 処理をおこなうためのトリガーとなるI/Fの正規化
• それを行う役割（ロール）の正規化
• などを考えることができ、こうして組織の役割を見直していくことがリストラクチャリングと呼ばれるもの

これがデータ中心アプローチであり、データ構造の正規化ってのはその出発点。
データ構造を見いだすためのアプローチとしてユーザーインターフェースから考える方法がある。つまり「どのようなアウトプットが求められているのか」がわかればデータ構造が決まってくる。教科書的なデータ構造が必ずしも正しくはない。売り上げ伝票1つをとっても、値引き、得意先への特別価格、期間限定の値引きなどを考えに入れていくと、業務によってデータ構造が変わってくる。
あと、
インデックス超大事。

実装編

SQLがどういうものかを知ることが大切。SQLはインタプリタでありバッチ処理。命令に対して、文法は正しいか、オブジェクトは存在するかなどを確認しなければならない。何気なく書いているSELECT文も実際には多くの内部処理の固まりであるということを認識する。SQL文がどういうことを行うのか、EXPLAINで確認。いちいちフェッチしてUPDATEとかするんじゃなくて副問い合わせを使う。ストアドプロシージャを使おう。

• • -

いい勉強になりました。ただストアドプロシージャはどうだろう。5.0以降を使うことがないからというのもあるけど、この先も使うのかは不明だ。MySQLの場合、サブクエリは4.1から、ストアドプロシージャは5.0からです。

• • -

MySQL :: MySQL 5.6 リファレンスマニュアル :: 13.8.2 EXPLAIN 構文
MySQL :: MySQL 5.6 リファレンスマニュアル :: 13.2.10 サブクエリー構文
http://dev.mysql.com/doc/refman/5.0/en/stored-procedures.html

• • -

Web+DB press (特別総集編)