Vague requirements
Your requirements are too vague. Add more detail. Talk about how each entity relates to another in very precise terms.
Address
The address should be assigned to the office. If the office can have only one address, then address should likely be part of the office table.
The hierarchy of country-state-city makes no sense to me. Explain exactly how your requirements demand that structure. Reporting on such values is done by queries, with sorting and grouping, not building out separate tables. Generally, a related table with only a single semantic column should not be a separate table.
You talked about assigning people to offices but your design makes no such association.
Data-Validation
Some of your concerns seem to be related to validating the data-entry of the address. Usually the app is the front-line of defense for that kind of data-validation, with checks on the database side playing a secondary role.
Either way (app or db), your attempts shown here are meager, and insufficient to ensure valid data. If you are going to do data-validation on the address, do it seriously: Rather than hack your own checks, leverage a postal address verification system driven by postal-code. Either use a remote service or provide your own locally with complete dataset of known addresses and an existing library for look-up and comparing of address info. Your business-problem data should not be directly linked to such tables, but rather your app or database trigger should call out to the remote or local address-verification service.
Naming issues
Change People
to singular Person
.
Fix spelling of Adress
to Address
.
Use all lowercase in the names for maximum portability and avoid problems.
Fix Name
appearing twice on the address table.