I Dia PostgreSQL São Paulo (2009)

Dia vinte e quatro de abril, sexta-feira próxima, será o I Dia PostgreSQL de São Paulo (2009), SP, Brasil. Vou apresentar as ferramentas de documentação automática de modelos e bases de dados PostgreSQL, espero que de maneira mais objetiva que o que consegui fazer na II Conferência Brasileira de PostgreSQL (2008), em Campinas.

Como sempre nos eventos dessa comunidade, haverá alguns ótimos palestrantes, como o Euler e o Guedes; desta vez teremos também o próprio organizador do evento, o Rodrigo Marins, possivelmente o Leonardo César, e um DBA da Caixa Econômica Federal. Parece que será bem interessante.

Pretendo abordar programação literária em NoWeb (en passant), mas principalmente Auto Doc, assim como um pouco do SQL Fairy e do Schema Spy.

O evento é gratuito, portanto a única desculpa para não ir é ser uma sexta-feira de trabalho. É uma semana curta por causa do feriado do Descobrimento do Brasil na terça-feira, dia vinte e um, o que pode ajudar — deve ser uma semana lenta de trabalho — ou atrapalhar — algumas pessoas podem ser atropeladas justamente pela falta de tempo na semana para liqüidar alguma tarefa urgente e inadiável. O lugar é um pouco remoto, a Lapa de Baixo, perto da Marginal do rio Tietê; mas, numa semana curta, esperamos que o trânsito não esteja ruim.

Mapear e Reduzir em PostgreSQL

O ‘Mapear e reduzir’, o conceito da Google para processamento de grandes quantidades de dados implementado como MapReduce, foi incoporado em dois derivativos do PostgreSQL, o Aster e o Greenplum.

Não fui atrás ainda dos detalhes de implementação e uso. Devido à licença do PostgreSQL, não neceßariamente temos o código-fonte desses derivativos; e conheço peßoas da comunidade, com muito mais conhecimento do que eu, que acham que na verdade ißo não é útil, mas apenas uma jogada de publicidade para aproveitar o nome Google. Vejamos!

Primeiras fotos do PgConBR 2008

Estão no Shutterfly as primeiras fotos da II Conferência PostgreSQL Brasil (2008). São apenas três agora, duzentas e onze devem seguir-se nos próximos dias (ou semanas...) Paciência!

Aproveitando, aceito sugestões de onde carregar fotos em resolução mais alta ou até nos originais DNG ou ORF — mas tem de ser sem limite de espaço de armazenamento.

Ingres Relacional

Mais uma notícia interessante de tentativas de implementar plenamente o modelo relacional em sistemas de produção. Hugh Darwen nos diz que

O Projeto D do Ingres busca adicionar ao servidor de bases de dados Ingres suporte à linguagem Tutorial D. […]

O Projeto D possibilitará desenvolvimento de bases de dados usando um ambiente de desenvolvimento completamente conforme à especificação D, consistindo do servidor de bases de dados Ingres e um superconjunto da linguagem Tutorial D, incluindo ferramentas de suporte. […] Vai fornecer um SGBD robusto que, no final das contas, implementará tudo do Terceiro Manifesto, dados temporais e do Modelo Relacional

• Imposição de restrições complexas de integridade de dados afetando muito pouco o desempenho da maior parte das restrições.
• Variáveis de relação virtuais, visões materializadas.
• Otimização semântica de expressões relacionais.
• Atribuição múltipla simultânea eficiente.
• Otimização de bases de dados temporais.
• Especialização por restrição.
• Atualizações irrestritas a variáveis de relação virtuais, quando possível.
• Estruturas físicas de armazenamento auto-organizadas (SGBD autônomo).

Como vêem, são objetivos ambiciosos, e que certamente demorarão para amadurecer. Atualmente, o Alphora Dataphor é uma aposta muito mais segura, embora ainda careça de portes para plataformas livres, especificamente Mono e PostgreSQL. Entretanto, o Dataphor ainda é um sistema virtual, enquanto o Projeto D do Ingres, se for bem-sucedido, será um sistema integrado e já nascerá portável, aparentemente.

Resta ver se conseguirão evitar duas decisões que a Alphora viu-se constrangida a tomar: adotar os NULLs do SQL e abandonar a especialização por restrição. E, principalmente, quando chegarão os primeiros frutos.

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: 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 à 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?