とは

データベース設計書を
徹底チェックし、
設計ミスを洗い出す

画期的ツールです！（特許取得済み）

ODMを選択するべき 5つの理由

• 1
  
  「人間の限界」には、AIの力で！
• 2
  
  「運用でカバー」の産む隠れコスト！
• 3
  
  「性能問題」はテーブル設計に起因する！
• 4
  
  SQL標準を優先する！
• 5
  
  サインアップするだけの簡単導入！

• 「人間の限界」には、AIの力で！

  人間は単調な作業が苦手です。エンジニアは特にそうです。 テーブル名やカラム名にスペルミスがないかどうか、スペルチェッカーが使えれば良いのですが、DB設計には専用のスペルチェッカーが必要です。 既存のツールは、命名規則等のチェック規則を設定しなければ使えません。 正直面倒なので、導入するのにハードルが高く、実際普及していません。 ODMは、設定なしで即座に使える。あなたのDB設計が確実に向上します。

  品質改善の仕組み: スペルチェック。命名規則の遵守のチェック。型のブレのチェック。正規化のチェック。アンチパターンのチェック。いずれも問題を指摘するだけでなく、具体的な修正案を提案します。GitHub Copilotのようなコーディング支援だと、なんとなく良さそうなコードができてしまい、ますますケアレスミスに気付きにくくなります。ODMはデータベース全体を見渡して、人の目では気付きにくいところを徹底チェックします。

  

• 「運用でカバー」の産む隠れコスト！

  納期を厳守するために、DB設計上の課題は見過されがちです。 製造フェーズに入ってから設計ミスに気付いたとして、遡って直せますか？ 気付かなかったフリをしたりしませんか？ 運用が始まったシステムのデータベース設計は、なかなか修正されません。 延々と払わされる隠れコスト、「運用でカバー」を防ぎましょう。 ODMがサポートします。

  積み残しを防ぐ仕組み: リーンの原則にある「品質を作り込む」ことが、後々の仕事を減らす重要なポイントです。ODMは非常に高速なので、開発の流れを阻害しません。最新の成果物を、1日に何度でもチェックすることができます。ODMの指摘事項をすべて検討することで、属人化することなく、品質を作り込むことができます。比較的レベルの低い人に、テーブル設計の改善をアサインできるので、レベルの高い人をより高度な要件定義や設計業務に集中させることができます。

  

• 「性能問題」はテーブル設計に起因する！

  運用がはじまると「性能問題」に直面することがよくあります。 プロが遅いクエリを分析すると、そもそもテーブル設計がよくない、と気付く。しかし、これを直すとなると、かなりの費用になってしまう...運用開始後の修正はいつでも頭の痛いことであり、システム障害の原因となることもしばしばです。 どうすれば良いのか？最初から正しい設計をすべきです。 ODMは、問題を指摘するだけでなく、プログラマに代替案を提示します。 性能を劣化させないシステムを、ODMで。

  正しい設計は性能を守る: 性能劣化の原因となるのは「不必要なSELECT」「場当たり的なインデックス」「テーブルサイズが大きくなったときのことを考えていない設計」などにあります。「このテーブル、大きくなったときのこと、考えていますか？」という単純な問いがあるだけで、そうか、そうだった、と気付けることがある。ODMは、テーブル名やカラム名から、性能のボトルネックになりそうなテーブルの存在を察知し、注意を喚起します。もちろんインデックスや外部キーについても。

  

• SQL標準を優先する！

  特定のDB製品に特有の機能を使ってしまうと、いわゆるベンダーロックインの状態となります。 SQL標準を守って、製品に特有の機能を避けることは、ベンダーロックインを避けるだけでなく、堅実な設計を導入する効果もあるのです。 DB製品特有の機能を避けるためのツールはほとんどなく、代替手段まで提示できる製品となるとODM以外にはありません。

  ベンター中立なODM: ODMはOracle、SQL Server、DB2、MySQL、PostgreSQLの文法をサポートしています。Optimaはどの製品とも資本関係がなく、中立な立場からアドバイスします。SQL標準を優先し、ベンターロックインされない方法をご提示いたします。また、あえてDB製品特有の機能を使う場合にも、効果的な利用方法や、万一の場合にそなえた「ポータビリティの確保の方法」も提示します。

  

• サインアップするだけの簡単導入！

  Datadogを使ったことのある方なら、導入が簡単であることの重要性をご存知のはず。 データベース設計に関しても、さまざまなツールを選定し、設定ファイルを書き、利用者マニュアルを書いたり、Dockerfileを書いたり...といった準備が必要だと、その後も、設定ファイルやマニュアルのメンテナンスが必要になります。 ODMなら、サインアップして、設計書をアップロードすれば、即座にレポートが得られます。

  ODMの簡単さ: たとえばSQLFluffのようなSQL Lintツールは、導入、設定ファイルの整備、チーム内での使い方の統一等、実際の運用にあたって考えるべきことや、大小のタスクがどうしても必要になります。ODMは、本当に簡単なので、チームの中に1人担当者を決めるだけでも即座に運用可能になりますし、メンバー各自で使うのでも何の問題もありません。（GitHub Actions等のCI/CDへの組込みもサポート予定です。）