Re: [pgbr-geral] Bom site sobre bancos de dados
2008/7/13 Euler Taveira de Oliveira [EMAIL PROTECTED]: Leandro, já olhastes o livro citado em [1]? [1] http://www.inf.ufrgs.br/~heuser/livroProjBD/ Não, mas tua recomendação já conta pontos! :-) Estou meio sem tempo de passar numa livraria, e meus gastos com livros este ano já passaram do razoável — farias o obséquio de levar um exemplar ao PgConBR 2008 para darmos uma sapeada? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 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] Bom site sobre bancos de dados
2008/7/12 Ribamar Sousa [EMAIL PROTECTED]: Aqui faço uma pergunta: não são fases da modelagem, relação (fase conceitual) e tabela (fase de implementação)? Se falas de implementação em SQL, sim. Mas aí já não é relacional, percebes? SQL não é relacional: nunca foi de fato e já há muitos anos abandonou a pretensão de ser. O problema básico aí foi justamente misturar o que chamastes de fases de modelagem, e como o Euler lembrou os níveis conceitual e físico — onde o físico não é relacional, mas SQL. Um livro que não recomendo é o de C.J.Date (Introdução a Sistemas de Bancos de Dados, 8a. edição, 2004), pois não concordamos com várias de suas afirmações e enfoque. Por exemplo, nessa edição, na página 366, ele afirma que o melhor modo de ver os 'relacionamentos' é simplesmente considerá-los um tipo especial de entidade. ... qualquer abordagem que insista em fazer tal distinção [entre entidades e relacionamentos] tem um grave defeito, porque... o mesmo objeto pode, de forma bastante legítima, ser visto como uma entidade por alguns usuários e como um relacionamento por outros Pois é, e o Date está completamente certo aí. Esse é um fato, e uma das muita belezas do Princípio da Informação: tudo é representado por relações, atributos, seus valores e restrições de integridade. ... Infelizmente, UML e outros modelos de análise OO aparentemente não foram desenvolvidos por pessoas que tivessem boa experiência com o MER e o conceito de modelagem conceitual de dados. Concordo que UML e BDOOs de maneira geral são problemáticos — mas MER também é, porque reducionista. E necessariamente reducionista, uma vez que é impossível descrever todo um modelo de dados completo em forma de diagramas. Não tenho nada contra DERs, desde que não passem disso: representação em forma de diagrama de um bom modelo de dados. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 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] Bom site sobre bancos de dados
2008/7/13 Euler Taveira de Oliveira [EMAIL PROTECTED]: Leandro, já olhastes o livro citado em [1]? [1] http://www.inf.ufrgs.br/~heuser/livroProjBD/ Aha, achei as outras páginas do sítio... Euler, você não acha complicado propor DERs como MER, e a origem do modelo de dados conceitual? Representação ER tudo bem, mas não o modelo de dados em si. Lembra daquela minha idéia maluca, a Administração de Dados à la Unix? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 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] Bom site sobre bancos de dados
2008/7/13 Leandro DUTRA [EMAIL PROTECTED]: Se falas de implementação em SQL, sim. Mas aí já não é relacional, percebes? SQL não é relacional: nunca foi de fato e já há muitos anos abandonou a pretensão de ser. O problema básico aí foi justamente misturar o que chamastes de fases de modelagem, e como o Euler lembrou os níveis conceitual e físico — onde o físico não é relacional, mas SQL. Quer dizer que temos uma teoria dos bancos de dados relacionais, fundamentada na teoria dos conjuntos. Mas quando vamos colocar isso na prática temos que adaptar para o que existe e que foi adotado como padrão, que é o SQL, que não faz um bom casamento com a parte teórica, é mais ou menos isso? Um livro que não recomendo é o de C.J.Date (Introdução a Sistemas de Bancos de Dados, 8a. edição, 2004), pois não concordamos com várias de suas afirmações e enfoque. Por exemplo, nessa edição, na página 366, ele afirma que o melhor modo de ver os 'relacionamentos' é simplesmente considerá-los um tipo especial de entidade. ... qualquer abordagem que insista em fazer tal distinção [entre entidades e relacionamentos] tem um grave defeito, porque... o mesmo objeto pode, de forma bastante legítima, ser visto como uma entidade por alguns usuários e como um relacionamento por outros Pois é, e o Date está completamente certo aí. Esse é um fato, e uma das muita belezas do Princípio da Informação: tudo é representado por relações, atributos, seus valores e restrições de integridade. Pelo visto o SQL com seus comandos, PK, FK e References não deixa nem vislumbrar isso. Você poderia detalhar um pouco sobre isso, ou isso somente é algo teórico e que se demonstra com fórmulas e gráficos matemáticos? -- Ribamar FS - [EMAIL PROTECTED] http://ribafs.net ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelando um Controle de Estoque
Voc pode deixar a coluna aceitando nulo ! -- Adriano Sanches Tonetto astoneto (at) gmail (dot) com Antes de imprimir, lembre-se da sua responsabilidade como planeta ! [EMAIL PROTECTED] escreveu: Outro problema para o CNPJ ser a chave natural. E se quisermos ter cliente cadastrado sem CNPJ ou CPF, ou seja, podero ser futuros clientes, com cadastro incompleto, esto cadastrados para mailing, mala-direta ou qualquer outra atividade de marketing. No meu caso eu procuro sempre generalizar as coisas. Alecindro Quoting Ribamar Sousa [EMAIL PROTECTED]: 2008/7/11 Leandro DUTRA [EMAIL PROTECTED]: 2008/7/11 Ribamar Sousa [EMAIL PROTECTED]: Mesmo sem ser o Leandro vou arriscar um palpite: em separando bem as coisas, fsica, jurdica, pblica e privada, acredito que se "deva" usar nossos CPF e CNPJ. Desde que no entrem nem estrangeiros (no tm CNP[FJ]), nem crianas nem mulheres casadas sem vida econmica (no tm CNPF), concordo. Acredito que se tem que chegar a um acordo sobre as restries de abrangncia, pois se no restringirmos a abrangncia a coisa ficar muito difcil de implementar, correto? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED][EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 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 -- Ribamar FS - [EMAIL PROTECTED] http://ribafs.net ___ 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] Modelando um Controle de Estoque
2008/7/13 Adriano Sanches Tonetto [EMAIL PROTECTED]: Você pode deixar a coluna aceitando nulo ! Tens razão. Atualizei o script e o diagrama, colocando cnpj como um campo comun mas deixei como not null. Realmente, deve ser um campo secundário e aceitando null para quando não se tiver cnpj, ou cpf. -- Adriano Sanches Tonetto astoneto (at) gmail (dot) com Antes de imprimir, lembre-se da sua responsabilidade como planeta ! [EMAIL PROTECTED] escreveu: Outro problema para o CNPJ ser a chave natural. E se quisermos ter cliente cadastrado sem CNPJ ou CPF, ou seja, poderão ser futuros clientes, com cadastro incompleto, estão cadastrados para mailing, mala-direta ou qualquer outra atividade de marketing. No meu caso eu procuro sempre generalizar as coisas. Alecindro Quoting Ribamar Sousa [EMAIL PROTECTED] [EMAIL PROTECTED]: 2008/7/11 Leandro DUTRA [EMAIL PROTECTED] [EMAIL PROTECTED]: 2008/7/11 Ribamar Sousa [EMAIL PROTECTED] [EMAIL PROTECTED]: Mesmo sem ser o Leandro vou arriscar um palpite: em separando bem as coisas, física, jurídica, pública e privada, acredito que se deva usar nossos CPF e CNPJ. Desde que não entrem nem estrangeiros (não têm CNP[FJ]), nem crianças nem mulheres casadas sem vida econômica (não têm CNPF), concordo. Acredito que se tem que chegar a um acordo sobre as restrições de abrangência, pois se não restringirmos a abrangência a coisa ficará muito difícil de implementar, correto? --skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED][EMAIL PROTECTED] [EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing [EMAIL PROTECTED]://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Ribamar FS - [EMAIL PROTECTED]://ribafs.net ___ pgbr-geral mailing [EMAIL PROTECTED]://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 -- Ribamar FS - [EMAIL PROTECTED] http://ribafs.net ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelando um Controle de Estoque
2008/7/11 Leandro DUTRA [EMAIL PROTECTED]: Ainda não vi um uso interessante e generalizado de TYPEs; de qualquer maneira, qualquer TYPE criado fica mais interessante se usado dentro de DOMAINs. Talvez o Leonardo César tenha alguns exemplos interessantes? Temos, sob condição de propriedade intelectual em um cliente :-(. Talvez um tema prum Hacker Talk do PGCon'08 ??? -Leo -- Leonardo Cezar http://pgcon.postgresql.org.br http://www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelando um Controle de Estoque
2008/7/13 Leonardo Cezar [EMAIL PROTECTED]: 2008/7/11 Leandro DUTRA [EMAIL PROTECTED]: Ainda não vi um uso interessante e generalizado de TYPEs; de qualquer maneira, qualquer TYPE criado fica mais interessante se usado dentro de DOMAINs. Talvez um tema prum Hacker Talk do PGCon'08 ??? Boa! -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 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] Modelando um Controle de Estoque
2008/7/13 Adriano Sanches Tonetto [EMAIL PROTECTED]: Você pode deixar a coluna aceitando nulo ! Em princípio, NULLs indicam falta de normalização. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 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] Bom site sobre bancos de dados
2008/7/13 Ribamar Sousa [EMAIL PROTECTED]: Quer dizer que temos uma teoria dos bancos de dados relacionais, fundamentada na teoria dos conjuntos. E na lógica dos predicados. Mas quando vamos colocar isso na prática temos que adaptar para o que existe e que foi adotado como padrão, que é o SQL, que não faz um bom casamento com a parte teórica, é mais ou menos isso? Exatamente! Há controvérsias, mas o básico é isso. Pois é, e o Date está completamente certo aí. Esse é um fato, e uma das muita belezas do Princípio da Informação: tudo é representado por relações, atributos, seus valores e restrições de integridade. Pelo visto o SQL com seus comandos, PK, FK e References não deixa nem vislumbrar isso. Até deixa. Só não realiza todo o potencial, além de ser desnecessariamente complexo e prejudicar até em algumas questões de desempenho; mas o fato é que, sem o modelo relacional, o que teríamos seria ainda pior que o SQL — muito pior. Você poderia detalhar um pouco sobre isso, ou isso somente é algo teórico e que se demonstra com fórmulas e gráficos matemáticos? Olha, estou sem ter como correr atrás de muitos exemplos, mas é bastante simples. Pense que todas as regras de negócio deveriam ser implementadas como restrições de integridade declaradas. Há muitos tipos de restrições de integridade: declaração de tipos, chaves candidatas (primárias ou alternativas), integridade referencial (chaves estrangeiras), regras de transição (como a que diz que um salário não pode diminuir, por exemplo). Existe um sistema que implementa tudo. É um sistema livre, mas tem alguns defeitos: por enquanto roda apenas em MS .Net, e não foi portado para PostgreSQL: o Alphora Dataphor http://dataphor.org./. Interessantemente, você modela os dados e ele já deriva disso interfaces gráficas, restando ao programador aperfeiçoá-las. Há também alguns sistemas com implementações parciais, listados em http://thethirdmanifesto.com/ e http://dmoz.org./Computers/Software/Databases/Relational/Implementations -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 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] Bom site sobre bancos de dados
Leandro DUTRA escreveu: 2008/7/13 Euler Taveira de Oliveira [EMAIL PROTECTED]: Leandro, já olhastes o livro citado em [1]? [1] http://www.inf.ufrgs.br/~heuser/livroProjBD/ Aha, achei as outras páginas do sítio... Euler, você não acha complicado propor DERs como MER, e a origem do modelo de dados conceitual? Representação ER tudo bem, mas não o modelo de dados em si. [Folheando o livro] Onde? Na introdução do capítulo 2 eu vejo: A técnica de modelagem de dados mais difundida e utilizada é a abordagem entidade-relacionamento (ER). Nesta técnica, o modelo de dados é representado através de um modelo entidade-relacionamento (modelo ER). Usualmente, um modelo ER é representado graficamente, através de um diagrama entidade-relacionamento (DER). Lembra daquela minha idéia maluca, a Administração de Dados à la Unix? Não. Qual? -- 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] Modelando um Controle de Estoque
2008/7/13 Leandro DUTRA [EMAIL PROTECTED]: 2008/7/13 Adriano Sanches Tonetto [EMAIL PROTECTED]: Você pode deixar a coluna aceitando nulo ! Em princípio, NULLs indicam falta de normalização. Parece que a própria lógica mostra a coerência da teoria, desde que estou adicionando um campo que não tem importância. Neste caso temos que criar uma outra tabela e relacionar, correto? Vou ver com calma isso para tentar colocar no script. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED][EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 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 -- Ribamar FS - [EMAIL PROTECTED] http://ribafs.net ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelando um Controle de Estoque
2008/7/13 Ribamar Sousa [EMAIL PROTECTED]:
Parece que a própria lógica mostra a coerência da teoria
Bingo!
Teoria *é* lógica!
desde que estou
adicionando um campo que não tem importância.
Exato. Ou seja, denota que na verdade fala-se de duas entidades...
Neste caso temos que criar
uma outra tabela e relacionar, correto?
Exato, uma relação ('tabela') para cada entidade.
Vou ver com calma isso para tentar colocar no script.
Legal.
Isso dito, em SQL pode ser que a normalização total fique
excessivamente complexa, por causa de limitações arbitrárias nas
relações derivadas (visões, VIEWs) atualizáveis (nível conceitual) e
da falta de independência de dados (nível físico — difícil garantir
desempenho em situações extremas. Aliás o Date está nos devendo o tal
modelo transrelacional). Mas seria a única maneira de fazer um modelo
verdadeiramente genérico.
--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 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] Bom site sobre bancos de dados
2008/7/13 Leandro DUTRA [EMAIL PROTECTED]: Você poderia detalhar um pouco sobre isso, ou isso somente é algo teórico e que se demonstra com fórmulas e gráficos matemáticos? Olha, estou sem ter como correr atrás de muitos exemplos, mas é bastante simples. Pense que todas as regras de negócio deveriam ser implementadas como restrições de integridade declaradas. Há muitos tipos de restrições de integridade: declaração de tipos, chaves candidatas (primárias ou alternativas), integridade referencial (chaves estrangeiras), regras de transição (como a que diz que um salário não pode diminuir, por exemplo). Existe um sistema que implementa tudo. É um sistema livre, mas tem alguns defeitos: por enquanto roda apenas em MS .Net, e não foi portado para PostgreSQL: o Alphora Dataphor http://dataphor.org./. Interessantemente, você modela os dados e ele já deriva disso interfaces gráficas, restando ao programador aperfeiçoá-las. Há também alguns sistemas com implementações parciais, listados em http://thethirdmanifesto.com/ e http://dmoz.org./Computers/Software/Databases/Relational/Implementations A idéia é criar banco e aplicação somente em se elaborar um projeto, ou seja, o modelo do banco? Muito grato. Vou mexer um pouco. P.S.: curiosamente os links com .org trazem um ponto a mais, impedindo a abertura, mas com a ajuda do Google encontrei ambos. -- Ribamar FS - [EMAIL PROTECTED] http://ribafs.net ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelando um Controle de Estoque
2008/7/13 Leandro DUTRA [EMAIL PROTECTED]: 2008/7/13 Ribamar Sousa [EMAIL PROTECTED]: Isso dito, em SQL pode ser que a normalização total fique excessivamente complexa, por causa de limitações arbitrárias nas relações derivadas (visões, VIEWs) atualizáveis (nível conceitual) e da falta de independência de dados (nível físico — difícil garantir desempenho em situações extremas. Aliás o Date está nos devendo o tal modelo transrelacional). Mas seria a única maneira de fazer um modelo verdadeiramente genérico. Por que você acha que não se usa uma outra linguagem que melhor atenda ao modelo relacional? Não seria mais indicado uma linguagem mais coerente com o modelo ao invés de um novo modelo para evitar as limitações da linguagem? Acho que não é só o fato de ter virado padrão que dá força ao SQL. Acho que houve e há uma certa acomodação, ou estou enganado? -- Ribamar FS - [EMAIL PROTECTED] http://ribafs.net ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Bom site sobre bancos de dados
2008/7/13 Euler Taveira de Oliveira [EMAIL PROTECTED]: Aha, achei as outras páginas do sítio... Euler, você não acha complicado propor DERs como MER, e a origem do modelo de dados conceitual? Representação ER tudo bem, mas não o modelo de dados em si. [Folheando o livro] Onde? Digo das outras páginas do sítio que você indicou, como http://www.inf.ufrgs.br/~heuser/livroProjBD/apresenta.htm Na introdução do capítulo 2 eu vejo: A técnica de modelagem de dados mais difundida e utilizada é a abordagem entidade-relacionamento (ER). Nesta técnica, o modelo de dados é representado através de um modelo entidade-relacionamento (modelo ER). Usualmente, um modelo ER é representado graficamente, através de um diagrama entidade-relacionamento (DER). Exato. Mas me parece que o MER não é bom o suficiente, sendo inerentemente reducionista por um lado, e mapeando pobremente ao modelo relacional para o outro. Por isso minha proposta de usar somente DER, não MER. O Codd sentiu isso, e pouco antes de ficar doente e fracassar com seu último livro propôs o RM/T. Não creio que alguém o tenha desenvolvido, mas o pouco que vi dele me pareceu mais atraente que o MER, sendo mais são conceitualmente e mapeando melhor ao modelo relacional. Lembra daquela minha idéia maluca, a Administração de Dados à la Unix? Não. Qual? A idéia é separar modelagem de diagramação. Fazer o modelo direto em DDL, usando seja o SQL do PostgreSQL, seja ISO SQL:2006 ou uma D qualquer (Tutorial, D4...); depois usar um AutoDoc ou SQL::Fairy para diagramar. É como eu trabalho, mas por falta de desenvolver minha própria idéia só o posso fazer direto em SQL do PostgreSQL, quando não estou numa empresa multi-SGBD. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 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] Bom site sobre bancos de dados
2008/7/13 Ribamar Sousa [EMAIL PROTECTED]: A idéia é criar banco e aplicação somente em se elaborar um projeto, ou seja, o modelo do banco? Não entendi a pergunta... :-( P.S.: curiosamente os links com .org trazem um ponto a mais, impedindo a abertura, mas com a ajuda do Google encontrei ambos. Deve ser problema de teu navegador, proxy ou coisa que o valha. Esse ponto é a raiz canônica do DNS. Vício de ex-administrador de BIND. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 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] Modelando um Controle de Estoque
2008/7/13 Ribamar Sousa [EMAIL PROTECTED]: Por que você acha que não se usa uma outra linguagem que melhor atenda ao modelo relacional? Sinceramente? Inércia do mercado. Há quem discorde, e ache que SQL é o que dá para fazer com a tecnologia e o desenvolvimento teórico disponíveis hoje. Não seria mais indicado uma linguagem mais coerente com o modelo ao invés de um novo modelo para evitar as limitações da linguagem? Sim! Daí o Terceiro Manifesto, e iniciativas como Dataphor, Rel e vai por aí afora. Acho que não é só o fato de ter virado padrão que dá força ao SQL. Acho que houve e há uma certa acomodação, ou estou enganado? Concordo. Mesmo fugindo da questão do modelo relacional em si, veja que só o PostgreSQL tem uma preocupação forte com conformidade a padrões. O IBM DB2 tem uma preocupação fraca, e outros concorrentes nenhuma... -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 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] Bom site sobre bancos de dados
2008/7/13 Leandro DUTRA [EMAIL PROTECTED]: 2008/7/13 Ribamar Sousa [EMAIL PROTECTED]: A idéia é criar banco e aplicação somente em se elaborar um projeto, ou seja, o modelo do banco? Não entendi a pergunta... :-( Pelo que você falou e pelo que entendi no site do Dataphor, é um framework que segue o modelo relacional e pretende criar o banco e a aplicação simplesmente em se criando um modelo do banco, é isso? -- Ribamar FS - [EMAIL PROTECTED] http://ribafs.net ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Bom site sobre bancos de dados
2008/7/13 Leandro DUTRA [EMAIL PROTECTED]: 2008/7/13 Euler Taveira de Oliveira [EMAIL PROTECTED]: Exato. Mas me parece que o MER não é bom o suficiente, sendo inerentemente reducionista por um lado, e mapeando pobremente ao modelo relacional para o outro. Por isso minha proposta de usar somente DER, não MER. Tentando entender: DER - diagrama. MER - modelo. Ambos do modelo entidades e relacionamentos. Você fala que podemos usar o diagrama mas evitar o modelo entidade relacionamentos, é isso? No caso, usar o modelo relacional com o DER do modelo anterior? Lembra daquela minha idéia maluca, a Administração de Dados à la Unix? Não. Qual? A idéia é separar modelagem de diagramação. Fazer o modelo direto em DDL, usando seja o SQL do PostgreSQL, seja ISO SQL:2006 ou uma D qualquer (Tutorial, D4...); depois usar um AutoDoc ou SQL::Fairy para diagramar. É como eu trabalho, mas por falta de desenvolver minha própria idéia só o posso fazer direto em SQL do PostgreSQL, quando não estou numa empresa multi-SGBD. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED][EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 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 -- Ribamar FS - [EMAIL PROTECTED] http://ribafs.net ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelando um Controle de Estoque
2008/7/13 Leandro DUTRA [EMAIL PROTECTED]: 2008/7/13 Ribamar Sousa [EMAIL PROTECTED]: Por que você acha que não se usa uma outra linguagem que melhor atenda ao modelo relacional? Mesmo fugindo da questão do modelo relacional em si, veja que só o PostgreSQL tem uma preocupação forte com conformidade a padrões. O IBM DB2 tem uma preocupação fraca, e outros concorrentes nenhuma... Mas talvez eu entenda, embora concorde que chegou o momento de mudar o foco, pois já crescemos. Acho que se tento agradar a todos é porque quero conquistar meu espaço, enquanto que os demais conquistaram seu espaço. Como também já conquistamos nosso espaço acho que tá na hora de mudar o foco e trilhar um caminho pessoal. -- Ribamar FS - [EMAIL PROTECTED] http://ribafs.net ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelando um Controle de Estoque
2008/7/13 Ribamar Sousa [EMAIL PROTECTED]: Mas talvez eu entenda, embora concorde que chegou o momento de mudar o foco, pois já crescemos. Acho que se tento agradar a todos é porque quero conquistar meu espaço, enquanto que os demais conquistaram seu espaço. Como também já conquistamos nosso espaço acho que tá na hora de mudar o foco e trilhar um caminho pessoal. Vixe, estou ficando burro... segunda colocação tua que não entendo, e duas mensagens seguidas! -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 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] Bom site sobre bancos de dados
2008/7/13 Ribamar Sousa [EMAIL PROTECTED]: Pelo que você falou e pelo que entendi no site do Dataphor, é um framework que segue o modelo relacional e pretende criar o banco e a aplicação simplesmente em se criando um modelo do banco, é isso? Basicamente. Claro que as telas derivadas são toscas e precisam um tapa para ficarem legais. Já brinquei um pouco com ele, gostei, mas não fui a fundo. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 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] Bom site sobre bancos de dados
2008/7/13 Ribamar Sousa [EMAIL PROTECTED]: Tentando entender: DER - diagrama. MER - modelo. Ambos do modelo entidades e relacionamentos. Exato. Você fala que podemos usar o diagrama mas evitar o modelo entidade relacionamentos, é isso? Pelo menos é a minha abordagem. No caso, usar o modelo relacional com o DER do modelo anterior? Não sei se entendi... terceira vez, hora de ir descansar! ;-) Na verdade, gerar o DER a partir dum modelo em DDL, seja PostgreSQL, ISO SQL:2006 ou D. Talvez RM/T, não sei se este último é viável. De qualquer maneira, hoje não há muito ferramental para isso fora do PostgreSQL. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 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] Bom site sobre bancos de dados
Em 13/07/08, Euler Taveira de Oliveira[EMAIL PROTECTED] escreveu: Ribamar Sousa escreveu: 2008/7/12 Leandro DUTRA [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: 2008/7/12 Ribamar Sousa [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Aí tem algumas informações básicas úteis. Como conheço ainda pouco sobre o assunto não posso avaliar sua crítica, em especial por você não ter citado nenhum dos erros. Não vou ler para fazer uma crítica detalhada, até por estar mal traduzido — mas, no modelo relacional, usamos relações. Tabelas são apenas uma representação aproximada de relações. Aqui faço uma pergunta: não são fases da modelagem, relação (fase conceitual) e tabela (fase de implementação)? Eu usaria os termos: modelo conceitual e modelo físico. Bem, para que fique claro, pois posso ter feito alguma confusão, vou citar o livro: Não dá para esperar muito de um professor de engenharia de software (sem ofensas). Eu mesmo *não* recomendaria esse livro que tu citou. Se queres aprender os conceitos de modelagem e projeto de uma maneira didática e sólida, eu recomendo o livro do meu orientador [1]. Temos bons pesquisadores brasileiros na área de banco de dados mas poucos se aventuram a escrever sobre um assunto que já está consolidado por mais de duas décadas. Chego ao ponto de não recomendar a leitura de autores brasileiros — gostaria que alguém provasse que estou errado, seria um alívio poder recomendar um brasileiro. Para já me defender, também há Leandro, já olhastes o livro citado em [1]? [1] http://www.inf.ufrgs.br/~heuser/livroProjBD/ Este livro estava esgotado. Você sabe se foi relançado? Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelando um Controle de Estoque
2008/7/13 Leandro DUTRA [EMAIL PROTECTED]: 2008/7/13 Ribamar Sousa [EMAIL PROTECTED]: Mas talvez eu entenda, embora concorde que chegou o momento de mudar o foco, pois já crescemos. Acho que se tento agradar a todos é porque quero conquistar meu espaço, enquanto que os demais conquistaram seu espaço. Como também já conquistamos nosso espaço acho que tá na hora de mudar o foco e trilhar um caminho pessoal. Vixe, estou ficando burro... segunda colocação tua que não entendo, e duas mensagens seguidas! Ok. Entendo que o PostgreSQL adotou usar o padrão, para ser compatível com todos que estão aí. Mas também acho que já conquistamos nosso espaço e já podemos tentar deixar os padrões de lado (pelo menos em boa parte) e trilhar algo mais saudável. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED][EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 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 -- Ribamar FS - [EMAIL PROTECTED] http://ribafs.net ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Bom site sobre bancos de dados
2008/7/13 Leandro DUTRA [EMAIL PROTECTED]: 2008/7/13 Ribamar Sousa [EMAIL PROTECTED]: No caso, usar o modelo relacional com o DER do modelo anterior? Não sei se entendi... terceira vez, hora de ir descansar! ;-) É que no que sei o DER é algo do modelo entidade relacionamento (MER), que é o modelo precursor do nosso modelo relacional. Então, usar o DER mas não usar o MER, e sim o modelo relacional. Na verdade, gerar o DER a partir dum modelo em DDL, seja PostgreSQL, ISO SQL:2006 ou D. Talvez RM/T, Agora sou eu que percebo que estou avançando muito. RM/T, o que é isso? -- Ribamar FS - [EMAIL PROTECTED] http://ribafs.net ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelando um Controle de Estoque
2008/7/13 Ribamar Sousa [EMAIL PROTECTED]: eis que surge um invasor na conversa... Entendo que o PostgreSQL adotou usar o padrão, para ser compatível com todos que estão aí. ... e pra alcançar o padrão ainda tem caminho pra se andar. Mas também acho que já conquistamos nosso espaço e já podemos tentar deixar os padrões de lado (pelo menos em boa parte) e trilhar algo mais saudável. Protocolos (padrões) são saudáveis e devem ser seguidos para evitar a procria de softcidas. Vide post no Soli Deo Gloria: Um brasileiro pelegrino, no nosso planeta, sobre o assunto. -Leo -- Leonardo Cezar http://pgcon.postgresql.org.br http://www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Bom site sobre bancos de dados
2008/7/13 Ribamar Sousa [EMAIL PROTECTED]: 2008/7/13 Leandro DUTRA [EMAIL PROTECTED]: 2008/7/13 Ribamar Sousa [EMAIL PROTECTED]: No caso, usar o modelo relacional com o DER do modelo anterior? Não sei se entendi... terceira vez, hora de ir descansar! ;-) É que no que sei o DER é algo do modelo entidade relacionamento (MER) Certo; mais precisamente, uma representação gráfica. que é o modelo precursor do nosso modelo relacional. Pelo contrário, uns sete anos depois. Então, usar o DER mas não usar o MER, e sim o modelo relacional. Essa é minha concepção, e aliás derivar o DER do relacional. Agora sou eu que percebo que estou avançando muito. RM/T, o que é isso? Relational Model Tasmania, uma alternativa relacional ao MER proposta por Codd naquela ilha. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 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] Modelando um Controle de Estoque
2008/7/13 Ribamar Sousa [EMAIL PROTECTED]: Entendo que o PostgreSQL adotou usar o padrão, para ser compatível com todos que estão aí. Na verdade parcialmente, porque ninguém mais segue o padrão como nós. Mas também acho que já conquistamos nosso espaço e já podemos tentar deixar os padrões de lado (pelo menos em boa parte) e trilhar algo mais saudável. Hm, não é viável. São duas coisas diferentes. Por um lado é bom que haja um SGBD SQL conforme e livre, como alternativa aos proprietários, forçando-os à conformidade e à liberdade, uma vez que não se prevê o abandono do ISO SQL a não ser a longo prazo. Por outro, é bom que se desenvolva uma D ou algo assim, mas é difícil pensar que isso se dê como um desenvolvimento ou migração duma ferramenta ISO SQL. O melhor que consigo imaginar para facilitar essa migração é o caminho do Dataphor: um SGBDR D virtual, usando SGBDs SQL como mecanismo de armazenamento até que se possa desenvolver algo próprio e melhor. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 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] Bom site sobre bancos de dados
Osvaldo Kussama escreveu: Este livro estava esgotado. Você sabe se foi relançado? De acordo com as últimas informações que tive, ainda existiam alguns volumes na UFRGS; mas a idéia é lançar todos os livros da série didática da II-UFRGS por outra editora. Não sei em que pé está esta última. -- 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
[pgbr-geral] Index covering
Pessoal, Andei lendo a documentação http://wiki.postgresql.org/wiki/Introduction_to_VACUUM%2C_ANALYZE%2C_EXPLAIN%2C_and_COUNT e me deparei com esse parágrafo: (...) If you've read my past articles you'll recall that PostgreSQL's MVCC (Multi-Version Concurrency Control) does away with the need for expensive read locks by keeping multiple versions of table rows that have been updated, and not immediately removing deleted rows. This is done by storing 'visibility information' in each row. But for performance reasons, this information is not stored in indexes. This means that every time a row is read from an index, the engine has to also read the actual row in the table to ensure that the row hasn't been deleted. (...) Se eu entendi direito, isso quer dizer que a forma como o Postgres armazena os dados para permitir acesso concorrente torna *muito* limitado o uso de índices (comparado a bancos de dados com index covering). Isso pode comprometer seriamente o desempenho nas consultas a tabelas grandes e com razoável taxa de atualização. Isso explica boa parte dos planos horríveis do Postgres 7, mas não sei até que ponto isso foi melhorado na versão 8. É isso mesmo ?! Há planos de se deixar isso mais eficiente em alguma versão futura? Mozart Hasse ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
