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?