まず、代理FK置換は、複合キー（{First Name、Last Name}など）で機能します（または少なくとも機能するはずです）。
次に、これらのレコードを一意にする「他の列に追加データ」があると述べます...それでは、なぜこれらの列を食品の名前と組み合わせて代替キーを形成しないのですか？データモデルが正しくないようです（または、少なくとも一部のメタデータが、指定した条件と一致していません）
第3に、任意のフィールドグループを参照グループコントロールのReplacementFieldGroupとして選択できます。それだけで、基本的にあなたがやりたいことを何でもすることができます。とはいえ、代理FK置換のセマンティクスのため、可能な限り、置換フィールドグループとして代替キーを使用することを強くお勧めします。
フロー：
1）ユーザーが参照グループに値を入力します。
2）ユーザーのタブが表示されます。
3）ユーザーが入力した値は、関連するテーブルでレコードを検索するために使用されます。
4a）ユーザーが入力した値がレコードに一意にマップされている場合、そのレコードが選択されます。それ以外の場合は、
4b）ユーザーが入力した値が一意でない場合、ユーザーが「意味のある」レコードを選択できるようにルックアップが表示されます。したがって、ルックアップは一意に識別可能なレコードのコレクションを提示する必要があることに注意してください。これにより、ユーザーはどのレコードを選択するかを知ることができます（ルックアップですべてのレコードが同じように見える場合、何を選択する必要があるのかわかりません）。
5）入力された値が正常に解決されると、レコードはソースフォームに戻されます。
このフローを考えると、テーブルに一意のインデックス（キー）がない場合、ステップ3〜5が中断されることは明らかです。（レコードに一意の識別手段がない場合、ユーザーはレコードへの一意の参照をどのように指定する必要がありますか（RecIdをユーザーに表示したくない場合）???）
置換フィールドグループとして一意でないインデックスを引き続き使用することを決定した例外的なケースでは、 resolveReferenceとlookupReferenceを実装して、ユーザーに一意の解決/ルックアップエクスペリエンスを提供する必要があります（上記のフローのステップ3〜5を処理するため） ）。注：これの一般的な使用例は、非選択フィールドが参照グループに表示されないように効果的に排除し、代わりに外部コンテキストまたはモードにその値を暗黙的に設定させることです。たとえば、代替キーが{Size、Color}の場合、おそらくユーザーにフォームの上部で色を選択させ、ユーザーにSizeを入力させるだけで、「Color」をグローバルフォームコンテキストにすることができます。参照グループ...次に、resolveReferenceおよびlookupReferenceオーバーライドを介して色を暗黙的に追加し直すことができます。