Leandro DUTRA escreveu:
2008/6/23 Alexsandro Haag <[EMAIL PROTECTED]>:
Ao invés de um cadastro de clientes e outro de fornecedores poderia haver
apenas uma tabela de cadastro de Empresas ou Pessoas (como achar melhor)
Não.
Pode haver uma hierarquia de entidades pais e filhas. Pessoas a raiz,
aà pessoas_fÃsicas ou pessoas_jurÃdicas (um arco), e doutro lado
fornecedores ou clientes (outro arco)...
Realmente, é mais conceitual desta forma, melhor ainda.
Para melhor viabilizar a unificação de cadastro acima (não estou quebrando
regras de normalização, pelo contrário) poderÃamos aà criar um novo
cadastro
de TIPOS_DE_EMPRESA e uma outra chamada EMPRESA_TIPOS (que conteria os tipos
associados a determinada empresa) Ex.:
EMPRESA: ALEX
TIPOS_DE_EMPRESA (FUNCION�RIO,CLIENTE,FORNECEDOR, UNIDADE ORGANIZACIONAL)
EMPRESA_TIPO: ALEX - (FUNCION�RIO,CLIENTE)
Se for o caso, chame de PESSOA então. O nome da entidade não altera a
questão. O que me refiria era sobre poder manter o cadastro na mesma
entidade. Independente do nome que tiver.
Hm... não... um funcionário por definição não pode ser empresa. Isso
aà não é normalizado nem aqui, nem na china.
É importante que sejam identificados adequadamente os nomes das
entidades, mas não é o nome que define que está ou não normalizada. A
normalização tem a ver com estruturação das entidades, não os seu rótulos.
Outra sugestão seria utilizar um código sequencial para o cadastro desta
empresa (fornecedores,funcionários,clientes), pois os campos de CPF e CNPJ
como chaves primárias pode limitar o sistema.
Eles têm de ser declarados como chaves � e aà a importância da
normalização, e as entidades mais especÃficas que delineei acima.
Eu os criaria como chaves secundárias, não como primárias ou únicas.
Pelos motivos que citei acima e reforcei abaixo.
Conheço inúmeros casos reais
onde há várias vezes, pelas mais diferentes razões, clientes "diferentes"
cadastrados com o mesmo CPF ou mesmo CNPJ.
Tem de ver se as razões são razoáveis, me parece mais um defeito de
modelagem exigindo gambiarras.
Isso muitas vezes depende de como o cliente quer tratar sua base. Por
exemplo ele pode não possuir 2 empresas com CNPJs diferentes, mas quer
trabalhar como se tivésse, devido a alguma logística sua. Pode ter por
exemplo a indústria num prédio dos fundos e a loja no prédio da frente e
vai querer fazer uma transferência de produto de uma unidade para outra.
Neste caso ele vai querer cadastrar duas unidades organizacionais, com o
mesmo CNPJ.
Claro que há outras maneiras de tratar isso, poderíamos por exemplo
obrigar o cliente a registrar uma outra empresa/filial para a loja,
mesmo elas estando no mesmo endereço, o que seria o mais correto a
fazer. Mas na prática isso não é flexível para o cliente.
Ou poderíamos ainda acrescentar uma sequencia que complementasse o CNPJ
e a PK ficaria CNPJ + sequencia, mas acho neste caso seria mais simples
criar ID sequencial e uma rotina para alertar, mas não bloquear o
usuário quando tentar criar um cliente que já exista no cadastro.
Esse tipo de situação é mais comum do que parece. Além de ver N outras
situações que convergem para esta mesma questão.
Sempre poderia ser tratado de outra forma, e talvez tenham sugestões
melhores para o caso explanado, mas aí o modelo ER proposto não está
fazendo este tratamento atualmente.
Outra coisa que vejo que poderia ser unificado é o cadastro de Pedidos. O
pedido pode ser de Venda, mas também um pedido de Compra.
Então mais uma vez, seria uma entidade-pai pedidos e um arco de
entidades-filhas de vendas, compras, serviços, o que for.
Concordo.
Att. Alex
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
