UNYLEYA

PÓS-GRADUAÇÃO LATO SENSU MBA EM DATA WAREHOUSE E

BUSINESS INTELLIGENCE

RINALDO DEMÉTRIO

PROCESSO DE TOMADA DE DECISÃO COM BUSINESS

INTELLIGENCE

Gravataí
2016

RINALDO DEMÉTRIO
PROCESSO DE TOMADA DE DECISÃO COM BUSINESS
INTELLIGENCE

Monografia apresentada à UNYLEYA Faculdade

Integrada como exigência parcial à obtenção do título
de Especialista em MBA em Data Warehouse e
Business Intelligence.

Nome do Orientador: Rômulo Monteiro Ferreira

Gravataí
2016
 UNYLEYA

PÓS-GRADUAÇÃO LATO SENSU MBA EM DATA WAREHOUSE E BUSINESS

INTELLIGENCE

RINALDO DEMÉTRIO

PROCESSO DE TOMADA DE DECISÃO COM BUSINESS INTELLIGENCE

APROVADO EM ____/____/____

BANCA EXAMINADORA

______________________________________________________________

RÔMULO MONTEIRO FERREIRA – ORIENTADOR E PRESIDENTE DA BANCA

______________________________________________________________

NOME DO PROFESSOR – EXAMINADOR

______________________________________________________________

NOME DO PROFESSOR – EXAMINADOR

 Resumo

Dados são o novo petróleo e como tal devem ser extraídos, refinados, tratados para
que possam gerar lucros, dividendos, resultados. Pode parecer um exagero, mas só deverá
permanecer no mercado a organização que der atenção especial as suas informações. Será
preciso profissionais capacitados e analíticos que possuam a capacidade de extrair das
informações as vantagens competitivas.
Esta monografia introduz o leitor no trabalho com dados para a futura tomada de
decisão. Cada vez mais as empresas estão dando guinadas para a inteligência dos negócios
buscando soluções que as diferenciem da concorrência.
Indiscutivelmente um banco de dados se bem administrado por um profissional
competente poderá agregar valor à empresa gerando maiores lucros e ganhos de
produtividade.
Diversos projetos de análises de bases de dados com vistas a gerar ganhos maiores às
empresas envolvidas podem falhar devido à ausência de profissionais capacitados na área.
Sendo o assunto inteligência dos negócios de vital importância para os dias de hoje é
fundamental que em qualquer organização tenha em seus quadros profissionais com alta
capacidade analítica sejam eles analistas ou não. O autor espera que o texto desperte nos
profissionais a vontade e a capacidade de se desenvolver nesta área tão apaixonante.

Palavras-chave: modelagem de dados relacional, dimensional, banco de dados,

Business Intelligence, inteligência dos negócios, inteligência competitiva, Data Warehouse,
tomada de decisão.
 Abstract

Data is the new oil and as such should be extracted, refined, processed so they can
generate profits, dividends, results. It may seem an exaggeration, but it should only remain in
the market organization that gives special attention to your information. You will need skilled
and analytical professionals who have the ability to extract information from the competitive
advantages.
This paper introduces the reader to work with data for future decision making. More
and more companies are giving lurches to Business Intelligence seeking solutions that
differentiate from the competition.
Arguably a database is well run by a competent professional can add value to the
company generating higher profits and productivity gains.
Several projects database analysis in order to generate greater gains to the companies
involved may fail due to lack of trained professionals in the area.
Being the subject of intelligence vital to business today is critical that any organization
has on their staff with high analytical capacity whether or not analysts. The author hopes that
the text arouse in professional will and the ability to develop this area so exciting.

Keywords: modeling relational data dimensional database, Business Intelligence,

Business Intelligence, competitive intelligence, data warehousing, decision making.
Índice de ilustrações
Figura 1 Representação de banco de dados.........................................................................................21

Figura 2 relacionamento.......................................................................................................................24

Figura 3 tabela de fatos - Fonte: (ZAIDAN, 2016)..................................................................................39

Figura 4 Modelo Snow flake – Fonte: (ZAIDAN, 2016)..........................................................................40

Figura 5 – Métricas – Fonte: (SERPA, 2015)..........................................................................................40

Figura 6 - Tabela fato (FILHO, 2012)......................................................................................................41

Figura 7 - Cubo com 3 dimensões Fonte: (ZAIDAN, 2016)....................................................................42

Figura 8 - Gráfico demonstrativo da tabela - Fonte: do autor...............................................................47

Figura 9 - Gráfico meramente ilustrativo - Fonte: do autor..................................................................47

Figura 10 Gráfico de correlação - Fonte: (VIGEN, 2014)........................................................................48

Figura 11 Histograma - Fonte: do autor................................................................................................49

Figura 12 Histograma de aumentos - Fonte: (MILTON, 2010)...............................................................50

Figura 13 Gráfico de dispersão - Fonte: (MILTON, 2010)......................................................................50

Figura 14 curtidas por categoria - Fonte: do autor...............................................................................51

Figura 15 Curtidas por hora - Fonte: do autor......................................................................................52

Figura 16 curtidas por dia da semana - Fonte: do autor.......................................................................52

Figura 17 Nuvem de palavras - Fonte: do autor....................................................................................52

Índice de tabelas

Tabela 1 Clientes Fonte: Machado (2008, p. 42)...................................................................................25

Tabela 2 Funcionário (parcial). Fonte: Machado (2008, p. 62)..............................................................27

Tabela 3 Departamento (parcial). Fonte: Machado (2008, p.62)..........................................................27

Tabela 4 Fonte: Beighley (2008, p. 142)................................................................................................31

Tabela 5 Professores e disciplinas. Fonte: do Autor..............................................................................31

Tabela 6 Fonte: (MACHADO, 2008, p. 182)...........................................................................................32

Tabela 7 Super-heróis (parcial). Fonte: (BEIGHLEY, 2008, p. 261).........................................................34

Tabela 8 Fonte: (TONSIG, 2006, p. 41)..................................................................................................35

Tabela 9 Fonte: (TONSIG, 2006, p. 42)..................................................................................................35

Tabela 10 – Fonte (ZAIDAN, 2016)........................................................................................................38

Tabela 11 Fonte (ZAIDAN, 2016)...........................................................................................................38

Tabela 12 - Fonte: do autor..................................................................................................................44

Tabela 13 - Idade x percentual de gordura - Fonte: do autor................................................................47

Sumário

CAPÍTULO 1 – O PORQUÊ DO BI........................................................................................10

1.1. Introdução...................................................................................................................10
1.2. Objetivos....................................................................................................................10
1.2.1. Geral.......................................................................................................................10
1.2.2. Específico...............................................................................................................10
1.3. Justificativa.................................................................................................................10
1.3.1. Pessoal....................................................................................................................10
1.3.2. Geral.......................................................................................................................11
1.4. Revisão de literatura...................................................................................................11
1.5. Metodologia...............................................................................................................12
CAPÍTULO 2 - A INTELIGÊNCIA DOS NEGÓCIOS...........................................................13
2.1. Businnes Intelligence.................................................................................................13
2.2. O caso da Toyota........................................................................................................14
CAPÍTULO 3 - DADOS RELACIONAIS...............................................................................17
3.1. Banco de Dados..........................................................................................................17
3.2. Sistema de Gerenciamento de Banco de Dados.........................................................18
3.3. Modelo conceitual......................................................................................................18
3.4. Modelo Entidade - Relacionamento...........................................................................19
3.5. Entidade......................................................................................................................20
3.6. Relacionamento..........................................................................................................20
3.7. Modelo Relacional.....................................................................................................21
3.8. Valores nulos..............................................................................................................22
3.9. Chave primária...........................................................................................................23
3.10. Chave candidata ou alternativa...............................................................................23
3.11. Chave estrangeira...................................................................................................23
3.12. Restrições de Integridade........................................................................................24
3.13. Integridade de domínio...........................................................................................24
3.14. Integridade de vazio................................................................................................24
3.15. Integridade de chave...............................................................................................24
3.16. Integridade referencial............................................................................................25
 3.17. Normalização..........................................................................................................25
3.18. Dados atômicos.......................................................................................................26
3.19. Anomalias...............................................................................................................27
3.19.1. Anomalias de atualização.......................................................................................28
3.19.2. Anomalias de exclusão...........................................................................................29
3.19.3. Anomalias de inclusão............................................................................................29
3.20. Dependência funcional total...................................................................................29
3.21. Dependência funcional parcial...............................................................................30
3.22. Dependência funcional transitiva (transitória).......................................................31
3.23. Regras de normalização..........................................................................................32
3.24. Primeira Forma Normal – 1FN...............................................................................32
3.25. Segunda Forma Normal – 2FN...............................................................................32
3.26. Terceira forma Normal – 3FN................................................................................33
CAPÍTULO 4 - A TOMADA DE DECISÃO...........................................................................34
4.1. Dados demais.............................................................................................................34
4.2. Metodologias estatísticas para tomada de decisão.....................................................36
4.3. Correlação..................................................................................................................36
4.4. A tomada da decisão da Netflix..................................................................................38
4.5. Análise de regressão linear.........................................................................................38
4.6. Tomada de decisão sobre aumento de salário............................................................39
4.7. Análise de dados e tomada de decisão sobre dados do Facebook..............................41
4.8. Conteúdos mais vistos................................................................................................41
5. CONSIDERAÇÕES FINAIS.........................................................................................44
6. BIBLIOGRAFIA...........................................................................................................45
 10

CAPÍTULO 1 – O PORQUÊ DO BI
1.1. INTRODUÇÃO

Sem sombra de dúvida BI é um dos assuntos mais necessários em nossa atualidade,

mas ainda talvez pouco com compreendido. Business Intelligence aplica- se a qualquer área.
Enquanto muitos acham que é necessário aprofundar-se em tecnologias para trabalhar com BI
ignorando que este pode ser necessário em qualquer área: finanças, marketing, vendas, saúde,
etc.
Todas as empresas necessitam um ambiente que propicie a tomada de decisão: o que
comprar? O que vender? Qual nossa melhor filial? Possuir um sistema de suporte à decisão
evita que seus clientes tentem matar mosca com bala de canhão.
É possível ir mais longe: a empresa que não fizer uso de um ambiente de Business
Intelligence estará fadada a fechar ou diminuir.

1.2. OBJETIVOS

1.2.1. GERAL

A principal finalidade deste trabalho é mostrar os passos necessários para a criação de

um ambiente de tomada de decisão.

1.2.2. ESPECÍFICO

Descrever um ambiente de dados necessários à compreensão do ambiente decisório.

Apontar os passos necessários (modelagem de dados relacional e dimensional) para a
criação de um ambiente de tomada de decisão.
Demonstrar a criação do ambiente e consequente utilização com análise de dados
estatísticos.

1.3. JUSTIFICATIVA

1.3.1. PESSOAL

O autor considera-se um aficionado por análise de dados, durante sua graduação

estudou com muita dedicação as disciplinas que versavam sobre o assunto. Também o autor
conta com grande experiência na área pelo fato de ser professor na área de computação e
grande consumidor de literatura sobre estatística.
Com base em sua experiência considerou justo pesquisar sobre um assunto onde já
possui relativo domínio.
 11

1.3.2. GERAL

Ultimamente comenta-se com frequência que os dados são o novo petróleo.

O seguinte estudo vai procurar aprofundar-se no conceito de tomada de decisão
buscando padrões que talvez desconheçamos. Tem a pretensão de tornar-se uma fonte de
consulta para usuários que desejarem ter uma introdução sobre este amplo assunto. Pode este
estudo mostrar informações que deveriam ser levadas em conta quando da pretensão de
perpetuar um negócio.
O autor vai poder usar como fonte de sua pesquisa materiais e fontes de seu próprio
acervo, além de também buscar ajuda em sua própria experiência com o tema o que tornará a
pesquisa mais facilitada.

1.4. REVISÃO DE LITERATURA

O autor considera o tema Business Intelligence de extrema importância, mas ao

contrário do que se pode imaginar justamente quem mais necessita de uma intervenção nos
dados é justamente quem desconhece o poder que a análise de dados pode trazer para o meio
empresarial.
Acredita que uma empresa perde muitas oportunidades devido ao fato de possuir uma
grande quantidade de dados sem utilidade, os chamados cemitérios de dados. É possível fazer
uma entrevista com estes dados. Poderiam nortear as atitudes comerciais e de marketing.
Para isso o autor vai se sustentar em diversos autores especialistas nas mais diversas
áreas do conhecimento. Nate Silver, autor do livro O Sinal e o Ruído, conhecido estatístico
norte americano que construiu sua reputação fazendo previsões bem-sucedidas usando dados
e estatísticas em eventos nas mais diversas áreas. Esportes, política, clima.
Nate Silver afirma que é necessário reunir uma maior quantidade de dados sobre o
problema para que seja possível desenvolver maior discernimento para o planejamento futuro
reduzindo assim drasticamente a repetição de erros.
Um dos conceitos citados por Silver divide os analistas de dados em porcos-espinhos e
raposas. O analista porco-espinho prende-se a ideias concretadas não aceitando mudanças em
seu modelo original. Já a raposa incorpora os dados com base em diversas fontes para só
então tomar uma decisão. Exatamente como se comporta o mundo corporativo.
Silver alerta que a crise global de 2008 que levou milhares de americanos a perderem
suas casas e levou a bancarrota empresas financeiras centenárias, poderia ter sido evitada se
os sinais de perigo fossem levados a sério. Havia uma enxurrada de informações indicando a
iminente crise e estes dados poderiam ter sido esmiuçados e analisados.
 12

Thomas Davenport (autor do best seller Dados Demais) que trabalha especificamente
o desenvolvimento de habilidades analíticas para a solução de problemas complexos que
envolvam grande quantidade de dados.
Assim como Silver, Davenport vaticina que vivemos em um mundo inundado de
dados que se acumulam em uma velocidade espantosa. A IBM estima que são produzidos
diariamente 2,5 quintilhões de bytes de dados. Google processa cerca de 24 petabytes de
dados de Internet por dia. AT&T transfere em torno de 30 petabytes de voz e dados ao dia.
Davenport afirma que é necessário que estes dados sejam explorados com vistas a uma
melhor tomada de decisão ou a falta desta análise fará com que os gestores sejam pegos de
surpresa por reveses que poderiam ter sido previstos.
Davenport defende que todos, sem distinção, em uma organização (do porteiro ao
executivo de ponta) saibam usar a Analítica em maior ou menor grau. No lugar de confiar nos
instintos é necessário munir-se de dados para compreender melhor os resultados e usá-los para
melhorar o desempenho da organização.

Analítica significa o uso amplo de dados, de análise estatística e quantitativa, de

modelos explanatórios e preditivos e de gestão fatual para orientar decisões e
agregar valor. (DAVENPORT, 2014)

O autor também vai procurar auxílio em outros autores de reconhecida fama no

trabalho com banco de dados diversos.

1.5. METODOLOGIA

Metodologicamente, este trabalho adotará o tipo de pesquisa:

Pesquisa bibliográfica – será feito um levantamento da literatura relevante disponível
sobre o assunto.
Documentação direta – levantamento de dados nos sites específicos.
Pesquisa bibliográfica – será feito um levantamento dos periódicos do autor.
 13

CAPÍTULO 2 - A INTELIGÊNCIA DOS NEGÓCIOS

2.1. BUSINNES INTELLIGENCE

Sobre BI (Businnes Intelligence) alguns autores costumam dizer que não se trata de
tecnologia, mas sim de um conceito (PITON, 2016). Também chamado de inteligência nos
negócios o que o BI pode fazer por uma organização? De acordo com o IBGE, em junho de
2016 as vendas do comércio varejista acumularam uma queda de 7,3 %. Na comparação entre
maio/2015 e maio/2016 a queda nas vendas chega a um patamar de 9% de queda. Recentes
estatísticas sinalizam que as empresas que optaram por acrescentar business Intelligence em
suas operações arrebanharam ganhos entre 5% e 6% de produtividade e rentabilidade acima
de seus principais concorrentes (SANCHEZ, 2015).
Em momentos de crise como o que vivemos atualmente torna-se crucial conhecer seu
negócio. Saber onde estão as perdas e os ganhos podem tornar a empresa única entre seus
competidores. Ter um profundo conhecimento dos dados relacionados ao estoque, às vendas e
até quais perdas, podem fazer um diferencial na hora de destacar-se da concorrência.
Infelizmente, de acordo com observações do autor, o assunto ainda é tabu entre a
maioria das pequenas empresas. Em conversa informal o autor manteve contato com
proprietários de pequenos negócios, academias, escolas, comércios de alimentos, etc.
Seus gestores por não saberem do que se trata e quais benefícios o BI poderá trazer,
rechaçam quaisquer tentativas de aproximação de uma equipe de inteligência de negócios.
Alguns gestores temem a perda ou revelação de seus dados para os concorrentes (SOUSA,
2016). Ironia que talvez justamente estas empresas precisariam do benefício desta ação de TI.
Trabalhar com BI significa integrar fontes de dados de várias origens: planilhas,
arquivos de texto, variados bancos de dados, etc. De posse destas informações cria-se um
Data Warehouse também conhecido como armazém de dados que poderá ser usado para
criação dos cubos de informações. Estes cubos poderão informar quais produtos vendem mais
na empresa e fazer com que procure o porquê destes produtos venderem mais. A resposta
poderá ser usada para multiplicar as estratégias de vendas para outros produtos.
Um cubo pode permitir inferir qual a causa de determinado produto não vender para a
partir daí criar campanhas de promoção que façam este produto aumentar suas vendas.
Como trabalhar com BI não necessariamente precisa desta ou daquela tecnologia, de
uma simples planilha com informações de uma empresa tais como, vendas, clientes,
fornecedores é possível inferir diversas constatações. Tomar decisões com base nestas
informações significa em última instância não mostrar que a empresa deixou de vender uma
 14

quantidade maior de pizza por que faltou queijo ralado orégano, mas fazer até uma análise
preditiva e mostrar com antecedência que este revés poderia acontecer.
Para uma empresa que atua no mercado financeiro pode ser muito importante
antecipar quais clientes poderiam contrair determinado valor de empréstimo e aumentar a
base de vendas ou ainda descobrir quais possíveis fraudes podem ser perpetradas se não for
aumentada a segurança das informações.

2.2. O CASO DA TOYOTA

A Toyota Motor Sales (TEIXEIRA, 2015) em determinada ocasião descobriu que

gastava em média cerca de U$ 8,00 por dia para transporte de um de seus automóveis para os
revendedores nos Estados Unidos. Como os veículos ficavam em trânsito entre 9 e 10 dias, a
despesa ficava em torno de até U$ 80,00 por unidade. Dois milhões de carros transportados
por ano dava um custo de até 160 milhões de dólares. Um valor extremamente alto.
Ao final dos anos 90 a empresa enfrentava problemas de transporte e armazenamento
o que fez com que perdesse mercado para seus concorrentes. Sob o comando de uma nova
CIO a empresa implementou um Data Warehouse que permitiu a criação de cubos de consulta
e demonstração dos dados através de dashboards. Como resultado a empresa reduziu seus
custos e conseguiu aumentar o volume de carros negociados em até 40%.
A solução de business Intelligence foi capaz de mostrar em tempo real o que os
gestores não estavam vendo, onde a cadeia de fornecimento apresentava custos exorbitantes.
De posse das informações a direção da empresa foi capaz de tomar decisões que recolocaram
a empresa de volta aos trilhos.
Se por um lado a Toyota soube aproveitar as informações e seus tomadores de decisão
tomaram as medidas que culminaram em maior competitividade da empresa, o mesmo não se
pode dizer no caso mais famoso que se tem notícia envolvendo mineração de dados (data
mining). O Professor Thomas Davenport (DAVENPORT, 2014) relata em seu livro Dados
Demais o caso que ficou conhecido como Cerveja e Fraldas. Praticamente o caso mais citado
como exemplo quando o assunto data mining é introduzido.
Fazendo uso de uma técnica denominada identificação de padrões, foi constatado, em
Chicago no ano de 1992 que homens que entravam em mercearias nos fins de semana tinham
a tendência a comprar fraldas juntamente com cerveja.
Trabalho desenvolvido pela empresa Teradata para o cliente Osco Drug, tinha como
objetivo analisar os dados de pontos de venda a procura de afinidades entre os itens
comprados em uma mesma loja. Com base na descoberta de pares de itens que eram vendidos
 15

em conjunto (na mesma cesta) a ideia deveria sugerir uma rearrumação de mercadorias nas
lojas para saber como as vendas seriam afetadas. Como exemplo didático o arroz poderia ficar
junto do feijão e o refrigerante junto do salgadinho se estes itens fossem comprovadamente
vendidos em conjunto.
No início apenas tinha-se a certeza de que itens específicos para bebês erram muito
lucrativos (fraldas inclusas). Seria necessário descobrir quais itens poderiam ser vendidos em
conjunto ou ainda levar a compra dos itens infantis. O trabalho examinou cerca de 1,2 milhão
de cestas de mercado que foram extraídos de um total de 25 lojas e apesar dos relatos
apócrifos afirmarem o contrário a Teradata descobriu que na verdade um grande número de
clientes (não foram identificados como homens) compareciam as lojas entre as 17 e 19 horas
das quintas-feiras e sábados para comprar cerveja e fraldas com frequência acima do normal.
Esperava-se que de posse destas valiosas informações as fraldas e as cervejas fossem
colocadas lado a lado para facilitar ou induzir a venda, mas para total estranheza nada foi feito
com estes dados. De certa forma a direção da Osco Drugs achou a descoberta divertida, mas
não tomou nenhuma atitude com relação a esta.
O que prova que examinando os dados é possível fazer descobertas valiosas, mas que
de nada servirão se não houver uma pessoa disposta a tomar decisões.
Apenas possuir e armazenar os dados não é suficiente, é preciso saber o que fazer com
eles. Uma análise dados com métodos estatísticos que por vezes é subutilizada é a correlação
ou coeficiente de correlação. O Professor Charles (WHEELAN, 2016) cita o caso da Netflix.
Como a Netflix sabe que o usuário iria gostar de determinado filme ou série? A empresa não
conhece o usuário nem tampouco tem uma grande quantidade de estagiários pesquisando
sobre sua vida e seus gostos de filmes. Muito menos a Netflix encarregaria espiões e
entrevistadores para conhecer a família do usuário desde que estes dessem pistas sobre seus
anseios cinematográficos.
Usando coeficientes de correlação a empresa recomenda filmes que são semelhantes a
filmes dos quais o usuário já gostou e avaliou, informando a empresa. Cruza estas
informações com recomendações de usuários que também deram avaliações similares.
Desta forma correlação faz a medição do grau no qual dois fenômenos mantém uma
relação mútua. Como no caso famoso da correlação positiva entre venda de sorvete e aumento
da temperatura. Se sobem os termômetros a venda aumenta. Produtos que possuem correlação
positiva poderiam ser oferecidos em conjunto ou no mesmo local. Carvão e carne de
churrasco. Celulares de cartão de memória. Pode-se tirar grande vantagem da correlação.
 16

O autor possui grande conhecimento na área estatística e análise de dados que se junta
a uma sólida formação em banco de dados. O conhecimento adquirido já tecnicamente o
autoriza a discorrer sobre o tema. Também o tema é instigante de grande interesse pelo
público já que dados armazenados são de interesse qualquer instituição.
A pesquisa será bibliográfica em biblioteca privada do autor com consultas prévias a
fontes disponíveis na Internet.
O capítulo 1 introduz o leitor ao conceito de Business Intelligence.
No capítulo 2 ao autor conceitua banco de dados e seus tópicos principais
aprofundando-se em modelagem relacional.
No terceiro capítulo entra a modelagem de dados dimensional que é um conceito
relativamente novo, mas que se tornou muito útil para a criação de ambientes de tomada de
decisão.
O capítulo 4 trabalha a tomada de decisão. De posse dos dados o que pode ser feito
para otimizar processos, aumentar vendas, diminuir prejuízos.
 17

CAPÍTULO 3 - DADOS RELACIONAIS

3.1. BANCO DE DADOS

Os bancos de dados foram desenvolvidos nos anos de 1950 e 1960 e popularizaram-se

à medida que seu uso se tornou indispensável a qualquer organização. Tudo são dados desde
uma agenda pessoal de amigos passando por uma lista de supermercado até a movimentação
financeira de um grande banco.

Figura 1 Representação de banco de dados

Todos estes dados devem pertencer naturalmente a uma categoria e muito

provavelmente estejam relacionados entre si. Para que se possam processar estes dados torna-
se necessário a criação de um banco de dados.

Um banco de dados pode ser definido como um conjunto de dados devidamente

relacionados. Podemos compreender como dados os objetos conhecidos que podem
ser armazenados e que possuem um significado implícito. Porém, o significado do
termo banco de dados é mais restrito que simplesmente a definição dada
anteriormente. (MACHADO, 2008, p. 20)

Para (HEUSER, 2009, p. 22) “um banco de dados é um conjunto de dados integrados
que tem por objetivo atender a uma comunidade de usuários”. Em tempo o termo preferido
pelos utilizadores é database (base de dados). Antigamente o termo databank (banco de
dados) era preferido pelos autores tendo caído em desuso e sido substituído pelo atual banco
ou base de dados. Na língua portuguesa ambos os termos são aceitos.
Ainda de acordo com (GUIMARÃES, 2003, p. 19), “um banco ou base de dados é
uma coleção de dados ou informações relacionadas entre si. Elas representam aspectos do
mundo real com significado próprio e que desejamos armazenar para uso futuro”.
O autor desta monografia também avaliza que ambos os termos sejam usados.
 18

3.2. SISTEMA DE GERENCIAMENTO DE BANCO DE DADOS

Desenvolvidos a partir do início dos anos 1970 basicamente os SGBDs primais e que
se tornariam mais tarde comerciais foram baseados em dois principais modelos lógicos de
dados. Um deles, o modelo de redes foi determinado pelo comitê “Codasyl Data Base Task
Group”.
Outro, o modelo hierárquico foi teve seu desenvolvimento pela IBM com vistas aos
seus mainframes. Evidentemente estes SGBDs são de interesse puramente histórico onde os
SGBDs de modelo relacional ocupam posição de destaque.
Um banco de dados terá seu gerenciamento por um SGBD. Este por sua vez deve
permitir uma série de funções necessárias ao manejo do banco, a saber, um SGBD deve
possuir funções básicas como a inserção de dados, sua eventual atualização e até a exclusão
dos dados. Também o gerenciador deve permitir a seleção ou obtenção dos dados quando esta
for necessária.
De acordo com (HEUSER, 2009, p. 23), “um SGBD é um software que incorpora as
funções de definição, recuperação e alteração de dados em um banco de dados”.
Os mecanismos internos de um SGBD devem evitar que os dados inseridos sejam
conflitantes, estes devem ser consistentes. O uso do banco de dados deverá permitir seu uso
de forma simultânea sem que isso afete o desempenho do banco e na hipótese de eventuais
falhas os dados devem ser armazenados com a necessária segurança para que possam ser
recuperados.

Um Sistema Gerenciador de Banco de Dados (SGBD) é constituído por um

conjunto de dados associados a um conjunto de programas para acesso a esses
dados. O conjunto de dados, comumente chamado banco de dados, contém
informações sobre uma empresa em particular. O principal objetivo de um SGBD é
proporcionar um ambiente tanto conveniente quanto eficiente para a recuperação e
armazenamento das informações do banco de dados. (SILBERSCHATZ, 1999, p.
1)

3.3. MODELO CONCEITUAL

Pontualmente a primeira etapa quando se pretende iniciar um projeto de um banco

de dados deve ser a sua modelagem conceitual. Objetivamente a modelagem conceitual
deve fazer uma descrição simples e de fácil compreensão pelo usuário-alvo de como e
quais informações deverão ser armazenadas no banco de dados final.

Representa, descreve a realidade do ambiente do problema, constituindo-se em uma

visão global dos principais dados e seus relacionamentos (estruturas de
informação), completamente independente dos aspectos de sua implementação
tecnológica. É uma descrição de alto nível (macrodefinição), mas que tem a
 19

preocupação de captar e retratar toda a realidade de uma organização, processo de

negócio, setor, repartição, departamento, etc. (MACHADO, 2008, p. 21-22).

O modelo conceitual resultante não deverá de modo algum ser projetado levando-se
em conta determinado tipo banco de dados disponível ou como será a forma de acesso aos
dados. Também não deverá ser levada em conta a forma de acesso aos dados ou sua
manutenção. Deve-se efetuar a modelagem conceitual tendo em mente que o mais
importante é a representação clara e adequado entendimento da realidade modelada.

Para (HEUSER, 2009, p. 25),

Um modelo conceitual é uma descrição do banco de dados de forma independente

de implementação em um SGBD. Um modelo conceitual registra que dados podem
aparecer no banco de dados, mas não registrar como estes dados estão armazenados
ao nível de SGBD.

3.4. MODELO ENTIDADE - RELACIONAMENTO

O MER é considerado a técnica de modelagem dados de maior difusão entre os já

usuários de bancos de dados ou estudantes da área. De características gráficas de fácil
assimilação e de fácil construção, pois utiliza figuras fáceis de desenhar. Esta simplicidade na
modelagem permite uma maior comunicação entre quem faz a modelagem e para quem se
destina, afinal de contas um projeto de banco de dados bem-sucedido está ligado diretamente
à sua correta modelagem.

A estrutura lógica de um banco de dados pode ser expressa graficamente por um

diagrama de entidades (representado por retângulos), por relacionamentos
(representado por losangos) e pelos atributos de cada entidade ou relacionamento
através de elipses (notação Peter Chen) (MACHADO, 2008, p. 25).

Se expressa o modelo de um banco de dados, de acordo com o modelo entidade-

relacionamento, fazendo uso de retângulos para representar uma entidade, losangos para a
representação de relacionamentos e elipses para a representação dos atributos de cada
entidade.

O modelo entidade-relacionamento (ER) foi definido por Peter Pin-Shan Chen, em

1976 e baseia-se na percepção do mundo real como constituído por um conjunto de
objetos básicos chamados entidades e relacionamentos e define uma técnica de
diagramação para modelos de dados, o diagrama de entidades e relacionamentos.
(MACHADO, 2008, p. 67)
 20

3.5. ENTIDADE

Qualquer coisa ou objeto do mundo real sobre os quais se deseja ou se precisa

armazenar alguma informação pode ser definido como uma possível entidade. Uma
entidade pode ser uma pessoa (física ou jurídica) ou um objeto físico (um veículo ou livro)
ou ainda um objeto abstrato (um departamento, uma conta corrente).

Alguns autores preferem referir-se à entidade como conjunto de entidades (CE) para
representar uma coleção de objetos do mesmo tipo e apenas a palavra entidade para a
representação de um único objeto deste conjunto. Já outros autores preferem o uso da
palavra entidade para representar o todo e a palavra ocorrência de entidade para referir-se a
um objeto deste conjunto.

Uma entidade é um objeto ou ente do mundo real que possui existência própria e
cujas características ou propriedades desejamos registrar. Ela pode ter uma
existência física (uma pessoa, um carro, um livro, uma peça) ou abstrata (um
departamento, um projeto, um curso). (GUIMARÃES, 2003, p. 33)

Uma entidade representa um conjunto de objetos da realidade modelada. Como o

objetivo de um modelo ER é modelar de forma abstrata um BD, interessam-nos
somente os objetos sobre os quais se deseja manter informações. (HEUSER, 2009,
p. 34)

PESSOA DEPARTAMENTO
Figura 2 Entidades
3.6. RELACIONAMENTO

Não é impossível apenas é muito raro que uma entidade não se relacione ou esteja
interligada a outra. Em uma modelagem que pretenda representar corretamente uma situação
do mundo real é muito comum que uma entidade esteja intimamente ligada à outra, pois
normalmente as informações que serão armazenadas em uma entidade serão solicitadas em
outras.
À ligação que envolve duas ou mais entidades dá-se o nome de relacionamento.

A essa conexão lógica entre duas ou mais entidades definimos como

relacionamento, que é representado em um diagrama entidade-relacionamento por
meio de uma linha unindo as entidades associadas, contendo ainda um losango com
o nome do relacionamento (um verbo flexionado) ao centro. (MACHADO, 2008,
p. 73)

Ao se nomear um relacionamento pode-se optar por utilizar um verbo que seria o

resultado do fato de duas entidades estarem associadas. Também é possível usar dois verbos
 21

para justificar o relacionamento. Um verbo no sentido da entidade X para a entidade Y e outro

verbo para esclarecer o relacionamento da entidade Y para a entidade X.

Um relacionamento entre dois CEs (conjunto de entidades) é uma lista de pares de

entidades, onde cada par representa uma associação entre uma entidade de um CE
com outra entidade de outro CE e que estabelece uma interdependência entre essas
entidades. (GUIMARÃES, 2003, p. 36)

POSSUI POSSUI

PERTENCE

Figura 3 Relacionamentos
3.7. MODELO RELACIONAL

Desenvolvido por Edgar F. Codd nos anos de 1970, o modelo de dados relacional
baseia-se em conceitos matemáticos simples: a teoria dos conjuntos. Com vistas a facilitar a
visualização dos dados para os usuários, o modelo de dados relacional simplifica um banco de
dados em um conjunto de tabelas (Tabela 2) formadas por suas linhas e colunas. Para
Machado (2008, p. 42), “São conjuntos de dados vistos segundo um conjunto de TABELAS, e
as operações que utilizam são feitas por linguagens que o manipulam, não sendo procedurais,
ou seja, manipulando conjuntos de uma só vez”.

Tabela 1 Clientes Fonte: Machado (2008, p. 42)

CodCliente NomCliente RuaCliente CidadeCliente
1 Luis Sampaio Rua A Rio de Janeiro
2 Carlos Pereira Rua B Niterói
3 José Alves Rua C Rio de Janeiro
4 Luis Paulo Souza Rua D Niterói

O modelo relacional estabeleceu-se como o primeiro modelo de dados para

aplicações comerciais. Um banco de dados relacional consiste em uma coleção de
tabelas, cada uma das quais com um nome único. Uma linha em uma tabela
representa um relacionamento entre um conjunto de valores. Uma vez que uma
tabela é uma coleção de tais relacionamentos, há uma estreita correspondência entre
o conceito de tabela e o conceito matemático de relação. (SILBERSCHATZ, 1999,
p. 61)

Em uma tabela serão encontradas diversas colunas que correspondem diretamente aos
atributos de uma entidade no caso do modelo entidade-relacionamento. No MER os atributos
descrevem uma entidade, no MR as entidades serão representadas por tabelas que irão
 22

armazenar os dados do banco. Assim todas as colunas de uma tabela traduzirão todos os
atributos de uma entidade. Cada tabela deverá conter um número variável de linhas (também
chamadas tuplas) que tenderá a aumentar com o tempo.
Complementa o modelo relacional o domínio de cada coluna, ou seja, quais valores ou
tipos de dados (datatype) são admitidos para esta coluna. Devem ser uma cadeia de caracteres
ou valores inteiros ou decimais, entre outros. Sendo o tipo de domínio uma restrição natural
do banco de dados, garante que todos os dados que irão ser recebidos pela coluna sejam
sempre do mesmo tipo de dados.

O modelo relacional foi criado seis anos antes do MER e, portanto, é independente
do mesmo na sua definição e nos seus conceitos básicos. Do ponto de vista
didático, porém, fica mais simples introduzir esses conceitos via analogia com o
MER, além de que ela simplifica a compreensão do mapeamento do MER para o
MR no projeto top down de um BD. (GUIMARÃES, 2003, p. 36)

Denomina-se esquema de uma relação utilizar o nome da relação ou tabela e logo

após, entre parênteses, todos os nomes de atributos da tabela, no exemplo, representando
a tabela 2.

Clientes (codcliente, nomecliente, ruacliente, cidadecliente)

3.8. VALORES NULOS

Fosse o mundo perfeito e todas as informações modeladas para um banco de dados

estariam prontamente disponíveis quando do preenchimento das mesmas, mas na
implementação de um banco de dados será necessário estar preparado para uma
característica não muito bem-vinda que é a ausência das informações.

Ao começar o preenchimento das informações requeridas em um banco será comum

deparar-se com a falta de informações sobre diversos atributos de uma ou várias linhas. Para
(GUIMARÃES, 2003, p. 55), “poder-se-ia adotar a solução draconiana de que tuplas com
informações incompletas seriam impedidas de inclusão na BD, mas em geral isso é
inaceitável”.
Durante a modelagem e mesmo na implementação do banco observa-se que as
informações necessárias nem sempre estarão disponíveis no momento e talvez em momento
algum. Se for solicitado que se preencha o nome da esposa, o indivíduo pode nem ser casado
o que significa que este campo deverá ficar sem preenchimento. Já em um banco que solicite
o departamento onde um funcionário ficará alocado pode ser que na hora do cadastramento
ainda não se saiba para qual departamento este será encaminhado. Para estes casos descritos
 23

devem-se deixar os valores em branco o que significa que o campo assumirá o valor vazio ou
nulo (do inglês null value).
Evidentemente esta será uma solução tampão pois um valor null pode assumir diversas
significações de acordo com (GUIMARÃES, 2003, p. 55), “(...) temporariamente vazio,
inexistente, desconhecido, não se aplica (...)”.
Depois de vários debates a comunidade científica não chegou a nenhum consenso
sobre o null, se deveria ser mais específico ou não.

3.9. CHAVE PRIMÁRIA

Uma chave é uma coluna ou combinação de colunas que assegurem que cada linha de
uma tabela possui um valor único. A chave deve sempre possuir um valor, ou seja, não podem
existir valores null em uma chave primária. Ao se conhecer o valor da chave deverá ser
possível distinguir uma linha de todas as outras.

É imperativo que possamos sempre encontrar um determinado objeto (ou linha ou

registro em uma tabela). Isso significa que todos os registros devem ser exclusivos;
caso contrário, não seria possível distinguir dois que fossem idênticos.
(CHURCHER, 2009, p. 98)

3.10. CHAVE CANDIDATA OU ALTERNATIVA

Sempre é possível que uma tabela possua mais de uma coluna em condições de
responder como chave primária da tabela. Neste caso deve-se escolher a chave com menor
número de colunas ou que seja mais significativa na identificação das linhas da tabela. As
chaves que não forem escolhidas tornar-se-ão chaves candidatas.

3.11. CHAVE ESTRANGEIRA

É a chave que permite que existam relacionamentos entre as tabelas, o fato de existir
entre duas tabelas um relacionamento confirma que uma das tabelas recebe a chave primária
de outra e que uma vez na tabela que recebe a chave, esta é chamada de chave estrangeira.
Tabela 2 Funcionário (parcial). Fonte: Machado (2008, p. 62)
NumReg NomeFunc DtAdmissão Sexo CdDepto
101 Luis Sampaio 10/8/2003 M D5
104 Carlos Pereira 2/3/2004 M D6
134 José Alves 23/5/2001 M D1
 24

Tabela 3 Departamento (parcial). Fonte: Machado (2008, p.62)

CdDepto NomDepto RamalTel
D1 Assist. Técnica 2246
D2 Estoque 2589
D3 Administração 2772

Nas tabelas 3 e 4 NumReg e CdDepto são chaves primárias das respectivas tabelas.
CdDepto na tabela 3 é chave estrangeira.

3.12. RESTRIÇÕES DE INTEGRIDADE

Em um SGBD existem mecanismos cuja função é manter os dados do banco íntegros

de forma que representem exatamente a realidade modelada pelo banco de dados.

3.13. INTEGRIDADE DE DOMÍNIO

Esta restrição define que o tipo de dados (datatype) escolhido para uma coluna
(domínio) de uma tabela deverá ser o tipo de dados para todos os dados que esta coluna
receber. Desta forma se, por exemplo, for escolhido um valor numérico para determinada
coluna, esta coluna só aceitará valores numéricos, o que garante que os dados quando forem
solicitados por ocasião de uma consulta estejam exatamente como foram modelados.

3.14. INTEGRIDADE DE VAZIO

É por este tipo de restrição que se faz a definição se uma coluna é de preenchimento
obrigatório ou opcional. O padrão de um banco de dados quando da sua implementação
sempre é de preenchimento opcional, ou seja, excetuando os campos que compõe a chave
primária que devem ser obrigatoriamente preenchidos já que chaves não aceitam valores null,
todos os campos podem deixar de serem preenchidos. Para obrigar que um campo seja
obrigatoriamente preenchido será necessário na criação da tabela fazer com que o null seja
negado, usando not null.

3.15. INTEGRIDADE DE CHAVE

Esta restrição especifica que campos que fazem parte da chave primária e da chave
alternativa devem ser únicos, não podem se repetir.

3.16. INTEGRIDADE REFERENCIAL

Especifica que os valores que aparecem na chave estrangeira de uma tabela devem
obrigatoriamente aparecer na chave primária da tabela que está sendo referenciada.
 25

De acordo com (HEUSER, 2009, p. 127), “as restrições dos tipos acima especificados
devem ser garantidas automaticamente por um SGBD relacional, isto é, não deve ser exigido
que o programador escreva procedimentos para garanti-las explicitamente”.

3.17. NORMALIZAÇÃO

Considera-se normalização um modo de fazer uma verificação nas colunas de uma

tabela de modo que não apresentem problemas posteriores. Para isso é necessário que todos os
campos tenham sido criados corretamente e na tabela certa. Durante o processo de
normalização será feita a verificação da necessidade da criação de novas tabelas para correta
acomodação de todos os dados e que estes dados sejam precisos. Também considerada uma
teoria, a normalização consiste de uma série de técnicas propostas com o intuito de eliminar
as possíveis anomalias que um modelo de dados poderá gerar após a sua implementação.
Estas possíveis anomalias, que são tratadas na sequência, consistem em uma modelagem não
considerada ideal e que poderá acarretar além da redundância dos dados, perda de
desempenho do banco.
De acordo com (GUIMARÃES, 2003, p. 81), “os conceitos de normalização vão nos
ajudar a projetar bases de dados com menos possibilidades de inconsistências e menos
redundâncias de informação”.
Para (HEUSER, 2009, p. 213), “entre as propriedades consideradas indesejáveis em
um projeto de banco de dados estão as informações repetidas e a inabilidade para
representação de certas informações”.
O autor concorda com (MACHADO, 2008) quando este ressalta que ao pensar-se um
banco de dados deve-se evitar a mistura de assuntos em uma tabela. Note que a tabela 5 que
possui dados atômicos, tem dois assuntos tecnicamente misturados, pois tanto o nome da
comida quanto os ingredientes que fazem parte de sua composição estão na mesma tabela.
Na maior parte das vezes a normalização poderá gerar uma maior quantidade de
tabelas que aumentarão o número de tabelas original do banco. Esta divisão das tabelas
aumentando seu número de certa forma acabará por simplificar o número e atributos ou
colunas de uma tabela o que acarretará por deixar as tabelas mais simples deixando o modelo
mais estável como um todo e por consequência tornando as manutenções do banco mais raras.
Na prática é possível normalizar um modelo de cima para baixo (top -down) ou de
baixo para cima (down-top). Quando da definição de uma modelo de banco de dados pode-se,
ao se pensar nas futuras tabelas que irão armazenar os dados do modelo, ir normalizando à
medida que vamos projetando o modelo. Assim ao final do modelo restarão poucas tabelas
 26

para passarem pelo processo de normalização. Projetar um banco desta forma pode ser muito
proveitoso pelo fato de que com algum conhecimento por parte do usuário poderá facilitar e
muito o processo final da implementação por que o modelo já deverá estar quase pronto.

O conceito de normalização foi introduzido para o modelo relacional por Edgar F.

Codd, em 1970 (primeira forma normal). Essa técnica é baseada em um processo
matemático formal, que tem seus fundamentos na teoria dos conjuntos.
(MACHADO, 2008, p. 182)

3.18. DADOS ATÔMICOS

O conceito de normalização passa diretamente pelo ato de se obter dados atômicos em

uma tabela. Para uma tabela de entregas de uma pizzaria será necessário saber o endereço do
cliente que irá receber a pizza. Este endereço poderá ser uma coluna única com todos os dados
(rua, número, bairro, CEP, etc.). Já para uma imobiliária onde o que será oferecido são
diversos prédios comerciais como salas, lojas, casas, etc. A coluna endereço não poderia ser
única com todos os dados. O ideal deverá ser que todos os dados que formam o endereço
estejam separados de forma que se possa fazer uma pesquisa apenas por bairro ou ainda por
cidade. (BEIGHLEY, 2008) ressalta que ambas as tabelas, tanto da Pizzaria quanto da
Imobiliária são considerados atômicos, ou seja, estão suficientemente divididos.
Para o autor as tabelas deverão ser divididas apenas o suficiente para que a tabela seja
considerada eficiente o que evitaria divisões desnecessárias. Se não houver a necessidade
expressa de determinada coluna esta não deverá ser criada.
Segundo (BEIGHLEY, 2008, p. 139), dados atômicos:

O que é um átomo? Um pequeno pedaço de informação que não pode ou não

deveria ser dividido. É o mesmo para seus dados. Quando eles são ATÔMICOS,
isto quer dizer que ele já foi dividido até o menor pedaço de dados que não pode
ou não deve ser dividido.

(BEIGHLEY, 2008) cita duas regras para que uma tabela possua dados atômicos:
 Uma coluna para possuir dados atômicos não poderá possuir muitos valores do
mesmo tipo de dados na mesma coluna (tabela 5).
 Uma tabela que possua múltiplas colunas com o mesmo tipo de dados não
possui dados atômicos (tabela 6).
Para (BEIGHLEY, 2008) quando do projeto de uma base de dados algumas perguntas
deverão ser feitas, por exemplo, exatamente o que uma tabela deverá armazenar? Pessoas,
vacas ou rosquinhas?
 27

Como serão feitas as consultas nas tabelas projetadas? Como exatamente as

informações poderão ser consultadas? Pensando nisso o projeto das tabelas deverá levar em
conta a facilidade de sua consulta.
Tabela 4 Fonte: Beighley (2008, p. 142)
Nome_comida Ingredientes
Pão Farinha, leite, ovo, fermento, óleo
Salada Alface, tomate, pepino

Tabela 5 Professores e disciplinas. Fonte: do Autor

Professor Disciplina1 Disciplina2 Disciplina3
Ricardo XHTML Ajax XHTML
Robson PHP SQL null
José Modelagem Java Script UML

Observa-se que o fato de uma tabela não possuir dados atômicos acabará por
prejudicar a manutenção e consequente desempenho do banco. A tabela 5 à medida que for
recebendo informações terá naturalmente uma grande redundância de informações, pois visto
que é uma tabela que pretende cadastrar diversos pratos de um restaurante, será muito natural
que os ingredientes se repitam de um prato para outro. Além do evidente consumo de disco
para armazenar informações repetidas, uma simples pesquisa por determinado prato ou
ingrediente irá consumir muito tempo e carga do processador.
Já na tabela de número 6, da forma em que está fará com que as disciplinas sejam
constantemente repetidas para os diversos professores. Uma pesquisa sobre determinada
disciplina também irá consumir muito tempo devido às diversas colunas com informações.
Em suma optar por dados atômicos fará com que os dados estejam corretos, pois em
uma coluna denominada logradouro teremos a garantia de que esta apenas possui os
logradouros e nenhum outro tipo de informação.

3.19. ANOMALIAS

Normalizar corretamente um modelo de dados fará com que diversos problemas ao

lidar com o banco de dados possam ser minimizados e até evitados.
Observe na tabela 7 que para, por exemplo, fazer uma consulta que mostre o nome de
todos os clientes que efetuaram pedido de refrigeradores no mês de junho, será necessário que
seja percorrida todas as linhas da tabela. Considerando uma empresa com uma grande venda e
que tenha muito tempo de mercado deveremos estar preparados para uma tabela com milhares
de linhas. O que tornará a consulta anterior muito demorada e que consumirá com isso muito
 28

recursos tanto de processador quanto de memória, inclusive a quantidade de espaço em HD

que será necessária para o armazenamento destes dados.
Uma breve olhada para a tabela 7 e poderá observar-se que é uma tabela mal
projetada, pois mistura muitos assuntos na mesma tabela.
Na sequência serão listados alguns destes problemas que podem ocorrer em um banco
se não processada a normalização.
Tabela 6 Fonte: (MACHADO, 2008, p. 182)
Nome Pedido Nome Endereço Limite de Data Nome
Produto número Cliente Cliente Crédito Vendedor
Limpadora a 1458 Davi Rio de US$ 5,000 05/05/00 Carlos
vácuo Bachman Janeiro Book
Computador 2730 Helena Vancouver US$ 2,000 05/06/00 João Hans
Daudt
Refrigerador 2461 José Chicago US$ 2,500 07/03/00 Silvio
Stolaruck Pherguns
Televisão 456 Pedro São Paulo US$ 4,500 09/05/00 Frederico
Albuquerque Raposo
Rádio 1986 Carlos Porto US$ 2,000 18/09/00 Rui Ments
Antonelli Alegre
CD player 1815 Davi Rio de US$ 5,000 18/04/00 Silvio
Bachman Janeiro Pherguns
Limpadora a 1963 C. V. Bombaim US$ 7,000 03/01/00 Carlos
vácuo Ravishandar Book
Limpadora a 1855 Carlos Porto US$ 2,000 13/05/00 João Hans
vácuo Antonelli Alegre
Refrigerador 1943 Davi Rio de US$ 5,000 19/06/00 Silvio
Bachman Janeiro Pherguns
CD player 2315 Davi Rio de US$ 5,000 15/07/00 João Hans
Bachman Janeiro

3.19.1. ANOMALIAS DE ATUALIZAÇÃO

Tomando ainda como base a tabela 7, se porventura um determinado produto mudar de

nome, por exemplo, refrigerador mudará de nome para refrigerador duplex. Será preciso
que todas as linhas da tabela sejam percorridas para que esta alteração seja processada, o que
de maneira similar a seleção de dados simulada anteriormente, levará muito tempo
consumindo recursos preciosos.
De acordo com (GUIMARÃES, 2003, p. 36),

(...) uma atualização do endereço de um cliente exige que se faça a consulta de

todas as linhas em que o nome do cliente seja igual ao desejado e se realize a
alteração nessas linhas.
 29

3.19.2. ANOMALIAS DE EXCLUSÃO

A tabela 7 que mostra as informações de produtos, vendedores, clientes e pedidos de

venda, por ter os dados misturados, poderá causar problemas quando da decisão, por parte dos
administradores do banco, de excluir alguma linha. Observe que para o caso de ser necessária
a exclusão do cliente José Stolaruck, juntamente com o cliente serão excluídos suas
informações de endereço, limite de crédito e ainda do vendedor que o atendeu. Se o cliente
efetuou uma única compra na empresa, com a exclusão de um pedido serão perdidas todas as
suas informações.

3.19.3. ANOMALIAS DE INCLUSÃO

Observe-se que na tabela 7, da forma como foi projetada, se desejarmos acrescentar

uma nova linha com novo pedido para o cliente Davi Bachman será necessário repetir as
informações de endereço do cliente, seu limite de crédito e até mesmo o nome do produto se o
cliente resolver comprar o mesmo item. Aliás, de um modo geral sempre que um cliente
efetuar um pedido, todos os seus dados deverão ser repetidos e esta urgência da repetição das
informações que foi imposta pelo projeto do banco, acarretarão diversos problemas na
manutenção do banco.
Note-se que uma inclusão mal efetuada poderá fazer com que o mesmo cliente tenha
dois endereços diferentes ou limite de crédito com valores desencontrados.

3.20. DEPENDÊNCIA FUNCIONAL TOTAL

Se a correta normalização de um modelo de dados contribuirá para a determinação de

tabelas bem projetadas e estruturadas que com toda a certeza irão evitar o concurso das
anomalias descritas anteriormente, também inclusa no conceito de normalização está a
definição de dependência funcional. Dependência funcional descreve a dependência entre os
atributos ou campos de uma tabela. Encontrando as DF reforçaremos o conceito de chave
primária de uma tabela, trabalhado anteriormente.
(CHURCHER, 2009, p. 113) afirma sobre uma dependência funcional, “se eu
conheço o valor para este(s) atributos(s), posso dizer, de maneira única, o valor de alguns
outros atributos”.
(MACHADO, 2008, p. 187) sintetiza que,

Dados dois conjuntos de atributos A e B de uma entidade diz-se que:

 B é funcionalmente dependente de A ou
 A determina B ou
 30

 B depende de A

Tecnicamente é possível fazer a descrição de uma dependência funcional desta forma:

T.A ; T.B
Descreve-se assim: “na tabela relacional denominada T, a coluna A é dependente
funcional da coluna A”. Se a coluna B é dependente de A, a cada valor de A deverá existir um
único valor para B.
Na seguinte tabela:
livro (ISBN, título do livro, número de páginas, preço)
O título do livro, o número de páginas e o preço são dependentes do ISBN, pois a
qualquer alteração no ISBN, mudarão imediatamente o título, o número de páginas e o preço.
Em outras palavras ISBN determina título do livro, número de páginas e preço.
Então:
livro.ISBN ; livro.título do livro
Na tabela relacional livro, a coluna título do livro é dependente funcional da coluna
ISBN.
livro.ISBN ; livro.número de páginas
Na tabela relacional livro, a coluna número de páginas é dependente funcional da
coluna ISBN.

3.21. DEPENDÊNCIA FUNCIONAL PARCIAL

Se em uma DF total um atributo não-chave é dependente exclusivamente da chave

primária, para existir uma DF parcial será necessário que um atributo não-chave dependa
apenas de parte da chave e não de toda.
De acordo com (HEUSER, 2009), “uma dependência (funcional) parcial ocorre
quando uma coluna depende apenas de parte de uma chave primária composta”.
 31

Tabela 7 Super-heróis (parcial). Fonte: (BEIGHLEY, 2008, p. 261)

nome poder fraqueza cidade iniciais país Arqui-inimigo
Super Limpa Alvejante Gotham SL US Verminador
Lixeiro rapidamente
O Corretor Faz Null Nova York OC US Senhor
dinheiro do Impostos
nada
Super Cara Voa Pássaros Metrópolis SC US Super Colega
Garçom Nunca Insetos Paris GM França Garota Coma
Maravilha esquece um Tudo O Que
pedido Puder
Homem Cria Alvejante Tulsa HP US Hoover
Poeira tempestades
de areia
Super Cara Super força Alumínio Metrópolis SC US Badman

A tabela 8 tem uma chave primária composta formada pelas colunas nome e poder.
Conforme (BEIGHLEY, 2008) a coluna iniciais não é funcionalmente dependente de toda a
chave, pois depende apenas da coluna nome já que apenas se a coluna nome for alterada
haverá alteração na coluna iniciais. As outras colunas todas dependem da chave como um
todo. Neste caso esta tabela possui uma dependência funcional parcial.
Tabela 8 Fonte: (TONSIG, 2006, p. 41)
Nr_Pedido Cod_produto Qtde_Comprada Descrição_produto
123456 321 12 Parafuso Metálico

Observe que na tabela 9 a chave primária é composta por Nr_Pedido + Cod_produto

que por sua vez determinam a coluna Qtde_comprada. Mas a coluna Descrição_produto é
funcionalmente dependente apenas de parte da chave, ou seja, da coluna Cod_produto.
Novamente uma dependência funcional parcial.

3.22. DEPENDÊNCIA FUNCIONAL TRANSITIVA (TRANSITÓRIA)

Neste caso será necessário verificar o relacionamento de uma coluna não-chave com
as outras colunas. Quando um atributo não-chave depende de outro atributo não-chave existe
uma dependência funcional transitiva.
De acordo com Beighley (2008, p. 262), “dependência funcional transitória: quando
qualquer coluna não-chave é relacionada a qualquer outra das colunas não-chave”.

Tabela 9 Fonte: (TONSIG, 2006, p. 42)

Cod_Compra Cod_Produto Cod_Fornecedor Quantidade Nome_Fornecedor
44422 321 95.978.077.0991.99 12 Fulano de Tal
 32

Observe que na tabela 10 a coluna Nome_Fornecedor que é não-chave depende da

coluna Cod_Fornecedor que também não é chave.
Se uma coluna não-chave for alterada e esta alteração contribuir para que outras
colunas também sejam alteradas estaremos diante de uma dependência funcional transitória.

3.23. REGRAS DE NORMALIZAÇÃO

O autor optou nesta monografia por ater-se as regras de normalização que foram
propostas pelo Doutor Edgar Ted Codd.

3.24. PRIMEIRA FORMA NORMAL – 1FN

Para que uma tabela esteja na primeira forma normal será necessário que:
 As colunas da tabela só poderão possuir valores atômicos (unívocos).
 Não poderão existir múltiplas colunas com o mesmo tipo de dados.
Para (MACHADO, 2008, p. 183), “uma tabela está na primeira forma normal se e
somente se todas as colunas possuem um único valor, e não existem grupos repetitivos
(colunas) em uma linha ou atributos compostos”.
(HEUSER, 2009) por sua vez sugere que uma tabela se encontre na 1FN quando esta
não possua tabelas aninhadas. O autor concorda pelo fato de reafirmar o conceito de uma
tabela não misturar assuntos e apenas pretender armazenar informações sobre um único item.
Os atributos repetitivos e multivalorados deverão obrigatoriamente gerar novas tabelas para o
modelo.

3.25. SEGUNDA FORMA NORMAL – 2FN

Uma tabela estará de acordo com as regras da segunda forma normal se já estiver na
primeira forma normal e se não possuir dependências funcionais parciais. Uma estrutura de
dados que possua chaves primárias compostas, para estar na 2FN não pode possuir colunas
que sejam funcionalmente dependentes apenas uma parte da chave.
(BEIGHLEY, 2008) vaticina que uma tabela em que todas as colunas façam parte da
chave primária e que já esteja na 1FN automaticamente também será 2FN. Ou ainda se uma
tabela já estiver respeitando as regras de 1FN e tenha apenas uma coluna como chave
primária, também estará em 2FN. Em tempo, para uma tabela em que foi criada uma chave
primária artificial (sintética) e que esteja em 1FN também estará na 2FN.
 33

De acordo com (HEUSER, 2009, p. 197), “uma tabela encontra-se na segunda forma
normal (2FN) quando, além de encontrar-se na 1FN, cada coluna não chave depende da chave
primária completa”.

3.26. TERCEIRA FORMA NORMAL – 3FN

Para que uma tabela fique na terceira forma normal será necessário que a mesma já
esteja na 2FN e que não possua dependências funcionais transitórias. Uma vez que o conceito
de DF seja bem compreendido é muito difícil que ao se projetar um modelo de dados com
suas tabelas já não se enxergue as possíveis DF e já se vá evitando ocorrerem.
(HEUSER, 2009, p. 200) assinala que, “uma tabela encontra-se na 3FN quando, além
de estar na 2FN, não contém dependências transitivas”.
Para (MACHADO, 2008), o fato de uma tabela estar na 3FN e não possuir
dependências funcionais transitivas evita que ocorram as anomalias de inclusão, atualização e
exclusão.
 34

Data warehouse
(FILHO, 2012, p. 86) afirma que a melhor definição para DW é um grande armazém
de dados para armazenar informações e propiciar a constiutição de ambientes mais
estruturados para suporte à decisão. O ponto de partida para a implementação de um bom
ambiente de business intelligence parte da criação de um Data warehouse.
Utliliza-se o DW para fazer consultas sobre todo o banco e todos os setores da
empresa. Leia-se vendas, estoque, financeiro, compras, RH, etc.
Dentre as razões para estruturar um Data warehouse podemos citar:
Otimização do processo de consulta em grandes volumes de dados – até pelo fato de
armazenar dados sem normalização um DW poderá ter uma quantidade de dados absurda, da
ordem de terabytes.
Analisar eventos passados – quem conhece o passado pode prever o futuro. Se uma
danceteria souber que determinada semana do ano passado teve poucos frequentadores será
possível tomar alguma atitude para que isso não se repita este ano. Promoções, ingresso grátis,
etc.
Busca de informações de acordo com a necessidade do usuário – ao gerente comercial
é possível fazer acompanhamento de vendas de sua equipe e corrigir rumos. Já o supervisor
de cobrança pode montar um mapa de devedores de acordo com suas consultas ao DW.

OBJETIVOS DO DATA WAREHOUSE

O DW deve manter as informações acessíveis na organização. Seu conteúdo deve ser

de fácil interpretação, acesso e com bons índices de desempenho às respostas dos usuários.
Deve garantir a consistência dos dados na empresa. Uma mesma informação praticada por
diferentes áreas dentro da mesma empresa deverá ser rigorosamente igual com um conceito
único de dados para todos.
O DW deverá ser flexível e se adaptar às mais diferentes origens de dados além estar
preparado para alterações frequentes. Com relação aos dados de um DW estes estarão
disponíveis apenas para consultas (leitura) e não poderão ser alterados.
Como já deve ter ficado claro anteriormente o Data warehouse dará suporte à tomada
de decisão.
Modelagem dimensional
A modelagem dimensional é a técnica utilizada para ter uma visão multidimensional dos dados e
não uma visão simplista, como na modelagem relacional (ZAIDAN, 2016). As seguintes tabelas
mostram dois comparativos entre os modelos relacional abordado no capítulo anterior e o
modelo dimensional:
 35

Tabela 10 – Fonte (ZAIDAN, 2016)

Aplicativos transacionais (Modelo Sistemas analíticos (Modelo dimensional)

relacional)
Visão do atual e do real
Solução para requisitos conhecidos
Abrangência restrita
Informação produzida por profissionais de
informática
Custo e tempo para obtenção da
informação altos
Informação disponível a poucos usuários
Visão histórica e de tendência
Permitir a identificação de fatos
desconhecidos
Abrangência ampla
Informação produzida pelo próprio usuário
Informação obtida com baixo custo
Informação democratizada

Tabela 11 Fonte (ZAIDAN, 2016)

Característica Aplicativos transacionais Sistemas analíticos

(Modelo relacional) (Modelo dimensional)
Atualizações Mais frequentes Menos frequentes
Tipo de informação Detalhes Agrupamento
Quantidade de Dados Poucos Muitos
Precisão Dados atuais Dados históricos
Complexidade Baixa Alta
Consistência Microscópica Global
Exemplos CRM, ERP, Supply Chain EIS (Executive Information
System)
Terminologia Linhas e colunas Dimensões, Medidas e Fatos

A modelagem dimensional foi pensada com a exclusiva intenção da criação de

projetos de data warehouse e sistemas que propiciam a tomada de decisão. Até então a
estrutura proporcionada pelo modelo relacional não favorecia o armazenamento de grandes
volumes de dados. O modelo dimensional faz a associação com cubos de dados onde as faces
do cubo poderiam ter diversas medidas numéricas como:
 Quantidade de produtos vendidos
 Valor de faturamento
 Quantidade de entregas efetuadas
 Valor dos impostos
 Etc.
O modelo dimensional para construção de banco de dados para Data Warehouse é uma
forma de modelagem em que é possível relacionar as informações e estas serão representadas
 36

como se estivessem em um cubo. Desta forma será possível “cortar” este cubo em fatias que
poderão ser analisadas a procura de métricas pré-estabelecidas.

MODELO STAR SCHEMA

Criado por Ralph Kimball este modelo não é normalizado como no modelo relacional.
Isto faz com que os dados sejam extremamente redundantes e por este fato, de evitar os
JOINS faz com que a consulta tenha altíssimo desempenho. Muito utilizada na concepção de
Data warehouses.
Este modelo contém a tabela fato ao centro cercada pelas tabelas dimensões.

De acordo com (PINHO, 2016, p. 30) no modelo Star todas as tabelas relacionam-
se diretamente com a tabela de fatos, sendo assim as tabelas dimensionais devem
conter todas as descrições que são necessárias para definir uma classe como
Produto, Tempo ou Loja nela mesma, ou seja, as tabelas de dimensões não são
normalizadas no modelo estrela.
Figura 4 a tabela de fatos fica ao centro cercada
das tabelas dimensionais assemelhado a uma
estrela.

Os dados são modelados em tabelas dimensionais ligados a uma tabela de fatos. Desta
forma a consulta ocorre inicialmente nas tabelas de dimensão e depois nas tabelas de fatos,
garantindo a precisão dos dados por meio de uma estrutura de chaves onde não é preciso
percorrer todas as tabelas como aconteceria se fosse o modelo relacional normalizado. Isso
garante velocidade de acesso e excelente desempenho.

MODELO SNOW FLAKE

Basicamente é considerado uma variação do modelo estrela mas conta com tabelas
normalizadas.
 37

No modelo Snow Flake as tabelas dimensionais relacionam-se com a tabela de

fatos, mas algumas dimensões relacionam-se apenas entre elas, isto ocorre para fins
de normalização das tabelas dimensionais, visando diminuir o espaço ocupado por
estas tabelas (PINHO, 2016, p. 29).

Figura 5 Modelo Snow flake

MÉTRICAS

Figura 6 - Métricas

É uma informação numérica cuja principal função é medir as

transações da empresa. No geral sempre deverá ser algum indicador que
possa ser quantificado, ou seja, que operações matemática possam ser
realizadas com ele. Leia-se, adição, subtração, multiplicação, divisão, etc.
Na grande maioria das vezes uma métrica será aquilo que o usuário deseja fazer a
medição e normalmente encontra-se perguntando “o que” deseja-se medir. Na figura as
métricas são representadas pelo preço da venda, preço de custo e a quantidade de unidades
vendidas.

As métricas são o foco da análise dos dados, pois expressam os valores que irão
quantificar o que desejamos analisar. Podemos analisar o valor total em Real dos
produtos vendidos, assim como podemos, em uma análise, representar a métrica
das quantidades vendidas de produtos (SERPA, 2015, p. 17).

As métricas são subdivididas em:

ADITIVAS

Os fatos que mais fazem sentido para serem analisados são os perfeitamente aditivos.
Exemplo: valor das vendas em dólares e unidades. Entretanto, medidas numéricas de
intensidade, que não são perfeitamente aditivas (semiaditivos), também podem ser utilizadas
(CORDEIRO, 2015).
 38

DERIVADAS

Cálculo efetuado sobre as métricas aditivas

SEMI-ADITIVAS

Diferentemente dos fatos aditivos, os fatos semiaditivos não representam um fluxo

temporal. Medidas de intensidade são, normalmente, fatos aditivos ao longo de quase todas as
dimensões, exceto a dimensão Tempo. Exemplos de medidas de intensidade: níveis de
inventário e balanço contábil (CORDEIRO, 2015).

NÃO-ADITIVAS

Os fatos mais úteis em uma tabela Fato são numéricos e aditivos. Teoricamente, um
fato medido pode ser textual; no entanto, isso raramente acontece. Na maioria dos casos, uma
medida textual é uma descrição de algo e é obtida a partir de uma lista discreta de valores.
Não armazenamos informações textuais em tabelas Fato, como comentários textuais. A menos
que o texto seja exclusivo para cada linha. Exemplo: descrição climática de um registro de
acidente (CORDEIRO, 2015).
A modelagem dimensional envolve basicamente o uso das tabelas fato e das tabelas
dimensões.

TABELAS FATO

A tabela fato está ligada sempre a duas ou mais dimensões (data e outras). É a
principal tabela do DW e é onde as métricas estão armazenadas.
Figura 7 - Tabela fato (FILHO,
2012)
Tabela de fatos de entregas
Valor de faturamento
Quantidade de produtos
Quantidade de entregas
Peso
Valor impostos
Volumes

As tabelas de fatos são utilizadas para armazenar medidas numéricas, que são
associadas a eventos de negócios. O valor de faturamento, a quantidade de produtos
entregues e a quantidade de entregas são exemplos de fatos que podem ser
visualizados por várias dimensões (FILHO, 2012, p. 174).

TABELAS DIMENSÕES

É toda e qualquer informação que qualifique uma métrica, mas na maioria das vezes
pode ser encontrada ao perguntar “o porquê” o usuário deseja mensurar uma informação.
 39

As tabelas de dimensão estão sempre acompanhadas de tabelas de fatos. Sem os

fatos não há informações para exibir aos usuários. É a partir das dimensões
disponíveis que os executivos podem formular diferentes visões das mesmas
informações (FILHO, 2012, p. 175).

CUBOS

Basicamente o cubo pode ser uma metáfora onde os lados são as dimensões como por
exemplo tempo, região, produto e assim por diante. Por questões espaciais nossa visão apenas
consegue lidar com três dimensões, mas um cubo pode ter muito mais dimensões. Na figura
em exemplo de um cubo com 3 dimensões: localização, produto e período de vendas.

Figura 8 - Cubo com 3 dimensões Fonte: (ZAIDAN, 2016)

OLAP

As ferramentas organizadas para que os usuários possam acessar as informações do

DW são denominadas de OLAP. Também pode ser considerada uma base de dados
centralizada formado por outras bases relacionais.

O termo OLAP surgiu em 1993, proferido por Edgar Frank Codd, matemático
britânico, que é considerado “o pai do banco de dados relacional”. OLAP, ou
Online Analytical Processing, como a capacidade de manipular e analisar grandes
volumes de dados (SERPA, 2015, p. 11).

OPERAÇÕES OLAP

Drill-down – aumentar o grau de detalhe da informação como no exemplo:

Dimensão tempo: dia  semana  quinzena  mês  trimestre  ano
Roll-up ou drill-up – contrário de drill-down, significa diminuir o detalhe da
informação: Dimensão tempo: ano  mês  dia.
Drill-across – pode ocorre quando a visão dentro de uma dimensão for alternada. Por
exemplo na dimensão tempo “pular” de ano para trimestre sem passar por dia.
 40

Drill throught – ocorre quando o usuário passa de uma informação contida numa
dimensão para outra. Por exemplo: a navegação está concentrada na dimensão tempo e em
seguida a análise passa para a dimensão região (FILHO, 2012, p.79).
Slice and disse – utiliza-se para modificar o eixo das informações. Trocar uma visão
de dados e colunas por uma de linhas.
 41

CAPÍTULO 4 - A TOMADA DE DECISÃO

4.1. DADOS DEMAIS

Para alimentar os decididores, de informações para que possam tomar as decisões mais
acertadas precisamos falar de Big Data, um banco de dados de tamanho bem maior que os que
já conhecemos (SILVER, 2013).
DAVENPORT (2014) afirma em seu livro de título homônimo ao deste capítulo que
Big Data denota volumes de dados inusitadamente grandes ou tipos de dados não
estruturados. Dados armazenados em tabelas ou planilhas possuem uma determinada estrutura
do tipo que possui um campo ou cabeçalho em uma coluna e as informações em linhas como
na modelagem de dados relacional. Relacional tem a origem na palavra relação ou também
conhecida como tabela. Na tabela é possível fica de fácil entendimento de como as
informações seriam recuperadas.
Tabela 12 - Fonte: do autor
Nome Data de nascimento Time de futebol
Pedro 14/10/1990 Grêmio
Alessandro 10/01/2000 Juventude
Como se fosse etiquetas as colunas nome, data de nascimento e time de futebol
facilitam a compreensão e posterior recuperação destas informações.
Já os dados não-estruturados são encontrados em postagens em redes sociais,
documentos de texto, e-mails, vídeos, animações, etc. É uma tarefa hercúlea recuperar estas
informações. E observe que a cada dia mais e mais informações vão se juntando as anteriores
formando o que chamamos de Big Data.
DAVENPORT (2014) sugere uma pequena lista do volume de informações que
compõe o Big Data (dados referentes a 2014):
 Trinta bilhões de unidades de conteúdo são acrescentadas ao facebook por mês
por mais de um bilhão de usuários.
 Usuários do Youtube assistem mais de 2 bilhões de vídeos por dia.
 Os usuários do Google realizaram mais de 5 bilhões de buscas por dia em
2011.
 E por aí vai.
DAVENPORT (2014) infere que as instituições que contarem em suas fileiras com
indivíduos que tenham perfil analítico conquistarão grande vantagem sobre seus principais
concorrentes. O autor inclusive afirma que todos em uma instituição deveriam ter perfil
analítico. Da recepção aos andares de cima.
 42

O Big Data revolucionou praticamente todas as áreas. Quem assistiu ao filme

Moneyball (2011) com Brad Pitt sabe como o estudo dos dados foram cruciais para a série de
vitórias obtida pelo time de beisebol profissional Oakland Athletics. A partir da bem-sucedida
experiência contada no filme convencionou-se usar estatística como suporte por vários
esportes, do futebol ao basquete. O site mantido pela Universidade Federal de Minas Gerais
(MATEMÁTICA UFMG, 2011) faz um trabalho de previsão de resultados no futebol fazendo
uso de estatística.
DAVENPORT (2014) denomina de analítica o uso amplo de dados, de análise
estatística e quantitativa, de modelos explanatórios e preditivos para orientar decisões e
agregar valor. O autor subdivide a analítica em três:
Descritiva, preditiva e prescritiva.
A analítica descritiva passa pela coleta, organização, tabulação e a apresentação dos
dados do assunto que está sendo estudado. Basicamente é a apresentação de um relatório
(reporting) sobre o assunto. De certa forma superficial já que não busca explicar resultados
nem emite uma opinião sobre o que poderá acontecer no futuro. Mas não menos importante já
que algumas empresas não tem a menor ideia da situação em que se encontram. Como estão
as vendas? Quantos cliente entram na loja por dia? Quantos sanduíches de queijo são
vendidos e cada fim de semana? São perguntas que poderiam ser respondidas com uma
análise descritiva.
Já a analítica preditiva vai um pouco mais além quando se propõe a usar os dados do
passado para prever o futuro.

Primeiro identifica as associações entre as variáveis e depois prevê a possiblidade

de um fenômeno, por exemplo, saber se um cliente reagirá de modo positivo à
propaganda de um produto e o comprará (DAVENPORT, 2014).

O algoritmo FICO que é constituído de um número de 3 dígitos entre 300 e 850 mostra
um instantâneo da situação financeira de um possível cliente em certo ponto de sua vida
financeira. Se um cliente se apresenta para comprar a crédito um automóvel ou apartamento,
os analistas da FICO podem avaliar o risco da transação e autorizarem ou não
(CORPORATION, 2016).

O engenheiro Bill Fair e o Matemático Isaac Earl fundam a FICO em 1956

baseados no princípio de que os dados utilizados de forma inteligente, podem
melhorar as decisões de negócios (CORPORATION, 2016).
 43

A analítica prescritiva busca não apenas identificar o que aconteceu, mas com base nas
descobertas procura sugerir um curso de ação. Por exemplo qual tipo de investimento traria
mais vantagens financeiras a um banco.

4.2. METODOLOGIAS ESTATÍSTICAS PARA TOMADA DE DECISÃO

Como já citado anteriormente é possível tomar decisões com base em intuição, mas
não é recomendado. Boas decisões necessariamente precisam vir acompanhadas ou
embasadas em bons dados. Se a vida real fosse como no filme Minority Report, grande filme
de Steven Spielberg estrelado pelo astro de block busters Tom Cruise. No filme era possível
prever o futuro e saber com antecedência o que iria acontecer.

Washington, 2054. O assassinato foi banido, pois há a divisão pré-crime, um setor

da polícia onde futuro é visualizado através de paranormais, os precogs, e o culpado
é punido antes do crime ter sido cometido (CINEMA, 2002).

No mundo em que vivemos precisamos estar cercados de todas as informações

necessárias para que boas decisões sejam tomadas. Uma boa introdução para falar da análise
estatística denominada correlação.

4.3. CORRELAÇÃO

A correlação deverá medir o grau no qual dois fenômenos ou variáveis terão forte
relação entre si. Com certeza existe uma correlação entre altas temperaturas e a venda de
cerveja. Se a temperatura sobe a venda de cerveja também sobe (G1, 2016).

Extensão em que duas ou mais variáveis se relacionam entre si. O grau de

relacionamento se expressa como coeficiente de correlação que varia de -1,0 a +1,0
(DAVENPORT, 2014, p. 80).

Correlação = +1 (correlação positiva que significa que se uma variável cresce a outra
acompanha este crescimento.
Correlação = 0 (zero) (não existe correlação). Por exemplo a altura do indivíduo com a
nota obtida em um exame de matemática. Nenhuma relação.
Correlação = -1 (correlação negativa, se uma variável sobe a outra variável deverá
cair. Como exemplo o número de horas de academia versus a queda do peso ou percentual de
gordura. Tecnicamente quanto mais horas de exercício menor o peso do praticante.
Na seguinte tabela é mostrado uma correlação positiva entre idades e percentual de
gordura corporal, meramente ilustrativa.
 44

Tabela 13 - Idade x percentual de gordura - Fonte: do autor

%
Idade Gordura
27 7,8
23 9,5
27 17,8
41 25,9
23 26,5
49 27,2
47 27,4
54 28,8
57 41,2

Após o cálculo da correlação o resultado é 0,8 que é muito próximo de 1 indicando

uma forte correlação positiva que poderíamos traduzir por quanto mais avançada a idade, a
Figura 9 - Gráfico demonstrativo da tabela - Fonte: do autor

tendência é aumentar o percentual de gordura.

O gráfico ilustra bem a tendência de crescimento. Seria possível desenhar uma linha
reta ascendente confirmando a correlação positiva.
Não podemos esquecer que correlação não determina causalidade. O fato de haver
uma correlação não significará jamais que uma variável determina a outra. Vendas de sorvete

Figura 10 - Gráfico meramente ilustrativo - Fonte: do autor

 45

aumentam no verão assim como casos de conjuntivite. Existe correlação entre as duas
variáveis, mas não existem relação entre elas.
A título de curiosidade o site Correlations Spurious (VIGEN, 2014) mostra uma série
de correlações que não são causais. Na figura a falsa relação entre os gastos com ciência
relacionados com o índice de mortes por suicídio.

Figura 11 Gráfico de correlação - Fonte: (VIGEN, 2014)

4.4. A TOMADA DA DECISÃO DA NETFLIX

O assinante comum da Netflix termina de ver um filme na plataforma e imediatamente

a empresa sugere um filme do qual ele vai gostar e que até daria 5 estrelas ao final da
exibição. Como a Netflix infere quais filmes o assinante gostaria de assistir? Em um nível
estatístico mais básico a Netflix está usando a correlação.
O Professor WHEELAN (2016) exemplifica que a Netflix não conhece o assinante
(pelo menos não em nível pessoal) mas conhece quais filmes ele gostou no passado por que
foram avaliados por ele. A empresa compara as avaliações de um cliente com as de outros
clientes que tenham tido avaliações altamente correlacionadas positivamente. O que vai
significar que estes outros clientes gostarão dos mesmos filmes que o primeiro. Encontrada a
correlação a Netflix faz a recomendação de filmes que ela entende que seriam do gosto do
cliente.

4.5. ANÁLISE DE REGRESSÃO LINEAR

A análise de regressão está intimamente ligada com a correlação já que também

observa o comportamento entre duas variáveis, mas enquanto a correlação determina a força
da ligação entre as variáveis, a regressão linear procura traçar uma reta que descreva o
relacionamento entre as variáveis.
 46

Especificamente, a análise de regressão nos permite quantificar a relação entre uma

variável específica e um resultado que nos interessa enquanto controlamos outros
fatores (WHEELAN, 2016, p. 222).

É possível usar a análise de regressão para prever resultados. Foi descoberta por Sir
Francis Galton (1822-1911) quando estudava como a altura dos pais poderia influenciar a
altura dos filhos. Seus dados mostraram que em média pais mais baixos tinham filhos mais
altos e pais altos teriam filhos mais baixos. Chamou de regressão à mediocridade (MILTON,
2010).

4.6. TOMADA DE DECISÃO SOBRE AUMENTO DE SALÁRIO

Uma consultoria fictícia precisa aconselhar os funcionários de uma empresa como

pedirem aumento. Eles podem aguardar uma oferta dos gestores ou podem arriscar e fazer um
pedido.

Um histograma é similar ao gráfico em barras utilizado para descrever variáveis

nominais em que se usam categorias criadas artificialmente para segmentar a
variável (BECKER, 2015, p. 54).

Para exemplificar, o histograma a tabela a seguir foi criado com idades de um grupo de
400 pessoas entre 20 e 53 anos de idade.
Figura 12 Histograma - Fonte: do autor

Note que a distribuição das idades dos indivíduos é um tanto assimétrica sendo que
temos poucos colaboradores com idade abaixo de 29 anos. Os mais jovens e os mais maduros
são a minoria dos colaboradores. Temos muitos indivíduos na faixa etária de 31 e 43 anos. O
histograma permite uma boa análise em grupos de valores. Usando histogramas poderíamos
avaliar quais as faixas de disciplinas em que alunos de uma universidade matriculam-se mais.
 47

Voltando ao trabalho da consultoria o próximo histograma exibe os aumentos obtidos

pelos funcionários sem negociação com a empresa. A empresa definiu o que o colaborador
deveria receber.
Figura 13 Histograma de aumentos - Fonte: (MILTON, 2010)

Observe que a maior parte dos funcionários obteve aumentos de salário na faixa entre
5% e 6%. Parece um bom número para solicitar sem correr riscos.
Mas seguindo adiante podemos criar um gráfico de dispersão comparando duas
variáveis que estão disponíveis para consulta pela consultoria: aumento solicitado e aumento
recebido. Estes dados podem abastecer a consultoria com informações de maior exatidão que
sugiram um percentual satisfatório de aumento que poderá ser solicitado sem que o
colaborador corra o risco de parecer ir com muita sede ao pote.
Figura 14 Gráfico de dispersão - Fonte: (MILTON, 2010)

O gráfico agora mostra seguramente que o percentual de aumento mais requisitado e

recebido por parte da empresa é o valor de 12%. O que já dá uma boa margem de segurança
para o colaborador que queira arriscar receber maior aumento no seu salário.
 48

4.7. ANÁLISE DE DADOS E TOMADA DE DECISÃO SOBRE DADOS DO

FACEBOOK

Inegável que o Facebook monopolizou o uso da Internet. Inclusive muitos sites

relevantes que tinham maior audiência cederam espaço para o Facebook (REDAÇÃO, 2014).
Isso fez com que muitas empresas migrassem suas páginas para o a rede social. Evidente que
não basta compartilhar conteúdos e aguardar curtidas, é preciso saber qual o melhor horário
para as postagens, qual postagem obteve maior número de curtidas. Que tipo de conteúdo a
audiência prefere? Vídeo, fotos ou texto?
É possível saber o que está acontecendo para só então tomar as melhores decisões.
Postar conteúdos que são mais simpáticos ao público pode melhorar a audiência atingindo
mais pessoas e consequentemente gerar maior volume de negócios.
Usando um programa de BI foram extraídos do facebook os dados relativos a curtidas
e comentários nas postagens. As conclusões estão nas linhas a seguir.

4.8. CONTEÚDOS MAIS VISTOS

Uma olhada atenta no gráfico de cascata e é possível perceber que das mais de 20 mil
curtidas o conteúdo onde existe mais engajamento são fotos. Mas isso não constitui nenhuma
surpresa conforme pesquisa da Social Bakers (BAKERS, 2014).
Das mais de 20 mil curtidas cerca de 17 mil são em imagens ou 84% das curtidas.
Uma boa dica seria continuar postando imagens mais elaboradas. Caso seja um restaurante,
fotos de comida podem funcionar muito bem.
Figura 15 curtidas por categoria - Fonte:
do autor

Observe-se que vídeos tem audiência muito baixa, cerca de 3% das curtidas e/ou
visualizadas. Dependendo do tipo de negócio da empresa, poderia ser investido mais tempo e
cuidado com vídeos mais elaborados. De qualquer forma existe espaço para crescer.
 49

O próximo gráfico combinado entre linhas e colunas mostra um comparativo entre

conteúdo postado que é indicado pela linha preta e as curtidas que são representadas pelas
Figura 16 Curtidas por hora - Fonte: do autor

colunas, hora a hora. A ideia aqui é saber em qual hora do dia a página é mais curtida até para
que o administrador se programe para postar no horário em que os usuários estão curtindo.
Uma rápida olhada e se perceberá que os horários onde os conteúdos recebem mais cliques
são as 6 horas da manhã e as 16 horas. Erroneamente as postagens da página estão se
concentrando as 11 horas e as 21 horas. Primeira decisão será trocar o horário da postagem.
Outra observação nos mesmos moldes da anterior é quanto ao dia da semana. Qual é o
dia em que a página recebe mais curtidas? É preciso descobrir para priviliegiar este dia com
mais postagens. De acordo com o gráfico os dias de maior curtida na página são domingo,
segunda-feira e quarta-feira. Observe que salvo o domingo na segunda e na quarta quase nada
de conteúdo novo é postado. Será preciso mudar isso.
Figura 17 curtidas por dia da semana - Fonte: do
autor

Para finalizar ainda será necessária uma examinada nas curtidas da página. É
importante descobrir quem mais curte as postagens da página pois este é um dos clientes que
Figura 18 Nuvem de palavras - Fonte: do autor
 50

por ser fã da empresa pode engajar mais usuários ao empreendimento. Uma alternativa é usar
uma nuvem de palavras que mostrará com fonte de tamanho maior quem são os maiores
curtidores.
Uma boa recomendação seria incentivar os curtidores com prêmios ou brindes para
que continuem sendo fãs da página.
 51

5. CONSIDERAÇÕES FINAIS

O autor considera que todos os objetivos propostos foram atingidos, tendo permitido o
acesso ao mundo do Business Intelligence ao público leigo. Conseguiu demonstrar a
importância da análise de dados nas organizações e como as decisões que devem ser tomadas
precisam ser embasadas em dados concretos.
Acredita que ainda existe um longo caminho a percorrer para que as pessoas e
organizações se deem conta que a análise de dados é muito importante e pode afetar
diretamente as decisões que são tomadas diariamente.
 52

6. BIBLIOGRAFIA

BAKERS, S. Statistics. Social Bakers, 2014. Disponivel em: <https://www.socialbakers.com/statistics/>.

Acesso em: 01 nov. 2016.

BECKER, J. L. Estatística básica: transformando dados em informação. Porto Alegre: Bookman, 2015.

BEIGHLEY, L. Use a Cabeça: SQL. 1ª. ed. Rio de Janeiro: Altabooks, 2008.

BOTELHO, ; FILHO,. Conceituando o termo l Intelligence: origem e principais objetivos. Universidade

Federal do Paraná. Paraná, p. 6. 2014.

CENTRAL, B. N. A Arte da Guerra. Biblioteca digital mundial, 2014. Disponivel em:

<https://www.wdl.org/pt/search/?contributors=Sunzi%2C%20544-496%20BCE>. Acesso em: 13
agosto 2016.

CHURCHER, C. Introdução ao Design de Bancos de Dados. 1ª. ed. Rio de Janeiro: Altabooks, 2009.

CINEMA, A. Filmes. Adoro cinema, 2002. Disponivel em:

<http://www.adorocinema.com/filmes/filme-34917/>. Acesso em: 30 out. 2016.

CORDEIRO, K. F. D. Modelagem multidimensional de dados. Unyleya. Brasília, p. 79. 2015.

CORPORATION, F. I. Fico, 2016. Disponivel em: <http://www.fico.com/br/>. Acesso em: 30 out. 2016.

DAVENPORT, T. H. Dados Demais. Rio de Janeiro: Elsevier, 2014.

ÉPOCA. Época Negócios, 2013. Disponivel em:

<http://epocanegocios.globo.com/Informacao/Acao/noticia/2013/08/jornalista-americana-vira-
suspeita-de-terrorismo-por-buscar-panela-de-pressao-na-internet.html>. Acesso em: 22 out. 2016.

FILHO, T. L. BI - Business Intelligence no Excel. Rio de Janeiro: Novaterra, 2012.

G1. economia. G1, 2016. Disponivel em: <http://extra.globo.com/noticias/economia/verao-carnaval-

aumentam-venda-de-bebidas-no-gpa-18591482.html>. Acesso em: 30 out. 2016.

GUIMARÃES, C. C. Fundamentos de Bancos de dados: Modelagem, projeto e linguagem SQL. São

Paulo: Editora da Unicamp, 2003.

GUNTHER, M. O Fator Sorte. Rio de Janeiro: Best Business, 2013.

HEUSER, C. A. Projeto de banco de dados. 6ª. ed. Porto Alegre: Bookman, 2009.

HUFF, D. Como mentir com estatística. Rio de Janeiro: Intrínseca, 2016.

LIMA, C. A. L. Estudo de Caso – Toyota USA. Blog do Lito - Data Warehouse/Business Intelligence,
2011. Disponivel em: <https://litolima.com/2011/03/05/estudo-de-caso-toyota-usa/>. Acesso em: 14
out. 2016.

LOH, S. BI na Era do Big Data para Cientistas de Dados. Porto Alegre: Amazon, 2014.

MACHADO, F. N. R. Banco de Dados: Projeto e Implementação. 2ª. ed. São Paulo: Érica, 2008.

MARTINEZ, M. Sistemas de informação. Infoescola - navegando e aprendendo, 2016. Disponivel em:

<http://www.infoescola.com/administracao_/sistema-de-informacao-gerencial/>. Acesso em: 12
agosto 2016.
 53

MATEMÁTICA UFMG, D. D. Probabilidades no futebol, 2011. Disponivel em:

<http://www.mat.ufmg.br/futebol/index.html>. Acesso em: 29 out. 2016.

MIKKELSON, D. Ice cream cone car. Snopes, 1998. Disponivel em:

<http://www.snopes.com/autos/techno/icecream.asp>. Acesso em: 08 agosto 2016.

MILTON, M. Use a cabeça análise de dados. Rio de Janeiro: Altabooks, 2010.

MONEYBALL. Direção: Bennett Miller. Produção: Michael DeLuca, Michael De Luca, Rachael Horovitz
Brad Pitt. Intérpretes: Philip Seymour Hoffman, Robin Wright, Jonah Hill Brad Pitt. [S.l.]: Sony Pictures.
2011.

MOURA, G. A. C. D. Quatro cantos. Lendas e folclore da Internet. As pulhas virtuais, 2015. Disponivel
em: <http://www.quatrocantos.com/lendas/136_pontiac_baunilha.htm>. Acesso em: 08 Agosto
2016.

PERIARD, G. Sobre Administração, 2009. Disponivel em: <http://www.sobreadministracao.com/o-

que-e-o-5w2h-e-como-ele-e-utilizado/>. Acesso em: 19 out. 2016.

PINHO, F. L. G. C. D. Aplicações em ETL. Instituto de Gestão em Tecnologia da Informação. Minas

Gerais, p. 43. 2016.

PITON, R. Rafael Piton. Youtube, 2016. Disponivel em: <https://www.youtube.com/watch?

v=8X4q5NTvKf0>. Acesso em: 09 agosto 2016.

REDAÇÃO, D. Tecnologia. Veja, 2014. Disponivel em: <http://veja.abril.com.br/tecnologia/brasil-

passa-russia-e-se-consolida-como-a-5a-maior-audiencia-de-internet-do-mundo/>. Acesso em: 01 nov.
2016.

SANCHEZ, T. Artigo - Operações. Varejista, 08 set. 2015. Disponivel em:

<http://varejista.com.br/artigos/operacoes/1383/como-o-bi-pode-ajudar-as-empresas-do-varejo>.
Acesso em: 10 out. 2016.

SERPA, S. S. Técnicas e ferramentas OLAP. Unyleya. Brasília, p. 68. 2015.

SILBERSCHATZ, A. Sistema de Banco de Dados. 3ª. ed. São Paulo: Pearson Makron Books, 1999.

SILVER, N. O SInal e o Ruído. Rio de Janeiro: Intrínseca, 2013.

SOUSA, L. Artigos. Administradores, 17 ago. 2016. Disponivel em:

<http://www.administradores.com.br/artigos/tecnologia/os-riscos-das-perdas-de-dados-
corporativos/97453/>. Acesso em: 16 out. 2016.

TEIXEIRA, D. Docplayer, 2015. Disponivel em: <http://docplayer.com.br/>. Acesso em: 12 out. 2016.

TONSIG, S. L. Mysql - Aprendendo na Prática. Rio de Janeiro: Ciência Moderna, 2006.

VIANNA, F. Dashboards em Excel. São Paulo: Scortecci, 2016.

VIGEN, T. Spurious Correlations. Tyler Vigen, 2014. Disponivel em:

<http://www.tylervigen.com/spurious-correlations>. Acesso em: 22 out. 2016.

WHEELAN, C. Estatística: o que é, para que serve, para que serve, como funciona. 1ª. ed. Rio de
Janeiro: Zahar, 2016.

ZAIDAN, F. H. Análise Dimensional e Data Warehouse. Instituto de Gestão em Tecnologia da

Informação. Minas Gerais, p. 29. 2016.
54