NOTAS DO PROFESSOR
- enfatizar: a base de dados não é um extra informático, é o registo científico da escavação. Perder dados é perder informação irrecuperável, porque escavar destrói o contexto.
- erro comum: alunos pensam que uma folha de cálculo por si só resolve. Serve para pouco tempo, mas não impede duplicação de números nem garante relações entre tabelas.
- exemplo: a DGPC (Direção-Geral do Património Cultural) mantém o Endovélico, a base de dados nacional do património arqueológico português, onde os sítios e as intervenções ficam registados.
NOTAS DO PROFESSOR
- enfatizar que o contexto profissional real é misto: campo e gabinete, muitas vezes no mesmo dia.
- pergunta à turma: porque é que uma empresa de conservação e restauro também precisa desta base de dados? (para saber a proveniência exata de cada peça antes de intervencionar).
- analogia: a base de dados é o "livro de bordo" digital da escavação, sem ele o navio perde-se.
NOTAS DO PROFESSOR
- enfatizar o vocabulário: tabela, registo, campo. Vai aparecer em toda a UC e é preciso fixar cedo.
- erro comum: confundir campo com valor. O campo é o "rótulo" (material), o valor é o conteúdo (ceramica).
- exemplo/analogia: uma tabela é como um ficheiro de fichas de cartão, cada ficha é um registo, cada linha preenchida na ficha é um campo.
NOTAS DO PROFESSOR
- enfatizar que estes quatro princípios vão reaparecer, com nome técnico, no bloco da normalização.
- erro comum: achar que "duplicar para garantir" é seguro. É o oposto: duplicar cria inconsistências quando só uma cópia é corrigida.
- pergunta: o que acontece se o nome de um sítio arqueológico estiver escrito de duas formas diferentes em duas tabelas? (as consultas deixam de cruzar os dados corretamente).
NOTAS DO PROFESSOR
- enfatizar: metodologia vem antes de qualquer software. A ferramenta informática só formaliza um processo que já tem de estar certo em papel.
- erro comum: deixar o registo "para logo", confiando na memória. Em campo, o que não se escreve no momento perde-se.
- exemplo: a ficha de unidade estratigráfica (ficha de UE) é preenchida na própria trincheira, antes de a camada ser retirada.
NOTAS DO PROFESSOR
- enfatizar a ligação direta com a realização "analisar as necessidades para a criação da base de dados": sem organizar primeiro, não se sabe o que a base de dados precisa de guardar.
- erro comum: misturar unidades estratigráficas com peças na mesma lista de registo, "porque saíram juntas". São entidades diferentes e vivem em tabelas diferentes.
- pergunta à turma: se encontraram três fragmentos de cerâmica na mesma camada, são um registo ou três? (três, cada peça é um registo próprio, todos ligados à mesma UE).
NOTAS DO PROFESSOR
- enfatizar: desenhar a estrutura sem saber as perguntas de partida é a causa mais comum de bases de dados mal feitas.
- erro comum: começar a criar campos "porque parecem úteis", sem validar se respondem a uma necessidade real do inventário.
- exemplo: uma equipa que só regista "descrição da peça" em texto livre não consegue depois filtrar por material, porque a informação não está num campo próprio.
NOTAS DO PROFESSOR
- enfatizar que planear no papel ou num diagrama antes do software poupa retrabalho: mudar a estrutura depois de ter dados introduzidos é caro.
- erro comum: saltar direto para o software (Access, SQLite) sem desenhar primeiro o diagrama de entidades e relações.
- exemplo/analogia: o diagrama é como a planta de uma casa antes de a construir; ninguém assenta tijolo sem planta.
NOTAS DO PROFESSOR
- enfatizar: uma tabela por entidade é a decisão estrutural mais importante da UC. Tudo o resto (chaves, normalização) decorre daqui.
- erro comum: querer meter "tudo numa tabela só" para simplificar. É exatamente o oposto do modelo relacional e gera duplicação.
- pergunta: porque é que "desenho" e "fotografia" são entidades diferentes, mesmo sendo ambas "imagens"? (têm atributos próprios, como escala no desenho e formato na fotografia, e ciclos de produção diferentes).
NOTAS DO PROFESSOR
- enfatizar: o diagrama ER é uma ferramenta de comunicação com a equipa, não só um exercício académico.
- erro comum: desenhar o ER só com nomes de tabelas, sem os atributos principais. Sem atributos, não dá para validar se responde às necessidades do bloco 4.
- exemplo: pedir à turma para desenhar o ER de `desenhos` e `fotografias` com os atributos próprios de cada uma.
NOTAS DO PROFESSOR
- enfatizar: a chave primária não muda depois de criada. Se o id de uma peça mudasse, todas as ligações a desenhos e fotografias partiam.
- erro comum: usar um campo que pode repetir-se (como o nome do sítio) como chave primária.
- exemplo: numa turma de 30 alunos, o número de aluno é chave primária, o nome próprio não é, porque pode haver dois "João".
NOTAS DO PROFESSOR
- enfatizar a diferença de vocabulário: PK identifica "a mim próprio", FK aponta "para outro".
- erro comum: escrever o número da UE por extenso dentro da tabela `pecas` (ex.: repetir "UE 1042" como texto) em vez de usar o id como chave estrangeira. Isso reintroduz duplicação.
- exemplo: mostrar no software como o campo ue_id aparece como uma lista de escolha ligada à tabela das unidades estratigráficas, não como texto livre.
NOTAS DO PROFESSOR
- enfatizar: a chave estrangeira vai sempre no lado "muitos" da relação. É um erro comum colocá-la do lado errado.
- erro comum: pensar que cardinalidade 1:N precisa de tabela de ligação. Não precisa, chega a chave estrangeira direta.
- pergunta: se uma peça pudesse pertencer a duas unidades estratigráficas ao mesmo tempo, a relação continuaria a ser 1:N? (não, passaria a N:M, próximo bloco).
NOTAS DO PROFESSOR
- enfatizar que a cardinalidade se lê nos dois sentidos da relação, um de cada vez.
- erro comum: só olhar para um lado da relação e esquecer o outro.
- exemplo: pedir à turma para verbalizar a cardinalidade entre `unidades_estratigraficas` e `pecas` nos dois sentidos, em voz alta.
NOTAS DO PROFESSOR
- enfatizar: N:M não se resolve nunca com uma chave estrangeira simples de um lado só. É preciso uma terceira tabela.
- erro comum: tentar meter uma lista de números de desenho num único campo de texto da tabela `pecas`. Quebra a atomicidade e impede consultas fiáveis.
- exemplo: uma fotografia de uma prancha com cinco fragmentos de cerâmica documenta cinco peças diferentes, a mesma fotografia.
NOTAS DO PROFESSOR
- enfatizar que a chave primária composta (peca_id + desenho_id) é o que impede o mesmo par de se repetir por engano.
- erro comum: esquecer a chave primária composta na tabela de ligação e acabar com pares duplicados.
- exemplo: mostrar a consulta que devolve todos os desenhos de uma peça através da tabela `peca_desenho`, usando dois JOIN.
NOTAS DO PROFESSOR
- enfatizar: normalizar não é burocracia, é o que evita que uma correção tenha de ser feita em dez sítios diferentes.
- erro comum: guardar listas separadas por vírgula num único campo, como "D.2025.014, D.2025.015". É o sinal mais claro de falta de normalização.
- exemplo: perguntar à turma o que acontece se o nome do sítio "Cerro da Vila" estiver mal escrito em 30 peças diferentes, todas copiadas à mão.
NOTAS DO PROFESSOR
- enfatizar as três fases por ordem: primeiro tirar as listas (1FN), depois garantir dependência da chave inteira (2FN), por fim eliminar dependências indiretas (3FN).
- erro comum: achar que normalizar é "criar muitas tabelas pequenas por criar". Cada tabela nova resolve um problema concreto de duplicação, não é um fim em si.
- exemplo/analogia: normalizar é como arrumar uma casa por categorias, roupa na gaveta da roupa, livros na estante, em vez de tudo numa caixa só.
NOTAS DO PROFESSOR
- enfatizar que o tipo de dados é uma decisão técnica com consequência direta nas consultas: não se filtra nem ordena bem um campo mal tipado.
- erro comum: usar texto livre para tudo "para não complicar". Complica depois, nas consultas.
- exemplo: mostrar como um campo `material` como categoria fixa evita "cerâmica", "Ceramica" e "CERAMICA" coexistirem na mesma tabela.
NOTAS DO PROFESSOR
- enfatizar a sequência: primeiro tipos de dados corretos, só depois consultas fiáveis. Uma coisa depende da outra.
- erro comum: tentar filtrar por material quando o campo foi criado como texto livre, com variações de maiúsculas e minúsculas.
- exemplo: mostrar a mesma consulta a falhar com dados mal tipados e a funcionar depois de corrigido o tipo do campo.
NOTAS DO PROFESSOR
- enfatizar: a UE regista se mesmo quando não tem peças associadas, porque documenta a estratigrafia do sítio, não só os achados.
- erro comum: só criar registo de UE quando há peças para lhe associar. A UE tem valor próprio, mesmo vazia de achados.
- exemplo: percorrer a consulta LEFT JOIN em conjunto e explicar porque LEFT JOIN mantém a UE 2010 mesmo que só tenha uma peça.
NOTAS DO PROFESSOR
- enfatizar que desenho e fotografia, apesar de ambos serem "imagens", justificam tabelas próprias por terem atributos distintos e processos de produção diferentes.
- erro comum: tratar desenho e fotografia como a mesma entidade "documentação visual". Perde se informação específica, como a escala.
- pergunta: porque é que a escala só faz sentido no desenho e não na fotografia? (o desenho é traçado a uma escala definida; a fotografia depende da distância e da lente, não tem escala fixa embutida).
NOTAS DO PROFESSOR
- enfatizar que o número de inventário é atribuído uma única vez e nunca reutilizado, mesmo que a imagem seja descartada.
- erro comum: numerar desenhos e fotografias com o mesmo número da peça que documentam. São entidades diferentes, com séries de numeração próprias.
- exemplo: mostrar como dois desenhos da mesma peça (CV.2025.0087) têm dois números de desenho distintos, D.2025.014 e D.2025.015.
NOTAS DO PROFESSOR
- enfatizar que localizacao_original e bibliografia são complementares: uma imagem tem uma ou outra, raramente as duas.
- erro comum: deixar os dois campos vazios "para preencher depois". Sem esta informação, a proveniência da imagem perde-se.
- exemplo: percorrer com a turma a consulta WHERE localizacao_original IS NULL e discutir porque é uma consulta útil de auditoria.
NOTAS DO PROFESSOR
- enfatizar a ordem de leitura da instrução: SELECT o quê, FROM de onde, JOIN com o quê, WHERE com que condição, ORDER BY em que ordem.
- erro comum: esquecer a condição do JOIN (ON ue.id = p.ue_id) e obter um produto cartesiano, com muito mais linhas do que devia.
- exemplo: correr a consulta sem o WHERE e mostrar que aparecem peças de todos os materiais, não só cerâmica.
NOTAS DO PROFESSOR
- enfatizar que uma relação N:M exige sempre dois JOIN na consulta, nunca um só, porque há uma tabela intermédia.
- erro comum: tentar ligar `pecas` diretamente a `desenhos` sem passar por `peca_desenho`. Não há chave estrangeira direta entre as duas.
- exemplo: pedir à turma para escrever a consulta equivalente para `peca_fotografia`, substituindo só os nomes das tabelas.
NOTAS DO PROFESSOR
- enfatizar que o Endovélico é o sistema oficial português, mantido pela DGPC, e que qualquer inventário de campo pode vir a alimentar dados que lá entram.
- erro comum: escolher a ferramenta pela moda em vez de pela necessidade: uma pequena escavação não precisa de um sistema empresarial complexo.
- exemplo: mostrar a mesma tabela `pecas` aberta em SQLite e como se relaciona com o que foi desenhado no diagrama ER do bloco 5.
NOTAS DO PROFESSOR
- enfatizar que o fluxo é conceptual, independente do botão específico de cada programa.
- erro comum: aprender "onde clicar" num software sem perceber porque a ação corresponde a um passo do modelo relacional.
- exemplo: mostrar o mesmo fluxo em Access e em SQLite, com nomes de menu diferentes mas a mesma lógica.
NOTAS DO PROFESSOR
- enfatizar que "implementar" não termina quando as tabelas estão criadas: só está feito quando responde de facto às perguntas do inventário.
- erro comum: dar a base de dados por terminada sem testar nenhuma consulta real.
- exemplo: percorrer com a turma o percurso completo desde a necessidade (bloco 4) até à consulta que a resolve (bloco 13).
NOTAS DO PROFESSOR
- enfatizar que a responsabilidade pelo inventário não acaba na introdução dos dados, continua na manutenção.
- erro comum: guardar o único backup no mesmo disco da base de dados de trabalho.
- exemplo: perguntar à turma o que aconteceria a um projeto de três anos de escavação se o computador de campo se perdesse sem backup.