How do I properly design a Z schema for this scenario?

All of the examples I found had only 2 declarations such as name and date OR members and telephone. However, my scenario is this :

I would like to create a Z schema called AppointmentDB. AppointmentDB keeps appointments details such purpose, attendees and schedule

My take (EDITED):

There are 5 declarations and 1 predicate

|--AppointmentDB----------------
|attendees : P Person
|appointments : P APPOINTMENT
|hasAppointment : Person ↔ APPOINTMENT
|schedule : APPOINTMENT → DateTime
|purpose : APPOINTMENT → Report 
|-----------------------------
|attendees ⊆ dom(hasAppointment)
|-----------------------------

As you can see, I'm trying to link the APPOINTMENT to all its other attributes. Is my schema correct or complete or how can I optimize it further? Also, how do I know which relation should I consider from the relation to define inside the predicate part?

Solution

In your specification there is e.g. no link between the purpose and schedule. You define schedule in a way that a person is mapped to an arbitrary number of times and purpose maps a person to an arbitrary number of words. But there is no way to tell at which time the person has an appointment with what purpose.

I suppose you want to have a single appointment have a time and a purpose. My suggestion (there are actual many ways to achieve this) is to introduce a data type for appointments, e.g. with a carrier set:

[APPOINTMENT]

Then you can specify that a person has an arbitrary number of appointments:

|--------------------
| appointments: P APPOINTMENT
| hasAppointment: Person <-> APPOINTMENT
|----
| appointments = ran(hasAppointment)
|--------------------

And for each appointment you can specify its time and purpose:

|--------------------
| schedule: appointments --> DateTime
| purpose: appointments --> Word
|--------------------

So this is by not everything you specified in your schema but I'm not sure how exactly to interpret e.g. object or availability of your specification. But I think the basic approach to make the appointment itself an object will be helpful in most scenarios.

Another approach instead of introducing a type APPOINTMENT would be to define a schema Appointment and use it like a record data type.