YAML-Spezifikation für semantische Ansichten¶
Semantische Ansichten sind Objekte auf Schemaebene, die Geschäftskonzepte für Ihre Daten definieren und es Benutzenden erleichtern, Daten mithilfe von Geschäftsterminologie abzufragen und zu analysieren. Sie können mit der YAML-Spezifikation eine semantische Ansicht in Cortex Analyst erstellen oder die SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML gespeicherte Prozedur verwenden, um eine semantische Ansicht anhand einer YAML-Spezifikation zu erstellen.
Übersicht¶
Semantische Ansichten sind der empfohlene Ansatz für die Definition von Geschäftssemantik in Snowflake. Semantische Ansichten sind Objekte auf Schemaebene, die sich in das Berechtigungssystem, die Freigabemechanismen und den Metadatenkatalog von Snowflake integrieren lassen.
Bemerkung
YAML-Dateien älterer semantischer Modelle (in Stagingbereichen gespeichert) können weiterhin mit Cortex Analyst verwendet werden (aus Gründen der Abwärtskompatibilität). Wir empfehlen jedoch die Verwendung semantischer Ansichten für neue Implementierungen.
Die Vorteile semantischer Ansichten gegenüber älteren semantischen Modellen sind:
Native Snowflake-Integration: Objekte auf Schemaebene mit vollständiger RBAC, Freigabe und Katalogunterstützung
Erweiterte Features: Unterstützung für abgeleitete Kennzahlen und Zugriffsmodifikatoren (öffentlich/privat)
Verbesserte Governance: Integriert in die Berechtigungs- und Freigabesysteme von Snowflake
Vereinfachte Verwaltung: Kein Verwalten von YAML-Dateien in Stagingbereichen
YAML-Format¶
Semantische Ansichten können eine YAML-Spezifikation nutzen, um ihr Verhalten zu definieren und so lesbare Definitionen in Klartext zu ermöglichen.
Die allgemeine Syntax einer semantischen Ansicht mit YAML-Spezifikation lautet wie folgt:
Wichtig
Für semantische Ansichten wird Folgendes nicht benötigt: Feld join_type oder relationship_type, die in älteren semantischen Modellen verwendet wurden. Der Beziehungstyp wird automatisch aus den Daten abgeleitet.
Die wichtigsten Konzepte¶
Tabellen¶
Logische Tabellen repräsentieren Geschäftseinheiten (wie Kunden, Aufträge oder Produkte) und werden physischen Datenbanktabellen zugeordnet. Jede logische Tabelle kann Folgendes definieren:
Basistabelle: Der vollqualifizierte Name der physischen Tabelle
Primärschlüssel: Spalten, die Zeilen eindeutig identifizieren
Synonyme: Alternative Namen für die Tabelle
Beschreibung: Geschäftsfreundliche Erklärung, was die Tabelle darstellt
Dimensionen¶
Dimensionen stellen Kategorie-Attribute dar, die Kontext für die Analyse bereitstellen. Sie beantworten die Fragen „Wer“, „Was“, „Wo“ und „Wann“. Dimensionen können Folgendes sein:
Reguläre Dimensionen: Text, numerische oder andere Kategoriewerte
Zeitdimensionen: Datums- oder Zeitstempelspalten mit spezieller zeitbasierter Behandlung
Eigenschaften von Dimensionen¶
expr: SQL-Ausdruck zum Berechnen des Dimensionswertssynonyms: Alternative Begriffe, die von Benutzenden verwendet werdenunique: Gibt an, ob Werte über Zeilen hinweg eindeutig sindis_enum: Gibt an, ob die Dimension einen festen Satz von Werten hatcortex_search_service: Optionaler Cortex Search Service für die semantische Suche
Optionale Eigenschaften für physische Dimensionen¶
Diese Felder sind optional, werden aber empfohlen, um bei einer Suche aus einer semantischen Ansicht qualitativ bessere Ergebnisse zu erzielen.
synonymsEine Liste anderer Begriffe/Phrasen, die sich auf diese Dimension beziehen. Muss für alle Synonyme in diesem semantischen Modell eindeutig sein.
descriptionEine kurze Beschreibung dieser Dimension. Fügen Sie Informationen hinzu, die nützlichen Kontext liefern, z. B. Daten, die diese Dimension repräsentiert.
uniqueEin boolescher Wert, der angibt, dass diese Dimension eindeutige Werte hat.
sample_valuesBeispielwerte für diese Spalte, falls vorhanden. Fügen Sie alle Werte hinzu, auf die in den Fragen der Benutzer wahrscheinlich Bezug genommen wird.
is_enumEin boolescher Wert. Wenn Sie
Truewählen, werden die Werte im Feldsample_valuesals die vollständige Liste der möglichen Werte betrachtet und das Modell wählt nur aus diesen Werten, wenn es nach dieser Spalte filtert.cortex_search_serviceGibt den Cortex Search Service an, der für diese Dimension verwendet werden soll. Es hat die folgenden Felder:
service: Der Name des Cortex Search Service.literal_column: (optional) Die Spalte im Cortex Search Service, die die literalen Werte enthält.database: (optional) Die Datenbank, in der sich der Cortex Search Service befindet. Standardmäßig wird die Datenbank vonbase_tableverwendet.schema: (optional) Das Schema, in dem sich der Cortex Search Service befindet. Standardmäßig wird das Schema vonbase_tableverwendet.
cortex_search_serviceersetzt das Feldcortex_search_service_name, in dem nur der Name angegeben werden konnte.cortex_search_service_nameist veraltet.
Optionale Eigenschaften für Zeitdimensionen¶
Diese Felder sind optional, werden aber empfohlen, um bei einer Suche aus einer semantischen Ansicht qualitativ bessere Ergebnisse zu erzielen.
synonymsEine Liste anderer Begriffe/Phrasen, die sich auf diese Zeitdimension beziehen. Muss für alle Synonyme in diesem semantischen Modell eindeutig sein.
descriptionEine kurze Beschreibung dieser Dimension. Fügen Sie Informationen hinzu, die einen nützlichen Kontext liefern, z. B. die Zeitzone, die diese Dimension als Referenzpunkt verwendet.
unique:Ein boolescher Wert, der angibt, dass diese Spalte eindeutige Werte hat.
sample_values:Beispielwerte für diese Spalte, falls vorhanden. Fügen Sie alle Werte hinzu, auf die in den Fragen der Benutzer wahrscheinlich Bezug genommen wird.
Fakten¶
Fakten sind quantitative Attribute auf Zeilenebene, die bestimmte Geschäftsereignisse oder Transaktionen darstellen. Fakten erfassen das „wie viel“ auf der detailliertesten Ebene, z. B. einzelne Verkaufsbeträge, gekaufte Mengen oder Kosten.
Fakten fungieren in der Regel als „Hilfskonzepte“ innerhalb der semantischen Ansicht, um Dimensionen und Kennzahlen zu konstruieren.
Die Eigenschaften von Fakten sind:
expr: SQL-Ausdruck zum Berechnen des Faktenwertsaccess_modifier: Aufprivate_accessfestlegen, um vor Abfragen zu verbergen (nützlich für Zwischenberechnungen)data_type: Der Datentyp des Fakts
Kennzahlen¶
Kennzahlen sind quantifizierbare Messgrößen der Geschäftsleistung, die durch Aggregieren von Fakten oder anderen Spalten mit Funktionen wie SUM, AVG und COUNT berechnet werden.
Zwei Arten von Kennzahlen:
Kennzahlen auf Tabellenebene: Bereich auf eine bestimmte logische Tabelle festgelegt, Aggregieren von Daten innerhalb dieser Tabelle
Abgeleitete Kennzahlen: Kennzahlen auf Ansichtsebene, die Kennzahlen aus mehreren Tabellen kombinieren
Eigenschaften von Kennzahlen¶
expr: SQL-Ausdruck mit Aggregationsfunktionaccess_modifier: Aufprivate_accessfestlegen, um vor Abfragen zu verbergen (nützlich für Zwischenberechnungen)synonyms: Alternative Begriffe für Kennzahlen
Optionale Eigenschaften von Kennzahlen¶
Wenn Sie die Dimensionen angeben möchten, die für die Kennzahl nicht additiv sein sollen, verwenden Sie die folgenden Felder:
non_additive_dimensionsGibt die Dimensionen an, über die die Kennzahl nicht aggregiert werden soll.
tableName der logischen Tabelle, die die Dimension enthält.
dimensionName der Dimension.
sort_directionSortierreihenfolge für die nicht additive Dimension. Sie können einen der folgenden Werte angeben:
ascending: Sortieren Sie die Dimensionswerte in aufsteigender Reihenfolge.descending: Sortieren Sie die Dimensionswerte in absteigender Reihenfolge.
Standard:
ascendingnull_orderGibt an, ob NULLs :ref:` vor oder nach Nicht-NULL-Werten <label-semantic_views_metrics_semi_additive_order>` sortiert sind. Sie können einen der folgenden Werte angeben:
first: NULLs werden vor Nicht-NULL-Werten sortiert.last: NULLs werden nach Nicht-NULL-Werten sortiert.
Standard: Hängt von dem Wert im Feld
sort_direction(ascendingoderdescending) ab; siehe Nutzungshinweise in der ORDER BY-Dokumentation.
Bemerkung
Da die Zeilen nach den nicht additiven Dimensionen sortiert sind, ist die Reihenfolge, in der Sie die Dimensionen angeben, wichtig. Dies ist vergleichbar mit der Reihenfolge, in der Sie die Spalten in der ORDER BY-Klausel angeben.
Das folgende Beispiel gibt an, dass die Kennzahl
m_account_balancenicht durch die Dimensionenyear_dimundmonth_dimaggregiert werden kann:Wenn es mehrere Beziehungspfade zwischen zwei bestimmten logischen Tabellen in einer semantischen Ansicht gibt, verwenden Sie das folgende Feld, um den zu verwendenden Beziehungspfad anzugeben:
using_relationships-
Gibt den Namen der Beziehung an, die für das Verknüpfen der logischen Tabellen bei der Berechnung der Kennzahl verwendet werden soll.
Abgeleitete Kennzahlen¶
Abgeleitete Kennzahlen sind Kennzahlen auf Ansichtsebene, die nicht an eine bestimmte Tabelle gebunden sind. Sie können Kennzahlen aus mehreren Tabellen kombinieren oder Berechnungen über die gesamte Ansicht hinweg durchführen.
Beispiel für eine abgeleitete Kennzahl:
Beziehungen¶
Beziehungen definieren, wie logische Tabellen miteinander verknüpft werden. Jede Beziehung legt Folgendes fest:
left_table: Die Tabelle, die den Fremdschlüssel enthältright_table: Die Tabelle, auf die verwiesen wirdrelationship_columns: Paare von Spalten für die Verknüpfung, wieleft_columnundright_column
Der Beziehungstyp (1:1, n:1) wird automatisch aus den Definitionen der Daten und der Primärschlüssel abgeleitet.
Bemerkung
Im Gegensatz zu älteren semantischen Modellen erfordern semantische Ansichten keine expliziten join_type- oder relationship_type-Spezifikationen. Diese werden automatisch ermittelt.
Filter¶
Filter definieren häufig verwendete Filterbedingungen, die über den Namen referenziert werden können. Dadurch wird eine konsistente Filterlogik über alle Abfragen hinweg sichergestellt.
Beispiel:
Geprüfte Abfragen¶
Verifizierte Abfragen sind Beispielfragen mit den entsprechenden SQL-Abfragen. Sie unterstützen Cortex Analyst dabei zu verstehen, wie ähnliche Fragen beantwortet werden können, und dienen als Dokumentation für Benutzende.
Eigenschaften:
question: Frage in natürlicher Sprachesql: SQL-Abfrage, die die Frage beantwortetverified_by: Optional die Person, die verifiziert hat, dass die Abfrage korrekt istverified_at: Optionaler Zeitstempel der Überprüfunguse_as_onboarding_question: Optionales Flag, um dies den Benutzenden als Vorschlag anzuzeigen
Zugriffsmodifikatoren¶
Semantische Ansichten unterstützen Zugriffsmodifikatoren für Fakten und Kennzahlen, mit denen Sie die Sichtbarkeit steuern können:
public_access(Standard): Für Benutzende sichtbar und abfragbarprivate_access: Für Abfragen verborgen, wird nur für Zwischenberechnungen verwendet
Beispiel:
Kundenspezifische Anweisungen in Cortex Analyst¶
Sie können SQL-Befehle verwenden, um benutzerdefinierte Anweisungen in der Definition der semantischen Ansicht bereitzustellen. Diese Anweisungen steuern, wie die Abfragen generiert und die Fragen kategorisiert werden. Diese Anweisungen sind nicht Teil der YAML-Spezifikation, werden jedoch mit dem Befehl CREATE SEMANTIC VIEW festgelegt.
Weitere Informationen dazu finden Sie unter Bereitstellung kundenspezifischer Anweisungen für Cortex Analyst.
Beispiel für eine semantische YAML-Ansicht¶
Hier ist ein vollständiges Beispiel für eine semantische Ansicht einer YAML-Spezifikation:
Erstellen einer semantischen Ansicht aus YAML¶
Verwenden Sie zum Erstellen einer semantischen Ansicht anhand einer YAML-Spezifikation die gespeicherte Prozedur SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML.
Weitere Informationen dazu finden Sie unter Semantischen Ansicht aus einer YAML-Spezifikation erstellen.
Abrufen von YAML aus einer semantischen Ansicht¶
Um eine semantische Ansicht in das YAML-Format zu exportieren, verwenden Sie die Funktion SYSTEM$READ_YAML_FROM_SEMANTIC_VIEW.
Weitere Informationen dazu finden Sie unter YAML-Spezifikation für eine semantische Ansicht abrufen.
Unterschiede zu älteren semantischen Modellen¶
Wenn Sie von YAML-Dateien eines älteren semantischen Modells zu semantischen Ansichten migrieren, beachten Sie folgende wichtige Unterschiede:
Feature |
Ältere semantische Modelle |
Semantische Ansichten |
|---|---|---|
Speicher |
YAML-Dateien in Stagingbereichen |
Objekte auf Schemaebene in Datenbank |
Berechtigungen |
Stagingbereich-basierte Zugriffssteuerung |
Vollständige Snowflake RBAC-Integration |
Freigeben |
Manuelle Dateifreigabe |
Native Snowflake-Freigabe |
Join-Typen |
Erfordert |
Automatisch abgeleitet |
Abgeleitete Kennzahlen |
Nicht unterstützt |
Vollständig unterstützt |
Zugriffsmodifikatoren |
Nicht unterstützt |
|
Kundenspezifische Anweisungen |
In YAML-Datei |
Über SQL-Befehle festgelegt |
Bei der Konvertierung von einem älteren semantischen Modell in eine semantische Ansicht:
join_typeundrelationship_typeaus Beziehungen entfernenDie Verwendung abgeleiteter Kennzahlen für Berechnungen auf Ansichtsebene in Erwägung ziehen
access_modifierzu Fakten/Kennzahlen hinzufügen, die privat gemacht werden sollenVerschieben kundenspezifischer Anweisungen zum Befehl SQL CREATE SEMANTIC VIEW
