Mini-Projeto · Modelar uma BD à escolha
Contexto
Cada par/trio escolhe um domínio real (ginásio, oficina, livraria, app de gestão pessoal, escola de música, etc.) e modela uma base de dados completa: do levantamento de requisitos ao SQL final em 3FN.
Foco em modelo, não em programação: não há aplicação a construir nesta UC; isso vem em UCs seguintes.
Requisitos
Funcionais
- Documento de requisitos (1 página) descrevendo o domínio.
- Diagrama ER (Crow's Foot) com pelo menos 5 entidades e 2 relações N:M.
- Esquema SQL com tabelas, PK, FK, restrições.
- Script de inserção de dados de exemplo (mín. 5 linhas por tabela).
- 3 consultas SQL simples que validam o modelo, no estilo das do capítulo 16.5 da sebenta.
Não-funcionais
- Modelo em 3FN, com justificação por escrito do que decidiram ou não normalizar.
- SQL testado num SGBD real. O dialeto da sebenta é o MySQL 8; se usarem PostgreSQL ou SQLite, adaptam a sintaxe e dizem qual foi usado nos testes.
- Conformidade: lista das colunas com dados pessoais, prazo ou critério de conservação de cada uma e, se houver dados sensíveis, uma vista ou a anonimização que os protege.
- Documentação clara com diagrama, SQL e explicações.
Fases
Fase 1 · 1 h
Levantamento de requisitos
- Escolher domínio (livre, validar com professor).
- Entrevistar (real ou imaginariamente) um "cliente" do domínio.
- Listar entidades, atributos, regras de negócio.
Documento de 1 página com descrição do domínio + lista inicial de entidades e atributos.
Fase 2 · 1,5 h
Diagrama ER
- Desenhar em dbdiagram.io ou drawSQL.
- Pelo menos 5 entidades, 2 relações N:M.
- Resolver N:M com tabelas de associação.
- Definir cardinalidades em cada relação.
PNG/PDF do diagrama + link de partilha para a ferramenta usada.
Fase 3 · 1,5 h
SQL e restrições
- Escrever
CREATE TABLEcom PK, FK, NOT NULL, UNIQUE, CHECK, DEFAULT. - Definir ações referenciais (CASCADE / RESTRICT / SET NULL) com justificação.
- Aplicar 3FN; explicar quaisquer desvios.
- Confirmar no manual do SGBD (na versão usada) qualquer cláusula de que haja dúvidas.
schema.sql executável sem erros no SGBD escolhido.
Fase 4 · 1 h
Dados e consultas
- Script
seed.sqlcom 5+ linhas por tabela. - 3 consultas
SELECTque validam o modelo, como as do capítulo 16.5 da sebenta: uma comWHERE, uma comJOINentre tabelas ligadas por chave estrangeira e uma comORDER BY. As agregações (GROUP BY) são opcionais.
seed.sql + queries.sql com resultados esperados em comentário.
Fase 5 · 1 h
Dossier final + apresentação
- Compilar tudo em PDF com diagrama + SQL + explicações.
- Apresentar 5 min ao resto da turma.
PDF final + slides curtos (5 slides).
Critérios de avaliação
| Item | Peso |
|---|---|
| Requisitos claros | 10% |
| Diagrama ER correto | 25% |
| 3FN aplicada | 15% |
| SQL com restrições adequadas | 20% |
| Dados de exemplo realistas | 10% |
| Consultas que validam o modelo | 5% |
| Justificação das decisões de modelação e conformidade com o RGPD | 10% |
| Apresentação | 5% |
Erros comuns
- N:M resolvido com colunas múltiplas em vez de tabela de associação.
FLOATpara preços (problemas de precisão).VARCHAR(255)em tudo sem pensar.- Falta de FK (tabelas sem ligação real, JOINs sem integridade).
- 0 restrições CHECK; aceita qualquer lixo.
- ENUM exagerado em vez de tabelas de lookup quando há crescimento.
Bónus (opcional)
- Acrescentar uma vista (
CREATE VIEW) que esconda os dados pessoais mais sensíveis a um perfil de utilizador só de leitura. - Escrever uma segunda versão do esquema em PostgreSQL e listar as diferenças de sintaxe face a MySQL.
- Acrescentar ao modelo uma tabela de histórico de alterações de uma tabela com dados pessoais, indicando durante quanto tempo se guarda.
Reflexão
Em meia página: que decisão de modelação foi mais difícil? Que coisa farias diferente agora? Se este projeto fosse escalar para 100 mil utilizadores, o que mudarias?