これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
CTC 教育サービス
[IT研修]注目キーワード Python Power Platform 最新技術動向 生成AI Docker Kubernetes
前回に引き続き、2026年に公開された論文「Semantic Data Modeling, Graph Query, and SQL, Together at Last?」に基づいて、現在Google社内で利用されている、セマンティックデータモデルに対応するSQL拡張を紹介します。今回は、論文内で議論されている具体的な拡張の内容を説明します。
冒頭の論文では、主に次の4つのSQL拡張構文が説明されています。
それぞれの説明を見ると、間違いやすい複雑なSQLクエリーをより簡単に記述する機能だとわかりますが、これだけでは、セマンティックデータモデルの実現にどのように役立つかがわかりにくいかもしれません。実は、これらの機能を組み合わせると、グラフ型のデータ構造を自然に表すことができます。ビジネス視点でのデータは、グラフ型のデータ構造を持つことが多いため、これにより、従来のリレーショナルデータベースとの互換性を保ちながら、セマンティックデータモデルが自然に記述できるようになります。
グラフ型のデータ構造については、後ほど説明することにして、まずは、上記の4つの拡張構文を説明していきます。今回は、「外部キーによる暗黙のジョイン」と「仮想カラム（Virtual columns）」を説明します。
この構文拡張は、テーブルのジョインを簡潔に記述します。例えば、CustomerテーブルとOrdersテーブルをジョインする次のSQLクエリー（の一部）を考えます。
FROM Customer c JOIN Orders o ON c_custkey = o_custkey
ここでは、Customerテーブル（顧客テーブル）のc_custkey列とOrdersテーブル（注文テーブル）のo_custkey列は、ビジネス的に同一の概念（顧客ID）を表しており、この事実を理解した上でジョインする必要があります。さもなくば、SQL構文としては正しくてもビジネス的には意味のないデータが得られます。通常、このような関係性は外部キーとして宣言されているので、外部キーを参照すれば、ビジネス的に意味のあるジョインかどうかが確認できます。逆に言うと、2つのテーブルに外部キーが定義されていれば、それらの列でジョインするのはビジネス的に自然な操作と言えます。そこで、この拡張構文では、上記のSQLクエリーを次のように記述することを許します。
FROM Customer c JOIN c.Orders
ここでは、CustomerテーブルとOrdersテーブルのジョインを指定していますが、ジョインに使用される列は外部キーによって自動的に決定されます。そして、ジョイン後のテーブルで、Ordersテーブルの列o_orderkeyにアクセスする際は、「c.Orders.o_orderkey」のように記述します。１つの顧客が複数の注文記録を持つ場合、「c.Orders.o_orderkey」は複数のo_orderkeyを含むARRAY型のデータになります。
さらにまた、c.Ordersという記法は、CustomerテーブルにSTRUCT型（辞書型）の列Ordersを追加していると見なすこともできます。先ほどの「c.Orders.o_orderkey」は、「CustomerテーブルのOrder列に含まれるSTRUCT型データのo_orderkeyキーに対応するバリュー（結果はARRAY型）」を取り出していると考えられます。前回の記事で、「ARRAY型やSTRUCT型のデータは別テーブルに保持されるデータをビジネス視点で意味のあるデータ構造として1つのカラムにまとめていると見なせる」という説明をしましたが、この拡張構文は、複数のテーブルに分かれたデータを仮想的にSTRUCT型の列にまとめる機能とも言えるでしょう。
論文の中では、より複雑な例として図1の例が紹介されています。上段のSQLクエリーでは、5つのテーブルを結合して、ヨーロッパ地域に含まれる国について、国ごとのl_extendedpriceの合計値を計算しています。この拡張構文を用いると、このSQLクエリーは、下段のように簡潔に記述できます。複数のテーブルをジョインする際は、ドット表記を連続することができて、JOIN句では3つのテーブルを明示的にジョインしており、さらに、WHERE句では3つのテーブルが暗黙的にジョインされます。
図1 外部キーによる暗黙のジョインの利用例（論文より抜粋）
仮想カラムは、スプレッドシートの計算式に類似した機能で、クエリーを実行したタイミングで事前に定義した計算処理が実行されます。例えば、BrithDate列を持つStudentsテーブルに対して、次の計算式で仮想カラムのAge列を定義します。
DATE_DIFF(CURRENT_DATE(), BirthDate, YEAR).
その後、次のクエリーを実行すると、現在時刻（CURRENT_DATE()）と誕生日（BirthDate）の差からその時点での年齢が計算されます。
SELECT Name, BirthDate, Age FROM Students
仮想カラムを利用することで、ビジネスロジックを列の定義に直接埋め込むことができます。同様の事はビューを用いても実現できますが、ビューを用いた場合、既存のテーブルとビューをジョインするなど、分析のためにSQLクエリーを書く手間が増えてしまいます。既存のテーブルに仮想カラムを追加することで、ビジネス的に関連する情報を1つのテーブルにまとめることができます。
今回は、2026年に公開された論文「Semantic Data Modeling, Graph Query, and SQL, Together at Last?」に基づいて、4つのSQL拡張構文から「外部キーによる暗黙のジョイン」と「仮想カラム（Virtual columns）」を説明しました。次回は、残りの2つのSQL拡張構文、そして、これらの拡張構文とグラフ型データ構造との関係を説明します。
Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡
[IT研修]注目キーワード Python Power Platform 最新技術動向 生成AI Docker Kubernetes
