Let'sd prefix with "I am not a database expert, but..."
Try to avoid duplication of data, until duplication of data is speed-critical.
Try to store each conceptual "thing" in a table row of its own, using many-to-many tie-tables when there's assorted interlinking between related "things" (typical example where I did the DB design myself and am not entirely displeased with the result; one table for books that hold "id", "title", "isbn", "classification" [this is for my own sheer enjoyment], "publisher" [an ID reference to a publisher table]; one for authors that hold "non-sur name(s)", "surname" and assorted bio data when known and a book-author tie table that holds tuples of book-id and author-id).
Having loked at the image, it' snot too far off what I've mostly seen. In general, database sketches tend to describe teh tables and their direct inter-linking.
no subject
Try to avoid duplication of data, until duplication of data is speed-critical.
Try to store each conceptual "thing" in a table row of its own, using many-to-many tie-tables when there's assorted interlinking between related "things" (typical example where I did the DB design myself and am not entirely displeased with the result; one table for books that hold "id", "title", "isbn", "classification" [this is for my own sheer enjoyment], "publisher" [an ID reference to a publisher table]; one for authors that hold "non-sur name(s)", "surname" and assorted bio data when known and a book-author tie table that holds tuples of book-id and author-id).
Having loked at the image, it' snot too far off what I've mostly seen. In general, database sketches tend to describe teh tables and their direct inter-linking.