O padrão de projeto da lista de materiais (BOM) é enganosamente simples, mas incrivelmente poderoso. Historicamente, tem sido empregado para modelar estruturas de produtos, mas o padrão pode ser usado para fazer muito mais do que simplesmente definir uma hierarquia. Este artigo apresentará três exemplos muito diferentes para ajudá-lo a reconhecer o padrão em seus próprios projetos.
O que é uma lista de materiais ou BOM?
Uma lista de materiais tem suas raízes na fabricação. É uma lista das matérias-primas, subconjuntos, conjuntos intermediários, subcomponentes, peças e as quantidades de cada um necessário para fabricar um produto final. Você pode vê-lo como uma decomposição hierárquica de um produto. Outros termos para a mesma coisa são estrutura do produto, lista de materiais e lista associada.
Para ilustrar uma lista técnica, observe o modelo conceitual abaixo. Começa com o produto de nível superior,
Car . De um modo geral, um Car tem um Engine e um Body . Neste exemplo, existem diferentes tipos de motores:V6 e V8. Existem diferentes tipos de carroçarias:3 portas, 5 portas e carrinha (também conhecida como carrinha ou carrinha). O processo de decomposição pode ir até a última porca e parafuso – ou até mesmo um pouco de cola – mas você entendeu. 
No nível mais simples, você está juntando duas partes na forma de uma hierarquia – uma parte pai a uma parte filha – do topo da hierarquia até a parte inferior. O modelo de BOM de fabricação mais básico se parece com isso:
Esta é a estrutura clássica da BOM , em que uma única tabela [pai] tem dois relacionamentos com uma tabela de junção [filho].
Aqui está a hierarquia de produtos simples do exemplo Car:
| Pai | Filho | Quantidade |
|---|---|---|
| Carro | Corpo | 1 |
| Carro | Motor | 1 |
| Motor | V6 | 1 |
| Motor | V8 | 1 |
BOMs na fabricação tendem a ter o mesmo tipo de propriedades principais:
- Montagens, submontagens e componentes individuais podem ser reutilizados . Por exemplo, o mesmo tipo de parafuso pode ser usado em diferentes tipos de montagem.
- Muitas vezes, é preciso haver uma quantidade específica da hierarquia . Por exemplo, é importante saber que um conjunto precisa de 10 parafusos, mas outro conjunto pode precisar de 15 parafusos da mesma especificação.
Depois de definir uma montagem, sua estrutura é automaticamente importada para quaisquer outras montagens que a utilizem. Portanto, se essa montagem for alterada, todas as outras BOMs que a usarem serão atualizadas automaticamente. As BOMs que descrevem submontagens como esta são chamadas de BOMs modulares .
Para os fabricantes, uma BOM é uma informação crítica do produto, um registro que lista tudo o que é necessário para fabricar um produto. Técnicas de modelagem avançadas são necessárias para lidar com configuráveis produtos, componentes variações , ou substituir componentes. Alterar uma pequena parte de um produto pode ter vários impactos em outros BOMs de produtos. Sem levar isso em consideração, o gerenciamento de BOM pode se tornar bastante incontrolável.
Mas essa área de especialização está além do escopo deste artigo. Em vez disso, vamos nos concentrar em exemplos de onde as estruturas BOM podem ocorrer no design do banco de dados. Depois de reconhecer uma BOM, você poderá usar esse poderoso padrão de design.
Começaremos com um exemplo comum:a relação muitos-para-muitos entre voos e aeroportos.
O que o padrão da lista de materiais tem a ver com voos?
Aqui está o modelo conceitual:
Imagine-se em qualquer aeroporto do mundo. De lá, você poderá ver aviões decolando para outros destinos. Você também verá aviões pousando de outros destinos. Portanto, há uma relação de muitos para muitos entre os aeroportos de partida e chegada.
Normalmente, resolvemos esse relacionamento muitos para muitos usando uma tabela de junção:
O Flight classe terá seus próprios atributos, incluindo flightNumber , scheduledDepartureTime e scheduledArrivalTime .
Olhando para o nosso modelo, podemos identificar um pequeno problema. Sabemos que não existe um DepartureAirport ou um ArrivalAirport . Ambos são apenas aeroportos de onde os voos partem e para os quais os voos chegam.
Então, nós fundimos DepartureAirport e ArrivalAirport em um único airport mesa assim:
Novamente, isso segue a estrutura clássica da BOM , em que uma única tabela [pai] tem dois relacionamentos com uma tabela de junção [filho].
Conceitualmente, porém, há uma grande diferença entre isso e uma lista técnica de fabricação. Este BOM não tem estrutura hierárquica verdadeira. É completamente plano. Por que eu digo isso?
É melhor descrito por meio de um exemplo.
Primeiro, vamos considerar alguns dados de exemplo para este BOM:
| Partida | Destino |
|---|---|
| Manchester | Paris |
| Manchester | Dubai |
| Dubai | Chennai |
| Dubai | Cidade do Cabo |
Agora vamos trabalhar com um exemplo. Imagine que você precisa voar de Manchester para Chennai. Não há voos diretos. Mas você pode voar de Manchester para Dubai, a primeira etapa de sua viagem. Você pode então pegar outro voo de Dubai para Chennai, a segunda etapa de sua viagem. Enquanto as duas etapas formam o seu itinerário, de forma alguma a segunda etapa é uma espécie de subcomponente da primeira etapa! Portanto, esta estrutura é plana.
Mas observe a correspondência de dados 1:1 entre os exemplos de peças e voos:Carro → Manchester; Motor → Dubai; Chennai → V6.
No exemplo do carro, as peças formam uma hierarquia fortemente acoplada . No exemplo do aeroporto, os voos podem ser percorridos para formar mais conexões fracamente acopladas entre voos. Para um passageiro voando de Manchester para Chennai, é necessário criar um itinerário. Este é o resultado de uma consulta, que leva em consideração o que constitui uma conexão – por exemplo, o tempo mínimo e máximo entre voos; se a mesma companhia aérea deve ser usada ou se diferentes companhias aéreas são permitidas.
Em seguida, vamos ver como a BOM pode ser usada para descrever relacionamentos na modelagem de dados.
Relacionamentos na estrutura de BOM
Com isso quero dizer relacionamentos entre pessoas, entre organizações e entre organizações e pessoas. São relacionamentos do mundo real, como alguém ser funcionário de uma empresa ou membro de uma equipe, ou de uma empresa ser proprietária de outra empresa. O modelo conceitual fica assim:
Se você mapeasse isso diretamente para um modelo físico, teria tabelas de junção para cada um dos relacionamentos muitos-para-muitos. Isso pode ficar um pouco confuso e não ajuda na execução de consultas – por exemplo, encontrar todos os relacionamentos como Person tem.
Portanto, provavelmente é melhor reconhecer essa Person e Organization são diferentes tipos de Party . Isso nos permite simplificar os três relacionamentos muitos-para-muitos em um único:
Se seus requisitos são simples, isso pode ser suficiente. Mas no mundo real, as coisas não tendem a ser tão simples. Por exemplo, um funcionário pode deixar uma empresa para viajar pelo mundo por um tempo. Quando volta de suas viagens, procura trabalho e é recontratado pela empresa de onde saiu. (Acontece!) O funcionário, portanto, tem duas instâncias separadas de um relacionamento com esse empregador, cada uma com datas efetivas diferentes e possivelmente com um ID de funcionário diferente.
Portanto, o próprio relacionamento requer atributos. Isso significa outra entidade, Relationship , é necessário para contê-los:
Novamente, isso segue a estrutura clássica da BOM , em que uma única tabela [pai] tem dois relacionamentos com uma tabela de junção [filho].
Por convenção, neste modelo o 1 o interator tende a ser o Party no Relationship como o empregador em vez do empregado, ou o líder da equipe em vez do membro da equipe.
Este padrão de BOM de relacionamento entre partes pode ser usado para listar todos os funcionários (2 interactor ) em uma organização (1 interactor ) no contratual nível se você quiser. Esta é uma hierarquia plana de nível único. Também pode ser usado simultaneamente para definir toda a estrutura de relatórios gerenciais (ou hierarquia) na mesma organização, que pode ter qualquer número de níveis. Por exemplo:um funcionário pode trabalhar sob um contrato por vários anos, mas pode encontrar-se trabalhando para diferentes gerentes durante esse período (1 interator =responsável por; 2 interator =subordinado). Ele pode até trabalhar simultaneamente para mais de um gerente.
Aqui está a aparência dos dados (com suas respectivas funções entre parênteses):
| 1 interator | 2 interator |
|---|---|
| Widget Co. Inc. (empregador) | Gerente 1 (funcionário) |
| Widget Co. Inc. (empregador) | Gerente 2 (funcionário) |
| Widget Co. Inc. (empregador) | Funcionário 1 (funcionário) |
| Widget Co. Inc. (empregador) | Funcionário 2 (funcionário) |
| Widget Co. Inc. (empregador) | Funcionário 3 (funcionário) |
| Widget Co. Inc. (empregador) | Funcionário 4 (funcionário) |
| Gerente 1 (responsável por) | Funcionário 1 (subordinado a) |
| Gerente 1 (responsável por) | Funcionário 2 (subordinado a) |
| Gerente 2 (responsável por) | Funcionário 3 (subordinado a) |
| Gerente 2 (responsável por) | Funcionário 4 (subordinado a) |
Conheça o BOM
Enquanto a lista de materiais estrutura tem suas raízes na fabricação, pode ser usado para diferentes propósitos , que pode variar de algo estritamente hierárquico e fortemente acoplado a algo bastante plano e mais fracamente acoplado.
Minha esperança é que esses exemplos o ajudem a reconhecer o padrão BOM se ele existir em seus projetos. Depois de reconhecer o padrão, você entenderá como ele deve ser implementado. Você não precisa reinventar a roda toda vez – você só precisa adaptá-la às suas necessidades específicas.
