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 Eksplorasi dan tampilan, sehingga Anda dapat menggabungkan data dari beberapa tampilan. Anda dapat menggabungkan sebanyak mungkin tampilan yang Anda inginkan untuk Eksplorasi tertentu.
Ingatlah bahwa setiap tampilan dikaitkan dengan tabel di database Anda, atau tabel turunan yang telah Anda tentukan di Looker. Demikian pula, karena Eksplorasi dikaitkan dengan tampilan, Eksplorasi juga terhubung ke tabel dari beberapa jenis.
Tabel yang terkait dengan Eksplorasi 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 gabungan utama
Untuk menentukan hubungan gabungan (klausa SQL ON) antara Eksplorasi dan tampilan, Anda harus menggunakan join bersama dengan parameter lainnya.
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 klausaFROMkueri SQL yang dihasilkan. - Setiap parameter
joinmenentukan klausaJOINkueri SQL yang dihasilkan.- Parameter
typemenentukan jenis gabungan SQL. - Parameter
sql_ondan parameterforeign_keymenentukan klausaONkueri SQL yang dihasilkan.
- Parameter
sql_on
sql_on memungkinkan Anda membuat hubungan gabungan dengan menulis klausa SQL ON secara langsung. Parameter ini dapat melakukan gabungan 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 gabungan, dan menghubungkannya dengan dimensi di Eksplorasi. Pola ini sangat umum dalam desain database, dan foreign_key adalah cara yang elegan 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 lengkapnya, lihat halaman documentasi 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 Eksplorasi 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
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
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
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 dasar
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 tampilan gabungan. Agar Looker mendukung agregat simetris di project Looker Anda, dialek database Anda juga harus mendukungnya. Tabel berikut menunjukkan dialek mana yang mendukung agregat simetris dalam rilis Looker terbaru:
| 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 | |
| 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 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 | |
| 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 membuat hasil yang tidak akurat dalam fungsi agregat. Karena ukuran Looker adalah fungsi agregat, hanya ukuran type: count (sebagai COUNT DISTINCT) yang diambil dari tampilan gabungan ke Eksplorasi. Jika Anda memiliki hubungan gabungan 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 berfungsi seperti ini (untuk dialek yang tidak mendukung agregat simetris) dibahas lebih mendetail dalam Masalah fanout SQL postingan Komunitas.
Yang perlu diketahui
Anda dapat menggabungkan tabel yang sama lebih dari sekali menggunakan from
Jika satu tabel berisi berbagai jenis entity, Anda dapat menggabungkan tampilan ke Eksplorasi lebih dari sekali. Untuk melakukannya, Anda harus menggunakan parameter from. Misalnya, Anda memiliki Eksplorasi order dan perlu menggabungkan tampilan person ke dalamnya 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 gabungan adalah menggunakan LEFT JOIN jika memungkinkan. Pertimbangkan pendekatan lain 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, kita telah membuat Eksplorasi yang hanya melihat peristiwa yang terkait dengan anggota yang dikenal. Namun, cara yang lebih disukai untuk mengeksekusi hal ini di Looker adalah menggunakan LEFT JOIN untuk mendapatkan data peristiwa dan data anggota yang digabungkan, 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 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 peristiwa, atau hanya peristiwa anggota, sesuai keinginan mereka. Anda tidak memaksa mereka untuk hanya melihat peristiwa anggota melalui gabungan.
Jika tidak menggunakan agregat simetris, hindari gabungan yang menyebabkan fanout
Bagian ini hanya berlaku untuk dialek database yang tidak mendukung agregat simetris. Lihat pembahasan tentang 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 satu-ke-banyak 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.