これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
CTC 教育サービス
[IT研修]注目キーワード Python Power Platform 最新技術動向 生成AI Docker Kubernetes
前回に引き続き、2026年に公開された論文「Semantic Data Modeling, Graph Query, and SQL, Together at Last?」に基づいて、現在Google社内で利用されている、セマンティックデータモデルに対応するSQL拡張を紹介します。今回は、前回に紹介し切れなかった2つのSQL拡張構文、そして、グラフ型データ構造との関係を説明します。
これは、ARRAY型（配列型）のカラムに保存されたデータについて、配列内のデータの集計処理を行います。たとえば、文字列型のカラムStudentID（生徒ID）とARRAY型のカラムgrades（複数のテストの点数をまとめた配列）を持つStudentsテーブルがあり、StudentIDごとに、該当生徒のすべてのテストの平均点を計算する場合を考えます。処理としてはシンプルですが、実は、従来のSQLではそれほど簡単には記述できません。第215回の記事で説明したように、ARRAY型のデータをUNNESTで展開すると、ARRAY内のデータが複数の行に分かれた新しいテーブルが生成されます。そのため、元のStudentsテーブルとジョインしてから、StudentIDでまとめる必要があります。具体的には、次のようなSQLクエリーになります。
SELECT StudentID, AVG(g)
FROM Students s JOIN UNNEST(s.grades) g
GROUP BY StudentID
一方、この拡張構文を利用すると、次のようにJOINが省略できます。
SELECT StudentID, AVG(UNNEST(s.grades))
FROM Students s
GROUP BY StudentID
前回の記事の図1で、5つのテーブルをジョインして、「国ごとのl_extendedpriceの合計値を計算する」というSQLクエリーを紹介しました。このSQLクエリーは、この拡張構文を利用すると、JOINを省略して、次のようにさらに簡潔に記述できます。
SELECT c.Nation.n_name,
SUM(UNNEST(c.Orders.Lineitems.l_extendedprice))
FROM Customer c
WHERE c.Nation.Region.r_name = "EUROPE"
GROUP BY 1
「c.Orders.Lineitems.l_extendedprice」という表記は、顧客（c）の注文（Orders）に含まれる商品（Lineitems）の提供価格（l_extendedprice）と自然に読むことができるので、提供価格の合計を「c.Nation.n_name」、つまり、顧客が属する国ごとに合計していると直感的に理解できます。（「GROUP BY 1」は、SELECTの最初の要素「c.Nation.n_name」でグループ化します。）
前回の記事で説明した仮想カラム（Virtual columns）は、行ごとに計算処理を行いますが、評価カラム（Measure columns）は、特定の列についての集計処理を事前に定義した仮想的なカラムです。次は、o_totalprice列の合計を表す評価カラムTotalRevenueを定義する例です。
ALTER TABLE Orders
ADD COLUMN TotalRevenue AS MEASURE(SUM(o_totalprice));
SQLクエリーの中で、評価カラムにAGG関数を適用すると、実際の計算値が得られます。図1は論文内で紹介されている利用例で、3行目のAGG(o.TotalRevenue)は、OrderテーブルにおけるSUM(o_totalprice)の計算結果を返します。2行目のSUM(o_totalprice)でも同じ結果が得られる気がしますが、実はここには落とし穴があります。このクエリーでは、OrderテーブルとLineitemテーブルをジョインしており、（1つのOrderに複数のLineitemが含まれるため）ジョイン後のテーブルではOrderテーブルの行が複製されており、SUM(o_totalprice)ではダブルカウントが発生します。評価カラムは、定義された元のテーブル内での計算が行われるので、このようなミスが発生しなくなります。
図1 評価カラムにAGG関数を適用したSQLクエリーの例
ここまで、4つのSQL拡張構文を説明しました。一般に、SQLクエリーでビジネス視点でのデータ分析を行うには複雑なクエリーが必要で、先ほど説明したダブルカウントのようなミスも起きやすくなります。これらのSQL拡張構文は、ビジネス視点でのデータ分析に必要なSQLクエリーをよりシンプルで直感的に記述するのに役立ちます。これだけでも有用な機能ですが、第215回の記事では、これらの機能は、セマンティックデータモデル、すなわち、ビジネス視点に適合したデータ構造を実現することが目的だと説明しました。この点について、論文内では、グラフ型データ構造との関係が説明されています。
まず、「外部キーによる暗黙のジョイン」は、外部キーを通して複数のテーブルを連結する機能ですが、これは、テーブルをノードとしたグラフ構造を定義していると考えられます。また、「仮想カラム（Virtual columns）」「配列内の集計（Horizontal aggregation）」「評価カラム（Measure columns）」は、それぞれのテーブルからビジネス視点で意味のあるデータを抽出する機能で、グラフ型データで言うと、それぞれのノードに固有の属性情報を表すアトリビュートに相当すると考えられます。一般に、ビジネス視点での情報は、グラフ型のデータ構造で表現されることが多く、これまで、ビジネス情報を表現するセマンティックデータモデルとして、グラフ型データベースを活用するアイデアも数多くありました。しかしながら、グラフ型データベースは、リレーショナルデータベースとはデータの構成方法やクエリーの記述方法が異なります。そのため、リレーショナルデータベースに格納された既存のデータとの相互運用が難しいと言う課題がありました。
一方、この論文で紹介されている拡張構文を活用すれば、既存のリレーショナルデータベースのデータからスタートして、外部キーによるグラフ構造の導入、そして、その他の機能によるアトリビュートの追加を行うことで、自然な形でグラフ構造が導入できます。さらに、これらの拡張構文を利用することで、既存のSQLクエリーの延長として、グラフ構造のデータにアクセスできるというわけです。
今回は、2026年に公開された論文「Semantic Data Modeling, Graph Query, and SQL, Together at Last?」に基づいて、4つのSQL拡張構文から「配列内の集計（Horizontal aggregation）」と「評価カラム（Measure columns）」を説明した上で、グラフ型データ構造との関係を解説しました。
次回は、生成AIを利用したデータビジュアライゼーションに関する話題をお届けします。
Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡
[IT研修]注目キーワード Python Power Platform 最新技術動向 生成AI Docker Kubernetes
