1
resposta

[Projeto] Resolução Exercício - 02.05 (Modelagem de Dados)

Bom, como atualmente a tabela de ClientesFornecedores, há diversos dados, uma forma de realizar a normalização dessa tabela e consequentemente aplicar a 1FN, é dividindo a tabela main (principal), no caso a ClienteFornecedores em outras tabelas distintas, por exemplo:

Tabela de Clientes, onde terá os campos:

ID_CLIENTE, Nome_Cliente. Como não tem explicíto no enunciado, suponhamos que um cliente/fornecedor só pode ser cliente, não pode ser fornecedor também e vice versa, ou seja, podemos retirar o campo tipo. Já que se ele está na tabela de cliente, ele é um cliente.

Tabela de Fornecedores:

ID_FORNECEDOR, Nome_Fornecedor.

Como aqui temos a tabela de Clientes e Fornecedores, temos um problema na tabela de e-mail, já que um fornecedor pode ter o ID = 1 e o cliente também, tendo em vista que são tabelas distintas. Para isso, criei uma tabela chamada "Contatos", criando um ID que referencia aquele cliente/fornecedor.

Tabela de Contatos

ID_CONTATO, Nome, TIPO. (Fornecedor/Cliente).

Tabela de E-mails:

ID_Email, ID_Contato, E-mail.

Tabela de Telefones:

ID_TELEFONE, ID_CONTATO, Telefone.

Acho que essa resolução resolve o exercício, mas da um nó grande no sistema.

1 resposta

Oii, André. Tudo bem?

É muito interessante ver como você buscou uma estrutura que garante a integridade dos dados, especialmente ao notar que IDs iguais em tabelas diferentes poderiam gerar conflitos. Você deu um passo além da normalização básica e pensou na arquitetura lógica do banco de dados.

Sua percepção sobre a Primeira Forma Normal (1FN) tá certíssima: o objetivo principal aqui é a atomicidade, ou seja, garantir que cada campo contenha apenas um valor. Ao separar os e-mails e telefones em linhas individuais em tabelas próprias, você resolveu o problema dos dados multivalorados.

Sua sugestão de criar uma tabela de "Contatos" (ou uma tabela "Pai") para centralizar os IDs é uma prática comum para evitar a duplicidade que você mencionou. Isso cria uma base sólida para as tabelas de e-mail e telefone se relacionarem com um único identificador, independentemente de ser cliente ou fornecedor.

Alguns pontos para refletir sobre a sua estrutura:

  • Embora separar Clientes de Fornecedores seja uma opção, manter a tabela original como Entidades ou Parceiros com o campo Tipo (como sugerido pelo instrutor) costuma deixar o sistema menos complexo, pois evita a criação de duas tabelas com estruturas idênticas.
  • A tabela de Contatos que você propôs acaba funcionando como essa tabela centralizadora. Se ela já contém o nome e o tipo, as tabelas de Clientes e Fornecedores que você citou no início podem acabar se tornando redundantes, a menos que existam dados muito específicos para cada categoria (como CNPJ para fornecedores e CPF para clientes).
Alura Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!