Etiquetas de linaje para modelos semánticos de Power BI
Puede usar etiquetas de linaje en objetos de modelo semántico para permitir la identificación estable de estos objetos en diferentes modelos semánticos. El uso de etiquetas de linaje permite a las características de Power BI, como modelos compuestos, mantener su enlace a tablas o columnas a las que se hace referencia (mediante el uso de SourceLineageTag), incluso si se cambia el nombre del objeto del modelo semántico de origen.
Las etiquetas de linaje deben ser únicas dentro de su ámbito; por ejemplo, dos tablas del mismo modelo semántico no pueden tener la misma etiqueta de linaje. Power BI Desktop suele asignar un GUID para cada objeto de modelo semántico que requiera linaje, pero esta asignación no es obligatoria y las etiquetas de linaje se pueden cambiar a cualquier otro formato de cadena.
Importante
Si los objetos de modelo semántico no tienen una etiqueta de linaje, Power BI usa el nombre del objeto, lo que puede provocar la pérdida de personalizaciones si se cambia el nombre del objeto.
Seguimiento de personalizaciones de usuario en modelos semánticos
Los modelos semánticos pueden incluir objetos y propiedades derivados de otros modelos o orígenes de datos. Por ejemplo, al crear un modelo compuesto en modelos semánticos de Power BI, los nombres de tabla y columna, los tipos de datos, las cadenas de formato y otras propiedades se originan en el modelo de origen.
Al personalizar propiedades o quitar objetos del modelo que se han sincronizado desde el origen de datos, Power BI espera que la propiedad changedProperties y PBI_RemovedChildren anotación que se establezca para indicar una personalización de usuario para que las personalizaciones se mantengan durante la siguiente sincronización de esquemas con el origen de datos.
Los siguientes objetos o propiedades se sincronizan con el origen de datos y requieren que declare las propiedades modificadas y las eliminaciones de objetos:
| Escenario | Objetos | Personalización de propiedades | Personalización de eliminación |
|---|---|---|---|
| Import/DirectQuery | Tablas, columnas, relaciones | Name, DataType | Relaciones 1 |
| Compuesto | Tablas, columnas, relaciones, medidas, jerarquías, niveles | Name, DataType, IsHidden, FormatString, Description, SummarizeBy, DataCategory, SortByColumn, GroupByColumns, DisplayFolder, IsNullable | Todas las tablas del modelo remoto no se incluyen en el modelo local |
| DirectLake | Tablas, columnas | Name, DataType | Todas las tablas de Lakehouse no incluidas en el modelo |
[1] Power BI crea automáticamente relaciones basadas en la información de clave principal y externa del origen de datos. Si los usuarios quitan esas relaciones, Power BI realiza un seguimiento de los cambios para evitar volver a agregarlas durante la futura sincronización de esquemas.
La colección ChangedProperties
La colección ChangedProperties permite especificar qué valores de propiedad de objeto se han modificado, lo que indica que esos valores ya no se pueden sincronizar con el origen.
Por ejemplo, al crear un modelo compuesto en modelos semánticos de Power BI, los nombres de columna se originan en el modelo de origen. Si cambia el nombre de una columna en el modelo local, debe especificar la propiedad Name
En el ejemplo siguiente, se cambió el nombre de la columna ProductID del modelo de origen a ProductKey:
table Products
column ProductKey
dataType: int64
lineageTag: 9636345e-0328-43fb-acd3-e7894734d08a
sourceLineageTag: 6890686b-4899-4916-9ec2-2e8ff5a05eb7
sourceColumn: ProductID
changedProperty = Name
Anotación de PBI_RemovedChildren
La anotación PBI_RemovedChildren es una anotación de modelo declarada en el objeto primario del elemento quitado que declara la intención del usuario de excluir un objeto del objeto local. Por ejemplo, al construir un modelo compuesto, puede elegir qué tablas cargary todas las tablas no seleccionadas se incluyen en la anotación PBI_RemovedChildren almacenada en el NamedExpression del origen de datos. En Los modelos Import y DirectQuery, la anotación se almacena dentro del modelo para realizar un seguimiento de las eliminaciones de relaciones.
No declarar esta anotación hace que los objetos de modelo semántico se recuperen durante la sincronización de esquemas con el origen.
En el ejemplo siguiente se quita una tabla del modelo compuesto. La etiqueta de linaje de la tabla del modelo de origen se usa en lugar de su nombre para garantizar una identificación estable:
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"}]
Consideraciones y limitaciones
- En el caso de los modelos Import/DirectQuery, el modificadoProperty solo es necesario cuando el cambio no se puede plegar en la consulta M de la tabla, como en tablas directQuery que usan una consulta nativa.
- En el caso de los modelos de DirectLake, el sourceLineageTag debe ser el nombre de la tabla o columna en el almacén de datos o lakehouse.
Paso siguiente
Los artículos siguientes contienen información adicional útil:
- compatibilidad de escritura del modelo con el punto de conexión XMLA
- modificaciones de XMLA y modelos compuestos