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).

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.