UEMG-
Universidade do Estado de Minas Gerais Campus de Frutal
Curso: Sistemas
de Informação, 5º período, noturno
Disciplina:
Banco de Dados II
Docente: Prof.
Dr. Geraldo Corrêa
Discentes:
Mariana Pereira, Jean Nelson e Heitor Souza
Trabalho: Data
Warehouse e Olap
Sumário
1
INTRODUÇÃO
Os sistemas de apoio à decisão são sistemas que ajudam
na análise de informações do negócio. Sua meta é ajudar a administração a
“definir tendências, apontar problemas e tomar... decisões inteligentes”. As
raízes de tais sistemas surgiram nas décadas de 1940 e 1950, antes mesmo que os
computadores estivessem disponíveis.
A
ideia básica era coletar dados e reduzi-los para que fossem utilizados para
analisar e modificar o comportamento do negócio.
No final dos anos 1960 surgiram os primeiros sistemas
de apoio a decisão que utilizavam computadores para. Esses primeiros sistemas
de computadores ficaram conhecidos inicialmente como sistemas de decisões
gerenciais; mais tarde, eles também se tornaram conhecidos como sistemas de
informações gerenciais. Hoje se usa o termo sistemas de apoio à decisão, por
sistemas de informações gerenciais ser um termo bastante genérico.
Na década de 1970 começou o
desenvolvimento de linguagens de consulta que possibilitou que uma pessoa com
treinamento adequado pudesse estar realizando consultas ao depósito de dados
sem precisar esperar pela ajuda do departamento de TI.
Os depósitos de dados da época eram
arquivos simples antes da utilização de bancos de dados relacionais,
necessitando que esses dados fossem copiados em arquivos antes de se tornarem
disponíveis para o sistema de apoio à decisão. Somente no início dos anos
oitenta, os bancos de dados relacionais começaram a ser usados em lugar de
arquivos simples para fins de apoio à decisão.
2
ASPECTOS DO APOIO À DECISÃO
Uma das principais
características dos bancos de dados de apoio à decisão é que este é um banco de
dados basicamente de leitura visto que raramente são feitas atualizações no
banco, pois é esperado que as informações estavam corretas no momento da
inserção não havendo necessidade de corrigi-las.
Esses bancos também se caracterizam por terem
consultas bastante complexas, com expressões na cláusula WHERE que difíceis de
escrever, difíceis de entender e difíceis para o sistema lidar com elas.
Com
a tecnologia da época, outro problema muito comum era o tempo que demorava para
se fazer consultas com junções entre tabelas. Mesmo em um banco de tamanho
moderado, fazer uma consulta com a junção entre três a quatro tabelas poderia
levar horas. Era comum que se desmembrassem essas junções a fim de facilitar o
processo, mas na maioria das vezes isso causava mais problemas do que resolvia.
3
PROJETO DE BANCOS DE DADOS PARA APOIO À DECISÃO
O
projeto do banco de dados deve ser divido em duas partes: a parte lógica e a
parte física.
O projeto lógico deve ser feito
primeiro. Nessa fase, o enfoque está em correção: as tabelas devem representar
relações de forma apropriada, garantindo assim que as operações relacionais
funcionarão como se deseja e não produzirão resultados surpreendentes. Domínios
(tipos) são especificados, as colunas definidas neles e as dependências entre
colunas são identificadas. A partir dessas informações, a normalização pode
prosseguir com a definição das restrições de integridade.
Em segundo lugar, o projeto físico deve ser
derivado do projeto lógico. Nessa fase, é claro, o foco está em eficiência de
armazenamento e desempenho. Em princípio, qualquer organização física dos dados
é permitida, desde que exista uma transformação que preserve a informação, que
possa ser expressa na álgebra relacional, entre os esquemas lógico e físico.
Observe em particular que a existência de tal transformação implica que existe
visões relacionais do esquema físico que a tornem semelhante ao esquema lógico
e vice-versa.
Ainda há a possibilidade de que
tanto o esquema lógico como o esquema físico sejam alterados ao longo do tempo,
principalmente em casos de haver alterações no esquema físico para que se possa
trabalhar de forma mais eficiente, por exemplo, com junções e o esquema lógico
precisa continuar funcionando normalmente. Isso garante que os níveis lógico e
físico trabalhem de forma individual.
Então, em teoria, se o esquema
físico é derivado do esquema lógico da maneira descrita, será alcançada a
máxima independência de dados física; qualquer atualização expressa em termos
do esquema lógico poderá ser automaticamente traduzida em uma atualização
expressa em termos do esquema físico e vice-versa, e as mudanças no esquema
físico não exigirão por si próprias mudanças no esquema lógico.
As regras de projeto lógico não
dependem do uso pretendido do banco de dados — as mesmas regras se aplicam,
independentemente dos tipos de aplicações desejados. Assim, em particular, não
deve fazer nenhuma diferença se essas aplicações são operacionais (OLTP) ou de
apoio à decisão: de qualquer modo, o mesmo procedimento de projeto deve ser
seguido.
Os bancos de dados operacionais
normalmente envolvem apenas dados atuais. Em contraste, os bancos de dados de
apoio à decisão, em geral envolvem dados históricos e, portanto, tendem a
incluir um timbre de hora na maioria ou em todos esses dados.
Os bancos de dados de apoio à
decisão tendem a ser grandes e fortemente indexados e a envolver vários tipos
de redundância controlada. O particionamento representa um ataque ao problema
do “banco de dados grande”; ele divide uma dada tabela em um conjunto de
partições disjuntas ou fragmentos para fins de armazenamento físico. Esse
particionamento pode melhorar de modo significativo a facilidade de
gerenciamento e de acesso da tabela em questão. Em geral, cada partição recebe
a atribuição de certos recursos de hardware mais ou menos dedicados (por
exemplo, disco, CPU), minimizando assim a competição por esses recursos entre
partições.
A maioria dos primeiros produtos de
SQL oferecia apenas um tipo de índice, a árvore B, mas vários outros tipos se
tornaram disponíveis ao longo dos anos, especialmente em conexão com bancos de
dados de apoio à decisão; eles incluem índices de bitmap, de hashing, de várias
tabelas (multi-table), booleanos e funcionais, além dos índices de árvore B em
si.
4
PREPARAÇÃO DE DADOS
Muitas das questões relacionadas que
envolvem o apoio à decisão estão relacionadas com as tarefas de obtenção e
preparação inicial dos dados. Os dados devem ser extraídos de várias fontes,
limpos, transformados e consolidados, carregados no banco de dados de apoio à
decisão, e depois periodicamente renovados. Cada uma dessas operações envolve
suas próprias considerações especiais.
A extração é o processo de capturar
dados de bancos de dados operacionais e outras fontes. O processo de extração
tende a ser muito intenso em termos de E/S, e assim pode interferir com
operações de missão crítica; por essa razão, ela é com frequência realizada em
paralelo (isto é, como um conjunto de subprocessos paralelos) e em nível
físico.
Poucas fontes de dados controlam a
qualidade dos dados adequadamente. Como resultado, os dados com frequência
exigem limpeza (cleansing) (em geral, batch) antes de poderem ser introduzidos
no banco de dados de apoio à decisão. Normalmente, as operações de limpeza
incluem o preenchimento de valores omitidos, a correção de erros de digitação e
outros erros de entrada de dados, o estabelecimento de abreviações e formatos
padrão, a substituição de sinônimos por identificadores padrão, e assim por
diante. Os dados reconhecidos como errados e que não podem ser limpos são
rejeitados.
Mesmo após terem sido limpos, os
dados provavelmente ainda não estarão na forma que o sistema de apoio à decisão
exige, e assim precisarão ser transformados de modo apropriado. Em geral, a
forma exigida será um conjunto de arquivos, um para cada tabela identificada no
esquema físico; como resultado, a transformação dos dados pode envolver a
divisão e/ou a combinação de registros de origem. Os erros de dados que não
foram corrigidos durante a limpeza às vezes são encontrados no decorrer do
processo de transformação. Como antes, quaisquer dados incorretos geralmente
são rejeitados. (Também como antes, as informações obtidas como parte desse
processo podem às vezes ser usadas para melhorar a qualidade da origem de
dados). Por razões de desempenho, operações de transformação frequentemente são
executadas em paralelo. Elas podem utilizar intensamente operações de E/S e da
CPU.
Os fornecedores de SGBDs deram
importância considerável à eficiência de operações de carga. Para nossos fins,
consideramos que as “operações de carga” incluem mover os dados transformados e
consolidados para o banco de dados de apoio à decisão; verificar a consistência
dos dados (isto é, fazer a verificação de integridade); e construir quaisquer
índices necessários.
A maioria dos bancos de dados de
apoio à decisão (nem todos) exige renovação periódica dos dados, a fim de
mantê-los razoavelmente atualizados. Em geral, a renovação envolve uma carga
parcial, embora algumas aplicações de apoio à decisão exijam que se descarte
tudo no banco de dados e se faça o recarregamento completo dos dados. A
renovação envolve todos os problemas associados com a carga, mas também pode
ser necessário executá-la enquanto os usuários têm acesso ao banco de dados.
Um depósito de dados operacionais
(ODS — operational data store) é uma “coleção de dados orientada por assunto,
integrada, volátil (isto é, atualizável), atual ou quase atual”. Em outras
palavras, é um tipo especial de banco de dados. A expressão orientada por
assunto significa que os dados em questão estão relacionados com algum assunto
específico (por exemplo, clientes, produtos). Um depósito de dados operacionais
pode ser usado como uma área provisória para reorganização física de dados
operacionais extraídos, para fornecer relatórios operacionais, e para dar
suporte a decisões operacionais.
5
DATA WAREHOUSES E DATA MARTS
Os sistemas operacionais normalmente
têm exigências estritas de desempenho, cargas de trabalho previsíveis, pequenas
unidades de trabalho e utilização elevada. Em contraste, os sistemas de apoio à
decisão normalmente têm requisitos de desempenho variáveis, cargas de trabalho
imprevisíveis, grandes unidades de trabalho e utilização irregular. Essas
diferenças podem tornar muito difícil combinar o processamento operacional e de
apoio à decisão dentro de um único sistema, em especial com respeito ao
planejamento da capacidade, ao gerenciamento de recursos e ao ajuste de
desempenho do sistema. Por essas razões, os administradores de sistemas
operacionais em geral relutam em permitir atividades de apoio à decisão em seus
sistemas, daí a abordagem familiar de sistema dual. observamos a propósito que
a situação nem sempre foi essa; os primeiros sistemas de apoio à decisão
funcionavam de fato sobre sistemas operacionais, mas em baixa prioridade ou
durante a chamada “janela batch”. Considerando-se recursos de computação
suficientes, há várias vantagens nessa organização, das quais talvez a mais
óbvia seja a de evitar todas as operações possivelmente dispendiosas de cópia
de dados, reformatação e transferência (etc.) exigidas pela abordagem de
sistema dual.
Um data warehouse é um tipo especial
de banco de dados. O termo parece ter tido origem no final dos anos oitenta,
embora o conceito seja um pouco mais antigo. Os data warehouses surgiram por
duas razões: primeiro, pela necessidade de fornecer uma origem de dados única,
limpa e consistente para fins de apoio à decisão; segundo, pela necessidade de
fazê-lo sem causar impacto sobre os sistemas operacionais.
Por definição, as cargas de trabalho
de data warehouses são cargas de trabalho de apoio à decisão e, portanto, fazem
uso intensivo de consultas além disso, os próprios armazéns de dados tendem a
ser bem grandes (frequentemente acima de 500 GB, crescendo cerca de 50% em um
ano).
Data Mart é um “depósito de dados
especializado, orientado por assunto, integrado, volátil e variável no tempo
que fornece apoio a um subconjunto específico de decisões da gerência”. Como
podemos ver, as principais distinções entre um data marts e um data warehouse
são as de que um data warehouse é especializado e volátil. Por especializado,
queremos dizer que ele contém dados para apoio a uma área específica (somente)
de análise de negócios; por volátil, queremos dizer que os usuários podem
atualizar os dados, e talvez até mesmo criar novos dados (isto é, novas
tabelas) para algum propósito.
Uma decisão importante a ser tomada
no projeto de qualquer banco de dados de apoio à decisão é a granularidade do
banco de dados. O termo granularidade se refere aqui ao nível mais baixo de
agregação de dados que será mantido no banco de dados. Agora, a maioria das
aplicações de apoio à decisão exige acesso a dados de detalhe mais cedo ou mais
tarde; assim, no caso do data warehouse, a decisão é fácil. Para um data mart,
ela pode ser mais difícil. Extrair grandes quantidades de dados de detalhe do
data warehouse e armazená-los no data mart pode ser muito ineficiente se esse
nível de detalhe não for necessário com muita frequência.
6
PROCESSAMENTO ANALÍTICO ON-LINE
O
termo processamento analítico on-line (ou OLAP, de “online analytical
processing”) foi cunhado em um white paper escrito para a Arbor Software Corp. em
1993, embora (como ocorre com o termo “data warehouse”), o conceito seja muito
mais antigo. Ele pode ser definido como “o processo interativo de criar,
administrar, analisar e gerar relatórios sobre dados” — e é habitual
acrescentar que os dados em questão são percebidos e manipulados como se
estivessem armazenados em um “array multidimensional”.
O processamento analítico exige
invariavelmente algum tipo de agregação de dados, normalmente de muitos modos
diferentes (isto é, de acordo com muitos agrupamentos diferentes). De fato, um
dos problemas fundamentais do processamento analítico é que o número de
agrupamentos possíveis se torna muito grande bem depressa. E ainda que os
usuários precisam considerar todos ou a maioria deles. Agora, é claro que as linguagens
relacionais oferecem suporte para tal agregação, mas cada consulta individual
em uma dessas linguagens produz apenas uma tabela como seu resultado (e todas
as linhas nessa tabela têm a mesma forma e o mesmo tipo de interpretação).
Desse modo, obter n agrupamentos distintos exige n consultas distintas e produz
n tabelas de resultados distintas.
Os produtos de OLAP frequentemente
exibem resultados de consultas não como tabelas no estilo de SQL, mas como
tabulações cruzadas.
O MOLAP envolve um banco de dados
multidimensional, um banco de dados no qual os dados estão armazenados
conceitualmente nas células de um array multidimensional. O SGBD de suporte é
chamado SGBD multidimensional. Como um exemplo simples, os dados poderiam ser
representados como um array de três dimensões, correspondendo a produtos,
clientes e períodos de tempo, respectivamente; cada valor de célula individual
pode então representar a quantidade total do produto indicado vendido ao
cliente indicado no período de tempo indicado.
7
MINERAÇÃO DE DADOS
A mineração de dados pode ser
descrita como “análise de dados exploratória”. O objetivo é procurar padrões
interessantes nos dados, padrões que possam ser usados para definir a
estratégia do negócio ou para identificar um comportamento pouco usual (por
exemplo, um aumento súbito na atividade de um cartão de crédito poderia
significar que o cartão foi roubado). As ferramentas de mineração de dados
aplicam técnicas estatísticas a grandes quantidades de dados armazenados, a fim
de procurar por tais padrões. Os bancos de dados de mineração de dados com
frequência são extremamente grandes, e é importante que os algoritmos sejam
escaláveis.
8
REFERÊNCIAS
DATE,
C. J. Introdução a Sistemas de Banco de
Dados. Trad. Daniel Vieira. Rio de
Janeiro: Elsevier, 2004.
Nenhum comentário:
Postar um comentário