Solução de business intelligence orientada a arquitetura empresarial

Para se implementar uma solução de business intelligence, definiu-se uma abordagem, apresentada na Figura 6.8 que considere a arquitetura empresarial como fonte inicial de definição de requisitos enquanto dimensões e métricas, mas igualmente ao nível de áreas de informação que determinam como são organizados os artefactos de business intelligence.

Figura 6.8: Abordagem de implementação de business intelligence Identificar áreas de informação em AE Obter dimensões e hierarquias em AE Obter conceitos com propriedades de indicadores em AE Ajustar AE face a novas definições de conceitos e relações Implementar BI

113

Ao nível de processos de integração em business intelligence, foram considerados somente princípios de estruturação de processos considerando que as ferramentas de ETL têm por base os seguintes componentes:

• Forma de agregar Jobs por áreas, que neste caso correspondem aos níveis de arquitetura, exceto casos transversais entre vários níveis, como é o caso de tabelas de tempo ou geografia. Na Figura 6.9 é apresentado um caso em Microsoft Integration Services onde se estruturam 2 Packages (Contexto e Operacional), sendo que no caso do package “Operacional”, se coloca agregação de jobs por áreas através de sequence container (e.g. Orgânica), em que cada um se coloca os Jobs para carregamento de tabelas específicas (e.g. LK_EstruturaOrganica);

• Job que agrega um conjunto de tarefas, sendo que cada tarefa tem normalmente um objeto que representa a origem da informação, um objeto que representa a transformação e um objeto que representa o carregamento no destino da informação. Neste caso, cada Job corresponde a uma tabela, isto é, conceito do modelo de ontologia a tratar. Na Figura 6.10 é apresentado um caso em Microsoft Integration Services em que um job visto como control flow, tem um data flow (LK_EstruturaOrganica), com um componente que indica que a origem de dados está em Microsoft Excel, um processo de transformação (script component) e um objeto que representa a tabela destino (ADO Net Destination).

114

Figura 6.10: Processo de integração de dados de uma tabela em Microsoft Integration Sevices

Ao nível de dados, foram considerados modelos implementados em bases de dados com as seguintes características e representado na Figura 6.11 no caso de uma base de dados em Microsoft SQL Server, na Figura 6.12 no caso do modelo de dados para visualização e na Figura 6.13 com uma estrutura de relação entre tabelas em Microsoft Power BI:

• Tipo de modelação em snow flake tendo por base as hierarquias e sua relação com a estrutura de conceitos e respetivas relações com origem na ontologia definida;

• As tabelas com prefixo “FT” (Fact Table) correspondem a tabelas de factos onde as principais métricas e códigos de dimensões estão definidos, sendo que as dimensões são descodificadas em tabelas com prefixo “LK” (Lookup Table). As tabelas LK podem estar relacionadas entre si de acordo com hierarquias de negócio;

• As dimensões correspondem aos conceitos identificados na ontologia, respeitando as nomenclaturas e hierarquias definidas. Numa arquitetura empresarial corresponde a relações entre conceitos;

• As métricas são representadas como tabelas de factos de “Proveitos” e “Custos” que agregam todas as métricas agrupadas pelas dimensões definidas. As métricas têm origem em conceitos de eventos, que agregam várias métricas. Por exemplo, uma transação de proveitos pode indicar métricas de valor da fatura, valor cobrado, valor de impostos, entre outras rúbricas financeiras, além da contagem de faturas;

• Podem existir tabelas de factos complementares, desde que existam sempre os “Proveitos” e “Custos”. Tal é o caso de detalhe de tabelas de faturação (recebidas ou emitida), carteira de clientes e orçamentos, entre outras. No entanto, para focarmos a nossa investigação, consideramos somente os "Custos" e “Proveitos”;

• A relação entre tabelas é mantida, como um modelo semântico, nas ferramentas de business intelligence e não no sistema de gestão de base de dados.

115

No caso da Figura 6.11 apresenta-se a base de dados em Microsoft SQLServer com as respetivas tabelas sendo que as tabelas foram criadas com script DDL gerado a partir de Microsoft Integration Server por ligação direta às fontes de dados mas ajustando as nomenclaturas antes da criação das tabelas.

Figura 6.11: Base de dados em Microsoft SQLServer

No caso da Figura 6.12 apresenta-se o modelo de dados criado em Microsoft PowerBI diretamente com as respetivas relações entre as chaves considerando as chaves estrangeiras, sendo que a ferramenta deteta as relações de acordo com a nomenclatura dos campos mas permitindo acertos na cardinalidade ou na criação de relações específicas que seja necessário ajustar, como é mostrado na Figura 6.13.

116

Figura 6.13: Modelação de dados em Microsoft PowerBI (Relações entre tabelas)

Ao nível de dashboard em business intelligence, considerou-se a representação em quatro áreas temáticas, vistas como áreas de representação de conhecimento, relacionadas com “organização”, “negócio”, “custos” e “proveitos”, com as seguintes características, tal como apresentado na Figura 6.14:

• Cada área reutiliza os conceitos da arquitetura empresarial enquanto dimensões e métricas, com os mesmos nomes;

• A navegação por hierarquias e relações entre dimensões deve ser feita por conceitos de “drill”, permitindo não só mostrar a ontologia (e.g. segmentos tem clientes) mas também o detalhe de métricas instanciado a partir de quantidade de clientes por dimensão e a desagregação por hierarquia da dimensão. No caso de informação muito detalhada é uma vantagem face a visualizações na arquitetura empresarial. O “drill” permite uma navegação entre hierarquias (e.g. de Segmento de cliente para cliente), recalculando as métricas em conformidade e por decomposição de dimensões. Este modelo permite mostrar a relação entre conceitos, com a vantagem de apresentar as métricas em conformidade com o nível de detalhe. Como tal, é uma alternativa mais adequada para visualização da informação, face a modelos de orgânica e relações visualizados numa arquitetura empresarial.

117

Figura 6.14: Estrutura de dashboard business intelligence