Exercício 3: Definindo as Regras do Jogo

Sua Missão: Agir como o(a) legislador(a) do seu banco de dados, aplicando as Constraints para garantir que as regras sejam seguidas e a ordem seja mantida!

Vamos voltar ao cenário da agência de heróis/vilões do exercício anterior, ou ao modelo que você criou no Exercício 2.

O Desafio:

Para as tabelas agentes e missoes (ou as tabelas do seu próprio modelo), revise a estrutura e pense em quais Constraints fariam sentido aplicar para melhorar a qualidade e a integridade dos dados.

Tarefas de Legislador(a):

1. Revisão da Tabela agentes:

   • Quais colunas não podem ser nulas (NOT NULL) de jeito nenhum? (Pense: Todo agente precisa de um nome_codigo? De um nível?)

   • A coluna nome_codigo já era UNIQUE. Existe alguma outra coluna que também deveria ser única? (Talvez um numero_registro_agente se existisse?)

   • Faz sentido ter um valor DEFAULT para alguma coluna? (Talvez o nivel_habilidade padrão seja 1? Ou ativo padrão true já está bom?)

   • A PRIMARY KEY (id) já está definida. Está ok?

2. Revisão da Tabela missoes:

   • Quais colunas são obrigatórias (NOT NULL)? (Toda missão precisa de um nome? De um status? De um agente associado?)

   • Existe alguma coluna que deveria ser UNIQUE? (Talvez o nome_missao dentro de um certo período? Ou é ok repetir?)

   • Faz sentido ter um DEFAULT? (Talvez o status padrão seja 'Planejamento'? Ou a data_inicio padrão seja a data atual?)

   • A PRIMARY KEY (id) está ok?

   • A FOREIGN KEY (agente_id referenciando agentes.id) é crucial. Quais regras ON DELETE e ON UPDATE você aplicaria? Pense nas opções:

     • RESTRICT/NO ACTION: Impedir que um agente seja apagado se tiver missões associadas.

     • CASCADE: Apagar o agente E todas as suas missões (perigoso!).

     • SET NULL: Apagar o agente e deixar as missões sem agente (agente_id = NULL). A coluna agente_id precisaria permitir nulos.

     • SET DEFAULT: Apagar o agente e atribuir as missões a um agente "padrão" (precisaria de um agente padrão e a coluna agente_id ter um DEFAULT).

     • Qual faz mais sentido para a Agência? Justifique sua escolha!

3. (Se aplicável ao seu modelo do Exercício 2): Faça a mesma análise para as tabelas que você desenhou. Quais NOT NULL, UNIQUE, DEFAULT, PRIMARY KEY e FOREIGN KEY (com ações ON DELETE/UPDATE) você aplicaria?

Como Entregar:

• Liste as constraints que você adicionaria ou modificaria para cada tabela.

• Para as FOREIGN KEYs, explique qual ação (ON DELETE/ON UPDATE) você escolheu e por quê.

• Você pode escrever isso como texto, ou se estiver usando o Supabase/SQLiteOnline, pode tentar usar comandos ALTER TABLE para adicionar algumas dessas constraints (pesquise a sintaxe se precisar! Ex: ALTER TABLE agentes ADD CONSTRAINT nome_unico UNIQUE (nome_codigo); ou ALTER TABLE agentes ALTER COLUMN nivel_habilidade SET NOT NULL;). Cuidado ao alterar tabelas existentes!.

Exemplo de Resposta (Parcial para agentes):

• Tabela agentes:

  • nome_codigo: Manter UNIQUE, adicionar NOT NULL (Todo agente precisa de um codinome).

  • nivel_habilidade: Adicionar NOT NULL (Todo agente tem um nível).

  • cidade_base: Pode ser NULL? Talvez um agente nômade? Decidi deixar como opcional (sem NOT NULL).

  • ativo: Manter DEFAULT true, adicionar NOT NULL (Sempre tem que ser true ou false, não nulo).

• Tabela missoes:

  • nome_missao: Adicionar NOT NULL.

  • status: Adicionar NOT NULL. Talvez um DEFAULT 'Planejamento'.

  • agente_id: Adicionar NOT NULL (Toda missão precisa de um agente?).

  • FOREIGN KEY (agente_id): Escolho ON DELETE RESTRICT. Não quero apagar um agente se ele ainda tiver missões ativas ou no histórico. Prefiro reatribuir as missões manualmente ou arquivar o agente (marcar como ativo = false) em vez de perder o histórico da missão ou apagar a missão junto.

Objetivo: Entender a importância das constraints para garantir a qualidade dos dados e aprender a pensar sobre as regras que governam suas tabelas e relacionamentos.