Tagi pochodzenia modeli semantycznych usługi Power BI
Można użyć tagów pochodzenia w obiektach modelu semantycznego, aby umożliwić stabilną identyfikację takich obiektów w różnych modelach semantycznych. Użycie tagów pochodzenia umożliwia korzystanie z funkcji usługi Power BI, takich jak modele złożone , aby zachować powiązanie z przywoływanych tabelami lub kolumnami (przy użyciu SourceLineageTag), nawet jeśli nazwa obiektu modelu semantycznego źródłowego zostanie zmieniona.
Tagi pochodzenia muszą być unikatowe w ich zakresie; na przykład dwie tabele w tym samym modelu semantycznym nie mogą mieć tego samego tagu pochodzenia. Program Power BI Desktop zazwyczaj przypisuje identyfikator GUID dla każdego obiektu modelu semantycznego wymagającego pochodzenia, ale takie przypisanie nie jest obowiązkowe, a tagi pochodzenia można zmienić na inny format ciągu.
Śledzenie dostosowań użytkowników w modelach semantycznych
Modele semantyczne mogą zawierać obiekty i właściwości pochodzące z innych modeli lub źródeł danych. Na przykład podczas tworzenia modelu złożonego w modelach semantycznych usługi Power BInazwy tabel i kolumn, typów danych, ciągów formatu i innych właściwości pochodzących z modelu źródłowego.
Podczas dostosowywania właściwości lub usuwania obiektów w modelu, które zostały zsynchronizowane ze źródła danych, usługa Power BI oczekuje zmienioną właściwośćWłaściwości i PBI_RemovedChildren adnotacji, aby wskazać dostosowanie użytkownika, tak aby dostosowania były zachowywane podczas następnej synchronizacji schematu ze źródłem danych.
Następujące obiekty/właściwości są synchronizowane ze źródłem danych i wymagają zadeklarowania zarówno wszelkich zmodyfikowanych właściwości, jak i usuwania obiektów:
Scenariusz | Obiektów | Dostosowywanie właściwości | Dostosowywanie usuwania |
---|---|---|---|
Importowanie/zapytanie bezpośrednie | Tabele, kolumny, relacje | Nazwa, Typ danych | Relacje 1 |
Kompozytowe | Tabele, kolumny, relacje, miary, hierarchie, poziomy | Name, DataType, IsHidden, FormatString, Description, SummarizeBy, DataCategory, SortByColumn, GroupByColumns, DisplayFolder, IsNullable | Wszystkie tabele w modelu zdalnym nieuwzględniane w modelu lokalnym |
DirectLake | Tabele, kolumny | Nazwa, Typ danych | Wszystkie tabele w usłudze Lakehouse nieuwzględniane w modelu |
[1] usługa Power BI automatycznie tworzy relacje na podstawie podstawowych i obcych informacji z źródła danych. Jeśli użytkownicy usuwają te relacje, usługa Power BI śledzi zmiany, aby zapobiec ponownemu dodawaniu ich podczas przyszłej synchronizacji schematów.
Kolekcja ChangedProperties
Kolekcja ChangedProperties umożliwia określenie, które wartości właściwości obiektu zostały zmodyfikowane, co oznacza, że te wartości nie mogą być już synchronizowane ze źródłem.
Na przykład podczas tworzenia modelu złożonego w modelach semantycznych usługi Power BI nazwy kolumn pochodzą z modelu źródłowego. Jeśli zmienisz nazwę kolumny w modelu lokalnym, musisz określić właściwość Nazwa jako zmienioną właściwość.
W poniższym przykładzie nazwa kolumny ProductID z modelu źródłowego została zmieniona na ProductKey:
table Products
column ProductKey
dataType: int64
lineageTag: 9636345e-0328-43fb-acd3-e7894734d08a
sourceLineageTag: 6890686b-4899-4916-9ec2-2e8ff5a05eb7
sourceColumn: ProductID
changedProperty = Name
Adnotacja PBI_RemovedChildren
Adnotacja PBI_RemovedChildren to adnotacja modelu zadeklarowana na obiekcie nadrzędnym usuniętego elementu, która deklaruje zamiar wykluczania obiektu użytkownika z obiektu lokalnego. Na przykład podczas konstruowania modelu złożonego można wybrać tabele do załadowania, a wszystkie nieznajdujące się tabele znajdują się w adnotacji PBI_RemovedChildren przechowywanej w NamedExpression źródła danych. W modelach Import i DirectQuery adnotacja jest przechowywana w modelu w celu śledzenia usuwania relacji.
Brak deklarowania tej adnotacji powoduje pobranie obiektów modelu semantycznego podczas synchronizacji schematu ze źródłem.
W poniższym przykładzie tabela jest usuwana z modelu złożonego. Tag pochodzenia tabeli modelu źródłowego jest używany zamiast jego nazwy w celu zapewnienia stabilnej identyfikacji:
expression 'DirectQuery to AS - AdventureWorks' =
let
Source = AnalysisServices.Database("[XMLA Endpoint]"),
Cubes = Table.Combine(Source[Data]),
Cube = Cubes{[Id="Model", Kind="Cube"]}[Data]
in
Cube
annotation PBI_RemovedChildren = [{"remoteItemId":{"analysisServicesObject":{"sourceName":null,"sourceLineageTag":"8e47b52e-1c1a-4029-b6cc-25200d213fcf"}},"objectType":"Table"}]
Zagadnienia i ograniczenia
- W przypadku modeli Import/DirectQuery zmienionoWłaściwość jest wymagana tylko wtedy, gdy nie można złożyć zmiany w zapytaniu M tabeli, na przykład w tabelach DirectQuery korzystających z zapytania natywnego.
- W przypadku modeli DirectLake sourceLineageTag musi być nazwą tabeli/kolumny w magazynie lakehouse/data warehouse.
Następny krok
Następujące artykuły zawierają przydatne dodatkowe informacje:
- obsługa zapisu modelu przy użyciu punktu końcowego XMLA
- modyfikacje XMLA i modele złożone