0

私が見つけたすべての例には、宣言が 2 つしかありませんでしたsuch as name and date OR members and telephone。ただし、私のシナリオは次のとおりです。

AppointmentDB という Z スキーマを作成したいと考えています。AppointmentDB は、目的、出席者、スケジュールなどの予定の詳細を保持します

私の見解（編集済み）：

5 つの宣言と 1 つの述語があります。

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

ご覧のとおり、APPOINTMENT を他のすべての属性にリンクしようとしています。スキーマは正しいか完全か、またはさらに最適化するにはどうすればよいですか? また、述語部内で定義する関係から、どの関係を考えればよいかを知るにはどうすればよいでしょうか。

4

1 に答える 1

1

あなたの仕様では、例えば と の間にリンクがありませpurposeんschedule。schedule人が任意の回数にマッピングされ、目的が人を任意の数の単語にマッピングするように定義します。しかし、その人がいつ、どのような目的で約束をしているのかを知る方法はありません。

時間と目的を持った単一のアポイントメントが必要だと思います。私の提案 (実際にはこれを実現する方法はたくさんあります) は、予定のデータ型を導入することです。たとえば、キャリア セットを使用します。

[APPOINTMENT]

次に、人に任意の数の予定があることを指定できます。

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

また、予定ごとに時間と目的を指定できます。

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

objectしたがって、これはスキーマで指定したすべてのものではありませんが、たとえば、またはavailability仕様を正確に解釈する方法がわかりません。しかし、予定自体をオブジェクトにする基本的なアプローチは、ほとんどのシナリオで役立つと思います。

型を導入する代わりのもう 1 つのアプローチはAPPOINTMENT、スキーマを定義し、Appointmentそれをレコード データ型のように使用することです。

于 2015-04-20T14:20:41.570 に答える