Results 1 to 15 of 15
  1. #1
    Join Date
    Aug 2008
    Location
    Australia
    Posts
    23

    Question Looking for graphical examples of concepts

    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!
    Last edited by enuenu; 08-18-08 at 01:13.

  2. #2
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    your assessment of that book is quite accurate

    however, you're at university -- university-level database courses are supposed to be hard

    try this for an intro to keys -- http://r937.com/relational.html
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  3. #3
    Join Date
    Aug 2008
    Location
    Australia
    Posts
    23
    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.

  4. #4
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    Quote Originally Posted by enuenu
    ... until you can experiment with it in a practical way and make code work it's all just theory.
    agreed

    skip over that tutorial D stuff -- won't see the light of day outside the lab
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  5. #5
    Join Date
    Aug 2008
    Location
    Australia
    Posts
    23
    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.

  6. #6
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Quote Originally Posted by enuenu
    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.

    -PatP

  7. #7
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    the world cries out for an SQL book written without resort to fifty cent words
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  8. #8
    Join Date
    Aug 2008
    Location
    Australia
    Posts
    23
    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??

  9. #9
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    Quote Originally Posted by enuenu
    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.
    quite clearly talking about the SELECT clause

    confusling, innit
    Last edited by r937; 08-19-08 at 14:00.
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  10. #10
    Join Date
    Aug 2008
    Location
    Australia
    Posts
    23
    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.

  11. #11
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    To paraphrase Rudy, the vernacular of database theory is so obtuse that even professional DBAs do not use it.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  12. #12
    Join Date
    Dec 2007
    Location
    London, UK
    Posts
    741
    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.

    Persevere with Date's book is my advice. Use an RDBMS that implements Tutorial D so that you can try out the syntax for yourself. Some links here:
    http://www.dcs.warwick.ac.uk/~hugh/TTM/Projects.html

  13. #13
    Join Date
    Aug 2008
    Location
    Australia
    Posts
    23
    Thanks. I will hang in there and check the link.

  14. #14
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    Quote Originally Posted by dportas
    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.
    preposterous

    a projection is undefined unless you specify which attributes to project

    similarly, a SELECT clause is undefined unless you specify which columns you want

    perhaps you are confusing SELECT ALL with the dreaded, evil "select star"

    the ALL keyword, if you did not realize, is the opposite of DISTINCT, and refers to returning all rows, without eliminating any dupes that might be the result of the projection

    for example, SELECTing just cityname out of the employees table will result in duplicate rows -- but you can't just say SELECT ALL, you have to say which column you want (cityname)

    to suggest that "SQL is not a relational language and so is not instructive for learning about relational databases" is being pedantic to very unproductive degrees

    SQL is a most appropriate language to learn if you are interested in working with MySQL, PostgreSQL, DB2, Oracle, SQL Server, etc.

    you can stay in your lab forever, for all i care

    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  15. #15
    Join Date
    Dec 2007
    Location
    London, UK
    Posts
    741
    Quote Originally Posted by r937
    preposterous
    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).

    Whereas

    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.


    Quote 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.
    Last edited by dportas; 08-21-08 at 03:10.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •