Mais algumas respostas para suas perguntas:

1) Você está praticamente no alvo para alguém que está abordando um problema como esse pela primeira vez. Eu acho que os ponteiros de outros sobre essa questão até agora cobrem isso. Bom trabalho!

2 e 3) O impacto no desempenho que você terá dependerá em grande parte de ter e otimizar os índices corretos para suas consultas/procedimentos específicos e, mais importante, o volume de registros. A menos que você esteja falando sobre mais de um milhão de registros em suas tabelas principais, você parece estar no caminho certo para ter um design suficientemente mainstream para que o desempenho não seja um problema em hardware razoável.

Dito isso, e isso está relacionado à sua pergunta 3, com o início que você tem, você provavelmente não deveria estar muito preocupado com o desempenho ou hipersensibilidade à ortodoxia da normalização aqui. Este é um servidor de relatórios que você está construindo, não um back-end de aplicativo baseado em transações, que teria um perfil muito diferente em relação à importância do desempenho ou normalização. Um banco de dados que oferece suporte a um aplicativo de agendamento e inscrição ao vivo precisa estar atento às consultas que levam segundos para retornar dados. Não apenas uma função de servidor de relatório tem mais tolerância para consultas complexas e demoradas, mas as estratégias para melhorar o desempenho são muito diferentes.

Por exemplo, em um ambiente de aplicativo baseado em transação, suas opções de melhoria de desempenho podem incluir a refatoração de seus procedimentos armazenados e estruturas de tabela até o enésimo grau ou o desenvolvimento de uma estratégia de armazenamento em cache para pequenas quantidades de dados comumente solicitados. Em um ambiente de relatórios, você certamente pode fazer isso, mas pode ter um impacto ainda maior no desempenho introduzindo um mecanismo de instantâneo em que um processo agendado é executado e armazena relatórios pré-configurados e seus usuários acessam os dados de instantâneo sem estresse em sua camada de banco de dados em por solicitação.

Tudo isso é um discurso prolixo para ilustrar que os princípios e truques de design que você emprega podem diferir devido à função do banco de dados que você está criando. Espero que seja útil.