Modelagem de Bancos de Dados sem Segredos — Parte 05 | by Albert Eije Barreto Mouta | Medium

Modelagem de Bancos de Dados sem Segredos — Parte 05



Image for post
Image for post

Estudo de Caso

Vamos agora analisar um estudo de caso. Nossos objetivos são:

  1. Identificar as entidades
  2. Identificar os relacionamentos
  3. Normalizar as entidades
  4. Criar o DER no MySQL Workbench

A situação é a seguinte: uma empresa deseja armazenar os dados de seus contatos, sejam eles Clientes, Fornecedores, Colaboradores, Contadores ou Transportadoras. A empresa precisa se comunicar com essas pessoas através de telefone, e-mail e correspondência impressa.

Entidades

Nosso primeiro passo é encontrar as entidades. Algumas delas nos foram dadas de mão beijada:

  • Cliente
  • Fornecedor
  • Colaborador
  • Contador
  • Transportadora

Vamos imaginar os atributos dessas entidades:

Nome, Email, Rua, Número, Complemento, Bairro, Cidade, CEP, Estado, CPF, CNPJ, RG, Data RG, Órgão RG, Sexo, Raça, Naturalidade, Nacionalidade, Nome Pai, Nome Mãe, Inscrição Estadual, Inscrição Municipal, Nome de Fantasia, Inscrição CRC, UF CRC.

Veja que temos vários atributos. Alguns deles servem para mais do que uma entidade, por exemplo, Nome. As cinco entidades precisarão desse atributo. No entanto CRC é um atributo utilizado apenas pelo Contador. Vamos organizar esses atributos para facilitar a visualização.

Nome
Email
Site
Rua
Número
Complemento
Bairro
Cidade
CEP
Estado

Existem alguns atributos que são específicos para Pessoa Física, independente de ser Cliente, Fornecedor, Colaborador, Transportadora ou Contador. São os seguintes:

CPF
RG
Data RG
Órgão RG
Sexo
Raça
Naturalidade
Nacionalidade
Nome Pai
Nome Mãe

Existem alguns atributos que são específicos para Pessoa Jurídica, independente de ser Cliente, Fornecedor, Colaborador, Transportadora ou Contador. São os seguintes:

CNPJ
Inscrição Estadual
Inscrição Municipal
Nome de Fantasia

Finalmente temos dois atributos específicos para Contadores:

Inscrição CRC
UF CRC

Você deve baixar o MySQL Workbench (vou me referir ao produto a partir de agora como MW) no site do MySQL. Após instalar o MW, você deve iniciar um novo modelo utilizando a opção File/New Model. Clique duas vezes na opção “Add Diagram” e você estará pronto para modelar seu banco de dados utilizando essa poderosa ferramenta.

Image for post
Image for post
Figura 5.1 — Criando um Modelo no MySQL Workbench

Vamos explicar agora para que serve cada item da barra de ferramentas vertical (Vertical Toolbar). Conhecer bem essa barra é o primeiro passo para iniciar a modelagem.

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Generalização?

Lembra do que vimos anteriormente sobre Generalização (Parte 3)? Será uma boa ideia utilizar esse conceito aqui. Vamos pensar:

Nós temos Cliente, Fornecedor, Contador, Colaborador e Transportadora. Todas essas entidades são PESSOA, sendo que temos dados específicos para PESSOA_FISICA e dados específicos para PESSOA_JURIDICA. Além disso, embora CONTADOR seja uma PESSOA, temos dados específicos para ele que não convém gravar para as demais entidades (Inscrição CRC e UF CRC).

Que tal se criássemos a tabela PESSOA e fizéssemos a generalização com as demais tabelas? Vamos ver como fica.

Image for post
Image for post
Figura 5.2 — Tabelas do Grupo Pessoa

Então vejamos. Nós temos a tabela PESSOA. Tudo começa com ela. Mas a PESSOA pode ser física ou jurídica. Então nós criamos as tabelas PESSOA_FISICA e PESSOA_JURIDICA para armazenar os dados específicos de cada uma.

E qual o relacionamento entre PESSOA e PESSOA_FISICA e entre PESSOA e PESSOA_JURIDICA? Esses campos só foram removidos de PESSOA para evitar que tenhamos valores nulos. Como assim? Digamos que eu tivesse colocado os campos CPF e CNPJ na tabela PESSOA. Se for pessoa física eu informo o CPF e o CNPJ fica nulo. Se for pessoa jurídica eu informo o CNPJ e o CPF fica nulo. A melhor solução é fazer o que fizemos: separar as tabelas. O relacionamento será de 1:1 sempre. Uma PESSOA será sempre Uma PESSOA_FISICA ou Uma PESSOA_JURIDICA.

O mesmo raciocínio vale para CLIENTE, COLABORADOR, FORNECEDOR, CONTADOR e TRANSPORTADORA. O relacionamento é de 1:1 entre PESSOA e essas tabelas.

Esse é um caso bem interessante de modelagem. Os dados ficam bem organizados. Na tabela PESSOA nós criamos os campos CLIENTE, COLABORADOR, FORNECEDOR, CONTADOR e TRANSPORTADORA (do tipo CHAR tamanho 1) apenas para marcar se a PESSOA faz o papel de uma ou mais dessas entidades. Saiba que PESSOA pode ser CLIENTE e COLABORADOR ao mesmo tempo! Sim, você pode ter um funcionário seu que também é seu cliente. É para isso que temos esses campos na tabela PESSOA. Basta gravar “S” no campo CLIENTE e você saberá que essa PESSOA é CLIENTE. Com esse esquema montado, as opções para criação de telas na aplicação que vai utilizar esse banco de dados são muitas.

Finalmente temos os relacionamentos 1:N entre PESSOA e PESSOA_TELEFONE e entre PESSOA e PESSOA_ENDERECO. Você armazena os endereços e os telefones da pessoa, seja ela cliente, fornecedor, colaborador, etc.

Com este modelo nós não temos redundância de dados e não temos problemas com valores nulos sem necessidade. A ressalva desse modelo é a dificuldade de consultar dados a partir da aplicação cliente que vai usar esse banco de dados. No entanto, isso pode ser facilmente resolvido com a criação de “views”.

Tabelas do Grupo Pessoa

Seguem as imagens com detalhes das tabelas do Grupo Pessoa para que você possa implementar usando o MySQL Workbench.

Image for post
Image for post
Figura 5.3 — Tabela PESSOA
Image for post
Image for post
Figura 5.4 — Tabela PESSOA_FISICA

Observe que temos os campos ID_NIVEL_FORMACAO e ID_ESTADO_CIVIL. Isso indica que existem outras duas tabelas que armazenam esses dados. Implemente-as.

Image for post
Image for post
Figura 5.5 — Tabela PESSOA_JURIDICA
Image for post
Image for post
Figura 5.6 — Tabela PESSOA_ENDERECO
Image for post
Image for post
Figura 5.7 — Tabela PESSOA_TELEFONE
Image for post
Image for post
Figura 5.8 — Tabela CLIENTE
Image for post
Image for post
Figura 5.9 — Tabela TRANSPORTADORA
Image for post
Image for post
Figura 5.10 — Tabela FORNECEDOR
Image for post
Image for post
Figura 5.11 — Tabela CONTADOR
Image for post
Image for post
Figura 5.12 — Tabela COLABORADOR

Observe que temos os campos ID_CARGO e ID_SETOR. Isso indica que existem outras duas tabelas que armazenam esses dados. Implemente-as.

Parte 5 — Considerações Finais

Nessa parte fizemos um estudo de caso utilizando a ferramenta MySQL Workbench para modelar o banco de dados Pessoa.

Abordamos novamente o conceito de Generalização. Vimos como organizar os dados em tabelas separadas com relacionamentos 1:1 para evitar redundâncias e valores nulos.

Como exercício, tente modelar as tabelas para uma Clínica Veterinária. Pense nas entidades e seus atributos. Defina os relacionamentos. Crie o modelo utilizando o MySQL Workbench.


T2Ti ERP — Aprenda a Desenvolver um ERP

O T2Ti ERP 2.0 é feito em C#, Delphi, Java (RIA e Web) e Lazarus. São cinco projetos diferentes. Que tal aprender a desenvolver esse ERP totalmente grátis? Parece bom?

Image for post
Image for post

Acompanhe o canal da T2Ti no Youtube. A T2Ti está postando todos os vídeos do T2Ti ERP 2.0 no Youtube. São quase 300 módulos!


Os vídeos estão organizados em Playlists. Então se inscreva no canal e ative o sininho para receber atualizações sobre as postagens.


Acesse o artigo no Medium para aplaudir e/ou comentar.