Geodatenbanksysteme in Theorie und Praxis - VDE

24
1 Einleitung
die Aufgabe der Primärschlüssel übernehmen. Zeilen der Tabelle (also die Objekte) sind über
einen Referenztyp (REF) referenzierbar, die damit die herkömmlichen Fremdschlüssel ersetzen. Abbildung 1.8 zeigt ein entsprechendes Beispiel.
Die zweite Möglichkeit, mit Objekten zu arbeiten, ist der Einsatz von Klassen als Datentyp
von Attributen. Ein Attributwert ist in diesem Fall ein sogenanntes Spaltenobjekt. Die Abbildung 1.9 skizziert diese Möglichkeit.
gkz
DECIMAL(8)
name
VARCHAR(50)
3403000
Oldenburg
...
...
...
fläche
POLYGON
( 1234, 8,
(8.214, 53.087,
8.305, 53.148,
8.173, 53.184,
8.214, 53.087))
Typ des Attributs = Klasse
Attributwert = Spaltenobjekt
...
Abb. 1.9: Spaltenobjekt als Attributwert
Objektsichten (auch typisierte Sichten genannt) erlauben es, die Tupel einer Relation als
Objekte aufzufassen. Damit können Datensätze in herkömmlichen Tabellen wie Objekte
gehandhabt und mit Methoden versehen werden.
1.5
Geodatenbanksysteme
Datenbanksysteme, die die Speicherung von Geodaten und die Bearbeitung räumlicher
Anfragen in hinreichender Weise unterstützen, werden räumliche Datenbanksysteme oder
auch Geodatenbanksysteme (engl. Spatial Database Systems) genannt [49][155][169][197].
In einem Geodatenbanksystem werden Geoobjekte (engl. (Geographic) Features oder Spatial Objects) gespeichert. Ein Geoobjekt besitzt verschiedene Eigenschaften, darunter ein
ausgezeichnetes Geometrieattribut, auf das sich räumliche Anfragen und Operationen beziehen6. Es dient der Beschreibung eines Objektes oder Phänomens der realen Welt, das einen
Lagebezug zur Erde aufweist.
Im Folgenden werden die wesentlichen Anforderungen an Geodatenbanksysteme erörtert.
Auf dieser Basis kann dann betrachtet werden, ob und wie Geoobjekte von relationalen und
objektrelationalen Datenbanksystemen verwaltet werden können.
6
Aufgrund dieser Definition ist es möglich, geometrische Aussagen auf ein Geoobjekt zu beziehen. So
bezeichnet zum Beispiel „Schnitt mit dem Geoobjekt“ den Schnitt mit dem ausgezeichneten Geometrieattribut des Geoobjektes.
1.5 Geodatenbanksysteme
1.5.1
25
Anforderungen an Geodatenbanksysteme
Ein Geodatenbanksystem muss die erforderlichen Datentypen für Geoobjekte bereitstellen
und hinreichend gut unterstützen. Eine solche Forderung umfasst eine Reihe von Zielen:
• Das Geodatenbanksystem muss geometrische Datentypen anbieten, die Geometrieattribute geeignet repräsentieren können. So werden zum Beispiel Datentypen für Punkte,
Streckenzüge, Polygone mit Löchern und Mengen von Polygonen benötigt.
• Ein Geodatenbanksystem muss Methoden für die geometrischen Datentypen bereitstellen, die die Ausführung geometrischer Funktionen erlauben. Solche Funktionen berechnen zum Beispiel den Schnitt zwischen zwei Flächen oder bestimmen die Länge eines
Streckenzuges. Sie können vom Benutzer in der Anfragesprache des Datenbanksystems
verwendet werden. Dies kann entweder in der Anfragebedingung erfolgen, um die Daten
aus einem bestimmten Gebiet zu bestimmen, oder bezüglich der Datensätze, die eine
nichtgeometrische Anfragebedingung erfüllen, um beispielsweise deren Fläche zu berechnen.
• Enthält eine Anfragebedingung eine oder mehrere Operationen, die einen Raumbezug
aufweisen, wird die Anfrage auf eine oder eine Folge von räumlichen Basisanfragen
zurückgeführt. Beispiele hierfür sind die Punktanfrage, die alle Objekte bestimmt, deren
Geometrie einen Anfragepunkt enthält, oder die Rechteckanfrage, die zu einem gegebenen Anfragerechteck alle Geoobjekte bestimmt, die das Rechteck schneiden. Die Verarbeitung der räumlichen Basisanfragen und auch anderer geometrischer Operationen
muss hinreichend effizient erfolgen. Dazu sind geeignete Algorithmen und Datenstrukturen erforderlich. Diese Forderung umfasst zum Beispiel, dass Geoobjekte mit Hilfe
räumlicher Indexe vom Datenbankmanagementsystem verwaltet werden und dass effiziente Algorithmen für die Lösung geometrischer Fragestellungen implementiert sind.
• Die geometrischen Datentypen und Funktionen müssen so spezifiziert sein, dass sie im
Sinne eines offenen GIS von Anwendungen außerhalb des Geodatenbanksystems problemlos genutzt werden können. Um eine Interoperabilität zwischen verschiedenen
Applikationen zu erreichen, haben die Datenmodelle allgemein anerkannte Standards
einzuhalten. Damit wird die Integration von Geodaten in die herkömmliche IT-Infrastruktur einer Organisation und deren Geschäftsprozesse ermöglicht.
1.5.2
Speicherung von Geodaten in relationalen Datenbanken
Nachdem wir die wichtigsten Anforderungen an Geodatenbanksysteme erörtert haben, soll
nun die Verwaltung und Speicherung von Geodaten in herkömmlichen Datenbanken näher
betrachtet werden. Betrachten wir dazu das Bundesland Niedersachsen in Abbildung 1.10. Es
besteht aus dem Festland und den Ostfriesischen Inseln, also aus mehreren Polygonen. Im
Festland befindet sich als Aussparung das Gebiet der Gemeinde Bremen, die zusammen mit
Bremerhaven das Bundesland Bremen bildet. Damit kann die Geometrie von Niedersachsen
geeignet über eine Menge von Polygonen mit Löchern beschrieben werden, die auch Multipolygon genannt wird. Ein solches Multipolygon kann offenkundig nicht als atomares Attribut in einer relationalen Datenbank repräsentiert werden.
26
1 Einleitung
Ostfrie
In
sische
seln
Bremerhaven
Bremen
Niedersachsen
Abb. 1.10: Das Bundesland Niedersachsen
1.5.2.1
Zerlegung von geometrischen Attributen
Eine Lösung, um ein Multipolygon in einer relationalen Datenbank zu speichern, ist dessen
Aufteilung auf mehrere Tabellen. Diese Tabellen sind dann über Beziehungen miteinander
verbunden. Eine solche Zerlegung kann wie folgt aussehen:
• Ein Multipolygon besteht aus mehreren Polygonen; zwischen diesen beiden Relationen
liegt also eine 1-zu-n-Beziehung vor.
• Ein Polygon besteht aus einem äußeren Ring und mehreren inneren Ringen. Damit haben
wir eine 1-zu-1-Beziehung und eine 1-zu-n-Beziehung, die wir zu einer 1-zu-n-Beziehung zusammenfassen können, wenn wir zusätzlich die Art des Rings in der entsprechenden Tabelle vermerken.
• Ein Ring besteht aus Strecken; diese können durch eine Folge von Punkten repräsentiert
werden. Zwischen Ringen und Punkten liegt somit eine sortierte 1-zu-n-Beziehung vor.
Ein mögliches Datenmodell ist in Abbildung 1.11 dargestellt. Die Sortierung der Punkte wird
über das Attribut pos in „Punkte“ umgesetzt.
Bundesländer
num
name
hauptstadt
gebiet
1
1..*
MultiPolygone
1
num
darstellung
1..*
Polygone
num
multipol
1
1..*
Ringe
num
art
pol
Abb. 1.11: Beziehungsdiagramm für Multipolygone
Punkte
num
3..*
ring
1
pos
laenge
breite
1.5 Geodatenbanksysteme
27
Man beachte, dass dieses Modell nicht berücksichtigt, dass der innere Ring im Festland von
Niedersachsen gleichzeitig der äußere Ring der Gemeinde Bremen ist. Die Gemeinde Bremerhaven als zweiter Teil des Bundeslandes Bremen hat wiederum Teile seiner Grenze mit
Niedersachsen gemein. Wollte man solche topologischen Eigenschaften berücksichtigen,
entstände ein weitaus komplexeres Datenmodell, bei dem u.a. die 1-zu-n-Beziehungen durch
n-zu-m-Beziehungen ersetzt werden müssten.
Das dargestellte Datenmodell weist eine Reihe von Nachteilen auf. Möchte man für ein Bundesland zum Beispiel (in geordneter Reihenfolge) auf dessen Polygonpunkte zugreifen, ist
dafür die Ausführung einer Verbundoperation über fünf Tabellen mit mehreren Sortierkriterien erforderlich:
SELECT Punkte.laenge, Punkte.breite, Ringe.num, Ringe.art
FROM Bundeslaender, MultiPolygone, Polygone, Ringe, Punkte
WHERE Bundeslaender.name = 'Niedersachsen' AND
Bundeslaender.gebiet = MultiPolygone.num AND
MultiPolygone.num = Polygone.multipol AND
Polygone.num = Ringe.pol AND
Ringe.num = Punkte.ring
ORDER BY MultiPolygone.num, Polygone.num, Ringe.num, Punkte.pos;
Informationen, die eigentlich zusammengehören, verteilen sich auf mehrere Tabellen. Das
Zusammenführen dieser Daten ist – insbesondere bei großen Datenbeständen oder noch
komplexeren Datenmodellen – recht aufwändig.
Eine solche Anfrage verstößt auch gegen das Prinzip der Datenunabhängigkeit. So erfordert
eine Änderung des Datenmodells auch eine Anpassung der dargestellten Anfrage. Eine solche Änderung wäre beispielsweise für den Fall erforderlich, dass Punkte nicht nur zur
Beschreibung des Randes, sondern auch für andere Zwecke, wie die Speicherung der Lage
des Gemeindezentrums, verwendet werden sollen.
Die Formulierung der dargestellten Anfrage ist recht benutzerunfreundlich. Räumliche
Basisanfragen wie die Punktanfrage lassen sich mit der herkömmlichen Funktionalität von
SQL nicht formulieren. Da die Datensätze von relationalen Systemen nicht nach räumlichen
Kriterien verwaltet und gespeichert werden können, lassen sich räumliche Basisanfragen
auch nicht effizient bearbeiten.
Die Zerlegung der Geometrie ist somit weder funktional noch von der Effizienz her eine
befriedigende Lösung.
1.5.2.2
Speicherung der geometrischen Attribute in Dateien
Eine Alternative, die ältere Geoinformationssysteme oft aufweisen, stellt die getrennte Speicherung geometrischer und alphanumerischer (d.h. nichtgeometrischer Sach-)Attribute dar.
Während die alphanumerischen Attribute in einer relationalen Datenbank gespeichert sind,
werden die geometrischen Attribute in einem GIS-spezifischen Datenformat in Dateien
abgelegt. Wie in Abbildung 1.12 angedeutet, erfolgt die Kopplung zwischen den beiden Teilen eines Datensatzes meist über einen gemeinsamen Schlüssel.
Gegen eine solche Lösung spricht insbesondere, dass damit alle in Abschnitt 1.2.2 aufgeführten Vorteile von Datenbanksystemen für die geometrischen Attribute verloren gehen. Eine
Nutzung der Geodaten außerhalb des spezifischen Geoinformationssystems wird vereitelt, da
das Datenformat in der Regel proprietär ist und sich bei einem Versionswechsel verändern
28
1 Einleitung
kann. Auf Seiten des Systembetriebs stößt es auch selten auf Begeisterung, dass neben dem
Datenbanksystem eine weitere Datenhaltungskomponente existiert, die ggf. zu erhöhten
Betriebskosten führt.
Geoinformationssystem
Oldenburg
3403000
155908
relationale Datenbank
3403000
Datei
Abb. 1.12: Getrennte Speicherung von Sach- und Geodaten
Aufgrund der aufgeführten Nachteile können es sich die aktuell auf dem Markt befindlichen
Geoinformationssysteme nicht mehr leisten, ausschließlich diese Lösung zu unterstützen.
1.5.2.3
Speicherung der geometrischen Attribute als BLOBs
Für Daten, die sich mit den Wertebereichen des relationalen Datenbankmodells nicht
beschreiben lassen – zum Beispiel Rasterbilder oder andere Multimediaobjekte wie Audiodaten oder Videos – bieten relationale Datenbanksysteme zusätzliche Datentypen an. Hier
sind insbesondere Binary Large Objects (BLOBs) zu nennen. In einem BLOB können beliebige Binärdaten gespeichert werden. Damit besteht die Möglichkeit, Geometrien binär in der
Datenbank abzulegen.
Es gibt eine Reihe von Vorteilen bei der Verwendung von BLOBs. Im Gegensatz zu der zerlegten Speicherung können alle relevanten Informationen einer Geometrie zusammengehalten werden und müssen nicht aufwändig zusammengesetzt werden. Auch ist eine integrierte
Speicherung aller Attribute eines Objektes unter Verwendung nur eines Systems möglich.
Bestimmte Konzepte von Datenbanksystemen wie Zugriffskontrolle, gesicherter Mehrbenutzerbetrieb und Recovery können auf BLOBs angewendet werden. Aus diesen Gründen bieten viele Geoinformationssysteme die Möglichkeit, geometrische Attribute über BLOBs in
einer relationalen Datenbank zu speichern.
Allerdings weist diese Lösung auch Nachteile auf. Für das Datenbanksystem ist ein BLOB
eine Folge von Binärinformationen, die es nicht interpretieren kann. Dies hat eine Reihe von
Konsequenzen:
• Da das Datenbankmanagementsystem die Semantik (d.h. die Bedeutung) der Binärdaten
nicht kennt, können keine Mechanismen zur effizienten Anfragebearbeitung und -optimierung angewendet werden. Aus den gleichen Gründen ist es auch nicht möglich, geometrische Operationen zu verarbeiten oder durch die Anfragesprache zu unterstützen;
dies muss außerhalb des Datenbanksystems erfolgen. Für die Überprüfung von Beziehungen innerhalb eines Geometrieattributs – um z.B. zu bestimmen, ob die Löcher eines
Polygons sich tatsächlich im Polygon befinden – oder auch zwischen verschiedenen
Geometrien stehen dem Datenbanksystem keine Mittel zur Verfügung. Dadurch kann es
die Konsistenz der Geodaten nicht sicherstellen.
1.5 Geodatenbanksysteme
29
• BLOBs sind für anderweitige Programme nicht ohne weiteres interpretierbar; ein
Anwendungsprogramm ist auf Nutzung des GIS angewiesen oder muss entsprechend
programmierte Komponenten besitzen. Dies widerspricht aber der Idee eines offenen
Systems. Diese Situation wird in Abbildung 1.13 skizziert, wo das Anwendungsprogramm 3 die Geodaten letztendlich nicht verarbeiten kann.
Anwendungsprogramm 2
Anwendungsprogramm 1
GIS
Geometrieverarbeitung
Anwendungsprogramm 3
Geometrieverarbeitung
???
Datenbankmanagementsystem
Geodaten 10011010
in BLOBs 11011101
DBS
Abb. 1.13: Verwendung von Binary Large Objects
Zusammenfassend kann festgestellt werden, dass der Einsatz von Binary Large Objects ein
Fortschritt gegenüber den beiden zuvor vorgestellten Ansätzen ist. Befriedigend ist er allerdings nicht.
1.5.3
Objektrelationale Geodatenbanksysteme
Eine Lösung des dargestellten Problems kann der Einsatz von objektrelationalen Datenbanksystemen als Basis für Geodatenbanken darstellen. In diesem Fall sprechen wir von objektrelationalen Geodatenbanksystemen.
1.5.3.1
Eignung von objektrelationalen Datenbanksystemen
Zunächst soll die Eignung von objektrelationalen Datenbanksystemen zur Verwaltung und
Speicherung von Geodaten näher betrachtet werden.
• Geodaten erfordern geometrische Datentypen (engl. Spatial Datatypes), die eine variable und komplexe Struktur aufweisen. Entsprechende Klassen können mit Hilfe des
objektrelationalen Datenbankmodells definiert werden. Ein objektrelationales Geodatenbanksystem sollte bereits einen hinreichenden Satz von vordefinierten geometrischen
Datentypen anbieten.
• Geodatenbanksysteme benötigen die Bereitstellung geeigneter geometrischer Funktionen. In objektrelationalen Datenbanksystemen können entsprechende Methoden für
die Geometrieklassen vereinbart werden. In einem objektrelationalen Geodatenbanksystem sollten diese Methoden für die geometrischen Datentypen bereits implementiert
sein.
30
1 Einleitung
• Wenn dem Datenbanksystem die Struktur und die Bedeutung der geometrischen Datentypen bekannt sind, kann dies prinzipiell auch bei der Anfragebearbeitung und -optimierung berücksichtigt werden. Für die räumlichen Basisanfragen bedeutet dies, dass das
Datenbanksystem effizient die Datensätze auswählt, die räumliche Anfragebedingungen
erfüllen. Dies ist keine triviale Aufgabe und erfordert das Einbinden neuer Algorithmen
und Datenstrukturen auch in tiefere Schichten des Datenbankmanagementsystems.
Objektrelationale Datenbanksysteme stellen dazu entsprechende Erweiterungsmöglichkeiten zur Verfügung. Je nach Datenbankhersteller heißen solche Erweiterungskomponenten „Data Cartridge“ (Oracle), „DataBlade“ (IBM Informix) oder „Data Extender“
(IBM DB2). In einem objektrelationalen Geodatenbanksystem sollte eine solche Erweiterung bereits vorhanden sein, da dem Anwender eines Datenbanksystems die Erstellung
einer entsprechenden Erweiterungskomponente kaum zuzumuten ist.
Zusammenfassend lässt sich feststellen, dass objektrelationale Datenbanksysteme als Geodatenbanksysteme geeignet sind. Für eine einfache Nutzung müssen durch eine entsprechende
Erweiterungskomponente die notwendigen Klassen mit den entsprechenden Methoden und
Verfahren zur Anfragebearbeitung und -optimierung bereitgestellt werden. Diese Forderung
macht allerdings auch ein Problem dieses Ansatzes deutlich. Da die Erweiterungskomponenten je nach Datenbankhersteller unterschiedlich aufgebaut sind, begibt man sich bei deren
Nutzung in Abhängigkeit von einem bestimmten Datenbanksystem. Diese Problematik kann
ggf. dadurch entschärft werden, dass das objektrelationale Geodatenbanksystem allgemein
anerkannte Standards einhält.
1.5.3.2
Objektrelationale Geodatenbanksysteme
IBM Informix und DB2
Die Firma Informix hat im Jahr 1996 die Firma Illustra Information Technologies übernommen, die 1992 von Michael Stonebraker, einem damaligen Professor der University of
California Berkeley, gegründet worden war. Das Illustra-System war ein objektrelationales
Datenbanksystem, das komplexe Objekte verwalten konnte und über sogenannte DataBlades
erweiterbar war. Informix übernahm diese Technologie in sein Datenbanksystem, den Informix Dynamic Server. Im Juli 2001 hat IBM die Firma Informix aufgekauft.
Zur Verwaltung von Geodaten werden von IBM Informix das Spatial DataBlade [65] und
das Geodetic DataBlade [64] angeboten. Das Spatial DataBlade stellt geometrische Datentypen und Methoden zur Verfügung, die den Vorgaben des Open Geospatial Consortiums
(OGC) genügen; dieses OGC-Datenmodell wird Abschnitt 3.4 näher vorgestellt. Daneben
gibt es zusätzliche Funktionen, die z.B. Geometrien in der Geography Markup Language
(GML) oder als ESRI Shapefiles bereitstellen oder auch Generalisierungen und Transformationen durchführen. Das Geodetic DataBlade, das nicht OGC-konform ist, unterstützt geografische Koordinaten, so dass für diese metrische Längen- und Flächenangaben berechnet
werden. Im Spatial DataBlade ist dazu eine Transformation in entsprechend projizierte Koordinaten erforderlich (vgl. Abschnitt 3.6). Zur Unterstützung räumlicher Basisanfragen setzen
beide DataBlades räumliche Indexe ein.
Das Gegenstück zum Spatial DataBlade ist für das IBM-Datenbanksystem DB2 der DB2
Spatial Extender [63]. Auch der DB2 Spatial Extender bietet OGC-konforme geometrische
Datentypen und Methoden. Räumliche Anfragen werden durch eine hierarchische Gitter-
1.5 Geodatenbanksysteme
31
struktur unterstützt. In Analogie zum Geodetic DataBlade und in Ergänzung zum Spatial
Extender bietet IBM DB2 das Geodetic Data Management Feature, das Voronoi-Diagramme als räumliche Indexe einsetzt.
Microsoft SQL Server
Für den SQL Server 2008 hat Microsoft die Unterstützung von OGC-konformen geometrischen Datentypen angekündigt [110]. Neben projizierten Koordinaten sollen auch geografische Koordinatensysteme unterstützt werden. Für eine effiziente Anfragebearbeitung steht
ein räumlicher Index zur Verfügung. Ein Im- und Export von GML soll möglich sein.
Open-Source-Datenbanksysteme
Im Bereich der Open-Source-Bewegung ist das freie, objektrelationale Datenbanksystem
PostgreSQL zu erwähnen. Auch PostgreSQL hat seinen Ursprung bei Michael Stonebraker:
es ist eine Weiterentwicklung des 1993 beendeten Berkeley POSTGRES Project.
PostgreSQL unterstützt den R-Baum (vgl. Abschnitt 6.5) als räumlichen Index und stellt
einige geometrische Datentypen bereit, die allerdings nicht der OGC-Spezifikation genügen
[149]. Dies wird erst durch die Erweiterung PostGIS [151] erreicht, die auf PostgreSQL aufsetzt. PostGIS ist ein voll funktionsfähiges Geodatenbanksystem, das den OGC-Konformitätstests genügt. In Ergänzung werden u.a. GML, Koordinatentransformationen und geometrische Aggregatfunktionen unterstützt. Die räumliche Indexierung erfolgt über den entsprechend angepassten GiST-Index [56] von PostgreSQL.
MySQL als weiteres Open-Source-System ist ein relationales Datenbanksystem ohne objektrelationale Erweiterungen. Nichtsdestotrotz hat MySQL seit der Version 4.1 geometrische
Datentypen gemäß dem OGC-Datenmodell „eingebaut“ [111]. Als räumlicher Index wird ein
R-Baum mit quadratischem Split-Algorithmus verwendet (vgl. Abschnitt 6.5.1.2), wobei
Anfragebedingungen nur anhand der minimal umgebenden Rechtecke und nicht auf Grundlage der exakten Geometrie ausgewertet werden [24].
Oracle
In diesem Buch werden wir die Umsetzung der Grundlagen von Geodatenbanksystemen
anhand von Oracle Spatial betrachten. Mitte der 90er-Jahre entstand Oracle Multidimension
(MD) zur Speicherung mehrdimensionaler Daten. Die spätere Umbenennung in Oracle
Spatial Data Option (SDO), die für die Version 7 der Oracle Enterprise Edition verfügbar
war, zeigt eine geänderte Zielrichtung: die Unterstützung zweidimensionaler Geodaten. Mit
der Einführung objektrelationaler Erweiterungskomponenten in der Version 8.0 von Oracle
erfolgte eine erneute Umbenennung in Oracle Spatial Cartridge, ohne dass damit eine geänderte Funktionalität verbunden war. Mit dem Release 8.1.5 erfolgte die (bislang) letzte
Umbenennung in Oracle Spatial. Seitdem ist es in Oracle möglich, Geodaten objektrelational
zu speichern. Das Release 8.1.7 brachte einige funktionale Erweiterungen. Weitere Ergänzungen – so die Unterstützung geografischer Koordinatensysteme – erfolgten mit der Version 9 (Release 9.0.1 und 9.2). Oracle 10g erschien im Jahr 2004. Seit dieser Version wird die
Speicherung der Topologie und von georeferenzierten Rasterdaten unterstützt. Das Release
10.2, das im Juli 2005 veröffentlicht wurde, erlaubt den Einsatz von EPSG-Koordinatensystemen. Oracle 11g ist seit August 2007 verfügbar und enthält Neuerungen, die u.a. die Speicherung und Anfrage von 3D-Geodaten betreffen.
32
1 Einleitung
Die Darstellung von Oracle Spatial in den nachfolgenden Kapiteln basiert auf der OracleVersion 11g, wobei aber auch auf Unterschiede zu den Vorversionen 9 und 10 eingegangen
wird. Oracle Spatial gliedert sich in einen Kern (Oracle Spatial Locator), der von allen Oracle-Varianten (außer der „Lite Version“) unterstützt wird, und einer zusätzlich erhältlichen
Spatial Option mit zusätzlicher Funktionalität. Auf diese Unterscheidung wird im Folgenden
nicht weiter eingegangen.