SUMÁRIO

UNIDADE 1 – Introdução ....................................................................................................... 3

Conceitos fundamentais de modelo de dados ........................................................................................................ 3
Conceitos fundamentais de modelo de dados alternativos .............................................................................. 11

UNIDADE 2 – NoSQL............................................................................................................ 24
Conceitos fundamentais .............................................................................................................................................. 24
Funcionamento Interno ............................................................................................................................................... 27
Tipos de Armazenamento............................................................................................................................................ 31

UNIDADE 3 – Data Warehouse.......................................................................................... 33

Modelagem Multimensional ....................................................................................................................................... 33
Data Stage, Data Marts e Data Lakes ....................................................................................................................... 39
Considerações Finais ..................................................................................................................................................... 49

UNIDADE 4 – Data Mining ................................................................................................. 51

Descoberta de Conhecimento .................................................................................................................................... 51
Principais Algoritmos..................................................................................................................................................... 57
Considerações Finais ..................................................................................................................................................... 64

UNIDADE 5 – Cenários de Utilização ................................................................................ 65

Cenários comuns de utilização dos modelos alternativos ................................................................................. 65
Como evitar modismos................................................................................................................................................. 66
Boas práticas de modelagem...................................................................................................................................... 66
Considerações Finais ..................................................................................................................................................... 67

Referências ........................................................................................................................................... 68

1
Apresentação
Everton Gomede
Doutorando em Engenharia Elétrica/Computação pelo Programa de Pós-
graduação da Faculdade de Engenharia Elétrica e de Computação (FEEC) da
Universidade Estadual de Campinas (UNICAMP). Mestre em Ciência da
Computação pela Universidade Estadual de Londrina. MBA (Master of Business
Administration) em Neurogestão pela Fundação Getúlio Vargas. MBA em
Gerenciamento de Projetos pela FGV. Especialista em Engenharia de Software e
Banco de Dados pela Universidade Estadual de Londrina. Graduado em
Processamento de Dados. Sun Certified Programmer for Java 2 Platform 1.4 e
ITIL® Foundation Certificate in IT Service Management. Experiência de mais de
10 anos na área de TI em arquitetura de software, engenharia de software,
mapeamento de processos de negócio, gerenciamento de projetos,
desenvolvimento de sistemas transacionais e de suporte à decisão. Experiência
em projetos nacionais e internacionais em instituições financeiras e empresas
de desenvolvimento de software. Professor de cursos de pós-graduação em
universidades públicas e privadas. Membro do PMI 1580489. Publicações
nacionais e internacionais. Proficiência em inglês atestada pelo TOIEC e TOEFL.
Áreas de Interesse: Estrutura de Dados e Organização de Arquivos, Análise de
Sistemas e Engenharia de Software, Lógica de Programação, Redes de
Computadores, Linguagem de Programação, Administração de Banco de Dados,
Governança de TIC (ITIL/CobIT), Data Warehouse, Data Mining, Big Data,
Gerenciamento de Projetos, Gerenciamento de Processos de Negócio
(BPM/BPMN™), Pesquisa Operacional, Algoritmos, Sistemas de Suporte à
Decisão, Data Science e Machine Learning.

Ricardo Satin
Mestre em Engenharia de Software pela UTFPR; Especialista em Computação
pela Unicesumar; Graduado em Computação pela Universidade Estadual de
Maringá -UEM; MBA em Gerenciamento de Projetos pela FCV. Profissional
certificado em: gerenciamento de projeto pelo P.M.I. (profissional PMP);
Gerenciamento ágil de projetos (SCRUM); Gerenciamento de serviços de T.I.
(ITIL). Professor de ensino superior para cursos da área de T.I. e pós-graduação
para diversas áreas. Atua como consultor em gerenciamento de projetos;
processos de negócio; melhoria de processos e machine learning.

2
UNIDADE 1 – Introdução

Objetivos de aprendizagem
 Conceitos fundamentais de modelos de dados
 Conceitos fundamentais de modelos de dados alternativos
 Utilização e tendências
 Padrões de projetos

Conceitos fundamentais de modelo de dados

A evolução dos bancos de dados e princípios de banco de dados começou

com o uso de arquivos sequenciais básicos de dados para processamento de
informações. Como o suporte ao sistema cresceu em sistemas de
gerenciamento de arquivos e como vários aplicativos desenvolvidos em tais
arquivos, problemas básicos se tornaram aparentes, levando a vários princípios
fundamentais de banco de dados. Esses princípios orientaram o
desenvolvimento de sistemas completos de gerenciamento de banco de dados
que agora estão disponíveis comercialmente. Descreveremos a evolução desses
sistemas à medida que os princípios básicos do banco de dados forem
integrados aos SGBD modernos (HAN, 2006).
Na Figura 1, o primeiro relacionamento (1) é aquele em que as estruturas
de aplicação do usuário eram da mesma forma que as estruturas de arquivos de
arquivos. Arquivos de dados são conjuntos de registros relacionados conforme
percebidos por um usuário e as estruturas de arquivos são a realização física
real dessas estruturas. Tal mapeamento direto, claro, causou muitos problemas,
pois quaisquer mudanças nos dispositivos de arquivo, organização, usos, etc.
exigiam mudanças correspondentes nos programas de aplicação. O segundo
relacionamento (2) na figura mostra que os recursos de gerenciamento de
dados estão agora disponíveis e, portanto, a organização das estruturas no
programa aplicativo não precisa mais ser idêntica à organização do arquivo. Ou
seja, há um grau de independência alcançado desde que o sistema de
gerenciamento de dados está mapeando entre eles. Com os dados nos arquivos
de arquivamento não mais dedicados a aplicativos e programas específicos, as
alterações nas estruturas de arquivos não exigiam alterações nas estruturas de
dados dos programas de aplicativos.
Finalmente, como vemos no mapeamento rotulado (3) na Figura 1, em
um ambiente de banco de dados verdadeiro, as estruturas de aplicativo podem
3
acessar dados de qualquer lugar da organização de arquivos, se os
mapeamentos apropriados estiverem disponíveis. Isso, obviamente, alcança um
grau ainda maior de independência e nos levará a descrever a estrutura de um
sistema completo de gerenciamento de banco de dados (HAN, 2006).

Figura 1 – Estrutura de dados

Arquitetura de três níveis para sistemas de gerenciamento de banco de dados

4
 Com a descrição das relações entre as estruturas como motivação,
podemos agora discutir a arquitetura de três níveis de um sistema de
gerenciamento de banco de dados completo (SGBD). Os níveis que são
mantidos em tal sistema servem para fornecer independência de estruturas do
tipo que descrevemos. Esta organização é ilustrada na Figura 2.
O objetivo da organização de três níveis é a separação dos aplicativos do
usuário e do banco de dados físico. Isso também é conhecido como a
arquitetura ANSI/SPARC, após o comitê que o propôs. Primeiro no nível, o nível
físico possui um esquema interno, que descreve a estrutura de armazenamento
físico do banco de dados. Esse esquema usa um modelo de dados físico e
fornece detalhes de armazenamento de dados e caminhos de acesso para o
banco de dados (HAN, 2006).
O nível lógico descreve o modelo lógico, que é a visão da estrutura do
banco de dados inteiro para todos os usuários. Esse esquema oculta os detalhes
dos usuários e se concentra na descrição de entidades, tipos de dados,
relacionamentos, operações do usuário e restrições. O modelo lógico é
frequentemente usado para caracterizar um banco de dados específico.
Descreveremos a variedade de modelos de dados nesse nível que foram
desenvolvidos de hierárquico para relacional para o modelo de dados orientado
a objeto. Como será visto, a maioria das questões relativas à incerteza de
modelagem são descritas nesse nível e, portanto, a maior parte da ênfase em
nossa descrição será desse nível.
O nível externo ou de exibição inclui vários esquemas externos ou
visualizações do usuário. Cada esquema externo descreve a parte do banco de
dados em que um determinado grupo de usuários está interessado e oculta o
restante do banco de dados desse grupo de usuários.

5
 Figura 2 – Estrutura de 3 níveis

Então, em geral, um SGBD fornece uma integração de várias instalações.

Ele fornece suporte para a definição de estruturas lógicas de entidades e
relacionamentos que compõem o banco de dados. Isso é geralmente
especificado por uma Linguagem de Definição de Dados (DDL). Também
discutiremos em breve o processo real de design de banco de dados no qual as
entidades e seus relacionamentos são especificados. Também são fornecidas
linguagens de manipulação de dados (geralmente incorporadas em um
programa aplicativo) e/ou linguagens de consulta autônomas (HAN, 2006).
Observe que os três níveis são apenas descrições de dados. Os dados
reais residem na mídia de armazenamento no nível físico. Assim, para obter
respostas às solicitações do usuário no nível externo, a solicitação deve passar
pelos três níveis. Os processos de transformação de solicitações e resultados
entre níveis são chamados de mapeamentos. Esses mapeamentos podem ser
demorados, mas fornecem o suporte básico para fornecer a independência de
dados físicos e lógicos discutida na próxima seção.

Independência de dados

6
 O conceito de independência de dados é ilustrado pelas relações entre os
níveis da arquitetura ANSI/SPARC. Há independência entre os níveis se for
possível alterar o esquema em um nível de um sistema de banco de dados sem
ter que alterar o esquema no próximo nível mais alto. Dois tipos de
independência de dados são geralmente distintos, independência de dados
lógica e física.

Independência de dados lógicos

A independência de dados lógicos permite que o esquema lógico seja

modificado sem a necessidade de alterar esquemas externos ou programas
aplicativos. Portanto, o esquema lógico pode ser modificado para expandir o
banco de dados (adicionando um novo tipo de registro ou item de dados) ou
para reduzir o banco de dados (removendo um tipo de registro ou item de
dados). Neste último caso, os esquemas externos que se referem apenas aos
dados restantes não devem ser afetados. Somente a definição de visualização e
os mapeamentos precisam ser alterados em um DBMS que ofereça suporte à
independência de dados lógicos. Os programas aplicativos que fazem referência
às construções do esquema externo devem operar como antes. Depois que o
esquema conceitual passa por uma reorganização lógica, as mudanças nas
restrições também podem ser aplicadas ao esquema conceitual sem afetar os
esquemas externos.

Independência de Dados Físicos

Como também há um mapeamento entre o esquema que representa o

modelo lógico ou conceitual e a mídia real na qual os dados são fisicamente
armazenados, é possível alterar o esquema interno sem ter que alterar os
esquemas nos níveis acima. Mudanças no esquema interno seriam necessárias
se os arquivos físicos tivessem que ser reorganizados. Por exemplo, criando
estruturas de acesso adicionais, o desempenho de recuperações ou
atualizações pode ser significativamente melhorado. Se os mesmos dados de
antes permanecerem no banco de dados, não será necessário alterar o
esquema lógico/conceitual. Assim, fornecer um caminho de acesso para
melhorar a recuperação de registros por determinados campos comumente
usados não deve exigir uma consulta como listar todos os registros de um
determinado tipo a ser alterada, embora a consulta possa ser executada de
forma mais eficiente pelo SGBD utilizando o novo caminho de acesso. Como a

7
independência de dados físicos requer o divórcio de um aplicativo apenas das
estruturas de armazenamento físico específicas, geralmente é mais fácil obter
resultados do que a independência de dados lógicos.

Princípios de Redundância e Integridade

Capacidade de dados

Uma das primeiras motivações para a criação de instalações de

gerenciamento de dados foi que, em uma determinada organização, vários
departamentos podem precisar de acesso a grande parte das mesmas
informações. Assim, os departamentos de pessoal, contabilidade e
planejamento precisavam de informações muito semelhantes sobre os
funcionários, mas por diferentes razões e, portanto, utilizavam diferentes
programas de acesso. Geralmente, esses departamentos mantêm seus próprios
arquivos de dados. Isso, obviamente, pode se tornar muito caro em termos de
armazenamento e compartilhamento de recursos funcionais. A integração
desses conjuntos de dados independentes eliminaria essa redundância e, por
meio do projeto correto do modelo lógico e dos esquemas de usuários
individuais, ainda permitiria que cada aplicativo operasse como antes,
independentemente dos outros (HAN, 2006).

Integridade

Uma consequência adicional da situação descrita acima envolvendo

arquivos de dados separados é o problema da integridade dos dados. Como um
determinado departamento atualizaria seu arquivo, como a atualização contábil
dos salários dos indivíduos para refletir os aumentos, essas alterações não
seriam refletidas imediatamente nos outros arquivos de dados e, portanto, o
aplicativo de planejamento poderia estar operando com informações salariais
inválidas. Com o passar do tempo, seria possível que a diferença de dados se
propagasse nos arquivos produzindo dados significativamente corrompidos que
seriam muito difíceis de restaurar para valores válidos. Portanto, uma
abordagem uniforme ao gerenciamento de dados aprimora o gerenciamento de
integridade, evitando inconsistências entre várias cópias do mesmo ou de dados
relacionados. Existem, é claro, outros aspectos relacionados à integridade de
dados que também são mais viáveis em um SGBD, como a validação de dados
sobre entrada e mudanças. Os problemas de integridade descritos aqui são

8
obtidos diretamente do gerenciamento integrado dos dados e não da
semântica de dados. Em geral, o termo integridade abrange ambos os aspectos,
isto é, preservar a consistência dos dados e sua correção.

Processo Geral

O processo geral de design de banco de dados é análogo ao processo de

desenvolvimento de software, conforme visto pelos engenheiros de software,
no qual um passa por vários estágios, como análise de requisitos até a produção
final do código.
O objetivo do processo de design de banco de dados é capturar os
aspectos essenciais de algumas empresas do mundo real para as quais se deseja
construir um banco de dados. A Figura 3 mostra uma descrição simplificada do
processo de design do banco de dados. O primeiro passo é a coleta e análise de
requisitos, na qual os projetistas de bancos de dados podem entrevistar
possíveis usuários do banco de dados para entender e documentar seus
requisitos de dados. O resultado dessa etapa é um conjunto de requisitos de
usuários redigidos de forma concisa.
Quando todos os requisitos foram coletados e analisados, a próxima
etapa é criar um esquema conceitual para o banco de dados, usando um
modelo de dados conceitual de alto nível. O esquema conceitual é uma
descrição concisa dos requisitos de dados dos usuários e inclui descrições
detalhadas dos tipos de dados, relacionamentos e restrições. Como neste nível
não há representação de detalhes de implementação, é geralmente mais fácil
entender as descrições que pode então ser compartilhado com usuários não
técnicos. O esquema conceitual de alto nível também pode ser usado como
referência para garantir que todos os requisitos de dados dos usuários sejam
atendidos e que os requisitos não incluam conflitos. Essa abordagem permite
que os designers de banco de dados se concentrem em especificar as
propriedades dos dados, sem se preocupar com detalhes de armazenamento.
Depois que o esquema conceitual é projetado, as operações básicas do
modelo de dados podem ser usadas para especificar transações de alto nível
correspondentes às operações definidas pelo usuário identificadas durante uma
análise funcional. Assim, pode-se verificar que o esquema conceitual atende a
todos os requisitos funcionais identificados e que alterações ao esquema
podem ser feitas se alguns requisitos funcionais não forem especificados no
esquema inicial (HAN, 2006).

9
 Figura 3 – Processo de criação de modelos de dados

A próxima etapa é o design do modelo lógico, que pode ser suportado

por uma abordagem específica usando um SGBD comercial. Portanto, o
esquema conceitual é mapeado do modelo de dados de alto nível para um
modelo de dados lógicos. Este é o nível médio, ou nível lógico, mostrado no
diagrama ANSI da Figura 2. Portanto, esse resultado talvez seja um esquema de
modelo relacional ou orientado a objeto. Geralmente, isso é a representação do
banco de dados que será mostrado quando queremos ilustrar um aplicativo
específico ou fornecer um exemplo de uma extensão de banco de dados
específica para representar algum aspecto de incerteza.
Finalmente, o último passo é a fase de design do banco de dados físico,
embora, é claro, com um SGBD comercial, isso já esteja praticamente
formulado. No entanto, pode haver certas escolhas a serem feitas em relação às
estruturas internas de armazenamento e organizações de arquivos para o
banco de dados com base em critérios de desempenho e requisitos de

10
armazenamento e acesso. Em geral, não trataremos do processo de design
nesse nível em nossas discussões (HAN, 2006).

Conceitos fundamentais de modelo de dados alternativos

Modelos hierárquicos e de rede

Nesta seção, apresentaremos brevemente os conceitos básicos dos

modelos de banco de dados para fins de discussão geral. No entanto, conforme
necessário em capítulos posteriores, apresentaremos descrições mais formais e
detalhadas desses modelos, em particular, quando necessário, para descrever
os detalhes das várias abordagens de conjuntos difusos para o design e a
construção de bancos de dados.
Historicamente, à medida que as abordagens aos bancos de dados
evoluíram, foram criados modelos lógicos mais bem definidos do que estruturas
de arquivos. Em particular, os primeiros desenvolvidos eram conhecidos como
modelos hierárquicos e de rede. Nestes, os relacionamentos entre os dados
foram representados como uma estrutura em árvore para a estrutura
hierárquica ou mais geral do grafo para o modelo de rede. O modelo
hierárquico usou estruturas de árvore hierárquica nas quais cada hierarquia
representa um conjunto de registros relacionados (HAN, 2006).

Modelo de dados de rede

O modelo de dados de rede usa tipos de registro para representar dados

e uma representação direta de um relacionamento um-para-muitos chamado
de tipo de conjunto. Por exemplo, se o banco de dados ambiental discutido
anteriormente fosse usado para classificar os vários locais quanto aos tipos de
terras, tais como pantanoso, agrícola, suburbano etc., haveria uma relação um-
para-muitos entre cada tipo de terra e as parcelas de terra daquele tipo. O tipo
de terra seria o tipo de registro do proprietário e as parcelas de terra, os tipos
de registro do membro. Na Figura 4, vemos um conjunto de tipos de terrenos
com registros como pantanoso, suburbano, agrícola, etc. Cada um desses
registros de membros é, eles próprios, proprietários de conjuntos de registros
de parcelas de terra específicas do tipo de terra determinado.

11
 Figura 4 – Exemplo de modelo de dados em rede

#ATENÇÃO#
Existem uma variedade de modelos de dados. Escolha o que se adapte mais ao
problema a ser resolvido e não o contrário.
#ATENÇÃO#

Bases de dados difusas (Fuzzy)

Nesses modelos, o processo de consulta exige uma travessia específica

ou procedural da estrutura em árvore ou rede para recuperar os dados
desejados com o modelo de rede CODASYL/DBTG tendo uma linguagem de
recuperação definida que normalmente seria incorporado em uma linguagem
de programação de host.
Por exemplo, para encontrar a área do site B6C56, seria necessário
atravessar o conjunto Landtype e, em seguida, o conjunto de sites que são
Marshy para acessar esse registro específico. Em geral, dependendo do nível de
conjuntos de interseções e do número de registros em cada um, isso pode ser
bastante complexo. Esse tipo de consulta exigia que o programador do banco
de dados tivesse uma especificação explícita do caminho para os dados a serem
recuperados e passasse a ser conhecida como navegação de um banco de
dados. De fato, quando Bachman recebeu o prêmio Turing da ACM por seu
trabalho seminal no desenvolvimento de bancos de dados, ele intitulou sua
palestra do prêmio Turing, "The Programmer as Navigator".

Modelo Relacional

12
 Nesses modelos anteriores, a necessidade de conhecimento
excessivamente detalhado da estrutura e o fato de não se basearem em um
conceito bem definido causaram muitos problemas. Eles eram geralmente
difíceis de programar e manter devido a essa complexidade e não eram
passíveis de desenvolvimento de interfaces de alto nível e fáceis de usar. Tais
problemas levaram a várias investigações de maneiras de fornecer uma visão
mais abstrata e mais sólida dos dados e suas relações. Isso culminou no
trabalho de Codd em sua proposta para o modelo de dados relacionais baseado
em conceitos teóricos. Essencialmente, os bancos de dados relacionais
consistem em uma ou mais relações no formato bidimensional (linha e coluna).
As linhas são chamadas tuplas e correspondem aos registros; as colunas são
chamadas de domínios ou atributos e correspondem aos campos. Um ou mais
dos atributos são distinguidos como atributos-chave. É desejável manter uma
relação na terceira forma normal, a fim de evitar certos problemas de
redundância e anomalias de armazenamento. Uma relação está na terceira
forma normal se os atributos chave e não-chave possuem duas características.
Primeiro, cada atributo deve ser totalmente dependente da chave inteira e não
de uma parte dela se a chave englobar mais de um atributo. Segundo, cada um
dos atributos não chave deve ser dependente não transitivamente da chave. Ou
seja, eles dependem diretamente apenas do chave e não uns sobre os outros
(HAN, 2006).
Agora podemos apresentar um exemplo de algumas relações da nossa
Entidade-Projeto de relacionamento do banco de dados de sites ambientais.
Conforme discutido, as entidades individuais tornam-se relações com valores de
dados reais dos atributos inseridos na relação. Dois deles são mostrados na
Figura 5. Também há a relação AVALIAÇÕES que foi derivada das relações
correspondentes no diagrama E-R. A transformação para criar essa relação é a
seguinte. As chaves das duas entidades envolvidas no relacionamento são
usadas como a chave composta na relação derivada. Além disso, quaisquer
atributos associados ao relacionamento são incluídos como atributos, nesse
caso, o atributo COSTS.

13
 Figura 5 – Exemplo de modelo de dados relacional

Um meio de acesso a um banco de dados relacional no qual linguagens

de consulta de alto nível são frequentemente traduzidas é a álgebra relacional.
Isso fornece uma maneira de manipular e combinar as relações ou tabelas para
fornecer resultados de consulta. Assim, uma operação de álgebra relacional
consiste em (1) um nome de operação, (2) um ou mais nomes de relações, (3)
um ou mais nomes de domínio e (4) uma expressão condicional opcional. Por
exemplo, uma operação nas relações da Figura 5 pode ser

SELECT SITES WHERE Landfonn = Marshy AND Development = Moderate

Essa consulta resultaria em uma relação com todas as tuplas

correspondentes a sites pantanosos que têm apenas um desenvolvimento
moderado no site.

#ATENÇÃO#

14
O modelo de dados relacional é o mais utilizado na indústria do software.
Entretanto, ele não é conhecido com a profundidade que deveria. Conhecer
esse modelo aumenta sua vantagem para a criação de estruturas de dados
robustas e eficientes.
#ATENÇÃO#

Non-First Normal Forms

Uma suposição particular do modelo relacional é que as relações estão

na primeira forma normal, ou seja, os valores de um atributo são atômicos. Essa
suposição simplifica a teoria do modelo relacional, sua implementação e a
forma de uma linguagem de consulta, como a álgebra relacional. No entanto,
também restringe muito a capacidade de modelagem de bancos de dados
relacionais e é uma das motivações para o desenvolvimento de bancos de
dados orientados a objetos.
Também quase todas as abordagens para representar informações
incompletas e representações de dados imprecisas por conjuntos nebulosos nos
capítulos seguintes exigem que os atributos sejam definidos com valores. No
entanto, algumas extensões do modelo relacional conhecidas como não-
primeiras formas normais permitem valores de atributos não-atômicos. Essa
extensão fornece a base para a maioria das abordagens para representar dados
inexatos e imprecisos em bancos de dados relacionais.

Modelos Orientados a Objetos

Vários outros datamodels foram desenvolvidos em geral com o propósito

de poder adicional de representação. Estes incluem particularmente o modelo
de dados semânticos que introduziu as ideias de classes e subclasses em
modelagem de dados e bancos de dados dedutivos ou lógicos. Os últimos
sistemas têm recursos para especificar regras que um mecanismo inferencial ou
dedutivo pode usar para derivar informações adicionais dos dados armazenados
no banco de dados. Embora sejam interessantes e tenham influenciado, ou
possam ter influenciado no futuro, o desenvolvimento e a evolução de modelos
de bancos de dados, eles não estão no mainstream atual. de sistemas de banco
de dados (HAN, 2006).
De fato, o aparente último sucessor do modelo relacional será
datamodels orientados a objetos. Estes são atualmente representados por

15
bancos de dados orientados a objetos independentes e por extensões
orientadas a objeto para o modelo relacional. Eles foram desenvolvidos em
resposta a aplicações complexas que não poderiam ser tratadas por modelos de
dados anteriores. Tais aplicativos incluíam sistemas CAD/CAM, bancos de dados
de imagens, sistemas de informações geográficas e outros que exigiam dados
altamente estruturados. A abordagem básica no modelo de dados orientado a
objeto é organizar um banco de dados em termos de objetos, suas
propriedades e suas operações. Uma classe conterá objetos com a mesma
estrutura e comportamento. As classes são organizadas em uma hierarquia de
superclasses e subclasses. Para cada classe, as operações permitidas são
fornecidas por procedimentos pré-definidos. Outra característica importante da
abordagem é o conceito de herança que permite a especificação de novas
classes e tipos que herdam a maioria de suas operações e estrutura de
superclasses na hierarquia de classes.

#ATENÇÃO#
O modelo de dados orientado a objetos é antigo mas não tem muita utilização
em aplicações comerciais. Ele acabou sendo substituído pelos modelos NoSQL.
#ATENÇÃO#

Imprecisão nas Bases Data Convencionais

Nesta seção, apresentaremos uma série de abordagens que foram

consideradas para permitir uma variedade de representações de dados
incompletos e incertos. Estes variam de simples valores nulos ou ausentes a
representações de dados probabilísticos. Esta discussão fornecerá uma visão do
contexto em que ocorreram os desenvolvimentos de bancos de dados difusos.
Estes desenvolvimentos serão apresentados nos capítulos seguintes.

Valores nulos

A primeira tentativa na área de banco de dados para representar dados

inexatos foi a introdução do conceito de valores nulos por Codd. As primeiras
extensões do modelo de dados relacionais que incorporaram conjuntos de
domínios não homogêneos não utilizaram a teoria dos conjuntos fuzzy. Em vez
disso, eles foram tentativas de representar valores e intervalos nulos. O

16
relatório ANSI/X3/SPARC de 1975, por exemplo, aponta mais de uma dúzia de
tipos de nulos. Em uma extremidade do espectro, NULL significa
completamente desconhecido. Por exemplo, um valor nulo no salário atual de
um funcionário pode significar que o valor real é qualquer um dos valores
permitidos para o conjunto de domínios salariais.
Sem recorrer a medidas difusas, um usuário pode especificar algumas
informações sobre um valor que o restringe ainda mais. Um subconjunto ou
intervalo de valores do conjunto de domínios pode ser descrito dentro do qual
o valor real do atributo deve estar. O usuário ou o sistema (via dependências
funcionais) pode especificar subconjuntos ou sub-intervalos dentro dos quais o
valor real não deve estar.
Ainda outra opção é rotular valores nulos de uma maneira que requer
nulos distintos em diferentes partes do banco de dados para ter um
relacionamento de valor real específico (geralmente igualdade) se eles tiverem
o mesmo rótulo. A semântica do valor nulo varia de desconhecido (por exemplo,
o salário atual de um funcionário) para não aplicável (por exemplo, número da
submontagem de uma peça que não é um subconjunto) para não existe (por
exemplo, meio nome de uma pessoa). Esses dois últimos significados, no
entanto, não estão relacionados à incerteza.
Essas extensões relativamente pequenas tiveram muitas ramificações
dentro da teoria, algumas das quais ainda não foram totalmente resolvidas. Por
exemplo, se dois valores de domínio tiverem a mesma representação, eles
serão considerados o mesmo valor em bancos de dados comuns. Isso
claramente não é uma suposição correta para o valor nulo quando significa
desconhecido. É preciso levar em conta a semântica do nulo quando encontrado
durante a interpretação da consulta. Outro problema é a ocorrência de nulo
como valor-chave.

#ATENÇÃO#
Evite ao máximo valores nulos em seu banco de dados. Valores nulos, em sua
maioria, representam problemas de modelagem.
#ATENÇÃO#

Múltiplos Nulos

Em seguida, discutimos uma abordagem que foi desenvolvida para

permitir múltiplos nulos, em particular quatro interpretações nulas. O método é
baseado no uso de valores padrão (em vez de valores nulos) no lugar de dados

17
ausentes e no armazenamento de valores verdadeiros que descrevem o status
lógico dos valores padrão em tabelas suplementares. Quatro valores lógicos são
usados para que o status lógico dos valores de dados padrão possa ser descrito
como não apenas verdadeiro ou falso, mas também como inaplicável ou
desconhecido.
Se uma dada relação R pode ter valores faltantes em qualquer um de
seus campos não-chave, outra relação RL (tabela de status lógico) está
associada a R. RL possui o esquema relacional idêntico a R e os mesmos valores
nos campos-chave. No entanto, em outros campos, RL possui valores de status
lógicos correspondentes aos valores de atributos ou dados em R, e agora nem R
nem RL devem usar valores nulos reais (HAN, 2006).
Os valores de status lógico em RL são, na verdade, valores de verdade
lógicos de quatro valores. Os quatro valores de verdade são usados para
fornecer semântica adicional para descrever o status lógico de dados ausentes.
Os valores adicionais podem ser usados para descrever dados como não apenas
verdadeiros ou falsos, mas também como inaplicáveis ou desconhecidos. Agora
podemos discutir a semântica desses quatro casos.

Tipos de nulos

Primeiro é o caso de Não Aplicável (NA ou 0). Um NA no campo de valor

verdade de uma tabela de status lógico significa que o valor do atributo
correspondente em R: (1) é um valor padrão, (2) é 0 ou um valor que não está
no domínio do campo de dados e ( 3) não é aplicável à entidade. O valor dos
dados não é verdadeiro, nem falso, nem mesmo potencialmente verdadeiro da
entidade em questão, ou seja, a categoria de descrição que o atributo
representa não se aplica à entidade nomeada pela chave primária. Por exemplo,
suponha que, na base de dados de sensoriamento remoto, uma relação R tenha
entradas cujos valores de chave são valores de coordenadas, de modo que
armazenemos os quadrados de grade da imagem. Em seguida, um atributo
associado pode ser do tipo solo para o quadrado da grade. No entanto, se um
quadrado de grade particular cair totalmente sobre um corpo de água, o
atributo tipo de solo não será aplicável a esse quadrado. Assim, um valor
padrão é usado para esse valor de atributo no Rand NA na entrada
correspondente em RL.
Aplicável e Falso (AF ou 1) significa que o valor dos dados: (1) é um valor
real, (2) está no domínio do atributo, mas (3) é uma descrição falsa do entidade
nomeada pela chave primária. Este caso pode ser usado se os dados falharem
em uma restrição de integridade. Por exemplo, na componente de avaliação da

18
poluição da nossa base de dados de exemplo, em alguns campos as respostas
eram "sim" ou "não" para fornecer uma avaliação estatística uniforme, mas
alguns indivíduos podem fornecer respostas como "talvez", "por vezes" que não
são permitidas como valores.
Aplicável e Talvez Verdadeiro (AM ou 2) é o caso em que o valor: (1) é um
valor padrão, (2) está no domínio do atributo (é aplicável) e (3) pode ser um
verdadeiro ou um falso descrição da entidade nomeada pela chave primária. Ou
seja, o valor real é desconhecido, mas o padrão pode vir a ser uma descrição
verdadeira da entidade. Finalmente, o caso de Aplicável e Verdadeiro (AT ou 3),
que basicamente significa que os dados armazenados são exatamente como
deveriam ser para uso em o sistema de banco de dados.
Para entender a utilização desses valores e sua relação, devemos
considerar como os casos que eles representam podem ter surgido. Primeiro,
considere o processo de design do banco de dados. Uma dificuldade no
processo é decidir o que representar como uma entidade única e quais
atributos associar a determinadas entidades. Portanto, é possível que nem
todas as entidades de um determinado tipo tenham todas as propriedades ou
atributos associados ao tipo de entidade. Para algumas entidades, alguns dos
atributos não serão aplicados. Por exemplo, se na classificação de corpos de
água não tivermos distinguido entre rios e lagos, o atributo "corrente" pode não
ter um valor para algumas entradas de dados. Esse tipo de dados ausentes é
chamado de dados ausentes inaplicáveis, associados ao valor de verdade, NA.
Naturalmente, a outra situação comum é aquela em que os valores de
dados não estão disponíveis por algum motivo quando os registros são
adicionados ao banco de dados. Por exemplo, a corrente de um rio pode não
estar disponível quando inserimos outras características, como comprimento,
largura média, etc., de uma imagem de sensor remoto em um sistema GIS. Isso
é um dado desconhecido e está associado ao valor de verdade AM.

Benefícios

Diversos benefícios de representar dados ausentes usando padrões e valores de

verdade armazenados são descritos para essa abordagem:

• Como o status lógico dos valores de dados é representado em uma

tabela, esses valores podem ser manipulados por meio do SQL padrão.
• É possível fazer cálculos "e se" em dados perdidos. Pode ser útil calcular
um total mínimo e máximo possível. Isso pode ser feito facilmente

19
 definindo uma exibição na qual todos os campos AM foram substituídos
pelos valores mínimo ou máximo no domínio.
• É possível fazer aritmética em dados perdidos, pois os campos de dados
sempre contêm um valor padrão, em vez de um valor ou marca nulos.

Incompletitude em bancos de dados

Anteriormente, discutimos abordagens para representar dados

incompletos em casos específicos, como valores nulos para dados ausentes ou
inaplicáveis e valores de intervalo de dados. O tópico de dados perdidos pode
ser abordado de maneira mais generalizada. Os desenvolvimentos da Lipski
foram as contribuições iniciais dessa maneira e serão revisados a seguir. Deve-
se notar que, como a representação de dados inexatos é suficientemente
generalizada, ela se torna intimamente relacionada à modelagem de dados de
incerteza usando conjuntos fuzzy que discutiremos nos capítulos seguintes
(HAN, 2006).

Abordagem de Lipski

Lipski propõe uma abordagem mais geral. Ele não assume, por exemplo,
que NULL significa que um valor é completamente desconhecido. Dado que
pode haver nulos de valor rotulados ou restritos, deixe Q denotar todos os
objetos do mundo real que uma consulta Q poderia representar. Seja T um
objeto de banco de dados e T todos os objetos do mundo real que ele poderia
representar. Estes também são conhecidos como interpretações externas e
internas.
O trabalho original de Lipski não assume um formulário de banco de
dados relacional (ou qualquer outro), mas, para ilustração, um será usado aqui.
Suponha uma relação EMPREGADO com os domínios NOME e IDADE. O objeto
do banco de dados T = [Bob 30-35] poderia representar seis objetos do mundo
real (um para cada ano na faixa etária). Uma consulta, Q, coloca cada objeto de
banco de dados em uma das três categorias.
Por exemplo, a query, EMPLOYEE [AGE> 32], coloca T no set possível,
enquanto EMPLOYEE [AGE> 25] V EMPLOYEE [AGE <40] coloca T em conjunto
com certeza. As duas primeiras categorias também são conhecidas como o
menor valor, IIQII * 'e valor superior, IIQII *, e estas interpretações limitantes
são estudadas em sua abordagem. Vários relacionamentos são desenvolvidos
para auxiliar na avaliação desse tipo de consulta. Este trabalho tem sido a base

20
de comparação para várias abordagens mais generalizadas que descreveremos
a seguir.

Família de Modelos Incompletos

Recentemente, a modelagem geral de nulos e incompletude foi

organizada por um número de pesquisadores em abordagens que tentam
fornecer uma estrutura mais geral para a variedade de descrições de
informações incompletas que estivemos discutindo. Uma abordagem define
uma família de modelos de bancos de dados relacionais incompletos
caracterizados por relações entre tuplas em diferentes relações. Intervalos são
utilizados para valores desconhecidos e três tipos de tuplas parciais são usados
para especificar relações de incompletude entre tuplas na mesma relação (HAN,
2006).
A base para a família de modelos é a classificação de incompletude na
relação, tupla e nível de atributo. Resumidamente os quatro modelos podem
ser caracterizados da seguinte forma:

• Modelo 1: Este modelo permite erros ou incompletude no nível de

relação. Assim, a mesma tupla desconhecida pode ser representada por
diferentes tuplas em diferentes relações.
• Modelo 2: Aqui a incompletude é introduzida no nível dos valores dos
atributos. Essa situação pode ocorrer na origem dos dados antes que as
tuplas sejam inseridas no banco de dados. Assim, o mesmo identificador
pode ser usado para o mesmo valor desconhecido em qualquer lugar no
banco de dados.
• Modelo 3: é igual ao modelo 2, exceto que identificadores diferentes são
conhecidos por representar valores diferentes.
• Modelo 4: Finalmente considerado é a possibilidade de erros serem
introduzidos no nível da tupla. Uma tupla específica com valores
desconhecidos é representada pela mesma tupla parcial em todas as
relações, mas os identificadores não estão associados aos valores de
atributos desconhecidos. Em vez disso, eles estão ligados a tuplas.

Bancos de dados estatísticos e probabilísticos

21
 Primeiro, discutiremos os conceitos de abordagens estatísticas à
incerteza em bancos de dados. A principal abordagem nessa área é a de Wong,
na qual ele lida com uma grande classe de casos de incerteza por inferência
estatística. Essa formulação aborda a incerteza dos dados do mundo real,
assumindo um mundo ideal de informações perfeitas, ao qual os dados
incompletos podem ser estatisticamente comparados. A informação anterior
desta comparação é representada como uma função de distorção ou uma
distribuição condicional. Atributos ausentes e combinados podem ser tratados
por funções de distorção. Fontes de incerteza que resultam de distribuições
condicionais podem incluir obsolescência, erro de medição e agregação de
dados. Seu método visualiza as consultas como experimentos estatísticos nos
quais as informações eram incompletas e centradas no cálculo da resposta da
consulta como consistindo naquelas tuplas que minimizaram os dois tipos de
erros estatísticos.
Outra abordagem lida com tabelas relacionais estatísticas, mas a ênfase
está na informação estatística e não na informação incerta. Um excelente Um
resumo das questões de pesquisa de bases de dados estatísticos e científicos é
encontrado no artigo de Shoshani e Wong.
O método mais direto de lidar com a incerteza e a incompletude é usar
especificamente um modelo de dados probabilístico. Aqui vamos descrever a
abordagem mais completamente desenvolvida em que as probabilidades estão
associadas aos valores dos atributos. Em seu modelo, como cada atributo
estocástico é tratado como uma função de distribuição de probabilidade
discreta, as probabilidades de cada atributo (em uma tupla) devem ser
normalizadas (soma para 1.0). Entretanto, pode ser difícil determinar
probabilidades exatas para todos os valores de domínio possíveis. Como
resultado, eles desenvolveram o conceito de probabilidades ausentes para
considerar tais distribuições de probabilidade especificadas de forma
incompleta.

Utilização e Tendências

Os modelos de dados iniciaram com arquivos simples e evoluíram para

diversos outros modelos. A Figura 6 a seguir exibe a histórico de eovlucao
desses modelos até meados dos anos 2000.

22
 Figura 6 – Tendências dos modelos de dados

Pode-se notar que o modelo relaciona, da década de 70, ainda é muito

utilizado nas aplicações que desenvolvemos no dia a dia.

#ATENÇÃO#
Cuidado com a utilização de tendências. Nem sempre elas tem durabilidade ou
são adequadas ao seu modelo de negocio atual.
#ATENÇÃO#

Considerações Finais

Projetar modelos de qualidade é uma tarefa difícil (LARMAN, 2007).

Mesmo que tenhamos as melhores ferramentas, processos e técnicas sempre
devemos nos atentar para os princípios que norteiam esse tipo de trabalho.
Alguns desses princípios são os modelos de dados alternativos. Todos eles
então apoiados em dois conceitos conhecidos como entidade e
relacionamento. Ambos visam reduzir os efeitos de atualização de banco de
dados e problemas com dados incorretos.

23
UNIDADE 2 – NoSQL

Objetivos de aprendizagem
 Conceitos fundamentais
 Funcionamento interno dos modelos NoSQL
 Os padrões ACID vs. BASE
 Tipos de armazenamentos

Conceitos fundamentais

Atualmente, os sistemas de gerenciamento de bancos de dados

relacionais (SGBDRs) são a tecnologia predominante para armazenar dados
estruturados de aplicativos de negócios. Desde o trabalho publicado por Codd,
esses bancos de dados, baseados no cálculo relacional e fornecendo recursos
de consulta ad hoc meio de por SQL têm sido amplamente adotados e são
frequentemente pensado como a única alternativa para armazenamento de
dados de forma consistente. Embora tenha havido abordagens diferentes ao
longo dos anos, como bancos de dados de objetos ou armazenamentos XML,
essas tecnologias nunca obtiveram a mesma adoção e participação de mercado
que os SGBDRs.
Nos últimos anos, o pensamento “tamanho único” de armazenamento de
dados tem sido questionado por empresas científicas e afins, o que levou ao
surgimento de uma grande variedade de bancos de dados alternativos. O
movimento, bem como os novos datastores, são comumente incluídos sob o
termo NoSQL. A Figura 7 abaixo exibe o histórico da evolução dos bancos de
dados relacionais e NoSQL.

24
 Figura 7 – Evolução dos modelos de dados

O termo NoSQL foi usado pela primeira vez em 1998 para um banco de
dados relacional que omitiu o uso do SQL. O termo foi retomado em 2009 e
usado para conferências de defensores de bancos de dados não relacionais,
como o desenvolvedor do Last.fm Jon Oskarsson, que organizou o meetup
NoSQL em San Francisco. A revista Computerworld relata em um artigo sobre o
encontro NoSQL em São Francisco que “NoSQLers chegaram a compartilhar
como eles haviam derrubado a tirania de bancos de dados relacionais lentos e
caros em favor de maneiras mais eficientes e mais baratas de gerenciar dados”.
Ele afirma que, especialmente, as startups da Web 2.0 iniciaram seus negócios
sem a Oracle e mesmo sem o MySQL, que antes era popular entre as mesmas.
Em vez disso, eles criaram seus próprios armazenamentos de dados
influenciados pelo Dynamo da Amazon e pelo Bigtable do Google para
armazenar e processar grandes quantidades de dados como aparecem, por
exemplo, na comunidade social ou aplicativos de computação em nuvem (HAN,
2006).
Com isso, a maioria desses datastores tornaram-se software de código
aberto. Por exemplo, o Cassandra originalmente desenvolvido para um novo
recurso de pesquisa do Facebook agora faz parte do Apache Software Project.
De acordo com o engenheiro Avinash Lakshman, ele é capaz de escrever 2500
vezes mais rápido em um grande banco de dados de 50 gigabytes do que o
MySQL. Algumas das razões normalmente usadas para desenvolver e usar
datastores NoSQL são:

 Evitar a complexidade desnecessária. Os bancos de dados

25
 relacionais fornecem uma variedade de recursos e consistência de
dados. Mas esse conjunto de recursos e as propriedades ACID
implementadas podem ser mais do que o necessário para
aplicativos e casos de uso específicos.
 Alta taxa de transferência. Alguns bancos de dados NoSQL
fornecem uma taxa de transferência de dados significativamente
maior do que os SGBDRs tradicionais. Por exemplo, o Hypertable,
que busca a abordagem Bigtable do Google, permite que o
mecanismo de busca local Zvent armazene um bilhão de células de
dados por dia. Para dar outro exemplo, o Google pode processar
20 petabytes por dia armazenados no Bigtable por meio da
abordagem MapReduce.
 Escalabilidade Horizontal e Execução em Hardware de Mais Barato.
Definitivamente, o volume de dados está ficando tão grande que as
pessoas estão olhando para outras tecnologias.
 Evitar o caro mapeamento objeto-relacional. A maioria dos bancos
de dados NoSQL é projetada para armazenar estruturas de dados
simples ou mais semelhantes às de linguagens de programação
orientadas a objeto em comparação com estruturas de dados
relacionais. Eles não precisam do mapeamento objeto-relacional.
 Complexidade e custo de configuração de clusters de banco de
dados. Os bancos de dados NoSQL são projetados de maneira que
os clusters de PC podem ser expandidos de maneira fácil e barata
sem a complexidade e o custo de fragmentação, o que envolve o
corte de bancos de dados em várias tabelas. clusters ou grades.
 Confiabilidade para um melhor desempenho. Existem cenários em
que as aplicações estariam dispostas a comprometer a
confiabilidade para um melhor desempenho. Como exemplo,
imagine os dados de sessão HTTP que precisam ser compartilhados
entre vários servidores web, mas como os dados são de natureza
transitória (desaparecem quando o usuário efetua LOGOFF), não é
necessário armazená-los em de forma persistente.
 O atual "um tamanho para todos" dos bancos de dados. Um número
crescente de cenários não podem ser abordados com bancos de
dados tradicionais. Ele argumenta que "essa percepção não é

26
 realmente tão nova", como os estudos de Michael Stonebraker
(veja abaixo) existem há anos, mas as antigas "notícias" se
espalharam para uma comunidade maior nos últimos anos.

Funcionamento Interno

Em uma apresentação intitulada "Towards Robust Distributed Systems"

no simpósio da ACM PODC1 em 2000, Eric Brewer surgiu com o chamado
teorema CAP, que é amplamente adotado hoje por grandes empresas web (por
exemplo, Amazon) bem como na comunidade NoSQL. O acrônimo CAP significa:

 Consistência. Significa que o sistema está em um estado consistente após

a execução de uma operação. Normalmente, um sistema distribuído é
considerado consistente se, após uma operação de atualização de algum
local, todos os leitores visualizarem suas atualizações em alguma fonte de
dados compartilhada.
 Disponibilidade. Especialmente alta disponibilidade significa que um
sistema é projetado e implementado de uma maneira que permite que
ele continue a operação (isto é, permitindo operações de leitura e
gravação) se um dos nós do cluster falhar.
 Tolerância à partição. A capacidade de um sistema lidar com a adição e
remoção dinâmica de nós (por exemplo, para fins de manutenção; nós
removidos e novamente adicionados são considerados uma partição de
rede própria nessa noção).

Brewer alega que se pode escolher, no máximo, duas dessas três

características em um “sistema de dados compartilhados”. Em sua palestra, ele
se referiu a compensações entre os sistemas ACID1 e BASE2 e propôs como
critério de decisão selecionar um ou outro para casos de uso individuais.

1
Acronimo para Atomicidade, Consistência, Isolamento e Durabilidade. São as propriedades fundamentais de
qualquer SGBDRs.
2
Propriedades BASE: Basically Available, Soft state, Eventually consistent.

27
ACID vs. BASE

A internet, com seus wikis, blogs, mídias sociais, etc., cria uma enorme e
crescente quantidade de dados que precisam ser processados, analisados e
entregues. Empresas, organizações e indivíduos que oferecem aplicativos ou
serviços nesse campo precisam determinar suas necessidades individuais em
relação a desempenho, confiabilidade, disponibilidade, consistência e
durabilidade. Como discutido acima, o teorema CAP afirma que uma escolha só
pode ser feita para duas opções de consistência, disponibilidade e tolerância à
partição (KIMBALL, 2013).
Para um número crescente de aplicações e casos de uso (incluindo
aplicações web, especialmente em grande e ultra grande escala, e até mesmo
no setor de e-commerce) a disponibilidade e a tolerância à partição são mais
importantes do que consistência. Essas aplicações precisam ser confiáveis, o
que implica disponibilidade e redundância. Estas propriedades são difíceis de
alcançar com propriedades ACID, portanto abordagens como BASE são
aplicadas. A abordagem BASE de acordo com Brewer perde as propriedades
ACID de consistência e isolamento em favor de disponibilidade, degradação
graciosa e desempenho. A sigla BASE é composta das seguintes características:

• Basically available
• Soft-state
• Eventual consistency

Brewer contrasta o ACID com o BASE, conforme ilustrado na Figura 8 a

seguir, considerando, no entanto, os dois conceitos como um espectro em vez
de alternativas excludentes. As propriedades BASE podem ser resumidas da
seguinte maneira: um aplicativo funciona basicamente o tempo todo (Basically
available), não precisa ser consistente o tempo todo (Soft-state), mas
eventualmente estará em algum estado de estado conhecido (Eventual
consistency).

28
 Figura 8 – Padrão ACID versus BASE

Consistência Eventual significa que os leitores verão gravações, conforme

o tempo passa: “Em um estado estável, o sistema retornará o último valor
escrito”. Os clientes, portanto, podem enfrentar um estado inconsistente de
dados conforme as atualizações estão em andamento. Por exemplo, em um
banco de dados replicado, as atualizações podem ir para um nó que replica a
versão mais recente para todos os outros nós que contêm uma réplica do
conjunto de dados modificado, para que os nós de réplica tenham a versão mais
recente. Dessa forma, um sistema eventualmente consistente pode fornecer
garantias adicionais diferenciadas aos seus clientes:

• Ler suas próprias gravações (RYOW). A consistência significa que um

cliente vê suas atualizações imediatamente após elas terem sido emitidas
e concluídas, independentemente de ele ter escrito para um servidor e
nas seguintes leituras de servidores diferentes. Atualizações de outros
clientes não são visíveis para ele instantaneamente.
• Consistência de Sessão. Significa ler sua própria consistência de escrita
que é limitada a um escopo de sessão (normalmente ligado a um
servidor), então um cliente vê suas atualizações imediatamente somente
se as solicitações de leitura após uma atualização forem emitidas no
mesmo escopo de sessão.

A consistência casual expressa que, se um cliente ler a versão x e,

subsequentemente, gravar a versão y, qualquer versão de leitura do cliente y
também verá a versão x. Consistência de leitura monotônica fornece a garantia

29
de monotonicidade de tempo que os clientes só verão versões mais atualizadas
dos dados em solicitações futuras (KIMBALL, 2013).

#ATENÇÃO#
Consistência de dados é muito importante para cenários de tomada de decisão.
Entretanto, você pode abrir mão dela para aumentar o desempenho onde esses
dados não tem uma relevância tão alta.
#ATENÇÃO#

Versionamento de conjuntos de dados em cenários distribuídos

Se os conjuntos de dados são distribuídos entre os nós, eles podem ser

lidos e alterados em cada nó e nenhuma consistência rígida é garantida por
protocolos de transação distribuída, surgem dúvidas sobre como as
modificações e versões “simultâneas” são processadas e para quais valores um
conjunto de dados convergirá. Existem várias opções para lidar com esses
problemas:

• Timestamps parecem ser uma solução óbvia para o desenvolvimento de

uma ordem cronológica. No entanto, os timestamps “dependem de
relógios sincronizados e não capturam causalidade”, como aponta Lipcon.
• Bloqueio otimista implica que um contador único ou valor de clock é salvo
para cada parte dos dados. Quando um cliente tenta atualizar um
conjunto de dados, ele deve fornecer o valor de contador/relógio da
revisão que deseja atualizar. Como desvantagem desse procedimento, a
equipe de desenvolvimento do Projeto Voldemort observa que ele não
funciona bem em um cenário dinâmico e distribuído em que os
servidores aparecem e desaparecem com frequência e sem aviso prévio.
Para permitir o raciocínio de casualidade nas versões (por exemplo, qual
revisão é considerada a mais recente por um nó em que uma atualização
foi emitida) é necessário salvar, manter e processar muitos históricos,
pois o esquema de bloqueio otimista precisa de uma ordem total de
números de versão tornar o raciocínio de casualidade possível. Essa

30
 ordem total é facilmente interrompida em um ambiente distribuído e
dinâmico de nós, argumenta a equipe do Projeto Voldemort.
• O Vector Clocks é uma abordagem alternativa para capturar pedidos e
permitir o processamento entre atualizações em um sistema distribuído.
• Armazenamento Multiversão significa armazenar um registro de data e
hora para cada célula da tabela. Esses timestamps "não precisam
necessariamente corresponder à vida real", mas também podem ser
alguns valores artificiais que podem ser colocados em uma ordem
definida. Para uma determinada linha, várias versões podem existir
simultaneamente. Além da versão mais recente, um leitor também pode
solicitar a versão “mais recente antes de T”. Isso fornece “controle de
simultaneidade otimista com comparação e troca de registros de data e
hora” e também permite obter instantâneos de conjuntos de dados.

Tipos de Armazenamento

Os bancos de dados NoSQL possuem varias finalidades. Tais finalidades

podem ser usadas para uma classificação dos tipos de armazenamento
disponíveis para esses bancos (HAN, 2006). Dessa forma, podemos classifica-los
como:

• Os bancos de dados de documentos combinam cada chave com

uma estrutura de dados complexa conhecida como documento. Os
documentos podem conter vários pares de valores-chave
diferentes ou pares de matriz de chaves ou até mesmo
documentos aninhados.
• Armazenamento em grafos são usados para armazenar
informações sobre redes de dados, como conexões sociais.
Incluem Neo4J e Giraph.
• Os armazenamentos de valores-chave são os bancos de dados
NoSQL mais simples. Cada item individual no banco de dados é
armazenado como um nome de atributo (ou 'chave'), junto com
seu valor. Exemplos de armazenamentos de valores-chave são Riak
e Berkeley DB. Alguns armazenamentos de valores de chaves,

31
 como o Redis, permitem que cada valor tenha um tipo, como
'integer', que adiciona funcionalidade.
• Os repositórios de coluna ampla, como o Cassandra e o HBase, são
otimizados para consultas em grandes conjuntos de dados e
armazenam colunas de dados juntas, em vez de linhas.

Considerações Finais

Neste estudo entendemos os bancos de dados NoSQL e como os mesmos

podem ser aplicados aos projetos de software. Esses modelos são fundamentais
para a escalabilidade do software e facilitam a adição de novos elementos ao
longo do ciclo de vida do produto.

32
UNIDADE 3 – Data Warehouse

Objetivos de aprendizagem
 Modelo multidimensional
 Data Stage, Data Marts e Data Lakes
 Extração, Transformação e Carga (ETL)

Modelagem Multimensional

Um data warehouse (DW) é a coleção de processos e dados cuja

finalidade é apoiar o negócio com sua análise e tomada de decisões. Em outras
palavras, não é uma coisa em si, mas uma coleção de muitas partes diferentes.
Antes de examinar mais de perto as partes específicas de um ambiente de data
warehouse, é útil comparar as características e a finalidade de um data
warehouse com um sistema de aplicativo operacional.
Aplicativos que executam o negócio são chamados de OLTPs (Online
Processing Processing Systems). Os sistemas OLTP são voltados para funções
como processamento de pedidos recebidos, envio de produtos e transferência
de fundos, conforme solicitado. Esses aplicativos devem garantir que as
transações sejam tratadas com precisão e eficiência. Ninguém quer esperar
minutos para receber dinheiro de um caixa automático ou para inserir pedidos
de vendas no sistema de uma empresa (KIMBALL, 2013).
Em contraste, o propósito e as características de um ambiente de data
warehousing são fornecer dados em um formato facilmente compreensível pela
comunidade de negócios, a fim de apoiar os processos de tomada de decisão. O
data warehouse suporta a observação dos dados de negócios ao longo do
tempo para identificar tendências significativas no comportamento de compra,
retenção de clientes ou mudanças na produtividade dos funcionários. A Figura 9
apresenta as principais diferenças entre esses dois tipos de sistemas (HAN,
2006).
As diferenças inerentes entre as funções executadas nos sistemas OLTP e
DW resultam em diferenças de metodologia, arquitetura, ferramenta e
tecnologia. O data warehousing surgiu como uma consequência da
necessidade, mas se transformou em uma indústria completa que serve a uma
função valiosa na comunidade empresarial.
Agora que as diferenças entre os sistemas de data warehouse e OLTP
foram revisadas, é hora de analisar mais detalhadamente a composição do
33
próprio data warehouse (KIMBALL, 2013).

Figura 9 – Padrão OLAP versus OLTP

Um modelo de dados é uma abstração de como os elementos de dados

individuais se relacionam entre si. Representa visualmente como os dados
devem ser organizados e armazenados em um banco de dados. Um modelo de
dados fornece o mecanismo para documentar e entender como os dados são
organizados.
Existem muitos tipos diferentes de modelagem de dados, cada um com
um objetivo e propósito específicos. Conforme as organizações modificavam
como os dados eram estruturados para suportar relatórios e análises, surgiu
uma nova técnica de modelagem de dados, agora denominada modelagem
dimensional. Ralph Kimball, um pioneiro em armazenamento de dados, pode
ser creditado por cristalizar essas técnicas e publicá-las para o benefício do
setor (SULLIVAN, 2015).
Os dados e processos para executar o trabalho são chamados
coletivamente de data warehouse. Esses conceitos básicos foram aperfeiçoados
e remarcados por vários players diferentes no campo de data warehousing.
Uma técnica de modelagem específica evoluiu para suportar os tipos de
consultas e análises exigidas pelos negócios. Essa técnica é chamada de
modelagem dimensional. Essa abordagem foi aplicada ao data warehousing por
quase trinta anos e é suportada por uma ampla variedade de plataformas de
banco de dados e ferramentas de acesso a dados ou business intelligence. Os
34
modelos dimensionais dão suporte à perspectiva de negócios dos dados, e a
tecnologia atual garante que eles possam ser efetivamente implementados.
A modelagem dimensional é uma técnica de modelagem de dados formal
usada para organizar e apresentar dados para uso analítico e de relatórios. O
foco está na perspectiva de negócios e na representação de dados. O objetivo é
liberar os dados que foram capturados e armazenados pelos sistemas
operacionais e disponibilizá-los para a comunidade empresarial.
Independentemente de como os dados são estruturados, os executivos farão
perguntas com base em seu quadro de referência. Essa perspectiva é
impulsionada pelas características básicas da indústria e pela organização da
empresa. Por que não organizar os dados para refletir essa perspectiva de
negócios? Os dois principais objetivos da modelagem dimensional são a
facilidade de uso e o desempenho das consultas. Esses são os princípios que
guiam todo o processo de modelagem dimensional.
Existem outras técnicas de modelagem de dados que desempenham um
papel importante no desenvolvimento geral dos sistemas. Eles ajudam a
garantir que os dados em si e as relações entre os diferentes elementos de
dados sejam claramente definidos. Para sistemas operacionais, é importante
que os dados sejam organizados para facilitar o processamento de transações.
Isso inclui garantir a integridade e a velocidade das transações. O tipo de
modelagem usado para o design do sistema operacional é chamado de
modelagem de relação de entidade (E-R). Isso também pode ser chamado de
modelagem normalizada. Uma forma específica de modelagem E-R representa
os dados na terceira forma normal (3NF). Há uma disciplina completa em torno
dessa abordagem à modelagem de dados. Isso é mencionado para reconhecer o
valor e o propósito da modelagem E-R para o projeto do sistema operacional.
As duas seções a seguir examinam os principais objetivos da modelagem
dimensional (SULLIVAN, 2015).
O segundo objetivo, e igualmente importante, de um modelo
dimensional é garantir um bom desempenho de consulta. Se as solicitações não
forem executadas em tempo hábil, o data warehouse não será usado e não será
útil para a empresa. A modelagem dimensional leva em conta a necessidade
desse desempenho de consulta como parte da abordagem de design inerente.
Os dados são organizados para fornecer um desempenho consistente tanto
para consultas solicitadas antecipadamente quanto para aquelas que surgem
mais tarde. Todas as consultas possíveis não podem ser definidas com
antecedência, portanto, a técnica leva isso em conta para fornecer suporte a
padrões de acesso imprevisíveis.

35
Modelos

Um modelo dimensional é um modelo de dados organizado para fins de

compreensão do usuário e alto desempenho. Existem duas partes básicas de
um modelo dimensional: as dimensões e os fatos. Estes são os blocos de
construção que compreendem todos os modelos dimensionais, simples ou
complexos.

Dimensões

Dimensões são agrupamentos de elementos de dados nas principais

categorias de negócios. Dimensões comuns incluem o seguinte:
• Clientes
• Produtos
• Datas
• Fornecedores
• Vendedores
• Contas

Os elementos de dados individuais são chamados de atributos

dimensionais ou dados de referência. Os atributos dimensionais são usados
como cabeçalhos de linha e coluna para relatórios. Eles são usados para criar
listas de opções para determinar o que incluir ou excluir em um relatório. O
relacionamento entre esses atributos dimensionais cria caminhos de DRILL ou a
capacidade de navegar para cima e para baixo em uma hierarquia.
A necessidade de dados dimensionais é geralmente reconhecida ao
coletar os requisitos de negócios. Pode não ser comunicado diretamente, mas
percebido quando alguém precisa de um relatório por região, por semana e por
categoria de produto. Cada um dos termos que seguem a palavra "por" é um
atributo dimensional. Estes devem ser incluídos nas dimensões para apoiar esse
tipo de relatório.
Um exemplo de uma dimensão do cliente é mostrado na Figura 10. Este é
um exemplo altamente simplificado que mostra apenas os atributos de
endereço e data de nascimento do cliente. Alguns desses atributos se
relacionam entre si em uma hierarquia, enquanto outros são simplesmente
características adicionais do cliente. Qualquer um desses atributos pode ser

36
usado para restringir uma consulta ou para uso em um relatório.

Figura 10 - Exemplo de uma tabela dimensão

Fatos

Fatos são a medição de eventos de negócios. Estes são capturados como

informações específicas sobre um evento ou transação de negócios. Estes são
medidos, monitorados e rastreados ao longo do tempo. Os fatos são
tipicamente os valores e contagens que aparecem como o corpo dos relatórios.
Os fatos são usados como base para todos os cálculos (SULLIVAN, 2015).
Exemplos de fatos incluem unidades encomendadas, preço de varejo, valor
pago, valor do pagamento do sinistro, margem bruta, dólares orçados, previsão
de receita e saldo do empréstimo, entre outros.
Os fatos são apenas interessantes dentro do contexto apropriado, e o
contexto vem das dimensões. Por exemplo, o fato de uma empresa ter US $ 10
mil em vendas não é útil, a menos que você saiba que foi de sapatos vermelhos,
no mercado de Chicago, na semana anterior ao Dia dos Namorados. A Figura 11
é um exemplo de um Fato.

37
 Figura 11 – Exemplo de uma tabela fato

Uma característica importante da tabela fato é que ela armazena

basicamente referencias das dimensões e medidas. Medidas são o que você
mensurar, por exemplo, o numero de vendas, o valor das vendas, etc.

Diagramação do seu modelo dimensional

Existem diferentes maneiras de documentar e apresentar modelos

dimensionais. Uma das formas mais comuns que os modelos dimensionais são
representados são as tabelas a serem armazenadas em um banco de dados
relacional. O modelo dimensional pode ser documentado usando a mesma
ferramenta de modelagem usada para desenvolver outros modelos de dados
para o banco de dados relacional. Cada um dos atributos dimensionais é
incluído e representado usando nomes lógicos que devem ser significativos para
o negócio. Esse tipo de diagrama de tabela é facilmente entendido pelos
profissionais de sistemas, mas não é tão claro para os profissionais de negócios
(HAN, 2006).
Outro método para documentar seu modelo dimensional é apresentar
diagramas de negócios. A intenção é apresentar visualmente o modelo em
termos que reflitam mais de perto a interface que será finalmente apresentada
para acesso. Isso é chamado de modelagem dimensional de negócios e pode ser
documentado usando qualquer ferramenta de diagramação visual. Um exemplo
pode ser visto na Figura 12 abaixo.

38
 Figura 12 – Exemplo de modelo multidimensional

Uma análise cuidadosa deve ser realizada e princípios de modelagem

dimensional devem ser seguidos em ambos os casos. A principal diferença é
como o modelo é apresentado ao negócio. A notação do diagrama do modelo
dimensional de negócios é revisada a seguir. O processo para desenvolver um
modelo dimensional é discutido mais adiante neste capítulo.

#ATENÇÃO#
O modelo multidimensional deve ser orientado a consultas. Dessa forma, os
dados deverão estar desnormalizados.
#ATENÇÃO#

Data Stage, Data Marts e Data Lakes

Data Marts

Para suportar mais diretamente cada área de negócios, uma coleção de

dados necessários para essa área específica pode ser carregada em um data
mart. Cada data mart destina-se a suportar diretamente as necessidades de um
grupo de negócios específico. Pode ser possível definir uma camada semântica
na parte superior do armazém de dados para fornecer a exibição do data mart.
Nesse caso, os dados não são movidos fisicamente do data warehouse
(ROKACH, 2014). A arquitetura de dados refletiria isso aqui. Também é comum

39
que os dados sejam movidos fisicamente do data warehouse para os data
marts. Isso requer outra camada de extração, transformação e carregamento
(ETL) para mover os dados do data warehouse para o(s) data mart(s). A seguir,
descrevemos as características desse movimento físico de dados. Em alguns
casos, as estruturas do próprio data warehouse podem ser modificadas para
suportar os processos de carregamento e manutenção de data marts.
Mastering Data Warehouse Design, de Claudia Imhoff, Nicholas Galemmo e
Jonathon Geiger (Wiley, 2003), é um bom recurso para aprender mais sobre
essas técnicas.

 Quais dados serão armazenados aqui (dados de referência e / ou

transação)? Os dados necessários para suportar a análise de negócios
específica devem ser carregados. Teoricamente, apenas os dados
resumidos são necessários porque as transações detalhadas estão no
próprio armazém de dados. Na realidade, todos os dados de transação
usados com frequência são carregados no data mart. Os dados de
referência necessários para suportar a análise também são carregados no
data mart.
 Qual é o objetivo principal de manter os dados aqui? Os data marts são
projetados para suportar grupos de negócios ou análises específicos.
 Como isso será estruturado? O armazenamento geralmente armazena
estruturas dimensionais no data mart. As estruturas dimensionais podem
ser armazenadas fisicamente em um banco de dados relacional ou em
um cubo multidimensional (isso é uma característica da arquitetura
técnica). Às vezes, os dados são armazenados em estruturas
especificamente adaptadas ao aplicativo de negócios. Por exemplo, um
arquivo simples pode ser criado para suportar um pacote de software de
modelagem de catástrofe de seguro específico. Se uma camada
semântica for usada, em vez de mover fisicamente os dados, isso deve
ser observado aqui.
 Qual é a persistência dos dados ou quanta história será armazenada? O
requisito de dados históricos varia de acordo com a necessidade de
negócios específica para esse data mart. Isso pode fazer com que os
mesmos dados sejam carregados em vários data marts, com diferentes
quantidades de histórico. Por exemplo, os atuários podem usar dez anos
de histórico de sinistros, enquanto a administração de sinistros pode usar

40
 apenas cinco anos.
 Quem poderá usar os dados aqui? Os data marts são projetados
especificamente para suportar muitos usuários corporativos para suas
necessidades de relatórios e análises. Isso pode significar milhares de
representantes de atendimento ao cliente analisando o desempenho do
dia anterior, centenas de fornecedores acompanhando seu progresso em
direção a metas anuais ou um painel executivo revisado por um punhado
de executivos para acompanhar o desempenho corporativo.
 Que tipo de acesso a dados eles terão? O acesso é direto ao data mart por
meio de um ambiente de acesso ou consulta de dados ou talvez por meio
de relatórios interativos publicados pela intranet da empresa.

Extração, Transformação e Carga (ETL)

O trabalho de ETL (extrair, transformar e carregar) é o trabalho

subestimado com mais frequência que é feito em um projeto de data
warehouse. É também o conjunto de tarefas menos compreendido por todos
que não sejam os próprios desenvolvedores. Parece simples: copiar os dados,
movê-los um pouco e carregá-los para uso. Na realidade, o processo de ETL
raramente é direto e simples. Ter um bom entendimento do trabalho que deve
ser feito e da condição dos dados existentes ajudará a equipe do projeto a
estimar melhor o esforço e o tempo necessários para construir o data
warehouse (HAN, 2006). Vários passos importantes estão envolvidos no
desenvolvimento de um sistema ETL de produção:

1. Requisitos do sistema ETL: Os requisitos e os componentes de design do

projeto focaram em como deve ser o resultado final. O modelo de dados
reflete como os dados devem ser armazenados. Muitos requisitos
detalhados já foram coletados durante outras atividades do projeto,
como nomes e definições de elementos de dados individuais. As
atividades de criação de perfil de dados devem fornecer informações
sobre como os dados atuais se parecem, e a governança de dados forte
pode já ter determinado como cada elemento de dados deve ser tratado.
Requisitos adicionais para o sistema ETL também devem ser definidos.
Exemplos desses requisitos incluem regras de processamento, diretrizes

41
 para conformidade com requisitos legais, uma janela de processamento e
o que a trilha de auditoria deve incluir.
2. Desenho do sistema ETL: O modelo dimensional é o alvo que o sistema
ETL irá construir. O design do sistema ETL fornece os detalhes sobre
como ir de onde os dados estão agora para esse modelo dimensional de
destino. Algumas organizações exigem que cada pequeno detalhe seja
definido, incluindo todas as regras específicas para construir a dimensão,
e essas tabelas de fatos ser documentado antes de começar a construir o
sistema ETL. Outros esboçam um rápido fluxo de dados de alto nível em
um guardanapo e então começam a construir. Deve haver algum
equilíbrio aqui. É impossível rastrear cada pequeno detalhe que pode ser
descoberto nos dados antes de iniciar o trabalho no sistema ETL. No
entanto, é importante criar especificações que definam como o sistema
ETL funcionará. Eles são desenvolvidos usando os resultados dos
requisitos, incluindo definições de elementos de dados, mapeamento de
dados e insights da análise de dados de origem. Isso é ainda mais crítico
se o trabalho de construção for feito por desenvolvedores terceirizados.
Parte do design geral também deve abordar a funcionalidade para
manter o próprio sistema ETL em execução, incluindo uma trilha de
auditoria e recursos de backup / recuperação.
3. Construção do sistema ETL: Este é o desenvolvimento real do próprio
sistema, que pode incluir programas de escrita ou uso de tecnologia para
realizar o trabalho. Este trabalho pode ser dividido entre pessoas
diferentes ou até equipes diferentes. Usando o design coeso, cada equipe
pode trabalhar em sua parte. Pode haver algumas dependências entre as
equipes, mas muito do trabalho pode ser feito ao mesmo tempo.
4. Teste do sistema ETL: Como se trata de diferentes tipos de pessoas
trabalhando em diferentes partes do sistema, é importante realizar testes
completos e completos de todo o sistema. Isso também fornece a
oportunidade de identificar quaisquer gargalos e melhorar o
desempenho do sistema. Para se preparar para o teste, uma série de
casos de teste precisa ser desenvolvida para fornecer condições realistas
para determinar se o sistema está funcionando corretamente. Esses
casos de teste devem representar situações de negócios reais e precisam
ser definidos por representantes da comunidade de negócios.

42
#ATENÇÃO#
ETL tende a consumir muito processamento, memoria e acesso a disco. Dessa
forma, ter um servidor dedicado ao mesmo é uma boa prática.
#ATENÇÃO#

Funcionalidade do Sistema ETL

O que exatamente esse sistema ETL precisa fazer? O sistema fornecerá

várias funções comuns. Embora os conceitos sejam consistentes em todo o
mercado, os específicos são exclusivos para cada organização individual e seus
próprios sistemas de origem. As seções a seguir descrevem a funcionalidade e o
fluxo de um sistema ETL para preencher diretamente as estruturas de dados
dimensionais, chamadas de servidores de apresentação ou data marts. Etapas
adicionais seriam necessárias para preencher um data warehouse normalizado,
mas a maioria das funcionalidades seria semelhante. Vamos ver várias dessas
funções comuns.

Extração

Extrair os dados pode ser muito mais difícil do que parece. O negócio
precisa de informações sobre as transações mais recentes ou aquelas que
foram processadas desde a última vez em que o sistema ETL foi executado.
Também é necessário obter os dados de referência que descrevem essas
transações. Por exemplo, se um cliente existente mudou, mas desde então
comprou mais produtos, você precisa saber os detalhes sobre o novo local do
cliente e ainda obter as transações de compra (ROKACH, 2014).
Os desafios na extração de dados estão diretamente relacionados à
capacidade de um sistema de origem de fornecer novas transações de negócios
e suportar dados de referência. Alguns sistemas identificam quando as
mudanças ocorreram e podem compartilhar facilmente os dados. Outros
sistemas efetivamente fazem o que é necessário para concluir a transação, mas
não são projetados para acompanhar o que mudou. Isso pode significar que o
data warehouse obtém uma cópia de todo o arquivo do cliente e o sistema ETL
precisa descobrir o que foi alterado. Claramente, há uma diferença significativa
na quantidade de trabalho necessária para filtrar todo o arquivo do cliente, em
vez de obter detalhes sobre apenas os clientes que atualizaram as informações.

43
 Os desenvolvedores de ETL precisam coordenar seu trabalho com o de
equipes de TI que trabalham com os sistemas de origem nos quais os dados
devem ser extraídos. Essas outras equipes de desenvolvimento e suporte de
aplicativos podem ficar sobrecarregadas com seu próprio trabalho. Nesse caso,
as solicitações da equipe do data warehouse são apenas mais trabalho
adicionado a um cronograma já sobrecarregado.

Transformação

O termo transformação representa uma ampla variedade de funções que

são executadas para levar os dados como estão e prepará-los para o que você
precisa para suportar o processo de tomada de decisões de negócios. Algumas
dessas funções são diretas e diretas, enquanto outras podem ser complexas e
desafiadoras. Há dois conjuntos de trabalho distintamente diferentes a serem
feitos pelos desenvolvedores: um para criar e manter as dimensões e outro
para criar e manter as tabelas de fatos (ROKACH, 2014).
As dimensões fornecem os dados necessários para ativar a seleção e o
agrupamento de dados de muitas maneiras diferentes. Criar e manter as
dimensões geralmente envolve o uso de dados de vários sistemas de origem.
Pode haver algumas fontes que são usadas apenas para obter dados descritivos
para a dimensão. A funcionalidade é mais fácil de entender em um contexto
específico, portanto, vamos ver as funções comuns necessárias para criar e
manter uma dimensão do cliente:

Validar o cliente: Determine se o cliente recebido já é conhecido

Identificar alterações em clientes conhecidos: Se o cliente é conhecido,

houve alguma alteração nessas informações do cliente? Isso pode exigir a
análise de dados de várias fontes - talvez as transações de vendas, o banco de
dados corporativo de clientes de marketing e os sistemas contábeis.

• Lide com alterações para clientes conhecidos: para clientes

existentes, certifique-se de que as alterações sejam tratadas
adequadamente. Às vezes, os dados são atualizados para refletir os
valores atuais. Em outros casos, são necessárias versões históricas
do cliente. Esse conceito é chamado de dimensões que mudam
44
 lentamente. Muitos outros livros de data warehouse fornecem
detalhes técnicos sobre como desenvolver e manter dimensões
que mudam lentamente. Desnecessário dizer que isso significa
simplesmente que há mais trabalho a ser feito e um pouco mais de
complexidade para ser gerenciado.
• Identifique novos clientes: se este for um novo cliente, observe as
fontes mencionadas acima para determinar se o cliente está
identificado nesses sistemas. Se este for um novo cliente, um novo
identificador de data warehouse será atribuído. Isso é chamado de
atribuição de uma chave substituta.

Crie uma descrição completa para novos clientes: depois que um novo
cliente é identificado, os dados devem estar localizados para preencher todos
os atributos do cliente. Isso pode exigir a análise de várias fontes de dados.
Também requer diretrizes que priorizem as fontes. Talvez o banco de dados
mestre de clientes do departamento de marketing sempre seja o primeiro a
procurar informações sobre o cliente. Se o cliente não for encontrado lá, use os
dados de nome e endereço da fonte em que o cliente foi identificado pela
primeira vez e, em seguida, solicite dados demográficos de um provedor de
dados de terceiros. A fonte deve ser selecionada para cada elemento de dados.
Validar relacionamentos de dados: Siga as regras de negócios definidas
para garantir que todos os relacionamentos de dados estejam corretos. Por
exemplo, verifique os valores de cidade, estado e código postal para garantir
que eles representem uma combinação válida. Isso pode incluir
relacionamentos padrão, como a geografia, bem como relacionamentos
internos, como clientes residentes em Illinois, pertencentes à região de vendas
do centro-oeste.
Mapear dados do cliente de várias origens: quando os dados estão sendo
processados de mais de um sistema de origem, deve haver um método para
associar dados de cada fonte. Cada sistema de origem pode ter diferentes
identificadores de clientes, às vezes chamados de identificadores de produção
(IDs) ou códigos. Por exemplo, deve haver um mapeamento indicando que o ID
de produção para o cliente "ABC" no sistema de vendas é o mesmo cliente
identificado como "1003XJ" no sistema de contabilidade. Criar e manter este
mapa é uma parte crítica do processo geral de transformação que permite a
integração de dados de diferentes origens / sistemas.
Identifique e elimine clientes duplicados: é comum encontrar o mesmo

45
cliente em cada uma das diferentes origens de dados. No entanto, pode ser que
o mesmo cliente possa estar em dados da mesma fonte de dados. Por exemplo,
pode haver dados para um cliente chamado Laura Reeves e para um cliente
chamado L. L. Reeves. Observando o sobrenome, as variações do nome e da
inicial e outros dados diferenciados, como data de nascimento e endereço
residencial, você pode determinar se essa é a mesma pessoa. Esse
processamento é geralmente chamado de desduplicação ou deduplicação dos
dados (SHMUELI, 2016).

#ATENÇÃO#
Existem algoritmos para a desduplicação de dados. Vale a pena estuda-los para
entender como o funcionamento pode auxiliar na economia de processamento.
#ATENÇÃO#

Reestruture os dados: os dados do cliente devem ser reorganizados para se

ajustarem ao design do banco de dados de destino

Erros de tratamento: Durante o processamento dos dados de referência

do cliente, as regras são aplicadas para realizar a função necessária. Se, por
algum motivo, houver um problema no processamento dos dados, será
necessário determinar o que fazer a seguir. O perfil de dados anterior pode já
ter capturado o que deve ser feito. Alguns erros são pequenos e podem
simplesmente exigir que um valor padrão seja colocado no campo de fidelidade
do cliente. Em outros casos, o erro pode ser grave o suficiente para que um
cliente não possa ser identificado em nenhum lugar. A empresa pode exigir que
o cliente (e, em seguida, quaisquer transações associadas) seja colocado em um
"estacionamento" para revisão adicional e não seja carregado no data
warehouse. O número de erros e como eles são manipulados depende de como
a empresa precisa ver os dados.
Da mesma forma, existem funções comuns que são executadas para
processar dados de transação de entrada para produzir as tabelas de fatos. Isso
é explicado no contexto do processamento das transações de vendas do cliente.
Funções comuns incluem o seguinte:

• Isolar transações de interesse: Dependendo de como os dados são

fornecidos a partir do sistema de origem, pode ser necessário algum

46
 processamento para isolar as transações necessárias para preencher a
tabela de fatos de vendas. O sistema de vendas pode processar outras
transações, como devoluções de produtos ou ajustes de estoque. Se isso
não for necessário para criar a tabela de fatos de vendas, eles poderão
ser ignorados para essa etapa (eles podem ser necessários para outras
tabelas de fatos).
• Verifique a existência de dados de referência de dimensão para cada
transação de vendas: isso significa que os dados descritivos críticos, como
produto, cliente e data de vendas, são válidos. As transações podem fluir
pelo sistema de vendas com identificadores de clientes ausentes ou
inválidos. Deve haver um conjunto de regras sobre como lidar com cada
caso especial observado na transação. Também é essencial garantir que
haja uma linha na tabela de dimensões para cada instância usada para
uma transação. Isso é conhecido como integridade referencial.
• Atribuir identificadores de data warehouse apropriados: Uma vez que os
dados de referência críticos tenham sido validados, os identificadores
devem ser alterados daqueles usados pelos sistemas de origem
subjacentes àqueles usados no ambiente de data warehouse, as chaves
substitutas.
• Validar campos de fatos: Embora os fatos reais sejam específicos de cada
transação, geralmente há diretrizes gerais que podem ser verificadas
para determinar se o fato é exato. Por exemplo, uma transação de
vendas de unidades zero pode indicar que essa não é uma venda real.
Uma única transação de vendas para uma quantia maior que a média de
vendas semanais para toda a empresa é provavelmente um erro de
dados.
• Traduzir valores de fatos para facilidade de uso: as medidas de negócios
necessárias para relatórios podem ser diferentes de como os dados são
armazenados nos sistemas de origem. É útil converter dados em uma
unidade de medida comum para relatórios. Se uma transação de venda
registra a venda de um caso, isso pode ser um caso de 24 unidades
individuais ou talvez 36 unidades individuais. A conversão de todas as
vendas para as unidades individuais garante relatórios consistentes e
significativos. Além disso, muitos fatos funcionam juntos. Por exemplo, o
número de unidades vendidas, o preço e a quantia em dólares vendida

47
 são todos fatos úteis. Apenas dois deles precisam ser armazenados
fisicamente; o terceiro pode ser calculado on-the-fly. Para fazer isso o
mais rápido possível, é útil armazenar os dois fatos que são usados com
mais frequência.
• Desvendar a lógica do sistema de origem: em muitos casos, o sistema de
origem tem dados principais armazenados de maneira a ajudar esse
sistema a executar rapidamente e permitir que cada módulo seja
relativamente autônomo. Isso pode significar que as peças necessárias
para obter uma imagem completa de uma transação de vendas podem
ser armazenadas em vários locais ou tabelas. Para tornar as coisas mais
desafiadoras, pode não haver links diretos entre essas tabelas, embora
possa haver uma série de tabelas de conversão e de pesquisa necessárias
para chegar ao fim das coisas. Talvez seja por isso que os dados são tão
difíceis de serem usados no sistema de origem. Os detalhes estão todos
lá, mas você precisa entender os "apertos de mão secretos" para chegar
aos números reais. O sistema ETL pode aplicar essa lógica para fornecer
os números de venda reais a serem carregados em uma tabela de fatos.
Isso é feito uma vez e todos podem acessar esses fatos sem ter que
aprender todos esses detalhes.
• Realizar cálculos complexos: muitos cálculos podem ser feitos ao criar um
relatório ou acessar dados de maneira ad hoc. No entanto, alguns
cálculos podem ser complexos e demorados demais para serem
executados on-the-fly. O sistema ETL pode executar esses cálculos e
armazenar os resultados como fatos, que podem ser acessados
diretamente para geração de relatórios.

#ATENÇÃO#
A realização de cálculos complexos exige que esse cálculo possa ser auditado.
Tenha uma forma de armazenar a memoria de calculo do mesmo.
#ATENÇÃO#

Definições e Perspectivas do Data Lake

48
 À medida que o conceito de data lake se torna parte da arquitetura
central de dados, a questão é, muitas vezes, se o data lake é uma estratégia de
arquitetura ou um destino de arquitetura. A resposta é ambas. Ao definir o data
lake como um repositório centralizado de dados corporativos para várias cargas
de trabalho de dados (dentro e fora de uma parte), abordamos tanto a
arquitetura do estado final como também estabelecer uma luz orientadora para
as decisões relacionadas à arquitetura de dados na jornada para alcançar massa
crítica para o lago de dados. Muitas empresas aplicam sabiamente o conceito
de lago de dados ao ditado de Ralph Waldo Emerson de que “a vida é uma
jornada, não um destino” e reconhecer que o lago de dados é o destino final de
uma jornada única que segue seu próprio ritmo e direção com base nos
direcionadores e prioridades da empresa adotante. Com base nos padrões de
adoção de arquitetura que vemos acontecendo nas empresas hoje, podemos
destilar a jornada até o data lake em quatro estágios de adoção de negócios.
O estágio 1 é composto por projetos pilotos de Big Data “kick-the-tire”
que focam em resultados de negócios específicos que servem como uma
introdução ao uso e gerenciamento de um ambiente Apache Hadoop. O estágio
2 é uma abordagem mais reacionária à medida que as empresas começam a se
concentrar na alavancagem dos pontos fortes do Hadoop para lidar com as
ineficiências da arquitetura existente e isolar oportunidades de valor de
negócios claras, rápidas e mensuráveis. Um desses padrões é aproveitar a
camada de persistência escalonável e de baixo custo do Hadoop ou sua
capacidade de executar processamento e análise de big data.
Um exemplo é a recente aceitação da realocação de dados de data
warehouse históricos para o data lake como uma extensão de armazenamento
on-line com acordos de nível de serviço menores para reduzir o tamanho e o
gerenciamento geral do data warehouse. Outras implementações podem
fornecer valor potencialmente de longo prazo, como realocar uma área de
armazenamento de dados de aquisições de dados de origem operacional no
data lake para que as integrações de data warehouse possam originar e
persistir dados adquiridos como dados brutos de longo prazo (e dados
adicionais não usados pelo data warehouse) para permitir a acessibilidade e
poder de processamento de dados necessários aos cientistas de dados e
desenvolvimento de análises (SHMUELI, 2016).

Considerações Finais

Neste estudo entendemos o modelo de dados para data warehouse e

como os mesmos podem ser aplicados aos projetos de software de decisão.

49
Esses modelo são fundamentais para a estabilidade do software e facilitam o
acesso aos ao longo do ciclo de vida do produto.

50
UNIDADE 4 – Data Mining

Objetivos de aprendizagem
 Descoberta de conhecimento
 Principais algoritmos
 Técnicas para preparação de dados

Descoberta de Conhecimento

A mineração de dados tem atraído muita atenção da indústria da

informação e da sociedade como um todo nos últimos anos, devido à ampla
disponibilidade de enormes quantidades de dados e à necessidade de
transformar tais dados em informação e conhecimento úteis. As informações e
conhecimentos adquiridos podem ser usados para aplicações que vão desde
análise de mercado, detecção de fraudes e retenção de clientes, até controle de
produção e exploração científica.
A mineração de dados pode ser vista como resultado da evolução natural
da tecnologia da informação. A indústria de sistemas de banco de dados
testemunhou um caminho evolutivo no desenvolvimento das seguintes
funcionalidades: (a) coleta de dados e criação de banco de dados, (b)
gerenciamento de dados (incluindo armazenamento e recuperação de dados e
processamento de transações de bancos de dados) e (c) análise avançada de
dados (envolvendo data warehousing e mineração de dados).
Por exemplo, o desenvolvimento inicial de mecanismos de coleta de
dados e criação de bancos de dados serviu como um pré-requisito para o
desenvolvimento posterior de mecanismos eficazes de armazenamento e
recuperação de dados e processamento de consultas e transações. Com
inúmeros sistemas de banco de dados oferecendo processamento de consultas
e transações como prática comum, a análise avançada de dados tornou-se
naturalmente o próximo alvo (HAN, 2006).
Desde a década de 1960, o banco de dados e a tecnologia da informação
têm evoluído sistematicamente de sistemas primitivos de processamento de
arquivos para sistemas sofisticados e poderosos de banco de dados. A pesquisa
e desenvolvimento em sistemas de banco de dados desde a década de 1970
progrediu desde sistemas de banco de dados hierárquicos e de rede iniciais até

51
o desenvolvimento de sistemas de bancos de dados relacionais (onde os dados
são armazenados em estruturas de tabelas relacionais), ferramentas de
modelagem de dados e indexação e métodos de acesso. Além disso, os usuários
obtiveram acesso conveniente e flexível aos dados por meio de linguagens de
consulta, interfaces de usuários, processamento otimizado de consultas e
gerenciamento de transações. Métodos eficientes para processamento de
transações on-line (OLTP), onde uma consulta é vista como uma transação
somente leitura, contribuíram substancialmente para a evolução e ampla
aceitação da tecnologia relacional como uma ferramenta importante para
armazenamento, recuperação e gerenciamento eficientes de grandes volumes.
quantidades de dados.
A tecnologia de banco de dados desde meados da década de 1980 tem
sido caracterizada pela popular adoção de tecnologia relacional e pelo
surgimento de atividades de pesquisa e desenvolvimento em novos e
poderosos sistemas de banco de dados. Elas promovem o desenvolvimento de
modelos de dados avançados, como modelos de relacionamento estendido-
relacional, orientado a objetos, objeto-relacional e dedutivo. Sistemas de banco
de dados orientados a aplicativos, incluindo bancos de dados espaciais,
temporais, multimídia, ativos, de fluxo e sensor, e científicos e de engenharia,
bases de conhecimento e bases de informações de escritório, floresceram.
Questões relacionadas à distribuição, diversificação e compartilhamento de
dados têm sido estudadas extensivamente. Sistemas de bancos de dados
heterogêneos e sistemas de informações globais baseados na Internet, como a
World Wide Web (WWW), também surgiram e desempenham um papel vital na
indústria da informação.
O progresso constante e surpreendente da tecnologia de hardware de
computador nas últimas três décadas levou a um grande suprimento de
computadores poderosos e acessíveis, equipamentos de coleta de dados e
mídia de armazenamento. Essa tecnologia fornece um grande impulso ao banco
de dados e ao setor de informações e disponibiliza um grande número de
bancos de dados e repositórios de informações para gerenciamento de
transações, recuperação de informações e análise de dados.

52
 Figura 13 – Como podemos analisar os dados?

Os dados podem agora ser armazenados em muitos tipos diferentes de

bancos de dados e repositórios de informações. Uma arquitetura de repositório
de dados que emergiu é o data warehouse, um repositório de múltiplas fontes
de dados heterogêneas organizadas sob um esquema unificado em um único
site, a fim de facilitar a tomada de decisões gerenciais. A tecnologia de data
warehouse inclui limpeza de dados, integração de dados e processamento
analítico on-line (OLAP), ou seja, técnicas de análise com funcionalidades como
sumarização, consolidação e agregação, bem como a capacidade de visualizar
informações de diferentes ângulos. Embora as ferramentas OLAP suportem a
análise multidimensional e a tomada de decisão, ferramentas adicionais de
análise de dados são necessárias para uma análise aprofundada, como
classificação de dados, armazenamento em cluster e caracterização de
alterações de dados ao longo do tempo. Além disso, grandes volumes de dados
podem ser acumulados além de bancos de dados e armazéns de dados.
Exemplos típicos incluem a World Wide Web e fluxos de dados, onde os dados
entram e saem como fluxos, como em aplicações como vigilância por vídeo,
telecomunicações e redes de sensores. A análise eficaz e eficiente de dados de
formas tão diferentes torna-se uma tarefa desafiadora (HAN, 2006).
A abundância de dados, juntamente com a necessidade de poderosas
ferramentas de análise de dados, tem sido descrita como uma situação rica em
53
dados, mas com pouca informação. A quantidade enorme e crescente de dados,
coletados e armazenados em grandes e numerosos repositórios de dados,
excedeu em muito nossa capacidade humana de compreensão sem
ferramentas poderosas. Como resultado, os dados coletados em grandes
repositórios de dados tornam-se “data túmulos” - arquivos de dados raramente
visitados.

#ATENÇÃO#
Abundancia de dados nem sempre significa qualidade de dados. Entenda os
dados que você tem disponível para verificar a qualidade dos mesmos.
#ATENÇÃO#

Consequentemente, decisões importantes são frequentemente tomadas

com base não nos dados ricos em informação armazenados nos repositórios de
dados, mas sim na intuição de um tomador de decisão, simplesmente porque o
tomador de decisão não possui as ferramentas para extrair o conhecimento
valioso embutido nas vastas quantidades de dados. Além disso, considere as
tecnologias de sistemas especialistas, que normalmente dependem de usuários
ou especialistas de domínio para inserir manualmente o conhecimento em
bases de conhecimento. Infelizmente, este procedimento é propenso a vieses e
erros e é extremamente demorado e dispendioso.
Ferramentas de mineração de dados executam análise de dados e podem
revelar padrões de dados importantes, contribuindo enormemente para
estratégias de negócios, bases de conhecimento e pesquisas científicas e
médicas. A diferença crescente entre dados e informações exige um
desenvolvimento sistemático de ferramentas de mineração de dados que
transformarão as tumbas de dados em “pepitas de ouro” de conhecimento.

Então, o que é mineração de dados?

Em termos simples, a mineração de dados se refere à extração ou

conhecimento de “mineração” de grandes quantidades de dados. O termo é na
verdade um equívoco. Lembre-se que a mineração de ouro de rochas ou areia é
referida como mineração de ouro, em vez de mineração de rochas ou areia.
Assim, a mineração de dados deveria ter sido mais apropriadamente chamada
de “conhecimento de mineração de dados”, o que infelizmente é um tanto

54
longo. “Mineração de conhecimento”, um termo mais curto, pode não refletir a
ênfase na mineração de grandes quantidades de dados. No entanto, a
mineração é um termo vívido que caracteriza o processo que encontra um
pequeno conjunto de pepitas preciosas de uma grande quantidade de matéria-
prima. Assim, tal denominação incorreta que carrega tanto “dados” como
“mineração” tornou-se uma escolha popular. Muitos outros termos carregam
um significado semelhante ou ligeiramente diferente para a mineração de
dados, como mineração de dados, extração de conhecimento, análise de
dados/padrões, arqueologia de dados e dragagem de dados (HAN, 2006).

Figura 14 – Extração de conhecimento em bancos de dados

Muitas pessoas tratam a mineração de dados como sinônimo de outro

termo usado popularmente, o Knowledge Discovery from Data, ou KDD.
Alternativamente, outros vêem a mineração de dados como simplesmente uma
etapa essencial no processo de descoberta de conhecimento. Descoberta de
conhecimento como um processo é representado na Figura 15 e consiste em
uma sequência iterativa das seguintes etapas:

55
 1. Limpeza de dados. Para remover ruído e dados inconsistentes.
2. Integração de dados. Onde várias fontes de dados podem ser
combinadas.
3. Seleção de dados. Onde o registro de dados é feito por um indivíduo
exclusivo que foi retirado do banco de dados.
4. Transformação de dados. Em que os dados transformam ou consolidam
uma forma adequada de mineração, realizando operações de resumo ou
de agregação, por exemplo.
5. Mineração de dados. Um processo essencial em que métodos inteligentes
são aplicados para extrair padrões de dados.
6. Avaliação de padrões. Para identificar os padrões realmente interessantes
que representam o conhecimento com base em algumas medidas de
interesse.
7. Apresentação do conhecimento. Onde as técnicas de visualização e
representação de conhecimento são usadas para apresentar o
conhecimento extraído ao usuário.

As etapas 1 a 4 são formas diferentes de pré-processamento de dados,

onde os dados são preparados para mineração. A etapa de mineração de dados
pode interagir com o usuário ou com uma base de conhecimento. Os padrões
interessantes são apresentados ao usuário e podem ser armazenados como
novos conhecimentos na base de conhecimento. Observe que, de acordo com
essa visão, a mineração de dados é apenas uma etapa em todo o processo,
embora essencial, pois revela padrões ocultos para avaliação.
Concordamos que a mineração de dados é uma etapa no processo de
descoberta de conhecimento. No entanto, na indústria, na mídia e no ambiente
de pesquisa de banco de dados, o termo mineração de dados está se tornando
mais popular do que o longo prazo da descoberta de conhecimento a partir de
dados. Portanto, neste livro, escolhemos usar o termo mineração de dados.
Adotamos uma visão ampla da funcionalidade de mineração de dados: a
mineração de dados é o processo de descoberta de conhecimento interessante
a partir de grandes quantidades de dados armazenados em bancos de dados,
armazéns de dados ou outros repositórios de informações (HAN, 2006).

56
 Figura 15 – Processo de descoberta de conhecimento em bancos de dados

Principais Algoritmos

Padrões, Associações e Correlações Frequentes de Mineração

Padrões frequentes, como o nome sugere, são padrões que ocorrem com
frequência nos dados. Existem muitos tipos de padrões frequentes, incluindo
conjuntos de itens, subsequências e subestruturas. Um conjunto de itens
frequente geralmente se refere a um conjunto de itens que aparecem

57
frequentemente juntos em um conjunto de dados transacionais, como leite e
pão. Uma subsequência de ocorrência frequente, como o padrão que os
clientes tendem a adquirir primeiro um PC, seguido por uma câmera digital e,
em seguida, um cartão de memória, é um padrão sequencial (frequente). Uma
subestrutura pode se referir a diferentes formas estruturais, como gráficos,
árvores ou reticulados, que podem ser combinados com conjuntos de itens ou
subsequências. Se uma subestrutura ocorre com frequência, ela é chamada de
padrão estruturado e frequente. Padrões frequentes de mineração levam à
descoberta de associações e correlações interessantes dentro dos dados
(SHMUELI, 2016).

Classificação e Previsão

Classificação é o processo de encontrar um modelo (ou função) que

descreva e distinga classes ou conceitos de dados, para poder usar o modelo
para prever a classe de objetos cujo rótulo de classe é desconhecido. O modelo
derivado é baseado na análise de um conjunto de dados de treinamento (ou
seja, objetos de dados cujo rótulo de classe é conhecido).
O modelo derivado pode ser representado em várias formas, tais como
regras de classificação (IF-THEN), árvores de decisão, fórmulas matemáticas ou
redes neurais. Uma árvore de decisão é uma estrutura de árvore do tipo
fluxograma, em que cada nó denota um teste em um valor de atributo, cada
ramificação representa um resultado do teste e as folhas de árvore
representam classes ou distribuições de classes. As árvores de decisão podem
ser facilmente convertidas em regras de classificação. Uma rede neural, quando
usada para classificação, é tipicamente uma coleção de unidades de
processamento semelhantes a neurônios com conexões ponderadas entre as
unidades. Existem muitos outros métodos para a construção de modelos de
classificação, como a classificação bayesiana ingênua, máquinas de vetores de
suporte e classificação de k vizinhos mais próximos.

#ATENÇÃO#
Redes neurais são uma área extensa e deve ser bem entendida antes de utilizar
os resultados produzidos.
#ATENÇÃO#

Considerando que a classificação prevê rótulos categóricos (discretos,

não ordenados), modelos de previsão com funções de valor contínuo. Isto é, é
58
usado para prever valores de dados numéricos ausentes ou não disponíveis, em
vez de rótulos de classes. Embora o termo predição possa se referir tanto à
predição numérica quanto à predição de rotulação de classe, neste livro nós o
usamos para referir-se principalmente à predição numérica. A análise de
regressão é uma metodologia estatística mais usada para previsão numérica,
embora outros métodos também existam. A previsão também abrange a
identificação de tendências de distribuição com base nos dados disponíveis
(SHMUELI, 2016).
A classificação e a previsão podem precisar ser precedidas pela análise de
relevância, que tenta identificar atributos que não contribuem para o processo
de classificação ou previsão. Esses atributos podem ser excluídos.

Análise de Cluster

Diferentemente da classificação e predição, que analisam objetos de

dados com rótulo de classe, o agrupamento analisa objetos de dados sem
consultar um rótulo de classe conhecido. Em geral, os rótulos de classe não
estão presentes nos dados de treinamento simplesmente porque eles não são
conhecidos para começar. Clustering pode ser usado para gerar esses rótulos.
Os objetos são agrupados ou agrupados com base no princípio de maximizar a
semelhança intraclasse e minimizar a similaridade interclasse. Ou seja, os
clusters de objetos são formados de modo que os objetos dentro de um cluster
tenham alta similaridade em comparação um ao outro, mas são muito
diferentes dos objetos em outros clusters. Cada cluster formado pode ser visto
como uma classe de objetos, a partir da qual as regras podem ser derivadas. O
agrupamento também pode facilitar a formação de taxonomia, isto é, a
organização de observações em uma hierarquia de classes que agrupam
eventos semelhantes.

Análise Outlier

Um banco de dados pode conter objetos de dados que não obedecem ao

comportamento ou modelo geral dos dados. Esses objetos de dados são
outliers. A maioria dos métodos de mineração de dados descarta outliers como
ruído ou exceções. No entanto, em alguns aplicativos, como a detecção de
fraudes, os eventos raros podem ser mais interessantes do que os mais
frequentes. A análise de dados outliers é referida como mineração outlier

59
(SHMUELI, 2016).
Os outliers podem ser detectados usando testes estatísticos que
pressupõem um modelo de distribuição ou probabilidade para os dados, ou
usando medidas de distância, onde os objetos que estão a uma distância
substancial de qualquer outro cluster são considerados outliers. Em vez de usar
medidas estatísticas ou de distância, os métodos baseados em desvios
identificam os valores discrepantes examinando as diferenças nas principais
características dos objetos de um grupo.

Figura 16 – Tipos de algoritmos mais comuns para mineração de dados

Técnicas para Preparação dos Dados

Os bancos de dados do mundo real de hoje são altamente suscetíveis a

dados ruidosos, ausentes e inconsistentes, devido ao seu tamanho
normalmente grande (geralmente vários gigabytes ou mais) e sua provável
origem de várias fontes heterogêneas. Dados de baixa qualidade levarão a
resultados de mineração de baixa qualidade. “Como os dados podem ser pré-
processados para ajudar a melhorar a qualidade dos dados e,
consequentemente, os resultados da mineração? Como os dados podem ser
pré-processados para melhorar a eficiência e a facilidade do processo de
mineração? ”
Existem várias técnicas de pré-processamento de dados. A limpeza de
dados pode ser aplicada para remover ruídos e corrigir inconsistências nos
dados. A integração de dados mescla dados de várias origens em um
armazenamento de dados coerente, como um data warehouse. Transformações
de dados, como a normalização, podem ser aplicadas. Por exemplo, a
normalização pode melhorar a precisão e a eficiência de algoritmos de
mineração envolvendo medições de distância. A redução de dados pode reduzir

60
o tamanho dos dados agregando, eliminando recursos redundantes ou clusters,
por exemplo. Essas técnicas não são mutuamente exclusivas; eles podem
trabalhar juntos. Por exemplo, a limpeza de dados pode envolver
transformações para corrigir dados incorretos, como transformar todas as
entradas de um campo de data em um formato comum. As técnicas de
processamento de dados, quando aplicadas antes da mineração, podem
melhorar substancialmente a qualidade geral dos padrões minerados e / ou o
tempo necessário para a mineração real (HAN, 2006).
Imagine que você é um gerente da AllElectronics e foi encarregado de
analisar os dados da empresa em relação às vendas na sua filial. Você
imediatamente começou a executar essa tarefa. Você inspeciona
cuidadosamente o banco de dados e o data warehouse da empresa,
identificando e selecionando os atributos ou dimensões a serem incluídos em
sua análise, como item, preço e unidades vendidas. Você percebe que vários
dos atributos para várias tuplas não têm valor registrado. Para sua análise, você
gostaria de incluir informações sobre se cada item comprado foi anunciado
como vendido, mas você descobre que essa informação não foi registrada. Além
disso, os usuários do sistema de banco de dados relataram erros, valores
incomuns e inconsistências nos dados registrados para algumas transações. Em
outras palavras, os dados que você deseja analisar pelas técnicas de mineração
de dados são incompletos (sem valores de atributos ou certos atributos de
interesse, ou contendo apenas dados agregados), ruidosos (contendo erros ou
valores discrepantes que se desviam do esperado ) e inconsistente (por
exemplo, contendo discrepâncias nos códigos de departamento usados para
categorizar itens). Bem-vindo ao mundo real!
Dados incompletos, ruidosos e inconsistentes são propriedades comuns
de grandes bancos de dados e data warehouses do mundo real. Dados
incompletos podem ocorrer por várias razões. Os atributos de interesse nem
sempre estão disponíveis, como informações de clientes para dados de
transações de vendas. Outros dados podem não estar incluídos simplesmente
porque não foram considerados importantes no momento da entrada. Dados
relevantes podem não ser registrados devido a um mal-entendido ou devido a
falhas no equipamento. Dados inconsistentes com outros dados gravados
podem ter sido excluídos. Além disso, o registro da história ou modificações nos
dados pode ter sido negligenciado. Dados ausentes, particularmente para tuplas
com valores ausentes para alguns atributos, podem precisar ser inferidos.
Existem muitas razões possíveis para dados ruidosos (com valores de
atributos incorretos). Os instrumentos de coleta de dados usados podem estar
com defeito. Pode ter havido erros humanos ou de computador ocorridos na

61
entrada de dados. Erros na transmissão de dados também podem ocorrer. Pode
haver limitações de tecnologia, como tamanho de buffer limitado para
coordenar a transferência e o consumo de dados sincronizados. Dados
incorretos também podem resultar de inconsistências em convenções de
nomenclatura ou códigos de dados usados ou formatos inconsistentes para
campos de entrada, como data. As tuplas duplicadas também exigem limpeza
de dados.

Figura 17 – Técnicas para preparação dos dados

As rotinas de limpeza de dados funcionam para limpar os dados,

preenchendo valores ausentes, suavizando dados ruidosos, identificando ou
removendo valores discrepantes e resolvendo inconsistências. Se os usuários
acreditarem que os dados estão sujos, é improvável que eles confiem nos
resultados de qualquer mineração de dados que tenha sido aplicada a eles.
Além disso, dados sujos podem causar confusão para o procedimento de
mineração, resultando em resultados não confiáveis. Embora a maioria das
rotinas de mineração tenha alguns procedimentos para lidar com dados
62
incompletos ou ruidosos, eles nem sempre são robustos. Em vez disso, eles
podem se concentrar em evitar sobrecarregar os dados para a função que está
sendo modelada. Portanto, uma etapa útil de pré-processamento é executar
seus dados por meio de algumas rotinas de limpeza de dados.
Voltando à sua tarefa na AllElectronics, suponha que você gostaria de
incluir dados de várias fontes em sua análise. Isso envolveria a integração de
vários bancos de dados, cubos de dados ou arquivos, ou seja, integração de
dados. No entanto, alguns atributos que representam um determinado conceito
podem ter nomes diferentes em bancos de dados diferentes, causando
inconsistências e redundâncias. Por exemplo, o atributo para identificação do
cliente pode ser referido como ID do cliente em um armazenamento de dados e
cust id em outro. Inconsistências de nomenclatura também podem ocorrer para
valores de atributo. Por exemplo, o mesmo primeiro nome pode ser registrado
como "Bill" em um banco de dados, mas "William" em outro e "B." no terceiro.
Além disso, você suspeita que alguns atributos podem ser inferidos de outros
(por exemplo, receita anual). Ter uma grande quantidade de dados redundantes
pode retardar ou confundir o processo de descoberta de conhecimento.
Claramente, além da limpeza de dados, medidas devem ser tomadas para
ajudar a evitar redundâncias durante a integração de dados. Normalmente, a
limpeza de dados e a integração de dados são executadas como uma etapa de
pré-processamento ao preparar os dados para um data warehouse. A limpeza
adicional de dados pode ser realizada para detectar e remover redundâncias
que podem ter resultado da integração de dados (SHMUELI, 2016).
Voltando aos seus dados, você decidiu, por exemplo, que gostaria de usar
um algoritmo de mineração à distância para sua análise, como redes neurais,
classificadores de vizinho mais próximo ou clustering. Esses métodos fornecem
melhores resultados se os dados para ser analisado foram normalizados, isto é,
escalonados para um intervalo específico como [0.0, 1.0]. Seus dados do cliente,
por exemplo, contêm os atributos idade e salário anual. O atributo salário anual
geralmente leva valores muito maiores que a idade. Portanto, se os atributos
não forem normalizados, as medições de distância feitas no salário anual
geralmente superam as medidas de distância feitas com a idade. Além disso,
seria útil para sua análise obter informações agregadas sobre as vendas por
região do cliente - algo que não faz parte de nenhum cubo de dados pré-
computados em seu data warehouse.
Você logo percebe que as operações de transformação de dados, como
normalização e agregação, são procedimentos adicionais de pré-processamento
de dados que contribuiriam para o sucesso do processo de mineração.
"Hmmm", você se pergunta, ao considerar seus dados ainda mais. “O conjunto

63
de dados que eu selecionei para análise é ENORME, o que certamente
desacelerará o processo de mineração.
Existe alguma maneira de reduzir o tamanho do meu conjunto de dados,
sem comprometer os resultados de mineração de dados? ”A redução de dados
obtém uma representação reduzida do conjunto de dados que é muito menor
em volume, mas produz o mesmo (ou quase o mesmo) resultados. Existem
várias estratégias para redução de dados. Estes incluem agregação de dados
(por exemplo, construção de um cubo de dados), seleção de subconjunto de
atributos (por exemplo, remoção de atributos irrelevantes através de análise de
correlação), redução de dimensionalidade (por exemplo, usando esquemas de
codificação como codificação de comprimento mínimo) e redução de
numerosidade (por exemplo, “substituindo” os dados por representações
alternativas menores, como clusters ou modelos paramétricos).
Os dados também podem ser “reduzidos” pela generalização com o uso
de hierarquias conceituais, onde conceitos de baixo nível, como cidade para
localização do cliente, são substituídos por conceitos de nível superior, como
região ou província ou estado. Uma hierarquia conceitual organiza os conceitos
em níveis variados de abstração. A discretização de dados é uma forma de
redução de dados que é muito útil para a geração automática de hierarquias
conceituais a partir de dados numéricos.
Em resumo, os dados do mundo real tendem a ser sujos, incompletos e
inconsistentes. As técnicas de pré-processamento de dados podem melhorar a
qualidade dos dados, ajudando a melhorar a precisão e a eficiência do processo
de mineração subsequente. O pré-processamento de dados é um passo
importante no processo de descoberta de conhecimento, porque as decisões
de qualidade devem ser baseadas em dados de qualidade. Detectar anomalias
de dados, retificá-las precocemente e reduzir os dados a serem analisados pode
levar a enormes retornos para a tomada de decisões (SHMUELI, 2016).

Considerações Finais

Neste estudo aprendemos sobre data mining e como os isso podem ser
aplicados aos projetos de software orientados a decisões. Esses modelos e
técnicas são fundamentais para a criação de decisões baseadas na descoberta
de conhecimento que seriam mais difíceis cm as técnicas convencionais.

64
UNIDADE 5 – Cenários de Utilização

Objetivos de aprendizagem
 Cenários comuns de utilização dos modelos de dados alternativos
 Como evitar os modismos
 Boas práticas de modelagem

Cenários comuns de utilização dos modelos alternativos

Quando tratamos de modelos de dados alternativos é importante

entender bem os cenários de utilização dos mesmos. Por exemplo, a utilização
de um modelo NoSQL para um problema que tenha a necessidade de ACID
provavelmente não será uma boa ideia. Dessa forma, o entendimento claro do
problema a ser resolvido facilita muito a escolha do modelo.

Modelos NoSQL

Os modelos NoSQL podem ser empregados em cenários onde a

escalabilidade tem maior importância do que o controle transacional ACID. Com
isso podemos resolver varias requisições simultâneas sem os mecanismos de
bloqueios dos bancos de dados transacionais. Além disso, são extremamente
uteis para armazenamento de documentos como vídeos, fotos, musicas e
demais arquivos que seriam custoso para um banco de dados convencional
administrar.
Modelos de dados NoSQL permitem também o escalonamento
horizontal, ou seja, a adição de computadores no em um arranjo conectados via
rede que permite com que o processamento seja distribuído ao longo deles.
Isso tem uma serie de benefícios como por exemplo permitir a substituição
quando necessário sem a parada do serviço.

#ATENÇÃO#
Os modelos NoSQL tem algumas finalidades especificas. Evite eles quando o
padrão ACID for mais importante do que o BASE.
#ATENÇÃO#

65
Modelos Data Warehouse

Os modelos de dados para data warehouse são principalmente utilizados

para sistemas de suporte a decisão. Eles são orientados a consultas e permitem
que os usuários possam obter informações valiosas (pela combinação de várias
tabelas) que seriam impossível de se obter no modelo OLTP.
Além disso, esse modelo permite armazenar dados de forma temporal
podendo mostrar como os mesmos eram em um determinado período sem a
necessidade de combinações computacionais custosas.

Modelos Data Mining

Os modelos de data mining são utilizados para suporte a algoritmos de

classificação, associação, agrupamento e detecção de anomalias. Esses
algoritmos precisam de estrutura de dados próprias para que os mesmo possam
ser executados com precisão em com um custo computacional adequado.
O resultado desses algoritmos são modelos de dados que podem ser
armazenados no formato de arvores, grafos e demais para prover a predição
dos mais variados problemas.

Como evitar modismos

Uma fenômeno comum que acontece quando começamos a dominar a

utilização dos modelos de dados são os modismos. Isso faz com que as pessoas
tentem adotar modelos que não são adequados para o problema existente.
Geralmente, os desenvolvedores gostam de utilizar esses modelos por
curiosidade e com a justificativa que sejam uteis para o projeto em questão. Do
ponto de vista arquitetural isso é chamado de complexidade acidental. Dessa
forma, utilize os modelos caso seja necessário.

Boas práticas de modelagem

66
 Ao projetar modelos de dados alternativos precisamos saber como criar
as entidades e principalmente como as mesmas se relacionam entre si. Dessa
forma, a utilização de modelos como NoSQL, DW e DM podem ajudar nessa
tarefa. Além disso, podemos lançar mão dos modelos de dados para criar uma
estrutura que possa acomodar facilmente modificações que possam (em
sempre vão) surgir e se não bem projetado, haverá sempre muito esforço para
modificar o software evitando os efeitos colaterais.

Considerações Finais

Nesse estudo abordamos os cenários de utilização dos modelos de dados. Isso é

importante para o entendimento claro de como podemos resolver um determinado
problema. A escolha do modelo certo pode ajudar muito na solução do mesmo. Utilize esses
modelos com sabedoria e sempre com o objetivo de resolver um problema real e bem
definido.

67
Referências

HAN, Jiawei e KAMBER, Micheline. Data Mining: Concepts and Techniques,

Second Edition, Elsevier Inc, 2006

SHMUELI, Galit, BRUCE, Peter C., STEPHENS, Mia L. e PATEL, Nitin R. Data
Mining for Business Analytics: Concepts, Techniques, and Applications, Wiley,
2016

ROKACH, Lior, MAIMON, Oded, MAIMON, Oded Z. Data Mining with Decision
Trees:Theory and Applications. WSPC, 2014.

SULLIVAN, Dan. NoSQL for Mere Mortals. Addison-Wesley Professional, 2015.

KIMBALL, Ralph, ROSS, Margy. The Data Warehouse Toolkit: The Definitive
Guide to Dimensional Modeling, Wiley, 2013.

68