February 5, 2009 at 9:48 am
I looked at the docs at Rel's page and checked the D section in Thethirdmanifesto home page and I see a lot of differences.
http://www.thethirdmanifesto.com
Kind regards,
Gift Peddie
February 5, 2009 at 10:07 am
Gift Peddie (2/5/2009)
I looked at the docs at Rel's page and checked the D section in Thethirdmanifesto home page and I see a lot of differences.
I guess you are talking about Tutorial D rather than D. Rel is not a complete implementation of Tutorial D as is made clear in the documentation. Tutorial D is only one possible implementation of a relational system however. Neither Date or Darwen or anyone else has claimed that a RDBMS has to be Tutorial D or even have every Tutorial D feature. In fact D & D's algebraic language called "A" has only TWO relational operators (plus assignment and comparison) and it's certainly relational - its data structures are relvars and it is provably relationally complete.
February 5, 2009 at 12:43 pm
Yes Chris Date also covered that in the last book Greater Than and Less Than are not relevant to the relational model because all Sets are equal. Here is my take I like Jim Gray because I can take one look at his transactions implemented by Microsoft in a developer's code and separate it by implementation layers and platforms resolve what I can and send the developer to product owners within Microsoft. It shows transactions can be propagated from one development model like the object layer to the relational model of the application. I read Chris Date because he is succinct and to the point and helps me use most RDBMS.
All RDBMS varies in degree of the ANSI SQL model because those of us with long memories remember SQL Server 7.0 and Oracle 8i. Both products were quickly replaced and Oracle tries to pretend 8i the object relational product does not exist in it’s .NET data access.
Kind regards,
Gift Peddie
February 5, 2009 at 1:43 pm
Gift Peddie (2/5/2009)
All RDBMS varies in degree of the ANSI SQL model because those of us with long memories remember SQL Server 7.0 and Oracle 8i. Both products were quickly replaced [..]
Umm, if I remember correctly 8i wasn't any more quickly replaced than any other recent version, it was released on 1999, 9i first release was 2 years later and the trend more or less continues - 2 years for new version 1 year for next release (OK 11g second release has broken it). Actually 9i first release was quite buggy and I think 8i was quite long choice for many customers.
Gints Plivna
http://www.gplivna.eu
February 5, 2009 at 1:53 pm
8i was released almost 2000 and 9i was released in 2001 while 10g was 2004/5. And I read from Oracle's Jim Melton it does not scale and a lot of performance issues. If you look at the ODP.NET page you need Oracle 9i client to use 8i.
And I think 9i may be buggy because it was also the first x86 and x64 version of Oracle, I used 9i RC2 as 64bits and I have not used x86 Oracle at place of employment. The first 9i I used comes with both IBM and Oracle C++ compilers at the root we had to remove both for security reasons.
Kind regards,
Gift Peddie
February 5, 2009 at 2:22 pm
Gift Peddie (2/5/2009)
Heh? Access is relationalYou starting in it does not make it relational starting with the data types, aggregate functions and DRI trigger wizard which is actually invalid in all RDBMS. The most important it comes without the third part of the relational model DCL(data control language.)
No actually, I insist, when I developed in Access it was relational, what you did to it is your own business.
Max
February 5, 2009 at 2:31 pm
David Portas (2/5/2009)
GSquared (2/5/2009)
The Berkley DB (which is what Rel is based on) is not relational. It stores data as key-value pairs without relations. Yes, Rel may be "relational", but it's built on a non-relational engine and is essentially just a mapping/communication layer on top of that.An RDBMS is a mapping between a logical representation and physical storage. That was Codd's principle goal in inventing it. It makes no difference what the underlying storage engine is.
Per basic relational theory, a "relation" is a set of tuples. In mathematics, and original relational database definition, tuples are ordered sets of attribute values, though later this was modified to unordered sets of name-value attributes in relational definitions.
Any database, therefor, that complies with storing data in related sets of tuples, is fundamentally relational in nature.
Exactly so. And that's not the model used by any SQL DBMS. SQL uses a table, view and "table expression" model rather than one based on relations. SQL tables, views and table expressions are tuple bags, not sets. They don't always have keys (you can't actually have a key on a view in standard SQL). They don't always use relational operations like projection or join. They may be column-ordered or have duplicate or un-named columns, nulls and so on.
Please tell me the exact mathematical difference between a "tuple bag" and a "relation" or "set". Prove your answer using standard mathematical methodology and terminology, please. If you can't prove it mathematically, you're operating on authority, and therefore what you are claiming falls outside the realms of both logic and math, and definitely outside the realm of science, and is thus either a philosophy or a religion.
So, which is it? Can you prove it mathematically, or is it a philosophy/religion, and not part of anything that should be called a theory?
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
February 5, 2009 at 2:59 pm
Gift Peddie (2/5/2009)
8i was released almost 2000 and 9i was released in 2001 while 10g was 2004/5.
Umm where you got these years?
According to both official history article and official timeline (unfortuntely they haven't months) as well as orafaq version history of 8i 8.1.5 was released on February 1999 and contained Java virtual machine and internet file system so blah blah it was internet ready 🙂
And yes according to both official docs and Orafaq 9i release history 9.0.1 was in June 2001, but 10g was according to official docs on 2003, according to Orafaq 10g version history on January 2004.
So let's calculate Jun 2001 - Feb 1999 = 28 months
Jan 2004 - Jun 2001 = 31 months
Not so big diff 🙂
And I think 9i may be buggy because it was also the first x86 and x64 version of Oracle, I used 9i RC2 as 64bits and I have not used x86 Oracle at place of employment. The first 9i I used comes with both IBM and Oracle C++ compilers at the root we had to remove both for security reasons.
Yeahh probably, as I'm sort of a developer more than DBa, therefore I more remeber 9i first implementation of ANSI SQLs and quite many bugs connected with that. For example initially it was possible to get data out of tables one hasn't privileges on, using some ANSI joins 🙂
Gints Plivna
http://www.gplivna.eu
February 5, 2009 at 3:10 pm
My years are RC2 because that is when Oracle is stable for example 10g RC2 and above you only need Oracle MTS to propagate transactions in .NET layers the same way as SQL Server.
And Oracle 8i was a turning point in Jim Melton's career because with 8i he realised Objects in RDBMS without any math as the Object community wanted will fail.
Kind regards,
Gift Peddie
February 5, 2009 at 3:22 pm
Please tell me the exact mathematical difference between a "tuple bag" and a "relation" or "set". Prove your answer using standard mathematical methodology and terminology, please.
Start here:
http://www-users.cs.york.ac.uk/~susan/cyc/b/bag.htm
Now let R be some relation {S}.
In the relational model:
R X R = R
R JOIN R = R
R PROJECT {S} = R
This is in fact the definition of a relation: the subset of a cartestian cross product.
http://mathworld.wolfram.com/Relation.html
In SQL:
CREATE TABLE R (S INT NOT NULL);
In SQL's tuple bag model none of the following is equivalent to R because duplicate tuples are permitted (NULLs would also be a problem too but let's keep things simple):
SELECT R1.S FROM R R1, R R2;
SELECT R1.S FROM R R1, R R2 WHERE R1.S = R2.S;
SELECT S FROM R R1 NATURAL JOIN R R2;
SELECT DISTINCT * FROM R;
In fact SQL has no single equivalent to the relational join / product operator at all. Related but much harder problems exist with other relational operators. Try working out what relational division means in the SQL model. Is it the inverse of the product?
Multiset math is quite distinct from set math. You will find numerous references in textbooks but here's one Googled at random:
February 5, 2009 at 5:15 pm
The theory is good, but for me the most defining feature of a relational database would be the ability to enforce referential integrity, excellent reading though.
Max
February 6, 2009 at 6:55 am
Again with the SQL being the database. It's not a valid equality statement. Select != set-multiply. If that's all you're saying, that's fine. SQL is not a relational language, it's a data-manipulation and communication language. The database, with tables containing rows and columns, is still potentially relational (depends on a number of factors in how the data is contained, generally refered to as normal forms). Is that what you're trying to assert? If so, I agree with you. If not, then please clarify.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
February 6, 2009 at 2:10 pm
All I am saying is that the SQL data model (the model of tables, views and DML) is not relational, which is what relational experts like Codd, Date, Darwen and others have said ever since SQL was invented. A data model you may know consists of three elements: structure, manipulation and integrity. SQL fails to be equal to the relational model in all three ways, most obviously because of its basis in tuple bags rather than relations (there are plenty of other differences as well).
It's true that a SQL database can be used to mimic the structure and behaviour of a relational database in certain respects. SQL doesn't do that automatically for you though. You need to work at it and it's a pretty hard slog to achieve sometimes. All the more reason therefore to distinguish between a SQL DBMS and a Relational DBMS - so that users are forewarned that it has non-relational "features" which they may choose to avoid.
Unfortunately our profession has too many people who never learnt about the relational model at all. They learnt about SQL and someone told them it was "relational", which explains a lot of the misinformation and rubbish written about databases on the internet.
February 6, 2009 at 2:45 pm
Beyond even that, just trying to find a decent definition for the words "relational database" was a major hassle when I was first starting out as a DBA (9 years ago). Definitions that I could find either required that you already know the whole subject, or were circular.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
February 6, 2009 at 5:11 pm
I, on the other hand, hope that true relational databases never come to pass. The non-relational ones are a hell of a lot more fun. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 121 through 135 (of 250 total)
You must be logged in to reply to this topic. Login to reply