MODELO RELACIONAL e NORMALIZAÇÃO

     ✅    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

1. Eliminar redundância de dados
   → Evita dados repetidos 

2. Evitar inconsistências
   → Impede que o mesmo dado tenha valores diferentes em tabelas distintas.

3. Facilitar manutenção
   → Inserir, atualizar e apagar dados torna-se mais simples.

4. 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 👉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:

• Estão corretos

• Estão coerentes

• Não entram em contradição

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

• A chave primária não pode ser nula

• Cada registo deve ser único

Exemplo:

• Não podem existir dois clientes com o mesmo IdCliente

• IdCliente não pode ser NULL




2️⃣ Integridade Referencial

• Uma chave estrangeira deve corresponder a um registo existente

Exemplo:

• Não posso criar uma Encomenda com IdCliente = 10 se esse cliente não existe

3️⃣ Integridade de Domínio

• Os dados devem respeitar o tipo e as regras definidas

Exemplo:

• DataNascimento deve ser uma data válida

• Quantidade não pode ser negativa

• Preço não pode ser texto




 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

1.  valores não atómicos: campos Address e Name
2. 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:

• 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 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 3FN

DIAGRAMA DER








COMPRAS ONLINE

















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

 




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

📘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  

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






  Chave Primária composta 




👉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.
• 
  

• 📘OUTRO EXERCÍCIO de NORMALIZAÇÃO

  IdEmployer	Name	Department	Language
  1	Ana Gomes	Ciências	Inglês, Espanhol
  2	Ester Oliveira	Informática	Inglês
  3	Rita Sousa	Marketing	Inglês, Francês

  • 👉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 

  
  

  Tabela EMPREGADOS

  IdEmployer	Name	SurName	Department	Language
  1	Ana	Gomes	Ciências	Inglês
  1	Ana	Gomes	Ciências	Espanhol
  2	Ester	Oliveira	Informática	Inglês
  3	Rita	Sousa	Marketing	Inglês
  3	Rita	Sousa	Marketing	Francês
  4	Pedro	Lima	Informática	Alemão
  4	Pedro	Lima	Informática	Inglês

  
  

  
  

  
  

  
  

  
  

  
  

  
  

  
  

  
  

   👉Transformando para 2FN

  • Verificar dependências parciais

  • Solução: separar em tabelas

  • 1️⃣ Tabela de EMPREGADOS

    IdEmployer	Name	Apelido	Department
    1	Ana	Gomes	Ciências
    1	Ana	Gomes	Ciências
    2	Ester	Oliveira	Informática
    3	Rita	Sousa	Marketing
    3	Rita	Sousa	Marketing
    4	Pedro	Lima	Informática
    4	Pedro	Lima	Informática

  • 
    

  • 
    

  • 
    

  • 
    

  • 
    

  •  📌 Tabela LÍNGUAS_EMPREGADO

    (PK = chave composta (IdEmployer + Language)

    IdEmployer	Language
    1	Inglês
    1	Espanhol
    2	Inglês
    3	Inglês
    3	Francês
    4	Alemão
    4	Inglês

  • 
    
  • 👉Transformando para 3FN
  • 
    
  •  Otimização: reduzir redundância de departamentos
  • 
    

  • TABELA PRINCIPAL

    Tabela EMPREGADORES

  IdEmployer	Name	SurName	IdDepartmentFK
  1	Ana	Gomes	10
  2	Ester	Oliveira	20
  3	Rita	Sousa	30
  4	Pedro	Lima	20

  
  

  
  

  
  

  
  

  
  

  
  

  
  

  TABELA SECUNDÁRIA (elimina redundância)

  📌 Tabela DEPARTMENT

  IdDepartment	Department
  10	Ciências
  20	Informática
  30	Marketing

  
  

  
  

  
  

  TABELA RELACIONAMENTO

  
  

  Tabela LÍNGUAS_EMPREGADO

  (PK = chave composta (IdEmployer + Language)

  IdEmployer	Language
  1	Inglês
  1	Espanhol
  2	Inglês
  3	Inglês
  3	Francês
  4	Alemão
  4	Inglês

   

  
  

  Todas as tabelas estão em 3FN

  
  

  Não há dependências parciais nem transitivas

  
  

  A tabela associativa resolve o relacionamento M:M com as línguas

  
  

  Departamento foi separado para eliminar redundância (boa prática)

  
  

  
  
•