Verwendung von SQL-Befehlen zum Erstellen und Verwalten semantischer Ansichten¶

Definieren der logischen Tabellen¶

Verwenden Sie im Befehl CREATE SEMANTIC VIEW die Klausel TABLES, um die logischen Tabellen in der Ansicht zu definieren. In dieser Klausel können Sie:

• Geben Sie den Namen der physischen Tabelle und einen optionalen Alias an.

• Identifizieren Sie die folgenden Spalten in der logischen Tabelle:

  • Spalten, die als Primärschlüssel dienen.

  • Spalten, die eindeutige Werte enthalten (andere als die Primärschlüsselspalten).

  Sie können diese Spalten verwenden, um Beziehungen in dieser semantischen Ansicht zu definieren.

• Fügen Sie Synonyme für die Tabelle hinzu (für eine bessere Auffindbarkeit).

• Fügen Sie einen beschreibenden Kommentar hinzu.

In dem zuvor vorgestellten Beispiel definiert die Klausel TABLES drei logische Tabellen:

• Eine Tabelle orders, die die Bestellinformationen aus der Tabelle TPC-H orders enthält.

• Eine Tabelle customers, die die Kundeninformationen aus der Tabelle TPC-H customers enthält.

• Eine Tabelle line_items, die die Einzelposten in Bestellungen aus der Tabelle TPC-H lineitem enthält.

In dem Beispiel wird die PRIMARY KEY-Klausel verwendet, um die Spalten zu identifizieren, die als Primärschlüssel für jede logische Tabelle verwendet werden sollen. Primärschlüssel und eindeutige Werte helfen bei der Bestimmung der Typen von Beziehungen zwischen den Tabellen (z. B. viele-zu-eins oder eins-zu-eins).

Das Beispiel enthält auch Synonyme und Kommentare, die die logischen Tabellen beschreiben und die Daten leichter auffindbar machen.

TABLES (
  orders AS SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.ORDERS
    PRIMARY KEY (o_orderkey)
    WITH SYNONYMS ('sales orders')
    COMMENT = 'All orders table for the sales domain',
  customers AS SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.CUSTOMER
    PRIMARY KEY (c_custkey)
    COMMENT = 'Main table for customer data',
  line_items AS SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.LINEITEM
    PRIMARY KEY (l_orderkey, l_linenumber)
    COMMENT = 'Line items in orders'
)

Identifizierung der Beziehungen zwischen logischen Tabellen¶

Verwenden Sie im Befehl CREATE SEMANTIC VIEW die RELATIONSHIPS-Klausel, um die Beziehungen zwischen den Tabellen in der Ansicht zu identifizieren. Für jede Beziehung geben Sie Folgendes an:

• Einen optionalen Namen für die Beziehung.

• Den Namen der logischen Tabelle, die den Fremdschlüssel enthält.

• Die Spalten in dieser Tabelle, die den Fremdschlüssel definieren.

• Den Namen der logischen Tabelle, die den Primärschlüssel oder Spalten mit eindeutigen Werten enthält.

• Die Spalten in dieser Tabelle, die den Primärschlüssel definieren oder eindeutige Werte enthalten.

  • Wenn Sie in der Klausel TABLES bereits PRIMARY KEY für die logische Tabelle angegeben haben, müssen Sie die Primärschlüsselspalte in der Beziehung nicht angeben.

  • Wenn es in der Klausel TABLES ein einziges UNIQUE-Schlüsselwort für die logische Tabelle gibt, müssen Sie die entsprechenden Spalten in der Beziehung nicht angeben.

  Sie können auch ein Datum, eine Uhrzeit, einen Zeitstempel oder eine numerische Spalte angeben, wenn Sie die Spalten eines Bereichs verknüpfen möchten.

In dem zuvor vorgestellten Beispiel gibt die Klausel RELATIONSHIPS zwei Beziehungen an:

• Eine Beziehung zwischen den Tabellen orders und customers. In der Tabelle orders ist o_custkey der Fremdschlüssel, der sich auf den Primärschlüssel in der Tabelle customers (c_custkey) bezieht.

• Eine Beziehung zwischen den Tabellen line_items und orders. In der Tabelle line_items ist l_orderkey der Fremdschlüssel, der sich auf den Primärschlüssel in der Tabelle orders (o_orderkey) bezieht.

RELATIONSHIPS (
  orders_to_customers AS
    orders (o_custkey) REFERENCES customers (c_custkey),
  line_item_to_orders AS
    line_items (l_orderkey) REFERENCES orders (o_orderkey)
)

Verwenden eines Datums, einer Uhrzeit, eines Zeitstempels oder eines Zahlenbereichs zum Verknüpfen logischer Tabellen¶

Wenn Sie eine Beziehung zwischen zwei logischen Tabellen angeben, werden die Tabellen standardmäßig mit einer Gleichheitsbedingung verknüpft.

Wenn Sie zwei logische Tabellen über einen Datums-, Uhrzeit-, Zeitstempel- oder Zahlenbereich verknüpfen müssen (wobei die Werte in einer Spalte einer Tabelle im gleichen Bereich liegen müssen wie die Werte in einer Spalte einer anderen Tabelle), können Sie das ASOF-Schlüsselwort mit dem Spaltennamen in der REFERENCES-Klausel angeben:

RELATIONSHIPS(
  my_relationship AS
    logical_table_1(
      col_table_1
    )
    REFERENCES
    logical_table_2(
      ASOF col_table_2
    )
)

Eine Abfrage der oben definierten semantischen Ansicht erzeugt einen ASOF JOIN, der den >= Vergleichsoperator in der MATCH_CONDITION-Klausel verwendet. Dadurch werden die beiden Tabellen so verknüpft, dass die Werte in col_table_1 größer als die Werte in col_table_2 oder gleich sind:

...
FROM logical_table_1 ASOF JOIN logical_table_2
  MATCH_CONDITION(
    logical_table_1.col_table_1 >= logical_table_2.col_table_2
  )
...

Sie können das ASOF-Schlüsselwort für Spalten desselben Typs verwenden, den Sie auch für ASOF JOIN nutzen.

Angenommen, Sie haben Tabellen mit Kunden-, Kundenadress- und Bestelldaten:

CREATE OR REPLACE TABLE customer(
  c_cust_id VARCHAR,
  c_first_name VARCHAR,
  c_last_name VARCHAR);

INSERT INTO customer VALUES
  ('cust001', 'Mary', 'Smith'),
  ('cust002', 'Bill', 'Wilson');

CREATE OR REPLACE TABLE customer_address(
  ca_cust_id VARCHAR,
  ca_zipcode VARCHAR,
  ca_street_addr VARCHAR,
  ca_start_date DATE,
  ca_end_date DATE
);

INSERT INTO customer_address VALUES
  ('cust001', '94025', '100 Main Street', '2024-01-01', '2024-03-31'),
  ('cust001', '94026', '200 Main Street', '2024-04-01', '2024-06-30'),
  ('cust001', '94027', '300 Main Street', '2024-07-01', NULL),
  ('cust002', '94028', '400 Main Street', '2024-01-01', '2024-04-30'),
  ('cust002', '94029', '500 Main Street', '2024-05-01', '2024-07-31'),
  ('cust002', '94030', '600 Main Street', '2024-08-01', NULL);

CREATE OR REPLACE TABLE orders(
  o_ord_id VARCHAR,
  o_cust_id VARCHAR,
  o_ord_date DATE,
  o_amount NUMBER
);

INSERT INTO orders VALUES
  ('ord100', 'cust001', '2024-02-01', 100),
  ('ord101', 'cust001', '2024-02-02', 200),
  ('ord102', 'cust001', '2024-05-01', 300),
  ('ord103', 'cust001', '2024-05-02', 400),
  ('ord104', 'cust001', '2024-08-01', 500),
  ('ord105', 'cust001', '2024-08-02', 600),
  ('ord106', 'cust002', '2024-03-01', 100),
  ('ord107', 'cust002', '2024-03-02', 200),
  ('ord108', 'cust002', '2024-06-01', 300),
  ('ord109', 'cust002', '2024-06-02', 400),
  ('ord110', 'cust002', '2024-09-01', 500),
  ('ord111', 'cust002', '2024-09-02', 600);

In diesem Beispiel hat die Tabelle customer_address hat die Spalte ca_start_date, die angibt, seit wann die Kundin oder der Kunde an der angegebenen Adresse ansässig ist. Die Tabelle orders hat die Spalte o_ord_date mit dem Datum der Bestellung.

Angenommen, Sie möchten Informationen zu Kundenaufträgen abfragen und die Postleitzahlen abrufen, die dem Standort der Kundin/des Kunden zum Zeitpunkt der Auftragsausführung entsprechen.

Sie können eine semantische Ansicht definieren, die eine ASOF-Verknüpfung zwischen den Spalten ca_start_date und o_ord_date angibt:

CREATE OR REPLACE SEMANTIC VIEW customer_orders_view
  TABLES (
    customer_address UNIQUE (ca_cust_id, ca_start_date),
    customer UNIQUE (c_cust_id),
    orders UNIQUE (o_ord_id)
  )
  RELATIONSHIPS (
    customer_address(ca_cust_id) REFERENCES customer,
    -- Defines an ASOF JOIN on the date columns.
    orders(o_cust_id, o_ord_date)
      REFERENCES
        customer_address(ca_cust_id, ASOF ca_start_date)
  )
  FACTS (
    customer_address.f_zipcode AS ca_zipcode
  )
  DIMENSIONS (
    -- Relies on the ASOF join to retrieve the zip code
    -- where the order date is greater than or equal to
    -- the address starting date.
    orders.f_cust_zipcode AS customer_address.f_zipcode,
    orders.dim_year_month AS DATE_TRUNC('month', o_ord_date)
  )
  METRICS (
    orders.m_order_amount AS SUM(o_amount)
  );

Angenommen, Sie führen eine Abfrage dieser semantischen Ansicht durch, um die Summe der Bestellbeträge pro Monat für jede Postleitzahl zu ermitteln:

SELECT * FROM SEMANTIC_VIEW(
  customer_orders_view
  DIMENSIONS orders.dim_year_month, orders.f_cust_zipcode
  METRICS orders.m_order_amount
);

+----------------+----------------+----------------+
| DIM_YEAR_MONTH | F_CUST_ZIPCODE | M_ORDER_AMOUNT |
|----------------+----------------+----------------|
| 2024-02-01     | 94025          |            300 |
| 2024-05-01     | 94026          |            700 |
| 2024-08-01     | 94027          |           1100 |
| 2024-03-01     | 94028          |            300 |
| 2024-09-01     | 94030          |           1100 |
| 2024-06-01     | 94029          |            700 |
+----------------+----------------+----------------+

Die Abfrage verwendet im Endeffekt einen ASOF JOIN zur Verknüpfung der Tabellen über die Datumsspalten, wobei das Bestelldatum nicht vor dem Startdatum der Adresse liegen darf:

...
FROM orders ASOF JOIN customer_address
  MATCH_CONDITION(
    orders.o_ord_date >= customer_address.ca_start_date
  )
  ON
    orders.o_cust_id = customer_address.ca_cust_id
...

Verknüpfen logischer Tabellen, die Wertebereiche enthalten¶

Sie können eine Bereichsverknüpfung verwenden, wenn Sie eine Tabelle mit einer anderen Tabelle verknüpfen möchten, die einen Bereich von möglichen Werten in der ersten Tabelle definiert. Angenommen, eine Tabelle repräsentiert die Kundenaufträge und enthält eine Spalte mit dem Zeitstempel, wann die Bestellung erteilt wurde. Angenommen, eine andere Tabelle repräsentiert die Geschäftsquartale und enthält die unterschiedlichen Zeitbereiche, die diese Quartale darstellen. Sie können eine semantische Ansicht erstellen, die die beiden Tabellen so verknüpft, dass die Zeile für einen Auftrag das Geschäftsquartal enthält, in dem der Auftrag erteilt wurde.

In der Tabelle, die die Bereiche enthält, muss jeder Bereich eindeutig sein. Es können sich keine zwei Bereiche überschneiden.

Wenn Sie in den Tabellendaten den niedrigstmöglichen Wert für den Bereich oder den höchstmöglichen Wert für den Bereich angeben möchten, verwenden Sie NULL.

Die folgende Tabelle definiert zum Beispiel eine Menge von Zeitbereichen, die sich nicht überschneiden:

• Die erste Zeile deckt den Bereich ab, der alles bis (aber nicht einschließlich) zum 1. Januar 2024 umfasst.

• Die letzte Zeile deckt den Bereich ab, der alles ab dem 20. März 2024 umfasst.

+----------------+------------------+-------------------------+-------------------------+
| TIME_PERIOD_ID | TIME_PERIOD_NAME | START_TIME              | END_TIME                |
|----------------+------------------+-------------------------+-------------------------|
|              1 | Before_January   | NULL                    | 2024-01-01 00:00:00.000 |
|              2 | Early_January    | 2024-01-01 00:00:00.000 | 2024-01-15 00:00:00.000 |
|              3 | Late_January     | 2024-01-15 00:00:00.000 | 2024-02-01 00:00:00.000 |
|              4 | Early_February   | 2024-02-01 00:00:00.000 | 2024-02-15 00:00:00.000 |
|              5 | Late_February    | 2024-02-15 00:00:00.000 | 2024-03-01 00:00:00.000 |
|              6 | Early_March      | 2024-03-01 00:00:00.000 | 2024-03-20 00:00:00.000 |
|              7 | After_March20    | 2024-03-20 00:00:00.000 | NULL                    |
+----------------+------------------+-------------------------+-------------------------+

Für Fälle wie diese können Sie eine semantische Ansicht einrichten, die Bereichsverknüpfungsabfragen unterstützt. Wenn Sie die semantische Ansicht erstellen, müssen Sie Folgendes tun:

1. Definieren Sie für die logische Tabelle, die die Start- und Endzeiten eines Zeitraums enthält, eine Einschränkung, die angibt, dass sich keine zwei Bereiche überlappen können.

   Geben Sie der TABLE-Klausel des Befehls CREATE SEMANTIC VIEW die CONSTRAINT-Klausel in der Definition der logischen Tabelle an. Die Syntax finden Sie in der Dokumentation für CONSTRAINT im Thema zu CREATE SEMANTIC VIEW.

2. Definieren Sie eine Beziehung zwischen der Spalte, die den Zeitstempel in einer Tabelle enthält, und den Spalten für Start- und Endzeit in der anderen Tabelle.

   Verwenden Sie in der RELATIONSHIPS-Klausel des Befehls CREATE SEMANTIC VIEW die BETWEEN-Klausel, um die Spalten anzugeben, die die Start- und Endzeiten enthalten. Die Syntax finden Sie in der Dokumentation für RELATIONSHIP im Thema zu CREATE SEMANTIC VIEW.

Angenommen, die Tabelle my_time_periods definiert bestimmte Zeiträume:

CREATE OR REPLACE TABLE my_time_periods (
  time_period_id INT PRIMARY KEY,
  time_period_name VARCHAR(50),
  start_time TIMESTAMP,
  end_time TIMESTAMP
);

INSERT INTO my_time_periods (
    time_period_id, time_period_name, start_time, end_time
  ) VALUES
    (1, 'Before_January', NULL, '2024-01-01 00:00:00'::TIMESTAMP),
    (2, 'Early_January', '2024-01-01 00:00:00'::TIMESTAMP, '2024-01-15 00:00:00'::TIMESTAMP),
    (3, 'Late_January', '2024-01-15 00:00:00'::TIMESTAMP, '2024-02-01 00:00:00'::TIMESTAMP),
    (4, 'Early_February', '2024-02-01 00:00:00'::TIMESTAMP, '2024-02-15 00:00:00'::TIMESTAMP),
    (5, 'Late_February', '2024-02-15 00:00:00'::TIMESTAMP, '2024-03-01 00:00:00'::TIMESTAMP),
    (6, 'Early_March', '2024-03-01 00:00:00'::TIMESTAMP, '2024-03-20 00:00:00'::TIMESTAMP),
    (7, 'After_March20', '2024-03-20 00:00:00'::TIMESTAMP, NULL);

Angenommen, die Tabelle my_events erfasst Ereignisse, die innerhalb dieser Zeiträume aufgetreten sind:

CREATE OR REPLACE TABLE my_events (
  event_id INTEGER PRIMARY KEY,
  event_timestamp TIMESTAMP,
  event_name VARCHAR
);

INSERT INTO my_events (event_id, event_name, event_timestamp) VALUES
  (1, 'Login', '2024-01-15 10:00:00'::TIMESTAMP),
  (2, 'Purchase', '2024-01-15 14:30:00'::TIMESTAMP),
  (3, 'Logout', '2024-01-15 18:45:00'::TIMESTAMP),
  (4, 'Review', '2024-02-10 12:00:00'::TIMESTAMP),
  (5, 'Support', '2024-02-20 09:30:00'::TIMESTAMP),
  (6, 'Upgrade', '2024-03-05 16:00:00'::TIMESTAMP),
  (7, 'Feedback', '2024-03-25 11:00:00'::TIMESTAMP);

Sie können eine semantische Ansicht definieren, die die Tabellen verknüpft. Zeilen in my_events werden mit Zeilen in my_time_periods verknüpft, wobei der Wert in Spalte event_timestamp in``my_events`` innerhalb des durch die Spalten start_time und end_time in my_time_periods angegebene Bereichs liegt.

CREATE OR REPLACE SEMANTIC VIEW my_semantic_view_range_join
  TABLES (
    my_events PRIMARY KEY (event_id),
    my_time_periods UNIQUE (start_time, end_time)
      CONSTRAINT my_time_period_range DISTINCT RANGE BETWEEN start_time AND end_time EXCLUSIVE
  )
  RELATIONSHIPS (
    my_time_periods_for_events AS
      my_events(event_timestamp) REFERENCES
        my_time_periods(BETWEEN start_time AND end_time EXCLUSIVE)
  )
  DIMENSIONS (
    my_events.dim_event_name AS event_name,
    my_events.dim_event_timestamp AS event_timestamp,
    my_time_periods.dim_time_period_name AS time_period_name
  )
  METRICS (
    my_events.m_event_count AS COUNT(*)
  );

Die folgende Abfrage veranschaulicht, wie die Zeilen verknüpft werden:

SELECT
    sv.dim_event_name,
    sv.dim_event_timestamp,
    sv.dim_time_period_name,
    sv.m_event_count
  FROM SEMANTIC_VIEW(
    my_semantic_view_range_join
    METRICS my_events.m_event_count
    DIMENSIONS
      my_events.dim_event_name,
      my_events.dim_event_timestamp,
      my_time_periods.dim_time_period_name
  ) AS sv
  ORDER BY
    sv.dim_event_timestamp,
    sv.dim_time_period_name;

+----------------+-------------------------+----------------------+---------------+
| DIM_EVENT_NAME | DIM_EVENT_TIMESTAMP     | DIM_TIME_PERIOD_NAME | M_EVENT_COUNT |
|----------------+-------------------------+----------------------+---------------|
| Login          | 2024-01-15 10:00:00.000 | Late_January         |             1 |
| Purchase       | 2024-01-15 14:30:00.000 | Late_January         |             1 |
| Logout         | 2024-01-15 18:45:00.000 | Late_January         |             1 |
| Review         | 2024-02-10 12:00:00.000 | Early_February       |             1 |
| Support        | 2024-02-20 09:30:00.000 | Late_February        |             1 |
| Upgrade        | 2024-03-05 16:00:00.000 | Early_March          |             1 |
| Feedback       | 2024-03-25 11:00:00.000 | After_March20        |             1 |
+----------------+-------------------------+----------------------+---------------+

Wie in den Beispielen gezeigt, ist die dim_time_period_name-Dimension für jede Zeile in den Ergebnissen der Name des Zeitraums, in den die dim_event_timestamp-Dimension fällt.

Definition von Fakten, Dimensionen und Metriken¶

Verwenden Sie im Befehl CREATE SEMANTIC VIEW die Klauseln FACTS, DIMENSIONS und METRICS, um die Fakten, Dimensionen und Metriken in der semantischen Ansicht zu definieren.

Sie müssen mindestens eine Dimension oder Metrik in der semantischen Ansicht definieren.

Für jeden Fakt, jede Dimension oder Metrik, geben Sie an:

• Die logische Tabelle, zu der sie gehört.

  Bemerkung

  Wenn Sie eine abgeleitete Metrik definieren möchten (eine Metrik, die nicht für eine logische Tabelle spezifisch ist), müssen Sie den Namen der logischen Tabelle weglassen. Siehe Abgeleitete Metriken definieren.

• Einen Namen für den Fakt, die Dimension oder die Metrik.

• Den SQL-Ausdruck, um ihn zu berechnen.

  Bemerkung

  Für Dimensionen können Sie einen Cortex Search Service </user-guide/snowflake-cortex/cortex-search/cortex-search-overview>`angeben, der für die Dimension verwendet werden soll. Weitere Informationen dazu finden Sie unter :ref:`label-semantic_views_create_cortex_search_service_dimension.

• Optionale Synonyme und Kommentare.

Das zuvor vorgestellte Beispiel definiert mehrere Fakten, Dimensionen und Metriken:

FACTS (
  line_items.line_item_id AS CONCAT(l_orderkey, '-', l_linenumber),
  orders.count_line_items AS COUNT(line_items.line_item_id),
  line_items.discounted_price AS l_extendedprice * (1 - l_discount)
    COMMENT = 'Extended price after discount'
)

DIMENSIONS (
  customers.customer_name AS customers.c_name
    WITH SYNONYMS = ('customer name')
    COMMENT = 'Name of the customer',
  orders.order_date AS o_orderdate
    COMMENT = 'Date when the order was placed',
  orders.order_year AS YEAR(o_orderdate)
    COMMENT = 'Year when the order was placed'
)

METRICS (
  customers.customer_count AS COUNT(c_custkey)
    COMMENT = 'Count of number of customers',
  orders.order_average_value AS AVG(orders.o_totalprice)
    COMMENT = 'Average order value across all orders',
  orders.average_line_items_per_order AS AVG(orders.count_line_items)
    COMMENT = 'Average number of line items per order'
)

Definieren einer Dimension, die einen Cortex Search Service verwendet¶

Um eine Dimension zu definieren, die einen Cortex Search Service verwendet, legen Sie die WITH CORTEX SEARCH SERVICE-Klausel auf den Namen des Cortex Search Service fest. Wenn sich der Dienst in einer anderen Datenbank oder einem anderen Schema befindet, qualifizieren Sie den Namen des Dienstes. Beispiel:

DIMENSIONS (
  my_table.my_dimension AS my_dimension_expression
    WITH CORTEX SEARCH SERVICE my_db.my_schema.my_dimension_search_service
)

Abgeleitete Metriken definieren¶

Wenn Sie eine Metrik definieren, geben Sie den Namen der logischen Tabelle an, zu der die Metrik gehört. Dies ist die logische Tabelle, in der die Metrik aggregiert wird.

Wenn Sie eine Metrik auf der Grundlage von Metriken aus verschiedenen logischen Tabellen definieren möchten, können Sie eine abgeleitete Metrik definieren. Eine abgeleitete Metrik ist eine Metrik, die auf die semantische Ansicht (und nicht auf eine bestimmte logische Tabelle) beschränkt ist. Eine abgeleitete Metrik kann Metriken aus mehrere logischen Tabellen kombinieren.

Lassen Sie bei der Definition einer abgeleiteten Metrik den Namen der logischen Tabelle weg.

Angenommen, Sie möchten die Metrik my_derived_metric_1 definieren, die die Summe der Metriken table_1.metric_1 und table_2.metric_2 ist. Wenn Sie my_derived_metric_1 definieren, qualifizieren Sie den Namen nicht mit einem logischen Tabellennamen:

CREATE SEMANTIC VIEW sv_with_derived_metrics
  TABLES (
    table_1 PRIMARY KEY (column_1),
    table_2 PRIMARY KEY (column_2)
  )
  ...
  METRICS (
    table_1.metric_1 AS SUM(...),
    table_2.metric_2 AS SUM(...),
    my_derived_metric_1 AS table_1.metric_1 + table_2.metric_2
  )
 ...

Sie können andere abgeleitete Metriken in dem Ausdruck verwenden. Beispiel:

METRICS (
  ...
  my_derived_metric_1 AS table_1.metric_1 + table_2.metric_2,
  my_view_metric_2 AS my_derived_metric_1 + table_3.metric_3
)

Beachten Sie die folgenden Einschränkungen, wenn Sie eine abgeleitete Metrik definieren:

• Sie können für eine abgeleitete Metrik und eine reguläre Metrik nicht denselben Namen verwenden.

• Der Ausdruck für eine abgeleitete Metrik kann Folgendes verwenden:

  • Aggregationen von Dimensionen und Fakten, die in einer beliebigen logischen Tabelle in der semantischen Ansicht definiert sind.

  • Skalare Ausdrücke von Metriken, die in einer beliebigen logischen Tabelle in der semantischen Ansicht definiert sind.

  • Andere abgeleitete Metriken.

  Im folgenden Beispiel:

  • Verwendet derived_metric_1 einen skalaren Ausdruck mit zwei Metriken.

  • Verwendet derived_metric_2 eine Aggregation einer Dimension.

  • Fügt derived_metric_3 eine Aggregation einer Dimension zu einer anderen abgeleiteten Metrik hinzu.

  CopyExpand

  CREATE OR REPLACE SEMANTIC VIEW sv_derived_metrics
    TABLES (t1)
    DIMENSIONS (t1.dim1 AS t1.col1)
    METRICS (
      t1.m1 AS SUM(t1.col1),
      t2.m2 AS SUM(t1.col2),
      derived_metric_1 AS t1.m1 + t2.m2,
      derived_metric_2 AS SUM(t1.dim1),
      derived_metric_3 AS SUM(t1.dim1) + derived_metric_2
    )
    ...
  

  Show lessSee more

  Scroll to top

• Sie müssen den Namen einer Metrik, Dimension oder eines Fakts im Ausdruck nicht qualifizieren, wenn der Name eindeutig ist. Beispiel:

  CopyExpand

  METRICS (
    table_1.metric_1 AS ...,
    table_1.my_unique_metric_name AS ...,
    table_2.metric_1 AS ...,
    my_derived_metric_1 AS table_1.metric_1 + my_unique_metric_name
  )
  

  Show lessSee more

  Scroll to top

  Beachten Sie, dass metric_1 durch table_1 qualifiziert werden muss, da es zwei Metriken mit dem Namen metric_1 gibt. Allerdings muss my_unique_metric_name nicht qualifiziert werden, da der Name eindeutig ist.

• Im Ausdruck für eine abgeleitete Metrik können Sie Folgendes nicht verwenden:

  • Aggregationen von Metriken.

  • Fensterfunktionen

  • Verweise auf physische Spalten.

  • Verweise auf Fakten oder Dimensionen, die nicht aggregiert sind.

• Sie können eine abgeleitete Metrik im Ausdruck nicht für eine reguläre Metrik, reguläre Dimension oder regulären Fakt verwenden. Nur eine andere abgeleitete Metrik kann eine abgeleitete Metrik in ihrem Ausdruck verwenden.

Angeben der Beziehung für eine Metrik, wenn mehrere Beziehungspfade existieren¶

In einigen Fällen können zwischen zwei bestimmten logischen Tabellen in einer semantischen Ansicht mehrere Beziehungspfade existieren. In diesen Fällen müssen Sie bei der Definition einer Metrik den zu verwendenden Beziehungspfad angeben.

CREATE OR REPLACE TABLE airports (
  airport_code VARCHAR PRIMARY KEY,
  city_name VARCHAR,
  airport_region_code VARCHAR
);

INSERT INTO airports VALUES
  ('SEA', 'Seattle', 'NA'),
  ('SFO', 'San Fransico', 'NA'),
  ('PVG', 'Shanghai', 'AS');

SELECT * FROM airports;

+--------------+--------------+---------------------+
| AIRPORT_CODE | CITY_NAME    | AIRPORT_REGION_CODE |
|--------------+--------------+---------------------|
| SEA          | Seattle      | NA                  |
| SFO          | San Fransico | NA                  |
| PVG          | Shanghai     | AS                  |
+--------------+--------------+---------------------+

CREATE OR REPLACE TABLE flights (
  flight_id INTEGER PRIMARY KEY,
  departure_airport VARCHAR,
  arrival_airport VARCHAR,
  is_late BOOLEAN,
  aircraft_id INTEGER,
  departure_time DATETIME,
  arrival_time DATETIME
);

INSERT INTO flights VALUES
  (1, 'SFO', 'SEA', true, 1, '2025-01-03 06:00:00', '2025-01-03 11:00:00'),
  (2, 'SEA', 'SFO', false, 2, '2025-01-03 11:00:00', '2025-01-03 16:00:00'),
  (3, 'SEA', 'PVG', false, 3, '2025-01-03 11:00:00', '2025-01-04 11:00:00'),
  (4, 'SFO', 'PVG', true, 1, '2025-01-03 06:00:00', '2025-01-04 11:00:00');

SELECT * FROM flights;

+-----------+-------------------+-----------------+---------+-------------+-------------------------+-------------------------+
| FLIGHT_ID | DEPARTURE_AIRPORT | ARRIVAL_AIRPORT | IS_LATE | AIRCRAFT_ID | DEPARTURE_TIME          | ARRIVAL_TIME            |
|-----------+-------------------+-----------------+---------+-------------+-------------------------+-------------------------|
|         1 | SFO               | SEA             | True    |           1 | 2025-01-03 06:00:00.000 | 2025-01-03 11:00:00.000 |
|         2 | SEA               | SFO             | False   |           2 | 2025-01-03 11:00:00.000 | 2025-01-03 16:00:00.000 |
|         3 | SEA               | PVG             | False   |           3 | 2025-01-03 11:00:00.000 | 2025-01-04 11:00:00.000 |
|         4 | SFO               | PVG             | True    |           1 | 2025-01-03 06:00:00.000 | 2025-01-04 11:00:00.000 |
+-----------+-------------------+-----------------+---------+-------------+-------------------------+-------------------------+

CREATE OR REPLACE SEMANTIC VIEW flights_sv
  TABLES (
    flights PRIMARY KEY (flight_id),
    airports PRIMARY KEY (airport_code)
  ) RELATIONSHIPS (
    flight_departure_airport AS flights(departure_airport) REFERENCES airports(airport_code),
    flight_arrival_airport AS flights(arrival_airport) REFERENCES airports(airport_code)
  ) DIMENSIONS (
    airports.city_name AS city_name
  ) METRICS (
    flights.m_flight_count AS COUNT(flight_id)
  );

SELECT * FROM SEMANTIC_VIEW (
  flights_sv
  METRICS flights.m_flight_count
  DIMENSIONS airports.city_name
);

010246 (42601): SQL compilation error:
Invalid dimension specified: Multi-path relationship between the dimension entity 'AIRPORTS'
  and the base metric or dimension entity 'FLIGHTS' is not supported.

METRICS (
  <table_alias>.<metric>
    [ USING ( <relationship_name> [ , ... ] )
    AS <sql_expr>
  [ , ... ]
)

CREATE OR REPLACE SEMANTIC VIEW flights_sv
  TABLES (
    flights PRIMARY KEY (flight_id),
    airports PRIMARY KEY (airport_code)
  ) RELATIONSHIPS (
    flight_departure_airport AS flights(departure_airport) REFERENCES airports(airport_code),
    flight_arrival_airport AS flights(arrival_airport) REFERENCES airports(airport_code)
  ) DIMENSIONS (
    airports.city_name AS city_name
  ) METRICS (
    flights.m_flight_count AS COUNT(flight_id),
    flights.m_flight_departure_count USING (flight_departure_airport) AS flights.m_flight_count,
    flights.m_flight_arrival_count USING (flight_arrival_airport) AS flights.m_flight_count
  );

SELECT * FROM SEMANTIC_VIEW (
  flights_sv
  METRICS flights.m_flight_arrival_count, flights.m_flight_departure_count
  DIMENSIONS airports.city_name
);

+------------------------+--------------------------+--------------+
| M_FLIGHT_ARRIVAL_COUNT | M_FLIGHT_DEPARTURE_COUNT | CITY_NAME    |
|------------------------+--------------------------+--------------|
|                      1 |                        2 | San Fransico |
|                      1 |                        2 | Seattle      |
|                      2 |                     NULL | Shanghai     |
+------------------------+--------------------------+--------------+

CREATE OR REPLACE TABLE regions (
  region_code VARCHAR PRIMARY KEY,
  region_name VARCHAR
);

INSERT INTO regions VALUES
  ('NA', 'North America'),
  ('AS', 'Asia');

SELECT * FROM regions;

+-------------+---------------+
| REGION_CODE | REGION_NAME   |
|-------------+---------------|
| NA          | North America |
| AS          | Asia          |
+-------------+---------------+

CREATE OR REPLACE SEMANTIC VIEW flights_by_regions_sv
  TABLES (
    flights PRIMARY KEY (flight_id),
    airports PRIMARY KEY (airport_code),
    regions PRIMARY KEY (region_code)
  ) RELATIONSHIPS (
    flight_departure_airport AS flights(departure_airport) REFERENCES airports(airport_code),
    flight_arrival_airport AS flights(arrival_airport) REFERENCES airports(airport_code),
    airport_region AS airports(airport_region_code) REFERENCES regions(region_code)
  ) DIMENSIONS (
    airports.city_name AS city_name,
    regions.region_name AS region_name
  ) METRICS (
    flights.m_flight_count AS COUNT(flight_id),
    flights.m_flight_departure_count USING (flight_departure_airport) AS flights.m_flight_count,
    flights.m_flight_arrival_count USING (flight_arrival_airport) AS flights.m_flight_count
  );

SELECT * FROM SEMANTIC_VIEW (
  flights_by_regions_sv
  METRICS flights.m_flight_arrival_count, flights.m_flight_departure_count
  DIMENSIONS regions.region_name
);

+------------------------+--------------------------+---------------+
| M_FLIGHT_ARRIVAL_COUNT | M_FLIGHT_DEPARTURE_COUNT | REGION_NAME   |
|------------------------+--------------------------+---------------|
|                      2 |                        4 | North America |
|                      2 |                     NULL | Asia          |
+------------------------+--------------------------+---------------+

CREATE OR REPLACE TABLE weather (
  airport_code VARCHAR PRIMARY KEY,
  weather_condition VARCHAR,
  start_date DATETIME,
  end_date DATETIME
);

INSERT INTO weather VALUES
  ('SEA', 'rainy', '2025-01-01 10:00:00', '2025-01-01 12:00:00'),
  ('SEA', 'rainy', '2025-01-03 10:00:00', '2025-01-03 12:00:00'),
  ('SFO', 'sunny', '2025-01-03 05:00:00', '2025-01-03 09:00:00'),
  ('SFO', 'sunny', '2025-01-03 10:00:00', '2025-01-03 18:00:00'),
  ('PVG', 'cloudy', '2025-01-04 10:00:00', '2025-01-04 12:00:00');

SELECT * FROM weather;

+--------------+-------------------+-------------------------+-------------------------+
| AIRPORT_CODE | WEATHER_CONDITION | START_DATE              | END_DATE                |
|--------------+-------------------+-------------------------+-------------------------|
| SEA          | rainy             | 2025-01-01 10:00:00.000 | 2025-01-01 12:00:00.000 |
| SEA          | rainy             | 2025-01-03 10:00:00.000 | 2025-01-03 12:00:00.000 |
| SFO          | sunny             | 2025-01-03 05:00:00.000 | 2025-01-03 09:00:00.000 |
| SFO          | sunny             | 2025-01-03 10:00:00.000 | 2025-01-03 18:00:00.000 |
| PVG          | cloudy            | 2025-01-04 10:00:00.000 | 2025-01-04 12:00:00.000 |
+--------------+-------------------+-------------------------+-------------------------+

CREATE OR REPLACE SEMANTIC VIEW flights_and_weather_sv
  TABLES (
    flights PRIMARY KEY (flight_id),
    airports PRIMARY KEY (airport_code),
    weather PRIMARY KEY (airport_code, start_date, end_date)
  ) RELATIONSHIPS (
    flight_departure_airport AS flights(departure_airport) REFERENCES airports(airport_code),
    flight_arrival_airport AS flights(arrival_airport) REFERENCES airports(airport_code),
    flight_departure_weather AS flights(departure_airport, departure_time) REFERENCES weather(airport_code, BETWEEN start_date AND end_date EXCLUSIVE),
    flight_arrival_weather AS flights(arrival_airport, arrival_time) REFERENCES weather(airport_code, BETWEEN start_date AND end_date EXCLUSIVE)
  ) DIMENSIONS (
    airports.city_name AS city_name,
    weather.weather_condition AS weather_condition
  ) METRICS (
    flights.m_flight_count AS COUNT(flight_id),
    flights.m_flight_departure_count USING (flight_departure_airport, flight_departure_weather) AS flights.m_flight_count,
    flights.m_flight_arrival_count USING (flight_arrival_airport, flight_arrival_weather) AS flights.m_flight_count
  );

SELECT * FROM SEMANTIC_VIEW (
  flights_by_regions_sv
  METRICS flights.m_flight_arrival_count, flights.m_flight_departure_count
  DIMENSIONS weather.weather_condition
);

+------------------------+--------------------------+-------------------+
| M_FLIGHT_ARRIVAL_COUNT | M_FLIGHT_DEPARTURE_COUNT | WEATHER_CONDITION |
|------------------------+--------------------------+-------------------|
|                      2 |                     NULL | cloudy            |
|                      1 |                        2 | sunny             |
|                      1 |                        2 | rainy             |
+------------------------+--------------------------+-------------------+

CREATE OR REPLACE SEMANTIC VIEW flights_derived_metrics_sv
  TABLES (
    flights PRIMARY KEY (flight_id),
    airports PRIMARY KEY (airport_code)
  ) RELATIONSHIPS (
    flight_departure_airport AS flights(departure_airport) REFERENCES airports(airport_code),
    flight_arrival_airport AS flights(arrival_airport) REFERENCES airports(airport_code)
  ) DIMENSIONS (
    airports.city_name AS city_name
  ) METRICS (
    flights.m_flight_count AS COUNT(flight_id),
    flights.m_flight_departure_count USING (flight_departure_airport) AS flights.m_flight_count,
    flights.m_flight_arrival_count USING (flight_arrival_airport) AS flights.m_flight_count,
    global_m_departure_arrival_ratio AS DIV0(flights.m_flight_departure_count, flights.m_flight_arrival_count),
    global_m_departure_arrival_sum AS flights.m_flight_departure_count + flights.m_flight_arrival_count
  );

SELECT * FROM SEMANTIC_VIEW (
  flights_derived_metrics_sv
  METRICS global_m_departure_arrival_ratio,
    flights.m_flight_arrival_count, flights.m_flight_departure_count
  DIMENSIONS airports.city_name
);

+------------------------+--------------------------+----------------------------------+--------------+
| M_FLIGHT_ARRIVAL_COUNT | M_FLIGHT_DEPARTURE_COUNT | GLOBAL_M_DEPARTURE_ARRIVAL_RATIO | CITY_NAME    |
|------------------------+--------------------------+----------------------------------+--------------|
|                      1 |                        2 |                         2.000000 | Seattle      |
|                      1 |                        2 |                         2.000000 | San Fransico |
|                      2 |                     NULL |                             NULL | Shanghai     |
+------------------------+--------------------------+----------------------------------+--------------+

Identifizieren der Dimensionen, die für eine Metrik nicht additiv sein sollen¶

In manchen Fällen sollte eine Metrik nicht über bestimmte Dimensionen hinweg aggregiert werden. In diesen Fällen können Sie die Dimensionen als nicht additiv markieren.

CREATE OR REPLACE TABLE bank_accounts (
  customer_id VARCHAR,
  account_type VARCHAR,
  year NUMBER,
  month NUMBER,
  day NUMBER,
  balance NUMBER
);

INSERT INTO bank_accounts VALUES
  ('cust-001', 'checking', 2024, 01, 01, 100),
  ('cust-001', 'savings', 2024, 01, 01, 110),
  ('cust-001', 'checking', 2024, 02, 10, 140),
  ('cust-001', 'savings', 2024, 02, 10, 150),
  ('cust-001', 'checking', 2024, 03, 15, 200),
  ('cust-001', 'savings', 2024, 03, 30, 210),
  ('cust-001', 'checking', 2025, 02, 15, 280),
  ('cust-001', 'savings', 2025, 02, 15, 290),
  ('cust-001', 'checking', 2025, 03, 20, 300),
  ('cust-001', 'savings', 2025, 03, 20, 310),
  ('cust-002', 'checking', 2025, 03, 30, 200),
  ('cust-002', 'savings', 2025, 03, 30, 310);

SELECT * FROM bank_accounts;

+-------------+--------------+------+-------+-----+---------+
| CUSTOMER_ID | ACCOUNT_TYPE | YEAR | MONTH | DAY | BALANCE |
|-------------+--------------+------+-------+-----+---------|
| cust-001    | checking     | 2024 |     1 |   1 |     100 |
| cust-001    | savings      | 2024 |     1 |   1 |     110 |
| cust-001    | checking     | 2024 |     2 |  10 |     140 |
| cust-001    | savings      | 2024 |     2 |  10 |     150 |
| cust-001    | checking     | 2024 |     3 |  15 |     200 |
| cust-001    | savings      | 2024 |     3 |  30 |     210 |
| cust-001    | checking     | 2025 |     2 |  15 |     280 |
| cust-001    | savings      | 2025 |     2 |  15 |     290 |
| cust-001    | checking     | 2025 |     3 |  20 |     300 |
| cust-001    | savings      | 2025 |     3 |  20 |     310 |
| cust-002    | checking     | 2025 |     3 |  30 |     200 |
| cust-002    | savings      | 2025 |     3 |  30 |     310 |
+-------------+--------------+------+-------+-----+---------+

CREATE OR REPLACE SEMANTIC VIEW bank_accounts_sv
  TABLES (
    bank_accounts
  )
  DIMENSIONS (
    bank_accounts.customer_id_dim AS bank_accounts.customer_id,
    bank_accounts.account_type_dim AS bank_accounts.account_type,
    bank_accounts.year_dim AS bank_accounts.year,
    bank_accounts.month_dim AS bank_accounts.month,
    bank_accounts.day_dim AS bank_accounts.day
  )
  METRICS (
    bank_accounts.m_account_balance AS SUM(balance)
  );

SELECT * FROM SEMANTIC_VIEW(
    bank_accounts_sv
    METRICS bank_accounts.m_account_balance
    DIMENSIONS customer_id_dim, year_dim
  )
  ORDER BY customer_id_dim, year_dim;

+-------------------+-----------------+----------+
| M_ACCOUNT_BALANCE | CUSTOMER_ID_DIM | YEAR_DIM |
|-------------------+-----------------+----------|
|               910 | cust-001        |     2024 |
|              1180 | cust-001        |     2025 |
|               510 | cust-002        |     2025 |
+-------------------+-----------------+----------+

CREATE OR REPLACE SEMANTIC VIEW bank_accounts_sv
  TABLES (
    bank_accounts
  )
  DIMENSIONS (
    bank_accounts.customer_id_dim AS bank_accounts.customer_id,
    bank_accounts.account_type_dim AS bank_accounts.account_type,
    bank_accounts.year_dim AS bank_accounts.year,
    bank_accounts.month_dim AS bank_accounts.month,
    bank_accounts.day_dim AS bank_accounts.day
  )
  METRICS (
    bank_accounts.m_account_balance
      NON ADDITIVE BY (year_dim, month_dim, day_dim)
      AS SUM(balance)
  );

SELECT * FROM SEMANTIC_VIEW(
    bank_accounts_sv
    METRICS bank_accounts.m_account_balance
    DIMENSIONS customer_id_dim, year_dim
  )
  ORDER BY customer_id_dim, year_dim;

+-------------------+-----------------+----------+
| M_ACCOUNT_BALANCE | CUSTOMER_ID_DIM | YEAR_DIM |
|-------------------+-----------------+----------|
|               210 | cust-001        |     2024 |
|               610 | cust-001        |     2025 |
|               510 | cust-002        |     2025 |
+-------------------+-----------------+----------+

SELECT * FROM SEMANTIC_VIEW(
    bank_accounts_sv
    METRICS bank_accounts.m_account_balance
    DIMENSIONS year_dim
  )
  ORDER BY year_dim;

+-------------------+----------+
| M_ACCOUNT_BALANCE | YEAR_DIM |
|-------------------+----------|
|               210 |     2024 |
|               510 |     2025 |
+-------------------+----------+

METRICS (
  bank_accounts.m_account_balance
    NON ADDITIVE BY (year_dim DESC, month_dim DESC, day_dim DESC)
    AS SUM(balance)
);

METRICS (
  bank_accounts.m_account_balance
    NON ADDITIVE BY (
      year_dim DESC NULLS FIRST,
      month_dim DESC NULLS FIRST,
      day_dim DESC NULLS FIRST
    )
    AS SUM(balance)

Tatsache oder Metrik als privat markieren¶

Wenn Sie einen Fakt oder eine Kennzahl nur zur Verwendung in Berechnungen in der semantischen Ansicht definieren und nicht möchten, dass der Fakt oder die Kennzahl in einer Abfrage zurückgegeben werden, können Sie das Schlüsselwort PRIVATE angeben, um die Tatsache oder Kennzahl als privat zu markieren. Beispiel:

FACTS (
  PRIVATE my_private_fact AS ...
)

METRICS (
  PRIVATE my_private_metric AS ...
)

Wenn Sie eine semantische Ansicht abfragen, die private Fakten oder Metriken enthält, können Sie in den folgenden Klauseln keine privaten Fakten oder Metriken angeben:

• Die SELECT-Liste

• FACTS in der SEMANTIC_VIEW-Klausel

• METRICS in der SEMANTIC_VIEW-Klausel

• METRICS

• WHERE in der SELECT-Anweisung oder SEMANTIC_VIEW-Klausel

Einige Befehle und Funktionen beinhalten private Fakten und Kennzahlen:

• Private Fakten und Kennzahlen werden nicht in der Ausgabe des DESCRIBE SEMANTIC VIEW-Befehls angezeigt. Die Zeilen für private Fakten und Metriken zeigen PRIVATE in der access_modifier-Spalte.

• Private Fakten und Metriken werden im Rückgabewert eines GET_DDL-Funktionsaufrufs aufgeführt, wie unter Abrufen der SQL-Anweisung für eine semantische Ansicht erwähnt.

Einige Befehle und Funktionen enthalten private Fakten und Metriken nur unter bestimmten Bedingungen:

• Private Fakten und Metriken sind unter INFORMATION_SCHEMA SEMANTIC_FACTS und SEMANTIC_METRICS-Ansichten aufgeführt. Dies gilt nur, wenn Sie eine Rolle verwenden, die die Berechtigung gewährt hat fürREFERENCES oder OWNERSHIP. Diese muss für die semantische Ansicht gelten.

  Andernfalls werden in diesen Ansichten nur die öffentlichen Fakten und Metriken aufgelistet.

Andere Befehle und Funktionen enthalten keine privaten Fakten und Metriken:

• Private Fakten werden nicht in der Ausgabe des Befehls SHOW SEMANTIC FACTS angezeigt.

• Private Metriken werden nicht in der Ausgabe des Befehls SHOW SEMANTIC METRICS angezeigt.

Bereitstellung kundenspezifischer Anweisungen für Cortex Analyst¶

In einer semantischen Ansicht können Sie Anweisungen für Cortex Analyst angeben, die Folgendes erklären:

• SQL-Anweisung generieren

• Fragen klassifizieren und zusätzliche Informationen einfordern

Um diese benutzerdefinierten Anweisungen bereitzustellen, verwenden Sie die folgenden Klauseln:

• Für eine Anleitung zum Generieren der SQL-Anweisung verwenden Sie die AI_SQL_GENERATION-Klausel im Befehl CREATE SEMANTIC VIEW.

  Um zum Beispiel Cortex Analyst anzuweisen, die SQL-Anweisung zu generieren, sodass alle numerischen Spalten auf zwei Dezimalstellen gerundet werden, geben Sie Folgendes an:

  CopyExpand

  CREATE SEMANTIC VIEW my_semantic_view
    ...
    -- Definitions of logical tables, relationships, dimensions, facts, and metrics
    ...
    AI_SQL_GENERATION 'Ensure that all numeric columns are rounded to 2 decimal points.'
    ...
    -- Additional clauses
  

  Show lessSee more

  Scroll to top

• Für eine Anleitung zum Klassifizieren von Fragen verwenden Sie die AI_QUESTION_CATEGORIZATION-Klausel.

  Um zum Beispiel Cortex Analyst anzuweisen, Fragen zu Benutzern abzulehnen, geben Sie Folgendes an:

  CopyExpand

  CREATE SEMANTIC VIEW my_semantic_view
    ...
    -- Definitions of logical tables, relationships, dimensions, facts, and metrics
    ...
    AI_QUESTION_CATEGORIZATION 'Reject all questions asking about users. Ask users to contact their admin.'
    ...
    -- Additional clauses
  

  Show lessSee more

  Scroll to top

  Sie können auch Anweisungen geben, nach weiteren Details zu fragen, wenn die Frage nicht klar ist. Beispiel:

  CopyExpand

  AI_QUESTION_CATEGORIZATION 'If the question asks for users without providing a product_type, consider this question UNCLEAR and ask the user to specify product_type.'
  

  Show lessSee more

  Scroll to top