MODELAGEM DE DADOS
Amigos boa noite,
Após compreender boa parte do conceito de OO, volto o foco para um assunto tão importante quanto: a modelagem de nossos bancos de dados.
Como todos fazem de praxe, começam a escrever o código de um pequeno cadastro e a coisa vai crescendo. AÃ nesse momento você percebe que seu banco não foi modelado corretamente, começa os gatilhos, e tudo vai pro brejo.
Meu caso não foi diferente, e hoje tenho um banco SQL como mais de 200 tabelas, e creio que 50% a 70% das tabelas não estão modeladas corretamente. Sei que não é possÃvel para tudo para fazer do zero, então é necessário fazer as adequações por partes ou setores para não perder dados e parar o fluxo de trabalho.
Para começar vou postar minha tabela de produtos como está hoje. Preciso remodelá-la, mas não tenho idéia de como fazer ou qual seria o melhor caminho a adotar.
Agradeço a todos pela ajuda.
Após compreender boa parte do conceito de OO, volto o foco para um assunto tão importante quanto: a modelagem de nossos bancos de dados.
Como todos fazem de praxe, começam a escrever o código de um pequeno cadastro e a coisa vai crescendo. AÃ nesse momento você percebe que seu banco não foi modelado corretamente, começa os gatilhos, e tudo vai pro brejo.
Meu caso não foi diferente, e hoje tenho um banco SQL como mais de 200 tabelas, e creio que 50% a 70% das tabelas não estão modeladas corretamente. Sei que não é possÃvel para tudo para fazer do zero, então é necessário fazer as adequações por partes ou setores para não perder dados e parar o fluxo de trabalho.
Para começar vou postar minha tabela de produtos como está hoje. Preciso remodelá-la, mas não tenho idéia de como fazer ou qual seria o melhor caminho a adotar.
[codigo] [int] NULL,
[nome] [nvarchar](60) NULL,
[codigo_barras] [nvarchar](13) NULL,
[descricao] [nvarchar](255) NULL,
[unidade] [nvarchar](3) NULL,
[tipo] [int] NULL,
[grupo] [int] NULL,
[classe] [int] NULL,
[estoque_atual] [float] NULL,
[estoque_minimo] [float] NULL,
[estoque_maximo] [float] NULL,
[similar] [nvarchar](6) NULL,
[peso_bruto] [float] NULL,
[peso_liquido] [float] NULL,
[volume] [float] NULL,
[validade] [int] NULL,
[aliquota_icms] [money] NULL,
[aliquota_ipi] [money] NULL,
[aliquota_pis] [money] NULL,
[aliquota_cofins] [money] NULL,
[ncm] [nvarchar](10) NULL,
[cst] [nvarchar](3) NULL,
[numero_onu] [nvarchar](6) NULL,
[data_revisao_pop] [datetime] NULL,
[equipamento] [nvarchar](80) NULL,
[epis] [nvarchar](255) NULL,
[preco_compra] [money] NULL,
[valor_ipi_compra] [money] NULL,
[outros_custos] [money] NULL,
[preco_custo] [money] NULL,
[custo_operacional] [money] NULL,
[margem_lucro] [money] NULL,
[preco_venda00] [money] NULL,
[preco_venda28] [money] NULL,
[preco_venda42] [money] NULL,
[preco_venda56] [money] NULL,
[preco_venda_min] [money] NULL,
[modo_uso] [nvarchar](255) NULL,
[observacao] [nvarchar](255) NULL,
[observacao_laudo] [nvarchar](255) NULL,
[inativo] [bit] NULL,
[imprimir_op] [bit] NULL,
[imprimir_tabela_preco] [bit] NULL,
[pedir_data_fabr_mp] [bit] NULL,
[controlado] [bit] NULL,
[limite_qtde_licenca] [float] NULL,
[tabela_analise] [int] NULL,
[comissao_lab] [money] NULL,
[comissao_cor] [money] NULL,
[cst_origem] [int] NULL,
[perc_importacao] [money] NULLAgradeço a todos pela ajuda.
Bem, vamos lá com meu pitaco:
Os conceitos de OOP, também se aplicam ao banco de dados, fato. Cada coisa é uma coisa. Dados de produto e de estoque, são objetos diferentes, logo, devem estar em tabelas diferentes. O mesmo para comissões, preços e custos, que são dados relativos ao movimento.
O mais importante aqui é entender o funcionamento de [Ô]estoque[Ô]. Estoque, nada mais é que uma conta, um saldo baseado em lançamentos. Cada compra de produto do fornecedor, é um movimento no estoque, com um preço especÃfico, data de entrada, comissão(sim, existem muitos casos em que a comissão do vendedor é diferente para diferentes lotes) e tudo o mais relativo ao produto e à venda no momento. No momento da venda de cada produto, a [Ô]baixa no estoque[Ô], deve levar em conta à que lote o produto vendido pertencia, isso geralmente é regido pelo sistema PEPS ou FIFO(Primeiro Entra Primeiro Sai ou First In First Out), existem algumas outras metodologias, mas o PEPS é o mais comum. Na verdade, não existe [Ô]baixa[Ô] no estoque, existem lançamentos de entrada, saÃda ou relocação de produtos. Esses lançamentos são a base para o estoque, eles são a [Ô]conta[Ô]. A soma de entradas subtraÃda da soma de saÃdas, compõem o [Ô]saldo em estoque[Ô].
A importância para um sistema de controle de movimentação de estoque, fica muito mais visÃvel e latente, quando se usa:
- Estoque distribuÃdo, com múltiplos locais de armazenamento em diferentes locais fÃsicos(depósitos)
- Produtos perecÃveis, onde a entrada e saÃda devem ter uma ordem correta para evitar perda
- Se quer controlar preço médio do produto baseado em compras de múltiplos fornecedores(para um mesmo produto), com isso pode-se ter a média mais detalhada, inclusive por região, porte do fornecedor...
- Se o produto possui alÃquotas estaduais diferentes e você possui estoques em diferentes estados
Enfim, existem muitas outras situações em que o controle organizado de estoque se faz muito necessário. Para o pequeno cliente, isso faz pouca diferença, pois o estoque é mesmo controlado [Ô]à olho[Ô] mesmo e os dados são menos precisos. Mas se você tem um cliente maior, muito mais criterioso, aà não tem jeito, ou se faz do jeito certo ou nem tenta.
Resumindo o começo de uma reorganização da sua tabela é separar o que é relativo à produto em tabela de produto, o que é relativo à estoque, em um conjunto de tabelas e por aà vai.
Os conceitos de OOP, também se aplicam ao banco de dados, fato. Cada coisa é uma coisa. Dados de produto e de estoque, são objetos diferentes, logo, devem estar em tabelas diferentes. O mesmo para comissões, preços e custos, que são dados relativos ao movimento.
O mais importante aqui é entender o funcionamento de [Ô]estoque[Ô]. Estoque, nada mais é que uma conta, um saldo baseado em lançamentos. Cada compra de produto do fornecedor, é um movimento no estoque, com um preço especÃfico, data de entrada, comissão(sim, existem muitos casos em que a comissão do vendedor é diferente para diferentes lotes) e tudo o mais relativo ao produto e à venda no momento. No momento da venda de cada produto, a [Ô]baixa no estoque[Ô], deve levar em conta à que lote o produto vendido pertencia, isso geralmente é regido pelo sistema PEPS ou FIFO(Primeiro Entra Primeiro Sai ou First In First Out), existem algumas outras metodologias, mas o PEPS é o mais comum. Na verdade, não existe [Ô]baixa[Ô] no estoque, existem lançamentos de entrada, saÃda ou relocação de produtos. Esses lançamentos são a base para o estoque, eles são a [Ô]conta[Ô]. A soma de entradas subtraÃda da soma de saÃdas, compõem o [Ô]saldo em estoque[Ô].
A importância para um sistema de controle de movimentação de estoque, fica muito mais visÃvel e latente, quando se usa:
- Estoque distribuÃdo, com múltiplos locais de armazenamento em diferentes locais fÃsicos(depósitos)
- Produtos perecÃveis, onde a entrada e saÃda devem ter uma ordem correta para evitar perda
- Se quer controlar preço médio do produto baseado em compras de múltiplos fornecedores(para um mesmo produto), com isso pode-se ter a média mais detalhada, inclusive por região, porte do fornecedor...
- Se o produto possui alÃquotas estaduais diferentes e você possui estoques em diferentes estados
Enfim, existem muitas outras situações em que o controle organizado de estoque se faz muito necessário. Para o pequeno cliente, isso faz pouca diferença, pois o estoque é mesmo controlado [Ô]à olho[Ô] mesmo e os dados são menos precisos. Mas se você tem um cliente maior, muito mais criterioso, aà não tem jeito, ou se faz do jeito certo ou nem tenta.
Resumindo o começo de uma reorganização da sua tabela é separar o que é relativo à produto em tabela de produto, o que é relativo à estoque, em um conjunto de tabelas e por aà vai.
Citação:Na verdade, não existe [Ô]baixa[Ô] no estoque, existem lançamentos de entrada, saÃda
Realmente, faço isso, inclusive para ter o histórico detalhado do item, pois o cliente fica com a pulga atras da orelha,pesando se o sistema esta dando baixa certo ou não, Na primeira falha de estoque, o sistema é o primeiro suspeito.
Citação:Estoque distribuÃdo, com múltiplos locais de armazenamento em diferentes locais fÃsicos(depósitos)
Infelizente isso só para grandes comerciantes, como vc disse.
No meu caso em pequenos comercios, eu faço o usuario lançar a data de validade do lote, ediariamente ele pode gerar relatórios com os lotes a vencer.
Grande KERPLUNK,
Você acertou em cheio. Hoje eu tenho 4 estoques (depósitos), e está se tornando difÃcil o controle dos mesmos.
Entendi perfeitamente o conceito que você atribuiu de ser uma [Ô]conta[Ô]. Funcionaria com uma conta bancária.
No entanto, baseado na minha tabela, você teria alguma sugestão de modelagem, para que eu possa visualizar isso de uma maneira melhor?
Seguindo esse conceito, ao fazer uma venda, o lançamento seria com valor negativo, ao invés de uma tabela para saÃdas, é isso mesmo?
Como ficaria os itens de uma entrada ou venda, seria relacionado aos lançamentos (movimento) ou uma tabela a parte?
Esse será o meu primeiro passo para uma correta abordagem do banco, pois ainda tenho outros setores que passarão pelo mesmo processo.
LLAIA,
Li o artigo e achei muito interessante, boa parte do que foi dito, infelizmente ocorreu aqui no meu serviço.
Agradeço pela ajuda.
P.S.: Kerp, no outro tópico sobre o Conceito de OOP, ainda tem algumas dúvidas sobre os tópicos que você dispôs a comentar.
Você acertou em cheio. Hoje eu tenho 4 estoques (depósitos), e está se tornando difÃcil o controle dos mesmos.
Entendi perfeitamente o conceito que você atribuiu de ser uma [Ô]conta[Ô]. Funcionaria com uma conta bancária.
No entanto, baseado na minha tabela, você teria alguma sugestão de modelagem, para que eu possa visualizar isso de uma maneira melhor?
Seguindo esse conceito, ao fazer uma venda, o lançamento seria com valor negativo, ao invés de uma tabela para saÃdas, é isso mesmo?
Como ficaria os itens de uma entrada ou venda, seria relacionado aos lançamentos (movimento) ou uma tabela a parte?
Esse será o meu primeiro passo para uma correta abordagem do banco, pois ainda tenho outros setores que passarão pelo mesmo processo.
LLAIA,
Li o artigo e achei muito interessante, boa parte do que foi dito, infelizmente ocorreu aqui no meu serviço.
Agradeço pela ajuda.
P.S.: Kerp, no outro tópico sobre o Conceito de OOP, ainda tem algumas dúvidas sobre os tópicos que você dispôs a comentar.
Citação:No entanto, baseado na minha tabela, você teria alguma sugestão de modelagem, para que eu possa visualizar isso de uma maneira melhor?
Você até poderia deixar a estrutura como está e passar a utilizar o conceito de [Ô]conta[Ô]
Citação:Seguindo esse conceito, ao fazer uma venda, o lançamento seria com valor negativo, ao invés de uma tabela para saÃdas, é isso mesmo?
Cada lançamento, tem um tipo especÃfico. Cada tipo, determina a operação, se [Ô]adiciona[Ô], [Ô]subtrai[Ô], ou simplesmente movimenta de estoque para estoque.
Algo assim:
Select entradas - saidas from
(
select CodigoProduto, Sum(quantidade) entradas from movimento where tipo = [ô]ENTRADA[ô] group by CodigoProduto
union
select CodigoProduto, Sum(quantidade) saidas from movimento where tipo = [ô]SAIDA[ô] group by CodigoProduto
)
Where CodigoProduto in ([ô]2323[ô], [ô]343434[ô], [ô]454545[ô])
O código acima, daria o saldo dos produtos cujo código esteja dentro da cláusula [Ô]In[Ô]. Usando esse mesmo raciocÃnio, se pode construir uma query para até mesmo um [Ô]extrato[Ô] de movimentação de produtos, só que o invés de somar quantidade, você simplesmente a lista.
Citação:Como ficaria os itens de uma entrada ou venda, seria relacionado aos lançamentos (movimento) ou uma tabela a parte?
Quando se faz uma venda, se faz o lançamento de saÃda daquele produto. Esse lançamento, é construÃdo levando-se em conta o modo de gestão do seu estoque, que como falei, pode ser PEPS ou qualquer outro.
Amigos, depois de algum tempo analisando os dados e as regras de negócio fiz essa modelagem conforme imagem.
Esse modelo estaria em melhor conformidade, levando em conta o que foi citado nos posts anteriores? Se não, o que sugerem adicionar/remover/melhorar.
Agradeço pela opinião de todos.
Esse modelo estaria em melhor conformidade, levando em conta o que foi citado nos posts anteriores? Se não, o que sugerem adicionar/remover/melhorar.
Agradeço pela opinião de todos.
Ta quase lá! Movimento, possui cabeçalho e Ãtens. Cada Ãtem do movimento além do produto, contém o preço de movimentação, quantidade, data real da movimentação(à s vezes, a compra chega em partes). O movimento em si é basicamente uma cópia de um pedido de compra ou pedido de venda. Mas o resto é mais ou menos isso mesmo.
Tópico encerrado , respostas não são mais permitidas