Membuat grafik dari tampilan SQL

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:

  1. Pastikan lingkungan Spanner Graph Anda disiapkan.

  2. Pahami cara kerja skema Spanner Graph.

Membuat grafik menggunakan tampilan

Untuk membuat grafik menggunakan tampilan:

  1. Tentukan tampilan untuk grafik Anda. Pastikan tampilan Anda mengikuti salah satu pola tampilan yang diperlukan. Untuk mengetahui informasi selengkapnya, lihat Membuat tampilan.

  2. Gunakan tampilan Anda dalam klausa NODE TABLES dan EDGE TABLES dari pernyataan CREATE PROPERTY GRAPH untuk membuat grafik.

  3. Sertakan klausa KEY dalam pernyataan CREATE PROPERTY GRAPH. Klausul KEY menentukan 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 Customer menggunakan tampilan AsiaCustomer.

  • Buat tabel node Account menggunakan tampilan AsiaBankAccount.

  • Buat tabel tepi Owns menggunakan tampilan AsiaAccountsOwnership. Edge ini menghubungkan node Customer dengan node Account.

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:

  1. Tentukan tampilan untuk setiap jenis node dan tepi yang ingin Anda formalisasikan (misalnya, Person atau WorksFor). 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).

  2. Tentukan grafik properti baru tempat NODE TABLES dan EDGE TABLES mereferensikan 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:

  1. Tentukan tabel GraphNode dan GraphEdge kanonis untuk model tanpa skema.

  2. Buat grafik awal yang fleksibel pada tabel tanpa skema tersebut.

  3. Tentukan tampilan yang diketik (Person, Company, WorksFor) yang mengekstrak dan memformalkan data dari tabel tanpa skema.

  4. 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