OK, so some first things first
Assuming a property is a building, like a high rise, and a unit is one or more residential units within the building, I probably would have made it so a Unit has a PropertyId (because realistically a unit can only be inside one building) and a UnitId, and I'd have UnitId be unique across all units everywhere - I wouldn't use the door number, such that two different units in two different buildings could have ID 100 because the door number is 100 on both units.
I would not have used property name as a key in other tables - names repeat; there is sure to be more than one building in the world called Beach Villas so you're engineering a collision in there that the poor user will ahve to work around by calling the second property they take on something else, such as repeating the city name into the property name; if I was making something that was relating to the property, such as the street address of the building, then an address record would have a property Id, or perhaps a property would have an address ID - we flip relationships around depending on how it suits us - can a property have multiple addresses? Probably not. Can an address have multiple properties? Maybe - so maybe the Property should have an address ID. The main thing is it's usually quite helpful to have a unique number for a record - it's one column that we can then establish relationships with
On relationships; the tenant and the unit clearly have a relationship when a tenant is leasing a unit, and we might want to keep ahold of that history too, even when the lease is over. One unit has many tenants according to your diagram, and yes, that might be true in the real world, for a house share.. But can one person ever rent two units? That also happens in the real world. Do you make another Tenant record for the same person, so you now have two John Does to keep up to date, that actually refer to the same person? What if one ends up with a good credit risk and the otehr a bad?
If you're having a record for John Doe, a particular human then he should probably have only one record. This would then mean he has e.g. TenantId 123. If youre having a record for apartment 104 (unit id 232323) Beach Villas (property Id 45) then on the question of how John can have multiple units and how a unit can have multiple tenants, you can actually have a third table, TenantUnit that tracks the two IDs as a pair, and then maybe also things like the length of the lease.. So you can record that tenant 123 (john) in unit 232323 from date to date - you only have one tenant record, one unit record, and this other table TenantUnit has multiple records in it that track every lease John has for all the units, and also tracks every tenant apartment 104 has/did have. The TenantId,UnitId in the TenantUnit table is unique, unless one person can lease one unit multiple times (move out and then back in later?) so you then start thinking whether to make the date part of the key, or maybe there is a new tenancy agreement record that is part of the key
Maybe also TenantUnit is the thing that has the reservation - everyone who takes a unit pays a reservation, we track that historically etc..
Think about that relationship thing with single numeric IDs though; you're making property name and unit number a key of Unit, which is understandable, but hard work, because in future whenever you want to relate something to a Unit, you now have to put 2 bits of info in the related table.
