Sebenta · Gerir bases de dados de unidades estratigráficas, peças, desenhos e fotografias em Arqueologia (UC02355)

Introdução

Esta sebenta ensina a construir e gerir uma base de dados relacional para uma escavação arqueológica: as unidades estratigráficas registadas no terreno, as peças recolhidas, os desenhos técnicos e as fotografias que as documentam. É um trabalho que combina rigor metodológico de arqueologia com competências técnicas de gestão de dados.

O percurso segue o de um assistente de arqueólogo/a real: primeiro analisamos as necessidades (que perguntas a base de dados tem de responder), depois planeamos a estrutura (entidades, atributos, relações), de seguida implementamos uma base de dados normalizada e, por fim, consultamos e mantemos essa base de dados ao longo do projeto. No fim, deves conseguir desenhar, implementar e interrogar uma base de dados de inventário arqueológico completa.

Objetivos de aprendizagem (referencial): analisar as necessidades para a criação da base de dados em Arqueologia; planear e conceber a estrutura da base de dados; implementar uma base de dados normalizada para o inventário do património arqueológico; utilizar ferramentas informáticas para definir o tipo de dados dos campos e criar consultas; cumprir as fases de normalização de dados; referenciar imagens, desenhos e fotografias com número de inventário e localização do original ou bibliografia.

1. Bases de dados: conceitos e princípios

Uma base de dados é um conjunto organizado de informação, estruturado em tabelas, pensado para ser consultado de forma rápida e fiável. É o suporte técnico do inventário do património arqueológico, obrigatório em qualquer intervenção que envolva entidades públicas, museus ou empresas de arqueologia.

Três conceitos são a base de tudo o resto nesta UC:

• Tabela · um conjunto de dados do mesmo tipo (ex.: pecas).
• Registo (linha) · uma ocorrência concreta (uma peça específica).
• Campo (coluna) · um atributo dessa ocorrência (o material, a cronologia).

Princípios de uma boa base de dados

• Consistência: o mesmo tipo de informação escreve-se sempre da mesma forma (por exemplo, o material é sempre "ceramica", nunca "Ceramica" ou "CERÂMICA").
• Não duplicação: cada facto vive num só sítio; o nome de um sítio arqueológico regista-se uma vez, não em cada peça.
• Integridade: as relações entre tabelas mantêm-se corretas quando os dados mudam.
• Unicidade: cada registo tem um identificador que não se repete.

2. Metodologia: pesquisa, recolha e organização de informação

Antes de qualquer software, há um trabalho metodológico de campo. É um dos conhecimentos do referencial: metodologia, pesquisa, recolha e organização de informação.

Pesquisa

Consultar cartas arqueológicas, relatórios de intervenções anteriores no mesmo sítio e bibliografia especializada, antes de iniciar a escavação. Em Portugal, a DGPC (Direção-Geral do Património Cultural) mantém o registo de sítios e intervenções através do sistema Endovélico, ponto de partida obrigatório de qualquer pesquisa prévia.

Recolha

Registar em campo, no momento, com fichas normalizadas:

• Ficha de unidade estratigráfica (UE): preenchida na própria trincheira, antes de a camada ser retirada, porque escavar destrói o contexto.
• Registo de peças: número de inventário atribuído no momento da recolha, nunca depois.
• Fotografia sistemática: antes, durante e depois de cada intervenção.

Organização

• Agrupar por proveniência: tudo o que sai da mesma unidade estratigráfica fica ligado a ela.
• Classificar por tipo: unidade estratigráfica, peça, desenho e fotografia são categorias distintas, nunca misturadas na mesma lista.
• Ordenar cronologicamente: por data de registo e, quando possível, por cronologia atribuída ao contexto.
• Rever antes de introduzir: uma segunda leitura evita erros de transcrição do caderno de campo para a base de dados.

Exemplo resolvido · da ficha de campo ao registo

Uma equipa escava a UE 1042 no sítio de Cerro da Vila e recolhe dois fragmentos de cerâmica no mesmo dia.

1. Preenche a ficha de UE: número, sítio, tipo (camada), descrição, cronologia atribuída.
2. Atribui um número de inventário a cada fragmento, no momento da recolha: CV.2025.0087 e CV.2025.0088.
3. Regista, para cada peça, a ligação à UE de onde saiu, o material e o estado de conservação.
4. Só depois, em gabinete, introduz estes dados na base de dados, conferindo com a ficha de campo.

Resultado: dois registos na tabela pecas, ambos ligados ao mesmo registo UE 1042 na tabela unidades_estratigraficas.

3. Analisar as necessidades e planear a estrutura

Analisar as necessidades

A primeira realização do referencial é analisar as necessidades para a criação da base de dados. A pergunta de partida é sempre: que perguntas a base de dados tem de responder?

• Que peças vieram de uma determinada unidade estratigráfica?
• Que fotografias e desenhos documentam uma peça específica?
• Onde está o original de uma imagem, ou de que bibliografia foi retirada?
• Quantas peças de um determinado material foram recolhidas num sítio?

Planear e conceber a estrutura

A segunda realização é planear e conceber a estrutura da base de dados, em quatro passos:

1. Identificar as entidades (o que vai ter tabela própria): unidade estratigráfica, peça, desenho, fotografia.
2. Definir os atributos (campos) de cada entidade.
3. Definir as relações entre entidades.
4. Rever com um diagrama entidade-relação (ER) antes de criar qualquer tabela no software.

[Unidade Estratigráfica] ──1:N── [Peça] ──N:M── [Desenho]
                                      └──N:M── [Fotografia]

Este diagrama é o mapa seguido nos capítulos seguintes: chaves, cardinalidade e normalização.

4. O modelo relacional

O modelo relacional organiza os dados em tabelas ligadas entre si, em vez de uma tabela gigante com tudo misturado. Cada entidade do mundo real vira uma tabela própria.

Cada atributo guarda um valor, de um tipo, para um registo: é o princípio da atomicidade dos dados, base de toda a normalização do capítulo 6.

Diagrama entidade-relação

UNIDADES_ESTRATIGRAFICAS          PECAS
  id (PK)                          id (PK)
  numero_ue                        numero_inventario
  sitio                            ue_id (FK)
  tipo                             designacao
  descricao                        material
  cronologia                       estado_conservacao
  data_registo                     localizacao_atual

PK identifica de forma única o registo (capítulo 5). FK liga uma tabela a outra (capítulo 5). Desenhar este diagrama antes do software é o que separa uma base de dados robusta de uma feita sem planeamento.

5. Chaves primárias, chaves estrangeiras e cardinalidade

Chave primária

A chave primária (PK) identifica cada registo de forma única, nunca se repete nem fica vazia. Pode ser um número sequencial automático (id) ou um código natural único, desde que garantidamente irrepetível.

CREATE TABLE unidades_estratigraficas (
    id           INTEGER PRIMARY KEY AUTOINCREMENT,
    numero_ue    TEXT NOT NULL UNIQUE,
    sitio        TEXT NOT NULL,
    tipo         TEXT NOT NULL CHECK (tipo IN ('camada','corte','estrutura','enchimento')),
    descricao    TEXT NOT NULL,
    cronologia   TEXT,
    data_registo TEXT NOT NULL
);

Chave estrangeira

A chave estrangeira (FK) é um campo que aponta para a chave primária de outra tabela, criando a relação entre elas.

CREATE TABLE pecas (
    id                  INTEGER PRIMARY KEY AUTOINCREMENT,
    numero_inventario   TEXT NOT NULL UNIQUE,
    ue_id               INTEGER NOT NULL REFERENCES unidades_estratigraficas(id),
    designacao          TEXT NOT NULL,
    material            TEXT NOT NULL CHECK (material IN ('ceramica','metal','vidro','osso','litico')),
    cronologia          TEXT,
    estado_conservacao  TEXT NOT NULL,
    localizacao_atual   TEXT NOT NULL
);

ue_id aponta para unidades_estratigraficas.id. Garante integridade referencial: não é possível registar uma peça ligada a uma unidade estratigráfica que não existe.

Cardinalidade 1:N

Cardinalidade descreve quantos registos de uma tabela se ligam a quantos de outra. Na relação entre unidades estratigráficas e peças: uma UE tem muitas peças, mas cada peça pertence a uma só UE. É uma relação 1:N, resolvida com a chave estrangeira ue_id do lado "muitos" (pecas).

6. Relações muitos para muitos e tabelas de ligação

Em arqueologia, um único desenho ou fotografia (uma prancha, um enquadramento) documenta muitas vezes várias peças ao mesmo tempo, e uma peça pode ter vários desenhos (vistas diferentes) e várias fotografias. Isto é uma relação N:M, que não cabe numa única chave estrangeira.

Resolve-se sempre com uma tabela de ligação (ou tabela associativa), com duas chaves estrangeiras e uma chave primária composta pelas duas:

CREATE TABLE peca_desenho (
    peca_id     INTEGER NOT NULL REFERENCES pecas(id),
    desenho_id  INTEGER NOT NULL REFERENCES desenhos(id),
    PRIMARY KEY (peca_id, desenho_id)
);

CREATE TABLE peca_fotografia (
    peca_id       INTEGER NOT NULL REFERENCES pecas(id),
    fotografia_id INTEGER NOT NULL REFERENCES fotografias(id),
    PRIMARY KEY (peca_id, fotografia_id)
);

A chave primária composta (peca_id + desenho_id) garante que o mesmo par não se repete por engano. Uma tabela de ligação por cada relação N:M é o padrão usado em qualquer base de dados relacional, não só em arqueologia.

7. Normalização de dados

Normalizar é organizar os dados por fases, para eliminar duplicação e garantir que cada facto vive num só sítio. É um critério de desempenho explícito do referencial: cumprir as diferentes fases de normalização de dados para o inventário.

Exemplo resolvido · de tabela não normalizada a 3FN

Tabela não normalizada (má prática, dados reais do sítio Cerro da Vila):

Dois problemas visíveis: o sítio repete-se em cada peça da mesma UE, e o campo desenhos guarda vários valores separados por vírgula, impossibilitando consultar um desenho de cada vez.

Passo 1, primeira forma normal (1FN): cada campo guarda um único valor, sem listas. Separa-se desenhos numa tabela de ligação peca_desenho (capítulo 6).

Passo 2, segunda forma normal (2FN): cada campo depende da chave primária inteira, não só de parte dela. Numa tabela com chave composta, isto obriga a que cada atributo não-chave dependa das duas colunas da chave, não só de uma.

Passo 3, terceira forma normal (3FN): nenhum campo depende de outro campo que não seja a chave primária. Retira-se sitio da tabela pecas, porque já vive em unidades_estratigraficas, acessível pela chave estrangeira ue_id. Guardar sitio em pecas seria uma dependência transitiva: sitio depende de ue_id, que depende de id, não diretamente da peça.

Resultado normalizado: unidades_estratigraficas (com sitio), pecas (com ue_id, sem repetir sitio) e peca_desenho (sem listas em texto). Implementar uma base de dados normalizada para o inventário é a terceira realização do referencial.

8. Tipos de dados dos campos

Cada campo tem um tipo de dados, que define o que pode guardar e como pode ser tratado nas consultas. É um critério de desempenho: utilizar ferramentas informáticas para definir o tipo de dados dos campos.

Escolher bem o tipo evita erros: um campo data mal definido como texto livre permite escrever "10 de maio" numa peça e "2025-05-10" noutra, impossibilitando ordenar por data. Um campo material como categoria fixa evita "cerâmica", "Ceramica" e "CERAMICA" coexistirem na mesma tabela.

9. As quatro bases: unidades estratigráficas, peças, desenhos e fotografias

O referencial pede explicitamente o domínio de diferentes tipos de bases de dados: unidades estratigráficas, peças, desenhos e fotografias. São quatro entidades com atributos próprios:

• Unidade estratigráfica (UE): a unidade mínima de escavação (camada, corte, estrutura, enchimento). Regista-se mesmo sem peças associadas, porque documenta a estratigrafia, não só os achados.
• Peça: um objeto recolhido, ligado a uma UE. Número de inventário, material, cronologia, estado de conservação.
• Desenho: registo gráfico rigoroso, com escala definida (ex.: 1:1, 1:2).
• Fotografia: registo visual, com formato (digital ou analógico), sem escala fixa embutida.

SELECT ue.numero_ue, COUNT(p.id) AS total_pecas
FROM unidades_estratigraficas ue
LEFT JOIN pecas p ON p.ue_id = ue.id
GROUP BY ue.numero_ue;

10. Referenciar imagens: inventário e localização do original

Atribuir número de inventário fotográfico e de desenho

Cada desenho e cada fotografia recebe um número de inventário próprio, único e sequencial. Convenção usada nesta sebenta: D.ANO.SEQUENCIAL para desenhos (ex.: D.2025.014) e F.ANO.SEQUENCIAL para fotografias (ex.: F.2025.221). É uma aptidão explícita do referencial: atribuir número de inventário fotográfico ou de desenho.

Registar o local do original ou a bibliografia

Para cada desenho e fotografia regista-se onde está o original (arquivo, instituição), ou, quando a imagem vem de uma publicação, a bibliografia de onde foi retirada. É a última aptidão explícita do referencial ligada às imagens.

Exemplo resolvido · consulta de auditoria

SELECT numero_desenho, autor, bibliografia
FROM desenhos
WHERE localizacao_original IS NULL;

Resultado real: D.2025.028, João Aveiro, "Aveiro, J. (2024). Metalurgia do Cerro da Vila, p. 45, fig. 12". Este desenho não tem original no arquivo próprio; foi reproduzido de uma publicação. Os campos localizacao_original e bibliografia são complementares: uma imagem tem um ou outro, raramente os dois.

11. Criar consultas

Manusear os campos existentes para criar consultas é o segundo critério de desempenho do referencial. Uma consulta (query) pede à base de dados um subconjunto de dados, filtrado, ordenado ou cruzado entre tabelas.

A instrução SELECT

SELECT p.numero_inventario, p.designacao, ue.sitio
FROM pecas p
JOIN unidades_estratigraficas ue ON ue.id = p.ue_id
WHERE p.material = 'ceramica'
ORDER BY p.numero_inventario;

Resultado real (3 peças): AL.2025.0031 · Castelo de Alcácer, CV.2025.0087 · Cerro da Vila, CV.2025.0088 · Cerro da Vila.

• SELECT escolhe os campos.
• FROM indica a tabela principal.
• JOIN cruza com outra tabela, segundo a condição em ON.
• WHERE filtra os registos.
• ORDER BY define a ordem do resultado.

Consultas através de tabelas de ligação (N:M)

Para consultar através de uma tabela de ligação são precisos dois JOIN: um até à tabela de ligação, outro até à tabela final.

SELECT p.numero_inventario, d.numero_desenho, d.autor, d.escala
FROM pecas p
JOIN peca_desenho pd ON pd.peca_id = p.id
JOIN desenhos d ON d.id = pd.desenho_id
WHERE p.numero_inventario = 'CV.2025.0087';

Resultado real: CV.2025.0087 → D.2025.014, Marta Pinheiro, escala 1:1. Esta consulta responde exatamente à pergunta de partida do capítulo 3: que desenhos documentam esta peça?

12. Software de gestão de bases de dados

O referencial pede o domínio de aplicações informáticas: sistemas de gestão de bases de dados.

Independentemente da ferramenta, o fluxo de trabalho é sempre o mesmo:

1. Criar as tabelas com os campos e tipos definidos.
2. Definir as chaves primárias e estrangeiras.
3. Introduzir os dados, um registo de cada vez, com rigor.
4. Verificar a integridade: nenhuma chave estrangeira aponta para um registo inexistente.
5. Consultar com filtros, ordenações e cruzamentos.

A competência transfere-se entre softwares: o que se aprende no modelo relacional serve em qualquer ferramenta, do Access ao Endovélico.

13. Manutenção, backups e RGPD

Implementar a base de dados não termina quando as tabelas estão criadas: só está feito quando responde de facto às perguntas do inventário e é mantida ao longo do projeto.

• Backups regulares da base de dados, em local diferente do computador de campo.
• Cópias de segurança antes de qualquer alteração estrutural às tabelas.
• RGPD: quando a base de dados regista nomes de escavadores, proprietários de terrenos ou colaboradores, aplicam-se as regras de proteção de dados pessoais, incluindo a limitação do acesso a quem precisa desses dados e a eliminação quando deixam de ser necessários.
• Documentar as decisões de estrutura, para quem continuar o trabalho depois.

Atitudes do referencial em jogo: responsabilidade pelas suas ações, autonomia no âmbito das suas funções, sentido de organização, empenho e persistência na resolução de problemas e respeito pelas normas e regras definidas.

Erros comuns

• Meter tudo numa tabela só, em vez de separar por entidade. É o oposto do modelo relacional.
• Repetir o nome do sítio em cada peça, em vez de o guardar uma vez na unidade estratigráfica e aceder por chave estrangeira.
• Guardar listas separadas por vírgula num único campo (como vários números de desenho), quebrando a 1FN.
• Colocar a chave estrangeira do lado errado numa relação 1:N (tem de ficar do lado "muitos").
• Tentar resolver uma relação N:M com uma única chave estrangeira, sem tabela de ligação.
• Numerar desenhos e fotografias com o número da peça, em vez de terem série própria.
• Deixar localizacao_original e bibliografia vazios, perdendo a rastreabilidade da imagem.
• Esquecer o backup, confiando num único ficheiro no computador de campo.

Glossário

• Base de dados: conjunto organizado de informação, estruturado em tabelas.
• Tabela: conjunto de registos do mesmo tipo.
• Registo: uma ocorrência concreta numa tabela (uma linha).
• Campo: um atributo de um registo (uma coluna).
• Chave primária (PK): identifica de forma única cada registo de uma tabela.
• Chave estrangeira (FK): campo que aponta para a chave primária de outra tabela.
• Cardinalidade: quantidade de registos de uma tabela que se ligam a quantidade de registos de outra (1:N, N:M).
• Tabela de ligação: tabela intermédia usada para resolver relações N:M.
• Normalização: processo por fases (1FN, 2FN, 3FN) que elimina duplicação de dados.
• Integridade referencial: garantia de que uma chave estrangeira aponta sempre para um registo existente.
• Consulta (query): instrução que pede um subconjunto de dados à base de dados.
• JOIN: operação que cruza duas tabelas segundo uma condição.
• Unidade estratigráfica (UE): unidade mínima de escavação identificada no terreno.
• Endovélico: sistema nacional de inventário do património arqueológico da DGPC.
• RGPD: Regulamento Geral sobre a Proteção de Dados, aplicável a dados pessoais registados na base de dados.

Síntese

Gerir uma base de dados de arqueologia segue sempre a mesma ordem: analisar as necessidades (que perguntas responder) → planear a estrutura (entidades, atributos, diagrama ER) → definir chaves (primárias e estrangeiras, cardinalidade 1:N e N:M) → normalizar (1FN, 2FN, 3FN) → definir tipos de dados → implementar as quatro tabelas (unidades estratigráficas, peças, desenhos, fotografias) → referenciar imagens com número de inventário e localização do original ou bibliografia → consultar com SQL → manter, com backups e RGPD. Domina este fluxo e aplicas-te a qualquer software de gestão de bases de dados, do Access ao Endovélico.

Exercícios resolvidos

1. Uma equipa quer saber quantas peças saíram de cada unidade estratigráfica. Que tipo de consulta é preciso e que resultado esperarias com os dados de exemplo desta sebenta?

Resolução: uma consulta com JOIN (ou LEFT JOIN, para incluir UEs sem peças) e GROUP BY sobre unidades_estratigraficas.numero_ue, contando os registos de pecas ligados por ue_id. Com os dados de exemplo: UE 1042 → 2 peças, UE 1043 → 1 peça, UE 2010 → 1 peça.

2. Um colega guarda, na tabela pecas, um campo desenhos com o texto "D.2025.014, D.2025.015". Que problema é este e como se resolve?

Resolução: viola a primeira forma normal (1FN), porque o campo guarda vários valores separados por vírgula em vez de um só. Resolve-se com uma tabela de ligação peca_desenho, com uma linha por par peça-desenho, permitindo consultar cada desenho individualmente.

3. Porque é que o campo sitio não deve estar na tabela pecas, mesmo sabendo que cada peça pertence a um sítio?

Resolução: porque sitio já é um atributo de unidades_estratigraficas, e a peça acede a ele através da chave estrangeira ue_id. Repeti-lo em pecas seria uma dependência transitiva (viola a 3FN) e criaria duplicação: se o nome do sítio mudasse, teria de ser corrigido em todas as peças.

4. Uma fotografia documenta três peças diferentes numa mesma prancha. Que tipo de relação é esta entre pecas e fotografias, e como se implementa?

Resolução: é uma relação muitos para muitos (N:M), porque uma fotografia documenta várias peças e uma peça pode ter várias fotografias. Implementa-se com uma tabela de ligação peca_fotografia, com peca_id e fotografia_id como chaves estrangeiras e chave primária composta pelas duas.

5. Um desenho não tem localização de original registada. Que consulta SQL identifica todos os desenhos nesta situação, e qual é o resultado nos dados de exemplo?

Resolução: SELECT numero_desenho, autor, bibliografia FROM desenhos WHERE localizacao_original IS NULL;. Nos dados de exemplo, devolve D.2025.028, João Aveiro, cuja bibliografia é "Aveiro, J. (2024). Metalurgia do Cerro da Vila, p. 45, fig. 12".