Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Datenbankmodelle für die Realisierung von Anwendungen Hauptseminar Nichtrelationale Datenbanken Master of Ceremony: Christian Daum.

Ähnliche Präsentationen


Präsentation zum Thema: "Datenbankmodelle für die Realisierung von Anwendungen Hauptseminar Nichtrelationale Datenbanken Master of Ceremony: Christian Daum."—  Präsentation transkript:

1 Datenbankmodelle für die Realisierung von Anwendungen Hauptseminar Nichtrelationale Datenbanken Master of Ceremony: Christian Daum

2 Grundlagen Datenbankmodell Datenbankmodell : oEin System von Konzepten zur Beschreibung von Datenbanken oEs liefert zudem die Grundlage für Syntax & Semantik eines Datenbankschemas (& damit auch einer Datenbankprogrammiersprache). oNach Edgar F. Codd definiert sich ein Datenbankmodell aus 3 Eigenschaften: >Einer Sammlung von Datenstrukturen >Einer Menge von Operatoren, die auf jede der Datenstrukturen angewandt werden kann, um Daten abzufragen oder abzuleiten. >Einer Menge von Integritätsregeln, die Veränderungen der Daten festlegen. Datenbankschema oFormales Modell für die Struktur von Daten: Beschreibt den Aufbau einer konkreten Datenbank auf Basis des Datenbankmodells: 3 >Aufbau der Daten, Basisdatentypen, zulässige Operationen auf Daten, Beziehungen, Konsistenz-/Integritätsbedingungen etc. oDas Datenbankschema ist in einer formalen Sprache definiert – einer Datenbankprogrammiersprache (DBPL = Database Programming Language); Beispiele: >XML-Datenbanken -> Schema durch DTD (Document Type Definition) definiert >SQL-Datenbanken -> Schema durch DDL (Data Definition Language) definiert

3 Übersicht Datenbankmodelle Relationenmodell oDerzeit das am weitesten verbreitete Modell Netzwerkmodell & hierarchisches Modell oEher historische aber nichtsdestotrotz nach wie vor im Einsatz befindliche Modelle Erweiterte relationale & semantische Modelle oNeuere Modelle wie NF 2 etc. Objektorientierte (ODMG) & objektrelationale (SQL-3/SQL-99) Modelle oDie beiden aktuellen Trends im DB-Bereich Multidimensionale Modelle (MOLAP/OLAP/ROLAP) oInsbesondere im Data Warehouse-Umfeld weit verbreitet Semistrukturierte Modelle (z.B. auf XML-Basis) oBesonders für die Verarbeitung von heterogenen und uneinheitlich strukturierten Dokumenten (Text, Bild etc.) geeignet

4 Das Relationenmodell Zentrale Eigenschaften des 1970 von Edgar F. Codd eingeführten Relationenmodells I: Im Relationenmodell werden – idealerweise logisch zusammenhängende – Daten (Realweltausschnitte) in Form von zweidimensionalen Tabellen (Relationen) verwaltet, die über Schlüssel (Primärschlüssel, Fremdschlüssel) miteinander verknüpft werden können. Die Attribute (Tabellenspalten) stellen die Eigenschaften der aufgelisteten Datensätze (Records) dar, welche den Tabellenzeilen (Tupel) entsprechen. Die konkrete Ausprägung einer solchen Eigenschaft lässt sich jeweils am Kreuzungspunkt zwischen Attribut & Tupel – den Komponenten (Zellen) – ablesen. Der Tabellenname (Relationenname) sowie die Menge der Attribute einer Tabelle werden als Relationenschema bezeichnet. 2 Tupel einer Relation (Tabelle bzw. Menge von Zeilen) sind dabei niemals identisch & besitzen also immer unterschiedliche Schlüssel

5 Das Relationenmodell Zentrale Eigenschaften des Relationenmodells II: Ein Primärschlüssel ist ein Attribut (bzw. eine Attributkombination), dass zur eindeutigen Identifikation eines Tupels einer Relation dient. Wird dieser Schlüssel in einer anderen Tabelle als Attribut verwendet, ist er dort Fremdschlüssel – über Fremdschlüssel werden also die Relationen zwischen Tabellen realisiert oSchlüssel sind auch für die Einhaltung von sog. Integritätsbedingung notwendig (Bsp. Reservierungssystem Fluggesellschaft: Kein Sitzplatz eines Fluges darf mehrfach reserviert werden etc.) >Insbesondere Fremdschlüssel sind für globale – also über mehrere/alle Relationen hinweg geltende – Integritätsbedingungen maßgeblich; s. referentielle Integrität: Ein Eintrag in ein Feld darf nur vorgenommen werden, wenn ein entsprechender Eintrag im – über den Fremdschlüssel – referenzierten Feld der entsprechenden Tabelle existiert. >Primärschlüssel hingegen gewährleisten die lokale Integrität innerhalb einer Relation. Die Integrität kann dabei automatisch von einem Integritätsmonitor als Teil des DBMS überwacht werden (s. Access etc.) Die Reihenfolge der Tupel einer Relation ist nicht von Bedeutung – desgleichen gilt für die Attribute einer Relation (mal abgesehen von irgendwelchen finsteren weil diskriminierenden Sortierabsichten etc.). Attribute haben i.d.R. atomare Werte (d.h. eine Komponente bzw. Zelle enthält normalerweise – in der 1. NF – nur einfache Datentypen wie string, int etc. –im sog. Non First Normal Form-Model (NF 2 -Modell) sind allerdings auch komplexere Datentypen & Relationen – also weitere Tabellen – als Werte erlaubt)

6 Das Relationenmodell Die wichtigsten Basisoperationen im Relationenmodell (sog. Relationenalgebra) Selektion: Wählt Tupel aus einer Relation aus -> z.B. alle Personen mit Nachnamen Meyer etc. oDas Ergebnis ist wieder eine Relation Projektion: Wählt Attribute einer Relation aus -> z.B. nur Vorname & PLZ aller Personen Natürlicher Verbund (Join) oVerknüpft/Vereinigt 2 Relationen hinsichtlich ihrer gemeinsamen (da in logischem bzw. natürlichem Zusammenhang stehenden) Attribute -> mehrere Tupel werden also zu einem Neuen vereinigt >z.B. wird aus einem Tupel der Relation Personen (Attribute: Vorname, Name) & einem Tupel der Relation Personen_Tel (Attribut: Nummer) über einen Join ein neuer Tupel, der nun sowohl die Attribute Vorname & Name als auch das Attribut Nummer enthält. Mengen-Operationen (Vereinigung, Differenz, Durchschnitt) oDiese Mengen-Operationen können nur auf Relationen angewandt werden, welche ein identisches Relationenschema aufweisen (s. a. Umbenennung) Umbenennung: z.B. die Umbenennung des Attributs Ort in Wohnort oDie Notwendigkeit einer solchen Umbenennung wäre beispielsweise bei einer Vereinigung zweier Relationen gegeben, um deren Attribute zueinander kompatibel zu machen – enthielte eine Relation das Attribut Wohnort & die andere das Attribut Ort, muss eines dieser Attribute vor einer Vereinigung dergestalt umbenannt werden, dass es mit dem anderen Attributnamen identisch ist, da eine Vereinigung nur bei identischem Schema möglich ist – puh. oDas Ergebnis einer Umbenennung ändert also nicht die Relation selbst sondern lediglich das Relationenschema

7 Attribut Spalte einer Tabelle Wertebereich Mögliche Werte eines Attributs (auch Domäne; int, string, boolean) Attributwert Element eines Wertebereichs Relation/Instanz Tabelle bzw. Menge von Zeilen einer Tabelle (auch Instanz eines Relationenschemas) Relationenschema Relationenname + Menge von Attributen Tupel Zeile einer Tabelle / Record (auch Element einer Relation) Datenbankschema Menge von Relationenschemata Datenbank Menge von Relationen (Basisrelationen) Schlüssel minimale Menge von Attributen, deren Werte ein Tupel einer Tabelle eindeutig identifizieren Primärschlüssel ein beim Datenbankentwurf ausgezeichneter Schlüssel Fremdschlüssel Attributmenge, die in einer anderen Relation Schlüssel ist Fremdschlüssel- bedingung alle Attributwerte des Fremdschlüssels tauchen in der anderen Relation als Werte des Schlüssels auf Begriffe des Relationenmodells Das Relationenmodell 2 Relationen zur Darstellung von Personen:

8 Netzwerkmodell & hierarchisches Modell Hierarchisches Modell Ältestes & kommerziell erfolgreichstes Datenbankmodell der ersten Generation o1969 von IBM mit dem IMS – Information Management System – eingeführt oInsbesondere von Banken & Versicherungen z.T. bis dato eingesetzt Hierarchie/Wald als Datenbankschema: oBildet die Realwelt durch eine hierarchische Baumstruktur (einen Wald – also eine Menge von Bäumen) ab oVerknüpfungen der Records via PCR (Parent Child Relationships): >Die einzelnen Records sind dabei jeweils mit ihrem Vorgänger (Parent) verlinkt – mit Ausnahme der Wurzel, welche aus einem einzelnen Record besteht & keinen Vorgänger hat >Ergo tritt jeder Record mit Ausnahme der Wurzel genau einmal als Child auf >Die Enden des Baums, welche also nicht als Parent fungieren können, werden jeweils Blatt genannt Operationen im Hierarchischen Modell: oDie Operationen des hierarchischen Modells lassen sich sehr einfach implementieren (was eine der Ursachen für die Beliebtheit des Modells in der Praxis ist); Basisoperationen: >Durchlauf eines Baums ausschließlich von oben nach unten... >... bzw. bei Geschwistern einer Ebene von links nach rechts

9 Netzwerkmodell & hierarchisches Modell Hierarchisches Modell Problem dieses Datenbankschemas: oMit einer solchen Baumstruktur lassen sich lediglich 1:1 sowie 1:n-Beziehungen darstellen – nicht jedoch die oftmals benötigten n:m-Beziehungen: Lösung: VPCR (um nicht zu sagen: Virtual Parent Child Relationships): oHier wird via virtual records (Zeigern) die klassische Baumstruktur durchbrochen, so dass auch Querverbindungen möglich sind, um auch allgemeine Beziehungen darzustellen:

10 Netzwerkmodell & hierarchisches Modell Netzwerkmodell (CODASYL-Datenbankmodell) Datenbankmodell der ersten Generation o1971 von CODASYL-DBTG (Yihah: Conference on Data Systems Language - Data Base Task Group) entwickelt (wird deswegen oft auch CODASYL-Datenbankmodell genannt) oZwar wird das Netzwerkmodell seit den 90ern zunehmend durch das relationale Modell verdrängt, ist jedoch insbesondere im Großcomputerbereich heute noch weit verbreitet & gewinnt zudem im Zuge des Semantic Web wieder an Bedeutung oBekannte Systeme: >IDMS (Integrated Database Management System) von Cullinet Software >UDS (Universelles Datenbank-System) von Siemens Begriffe des Netzwerkmodells/Gegenüberstellung zum ER- & Relationenmodell:

11 Netzwerkmodell & hierarchisches Modell Netzwerkmodell (CODASYL-Datenbankmodell) Datenbankschema: Das Netzwerkmodell fordert keine strengen Hierarchien – vielmehr kann es als Verallgemeinerung bzw. Erweiterung des hierarchischen Modells betrachtet werden. Es entspricht jedoch auch – mit gewissen Einschränkungen – dem ER-Modell Verknüpfungen der Records oRecords können mehrere Vorgänger haben – es sind prinzipiell also auch m:n-Beziehungen erlaubt – zudem können mehrere Records an oberster Stelle stehen, so dass sich eine Netzwerkstruktur ergibt. oAllerdings sind Beziehungen immer 2stellig (binär) >Beispiel n-stellige Beziehung: Professor Jedöns hält Vorlesung V & empfiehlt das passende Buch B mit der ISBN xyz >Beispiel 2stelliger Beziehungen: Professor Jedöns hält Vorlesung V; Professor Jedöns empfiehlt Buch B; Buch B hat die ISBN xyz usw.... oDie Beziehungstypen haben zudem keine Attribute (hein?) oAnstelle der Mengensemantik des ER-Modells hat das Netzwerkmodell eine Listensemantik Das Schema des Netzwerkmodells wird als gerichteter Graph definiert: oMit der Menge der Record-Typen (Schemata) als Knoten & den Set-Typen (Relationen) als Kanten Über Zeiger wird eine Reihenfolge von Instanzen (Member) festgelegt oDiese Member sind einer Vorgängerinstanz (Owner) zugeordnet oWird der Member-Satz (Set) vollständig durchlaufen, gelangt man schließlich wieder zum Owner

12 Netzwerkmodell & hierarchisches Modell Netzwerkmodell (CODASYL-Datenbankmodell) Beispiel Netzwerkstruktur: Basisoperationen im Netzwerkmodell: oSelektionsoperationen für Rekord-Typen (Schemata) >z.B.: Suche alle Studenten die in Rostock wohnen oBefehle zum Verfolgen von Links (Set-Typen/Relationen) in beiden Richtungen >z.B.: Suche alle Vorlesungen eines Professors

13 Erweiterte relationale & semantische Modelle Geschachtelte Relationen: NF 2 -Modell (NF 2 = NFNF = Non First Normal Form): Geschachtelte Relationen: NF 2 -Modell (NF 2 = NFNF = Non First Normal Form): oErlaubt im Gegensatz zum klassischen Relationenmodell auch geschachtelte Relationen. oWährend im Relationenmodell Attribute i.d.R. nur atomare Werte haben (eine Komponente bzw. Zelle also in der 1. NF nur einfache Datentypen wie string, int etc enthält), sind im sog. NF 2 -Modell neben komplexeren Datentypen vor allem auch Relationen – also weitere Tabellen – als Werte erlaubt, was letztlich einer Schachtelung von Relationen entspricht PNF-Relationen (Partitioned Normal Form): PNF-Relationen (Partitioned Normal Form): oDa die beschriebene Schachtelung von Relationen schnell zu unübersichtlichen & auch fehlerträchtigen Relationen führen können, gibt es sog. PNF-Relationen oDiese lassen sich immer zu einer klassischen (flachen) Relation im Sinne der 1. NF entschachteln oPNP-Relationen haben demnach auf jeder Stufe der Schachtelung einen flachen Schlüssel oPNF-Relationen sind also jene NF-Relationen, die sich entschachtelt immer durch eine flache 1. NF-Relation darstellen lassen Erweitertes NF-Modell (eNF): Erweitertes NF-Modell (eNF): oHier sind als Attributwerte Mengen von..., Listen von..., Tupel von... erlaubt Semantische Datenmodelle: Semantische Datenmodelle: oDatenmodelle, die das Relationenmodell um weitere Abstraktionskonzepte wie Generalisierung, Spezialisierung, Aggregation, Gruppierung etc. ergänzen

14 Objektorientierte & Objektrelationale Modelle Objektorientierte Modelle Modelle, deren Gegenstände Objekte im Sinn der objektorientierten Programmierung sind Basieren dementsprechend auf objektorientierten Sprachen wie C++ & bilden deren Typsystem direkt auf das Datenmodell ab oZiel: Struktur & Verhalten von Umweltobjekten möglichst 1:1 zu erfassen oZu diesem Zweck unterstützen OODB-Modelle im Gegensatz zu klassischen DB-Modellen weiterführende OO Konzepte wie >Komplexe Werte (Objekte), die als set of, tuple of & list of beschrieben werden können Also bspw. Objekte, die neben den üblichen Attributen wiederum Objekte beinhalten können >Objektidentität, um die gespeicherten Objekte von ihren Werten unterscheiden zu können >Methoden, um objektspezifische Operationen definieren & ausführen zu können (& damit ausschließlich für bestimmte Objekttypen zuzulassen) >Vererbung von Attributen & Methoden zwischen Objekten, die in einer IST-Beziehung zueinander stehen >Möglichkeit der (Neu)Definition von Objekttypen (s. Definition von Klassen in der OOP im Sinne selbstdefinierter Datentypen) >Kapselung – Verbergen von Attributen & Methoden – bzw. Kontrolle des Zugriffs auf Objekteigenschaften durch öffentliche Methoden (s. public/private/protected/friends-Prinzip bei C++) >Persistenz – Objekte werden dauerhaft gespeichert oWichtiger Vertreter OODBM ist ODMG-93 (Object Database Management Group) >Hier beschreibt ein (C++-lastiges) Objektmodell Begriffe & semantische Bedingungen des OO Datenmodells >Mögliche Schnittstellen zur Datendefinition & -manipulation werden durch Datenbanksprachen wie ODL (Object Definition Language) OQL (Object Query Language) geboten >Zudem sind Bindings (Spracheinbettungen) für C++, Java & SMALLTALK vorgesehen

15 Objektorientierte & Objektrelationale Modelle Objektorientierte Modelle Abgrenzung zum relationalen Modell: oIm relationalen Modell sind Informationen über ein Objekt (wie einen Angestellten o.ä.) über mehrere Relationen verstreut – d.h. die gefragte Information muss unter Umstände aus mehreren Relationen (via Verbundoperationen etc.) vergleichsweise umständlich zusammengesetzt werden oIm OODBM hingegen wird die Gesamtheit der Informationen über einen Angestellten o.ä. in einem Datenobjekt gehalten – eine entsprechende Anfrage betrifft dann auch nur dieses Objekt. >Vereinfachung der Konsistenzregeln & Leistungsvorteil: Demzufolge müsste auch bei einer Aktualisierung nicht die gesamte Datenbasis der DB nach eventuell betroffenen Tupeln abgesucht werden, wie dies im relationalen Modell der Fall wäre.

16 Objektorientierte & Objektrelationale Modelle Objektrelationale Modelle Bindeglied zwischen klassischen relationalen und objektorientierten Datenbanksystemen – also eine Erweiterung relationaler DB-Systeme um bestimmte objektorientierte Eigenschaften (s. SQL3/SQL-99) oHäufig wird über eine Relationale Datenbank eine objektorientierte Zugriffsschicht (Persistent Framework) gesetzt. Objektrelationale Modelle kommen überall dort zum Einsatz, wo Mengen von Objekten in Beziehung zu anderen Daten oder Objekten gebracht werden müssen. oBeispiel GIS: Mehrere Koordinaten-Objekte referenzieren eine Straße – die Koordinaten stehen also in Relation mit einem Straßennamen und sind selbst Objekte, die zueinander eine Beziehung haben.

17 Data Warehouse Multidimensionale Datenmodelle Data Warehouse Data Warehouse: Mitnichten ein Warenhaus, sondern ein multidimensionales System, das unternehmensübergreifend Daten aus den operativen Einzelsystemen zusammenführt, integriert & für die Analyse aufbereitet oAlso eher ein Datenlager, dass der Informationsintegration dient oDer Inhalt dieses Datenlagers setzt sich demnach aus Daten unterschiedlicher Quellen zusammen, die in das Warehouse geladen & dort mehr oder weniger langfristig gespeichert werden, um zu Analysezwecken sowie als betriebswirtschaftliche Entscheidungshilfe verwendet zu werden. oEs wird also eine homogene, vergleichbare Datenbasis generiert, um eine globale Sicht auf heterogene & verteilte Datenbestände zu ermöglichen oEin Data Warehouse dient oft einem OLAP (OnLine Analytical Processing) als Datenquelle (s. Folgechart). oDie Beladung eines Warehouse erfolgt z.B. turnusmäßig, um Analysen über die Zeit zu ermöglichen. Der Trend geht allerdings inzwischen zum Real-Time-Data- Warehousing (yoyoyo!).

18 OLAP Multidimensionale Datenmodelle OLAP OLAP (OnLine Analytical Processing): Ein analytisches Informationssystem, welches entscheidungsunterstützend im interaktiven Bereich eingesetzt wird oOLAP wird zur hypothesengestützten Analyse von Daten z.B. eines Data Warehouse verwendet: >Der Analyst muss also vor der eigentlichen Untersuchung wissen, welche Anfragen er an das OLAP-System stellen möchte. >Seine Hypothese wird dann durch das Analyseergebnis bestätigt oder abgelehnt >Ziel ist, durch multidimensionale Betrachtung dieser Daten ein entscheidungsunterstützendes Analyseergebnis zu gewinnen. oOLAP-Cube Der OLAP-Cube ist ein Data Cube, ein mehrdimensionaler Datenwürfel, der auf Basis bspw. eines Data Warehouse erstellt wurde und der logischen Darstellung von Daten dient >Die Daten – z.B. Kennzahlen wie Geldbeträge etc. – werden dabei als Elemente eines solchen mehrdimensionalen Würfels angeordnet. >Da häufig mehr als 3 Dimensionen realisiert werden, spricht man auch von einem Hypercube >Bei OLAP sind die Dimensionen des Cube i.d.R. hierarchisch angeordnet Produktgruppen -> Produktklassen -> Produkte etc. Staaten -> Bundesländer -> Städte -> Stadtbezirke etc.

19 Data Warehouse & OLAP Multidimensionale Datenmodelle Data Warehouse & OLAP Ich hab da mal ne Grafik vorbereitet, ne: Oder wie der Spanier sagt:

20 Data Warehouse & OLAP Multidimensionale Datenmodelle Data Warehouse & OLAP Zusammenspiel zwischen Data Warehouse & OLAP: Das Befüllen eines Data Warehouse ist ein komplexer & zeitaufwendiger Prozess, der nicht synchron zum normalen Transaktionsbetrieb der als Quelle dienenden DB erfolgen kann & deshalb nur selten vorgenommen wird: oEin Data Warehouse wird aus mehreren verschiedenen operationalen DB gefüllt – also DB, welche im laufenden Betrieb beständig Transaktionen verschiedenster Art durchführen >Als mögliche Datenquellen werden neben DB auch WWW-Quellen genutzt oVor der Datenintegration ins Warehouse müssen die Daten aktualisiert (refreshed), extrahiert, transformiert & bereinigt werden (Data Cleaning), um schließlich eine homogene & vergleichbare Datenbasis zu generieren Auf dem Gesamtbestand des Warehouse setzt (i.d.R. nach dem Client-Server-Prinzip) ein OLAP-System auf, welches aus ein od. mehreren OLAP-Servern besteht oDabei sollte das OLAP-System den durch das Akronym FASMI (Fast Analysis of Shared Multidimensional Information) definierten Anforderungen genügen: >Fast: Fürgegen interaktives Arbeiten notwendig >Analysis: Unterstützung analytischer & statistischer Funktionalitäten >Shared: Unterstützung des Mehrbenutzerbetriebs >Multidimensional: Unterstützung des multidimensionalen Datenmodells >Information: Gewährleistung der Informationsgewinnung aus Rohdaten oOLAP-Varianten >MOLAP Multidimensional OLAP (s. OLAP-Cube: eigene Datenhaltung in Form eines Datenwürfels – realisiert als direkte Speicherung von Matrizen; schneller Zugriff) >ROLAPRelationales OLAP (basiert auf relationaler DB) >HOLAPHybrides OLAP (Hybrid zwischen MOLAP & ROLAP)

21 Semistrukturierte Datenbanken Semistrukturierte Daten/Dokumente: Daten bzw. Dokumente wie Text- oder HTML-Files mit wechselnder Strukturierung oBestenfalls liegt zwar eine interne Struktur vor, jedoch ist diese oft wechselhaft/nicht zwingend konsistent oMögliche Merkmale semistrukturierter Datenmodelle: >Kein Zentrales Schema vorhanden: Das Schema solcher Modelle ist nicht zentral für alle Daten gleichen Typs gespeichert – sondern implizit in jedem Dokument enthalten Notwendigkeit von Parsern o.ö. zur Strukturerkennung & -interpretation, da sich ein solches Schema nicht von Standard-Datenmodellen adäquat verarbeiten ließe >Wechselnde Datenstruktur: Selbst Daten desselben Typs können eine wechselnde Struktur aufweisen differierende, fehlende od. zusätzliche Attribute bzw. divergierende Strukturierung auch innerhalb der Attribute selbst >Daten haben keine Struktur im Sinne von Attributen bzw. Tags So lassen sich beispielsweise die einzelnen Sätze eines Textes in Ermangelung von Attributen bzw. Tags nicht ohne weiteres (parsing o.ä.) identifizieren >Ggf. variierende Datentypen der Attribute: Diese haben keine verbindliche Typisierung im Sinne einer Integritätsbedingung Relationale Modelle definieren für die Attribute Integritätsbedingungen hinsichtlich der zuzulassenden Datentypen >Große Anzahl möglicher Attribute & polymorphe interne Strukturierung der Attribute (im Gegensatz zu relationalen Modellen mit einer überschaubaren Anzahl von Attributen & deren durchgängigen Strukturierung)

22 Semistrukturierte Datenbanken Mögliche Merkmale semistrukturierter Datenmodelle (Fortsetzung): Kein festes Schema (als auch nicht implizit): Attribute & Dokument-Struktur unterliegen häufigen Änderungen orelationale DB haben über einen längeren Zeitraum hinweg ein festes Schema Unscharfe Trennung zwischen Daten & Schema: Bedingt durch häufige strukturelle Änderungen können Schema & die eigentlichen Nutzdaten nicht immer klar voneinander unterscheiden werden – Schemainformationen werden also ggf. als Daten missverstanden oRelationale Modelle trennen Schemata & Instanzen (Daten) streng voneinander Inhaltsbasierte Anfragen: Bei Anfrageoptionen wie Vergleichsprädikaten (z.B. die Suche nach einem Begriff) wird oftmals das gesamte Dokument & nicht einzelne Attribute abgeglichen bzw. durchsucht (s. übliche Suchanfragen im klassischen (nicht semantischen) Web: Ein gesuchter Begriff wird im Titel, in den Keywords sowie des gesamten HTML-Dokuments gesucht) oIn relationalen Modelle erfolgen Anfragen hingegen auf Basis von konkreten Attributen

23 Semistrukturierte Datenbanken Datenmodelle für semistrukturierte Dokumente (welche die beschriebenen Merkmale teilweise beheben) Schemalose Datenmodelle: Nutzen Graphendarstellungen für Instanzen & Attribute oOEM (Object Exchange Model) oBaummodell Union-Datenmodell: Hier wird eine Dokumentstruktur durch Vereinigung von Basisstrukturen erreicht oProblemski: Notwendigkeit vordefinierter Basisstrukturen – andernfalls bleiben die Probleme semistrukturierter Modelle bestehen Die Markup-Sprache HTML (Hypertext Markup Language): Strukturierung durch Tags oVorteil: Hohe Toleranz bei fehlenden/zusätzlichen Tags – deshalb eigentlich für semistrukturierte Dokumente gut geeignet oProblem: Vordefinierter & nicht veränderbarer Satz von (Tag-)Attributen Metasprachen wie SGML (Standard Generalized Markup Language) & XML (Extensible Markup Language): Ermöglichen die Beschreibung einer sog. DTD (Document Type Definition), welche Art, Menge & Strukturierung (Schachtelung) der Attribute definiert

24 Semistrukturierte Datenbanken Semistrukturierte Daten am Beispiel von XML XML ist eine Teilmenge von SGML, die aufgrund der hohen Komplexität von SGML vom W3C neu abgeleitet wurde Damit ist XML - wie SGML auch – eine Metasprache (also eine Sprache zur (Regel-)Definition anderer Sprachen) zur Erstellung maschinen- und menschenlesbarer Dokumente in Form einer Baumstruktur XML-Dokumente haben eine logische & eine physische Struktur (im Gegensatz zu HTML jedoch keine zwingende Layout-Struktur für die Browser-Darstellung) oLogische Struktur: Durch einen hierarchisch strukturierten Baum gewährleistet; Baumknoten: >Elemente: Tags bzw. Tag-Paare oder Empty-Element-Tags >Attribute: Schlüsselwort-Werte-Paare für Zusatz-Informationen über Elemente >Processing Instructions (Verarbeitungsanweisungen): Werden z.B, verwendet, um Verarbeitungsanweisungen anderer Sprachen zu integrieren – PHP-Beispiel: >Kommentare: >Daten/Payload wie Text etc.: oPhysische Struktur: >Hauptdatei des XML-Dokuments als erste Entität: *.xml >XML-Deklaration (spezifiziert XML-Version, Zeichenkodierung und Verarbeitbarkeit): >DTD definiert Entitäten & spezifiziert den erlaubten logischen Aufbau des XML- Dokuments (s. Folgerchart): *.dtd

25 Semistrukturierte Datenbanken Semistrukturierte Daten am Beispiel von XML – die DTD I (Elementtyp-Deklaration) In einer DTD werden Elemente, Attribute von Elementen & Entitäten definiert. Mit einer Elementtyp-Deklaration wird ein Element (Tag) & sein möglicher Inhalt definiert. In einem validen XML-Dokument dürfen nur Elemente vorkommen, die in der DTD definiert sind. Die DTD verwendet zur Elementtyp-Deklaration folgende Ausdrücke : oSequenz: (A1, A2) Definiert die Reihenfolge von Elementen – logo: erst A1, dann A2... oAlternative : (A1|A2) Definiert eine Wahlmöglichkeit zwischen Elementen - entweder muss A1 oder A2 enthalten sein oVerschiedene Varianten für Wiederholungen (Iteration),deren Notation an reguläre Ausdrücke anlehnt (fehlt eine solche Notation, muss das entsprechende Element genau einmal vorkommen!) : >Beliebige Iteration: A* A kann beliebig oft vorkommen –also auch gar nicht >nichtleere Iteration: A+ A muss mindestens einmal vorkommen >optionales Element: A? A darf vorkommen, muss es jedoch nicht – wenn A vorkommt, dann jedoch nur einmal! oGruppierung von Elementen mit runden Klammern: () oKein Inhalt: EMPTY (das Element ist immer leer, wie z.B. bei ) oBeliebiger Inhalt: ANY oAusschließlich Text: # PCDATA (parseable character data)

26 Semistrukturierte Datenbanken Semistrukturierte Daten am Beispiel von XML – die DTD II (Attributlisten-Deklaration) Die Liste der möglichen Attribute eines Elementes wird in einer DTD mit angegeben. Die Attributliste enthält durch Leerzeichen oder Zeilenumbrüche getrennt jeweils den Namen, den Typ und Vorgaben eines Attributes. Attributtypen: oCDATA (Zeichenketten) oID (Attributwert gilt als eindeutige ID – optimal für IDs aus Datenbanken) oIDREF (Einzelne Referenz auf Attribute des Typs ID - Attributwert muss also gleich einer ID sein) IDREFS (Liste von Referenzen auf Attribute des Typs ID - dito für ein oder mehrere ID's) oNMTOKEN (einzelnes Token - Attributwert muss gleich einem Namen sein ) NMTOKENS (Liste von Tokens - dito für ein oder mehrere Namen ) oENTITY ( Attributwert muss gleich ungeparster Entity sein ) ENTITIES ( dito für ein oder mehrere Entities ) oAufzählungen & NOTATION -Aufzählungen (Liste der erlaubten Werte; wird der Reihe nach angegeben und durch | getrennt) Attribut-Vorgaben: o#REQUIRED Erforderliches Attribut (muss explizit im Element vorkommen) o#IMPLIED Optionales Attribut (darf fehlen & hart dann auch keinen Default-wert) o"..." Default-Wert (falls das Attribut weggelassen wird) o#FIXED "..." Das Attribut hat immer einen festen Standardwert

27 Semistrukturierte Datenbanken Semistrukturierte Daten am Beispiel von XML – die DTD III (Entity-Deklaration) Ein Entity ist eine benannte Abkürzung für eine Zeichenkette (oder ein externes Dokument), die innerhalb der DTD oder des XML-Dokumentes, das diese DTD benutzt, verwendet werden kann. Entities sind also (verkürzte) Platzhalter für längere Deklarationen innerhalb einer DTD Die Entity-Deklaration wird durch das Schlüsselwort ENTITY in der DTD festgelegt. Ein Beispiel-Entity fasst unter dem Platzhalter %adresse die Elemente straße, plz und stadt zusammen: o //Anführungsstriche beachten! oMöchte man nun die Adresse als Unterelement einer Person verwenden, tut man dies über das Entity %adresse : //Semikolon nicht vergessen! oHier zeigt sich der Vorteil der Entity-Verwendung, da logisch zusammengehörende Elemente zu einem verkürzten Platzhalter zusammengefasst werden können. Interne Entities: Diese bestehen aus Zeichenketten (& können selber wieder Entity-Referenzen und wohlgeformtes XML-Markup enthalten) – hier wird eine Entity-Referenz der Form &name; wird durch den Inhalt der Entity name ersetzt: Externe Entities: Diese bestehen aus dem Inhalt einer externen Datei, auf die verwiesen wir

28 Semistrukturierte Datenbanken Semistrukturierte Daten am Beispiel von XML – die DTD IV (Verschiedene DTD-Klassen) Standard-DTDs oAlso gleichsam als Standard verabschiedete DTDs (EAD-DTD, TEI-DTD, EBIND-DTD etc.) mit einem fixen Schema oVorteil: Lassen sich leicht in beliebige Datenbanken importieren Separate DTDs oZ.B. für den Datenaustausch innerhalb von Firmen etc. oVorteil: dito; die Programmierung spezifischer Import-Filter etc. lohnt sich jedoch erst bei einer großen Anzahl zu importierender XML-Dokumente Lokale DTDs für selbstbeschreibende Dokumente oAls Teil des Dokuments selbst (interne Notation) oNachteil: Variierende, zueinander inkompatible DTDs - hier muss also auf die genannten anderen Modelle zur Verarbeitung semistrukturierter Datenbanken zurückgegriffen werden

29 Semistrukturierte Datenbanken Import semistrukturierter Daten in relationalen od. objektorientierten Datenbanken Hier lässt sich ein Import dadurch realisieren, dass die zu importierenden, semistrukturierten Daten als neuer Datentyp für Dokumente etc. definiert werden. oBei XML-Dokumenten od. DTDs kann dies durch die Definition eines Erweiterungsmoduls geschehen oXML kann hier auch als Datenaustauschformat zwischen verschiedenartigen relationalen DB fungieren (Die Tabellenstruktur wird dann als DTD erfasst) oXQL, XML-Q & Lorel sind mögliche Technologien zur Abfrage von XML basierten Datenbanken oDas DOM (Document Object Model) als plattform- & PPSneutrale Schnittstelle fungiert im Zusammenhang mit XML-Parsern als API, um Programmen den Zugriff auf Inhalt, Struktur & Stil von XML-Dokumenten zu ermöglichen.

30 Sonstige DB-Modelle GOOD (Graph-Oriented Object Model) GOOD (Graph-Oriented Object Model) DB-Modell auf Basis von Graphen oHier werden die Ecken eines Graphen als Werte, Objekte & Typen interpretiert, wobei die Kanten des Graphen dessen Ecken einander zuordnen oEin GOOD-Graph besteht aus DB & DB-Schema in einer homogenen Darstellung oMittels Graphmanipulationen werden Anfragen & Änderungen vorgenommen Klassenlose DB-Modelle Klassenlose DB-Modelle Variante der OODBM oMit ähnlichen Eigenschaften, allerdings wird hier auf eine strenge Klassifizierung & Typisierung verzichtet >Vorteil: Höhere Flexibilität bei der Modellierung dynamischer & komplexer Anwendungen >Nachteil: Erschweren von Anfragen & effizienten Speicherstrukturen Feature-Terme Feature-Terme Dienen der Wissensrepräsentation oFeature-Terme bestehen aus einem eindeutigen Namen & verschiedenen Features (Attributen) >Die Features können wiederum weitere vollständige Feature-Terme aufnehmen, so dass eine komplexe Objektstruktur ermöglicht wird >Das Lilog-Datenmodell dient der Verarbeitung natürlicher Sprachen (& wohl auch von feature-Termen) – eine logikbasierte Abfragesprache stellt F-Logic dar (basiert auf Feature-Termen) Komplex-Objekt-Datenmodelle wie MAD (Molekül-Atom-Datenmodell) Komplex-Objekt-Datenmodelle wie MAD (Molekül-Atom-Datenmodell) Dient der Darstellung komplexer Objektstrukturen oWird im technischen Bereich verwendet, um die dort weit verbreiteten hierarchischen Ist Teil von- Beziehungen zu unterstützen. MAD ermöglicht z.B. das Zusammensetzen von Basisobjekten (Atomen) zu komplexen Objektstrukturen (Molekülen)


Herunterladen ppt "Datenbankmodelle für die Realisierung von Anwendungen Hauptseminar Nichtrelationale Datenbanken Master of Ceremony: Christian Daum."

Ähnliche Präsentationen


Google-Anzeigen