Vous êtes sur la page 1sur 9

UNIVERSIDADE ESTADUAL DE MONTES CLAROS - UNIMONTES CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS - CCET DEPARTAMENTO DE CIÊNCIAS DA COMPUTAÇÃO CURSO DE SISTEMAS DE INFORMAÇÃO

POSTGRESQL

Montes Claros

abril/2011

UNIVERSIDADE ESTADUAL DE MONTES CLAROS - UNIMONTES CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS - CCET DEPARTAMENTO DE CIÊNCIAS DA COMPUTAÇÃO CURSO DE SISTEMAS DE INFORMAÇÃO

Autores:

Farlley Barbosa Gonçalves Fred Willian de Freitas Santos Paulo Evaristo Cabral de Oliveira Otalino Geraldino Soares Junior

POSTGRESQL

Trabalho apresentado à disciplina de Banco de Dados I como requisito de avaliação parcial orientado pelo professor Leandro Clementino.

Montes Claros

abril/2011

RESUMO

O PostgreSQL é um SGBD objeto-relacional, com vários recursos para a elaboração e otimização

de projetos físicos de bancos de dados. Surgido como um software acadêmico, ele é utilizado hoje por várias empresas de diversas áreas de negócio. Nesse relatório, fazemos uma análise das principais carac- terísticas do PostgreSQL, especialmente daquelas ligadas à elaboração de projetos de bancos de dados.

1 INTRODUÇÃO

Desde os primórdios o homem teve a necessidade de armazenar dados. Os dados eram escritos

para fazer controle ou informar outras pessoas.O único meio físico disponível para registrar dados eram as paredes das cavernas, e, posteriormente, com o desenvolvimento do papel este passou a ser o meio físico de registro. Com a evolução da sociedade foram criados métodos e processos para manipular e arquivar dados registrados em papel. Com o advento da tecnologia e substituição do registro em papel pelo registro digital inicou a busca por melhores métodos de armazenamento e recuperação de dados em sistemas digitais. Para armazenar e recuperar dados de forma mais eficiente em ambientes computacionais foram criados os Sistemas de Gerenciamento de Bandos de Dados que contém definições e regras de manipulação

e operação dos dados. Um desdes Sistemas de Gerencimanto de Banco de Dados - S.G.D.B. é o PostgreSQL que é um banco de dados objeto relacional que oferece uma boa performance, multiplataforma, escalabidade

1.1 Breve histórico

O PostgreSQL surgiu em 1977, na Califórnia, EUA, como um projeto acadêmico para a criação

de um sistema 100% Unix. Batizado inicialmente como Ingres. Posteriormente na Universidade de Berkley, um grupo de universitários desenvolveu um servidor de banco de dados objeto-relacional que foi nomeado de Posgres (“pós” Ingres). Em 1986, a empresa Illustra Corporation lançou a versão comercial do produto. Comprado pela Informix, o banco foi integrado ao Informix Universal Server. Em 1995, dois estudantes de graduação de Berkeley incrementaram o projeto, adicionando

a linguagem SQL, resultando no Postgres95. A partir de 1996, o banco ganhou o nome definitivo de PostgreSQL. E a linguagem SQL passou a ser padrão. Desde a sua criação o PostgreSQL teve enfoque na performance.

1.2 Contexto atual

O PostreSQL tem sido usado para implementar muitos aplicativos diferentes de pesquisa e de

produção, incluindo: sistema de análise de dados financeiros, pacote de monitoração de desempenho de motor a jato, banco de dados de acompanhamento de asteróides, banco de dados de informações médicas,

e vários sistemas de informações geográficas. Também tem sido usado como ferramenta educacional por várias universidades. No contexto atual o PostgreSQL concorre com o MySql como solução de banco de dados de aplicações cliente/servidor. Ambas ferramentas de gerenciamendo de Banco de Dados são Open Source mas o PosgreSQL ganha pelo fato de ser otimizado para aplicações complexas, isto é, que envolvem grandes quantidade de transações ou que tratam de informações com um maior nível de complexidade.

2 ARQUITETURA

O PostgreSQL segue a arquitetura tradicional cliente/servidor implementada pela maioria

dos SGBDs relacionais, como pode ser visto na Figura 1. O servidor PostgreSQL é quem manipula diretamente os arquivos da base de dados. As propriedades ACID (Atomicidade, Consistência, Isolamento

e Durabilidade) para transações em bancos de dados são garantidas nesta camada. Este servidor é capaz de atender simultaneamente várias conexões TPC/IP de aplicações-cliente através da rede.

No jargão de banco de dados, o PostgreSQL utiliza o modelo cliente-servidor. Uma sessão do PostgreSQL consiste nos seguintes processos (programas) cooperando entre si:

• Um processo servidor, que gerencia os arquivos de banco de dados, recebe conexões dos aplicativos cliente com o banco de dados, e executa ações no banco de dados em nome dos clientes. O programa servidor de banco de dados se chama postmaster.

• O aplicativo cliente do usuário (frontend) que deseja executar operações de banco de dados.

Os aplicativos cliente podem ter naturezas muito diversas: o cliente pode ser uma ferramenta no modo caractere, um aplicativo gráfico, um servidor Web que acessa o banco de dados para mostrar páginas Web, ou uma ferramenta especializada para manutenção do banco de dados são alguns exemplos. A interface de programação para comunicação do cliente com o servidor para uma variedade de padrões. Temos como exemplo o ODBC - plataforma Windows - e o JDBC - plataforma Java (ilustrado na figura abaixo).

- e o JDBC - plataforma Java (ilustrado na figura abaixo). Figura 1 - Arquitetura cliente/servidor

Figura 1 - Arquitetura cliente/servidor do PostgreSQL

O servidor PostgreSQL pode tratar várias conexões simultâneas de clientes. Para esta finalidade

é iniciado um novo processo para cada conexão. Deste ponto em diante, o cliente e o novo processo

servidor se comunicam sem intervenção do processo postmaster original. Portanto, o postmaster está sempre executando aguardando por novas conexões dos clientes, enquanto os clientes e seus processos servidor associados surgem e desaparecem (obviamente tudo isso é invisível para o usuário, sendo mencionado somente para ficar completo). Como em todos os bancos de dados relacionais, os dados gerenciados pelo PostgreSQL são armazenados em tabelas. Cada tabela é identificada por um nome e pertence a um esquema. Seus metadados são definidos por meio de colunas e, a cada nova informação inserida, uma tupla (ou registro)

é criada.

3

CARACTERÍSTICAS PRINCIPAIS

• Propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade) para as transações.

• Performance bastante admirável- O PostgreSQL é bastante avançado, suportando a maioria das

características esperadas em um sistema gerenciador de bancos de dados moderno.

• Multi-plataforma.

• Altamente escalável.- Característica do sistema ou equipamento que pode crescer em escala, isto

é, que possibilita incrementos de capacidade ou funcionalidades acompanhando as necessidades dos

usuários

• Excelente segurança- implementa o esquema de segurança usando a própria estrutura do banco de

dados, ou seja, ele abre o banco de dados para verificar segurança . O PostgreSQL consegue filtrar acessos antes mesmo de abrir o seu banco de dados interno.

• Stored Procedures: Usando stored procedures o programador pode realizar um grande número de operações dentro do próprio banco, aumentando o desempenho geral da aplicação.

• Altamente Extensível: o PostgreSQL possui uma característica bastante interessante que é a

possibilidade de se utilizar operadores, tipos de dados, estruturas e métodos de acesso definidos pelo usuário (o programador do sistema).

• Banco de Dados "Relacional a Objetos": o banco de dados possui algumas características de

orientação a objetos, como herança, por exemplo. Por isso, o PostgreSQL é, por vezes, chamado de banco

de dados "relacional a objetos" e não só um banco de dados relacional

• Características de Bancos Relacionais: quase todas as características esperadas em um banco de

dados relacional são encontradas no PostgreSQL, como consultas declarativas em SQL, otimizações de consultas, controle de concorrência, transações e multiusuário.

• Integridade Referencial: é uma característica da última versão do PostgreSQL. O banco de dados

agora suporta a integridade referencial de dados, característica muito útil que antes não era implementada.

4 FUNCIONALIDADES MAIS RELEVANTES E INOVADORAS

No que diz respeito ao projeto físico do banco de dados nos SGDBs relacionais, podemos dizer que os tipos dos recursos disponíveis são similares, variando, principalmente, quanto à forma de implementação. Se tratando do PostgreSQL podemos citar algumas funcionalidades:

4.1 Tabelas Assim como em todos os bancos de dados relacionais, os dados gerenciados pelo PosgreSQL são armazenados em tabelas:

CREATE TABLE capitals ( name text, population real, altitude int, state char(2) );

Apesar de o PostgreSQL não ser um Sistema de Gerência de Banco de Dados Orientado a Objetos, podemos utilizar o conceito de herança entre tabelas pela sua característica auto-relacional. Ou seja, se uma tabela é “descendente” de outra, todas as propriedades da primeira são, também, propriedades da segunda.

CREATE TABLE cities ( name text, population real, altitude int ); CREATE TABLE capitals ( state char(2) ) INHERITS (cities);

4.2 Restrições

O PostgreSQL permite a criação das restrições sobre os valores dos atributos. Os principais tipos

de restrições são: check, not null, unique, chave primária e chave estrangeira.

• A restrição check é o tipo mais genérico. Permite especificar que o valor de uma coluna deve

satisfazer uma expressão lógica e pode se referir a vários atributos.

• A restrição not null simplesmente impede que o valor de uma coluna seja nulo. O trecho a seguir

mostra a de criação dessa restrição. Nele, os atributos product_no e name não podem assumir valores

nulos.

A restrição unique garante que o dado contido em uma coluna ou em um grupo de colunas é

único em relação a todos os registros de uma tabela.

• A chave primária identifica unicamente um registro. Tecnicamente é a combinação das restrições

unique e not null.

• A chave estrangeira garante que o valor de um determinado atributo em uma relação deve ser

igual a um dos valores existentes em um atributo de uma outra relação, por ele referenciada. Essa restrição mantém a integridade referencial do esquema.

4.3 Gatilhos

O PostgreSQL permite a criação de gatilhos (triggers) que podem ser executados antes ou após

operações de inserção, atualização e exclusão. Existem dois tipos de gatilhos que podem ser executados uma vez para cada registro modificado ou uma vez para cada instrução SQL; são, respectivamente, os gatilhos por-registro (per-row) e por-instrução (per-statement). Se mais de um gatilho for definido para o mesmo evento de uma mesma relação então eles serão executados em ordem alfabética. Cada gatilho deve ter a sua função definida em PL/pgSQL ou em alguma linguagem procedimental disponível. As funções de gatilhos por-instrução devem sempre retornar nulo enquanto que as funções de gatilhos por-registro podem retornar o registro modificado. Os gatilhos por-instrução definidos para disparar antes de uma instrução SQL, ou gatilhos “antes”, são naturalmente disparados antes que qualquer modificação seja feita. No final da execução de toda a instrução SQL serão disparados, se houver, os gatilhos definidos pra disparar depois da instrução, ou gatilhos “depois”. Da mesma forma, os gatilhos por-registro definidos para disparar antes da instrução SQL são disparados imediatamente antes que cada registro em particular seja modificado. Em contrapartida, os gatilhos por-registro, definidos para disparar depois da instrução SQL, são disparados apenas no final da execução de toda essa instrução, comportando-se, nesse caso, como os gatilhos por instrução. Entretanto, nesse último caso, o gatilho por-registro será disparado antes de qualquer gatilho que seja do nível por- instrução definido para disparar após a instrução. Existem algumas regras que precisam ser conhecidas quando instruções SQL são executadas

dentro da função do gatilho. São as chamadas regras de visibilidade, que determinam se essas instruções SQL irão enxergar as mudanças de dados executadas e que ocasionaram o disparo do gatilho. Portanto, nesse ponto há dois tipos de instruções SQL: as instruções que provocaram o disparo do gatilho, e as instruções que serão executadas pelo próprio gatilho dentro da sua função. De maneira resumida, podemos dizer: as mudanças feitas por uma instrução SQL que provocou

o disparo do gatilho não serão visíveis até o fim do comando SQL se o gatilho for do tipo por-instrução e

“antes” (definido para disparar antes da instrução), no entanto, as mesmas mudanças serão visíveis durante

a execução do gatilho se for do tipo por-instrução “depois” (definido para disparar após o término da

instrução). A mesma situação pode ser aplicada para os casos dos gatilhos por-registro “antes” e “depois”. Entretanto, operações SQL executadas dentro de um gatilho do tipo por-registro “antes” verão os efeitos de mudanças ocasionadas por essa mesma operação executada no registro anterior. A ordem dessas mudanças, em geral, não é previsível.

4.4 Índices

A grande maioria dos SGBDs implementa índices para melhorar o desempenho de consultas às

suas bases de dados. De maneira geral, os índices evitam que uma tabela precise ser totalmente pesquisada na busca por registros. Dessa forma, os índices são estruturas construídas sobre as colunas escolhidas de maneira a tornar mais eficiente a localização de registros.

O PostgreSQL oferece os seguintes tipos de índice: árvore-B, árvore-R, hash e GiST. Cada tipo de

índice usa um algoritmo próprio. Cada algoritmo é melhor adaptado para algum tipo de consulta SQL. O comando CREATE INDEX irá criar, por padrão, um índice do tipo árvore-B, que se adapta melhor às

situações mais comuns.

O PostgreSQL considera o uso do índice de árvore-B quando uma coluna indexada está envolvida

em uma comparação usando os seguintes operadores: <, <=, =, >=, >. Construções equivalentes a combinações desses operadores, como BETWEEN e IN, podem ser também implementadas através do índice de árvore-B. O otimizador de consultas pode decidir usar índices de árvore-B envolvendo os operadores LIKE, ILIKE, ~, ~* se a palavra-chave procurada corresponder ao início da seqüência de caracteres, por exemplo, em LIKE 'foo%' esse fato ocorre porém, em LIKE '%foo' o padrão procurado corresponde ao fim da seqüência e, nesse caso, o índice não seria utilizado.

• Índices do tipo árvore-R são melhores para dados espaciais.

• Índices do tipo hash trabalham apenas com igualdades. Contudo, testes no PostgreSQL mostraram

que os índices de árvore-B são tão eficientes quanto os índices hash. Entretanto, o tamanho e o tempo

necessário para se construir um índice hash são muito piores. Por essas razões, os índices do tipo hash têm sem uso desencorajado.

• A classe de índices do tipo GiST oferece uma infra-estrutura em que muitas estratégias diferentes

de índices podem ser implementadas. GiST significa árvore de busca generalizada (Generalized Search

Tree). Esse tipo de índice ainda possui sérias limitações como, por exemplo, a não permissão de um acesso concorrente. O PostgreSQL também permite a criação de índices definidos em mais de uma coluna.

• Índices do tipo unique podem ser usados para reforçar a unicidade de uma coluna. O PostgreSQL

cria automaticamente esse tipo de índice quando uma restrição unique ou uma chave primária é definida

para uma tabela. Entretanto, o melhor método de se adicionar uma restrição a uma tabela é: ALTER

TABLE

ADD CONSTRAINT, e a criação explícita pelo usuário de índices do tipo unique não é

recomendada. O PostgreSQL permite que um índice seja criado também sobre uma função ou uma

expressão escalar referentes a uma ou mais colunas de uma tabela.

A classe de operador define os operadores que serão usados pelo índice na coluna especificada.

Na prática, a classe operador padrão para cada tipo de dados é suficiente. Por exemplo, um índice de árvore-B no tipo int4 irá utilizar a classe int4_ops. Essa classe de operador inclui funções de comparação

para os valores do tipo int4. No entanto, o objetivo de ter classes de operadores é que, para alguns tipos de dados, pode haver mais de um comportamento significantivo. Índices parciais podem ser criados em apenas um subconjunto dos dados de uma tabela. Esse subconjunto é definido através de expressões condicionais.

A maior motivação dos índices parciais é evitar valores comuns. Já que uma consulta por valores

comuns não irá utilizar o índice, não há razões para manter esses valores no índice. Isso irá reduzir o tamanho do índice, aumentando a velocidade de consultas e atualizações, já que o índice não precisará ser atualizado em todos os casos.

4.5 Controle de concorrência

Os SGBDs precisam de estratégias para lidar com a concorrência. A concorrência se caracteriza

quando duas ou mais sessões tentam acessar os mesmos dados ao mesmo tempo. Um dos principais objetivos dos SGBDs existentes é permitir um acesso eficiente a todas as sessões mantendo a integridade dos dados.

O PostgreSQL mantém a consistência dos dados através de um modelo de controle de

concorrência ulti-versões (Multiversion Concurrency Control, MVCC) . Isso significa que, enquanto está acessando a base de dados, cada transação “enxerga” uma “fotografia” dos dados feita há algum tempo atrás, independente de modificações que possam ter ocorrido a partir daquele momento. Essa estratégia protege a transação de ver dados inconsistentes decorrentes de atualizações concorrentes, oferecendo, assim, isolamento para cada sessão no SGBD. A principal vantagem do modelo MVCC quando comparado ao que modelo tradicional de bloqueios (locks) de dados é que os bloqueios feitos pelo MVCC para leitura não entram em conflito com aqueles feitos para escrita.

4.6 Linguagem procedimental

O PostgreSQL, assim como outro SGBDs relacionais, possui uma linguagem procedimental

própria para ser usada em trechos de código executados no servidor do SGBD. Algumas vezes,

sãonecessárias freqüentes interações entre a máquina cliente e o servidor do SGBD para a implementação de uma determinada operação. Em alguns casos, o custo da comunicaçãocliente/servidor faria com que esta operação se tornasse impraticável. Pelas características da linguagem SQL, não é possível descrever tarefas complexas em apenas uma requisição. Sendo assim, se torna necessário usar essa linguagem procedimental, que, no PostgreSQL, se denomina PL/pgSQL. Trechos de código escritos com ela, instalados junto ao servidor do SGBD, permitem que todas as solicitações sejam executadas sem a necessidade de comunicação com o cliente. O cliente dispara a solicitação para o servidor do PostgreSQL, chamando o programa escrito em PL/pgSQL, que é processado no servidor, e aguarda um aviso de retorno do programa juntamente com algum possível valor de resposta. A vantagem destas linguagens procedimentais dentro do servidor do SGBD é que todas as consultas SQL são embutidas no código de forma transparente. A linguagem suporta naturalmente todos os tipos previstos na SQL.

O PL/pgSQL é utilizado para implementar funções e gatilhos (triggers) no ostgreSQL.

4.7 Privilégios

Todo SGBD possui uma cadastro de usuário que podem acessar seus recursos. O cadastro de usuário é separado daquele do sistema operacional em que o SGBD é executado. Este cadastro não só define quem tem acesso à base de dados, mas também deve determinar qual é o nível do acesso que cada um pode ter a cada objeto dessa base. Entendemos nível de acesso como permissão de operações de leitura, criação, alteração e remoção e objetos de qualquer dado ou metadado do banco de dados.

No momento em que a base de dados do PostgreSQL é criada, um usuário padrão é criado. Este usuário tem o mesmo identificador daquele usuário do sistema operacional que efetuou a operação de criação e tem o privilégio de criar outros usuários.

4.8 Planos de execução de consultas

O otimizador de consultas do PostgreSQL, antes de executar uma instrução que requeira acesso

a dados, gera um conjunto de plano de execução [9] e escolhe o plano que considera o mais eficiente,

dito “ótimo”. A escolha do plano ótimo nem sempre é simples porque a geração de um número grande de alternativas pode gerar um consumo exagerado de tempo e de espaço de memória.

O plano de execução efetivamente utilizado pelo PostgreSQL durante o processamento de uma

operação pode ser obtido pelo usuário através do comando EXPLAIN.

A geração do plano de execução é baseada em estatísticas do banco de dados como, por exemplo,

a cardinalidade das tabelas e a distribuição dos valores dos atributos pelas tuplas. Como esta informação

não é gerada automaticamente, é necessário que se execute periodicamente o comando ANALYZE para atualizar as estatísticas disponíveis para o otimizador.

5 CONSIDERAÇÕES FINAIS

O PostgreSQL oferece o mais baixo custo total de propriedade (TCO), reduzindo de forma

significativa seus custos de administração, suporte e licenciamento e, ao mesmo tempo, fornecendo alta performance, confiabilidade e escalabilidade. Trabalha com várias linguagens de programação e pode operar nos mais diversos tipos de Sistemas operacionais o que lhe garante uma posição de destaque entre as soluções de Gerenciamento de Banco de Dados atualmente disponíveis.

REFERÊNCIAS

Conquistando novas fronteiras PostgreSQLdisponível em <http://www.devmedia.com.br/post-6936- Artigo-SQL-Magazine-1-Conquistando-novas-fronteiras-PostgreSQL.html>. Acesso em 04 Abr. 2011.

Principais Características do PostgreSQL <http://www.sqlmagazine.com.br/Artigos/Postgre/01_ Caracteristicas.asp> . Acesso em 04 Abr. 2011.

Documentação do PostgreSQL 8.0.0. Disponível em: <http://sourceforge.net/projects/pgdocptbr/>. Acesso em 07 Abr. 2011

PostgreSQL 8.4. Disponível em: <http://gilbertexbom.com/bd2/ResumoBD2_2InfoT/postgresql.pdf>. Acesso em 06 Abr. 2011

PostgreSQL 8.0.0. Documentation: ANALYZE - Disponível em: <http://www.postgresql.org/docs/8.0/ interactive/sql-analyze.html> Acesso em 12 de abril de 2011.