PgBr MMXI

Mais um ano, e volta a Conferência Braſileira de PoſtgreSQL, agora chamada PgBr, e não mais PgConBr. Além de economizar três caracteres (¡dã!), o novo nome evita coliſão com a Conferência global de PoſtgreSQL, realizada todo ano em Otava, Ontário, Canadá, no primeiro ſemeſtre.

Ainda não ſei ſe poderei ir. Eſte ano, apeſar de ſer realizada na capital de São Paulo dos Campos de Piratininga, SP, a conferência realizar‐ſe‐á durante a ſemana de trabalho, como ſe fôra planejada para uma cidade de funcionários públicos, como Braſília, DF. Eu meſmo, funcionário público, ſaio do eſperado e me acho aßoberbado de trabalho, o que me dificulta a ida. Ißo ainda poderia ſer negociado; o que realmente me atrapalha é juſtificar ir ſem paleſtrar, e tenho já mais de um ano afaſtado da área de dados, o que me gera falta de aßunto.

Não que não haja aßuntos intereßantes. Mas após duas experiências ſofridas de paleſtrar ſem preparação adequada (PgBr MMIX, ſobre expreßões comuns de tabelas e PgCon MMX, ſobre modelagem literária), além de meu preſtígio ter baixado baſtante na comunidade, reluto em achar que conſeguirei preparar e apreſentar algo que valha a pena, ainda mais que ainda eſtou ſem meu Debian GNU/Linux em caſa, ainda com os problemas do EFI da Apple — no trabalho, onde ainda é Bios, eſtou no conforto do Debian com GNU Emacs — ſaudades do Open Firmware…

Idéias até tenho — por exemplo, ‘O Paquiderme univerſal’, ſobre como o PoſtgreSQL, ao rodar em todo tipo de plataforma, eſcalando do portátil ao grande porte, com todo tipo de linguagem e extenſão, atende a praticamente todas as demandas poßíveis e imagináveis de computação e geſtão de dados deſte lado do paraíſo relacional; ou ‘A Evolução paquidérmica: para o alto, e ¡avante!’, repaßando a liſta de afazeres do PoſtgreSQL, moſtrando como vamos melhorar, talvez colocando em perſpectiva tanto das noßas verſões mais recentes quanto do eſtado e melhorias mais recentes dos principais concorrentes; ou ‘O Elefante: ſua verdadeira forma, e diſfarces’, moſtrando as facilidades de migração de código, com ênfaſe dividida entre facilidades de compatibilidade com concorrentes e aplicação de padrões que facilitam a migração de e para o PoſtgreSQL. A queſtão é que, no momento, creio que há muito mais gente que poßa fazê-lo muito melhor do que eu.

Vejamos. No momento, não eſtou paßando bem. Talvez amanhã reſolva apreſentar algo, o prazo já ſe encerrará. Mas eu bem preferia que outros apreſentaßem eßes temas, e outros melhores ainda.

Se eu não puder ir, peço que alguém levante a diſcußão: regiſtremos os domínios Poſtgres, PoſtgreSQL e Postgres.org.br?

Leonardo César e os softicidas

Conversa esses dias com o Leonardo César:

Eu: O que é isso?

LC: Isso o quê?

Softcida…

cida = assassinos (?)

E quem são os tais? Maus programadores, gestores, o quê?

Sim, estes mesmos…

Estes últimos, os gestores… certo!

Veja bem, estamos desenvolvendo uma arquitetura bem complexa e distribuída através de webservices (SOAP). Isso envolve alguns bancos e seguradoras e estes normalmente estão utilizando Java ou .Net. O problema é que as ferramentas geram os clientes automaticamente, baseado no WSDL.

Uau! Mas e aí?

E estas ferramentas não são compatíveis com a especificação padrão WSDL e os "programadores" não fazem a mínima questão de ler a especificação e ver que a ferramenta deles não gera o cliente porque fogem do padrão… e daí eu que preciso adequar o WSDL às ferramentas de todos os clientes… por isso odeio softcidas…

Isso me fez lembrar adivinhem o quê? Hybernate!

Pode parecer à primeira vista não ter nada a ver. Mas tem: alguém faz ferramentas de qualquer jeito, sem levar em conta os conceitos e padrões fundamentais, tornando-se um softcida, que vai gerar muito mais problemas do que aparentemente resolve.

Usar Hybernate é cometer softcídio, porque os resultados são terríveis assim que se precisa escalar, e geralmente muito antes, por causa da inconsistência de dados. Evite Hybernate, previna o softcídio. Aprenda dados e SQL.

Entrevista concedida ao Fernando Ike

O que é um Arquiteto de Dados?

A pessoa responsável pela arquitetura e administração dos dados de uma organização. No caso, a arquitetura envolve desde a arquitetura de sistemas de bases de dados até a modelagem dos dados e sua manutenção; e a administração seria mais especificamente a manutenção dos modelos e dicionários de dados.

Qual a interação de um Arquiteto de Dados e um DBA? Ou é a mesma coisa?

Muitas vezes, em organizações menores ou menos estruturadas, a administração de dados é efetuada pelo Administrador de Bases de Dados. Mas normalmente, o DBA deve se ocupar da administração diária dos bancos de dados físicos e seu conteúdo, efetivamente uma administração dos Sistemas Gestores de Bases de Dados. Enquanto o AD deve se ocupar do projeto das bases de dados e sua estrutura lógica, não se envolvendo diretamente nos aspectos físicos.

Ok. corrigindo, Administrador de Base de Dados.

Tanto faz. Databank era o uso até os anos 70, que ficou fixado no Brasil. No resto do mundo se usa base.

Com essa afirmação, é possível supor que o AD seria o chefe de DBA (vou manter a sigla por enquanto…)?

Não, eles colaboram em níveis hierárquicos similares. Imagine um novo sistema. O arquiteto de dados será responsável pelos aspectos lógicos, principalmente a modelagem da estrutura da base; o DBA participará do projeto físico, como questões de distribuição, processamento e armazenamento. Um não trabalha sem o outro, e enquanto o projeto lógico deveria teoricamente determinar o físico, restrições tecnológicas podem (embora indesejável) determinar aspectos do lógico.

Como você afirmou acima, as vezes o DBA acaba executando algumas funções que estariam com AD, no Brasil tem mercado para um Arquiteto de Dados?

Ainda restrito e subvalorizado, mas tem. Empresas que têm na informação seu principal meio de trabalho costumam contratar ou formar um quando amadurecem. Bancos, empresas de informação de crédito, seguradoras e até corretoras de seguros, mesmo fornecedores de programas (é o caso de meu empregador atual).

É verdade que há retrocessos, como o advento da terceirização; assim, há o caso de uma multinacional fabril que terceirizou a mão de obra, de modo que a mesma vaga, que antes percebia determinada quantia CLT, hoje percebe a mesma quantia mas em regime PJ, sem correção significativa.

Outro fator detrimental é o foco em produtos, não em conceitos e processos. Assim, a mesma multinacional já deixou de contratar ótimos candidatos por falta de experiência em determinada marca de ferramenta de administração e diagramação, sendo que o candidato em questão tinha experiência suficiente em mais de uma ferramenta completamente equivalente.

Resumindo, ainda é um mercado bastante imaturo, o que leva a situações como as recomendações do AD serem vencidas por meras impressões e preconceitos de pessoas sem experiência com dados, opinando simplesmente do ponto de vista de vícios de programação por exemplo.

Então é possível afirmar que para um Arquiteto de Dados não é necessário ter conhecimento em vários banco de dados?

Em princípio não. Entretanto, devido à imaturidade de vários SGBDs — citem-se por exemplo, mas não exaustivamente, suporte deficiente a tipos de dados em Oracle, MS SQL Server, Sybase e MySQL, e problemas graves de desempenho e consistência neste último —, muitas vezes é conveniente que o AD possa compreender essas especificidades e trabalhar com o DBA e os desenvolvedores para adaptar a arquitetura e o modelo de dados às circunstâncias tecnológicas.

Não citou o PostgreSQL, ele é um boa referência para quem quer iniciar uma carreira como AD?

Uma das melhores, no mesmo nível do IBM DB2. São os SGBDs que têm o melhor suporte tanto ao padrão ISO SQL:2003 (o 2006 ainda não se fez sentir no dia-a-dia) quanto ao modelo relacional — ambos com restrições, mas ainda assim superiores a todos os concorrentes mais óbvios.

Entretanto, sendo uma área de atuação eminentemente lógica, recomenda-se, mais que determinados SGBDs, o futuro AD tenha um bom domínio tanto do modelo relacional, quanto de outros aspectos da teoria da gestão de bases de dados, e inclusive do padrão ISO SQL:2003 em si. As referências padrão, pela atenção que dão aos aspectos lógicos, são as obras de Chris J Date, embora polêmicas em vários aspectos que chegam a suscitar reações apaixonadas contra e a favor de vários praticantes de prestígio.

Esse é um ponto interessante, pois reflete alguns aspectos teóricos que envolvem o DBA. Um AD necessariamente deve ser um DBA também?

Não necessariamente. Entretanto, justamente devido a todas as restrições tecnológicas atuais, é interessante que o AD tenha a capacidade de adaptar-se a circunstâncias, o que pode ser facilitado se ele tiver tido alguma experiência com aspectos físicos, seja como DBA, programador, analista de sistemas, SysAdmin… isso lhe dará mais empatia com posições eventualmente divergentes na negociação de projetos de arquitetura de dados e modelagem, e possibilidade de dialogar com os problemas físicos reais ou imaginários freqüentemente trazidos por outros profissionais.

Pensando que uma empresa irá contratar uma consultoria para área de banco de dados, o que a mesma economizará contratando um Arquiteto de Dados ao invés de ter somente DBAs?

Nem tudo na vida são economias. Embora o principal foco do AD não seja monetário, porque o resultado do seu trabalho dificilmente é mensurável nesses termos, há muitos erros de projeto caros que podem ser minorados pela presença de um AD, ou pelo menos de um DBA com preocupação pelos aspectos lógicos.

Um dos aspectos do trabalho do AD é a normalização, que evita duplicação de dados que normalmente torna o desenvolvimento do sistema como um todo, mesmo na fase de programação, mais complexo, frágil, lento e arriscado, podendo também gerar custos de manutenção e operação como freqüentes anomalias de atualização, consumo exagerado de recursos de sistema, problemas de escalabilidade &c.

Um exemplo foi uma operadora de telecomunicações brasileira que tinha um consultor ao custo de ao menos nove mil dólares por mês (valor mínimo cobrado pela consultoria, possivelmente muito mais naquele caso específico) para resolver casos de inconsistência de dados. Além desse gasto muito simples e mensurável, essas inconsistências geravam grandes problemas de insatisfação de clientes. Não é difícil imaginar alguns desses problemas tornando-se questões mesmo de relações públicas, no caso de uma operadora de serviços públicos.

Há que se considerar também a questão da eficiência: embora alguns DBAs possam desempenhar funções de AD com razoável competência, será um uso ineficiente do recurso humano, que perderá foco em sua função tradicional sem realmente se concentrar na de AD.

O outro lado da moeda é que, devido ao baixo nível intelectual de muitas equipes de desenvolvimento impedi-las de compreender questões lógicas de conseqüências não inteiramente óbvias e imediatas, o peso da opinião de um DBA praticante pode ser maior que a de um AD. Entretanto, uma equipe com esse problema certamente terá muitos outros problemas igualmente óbvios e imediatos.

É um problema de maturação do mercado de TI no geral.

Aliás, ou de maturação ou, às vezes dá impressão, decadência…

Dê duas ou três dicas rápidas para quem quiser trabalhar como AD.

1. Concentrar-se num sólido conhecimento conceitual;
2. Abstrair problemas específicos de SGBDs, mesmo que depois sejam necessárias adaptações;
3. Desenvolver uma visão ampla, que contemple desde as regras de negócio (== restrições de integridade) até questões de desempenho e manutenção da aplicação.

Administração de dados: codificação de caracteres

Codificação de caracteres. Não deve haver assunto mais insistente na lista brasileira de discussões. ASCII, Latin1 e UTF-8 estão sempre em discussão. Mas alguém pode dizer: ‘Isso não é um problema de administração de dados, mas físico! É uma questão do que é mais eficiente!’ Mas não — a codificação de caracteres limita o que pode ser codificado, e portanto um administrador de dados, sempre que possível, vai querer usar o que for mais flexível, que não estabeleça limites arbitrários.

Ainda tem gente brigando com bases de dados em ASCII. Tipicamente, porque instalou um sistema operacional sem configurar a língua, ficando com as configurações por omissão, ou seja, o local ‘C’. O problema é que o ASCII é 7 bits, portanto codifica apenas 128 caracteres — o que, devido a caracteres de controle, não imprimíveis, pontuação e acentuação para línguas mais votadas, não cobre todos os caracteres da língua portuguesa. Ou seja, é verboten!

A opinião mais corrente parece ser a de que ‘não se precisa mais que Latin1 no Brasil’. Errado! Latin1, cujo nome correto é ISO 8859-1, está obsoleto: por exemplo, não consegue codificar €, o símbolo do Euro. Ou seja, proibido também.

Então, dirão, vamos de Latin9, ISO 8859-15. Sim, é uma escolha razoável. Mas imagine que chegue um chinês maluco, goste de seu programa, e decida levá-lo para a China. Pena, você acabou de perder o negócio de sua vida. E se teu chefe decidir expandir negócios para a Índia, e descobrir que você criou um sistema que só serve para o Ocidente? Pena, você vai ter de procurar outro emprego.

Isso nos deixa com Unicode, do qual a escolha mais razoável no Ocidente é o UTF-8. Sim, UTF-16 é mais consistente, mas além de ser o único suportado pelo PostgreSQL, ocupa apenas um byte para os caracteres ocidentais, que costumam ser a grande maioria, exceto para aplicações estritamente locais do Oriente. E, se você tem algum problema em usar UTF-8… bom, ele suporta qualquer codificação, então certamente é um problema estritamente de aplicação, configuração, até um possível defeito no PostgreSQL ou alguma biblioteca relacionada, mas certamente não é um problema do UTF-8 em si.

Resumindo, a menos que você precise de algo muito, muito específico mesmo, faça-se um favor — Unicode na cabeça.

Administração de Dados: tipos & domínios

Seguindo a série sobre os fundamentos da gestão de dados, falemos sobre os tipos de dados.

Fico impressionado com a quantidade de ‘ferramentas de modelagem de dados’ que não passam de diagramadores — porque não suportam o conceito mais básico depois da própria teoria de dados, que é o de tipagem.

Há muita confusão neste campo por erros terminológicos de ferramentas, métodos e mesmo padrões. Por exemplo, quase todos os sistemas de informática suportam alguns tipos de dados — mas geralmente são apenas alguns poucos tipos básicos, não extensíveis pelo usuário. E quando há essa extensibilidade, chamam-nos tipos abstratos de dados, como se houvesse outros tipos não abstratos. Confundem-se tipos com sua representação, de modo que duas representações são tratadas como tipos diferentes. E, por fim, chamam-se domínios a simples nomes dados a determinados tipos básicos, talvez com algumas restrições de integridade associadas.

Ora, tipos nada mais são que domínios e seus operadores associados; enquanto domínios são listas de valores (não necessariamente discretos) nos quais se pode definir um atributo. Assim, os domínios ISO SQL não são domínios de verdade, e o conceito realmente útil seria o de tipos, mas que também não é realmente suportado, e o que é suportado é de difícil implementação.

Sem uma definição de domínios centralizada no SGBD ou ao menos na ferramenta de modelagem, cada relação do modelo vai tender a ganhar diferentes definições para os mesmos tipos de dados, e o caos é o limite. Sem contar as comparações e cálculos absurdos que se fazem entre tipos de dados incompatíveis.

Em PostgreSQL temos uma sorte: os tipos são um pouco melhor implementados que noutros SGBD ou mesmo no padrão ISO SQL, e em combinação com os domínios SQL realmente se aproximam do conceito matemático. Duro é trabalhar num projeto que realmente implemente os tipos e aloque um programador (C ou D, por exemplo) para criar os tipos assim que possível, antes do resto da programação e implementação da base de dados.

O suporte, embora imperfeito, está aí. Mesmo que tipos SQL muitas vezes não sejam práticos, pelo menos seus ‘domínios’ ajudam. Agora não me venham com diagramas bonitos chamando-os de modelos, se pelo menos os domínios não estão definidos! Quase cem por cento de probabilidade de que, se já não houver grandes inconsistências, elas logo ocorram ao longo da vida da aplicação.

Administração de Dados: os fundamentos

Gostaria de saber dum bom livro-texto de administração de dados. Faz falta, mesmo já com muitos anos de estrada, e mesmo tendo livros tão bons sobre modelos de dados quanto o do Date. Acontece que a ênfase dos livros costuma ser tecnológica; e mesmo um livro conceitual (e conceituado) como o do Date usa os conceitos como base para aplicações tecnológicas, não conseguindo — afinal, trata-se apenas de um livro-texto, não uma enciclopédia de gestão de dados — se preocupar com o projeto e manutenção dos modelos específicos de dados.

Aliás, também gostaria de ter mais contatos na área, a abrangência de meus interesses acaba prejudicando esse corpo-a-corpo tão necessário no Brasil.

Enfim, farei aqui algumas anotações, na esperança de que alguns colegas vejam e comentem.

Primeira anotação: qual o fundamento mais importante da administração de dados?

Resposta irrefutável, mas que virá como surpresa para os empiricistas: uma teoria de dados.

Muita gente começa até com um bom entendimento dos dados em si no sentido de que conhece a aplicação e os usos que fará de que dados. Mas acaba fracassando na organização desses dados, e criando sistemas que não escalam, que são xingados por usuários e mantenedores, que têm de ser refeitos várias vezes até se tornarem aceitáveis, por faltar uma teoria de dados. Daí também vêm tiros no pé como bases de dados multivaloradas (Pick, Caché), navigacionais (Clipper, BTrieve) e orientadas a objeto (Jasmim, de novo Caché). E coisas mais estranhas ainda, como o ReiserFS (não a implementação atual, mas o objetivo final).

Aqui não é o lugar para justificar o modelo relacional como única teoria de dados válida, nem para criticar os outros. Então meus (eventuais) leitores terão de fazer a tarefa de casa, que consiste em ler —­ de preferência, o Date supracitado — e pensar muito.

PostgreSQL Conference Brasil 2007

Vou falar no PGCon 2007, patrocinado e organizado pela comunidade PoſtgreSQL brasileira e pela Tempo Real, sobre Adminiſtração e Modelagem de Dados em PoſtgreSQL.

Inſcrevam-ſe e acompanhem aqui, pretendo publicar o conteúdo da palestra antes do evento para que todos a aproveitem melhor e quem ſabe naſça algum debate intereßante.

Administração de dados à la Unix

Originalmente publicada em pgbr-geral@postgresql.org., tranſcrita com adaptações.

Eſta é uma idéia bem incipiente, goſtaria de diſcuti-la aqui. Alguns podem achar que é fora do tópico; neße caſo, aceito ſugeſtões de onde debatê-la.

Andei inveſtigando ferramentas de modelagem, e acabei ficando fruſtrado. Pelo que olhei e até teſtei, as ferramentas ‘profißionais’ eſtão por volta de US$4K, chegando facilmente a US$8K ſe a gente quiſer ‘luxos’ (¡não!) como verſionamento. As ferramentas livres são inexiſtentes, incompletas e (ou) imaturas; eſcolha pelo menos dois deßes adjetivos. Além de falta de ſuporte a ſiſtemas livres e vai por aí afora.

Mas agora o que tem me irritado é o próprio fluxo de trabalho deßas ferramentas. Não são nada práticas, forçando tudo a paßar por diagramas. Eu preferiria fazer tudo em texto, e ter diagramas como ſaídas do proceßo, não entradas. E tive a idéia maluca de eſcrever uma propoſta a reſpeito, mas queria ſaber ſe alguém já viu algo aßim, ou ſe é abſurdo.

Hoje, numa ferramenta de modelagem de dados, o proceßo começa com a definição de um dicionário de dados. Uſando eße dicionário de dados, cria-ſe um DER. Eße diagrama é então traduzido para o ſabor SQL do SGBD relevante.

O problema óbvio é que diagramas são menos expreßivos e mais chatos de fazer que um programa SQL ou (idealmente) relacional. Então por que não eſcrever ISO SQL, Tutorial D ou meſmo D4 (deſculpem os idealiſtas, também ſou idealiſta mas…)?

Não ſeria fácil, mas creio que ſeria poßível, com planejamento e paciência, criar um ſiſtema muito mais produtivo e flexível uſando a filoſofia Unix: cada tarefa deve ſer bem feita por um componente. As interfaces são bem definidas, e cada ferramenta pode ſer ſubſtituída ou melhorada independentemente.

No caſo, começar‐ſe‐ia com uma gramática (por exemplo) Tutorial D ou D4. Talvez uſar um derivado de Scheme ou ML para obter mais concisão e poder programático, creio que já fizeram um SchemeQL ou coiſa aßim. Mas talvez um ſubconjunto do ISO SQL:2003, deixando de lado tudo o que for físico como ponteiros, índices &c; embora eu não creia que o SQL seja ſuficientemente expreßivo de todas as ſituações com que um SGBD deva lidar — eſpecificamente, todos os tipos de reſtrições de integridade.

Neßa linguagem, definiríamos domínios, entidades, regras de negócio &c, tudo o que tem a ver com o modelo lógico (conceitual). O básico é ter a linguagem definida; a partir daí criam-ſe validadores e compiladores. O reſultado dos compiladores ſeria um programeta de definição de dados para o(s) SGBD(s) alvo de eſcolha, por exemplo noßo caro Dumbo.

Deßa meſma definição, uſaríamos um AutoDoc ou SQL Fairy (cuidado, a página inicial dele cega!) para gerarmos todos os diagramas que quiséßemos: DER, IDEF1X &c para benefício dos uſuários. Até aí é trabalho do Adminiſtrador (ou Arquiteto) de Dados. A partir da linguagem, podemos criar todo tipo de auxílios, como IDEs (um modo Emacs, por exemplo).

Até aí foi conceitualmente tranqüilo. O que me preocupa, além da poßibilidade deßa idéia ſer muito pior do que me parece, é o ſegundo paßo: findo o trabalho do AD, começa o do Adminiſtrador de Baſes de Dados, o ſempre popular ABD (ou DBA, para os anglófilos). Ele teria de pegar eßa definição da Baſe de Dados (BD) e acreſcentar tudo o que é físico: índices, parâmetros de armazenamento &c. Não me parece eſpecialmente difícil; ele poderia fazê-lo ſeja numa extensão da noßa linguagem conceitual, ſeja na linguagem do ſiſtema alvo. Ou meſmo através de remendos a aplicar ao modelo conceitual, como ſe faz em programação tradicional meſmo.

Tenho certeza de que há muitos percalços nos quais não penſei, mas queria ſaber de vocês o que acham.

Para concluir, creio que um ſiſtema aßim poderia ſer o começo de coiſas muito melhores. Por exemplo, o único quaſe‐SGBDR hoje em produção é o Alphora Dataphor, que tem algo ſemelhante não para modelagem de dados mas para o ſiſtema como um todo: a gente eſcreve D4 (que é uma D válida) e os comandos são executados num SGBD SQL (infelizmente ainda não ſuporta o Jumbo). É um ſiſtema proprietário e complexo, e ainda por cima em MS .Net, mas é uma boa idéia. Não conſigo imaginar hoje um projeto dum clone ou equivalente livre dele, mas eße noßo ſiſtema eventualmente poderia ſer um primeiro paßo.

Deu para entender?