Pertama, antarmuka pengguna: sebagai pengguna yang saya benci untuk mencari produk dalam katalog yang diatur dalam secara hierarkis jalan. Saya tidak pernah ingat di sub-sub-sub-sub...-kategori apa produk "eksotis" berada dan ini memaksa saya untuk membuang waktu menjelajahi kategori "menjanjikan" hanya untuk menemukan itu dikategorikan dalam (untuk saya, setidaknya ) cara yang aneh.
Apa Kevin Peno menyarankan adalah saran yang bagus dan dikenal sebagai penjelajahan segi . Sebagai Marcia Bates tulis di Setelah Bom Titik :Mendapatkan Pengambilan Informasi Web Saat Ini , " .. klasifikasi segi adalah untuk klasifikasi hierarkis karena basis data relasional adalah untuk basis data hierarkis. .. ".
Intinya, pencarian segi memungkinkan pengguna untuk mencari katalog Anda mulai dari "segi" apa pun yang mereka sukai dan membiarkan mereka memfilter informasi memilih segi lain di sepanjang pencarian. Perhatikan bahwa, bertentangan dengan bagaimana sistem tag biasanya disusun, tidak ada yang mencegah Anda untuk mengatur beberapa aspek ini secara hierarkis.
Untuk memahami dengan cepat apa itu penelusuran segi, ada beberapa demo untuk dijelajahi di Proyek Antarmuka Penelusuran Flamenco - Antarmuka Penelusuran yang Mengalir .
Kedua, logika aplikasi: apa Manitra
mengusulkan juga merupakan saran yang baik (seperti yang saya pahami), yaitu memisahkan nodes dan links pohon/grafik dalam relasi yang berbeda. Apa yang dia sebut "tabel leluhur" (yang merupakan nama intuitif yang jauh lebih baik, bagaimanapun) dikenal sebagai penutupan transitif dari grafik asiklik terarah (DAG)
(hubungan keterjangkauan). Di luar kinerja, ini sangat menyederhanakan kueri, seperti yang dikatakan Manitra.
Tapi Saya menyarankan tampilan untuk "tabel leluhur" seperti itu (penutupan transitif), sehingga pembaruan dilakukan secara real-time dan inkremental, bukan berkala oleh pekerjaan batch. Ada kode SQL (tapi saya pikir itu perlu sedikit disesuaikan dengan DBMS tertentu) di makalah yang saya sebutkan dalam jawaban saya untuk bahasa kueri untuk kumpulan grafik:pertanyaan pemodelan data . Secara khusus, lihat Mempertahankan Penutupan Grafik Transitif dalam SQL (.ps - postscript).
Hubungan Produk-Kategori
Poin pertama Manitra juga perlu ditekankan.
Apa yang dia katakan adalah bahwa antara produk dan kategori ada hubungan banyak-ke-banyak. Yaitu:setiap produk dapat berada dalam satu atau lebih kategori dan dalam setiap kategori dapat ada nol atau lebih produk.
Variabel relasi yang diberikan (relvars) Produk dan Kategori hubungan tersebut dapat direpresentasikan, misalnya, sebagai PC relvar dengan setidaknya atribut P# dan C#, yaitu nomor produk dan kategori (pengidentifikasi) dalam hubungan kunci asing dengan Produk dan Kategori yang sesuai angka.
Ini melengkapi manajemen hierarki kategori. Tentu saja, ini hanya sketsa desain.
Pada penjelajahan segi dalam SQL
Konsep yang berguna untuk menerapkan "penjelajahan segi" adalah divisi relasional , atau, bahkan, perbandingan relasional (lihat bagian bawah halaman tertaut). Yaitu. membagi PC (Products-Categories) dengan daftar kategori (bertambah) yang dipilih dari pengguna (navigasi faset) seseorang hanya memperoleh produk dalam kategori tersebut (tentu saja, kategori dianggap tidak semua saling eksklusif, jika tidak memilih dua kategori satu akan mendapatkan produk nol).
DBMS berbasis SQL biasanya kekurangan operator ini (pembagian dan perbandingan), jadi di bawah ini saya berikan beberapa makalah menarik yang mengimplementasikan/mendiskusikannya:
- MEMBUAT DIVISI RELASIONAL YANG DAPAT DIPERHATIKAN (.pdf dari Indeks Sesi FIE 2003 );
- Pendekatan SQL yang lebih sederhana (dan lebih baik) untuk pembagian relasional (.pdf dari Jurnal Pendidikan Sistem Informasi - Isi Volume 13, Nomor 2 (2002) );
- Memproses kueri penemuan kumpulan item yang sering menurut divisi dan penyetelan penahanan bergabung dengan operator ;
- Hukum untuk Menulis Ulang Kueri yang Mengandung Operator Divisi ;
- Algoritma dan Aplikasi untuk Kuantifikasi Universal dalam Basis Data Relasional;
- Mengoptimalkan Kueri dengan Kuantifikasi Universal dalam Berorientasi Objek dan Database Relasional Objek ;
- (Diperlukan akses ACM) Tentang kompleksitas pembagian dan himpunan yang bergabung dalam relasional aljabar ;
- (Diperlukan akses ACM) Algoritme cepat untuk kuantifikasi universal dalam database besar;
dan seterusnya...
Saya tidak akan membahas detailnya di sini, tetapi interaksi antara hierarki kategori dan penjelajahan segi membutuhkan perhatian khusus.
Penyimpangan pada "kerataan"
Saya melihat sekilas artikel yang ditautkan oleh Pras , Mengelola Data Hirarki di MySQL , tapi saya berhenti membaca setelah beberapa baris dalam pendahuluan ini:
Untuk memahami mengapa desakan pada kerataan hubungan ini hanya omong kosong , bayangkan sebuah kubus dalam sistem koordinat Kartesius tiga dimensi :akan diidentifikasi dengan 8 koordinat (kembar tiga), misalkan P1(x1,y1,z1), P2(x2,y2,z2), ..., P8(x8, y8, z8) [disini kita tidak mempermasalahkan kendala pada koordinat ini sehingga benar-benar mewakili kubus].
Sekarang, kita akan menempatkan himpunan koordinat (titik) ini ke dalam variabel relasi dan kita akan menamai variabel ini Points . Kami akan mewakili nilai relasi Points seperti tabel di bawah ini:
Points| x | y | z |
=======+====+====+====+
| x1 | y1 | z1 |
+----+----+----+
| x2 | y2 | z2 |
+----+----+----+
| .. | .. | .. |
| .. | .. | .. |
+----+----+----+
| x8 | y8 | z8 |
+----+----+----+
Apakah kubus ini sedang "diratakan" hanya dengan merepresentasikannya dalam bentuk tabel? Apakah relasi (nilai) sama dengan representasi tabularnya?
Variabel relasi diasumsikan sebagai kumpulan nilai dari titik-titik dalam ruang diskrit n-dimensi, di mana n adalah jumlah atribut relasi ("kolom"). Apa artinya, untuk ruang diskrit n-dimensi, menjadi "datar"? Hanya omong kosong, seperti yang saya tulis di atas.
Jangan salah paham, Memang benar bahwa SQL adalah bahasa yang dirancang dengan buruk dan DBMS berbasis SQL penuh dengan keanehan dan kekurangan (NULL, redundansi, ...), terutama yang buruk, DBMS-sebagai- tipe dumb-store (tidak ada batasan referensial, tidak ada batasan integritas, ...). Tapi itu tidak ada hubungannya dengan batasan fantasi model data relasional, sebaliknya:semakin mereka berpaling darinya dan hasilnya lebih buruk.
Secara khusus, model data relasional, setelah Anda memahaminya, tidak menimbulkan masalah dalam mewakili struktur apa pun, bahkan hierarki dan grafik, seperti yang saya rinci dengan referensi ke makalah yang diterbitkan di atas. Bahkan SQL dapat, jika Anda menutupi kekurangannya, kehilangan sesuatu yang lebih baik.
Pada "Model Kumpulan Bersarang"
Saya membaca sekilas artikel itu dan saya tidak terlalu terkesan dengan desain logis seperti itu:ini menyarankan untuk mengacaukan dua entitas yang berbeda, simpul dan tautan , menjadi satu relasi dan ini mungkin akan menyebabkan kecanggungan. Tapi saya tidak cenderung menganalisis desain itu lebih teliti, maaf.
EDIT: Stephan Eggermont keberatan, dalam komentar di bawah, bahwa " Model daftar datar adalah masalah. Ini adalah abstraksi dari implementasi yang membuat kinerja sulit dicapai. ... ".
Sekarang, maksud saya adalah, tepatnya, bahwa:
- "model daftar datar" ini adalah fantasi :hanya karena satu lay out (mewakili) relasi sebagai tabel ("daftar datar") tidak berarti bahwa relasi adalah "daftar datar" ("objek" dan representasinya tidak sama);
- representasi logis (relasi) dan detail penyimpanan fisik (dekomposisi horizontal atau vertikal, kompresi, indeks (hash, b+tree, r-tree, ...), pengelompokan, partisi, dll.) berbeda; salah satu poin dari model data relasional (RDM ) adalah untuk memisahkan logika dari model "fisik" (dengan keuntungan bagi pengguna dan pelaksana DBMS);
- kinerja adalah konsekuensi langsung dari detail penyimpanan fisik (implementasi) dan bukan representasi logis (komentar Eggermont adalah contoh klasik dari kebingungan logika-fisik ).
Model RDM tidak membatasi implementasi dengan cara apa pun; seseorang bebas untuk mengimplementasikan tupel dan relasi sesuai keinginannya. Hubungan belum tentu file dan tupel belum tentu catatan dari sebuah file. Korespondensi semacam itu adalah implementasi gambar langsung yang bodoh .
Sayangnya implementasi DBMS berbasis SQL adalah , terlalu sering, implementasi gambar langsung yang bodoh dan kinerjanya buruk dalam berbagai skenario - OLAP /ETL produk ada untuk menutupi kekurangan ini.
Ini perlahan berubah. Ada implementasi perangkat lunak/sumber terbuka komersial dan gratis yang akhirnya menghindari perangkap mendasar ini:
- Vertica , yang merupakan penerus komersial dari..
- C-Store:DBMS Berorientasi Kolom ;
- MonetDB ;
- LucidDB ;
- Kdb dengan cara;
- dan seterusnya...
Tentu saja, intinya adalah tidak bahwa harus ada desain penyimpanan fisik "optimal", tetapi desain penyimpanan fisik apa pun dapat diabstraksikan dengan bahasa deklaratif yang bagus berdasarkan aljabar/kalkuli relasional (dan SQL adalah buruk contoh) atau lebih langsung pada bahasa pemrograman logika (seperti Prolog, misalnya - lihat jawaban saya untuk "prolog ke konverter SQL " pertanyaan). DBMS yang baik harus mengubah desain penyimpanan fisik dengan cepat, berdasarkan statistik akses data (dan/atau petunjuk pengguna).
Akhirnya, dalam komentar Eggermont pernyataan " Model relasional semakin terjepit antara cloud dan prevayler. " adalah omong kosong lain tetapi saya tidak bisa memberikan bantahan di sini, komentar ini sudah terlalu panjang.
