「先輩，もういいですかぁ」
「うーん。まだダメ。これじゃ後々面倒が起きる」
「ふう。早く実際の作業に移りたいです」
「でも，やるべきことをやっておかないと後で苦労するよ」
「はーい。でも，なんでこんな面倒なこと考えなきゃいけないんですか」
「だから，後で苦労するからって言ったじゃない」

　データベースを使うアプリケーションを開発する際の一つのヤマが，最初に訪れるデータ設計である。データベースはデータをうまく管理するために使うものだが，最初のデータ設計で失敗すると手間ばかりかかってまともに管理できなくなってしまう。データベース・アプリケーションの大雑把な作成手順を見ても分かるが，実際にシステムにマッピングしてデータベースの定義を始めるまでにクリアすべきカベがいくつもある（図1[拡大表示]）。

図1●データベース設計の大雑把な流れ
データを中心に考えるという点では非常にオブジェクト指向的である。しかしデータ設計とオブジェクト指向分析/設計を明確に分ける指針がないと，混乱する可能性はある。
図2●E-R（エンティティ-リレーションシップ）図の例
記事データベースを題材にした。

　データ設計でまず大事なのが，データの識別である。システム化に必要なデータは何なのか。実際の業務に照らし合わせて導出する作業である。この時点では，データベースにうまく放り込むための項目などは考えなくてよい。あくまでもシステムの論理的なレベルで必要なデータを見つけ出すことが肝心である。

　次に取り出したデータを分析して，データの依存関係などを導き出す。ここで何がデータの入れ物（エンティティ）となっているか，エンティティ間の関係は何か，などを分析する。よくこの段階から使われるのが，「E-R（エンティティ-リレーションシップ）図」である（図2[拡大表示]）。この次の段階で，後述する「正規化」や実装が行われていく。正規化の作業は，E-R図を詳細化していくことで実施することが多い。

　このようなデータベース開発を中核に据えた開発手順を「データ中心アプローチ（DOA：Data Oriented Approach）」と呼ぶ注1）。このようにデータを識別する作業は，オブジェクト指向に基づく開発に似ている面がある。オブジェクト指向においても，まず識別するのはデータである。そしてそのデータの関連を分析していくのが基本だ。ただオブジェクトがすべてのデータに着目するのに対して，DOA的なアプローチではもう少し大きな単位のデータに着目する。

データの方がプロセスより安定している

　オブジェクト指向もDOAも，データに着目する点では同じである。なぜデータを中心に据えるかというと，データの方が変更に強いからだ。つまりデータそのものは時々刻々変化するが，必要とされるデータの構造自体はあまり変わらない。例えば伝票の処理は，組織が変わると回送する経路が変わる。しかし，伝票に記入すべき情報は大きく変わらない。このことはシステムでも同様である。消費税が付与されると処理は変えなければならないが，「消費税分」のデータは必ずしも必要ない。計算可能な量だからだ。しかも消費税は税率が変わる可能性がある。これをデータとして保持するのは得策ではない注2）。

　またデータベースは，ロジックとは独立して存在している。だからロジックの影響を受けにくく，保守が容易である。しかしこの利点は，データを中心に考えて定義してやらないと生きてこない。

　このためには，データベースに対する操作はあらかじめ定義しておき，データベース側に持たせた方がよい。これが「ストアド・プロシジャ」である。こうすることによって，データベースが担当する処理と，それ以外の処理を明確に分けることができる。データベース全体を独立した存在として考えれば，大きな粒度のオブジェクトと考えられる。定義したストアド・プロシジャの手続きが，メソッドということになる。その意味でも，データベースを中心とした開発はオブジェクト指向的である。

　ただ注意しておきたいのは，オブジェクト指向分析において定義したクラスがそのまま，データベースに置き換えられるとは限らないことだ。つまりオブジェクト指向分析の結果を単純にリファインしていっても，データベースに格納するのに適切な形になってくれるとは限らないのである。その意味では，別途データ設計をすると考えるべきだろう。

（北郷　達郎、八木　玲子）