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 [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
