あなたの質問に対するいくつかの答え：
1）このような問題に初めて取り組む人の目標はほぼ達成されています。これまでのところ、この質問に関する他の人からのポインタはほとんどそれをカバーしていると思います。お疲れ様でした！
2＆3）パフォーマンスへの影響は、特定のクエリ/プロシージャに適切なインデックスを設定して最適化するか、さらに重要なことにレコードの量に大きく依存します。メインテーブルの100万をはるかに超えるレコードについて話しているのでない限り、適切なハードウェアでパフォーマンスが問題にならないように、十分に主流の設計を採用することは順調に進んでいるようです。
そうは言っても、これはあなたの質問3に関連しています。最初は、ここでの正規化の正統性に対するパフォーマンスや過敏症について過度に心配する必要はないでしょう。これは、構築しているレポートサーバーであり、トランザクションベースのアプリケーションバックエンドではありません。パフォーマンスや正規化の重要性に関して、プロファイルが大きく異なります。ライブサインアップおよびスケジューリングアプリケーションをサポートするデータベースは、データを返すのに数秒かかるクエリに注意する必要があります。レポートサーバー機能は、複雑で時間のかかるクエリに対する耐性が高いだけでなく、パフォーマンスを向上させるための戦略も大きく異なります。
たとえば、トランザクションベースのアプリケーション環境では、パフォーマンス向上オプションには、ストアドプロシージャとテーブル構造をn次までリファクタリングすることや、一般的に要求される少量のデータのキャッシュ戦略を開発することが含まれる場合があります。レポート環境では確かにこれを行うことができますが、スケジュールされたプロセスが実行され、事前構成されたレポートが保存され、ユーザーがデータベース層にストレスをかけることなくスナップショットデータにアクセスするスナップショットメカニズムを導入することで、パフォーマンスにさらに大きな影響を与えることができます。リクエストごとに。
これはすべて、作成するデータベースの役割によって、使用する設計原則とトリックが異なる可能性があることを示すための長年の怒りです。お役に立てば幸いです。