INTERLIS Benutzerhandbuch

Die Ferienregion Ilistal hat sich entschlossen, ihre Webpage auf Vordermann zu bringen. Das vielfältige Transportangebot soll interaktiv mittels eines grafischen Dialogs abrufbar sein. Die Präsentation im Gemeindehaus war beeindruckend: Schöne Bilder, trendige Abkürzungen wie HTML, XML, GIS, SVG! Sogleich kamen natürlich weitere Wünsche auf. Im Bauamt entschloss man sich kürzlich, die Adressen nach der neuen Norm zu erfassen. Das könnte man doch nutzen! Der Direktor der Ilishornbahnen erinnert sich, dass der nationale Bergbahnenverband einen Dienst einrichten möchte, über den das landesweite Bergbahnangebot verfügbar ist. Dabei sollen auch die Fahrpreise und insbesondere die verschiedenen Verbundabonnemente abrufbar sein. Sein Kollege, der für die technischen Belange zuständig ist, macht darauf aufmerksam, dass er auf seinem Compi die ganze Infrastruktur verwalte. Informationen über die Bahntrassees und die Pisten könne er schon liefern. Da sei aber nicht alles klar. Kürzlich habe er nämlich auf dem Bauamt gefragt, ob er nicht die Daten der neuen Überbauung «Im Oberboden» haben könne. Sie hätten es dann schliesslich hingekriegt. Einige Informationen seien zwar verloren gegangen. Die seien aber nicht so wichtig gewesen.

Da wird die Gemeindepräsidentin hellhörig. Eine Kollegin, die in einer Gemeinde nahe der Hauptstadt tätig ist, hat ihr doch erzählt, dass sie in einem Teilbereich bereits die dritte Software im Einsatz hätten. Zusatzwünsche, die sie eigentlich normal fand, führten jeweils zur vollständigen Überarbeitung. Sie hätten dann Unterstützung von einem Informatiker erhalten, der weniger von den verschiedenen Techniken sprach. Vielmehr habe man zuerst gemeinsam überlegt, welche Daten mit den Problemen verbunden seien. Seitdem man so vorgehe, sei es auch viel besser möglich, schrittweise Erfolge zu erzielen.

Die Gemeindepräsidentin, eine freundliche aber entschlossene Frau, beauftragt darum den Bausekretär, sich zusammen mit dem technischen Leiter der Ilishornbahnen um die Sache zu kümmern. Als Fachmann zieht sie den Informatiker ihrer Kollegin bei.

Beim ersten Gespräch der Arbeitsgruppe purzelten die verschiedenen Stichworte und Argumente anfänglich noch wild durcheinander: Mit welchem Programmpaket arbeitet der nationale Verband? Meint man nur die Bahnunternehmung oder jede einzelne Bahn, jeden Skilift? Die einzelnen Bahnen, aber auch die Gebäude sind ja bereits in der amtlichen Vermessung enthalten. Wie kann man diese Daten brauchen? Was passiert, wenn Daten ändern, wenn neue Daten hinzukommen? Aber mein Programmpaket versteht nur DXF! Und ich nur Bahnhof!

Das gab das Zeichen, um kurz inne zu halten. Man erinnerte sich an die alte römische Devise «Divide et impera» und begann Ordnung zu machen, um der Sache Herr zu werden. Im Vordergrund standen zuerst folgende Fragen:

Aber wie kommen die Daten nun vom Bearbeiter zum Nutzer? E-Mail, FTP, DXF, ASCII – schon ging’s wieder los. Der Informatiker empfahl, diese Frage mal etwas zurückzustellen und sich darum zu kümmern, wie die Daten modelliert seien. Modelliert? Wir wollen doch eine Informatiklösung und kein Holzmodell für unser schönes Ilistal. Die Frage, was ein Datenmodell ist, sprengte den Rahmen der ersten Sitzung. Nur soviel: Es soll beschreiben, wie die Daten aufgebaut sind. Welche Eigenschaften haben die verschiedenen Objekte? Welche Objekte stehen mit welchen anderen Objekten in Beziehung? Und das nicht einfach als Aufsatz, sondern in einer klaren, präzisen bildlichen oder formalen Sprache!

Der nationale Tourismusverband bietet mit seinem Programmpaket NatTourSys einen Überblick zu den verschiedenen Billetten der Bergbahnen an. Die Billette werden durch die einzelnen Bahngesellschaften herausgegeben. Der Tourist interessiert sich aber vor allem dafür, auf welchen Bergbahnen welche Billette gültig sind. Bevor sie in ihr eigenes Projekt einsteigen, wollen sich die Ilistaler zunächst eine Übersicht verschaffen.

Eines ist klar: Im Zusammenhang mit dem Programmpaket muss man über Bergbahnen, Bahngesellschaften und Billette sprechen.

Was meint man wirklich, wenn man von Billetten spricht? Wirklich das einzelne Billett, das verkauft wird? In dieser Anwendung sicher nicht. Man möchte die einzelnen Arten von Billetten beschreiben. Besser sprechen wir darum gleich von Billettarten. Die verschiedenen Gegenstände haben offensichtlich weitergehende Eigenschaften: Bei den Billettarten kann man z.B. von einem Preis und von einer Gültigkeitsdauer sprechen.

Beschreibt man nun alle Eigenschaften der Gegenstände in Worten, wird bald einmal die Übersicht relativ schwierig. «Ein Bild sagt mehr als tausend Worte» kommt einem in den Sinn. Ein Objektdiagramm – das wär’s! Aber eigentlich wollen wir ja gar nicht die einzelnen Objekte beschreiben. Wir möchten vor allem aufzeigen, welche gleichartigen Gegenstände es gibt und welche Eigenschaften sie haben.

Mit einem solchen Diagramm sieht man das Wichtigste ganz gut:

Objektklassen werden mit Substantiven bezeichnet. Es wird die Einzahl verwendet, weil man ausdrücken möchte, dass jedes einzelne Objekt (z.B. also jede einzelne Bergbahn) die mit der Klasse beschriebenen Eigenschaften hat.

Jede Bergbahn wird von einer Bahngesellschaft betrieben. Diese bietet bestimmte Billettarten an. Ohne zusätzliche Informationen müssen sie jeweils für alle ihre Bergbahnen gültig sein. Damit wird man kaum zufrieden sein, da grössere Gesellschaften durchaus Billettarten herausgeben, die nur für einen Teil ihrer Bahnen gelten. Als nahe liegende Idee führt man eine weitere Beziehung zwischen Bergbahn und Billettart ein. Es wird also bei jeder Billettart aufgezählt, für welche Bergbahnen sie gilt:

Häufig sind aber mehrere Billettarten (z.B. Tageskarte, Wochenkarte, etc.) im gleichen Bereich gültig. Mit dem bis jetzt formulierten Modell müssten die Zuordnungen für jede Billettart einzeln erstellt werden. Das ist eher mühsam und fehleranfällig. Darum hat wohl auch der nationale Tourismusverband ein etwas verfeinertes Modell gewählt:

Mehrere Bergbahnen können einer Bahngesellschaft zugeordnet werden. Einer Bahngesellschaft können umgekehrt mehrere Bergbahnen zugeordnet werden. Mehrere? Wie viele genau?

In der Grafik wird die minimale und maximale Zahl der zulässigen anderen Objekte am Ende der Beziehungslinie bei der Klasse der anderen Objekte angemerkt. Ist die Zahl nach oben nicht beschränkt ist, schreibt man einen Stern (*) oder lässt die Angabe weg.

Selbstverständlich ist es für die geplante Anwendung nötig, dass eine Bergbahn, eine Bahngesellschaft, usw. detaillierter beschrieben wird. Eine Gesellschaft wird einen Namen und (bei Bahnen typisch) eine Kurzbezeichnung haben (z.B. Ilishornbahnen, IhB).

Bei diesen beiden Attributen ist es bereits durch die Bezeichnung recht offensichtlich, von welcher Art sie sind: Texte. Beim Preis einer Billettart werden weitere Angaben schon etwas wichtiger: Franken, Euro, Dollar, Ahländer Taler? Bei der Gültigkeitsdauer würde es vor allem dann anspruchsvoller, wenn sie nicht einfach mit einer Anzahl von Tagen beschrieben werden kann. Will man bei einer Bahn die Länge angeben, ist es natürlich auch von Belang, ob sie in Meter oder Kilometer beschrieben wird. Für die bearbeitenden Programme ist es wichtig zu wissen, wie lang die vorgesehenen Textattribute werden dürfen oder in welchem Bereich die vorgesehenen Zahlen liegen dürfen.

Man kann sich aber auch gut andere Attributtypen vorstellen:

Anders als eine Billettart oder eine Bergbahngesellschaft ist die Talstation einer Bergbahn ein Gegenstand, der real an einem bestimmten Ort existiert. Orte werden sinnvollerweise mittels Koordinaten innerhalb eines bestimmten Koordinatensystems, z.B. des Landessystems, beschrieben.

Für jede Eigenschaft wird somit ein passender Attributtyp festgelegt. Im Fall einer Skipiste ist der Schwierigkeitsgrad eine Aufzählung. Der Verlauf der Skipiste ist dagegen eine gerichtete Linie in Ahländer Landeskoordinaten. Details zu verschiedenen Typen werden in Kapitel 6, Das Datenmodell unter der Lupe besprochen.

Nach all diesen doch eher theoretischen Dingen drängen die Ilistaler nun auf Taten. Eine Anfrage beim nationalen Tourismusverband ergab, dass dieser ein einfaches Programm zur Datenerfassung gemäss seinen Anforderungen zur Verfügung stellt. Mit diesem können die Daten im INTERLIS-Format exportiert und dann dem nationalen Tourismusverband geschickt werden. Der Informatiker wendete zwar ein, dass damit höchstens ein erster Test gemacht werden könne und man die Daten nachher im Programmpaket der Ilishornbahnen oder in demjenigen des Bauamtes halten sollte. Diesen Test wollte man aber schon machen. Schliesslich sollte damit ja nicht soviel Arbeit verbunden sein. Denn so umfangreich sind die Ilishornbahnen auch wieder nicht, und die Anzahl Billettarten hält sich auch in Grenzen.

Zu den Ilishornbahnen gehören folgende Bergbahnen:

Die Ilishornbahnen bieten dafür folgende Billettarten an:

Für den Test konnte mit dem Programm eine Datei erstellt werden, die alle Daten enthält.

Ein kurzer Blick in die Datei zeigte zwar viel Unverständliches, aber immerhin fand man die Texte «Ilishornbahnen», gleich daneben «IhB», und auch der Abonnementspreis war leicht zu finden.

Gleich noch ein Test: Der Jahrespreis für den Sportpass wird von 635 auf 600 Taler gesenkt und mit der Funktion Nachlieferung eine neue Datei erstellt. Der Anfang sieht zwar noch gleich aus. Die Texte «Ilishornbahnen» und «IhB» fehlen. Aber hier, fast am Schluss – das könnte der neue Preis sein!

Beide Dateien wurden dann wie vereinbart dem Tourismusverband geschickt. Dieser konnte sie offenbar problemlos lesen. Einwand des Informatikers: Das ist ja auch nicht verwunderlich. Solange wir genau die Daten erfassen, die der Verband will, und dies erst noch mit einem Programm, das der Verband zur Verfügung stellt, kann man das ja schon erwarten. Aber wir Ilistaler wollen doch mehr! Und wir möchten doch wenn immer möglich unsere bisherigen Programmpakete einsetzen.

Ilistal möchte also nicht einfach den gleichen Service anbieten, wie dies der nationale Tourismusverband tut. Folgende Zusatzleistungen stehen im Vordergrund:

Die für die bildliche Darstellung nötigen Daten der Wälder und Strassen möchte man natürlich nicht selbst erfassen, denn das Bauamt hat schliesslich die Daten der amtlichen Vermessung, welche auch Wälder und Strassen enthalten. Und das Bauamt hat doch damit begonnen, die Gebäudeadressen gemäss der neuen Norm zu erfassen. Nun macht es wenig Sinn, im Datenmodell von Ilistal all diese Definitionen zu wiederholen. Man möchte einfach die vorhandenen Modelle der amtlichen Vermessung und der Gebäudeadressen nutzen.

Das Modell des nationalen Tourismusverbandes wollen die Ilistaler aber nicht einfach so nutzen, wie es ist. Damit man eine bildliche Darstellung machen kann, muss doch bei jeder Bergbahn auch der Trasseeverlauf beschrieben sein. Zudem möchte man festhalten, ob die Bahn durch Wanderer und Schlittler benutzbar ist, wann sie in Betrieb ist und wie lange die aktuelle Wartezeit ist. Es wäre nahe liegend, eine eigene Klasse für die Ilistaler Bergbahnen zu definieren. Sollen dabei die Attribute der Klasse Bergbahn des nationalen Verbandes wiederholt werden? Und da gibt es noch die Beziehung zwischen Bergbahnen und Tarifbereichen. Was würde eine eigene Klasse für diese Beziehung heissen?

Zum Glück gibt es für solche Fälle die Vererbung.

Wäre es nun richtig, in der Klasse IhBBergbahn gleich auch die Attribute Betriebszeit und aktuelle Wartezeit aufzunehmen? Wäre die Betriebszeit direkt ein Attribut von IhBBergbahn, könnte für jede Bahn genau eine, typischerweise die aktuelle Betriebszeit festgehalten werden. Der Betriebsleiter legt aber die Betriebszeiten jeweils zu Saisonbeginn fest: In der Vorsaison sind einzelne Lifte noch nicht in Betrieb, andere haben Mittagspause; über die Weihnachtstage ist voller Betrieb von 9 bis 15.30 Uhr; ab Mitte Februar – wenn die Tage länger werden – wird die Betriebszeit schrittweise bis 16.30 ausgedehnt. Je nach Schneeund Wetterverhältnissen wird dann der Betrieb einzelner Bahnen vorübergehend stillgelegt.

Legt man zudem noch fest, dass eine bestimmte Betriebszeit für verschiedene Bahnen gelten kann, kann der Erfassungsaufwand noch weiter gesenkt werden. Bei den Wartezeiten macht dies natürlich keinen Sinn. Eine zu einem bestimmten Zeitpunkt beobachtete Wartezeit muss derjenigen Bahn zugeordnet werden, bei der entsprechend gewartet werden muss. Warum hält man die Wartezeit also nicht direkt auf der IhBBergbahn fest? Folgende Gründe sprechen dagegen:

Bei diesen Überlegungen ist der tatsächliche Sachverhalt und nicht die Nutzung z.B. für Darstellungen massgebend. Wichtig sind aber auch die organisatorischen Verhältnisse. Wer ist für die Nachführung der Daten zuständig? In welchen Rhythmus werden sie nachgeführt?

Im Modell des nationalen Verbandes sind die einzelnen Bergbahngesellschaften für die Nachführung ihrer Daten verantwortlich. Das Ilistaler Modell möchte – was die Bergbahnen betrifft – das Modell des nationalen Verbandes zwar nutzen, es aber für die Ilishorn-Bergbahnen erweitern.

Das Ilistaler Modell erweitert darum das vom nationalen Verband vorgegebene Thema Bergbahnen zu IhBBergbahnen. In dieser lokalen Erweiterung ist definiert, dass die Klasse IhBBergbahn die Klasse Bergbahn spezialisiert und um zusätzliche Attribute erweitert.

Da die Betriebszeiten, die Betriebsentscheide und die Zustandsmeldungen teilweise durch verschiedene Stellen, vor allem aber in völlig anderem Rhythmus erfasst werden, werden sie je in eigenen Themen (IhBPlanung, IhBBetrieb, IhBAktuell) definiert.

Zusätzlich möchten die Ilistaler auch Pisten und Gasthäuser beschreiben. Sie fügen dem Ilistaler Modell darum noch weitere Themen zu.

Besonders bei den Gasthäusern stellen sich wieder Fragen. Wie soll z.B. der Schnellimbiss INTERLUNCH bildlich dargestellt werden? Man weiss zwar, dass er an der Dorfstrasse 27 liegt. Aber damit kann man kein Symbol auf dem Plan platzieren! Die Lösung liegt in der Nutzung der Gebäudeadressen. Dort gibt es eine Klasse Hauseingang, die auch ein Lageattribut (in Landeskoordinaten) aufweist. In der Klasse Gasthaus wird darum gar keine Adresse geführt, sondern eine Beziehung zum Hauseingang definiert. Konkret wird das Objekt, welches dem Hotel Sonne entspricht, mit dem Hauseingang-Objekt verbunden, das die Dorfstrasse 27 beschreibt.

Ein Konzept regelt die Anforderungen, nicht aber die Implementation. In der Implementation ist man grundsätzlich frei. Die Ilishornbahnen haben sich für ein standardisiertes Programmpaket (LiftSys) entschieden, das allerdings nur Daten gemäss dem erweiterten Modell behandeln kann. Es ist aber ohne weiteres zulässig, auf die Klasse Bergbahn zu verzichten und deren Attribute gleich in der Klasse IhBBergbahn einzufügen.

Analog zur Behandlung der Klassen gemäss Konzept stellen sich verschiedene weitere Fragen, wie ein bestimmtes Computersystem die Vorstellungen umsetzt, die mit dem konzeptuellen Modell verbunden sind.

Nachdem das LiftSys-Programmpaket eingerichtet und die Daten erfasst sind, stellt sich wieder die Frage, wie die Daten dem nationalen Verband übermittelt werden können. Dieser will natürlich nicht alle Daten, sondern nur diejenigen, die ihn interessieren. Der nationale Verband ist z.B. weder an Pisten noch an der Eignung für Wanderer und Schlittler interessiert.

Die Ilistaler wollen darum dem nationalen Verband die Daten der Themen Bergbahnen und Billette schicken. Aber wie kann ein Programmpaket eine korrekte Transferdatei erstellen – der Hersteller kannte doch die Spezifikationen des Tourismusverbandes gar nicht? Die Lösung liegt im modellbasierten Transfer.

Jede Modellierungsmethode (z.B. INTERLIS, oder die Definitionen, mit denen ein bestimmtes Programmpaket eingerichtet wird) stellt bestimmte Ausdrucksmittel (Objektklassen, Attribute, Typen, Beziehungen, Tabellen, Kolonnen, usw.) zur Verfügung. Für jedes solche Ausdrucksmittel wird unabhängig vom konkreten Datenmodell geregelt, welche Wirkungen es auf den Transfer hat. Von einem konkreten Transferformat, also der genauen Reihenfolge der Zeichen, welche die jeweiligen Daten repräsentieren, kann man somit erst sprechen, wenn das zugehörige Datenmodell bekannt ist. Ja, das Transferformat ergibt sich direkt aus dem Datenmodell.

Wäre LiftSys in der Lage, das interne Datenmodell direkt gemäss dem konzeptuellen Datenmodell aufzubauen, und würde es zusätzlich die Umsetzung der Daten in Transferdateien gemäss den Spezifikationen von INTERLIS unterstützen, wäre alles kein Problem. Die Transferdateien könnten genau so einfach erstellt werden wie mit dem Testprogramm des Verbandes.

Das Programmpaket des Bauamtes (BauSys) unterstützt zum Beispiel die Erstellung von INTERLIS 2-konformen Dateien. Es kennt aber nur einzelne Tabellen, die jeweils mehrere Kolonnen aufweisen können. Da die Formatierungsregeln von INTERLIS so aufgebaut sind, dass die Vererbungsstruktur sich in der Transferdatei nicht direkt spiegelt, könnten mit BauSys direkt korrekte Dateien erstellt werden. Die Umsetzung von den internen in die externen Daten kann man sich wie folgt vorstellen:

Das LiftSys unterstützt aber INTERLIS nicht. Was nun? Müssen sich die Ilishornbahnen mit dem Kauf eines neuen Programmpakets beschäftigen? Der Ausweg ist offensichtlich: LiftSys exportiert die Daten in einem anderen Format, diese werden dann mit einem Konversionsprogramm nach INTERLIS umgeformt. Das Konversionsprogramm kann entweder spezifisch für das konkrete Datenmodell oder allgemein als modellbasiertes Werkzeug realisiert sein.

Nachdem alles glücklich funktionierte, wird die Datei an den nationalen Verband geschickt. Das Echo: «Fast gut – beim Namen des Sesselliftes auf die Ilisegg gibt es aber ein Problem!» Uff – das kennen wir doch auch aus verschiedenen E-Mails: «Ilistäli»; immer diese Umlaute.

Zwei Dinge sollten klar unterschieden werden:

Die Umlaute gehören zum erlaubten Zeichenvorrat von INTERLIS. Aber bei der Konversion wurde vergessen, die Zeichencodierung der Daten, die vom LiftSys kamen, korrekt anzugeben. Nach der Korrektur erhält Ilistal ein positives Echo vom Verband.

Über etwas sind nun die Ilistaler ein wenig erstaunt: Was hat das Computersystem des nationalen Tourismusverbands (NatTourSys) wohl mit den zusätzlichen Attributen angefangen – etwa mit der Eignung für Wanderer und Schlittler oder gar dem Trasseeverlauf? Die Lösung klingt simpel: NatTourSys hat sie einfach ignoriert.

Die Ilistaler haben die Daten zwar so geschickt, dass sie alle Erweiterungen gemäss dem Ilistaler Modell enthalten. Die Transferregeln von INTERLIS sorgen dafür, dass die Daten dennoch gemäss dem Modell des nationalen Tourismusverbandes gelesen werden können, ohne dass das Leseprogramm wegen der zusätzlichen Daten aus dem Takt gerät. Bedingung ist nur, dass das Modell, gemäss dem die Daten erstellt wurden, eine Erweiterung jenes Modells ist, das der Empfänger der Daten benutzt. Das Ilistaler Modell muss also das Modell des nationalen Tourismusverbandes erweitern.

Dabei ist es auf der lesenden Seite möglich, dass die Daten direkt mit dem Programmpaket des Empfängers gelesen werden oder dass auch hier ein Konversionsprogramm zwischengeschaltet wird. Und auch hier gilt wieder, dass die konkreten Zeichen der TextAttribute korrekt umgesetzt werden. Das «ä» von Ilistäli kann durchaus im LiftSys, auf der Transferdatei und im NatTourSys je unterschiedlich codiert sein. Für die jeweiligen Programme ist es immer klar, dass es ein «ä» ist.

Beim Internet hat man sich für eine relativ einfache Lösung entschieden: Der Situationsplan wird als statisches Bild durch das Programmpaket LiftSys erstellt und danach einem WebPräsentationssystem (WebSys) zur Verfügung gestellt. Um den aktuellen Zustand der Bahnen abfragen zu können, werden bestimmte Bereiche im Bild markiert. Wird mit der Maus auf einen dieser Flecken geklickt, erscheinen die aktuellen Zustandsdaten der betreffenden Bahn. Zudem sollen die Hotels mit freien Zimmern speziell markiert werden.

Die Ilistaler haben sich Mühe gegeben und ihr Modell vor allem auch für die betrieblichen Daten der Bahnen und Pisten sauber strukturiert. Nur ist leider das Programm, welches laufend die Internetseite aktualisiert, nicht in der Lage, aus der Vielzahl von Betriebszeiten, Betriebsentscheiden und Zustandsmeldungen den jeweils aktuellen Zustand abzuleiten. Der Betreiber möchte einerseits die Daten gemäss dem Thema IhBBillette immer dann erhalten, wenn etwas geändert hat. Andererseits möchte er aber über den betrieblichen Zustand der Bergbahnen alle 20 Minuten eine neue Mitteilung erhalten.

Die verlangte Sicht verbindet Betriebszeiten, Betriebentscheide und Wartezeiten mit derjenigen Bergbahn, der sie gemäss Beziehung zugeordnet sind und filtert so, dass nur der aktuelle Zustand beschrieben wird.

Damit WebSys eine zusätzliche Markierung anbringen kann, in welchen Hotels es noch freie Zimmer gibt, braucht es natürlich die nötigen Informationen. Ähnlich wie bei den Zuständen der Bahnen wird darum auch für Hotels eine Sicht definiert. Sie enthält einerseits die nötigen Daten der Gasthausobjekte, andererseits die Lagekoordinaten gemäss dem zugeordneten Hauseingang.

Leider ist WebSys aber nicht in der Lage, solche Umsetzungsbeschreibungen zu verarbeiten. Es ist aber fähig, die Symboldefinitionen zu lesen. Zudem kann es Daten entgegennehmen, die aussagen, welches Symbol an welcher Stelle dargestellt werden soll und dann die Darstellung vornehmen. Damit kann eine andere Möglichkeit von INTERLIS ausgenützt werden, die auf LiftSys zur Verfügung steht.

LiftSys liefert WebSys darum nicht die Sichtdaten der Hotels, sondern setzt diese selbst in Grafikdaten um. Der genaue Aufbau der Grafikdaten kann wiederum mit Klassen definiert werden. Typische Attribute solcher Grafikdaten sind die Position, der Symbolname, die Farbe.

Das Modell für Gebäudeadressen wird nicht abgedruckt, denn es würde mehrere Seiten umfassen und ist im Zusammenhang des Ilistals nicht im Detail von Interesse. Das Ilistaler Tourismus-Modell etabliert jedoch eine Beziehung zwischen Gasthäusern und den im Adressmodell definierten Hauseingängen.

Ein Einzelbillett für eine einfache Fahrt mit der Standseilbahn auf das Ilishorn kostet 10 Ahländer Taler, ein Jahressportpass 635 Taler. Wie soll nun der Preis eines Billettes modelliert werden?

Wer sich an Programmiersprachen gewohnt ist, denkt sicher sofort an ganze Zahlen («Integer») oder Fliesskommazahlen («Real»). Bei vielen Programmiersprachen und Datenbanken lässt sich festlegen, wie viel Speicherplatz eine Zahl benötigt; hieraus folgen Grösse und Genauigkeit der speicherbaren Zahlen («short integer», «long integer», «double precision», etc.). Man überlegt sich dann, in welchem Bereich die Werte etwa liegen können, und wählt die passende Speicherform.

Bei der Modellierung auf konzeptueller Stufe möchte man sich aber eigentlich nicht um die Speicherform kümmern. Es ist aber möglich, den höchsten und den tiefsten zulässigen Wert anzugeben und dabei gleich noch die Stellenzahl sowie den Exponenten festzulegen.

Da sich die Preise zwischen 10 und 635 Talern bewegen, könnte man also schreiben:

Damit würde man aber auch festlegen, dass ein Preis nie kleiner als 10 Taler und nie grösser als 635 Taler sein kann. Das möchte man natürlich nicht. Als untere Schranke ist 0 plausibel. Aber die obere Schranke? Mehr als 10'000 Taler werden es ja kaum sein. Also 10'000? Wo eine Schranke auf Grund der Anwendung nicht genau festgelegt werden kann, macht es jedenfalls keinen Sinn, den Wert so zu wählen, dass eine kürzere Speicherform (z.B. short integer mit Werten zwischen –32768 und 32767) gerade nicht mehr ausreicht.

Dabei ist es natürlich auch wichtig zu überlegen, wie viele Nachkommastellen nötig sind. Wenn die Preise auch Groschen aufweisen können, werden die Schranken eben mit jeweils zwei Nachkommastellen festgelegt. Bei einem Attribut, das z.B. ein Investitionsbudget darstellt, möchte man sich nur mit Millionen abgeben; wo es nur um Grössenordnungen geht, reichen zwei Ziffern. Diese können sich aber auf Tausend, eine Million oder gar eine Milliarde beziehen.

Die Anzahl der Stellen bezeichnet die Genauigkeit: «4.3 Millionen» (4.3E6 = 4.3 · 106) ist eine weniger genaue Angabe als «4300000».

Sind das jetzt Taler, Franken, Euro oder Dollar? Die Einheit ist – nicht nur beim Geld – von entscheidender Bedeutung. Darum ist es empfehlenswert, die Einheit nicht nur als Kommentar oder als Teil des Attributnamens anzugeben, sondern als Bestandteil des Typs:

Taler (oder Schweizerfranken, Euro, Dollar, etc.) werden als Einheit definiert und können dann bei der Definition eines numerischen Typs benutzt werden. Die meisten gängigen Einheiten (darunter auch CHF, EUR, USD) müssen jedoch nicht selbst definiert werden, sondern stehen über das spezielle Einheiten-Modell (units.ili, vgl. Kapitel 3.3, “Standardisierte Datenmodelle”) zur Verfügung.

Da die Ilishornbahnen nie Billette abgeben werden, die mehr als tausend Taler kosten, könnte man auf die Idee kommen, dies in einer eigenen Klasse zu definieren:

In dieser Anwendung macht dieses konkrete Beispiel eher wenig Sinn. Es gibt aber durchaus Fälle in der Praxis, wo es sinnvoll ist, den ererbten Wertebereich einzuschränken.

Die Ilistaler dürfen nun allerdings nicht die Wertebereiche des nationalen Modells beliebig verändern: Es gilt das Prinzip, dass jeder Ilistaler Wert auch im Basismodell des Nationalverbands zulässig sein muss. Sonst wäre nicht mehr sichergestellt, dass der nationale Verband problemlos Daten aus dem Ilistal übernehmen kann.

Eine Preisangabe 0 .. 1000 ist also eine zulässige Einschränkung des national vorgesehenen Bereichs 0 .. 9999. Würde man den Wertebereich im Ilistal aber ausdehnen – etwa mit der Angabe 0 .. 15000 – dann wären Billettarten, die zwischen 10000 und 15000 Taler kosten, aus der Sicht des nationalen Verbandes nicht korrekt. Eine solche Definition ist darum unzulässig.

Die Ilistaler wollen auch die Möglichkeit haben, Billette auszugeben, deren Preis nicht zwingend ein voller Talerbetrag ist. Man möchte folgende Definition schreiben:

Aber ist das mit dem Basismodell verträglich? Ja, denn jeder Wert gemäss Ilistaler Modell (z.B. 7.35) kann mit mathematischer Rundung auf einen korrekten Wert des nationalen Modells abgebildet werden (z.B. 7).

Die Definition wäre dann unzulässig, wenn sie Werte umfassen würde, die gerundet das Basismodell verletzen. Beispielsweise würde ein Maximalwert von 9999.99 nach dem Runden zu 10000 – dies wäre mehr als die vom nationalen Verband vorgegebenen 9999. Dagegen könnten die Ilistaler einen Bereich 0.00 .. 9999.49 definieren, ohne dem Basismodell zu widersprechen, denn 9999.49 ergibt nach der Rundung wieder 9999.

Ebenfalls unzulässig ist es, im spezialisierten Modell auf Genauigkeit zu verzichten. Würde das nationale Tourismusmodell zum Beispiel einen Bereich von 0.00 .. 1000.00 vorsehen, könnten die Ilistaler in ihrer Spezialisierung nicht die Angabe 0 .. 1000 machen.

Und noch etwas: Die Einheiten der Erweiterung müssen immer mit derjenigen der Basis übereinstimmen!

Kann der nationale Verband festlegen, welcher Preis für ein Billett zulässig ist? Sind die Schranken noch völlig unbekannt, kann – im Rahmen abstrakter Attribute – auf ihre Angabe verzichtet werden. Es ist aber möglich, dennoch bereits eine Einheit festzulegen.

Vielleicht ist sogar die Einheit noch unklar. Man weiss erst, dass es sich z.B. um eine Währung handelt.

Damit ist immerhin der Charakter der Einheit festgelegt. In einer Erweiterung können damit nur noch Einheiten definiert werden, die Konkretisierungen der abstrakten Einheit MONEY sind (zu abstrakten Eigenschaften siehe auch Abschnitt 5.4).

Um den Schwierigkeitsgrad von Skipisten grob zu beschreiben, wurden drei Farben gewählt: blau, rot, schwarz. Es soll nur diese und keine anderen Schwierigkeitsgrade geben. Zudem sind sie geordnet. Blau bezeichnet eine einfache Piste, eine rote Piste ist schwieriger als eine blaue, eine schwarze am anspruchsvollsten. Dies wird mit der folgenden Definition beschrieben:

Würde die FINAL-Angabe fehlen, könnte die Aufzählung in einer Erweiterung noch ergänzt werden. Zum Beispiel könnte dies bei der Art von Bergbahnen Sinn machen:

In der erweiterten Klasse wird der Aufzählung noch das Element Schneebus – das neuste vom Neuen – am Ende der bisherigen Aufzählung beigefügt. Aber was fängt der nationale Tourismusverband damit an? Dort ist «Schneebus» doch ein unbekannter Wert.

Für die Basisklasse ist der Wert Schneebus (und allfällige weitere Werte) nur noch als OTHER erkennbar. Wird jedoch FINAL angegeben, kann der Wert OTHER nicht mehr auftreten. Ist eine Aufzählung zyklisch (CIRCULAR) definiert, sind solche Ergänzungen nie möglich, heisst doch zyklisch, dass nach dem höchsten Wert wieder der niedrigste kommt und man sonst gar nicht wüsste, welches der höchste ist.

Man hatte also beschlossen, die verschiedenen Arten von Bergbahnen nicht mit einer ganzen Landschaft von Klassen zu modellieren. Aber die Bahnfreunde waren nicht recht einverstanden: Das Stangensystem der Zahnradbahnen könnte ja vielleicht doch noch irgendwann einmal von Interesse sein…​

Für jeden Wert einer Aufzählung kann eine Unteraufzählung definiert werden. Dies kann direkt innerhalb der Basisdefinition oder erst in einer Erweiterung erfolgen.

Wird eine solche Unteraufzählung in einer Erweiterung definiert, ist sie aus der Sicht der Basis einfach nicht von Belang. Aus der Sicht des nationalen Tourismusverbands würde also auch eine Riggenbach-Zahnradbahn eine Zahnradbahn sein.

Auch Unteraufzählungen können wieder um weitere Werte ergänzt werden, sofern ihr letzter Wert nicht als FINAL erklärt wurde. Die einzelnen Werte einer Unteraufzählung können zudem wiederum durch Unteraufzählungen präzisiert werden, so dass ganze Aufzählungsbäume entstehen.

Mit der Frage «Wo?» ist die Vorstellung eines punktförmigen Ortes in der realen Welt verbunden. Ein solcher Ort kann mittels einer Koordinate beschrieben werden. Eine Koordinate ist typischerweise ein Zahlenpaar das die Lage, oder ein Zahlentripel das die Lage und Höhe, eines Ortes beschreibt.

Für jede Dimension eines Koordinatentyps muss darum wie für jeden numerischen Typ festgelegt werden, in welchem Zahlenbereich die zulässigen Werte liegen dürfen und welche Einheit mit ihr verbunden ist.

Der Unterschied zwischen einem Lageattribut mit einem Koordinatentyp und je einem numerischen Attribut für die X- und die Y-Richtung ist auf den ersten Blick klein. Dank der Definition als Koordinatentyp ist es aber offensichtlich, dass die beiden Angaben zusammengehören. Diese Eigenschaft kann durch die Programmpakete auch ausgenützt werden. So sind viele Programme dafür eingerichtet, kartesische Koordinatenwerte grafisch darzustellen.

Kartesische Koordinatenwerte? Als kartesische Koordinaten werden Koordinaten bezeichnet, deren Dimensionen senkrecht aufeinander stehen. Mit der Definition der obigen Lagekoordinaten wird also ein rechteckiges Fenster von etwa 90 mal 22 Kilometer Ausdehnung beschrieben. Ein Rückfall ins Mittelalter? Ist nun die Erde im Ilistal wieder zur Scheibe geworden?

Schon für Ptolemäus war die Erde eine Kugel. Die Vermesser (oder die Geodäten, wie sie heissen, wenn es um die gehobeneren Fragen der Vermessungstechnik geht) mussten sich schon lange von dieser Sicht abwenden, weil sie allzu sehr vereinfacht.

Eine brauchbare Annäherung der Erdoberfläche ist das Ellipsoid, also jene Fläche, die entsteht, wenn sich eine Ellipse um ihre zentrale Achse dreht.

Je nach Weltgegend werden anders gelegene Ellipsoide benutzt, sonst würde die Annäherung zu ungenau. Beispielsweise verwendet die Schweiz das gleiche Ellipsoid wie Deutschland, aber ein leicht anderes als Schweden oder Frankreich.

Als räumliche Gebilde sind Ellipsoide jedoch etwas mühselig zu handhaben. Aus diesem Grund bilden Geodäten das Ellipsoid auf eine Fläche ab. Hierzu legen sie einen Zylinder oder Kegel an das Ellipsoid an und beleuchten es von innen, so dass das Landschaftsbild auf den Zylinder oder den Kegel projiziert wird.

Als nächstes wird der Zylinder oder Kegel mit einer Schere aufgeschnitten, abgerollt und flach auf den Tisch gelegt – fertig ist die Karte!

Zuletzt werden feine, rechtwinklig aufeinander stehende Linien über die Karte gelegt: Das Koordinatensystem der Karte. Bei jedem Koordinatentyp muss darum auch festgelegt werden, welches Koordinatensystem ihm zu Grunde liegt.

Die erste Dimension der Koordinate entspricht der ersten Achse des Koordinatensystems mit Namen «AhlandSys», die zweite Dimension der zweiten Achse des gleichen Systems.

Ist «AhlandSys» ein kartesisches, ein ellipsoidisches System? Wie heissen die Achsen? Gibt es Zusammenhänge (z.B. Kartenprojektionen) zu anderen Koordinatensystemen? All diese Angaben können selbst wieder mittels Daten beschrieben werden. Damit klar ist, wie diese Daten strukturiert sind, wird dafür ebenfalls ein Datenmodell formuliert. Ein solches Modell heisst Metamodell, die zugehörigen Daten Metadaten, weil sie dazu dienen, die eigentlichen Daten zu beschreiben.

Die Daten zu einem Metamodell sind in einem anderen, formaleren Sinn «meta» als Angaben zu Herkunft oder Preis (vgl. Kapitel 3.3, “Standardisierte Datenmodelle”). Für beides ist jedoch unglücklicherweise dieselbe Bezeichnung verbreitet.

In den einfachen Fällen, wo es auf Grund des Anwendungs- und Einsatzgebietes eines Datenmodells klar ist, zu welchem Koordinatensystem die Koordinaten gehören, kann auf die explizite Angabe des Koordinatensystems verzichtet werden. Es macht aber Sinn, das Koordinatensystem mindestens im Namen des Koordinatentyps anklingen zu lassen.

Um Verwechslungen auszuschliessen haben die Ilistaler eine präzise Definition vorgezogen:

Sie haben auf der Grundlage des allgemeinen Modells für Koordinatensysteme (CoordSys) ihr Landessystem präzis definiert. Für die Lage wurde dafür in den entsprechenden Daten ein Objekt der Klasse GeoCartesian2D mit dem Namen AhlandSys eingetragen. Die Existenz dieses Dateneintrags wird mittels OBJECTS OF im Modell angemerkt. Das Koordinatensystem „AhlandSys“ ist damit im Modell verfügbar. Bei der Anwendung des Systems muss der Name des Metadatenbestands (CoordSystems) nur erwähnt werden, wenn im aktuellen Modellierungsteil mehrere solche Metadatenbestände definiert sind.

Damit denjenigen Touristen, die über einen einfachen GPS-Empfänger verfügen, ein besonderer Service geboten werden kann, möchten die Ilistaler ihre Koordinaten auch als geografische Koordinaten im globalen WGS84-System anbieten.

Nun ist es aber offensichtlich, dass die beiden Attribute einen direkten Zusammenhang haben. Landeskoordinaten können doch in WGS84-Koordinaten umgerechnet werden. Die detaillierte Definition einer solchen Umrechnung ist aber nicht Aufgabe einer konzeptuellen Beschreibung der Daten. Es ist aber wünschenswert anzugeben, dass die einen Koordinaten aus den anderen gerechnet werden können.

Den Skifahrern und Wanderern rund um das Ilishorn genügen natürlich die Lagekoordinaten nicht. Grosse Höhendifferenzen lassen die Skifahrerherzen höher schlagen, während der Wanderer Schweissperlen oder schlotternde Knie befürchten muss. Höhen sind gefragt! Koordinatentypen können darum auch drei Dimensionen aufweisen.

Bei den Höhen stellt sich noch ein besonderes Problem. Wo ist eigentlich die Höhe 0? Wie kann man die Höhe eines Punktes gegenüber dieser Höhe 0 bestimmen? Die Geodäten unterscheiden vor allem zwischen den Höhen gemäss dem Schwerefeld der Erde (Schwereoder Geoid-Höhe; 0 ist die Höhe der gedachten Fortsetzung des Meeres unter den Kontinenten) und Höhen gemäss der geometrischen Annäherung der Erde (Ellipsoid-Höhe; 0 ist die Oberfläche des Ellipsoids).

Die Landeskoordinatensysteme verwenden typischerweise Geoidhöhen. Darum bezieht sich die dritte Dimension der Landeskoordinaten auch nicht einfach auf die dritte Achse des Landessystems, sondern auf die erste Achse eines speziellen Höhensystems.

Dagegen werden die Koordinaten bei GPS-Messungen rein geometrisch aus Satellitenpositionen bestimmt, ohne dass das Schwerefeld der Erde eine Rolle spielen würde. WGS84-Höhen sind also Ellipsoidhöhen.

Die Umrechnung zwischen Schwerehöhen und Ellipsoidhöhen kann vor allem dort ein Problem sein, wo der Bereich der zulässigen Koordinaten ein Gebiet abdeckt, dessen Schwerefeld nicht mehr homogen ist. Zum Glück sind diese Fragen bei der Modellierung nur von geringer Bedeutung. Einen kleinen Gedanken sind sie aber dennoch wert.

Vom Standpunkt der Skifahrer aus gesehen ist der Bedarf klar: Sie wollen wissen, wo die Piste beginnt, wo sie endet und wo sie grob durchführt. Gibt es ein Gasthaus am Pistenrand? Führt die Piste über freie Hänge oder durch den Wald? Für diese Information genügt es, den Pistenverlauf als Linie zu beschreiben.

Unter einem Linientyp darf man sich zunächst genau das vorstellen, was das Wort verspricht: Eine mehr oder minder komplizierte Verbindung zwischen zwei Punkten.

In diesem Sinn ist ein Linientyp nichts anderes als z.B. ein numerischer Typ oder besser noch ein Koordinatentyp. Da die an der Linie beteiligten Punkte durch Koordinaten beschrieben werden müssen, ist es zwingend, dass ein Linientyp immer mit einem Koordinatentyp verbunden sein muss.

In INTERLIS könnte man schreiben:

Der Pistenverlauf wird mittels Linien beschrieben, die auf dem Ahländer LandesKoordinatensystem basieren. Die Stützpunkte der Linien im Ahländer Landessystem stützen sich deshalb auf den Koordinatentyp des Landessystems ab.

Es ist offensichtlich: Die Piste vom Ilishorn zur Ilisegg ist eine komplizierte Linie. Die Pisten bei den Ponyliften dagegen relativ einfach. Alles mit demselben Typ beschreibbar? Die Lösung liegt darin, dass die Linie als Ganzes in einzelne Linienstücke aufgeteilt wird. Jedes Linienstück ist selbst eine einfache Geometrie (z.B. eine Gerade, ein Stück eines Kreisbogens) und schliesst jeweils an das Vorgängerstück an.

Diesen Sachverhalt könnte man im konzeptuellen Modell auch darstellen. Das wäre aber eher eine überflüssige Belastung. Wenn man einmal weiss, dass Linien immer so aufgebaut sind, muss dies ja nicht mehr dargestellt werden.

Es macht aber durchaus Sinn anzugeben, welche Arten von Linienstücken bei einem bestimmten Linientyp vorkommen dürfen.

Mit dieser INTERLIS 2-Definition wird angegeben, dass Linien dieses Typs Geraden- und Kreisbogenstücke aufweisen dürfen.

In vielen Fällen – so auch bei den Pisten – macht es keinen Sinn, dass eine Linie Schnittpunkte mit sich selbst aufweist. Solche Einschränkungen gehören auch zum konzeptuellen Modell. Aufgrund von Ungenauigkeiten beim Vermessen (und teils auch beim Berechnen) ist es jedoch möglich, dass eine an sich überlappungsfreie Form ganz leichte Überlappungen aufweist. Aus diesem Grund ist die maximal noch zulässige Überlappung Teil des Modells. Sie wird in den Einheiten der zugehörigen Koordinaten angegeben.

Nachdem das Ahländer Landes-Koordinatensystem Meter verwendet, sind mit dieser Definition Überlappungen bis zu 2 cm erlaubt:

Als Skifahrer erwartet man natürlich, dass die Linienstücke der Piste vom Ilishorn zur Ilisegg beim Ilishorn beginnen und bei der Ilisegg enden. Man möchte ja hinunterfahren und nicht die Steigfelle montieren! Zur Beschreibung anderer Objekte (z.B. der Wanderwege) ist jedoch die Richtung nicht von Bedeutung. Wo die Richtung der Linien von Bedeutung ist, soll dies im konzeptuellen Modell auch angegeben werden.

Für den Pistendienst der Ilishornbahnen stellte sich die Frage, ob die Beschreibung der Pisten für seine Zwecke genügt. Damit immer klar ist, welche Bereiche jeweils präpariert werden müssen, wird eine Darstellung als Fläche vorgezogen.

Kurz vor der Ilisegg steht mitten in der Piste ein grosser Baum – oder anders gesagt, die Piste geht links und rechts am Baum vorbei.

Ist die zu präparierende Fläche noch eine einzige Fläche? Mit Flächen – mindestens im Sinne von INTERLIS – sind immer zusammenhängende Bereiche gemeint. Auch wenn sie im Innern Aussparungen (Löcher, Enklaven) haben, sind es immer noch zusammenhängende Bereiche und können damit als eine Fläche beschrieben werden.

Oben beim Ilishorn liegen verschiedene Pisten anfänglich so nahe beieinander, dass eine gemeinsame präparierte Fläche entsteht. Welcher Flächenteil soll nun welcher Piste zugeordnet werden? Im Ilistäli kreuzen sich zwei Pisten. Damit wird die Fläche ja doppelt erfasst. Für die Abschätzung des Arbeitsaufwandes für die Präparierung stört das natürlich.

Der Pistendienst hat sich darum für eine andere Modellierung entschieden: Die zu präparierenden Flächen werden nicht direkt den Pisten zugeordnet, sondern als eigenständige Pistenabschnitte geführt. Jeder Pistenabschnitt ist eine Fläche. Die Pistenabschnitte sollen sich aber nie überlappen, da ein bestimmter Geländeabschnitt schliesslich nur einmal präpariert werden muss.

Da solche überlappungsfreien Flächen recht häufig vorkommen, wurde dafür in INTERLIS ein eigener Typ (AREA) eingeführt. Statt von Flächen wird von Gebietseinteilungen gesprochen.

Ist der zur Liniendefinition gehörige Koordinatentyp ein dreidimensionaler Typ, ist auch der Linientyp dreidimensional. INTERLIS 2 verzichtet dabei darauf, die dritte Dimension gleichberechtigt zu den ersten beiden zu führen, da in geographischen Anwendungen die drei Dimensionen immer in die Lage und eine Höheninformation aufgeteilt werden können.

Dabei wird davon ausgegangen, dass jeder Stützpunkt (Punkt zwischen zwei Linienstücken) mit Lage und Höhe definiert ist und die Höhe auf dem Linienstück entsprechend der Länge des Kurvenstückteils linear interpoliert wird.

Sollte man den Pistenverlauf nun nicht mit einem dreidimensionalen Linientyp modellieren? Rein technisch wäre dies offenbar kein Problem, und die Höhe spielt schliesslich beim Skifahren eine wichtige Rolle. Dagegen spricht aber, dass die Höhe des Pistenverlaufs keine unabhängige Grösse ist: Kennt man die Lage, ergibt sich die Höhe aus der Geländeform. Die Höhe des Pistenverlaufs kann damit anhand seiner Lage und einem Geländemodell berechnet werden. Aus konzeptueller Sicht ist es darum vorzuziehen, auf die Höheninformation beim Pistenverlauf zu verzichten.

Anders kann es bei Strassen und Eisenbahnen sein, denn bei Brücken und Tunnels stimmt die Höhe nicht mit der Terrainhöhe überein. Allenfalls wird auch für die Höhe eine so grosse Genauigkeit gefordert, dass eine Ableitung aus dem Geländemodell nicht in Frage kommt. In gewissen Fällen kann es auch Sinn machen, die Kunstbauten (mit Höhe) unabhängig vom Trasseeverlauf zu modellieren. In diesem Fall würde die effektive Trasseehöhe im Bereich der Kunstbauten aus dem Modell errechnet; an den übrigen Stellen würde auf das Geländemodell zurückgegriffen.

Ein wichtiges Entscheidungskriterium in dieser Frage dürfte der Aufwand für Erfassung und Nachführung sein.

Kurz vor der Ilisegg ziehen sich die Leute auf dem Sessellift vom Ilistäli die Kappe fest über die Ohren: Hier pfeift der Wind so richtig. Beim Wind ist eben nicht nur die Windgeschwindigkeit, sondern auch die Richtung aus der er kommt, massgebend. Führt man diese beiden Eigenschaften im Rahmen einer Klassenbeschreibung einfach zusammen mit anderen Attributen auf, kommt dieser Sachverhalt wenig zum Ausdruck.

Für Situationen, wo ein Sachverhalt nicht durch einen einzigen, sondern durch mehrere Werte beschrieben wird, ist es sinnvoll, eine Struktur (Windangabe) zu definieren, welche die verschiedenen Eigenschaften (Windrichtung, Windgeschwindigkeit) umfasst.

Überall, wo eine Aussage über den Wind gemacht wird, kann diese Struktur verwendet werden.

Der Windmesser auf der Ilisegg ist noch etwas spezieller: Er zeigt nicht einfach den aktuellen Wert, sondern gleich die letzten sechs gemessenen Werte an. Deswegen werden die Ohren zwar nicht wärmer, aber erstaunlich ist es ja schon, wie schnell die Verhältnisse manchmal ändern können.

Das Attribut Wind umfasst also sechs Elemente (Messwerte je mit Windrichtung und Windgeschwindigkeit). Mit LIST OF wird ausgesagt, dass die Reihenfolge relevant ist (z.B. der neuste Wert zuerst). Wäre die Reihenfolge nicht relevant, würde man BAG OF schreiben. Ähnlich wie bei den Beziehungen kann angegeben werden, wie viele Elemente minimal und maximal aufgeführt sein können.

Strukturen und (Objekt-)Klassen sind einander formal sehr ähnlich. Sachlich bestehen aber erhebliche Unterschiede. Eine Klasse (Bahngesellschaft, Windmesser) beschreibt, wie Objekte aufgebaut sind. Eine Struktur beschreibt, wie kompliziertere Eigenschaften von Objekten (Windangabe) aufgebaut sind. Eine Struktur dient also dem gleichen Zweck wie ein Wertebereich, nämlich der Beschreibung wie ein Attribut aufgebaut ist. Manchmal bedarf es nur dann einer Struktur, wenn die Eigenschaft detaillierter beschrieben werden soll, während bei einfacher Beschreibung die Angabe eines Wertebereichs genügt (vgl. Kapitel 6.12, “Wie ticken die Ilistaler? – Modellierung von Zeit”).

Die Instanzen von Klassen sind Objekte mit einer Eigenständigkeit (Ilishornbahnen, Windmesser auf der Ilisegg). Die Instanzen von Strukturen sind Strukturelemente (Wind mit 180 km/h aus NE). Der Wert eines Strukturattributes kann genau ein Strukturelement oder eine Menge von Strukturelementen (BAG OF, LIST OF) umfassen.

Objekte können miteinander in Beziehung stehen (vgl. Kapitel 6.13, “Tarifbereiche, Zustandsmeldungen – Beziehungen”). Werte (von Wertebereichen oder Strukturen) können dies nicht. Man kann allerdings gleichartige Werte verschiedener Objekte (und verschiedener Klassen) miteinander vergleichen und so in eine Beziehung bringen (vgl. Kapitel 6.17, “Tarifbereiche interessieren nicht – Sichten”). So könnte man den Preis für den Wanderer-Pass mit dem Preis für das Holzfällersteak vergleichen, das man im Falle des Fussmarsches im Bergrestaurant Ilishorn essen würde. Deswegen besteht aber keine Beziehung zwischen dem Wanderer-Pass und dem Holzfällersteak.

Für gewisse Fälle ist es nötig, dass zur Beschreibung einer Eigenschaft auf ein anderes Objekt verwiesen wird (vgl. Kapitel 6.11.3, “Strukturelemente dürfen auf Objekte verweisen”). Auf einen Wert oder ein Strukturelement kann nie verwiesen werden, sie haben keine Identität.

Das Attribut Verlauf der Piste (vgl. Kapitel 6.9.1, “Einfache konzeptuelle Sicht einer Linie”) ist als AhlandLinie, diese als POLYLINE definiert. Eine POLYLINE kann man als eine Menge von Linienstücken verstehen (vgl. Kapitel 6.9.2, “Linienstücke”). Die Definition als POLYLINE ist also nur eine abgekürzte Schreibweise für eine geordnete Menge von Strukturen, wobei die Strukturelemente einer bestimmten Strukturdefinition entsprechen:

Im bisherigen Modell besitzt eine Bahngesellschaft einen Namen sowie eine Kurzbezeichnung. Wie kann damit erfasst werden, dass die Ilishornbahnen (IhB) auf Französisch Remontées mécaniques de la Dent d’Ili (RDI) heissen?

Es liegt nahe, die Objektklasse Bahngesellschaft um den französische Namen und die Kurzbezeichnung zu ergänzen:

Damit wäre der Fall klar. Was aber, wenn eines Tages der Wunsch aufkommen sollte, den Namen auch noch in einer dritten, vierten oder fünften Sprache zu erfassen? An sich kein Problem – es handelt sich ja nur um eine kleine Änderung des Datenmodells!

Besser ist es daher, wenn die konkrete Sprache gar nicht im Datenmodell vorkommt. In der folgenden neuen Version weist eine Bahngesellschaft eine Menge von Bahnbezeichnungen auf. Da der Umgang mit mehreren Sprachen ein häufiges Anliegen ist, erbt die Struktur Bahnbezeichnung die Grundstruktur Bezeichnung, welche die Sprache und einen Text umfasst.

Oder bildlich:

Um Bezeichnungen in einer anderen Sprache hinzuzufügen, sind nur neue Daten zu erfassen. Das Datenmodell muss deswegen nicht angepasst werden.

Wer kennt schon die Sprachabkürzung für das Rätoromanische? rr? rm! Im Rahmen des nationalen Verbandes ist es klar, welche Sprachen für die Bezeichnungen der Bahngesellschaften in Frage kommen. Bei der Erfassung einer Bahn ist in der Regel nur eine Abkürzung zu beachten. Die kann man sich gut merken, weshalb der nationale Tourismusverband sein Modell wie oben beschrieben aufgebaut hat.

Wäre dies nicht der Fall gewesen, hätte man ein Modell gewählt, bei dem die Sprachen eigentliche Objekte sind. Das Sprachobjekt würde die Abkürzung und z.B. den Namen je als Text in der eigenen Sprache und in englisch enthalten.

Die Bezeichnung verweist so auf die Sprache. Dieser Verweis ist aber nicht eine vollwertige Beziehung (vgl. Kapitel 6.13, “Tarifbereiche, Zustandsmeldungen – Beziehungen”), da die Bezeichnungen keine Identität haben. Aus Sicht des Sprachobjektes besteht darum auch kein direkter Zugang zu den Bezeichnungselementen. Dieser müsste über eine Sicht etabliert werden (vgl. Kapitel 6.17, “Tarifbereiche interessieren nicht – Sichten”).

Der nationale Verband hat eine simple Lösung und für die Gültigkeitsdauer von Billettarten ein Attribut vorgesehen, das die Anzahl Tage (mit einer Stelle nach dem Komma) vorsieht.

Wenn man es – wie die Ilistaler – etwas genauer nimmt, stellen sich verschiedene Fragen:

Auf Anfrage erhielten die Ilistaler vom nationalen Verband die Antwort, dass folgendes gelte:

Wie könnte aber eine bessere Lösung aussehen?

Objekteigenschaften wie die Gültigkeitsdauer können nicht immer durch einen einzigen Wert genügend präzis beschrieben werden. Manchmal braucht es eine Gruppe von Attributen, manchmal macht es Sinn, verschiedene Erweiterungen vorzusehen. Dafür bietet sich die Struktur an.

Die Gültigkeitsdauer einer bestimmten Billettart ist mit einer Instanz (einem Strukturelement) der Struktur ZeitdauerHeute, ZeitdauerInTagen, ZeitdauerInMonaten, etc. beschrieben. Man könnte sogar noch etwas präziser modellieren und dafür sorgen, dass die Einheit einer expliziten Dauer (Tag, Monat, etc.) immer eine Zeitdauer sein muss und für implizite Zeitdauern (Woche, Saison, etc.) eine Aufzählung definieren:

Zeitdauern gibt es nicht nur für Billette. Die Ilistaler veranstalten jeden Freitag ein Skirennen für ihre Gäste. Dort werden Rennzeiten in Minuten, Sekunden und deren Bruchteilen gemessen. Es ist nahe liegend, dafür eine Struktur zu definieren, welche die Attribute Minuten und Sekunden aufweist:

Damit der Zusammenhang zwischen Minuten und Sekunden ausgedrückt werden kann, bietet sich eine zusätzliche Möglichkeit an:

Damit ist nichts darüber ausgesagt, in welcher Form solche Zeitdauern in einem Computer gespeichert werden. Es handelt sich nur um ein Mittel, möglichst konzeptnah zu beschreiben, was man wirklich will.

Das Gästeskirennen wird immer so gestaltet, dass selbst die Skilehrer sicher mehr als dreissig Sekunden für die Abfahrt benötigen. Wer mehr als drei Minuten und dreissig Sekunden braucht, erhält am Ziel einen wärmenden Tee, die Zeit wird jedoch nicht festgehalten.

Wie kann nun der zulässige Wertebereich (30 Sekunden bis 3 Minuten und 30 Sekunden) festgehalten werden? Die Lösung liegt in formatierten Wertebereichen:

Ein formatierter Wertebereich nimmt auf eine Struktur Bezug und legt fest, wie aus den einzelnen Attributen der Struktur und aus Textkonstanten eine Zeichenkette entsteht, die den Wert wiedergibt. In dieser Form können Wertebereichseinschränkungen festgelegt werden. Die formatierte Darstellung wird auch für den Datentransfer verwendet. Damit ist es zum Teil möglich, gewisse extern verlangte Darstellungsformen direkt zu unterstützen. Dies kann insbesondere für die XML-konforme Darstellung von Zeitdauern und Zeitpunkten genutzt werden.

Statusmeldungen über das Wetter, die Wartezeiten, die Pistenverhältnisse sollen im Ilistal immer mit dem Zeitpunkt versehen werden, in dem der Zustand festgestellt wurde. Erster Gedanke: Uhrzeit in Stunden und Minuten. Ja, damit man Statistiken erstellen kann, gehört natürlich noch das Datum dazu. Das sollte genügen!

Wirklich? Die Ilishornbahnen führen in schönen Vollmondnächten Sonderkurse zum Ilishorn, damit dort die beliebte Dracula-Party steigen kann. Da werden natürlich auch mitten in der Nacht Statusmeldungen geschickt. Auch um 2.30 Uhr. Auch an jenem Sonntag in der Früh, als von der Sommer- auf die Winterzeit umgestellt wurde. Allerdings gab es da ein grosses Durcheinander: Die neuste Meldung war plötzlich älter als die letzte! Natürlich: Alle Zeiten zwischen 2.00 und 3.00 gab es in jener Nacht doppelt, einmal gemäss Sommerzeit, einmal gemäss Winterzeit.

Meinen wir Sommerzeit, Winterzeit, UTC? Je internationaler, desto wichtiger! Da kommt man schnell einmal auf den Gedanken, alles in UTC festzuhalten und es dem Computer zu überlassen, die Daten dem Benützer gemäss seiner aktuellen Zeitzone zu präsentieren.

INTERLIS 2 bietet die Möglichkeit an, nicht nur den Wertebereich und die Einheit, sondern auch das Bezugssystem zu beschreiben. Für die UTC-Zeiten sind bereits formatierte Wertebereiche gemäss den XML-Regeln vordefiniert (XMLTime, XMLDate, XMLDateTime).

Gerade Öffnungs- oder Betriebszeiten werden aber vorzugsweise in der lokalen Zeit beschrieben. Mitternacht ist eben um 24.00 Uhr, unabhängig davon, ob gerade Sommer- oder Winterzeit ist. Dies sind aber nicht eigentliche Zeitpunkte. Vielmehr beschreiben sie Differenzen zu Mitternacht gemäss der aktuell gültigen Zeit.

Was ist nun eine Bahngesellschaft für eine bestimmte Bergbahn? Eigentümerin? Betreiberin!

In der Beziehung zwischen Bahngesellschaft und Bergbahn ist die Bahngesellschaft in der Rolle der Betreiberin.

Der Rollenname wird in der Grafik am Ende der Beziehungslinie auf der Seite des Inhabers der Rolle angeschrieben. Wenn er sich aber nicht vom Klassennamen unterscheidet, wird der Rollenname meistens weggelassen.

Es ist durchaus normal, dass Rollennamen gewählt werden, die sich nicht von den Klassennamen unterscheiden. In der Beziehung Bergbahn – Tarifbereich macht es z.B. wenig Sinn, weitere Namen einzuführen. Allerdings ist der Bedarf nach zusätzlichen Namen ganz offensichtlich gegeben, wenn eine Beziehung zwischen Objekten der gleichen Klasse besteht. So möchte man auch darstellen können, dass eine Bahngesellschaft andere Bahngesellschaften als Tochtergesellschaften besitzt.

Assoziation, Aggregation und Komposition sind Ausdrücke für unterschiedliche Stärken von Beziehungen.

Die Einteilung gemäss diesen Stärken ist nicht immer einfach. Aus Sicht der Informatik gibt es aber noch weitere Regeln, die den Entscheid manchmal vereinfachen:

Die Schreibweise in INTERLIS ist der graphischen Darstellung nachempfunden. Der Rollenname muss jedoch auch dann geschrieben werden, wenn er sich nicht vom Namen der Klasse unterscheidet.

Diverse Billettarten berechtigen zur Fahrt auf Bergbahnen, die von verschiedenen Bahngesellschaften betrieben werden. Damit stellt sich die Frage, wie der mit dem Billettverkauf erzielte Erlös auf die einzelnen Gesellschaften verteilt wird. Zum Beispiel berechtigt das nationale Generalabonnement auch zur Fahrt mit der Ilishornbahn. Gemäss Abmachung erhalten die Ilishornbahnen dafür 0.13% des Umsatzes an Generalabonnements vergütet.

Beziehungen können auch Attribute aufweisen und haben so den Charakter von speziellen Klassen.

Um einen besseren Überblick über die Billettverkäufe zu erhalten, möchte der nationale Verband in Zukunft noch festhalten, welche Verkaufsstelle von welcher Billettart in welcher Saison wie viele Exemplare verkauft hat.

Verkaufsstelle, Billettart und Saison stehen damit in einer gleichberechtigten Beziehung, auf der zudem noch die Anzahl der verkauften Billette und der umgesetzte Betrag als Attribut festgehalten sind. Diese Beziehung verbindet also nicht mehr zwei, sondern drei Klassen.

Was aber bedeuten bei mehrgliedrigen Beziehungen die Kardinalitätsangaben genau? Die Kardinalitätsangabe z.B. bei der Saison (*) sagt aus, dass es für eine bestimmte Kombination von Billettart und Verkaufsstelle beliebig viele Zuordnungen zu Saison-Objekten geben darf. Würde dort die Kardinalität 1 angegeben, würde das bedeuten, dass eine bestimmte Billettart durch eine bestimmte Verkaufsstelle nur während einer Saison verkauft werden kann.

Etwas kompliziert. Braucht es wirklich mehrgliedrige Beziehungen, oder könnte man sie auf die üblichen Zweierbeziehungen reduzieren?

Dieses Modell drückt aber weniger klar aus, dass die drei Klassen Verkaufsstelle, Billettart und Saison als Dreiergruppe miteinander in Beziehung stehen.

Betrachtet man alle Bergbahnen, die der Bahngesellschaft Ilishorn-Bahnen zugeordnet sind, ist damit keine bestimmte Ordnung verbunden. Die Frage, ob in der Zuordnung die Luftseilbahn vor oder nach der Gondelbahn erscheint, macht eigentlich gar keinen Sinn.

Natürlich kann man die Bahnen einer Gesellschaft in alphabetischer Reihenfolge auflisten. Diese Sortierung ist aber nicht eine Eigenschaft der Beziehung zwischen Bahngesellschaft und Bergbahn, sondern eine reine Frage der Darstellung. Für einen anderen Zweck könnte auch eine Sortierung nach Investitionskosten, Fahrzeit usw. interessant sein.

Aber wäre es nicht sinnvoll, mit der Ordnung festzuhalten, in welcher Reihenfolge die Beziehung etabliert wurde? Zuerst wurde die Luftseilbahn eröffnet, dann der Skilift, dann die Gondelbahn, usw. In diesem Fall wäre es allerdings besser, die Beziehung mit den Attributen Betriebsanfang und Betriebsende zu versehen. Dann könnte sogar festgehalten werden, welche Betreiberin es über die Zeit hinweg gegeben hat. Es macht in diesem Fall auch keinen Sinn mehr, die Beziehung als Aggregation aufzufassen.

Ähnliche Überlegungen gelten für die Beziehung zwischen Bergbahn und Masten: Mit der Ordnung der Beziehung könnte man die Reihenfolge von Tal- zu Bergstation ausdrücken. Konzeptuell ist es aber besser, beim Mast ein Lageattribut zu führen und die Reihenfolge dann aus dieser Lage und dem Trasseeverlauf abzuleiten.

Wo machen geordnete Beziehungen überhaupt einen Sinn? Die Gondelbahn von Ilisbad aufs Ilishorn hat Gondeln, die nicht fix auf dem Transportseil montiert sind. Sie können vielmehr in der Tal- und Bergstation abgestellt und je nach Bedarf ins Seil eingeklinkt werden. Welche Gondeln sind aktuell in welcher Reihenfolge auf das Seil eingeklinkt?

Hier ist die Ordnung gefragt. Die Nummer der Gondel kann nicht für die Ordnung herangezogen werden. Diese identifiziert einfach die konkrete Gondel. Über die Reihenfolge, wie sie aktuell auf dem Seil angeordnet sind, sagt sie überhaupt nichts aus.

Eine Bahngesellschaft steht zu einer Reihe von Personen in Beziehung. Die einen sind bei ihr angestellt, die anderen an ihr beteiligt. Ähnlich wie zuvor bei den verschiedenen Arten von Bergbahnen gibt es auch hier verschiedene Möglichkeiten der Modellierung.

Eine Möglichkeit besteht darin, zwei unterschiedliche Beziehungen zwischen Bahngesellschaft und Person zu definieren: eine für die Anstellung, eine für die Beteiligung. Falls diese Unterscheidung einmal nicht wesentlich sein sollte (vielleicht für den weihnachtlichen Versand eines Schoggi-Bähnlis), muss sich eine Anwendung aber um beide Beziehungen kümmern.

Eine andere Möglichkeit der Modellierung besteht darin, primär eine Beziehung zu definieren (Kontakt) und diese dann zu Anstellung bzw. Beteiligung zu erweitern. Solange es für eine Anwendung nicht relevant ist, in welcher Art des Kontaktes die Person zur Bahngesellschaft steht, nutzt sie die Kontakt-Beziehung und erhält so alle Personen, die in irgendeiner Art und Weise zur Bahngesellschaft in Kontakt stehen. Eine Anwendung, für die nur die Angestellten relevant sind, nutzt die erweiterte Beziehung Anstellung und erhält so nur die angestellten Personen.

Man könnte die Anstellungsbeziehung nochmals erweitern und z.B. eine Beziehung «Direktion» einführen.

Erweiterungen von Beziehungen gehen häufig Hand in Hand mit der Erweiterung von Objektklassen. Statt dass man z.B. von Anfang an sagt, eine Bergbahn weise Masten auf, spricht man zunächst nur von Betriebsmitteln. Diese sind der Bahn locker, also mittels Assoziation, zugeordnet. Da Masten eine wichtige Eigenschaft verschiedener Arten von Bergbahnen sind, wird die Klasse «BahnMitMasten» eingeführt. Diese hat eine Beziehung zu den Masten. Diese wird aber als Erweiterung der Beziehung zwischen Bergbahnen und Betriebsmitteln geführt. Da die Masten – etwa im Gegensatz zu einem Pistenfahrzeug – unmittelbar zu Bergbahn gehören, wird diese Beziehung zur Komposition. Die Stärke einer Beziehung darf in einer Erweiterung aber nur verstärkt, nicht aber gelockert werden, da sie sonst im Widerspruch zur Definition in der Basisdefinition stünde.

Wenn der Magen knurrt, wählt man lieber eine Skipiste, an der ein Gasthaus liegt. Deswegen müssen aber Pisten und Gasthäuser nicht miteinander in einer ständigen, ausdrücklichen Beziehung stehen. Es genügt zu wissen, dass das Gasthaus in der Nähe der Piste steht. Eine Aussage, die auf Grund von Lage des Gasthauses und Verlauf der Piste (je in Landeskoordinaten) herleitbar ist.

Es macht auch keinen Sinn, sämtliche ableitbaren Beziehungen ins konzeptuelle Modell aufzunehmen. Darum fehlt die ableitbare Beziehung zwischen Gasthäusern und Pisten im konzeptuellen Modell.

Von konzeptueller Bedeutung sind nicht zuletzt Beziehungen, die in einigen Fällen explizit definiert werden müssen und in anderen Fällen ableitbar sind. Die Ableitung kann sich auf die Geographie oder auf andere Eigenschaften abstützen. Beispielsweise führten die Ilistaler einen speziellen Tarifbereich ein, der als Fläche umschrieben ist und alle Bergbahnen umfasst, deren Tal- und Bergstation innerhalb der Fläche liegt.

Die Beziehung zwischen diesem speziellen Tarifbereich und den Bergbahnen in der zugehörigen Gegend kann mit Sichten (vgl. Kapitel 6.17, “Tarifbereiche interessieren nicht – Sichten”) automatisch etabliert werden.

Wir erinnern uns, dass die Ilishornbahnen für die einzelnen Bergbahnen jeweils den aktuellen Zustand erfassen wollen, unter anderem das Wetter bei der Bergstation:

Mit dieser Definition wäre auch eine Meldung mit einer undefinierten Windrichtung und einer Windgeschwindigkeit von 60 km/h erlaubt. Das ist aber nicht die Meinung. Eine undefinierte Windrichtung soll Windstille bedeuten. Dann aber ist die Windgeschwindigkeit natürlich 0. Und umgekehrt soll bei einer Windgeschwindigkeit grösser Null immer auch die Windrichtung definiert sein.

Eine Konsistenzbedingung wird in der Regel mit einer Formel beschrieben, deren Auswertung ergibt, ob die Bedingung erfüllt ist oder nicht. Mit einem solchen logischen Ausdruck kann die Windstille geregelt werden:

Genau dann wenn die Windrichtung definiert ist, muss die Windgeschwindigkeit grösser Null sein. Ist die Windrichtung nicht definiert, muss die Geschwindigkeit Null sein. Es wird also gefordert, die «Definiertheit» der Windrichtung solle gleich (==) der «Positivheit» der Windgeschwindigkeit sein.

Häufig sind aber Konsistenzbedingungen vermeidbar, wenn das Modell anders aufgebaut wird. Packt man die Windangaben in eine Struktur und sagt, dass diese Struktur als Ganzes fakultativ ist, braucht es keine Konsistenzbedingung. Bei Windstille fehlt das Strukturelement. Windet es, sind zwingend Windrichtung und Windgeschwindigkeit vorhanden.

Die Angestellten der Ilishornbahn verdienen allesamt nicht schlecht, aber der Direktor bezieht ein doch deutlich höheres Gehalt.

Konsistenzbedingungen gelten üblicherweise für alle Objekte der betreffenden Klasse. In INTERLIS 2 werden sie als MANDATORY CONSTRAINT bezeichnet. Man spricht gelegentlich von «harten» Bedingungen, weil sie immer erfüllt sein müssen. Nun gibt es aber auch Bedingungen, die in aller Regel, aber eben nicht immer erfüllt sind.

Bei Attributen wie Monatssalär oder Körpergrösse muss der grundsätzlich zulässige Bereich relativ gross gewählt werden. Die Werte der meisten Objekte liegen aber unterhalb einer wesentlich tieferen Grenze. Ausnahmen sind dennoch möglich, wie zum Beispiel für den Lohn des Bahndirektors.

Es wird geschätzt, dass das Monatssalär in mindestens (>=) 95% aller Fälle unter 10000 Talern liegt. Umfasst ein Modell solche «weichen» Bedingungen, wird es möglich, Daten bei der Eingabe auf ihre Plausibilität zu prüfen und statistisch zu kontrollieren.

Wie werden die Personen identifiziert, die bei Bergbahngesellschaften arbeiten oder an ihnen beteiligt sind? Nahe liegend, aber ungeeignet wäre es, hierzu Name und Vorname zu verwenden:

Es wäre dann unzulässig, zwei verschiedene Personen mit der gleichen Kombination von Name und Vorname aufzuführen. Der neue Lokomotivführer Hans Huber darf seine Arbeit also erst antreten, wenn zuvor sein Namensvetter in der Buchhaltung entlassen wird.

Was wäre eine bessere Eindeutigkeitsbedingung? Warum überhaupt Eindeutigkeitsbedingungen?

Es braucht also nicht für jede Objektklasse eine Eindeutigkeitsbedingung, nur damit ein Objekt identifizierbar ist. Es reicht, wenn das Datenobjekt, welches der effektiven Person entspricht, bei der Eingabe gefunden werden kann. Hierfür können auch Attribute, Beziehungen usw. herangezogen werden, ohne dass eine Kombination eindeutig sein muss.

Will man jedoch eine system-externe Identifikation, die zum Beispiel für Menschen verständlich ist, braucht es ein Attribut oder eine Kombination von Attributen, deren Werte über alle Objekte eindeutig sind. Häufig werden dafür künstliche Attribute geschaffen (Versicherungsnummer, Kundennummer, Artikelnummer, usw.)

Bei den Ilishornbahnen wurde dieses Problem auf simple Weise gelöst: Man hat einfach eine Personalnummer eingeführt. Stösst eine Person neu zu den Ilishornbahnen, wird ihr eine Nummer zugewiesen, die noch nicht vergeben ist.

Heikler würde die Sache, wenn die Klasse, durch die Personen beschrieben sind, nicht durch die Ilishornbahnen, sondern durch den nationalen Verband definiert wäre. Die Personalnummern aller Personen im Rahmen des Verbandes müssten dann eindeutig sein – auch wenn sie dezentral erfasst werden. Gäbe es zwei gleiche Nummern (z.B. eine bei den Ilishornbahnen, eine bei den Blaubergbahnen), wäre die Bedingung verletzt.

Eine Bahngesellschaft kann mehrere Namen tragen. Es soll aber pro Sprache nur eine einzige Bahnbezeichnung geben können; die Ilishornbahnen dürfen somit keinen zweiten deutschsprachigen Namen führen. Allerdings gilt diese Einschränkung nur lokal, also pro Gesellschaft: Schliesslich besitzen ja auch die Blaubergbahnen einen deutschsprachigen Namen. Über alle Gesellschaften hinweg gesehen gibt es also durchaus mehr als einen Namen in derselben Sprache. Die Sprache von Bahnbezeichnungen muss nur für eine bestimmte Bahngesellschaft eindeutig sein.

Wie aber erreicht man, dass die Kurzbezeichnungen der verschiedenen Bahnen nicht kollidieren? Sowohl die Blaubergbahnen wie die Buntbergbahnen möchten doch primär einmal BBB heissen. In INTERLIS 2 können Konsistenzbedingungen nicht nur für Objektklassen bzw. lokale Strukturelemente, sondern auch für Sichten (vgl. Kapitel 6.17, “Tarifbereiche interessieren nicht – Sichten”) formuliert werden. Mit einer bestimmten Sicht können aus Strukturelementen quasi eigenständige Objekte gemacht werden. Für diese kann dann wieder eine Eindeutigkeitsbedingung formuliert werden.

Im Gegensatz zu Zahnrad- und Standseilbahnen ist der Trasseeverlauf von Luftseilbahnen, Gondelbahnen, Skiliften usw. nicht einfach beliebig, sondern an die Tal- und Bergstation sowie an die Masten gebunden.

Diesen Zusammenhang möchte man ausdrücken. Die Linien von INTERLIS 2 verbinden jedoch Stützpunkte, die primär Koordinaten sind und keinen Bezug zu Modellobjekten wie etwa Masten aufweisen. Der Zusammenhang zwischen dem Trasseeverlauf und anderen Objekten kann aber als Konsistenzbedingung formuliert werden.

Mit der folgenden Definition muss sich jeder Punkt des Trasseeverlaufs auf die Lage eines Masts (Mast:Lage), die Lage der Talstation einer Bergbahn (Bergbahn:LageTalstation) oder (OR) die Lage der Bergstation einer Bergbahn (Bergbahn:LageBergstation) abstützen.

Solche Existenzbedingungen sind nicht nur im Zusammenhang mit Linien, sondern auch bei gewöhnlichen Attributen formulierbar. Konzeptuell können sie immer als eine schwache Form einer Beziehung betrachtet werden.

Bereits bei der Bergbahn selbst wurde eine Konsistenzbedingung formuliert: Der Trasseeverlauf muss bei der Talstation beginnen und bei der Bergstation enden. Oder anders gesagt, der erste Punkt des Trasseeverlaufs (Trassee → Segments[FIRST] → SegmentEndPoint) muss gleich der Lage der Talstation sein, und (AND) der letzte Punkt des Trasseeverlaufs (Trassee → Segments[LAST] → SegmentEndPoint) muss mit der Lage der Bergstation zusammenfallen.

Abschnitt 7.3 erläutert, wie Linien aufgebaut sind. Dort wird auch das Attribut SegmentEndPoint besprochen, das für den Endpunkt eines Liniensegments steht.

Was bedeutet eine solche Definition für allfällige Erweiterungen dieser Klasse?

Betriebsentscheide beziehen sich jeweils auf eine bestimmte Bergbahn. Entsprechend sind die beiden Klassen durch eine Assoziation verbunden.

Dennoch sind die Objekte der beiden Klassen recht unterschiedlich. Es braucht einiges, bis eine Bergbahn erstellt ist und bis sich irgendwelche Eigenschaften ändern. Solche Änderungen (und auch die der Billette) werden immer durch die Direktion beschlossen. Betriebsentscheide werden jedoch täglich durch den Betriebsleiter gefällt.

Noch extremer ist es mit den Zustandsmeldungen: Bei den wichtigeren Bergbahnen werden sie sogar automatisch alle zwanzig Minuten erzeugt. Zum Erfassen und Bearbeiten der Daten werden teilweise auch unterschiedliche Programmpakete eingesetzt. Diesen Sachverhalt möchte man im Konzept irgendwie darstellen.

Damit eröffnet sich die Möglichkeit, dass auf einem bestimmten Computersystem nicht alle Daten vorhanden sein müssen, oder dass bestimmte Themen nur gelesen, nie aber verändert werden.

Das Computersystem der Ilishornbahnen umfasst z.B. je einen Behälter für die Bergbahnen, die Billette und die verschiedenen betrieblichen Aspekte. Der nationale Verband führt auch je einen Behälter für die Bergbahnen und die Billette. Die Ilishornbahnen schicken dem Verband immer die Änderungen, die sich in den Behältern der Bergbahnen und der Billette ergeben haben. Die Blauhornbahnen und alle weiteren Bahngesellschaften schicken dem Verband ebenfalls die Änderungen oder periodisch eine Kopie ihrer Datenbehälter. Der Verband integriert die Daten dieser Behälter dann in die eigenen Behälter.

Dank der Gliederung der Modelle in verschiedene Themen können die Daten gezielt geliefert werden. Es brauchen nur die Behälter jener Themen übermittelt werden, die für den Empfänger relevant sind.

Wird eine Bergbahn abgebrochen, wird als Folge das Datenobjekt gelöscht. Die Änderung wird nun auch dem nationalen Verband mitgeteilt. Wenn dabei aber nur der Behälter der Bergbahnen übermittelt wird, entsteht beim nationalen Verband ein Widerspruch in den Daten: Es gibt noch Tarifbereiche, die mit der Bergbahn verbunden sind, obwohl diese gelöscht wurde. Offensichtlich sind Beziehungen, die über Themengrenzen hinweg gehen, besonders heikel.

In grafischen Darstellungen von Modellen sind solche Beziehungen relativ einfach erkennbar, wenn die Darstellung die Themen und die Beziehungen klar zeigt. In der textlichen Darstellung von INTERLIS 2 muss der Sachverhalt mit dem Schlüsselwort EXTERNAL gekennzeichnet werden. Sie sind zudem nur zulässig, wenn die Themen als voneinander abhängig deklariert wurden (DEPENDS ON). Gegenseitige Abhängigkeiten (auch indirekte) sind unzulässig.

Aber wie sollen Beziehungen über Themengrenzen vermieden werden, ohne als Folge einfach alles im selben Thema zu halten?

Die Beziehung zwischen Betriebsentscheid und Bergbahn, auf den er sich bezieht, lässt sich nun aber mal nicht vermeiden. Dennoch macht es Sinn, die Bergbahnen und die Betriebsentscheide in verschiedenen Themen zu halten. Und bei dieser Beziehung ist es auch kein Problem, dass die Dinge nicht zusammenpassen. Beide Themen und ihre zugehörigen Behälter werden ja durch die Ilishornbahnen nachgeführt. Vor allem bei schnelllebigen Objekten, die über Beziehungen in verschiedenen Themen angesprochen werden, sind Konflikte aber nicht immer auszuschliessen.

INTERLIS 2 legt dabei folgende Regelung fest:

Die erste Regel, wonach ein Behälter in sich korrekt sein muss, ist auch dann zu beachten, wenn ein Behälter aus irgendeinem Grund aufgeteilt wird.

Wenn im Rahmen der Modellierung von Sichten gesprochen wird, ist natürlich nicht die Aussicht vom Ilishorn mit dem schönen Blick auf das Krummhorn gemeint. Und doch gibt es eine Ähnlichkeit zwischen den beiden Arten von Sichten. Auf der topographischen Karte sind das Ilishorn, das Krummhorn und all die weiteren Berge, Täler und Dörfer eingezeichnet und dabei die Höhe mit Zahlen und Höhenschichtlinien verdeutlicht. Die Karte zeigt die Aussicht vom Ilishorn nicht direkt. Sie enthält aber die nötigen Angaben, aus denen geübte

Kartenleser die Aussicht vom Ilishorn ableiten. Auf Grund der Karte ist klar, dass der Spitz, der links hinter dem Krummhorn hervor schaut, der «Schwarze Zahn» ist.

In der Analogie entsprechen die Objektklassen, Strukturen und Beziehungen eines Modells der Karte. Sie sind ein sachgerechtes Abbild der Realität, ohne dass ein bestimmter Verwendungszweck vorgegeben ist. Die Sichten eines Modells entsprechen der Aussicht vom Ilishorn. Sie unterstützen einen bestimmten Verwendungszweck. Sie nehmen dazu auf die Grundlagen oder andere Sichten Bezug und formen sie so um, dass der Verwendungszweck möglichst gut unterstützt werden kann.

Aber warum sollen dann solche Sichten Bestandteil des Modells sein? Im Modell soll doch nicht vorweggenommen werden, ob die Aussicht quasi vom Ilishorn, dem Krummhorn, vom Schwarzen Zahn oder vom Sprudelbecken im Garten des Kurhauses Ilisbad aus genossen wird.

Vor allem für spezielle Konsistenzbedingungen (vgl. Kapitel 6.14.3, “Eindeutigkeitsbedingungen”) und für ableitbare Beziehungen (vgl. Kapitel 6.13.7, “Ableitbare Beziehungen”) machen Sichten auch im Bereich des Modells Sinn. Sichten sind aber auch nützlich, wenn die Daten für einen bestimmten Zweck in einer aufbereiteten Form geliefert werden müssen, wie das bei der Datenabgabe zuhanden des Ilistaler Webdienstes der Fall ist. INTERLIS 2 bietet zudem noch die Möglichkeit, Grafiken zu definieren. Die Grundlage für die Grafikdefinition bilden in vielen Fällen nicht die Originaldaten, sondern Sichten.

Die Sichten von INTERLIS sind mit den Sichten von Datenbank-Systemen vergleichbar.

Der detaillierte Trasseeverlauf interessiert vielleicht nicht, wohl aber die Länge. Bei Personen ist man manchmal eher am Alter als am Geburtsjahr interessiert. Diese Eigenschaften können aus anderen abgeleitet werden. Würden derartige «redundante» Eigenschaften als normale Daten erfasst, wäre die Gefahr sehr gross, dass sie nicht immer auf dem aktuellen Stand wären. Das Alter einer Person ändert sich schliesslich jedes Jahr!

Beispielsweise ist die Sicht «PersonMitAltersangabe» von der Objektklasse «Person» abgeleitet, der so genannten Basis. Eine einzelne PersonMitAltersangabe trägt dieselben Eigenschaften (ALL OF) mit genau denselben Werten wie die ursprüngliche Person. Zusätzlich fügt die Sicht aber noch eine weitere Eigenschaft «Alter» hinzu. Das Alter bestimmt sich (:=) aus der Differenz von Jahrgang und laufendem Jahr.

In diesem Beispiel gibt es für jedes Objekt der Basisklasse genau ein virtuelles Sicht-Objekt, also zu jeder Person eine entsprechende PersonMitAltersangabe.

Der nationale Tourismusverband hat eine abstrakte Klasse «Tarifbereich» definiert. Im Ilistal will man jedoch nicht einzeln aufzählen, welche Bahnen an welchem Tarifbereich teilnehmen. Stattdessen gibt es dort räumlich umgrenzte Tarifbereiche, die im Modell mit der Klasse «TarifbereichInGegend» beschrieben sind. Diese Klasse besitzt eine Eigenschaft «Gegend» für das geographisch umgrenzte Gültigkeitsgebiet.

Eine Bahn, deren Tal- und Bergstation innerhalb der Gegend eines solchen räumlichen Tarifbereichs liegt, akzeptiert automatisch dessen Billette.

Aber welche Bergbahn liegt nun konkret in der Gegend von welchem Tarifbereich? Auch diese Verbindung von Bergbahn und Tarifbereich kann mit einer Sicht abgeleitet werden.

Mit der Verbindung werden zunächst sämtliche Paare gebildet: Jedes Objekt der Klasse Bergbahn wird mit jedem Objekt der Klasse TarifbereichInGegend zu einem virtuellen Sichtobjekt verbunden.

Mit dem WHERE-Teil wird die Menge aller Sichtobjekte auf jene eingeschränkt, bei denen die Bedingungen erfüllt sind. Damit bleiben nur jene Paare aus Bergbahn Bb und Tarifbereich T übrig, wo Tal- und Bergstation von Bb im Gebiet von T liegt. In der obigen Abbildung erfüllen von den sechs möglichen Paaren (drei Bahnen x zwei Tarifbereiche) vier die Bedingung.

In einem letzten Schritt wird wie bei einer Projektion bestimmt, welche Eigenschaften die Sichtobjekte tragen sollen, und wie sich ihre Werte bestimmen. In der obigen INTERLIS-Definition dient hierzu der Teil nach dem Gleichheitszeichen.

Gibt es zu einer Bergbahn keinen Tarifbereich, kommt sie in der Sicht nicht vor. Mit einer besonderen Verbindung (so genannte «Outer Join») wird verlangt, dass auch dann ein Sichtobjekt entstehen soll, wenn zu einer Bergbahn kein Tarifbereich besteht. Für die konkrete Anwendung der Bergbahnen und Tarifbereiche macht dies allerdings kaum einen Sinn.

Möchte man ein Verzeichnis aller Koordinaten von Tal- und Bergstationen, steht dem die Tatsache entgegen, dass diese Koordinaten als einzelne Attribute der Bergbahnen aufbewahrt sind. Mit der Vereinigung (UNION) können sie aber zu einer Menge von gleichberechtigten Sichtobjekten zusammengefasst werden.

Die Menge der Sichtobjekte ist hier gleich der doppelten Menge der Bergbahnen. Einmal werden sie unter dem Aspekt Talstation, einmal unter dem Aspekt Bergstation ausgewertet. Das Attribut wird je nachdem gemäss dem Lageattribut von Tal- bzw. Bergstation gesetzt.

Zusammenfassung (AGGREGATION) und Aufschlüsselung (INSPECTION) haben mit Strukturattributen zu tun. Eine Zusammenfassung fasst Objekte, die bestimmte gleiche Eigenschaften aufweisen, zu einem einzigen Objekt zusammen. Im Rahmen des Sichtobjekts stehen die bisherigen Objekte als Elemente eines Strukturattributes zur Verfügung (vgl. Kapitel 6.17.3, “Schrittweiser Aufbau von Sichten”). Eine Aufschlüsselung sorgt umgekehrt dafür, dass aus Strukturelementen eigenständige Sichtobjekte werden (vgl. Kapitel 6.14.3, “Eindeutigkeitsbedingungen”).

Für die Billettkontrolle muss man bei jeder Bergbahn wissen, welche Billettarten gültig sind. Man möchte doch ein Verzeichnis aller Bergbahnen, in dem bei jeder Bergbahn die gültigen Billettarten aufgeführt sind. Losgelöst von den Basisdaten möchte man etwa folgendes Modell definieren:

Aber wie kann das nun aus den Originaldaten abgeleitet werden? Das ist gar nicht so einfach. Einer Bergbahn können mehrere Tarifbereiche zugeordnet sein, welchen ihrerseits wieder mehrere Billettarten zugeordnet sind. Zudem gibt es Tarifbereiche, die alle Bergbahnen einer Gegend umfassen.

Der letzte Aspekt ist zum Glück schon erledigt, weil es eine abstrakte Beziehung zwischen Bergbahn und Tarifbereich gibt, die «Gültigkeit». Sie wird einerseits durch eine explizite Beziehung zwischen den beiden Klassen realisiert («GültigkeitExplizit»). Andererseits kann von der Sicht «BergbahnenInGegend» abgeleitet werden, welche Bahnen aufgrund ihrer Lage die Billette eines Tarifbereichs anerkennen.

Auf dieser Basis kann eine Sicht definiert werden, welche die Bergbahnen mit den Billettarten verbindet:

Diese Verbindung kombiniert Bergbahn und Billettart. Sie berücksichtigt dabei die Gültigkeitsbeziehung und dass einer Billettart ein Tarifbereich zugeordnet ist, der mit jenem der Gültigkeits-Beziehung übereinstimmen muss. Damit ist das Ziel schon fast erreicht. Die zulässigen Kombinationen von Bergbahn und Billettart sind als Sichtobjekte verfügbar. Nur möchte man sie noch pro Bergbahn zusammenfassen:

Eine solche Zusammenfassung erfolgt mit einer Aggregation. Damit werden alle Objekte der Basissicht, die eine bestimmte Bedingung erfüllen (nämlich dass sie zur gleichen Bergbahn gehören), zu einem Sichtobjekt zusammengefasst. Die Menge aller ursprünglichen Sichtobjekte, die zu einem Ganzen zusammengefasst wurde, steht dabei für Strukturattribute zur Verfügung (AGGREGATES).

Bereits der nationale Verband hat die Sicht definiert, die alle gültigen Billettarten für jede Bergbahn aufführt (Sicht «AufBergbahnGueltigeBillettart», siehe oben). Die Ilistaler wollen diese Sicht auch benutzen. Sie möchten aber auch in dieser Sicht das Attribut Trasseeverlauf einbeziehen, das sie in der eigenen Erweiterung der Klasse Bergbahn definiert haben.

Mit der Definition einer zusätzlichen Basis (muss eine Erweiterung einer bisherigen Basis sein) stehen deren Attribute zur Verfügung. Beruht ein Sichtobjekt nicht auf dieser Erweiterung (ist es also keine IhBBergbahn), ist das Attribut undefiniert.