Udostępnij za pośrednictwem


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: