Quellen/Literaturverzeichnis
Werbung
Folie 1 Geo-Informationssysteme Datenbankkonzepte und Realisierungsansätze UH, FB Inf, M. Blaszkowski 1 Daten sind ein wesentlicher Bestandteil von Geo-Informationssystemen. Für die Verwaltung der Daten werden Datenbanken als Speichermedien eingesetzt. Im Folgenden werden die aktuellen DB-Technologien und ihre Anwendung in Geo-Informationssystemen erläutert. ________________________________________ Folie 2 Übersicht 1. Motivation - Warum Datenbanken? 2. Architekturaspekte von DBS 3. Das ER- und EER-Modell 4. Relationale Datenbanken 5. Objektrelationale Datenbanken 6. Nichtstandardanwendungen von Datenbanken UH, FB Inf, M. Blaszkowski ________________________________________ 2 Folie 3 Motivation - Warum Datenbanken? Zu Begriffsklärung: Datenbanksystem (DBS) = Datenbank (DB) + Datenbankverwaltungssystem (DBVS) Eine Datenbank ist eine Sammlung gespeicherter operationaler Daten die von den Anwendungssytemen benötigt werden. Ein DBVS ist ein standardisiertes Softwaresystem zur Definition, Verwaltung, Verarbeitung und Auswertung von DB-Daten. UH, FB Inf, M. Blaszkowski 3 Ein Datenbanksystem, ist die Kombination eines DBVS mit einer Datenbank. Ein DBVS ist die Gesamtheit der Software-Module, die die Verwaltung einer Datenbank übernehmen. Eine Datenbank ist also, ein von dem DBVS strukturierter und verwalteter Datenbestand. DBVS definieren ein Datenbankmodell, das alle Daten einheitlich beschreibt. Sie stellen Operationen und Sprachen (DDL, DML) zur Verfügung. Solche Sprachen sind deskriptiv und sind getrennt von einer Programmiersprache zu benutzen. Das DBVS unterstützt das Transaktionskonzept und Mehrbenutzerkontrolle entsprechend dem ACID-Paradigma. ________________________________________ Folie 4 Motivation - Warum Datenbanken? Dateisystem vs. Datenbanksystem DATEISYSTEM DATENBANKSYSTEM Datenredundanz u. Inkonsistenz Redundanzfreiheit u. Konsistenz durch zentrale Verwaltung der Daten (semantische) Integritätssicherung Mehrbenutzugriff (ACID) keine Integritätssicherung keine Mehrbenutzerzugriffe einfache Zugriffskontrolle komplexes Autorisierungsu. Überwachungssystem UH, FB Inf, M. Blaszkowski 4 Folie 5 Motivation - Warum Datenbanken? Dateisystem vs. Datenbanksystem (Forts.) DATEISYSTEM DATENBANKSYSTEM viele unterschiedliche Datenformate Datenunbahängigkeit (Daten vollständig strukturiert) keine anwendungsunabhängigen Abfragemöglichkeiten komplexe Abfragemöglichkeiten, einheitliche Schnittstellen (SQL, ODBC, JDBC) hoher Verwaltungsaufwand geringer Verwaltungsaufw. UH, FB Inf, M. Blaszkowski 5 Bei einem Dateisystem werden hinsichtlich einer redundanzfreien Datenhaltung, einem einheitlichen Datenmodell, einer Zugriffskontrolle und Konsistenzbedingungen keine allzu hohen bzw. überhaupt keine Anforderungen gestellt. Die Daten sind meistens eng an eine bestimmte Anwendung gekoppelt (Datenabhängigkeit). Durch den parallelen Datenbestand (die selben Daten in unterschiedlichen Datenformaten) ergeben sich Redundanzen und konsequenterweise Inkonsistenzen hervorgerufen durch nicht synchronisierte Änderungen an den Daten. Dateisysteme verfügen über keine mit SQL oder anderen Anfragesprachen vergleichbaren Abfragemöglichkeiten. Vorteilhaft ist der relativ geringe Verwaltungsaufwand gegenüber DBVS. Die oben erwähnten Anforderungen können alle von einem Datenbanksystem erfüllt werden. Datenbanksysteme können große Datenmengen effizient und einheitlich verwalten. Sie gewährleisten Datenunabhängigkeit und bieten ausdruckstarke Anfragesprachen. Viele Benutzer können parallel auf Datenbanken arbeiten. Das Transaktionskonzept garantiert, dass im Mehrbenutzerbetrieb keine Änderungsanomalien auftreten. Die Integritätssicherung gewährleistet die Korrektheit von Datenbankinhalten und der korrekten Ausführung von Änderungen, so dass diese die Konsistenz nicht verletzen können. Eine flexible Zugriffskontrolle sichert den Ausschluss unauthorisierter Zugriffe auf die gespeicherten Daten. ________________________________________ Folie 6 Architekturaspekte von DBS Zwei unterschiedliche Sichten auf ein DBS: • Benutzungssicht Drei-SchemaArchitektur nach ANSI-SPARC • Realisierugssicht 5-Schichtenmodell UH, FB Inf, M. Blaszkowski 6 Die ANSI-SPARC-Architektur ist eine Schnittstellenarchitektur. Sie beschreibt im wesentlichen Schnittstellen, die für unterschiedliche Benutzergruppen und Aufgaben konzipiert worden sind. Im Gegensatz dazu dient das 5Schichtenmodell zur Beschreibung und Erklärung der Realisierung von DBVS. ________________________________________ Folie 7 Architekturaspekte von DBS Drei-Schema-Architektur (Benutzungssicht) Externe Schemata Schema 1 ... Schema n Konzeptionelles Schema (logisches Datenmodell) Internes Schema UH, FB Inf, M. Blaszkowski 7 Die Schnittstellen in der Drei-Schema-Architektur bieten gewisse Sichten auf die Daten. Zentral ist dabei die gemeinschaftliche Datensicht, die auch als Konzeptionelles Schema bezeichnet wird. Sie entspricht in der Regel dem logischen Datenmodell eines bestimmten DBVS. Benutzerspezifische Sichten werden durch Externe Schemata festgelegt. Sie werden aus dem konzeptionellen Schema abgeleitet, um Anwendungsprogrammen für ihre Problemlösung angemessene Datenstrukturen bieten zu können. Die Isolation der Externen Schemata von dem Konzeptionellen Schema, macht es möglich die Daten in dem Konzeptionellen Schema unabhängig von den Anwendungsprogrammen zu verwalten. Zugleich erfüllen Externe Schemata Aufgaben, die einfache Nutzung (es sind nur die für den Benutzer spezifizierten Daten sichtbar) und Zugriffsschutz betreffen. Das Interne Schema beschreibt bestimmte Aspekte der physischen DB-Organisation. Es sollte ebenfalls möglichst stark von dem Konzeptionellen Schema isoliert sein, um Änderung in der physischen DB-Struktur (z. B. Setzen von physischen Zugriffspfaden) unabhängig vom Konzeptionellen Schema durchführen zu können. Alle Schemata sollten vollständig definiert sein, bevor mit ihnen und einem generischen DBVS ein konkretes DBS erzeugt wird. _______________________________________ Folie 8 Architekturaspekte von DBS 5-Schichtenmodell (Realisierungssicht) Mengenorientierte DB-Schnittstelle Logische Datenstrukturen Satzorientierte DB-Schnittstelle Logische Zugriffspfade Interne Satz-Schnittstelle Speicherungsstrukturen DB-PufferSchnittstelle Seitenzuordnugsstrukturen Dateischnittstelle Speicherzuordnugsstrukturen UH, FB Inf, M. Blaszkowski 8 Die 5-Schichten-Architektur beschreibt die in einem DBVS enthaltenen Komponenten (Schichten), die eine schrittweise Transformation von Anfragen und Änderungen von der abstrakten mengenorientierten Ebene bis hinunter zu Zugriffen auf den Speichermedien realisieren. Die Einteilung in Schichten dient vor allem der Reduktion der Komplexität und soll Systemeigenschaften wie Modularität, Anpassbarkeit, Erweiterbarkeit und Portabilität ermöglichen. Durch klar definierte Schnittstellen zwischen den Schichten wird ein hoher Grad an Datenunabhängigkeit erreicht. Die an einer Schnittstelle verfügbaren Objekte und Operationen werden von den direkt übergeordneten Komponenten wiederum zur Realisierung ihrer Strukturen und Funktionen benutzt. Die gewählte Anzahl von Schichten ist ein Kompromiss aus Forderung nach Datenunabhängigkeit und zugleich möglichst effizienter Ausführung von DB-Operationen. Als oberste Schicht der Abbildungshierarchie wird durch die Ebene der Logischen Datenstrukturen eine mengenorientierte DB-Schnittstelle (zugriffspfadunabhängiges Datenbankmodell) realisiert, die Zugriffsmöglichkeiten in deskriptiven Sprachen bietet. Ein wichtiges Beispiel für die mengenorientierte DBSchnittstelle bildet das Relationenmodell mit der Sprache SQL. Die Ebene der Logischen Zugriffspfade stellt eine satzorientierte DB-Schnittstelle zur Verfügung. Sie verbirgt die gewählten Implementierungskonzepte für Sätze und Zugriffspfade und erzielt damit eine Unabhängigkeit von den Speicherungsstrukturen. Die Logischen Zugriffspfade an sich kommen im relationalen Datenmodell nicht vor, sonder nur im Hierarchie- oder Netzwerkmodell und werden dort beim Definieren von so genannten Owner-Member-Beziehungen angelegt. Die nächste Systemschicht realisiert eine Menge von Speicherungsstrukturen wie interne Sätze und physische Zugriffspfade, die sie auf Seiten von Segmenten abbildet. Durch die verschiedenartigen Zugriffspfade und Speicherungsoptionen kann das Systemverhalten auf die Leistungsanforderungen einer konkreten Anwendung hin optimiert werden. Die Ebene der sog. Seitenzuordnungsstrukturen realisiert die DB-Pufferschnittstelle und stellt Segmente mit sichtbaren Seitengrenzen als lineare Adressräume im DB-Puffer zur Verfügung. Die Seiten werden in der Regel direkt auf Dateiblöcke abgebildet. Durch die Schicht, welche die Speicherzuordnungsstrukturen verkörpert, wird eine Dateischnittstelle erzeugt, auf der von Gerätecharakteristika wie Speichertyp, Zylinder- und Spuranzahl, usw. abstrahiert werden kann. ________________________________________ Folie 9 Das ER- und EER-Modell Das Entity-Relationship-Modell (ERM) ist eine Art formale Sprache für den DB-Entwurf . Modellierungskonzepte: • • • • Entity-Mengen (Objektmengen) Wertebereiche, Attribute Primärschlüssel Relationship-Mengen (Beziehungsmengen) UH, FB Inf, M. Blaszkowski 9 Der Entwurf eines (raumbezogenen) DBS kann aus dem Entity-Relationship-Modell resultieren. Er kann grafisch in einem Entity-Relationship-Diagramm visualisiert werden. Dabei sind Entitätsmengen und Relationsmengen zu definieren. Die Menge der Entitäten ist durch die vorgegebenen Attribute genau festgelegt. Eine Entität stellt ein Element dieser Menge dar und kann aus einem oder mehreren Attributwerten bestehen. Ein Primärschlüssel ist eine ausgewählte minimale Teilmenge von Attributen, die einer Entitätsmenge zugeordnet sind und die Entitäten dieser Menge eindeutig identifizieren. Eine Relation ist die Verbindung von zwei Entitäten. Relationship-Mengen vereinigen alle Relationen zwischen Entitäten aus zwei Entity-Mengen. Mathematisch lassen sich die Entitäten- und Relationenmengen mit den Hilfsmitteln der Mengenlehre angeben. ________________________________________ Folie 10 Das ER- und EER-Modell Beziehungstypen: • 1:1 • 1 : n, n : 1 • n:m Die Modellierungskonzepte des ERM sind häufig zu ungenau oder unvollständig. Sie müssen deshalb ergänzt werden durch Integritätsbedingungen. UH, FB Inf, M. Blaszkowski 10 1 : 1 bedeutet: Jede Entität aus Ei (Entitätsmenge) steht mit höchstens einer Entität aus E k in Beziehung. n : 1 bzw. 1 : n bedeutet: Jede Entität aus Ei bzw. Ek steht mit n >= 0 Entitäten aus Ek bzw. Ei in Beziehung. Leider wird, je nach Autor, die 1 : n bzw. n : 1 Beziehung unterschiedlich definiert. Was für den einen 1 : n ist, das ist für den anderen n : 1. Die hier angegebene Definition hat den Vorteil, dass sie zu der min-max-Notation (siehe EER-Modell: Kardinalitätsrestriktionen) kompatibel ist, jedoch nicht so anschaulich ist. n : m bedeutet: Jede Entität aus Ei steht mit n >= 0 Entitäten aus Ek in Beziehung und umgekehrt gilt auch, dass jede Entität aus Ek mit n >= 0 Entitäten aus Ei in Beziehung steht. Der Beziehungstyp entspricht also einer mathematischen Relation. ________________________________________ Folie 11 Das ER- und EER-Modell Beispiel: PID Name Parzelle Rand n GID m steht auf Fläche Adresse Gebäude n D.-Höhe 1 L.-B. L.-E. Darlehen finanziert von UH, FB Inf, M. Blaszkowski 11 Die Rechtecke stellen Entitätsmengen u. die Rauten Beziehungsmengen dar. Durch Ovale werden Attribute gekennzeichnet. Unterstrichene Attributnamen kennzeichnen Primärschlüssel. Entsprechend der Def. auf Folie 10 bedeutet die n : 1 Beziehung, dass ein Gebäude von n >= 0 Darlehen finanziert wird. ________________________________________ Folie 12 Das ER- und EER-Modell Erweiterungen des ERM: • • • • Kardinalitätsrestriktionen Generalisierung/Spezialisierung (disjunkt, überlappend) Aggregation Assoziation UH, FB Inf, M. Blaszkowski 12 Das erweiterte ER-Modell erlaubt vor allem eine genauere Modellierung von Beziehungen. So wird durch Kardinalitätsrestriktionen die Semantik der Beziehungstypen verfeinert. Sind z. B. die Beziehungen zwischen Entitäten aus E1 und E2 durch die Relationship-Menge R gegeben, so bedeutet die Restriktion [min1, max1] bzw. [min2, max2], dass eine Entität aus E1 bzw. E2 an wenigstens min1 bzw. min2 u. höchstens max1 bzw. max2 Beziehungen vom Typ R teilnimmt. Generalisierung/Spezialisierung, Aggregation und Assoziation stellen Abstraktionskonzepte dar, mit denen es möglich ist noch mehr Semantik aus der ausgewählten Miniwelt (Diskursbereich) zu erfassen. Dabei entspricht die Generalisierung/Spezialisierung ungefähr dem Vererbungskonzept aus den objektorientierten Programmiersprachen. Im Datenbankbereich ist es jedoch adäquater von Teilmengenbeziehungen zu sprechen, die sowohl disjunkt, als auch überlappend sein können. Die Aggregation ist mit einer Teil-Ganze-Beziehung vergleichbar und impliziert damit zusammengesetzte Objekte, auch Aggregate genannt. Ziel der Assoziation ist die Zusammenfassung von Gruppen mit heterogenen Objekten für einen bestimmten Kontext, z. B. Sichtkonzept. Sie ist vergleichbar mit Mengenbildung, bei der die Objekte das Mengenprädikat erfüllen müssen, um in der Menge enthalten zu sein. Dabei werden einerseits Details der einzelnen Elemente unterdrückt und andererseits bestimmte Eigenschaften, die die Menge (Objektgruppe) charakterisieren, hervorgehoben. ________________________________________ Folie 13 Das ER- und EER-Modell Beispiel: PID Name Parzelle Rand n GID m Fläche Adresse Gebäude n steht auf D.-Höhe 1 L.-B. L.-E. Darlehen finanziert von t Gebäude privat Gebäude Industrie Gebäude Landwirtschaft UH, FB Inf, M. Blaszkowski 13 Das Dreieck symbolisiert eine Teilmengenbeziehung. Das t steht für total und bedeutet, dass die Vereinigung der Mengen G. privat, Industrie u. Landwirtschaft gleich der Menge Gebäude ist. Die Attribute der Menge Gebäude werden natürlich von den Teilmengen vererbt. Da die Pfeile in Richtung des Dreiecks zeigen, dürfen sich die Teilmengen überlappen. ________________________________________ Folie 14 Relationale Datenbanken Eigenschaften des relationalen Datenmodels: • Relation (Tabelle) als einzige Datenstruktur (neben atomaren Werten) • Informationsdarstellung ausschließlich durch Werte • Jede Zeile (Tupel) ist eindeutig und beschreibt ein Objekt • Die Ordnung der Zeilen und Spalten ist ohne Bedeutung • Es existieren ein Primärschlüssel und ggf. weitere Schlüsselkandidaten UH, FB Inf, M. Blaszkowski 14 Das relationale Datenmodell ist ein auf Tabellen basierendes Konzept. Neben den atomaren Werten sind sie die einzige Datenstruktur. Die Informationsdarstellung in den Tabellen erfolgt ausschließlich durch Werte. Dies gilt auch für Beziehungen. Die Zeilen solcher Tabellen können als Tupel aufgefasst werden, die eindeutig ein Objekt beschreiben. Entsprechend der mathematischen Modellierung einer Tabelle durch eine Relation spielt die Ordnung der Zeilen und Spalten keine Rolle. Der Primärschlüssel (PS) hat hier die selbe Bedeutung, wie beim ERM, wobei die Attribute des PS als Spalten aufzufassen sind. Abstraktionskonzepte finden im relationalen Datenmodell keine Unterstützung und lassen sich auch kaum nachbilden. ________________________________________ Folie 15 Relationale Datenbanken Operatoren auf Relationen: • Vereinigung, Differenz • Kartesisches Produkt • Projektion • Selektion • zusätzlich: Grundoperationen (Einfügen, Löschen, Ändern) Standardanfragesprache SQL2 (1992): • deskriptiv; leicht zu erlernen; relational vollständig • Grundbaustein: SFW-Block UH, FB Inf, M. Blaszkowski 15 Das relationalen Datenmodell hat den Vorteil, dass es auf Basis der relationalen Algebra mathematisch klar dargestellt werden kann. Standardmäßig umfasst die Relationenalgebra die Operatoren Vereinigung, Differenz, Kartesisches Produkt, Projektion (wählt bestimmte Spalten einer Relation im Sinne von Tabelle aus) und Selektion (wählt Tupel aus einer Relation aus, die die Selektionsbedingung erfüllen). Diese reichen bereits aus, um relationale Vollständigkeit zu garantieren. Die zusätzlichen Grundoperationen (Einfügen, Löschen, Ändern, etc.) ergeben sich durch Implementierung des Relationalen Datenmodells auf einem Rechner. Alle Operationen zusammen werden in der Regel in Form einer Anfragesprache dem Anwender des DBS zur Verfügung gestellt. Zu den am weitesten verbreiteten Anfragesprachen gehört mit Abstand die Standardanfragesprache SQL2. Sie zeichnet sich u. a. durch relationale Vollständigkeit, deskriptive Anfrageformulierung und leichte Erlernbarkeit aus. Typisch für SQL ist der sogenannte SFW-Block. Dieser besteht nämlich aus einer SELECT-Anweisung (Projektion), einer FROM-Anweisung (kartesisches Produkt) und einer WHERE-Anweisung (Selektion). ________________________________________ Folie 16 Relationale Datenbanken Beziehungen: • sind binär und symmetrisch • werden durch Werte dargestellt: Primär-/Fremdschlüssel (Gewährleistung von referentieller Integrität) • können in SQL automatisch gewartet werden (referentielle Aktionen) Entwurfstheorie: • Normalformenlehre (1NF, 2NF, 3NF, BCNF, 4NF) UH, FB Inf, M. Blaszkowski 16 Beziehungen werden durch Fremdschlüssel (Attribut oder eine Attributkombination) und zugehörige Primärschlüssel oder Schlüsselkandidaten dargestellt. Der FS und der zugehörige PS (SK) sind auf dem gleichen Wertebereich definiert. Die referentielle Integrität garantiert, dass zu jedem Wert des FS ein gleicher Wert des PS immer vorhanden ist. Fremdschlüssel können jedoch auch Nullwerte aufweisen, wenn nicht explizit NOT NULL spezifiziert ist. Diese Art und Weise wie Beziehungen im relationalen Datenmodell realisiert werden, hat zur Folge, dass in Prinzip alle Beziehungstypen durch (n : 1 bzw. 1 : n) – Beziehungen dargestellt werden müssen. Dies erreicht man hauptsächlich dadurch, dass weitere Relationen eingeführt werden, womit sowohl (n : m) – Beziehungen, als auch beliebige k-näre Beziehungen, sich durch (n : 1) – Beziehungen darstellen lassen. Die vorhandene Symmetrie (keine Zeigerstrukturen) in den Beziehungen, vereinfacht die Anfrageoptimierung. Die Normalformenlehre, als Entwurfstheorie für relationale Datenbanken, liefert Methoden für den Entwurf von möglichst redundanzfreien DB-Schemata, um vor allem die damit verbundenen Änderungsanomalien zu vermeiden. Die Normalisierungsschritte lassen sich vollständig formalisieren, sodass, bei Angabe von funktionalen Abhängigkeiten (zwischen Mengen von Attributen), die Normalisierung vorhandener DB-Schemata unter Einsatz von entsprechenden Werkzeugen am Rechner durchgeführt werden kann. ________________________________________ Folie 17 Relationale Datenbanken Beispiel: UH, FB Inf, M. Blaszkowski 17 Das Beispiel demonstriert die Anwendung des relationalen Datenmodells zur Verwaltung eines zusammenhängenden räumlichen Objekts bestehend aus den beiden Flächen 125 und 126. Durch (FS : PS)Beziehungen zwischen der Flächen-, Kanten- und Knotentabelle wird vor allem die Topologie des Objekts vollständig erfasst. ________________________________________ Folie 18 Objektrelationale Datenbanken Objektrelationale DBS erweitern die RDBS um OO-Konzepte: • • • • • • • • ADTs/Kapselung Klassen/Vererbung mengenwertige Attribute OIDs/Referenzen benutzerdefinierte Funktionen prozedurale Verarbeitung Multimedia-Integration Offenheit UH, FB Inf, M. Blaszkowski 18 Objektrelationale DBS erweitern die RDBS um objektorientierte Konzepte und machen es damit möglich nahezu die gesamte Anwendungslogik in die Datenbank zu integrieren. Die Vorteile liegen auf der Hand: der Programmentwurf wird einheitlicher und konsistenter, die direkte Unterstützung von Abstraktionskonzepten (ADTs, Vererbung) durch das DBS macht den DB-Entwurf natürlicher, die Anfragemächtigkeit wird erhöht (Nachteil: Terminierungsproblem, Fehleranfälligkeit). ________________________________________ Folie 19 Objektrelationale Datenbanken Merkmale von objektrelationalen DBS: 19 UH, FB Inf, M. Blaszkowski Die Tabelle gibt eine Übersicht über die typischen Merkmale von objektrelationalen Datenbanken. Zu sehen sind auch Kriterien, die die objektrelationalen DBS nicht erfüllen und sich deshalb von rein objektorientierten DBS unterscheiden. Dies gilt vor allem für den Operationenteil. D. h., trotz vieler objektorientierter Konzepte im Datenbankmodell sind die Anfrageergebnisse relational, entsprechen also Tabellen oder verallgemeinerten geschachtelten Tabellen. ________________________________________ Folie 20 Objektrelationale Datenbanken Erweiterungen nach ISO-Standard SQL: 1999/2003 • Unterstützung von benutzerdefinierten Typen (UDT) mit komplexen Datenstrukturen, komplexer Funktionalität und Vererbungshierarchie • Erhöhung der Anfragemächtigkeit durch Allgemeine Tabellenausdrücke/Rekursion • Erweiterung von Tabellen (Schachtelung, Referenzierung, Tabellen mit Typbildung und Tabellenhierarchien) UH, FB Inf, M. Blaszkowski 20 SQL-99 umfasst die Standardisierungsbemühungen für die Erweiterung des relationalen Modells um objektorientierte Konzepte. Der Standard basiert auf dem SQL3-Standard, deckt jedoch nicht alle Inhalte, wie z. B. dynamische Datenstrukturen (Listen, Mengen, etc.), aus SQL3 ab. Im Vergleich zu SQL92 ist SQL99 um ein Vielfaches umfangreicher und besteht deshalb aus mehreren Teilen (SQL/Foundation, SQL/Object, SQL/MM, ...). Von zentraler Bedeutung in SQL99 sind die benutzerdefinierten Typen (UDT). Sie erhöhen die Modellierungsmächtigkeit von SQL, da sie die Menge der verfügbaren Typen u. Operationen beliebig erweitern. UDTs erlauben die Anwendung objektorientierter Konzepte, wie Vererbung oder Kapselung, und vereinfachen damit die Anwendungsentwicklung. Allgemeine Tabellenausdrücke definieren eine oder mehrere Sichten (WITH-Sichten) für die Verarbeitung der SQL-Anweisung. WITH-Sichten sind nur im Kontext einer SQL-Anweisung definiert, erlauben jedoch mehrfache Referenz, ohne eine Sicht materialisieren zu müssen. Ein allgemeiner Tabellenausdruck ist rekursiv, falls er in seiner Definition auf sich selbst Bezug nimmt (Schlüsselwörter: WITH RECURSIVE und UNION ALL). Rekursion erlaubt zwar mächtige Anfragen in SQL-99, macht die Sprache aber insgesamt unsicher, da innerhalb der Rekursion u. a. Funktionen oder Aggregatfunktionen erlaubt sind, die (wenn unsauber programmiert) die Anfragenergebnisse unbeschränkt wachsen lassen können. Unabhängig von den UDTs wurde natürlich das Tabellenkonzept aus SQL-92 beibehalten und sogar um sogenannte konstruierte Typen erweitert. Diese erlauben vor allem die Schachtelung von Zeilen und Anwendung von Kollektionstypen (in SQL-99 nur ARRAY, keine dynamischen Datenstrukturen). Tabellen sind auch in SQL-99 das Basiskonstrukt und sind notwendig, um die UDTs überhaupt verwenden zu können. Die UDTs können also nur im Zusammenhang mit Tabellen verwendet werden, was zu sogenannten getypten Tabellen und, analog zu den Typhierarchien der UDTs, zu Tabellenhierarchien führt. ________________________________________ Folie 21 Objektrelationale Datenbanken Datentypen und Operationen (SQL 99): UH, FB Inf, M. Blaszkowski 21 Die Grafik zeigt die in SQL-99 vorhandenen Datentypen und die entsprechenden Operationen. Während in SQL92 nur die vordefinierten Datentypen (string, numeric, boolean, ...) verfügbar sind, gibt es in SQL-99 auch konstruierte Typen (Schachtelung von Zeilen, Kollektionstypen) und benutzerdefinierte Typen (UDTs). Die UDTs bestehen aus umbenannten Typen (distinct type) und strukturierten Typen, wobei nur die strukturierten Typen über Objekteigenschaften verfügen (Kapselung, Wiederverwendung von Code, Überladen und Überschreiben). In den Tabellen können die strukturierten Typen sowohl als Spaltentyp, als auch als Zeilentyp benutzt werden. Benutzt man die strukturierten Typen als Zeilentypen, so lassen sich, aufbauend auf deren Typhierarchien, Tabellenhierarchien erstellen. Natürlich erlauben die strukturierten Typen spezifische Operationen (UDR) zu definieren, die entsprechend dem ADT-Konzept benutzt werden können. Die Einteilung in Funktionen, Prozeduren und Methoden ergibt sich aus den Beschränkungen in Hinblick auf das Überladen und Überschreiben von Operationen. ________________________________________ Folie 22 Objektrelationale Datenbanken Beispiel (Verwaltung von Flurstücken): CREATE TYPE Polygon AS ( Nummer INTEGER, Rand LIST (Punkt), Löcher SET (LIST (Punkt))) INSTANTIABLE NOT FINAL; METHOD Umfang () RETURNS DECIMAL, METHOD FLäche () RETURNS DECIMAL, METHOD Enthält (Punkt) RETURNS BOOLEAN, ... CREATE TABLE Flurstücke ( Nummer INTEGER PRIMARY KEY, Geometrie Polygon, Eigentümer CHAR (50)); UH, FB Inf, M. Blaszkowski 22 Zur Verwaltung von Flurstücken wird hier ein UDT Polygon definiert. Dieser soll sich zusammensetzen aus einer Variable vom Typ INTEGER, einer Liste von Punkten (Punkt ist ebenfalls ein UDT, der bereits definiert wurde) zur Definition des Randes und einer Menge (evtl. leeren) von Punktlisten, die mögliche Löcher beschreiben sollen. Die Schnittstelle nach außen definieren mehrere Methoden. Mit diesen soll unter anderem möglich sein den Umfang und die Fläche des Polygons zu bestimmen. Anschließend wird der UDT Polygon in der Tabelle Flurstücke als Spaltentyp verwendet. ________________________________________ Folie 23 Nichtstandardanwendungen von Datenbanken SA Bankwesen Lohnwesen Produktion NSA CAD GIS Elektronik Einige Unterschiede zwischen SA und NSA: Standardanwendungen Einfachschlüssel exakter Match Nichtstandardanwendungen Mehrfachschlüssel unsicherer Match einige logische Verknüpfungen vielfache logische Verknüpfungen leichte Operatoren komplexe Operatoren UH, FB Inf, M. Blaszkowski 23 Standardanwendungen (SA) von Datenbanken kommen z. B. im Lohn- und Bankwesen oder Materialbestellung vor. Dagegen gelten als Nichtstandardanwendungen (NSA) die Bereiche des CAD und der GeoInformationssysteme, also vor allem die Bereiche, die mit raumbezogenen Daten umgehen müssen. NSA sind wesentlich komplexer als SA, was sich z. B. im Vorhandensein von Mehrfachschlüssel in NSA bemerkbar macht. In SA kommen meistens einfache Schlüssel, wie z. B. Kundennummer, vor, während in raumbezogenen Systemen sich der Schlüssel über mindesten zwei Größen, z. B. x- und y-Koordinate erstreckt. Eine Anfrage in SA beruht auf einem exakten Match, dagegen kann eine Anfrage in GIS im Allgemeinen nicht direkt in einer SQL-Anweisung formuliert werden. Vielmehr müsste ein GIS in der Regel mehrere SQLAnfragen auswerten, um daraufaufbauend ein korrektes Ergebnis liefern zu können. Da die Objekte in raumbezogenen Systemen relativ komplex sind (ein Polygon besteht aus Linien, eine Linie aus Punkten, ...), werden die Objekte durch Normalisierung des DB-Entwurfs auf viele Tabellen aufgesplittet. Dies führt dann zwangsläufig zu vielen logischen Verknüpfungen und komplexen Operatoren bei Anfragen. ________________________________________ Folie 24 Nichtstandardanwendungen von Datenbanken Allgemeiner Aufbau eines raumbezogenen Datenbanksystems Datenbankmanagementsystem (DBMS) Datenbank (DB) Objektdefinition Geometrie Topologie Graph. Beschreibung Sachdaten UH, FB Inf, M. Blaszkowski 24 Folie 25 Nichtstandardanwendungen von Datenbanken Architekturen: Non-StandardAnwendung Non-StandardAnwendung anwendungsabhängige Zusatzebene ORDBS Non-StandardAnwendung Geometrie Sachdaten zugeschnittenes DBS UH, FB Inf, M. Blaszkowski Relationales DBS Anwendungsspezifisch 25 Der allgemeine Aufbau von raumbezogenen Datenbanken orientiert sich natürlich an den klassischen DBS in der Informatik. Es gibt also ebenfalls ein Datenbankmanagmentsystem (DBMS) welches in Kombination mit der Datenbank, also den Daten an sich, das Datenbanksystem ergibt. Da die Funktionalität der klassischen DBMS nicht ausreicht, um die komplexen Daten, die in einer raumbezogenen Datenbank anfallen, zu verwalten, muss das klassische DBMS, um entsprechende Funktionalität erweitert werden. Mit der zur Zeit verfügbaren DB- Technologie sind für die Realisierung einer raumbezogene Datenbank prinzipiell drei unterschiedliche Architekturen denkbar. Alle drei haben ihre Vor- und Nachteile. Die Realisierung eines zugeschnittenen DBS ist vergleichbar mit einer Neuentwicklung des DBMS. Dementsprechend ist diese Lösung sehr aufwendig, hat aber den Vorteil sehr effizient zu sein. Eine andere Möglichkeit besteht darin ein vorhandenes relationales DBS um eine Zusatzebene zur erweitern, die die von der Anwendung benötigten zusätzlichen Funktionalitäten (wie z. B. Verwaltung raumbezogener Datentypen) zur Verfügung stellt. Dieser Ansatz hat den Vorteil, dass relationale Datenbanken sehr verbreitet sind und sich damit die NSA mit relativ wenig Aufwand in eine vorhandene Systemumgebung integrieren lässt. Das ist auch die Architektur, die zur Zeit im GIS-Bereich üblich ist. Als letzte Lösung, die softwaretechnisch vieleicht die sauberste ist, kann eine objektrelationale Datenbank verwendet werden. Hierdurch kann nahezu die gesamte Anwendungslogik in das DBS verlagert werden, was den Code insgesamt konsistenter macht. Ebenso müssen die räumlichen Anfragesprachen nicht erst aufwendig neuentwickelt werden, sondern können direkt auf SQL 99 aufbauen. Leider haben sich bis jetzt die objektrelationalen Datenbanken bei der Ausführung größerer Mengen an Code als nicht besonders effizient erwiesen, sodass hier sicherlich noch einiges an Entwicklungsarbeit zu leisten ist. ________________________________________ Folie 26 Nichtstandardanwendungen von Datenbanken Schalenmodell der raumbezogenen Datenhaltung Räumliches Modell Konzeptionelles Modell Logisches Modell Externes Schema Physikalisches Modell UH, FB Inf, M. Blaszkowski 26 Das Schalenmodell zeigt den Aufbau eines raumbezogenen Anwendungssystems aus daten-logischer Sicht. Dabei gehört die Bereitstellung und Verwaltung der beiden inneren Schalen (logisches und physikalisches Datenmodell) zu den klassischen Aufgaben von Datenbanksystemen. Das logische Datenmodell beinhaltet die Festlegung von Datenbankschemata zur Aufnahme der gegebenen Datenstrukturen. Die Art der Datenspeicherung auf der Festplatte sowie der dazugehörige Zugriffsmechanismus wird im physikalischen Datenmodell festgelegt. In das konzeptionelle Datenmodell ist vor allem das geometrische Modellieren (z. B. Kanten-, Flächen- und Volumenmodelle) eines Objektes einzuordnen, das von dem Anwender in dem räumlichen Datenmodell, hinsichtlich seiner thematischen Ausdehnung und Abgrenzung, festgelegt wird. Vergleicht man das Schalenmodell mit der Drei-Schema-Architektur (siehe Folie 7), so würden die beiden äußeren Schalen (das räumliche und das konzeptionelle Datenmodell) dem externen Schema in der DreiSchema-Architektur entsprechen. Verwendet man also zur Realisierung eines raumbezogenen Anwendungssystems ein DBS, welches die Vorgabe der Drei-Schema-Architektur in konsequenter Weise umsetzt, so sollte es in diesem möglich sein die Daten in den beiden inneren Schalen unabhängig von den beiden äußeren Schalen zu verwalten. Diese Daten könnten dann also auch anderen Anwendungsprogrammen zur Verfügung gestellt werden. So könnten z. B. die Daten eines GIS mit relativ wenig Aufwand in ein sogenanntes Datawarehouse (unter dem Begriff ist in Prinzip nur eine Menge von Daten zu verstehen, die aus mehreren unterschiedlichen Quellen extrahiert worden sind) integriert werden, um Tools bei der Analyse von Daten zu unterstützen. ________________________________________ Folie 27 Nichtstandardanwendungen von Datenbanken Punktanfrage 125 126 127 Bereichsanfrage Gegeben sei ein bestimmter Punkt mit seinen Koordinaten; innerhalb welchem Objekt liegt dieser Punkt? Gegeben sei ein bestimmter Bereich - welche Objekte schneiden diesen Bereich? UH, FB Inf, M. Blaszkowski 27 Es wird angenommen, dass ein Grafiksystem Auskunft über die aktuelle Position des Cursors ausgibt und das Flurstück nach einem Knoten-Kanten-Modell in einer relationalen Datenbank gespeichert ist. Wird nun der Cursor an eine beliebige Stelle im Flurstück positioniert, so muss eine Abfrage gestellt werden, die aus dem Datenbestand der Datenbank selbst nicht beantwortet werden kann, sondern erst durch eine Nachbereitung der von der Datenbank erhaltenen Kandidaten. Man erhält nämlich als Ergebnis mindestens vier Parzellen, da in der Datenbank nur Positionen der Eckpunkte gespeichert sind. Mit diesen Daten können jedoch vollständige geometrische Modelle der Parzellen bestimmt werden, mit denen sich anschließend beide Anfragen beantworten ließen. Die Anfrage nach den Objekten, die einen bestimmten Bereich schneiden ist übrigens ein typisches Beispiel für das Anzeigen raumbezogener Daten in einem Fenster am Bildschirm. Sie könnte also durch Anwendung eines Clipping-Algorithmus (z. B. des Liang-Barsky-Algorithmus) auf die geometrischen Modelle der Objekte beantwortet werden. ________________________________________ Folie 28 Nichtstandardanwendungen von Datenbanken Bestandsflächen eines Forsteinrichtungssystems: Aufgabe: Holzvorrat innerhalb eines beliebigen frei definierbaren Polygons ermitteln. UH, FB Inf, M. Blaszkowski 28 Die Frage nach dem Holzvorrat in einzelnen Flächen oder auch zum Beispiel nach dem gesamten Holzvorrat in den Flächen 3 und 4 ist mittels Standard-SQL leicht zu formulieren (SELECT SUM (HOLZVORRAT) FROM WALD WHERE BEST-ID = 3 OR BEST-ID = 4;). Soll jedoch der Holzvorrat innerhalb eines frei definierbaren Polygons (Abfragepolynoms) ermittelt werden, so bietet Standard-SQL keine direkte Möglichkeit, dies zu ermitteln. Es ist nämlich sowohl eine Verschneidung, als auch eine Interpolation notwendig. D. h., die Anfrage kann ebenfalls nur durch Verwendung der geometrischen Modelle der jeweiligen Objekte beantwortet werden. Dabei kann man natürlich annehmen, dass die einzelnen Bestandsflächen einen gleichmäßigen Bewuchs aufweisen. ________________________________________ Folie 29 Nichtstandardanwendungen von Datenbanken SQL/MM Spatial: • Definiert raumbezogene Datentypen und Funktionen • Basiert auf SQL99 UH, FB Inf, M. Blaszkowski 29 Der Standard SQL/MM Spatial soll eine einheitliche Schnittstelle bieten, um raumbezogene Daten in einer Datenbank speichern und verarbeiten zu können. Der Standard basiert auf SQL99 (SQL/MM ist der Oberbegriff für einige Erweiterungen des SQL-Standards) und nutzt dessen Objektorientierung. Es existieren zwar bereits einige Produkte welche ähnliche Funktionalität bieten, jedoch basieren diese meistens auf firmenspezifischen Funktionen und Objekten. Beispiele für solche Herstellerspezifischen Erweiterungen sind: Spatial Database Engine (SDE) von ESRI, Datablade von Informix und Spatial Database Option (SDO) von Oracle. ________________________________________ Quellen/Literaturverzeichnis Bill, Ralf: Grundlagen der Geo-Informationssysteme: Band 1. Hardware, Software und Daten. 4. Auflage, 1999 Heuer, A., Saake, G.: Datenbanken: Konzepte und Sprachen, 2. Auflage, 2000 Härder, T., Rahm, E.: Datenbanksysteme - Konzepte und Techniken der Implementierung, Springer-Verlag, Berlin, 2001 Anderegg, F.: Raumbezogene Datentypen in SQL/MM Spatial und verwandten Standards, Hochschule für Technik Rapperswil, 2002 Ritter, N.: Vorlesungsunterlagen Datenbanken und Informationssysteme (SS 2003 und SS 2004) www.esri.com
