UNIGIS Abschlussarbeiten

Der krönende Abschluss eines UNIGIS MSc Studiums ist sicherlich die Master Thesis. Mit ihr belegen unsere MSc-AbsolventInnen, dass sie den akademischen Grad "Master of Science (Geographical Information Science & Systems)" zu Recht führen.  Im UNIGIS professional Studiengang muss keine Abschlussarbeit verfasst werden. Dennoch nehmen einige Studierende die Möglichkeit war, ein Geoinformatikprojekt durchzuführen und entsprechend zu dokumentieren.

Sie sind auf der Suche nach aktueller Literatur zu Geoinformatik-Themen?
Hier finden sie die mitunter preisgekrönten Abschlussarbeiten unserer AbsolventInnen!

Michael Wagner [10-2009]:

Implementation of a History Extension to the Open Source Database Management System PostgreSQL/PostGIS

Diese Arbeit ist online verfügbar: Download

In many fields of application it is crucial to keep track of the changes occurring to objects in the real world in the particular domain. The division of a cadastral parcel in the sector of land administration is an example of such change. Even after the division, resulting in two or more successors, it is important to know how the original parcel looked like and when it existed. If such \historical" information is to be retained in a database, particular concepts have to be applied to allow for this. Within the scope of this thesis a prototype of a history extension to the OpenSource database management system PostgreSQL / PostGIS was implemented. The aim was to provide support for an automated maintenance of valid time and the related history, with valid time being the time when a fact happens or becomes true in the real world (Jensen et al., 1994). It was assumed that in many domains valid time is of greater interest than transaction time, i.e. the time when an information becomes known to the system (Jensen et al., 1994). The challenge was to implement the functionality required for maintenance of a history entirely, on the database server. This way no modification of the client application would be necessary. Furthermore the valid-time period of a feature was to be stored as line, taking into consideration that time can be represented as geometry (Kunzel, 2008; ISO, 2002b). Hence, the spatial functions of PostGIS could be used to perform temporal analysis. With regard to time-oriented statements in databases three types can be differentiated: current (now), sequenced (at each instant of time) and non-sequenced ones (ignoring time) (Snodgrass, 2000). Sequenced statements are the most useful ones but also most complex to express in SQL. A sequenced update actually requires five SQL statements while a sequenced deletion requires four. Within the extension support for sequenced statements was implemented. Sequenced statements cover current statements implicitly. Given a temporal table the standard SQL PRIMARY KEY construct cannot be used any longer. A sequenced primary key is required, one that applies at each instant of time. Such key must be ensured and implemented by a sequenced constraint. The same concept applies to foreign keys and referential integrity. Thus, a sequenced foreign key is necessary, again ensured by a constraint. Converting an existing user table without temporal support to a temporal table required some crucial modifications of that table. First any existing primary or foreign key constraint was dropped. Next a column of type geometry was added to the table to record the valid-time period of the rows. After that the table was renamed and a view created on the table which was given the original name of the table. The view was made \updatable" by creating an INSERT, UDPATE and DELETE rule on it. Within each rule the actual SQL statements required for a sequenced modification (five for an update, four for a deletion and one for an insertion) are executed on the underlying table. Furthermore, triggers were created on the table that ensure the sequenced primary and foreign key(s). Besides that, a number of supportive database procedures were implemented that are required e.g. to convert time to geometry and vice versa. The entire changes necessary to make a table temporal, are basically hidden from the client. The client still finds the user table under the same name (although its actually a view), and also original primary and foreign key(s) are retained (implemented as sequenced keys). The only obvious change for the client application is the need to set the period of applicability (by calling a single database procedure) before performing a database operation. Once set, this period serves as a filter for all subsequent queries and modifications on the user table. The client application continues working with the database the way it did as without temporal support but behind the \scenes" a full history of the data is maintained.

Zurck weitere Arbeiten ...