Tipicamente os valores das dimensões são conhecidos à partida, podendo ser acrescentados novos registos a cada dimensão, mas que não interferem nos valores numéricos já existentes (os novos registos da dimensão apenas serão utilizados em novos dados).
Existem no entanto algumas dimensões cujos valores se alteram ao longo do tempo, sendo que pode ser necessário a cada momento obter o(s) valor(es) da dimensão que estava(m) ac- tivo(s) no período de tempo para o qual se pretende efectuar a análise de dados. Como exemp- los destas dimensões referem-se o Produto (alteração da categoria a que o produto pertence, renomeação de produtos, etc.) e Cliente (alteração da morada, estado civil, etc.).
São consideradas 3 formas principais de se lidar com as dimensões lentamente alteráveis, ou Slowly Changing Dimensions (SCD) [Kim96b]:
1. sobreposição do valor da dimensão - esta opção não mantém histórico, deve ser utilizada quando o anterior valor não é interessante para a realização de análises, como seja, por exemplo, para correcção de erros ou actualização de atributos descritivos (alteração de e-mail, nome da empresa, etc.);
2. criação de novo registo na dimensão - este é o tipo mais comum de solução para as SCD. Neste caso, se cada registo for identicado por um código especíco, a chave do DW poderá por exemplo prever mais alguns dígitos, para permitir as novas versões do mesmo registo, e evitando assim as estampilhas temporais. Esta opção tem a vantagem de permitir a partição automática dos dados, mas é necessário ter em conta que haverá necessariamente um crescimento do número de registos da tabela de dimensão, que pode ou não ser relevante;
3. adicionar à dimensão um campo que indica o valor corrente - nos casos em que o valor antigo é legítimo, e é necessário mantê-lo e utilizá-lo, pode ser adoptada esta solução. Consiste em criar um campo onde é indicado o valor corrente, passando outro campo a indicar o valor antigo. Apenas as alterações mais recentes são guardadas, mas permite a visualização dos dados por cada uma das alternativas. Pode ser alargada para as 2 alterações mais recentes, mas nesse caso poderá ser considerada a adopção da segunda forma de se lidar com as SCD em vez desta.
Esta última opção tem algumas desvantagens: é necessário um atributo extra por cada al- teração que se pretenda guardar; caso se pretenda guardar a data de alteração, é também necessário contabilizar mais este atributo; e só permite guardar um número limitado de alterações. O código necessário para extrair a informação pode ser complexo, quando se quer o valor num período especíco do tempo, ou vários atributos em simultâneo, com valores velhos e novos.
O primeiro passo para gerir as SCD é determinar qual o tipo de alterações que se vai aco- modar, e a partir daí determinar a implementação pretendida.
Para as opções 1 e 3 não é necessária uma modicação substantiva no modelo de dados. Mas, no caso da opção 3, é necessário prever a inclusão dos novos campos para guardar as
alterações.
Quando se implementam dimensões agregadas, por exemplo para melhorar algumas pesquisas, é necessário ter em conta que as alterações de tipo 1 podem alterar a história e portanto têm inuência ao nível de histórico das tabelas agregadas.
A implementação da opção 2 é mais complexa. Para esta opção de implementação torna-se particularmente importante (e é normalmente aconselhado) a utilização de chaves articiais no DW, que não tenham qualquer signicado a nível de negócio [Kim98]. Desta forma é sempre possível criar novos registos sem se comprometer a identicação da sua inter-relação (mantém- se o identicador interno do registo, apenas muda a chave).
Como forma alternativa de implementar esta opção podem ser utilizadas chaves compostas (acrescenta-se à chave existente mais 2 ou 3 dígitos para a versão), mas tem como desvantagem aumentar o tamanho da chave que depois será usada nas tabelas de factos.
No caso de se tratar de modelos normalizados, que normalmente não têm normalmente uma dimensão tempo explícita, a existência de um atributo que indique qual o valor corrente facilita a realização das pesquisas.
A implementação desta opção tem, portanto, custos de complexidade associados à alteração de chaves primárias. É necessário ter em conta que num sistema normalizado, ou dimensional mas com estrutura snowake, a alteração da chave primária de uma tabela de dimensão pode implicar a actualização das chaves estrangeiras dos registos das tabelas relacionadas (por exem- plo, quando se altera a chave primária num nível superior de uma hierarquia dimensional).
Assim, para se diminuir a complexidade, podem ser utilizadas soluções híbridas, por exem- plo, do tipo 1 e 2, de forma a diminuir o número de campos abrangidos pela opção de imple- mentação do tipo 2.
Todas estas abordagens permitem que as dimensões se mantenham em tabelas desnormal- izadas, facilitando a sua utilização e navegação por todos os atributos da dimensão nas ferra- mentas de pesquisa. Além disso, torna transparente a existência de várias versões de um só registo, pelo menos até que seja feita uma selecção por um dos atributos alterados.
No entanto, pode acontecer que um atributo de uma destas dimensões se comece a al- terar mais frequente, como por exemplo mensalmente. Nesse caso, deixamos de estar perante uma dimensão lentamente alterável [Kim99]. Uma das abordagens para solucionar este prob- lema será a separação dos atributos problemáticos numa ou mais dimensões, criando mini- dimensões, e deixando os atributos lentamente alteráveis na dimensão maior, mas essa prob- lemática não será detalhada neste trabalho.