Use o IBM Industry Model Information Insurance Warehouse para definir modelos de dados inteligentes e maduros

Introdução ao método de desenvolvimento de data warehousing para seguros

Neste tutorial, entenda o método para desenvolver modelos de dados para projetos de armazém de dados usando o IBM Industry Model Insurance Information Warehouse (IIW), que é parte do produto IBM Industry Models definido para o setor de seguros. O tutorial mostra a melhor abordagem para desenvolver modelos de core data warehouse (CDW) e modelos de data mart (DM). Também apresenta o data warehousing development method (DWDM) recomendado para lidar com a estrutura de padrão de modelo IIW para arquitetar soluções de DWH para empresas de seguro.

Hermann Voellinger, Senior IT Architect, IBM

Hermann Voellinger photoHermann Voellinger é um arquiteto de TI senior do IBM Software Group Services. Ao longo dos últimos 12 anos, ele vem sendo o arquiteto de TI responsável pelos grandes projetos de armazém de dados (DWH) na Alemanha. Nos 10 anos anteriores, ele trabalhou no German Development Lab como o principal desenvolvedor e arquiteto para ferramentas e soluções de mineração de dados e texto. Suas habilidades essenciais e seu principal foco de trabalho são a arquitetura dos processos de preenchimento de dados (ETL), os conceitos de modelagem de dados e a estratégia e arquitetura das soluções DWH.


nível de autor Contribuidor do
        developerWorks

Alexander Tarabrin, Advisory IT Architect, I.B.M.

Photo of Alexander TarabrinAlexander Tarabrin tem 14 anos de experiência profissional na área de TI. Ele é Advisory IT Architect no IBM Software Group Services na IBM Alemanha. Alexander está trabalhando nas áreas de modelagem de dados, gerenciamento de dados, modelos do segmento de mercado e integração de dados do cliente.



13/Jan/2011

Antes de iniciar

Introdução

Design de armazém de dados e modelagem de dados é uma mistura significativa de ciência da computação e TI. A tecnologia nasceu no início da década de 1990, usando várias abordagens desenvolvidas naquele tempo. Os métodos mais significativos foram definidos por Ralph Kimball (de cima para baixo) e por W. H. Inmon (de baixo para cima) (consulte Recursos ).

Produtos de modelagem de dados comerciais têm valor devido a seu conhecimento específico do conteúdo, que é baseado em experiência prática e conhecimento de negócios. A IBM oferece uma família de produtos de capital intelectual nesse espaço, chamada IBM Industry Models. Os produtos IBM Industry Models consistem em estruturas de padrão maduros e bem testados para modelagem de dados (relacionais e multidimensionais), com pacotes para vários segmentos de mercado. Este artigo apresenta uma visão geral do Information Insurance Warehouse (IIW), que é parte do produto IBM Industry Models definido para o segmento de mercado de seguros.

Este tutorial apresenta o método para desenvolver modelos de dados para armazém de dados (DWH) usando o IBM Industry Model IIW. O tutorial demonstra a abordagem para o desenvolvimento de modelos de core data warehouse (CDW) models (modelos de dados altamente normalizados que contêm os elementos de dados atômicos) e os modelos de data mart (DM) (modelos de dados não normalizados que implementam a estrutura de modelos de dados multidimensionais). Modelos de dados multidimensionais são caracterizados pela definição de medidas, que são armazenadas em tabelas de fatos, e pela definição de tabelas de dimensões, que definem os eixos ou dimensões da análise.

O método descrito neste tutorial é o roteiro do IIW para desenvolver modelos de dados. O roteiro do IIW baseia-se na abordagem de cima para baixo, que começa com a captura d requisitos de negócios e a definição do modelo de negócios (em termos de IIW, conhecido como modelo de dados de análise). Definir os requisitos de negócios é o pré-requisito para todo o trabalho posterior. O ideal é que esse trabalho seja realizado em conjunto pelo modelador de dados e especialistas dos departamentos de negócios. Quando os departamentos de negócios criam e aprovam o modelo, começa a fase para criar modelos lógicos.

O design de modelos lógicos consiste em duas etapas: design do modelo lógico de DWH (CDW) seguido pelo design do modelo lógico de DM. É importante seguir essa abordagem sequencial. Começar fases posteriores antes de concluir as fases anteriores pode ter resultados indesejados. Portanto a estrutura do roteiro do IIW e esse tutorial estão divididos nas quatro fases seguintes:

  1. Fase 1: Capturar requisitos de negócios de IIW
  2. Fase 2: Definir o modelo de dados de análise
  3. Fase 3: Projetar o modelo lógico do armazém de dados
  4. Fase 4: Projetar o data mart

Essas quatro fases completam objetivos diferentes e oferecem diferentes entregas:

Fase 1: Capturar requisitos de negócios de IIW
Uma descrição completa dos requisitos de negócios que o projeto de BI deve resolver. As entregas são um modelo conceitual e um modelo de requisitos analíticos.
Modelo conceitual
Um modelo de todos os conceitos e termos de negócios usados na organização
Modelo de requisitos analíticos
Modelos predefinidos de requisitos de negócios que lidam com questões específicas do segmento de mercado. Modelos são expressos como medidas e dimensões
Fase 2: Definir o modelo de dados de análise
Um modelo conceitual que representa uma imagem ideal dos conceitos de negócios e como esses conceitos se relacionam entre si. Esse modelo é independente de plataforma e não exige aspectos físicos da implementação. A entrega é o modelo de dados de análise.
Modelo de dados de análise
Um modelo de dados que especifica as estruturas de dados normalizadas exigidas para representar os conceitos definidos no modelo conceitual.
Fases de design de DWH e DM
Os conceitos de negócios mapeados em um modelo lógico (DWH) de entity-relationship (ER) e em um modelo lógico multidimensional (MD). Esses modelos são a base para a estrutura física dos dados no banco de dados. As entregas são modelos de dados de design de DW e modelos de dados de design de DM.
Modelos de dados de design de DW
Modelos de dados que representam o repositório corporativo de dados atômicos e analíticos usados para processamento de informações
Modelos de dados de design de DM
Modelos dimensionais que implementam requisitos analíticos e são estruturados para permitir análises dimensionais específicas

Figura 1 resume essas entregas.

Figura 1. Entregas das quatro fases do IIW
Entregas das quatro fases do IIW

IIW também define três camadas de modelo:

  • A camada de base contém os modelos de requisitos conceituais e analíticos.
  • A camada de análise abrange o modelo de dados de análise.
  • A camada de design contém os modelos de design do DW e do DM.

O diagrama da Figura 2 representa essas camadas.

Figura 2. Camadas do modelo do IIW
Shows the 3 foundation layers, with the supporting models layer above containing schemas for HIPAA, Sarbanes Oxley, Basel II, IFRS/IAS, and Solvency II

As seções a seguir do tutorial descrevem as quatro fases, com exemplos de cada fase usando InfoSphere™ Data Architect (IDA). Os exemplos usam o IBM IIW Model Versão 8.2. O conteúdo do modelo do IIW é importado para o IDA com a ajuda da ferramenta Enterprise Model Extender (EME). EME é um conjunto de extensões de plug-in do produto IBM InfoSphere Data Architect. Para acompanhar o tutorial, você precisará instalar esses produtos.


Fase 1: Capturar requisitos de negócios de IIW

A necessidade de conjunto de ferramentas e padrões de modelo apropriados aparece na fase inicial de análise de requisitos. Os pacotes de trabalho desta fase são designados a analistas de negócios com grande conhecimento do segmento de mercado e qualificações de TI de alto nível. As entregas de tais pacotes de trabalho são, geralmente, documentos não estruturados, tais como protocolos de reuniões, apresentações e documentos de processador de texto. As informações assim coletadas geralmente não têm qualquer modelo independente. As informações são entregues no estado em que se encontram para a próxima fase (o modelo de negócio), que cria o gasto adicional do processamento de grandes quantidades de entregas de entrada. Há uma necessidade clara de introduzir modelos de alto nível, que não sejam de relacionamento de entidade.

Acesso ao conhecimento e soluções de referência e outro requisito. Os padrões de solução disponíveis devem ser apresentados de maneira apropriada para dar a consultores de negócios uma maneira eficiente e fácil de:

  • Acessar os padrões e documentação da estrutura do IIW
  • Coletar requisitos na estrutura do IIW
  • Mapear entregas da fase de análise de requisitos para os componentes da estrutura do IIW

O IIW apresenta os modelos de camada de base para fornecer a consultores de negócios e analistas o conjunto de ferramentas e recursos de propriedade intelectual, que são distribuídos como um produto comercial. Os modelos da camada de base incluem:

Modelo conceitual
Contém os metadados de negócios a serem usados em outros modelos
Modelo de requisitos analíticos
Usa os metadados de negócios identificados no modelo conceitual para documentar os requisitos de consultas analíticas
Vocabulário de conceitos de negócios
Entrega a representação em forma de dicionário dos termos de negócios coletados

Modelo conceitual

O modelo conceitual é o modelo mais alto para a definição de requisitos de negócios. Os dados de negócios coletados nesta fase são muito não estruturados. O modelo conceitual entrega o suporte de ferramenta para coletar informações sobre elementos de dados numéricos e não numéricos e dependências entre eles.

As partes do modelo conceitual são:

  • Agregar descritores que focam em requisitos baseados em medidas. Os descritores agregados são referências de modelos de medida para o modelo de requisitos analíticos.
  • A parte de conceitos do modelo, que é focada principalmente na coleta de metadados classificados hierarquicamente. Essa parte é usada no modelo de requisitos analíticos para a definição de dimensões.

O modelo de descritores agregados representa uma lista de descritores predefinidos. Cada descritor contém uma etiqueta exclusiva e texto de documentação, como mostra a Figura 3.

Figura 3. Propriedades do descritor agregado Contas a Receber
Propriedades do descritor agregado Contas a Receber

(Veja uma versão maior da Figura 3.)

Para medidas calculadas, é possível usar um recurso para documentar a expressão de cálculo e referenciar medidas relacionadas. Um descritor agregado pode ser vinculado a outro modelo (por exemplo, ao modelo de requisitos analíticos ou o modelo de dados de análise).

A parte de conceitos do modelo contém os seguintes tipos de metadados:

Descritores
Podem ser numéricos ou não numéricos. Os descritores numéricos podem ser usados para medidas calculadas.
Relacionamentos
Descreve relacionamentos entre conceitos.
Hierarquias
Descreve a ordem dos conceitos de negócio. Cada conceito tem vários subconceitos que o classificam e descrevem. Os três subconceitos a seguir são usados:
  • Classificador
  • Descritor
  • Relacionamento
O usar classificadores, é possível documentar a hierarquia de negócios. Por exemplo, uma conta tem quatro classificadores:
  • Tipo de período contábil
  • Tipo da razão do status da conta
  • Tipo do status da conta
  • Tipo da conta
Em tipo de conta, é possível definir quatro subtipos, incluindo conta monetária. Conta monetária, por sua vez, tem sete subtipos, e assim por diante, como mostra a Figura 4. Esta arte de notação de diagrama é chamada de notação esquema-valor. Usando esta notação, é possível documentar os metadados (nomes de nível) e dados de negócios (valores de nível) na mesma hierarquia.
Figura 4. Um recorte do modelo conceitual, mostrando um fragmento da hierarquia da conta
Um recorte do modelo conceitual, mostrando um fragmento da hierarquia da conta

O modelo conceitual é um recurso importante do IIW para documentar conceitos de negócios e suas dependências em uma visualização de nível de negócios alta. Também mostra as dependências e relacionamentos existentes de um objeto de negócios, como o objeto de negócios account na Figura 4.

Modelo de requisitos analíticos

O propósito do analytical requirements model (ARM) é agrupar e classificar os conceitos coletados no modelo conceitual. Um modelo de requisitos analíticos representa requisitos analíticos individuais. Um requisito analítico contém medidas e dimensões necessárias para analisar um caso de negócio em particular.

Requisitos analíticos são agrupados em vários grupos, chamados áreas de foco. Cada área de foco representa um domínio de problemas de negócios, tais como análise de solicitações, gerenciamento de produtos, gerenciamento de risco e assim por diante. É possível criar áreas de foco substitutas. Por exemplo, análise de eficiência de solicitações pode substituir análise de solicitações, como mostra a Figura 5.

Figura 5. Áreas de foco do modelo de requisitos analíticos
Áreas de foco do modelo de requisitos analíticos

Uma área de foco contém requisitos analíticos. Um requisito analítico contém um conjunto de medidas e um conjunto de dimensões. Por exemplo, o requisito Análise de risco do cliente contém as dimensões Política , Produto e Dimensão de tempo, e contém as medidas Número de acidentes e Número de solicitações, como mostra a Figura 6.

Figura 6. Requisito analítico de amostra
Requisito analítico de amostra

Os vínculos entre o modelo de requisitos analíticos e o modelo conceitual são cruciais. Todas as medidas e dimensões são vinculadas a conceitos apropriados no modelo conceitual. Medidas reutilizam propriedades agregadas ou mensuráveis que são predefinidas no modelo conceitual. Dimensões são visualizações de wrappers de conceitos de negócios, classificadores, relacionamentos ou propriedades descritivas que são predefinidas no modelo conceitual.

A vantagem desta abordagem de vínculo é que medidas ou dimensões semanticamente idênticas referenciadas em diferentes requisitos analíticos são mapeadas para um único conceito no modelo conceitual. Isso resolve o problema da redundância, e permite colocar a documentação sobre um conceito de negócios em particular em um só lugar. Da mesma forma, é possível inspecionar qualquer elemento do modelo conceitual para ver se há referências do modelo de requisitos analíticos.

IIW é entregue com um conjunto de requisitos analíticos predefinidos agrupados em áreas de foco. Usuários de negócios podem selecionar os requisitos analíticos para modificar, ou criar novos requisitos analíticos. Consulte o artigo Scoping the IBM Industry Model for banking using Enterprise Model Extender and InfoSphere Data Architect para obter mais informações.

Vocabulário de negócios

O vocabulário de negócios (ou glossário de negócios) é uma entrega obrigatória de qualquer projeto de data warehousing. Geralmente é mantido manualmente como um documento semiestruturado, com dependências do catálogo de requisitos e modelos de dados. O IIW entrega o vocabulário de negócios como parte integral do ambiente de modelagem.

O vocabulário de negócios resume os termos de negócios coletados nos modelos conceitual e de requisitos analíticos. O vocabulário de negócios consiste em termos definidos (palavras) agrupadas em dicionários, como mostra a Figura 7.

Figura 7. Vocabulário de negócios
Vocabulário de negócios

(Veja uma versão maior da Figura 7.)

Cada palavra é fornecida com uma descrição, que é a descrição do elemento apropriado do modelo conceitual ou de requisitos analíticos. O vocabulário de negócios está aberto a modificações. Usuários de negócios podem editar ou criar dicionários e palavras. Usuários de negócios podem definir um ciclo de vida da palavra no qual usuários podem especificar status, tais como candidata, aceita, padrão e descontinuada.

O vocabulário de negócios oferece vários outros recursos, incluindo a possibilidade de especificar sinônimos ou palavras relacionadas.

O conteúdo do vocabulário de negócios pode ser exportado para o IBM InfoSphere Business Glossary usando o Metadata Server.

Resumo da fase 1

Esta seção ofereceu uma visão geral dos modelos principais da camada de base do IIW. Os modelos são a estrutura para coletar dados durante a análise de requisitos. Os modelos são a entrega para as próximas fases.


Fase 2: Definir o modelo de dados de análise

IIW usa o termo modelo de dados de análise para se referir ao modelo de negócio. A abordagem de entrega do data warehousing development method (DWDM) prevê a criação do modelo de dados de análise antes da criação dos modelos lógico e físico. O modelo de dados de análise é orientado para os negócios. É independente de qualquer design ou arquitetura. Definir o modelo de dados é uma das fases que mais demanda recursos no processo de design.

O modelo de dados de análise é um modelo de dados que especifica as estruturas de dados normalizadas exigidas para representar os conceitos definidos no modelo conceitual.Como um modelo de análise, o modelo de dados de análise não inclui novos conceitos de negócios ao conteúdo definido no modelo conceitual. .

Estrutura do modelo de negócio de análise

O modelo de dados de análise consiste em 23 áreas de negócios, incluindo grupo, local, solicitação, evento e assim por diante. O modelo de dados de análise tem mais de 1.100 entidades. Há uma hierarquia de tipo para cada entidade principal, como a hierarquia de tipo para a entidade principal Solicitação, como mostra a Figura 8.

Figura 8. Hierarquia de tipo Solicitação
Hierarquia de tipo Solicitação

Os supertipos e subtipos (conhecidos como naturezas) são conectados usando o relacionamento pai-filho. Os atributos estão contidos no nível apropriado da hierarquia.

As entidades e atributos do modelo de dados de análise são descritos com propriedades específicas do Enterprise Model Extender (EME). Guias Classification e Mappings adicionais são exibidas na Figura 9.

Figura 9. Propriedades específicas do EME
Propriedades específicas do EME

Usando a opção Classification, é possível verificar o tipo apropriado de entidades e atributos. Os tipos mais comuns são entidade semântica para entidades e atributo semântico para atributos. Todos os atributos do modelo de dados de análise são mapeados para o modelo conceitual, como mostra a Figura 10.

Figura 10. Mapeamento do modelo conceitual
Mapeamento do modelo conceitual

Verificação e análise do modelo

É possível verificar e analisar o modelo para identificar modelagem errônea ou diferenças. A análise de modelo é definida como o conjunto de regras que servem de parâmetro para o modelo de dados de análise criado. Por exemplo, há uma regra para verificar a existência de mapeamentos para todos os atributos definidos no modelo, como mostra a Figura 11.

Figura 11. Regras de análise de modelo
Regras de análise de modelo

Se alguns mapeamentos estiverem ausentes, como mostra a Figura 12, a mensagem de erro apropriada aparece após a análise do modelo ser executada.

Figura 12. Amostra de mensagem de erro
Amostra de mensagem de erro

Resumo da fase 2

Esta seção descreveu como definir o modelo de dados de análise (modelo de negócio), que é uma das tarefas mais importantes do método DWDM. A pessoa designada para esta atividade precisa de conhecimento do negócio e qualificações de modelagem de dados. O modelo de dados de análise é a base da definição do modelo de dados lógicos descrito na Fase 3.


Fase 3: Projetar o modelo lógico do armazém de dados

Usuários de negócios concluem as fases descritas nas primeiras duas fases deste tutorial. Projetar modelos lógicos do IIW é orientado para TI, e é mais adequado que usuários de TI (designers de dados) os concluam. A camada de design do IIW consiste na parte atômica (o modelo corporativo) e na parte analítica (modelo de dimensões e modelos de data mart conformados). Esta seção descreve o modelo corporativo do IIW.

A estrutura do modelo corporativo é semelhante ao modelo de dados de análise. O modelo é colocado em vários pacotes. Cada pacote consiste em um conjunto de artefatos (entidades, atributos e relacionamentos) e alguns diagramas para fins de visualização, como mostra a Figura 13. Essa é a estrutura padrão de modelos lógicos no IBM InfoSphere Data Architect.

Figura 13. Recorte de amostra da estrutura de modelo corporativo
Recorte de amostra da estrutura de modelo corporativo

Artefatos do modelo corporativo

O modelo de armazém de dados é um modelo de dados que representa o repositório corporativo de dados atômicos usados para processamento de informações. Esse modelo inclui o histórico das mudanças de valor das informações de negócios, que podem variar no tempo. Pode ser proveitoso manter um registro desse histórico para fins analíticos.

O modelo de armazém de dados define os seguintes tipos de atributos:

Entidade fundamental
Contém informações de negócios atômicas. Uma entidade fundamental pode ser com versão ou sem versão. Requer uma entidade âncora se for com versão, ou uma entidade raiz se for sem versão, para manter suas versões
Entidade âncora
Atua como uma âncora para manter versões diferentes da instância de uma entidade. Âncoras também são usadas como time-invariant keys (TIKs) em um ambiente de armazém de dados.
Entidade raiz
Atua como supertipo para entidades fundamentais sem versão
Entidade sem associação
Serve como relacionamento entre duas entidades raízes ou âncoras.
Entidade de característica de população
Contém informações sobre tarefas ETL.
Entidade de classificação
Instancia atributos semânticos específicos do tipo de dado enumeração.

As entidades são conectadas usando relacionamentos de diferentes tipos, conforme a seguir, definido para o modelo corporativo:

Relacionamento de design
Conecta duas entidades, geralmente uma para muitas, para fins de design (como navegação ou melhor desempenho).
Relacionamento de âncora
Conecta a entidade fundamental com a entidade âncora relacionada.

As entidades têm atributos. Os tipos de atributos definidos no modelo corporativo são os seguintes:

Atributo básico
Contém dados de negócios.
Chave de candidato
Contém a chave comercial que identifica exclusivamente a instância de uma entidade.
Atributo de relacionamento
Contém um atributo de chave estrangeira.
Atributo derivado
Contém um valor derivado (ou duplicado) de um valor de um ou mais dos outros atributos.

Figura 14 mostra um recorte de um diagrama de dados da área de solicitações. Os atributos foram omitidos para melhorar a leitura.

Figura 14. Recorte do modelo corporativo para a área de solicitações
Recorte do modelo corporativo para a área de solicitações

Abordagem de customização

A abordagem da customização do modelo corporativo é descrita em detalhes na ajuda online instalada com o Enterprise Model Extender. Há técnicas específicas para incluir ou modificar uma entidade, relacionamento ou atributo de qualquer tipo. As técnicas são descobertas na forma de oito regras de transformação. As regras descrevem a abordagem de customização incluindo entidades de associação semântica e associações semânticas; transformando entidades supersemânticas e entidades subsemânticas; e lidando com atributos derivados e duplicados.

Ao customizar o modelo corporativo, o designer de dados deve lembrar-se de que os elementos do modelo corporativo devem ser vinculados aos elementos apropriados no modelo de dados de análise.

Em direção a um modelo físico

Ao contrário do modelo de dados de análise, o modelo corporativo é orientado para TI. O modelo corporativo contém os seguintes recursos:

Versão de dados
Um dos aspectos mais importantes do design de data warehousing. As entidades fundamentais do modelo corporativo (EM) contam com os quatro atributos a seguir:
  • EFFECTIVE_FROM
  • EFFECTIVE_TO
  • VALID_FROM
  • VALID_TO
Os atributos EFFECTIVE_FROM/TO se baseiam no período de validade semântica. Os atributos VALID_FROM/TO se baseiam nos registros de data e hora de quando os dados foram preenchidos no sistema de origem e representam o período de validade técnica.
Chaves primárias
As chaves primárias definidas no EM são números inteiros de 4 bits. São surrogate keys sem semântica de negócios. Não são derivadas das chaves primárias dos sistemas de origem.
Preenchimento de dados
As entidades contêm os atributos de preenchimento de dados que descrevem as informações sobre o processo de ETL.

Resumo da fase 3

Esta seção descreveu o modelo corporativo e a abordam para customizá-lo. É possível transferir o modelo corporativo para o modelo físico usando o assistente do InfoSphere Data Architect.


Fase 4: Projetar o data mart

Usuários de negócios concluem as fases descritas nas primeiras duas fases deste tutorial. Projetar um data mart é orientado para TI, e é mais adequado que usuários de TI (designers de dados) os concluam. A camada de design do IIW consiste na parte atômica (o modelo corporativo) e na parte analítica (modelo de dimensões e modelos de data mart conformados). Esta seção descreve a parte analítica.

O modelo dimensional conformado é o repositório corporativo de dados analíticos. Contém estruturas de dados dimensionais baseadas em entidades de fato que permitem distribuição fácil de dados analíticos para modelos analíticos de recebimento de dados, tais como data marts.

A estrutura e o conteúdo de negócios das dimensões no modelo dimensional conformado baseiam-se e reutilizam o modelo de armazém de dados. As medidas na tabela de fatos suportam as medidas definidas nos requisitos analíticos.

Além das estruturas de dados e conteúdo originados do modelo de armazém de dados, o modelo dimensionado conformado inclui o seguinte:

  • Relacionamentos adicionais para desenvolver caminhos de agregação nos quais medidas podem ser analisadas
  • Entidades adicionais para eficiência de armazenamento e análise, tais como perfil e entidades auxiliares

No InfoSphere Data Architect, há vários modelos lógicos de data marts predefinidos no IIW, como mostra a Figura 15.

Figura 15. Recorte de amostra da estrutura de data mart do IIW
Recorte de amostra da estrutura de data mart do IIW

Cada modelo de data mart em si pode consistir em um conjunto de subconjuntos analíticos. Figura 5 mostra que a análise de eficiência de solicitações consiste em quatro pacotes analíticos (contêm tipo de dado) e um pacote de associação (contém entidades de relacionamento). Essa é a estrutura padrão de modelos lógicos no IBM InfoSphere Data Architect.

Usando o modelo dimensional conformado

O modelo dimensional conformado é um como um super data mart. Entretanto, tenha cuidado com as consultas do usuário final, por estas razões:

  • As estruturas dimensionais do modelo dimensional conformado são organizadas como flocos de neve, o que torna as consultas mais complexas
  • Algumas entidades de fato podem ser genéricas demais, o que pode resultar em nomes de medidas de negócios que são pouco significativos.
  • O número de dimensões por fato pode ser alto demais. A granularidade de dimensões é o mais alto possível para permitir os requisitos analíticos mais granulares sem exigir manutenção do design. Isso pode resultar em fatos demais e tempos de resposta ruins nas consultas.

O modelo dimensional conformado é baseado nos dois principais princípios de design a seguir:

Dimensões conformadas
Uma dimensão conformada é uma dimensão principal com cujo conteúdo todos os grupos no empreendimento concordam. Dimensões conformadas permitem caminhos de agregação reutilizáveis para medidas em diversas tabelas de fatos.
Fatos conformados
Um fato conformado é uma medida com cuja definição de negócio todos os grupos no empreendimento concordam. O fato pode ser usado em cálculos analíticos em fontes de dados separadas e com outros fatos conformados.

Os dois princípios de design definem consistência nas tabelas de fato, melhoram a qualidade dos resultados analíticos e facilitam técnicas de análise, tais como drilling across.

O modelo dimensional conformado é parcialmente não normalizado para facilitar a extração de estruturas dimensionais para preencher modelos de data mart de recebimento de dados.

Artefatos do modelo dimensional conformado

Ao usar IBM Industry Models para desenvolver soluções de BI, o modelo dimensional conformado usa os seguintes artefatos:

Entidade de fato
Uma entidade agregada que reagrupa um conjunto de medidas (fatos) que compartilham todos as mesmas dimensões. A chave primária de uma entidade de fato é definida como a concatenação de todas as chaves estrangeiras das entidades que são usadas como suas dimensões. A entidade de fato é a entidade principal da estrutura de dados dimensional. Pode servir como base para criar subconjuntos da estrutura que são distribuídos para data marts.
Entidade auxiliar
Uma entidade auxiliar gerencia a análise de uma estrutura hierárquica complexa de profundidade variável de uma dimensão. Uma entidade auxiliar pode ser usada apenas se a estrutura hierárquica for uma árvore, e não uma rede. Essa entidade contém uma instância para cada caminho separado de cada nó na árvore hierárquica para si mesmo e para cada nó abaixo. Um exemplo é a entidade auxiliar geográfica.
Entidade de apoio
Uma entidade que é usada apenas para apoiar as estruturas de dados analíticas. Um exemplo é a entidade de data do calendário.
Entidade de grupo de valor
Uma entidade que agrupa atributos usados para realizar análise em uma entidade de fato. Cada atributo de uma entidade de grupo de valor tem um conjunto de valores discretos nos quais é ;possível agregar as medidas de uma entidade de fato. Um exemplo é a entidade de perfil do cliente.
Relacionamento de dimensão
Um relacionamento entre uma entidade de fato e uma entidade fundamental ou uma entidade de classificação no modelo de armazém de dados.
Atributo complexo
Uma medida que é calculada a partir de outras medidas. A definição inclui uma fórmula na qual os parâmetros são atributos.
Atributo derivado
Um atributo cujo valor é derivado do valor de um ou mais atributos no modelo de armazém de dados. Geralmente esse valor inclui medidas de entidade de fato que não são atributos complexos. Esse valor é calculado a partir de dados atômicos no modelo de armazém de dados.
Outros artefatos no modelo de armazém de dados
O modelo dimensional conformado reutiliza entidades do modelo de armazém de dados, geralmente para definir suas dimensões e seus atributos derivados. Consulte os artefatos do modelo corporativo na Fase 3. Alguns dos artefatos são:
  • Entidade fundamental
  • Entidade de classificação
  • Entidade de apoio
  • Atributo básico
  • Atributo de relacionamento

Customização do modelo dimensional conformado

Geralmente, a customização realizada nos requisitos analíticos no contexto do escopo do projeto conduz a customização do modelo dimensional conformado.

Graças aos mapeamentos dos requisitos analíticos, a customização do modelo dimensional conformado é bem simples para todos os elementos do Industry Model pré-existentes nos requisitos analíticos. Se um elemento pré-existente de requisitos analíticos for customizado no contexto do projeto com escopo definido, a customização deve se refletir de acordo no modelo dimensional conformado. Por exemplo, definições e exemplos de uma medida customizada com escopo definido precisam ser revistas e customizadas no modelo dimensional conformado.

Para elementos de modelo que precisam ser criados no modelo dimensional conformado, a descrição dessa tarefa pode ser encontrada em uma descrição de tarefa especial do Industry Model Data Warehouse Development Method.

As duas seções a seguir apresentam exemplos de regras para seguir ao criar novos elementos de modelo dimensional conformado.

Regra 1

Se uma nova entidade de fato for incluída no modelo dimensional conformado, a chave primária precisa ser incluída na lista de atributos (medidas) originários dos requisitos analíticos. Essa entidade é composta de todos os atributos de relacionamento que são as chaves estrangeiras nos relacionamentos dimensionais. As frases verbais são para dimensão ou é uma dimensão de.

Observações:

  • Para uma entidade de fato de captura instantânea, a dimensão de tempo é substituída por um atributo de chave de candidato, como uma data de referência.
  • Os atributos de relacionamento que compõem a chave primária devem ser nomeados de acordo com a dimensão que representam. Por exemplo: id de agente de vendas em um relacionamento de dimensão com a entidade fundamental de função de canal.
  • Isso irá gerar um atributo de chave primária do Explorador de Projetos de Dados do EME que deve ser renomeado como o nome da entidade com o sufixo PK"
  • Os seguintes atributos técnicos precisam ser incluídos no atributo da chave primária:
    • Um atributo de data válido a partir de, que representa o horário de transação para o início do período durante o qual os valores deste dado registrado são verdadeiros no sistema de origem. O atributo de data válido a partir de também é classificado como um atributo básico, e usa um registro de hora de tipo de dado de [TIMESTAMP].
    • Um atributo de dados válido até, que representa o horário de transação para o fim do período no qual os valores deste dado registrado são verdadeiros no sistema de origem. O atributo de data válido até também é classificado como um atributo básico, e usa um registro de hora de tipo de dado de [TIMESTAMP].
  • É preciso mapear a nova entidade de fato para os requisitos analíticos que ela suporta.

Regra 2

Se uma nova dimensão for incluída em uma entidade de fato no modelo dimensional conformado, a nova dimensão precisa ser definida como um relacionamento dimensional que vincula uma entidade fundamental ou de classificação do modelo de armazém de dados para a entidade de fato. As frases verbais são para dimensão ou o é uma dimensão de.

Observações:

  • Você deve definir o atributo de relacionamento que representa a dimensão recém-incluída na entidade de fato como um componente da chave primária da entidade de fato.
  • O nome do atributo de relacionamento deve refletir a dimensão que ele representa. Por exemplo: id de agente de vendas em um relacionamento de dimensão com a entidade fundamental de função de canal.

Figura 16 mostra um recorte de um diagrama de dados de exemplo para um modelo de dados dimensionais para uma tabela de fato de desempenho de tratamento de solicitações. Esta tabela de fato é uma tabela de fato predefinida no modelo dimensional conformado do aplicativo Claim Efficiency Analysis (CEA). Os atributos foram omitidos para melhorar a leitura.

Figura 16. Exemplo de modelo dimensional para desempenho de tratamento de solicitações
Exemplo de modelo dimensional para desempenho de tratamento de solicitações

(Veja uma versão maior da Figura 16.)

O aplicativo Claim Efficiency Analysis (CEA) lida com os fatores que afetam a eficiência do tratamento de solicitações fazendo o seguinte:

  • Monitorando pagamentos de recuperação recebidos de terceiros e de resseguradoras
  • Avaliando a distribuição de solicitações entre intermediários e o carregamento dos manipuladores de solicitações
  • Reconciliando solicitações pendentes contra estimativas de solicitações
  • Realizando análise estatística que pode influenciar o desenvolvimento de produto
  • Analisando a distribuição de solicitações em todos os tipos de eventos de perda.

A solução CEA permite o desempenho do tratamento de solicitações da tabela de fato para monitorar e identificar ineficiências no processo de tratamento de solicitações. Os relatórios que resultam ajudam a otimizar redes de fornecedores e a melhorar eficiência operacional e satisfação do cliente.

Resumo da fase 4

Esta seção descreve o modelo dimensional conformado e como customizá-lo. Um modelo dimensional conformado pode ser transferido para o modelo físico usando o Assistente do InfoSphere Data Architect.


Conclusão

Este tutorial apresentou o processo de desenvolvimento para desenvolver um modelo de dados estável e flexível para um armazém de dados de seguros. A abordagem usou, como modelos de negócios, os conceitos específicos do segmento de mercado do IBM Industry Model for Insurance Information Warehouse (IIW). A modelagem em si é realizada usando a ferramenta de modelagem de dados Information Data Architect (IDA), com o aprimoramento específico Enterprise Model Extender (EME). A abordagem de design apropriada é descrita no Data Warehousing Development Method (DWDM). Você também leu dicas especiais sobre os artefatos principais do processo de desenvolvimento. Entender a descrição da abordagem e o método preparou você para acompanhar as etapas principais do processo de design.

O método consiste, em geral, de quatro etapas que passaram de objetos de negócios e visualizações para objetos mais e mais técnicos. Após coletar os requisitos na fase 1, você desenvolveu o modelo de negócios na fase 2. A coleta de requisitos de negócios é feita em cooperação com os especialistas de negócios, que precisam aprovar o modelo de negócios resultante antes que você possa continuar o processo de desenvolvimento. Nas fases 1 e 2, você usou vocabulário de negócios e outras opções específicas do EME e do ambiente da ferramenta IDA e EME. O tutorial explicou a estrutura desses dois modelos conceituais.

Nas fases 3 e 4, você desenvolveu os modelos de dados lógicos (também chamados de modelo corporativo) a partir do modelo de negócios. Na fase 3, você desenvolveu o modelo lógico para a parte atômica do modelo corporativo, que é um modelo normalizado de relacionamento de entidade (ER). Na fase 4, você lidou com um modelo de dados lógicos dimensional para data marts. Esse modelo é não normalizado e otimizado para consulta e desempenho de análise. As seções que descrevem as fases 3 e 4 oferecem os artefatos mais importantes do método DWDM, e deram exemplos de como customizar alguns desses artefatos. Esses exemplos mostram abordagens de boas práticas para resolver tarefas de modelagem específicas.

Seguindo este roteiro de fases claro, é possível entregar modelos de dados robusto e estável que também são flexíveis o suficiente para integrar novos requisitos de negócios no futuro.

Este tutorial ofereceu um entendimento de alto nível dos aspectos específicos do Industry Models. Em artigos e tutoriais futuros no developerWorks, iremos descrever melhor o IBM Industry Models. Em especial, planejamos oferecer artigos e tutoriais mais detalhados sobre cada uma das quatro fases do processo de desenvolvimento de modelo de dados do IIW com IDA e EME. Também planejamos escrever um artigo que descreve em detalhes o processo de desenvolvimento de um modelo físico a partir de um modelo lógico do IIW existente no ambiente de IDA e EME.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Information Management
ArticleID=608054
ArticleTitle=Use o IBM Industry Model Information Insurance Warehouse para definir modelos de dados inteligentes e maduros
publish-date=01132011