Minha programação de palestras do PgBr2011:

2011-11-3

9h30 Bruce Momjian, MVCC Unmasked
11h vmWare vPostgres
14h Eu!
15h Leonardo César, \dfS pg_*: Um passeio pelas funções administrativas do postgres
16h20 Greg(ory) Smiþ, Bottom-up Database Benchmarking

2011-11-4

9h Koichi Suzuki, PostgreSQL and Postgres-XC in NTT Group
10h30 Fernando Ike de Oliveira, Escalabilidade, As Modas e (No)SQL
10h30–12h30 Dickson S. Guedes, Estripando o Elefante - dividindo seus problemas em problemas menores
14h30 Euler Taveira de Oliveira, Tudo o que você queria saber sobre PostgreSQL mas tinha vergonha de perguntar
16h50 Flavio Henrique Araque Gurgel, Meu ambiente cresceu e eu não planejei. E agora?

O que você acha dos banco de dados NoSQL que estão na moda? Eles irão passar os bancos de dados SQL no uso?

Só moda mesmo, pré-relacional. Somente passarão os SGBDs SQL se (1) o SQL for superado pelo realmente relacional, (2) eles continuarem tendo novas idéias no nível físico antes que os SGBDs SQL ou relacionais as absorvam.

O negócio é que NoSQL é simplesmente a negação do SQL, sem entender a teoria lógica de dados relacional por trás do SQL. Nenhum deles tem nada comparável, e todas as técnicas físicas podem ser incorporados a SGBDRs.

Essa moda vem cada dois ou três anos, com nomes e aspectos diferentes. SGBDOOs, SGBDMVs, serializadores Java (Prevayler &c), até LDAP…

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.

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.

Administração de Dados: um sistema livre e relacional

Finalmente, habemus um sistema (quase) relacional e livre! Não, o (outramente ótimo) PostgreSQL não é relacional — ele é SQL e, portanto, não relacional. Mas o Alphora é tão livre quanto o PostgreSQL, e é quase completamente relacional, exceto por implementar os NULLs do SQL.

Perde-se algo? Desempenho, por enquanto. O Alphora é implementado por cima de bases SQL, portanto não consegue ter o mesmo desempenho, por acrescentar uma camada com seu próprio interpretador, alguma latência, consumo de recursos &c. Mas creio que vale a pena.

Buracos? Vários. Por enquanto roda somente em MS .Net, e nos SGBDs proprietários mais o MySQL. Mas tendo sido liberado o código-fonte (espero que seja bonito, ainda não vi), a esperança é que logo seja portado para Mono e PostgreSQL. E precisa de mais e melhor documentaçã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: 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.

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?

Tentando corrigir um livro

Eſtou tentando já há meſes corrigir o (em outros aſpectos excelente) Oracle Essentials, 3ª edição, da O’Reilly:

Dr. Edgar F Codd first described the relational database concept in an IBM Research Report named Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks. His 1970 paper was published in Communications of the ACM, and was called A Relational Model of Data for Large Shared Data Banks. The inexistent System R4 Relational name seems to be a mishearing of IBM’s System R subproject of the Future System project, which was thus named in 1974: probably an author overheard someone mentioning it as something like the IBM System R, (where R stands) for Relational. Also, Oracle was not the first relational database. It was the first SQL DBMS: it is neither a database, but a DBMS, nor relational, but based on SQL, which is not relational. Actually the first relational DBMS seems to have been the original University Ingres, before it became the current PostgreSQL.

O texto original, errôneo, que tem ſido amplamente copiado e divulgado na Teia (ſegundo o Google), aparentemente porque eſtá diſponível como uma amoſtra copiável em Adobe PDF:

The Evolution of the Relational Database

The relational database concept was described first by Dr. Edgar F. Codd in an IBM research publication entitled “System R4 Relational” appearing in 1970. Initially, it was unclear whether any system based on this concept could achieve commercial success. Nevertheless, Relational Software, Incorporated (RSI) began in 1977 and released Oracle V.2 as the world’s first relational database within a couple of years. By 1985, Oracle could claim more than 1,000 relational database customer sites. By comparison, IBM would not embrace relational technology in a commercial product until the Query Management Facility in 1983.

Hoje deve ſer a terceira vez que envio o comentário acima à editora, através de ſua página de comentários. E até agora, ſe recuſaram a publicar, ſeja o meu comentário ſeja uma verſão ſanitizada dele. Se alguém tiver uma maneira mais política de dizer ißo, ou meſmo parte dißo, por favor, comente… e aguarde a publicação de seus comentários na página de errata ou, pelo menos, na de relatos ainda não confirmados. O meu comentário tem ſido ignorado.

Atualização: Há outros erros no mesmo parágrafo, também enviados à O’Reilly:

The first IBM commercial SQL product was actually 1982’s SQL/DS for DOS/VSE, announced in 1981. 1983 saw also the launch of DB2.

E:

Actually the first IBM relational product was BS12.