[OFF] Modelo de dados para Diversos tipos de pessoas

[Daniel Lima]

Galera,

Estou desenvolvendo uma base nova pra minhas apps aqui.
E queria algo que fosse bastante flexível, reaproveitável e que nao fosse trabalhoso de implementar/usar.
O que necessito é um cadastro de pessoas e, consequentemente, de atores: Pessoa pode ser Física ou Jurídica. Daí então, derivar outros cadastros (atores): Vendedor, Cliente, Fornecedor, Funcionário, etc.
E desses cadastros, derivar outros: Venda, Compra, Recebimento, FolhaDeponto...etc.

Bom, inicialmente a minha idéia é muito simples:
Criar uma tabela PESSOA com relacionamento 1:1 com PESSOA_FISICA e PESSOA_JURIDICA. Isto somente normalizar os dados.

Depois criaria as tabelas dos atores (CLIENTE, VENDEDOR, FORNECEDOR, FUNCIONARIO, etc) somente para armazenar os dados específicos deste ator, e cada uma destas tabelas com um relacionamento 1:1 com PESSOA, já que todos os atores são pessoas, no meu caso.

Tendo feito isso, criaria as tabelas VENDA, COMPRA, RECEBIMENTO_MERCADORIA, FOLHA_DE_PONTO, etc dentre outras necessárias, de acordo com as necessidades dos atores e da aplicação, e cada uma destas, teria um relacionamento N:1 com PESSOA, e não com CLIENTE, FORNCEDOR.... Já que todas essa operações são feitas por PESSOAS.

Com isso eu nao precisaria fazer 2 JOINs para obter o nome de quem efetuou uma venda, por exemplo: VENDA -> VENDEDOR -> PESSOA -> NOME,
Eu já poderia obter o nome do sujeito da seguinte maneira: VENDA -> PESSOA-as-VENDEDOR -> NOME

Bom, já fiz uma base dessa maneira para outras apps , mas sempre gosto de perguntar antes de tomar as decisões iniciais.
Vocês acham que devo seguir por este caminho? Têm alguma crítica ou sugestão?

Segue em anexo o modelo proposto.

Abraços e paz a todos. 

______________________________________
Daniel Lima
Web Developer

Skype: yourwebmaker
G-talk: yourwe...@gmail.com
MSN: yourwe...@hotmail.com

Facebook: https://www.facebook.com/dlpinheiro 
Twitter: @yourwebmaker

[Diego Henrique Oliveira]

No seu exemplo eu só mudaria a ligação, colocaria a tabela vendas
ligada a tabela vendedor.

O caminho é esse mesmo, eu particularmente gosto desse modelo de herança.




2012/8/23 Daniel Lima <yourwe...@gmail.com>:

[Luís Otávio]

Daniel,

Na minha visão seu modelo possui algumas divergências conceituais.

A principal é: o vendedor É uma pessoa ou ESTÁ RELACIONADO a uma pessoa?

Segundo seu modelo o vendedor ESTÁ RELACIONADO.

Sugiro que você leia sobre Class Table inheritance, o seu modelo seria algo como o multiple table inheritance.

Att,

Luís

http://about.me/lcobucci

2012/8/23 Daniel Lima <yourwe...@gmail.com>

[Tiago da Hora]

Acho que o caminho é esse mesmo, só não faria o relacionamento entre Pessoa e Venda (ligaria com vendedor) você economiza um join mas pode ter problemas de integridade no futuro.

--

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

Tiago S. da Hora
Analista de Sistemas
TiagodaHora.com

+55 71 3314-4819 / 8887-5807 / 9192-2161

 

Esta mensagem, incluindo seus anexos, tem caráter confidencial e seu conteúdo é restrito ao destinatário da mensagem. Caso você tenha recebido esta mensagem por engano, queira por favor, retorná-la ao destinatário e apagá-la de seus arquivos. Qualquer uso não autorizado, replicação ou disseminação desta mensagem ou parte dela é expressamente proibido. O autor não é responsável pelo conteúdo ou a veracidade desta informação.

This message, including its annexes, has confidence and their content is restricted to recipiente of the message . If you have received this message in error, please, return it to the recipiente and delete it from your files. Any unauthorized use, dissemination or replication of part or this message is strictly prohibited. The author is not responsible for the content or the veracity of this information

[Daniel Lima]

Luis Otávio,

Vou explicar qual é o meu principal objetivo:

Um vendedor é uma pessoa, assim como fornecedor, cliente, distribuidor, funcionário, etc também são pessoas. 
Mas há também casos da mesma pessoa assumir diferentes papéis, como no seguinte exemplo:

Tenho um funcionário, cadastrado em meu sistema que é vendedor da loja X. Este mesmo vendedor, efetuou uma compra na loja X, e vou precisar cadastra-lo como cliente.

Neste exemplo, a mesma pessoa assumiu 3 papéis diferentes (funcionário, vendedor e cliente), mas poderia assumir mais (ex: usuario, gerente, etc...

Nesse caso, tenho herança multipla (uma pessoa é várias coisas ao mesmo tempo), mas nunca implementei isso em banco de dados e em um ORM (que é o que pretendo usar). Agradeceria se puder me passar um exemplo.

Sobre CTI, usarei somente para diferenciar pessoa física de jurídica. Pois é uma herança simples (uma pessoa é uma única coisa).

No fim das contas, acho melhor usar uma associação entre ator x pessoa. O que resultaria em algo como:

$venda->getVendedor()->getPessoa()->getNome(); // tudo isso mapeado por ORM

$compra->getCliente()->getPessoa()->getNome(); // tudo isso mapeado por ORM

Diego e Tiago,

Como citei anteriomente, acho que vou mudar o relacionmento Vendedor x Venda mesmo.
Conversando com o Renato Medina, que é expert em banco de dados (rsrs), disse que o custo de um JOIN não é tão alto assim.

Renato, Ademir e Chiquitto:

Acho que uma view para esse caso seria desnecessária. A lógica é muito simples e poderia resolvê-la com um ORM.

Quero ressaltar que nada disso é real na minha aplicação ainda. Estou pensando na melhor forma possível para atender à necessidades de qualquer sistema possa ser desenvolvido com essa base.

Segue um anexo com um novo modelo proposto.

Obrigado, e continuo aguardando críticas e sugestões.

Abraços a todos.
________________________________________
Daniel Lima
Web Developer - Cilens Software

Skype: yourwebmaker

Twitter: @yourwebmaker 
G-talk: yourwe...@gmail.com
MSN: yourwe...@hotmail.com

Facebook: https://www.facebook.com/dlpinheiro 

2012/8/23 Renato Medina <medin...@gmail.com>

Daniel, acho que você DEVE atender as normas formais. Há o custo dos Joins, mas pelo menos você não perde com uma modelagem ruim do seu banco de dados. Quanto as views, elas poderiam sim resolver seu problema, mas eu vejo views para encapsular logicas mais complexas de um sistema. Utilizá-las apenas para joins não acho que valha a pena. Faça apenas na sua camada de  Domain seu join, pronto resolveu e você migrou uma inteligencia que colocaria na view pra sua aplicação e também não vai precisar reescrever a mesma coisa varias vezes.

Minha opinião.

2012/8/23 Ademir Mazer Jr <ademir....@gmail.com>

Eu estou seguindo uma linha parecida, mas não tenho pessoa física e pessoa jurídica, tenho cliente, vendedor, fornecedor, etc, diretamente associados à pessoa ... e os demais objetos, como por exemplo, nf, associado ao ator correto, como cliente ...

isso pq em alguns casos um cliente pode ser uma pessoa fisica e em outros jurídica, e assim por diante ...

depois faço como o Chiquito e crio views...

--------------------------------------------------------------------------------------------------------------------------------
 Ademir Mazer Jr 
Software Engineer - Owner

Winponta - http://www.winponta.com.br

 ademir....@gmail.com |  http://ademir.winponta.com.br 
--------------------------------------------------------------------------------------------------------------------------------

Em 23 de agosto de 2012 08:10, Alisson Chiquitto <chiq...@gmail.com> escreveu:

O que eu sempre faço é mais ou menos o que você disse, mas dai eu
ainda implemento algumas views.

Para as tabelas PESSOA, PESSOA_FISICA, PESSOA_JURIDICA eu crio duas
views VPESSOA_FISICA e VPESSOA_JURIDICA.
Então eu não preciso ficar sempre fazendo os INNER JOINS.

Para vendedor seria a mesma coisa, eu faria uma VIEW.

Chiquitto

2012/8/23 Daniel Lima <yourwe...@gmail.com>:

> --
> Essa mensagem faz parte do grupo "zfbrasil" no Google Groups.
> Para escrever neste grupo, envie um email para zfbr...@googlegroups.com
> Para se desligar do grupo, envie um email para
> zfbrasil-u...@googlegroups.com
> Mais informações, visite o grupo em
> http://groups.google.com/group/zfbrasil?hl=pt-BR

--
Essa mensagem faz parte do grupo "zfbrasil" no Google Groups.
Para escrever neste grupo, envie um email para zfbr...@googlegroups.com
Para se desligar do grupo, envie um email para zfbrasil-u...@googlegroups.com
Mais informações, visite o grupo em http://groups.google.com/group/zfbrasil?hl=pt-BR

--
Essa mensagem faz parte do grupo "zfbrasil" no Google Groups.
Para escrever neste grupo, envie um email para zfbr...@googlegroups.com
Para se desligar do grupo, envie um email para zfbrasil-u...@googlegroups.com
Mais informações, visite o grupo em http://groups.google.com/group/zfbrasil?hl=pt-BR

--

Renato Medina,

Developer 

PHP Senior

MySQL Consultant

Blog:  http://meumysql.blogspot.com/

Skype: medinadato

Twitter:  @medinadato

LinkedIn: http://au.linkedin.com/pub/renato-medina/11/175/a07

Cel.: +55 27 9605 6061

Vitória/ES - Brazil.

--
Essa mensagem faz parte do grupo "zfbrasil" no Google Groups.
Para escrever neste grupo, envie um email para zfbr...@googlegroups.com
Para se desligar do grupo, envie um email para zfbrasil-u...@googlegroups.com
Mais informações, visite o grupo em http://groups.google.com/group/zfbrasil?hl=pt-BR

[Oliveira, Leandro]

Cara, achei um modelo bem coeso!

eu não penso diferente!

2012/8/23 Daniel Lima <yourwe...@gmail.com>

[Oliveira, Leandro]

Cara, achei um modelo bem coeso!

eu não penso diferente!

2012/8/23 Daniel Lima <yourwe...@gmail.com>

Galera,

[Diego Henrique Oliveira]

eu nem pensei em custo de join pra te ser sincero...

minha sugestão foi mais baseada em modelagem mesmo, já que faz mais sentido vc ter uma venda ligada a um vendedor que a uma pessoa...

2012/8/23 Daniel Lima <yourwe...@gmail.com>

[Daniel Lima]

Pois é, Diego.

Haveria a possibilidade de trabalhar com FK como PK, onde o ID do vendedor ficaria igual ao ID da pessoa, mas isso é um pouco trabalhoso de implementar, então vou seguir como está no modelo.

E pensando em termos de modelagem, fica melhor da ultima forma que você propôs.

Obrigado a todos.

________________________________________
Daniel Lima
Web Developer - Cilens Software

Skype: yourwebmaker

Twitter: @yourwebmaker 
G-talk: yourwe...@gmail.com
MSN: yourwe...@hotmail.com

Facebook: https://www.facebook.com/dlpinheiro 

2012/8/24 Diego Henrique Oliveira <con...@diegoholiveira.com>

[Luís Otávio]

Suas falas anteriores se contradizem :D

"O vendedor é uma pessoa" e "No fim das contas, acho melhor usar uma associação entre ator x".

Eu não estou falando se está certo ou errado uma ou outra situação, mas se o vendedor fosse uma pessoa, ele herdaria a pessoa, essa eh a diferença.

Para representar isso no db, você deveria utilizar o FK como PK e na venda relacionar com o vendedor. Assim você não teria possíveis erros de integridade dos dados.

Imagino que você tenha feito isso pra facilitar o seu mapeamento no ORM, mas não se "iluda" em pensar que o vendedor eh uma pessoa segundo o seu modelo atual :P.

Abraçow,

Luís

[Daniel Lima]

Pois é Luís,

Sempre me enrolo um pouco nas explicações, já tive problemas de comunicação em empresas que já trabalhei =).. enfim.

Mas acho que deu para entender o que queria no final. Vou começar a transformar isso tudo em realidade e antes, queria a opinião de cada um de vcs.

Já que vocês "aprovaram" a proposta, darei continuidade ao trabalho e postarei o código aqui futuramente.

Valeu cowboy!

Abraços a todos.
________________________________________
Daniel Lima
Web Developer - Cilens Software

Skype: yourwebmaker

Twitter: @yourwebmaker 
G-talk: yourwe...@gmail.com
MSN: yourwe...@hotmail.com

Facebook: https://www.facebook.com/dlpinheiro 

2012/8/24 Luís Otávio <lcob...@gmail.com>