É comumente aceito que as chaves primárias devem ser imutáveis ​​(ou o mais estável possível, já que a imutabilidade não pode ser imposta no banco de dados). Embora não haja nada que impeça você de atualizar uma chave primária (exceto restrição de integridade), pode não ser uma boa ideia:

Do ponto de vista do desempenho:

• Você precisará atualizar todas as chaves estrangeiras que fazem referência à chave atualizada. Uma única atualização pode levar à atualização de potencialmente muitas tabelas/linhas.
• Se as chaves estrangeiras não forem indexadas (!!), você terá que manter um bloqueio na tabela filhos para garantir a integridade. A Oracle só manterá o bloqueio por um curto período de tempo, mas ainda assim, isso é assustador.
• Se suas chaves estrangeiras forem indexadas (como deveriam ser), a atualização levará à atualização do índice (excluir+inserir na estrutura do índice), isso geralmente é mais caro do que a atualização real da tabela base.
• Nas tabelas ORGANIZATION INDEX (em outros RDBMS, consulte chave primária clusterizada), as linhas são classificadas fisicamente pela chave primária. Uma atualização lógica resultará em uma exclusão + inserção física (mais cara)

Outras considerações:

• Se essa chave for referenciada em qualquer sistema externo (cache de aplicativo, outro banco de dados, exportação...), a referência será interrompida na atualização.
• além disso, alguns RDBMS não suportam CASCADE UPDATE, em particular o Oracle.

Em conclusão, durante o projeto, geralmente é mais seguro usar uma chave substituta em vez de uma chave primária natural que supostamente não deve ser alterada - mas pode eventualmente precisar ser atualizada devido a requisitos alterados ou até mesmo a erros de entrada de dados.

Se você absolutamente precisar atualizar uma chave primária com a tabela filhos, veja este post de Tom Kyte para uma solução.