Pola desain bill of material (BOM) tampak sederhana, namun sangat kuat. Secara historis, ini telah digunakan untuk memodelkan struktur produk, tetapi polanya dapat digunakan untuk melakukan lebih dari sekadar mendefinisikan hierarki. Artikel ini akan memperkenalkan tiga contoh yang sangat berbeda untuk membantu Anda mengenali pola dalam proyek Anda sendiri.
Apa itu Bill of Materials, atau BOM?
tagihan bahan berakar pada manufaktur. Ini adalah daftar bahan mentah, sub-rakitan, rakitan antara, sub-komponen, suku cadang, dan jumlah masing-masing yang dibutuhkan untuk memproduksi produk akhir. Anda dapat melihatnya sebagai dekomposisi hierarkis suatu produk. Istilah lain untuk hal yang sama adalah struktur produk, bill of material, dan daftar terkait.
Untuk mengilustrasikan BOM, lihat model konseptual di bawah ini. Dimulai dengan produk tingkat atas, Car . Secara garis besar, sebuah Car memiliki Engine dan Body . Dalam contoh ini, ada berbagai jenis mesin:V6 dan V8. Ada berbagai jenis badan:3 pintu, 5 pintu, dan estate (juga dikenal sebagai wagon atau station wagon). Proses penguraian bisa sampai ke mur dan baut terakhir – atau bahkan setetes lem – tetapi Anda mendapatkan gambarannya.
Pada tingkat yang paling sederhana, Anda menggabungkan dua bagian bersama dalam bentuk hierarki – bagian induk ke bagian anak – dari atas hierarki sampai ke bawah. Model BOM manufaktur paling dasar terlihat seperti ini:
Ini adalah struktur BOM klasik , di mana satu tabel [parent] memiliki dua hubungan dengan tabel persimpangan [child].
Berikut hierarki produk sederhana dari contoh Mobil:
| Induk | Anak | Kuantitas |
|---|---|---|
| Mobil | Tubuh | 1 |
| Mobil | Mesin | 1 |
| Mesin | V6 | 1 |
| Mesin | V8 | 1 |
BOM di bidang manufaktur cenderung memiliki sifat utama yang sama:
- Perakitan, sub-rakitan, dan komponen individu dapat digunakan kembali . Misalnya, jenis baut yang sama dapat digunakan dalam berbagai jenis perakitan.
- Seringkali dibutuhkan jumlah khusus hierarki . Misalnya, penting untuk mengetahui bahwa satu rakitan membutuhkan 10 baut, tetapi rakitan lain mungkin memerlukan 15 baut dengan spesifikasi yang sama.
Setelah Anda menentukan rakitan, strukturnya secara otomatis diimpor ke rakitan lain yang memanfaatkannya. Jadi jika perakitan itu akan diubah, maka semua BOM lain yang menggunakannya akan diperbarui secara otomatis. BOM yang menggambarkan sub-rakitan seperti ini disebut sebagai BOM modular .
Bagi produsen, BOM adalah bagian penting dari informasi produk, catatan yang mencantumkan semua yang diperlukan untuk memproduksi suatu produk. Teknik pemodelan tingkat lanjut diperlukan untuk menangani dapat dikonfigurasi produk, komponen variasi , atau pengganti komponen. Mengubah sebagian kecil dari suatu produk dapat memiliki banyak dampak pada BOM produk lainnya. Tanpa mempertimbangkan hal ini, manajemen BOM dapat menjadi sangat tidak terkendali.
Tetapi bidang spesialis ini berada di luar cakupan artikel ini. Sebagai gantinya, kami akan fokus pada contoh di mana struktur BOM mungkin terjadi dalam desain database. Setelah Anda dapat mengenali BOM, Anda akan dapat menggunakan pola desain yang hebat ini.
Kita akan mulai dengan contoh umum:hubungan banyak ke banyak antara penerbangan dan bandara.
Apa Hubungan Pola Bill of Materials dengan Penerbangan?
Berikut model konseptualnya:
Bayangkan diri Anda di bandara mana pun di dunia. Dari sana, Anda akan dapat melihat pesawat lepas landas untuk tujuan lain. Anda juga akan melihat pesawat mendarat dari tujuan lain. Jadi ada hubungan banyak ke banyak antara bandara keberangkatan dan kedatangan.
Biasanya, kami menyelesaikan hubungan banyak-ke-banyak ini menggunakan tabel persimpangan:
Flight class akan memiliki atributnya sendiri, termasuk flightNumber , scheduledDepartureTime , dan scheduledArrivalTime .
Melihat kembali model kami, kami mungkin menemukan masalah kecil. Kami tahu bahwa tidak ada yang namanya DepartureAirport atau ArrivalAirport . Keduanya hanyalah bandara dari mana penerbangan berangkat dan ke mana penerbangan tiba.
Jadi kami menggabungkan DepartureAirport dan ArrivalAirport menjadi satu airport tabel seperti ini:
Sekali lagi ini mengikuti struktur BOM klasik , di mana satu tabel [parent] memiliki dua hubungan dengan tabel persimpangan [child].
Secara konseptual, ada perbedaan besar antara ini dan BOM manufaktur. BOM ini tidak memiliki struktur hierarki yang benar. Ini benar-benar datar. Mengapa saya mengatakan ini?
Ini paling baik dijelaskan sebagai contoh.
Pertama, mari kita pertimbangkan beberapa contoh data untuk BOM ini:
| Keberangkatan | Tujuan |
|---|---|
| Manchester | Paris |
| Manchester | Dubai |
| Dubai | Chennai |
| Dubai | Kota Tanjung |
Sekarang kita akan bekerja melalui sebuah contoh. Bayangkan Anda perlu terbang dari Manchester ke Chennai. Tidak ada penerbangan langsung. Tapi Anda bisa terbang dari Manchester ke Dubai, leg pertama perjalanan Anda. Anda kemudian dapat mengambil penerbangan lain dari Dubai ke Chennai, bagian kedua dari perjalanan Anda. Sementara dua kaki membentuk rencana perjalanan Anda, sama sekali bukan kaki kedua semacam sub-komponen dari kaki pertama! Oleh karena itu, struktur ini datar.
Namun perhatikan korespondensi data 1:1 antara bagian dan contoh penerbangan:Mobil → Manchester; Mesin → Dubai; Chennai → V6.
Dalam contoh mobil, bagian-bagiannya membentuk hierarki yang sangat erat . Dalam contoh bandara, penerbangan dapat dilalui untuk membentuk lebih banyak koneksi yang digabungkan secara longgar antar penerbangan. Untuk penumpang yang terbang dari Manchester ke Chennai, rencana perjalanan perlu dibuat. Ini adalah hasil kueri, yang memperhitungkan apa yang dimaksud dengan koneksi – mis. waktu minimum dan maksimum antar penerbangan; apakah maskapai yang sama harus digunakan atau jika maskapai yang berbeda diizinkan.
Selanjutnya, mari kita lihat bagaimana BOM dapat digunakan untuk menggambarkan hubungan dalam pemodelan data.
Hubungan dalam Struktur BOM
Yang saya maksud adalah hubungan antara orang-orang, antara organisasi, dan antara organisasi dan orang-orang. Ini adalah hubungan dunia nyata, seperti seseorang yang menjadi karyawan perusahaan atau anggota tim, atau perusahaan yang memiliki perusahaan lain. Model konseptual terlihat seperti ini:
Jika Anda memetakan ini langsung ke model fisik, Anda akan memiliki tabel persimpangan untuk setiap hubungan banyak ke banyak. Ini bisa menjadi sedikit berantakan, dan tidak membantu menjalankan kueri – misalnya, menemukan semua hubungan sebagai Person memiliki.
Jadi, mungkin lebih baik untuk mengenali Person dan Organization adalah berbagai jenis Party . Hal ini memungkinkan kita untuk menyederhanakan tiga hubungan banyak ke banyak menjadi satu:
Jika kebutuhan Anda sederhana, ini mungkin cukup. Tetapi di dunia nyata, hal-hal tidak cenderung sesederhana itu. Misalnya, seorang karyawan dapat meninggalkan perusahaan untuk pergi berkeliling dunia untuk sementara waktu. Ketika dia kembali dari perjalanannya, dia mencari pekerjaan dan dipekerjakan kembali oleh perusahaan yang dia tinggalkan. (Itu terjadi!) Oleh karena itu, karyawan memiliki dua contoh hubungan terpisah dengan pemberi kerja ini, masing-masing dengan tanggal efektif yang berbeda, dan mungkin dengan ID karyawan yang berbeda.
Jadi hubungan itu sendiri membutuhkan atribut. Ini berarti entitas lain, Relationship , wajib memuatnya:
Sekali lagi ini mengikuti struktur BOM klasik , di mana satu tabel [parent] memiliki dua hubungan dengan tabel persimpangan [child].
Dengan konvensi, dalam model ini 1 interaksi cenderung menjadi Party di Relationship seperti majikan daripada karyawan, atau pemimpin tim daripada anggota tim.
Pola BOM hubungan partai ini dapat digunakan untuk membuat daftar semua karyawan (2 interactor ) dalam sebuah organisasi (1 interactor ) di kontrak tingkat jika Anda mau. Ini adalah hierarki tingkat tunggal yang datar. Itu juga dapat digunakan secara bersamaan untuk menentukan seluruh struktur pelaporan manajemen (atau hierarki) pada organisasi yang sama, yang dapat memiliki sejumlah tingkatan. Misalnya:seorang karyawan dapat bekerja di bawah satu kontrak selama beberapa tahun tetapi mungkin mendapati dirinya bekerja untuk manajer yang berbeda selama periode itu (1 interaksi =bertanggung jawab untuk; 2 interaksi =melapor ke). Dia bahkan mungkin bekerja secara bersamaan untuk lebih dari satu manajer.
Berikut adalah tampilan data (dengan perannya masing-masing dalam tanda kurung):
| 1 interaksi | 2 interaksi |
|---|---|
| Widget Co. Inc. (majikan) | Manajer 1 (karyawan) |
| Widget Co. Inc. (majikan) | Manajer 2 (karyawan) |
| Widget Co. Inc. (majikan) | Karyawan 1 (karyawan) |
| Widget Co. Inc. (majikan) | Karyawan 2 (karyawan) |
| Widget Co. Inc. (majikan) | Karyawan 3 (karyawan) |
| Widget Co. Inc. (majikan) | Karyawan 4 (karyawan) |
| Manajer 1 (bertanggung jawab atas) | Karyawan 1 (melapor ke) |
| Manajer 1 (bertanggung jawab atas) | Karyawan 2 (melaporkan ke) |
| Manajer 2 (bertanggung jawab) | Karyawan 3 (melapor ke) |
| Manajer 2 (bertanggung jawab) | Karyawan 4 (melapor ke) |
Mengenal BOM
Sementara tagihan bahan struktur berakar pada manufaktur, dapat digunakan untuk tujuan yang berbeda , yang dapat berkisar dari sesuatu yang sangat hierarkis dan terkait erat hingga sesuatu yang cukup datar dan lebih longgar.
Harapan saya adalah contoh-contoh ini akan membantu Anda mengenali pola BOM jika ada di proyek Anda. Setelah Anda mengenali polanya, Anda akan memahami bagaimana pola itu harus diterapkan. Anda tidak perlu menemukan kembali roda setiap saat – Anda hanya perlu menyesuaikannya dengan kebutuhan spesifik Anda.
