Configuração Básica de Driver ODBC para PostgreSQL

Acesso a dados demanda um bom middleware. E a tecnologia ODBC - Open Database Connectivity, é uma opção bastante estável, disponível desde 1992. Por apresentar drivers para praticamente todos os bons SGBDs do mercado, muitas soluções são implementadas utilizando esta tecnologia.

O suporte às funcionalidades de um SGBD relacional e a grande disponibilidade de drivers são grandes pontos fortes deste middleware. Como problemas podem ser elencadas a falta de atualizações recentes, com defasagem em termos de novas funcionalidades oferecidas por outros componentes de acesso a dados e o fato de ser uma tecnologia proprietária.

Longe de esgotar este tópico, este post mostra uma configuração básica de ODBC para PostgreSQL, como a que foi utilizada para a utilização da ferramenta DbDesigner Fork.

* Etapa 1- Instalação
É sempre recomendável baixar a versão mais atualizada disponível, no site da comunidade PostgreSQL.ORG: http://www.postgresql.org/ftp/odbc/versions/

No nosso caso, a instalação será feita em uma máquina com Windows XP. Existem formas de utilizar o ODBC no Linux e no UNIX e meios de se fazer pontes envolvendo ODBC e JDBC, mas estas variações estão (bastante) fora do escopo deste post.

Descompacte o arquivo ZIP e execute o instalador. É sempre aconselhável ler antes o arquivo readme e se for uma atualização, pode ser disparado o arquivo upgrade.bat. Na instalação padrão um assistente relativamente simples se encarregará do processo sem que se precise fazer configurações complicadas.

* Etapa 2 - Configuração

Após a instalação, abra o painel de controle do windows (Menu Iniciar/ Painel de Controle). Dispare a opção "Ferramentas administrativas" e depois selecione "Fontes de Dados (ODBC)".

Será aberta a tela "Administrador de Fonte de Dados ODBC". Nesta tela, selecione a aba "Drivers ODBC que estão instalados no sistema". Observe na imagem abaixo que foram instalados os drivers para PostgreSQL ANSI e UNICODE.


Para criar um data source, selecione a aba "Fonte de dados do usuário" e o botão "Adicionar". Aparecerá uma tela como a que está abaixo. Selecione o driver do PostgreSQL e confirme.

Em seguida, preencha os valores para o nome da fonte (Description), banco de dados para o qual aponta (Database), servidor em que está o banco de dados (Server), Porta de Comunicação (Port), usuário e senha. O servidor pode assumir os valores "localhost" ou um endereço IP. Utilize o botão TEST para verificar se os dados foram devidamente fornecidos e se a conexão pode ser feita e a opção SAVE para gravar a configuração do driver.

A opção "Configurar" permite a alteração de uma fonte de dados do usuário, abrindo a tela abaixo. Os botões Datasource, Global e Manage DSN estão fora do escopo deste post.


Após fazer a instalação, a nova fonte de dados do usuário aparece na lista, podendo ser utilizada por várias aplicações compatíveis com o ODBC.


Mais informações sobre ODBC podem ser obtidas nestas fontes:
- Na Wikipedia
- Site Easysoft, com informações sobre ODBC em UNIX e Linux

Power Architect - Ótima Ferramenta Livre!!!

Falar de ferramentas de banco de dados geralmente implica em destacar suas limitações. Uma exceção é o Power Architect, que apresenta boas e úteis funcionalidades para o desenvolvimento de aplicações que tenham um certo grau de complexidade. É uma ferramenta livre e de código aberto, cujo download pode ser feito aqui.

Não é exclusiva para o PostgreSQL, podendo também ser utilizada em projetos com Oracle, SQL Server, MySQL, Derby e HSQLDB. O desenvolvimento é pago por taxa de suporte premium de 199 dólares ao ano, o que é relativamente baixo em se falando de ferramentas de base de dados.

As principais funcionalidades são:

• Boa interface visual com diagramas de ER e OLAP
  
• Acesso a bancos de dados via JDBC
• Conexão a múltiplas fntes de dados ao mesmo tempo
• Comparação de modelos de dados com identificação de diferenças e geração de scripts de sincronização
  
• Suporte a "Drag-and-drop" de tabelas de um modelo para o playpen (diagrama)
  
• Geração de banco de dados através do projeto (Forward-engineers)
• Engenharia reversa para a construção dos projetos
  
• Salvamento da estrutura de dados em um projeto que pode ser trabalhado remotemante
  
• Dados do projeto armazenados em um formato XML de fácil navegação
  
• Licença livre GPL (version 3)
• Suporte rudimentar a ETL - Extração, Transformação e Carga de Dados
• Suporte a esquemas OLAP para projeto de Data Warehouses

Alguns problemas ou desvantagens foram constatados. Falta suporte a visões, triggers, restrições tipo check e stored procedures, recursos importantes para o projeto de bancos de dados de maior complexidade. Outros problemas menores constatados foram: falta Suporte a trabalho em grupos, ausência de Controle de versões e falta de interface WEB.

Abaixo, algumas telas capturadas:

• Tela de conexão a banco de dados PostgreSQL, tendo ao fundo uma visão geral da ferramenta.
  

• Parâmetros para a comparação entre bancos de dados

• Tela de resultado da comparação entre bancos de dados.

* Avaliação Geral

A ferramenta é superior ao DBDesigner e pode ser utilizada para projetos que não sejam de pequeno porte. Apresentou poucos bugs nos testes realizados. No entanto, as desvantagens apesar de poucas são significativas.

PostgreSQL: primeira release de 2009!!!

A equipe do PostgreSQL lançou a primeira release de 2009, apresentando uma versão instável que não deve ser utilizada para ambientes de produção, que consiste basicamente em uma visão snapshot das atualizações feitas no desenvolvimento do banco. O instalador pode ser baixado aqui. A documentação desta versão está disponível aqui, mas não conta por exemplo com uma seção "release notes" apesar de apreentar no título referência à versão 8.4.

É uma boa opção para desenvolvedores e testadores que querem se antecipar às novas funcionalidades da versão 8.4 que estão em desenvolvimento ou colaborar nos testes.

Acredita-se que no primeiro semestre serão lançadas as primeiras versões de teste para a nova release 8.4 deste SGBD.

Boas Festas!!!

Não sou o primeiro, nem quero ser o último a desejar a você boas festas e um abençoado 2009!!!

DbDesigner Fork: Fraco, mas Gratuito!

Ferramentas para projeto de banco de dados estão entre as mais úteis para o desenvolvimento de sistemas. Infelizmente, também estão entre as mais difíceis de se encontrar dentre os softwares gratuitos. O DbDesigner Fork é uma boa opção livre para a modelagem de bancos de dados, apresentando suporte para Oracle, SQL Server, MySql e Firebird, além do PostgreSQL.

O projeto está disponível para Windows e Linux e sua última versão está datada de julho de 2007. Originou-se do DBDesigner, uma ferramenta mais antiga. Seu desenvolvimento apresenta alguma taxa de atividade e possivelmente será feito algum novo release em breve. Gera arquivos XML com a modelagem realizada em uma boa interface visual.

Apresenta uma série de recursos bastante úteis:
- Engenharia Reversa
- Sincronização
- Modelagem visual de diagramas de Entidade-Relacionamento, com integridade referencial
- Recursos para exportação SQL
- Importação da ferramenta ErWin
- Exportação dos diagramas como figuras (PNG e BMP)

DbDesigner e PostgreSQL

Nesta análise me concentrarei basicamente nas características específicas que o software tem em relação com o o PostgreSQL. A ferramenta apresentou um resultado razoável, pois foram constatados bugs e limitações. O ponto forte, além da gratuidade, foi a interface amigável, apesar de não tão moderna.

A conexão com o banco foi dificultada pelo fato da ferramenta só aceitar conexão ODBC com o PostgreSQL. Tive de baixar e instalar o driver ODBC, além de criar um data source no sistema operacional.


A interface visual é simples e a seleção da visualização em query mode permitiu a realização de consultas ao SGBD sem sair da ferramenta.


A engenharia reversa funcionou muito bem. Puxou os dados do PostgreSQL rapidamente e criou objetos no diagrama corrente. No entanto, não importou as chaves estrangeiras. Quando realizada mais de uma vez, criou mais de uma tabela com o mesmo nome no diagrama.


A sincronização de banco de dados simplesmente não funcionou. Fiquei em dúvida se a mensagem de erro apresentada foi em virtude de bug da ferramenta ou da versão do driver ODBC utilizada. Abaixo, a tela de sincronização:



Na exportação de dados, uma decepção: não há ligação direta para o PostgreSQL. O DbDesigner exporta um script SQL que deve ser submetido ao banco.

Avaliação geral

Creio que houve uma série de avanços em relação às versões anteriores da ferramenta, mas ainda está distante de ser utilizável sem ressalvas, especialmente nas grandes empresas. Abaixo listo algumas das limitações da ferramenta:

- Falta Suporte a trabalho em grupos.
- Ausência de Controle de versões.
- Grande espaçamento de tempo entre as atualizações de versão.
- Número grande de bugs e de requested features por atender.
- Falta de interface WEB

Observações

Aconselho a quem deseja utilizar esta ferramenta para suas aplicações que preserve o modelo gerado, que é criado em formato XML, em uma ferramenta de controle de versões. Em releases anteriores do DbDesigner cheguei a perder algumas horas de trabalho por corrupção do arquivo.

Retornando registros de consultas genéricas com RETURN QUERY

Recentemente, recebi uma dúvida sobre o RETURN QUERY, funcionalidade implementada na versão 8.3 do PostgreSQL, que permite o retorno de conjuntos de linhas e colunas de uma função. A dúvida do Patrick é bastante comum e até pouco tempo eu não teria uma resposta adequada:

"Patrick Espake disse...

Eu estou tentando usar isso, para retorna uma linha que vem de um inner join de diversas tabelas.

O que eu coloco para o RETURNS SETOF? Visto que os meus dados vem de uma junção de diversas tabelas.

Obrigado."

A solução do problema do Patrick é relativamente simples. O Return Query aceita o tipo RECORD como valor de retorno. Portanto, fica fácil retornar resultados de consultas genéricas. Para ilustrar, segue um exemplo de código Pl/ PgSQL abaixo.

A tabela indivíduo será utilizada para o teste do RETURN QUERY retornando uma consulta qualquer.

CREATE TABLE individuo (
cod integer PRIMARY KEY,
nome varchar(50));
INSERT INTO individuo VALUES (1,'Teste');
INSERT INTO individuo VALUES (2,'Teste 2');

Agora, a função RET_ROWS mostra como utilizar o retorno de tipos RECORD para funções:

--Retornando consulta de várias linhas
CREATE OR REPLACE FUNCTION ret_rows () RETURNS SETOF RECORD AS $$
BEGIN
RETURN QUERY SELECT * FROM individuo; -- Acrescenta um conjunto de linhas ao retorno da função
RETURN ; -- Retorna as linhas
END;
$$ LANGUAGE plpgsql;

A grande diferença desta forma de programar está na chamada da função. Ao utilizar valor de retorno do tipo RECORD, deve ser indicada a lista de campos a serem retornados e seus tipos. Esta pode ser vista como uma limitação, embora na prática também seja uma forma de se garantir a confiabilidade dos resultados retornados na execução de comandos SQL dentro de funções pela validação dos valores retornados.

SELECT * from ret_rows() as (c1 integer, c2 varchar(50)) ; --Declaração dos campos do record

Falta considerar a execução de uma junção dentro da função, que é nossa questão original. Para tanto, será criada uma tabela com os filhos dos indivíduos para sofrer junção com a de indivíduos. O exemplo abaixo executou sem qualquer problema na versão 8.3:

CREATE TABLE filhos (
cod integer PRIMARY KEY,
filhos integer);
INSERT INTO filhos VALUES (1,1);
INSERT INTO filhos VALUES (2,3);

--Retornando Resultado de Junção
CREATE OR REPLACE FUNCTION ret_filhos (psql integer) RETURNS SETOF RECORD AS $$
BEGIN
RETURN QUERY SELECT individuo.nome, filhos.filhos FROM individuo, filhos WHERE individuo.cod = filhos.cod AND individuo.cod = $1; -- Consulta
RETURN ; -- Retorna as linhas
END;
$$ LANGUAGE plpgsql;

SELECT * from ret_filhos(1) as (c1 varchar(50), c2 integer) ; --Declaração dos campos de retorno
SELECT * from ret_filhos(2) as (c1 varchar(50), c2 integer) ;

Outras Soluções

Outras soluções para o retorno de registros em funções são a consolidação e retorno dos dados dentro de um campo texto ou XML.

Resolveu, Patrick?

PostgreSQL: Tendências pelo Mundo e no Brasil!

Você já se perguntou que países mais utilizam o PostgreSQL? Em que colocação ficaria o Brasil neste ranking? As buscas sobre o PostgreSQL estão aumentando ou diminuindo? Este tipo de pergunta é difícil de responder em virtude da facilidade de instalação e difusão do software. Estatísticas confiáveis são difíceis de conseguir e as que são disponíveis são certamente sujeitas a erros substanciais. Por exemplo, o fato de termos o PostgreSQL instalado, não significa que esteja sendo realmente executado.

No site do Google Insights podem ser buscadas informações relativas a buscas de termos em geral. A busca por PostgreSQL revelou interessantes idéias. Confira por conta própria aqui.

Algumas curiosidades:

- A procura por PostgreSQL tem diminuído nos últimos 4 anos. Este dado não significa uma diminuição da base instalada, uma vez que o que é medido é a quantidade de buscas a respeito.

- Se em 2004, Japão e Rússia eram os países com maior interesse, Cuba e China hoje ocupam esta posição. Abaixo, uma visão do dia de hoje (28/11/2008)


- O Brasil ainda ocupa uma posição intermediária em buscas na internet sobre o tema. O Paraguai é o país da América do Sul que mais pesquisa sobre o PostgreSQL.

- Em 2008 a quantidade de buscas está estável, com queda à medida que se aproxima o fim do ano.


- Dentre os estados brasileiros, temos como grandes buscadores o Distrito Federal, o meu Ceará e Santa Catarina. A região Norte em Geral e alguns estados apresentaram um baixíssimo índice de buscas sobre o PostgreSQL, enquanto que a Região Sul é a que apresentou uma maior difusão, com todos os estados apresentando bom índice de buscas. Estes dados apresentam uma forte influência da concentração dos profissionais de informática no país.

Funções de Suporte a Tipos ENUM (8.3)

O PostgreSQL 8.3 disponibiliza algumas funções que permitem a consulta a campos ENUM com pouquíssimo esforço. As funções implementadas são: enum_first, enum_last e enum_range.

Para exemplificar sua utilização, vamos criar o tipo enum signos:

CREATE TYPE signos AS ENUM ('Áries', 'Touro', 'Gêmeos', 'Câncer', 'Leão', 'Virgem', 'Libra',
'Escorpião', 'Sagitário', 'Capricórnio', 'Aquário', 'Peixes');

* enum_first

1- Primeiro elemento de um tipo ENUM

SELECT enum_first(null::signos);

* enum_last

1- Último elemento de um tipo ENUM

SELECT enum_last(null::signos);

* enum_range - Intervalos de elementos de um tipo ENUM.

1 - Retornando todos os valores em ordem

SELECT enum_range(null::signos);

2 - Retorna valores até o ENUM Virgem, incluindo o 'Virgem'

SELECT enum_range(null, 'Virgem'::signos);

3 - Retorna valores a partir do ENUM Virgem, incluindo o 'Virgem'

SELECT enum_range('Virgem'::signos, null);

4 - Retorna valores do intervalo entre Touro e Virgem, incluindo os dois itens.

SELECT enum_range('Gêmeos'::signos,'Virgem'::signos);

Campos Tipo ENUM no PostgreSQL 8.3

Campos com enumerações de valores aceitos são implementados em vários bons bancos de dados. No caso do PostgreSQL, este recurso poderia ser realizado através de constraints tipo CHECK ou domínios. Na versão 8.3 foi introduzido um tipo de dado ENUM, facilitando ainda mais a operação de campos com uma lista restrita de valores permitidos.

Vantagens:
- Cria listas de valores aceitos que podem ser reutilizadas várias vezes, inclusive dentro de uma mesma tabela, para disciplinar os valores aceitos por um determinado campo.
- Apresenta funções específicas para manipulação dos tipos ENUM criados.
- Melhor uso de espaço: o armazenamento campos Enum ocupam 4 bytes em disco. Dependendo da quantidade de valores armezenados, pode ser economizado um bom espaço no banco de dados.
- Podem ser visualizados através de consultas a pg_enum.

Desvantagens:
- O tipo ENUM é diferente dos demais tipos do PostgreSQL, portanto não pode ser comparado com valores de outros tipos. Na ausência de CAST, empregue um operador customizado ou uma função que realize esta conversão.
- Falta de recursos para alterações no tipo. Não é possível simplesmente inserir ou retirar valores de um tipo, mas os valores de campos de tabelas tipo ENUM podem ser livremente alterados.
- Enumerados que não sejam de valores alfanuméricios não podem ser criados. Para enumerados de datas e números deve ser empregada uma restrição do tipo CHECK, por exemplo, ou outra maneira de simular o ENUM.

Sintaxe:

CREATE TYPE name AS ENUM
   ( 'label' [, ... ] )

Exemplos:

1 - Criação e Utilização de Tipo Enumerado

CREATE TYPE dia_sem AS ENUM ('Dom', 'Seg', 'Ter', 'Qua', 'Qui', 'Sex', 'Sab');

--Utilização na criação de tabelas
CREATE TABLE registro (
dia_coleta dia_sem,
dia_analise dia_sem,
dia_resultado dia_sem);

INSERT INTO registro VALUES ('Seg', 'Ter', 'Qua');
INSERT INTO registro VALUES ('Seg', 'Ter', 'Dom');
INSERT INTO registro VALUES ('Seg', 'Ter', 'QuW'); --ERRO - Não encontrado no tipo ENUM
INSERT INTO registro VALUES ('Seg', 'Ter', 'QuA'); --ERRO - Case sentitive

2 - Implementação similar com a cláusula check

CREATE TABLE registro_teste (
dia_coleta text check (dia_coleta in ('Dom', 'Seg', 'Ter', 'Qua', 'Qui', 'Sex', 'Sab')));

3 - Criação de Tipo Enumerado II

CREATE TYPE situacao AS ENUM ('Em elaboração', 'Proposto',
'Em homologação', 'Aprovado', 'Recusado', 'Cancelado', 'Efetivado');

--Utilização na criação de tabelas
CREATE TABLE documento (
descricao varchar(50) PRIMARY KEY,
estado situacao);
INSERT INTO documento VALUES ('Ata de reunião de 12/12/2008', 'Aprovado');
INSERT INTO documento VALUES ('Levantamento do Protótipo', 'Cancelado');

4 - Consulta aos enumerados no catálogo do PostgreSQL (OID do Tipo e Valor)

SELECT * from pg_enum;

5 - Consulta aos enumerados no catálogo do PostgreSQL (OID do Valor, do Tipo e o Valor)

SELECT oid,* from pg_enum;

PostgreSQL em Evento de Curitiba

O SERPRO - Serviço Federal de Processamento de Dados, promove o II Fórum de Tecnologia em Software Livre, em Curitiba. O evento ocorrerá de 10 a 12 de novembro de 2008, na Regional Serpro de Curitiba.

O PostgreSQL faz parte da programação por meio de uma palestra sobre as funcionalidades da versão 8.3 e de um minicurso de PostgreSQL Avançado, ministrado por mim. Plataformas, tecnologias e processos baseados em software e formatos livres e abertos fazem parte da programação do evento.

Participe! As incrições podem ser feitas pelo site: http://www.cta.softwarelivre.serpro.gov.br/

PostgreSQL no Novo Concurso do SERPRO

(09/10/2008) Saiu o edital do concurso do SERPRO - Serviço Federal de Processamento de Dados e pela primeira vez o banco de dados PostgreSQL aparece no edital. No cargo 5: ‘ANALISTA – ESPECIALIZAÇÃO: DESENVOLVIMENTO DE SISTEMAS’, aparece no conteúdo programático o tópico ‘PostgreSQL em Linux’. Dos bancos de dados proprietários, apenas o ADABAS (Software AG) foi citado explicitamente.

Uma curiosidade: no cargo 17, ANALISTA – ESPECIALIZAÇÃO: SUPORTE TÉCNICO, o PostgreSQL também faz parte do conteúdo programático, mas esta escrito errado.

E difícil afirmar que cairá ao menos uma questão de PostgreSQL no concurso, no entanto este edital consiste em mais um indicador da crescente utilização deste banco de dados na esfera federal brasileira.

Confira aqui o edital completo e boa sorte!

SERPRO Participa da PgCon 2008

O SERPRO - Serviço Federal de Processamento de Dados participou da PgCon 2008 como patrocinador. A ferramenta é o principal banco de dados livre homologada para compor as soluções da empresa, que conta com um portfólio de centenas de sistemas ativos.

Saiba mais neste link.