UML is a visual language used primarily to document and communicate design decisions made using object orientation. You don’t need know UML to build your software in this paradigm, especially if you will work alone. Still, the day you have a little time would be worth studying the Use Case and Class diagrams. The former is useful in communicating with the client and in understanding his problem and his expectations. The second is useful precisely in the scope of your question: understand what to produce in terms of classes, attributes and methods.
Well, in Object Orientation and computational resolution of a problem occurs through the exchange of messages between instantiated objects from classes. Each class has well-defined responsibilities (it ago something) and to assist in this maintains internal states through attributes (she has something). Consider, for example in your problem domain, a class quarto and a class cliente. The class quarto has important attributes related to the real-world entity, such as room number, occupancy status (occupied, vacant), cleanliness status (needs cleaning, clean room), indication about having TV or not, number of beds, etc. In addition, It has methods that allow you to perform actions involving the rooms, such as booking (for a particular cliente), block (prevent reservations in case of maintenance), request cleaning (involving another potential class camareira), etc..
The choice of classes, their attributes and the relationship between them (this dependence on quarto can be reserved for a cliente, for example) depends heavily on your problem area. That is, it depends on what needs to be implemented to solve your customer’s problem (in this case, the hotel). Whether or not you use a UML Class Diagram, you will first need to list the entities, concrete or abstract, that need to be represented in order for your system to be able to offer the solution that your customer (the hotel) expects. For example, cliente, quarto, camareira, estadia, reserva, mensagem left at reception, item consumível refrigerator, etc. Then, you will need to list the attributes of each of these classes, that is, what data they will need to store and manipulate in their respective scopes. For example, cliente has nome, CPF, etc.; estadia has data de início, data de fim, quarto, cliente, etc. Finally you will need to define the methods that each class should provide for public use (which can be executed/called/invoked by other classes) and privately (which is only for own and internal use). These methods are reralmente "functions" that perform something important within the scope of the class. For example, the quarto may have the method reservar, which does exactly what it says: reserve the room for use by a cliente; to camareira may have the method alocar, that records the quarto and the period of the day on which the official(a) (a) needs to clean up.
One difficulty you will certainly have is knowing how to differentiate what is important enough to be represented as a class or it should only be represented as an attribute of another class. For example, if in your problem domain the TV needs to be manipulated by your system (because your system should control the channels released, since it depends on the package the customer will pay for), you will certainly need to have a class TV that has attributes to the different channels and methods to release or block them (in addition it is clear to have to implement the interface with the real TV even directly in the room!). On the other hand, if your system does not have this type of interface and TV is merely something that may or may not exist in the room, just take it as an attribute of the class quarto (a boolean attribute indicating whether or not it has a TV, or a numeric attribute identifying the type of TV - 0 for single TV, 1 for cable TV with few channels, 2 for cable TV with many channels, etc).
Finally, note that the Class Diagram (is represented or not documented in UML) is not exactly the same thing as the Entity-Relationship Model (the tables in your database). Naturally, your system will need to persist (load into tables) the data it handles, and the choice of how this will be done depends on what needs to be represented in the system (in the classes). But they are distinct representations. Objects instantiated from classes have references to each other (the client is in a room, which are both referenced by the reservation, for example), while in their database the tables use codes (in primary and foreign keys) to make this reference indirectly. Such codes may or may not be interesting for human display. For example, the hotel attendant will probably need to reference the customer code and the room number, but the reservation may or may not have a code. Perhaps the hotel is used to "thinking" about the reservation in terms of the customer and the room only. This does not mean that your system does not need to use an internal identifier to reference the reservations (in other words, the "reserve" table in the database must have a primary key).
So, I would suggest first working on the domain model (in the classes, attributes and methods) to understand well what your system needs to represent and manipulate, only then to think about how these entities need to be persisted/stored.
I also suggest that you read a lot about Object Orientation. Right here in SOPT there is the tag orientation-to-objects that you have a lot of useful things. And, eventually, if you have questions, post new questions in a timely manner (for example: I thought of doing class X with attribute Y, but I don’t know how to represent it, some hint?).
Excellent response. Over time we understand the true value of software engineering.
– Weslley Tavares