On Jun 10, 12:19 am, Graham Cooper <grahamcoop...@gmail.com> wrote: > On Jun 9, 11:55 pm, Charlie-Boo <shymath...@gmail.com> wrote: > > > > > > > > > > > For years I have studied computer science and logic which overlaps > > it. One by one I have discovered weaknesses, omissions, mistakes and > > outright fraud. Here are just a few examples: > > > 1. E.F. Codd's Relational Model - SQL: Codd was trying to develop a > > mathematical model of database systems. He pointed out that records > > in database systems are relations in math. That is true and a good - > > the correct - start. But he was never able to model files or general > > file manipulations. He said a flat file is a relation. In a sense it > > is - its functionality relates to just one relation. But files in > > general consist of (a) multiple capabilities (programs), each of which > > is defined by a wff that (b) can reference multiple relations. Codd > > never figured that out or what to do with hierarchies, so he declared > > them illegitimate. So SQL has no hierarchies. It has simple indexes, > > otherwise it would be unbearable. But Codd says that doesn't count as > > data so he lets them in. Actually, indexes are no different from > > files in general and should not be treated any differently. One file > > is an inversion of another. The result is database systems are based > > on SQL, have no hierarchies beyond little indexes (not general ones), > > and are terribly inefficient. The notion that "hierarchies are not > > relational and so cannot be used" is ridiculous. > > Well half right. > > I think of SQL as a low-level 4GL and Prolog as a high level 4GL as > the tuples are recursively nested into hierarchies (and predicates > themselves are interpreted) > > Here is a PROLOG formula > > AXIOM: > p1( p11, p12, ...) > > INFERENCE RULE: > p2( p21, p22, ...) ^ p3( p31, p32, ...) ^ ... ^ pn( pn1, pn2, ...) > -> > p1( p11, p12, .. ) > > ------------------ > > where each term can recursively embed another predicate by adding > arguments. > > AXIOM: > p1( p11, p12( p121, p122, ...) ... ) > > which you CANNOT DO WITH SQL which is based on the field Relational > Algebra. > > ----------------- > > It's not that Heirarchies are not "allowed" it is merely that they are > superfluous and redundant. > > The process of Normalisation of the relations will not work with > embedded sub-tuples. > > e.g. > > TABLE BOOKS > > IBN# | TITLE | AUTHOR | AUTHORS WEBSITE > 23 MAGIC TOM www.tomssite.com > 32 MATHS JANE www.wolfram.com > 83 SPELLS TOM www.tomssite.com > > You might use an XML style to embed details about the AUTHOR in the > BOOKS table. > > IBN# | TITLE | ( AUTHOR , AUTHORS WEBSITE) > 23 MAGIC ( TOM www.tomssite.com ) > 32 MATHS ( JANE www.wolfram.com ) > 83 SPELLS ( TOM www.tomssite.com ) > > ------------------- > > But if the Author changes his website name, then instead of > updating 1 record, you have to update 2 records. > > ( TOM www.tomssite.com ) > ( TOM www.tomssite.com ) > > Now your database is no longer normal, it has a redundancy. > > If you EDIT one record and don't edit the other record as well, > then when you query: > > SELECT AUTHORSWEBSITE FROM BOOKS > WHERE AUTHOR = tom > > RESULT > > www.tomsnewsite.comwww.tomssite.com > > ------------------------- > > There should be an index from > > IBN to BOOK > and > AUTHOR to AUTHORSWEBSITE > > The reason for the indexes is two-fold, to speed up the queries > and enforce referential integrity. > > In fact, phpPROLOG is the first database to do exactly what you said, > use a flat table to represent hierarchies in tuples. > > I use a REF=1 REF=2 REF=3 REF=31 REF=32... > > system for super-fast Prolog processing! > > Herc > -- > > http://phpPROLOG.com > A.I. Software / Database on the Web! > > Powered By SQL > SELECT HEADS.id > FROM QUERY > INNER JOIN HEADS > ON QUERY.ref=HEADS.ref > AND QUERY.term=HEADS.term > > DATABASE QUERY > id ref term ref term > ---------------------- ---------------- > 6 1 test1 > 6 2 aaa > 7 1 test1 <=> 1 test1 > 7 2 bbb <=> 2 bbb > ---------------------- ----------------
That is all fine and dandy, a noble cause and laudable effort. But let us look at the complete picture of Codd's goal of formalizing database (management) systems. We need:
1. A model for databases. 2. A formalization of querying a database. 3. A model of manipulations of a database to process a query. 4. An algorithm to generate possible manipulations that process a given query.
(Do you agree this list is complete and not superfluous?)
How would you do each of these in Prolog?
(1) Codd omits hierarchies. (2) Predicate Calculus does fine - his "tuple variables" et. al. are unnecessary. (3) His Relational Algebra (this you also use) is special cases and incomplete. (4) He wrote a paper once seemingly addressing this. After working through its massive details for a couple of days, I discovered that he was merely saying to take the cartesian cross product of all relations involved and them walk through all of the tuples and apply logic to evaluate each to see if it passes, a totally unworkable algorithm. A few years later he dismissed that algorithm as not a solution.
After axiomatizing program synthesis I realized that (4), the database query processing problem, is a corollary, a special case.of program synthesis. Also note that nobody writes about both much less shows that they are the same problem. Manna/Waldinger and Codd/Date are strangers. Database relations are defined in the same terms as mathematical relations, but they neglect to apply the mathematical solution to their problems in the database context. However, this is understandable to a degree because they never did solve the program synthesis problem itself, as I noted elsewhere above. [I collaborated with Manna/Waldinger on a number of occasions, but in the end Waldinger simply said he was unable to utilize my solution because it was "a difficult paper". He then said he liked his better because more people wrote about it.]