Modelar como atributos ou entidades?

[Kamon Florentino Mesquita 0]

Estou criando um banco de dados para uma empresa com filiais, no qual os 'endereços' das entidades FILIAL, EMPRESA_ENTREGA_TERCERIZADA, FUNCIONÁRIO, CLIENTE e FORNECEDOR foram divididos nos campos: Bairro, Logradouro, CEP, Num, Complemento, Cidade, Estado e País. Atualmente cada um destes campos foi considerado como um atributo das entidades mencionadas, porém me dá a impressão que terei uma imensa repetição de dados nos campos Cidade, Estado e País. Por outro lado, acredito que se estes campos forem modelados com entidades (CIDADE, ESTADO e PAIS), terei buscas mais complexas, com mais INNER JOINS e, portanto, mais demoradas; sendo a velocidade vital nesta aplicação. Em resumo, neste caso, devo deixar estes três campos como atributos ou transformá-los em entidades relacionadas? Também aceito outras sugestões de como modelar o endereço neste caso.

[Motta 645]

É o problema de se modelar em OO e implementar o BD relacional.

 

Uma outra questão é quanto "endereço" é relevante no Sistema, não sendo necessário ter 1:n talvez o melhor seria manter o mais simples possível.

 

Outra solução poderia partir para soluções do tipo Hibernate para fazer a interface OO x BD.

[Kamon Florentino Mesquita 0]

A abordagem será relacional e o endereço está 1:1, eu só o dividi em campos por ser um atributo multivalorado. Meu problema, ou eu penso ser um problema é que se eu deixar cidade, estado e pais como atributos terei uma série de repetições de dados no BD. Por exemplo: em uma loja em Goiânia com filial em Anápolis, os endereços dos clientes e dos fornecedores em sua maioria irão ter estado 'Goiás' e cidade 'Goiânia' e 'Anapólis'. Estas informações irão se repetir a cada cliente, fornecedor e outras entidades criadas, desperdiçando muito espaço em disco conforme se insira novos dados no BD. O campo país só terá o valor Brasil (não evolve outros países) e este campo tem de estar no endereço (exigência do cliente que quer a aplicação). Porém se eu modelar estes três campos como três tabelas, acredito (não tenho certeza) que isto poderia tornar as buscas mais lentas (ao pesquisar por cliente, por exemplo, seria necessário usar INNER JOIN com as tabelas CIDADE, ESTADO e PAIS). Talvez eu modele apenas o país como tabela, mas isso me parece gambiarra.

[Motta 645]

No ER faça :

Tabela de CIDADES , CIDADES_BAIRROS , CIDADE_CEP (usando a base dos correiosque é comprada ...)

 

No endereço, algo como

 

 

tipo_endereco
cod_cidade
cod_bairro_cidade
cep
tipo_logradouro
logradouro
numero
complemento

Mas isto depende o quanto endereço é vital para o Sistema, num Sistema de Assinaturas (jornais/revistas) isto é vital, num outro Sistema nem tanto.

 

Vale a máxima, resolva os problemas que você tem.

[Prog 183]

O "desperdício" de espaço em disco é algo relativo. Os equipamentos são tão ruins assim?

 

Eu faria assim... Um modelo de dados consolidado e bem estruturado.

 

E para suprir a necessidade de velocidade, que acredito eu ser uma necessidade apenas para relatórios, vendas e atendimento ao cliente, criaria uma estrutura, em paralelo (algo para simular uma "Visão Materializada") que seria atualizada por triggers ou por processos agendados.

 

Cada loja vai ter seu próprio banco de dados, off-line?