＠IT読者調査結果：データベース編（2）
〜データベース設計の現状と課題とは？〜
小柴 豊＠IT マーケティングサービス担当
2005/3/15
リレーショナルデータベース（RDB）が情報システムの中核としての位置付けを固める一方、アプリケーション開発の領域では、オブジェクト指向アプローチの台頭が目覚ましい。そうした中、データベース設計の手法はどのように変わっていくのだろうか？ Database ExpertフォーラムとXML & SOAフォーラムが合同で実施した読者調査の結果から、その現状と課題を紹介しよう。
■設計業務にかかわる人は全体の8割
まず今回の調査回答者が、情報システムの設計業務にどのような立場でかかわっているのか尋ねた結果が図1だ。全体の84％が何らかの設計業務に従事している中で、「アプリケーションからデータベースまで、一貫して設計している」人が44％に上っている。ではシステムの複雑化が進む現在、読者はどのような手法で設計業務を行っているのだろうか？ 続いて検証していこう。
 |
| 図1 設計業務へのかかわり方 （N=218） |
■設計手法の4割はDOA
次に読者が現在かかわっているシステムの主な設計手法を尋ねたところ、設計業務従事者の44％が「一貫してデータ中心アプローチ（DOA）で設計している」と答えており、「一貫してオブジェクト指向（OO）で設計」（18％）を大きく上回った（図2）。この結果を図1の業務内容別に見ると、アプリケーション側の設計者ではOO、データベース設計者の間ではDOAの採用率が、それぞれ高い傾向にあった。RDBのデータ構造と親和性の高いDOAは、現在もデータベース設計者に最も活用される手法であり続けているようだ。
 |
| 図2 現在使用している設計手法 （設計業務従事者 n=183） |
■DOAとOOの使い分け方法
ところで図2を見ると「必要に応じてDOAとOOを使い分けている」設計者が21％に上っており、複数設計手法の共存も珍しくないことが分かる。そこで読者にDOAとOOの使い分け実態を尋ねたところ、最も多く寄せられたのは“n階層アプリケーション設計時の層別使い分け”に関するコメントだった。
- ビジネスロジックはクラス図・シーケンス図を作成。テーブル設計はメンテナンスの関係から正規化を行い、ER図を作成
- Web層およびビジネスロジック層の設計にはクラス図を使い、データベース設計ではER図を作成している
最近のシステム開発では、Javaなどのオブジェクト指向言語によるアプリケーション＋RDBという構成が標準的であることから、“プレゼンテーション層＋ロジック層はOO、データベース層はDOA”という使い分けが広く行われているもようだ。
またそれ以外に、上流工程／下流工程といった開発工程単位の使い分けに関するコメントも寄せられた。上述した層別の使い分け方法が下流工程内でほぼ共通していたのに対し、こちらは、
- ERでデータ設計をして、ユースケースで業務分析をしている
- 要件定義段階では、ユーザーの理解のしやすさを考慮してER図にて検討し、実際の設計段階からはUMLで設計を行っている
というように、さまざまな使い分けのバリエーションが見られた。要求定義などの上流工程では、エンドユーザーとの対話が求められるだけに、相手に応じた柔軟な設計手法の選択がなされているようだ。
■利用しているデータベース設計ツール
では読者はデータベース設計の際、どのようなツールを利用しているのだろうか？ 現在の利用状況を見ると、トップに挙げられたのはマイクロソフトの「Visio」であった（図3 青棒）。Visioは汎用的なグラフィック製品だが、気軽にER図やUMLをモデリングできる点が、多くの設計者に支持されているようだ。
参考：情報マネージャ／ITアーキテクト編（2） 図6「UMLモデリング・ツールの利用状況」
 |
| 図3 データベース設計ツールの利用状況（DB設計者 n=120） |
一方データベース設計専用ツールとしては、「Object Browser ER」「ERwin Data Modeler」「ER／Studio」の順に利用率が高くなっている。読者が利用を予定／検討している製品（図3 黄棒）では、これら専用ツールの利用意向がVisioと同等以上のポイントを示しており、今後はより高機能なデータベース設計ツールへの需要も高まりそうだ。
■O／Rインピーダンスミスマッチ問題の認識状況
さて上述したようなオブジェクト指向開発とRDBが混在するシステムでは、オブジェクトとリレーショナル・データの構造の違いによる不整合（O／Rインピーダンスミスマッチ）が発生するといわれている。そこでこの問題の認識状況を尋ねたところ、「マッピングの煩雑さなどに工数がかかり、大きな問題になっている」「ある程度問題にはなっているが、技術的に克服している」を合計した問題認識率は、設計業務に携わる読者の28％となった（図4）。
全体的には大きな問題といえないレベルだが、これを図2の設計手法別で見ると、オブジェクト指向設計者における同問題の認識率は46％に上っていた。今後OOによる設計が普及するにつれ、O／Rインピーダンスミスマッチ問題はより注目されていくものと思われる。
 |
| 図4 インピーダンスミスマッチの問題認識状況 （設計業務従事者 n=183） |
■O／Rインピーダンスミスマッチの解決手段とは？
ではO／Rインピーダンスミスマッチ問題を認識している設計者は、その解決にどのような手法やツールを利用しているのだろうか？ 該当者に尋ねた結果、現在は「EJB Entity Bean」およびオープンソースのO／Rマッピングフレームワーク「Hibernate」が、ほぼ同率で上位に挙げられた（図5 青棒）。 ちなみに「そのほか」との回答が26％でトップとなったが、その内容を見ると“自作／自社製のマッピングフレームワーク”が大多数を占め、O／Rインピーダンスミスマッチの解消に手数のかかる現状が表れていた。こうした現状を改善するためにも、POJOベースで開発の容易性を追求する EJB 3.0をはじめ、今後のO／Rマッピングツールの進化に期待したい。
 |
| 図5 O／Rマッピング手法・ツールの利用状況（ORM問題顕在層 n=58） |
|
|
||||||||
最新記事
 |
|
|
|
|
