Penggunaan
explore: explore_name {
join: view_name { ... }
}
|
Hierarki
join |
Nilai Default
Tidak ada
Menerima
Nama tampilan yang ada
Aturan Khusus
|
Definisi
join memungkinkan Anda menentukan hubungan gabungan antara Jelajah dan tampilan, sehingga Anda dapat menggabungkan data dari beberapa tampilan. Anda dapat bergabung ke sebanyak mungkin tampilan yang Anda inginkan untuk Jelajah tertentu.
Ingatlah bahwa setiap tampilan dikaitkan dengan tabel dalam database Anda, atau tabel turunan yang telah Anda tentukan di Looker. Demikian pula, karena Eksplorasi dikaitkan dengan tampilan, Eksplorasi juga terhubung ke tabel tertentu.
Tabel yang terkait dengan Jelajah ditempatkan ke dalam klausa FROM dari SQL yang dihasilkan Looker. Tabel yang terkait dengan gabungan tampilan ditempatkan ke dalam klausa JOIN dari SQL yang dihasilkan Looker.
Parameter gabungan utama
Untuk menentukan hubungan gabungan (klausa SQL ON) antara Eksplorasi dan tampilan, Anda harus menggunakan join bersama dengan parameter lain.
Anda harus menggunakan parameter sql_on atau foreign_key untuk membuat klausa SQL ON.
Anda juga harus memastikan bahwa Anda menggunakan jenis dan hubungan gabungan yang sesuai, meskipun parameter type dan relationship tidak selalu diperlukan secara eksplisit. Jika nilai default type: left_outer dan relationship: many_to_one sesuai untuk kasus penggunaan Anda, parameter ini dapat dikecualikan.
Parameter utama ini, dan hubungannya dengan SQL yang dihasilkan Looker, dapat diringkas sebagai berikut:
- Parameter
exploremenentukan tabel dalam klausaFROMpada kueri SQL yang dihasilkan. - Setiap parameter
joinmenentukan klausaJOINdari kueri SQL yang dihasilkan.- Parameter
typemenentukan jenis gabungan SQL. - Parameter
sql_ondan parameterforeign_keymenentukan klausaONdari kueri SQL yang dihasilkan.
- Parameter
sql_on
sql_on memungkinkan Anda membuat hubungan gabungan dengan menulis klausa SQL ON secara langsung. Fungsi ini dapat melakukan penggabungan yang sama dengan foreign_key, tetapi lebih mudah dibaca dan dipahami.
Lihat halaman dokumentasi parameter sql_on untuk mengetahui informasi selengkapnya.
foreign_key
foreign_key memungkinkan Anda membuat hubungan gabungan menggunakan kunci utama tampilan yang digabungkan, dan menghubungkannya dengan dimensi di Eksplorasi. Pola ini sangat umum dalam desain database, dan foreign_key adalah cara yang efektif untuk mengekspresikan gabungan dalam kasus ini.
Untuk memahami sepenuhnya, lihat halaman dokumentasi parameter foreign_key.
type
Sebagian besar gabungan di Looker adalah LEFT JOIN karena alasan yang dibahas di bagian Jangan terapkan logika bisnis dalam gabungan jika memungkinkan di halaman ini. Oleh karena itu, jika Anda tidak menambahkan type secara eksplisit, Looker akan menganggap Anda menginginkan LEFT JOIN. Namun, jika Anda memerlukan jenis gabungan lain karena alasan tertentu, Anda dapat melakukannya dengan type.
Untuk penjelasan lengkap, lihat halaman dokumentasi parameter type.
relationship
relationship tidak memiliki dampak langsung pada SQL yang dihasilkan Looker, tetapi sangat penting untuk fungsi Looker yang tepat. Jika Anda tidak menambahkan relationship secara eksplisit, Looker akan menafsirkan hubungan sebagai many-to-one, yang berarti banyak baris di Jelajah dapat memiliki satu baris di tampilan gabungan. Tidak semua gabungan memiliki jenis hubungan ini, dan gabungan dengan hubungan lain harus dideklarasikan dengan benar.
Untuk memahami sepenuhnya, lihat halaman dokumentasi parameter relationship.
Contoh
Gabungkan tampilan bernama customer ke Eksplorasi bernama order dengan hubungan gabungan adalah
FROM order LEFT JOIN customer ON order.customer_id = customer.id:
explore: order {
join: customer {
foreign_key: customer_id
relationship: many_to_one # Could be excluded since many_to_one is the default
type: left_outer # Could be excluded since left_outer is the default
}
}
Gabungkan tampilan bernama address ke Eksplorasi bernama person dengan hubungan gabungan adalah
FROM person LEFT JOIN address ON person.id = address.person_id
AND address.type = 'permanent':
explore: person {
join: address {
sql_on: ${person.id} = ${address.person_id} AND ${address.type} = 'permanent' ;;
relationship: one_to_many
type: left_outer # Could be excluded since left_outer is the default
}
}
Gabungkan tampilan bernama member ke Eksplorasi bernama event dengan hubungan gabungan adalah
FROM event INNER JOIN member ON member.id = event.member_id:
explore: event {
join: member {
sql_on: ${event.member_id} = ${member.id} ;;
relationship: many_to_one # Could be excluded since many_to_one is the default
type: inner
}
}
Tantangan umum
join harus menggunakan nama tampilan, bukan nama tabel pokok
Parameter join hanya mengambil nama tampilan, bukan nama tabel yang terkait dengan tampilan tersebut. Sering kali nama tampilan dan nama tabel identik, yang dapat menyebabkan kesimpulan yang salah bahwa nama tabel dapat digunakan.
Beberapa jenis pengukuran memerlukan agregat simetris
Jika Anda tidak menggunakan agregasi simetris, sebagian besar jenis ukuran dikecualikan dari tampilan gabungan. Agar Looker mendukung agregasi simetris di project Looker Anda, dialek database Anda juga harus mendukungnya. Tabel berikut menunjukkan dialek mana yang mendukung agregat simetris dalam rilis terbaru Looker:
| Dialek | Didukung? |
|---|---|
| Actian Avalanche | |
| Amazon Athena | |
| Amazon Aurora MySQL | |
| Amazon Redshift | |
| Amazon Redshift 2.1+ | |
| Amazon Redshift Serverless 2.1+ | |
| Apache Druid | |
| Apache Druid 0.13+ | |
| Apache Druid 0.18+ | |
| Apache Hive 2.3+ | |
| Apache Hive 3.1.2+ | |
| Apache Spark 3+ | |
| ClickHouse | |
| Cloudera Impala 3.1+ | |
| Cloudera Impala 3.1+ with Native Driver | |
| Cloudera Impala with Native Driver | |
| DataVirtuality | |
| Databricks | |
| Denodo 7 | |
| Denodo 8 & 9 | |
| Dremio | |
| Dremio 11+ | |
| Exasol | |
| Google BigQuery Legacy SQL | |
| Google BigQuery Standard SQL | |
| Google Cloud PostgreSQL | |
| Google Cloud SQL | |
| Google Spanner | |
| Greenplum | |
| HyperSQL | |
| IBM Netezza | |
| MariaDB | |
| Microsoft Azure PostgreSQL | |
| Microsoft Azure SQL Database | |
| Microsoft Azure Synapse Analytics | |
| Microsoft SQL Server 2008+ | |
| Microsoft SQL Server 2012+ | |
| Microsoft SQL Server 2016 | |
| Microsoft SQL Server 2017+ | |
| MongoBI | |
| MySQL | |
| MySQL 8.0.12+ | |
| Oracle | |
| Oracle ADWC | |
| PostgreSQL 9.5+ | |
| PostgreSQL pre-9.5 | |
| PrestoDB | |
| PrestoSQL | |
| SAP HANA | |
| SAP HANA 2+ | |
| SingleStore | |
| SingleStore 7+ | |
| Snowflake | |
| Teradata | |
| Trino | |
| Vector | |
| Vertica |
Tanpa agregat simetris, hubungan gabungan yang bukan satu-ke-satu dapat menghasilkan hasil yang tidak akurat dalam fungsi agregat. Karena ukuran Looker adalah fungsi agregat, hanya ukuran type: count (sebagai COUNT DISTINCT) yang diambil dari gabungan tampilan ke dalam Eksplorasi. Jika memiliki hubungan gabungan satu-ke-satu, Anda dapat menggunakan parameter relationship untuk memaksa jenis ukuran lain disertakan, seperti ini:
explore: person {
join: dna {
sql_on: ${person.dna_id} = ${dna.id} ;;
relationship: one_to_one
}
}
Alasan Looker bekerja dengan cara ini (untuk dialek yang tidak mendukung agregat simetris) dibahas lebih mendetail dalam postingan Komunitas Masalah fanout SQL.
Yang perlu diketahui
Anda dapat menggabungkan tabel yang sama lebih dari sekali menggunakan from
Jika satu tabel berisi berbagai jenis entitas, Anda dapat menggabungkan tampilan ke Eksplorasi lebih dari sekali. Untuk melakukannya, Anda harus menggunakan parameter from. Misalnya, Anda memiliki order Jelajah dan perlu bergabung ke tampilan person dua kali: sekali untuk pelanggan dan sekali untuk perwakilan layanan pelanggan. Anda dapat melakukan hal seperti ini:
explore: order {
join: customer {
from: person
sql_on: ${order.customer_id} = ${customer.id} ;;
}
join: representative {
from: person
sql_on: ${order.representative_id} = ${representative.id} ;;
}
}
Jangan terapkan logika bisnis dalam gabungan jika memungkinkan
Pendekatan Looker standar untuk menggabungkan adalah menggunakan LEFT JOIN jika memungkinkan. Pertimbangkan pendekatan lain jika Anda melakukan sesuatu yang serupa dengan hal-hal berikut:
explore: member_event {
from: event
always_join: [member]
join: member {
sql_on: ${member_event.member_id} = ${member.id} ;;
type: inner
}
}
Dalam contoh ini, kita telah membuat Eksplorasi yang hanya melihat peristiwa yang terkait dengan anggota yang dikenal. Namun, cara yang lebih disarankan untuk menjalankan hal ini di Looker adalah dengan menggunakan LEFT JOIN untuk menggabungkan data peristiwa dan data anggota, seperti ini:
explore: event {
join: member {
sql_on: ${event.member_id} = ${member.id} ;;
}
}
Kemudian, Anda akan membuat dimensi yang dapat disetel ke yes atau no, jika hanya ingin melihat peristiwa anggota, seperti ini:
dimension: is_member_event {
type: yesno
sql: ${member.id} IS NOT NULL ;;
}
Pendekatan ini lebih disukai karena memberikan fleksibilitas kepada pengguna untuk melihat semua acara atau hanya acara anggota, sesuai keinginan mereka. Anda belum memaksanya untuk hanya melihat peristiwa anggota melalui gabungan.
Jika tidak menggunakan agregasi simetris, hindari gabungan yang menyebabkan fanout
Bagian ini hanya berlaku untuk dialek database yang tidak mendukung agregat simetris. Lihat pembahasan agregat simetris di bagian Tantangan umum di halaman ini untuk menentukan apakah dialek Anda mendukung agregat simetris.
Jika dialek database Anda tidak mendukung agregasi simetris, Anda harus menghindari gabungan yang menghasilkan fanout. Dengan kata lain, gabungan yang memiliki hubungan one-to-many antara Eksplorasi dan tampilan umumnya harus dihindari. Sebagai gantinya, gabungkan data dari tampilan dalam tabel turunan untuk membuat hubungan satu-ke-satu dengan Eksplorasi, lalu gabungkan tabel turunan tersebut ke dalam Eksplorasi.
Konsep penting ini dijelaskan lebih lanjut dalam postingan Komunitas Masalah fanout SQL.