Architecture
From kaliko
The calendar server ist based on octopus. The data is stored in a database. At the moment PostgreSQL is used. By using tarent-database, the DBMS is interchangeable.
Contents |
Database Design
By the database design, the datawareholding in the server is explained. The design is pictured in the following graphic:
Table "event"
The central table "event" holds the basic information of an event like the event's title. The table does not include the event's date.
Table "occurence"
Several socalled occurences can be assigned to an event. These are stored in the table "occurences". An occurence defines one or more dates when the assigned event takes place. A specific date can be set by using the attributes "startdate", "enddate", "starttime" and "endtime". The date and the time are not stored together as a timestamp because this connection between those attributes gets lost in case of revision dates. In case of those dates, the information about the date just marks the first and last occurence of the date but not its exact point of time. Revision dates can be defined by the following attributes:
- frequency: states the interval in which the event takes place (e. g. "each 2 weeks"; the frequency would be 2)
- intervalType: states what the interval that is described by the "frequency" is related to. It may have the following values: once, hour, day, workday, week, month, year (e. g. "each 2 weeks"; the intervalType would be "week")
- type: just occures on the intervalTypes month or year. States if the date refers to a day or a week. It can be "exactly" or "relative" (e. g. "monday, August 10" with the intervalType "month" and the "frequency" 1 means exactly. "each 10th of a month" with relative means "each month on the second monday")
- updown: states if it is counted from the beginning or the end of the intervaltype. By this it is possible to state e.g. "last saturday of a month".
The information about a revision event is just stored in the database and is given to the clients. The server does not handle them further. A client could alternatively create several occurences for one event instead of using the information above. It is necessary that the occurences are stored in a seperate table (and not directly in "event") in spite of the possibility to state revision events because otherwise a construct like e. g. "each week on mondays and fridays" could not be created.
Table "event_resource" and Table "types"
The table "event_resource" is a temporary table by which resources can be assigned to an event. Resources can be persons as well as rooms, cars, video projectors and so on. The types like "person" can be defined in the table types to be able to distinguish the classes of resources. The resources themselves are not stored in the database. A client can add arbitrary resources to an event. A calendar server provides no services to request a list of resources. The client creates the resources on his own or gets them from somewhere else. Each resource needs a GUID for an exact identification.
Table "event_category" and Table "categoryprovider"
Each event can be assigned to categories with the table "event_category". A category can be "dates of Martin Pelzer", "project xy" or "vacation calendar", for example. An event can be assigned to several categories. As well as the resources, the categories are not stored on the server. Each category needs to have a GUID by which the server references it. In contrast to the resources to which the server provides no information at all, the server provides a list of category providers. A category provider is a service from which a client can get a list of categories or can possibly create a new category. The central storage of the links to the category providers on the calendar server is necessary to give the possibility for each user of a client to have access to the same categories.
PFAQ - Probably Frequently Asked Questions
Why are the resources and categories not stored on the calendar server?
They are not stored there to increase the flexibility of the calendar server. Externalizing the data makes it possible to integrate the server in allready existing structures like e. g. tarent-contact.
Why do category providers exist but no resource providers?
Category-providers are necessary to let all users with the according rights see all calendars. A user would possibly not be able to see the calendar category "vacation", because his calendar would not know that the category exists, if there had not been a central list of the category providers. On the contrary, resources are more independent. There is no need for a shared pool. It is possible to add everything as a resource, espessially external persons, that are not members of the systeminternal user system.
