Modelagem de cofre de dados

Modelo simples de cofre de dados com dois hubs (azul), um link (verde) e quatro satélites (amarelo)

O cofre de dados tenta resolver o problema de lidar com mudanças no ambiente separando as chaves de negócio (que não mudam com tanta frequência), porque eles identificam de forma única uma entidade empresarial) e as associações entre essas chaves empresariais, a partir dos atributos descritivos dessas chaves.

As chaves de negócio e suas associações são atributos estruturais, formando o esqueleto do modelo de dados. O método de abóbada de dados tem como um dos seus principais axiomas que as chaves de negócio reais só mudam quando o negócio muda e são, portanto, os elementos mais estáveis dos quais se pode derivar a estrutura de uma base de dados histórica. Se utilizar estas chaves como a espinha dorsal de um armazém de dados, pode organizar o resto dos dados à sua volta. Isso significa que a escolha das chaves corretas para os hubs é de primordial importância para a estabilidade do modelo. As chaves são armazenadas em tabelas com algumas restrições sobre a estrutura. Essas tabelas de chaves são chamadas de hubs.

HubsEdit

Hubs contêm uma lista de chaves de negócios exclusivas com baixa propensão a mudanças. Os hubs também contêm uma chave substituta para cada item do Hub e metadados descrevendo a origem da chave de negócio. Os atributos descritivos da informação sobre o Hub (como a descrição da chave, possivelmente em vários idiomas) são armazenados em estruturas chamadas Tabelas de Satélite que serão discutidas abaixo.

O Hub contém pelo menos os seguintes campos:

• uma chave substituta, usada para conectar as outras estruturas a esta tabela.
• uma chave de negócio, o driver para este hub. A chave de negócio pode consistir em múltiplos campos.
• a fonte de registro, que pode ser usada para ver qual sistema carregou primeiro cada chave de negócio.
• opcionalmente, você também pode ter campos de metadados com informações sobre atualizações manuais (usuário/tempo) e a data de extração.

Um hub não pode conter múltiplas chaves de negócio, excepto quando dois sistemas entregam a mesma chave de negócio mas com colisões que têm significados diferentes.

Hubs devem normalmente ter pelo menos um satélite.

Hub exampleEdit

Este é um exemplo para um hub-table contendo carros, chamado “Carro” (H_CAR). A chave de condução é o número de identificação do veículo.

LinksEdit

Associações ou transações entre chaves de negócio (relacionando por exemplo os hubs para cliente e produto entre si através da transação de compra) são modeladas usando tabelas de links. Estas tabelas são basicamente muitas tabelas de join, com alguns metadados.

Links podem ligar-se a outros links, para lidar com mudanças na granularidade (por exemplo, adicionar uma nova chave a uma tabela de banco de dados mudaria o grão da tabela de banco de dados). Por exemplo, se você tiver uma associação entre cliente e endereço, você poderia adicionar uma referência a um link entre os hubs para produto e empresa de transporte. Este poderia ser um link chamado “Entrega”. A referência a um link em outro link é considerada uma má prática, porque introduz dependências entre links que tornam o carregamento paralelo mais difícil. Como um link para outro link é o mesmo que um novo link com os hubs do outro link, nestes casos criar os links sem referenciar outros links é a solução preferida (veja a seção sobre práticas de carregamento para mais informações).

Links às vezes ligam os hubs a informações que por si só não são suficientes para construir um hub. Isto ocorre quando uma das chaves de negócio associadas pelo link não é uma chave de negócio real. Como exemplo, pegue uma forma de ordem com “número de ordem” como chave, e linhas de ordem que são digitadas com um número semi-randomial para torná-las únicas. Digamos, “número único”. Esta última chave não é uma chave de negócio real, por isso não é um centro. No entanto, precisamos de a utilizar para garantir a granularidade correcta do link. Neste caso, não usamos um hub com chave de substituição, mas adicionamos a própria chave de negócio “número único” ao link. Isto só é feito quando não há possibilidade de utilizar a chave de negócio para outro link ou como chave para atributos num satélite. Esta construção foi chamada de ‘peg-legged link’ por Dan Linstedt no seu (agora extinto) fórum.

Links contêm as chaves de substituição para os hubs que estão ligados, sua própria chave de substituição para o link e metadados descrevendo a origem da associação. Os atributos descritivos das informações sobre a associação (tais como tempo, preço ou quantidade) são armazenados em estruturas chamadas tabelas de satélite que são discutidas abaixo.

Link exampleEdit

Este é um exemplo para uma tabela de ligações entre dois hubs para carros (H_CAR) e pessoas (H_PERSON). O link é chamado “Driver” (L_DRIVER).

SatélitesEditar

Os cubos e links formam a estrutura do modelo, mas não possuem atributos temporais e não possuem atributos descritivos. Estes são armazenados em tabelas separadas chamadas satélites. Estes consistem em metadados que os ligam ao seu hub pai ou link, metadados que descrevem a origem da associação e atributos, assim como uma linha temporal com datas de início e fim para o atributo. Onde os hubs e links fornecem a estrutura do modelo, os satélites fornecem a “carne” do modelo, o contexto para os processos de negócio que são capturados nos hubs e links. Estes atributos são armazenados tanto no que diz respeito aos detalhes do assunto como à linha do tempo e podem variar desde bastante complexos (todos os campos descrevendo um perfil completo do cliente) até bastante simples (um satélite num link com apenas um indicador válido e uma linha do tempo).

Usualmente os atributos são agrupados em satélites por sistema fonte. No entanto, atributos descritivos como tamanho, custo, velocidade, quantidade ou cor podem mudar a diferentes taxas, assim também é possível dividir esses atributos em diferentes satélites com base na sua taxa de mudança.

Todas as tabelas contêm metadados, descrevendo minimamente pelo menos o sistema fonte e a data em que esta entrada se tornou válida, dando uma visão histórica completa dos dados ao entrar no data warehouse.

Satellite exampleEdit

Este é um exemplo para um satélite no link de condutores entre os hubs para carros e pessoas, chamado “Driver insurance” (S_DRIVER_INSURANCE). Este satélite contém atributos específicos para o seguro da relação entre o carro e a pessoa que o conduz, por exemplo, um indicador se este é o condutor principal, o nome da companhia de seguros para este carro e pessoa (pode também ser um hub separado) e um resumo do número de acidentes que envolvem esta combinação de veículo e condutor. Também está incluída uma referência a uma tabela de pesquisa ou referência chamada R_RISK_CATEGORY contendo os códigos para a categoria de risco na qual esta relação é considerada como recaindo.

(*) pelo menos um atributo é obrigatório.(**) O número de sequência torna-se obrigatório se for necessário para impor a unicidade de múltiplos satélites válidos no mesmo hub ou link.

Tabelas de referênciaEditar

As tabelas de referência são uma parte normal de um modelo de cofre de dados saudável. Elas estão lá para evitar o armazenamento redundante de dados de referência simples que são referenciados em um lote. Mais formalmente, Dan Linstedt define dados de referência da seguinte forma:

Todas as informações consideradas necessárias para resolver descrições de códigos, ou para traduzir chaves para (sic) de uma maneira consistente. Muitos desses campos são “descritivos” por natureza e descrevem um estado específico das outras informações mais importantes. Como tal, os dados de referência vivem em tabelas separadas das tabelas Data Vault em bruto.

As tabelas de referência são referenciadas a partir de Satélites, mas nunca ligadas com chaves físicas estranhas. Não há nenhuma estrutura prescrita para tabelas de referência: use o que funciona melhor no seu caso específico, desde simples tabelas de pesquisa até pequenos cofres de dados ou mesmo estrelas. Elas podem ser históricas ou não ter histórico, mas é recomendável que você se mantenha fiel às chaves naturais e não crie chaves de substituição nesse caso. Normalmente, os cofres de dados têm muitas tabelas de referência, como qualquer outro Data Warehouse.

Exemplo de referênciaEditar

Este é um exemplo de uma tabela de referência com categorias de risco para condutores de veículos. Ela pode ser referenciada a partir de qualquer satélite no cofre de dados. Por agora referenciamo-la a partir do satélite S_DRIVER_INSURANCE. A tabela de referência é R_RISK_CATEGORY.

(*) pelo menos um atributo é obrigatório.