PDF file - IDB - Universität Bonn

RHEINISCHE FRIEDRICH-WILHELMS-UNIVERSITÄT BONN
INSTITUT FÜR INFORMATIK III
Diplomarbeit
Interaktive Manipulation raumbezogener
Datenbanken über 2D-Bildschirmkarten
Vorgelegt von
Zheyi Ji
Bonn, Mai 2005
Betreuer: Prof. Dr. Rainer Manthey
Inhaltsverzeichnis
1.
2.
Einleitung ........................................................................................................................ 3
Grundlagen relationaler Datenbanken............................................................................ 5
2.1 Datenbankentwurf ................................................................................................. 5
2.2 Das Entity-Relationship-Modell ............................................................................. 8
2.3 Das relationale Modell ......................................................................................... 10
2.4 Normalisierung .................................................................................................... 13
2.5 Grundlagen der SQL ........................................................................................... 15
2.6 Microsoft Access.................................................................................................. 19
3. Visual Basic und Microsoft .NET................................................................................... 22
3.1 Microsoft .Net Framework.................................................................................... 22
3.1.1 Struktur des Microsoft .NET Frameworks.................................................. 23
3.1.2 Kompilierung der .NET-Programme .......................................................... 24
3.2 ADO .NET............................................................................................................ 26
3.3 Visual Basic ......................................................................................................... 28
3.4 Unterschiede zwischen VB und VB .NET ............................................................ 32
4. Geo-Informationssysteme............................................................................................. 33
4.1 Geoobjekte .......................................................................................................... 33
4.2 Modellierung von Geoobjekten ............................................................................ 35
4.3 Präsentation von Geoobjekten ............................................................................ 37
4.4 Kartenprojektion .................................................................................................. 38
5. Modellierung von Geoobjekten in VisMap .................................................................... 41
5.1 Primärmodell der Geoobjekte .............................................................................. 42
5.2 Präsentationsmodell der Geoobjekte................................................................... 46
6. VisMap .......................................................................................................................... 47
6.1 Systemarchitektur................................................................................................ 47
6.2 GUI ...................................................................................................................... 49
6.2.1 Layout der Bildschirmkarte........................................................................ 49
6.2.2 Steuerelemente des Hauptfensters ........................................................... 50
6.2.3 Konfiguration der Bildschirmkarte ............................................................. 52
6.3 Interaktion mit VisMap ......................................................................................... 53
6.3.1 Normalmodus ............................................................................................ 53
6.3.2 Einfügemodus ........................................................................................... 57
6.4 Fenstermanager .................................................................................................. 60
6.4.1 Ereignisinterpretation ................................................................................ 60
6.4.2 Kommunikation mit der Datenbank ........................................................... 62
6.4.3 Pfadsuche ................................................................................................. 66
6.5 Kartengenerator................................................................................................... 67
7. Zusammenfassung und Ausblick .................................................................................. 71
Literaturverzeichnis............................................................................................................... 73
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Ich erkläre hiermit, dass ich die vorliegende Arbeit selbständig verfasst und keine anderen als
die angegebenen Quellen und Hilfsmittel verwendet habe.
Bonn, Mai 2005
2
1. Einleitung
Seit Jahrtausenden versuchen die Menschen, visuelle Darstellungen räumlicher Objekte zu
gewinnen. In der alten Zeit lassen sich die Informationen nur analog darstellen, es findet
meistens in Form von Karten statt. Erst seit der Erfindung des Computers ist es möglich,
raumbezogene Informationen in digitaler Form zu speichern. Dies ist ein großer Fortschritt, da
man in digitaler Form Informationen leichter darstellen, verarbeiten und verbreiten kann.
Die Anwendungsmöglichkeiten rechnergestützter Informationssysteme für raumbezogene
Daten sind vielfältig. In der Wirtschaft können sie zur Standortplanung, Ver-/Entsorgung oder
Verkehrsleitung eingesetzt werden. In der wissenschaftlichen Forschungen wie zum Beispiel
Geographie, Klimatologie und Archäologie spielen sie ebenfalls eine wichtige Rolle. Im Alltagsleben werden sie häufig benutzt für GPS-Navigation, Routenplaner und Stadtpläne. In
dieser Diplomarbeit sowie in ihren zwei Vorgängerarbeiten wird ein 2D-Bildschirmkarten-System für die automatische Kartenerstellung und interaktive Manipulation raumbezogener Daten entwickelt, das für Landkarten, Stadtpläne oder Routenplaner benutzt werden
kann. Es gibt schon zahlreiche kommerzielle GIS-Anwendungen auf dem Markt, die ebenfalls
Bildschirmkarten als Schnittstellen anbieten. Die Bildschirmkarten solcher Anwendungen basieren aber meist auf eingescannten analogen Karten, die nicht automatisch vom Programm
erzeugt worden sind. Es ist bei solchen Systemen in der Regel auch nicht möglich, die Geoobjekte in der Datenbank direkt in der Bildschirmkarte zu bearbeiten. In dieser Arbeit wird die
Bildschirmkarte dagegen automatisch von einem VB-Programm erzeugt, und die Geoobjekte
in der Datenbank können durch Mausklicks auf die Bildschirmkarte leicht bearbeitet werden.
In der Diplomarbeit von Lutz Kunicke [Ku03] sind manche primitive Operationen wie zum
Beispiel das Einfügen der Linienzüge und der Vielecke nicht implementiert worden. Das DataMap-System von Ernest Hadziresic [Ha04] ist eine verbesserte Version von VirtualMap-Systems, bietet aber keine Suchfunktionen, und das Bedienungsinterface ist nicht
ausgereift. Beide Systeme nutzen nur einfache Datenbankstrukturen und ihnen fehlt ein allgemeines Konzept der Modellierung von Geoobjekten. Das Hauptziel dieser Diplomarbeit ist
es, eine technische, funktionale und konzeptuelle Verbesserung der zwei Vorgängerarbeiten
anzubieten. Dazu wird das VisMap-System entwickelt, das aus einer Datenbank und einem
VB-Programm besteht. Die Datenbank enthält sämtliche Informationen über die räumlichen
Objekte der jeweiligen Anwendung. Das anwendungsunabhängige VB-Programm soll in der
Lage sein, die für eine Visualisierung der Geoobjekte relevanten Informationen aus der Datenbank auszulesen, eine interaktive graphische Darstellung dieser räumlichen Objekte auf
dem Bildschirm zu erzeugen und ein benutzerfreundliches graphisches Interface anzubieten,
um die Informationen in der Datenbank zu manipulieren. VisMap ist kein System für eine bestimmte Anwendung, sondern es kann mit einer leichten Anpassungsarbeit in unterschiedlichen Anwendungsgebieten eingesetzt werden. Als Anwendungsbeispiel werden in dieser
Diplomarbeit das Eisenbahn- und Autobahnnetz Deutschlands benutzt, die Koordinatendaten
stammen von http://opengeodb.sourceforge.net/.
3
Statt Visual Basic 6, das die zwei Vorgängerarbeiten benutzt haben, wird in dieser Diplomarbeit eine echte objektorientierte Erweiterung dieser Sprache verwendet, nämlich Visual
Basic .NET, was zahlreiche Vorteile mit sich bringt. Damit das VB-Programm mit der Datenbank kommunizieren und die Daten in der Datenbank manipulieren kann, wird die neue Version von ADO, ADO .NET, verwendet. Das zugrunde liegende Datenbanksystem ist wie
bisher Microsoft Access, um den Administrationsaufwand der Datenbank zu verringern. Dank
der vielfältigen Daten-Provider von ADO .NET kann das Programm später sehr einfach umwandelt werden, damit es auch z.B. mit Microsoft SQL Server, ORACLE und anderen
ODBC-kompatible Datenbanksystemen arbeiten kann.
Im Kapitel 2 werden die Grundlagen von Datenbanken erläutet. Dabei werden nicht nur das
Konzept des Datenbankentwurfs, das Entity-Relationship-Modell und das relationale Datenmodell, sondern auch das DBMS Microsoft Access vorgestellt. Im Kapitel 3 werden die
Microsoft .NET-Plattform, Visual Basic .NET, und ADO .NET vorgestellt. Außerdem werden
die Vorteile von VB .NET gegenüber seinen Vorgängerversionen erörtert. Im Kapitel 4 werden
Geoobjekte behandelt, und deren Modellierung und Präsentation erläutet.
Im 5. Kapitel wird der konzeptuelle Entwurf des VisMap-Systems präsentiert. Dabei stehen
die Modellierung der Geoobjekte und der Entwurf der Access-Datenbank im Vordergrund. In
Kapitel 6 wird der Aufbau des VB-Programms von VisMap erläutet. Hier wird vorgestellt, wie
die Schnittstelle gestaltet ist, wie VisMap mit der Datenbank kommuniziert, wie es eine graphische Darstellung der Geoobjekte herstellt, wie es auf die Ereignisse der Steuerelemente
reagiert und welche Funktionen es bietet, um Geoobjekte zu bearbeiten.
4
2. Grundlagen relationaler Datenbanken
Der Inhalt dieses Kapitels orientiert sich am Buch „Datenbanksysteme“ von Alfons Kemper
[KeEi01] und am Vorlesungsskript „Informationssysteme“ von Rainer Manthey [Man03].
Die Datenverwaltung und Speicherung spielen eine zentrale Rolle in einem
Geo-Informationssystem. Nach einer formalen Definition besteht ein Datenbanksystem (DBS)
aus einem Datenbank-Managementsystem (DBMS) und einer oder mehreren Datenbanken.
Das DBMS dient der Verwaltung und Organisation einer Menge von Objekten, der Zusammenfassung zu Datensätzen und der Beschreibung von Beziehungen und Abhängigkeiten
zwischen Daten und Datensätzen. Es bildet die funktionale Schnittstelle zwischen dem Anwender und den Datenbanken, verwaltet den Zugriff auf die Datenbank, kontrolliert die Datenbankkonsistenz und bietet Funktionen, um die Datensätze zu manipulieren. Das DBMS
verfügt über eine Data Definition Language (DDL) und eine Data Manipulation Language
(DML).
Mit der DDL wird die Struktur der abzuspeichernden Datenobjekte definiert. Dabei werden
gleichartige Datenobjekte durch ein gemeinsames Schema beschrieben. Die Strukturbeschreibung aller Datenobjekte des betrachteten Anwendungsbereichs nennt man das Datenbankschema. Die DML besteht aus der Anfragesprache (Query Language) und der
Datenmanipulationssprache zur Änderung, Löschen und Einfügen von Abgespeicherten Daten. Die DML kann zwei unterschiedliche Arten genutzt werden: Interaktiv, indem
DML-Kommandos direkt im DBMS eingegeben werden, oder indem sie in einem Programm
eingebettet wird.
Die Datenbanksysteme basieren immer auf einem Datenmodell. Ein Datenmodell besteht aus
einer bestimmten Zusammenstellung von Konzepten zum Modellieren von Daten der realen
Welt und/oder im Rechner. Darüber hinaus stellen Datenbanksysteme Werkzeuge zur Definition, Generierung, Manipulation und Abfrage von Daten dar. Das heutzutage am meisten
benutzte Datenmodell ist das relationale Datenmodell. Außerdem gibt es auch das hierarchische Datenmodell, das objektorientierte Datenmodell und das deduktive Datenmodell.
2.1
Datenbankentwurf
Die ANSI/SPARC schlug bereits 1978 eine konzeptionelle Datenbankarchitektur vor, die auch
heute noch breite Anerkennung findet und in dieser Form die Grundlage der meisten kommerziellen und wissenschaftlichen Datenbanksysteme bildet. Diese Drei-Ebenen-Architektur
unterscheidet bei der Modellierung in interne, externe und konzeptuelle Ebene einer Datenbank.
5
Die interne Ebene liegt am dichtesten am physikalischen Speicher einer Datenbank. Auf
dieser Ebene wird die Speicherorganisation festgelegt. Es wird bestimmt, auf welchem
Speicherort und welchem Speichermedium (Platte, Band) welche Daten wie physisch abgelegt sind. Die Strukturen dieser Ebene können die Effizienz des gesamten Datenbanksystems
stark beeinflussen.
Die konzeptuelle Ebene liegt oberhalb der internen Ebene. Auf dieser Ebene erstellt man das
organisationsweite Datenmodell sowie das organisationsweite Datenbankschema. Es wird
festgelegt, welche Daten in der Organisation insgesamt von Bedeutung sind und mit welcher
Struktur sie in der Datenbank abgelegt sein sollen.
Die externe Ebene bietet die Schnittstelle zu den Anwendern und Applikationen. Auf dieser
Ebene kann der Anwender Daten in die Datenbank eintragen (INSERT), Daten ändern
(UPDATE, DELETE), Daten aus der Datenbank selektieren (SELECT) und die für sich relevante Aussicht (VIEW) definieren. Man kann sowohl mit einem User Interface (GUI) als auch
mit einer Programmschnittstelle (API) auf die Datenbank zugreifen.
Die oben genannten drei Ebenen kommunizieren ständig miteinander. Bei jedem Zugriff auf
die Datenbank werden die Daten zwischen zwei übereinander liegenden Ebenen bis zum
physikalischen Speicher und wieder zurück – bis zur externen Sicht – übertragen. Die drei
Ebenen und deren gegenseitige Kommunikationen werden von DBMS organisiert.
Benutzer 1
Benutzer 2
Externe Schicht A
Benutzer 3
Externe Schicht B
Benutzer 4
Externe Schicht C
externe/konzeptuelle Abbildung
Konzeptuelle Schicht
Konzeptuelle/interne Abbildung
Interne Schicht
Abb. 2.1: Drei-Ebenen-Modell
6
DBMS
Die Aufgabe des Datenbankentwurfs ist der Entwurf der logischen und physischen Struktur
einer Datenbank so dass die Informationsbedürfnisse der Benutzer in einer Organisation für
bestimmte Anwendungen adäquat befriedigt werden können. Der Datenbankentwurf orientiert
sich an den oben beschriebenen Abstraktionsebenen einer Datenbankanwendung.
Bevor jedem Datenbankentwurf soll eine Anforderungsanalyse durchgeführt werden. In der
Anforderungsanalyse sollen die Abgrenzung und Eingrenzung des zu modellierenden Realitätsausschnittes festgelegt werden. Außerdem wird auch bestimmt, auf welche Weise die
Objekte zu bearbeiten sind. Es sind ggf. Nutzergruppen mit unterschiedlichen Anforderungsprofilen zu berücksichtigen.
Nach Fertigstellung der Anforderungsspezifikation erfolgt der konzeptuelle Entwurf. In dieser
Phase werden die für die Verarbeitung wesentlichen Merkmale von Objekten und Beziehungen bestimmt. In diesem Entwicklungsschritt wird die Modellierung mit dem „Entity-Relationship-Modell“ bevorzugt. Im relationalen Datenmodell werden zusätzlich alle Details
zu den „Relationen“ der Datenbasis festgelegt, der so genannte logische Entwurf. Es erfolgt
eine Normierung der Relationen zur Vermeidung von Anomalien bei der Nutzung der Datenbank und zur Beseitigung von Redundanz.
Abb. 2.2: Datenbankentwurf und 3-Ebenen-Architektur [Vo99]
Der letzte Schritt des Datenbankentwurfs, der physische Entwurf, verfolgt das Ziel der Effizienzsteigerung. Im physikalischen Modell werden schließlich die Art der Datenspeicherung
sowie der zugehörige Zugriffsmechanismus festgelegt. Bei manchen Datenbanksystemen
kann dabei auch angegeben werden, welche Datenstrukturen für diese Zugriffspfade (Indizierung) benutzt werden sollen.
7
Für diese Diplomarbeit wird das Entity-Relationship-Modell für den konzeptuellen Entwurf und
das relationale Datenmodell für den logischen Entwurf benutzt, die im nächsten Abschnitt
erklärt werden.
2.2
Das Entity-Relationship-Modell
Das am häufigsten benutzte Modell für den konzeptuellen Entwurf ist das Entity-Relationship-Modell, das im Jahr 1976 von Peter Chen entwickelt wurde. Es dient als Abstraktion eines Ausschnitts der realen Welt. Es ist aus mindestens drei unterschiedlichen
Elementen aufgebaut: aus den so genannten Entitäten (Gegenständen), den Attributen von
Entitäten und den so genannten Relationships (Beziehungen zwischen den Gegenständen).
Entitäten und Attribute
Entitäten sind wohlunterscheidbare physisch oder gedanklich existierende Konzepte der zu
modellierenden Welt. Die einzelnen Entitäten, die ähnlich, vergleichbar oder zusammengehörig sind, werden zu einem Entitätstyp zusammengefasst.
Entitäten besitzen Attribute (Eigenschaften), wobei die konkreten Merkmalsausprägungen als
Attributwerte bezeichnet werden. Die Domäne (Wertebereich) umfasst sämtliche mögliche
oder zugelassene Merkmalsausprägungen.
Im ER-Diagramm werden die Entitätstypen als Rechtecke dargestellt. Die Attribute werden
als Kreise oder Ovale graphisch beschrieben, die durch ungerichtete Kanten mit dem zugehörigen Rechteck verbunden werden.
Stadt
id
Stadt
KFZ
Name
Rathaus
Liegt_in
Baujahr
Population
Abb. 2.3: Entitäten und ihre Attribute
Es gibt nicht nur die Entitäten, die autonom existieren und innerhalb ihrer Entitätsmenge über
die Schlüsselattribute eindeutig identifizierbar sind, sondern auch schwache Entitäten, bei
denen dies nicht gilt. Die schwachen Entitäten sind in ihrer Existenz von einer anderen, übergeordneten Entität abhängig und oft nur in Kombination mit dem Schlüssel der übergeordneten Entitäten eindeutig identifizierbar. Sie werden durch doppelt umrandete Rechtecke
8
repräsentiert. Die Beziehung zu dem übergeordneten Entitätstyp wird ebenfalls durch eine
Verdopplung der Raute und der von dieser Raute zum schwachen Entitätstyp ausgehenden
Kante markiert.
Beziehungen
Zwischen verschiedenen Entitäten können Beziehungen existieren. Beim konzeptuellen Datenbankentwurf sind die Beziehungen zwischen Entitätstypen von Interesse. Die Menge solcher Beziehung nennt man Beziehungstypen. Die Beziehungstypen werden als Rauten mit
entsprechender Beschriftung repräsentiert.
Man kann Beziehungstypen hinsichtlich ihrer Funktionalität charakterisieren. Die Funktionalitäten stellen Integritätsbedingungen dar, die in der zu modellierenden Welt immer gelten
müssen. Es gibt 3 Arten von Beziehungstyp. Seien A und B Entitätstypen und R eine Relation
R(a,b), dann gilt:
1: 1 Typ:
1: n Typ:
n: m Typ:
one-to-one-Relationship
Zu jedem a aus A gibt es genau ein b aus B mit R(a,b) und umgekehrt.
one-to-many-Relationship
Zu jedem a aus A gibt es ein oder mehrere b aus B mit R(a,b).
many-to-many-Relationship
Zu jedem a aus A gibt es ein oder mehrere b aus B mit R(a,b) und zu jedem b
aus B gibt es ein oder mehrere a aus A mit R(a,b)
M
N
Begrenzung
Flächen
(3,*)
Kanten
(2,2)
Abb. 2.4: Funktionalität der Beziehung und (min, max)-Notation
Bei der Angabe der Funktionalitäten ist für eine Entität nur die maximale Anzahl von Beziehungsinstanzen relevant. Wenn man für eine Entität die präzisen Unter- und Obergrenzen
festlegen will, ist die (min, max)-Notation die richtige Lösung. Die Markierung (mini, maxi) gibt
an, dass es für alle ei∈Ei mindestens mini viele Tupel der Art (...,ei, …) und höchstens maxi
viele solcher Tupel in R gibt.
Um eine weitere Strukturierung der Entitätstypen zu realisieren werden Generalisierung und
Aggregation eingesetzt. Bei der Generalisierung werden die Attribute ähnlicher Entitätstypen
zusammengefasst und einem gemeinsamen Obertyp zugeordnet. Die ähnlichen Entitätstypen,
aus denen diese Eigenschaften faktorisiert werden, heißen Untertypen des generalisierten
Obertyps. Die Untertypen erben die Attribute von Obertypen. Bei dem jeweiligen Untertyp
verbleiben nur die nicht faktorisierbaren Attribute. Somit stellt der Untertyp eine Spezialisie-
9
rung des Obertyps dar. Die Generalisierung wird durch eine Beziehung mit dem Namen IS-A
ausgedrückt, welche durch ein Sechseck, verbunden mit gerichteten Pfeilen symbolisiert
wird.
Auto
IS-A
Fahrzeug
IS-A
PART-OF
LKW
PKW
PART-OF
Auto
Generalisierung
Auto
Aggregation
Abb. 2.5: Generalisierung und Aggregation
Durch die Aggregation werden einem übergeordneten Entitätstyp mehrere untergeordnete
Entitätstypen zugeordnet. Die unterordneten Entitätstypen bilden in ihrer Gesamtheit den
übergeordneten Entitätstyp. Diese Beziehung wird als PART-OF bezeichnet, um zu betonen,
dass die untergeordneten Entitäten Bestandteile der übergeordneten Entitäten sind.
2.3
Das relationale Modell
Das relationale Datenmodell dient den meisten derzeitigen Datenbanken als Grundlage. In
kommerziellen Datenbanken wird es seit etwa 1981 eingesetzt. Es wurde von E. F. Codd um
1970 vorgestellt mit dem Ziel, die Datenunabhängigkeit zu gewährleisten und basiert auf einer Variante des mathematischen Konzepts der Relation, in der Relationen auf einfache
Weise als Tabellen interpretiert werden. Es sind im Wesentlichen zwei Gründe, die für das
relationale Datenmodell als logisches Datenbankmodell sprechen: [GI03]
•
Einfachheit: die gesamte Information einer relationalen Datenbank wird
einheitlich durch Werte repräsentiert, die mittels eines einzigen Konstrukts
(nämlich der "Relation") strukturiert sind
•
Systematik: das Modell besitzt eine fundierte mathematische Grundlage: die
Mengentheorie
Im Gegensatz zum Entity-Relationship-Modell, welches ein konzeptuelles Modell darstellt,
handelt es sich beim relationalen Modell um ein logisches Datenmodell. Es liegt in gewisser
Hinsicht eine Stufe "tiefer". Hier werden keine abstrakten Entitäten oder Entitätstypen mehr
betrachtet, sondern nur noch deren konkrete, datenmäßige Umsetzung. Das Ziel der logi-
10
schen Datenmodellierung ist das Anordnen der zu speichernden Informationen mit Hilfe eines
Modells, welches eine möglichst redundanzfreie Speicherung unterstützt und geeignete Operationen für die Datenmanipulation zur Verfügung stellt.
In der Regel basiert die logische Datenmodellierung auf einem fertig gestellten konzeptuellen
Schema, das mit Hilfe bestimmter Richtlinien und Regeln in möglichst eindeutiger Weise auf
ein relationales Schema abgebildet wird. Die grundlegende Organisationsform der Daten im
relationalen Datenbankmodell ist die Relation. Das Relationale Datenmodell basiert auf der
mathematischen Definition einer Relation:
Gegeben seien n nicht notwendigerweise unterschiedliche Wertebereiche
(Domänen) D1, D2, …, Dn. Eine Relation R ist dann definiert als eine Teilmenge
des kartesischen Produkts der n Domänen:
R ⊆ D1 × D2 × L × Dn
Eine derartige Relation kann anschaulich durch eine zweidimensionale Tabelle dargestellt
werden, wobei zu beachten ist, dass sich die Definition einer Relation nicht mit der einer Tabelle deckt und umgekehrt. Beim relationalen Datenmodell wird also der gesamte Datenbestand durch einfache Tabellen verwaltet, in denen die Daten der Relationen gespeichert
werden. Dabei stellt eine Zeile jeweils einen Datensatz oder ein Tupel dar. Als Beispiel sei
eine einfache Relation Point zur Speicherung punktförmiger Geometrie genannt.
Schema(Point) = (id: LONG, PositionX: SINGLE, PositionY: SINGLE)
Sei ein Relationenschema, dann ist eine gültige Menge von Instanzen gegeben durch:
Point = {(1, 7.21667, 51.4833), (2, 7.1, 50.7333), (3, 8.68333, 50.1167)}
Schlüssel (key) oder Kandidatenschlüssel (candidate key) ist die minimale Kombination
von Attributen, die eine Entität aus einer Entitätsmenge eindeutig identifiziert. Minimal bedeutet hier, dass man nicht alle Attribute angeben muss, um ein einzelnes Tupel einer Relation eindeutig zu identifizieren. Die Zahl der notwendigen oder auch hinreichenden Attribute
hängt natürlich stark von den Inhalten ab. Man kann einen der Kandidatenschlüssel als so
genannten Primärschlüssel auswählen. Es gibt im relationalen Modell einen besonderen
Schlüsseltyp, den so genannten Fremdschlüsseln. Mit diesem werden Abhängigkeiten
zwischen verschiedenen Relationen einer Datenbank definiert.
Um ein Entity-Relationship-Modell in ein relationales Datenbankschema umzuwandeln, sollen
acht Abbildungsregeln abgearbeitet werden. Jede Regel wird für alle im zu bearbeitenden
Entity-Relationship-Modell gefundenen und der Regel entsprechenden Entitätstypen (Regel 1,
2, 7 und 8) oder Beziehungen (Regel 3, 4, 5 und 6) angewendet. Man beachte die korrekte
11
Reihenfolge der Anwendung der Abbildungsregeln in der Praxis (1, 7, 8, 2, 3, 4, 5 und zum
Schluss 6) [GI03].
Regel 1:
Definiere ein Relationenschema R für jeden starken Entitätstypen G, wobei die Eigenschaften
von G die Attribute von R bilden. Bei mehrwertigen Eigenschaften verfahre nach Regel 7.
Wähle einen Primärschlüssel (Identifikationsschlüssel) aus.
Regel 2:
Für jeden schwachen Entitätstypen S mit Eigentümer G erzeuge ein Relationenschema R,
wobei die Eigenschaften von S die Attribute von R bilden. Bei mehrwertigen Eigenschaften
verfahre nach Regle 7. Übernimm den Primärschlüssel des Relationenschemas, das dem
Eigentümer G entspricht und füge ihn als Fremdschlüssel R hinzu. Wähle eine Attributkombination (Kandidatenschlüssel) aus, die dann zusammen mit diesem Fremdschlüssel den
Primärschlüssel der Relation bildet. Erst die Kombination von Fremdschlüssel- und Kandidatenschlüsselattributen bildet den Primärschlüssel von R.
Regel 3:
Suche alle regulären, binären (1,1)(1,1)-, (0,1)(1,1)- und (0,1)(0,1)-Beziehungstypen B. Finde
die Relationenschemata S und T für die beteiligten Entitätstypen. Wähle eines davon (zum
Beispiel S) aus und füge dort den Primärschlüssel von T als Fremdschlüssel sowie die Eigenschaften von B als Attribute hinzu.
Regel 4:
Suche
alle
regulären,
binären
(1,n)(1,1)-,
(0,n)(1,1)-,
(1,n)(0,1)und
(0,n)(0,1)-Beziehungstypen B, sowie die jeweiligen Relationenschemata S und T der beteiligten Entitätstypen. Wähle das Relationenschema auf der "(1,1)"/"(0,1)"-Seite (S) aus und
füge dort den Primärschlüssel von T als Fremdschlüssel hinzu. Ausserdem werden allfällige
Eigenschaften von B als Attribute zu S hinzugefügt.
Regel 5:
Suche alle regulären, binären (0,n)(0,n)-, (0,n)(1,n)- und (1,n)(1,n)-Beziehungstypen B, sowie
jeweils die Relationenschemata S und T der beteiligten Entitätstypen. Definiere für jeden Beziehungstyp B ein neues Relationenschema R. Die Primärschlüssel der Relationenschemata
der beteiligten Entitätstypen S und T werden als Fremdschlüssel übernommen. Sie bilden
zusammen den Primärschlüssel des neuen Relationenschemas R. Füge Attribute, die Eigenschaften von B entsprechen, zu R hinzu.
Regel 6:
Verfahre für n-stellige Beziehungstypen (n>2) analog zu Regel 5, d.h. bilde sie auf eigenständige Relationenschemas ab und übernimm den Primärschlüssel der Relationenschemas
aller beteiligten Entitätstypen als Fremdschlüssel.
12
Regel 7:
Definiere für jede mehrwertige Eigenschaft E ein neues Relationenschema R'. R' enthält ein
Attribut A, das der Eigenschaft E entspricht und den Primärschlüssel K jenes Relationenschemas (R), welches dem Gegenstandstyp entspricht, der E enthält. Der Primärschlüssel
von R' ergibt sich aus der Kombination von A und K (man beachte, dass R keine Attributentsprechung für die mengenwertige Eigenschaft besitzt).
Regel 8:
Definiere ein Relationenschema R für die Superklasse C mit den Attributen A(R) = (K, A1, ...,
An). Bestimme K zum Primärschlüssel von R. Definiere weiter ein Relationenschema Ri für
jede Subklasse Si, (1<=i<=m) mit den Attributen A(Ri) = (K) ∪ (Attribute von Si). Setze den
Primärschlüssel von Si gleich K.
2.4
Normalisierung
Bei komplexen Systemen mit vielen Objekttypen und Beziehungen ist die Modellierung der
Datenstruktur nicht unproblematisch. Bei einem schlecht entworfenen Relationenschema sind
die Daten mehrfach gespeichert, dies verursacht einen höheren Speicherbedarf sowie einen
langsameren Zugriff auf die Daten. Insbesondere können Probleme bei der Datenpflege auftreten, die so genannten Anomalien.
Updateanomalien:
Bei der Aktualisierung der redundanten Einträge in einem Relationenschema kann es passieren, dass nicht alle betroffene Einträge aktualisiert werden. Dies hat die Verletzung der
Datenbankintegrität zur Folge.
Einfügeanomalien:
Beim Einfügen einer Entität in ein Relationenschema mit gemischten Entitätstypen kann es
passieren, dass nur die Attribute von dieser Entität zugewiesen werden, die Attribute von
anderen Entitäten besitzen nur die NULL-Werten.
Löschanomalien:
Wenn die Information bezüglich eines der miteinander vermischten Entitätstypen gelöscht
wird, kann es zum gleichzeitigen und unbeabsichtigten Verlust der Daten des anderen Entitätstypen kommen.
Um die oben genannten Anomalien zu vermeiden, soll man beim Entwurf einer relationalen
Datenbank die Relationen normalisieren. Normalerweise sollte der Normalisierungsprozess
schon auf konzeptueller Ebene stattfinden. Sein Ziel besteht darin, eine gewisse Einheitlichkeit in den Entwurf zu bringen. Allerdings sind bisher die für diesen Prozess erforderlichen
Schritte nur auf der Ebene des relationalen Datenmodells sauber definiert worden. Daher
werden auch wir die Normalisierung auf logischer Ebene betrachten. Der Entwerfe eines
13
konzeptuellen Schemas sollte sich über die Normalisierungsprinzipien im Klaren sein, um mit
einem korrekten konzeptuellen Schema die Implementierung eines korrekten logischen
Schemas zu erleichtern.
Die Theorie der Normalisierung, die durch E. F. Codd begründet worden ist, besteht aus 9
Regeln, die auch als 1. - 9. Normalform bezeichnet werden, von denen die ersten drei die
wichtigsten sind. Um die Umwandlung der Relationen in die drei Normalformen zu verstehen,
müssen wir zuerst das Konzept der Abhängigkeiten zwischen Attributen dieser Relationen
einführen.
Seien A und B Mengen von Attributen des Relationsschemas R, B ist von A funktional abhängig, wenn zu jedem Wert von A höchstens ein Wert von B auftreten kann. Dies wird wie
folgt dargestellt:
A → B
Die funktionalen Abhängigkeiten stellen eine Verallgemeinerung des Schlüsselbegriffs dar.
Um es zu präzisieren, definieren wir hier den Begriff voll funktional abhängig:
Seien A und B Mengen von Attributen des Relationsschema R, B ist von A
voll funktional abhängig, wenn B von A funktional abhängig aber nicht funktional abhängig von einer echten Teilmenge von A ist. Dies wird wie folgt
bezeichnet:
& B
A →
Nun können wir die ersten drei Normalformen definieren:
Erste Normalform:
Eine Relation befindet sich in erster Normalform, wenn jedes Attribut elementar oder atomar,
d.h. unzerlegbar, ist.
Zweite Normalform:
Eine Relation befindet sich in zweiter Normalform, wenn sie die erste Normalform besitzt und
zusätzlich jedes Attribut, das nicht selbst zum Identifikationsschlüssel gehört, voll funktional
vom gesamten Identifikationsschlüssel abhängig ist.
Dritte Normalform:
Eine Relation befindet sich in dritter Normalform, wenn sie die zweite Normalform besitzt und
zusätzlich kein Attribut, das nicht zum Identifikationsschlüssel gehört, transitiv von einem Identifikationsschlüssel abhängig ist.
14
2.5
Grundlagen der SQL
Der Inhalt dieses Abschnittes orientiert sich stark am „SQL: The Complete Reference“ von
James Groff [GrWe02] und am „Die relationale Anfragesprache SQL“ [GI03].
Man benötigt neben der Strukturbeschreibung auch eine Sprache, mit der man Informationen
aus der Datenbank extrahieren kann. Es gibt zwei formale Anfragesprachen, die für die Anfrageformulierung in relationalen Datenbanken konzipiert wurden: die relationale Algebra und
das Relationenkalkül. In ihrer unmittelbaren Form haben sie heute jedoch als DML stark an
Bedeutung verloren, da sie schwer zu durchschauen sind. Stattdessen hat SQL (structured
query language) sich seit Mitte der 80er Jahre für relationale Datenbanken durchgesetzt. Sie
basiert auf den oben genannten zwei formalen Sprachen und ist eine deskriptive, mengenorientierte Sprache. Sie kann sowohl selbständig als auch eingebettet in eine Programmiersprache (C, C++, Java, VB, …) verwendet werden. SQL wurde zunächst in den 70er Jahren
von IBM unter dem Namen „SEQUEL“ entwickelt. In den 80ern erfolgte eine allgemeine
Standardisierung dieser Sprache, die jüngste Version ist SQL99.
SQL kann nicht nur benutzt werden, um die Daten in der Datenbank zu manipulieren. Sie
kann in drei konzeptionelle Teile aufgeteilt werden. Die Datenbankschemata können mittels
SQL erzeugt und abgeändert werden, hier wird sie als Datendefinitionssprache (DDL) benutzt.
Am häufigsten werden die SQL-Anweisungen benutzt, um Anfragen an die Datenbank zu
stellen und Tupel in Tabellen zu mutieren (mit den Anweisungen INSERT, DELETE und
UPDATE), hier dient sie als Datenmanipulationssprache (DML). Außerdem kann mittels SQL
die Sicherheit der Datenbanken kontrolliert werden, hier wird sie als Datenkontrollsprache
(DCL) benutzt.
Relation, Tupel und Attribute werden in SQL als „table", „row" und „column" bezeichnet. Durch
die CREATE TABLE-Anweisung wird ein Relationenschema in der Datenbank definiert. Bei
dem Definieren eines Relationenschemas müssen die zur Relation gehörenden Attribute sowie deren Domänen angegeben werden. Außerdem kann man auch weitere Deklarationen
wie z.B. Wertebeschränkungen (CHECK-Klausel), Standardwerte oder Primär- und Fremdschlüsseldeklarationen angeben.
SQL bietet eine umfangreiche Auswahl der Domänen, Beispiele dafür sind char, number, long
und date. Durch die Deklaration „NOT NULL“ wird festgelegt, dass für das jeweilige Attribut
keine NULL-Werte zulässig sind. Folglich muss beim Einfügen eines Tupels grundsätzlich ein
Wert für dieses Attribut angegeben werden. Primärschlüssel können mit Hilfe der PRIMARY
KEY-Klausel durch eine so genannte „Table Constraint“ deklariert werden. Gefolgt ist ein
Beispiel dafür, wie eine Datenbanktabelle mit Hilfe von SQL definiert werden kann.
CREATE TABLE City
(
Name VARCHAR2(35),
15
Country VARCHAR2(4),
Province VARCHAR2(32),
Population NUMBER CONSTRAINT CityPop
CHECK (Population >= 0),
CONSTRAINT CityKey PRIMARY KEY (Name, Country, Province)
);
Die Möglichkeiten der Datenmanipulation mit SQL können in zwei Kategorien eingeteilt werden. Die eine sind die Datenbankanfragen, welche Inhalte abfragen, aber keine Änderungen
an der Datenbank vornehmen. Die zweite Gruppe sind die Datenmanipulationen, die die Datenbank verändern, die zum Beispiel Daten einfügen, löschen oder abändern.
Bei den Abfragen mit der SQL werden die Daten des Definitionsbereichs (FROM) mit Hilfe
eines Auswahlkriteriums (WHERE) auf einen Bildbereich (SELECT) abgebildet. Dabei entstehen im Ergebnis grundsätzlich wieder Relationen. Die Standardform einer Datenbankanfrage mittels SQL ist wie folgt aufgebaut:
SELECT <Attributliste>
FROM
<Relationenliste>
WHERE
<Bedingungen>
Wobei die Attributliste aus den Namen der Attribute besteht, deren Werte man durch die Anfrage erhalten möchte; Die Relationenliste ist die Aufführung der Namen der Relationen, die
für die Anfrage gebraucht werden. Die Bedingungen identifizieren die Tupel, die durch die
Anfrage zurückgegeben werden sollen.
Es gibt nun eine Reihe von möglichen Erweiterungen des obigen Grundschemas, welche die
Flexibilität von Anfragen massiv erhöhen:
-
mehrere Bedingungen (konjunktiv oder disjunktiv verknüpft)
komplexere Bedingungen (Unteranfragen, Bereichsanfragen, Verbundoperatoren)
speziellere Bildbereiche (Verknüpfung von Attributen)
nicht-relationale Konstrukte (Sortieren, Gruppierungen, Aggregatfunktionen)
Mengenoperationen (Vereinigung, Durchschnitt, Differenz)
Bedingungen können beliebig durch die Anwendung der logischen Operatoren AND und OR
miteinander verkettet werden. Einzelne Bedingungen können mit dem NOT-Operator negiert
werden. Bedingungen haben prinzipiell die Struktur <Attribut> <Operator> <Wert> (z.B. Name=“Zheyi“) wobei die Werte wiederum Attribute, Konstanten oder aber das Resultat von
Unteranfragen sein können, d.h. man muss die Werte von Bedingungen nicht unbedingt fix
definieren, sondern kann sie mittels einer verschachtelten Anfrage generieren. Mit dem Vergleichs-Operator "IN" können Anfragen beliebig tief geschachtelt werden.
16
SQL unterstützt eine Reihe von Vergleichs- und Mengenoperatoren. Vergleichsoperatoren
wie =, <, >, <>, <=, >=, BETWEEN können auf zwei Arten verwendet werden. Ist ein Wert
einer Bedingung eine Konstante, so handelt es sich bei dieser Bedingung um eine Restriktion.
Ist der Wert wiederum ein Attribut einer anderen Relation des Definitionsbereichs, so handelt
es sich um eine Verbundbedingung. Mittels Verbundbedingungen können Daten aus mehreren Relationen miteinander verknüpft werden. Es können nur Attribute mit identischen Domänen miteinander verglichen werden. Sie müssen jedoch nicht den gleichen Namen
besitzen.
Im SELECT-Teil kann anstelle einer Attributliste auch ein „*“ geschrieben werden. Der Effekt
besteht darin, dass alle Attribute des Definitionsbereichs gezeigt werden.
Durch den Vergleichsoperator "LIKE" können Teile von Zeichenketten miteinander verglichen
werden. Teile von Zeichenketten werden mit zwei reservierten Zeichen dargestellt: "%" ersetzt eine unbestimmte Anzahl von Zeichen, während "_" ersetzt ein Zeichen.
Die arithmetischen Standard-Operatoren für Addition (+), Subtraktion (-), Multiplikation (*) und
Division (/) können für alle numerischen Werte oder Attribute mit numerischen Domänen eingesetzt werden.
SQL unterstützt auch Konstrukte, die mit der ursprünglichen relationalen Algebra wenig bis
gar nichts zu tun haben. So besitzt eine Menge per Definition keine Ordnung. Mittels des
Konstrukts "ORDER BY" kann man jedoch eine Ordnung auf der Ergebnisrelation definieren.
Standardmäßig wir absteigend sortiert. Die Schlüsselwörter "ASC" und "DESC" jedoch bezeichnen aufsteigende und absteigende Anordnung der Werte im Resultat.
Gruppierungen (GROUP BY-Klausel) dienen dazu, die Menge aller Tupel einer Relation nach
bestimmten Kriterien in Teilmengen zu unterteilen, um für diese Teilmengen bestimmte Statistiken zu berechnen. Als Gruppierungskriterium dienen die Werte eines bestimmten Attributs.
Alle Tupel, die für dieses Attribut den gleichen Wert besitzen, werden zu einer Gruppe zusammengefasst. Diese Gruppen können dann weiterbearbeitet werden (als Spezialfall auch
durch eine weitere Gruppierung, um Gruppen von Gruppen zu bearbeiten etc.). Dazu dienen
so genannte Aggregatfunktionen, die nur auf numerische Attribute im "SELECT"-Teil angewendet werden können. Folgende Aggregatfunktionen stehen üblicherweise zur Verfügung:
-
MIN:
MAX:
SUM:
COUNT:
AVG:
Bestimmen des minimalen Wertes eines Attributs
Bestimmen des maximalen Wertes eines Attributs
Berechnen der Summe aller Werte eines Attributs
Anzahl der Werte eines Attributs (nicht der verschiedenen Werte!)
Berechnen des Durchschnitts aller Werte einen Attributs, wobei
NULL-Werte nicht in die Berechnung einfließen
17
Mengenoperationen werden verwendet, um Tupel in einer Ergebnisrelation zusammenzufassen, die aus im Grunde verschiedenen Anfragen stammen. Voraussetzung dafür ist natürlich, dass die Anzahl der selektierten Attribute jeder beteiligten Anfrage identisch ist.
Außerdem müssen die jeweiligen Domänen kompatibel sein (und zwar jeweils in der selben
Reihenfolge). Für die Verknüpfung von Tupelmengen stehen die üblichen Operatoren zur
Verfügung, wie man sie von der Mengenlehre her kennt:
-
UNION:
INTERSECT:
MINUS:
Vereinigung von Tupelmengen
Durchschnitt von Tupelmengen
Differenz von Tupelmengen
Um eine Datenbank immer auf dem aktuellen Stand zu halten, müssen von Zeit zu Zeit die
Daten nachgeführt werden (alte, nicht mehr gebrauchte Einträge löschen, neue Einträge erfassen oder veränderte Einträge anpassen). In SQL gibt es drei Kommandos um die Datenbasis zu modifizieren. Diese Kommandos sind Einfügen (INSERT), Löschen (DELETE) und
Ändern (UPDATE).
In seiner einfachsten Form wird durch das Einfügen-Kommando (INSERT INTO) ein Tupel zu
einer Relation hinzugefügt. Form des Statements:
INSERT INTO Relationenname (Liste von Attributen)
VALUES (Liste von Werten);
Wobei die Liste der Attribute nur dann angegeben werden muss, wenn keine vollständigen
Tupel eingegeben werden oder wenn die Werte in einer anderen Reihenfolge erscheinen
sollen als die zugehörigen Attribute bei der Definition der Relation.
Das Löschen-Kommando (DELETE FROM) entfernt ein oder mehrere Tupel aus einer Relation. Die WHERE-Klausel spezifiziert, welche Tupel betroffen sind. Tupel werden explizit
immer nur aus einer Relation gleichzeitig gelöscht. Bei einer fehlenden WHERE-Klausel
werden alle Tupel aus der angegebenen Relation gelöscht. Form des Statements:
DELETE FROM Relationenname
WHERE Bedingung;
Das Ändern-Kommando (UPDATE) wird gebraucht, um Werte von Attributen von einem oder
mehreren Tupeln zu ändern. Die WHERE-Klausel spezifiziert, welche Tupel von der Änderung betroffen sind. Die SET-Klausel spezifiziert die Attribute, die geändert werden sollen und
bestimmt deren neue Werte. Form des Statements:
UPDATE Relationenname
SET einem oder mehreren Attributen einen Wert zuweisen
WHERE Bedingung;
18
2.6
Microsoft Access
Access ist ein DBMS für relationale Datenbanken, das seit 1992 von Microsoft entwickelt und
vertrieben wird. Es ist eine wichtige Komponente des Microsoft Office Paketes und zählt
heute zum populärsten DBMS für Desktop-PCs, weil es sehr gut für kleine bis mittlere
DB-Anwendungen ohne große Anforderungen für Mehrbenutzerbetrieb geeignet ist.
Es gibt zwei Typen von DBMS für Access, die Jet Database Engine und die MSDE (Microsoft
SQL Server 2000 Desktop Edition). Microsoft SQL Server 2000 Desktop Edition ist eine
Technologie zur lokalen Datenspeicherung in einem Format, das kompatibel mit Microsoft
SQL Server 2000 ist. MSDE kann auch zur servergestützten Datenspeicherung verwendet
werden. Man kann sich SQL Server 2000 Desktop Edition als Client/Server-Alternative zum
Dateiserver Microsoft Jet-Datenbank-Engine vorstellen, sie bietet mehr Funktionen als die Jet
Database Engine. Das System VisMap ist keine Client/Server Anwendung, die Datenbankstruktur ist auch relativ einfach. Um die Verwaltungsaufwand für die Datenbank zu minimieren
wird in VisMap die Jet Database Engine benutzt. Die Jet Database Engine ist das traditionale
DBMS für Access. Sie ist einfach zu verwalten und besonderes geeignet für die Datenbank
mit einfacher Struktur. Die Daten werden in einer Datei gespeichert und deswegen einfach zu
transportieren. Die Benutzung der Systemressource ist auch sehr gering.
MS Jet hat erweiterte Kapazitäten, die normalerweise bei Desktop-Datenbanken nicht zur
Verfügung stehen. Diese sind: [Gr02]
•
Zugriff auf heterogene Datenquellen. MS Jet unterstützt mit Hilfe von Open Database Connectivity (ODBC)-Treibern den Zugriff auf über 170 verschiedene Datenformate einschließlich Borlands dBASE und Paradox, ORACLE von der Oracle
Corporation, den MS SQL Server und IBM DB2. Entwickler können Applikationen
erstellen, in denen die Anwender praktisch jedes Datenformat lesen und verändern
können.
•
Referenzielle Integrität und die Gültigkeit von Daten. MS Jet unterstützt sowohl
Primärschlüssel als auch Fremdschlüssel, datenbankspezifische Regeln und das Löschen oder Ändern von Datensätzen in untergeordneten Tabellen. Das bedeutet, dass
der Entwickler diese Regeln nicht mehr selbst entwickeln muss. Die Datenbank-Engine enthält die Regeln bereits, so dass sie für jede Applikation verfügbar
sind.
•
Erweiterte Sicherheitsmerkmale für Workgroups. MS Jet speichert die Benutzerrechte in einer separaten Datenbank, die normalerweise im Netzwerk abgelegt wird.
Zugriffe auf Datenbank-Objekte (z. B. Tabellen oder Abfragen) werden in jeder Datenbank gespeichert. Durch die Trennung von Benutzerrechten und Informationen
über Dateizugriffe erleichtert MS Jet die Administration der Datenbanken im Netzwerk.
19
•
Veränderbare Datenblattansicht. Im Gegensatz zu vielen Datenbank-Engines, die
Datenbankabfragen in temporären Views oder Snapshots anzeigen, gibt MS Jet eine
Datenblattansicht zurück, die automatisch alle Änderungen, die die Anwender vornehmen, in die Original-Datenbank zurückschreibt. Das heißt, dass alle Ergebnisse
einer Abfrage, auch wenn sie auf verschiedene Tabellen zugegriffen hat, genauso
behandelt werden können wie die Tabellen selber. Außerdem können Abfragen auch
auf anderen Abfragen basieren.
•
Abfrage-Optimierung mit der Microsoft RushmoreTM-Technologie. MS Jet enthält
die innovative RushmoreTM-Technologie von MS FoxPro; die Geschwindigkeit der
Abfragen erhöht sich damit erheblich
Die Daten einer Access-Datenbank werden in Tabellen gespeichert. Tabellen sind daher die
Grundlagen einer Datenbank. Wie viele Tabellen eine Datenbank umfasst und in welcher
Weise die Daten der einzelnen Tabellen miteinander verknüpft sind, lässt sich nicht allgemein
sagen. Diese Aufgabe muss bei den Überlegungen zum Datenbankdesign gelöst werden.
Jede einzelne Tabelle ist dagegen in gleicher Weise aufgebaut.
Abb. 2.6: Graphisches Interface von Microsoft Access
Tabellen sind in Zeilen und Spalten organisiert. Jede Zeile stellt einen Datensatz dar, jede
Spalte ein Feld. Ein Feld enthält daher so viele Werte, wie eine Tabelle Datensätze aufweist.
Obwohl die Werte eines Feldes sich im Allgemeinen inhaltlich unterscheiden, sind sie doch
von gleicher Art. So enthält das Feld Name lauter Textwerte, während das Feld Geburtsdatum nur Datumswerte aufweist. Für eine effiziente Datenbankverwaltung ist es erforderlich,
dass bei der Definition einer Tabelle für jedes Feld sein Datentyp festgelegt wird.
20
Man kann bei dem relationalem Datenmodell die Relationen leicht in Tabellenform umwandeln. Die Tabellen lassen sich auch als Relationen formalisieren, wenn man keine Duplikate
zulässt und von der Anordnung absieht. Im Access kann man mit der Entwurfsansicht sehr
leicht das Schema einer Relation (Felder von Tabellen, Feldernamen, Felddatentypen, Bedingungen, etc.) festlegen. In der Datenblattansicht der Tabellen kann man die Datensätze
addieren, löschen und aktualisieren.
Nachdem man verschiedene Tabellen zu den einzelnen Themen in der Access Datenbank
angelegt hat, muss er Microsoft Access mitteilen, wie diese Informationen wieder zusammengeführt werden. Der erste Schritt in diesem Prozess besteht darin, Beziehungen zwischen den Tabellen zu definieren. Eine Beziehung ist eine Zuordnung zwischen allgemeinen
Feldern (Spalten), die in zwei Tabellen vorkommen. Eine Beziehung kann vom Typ 1:1, 1:n
oder n:n sein. Anschließend kann man Abfragen, Formulare und Berichte erstellen, um die
Informationen aus verschiedenen Tabellen gleichzeitig anzuzeigen. Eine Beziehung funktioniert durch übereinstimmende Daten in Schlüsselfeldern (in der Regel ein Feld, das in beiden
Tabellen denselben Namen besitzt). In den meisten Fällen stellen diese übereinstimmenden
Felder in der einen Tabelle den Primärschlüssel, der einen eindeutigen Bezeichner für jeden
Datensatz enthält, und in der anderen Tabelle einen Fremdschlüssel dar.
Im Abfragenbereich kann man die komplexe Abfragen definieren und speichern. In der Entwurfsansicht kann man mit Hilfe der vordefinierten Formulare unterschiedliche Abfragentypen
definieren: Auswahlabfrage, Kreuztabellenabfrage, Tabellenerstellungsabfrage, Aktualisierungsabfrage, Anfügabfrage und Löschensabfrage. Sie können Abfragen zusammen mit der
Datenbank speichern. Im Allgemeinen enthält eine Datenbank eine Vielzahl von gespeicherten Abfragen, die dann jeweils bei Bedarf aufgerufen oder dauerhaft als Datenherkunft von
Formularen oder Berichten dienen. Obwohl das Abfrageergebnis große Mengen von Daten
beinhalten kann, verbraucht eine gespeicherte Abfrage nur sehr wenig Speicherplatz auf der
Festplatte. Insbesondere ist der benötigte Speicherplatz unabhängig von der im Abfrageergebnis vorhandenen Datenmenge. Dies ist darin begründet, dass Access nur die Abfrageformulierung speichert, nicht jedoch das Abfrageergebnis. Die Folge dieses Konzepts ist
natürlich, dass das Abfrageergebnis jedes Mal neu ermittelt werden muss, wenn die Abfrage
benötigt wird. Das kostet mehr oder weniger viel Zeit, hat jedoch den unschätzbaren Vorteil,
dass Abfrageergebnisse stets dem neuesten Datenmaterial der Tabellen entsprechen.
Access bietet zwei grundsätzlich verschiedene Anfragesprachen, die QBE (Query-by-Example) und die SQL. Mit QBE erhält der Benutzer ein benutzerfreundliches Interface,
um die einfachen Abfragen zu konstruieren. Die komplexen Abfragen können aber nur durch
SQL konstruierbar. Weil man die Datenbank nicht im Access, sondern direkt durch die
Jet-Datenbank-Engine verwaltet und bearbeitet, ist QBE von weniger Bedeutung. Hingegen
sind für diese Diplomarbeit die Abfragen durch die im VB Programm eingebetteten SQL Statements von großer Bedeutung. Zu beachten ist, dass das von MS Jet Database Engine unterstützte SQL keine ANSI-SQL, sondern Jet-SQL von Microsoft ist.
21
3. Visual Basic und Microsoft .NET
Statt Visual Basic 6 wird die Implementierung des VB-Programms von VisMap mit Visual Basic .NET entwickelt. Für den Datenzugriff zur Access-Datenbank wird statt ADO ADO .NET
verwendet. Weil Visual Basic .NET und ADO .NET stark abhängig von dem Microsoft .NET
Framework sind, wird in diesem Kapitel zunächst das Microsoft .NET Framework erklärt.
Dann wird erläutet, was ADO .NET ist und seine Fortschritte im Vergleich mit ADO. Danach
wird erklärt, was Visual Basic .NET ist und wie man die Visual Basic .NET Programme
schreiben. Am Ende wird ein Vergleich zwischen Visual Basic und Visual Basic .NET gemacht, um die Fortschritte von VB .NET zu erklären. Der Inhalt dieses Abschnittes orientiert
sich am „Database Programming with Visual Basic® .NET and ADO .NET” von Barker
[Bark02], „Programming Visual Basic .NET“ von Liberty [Lib03] und „MSDN for Visual Studio .NET“ von Microsoft [MSDNLib].
3.1
Microsoft .Net Framework
Im Jahr 2000 hat Microsoft die .NET Plattform angekündigt. .NET ist ein Entwicklungsframework, das ein neues API (application programming interface) für die Dienste und die APIs
für klassische Windows Betriebssysteme anbietet, besonders für die Windows 2000/XP/2003
Familie. Es kombiniert unterschiedliche Technologien, die von Microsoft während der späten
1990er herausgegeben wurden. Unter letzterem sind die COM+ Komponente-Dienste, das
ASP Web-Entwicklungsframework, die XML, das objektorientierte Design und die Unterstützung der neuen Web Dienste Protokolle wie SOAP, WSDL und UDDI zufinden.
Der Anwendungsbereich von .NET Framework ist riesig, Die Plattform besteht aus 4 separaten Produktionsgruppen, diese Diplomarbeit betrifft aber nur die erste Gruppe:
-
Eine Gruppe von Sprachen, einschließlich Visuell Basic .NET, C#, JScript .NET, und Managed C++; eine Gruppe von Entwicklungswerkzeugen, einschließlich Visual Studio .NET;
eine umfassende Klassenbibliothek für den Aufbau der Web Dienste und Windows-Anwendungen; und die Common Language Runtime (CLR), um die in diesem
Framework erzeugende Objekte auszuführen.
-
Eine Gruppe von .NET Enterprise Server, wie SQL Server 2000, Exchange 2000, BizTalk
2000 usw., die spezialisierte Funktionalität für relationale Datenspeicherung, Email, B2B
Kommerz anbieten.
-
Ein Angebot von kommerziellen Webdiensten, .NET My Services; für ein Honorar können
die Entwickler diesen Dienst benutzen, um eigene Programme zu erstellen.
-
Neue .NET-enabled non-PC Geräte, von Handy bis zum Spiel-Konsole.
22
Das .NET Framework ermöglicht die Zusammenarbeit der unterschiedlichsten Sprachen.
Zusammenarbeit bedeutet dabei nicht nur, dass ein Aufruf von einem Programmcode möglich
ist, der in einer anderen Sprache geschrieben wurde, sondern auch, dass in objektorientierten
Sprachen eine Vererbung von Klassen möglich ist, die in einer anderen objektorientierten
Sprache entwickelt wurden.
Basis für diese Sprachintegration ist einerseits die Zwischensprache MSIL und die CLR und
andererseits die so genannte Common Language Specification (CLS). Die CLS ist ein Regelwerk für Compiler, das festlegt, wie die Umsetzung von sprachspezifischen Konzepten in
die MSIL erfolgen muss. Kern der CLS ist das Common Type System (CTS), das ein einheitliches System von Datentypen definiert. Denn nur, wenn die verschiedenen Sprachen die
gleichen Datentypen verwenden, ist eine problemlose Integration möglich.
3.1.1
Struktur des Microsoft .NET Frameworks
Die Ausführung einer .NET-Anwendung setzt eine Laufzeitumgebung voraus, die Common
Language Runtime (CLR) genannt wird. Die CLR stellt den Just-in-Time-Compiler und zahlreiche andere Basisdienste bereit, die von allen .NET-fähigen Sprachen verwendet werden.
Dazu gehören zum Beispiel ein Garbage Collector, Exception Handling, ein Sicherheitssystem und die Interoperabilität mit Nicht-.NET-Anwendungen.
Wie in der Abb. 3.1 gezeigt, die „Framework Base Classes“ basiert auf CLR. Oberhalb von
„Framework Base Classes“ ist eine Menge von Klassen, die zusätzliche Funktionen bietet, die
„Data and XML Classes“. Am ganz oben ist eine Menge der Klassen für Web Dienste, Web
Formen und Windows Formen. Insgesamt werden diese Klassen als die Framework Class
Library (FCL) bezeichnet, die eine objektorientierte API für das ganze .NET Framework bietet.
Abb. 3.1: Systemarchitektur des .Net Frameworks [Lib03]
23
Die Framework Base Classes, die niedrigste Stufe der FCL, ist ähnlich wie die Java Basis
Klassen. Diese Klassen unterstützen fundamentale Eingabe und Ausgabe, Manipulation der
Strings, Sicherheitsmanagement, Netzkommunikation, Management des Threads, Textmanipulation usw.
Die Data and XML Classes sind eine Erweiterung der Framework Base Classes, sie unterstützen Datenverwaltung und XML Manipulation. Die Daten-Klassen, die ADO .NET enthält,
unterstützen das persistente Management von Daten, die von den Datenbanken im Hintergrund erhalten werden. Diese Klassen umfassen die Structured Query Language Klassen,
damit man durch eine standardmäßige SQL-Schnittstelle die persistente Datenbank manipulieren kann. Das .NET Framework unterstützt auch eine Menge von Klassen, mit denen die
XML Daten bearbeitet und geparst werden können.
Ganz oben steht eine Reihe von Klassen, mit den man mit drei unterschiedlichen Technologien Anwendungen erzeugen kann: Web-Dienste, Web-Formen, und Windows-Formen. Web
Dienste schließen eine Anzahl von Klassen ein, die die Entwicklung von einfach verteilten
Komponenten unterstützen, die sogar mit Firewall und NAT funktionieren können. Diese
Komponenten unterstützen auch Plug-and-Play, da die Web Dienste HTTP und SOAP als
zugrunde liegende Kommunikations-Protokolle brauchen.
Die Web Formen und Windows Formen ermöglichen eine schnelle Entwicklung von Web- und
Windows-Anwendungen. Mit dem Drag and Drop der Maus kann man einfach die vordefinierten Steuerelemente auf die Formen rüberziehen. Nach dem Einfügen des Steuerelementes kann man die gewünschten Ereignisse von diesem Steuerelement in einer List
auswählen und dafür eigene Programmiercodes schreiben.
3.1.2
Kompilierung der .NET-Programme
Das .NET Framework arbeitet – genau wie die Programmiersprache Java – mit einer Zwischensprache. Ein Compiler einer .NET-Sprache erzeugt also nicht einen prozessorspezifischen Maschinencode, sondern einen plattformunabhängigen Zwischencode, der von CLR
ausgeführt werden kann. Dieser Zwischencode heißt Microsoft Intermediate Language (MSIL)
und bildet eine so genannte Assembly. Die VB .NET erzeugende MSIL Datei ist identisch mit
denen von anderen Sprachen erzeugte MSIL Dateien. Eine wichtige Besonderheit der CLR
ist, dass es allgemein ist. Die gleiche Runtime unterstützt die Entwicklung in Visual
Basic .NET und in C#.
Erst zur Laufzeit wird dieser MSIL-Code in einen prozessorspezifischen Maschinencode (Native Code) umgewandelt. MSIL-Code wird aber nicht interpretiert, sondern von einem so genannten Just-in-Time-Compiler Stückchenweise umgewandelt und dann ausgeführt. Der
24
standardmäßige JIT-Compiler läuft nur beim Bedarf. Wenn eine Methode aufgerufen wird,
analysiert der JIT-Compiler die MSIL und erzeugt sehr effiziente Maschinencodes, die sehr
schnell laufen. Der JIT-Compiler kann erkennen, ob der Code schon kompiliert ist. Da die
Kompilierung passiert nur beim Bedarf, läuft eine .NET Anwendung immer schneller, weil die
kompilierten Codes wiederbenutzt werden.
Andere .NET-fähige
VB .NET Quell-
C# Quellcode
Sprachen
VB .NET Compiler
C# Compiler
Compiler
Microsoft Intermediate Language (MSIL)
[Datei]
Just-In-Time-Compiler (JIT)
(Teil der Common Language Runtime)
Native Code
Native Code
(Native Image)
[RAM]
[Datei]
Betriebssystem
Abb. 3.2: Intermediation-Konzept im.NET Framework
Dadurch, dass nicht interpretiert, sondern vor der Ausführung kompiliert wird und der
Just-in-Time-Compiler sehr schnell ist, ist der Performance-Verlust durch die Intermediation
sehr gering. Im Zweifel gibt es auch die Möglichkeit, das Ergebnis der Kompilierung von MSIL
zu Maschinencode zu speichern und später auszuführen. Dies nennt man ein Native Image.
Ein Native Image ist aber nicht mehr plattformunabhängig.
Die CLS garantiert, dass alle .NET-Sprachen sehr ähnliche MSIL erzeugen. Dadurch können
die in einer Sprache entworfenen Objekte von den anderen aufgegriffen und abgeleitet werden. Damit ist es möglich, eine Klasse in C# zu entwerfen und sie davon in VB.NET abzuleiten.
25
3.2
ADO .NET
Viele Anwendungen interagieren mit der Datenbank. Das .NET Framework bietet eine große
Gruppe von Objekten, um die Datenbankinteraktion zu verwalten. Diese Klassen werden als
ADO .NET (ActiveX Data Objects) bezeichnet.
ADO.NET sieht ähnlich wie sein Vorgänger ADO aus. Der Schlüsselunterschied ist, dass
ADO.NET eine getrennte Datenarchitektur ist. In einer getrennten Architektur werden die
Daten aus einer Datenbank abgeholt und in den Cachespeicher auf der lokalen Maschine
aufgenommen. Man manipuliert die Daten auf seinem lokalen Rechner und nimmt mit der
Datenbank Verbindung nur auf, wenn man wirklich die Datensätze in der Datenbank aktualisieren möchte.
Es gibt bedeutende Vorteile, die Verbindung mit der Datenbank nicht permanent zu halten.
Der größte Vorteil ist, dass viele in Zusammenhang mit verbindenden Datenobjekten stehende Probleme vermieden werden. Datenbankverbindungen sind ressourceintensiv, und es
ist schwierig, Tausende (oder Hunderttausende) von gleichzeitigen, kontinuierlichen Verbindungen zu halten. Eine getrennte Architektur ist ressourcesparsam.
Abb. 3.3: Eigenschaften, Methoden, und zusätzliche Objekte von DataSet [Bark02]
26
ADO.NET nimmt mit der Datenbank Verbindung auf, um Daten abzuholen. Dann wird die
Verbindung abgebrochen, bis man die Änderungen eingegeben hat, und die Daten aktualisieren möchte. Zahlreiche Anwendungen verwenden viele Zeit damit, die Daten durchzulesen
und auszustellen, ADO.NET stellt eine auf der lokalen Maschine liegende Untermenge der
Daten für die Anwendung zur Verfügung, wenn sie die Daten liest und ausstellt. Getrennte
Datenarchitektur arbeitet ähnlich wie die Datenbearbeitung in den Web-Applikationen. Alle
Websitzungen sind getrennt, und der Zustand verändert sich nicht, bis man die Abfrage zum
Server schickt. Mit der getrennten Datenarchitektur kann man leicht Netzanwendungen entwickeln.
Abb 3.3 zeigt die Struktur des wichtigsten Objekts von ADO .NET: DataSet. Offensichtlich hat
ADO .NET mehr Objekte als ADO. Das DataSet-Objekt wird zusammen mit den anderen
Datenkontrollen benutzt, in DataSet werden Ergebnisse gespeichert, die von Befehlen und
den Datenadaptern zurückgegeben werden. Im Gegensatz zu dem Recordset von ADO und
DAO bringt es eine hierarchische Ansicht der Daten zurück. Bei der Benutzung der Eigenschaften und Kollektionen im DataSet-Objekt kann man Zeilen, Spalten, einzelne Tabellen
und Beziehungen zwischen Tabellen erhalten.
Das DataTable-Objekt ist ein Objekt von DataSet, es ermöglicht die Manipulation von einzelnen Tabellen. Das Datatable-Objekt ist mit dem Recordset in ADO vergleichbar. Mit dem
DataView-Objekt kann man die Daten filtern, sortieren und unterschiedliche Ansichten von
Daten behalten. Jedes DataTable hat eine Standardansicht, die nach der Initialisierung verändert und in eine andere DataView gespeichert werden kann.
Abb. 3.4: Zwei unterschiedliche Data Providers von ADO .NET [Bark02]
27
Mit dem DataRow-Objekt kann man die Zeilen in einer DataTable manipulieren. Die Manipulation wie Addieren, Löschen oder Aktualisieren findet erst im Cache statt. Mit den
SQL-Anweisungen kann man die Änderung in die Datenbank weiter schicken. Mit dem DataColumn-Objekt kann man die Informationen aus den Spalten der DataTable erhalten. Und
das PrimaryKey-Objekt erlaubt, dass man einen Primärschlüssel für eine DataTable definiert.
Das DataSet-Objekt ist eine Abstraktion der relationalen Datenbank. ADO .NET benutzt DataAdapter als eine Brücke zwischen DataSet und der Datenquelle. DataAdapter nutzt eine
Fill()-Methode, um die Daten von der Datenbank abzuholen und DataSet zu füllen.
Das DBConnection-Objekt repräsentiert eine Verbindung zu einer Datenquelle. Diese Verbindung kann von unterschiedlichen Command-Objekten zusammen benutzt werden. Mit
dem DBCommand-Objekt kann man einzelnen Befehl (normalerweise eine SQL-Anweisung
oder eine gespeicherte Prozedur) zur Datenbank schicken. Diese Objekte werden oft implizit
erzeugt, wenn man ein DataSet erstellt. Aber auf sie kann natürlich auch explizit zugegriffen
werden.
3.3
Visual Basic
Visual Basic ist eine Programmiersprache, mit der man die Programme und Anwendungen für
Microsoft Windows Familie entwickeln kann, sie basiert auf der Programmiersprache BASIC.
Heutzutage ist sie eine der populärsten Programmiersprachen in der kommerziellen Welt
wegen ihres schnellen Entwicklungsdauerns.
Der Befehlssatz von Visual Basic ähnelt dem von Basic, wurde jedoch an das Multitasking
und an die grafischen Eigenschaften von Windows angepasst. Somit enden beim Befehlssatz
bereits die Gemeinsamkeiten mit herkömmlichen Basic-Varianten. Hinter Visual Basic steckt
ein vollkommen anderes Konzept. Wie der Begriff „Visual“ im Namen bereits ausdrückt, spielt
der grafische Aspekt eine entscheidende Rolle. Im Gegensatz zu vielen anderen Programmiersprachen wird ein Visual Basic-Programm zunächst grafisch entwickelt, erst später erfolgt eine textuelle Programmierung. Dafür stellt Visual Basic eine grafische
Entwicklungsumgebung zur Verfügung. Somit ist Visual Basic viel mehr als nur eine Programmiersprache, denn es umfasst neben der eigentlichen Programmiersprache verschiedene Werkzeuge wie eine sehr leistungsfähige und komfortable Entwicklungsoberfläche,
einen Debugger zur Fehlersuche und ein Projektverwaltungssystem.
Visual Basic ist eine objektbasierte System, welches ereignisgesteuert arbeitet. Objektbasiert
bedeutet, dass sich das Programm aus Objekten zusammensetzt, die dem Benutzer grafisch
visualisiert werden. Ein Objekt kann hierbei z.B. eine Schaltfläche, eine Combo-Box oder ein
Laufwerkssymbol sein. Ereignisgesteuert bedeutet, dass das Programm ausschließlich auf
Ereignisse reagiert. Unter Ereignissen versteht man bestimmte Systemereignisse und Anwenderaktionen wie zum Beispiel Mausklicks und Tastatureingaben. Das bedeutet, die Er-
28
eignisse in VB sind die Trigger der Prozeduren, die Prozeduren werden erst aufgerufen, wenn
ein Ereignis passiert. Für jedes Steuerelement gibt es einen Satz von Ereignissen. Nach
Bedarf kann man die Programmcodes schreiben, die auf spezifische Ereignisse reagieren.
Zentrales Merkmal von Visual Basic ist seine Entwicklungsumgebung, die von Microsoft entwickelte IDE (Integrated Development Environment): Microsoft: Visual Studio .NET. Hier
werden die Programme grafisch aufbereitet und mit Funktionalität hinterlegt. Abb 3.5 zeigt die
Entwicklungsumgebung von Visual Basic .NET.
Am oberen Bildschirmrand befindet sich die Menüleiste, die den typischen Stil von Microsoft-Anwendungen hat und die Befehle anzeigt, die dem Entwickler für seine Programmerstellung zur Verfügung stehen. Die Symbolleiste darunter kann wie in anderen
Microsoft-Produkten beliebig angepasst und erweitert werden. Sie bietet einen schnellen
Zugriff auf häufig verwendete Befehle in der Programmierumgebung.
Abb. 3.5: Arbeitsbereich von Microsoft Visual Studio .NET
29
Zentrales Element der Entwicklungsumgebung ist das Entwurfsfenster, hier kann man die
Windows Form entwerfen und die Programmiercodes schreiben. Eine Form ist die Vorlage für
das spätere Programmfenster. Hier wird die grafische Programmoberfläche für die zu entwickelnde Applikation durch Einfügen von Steuerelementen aus der Werkzeugkiste, Grafiken
und Bildern entwickelt. Durch Doppelklick auf die Form oder ein Steuerelement kann man das
Codefenster öffnen und die Programmiercodes für die ausgewählte Form bearbeiten.
Die Werkzeugsammlung auf der linken Seite enthält die Werkzeuge, mit denen zur Entwurfszeit Steuerelemente in einer Form angeordnet werden können. Viele Elemente in dieser
Toolbox sind Standard-Windows-Bedienelemente, die man auch von anderen Windows-Programmen kennt. So gehören z.B. Textfelder, Befehlsschaltflächen und Listenfelder
zu den Steuerelementen.
Sowohl für die Form als auch für die auf ihr positionierten Steuerelemente sind bestimmte
Eigenschaften konfigurierbar. Dies erfolgt im Eigenschaftsfenster, welches eine alphabetisch
geordnete Liste der möglichen Eigenschaftseinstellungen enthält.
Das Projektfenster enthält die Liste der Formen und Module in dem aktuellen Projekt. Als
Projekt wird die Gruppe der Dateien bezeichnet, aus denen die gesamte Anwendung besteht.
Schon anhand dieses Projektfensters erkennt man, dass Visual Basic-Anwendungen modular
aufgebaut sind. Das zu erstellende Programm setzt sich aus mehreren Bestandteilen zusammen.
Visual Basic .NET ist eine objektorientierte Programmiersprache, deswegen besteht ein
VB .NET-Anwendung aus Klassen und Methoden. Die erste Form in dem Projekt kann man
auch als die erste Klasse in dem Projekt nennen. Jede Prozedur für das ausgelöste Ereignis
ist eine Methode in dieser Klasse. Man kann natürlich mehrere Klassen in das Projekt einfügen, um die Funktionalität des Programms zu erweitern und die Struktur des Programms zu
verbessern.
Es gibt zwei Arten von Methoden in VB .NET. Eine Sub-Methode kann eine Aufgabe durchführen. Man kann bei dem Aufruf der Methode Parameter übergeben, um die Aufgabe der
Methode zu steuern. Im Unterschied zu einer Sub-Methode liefert eine Funktion-Methode
einen Rückgabewert zurück. Durch die Benutzung des Schlüsselwortes AS kann man den
Typ des Rückgabewerts der Funktion-Methode bestimmen. Nachfolgend Beispiele für die
Methoden beider Typen:
Sub SomeMethod(ByVal Param As Integer)
Debug.WriteLine( _
"Here are the parameters received: " & Param)
End Sub
30
Function IsBigger(ByVal firstVal As Integer, _
ByVal secondVal As Integer) As Boolean
If firstVal > secondVal Then
Return True
Else
Return False
End If
End Function
Um eine VB .NET-Anwendung zu entwerfen, muss man zuerst ein Projekt erstellen. Visual
Studio .NET bietet viele Projekttypen, die man auswählen kann. Die Projektauswahl legt lediglich eine Reihe von Vorlagen und Voreinstellungen fest, die sich auch unabhängig von der
Auswahl treffen lassen. Die wichtigsten Projekttypen sind Windows-Anwendungen und Konsolenanwendungen. Um das VB-Programm von dem VisMap zu entwerfen wird der Projekttyp Windows-Anwendung benutzt.
Wenn ein Windows-Anwendung-Projekt erstellt wird, wird die erste Form der Anwendung
automatisch erstellt. Man kann dann die Eigenschaften von Steuerelementen auf dieser Form
konfigurieren. Wie schon gesagt ist Visual Basic eine objektorientierte Programmiersprache,
jedes Steuerelement ist ein Objekt. Man kann die Methoden und Eigenschaften für diese
Objekte definieren. Die Eigenschaften der Steuerelemente wie Schriftart, Schriftgröße, Titel,
Farbe, Position oder der Inhalt der Combo-Box werden im Eigenschaftsfenster geändert.
Nach Anklicken des entsprechenden Steuerelementes werden dessen Eigenschaften im Eigenschaftsfenster angezeigt. Zur Festlegung einer Eigenschaft wählt der Entwickler den entsprechenden Eintrag aus, der in der rechten Hälfte des Eigenschaftsfensters bearbeitet
werden kann. Dabei erscheint entweder ein Textcursor zur Texteingabe, oder es wird ein Pfeil
nach unten eingeblendet, mit dem ein Auswahlmenü geöffnet werden kann, welches die
möglichen Werte enthält.
Die eigentliche Programmierung erfolgt im so genannten Codefenster. Unter Visual Basic ist
der Code in Prozeduren unterteilt und häufig bestimmten Steuerelementen zugeordnet.
Deshalb öffnet sich das Codefenster nach dem Doppelklick auf ein Steuerelement. Das zu
erstellende Programm arbeitet ereignisgesteuert, d.h. die Anweisungen beziehen sich auf ein
bestimmtes Ereignis. Im Codefenster werden in der rechten Listbox alle Ereignisse angezeigt,
die zu dem in der linken Box angegebenen Steuerelement ausgelöst werden können. Daher
setzen sich die Namen der Prozeduren meistens aus dem Namen des ausgewählten Steuerelementes und der Bezeichnung des ausgelösten Ereignisses zusammen. Ein typisches
Beispiel dafür ist:
Private Sub btnShow_Click(ByVal sender As System.Object, ByVal
e As System.EventArgs) Handles btnShow.Click
MessageBox.Show("Hello World.")
End Sub
31
3.4
Unterschiede zwischen VB und VB .NET
Visual Basic .NET ist eine Überarbeitung von Visual Basic von Microsoft für
die .NET-Plattform. Es unterscheidet sich in bedeutende Hinsicht von den früheren Versionen
von Visual Basic.
Eine der wichtigsten Änderungen ist, dass VB .NET endlich eine echte objektorientierte Programmiersprache geworden ist. Mit dem neuen Schlüsselwort „Inherites“ unterstützt jetzt
VB .NET die Erbung von Objekten, die neue Klasse kann dann alle Methoden und Interfaces
von der Basisklasse haben, aber nur die Methoden mit dem Schlüsselwort „Overridable“ in
der alten Klasse können ersetzt werden. VB .NET unterstützt auch Polymorphismus, man
kann jetzt mit dem Schlüsselwort „Overloads“ Methoden mit selbem Name aber unterschiedliche Eingabeparameter erzeugen. Außerdem kann man auch einen Constructor in der
Klasse definieren, damit man beim Erzeugen der neuen Instanz der Klassen Parameter übertragen kann.
Ein weiterer Fortschritt von VB .NET ist die Fehlerbehandlung. Die unstructured error handling „On Error Goto“ in der früher VB-Version ist nicht geeignet für die Entwicklung der Enterprise-Level-Anwendungen.
Sie
verursacht
hohe
Weiterentwicklungsund
Verwaltungskosten. VB .NET unterstützt zwar wegen der Kompatibilität die alte Mode weiter,
bietet aber eine viel schönere und leistungsfähigere Fehlerbehandlung: die „structured exception handling“. Mit „Try … Catch … Finally“ kann der Code die unterschiedlichen Exceptions unterscheiden und dann passende Reaktionen aufrufen.
In der Vergangenheit wurde Visual Basic als eine Programmiersprache zweiter Klasse behandelt. Die Herausforderung der Software-Entwicklung von Enterprise Niveau konnte nicht
erfüllt werden. Dies ist nicht mehr so in VB .NET. Der von VB .NET erzeugte Code ist fast
gleich wie der von C# oder anderen .NET unterstützten Sprachen erzeugte Code. Es gibt
keine Performance- oder Größenachteile, wenn man in VB .NET programmiert. Eigentlich gibt
es zwischen VB .NET und C# nur syntaktische Unterschiede. Man kann sogar ein
VB .NET-Programm leicht zu einem C#-Programm konvertieren. Solche Software existiert
schon im Internet.
Im Prinzip gibt es gar keine Sprache VB .NET oder C#, es gibt nur eine .NET-Sprache: MSIL
(Microsoft Intermediate Language). Die VB .NET- und C#-Compiler erzeugen beide die
MSIL-Codes, und die von den beiden Compiler erzeugte MSIL-Codes sind fast identisch.
32
4. Geo-Informationssysteme
Der Inhalt dieses Kapitels orientiert sich am " Grundlagen der Geo-Informationssysteme“ von
Ralf Bill [Bi99], „Geoinformatik in Theorie und Praxis“ von Norbert Lange [La02] und „Lexikon
der Geoinformatik“ von Ralf Bill und Marco Zehner [BiZe01].
Geoinformation ist raumbezogene Information und beschreibt unseren Lebensraum, unser
Umfeld im Kleinen wie im Großen, ob es sich um lokale Details handelt wie etwa Gebäude,
Grundstücke, Leitungen und Hausanschlüsse, oder um eine globale Zusammenschau von
Verkehrswegen, Umweltaspekten und Wirtschaftsräumen. Laut [BiZe01] ist ein Geoinformationssystem so definiert:
„Ein Geoinformationssystem (GIS) ist ein rechnergestütztes System, das
aus Hardware, Software, Daten und den Anwendungen besteht. Mit ihm
können raumbezogene Daten digital erfasst und redigiert, gespeichert und
reorganisiert, modelliert und analysiert sowie alphanumerisch und graphisch präsentiert werden.“
Ein GIS soll die raumbezogenen Massendaten verwalten können. Es soll auch die vielfältigen
Datenbankabfragen unterstützen wie zum Beispiel: Existenz, Position, Eigenschaften von
Geoobjekten. Es kann auch das System den Nutzeranforderungen anpassen. Die Lernfähigkeit des Systems kann GIS auch unterstützen.
Die Vorteile der GIS-Technologie sind vielfältig: Sie kann die manuellen Erfassungs-, Zeichen- und Kartierarbeiten entlasten. Mit ihr kann die Redundanz von Geodaten vermieden
werden; erfasste Geometrie- und Attributdaten können vielfach genutzt werden; die Datenqualität (Aktualität, Metadaten) können dadurch verbessert werden; die Auskunfts-, Auswertungs- und Entscheidungsmöglichkeiten durch Raumanalysen können verbessert werden; die
Informationsqualität kann durch die Visualisierung verbessert werden; das Management der
fachübergreifenden GIS-Projekte wird auch verbessert.
4.1
Geoobjekte
Die
raumbezogenen
Informationen
von
Objekten
sind
Kennzeichen
der
Geo-Informationssysteme. Als Geoobjekte treten Punkte, Linien, Flächen und Körper auf.
Laut [La02] werden Geoobjekte wie folgt definiert:
„Geoobjekte sind räumliche Elemente, die zusätzlich zu Sachinformationen
geometrische und topologische Eigenschaften besitzen und zeitlichen Veränderungen unterliegen können. Kennzeichnend für Geoobjekte sind somit
Geometrie, Topologie, Thematik und Dynamik.“
33
Die Geometrie eines Geoobjektes beschreibt die Position des Geoobjektes auf der Basis eines eindeutigen räumlichen Bezugssystems. Um die Lage der Geoobjekte zu beschreiben,
kann man zwei Arten von Metrik benutzen: die primäre Metrik und die sekundäre Metrik. Die
primäre Metrik beschreibt die exakte Festlegung durch Koordinatensystem, man kann zum
Beispiel die Geoobjekte in globalen Koordinatensystemen durch geodätische Koordinaten
oder GPS-Koordinaten darstellen, oder eine Karte mit einer bestimmten Kartenprojektion erzeugen, die die gekrümmte Erdoberfläche in einer zweidimensionalen Ebene abbildet. Die
sekundäre Metrik beschreibt nur die unscharfe Festlegung, man kann zum Beispiel mit
Kennziffern, Adressen oder Namen die Positionen der Geoobjekte beschreiben.
Außer Koordinatensysteme, die die Eigenschaft für einzelnen Punkt beschreiben, sind räumliche Beziehungen von Geoobjekten zueinander auch nicht verzichtbar. Die Topologie der
Geoobjekte beschreibt die Umgebungsbeziehungen, die Nachbarschaftsbeziehungen, die
Teilmengen- oder Enthaltensbeziehungen oder die Überdeckungs- oder Überschneidungsbeziehungen der Geoobjekte. Der Unterschied zwischen Geometrie und Topologie liegt darin,
dass die Topologie sich gegenüber topologischen Transformationen nicht verändert, während
die Geometrie sich verändert. Ein Beispiel für die Hervorhebung topologischer Aspekte und
die Unterdrückung der Geometrie ist die schematische Darstellung der Verbindungen des
öffentlichen Verkehrs. In dieser schematischen Darstellung ist nur das Vorhandensein der
Verbindungen der Verkehrsknotenpunkte von Bedeutung, die exakten Positionen der Verkehrsknotenpunkte sind nicht relevant.
Abb. 4.1: Merkmale der Geoobjekte [AsJa04]
Wie alle anderen Objekte besitzt jedes Geoobjekt auch eine Thematik. Während die Geometrie die räumlichen Informationen von Geoobjekten und die räumlichen Beziehungen zueinander von Geoobjekten beschreibt, gibt die Thematik den Geoobjekten die inhaltliche bzw.
semantische Bedeutung, zum Beispiel physikalische, chemische, funktionale oder soziale
Bedeutung. Es gibt zwei Arten von Thematik: die qualitativen Objektmerkmale und die quantitative Objektmerkmale. Die qualitativen Objektmerkmale beschreiben die Gliederungen
34
nach Merkmalen ihrer Beschaffenheit, und die quantitativen Objektmerkmale sind die größen-,
mengen-, wertmäßige oder relative Ausprägung der Geoobjekte.
Um die verschiedene Thematik von Geoobjekten zu beschreiben, zu bearbeiten und zu
speichern, werden das Ebenenprinzip und das Objektklassenprinzip verwendet. Beim Ebenenprinzip werden die Geometrie der Objekte und deren Attribute streng nach den verschiedenen thematischen Bedeutungen getrennt und in verschiedenen Ebenen vorgehalten.
Beim Objektklassenprinzip gibt es eine Hierarchie zwischen Objektklasse, Objekt und Objektteil, die nach oben offen ist. Diese Hierarchie kann streng eingehalten werden, was zu
einem thematischen Baum führt, oder aber es werden netzwerkartige Verknüpfungen zugelassen.
Die Dynamik der Geoobjekte bezeichnet die zeitlichen Änderungen der Geometrie, Topologie
und Thematik der Geoobjekte. Die Änderungen der Thematik sind am einfachsten realisierbar.
Einzelnen Attributen können Zeitabschnitte für die Gültigkeit der einzelnen Ausprägungen
zugewiesen werden. Für die Verwaltung der zeitlichen Veränderung der Geometrie oder
Topologie von Geoobjekten sind schwer zu implementieren. Diese beschränken sich oft
darauf, zu bestimmten Zeitpunkten Schnappschüsse zur Verfügung zu stellen.
4.2
Modellierung von Geoobjekten
Unsere Welt ist in vielen Fällen ein Kontinuum, in der Regel ist es nicht möglich, eine kontinuierliche Welt direkt in einem System abzubilden. Um die raumbezogenen Daten der realen
Welt digital erfassen, speichern, verwalten, aktualisieren, und analysieren sowie alphanumerisch und graphisch präsentieren zu können, muss man die reale Welt zuerst modellieren.
Diese Modelle entsprechen den Verfahren zur Diskretisierung der Erdoberfläche. Die wichtigsten Modelle sind das Vektormodell und das Rastermodell.
Abb. 4.2: Rastermodell und Vektormodell
Im Vektormodell wird die Geometrie eines Geoobjektes direkt durch Koordinaten aufgezeichnet. Ein Punkt wird über eine X-, eine Y- und gegebenenfalls über eine Z-Koordinate
(Rechtswert, Hochwert, Höhe) genau beschrieben. Eine Linie kann durch zwei solche Tupel
35
bzw. Tripel und eine Fläche durch einen geschlossenen Linienzug, d.h. mindestens drei Tupel bzw. Tripel angegeben. Im Vektormodell werden im Prinzip nur Punkte erfasst, Linien und
Flächen müssen aus Punkten bzw. Vektoren aufgebaut werden.
Die Topologie der Geoobjekte kann jedoch nicht so einfach im Vektormodell modelliert werden. Man muss hier die topologischen Beziehungen der Geoobjekte explizit erfassen, modellieren und speichern. Zum Beispiel muss gespeichert werden, welche Geoobjekte benachbart
sind und damit eine Linie definieren, und welche Linien eine spezielle Fläche begrenzen.
Vektormodell
Vorteile
z
Rastermodell
hohe geometrische Genauig-
z
einfache Datenstrukturen
keit
z
geringer Aufwand bei Erfassung
z
eindeutige Objektbeschreibung
z
geringe Datenmengen
z
größere Ähnlichkeit der gra-
der Geometrie und Topologie
z
phischen Präsentation mit tra-
und Scannerdaten
z
ditionellen Karten
Nachteile
komplexere Datenstrukturen
z
aufwändige
z
einfache logische und algebraische Operationen
z
z
kompatibel mit Fernerkundungs-
Erfassung
z
keine Form- und Lagetreue der
Geoobjekte
von
Geometrie und Topologie
z
höherer Speicheraufwand
aufwändige und recheninten-
z
kleine Pixelgröße mit explodie-
sive logische und algebraische
renden Datenmengen für höhere
Operationen
Genauigkeitsanforderungen
parallele
geometrische
und
z
topologische Beschreibung der
Geoobjekte
weniger
zufrieden
stellende
graphische Präsentation
z
aufwändige
Koordinatentrans-
formationen
Tab. 4.1: Vergleich von Vektor- und Rastermodell ([La02])
Das Rastermodell basiert auf der Unterteilung eines Interessenbereichs in Elemente bestimmter Größe. Man bezeichnet diese Teilflächen als Mosaik. Die Mosaike weisen am häufigsten quadratische oder rechteckige Rasterzellen bzw. Pixel auf. Die Geometrie der
Geoobjekte wird durch Angabe der sie ausfüllenden Pixel beschrieben. Da im Rastermodell
36
jeder Pixel gespeichert werden muss, hat es einen großen Speicherplatzbedarf. Und der
Speicherplatzbedarf steigt bei zunehmender Auflösung erheblich an.
Im Rastermodell muss die Topologie der Geoobjekte nicht explizit angegeben werden. Die
Topologie ist bereits direkt durch Angabe der Geometrie definiert. Zum Beispiel sind zwei
Rasterzellen benachbart, wenn sie eine gemeinsame Zellkante besitzen oder wenn sie mindestens eine gemeinsame Zellecke besitzen.
Die beiden Modelle haben Vor- und Nachteile, und werden nach Bedarf in den verschiedenen
Bereichen verwendet. Das Vektormodell wird wegen seiner höheren Genauigkeit und Eindeutigkeit für das Vermessungs- und Katasterwesen bzw. in der Infrastrukturplanung sowie
generell für großmaßstäbige Anwendungen benutzt. Das Rastermodell wird für kleinmaßstäbige Anwendungen und für die Bildverarbeitung verwendet. Einen Vergleich von Vektor- und
Rastermodell zeigt Tabelle 4.1.
4.3
Präsentation von Geoobjekten
Die Daten in den Datenbanken allein sind nutzlos, wenn man sie nicht je nach Bedarf präsentieren und austauschen kann. Man muss die Ergebnisse der Datenverarbeitung und der
Datenmanipulation im GIS in einer Form präsentieren, die für die Benutzer verständlich und
lesbar ist. Es gibt folgende Möglichkeiten, um die Geoobjekte zu präsentieren:
-
digitaler Datentransfer auf rechnerlesbaren Medien oder via Netzwerk,
nichtgraphische Formen wie Tabellen, Berichte,
passive Graphik in Form von Karten,
interaktive Graphik am Bildschirm in Form von kartenähnlichen und sonstigen graphischen Darstellungen.
Die oben genannten Präsentationsarten können in Kombination miteinander verwendet
werden. So können zum Beispiel in einer interaktiven Graphik Tabellen oder Berichte eingebettet werden, damit man einen klareren Überblick über die Informationen des jeweiligen Interessenbereichs erhält.
In dieser Diplomarbeit werden die Geoobjekte als interaktive Graphik präsentiert, deswegen
ist die visuelle Präsentation der Geoobjekte von großer Bedeutung. Das menschliche Sehvermögen bietet eine wichtige Hilfe beim Erkunden und Verstehen räumlicher Strukturen und
Prozesse. Die Darstellung von Geoobjekten in visueller, bildhafter Form besitzt daher eine
wesentliche Bedeutung für die Analyse und Interpretation von Zusammenhängen und Veränderungen. Die Modellierung und Entscheidungsfindung werden wirkungsvoll unterstützt.
Die Visualisierung gehört zu den am frühesten benutzten und am häufigsten eingesetzten
Wahrnehmungstechniken der Umwelt des Menschen. Information und Kommunikation mittels
37
Visualisierung geschieht häufig unbewusst und intuitiv. Visualisierung ist die Transformation
von Daten in ein sichtbares Bild zur Unterstützung der Erkundung, des Erkennens und der
Erklärung von Strukturen und Prozessen. Visualisierung ist damit eine wichtige Methode für
den wissenschaftlichen Erkenntnisprozess und zugleich ein Verfahren zur raschen Übermittlung komplexer Informationen zwischen Wissenschaft und Praxis.
Die moderne Kartographie orientiert sich an einer Modelltheorie, in der die drei Zustände ineinander überführt werden. Das Original in Form der abzubildenden Landschaft oder eines
problemabhängigen Ausschnitts der Realität wird in ein Primärmodell (Datenmodell) überführt, aus dem beliebige Sekundärmodelle (Präsentationsmodelle) abgeleitet werden können. Die Datenerfassung und Modellierung der Geoobjekte der realen Welt führt zu dem
Primärmodell. Das Primärmodell ist eine 1:1 Abbildung der Realität. Bei der visuellen Präsentation der Geoobjekte sind die Betrachtung und der Aufbau von Sekundärmodellen als
Ableitung aus den jeweiligen Primärmodellen notwendig. Bei einem Präsentationsmodell
handelt es sich um ein kartographisches Modell, das z.B. die kartographischen Signaturen
definiert. Im Gegensatz zu Primärmodellen müssen die Sekundärmodelle nicht unbedingt
eine 1:1 Abbildung der Realität sein.
Die Aufgabe des Präsentationsmodells besteht somit in der Umsetzung kartographischer
Darstellungsformen, die in ihrem Erscheinungsbild völlig losgelöst vom jeweiligen Datenmodell sein können. Es muss umgekehrt jedoch möglich sein, aus jedem beliebigen Datenmodell eine kartographische Darstellung zu entwickeln. Der angestrebte Übergang vom
Datenmodell zum Präsentationsmodell wird über Maßnahmen der Modellgeneralisierung bzw.
der kartographischen Generalisierung erreicht. Während die Modellgeneralisierung den Übergang von einem Objektmodell zu einem anderen Objektmodell behandelt, strebt die kartographische Generalisierung den Übergang von Objektmodell zum kartographischen Modell
an.
4.4
Kartenprojektion
Die Position jedes Geoobjektes auf der Erdoberfläche kann durch das geodätische Koordinatensystem genau bestimmt werden. In diesem System sind der Nullmeridian und der Äquator die Referenzebenen. Der Äquator teilt die Erdkugel in zwei Hälften: Die nördliche und
die südliche Halbkugel, wobei der Äquator selbst senkrecht zur Erdachse steht. Die anderen
Breitenkreise verlaufen parallel dazu, insgesamt 90 in nördlicher sowie 90 in südlicher Richtung vom Äquator aus gesehen. Der Greenwich-Meridian ist der so genannte Nullmeridian. In
ost-westlicher Richtung von dem Nullmeridian liegen die einzelnen Längenkreise nebeneinander, wobei diese jeweils den Nord- und den Südpol verbinden. Die geodätische Länge φ ist
der Winkel zwischen der Meridianebene von Greenwich und der Meridianebene des aktuellen
Punktes, die geodätische Breite λ ist der Winkel zwischen der Ellipsoidnormale im aktuellen
Punkt und der Äquatorebene. Die ellipsoidische Höhe h ist die Höhe eines Punktes über
seinem Lotfußpunkt auf dem Ellipsoid.
38
Abb. 4.3: geodätische Länge und Breite, ellipsoidische Höhe [Bart00]
Das geodätische Koordinatensystem beschreibt die Position der Geoobjekte auf einer gekrümmten Oberfläche. Um sie in einer flachen Karte darzustellen müssen die geodätischen
Koordinaten durch bestimmte mathematische Formeln auf eine rechtwinklige (kartesischen)
Koordinaten übertragen werden. Falls der Ursprung des kartesischen Koordinatensystems
mit dem Zentrum des Rotationsellipsoides zusammenfällt und die x-Achse das Ellipsoid am
Punkt φ=0, λ=0 durchstößt, so gilt:
⎛ x ⎞ ⎛ [ N + h] cos ϕ cos λ ⎞
⎟
⎜ ⎟ ⎜
⎜ y ⎟ = ⎜ [ N + h] cos ϕ sin λ ⎟
⎜ z ⎟ ⎜ [ N (1 − e 2 ) + h] sin ϕ ⎟
⎝ ⎠ ⎝
⎠
Wobei N = a (1 − e 2 sin 2 ϕ )
−
1
2
und a die große Halbachse sowie e die numerische Exzentri-
zität des Ellipsoides ist.
Eine gekrümmte Oberfläche kann nicht verzerrungsfrei in die Ebene abgewickelt werden,
deswegen muss man die Erdeoberfläche auf mehrere Bereiche aufteilen, dann die lokale
Bereiche abbilden und die Abbildung stückweise zusammensetzen. In Deutschland und Österreich wird die Gauß-Krüger-Projektion verwendet. Die GK-Projektion umfasst 120 Meridianstreifen zu je 3 Grad. Jeder Meridianstreifen erhält eine Kennziffer. Dabei bekommt der
Nullmeridian die Kennziffer 0 zugewiesen. Nach Osten wird aufwärts gezählt, und nach
39
Westen abwärts gezählt. In jedem Streifen wird ein rechtwinkliges Koordinatensystem gelegt,
die Y-Achse (Rechtswert) wird am Äquator gelegt, und die X-Achse (Hochwert) wird auf den
Hauptmeridian gelegt. Der Rechtswert gibt die Entfernung vom Hauptmeridian bis zum Punkt
an, und der Hochwert die Entfernung von Äquator auf dem abgebildeten Hauptmeridian bis
zum Ordinatenfußpunkt. Der Rechts- und Hochwert wird in Metern angegeben. Um beim
Rechtswert negative Werte zu vermeiden, wird zu diesem Wert häufig ein konstanter Wert
von 500.000 m addiert. Vor diesen Wert wird die Kennziffer des Meridianstreifens gesetzt. Als
Hochwert wird immer die Entfernung vom Äquator angegeben. Ein Punkt mit Hochwert
15.932.432 m und Rechtswert 4.568.211 m bedeutet, dass er 15.932.432 m vom Äquator
entfernt ist, und liegt im 4. Meridianstreifen bei +68.211 m.
In der bundesdeutschen Landesvermessung gibt es im Randbereich eines Meridianstreifens
jeweils ein „Überlappungsbereich“ mit einer Breite von 1 Grad und 40 Minuten. Im Überlappungsbereich werden für jeden Punkt die Koordinaten im jeweiligen Meridianstreifen und die
Koordinaten des benachbarten Meridianstreifens angegeben.
40
5.
Modellierung von Geoobjekten in VisMap
Die Geoobjekte der realen Welt können nicht direkt in die Datenbank gespeichert und auf der
Bildschirmkarte visualisiert werden. Sie müssen zuerst nach den Verwendungszwecken und
gemäß verschiedenen Maßstäben abstrahiert und durch einfache geometrische Objekte
modelliert werden. Diese geometrischen Objekte können dann mit der Verwendung eines
Präsentationsmodells auf dem Bildschirm visualisiert werden.
In VisMap wird Microsoft Access als DBMS verwendet. Weil Access ein relationales DBMS ist,
wird hier das relationale Modell benutzt. Als Beispiel wird in VisMap das Autobahn- und Eisenbahnnetz Deutschlands verwendet. Weil es sich um ein Infrastrukturnetz handelt, wird hier
für die Modellierung der Geoobjekte ein Vektormodell benutzt, das Genauigkeit bzw. Eindeutigkeit verlangt.
Abb. 5.1: ER-Diagramm von VisMap
Die Anforderungen der Datenbank sind stark von der jeweiligen Anwendung abhängig. In
dieser Diplomarbeit soll die Datenbank in der Lage sein, alle Informationen zu erhalten, aus
denen eine Karte vom Verkehrsnetz Deutschlands durch ein VB .NET-Programm automatisch generiert und auf den Bildschirm angezeigt werden kann. Außerdem soll sie auch die
allgemeinen Metadaten der Geoobjekte erhalten, um die verschiedenen Suchkriterien verwenden zu können.
41
Für die Beispielsanwendung sollen folgende Geoobjekte modelliert und in der Datenbank
gespeichert werden: Städte, Flughäfen, Infrastrukturen zwischen zwei benachbarten Städten,
Zuglinien, Autobahnlinien, Bundesländer und Länder. Weil die Geoobjekte nicht nur tabellarisch in der Datenbank gespeichert, sondern auch in Form einer Karte auf den Bildschirm
angezeigt werden, wird die Modelltheorie der Kartographie verwendet. Wie im letzten Kapitel
dargelegt, gibt es in der Kartographie zwei Modelle der Geoobjekten der realen Welt: das
Primärmodell (Datenmodell) und das Sekundärmodell (Präsentationsmodell). In den zwei
Vorgängerarbeiten wird nur das Primärmodell in der Datenbank gespeichert, das Präsentationsmodell wird aber im VB-Programm festgelegt. Der Nachteil ist offensichtlich: Der Endnutzer kann das Präsentationsmodell nicht ändern, da das GUI dafür keine Funktion anbietet
und er auch keinen Zugriff auf die Quellcode des VB-Programms hat. Der Zeitaufwand für die
Anpassung des Programms ist sehr groß. Das VisMap-System speichert dagegen nicht nur
das Primärmodell, sondern auch das Präsentationsmodell in der Datenbank. Die Änderungen
des Präsentationsmodells kann man sowohl durch das GUI (Endnutzer) als auch durch direkte Bearbeitung in der Datenbank (Datenbankadministrator) realisieret werden.
5.1
Primärmodell der Geoobjekte
Das Primärmodell besteht aus den geometrischen und semantischen Beschreibungen der
Objekte der realen Welt sowie den zwischen ihnen bestehenden Beziehungen unabhängig
von einem konkreten Präsentationsmodell. Die Modellierung der Geometrie der Geoobjekte
ist fundamentaler Bestandteil des Primärmodells. Da wir hier das Vektormodell verwenden,
werden alle Geoobjekte als geometrische Formen modelliert, um sie in der Bildschirmkarte
darstellen zu können.
Die einfachsten geometrischen Formen sind Punkt, Linie und Vieleck. Wegen der Komplexität
der Geoobjekte sind solche einfache Formen nicht ausreichend, um ein zufrieden stellendes
geometrisches Modell der Geoobjekte zu gewinnen. Eine Zuglinie kann zum Beispiel nicht als
Linie modelliert werden, da sie mehrere Städte verbindet; sie ist deswegen nur durch ein
Polygon darstellbar. Analog können manche Länder nicht durch ein Vieleck präsentiert werden. Sie können aus mehreren Bezirken bestehen und deswegen nur mit einer Vieleckgruppe
modelliert werden.
Aus oben genannten Gründen werden in VisMap die Geoobjekte der realen Welt beim Aufbau
des Primärmodells als Punkt, Polygon oder Vieleckgruppe modelliert. Ein Geoobjekt kann
nach den verschiedenen Maßstäben und Anwendungszwecken unterschiedlich modelliert
werden. Eine Stadt kann zum Beispiel in einer Karte im großen Maßstab als Punkt, aber in
einer anderen Karte im kleinen Maßstab als Vieleckgruppe modelliert werden.
Die Thematik der Karte beeinflusst die Modellierung der Geoobjekte ebenfalls sehr stark. In
einem Stadtplan wird die Stadt als Vieleckgruppe modelliert, da nicht nur die Informationen
über die ganze Stadt, sondern auch detaillierte Informationen über die relevanten Entities in
42
der Stadt dargestellt werden. Die Verläufe der Straßen und die Positionen wichtiger Gebäude
sind die typischen Informationen, die in einem Stadtplan enthalten sein sollen. Solche Entities
liegen in der Stadt. Der Punkt ist die kleinste geometrische Einheit, nichts kann in einem
Punkt liegen. Deswegen kann die Stadt in einem Stadtplan nicht als Punkt, sondern nur als
Vieleckgruppe modelliert werden. Nur dann können die Details der Stadt richtig positioniert
und dargestellt werden. Die Bildschirmkarte in unserem Beispiel ist eine Karte des Verkehrsnetzes zwischen den Städten. Die Details der Stadt wie zum Beispiel die Position des
Rathauses oder der Verlauf einer bestimmten Straße sind irrelevant. Die Informationen der
Entities der Stadt sind ebenfalls irrelevant. Relevant sind die Positionen des Stadtzentrums
und die allgemeinen Metadaten der Stadt, um sie in der Karte zu positionieren und einen
Überblick über ihre wichtigsten Informationen der Stadt zu gewinnen. Deswegen genügt es in
dieser Situation, die Städte als Punkte zu modellieren.
Da VisMap eine 2D-Bildschirmkarte erzeugt, wird jeder Punkt durch ein Tupel Koordinaten
festgelegt. Das Bezugssystem, das hier benutzt wird, ist WGS84. Die Position eines Geoobjekts der realen Welt wird durch ihre geodädische Breite (Latitude) und Länge (Longitude)
eindeutig definiert. Die Breite bezieht sich auf den Äquator und reicht von 90 Grad Nord bis 90
Grad Süd. Die Länge bezieht sich auf den Nullmeridian, der durch Greenwich verläuft. Längengrade liegen im Bereich von 180 Grad West bis 180 Grad Ost. Die Geoobjekte City und
Airport werden im diesen Beispiel durch Punkt modelliert.
Abb. 5.2: Modellierung des Geoobjektes des Typs „City“
Die Metadaten der Geoobjekte City und Airport werden in den Tabellen „MetaDaten_city“ und
„MetaDaten_airport“ abgelegt. In unserem Beispiel werden nur einige wichtige Eigenschaften
der Geoobjekte gespeichert. Später lassen sich die Felder der zwei Tabellen nach Bedarf
beliebig erweitern. Diese Vereinfachung gilt auch für andere Geoobjekte.
Die Straßenlinien und Infrastrukturen sind die wichtigsten Geoobjekte in diesem Beispiel. Sie
präsentieren die topologischen Beziehungen zwischen den Städten und können daher nicht
43
als Punkte modelliert werden, da ein Punkt selbst keine topologische Bedeutung hat. In einem
Architekturplan ist es für die Gebäude nötig, die Straßen als Vieleckgruppe zu modellieren, da
es sich um eine Karte im kleinen Maßstab handelt, und ihre Breite und andere Details für die
Anwendung relevant sind. In unserem Beispiel sind die Straßen und Infrastrukturen in einer
Karte im großen Maßstab, denn detaillierte Informationen über eine Straße sind unwichtig.
Die Straßenlinien oder Infrastrukturen präsentieren die topologischen Beziehungen zwischen
den Städten, deswegen wird hier der Linienzug benutzt. Wegen des Aufwands der Datengewinnung werden die Verläufe der Straßenlinien und Infrastrukturen in VisMap stark vereinfacht, die Straßen zwischen zwei Städten werden nur als Linien modelliert. Aber in der
Datenbank werden sie immer als Linienzüge gespeichert, da die Linie ein Sonderfall des Linienzugs ist.
Eine Linie verbindet zwei Punkte. Sie kann nur existieren, wenn ihr Anfangspunkt und Endpunkt schon existiert. Sie beschreibt auch die Topologie zwischen zwei Punkten. Die Geometrie einer Linie wird durch die Koordinaten des Anfangspunktes und des Endpunktes der
Linie gegeben. Die Linie präsentiert kein Objekt der realen Welt, sie ist nur der Baustein des
Linienzugs.
Abb. 5.3: Modellierung des Geoobjektes des Typs „Zuglinie“
Ein Polygon besteht aus einer oder mehreren Linien. Die Geometrie der durch Polygone
modellierten Geoobjekte wird durch die Geometrie der durch die Linie modellierten Geoobjekte bestimmt. Die Infrastruktur zwischen zwei Städten (Eisenbahn, Straße), Zuglinien, die
Autobahnlinien und die Wege zwischen zwei durch Nodes modellierten Geoobjekten werden
in diesem Beispiel durch Polygone modelliert. Die Metadaten der als Polygon modellierten
Geoobjekte von unterschiedlichen Typen werden in den Tabellen „MetaDaten_railway“,
„MetaDaten_street“, „MetaDaten_zuglinie“ und „MetaDaten_autobahnlinie“ gespeichert.
Der Fall für Bundesländer und Länder ist viel übersichtlicher. Die Städte sind als Punkte
modelliert und liegen in einem Land oder einem Bundesland. Die Straßen und Infrastrukturen
sind als Linienzüge modelliert und liegen in einem oder mehreren Ländern/Bundesländern.
Gleiches gilt für die Modellierung der Städte. Sie können nur als Vieleckgruppen modelliert
werden.
44
Das Primärmodell ist eine 1:1 Abbildung des problemabhängigen Abschnitts der Realität, und
jedem Objekt im Primärmodell wird eine geometrische Form zugewiesen. Deswegen werden
die topologischen Beziehungen zwischen den Geoobjekten der realen Welt durch die topologischen Beziehungen zwischen den geometrischen Formen repräsentiert. Im VB-Programm
wird nur die Beziehung zwischen den geometrischen Formen betrachtet.
Die Punkte sind die atomarsten Entities. Sie sind abhängig von keiner anderen geometrischen Form. Eine Linie ist durch genau einen Startpunkt und einen Endpunkt festgelegt, aber
ein Punkt kann der Start-/Endpunkt von beliebig viele Linien sein. Ein Polygon kann aus einer
oder mehreren Linien bestehen. Ein Vieleck ist begrenzt durch genau ein abgeschlossenes
Polygon, und ein Polygon begrenzt auch maximal ein Vieleck. Eine Vieleckgruppe besteht
aus einem oder mehreren Vielecken.
Um die Geoobjekte der realen Welt auf der Bildschirmkarte zu visualisieren, soll ein Sekundärmodell (Präsentationsmodell) aufgebaut werden. Die in der Bildschirmkarte angezeigten
Objekte sind die Abbildung dieser geometrischen Objekte und damit auch die Abbildung der
Objekte der realen Welt. Die Eigenschaften der Objekte im Präsentationsmodell bestimmen
die Visualisierungsform der geometrischen Objekte. So können für einen bestimmten Typ
geometrischer Objekte wie zum Beispiel die Linien verschiedene Farben, Breiten oder Stile
definiert werden.
Abb. 5.4: Modellierung des Geoobjektes des Typs „State“
Ein Vieleck ist von einem abgeschlossenen Polygon begrenzt. Die Geometrie eines Vielecks
wird durch die Koordinaten seiner Eckpunkte bestimmt. Die Vieleckgruppe kann aus einem
oder mehreren Vielecken bestehen. Im diesen Beispiel werden die Bundesländer, das ganze
Deutschland und die Seen durch die Vieleckgruppe modelliert. Die Metadaten der als Vieleckgruppe modellierten Geoobjekte unterschiedlicher Typen werden in den Tabellen „MetaDaten_state“ und „MetaDaten_country“ gespeichert.
45
5.2
Präsentationsmodell der Geoobjekte
Durch die Modellierung des Primärmodells lassen sich bereits die Informationen der relevanten Geoobjekte in die Datenbank speichern und somit manipulieren. Aber um die Geoobjekte in der Bildschirmkarte zu visualisieren, muss noch ein Sekundärmodell
(Präsentationsmodell) aufgebaut werden.
Jedes durch Punkte modellierte Geoobjekt kann durch „Nodes“ in der Bildschirmkarte dargestellt werden, dessen Position von der Koordinate des zugrunde liegenden Punktes umgerechnet ist. Alle Nodes werden in der Tabelle „node“ gespeichert. Das Feld „typeID“ zeigt den
Typ des Nodes. Den verschiedenen Node-Typen können unterschiedliche Darstellungsformen zugewiesen werden. Zum Beispiel kann eine Stadt durch ein Kreis mit einem schwarzen
Punkt in der Mitte dargestellt werden oder ein Flughafen durch ein blaues Fugzeug. Diese
Informationen werden in der Tabelle „nodeType“ gespeichert. Die Darstellungsformen der
Nodes werden durch unterschiedliche Bilder bestimmt. Die Bilder werden in der Tabelle
„images“ gespeichert. Man kann mit dem GUI nicht nur die Darstellungsform des Nodes ändern, sondern auch neue Bilder in der Datenbank hinzufügen.
Die durch Polygone modellierten Geoobjekte können durch „Path“ in der Bildschirmkarte dargestellt werden. Da sie aus Linien bestehen, werden ihre Positionen in der Bildschirmkarte
durch die Positionen der bestehenden Linien abgeleitet. Die Positionen der Linien werden von
den Koordinaten der zugrunde liegenden Start- und Endpunkte umgerechnet. Die Darstellungsformen der Polygone werden durch verschiedene Linientypen, -farben und -breiten bestimmt. Solche Informationen werden in der Tabelle „polygonType“ gespeichert. Man kann für
verschiedenen Typen von Polygonen unterschiedliche Darstellungsformen zuweisen. Zum
Beispiel kann eine Eisenbahn durch eine schwarze Linie dargestellt werden, eine Straße
durch eine blaue Linie.
Die durch eine Vieleckgruppe modellierten Geoobjekte können durch „Region Set“ in der
Bildschirmkarte dargestellt werden. Da sie aus Vielecken bestehen, werden ihre Positionen in
der Bildschirmkarte durch die Position der bestehenden Vielecke abgeleitet. Die Vielecke sind
durch ein abgeschlossenes Polygon begrenzt, deswegen sind ihre Positionen durch die Positionen der Polygone bestimmt. Die Darstellungsformen der Vieleckgruppe werden durch die
Darstellungsformen der zugrunde liegenden Polygone und das Textur ihres Inneren festgelegt. Diese Informationen werden in der Tabelle „areaType“ gespeichert. Verschiedenen Typen von Vieleckgruppen können unterschiedliche Darstellungsformen zugewiesen werden.
Zum Beispiel kann die Landesgrenze durch eine Linie mit der Breite drei, und eine Bundesland-Grenze durch eine Linie mit der Breite eins dargestellt werden.
46
6.
VisMap
6.1
Systemarchitektur
Das VisMap-System besteht aus vier Hauptkomponenten: einer Access-Datenbank, die alle
Informationen über Geoobjekte enthält; einem benutzerfreundlichen GUI, durch das man mit
der Datenbank interagieren kann; dem Kartengenerator, der die Bildschirmkarte erstellt, und
dem Fenstermanager, der die Ereignisse vom GUI interpretiert und darauf reagiert.
Abbildung 6.1 zeigt die Struktur von VisMap. Es kann sowohl das GUI als auch Microsoft
Access benutzt werden, um auf die Datenbank zuzugreifen. Das GUI erzeugt Ereignisse
durch die Bedienung vom Nutzer, der Fenstermanager reagiert auf die Ereignisse und benutzt ADO .NET als Interface für den Zugriff der Jet Database Engine. Die Jet Database Engine dient als DBMS. Sie verarbeitet die SQL-Anweisungen und kommuniziert mit der
Datenbank. Nach der Bearbeitung der SQL-Anweisungen sendet die Jet Database Engine
dann die Ergebnisse der Abfragen zu dem ADO .NET Interface zurück. Das ADO .NET leitet
die Ergebnisse weiter zum Fenstermanager. Dieser bearbeitet die Eingaben vom ADO .NET
und sendet die Ergebnisse eventuell zum Kartengenerator, welcher die Koordinaten der
Geoobjekte konvertiert und eine Bitmap mit den Ergebnissen erzeugt und auf dem Bildschirm
präsentiert. Der andere Weg ist unkomplizierter: Microsoft Access ist das Standardinterface
für das Jet Database Engine. Es kommuniziert direkt mit diesem und bearbeitet die Datenbank mit den Anweisungen. Der Benutzer hat in Access alle Möglichkeiten, die Datenbank zu
manipulieren. Die Voraussetzung hierfür ist, dass er ausreichende Datenbankkenntnisse besitzt und Zugriffsrecht auf die Datenbank hat.
Um die nötige Sicherheit zu gewähren wird die Datenbank durch zwei Arten von Kennwörtern
geschützt. Auf Benutzerebene gibt es zwei Gruppen: die Gruppe „Administrator“ und die
Gruppe „Benutzer“. Jeder Benutzer hat sein eignes Kennwort und gehört zu einer oder mehreren Gruppen. Verschiedene Gruppe haben unterschiedliche Zugriffsrechte auf die Datenbank. Während die Mitglieder der Gruppe „Administrator“ Vollzugriff auf die Datenbank haben,
besitzen die Mitglieder der Gruppe „Benutzer“ nur beschränkten Zugriff. Sie können nur Datensätze in den Tabellen manipulieren, aber nicht die Strukturen der Tabellen ändern. Die
Sicherheit auf der Benutzerebene ist jedoch nicht ausreichend. Sie kann das Zugriffsrecht nur,
wenn die Datenbank mit Access geöffnet wird, kontrollieren. Wird auf die Datenbank direkt
durch den OLEDB-Provider zugegriffen, ist dieser Schützmechanismus umgangen. Der Programmierer hat dann Vollzugriff auf die Datenbank. Um diese Situation zu vermeiden, sollte
zusätzlich ein Datenbankkennwort für die Datenbank verwendet werden, das alle Benutzer
eingeben müssen, um die Datenbank öffnen zu können. Auch der Programmierer muss das
Kennwort kennen, um die Datenbank durch den OLEDB-Provider zu öffnen.
47
Ein normaler Benutzer von VisMap kann auf die Datenbank nicht direkt zugreifen. Nur mit
dem GUI hat er die Möglichkeit, mit Hilfe der Steuerelemente des graphischen Interfaces die
DML eingeschränkt zu benutzen, um die Daten in der Datenbank zu manipulieren. Er hat jedoch keine Möglichkeit, die DDL zu benutzen, um die Datenbankstruktur zu ändern. Der
Benutzer sollte die SQL-Anweisungen nicht direkt erteilen können, da es möglich ist, dass er
nicht genug Kenntnisse von Datenbanken besitzt und nicht in der Lage ist, die Datenbank
direkt mit den SQL-Anweisungen richtig zu bearbeiten. Die CheckBoxes, ComboBoxes,
TextBoxes und Menüs helfen ihm, korrekte SQL-Anweisungen zu konstruieren.
DatenbankAdministrator
GUI
Kartengenerator
MS Access
Nutzer
Fenstermanager
geodata.mdb
Jet Database Engine
ADO .NET
VisMap
DB-Back End
Abb. 6.1 Systemarchitektur von VisMap
Der Datenbankadministrator hat Vollzugriff auf die Datenbank. Er kann die Daten in der Datenbank sowohl durch das GUI als auch durch Microsoft Access manipulieren. Wenn er mit
Access arbeitet, kann er die SQL-Anweisungen direkt ausführen, die Datenbankstruktur ändern und die Datensätze abfragen. Was er in Access nicht ermöglichen kann, ist, die Daten
graphisch auf dem Bildschirm darzustellen. Hierin liegt auch der Grund, aus dem das GUI
aufgebaut wird.
48
6.2
GUI
Die Objekte in einem Geo-Informationssystem sind nicht abstrakte sondern reale Gegenstände, die durch Graphik auf dem Bildschirm simuliert werden können. Deswegen wird ein
GUI für die Datenbank entworfen. Das graphische Interface ist aus Nutzersicht der wichtigste
Bestandteil von VisMap. Mit seiner Hilfe kann ein Benutzer ohne Datenbankkenntnisse die
Daten in der Datenbank manipulieren. Das Ziel des GUI ist, ein benutzerfreundliches Interface für die Manipulation der Datenbank und eine interaktive Bildschirmkarte für die visuelle
Darstellung der Geoobjekte anzubieten. Das GUI besteht aus Steuerelementen. Die Klassen,
die das GUI konstruieren, erben die von .NET vordefinierte Klasse System.Windows.Forms.Form, um das graphische Interface unter dem Betriebssystem Windows
aufbauen zu können.
Abb. 6.2: Hauptfenster von VisMap
6.2.1
Layout der Bildschirmkarte
Das wichtigste Steuerelement des GUI ist die PictureBox1. Sie enthält die Bildschirmkarte.
Die Geometrie der Geoobjekte in VisMap wird durch die geometrischen Koordinaten (x, y)
beschrieben und das Koordinatensystem der PictureBox1 ist ein kartesisches Koordinaten-
49
system, das ideal dafür geeignet ist, alle Geoobjekte in der Datenbank in einer
2D-Bildschirmkarte zu präsentieren.
Die Bildschirmkarte in der PictureBox1 ist eine Bitmap, sie wird durch den Kartengenerator
erzeugt. Beim Starten des GUI wird eine Bitmap mit vorgegebenen Optionen generiert und in
der PictureBox1 angezeigt. Der vorgegebene Maßstab wird so definiert, dass alle Geoobjekte
der Datenbank in der PictureBox1 präsentiert werden können. Nachdem das GUI initialisiert
wurde, kann mit dem Mausklick der Maßstab der Karte vergrößert oder verkleinert werden.
Ebenso lassen sich per Mausklick auf die Bildschirmkarte die Tooltips mit Metadaten der
Geoobjekte und die ContextMenus für Löschen und Aktualisieren der Geoobjekte aktivieren.
Das Koordinatensystem der PictureBox1 ist das Windows-typische Koordinatensystem, sein
Unterschied zum kartesischen Koordinatensystem ist, dass der Ursprung des Koordinatensystems links oben liegt, und der positive Zuwachs der Y-Koordinate erfolgt nach unten hin.
Beim Kartesischen Koordinatensystem ist die Ordinate umgekehrt ausgerichtet, also von
unten nach oben zeigend. Da die Geometrie der Geoobjekte aber von dem geodätischen
Koordinaten beschrieben wird, müssen die Koordinaten zuerst konvertiert werden, damit die
Geoobjekte im Rang der Bildschirmkarte angezeigt werden können. Die Konvertierung erfolgt
in zwei Schritten: Zuerst wird eine Projektion von den geodätischen Koordinaten zu den ebenen rechtwinkligen Koordinaten durchgeführt, dann werden diese Koordinaten umgerechnet, um das Koordinatensystem der PictureBox1 anzupassen.
Zunächst wurde geplant, zuerst die Gauß-Krüger-Projektion anzuwenden und dann die
Gauß-Krüger-Koordinaten nach Maßstab zu verkleinern und zu verschieben, bis sie in der
PictureBox1 angezeigt werden können. Im unseren Beispiel befinden sich die geodätischen
Koordinaten der Geoobjekte in drei verschiedenen Meridianstreifen mit der Streifenbreite 3○.
Um sie in einer Karte darzustellen muss nach der Gauß-Krüger-Projektion noch eine Streifentransformation durchgeführt werden. Diese Transformation ist noch nicht im VB-Programm
implementiert. Deswegen wird im hier behandelten Beispiel der erste Schritt der Konvertierung übersprungen und die geodätischen Koordinaten werden direkt nach Maßstab verkleinert und verschoben. Dies stellt nur eine Zwischenlösung dar. Wenn das Problem der
Transformation zwischen verschiedenen Meridianstreifen gelöst wird, dann kann die alte
convert.vb leicht durch die neue ersetzt werden.
6.2.2
Steuerelemente des Hauptfensters
Das Hauptfenster des GUI besteht aus folgenden Steuerelementen: einer Menüleiste, einer
Statusleiste, einer PictureBox, einer RichtextBox bzw. ListBox, sowie diversen CheckBoxes,
ComboBoxes, TextBoxes, Labels und Buttons.
Mit Hilfe der Menüleisten kann ein Benutzer fast alle Funktionen von VisMap verwenden. Das
Submenü „File“ besteht aus „Open“ und „Exit“, womit eine gewünschte Datenbank geöffnet
50
und das Programm beenden werden kann. Das Submenü „View“ wird verwendet, um zu
bestimmen, welche Typen von Geoobjekten in der PictureBox angezeigt werden sollen. Mit
dem Submenü „Add“ kann der Einfügemodus aktiviert werden, um per Mausklick die neue
Geoobjekte in die Datenbank einzufügen. Mit dem Submenü „Options“ lässt sich konfigurieren, wie die Geoobjekte auf dem Bildschirm dargestellt werden sollen. Das Submenü „About“ von „Help“ zeigt die Metadaten des Programms wie zum Beispiel Name, Version und
Autor des Programms.
Die RichtextBox bzw. ListBox dient als Metadaten-Anzeige für die gewählten Geoobjekte. Die
Metadaten der ausgewählten Geoobjekte oder die per Suchfunktion gefundenen Wege zwischen zwei Nodes werden hier als Text angezeigt.
Die PictureBox dient als Container für die Bildschirmkarte. Alle Geoobjekte in der Datenbank
können nach Wunsch visualisiert und in der PictureBox graphisch dargestellt werden. Die
PictureBox akzeptiert Mausereignisse; auf diese Weise kann interaktiv mit der Datenbank
kommuniziert werden. Unter verschiedenen Modulen wird das Programm auf spezifische Ereignisse unterschiedlich reagieren. Ein linker Mausklick aktiviert im „Add Point“-Modul die
Form frmAddIcon.vb, während im „Zoom“-Modul die „Zoom in“-Funktion aktiviert wird.
Die Statusleiste zeigt die geodätischen Koordinaten der Mausposition in der PictureBox, die
durch das „MouseMove“-Ereignis von der PictureBox ständig aktualisiert werden.
Durch Auswahl der CheckBoxes in der Gruppe „Add“ kann das Einfügemodul aktiviert werden.
Man kann auswählen, welche Art von Geoobjekten in die Datenbank hinzugefügt werden
sollen. Die CheckBoxes in der Gruppe „Show“ steuern die in der Picturebox dargestellten
Geoobjekte nach Wunsch. Das Geoobjekt, das von den ComboBoxes in der Gruppe „Select“ ausgewählt wird, wird in der Picturebox graphisch angezeigt. Per „Route Search“ lassen
sich auch alle bzw. optimale Verbindungen zwischen zwei Knoten suchen. Das Ergebnis wird
in der ListBox angezeigt.
Abb. 6.3: diverse Steuerelemente des Hauptfensters
51
6.2.3
Konfiguration der Bildschirmkarte
Anders
als
in
den
zwei
Vorgängerarbeiten
kann
der
Benutzer in VisMap die Darstellungsformen der Geoobjekte mittels
der GUI ändern. Diese Funktion wird
durch die Auswahl des MenüItems
„Options -> Mode of Display“ realisiert. Nach der Auswahl des
MenuItems wird ein Fenster mit drei
Tabs aktiviert. Im Tab „Nodes“
können
unterschiedliche
Images zu den verschiedenen
Subklassen
der
Objektklasse
„Node“ zugewiesen werden. Weil die
Städte durch Nodes modelliert
werden, werden in diesem Tab die
Darstellungsformen
der
Städte
bestimmt. Die in den ComboBoxes
angezeigten Images sind nicht im
Programm definiert, sondern in der
Datenbank gespeichert. Mit dem
Mausklick auf den Button „Add New
Image“ kann man selbst definierte
Images in die Datenbank einfügen.
Dies
erhöht
die
Erweiterungsmöglichkeit des Präsentationsmodells von Geoobjekten. Mit dem
Mausklick
auf
den
Button
„Ok“ werden die Änderungen übernommen und in der Datenbank
gespeichert. Mit dem Mausklick auf
den Button „Cancel“ werden die
Änderungen verworfen und das
Fenster wird danach geschlossen.
Im
Tab
„Path“
kann
die
Abb. 6.4: Fenster zum Konfigurieren des PräsenDarstellungsform der Subklassen
tationsmodells der Geoobjekte
der Objektklasse „Path“ bestimmt
werden. Weil die Zuglinien und
Autobahnlinien durch Path modelliert werden, werden hier die Darstellungsformen der Zugli-
52
nien und Autobahnlinien bestimmt. Die Attribute „Style“, „Width“ und „Color“ werden ebenfalls
in der Datenbank gespeichert. Die Einträge in den ComboBoxes entsprechen den Parametern der Methode Graphics.DrawPath. Der Mausklick auf den Button „Ok“ oder „Cancel“ funktioniert wie im Tab „Nodes“.
Im Tab „Areas“ kann die Darstellungsform der Subklassen der Objektklasse „Area Set“ bestimmt werden. In unserem Beispiel sind „Country“ und „State“ vom Typ „Area Set“, seine
Darstellungsformen werden in diesem Tab bestimmt. Wie im Tab „Path“ entsprechen die
Einträge in den ComboBoxes den Parametern der Methode Graphics.DrawPath. Der Mausklick auf den Button „Ok“ oder „Cancel“ funktioniert wie im Tab „Nodes“.
6.3
Interaktion mit VisMap
Die Bildschirmkarte bietet nicht nur eine graphische Darstellung der Geoobjekte, sondern
auch ein Interface, wodurch die Geodaten in der Datenbank interaktiv bearbeiten werden
können. Der Benutzer kann mit den Mausklicks auf die Bildschirmkarte und der Abgaben der
Formulare die gewünschten Geoobjekte auf dem Bildschirm anzeigen, die Metadaten bestimmter Geoobjekte abfragen, neue Geoobjekte einfügen, löschen und aktualisieren, sowie
nach bestimmten Geoobjekten suchen. Das GUI hat zwei Modi: Normalmodus und Einfügemodus. Im Normalmodus können die in der Datenbank existierenden Geoobjekte bearbeitet
werden, während im Einfügemodus die neuen Geoobjekte in die Datenbank eingefügt werden.
6.3.1
Normalmodus
Bei Programmstart befindet sich der Nutzer im Normalmodus. Die Geoobjekte in der PictureBox, die vorgegeben angezeigt werden, sind alle in der Datenbank stehenden Geoobjekte
außer Infrastrukturen zwischen den Städten. Es gibt zwei Gründe, aus denen die physischen
Verbindungen nicht angezeigt werden: Erstens sind sie immer von den logischen Verbindungen bedeckt und zweitens ist die logische Bedeutung der Verbindungen zwischen den
Städten in einen Verkehrsnetz wichtiger als die physische Existenz der Infrastrukturen.
Die angezeigten Geoobjekte in der PictureBox lassen sich jedoch nach Wunsch definieren.
Durch die Benutzung der CheckBoxes in der Gruppe „Show“ können die vier Schichten der
Geoobjekte separat oder kombiniert in der PictureBox angezeigt werden. Durch die Benutzung des Menüs „Options -> Mode of Display“ werden die Subschichten der jeweiligen
Schicht konfiguriert, die angezeigt werden sollen.
Durch die Auswahl der CheckBox „Zoom“ hat der Benutzer die Möglichkeit, mit dem Mausklick auf die PictureBox die angezeigte Karte zu vergrößern oder zu verkleinern. Wenn die
CheckBox „Zoom“ angeklickt ist, wird die Auswahl der Geoobjekte beim Mausklick deaktiviert.
Stattdessen wird die Karte in der PictureBox beim rechten Mausklick um das 1,2-Fache ver53
größert und beim linken Mausklick um das 1,2-Fache verkleinert. Die Mitte der vergrößerten
bzw. verkleinerten Karte ist die Position des Mausklicks.
Nach der Darstellung von Geoobjekten können diese interaktiv bearbeitet werden. Im Normalmodus lassen sich die Geoobjekte abfragen, löschen und aktualisieren. Um ein Geoobjekt
zu bearbeiten, muss es zuerst ausgewählt werden. In VisMap wird das gewünschte Geoobjekt durch Mausklick auf die Karte in der PictureBox ausgewählt.
Wie oben erwähnt, gibt es in VisMap mehrere Schichten und Subschichten. Die ausgewählten Schichten werden überlappende in der Picturebox angezeigt. Nur die in der PictureBox
angezeigten Geoobjekte können ausgewählt werden. Wenn die CheckBox „Zoom“ nicht ausgewählt ist, muss das Programm bei jedem Mausklick auf die Karte in der PictureBox im
Normalmodus entscheiden, welches Objekt will der Benutzer mit dem Mausklick auswählen.
Im Prinzip erhält das Programm ein Koordinatenpaar beim Mausklick, und vergleicht es mit
den Koordinateninformationen der in der PictureBox angezeigten Geoobjekte. Wenn sie übereinstimmen, dann werden sie ausgewählt, was in der Praxis aber nicht durchführbar ist.
Mit der Maus lässt sich nur schwer auf einen Punkt oder eine Linie klicken. Dafür muss eine
Toleranz definiert werden. Man kann für die Nodes und Linienzüge eine Epsilonumgebung
definieren, jeder Mausklick in dieser Umgebung kann als Auswahl des Nodes oder Linienzugs
interpretieren. Die Epsilonumgebung kann sowohl durch die euklidische Metrik oder durch die
Manhattan-Metrik definiert werden.
Es kann passieren, dass ein Mausklick in der Epsilonumgebung von mehreren Geoobjekten
unterschiedlicher Schichten stattfindet. Das Programm muss zuerst feststellen, welche
Schicht der Benutzer auswählen will. Deswegen wird jeder Schicht eine Priorität zugewiesen.
Weil die Epsilonumgebung des Punktes kleiner als die der Linie, und die Epsilonumgebung
der Linie kleiner als die des Vielecks ist, haben die Nodes die höchste Priorität, danach die
Path und die Regionen haben die niedrigste Priorität. Das heißt, wenn sich ein Mausklick
gleichzeitig in der Epsilonumgebung von einem Node und einem Path befindet, nimmt das
Programm an, dass der Benutzer das Node auswählen will.
Es kann auch vorkommen, dass mehrere Objekte in derselben Schicht teilweise oder ganz
überlappend in der PictureBox dargestellt werden. Wenn die Metadaten der Geoobjekte abgefragen werden, werden alle überlappenden Objekte in der gleichen Schicht ausgewählt.
Wenn das Geoobjekt bearbeitet werden soll, erscheint ein Popup-Fenster und alle Kandidaten stehen dann in einer ComboBox des Fensters in der dann das gewünschte Objekt ausgewählt werden kann.
Beim Mausklick auf die PictureBox im Normalmodus überprüft das Programm zuerst, ob ein
oder mehrere Geoobjekte ausgewählt werden. Ist dies nicht der Fall, geschieht nichts. Andernfalls wird beim linken Mausklick eine Abfrage nach den Metadaten des Geoobjektes aufgerufen. Die Namen der ausgewählten Geoobjekte werden in einem ToolTip angezeigt,
gleichzeitig stehen die ausführlichen Metadaten des Objektes in der „Info Box“. Bem rechten
54
Mausklick wird ein Kontextmenü angezeigt. Die Menüeinträge des Kontextmenüs sind abhängig vom Typ des ausgewählten Geoobjektes. Mit der Auswahl des Menüeintrages wird die
entsprechende Methode aufgerufen, um das gewählte Objekt zu löschen oder zu aktualisieren.
Abb. 6.5: Fenster zum Aktualisieren der Verkehrslinien
Im Normalmodus kann man nicht nur die in der Datenbank existierenden Geoobjekte abfragen, sondern auch bearbeiten. Diese Funktion wird mit Hilfe der entsprechenden Fenster
ermöglicht. Die Auswahl des Geoobjekts, das der Nutzer bearbeiten möchte, ist identisch mit
der Anzeige der Metadaten von Geoobjekten. Beim rechten Mausklick auf die Bildschirmkarte
überprüft der Fenstermanager, ob ein Geoobjekt ausgewählt wird. In diesem Fall erscheint
ein ContextMenu. Hier kann die gewünschte Operation für das Geoobjekt ausgewählt werden.
Wenn die Operation „Delete“ gewählt wird, dann erscheint ein Dialogfenster, um die Operation zu bestätigen. Beim Mausklick auf den Button „Ok“ wird das Geoobjekt in der Datenbank
gelöscht, und mit dem Mausklick auf den Button „Cancel“ wird die Operation abgebrochen.
Wenn die Operation „Modify“ gewählt wird, erschienen abhängig vom ausgewählten Geoobjekt unterschiedliche Dialogfenster, in denen die Metadaten und Geometrie des Geoobjektes
geändert werden kann. Beim Ausfüllen der Formulare im Dialogfenster gibt der Benutzer die
neuen Werte der Objekte ein. Mit dem Mausklick auf den Button „Save“ werden die
SQL-Anweisungen konstruiert und zum DBMS übertragen. Die Daten in der Datenbank
werden dann aktualisiert. Mit dem Mausklick auf den Button „Cancel“ werden die Änderungen
verworfen und das Fenster wird geschlossen.
Die Änderungen der Geoobjekte bestehen aus den Änderungen der Geometrie und der
Thematik. Die Thematik und Geometrie einer Stadt oder eines Flughafens sind atomar. Die
Infrastruktur verbindet nur zwei Städte. Es ist nicht nötig, ihre geometrische Lage zu ändern.
Es genügt, die alte Lage zu löschen und eine neue anlegen. Die Änderungen, die für die
55
Städte, Flughäfen und Infrastrukturen eingegeben werden können, sind identisch mit denen,
die beim Einfügen solcher Geoobjekte eingegeben werden können. Deswegen sind die Darstellungen der Fenster zum Aktualisieren der Stadt, des Flughafens und der Infrastruktur
ähnlich wie beim Einfügen.
Die Geometrie der Verkehrslinien basiert auf der Geometrie der Infrastrukturen. Sie ist nicht
atomar in der Datenbank. Die Änderungen können deswegen nicht nur durch Aktualisieren
der existierenden Datensätze, sondern auch durch Einfügen oder Löschen der neuen Datensätze ermöglicht werden. Die SQL-Anweisungen dafür sind komplizierter als beim Aktualisieren der Städte, Flughäfen und Infrastrukturen. Die Struktur der SQL-Anweisungen für das
Aktualisieren der Thematik, das Einfügen eines neuen und das Löschen eines existierenden
Nodes sind unterschiedlich. Aus diesem Grund wird das Fenster in drei Tabs aufgeteilt: „General“, „Delete Node“ und „Add Node“. Beim Mausklick auf den Button „Ok“ in verschiedenen
Tabs werden unterschiedliche SQL-Anweisungen erzeugt. Im Tab „General“ lässt sich ausschließlich die Thematik der Verkehrslinien ändern, zum Beispiel deren Namen. Mit dem Tab
„Delete Node“ kann ein Node auf der Verkehrslinie gelöscht werden, in der Combobox stehen
nur die Nodes von der ausgewählten Verkehrslinie, da nur das schon auf der Verkehrslinie
stehende Node gelöscht werden kann. Mit dem Tab „Add Node“ lässt sich ein neues Node in
die Verkehrslinie einfügen. Die erste ComboBox enthält die Namen aller in der Datenbank
gespeicherten Nodes. Nur die schon existierenden Nodes können in eine Verkehrslinie eingefügt werden. Die zweite ComboBox enthält die Namen aller Nodes auf der Verkehrslinie,
um zu kontrollieren, auf welcher Position der Verkehrslinie das neue Node liegen soll. Mit den
RadioButtons kann man bestimmen, ob das neue Node vor oder hinter dem existierenden
Node der Verkehrslinie hinzugefügt werden soll.
Um die Integrität der Datenbank zu bewahren, gibt es für das Löschen und Aktualisieren des
Geoobjektes folgende Integritätsbedingungen:
•
•
•
•
•
Alle Attribute der Geoobjekte dürfen nicht Null sein
Die Werte der Koordinaten dürfen nur im Bereich von -180 bis +180 Grad sein
Die Anzahl der Bewohner darf nur positiv sein
Das Node darf nicht gelöscht werden, wenn es Start- oder Endpunkt einer Kante ist
Die Infrastruktur darf nicht gelöscht werden, wenn Verkehrslinien auf dieser Kante
basieren.
Eine weitere Funktionalität von VisMap im Normalmodus ist das Suchen nach einem bestimmten Objekt in der Datenbank. Die drei ComboBoxes rechts unten im Hauptfenster enthalten alle Geoobjekte der Datenbank. Mit ihnen lässt sich das gewünschte Geoobjekt
auswählen. Das ausgewählte Geoobjekt wird auf der Karte in der PictureBox anschaulich
dargestellt.
Das VisMap-System soll in der Lage sein, die Informationen nicht nur einfach darstellen und
bearbeiten, sondern auch nach individuellen Bedürfnissen analysieren zu können. Durch die
56
Analyse der existierenden Informationen in der Datenbank können neue Informationen gewonnen werden. Als Beispiel wird das Suchen nach den Verbindungen zwischen zwei beliebigen Städten verwendet. Man kann in einem Formular zwei beliebige Städte und den Typ
der Verbindung (momentan nur Eisenbahn und Straße) eingeben. Nach einem Klick auf den
Button „Search“ wird die Suche gestartet. Wenn kein Ergebnis gefunden wird, erscheint ein
Dialogfenster mit einer Warnung. Wenn es die Verbindungen zwischen beiden Städten gibt,
dann werden die gefundenen Verbindungen in der „Info Box“ angezeigt. Bei der Auswahl einer Verbindung in der „Info Box“ wird diese Verbindung graphisch auf der Karte in der PictureBox dargestellt, damit der Benutzer einen anschaulichen Eindruck vom Ergebnis erhält.
Abb. 6.6: Formular zum Suchen der Wege zwischen zwei Nodes
6.3.2
Einfügemodus
Mit Auswahl der CheckBoxes der Gruppe „Add“ befindet der Benutzer sich im Einfügemodus.
Hier kann er mit Mausklicks auf die Bildschirmkarte und die Formulare die neuen Geoobjekte
in die Datenbank speichern. Das Programm reagiert auf die Mausklicks und vordefinierten
Formulare, überprüft die Integritätsbedingungen, und fügt dann die eingegebene Geoobjekte
in die Datenbank ein. Es lassen sich in VisMap drei Typen von Objekte einfügen: Node, Path
und Region Set.
Es ist wichtig, die Objekte vom bestimmten Typ bereits auf dem Bildschirm sehen zu können,
wenn ein Objekt einfügt werden soll. Nur dann lässt sich die ungefähre Position des neuen
Objektes erkennen, gemäß den existierenden Objekten auf der Karte das neue Objekt einfügen, und nach dem Einfügen direkt auf der Karte sehen. Deswegen sind die Zustände der
CheckBoxes in der Gruppe „Add“ abhängig von den Zuständen der CheckBoxes der Gruppe
„View“. Sie sind nur aktiv und auswählbar, wenn die entsprechenden CheckBoxes in der
Gruppe „View“ ausgewählt sind.
57
Das Einfügen der Geoobjekte wird mit Hilfe des entsprechenden Fensters realisiert. Für das
Einfügen verschiedener Objektklassen gibt es unterschiedliche Fenster. Die ComboBoxes
und TextBoxes in den Fenstern entsprechen den Attributen der jeweiligen Geoobjekte, damit
die richtigen SQL-Anweisungen generiert werden können. Mit dem Mausklick auf den Button
„Ok“ werden die Änderungen angenommen, mit dem Mausklick auf den Button „Cancel“ werden die Änderungen verworfen und das Fenster wird geschlossen.
Das Einfügen eines neuen Nodes ist nur möglich, wenn die existierenden Nodes schon auf
der Bildschirmkarte angezeigt werden. Mit dem Mausklick auf die ungefähre Position des
Nodes in der PictureBox erscheint ein Dialogfenster. Man kann dann das Typ, die genauen
geodätischen Koordinaten und die Metadaten für das Node eingeben. Die Steuerelemente
des Dialogfensters werden gemäß dem Typ des Nodes angepasst. Die Klasse „frmAddNode“ erzeugt das Fenster zum Einfügen der Stadt oder des Flughafens. In der ComBox „Node
Type“ kann man die Subklasse der Objektklasse „Node“ wählen. Abhängig von der gewählten
Subklasse werden die entsprechenden ComboBoxes und TextBoxes aktiviert bzw. deaktiviert.
Wenn der Benutzer die Subklasse „City“ wählt, wird das Feld „IATA Code“ deaktiviert, da es
keine IATA-Kennzahl für eine Stadt gibt. Alle anderen Felder bleiben aktiviert. Wenn „Airport“ ausgewählt wird, werden die Felder „KFZ“, „Population“ und „Bundesland“ deaktiviert,
stattdessen wird das Feld „IATA Code“ aktiviert. Es gibt Regeln für die Felder: Die zentralen
Punkte der zwei Nodes können nicht dieselbe Koordinate haben, die Felder „Position“ und
„Population“ dürfen nur Zahlen enthalten, und alle Felder müssen ausgefüllt werden. Beim
Mausklick auf den Button „Ok“ wird kontrolliert, ob alle Regeln eingehalten wurden. Andernfalls erscheint eine Fehlermeldung.
Abb. 6.7: Fenster zum Einfügen einer neuen Stadt oder eines neuen Flughafens
Das Einfügen einer Infrastruktur zwischen zwei Nodes ist komplizierter als das Einfügen des
Nodes. Die Nodes müssen angezeigt werden, damit der Benutzer den Startpunkt und End-
58
punkt der Infrastruktur per Mausklick auswählen kann. Bem Ereignis MouseDown der linken
Maustaste überprüft das Programm, ob ein Node ausgewählt ist. In diesem Fall wird dieses
Node als Startpunkt der Infrastruktur zugewiesen. Andernfalls passiert nichts. Durch Bewegen der Maus wird dann der Endpunkt der Infrastruktur wählbar. Beim MouseUp-Ereignis der
linken Maustaste reagiert das Programm analog wie bei dem MouseDown Ereignis. Wenn ein
Node ausgewählt ist, dann ist es der Endpunkt der Infrastruktur. Nach der Bestimmung des
Startpunktes und Endpunktes der Infrastruktur erscheint ein Dialogfenster. Der Benutzer kann
in diesem Fenster die Namen der zwei Städte sehen, die mit dieser Infrastruktur verbunden
sind. Man kann dann den Typ der Infrastruktur (Eisenbahn oder Straße) eingeben.
Beim Einfügen einer Verkehrslinie (Autobahn oder Zuglinie) muss das Programm noch
strenger kontrollieren, um die Integrität der Datenbank zu bewahren. Wie beim Einfügen der
Infrastruktur müssen die Nodes auf der Bildschirmkarte angezeigt werden, damit der Benutzer die Routine der Verkehrslinie bestimmen kann. Das Programm überprüft beim jeden linken Mausklick, ob ein Node ausgewählt ist. Das erste ausgewählte Node wird als der
Startpunkt der Verkehrslinie gespeichert. Bei der Auswahl des zweiten und nachfolgenden
Nodes überprüft das Programm, ob es zwischen dem n-ten und n-1-ten ausgewählten Node
die Infrastruktur des bestimmten Typs gibt. Zum Beispiel wird beim Einfügen einer ICE Linie
überprüft, ob es zwischen den zwei Nodes eine Infrastruktur vom Typ Eisenbahn gibt. Wenn
eine solche Infrastruktur nicht existiert, dann wird der Vorgang abgebrochen, und eine Fehlermeldung angezeigt. Wenn diese Infrastruktur existiert, wird das ausgewählte Node als die
nächste Station der Routine gespeichert.
Mit dem rechten Mausklick endet die Auswahl der Routine. Das letzte ausgewählte Node wird
als der Endpunkt der Verkehrslinie gespeichert. Ein Dialogfenster erscheint automatisch, und
der Benutzer kann dann die Metadaten der Verkehrslinie eingeben. Der Verlauf der Verkehrslinie wird ganz oben im Fenster angezeigt, damit der Benutzer überprüfen kann, ob der
Verlauf richtig eingegeben wurde. Dieses Feld beschreibt die Geometrie der Verkehrslinien,
da seine Geometrie nicht atomar in der Datenbank ist, ist eine Änderung hier nicht möglich.
Wurde der Verlauf falsch ausgewählt, kann er entweder erneut ausgewählt oder durch das
Fenster zum Aktualisieren der Verkehrslinien modifiziert werden. Im Feld „Type“ lässt sich die
gewünschte Art der Verkehrslinie wählen, und im Feld „Name“ der Name für die Verkehrslinie
eingeben. Beide Felder müssen ausgefüllt werden. Bevor die Verkehrslinie in die Datenbank
gespeichert wird, muss das Programm überprüfen, ob eine identische Verkehrslinie schon in
der Datenbank vorhanden ist.
Beim Einfügen einer Region speichert das Programm die Position des ersten linken Mausklicks als Startpunkt der Region, und überprüft die folgenden Mausklicks. Bei einem rechten
Mausklick wird der Vorgang abgebrochen. Wenn die Position eines linken Mausklicks in der
Epsilonumgebung des Startpunktes liegt, dann erscheint das Fenster zum Einfügen der Region. In diesem Fenster kann der Name und Typ der Region eingegeben werden. Die beiden
Felder dürfen nicht leer sein.
59
6.4
Fenstermanager
6.4.1
Ereignisinterpretation
Die Ereignisse in einem VB-Programm sind abhängig von den Steuerelementen. Das heißt,
die gleichen Ereignisse von verschiedenen Steuerelementen werden unterschiedlich behandelt. Zum Beispiel werden beim linken Mausklick auf einen Button die eingegebenen Informationen zum Programm abgegeben, während beim Klick auf einen anderen Button die
eingegebenen Informationen verworfen werden. Die Methoden für solche Reaktionen sind
von .NET vordefiniert, und so lässt sich leicht die gewünschte Methode im Entwurfsfenster
auswählen. Solche vordefinierten Methoden sind leer, deswegen müssen danach die benutzerdefinierten Codes in die Methode eingefügt werden. Dies funktioniert reibungslos, wenn
die Reaktion auf jedes Ereignis eines Steuerelements eindeutig ist. Aber wenn es für das
gleiche Ereignis eines Steuerelements mehrere Reaktionsmöglichkeiten gibt, muss das Programm nach weiteren Kriterien überprüfen und die richtige Aktion durchführen.
Im GUI von VisMap sind die Reaktionen der Ereignisse für die meisten Steuerelemente eindeutig, außer beim Mausklick auf das Steuerelement PictureBox1. Ein Mausklick auf die PictureBox1 kann mehrere Bedeutungen haben. Zuerst sind das vom Drücken der Maustaste
erzeugte Ereignis und das vom Loslassen der Maustaste erzeugte Ereignis separat zu behandeln. Die zwei Ereignisse können die vorgegebenen Methoden PictureBox1_MouseDown
und PictureBox1_MouseUp aufrufen. Da das Loslassen der Maustaste notwendig immer
nach dem Drücken der Maustaste erfolgt, wird im Programm zuerst die Methode PictureBox1_MouseDown, und danach die Methode PictureBox1_MouseUp aufgerufen. Die separate Behandlung ist sehr sinnvoll, wenn die Drag and Drop Operation von der Maus auf einem
Steuerelement erwünscht ist. Zum Beispiel beim Einfügen einer Linie in VisMap: Das Drücken
der Maustaste auf ein Node ruft die PictureBox1_MouseDown Methode auf, speichert dieses
Node als Startpunkt, und das nachfolgende Auflösen der Maustaste auf ein anderes Node ruft
die PictureBox1_MouseUp Methode auf, speichert dieses Node als Endpunkt und dann ruft
das Fenster zum Einfügen der Linien auf.
Zweitens sollen die Ereignisse der Maus in verschiedenen Modi unterschiedlich behandelt
werden. Mit dem linken Mausklick auf ein Node im Normalmodus ist gemeint, dass die Metadaten des Nodes angezeigt werden sollen. Während es im Einfügemodus, wenn die
CheckBox „Add Route“ ausgewählt wird, bedeutet, dass das Node in ein neues Path eingefügt werden soll.
Drittens werden die von der rechten und linken Maustaste erzeugten Ereignisse unterschiedlich behandelt. Ein linker Mausklick auf ein Node im Normalmodus zeigt die Metadaten des
Nodes im RichTextBox1 und ToolTip, während beim rechten Mausklick ein KontextMenü
angezeigt wird.
60
Abb. 6.8: dynamische Modellierung des Ereignismanagers
Viertens sollen die Mausklicks an verschiedenen Positionen, wenn nötig, auch unterschiedlich behandelt werden. In VisMap enthält die PictureBox1 eine interaktive Bildschirmkarte. In
der Karte stehen alle anzuzeigenden Geoobjekte. Wenn diese mit der Karte interaktiv bearbeitet werden sollen, müssen auch die Positionen der Mausklicks berücksichtigt werden. Das
heißt, auf Ereignisse vom gleichen Steuerelement im gleichen Modus, die von der gleichen
Maustaste erzeugt werden, kann das Programm unterschiedlich reagieren, wenn die Positionen der Mausklicks nicht gleich sind. Zum Beispiel zeigt das Programm die Metadaten einer
61
Stadt, wenn man die linke Maustaste auf eine Stadt drückt, während das Programm beim
linken Mausklick auf eine Verkehrslinie deren Metadaten zeigt.
Um die oben genannte Situation anzupassen, müssen in den Methoden PictureBox1_MouseUp und PictureBox1_MouseDown die „If … Then“-Kontrollstrukturen eingebaut
werden. Nachdem das Programm das Mausklick-Signal erhalten hat, überprüft es zuerst, ob
es sich im Normalmodus oder Einfügemodus befindet. Wenn es im Normalmodus ist, überprüft es, ob die Zoom-Funktion aktiviert ist. Wenn sie nicht aktiviert ist, überprüft es, welche
Maustaste gedrückt ist. Wenn es im Einfügemodus ist, dann überprüft es welche Maustaste
gedrückt ist. Wenn es die linke Maustaste ist, dann wird die Art des Geoobjektes, das eingefügt werden soll, geprüft. Wenn die Zoom-Funktion aktiviert ist, dann überprüft das Programm
welche Maustaste gedrückt wird, wenn es die linke Maustaste ist, wird die Bildschirmkarte
vergrößert. Wenn es die rechte Maustaste ist, wird die Bildschirmkarte verkleinert, dessen
Zentralpunkt die Position des Mausklicks ist.
Die Auswahl des Geoobjektes basiert auf der Überprüfung seiner Epsilonumgebung. Bei jedem Mausklick erhält das Programm die Position des Mausklicks (e.X und e.Y), die in den
Methoden PictureBox1_MouseUp und PictureBox1_MouseDown benutzen werden kann. Das
Programm soll die Position des Mausklicks mit der geometrischen Lage aller vorhandenen
Geoobjekte vergleichen und feststellen, ob der Mausklick in der Epsilonumgebung eines oder
mehrer Geoobjekte stattfand. Für unterschiedliche Geoobjekte gibt es unterschiedliche Vergleichsmethoden. Für die Geoobjekte vom Typ „Node“ wird die Position des Mausklicks mit
dem Zentralpunkt des Nodes verglichen. Die Metrik, die hier benutzt wird, ist die euklidische.
Für die Geoobjekte vom Typ „Linienzug“ wird die Position des Mausklicks mit dem Verlauf der
Linien verglichen. Hier wird die Manhattan-Metrik benutzt. Für die Geoobjekte vom Typ „Vieleck“ wird das Theorem von Jordan benutzt [Bi99]. Ist die Anzahl der echten Schnittpunkte
eines beliebigen in Punkt X startenden Teststrahls mit Vieleckkanten ungerade, so liegt X
innerhalb des Vielecks, anderenfalls ist X ein Punkt außerhalb des Vielecks. Als echte
Schnittpunkte gelten nur solche Punkte, an denen sich die Geraden tatsächlich schneiden,
d.h. Schnitte in der Verlängerung der einen oder der anderen Geraden werden nicht mitgezählt. Der Teststrahl wird im Programm folgendermaßen festgelegt: Er geht von der Position
des Mausklicks aus und durch den Mittelpunkt der ersten Grenzelinie eines Vielecks. Es wird
überprüft, wie viele Grenzelinien, außer der ersten Grenzelinie, noch von diesem Strahl echt
geschnitten werden. Wenn die Anzahl ungerade ist, dann befindet sich der Mausklick innerhalb dieses Vielecks, anderenfalls ist er außerhalb dieses Vielecks.
6.4.2
Kommunikation mit der Datenbank
Wenn man die Datenbank mit dem GUI interaktiv bearbeiten möchte, muss zuerst eine Verbindung zu ihr hergestellt werden. Um diese Verbindung herzustellen, wird hier ADO .NET
(vgl. Kap. 3.2) benutzt. Mit der Klasse DBConnection.vb wird eine Verbindung zur angege-
62
benen Datenbank definiert, die später von mehreren Klassen und Methoden benutzt werden
kann. Weil hier die Microsoft Jet Database Engine als DBMS benutzt wird, wird Microsoft.JET.OLEDB.4.0 als Data-Provider verwendet. Die Datenbank hat ein Datenbankkennwort, um den Zugriff auf die Datenbank zu kontrollieren. Es muss in den ConnectionString
eingegeben werden:
Dim cnn1 As New System.Data.OleDb.OleDbConnection
cnn1.ConnectionString = & _
"provider=Microsoft.JET.OLEDB.4.0;" & _
"Data Source=" & appPath & _
";Jet OLEDB:Database Password=" & Passwd
Eine Verbindung reicht noch nicht, damit beide Seiten miteinander kommunizieren können.
Das Programm muss eine bestimmte Sprache verwenden, die Jet Database Engine versteht:
Jet SQL (vgl. Kap. 2.6). Dann kann sie richtig reagieren und die gewünschten Daten zurückschicken.
In VisMap soll für jedes Ereignis der Steuerelemente, das den Zustand der Daten in der Datenbank verändert, eine SQL-Anweisung erzeugt werden. Nach verschiedenen Anforderungen und Optionen erzeugt die Klasse sqlGenerator.vb unterschiedliche SQL-Anweisungen.
Das Programm schickt diese SQL-Anweisungen über die oben genannte Verbindung zur
Datenbank, und die Datenbank folgt der Anweisung, ändert den Datenzustand, und schickt
ggf. eine Antwort zurück.
Der OleDbAdapter (vgl. Kap. 3.2) erfasst die Antwort der Datenbank, konstruiert ein DataSet-Objekt und schickt es zurück zum Programm. MDieses DataSet-Objekt lässt sich lokal
lesen und bearbeiten. Zum Schluss werden die Änderungen in der Datenbank ermittelt.
Dim sqlstat as String = “SELECT * FROM city”
Dim dataAdapter1 As New System.Data.OleDb.OleDbDataAdapter( &_
sqlstat, cnn1)
Dim cityDataset1 As New System.Data.DataSet
dataAdapter1.Fill(cityDataset1, "city")
Werden nur die Befehle zur Datenbank geschickt und die Antwort der Datenbank soll nicht
bearbeitet werden, muss der OleDbAdapter nicht unbedingt benutzt werden. Für solche Situation wird eine Instanz von der Klasse OleDbCommand für eine bestimmte Datenbankverbindung definiert und ausgeführt, um die Daten in der Datenbank zu manipulieren:
Dim cmd As New OleDbCommand
cmd.Connection = cnn1
cmd.CommandText = "DELETE FROM icon WHERE id=" & _city.icon_id
cmd.ExecuteNonQuery()
63
Die Methode ExecuteNonQuery gibt keinen Datensatz, sondern einen Integer-Wert zurück.
Die Bedeutung des Wertes hängt vom Typ des Kommandos ab. Wenn eine DDL-Anweisung
ausgeführt wird, dann gibt die Methode -1 zurück, wenn die Operation erfolgreich beendet
wurde. Wenn eine Update-, Insert- oder Delete-Anweisung ausgeführt wird, dann gibt die
Methode die Anzahl der beeinflussten Zeilen zurück. In beiden Fällen gibt die Methode 0 zurück, wenn die Operation gescheitert ist.
Manchmal soll ein Kommando ausgeführt werden, das nur einen einzelnen Wert zurückgibt.
Zum Beispiel bei Verwendung von SQL-Anweisungen wie SUM oder COUNT, die eine Aggregatikonsfunktion haben, oder wenn man das Maximum einer Spalte bekommen möchte. In
dieser Situation kann die Methode ExecuteScalar verwendet werden. Diese Methode führt
eine SQL-Anweisung aus und gibt die erste Spalte der ersten Zeile zurück.
Dim maximum as Integer
Dim cmd As New OleDbCommand
cmd.Connection = cnn1
cmd.CommandText = "SELECT areaSegment.ID
FROM areaSegment" & _
" ORDER BY areaSegment.ID DES"
maximum = ToInt16(cmd.ExecuteScalar())
In VisMap werden die Informationen in verschiedenen Zuständen unterschiedlich präsentiert.
Im konzeptuellen Modell werden sie als Entity-Relationship-Typen dargestellt; in der Access-Datenbank sind sie durch Tabellen repräsentiert, bei der Antwort einer SQL-Anweisung
sind sie in DataSets gespeichert, und im VB-Programm werden sie als VB Klassen dargestellt.
Die Konvertierung von ER-Typen zu Tabellen wird durch Aufbau der Datenbank implementiert; die Konvertierung von Tabellen zu DataSets wird durch Microsoft Jet Database Engine
realisiert, das VB-Programm ist dafür zuständig, die DataSets zu VB-Klassen zu konvertieren.
Abb. 6.9: Konvertierung der Datenformate
Im Kapitel 5 wurde schon die Klassifizierung der Geoobjekte bereits diskutiert. Da VB .NET
eine objektorientierte Programmiersprache ist, ist es sehr sinnvoll, im Programm auch die
Klassen für unterschiedliche Geoobjekte zu definieren. Die Klassen im Programm sollen der
Klassifizierung der Geoobjekte im Kapitel 5 entsprechen, um den Datenaustausch zwischen
dem Programm und der Datenbank zu erleichtern.
Die Klassen myNodeClass, myPathClass und myAreaClass entsprechen Node, Path und
Area Set in der Datenbank. Die Eigenschaften der Klassen entsprechen auch den Attribute
von Node, Path und Area Set. Außerdem erbt die Klasse myNodeClass die Klasse my-
64
PointClass, die eine Erweiterung der von .NET vordefinierten Klassen für Punkt ist. Die
von .NET angebotenen Klassen für Punkt sind System.Drawing.Point und System.Drawing.PointF, die Werttypen für die Koordinaten sind Integer und Single. Die Koordinaten in der Klasse myPointClass sind hingegen vom Typ Double.
Abb. 6.10: Klassifizierung der Geoobjekte im VB Programm
Wie in der Modellierung des Datenbankentwurfs gibt es im Programm auch Subklassen für
jeweilige Oberklassen. Die Klasse myNodeClass wird von ihren Subklassen myCityClass und
myAirportClass geerbt. Die beiden Subklassen haben die Eigenschaften von myNodeClass
und ihre eigenen unterschiedlichen Eigenschaften. Die Klasse myPathClass wird von ihren
Subklassen ICE, IC, RB und Autobahn geerbt, und somit auch alle ihre Eigenschaften. Die
Klassen Country und State sind die Subklassen von myAreaClass, sie erben auch alle Eigenschaften von myAreaClass. Das DataSet, das als Antwort auf die SQL-Anweisung zurück
zum Programm geschickt wird, wird durch die mapCollection.vb zu den drei oben genannten
Klassen konvertiert.
Für jede Klasse existieren auch entsprechende Methoden, mit denen die Objekte dieser
Klasse bearbeitet werden können. Diese Methoden ermöglichen das Einfügen, Löschen und
Aktualisieren der Geoobjekte von unterschiedlichen Klassen. Sie werden durch den Mausklick auf den „Ok“ Button in unterschiedlichen Windows-Fenstern aufgerufen, und die unterschiedlichen Aktionen durchführen.
65
6.4.3
Pfadsuche
Das VisMap kann nicht nur die in der Datenbank existierende Dateien darstellen, sondern
besitzt auch die Funktionalität, die existierenden Informationen zu analysieren. Das Suchen
nach dem kürzesten Weg zwischen zwei beliebigen Nodes ist ein Beispiel dafür. Man kann in
VisMap sowohl nach allen Wegen, als auch nach dem kürzesten Weg zwischen zwei beliebigen Nodes suchen.
Das Suchen nach allen Wegen in VisMap ist durch einen rekursiven Algorithmus realisiert.
Am Anfang wird eine Adjazenzmatrix M aufgebaut. Wenn es n Knoten gibt, dann ist die Größe
der Adjazenzmatrix n x n. M(i,j) hat den Wert -1 wenn es keine direkte Verbindung zwischen
dem Knoten i und j gibt, ansonst ist M(i,j) gleich die Distanz zwischen den zwei Knoten. Zuerst
wird gesucht, welche Knoten mit dem Startknoten direkt verbunden sind. Dann wird der
Vorgang rekursive an diesen Knoten wiederholt, bis der Endknoten erreicht:
Private Sub findPaths(ByVal src As Integer, ByVal dest As Integer, & _
ByVal adjmatrix(,) As Double)
For i = 0 To adjmatrix.GetLength(0) - 1
If (adjmatrix(src, i) <> -1) Then
findPaths(i, dest, adjmatrix)
End If
End If
Next i
End Sub
Die Ergebnisse werden in der ListBox1 angezeigt, beim Mausklick auf die Ergebnisse wird
der ausgewählte Weg auf der Bildschirmkarte angezeigt. Dieser Algorithmus ist sehr ineffizient, denn beim Ansteigen der Knotenanzahl steigt Abrechnungsdauer exponentiell. Da das
Suchen aller Wege zwischen zwei Knoten nicht immer gewünscht ist, ist diese Suchoption
nicht die bevorzugte. Die bevorzugte Suchoption ist das Suchen nach dem kürzesten Weg
zwischen zwei vorgegebenen Knoten. Für die Berechnung des kürzesten Wegs wird in VisMap der Dijkstra-Algorithmus benutzt. Das Ergebnis wird nach der Berechnung auf der Bildschirmkarte angezeigt.
Der Dijkstra-Algorithmus wird oft benutzt, um die kürzesten Wege von einem Startknoten s zu
allen anderen Knoten in einem ungerichteten Distanzgraphen G zu berechen. Ein kürzester
Weg von einem Start- zu einem Zielknoten bedeutet hier, dass die Summe der Kantenlängen
vom Start- zum Zielknoten d[v] minimal ist. Ausgehend von s werden die kürzesten Wege für
die Knoten mit aufsteigendem Abstand nacheinander bestimmt. Zuerst wird aus den Knoten,
die mit s durch eine Kante verbunden sind, der Knoten v mit dem kürzesten Abstand zu s
ausgewählt. Aus den gewählten Knoten (hier s und v) werden die so genannten Randknoten
bestimmt. Dies sind Knoten zu denen es einen Weg nach s über die gewählten Knoten gibt.
66
Das heißt: Von einem Randknoten gibt es eine Kante zu einem gewählten Knoten. Durch
Neubestimmung der Randknoten ist es dann möglich, iterativ so fortzufahren, bis für jeden
Knoten ein kürzester Weg nach s gefunden wurde. (Vorausgesetzt es gibt für jeden Knoten
einen Weg zu s) Die Pseudocodes des Dijkstra-Algorithmus’ lauten wie gefolgt:
Dijkstra(G,w,s)
For each Vertex v ∈ V[G]
do d[v] ← ∞
π[v] ← NIL
d[s] ← 0
S ← Ø
Q ← V[G]
While Q ≠ Ø
do u ← Extract-Min(Q)
S ← S ∪ {u}
For each vertex v ∈ Adj[u]
Do Relax(u,v,w)
Relax(u,v,w)
If d[v] > d[u] + w(u,v)
Then d[v] ← d[u] + w(u,v)
π[v] ← u
In VisMap wird ein Sonderfall des Dijkstra-Algorithmus’ benutzt. Es werden nicht die Wege
von einem Startknoten zu allen anderen Knoten im Graph berechnet, sondern nur die Wege
zwischen einem Startknoten und einem Endknoten berechnet. Das heißt, der Algorithmus
wird abgebrochen, sobald der Endknoten durch Extract-Min(Q) aus Q entfernt wird. Die
Komplexität des Dijkstra-Algorithmus’ ist kleiner als O(|V|2).
6.5
Kartengenerator
Die Visualisierung der Geoobjekte spielt eine große Rolle in VisMap. Sie ist eine geometrische und topologische Abbildung der realen Welt auf einer Bildschirmkarte. Häufig werden
Strukturen und Zusammenhänge erst durch die graphische und kartographische Umsetzung
oder durch den visuellen Vergleich von Karten sichtbar. Die PictureBox von Form1 dient als
Container der abgebildeten Geoobjekte. Alle Geoobjekte in der Access-Datenbank können in
der PictureBox visualisiert und danach interaktiv durch Mausklick bzw. Abfrageformulare
behandelt werden. Um die Geoobjekte in der PictureBox darzustellen, wird der Kartengenerator entworfen.
Wie im letzten Abschnitt erklärt, erhält das Programm die Geoobjekte von ADO .NET in
Format DataSet. Sie werden dann durch mapCollection.vb zu VB-Klassen konvertiert und zu
67
mapGenerator.vb geschickt. Die mapGenerator.vb ruft convert.vb auf, um die geodätischen
Koordinaten der Geoobjekte in das Koordinatensystem der PictureBox zu konvertieren, und
lädt die visuelle Einstellung (z.B. das Symbol für Städte, die Stärke der Linien usw.) der
Geoobjekte, konstruiert ein Bitmap-Bild, und zeichnet das Bild in die PictureBox.
Das VisMap verwendet eine erweiterte Implementierung des Windows Graphics Design Interfaces (GDI), die so genannte GDI+, um die Bildschirmkarte zu erzeugen. Mit GDI+ lassen
sich Grafiken erstellen, Text zeichnen und grafische Bilder als Objekte bearbeiten. Mit GDI+
lassen sich grafische Bilder in Windows Forms und Steuerelementen rendern. Grafiken
können nur mit GDI+ programmgesteuert in Windows Forms-Anwendungen gerendert werden.
Um die Geoobjekte visuell darzustellen, muss zuvor jedem Objekttyp ein Symbol zugewiesen
werden. Für verschiedene Anwendungsgebiete und verschiedene Maßstäbe sollte je eine
unterschiedliche Symbolik entworfen werden. In dieser Diplomarbeit wird das Verkehrsnetz
von Deutschland als Beispiel benutzt, für die anderen Anwendungen gilt das gleiche Prinzip.
Wie im Kapitel Fünf geschrieben können alle Geoobjekte in einer 2D-Karte mit drei elementaren Komponenten dargestellt werden: Node, Path und Region Set. Da hier mit einer großmaßstäbigen Karte gearbeitet wird, können die Städte oder Flughäfen als Nodes, die
Verkehrsverbindungen als Path und die Bundesländer oder Seen als Region Set dargestellt
werden.
Die Form des Nodes ist abhängig vom Objekttyp und den quantitativen Eigenschaften der
Objekte. Das Node für den Flughafen ist ein kleines Flugzeug; das Node für eine Stadt mit
weniger als 200.000 Bewohnern ein durchsichtiger Kreis; eine Stadt mit 200.000 - 500.000
Bewohnern wird durch einen Kreis mit einem schwarzen Punkt in der Mitte dargestellt, ein
durchsichtiger Kreis mit einem kleineren schwarz ausgefüllten Kreis präsentiert eine Stadt mit
500.000 - 1.000.000 Bewohnern; Eine Stadt mit mehr als 1.000.000 Bewohnern wird mit einem rot ausgefüllten Quadrat dargestellt.
Da die Nodes keine einfachen geometrischen Formen sind, werden sie als Image-Dateien in
der Datenbank gespeichert. In Access lassen sich die Dateien nicht direkt speichern, sondern
nur mit Hilfe des Programms die ganze Datei als Stream einlesen und als OLE-Objekt in die
Datenbank speichern. Mit dem Menü „Options -> Mode of Display“ lassen sich die zugewiesenen Nodes der Geoobjekte ändern und die neue Art Nodes in die Datenbank einfügen. Mit
der Methode Graphics.DrawImage(image, x, y) werden die Images in die PictureBox gezeichnet. Wobei image das zu zeichnende Image-Objekt, x/y die X/Y-Koordinate der oberen
linken Ecke des gezeichneten Bildes ist.
Jeder Stadt wird eine Beschriftung zugewiesen. Sie ist das KFZ-Kennzeichen der Stadt und
wird mit der Methode Graphics.DrawString(s, font, brush, x, y) in die PictureBox gezeichnet.
Wobei s die zu zeichnende Zeichenfolge, font das Font-Objekt, das das Textformat der zeichenfolge definiert, brush das Brush-Objekt, das die Farbe und Struktur des gezeichneten
68
Textes bestimmt und x/y die X/Y-Koordinate der oberen linken Ecke des gezeichneten Textes
ist. Die Positionen der Beschriftungen für die Geoobjekte zu bestimmen ist ein sehr kompliziertes Problem. Hier werden sie einfach unter die Images gezeichnet. Abhängig von den
Größen der Images für die Städte verschiedener Größen ist die Distanz zwischen der Beschriftung und dem zentralen Punkt des Images unterschiedlich.
Dim townIcon As Image
Dim graphic As Graphics
graphic.DrawImage(townIcon, x, y)
graphic.DrawString(s, drawFont, drawBrush, x-2, y+6)
Die Paths präsentieren die Verkehrsverbindung der realen Welt. Sie bestehen aus Linien, die
Eigenschaften der Linien bestimmen die Eigenschaften der Paths. Die Verbindungen verschiedenen Typs werden durch unterschiedliche Linientypen dargestellt. Der Typ der Linie
wird durch folgende Elemente festgestellt: die Farbe der Linie, die Stärke der Linie und den
Linienstil. Die ICE-Verbindung wird zum Beispiel durch eine braune Linie mit dem Stil „Solid“ und der Stärke drei dargestellt. Die Parameter für Graphics.DrawLine werden in der Datenbank gespeichert, mit dem Menü „Options -> Mode of Display“ kann man die
Darstellungsform der Linien für verschiedene Verkehrsverbindungen anpassen. Mit der Methode Graphics.DrawLine(pen, x1, y1, x2, y2) werden unterschiedliche Linien auf den Bildschirm gezeichnet. Wobei pen das Pen-Objekt, das die Farbe, Breite und den Stil der Linie
bestimmt, x1/y1 die X/Y-Koordinate des ersten Punktes, x2/y2 die X/Y-Koordinate des zweiten Punktes ist.
Dim graphic As Graphics
graphic.DrawLine(myRoute(i).lineStyle, ToSingle(x1), &_
ToSingle(y1), ToSingle(x2), ToSingle(y2))
Das Attribut lineStyle gehört zur Klasse struMap.myRouteClass, es ist vom Typ System.Drawing.Pen. In der Klasse mapCollection.vb werden die Darstellungsformen der verschiedenen Geoobjekte aus der Datenbank gelesen, und dann werden verschiedene
Instanzen von System.Drawing.Pen für unterschiedliche Subklassen von Path definiert:
Dim m_Pen As Pen
m_Pen = New Pen(Color.FromName(row("color").ToString))
m_Pen.Width = ToInt16(row("stark"))
m_Pen.DashStyle = CType(row("style"), DashStyle)
Die Darstellung des Region-Sets ist ähnlich wie die der Paths. Ein Region-Set besteht aus
Regionen, und die Region ist begrenzt durch einen abgeschlossenen Path. Die Region lässt
sich mit der Methode Graphics.DrawPath(pen, path) und GraphicsPath.CloseFigure() auf den
Bildschirm zeichnen. Wobei pen das Pen-Objekt, das die Farbe, Breite und den Stil des
Pfades bestimmt, path das zu zeichnende GraphicsPath-Objekt ist. Die Methode
69
GraphicsPath.CloseFigure() schließt die aktuelle Figur und beginnt eine neue. Wenn die aktuelle Figur eine Abfolge verbundener Linien und Kurven enthält, schließt die Methode die
Schleife, indem End- und Anfangspunkt durch eine Linie verbunden werden. Mit der Methode
Graphics.FillPath(brush, path) kann das Innere der Region mit einer Farbe ausgefüllt werden.
Wobei brush das Brush-Objket, das die Merkmale des Füllvorgangs bestimmt und path das
GraphicsPath-Objekt, das den zu füllenden Pfad darstellt, ist. Das heißt, für das Region-Set
kann mindestens ein weiterer Parameter „Farbe“ in der Datenbank gespeichert werden. Wie
beim Zeichnen der Paths werden m_Pen und m_Brush in der Klasse mapCollection.vb definiert:
Dim myPath As New GraphicsPath
myPath.AddLines(myPoint)
myPath.CloseFigure()
graphic.DrawPath(m_Pen, myPath)
graphic.FillPath(m_Brush, myPath)
70
7.
Zusammenfassung und Ausblick
Das Ziel dieser Diplomarbeit war eine Implementierung der interaktiven Manipulation raumbezogener Datenbanken über eine 2D-Bildschirmkarte, um die in den zwei Vorgängerarbeiten entwickelten Systeme zu verbessern. Dieses Ziel ist mit dem VisMap-System erreicht. In
VisMap sind die Geoobjekte in einer Access-Datenbank gespeichert. Sie können mit dem
VB-Programm gelesen und in einer Bildschirmkarte dargestellt werden. Eine Menge grundsätzlicher Funktionen, mit denen die Geoobjekte bearbeitet werden können, sind auch in
VisMap implementiert. Der Benutzer kann zum Beispiel alle in der Bildschirmkarte dargestellten Geoobjekte löschen und aktualisieren und neue Geoobjekte in die Datenbank einfügen. Eine Pfadsuche zwischen zwei beliebigen Knoten ist ebenfalls möglich. Außerdem bietet
VisMap im Vergleich mit den vorangegangenen Diplomarbeiten eine technische, konzeptuelle
und funktionale Verbesserung.
Mit der technischen Verbesserung ist die Benutzung der Microsoft Visual Basic .NET und
ADO .NET gemeint. Mit der objektorientierten Programmiersprache kann das Programm
später leicht verbessert und erweitert werden. Mit ADO .NET ist die Verbindung mit der Datenbank nicht permanent. Das Programm ist, nur wenn es notwendig ist, mit der Datenbank
verbunden. Damit ist die Leistung der Datenbank drastisch erhöht.
Die primitive Modellierung der Geoobjekte in den Vorgängerarbeiten wurde durch ein
Drei-Schichten-Modell ersetzt. Eine klare Trennung zwischen den Geoobjekten in der realen
Welt, im konzeptuellen Modell und im Präsentationsmodell erleichtert die Erweiterung und
Umwandlung des zukünftigen Entwurfes.
Das VisMap-System bietet auch eine funktionale Verbesserung. Die Darstellungsformen der
Geoobjekte sind nicht mehr vom VB-Programm abhängig, sie werden in der Datenbank gespeichert, und sind durch GUI veränderbar. Außerdem kann der Benutzer nicht nur die in der
Datenbank existierenden Geoobjekte manipulieren, sondern auch durch Analysieren der existierenden Geoobjekte neue Informationen gewinnen. Ein Versuch dafür ist das Suchen
nach den Wegen zwischen zwei beliebigen Knoten.
Wegen der eingeschränkten Funktionalitäten der Microsoft Jet Database Engine müssen
anwendungsabhängige Codeteile im VB-Programm bereitgestellt werden, um komplexe Anfragen zu realisieren. Ein Versuch, das VB-Programm noch unabhängiger von den Anwendungsgebieten zu machen, ist deswegen nur teilweiser erfolgreich. Eine Erweiterung ist nur
möglich, wenn ein anderes DBMS mit der Unterstützung komplexerer Abfragenmöglichkeiten,
gespeicherter Prozeduren und von Triggern verwendet wird.
In der Zukunft kann das VisMap-System in zwei Richtungen weiterentwickelt werden. In
Richtung Datenbankentwicklung können zum Beispiel durch die Benutzung eines leistungsstärkeren DBMS wie zum Beispiel Oracle oder Microsoft SQL Server die gespeicherten Pro71
zeduren und Trigger verwendet werden. Dadurch kann nicht nur das VB-Programm noch
unabhängiger von den Anwendungsgebieten sein, sondern die häufig benutzten Berechnungen müssen auch nicht on Demand aufgerufen werden, ihre Ergebnisse werden statisch
in der Datenbank gespeichert und nur beim Einfügen, Löschen oder Aktualisieren der Geoobjekte aktualisiert. In Richtung Softwareentwicklung können noch mehr Funktionen implementiert werden. Zuerst soll eine Kartenprojektion wie zum Beispiel Gauß-Krüger-Projektion
implementiert werden. Es ist auch sinnvoll, die komplexen Operationen wie zum Beispiel
Zerlegung und Vereinigung der Linien und Vielecke zu realisieren. Um den Datenaustausch
zwischen VisMap und anderen Geo-Informationssysteme zu ermöglichen, ist eine Konvertierungsfunktion auch wünschenswert.
72
Literaturverzeichnis
[Av00]
Averdung, Christoph: GIS im Kontext der Steuerung von Geschäftsprozessen, Dissertation, Institut für Kartographie und Geoinformation der Universität Bonn, 2000
[AsJa04]
Asche, Hartmut/Schwarz, Jan-Arne: Geoinformationssysteme, Vorlesungsskript, Institut für Geographie der Universität Potsdam, 2004
[Bark02]
Barker, F. Scott: Database Programming with Visual Basic® .NET and
ADO .NET, Sams Publishing, 2002
[Bart00]
Bartelme, Norbert: Geoinformatik, Springer, Berlin 2000
[Bi99]
Bill, Ralf: Grundlagen der Geo-Informationssysteme, Herbert Wichmann
Verlag, 1999
[BiZe01]
Bill, Ralf/Zehner, Marco: Lexikon der Geoinformatik, Herbert Wichmann
Verlag, 2001
[BuSn95]
Bugayevskiy, Lev M./Snyder, John P.: Map Projections, Taylor & Francis,
1995
[Dob03]
Dobson, Rick: Programming Microsoft Visual Basic .NET for Microsoft Access Databases, Microsoft Press, 2003
[Ha04]
Hadziresic, Ernest: Interaktive 2D-Bildschirmkarten mit Datenbankanbindung, Diplomarbeit, Institut für Informatik III der Universität Bonn, 2004
[GrWe02]
Groff, James R. /Weinberg, Paul N.: SQL: The Complete Reference, Second
Edition, Osborne/McGraw-Hill, 2002
[GIS99]
Das GIS-Tutorial 3.0 (http://www.gis-tutor.de)
[Gle01]
Glemser: Zur Berücksichtigung der geometrischen Objektunsicherheit in der
Geoinformatik, Dissertation, Fakultät Bauingenieur- und Vermessungswesen der Universität Stuttgart, 2001
[Geo03]
Geographic Information Technology Training Alliance (http://www.gitta.info)
73
[Gr02]
Green, Robert: Leitfaden Datenbankauswahl, (http://portal.dfpug.de/dfpug/
Dokumente/Online/Leitfaden%20Datenbankauswahl.doc)
[HaGrMe02]
Hake, Günter/Grünreich, Dietmar/Meng, Liqiu: Kartographie, Gruyter, 2002
[KeEi01]
Kemper, Alfons/Eickler, Andre: Datenbanksysteme, Oldenbourg, 2001
[Ku03]
Kunicke, Lutz: Entwurf und Implementierung eines Werkzeugs zur Visualisierung und interaktiven Manipulation von Geodaten, Diplomarbeit, Institut
für Informatik III der Universität Bonn, 2003
[La02]
Lange, Norbert: Geoinformatik in Theorie und Praxis, Springer, Berlin 2002
[Li94]
Litwin, Paul: Microsoft Jet Database Engine 2.0: A User’s Overview,
(http://support.microsoft.com/default.aspx?scid=kb;en-us;128386)
[Lib03]
Liberty, Jesse: Programming Visual Basic .NET, O’Reilly & Associates, 2003
[Man03]
Manthey, Rainer: Informationssysteme, Vorlesungsskript, Institut für Informatik III der Universität Bonn, 2003
[MSDNLib]
MSDN for Visual Studio .NET, (http://msdn.microsoft.com/)
[Op05]
OpenGeoDB: (http://opengeodb.sourceforge.net/)
[SaBe97]
Saurer, Helmut/Behr, Franz-Josef: Geographische Informationssysteme,
Wissenschaftliche Buchgesellschaft, 1997
[Sta01]
Stark, Benjamin: Vektorisierung von raum- und zeitbezogenen Daten zur
Visualisierung mit Macromedia Flash, Diplomarbeit, Fakultät Mathematik/Informatik der Universität Osnabrück, 2001
[Ste98]
Stephans: SQL in 21 Tagen, Markt+Technik, 1998
[Vo99]:
Vossen, Gottfried: Datenmodelle, Datenbanksprachen und DatenbankManagement-Systeme, Oldenbourg, 1999
[Wa96]:
Walter, Volker: Zuordnung von raumbezogenen Daten, Dissertation, Institut
für Photogrammetrie der Universität Stuttgart, 1996
74
Danksagung
Ich möchte mich ganz herzlich bei meinem Betreuer Professor Rainer Manthey für sein außergewöhnliches Engagement und für sein stets offenes Ohr für meine Fragen während der
Entstehung dieser Arbeit bedanken. Einen ganz besonderen Dank möchte ich meinen Eltern
für die Ermöglichung meines Studiums und für ihre Unterstützung in jeder Situation aussprechen.
75