Algoritmo de Data Mining para PostgreSQL

Algoritmo de Data Mining para PostgreSQL
Milton Roberto y Goya
Banco de Dados - Introdução
Desde que o homem começou a usar computadores para armazenar e
recuperar dados tem-se procurado processos para tornar essas operações
mais eficientes. Uma das tentativas nesse processo foi o uso de fitas
magnéticas em uma operação similar a que usamos para gravar filmes da
televisão em uma fita de videocassete. Essa técnica ficou conhecida como
gravação seqüencial em fita magnética.
O problema da gravação seqüencial em fita magnética é justamente o que o
nome indica: os dados são gravados sequencialmente e para chegarmos a um
dado específico temos que ler todos os que o precede. Isso não chega a ser
um problema caso precisemos acessar, realmente, todos nossos dados, mas,
se precisarmos recuperar um dado único então essa técnica mostra-se muito
pouco eficiente.
A criação de circuitos integrados na década de 60 permitiu que a fita magnética
fosse sendo substituída por unidades de disco que, hoje em dia, são
conhecidas como disco rígido, winchester ou meramente HD. A vantagem
destas unidades de disco é que elas permitem tanto a leitura/gravação de
dados de modo sequencial – da mesma forma que era feito nas fitas
magnéticas – quanto à leitura/gravação de um dado específico em qualquer
ponto do disco rígido. Esta última técnica ficou conhecida como
leitura/gravação aleatória ou, em jargão técnico, leitura/gravação randômica.
O uso da técnica de leitura aleatória é um dos fatores que permitiu que
pessoas não especializadas pudessem acessar os dados armazenados nos
computadores. Essas pessoas passaram a exigir maior acesso as informações
e fizeram brotar a necessidade de melhorar a organização dos mesmos e
dessa necessidade surgiram os primeiros bancos de dados.
Existem vários modelos de banco de dados, entre eles estão os modelos de
dados relacional, hierárquico, em redes e orientado a objeto. A principal
diferença entre eles está na maneira como os dados são vistos.
Banco de Dados Hierárquico
O primeiro modelo de banco de dados comercialmente viável foi o banco de
dados hierárquico. Foi muito popular comercialmente nas décadas de 60 e 70 e
ainda é possível encontrar sistemas utilizando este banco de dados em
equipamento de grande porte, também conhecidos como mainframe.
Este modelo é baseado em uma estrutura hierárquica similar a estrutura de um
organograma de uma empresa. No organograma existe um presidente e abaixo
dele seus subordinados e os subordinados a estes, lembrando a figura de uma
árvore. Do mesmo modo, em um banco de dados hierárquico existe uma raiz e
galhos ligados a eles, como se a estrutura toda fosse uma árvore invertida.
A raiz possui os dados principais e os galhos possuem informações adicionais
sobre os dados. Estes galhos, por sua vez, podem possuir seus próprios
galhos com mais informações adicionais.
Um dos problemas apresentado por esta arquitetura é a dificuldade em chegar
a informação desejada, exigindo um especialista no assunto para localizar um
dado específico. Para se acessar um dado que estivesse no terceiro nível das
ramificações é necessário começar da raiz, passar para o primeiro nível das
ramificações, deste para o segundo nível para, por fim, chegarmos ao terceiro
nível das ramificações.
Banco de Dados em Redes
Na tentativa de solucionar o problema de localizar os dados no banco de dados
hierárquico foi proposto – ainda na década de 60 – o banco de dados em
redes. Nesse modelo aproveitou-se a estrutura do banco de dados hierárquico
mas possibilitou a disponibilidade de acesso direto a um só galho e a partir
deste encontrar os demais galhos que estivem correlacionados a ele.
No entanto, para que esta estrutura funcione corretamente, o mesmo dado
deve estar gravado em mais de um lugar ao mesmo tempo. Chamamos de
redundância a este tipo de ocorrência.
Este modelo não teve tanta popularidade quanto o modelo hierárquico e
acabou caindo em desuso.
Banco de Dados Relacionais
No final dos anos 60, Codd – um pesquisador da IBM – e sua equipe, estavam
procurando novas maneiras de resolver os problemas apresentados pelos
modelos Hierárquico e em Rede quando trabalhavam com um volume maciço
de dados. Sendo um matemático, postulou que seria possível usar estruturas
matemáticas para resolverem muitos dos problemas apresentados pelos dois
modelos citados.
Em 1970, Codd apresentou o seu trabalho: “Um Modelo Relacional de Dados
para Grandes Banco de Dados Compartilhados”. Neste trabalho ele apresenta
o modelo relacional de banco de dados. Este modelo se baseou em duas
vertentes da matemática – teoria dos conjuntos e lógica de predicado de
primeira ordem. O modelo relacional deriva seu nome do termo “relação”, que é
uma parte da teoria dos conjuntos.
Em um modelo relacional, os dados são armazenados em relações, que são
percebidas pelo usuário como tabelas. Cada relação é composta de tuplas,
também conhecidas como registros ou linhas, e atributos, também conhecidos
como campos. A ordem física em que os registros encontram-se numa tabela
é totalmente arbitrária. Cada registro de uma tabela é identificado por um
campo que contém valores únicos. Essas duas características do modelo
relacional permitem que os dados existam independentes da forma como eles
foram fisicamente armazenados.
Então, o usuário não precisa saber o local físico de um registro para poder
trabalhar com ele. Por este lado, o modelo relacional é diferente do modelo
hierárquico e do de rede, pois nestes modelos era imprescindível que o usuário
conhecesse o desenho da estrutura para que pudesse usar os seus dados.
Esse modelo é muito usado até hoje e encontra-se em bancos de dados como
Oracle, DB2, Access e PostgreSQL, entre outros.
Banco de Dados Orientado a Objeto
Os sistemas de gerenciamento de bancos de dados relacionais foram
projetados para armazenar dados segundo a teoria dos conjuntos. Entretanto,
muitas vezes, o método mais eficiente de catalogar dados não é o método mais
eficiente de armazenar e recuperar esses dados.
A técnica de modelagem orientada a objetos normalmente é empregada nos
casos onde os dados envolvidos na aplicação apresentam uma estrutura
complexa.
Os bancos de dados relacionais funcionam bem e os dados são
adequadamente administrados como se fossem partes de uma tabela, com
tipos simples de dados, envolvendo poucas associações com dados de outras
listas. Ao lidar com dados que devem ser mantidos em estruturas complexas
interdependentes, ou quando os dados devem ser rapidamente recuperados
percorrendo caminhos de associações em vez de simplesmente procurar em
listas simples, a base de dados relacional começa a requerer características
como gerenciamento de múltiplos índices e esquemas que empregam
estruturas transversais e normalizações complexas.
A meta dos bancos de dados orientados a objetos é manter a correspondência
direta entre os objetos do mundo real e os do banco de dados, no que implica
que podemos identificar e manipular os objetos como um todo. Representar um
objeto complexo no modelo relacional significa que o objeto tem que ser
subdividido em um grande número de linhas ou tuplas, o que leva à
necessidade de realizar um considerável número de operações de junção para
recuperar o objeto.
Nos modelos de dados tradicionais os dados são vistos como uma coleção de
tipos de registros ou de relações, cada qual tendo uma coleção de linhas
armazenadas em um banco de dados. Em um modelo de dados orientado a
objetos um banco de dados é considerado como uma coleção de objetos do
mundo real.
Os bancos de dados orientados a objetos foram propostos para dar suporte às
necessidades de aplicações mais complexas, como aquelas que exigem
transações mais longas, textos longos e armazenamento de imagens.
SGBD
Um Sistema de Gerenciamento de Banco de Dados ou SGBD ou RDBMS, na
sigla em inglês, é uma coleção de programas que permitem ao usuário definir,
construir e manipular Bases de Dados para as mais diversas finalidades. Ou
seja, SGBD é uma ferramenta que permite administrar nossas bases de dados
com mais facilidade.
Para que o conjunto de programas seja considerado um SGBD ele deve
atender integralmente a seis regras:
Regra 1: Auto-Contenção - Um SGBD não contém apenas os dados em si, mas
armazena completamente toda a descrição dos dados, seus relacionamentos e
formas de acesso. Normalmente esta regra é chamada de meta-base de dados
ou dicionário de dados.
Regra 2: Independência dos Dados - Quando as aplicações estiverem
realmente imunes a mudanças na estrutura de armazenamento ou na
estratégia de acesso aos dados, podemos dizer que esta regra foi atingida.
Regra 3: Abstração dos Dados - É fornecida ao usuário somente uma
representação conceitual dos dados, o que não inclui maiores detalhes sobre
sua forma de armazenamento real. O chamado Modelo de Dados é um tipo de
abstração utilizada para fornecer esta representação conceitual. Neste modelo,
um esquema das tabelas, seus relacionamentos e suas chaves de acesso são
exibidas ao usuário, porém nada é afirmado sobre a criação dos índices, ou
como serão mantidos, ou qual a relação existente entre as tabelas que deverá
ser mantida íntegra.
Regra 4: Visões - Cada usuário pode vir a visualizar os dados de forma
diferente daquela existente previamente no Banco de Dados. Uma visão
consiste de um subconjunto de dados do Banco de Dados, necessariamente
derivados dos existentes no Banco de Dados, porém estes não deverão estar
explicitamente armazenados.
Regra 5: Transações - Deve gerenciar completamente a integridade referencial
definida em seu esquema, sem precisar em tempo algum, do auxílio do
programa aplicativo. Desta forma exige-se que o banco de dados tenha ao
menos uma instrução que permita a gravação de uma série modificações
simultâneas e uma instrução capaz de cancelar uma série modificações. Por
exemplo, imaginemos que estejamos cadastrando um pedido para um cliente,
que este deseje reservar 5 itens de nosso estoque, que estão disponíveis e,
portanto são reservados, porém existe um bloqueio financeiro (duplicatas em
atraso) que impede a venda. A transação deverá ser desfeita com apenas uma
instrução ao Banco de Dados, sem quaisquer modificações suplementares nos
dados.
Regra 6: Acesso Automático – Deve resolver automaticamente as situações
onde um usuário bloqueie o recurso que outro usuário deseja utilizar.
Os SGBD tem, ainda, sete características operacionais elementares sempre
observadas:
Característica 1: Controle de Redundâncias - A redundância consiste no
armazenamento de uma mesma informação em locais diferentes, provocando
inconsistências. Em um Banco de Dados as informações só se encontram
armazenadas em um único local, não existindo duplicação descontrolada dos
dados. Quando existem replicações dos dados, estas são decorrentes do
processo de armazenagem típica do ambiente Cliente-Servidor, totalmente sob
controle do Banco de Dados.
Característica 2: Compartilhamento dos Dados - Deve incluir software de
controle de concorrência ao acesso dos dados, garantindo em qualquer tipo de
situação a escrita/leitura de dados sem erros.
Característica 3: Controle de Acesso - Deve dispor de recursos que
possibilitem selecionar a autoridade de cada usuário. Assim um usuário poderá
realizar qualquer tipo de acesso, outros poderão ler alguns dados e atualizar
outros e outros ainda poderão somente acessar um conjunto restrito de dados
para escrita e leitura.
Característica 4: Interfaceamento - Deve disponibilizar formas de acesso
gráfico, em linguagem natural, em SQL ou ainda via menus de acesso, não
sendo uma "caixa-preta" somente sendo passível de ser acessada por
aplicações.
Característica 5: Esquematização - Deve fornecer mecanismos que
possibilitem a compreensão dos relacionamentos existentes entre as tabelas e
de sua eventual manutenção.
Característica 6: Controle de Integridade - Deve impedir que aplicações ou
acessos pelas interfaces possam comprometer a integridade dos dados.
Característica 7: Backup - O SGBD deverá apresentar facilidade para recuperar
falha de hardware e software, através da existência de arquivos de pré-imagem
ou de outros recursos automáticos, exigindo minimamente a intervenção de
pessoal técnico.
Software Livre
Em 1984, o idealizador do software livre, Richard Stallman, definiu software
livre como sendo “liberdade dos usuários executarem, copiarem, distribuírem,
estudarem, modificarem e aperfeiçoarem o software”. Mais precisamente, ele
se refere a quatro tipos de liberdade, para os usuários do software:
“Liberdade de executar o programa, para qualquer propósito.
Liberdade de estudar como o programa funciona, e adaptá-lo para as
suas necessidades. Aceso ao código-fonte é um pré-requisito para esta
liberdade.
Liberdade de redistribuir cópias de modo que você possa ajudar ao seu
próximo.
Liberdade de aperfeiçoar o programa, e liberar os seus
aperfeiçoamentos, de modo que toda a comunidade se beneficie.
Acesso ao código-fonte é um pré-requisito para esta liberdade.”
SQL
Em 1974 dois pesquisadores da IBM, Chamberlim e Boyce, publicaram um
artigo intitulado “SEQUEL: A Structured English Query Language”. Nesse artigo
propunham uma forma de acessar os dados na estrutura relacional proposta
por Codd usando uma seqüência de comando o mais próximo possível da
linguagem natural do usuário. Junto com o artigo apresentaram um protótipo da
IBM chamado SEQUEL-XRM.
Por motivos jurídicos o SEQUEL-XRM mudou de nome para SQL no início da
década de 80. O equilíbrio entre a facilidade de uso e o poder de seus recursos
fez com que o SQL atingisse enorme popularidade entre seus usuários vindo a
tornar-se, em 1987, padrão para todos os SGBD relacionais.
O que é o PostgreeSQL?
O PostgreSQL é um sistema de gerenciamento de banco de dados relacional e
orientado a objetos (SGBD) em código livre. Permite executar várias operações
do SQL (Linguagem de Pesquisa Estruturada - Strutured Query Language),
incluindo subquerys, transações, funções, tipos definidos pelo usuário (UDT –
User Defined Type) e funções definidas pelo usuário (UDF – User Defined
Function). Ele é o mais avançado banco de dados de código livre disponível.
Seu código-fonte e binários pré-compilados estão disponíveis para diversas
plataformas. Optei trabalhar com a versão 7.4 por ser a versão mais recente do
software em plataforma Windows XP. Esta plataforma foi escolhida devido a
sua facilidade de uso.
O PostgreSQL - conhecido anteriormente como Postgres95 - derivou do projeto
POSTGRES da universidade de Berkley, cuja última versão foi a 4.2. O
POSTGRES foi originalmente patrocinado pelo DARPA (Agência de Projetos
de Pesquisa Avançada para Defesa), ARO (Departamento de Pesquisa Militar),
NSF (Fundação Cientifica Nacional) e ESL Inc.
Monjian (2004) conta que a implementação do projeto POSTGRES iniciou em
1986, já em 87 tornou-se operacional. A primeira versão lançada para o público
externo foi em 1989. Devido a uma crítica feita ao seu sistema de regras, o
POSTGRES teve essa parte re-implementada e lançada em uma segunda
versão em 1990. Em 1991 foi lançada a versão 3, com melhorias no executor
de consultas e algumas partes do código foram re-escritas. As versões
subseqüentes, até o Postgres95, foram focadas em confiabilidade e
portabilidade.
Segundo Lane (2004), o POSTGRES foi utilizado para diversos sistemas de
pesquisa e de produção, entre eles, um banco de dados com rotas de
asteróides e diversos sistemas de informações geográficas.
O código do POSTGRES foi aproveitado em um produto comercializado pela
Illustra Information Technologies (posteriormente incorporada à Informix, que
agora pertence à IBM).
A versão seguinte, o Postgres95, teve mudanças radicais em relação ao
projeto original. O seu código foi totalmente revisado, o tamanho dos fontes foi
reduzido em 25%, e a linguagem SQL foi implementada como interface padrão.
A performance foi consideravelmente melhorada e vários recursos foram
adicionados.
Em 1996 o nome Postgres95 tornou-se inadequado, o projeto foi rebatizado
"PostgreSQL", para enfatizar a relação do POSTGRES original com a
linguagem SQL. A numeração da versão voltou a seguir o padrão anterior ao
Postgres95 (considerada a 5.0), e a primeira versão do PostgreSQL foi a 6.0.
Enquanto a ênfase do Postgres95 tinha sido a correção de falhas e otimização
do código, o desenvolvimento das primeiras versões do PostgreSQL foi
orientada à melhoria de recursos e implementação de novos recursos, sempre
seguindo os padrões de SQL anteriormente estabelecidos.
“O Grupo Global de Desenvolvimento do PostgreSQL tem membros nos
Estados Unidos, Brasil, Canadá, Japão, Rússia, Portugal, Alemanha,
Suécia, Suíça, Hungria, Polônia, Turquia entre outros. Esse grupo é
formado essencialmente por empresas especializadas em PostgreSQL,
empresas usuárias do sistema, além dos pesquisadores acadêmicos e
programadores independentes. Além da programação, essa comunidade
é responsável pela documentação, tradução, criação de ferramentas de
modelagem e gerenciamento, e elaboração de extensões e acessórios.
Pela riqueza de recursos e conformidade com os padrões, ele é um
SGBD muito adequado para o estudo universitário do modelo relacional,
além de ser uma ótima opção para empresas implementarem soluções
de alta confiabilidade sem altos custos de licenciamento. É um programa
distribuído sob a licença BSD, o que torna o seu código fonte disponível
e o seu uso livre para aplicações comerciais ou não.“ (PostgreSQL,
2003, 12 p. - Tradução livre, minha)
O que é Data Mining?
“Data Mining é um processo analítico projetado para explorar grandes
quantidades de dados (tipicamente relacionados a negócios, mercado ou
pesquisas científicas), na busca de padrões consistentes e/ou relacionamentos
sistemáticos entre variáveis e, então, validá-los aplicando os padrões
detectados a novos subconjuntos de dados.” (Werneck, 2003)
Usama Fayyad (Fayyad et al. 1996) define como sendo:
"...o processo não-trivial de identificar, em dados, padrões válidos, novos,
potencialmente úteis e ultimamente compreensíveis"
Esse processo vale-se de diversos algoritmos que processam os dados e
encontram esses padrões. É preciso ressaltar que embora os algoritmos atuais
sejam capazes de descobrir padrões, ainda não temos uma solução eficaz para
determinar padrões valiosos.
Por essa razão, Data Mining ainda requer uma interação muito forte com
analistas humanos, que são, em última instância, os principais responsáveis
pela determinação do valor dos padrões encontrados. O mesmo é feito na
condução (direcionamento) da exploração de dados e, este aspecto, não pode
ser desprezado em nenhum projeto que queira ser bem sucedido. Han (1996)
ainda nos diz:
“Data Mining é parte de um processo maior de conhecimento denominado
Knowledge Discovery in Database (KDD). KDD consiste, fundamentalmente, na
estruturação do banco de dados; na seleção, preparação e pré-processamento
dos dados; na transformação, adequação e redução da dimensionalidade dos
dados; no processo de Data Mining; e nas análises, assimilações,
interpretações e uso do conhecimento extraído do banco de dados, através do
processo de Data Mining.” (tradução livre minha).
Bibliografia
Codd, E.F.. A Relational Model of Data for Large Shared Data Banks. In:
Communications of the ACM, Vol. 13, No. 6, June 1970, pp. 377-387.
Disponível em: < http://www.acm.org/classics/nov95/toc.html >, Acesso em 01
ago 2004, 12:13:00
Chamberlin, D.; Boyce, R.. SEQUEL: A Structured English Query Language.
IBM
Research
Laboratory,
1975.
Disponível
em:
<
http://www.cs.uml.edu/~cchen/574-F03/reading/cb74.pdf >, Acesso em 01 ago
2004, 16:47
Fayyad, Usama; Piatetski-Shapiro, Gregory; Smyth, Padhraic. The KDD
Process for Extracting Useful Knowledge from Volumes of Data. In:
Communications of the ACM, pp.27-34, Nov.1996
Groth, R. Data Mining, A Hands-on Approach for Business Professionals.
Prentice-Hall PTR. 1998
Han, Jiawei; Fu, Yongjian. Discovery of Multiple-Level Association Rules
From Large Databases. Proceedings of 21st VLDB Conference. 1995
JOHNSON, Deborah G., NISSENBAUM, Helen. Computers, Ethics & Social
Values. USA, Prentice HallInc. 1995.
LANE, Tom. A Tour of PostgreSQL Internals. Great Brigde. Disponível em: <
http://developer.postgresql.org/pdf/tour.pdf>, Acesso em 10 abr 2004, 22:50:00.
MEDEIROS, Rosalvo. O Impacto dos Requisitos Fixados pelo Cliente na Produção
de Software. Dissertação apresentada ao Programa de Pós-Graduação em Engenharia
de Produção da Universidade Federal de Santa Catarina como requisito parcial para
obtenção do título de Mestre em Engenharia de Produção. Florianópolis, 2000.
MOMJIAN, Bruce. Mastering PostgreSQL Administration, Software Research
Associates. Disponível em <http://candle.pha.pa.us/main/writings/pgsql/admin.pdf>,
Acesso em 10 abr 2004, 22:15:00
Navega, Sérgio. Princípios Essenciais do Data Mining. Anais da Infoimagem
2002. Cenadem 2002.
L. Rowe; M. Stonebraker, The Postgres data model, Proc. VLDB Conference,
Sept. 1987. Disponível em <http://db.cs.berkeley.edu//papers/ERL-M87-13.pdf
>. Acesso em 12 abr 2004, 21:30:00
M. Stonebraker; L. Rowe, The design of Postgres, Proc. ACM-SIGMOD
Conference on Management of Data, May 1986. Disponível em < http://s2kftp.cs.berkeley.edu:8000/postgres/papers/ERL-M85-95.pdf >. Acesso em 12
abr 2004, 21:42:00
M. Stonebraker, The design of the Postgres storage system, Proc. VLDB
Conference, Sept. 1987. Disponível em <http://db.cs.berkeley.edu//papers/ERLM87-06.pdf>. Acesso em 12 abr 2004, 21:42:00
M. Stonebraker; M. Hearst; S. Potamianos, A commentary on the POSTGRES
rules system, SIGMOD Record 18(3), Sept. 1989. Disponível em
<http://db.cs.berkeley.edu//papers/ERL-M89-82.pdf >. Acesso em 12 abr 2004,
21:53:00
M. Stonebraker, The case for partial indexes, SIGMOD Record 18(4), Dec.
1989, 4-11. Disponível em < http://db.cs.berkeley.edu//papers/ERL-M89-17.pdf
>. Acesso em 13 abr 2004, 14:12:00
M. Stonebraker; L. A. Rowe; M. Hirohama, The implementation of Postgres,
Transactions on Knowledge and Data Engineering 2(1), IEEE, March 1990.
Disponível em <http://db.cs.berkeley.edu//papers/ERL-M90-34.pdf>. Acesso em
13 abr 2004, 14:52:00
M. Stonebraker; A. Jhingran; J. Goh; S. Potamianos, On Rules, Procedures,
Caching and Views in Database Systems, Proc. ACM-SIGMOD Conference
on
Management
of
Data,
June
1990.
Disponível
em
<http://db.cs.berkeley.edu//papers/ERL-M90-36.pdf>. Acesso em 13 abr 2004,
15:02:00
POSTGRESQL. PostgreSQL 7.3.2 Documentation, USA, 2003
Werneck, Paul. Data Warehouse and Data Mining. IBM. USA. 2003