Esta é uma idéia bem incipiente, gostaria de discuti-la aqui. Alguns
podem achar que é fora do tópico; nesse caso, aceito sugestões de onde
debatê-la.
Vocês sabem que andei investigando ferramentas de modelagem, e acabei
ficando frustrado. Pelo que olhei e até testei, as ferramentas
‘profissionais’ estão por volta de US$4K, chegando facilmente a US$8K se
a gente quiser ‘luxos’ (¡não!) como versionamento. As ferramentas
livres são inexistentes, incompletas e (ou) imaturas; escolha pelo menos
dois desses adjetivos. Além de falta de suporte a sistemas livres e vai
por aí afora.
Mas agora o que tem me irritado é o próprio fluxo de trabalho dessas
ferramentas. Não são nada práticas, forçando tudo a passar por
diagramas. Eu preferiria fazer tudo em texto, e ter diagramas como
saídas do processo, não entradas. E tive a idéia maluca de escrever uma
proposta a respeito, mas queria saber se alguém já viu algo assim, ou se
é absurdo.
Hoje, numa ferramenta de modelagem de dados, o processo começa com
a definição de um dicionário de dados. Usando esse dicionário de dados,
cria-se um Diagrama de Entidades e Relacionamentos, DER. Esse diagrama
é então traduzido para o sabor SQL do SGBD relevante.
O problema óbvio é que diagramas são menos expressivos e mais
chatos de fazer que um programa SQL ou (idealmente) relacional. Então
por que não escrever ISO SQL, Tutorial D ou mesmo D4 (desculpem os
idealistas, também sou idealista mas…)?
Não seria fácil, mas creio que seria possível, com planejamento e
paciência, criar um sistema muito mais produtivo e flexível usando a
filosofia Unix: cada tarefa deve ser bem feita por um componente. As
interfaces são bem definidas, e cada ferramenta pode ser substituída ou
melhorada independentemente.
No caso, a gente começaria com uma gramática (por exemplo) Tutorial D
ou D4. Talvez usar um derivado de Scheme ou ML para obter mais concisão
e poder programático, creio que já fizeram um SchemeQL ou coisa assim.
Mas talvez um subconjunto 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 suficientemente expressivo de todas as situações com que um SGBD
deva lidar — especificamente, todos os tipos de restrições de
integridade.
Nessa 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-se validadores e
compiladores. O resultado dos compiladores seria um programeta
(/script/) de definição de dados para o(s) SGBD(s) alvo de escolha, por
exemplo nosso caro Dumbo.
Dessa mesma definição, usaríamos um AutoDoc ou SQL Fairy (cuidado, a
página inicial dele cega!) para gerarmos todos os diagramas que
quiséssemos: DER, IDEFIX &c para benefício dos usuários. Até aí é
trabalho do Administrador (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
possibilidade dessa idéia ser muito pior do que me parece, é o segundo
passo: findo o trabalho do AD, começa o do Administrador de Bases de
Dados, o sempre popular ABD (ou DBA, para os anglófilos). Ele teria de
pegar essa definição da Base de Dados (BD) e acrescentar tudo o que é
físico: índices, parâmetros de armazenamento &c. Não me parece
especialmente difícil; ele poderia fazê-lo seja numa extensão da nossa
linguagem conceitual, seja na linguagem do sistema alvo. Ou mesmo
através de remendos (/patches/) a aplicar ao modelo conceitual, como se
faz em programação tradicional mesmo.
Tenho certeza de que há muitos percalços nos quais não pensei, mas
queria saber de vocês o que acham.
Para concluir, creio que um sistema assim poderia ser o começo
de coisas muito melhores. Por exemplo, o único SGBDR hoje em produção é
o Alphora Dataphor, que tem algo semelhante não para modelagem de dados
mas para o sistema como um todo: a gente escreve D4 (que é uma D válida)
e os comandos são executados num SGBD SQL (infelizmente ainda não
suporta o Jumbo). É um sistema proprietário e complexo, e ainda por
cima em MS .Net, mas é uma boa idéia. Não consigo imaginar hoje um
projeto dum /clone/ ou equivalente livre dele, mas esse nosso sistema
eventualmente poderia ser um primeiro passo.
Deu para entender?
--
Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]>
Atech Fundação Aplicação de Tecnologias Críticas SP, BR
msnim:[EMAIL PROTECTED]
skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151
- - - - -
Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou
privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber
esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas
ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta
mensagem por engano, por favor avise imediatamente o remetente, respondendo o
e-mail e em seguida apague-o. Agradecemos sua cooperacao.
Privacy Policy: This message may contain confidential and/or privileged
information. If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose or take any action based on this
message or any information herein. If you have received this message in error,
please advise the sender immediately by reply e-mail and delete this message.
Thank you for your cooperation._______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
