In simple cases, it is possible to read information about entities from your database query result sets and do whatever needs to be done without creating objects. For more complicated cases, it is more convenient and maybe more efficient to create objects to represent the entities. But you don't have to do that. Even in the most complicated cases you could probably avoid creating objects to represent the entities ... though you would pay a number of penalties for doing this.
It is certainly "more object-oriented" to represent the entities as objects. But there is no law that says that your code needs to be maximally OO.
The original question title asked an entirely different question:
Do OOP objects (entities) need to have attributes/properties?
The answer is that they don't have to:
An object can be stateless, consisting only of methods that operate on their arguments and return results.
An object's only state can be its identity1 ... which needs no attributes to represent. (Though if you are going to store an object whose only state is its identity in a database, then you will most likely need an
idfield to represent the object's identity (primary key) in the database table.)
1 - For example, new Object() in Java is creating an object whose only explicit state is its identity. (Implicit state includes the mutex state if the Object is used as a primitive mutex, and the identity hashcode if that is calculated.)
