Projetando modelos de relatório com base em cubo
Os modelos de relatório são gerados com base em cubos do SQL ServerAnalysis Services (SSAS) com o uso do Gerenciador de Relatórios ou do MicrosoftOffice SharePoint Server 2007 durante a execução no modo integrado do SharePoint. Antes de criar um modelo de relatório com base no cubo SSAS, você deve ser um administrador do banco de dados do Analysis Services. Depois que o modelo é gerado, não é possível modificá-lo. Se você decidir alterar o conteúdo do banco de dados, gere o modelo novamente para incorporar suas alterações.
Cadeias de conexão
Quando você cria um modelo de relatório com base em um banco de dados Analysis Services, sua cadeia de conexão parece semelhante ao seguinte:
Fonte de dados =<servidor_de_relatório>; Catálogo Inicial =<nome de banco de dados>
Observação |
---|
Se seu banco de dados do Analysis Services contiver traduções de cubo, você poderá criar versões traduzidas do modelo de relatório. Para criar um modelo para cada idioma,especifique o LCID (identificador de localidade) na cadeia de conexão da fonte de dados. Para criar um modelo em chinês, por exemplo, sua cadeia de conexão deve ser semelhante a: Fonte de dados =<reportserver>; Catálogo Inicial =<nome de banco de dados>; LocaleIdentifier=3012. Para obter mais informações sobre traduções de cubo, consulte Traduções de cubo. |
Regras para gerar modelos de bancos de dados do Analysis Services
A seguir é apresentada uma lista de regras genéricas aplicadas durante a criação de um modelo com base em um cubo:
Os grupos de medidas são mapeados para entidades. Um único modelo de relatório contém todos os cubos dentro do banco de dados do Analysis Services.
As dimensões são mapeadas para entidades. As dimensões de fato não resultam em uma entidade diferente. Por exemplo, vamos supor que você tenha um grupo de medidas Venda dentro de um cubo e uma dimensão de fato denominada Detalhe de Venda. Quando um modelo é gerado com base nesse cubo, o modelo gerará uma única entidade que contém todas as medidas de Venda e todos os atributos de dimensão de Detalhe de Venda.
As relações entre os grupos de medidas e as dimensões são convertidas em funções dentro do modelo. As relações referenciadas (usadas para relações indiretas) e as relações do tipo muitos para muitos são definidas no modelo como funções.
As medidas são convertidas em atributos de entidade.
Os atributos de dimensão são convertidos em atributos de entidade. Os modelos não têm nenhum conceito de hierarquia. Assim, um atributo de dimensão será incluído no modelo se estiver visível ou se houver uma hierarquia visível que contenha um nível com base nela. O atributo de chave de uma dimensão sempre é incluído, mesmo que esteja marcado como invisível.
Os atributos de entidade das medidas e os atributos de dimensão são organizados em pastas de acordo com as pastas de exibição definidas no cubo.
As perspectivas do cubo se tornam perspectivas do modelo de relatório. Além disso, cada cubo se torna uma perspectiva dentro do modelo. Assim, os usuários do Construtor de Relatórios devem selecionar uma perspectiva dentro do modelo e não o modelo de nível superior.
As medidas calculadas (membros calculados) se tornam atributos na entidade que corresponde ao grupo de medidas ao qual às medidas estão associadas.
Os conjuntos nomeados definidos no atributo de chave de uma dimensão são convertidos em um subtipo da entidade. Por exemplo, o conjunto nomeado “Grandes Clientes” resulta em um subtipo “Cliente”. Os conjuntos nomeados que não se baseiam em um único atributo de chave são ignorados.
Os KPIs (Indicadores Chave de Desempenho) são convertidos em atributos na entidade que corresponde ao grupo de medidas ao qual o KPI está associado. Vários atributos são criados para cada KPI, cobrindo os componentes diferentes do KPI (Valor, Meta, Status e Tendência). Além disso, um atributo de variação que contém os atributos StatusGraphic e TrendGraphic é criado para Status e Tendência respectivamente. A imagem real é incluída no relatório quando você usa esses atributos.
Itens de banco de dados do Analysis Services omitidos dos modelos de relatório
Os seguintes itens de SSAS não aparecem no modelo gerado:
Membros calculados (que não estão na dimensão medidas).
Hierarquias pai-filho que não são convertidas em atributos de modelo ou funções. O atributo de Chave ainda é incluído, embora seu uso em um relatório mostre valores de medidas para o membro de chave, não o valor agregado na hierarquia pai-filho. Além disso, o desempenho será afetado.
Ações. Isso inclui ações de detalhamento. A funcionalidade de detalhamento sempre está habilitada em atributos agregados, independentemente das ações de detalhamento definidas no cubo. Assim, quando um usuário executa um relatório do Construtor de Relatórios fora do modelo e clica em um agregado para exibir um relatório de clickthrough, tabelas vazias são exibidas.
Relações de atributo. Uma dimensão resulta em uma única entidade e as relações entre os atributos das dimensões não afetam o modelo de relatório.
As relações de um grupo de medidas para uma dimensão serão ignoradas caso se baseiem em um atributo que não seja o atributo de chave da dimensão. Por exemplo, o grupo de medidas Orçamento pode estar relacionado ao nível Hora do Mês, em vez de ao nível Dia. Nesse caso, o modelo de relatório não incluiria nenhuma relação entre as entidades Orçamento e Hora.
Considerações sobre o design de cubo
Considere o seguinte ao projetar um cubo para o qual você planeja gerar um modelo de relatório:
As medidas calculadas ou os KPIs que não têm um grupo de medidas associado não aparecerão no modelo de relatório. Para configurar o grupo de medidas associado de uma medida calculada, você deve usar a caixa de diálogo Propriedades de Cálculo.
As consultas enviadas pelo Construtor de Relatórios sempre solicitarão o valor do membro de membros de dimensão e usarão esse valor para classificação e filtragem. Por padrão, no Analysis Services, se um atributo tiver uma associação de nome, o valor do membro será igual ao nome do membro, e se o atributo não tiver nenhuma associação de nome, o valor do membro será igual à chave de membro. No entanto, cada atributo pode ter uma associação explícita com uma coluna que fornece o valor do membro, que deve retornar o valor no tipo de dados “true”. Por exemplo, um atributo Date no Analysis Services pode ter uma chave que é DateTime (por exemplo, “25/4/2008”) e um nome/legenda que é uma descrição textual (“Sexta-feira, 25 de abril de 2008”). Nesse caso, o designer de cubo deverá definir MemberValue como a chave, para assegurar a classificação e a filtragem razoáveis. Embora você deva considerar isso para qualquer atributo, é particularmente pertinente para atributos datetime. Para qualquer atributo datetime, o modelo gerado conterá dois atributos de modelo de relatório — um que é a legenda e uma variável dela que corresponde ao verdadeiro valor de datetime.
A propriedade do atributo de dimensão InstanceSelection é usada para definir as propriedades do modelo de relatório InstanceSelection (nas entidades) e ValueSelection (nos atributos). Isso determina o modo como um usuário poderá selecionar instâncias no Construtor de Relatórios (por exemplo, utilizando uma lista suspensa).
A propriedade do atributo de dimensão GroupingBehavior é usada para definir a propriedade do atributo de modelo DiscourageGrouping.
Os atributos de dimensão que forem imagens devem ter o tipo de dados Image definido na associação de atributo de dimensão.
O recurso de detalhamento sempre está habilitado nos atributos que resultam de medidas, mas somente detalhes mínimos são incluídos nos relatórios de detalhamento padrão. Relatórios de detalhamento personalizados deveriam ser adicionados conforme o necessário para personalização.
Se traduções forem incluídas no cubo, será necessário criar uma fonte de dados por tradução para expô-las no modelo de relatório com a definição da propriedade LocaleIdentifier, conforme o apropriado na cadeia de conexão. Dessa forma, um modelo é gerado para cada fonte de dados e conterá os metadados da tradução associada.
Consulte também