大規模な言語モデルを使用して SQL スキーマを生成する

オープンソースの中国コミュニティチームは、共有の名のもとに、オープンソースの中国コミュニティの背後にあるストーリーを伝える初のライブブロードキャストを行いました。」

あるドメイン (パブリッシング) を別のドメイン (SQL のドメイン固有言語) にマッピングすることは、LLM の強みによく適合することがわかりました。

著者 David Eastman によるSQL Schema Generation With Large Language Modelsから翻訳。

LLM を使用して生成された正規表現とJSON 永続性について調べてきましたが、多くの人は AI が構造化照会言語 (SQL)を適切に処理すると信じています。 SQL の50 周年を記念して、必要に応じて技術用語を紹介しながら、テーブルについて説明します。ただし、既存のテーブルに対してクエリをテストするだけでは済みません。リレーショナルデータベースの世界はSchemaから始まります。

スキーマは、SQL クエリが現実世界のシステムのモデルに関する質問に答えることができるように相互作用する一連のテーブルを記述します。さまざまな制約を使用して、テーブルが相互にどのように関連するかを制御します。この例では、書籍、著者、出版社のスキーマを開発します。次に、LLM がこの作業を再現できるかどうかを確認します。

私たちは物事間の関係から始めます。本は著者によって書かれ、出版社によって出版されます。実際、本の出版によって、著者と出版社の関係が決まります。

したがって、具体的には次の結果を生成したいと考えています。

本	著者	出版社	発売日
ワスプファクトリー	イアン・バンクス	そろばん	1984 年 2 月 16 日
フレバスを検討してください	イアン・M・バンクス	軌道	1988 年 4 月 14 日

これは読むのには良いのですが (後ほど説明します)、表自体はより多くの情報を管理するのに適した方法ではありません。

発行者の名前が単なる文字列の場合は、それを複数回入力する必要がある可能性があります。これは非効率的であり、エラーが発生しやすくなります。著者もそうです。文学に興味のある人は、両方の本の著者 (イアン・バンクス) が同一人物であることを知っているでしょうが、彼は SF を書くときにわずかに異なるペンネームを使用していました。

その本が後で別の出版社から再出版された場合はどうなりますか?これら 2 つの出版イベントを確実に区別するには、本のタイトルと発売日の両方を指定する必要があるため、主キーまたは一意の識別子には両方が含まれている必要があります。同じタイトルと発行日を持つ 2 冊の本をシステムが拒否するようにしたいと考えています。

1 つの大きなテーブルを使用する代わりに 3 つのテーブルを使用し、必要に応じてそれらを参照します。 1 つは著者用、もう 1 つは出版社用、そして 1 つは本用です。著者の詳細を Authors テーブルに書き込み、外部キーを使用してBooks テーブルで参照します。

したがって、以下はデータ定義言語 ( DDL ) を使用して記述されたスキーマテーブルです。私は MySQL のバリアントを使用していますが、迷惑なことに、すべてのベンダーがまだわずかに異なる方言を維持しています。

まず、著者テーブルがあります。自動 ID 列インデックスを主キーとして追加します。実際には仮名の問題は解決していません (それは読者に任せます)。

CREATE TABLE Authors ( 
  ID int NOT NULL AUTO_INCREMENT, 
  Name varchar(255) not null, 
  Birthday date not null, 
  PRIMARY KEY (ID) 
);

発行者テーブルも同じパターンに従います。「NOT NULL」は、コンテンツのないデータの追加を防ぐもう 1 つの制約です。

CREATE TABLE Publishers ( 
  ID int NOT NULL AUTO_INCREMENT, 
  Name varchar(255) not null, 
  Address varchar(255) not null, 
  PRIMARY KEY (ID) 
);

Books テーブルは外部キーを参照するため、論理的ではありますが、理解するのが少し難しくなります。本のタイトルとその発行日が主キーを形成することに注意してください。

CREATE TABLE Books ( 
   Name varchar(255) NOT NULL, 
   AuthorID int, PublisherID int, 
   PublishedDate date NOT NULL, 
   PRIMARY KEY (Name, PublishedDate), 
   FOREIGN KEY (AuthorID) REFERENCES Authors(ID), 
   FOREIGN KEY (PublisherID) REFERENCES Publishers(ID) 
);

上部にきちんとしたテーブルを表示するには、 view が必要です。これは、スキーマをそのままにしながら、表示する必要がある情報を選択できるように、テーブルをつなぎ合わせる単なる方法です。スキーマを書き留めたので、ビューを構築できます。

CREATE VIEW ViewableBooks AS 
SELECT Books.Name 'Book', Authors.Name 'Author', Publishers.Name 'Publisher', Books.PublishedDate 'Date' 
FROM Books, Publishers, Authors 
WHERE Books.AuthorID = Authors.ID 
AND Books.PublisherID = Publishers.ID;

データベースをインストールする必要がないように、オンラインプレイグラウンドでスキーマを生成できるかどうかを見てみましょう。

DB Fiddle がその仕事をするはずです。

DDL を入力してから実際のデータを追加すると、次のようになります。

INSERT INTO Authors (Name, Birthday) 
VALUES ('Iain Banks', '1954-02-16'); 
 
INSERT INTO Authors (Name, Birthday) 
VALUES ('Iain M Banks', '1954-02-16'); 
 
INSERT INTO Publishers (Name, Address) 
VALUES ('Abacus', 'London'); 
 
INSERT INTO Publishers (Name, Address) 
VALUES ('Orbit', 'New York');

ビューを表示した結果は、DB Fiddle に「Query 3」として表示されます。これはまさに私たちが見たかったデータです。

LLM はパターンも作成できますか?

さて、LLM にスキーマの作成について尋ねたいと思います。 LLM をどのように指導したいと考えているかを要約すると、次のようになります。

英語でスキーマを要求する場合、インデックスと制約を含む 3 つのテーブルの DDL を生成するようにします。
必要に応じて、制約 (主キー、外部キーなど) の必要性を暗示することもできます。
見てもらうことができます。
必要に応じて、MySQL 構文を使用するように指示できます。

私はLlama 3を使用しますが、OpenAI の LLM も調べたところ、ほぼ同じ結果が得られました。

最初のクエリ: 「書籍、出版社、著者を説明するリレーショナルデータベーススキーマを作成する」。

結果：

ここまでは順調ですね。 DDL はまだ作成されていませんが、別途問い合わせることができます。どういうわけか、英語でパターンを説明するのがうまくいきます。返信の残りの部分を見てみましょう。

外部キーの制約が説明されており、ISBN が追加されていますが、これは予想外でした。また、「PublicationDate」は私の「PublishedDate」よりも慣用的です。また、テーブルも作成されます。

これにより、これまで考えもしなかった、1 つの本に複数の著者を作成するという問題が解決されました。ブリッジテーブルという用語は、2 つのテーブル (書籍と著者) が外部キーによって結合されていることを示します。

DDL に「このスキーマのデータ定義言語を見せて」と尋ねてみましょう。

これらは、空のエントリがないことを保証するために、NOT NULL を含めて正しく返されます。また、ベンダー SQL 間の実際の違いにより、DDL はいくつかの点で「ユニバーサル」であるとも述べています。

最後に意見を聞いてみましょう。

これは私のバージョンよりも複雑ですが、スキーマの名前を調整すると DB Fiddle で正常に動作します。ここで示されているテーブルのエイリアスの名前は、理解には役立ちません。

結論: LLM は実際にパターンを作成できる

これは LLM にとって大きな勝利だと思います。なぜなら、彼らは私の英語の記述を十分に制約されたパターンに変換し、さらに実行可能な DDL に変換し、同時に説明も提供してくれたからです (ただし、それらの説明はより技術的な関係の詳細に関するものになりました)。専用の LLM やサービスも使用しなかったので、うまくいきました。

ある意味、これはあるドメイン (出版界) を別のドメイン (SQL のドメイン固有言語) にマッピングするものであり、LLM にとって非常に有利です。各エリアは明確に定義されており、詳細が豊富です。

SQL のお誕生日おめでとうございます。LLM が SQL を今後数十年にわたって維持できることを願っています。

この記事はYunyunzhongsheng ( https://yylives.cc/ ) で最初に公開されたもので、どなたでもご覧いただけます。