Universität Zürich - Geographisches Institutgmiele/downloads/sihlwald_bericht_pro05_miele... · Als Ausgangsschema wird das Lebenszyklusmodell, aus der Vorlesung (Burghardt, Meile,

Universität Zürich - Geographisches Institut Geographische Informationssysteme Winterthurerstrasse 190 CH – 8057 Zürich

REGIONALPARK SIHLWALD

DATENBANK INFORMATIONSSYSTEM

Prototyp einer möglichen räumlichen Datenbank

auf der Basis von Oracle® Spatial Modul: GEO 451, Räumliche Datenbanken, Herbstsemester 2007 Autoren Leitung

Gianluca Miele Dr. Dirk Burghardt (Dozent) Dorfstrasse 18 Universität Zürich CH-8733 Eschenbach 055 / 511 21 17 Rolf Meile (Dozent) [email protected] WSL - Birmensdorf Jonas Snozzi Winterthurerstrasse 659 Lorenz Dolder (Tutor) CH-8051 Zürich Universität Zürich 044 / 311 25 78 [email protected]

Zürich, 8. Dezember 2007

Datenbank – Prototyp – Sihlwald

Inhalt 1. Einleitung.............................................................................................. 3

1.1 Projektbeschreibung ......................................................................................3 1.2 Aufgabenstellung ...........................................................................................3 1.3 Explizite Fragestellung ...................................................................................3 1.4 Verwendete Software und Methoden .............................................................4 1.5 Beteiligte Personen ........................................................................................4 1.6 Lebenszyklus einer Datenbank ......................................................................5

2. Datenbankentwurf................................................................................. 6

2.1 Anforderungsanalyse .....................................................................................6 2.2 Konzeptueller Entwurf ....................................................................................8

2.2.1 ER-Modell............................................................................................8 2.3 Logischer Entwurf ........................................................................................14

2.3.1 Ableitung des ER-Modells .................................................................15 2.3.2 Räumliche Topologie.........................................................................20

2.4 Physischer Entwurf ......................................................................................22 3. Datenbankimplementierung................................................................ 24 4. Laden der Beispieldaten ..................................................................... 26 5. Resultate............................................................................................. 28

5.1 Kommentare ...................................................................................................31 6. Erweiterungen und Diskussion ........................................................... 32

6.1 Implementierte Erweiterungen .....................................................................32 6.1.1 Informationstafeln ..............................................................................32 6.1.2 Erlebnispfad – Tabelle.......................................................................32 6.1.3 Vogelgruppen – view’s ......................................................................33 6.1.4 Erweiterte Abfragen...........................................................................33 6.1.5 Sequenz für Schlüsselattribute..........................................................35

6.2 Kurzbeurteilung der Datenbank....................................................................35 6.3 Mögliche Erweiterungen – Ausblick .............................................................36

7. Literatur und Quellen .......................................................................... 37 8. Anhang ............................................................................................... 38

Datenbank – Prototyp – Sihlwald

Abbildungen Abbildung 1: Lebenszyklusmodell eine Datenbanksystems. (Burghardt, Meile, 2007)_____________________ 5 Abbildung 2: Vereinfachtes Modell des Datenbankentwurfs. (Burghardt, Meile, 2007) ___________________ 6 Abbildung 3: ER-Diagramm für den Ausschnitt "Erlebnispfad". _____________________________________ 8 Abbildung 4: ER-Diagramm für den Ausschnitt "Gemeindegrenze". __________________________________ 9 Abbildung 5: ER-Diagramm für den Ausschnitt "Person"._________________________________________ 10 Abbildung 6: ER-Diagramm für den Ausschnitt "Vogelmeldung". ___________________________________ 11 Abbildung 7: ER-Diagramm für den Ausschnitt "Vogelmeldung und Person". _________________________ 12 Abbildung 8: ER-Modell für den Abschnitt "Parkgrenze". _________________________________________ 13 Abbildung 9: Erlebnispfad - logische Modellierung. _____________________________________________ 15 Abbildung 10: Gemeindegrenze - logische Modellierung. _________________________________________ 16 Abbildung 11: Person - logische Modellierung. _________________________________________________ 16 Abbildung 12: Vogelmeldung - logische Modellierung. ___________________________________________ 17 Abbildung 13: Vogelmeldung zu Person - logische Modellierung.___________________________________ 18 Abbildung 14: Parkgrenze - logische Modellierung. _____________________________________________ 19 Abbildung 15: Userdialog in PL/SQL Developer, create new table. _________________________________ 24 Abbildung 16: Userdialog in PL/SQL Developer, create new table: keys._____________________________ 24 Abbildung 17: Edit Table __________________________________________________________________ 25 Abbildung 18: Veränderung der Parkgrenze. Visualisierung des Abfrageresultats 3 mit PL/SQL Developer. _ 28 Tabellen Tabelle 1: Resultat Abfrage 1. ______________________________________________________________ 28 Tabelle 2: Resultat Abfrage 2. ______________________________________________________________ 28 Tabelle 3: Resultat Abfrage 3. ______________________________________________________________ 28 Tabelle 4: Resultat Abfrage 4. ______________________________________________________________ 29 Tabelle 5: Resultat Abfrage 5. ______________________________________________________________ 29 Tabelle 6: Resultat Abfrage 6. ______________________________________________________________ 29 Tabelle 7: Resultat Abfrage 7. ______________________________________________________________ 29 Tabelle 8: Resultat Abfrage 8. ______________________________________________________________ 29 Tabelle 9: Resultat Abfrage 9. ______________________________________________________________ 29 Tabelle 10: Resultat Abfrage 10. ____________________________________________________________ 30 Tabelle 11: Resultat Abfrage 11. ____________________________________________________________ 30 Tabelle 12: Resultat Abfrage 12. ____________________________________________________________ 30 Tabelle 13: Resultat Abfrage 13. ____________________________________________________________ 30 Tabelle 14: Resultat Abfrage 14. ____________________________________________________________ 30 Tabelle 15: Resultat Abfrage 15. ____________________________________________________________ 30 Tabelle 16: Ausschnitt Erlebnispfad - Tabelle mit Zuordnungen für Pfad, Posten, Weg und Infotafel. _______ 32 Tabelle 17: Resultat / Inhalt der Eulen - view. __________________________________________________ 33 Tabelle 18: Resultat Abfrage Nr. 14. Basierend auf view "meldung_erfasser". _________________________ 33 Tabelle 19: Resultat Abfrage 15. Basierend auf view "vogelart_anzahlmeldungen"._____________________ 33 Tabelle 20: Resultat Abfrage 16. Anzahl bisher gemeldeter Vögel pro Vogelart. _______________________ 34 Tabelle 21: Resultat Abfrage 17. Gemeldete Vögel pro Person._____________________________________ 34 Tabelle 22: Resultat Abfrage 18. Vogelmeldungen des Parkpersonals. _______________________________ 34 Tabelle 23: Resultat Abfrage 19. Vogelmeldungen max. 50m von einem Posten entfernt. _________________ 35 Tabelle 24: Resultat Abfrage 20. Gemeinden mit Vogelmeldungen.__________________________________ 35 Tabelle 25: Resultat Abfrage 21. Länge des aktuell begehbaren Erlebnispfads. ________________________ 35 Listing Listing 1: Trigger "meldung_in_parkgrenze". __________________________________________________ 20 Listing 2: Trigger "posten_in_parkgrenze". ____________________________________________________ 20 Listing 3: Trigger "infotafel_inparkgrenze". ___________________________________________________ 21 Listing 4: Trigger „posten_nearby_weg“. _____________________________________________________ 21 Listing 5: Metadatenregistrierung für Gemeindegrenzen__________________________________________ 22 Listing 6: Indexerzeugung für Gemeindegrenzen ________________________________________________ 22 Listing 7: Sequenz und Trigger für automatisches Hochzählen eines Primary Key. _____________________ 23 Listing 8: Tabelle erzeugen mit SQL, Beispiel Vogelmeldung. ______________________________________ 24 Listing 9: SQL für Eulen – view als Beispiel. ___________________________________________________ 33

Regionalpark - Sihlwald Datenbank - Prototyp

1. Einleitung Dieser Bericht ist eine ‚Roadmap’ zur Beantwortung der Fragestellung im Rahmen des GIS Masterblocks GEO 451 – Räumliche Datenbanken. Die räumliche Datenbank soll rund um den Sihlwald – Park erstellt werden. Der Sihlwald ist der grösste Laubmischwald des Schweizerischen Mittellandes. Er wurde über Jahrhunderte genutzt und gepflegt. Daher ist er kein Urwald. Heute ist der Sihlwald geschützt und erfreut täglich Besucher, die aus dem nahen Umland, zu dem auch Zürich gehört, per Bahn anreisen können. Innerhalb des Parks gibt es die Möglichkeit Ausstellungen zu besuchen und sich mit Informationen einzudecken. Der Sihlwald ist somit der ideale Exkursionsort (Stadt Zürich, 2007). Die genauen Eckdaten zur Beantwortung der Fragestellung bezüglich das Projekt wurden von der Übungsleitung wie folgt definiert.

1.1 Projektbeschreibung Das ganze Projekt wird um einen (noch) fiktiven Regionalpark im Sihlwald aufgebaut. Es sollen Sachdaten und raumbezogene Daten in einer Datenbank gespeichert, verwaltet und für verschiedene Benutzergruppen zugänglich gemacht werden. Um dies verwirklichen zu können, musste der Aufbau einer Datenbank von der Anforderungsanalyse bis zur Implementierung durchlaufen werden. Als Ziel wird eine möglichst sauber funktionierende und in ihren Inhalten konsistente Datenbank angestrebt. Der Fokus liegt somit nicht in der Fülle der Daten.

1.2 Aufgabenstellung Das Projekt befasst sich mit folgender grundsätzlicher Aufgabenstellung:

• Modellierung, Erstellung und Verwaltung räumlicher und nicht-räumlicher Daten. • Erstellung eines objekt-relationales Datenmodells. • Einfügen von Beispiel – Daten in das Modell • Erstellung typischer Abfragen für verschiedene Benutzergruppen respektive für

entsprechende Daten-Services.

1.3 Explizite Fragestellung Von der Übungsleitung wurde folgende explizite Fragestellung vorgegeben:

Grenzen des Regionalparks Bestimmen Sie die selbst eine stark generalisiert Grenze (Geometrie) des Parks. Womöglich ist zusätzliche Information am Institut oder im Internet verfügbar. Die Grenze des Regionalparks wird sich über die Zeit ändern. Wie gross war der Park 2005? Wie hat sich die Parkfläche in den letzten 10 Jahren verändert?

Gemeindegrenzen aller Gemeinden, die an die Stadt Zürich grenzen. Für eine zukünftige Webapplikation verwalten Sie auch die Daten der Gemeindegrenzen. Die ursprünglichen Grenzen werden Ihnen als ‚shape-file’ oder in der Datenbank zur Verfügung gestellt werden. Auch Gemeindegrenzen können sich ändern. Über welche Gemeinden erstreckt sich der Regionalpark? Eine mögliche Erweiterung des Parks könnte sich auch in die Gemeinde Baar (ZG) erstrecken. Für den Anteil der Zuger Fläche am Park zahlt der Kanton Zug der Stadt Zürich einen Betrag. Berechnung?

Walderlebnispfad mit 12 Posten Der bereits im Sihlwald vorhandene Walderlebnispfad mit seinen Posten wird für die Besucher auch interaktiv im Web zur Verfügung gestellt. Beschreibungen, Raumbezug, Information, Reihenfolge, Zugang für Behinderte, 'aktuelle Betriebslage' (Begehbarkeit) sollen für den Weg respektive die Wegstücke

- 3 -


festgehalten werden. Der Betriebszustand (z.B. über den Zustand der Infotafeln oder Lernobjekten) soll für die Posten vorhanden sein. Posten müssen nicht zwingend auf dem Weg, aber in der Nähe des Weges liegen. Legen Sie bei fehlender Information selber fest, wo die Posten liegen sollen. Digitalisieren Sie einen stark generalisierten Waldpfad und die Posten. Wo liegen die von Rollstuhlfahrern nicht zugänglichen Strecken des Pfades? Kann der Weg heute Sonntagmorgen begangen werden? Wo kann ich das Alter eines Baumes bestimmen?

Erfassen von Hör- oder Sichtmeldungen von Vögeln auf dem Gebiet des Regionalparks Die Meldungen stammen von Privatpersonen, deren Adresse, wenn nicht schon vorhanden, aufgenommen wird. Vogelarten werden jeweils mit Koordinaten, Zeitpunkt und Anzahl gemeldet. Ebenso erfasst wird der geschätzte oder gemessene Koordinatenfehler, die Qualität der Vogelartbestimmung, die erfassende Person und der Zeitpunkt der Erfassung. Die Daten 'landen' via Webapplikation in der Datenbank. Entweder erfassen die Privatpersonen selbst oder die Parkverwaltung nach telefonischer Meldung der Privaten. Für den Eintrag kann nur das aktuelle Gebiet des Parks berücksichtigt werden. Wo wurde in den letzten 3 Jahren der Schwarzspecht gesehen oder gehört? Welche Vogelarten tauchen im Regionalpark als Schwärme auf (mehr als 10 Exemplare)? Wie lauten Adresse und Telefonnummern derjenigen Person, die am meisten Funde gemeldet hat?

Besucher informieren sich über interessante Vogelgruppen Besonders spannend sind folgende Vogelgruppen: Eulen, Greifvögel, Wasservögel, Zugvögel, Brutvögel. Die Gruppen überschneiden sich im Bezug auf die Vogelarten. Die Waldohreule gehört beispielsweise zur Gruppe der Eulen, der Greifvögel und der Brutvögel (im Park brütend). Welche im Park festgestellten Vogelarten brüten hier? Haben die Meldungen über Eulen in den letzten 3 Jahren abgenommen? In welchem Gebiet werden gehäuft Greifvögel beobachtet?

1.4 Verwendete Software und Methoden In diesem Projekt wurde eine Oracle Datenbank 9i/10g mit räumlicher Erweiterung sowie die Client-Software PL/SQL Developer für den Zugriff auf die Datenbank verwendet. Seit Version 8.1.5 von Oracle-Spatial ist es möglich Geodaten objektrelational zu speichern und seit der Version 10g von Oracle, im Jahr 2004, wird die Speicherung von Topologie und georeferenzierten Daten unterstützt (Brinkhoff, 2005: 31). Bei der Umsetzung der Spatial-Erweiterung der Oracle-Datenbank kommt es jedoch zu einigen Ungereimtheiten. Die momentanen SQL-Standards werden demnach nur teilweise umgesetzt. Dies führt dazu, dass SQL-Datentypen in Oracle unterschiedlich repräsentiert werden. Die SQL-Datentypen NUMERIC und DECIMAL werden als NUMBER repräsentiert (Brinkhoff, 2005: 36f). Der PL/SQL Developer ist ein professionelles Tool, mit dem man SQLs schnell und effizient ausführen kann. Zudem verfügt es über etliche grafische Oberflächen um gewisseAbläufe zu vereinfachen.

1.5 Beteiligte Personen An diesem Projekt waren folgende Personen beteiligt:

Gianluca Miele – Student Pro05

Jonas Snozzi – Student Pro05

Dr. Dirk Burghardt – Dozent des Blocks GEO 451

Rolf Meile – Dozent des Blocks GEO 451

Lorenz Dolder – Tutor des Blocks GEO 451 Wir möchten allen beteiligten Personen ganz herzlich für ihre Zusammenarbeit danken.

- 4 -


1.6 Lebenszyklus einer Datenbank Die folgende Grafik illustriert welche Schritte im Rahmen dieses Projekts unternommen wurden. Als Ausgangsschema wird das Lebenszyklusmodell, aus der Vorlesung (Burghardt, Meile, 2007), verwendet. Grau hinterlegt sind jene Schritte, die in diesem Projekt nicht durchgeführt worden sind.

1. Systemdefinition 2. Datenbankentwurf 3. Datenbankimplementierung

4. Laden oder Datenkonvertierung (5. Anwendungskonvertierung)

6. Testen und Validierung

(7. Betrieb)

(8. Überwachung und Wartung)

Abbildung 1: Lebenszyklusmodell eine Datenbanksystems. (Burghardt, Meile, 2007)

1. Systemdefinition: Umfang des DBS1, deren Nutzer und Anwendungen werden

definiert. Dies wurde in der Aufgabenstellung vorgegeben. (siehe Kap. 1.3) 2. Datenbankentwurf: Wird mit dem vollständigen logischen und physischen

Datenbankenwurf abgeschlossen. (siehe Kap. 2) 3. Datenbankimplementierung: Erzeugung der leeren Tabellen. (siehe Kap. 3) 4. Laden oder Datenkonvertierung: Einlesen von Beispieldaten. (siehe Kap. 4) 5. Anwendungkonvertierung: Wird übersprungen, da keine früheren DB2 vorhanden

sind. 6. Test und Validierung: Die vorgegebenen Anforderungen an die DB werden anhand

von Beispieldaten getestet und validiert. (siehe Kap. 5) 7. Betrieb & 8. Überwachung und Wartung: Da es sich im Rahmen dieses Projekts um

einen Prototypen handelt werden diese Schritte nicht durchgeführt. Der Schritt 1 wurde wie bereits erwähnt in der Aufgabenstellung vordefiniert. Schreiten wir nun im Produktzyklusmodell weiter zu Schritt 2, dem Datenbankentwurf.

1 DBS, Abkürzung für Datenbanksystem. 2 DB, Abkürzung für Datenbank.

- 5 -


2. Datenbankentwurf Aus der Vorlesung (Burghardt, Meile, 2007) kann entnommen werden, wie die Phasen des DB-Entwurfs aussehen. Vereinfacht sieht dies wie in der folgenden Abbildung aus:

Abbildung 2: Vereinfachtes Modell des Datenbankentwurfs. (Burghardt, Meile, 2007)

Als erstes soll eine Anforderungsanalyse durchgeführt werden. Der Konzeptueller Entwurf soll mit dem ER-Modell3 abgeschlossen werden. Der Logisch Entwurf soll mit dem relationalen Modell beendet werden. Im physischen Entwurf soll noch die Effizient gesteigert werden.

Der ganze Prozess darf aber nicht als rein linearer Verlauf wahrgenommen werden. Wege auftauchender Probleme im logischen Entwurf mussten immer wieder Korrekturen im konzeptuellen Entwurf (ER-Modell) vorgenommen werden (Burkhardt, Meile, 2007).

2.1 Anforderungsanalyse Eine Anforderungsanalyse wird normalerweise im engen Kontakt mit dem Kunden durchgeführt. Sie ist ein entscheidender Baustein im Werdegang einer Datenbank. Wird sie nicht konsequent durchgeführt, können die Folgekosten um eine Datenbank umzuschreiben exponentiell ansteigen (Burkhardt, Meile, 2007). Wir haben als Ausgangslage die vorgegebene Aufgabenstellung verwendet. Die Aussagen auf dem Aufgabenblatt wurden in möglichst präzise Anforderungen umformuliert. Diese Anforderungen sollten zudem möglichst kurz und prägnant sein um daraus die Struktur der Daten erkennen zu können. Des weiteren werden die möglichen Entitätstypen Fett und die Attribute unterstrichen dargestellt.

Die räumliche Modellierung des Parks erfolgt über eine stark generalisierte Grenze.

Die Grenze des Regionalparks ändert sich über die Zeit. Für die Geometrien müssen

aufgrund der zeitlichen Veränderung jeweils zusätzliche Informationen in Form eines

Datums abgespeichert werden.

Die Gemeindegrenzen der an die Stadt Zürich angrenzenden Gemeinden werden

gespeichert. Auch diese können sich über die Zeit ändern. Die beteiligten Gemeinden

zahlen, je nach beteiligter Fläche, der Stadt Zürich einen Betrag.

Der Walderlebnispfad besteht aus 12 Posten. Der Pfad mit seinen Posten soll auch

interaktiv im Web zugänglich sein.

3 ER-Modell: Abk. Entity-Relationship-Modell. (Kannengiesser, 2004: 84)

- 6 -


Für die Wegstücke des Walderlebnispfades sollen Beschreibungen, Start- und

Endkoordinaten, aktuelle Betriebslage und Informationen über Zugang für Behinderte

zur Verfügung stehen.

Jeder Posten wird mit Informationen über seine Koordinaten, Titel, Beschreibung und

Betriebszustand abgespeichert.

Die Posten müssen nicht auf dem Weg liegen, aber in dessen Nähe.

Hör- und/oder Sichtmeldungen von Vögeln auf dem Parkgebiet sollen erfasst und

abgelegt werden können. Die Meldungen stammen von Privatpersonen, die mit

vollständiger Adresse registriert werden.

Eine Meldung enthält jeweils Vogelarten, Koordinaten, Zeitpunkt der Sichtung sowie

Anzahl der gesichteten / gehörten Exemplare. Für jede Meldung werden zusätzlich

Koordinatenfehler (geschätzt oder gemessen), Zeitpunkt der Erfassung und die

erfassende Person registriert.

Privatpersonen können die Meldung entweder selber erfassen oder sie

benachrichtigen die Parkverwaltung, die dann die Meldung im System erfasst.

Die Vogelarten gehören mindestens einer oder mehreren Vogelgruppen an.

Über die Vogelgruppen: Eulen, Greifvögel, Wasservögel, Zugvögel und Brutvögel

können sich die Besucher informieren.

Aus der Anforderungsanalyse können direkt Entitäten sowie deren Attribute abgeleitet werden. Zusätzlich können noch Beziehungen herausgelesen werden.

Angrenzende Gemeinden überschneiden Parkgrenze Posten sind nahe beim Weg Vogelmeldungen innerhalb des Parkgebiets Parkverwaltung erfasst Vogelmeldung Privatperson meldet Vögel

Diese werden in einem nächsten Schritt, dem konzeptuellen Entwurf, ausgewertet und in einem ER-Diagramm4 abgebildet. Die als mögliche Entitätstypen identifizierten Objekte können dabei zusammengefügt werden.

4 ER-Diagramm: Die grafische Darstellung von Entitäts- und Beziehungstypen, also des ER-Modells.

- 7 -


2.2 Konzeptueller Entwurf In diesem Schritt soll als Endprodukt ein ER-Modell erzeugt werden. Ausgehend von unserer Anforderungsanalyse wurden die Entitäten, Attribute und Beziehungen in das ER-Modell übertragen. Das ER-Modell wurde mehrmals überarbeitet. Es sieht wie folgt aus. 2.2.1 ER-Modell Ein ER-Diagramm kann in unterschiedlicher Komplexität erzeugt werden. In unserem Fall genügen die Entität, deren Attribute und Schlüsselattribute, die Beziehung (1-1, 1-n, n-n) und eine Information darüber um was für eine räumliche Ausprägung es sich handelt. Für räumliche Beziehungen wurden die Symbole gestrichelt gezeichnet. Das komplette ER-Diagramm ist im Anhang beigefügt. In diesem Kapitel sollen, zur besseren Übersicht, einzelne Teile des ER-Diagramms getrennt besprochen werden. Wir teilen das ganze ER-Diagramm in die Teile Erlebnispfad, Gemeindegrenze, Person und Vogelmeldung auf. Diese Teile können dann mittels der Entität Parkgrenze in einen räumlichen Zusammenhang gebracht werden. - Erlebnispfad

Abbildung 3: ER-Diagramm für den Ausschnitt "Erlebnispfad".

Zu diesem Teil der Datenbank wurden viele Überlegungen angestellt. Im Entwicklungsprozess unterlag dieser Teil daher auch den grössten Veränderungen. Aus der Aufgabenstellung wurden Entitäten Posten und Wegabschnitte direkt abgeleitet. Als weitere Entität wurde die Infotafel definiert, da es möglich sein sollte die Infotafel unabhängig von den Posten zu erfassen. Dies ermöglicht zum Beispiel die Erfassung von Warnschildern. Im ER-Modell sind oben links in den Entitäts – Kästen die geometrischen Attribute spezifiziert (Punkt / Linie / Polygon).

- 8 -


Die Entitäten Posten und Infotafel wurden als Punkte, die Entität Wegabschnitt als Linie definiert. Zu den einzelnen Tafeln mussten verschiedene Attribute definiert werden. Wichtigster Hinweis sind die Attribute Betriebszustand oder Zustand. In der Datenbank soll erfasst werden können, ob eine Infotafel, ein Wegabschnitt oder Posten gerade betriebstauglich ist. Alle drei Entitäten zusammen ergeben den Erlebnispfad mittels einer M:N:O-Beziehung. (Dies ist in Abbildung 3wegen der eigentlichen räumlichen Beziehung von Wegabschnitt und Posten, unterschiedlich gezeigt). E Erlebnispfad muss zwingend einen Wegabschnitt beinhalten. Die Posten und Tafeln sind hingegen nicht zwingend nötig. Weiter besteht zwischen Posten und Wegabschnitt eine räumliche „near by“ – Beziehung. Sie trägt der in der Projektbeschreibung angestrebten Forderung Rechnung, dass ein Posten sich in der Nähe eines Wegabschnittes befinden muss (siehe Kap. 1.3). Aus technischen Gründen konnte der „near by“ – Trigger erst gegen Ende des Projekts realisiert werden. Dies ist eine ergänzende Funktion und löst die bestehende logische Beziehung nicht ab. - Gemeindegrenze

GEMEINDE

Geometrie (Polygon)

Gem-Nr

von (date)

Gemeindenamen

„hat“

1

nGem-Nr

bis (date)

GemGrenz-Nr

Kantons-Nr

KANTON

Kantons-Nr Kantonsname

GEMEINDEGRENZ

„hat“

1

n

Abbildung 4: ER-Diagramm für den Ausschnitt "Gemeindegrenze".

Aus der Anforderungsanalyse ging hervor, dass es die Entitäten Kanton und Gemeinde geben muss. Da eine Gemeinde mehrere Grenzen haben kann wurde die zusätzliche Entität Gemeindegrenze definiert, welche von einem Anfangsdatum bis zu einem Schlussdatum gültig ist. Da es sich beim Sihlwald – Park in Zukunft um ein interkantonales5 Gebiet handeln soll wurde die Gemeindegrenze mit dem Kanton verknüpft. Da nur die Gemeindegrenze ein geometrische Attribut besitzt wurde dieser Entität ein Polygonsymbol zugeordnet.

5 Der Park soll zukünftig erweitert werden, was v.a. die Fläche des Kantons Zug betreffen würde.

- 9 -


- Person

Abbildung 5: ER-Diagramm für den Ausschnitt "Person".

Die Entität Person wurde direkt aus der Anforderungsanalyse abgeleitet. Da es sowohl Privatpersonen, die gesichtete Vögel melden können, als auch Verwalter, welche die Vogelmeldungen administrieren, geben kann, haben wir diese Beziehung mittels einer disjunktiven6 Generalisierung gelöst. Der (Wohn-) Ort wurde als separate Entität modelliert und mittels einer 1:N-Beziehung an die Entität Person geknüpft.

6 disjunkt: einander ausschliessend, trennend, gegensätzlich. (Wahrig, 2002)

- 10 -


- Vogelmeldung

VOGELMELDUNG

VOGELART

VOGELGRUPPE

m

Gruppenarten

n

enthält

1

1

Name

VGr-ID Name

VArt-ID

Meldung-Nr VArt-IDGeometrie (Punkt)

Datum_Zeit

Anzahl_Tiere

Meldende_Person(PersID)

Erfassende_Person(VWID)

Beobachtungstyp

Fehler_gemolden

Abbildung 6: ER-Diagramm für den Ausschnitt "Vogelmeldung". Um den Aspekt der Vogelmeldungen zu berücksichtigen, waren wiederum einige wichtige Entscheidungen zu treffen. Die Beziehung der Vogelart zur Vogelgruppe war relativ simpel abzuleiten. Es handelt sich um eine klare M:N-Beziehung, wobei jede Vogelart einer oder mehreren Vogelgruppen zugeordnet wird, aber nicht zwingend jede Vogelgruppe eine Vogelart beinhalten muss. DieVogelmeldung wurden gegenüber den Vorgaben noch erweitert und mit weiteren Attributen ergänzt. Die Beziehung der meldenden und erfassenden Person zur Entität Vogelmeldung wird in Abbildung 7 erläutert.

- 11 -


- Vogelmeldung zu Person

Abbildung 7: ER-Diagramm für den Ausschnitt "Vogelmeldung und Person".

Die Entitäten Vogelmeldung und Person stehen in einem wichtigen Zusammenhang. In der Personentabelle gibt es sowohl Privatpersonen als auch Verwalter. Jede Person kann eine Vogelbeobachtung melden. Jedoch nur Verwalter können diese auch erfassen (und evt. kontrollieren). Da der Entität Person mittels disjunktiver Spezialisierung zusätzliche Verwalterattribute angehängt werden, ergibt sich nun die Möglichkeit von der Vogelmeldung auf dieses Verwalterattribut zu verweisen.

- 12 -


- Parkgrenze

Abbildung 8: ER-Modell für den Abschnitt "Parkgrenze".

Die Entität Parkgrenze, welche mit allen vorgängig diskutierten Entitäten in Beziehung steht, bildet die zentrale Entität unserer Modellierung. Die Parkgrenze definiert die Ausdehnung des Parks zu verschiedenen Zeitpunkten, was eine Modellierung der Parkgrenze über die Zeit erst ermöglicht. Zu den vorgestellten Entitäten bestehen lediglich räumliche Beziehungen. Die sich somit ergebende Verschneidung der Gemeindegrenzen (und somit auch der Kantone) mit der Parkgrenze erlaubt es festzustellen zu welchem Anteil einzelne Gemeinden am Sihlwald – Park beteiligt sind. Weiter müssen die Vogelmeldungen und die möglichen Erlebnispfade innerhalb der definierten und momentan gültigen Parkgrenze liegen.

- 13 -


2.3 Logischer Entwurf Das Logische Modell wurde anhand der Überführungsregeln von Meier erstellt. Sie lauten: (abgekürzte Version)

1. Jede Entitätsmenge muss als eigenständige Tabelle mit eindeutigem Primärschlüssel definiert werden.

2. Jede Beziehungsmenge kann als eigenständige Tabelle definiert werden, wobei die Primärschlüssel der zugehörigen Entitätsmengen als Fremdschlüssel in dieser Tabelle auftreten müssen.

3. Jede M:N-Beziehung muss als eigenständige Tabelle definiert werden. Dabei treten mindestens die Primärschlüssel der zugehörigen Entitätstypen als Fremdschlüssel auf.

4. Eine N:1 oder 1:1 Beziehung kann ohne eine eigenständige Tabelle mittels Primär-Fremdschlüssel Beziehung abgebildet werden. Dazu wird der Primärschlüssel der einen Tabelle (1-Zweig) als Fremdschlüssel in die andere Tabelle (N-Zweig) eingefügt.

Somit werden Entitätstypen als Tabellen realisiert. Die dazugehörigen Variablen werden zu Spalten. 1:1-/ und 1:N-Beziehungen können mittels Fremdschlüssels erzeugt werden. Für eine M:N-Beziehung muss eine neue Tabelle mit zwei Fremdschlüsseln generiert werden. Zusätzlich wurde versucht die Tabellen in Normalform zu halten. Die 1. Normalform sagt aus, dass nur atomare Attribute auftreten. Dies konnte immer realisiert werden. Die 2. Normalform bedeutet, dass die 1. Normalform herrscht und alle Nichtschlüsselattribute voll funktional vom Primärschlüssel abhängen. Die 3. Normalform bedeutet, dass die 2. Normalform herrscht und keine Nichtschlüsselattribute transitiv vom Primärschlüssel bestehen. Die 3. Normalform wurde nicht in allen Fällen erreicht. So könnten einige Tabellen noch weiter aufgeteilt werden. Dies macht in unserem Fall aber nur wenig Sinn, da die Struktur der Datenbank dadurch nur unnötig kompliziert würde. (Burghardt, Meile, 2007)

- 14 -


2.3.1 Ableitung des ER-Modells Das logische Modell wird nun im Folgenden analog zum ER-Modell diskutiert. Das ganze logische Modell kann im Anhang betrachtet werden. - Erlebnispfad

Abbildung 9: Erlebnispfad - logische Modellierung. Die M:N:O-Beziehung zwischen den Tabellen Wegabschnitt, Infotafel und Posten wurde mittels einer neuen Tabelle gelöst. Der Erlebnispfad hat als Primary-Key die Erlebnispfad-Nummer. Es können also mehrere Erlebnispfade erstellt werden. Die Foreign-Keys verweisen auf die Tabellen Infotafel, Posten und Wegabschnitt. Die Beschreibung und Information zu den Tabellen Posten und Wegabschnitt können ‚Null’ sein.

- 15 -


- Gemeindegrenze

Abbildung 10: Gemeindegrenze - logische Modellierung. Die Tabelle Gemeindegrenz verweist mittels Foreign-Key auf den Primary-Key der Tabelle Kanton und Gemeinde. Sämtliche Attribute dürfen nicht ‚Null’ sein. - Person

Abbildung 11: Person - logische Modellierung. Die disjunktive Beziehung zwischen den Tabellen Person und Verwalter wurde mittels Foreign-Key (PersID, diese ist zugleich Primary-Key zusammen mit VWID) realisiert. Die Tabelle Privatperson muss nicht erstellt werden, da die Entität Person sämtliche Attribute beinhaltet, welche die Entität Privatperson hätte.

- 16 -


- Vogelmeldung

Abbildung 12: Vogelmeldung - logische Modellierung. Die M:N-Beziehung zwischen der Vogelgruppe und der Vogelart wurde mittels einer neuen Tabelle realisiert. In ihr werden die Zugehörigkeiten einer Vogelart zu einer Vogelgruppe geregelt. Die Tabelle Vogelmeldung verweist mittels eines Foreign-Keys auf die Vogelart. Sämtliche Attribute ausser „Fehler_gemolden“ dürfen nicht ‚Null’ sein.

- 17 -


- Vogelmeldung zu Person

Abbildung 13: Vogelmeldung zu Person - logische Modellierung.

Die Beziehung zwischen der Tabelle Vogelmeldung und der Tabelle Person (welche eine Vogelmeldung macht) sowie die Beziehung zwischen der Tabelle Vogelmeldung und der Tabelle Verwalter (welche die Meldung eingibt) wurde mittels „Foreign-Key“ gelöst.

- 18 -


- Parkgrenze

Abbildung 14: Parkgrenze - logische Modellierung. Alle Beziehungen der Tabellen Parkgrenze zu den anderen Entitäten sind nicht logischer Natur. Daher müssen die Beziehungen zu den Tabellen Infotafel, Posten, Wegabschnitt und Vogelmeldung mittels Trigger gelöst werden. Diese vier Instanzen müssen räumlich innerhalb der Parkgrenze liegen. Die Beziehung der Tabelle Parkgrenze zu den Gemeindegrenzen lässt sich nur anhand des gleichen Referenzsystems (CH1903+) beschreiben.

- 19 -


2.3.2 Räumliche Topologie Um die räumliche Topologie der verschiedenen Entitäten in der Datenbank abbilden zu können, bedienen wir uns einiger Trigger. Dabei handelt es sich um Routinen, welche für eine spezifizierte Tabelle beim Einfügen oder Ändern von Datensätzen aufgerufen werden und überprüfen, ob die neuen Daten den topologischen Anforderungen genügen. So überprüft der zentrale Trigger, ob die geographischen Angaben einer Vogelmeldung sich auch tatsächlich innerhalb der aktuell geltenden Parkgrenze befinden (Listing 1). Das selbe haben wir für die Platzierung der Posten (Listing 2) und der Infotafeln (Listing 3) implementiert. Als speziell herausfordernd stellte sich die topologische Beziehung heraus, welche besagt, dass sich ein Posten sich in der Nähe des Erlebnispfades bzw. eines einzelnen Wegabschnittes befinden muss (Listing 4). Nachfolgend sind die listing der Trigger inklusive zugehöriger Kommentare aufgeführt. -- 1. TRIGGER: 'meldung_in_parkgrenze' -- Trigger Voglemeldung innerhalb Parkgrenze -- Es wird sichergestellt, dass die Koordinaten einer Vogelmeldung mit -- Sicherheit innerhalb der deklarierten Parkgrenze liegen. -- Es wird der räumliche Operator 'SDO_Contains' verwendet, der -- ein Polygon und ein Punkt/Linie als input erwartet. -- Falls nicht, wird ein Error mit Info-Text ausgegeben. CREATE OR REPLACE TRIGGER meldung_in_parkgrenze BEFORE INSERT OR UPDATE ON VOGELMELDUNG FOR EACH ROW DECLARE num_check NUMBER; BEGIN SELECT COUNT(*) INTO num_check FROM PARKGRENZE pg WHERE mdsys.sdo_contains(pg.pgrenzshape, :NEW.meldepoint) = 'TRUE' AND pg.isvalid = 1; IF num_check <> 1 THEN RAISE_APPLICATION_ERROR(-20500, 'Vogelmeldung ausserhalb Parkgrenze'); END IF; END;

Listing 1: Trigger "meldung_in_parkgrenze". -- 2. TRIGGER: 'posten_in_parkgrenze' -- es wird sichergestellt, dass die posten innerhalb der -- aktuell gültigen parkgrenze liegen -- die methodik enspricht der für den trigger betreffend den vogelmeldungen CREATE OR REPLACE TRIGGER posten_in_parkgrenze BEFORE INSERT OR UPDATE ON posten FOR EACH ROW DECLARE num_check NUMBER; BEGIN SELECT COUNT(*) INTO num_check FROM PARKGRENZE pg WHERE mdsys.sdo_contains(pg.pgrenzshape, :NEW.postenpoint) = 'TRUE' AND pg.isvalid = 1; IF num_check <> 1 THEN RAISE_APPLICATION_ERROR(-20501, 'Posten ausserhalb Parkgrenze'); END IF; END;

Listing 2: Trigger "posten_in_parkgrenze".

- 20 -


-- 3. TRIGGER: ’infotafeln_in_parkgrenze’ -- es wird sichergestellt, dass die infotafeln innerhalb der -- aktuell gültigen parkgrenze liegen -- die methodik enspricht der für den trigger betreffend den vogelmeldungen CREATE OR REPLACE TRIGGER infotafel_in_parkgrenze BEFORE INSERT OR UPDATE ON infotafel FOR EACH ROW DECLARE num_check NUMBER; BEGIN SELECT COUNT(*) INTO num_check FROM PARKGRENZE pg WHERE mdsys.sdo_contains(pg.pgrenzshape, :NEW.infotpoint) = 'TRUE' AND pg.isvalid = 1; IF num_check <> 1 THEN RAISE_APPLICATION_ERROR(-20502, 'Infotafel ausserhalb Parkgrenze'); END IF; END;

Listing 3: Trigger "infotafel_inparkgrenze". -- 4) TRIGGER: 'posten_nearby_weg' -- Trigger Posten in der Nähe eines Wegabschnittes. -- Es wird sichergestellt, dass die Koordinaten eines Pfostens -- in der Nähe eines Wegabschnittes liegen. (Distanz = 25m) -- Es wird der räumliche Operator 'SDO_WITHIN_DISTANCE' verwendet. -- Dieser erwartet zwei Geometrien und einen Distanzparameter als -- Inputvariable für die Funktion. -- Falls ein Posten mehr als 25m von einem Wegabschnitt entfernt ist, -- wird ein Error mit Info-Text ausgegeben. CREATE OR REPLACE TRIGGER posten_nearby_weg BEFORE INSERT OR UPDATE ON posten FOR EACH ROW DECLARE num_check NUMBER; BEGIN SELECT COUNT(*) INTO num_check FROM wegabschnitt w WHERE mdsys.sdo_within_distance(w.wegline, :NEW.postenpoint, 'distance=25') = 'TRUE'; AND pg.isvalid = 1; IF num_check <> 1 THEN RAISE_APPLICATION_ERROR(-20503,'Posten > 25m vom Pfad entfernt.'); END IF; END;

Listing 4: Trigger „posten_nearby_weg“.

- 21 -


2.4 Physischer Entwurf Definitionsgemäss verfolgt jeder physische Entwurf einer Datenbank das Ziel der Effizienzsteigerung. Dies geschieht unter Beachtung unten aufgeführter Punkte, die im Zusammenhang mit diesem Kurs und Projekt jedoch nicht vertieft behandelt werden.

• Zugriffseinheiten • Speicherhierarchie • Pufferverwaltung • Adressierung • Indexstrukturen

(Lausen, 2007). Die Indexierung (v.a. der räumlichen Daten) fand in diesem Prototypen als einziges grössere Beachtung. Dazu wurden zuerst Metadaten – Informationen hinzugefügt, die Angaben über min-, max. – Ausdehnung und räumliche Referenz beinhalten. Listing 5 und Listing 6 zeigen die dazu notwendigen SQL – Codes am Beispiel der Gemeindegrenzen – Tabelle. -- 1) Metadaten Registrierung -- Die Metadatenregistrierung erfolgt für alle Geometrien analog. -- Als Raum wird die Schweiz mit den minimalen und maximalen -- Grenzen von x und y verwendet. Genauigkeit ist 1 mm. -- Das räumliche Koordinatensystem bezieht sich auf die Schweiz: srid = 352257. -- a) Gemeindegrenzen INSERT INTO USER_SDO_GEOM_METADATA VALUES ( GEMGRENZ', 'GEMSHAPE', -- 'tabelle', 'räumliche spalte' MDSYS.SDO_DIM_ARRAY( MDSYS.SDO_DIM_ELEMENT('X', 485410, 833855, 0.001), -- ausdehnung in X MDSYS.SDO_DIM_ELEMENT('Y', 75270, 295935, 0.001) ), -- ausdehnung in Y 352257 ) -- räumliches referenzsystem: CH1903+ (srid = 352257)

; Listing 5: Metadatenregistrierung für Gemeindegrenzen

-- 2) Erstellund des räumlichen Index -- a)Gemeindegrenzen 'gemgrenz' CREATE INDEX gemgrenz_geometry_idx ON gemgrenz(gemshape)

INDEXTYPE IS MDSYS.SPATIAL_INDEX ;

Listing 6: Indexerzeugung für Gemeindegrenzen

- 22 -


Zur Sicherstellung der Datenintegrität und zur leichten Effizienzsteigerung bei der Datenerfassung wurden eine Sequenz und ein dazugehöriger Trigger implementiert. Diese garantieren, dass für jeden neu hinzukommenden Datensatz der „Primary-Key“ automatisch um den Wert 1 inkrementiert. Es ist zu beachten, dass dies erst im späteren Verlauf des Projekts realisiert worden ist, weshalb Inkonsistenzen in gewissen SQL’s möglich sind, weil dort das primäre Schlüsselattribut noch manuell hinzugefügt wurde. Listing 7 zeigt die dazu notwendigen SQL’s am Beispiel der Tabelle „Vogelart“. -- 3) SEQUENZ und TRIGGER -- Beispiel für Tabelle: "Vogelart" -- sequenz, die automatisch die primary key's inkrementiert -- funktioniert in zusammenhang mit trigger, der überprüft und -- den nächsten wert aus der sequenz dem neuen datensatz zuweist. CREATE SEQUENCE varid_sq MINVALUE 1 MAXVALUE 99999999 START WITH 39 -- 39 weil bis schon 38 Vogelarten in Tabelle INCREMENT BY 1 -- normal wird mit 1 gestartet! CACHE 2 CREATE OR REPLACE TRIGGER VARID_TRI

BEFORE INSERT /*OF VARID*/ ON Vogelart FOR EACH ROW DECLARE num NUMBER; BEGIN SELECT VARID_SQ.NEXTVAL INTO num FROM dual; :NEW.VARID := num; END VARID_TRI

Listing 7: Sequenz und Trigger für automatisches Hochzählen eines Primary Key.

- 23 -


3. Datenbankimplementierung Die Tabellen wurden teils über SQL-Befehle, teils über das grafische Interface des PL/SQL Developers (siehe Abbildung 15 und Abbildung 16) generiert. Ein Beispiel für einen solchen SQL-Befehl ist in Listing 8 aufgeführt. CREATE TABLE VOGELMELDUNG( MELDUNGNR NUMBER(5) NOT NULL, VARTID NUMBER(5) NOT NULL, ANZAHLTIERE NUMBER(3) NOT NULL, BEOBACHTUNGSTYP VARCHAR(10) NOT NULL, DATUM DATE NOT NULL, FEHLERGEMOLDEN NUMBER(5), MELDEPERSON NUMBER(5), ERFASSUNGSPERSON NUMBER(5), MELDEPOINT SDO_GEOMETRY NULL, PRIMARY KEY(MELDUNGNR), FOREIGN KEY(VARTID) REFERENCES pro05.vogelart(varid), FOREIGN KEY(ERFASSUNGSPERSON) REFERENCES pro05.personen(persid), FOREIGN KEY(MELDEPERSON) REFERENCES pro05.personen(persid) )

Listing 8: Tabelle erzeugen mit SQL, Beispiel Vogelmeldung.

Abbildung 15: Userdialog in PL/SQL Developer, create new table.

Abbildung 16: Userdialog in PL/SQL Developer, create new table: keys.

- 24 -


Abbildung 17: Edit Table

Sämtliche Tabellen wurden auf die eine oder andere Weise generiert. Über die Schaltfläche ‚Edit Table’ konnten die Tabelle noch editiert werden (siehe Abbildung 17).

- 25 -


4. Laden der Beispieldaten Als nächstes wurden in sämtliche Tabellen Beispieldaten eingefügt. Die Bezugsquellen der Daten werden im Folgenden erläutert. Gemeinden, Gemeindegrenzen, Kantone Die thematischen und geometrischen Daten zu den Gemeinden, ihren Grenzen und Kantonszugehörigkeit stammen vom Schema ‚usrdemo’ der Übungsleitung. Der Inhalt wurde eins zu eins in die Projekt-Datenbank übernommen. Zusätzlich wurden für die Gemeindegrenzen zwei weitere Attribute zur zeitlichen Modellierung möglicher Veränderungen eingefügt, die zum jetzigen Zeitpunkt aber noch leer sind. Parkgrenze Die in der Datenbank erfassten Parkgrenzen basieren auf einen stark generalisierten Verlauf der Parkausdehnung (OpenMapSihlwald). Es wurden fünf, in ihrer Ausdehnung unterschiedliche, Parkflächen gespeichert, wobei die Nr. 5 ein mögliches zukünftiges Szenario darstellt, wo ein Teil der Parkfläche im Kanton Zug liegt. Weiter ist der zeitliche Aspekt auch hier implementiert worden. Dazu wurden wiederum zwei Attribute des Datentyps ‚Datum’ eingefügt, welche Anfangs- und Endzeitpunkt der Gültigkeit einer Parkgrenze beinhalten. Wegabschnitte Ebenfalls auf den Informationen der Website „OpenMapSihlwald“ basieren die einzelnen Wegabschnitte in geometrischen und thematischer Hinsicht. Informationen über Rollstuhlzugänglichkeit stammen von der Stadt Zürich. Die Nummerierung der einzelnen Wegabschnitte ist zugleich deren Reihenfolge. Alle Wegabschnitte aneinandergereiht, ergeben folglich den Erlebnispfad. Posten Alle Posten sind entlang dem Erlebnispfad verteilt. Dabei wurde z.B. darauf geachtet, dass der Posten ‚Jahrringe zählen’ sich nicht beim Wegabschnitt ‚Bahnhof’, sondern im Wald befindet. Titel sowie Inhalt der einzelnen Posten stammen von der Website der Stadt Zürich. Infotafeln Um die Platzierung von Informationstafeln im Parkgelände zu ermöglichen, wurden einfache Warn- oder Willkommenstafeln generiert, die möglichst realistisch platziert wurden. So finden sich eine Willkommens-Tafel vor dem Museumsgebäude, und zwei Warntafeln bei den für Rollstuhlgäste nicht zugänglichen Wegabschnitten. Personen, Verwalter und Ort Die Inhalte dieser drei Tabellen sind mit Ausnahme der Orte, welche existierende Städte und Ortschaften beinhalten, vollkommen willkürlich. Die Subklasse Verwalter speichert zusätzlich für fünf zufällig ausgewählte Personen, deren Tätigkeit als Parkpersonal.

- 26 -


Vogelarten, -gruppen und –meldungen Die in der Datenbank erfassten Vogelarten bilden eine Auswahl, aus einem Datensatz der Vogelwarte – Sempach. Aufgrund dieser Datensätze erfolgte auch die Zuordnung einer bestimmten Vogelart zu einer oder mehreren Vogelgruppen. Die Vogelgruppe „Brutvogel“ wurde willkürlich zusammengestellt. Es gäbe einen Datensatz, der sämtliche brütenden Vogelarten im Sihlwald – Park enthält. Da es sich aber nur um einen Beispieldatensatz handelt haben wir uns diese Mühe erspart. Alle in der Datenbank registrierten Vogelmeldungen sind willkürlich erstellt worden und dienen lediglich der Überprüfung der implementierten Datenbankstruktur und ihrer internen Kompatibilität. Zusätzlich zu den eigentlichen Daten wurden jeweils für alle Attribute der Tabellen Kommentare erfasst, die Missverständnisse und Unklarheiten beim Eintragen von Daten auf ein Minimum reduzieren sollten.

- 27 -


5. Resultate Das folgende Kapitel zeigt die mit der implementierten Datenbank erreichten Resultate bezüglich der in Kap.1.3 spezifizierten expliziten Fragestellungen. Die SQL – Abfragen dazu finden sich im Anhang. Alle Abfragen wurden mit den nötigen Kommentaren versehen. Die Nachvollziehbarkeit der erzielten Resultate ist somit gegeben.

Wie gross ist der Park, bezogen auf die aktuelle Grenze?

PGRENZID VON BIS AKTUELLE_PARKFLÄCHE_QKM 4 10.12.2006 31.12.2007 17.268

Tabelle 1: Resultat Abfrage 1.

Wie gross war der Park im Jahr 2005?

PGRENZID VON BIS PARKFLÄCHE_QKM 2 15.03.2005 31.12.2005 4.126


Wie veränderte sich die Parkgrenze in den letzten 10 Jahren?

PGRENZID VON BIS PARKFLÄCHE_QKM 1 28.02.2004 14.03.2005 1.58 2 15.03.2005 31.12.2005 4.126 3 03.02.2006 09.12.2006 5.795 4 10.12.2006 31.12.2007 17.268 5 01.01.2008 31.12.2008 18.566


Abbildung 18: Veränderung der Parkgrenze. Visualisierung des Abfrageresultats 3 mit PL/SQL Developer.

- 28 -


Über welche Gemeinden erstreckt sich die aktuelle Parkgrenze?

GEMEINDE KANTON Hausen am Albis Zürich Hirzel Zürich Horgen Zürich Langnau am Albis Zürich Oberrieden Zürich Thalwil Zürich


In welchen Gemeinden wird die zukünftige Parkfläche zu liegen kommen?

GEMEINDE KANTONHausen am Albis Zürich Hirzel Zürich Horgen Zürich Langnau am Albis Zürich Menzingen Zug Neuheim Zug Schönenberg (ZH) Zürich


Wie gross ist der Anteil des Kantons Zug an der zukünftigen Parkfläche?

PARKGRENZE_ID PROZ_ANTEIL_KTZG_PARK QKM_ANTEIL_KTZG QKM_PARKFLAECHE5 13.29 2.47 18.57


Wo liegen die für Rollstuhlfahrer nicht zugänglichen Wege (Start und Ende)?

WEGNR BEZEICHNUNG ROLLSTUHLZUGANG X_KOORD Y_KOORD 2 Dachslöcher nein 684847 235699 2 Dachslöcher nein 684975 235791 6 Sihlflue-1 nein 684705 236445 6 Sihlflue-1 nein 684704 236198 7 Sihlflue-2 nein 684704 236198 7 Sihlflue-2 nein 684606 236200


Kann der Weg „heute“ begangen werden? bzw. Welche Wege sind offen?

WEGNR BEZEICHNUNG BETREIBSZUSTAND1 Bahnhofweg offen 2 Dachslöcher offen 3 Langmoos offen 4 Widenböden-1 offen 6 Sihlflue-1 offen 7 Sihlflue-2 offen


Wo kann das Alter eines Baumes bestimmt werden?

POSTENNR TITEL BETRIEBSZUSTAND X Y 3 Jahrringe zählen offen 684980 235795


- 29 -


Alle gesichteten Kohlmeisen der letzten drei Jahre

MELDUNG VOGELART ANZAHL DATUM X Y 1 Kohlmeise 6 10.02.2007 08:00 685020 236058 23 Kohlmeise 4 10.11.2005 17:00 685234 232432


Welche Vogelarten tauchen im Park als Schwärme (>10 Exemplare) auf?

ANZAHL VOGELART BEOBACHTUNGSTYP 11 Tannenmeise gesehen 23 Schwarzkopfmöwe gesehen


Kontaktdaten der Person, die am meisten Beobachtungen gemeldet hat?

NAME VORNAME ADRESSE PLZ ORT TELEFONNR ANZAHL_MELDUNGENSulzer Petra Sulgenstrasse 34 8000 Zürich 076 552 66 25 4


Dieses Resultat basiert auf eine Abfrage einer zuvor zusammengestellten ‚view’, die Informationen zu den Personen und den von ihnen gemachten Meldungen zusammenfasst.

Welche im Park festgestellten Vogelarten brüten hier?

BRUTVOEGEL MELDUNGNRKleiber 3Haubenmeise 2Tabelle 13: Resultat Abfrage 13.

Auch dieses Resultat wurde mittels Abfrage auf eine bestehende ‚view’ herbeigeführt. Ob die gemeldeten Vögel tatsächlich im Parkgebiet brüten, kann mit diesem Resultat nicht gänzlich beantwortet werden. Dazu bedingte es weiterer Attribute, die bei einer Meldung erfasst werden müssten.

Haben die Meldungen über Eulen in den letzten 3 Jahren abgenommen?

JAHR EULEN_MELDUNGEN2007 3 2006 1 2005 2 2004 1 Tabelle 14: Resultat Abfrage 14.

In welchem Gebiet werden gehäuft Greifvögel beobachtet?

MELDUNG X Y VOGELGRUPPE VOGELART 22 683671 235163 Greifvogel Uhu 17 684235 235623 Greifvogel Uhu 18 683856 235387 Greifvogel Zwergohreule 19 683642 236912 Greifvogel Bartkauz 21 683672 235173 Greifvogel Zwergohreule 8 682697 237123 Greifvogel Bartgeier

20 684562 234376 Greifvogel Uhu 16 684602 235748 Greifvogel Uhu


- 30 -


5.1 Kommentare Zur aktuellen Parkgrenze, der Parkgrenze im Jahr 2005 und den Parkgrenzen in den letzten 10 Jahren: Die Resultate machen soweit sinn, dass die Parkflächen der einzelnen Abfragen übereinstimmen. Dies gilt für die aktuelle Grenze (2007), als auch für die Grenze im Jahr 2005. Zur Überschneidung der Parkgrenze mit den umliegenden Gemeinden: Da es sich nur um Beispieldaten für eine Parkgrenze handelt, können die Überschneidungen nicht in der Realität überprüft werden. Die angegebenen Grenzen können aber stimmen. Es sind zumindest keine weit entfernten Gemeinden (wie z.B. Zürich) aufgelistet. Zum Anteil des Kantons Zug an der Parkfläche:. Die angegebenen Zahlen sind in Prozent und können daher Sinn machen. Es gibt aus der vorherigen Abfrage nur zwei Gemeinden aus dem Kanton Zug, die einen Flächenanteil an der Parkfläche haben. Die angegeben Prozentzahlen machen also Sinn. Zu den rollstuhlzugänglichen Wegabschnitten: Alle ausgegebenen Wegabschnitte sind für Rollstuhlfahrer zugänglich. Sihlflue-1 und Sihlflue-2 hängen zudem zusammen. Es sind also zwei durchgehende Abschnitte für Rollstuhlfahrer unzugänglich. Zur Bestimmung des Alters eines Baumes: Der Titel des ausgegebenen Postens lautet ‚Jahrringe zählen’. Das Ergebnis sollte also korrekt sein. Zu den gesichteten Kohlmeisen der letzten drei Jahre: Alle ausgegebenen Meldungen enthalten die Kohlmeise. Da nur relativ wenige Meldungen in der Testdatenbank aufgenommen wurden, macht es Sinn, dass es nur zwei Meldungen gibt. Zu den Vogelarten die in Schwärmen (# > 10) auftreten: Die Anzahl Vögel in den Meldungen sind alle grösser als 10. Somit macht das Ergebnis Sinn. Zu der fleissigsten Beobachterin: Die Anzahl Meldungen ist 4. Was in Relation zur totalen Anzahl Meldungen relativ gross ist. Zu den Brutvögeln: Die Abfrage beruht auf einer View, welche alle Brutvögel beinhaltet. Das Ergebnis macht also Sinn. Obwohl ein explizites Attribut „brütet_hier“ bestimmt aussagekräftiger wäre. Zu den Meldungen in den letzten 3 Jahren: Aus der Tabelle kann herausgelesen werden, ob die Meldungen zugenommen haben. Im Jahr 2007 wurden die meisten Vögel gemeldet. Zu den gemeldeten Greifvögeln: Alle gemeldeten Vögel sind Greifvögel. Das Ergebnis bestätigt sich durch manuelles Nachprüfen der Daten direkt in der Datenbanktabelle.

- 31 -


6. Erweiterungen und Diskussion Das vorliegende Kapitel zeigt die in diesem Prototypen implementierten Erweiterungen. Es werden die kommentierten SQL’s sowie deren Resultate dargestellt. Die darauf folgende Beurteilung und der Ausblick auf weitere mögliche Erweiterungen schliessen das Kapitel ab.

6.1 Implementierte Erweiterungen Zusätzlich zu den geforderten Abfragen und Implementierungsvorschriften (siehe Einleitung) sind folgende Punkte realisiert worden. 6.1.1 Informationstafeln Mit der vorliegenden Struktur ist es für die Parkverwaltung möglich, unabhängig von der Positionierung der Posten, allgemeine Informationstafeln an einem beliebigen Ort innerhalb der geltenden Parkgrenze zu platzieren. Dazu dient die Tabelle ‚Infotafel’, welche gekoppelt mit einem ‚Trigger’ garantiert, dass jede neu eingefügte Infotafel sich auch tatsächlich innerhalb der aktuell geltenden Parkgrenzen befindet. 6.1.2 Erlebnispfad – Tabelle Die Beziehungstabelle ‚Erlebnispfad’ ermöglicht die Zuordnung einzelner Wegstücke, Posten, Tafeln zu einem Erlebnispfad. Somit kann auf eine einfache und rationelle Weise eine Übersicht über die aktuelle Situation des Parks gewonnen werden. Weiter ist die Schaffung mehrer Erlebnispfade erlaubt. Es handelt sich dabei um eine strenge relationale Modellierung der Entitäten Infotafel, Wegabschnitt und Posten. aufgrund ihrer räumlichen Beziehungen wäre eine solche Tabelle nicht zwingend notwendig. Sie vereinfacht jedoch alle nicht-räumlichen Abfragen zu diesen Entitäten. Man kann schnell und einfach ausfindig machen, welcher Posten zu welchem Wegabschnitt und Erlebnispfad zugeordnet ist. Der Nachteil dieser Tabelle liegt in ihrer möglichen Inkonsistenz, denn die Zuordnungen könnten, mit der jetzigen Implementierung, auch willkürlich erfolgen. Es bedinge also auch hier einer Überprüfung durch das System, die in Form verschiedener Trigger realisierbar wäre.

PID PFADNR WEGNR TAFELNR POSTENNR

1 1 1 0 0 2 1 2 0 0 3 1 3 0 0 4 1 4 0 0 5 1 5 0 0 6 1 6 0 0 7 1 7 0 0 8 1 0 1 0 9 1 0 2 0

10 1 0 3 0 11 1 0 4 0 12 1 0 0 1 13 1 0 0 2 14 1 0 0 3 15 1 0 0 4

Tabelle 16: Ausschnitt Erlebnispfad - Tabelle mit Zuordnungen für Pfad, Posten, Weg und Infotafel.

- 32 -


6.1.3 Vogelgruppen – view’s Aufgrund der M:N – Beziehung zwischen den beiden Entitäten ‚Vogelart’ und ‚Vogelgruppe, ist für jede Vogelgruppe eine view, also eine zusammenfassende, virtuelle Tabelle generiert worden, was den Zugriff auf die verschiedenen Vogelgruppen und deren zugehörigen Vogelarten wesentlich vereinfacht.

create or replace view Eulen AS select vogelart.varid, vogelart.varname AS Eulen from var2vgr INNER JOIN vogelart ON vogelart.varid = var2vgr.varid INNER JOIN vogelgruppe ON vogelgruppe.vgrid = var2vgr.vgrid WHERE vogelgruppe.vgrname='Eule';

Listing 9: SQL für Eulen – view als Beispiel.

VARID EULEN 38 Bartkauz 22 Uhu 34 Zwergohreule

Tabelle 17: Resultat / Inhalt der Eulen - view.

6.1.4 Erweiterte Abfragen Im thematischen wie auch räumlichen Bezug sind weitere Abfragen implementiert worden, die eine etwas vertiefte Betrachtung des Modells erlauben. Dabei werden einerseits Fragen zu Vogelmeldungen, Anzahl gemeldeter Tiere und den betreffenden Personen beantwortet. Andererseits werden zusätzliche räumliche Aspekte beleuchtet. Es wurde z.B. für jede Vogelmeldung eruiert welche Posten sich in der Nähe befinden oder in welchen Gemeinden die Vogelmeldungen liegen. Weiter wurde auch die Länge des aktuell begehbaren Erlebnispfades berechnet. Die kommentieren SQL’s sind dem Anhang beigefügt worden (Abfragen 14 bis 21).

Welche Person aus der Parkverwaltung hat am meisten Meldungen erfasst?

NAME VORNAME FUNKTION ERFASSTE_VOGELMELDUNGEN Muster Hans Vogelexperte 14

Tabelle 18: Resultat Abfrage Nr. 14. Basierend auf view "meldung_erfasser".

Welche Vogelart wurde am häufigsten gesichtet?

VOGELART ANZAHL_MELDUNGENUhu 4

Tabelle 19: Resultat Abfrage 15. Basierend auf view "vogelart_anzahlmeldungen".

- 33 -


Wie viele Vögel einer Vogelart wurden bis jetzt gemeldet?

VOGELART VOEGEL_GEMOLDENBartgeier 1Wachtelkönig 1Feldsperling 2Wendehals 2Bartkauz 3Star 3Zwergohreule 3Haubenmeise 4Haubenlerche 5Sumpfeise 5Uhu 5Mehlschwalbe 6Trauerschnäpper 7Halsbandschnäpper 8Kleiber 8Kohlmeise 10Tannenmeise 11Schwarzkopfmöwe 23

Tabelle 20: Resultat Abfrage 16. Anzahl bisher gemeldeter Vögel pro Vogelart.

Wer hat wie viele Vögel gemeldet?

NAME VORNAME WOHNORT GEMOLDENE_VOEGEL Allemann Doria Horgen 5 Dardelle Konrad Baar 1 De Gaule Karl Genf 7 Ebner Martin Zürich 8 Ellenberger Katherine Baar 6 Flugstrasser Helge Basel 1 Hollenstein Karin Schaffhausen 10 Molger Kurt Horgen 4 Montesquieu Piere Frankreich 2 Quadrillian Pierro Zug 7 Schälibaum Elmar Zürich 23 Sulzer Petra Zürich 16 Sulzer Georg Winterthur 8 Wiiser Adrian Bern 9

Tabelle 21: Resultat Abfrage 17. Gemeldete Vögel pro Person.

Wer aus dem Parkpersonal hat auch schon Vogelbeobachtungen gemeldet?

NAME VORNAME FUNKTION VOEGEL_GEMOLDEN Ebner Martin Reinigungspersonal 8 Hollenstein Karin Verwaltung Posten und Infotafel 10 Dardelle Konrad Geschäftsleiter Park 1

Tabelle 22: Resultat Abfrage 18. Vogelmeldungen des Parkpersonals.

- 34 -


Welche Vogelarten wurden in einem Radius von 50m um welche Posten gesichtet?

MELDUNGNR VOGELART POSTEN_IN_NAEHE POSTENTITEL 14 Halsbandschnäpper 7 Lauschen, staunen und geniessen

1 Kohlmeise 6 Schau genau! 14 Halsbandschnäpper 4 Baumtelefon

1 Kohlmeise 1 Waldklänge Tabelle 23: Resultat Abfrage 19. Vogelmeldungen max. 50m von einem Posten entfernt.

In welchen Gemeinden wurden die bisherigen Beobachtungen gemacht?

GEMEINDEN_MIT_BEOBACHTUNGENHorgen Oberrieden Langnau am Albis

Tabelle 24: Resultat Abfrage 20. Gemeinden mit Vogelmeldungen.

Wie lange ist der momentan begehbare Erlebnispfad in km?

PFAD_OFFEN_KM1.659

Tabelle 25: Resultat Abfrage 21. Länge des aktuell begehbaren Erlebnispfads. 6.1.5 Sequenz für Schlüsselattribute Wie in Kapitel 2.4 (Physischer Entwurf) bereits ausgeführt worden ist, wurden am Beispiel der Tabelle „Vogelart“ eine Sequenz und ein dazugehöriger Trigger generiert. Somit entfällt die manuelle Eingabe des primären Schlüsselattributs, da dieser aufgrund der Sequenz bekannt ist und mittel Trigger automatisch zu jedem neuen Datensatz eingefügt wird.

6.2 Kurzbeurteilung der Datenbank Wie aus Kapitel 6 hervorgeht, wurden die zu Beginn gestellten Anforderungen von der implementieren Datenbank weitgehend erfüllt. Die Bereiche Datenkonsistenz und räumliche Topologie weisen aber noch Verbesserungspotential auf. So wurde die automatische Inkrementierung des Primärschlüssel lediglich beispielhaft für die Tabelle der Vogelarten realisiert. Weiter können in der Tabelle Erlebnispfad mögliche Inkonsistenzen auftreten. Mit der momentanen Implementierung, können Zuordnungen auch willkürlich erfolgen. Dieses Problem könnte mit dem Einsatz verschiedener Routinen und Trigger gelöst werden. Dies weil jeder Erlebnispfadeintrag definitionsgemäss lediglich eine Zuordnung haben darf und somit die Zuteilung eines Postens und eines Weges zwei Datensätze bedingt. Es gilt also: „Für jeden Eintrag zum gleichen Erlebnispfad muss also z.B. bei der Zuordnung eines Posten überprüft werden, ob nicht schon eine Wegzuordnung im selben Datensatz vorhanden ist. Um die Doppelspurigkeit zu vermeiden, hätte im diesem Fall die Zuordnung des Postens mittels eines weiteren Tabelleneintrags zu erfolgen.“ In der aktuell vorliegenden Version sind einige Attribute, wie Betriebszustand, Begehbarkeit, usw., die als eigentliche binäre Attribute modelliert wurden, nicht korrekt umgesetzt worden. Die Attributwerte für die Begehbarkeit eines Weges dürften nur 1 oder 0 (bzw. true / false) sein und keine Strings. Um Tippfehler und die damit verbunden Inkonsistenzen zu vermeiden, wäre dies einer der ersten Punkte, die an der Tabellenstruktur zu ändern wären.

- 35 -


6.3 Mögliche Erweiterungen – Ausblick Damit ein produktiver Einsatz einer Datenbank überhaupt denkbar ist und die angestrebte Produktivitätssteigerung auch erreicht werden kann, bedingt es einer graphischen Benutzerschnittstelle, die sowohl Abfragen, wie auch Aktualisierungen und Änderungen am Datenbestand benutzerfreundlich zulässt. Eine erste Variante könnte ein in HTML definiertes Interface sein, das serverseitig via PHP oder PERL auf den Datenbestand zugreifen kann. Das Einsatzgebiet einer solchen Applikation erstreckt sich von der Intranet- bis zur Internetanwendung mit öffentlichem Zugang. Etwas weiter vernetzt und eventuell auch mit einer bestehenden Verwaltungssoftware eines solchen Parks gekoppelt, kämme eine objektorientierte Applikation zum Zuge. Als mögliche Plattform kann hier JAVA erwähnt werden. Im Zusammenhang mit der Schaffung eines solchen Interfaces müssen unumgänglich auch Fragen im Bezug auf unterschiedliche Datenbanksichten und Zugriffsrechte geklärt werden. Dies erfordert aber eine bessere und vertiefte Auseinandersetzung mit den verschiedenen Anforderungen unterschiedlicher Benutzer des Systems. Die Tatsache, dass die Besucher des Parks Meldungen über Vogelvorkommnisse mit Koordinaten machen können, bedingt nahezu den Einsatz eines LBS7. Nur so kann auch tatsächlich sichergestellt werden, dass die Besucher ihre Vogelmeldungen der Parkverwaltung mitteilen. Ohne die Möglichkeit die Koordinaten direkt über ein GPS – Gerät erfassen zu können, werden nur sehr wenige Besucher ihre Beobachtungen melden, da der Aufwand und die Möglichkeit der Koordinatenerfassung im Feld erheblich eingeschränkt wird.

7 LBS, Abkürzung für Location Based Service. (dt.: standortbezogener Service)

- 36 -


7. Literatur und Quellen BRINKHOFF T. (2005): Geodatenbanksysteme in Theorie und Praxis, Herbert Wichmann

Verlag, Heidelberg, 2005. BURGHARDT D., MEILE R. (2007): Räumliche Datenbanken, Vorlesungsunterlagen,

Geographisches Institut, Universität Zürich, Herbstsemester 2007. Kannengiesser M. (2004): PHP5, Das Praxisbuch, Professional Series, Franzis Verlag GmbH, Poing, 2004. LAUSEN G. (2007): Datenbanken und Informationssysteme I, Vorlesungsunterlagen, Lehrstuhl

Datenbanken und Informationssysteme, Albert-Ludwigs Universität Freiburg, http://dbis. informatik.uni-freiburg.de/content/DBBuch/Folien/kapitel08.pdf, Zugriff: 29.11.2007.

OPENMAPSIHLWALD: Internetkarte – Sihlwald, http://www.openmapsihlwald.ch,

Zugriff: 16.11.2007. ORACLE (2005): Oracle Spatial®, User’s Guide and Reference, 10g Release 2 (10.2), 2005. STADT ZÜRICH: Grün Stadt Zürich, Der Sihlwald, http://www.stadt-zuerich.ch/internet/gsz/

home/naturraeume/sihlwald/sihlwald.html, Zugriff: 3.11.2007. VOGELWARTE SEMPACH: Vögel der Schweiz,

http://www.vogelwarte.ch/home.php?lang=d&cap=voegel, Zugriff 15.11.2007

WAHRIG (2002): Deutsches Wörterbuch, 7.Auflage, Wissen Media Verlag GmbH, München, 2002.

- 37 -


8. Anhang SQL – Skripte

ER – Modell

Logisches Modell

- 38 -

Drpeace

Cross-Out

GE

ME

IND

E

WE

GA

BS

CH

NIT

T

PA

RK

GR

EN

ZE

PO

STE

N

INFO

TAFE

L

VO

GE

LME

LDU

NG

VO

GE

LAR

T

VO

GE

LGR

UP

PE

PE

RS

ON

1

Weg

absc

hnitt

e, P

oste

n&

Info

tafe

lnin

Par

kgre

nze

o

m

m

Gru

ppen

arte

n

n

enth

ält

1

1

n

mel

den

1

n

erfa

ssen

Geo

met

rie (P

olyg

on)

Gem-Nr

von

(dat

e)

Gem

eind

enam

en

Geo

met

rie (P

olyg

on)

von

(dat

e)

Weg-Nr

Geo

met

rie (L

inie

)

Bes

chre

ibun

g

Info

rmat

ion

Bet

riebs

zust

and

Posten-Nr

Geo

met

rie (P

unkt

)

Bes

chre

ibun

g

Tite

l

Bet

riebs

zust

and

Tafel-Nr Tite

lTa

felte

xtZu

stan

dR

olls

tuhl

zuga

ng

ID

PersID

Nam

eA

dres

se

Vor

nam

e

PLZ

OR

T

Orts

nam

e

nw

ohnt

1

Funk

tion

PLZ

Nam

e

VGr-ID

Nam

e

VArt-ID

1in

nerh

alb

von

n

Meldung-Nr

VA

rt-ID

Geo

met

rie (P

unkt

)

Dat

um_Z

eit

Anz

ahl_

Tier

e

Mel

dend

e_P

erso

n(P

ersI

D)

Erfa

ssen

de_P

erso

n(V

WID

)

Beo

bach

tung

styp

Fehl

er_g

emol

den

VE

RW

ALT

ER

PR

IVA

TPE

RS

ON

d

Weg

-Nr

Tafe

l-Nr

n

„hat

“

1 nG

em-N

r

Par

kgre

nze

liegt

in C

H(g

leic

he rä

uml.

Ref

.)1

n

near

by

n

1

Geo

met

rie (P

unkt

)

defin

iere

nE

rlebn

ispf

ad

Pfad-Nr

bis

(dat

e)

GemGrenz-Nr

Kan

tons

-Nr

KA

NTO

N

Kantons-Nr

Kan

tons

nam

e

GE

ME

IND

EG

RE

NZ

„hat

“

1

n

Parkgrenz-Nr

bis

(dat

e)

VWID

pP

sten

-Nr

Tele

fonn

r1

GIS

- R

äum

liche

Dat

enba

nken

ER

-Mod

ell f

ür In

form

atio

nssy

stem

Sih

lwal

dS

emes

tera

rbei

t, H

S 2

007

J.S

nozz

i, G

.Mie

leG

rupp

e: P

ro_0

5S

amst

ag, 8

. Dez

embe

r 200

7

Gem

eind

e

PKGem-Nr

Gemeindename

Gem

eind

egre

nz

PKGemGrenz-Nr

FK2

Gem-Nr

FK1

Kantons-Nr

von

bis

Geometrie

Kan

ton

PKKantons-Nr

Kantonsname

Info

tafe

l

PKTafelnr

Titel

Tafeltext

Zustand

Geometrie

Weg

absc

hnitt

PKWeg-Nr

Bes

chre

ibun

gBetriebsustand

Info

rmat

ion

Rollstuhlzugang

Geometrie

Pos

ten

PKPosten-Nr

Titel

Bes

chre

ibun

gBetriebszustand

Geometrie

Erle

bnis

pfad

PKPfad-Nr

FK1

Pos

ten-

Nr

FK2

Weg

-Nr

FK3

Tafe

lnr

Per

son

PKPersID

Name

Vorname

Plz

Adresse

Telnr

Ver

wal

ter

PKVW

IDPK,FK1

PersID

Funktion

Vog

elar

t

PKVArt-nr

Name

Vog

elgr

uppe

PKVGr-nr

Name

VA

R2V

GR

PK,FK1

VArt-nr

PK,FK2

VGr-nr

Vog

elm

eldu

ng

PKMeldung-Nr

Anzahl_Tiere

Beobachtungstyp

Datum

_Zeit

Fehl

er_g

emol

den

FK1,

FK2

Per

sID

FK2

VW

IDFK

3V

Art-

nr

Trig

ger

Par

kgre

nze

PKParkgrenz-Nr

von

bis

Geometrie

Trig

ger

Trig

ger

Trig

ger

Trig

ger

Gle

iche

Ref

eren

z

GIS

- R

äum

liche

Dat

enba

nken

Logi

sche

s-M

odel

l für

Info

rmat

ions

syst

em S

ihlw

ald

Sem

este

rarb

eit,

HS

200

7

J.S

nozz

i, G

.Mie

leG

rupp

e: P

ro_0

5S

amst

ag, 8

. Dez

embe

r 200

7

Documents

Universität Zürich - Geographisches Institutgmiele/downloads/sihlwald_bericht_pro05_miele... · Als Ausgangsschema wird das Lebenszyklusmodell, aus der Vorlesung (Burghardt, Meile,