Halaman ini ditulis untuk siapa saja yang mencoba menggunakan LookML untuk membuat Jelajah di Looker. Laman ini akan lebih mudah dipahami jika Anda mahir dalam SQL, khususnya jika Anda memahami perbedaan antara {i>inner<i} dan {i>outer join<i}. Untuk mengetahui penjelasan singkat tentang perbedaan penggabungan dalam dan luar, lihat artikel w3schools tentang Penggabungan SQL.
Looker memiliki kemampuan untuk menjadi mesin SQL yang canggih bagi perusahaan Anda. Pemodelan abstrak di LookML memungkinkan tim data dan IT untuk membangun aturan umum yang selalu benar, membebaskan analis bisnis untuk membangun kueri di alam liar yang selalu benar bahkan jika tim data tidak pernah mengantisipasi kebutuhan mereka. Pendorong utama kemampuan ini adalah algoritma agregat simetris, yang memecahkan masalah di seluruh industri terkait penggabungan SQL. Namun, dua hal harus dilakukan dengan benar untuk memanfaatkan algoritme: 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 {i>primary key<i} dari sebuah tabel pada dasarnya sama dengan memahami apa itu tabel dan apa yang mungkin dilakukan dengannya. Satu-satunya hal yang harus benar adalah kolom (atau kumpulan kolom sambungan) 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 memungkinkan dalam kasus ini adalah memberi tahu Looker untuk selalu memanggilnya, yang akan selalu memberikan hasil yang akurat. Namun, hal ini berdampak pada performa, jadi sebaiknya gunakan agregat simetris dengan bijaksana.
Proses untuk menentukan nilai yang benar sedikit berbeda antara gabungan dalam dan luar.
{i>Inner join<i}
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 | Burung Earhart | 2 |
| 2 | Bessie | Coleman | 2 |
| 3 | Wilbur | Wright | 4 |
Anda dapat menggabungkan tabel ini di 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 | Burung Earhart | 2 |
| 2 | $50.00 | 1 | 1 | Amelia | Burung 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 berapa kali satu nilai kolom join (customer_id) direpresentasikan di setiap tabel. Pada tabel orders (tabel kiri), satu ID pelanggan diwakili beberapa kali (dalam hal ini, ini adalah pelanggan dengan ID 1, yang terdapat di beberapa baris).
Pada tabel customers (tabel kanan), setiap ID pelanggan hanya diwakili satu kali karena customer_id adalah kunci utama tabel tersebut. Oleh karena itu, 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 ini 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 memberikan hasil yang akurat karena Looker akan selalu memicu algoritma agregasi simetris dan menerapkan akurasi. Namun, karena algoritme akan merumitkan kueri dan menambahkan waktu proses, sebaiknya coba ubah salah satu atau kedua sisi menjadione, bukanmany. - Lihat satu atau beberapa kolom yang ada di klausa
sql_ondari tabel kiri. Jika 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 yang mewakili tabel kanan Anda dalam klausa
sql_on. Jika kolom membentuk kunci utama tabel kanan, Anda dapat mengubah sisi kanan menjadione.
Praktik terbaiknya adalah menulis frasa sql_on yang dimulai dengan tabel kiri, yang diwakili di sisi kiri tanda sama dengan, dan tabel kanan, berada di sisi kanan. Urutan kondisi dalam parameter sql_on tidak berpengaruh, 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 Anda membedakan tabel yang sudah ada di bagian Jelajahi dengan cepat dan mudah dilihat.
{i>Outer join<i}
Untuk outer join, Anda juga perlu mempertimbangkan bahwa fanout mungkin terjadi jika record null ditambahkan selama join. Hal ini sangat penting karena left outer join adalah default di Looker. Meskipun data null tidak memengaruhi jumlah atau rata-rata, data tersebut memengaruhi cara Looker menjalankan pengukuran type: count. Jika hal ini tidak dilakukan dengan benar, {i>record<i} 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 seperti 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 |
Misalnya, anggaplah Anda juga memiliki tabel customers berikut:
| customer_id | first_name | last_name | kunjungan |
|---|---|---|---|
| 1 | Amelia | Burung Earhart | 2 |
| 2 | Bessie | Coleman | 2 |
| 3 | Wilbur | Wright | 4 |
| 4 | Charles | Yager | 3 |
Setelah digabungkan, tabel yang digabungkan dapat ditampilkan sebagai berikut:
| order_id | jumlah | customer_id | customer_id | first_name | last_name | kunjungan |
|---|---|---|---|---|---|---|
| 1 | $25.00 | 1 | 1 | Amelia | Burung Earhart | 2 |
| 2 | $50.00 | 1 | 1 | Amelia | Burung Earhart | 2 |
| 3 | $75.00 | 2 | 2 | Bessie | Coleman | 2 |
| 4 | $35.00 | 3 | 3 | Wilbur | Wright | 4 |
| null | null | null | 4 | Charles | Yager | 3 |
Sama seperti dalam join dalam, hubungan antara kunci utama tabel adalah many_to_one. Namun, data null yang ditambahkan memaksa kebutuhan akan agregat simetris di tabel kiri juga. Oleh karena itu, Anda harus mengubah parameter relationship menjadi many_to_many, karena melakukan penggabungan ini akan mengganggu jumlah di tabel kiri.
Jika contoh ini merupakan left outer join, baris null tidak akan ditambahkan dan data pelanggan tambahan akan dihapus. Dalam hal ini, hubungan akan tetap many_to_one. Ini adalah 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.
Gabungan level
Di beberapa Jelajah, tabel dasar digabungkan ke satu atau beberapa tampilan yang, pada gilirannya, harus digabungkan ke satu atau beberapa tampilan tambahan. Dalam contoh di sini, itu berarti sebuah tabel akan digabungkan ke tabel pelanggan. Dalam situasi ini, sebaiknya hanya lihat gabungan individual yang ditulis saat mengevaluasi parameter relationship. Looker akan memahami kapan fanout downstream memengaruhi kueri meskipun tampilan yang terpengaruh tidak ada dalam gabungan yang benar-benar membuat fanout.
Bagaimana cara Looker membantu saya?
Ada mekanisme dalam Looker untuk membantu memastikan bahwa nilai hubungan sudah benar. Salah satunya adalah pemeriksaan untuk keunikan kunci utama. Setiap kali ada agregat fanout dan simetris yang diperlukan untuk menghitung ukuran, Looker akan memeriksa keunikan kunci utama yang dimanfaatkan. Jika tidak unik, error akan muncul pada waktu kueri dijalankan (tetapi tidak ada error Validator LookML untuk hal ini).
Selain itu, jika tidak ada cara bagi Looker untuk menangani fanout (biasanya karena tidak ada kunci utama yang ditunjukkan), tidak ada tindakan yang akan muncul di Explore dari tampilan tersebut. Untuk memperbaikinya, cukup tetapkan sebuah kolom sebagai kunci utama agar tindakan Anda dapat masuk ke tab Eksplorasi.
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 yang ada di klausa sql_on dari tabel kiri: “Jika kolom merupakan kunci utama dari 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 catatan berulang di dalamnya. Dalam hal ini, Anda dapat memperlakukan kolom apa pun seolah-olah kolom tersebut adalah kunci utama saat merumuskan hubungan, meskipun kolom tersebut bukan primary_key: yes yang ditetapkan.
Akan sangat berguna untuk memastikan bahwa ada semacam aturan perangkat lunak yang memastikan bahwa pernyataan dalam paragraf sebelumnya akan selalu benar untuk kolom yang Anda tetapkan. Jika demikian, lanjutkan dan perlakukan seperti itu dan catat properti khususnya di file tampilan agar dapat dirujuk orang lain di masa mendatang (lengkap dengan link SQL Runner untuk membuktikannya). Meskipun demikian, perlu diketahui bahwa Looker akan mengonfirmasi kebenaran keunikan tersirat jika sebuah kolom ditetapkan sebagai kunci utama, tetapi tidak akan melakukan hal yang sama untuk kolom lainnya. Ini tidak akan memanggil algoritma agregat simetris.