It covers the full syllabus of a training module: files and databases, database management systems, conceptual design with entity-relationship models, the relational model, converting one into the other, normalisation, physical design, queries, data editing, a PL/SQL block, transactions, backups, and import and export. It is a textbook, with everything that implies, good and bad.
What I took from it
Normalisation, the only part of this book that does not age and the one almost nobody applies when arguing about a new field. The question that stayed with me is simple: what does that value depend on. If it depends on only part of the key, or on another field that is not the key, it is in the wrong table, and putting it there guarantees that within a year there will be two versions of the same value and nobody will know which one counts. Faced with a request to add a field, that question settles the discussion in two minutes.
Converting the conceptual model into a relational one is the second part that still serves, above all for reading somebody else's ERP schema: understanding why a many-to-many relationship produced that intermediate table that looks like filler and is in fact where the information lives.
And a third, minor but practical: the chapter on backups, export and import is a reminder that a backup nobody has ever restored is not a backup. I always ask, and the uncomfortable answer is common.
What I left out
The PL/SQL block, which ties the book to one vendor and one era, and much of the rest. The years show, and so does the editing: there are typos from the table of contents onwards. It is a handbook for passing a module, not a book you would recommend for pleasure, and it is here because its design chapters are still correct and because not everything useful is recent.