i have seen that we can have composite keys where the primary key is made up from combined primary keys of two tables.
Like persons and Books
person_id a
Surrogate keys are intrinsically bad and should be avoided at all costs. They make no sense in the real world. But sometimes they are necessary.
Leaving that aside for now, your example demonstrates exactly why composite keys are needed - more than one person can have a copy of a particular book - and a person can have more than one book - it's a N:M relationship. And representing this in a relational database is simple: you put another table in the middle with the PK of the book and the PK of the person.
id,person_id ,book_id
But (unless you want to cater for the scenario where you need to differentiate 2 copies of the same book owned by the same person, in which case the schema needs several other changes) since the combination of person_id and book_id is already unique, why do you need to another unique identifier which has no relevance to the data you are trying to model.