Ola,
Gostaria de saber se estaria correto esse relacionamento. Acho q pela normalizacao nao. mas gostaria de saber se na pratica alguem usa assim e acarretaria algum problema.
Como o produto so teria duas formulas nao haveria necessidade de criar uma terceira tabela ProdutoFormula.
modelagem de banco não é minha especialidade, mas vamos la.
E se vc criar uma chave composta na tabela formula, com o id e um segundo campo sendo uma flag. Um campo como char(1), onde receberá C se a formula for de custo e V se a formula for de venda. A tabela produto terá os campos id e a flag(que vc dará um nome qualquer), que será a chave estrangeira.
olha é o seguinte o problema, de não se fazer uma boa modelação vem muito depois, e por vezes quando o problema vem, vais ter que começar o projecto do 0.
normalmente pela experiençia que eu tenho se modelares mal vai acontecer o seguinte:
[list]sera dificil e quase impossivel a manutenção[/list]
[list]sera dificil a construcao dos formularios[/list]
[list]a base de dados mesmo com poucos dados podera ocupar muito espaço ( isso apenas acontece raramente)[/list]
[list]fazer as pesquisas ( consultas) será muito complicado[/list]
[list]pedir ajuda a terceiros será quase impossivel, ninguem vai ter paciencia de analisar uma consulta ou similar para uma base de dados mal modelada[/list]
agora para concluir eu ainda nao analisei bem as tuas duas tabelas ( estava com preguiça de ler) vou analisar e dizer alguma coisa.
modelagem é minha especialidade, e eu tentei analisar e reanalisei e até agora nao entendi o que querias fazer, e o factor de eu nao entender é porque deve estar errado.
algo bem modelado qualquer um entende logo rapido.
mas tenta explicar por palavras o que querias fazer ( talvez até esteja bem modelado) e depois da tua explicacao vou modelar para voce e explicar
Se surgir mais um tipo formula a estrutura da tabela Produto terá que ser alterada.
No código certamente haverá IFs para identificar qual fórmula está sendo aplicada.
Sempre haverá uma coluna nula, a não ser que o produto sem tenha as duas formulas.
Outra alternativa é igual ao que já foi dito (acho) antes.
Criar uma tabela associativa (n x n ) entre a tabela Produto e Formula; na tabela formula tera que ser criada uma coluna para identificar é qual tipo de formula.
Esta solução elimina possiveis colunas nulas e a necessidade de alterar a estrutura da tabela Produto ao surgir uma nova formula. Porem, a necessidade de verificar qual é o tipo de formula que está sendo aplicada continua.
Cara, eu acho uma má idéia.
Se você precisar expandir seu projeto pra que um produto aceite mais fórmulas, como fica?
E se um produto tiver apenas uma fórmula? Vai ficar uma FK nula.
Use uma relação 1-n, vai deixar o projeto mais limpo e extensível.
Ok, obrigado pelas respostas e atencao dos senhores. Eu vi que realmente eu deveria ter explicado melhor. é o seguinte. eu tenho a tabela produto e a tabela formula na qual cadastro formulas para calculo dos precos de custo e venda do produto. No produto eu preciso informar qual formula de custo e venda ele deve utilizar. Por isso gostaria de saber se a modelagem que coloquei seria apropriada para esse caso, sem a a utilizacao da tabelal de n:n.
[quote=thimor]Ok, obrigado pelas respostas e atencao dos senhores. Eu vi que realmente eu deveria ter explicado melhor. é o seguinte. eu tenho a tabela produto e a tabela formula na qual cadastro formulas para calculo dos precos de custo e venda do produto. No produto eu preciso informar qual formula de custo e venda ele deve utilizar. Por isso gostaria de saber se a modelagem que coloquei seria apropriada para esse caso, sem a a utilizacao da tabelal de n:n.
mais uma vez obrigado.[/quote]
Excia, ja notei que tens alguns problemas de modelação, mas isso sera superado rapidamente, mas para te ajudar tens que te explicar melhor.
Mas tendo em conta o pouco que disseste, ai vai
[list]se tens uma tabela produto e uma formula para calcular o preço do produto então não precisas de tabela formula, a não ser que diferentes produtos tenham a mesma formula de calculo do preço[/list]
Tera produtos com a mesma formula de calculo de preço??
exemplifica os dados possiveis das tabelas produto e formula ( até pelo menos 5 dados em cada tabela)??
o exemplo de uma formula de preco de custo que estaria cadastrada na tabela formula so para entenderem melhor
COMPRA+(COMPRA*((IPI+FRETE+DESPESAS-ICMSCOMPRA-PIS-COFINS)/100)
assim eu posso definir mais de uma formula de custo conforme eu queira e atribuir a diferentes produtos formulas diferentes ou definir a mesma formula a todos os produtos.
o exemplo de uma formula de preco de custo que estaria cadastrada na tabela formula so para entenderem melhor
COMPRA+(COMPRA*((IPI+FRETE+DESPESAS-ICMSCOMPRA-PIS-COFINS)/100)
assim eu posso definir mais de uma formula de custo conforme eu queira e atribuir a diferentes produtos formulas diferentes ou definir a mesma formula a todos os produtos.[/quote]
eu pedi que pussesses um exemplo de tabela com os dados, para ser mais facil analisar, mas ta bom vou analisar e dar a minha opinião
o exemplo de uma formula de preco de custo que estaria cadastrada na tabela formula so para entenderem melhor
COMPRA+(COMPRA*((IPI+FRETE+DESPESAS-ICMSCOMPRA-PIS-COFINS)/100)
assim eu posso definir mais de uma formula de custo conforme eu queira e atribuir a diferentes produtos formulas diferentes ou definir a mesma formula a todos os produtos.[/quote]
Analisando a situação vejo 2 saidas, uma que pode não ser a melhor para o teu caso, mas que é uma opção a pensar, é a seguinte.
[list]a formula de venda e a formula de custo se for a mesma para todos os produtos devias por na logica do lado da linguaguem de programação, e não na base de dados[/list]— mas descartando esta idea. ai vai a outra idea.
[b]
o campo id_tipo, pode ser uma chave estrangeira para outra tabela tipo, ou pode ser um campo do tipo enum , se os dados possiveis de tipo forem apenas ( venda, e compra) então podera ser do tipo enum, agora se posteriormente haver mais tipos então deveras de inicio por uma tabela tipo e definir o campo como chave estrangeira
A tabela produto inicial tinha os campos formulacusto
formulavenda
mas ai esta o problema preste atenção nesta palavra
formulacusto, ( esta palavra explica que sera uma formula de custo, então custo ja é dados,) e estavas a querer dar nome de dados( custo) num campo
a mesma coisa para o campo formulavenda.
agora imagina se depois de uns anos do sistema estar a funcionar , te mandassem aumentar outros tipos de formulas para .
formula de promocao
formula de venda a grosso
formula de venda a retalho
formula de venda a funcionarios.
ai ias aumentar um montao de campos na tabela produto
por isso eu disse ontem que se modelamos mal o sistema posteriormente dara outros problemas futuros na manutenção e actualização
lembrando agora eu te pergunto que erro notas no meu modelo relacional???
depois de eu olhar o modelo pela segunda vez notei um erro.
na tabela formula
como podera existir varias formulas ( formula de venda, formula de custo, formula de promoção, formula de venda a funcionarios, formula de venda a grosso e etc)
então na tabela formula alem da formula e do campo id_formula, devemos acrescentar um campo descricao da formula, para sabermos se esta formula
se refere a formula de que.
e ja agora que abriste este topico se tiveres mais duvidas sobre modelo relacional, podes meter para entenderes de uma vez por todas como modelar um sistema correctamente.
retificando o erro e voltando a por o modelo relacional ai vai.
[b]
formula
id_formula
formula
id_tipo ( venda, custo)
descricao
[/b]
exemplo de dados na tabela formula id_formula ; -------------------formula ; ------------------ id_tipo ; --------------------descricao
1----------------- IPI+FRETE+DESPESAS-ICMSCOMPRA-PIS-COFINS)/100--------- venda ---- formula para venda geral
2----------------- IPI+FRETE+DESPESAS-ICMSCOMPRA-PI -----------------------venda------ formula para venda de produtos exportados
3-----------------IPI+FRETE ---------------------------------------------------------------custo------- formula de custo geral
não esquecer que eu pus formula aleatorias, mas é apenas para te ilustrar de como vai ficar.
por vezes se fizermos uma tabela com os dados nos da uma visão melhor de como modelar os dados.
agora imagina aquele cenario, de depois de 2 anos pedirem para inserir novas formulas, ai será facil, nao teras que mudar o modelo relacional apenas basta aumentares dados na tabela formula e ou criar um formulario de inserção de novas formulas.