常に、テーブルを第3正規形（3NF）で設計することから始める必要があります。影響を理解して軽減することを条件として、（通常はパフォーマンス上の理由から）より小さな形式に戻すことはまったく問題ありませんが、開始 3NFで。
覚えておくべき（少し単純化された）ルールは、テーブル内のすべての非キー列は以下に依存する必要があるということです。
- 鍵
- キー全体
- そして鍵以外は何もありません
- 「助けてください、コッド」-少しDBAのユーモア（そして私は「少し」を意味します）。
最初の質問はかなり単純です。
1対多の関係は、「多」テーブルでは外部キーとして最もよく表されます。だからあなたが提案することは賢明です。これにより、関係を自動的に制限できます。別の結合テーブル（多対多に使用）がある場合は、「トリッケリー」に頼って1対多の関係を強化する必要があります。
2番目の質問については、上記の「コッド」ルールを見て、自分で考える必要があります。各テーブルのこれらの行は正確に何を表していますか。作業項目のアクションが作業項目とは異なるオブジェクトである場合（関連している可能性があります ただし、それらが同じオブジェクトを表していない場合は、それらは区別されます）、それらは異なるテーブルにある必要があります。
さらに、そこには1対多の関係があるようです（1つのアイテムに多くのアクションを含めることができます）ので、その理由だけで異なるテーブルに配置する必要があります。
冗長な情報に関するクエリについて：本当にかどうか 冗長であるため、修復する必要があります。
step_numの使用 例として、これは正確に何を表していますか？作品のアイテムの属性である場合 作業中であってはなりませんアクション テーブル。
そこからそれを取り除き、作業アクションテーブルの行のステップ番号を知りたい場合は、外部キーを使用して作業項目テーブルと結合します。
代わりにそれが作業アクションの属性である場合は、意味がないため、作業項目テーブルから削除する必要があります。ステップ番号がそれぞれ異なる2つのアクションがある場合、その場合、親アイテムのステップ番号はどうなりますか？
もちろん、あなたは明確なを持っているかもしれません との両方のアイテムのステップ番号 アクション-その場合、item_step_numのように、意図を明確にするために名前を変更することを検討します。 およびaction_step_num 。
結論は、3NFから始めることです。ある時点でデータベースの実行が遅すぎる場合は、次に より小さな形式への復帰を検討してください。その後、別のに尋ねることができます ここで、そこから発生する問題を認識して軽減する方法について質問します（たとえば、2つの場所でデータに一貫性がない可能性があり、トリガーを使用してそれを防止します）。