これはかなり基本的だと思いますが、私はこれに新しいです。私はテーブルを正規化しようとしています。複数の外部キーとの関係を3NFにすることはできますか？リレーションシップは複数の外部キーを持つ3NF内にありますか？
か、それ以上に分解される必要があるであろう：
この3NFでありますTALENTPAYMENT（支払い、日付、小計、税金、合計）
TALENTPAYMENTID（ペイメントナンバー、タレント）
TALENTAGENT（TALENTID、agentnumber）
それは合計=小計+税（または他の方法で回避するので、とにかく3NFではありません。私は合計と小計の差で悪いです）。
3NFになるためには、非プライム属性に推移的な関数の依存関係を持たないでください。派生した属性（合計または小計）を削除して、あなたの解決策はOKだと思います。
その点については、オリジナルは問題ありませんが、問題については言及します。
3NFではありませんが、外部キーのためではありません。左側が候補キーではないとなっているあなたは、いくつかの機能の依存関係を持っている：
subtotal,tax -> total
subtotal,total -> tax
tax,total -> subtotal
にあなたのスキーマを分割すると言うでしょう3NFに減少させるためのアルゴリズム：
PAYMENTNUMBER | date | subtotal | tax | talentid | agentnumber
と
subtotal | tax | total
「talentid - > agentnumber」またはその逆をnとすると、スキーマは3NFにありますが、あなたの（小計、税金、合計）テーブルは、3つの明白な冗長性をすべて格納しているので、基本的に無駄です。それだけで使用する方がよいでしょう：
PAYMENTNUMBER | date | subtotal | tax | talentid | agentnumber
そして、すべてではないの合計保存します。クエリでそれを使用したい場合は、SELECT (subtotal+tax) as totalとすると、小計と税が両方とも数値型であると仮定します。
あなたの3つの部分からスキーマは、機能依存talentid⟶ agentnumber 、talendtidは関係のための鍵の一つではありませんので、あなたの関係がBCNF（3NF）にすることはできません、その場合にはそこにあるかもしれないことを示唆しています。
一方、才能/エージェントの関係は脆弱である傾向があるため、同じ才能が異なる時期に異なるエージェントによって表されることは驚くことではありません。その場合、おそらく、支払い時に「才能のエージェント」を記録しておく必要があります。元のスキーマは3部構成のスキーマよりも優れています（3部構成のデータの変更が変更されるため歴史的記録）。
私は他の答えのほとんどがあなたの質問に向かっているよりもあなたの例に向けていると思います。
質問に直接答えるには、複数の外部キーがある場合でも、関係は3NFになる可能性があります。 3NFのキー（咳）ポイントは、外部キーの数を減らすのではなく、推移的な依存関係を削除することです。
言い換えれば、「私は外国キーが多すぎます」という通常の形はありません。