✅ MODELO RELACIONAL

O modelo relacional de Bases de Dados é um dos modelos mais utilizados atualmente pois é adotado pela maioria dos SGBD, como MySQL, PostgreSQL, Oracle Database e SQL Server, entre outros.

Desenvolvido por Edgar F. Codd, na década de 1970

📌 Definição

O Modelo Relacional de Bases de Dados armazena e organiza os dados em tabelas (relações), que se relacionam entre si através de chaves primárias (PK) e estrangeiras (FK).

Tabela ALUNOS da entidade ALUNO

📌CARACTERÍSTICAS

os dados são armazenados em tabelas (linhas e colunas)
Cada tabela representa uma entidade do mundo real (por exemplo: Aluno, Produto, Consulta)
Cada linha corresponde a um registo (tuplo).
Cada coluna/campo corresponde a um atributo da entidade.
utiliza chaves primárias para identificar de forma única cada registo da tabela
utiliza chaves estrangeiras para criar relações entre as tabelas
Permite a manipulação dos dados através da linguagem SQL.

Relacionamento da Tabela ALUNOS com a Tabela CURSOS

📌 Vantagens do modelo relacional

Boa organização dos dados - Os dados são estruturados em tabelas (ou relações), facilitando o entendimento e a gestão das informações.
Redução da redundância de dados - Evita a duplicação de informações, economizando espaço e prevenindo inconsistências.
Garante a integridade e consistência dos dados – Regras como chaves primárias e estrangeiras garantem que os dados permaneçam corretos e confiáveis.
Facilita a pesquisa e atualização da informação - A linguagem SQL permite consultas complexas, além de inserções, alterações e exclusões de dados de forma eficiente.
Permite segurança e controlo de acessos – É possível definir quem pode ler, inserir ou alterar informações, garantindo proteção e privacidade dos dados.
Amplamente utilização - É o modelo mais adotado em sistemas atuais, com grande suporte de ferramentas e profissionais especializados.

🔹 Estrutura das tabelas

🧠 Nome da tabela: deve refletir os dados que ela guarda

TABELA: Estrutura bidimensional que armazena dados de uma entidade.

LINHA ou REGISTO: Representa uma ocorrência específica de uma entidade (linha de dados)

CAMPO ou COLUNA: representa as características/ propriedades (atributo) da entidade.

DOMÍNIO: Define os valores permitidos para um atributo.

(ex: no campo IdCurso, os domínios são os valores: 290 , 122 ,etc )

🔑 Chave Primária (Primary Key - PK)

✅ Definição

Chave Primária é um Campo (ou conjunto de campos) que Identifica de forma única cada registo de uma tabela.

✔️ Características

Não pode repetir valores
Não pode ser nula (vazia)
Existe apenas uma PK por tabela

🔗 Chave Estrangeira (Foreign Key – FK)

✅ Definição

Campo que liga uma tabela a outra, referenciando a chave primária de outra tabela.

✔️ Serve para:

criar relações entre tabelas
manter integridade dos dados

🔑 Chave Candidata (Candidate Key)

✅ Definição:

É qualquer campo (ou conjunto de campos) que identificar de forma única cada registo de uma tabela e que pode ser selecionado para ser a chave primária.

👉 EXEMPLO:

Na tabela Alunos podemos ter vários campos podem ser candidatos a PK: NProcesso, NIF, CC

Deve escolher a que melhor representa a respetiva tabela para ser a chave primária

🔑 Chave Composta (Composite Key)

✅ Definição:

👉 É uma chave primária formada por dois ou mais campos, cuja combinação identifica de forma única cada registo de uma tabela.

Exemplo:

É o caso mais comum.

Tabela Inscrições

NProcesso	IdDisciplina
123 123	SI OEAG

👉 Assim, a chave primária é formada por 2 campos (chave composta).

🔑 PK = (NProcesso + idDisciplina)

Atualmente, usa-se pouco a chave composta, sendo substituída um campo único (chave artificial) de auto-incremento.

🔑 PK = IdInscricao (auto-incremento)

Em teoria (exames de BD)

👉 Usar chave composta é o mais comum.

Em sistemas reais

👉 Quase sempre usa-se chave artificial.

RESUMO

Numa relação de 1 :1 normalmente o modelo ER converte em 1 ou 2 tabelas.
Numa relação de 1 : M o modelo E-R transforma-se em 2 tabelas
Numa relação de M:M o modelo E-R é convertido em 3 tabelas

A normalização poderá forçar a criação de novas tabelas, dependendo dos dados que estamos a tratar

NORMALIZAÇÃO

✅ Definição:

Normalização é o processo de organizar os dados em uma Base de Dados Relacional para eliminar redundâncias e garantir consistência e a integridade dos dados, através da aplicação de um conjunto de regras chamadas Formas Normais.

✅Principais objetivos da normalização

Eliminar redundância de dados
→ Evita dados repetidos
Evitar inconsistências
→ Impede que o mesmo dado tenha valores diferentes em tabelas distintas.
Facilitar manutenção
→ Inserir, atualizar e apagar dados torna-se mais simples.
Melhorar organização
→ Os dados ficam divididos em tabelas lógicas e bem relacionadas.

📊 As 3 Formas Normais

🔹 1ª Forma Normal (1FN) -

Regra:

- Cada campo deve ter apenas um único valor (valor atómico)
-Não pode haver multivalores dentro de uma célula
Solução:

- Se houver atributos com valores compostos (ex: Endereço) devem dividir em campos de valores atómicos

- Se houver atributos com valores multivalores devem adiciona novos registos

🔹 2ª Forma Normal (2FN)
Regra:

- Deve estar na 1FN

- todos os campos não-chave dependem da chave primária.
- Não pode existir dependências parciais — cada campo deve depender de toda a chave, não só de um componente dela.
(A 2FN poderá ser um problema quando a tabela tem chave primária composta e se houver dependência parcial)

🔹 3ª Forma Normal (3FN)

Regra:

-a tabela deve estar na 2FN

- Nenhum campo depende de outro campo que não seja chave primária, ou seja,
- não existem dependências transitivas A → B → C
(atributo não pode depender de outro atributo que não seja chave)

Resumo das 3 Formas Normais

Forma Normal	Regra principal	Objetivo
1FN – Primeira Forma Normal	Cada campo deve ter apenas um único valor (valores atómicos), sem multivalores ou grupos repetidos	Evitar campos múltiplos e organizar dados
2FN – Segunda Forma Normal	Todos os atributos devem depender da chave primária completa (não só parte dela)	Evitar dependências parciais em chaves compostas
3FN – Terceira Forma Normal	Nenhum atributo deve depender de outro atributo que não seja a chave primária	Evitar dependências transitivas e garantir consistência


		EXEMPLO de tabela com multivalores e grupos repetidos

Situação inicial (não normalizada)

IdClient	Name	Address	DateBirth	Produt	Price	PurchaseDate
1	Anne Matos	Rua Prata, 4, R/ch A, Sacavém	03/03/2000	Mouse Gaming, Computer	20,00 € , 1 123,00 €	08/01/2026
2	Artur Lopes	Rua Paz, 7, 3ºEsq Portela	25/07/1999	Pen 128GB	10,00 €	09/01/2026
3	Charles Sal	Av. Luz 3, 5ºA Olivais	12/12/2001	Keyboard	55,99 €	9/01/2026
3	Charles Sal	Av. Luz 3, 5ºA Olivais	12/12/2001	Mouse Gaming	20 €	10/01/2026
4	Pedro Sousa	Rua Sol 4, 1ºDt Moscavide	08/08/2000	Tablet	234,00 €	11/01/2026
4	Pedro Sousa	Rua Sol 4, 1ºDt Moscavide	08/08/2000	Pen 128GB	10 €	11/01/2026

👉Transformar para a 1FN

valores não atómicos: campos Address e Name
multivalores: campos Product e Price

Solução:

Valores compostos à criar novos campos/colunas
Multivalores à adicionar novos registos

Chave Primária é uma chave composta (IdClient + Produt + PurchaseDate)

Tabela está na 1FN pois tem valores atómicos

👉Transformar para a 2FN

REGRA: Não pode haver repetição de dados e não pode haver dependências parciais

👉 Dependência parcial acontece quando um atributo depende apenas de parte da chave primária.

Na tabela anterior,

Há dependências parciais

- os campos do cliente

FirstName

LastName

Street

Number

Floor

Side

Locality

DateBirth

dependem do IdClient;

- e os campos do produto Price dependem apenas do Product...)

- E há redundância de dados

SOLUÇÃO: devemos criar várias tabelas por entidade ( CLIENTES; PRODUTOS; Relação)

Na Tabela CLIENTES, com PK IdClient, todos os campos não-chave dependem da PK

Na Tabela PRODUTOS, com PK IdProduct, todos os campos não-chave dependem da PK

Na tabela COMPRAS, a PK é a uma chave composta pelos 3 campos (IdClientFK, IdProductFK, Purchase_date), pois apenas a combinação destes três campos só assim identifica de modo único cada registo.

Pois pode haver novas compras de um utilizador existente e de um produto comprado anteriormente mas em data diferente.

📘Na teoria da normalização:

Podemos usar chaves compostas naturalmente.

💻 Na implementação real (bases de dados reais)

Na prática, é muito comum substituir a chave composta por uma:

🔑 Chave artificial (Surrogate Key)

Para a tabela COMPRAS ter chave simples, podemos acrescentar um novo chave artificial PK IdPurchase (auto-incremento) para simplificar as relações entre tabelas e melhora o desempenho dos dados na BD.

Todas as Tabelas estão na 2FN

-----------------------------------------------------------------------------------------------------

👉Transformar para a 3FN

Regra:

- Estar na 2FN

- Os valores dos campos da tabela não dependem de outros campos que não seja a PK (dependência transitiva)

Verificar dependências transitivas
campo Locality depende de Street e não diretamente da chave primária IdClient

campo Locality (Localidade) - valores repetidos à Criar nova tabela e adicionar chave FK

Agora, todos os atributos da tabela CLIENTES dependem unicamente da chave primária IdClient.

Assim, as 4 tabelas já estão na 3FN

------------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------------------------

OUTRO EXERCÍCIO DE NORMALIZAÇÃO

👉Transformando para 1FN

REGRA

- Cada campo deve ter apenas um único valor (valor atómico)

- Não pode haver multivalores dentro de uma célula

Código Nome Apelido Profissão HorasTrabalhadas

1 Vítor Duque Engenheiro 100

1 Vítor Duque Professor 300

2 Carlos Fontes Pintor 200

2 Carlos Fontes Carpinteiro 50

3 David Martínez Engenheiro 300

✅ Agora está em 1FN

👉Transformando para 2FN

Problema: há valores repetidos e há dependências parciais

Solução: separar em tabelas

1️⃣ Tabela Funcionários

CodFunc	\| Nome	\| Apelido
1	\| Vitor	\| Duque
2	\| Carlos	\| Fontes
3	\| David	\| Martínez

Chave primária: CodFunc

Tabela Funcionários, não tem dependência parcial pois todos os atributos dependem somente da PK.

2️⃣ Tabela TRABALHOS

👉Transformando para 3FN

Tabela PROFISSÕES

Existe um relacionamento N:N = Muitos-para-Muitos

👉 Uma pessoa pode ter várias profissões
👉 Uma profissão pode pertencer a várias pessoas

🔗 TABELA relacionamento (TRABALHOS)

PK composta: (CodFuncFK + CodProfissaoFK )

✅tabelas já estão 3FN.

Programação e Base de Dados

Programação

segunda-feira, 23 de fevereiro de 2026

MODELO RELACIONAL e NORMALIZAÇÃO

📌 Vantagens do modelo relacional

🧠 Nome da tabela: deve refletir os dados que ela guarda

✔️ Características

🔗 Chave Estrangeira (Foreign Key – FK)

✅ Definição

🔑 Chave Candidata (Candidate Key)

✅ Definição:

🔑 Chave Composta (Composite Key)

✅ Definição:

Em teoria (exames de BD)

Em sistemas reais

✅ Definição:

✅Principais objetivos da normalização

Resumo das 3 Formas Normais

Na Tabela CLIENTES, com PK IdClient, todos os campos não-chave dependem da PK

Na Tabela PRODUTOS, com PK IdProduct, todos os campos não-chave dependem da PK

Pois pode haver novas compras de um utilizador existente e de um produto comprado anteriormente mas em data diferente.

📘Na teoria da normalização:

🔑 Chave artificial (Surrogate Key)

Problema: há valores repetidos e há dependências parciais

Solução: separar em tabelas

1️⃣ Tabela Funcionários

2️⃣ Tabela TRABALHOS

🔗 TABELA relacionamento (TRABALHOS)