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.

Esqueça o Comando SHOW: Use PG_SETTINGS

O comando SHOW é bastante utilizado para visualizar as configurações de um servidor PostgreSQL de datas, log, gerência de memória etc. Uma vez que na versão em que estou trabalhando tempos 187 parâmetros distintos, este comando se revela bastante prático para se ter uma visão geral da configuração e bem fácil de usar sem.
Abaixo, exemplos de sua sintaxe:

- SHOW ALL

- SHOW work_mem

No entanto, apresenta uma série de desagradáveis limitações:

- O resultado da consulta das variáveis de configuração não pode ser alterado (essa atualização pode ser feita pelo comando SET).
- Os campos mostrados são poucos e até insuficientes dependendo da necessidade (nome do parâmetro, valor corrente e descrição)
- Não é possível selecionar um subconjunto dados para ser visualizado (linhas e colunas), tampouco agregar colunas adicionais na consulta retornada.
- Não é possível montar consultas envolvendo junção, union e outros recursos da linguagem SQL.
- Para se visualizar 10 variáveis importantes, deve-se usar SHOW ALL ou fazer 10 comandos SHOW indicando as variáveis desejadas.

Apesar de sua utilizada, este comando simplesmente limita a flexibilidade de consultas e relatórios sobre as configurações do PostgreSQL. Como contornar esta limitação?

A tabela virtual PG_SETINGS contorna TODAS AS LIMITAÇÕES apresentadas pelo comando SHOW. As únicas restrições são:
- Não se pode inserir registros ou excluí-los (assim como não se pode adicionar e excluir variáveis de configuração)
- Certas variáveis não podem ser alteradas com o servidor em funcionamento ou apresentam restrições (como 'autovacuum' e 'bonjour_name', por exemplo).

As vantagens obtidas são várias:
- O resultado da consulta das variáveis de configuração pode ser alterado, respeitando-se as restrições de cada variável e seus valores aceitos .
- São mostradas mais informações sobre cada item de configuração (11 colunas)
- É possível selecionar um subconjunto dados para ser visualizado (utilizando comando SELECT!!!)
- É possível (e fácil) montar consultas envolvendo junção, union e outros recursos da linguagem SQL.
- Para se visualizar 10 (ou mais) variáveis importantes, pode ser empregado apenas um comando que retorne exclusivamente as variáveis desejadas.

Exemplos de utilização de PG_SETTINGS:

1 - Sintaxe básica, retornando todas as configurações.

SELECT * FROM pg_settings;

2 - Seleção de variáveis de configuração que comecem com 'AUTO'.

SELECT * FROM pg_settings WHERE NAME LIKE 'auto%';

3 - Consulta de variáveis de configuração com UNION.

SELECT * FROM pg_settings WHERE NAME LIKE 'auto%'
UNION
SELECT * FROM pg_settings WHERE NAME LIKE 'Date%';

4 - Consulta de variáveis de configuração com junção.

SELECT * FROM pg_settings p1, pg_settings p2
WHERE P1.NAME LIKE 'log_%' AND P1.NAME = P2.NAME AND UPPER(P2.UNIT) = 'KB';

Que tipo de aplicação você implementa com PostgreSQL?

Esta e a enquete que está sendo realizada no momento pela comunidade postgresql.org

Participe!!! O link está abaixo:

http://www.postgresql.org/community/

Exemplos de Código e SQL e PgSQL

O site abaixo apresenta uma série de bons exemplos (e simples de reproduzir) de código SQL e PlPgSQL. São abordados assuntos como funções matemáticas, de datas, índices, tabelas, consultas, cursores, tipos de dados, entre outros recursos do banco. Boa sugestão para a lista de favoritos de quem trabalha com o PostgreSQL:

http://www.java2s.com/Code/PostgreSQL/CatalogPostgreSQL.htm