Pelajari cara membuat grafik menggunakan tampilan SQL. Dokumen ini memberikan petunjuk langkah demi langkah dan contoh kode untuk menentukan tampilan dan menggunakannya untuk menentukan tabel node dan edge. Pelajari contoh dengan kode contoh yang menunjukkan kasus penggunaan untuk membuat grafik dengan tampilan. Untuk mempelajari lebih lanjut cara menggunakan tampilan untuk membuat grafik properti, termasuk manfaat dan pertimbangan, lihat Ringkasan grafik yang dibuat dari tampilan SQL.
Sebelum memulai
Untuk membuat grafik, Anda harus:
Pastikan lingkungan Spanner Graph Anda disiapkan.
Pahami cara kerja skema Spanner Graph.
Membuat grafik menggunakan tampilan
Untuk membuat grafik menggunakan tampilan:
Tentukan tampilan untuk grafik Anda. Pastikan tampilan Anda mengikuti salah satu pola tampilan yang diperlukan. Untuk mengetahui informasi selengkapnya, lihat Membuat tampilan.
Gunakan tampilan Anda dalam klausa
NODE TABLESdanEDGE TABLESdari pernyataanCREATE PROPERTY GRAPHuntuk membuat grafik.Sertakan klausa
KEYdalam pernyataanCREATE PROPERTY GRAPH. KlausulKEYmenentukan kolom dari tampilan sumber yang secara unik mengidentifikasi setiap elemen grafik.
Contoh: Membuat grafik menggunakan tampilan
Contoh ini membuat tampilan berikut di atas tabel Customer dan Account:
AsiaCustomer, AsiaBankAccount, dan AsiaAccountsOwnership. Kemudian, contoh
menggunakan tampilan ini untuk membuat hal berikut dalam grafik:
Buat tabel node
Customermenggunakan tampilanAsiaCustomer.Buat tabel node
Accountmenggunakan tampilanAsiaBankAccount.Buat tabel tepi
Ownsmenggunakan tampilanAsiaAccountsOwnership. Edge ini menghubungkan nodeCustomerdengan nodeAccount.
Langkah 1: Buat tabel
Pertama, buat tabel data. Kode berikut membuat tabel Customer dan
Account.
CREATE TABLE Customer (
customer_id INT64 NOT NULL,
name STRING(MAX),
address_continent STRING(MAX),
address_country STRING(MAX),
) PRIMARY KEY(customer_id);
CREATE TABLE Account (
account_id INT64 NOT NULL,
customer_id INT64 NOT NULL,
account_type STRING(MAX),
balance INT64,
create_time TIMESTAMP,
address_continent STRING(MAX),
address_country STRING(MAX),
CONSTRAINT FK_CustomerId FOREIGN KEY (customer_id)
REFERENCES Customer (customer_id)
) PRIMARY KEY(account_id);
Langkah 2: Buat tampilan
Selanjutnya, buat tampilan untuk mengubah atau memfilter data dari tabel. Tampilan ini memfilter tabel untuk menyertakan hanya pelanggan dan akun di Asia. Tampilan yang digunakan untuk membuat elemen grafik harus memastikan bahwa baris dalam tampilan bersifat unik.
-- View for 'Customer' nodes, filtered for Asia
CREATE VIEW AsiaCustomer
SQL SECURITY INVOKER AS
SELECT customer.customer_id, customer.name
FROM Customer customer
WHERE LOWER(customer.address_continent) = "asia";
-- View for 'Account' nodes, filtered for Asia.
CREATE VIEW AsiaBankAccount
SQL SECURITY INVOKER AS
SELECT account.account_id, account.balance, account.account_type, account.create_time
FROM Account account
WHERE LOWER(account.address_continent) = "asia";
-- View for 'Owns' edges, connecting customers to accounts in Asia.
CREATE VIEW AsiaAccountsOwnership
SQL SECURITY INVOKER AS
SELECT account.customer_id, account.account_id
FROM Account account
WHERE LOWER(account.address_continent) = "asia";
Langkah 3: Buat grafik properti
Sekarang, buat AsiaFinGraph menggunakan tampilan yang Anda buat. Pernyataan
CREATE PROPERTY GRAPH menyertakan klausa KEY untuk setiap definisi elemen
grafik guna menentukan kolom yang secara unik mengidentifikasi elemen grafik.
CREATE PROPERTY GRAPH AsiaFinGraph
NODE TABLES (
AsiaCustomer AS Customer KEY(customer_id),
AsiaBankAccount AS Account KEY(account_id)
)
EDGE TABLES (
AsiaAccountsOwnership AS Owns
KEY(customer_id, account_id)
SOURCE KEY (customer_id) REFERENCES Customer (customer_id)
DESTINATION KEY (account_id) REFERENCES Account (account_id)
);
Contoh kasus penggunaan
Tampilan SQL menawarkan manfaat dibandingkan menggunakan tabel untuk elemen grafik properti. Contoh berikut menunjukkan beberapa kasus penggunaan untuk menentukan elemen grafik dengan tampilan, bukan tabel.
Contoh: Menerapkan kontrol akses data grafik yang sangat terperinci
Untuk menerapkan keamanan tingkat baris pada data grafik, tentukan tabel node atau edge menggunakan tampilan hak penentu. Tampilan mengekspos subkumpulan data pokok yang diizinkan ke grafik
Misalnya, untuk membatasi akses grafik hanya kepada karyawan di pusat biaya teknik, Anda dapat membuat tampilan EngineerEmployeeView dan memberikan izin SELECT pada tampilan tersebut ke peran engineering_data_reader menggunakan klausa GRANT.
Saat Anda menentukan tabel node grafik menggunakan tampilan ini, pengguna yang menjalankan kueri grafik dengan peran engineering_data_reader hanya dapat melihat baris yang difilter menurut tampilan, yang mencakup karyawan engineering.
-- The table containing all employee data.
CREATE TABLE Employee (
id INT64 NOT NULL,
cost_center STRING(MAX),
job_title STRING(MAX),
office STRING(MAX)
) PRIMARY KEY (id);
-- The definer's rights view that filters for engineering employees.
CREATE VIEW EngineerEmployeeView SQL SECURITY DEFINER AS
SELECT e.id, e.cost_center, e.job_title, e.office
FROM Employee e
WHERE LOWER(e.cost_center) = "engineering";
-- The role that is granted to read the view.
CREATE ROLE engineering_data_reader;
GRANT SELECT ON VIEW EngineerEmployeeView TO ROLE engineering_data_reader;
-- The graph that uses definer's rights view.
CREATE PROPERTY GRAPH EngineeringGraph
NODE TABLES (
EngineerEmployeeView KEY(id)
);
Contoh: Elemen grafik turunan model
Anda dapat menggunakan tampilan untuk menentukan elemen grafik yang memerlukan transformasi data. Manfaat utama adalah tampilan menentukan transformasi, sehingga Anda tidak perlu mengelola tabel terpisah untuk data turunan.
Misalnya, Anda dapat UNNEST data dari kolom ARRAY (atau kolom array dalam kolom JSON) untuk memodelkan beberapa hubungan antar-node dari satu baris.
Dalam contoh skema rantai pasokan berikut, tabel Parts menyimpan daftar
sub-komponen dalam array dependent_parts. Tampilan dapat menggunakan operator UNNEST
untuk mengubah setiap elemen array tersebut menjadi baris yang berbeda. Tampilan ini
kemudian dapat berfungsi sebagai tabel edge, sehingga Anda dapat membuat model edge PartDependsOnPart untuk
merepresentasikan hubungan dependensi antarbagian.
-- Parts table with an ARRAY of dependent parts.
CREATE TABLE Parts (
part_id INT64 NOT NULL,
dependent_parts ARRAY<INT64>
) PRIMARY KEY (part_id);
-- A view that unnests the dependent_parts array.
-- GROUP BY ensures uniqueness for the graph element KEY.
CREATE VIEW PartDependsOnPart SQL SECURITY INVOKER AS
SELECT p.part_id, dependent_part_id
FROM Parts AS p,
UNNEST(p.dependent_parts) AS dependent_part_id
GROUP BY p.part_id, dependent_part_id;
-- Graph modeling the part dependency relationship.
CREATE PROPERTY GRAPH SupplyChainGraph
NODE TABLES (
Parts
)
EDGE TABLES (
PartDependsOnPart KEY (part_id, dependent_part_id)
SOURCE KEY (part_id) REFERENCES Parts(part_id)
DESTINATION KEY (dependent_part_id) REFERENCES Parts(part_id)
);
Contoh: Transisi data tanpa skema
Pengelolaan data tanpa skema memungkinkan Anda membuat definisi grafik yang fleksibel tanpa jenis node dan edge yang telah ditentukan sebelumnya. Meskipun pengelolaan data tanpa skema memberikan fleksibilitas, Anda mungkin perlu beralih ke struktur yang lebih formal saat data Anda menjadi lebih jelas. Struktur yang lebih formal mengekspos hubungan node dan edge, label, serta properti grafik dalam skema, yang mengurangi kebutuhan akan eksplorasi data manual untuk memahami skema grafik.
Anda dapat menggunakan tampilan untuk memformalkan jenis node dan tepi tanpa memigrasikan data pokok. Misalnya, Anda dapat bertransisi dari model tanpa skema umum yang menggunakan tabel GraphNode dan GraphEdge kanonis. Untuk melakukannya, Anda membuat
tampilan yang mengekstrak data dari tabel tanpa skema:
Tentukan tampilan untuk setiap jenis node dan tepi yang ingin Anda formalisasikan (misalnya,
PersonatauWorksFor). Dalam tampilan, filter data menurut labelnya (misalnya,WHERE n_label = "person") dan tetapkan properti dari kolom JSON ke jenis data tertentu (misalnya,STRING(prop.name) AS name).Tentukan grafik properti baru tempat
NODE TABLESdanEDGE TABLESmereferensikan tampilan berjenis yang baru saja Anda buat.
Grafik tanpa skema memberikan performa yang lebih baik daripada grafik yang diformalisasi untuk beberapa kueri (misalnya, pola jalur yang dikuantifikasi dengan beberapa jenis tepi). Jika metadata yang diformalkan penting untuk kasus penggunaan Anda, Anda dapat menggunakan tampilan untuk bertransisi dari grafik tanpa skema ke skema yang diketik. Anda juga dapat memilih untuk menggunakan grafik tanpa skema untuk beberapa kasus penggunaan dan grafik skema berjenis untuk kasus penggunaan lainnya. Untuk mengetahui informasi selengkapnya, lihat Memilih desain skema berdasarkan kueri grafik.
Contoh berikut menunjukkan alur kerja untuk bertransisi dari grafik tanpa skema ke grafik yang diformalisasi dalam empat langkah:
Tentukan tabel
GraphNodedanGraphEdgekanonis untuk model tanpa skema.Buat grafik awal yang fleksibel pada tabel tanpa skema tersebut.
Tentukan tampilan yang diketik (
Person,Company,WorksFor) yang mengekstrak dan memformalkan data dari tabel tanpa skema.Buat grafik akhir yang memiliki jenis yang kuat yang menggunakan tampilan ini sebagai tabel node dan tepinya.
-- 1. Create the canonical tables for a schemaless model.
CREATE TABLE GraphNode (
id INT64 NOT NULL,
label STRING(MAX) NOT NULL,
properties JSON
) PRIMARY KEY (id);
CREATE TABLE GraphEdge (
id INT64 NOT NULL,
dest_id INT64 NOT NULL,
edge_id INT64 NOT NULL,
label STRING(MAX) NOT NULL,
properties JSON
) PRIMARY KEY (id, dest_id, edge_id),
INTERLEAVE IN PARENT GraphNode;
-- 2. Define a schemaless graph.
CREATE PROPERTY GRAPH FinGraph
NODE TABLES (
GraphNode
DYNAMIC LABEL (label)
DYNAMIC PROPERTIES (properties)
)
EDGE TABLES (
GraphEdge
SOURCE KEY (id) REFERENCES GraphNode(id)
DESTINATION KEY (dest_id) REFERENCES GraphNode(id)
DYNAMIC LABEL (label)
DYNAMIC PROPERTIES (properties)
);
-- 3. Define typed views that extract and formalize the data.
-- Convert JSON fields to primitive types (for example, INT64, STRING) to
-- ensure type safety.
CREATE VIEW Person SQL SECURITY INVOKER AS
SELECT n.id, STRING(n.properties.name) AS name, INT64(n.properties.age) AS age
FROM GraphNode n WHERE n.label = "person";
CREATE VIEW Company SQL SECURITY INVOKER AS
SELECT n.id, STRING(n.properties.name) AS company_name, BOOL(n.properties.is_public) AS is_public
FROM GraphNode n WHERE n.label = "company";
CREATE VIEW WorksFor SQL SECURITY INVOKER AS
SELECT e.id AS person_id, e.dest_id AS company_id, e.edge_id AS edge_id, STRING(e.properties.since) AS since
FROM GraphEdge e
WHERE e.label = "worksfor";
-- 4. Create the final, formalized graph from the typed views.
CREATE PROPERTY GRAPH typed_formalized_graph
NODE TABLES (
Person KEY(id)
PROPERTIES (name, age),
Company KEY(id)
PROPERTIES (company_name, is_public)
)
EDGE TABLES(
WorksFor KEY(person_id, company_id, edge_id)
SOURCE KEY (person_id) REFERENCES Person(id)
DESTINATION KEY (company_id) REFERENCES Company(id)
PROPERTIES (since)
);
Langkah berikutnya
Pelajari skema Spanner Graph.
Pelajari praktik terbaik untuk mendesain skema Spanner Graph.