I have just started a unit on databases at university. I have already completed other programming and systems design units. We are using the following text;
An Introduction to Database Systems
by C.J. Date
8th edition - 2004
I am having a lot of trouble understanding this text . It seems highly theoretical in nature and goes into a lot of fine detail very early. The language used is also very "mathematical" in nature (I realize the maths is important). Very few diagrams are used and real world examples are few and far between. He constantly refers to a DB language known as "Tutorial D" when we are learning SQL (the language of many real world applications). I feel I need to get a grasp on basic DB concepts before delving into highly theoretical discussions that split hairs on definitions etc that more experienced practitioners would understand. In short, I find this book the most difficult to read and understand of any unit I have completed so far. Its like he spends an entire chapter describing the colour blue without ever showing a sample of what it looks like.
Can anyone recommend a Website, blog or textbook that employs A LOT of diagrams of "real world" relations so I can get a handle on primary keys, super keys, candidate keys, foreign keys, relational algerbra and relational calculus? A theoretical explanation is great, but personally without employing a simple real world example I get lost. I have done some research online already and have found explanations of some concepts that make Date's attempted explanations seem like the ravings of a person from another planet. Sorry Mr Date , you are obviously much smarter than I am. However I personally don't consider your book a very good "Introduction to Database Systems". There I go, insulting the king of databases in my first database unit!
Thanks, that's more like it. I would say the problem was me being too dumb to understand (still a possibility of course), but I have already completed 7 units in my comp sci course and done very well in all of them. This book has really been a shock to the system. I thought I was doing OK until now. I have been doing more online research and even Wikipedia leaves Date's explanantions for dead IMHO (even though Wikipedia references him. Maybe that's what I need, a Date -> English interpreter!). Like most things I have found in comp sci, until you can experiment with it in a practical way and make code work it's all just theory. Trouble is we are supposed to be learning SQL and he constantly references "Tutorial D". I am looking for another text right now.
OK. You have confirmed my suspicion that this is a highly theoretical text. Why we are using this text is beyond me. There must be a reason that my lack of knowledge does not allow me to appreciate at this point. If I skip over the Tutorial D stuff I will be skipping over most of the code in the book. Date seems a little contemptuous of SQL, he constantly points out its deviation from his relational Nirvana. Probably a great text for guys and gals in the lab developing new products, but it leaves me wondering why I am reading it. You have confirmed my decision to find another text to complete this unit. Anyway, enough pointless bleating. Back to work. I will learn this stuff by hook or by crook! It is very interesting and the concepts powerful in real world computing. I feel knowledge of database concepts and SQL is essential to my development in the field.
I feel knowledge of database concepts and SQL is essential to my development in the field.
Spot on, on both points!
University courses often teach what the world ought to use, as opposed to what it uses today. This is a pretty fundamental step toward getting to a better world, but it makes things a lot tougher for the university students because they are learning about what should be instead of what currently exists.
Tutorial-D is a great concept, but I don't know of anyone that has implemented it (or even anything very much like it) in a way that compares to what exists in the SQL world today. A few years ago, there was a company working on a beta version of a product that was truly relational, and that had me very excited... Unfortunately, the company went "toes skyward", the project dropped into the dumper, and now it seems like there is little or no chance of anyone making a go of a truly relational database in the next few years.
I have a lot of respect for Chris Date, and even more respect for his mentor Edgar Codd. They are both great theoretical/mathematical thinkers. Spend some time with Date's book, learn to work around his writing style, I think you'll find a lot of great ideas that are of great value.
Here is an example of some relational algebra concepts explained in a manner I can easily understand. A book that explained everything in the Date text in such a manner would be ideal for me. Maybe it is just the way my brain works, a graphical learner??
Here is an example of some relational algebra concepts explained in a manner I can easily understand.
my considered opinion is: meh!!
why do we need relational algebra at all if we're going to work with databases?
all those silly operators and set notations are useless
those diagrams are a step in the right direction (although the artwork is poor) but the accompanying text is pants
and look at this -- the "SELECT operation" is described as
... an unary operation. It means the input of this operation is only one relation and it output is also a relation.
The SELECT operation returns a subset of the tuples from a relation that satisfies a selection condition. The SELECT operation can be viewed as a horizontal filter of the relation. It partitions the input relation into two sets of tuples: those tuples that satisfies the condition are select, those do not satisfy the condition are discarded.
quite clearly talking about the WHERE clause
a bit further down, the "PROJECT operation"
on the other hand, selects some columns of the relation and discards the other column. The PROJECT operation can be viewed as the vertical filter of the relation.
We are asked questions in our unit assignments and asked to provide answers expressed as relational algebra, not SQL. I actually find it much easier to write the SQL statements. The content of the link I provided may not be correct, but the style of concept presentation is what I liked. A simple real world example in the form of relations to demonstrate the concepts.
Well I wholly agree with your university and disagree with r937. You should learn the fundamentals using the algebra, the calculus and other relational languages such as those based on D.
If you try to learn from SQL then you will learn some things that ain't so and you won't learn other things at all. The reason why so many database professionals are ignorant about the relational model is that they learnt only by using SQL. That is why Tutorial D was invented.
As evidence of what I say, take a look at r937's comment that the SELECT "clause" is a projection. By default, SELECT means SELECT ALL, which is NOT a projection. Probably r937 is aware of that but it's an example of how imprecise and full of pitfalls the SQL notation is. SQL is not a relational language and so is not instructive for learning about relational databases.
a projection is undefined unless you specify which attributes to project
Sorry if I wasn't clear before. I was refering to SELECT ALL <column names>, rather than SELECT DISTINCT <column names>. SELECT ALL is the default if ALL or DISTINCT is not specified (see section 7.13 of the 2003 SQL standard doc).
To take your example.
SELECT ALL cityname FROM tbl;
is not a projection because the result is not a relation (unless cityname happens to be unique).
SELECT DISTINCT cityname FROM tbl;
is a projection (in both cases I'm assuming cityname is non-nullable). I'm not sure which part of my statement you thought was preposterous but I hope that clears it up.
Originally Posted by r937
SQL is a most appropriate language to learn if you are interested in working with MySQL, PostgreSQL, DB2, Oracle, SQL Server, etc.
Of course. I agree with you. But those products you listed are not RDBMSs, as I hope you know. What I said was that if you want to learn about the Relational database model then SQL is not the best language to use. That's a long way from just a pedantic distinction. The differences are very significant both in theory and in practice.