Sounds like you've entered terminology hell.
I've never been a fan of database theory, there'll be some stuff that will really suck
I could be explaining this wrong but try to think of the book entity as being defined as the relationship of ISBN, Type, Page_count, Price, and Rating.
Thanks Crome, you've been the most friendly and helpful person here in CF
And you must be right, there cannot be another logical way to explain why the book is a relation, I've been thinking about this, the only way to take book as a relation, is if we think of the defining attributes to be independent "sub-entities"(weak entities) and BOOK as a "super-entity" (Strong entity) associated with these sub-entities. I'm probably wrong, but I just cannot think of another explanation.
Now, what happens if we have another relation
PUBLISHER (Address, Phone, Email).
We now have two relations, this, and
BOOK (ISBN,Type,Page_count,Price,Rating).
Every book must be in full-participation in the relationship (double lines in ER Diagram, hope i could explain) as a BOOK cannot exist without a PUBLISHER.
Hence, BOOK itself is a "relation", and so is PUBLISHER. When I associate a BOOK with a PUBLISHER using a Foreign-key, am i establishing a
relation among two relations??
I sure have entered terminology hell.
The next chapter is called "Relational Algebra and Calculus".
This too, is a theoretical chapter, but i think it'll be easier to learn, because the things they talk about, are mathematically explained.
And after that, is the chapter on SQL. I just can't wait to get past these two chapters and start the SQL chapter. SQL is cool. But having to understand a hundred theoretical definitions/ terminologies, is not so cool.
Thanks for replying bro