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」フィールドにアノテーションとして次のように追加します: 「「Contacts」テーブルとの 1 対多のリレーションシップ用の外部キー」

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

フィールドアノテーションを追加する

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

フィールドアノテーションの追加の詳細については、詳細フィールドオプションの定義を参照してください。

フィールドアノテーションを指定して含まれるフィールドを制限する

テーブルのフィールドをすべて DDL に含めるのではなく、重要なフィールドのみを指定して、無関係な情報がモデルに送信されて応答の品質が低下する現象を軽減できます。そのためには、含めるフィールドにフィールドアノテーションを追加します。1 つ以上のフィールドアノテーションをテーブルに追加すると、アノテーションのあるフィールドのみが DDL に含められ、アノテーションのないフィールドは除外されます。

たとえば、「Products」テーブルにこれらのフィールドが含まれているが「Status」フィールドにアノテーションがない場合:

フィールド名 アノテーション

ProductID

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

ProductName

製品の具体的な名称

Price

日本円での製品価格

Status

(アノテーションなし)

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

コピー 
CREATE TABLE "Products" (
"ProductID" int, /*製品を固有に識別する主キー*/
"ProductName" varchar(255), /*製品の具体的な名称*/
"Price" int, /*日本円での製品価格*/
PRIMARY KEY (ProductID)
);

アノテーションのある 3 つのフィールドのみが含まれていることに注意してください。

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

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

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

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

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

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

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

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

メモ 

フィールドアノテーションの代わりにフィールドコメントを使用するカスタム App との互換性を保つには:

  • テーブル内でフィールドアノテーションが指定されていない場合、そのテーブルのすべてのフィールドが DDL に含まれます。フィールドコメントがある場合、DDL の説明として含まれます。

  • フィールドアノテーションが空白でフィールドコメントの先頭が特別な [LLM] タグで始まる場合、[LLM] タグを除くコメントテキストがアノテーションとして DDL で使用されます。

関連項目