Web+DB press (Vol.21)

Web+DB press (Vol.21)

最新テスト手法調査隊

１章では、テスト手法や種類が簡単に整理されていて分かりやすい。２章では、テスト対象に合わせたテスト自動化やメリットの紹介。３章は、JUnit入門という感じで、ちょっと浅いかな。４章は、受け入れテスト自動化でJameleonの紹介。これは知らなかったので参考にはなったが、使ってみようとまでは思わなかった。しばらく様子見かな。５章は、JMeter再考という題名だが、入門といった感じ。６章は、不具合管理システムとして、Scarabの紹介。けっこう具体的に記述されていて参考になる。全体として、テスト初心者には大いに参考になる記事だと思う。

Eclipse3.0がやってきた！

１章は、最近の動向で、あまり追いかけてなかったので参考になった。２章以降は、3.0の新機能の紹介で、既に使っているのでだいたいは知っていたが、それでも知らなかった部分もあり、一読の価値はあった。

データベース設計の基礎知識 １章 DB設計者が抱える悩みの３つの原因

10人未満程度のプロジェクトでDB設計をするのは開発チームで1人になり、しかもシステム全体への影響が大きいから未経験者には任せづらいから、経験を積むことが出来ない。しかし、急ぎの場合は未経験者が担当せねばならず、それがパニックにつながるそうだ。本特集は、そうなった場合に何をすべきかを提示してくれている。いつもながら、はぶさんの文章は最初の引き込みが巧い。私は幸いな事に、いままで関わった開発のほとんどのDB設計を担当しているので、けっこうDB設計の経験は積んでいる方だと思います。そろそろ後輩にDB設計のノウハウを伝授すべく、少しずつDB設計を任せるようにして、それをアドバイスするような役割になろうとしていました。私の場合、OJTを通して教えることは出来るのですが、言葉として伝えるまでには至っていないので、本特集はそれを言葉だけで伝えることが出来ていると感じたので、見事なものです。ちなみに、今年度の組織変更で、OJTでアドバイスすることも出来なくなったのが残念ですが、この特集記事を読ませれば良いか、などと思ってしまいます。

データベース設計の基礎知識 ２章 エンティティの見出し方

エンティティをリソース系とイベント系に分類すると言うことで、T字型にも書いてあったことです。さらに、6W3Hで整理することで、ビジネスモデルとデータモデルの整理ができるそうで、このように明示してあると良いと思いました。私もDB設計で悩むと、このように整理するのですが、それが経験からそのようにしていただけで、6W3Hとして言葉にしていませんでした。次に、漏れている事に気が付くのは難しいという話があります。これに対しては、DB設計者も業務要件を理解する必要があるそうで、まさにその通りだと思います。私は、要件分析者とDB設計者は同じ人が担当すべきと思っていて、それで今までは巧くこなしてきたけれど、システムの規模が大きいと難しいかなとも思っています。ある程度の規模の開発をやってみたいものだ。

データベース設計の基礎知識 ３章 キー設定の仕方

キーとコードは違う物で、行の特定にはアイデンティファイア（ID）を使えという内容。そうそう、これは私も言葉として常日頃から言っています。商品コードとかをPRYMARY KEYに設定して、それで行を特定するとか、外部キーとして他のテーブルから参照するとかありますが、商品コードのコード体系が変わったら影響範囲が大きすぎるのです。それらをSEQUENCE型か何かのIDにして、商品コードは単なるカラムか別テーブルに放り出して、ただのアクセスパスにした方が仕様変更に強いです。私の場合は、オブジェクト指向を知ってからRDBMSを知ったので、行の特定に商品コードなど業務に関わるデータ、つまり変更される可能性があるデータを使うのが信じられなくて、システム内のみで使用する専用のデータ、つまりIDを使うのが普通だと思っていました。昔、SEQUENCE型のIDではなくて、商品コードを使えと命令された事があり、変更される可能性があるコードを主キーには出来ないと言ったところ、それは業務分析が出来ていないからだ！と返されて、それに反論することが出来なかった事がありました。それでもやはり、自分で決められるときはIDを使っています。未来永劫、変更されないとの確約書でも貰えれば別ですが。次に、諸口のオール9問題ですが、これもIDで行を特定できれば、コードが同一のオール9になっても、それぞれを区別できると記述されている。私の場合も同様なのですが、コード値をオール9ではなくてnullにして、UNIQUE制約（NULLは許容）を使っています。プログラムにバグがあったとしても、データベースの整合性は保証しておきたいので、制約はかなり強めに定義しています。

データベース設計の基礎知識 ４章 業務システムにおける正規化

重複の排除ということで、売上明細の正規化について説明してある。これって、DBだけを見ていてはダメで、要件を見る必要があります。記事では、販売時値引きや総額値引きがある場合が例として記述されています。実際の開発でも同様で、どのような情報を引き出したいのかによって、テーブルの設計が変わってくるし、その上で重複の排除をしておかないと、データに一貫性が無くなる可能性が入り込むわけで、カットオーバー後に困った事になりかねません。ここら辺は本当に難しいし、経験が必要だと思っています。次にステータスが変わるような業務のDB設計として、ステータスごとにテーブルを分けると記述されています。GOFのStateパターンと考えれば特に違和感は無いのですが、DB設計でこのように記述されているのを見たのは初めてかもしれません。次に、従業員と組織のような場合、間に所属テーブルを入れておけば組織変更に耐えられると記述されています。アナリシスパターンの組織関係を知っていれば直ぐに納得するのですが、なかなか受け入れられない人も多いように見受けられます。次に、23種類の単価があったと記述されており、そこまで多かった事は無いのですが、やはりそういうことは多くあり、それを整理するのも大変です。こういうのって、お客様にとっては常識だったりするので、常識を説明してもらうのは実は難しいのです。こういう事もDB設計をする上では必要なことなので、DB設計の担当者は要件分析もしなくてはならないと思っています。だから難しいし、やり甲斐もあるのかと思います。

データベース設計の基礎知識 ５章 DB設計の手順

実際にどのようにDB設計を行うのかの手順が記述されていて、とても参考になります。と簡単に書きましたが、本文を読んでのお楽しみってことで。私は記述されていることは一通り行っていると思いますが、このような手順にはなっていなかったので、整理されていて参考になった。こういうのを見るとパターン名が欲しくなってしまうかも。次に、計画系のシステムではバージョン管理があるので、それなりの検討が必要とのこと。私は業務系と研究系のシステム開発でRDBMSを使ってきたのですが、研究系ではバージョンをまたがった、または制限した検索やナビゲーション、履歴の追跡などが必要でかなり苦労したのですが、そういうのも計画系と言えるのかな。また、分析系の設計についても簡単に紹介されていますが、詳細は参考文献を参照せよとのこと。けっこう興味があるので、明日にでも買いに行ってみよう。

データベース設計の基礎知識 全体を通して

DB設計をやるのなら読むべし。良記事。ところで、Vol.11を無くしてしまい、再購入しようにも品切れ状態。そろそろ過去記事CD-ROMとか出して欲しい。

オープンソースではじめるOLAP実践講座

OpenOLAPというオープンソースがあるのか。ちょっと試してみたい。以前は、こういうのは作り込んでいたので、なるべくなら作らずに済ませたい。

顧客ウケの良いGUIの作り方 １章 Flash時代のGUI概論

Flashに特化しているわけではなくて、GUIの一般論って感じです。画面の目的、負担を強いない、やりたいことができること、といった内容が記述されています。私は研究系の仕事もするのですが、そちらのお客様は認知科学方面の方が多くて、こういうGUIも研究対象になっているようです。その関係で、いろいろ話を聞いたりする機会もありまして、だいたい本章と同じようなことを言っています。で、これらの内容は普通に満たさなくてはならなくて、更にその先、使っていて感動を覚えるようなGUIにするためには、どうすべきかなどを言っています。私は自分が使うとしたら、ストレスを感じないでサクサクと操作できることに気を使っていて、その内容は本章とほぼ同じだったので、ちょっと安心しました。

顧客ウケの良いGUIの作り方 ２章 Java,PHPにおけるUI設計の実践テクニック

Webアプリにおける、リストの並べ替えとフレームを使った選択方法、長い処理、ページ遷移について、どのように実装したらよいかが記述されている。これ全部、実案件で使ったことがあるので目新しさは無かったのですが、まだ経験の無い人には参考になると思う。

徒然PostgreSQL散策

今回はネットワークプログラミングということで、ソケット関係の話題。実はちょっと苦手な分野だったので、参考になった。