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.
Hierarchies are not part of SQL and they are necessary to efficiently implement almost every database application. That's why programmers include them in the design of their systems.
Codd and his followers use "file" and "relation" as interchangeable synonyms e.g. referring to "relation (table)" where a file in SQL is called a table. A single relation is a very special case of a file, which in general can be a hierarchy which is not included in his "model". He simply left it out. Why? His understanding, as reflected in his calling a file a relation and saying "hierarchies are not relational", is deficient and we all suffer because of it with slow systems.
> 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 > ---------------------- ----------------