Conceptos de CSDLBI
Importante: Este documento está archivado. Para obtener la información más reciente, vea la especificación abierta [MS-CSDLBI]: formato de archivo de definición de esquemas conceptuales con anotaciones de inteligencia empresarial.
El lenguaje de definición de esquemas conceptuales con anotaciones BI (CSDLBI) se basa en Entity Data Framework, que es una abstracción para representar datos de una forma que permita el acceso, la consulta o la exportación de conjuntos de datos diversos mediante programación. CSDLBI se usa para representar los modelos de datos creados mediante Analysis Services porque admite aplicaciones y informes enriquecidos controlados por datos.
En esta sección se explica cómo se asigna la representación de CSDLBI Analysis Services modelos de datos (tabulares y multidimensionales), junto con ejemplos de cada tipo de modelo.
Los ejemplos usados para ilustrar estos conceptos se han tomado de la base de datos de ejemplo AdventureWorks, disponible en Codeplex. Para obtener más información sobre los ejemplos, vea Ejemplos de Adventure Works para SQL Server.
Estructura de un modelo tabular en CSDLBI
Un documento CSDLBI que describe un modelo de informe y sus datos comienza con la instrucción XSD, seguida de la definición de un modelo.
El modelo es un espacio de nombres, que contiene las siguientes entidades, asociaciones y propiedades principales:
EntityContainer enumera las tablas del modelo.
Cada tabla se muestra con EntityContainer como EntitySet.
Cada relación entre dos tablas se describe como un AssociationSet que define los puntos de conexión de relación y los roles de relación.
El elemento EntityType se extiende para BISM a fin de proporcionar detalles adicionales sobre las tablas y las columnas de ellas, incluidas las propiedades con fines de ordenación y visualización.
El elemento Measure define los cálculos que se pueden usar en el modelo. Una medida se puede convertir en un KPI agregando un conjunto de atributos de presentación especiales, mediante el nuevo elemento KPI .
No hay representación independiente de las perspectivas. Las columnas y tablas que no están incluidas en una perspectiva están presentes en el CSDL, pero marcadas con el atributo Hidden .
Entidades, EntitySets y EntityTypes
La noción de una entidad en Entity Data Framework se amplía para representar columnas y tablas del modelo de datos. En el extracto siguiente se muestra la lista de elementos EntitySet en un modelo simple que contiene solo tres tablas.
<EntityContainer Name="SimpleModel">
<EntitySet Name="DimCustomer"EntityType="SimpleModel.DimCustomer">
<bi:EntitySet />
</EntitySet>
<EntitySet Name="DimDate" EntityType="SimpleModel.DimDate">
<bi:EntitySet />
</EntitySet>
<EntitySet Name="DimGeography" EntityType="SimpleModel.DimGeography">
<bi:EntitySet />
</EntitySet> />
EntitySet no contiene información sobre las columnas o los datos de la tabla. La descripción detallada de las columnas y sus propiedades se proporcionan en el elemento EntityType.
El elemento EntitySet para cada entidad (tabla) incluye una colección de propiedades que definen la columna de clave, el tipo de datos y la longitud de la columna, nulabilidad, comportamiento de ordenación, etc. Por ejemplo, el extracto de CSDL siguiente describe tres columnas de la tabla Customer. La primera columna es una columna oculta especial que usa el modelo internamente.
<EntityType Name="Customer">
<Key>
<PropertyRef Name="RowNumber" />
</Key>
<Property Name="RowNumber" Type="Int64" Nullable="false">
<bi:Property Hidden="true" Contents="RowNumber"
Stability="RowNumber" />
</Property>
<Property Name="CustomerKey" Type="Int64" Nullable="false">
<bi:Property />
</Property>
<Property Name="FirstName" Type="String" MaxLength="Max" FixedLength="false">
<bi:Property />
</Property>
Para limitar el tamaño del documento CSDLBI que se genera, las propiedades que aparecen más de una vez en una entidad se especifican mediante una referencia a una propiedad existente, de modo que la propiedad solo se debe enumerar una vez para EntityType. La aplicación cliente puede obtener el valor de la propiedad mediante la búsqueda de EntityType que coincida con OriginEntityType.
Relaciones
En Entity Data Framework, las relaciones se definen como asociaciones entre entidades.
Las asociaciones siempre tienen exactamente dos extremos, uno que apunta a un campo o columna de una tabla. Por lo tanto, son posibles múltiples relaciones entre dos tablas, si las relaciones tienen extremos distintos. Un nombre de rol se asigna a los extremos de la asociación, e indica como se usa la asociación en el contexto del modelo de datos. Un ejemplo de un nombre de rol podría ser ShipTo, cuando se aplica a un identificador de cliente relacionado con el identificador de cliente en una tabla Orders.
La representación CSDLBI del modelo también contiene atributos en la asociación que determinan cómo se asignan las entidades entre sí en términos de la multiplicidad de la asociación. La multiplicidad indica si el atributo o la columna en el extremo de una relación entre tablas está en el lado uno de una relación o en el lado de varios. No hay ningún valor independiente para las relaciones uno a uno. Las anotaciones CSDLBI admiten la multiplicidad de 0 (lo que significa que la entidad no está asociada a nada) o 0..1, lo que significa una relación de uno a uno o una relación de uno a varios.
El ejemplo siguiente representa la salida CSDLBI para una relación entre las tablas Date y ProductInventory, donde las dos tablas están combinadas por la columna DateAlternateKey. Tenga en cuenta que, de forma predeterminada, el nombre de AssociationSet es el nombre completo de las columnas implicadas en la relación. No obstante, puede cambiar este comportamiento al diseñar el modelo, para usar otro formato de nomenclatura.
<AssociationSet Name="ProductInventory_Date_DateKey" Association="Model.ProductInventory_Date_DateKey">
<End EntitySet="ProductInventory" />
<End EntitySet="Date" />
<bi:AssociationSet />
</AssociationSet>
Propiedades de visualización y navegación
Una parte importante de las anotaciones CSDLBI son las propiedades para definir la presentación en el nivel de informe y para navegar por las relaciones entre las entidades. Normalmente, cuando se crea un modelo de datos, no se considera importante controlar cómo se ordenan o agrupan los datos, o cuál podría ser el valor predeterminado, en el suposición de que la aplicación cliente especificara la ordenación y otros detalles de presentación. Sin embargo, Analysis Services modelos tabulares están diseñados para la integración con el cliente de informes de Power View e incluye propiedades y atributos que admiten la presentación de entidades del modelo de datos en la superficie de diseño del informe.
Las extensiones para la visualización incluyen atributos para especificar la agregación predeterminada que se usará con datos numéricos, para indicar que un campo de texto apunta a una dirección URL de una imagen o para especificar el campo que se emplea para ordenar el campo actual.
Propiedades de nombre y convenciones de nomenclatura
El esquema CSDLBI indica que cada entidad tiene un nombre único y un identificador que se puede usar como clave. Además, algunas entidades pueden tener leyendas que usan para la visualización y nombres contextuales que cambian en función de dónde se usa la entidad.
El elemento Documentation ofrece a los diseñadores de informes la oportunidad de proporcionar una descripción de la entidad para ayudar a los usuarios empresariales a comprender el significado de los datos. Algunas entidades también permiten uno o varios atributos annotation , que proporcionan metadatos adicionales para su consumo por parte de la aplicación o de los clientes.
Al generar un modelo, Analysis Services herramientas, los nombres que se crean para los objetos siguen las convenciones de Analysis Services para la nomenclatura de objetos y la unidad de nombre. Sin embargo, dado que CSDLBI se basa en Entity Data Framework (EDF), que requiere que los nombres cumplan las convenciones de los identificadores de C#, cuando el servidor crea la salida de CSDLBI para un modelo, el servidor toma los nombres usados en el esquema de Analysis Services y crea automáticamente nuevos nombres de objeto que cumplen los requisitos de EDF. En la tabla siguiente se describen las operaciones por las que se generan los nuevos nombres.
Regla | Acción |
---|---|
Sin caracteres prohibidos | Los caracteres prohibidos se reemplazan por el carácter de subrayado. |
Los nombres deben ser únicos | Si dos cadenas son iguales, una se convierte en única anexando un carácter de subrayado además de un número |
Advertencia
Las leyendas y los calificadores tienen traducciones y, para un determinado idioma, uno u otro podría estar presente. Esto significa que en caso de que se concatenen un calificador y un nombre o un calificador y una leyenda, las cadenas podrían estar en dos idiomas distintos.
Adiciones para admitir modelos multidimensionales
La versión 1.0 de las anotaciones CSDLBI solo admitía modelos tabulares. En la versión 1.1 se agregó compatibilidad con los modelos multidimensionales (cubos OLAP) creados mediante herramientas tradicionales de desarrollo de BI. Por consiguiente, ahora se puede emitir una solicitud XML a un modelo multidimensional y recibir una definición CSDLBI del modelo, para su uso en los informes.
Cubos: Una SQL Server Analysis Services base de datos tabular solo puede contener un modo. En cambio, cada base de datos multidimensional puede contener varios cubos y cada base de datos está asociada a un cubo predeterminado. Por lo tanto, al emitir una solicitud XML en un servidor multidimensional, es necesario especificar el cubo; en caso contrario, se devolverá el XML del cubo predeterminado.
Por lo demás, la representación de un cubo es muy similar a la de una base de datos de modelo tabular. El nombre del cubo y el cubo corresponden al nombre de la base de datos tabular y al identificador de la base de datos.
Dimensiones: Una dimensión se representa en CSDLBI como una entidad (tabla) con columnas y propiedades. Tenga en cuenta que, incluso si no se incluye en una perspectiva, una dimensión incluida en el modelo se representará en la salida CSDL, marcada como Oculta.
Perspectivas: Un cliente puede solicitar CSDL para perspectivas individuales. Para obtener más información, vea DISCOVER_CSDL_METADATA Rowset.
Jerarquías: Las jerarquías se admiten y representan en CSDLBI como un conjunto de niveles.
Miembros: Se ha agregado compatibilidad con el miembro predeterminado y los valores predeterminados se agregan automáticamente a la salida de CSDLBI.
Miembros calculados: Los modelos multidimensionales admiten miembros calculados para el elemento secundario de Todos con un único miembro real.
Atributos de dimensión: En la salida de CSDLBI, los atributos de dimensión se admiten y se marcan automáticamente como no agregables.
Kpi: Los KPI se admiten en CSDLBI versión 1.1, pero la representación ha cambiado. Antes, un KPI era una propiedad de una medida. En la versión 1.1, el elemento KPI se puede agregar a una medida
Nuevas propiedades: Se agregaron atributos adicionales para admitir modelos de DirectQuery.
Limitaciones: No se admite la seguridad de celda.