Tabellarische Modelldefinitionssprache (TMDL)
Gilt für: SQL Server 2016 und höher Analysis Services Azure Analysis Services Fabric/Power BI Premium
Wichtig
Die Tabellarische Modelldefinitionssprache (TMDL) befindet sich derzeit in der Vorschauphase. Funktionalität und Dokumentation von Vorschauversionen unterliegen wahrscheinlich Änderungen.
Die Tabellenmodelldefinitionssprache (Tabular Model Definition Language, TMDL) ist eine Objektmodelldefinitionssyntax für tabellarische Datenmodelle mit Kompatibilitätsgrad 1200 oder höher.
Zu den wichtigsten Elementen von TMDL gehören:
- Vollständige Kompatibilität mit dem gesamten tabellarischen Objektmodell (TOM) Jedes TMDL-Objekt macht dieselben Eigenschaften wie TOM verfügbar.
- Textbasiert und optimiert für menschliche Interaktion und Lesbarkeit. TMDL verwendet eine Grammatiksyntax ähnlich YAML. Jedes TMDL-Objekt wird in Text mit minimalen Trennzeichen dargestellt und verwendet den Einzug, um beziehungen zwischen übergeordnetem und untergeordnetem Element zu markieren.
- Bessere Bearbeitungserfahrung, insbesondere für Eigenschaften mit Einbettungsausdrücken aus verschiedenen Inhaltstypen, z. B. Data Analysis Expression (DAX) und M.
- Besser für die Zusammenarbeit aufgrund seiner Ordnerdarstellung, in der jedes Modellobjekt eine individuelle Dateidarstellung aufweist, wodurch es quellcodeverwaltungsfreundlicher wird.
Ein wichtiger Aspekt von TMDL ist die Verwendung des Leerzeicheneinzugs zum Bezeichnen einer TOM-Objektstruktur. Das folgende Beispiel zeigt, wie einfach es ist, ein tabellarisches Modell bei Verwendung von TMDL darzustellen:
database Sales
compatibilityLevel: 1567
model Model
culture: en-US
table Sales
partition 'Sales-Partition' = m
mode: import
source =
let
Source = Sql.Database(Server, Database)
…
measure 'Sales Amount' = SUMX('Sales', 'Sales'[Quantity] * 'Sales'[Net Price])
formatString: $ #,##0
column 'Product Key'
dataType: int64
isHidden
sourceColumn: ProductKey
summarizeBy: None
column Quantity
dataType: int64
isHidden
sourceColumn: Quantity
summarizeBy: None
column 'Net Price'
dataType: int64
isHidden
sourceColumn: "Net Price"
summarizeBy: none
table Product
partition 'Product-Partition' = m
mode: import
source =
let
Source = Sql.Database(Server, Database),
…
column 'Product Key'
dataType: int64
isKey
sourceColumn: ProductKey
summarizeBy: none
relationship cdb6e6a9-c9d1-42b9-b9e0-484a1bc7e123
fromColumn: Sales.'Product Key'
toColumn: Product.'Product Key'
role Role_Store1
modelPermission: read
tablePermission Store = 'Store'[Store Code] IN {1,10,20,30}
expression Server = "localhost" meta [IsParameterQuery=true, Type="Text", IsParameterQueryRequired=true]
expression Database = "Contoso" meta [IsParameterQuery=true, Type="Text", IsParameterQueryRequired=true]
TMDL-Ordnerstruktur
Im Gegensatz zu TMSL verwendet TMDL eine Ordnerstruktur. Die Standardordnerstruktur verfügt nur über eine Ebene von Unterordnern, die alle tmdl-Dateien enthalten:
- cultures
- Perspektiven
- roles
- Tabellen
Und Stammdateien für:
- database
- model
- relationships
- Ausdrücke
- datasources
Hier sehen Sie ein Beispiel für einen TMDL-Ordner:
Zu den Definitionen gehören:
- Eine Datei für die Datenbankdefinition.
- Eine Datei für die Modelldefinition.
- Eine Datei für alle Datenquellen im Modell.
- Eine Datei für alle Ausdrücke im Modell.
- Eine Datei für alle Beziehungen im Modell.
- Eine Datei für jedes linguistische Kulturschema.
- Eine Datei für jede Perspektive.
- Eine Datei für jede Rolle.
- Eine Datei für jede Tabelle.
- Alle inneren Metadateneigenschaften von Tabellen (Spalten, Hierarchien, Partitionen,...) metadaten befinden sich in der TMDL-Datei der übergeordneten Tabelle.
TMDL-API
Ähnlich wie die Tabular Model Scripting Language (TMSL) gibt es eine Klasse zum Verarbeiten der TMDL-Serialisierung. Für TMDL ist die Klasse TmdlSerializer unter dem Microsoft.AnalysisServices.Tabular-Namespace .
Die TmdlSerializer-Klasse macht Methoden zum Serialisieren und Deserialisieren von TMDL-Dokumenten verfügbar:
Ordnerserialisierung
public static void SerializeDatabaseToFolder (Database database, string path)
- Empfängt ein TOM-Datenbankobjekt und den TMDL-Ausgabepfad.
- Serialisiert die TOM-Datenbank in eine TMDL-Ordnerdarstellung.
Erfahren Sie mehr über das Serialisieren in einen Ordner.
public static Database DeserializeDatabaseFromFolder (string path)
- Empfängt einen vollständigen Pfad zu einem TMDL-Ordner.
- Gibt die Darstellung des TOM-Datenbankobjekts des Ordners TMDL zurück.
Erfahren Sie mehr über das Deserialisieren von Ordnern.
Zeichenfolgenserialisierung
public static string SerializeObject (MetadataObject object, bool qualifyObject = true)
- Empfängt ein TOM-Objekt und gibt dessen TMDL-Textdarstellung zurück.
Erfahren Sie mehr darüber, wie Sie ein Objekt in eine Zeichenfolge serialisieren.
Stream-Serialisierung
Sie können TMDL zu/aus Streams serialisieren/deserialisieren, sodass Sie ein TOM-Objekt in Bytedatenströme für die speicherung, übertragung und plattformübergreifende Interoperabilität konvertieren können. Mit der Stream-API können Sie auch steuern, welche TMDL-Dokumente geladen werden und welche TMDL-Dokumente ausgegeben werden.
Die TMDL Stream-Serialisierung wird von der MetadataSerializationContext-Klasse verarbeitet.
Erfahren Sie mehr darüber, wie Sie mithilfe von Streams zu/aus TMDL serialisieren.
TMDL-Sprache
Objektdeklaration
Mit Ausnahme des Serverobjekts macht TMDL die gesamte TOM Database-Objektstruktur im Microsoft.AnalysisServices.Tabular-Namespace verfügbar.
Ein TMDL-Objekt wird deklariert, indem der TOM-Objekttyp gefolgt von seinem Namen angegeben wird. Im folgenden Codebeispiel wird jeder Objekttyp: model
, table
gefolgt column
von einem Objektnamen.
model Model
culture: en-US
table Sales
measure Sales = SUM(…)
formatString: $ #,##0
column 'Customer Key'
datatype: int64
sourceColumn: CustomerKey
Objekte wie partition
oder measure
verfügen über Standardeigenschaften , die nach dem Trennzeichen gleich (=) in derselben Zeile der Objektdeklaration oder in der folgenden Zeile für einen mehrzeiligen Ausdruck zugewiesen werden können:
table Sales
partition Sales-Part1 = m
mode: import
...
measure Sales = SUM(…)
formatString: $ #,##0
measure 'Sales (ly)' =
var ly = ...
return ly
formatString: $ #,##0
Der TMDL-Objektname muss in einzelne Anführungszeichen (') eingeschlossen werden, wenn er eines der folgenden Zeichen enthält:
- Punkt (.)
- Gleich (=)
- Doppelpunkt (:)
- Einzelnes Anführungszeichen (')
- Leerzeichen ( )
Wenn ein Objektname einzelne Anführungszeichen (') enthält, verwenden Sie zwei einzelne Anführungszeichen, um ihn zu escapen.
Objekteigenschaften
Objekteigenschaften werden nach dem mehrzeiligen Ausdruck der Objektdeklaration oder der Objektstandardeigenschaft angegeben. Objekteigenschaftenwerte werden nach dem Doppelpunkttrennzeichen (:) angegeben. Beispiel:
table Sales
lineageTag: e9374b9a-faee-4f9e-b2e7-d9aafb9d6a91
column Quantity
dataType: int64
isHidden
isAvailableInMdx: false
sourceColumn: Quantity
measure 'Sales Amount' =
var result = SUMX(...)
return result
formatString: $ #,##0
displayFolder: " My ""Amazing"" Measures"
Die folgenden Regeln gelten für Eigenschaftswerte:
Der Wert muss sich in derselben Zeile nach dem Doppelpunkt befinden und darf nicht über mehrere Zeilen verfügen.
Texteigenschaftenwerte
- Führende und nachfolgende Double-Anführungszeichen sind optional und werden während der Serialisierung automatisch entfernt.
- Muss in doppelte Anführungszeichen (") eingeschlossen werden, wenn der Text nachfolgendes oder führendes Leerzeichen enthält.
- Wenn der Wert in doppelte Anführungszeichen eingeschlossen ist, verwenden Sie zwei doppelte Anführungszeichen, um sie zu escapen (siehe
displayFolder
Eigenschaft im obigen Codebeispiel).
Boolesche Eigenschaften können mithilfe der standardmäßigen Schlüssel-Wert-Paarsyntax festgelegt werden, z. B. mit der
'isAvailableInMdx'
-Eigenschaft im vorherigen Beispiel. Sie können auch mithilfe einer Tastenkombinationssyntax festgelegt werden, bei der nur der Eigenschaftsname deklariert undtrue
impliziert wird. Siehe beispielsweise die Eigenschaft "isHidden" im vorherigen Beispiel.
Verweise auf benannte Objekte
Einige Objekteigenschaften enthalten Verweise auf andere Modellobjekte, z. B.:
- Spaltenverweis in Hierarchieebenen.
- SortByColumn-Verweis in jeder Tabellenspalte.
- Tabelle/Spalte/Measurereferenz in Perspektiven.
In TMDL werden Verweise unter Verwendung des Objektnamens erstellt und folgen den gleichen Escaping- und Single-Anführungszeichen (') einschließenden Anforderungen für die Objektdeklaration. Im folgenden Codebeispiel werden Objekteigenschaften angezeigt, die einen Verweis auf ein anderes Objekt enthalten: column.sortByColumn
, level.column
und perspectiveMeasure.measure
perspectiveTable.table
.
table Product
column Category
sortByColumn: 'Category Order'
hierarchy 'Product Hierarchy'
level Category
column: Category
perspective Product
perspectiveTable Product
perspectiveMeasure '# Products'
Falls erforderlich, um auf einen vollqualifizierten Namen zu verweisen, verwendet TMDL die Punktnotation , um auf ein Objekt zu verweisen, z. B.: 'Table 1'.'Column 1'
Untergeordnete Objekte
Die TOM-Objektstruktur enthält untergeordnete Objekte an vielen Stellen und auf verschiedenen Ebenen. Beispiel:
- Ein Modellobjekt enthält Tabellen-, Rollen- und Ausdrucksobjekte.
- Ein Tabellenobjekt enthält Spalten-, Measure- und Hierarchieobjekte.
TMDL deklariert untergeordnete Auflistungen nicht explizit. Stattdessen bilden alle anwendbaren untergeordneten Elemente innerhalb des Bereichs ihres jeweiligen übergeordneten Elements implizit die Elemente der entsprechenden Auflistung. Beispielsweise werden alle Spaltenelemente innerhalb des Bereichs einer bestimmten Tabelle zu Elementen der Spaltenauflistung dieser Tabelle in TOM, wie hier gezeigt:
table Sales
measure 'Sales Amount' = SUMX('Sales', [Quantity] * [Net Price])
measure 'Total Quantity' = SUM('Sales'[Quantity])
measure 'Sales Amount YTD' = TOTALYTD([Sales Amount], 'Calendar'[Date])
Untergeordnete Objekte müssen nicht zusammenhängend sein. Beispielsweise können Sie Spalten und Measures in beliebiger Reihenfolge und Interminierung deklarieren.
Standardeigenschaften
Einige Objekttypen verfügen über eine Standardeigenschaft, die in den meisten Fällen wie Ausdrücke behandelt wird. Die Standardeigenschaft ist objekttypspezifisch. Falls zutreffend, wird der Eigenschaftswert oder Ausdruck nach dem Gleichheitstrennzeichen (=) nach der Abschnittsdeklaration angegeben.
Unterstützte Syntax:
- Der Wert wird in derselben Zeile wie der Abschnittsheader angegeben.
- Der Wert wird als mehrzeiligen Ausdruck nach dem Abschnittsheader angegeben.
Im folgenden Codebeispiel sind Measure Sales Amount
und Partition Sales-Partition1
einzeilig, und measure Quantity
ist mehrzeilig:
table Sales
measure 'Sales Amount' = SUM(...)
formatString: $ #,##0
measure Quantity =
var result = SUMX (...)
return result
formatString: #,##0
partition Sales-Partition1 = m
mode: import
source =
let
...
in
finalStep
Ausdrücke
Es gibt Objekteigenschaften, die zwar eine Texteigenschaft in TOM sind, aber spezielle Analysevorgänge in TMDL erhalten. Der gesamte Text wird wörtlich gelesen, da er Sonderzeichen wie Anführungszeichen oder eckige Klammern in M- oder DAX-Ausdrücken enthalten kann. Ausdrücke können mehrzeilig oder einzeilig sein. Bei mehrzeiligen Zeilen müssen sie sich in der Zeile befinden, die unmittelbar auf die Eigenschafts- oder Objektdeklaration folgt.
Ein Ausdruckswert in TMDL wird nach einem Gleichheitstrennzeichen (=) angegeben, wie im folgenden Beispiel:
table Table1
partition 'partition 1' = m
mode: import
source =
let
...
in
finalStep
measure Measure1 = SUM(...)
measure Measure2 =
var result = SUMX (
...
)
return result
formatString: $ #,##0
Die folgenden speziellen Regeln gelten für Ausdrücke:
- Mehrzeilige Ausdrücke müssen eine Ebene tiefer in die Eigenschaften des übergeordneten Objekts eingerückt werden, und der gesamte Ausdruck muss sich innerhalb dieser Einzugsebene befinden.
- Alle äußeren Einzugsweißräume werden über die Einzugsebene des übergeordneten Objekts hinaus entfernt.
- Vertikale Leerzeichen (leere Zeilen ohne Leerzeichen) sind zulässig und werden als Teil des Ausdrucks betrachtet.
- Nachfolgende leerer Zeilen und Leerzeichen werden entfernt.
- Um einen anderen Einzug zu erzwingen oder nachfolgende Leerzeilen oder Leerzeichen beizubehalten, verwenden Sie die umschließenden drei Rückticks (```).
- Standardmäßig wird das TMDL-Serialisierungsprogramm in Backticks eingeschlossen, wenn der Ausdruckswert etwas enthält, das eine Änderung auf Roundtrips verursachen kann (z. B. nachfolgende Leerzeichen, leerer Zeilen mit Leerzeichen).
Ausdrücke, die mit drei Backticks (```) eingeschlossen sind, werden wörtlich gelesen, einschließlich Einzug, Leerzeilen und Leerzeichen. Das Trennzeichen sollte unmittelbar nach dem Gleichheitszeichen (=) und der Zeile nach dem Ausdruck angewendet werden, und es kann nichts mehr hinter dem Ausdruck enthalten, wie im folgenden Beispiel gezeigt:
table Table1
partition partition1 = m
mode: import
source = ```
let
...
in
finalStep
```
measure Measure1 = ```
var myVar = Today()
…
return result
```
Die Verwendung des Trennzeichens der drei Backticks (```) ist optional und nur in eindeutigen Situationen erforderlich. In den meisten Fällen stellt die Verwendung des korrekten Einzugs und der Objektdeklaration die korrekte Analyse des Ausdrucks sicher, den Sie der -Eigenschaft hinzufügen.
Wenn der Ausdruck in Backticks eingeschlossen wird, gelten die folgenden Regeln:
- Alles zwischen drei Backticks (```) wird als Teil des Multiblockausdrucks betrachtet, und TMDL-Einzugsregeln werden nicht angewendet. Das Endtrennzeichen bestimmt den Einzug innerhalb des Ausdrucks.
- Der relative Einzug innerhalb des Ausdrucks wird beibehalten. Das Endtrennzeichen (```) bestimmt die linke Grenze des Ausdrucks (siehe "Measure1" im vorherigen Beispiel).
Die folgenden Eigenschaften werden als Ausdrücke behandelt:
Objekttyp | Eigenschaft | Ausdruckssprache |
---|---|---|
"Measure" | Ausdruck (Expression) | DAX |
MPartitionSource | Ausdruck | M |
CalculatedPartitionSource | Ausdruck (Expression) | DAX |
QueryPartitionSource | Abfrage | NativeQuery |
CalculationItem | Ausdruck (Expression) | DAX |
BasicRefreshPolicy | SourceExpression, PollingExpression | M |
KPI | StatusExpression, TargetExpression, TrendExpression | DAX |
LinguisticMetadata | Inhalt | XML oder Json |
JsonExtendedProperty | Wert | Json |
FormatStringDefintion | Ausdruck (Expression) | DAX |
DataCoverageDefinition | Ausdruck (Expression) | DAX |
CalculationGroupExpression | Ausdruck (Expression) | DAX |
NamedExpression | Ausdruck (Expression) | DAX |
DetailRowsDefinition | Ausdruck (Expression) | DAX |
TablePermission | FilterExpression | DAX |
CalculatedColumn | Ausdruck (Expression) | DAX |
Standardeigenschaften nach Objekttyp
Die folgende Tabelle zeigt die Standard-Eigenschafts- und Ausdruckssprache nach Objekttyp:
Objekttyp | Standardeigenschaft | Ausdruckssprache |
---|---|---|
"Measure" | Ausdruck (Expression) | DAX |
CalculatedColumn | Ausdruck (Expression) | DAX |
CalculationItem | Ausdruck (Expression) | DAX |
FormatStringDefinition | Ausdruck (Expression) | DAX |
DetailRowsDefinition | Ausdruck (Expression) | DAX |
CalculationExpression | Ausdruck (Expression) | DAX |
DataCoverageDefinition | Ausdruck (Expression) | DAX |
TablePermission | FilterExpression | DAX |
ColumnPermission | MetadataPermission | MetadataPermission-Enumeration |
NamedExpression | Ausdruck | M |
MPartitionSource | Ausdruck | M |
CalculatedPartitionSource | Ausdruck (Expression) | DAX |
JsonExtendedProperty | Wert | Json |
Anmerkung | Wert | Text |
StringExtendedProperty | Wert | Text |
DataSource | Typ | DataSourceType-Enumeration |
Partition | SourceType | PartitionSourceType-Enumeration |
ChangedProperty | Eigenschaft | Eigenschaftstext |
ExternalModelRoleMember | MemberType | RoleMemberType-Enumeration |
Beliebige benutzerdefinierte JSON-Eigenschaft (z. B. DataAccessOptions) | JSON-Dokument | Json |
LinguisticMetadata | Inhalt | Json |
Beschreibungen
TMDL bietet erstklassige Unterstützung für Beschreibungen. Zu Modelldokumentationszwecken besteht die bewährte Methode darin, Beschreibungen für jedes TOM-Objekt bereitzustellen. TMDL behandelt Beschreibungen als spezielle Eigenschaft mit expliziter Syntaxunterstützung. Anhand der Beispiele aus vielen anderen Sprachen werden Beschreibungen über jeder Objektdeklaration mithilfe von Dreistrichssyntax (///) angegeben.
Zwischen dem Beschreibungsblockende und dem Objekttyptoken ist kein Leerzeichen zulässig.
Beschreibungen können auf mehrere Zeilen aufgeteilt werden. Das TMDL-Serialisierungsprogramm unterbricht Objektbeschreibungen in mehrere Zeilen, um ausgegebene Dokumentzeilen unter der maximalen Länge zu halten. Die maximale Standardlänge beträgt 80 Zeichen.
/// Table Description
table Sales
/// This is the Measure Description
/// One more line
measure 'Sales Amount'' = SUM(...)
formatString: #,##0
Partielle Deklaration
TMDL erzwingt keine Objektdeklaration im selben Dokument. Sie ähnelt jedoch partiellen C#-Klassen , bei denen es möglich ist, die Objektdefinition auf mehrere Dateien aufzuteilen. Beispielsweise können Sie eine Tabellendefinition in einer [table].tmdl-Datei deklarieren und dann alle Measures aus allen Tabellen in einer einzigen [measures].tmdl-Datei definieren lassen, wie hier gezeigt:
table Sales
measure 'Sales Amount' = SUM(…)
formatString: $ #,##0
table Product
measure CountOfProduct = COUNTROWS(…)
Um einen Analysefehler zu vermeiden, kann dieselbe Eigenschaft nicht zweimal deklariert werden. Beispielsweise führt das Deklarieren von zwei Measures mit demselben Namen für dieselbe Tabelle in zwei verschiedenen TMDL-Dokumenten zu einem Fehler.
Objektverweise
Sie können mithilfe des verweis-Schlüsselwort (keyword) gefolgt vom Objekttyp und -namen auf ein anderes TMDL-Objekt verweisen.
Wenn Sie beispielsweise ein Column-Objekt mithilfe der Zeichenfolgenserialisierungs-API serialisieren, lautet das Ergebnis:
ref table Table1
column Column1
datatype: int64
sourceColumn: Column1
Deterministische Sammlungsreihenfolge
Der Verweis Schlüsselwort (keyword) wird auch verwendet, um die Sammlungsreihenfolge für TOM <> TMDL-Roundtrips zu definieren und beizubehalten. Es ist besonders wichtig, die Quellcodeverwaltung diff auf TMDL-Objekte zu vermeiden, die in einzelne Dateien serialisiert werden: Tabellen, Rollen, Kulturen und Perspektiven. Der verweis Schlüsselwort (keyword) wird für die TMDL-Datei des übergeordneten Objekts verwendet, um die Elementreihenfolge aus TOM zu deklarieren:
model Model
ref table Calendar
ref table Sales
ref table Product
ref table Customer
ref table About
ref culture en-US
ref culture pt-PT
ref role 'Stores Cluster 1'
ref role 'Stores Cluster 2'
Die folgenden Regeln werden angewendet:
- Während der TMDL-Deserialisierung:
- Objekte, auf die in TMDL verwiesen wird, aber mit fehlender TMDL-Datei, werden ignoriert.
- Objekte, auf die nicht verwiesen wird, aber mit einer vorhandenen TMDL-Datei, werden am Ende der Auflistung angefügt.
- Während der TMDL-Serialisierung:
- Auf alle Auflistungsobjekte in TOM wird mithilfe des verweis-Schlüsselwort (keyword) verwiesen.
- Sammlungen mit nur einem Element geben keinen Verweis aus.
- Leere Zeilen werden nicht zwischen Refs ausgegeben, wenn derselbe Objekttyp gilt.
Eigenschaftswerttrennzeichen
Es gibt nur zwei Trennzeichen/Symbole, um einen Eigenschaftswert zuzuweisen:
Gleich (=)
- Wird bei der Objektdeklaration mit der Standardeigenschaft (mehrzeilig und einzeilig) verwendet.
- Wird für jede Ausdruckseigenschaft verwendet, z. B. partition.expression
Doppelpunkt (:)
- Wird für jeden Eigenschaftswert ohne Ausdruck verwendet. Einschließlich Eigenschaften, die Modellverweise enthalten.
Indentation
TMDL verwendet strenge Leerzeicheneinzugsregeln zum Bezeichnen der Struktur der TOM-Hierarchie. Ein TMDL-Dokument verwendet eine Standardeinzugsregel für einzelne Registerkarten .
Jedes Objekt kann drei Einzugsebenen aufweisen:
- Ebene 1: Objektdeklaration
- Ebene 2: Objekteigenschaften
- Ebene 3: Mehrzeilige Ausdrücke der Objekteigenschaft
- Ebene 2: Objekteigenschaften
Innerhalb eines TMDL-Dokuments wird der Einzug in den folgenden Fällen angewendet:
Zwischen einer Objektabschnittsüberschrift und den Eigenschaften des Objekts (Tabelle -> Eigenschaften).
table Sales isHidden lineageTag: 9a48bea0-e5fb-40fa-9e81-f61288e31a02
Zwischen einem Objekt und seinen untergeordneten Objekten (Tabelle -> Measures).
table Sales measure 'Sales Amount' = SUMX(...) measure 'Total Quantity' = SUM(...)
Zwischen einem Objekt und seinen mehrzeiligen Ausdrücken (Tabelle -> Measure -> Ausdruck).
table Sales measure 'Sales Amount' = var result = SUMX(...) return result formatString: $ #,##0
Mehrzeilige Ausdrücke müssen eine Ebene tiefer als Objekteigenschaften eingerückt werden, und der gesamte Ausdruck muss innerhalb dieser Einzugsebene liegen (siehe Ausdrücke).
Datenbank- und direkte untergeordnete Objekte von Model müssen nicht eingerückt werden, da implizit davon ausgegangen wird, dass sie unter dem Stammmodell oder der Datenbank geschachtelt sind:
- model
- Tabellen
- Freigegebene Ausdrücke
- roles
- cultures
- Perspektiven
- relationships
- Datenquellen
- Abfragegruppen
- Anmerkungen auf Modellebene
- Erweiterte Eigenschaften auf Modellebene
Wenn Sie diese Einzugsregeln nicht einhalten, wird ein Analysefehler generiert.
Leerraum
TMDL wendet standardmäßig die folgenden Regeln auf Leerzeichen innerhalb von Eigenschafts- und Ausdruckswerten an, wenn sie nicht in Backticks (```) oder doppelte Anführungszeichen (") eingeschlossen sind:
- Bei Eigenschaftswerten werden führende und nachfolgende Leerzeichen gekürzt.
- Bei Ausdrücken werden Leerzeichenzeilen am Ende von Ausdrücken gelöscht.
- Leerzeichenlinien werden auf leere Zeilen (keine Leerzeichen/Tabstopps) gekürzt.
Schreibweise
Standardmäßig verwenden TMDL-API für Serialisierung/Schreibvorgänge camelCase, angewendet auf:
- Objekttypen
- Schlüsselwörter
- Enumerationswerte
Beim Deserialisieren/Lesen wird bei der TMDL-API die Groß-/Kleinschreibung nicht beachtet.
Überlegungen und Einschränkungen
Verwandte Inhalte
Nachdem Sie sich mit TMDL vertraut machen, lesen Sie Erste Schritte mit TMDL , um zu erfahren, wie Sie eine TMDL-Modelldarstellung eines Power BI-Semantikmodells abrufen und bereitstellen.
Feedback
https://aka.ms/ContentUserFeedback.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unterFeedback senden und anzeigen für