文書ドリブン開発 DB設計文書編：システム開発プロジェクトの現場から（25）（1/2 ページ）

開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。

» 2009年07月06日 00時00分公開

[宮本和洋，アクセンチュア・テクノロジー・ソリューションズ]

　システム開発プロジェクトにて作成される文書にフォーカスしての連載の第3回です。今回はDB（データベース）設計文書について考えたいと思います。なお、以下は筆者の私見であることをあらかじめおことわりしておきます。また、特に指定のない場合、本稿で指すDBとはRDBのことです。

高いプレッシャーと闘うDB設計者

　大半のシステム開発プロジェクトには、DB設計者としての役割を持つ方が専任・兼任の差はあれアサインされていると思います。わたしが考えるに、DB設計者は中堅からベテランのSEが担当されているケースが大半です。これはシステム開発においてDB設計の難解さと重要さが認識されているためですが、DB設計者の立場というのはその責任の重さの割には軽視されていると思えるようなことがあります。

　わたしが過去に経験したいくつかのプロジェクトにおいて、アプリケーション設計・開発者とDB設計者の間には少なからず溝ができてしまっていると感じる場面がありました。

　アプリケーション開発側の都合をDB設計者に押し付けたり、逆にDB設計の都合をアプリケーション側に押し付けたりするということを何度か繰り返すうちに、徐々に関係が悪化していくケースを何度か目にしました。そのうち、アプリケーション開発者はDB設計者の責任の重さを軽視し始め、「縁の下の力持ち」であるところの彼らに対して、声を荒げることがありました。

　システムの性能が思うように出ない場合に真っ先に見直しを検討されるのはDB設計やDB実装です。システムの開発効率や性能の責任を一身に背負わされるという常に責任の重い立場に置かれているにもかかわらず、その責任の重さを周囲に理解してもらいにくいのがDB設計者だとわたしは考えています。

　DB設計者は重い責任を課せられた「縁の下の力持ち」なのです。DB設計者を軽視することは、DB設計文書を軽視することにもつながるため、あえてこのような話を書かせてもらいました。DB設計者は常に大きなプレッシャーと闘い続けており、彼らや彼らの成果物を軽視することは、システム全体の進捗（しんちょく）や品質を危険にさらす恐れがあるということを、まずはご理解いただきたいと思います。

DB設計の特殊な位置付け

　わたしがDB設計者を「縁の下の力持ち」とたとえるのには理由があります。多くのDB設計の文書は、基本設計工程、詳細設計工程、開発工程のそれぞれの工程の中でも比較的早い段階で作成されることが一般的であり、多くの設計文書はDB設計文書をインプットにして作成されることが多いためです。DB設計文書が作成される過程には図1に示すような数々の困難が伴い、ほかの設計文書に比べるとDB設計文書作成の困難さと重要さは非常に高いものであることが分かります。

図1　DB設計文書の作成タイミングと伴う困難

　前回（「基本設計文書の質を下げる『4つの心理バイアス』」）で、V-モデルによる各工程の設計文書とテスト工程に関する対応を説明しましたが、DB設計文書については必ずしもこの法則を当てはめることができません。テスト工程以降になってDB設計に誤りがあったということが発覚することは許されず、その場合の手戻りは想像を絶するような範囲にまで及ぶためです。そのためDB設計に関してのみは、その工程内で品質を＜完全に＞担保して次の工程に進むことが至上命令となっており、「誤りがなくて当たり前」や「完成していて当たり前」という見方をされることもDB設計の特殊性を表しているかと思います。

　またDB性能に関する設計の成果はシステム稼働後しばらくたってから表れてくるという点でも、アプリケーション機能の設計とは違った意味を持っています。この側面を見てもDB設計は特殊であるということがいえます。

性能確保のためのCRUD図の工夫

　DB設計文書の中に、基本設計や詳細設計の工程で作成されるCRUD図（またはCRUD表）があります。このCRUD図は機能と実DBテーブル（基本設計の場合はエンティティ）との相関を示すものとして用いられます。このCRUD図は主にアプリケーション設計の際に作成される文書ですが、CRUD図のレイアウトに若干項目を追加することで、DB設計者がDBアクセスの性能を検討する際のインプット資料としての機能を持たせることができるようになります（図2）。

図2　標準的なCRUD図（例）

　CRUD図に施す具体的な工夫としては、機能の欄にその機能の使用頻度とエンティティの欄にデータ件数を記載することです。たったこれだけです。

得られる効果（1）　表領域の物理的な分割の検討が可能

　データ件数が多く参照頻度が高いエンティティは性能面で特に注意すべきエンティティであることになります。こういったエンティティは、例えば物理的なディスク分散によるアクセス負荷の分散や、パーティション化の検討の対象と識別することができます。表領域と物理ファイル・物理ディスクの設計はデータ件数とアクセス頻度との関係で決めるべきものなので、あえて検討専用の資料を作らずともCRUD図の工夫で十分に検討が可能になります。

得られる効果（2）　インデックス設計が可能

　エンティティに設定すべきインデックスと各機能の検索キーとなる項目をCRUD図に記入することで、インデックス設置効果の精度をさらに高めることができるようになります。参照頻度が多くて更新頻度が低く、かつデータ件数が多いエンティティに対してはインデックスを付与すればシステム性能の改善につながりますので、DB設計者はこのCRUD図を参考にしてインデックスの設計をすることが可能になります。

得られる効果（3）　テーブルのキャッシュ化検討が可能

　参照される頻度が高くかつ想定データ件数が少ないテーブルについては、あらかじめDBのキャッシュ領域に載せてしまうという打ち手の検討もすることができるようになります（図3）。