Como faço para criar um nível hierárquico "pai" anulável?

Na verdade, você tem 2 perguntas em uma pergunta. Se você criar uma nova pergunta para os atributos, seria mais organizado e cortarei/colarei metade disso como resposta lá :)

Nível pai anulável

Você provavelmente não quer NULLs em suas dimensões OLAP, e Kimball parece concordar .

Nulos também devem ser evitados quando não podemos fornecer um valor para um atributo de dimensão em uma linha de dimensão válida. Existem vários motivos pelos quais o valor de um atributo de dimensão pode não estar disponível:

Missing Value – The attribute was missing from the source data.
Not Happened Yet – The attribute is not yet available due to source system timing issues.
Domain Violation – Either we have a data quality issue, or we don’t understand all the business rules surrounding the attribute. The data provided by the source system is invalid for the column type or outside the list of valid domain values.
Not Applicable – The attribute is not valid for the dimension row in question.

Depende se você tem um ETLprocesso e um Data Warehouse ou não, como você deve lidar com eles, mas existem diferentes tipos de 'não encontrado'.

Pense na diferença em uma chave estrangeira, uma tem um campo vazio, outra tem um campo preenchido, mas o registro relacionado não pode (ou não pode mais) ser encontrado. Gosto de diferenciar entre BLANKe DATA ERRORna minha dimensão.

No seu exemplo, você poderia diferenciar entre 'sem código de preço' e 'um código de preço que não consigo mais encontrar'

Se você tiver um ETLprocesso com um Data Warehouse, poderá lidar com isso facilmente em seu ETLprocesso; caso contrário, precisará de algumas instruções de caso em suas consultas DSV.

Esta questão parece revelar problemas com o Data Warehouse subjacente. Existem argumentos a favor e contra os esquemas de estrela e floco de neve, mas pessoalmente eu tendo um esquema de estrela, com um pouco de floco de neve misturado quando necessário.
Em qualquer caso, a limpeza de dados e os links ausentes precisam ser resolvidos em seu Data Warehouse muito antes de você chegar ao dsv.

Atributos de dimensão de alteração lenta

Com relação ao seu Slowly Changing Dimension, não vejo como o tipo de dados de hierarquias ou chaves em sua dimensão mudaria porque a dimensão de alguma forma é SCD, isso não importa. Você só precisa de uma regra de validade em algum lugar em seu ETL que seja selecionada por sua definição de dimensão SSAS ( veja aqui ). Mas, para qualquer um dimension keyque você criar, sugiro que você use uma chave substituta principalmente porque sua chave substituta pode ser um intou bigintem vez de um varchar e isso pode melhorar enormemente o desempenho , mesmo para chaves de atributo.

O uso de uma coluna de chave numérica em vez de uma coluna de chave de string ou uma chave composta melhorará o desempenho de atributos que contêm muitos membros. Essa prática recomendada é baseada no mesmo conceito de usar chaves substitutas em tabelas relacionais para uma indexação mais eficiente. Você pode especificar a coluna substituta numérica como a coluna-chave e ainda usar uma coluna de string como a coluna de nome para que os membros do atributo pareçam os mesmos para os usuários finais. Como diretriz, se o atributo tiver mais de um milhão de membros, considere o uso de uma chave numérica.

É claro que essa chave numérica seria uma representação do 'atributo' e não incluiria necessariamente os campos de validade. A validade do registro é especificada no registro em sua tabela de dimensões, mas como você afirma não é necessário para suas chaves de atributo.

Por exemplo, estes podem ser seus dados de dimensão

+---------------+-------+-----------+----------+
| DIMENSION_KEY |  NAME |  NAME_KEY |  CURRENT |
+---------------+-------+-----------+----------+
| 1             | tom   | 1         | y        |
| 2             | mat   | 2         | n        |
| 3             | mat   | 2         | y        |
+---------------+-------+-----------+----------+

Onde você pode escolher dimension_key para a chave do seu key attributee pode escolher name ou name_key como a chave do seu nameatributo.

Determinar se vale a pena o aborrecimento namedepende de quantos membros seu atributo terá (e seu atributo de chave normalmente tem a maioria dos membros).

No final, não há realmente nenhuma relação entre o fato de você ter um SCDe sua decisão de qual chave é uma boa escolha para seu atributo. Os requisitos do usuário final tomam essa decisão por você. Na dimensão de exemplo, você desejaria que todas as vendas por esteira fossem relatadas sob esteira e não tivesse 2 esteiras em seus membros quando os usuários relatassem isso.