Halaman ini ditulis untuk siapa saja yang mencoba menggunakan LookML untuk membuat Jelajah di Looker. Halaman ini akan lebih mudah dipahami jika Anda mahir dalam SQL, terutama jika Anda memahami perbedaan antara join dalam dan luar. Untuk penjelasan ringkas tentang perbedaan join dalam dan luar, lihat artikel w3schools tentang Join SQL.
Looker memiliki kemampuan untuk menjadi mesin SQL yang andal bagi perusahaan Anda. Pemodelan abstrak di LookML memungkinkan tim data dan IT membuat aturan umum yang selalu benar, sehingga analis bisnis dapat membuat kueri di lapangan yang selalu benar meskipun tim data tidak pernah mengantisipasi kebutuhannya. Penggerak inti kemampuan ini adalah algoritma agregat simetris,
yang memecahkan masalah di seluruh industri terkait join SQL. Namun, ada dua hal yang harus dilakukan dengan benar untuk memanfaatkan algoritma ini: kunci utama harus akurat di setiap tampilan yang berisi ukuran (biasanya semuanya), dan parameter relationship harus benar di setiap join.
Kunci utama
Dalam banyak hal, memahami kunci utama tabel pada dasarnya sama dengan memahami apa itu tabel dan apa yang dapat dilakukan dengan tabel tersebut. Satu-satunya hal yang harus benar adalah kolom (atau kumpulan kolom yang digabungkan) yang Anda pilih sebagai kunci utama tidak boleh memiliki nilai berulang.
Parameter relationship
Setelah memverifikasi kunci utama, Anda dapat menentukan nilai yang benar untuk parameter relationship join. Tujuan parameter relationship adalah untuk memberi tahu Looker apakah akan memanggil agregat simetris saat join ditulis ke dalam kueri SQL. Pendekatan yang mungkin dilakukan di sini adalah dengan memberi tahu Looker untuk selalu memanggilnya, yang akan selalu menghasilkan hasil yang akurat. Namun, hal ini akan mengurangi performa, jadi sebaiknya gunakan agregat simetris dengan cermat.
Proses untuk menentukan nilai yang benar sedikit berbeda antara join dalam dan luar.
Inner join
Misalnya, Anda memiliki tabel pesanan dengan kunci utama order_id:
| order_id | jumlah | customer_id |
|---|---|---|
| 1 | $25,00 | 1 |
| 2 | $50,00 | 1 |
| 3 | $75,00 | 2 |
| 4 | $35,00 | 3 |
Misalkan Anda juga memiliki tabel pelanggan dengan kunci utama customer_id:
| customer_id | first_name | last_name | kunjungan |
|---|---|---|---|
| 1 | Amelia | Earhart | 2 |
| 2 | Bessie | Coleman | 2 |
| 3 | Wilbur | Wright | 4 |
Anda dapat menggabungkan tabel ini pada kolom customer_id, yang ada di kedua tabel. Gabungan ini akan direpresentasikan dalam LookML seperti ini:
explore: orders {
join: customers {
type: inner
sql_on: ${orders.customer_id} = ${customers.customer_id} ;;
relationship: many_to_one
}
}
Hasil penggabungan LookML ini dapat direpresentasikan sebagai satu tabel gabungan, sebagai berikut:
| order_id | jumlah | customer_id | customer_id | first_name | last_name | kunjungan |
|---|---|---|---|---|---|---|
| 1 | $25,00 | 1 | 1 | Amelia | Earhart | 2 |
| 2 | $50,00 | 1 | 1 | Amelia | Earhart | 2 |
| 3 | $75,00 | 2 | 2 | Bessie | Coleman | 2 |
| 4 | $35,00 | 3 | 3 | Wilbur | Wright | 4 |
Hubungan many_to_one di sini mengacu pada frekuensi satu nilai kolom join (customer_id) direpresentasikan dalam setiap tabel. Dalam tabel orders (tabel kiri), satu ID pelanggan ditampilkan beberapa kali (dalam hal ini, ini adalah pelanggan dengan ID 1, yang ada di beberapa baris).
Dalam tabel customers (tabel kanan), setiap ID pelanggan hanya direpresentasikan satu kali karena customer_id adalah kunci utama tabel tersebut. Oleh karena itu, kumpulan data dalam tabel orders dapat memiliki banyak kecocokan untuk satu nilai dalam tabel customers. Jika customer_id tidak unik di setiap baris tabel customers, hubungannya akan menjadi many_to_many.
Anda dapat mengikuti langkah-langkah berikut untuk menentukan nilai hubungan yang benar secara terprogram dengan memeriksa kunci utama:
- Mulai dengan menulis
many_to_manysebagai hubungan. Selama kunci utama Anda benar, tindakan ini akan selalu menghasilkan hasil yang akurat karena Looker akan selalu memicu algoritma agregasi simetris dan menerapkan akurasi. Namun, karena algoritma mempersulit kueri dan menambahkan waktu proses, sebaiknya coba ubah satu atau kedua sisi menjadione, bukanmany. - Lihat kolom yang ada dalam klausa
sql_ondari tabel sebelah kiri. Jika kolom atau kolom membentuk kunci utama tabel kiri, Anda dapat mengubah sisi kiri parameterrelationshipmenjadione. Jika tidak, biasanya harus tetapmany. (Untuk informasi tentang kasus khusus, lihat bagian Hal-hal yang perlu dipertimbangkan nanti di halaman ini.) - Selanjutnya, lihat kolom atau kolom yang mewakili tabel kanan Anda dalam klausa
sql_on. Jika kolom atau kolom membentuk kunci utama tabel kanan, Anda dapat mengubah sisi kanan menjadione.
Praktik terbaiknya adalah menulis frasa sql_on Anda yang dimulai dengan tabel kiri, yang diwakili di sisi kiri tanda sama dengan, dan tabel kanan, yang berada di sisi kanan. Urutan kondisi dalam parameter sql_on tidak penting, kecuali jika urutan tersebut relevan dengan dialek SQL database Anda. Meskipun parameter sql_on tidak mengharuskan Anda mengurutkan kolom dengan cara ini, mengatur kondisi sql_on sehingga sisi kiri dan kanan tanda sama dengan cocok dengan cara parameter relationship dibaca dari kiri ke kanan dapat membantu Anda menentukan hubungan. Mengurutkan kolom dengan cara ini juga dapat membantu mempermudah Anda membedakan, secara sekilas, tabel yang ada di Jelajahi yang akan Anda gabungkan dengan tabel baru.
Join luar
Untuk join luar, Anda juga perlu mempertimbangkan bahwa fanout dapat terjadi saat data null ditambahkan selama join. Hal ini sangat penting karena join luar kiri adalah setelan default di Looker. Meskipun tidak memengaruhi jumlah atau rata-rata, data null memengaruhi cara Looker menjalankan pengukuran type: count. Jika hal ini dilakukan dengan tidak benar, data null akan dihitung (yang tidak diinginkan).
Dalam full outer join, data null dapat ditambahkan ke salah satu tabel jika kunci join-nya tidak memiliki nilai yang ada di tabel lain. Hal ini diilustrasikan dalam contoh berikut, yang melibatkan tabel orders:
| order_id | jumlah | customer_id |
|---|---|---|
| 1 | $25,00 | 1 |
| 2 | $50,00 | 1 |
| 3 | $75,00 | 2 |
| 4 | $35,00 | 3 |
Untuk contoh, anggaplah Anda juga memiliki tabel customers berikut:
| customer_id | first_name | last_name | kunjungan |
|---|---|---|---|
| 1 | Amelia | Earhart | 2 |
| 2 | Bessie | Coleman | 2 |
| 3 | Wilbur | Wright | 4 |
| 4 | Charles | Yeager | 3 |
Setelah tabel ini digabungkan, tabel gabungan dapat direpresentasikan sebagai berikut:
| order_id | jumlah | customer_id | customer_id | first_name | last_name | kunjungan |
|---|---|---|---|---|---|---|
| 1 | $25,00 | 1 | 1 | Amelia | Earhart | 2 |
| 2 | $50,00 | 1 | 1 | Amelia | Earhart | 2 |
| 3 | $75,00 | 2 | 2 | Bessie | Coleman | 2 |
| 4 | $35,00 | 3 | 3 | Wilbur | Wright | 4 |
| null | null | null | 4 | Charles | Yeager | 3 |
Sama seperti dalam join dalam, hubungan antara kunci utama tabel adalah many_to_one. Namun, data null yang ditambahkan juga memaksa perlunya agregat simetris di tabel kiri. Oleh karena itu, Anda harus mengubah parameter relationship menjadi many_to_many, karena melakukan join ini akan mengganggu jumlah di tabel sebelah kiri.
Jika contoh ini adalah join luar kiri, baris null tidak akan ditambahkan dan data pelanggan tambahan akan dihapus. Dalam hal ini, hubungannya akan tetap many_to_one. Ini adalah setelan default Looker karena diasumsikan bahwa tabel dasar menentukan analisis. Dalam hal ini, Anda menganalisis pesanan, bukan pelanggan. Jika tabel pelanggan berada di sebelah kiri, situasinya akan berbeda.
Join multi-level
Di beberapa Jelajah, tabel dasar bergabung dengan satu atau beberapa tampilan yang, pada gilirannya, perlu bergabung dengan satu atau beberapa tampilan tambahan. Dalam contoh di sini, artinya tabel akan digabungkan ke tabel pelanggan. Dalam situasi ini, sebaiknya hanya lihat setiap join yang ditulis saat mengevaluasi parameter relationship. Looker akan memahami kapan fanout downstream memengaruhi kueri meskipun tampilan yang terpengaruh tidak ada dalam join yang benar-benar membuat fanout.
Bagaimana cara Looker membantu saya?
Ada mekanisme di Looker untuk membantu memastikan bahwa nilai hubungan sudah benar. Salah satunya adalah pemeriksaan keunikan kunci utama. Setiap kali ada fanout dan agregat simetris diperlukan untuk menghitung ukuran, Looker akan memeriksa kunci utama yang dimanfaatkan untuk mengetahui keunikannya. Jika tidak unik, error akan muncul pada waktu kueri dijalankan (tetapi, tidak ada error LookML Validator untuk hal ini).
Selain itu, jika Looker tidak dapat menangani fanout (biasanya karena tidak ada kunci utama yang ditunjukkan), tidak ada ukuran yang akan muncul di Jelajahi dari tampilan tersebut. Untuk memperbaikinya, cukup tetapkan kolom sebagai kunci utama agar ukuran Anda dapat masuk ke bagian Jelajahi.
Hal-hal yang perlu dipertimbangkan
Dukungan dialek untuk agregat simetris
Looker dapat terhubung dengan beberapa dialek yang tidak mendukung agregat simetris. Anda dapat melihat daftar dialek dan dukungannya untuk agregat simetris di halaman dokumentasi symmetric_aggregates.
Kasus khusus
Bagian Inner join sebelumnya di halaman ini menyatakan bahwa, untuk menentukan nilai hubungan yang benar, Anda harus melihat kolom atau kolom yang ada dalam klausa sql_on dari tabel kiri: “Jika kolom atau kolom membentuk kunci utama tabel kiri, Anda dapat mengubah sisi kiri parameter relationship menjadi one. Jika tidak, biasanya harus tetap sebagai many.” Hal ini berlaku kecuali jika tabel Anda berisi beberapa kolom yang tidak memiliki data berulang di dalamnya. Dalam hal ini, Anda dapat memperlakukan kolom tersebut seolah-olah itu adalah kunci utama saat merumuskan hubungan, meskipun bukan kolom yang ditetapkan primary_key: yes.
Sebaiknya pastikan ada semacam aturan software yang memastikan bahwa pernyataan di paragraf sebelumnya akan selalu benar untuk kolom yang Anda tetapkan. Jika demikian, lanjutkan dan perlakukan sebagai demikian dan catat properti khususnya dalam file tampilan agar orang lain dapat mereferensikannya di masa mendatang (lengkap dengan link SQL Runner untuk membuktikannya). Namun, perlu diketahui bahwa Looker akan mengonfirmasi kebenaran keunikan tersirat saat kolom ditetapkan sebagai kunci utama, tetapi tidak akan melakukan hal yang sama untuk kolom lain. Tindakan ini hanya akan mencegah algoritma agregat simetris dipanggil.