The others have given you lots of work to do so I won't add to that at this stage but I'll try to alleviate some confusion regarding relationships.
Relationships between tables are used to enforce Referential Integrity (RI). The vast majority of tables in any schema will be related to at least one other table. Some central elements might be related to dozens. For example a client will be related to multiple other tables such as diagnosis, medications, appointments, etc. Wheres tables like Days will be related only to Schedule.
The purpose of RI is to ensure that all rows that exist in the database have valid relationships to other tables. For example, it makes no sense to have a row in cMeds that doesn't include a valid ClientID to point the the client and a MedicationID to point to a medication. RI in addition to preventing invalid adds, also prevents deletes that will create orphans. So, if you don't have Cascade Delete specified, you will not be able to delete a diagnosis if there are any records in cDiagonsis. This was just an example. It is almost certainly wrong to specify cascade delete on that relationship because if you deleted the cancer diagnosis, that would celete all the CDiagnosis records for ALL clients which would almost certainly be a disaster. So Cascade Delete is a very powerful setting and should only be used in cases where you want to delete child records. An example of that would be the child tables of a Client. If your application logic allowed clients to be deleted (most would not), then you would want to delete all the lower level dependent data when you delete the client.
When you create a query, you draw join lines between tables and queries. These just tell the query engine how to join the tables. They do not in any way have anything to do with Referential Integrity. All the query engine cares about is that the two columns you join have compatable data types. You could create a query that joins the employees table to the Clients table on the two ID fields. It makes no sense at all but the query builder will allow it because both columns are long integer. You will get a resultset that shows client a with employee joe and client b with employee mary, whatever. It won't provide any valid information but the query engine will do it happily.
And finally, RI always ONLY exists in the BE database. The reason for this is because it is enforced by the Jet or ACE database engine. It is not enforced by Access because Access doesn't even need to be installed on a computer for an application to use Jet or ACE. For example, you can use asp to create a web page and the web page can get and update date in your BE database. You could have an Access FE (application) linked to that same database. It will be up to ACE to control what each FE does with the data in the shared BE. Neither Access nor ASP (the front end applications) have anything to do with RI. They may have application logic that enforces business rules but if the rules are implemented differently