Database
 sql >> Database >  >> RDS >> Database

Identificazione della struttura della distinta base (BOM) nei database

Il modello di progettazione della distinta base (BOM) è ingannevolmente semplice, ma incredibilmente potente. Storicamente, è stato impiegato per modellare le strutture dei prodotti, ma il modello può essere utilizzato per fare molto di più che definire semplicemente una gerarchia. Questo articolo introdurrà tre esempi molto diversi per aiutarti a riconoscere lo schema nei tuoi progetti.

Che cos'è una distinta base o distinta base?

Una distinta materiali ha le sue radici nella produzione. È un elenco di materie prime, sottoassiemi, assiemi intermedi, sottocomponenti, parti e le quantità di ciascuno necessarie per fabbricare un prodotto finale. Puoi considerarlo come una scomposizione gerarchica di un prodotto. Altri termini per la stessa cosa sono struttura del prodotto, distinta base e elenco associato.

Per illustrare una distinta base, guarda il modello concettuale di seguito. Si inizia con il prodotto di primo livello, Car . In linea di massima, un Car ha un Engine e un Body . In questo esempio, ci sono diversi tipi di motori:V6 e V8. Esistono diversi tipi di carrozzerie:3 porte, 5 porte e station wagon (noto anche come station wagon o station wagon). Il processo di decomposizione può scendere fino all'ultimo dado e bullone – o anche una piccola quantità di colla – ma si ottiene il quadro.

Al livello più semplice, stai unendo due parti insieme sotto forma di una gerarchia – una parte madre a una parte figlia – dalla cima della gerarchia fino al fondo. Il modello base della distinta base di produzione ha il seguente aspetto:




Questa è la struttura classica della distinta base , dove una singola tabella [genitore] ha due relazioni con una tabella di giunzione [figlio].

Ecco la semplice gerarchia di prodotti dall'esempio Car:

Genitore Bambino Quantità
Auto Corpo 1
Auto Motore 1
Motore V6 1
Motore V8 1


Le distinte base nella produzione tendono ad avere lo stesso tipo di proprietà principali:

  • Gli assiemi, i sottoassiemi e i singoli componenti possono essere riutilizzati . Ad esempio, lo stesso tipo di bullone può essere utilizzato in diversi tipi di assemblaggio.
  • Spesso deve esserci una quantità specifica della gerarchia . Ad esempio, è importante sapere che un assieme necessita di 10 bulloni, ma un altro assieme potrebbe aver bisogno di 15 bulloni della stessa specifica.

Una volta definito un assieme, la sua struttura viene automaticamente importata in tutti gli altri assiemi che ne fanno uso. Quindi, se l'assieme dovesse cambiare, tutte le altre distinte materiali che lo utilizzano verranno automaticamente aggiornate. Le distinte base che descrivono i sottoassiemi in questo modo sono denominate DBA modulari .

Per i produttori, una distinta base è un'informazione fondamentale sul prodotto, un record che elenca tutto ciò che è necessario per fabbricare un prodotto. Sono necessarie tecniche di modellazione avanzate per gestire configurabile prodotti, componenti varianti o sostituisce componenti. La modifica di una piccola parte di un prodotto può avere molteplici impatti sulle distinte materiali di altri prodotti. Senza tenerne conto, la gestione delle distinte base può diventare alquanto ingestibile.

Ma questa area specialistica va oltre lo scopo di questo articolo. Invece, ci concentreremo su esempi di dove potrebbero verificarsi strutture BOM nella progettazione di database. Una volta che sarai in grado di riconoscere una distinta base, sarai in grado di utilizzare questo potente modello di progettazione.

Inizieremo con un esempio comune:la relazione molti-a-molti tra voli e aeroporti.

Cosa c'entra il modello della distinta base con i voli?

Ecco il modello concettuale:

Immaginati in qualsiasi aeroporto del mondo. Da lì, potrai vedere gli aerei che decollano per altre destinazioni. Vedrai anche gli aerei che atterrano da altre destinazioni. Quindi esiste una relazione molti-a-molti tra gli aeroporti di partenza e di arrivo.

In genere, risolviamo questa relazione molti-a-molti utilizzando una tabella di giunzione:




Il Flight la classe avrà i suoi attributi, incluso flightNumber , scheduledDepartureTime e scheduledArrivalTime .

Guardando indietro al nostro modello, potremmo individuare un problema minore. Sappiamo che non esiste un DepartureAirport o un ArrivalAirport . Sono entrambi solo aeroporti da cui partono i voli e verso cui arrivano i voli.

Quindi uniamo DepartureAirport e ArrivalAirport in un unico airport tabella come questa:




Anche questo segue la struttura classica della distinta base , dove una singola tabella [genitore] ha due relazioni con una tabella di giunzione [figlio].

Concettualmente, però, c'è una grande differenza tra questo e una distinta base di produzione. Questa distinta base non ha una vera struttura gerarchica. È completamente piatto. Perché dico questo?

È meglio descritto a titolo di esempio.

Per prima cosa, consideriamo alcuni dati di esempio per questa distinta base:

Partenza Destinazione
Manchester Parigi
Manchester Dubai
Dubai Chennai
Dubai Città del Capo


Ora lavoreremo attraverso un esempio. Immagina di dover volare da Manchester a Chennai. Non ci sono voli diretti. Ma puoi volare da Manchester a Dubai, la prima tappa del tuo viaggio. Puoi quindi prendere un altro volo da Dubai a Chennai, la seconda tappa del tuo viaggio. Mentre le due tappe formano il tuo itinerario, la seconda tappa non è in alcun modo una sorta di sottocomponente della prima tappa! Pertanto, questa struttura è piatta.

Ma nota la corrispondenza dei dati 1:1 tra le parti ed esempi di voli:Auto → Manchester; Motore → Dubai; Chennai → V6.

Nell'esempio dell'auto, le parti formano una gerarchia strettamente accoppiata . Nell'esempio dell'aeroporto, i voli possono essere attraversati per formare più collegamenti ad accoppiamento libero tra i voli. Per un passeggero che vola da Manchester a Chennai, è necessario creare un itinerario. Questo è il risultato di una query, che tiene conto di ciò che costituisce una connessione, ad es. il tempo minimo e massimo tra i voli; se deve essere utilizzata la stessa compagnia aerea o se sono consentite compagnie aeree diverse.

Successivamente, diamo un'occhiata a come utilizzare la distinta base per descrivere le relazioni nella modellazione dei dati.

Relazioni nella struttura della distinta base

Con questo intendo le relazioni tra le persone, tra le organizzazioni e tra le organizzazioni e le persone. Si tratta di relazioni del mondo reale, come un dipendente di un'azienda o un membro di un team o un'azienda che possiede un'altra azienda. Il modello concettuale si presenta così:

Se dovessi mapparlo direttamente su un modello fisico, avresti tabelle di giunzione per ciascuna delle relazioni molti-a-molti. Questo può diventare un po' disordinato e non aiuta con l'esecuzione di query, ad esempio trovare tutte le relazioni a Person ha.

Quindi è probabilmente meglio riconoscere quella Person e Organization sono diversi tipi di Party . Questo ci permette di semplificare le tre relazioni molti-a-molti in una sola:

Se le tue esigenze sono semplici, questo potrebbe essere sufficiente. Ma nel mondo reale, le cose non tendono ad essere così semplici. Ad esempio, un dipendente può lasciare un'azienda per viaggiare per il mondo per un certo periodo. Al ritorno dai suoi viaggi, cerca lavoro e viene riassunto dall'azienda che aveva lasciato. (Succede!) Il dipendente, quindi, ha due casi separati di relazione con questo datore di lavoro, ciascuno con date di entrata in vigore diverse e possibilmente con un ID dipendente diverso.

Quindi la relazione stessa richiede attributi. Ciò significa un'altra entità, Relationship , è necessario contenerli:




Anche questo segue la struttura classica della distinta base , dove una singola tabella [genitore] ha due relazioni con una tabella di giunzione [figlio].

Per convenzione, in questo modello il 1 l'interlocutore tende ad essere il Party nel Relationship come il datore di lavoro piuttosto che il dipendente, o il team leader piuttosto che il membro del team.

Questo modello di distinta base del rapporto tra le parti può essere utilizzato per elencare tutti i dipendenti (2 interactor ) in un'organizzazione (1 interactor ) al contrattuale livello se vuoi. Questa è una gerarchia piatta, a livello singolo. Può anche essere usato simultaneamente per definire l'intera struttura dei rapporti di gestione (o gerarchia) presso la stessa organizzazione, che può avere un numero qualsiasi di livelli. Ad esempio:un dipendente può lavorare con un unico contratto per un certo numero di anni, ma può trovarsi a lavorare per diversi manager in quel periodo (1 interlocutore =responsabile; 2 interlocutore =risponde a). Potrebbe anche lavorare contemporaneamente per più di un manager.

Ecco come potrebbero apparire i dati (con i rispettivi ruoli tra parentesi):

1 interagente 2 interlocutori
Widget Co. Inc. (datore di lavoro) Direttore 1 (dipendente)
Widget Co. Inc. (datore di lavoro) Direttore 2 (dipendente)
Widget Co. Inc. (datore di lavoro) Dipendente 1 (dipendente)
Widget Co. Inc. (datore di lavoro) Dipendente 2 (dipendente)
Widget Co. Inc. (datore di lavoro) Dipendente 3 (dipendente)
Widget Co. Inc. (datore di lavoro) Dipendente 4 (dipendente)
Manager 1 (responsabile di) Dipendente 1 (riferisce a)
Manager 1 (responsabile di) Dipendente 2 (riferisce a)
Manager 2 (responsabile di) Dipendente 3 (riferisce a)
Manager 2 (responsabile di) Dipendente 4 (riferisce a)

Scopri la distinta base

Mentre la distinta base struttura ha le sue radici nella produzione, può essere utilizzato per scopi diversi , che può variare da qualcosa di strettamente gerarchico e strettamente accoppiato a qualcosa di abbastanza piatto e di accoppiamento più lasco.

La mia speranza è che questi esempi ti aiutino a riconoscere il modello BOM se esiste nei tuoi progetti. Una volta riconosciuto il modello, capirai come dovrebbe essere implementato. Non devi reinventare la ruota ogni volta, devi solo adattarla alle tue esigenze specifiche.