Olá, Matheus! Tudo bem?
Sua aplicação do modelo lógico está muito bem encaminhada! Pela imagem, percebo que você já compreendeu o conceito fundamental da normalização, separando as entidades para evitar a redundância de dados.
Aqui estão algumas observações e sugestões para elevar ainda mais a qualidade da sua modelagem:
ID_Projeto como o elo de ligação entre as duas tabelas. Isso garante que cada tarefa saiba exatamente a qual projeto pertence.Para tornar esse modelo ainda mais robusto, você pode considerar os seguintes pontos:
1. Padronização de Nomenclatura (Case Sensitivity)
Notei que em uma tabela você usou ID_Projeto e na outra ID_projeto (com "p" minúsculo).
2. Status da Tarefa
No mundo real, projetos e tarefas mudam de estado constantemente.
Status (Ex: Pendente, Em Andamento, Concluído) na tabela de tarefas? Isso permite gerar relatórios de produtividade muito mais interessantes.3. Relacionamento N:N (Muitos para Muitos)
Atualmente, seu modelo permite que uma tarefa pertença a apenas um projeto.
Se você quiser praticar o Modelo Físico a partir desse exemplo, tente pensar nos Tipos de Dados:
ID_Tarefa seria um INT (Inteiro).NomeProjeto seria um VARCHAR (Texto).Data-Entrega seria um DATE.Excelente trabalho com os dados da "Alpha" e "Beta"! Você já está pensando como um verdadeiro Modelador de Dados.
Espero que possa ter lhe ajudado!
No cenário que você está imaginando, os usuários podem ser atribuídos às tarefas? Se sim, você já pensou em como seria a estrutura de uma tabela de Colaboradores para interagir com esse modelo?