✅ 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.
🧠 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) - - 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)
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
👉EXEMPLO de dependência parcial
📦 Tabela: ENCOMENDA
| IdPedido | IdProduto | NomeProduto | Preco | Quantidade |
|---|
| 1 | 101 | Teclado | 25€ | 2 | | 1 | 102 | Rato | 15€ | 1 | | 2 | 101 | Teclado | 25€ | 1 | | 2 | 103 | Monitor | 150€ | 2 | | 3 | 102 | Rato | 15€ | 3 |
|
| | 🔑 Chave Primária Composta: (IdPedido + IdProduto) |
- - NomeProduto depende só do IdProduto
- - Preço depende só do IdProduto
- Há dependência parcial quando dependem de parte da chave e não da chave completa
- Solução: separar em tabelas
- 🟢 Tabela PRODUTO
| IdProduto | NomeProduto | Preco |
|---|
| 101 | Teclado | 25€ |
| 102 | Rato | 15€ |
| 103 | Monitor | 150€ |
| 104 | Headset | 45€ |
🟢 Tabela PEDIDO_PRODUTO
| IdPedido | IdProduto | Quantidade |
|---|
| 1 | 101 | 2 |
| 1 | 102 | 1 |
| 2 | 101 | 1 |
| 2 | 103 | 2 |
| 3 | 102 | 3 |
📌 Consistência dos Dados
A consistência significa que os dados da base de dados:
Exemplo: Uma encomenda refere um cliente que não existe.
📌 Integridade dos Dados
A integridade garante que os dados respeitam as regras definidas na base de dados.
1️⃣ Integridade de Entidade
Exemplo:
2️⃣ Integridade Referencial
Exemplo:
3️⃣ Integridade de Domínio
Exemplo:
Situação inicial (não normalizada)
|
IdClient
|
Name
|
Address
|
DateBirth
|
Produt
|
Price
|
PurchaseDate
|
|
1
|
Anne Matos
|
Rua Prata,
4, R/ch A, 2685 Sacavém
|
03/03/2000
|
Mouse Gaming, Computer
|
20,00 € ,
1 123,00
€
|
08/01/2026
|
|
2
|
Artur Lopes
|
Rua Paz, 7,
3ºEsq 2686Portela
|
25/07/1999
|
Pen 128GB
|
10,00 €
|
09/01/2026
|
|
3
|
Charles Sal
|
Av.
Luz 3, 5ºA 1800 Olivais
|
12/12/2001
|
Keyboard
|
55,99 €
|
9/01/2026
|
|
3
|
Charles Sal
|
Av.
Luz 3, 5ºA 1800Olivais
|
12/12/2001
|
Mouse
Gaming
|
20 €
|
10/01/2026
|
|
4
|
Pedro Sousa
|
Rua Sol 4,
1ºDt 1885 Moscavide
|
08/08/2000
|
Tablet
|
234,00 €
|
11/01/2026
|
|
4
|
Pedro Sousa
|
Rua Sol 4,
1ºDt 1885 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 COMPRAS)
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:
💻 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 transitivascampo Locality depende de
Código Postal e não diretamente da
chave primária IdClient Criar nova tabela CODIGOPOSTAL 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 3FNDIAGRAMA DER
------------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------------------------
OUTRO EXERCÍCIO DE NORMALIZAÇÃO
Código | NomeApelido | Profissão | HorasTrabalhadas
-----------------------------------------------------------------------------------------------------
1 | Vitor Duque
| Engenheiro , Professor | 100 , 300
2 | Carlos Fontes | Pintor , Carpinteiro | 200 , 50
3 | David Martínez | Engenheiro | 3000
👉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
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
Chave Primária composta
- 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.