SUMÁRIO

1 INTRODUÇÃO...........................................................................................................6
1.1 OBJETIVO GERAL.................................................................................................6
1.2 OBJETIVOS ESPECÍFICOS...................................................................................6
1.3 JUSTIFICATIVA......................................................................................................7
1.4 METODOLOGIA......................................................................................................7
2 REFERENCIAL TEÓRICO.........................................................................................9
2.1 PADRÕES DE PROJETOS....................................................................................9
2.2 ELT: EXTRACTION, TRANSFORMATION AND LOAD.......................................12
2.2 FERRAMENTA BI: DOMO....................................................................................13
2.3 DATA WARE.........................................................................................................15
3 CRONOGRAMA DE DESENVOLVIMENTO...........................................................16
4 CUSTOS...................................................................................................................17
REFERENCIAS...........................................................................................................18
 5

1 INTRODUÇÃO

A era da produção e acumulação de dados deu lugar à era da integração de

dados (BRAZNIK; JONES, 2005). O desafio de extrair informações de grandes
quantidades de dados foi superado. As grandes quantidades de dados coletados
pela ciência e pelos negócios devem ser reunidas e integradas para que a extração
de informações e a descoberta de conhecimento sejam possíveis.
Um data warehouse é um sistema de apoio à decisão que vai desde a análise
dos resultados das consultas até grandes quantidades de dados empresariais
previamente agrupados para melhorar essas consultas. Inicialmente, esses dados
eram carregados de bancos de dados operacionais, mas como Brazhnik e Jones
(2005) veem, o objetivo atual é integrar todas as fontes de dados para descoberta de
conhecimento para apoiar a tomada de decisão.
Para construir um data warehouse, é necessário realizar um processo de
extração, transformação e carregamento (ETL), que é responsável por: a) extrair
dados de várias fontes (estruturadas tradicionalmente); b) limpar; c) customizar para
se adequar aos dados modelo d) dados a inserção real (VASSILIADIS, 2001).
Segundo Inmon (2002), esse processo é considerado um dos mais críticos na
criação de um data warehouse.
A Motivação se dá pelo tratamento é todo feito numa ferramenta de BI
chamada Domo, essa ferramenta tem a funcionalidade do ETL, porém não aguenta
processar essa quantidade de dados demora cerca de 1 dia para processar e com
uma nova arquitetura vamos otimizar o tempo caindo para algumas horas.

1.1 OBJETIVO GERAL

O presente trabalho tem o objetivo de montar uma arquitetura de dados para

um sistema de telemedicina, as palavras chaves são engenharia de dados e pipline
de dados.

1.2 OBJETIVOS ESPECÍFICOS

 Apresentar todo o fluxo de dados, o dado é gerado e cai num banco de dados
e começa o desenvolvimento da monografia
 6

 Mostrar como vamos extrair, tratar e carregar esses dados (ETL); juntamente
como vamos automatizar todo esse processo.
 Exibir que no ETL vamos utilizar linguagem python como ferramenta, nele
vamos extrair os dados do banco, vamos tratar os dados (normalização de
dados), cruzar os dados e carregar os dados para um Data warehouse e
depois disponibilizar esses dados em uma ferramenta de BI, PowerBi.
 No banco de dados terá diversas tabelas, tabela de usuário, tabela de
profissional, tabela de registro de atendimento, então precisamos fazer
cruzamento dos dados para pegar os dados dos profissionais e usuários e
juntar com as de atendimentos, isso que seria o cruzamento dos dados.

1.3 JUSTIFICATIVA

Grande parte das ferramentas no mercado projetadas para dar suporte ao

processo ETL não oferece uma maneira de ajudar a extrair padrões de informações
textuais. Por esse motivo, o uso de documentos não estruturados para auxiliar a
tomada de decisão é menos comum do que com os sistemas tradicionais de
business intelligence (TRUJILLO; SONG, 2008).
Existem vários estudos sobre a análise de dados não estruturados, mas
poucos desses estudos focam especificamente na etapa de transformação dos
dados para analisá-los. De fato, um dos maiores desafios dos processos ETL para
dados não estruturados é executar o mesmo processo utilizado para dados
estruturados até chegar ao DW (DAYAL, 2009).
A proposta de melhoria é utilizar airflow para extração, normalização e
processamento dos dados para gerar datamars que serão consumidas pela
ferramenta de BI(Domo), logo o processamento vai ficar mais ágil e resolvendo o
problema de demero no processamento dos dados. Com essas dificuldades, é
proposta uma extensão ao processo ETL atual para que dados não estruturados
possam ser considerados no mesmo processo. Com isso, é possível tratar esses
dados como dados estruturados.

1.4 METODOLOGIA
 7

O método utilizado para a confecção deste trabalho foi uma pesquisa para
revisão bibliográfica de caráter exploratório, com foco na montagem de uma
arquitetura de dados para um sistema de telemedicina, realizados em consultas em
acervos e artigos científicos do ano de 2000 à 2022.

Os critérios de inclusão são: Artigos publicados no idioma da Língua

Portuguesa e Língua inglesa; Artigos publicados entre os anos de 2000 a 2022;
Artigos que respondam à pergunta norteadora; Artigos disponíveis na integra.

Os critérios de exclusão são: Artigos que foram publicados fora do recorte

temporal elegido; Artigos publicados somente com resumo; Artigos que não
respondam à pergunta norteadora; Artigos duplicados.

Na terceira etapa, serão definidos os critérios a serem extraídos dos estudos,

selecionando e caracterizando o que será importante para esta pesquisa de acordo
com o tema abordado, reunindo estudos com informações claras e objetivas que
facilitaram o acesso a base de dados, e a escolhida foi é o MongoDB.
 8

2 REFERENCIAL TEÓRICO

O padrão de projeto descreve uma solução para determinado ambiente que

pode ser aplicada inúmeras vezes. Porém a utilização desse padrão nunca será da
mesma forma.

2.1 PADRÕES DE PROJETOS

O conceito de padrões de projetos não é recente, ele vem da década de 70

com a crise do software. Segundo Alexander (1979), um padrão pode ser
caracterizado como uma regra de três partes que expressa uma relação entre um
contexto, um problema e uma solução. Para projeto de software o contexto permite a
compreensão do ambiente em que o problema reside e qual solução poderia ser
apropriada nesse ambiente. Um conjunto de requisitos influencia como o problema
pode ser interpretado e como a solução pode ser efetivamente aplicada.
Segundo Coplien (2005), caracteriza um padrão de projeto eficaz como:
● Ele soluciona um problema;
● É um conceito comprovado;
● Uma solução não é óbvia;
● Descreve uma relação;
● Possui um componente humano significativo.
Os padrões de projeto podem ser divididos em padrões de criação, padrões
estruturais e padrões comportamentais.
Uma maneira de garantir e atribuir as características descritas acima a um
software é com a aplicação e a utilização de Design Patterns, ou Padrões de
Projetos, ou seja, usando formas e modelos para padronizar a estrutura e a
codificação do software, pois isso visa a garantir a aplicação de boas práticas da
Engenharia de Software, que estão incorporadas nos padrões de projetos.
A definição de padrão de projeto segundo Gamma et al. (2008) é:
Um padrão de projeto sistematicamente nomeia, motiva e explica um design
geral que endereça um problema recorrente de design em sistemas orientados a
objeto. Ele descreve o problema, a solução, quando aplicar a solução e suas
consequências. Ele também dá dicas de implementação e exemplos. A solução é
 9

um arranjo geral de objetos e classes que resolvem o problema. A solução é

customizada e implementada para resolver o problema em um contexto em
particular. (GAMMA et al, 2008, p. 333)
Sommerville (2007) afirma que a utilização de padrões de projetos possibilita
construir softwares e componentes que viabilizam a reutilização de forma eficiente,
pois padrões são uma descrição do problema com a essência da sua solução, o que
possibilita a reutilização dessa solução em diferentes sistemas, pois eles descrevem
a experiência e o conhecimento que foram acumulados em uma solução
comprovada para um problema em comum.
Os padrões de projeto tiveram sua origem com base nos padrões
identificados pelo arquiteto e matemático Christopher Alexander, que teve a ideia de
documentar os pontos em comum identificados em projetos de arquitetura e
urbanismo, que seriam utilizados posteriormente em novos projetos.
Alexander é considerado o criador dos primeiros conceitos de padrões de
projeto, o mesmo afirma que “cada padrão descreve um problema no nosso
ambiente e o cerne de sua solução, de tal forma que se possa usar essa solução
mais de um milhão de vezes, sem nunca fazê-lo da mesma maneira”.
(ALEXANDER, 1977 apud GAMMA et al., 2008).
Com base nos padrões de projetos arquitetônicos de Alexander, os autores
Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides propuseram, no início
da década 1990, o conceito de padrões de projetos para a área de software com a
publicação do livro Design Patterns: Elements of Reusable Object-Oriented
Software. Devido ao amplo reconhecimento obtido com a publicação desse livro,
esses autores passaram a ser reconhecidos como a “Gangue dos Quatro” (GoF),
sendo que esse livro é, até hoje, a principal referência sobre o assunto.
A obra publicada pela Gangue dos Quatro teve como objetivo, além de
introduzir o conceito de padrões de projetos, descrever uma estrutura para catalogar
um total de 23 padrões. Um ponto importante é que os autores não são
responsáveis pela criação desses padrões, eles apenas documentaram padrões que
foram identificados por eles.
Gamma et al. (2008) estabeleceu um formato para descrever e documentar
um padrão de projeto, no qual deve ser descrito, em um esquema, um conjunto de
elementos essenciais:
 10

● O nome: Um padrão deve ter um nome a fim de identificá-lo, o que

facilita nas discussões e trocas entre programadores;
● O problema: é a motivação do padrão, deve ter uma descrição da
situação e do contexto no qual o padrão é aplicado;
● A solução: é a estrutura do padrão,
envolve um número de classes e descreve as relações
entre as suas instâncias, responsabilidades e colaborações. Define
como resolver o problema.
● As consequências: resultados da análise das
vantagens e desvantagens da aplicação do padrão, assim como as
determinadas circunstâncias em que pode ser aplicado.
Fowler (2003) afirma que “Um padrão é uma ideia útil em um contexto prático
e que provavelmente será útil em outro”. Afinal, um padrão não é um algoritmo ou a
implementação de um código que resolve um determinado problema, mas sim uma
descrição abstrata de uma solução para resolver um determinado problema, no qual
foi identificado o que se repete em diversas situações, sendo que essa solução pode
ser utilizada várias vezes e de maneiras diferentes.
Os padrões de projeto devem ser vistos como uma forma de trazer clareza
para um software, pois, com eles, consegue-se ter uma ideia de o que o software
está fazendo e não apenas uma descrição dos detalhes do código. Outro ponto
importante é que a aplicação deles permite melhorar o software, porque promovem a
extensibilidade e a reusabilidade, além de serem altamente estruturados, estando
documentados em um modelo que identifica o que é necessário para entender o
problema e a sua solução. (SHALLOWAY e TROTT, 2004).
De acordo com Shalloway e Trott (2004) os padrões de projeto têm como
princípio a reutilização de idéias que foram bem sucedidas, aproveitando não
apenas o código, mas também a experiência adquirida, resultando numa solução
confiável, mais robusta, reduzindo a complexidade e simplificando a manutenção.
Os padrões também auxiliam a estabelecer um vocabulário em comum entre
os desenvolvedores, melhorando a comunicação, a documentação e o aprendizado
deles, além de servir como um referencial que pode ser seguido. E, ainda, fornece
uma perspectiva de mais alto nível do problema e do processo, sendo que aplicam
os conceitos básicos da orientação a objetos como encapsulamento, herança e
 11

polimorfismo, o que melhora a capacidade de modificações no código fonte,

tornando-o mais elegante, estruturado e consequentemente mais simplificado.
Pressman (2010) afirma que a utilização e aplicação de padrões de projeto,
auxiliam na obtenção da qualidade de um software, contribuindo não só para a
redução dos custos de manutenção envolvidos, como também na diminuição do
tempo de aprendizado de novas bibliotecas ou funções pela equipe, com soluções
mais simples e mais flexíveis, sem grandes complexidades, numa linguagem de alto
nível.
A fim de melhorar o entendimento dos padrões de projeto, os autores buscam
classificá-los e dividi-los em famílias de acordo com a relação e características que
cada padrão possui, uma forma de torná-los mais organizados.
Dentre os diversos autores que estudaram os padrões de projetos, o presente
trabalho fará referência aos padrões de projeto documentados e catalogados por
Gamma et al. (2008), que catalogou um total de 23 padrões no livro intitulado Design
Patterns: Elements of Reusable Object-Oriented Software, em conjunto com os 51
padrões catalogados por Martin Fowler (2003), no livro intitulado Patterns of
enterprise application architecture.

2.2 ELT: EXTRACTION, TRANSFORMATION AND LOAD

De acordo com Inmon, Strauss e Neushloss (2007), extrair, transformar e

carregar (ETL) são as três etapas na construção de um DW. Os processos de ETL
devem coletar dados de vários aplicativos legados e transformá-los para que
possam trabalhar de forma integrada. O maior problema é que esses dados
geralmente não são projetados para trabalhar juntos devido a diferenças na
estrutura, formato, computação, definição de dados e outras diferenças semânticas.
De acordo com Kimball (2004), todo sistema ETL deve armazenar dados de
várias maneiras, seja de forma permanente ou semi-permanente, por isso esses
sistemas são frequentemente chamados de áreas de teste. Em muitos projetos de
ETL, você precisa escolher como fazer essa área de teste. A grande questão é se os
dados devem ser armazenados em disco ou na memória. As duas questões mais
importantes que definem o equilíbrio entre essas duas opções são: levar os dados
da origem ao destino final o mais rápido possível; e ter a possibilidade de recuperar
os dados em caso de falha sem reiniciar o processo do zero.
 12

Uma ferramenta que permite a integração de dados de diferentes fontes de

informação, extraindo, transformando e carregando os dados em outros sistemas,
geralmente dedicados à análise de dados. Essas ferramentas, conhecidas como a
sigla Extraction Transform Load (ETL), são capazes de se comunicar com bancos de
dados, ler diferentes formatos de arquivos usados em toda a organização e
gerenciar dados suportando diferentes processos relacionados, desde qualidade de
dados até qualidade de dados. (VASSÍLIADIS, 2009).
Em outro trabalho relacionado ao fluxo de trabalho (do inglês, workflow, WF),
Zhang et al. (2018) consideram otimizar a análise de dados em provedores de
nuvem, por meio do sistema de fluxo de trabalho como serviço, construção dinâmica
e execução de análise de dados inteligente, desenvolvimento rápido e
implementação flexível de processos de análise de negócios, o que pode melhorar a
interação do processo e o tempo de resposta.
Para esclarecer este sistema, são apresentados diagramas de arquitetura e
modelagem de diferentes fluxos de trabalho no contexto de técnicas analíticas e
computação em nuvem. No contexto da análise de dados, os fluxos de trabalho ETL
são especificados para extrair, transformar e executar dados e dar suporte a
abordagens híbridas, assíncronas e síncronas.

2.2 FERRAMENTA BI: DOMO

Business Intelligence (BI) ou Inteligência de Negócios é um conjunto de

ferramentas que apoiam a tomada de decisão da alta administração em empresas
de diversos portes e setores, como clínicas. A utilização da IB na saúde visa reduzir
custos sem comprometer a qualidade da assistência (ARAÚJO, 2020).
O termo foi cunhado por Richard Millar Devens em 1865 para descrever como
os banqueiros lucram antes da concorrência com base nas informações recuperadas
no ambiente de negócios (ARAÚJO, 2020).
O conceito de business intelligence não para por aí, um ambiente dessa
natureza permitirá que os usuários de negócios realizem explorações analíticas e
gerenciais para melhorar e otimizar o processo de tomada de decisão. O principal
objetivo da criação de um ambiente de business intelligence ou inteligência analítica
é criar uma infraestrutura técnica que possa atender às necessidades de negócios
de uma empresa. Entende-se que a direção do desenvolvimento de um ambiente de
 13

BI deve vir sempre do domínio do negócio, o que requer uma visão e contexto
relacionados aos temas que contribuem para o processo decisório (PINHEIRO,
2008).
Independentemente do tamanho de uma organização, as ferramentas de BI
ajudam a pesquisar e interpretar os dados armazenados em tempo real. Isso é
importante não apenas para o suporte à decisão, mas também para medir a
produtividade, avaliar, controlar e gerenciar diferentes ações (ARAÚJO, 2020).
Ao garantir o controle e a qualidade das informações, o BI tornou-se um
grande atrativo no setor da saúde, pois pode reduzir custos mantendo a qualidade
do atendimento. Algumas das principais vantagens de seu uso são: análise
inteligente de dados, a partir de filtros, que permitem análise rápida de processos e
monitoramento de desempenho, redução de custos proporciona insights sobre
eventos passados e previsões futuras além do uso de certificados digitais,
eliminando assim a demanda para impressão em papel, qualidade do atendimento e
gestão e acompanhamento de históricos de saúde do paciente, gerando relatórios e
métricas (ARAÚJO, 2020).
O BI, como qualquer projeto a ser implementado, tem suas etapas, que nem
sempre precisam ser seguidas à risca, mas facilitam o processo para que o modelo
de projeto possa ser utilizado por outras organizações ou em futuras
implementações. Em geral, a implementação de projetos de BI não difere de outros
projetos na forma como os requisitos são apresentados, mas possuem suas
peculiaridades. Com cada vez mais dados ao nosso alcance, fica cada vez mais
difícil focar em informações relevantes para nossos problemas e apresentá-las de
maneira acionável. É disso que se trata a inteligência de negócios (ALEX, s/d).
As ferramentas de BI tornam mais fácil coletar os dados corretos e visualizá-
los de uma maneira que nos permita entender seu significado. Mas o quão fácil o
processo se torna e como os dados são visualizados depende da ferramenta: torna-
se importante escolher a ferramenta certa para suas necessidades (OLAVSRUD,
SAYER, 2021).
Domo é uma plataforma baseada em nuvem focada em painéis e facilidade
de uso para implantações de usuários de negócios. Ele oferece ferramentas de
inteligência de negócios personalizadas para diferentes setores (como serviços
financeiros, saúde, manufatura e educação) e funções, incluindo CEOs, vendas,
profissionais de BI e trabalhadores de TI. Os CIOs podem começar vendo como ele
 14

lida com dados da AWS, Jira, GitHub ou New Relic antes de aprender como mais de
500 outras integrações podem ajudar outras empresas (OLAVSRUD, SAYER, 2021).
A decisão para estagiar os dados depende do ambiente e dos requisitos do
negócio. Todo Data Warehouse contém uma área de estagiamento de alguma
forma. Para decidir se isso será feito em memória ou em disco, deve-se considerar
as seguintes razões: recuperabilidade: em muitos sistemas, é uma boa prática
armazenar os dados assim que são colhidos da fonte e após cada uma das
transformações mais importante e confiável (ZORZO, 2009).
Dessa forma, se ocorrer um erro, você não precisará efetuar login no sistema
de origem novamente. Isso é especialmente importante para dados na rede, que
podem não estar mais disponíveis; backups: Muitas vezes, os data warehouses
contêm uma grande quantidade de dados, o que impossibilita o backup completo
confiável (ZORZO, 2009).
Após o arquivo carregado ser salvo, ele pode ser recuperado caso haja algum
problema no Data Warehouse; auditoria: salve os dados na área de staging, basta
comparar os dados de entrada e os dados de saída, fica mais fácil auditar o
processo ETL, levando em consideração as alterações no código ETL,
especialmente no caso de um data warehouse sobrescrevendo seus dados. Isso
torna cada vez mais difícil entender como os dados mudaram durante o processo de
ETL, o que pode torná-lo não confiável (ZORZO, 2009).

2.3 DATA WARE

Consoante Inmon (2002), um data warehouse é um banco de dados que

suporta a tomada de decisão e deve ser integrado, não volátil, variável no tempo e
organizado tematicamente. Um dos aspectos mais importantes do DW é a
granularidade, que se refere ao nível de detalhe ou agregação dos dados. Uma das
vantagens do DW é que os dados são armazenados em ordem cronológica,
produzindo um registro histórico de uma área de análise.
Talvez a parte mais complexa da criação de um DW seja a integração de
dados. O problema é que muitas organizações possuem sistemas legados que
utilizam dados apenas para fins operacionais. É necessário adaptar esses sistemas
para que possam fornecer uma visão integrada do negócio (INMON, 2002).