Embora não seja um termo que se ouça sempre nos corredores, se trata de algo bem mais simples do que sugere o nome.
Role-Playing Dimension refere-se a uma dimensão que pode ser usada em modelo dimensional para representar diferentes perspectivas de uma mesma entidade ou conceito, como se fosse um papel que essa entidade ou conceito pode assumir.
Por exemplo, em um modelo dimensional que representa as vendas de uma loja, podemos ter uma dimensão de TEMPO, que permite analisar as vendas por dia, semana, mês ou ano.
Para compreender bem o conceito, é importante saber um pouco também sobre Surrogate Key, pois a essa constraint(chave primária) da tabela é o que fará a conexão entre uma tabela DIM_TEMPO e FATO e permitirá que seja obtida da tabela DIM_TEMPO dados, para alimentar um ou mais campos na tabela FATO.
Para ilustrar e fixar bem o conceito, imagine que você deseja realizar uma análise do rastreamento de um produto, desde o dia do pedido até a data da venda e com isso construir uma linha do tempo para assim conseguir mensurar quanto tempo levou entre uma etapa e outra e identificar possíveis falhas no processo logístico de acordo com tempo gasto.
Quando esse tipo análise é demandado, sempre será necessário usarmos as datas presentes na tabela de TEMPO através das Surrogate Keys, que farão parte da tabela fato.
Em muitos casos, quando não se tem o entendimento do conceito de modelagem dimensional, não é incomum se criar mais de uma tabela para completar as lacunas, porém quando modelada corretamente a tabela, pode trazer muitas facilidades e mitigar dificuldades em projetos e análises mais complexas.
Para evitar o uso desnecessário de tabelas adicionais e atender bem as granularidades, podemos tornar o processo muito mais eficiente e profissional, adotando esse conceito e modelando a tabela de forma correta com os campos considerando as possibilidades de filtros, no caso em tela, entender qual será a dinâmica das análises e verificar como as datas são importantes para análises do negócio e processo e assim mapear a granularidade desejada.
Para finalizar esse breve artigo, vamos apresentar uma forma de como podemos criar uma tabela DIM_TEMPO.
A dimensão de TEMPO, é uma dimensão que após ser criada, será atualizada com um registro novo a cada dia que passar do dia mais recente.
Abaixo um padrão de tabela para DIM_TEMPO que contempla os conceitos de Surrogate Key, e carrega datas a partir de uma data estabelecida, atendendo também algumas granularidades possíveis a partir da mesma data, como trimestre, semestre, dia do ano, etc.
Para alimentar uma tabela de tempo criada com os campos previstos, podemos como no exemplo a seguir, desenvolver uma query que roda no banco de dados, usando funções para extrair do mesmo as respectivas datas e com isso podemos inserir o resultado na tabela DIM_TEMPO.
No exemplo abaixo, a query está sendo executada para extrair de um banco PostgreSQL as datas e as informações da mesma para alimentar os campos desejados.
select
to_char(datum, 'yyyymmdd')::int as sk_data,
datum as data_completa,
extract(year from datum) as nr_ano,
extract(month from datum) as nr_mes,
to_char(datum, 'TMmonth') as nm_mes,
extract(day from datum) as nr_dia_mes,
to_char(datum, 'TMday') as nm_dia_semana,
extract(doy from datum) as nr_dia_ano,
extract(week from datum) as nr_semana,
to_char(datum, 'dd/mm/yyyy') as data_formatada,
'T' || to_char(datum, 'Q') as nm_trimestre,
to_char(datum, 'yyyy/"T"Q') as nr_ano_trimestre,
to_char(datum, 'yyyy/mm') as nr_ano_nr_mes,
to_char(datum, 'iyyy/IW') as nr_ano_nr_semana ,
case when extract(isodow from datum) in (6, 7) then 'Fim de Semana' else 'Dia de Semana' end as flag_tipo_dia_semana,
--feriados fixos
case when to_char(datum, 'mmdd') in ('0101', '1225', '1115', '1102', '1012', '0907', '0611', '0501', '0421', '0410', '0225', '0224')
then 'Feriado' else 'Não Feriado' end
as flag_feriado_fixo,
-- periodos importantes para o negócio
case when to_char(datum, 'mmdd') between '0601' and '0831' then 'Temporada de Inverno'
when to_char(datum, 'mmdd') between '1115' and '1225' then 'Temporada de Natal'
when to_char(datum, 'mmdd') > '1225' or to_char(datum, 'mmdd') <= '0106' then 'Temporada de Verão'
else 'Normal' end
as periodo_negocio,
(datum + (1 - extract(day from datum))::integer + '1 month'::interval)::date - '1 day'::interval as ultimo_dia_mes
from (
-- data inicial da carga
select '2017-01-01'::date + sequence.day as datum
from generate_series(0,3652) as sequence(day)
group by sequence.day
) dq
order by 1;Resultado:
Como opção, depois de inseridos os registros na tabela, podemos aplicar um UPDATE na tabela e promover uma “tradução dos termos”, do inglês para o português, caso seja mais conveniente para o projeto e usuários.
Conclusão:
A técnica de role-playing dimension é útil para modelar conceitos que possuem diferentes perspectivas e para permitir a análise de dados em diferentes níveis de granularidade. No entanto, é importante usar essa técnica com cuidado para não criar complexidade desnecessária no modelo dimensional, o que pode dificultar a análise e a manutenção do modelo.
Esse breve artigo, buscou trazer uma visão do conceito de role-playing dimension, mas que ajudará a entender a importância de dominar bem os conceitos de modelagem multidimensional, granularidade e surrogate key, pois a importância de termos bem desenhados os requisitos, construir o modelo de forma eficiente para atender as expectativas será mais fácil.
Os códigos apresentados nos prints acima estão disponíveis no link:
😀 did you understand?
I hope so!😉