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

Question

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?

Answer 1

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.