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 Explore dan tampilan, sehingga Anda dapat menggabungkan data dari beberapa tampilan. Anda dapat menggabungkan tabel virtual sebanyak yang Anda inginkan untuk Eksplorasi tertentu.
Ingat bahwa setiap tabel virtual dikaitkan dengan tabel dalam database Anda, atau tabel turunan yang telah Anda tentukan di Looker. Demikian pula, karena Eksplorasi dikaitkan dengan tabel virtual, Eksplorasi juga terhubung ke tabel tertentu.
Tabel yang terkait dengan Explore ditempatkan ke dalam klausa FROM SQL yang dihasilkan Looker. Tabel yang terkait dengan tampilan gabungan ditempatkan ke dalam klausa JOIN SQL yang dihasilkan Looker.
Parameter join utama
Untuk menentukan hubungan gabungan (klausa ON SQL) antara Eksplorasi dan tabel virtual, Anda harus menggunakan join bersama dengan parameter lainnya.
Anda harus menggunakan salah satu parameter sql_on atau foreign_key untuk membuat klausa ON SQL.
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 klausaFROMdari kueri SQL yang dihasilkan. - Setiap parameter
joinmenentukan klausaJOINdari kueri SQL yang dihasilkan.- Parameter
typemenentukan jenis SQL join. - Parameter
sql_ondan parameterforeign_keymenentukan klausaONdari kueri SQL yang dihasilkan.
- Parameter
sql_on
sql_on memungkinkan Anda membuat hubungan gabungan dengan menulis klausa ON SQL secara langsung. Fungsi ini dapat melakukan penggabungan yang sama seperti 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 tabel virtual yang digabungkan, dan menghubungkannya dengan dimensi di Explore. Pola ini sangat umum dalam desain database, dan foreign_key adalah cara yang elegan untuk mengekspresikan penggabungan dalam kasus ini.
Untuk pemahaman yang lengkap, lihat halaman dokumentasi parameter foreign_key.
type
Sebagian besar gabungan di Looker adalah LEFT JOIN karena alasan yang dibahas di bagian Jangan menerapkan logika bisnis dalam gabungan jika memungkinkan di halaman ini. Oleh karena itu, jika Anda tidak menambahkan type secara eksplisit, Looker akan mengasumsikan bahwa Anda menginginkan LEFT JOIN. Namun, jika Anda memerlukan jenis join 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 tersebut sebagai many-to-one, yang berarti banyak baris di Explore dapat memiliki satu baris di tabel virtual yang digabungkan. Tidak semua join memiliki jenis hubungan ini, dan join dengan hubungan lain harus dideklarasikan dengan benar.
Untuk pemahaman yang lengkap, lihat halaman dokumentasi parameter relationship.
Contoh
Gabungkan tabel virtual bernama customer ke Eksplorasi bernama order dengan hubungan gabungan
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 tabel virtual bernama address ke Eksplorasi bernama person dengan hubungan gabungan
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 tabel virtual bernama member ke Eksplorasi bernama event dengan hubungan gabungan
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 menggunakan 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 ukuran memerlukan agregat simetris
Jika Anda tidak menggunakan agregat simetris, sebagian besar jenis ukuran akan dikecualikan dari tabel virtual gabungan. Agar Looker dapat mendukung agregat simetris di project Looker Anda, dialek database Anda juga harus mendukungnya. Tabel berikut menunjukkan dialek 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.x - 0.17.x | |
| Apache Druid 0.18+ | |
| Apache Hive 2.3+ | |
| Apache Hive 3.1.2+ | |
| Apache Spark 3+ | |
| ClickHouse | |
| ClickHouse 26+ | |
| 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+ | |
| Dremio 26+ with Arrow Flight SQL | |
| Exasol | |
| Google BigQuery Legacy SQL | |
| Google BigQuery Standard SQL | |
| Google Cloud AlloyDB for PostgreSQL | |
| 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 | |
| MongoSQL | |
| 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 tidak bersifat 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 dibawa dari tabel yang digabungkan ke dalam Eksplorasi. Jika memiliki hubungan join satu ke satu, Anda dapat menggunakan parameter relationship untuk memaksa jenis ukuran lainnya 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 secara 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 tabel virtual ke Eksplorasi lebih dari sekali. Untuk melakukannya, Anda harus menggunakan parameter from. Misalkan Anda memiliki Explore order dan perlu menggabungkan tabel virtual person ke dalamnya dua kali: sekali untuk pelanggan dan sekali untuk customer service representative. 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 menerapkan logika bisnis dalam penggabungan jika memungkinkan
Pendekatan Looker standar untuk penggabungan adalah menggunakan LEFT JOIN jika memungkinkan. Pertimbangkan pendekatan yang berbeda jika Anda melakukan 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, kami telah membuat Eksplorasi yang hanya melihat peristiwa yang terkait dengan anggota yang diketahui. Namun, cara yang lebih disukai untuk menjalankannya di Looker adalah 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 ditetapkan ke yes atau no, jika Anda hanya ingin melihat acara anggota, seperti ini:
dimension: is_member_event {
type: yesno
sql: ${member.id} IS NOT NULL ;;
}
Pendekatan ini lebih disukai karena memberi pengguna fleksibilitas untuk melihat semua acara, atau hanya acara anggota, sesuai keinginan mereka. Anda belum memaksa mereka untuk hanya melihat peristiwa anggota melalui join.
Jika tidak menggunakan agregat 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 agregat simetris, Anda harus menghindari gabungan yang menghasilkan fanout. Dengan kata lain, gabungan yang memiliki hubungan one-to-many antara Eksplorasi dan tabel virtual umumnya harus dihindari. Sebagai gantinya, gabungkan data dari tabel virtual dalam tabel turunan untuk membuat hubungan satu ke satu dengan Explore, lalu gabungkan tabel turunan tersebut ke dalam Explore.
Konsep penting ini dijelaskan lebih lanjut dalam postingan Komunitas Masalah fanout SQL.