コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第215回　セマンティックデータモデルに向けたSQL拡張（パート1）

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python Power Platform 最新技術動向 生成AI Docker Kubernetes

第215回　セマンティックデータモデルに向けたSQL拡張（パート1） (中井悦司) 2026年2月

はじめに

　今回からは、2026年に公開された論文「Semantic Data Modeling, Graph Query, and SQL, Together at Last?」に基づいて、現在Google社内で利用されている、セマンティックデータモデルに対応するSQL拡張を紹介していきます。今回は、セマンティックデータモデルの現状と課題を説明します。

セマンティックデータモデルの現状と課題

　リレーショナルデータベースに格納されたデータをビジネス視点で分析するためのBI（ビジネス・インテリジェンス）ツールの多くは、一定の検索パターンをSQLクエリーのテンプレートとして用意したり、あるいは、分析に必要なデータだけを事前に抽出した「ビュー」を用いるなどの方法で、利用者自身がSQLクエリーを記述することなく、データを分析できるように作られています。この背景には、ビジネス視点での分析に適したデータ構造と、リレーショナルデータベースに格納されたテーブル単位のデータ構造の乖離という問題があります。
　リレーショナルデータベースの正規化されたテーブルは、データの整合性を担保することに最適化されている一方、ビジネス視点で求められるデータを取り出す際は、多数のテーブルを結合・集計する必要があり、複雑なSQLクエリーを記述することが求められます。そこで、BIツールでは、よりビジネス視点に適合したデータ構造を事前に用意することで、複雑なSQLクエリーを用いずにビジネス視点でのデータ分析ができるようにしています。このような「ビジネス視点に適合したデータ構造」をセマンティックデータモデル（意味的データモデル）と呼びます。
　ただし、SQLクエリーのテンプレートやビューによるデータ分析は、事前に想定された特定パターンの分析のみに対応しており、このようなパターンに当てはまらない分析が必要な際は、BIツールに頼らない、SQLクエリーによる分析が必要になります。このようなBIツールによる分析の簡便さとSQLクエリーによる分析の複雑さのギャップには、次のような課題が隠されています。

BIツールで用意されたセマンティックデータモデルは簡単に利用できる一方で、そのようなデータモデルを用意するには、ビジネス側のドメイン知識を持った専門家とSQLクエリーの専門知識を持ったエンジニアが協力する必要があり、相応の時間とコストがかかる。
セマンティックデータモデルの定義方法はBIツールごとに異なっており、BIツールごとに作成する必要がある。
事前に用意したデータモデルで対応できない分析を行う際は、SQLクエリーによる分析に戻る必要があり、コストをかけて用意したデータモデルの恩恵が受けられなくなる。また、SQLクエリーによるビジネスデータ分析は、専門知識を持ったエンジニアにも容易ではない。

　このような課題を解決する方法として、大規模言語モデル（LLM）を用いて、自然言語で記述した分析内容から、それに必要なデータを取得するSQLを自動生成するというアプローチ（NL2SQL）が検討されることもあります。しかしながら、前述のように、リレーショナルデータベースのデータ構造は、ビジネス視点でのデータ分析からは乖離しており、LLMを用いたとしても適切なSQLクエリーを生成するのは容易ではありません。適切なSQLクエリーを生成するには、それぞれのテーブルに格納されたデータのビジネス上の意味付けやテーブル間のデータの関連を記述したメタデータ（スキーマ）を用意する必要があり、結局の所、セマンティックデータモデルを用意するのと同等、もしくは、それ以上の労力が事前準備にかかります。

SQLの拡張によるセマンティックデータモデルの構築

　このような課題を解消する試みとして、Google社内では、SQL構文を拡張することで、「SQLクエリーによる柔軟な検索が可能なセマンティックデータモデルを段階的に構築する」という手法が取られています。元々、Google社内では、GoogleSQLと呼ばれる独自のSQL構文が利用されており、これは、SpannerやBigQueryなどのGoogle Cloudで提供されるデータベースでも利用されています。GoogleSQLは、構造化データを柔軟に取り扱う仕組みが用意されていますが、これをさらに拡張して、ビジネス視点での分析で必須となる複雑なテーブルのジョインやビジネスロジックに基づいた計算処理をより簡単に記述できるようにしています。このような拡張を説明する準備として、ここではまず、既存の構造化データの取り扱いについて説明しておきます。
　GoogleSQLでは、Protocol BufferやJSON形式のネストした構造化データをARRAY型（同じ型のデータの配列）やSTRUCT型（辞書型のデータ構造）のカラムに格納できます。これらのデータには次のような方法でアクセスします。

・ネストしたデータの特定のフィールドを指定

SELECT object.field1.field2

・ARRAY型データを展開

FROM UNNEST(object.field.array_field)

　UNNESTで配列データを展開した結果は、該当データを展開した状態で保持する別テーブルとのINNER JOINを実行した結果に一致します。つまり、構造化データを使用することは、本来は正規化された別テーブルに保持されるデータをビジネス視点で意味のあるデータ構造として1つのカラムにまとめていると考えられます。冒頭の論文では、このような観点から、既存のSQLクエリーとの後方互換性を保ちながら、よりビジネス視点でのデータ分析が容易にできるようにSQL構文を拡張していく方法が紹介されています。

次回予告

　今回は、2026年に公開された論文「Semantic Data Modeling, Graph Query, and SQL, Together at Last?」に基づいて、セマンティックデータモデルに対応するSQL拡張に関連した、セマンティックデータモデルの現状と課題を説明しました。次回は、論文内で議論されている具体的な拡張の内容を説明します。

Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡

IT研修はCTC教育サービス

AWS　Microsoft Azure　生成AI

Python　Power Platform

コンテナ　その他（研修を分野から探す）

前回のコラム
「第214回　LLMによるJavaマイグレーションのベンチマークデータセット（パート2）」