Dúvidas dos Alunos: Chaves Estrangeiras e Relacionamentos Opcionais em Bancos de Dados

Bem-vindos de volta ao nosso blog de concursos, onde desvendamos as complexidades da modelagem de dados. Hoje, vamos abordar uma dúvida enviada por um aluno referente a chaves estrangeiras e a cardinalidade em um relacionamento de banco de dados. A questão central é: a chave estrangeira na entidade Empregado pode ser nula? Vamos analisar a regra de negócio e entender como implementar a constraint adequada.

A regra de negócio em questão detalha que um empregado é identificado por CPF e nome, enquanto um departamento é definido por um código e um nome. Um departamento pode ter vários empregados, mas um empregado pode estar lotado em no máximo um departamento. Isso nos leva à relação Departamento (0,1) —– Lotação ——– (1,N) Empregado, que sugere que um departamento pode existir sem empregados lotados, mas um empregado, ao ser associado, deve estar ligado a apenas um departamento.

Entendido, se o foco está na relação de lotação entre `Departamento` e `Empregado`, onde um departamento pode ter uma ou nenhuma lotação, e uma lotação pode ter um ou vários empregados, isso implica na introdução de uma nova tabela para representar a lotação. Vamos remodelar as tabelas e o script SQL com base nessa nova compreensão:

 Tabelas:

1. **Departamento**:

    – Código (Chave Primária)

    – Nome

2. **Lotação**:

    – ID_Lotação (Chave Primária)

    – Código_Departamento (Chave Estrangeira)

3. **Empregado**:

    – CPF (Chave Primária)

    – Nome

    – ID_Lotação (Chave Estrangeira)

### Script SQL com Inserts:

“`sql

— Criação da tabela Departamento

CREATE TABLE Departamento (

    Codigo VARCHAR(10) NOT NULL,

    Nome VARCHAR(100) NOT NULL,

    PRIMARY KEY (Codigo)

);

— Inserção de dados na tabela Departamento

INSERT INTO Departamento (Codigo, Nome) VALUES (‘D1’, ‘TI’);

INSERT INTO Departamento (Codigo, Nome) VALUES (‘D2’, ‘RH’);

INSERT INTO Departamento (Codigo, Nome) VALUES (‘D3’, ‘Vendas’);

— Criação da tabela Lotação

CREATE TABLE Lotação (

    ID_Lotação INT AUTO_INCREMENT NOT NULL,

    Codigo_Departamento VARCHAR(10),

    PRIMARY KEY (ID_Lotação),

    FOREIGN KEY (Codigo_Departamento) REFERENCES Departamento(Codigo)

);

— Criação da tabela Empregado

CREATE TABLE Empregado (

    CPF INT NOT NULL,

    Nome VARCHAR(100) NOT NULL,

    ID_Lotação INT,

    PRIMARY KEY (CPF),

    FOREIGN KEY (ID_Lotação) REFERENCES Lotação(ID_Lotação)

);

— Inserção de dados nas tabelas Lotação e Empregado

— Supondo que cada inserção na tabela Lotação corresponde a uma nova lotação em um Departamento específico

INSERT INTO Lotação (Codigo_Departamento) VALUES (‘D1’);

INSERT INTO Lotação (Codigo_Departamento) VALUES (‘D1’);

— Supondo que os empregados estejam lotados nas entradas criadas acima

INSERT INTO Empregado (CPF, Nome, ID_Lotação) VALUES (111, ‘Carlos’, 1);

INSERT INTO Empregado (CPF, Nome, ID_Lotação) VALUES (222, ‘Jose’, 2);

— Empregado sem lotação (ID_Lotação pode ser NULL)

INSERT INTO Empregado (CPF, Nome, ID_Lotação) VALUES (333, ‘Pedro’, NULL);

“`

Neste modelo revisado, a tabela `Lotação` serve como uma entidade associativa entre `Departamento` e `Empregado`, permitindo que um departamento tenha nenhuma ou uma lotação e que cada lotação possa ter vários empregados. A coluna `ID_Lotação` na tabela `Empregado` é uma chave estrangeira que pode ser nula, permitindo empregados sem lotação.

Para ilustrar os resultados das tabelas `Departamento`, `Lotação` e `Empregado` após os `INSERTS`, vamos considerar os dados inseridos e descrever como cada tabela ficaria:

### Tabela Departamento:

“`

+——–+———-+

| Codigo | Nome     |

+——–+———-+

| D1     | TI       |

| D2     | RH       |

| D3     | Vendas   |

+——–+———-+

“`

### Tabela Lotação:

Neste caso, supomos a criação de duas lotações, ambas vinculadas ao departamento ‘D1’. A tabela `Lotação` teria registros como:

“`

+————+——————–+

| ID_Lotação | Codigo_Departamento |

+————+——————–+

| 1          | D1                 |

| 2          | D1                 |

+————+——————–+

“`

### Tabela Empregado:

Os empregados Carlos e Jose estão associados às lotações 1 e 2, respectivamente, enquanto Pedro não está associado a nenhuma lotação, refletido pelo valor `NULL` em sua `ID_Lotação`.

“`

+—–+——–+———–+

| CPF | Nome   | ID_Lotação |

+—–+——–+———–+

| 111 | Carlos | 1         |

| 222 | Jose   | 2         |

| 333 | Pedro  | NULL      |

+—–+——–+———–+

“`

Neste modelo, a tabela `Lotação` funciona como uma ponte entre `Departamento` e `Empregado`, permitindo representar a relação onde um departamento pode ter uma ou nenhuma lotação e uma lotação pode ter um ou vários empregados. O empregado Pedro, não estando associado a uma lotação, ilustra a flexibilidade do modelo em acomodar empregados não lotados.

É importante lembrar que o verdadeiro aprendizado muitas vezes começa com uma pergunta. As dúvidas que surgem durante os estudos são sinais de um engajamento ativo com o material, e cada questão resolvida é um passo adiante na jornada de aprendizado. Este exercício específico nos permitiu revisitar os princípios fundamentais da modelagem de banco de dados, enquanto abordávamos uma situação complexa e muito relevante para muitos cenários de negócios. Continuem curiosos, continuem questionando e, mais importante, continuem aprendendo.

Até a próxima dúvida, sigam fortes em seus estudos e lembrem-se de que cada desafio enfrentado é uma oportunidade para crescer e se aprimorar. Se tiverem mais perguntas, não hesitem em enviá-las. Até a próxima !

A Dúvida do Aluno

Prof. Washington Almeida