Título Canalização e Visualização de dados em Data Warehouse para Call Centers Edgar Alexandre Gertrudes Guerreiro Dissertação para obtenção do Grau de Mestre em Engenharia Informática e de Computadores Júri Presidente: Prof. José Tribolet Orientadora: Prof. a Helena Galhardas Vogal: Prof. a Maribel Alves Setembro de 2008
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Título
Canalização e Visualização de dados em Data Warehouse para
Call Centers
Edgar Alexandre Gertrudes Guerreiro
Dissertação para obtenção do Grau de Mestre em
Engenharia Informática e de Computadores
Júri
Presidente: Prof. José Tribolet
Orientadora: Prof.a Helena Galhardas
Vogal: Prof.a Maribel Alves
Setembro de 2008
ResumoA crescente exigência dos clientes ao interagirem com as organizações, bem como o aumento das
pressões competitivas entre elas, leva a que se procurem soluções que optimizem os seus processos
de negócio. Uma organização onde este facto ganha especial relevo é o Call Center. Ao lidar diari-
amente com um grande número de clientes, gera-se uma enorme quantidade de dados, que têm de
ser rapidamente analisados de um modo correcto, para que continuamente se possam melhorar as
operações, quer seja na redução de custos ou no aumento da qualidade dos serviços prestados.
Nesta tese é descrito o processo de optimização de um processo de Extracção, Transformação e
Carregamento (ETL) de dados, a criação de uma componente de visualização de dados (dashboards)
que providencie aos actores do Call Center informação de um modo facilitado e simples e o desenvol-
vimento de um cubo OLAP sobre o modelo multidimensional de um sistema de Business Intelligence
(BI). Estes módulos foram desenvolvido no âmbito de um sistema de BI enquadrado num projecto da
Link Consulting, CCDM (Call Center Data Mart) que visa facilitar os processos de tomada de decisão
nos call centers.
Com os módulos criados, avaliaram-se os processos de ETL, para aferir da performance da solução
criada e sua adaptabilidade aos requisitos do negócio. Devido às métricas de benchmark serem ainda
escassas neste tipo de processos, procurou-se usar frameworks genéricas, que avaliam o sistema
criado como um todo. Com esta avaliação, foi possível ainda estudar a robustez da ferramenta usada
na criação destes processos (Microsoft Integration Services).
Palavras-chave: Call Center, Business Intelligence, ETL, Dashboards, Microsoft Integration Servi-
ces.
i
AbstractThe growing demand of customers in their interactions with organizations, as well as the growing compe-
tition between these organizations, leads the search for solutions capable of optimizing the organizations
business processes. One of these organizations where this fact is especially relevant is the Call Center.
By daily dealing with a great number of clients, a huge amount of data is generated. This data has to be
rapidly and thoroughly analyzed, so that operations can be improved, by reducing costs or by improving
service quality.
In this master thesis is described the process of optimizing a extraction, transformation and load
process (ETL), the creation of the components responsible for the presentation of the information (dash-
boards) and the development of an OLAP cube, that retrieves data from the multidimensional model of a
Business Intelligence (BI) system. These modules were created on a BI system developed by Link Con-
sulting called CCDM (Call Center Data Mart) which had the objective of facilitate the decision making at
the call centers.
With al the modules created, the ETL processes were evaluated, to determine their performance and
adaptability to the business requirements. Due to the fact that benchmark tests, are still very limited
to ETL processes, we opted for the use of generic frameworks, that evaluated the system created as a
whole. With this evaluation it was still possible to study the adaptability of Microsoft Integration Services
in creating these type of processes.
Keywords: Call Center, Business Intelligence, ETL, Dashboards, Microsoft Integration Services.
ii
AgradecimentosEmbora uma tese de mestrado seja, na sua essência, um trabalho individual, existem contributos e
apoios que não podem deixar de ser referidos. Aproveito, assim, esta oportunidade para expressar os
meus mais sinceros agradecimentos:
Antes e acima de todos, à minha irmã, que apesar de ser uma espectacular e ocupada estudante
de direito, sempre se disponibilizou para me ajudar na melhoria do conteúdo da minha tese, através de
constantes leituras e sugestões, e sem as quais possivelmente não conseguiria ter terminado esta tese
dentro do prazo estipulado.
À professora Helena Galhardas, pela sua orientação e disponibilidade demonstradas ao longo da
duração da tese. É imprescindível destacar o seu constante esforço, através de críticas construtivas e
várias sugestões, de forma a que desse de mim o meu melhor e construísse a melhor tese possível,
que na minha opinião excederam em muito aquilo que lhe era exigido. Mesmo nos momentos em que
me era mais difícil ter reuniões presenciais, a professora encontrou sempre maneiras de continuar a
orientar-me de uma forma, que apenas posso classificar como soberba. Enquanto orientadora desta
tese, penso sinceramente que não poderia ter feito uma melhor escolha.
Ao Engenheiro João Damásio, Director da unidade de CRM & Business Intelligence da Link Con-
sulting e co-orientador, pela excelente forma como me enquadrou na equipa de trabalho, bem como na
sua disponibilidade para discutir formas de estruturar o meu trabalho e constante preocupação em que
os meus resultados fossem os melhores possíveis.
À espectacular equipa da Link Consulting, especialmente à unidade de Business Intelligence, que
me acolheu de uma forma soberba e que sempre esteve pronta para me ajudar e contribuir para a
melhoria do meu trabalho, bem como providenciar um ambiente de trabalho que penso será difícil
igualar em qualquer emprego futuro que venha a ter.
À minha família, pela sua ajuda nos momentos mais difíceis, por me fazer procurar em mim o melhor,
me motivar, e sem a qual seria completamente impossível ter terminado o trabalho.
2.3 Micro-actividades e correspondentes operadores do Microsoft Integration Services 2005. 21
3.1 Ligação entre as tabelas que formam a vista F_Times_uCI_V1 . . . . . . . . . . . . . . . 31
x
Lista de AcrónimosBI Business Intelligence
CCS Call Center Supervisor
CCDM Call Center Data Mart
DIP-BENCH Data Intensive Integration Process Benchmark
DW Data Warehouse
DM Data Mart
ETL Extract, Transform and Load
KPI Key Performance Indicator
ODS Operational Data Store
OLAP Online Analytical Processing
SAD Sistemas de Apoio à Decisão
SLA Service Level Agreement
SQL Structured Query Language
SI Sistemas de Informação
THALIA Test Harness for the Assessment of Legacy Information Integration Approaches
WFM Work Force Management
xi
1 Introdução
1.1 Motivação
Um call center1 2 [2] é composto por estruturas físicas, pessoas e onde chamadas telefónicas são
efectuadas (chamadas outbound) e/ou recebidas (chamadas de inbound). Dependendo do tamanho
do Call Center, este pode ter desde algumas dezenas até centenas de operadores telefónicos e várias
campanhas a decorrer em simultâneo. Cada campanha agrega um conjunto de chamadas com objec-
tivos comuns (por exemplo, a campanha de venda de um dado produto). O call center pode existir sob
a forma de uma parcela funcional de uma organização maior ou ser ele próprio uma organização in-
dependente, prestadora de serviços em regime de outsource a outras organizações. Em qualquer dos
casos, as chamadas são efectuadas com um conjunto bem definido de clientes. No caso do call center
operar em regime de outsource este conjunto é definido pela organização que contratou os serviços do
call center. Para além do tratamento de chamadas inbound e outbound, o call center também provi-
dencia serviços de help desk (ajuda/resolução de problemas de clientes), de resposta a cartas, faxes e
e-mails.
Normalmente, um call center utiliza tecnologias com o intuito de melhorar o mais possível a perfor-
mance das suas operações. Uma dessas tecnologias é a redistribuição automática de chamadas, onde
as chamadas de inbound e/ou outbound são atribuídas aos agentes, pela ordem em que são recebidas
ou realizadas. Outra tecnologia comum é a monitorização de chamadas, onde as mesmas são selec-
cionadas aleatoriamente e, depois, monitorizadas, de forma a assegurar que os agentes cumprem os
requisitos de qualidade definidos e, consequentemente, asseguram a satisfação do cliente [3][4].
Existem os seguintes actores com intervenção relevante num call center : Agentes, Supervisor de
Campanhas Inbound, Supervisor de Campanhas Outbound, Consultor Interno, Coordenador de Call
Center, Gestor de Contas Inbound, Gestor de Contas Outbound, Gestor de Recursos Humanos e
Gestor de Call Center. Os operadores ou agentes são quem efectua ou recebe as chamadas. Um
Supervisor de Campanhas Inbound supervisiona grupos de métricas (como o tempo de chamada) bem
como métricas globais de funcionamento do call center (como o número total de chamadas recebidas)
e compara-as com os SLA’s definidos com a organização que requereu os serviços do call center. Um
Supervisor de Campanhas Outbound, tal como o supervisor de campanhas inbound, faz a monitoriza-
ção de um grupo de agentes e suas métricas, mas neste caso das métricas associadas a chamadas
de outbound (por exemplo: número de vendas). Um Consultor Interno, por sua vez, ajuda na resolu-
ção de certos problemas (como a existência de um número baixo de chamadas por hora, para dar um
exemplo), os quais os supervisores de inbound e outbound não conseguem solucionar. Um Coorde-
nador de Call Center faz análises diárias às campanhas em execução, de forma a aferir o seu sucesso
ou insucesso (analisa, por exemplo, o número de vendas ou o tempo de resolução das chamadas de
1Embora o termo call center se refira sobretudo ao tratamento de chamadas inbound e outbound, tendo o termo evoluído para
a designação contact center, que reflecte o facto de existirem mais interacções a ocorrer do que apenas as chamadas, ao longo
desta tese será usado o termo call center indiferentemente, quer se trate de um call center ou contact center [2]2Na literatura por vezes o call center aparece referenciado como call centre e o termo contact center pode aparecer como
contact centre
1
inbound); ele pode, ainda, em situações excepcionais, resolver problemas associados aos operadores,
quando os supervisores não os consigam resolver. Um Gestor de Contas Inbound faz análises diárias
ou semanais dos SLA’s mais relevantes acordados com as organizações que requereram os serviços
do call center (por exemplo: tempo médio de chamada e taxa resolução de problemas na primeira cha-
mada) para um grupo de campanhas. Um Gestor de Contas Outbound também faz analise diárias ou
semanais de grupos de campanhas, mas sobre os SLA’s referentes a chamadas outbound (por exem-
plo: vendas e taxa de sucesso). Um Gestor de Recursos Humanos ocupa-se das métricas relacionadas
com os operadores (o número de operadores necessários por campanha ou a taxa de absentismo, por
exemplo). Finalmente, um Gestor de Call Center tem a seu cargo a análise da performance global do
call center (como o número de horas trabalhadas nas campanhas ou os tempos médios de chama-
das), tomando decisões que podem afectar as operações globais do call center, numa base semanal
ou mensal.
A organização 3 que requisita os serviços do call center define com este um conjunto de métricas,
geralmente denominado Service Level Agreement (SLA), de forma a controlar o bom funcionamento
do serviço efectuado pelo call center. Estas métricas correspondem a conjuntos de valores de indi-
cadores de negócio que devem ser atingidos pelo call center. Em sistemas de apoio à decisão, estes
indicadores de negócio são normalmente denominados Key Performance Indicators (KPI’s). Jonathan
Wu [5] define um KPI como sendo um conjunto de medidas pré-definidas que providenciam informação;
esta informação é usada depois para quantificar objectivos que reflectem a performance e estratégia
da organização. Ou seja, um bom KPI deve simultaneamente, indicar um dado resultado (Indicator ),
estar relacionado com a performance do negócio da organização (Performance) e ser relevante para o
processo de decisão (Key ) [6]. Por exemplo um bom KPI no âmbito dos call centers é a taxa do número
de vendas ou inquéritos efectuados. Este KPI indica o número de vendas ou inquéritos face à totalidade
das chamadas feitas em regime de outbound (Indicator ), mede a eficiência na venda de um produto ou
inquérito (Performance) e é um factor importante nas tomadas de decisões do call center (Key ).
A tabela 1.1 lista alguns dos KPI’s usados na maior parte dos call centers[3][7][8][9].
OS KPI’s da Tabela 1.1 estão classificados segundo quatro categorias: Nível de Serviço e Processa-
mento de Chamadas, Custo, Qualidade e Agentes. O Nível de Serviço e Processamento de Chamadas
descreve os aspectos directamente relacionados com as chamadas telefónicas. O Custo descreve os
KPI’s associados a métricas de custo bem como as vendas/inquéritos efectuados. A Qualidade refere-
se às capacidades dos agentes do call center e a métricas relacionadas com a satisfação dos clientes
que interagem com o call center. Os Agentes contêm todos os aspectos relativos aos agentes, nas
suas tarefas e rotinas diárias. Algumas das métricas mais importantes identificadas, de acordo com os
requisitos do call center são [3][7][8][9]:
• Taxa de abandono: número de chamadas que foram desligadas antes de chegarem a um agente;
• Tempo médio de conversação: o tempo médio que os agentes passam em conversação com os
clientes;
3Esta organização pode significar a organização que detém o call center ou que contrata os serviços do call center em regime
de outsource
2
Nível de Serviço & Proc. de Chamadas Métricas de Qualidade
-Tempo médio de conversação -Satisfação do cliente
-Tempo médio para terminar a chamada -Satisfação do Staff
-Tempo médio de processamento de chamada -Satisfação dos parceiros/distribuidores
-Taxa de Abandono -% Chamas que necessitam de nova interacção
-Tempo médio de atendimento -Taxa de retenção dos clientes
-Taxa de primeiras resoluções -Razões das chamadas
-% Chamadas atendidas nos primeiros x segundos -Conhecimento dos produtos
-Tempo em trabalho pós-chamada -Conhecimento Técnico
-% Chamadas Transferidas -Competências de comunicação
-# chamadas feitas/recebidas -Competências na resolução de problemas
-Taxa de Bloqueios
Custo Agentes
-Custo por chamada -Ocupação
-Custo por minuto -Rotatividade dos agentes
-Custo médio por venda -Absentismo
-Total de itens vendidos -Aderência ao Script
-Horas de treino
-Aderência
-Taxa de Comparência
-Pontualidade
Tabela 1.1: Principais KPI’s usados nos call centers.
• Tempo em trabalho pós-chamada: o tempo médio que os agentes levam a terminar uma chamada;
• Tempo médio de chamada: a combinação do tempo médio de conversação e tempo em trabalho
pós-chamada;
• Tempo médio de atendimento: o tempo médio que leva a atender uma chamada;
• Taxa de primeiras resoluções: percentagem de clientes que vêem os seus problemas resolvidos
na primeira chamada que fazem;
• Taxa de Bloqueios: a percentagem de clientes que não conseguem aceder ao call center num
dado momento devido a falta de recursos do call center (sinal de ocupado)
• Aderência: o tempo que o agente passa em trabalho, comparado com o tempo que é pago;
• Taxa de comparência: taxa de comparecência dos agentes, isto é, se o agente aparece para
trabalhar nos dias em que tem trabalho;
• Ocupação: define se o número de agentes é adequado para o volume de chamadas, isto é, o
tempo que passam ocupados em chamadas sobre o tempo total de trabalho (tempo ocupado em
chamadas e tempo livre);
• Custo por chamada: o custo por cada chamada efectuada;
3
• Rotatividade dos agentes: taxa de rotatividade dos agentes, isto é, número de saídas e entradas
sobre o número de agentes empregados no call center ;
Geralmente, o call center é o primeiro ponto de contacto entre a organização e o cliente, numa comu-
nicação que se faz nos dois sentidos: por um lado, os clientes recorrem ao call center para esclarecer
dúvidas e por outro, é através do call center que a organização entra muitas vezes em contacto com os
seus clientes. Nestas comunicações com os clientes gera-se um grande volume de informação. Esta
informação engloba: dados sobre os clientes (exemplo, histórico de compras, perguntas frequentes),
pormenores sobre as chamadas (tal como, tempos de conversação e tempo dispendido após conver-
sação para terminar a chamada) e determinados pormenores sobre os agentes que fazem a chamada
(exemplo, tempo dispendido em chamadas, horas de trabalho). Toda esta informação desorganizada e
apreendida dispersamente no call center deve depois ser devidamente processada e analisada à luz
dos KPI’s predefinidos. Note-se que, aqui, a exigência crescente dos clientes (que esperam ver as suas
dúvidas rapidamente respondidas) e o maior ritmo com que os principais indicadores de negócio têm
que ser monitorizados são determinantes para que tanto a quantidade de informação como a rapidez
com que esta tem de ser processada sejam cada vez maiores. Percebe-se assim, que a capacidade
de integrar e tratar esta informação de um modo rápido e coerente seja pontos fulcrais em qualquer call
center. A necessidade constante de tratamento de informação aliada ao seu grande volume leva a que
um sistema de Business Intelligence (BI) (ver secção 1.2) possa ajudar em muito as necessidades de
um call center. O uso de um sistema de BI no call center pode trazer as seguintes vantagens:
• Optimizar as operações diárias e minimizar os riscos operacionais, através da constante moni-
torização dos principais indicadores de negócio (por exemplo; tempo de chamadas) e decidir de
acordo com estes indicadores quais as acções mais apropriadas (por exemplo, o número ideal de
agentes que devem estar a trabalhar numa dada campanha).
• Melhorar a qualidade do serviço prestado/Relações com os clientes que telefonam para o call
center, assegurando que estes vêem as suas necessidades rapidamente resolvidas (por exemplo,
maior personalização da resposta e menor tempo de espera).
• Tornar a análise dos indicadores de negócio mais robusta e facilitada, através da análise de infor-
mação detalhada sobre os clientes (como episódios passados e hábitos de compra). Melhorando
a análise dos indicadores de negócio pode-se aperfeiçoar a aferição do estado do negócio (como
vendas dos produtos oferecidos e progresso de cada campanha em execução) [10] [3].
• Identificar os perfis de agentes que melhor se adaptam às necessidades do call center [11].
• Reduzir custos, através da detecção de possíveis problemas (exemplo, campanhas com anormal
número de vendas face aos SLA’s definidos), da utilização de um menor número de agentes e
aumento de lucros operacionais (exemplo, alterar certas campanhas para melhor corresponderem
às expectativas dos clientes) [3].
4
1.2 Os Sistemas de Business Intelligence (BI)
No final dos anos 80, graças ao aumento do poder de processamento e facilidade de conectividade
entre diferentes sistemas (por exemplo, o aumento do número de ferramentas com ligação via Web)
começaram a massificar-se nas empresas aquilo que se designavam como Sistemas de Apoio à Deci-
são (SAD). Estes sistemas, por sua vez, gradualmente foram chegando a um número cada vez maior
de utilizadores dentro das organizações. Os sistemas de apoio à decisão são descritos por Keen e
Scott-Morton como "sistemas que aliam as capacidades intelectuais de indivíduos às capacidades de
sistemas computacionais, para melhorar a qualidade das decisões tomadas"[12]. Em 1989, Howard
Dresner, analista da Gartner, face à proliferação de sistemas de apoio à decisão e suas metodologias,
criou um termo unificador, o Business Intelligence [13].
Jane Griffin, consultora na Deloitte, descreve este termo como "um sistema centrado no utilizador
para a exploração de dados, relações entre dados e tendências, de forma a melhorar o processo de
tomada de decisão", e acrescenta ainda "Isso envolve um processo interactivo de acesso aos dados
e a sua análise para tirar conclusões, fazer descobertas e comunicá-las, com o objectivo de criar uma
mudança positiva na organização"[14]. O BI é assim, hoje em dia, uma componente essencial nos
Sistemas de Informação (SI) das organizações. É o BI que permite aos utilizadores analisarem as suas
operações de negócio e procurarem formas de as optimizarem, reduzindo custos e aumentando lucros
[15] [16].
A figura 1.1 [17] mostra uma arquitectura típica de BI com as suas principias componentes. Um
processo de BI comporta geralmente quatro grandes fases:
Figura 1.1: Arquitectura típica de BI.
1. Os dados que se encontram nas Fontes de Dados vão ser ser submetidos a processos de Extrac-
5
ção, Transformação e Carregamento (processos ETL, ou seja Extraction, Transformation e Load).
A área onde estes dados são submetidos aos processos de ETL é normalmente denominada
Operational Data Store (ODS) ou Área de Retenção (ou Data Staging).
2. Os dados após serem submetidos a processos de ETL, obedecem a um modelo dimensional e
são armazenados em Data Marts e Data Warehouses.
3. Depois de armazenados nos Data Marts e Warehouse, os dados podem ser manipulados por
ferramentas de BI, de modo a permitir a sua visualização em relatórios ou cubos OLAP, e serem
ainda submetidos a processos de Data Mining.
4. As ferramentas de BI apresentam os dados devidamente analisados e transformados aos utiliza-
dores finais.
1.2.1 Extracção, Transformação e Carregamento de dados - ETL
A Área de Retenção (ou Data Staging Area ou Operational Data Store - ODS) é uma área de arma-
zenamento de dados, onde estes sofrem as alterações necessárias para serem, depois, carregados
na Data Warehouse. As alterações efectuadas aos dados são realizadas por processos de ETL. A
primeira etapa de um processo de ETL é a extracção dos dados das suas várias fontes para a área
de retenção. Depois dos dados serem extraídos, sofrem um conjunto de transformações. Exemplos de
transformações normalmente efectuadas são limpeza (por exemplo: correcção de erros ortográficos),
purgação (que consiste na eliminação dos campos que não vão ser usados), combinação de fontes de
dados (agregar dados que fazem sentido estar juntos em vistas unificadas) e criação de identificadores
únicos para os objectos que se armazenam nos modelos multidimensionais. Quando a transformação
dos dados está completa, estes são carregados na data warehouse [18].
1.2.2 Data Warehouse e Data Marts
Uma Data Warehouse é uma colecção de dados orientada a um assunto, integrada, variante no tempo e
não volátil. Estes dados são depois usados para análises [18]. Um Data Mart é um subconjunto da Data
Warehouse, focado num assunto específico ou área de negócio (por exemplo: Data Mart financeiro).
1.2.3 Cubo OLAP
OLAP, Online Analytical Processing, é um tipo de actividade que permite efectuar análises e extracções
de dados a fontes de dados, de um modo rápido e fácil [18] [19]. Um Cubo OLAP é uma estrutura que
possui dados derivados da Data Warehouse e permite uma rápida análise dos dados que esta contém,
permitindo a obtenção de informação útil para o negócio a partir destes dados (como seja a tendência
de vendas de um dado produto). Este cubo é constituído por dados numéricos, chamados factos,
que estão organizados segundo várias dimensões (por exemplo, uma companhia pode querer analisar
dados financeiros sobre um dado produto, período temporal, região). Estas dimensões podem ser
depois agregadas usando hierarquias (por exemplo, países, distritos, cidades). Apesar do nome cubo,
este tipo de estruturas possuem geralmente mais do que três dimensões de análise.
6
1.2.4 Data Mining
Um dos modos de melhorar a análise dos dados é através do uso de técnicas analíticas ou Data Mining,
que permitem descobrir conhecimento novo e potencialmente útil a partir dos dados. Data Mining pode
também ser a extracção de informação sobre tendências futuras em grandes volumes de dados [20].
1.2.5 Relatórios e Dashboard
A grande quantidade de dados disponíveis e a velocidade com que estes devem ser analisados num
processo de tomada de decisão requerem formas de os sumariar e simplificar a sua visualização,
de modo a monitorizar os principais KPI’s do negócio da organização em causa. Um dos modos de
apresentar os dados de um modo sumarizado e simples é através do uso de relatórios. Relatórios são
essencialmente vistas agregadas de dados relevantes para os processos de decisão. Um Dashboard
é "uma ferramenta de relatórios que consolida agregados de dados e disponibiliza métricas (medidas
comparadas com um objectivo) (...) num único ecrã para que a informação possa ser monitorizada
num rápido relance"[21]. Um dashboard pode ainda providenciar avisos, sugerir próximas acções e
sumarizar certas condições de negócio (como por exemplo, as margens de lucros de um dado negócio
e sua evolução). Os dashboards são normalmente dinâmicos, orientados para tecnologias Web e
fornecem a possibilidade de serem ligados a ferramentas analíticas [22][23].
1.3 Objectivos
O trabalho realizado está enquadrado no âmbito de um projecto de desenvolvimento de um sistema de
BI para call centers levado a cabo na Link Consulting [24] de nome CCDM (Call Center Data Mart) que
visa facilitar os processos de tomada de decisão nos call centers. Os objectivos de desenvolvimento
deste projecto foram:
1. Criação de um modelo multidimensional para os principais indicadores do negócio do call center
em questão.
2. Construção de um sistema de ETL eficaz, que extraísse os dados das respectivas fontes e os
canalizasse para o modelo multidimensional criado.
3. Visualização dos dados presentes no modelo multidimensional, nomeadamente a criação de um
conjunto de dashboards que permita a fácil monitorização de indicadores de negócio relevantes
por parte dos vários intervenientes nas operações do call center.
Esta tese focou-se principalmente no segundo e terceiro pontos enunciados.
No segundo ponto, Construção de um sistema de ETL, salienta-se a identificação dos dados re-
levantes, que necessitavam de ser integrados a partir da grande quantidade de dados disponível nos
sistemas fonte. Destaca-se ainda a determinação de como os dados integrados deviam ser transfor-
mados de forma a se calcularem os indicadores de negócio pretendidos pelo call center (fórmulas de
cálculo dos indicadores). O modo de cálculo é especialmente relevante pois implicou a necessidade
de se perceber claramente os indicadores pretendidos e como estes poderiam ser obtidos a partir dos
7
dados disponibilizados pelo call center. Realça-se também a criação dos fluxos na ferramenta Microsoft
Integration Services [25] que permitiam o cálculo destes indicadores e sua passagem para o modelo
multidimensional. Por fim é de destacar a optimização efectuada a este processo de ETL, onde se
procurou perceber a carga temporal e de recursos computacionais sobre o sistema, imposta por cada
módulo deste componente e de acordo diminuir o tempo de execução do processo, tornando-o mais
eficiente.
No terceiro ponto, Criação de um conjunto de dashboards, sublinha-se o cuidado na concepção de
dashboards que permitissem a visualização dos indicadores de uma forma rápida, simples, respon-
dendo às necessidades de quem os ia consultar e de acordo com as melhores práticas de desenho
destes componentes [26]. Sobre este ponto destaca-se ainda a criação de um cubo OLAP sobre o qual
os dashboards iam buscar a informação. A criação deste cubo permitiu não só a obtenção de informa-
ção por parte dos dashboards mais facilitada e rápida, como providenciou mecanismos aos utilizadores
de fazerem as suas próprias pesquisas de um modo simples.
1.4 Tecnologias Existentes
No mercado de BI existem várias ferramentas específicas para call centers. Existe também um número
considerável de ferramentas que facilmente se adaptam às necessidades de BI de um call center,
isto é, ferramentas de fabricantes, que não sendo exclusivas para o domínio do call center possuem
módulos específicos para este domínio. Dos fabricantes de ferramentas de BI específicas ou facilmente
adaptáveis para call centers destacam-se a Genesys, Avaya, Business Objects e Oracle de acordo
com estudos da Gartner [27] [28] [29] e Forrester Wave [30]. Embora cada call center tenha as suas
necessidades específicas no que diz respeito a sistemas de BI, as ferramentas aqui citadas suprimem
as necessidades da maioria dos call centers.
Apesar deste tipo de ferramentas ser bastante útil na construção de sistemas de BI para call centers,
elas possuem algumas desvantagens, nomeadamente:
• Preço elevado.
• Pouca documentação disponível, de forma gratuita, que facilite o processo de escolha de entre as
várias ferramentas existentes.
Na construção deste sistema de BI em que se concentrou esta tese, optou-se pelo desenvolvimento
de uma solução de raiz, ao invés de se recorrer a uma já existente. Na base desta decisão esteve,
essencialmente, o facto do cliente da solução não ter manifestado vontade na compra de uma destas
ferramentas.
1.5 Tecnologia usada e Metodologia
O processo de ETL e os dashboards para visualização de dados foram desenvolvidos, recorrendo a
tecnologia Microsoft, nomeadamente:
8
• Microsoft SQL Server 2005 [31] e módulo Integration Services 2005 [25] do SQL Server 2005
para a construção das componentes de ETL.
• Microsoft Sharepoint 2005 Services [32], módulo Microsoft Reporting Services 2005 [33] do SQL
Server 2005 e Microsoft Excel 2007 [34] para a construção dos dashboards.
Como base de desenvolvimento das soluções de Microsoft enunciadas, foi utilizado o Microsoft
Visual Studio 2005 [35].
1.5.1 Metodologia Seguida
A metodologia seguida no desenvolvimento desta solução seguiu em parte a definida por Ralph Kimball
[18]. Esta metodologia centra-se sobretudo no ciclo de vida de um projecto de Data Warehouse e
compreende três fases: a vertente que define o projecto do Data Warehouse, a vertente de gestão
do projecto e a vertente que explicita passo a passo quais as tarefas a desempenhar de forma a que
consigamos implementar correctamente a Data Warehouse. Na Figura 1.2 pode-se ver a metodologia
proposta por este autor. Como se pode observar nesta abordagem é essencial perceber os requisitos
do negócio, tais como as necessidades dos utilizadores, nomeadamente a rapidez com que precisam
de ter os dados e principais indicadores de negócio para tomada de decisões, factores importantes
tendo em conta as necessidades do call center [16].
Figura 1.2: Metodologia de Data Warehousing proposta por Ralph Kimball.
As fases de desenvolvimento da solução foram as seguintes:
1. Identificação dos principais indicadores de negócio (de acordo com os utilizadores do sistema)
e seu modo de cálculo, segundo o conhecimento adquirido sobre o negócio dos call centers. A
definição do modo de cálculo de cada um dos indicadores foi um processo que sofreu algumas
iterações, à medida que ia sendo validado.
2. Definição da arquitectura da solução de ETL e implementação desta arquitectura.
3. Definição das interfaces de cada um dos dashboards que correspondia às necessidades dos
actores identificados. Estas interfaces, pela impossibilidade de serem validadas directamente
com os utilizadores, foram validadas com especialistas da Link Consulting. Este foi um processo
iterativo, com constantes melhorias das interfaces desenvolvidas e consequentes validações.
9
4. Criação de um cubo OLAP sobre o modelo multidimensional existente.
5. Ligação dos dashboards ao cubo OLAP, já com os dados providenciados pela solução de ETL.
6. Validação experimental dos componentes desenvolvidos, com especial ênfase na componente
de ETL. Na componente de ETL procurou-se principalmente aferir da performance da solução
desenvolvida, no que diz respeito à capacidade de integrar e calcular grandes quantidades de
dados gerados pelo call center de uma forma eficiente e rápida (testes de bechmarking).
1.6 Contribuições
Dado que a tese se enquadrou num projecto de engenharia de BI, a primeira contribuição foi respon-
der aos objectivos enunciados na secção 1.3, ou seja desenhar e implementar o processo de ETL e
componente de dashboards.
Em segundo lugar, procedeu-se à avaliação do módulo de ETL, procurando-se optimizar este pro-
cesso, tornando-o mais eficiente e rápido. Ao avaliar este processo seguiu-se e extendeu-se uma
framework de avaliação de processos de ETL genérica, devido ao facto dos benchmarks deste tipo
de processos serem ainda escassos. Avaliou-se ainda o Integration Services do Microsoft SQL Server
2005 [25] como ferramenta de ETL. Utilizando o sistema de BI para call centers em causa como caso
de estudo, avaliou-se a capacidade do Microsoft Integration Services [25] em três vertentes:
1. expressividade dos operadores para desenhar o processo de ETL necessário;
2. eficiência do Microsoft Integration Services para tratar grandes volumes de dados; e
3. metodologia de ETL usada na Link Consulting [24].
Em terceiro lugar, elaborou-se um estudo que reflecte o estado da arte das ferramentas de BI com
aplicação em call centers. Este estudo encontra-se detalhado no Capítulo 2.
Finalmente, como consequência do modelo dimensional criado permite-se que através de ferramen-
tas como o Microsoft Excel 2007 [34], os utilizadores finais a que se destina o sistema criado possam
de um modo facilitado criar as suas próprias tabelas e gráficos com dados relevantes sobre o call center
onde operam. Permite-se assim que estes utilizadores não tenham de limitar a sua análise apenas aos
dashboards providenciados, podendo criar os seus próprios relatórios e dashboards se assim acharem
necessário.
1.7 Organização da Tese
Esta dissertação encontra-se organizada da seguinte maneira. O Capítulo 2 apresenta as principais
soluções de BI para call centers existentes no mercado. Neste capítulo apresenta-se ainda um estudo
sobre benchmarks de processos de ETL. O Capítulo 3 descreve a metodologia usada para construir
o processo ETL, tal como é utilizado na Link Consulting [24]. O Capítulo 4 apresenta os dashboards
desenvolvidos e explica as decisões tomadas na sua concepção. O Capítulo 5 reporta os resultados
dos testes efectuados sobre o processo de ETL construído no Microsoft Integration Services [25] e
discute as principais vantagens e desvantagens enquanto ferramenta de ETL, aplicada a este caso de
10
estudo. No Capítulo 6, são expostas as principais conclusões desta tese e possíveis desenvolvimentos
futuros.
11
2 Trabalho Relacionado
Este capítulo incide sobre dois tópicos que estão relacionados com o trabalho realizado. Primeira-
mente, são estudadas as ferramentas de BI para Call Centers disponíveis no mercado. Em seguida,
apresentamos um estudo sobre Benchmarks em fluxos de ETL. Ambos estes tópicos são importan-
tes no âmbito do trabalho desenvolvido. No que diz respeito à ferramentas de BI para Call Centers é
importante perceber quais as suas funcionalidades e quais as ferramentas que melhor se adaptam às
necessidades do call center a que a solução a desenvolver se destina. Quanto aos Benchmarks em
fluxos de ETL são importantes, pois é fundamental arranjar mecanismos que permitam aferir da perfor-
mance da componente de ETL da solução desenvolvida, para verificar se esta serve as necessidades
dos call centers.
2.1 Ferramentas de BI para Call Centers
2.1.1 Características das Ferramentas
Para classificar as ferramentas de BI disponíveis, tomam-se em consideração as características [36]
(ver tabela 2.1):
Funcionalidades Compatibilidade
-Dashboards -Sistemas Legados
-Data Mining (motor analítico) -Produtos/Tecnologias comuns nos Call Centers
-Data Mart -Produtos BI mais usados
-Relatórios Predefinidos -Standards da industria
-Acesso Via Internet
-Multi-plataforma/Integração Facilidade de Modificação
-Suporte Directo a consultas -Relatórios
-Gestão dos Recursos Humanos -Dashboards
-KPI’s pré-definidos
Facilidade de Uso Interface Gráfica
-Pelos criadores dos sistemas de BI -Graficamente Familiar
-Pelos utilizadores finais -Graficamente Apelativo
Serviços/Suporte do fabricante da ferramenta
Tabela 2.1: Características usadas na classificação das ferramentas de BI para call centers.
As funcionalidades, expressam as capacidades genéricas das ferramentas. Para dar um exemplo,
um determinado call center pode não necessitar da funcionalidade data marts, por esta já ter sido
implementada por outra ferramenta.
• Dashboards: os dashboards providenciados e suas componentes (por exemplo: gráficos disponi-
bilizados).
13
• Data Mining (motor analítico): as técnicas de data mining providenciadas (como sejam árvores de
decisão e clustering).
• Data Mart : se a ferramenta tem um repositório para guardar a informação relevante do call center.
• Relatórios Pré-definidos: os relatórios pré-definidos providenciados pela ferramenta para uso di-
recto com um esforço mínimo de alterações/adaptações às necessidades específicas do call cen-
ter (dois exemplos de relatórios pré-definidos são: Performance do Call Center, Performance dos
Agentes).
• Acesso via Internet : capacidade de aceder à ferramenta remotamente. Note-se que esta é uma
característica fundamental para um call center. De facto, o elevado número médio de empregados
justifica que o melhor modo de acederem a relatórios e dashboards é via uma interface web;
• Multi-plataforma/Integração: capacidade de integrar dados de múltiplas fontes, para reunir infor-
mação sobre o negócio do call center.
• Suporte Directo a consultas: capacidade de se fazerem consultas directas aos dados, via lingua-
gens específicas, como SQL.
• Gestão de Recursos Humanos: módulos que permitam a gestão dos recursos humanos (como
a previsão das necessidades do call center relativamente ao número de agentes que melhor se
adequam a uma certa campanha, por exemplo);
• KPI’s pré-definidos - o conjunto de KPI’s providenciados directamente pela ferramenta (por exem-
plo, os tempos de conversação e de chamada, as vendas, entre outros), os quais permitem uma
mais rápida instalação da ferramenta, através da simplificação no uso dos principais indicadores
monitorizados pelos call centers.
Compatibilidade: a capacidade que a ferramenta tem para se integrar com os sistemas legados
existentes no call center e com os principais vendedores de soluções para call centers disponíveis no
mercado. Note-se que é, também, tida em consideração a capacidade de implementação da ferramenta
dos standards da indústria. Também se tem em consideração se o vendedor da ferramenta é um dos
principais distribuidores deste tipo de soluções, de acordo com a pesquisa efectuada pelo Gartner
Research [29];
Facilidade de Modificação: a facilidade com que se podem alterar as características da ferramenta
na criação de relatórios e dashboards, por exemplo, de acordo com as necessidades do utilizador.
Facilidade de Uso: a facilidade com que a ferramenta é utilizada, quer pelos responsáveis do
desenvolvimento da solução de BI, quer pelos utilizadores finais desta;
Interface Gráfica: a interface gráfica da ferramenta diz respeito, principalmente, às componentes
dos dashboards (visto serem estas as mais contempladas nas representações gráficas). A interface
gráfica pode ser classificada de duas maneiras:
• Graficamente Familiar: se os dados apresentados pelos dashboards são de fácil leitura pelos
utilizadores finais e os componentes para a sua criação são facilmente entendidos.
• Graficamente Apelativo: se os dashboards apelam ao utilizador, através do uso de vários arte-
factos, que ao mesmo tempo que atraem a atenção do utilizador, não o distraem das principais
tarefas que está a realizar.
14
Serviços/Suporte do fabricante da ferramenta: os serviços providenciados pelo vendedor da
ferramenta (por exemplo: implementação da ferramenta de BI no call center e treino no uso da ferra-
menta).
2.1.2 Classificação das Ferramentas de BI para Call Centers
No estudo levado a cabo nesta tese, foram avaliadas dezanove ferramentas de BI para call centers,
ou que podem ser facilmente adaptadas para este propósito, devido a possuírem módulos específicos
para o domínio dos call centers. É importante salientar que algumas das características acima men-
cionadas, tal como a facilidade de uso ou de modificação, não foram exaustivamente testadas, visto
não possuirmos as ferramentas para experimentação. De um modo geral, a informação providenciada
pelos vendedores é muito limitada, principalmente no que se refere às componentes mais técnicas.
As ferramentas testadas podem ser consultadas na Tabela 2.2:
Ferramenta Empresa
Avaya IQ Avaya [37]
Business Objects Contact Center Analytics Business Objects [38]
AgentView Centergistics Solutions [39]
Envision Business Intelligence Envision [40]
Genesys Contact Center Software Genesys [41]
Inova Solutions Call Center Dashboard Inova Solutions Call Center Dashboard [42]
Contact Centre Solutions inDashboard inRound Innovations [43]
Latigent Cisco [44]
EyeOps LiveOps [45]
People Soft Service Dashboard Oracle [46]
Performance Management Performance Edge [47]
PilotWorks Pilot Software [48]
Right Now Reporting and Dashboards Right Now [49]
SpeedWare Call Center Solutions SpeedWare [50]
nVision Symmetrics [51]
Contact Center Solutions Vista Symon [52]
Seratel Transera [53]
Verint Contact Center Solutions Verint [54]
VPI Call Center Performance Dashboards VPI [55]
Tabela 2.2: Ferramentas de BI para Call Centers
Existe um largo número de soluções de BI para call centers, com especial ênfase na componente
dos dashboards. É importante, por isso, compreender as necessidades específicas de cada call center,
de forma a escolher a ferramenta que melhor as satisfaz. De facto, existem call centers que apenas
15
necessitam da funcionalidade de apresentação dos dashboards, orientando, por isso, a escolha da
ferramenta nesse sentido. Existem outros call centers que exigem soluções mais complexas, com mó-
dulos de data mining, data marts, gestão de recursos humanos e capacidades de integração com várias
plataformas e fontes de dados. Outros factores a considerar são os KPI’s providenciados directamente
pela solução, os relatórios pré-definidos e a facilidade de modificação e de uso.
É importante referir a existência de um conjunto de características comum às dezanove ferramentas:
acesso via web, dashboards, suporte dos principais KPI’s, um conjunto de relatórios pré-definidos,
interface gráfica e algum grau de modificação das componentes da ferramenta (relatórios, dashboards).
Este conjunto de características foi considerado como o mínimo essencial para que uma ferramenta de
BI suprima as necessidades mais básicas de um call center.
Numa primeira análise, foi encontrado um grande número de ferramentas (mais concretamente dez),
entre as dezanove estudadas, com poucas características relativamente ao número de funcionalidades,
compatibilidade e interface gráfica. Com estes dados, seleccionaram-se nove ferramentas, as quais fo-
ram, depois, submetidas a um segundo estudo mais detalhado. Na segunda análise, as características
usadas para distinguir as ferramentas foram: existência de data mart, motor analítico, serviços e suporte
providenciados, multiplataforma/integração, módulo de gestão de recursos humanos, aspecto visual e
produtos compatíveis. As nove ferramentas analisadas foram: Avaya IQ, Business Objects Contact
Center Analytics, Envision Business Intelligence, Genesys Contact Center Software, Inova Solutions
Call Center Dashboard, Oracle PeopleSoft Service Dashboards, Performance Edge Performance Ma-
nagement, Symmetrics nVision and Symon Contact Center Solutions Vista. O resultado da comparação
destas ferramentas utilizando as características acima mencionadas encontra-se na figura 2.1.
Na Figura 2.1, note-se que a coluna do Aspecto Visual refere-se à apresentação - mais ou menos
atractiva - dos dashboards da ferramenta, numa escala de 1 a 5 (sendo o 5, visualmente apelativo e o
1, pouco apelativo visualmente). É de referir que por restrições temporais esta classificação visual não
pôde ser efectuada com utilizadores de call center ou outros similares, pelo que esta classificação foi
efectuada individualmente, mas pensando sempre na óptica dos utilizadores deste tipo de soluções.
A coluna das Características Adicionais diz respeito a considerações sobre módulos adicionais ou
particularidades da ferramenta importantes de salientar (como por exemplo: módulos adicionais provi-
denciados). A coluna dos Produtos Compatíveis é referente a produtos que são compatíveis ou fáceis
de adaptar, para uso conjunto com a ferramenta em análise; para esta coluna foi tido em conta se o
fabricante da ferramenta é um dos principais fornecedores de ferramentas e materiais de call centers
(de acordo com o Gartner Research Group [29]). O conteúdo das restantes colunas é o seguinte:
• SIM- se a solução tem aquele módulo específico;
• SOLUÇÃO DO FABRICANTE - apesar da ferramenta não ter aquele módulo específico, o fabri-
cante da ferramenta tem soluções com este módulo, e logo a sua integração é relativamente fácil
(por exemplo, ainda que a ferramenta Business Objects Contact Center Analytics [38] não tenha
um data mart incluído, o fabricante da ferramenta possui data marts que podem ser ligados a esta
ferramenta);
• NÃO DISPONÍVEL - foi impossível obter informação sobre a característica em análise;
16
Figu
ra2.
1:C
arac
terís
ticas
dist
intiv
asen
treas
ferr
amen
tas
deB
Iana
lisad
as.
17
• NÃO - a ferramenta não possui aquele módulo.
Analisando a Figura 2.1 é possível identificar dois grupos de ferramentas:
• Grupo 1 - Ferramentas cuja interface gráfica vai de relativamente boa a muito boa e um número
de funcionalidades aceitável (Symon, Envision, Performance Edge, Inova Solutions);
• Grupo 2 - Ferramentas com uma interface gráfica que vai de relativamente boa a muito boa e um
grande número de funcionalidades (Oracle, Avaya IQ, Genesys, Symmetrics nVision, Business
Objects).
Comparando a figura 2.1 com o Quadrante Mágico de Gartner para Plataformas de Business Intelli-
gence [27], a ferramenta Business Objects [38] é uma das ferramentas que se destaca, providenciando
um bom número de funcionalidades aliada a uma boa interface gráfica. Isto indica que esta ferra-
menta pode ser uma boa escolha para a maior parte das necessidades do call center. Esta indicação
é reforçada pelo estudo da Forrester Wave Research em plataformas de relatórios de BI e análise (BI
Reporting And Analysis Platforms) onde a ferramenta Business Objects se destaca como uma das
soluções com uma forte estratégia e oferta[30].
É importante salientar que uma ferramenta como a Avaya IQ [37], que possui menos capacidades
gráficas que a Genesys [41] ou a Business Objects [38] e relativamente o mesmo número de funcio-
nalidades, não é uma escolha pior que estas, visto que esta escolha depende muito das necessidades
específicas do call center em questão. Da mesma forma que uma ferramenta como a Inova Solutions
[42], que tem menos funcionalidades que muitas das ferramentas analisadas, pode ser mais adequada
para um determinado call center que já tenha as restantes funcionalidades implementadas por ou-
tras ferramentas. Por outro lado, devido a restrições especiais - como monetárias ou temporais - ou
a determinadas especificidades dos requisitos pretendidos pelo call center, que não sejam facilmente
colmatados pelas ferramentas analisadas, por vezes, a resposta passa pela criação de uma solução de
BI específica para aquela situação [56].
2.2 Benchmark em Fluxos de ETL
Tal como referido na secção 1.2.1 os processos de ETL são uma parte integrante de qualquer sistema
de BI. Devido à sua importância dentro dos sistemas de BI, o número de ferramentas que disponibilizam
este tipo de processos tem vindo a aumentar. De entre as principais ferramentas que disponibilizam
processos de ETL, destacam-se a IBM, a Informatica, a Microsoft, a Oracle e a Business Objects, de
acordo com a Gartner Research [57]. Com o aumento do número deste tipo de ferramentas, aumen-
tam, também, o número de técnicas de desenho, de conjuntos de transformações e de linguagens para
modelar os processos de ETL, já que as ferramentas não seguem uma abordagem standard. Além
disto, aumenta cada vez mais o volume de dados que as organizações precisam de analisar. Torna-se,
por isso, importante perceber se face ao crescente volume de dados, é possível escalar as soluções de
ETL desenvolvidas, de forma a processarem um maior volume de dados com a máxima eficiência pos-
sível [58] bem como avaliar as soluções desenvolvidas, procurando meios de as melhorar. No entanto
apenas recentemente se começaram a denotar preocupações em analisar e optimizar os workflows
18
(isto é, a transição dos vários processos) de ETL como um todo (ao invés de se procurarem soluções
óptimas, mas específicas de cada ferramenta) bem como procurar modos de os tornar robustos con-
tra falhas [59] [1]. Tal como foi salientado no Relatório Lowell [60] é fundamental que se começam a
procurar maneiras de medir a performance de workflows ETL e definam benchmarks para este tipo de
processos. Em parte como resposta a este relatório, só agora começam a surgir métricas de Bench-
mark standards para os processos de ETL, levando a que só muito recentemente se tenham começado
a criar frameworks para experimentação destes.
Os benchmarks estudados nesta secção, e os únicos encontrados na literatura sobre workflows
ETL procuram seguir os princípios abordados por Gray para benchmarks de sistemas transaccionais e
bases de dados [61]:
• Deve ser relevante no domínio de sistemas de integração heterogéneos, tendo que ter os proces-
sos de integração mais comuns presentes nos vários sistemas de integração;
• Deve ser portável, isto é, independente das plataformas, quer a de integração, quer as plataformas
dos sistemas fonte e destino;
• Deve ser escalável de forma a poder ser aplicado a sistemas quer de grande ou pequena dimen-
são;
• Deve ser simples na sua execução e análise.
Vassiliadis, Karagiannis, Tziovara e Simitsis [1] propõem que se experimentem as soluções de ETL
desenvolvidas representando os processos de ETL de um modo comum e independente da ferramenta
onde os processos são desenvolvidos. Estes autores descrevem um workflow de ETL como um con-
junto de actividades que podem ser representadas por meio de grafos, que especificam a ordem das
extracções, transformações e carregamentos efectuados. Para explicar estes grafos, consideremos
dois tipos de entidades: os conjuntos de dados, que descrevem as fontes de dados usadas/criadas (por
exemplo, ficheiros e tabelas de modelos multidimensionais) e as actividades, que se referem a qual-
quer operação que recebe como entrada um conjunto de dados e sobre este realiza qualquer processo
de extracção, transformação ou carregamento. Assim formalmente um workflow ETL pode ser visto
como um grafo G(V,E), onde cada nó v pertencente a V é uma actividade ou conjunto de dados e cada
conjunto (a,b) pertencente a E, denota que b recebe dados de a para posterior processamento.
Estes autores [1] consideram que todos os sistemas de ETL são compostos por actividades de nível
micro (micro-level activities) e actividades de nível macro (macro-level activities). As actividades de
nível micro estão divididas em três categorias: Extracção; Transformação e Limpeza e Carregamento.
Para a actividade de Transformação e Limpeza os autores dividem estas três actividades nas seguintes
categorias operacionais:
• Operações ao nível da linha (Row-level operations) - operações localizadas sobre uma única
coluna de uma tabela;
• Operações de reencaminhamento (Router operations) - onde para cada dado de destino (output)
se decide para onde ele vai ser enviado;
• Operações de Grupo Unárias (Unary Grouper operations) - que transformam um conjunto de
linhas numa única linha;
19
• Operações Holísticas Unárias (Unary Holistic operations) - que efectuam transformações a todo
o conjunto de dados disponível;
• Operações Binárias ou N-árias (Binary or N-ary operations) - que combinam várias entradas numa
mesma saída.
Na Tabela 2.3 faz-se o mapeamento das actividades e operações aqui descritas com os operadores
disponibilizados pelo Microsoft Integration Services 2005 [25], que foi a ferramenta usada na constru-
ção do sistema de ETL abordado nas secções posteriores (ver Capítulo 3). Permite-se assim fazer o
mapeamento entre as micro-actividades descritas e os operadores que as permitem realizar usando o
Microsoft Integration Services 2005.
Os mesmos autores consideram ainda a existência de workflows de nível macro (macro level work-
flows) que descrevem o modo como as actividades individuais e os dados se conjugam para criar um
workflow complexo. Os autores introduzem o conceito de Borboletas ETL (Butterflies) (Ver Figura 2.2),
que descrevem workflows genéricos de ETL. A parte esquerda da borboleta diz respeito às actividades
de ETL típicas (extracção, transformação e carregamento). O centro da borboleta diz respeito à fonte
para onde os dados são canalizados, ou seja a DW. Finalmente a parte direita da borboleta diz respeito
às actividades que usam os dados da DW para relatórios e análises [1].
Figura 2.2: Borboleta genérica de um workflow ETL
Este benchmark pretende assim providenciar uma abordagem experimental, a ser usada para afe-
rir dos métodos ETL e respectivas ferramentas, no que diz respeito a um conjunto de medidas (ou
parâmetros) que abranjam o maior número possível de workflows.
Os autores dividem esta abordagem experimental em dois grandes objectivos que devem ser afe-
ridos: efectividade e eficiência. Na efectividade pretende-se aferir da disponibilidade dos dados, para
estarem actuais e completos aquando do seu uso em processos de tomada de decisão, pretende-se
ainda aferir da resistência do sistema a falhas ocasionais. Na eficiência pretende-se determinar a rapi-
dez de execução do workflow bem como os recursos por este consumidos.
Considerando a definição de workflows acima descrita, os autores propõem um conjunto de parâ-
metros que permitem configurar os workflows em borboleta, bem como um grupo limitado de medidas
importantes na monitorização da solução de ETL desenvolvida. Os parâmetros propostos para confi-
gurar os workflows criados são:
• tamanho do workflow, ou seja o número de nós do grafo;
20
Tabela 2.3: Micro-actividades e correspondentes operadores do Microsoft Integration Services 2005.
• estrutura do workflow, isto é, variação das actividades de cada nó e suas ligações;
• tamanho dos dados de entrada, que se traduz no número de registos dos ficheiros e bases de
dados dos sistemas fonte;
• probabilidade de ocorrerem falhas (como a solução parar o seu workflow normal de execução).
As medidas que devem ser monitorizadas e avaliadas relacionam-se com os dois principais objecti-
vos acima enunciados: efectividade e eficiência. As principais medidas de efectividade são:
• Medidas do grau de actualidade dos dados e sua completude:
– Percentagem de dados que violam as regras de negócio;
– Percentagem de dados que deviam ser colocados nos modelos multidimensionais mas não
foram.
• Medidas da capacidade de resistência a falhas:
– Percentagem de workflows retomados com sucesso após falhas.
As principais medidas de eficiência são:
21
• Velocidade de execução do processo:
– Tempo total para se completar o workflow ;
– Tempo total para se completar o workflow incluindo uma dada percentagem de falhas;
– Tempo médio de execução por tuplo.
• Recursos consumidos pela execução da solução:
– Mínimo, Máximo e Média de memória consumida pelo processo ETL nos sistemas fonte;
– Mínimo, Máximo e Média de memória consumida pelo processo ETL no modelo multidimen-
sional;
– Tempo necessário para efectuar um dado número de querys para o suporte de decisões ao
modelo multidimensional na presença do sistema de ETL desenvolvido.
– Tempo necessário para efectuar um dado número de querys para o suporte de decisões ao
modelo multidimensional na presença do sistema de ETL desenvolvido, mas considerando
falhas nos sistemas fonte ou no modelo multidimensional.
Procura-se com este benchmark estudar a solução de ETL como um todo, ao invés de procurar
medidas específicas para cada actividade integrante da solução. Providencia-se assim uma framework
comum que permite avaliar qualquer processo de ETL construído.
Böhm, Habich, Lehner e Wloka seguem uma abordagem semelhante para descrever uma framework
genérica para avaliação de workflows ETL [59]. Estes autores propõem uma framework de nome
DIP-Bench (Data Intensive Integration Process Benchmark). As principais diferenças deste benchmark
para o proposto por Vassiliadis, Karagiannis, Tziovara e Simitsis [1] prendem-se com as medidas de
avaliação da performance do benchmark e a definição de uma métrica específica de avaliação. As
medidas de performance são:
• Tamanho da fonte de dados;
• Tempo, onde se usam medidas de tempo abstractas representadas por tu, que correspondem a
0.5 milisegundos;
• Distribuição, que representa a distribuição dos valores das fontes de dados, que pode ir desde
uma distribuição uniforme até valores bastante dispares.
Por forma a determinar o custo de uma operação estes autores baseiam-se num modelo de custos com
as seguintes três categorias:
• Custos de comunicação, com os sistemas externos (por exemplo: atrasos na comunicação com
os sistemas fonte);
• Custos de gestão interna, como sejam, custos de processamento de instâncias do sistema;
• Custos de processamento, isto é, execução do workflow.
A partir destes três custos os autores propõem o uso de uma métrica que abranja todo os sistema e
que é dada pela soma de todos os custos normalizados do sistema em questão com a soma do desvio
médio positivo. A inclusão do desvio médio, deve-se a classificar com uma melhor pontuação, sistemas
com uma performance previsível (isto é, que não varie muito).
22
Por fim destaca-se ainda a framework THALIA , Test Harness for the Assessment of Legacy Infor-
mation Integration Approaches, uma das primeira frameworks de benchmark a aparecer como resposta
ao Relatório Lowell [60]. Esta framework providencia uma conjunto standard de queries a fazer a um
sistema e um conjunto de classificações a atribuir a este sistema em função dos resultados obtidos.
Esta framework é contudo menos genérica que as duas anteriores aqui apresentadas, visto não ter
em consideração a performance do processamento do sistema onde o workflow está a correr, conside-
rando apenas o número de queries respondidas correctamente e o esforço na integração das fontes de
dados.
23
3 Metodologia ETLEsta tese de mestrado inseriu-se num projecto a decorrer na Link Consulting [24] de nome CCDM - Call
Center Data Mart. Este projecto tem como objectivo a criação de um sistema de business intelligence
que sirva as necessidades de um call center. Este sistema pretende ser adaptável às mais várias
necessidades de cada call center, sendo genérico e modular o suficiente, para poder ser aplicado
na maioria dos call centers. Tendo sido desenvolvimento em torno do sistema Altitude [62], um dos
principais fornecedores de soluções para call centers, assegura-se que o sistema poderá ser facilmente
inserido na maior parte dos call centers existentes, sendo facilmente compatível com a maior parte do
software que estes usam.
A arquitectura do sistema onde esta tese se inseriu é a de uma arquitectura típica de BI, composta
pelos seguintes componentes:
1. Fontes de Dados - dados provenientes dos sistemas legados do call center ;
2. Processos de ETL - conjunto de Extracções, Transformações e Carregamentos, efectuadas sobre
os dados de origem;
3. Modelo Multidimensional - modelo onde os dados tratados nos processos de ETL vão ser arma-
zenados, segundo uma estrutura previamente definida (tabelas de factos e dimensões);
4. Cubo OLAP - cubo resultante do modelo dimensional, que agrega os dados existentes neste
modelo, segundo um conjunto de dimensões e métricas;
5. Dashboards - conjunto de dashboards criados a partir do Cubo OLAP anteriormente definido;
6. Utilizadores - os utilizadores que vão fazer uso dos Dashboards nos seus processos de tomada
de decisão.
O foco desta tese foi na melhoria dos pontos 2 e na construção dos pontos 3 e 4.
A Figura 3.1 mostra a arquitectura do sistema de BI criado.
De forma a melhor compreender os processos de ETL, os restantes capítulos serão dedicados
a esta temática. Antes de serem disponibilizados os dados para a sua exploração e utilização pelo
sistema de BI para call centers, estes têm de sofrer um processo de ETL (Extracção, Transformação e
Carregamento).
Nesta metodologia, esquematizada na Figura 3.2, distinguem-se duas grandes etapas. Na primeira
etapa, denominada Difusão, os dados são extraídos das fontes ( nos Anexos, capítulo 7 podem ser
consultadas as fontes de dados do sistema) e são armazenados num conjunto de tabelas, cujo es-
quema reflecte a estrutura dos ficheiros de origem. A este conjunto de tabelas chama-se normalmente
Operational Data Store (ODS) ou Repositório de dados operacionais. A segunda etapa tem o nome
de Integração e divide-se em três fases. Na primeira fase, são criadas vistas (recorrendo a junções
das tabelas do ODS) com o objectivo de integrar os dados origem de modo a facilitar a sua posterior
manipulação. Na segunda fase são efectuados os cálculos e agrupamentos sobre as vistas criadas
anteriormente. O resultado desta segunda fase é um conjunto de vistas que reflectem a estrutura do
modelo multidimensional. Na terceira fase, as vistas criadas são executadas de modo a inserir os regis-
tos no modelo multidimensional. Paralelamente, para controlar os mecanismos de Difusão e Integração,
são usados sistemas de controlo de forma a registar quaisquer anomalias durante as duas etapas e
25
Figura 3.1: Arquitectura do sistema CCDM
para registar quando as difusões e integrações foram efectuadas. A Figura 3.3 representa com maior
pormenor as 3 fases da etapa de Integração.
As próximas secções vão detalhar as diferentes fases da metodologia ETL. De forma a facilitar a
explicação e demonstração de exemplos, consideramos como exemplo de trabalho um dos modelos em
estrela do projecto de BI. Este modelo está centrado na tabela de factos F_Times_uCI e encontra-se
representado na Figura 3.4
Este modelo em estrela da Figura 3.4 além da tabela de factos F_Times_uCI, é composto pelas se-
guintes oito tabelas de dimensões: D_Agents, D_CallCenters, D_Clients, D_Supervisors, D_Teamleaders,
26
Figura 3.2: Metodologia do processo de ETL seguida
Figura 3.3: Fases da etapa de Integração
D_Times, D_Dates e D_Campaigns (ver secção 4.2). A tabela de factos F_Times_uCI contém medidas
sobre os vários tempos referentes às chamadas efectuadas no call center. As medidas armazenadas
são:
• TotalCallTime, que representa o tempo total das chamadas;
• TotalTalkTime, que representa o tempo total de conversação;
• TotalHoldTime, que representa o tempo total de espera do cliente durante a chamada;
• TotalWrapUpTime, que representa o tempo total que o agente levou a efectuar operações após
ter terminado a chamada;
• TotalWaitTime, que representa o tempo total na fila de espera;
• TotalWaitTimeOfReceived, que representa o tempo total em fila de espera das chamadas atendi-
das;
• Received, que representa o número de chamadas recebidas.
27
Figura 3.4: Subconjunto do modelo multidimensional da DW, que corresponde à estrela da tabela de factos
F_Times_uCI.
3.1 Difusão
Na fase da difusão, os dados dos sistemas fonte são canalizados para a ODS. Aqui, eles são colocados
em tabelas, que reflectem a estrutura dos objectos das fontes de dados de origem. Às tabelas onde os
dados dos sistemas fonte vão ser armazenados, adiciona-se depois um campo extra, o DiffusionID, que
vai desempenhar o papel de marcador da difusão dos dados. Este campo vai suportar os mecanismos
de controlo sobre a etapa de difusão.
Exemplo 3.1.1 Existe uma tabela de nome uCI_e_user que vai conter os dados provenientes do fi-
cheiro e_user do sistema uCI (que por sua vez provêm de uma tabela com nome homólogo do mesmo
sistema), cujo esquema está representado na secção 7.2. No ODS a principal alteração é a adição de
28
um campo adicional DiffusionID que vai servir como marcador da data em que a difusão foi feita e que
será usado em controlos posteriores.
Durante a extracção de dados, não é efectuada qualquer tipo de validação, remetendo-se estas
operações para fases posteriores. As chaves primárias e restrições que existem nos sistemas fonte,
embora conceptualmente sejam consideradas, não vão ser validadas nem colocadas implicitamente
nas tabelas do ODS. Estas chaves e restrições vão apenas servir como guia para as integrações que
vão ocorrer na próxima etapa (Integração), e na prática, não estarão presentes nas tabelas criadas
durante a difusão. É durante a Integração que se vão validar as restrições existentes entre as tabelas,
evitando-se assim que se realizem duas fases de verificações, durante a Difusão e, posteriormente
durante a Integração.
3.1.1 Estrutura de dados de Controlo na Difusão
De forma a implementar os mecanismos de controlo das difusões são utilizadas duas tabelas adicionais:
CTRL_Diffusions e CTRL_SourceData . A Figura 3.5 mostra a estrutura destas tabelas.
A tabela CTRL_Diffusions regista para cada uma das difusões efectuadas sobre as tabelas existen-
tes (na Figura 3.6 pode-se ver um dos tuplos desta tabela) os seguintes campos:
• DiffusionID - o ID de difusão das tabelas difundidas, que corresponde a um número único que
identifica uma dada difusão. Por exemplo, suponha-se que se vão realizar duas difusões sobre
ficheiros que contêm dados sobre os utilizadores do sistema CCDM, ou seja o ficheiro e_user. Ao
efectuar a primeira difusão sobre o ficheiro e_user, vai ser atribuído aos dados daí resultantes,
um identificador único na tabela uCI_e_user do ODS. Ao efectuar a segunda difusão sobre outro
ficheiro e_user, o DiffusionID atribuído a estes dados vai ser diferente do da primeira difusão.
Neste caso a tabela uCI_e_user do ODS vai conter dados referentes a duas difusões, algo que
pode ser visível através da observação do campo DiffusionID da tabela, que vai conter o número
atribuído aquando da realização da difusão.
• SourceID - o identificador da tabela que foi difundida, que consiste numa chave estrangeira para
a tabela CTRL_SourceData;
• DiffusionDate - a data a que os dados da tabela se referem. Caso essa data não exista este
campo não é preenchido. Por exemplo se o ficheiro diz respeito a dados do dia 01-02-2008, então
esta data será a data que representa a data de difusão, isto é a data em que os dados foram
gerados nos seus sistemas fonte.
• StartDate e EndDate - A data de inicio e fim da difusão respectivamente.
• Status - o Estado da difusão, que indica se a difusão teve sucesso ou não.
• DiffusedRows - o número de linhas que foram difundidas.
• IntegrationData - a data em que a tabela foi usada numa integração.
• Error - a indicação se ocorreu algum erro ou não (0 se não ocorreu erro e 1 se ocorreu algum
erro).
A tabela CTRL_SourceData possui os seguintes campos:
29
• SourceDataID - identificador único, que vai ser usado para identificar as tabelas do ODS.
• Source - nome do ficheiro usado na difusão para uma dada tabela do ODS.
• Data - nome das tabelas do ODS que vão conter os dados difundidos.
• Description - descrição dos dados das tabelas do ODS.
Na Figura 3.6, encontra-se representado um tuplo da tabela CTRL_Diffusions que diz respeito à
fonte de dados com identificador 10 (SourceID).
Figura 3.5: Estrutura das tabelas de controlo usadas na Difusão
Figura 3.6: Tuplo da tabela CTRL_Diffusions.
O conteúdo das tabelas de controlo da difusão pode ser usado para interrogações, de modo a iden-
tificar a existência de erros ou para elaborar relatórios para manter o histórico das difusões realizadas.
A secção 3.3 representa em maior detalhe os relatórios criados.
3.2 Integração
Uma vez difundidos os dados das tabelas fonte para o ODS, estes ficam disponíveis para serem inte-
grados. Na etapa de Integração os dados sofrem as transformações necessárias, tais como cálculos
e junções de várias tabelas, de modo a poderem popular as tabelas do modelo multidimensional. Tal
como indicado na Figura 3.3, existem três grandes fases na Integração:
1. Junção dos campos das tabelas do ODS, que vai ser abordada na secção 3.2.1;
2. Agrupamentos e Cálculos sobre as junções anteriormente efectuadas, que vai ser descrita na
secção 3.2.2;
3. Carregamento dos dados no modelo multidimensional, que vai ser abordada na secção 3.2.3.
Tal como acontece na difusão, quando uma dada tabela é integrada ela vai possuir um identificador
único, o IntegrationID, que permite o controlo de todas as integrações feitas.
30
3.2.1 1a Fase - Junções dos campos das tabelas do ODS em vistas
Esta fase consiste em construir uma vista única, para juntar o conteúdo das várias tabelas do ODS
de modo a conseguir popular o modelo multidimensional. Assim, nesta fase não é realizada qualquer
grande correcção ao valor dos dados das várias tabelas, sendo estas correcções feitas em fases pos-
teriores. Nesta fase podem ser identificadas três tipos de operações principais:
1. Junções (Joins e Outer Joins);
2. Filtragem de valores;
3. Formatação de valores.
De forma a exemplificar melhor estas operações recorremos a uma das vistas criadas no sistema de-
senvolvido, a vista F_Times_uCI_V1 (o código da vista pode ser consultado no Anexo 9). Esta vista
destina-se a popular a tabela de factos referente aos tempos das chamadas provenientes do sistema
uCI, F_Times_uCI. A Figura 3.7 representa a interligação das várias tabelas do ODS cujo conteúdo
é necessário para popular a tabela F_Times_uCI. A Tabela 3.1 detalha as ligações entre cada par de
tabelas representada na Figura 3.7.
Figura 3.7: Interligação das várias fontes de dados usadas para criar a vista com todos os dados relevantes que
vão popular a tabela F_Times
Tabela 3.1: Ligação entre as tabelas que formam a vista F_Times_uCI_V1
31
3.2.1.1 Junções
Existem dois grandes tipos de Junções (Joins):
• Inner Joins;
• Outer Joins (e suas variantes, Full, Left e Right).
A operação de Inner Join é efectuada quando se pretende juntar o conteúdo de duas tabelas T1 de
estrutura (A1,B1,C1) e T2 de estrutura (A2,B2,C2) pelo atributo A1 de T1 e A2 de T2, em que existe
uma relação de "um para um"entre A1 e A2. Ou seja, para cada valor A1 de T1, existe exactamente um
valor A2 de T2 que lhe corresponde. A expressão algébrica que traduz esta operação está representada
na Figura 3.8. A semântica desta expressão é a seguinte: pretende-se obter os valores B1,C1,B2 e C2
das tabelas T1 e T2 onde A1=B1.
Figura 3.8: Expressão algébrica que traduz um Inner Join.
No caso da vista F_Times_uCI_V1, um exemplo deste tipo de operação é a relação entre a tabela
uCI_Thread e a tabela uCI_data_context. A interligação destas tabelas é representada pela seguinte
expressão algébrica (Ver Figura 3.9):
Figura 3.9: Expressão algébrica que traduz um Inner Join entre as tabelas uCI_Thread e uCI_data_context
A semântica da expressão representada na Figura 3.9 é a seguinte: pretende-se os códigos de
todas as campanhas cujo campo data_context da tabela uCI_Thread é igual ao campo code da tabela
uCI_Data_Context.
A operação de Outer Join é efectuada quando se pretende juntar o conteúdo de duas tabelas T1 de
estrutura (A1,B1,C1) e T2 de estrutura (A2,B2,C2) pelo atributo A1 de T1 e A2 de T2, em que podem
existir tuplos de T1 cujos valores de A1 não correspondem a nenhum de A2 em T2 ou então a um ou
mais valores de A2 em T2. A expressão algébrica que traduz esta operação pode ser vista na Figura
3.10.
Figura 3.10: Expressão algébrica que traduz um Outer Join
A expressão algébrica que pode ser lida na Figura 3.10 (mais propriamente um Full Outer Join)
selecciona todos os campos das tabelas T1 e T2 mesmo que estes não tenham correspondência entre
os campos A1 e A2. Esta expressão pode ter ainda ainda duas outras variantes. Na Figura 3.11
mostra-se a expressão usando um Left Outer Join e na Figura 3.12 usando um Right Outer Join. Um
32
Left Outter Join significa que devem ser seleccionados todos os campos da tabela à esquerda da união
(neste caso a tabela T1), mesmo que estes não tenham correspondência com valores da tabela à
direita (T2) através dos campos A1 e A2. Um Right Outer Join, de forma similar, significa que devem
ser seleccionados todos os campos da tabela à direita, mesmo que não exista correspondência com os
campos da tabela à esquerda.
Figura 3.11: Expressão algébrica que traduz um Left Outer Join
Figura 3.12: Expressão algébrica que traduz um Right Outer Join
Um exemplo de um Outer Join aplicado à vista F_Times_uCI_V1 é o da relação existente entre
as tabelas uCI_segment e uCI_thread. Uma thread é uma interacção (de dados ou telefónica) e um
segment é uma parte desta interacção. Desse modo, a cada tuplo de uCI_thread corresponde um
ou mais tuplos de uCI_segment. A expressão de álgebra relacional que traduz esta operação é a
representada na Figura 3.13.
Figura 3.13: Expressão algébrica que traduz um Outer Join entre as tabelas uCI_thread e uCI_segment da vista
F_Times_uCI_V1.
3.2.1.2 Filtragem de valores
Ao efectuar a junção das várias tabelas fonte, podem logo ser realizadas algumas filtragens, omitindo
valores de atributos. Estes valores omitidos referem-se a situações que não têm qualquer interesse
para fases posteriores da etapa de Integração. Por exemplo, na tabela de factos F_Times_UCI não
têm qualquer interesse os registos que correspondem a tuplos da tabela uCI_segment onde os nomes
dos utilizadores (usr_name) não estejam preenchidos. Estes registos não vão ter relevância para as
etapas posteriores da Integração, visto nestes casos ser impossível associar um utilizador a uma dada
interacção. Este filtro que se aplica à vista F_Times_UCI_V1 pode ser descrito pela expressão presente
na Figura 3.14.
É importante salientar que estas filtragens são todas efectuadas sobre as vistas construídas, ao
invés de se fazerem directamente sobre as tabelas fonte. Esta situação acontece por duas razões: (i)
por uma questão de simplicidade, pois assim todas as filtragens sobre uma vista são feitas num só
sítio e (ii) permite que se contemplem situações de filtragem mais complexas (por exemplo, ter de filtrar
sobre dois valores em simultâneo, de duas tabelas diferentes).
33
Figura 3.14: Filtro aplicado à vista F_Times_UCI_V1 para retirar desta vista os campos cujo nome de utilizador
(usr_name) é nulo.
3.2.1.3 Formatação de valores
Tal como já foi referido, na primeira etapa da fase de Integração, procura-se apenas integrar os valo-
res sem lhes aplicar qualquer tipo de cálculos. Contudo, quando estes cálculos são bastante simples,
essencialmente formatações de valores, por uma questão de simplicidade podem ser realizadas logo
nesta fase. No exemplo da construção da vista F_Times_uCI_V1, podem ser encontradas estas forma-
tações de valores. Por exemplo, o valor do campo duration da tabela uCI_segment integrante da vista
usada, que representa a duração de cada segmento, está representado em décimas de segundo. Os
cálculos que serão necessários realizar sobre este campo são efectuados quase sempre em segundos
(devido às regras de negócio impostas pelo call center ). Assim, o valor de duration de uCI_segment é
convertido para segundos na vista F_Times_uCI_V1 (o que equivale a uma simples divisão por 10). Por
exemplo no caso da passagem de décimas de segundos para segundos esta operação pode ser tra-
duzida pela expressão presente na Figura 3.15. Outro exemplo consiste na formatação das datas dos
segmentos. As datas costumam obedecer ao formato: ’2003/01/22 22:31:26’. Nos cálculos a realizar
posteriormente, é necessário separar os dias das horas. Na vista F_Times_uCI_V1, é então realizada
a separação de cada segmento da data em dois campos diferentes: ’2003/01/22 00:00:00’ e ’22:31:26’.
Figura 3.15: Formatação aplicada na vista F_Times_uCI_V1 para passar o campo duration de décimas de
segundo para segundos.
Um excerto do conteúdo da vista F_Times_uCI_V1 no final da 1a Fase (ver secção 3.2.1) de Integra-
ção, que consiste essencialmente na junção de tabelas do ODS, encontra-se exemplificado na Figura
3.16.
3.2.2 2a Fase - Agrupamentos e Cálculos
Nesta segunda fase da etapa de Integração vão ser efectuados os cálculos sobre a vista F_Times_uCI_V1,
anteriormente criada, de forma a produzir os tuplos que vão popular as tabelas do modelo multidimen-
sional. A vista resultante da aplicação destes cálculos tem o nome de F_Times_uCI_V2 (o código SQL
desta vista pode ser visto nos Anexos em 10). Estes cálculos consistem essencialmente numa suces-
são de condições e somas do tipo: se uma dada condição for verificada (por exemplo um valor ser igual
a zero) então procede-se à soma, contagem ou qualquer outra operação similar sobre os valores de
outro campo. Estes cálculos encontram-se representados na expressão da Figura 3.17.
Por exemplo, no caso da vista F_Times_uCI_V2, três dos valores que são necessários calcular são
34
Figura 3.16: Vista F_Times_uCI_V1 após a primeira fase da Integração.
Figura 3.17: Cálculos efectuados na segunda fase da etapa de Integração.
o tempo total de chamadas (TotalCallTime), o tempo total de conversação (TotalTalkTime) e o Tempo
Total de espera (TotalWaitTime). Para calcular estes valores um método simplificado pode ser descrito
pela expressão da Figura 3.18.
A necessidade de se seleccionarem campos adicionais como o agente e de agrupar os valores
obtidos segundo estes campos, decorre do facto de que as tabelas de factos se organizam deste modo,
ou seja, têm os seus valores agrupados por uma série de dimensões à qual a tabela de factos se liga.
Um exemplo da vista F_Times_uCI_V2 resultante da 2a Fase - Agrupamentos e Cálculos da etapa
de Integração encontra-se ilustrado na Figura 3.19.
35
Figura 3.18: Expressão de cálculo para obter os campos TotalCallTime, TotalTalkTime e TotalWaitTime da vista
F_Times_uCI_V2.
3.2.3 3a Fase - Carregamento dos dados nas tabelas do modelo multidimensional
Nesta fase, a vista F_Times_uCI_V2 é executada de modo a carregar as tabelas de factos da estrela
representada na Figura 3.4 da secção 3.
3.2.3.1 Carregamentos para as Tabelas de Factos
Nas tabelas de factos, o primeiro passo é a remoção de todos os registos que tenham uma data que
já esteja considerada nos novos dados que se vão integrar, isto garante assim que os dados das ta-
belas de factos são o mais actualizados possíveis. Adicionalmente, como estas tabelas, ao contrário
das tabelas de dimensões, têm chaves estrangeiras para várias tabelas, bem como os atributos destas
tabelas de factos são maioritariamente obtidos a partir de cálculos de vários campos (por exemplo, o
tempo total de chamada que é dado pelo tempo em conversação mais o tempo dispendido em opera-
ções após terminada a conversação), o seu carregamento é mais complexo comparativamente com o
que o que acontece com as tabelas de dimensões. No caso da tabela F_Times_UCI existem chaves es-
trangeiras para as seguintes tabelas de dimensões: D_Data, D_CallCenter, D_Cliente, D_Campanha,
D_Supervisor, D_Teamleader, D_Time e D_Agente. É assim necessário popular a tabela de factos não
só com os dados anteriormente calculados, mas também com estas referências (chaves estrangeiras).
Devido a ser preciso encontrar estas referências para as tabelas de dimensões, é necessário antes de
se carregarem os dados verificar se as referências que estão presentes nesses dados, são válidas face
às dimensões existentes. Assim verifica-se para cada uma das chaves estrangeiras se ela realmente
existe na tabela de dimensões e caso todas as chaves tenham referências válidas podem-se carregar
os dados na tabela de factos. Caso as referências não sejam válidas, os dados não vão ser carre-
gados na tabela de factos, e vão ser carregados em tabelas de erros. Estas tabelas de erros têm a
mesma estrutura que as tabelas de factos para onde os dados se destinavam, por exemplo a tabela de
factos F_Times_UCI vai ter uma tabela de erros de nome F_Times_UCI_Error, mas com três campos
36
Figura 3.19: Vista F_Times_uCI_V2 resultante da segunda fase da Integração.
adicionais: ErrorDescription, que se refere à descrição do erro ocorrido (por exemplo: valor da chave
estrangeira da Campanha não encontrada), ErrorDate, que se refere à data em que aconteceu o erro e
Corrected. O campo corrected existe caso se opte por manualmente corrigir o erro ocorrido, podendo
depois incluir estes dados nas vistas que vão popular as tabelas de factos numa nova iteração. O fluxo
de operações do Microsoft Integration Services 2005 [25] necessário para popular a tabela de factos
F_Times_uCI encontra-se representado na Figura 3.20.
No diagrama da Figura 3.20 podem-se identificar os seguintes passos:
1. Os dados das vista F_Times_uCI_V2 são extraídos;
2. Vai-se validar cada uma das referências para as tabelas de dimensões.
3. Caso a referência exista:
(a) Continuam-se a validar as restantes referências;
(b) Colocam-se os dados provenientes da vista F_Times_uCI_V2, na tabela de factos F_Times_uCI.
4. Caso a referência não exista:
(a) É assinalada a descrição do erro (por exemplo: Erro devido a falta de referência para a tabela
de dimensões D_Dates);
(b) Unem-se todos os tuplos onde aconteceram erros;
(c) Adiciona-se o campo que descreve que aconteceu um erro (campo Corrected, com o valor
0);
(d) Adiciona-se a data em que ocorreu o erro;
(e) Conta-se o número de erros ocorridos;
(f) Colocam-se os dados com erros na tabela F_Times_uCI_Error.
37
O esquema descrito na Figura 3.20 pode ser seguido para popular as restantes tabelas de factos,
alterando apenas as referências que devem ser encontradas nas várias tabelas de dimensões.
3.2.3.2 Carregamentos para as Tabelas de Dimensões
Neste tipo de tabelas, os carregamentos são directos a partir das tabelas criadas na segunda fase da
etapa de Integração (ver secção 3.2.2), não se recorrendo a qualquer tipo de cálculos adicionais. Pode-
se também recorrer directamente às fontes de dados provenientes da etapa de Difusão (ver secção 3.1)
caso não seja necessário qualquer tipo de integração, evitando-se assim a segunda etapa do processo
ETL (Integração).
Tome-se o exemplo da tabela da dimensão D_Campaigns, que contém informação relativa às cam-
panhas a decorrer no call center. Para popular esta tabela, basta mapear directamente o conteúdo
já existente da tabela uCI_campaigns, cuja estrutura é (diffusionId, code, shortname, fullname, cam-
paigntype, status, foreseen_start, foreseen_end, foreseen_calls, start_time, end_time), não sendo ne-
cessário qualquer tipo de integração.
Aquando da fase da Integração, é importante verificar se o tuplo que se pretende colocar na tabela
de dimensões já existe nesta e, caso isso aconteça, conferir os valores dos campos que diferem do
tuplo que se pretendia inserir; aqui, podemos deparar-nos com duas situações:
• se o campo se referir a um valor que pode ser mudado ao longo do tempo (Slowly Changing
Dimension), então este é actualizado;
• se o campo se referir a um valor que não pode ser modificado na tabela de dimensões, então
ignoramos esse tuplo que se pretendia inserir.
Considere-se a estrutura da tabela de dimensões D_Campaigns:CampaignID, CampaignNameUCI,