ノーコード開発のデータベースでできること・落とし穴
序章
昨今、プログラミングなしでアプリケーションを開発できる手法として、ノーコード開発が注目を浴びています。ノーコード開発ではプログラミングなしに画面やデータベースを構築できます。
高度な製品になると、単純なCRUD機能だけでなく、データを集計してダッシュボードを作ったり、その製品のローコード機能を使って、あるデータの変更を他の関連データに反映したりできます。SQLライクなクエリー言語をサポートしている製品では、クエリーを記述すれば複雑な検索機能も実現できます。
一見良いこと尽くめに思えるノーコード開発のデータベースですが、どんな仕組みで実現しているのでしょうか？データベースはシステム開発での中核技術ですが、自動生成されたものに何か落とし穴はないのでしょうか？その落とし穴は、どうすれば回避できるのでしょうか？それぞれ以下で解説していきます。
ノーコード開発でのデータベースの作り方・仕組み
ノーコード開発でデータベースを作るときは、GUIからテーブルの項目名、データ型を定義していきます。テーブル項目の入力操作が終わると、テーブルが自動的に作成されます。多くの製品では、実際の物理的なテーブルはその製品独自の方法で作成・保持しており、その物理的なテーブルと区別するために、ユーザが定義した論理的なテーブルをエンティティと呼んでいます。
エンティティが作られると、エンティティのレコードを一覧で見る画面、レコードを登録する画面、編集・削除する画面までも自動生成されます。中には、データを並べたExcelを作っておいてそれをインポートするだけで同じ作業をやってくれる製品もあります。とても簡単ですよね。
一体、どんな仕組みで実現されているのでしょうか？製品によって実現方法が異なりますが、大きく以下の2タイプに分かれます。
＜汎用的なテーブルを使用するタイプ＞
データを格納するためのテーブルや、参照関係を格納するためのテーブルを、汎用的なデータレイアウトで設けておくタイプです。ローコード製品のバックエンドのDBMS上に汎用テーブルのオブジェクトが先に存在し、その中に各種データ型のカラムがたくさん定義されています。製品のGUIでエンティティを作成すると、データ項目の型に基づいて、事前定義されたカラムが使われます。
この仕組みのメリットは、DDL操作を伴わずエンティティのデータ項目を増やせることです。デメリットは、汎用的なテーブルを論理的なエンティティでシェアする形になるため、DBMSの統計情報の精度が期待できないことです。
一般的に、DBMSのクエリオプティマイザーでは、テーブルの統計情報に基づいてクエリー実行計画を決定します。このタイプの製品の導入を検討している方は、クエリー実行計画をチューニングする仕組みがサポートされているか、という観点で評価すると良いでしょう。
＜個々のエンティティごとにテーブルを生成するタイプ＞
エンティティのデータ項目を定義したあとにデプロイ操作を行うと、DBMS上に対応するテーブルオブジェクトが生成されるタイプです。テーブル名の衝突がないように、テーブル名にはランダムな文字列が付与されます。
メリットは、個々のエンティティごとにテーブルが生成されるため、統計情報の精度が期待できることです。デメリットは、エンティティのデータ項目を増やすときにDDL操作を伴うため、データの挿入・更新などユーザのデータ変更操作と競合することです。ユーザの操作がデプロイ操作に待たされたり、タイムアウトしてエラーになったりする可能性があります。
このタイプの製品では、機能ごとにタイムアウトの時間を柔軟に設定できるかの観点で評価したり、計画停止に該当する変更を開発チームで共有したりすると良いでしょう。
いずれのタイプでも、製品がSQLクエリーを発行する際に開発者のエンティティ名、カラム名とDMBS上の物理的なテーブル名とカラム名のマッピングを行ってくれます。開発者は、DBMS上のテーブル名を意識せず、データ操作が行えます。また、テーブルの主キーはシーケンシャルな番号またはランダム値など製品固有の方法で自動的に定義されますので、開発者がキー値を払い出すロジックを実装する必要はありません。
事業企画者が押さえておくべき
ローコード開発のメリットと成功事例
ノーコードで作成したデータベースでできることは？
ノーコード開発で作成したデータベースでは、単純なCRUD操作以外にも様々なデータ操作が可能です。
- データの結合
エンティティのデータ項目を追加するときに、参照させたいエンティティを定義すると、SQLのJOIN相当のデータ操作を行えます。製品によりますが、1対多の場合は、親エンティティから子エンティティを参照させる形で設定したり、逆に子エンティティから親エンティティを参照させる形で実現したりします。
多対多の場合は、間に関連付けるレコードの主キーだけを保存するエンティティ（交差エンティティ、もしくは連関エンティティと呼ばれます。製品独自の呼び方もあります）を定義して、それぞれのエンティティから１対多の相手として設定します。こういった設定を行うだけで、自動生成されたエンティティのデータ表示画面からその参照先エンティティを表示する画面へのリンクが表示されるようになります。 - データ集計とダッシュボード画面
SQLのGROUP BY句による検索レコードのグループ化や、COUNT関数などグループごとの集約演算も行えます。ノーコードで対象カラムや適用したい演算の関数を選択する、またはローコードで集計クエリーを記述するだけです。
ダッシュボード画面の作り方は、どの製品でも大枠は同じです。GUIで、ダッシュボード画面のレイアウトを定義して（どの位置にどの集計結果の表、またはグラフを表示するか）、それぞれの集計結果の表に表示する項目と集計結果のカラムを対応付けていけば出来上がりです。 - ゴミ箱
ノーコード開発のデータベースでは、データの登録・更新操作はもちろん、エンティティの結合やレコード集計など複雑な問合せも出来ることが分かりました。では削除操作はどうでしょうか？ローコード製品によってはゴミ箱機能が実装されているものもあります。自動生成した画面でデータを削除すると、そのデータは論理的なゴミ箱に移動されます。ユーザが誤って削除してしまった場合でも、ユーザ自身の手で復帰できます。 - データの副問合せ
ローコード製品では、SQLライクな言語で副問合せもサポートしている製品もあります。ノーコードで実現できない複雑な問合せ結果を表示する機能も、ローコードでクエリーを記述するだけで実現できます。
落とし穴は？
ここまでで、ノーコード開発のデータベースについて、ローコードを記述すればかなり複雑なことまで出来るとお分かりいただけたのではないでしょうか。しかし、落とし穴もあります。ノーコードで作った画面では、その製品の仕様でSQLが発行されます。性能面をあまり考慮せず設計した場合では、性能要件を満たせないケースもあります。以下にありがちな要因と解消策を挙げます。
＜インデックスが設定されていない＞
参照先エンティティとの結合に使われるカラムに対してはローコード製品が自動的にインデックスを生成してくれます。しかし、他のカラムについては開発者自身で判断してインデックスを生成するかどうか指定する必要があります。
インデックスを設定していないカラムが画面の検索条件で使用された場合、DBMSがそのエンティティのすべてのレコードから目的のレコードを探しに行って、クエリーが低速になってしまいます。性能で困ったら、まずはインデックスを設定したか確認してみましょう。
＜不必要なレコード、カラムを取得してしまう＞
開発環境では中々気づきにくい症状ですが、画面表示に使わないレコードやカラムを大量に取得すると、クエリーが低速になったり、プラットフォームのメモリ領域が圧迫されて他の処理が遅延したりします。
色々な処理に使われる部品にこういった処理を設計することがありますが、テスト工程や運用開始後に性能トラブルが発覚するケースもあります。大規模にトランザクションデータを保存するエンティティの処理設計では、データ取得件数やカラムを最小限に絞れないか検討すると良いでしょう。
＜クエリーの発行回数が多すぎる＞
フローチャートで多くの処理を作っていく製品の場合、forループ要素の中でSQLを実行してしまうと、ループ回数が多い状況では処理時間が増加しがちです。エンティティを結合して必要なデータを1度のSQLですべて取得してループの中で扱うようにするなど、処理の見直しが解消策となります。
＜設定したはずのインデックスが効いていない＞
複雑なクエリーにありがちな症状です。DBMSのクエリオプティマイザーがインデックスを使用しないクエリー実行計画を選択してしまっています。原因としては、SQLでインデックスカラムに否定条件を指定していたり、インデックスが断片化していたり、統計情報が古いことなどが考えられます。
解消策として、ノーコードで作らずローコードまたプロコードによる処理のチューニング、インデックスや統計情報の最新化などが挙げられます。
とりわけ、大規模なシステムにローコード製品を適用する場合には、バックエンドのDBMSのチューニングテクニックがどれだけサポートされているかの観点で評価すると良いでしょう。
iPLAssはその製品のひとつです。大規模なローコード開発の現場で起こりがちな性能トラブルに対して、実践的な機能を提供しております。ローコードのクエリーにヒント句を指定してクエリー実行計画を変更する機能、複合インデックス、パーティショニングなどDBMSに元々備わっている仕組みを使うための機能、汎用的なテーブルと個別エンティティ専用のテーブルを併用する機能、データアクセスに関するメトリクス計測機能などです。
まとめ
ノーコード開発で作成したデータベースでは、そのデータベースに対して単純なCRUD機能だけでなく、結合や集計、副問合せといったデータ処理も行えます。データベースの性能に関する落とし穴と、その解消策もご紹介しました。
ノーコード開発は、上手く適用すれば非常に生産性が高い開発手法ですが、システムは作って終わりではなく、その後も安定的な運用が求められるものです。読者の皆様におかれましては、本記事で挙げた落とし穴を回避して、システム開発にご活用いただければ幸いです。最後までお読みいただきありがとうございました。
当サイトでは、ノーコード開発ツールやローコード開発プラットフォームを利用し、業務システムの開発を効率化したいエンジニアの方や、会員サイト構築などの新規事業の目的を達成したい方へ、ダウンロード資料をご用意しております。ぜひ資料をご覧いただき、ご活用ください。