Apa sajakah cara untuk menerapkan hubungan banyak ke banyak dalam data warehouse?

Topologi dominan pemodelan Data Warehouse (Star, Snowflake) dirancang dengan hubungan satu ke banyak. Keterbacaan permintaan, kinerja, dan struktur sangat menurun ketika dihadapkan dengan hubungan banyak ke banyak dalam skema pemodelan ini.

Apa sajakah cara untuk menerapkan hubungan banyak-ke-banyak antara dimensi atau antara tabel fakta dan dimensi dalam gudang data dan kompromi apa yang mereka berikan berkaitan dengan granularitas dan kinerja permintaan yang diperlukan?

Dalam pengalaman saya, hierarki rekursif adalah cara paling praktis untuk mengatasi hal ini. Ini menawarkan keuntungan-keuntungan berikut:

1. Kedalaman tidak terbatas.
2. Kekompakan.
3. Fleksibilitas.
4. Kecepatan.

Sebaliknya, dibutuhkan tabel tambahan untuk setiap level gabungan "-untuk-banyak". Ini sulit dikodekan dan sulit dipertahankan terhadap pembaruan skema.

Dengan menggunakan indeks yang difilter, tabel besar gabungan hierarkis dapat bekerja dengan kecepatan superior ke tabel khusus. Alasannya adalah setiap bergabung hanya "orangtua-anak" dibandingkan dengan "untuk bergabung dengan tabel ke tabel data". Yang terakhir memiliki lebih banyak indeks untuk diproses dan disimpan.

Saya sudah mencoba menyelesaikan masalah ini selama bertahun-tahun. Baru-baru ini, inilah yang saya pikirkan.

Beberapa skenario untuk hubungan M: M dalam model data warehouse

Sebagian besar server OLAP dan sistem ROLAP memiliki sarana untuk menangani struktur data M: M sekarang, tetapi ada beberapa peringatan tentang hal ini yang perlu Anda perhatikan. Jika Anda menerapkan hubungan M: M, Anda perlu mengawasi lapisan pelaporan Anda dan alat apa yang ingin Anda dukung.

Skenario 1: M: M dimensi ke tabel fakta

Contohnya mungkin beberapa driver pada kebijakan motor. Jika Anda menambah atau menghapus driver, transaksi penyesuaian kebijakan mungkin memiliki hubungan dengan daftar driver yang berubah dengan penyesuaian.

Opsi 1 - M: Tabel jembatan driver-fakta M Ini akan memiliki volume data yang cukup besar, karena memiliki driver x baris transaksi untuk kebijakan yang diberikan. SSAS dapat menggunakan struktur data ini secara langsung, tetapi lebih lambat untuk melakukan kueri melalui alat ROLAP.

Jika hubungan M: M Anda didasarkan pada entitas yang khusus untuk baris fakta (misalnya driver pada mobil) ini mungkin cocok untuk alat ROLAP juga, menyediakan alat ROLAP Anda mendukung hubungan M: M (misalnya menggunakan konteks dalam Bisnis Objek).

Opsi 2 - Tabel dimensi 'kombinasi' Dummy Jika Anda memetakan daftar kode umum ke tabel fakta (yaitu entitas yang ditautkan tidak khas ke baris fakta) maka Anda dapat mengambil pendekatan lain yang akan mengurangi volume data. Contoh dari jenis skenario ini adalah kode ICD pada kunjungan rawat inap. Setiap kunjungan rawat inap akan memiliki satu atau lebih diagnosa ICD dan / atau prosedur yang terdaftar. Kode ICD bersifat global.

Dalam hal ini, Anda dapat membuat daftar kombinasi kode yang berbeda untuk setiap kasus. Buat tabel dimensi dengan satu baris untuk setiap kombinasi yang berbeda, dan miliki tabel tautan antara kombinasi dan tabel referensi untuk kode ICD itu sendiri.

Tabel fakta dapat memiliki kunci dimensi ke dimensi 'kombinasi', dan baris dimensi memiliki daftar referensi ke kode ICD aktual. Sebagian besar alat ROLAP dapat menggunakan struktur data ini. Jika alat Anda hanya akan bekerja dengan hubungan M: M yang sebenarnya, maka Anda dapat membuat tampilan yang meniru hubungan M: M antara fakta dan tabel referensi pengkodean. Ini akan menjadi pendekatan yang disukai dengan SSAS.

Keuntungan opsi 1: - Diindeks dengan tepat, kueri berdasarkan pemilihan baris tabel fakta dengan hubungan tertentu melalui tabel M: M dapat cukup efisien.

• Model konseptual yang sedikit lebih sederhana

Keuntungan dari opsi 2: - Penyimpanan data lebih kompak

• Anda dapat meniru hubungan 1: M langsung dengan menghadirkan kombinasi dalam format yang dapat dibaca manusia sebagai kode pada dimensi 'kombinasi'. Ini mungkin lebih berguna pada alat pelaporan dumber yang kurang mendukung untuk hubungan M: M.

Skenario 2: M: M hubungan antara dimensi:

Sulit untuk memikirkan kasus penggunaan, tetapi orang bisa membayangkan sesuatu keluar dari perawatan kesehatan dengan kode ICD lagi. Pada sistem analisis biaya, kunjungan rawat inap dapat menjadi dimensi, dan akan memiliki hubungan M: M antara kunjungan (atau episode konsultan di NHS-speak) dan kode-kode.

Dalam hal ini, Anda dapat mengatur hubungan M: M, dan mungkin menyusun rendering yang dapat dibaca manusia dari mereka pada dimensi dasar. Hubungan dapat dilakukan melalui tabel tautan M: M lurus atau melalui tabel 'kombinasi' seperti sebelumnya. Struktur data ini dapat ditanyakan dengan benar melalui Objek Bisnis atau alat ROLAP yang lebih berkualitas.

Dari atas kepala saya, saya tidak bisa melihat SSAS dapat mengkonsumsi ini tanpa membawa hubungan langsung ke tabel fakta, jadi Anda perlu menyajikan pandangan tentang hubungan M: M antara pengkodean dan tabel fakta baris untuk menggunakan SSAS dengan data ini.

Saya ingin tahu persis apa hubungan banyak-ke-banyak yang ada dalam pikiran Anda dalam model Anda, apakah itu dalam sistem transaksional atau model data apa pun yang saat ini ada.

Biasanya, hubungan banyak-ke-banyak antara dimensi adalah fakta tentang dimensi. Fakta bahwa seorang pelanggan memesan dari beberapa kantor cabang yang melayani banyak pelanggan, atau sesuatu seperti itu. Masing-masing adalah fakta. Itu akan memiliki kencan yang efektif atau sesuatu seperti itu, tetapi hubungan itu bisa "tanpa fakta". Hubungan itu sendiri mungkin memiliki dimensi lain selain pelanggan dan kantor cabang. Jadi ini adalah skema bintang tipikal dengan tabel fakta (yang mungkin kurang fakta) di pusat. Bagaimana bintang ini dapat berhubungan dengan bintang dimensi lain di dalam gudang akan sangat bergantung. Setiap kali Anda menggabungkan bintang yang berbeda, Anda akan melakukannya pada kunci bisnis dan harus memastikan Anda tidak melakukan cross-joins yang tidak disengaja.

Biasanya seseorang tidak melaporkan tabel hubungan dimensi seperti ke tingkat yang sama seperti tabel fakta yang lebih besar dan ketika mereka melakukannya, itu tidak selalu sebanyak data, sehingga tidak cenderung mempengaruhi kinerja. Dalam kasus di atas, Anda mungkin melihat pemanfaatan pelanggan / cabang dari waktu ke waktu, tetapi data yang lebih baik tentang jumlah pesanan aktual akan tersedia dalam tabel fakta pesanan Anda, yang mungkin juga memiliki dimensi untuk pelanggan, cabang, dll. kebanyakan orang akan mempertimbangkan banyak-ke-banyak (meskipun pesanan dapat dianggap untuk menentukan hubungan banyak-ke-banyak dari pelanggan ke cabang), jadi lebih tipikal dalam lingkungan data warehouse. Anda hanya akan melakukan agregat angka pada banyak-ke-banyak model jika Anda telah menggulung informasi ringkasan ke tingkat hubungan itu - yaitu pelanggan, cabang, bulan,

Berikut adalah beberapa artikel yang relevan dari Kimball dan lainnya yang mungkin berlaku untuk pemodelan hubungan banyak-ke-banyak yang diusulkan. Perhatikan bahwa hubungan banyak ke banyak adalah konsep dalam domain masalah / model logis saja. Dalam model OLTP yang dinormalisasi itu masih akan ditangani dengan tabel tautan yang, tentu saja, satu ke banyak setiap jalan. Dalam model gudang data Kimball yang tidak dinormalisasi ada sejumlah cara untuk melakukan ini, salah satunya pada dasarnya memperlakukan tabel tautan itu sebagai fakta di pusat bintang. Lainnya adalah sebagai array dari kolom bendera.

Pada akhirnya, pilihan akan tergantung pada apa yang sebenarnya Anda modelkan, bagaimana itu berubah dan bagaimana Anda ingin melaporkannya. Di sinilah pemodelan dimensi dan penyimpanan data secara umum berbeda secara tajam dari model yang dinormalisasi. Model yang dinormalisasi berkonsentrasi pada hubungan logis dan teoritis dalam data, yang mana pergudangan data selalu mengawasi kasus penggunaan yang realistis dan denormalizes untuk membuat mereka melakukan.

Pemodelan hierarki alternatif menggunakan tabel jembatan:

http://www.kimballgroup.com/wp-content/uploads/2012/05/DT62Alternative.pdf

Tiga opsi untuk hubungan banyak ke banyak (terkait dengan alokasi berbagi numerik - lihat komentar untuk bolak-balik yang menarik)

http://www.pythian.com/news/364/implementing-many-to-many-relationships-in-data-warehousing/

Sayangnya, banyak artikel artikel Kimball Information Week / DBMS tidak lagi memiliki tautan yang baik ...

Salah satu cara kita dapat menyelesaikan ini adalah memiliki tabel Fakta hanya memiliki 2 kolom, kunci asing dari 2 dimensi yang memiliki banyak hubungan kapal.