Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-12-08 Por tôpico Lorn
Oi pessoal, eu conheci a ideia no pgcon 2007 e gostaria de saber se alguem
fez algum tipo de rascunho dessa linguagem para especificar o SQL ? ou até
um rascunho em D especificando isso.Pelo que eu entendi o pessoal chegou a
conclusão que XML não é legal pra isso, eu concordo.

On Jul 19, 2007 3:29 PM, Roberto Mello [EMAIL PROTECTED] wrote:

 On Wed, Jul 18, 2007 at 06:25:27PM -0300, Euler Taveira de Oliveira wrote:
  
  Não entendi porque XML complica. Não sei se um parser para D é melhor do
  que um parser XML, mas é mais fácil encontrar um parser XML do que um em
 D.

 Por que XML, por definicao, e' complicado. Como disse o James Clark
 (inventor do XML): any damn fool could produce a better data format than
 XML.

  E quem disse que com um esquema XML você vai restringir capacidades? Se
  a sua estrutura for bem montada, você pode armazenar quaisquer tipos de
  objetos e propriedades que o seu SGBD suportar.

 A meu ver, parece uma reinvencao da roda, desnecessaria.

  Por que por XML no meio? Simplesmente porque uma representação em D ou
  SQL é difícil de fazer um parsing; O XML tem uma estrutura bem
  definida, assim podemos obter a informação precisa (com XPath ou
 XQuery).

 XML nao tem estrutura definida, nao a estrutura que vai ser util para a
 aplicacao em questao. Voce mesmo disse acima que SE a sua
 estrutura [em XML] for bem montada (enfase minha). SE for bem montada.
 Quer dizer que ainda tem que design e montar a estrutura.

 -Roberto

 --
 In the long run, every program becomes rococo, and then rubble.
-- Alan Perlis
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Lindolfo Lorn Rodrigues
- www.slackwarezine.com.br
- http://lornlab.org
- http://sao-paulo.pm.org
use Catalyst;
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-07-19 Por tôpico Leandro Guimarães Faria Corcete DUTRA
Em Qua, 2007-07-18 às 18:25 -0300, Euler Taveira de Oliveira escreveu:
 Não entendi porque XML complica. Não sei se um parser para D é melhor do
 que um parser XML, mas é mais fácil encontrar um parser XML do que um em D.

Mas eu não quero escrever XML, nem diagramar.  Quero escrever D e ter o
diagrama automaticamente gerado.


 E quem disse que com um esquema XML você vai restringir capacidades? Se
 a sua estrutura for bem montada, você pode armazenar quaisquer tipos de
 objetos e propriedades que o seu SGBD suportar.

Não é essa a idéia, a idéia é escrever o modelo conceitual, com todas
as regras de negócios.  Vai ter de criar um esquema XML muito mais
complicado que uma D.


 Por que por XML no meio? Simplesmente porque uma representação em D ou
 SQL é difícil de fazer um parsing; O XML tem uma estrutura bem
 definida, assim podemos obter a informação precisa (com XPath ou XQuery).

D também tem uma estrutura bem definida.  Por isso é uma linguagem de
programação, não uma linguagem natural.

E é muito mais fácil de ler, escrever e depurar.

Por exemplo, essa minha idéia é um primeiro passo.  Nada impede que
depois se desenvolva num SGBDR virtual, como o Alphora Dataphor, ou
mesmo num SGBDR completo.  Você não vai querer XML como linguagem de
programação e interação num SGBD.


  Que diagrama?  Lembre-se, a idéia é simplesmente gerar diagramas com um
  AutoDoc da vida.
  
 Você quer uma ferramenta que gere os diagramas a partir do catálogo do
 BD ou uma ferramenta que, além disso, possa diagramar?

Nem uma, nem outra.  Vide proposta inicial, mas a idéia é escrever o
modelo conceitual, e dele tanto traduzir automaticamente para diversos
SGBDs quanto gerar diagramas à la AutoDoc.

Capito?

  Na última opção
 um formato intermediário, seria ideal para o versionamento e
 representação unificada do modelo de dados.

Nem assim.  D seria ideal para a representação do modelo de dados.

-- 
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


Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-07-18 Por tôpico Leandro Guimarães Faria Corcete DUTRA
Em Ter, 2007-07-17 às 17:44 +, Johnny Taylor Faria Chaves escreveu:
  Olhando as entradas da Wikipædia para XMI, MOF e correlatos parece que
  a gente introduziria mais complicações que soluções — o que o XMI daria
  de ganho em relação a ler um D qualquer e traduzir para os SQLs da vida?
 
 Apenas aproveitar as ferrramentas que já existam e que usem o XMI.

Isso coloca alguns problemas:

1) XMI não parece ser um D válido, portanto exigiria extensões
significativas.

2) XMI é uma linguagem de marcação de texto, não de programação.

3) XMI em si parece ser bastante complexo.


Em contrapartida, já temos:

1) Pelo menos dois Ds válidos já definidos, Tutorial D e D4, além da
possibilidade de usar ISO SQL.

2) Alguns programas (vide http://thethirdmanifesto.com) que já processam
Tutorial D, e o SQL Fairy para lidar com ISO SQL.

3) Um exemplo arquitetural interessante, se fechado, que é o Alphora
Dataphor; e um aberto, o SchemeQL.  Isso o que me vem à mente,
certamente há outros.

Portanto, o que eu me preocuparia agora é com a seleção da linguagem…

-- 
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


Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-07-18 Por tôpico Johnny Taylor Faria Chaves
Em Qua 18 Jul 2007, Leandro Guimarães Faria Corcete DUTRA escreveu:

 1) XMI não parece ser um D válido, portanto exigiria extensões
 significativas.

 2) XMI é uma linguagem de marcação de texto, não de programação.

 3) XMI em si parece ser bastante complexo.

Eu pensei em escrever em algum D e transformar em XMI, para ter apenas um 
parser/tradutor ou seja o que for que fosse criado, mas parece que o XMI não 
serve nem para isso :( . 



   Em contrapartida, já temos:

 1) Pelo menos dois Ds válidos já definidos, Tutorial D e D4, além da
 possibilidade de usar ISO SQL.

 2) Alguns programas (vide http://thethirdmanifesto.com) que já processam
 Tutorial D, e o SQL Fairy para lidar com ISO SQL.

Sabe de alguma tradução do manifesto?


   Portanto, o que eu me preocuparia agora é com a seleção da linguagem…

Certo, vou olhar SchemeQL e o thethirdmanifesto.com.



-- 
Johnny Taylor Faria Chaves - LUN 157066
Não combato ou defendo pessoas ou grupos,
Combato ou defendo idéias ou atos.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-07-18 Por tôpico Daniel Gaspary
Pessoal,

Que tal uma revisão do que buscam ?

Estou meio confuso sobre o que vocês procuram e o que falta para
isso. Confesso que reli o primeiro mail da Thread e não entendi qual a
real necessidade. Talvez por não fazer parte do meu dia-a-dia a
necessidade de trabalhar com tanta modelagem como parece ser do seu
cotidiano.

   Talvez seja só lentidão minha que impede de entender... :). Me
interessei no assunto, mas acho que começaram a aparecer outras
necessidades nas ferramentas que saíam do assunto original.
Versionamento, por exemplo.

   De repente, alguém (o Leandro pode ser o mais indicado) poderia
listar de forma concisa as características dessa ferramenta ideal ou
ambiente ideal para modelar/analisar/manter um Banco de dados.


   Obrigado,

Daniel



On 7/18/07, Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] wrote:
 Em Qua, 2007-07-18 às 11:10 +, Johnny Taylor Faria Chaves escreveu:
  Eu pensei em escrever em algum D e transformar em XMI, para ter apenas um
  parser/tradutor ou seja o que for que fosse criado, mas parece que o XMI não
  serve nem para isso :( .

 ...
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-07-18 Por tôpico Leandro Guimarães Faria Corcete DUTRA
Em Qua, 2007-07-18 às 14:46 -0300, Daniel Gaspary escreveu:
 Que tal uma revisão do que buscam ?

Sem problemas.


 Estou meio confuso sobre o que vocês procuram e o que falta para
 isso. Confesso que reli o primeiro mail da Thread e não entendi qual a
 real necessidade. Talvez por não fazer parte do meu dia-a-dia a
 necessidade de trabalhar com tanta modelagem como parece ser do seu
 cotidiano.

Realmente, apesar d’eu já ter pensado nisso antes, foi só me
concentrando em modelagem que senti a importância e a oportunidade.


Talvez seja só lentidão minha que impede de entender... :). Me
 interessei no assunto, mas acho que começaram a aparecer outras
 necessidades nas ferramentas que saíam do assunto original.
 Versionamento, por exemplo.

Creio que cheguei a mencionar no assunto original que versionamento
seria trivial de fazer com texto, mas é difícil e caro com diagramas.


De repente, alguém (o Leandro pode ser o mais indicado) poderia
 listar de forma concisa as características dessa ferramenta ideal ou
 ambiente ideal para modelar/analisar/manter um Banco de dados.

Não é uma ferramenta, mas um processo com várias ferramentas.

Escreve-se o modelo em D, onde claro é uma linguagem relacional sã e
completa.

Traduz-se esse modelo em D para o(s) SQL(s) necessários.

Essa é a essência.

Daí aparecem várias possibilidades e (ou) necessidades.  Reversas de
diversos sabores de SQL para D, relatório sobre partes do modelo que não
puderam ser implementadas em determinado sabor SQL (por exemplo, algumas
restrições de integridade), um AutoDoc para D, tradutores para diversos
sabores SQL e comandos DML (aí sim já saindo do âmbito de modelagem), e
vai por aí afora.

Ficou mais claro?

Uma outra maneira de pensar nisso seria reconstruir um Alphora
Dataphor, ou um SGBDR baseado em SQL (que em si não é relacional), um
tijolo de cada vez.

-- 
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


Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-07-18 Por tôpico Euler Taveira de Oliveira
Leandro Guimarães Faria Corcete DUTRA wrote:

   Creio que cheguei a mencionar no assunto original que versionamento
 seria trivial de fazer com texto, mas é difícil e caro com diagramas.
 
Por que é caro? Se você representar os dados em um formato
semi-estruturado (XML por exemplo) fica fácil adicionar versionamento.

   Não é uma ferramenta, mas um processo com várias ferramentas.
 
   Escreve-se o modelo em D, onde claro é uma linguagem relacional sã e
 completa.
 
Acho que o foco é montar uma estrutura que possa ser traduzida para
vários SGBDs. Particularmente, acho que D não seria a melhor opção. Na
minha opinião, uma estrutura semi-estruturada seria uma boa pois você
pode definir um modelo próximo a estrutura dos bancos de dados
suportados e escrever um tradutor (XSLT por exemplo) para transformar o
modelo em DDL/DML necessários. Fácil, simples e rápido.

   Daí aparecem várias possibilidades e (ou) necessidades.  Reversas de
 diversos sabores de SQL para D, relatório sobre partes do modelo que não
 puderam ser implementadas em determinado sabor SQL (por exemplo, algumas
 restrições de integridade), um AutoDoc para D, tradutores para diversos
 sabores SQL e comandos DML (aí sim já saindo do âmbito de modelagem), e
 vai por aí afora.
 
A parte reversa seria um pouco mais complicada. Teria que existir
tradutores diferentes para cada SGBD suportado; esses tradutores fariam
a leitura do catálogo ou dicionário de dados de cada SGBD e
transformaria isso no modelo (XML?) suportado pela ferramenta.
A documentação de tais diagramas poderia ser feita em qualquer uma das
partes (diagrama gerado ou catálogo). Utilizando o diagrama, poderia ser
criado um novo tradutor (XSLT por exemplo) para gerar um relatório
(HTML?) específico para um SGBD ou um genérico.


-- 
  Euler Taveira de Oliveira
  http://www.timbira.com/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-07-18 Por tôpico Leandro Guimarães Faria Corcete DUTRA
Em Qua, 2007-07-18 às 15:45 -0300, Euler Taveira de Oliveira escreveu:
 Leandro Guimarães Faria Corcete DUTRA wrote:
 
  Creio que cheguei a mencionar no assunto original que versionamento
  seria trivial de fazer com texto, mas é difícil e caro com diagramas.
  
 Por que é caro?

Era referência a quanto se cobra nas ferramentas proprietárias…


  Se você representar os dados em um formato
 semi-estruturado

O que você quer dizer com isso?


  (XML por exemplo) fica fácil adicionar versionamento.

Exatamente — as ferramentas tradicionais não têm tal formato, só para
exportação.

E os diagramas aí só complicam, como o XML também.  Um D basta, e é
mais simples e direto.


  Escreve-se o modelo em D, onde claro é uma linguagem relacional sã e
  completa.
  
 Acho que o foco é montar uma estrutura que possa ser traduzida para
 vários SGBDs. Particularmente, acho que D não seria a melhor opção.

Por quê?

Eu quero um D, porque quero algo que não se restrinja às capacidades
dos atuais SGBD.  Quero algo que dê conta de qualquer extensão ao SQL, e
a eventuais SGBDRs, assim como outras cositas menos cotadas como
quase-SGBDs.


 Na minha opinião, uma estrutura semi-estruturada

!?

 seria uma boa pois você
 pode definir um modelo próximo a estrutura dos bancos de dados
 suportados e escrever um tradutor (XSLT por exemplo) para transformar o
 modelo em DDL/DML necessários. Fácil, simples e rápido.

Cara, pára de colocar XML no meio… não tem necessidade.  Se não for um
D, vai ISO SQL mesmo.  Para que algo mais complicado que isso?


 A parte reversa seria um pouco mais complicada. Teria que existir
 tradutores diferentes para cada SGBD suportado; esses tradutores fariam
 a leitura do catálogo ou dicionário de dados de cada SGBD e
 transformaria isso no modelo (XML?) suportado pela ferramenta.

Claro.  Mas não creio que seja tão difícil, afinal os catálogos
costumam não ser tão ruins… exceto o do MS SQL Server que é chato e o do
MySQL que é péssimo, mas sempre se pode trabalhar de DDLs exportados ou
do INFORMATION_SCHEMA que começa a ser amplamente suportado (MySQL v5,
por exemplo).

O negócio é começar com um decente (PostgreSQL), aí fazer um outro
quase tanto quanto (DB2), depois os razoáveis (Oracle), e depois o resto
(vide acima).


 A documentação de tais diagramas poderia ser feita em qualquer uma das
 partes (diagrama gerado ou catálogo).

Que diagrama?  Lembre-se, a idéia é simplesmente gerar diagramas com um
AutoDoc da vida.


 Utilizando o diagrama, poderia ser
 criado um novo tradutor (XSLT por exemplo) para gerar um relatório
 (HTML?) específico para um SGBD ou um genérico.

Não, esqueça o diagrama!  O D da vida é o cerne da coisa.

Mas você lembrou bem, outra ferramenta seria um gerador de relatórios.
E tanto faz, RTF, SGML [(X)HTML ou coisa que o valha], ODF, LaΤeχ…


-- 
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


Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-07-18 Por tôpico Euler Taveira de Oliveira
Leandro Guimarães Faria Corcete DUTRA wrote:

   E os diagramas aí só complicam, como o XML também.  Um D basta, e é
 mais simples e direto.
 
Não entendi porque XML complica. Não sei se um parser para D é melhor do
que um parser XML, mas é mais fácil encontrar um parser XML do que um em D.

   Eu quero um D, porque quero algo que não se restrinja às capacidades
 dos atuais SGBD.  Quero algo que dê conta de qualquer extensão ao SQL, e
 a eventuais SGBDRs, assim como outras cositas menos cotadas como
 quase-SGBDs.
 
E quem disse que com um esquema XML você vai restringir capacidades? Se
a sua estrutura for bem montada, você pode armazenar quaisquer tipos de
objetos e propriedades que o seu SGBD suportar.

   Cara, pára de colocar XML no meio… não tem necessidade.  Se não for um
 D, vai ISO SQL mesmo.  Para que algo mais complicado que isso?
 
Por que por XML no meio? Simplesmente porque uma representação em D ou
SQL é difícil de fazer um parsing; O XML tem uma estrutura bem
definida, assim podemos obter a informação precisa (com XPath ou XQuery).

 A documentação de tais diagramas poderia ser feita em qualquer uma das
 partes (diagrama gerado ou catálogo).
 
   Que diagrama?  Lembre-se, a idéia é simplesmente gerar diagramas com um
 AutoDoc da vida.
 
Você quer uma ferramenta que gere os diagramas a partir do catálogo do
BD ou uma ferramenta que, além disso, possa diagramar? Na última opção
um formato intermediário, seria ideal para o versionamento e
representação unificada do modelo de dados.


-- 
  Euler Taveira de Oliveira
  http://www.timbira.com/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-07-18 Por tôpico Johnny Taylor
Euler Taveira de Oliveira escreveu:

 ...

Por que por XML no meio? Simplesmente porque uma representação em D ou
SQL é difícil de fazer um parsing; O XML tem uma estrutura bem
definida, assim podemos obter a informação precisa (com XPath ou XQuery).
  

Na sua visão, como seria para escrever o XML? Ou seja a como fazer a 
modelagem mesmo, pois o que *eu* quero é fazer isso usando qualquer 
editor de textos.



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-07-17 Por tôpico Johnny Taylor Faria Chaves
Em Sex 06 Jul 2007, Leandro Guimarães Faria Corcete DUTRA escreveu:
...

 Gerar diagramas é tranqüilo, as ferramentas já existem e bastaria
 adaptar.

Estive pensando em gerar (seja de qual linguagem for que se utilizasse) para 
XMI, mas parece que não dá suporte a domínios, ou será que usa outro nome?

As especificações do XMI:
http://www.omg.org/cgi-bin/apps/doc?formal/05-09-01.pdf


 Versionar seria basicamente usar os RCS, CVS, Darcs da vida, o que
 for.  Qualquer ferramenta de controle de código-fonte.

Esse é um efeito colateral que ajuda também, como são feitos os controles de 
versão nos diagramas gráficos? Na mão, escritos em alguma parte no corpo do 
próprio diagrama?


-- 
Johnny Taylor Faria Chaves - LUN 157066
Não combato ou defendo pessoas ou grupos,
Combato ou defendo idéias ou atos.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-07-17 Por tôpico Leandro Guimarães Faria Corcete DUTRA
Em Ter, 2007-07-17 às 16:40 +, Johnny Taylor Faria Chaves escreveu:
  Gerar diagramas é tranqüilo, as ferramentas já existem e bastaria
  adaptar.
 
 Estive pensando em gerar (seja de qual linguagem for que se utilizasse) para 
 XMI, mas parece que não dá suporte a domínios, ou será que usa outro nome?
 
 As especificações do XMI:
 http://www.omg.org/cgi-bin/apps/doc?formal/05-09-01.pdf

Parece que tem algo em 4.14, mas sendo da OMG dá medo…

Olhando as entradas da Wikipædia para XMI, MOF e correlatos parece que
a gente introduziria mais complicações que soluções — o que o XMI daria
de ganho em relação a ler um D qualquer e traduzir para os SQLs da vida?


  Versionar seria basicamente usar os RCS, CVS, Darcs da vida, o que
  for.  Qualquer ferramenta de controle de código-fonte.
 
 Esse é um efeito colateral que ajuda também, como são feitos os controles 
 de 
 versão nos diagramas gráficos? Na mão, escritos em alguma parte no corpo do 
 próprio diagrama?

Geralmente existe um repositório SQL que contém as versões, mas são
ainda mais caros.


-- 
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


Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-07-17 Por tôpico Johnny Taylor Faria Chaves
Em Ter 17 Jul 2007, Leandro Guimarães Faria Corcete DUTRA escreveu:
 Em Ter, 2007-07-17 às 16:40 +, Johnny Taylor Faria Chaves escreveu:
   Gerar diagramas é tranqüilo, as ferramentas já existem e
   bastaria adaptar.
 
  Estive pensando em gerar (seja de qual linguagem for que se utilizasse)
  para XMI, mas parece que não dá suporte a domínios, ou será que usa outro
  nome?
 
  As especificações do XMI:
  http://www.omg.org/cgi-bin/apps/doc?formal/05-09-01.pdf

   Parece que tem algo em 4.14, mas sendo da OMG dá medo…

   Olhando as entradas da Wikipædia para XMI, MOF e correlatos parece que
 a gente introduziria mais complicações que soluções — o que o XMI daria
 de ganho em relação a ler um D qualquer e traduzir para os SQLs da vida?

Apenas aproveitar as ferrramentas que já existam e que usem o XMI.

-- 
Johnny Taylor Faria Chaves - LUN 157066
Não combato ou defendo pessoas ou grupos,
Combato ou defendo idéias ou atos.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-07-06 Por tôpico Leandro Guimarães Faria Corcete DUTRA
Diogo Biazus [EMAIL PROTECTED] writes:

 Todos estamos, já pensei várias vezes em começar uma ferramenta de
 modelagem, mas ponho fé no trabalho do Euler com o PgAdmin.

Creio que isso não me é problema algum, porque me parece que o
objetivo dele — aliás, do pgAdmin — é bem diferente do meu.

Pelo que entendi, o pgAdmin inclui uma funcionalidade de modelagem
básica e tradicional (gráfica) exclusivamente para o PostgreSQL.  Eu quero
modelagem completa — idealmente, todas as regras de negócio — *e textual* para
qualquer SGBD.  O único privilégio do PostgreSQL seria suportar um subconjunto
maior da funcionalidade que a maioria dos outros SGBDs.


 Também gosto da idéia. Embora trabalhar com diagramas seja interessante,
 nenhuma ferramenta implementa eles de forma que sejam suficientes para o
 processo de modelagem.

E alguém tem alguma idéia de que forma os diagramas poderiam ser
implementados com vistas à suficiência para modelagem?

Particularmente, duvido que seja possível que sejam suficientes, muito
menos eficientes.


 O maior problema seriam as diferenças no tratamento de linhas
 duplicadas, nulos, e outras diferenças fundamentais.

Era o que eu temia.


 Pois essas partes implicam mudanças no executor, índices e um monte de
 coisas dentro do banco.

Quisera eu entender essa parte interna.


 A parte de sintaxe me parece mais tranquila, se você estiver disposto a
 ter um híbrido relacional/sql como produto final não seria tão complicado.

Bom, o SQL já é um híbrido relacional, então não vejo a graça… nesse
caso seria melhor implementar o ISO SQL:2003 mesmo, ou algo derivado dele.


 Na verdade o Postgres original suportava QUEL, uma outra linguagem.
 E o 'primo' Ingres ainda suporta QUEL.  Então imagino que seja viável,
 seja criando mais uma interface para o PostgreSQL, seja bifurcando o
 projeto.

 Sim, viável é, mas vale o esforço?

Duvido.


 Alterar o PostgreSQL para ter uma linguagem relacional me parece muito
 esforço para pouco resultado (desculpem-me os idealistas).

Acho que o resultado seria fantástico.  Mas o esforço também.

E tenho minhas dúvidas se seria uma adaptação ou uma bifurcação mesmo.


 Acho a idéia do Leandro de ter um sistema de modelagem sobre o SGBD mais
 interessante.

Veja que não são idéias mutuamente excludentes.  Na verdade acho que a
minha poderia teoricamente facilitar a solução definitiva, que seria mesmo um
SGBDR.  Porque todos os modelos criados com a ferramente de modelagem poriam
ser facilmente implementados num SGBDR; principalmente se compartilharem uma
linguagem D, como talvez a Tutorial D, D4 ou, sei lá, um eventual SchemeD.


 Mas quem sabe usamos UML?

Então… fiquei espantadíssimo do UML não suportar nem domínios, pelo
menos não obviamente.


-- 
+55 (11) 9406 7191   http://br.geocities.com./lgcdutra/
+55 (11) 5685 2219  gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 3040 7300 r151   Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 5686 9607ICQ/AIM: aim:GoIM?screenname=61287803
  MSN: msnim:[EMAIL PROTECTED]

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-07-06 Por tôpico Leandro Guimarães Faria Corcete DUTRA
Wallace Reis [EMAIL PROTECTED] writes:
 On 6/28/07, Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] wrote:
 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.

 Leandro, não sei se vc conhece o projeto XCDSQL (XML (en)Coded and
 Documented SQL)[1]. Talvez seria um bom começo.

Olha, não tenho muita simpatia por forçar SGML fora de seu âmbito
original, que é a documentação.  Acho muito chique HTML 5 ou XHTML 2 com CSS,
totalmente a favor de DocBook (embora esteja apaixonado por Τεχ) — mas não
entendo o que pode ajudar em bases de dados.

Eu pensei em Scheme, se alguém achar Tutorial D, D4 ou mesmo ISO
SQL:2003 feios (e num certo nível, eu concordaria).  Não vejo porque jogar XML
no meio…

Mas obrigado pela dica mesmo assim.

-- 
+55 (11) 9406 7191   http://br.geocities.com./lgcdutra/
+55 (11) 5685 2219  gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 3040 7300 r151   Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 5686 9607ICQ/AIM: aim:GoIM?screenname=61287803
  MSN: msnim:[EMAIL PROTECTED]

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-07-06 Por tôpico Leandro Guimarães Faria Corcete DUTRA
Johnny Taylor Faria Chaves [EMAIL PROTECTED] writes:

 Ter um conjunto de ferramentas bem modulares para modelar, gerar
 diagramas, alterar o modelo físico e fazer o versionamento do banco,
 seria ótimo.

 Talvez seja o caminho mais viável, alguma idéia?

Essa exatamente foi minha idéia original.

Ainda tenho algumas dúvidas; por exemplo, na minha idéia original o AD
escreveria o modelo conceitual e gerar-se-ia o físico também textualmente, o
qual o DBA poderia alterar; mas seria legal se já soubéssemos como o fluxo
funcionaria por exemplo no caso de alterações no conceitual depois do físico
ajustado; usar ferramentas de diferença e remendo (/diff/ e /patch/)?

Gerar diagramas é tranqüilo, as ferramentas já existem e bastaria
adaptar.

Versionar seria basicamente usar os RCS, CVS, Darcs da vida, o que
for.  Qualquer ferramenta de controle de código-fonte.

Mas de qualquer maneira, não sei bem por onde começar.

-- 
+55 (11) 9406 7191   http://br.geocities.com./lgcdutra/
+55 (11) 5685 2219  gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 3040 7300 r151   Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 5686 9607ICQ/AIM: aim:GoIM?screenname=61287803
  MSN: msnim:[EMAIL PROTECTED]

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-07-05 Por tôpico Wallace Reis
On 6/28/07, Leandro Guimarães Faria Corcete DUTRA [EMAIL PROTECTED] wrote:
 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.

Leandro, não sei se vc conhece o projeto XCDSQL (XML (en)Coded and
Documented SQL)[1]. Talvez seria um bom começo.

[1] http://www.xcdsql.org/

-- 
wallace reis/wreis
Núcleo de Biologia Computacional e
Gestão de Informações Biotecnológicas/LABBI
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-07-05 Por tôpico Daniel Gaspary
Sobre usar outra linguagem com o PostgreSql...

Creio que colocar Quel para dentro do PG é inviável. Não digo
tecnicamente, mas sim de disponibilidade / tempo / vontade.

Uma alternativa que tive idéia lendo o que falaram foi implementar na
forma de uma camada intermediária.

A mais simples (que seria bem trabalhosa também, creio) seria, por exemplo.

Fazer com que Quel rode sobre a máquina virtual do Java (JVM), o Java
6 tem suporte (facilitado) a linguagens de Script, tanto que hoje
existe Ruby rodando sobre JVM, suportado pela Sun.

Então Alguma alma caridosa Desenvolve o Quel para rodar na JVM. É
feito um mapeamento das expressões Quel para obter obter os  dados via
JDBC.

Existe também a alternativa de implementar a SPI do postgresql. Mas
essa talvez sirva só para procedures, implementar uma PL/Quel da vida
:)

http://www.postgresql.org/docs/8.2/interactive/spi.html

   Já sonhei com algo no Postgresql em que pudessemos escrever
   relacional e usar alguma parte do SGSB (sem passar por SQL) para
   executar, mas creio que isso seja sonha demais.
 
  Por quê?
 
  Difícil sim, nem faço idéia como se poderia começar.
 
  Na verdade o Postgres original suportava QUEL, uma outra linguagem.
  E o 'primo' Ingres ainda suporta QUEL.  Então imagino que seja viável,
  seja criando mais uma interface para o PostgreSQL, seja bifurcando o
  projeto.


 Me lembrei disso, e o ingres foi liberado com uma licença livre, não lembro
 qual e se continua ou foi apenas uma versão, cheguei a baixa-lo, mas não fui
 adiante. Se for com o PostgreSQL, seria ideal mais uma interface, era o que
 tinha em mente.


 Leandro, tenho recebido alguns caracteres estranhos em suas mensagens, uso o
 kmail com utf8 como primeira opção, se eles retornarem estranhos, me desculpe
 por enquanto.

 []'s

 --
 Johnny Taylor Faria Chaves - LUN 157066
 Não combato ou defendo pessoas ou grupos,
 Combato ou defendo idéias ou atos.
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-07-05 Por tôpico Diogo Biazus
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.


Acho que essa lista também se destina a discussões mais teóricas, desde
que relacionadas de alguma forma ao PostgreSQL.

 Acabei não participando das conversas na outra discussão, mas notei
 que estamos numa mesma encruzilhada.

Todos estamos, já pensei várias vezes em começar uma ferramenta de
modelagem, mas ponho fé no trabalho do Euler com o PgAdmin.

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.

 Também gostaria disso, mas não tenho estrutura para iniciar algo
 assim.

Também gosto da idéia. Embora trabalhar com diagramas seja interessante,
nenhuma ferramenta implementa eles de forma que sejam suficientes para o
processo de modelagem.

 Não creio que seja absurdo, mas quem fizesse seria considerado
 herege, pelos analistas empurra rato, desabafohoje mesmo me
 frustei muito tentando conversar com uma dessas /desabafo.

 Fiquei curioso.  Como você descreve um 'analista empurra-rato', e
 aliás de onde vem eßa expreßão?

Também fiquei curioso, explique por favor.

 Já sonhei com algo no Postgresql em que pudessemos escrever
 relacional e usar alguma parte do SGSB (sem passar por SQL) para
 executar, mas creio que isso seja sonha demais.

O maior problema seriam as diferenças no tratamento de linhas
duplicadas, nulos, e outras diferenças fundamentais.
Pois essas partes implicam mudanças no executor, índices e um monte de
coisas dentro do banco.
A parte de sintaxe me parece mais tranquila, se você estiver disposto a
ter um híbrido relacional/sql como produto final não seria tão complicado.

 Na verdade o Postgres original suportava QUEL, uma outra linguagem.
 E o 'primo' Ingres ainda suporta QUEL.  Então imagino que seja viável,
 seja criando mais uma interface para o PostgreSQL, seja bifurcando o
 projeto.

Sim, viável é, mas vale o esforço?
Alterar o PostgreSQL para ter uma linguagem relacional me parece muito
esforço para pouco resultado (desculpem-me os idealistas).
Acho a idéia do Leandro de ter um sistema de modelagem sobre o SGBD mais
interessante.
Ter um conjunto de ferramentas bem modulares para modelar, gerar
diagramas, alterar o modelo físico e fazer o versionamento do banco,
seria ótimo.

Mas quem sabe usamos UML?
(brincadeirinha)

-- 
Diogo Biazus - [EMAIL PROTECTED]
Móvel Consultoria
http://www.movelinfo.com.br
http://www.postgresql.org.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-07-05 Por tôpico Johnny Taylor Faria Chaves
Em Qui 05 Jul 2007, Diogo Biazus escreveu:

 O maior problema seriam as diferenças no tratamento de linhas
 duplicadas, nulos, e outras diferenças fundamentais.
 Pois essas partes implicam mudanças no executor, índices e um monte de
 coisas dentro do banco.
 A parte de sintaxe me parece mais tranquila, se você estiver disposto a
 ter um híbrido relacional/sql como produto final não seria tão complicado.

Poderia ser um híbrido, e (*eu*) só usar o relacional, mas, como já disse não 
tenho estrutura para algo assim.

 Alterar o PostgreSQL para ter uma linguagem relacional me parece muito
 esforço para pouco resultado (desculpem-me os idealistas).
 Acho a idéia do Leandro de ter um sistema de modelagem sobre o SGBD mais
 interessante.
 Ter um conjunto de ferramentas bem modulares para modelar, gerar
 diagramas, alterar o modelo físico e fazer o versionamento do banco,
 seria ótimo.

Talvez seja o caminho mais viável, alguma idéia?


 Mas quem sabe usamos UML?
 (brincadeirinha)

Arrumei um livro (UML Essencial), ainda estou no começo mas a impressão que 
estou tendo, e creio que já foi dito aqui (na postgresql-br), é que UML é boa 
para a análise e documentação *do sistema*, mas muitos querem leva-la para os 
bancos de dados.

-- 
Johnny Taylor Faria Chaves - LUN 157066
Não combato ou defendo pessoas ou grupos,
Combato ou defendo idéias ou atos.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-07-04 Por tôpico Johnny Taylor Faria Chaves
Em Sex 29 Jun 2007, Leandro Guimarães Faria Corcete DUTRA escreveu:
 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.
 
  O ideal, seria na bancosdedados, mas, como voce disse em outra
  mensagem, ela anda meio parada (ou parada e meia  ).

 Mea culpa, mea culpa, mea maxima culpa.

 Por outro lado, ela foi criada numa época em que, lá no Yahoo!,
 algumas pessoas reclamaram das discußões conceituais e da gente querer
 ensinar o melhor.  Como eßa época paßou, não vejo mal algum em
 retomarmos eßas discußões aqui.

Ótimo.


  Acabei não participando das conversas na outra discussão, mas notei
  que estamos numa mesma encruzilhada.

 Não sabia.  Te importas em compartilhar conosco tuas experiências?

É que estou envolvido em dois projetos.
Um, quase fracassando, onde combinamos fazer o BD o mais ANSI possível, mas 
decidiram usar .NET e ms sql server e mesmo os que tomaram essa decisão não 
conhecem as ferramentas. 
Outro ainda em fase de proposta vai, proposta vem, em uma entidade 
governamental, que deve usar exclusivamente PostgreSQL, mas terei 
(provavelmente) que usar diagramas para comunicar com outros (pessoas e/ou 
setores).

 Não creio que seja absurdo, mas quem fizesse seria considerado 
 herege, pelos analistas empurra rato, desabafohoje mesmo me 
 frustei muito tentando conversar com uma dessas /desabafo.

 Fiquei curioso.  Como você descreve um ‘analista empurra-rato’, e
 aliás de onde vem eßa expreßão?

Do primeiro projeto citado, onde as pessoas que estão fazendo a análise se 
limitam ao que o erwin ou o jude podem oferecer, tanto que em um deles (creio 
que o erwin) que é todo por click, me pediram ajuda por não conseguirem 
remover um elemento criado, ai descobri que era com DEL (ou Ctrl+X), a 
expressão é minha mesmo, mas como um desabafo mesmo.


 Aliás, meninas de plantão, vamos melhorar a representação na
 Informática… ou é verdade que vocês são tão inteligentes que preferem
 áreas com menos pepinos e (ou) maiores recompensas?

O fato de ter sido *uma* analista foi pura coincidência, *os* analistas dão o 
mesmo trabalho.


  Já sonhei com algo no Postgresql em que pudessemos escrever
  relacional e usar alguma parte do SGSB (sem passar por SQL) para
  executar, mas creio que isso seja sonha demais.

 Por quê?

 Difícil sim, nem faço idéia como se poderia começar.

 Na verdade o Postgres original suportava QUEL, uma outra linguagem.
 E o ‘primo’ Ingres ainda suporta QUEL.  Então imagino que seja viável,
 seja criando mais uma interface para o PostgreSQL, seja bifurcando o
 projeto.

Me lembrei disso, e o ingres foi liberado com uma licença livre, não lembro 
qual e se continua ou foi apenas uma versão, cheguei a baixa-lo, mas não fui 
adiante. Se for com o PostgreSQL, seria ideal mais uma interface, era o que 
tinha em mente.


  Eu entendi, e posso até *ajudar*, mas como disse, não tenho estrutura
  para iniciar, e no momento, nem tomar frente de muita coisa.

 Nem eu… estou só jogando a idéia para a lista (e os amigos), para
 ver o que acham.  E aceito idéias sobre como viabilizar.

  ps.: Não entendi as referências: Dumbo e Jumbo.

 Qual o noßo mascote?

Desculpe a vergonha que passei, parece que o dumbo aqui sou eu :) .


  ps2.: Alguém conhece alguma ferramenta boa para exibir os .dot
  gerados pelo Autodoc? Só conheço o dotty, mas não funciona

 Graphviz.  Muito bom.  Mas na verdade arquivos dot não se abrem, se
 usam para gerar diagramas.  Eles definem a estrutura, não o diagrama em
 si.

Obrigado, mas poderia me passar alguma referência, sobre como usa-los?

Leandro, tenho recebido alguns caracteres estranhos em suas mensagens, uso o 
kmail com utf8 como primeira opção, se eles retornarem estranhos, me desculpe 
por enquanto.

[]'s

-- 
Johnny Taylor Faria Chaves - LUN 157066
Não combato ou defendo pessoas ou grupos,
Combato ou defendo idéias ou atos.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-06-29 Por tôpico Euler Taveira de Oliveira
Leandro Guimarães Faria Corcete DUTRA wrote:

   Moderadores, outra choradinha… pelo menos o Evolution não consegue
 responder ao remetente, somente à lista.  O ideal seria que os
 cabeçalhos permitissem responder ou ao remetente, ou à lista, ou a
 ambos.
 
Sim, o problema é que a maioria *não* tem a cultura de responder
utilizando *Reply All* para lista de discussão, também porque são poucos
os casos onde o remetente não está cadastrado na lista e para que as
duplicatas sejam evitadas. Mas se todos tiverem de acordo podemos mudar
isso. Comentários?


-- 
  Euler Taveira de Oliveira
  http://www.timbira.com/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-06-29 Por tôpico Leandro Guimarães Faria Corcete DUTRA
Em Sex, 2007-06-29 às 15:04 -0300, Euler Taveira de Oliveira escreveu:
 Sim, o problema é que a maioria *não* tem a cultura de responder
 utilizando *Reply All* para lista de discussão, também porque são poucos
 os casos onde o remetente não está cadastrado na lista e para que as
 duplicatas sejam evitadas. Mas se todos tiverem de acordo podemos mudar
 isso. Comentários?

Só para esclarecer, julgo isso útil porque (1) às vezes queremos
responder só diretamente ao rementente e (2) porque geralmente o
rementente vai receber a resposta direta antes da cópia da lista, assim
agilizando o processo.

Mas concordo que haverá gente confusa, reclamando… mas como é uma lista
técnica, isso *deveria* ser o de menos.


-- 
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


[pgbr-geral] Modelagem de Dados à la Unix

2007-06-28 Por tôpico Leandro Guimarães Faria Corcete DUTRA
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 

Re: [pgbr-geral] Modelagem de Dados à la Unix

2007-06-28 Por tôpico Johnny Taylor Faria Chaves
Em Qui 28 Jun 2007, Leandro Guimarães Faria Corcete DUTRA escreveu:
   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.
O ideal, seria na bancosdedados, mas, como voce disse em outra mensagem, ela 
anda meio parada (ou parada e meia :( ).

   Vocês sabem que andei investigando ferramentas de modelagem, e acabei
 ficando frustrado. 

Acabei não participando das conversas na outra discussão, mas notei que 
estamos numa mesma encruzilhada.

...

   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.  

Também gostaria disso, mas não tenho estrutura para iniciar algo assim.

 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.

Não creio que seja absurdo, mas quem fizesse seria considerado herege, 
pelos analistas empurra rato, desabafohoje mesmo me frustei muito 
tentando conversar com uma dessas /desabafo. 


   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).  

Já sonhei com algo no Postgresql em que pudessemos escrever relacional e 
usar alguma parte do SGSB (sem passar por SQL) para executar, mas creio que 
isso seja sonha demais.

   Deu para entender?

Eu entendi, e posso até *ajudar*, mas como disse, não tenho estrutura para 
iniciar, e no momento, nem tomar frente de muita coisa.

ps.: Não entendi as referências: Dumbo e Jumbo.
ps2.: Alguém conhece alguma ferramenta boa para exibir os .dot gerados pelo 
Autodoc? Só conheço o dotty, mas não funciona :)

-- 
Johnny Taylor Faria Chaves - LUN 157066
Não combato ou defendo pessoas ou grupos,
Combato ou defendo idéias ou atos.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral