Um dado é um valor registado: 3, 101 ou 12/09/2026. Isoladamente, pode dizer pouco. Quando sabemos que 3 é a quantidade de cadernos da encomenda 101, o valor ganha significado. A informação resulta da interpretação dos dados num contexto.

Uma situação concreta

Há três linhas, mas apenas duas encomendas. A encomenda 101 contém dois produtos. Contar linhas como se fossem encomendas produziria uma informação errada. Antes de calcular, é necessário perceber o que cada linha representa.

Uma base de dados é um conjunto organizado de dados relacionados. O seu modelo descreve a estrutura desses dados e as regras que os ligam. No modelo relacional, organizamos a informação em relações, habitualmente representadas por tabelas.

Guardar e consultar

A mesma base de dados pode responder a perguntas diferentes: quais os produtos de uma encomenda, quantas encomendas fez um cliente ou que quantidade de um produto foi encomendada. Para isso, é necessário guardar os factos com significado consistente.

Dados corretos não garantem, por si só, uma interpretação correta. A pergunta, a unidade de medida e o período analisado também fazem parte do contexto. “Vendeu 20” é diferente de “vendeu 20 unidades nesta semana”.

O Sistema de Gestão de Bases de Dados, ou SGBD, é o software que permite definir estruturas, guardar e consultar dados e controlar o acesso. A base de dados é o conjunto organizado de dados; o SGBD é o software que o gere.

Num sistema cliente-servidor, uma aplicação envia pedidos ao servidor de base de dados. O SGBD interpreta esses pedidos, verifica permissões e regras e acede aos dados guardados. O resultado regressa à aplicação, que o apresenta ao utilizador.

Componentes e funções

O utilizador normalmente trabalha através do SGBD e não altera diretamente os seus ficheiros internos. Uma cópia de segurança permite recuperar dados; o modelo, por si só, não substitui essa proteção.

Três níveis de descrição

O nível conceptual descreve o negócio, como Cliente e Encomenda. O nível lógico define tabelas, chaves e relações. O nível físico concretiza a estrutura num SGBD, incluindo tipos de dados e índices. Uma vista pode apresentar apenas parte da informação a um utilizador.

Uma tabela representa um conjunto de ocorrências com a mesma estrutura. Cada registo, ou linha, corresponde a uma ocorrência; cada campo, ou coluna, descreve uma característica. O nome de um campo deve ajudar a compreender o valor que contém.

Esta tabela tem três registos e três campos. O produto 10 não é “a primeira linha”: é o produto identificado pelo valor 10. A ordem das linhas pode mudar sem alterar o significado dos dados. Uma ordenação de apresentação deve ser pedida explicitamente.

Domínio e significado

O domínio de um campo define os valores admissíveis. Uma quantidade pode aceitar apenas inteiros positivos. Uma data deve ser uma data válida. Um telefone é habitualmente texto, pois não é usado em cálculos e pode conter um indicativo ou zeros iniciais.

NULL representa a ausência de um valor, por exemplo um contacto ainda desconhecido. Não significa automaticamente zero, texto vazio ou “não”. É necessário documentar quando essa ausência é permitida e o que significa no sistema.

Estrutura e conteúdo

O esquema descreve os campos e as regras da tabela. Os dados são o seu conteúdo num determinado momento. Acrescentar um produto altera os dados; acrescentar o campo categoria altera o esquema.

Uma chave candidata é um conjunto mínimo de atributos que identifica cada registo de forma única. “Mínimo” significa que nenhum dos seus atributos pode ser retirado sem perder essa propriedade. Escolhemos uma das chaves candidatas como chave primária, ou PK.

As outras chaves candidatas são chaves alternativas. Uma chave simples usa um atributo; uma chave composta usa mais de um. Uma chave natural tem significado no negócio. Uma chave artificial, como um identificador interno, é criada para identificar o registo.

Exemplo resolvido

Dois clientes podem ter o mesmo nome, por isso nome não é uma boa chave primária. No nosso caso, id_cliente é um identificador interno único. Um número fiscal só seria uma chave candidata se as regras garantissem que está presente e é único para todos os clientes abrangidos.

Uma chave estrangeira, ou FK, referencia uma chave primária ou outra chave com unicidade adequada noutra tabela, ou na própria tabela. Em Encomenda, id_cliente indica a quem pertence a encomenda. Pode repetir-se porque um cliente pode ter várias encomendas.

Na nossa regra simplificada, cada produto aparece uma só vez em cada encomenda; a quantidade acumula as unidades. Por isso, o par id_encomenda e id_produto identifica uma linha. Se a regra mudar, será necessário rever a chave.

A integridade protege a coerência dos dados. As restrições traduzem parte das regras do negócio em condições verificáveis. Uma base de dados pode aceitar valores tecnicamente válidos que, ainda assim, violam uma regra não implementada.

Exemplo resolvido

Existem os clientes 1 e 2. Uma encomenda com id_cliente igual a 9 deve ser recusada: aponta para um cliente inexistente. Se id_cliente fosse opcional, NULL poderia representar uma relação ausente; aqui cada encomenda tem obrigatoriamente um cliente.

Eliminar um cliente com encomendas exige uma decisão. Neste caso, bloqueamos a eliminação enquanto houver referências. Apagar em cascata pode eliminar dados dependentes; só faz sentido quando corresponde às regras definidas. Não deve ser escolhido por conveniência.

Uma FK garante a existência da referência, mas não obriga uma encomenda a ter linhas. Algumas regras precisam de operações coordenadas ou de validação adicional na aplicação ou no SGBD. A transação permite tratar um conjunto de alterações como uma unidade.

Modelar começa por compreender o que o sistema tem de guardar e que perguntas deve responder. Uma frase vaga deve ser transformada em regras que possam ser discutidas e testadas. Não se deduzem todas as regras a partir de uma pequena amostra de dados.

Requisitos da Papelaria Horizonte

• Cada cliente tem identificador, nome e um contacto opcional. Pode existir antes de fazer uma encomenda.
• Cada encomenda tem identificador, data e exatamente um cliente. Neste modelo apenas guardamos encomendas confirmadas, com uma ou mais linhas.
• Cada produto tem identificador, designação e preço atual. Pode existir sem ter sido encomendado.
• Cada linha pertence a uma encomenda e refere um produto; guarda quantidade e preço unitário praticado.
• O mesmo produto aparece no máximo uma vez em cada encomenda. O preço praticado pode diferir do preço atual.

Fronteiras comportamento e implementação

A fronteira define o que pertence ao sistema: clientes, produtos e encomendas estão incluídos; salários, pagamentos, stock e documentos fiscais ficam fora deste exercício. O comportamento descreve operações e regras, como confirmar uma encomenda. A implementação concretiza essas decisões em tabelas e restrições.

Exemplo de operação: selecionar um cliente existente, criar a encomenda, adicionar os produtos e quantidades e confirmar o conjunto. Se faltar um produto válido ou uma quantidade positiva, a operação não fica concluída.

Uma entidade representa um tipo de objeto ou acontecimento relevante para o problema: Cliente, Produto ou Encomenda. Uma ocorrência é um exemplo concreto desse tipo: o cliente 1 ou a encomenda 101. Um atributo descreve uma característica da entidade.

Tipos de atributos

A decomposição depende das necessidades. Se for necessário pesquisar por localidade, misturá-la com toda a morada dificulta essa utilização. Um atributo multivalorado não deve ser convertido numa lista de valores dentro de uma célula do modelo relacional.

Exemplo resolvido

“A Ana fez uma encomenda de três cadernos” contém uma ocorrência de Cliente, uma de Encomenda e uma de Produto. A quantidade 3 pertence à associação entre a encomenda e o produto: o mesmo produto pode ter outra quantidade noutra encomenda.

A quantidade não é um atributo permanente de Produto. O preço atual pertence ao produto, mas o preço praticado pertence à linha da encomenda, porque descreve aquela compra. Esta distinção permite manter o histórico de valores.

Uma relação associa ocorrências de entidades. A cardinalidade máxima indica quantas ocorrências podem estar associadas; a mínima indica se a participação é obrigatória. Neste manual usamos pares mínimo e máximo: 0..1, 1..1, 0..N e 1..N.

N significa “muitos”, sem fixar um número concreto. Uma relação 1:N liga uma ocorrência de um lado a várias do outro. N:M permite várias ocorrências em ambos os sentidos. Uma relação 1:1 limita ambos os lados a uma ocorrência, sem definir, por si só, se a participação é obrigatória.

Exemplo resolvido

Uma encomenda pode incluir vários produtos e um produto pode surgir em várias encomendas. Conceptualmente, Encomenda e Produto têm uma relação N:M. Para guardar quantidade e preço praticado, a associação será representada por LinhaEncomenda.

Ao desenhar, inclua uma legenda da notação utilizada. Em diferentes notações, os símbolos podem ter convenções de leitura distintas. Confirme sempre a relação com duas frases: “para uma ocorrência de A, quantas B?” e “para uma ocorrência de B, quantas A?”.

Na transformação para o modelo relacional, cada entidade origina normalmente uma tabela. Definem-se as chaves e colocam-se as referências de forma a representar as relações sem listas de identificadores dentro das células.

Esquema relacional do caso

Cliente(id_cliente [PK], nome, contacto)

Produto(id_produto [PK], designacao, preco_atual)

Encomenda(id_encomenda [PK], data, id_cliente [FK])

LinhaEncomenda(id_encomenda [PK, FK], id_produto [PK, FK], quantidade, preco_unitario)

Os dois atributos assinalados como PK em LinhaEncomenda formam uma única chave composta. Não são duas chaves primárias independentes. id_cliente referencia Cliente; as duas FK da linha referenciam Encomenda e Produto, respetivamente.

O que conseguimos representar

Um cliente pode ter várias encomendas sem repetirmos o seu nome em todas. Cada encomenda pode ter vários produtos através das linhas. O preço atual pode mudar sem alterar o preço guardado na encomenda. O total calcula-se somando quantidade × preco_unitario de cada linha.

O dicionário de dados documenta cada campo: significado, tipo, obrigatoriedade e restrições. Permite que pessoas diferentes interpretem o modelo da mesma maneira. Os tipos concretos devem ser confirmados no SGBD utilizado; aqui descrevemos escolhas gerais.

A dimensão dos campos e os limites numéricos dependem do negócio. Valores monetários exigem representação decimal adequada. Um índice pode acelerar pesquisas, mas ocupa espaço e tem custo nas alterações; não substitui a definição das regras.

Procedimento de validação

Primeiro confirme o esquema e as referências. Depois introduza alguns registos fictícios e experimente operações válidas e inválidas. Registe o resultado esperado e o observado. Se existir implementação no SGBD, distinga as regras declaradas nas tabelas das que são verificadas pela aplicação.

Normalizar é organizar relações com base nas dependências entre atributos, reduzindo redundâncias e anomalias. Não significa eliminar todos os valores repetidos. Uma FK repetida pode ser necessária para representar corretamente uma relação 1:N.

Uma lista ainda não normalizada

A última coluna guarda um grupo repetido de produtos. Não existe uma estrutura uniforme para cada item. Acrescentar produto1, produto2 e produto3 criaria um limite artificial e obrigaria a alterar o esquema para encomendas maiores.

Três anomalias

Atualização: se o nome do cliente aparecer em muitas linhas, uma mudança pode ser aplicada apenas a algumas. Inserção: se produtos só existirem dentro de encomendas, não podemos registar um novo produto sem inventar uma encomenda. Eliminação: apagar a única encomenda de um produto pode fazer perder a sua descrição.

Dependência funcional

Escrevemos A → B quando o valor de A determina um único valor de B segundo as regras do problema. Por exemplo, id_cliente → nome. A repetição de um nome não implica que nome → id_cliente: duas pessoas podem ter o mesmo nome.

Uma relação em primeira forma normal, ou 1FN, não contém grupos repetidos nem listas de valores dentro de um atributo: cada posição contém um único valor do domínio escolhido. A atomicidade depende do significado adotado; um texto não precisa de ser dividido em letras.

Transformação resolvida

Transformamos a lista em linhas, uma por produto de cada encomenda. Os campos data e preco_unitario também fazem parte da relação, embora estejam omitidos nesta amostra para facilitar a leitura.

A relação completa é R(id_encomenda, data, id_cliente, nome, id_produto, designacao, quantidade, preco_unitario). A chave candidata considerada neste exercício é o par (id_encomenda, id_produto), porque um produto só pode aparecer uma vez em cada encomenda.

A estrutura já não tem listas e está em 1FN, mas repete o nome do cliente e a descrição do produto. A primeira forma normal não resolve todas as anomalias. Precisamos de analisar de que atributos depende cada informação.

Uma distinção necessária

Três unidades do mesmo produto ocupam uma linha com quantidade 3. Três produtos diferentes ocupam três linhas. O que identifica o registo é a combinação definida pela regra, não o número de unidades.

Uma relação está em segunda forma normal, ou 2FN, se estiver em 1FN e nenhum atributo não primo depender apenas de parte de uma chave candidata composta. Um atributo primo pertence a alguma chave candidata. Neste exercício consideramos apenas a chave candidata composta indicada na tema anterior.

Analisar as dependências

A data depende apenas da encomenda, e a designação depende apenas do produto. São dependências parciais em relação à chave composta. A quantidade e o preço praticado descrevem a combinação encomenda-produto.

Decomposição resolvida

Encomenda_2FN(id_encomenda [PK], data, id_cliente, nome)

Produto(id_produto [PK], designacao)

LinhaEncomenda(id_encomenda [PK, FK], id_produto [PK, FK], quantidade, preco_unitario)

A data deixa de se repetir em cada linha de produto, e a designação passa a ser guardada uma vez por produto. Encomenda_2FN ainda repete o nome de clientes com várias encomendas. Esse problema será tratado na 3FN.

Se todas as chaves candidatas forem simples, não há uma parte própria de uma chave à qual um atributo possa ficar dependente; estando em 1FN, a relação satisfaz a 2FN. Acrescentar um identificador artificial não elimina dependências das outras chaves candidatas.

Uma relação está em terceira forma normal, ou 3FN, se, para cada dependência funcional não trivial X → A, X for uma superchave ou A for um atributo primo. Uma superchave identifica os registos, podendo incluir atributos desnecessários; uma chave candidata é uma superchave mínima.

Nos exemplos deste manual, a verificação prática consiste em partir da 2FN e retirar dependências transitivas de atributos não primos em relação à chave. É necessário conhecer as regras do negócio para fazer esta análise.

Transformação resolvida

Em Encomenda_2FN, id_encomenda → id_cliente e id_cliente → nome. O nome depende da chave através do cliente. Como id_cliente não identifica uma encomenda e nome não é primo, esta dependência impede a 3FN.

Cliente(id_cliente [PK], nome)

Encomenda(id_encomenda [PK], data, id_cliente [FK])

Produto e LinhaEncomenda mantêm a estrutura obtida na 2FN. Com as dependências assumidas, as quatro relações ficam em 3FN. Acrescentamos contacto a Cliente e preco_atual a Produto para completar os requisitos do caso.

Preservar os factos

A separação não pode perder encomendas nem criar associações falsas. A ligação entre Encomenda e Cliente usa id_cliente, que é único em Cliente. Assim, cada encomenda recupera exatamente o cliente correspondente. As dependências principais ficam verificáveis nas tabelas onde os factos são guardados.

O preço praticado na encomenda não é uma cópia dispensável do preço atual: representa um facto histórico diferente. Alterar preco_atual não deve alterar automaticamente os valores de encomendas anteriores.

Utilize o esquema da tema 9 para reconstruir os dados seguintes nas quatro tabelas. Esta oficina articula modelação, normalização e verificação. Tempo de referência: 75 minutos, incluído no bloco final de quatro horas.

No catálogo atual, o caderno custa 2,80 euros, a caneta 1,20 euros e a pasta 3,00 euros. Existe ainda o produto 40, Borracha, a 0,80 euros, sem encomendas. A cliente 3, Carla, está registada mas ainda não encomendou. Os contactos não foram fornecidos.

Tarefas

• Preencha as quatro tabelas sem perder clientes nem produtos sem encomendas.
• Assinale cada PK e FK. Confirme a chave composta das linhas.
• Calcule o total de cada encomenda a partir dos preços praticados.
• Altere o nome da cliente 1 para Ana Martins e indique quantos registos precisam de alteração.
• Mostre onde fica guardado o produto 40 e justifique por que não precisa de inventar uma encomenda.

Testes a executar ou simular

Tente criar uma encomenda para o cliente 99; repetir o produto 10 na encomenda 101; inserir quantidade zero; eliminar um produto referenciado. Para cada tentativa, indique o resultado esperado e a regra que o justifica.

Verificação de controlo

O conjunto final deve conter 3 clientes, 4 produtos, 3 encomendas e 4 linhas de encomenda. A encomenda 101 totaliza 9,90 euros. Se obtiver outro resultado, reveja a multiplicação das quantidades e a distinção entre preço atual e preço praticado.

Um modelo também deve considerar as pessoas a quem os dados dizem respeito. O RGPD estabelece princípios como finalidade, minimização, exatidão, limitação da conservação e segurança. A proteção de dados deve ser considerada desde a conceção do sistema [2, artigos 5 e 25].

Em termos de modelação, justifique a necessidade de cada campo pessoal, planeie quem pode aceder aos dados e evite recolher informação sem finalidade definida. Um identificador interno continua a poder estar associado a uma pessoa; substituir o nome por um código não garante anonimização.

Neste manual, os nomes e os restantes dados são fictícios. Não use listas reais de clientes ou colegas nos exercícios. As decisões concretas sobre fundamentos de tratamento e conservação devem ser enquadradas pela organização e pelas regras aplicáveis.

Revisão do trabalho de outro grupo

Tempo de referência: 25 minutos. Troquem os modelos da oficina e verifiquem: há chaves em todas as tabelas? As cardinalidades correspondem às regras? As FK apontam para chaves adequadas? Há listas em células? O preço histórico está protegido de alterações ao catálogo?

Entreguem dois comentários fundamentados: um ponto correto e uma melhoria necessária. O grupo revisto deve aceitar a sugestão ou justificar a manutenção da sua decisão. O objetivo é praticar análise, responsabilidade e comunicação técnica.

Tempo proposto: 80 minutos de trabalho individual e 25 minutos de discussão ou verificação oral, completando as quatro horas do bloco final. As verificações individuais podem decorrer durante o trabalho. O formador define as condições e os recursos permitidos.

Enunciado

Um centro de formação regista formandos e ações de formação. Cada formando tem identificador, nome e contacto opcional. Cada ação tem identificador, designação e data de início. Um formando pode inscrever-se em várias ações e uma ação pode ter vários formandos. Há uma só inscrição por par formando-ação. Cada inscrição guarda a data de inscrição e uma classificação final opcional, de 0 a 20. Formandos e ações podem existir sem inscrições.

A lista inicial tem os campos id_formando, nome, contacto, id_acao, designacao_acao, data_inicio, data_inscricao e classificacao. Os dados pessoais dependem do formando; a designação e o início dependem da ação; a inscrição e a classificação dependem do par.

Entregas

• Identifique entidades, atributos e regras, incluindo a interpretação da classificação ausente.
• Desenhe o modelo com cardinalidades mínimas e máximas.
• Apresente a normalização da lista e o esquema final com PK e FK.
• Defina tipos e restrições para os campos e crie exemplos fictícios.
• Descreva dois testes que devem ser aceites e dois que devem ser recusados.
• Explique oralmente uma escolha e adapte o modelo a uma alteração apresentada pelo formador.

Em cada critério: 4 pontos para uma solução correta e fundamentada; 3 para pequenas falhas; 2 para compreensão parcial; 1 para uma tentativa com erros essenciais; 0 para ausência de evidência. Esta grelha é uma proposta de trabalho, não uma regra do referencial.

Fontes e enquadramento

[1] Catálogo de Qualificações. UC00602 — Modelar bases de dados relacionais. Documento disponibilizado pelo formador, criado em 22/03/2025. Realizações na página 1, conhecimentos e critérios na página 2 e recursos na página 3.

[2] Parlamento Europeu e Conselho. Regulamento (UE) 2016/679, artigos 5 e 25. EUR-Lex. Consulta em 12/09/2026. Consultar no EUR-Lex ↗

A duração de 25 horas foi indicada pelo formador. A sequência, os tempos, os exemplos, os exercícios e a grelha de avaliação são propostas pedagógicas deste manual. O percurso até à 3FN concretiza o tema da normalização para esta ação.