Als zentrale Komponente zur Verwaltung der Organisationsstruktur der Universität Erlangen-Nürnberg hat FAU.ORG nun das Release der zweiten Version erreicht. Seit der ersten Version hat sich hier einiges verändert. Die Benutzeroberfläche weist einige Neuerungen und verbesserte Features auf und die Kernkomponente wurde sogar komplett neu entwickelt. Dieser Blogartikel stellt das neue, bessere, schnellere und einfachere FAU.ORG vor.
Neue Datenhaltung
Die neu entwickelte Kernkomponente von FAU.ORG basiert nun auf einer relationalen Datenbank und bietet die folgenden Möglichkeiten:
- Abbildung der benötigten Informationen in ein geeignetes Entity-Relationship-Schema
- Persistierung der Daten und Änderungen auf diesen Daten (in separaten Relationen)
- Unterstützung der temporalen Semantik für die Speicherungen von Änderungen in der Vergangenheit, Gegenwart und Zukunft
- Volltextsuche in den Daten der Gegenwart
Zunächst wurde aus dem Datenmodell der ersten Version ein Entity-Relationship-Modell (ER-Modell) mit geringen Modifikationen erstellt. Da die meisten Attribute einer Organisationseinheit einwertige Daten enthalten, hätte man nur eine sehr geringe Anzahl an Relationen mit vielen Attributen entwerfen können. Dann wäre es jedoch nicht mehr so einfach gewesen, zusammen gehörende Daten zu gruppieren und später eine feingranulare Zugriffskontrolle auf bestimmte Attributgruppen zu implementieren. Über dies lässt sich mit mehreren Tabellen ein Mechanismus namens Lazy Loading nutzen. Hierbei werden aus der Datenhaltung nicht mehr alle verfügbaren Daten geladen, sondern nur noch das, was der Benutzer gerade benötigt. Das spart Hauptspeicher und ist in den meisten Fällen effizienter.
Neben den Relationen zur Speicherung der eigentlichen Daten, werden in FAU.ORG alle Änderungen von Beginn an auch als Änderungsereignisse in zwei eigenen Tabellen gespeichert. Ein Änderungsereignis bezieht sich auf das Erstellen, Modifizieren und Löschen von Daten einer Attributgruppe. Jedes Änderungsereignis enthält eine Reihe von Änderungseinträgen, die den alten und den neuen Wert des modifizierten Attributs, sowie das Datum der Änderung und das Datum, ab dem die Änderung gültig wird, enthalten. Dadurch ist es möglich in der Zeit zu reisen, da der Zustand jeder Organisationseinheit für jeden beliebigen Zeitpunkt aus dessen Änderungsereignissen berechnet werden kann.
Damit nicht bei jedem Zugriff der Zustand einer Organisationseinheit berechnet werden muss, enthält die Datenbank den Stand der Gegenwart in den eigentlichen Relationen zur Datenhaltung. Diese können schneller ausgelesen werden. Ändert der Benutzer etwas in der Zukunft werden für diese Änderungen lediglich Änderungsereignisse erstellt und gespeichert. Eine eigene Komponente liest jede Nacht die Änderungsereignisse aus, die für den aktuellen Tag gültig werden und setzt diese Änderungen im Stand der Gegenwart um. Damit wird der Zustand in den Tabellen immer up-to-date gehalten. Eine ähnliche Komponente wird in späteren Versionen externe Systeme mit diesen Änderungen provisionieren. Werden die Organisationsdaten in der Vergangenheit geändert, trägt die Datenhaltung diese Änderungen ebenfalls als Änderungsereignisse ein, prüft danach jedoch zusätzlich, ob sich diese Modifikationen auf die Gegenwart auswirken. Dies ist der Fall, wenn das Attribut der betroffenen Organisationseinheit zwischen dem Änderungszeitpunkt der Vergangenheit und dem Stand der Gegenwart nicht noch einmal modifiziert wurde. Die Änderung wird dann dementsprechend in den Relationen der Gegenwart umgesetzt.
Für die Suche wurde in der neuen Datenhaltung wieder eine Volltextindizierung integriert. Das heißt, dass Benutzer nach beliebigen Stichwörtern in allen Attributen suchen können. Die Volltextsuche kann in zukünftigen Versionen so erweitert werden, dass sie auch die Daten der Vergangenheit und Zukunft indiziert.
Neue und verbesserte Features in der Weboberfläche
Die Benutzeroberfläche von FAU.ORG hat ebenfalls einige Neuerungen zu bieten. So lassen sich beispielsweise Kontaktdaten, die Anschrift und die Statistikschlüssel rekursiv ändern. Das bedeutet, dass die Änderungen auch bei allen bzw. ausgewählten Kindern dieser Organisationseinheit umgesetzt werden. Das Verschieben von Einheiten ist nun auch problemlos möglich. Der Benutzer muss lediglich eine neue Organisationsnummer vergeben (dazu mehr weiter unten) und die Einheit wird mit allen Kindern im Baum an die entsprechende Stelle verschoben.
An der Benutzerfreundlichkeit der Weboberfläche wurde ebenfalls gearbeitet. Die Übersichtsseite einer Organisationseinheit enthält nun Sprungmarken, damit Benutzer schneller zur gewünschten Information gelangen. Des Weiteren unterstützt FAU.ORG nun die Anmeldung per SSO. Die wichtigsten Funktionen sind nun direkt aus dem Baum der Organisationseinheiten abrufbar. Des Weiteren zeigt der Baum nun die Langbezeichnung der Einheiten, was die Lesbarkeit verbessert.
Für die Integration der temporalen Semantik wurde in die Hauptseite eine Auswahlbox für das Systemdatum eingebaut. Hier wählt der Benutzer das Datum, in dem das System gerade betrieben wird. Damit entscheidet man also, ob man sich in der Vergangenheit, Gegenwart oder Zukunft arbeiten möchte. Die angezeigten Daten entsprechen dem zum ausgewählten Datum gültigen Stand der Organisationsstruktur. Das gewählte Systemdatum wird in allen Seiten in der kleinen Infobox auf der rechten Seite angezeigt.
Die verschiedenen Zustände (oder Versionen) der Organisationseinheiten lassen sich in der Historienansicht abrufen. Hier wird angezeigt, wer die Änderung erstellt hat, wann die Änderung erstellt wurde und zu welchem Zeitpunkt die Änderung gültig werden soll. Diese Ansicht lässt sich auf bestimmte Attributgruppen und Zeiträume filtern. Die Weboberfläche unterscheidet zudem seit der zweiten Version normale und kleine Änderungen. Eine kleine Änderung bezeichnet Modifikationen an den Daten, die lediglich Schreibfehler oder ähnliches betreffen und keine Wertänderung im eigentlichen Sinne darstellen. Kleine Änderungen lassen sich in der Historienansicht ausfiltern, was der Übersichtlichkeit beiträgt.
Das Erstellen von Brücken wird nun vollautomatisch von der Weboberfläche übernommen. Zur Erinnerung: jede Organisationseinheit besitzt eine Organisationsnummer aus fünf zweistelligen Zahlen. Der Organisationsbaum wird nach diesen Nummern aufgebaut und besitzt daher eine maximale Tiefe von fünf Ebenen. Ein Beispiel: der Hauptknoten des RRZE im Baum besitzt die Organisationsnummer 10 11 12 00 00. Dessen Vaterknoten hat dementsprechend die 10 11 00 00 00. Es kann nun vorkommen, dass ein Knoten einem Vaterknoten zugeordnet ist, der mehr als eine Ebene höher im Baum liegt. Mit anderen Worten überspringt ein Kind damit eine oder mehrere Ebenen. Der Datenmanagement-Lehrstuhl der Informatik besitzt beispielsweise die 15 13 00 16 00 und überspringt die dritte Ebene im Baum. Damit der Baum keine Lücken aufweist, existieren an diesen Stellen besondere Knoten, sogenannte Brücken (hier die 15 13 00 00 00), die als letzte definierte Stelle in der Organisationsnummer eine Doppelnull besitzen. Das Erstellen von Brücken wird in der zweiten Version nun vollkommen automatisch übernommen, sobald eine Brücke benötigt wird. Brücken werden ebenfalls automatisch gelöscht, falls sie keine Kinder mehr besitzt.
Zu den technischen Finessen werde ich im nächsten Blog-Artikel einen tieferen Einblick in die Umsetzung der Version 2 liefern.
RRZE ? Projects & Processes (P&P): An organisational structure in space and time
An organisational structure in space and time
The University Erlangen-Nuremberg’s central component for managing its organisational structure, FAU.ORG, has released its second version. There have been quite a few changes since the first version was originally released. Several improvements have been made to the user interface, improved features have been added and a new core component has been developed. This articles introduces the new, better, faster and easier-to-use FAU.ORG.
New Data management
FAU.ORG’s newly developed core component is now based on a relational database and offers the following:
- Mapping the necessary information in a suitable entity relationship schema
- Both persistance of data and changing the data (in separate relations)
- Supporting temporal semantics for saving changes in the past, present and future.
- full-text search in present data.
First, an entity relationship model (ER-model) was created from version 1’s data model with only a few changes. As most of the organisational units’ attributes only contain single values, a system with only few relations and a large number of attributes would have been possible. This would have impeded both the grouping of data belonging together, and a later implementation of access control for attribute groups. Use of several tables also allows use of a method called Lazy Loading. With this method, not all available data is loaded from data storage, but only the items the user needs at the moment. This saves memory and is more efficient in most cases.
In addition to saving the actual data, all changes in FAU.ORG are saved as change events in two tables. A change event is given when an attribute group is created, modified or deleted. Every change event contains a number of change entries with the old and new value of the modified attribute, date of the change and the date the change becomes active. This makes ?time travel? possible, as the state of every organisational unit at any point in time can be recreated from these change events.
To avoid having to create the state of an organisational unit with every access, the database contains the present state in the relations for data storage, as these can be read faster. If a user changes something in the future, change events are created and saved. A separate component reads these change events every night, selects those that become active the next day and includes them in the present state. That way, the tables are kept up to date. A similar component will later provision external systems with these changes. If organisational data is changed in the pats, data storage also enters these changes as change events, but then goes on to check if the modification affects the present state. That is the case if the attribute of the organisational unit in question is not modified again between the time of change in the past and the present state. Then, the change is included in the present relations.
For searching, the new data storage has been provided with a full-text index. That allows the user to search for keywords in all attributes. This can be expanded in future versions to allow indexing of past and future data.
New and improved features in the web interface
There are several improvements in FAU.ORG’s user interface as well. Recursive changing of contact data, mailing address and statistical keys is now possible, allowing changes for all or selected children of an organisational unit. Moving units is also much easier now. The user only needs to enter a new organisational number (more on this further down), and the unit and all its children are moved to a new place in the tree.
The website is now much more user-friendly. The starting page contains new jump labels, allowing users to get to the wanted information more easily. Furthermore, FAU.ORG now supports SSO login. The most important functions are available directly from organisational unit tree. The tree also uses the long description of units now, improving readability.
For better integration of the temporal semantic, the main page now features an entry box for the system date. Here, the user can chose the date at which the system runs. That way, you can chose whether to work in the past, present and future. The data displayed matches the organisational structure valid at the selected date. The system data chosen is always displayed in an info box on the right side of the screen.
The organisational units’ different states (or versions) can be selected in the history view. Here you can see who entered a change, and at what time that change will become active. Filters for attribute groups and time periods can be used in this view. The web interface also differenciates between normal and small changes. A small change indicates minor modifications to data like fixed spelling mistakes. They do not normally represent real changes to the values themselves. These small changes can be filtered out in the history view.
Bridges are now created automatically by the web interface. A reminder: Every organisational unit has its own organisational number, consisting of five two-digit numbers. The organisational tree is created from these numbers and accordingly has a maximum depth of five levels. E.g.: The RRZE’s main node in the tree is organisational number 10 11 12 00 00. Its father node is therefore 10 11 00 00 00. It is possible, however, for nodes to be attached to a father node that is more than one level higher up the tree. In other words, the child jumps one or more levels. Since the tree cannot have any ?gaps? special nodes, so called bridges, are entered in these places. Their last defined digit ist 00 (in our example 15 13 00 00 00). These bridges are now created automatically when they are needed. They are also deleted automatically if they do not have any children.
For the finer technical details, I will use the next blog article to give some insight into version 2’s implementation.