Tabellenobjektmodell (TOM)

Gilt für: SQL Server 2016 und höher analysis Services Azure Analysis Services Fabric/Power BI Premium

Das tabellarische Objektmodell (Tabular Object Model, TOM) ist eine Erweiterung der AMO-Clientbibliothek (Analysis Management Object), die zur Unterstützung von Programmierszenarien für tabellarische Modelle erstellt wurde, die mit Kompatibilitätsgrad 1200 und höher erstellt wurden. Wie bei AMO bietet TOM eine programmgesteuerte Möglichkeit, administrative Funktionen wie das Erstellen von Modellen, das Importieren und Aktualisieren von Daten sowie das Zuweisen von Rollen und Berechtigungen zu verarbeiten.

TOM macht native tabellarische Metadaten verfügbar, z. B. Modell, Tabellen, Spalten und Beziehungsobjekte . Eine allgemeine Ansicht der Objektmodellstruktur, die unten bereitgestellt wird, veranschaulicht, wie die Komponententeile miteinander verknüpft sind.

Da TOM eine Erweiterung von AMO ist, werden alle Klassen, die neue tabellarische Objekte darstellen, in einer neuen Microsoft.AnalysisServices.Tabular.dll-Assembly implementiert. Allgemeine Klassen von AMO wurden in die Microsoft.AnalysisServices.Core-Assembly verschoben. Ihr Code muss auf beide Assemblys verweisen. Weitere Informationen finden Sie unter Installieren, Verteilen und Verweisen auf das tabellarische Objektmodell (Microsoft.AnalysisServices.Tabular).

Die API ist für verwalteten .NET-Code verfügbar. Weitere Informationen zu bestimmten AMO/TOM-Klassen finden Sie unter Microsoft.AnalysisServices-Namespacereferenz. Die vollständige Liste der Programmieroptionen für tabellarische Modelle, einschließlich Der Unterstützung von Skripts und Abfragesprachen, finden Sie unter Programmierung von Tabellarischen Modellen für Kompatibilitätsgrad 1200.

Hierarchie des tabellarischen Objektmodells

Aus logischer Sicht bilden alle tabellarischen Objekte eine Struktur, deren Stamm ein Modell ist, das von Datenbank abstammt. Server und Datenbank werden nicht als tabellarisch betrachtet, da diese Objekte auch eine mehrdimensionale Datenbank darstellen können, die auf einem Server gehostet wird, der im mehrdimensionalen Modus ausgeführt wird, oder ein tabellarisches Modell mit einem niedrigeren Kompatibilitätsgrad, bei dem keine tabellarischen Metadaten für Objektdefinitionen verwendet werden.

Mit Ausnahme von AttributeHierarchy, KPI und LinguisticMetadata kann jedes untergeordnete Objekt Mitglied einer Auflistung sein. Das Model-Objekt enthält beispielsweise eine Auflistung von Table-Objekten (über die Tables-Eigenschaft ), wobei jedes Table-Objekt eine Auflistung von Column-Objekten enthält usw.

Der Nachfolger aller übergeordneten Objekte in dieser Hierarchie auf der niedrigsten Ebene ist ein Annotation-Objekt , das zum optionalen Erweitern des Schemas verwendet werden kann, solange Sie den Code für die Verarbeitung bereitstellen.

Objekthierarchiediagramm

TOM basiert auf der AMO-Infrastruktur, die auch mehrdimensionale und tabellarische Datenbanken mit Kompatibilitätsgraden unter 1200 bietet. Dies hat einige praktische Auswirkungen. Wenn Sie Objekte verwalten, die nicht in tabellenbezogenen Metadaten angegeben sind (z. B. ein Server oder eine Datenbank), müssen Sie Teile des vorhandenen AMO-Stapels nutzen, die diese Objekte beschreiben. Zusammen mit der Legacy-API ist das Konzept von Haupt- und Nebenobjekten, die präzise Beschreibungen des Objektzustands bereitstellen, wie er vom Server erkannt oder auf dem Server gespeichert wird. Die MajorObject-Klasse unter dem Microsoft.AnalysisServices-Namespace macht Methoden für Refresh und Update verfügbar. Nebenobjekte werden nur über das Hauptobjekt aktualisiert oder gespeichert, das sie enthält.

Wenn Sie hingegen Objekte verwalten, die Teil von tabellarischen Metadaten sind, z. B. Modell oder Tabelle, nutzen Sie einen völlig neuen tabellarischen Stapel. Innerhalb dieses Stapels werden Updates fein abgestuft. Dies bedeutet, dass jedes Metadatenobjekt, das von der MetadataObject-Klasse unter dem Microsoft.AnalysisServices.Tabular-Namespace abgeleitet wird, einzeln auf dem Server gespeichert werden kann. In der Regel würden Sie das gesamte Modell ermitteln. Anschließend nehmen Sie Änderungen an einzelnen Metadatenobjekten darunter vor, z. B. Tabelle oder Spalte. Anschließend rufen Sie die Model.SaveChanges() -Methode auf, die von Ihnen vorgenommene Änderungen auf differenzierter Ebene versteht und Befehle an den Server sendet, um nur die geänderten Objekte zu aktualisieren.

TOM und XMLA

Auf der Leitung verwendet TOM das XMLA-Protokoll, um mit dem Server zu kommunizieren und Objekte zu verwalten. Beim Verwalten nicht tabellarischer Objekte verwendet TOM ASSL, die Analysis Services Scripting Language-Erweiterung von XMLA. Bei der Verwaltung von tabellarischen Objekten verwendet TOM das tabellarische Protokoll MS-SSAS-T, ebenfalls eine Erweiterung von XMLA. Weitere Informationen finden Sie in der Dokumentation zum tabellenbasierten Protokoll MS-SSAS-T SQL Server Analysis Services.

TOM und JSON

Tabellarische Metadaten, die als JSON-Dokumente strukturiert sind, verfügen über eine neue Befehls- und Objektmodelldefinitionssyntax über die Tabular Model Scripting Language (TMSL). Die Skriptsprache verwendet JSON für den Text von Anforderungen und Antworten.

Obwohl sowohl TMSL als auch TOM die gleichen Objekte, Table, Column usw. und die gleichen Vorgänge verfügbar machen, verwendet Create, Delete, Refresh, TOM nicht TMSL on the wire. TOM verwendet stattdessen das tabellarische Protokoll MS-SSAS-T, wie bereits erwähnt.

Als Benutzer können Sie auswählen, ob Tabellarische Datenbanken über die TOM-Bibliothek aus Ihrem C#-Programm oder PowerShell-Skript oder über ein TMSL-Skript verwaltet werden sollen, das über PowerShell, SQL Server Management Studio (SSMS) oder einen SQL Server-Agent Auftrag ausgeführt wird.

Die Entscheidung, die eine oder die andere zu verwenden, hängt von den Besonderheiten Ihrer Anforderungen ab. Die TOM-Bibliothek bietet im Vergleich zu TMSL umfangreichere Funktionen. Während TMSL nur grob abstreckte Vorgänge auf Datenbank-, Tabellen-, Partitions- oder Rollenebene bietet, ermöglicht TOM Vorgänge mit einer viel feineren Körnung. Um Modelle programmgesteuert zu generieren oder zu aktualisieren, benötigen Sie den vollständigen Umfang der API in der TOM-Bibliothek.

Verwenden von TOM mit Power BI

Power BI Premium, Premium pro Benutzer und Power BI Embedded Arbeitsbereiche unterstützen verbindungen mit offenen Plattformen über den XMLA-Endpunkt. Mit dem XMLA-Endpunkt können benutzerdefinierte Tools, Skripts und automatisierte Prozesse für die Datenmodellierung und zum Ausführen von Arbeitsbereichs- und Semantikmodellverwaltungsaufgaben verwendet werden.

Bevor Sie eine .NET-Anwendung mit TOM für die Arbeit mit Power BI-Semantikmodellen erstellen, lesen Sie in der Power BI-Dokumentation die Semantische Modellkonnektivität mit dem XMLA-Endpunkt . In diesem Artikel wird beschrieben, wie Sie den XMLA-Endpunkt für Lese-/Schreibzugriff aktivieren, eine Arbeitsbereichsverbindungs-URL abrufen und andere wichtige Aspekte für die semantische Modellverwaltung mit benutzerdefinierten Apps, externen Tools und Skripts.

Weitere Informationen zur Verwendung des tabellarischen Objektmodells für die Verwaltung und Verwaltung von semantischen Modellen finden Sie unter Programmieren von Power BI-Semantikmodellen (TOM).

Weitere Informationen

Kompatibilitätsgrad für tabellarische Modelle
Analysis Services-Clientbibliotheken
XML for Analysis-Referenz (XMLA-Referenz)
Analysis Management Objects (AMO)