Kapittel 3: Design og metode
3.3 Intervju med gruppeledere og foreldre
Partindo do lado esquerdo da Figura 2, vê-se o fluxo de dados dos sistemas operacionais (por exemplo, CRM, ERP etc.) até o Data
Warehouse (DW), que é um banco ou um repositório de dados especial,
preparado para dar suporte a aplicações de tomada de decisão (TURBAN et al., 2009). Segundo Inmon (2005), o (DW) é uma coleção de dados orientada por assunto, integrada, variável no tempo e não volátil, que proporciona suporte ao processo de tomada de decisões dos gestores. Para Kimball e Ross (2002), as principais características que um DW deve buscar são:
Tornar as informações da organização acessíveis, de modo intuitivo e facilmente compreensível.
Tornar as informações da organização consistentes, com alta qualidade e credibilidade.
Ser adaptável a mudanças, sem comprometer dados históricos ou aplicações existentes.
Controlar efetivamente o acesso às informações confidenciais da organização.
Servir como base para as tomadas de decisão.
Ter aceitação dos gestores, pois, diferentemente dos sistemas operacionais que costumam ser de uso obrigatório para o fluxo de trabalho, o DW normalmente é uma solução opcional a ser utilizada.
Uma das grandes diferenças entre os sistemas de bancos de dados operacionais e os Data Warehouses é a forma como os dados são armazenados, o que reflete diretamente no processo de modelagem. Segundo Kimball et al. (2008), no tradicional modelo entidade- relacionamento (MER), a estrutura é otimizada para recuperar, criar e atualizar registros individuais em tempo real, e para preservar a integridade dos dados. No entendimento dos autores, esse modelo não é adequado para a construção de um Data Warehouse. O baixo desempenho em consultas e a falta de uma navegabilidade adequada entre as tabelas para a apresentação das informações são alguns dos motivos citados. Para eles, a técnica mais viável (e amplamente aceita) para disponibilização de dados em soluções de Business Intelligence é a modelagem dimensional.
Nos ensinamentos de Kimball et al (2008), um modelo dimensional é um modelo de dados estruturado para atingir a máxima
performance em consultas e com facilidade de uso, já que em um DW
essas consultas são realizadas recuperando normalmente um grande número de registros e sumarizando seus dados segundo diferentes perspectivas. Assim, é utilizada uma estrutura que normalmente não é normalizada para evitar junções de muitas tabelas, obtendo-se assim uma performance superior. O modelo dimensional divide o mundo em duas partes: medidas e contexto. As medidas são capturadas pelos processos de organização e pelos sistemas operacionais que dão suporte a eles – elas geralmente são valores numéricos e costumam ser chamadas de fatos. Os fatos são envolvidos por um amplo contexto textual no momento em eles são armazenados. Esse contexto é intuitivamente dividido em grupos lógicos chamados de dimensões. As dimensões, por sua vez, descrevem contextos como: quem, o que, quando, onde, por que e como.
No ambiente dos SGBD relacionais, uma tabela-fato é baseada em um evento de medição, a qual geralmente possui um registro para cada medição distinta. Essa tabela-fato possui uma chave composta que faz a ligação com tabelas dimensionais, cada uma com uma única chave primária, a qual descreve precisamente o que é conhecido dentro do contexto dos registros de medição.
De forma geral, cada processo de negócio de uma organização pode ser representado por meio de um modelo dimensional, que consiste em uma tabela-fato contendo as medidas numéricas envolvida por um conjunto de tabelas dimensionais. Devido a essa estrutura característica, um modelo dimensional geralmente é chamado de esquema-estrela (KIMBALL et al, 2008).
Para Inmom (2005), um esquema-estrela é a base para um projeto multidimensional de um Data Mart – que ele define como sendo uma estrutura de dados departamentizada que compõe o Data Warehouse.
Dessa forma, no Data Mart, os dados são denormalizados3 com base nas necessidades de informação do departamento. Kimball et al. (2008) relatam que, embora também utilizassem frequentemente o termo Data
Mart, não o fazem mais, já que o termo está caindo em desuso por
representar conjuntos de dados sumarizados por departamento, independentes e não integrados com o restante da arquitetura. Por isso, os autores preferem adotar o termo business process dimensional models (ou modelos dimensionais dos processos de negócio).
Nas FigurasFigura
3
e Figura4
, podemos observar, respectivamente, um modelo dimensional de um processo de negócios relacionado aos pedidos da organização, e parte de outro modelo dimensional relacionado ao processo de vendas. Neste último, é apresentada a ligação entre uma tabela de fatos e uma dimensão relativa aos produtos associados às vendas.Figura 3 – Exemplo de um modelo dimensional relacionado ao processo de pedidos de uma organização
Fonte: Kimball et al. (2008, p. 235)
3
Os sistemas de banco de dados tradicionais utilizam como boa prática a normalização de suas tabelas, visando garantir a consistência dos dados, a diminuição de redundâncias e a minimização do espaço de armazenamento necessário. Contudo, algumas transações e consultas em bases de dados normalizadas podem se tornar lentas devido às operações de junção entre tabelas. O modelo dimensional, utilizado em DW, utiliza a denormalização de suas tabelas, visando o aumento do desempenho das consultas e a facilidade de utilização pelos usuários finais (KIMBALL; ROSS, 2002).
Figura 4 – Ligação entre uma tabela de fato e uma tabela dimensional, ambas relacionadas a um processo de vendas
Fonte: Kimball et al. (2008, p. 245)
De forma geral, o DW é construído seguindo algumas metodologias. Entre elas, cita-se o ETL (Extract, Transformation and
Load), processo de extração, transformação e carga dos dados das
diversas fontes de dados da organização para as tabelas do modelo dimensional (KIMBALL; ROSS, 2002; INMON, 2005). No processo de ETL, ocorre a consolidação e a integração dos dados organizacionais (limpeza, eliminação de redundâncias, validação etc.).
Para Kimball et al (2008), modelos dimensionais se demonstraram fáceis de entender, previsíveis, estendíveis e altamente responsivos a demandas ad hoc devido à sua natureza simétrica previsível. Além disso, eles são a base de muitas melhorias de
performance dos SGBDs, incluindo potentes abordagens de indexação e
agregação, e de desenvolvimento incremental distribuído de Data
Warehouses mediante o uso de dimensões e de fatos adequados. Os
modelos dimensionais são também a fundamentação lógica de todos os sistemas OLAP.