I tend to agree with you.
In his defence if you reading the text I can see what his design aims are, i.e. he's effectively forcing you to always use only one database while not restrict the interface so that its hard to change it in this way later i.e. he's avoiding the singleton
pattern so you don't have to get the only instance of the one and only DVD database and he's done this at both a DBClient and DvdFileAccess level with his use of static and check there is only ever one db file (by path) . If he did use the standard singleton pattern and you wanted more than one dvd (flexibilty as you suggest) he'ed have to change the interfaces to the class and he's not gone the generic route has you have to deal with the issues of two files.
Again I see what your both getting at the actual code he's generated for me is at best odd (particularly the static) though not wrong as such but I do take on board his comment.
For me I would have gone for a pure singleton or a pure generic database rather than trying to do a hybrid, i.e. one that works as a singleton now but whose interfaces were easily adapted to generic use. I suspect I'll write a generic class and use it from a seperate a singleton instead.
If I hadn't read the book and just seen the code with no comments, and had no idea of the level of programmer who had implemented it I would have assumed a design mistake (though actually thats wrong).
It is personal preference though and hopefully the examiners are looking for more clear documentation of the design choice rather than only this design is right.