My answers are a bit vague, because I'm not sure what your intent is in this project, whether it's just a hobby or a prelude to adding database expertise to your professional credentials.
I'll note in passing that many database systems, unlike SQLite, do not require NOT NULL on top of PRIMARY KEY. However SQLite documentation says that SQLite does. So you don't need to change things.
There appear to be two different relationships between book and format, and between book, format, and ISBN. I'm not sure what your intent is here, and I'm not a subject matter expert on ISBNs. What purpose is served by BOOK_FORMAT that is not also served by BOOK_FORMAT_ISBN?
You have no foreign keys (REFERENCES constraints) embedded in the primary tables. This is different from every database I ever designed, although, for all I know, it may be appropriate in your case. In general, relationships are expressed with junction tables, as you have done, when the relationships are many to many, or are ternary. If you ever need to express a many-to-one relationship, you will find it more convenient to embed it in an entity table than to create a separate table for the relationship.
Trial and error is an awfully expensive way to learn databases, unless you don't value your own time. While you don't need to master an entire textbook on theory before diving in, I recommend that you at least begin to learn the theory behind databases in parallel with your project. Databases are not complicated compared to other aspects of computing, but they are a little on the abstract side. My experience with programmers cutting over to databases is that they tend to think well in terms of concrete details, but somewhat poorly in terms of overall abstract structure. Your experience may be different.
Object oriented modeling is one of the more powerful abstract tools that many programmers acquire. Unfortunately, data modeling and object modeling often lead to quite different thought patterns and many programmers find data modeling difficult to master precisely because object modeling has been so useful to them.
Another way to help your learning is to look at the way other people have solved your same problem. There is an organization called Database Answers that offers a library of hundreds of sample database models. It's available here. If you navigate to "Libraries" I'm sure you'll find some examples that overlap your project. Take them with a grain of salt, however. One person's best practices do not always suit another person's project goals.
Finally, I'm going to point you to an answer I gave about 7 years ago to a question that may or may not be relevant to your quest. It's what every developer should know about databases.