主要RDBMSに一つの製品で対応した設計・保守ツール
設計・保守フェーズを強力に支援するのが「SI Object Browser ER」（OBER）になる。この製品は一つでOracle、SQL Server、PostgreSQL、MySQL、DB2、HiRDB に対応している。その基礎となるデータモデリングの手法ER図はE（エンティティ）、R（リレーションシップ）でデータ構造を表現するデータベース設計における一つの定番となっている。エンティティ＝テーブルと考えれば、理解しやすいだろう。
後迫潤氏は「OBERの最大の特徴はRDBMSに接続し、ER図のフォワード、リバース、同期ができることにある」と語る。フォワードエンジニアリングによりOBERからデータベースにテーブルを作成し、リバースエンジニアリングによりデータベースからOBER上にER図を作成する。さらにデータベースとER図の相違点を調べ、自動で同期させることができる。
具体的な使い方だが、まずデータベースの設計では、OBERでER図を作成する。専用ツールなので、VisioやExcelなどより、マウスではるかに効率よくER図を作成することができる。そのER図をHiRDBなどの対応RDBMSにフォワード（テーブル作成）する。その後の仕様変更はOBER「データベース同期」機能で反映すればいい。
一方メンテナンスでは、既存のRDBMSからER図をリバース生成し、DB設計書を出力する機能が有用だ。リバース後、そのER図からメンテナンスができるようになる。例えばドキュメントが残っていないDBを引き継いだ場合でも、ER図を起こし、設計書も出せる。
そのほか、OBERには主要な設計ドキュメントの自動生成や、データサイズの自動見積、大規模DB設計を効率化するサブモデル分割など数多くの便利な機能が搭載されている。また、大規模DB設計でありがちなのが、名前の揺らぎだ。例えば商品コードが、別のエンティティでは商品ナンバーになっている、データ型の桁数が違うなど。そうした不整合が起き得ると思うが、OBERでは、それを防ぐ機能としてドメインという機能が付いている。ドメインは属性名、データ型のディクショナリであり、データベース設計においてドメインを割り当てることによりデータ型の揺らぎから解放される。仕様の変更があった場合、ドメインに適用すれば、参照しているエンティティの全てが同期する。
使い慣れたツールによりHiRDBへの移行のハードルが下がる
さらに注目したいのが、OBERのリバース、フォワード機能が、DB移行に有用だということだ。たとえば既存のOracleのRDBMSからリバース機能でER図を作成する。ツールメニューの「データ型一括変換」でデータ型を例えばHiRDB用に変換。フォワード機能でHiRDBにテーブルを生成すれば、OracleからHiRDBのDB移行が完了する。もちろん、変換不能なOracle独自の関数などもあるので、その部分は変換設定のカスタマイズにより対応する。
今回、「SI Object Browser」がHiRDBに対応したことに対する反響は大きく、関連セミナーなども盛況だ。なぜなら、ソフトウェアの料金改定で、ユーザー企業の経営層は、他のDBMSの選択肢を検討し始めている。一方で他のDBMSを使うように言われる現場のSEは混乱する。そこにユーザインタフェースをOracleとHiRDBで共通化できるObject Browserが使えるのであれば、現場の混乱も一気に解消できるからだ。
ただし、ユーザインタフェースの共通化だけで混乱を解消できるわけではない。例えばOracleのデータベースアプリケーション開発で広く利用されているPL/SQLなど、特定のDBMSに依存したユーザープログラムの移行が問題になる。この問題に対しては、ハイ・アベイラビリティ・システムズ社のDB移行ツール「SQL Ways」がHiRDBへの対応を表明するなど、アプリケーションインタフェースを共通化する動きも高まりつつある。2012年11月にリリースされる「SQL Ways」で、PL/SQLで書かれたソースコードを、ほぼ自動変換できるようになる。もはやアプリケーションのDBMS依存度も、かなり低くなっているといえる。
料金改定によるDB再考の動きがあるとはいえ、ミッドレンジ以下の情報系システムを中心にその果たす役割は不変だろう。ただ、ハイエンドの基幹系、勘定系はHiRDBなど、使い分けが進展していくと思われる。
システムインテグレータの鈴木氏は「日立のグループ力と顧客層には、現在のRDBMSにおけるシェアの数字以上の可能性を感じている」とSI Object BrowserのHiRDB対応への期待を語る。
