Modelo er para sistema de oficinas

[Eder Cuer]

Eae pessoal, tudo beleza?

 

Estou montando um sistema para gerenciamento de oficinas e travei justamente no começo, bem na modelagem de dados. Faz muito tempo que não me aventuro por esses lados e me surgiu uma dúvida.

 

O sistema será online e irei utilizar PHP + MySQL. 

A ideia é facilitar todo o processo que ocorre em uma oficina, onde o cliente pode fazer revisões, comprar peças, lavar o carro e etc. 

Levando em consideração que em uma oficina temos compras de peças e serviços criei as respectivas tabelas, também teremos vendas na oficina que pode ser um serviço ou uma peça e é ai que entra a dúvida, como será esse relacionamento? Inicialmente eu estava pensando em relacionar as tabelas e colocar as chaves estrangeiras de serviços e peças mas fiquei pensando caso um cliente fizesse apenas uma lavagem ou compre apenas uma peça, poderia deixar uma das chaves estrangeiras vazias. Pensei também em criar uma outra tabela fazer um relacionamento e ai sim adicionar em vendas mas não sei a melhor forma de fazer isso.

 

Não sei se ficou muito claro, caso for uma dúvida besta levem em consideração que faz muito tempo que não faço MER hehe.

 

Segue um print:

Spoiler

 

[DiF]

@Eder Cuer Mesmo processo de uma loja virtual, o que precisas ali é de uma tabela  N:N entre os produtos, vendas e serviços.

 

Em vendas você coloca os dados da venda  como o ID da venda,  id do cliente, data de venda, valor total,  e a forma de pagamento( avista, cartao, cheque etc)

Daí então crie uma tabela chamada itensvendas  que será um N:N com a tabela produto e serviço.. que vai conter os campos o ID do produto a ser vendido, ou o id do serviço a ser vendido... o ID da venda em si, ( considere a venda como serviço tb,.. afinal vendemos o serviço) e o preço dele.

 

Basicamente é isso... se não quiser "misturar... podes criar duas tabelas N:N

 um itensVendasProdutos  que controla as vendas de produtos,  e um itensVendasServicos que controla as vendas dos serviços.

 

Modelei um BD quando estava na faculdade no meu tcc...  estou disponibilizando para que você possa entender como é modelado.

PS: é protegido pelos direitos autorais heim!!   rsrsr brincadeiras à parte, espero que seja de alguma ajuda para você

 

 

 

[Eder Cuer]

@dif Então meu raciocínio estava no caminho certo. Vou ir modelando aqui e depois mostro completo.

Ajudou muito.

 

Caiu na net já era kkkkkkkk.

[Eder Cuer]

@dif

Seu MER me ajudou, até segui seu modelo para algumas tabelas. Criei uma tabela acompanhamento para o cliente poder consultar o andamento de uma revisão, por exemplo. Também achei melhor criar uma tabela específica para usuários do sistema (colaboradores e dono).

 

MER:

 

A tabela acompanhamento seria relacionada com vendas mesmo ou com itensVendas?

 

Alguém ai que costuma utilizar os serviços de oficinas teria algo a acrescentar em um sistema desse tipo? Tipo uma funcionalidade que seria legal para um cliente...

[DiF]

@Eder Cuer É praticamente isso. Na tabela " itens vendas" acredito que tenha faltado o valor do produto/serviço.. a não ser que esteja escondido ali no nome grande..

infelizmente essa é uma péssima caracteristica do mysql workbench.. de colocar esses nomes gigantes nos campos  rsrs

 

Fora isso não tenho nada a acrescentar.. não no momento.

[Eder Cuer]

Esqueci de editar os campos hehe.

Iria um valor na tabela itensVendas mesmo? Porque coloquei ali o preço unitário do produto e serviço.. Falando nisso vou adicionar um campo estoque as peças para controle e etc.

[DiF]

@Eder Cuer Dá uma olhadinha novamente no meu ER.

 

No itens vendas, tem um preço.. que é unitário...  já em vendas, o totalDesconto, é na verdade um "valor total".. pois imagine,  um cliente compre peças( produto), mande colocar estas peças(serviço) e de quebra pede para lavar o carro.( mais outro serviço) no final você contabiliza e dá o total final de quanto ele vai desembolsar!

é mais ou menos nessa linha de pensamento.

[Eder Cuer]

@dif

Entendi!

Eu pensei no seguinte, se o cliente fizer tudo ai que você disse na vdd será mais um cadastro na tabela itensVendas.

Vamos "enxergar" o seu exemplo com o que eu estava pensando simulando o funcionamento apenas na tabela itensVendas.

 

compra de peça: 

itensVendas: 1 - 1 - null - 1

 

compra serviço (mão de obra e lavagem):

itensVendas:  

• 2 - null - 1 - 1
• 3 - null - 2 - 1

Não sei se ficou claro, aliás, uma chave estrangeira pode ser nula?

Deu uma embarralhada na cabeça agora.

 

[DiF]

@Eder Cuer Entendo sua linha de pensamento e não deixa de estar certo. O lance é que está separado. 

O que melhor pode resolver o problema  é:  No itens vendas você usar o mesmo campo para os dois, produto e serviços..( sim dá para usar uma chave para os dois.)

 

Ou simplesmente você desmantela e aplica a 2NF na tabela... criando uma nova tabela N:N... aí você cria o itensvendas para o produto e cria um outro igual para o serviço.

assim você não tem perigo de ter uma chave em nulo( lembrando que nulo não é vazio.  é um valor.)

 

Das duas,  eu ficaria com a segunda ideia de criar uma tabela de controle para cada. isso torna seu banco menos suscetível a inconsistência de dados e redundâncias.

 

Isso que dizer que você teria a seguinte estrutura:

 

|produtos|------------->|itensvendasP|----------->|Vendas|

|servicos|------------->|itensvendasS|----------->|vendas|

sendo que o campo Vendas_id_vendas  será comum nas duas. pois ambos serão chaves estrangeiras de ID vendas da tabela Vendas!

 

Na minha opinião seria a melhor forma de contornar isso... O banco de dados pode ter muitas tabelas.  então não tem problema você criar duas para o controle.

 

No mais se tu quiser, tirar a limpo e testar para ver se não dá problemas.. usando uma única tabela fique a vontade! Porque se eu não me engano.. tu podes fazer uma relação N:N com um campo e vários outros chaves primárias. 

[Eder Cuer]

@dif

Entendi perfeitamente, eu já ia perguntar se essa solução era a melhor assim que você levantou lá atrás.

 

Ficou assim:

[DiF]

@Eder Cuer Está quase lá.

 

Ao meu ver só tens que alterar algumas coisinhas ali. por exemplo:

Retirar o primeiro itensvendas e relacionar diretamente o idVendas da tabela vendas com o campo idvendas nas tabelas N:N criadas. O valor dos produtos, altere para o tipo Double  9,2

 

Como estou sem o workbemch aqui.... editei no photoshop só para teres uma ideia do que estou falando.

 

PS: as linhas pontilhadas significa que estas usando campos que já existem... as linhas lisas significa que o proprio workbech criou os campos.. por isso a chave vermelhinha.. e porque assim ele define chaves compostas. 

 

Veja o modelo

 

PS2: posso ter me enganado algo sobre as chaves amarela ou vermelha... rsrs faz muito tempo que mexi com eles... er.. deixe-me ver.. desde 2012 +- que não brinco no workbench.   Em todo o caso... estás no caminho certo.

 

 

[Eder Cuer]

Entendi, agora estou apanhando do workbench kkkkkkkkkkkkkkkkkkk

Chave amarela quer dizer chave primária e vermelha estrangeira. O workbench acaba deixando a gente preguiçoso, e até entender todas as opções dele demora um pouco.

 

 

Agora me confundi todo kkkkkkk

[DiF]

Na verdade, pelo que eu lembrava.. quando estudei, a chave estrangeira era retratada pelo losango vermelho( veja sua tabela vendas os campos idcliente e idFormPagamento)

Até então tinha quase certeza de que a chave amarela seria a primária e a vermelha usada para chaves compostas. 

rsrs

 

No caso do meu ER que postei minhas chaves estrangeiras são retratadas como  #(tralha) porque foi feito diretamente no phpmyadmin rsrs

[Eder Cuer]

Na verdade é isso mesmo, chave vermelha é pra composta, chave estrangeira é o losango (olha eu ficando lesado já kkkk).

 

Então fica assim mesmo?

[DiF]

Sim exatamente isso mesmo.  Agora só não me recordo da necessidade de ter o valor unitário na tabela  N:N

Como está no meu ER. eu fiz assim por que na época meu orientador me disse que era desse jeito.. rsrsr 

Hj eu tenho minhas dúvidas...  você tá chegando lá. 

[Eder Cuer]

Estava aqui analisando a modelagem e acho que posso começar a desenvolver já.

Adicionei um campo valorDesconto na tabela vendas em caso de descontos que a oficina queira fazer, adicionei o campo descrição nas tabelas peças e serviços.

 

Estava pensando em criar uma tabela promoções, pensei, pensei e talvez só se houver necessidade, fazer isso agora já adiantaria um bom tempo mas talvez possa utilizar a tabela serviços para fazer isso... vamos ver...

 

Segue a modelagem:

[DiF]

@Eder Cuer Está ótimo.   só tem dois detalhes ali.  todos os campos com preços. altere de DECIMAL para DOUBLE.  e a tabela  acesso não está relacionada com nada.  acredito que ela será relacionada com a tabela cliente, ou seja,  a tabela de acessos precisa do campo chave estrangeira de Idcliente da tabela cliente.

O nivel é outro que precisa mudar  atualmente o mysql está usando Tinyint  .. mas enfim.. isso não será um problema!

 

 

[Eder Cuer]

@dif Atualizado.

 

No double não precisa especificar a quantidade de caracteres?

Quando fiz a tabela acesso estava fazendo somente para o dono/colaborador da oficina porém lembrei que o cliente também terá acesso ai fiz a ligação, agora não existe tabelas soltas.

 

Eu nunca fiz um painel administrativo com níveis de acesso, tem como fazer de boa sem encher de if?

[DiF]

@Eder Cuer  O double precisa do tamanho apenas..  só precisa manter os 9,2 mesmo! Preços sempre se usa Double(9,2)! 

Sim.  podes usar o switch-case para isso. 

 

Por exemplo  no momento do login, resgatar o valor do campo nível.. e comparar:

 

$nivel->nivel;

switch($nivel):
    case 1: header("paineladmin.php") break;
    case 2: header("areaCliente.php") break;
endswitch;

Bom é só um exemplo logico que tens que implementar.. mas isso é um assunto para o setor web! quando tiver desenvolvendo podes criar um tópico sobre isso lá.

 

[Eder Cuer]

Ata, então são só detalhes.

 

Ah então é sossegado tratar com níveis, nem tinha pensado nisso kkkkkkkkk. 

 

Pô @difmuito obrigado pela ajuda e paciência. Logo eu apareço com mais dúvidas 

[emailpublico3]

Então, minha sugestão é a seguinte.

 

A diferença de produto ou serviço, é justamente, se um é produto, ou serviço, ou seja, os campos das DUAS tabelas são iguais, e você tem 2 relacionamentos desnecessários.

 

Então porque não criar apenas a tabela produto, e criar uma coluna, que será , produto_servico, nesta coluna, você irá definir como sendo Boolean, char, etc, da forma que preferir.

 

Assim, você reduz, uma tabela, um relacionamento.

 

VENDAS ----<   ITENS_VENDAS >-------PRODUTO [ idProduto, produto_servico(char['P' OU 'S'], nome, valor, descricao)

etc.

 

 

 

 

 

[Eder Cuer]

@emailpublico3 Pô cara, pode ser uma boa ideia. Vou pensar nisso e valeu pela sugestão.

[Eder Cuer]

Seguindo a sugestão do @emailpublico3 atualizei a modelagem:

 

 

[Eder Cuer]

Estava pensando aqui, vou adicionar a funcionalidade de notificação tipo do facebook tanto para o usuário quanto para o dono da oficina.

Meu raciocínio era criar uma tabela "notificacao" relacionada com usuário, será que preciso de outra, a lógica é essa mesmo?

[DiF]

@Eder Cuer Não. É essa mesmo. crie a tabela de notificações que recebe o ID do cliente,  ID do dono e a notificação.