Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Hierarquias definidas pelo usuário são hierarquias definidas pelo usuário de atributos que são usados no Microsoft SQL Server Analysis Services para organizar os membros de uma dimensão em estruturas hierárquicas e fornecer caminhos de navegação em um cubo. Por exemplo, a tabela a seguir define uma tabela de dimensão para uma dimensão de tempo. A tabela de dimensões dá suporte a três atributos, chamados Ano, Trimestre e Mês.
| Ano | Trimestre | Mês |
|---|---|---|
| 1999 | Trimestre 1 | Jan |
| 1999 | Trimestre 1 | Fevereiro |
| 1999 | Trimestre 1 | Março |
| 1999 | Trimestre 2 | Abr |
| 1999 | Trimestre 2 | Maio |
| 1999 | Trimestre 2 | Jun |
| 1999 | Trimestre 3 | Jul |
| 1999 | Trimestre 3 | Agosto |
| 1999 | Trimestre 3 | Setembro |
| 1999 | Trimestre 4 | Outubro |
| 1999 | Trimestre 4 | Novembro |
| 1999 | Trimestre 4 | Dezembro |
Os atributos Ano, Trimestre e Mês são usados para construir uma hierarquia definida pelo usuário, chamada Calendário, na dimensão de tempo. A relação entre os níveis e os membros da dimensão Calendário (uma dimensão regular) é mostrada no diagrama a seguir.
Observação
Qualquer hierarquia diferente da hierarquia de atributo de dois níveis padrão é chamada de hierarquia definida pelo usuário. Para obter mais informações sobre hierarquias de atributo, consulte Atributos e Hierarquias de Atributos.
Estruturas de membro
Com exceção das hierarquias pai-filho, as posições dos membros dentro da hierarquia são controladas pela ordem dos atributos na definição da hierarquia. Cada atributo na definição de hierarquia constitui um nível na hierarquia. A posição de um membro dentro de um nível é determinada pela ordenação do atributo usado para criar o nível. As estruturas membro de hierarquias definidas pelo usuário podem usar um dos quatro formulários básicos, dependendo de como os membros estão relacionados uns aos outros.
Hierarquias equilibradas
Em uma hierarquia equilibrada, todos os branches da hierarquia descem para o mesmo nível e o pai lógico de cada membro é o nível imediatamente acima do membro. A hierarquia categorias de produto da dimensão Produto no banco de dados adventure works DW Multidimensional 2012 sample Analysis Services é um bom exemplo de uma hierarquia equilibrada. Cada membro no nível nome do produto tem um membro pai no nível de Subcategoria, que por sua vez tem um membro pai no nível categoria. Além disso, cada branch na hierarquia tem um membro folha no nível nome do produto.
Hierarquias desbalanceada
Em uma hierarquia desequilibrada, os branches da hierarquia descem para níveis diferentes. Hierarquias pai-filho são hierarquias desbalanceada. Por exemplo, a dimensão Organização no banco de dados adventure works dw multidimensional 2012 analysis services contém um membro para cada funcionário. O CEO é o principal membro da hierarquia, e os gerentes de divisão e o secretário executivo estão imediatamente abaixo do CEO. Os gerentes de divisão têm membros subordinados, mas o secretário executivo não.
Pode ser impossível para os usuários finais distinguir entre hierarquias desbalanceadas e esfarrapadas. No entanto, você emprega diferentes técnicas e propriedades no Analysis Services para dar suporte a esses dois tipos de hierarquias. Para obter mais informações, consulte hierarquias e atributos registradosem hierarquias de Parent-Child.
Hierarquias esfarrapadas
Em uma hierarquia esfarrapada, o membro pai lógico de pelo menos um membro não está no nível imediatamente acima do membro. Isso pode fazer com que os branches da hierarquia desçam para níveis diferentes. Por exemplo, em uma dimensão Geography definida com os níveis Continente, PaísRegião e Cidade, nessa ordem, o membro Europa aparece no nível superior da hierarquia, o membro França aparece no nível médio e o membro Paris aparece no nível inferior. A França é mais específica do que a Europa, e Paris é mais específica do que a França. Para essa hierarquia regular, as seguintes alterações são feitas:
O membro da Cidade do Vaticano é adicionado ao nível de CountryRegion.
Os membros são adicionados ao nível da cidade e são associados ao membro da Cidade do Vaticano no nível de CountryRegion.
Um nível, denominado Província, é adicionado entre os níveis de CountryRegion e City.
O nível de província é preenchido com membros associados a outros membros no nível de CountryRegion, e os membros no nível da cidade são associados a seus membros correspondentes no nível da província. No entanto, como o membro da Cidade do Vaticano no nível de CountryRegion não tem membros associados no nível da província, os membros devem ser associados do nível da Cidade diretamente ao membro da Cidade do Vaticano no nível de CountryRegion. Devido às alterações, a hierarquia da dimensão agora está esfarrapada. O pai da cidade Cidade do Vaticano é a Cidade do Vaticano do país/região, que não está no nível imediatamente acima do membro da Cidade do Vaticano no nível da Cidade. Para obter mais informações, consulte Hierarquias desbalanceadas.
Hierarquias de Parent-Child
As hierarquias pai-filho para dimensões são definidas usando um atributo especial, chamado de atributo pai, para determinar como os membros se relacionam entre si. Um atributo pai descreve uma relação de auto-referência, ou auto-junção, dentro de uma tabela principal de dimensão. As hierarquias pai-filho são construídas a partir de um único atributo pai. Apenas um nível é atribuído a uma hierarquia pai-filho, pois os níveis presentes na hierarquia são extraídos das relações pai-filho entre membros associados ao atributo pai. O esquema de dimensão de uma hierarquia pai-filho depende de uma relação de auto-referência presente na tabela principal da dimensão. Por exemplo, o diagrama a seguir ilustra a tabela principal da dimensão DimOrganization no banco de dados de exemplo Adventure Works DW Multidimensional 2012Analysis Services.
Nesta tabela de dimensão, a coluna ParentOrganizationKey tem uma relação de chave estrangeira com a coluna de chave primária OrganizationKey . Em outras palavras, cada registro nessa tabela pode ser relacionado por meio de uma relação pai-filho com outro registro na tabela. Esse tipo de auto-junção geralmente é usado para representar dados de entidades organizacionais, como a estrutura hierárquica dos funcionários em um departamento.
Quando você cria uma hierarquia pai-filho, as colunas representadas por ambos os atributos devem ter o mesmo tipo de dados. Ambos os atributos também devem estar na mesma tabela. Por padrão, qualquer membro cuja chave pai seja igual a sua própria chave de membro, nula, 0 (zero) ou um valor ausente da coluna para chaves de membro é considerado um membro do nível superior (excluindo o nível (Todos).
A profundidade de uma hierarquia pai-filho pode variar entre seus branches hierárquicos. Em outras palavras, uma hierarquia pai-filho é considerada uma hierarquia desequilibrada.
Ao contrário das hierarquias definidas pelo usuário, nas quais o número de níveis na hierarquia determina o número de níveis que podem ser vistos pelos usuários finais, uma hierarquia pai-filho é definida com o nível único de uma hierarquia de atributos e os valores nesse nível único produzem os vários níveis vistos pelos usuários. O número de níveis exibidos depende do conteúdo das colunas da tabela de dimensão que armazenam as chaves de membro e as chaves pai. O número de níveis pode ser alterado quando os dados nas tabelas de dimensão são alterados. Para obter mais informações, consulte Parent-Child Hierarquia e Atributos em hierarquias de Parent-Child.
Consulte Também
Criar hierarquias de User-Defined
Propriedades da hierarquia de usuário
Referência de propriedades de atributo de dimensão