Depende um pouco do seu uso. A abordagem normalizada (parque é uma tabela) facilitará as seguintes consultas:

• Quantos avistamentos de pássaros ocorreram em cada parque
• Em qual parque você provavelmente verá o pássaro XYZ
• Provavelmente há mais algumas consultas como esta

Mas sim, você se depara com alguns problemas complicados. O padrão "se o parque XYZ não existir, insira-o na tabela de parques" sofre de uma condição de corrida com a qual você terá que lidar.

Agora, que tal alguns argumentos contra a normalização aqui... A maioria dos bancos de dados de clientes provavelmente armazena meu endereço como "123 Foo Street", sem normalizar dinamicamente o nome da rua (poderíamos ter uma tabela de ruas e colocar "Foo Street" lá, então referenciar Por que trago isso à tona, bem para mostrar que mesmo os caras que odeiam dados repetidos provavelmente reconhecerão que há alguma linha que você não precisa necessariamente cruzar.

Outro exemplo bobo seria que podemos compartilhar sobrenomes. Nós realmente precisamos de uma tabela para sobrenomes exclusivos e, em seguida, uma chave estrangeira para ela de outras tabelas? Pode haver alguns aplicativos em que isso seja útil, mas para 99% dos aplicativos disponíveis, isso vai longe demais. É apenas mais trabalho e menos desempenho para pouco ou nenhum ganho.

Então, eu consideraria como eu quero poder consultar dados de volta da tabela. Honestamente, neste caso eu provavelmente faria uma tabela separada para parques. Mas em outros casos eu optei por não.

São meus dois centavos, um centavo depois dos impostos.