Supertype / Subtype memutuskan antara kategori: disjoint lengkap atau tidak lengkap tumpang tindih

Saya sedang membangun database inventaris yang menyimpan perangkat keras TI, seperti komputer desktop, laptop, sakelar, router, ponsel, dll. Saya menggunakan pola supertipe / subtipe, di mana semua perangkat disimpan dalam satu tabel, dan informasi spesifik dimasukkan ke dalam tabel subtipe. Dilema saya adalah memilih antara dua desain berikut:

Di diagram atas, semua perangkat berbagi subtipe umum. Misalnya, komputer desktop dan laptop akan memiliki catatan dalam tabel berikut: Perangkat, NetworkDevice. Switch akan memiliki catatan di: Perangkat, NetworkDevice. Perute akan memiliki catatan di: Perangkat, NetworkDevice, WANDevice. Perangkat apa pun yang kami lacak lokasinya akan memiliki catatan di Lokasi. Beberapa pro dan kontra yang saya pikirkan untuk pengaturan ini:

• Pro: MEMILIH catatan berdasarkan bidang umum, seperti Hostname, atau LocationID lebih mudah.
• Pro: Tidak ada bidang nol.
• Con: Tabel yang harus dimasukkan dalam operasi CRUD untuk perangkat tertentu tidak jelas, dan dapat membingungkan DBA di masa depan.

Di diagram bawah, semua perangkat memiliki subtipe sendiri (Ada lebih banyak kelas perangkat yang tidak ditampilkan di sini). Dalam situasi ini, jelas catatan tabel mana yang dimasukkan atau dipilih. Komputer desktop dan laptop masuk dalam Komputer, dll. Beberapa pro dan kontra yang saya pikirkan untuk pengaturan ini:

• Pro: Jelas tabel mana yang akan digunakan untuk operasi CRUD untuk subtipe.
• Pro: Hanya perlu menggunakan satu tabel untuk operasi CRUD.
• Con: MEMILIH catatan berdasarkan bidang subtipe umum mengharuskan semua tabel digabungkan, misalnya mencari berdasarkan Nama Inang, atau LocationID.

Dalam kedua situasi, bidang ClassDiscriminator ditempatkan di tabel subtipe untuk digunakan dengan kendala PERIKSA untuk mengontrol tipe mana yang bisa dimasukkan.

Apakah ada rekomendasi untuk desain yang lebih baik, atau apakah itu sepenuhnya pendapat dan tergantung pada tujuan database?

EDIT: Sebuah pertanyaan spesifik yang saya miliki mengenai sifat tabel "NetworkDevice" yang tumpang tindih. Tabel ini dimaksudkan untuk menyimpan informasi jaringan untuk perangkat apa pun dengan nama host dan / atau alamat IP, apakah itu komputer, sakelar, atau router. Apakah sifat tabel ini tumpang tindih sesuatu yang dapat menyebabkan masalah, atau apakah saya boleh menerapkannya dengan cara ini?

Terima kasih sebelumnya atas segala masukan yang diberikan. Tanyakan apakah ada informasi tambahan yang diperlukan.

Implementasi fisik subtyping dalam database adalah masalah yang kompleks. Kecuali Anda memiliki situasi di mana ia menawarkan keuntungan yang menarik (lihat di bawah untuk satu atau dua contoh) itu menambah kompleksitas ke dalam implementasi sambil memberikan nilai yang relatif sedikit.

Setelah melakukan ini dengan subtyping yang sangat kompleks (penerapan dan hukuman pada sistem manajemen kasus pengadilan, struktur kontrak asuransi komersial risiko gabungan yang berbeda), saya kira saya memiliki beberapa pengamatan mengenai hal ini. Beberapa kasus sudut signifikan adalah:

• Jika jumlah total bidang basis data di seluruh subtipe relatif rendah (katakanlah: kurang dari 100) atau ada kesamaan yang signifikan antara subtipe, maka pisahkan subtipe ke dalam tabel fisik yang terpisah mungkin bernilai kecil. Ini akan menambah overhead yang signifikan ke kueri pelaporan dan pencarian. Dalam kebanyakan kasus, yang terbaik adalah memiliki satu tabel dan mengelola subtyping Anda dalam aplikasi. (Mungkin yang paling dekat dengan masalah Anda)

• Jika subtyping Anda sangat terputus-putus, dan subtipe yang berbeda memiliki tipe struktur data yang tergantung padanya (yaitu tabel anak atau struktur yang lebih kompleks), maka tabel subtipe masuk akal. Dalam kasus ini, setiap subtipe mungkin memiliki relatif sedikit kesamaan dalam aplikasi (yaitu mungkin ada seluruh subsistem dalam aplikasi yang didedikasikan untuk subtipe itu). Sebagian besar pelaporan dan kueri mungkin akan terjadi dalam sub-tipe yang diberikan, dengan kueri tipe silang sebagian besar terbatas pada beberapa bidang umum. (Sistem manajemen kasus pengadilan)

• Jika Anda memiliki sejumlah besar subtipe dengan atribut yang berbeda dan / atau persyaratan untuk membuat ini dapat dikonfigurasi maka struktur umum dan metadata tambahan mungkin lebih tepat. Lihat posting SO ini untuk ikhtisar tentang beberapa pendekatan yang mungkin. (Sistem administrasi polis asuransi)

• Jika Anda memiliki jumlah bidang yang sangat besar dengan sedikit kesamaan di seluruh sub-tipe Anda dan sedikit persyaratan untuk kueri di seluruh sub-tipe tabel (yaitu tidak ada banyak cara penggabungan luar multi-arah terhadap tabel sub-tipe Anda) maka sub- tabel type dapat membantu mengelola sprawl kolom. (Versi rumit dari masalah Anda secara patologis)

• Beberapa pemetaan O / R hanya dapat mendukung pendekatan tertentu untuk mengelola sub-kelas.

Dalam kebanyakan kasus tabel sub-tipe fisik dalam skema DB adalah sedikit solusi dalam mencari masalah, karena mereka berpotensi memiliki efek samping yang tidak diinginkan.

Dalam kasus Anda, saya menganggap Anda memiliki jumlah sub-jenis yang relatif sederhana dan sejumlah atribut yang dapat dikelola. Diagram dan pertanyaan Anda tidak menunjukkan niat apa pun untuk menggantung tabel anak dari catatan. Saya menyarankan agar Anda mempertimbangkan untuk pergi dengan opsi pertama yang disarankan di atas dan mempertahankan satu tabel dan mengelola sub-pengetikan dalam aplikasi Anda.

Pertimbangkan pertama kali mengembangkan model data logis suara menggunakan aturan hirarki klasifikasi pemodelan data yang ditemukan di Enterprise Model Patterns , sebuah buku karya David Hay. Saat membuat hierarki klasifikasi, setiap kemunculan (baris) harus dari satu dan hanya satu subtipe. Ini berarti sub-tipe ini saling eksklusif. Klasifikasi harus didasarkan pada karakteristik tunggal, fundamental, tidak berubah. Menggunakan aturan dasar ini akan memberikan banyak kejelasan untuk model Anda. Dalam model yang Anda miliki, karakteristik tunggal untuk dikelompokkan adalah tujuan perangkat - telepon, sakelar jaringan, komputer, router, dll. Setiap perangkat harus terdiri dari satu, dan hanya satu, dari jenis ini. Jadi misalnya lokasi tidak akan menjadi sub tipe. Atribut seperti alamat IP milik tipe super.

Saya pikir Anda akan menemukan bahwa jumlah jenis perangkat akan cukup besar untuk menjamin pola EAV seperti yang disebutkan dalam jawaban lain. Referensi buku David Hay mencakup pola ini dengan sangat efektif. Namun, jika jumlah sub-jenis sedikit, Anda dapat menggunakan aturan praktis untuk memutuskan untuk mengimplementasikan hanya tabel tipe super dengan banyak kolom yang dapat dibatalkan, hanya tabel jenis sub dengan kolom yang digandakan, atau keduanya. Jika setiap sub-tipe sangat bervariasi dalam atributnya dan tidak memiliki hubungan di tingkat tipe super, Anda mungkin hanya menggunakan tabel sub-tipe. Jika kebalikannya benar, Anda mungkin hanya menggunakan tabel tipe super. Jika ada campuran, maka implementasikan keduanya.

Catatan akhirnya Anda selalu dapat menerapkan pola EAV sebagai skema tabel dasar dan kemudian membuat lapisan tampilan abstraksi yang menyajikan data ke aplikasi sebagai tabel tipe super dan sub. Ini memberi Anda fleksibilitas pada lapisan penyimpanan tetapi kemampuan memahami pada lapisan tampilan aplikasi.

Suatu produk bukan persediaan. Persediaan dan produk berbeda.

Suatu produk benar-benar merupakan spesifikasi dari suatu produk, bukan hal fisik.

Hal fisik adalah Aset yang dimiliki perusahaan (atau toko). Anda dapat memiliki aset yang Anda lacak berdasarkan nomor seri (aset diskrit) atau aset yang Anda lacak hanya berdasarkan kuantitas (aset inventaris).

Saya akan melihat Buku Data Model Resource Silverston Vol 1. Dia memiliki skema yang baik untuk proudcts, fitur, harga, persediaan. Ini akan menghemat banyak waktu.

Salah satu pertanyaan yang akan saya tanyakan adalah mengapa Anda melacak berbagai atribut dari item inventaris Anda? - Atau, lebih spesifik, apa yang Anda lakukan dengan informasi atribut ini?

Jika Anda memiliki banyak laporan atau formulir yang memahami atribut tertentu secara spesifik, maka Anda perlu menggunakan pendekatan yang direkomendasikan oleh ConcernedOfTunbridgeWell. Jika di sisi lain, atribut-atribut ini dicatat demi mendaftarkannya, atau mungkin membandingkannya dengan atribut sejenis dari perangkat yang serupa, maka Anda mungkin sebenarnya memiliki alasan (jarang) yang bagus untuk menggunakan EAV. Saya tahu bahwa "EAV adalah kejahatan murni" karena banyak alasan, kecuali untuk kasus yang sangat langka ketika alasan itu tidak terjadi pada aplikasi tertentu. Milik Anda mungkin aplikasi semacam itu.

Lihat jawaban ini mengenai desain sistem inventaris perangkat dan jawaban ini tentang desain sistem katalog produk untuk melihat bagaimana pendekatan EAV dapat menyederhanakan aplikasi Anda bersama dengan diskusi tentang apa sebenarnya risiko EAV dan bagaimana menilai apakah risiko itu mungkin tidak berlaku untuk aplikasi spesifik Anda.