DDL および SQL クエリー生成におけるデータベーススキーマのベストプラクティス

[自然言語で SQL クエリーを実行] スクリプトステップおよび GetTableDDL 関数を使用すると指定したテーブルオカレンスのデータベーススキーマの概要を示すデータ定義言語 (DDL) を生成できます。基礎となるロジックはほとんどのデータベーススキーマのフィールド設定およびリレーションシップグラフに依存しますが、追加情報として [データベースの管理] ダイアログボックスに入力したフィールドコメントを含めることもできます。

データベーススキーマを AI モデルに送信して SQL クエリーを生成する場合、これらのベストプラクティスに従うことでモデルの性能を向上させて有用な SQL ステートメントを生成できるようになります。

英数字のテーブル名およびフィールド名を使用する

最も良いのは SQL-92 標準に準拠しているフィールド名です。一般的に英数字を使用します。アンダースコア (_) 以外の特殊文字は使用できません。スペースの使用は避けるようにします。ただし必要に応じて使用することはできます (FileMaker は AI モデルとの通信中にスペースを含むテーブル名およびフィールド名を正しく処理します)。

主キーおよび外部キーフィールドを使用する

リレーションシップの主キーおよび外部キーフィールドは同じデータタイプにする必要があります (数字、テキスト、または必要な場合は日付やタイムスタンプなども)。

主キーフィールド

いずれのフィールドも固有の値を持つ場合は主キーフィールドとして使用できます。ただし、ベストプラクティスは FileMaker が主キーフィールドを自動的に検出するために使用するのと同じ条件を使用することです。

検出可能な主キーフィールドは、デフォルトの「主キー」フィールド (またはそのコピー) であるか、または次のいずれかの条件を満たす必要があります:

  • 自動入力シリアル番号が使用され、次のオプションが選択されている:

    • 自動入力では [データ入力時の値変更の禁止]

    • 制限では [ユニークな値]

  • Get (UUID) または Get (UUID 番号) 関数を含む自動入力計算が使用され、自動入力オプション [データ入力時の値変更の禁止] が選択されている

  • 計算結果を保存する計算フィールドで、Get (UUID) または Get (UUID 番号) 関数が含まれている

  • 自動入力シリアル番号が使用されている

入力値の自動化の定義、入力値の制限の設定、およびフィールドの索引オプションの定義を参照してください。

外部キーフィールド

外部キーフィールドは関連テーブルの対応する主キーフィールドと同じ名前にすることができますが、必須ではありません。たとえば、「Addresses」テーブルの「fk_Contacts」という名前の外部キーフィールドは「Contacts」テーブルから「Addresses」テーブルへのリレーションシップを表します。ベストプラクティスは AI モデルにとっても役立つ名前にもなるため、意味のある名前を使用することです。

フィールドの目的をより明確にして別のテーブルとのリレーションシップを指定するために、フィールドコメントでフィールドをさらに詳しく説明できます (下記参照)。たとえば、「Addresses::fk_Contacts」フィールドにコメントとして次のように追加します: 「[LLM] 「Contacts」テーブルとの 1 対多のリレーションシップ用の外部キー」

メモ  外部キーと関連テーブルとのリレーションシップはリレーションシップ内で両方のテーブルオカレンスが指定されている場合にのみ DDL に含まれます。

フィールドコメントを追加する

[データベースの管理] ダイアログボックスで入力したフィールドコメントは DDL に含まれます。モデルの性能を向上させて DDL に基づく有用な SQL ステートメントを生成するために、コメントを使用してフィールドの目的を説明できます。たとえば、フィールドが関連テーブルのレコードを識別する外部キーである場合や、フィールドの名前が一般的に理解されないおそれがある場合などです。主キーフィールドの場合、FileMaker がそれを検出して DDL で主キーであることを示す場合でも、フィールドコメントで識別することをお勧めします。

フィールドの定義と変更を参照してください。

[LLM] タグを追加して含まれるフィールドを制限する

テーブルのフィールドをすべて DDL に含めるのではなく、重要なフィールドのみを指定して、無関係な情報がモデルに送信されて応答の品質が低下する現象を軽減できます。そうするには、フィールドコメントの先頭に特別な [LLM] タグを追加してから、必要に応じてわかりやすいコメントを付けます。テーブル内のその他のフィールドのコメントが [LLM] タグで始まらない場合は DDL から除外されます。

たとえば、「Products」テーブルにこれらのフィールドが含まれているが「Status」フィールドのコメントが [LLM] タグで始まらない場合:

フィールド名

 コメント

ProductID

[LLM] 製品を固有に識別する主キー

ProductName

[LLM] 製品のわかりやすい名前

値段

[LLM] 製品価格

状態

在庫にある製品の状態。値は在庫、受注

このテーブルの DDL は次のようになります:

コピー 
CREATE TABLE "Products" (
"ProductID" int, /*製品を固有に識別する主キー*/
"ProductName" varchar(255), /*製品のわかりやすい名前*/
"Price" int, /*製品価格*/
PRIMARY KEY (ProductID)
);

[LLM] タグを持つ 3 つのフィールドのみが含まれ、[LLM] タグ自体は省略されていることに注意してください。

複数のテーブルで同じ名前のフィールドを区別する

データベースが複数のテーブル内に同じ名前のフィールドを持つ場合があります。たとえば、「Contacts」テーブルの「Photo」フィールドに顧客のイメージが格納され、「Orders」テーブルの別の「Photo」フィールドには注文の領収書のイメージが格納されている場合です。AI モデルがこれらのフィールドの目的の違いを確実に区別できるように、フィールドコメントを追加して明確にします。たとえば、「Contacts::Photo」フィールドのコメントに「[LLM] 顧客の写真」を追加して「Orders::Photo」フィールドのコメントに「[LLM] 注文の領収書の写真」を追加します。

大文字と小文字の違いが重要な場合は指定する

SQL クエリーでは大文字と小文字が区別されるため、テキストが大文字か小文字かによって結果が異なることがあります。たとえば、「Products」テーブルの「Tags」フィールドに各製品のタグが格納されてすべて最初の文字が大文字になっている場合です。この場合、予期しない参照結果を避けるために「Products::Tags」フィールドのコメントとして「[LLM] 製品のタグで最初の文字が大文字になっている」を追加します。

有効なフィールド値を使用する

カスタムの値一覧を使用して有効なフィールド値を指定しているフィールドの場合、ベストプラクティスは AI モデルが最適な SQL クエリーを生成できるようにフィールドコメントで有効な値を使用することです。たとえば、「Contacts::Title」フィールドのフィールドコメントとして「[LLM] 役職、有効な値は外科医、医師、歯科医、看護師、および薬剤師」を追加します。

集計フィールドを照会しない

FileMaker データベースの集計フィールドの値は現在の対象レコード内のレコードによって異なるため、場合により SQL クエリーが誤った結果を返すことがあります。代わりに、フィールドコメントに [LLM] タグを使用して集計フィールドを除外します。SQL は高度に発達しているため、DDL に集計フィールドを含めずに集計フィールドのタスクを実行できます。

関連項目