Checkup Modelagem Banco de dados
26/12/2022
0
Caro colegas, não tenho uma experiência aprofundada em banco de dados, portanto solicito apoio para verificarem se está correto a modelagem do banco que segue, será em MySQL.
Esse banco de dados, será utilizado em uma aplicação simples para armazenar o dados dos produtos, como numero de serie e etiquetas internas de garantia das peças.
As regras são:
A- Cada produto é constituído por um conjunto de peças. Cada peça recebe uma etiqueta interna de garantia.
B- Cada produto tem seu número de série único e exclusivo.
C- As etiquetas de garantia são fabricadas em lotes de sequencia única, não repetida e identificadas por sequencia numérica exclusiva.
D- Cada peça recebe uma etiqueta de Garantia. A etiqueta de garantia é violável, caso peça seja substituída requer nova etiqueta.
E- Cada modelo de produto, exemplo TVP400 ou TL320 possui é constituído por grupo de peças específicas.
F- Cada modelo exige uma nova tabela de sua composição.
G- Cada número de série tem uma data que foi associado ao produto.(data_fabrico)
Algumas duvidas, que tenho:
1)Neste modelamento, ao adicionar dados em TVP400 ou TL320, se existir algum numero de serie ou etiqueta de garantia já utilizada, o SGBD, irá impedir?
2)Caso ocorra, a rejeição de adição de dados, relacionado a pergunta anterior, tem como identificar os elementos que repetiram? Ou requer pesquisa no banco de dados?
3)Alguma dica ou sugestão ao modelo apresentado.
[url=https://postimg.cc/tnVx15zX][img]https://i.postimg.cc/tnVx15zX/banco-de-dados-ratro-DRE.png[/img][/url]
Esse banco de dados, será utilizado em uma aplicação simples para armazenar o dados dos produtos, como numero de serie e etiquetas internas de garantia das peças.
As regras são:
A- Cada produto é constituído por um conjunto de peças. Cada peça recebe uma etiqueta interna de garantia.
B- Cada produto tem seu número de série único e exclusivo.
C- As etiquetas de garantia são fabricadas em lotes de sequencia única, não repetida e identificadas por sequencia numérica exclusiva.
D- Cada peça recebe uma etiqueta de Garantia. A etiqueta de garantia é violável, caso peça seja substituída requer nova etiqueta.
E- Cada modelo de produto, exemplo TVP400 ou TL320 possui é constituído por grupo de peças específicas.
F- Cada modelo exige uma nova tabela de sua composição.
G- Cada número de série tem uma data que foi associado ao produto.(data_fabrico)
Algumas duvidas, que tenho:
1)Neste modelamento, ao adicionar dados em TVP400 ou TL320, se existir algum numero de serie ou etiqueta de garantia já utilizada, o SGBD, irá impedir?
2)Caso ocorra, a rejeição de adição de dados, relacionado a pergunta anterior, tem como identificar os elementos que repetiram? Ou requer pesquisa no banco de dados?
3)Alguma dica ou sugestão ao modelo apresentado.
Table "num_serie" {
"numero_serie" varchar(14) [pk, not null]
"data_fabrico" datetime [not NULL]
"idmodelo" int(10) [not NULL]
Indexes {
numero_serie [name: "numero_serie"]
}
}
Table "TVP400" {
"peca1" varchar(14) [not null]
"peca2" varchar(14) [not null]
"peca3" varchar(14) [not null]
"peca4" varchar(14) [not null]
"id_num_serie" varchar(14) [not null]
Indexes {
id_num_serie [name:"id_num_serie"]
}
}
Table "TL320" {
"peca1" varchar(14) [not null]
"peca2" varchar(14) [not null]
"peca3" varchar(14) [not null]
"peca4" varchar(14) [not null]
"peca5" varchar(14) [not null]
"id_num_serie" varchar(14) [not null]
Indexes {
id_num_serie [name:"id_num_serie"]
}
}
Table "garantias" {
"etiqueta_garantia" varchar(14) [pk, not null, increment]
"data_inserida" datetime
Indexes {
etiqueta_garantia [name: "etiqueta_garantia"]
}
}
Table "modelo" {
"id_modelo" int(1) [pk, not null, increment]
"nome" varchar(12) [default: NULL]
Indexes {
nome [name: "nome"]
}
}
Table "usuarios" {
"id_user" int(1) [pk, not null]
"apelido" varchar(12) [not null]
"nome" varchar(40) [not null]
"cargo" varchar(12) [default: NULL]
}
Ref{
modelo.id_modelo < num_serie.idmodelo
}
Ref{
num_serie.numero_serie - TVP400.id_num_serie
}
Ref{
TVP400.peca1 - garantias.etiqueta_garantia
}
Ref{
TVP400.peca2 - garantias.etiqueta_garantia
}
Ref{
TVP400.peca3 - garantias.etiqueta_garantia
}
Ref{
TVP400.peca4 - garantias.etiqueta_garantia
}
Ref{
num_serie.numero_serie - TL320.id_num_serie
}
Ref{
TL320.peca1 - garantias.etiqueta_garantia
}
Ref{
TL320.peca2 - garantias.etiqueta_garantia
}
Ref{
TL320.peca3 - garantias.etiqueta_garantia
}
Ref{
TL320.peca4 - garantias.etiqueta_garantia
}
Ref{
TL320.peca5 - garantias.etiqueta_garantia
}
[url=https://postimg.cc/tnVx15zX][img]https://i.postimg.cc/tnVx15zX/banco-de-dados-ratro-DRE.png[/img][/url]
Daniel Fernandes
Curtir tópico
+ 0
Responder
Posts
27/12/2022
Arthur Heinrich
Eu não utilizaria uma modelagem como esta, em que os itens são colunas na tabela do produto. Se um dia precisar adicionar ou remover itens, isso implicaria alterar o modelo.
Para definir os produtos, talvez você precise de 3 tabelas:
Uma tabela para cadastrar os tipos de peças.
Uma tabela para cadastrar os tipos de produtos.
Uma tabela para elencar que tipos de peças compõe cada um dos tipos de produtos e sua quantidade.
Porém, um mesmo tipo de produto pode ser produzido em lotes, com ou sem números de série individuais. Então, você precisa cadastrar os produtos e, eventualmente as peças, produzidos individualmente, que podem conter um status do tipo (em estoque, vendido, devolvido, inultilizado, etc.).
Já a garantia, costuma ser associada à venda de um produto e conta a partir da nota fiscal emitida.
A etiqueta/lacre de garantia, como você mesmo explicou, podem ser substituídas. Portanto, você precisa criar uma tabela para associar todas as etiquetas de garantia associadas a cada produto vendido.
É possível que a garantia de um produto esteja para se encerrar em 30 dias, mas o produto sofre uma manutenção que substitui um de seus componentes (peças), que passa a ter uma garantia de 6 meses, por exemplo. O produto precisa então manter a sua garantia original, pelo prazo restante, bem como a garantia sobre a peça substituída. Mas vinculadas a outra etiqueta.
É um sistema complexo. Foge do escopo deste grupo.
Para definir os produtos, talvez você precise de 3 tabelas:
Uma tabela para cadastrar os tipos de peças.
Uma tabela para cadastrar os tipos de produtos.
Uma tabela para elencar que tipos de peças compõe cada um dos tipos de produtos e sua quantidade.
Porém, um mesmo tipo de produto pode ser produzido em lotes, com ou sem números de série individuais. Então, você precisa cadastrar os produtos e, eventualmente as peças, produzidos individualmente, que podem conter um status do tipo (em estoque, vendido, devolvido, inultilizado, etc.).
Já a garantia, costuma ser associada à venda de um produto e conta a partir da nota fiscal emitida.
A etiqueta/lacre de garantia, como você mesmo explicou, podem ser substituídas. Portanto, você precisa criar uma tabela para associar todas as etiquetas de garantia associadas a cada produto vendido.
É possível que a garantia de um produto esteja para se encerrar em 30 dias, mas o produto sofre uma manutenção que substitui um de seus componentes (peças), que passa a ter uma garantia de 6 meses, por exemplo. O produto precisa então manter a sua garantia original, pelo prazo restante, bem como a garantia sobre a peça substituída. Mas vinculadas a outra etiqueta.
É um sistema complexo. Foge do escopo deste grupo.
Responder
06/01/2023
Daniel Fernandes
Obrigado pela resposta, dando prosseguimento.
Questionei, o que foi levantado na resposta anterior e foi determinado, que software deve atingir o objetivo de rastreabilidade, isso é, permitir o acompanhamento da composição do produto durante sua vida util. (montagem, reparo pós-montagem, assistência técnica)
Isso, significa, que deverá ter a possibilidade de atualizar as etiquetas de garantia e informar o usuário que atualizou a informação.
As consultas serão públicas, com finalidade de informar as datas e dados que foram modificados.
Não existirá outro fluxo de informação a ser tratado e a complexidade será até esse nível.
A tabela de produtos, exemplo TVP400 ou TL320, será criada dinamicamente, quando supervisor criar novo modelo de produto. Neste momento, será definido os nomes das peças correspondente a cada modelo, na tabela composição, que será usada para preencher os labels ao visualizar o modelo de produto na tela.
Haverá uma tabela para números de serie e outra tabela para garantias, segue modelamento a ser utilizado.
https://i.postimg.cc/jdrbn0vM/modelo-BD-rastro.png
Questionei, o que foi levantado na resposta anterior e foi determinado, que software deve atingir o objetivo de rastreabilidade, isso é, permitir o acompanhamento da composição do produto durante sua vida util. (montagem, reparo pós-montagem, assistência técnica)
Isso, significa, que deverá ter a possibilidade de atualizar as etiquetas de garantia e informar o usuário que atualizou a informação.
As consultas serão públicas, com finalidade de informar as datas e dados que foram modificados.
Não existirá outro fluxo de informação a ser tratado e a complexidade será até esse nível.
A tabela de produtos, exemplo TVP400 ou TL320, será criada dinamicamente, quando supervisor criar novo modelo de produto. Neste momento, será definido os nomes das peças correspondente a cada modelo, na tabela composição, que será usada para preencher os labels ao visualizar o modelo de produto na tela.
Haverá uma tabela para números de serie e outra tabela para garantias, segue modelamento a ser utilizado.
https://i.postimg.cc/jdrbn0vM/modelo-BD-rastro.png
Responder
Clique aqui para fazer login e interagir na Comunidade :)
