A thought about designing database tables

I think database tables can be designed just by studying the information that will be needed to be retrieved from the database. There may be exceptional cases where this technique will not work.

Example 1: Imaginary small Store Database

Products in store, product detail, sales record, profit.

products(pid, name,quantity, unit: carton, box, individual, package, packet,bottle),total units)

product_detail1(pid,price,discount)

product_detail2(pid,property,value,unit) [property could be weight, power, current, volume, concectration, size, etc.]

sales(sid,date,time,pid,quantity,mp,sp)

profit(sid,profit)

Example 2: A Database for Imaginary Library

List of all the books, book detail, book usage history, book status,  list of users, library cards, card detail, user detail, fines, total fines, late returns, books lost record, books recovered record, books stolen, etc.

library_books(lbid,bid)

books(bid,title,authors_id,ISBN,Edition)

authors(authors_id,name,order)
[one row for each author]

book_detail(bid,publisher,date,price)

book_usage(usage_id,lbid,userid,date,time,action:(taken,returned,late return,lost,damaged,recovered))

book_status(lbid,status:(good,damaged,old,lost,stolen)

users(userid,name)

cards(userid,cardid)

card_detail(cardid, created_date,expiry_date)

user_detail(userid,address1,address2,phone_number,email,total_pending_fines)

fines(usage_id,fine_amount)

{Total fines can be evaluated from user_detail}

{Remaining informations can be retrieved from book_usage table}

Optional tables:
late_return(lbid,userid,date,time,delay)
books_lost(lbid,userid,date,time)
and so on...