Thanks for all the replies. I am not learning how to do it -- I want an actual database to manage my books. Obviously, there's no way I am going to be able to run some kind of database system at home. (I'm using a laptop.) I just don't have that much time.
It looks like there are a couple of projects on freshmeat that do book management. You might also want to consider using a spreadsheet for the time being, or at least until you have a better idea of the features that you want implemented. Actually, we've sort of been using the term "database" loosely. It is common in industry to use the term "database" when you really mean "RDBMS", but anything that stores "structured data" is a database, so technically, a spreadsheet would be considered a database and is probably the easiest method for solving your problem.
What do you mean by knowledge base?
A KB is one method for performing "knowledge representation"; You can find quite a bit of material on KBs in the AI literature. There's a Google Tech on Cyc which is probably the most important KB in existence. I found it to be interesting. Perhaps the most significant difference between a KB and DBMS is that a KB is generally based upon logic (propositional, 1st order, 2nd order, etc), whereas a RDBMS is based on relational algebra.
What does that mean in practice? A KB can perform logical deduction. If I've added rules to the database that mammals are a type of animal, dogs are a type of mammal, and "scruffy" is a dog, then the KB can infer that scruffy is both an animal and mammal w/o having to be explicitly be told about the relationship. With a DBMS, you'd have to create tables/columns, insert each of the relationships, then write an explicit query to accomplish the same task. I did a couple of projects with a KB at USC and was always amazed by how little work the KB required compared to a DB (and somewhat ironically, I was working for the "database group" at Boeing during this period of time). I hadn't really thought of it before now, but a KB is probably a good way to prototype a production database.
The other major difference is the language syntax. While SQL is dead simple for the most basic of queries, I constantly find myself googling "SQL incantations". This is probably just a personal taste issue, but I really haven't used another language which required me to spend as much time looking up syntax for such trivial things. A language like Prolog seems much more natural to me.