Apa itu model relasional?
Ikhtisar model relasional
Model relasional Quick BI adalah kerangka pemodelan data yang dirancang untuk menggabungkan dan menganalisis beberapa tabel. Model ini mengatasi masalah umum dalam pemodelan fisik tradisional, seperti inefisiensi, ketidakakuratan, dan kurangnya fleksibilitas analitis, sehingga ideal untuk analisis data multidimensi dalam skenario bisnis yang kompleks.
Saat menggunakan model relasional, Anda tidak perlu mengelola detail data tingkat rendah atau menentukan jenis join secara eksplisit. Cukup letakkan tabel-tabel terkait di Kanvas dan konfigurasikan kunci gabungan (join keys) untuk menyelesaikan model.
Model relasional secara signifikan meningkatkan efisiensi pemodelan sekaligus memastikan akurasi data. Quick BI secara dinamis menyesuaikan kueri SQL berdasarkan bidang yang digunakan saat kueri dieksekusi dan konfigurasi hubungan, sehingga menjamin hasil yang tepat. Untuk detail logika dasarnya, lihat Cara kerja model relasional.
Nilai inti model relasional
Latar belakang dan tantangan
Pada versi Quick BI sebelumnya, pemodelan set data menghubungkan tabel menggunakan join fisik, seperti left join atau full join, yang menghasilkan satu tabel lebar besar. Karena join fisik dapat menyebabkan duplikasi data, pengguna biasanya harus memahami struktur datanya—termasuk kelengkapan dan keunikan datanya—untuk memastikan akurasi. Terkadang, tabel sumber bahkan memerlukan pra-pemrosesan, seperti pre-aggregation, guna mencegah duplikasi data. Hal ini membuat pemodelan fisik menjadi kompleks, mahal, dan rentan terhadap kesalahan.
Untuk mengatasi tantangan tersebut, Quick BI memperkenalkan model relasional baru yang menambahkan kemampuan "pemodelan hubungan" di atas "pemodelan fisik" yang sudah ada. Model relasional meningkatkan efisiensi dan fleksibilitas saat bekerja dengan model data yang kompleks.
Keunggulan
Pemodelan data yang disederhanakan: Anda tidak perlu menentukan jenis join. Cukup definisikan kunci gabungan untuk menyelesaikan model data. Model relasional secara otomatis menangani koneksi untuk memastikan integritas data.
Mencegah duplikasi data: Ketika granularitas data tidak sesuai, Anda tidak perlu lagi melakukan pra-pemrosesan data selama pemodelan. Model relasional secara otomatis menyelesaikan masalah duplikasi data untuk memastikan perhitungan yang benar.
Mendukung lebih banyak kasus penggunaan analitis dengan lebih sedikit model: Model relasional sangat dapat digunakan kembali. Alih-alih membangun model terpisah untuk skenario analitis berbeda, Anda dapat membuat satu model komprehensif. Hal ini mengurangi jumlah set data serta menyederhanakan pemeliharaan dan manajemen di masa depan.
Untuk informasi lebih lanjut, lihat Keunggulan model relasional.
Perbandingan model fisik dan model relasional
Model fisik | Model relasional |
|
|
Masalah:
| Solusi:
|
Konsep utama
Tabel fakta dan tabel dimensi
Tabel fakta dan tabel dimensi adalah dua jenis tabel umum dalam pemodelan data.
Tabel fakta: Menyimpan ukuran bisnis yang dapat dikuantifikasi dan berisi data terkait peristiwa bisnis (fakta). Misalnya, pada platform pendidikan daring, tabel fakta dapat mencakup jumlah siswa yang menyelesaikan kursus, skor ujian rata-rata, dan total waktu belajar.
Tabel dimensi: Menyimpan atribut deskriptif dan berisi data terkait konteks bisnis (dimensi). Misalnya, tabel dimensi dapat mencakup jenis kursus, tingkat kelas siswa, nama instruktur, dan tanggal belajar.
Tabel fakta dan tabel dimensi dihubungkan melalui bidang umum, sehingga memungkinkan Anda menghubungkan dimensi dan ukuran selama kueri untuk melakukan analisis multidimensi.
Contoh
Tabel fakta
Orders
Order ID | Date | Product ID | Quantity | Amount |
1 | 2025-12-01 | A | 1 | 50 |
2 | 2025-12-01 | A | 2 | 100 |
3 | 2025-12-01 | B | 3 | 60 |
4 | 2025-12-02 | C | 1 | 10 |
Inventory records
Date | Product ID | Inventory |
2025-12-01 | A | 10 |
2025-12-01 | B | 20 |
2025-12-01 | C | 5 |
2025-12-02 | C | 4 |
Tabel dimensi
Product ID | Product Name | Category | Brand |
A | Breeze Facial Tissues (Case) | Household Supplies | Breeze |
B | M&G File Folders (Set) | Stationery | M&G |
C | Oishi Prawn Crackers (Large Bag) | Food | Oishi |
Lapisan dalam pemodelan data
Model data adalah diagram hubungan antar tabel yang memberi tahu Quick BI cara mengkueri data dari tabel database Anda.
Lapisan logis dan lapisan fisik
Model data Quick BI memiliki dua lapisan:
Lapisan logis:
Saat Anda membuka kanvas pemodelan data untuk suatu set data, Anda pertama kali melihat lapisan logis. Dalam kebanyakan kasus, Anda hanya perlu bekerja di lapisan logis.
Anda menggunakan hubungan (garis yang menghubungkan tabel) untuk mendefinisikan bagaimana node berbeda di lapisan logis saling terkait. Setiap node adalah tabel logis. Tabel logis dapat berupa satu tabel, satu kueri SQL kustom, atau tabel lebar yang dibuat menggunakan join fisik atau union pada beberapa tabel atau kueri SQL kustom.
Pemodelan di lapisan logis membangun model data lengkap.
Lapisan fisik:
Dari tabel logis mana pun di lapisan logis, Anda dapat memasuki kanvas fisik tabel tersebut, yaitu lapisan fisik.
Lapisan fisik menggunakan join fisik dan union tradisional untuk mendefinisikan hubungan antara beberapa tabel fisik. Setiap node adalah tabel database atau kueri SQL kustom.
Pemodelan di lapisan fisik menghasilkan tabel lebar tetap, yang kemudian menjadi satu node logis di lapisan logis.
Lapisan logis | Lapisan fisik |
Relationship lines | Venn diagrams |
|
|
Hubungan antara lapisan logis dan lapisan fisik
Di lapisan logis, setiap tabel logis dihubungkan oleh "hubungan", yang pada akhirnya membentuk "model relasional". Saat memodelkan di lapisan logis, Anda tidak perlu menentukan jenis join untuk hubungan tersebut, dan hasilnya bukan tabel lebar tetap.
Setiap tabel logis memiliki "model fisik"-nya sendiri. Anda dapat memasuki lapisan fisik dengan mengklik ganda tabel logis atau dengan mengklik ikon 
dan memilih Go to Physical Canvas. Di lapisan fisik, tabel fisik dihubungkan menggunakan "join" atau "union". Di sini, Anda harus menentukan jenis join secara eksplisit, dan hasil akhirnya adalah tabel lebar lengkap.
Setiap tabel logis di lapisan logis memiliki model fisik yang sesuai (berupa model satu tabel atau multi-tabel) di lapisan fisik.
Pada versi Quick BI sebelumnya, model data hanya terdiri dari lapisan fisik. Mulai versi 6.1 dan seterusnya, model data memiliki lapisan logis dan lapisan fisik, yang menambahkan kemampuan "model relasional".
Kardinalitas dan integritas referensial
Saat Anda mengonfigurasi hubungan, Anda dapat mengklik More Options untuk mengatur kardinalitas dan integritas referensial. Quick BI menggunakan pengaturan ini untuk memilih jenis join paling tepat untuk kueri. Jika Anda mengonfigurasi pengaturan ini secara akurat, Anda dapat mencapai performa kueri yang lebih baik.
Jika Anda tidak memahami distribusi data Anda atau konsep kardinalitas dan integritas referensial, jangan ubah pengaturan default. Konfigurasi yang salah dapat menyebabkan kesalahan seperti duplikasi data atau kehilangan data.
Hanya sesuaikan pengaturan kardinalitas dan integritas referensial untuk mengoptimalkan performa kueri jika Anda memahami dengan jelas distribusi data Anda dan yakin bahwa distribusi tersebut tidak akan berubah di masa depan.
Kardinalitas
Kardinalitas menjelaskan apakah nilai kunci gabungan di suatu tabel bersifat unik dan bagaimana nilai kunci gabungan di dua tabel saling berkorespondensi.
1: Bidang berisi nilai unik.
N: Bidang berisi nilai tidak unik (banyak).
Kardinalitas | Contoh | Diagram |
1:1 | Setiap orang memiliki satu nomor KTP nasional yang unik, dan setiap nomor KTP nasional hanya berkorespondensi dengan satu orang. |
|
1:N | Setiap provinsi berkorespondensi dengan banyak kota, tetapi setiap kota hanya berkorespondensi dengan satu provinsi. |
|
N:1 |
| |
N:N | Satu buku dapat memiliki banyak penulis, dan satu penulis dapat memiliki banyak buku. |
|
Integritas referensial
Integritas referensial menjelaskan apakah nilai kunci gabungan di satu tabel dapat sepenuhnya dicocokkan dengan nilai di tabel lain. Dengan kata lain, integritas referensial menggambarkan kelengkapan data.
Beberapa catatan cocok: Beberapa nilai bidang di satu tabel tidak memiliki pasangan di tabel lain.
Semua catatan cocok: Semua nilai bidang di satu tabel memiliki pasangan yang sesuai di tabel lain.
Integritas referensial | Contoh | Diagram |
All records match : All records match | Setiap negara memiliki provinsi yang sesuai, dan setiap provinsi memiliki negara yang sesuai. |
|
Some records match : All records match | Setiap buku memiliki penulis yang sesuai, tetapi beberapa penulis mungkin tidak memiliki buku yang sesuai (misalnya, mereka belum menerbitkan apa pun). |
|
All records match : Some records match | ||
Some records match : Some records match | Beberapa siswa tidak memiliki kursus yang sesuai (mereka belum mendaftar), dan beberapa kursus tidak memiliki siswa yang sesuai (tidak ada yang mendaftar). |
|
Kasus penggunaan model relasional
Kasus penggunaan model relasional
Kasus penggunaan 1: Pemodelan sederhana untuk pengguna bisnis
Jika Anda memiliki pengetahuan terbatas tentang SQL atau database, kami merekomendasikan menggunakan model relasional untuk tugas pemodelan data Anda.
Mengonfigurasi model relasional lebih sederhana daripada pemodelan fisik. Anda hanya perlu menentukan kunci gabungan antara dua tabel. Kami merekomendasikan menggunakan nilai default untuk pengaturan lanjutan. Model relasional secara efektif mencegah duplikasi data tanpa mengharuskan Anda khawatir tentang kelengkapan atau keunikan data, sehingga menurunkan hambatan masuk untuk pemodelan dan meningkatkan akurasi.
Contoh
Departemen HR membuat sistem poin untuk mendorong karyawan berpartisipasi dalam kegiatan pelatihan. Karyawan mendapatkan poin dengan menghadiri acara dan dapat menukarkannya dengan hadiah. Database memiliki dua tabel:
Tabel poin diperoleh: Date, Employee ID, Department, Activity Name, Points Earned
Tabel poin ditukar: Date, Employee ID, Department, Gift Name, Points Spent
Hubungan antara tabel poin diperoleh dan tabel poin ditukar adalah sebagai berikut:
Tabel poin diperoleh - Tabel poin ditukar | ||
Kardinalitas | N:N | Karyawan dapat berpartisipasi dalam banyak aktivitas untuk mendapatkan poin dan juga dapat menukar poin berkali-kali. Oleh karena itu, bidang "Employee ID" tidak unik di kedua tabel. |
Integritas referensial | Some records match : All records match | Karyawan mungkin mendapatkan poin tetapi tidak pernah menukarnya. Dalam kasus ini, catatan karyawan tersebut ada di "Tabel poin diperoleh" tetapi tidak ada di "Tabel poin ditukar." Jika karyawan belum pernah mendapatkan poin, mereka tidak dapat menukarnya. Oleh karena itu, catatan tidak dapat ada di "Tabel poin ditukar" jika tidak ada di "Tabel poin diperoleh". |
Sekarang, analis HR perlu melakukan analisis self-service untuk memeriksa sisa poin setiap karyawan. Langkah awal yang wajar adalah membuat join fisik antara kedua tabel berdasarkan bidang "Employee ID". Namun, karena "Employee ID" tidak unik di kedua tabel, join langsung akan menyebabkan duplikasi data. Pendekatan yang benar dalam pemodelan fisik adalah mengagregasi kedua tabel berdasarkan "Employee ID" sebelum menggabungkannya, tetapi hal ini memerlukan keterampilan pra-pemrosesan data.
Jika analis HR menggunakan model relasional, mereka dapat langsung membuat hubungan menggunakan "Employee ID". Selama perhitungan aktual, Quick BI secara otomatis mengagregasi data untuk memastikan akurasi.
Untuk detail logika perhitungan, lihat Cara kerja model relasional.
Kasus penggunaan 2: Meningkatkan kemampuan guna ulang set data
Saat bekerja dengan sejumlah besar tabel sumber, pengguna IT dapat menyeret semua tabel terkait ke kanvas logis untuk membangun satu model relasional komprehensif. Pengguna bisnis kemudian dapat memilih bidang yang mereka butuhkan untuk analisis mereka. Pendekatan ini mencegah tim IT harus membuat banyak tabel lebar hasil join untuk skenario analitis berbeda, yang dapat menyebabkan proliferasi set data yang sulit dikelola dan dipelihara.
Dalam kasus penggunaan ini, kami merekomendasikan agar pengguna IT mengonfigurasi pengaturan "kardinalitas" dan "integritas referensial" secara akurat berdasarkan karakteristik data. Hal ini membantu mengoptimalkan performa kueri dan mengurangi dampak performa dari model yang kompleks.
Contoh
Mari kembali ke contoh sistem poin departemen HR:
Tabel poin diperoleh: Date, Employee ID, Department, Activity Name, Points Earned
Tabel poin ditukar: Date, Employee ID, Department, Gift Name, Points Spent
Berbeda dengan contoh sebelumnya, perusahaan ini memiliki tim IT terpusat yang menyiapkan set data untuk semua analis. Departemen HR mengajukan permintaan data untuk tiga skenario berikut. Jika tim IT menggunakan pemodelan fisik, mereka harus membuat tiga set data terpisah.
Skenario | Deskripsi | Pendekatan pemodelan |
Skenario 1 | Analisis jumlah peserta dan poin yang diperoleh untuk setiap aktivitas. | Tabel poin diperoleh (model satu tabel) |
Skenario 2 | Analisis jumlah orang dan penukaran untuk setiap hadiah. | Tabel poin ditukar (model satu tabel) |
Skenario 3 | Analisis sisa poin untuk setiap karyawan dan buat daftar peringkat. | Gabungkan tabel poin diperoleh dan tabel poin ditukar setelah mengagregasi masing-masing berdasarkan "Employee ID." |
Karena "Tabel poin diperoleh" dan "Tabel poin ditukar" memiliki tingkat granularitas berbeda, join fisik langsung akan menyebabkan duplikasi data dan hasil yang salah. Namun, jika tabel diagregasi terlebih dahulu berdasarkan "Employee ID", detail penting seperti "Activity Name" dan "Gift Name" akan hilang, sehingga tidak mungkin melakukan analisis untuk Skenario 1 dan Skenario 2. Oleh karena itu, saat menggunakan pemodelan fisik, tim IT harus menyiapkan tiga set data terpisah untuk mendukung ketiga skenario tersebut.
Namun, jika tim IT menggunakan model relasional, mereka hanya perlu menyiapkan satu set data. Quick BI akan secara otomatis memilih metode perhitungan yang tepat berdasarkan bidang yang digunakan dalam analisis untuk memastikan akurasi data.
Skenario | Deskripsi | Pendekatan pemodelan | Bidang yang digunakan | Penanganan model |
Skenario 1 | Analisis jumlah peserta dan poin yang diperoleh untuk setiap aktivitas. | Kunci join: ID Karyawan N:N Some : All | Dimensi: Nama Aktivitas Ukuran: Employee ID (distinct count), Points Earned (sum) | Kueri satu tabel |
Skenario 2 | Analisis jumlah orang dan penukaran untuk setiap hadiah. | Dimensi: Gift Name Ukuran: Employee ID (distinct count), Points Spent (sum) | Kueri satu tabel | |
Skenario 3 | Analisis sisa poin untuk setiap karyawan dan buat daftar peringkat. | Dimensi: Employee ID Ukuran: SUM(Points Earned) - SUM(Points Spent) | Join setelah agregasi |
Untuk detail logika perhitungan, lihat Cara kerja model relasional.
Batasan
Batasan performa
Untuk mencegah duplikasi data, model relasional menerapkan pemrosesan khusus pada kueri SQL, yang membuat SQL menjadi lebih kompleks. Dibandingkan dengan join fisik tradisional, kueri yang dihasilkan oleh model relasional memiliki lebih banyak subkueri dan nesting yang lebih dalam, yang dapat menurunkan performa kueri. Dampak performa ini sangat terkait dengan volume data dan kompleksitas model. Seiring peningkatan volume data dan kompleksitas model, selisih performa antara model relasional dan model fisik menjadi semakin nyata.
Jika Anda sangat memahami distribusi data Anda, Anda dapat mengoptimalkan performa kueri dengan menyesuaikan pengaturan "kardinalitas" dan "integritas referensial". Secara umum, performa setiap pengaturan diurutkan sebagai berikut:
Kardinalitas: 1:1 > 1:N = N:1 > N:N
Integritas Referensial: All records match : All records match > All records match : Some records match = Some records match : All records match > Some records match : Some records match
Jika Anda tidak memahami distribusi data Anda atau konsep "kardinalitas" dan "integritas referensial", jangan ubah pengaturan default. Konfigurasi yang salah dapat menyebabkan kesalahan seperti duplikasi data atau kehilangan data.
Hanya sesuaikan pengaturan "kardinalitas" dan "integritas referensial" untuk mengoptimalkan performa kueri jika Anda memahami dengan jelas distribusi data Anda dan yakin bahwa distribusi tersebut tidak akan berubah di masa depan.
Namun demikian, jika Anda memiliki keterampilan pemrosesan data yang kuat dan memerlukan performa kueri yang sangat tinggi, kami merekomendasikan menggunakan pendekatan pemodelan fisik tradisional. Hal ini memungkinkan Anda menghindari overhead komputasi tambahan yang diperkenalkan oleh logika kompleks model relasional.
Batasan volume data
Saat ukuran berasal dari beberapa tabel logis, Quick BI mengkueri dan menghitung setiap tabel logis secara terpisah, lalu menggabungkan hasilnya untuk mendapatkan output akhir. Untuk memastikan efisiensi kueri dan stabilitas layanan Quick BI secara keseluruhan, setiap kueri memiliki batas volume data sebesar 10.000 baris. Untuk detail lebih lanjut, lihat Cara kerja model relasional.
Batas 10.000 baris ini dapat dipahami sebagai batas data setelah agregasi. Misalnya, jika kunci gabungan adalah "Region" dan dimensi kueri adalah "Product Type", kueri pada tabel logis akan diagregasi berdasarkan bidang "Region" dan "Product Type", dan 10.000 baris pertama dari hasil agregasi akan dikembalikan.
Karena kompleksitas komputasi model relasional, Anda tidak dapat menggunakan pagination untuk mengambil data di luar batas 10.000 baris. Jika Anda perlu mengkueri data pada tingkat granularitas yang lebih detail atau jika dimensi kueri Anda memiliki terlalu banyak nilai unik, pemrosesan model relasional dapat menghasilkan data yang tidak lengkap. Dalam skenario ini, kami merekomendasikan agar Anda tetap menggunakan join fisik tradisional untuk pemodelan.
Batasan fitur
Dengan diperkenalkannya model relasional, pemrosesan dan perhitungan data dasar dalam set data telah mengalami perubahan signifikan. Fitur-fitur berikut tidak kompatibel dengan versi lama:
Paket resource tidak mendukung impor set data dari versi yang lebih baru ke lingkungan yang lebih lama. Hal ini akan menyebabkan error. Kami merekomendasikan agar Anda terlebih dahulu meningkatkan lingkungan target ke versi 6.1 atau lebih baru sebelum mengimpor paket resource.
API lama
QueryDatasetDetailInfountuk mengkueri detail set data tidak lagi kompatibel dengan set data model relasional. Kami merekomendasikan beralih ke API baru:QueryDatasetInfo.API lama (tidak lagi dipelihara): https://next.api.aliyun.com/document/quickbi-public/2022-01-01/QueryDatasetDetailInfo
API baru: https://next.api.aliyun.com/document/quickbi-public/2022-01-01/QueryDatasetInfo
Quick BI v6.1 memperkenalkan versi awal model relasional. Fitur-fitur berikut saat ini hanya mendukung set data tabel logis tunggal. Dukungan untuk set data multi-tabel logis akan ditambahkan di versi berikutnya:
Data preparation
Dalam kondisi filter kompleks, Anda tidak dapat memilih bidang dari beberapa tabel logis. Fitur-fitur berikut terpengaruh oleh batasan ini:
Keamanan tingkat baris: termasuk otorisasi kombinasi kondisional dan otorisasi berbasis tag pengguna
Dasbor - Composite Query Control
Monitoring dan alarm - aturan alarm
Batasan akselerasi ekstraksi: Jika kueri melibatkan lebih dari tiga tabel logis, sistem melewati mesin akselerasi dan menggunakan koneksi langsung.