Zusammenfassung Datenmanagement Erstellt aus den

Zusammenfassung Datenmanagement DMG 1.1 Sie kenne die Begriffe Daten, Datenbasis, Datenbankverwaltungssystem, Datenbankschema und Datenmodell ................................................................................................................................. 5 1.1.1 Daten ...................................................................................................................................... 5 1.1.2 Datenbasis .............................................................................................................................. 5 1.1.3 Datenbank .............................................................................................................................. 5 1.1.4 Datenbankverwaltungssystem / Datenbankmanagementsystem (DBMS) ............................ 5 1.1.7 Datenmodell ........................................................................................................................... 5 1.1.8 Datenbankschema .................................................................................................................. 5 1.2 Sie kennen die Konzepte Entität, Schlüssel und Relation ............................................................. 6 1.2.1 Entität ..................................................................................................................................... 6 1.2.2 Schlüssel ................................................................................................................................. 6 1.2.3 Relation .................................................................................................................................. 6 1.2.4 Attribut ................................................................................................................................... 6 1.3 Sie können Beziehungen im Blick auf Funktionalitäten charakterisieren und kennen die (min:max) Notation ............................................................................................................................. 6 1.3.1 Entity Relationsship Modell (ERM) ......................................................................................... 6 Funktionalitäten der Beziehungen .................................................................................................. 6 1.5 Sie können schwache Entitäten, Generalisierung und Aggregation modellieren ......................... 7 1.5.1 Schwache Entitäten (doppelt umrandet) ............................................................................... 7 1.5.2 Generalisierung (is_a) ............................................................................................................. 7 1.5.3 Aggregation (part_of) ............................................................................................................. 7 1.6 Sie kennen das Konzept von sichten und mögliche Schwierigkeiten bei der Sichtenintegration . 8 1.7 Sie können für ein gegebenes ERM ein relationales Schema definieren ...................................... 8 1.7.1 rundlagen des relationalen Modells ....................................................................................... 9 1.7.2 Verfeinerung des relationalen Schemas ................................................................................ 9 2. Sie kennen die Entwurfstheorie und Normalformen ........................................................................ 10 2.1 Sie kennen den Begriff der funktionalen Abhängigkeit und können funktionale Abhängigkeiten identifizieren ..................................................................................................................................... 10 2.2 Sie kennen die Definition eines Schlüssels und können Schlüsselkandidaten identifizieren...... 10 Formale Definition ......................................................................................................................... 10 2.3 Sie kennen die Definition der Boyce Codd Normalform (BCNF) ................................................. 11 2.4 Sie können entscheiden, ob ein relationales Modell in der BCNF ist .......................................... 11 1. Beispiel: ..................................................................................................................................... 11 Verletzung der BCNF ..................................................................................................................... 12 2. Beispiel aus dem formativen Test: ............................................................................................ 12 Verletzung der BCNF ..................................................................................................................... 12 3. Sie kennen die relationale Algebra .................................................................................................... 13 3.1 Operationen ................................................................................................................................ 13 3.1.1 Kreuzprodukt ........................................................................................................................ 13 3.1.2 Vereinigung .......................................................................................................................... 13 3.1.3 Differenz ............................................................................................................................... 13 3.1.4 Durchschnitt ......................................................................................................................... 13 3.1.5 Division ................................................................................................................................. 14 3.1.6 Projektion ............................................................................................................................. 14 3.1.7 Selection ............................................................................................................................... 14 3.1.8 Umbenennung ...................................................................................................................... 14 3.1.9 Natural Join .......................................................................................................................... 15 3.1.10 (full) outer join .................................................................................................................... 15 3.1.11 Left outer join ..................................................................................................................... 15 Erstellt aus den einzelnen Dokumenten von den Studenten Seite 1 Zusammenfassung Datenmanagement 3.1.12 Right outer join ................................................................................................................... 15 3.1.13 Conditional join .................................................................................................................. 16 3.2. Baumstruktur / Query tree ......................................................................................................... 16 3.3. Darstellung von Relationen ........................................................................................................ 16 3.4. Äquivalenzrelationen ................................................................................................................. 17 4.1 Sie können ein relationales Schema in SQL definieren ................................................................... 19 4.2 Sie können das Schema verändern ................................................................................................. 19 4.3 Sie können einfache Abfragen formulieren .................................................................................... 19 1. SELECT ........................................................................................................................................... 19 2. FROM ......................................................................................................................................... 20 3. WHERE ....................................................................................................................................... 20 4. GROUP BY .................................................................................................................................. 20 5. HAVING ...................................................................................................................................... 21 4.4 Sie können Abfragen mit mehreren Relationen formulieren. ........................................................ 21 4.5 Sie können Mengenoperationen und geschachtelte Anweisungen formulieren ........................... 21 4.6 Sie kennen die Aggregatfunktionen und Gruppierungen ............................................................... 21 4.7 Sie kennen den exists Operator ...................................................................................................... 22 4.8 Sie kennen die Problematik der Null‐Werte ................................................................................... 22 4.9 Sie können Abfragen mit joins formulieren .................................................................................... 22 4.10 Sie kennen die Befehle insert, delete und update ........................................................................ 23 4.11 Sie können Sichten erstellen und nutzen ...................................................................................... 23 4.12 Sie kennen die Problematik in Bezug auf Sichten ......................................................................... 24 5. Sie kennen JDBC ................................................................................................................................ 25 5.1 Sie können in Java den Zugriff auf Datenbanken mittels JDBC programmieren ......................... 25 5.2 Sie kennen dafür die Klassen Connection, Statement, ResultSet ................................................... 25 5.2.1 Klasse Connection ................................................................................................................ 25 5.2.2 Klasse Statement .................................................................................................................. 25 5.2.3 Klasse ResultSet .................................................................................................................... 26 6. Sie kennen das Konzept der referentiellen Integrität und können es anwenden ............................ 27 6.1 Sie kennen den Begriff der referentiellen Integrität ................................................................... 27 Datenintegrität .............................................................................................................................. 27 Referentielle Integrität .................................................................................................................. 27 Ein Beispiel: ................................................................................................................................... 27 6.2 Sie können statische Integritätsbedingungen formulieren ..................................................... 27 Datenfeldebene ............................................................................................................................. 27 Beziehungsebene * ....................................................................................................................... 28 6.3 Sie können Integritätsbedingungen in SQL formulieren. ............................................................ 28 6.4 Sie kennen den Begriff der Trigger und können einfache Trigger implementieren .................... 30 7. Physische Datenorganisation ............................................................................................................ 32 Bedeutung der Physischen Datenorganisation ................................................................................. 32 B – Bäume .......................................................................................................................................... 32 B+ ‐ Baum ........................................................................................................................................... 33 B* ‐ Baum .......................................................................................................................................... 33 Rechnen im B* Baum ........................................................................................................................ 34 Aufgabe 1: ......................................................................................................................................... 34 Aufgabe2: .......................................................................................................................................... 35 8. Sie verstehen die Optimierung von Anfragen ................................................................................... 36 8.1 Sie kennen die Bedeutung der Datenbankoptimierung .............................................................. 36 8.2 Sie können die logische Anfrageoptimierung einer Anfrage durchführen ................................. 36 8.3 Sie kennen Techniken der physischen Optimierung ................................................................... 39 8.3.1 Selektion ............................................................................................................................... 39 8.3.2 Binäre Zuordnung (Matching) .............................................................................................. 39 Erstellt aus den einzelnen Dokumenten von den Studenten Seite 2 Zusammenfassung Datenmanagement 8.3.3 Gruppierung und Duplikateliminierung ............................................................................... 43 8.3.4 Projektion und Vereinigung .................................................................................................. 43 9. Sie kennen das Transaktionskonzept und dessen Anwendung in Fehlerbehandlung und Mehrbenutzersysnchronisation ............................................................................................................ 46 9.1 Sie können das ACID Prinzip erklären. Sie kennen die möglichen Zustände einer Transaktion . 46 9.2 Sie kennen die möglichen Fehler, die zu einem Recovery führen. ............................................. 47 9.3 Sie kennen die Konzepte für die Ersetzung von Puffer Seiten (steal und NOTsteal). Sie kennen Möglichkeiten des Einbringens von Änderungen (force und NOTforce). ......................................... 47 9.4 Sie können eine Log Datei (logische Protokollierung) lesen und erstellen. Sie können Winner und Loser Transaktionen identifizieren. Sie können eine Log‐Datei analyisieren. Sie können den Wiederanlauf nach einem Fehler auf Papier nachvollziehen. Sie kennen das Konzept der Sicherungspunkte .............................................................................................................................. 47 9.5 Sie kennen Fehler beim unkontrollierten Mehrbenutzerbetrieb. Sie kennen den Begriff der Historie und der Serialisierbarkeit. Sie können eine Historie in eine äquivalente Historie umformen. Sie können den Serialisierbarkeitsgraphen einer Historie erstellen und interpretieren. ................. 50 9.6 Sie kennen verschiedene Sperrmodi. Sie kennen Methoden der sperrbasierten Synchronisation. Sie können einen Wartegraphen erstellen und Verklemmungen (deadlocks) erkennen. ................ 54 10. Sie kennen Sicherheitsaspekte in SQL ............................................................................................. 56 10.1 Sie kennen die Befehle der Zugriffskontrolle in SQL ................................................................. 56 10.1.1 Der Grant‐Befehl ................................................................................................................ 56 10.1.2 Der Revoke‐Befehl .............................................................................................................. 56 10.2 Sie kennen die Idee der Rollen und können sie in dem verwendeten Datenbank‐System umsetzen ........................................................................................................................................... 56 10.3 Sie können Zugriffsrechte auf Relationen und Sichten vergeben ............................................. 57 11. Sie kennen die Definitionssprache (ODL) und die Abfragesprache (OQL) der ODMG .................... 58 11.1 sie kennen die zwei Vererbungen in der ODL der ODMG (interface und extends) .................. 58 11.2 Sie können Beziehungen in der ODL beschreiben ..................................................................... 58 11.3 Sie können ein Datenmodell in ODL interpretieren .................................................................. 59 11.4 Sie können ein einfaches Datenmodell erstellen ...................................................................... 59 11.5 Sie kennen die Grundlagen der Anfragesprache der ODMG (Object Query Language, OQL) (iknsbes. Anfragen auf Extents, Path Expressions, Methodenaufrufe) ............................................. 59 11.6 Sie können Anfragen interpretieren. Sie können Anfragen selber formulieren ....................... 60 12. XPath und XQuery ........................................................................................................................... 61 12.1 Einführung ................................................................................................................................. 61 12.2 XML Struktur .............................................................................................................................. 61 12.3 XML Schema .............................................................................................................................. 61 Rekursive Struktur ......................................................................................................................... 62 12.4 Analyse von Dateninhalten ....................................................................................................... 63 12.5 XML‐Anfragesprache XQuery .................................................................................................... 65 12.6 XPath‐Achsen ............................................................................................................................ 65 12.7 XPath Ausdrücke........................................................................................................................ 66 Beispiel – Anfrage mit Bedingung ................................................................................................. 66 Beispiel – Anfrage .......................................................................................................................... 67 Beispiel – Anfrage mit Bedingung 2 .............................................................................................. 67 Beispiel – Anfrage mit Existenzprüfung ......................................................................................... 67 12.8 Verkürzte Syntax ....................................................................................................................... 68 12.9 XPath Ausdrücke mit verkürzter Syntax .................................................................................... 68 12.10Effektive XQuery Anfragen (MSSQL) ........................................................................................ 69 Joins in XQuery .............................................................................................................................. 70 13. Sie kennen das Konzept des Datawarehouse .................................................................................. 71 13.1 sie können einige wesentliche Unterschiede zwischen OLAP und OLTP nennen ..................... 71 Erstellt aus den einzelnen Dokumenten von den Studenten Seite 3 Zusammenfassung Datenmanagement 13.2 Sie kennen das Sternschema (Fakten‐ und Dimensionstabellen) und dessen Eigenschaften (in Bezug auf Normalisierung und Join‐Tiefen) ...................................................................................... 71 13.3 Sie können den Cube Operator anwenden ............................................................................... 76 14. Sie kennen Konzepte von Verteilten Datenbanken ........................................................................ 77 14.1 Sie können den Begriff der verteilten Datenbanken definieren ............................................... 77 14.2 Sie können die horizontale und vertikale Fragmentierung erläutern ....................................... 77 14.2.1 Horizontale Fragmentierung .............................................................................................. 77 14.2.2 Vertikale Fragmentierung .................................................................................................. 78 14.3 Sie wissen, was Allokation bedeutet ......................................................................................... 79 14.4 Sie können Fragmentierungs‐ und Allokationstransparenz erläutern ...................................... 80 14.4.1 Fragmentierungstransparenz ............................................................................................. 80 14.4.2 Allokationstransparenz ....................................................................................................... 80 14.5 Sie kennen das 2‐Phase‐Commit Protokoll als wichtiges Element der Transaktionskontrolle . 81 14.5.1 Einführung in die Problematik ............................................................................................ 81 14.5.2 Das 2PC‐Protokoll ............................................................................................................... 81 Erstellt aus den einzelnen Dokumenten von den Studenten Seite 4 Zusammenfassung Datenmanagement Sie können Datenbanken modellieren 1.1 Sie kenne die Begriffe Daten, Datenbasis, Datenbankverwaltungssystem, Datenbankschema und Datenmodell 1.1.1 Daten Daten ‐> Informationen ‐> Wissen •
Daten sind eine Folge von Zeichen; elementare Fakten, Aussagen und Sachverhalte. •
Information sind Daten mit einer Bedeutung und einem Zweck. •
Wissen ist Information in einem bestimmten, für den Menschen relevanten Kontext. 1.1.2 Datenbasis Gespeicherte Daten werden als Datenbasis bezeichnet. 1.1.3 Datenbank Einen logisch zusammengehörigen Datenbestand. Dieser Datenbestand wird von einem laufenden Datenbankverwaltungssystem verwaltet und für Anwendungssysteme und Benutzer unsichtbar auf nichtflüchtigen Speichermedien abgelegt. 1.1.4 Datenbankverwaltungssystem / Datenbankmanagementsystem (DBMS) Die Gesamtheit der Programme zum Zugriff auf die Datenbasis, zur Kontrolle der Konsistenzfügung: •
Datenabfrage und ‐manipulation (Data Manipulations Langauge, DML) (SELECT,FROM,WHERE…) •
Verwaltung der Datenbank (Data Definition Langauge, DDL) (CREATE TABLE PROJECT…) * Berechtigungssteuerung (Data Control Language, DCL) (GRANT SELECT…) 1.1.7 Datenmodell Das Datenmodell bestimmt, wie die Daten modelliert werden können: •
Beschreibung der Datenobjekte (WAS) und zur •
Festelegung der anwendbaren Operatoren und deren Wirkung. Das Datenmodell beinhaltet die zwei Sprachen; Data Manipulations Langauge und Data Definition Langauge. 1.1.8 Datenbankschema Das Datenbankschema legt die Struktur der speicherbaren Datenobjekte fest, es umfasst alle Informationen über die Datenbank (ausser den eigentlichen Daten) und wird mit der Data Definition Langugae (DDL) manipuliert. Erstellt aus den einzelnen Dokumenten von den Studenten Seite 5 Zusammenfassung Datenmanagement 1.2 Sie kennen die Konzepte Entität, Schlüssel und Relation 1.2.1 Entität Entitäten sind unterscheidbare physische oder gedanklich existierende Konzepte der zu modellierenden Welt. Man abstrahiert ähnliche Gegenstände zu Gegenstandstypen (Entitytypen). (zum Beispiel Angestellter "Müller", Projekt "3232") 1.2.2 Schlüssel Eine minimale Menge von Attributen, deren Werte das zugeordnete Entity eindeutig innerhalb aller Entities seines Typs identifiziert. (zum Beispiel Angestellter, Projekt, Buch, Autor, Verlag) 1.2.3 Relation Ist die Beziehung zwischen Entitätstypen. (zum Beispiel "Angestellter Müller leitet Projekt 3232") 1.2.4 Attribut Elementarinformation einer Entität oder einer Beziehung (zum Beispiel Vorname und Nachname von Angestellter) 1.3 Sie können Beziehungen im Blick auf Funktionalitäten charakterisieren und kennen die (min:max) Notation 1.3.1 Entity Relationsship Modell (ERM) Funktionalitäten der Beziehungen 1:1‐Beziehung: Jeder Entity e1 aus E1 höchstens ein Entity e2 aus E2, und umgekehrt. 1:n‐Beziehung: Jeder Entity e1 aus E1 beliebig viele (0..n) Entities aus E2 zugeordnet werden. n:m‐Beziehung: Jeder Entity e1 aus E1 beliebig viele (0..n) Entities aus E2 zugeordnet werden und umgekehrt (keine Restriktionen). Erstellt aus den einzelnen Dokumenten von den Studenten Seite 6 Zusammenfassung Datenmanagement Professoren x Studenten ‐> Seminarthemen Seminarthemen x Studenten ‐> Professoren Studenten dürfen bei demselben Professor bzw. derselben Professorin nur ein eminarthema "ableisten" (damit ein breites Spektrum abgedeckt wird). •
Studenten dürfen dasselbe Seminarthema nur einmal bearbeiten sie dürfen also nicht bei anderen Professoren ein schon einmal erteiltes Seminarthema nochmals bearbeiten. Die (min, max)­Notation Diese Notation legt die Unter‐ und Obergrenze für Entity‐Beziehungen fest. 1.5 Sie können schwache Entitäten, Generalisierung und Aggregation modellieren 1.5.1 Schwache Entitäten (doppelt umrandet) Sind in ihrer Existenz von einem anderen, übergeordneten Entity abhängig und oft nur in Kombination mit dem Schlüssel des übergeordneten Entites eindeutig identifzierbar. Räume sind existenzabhängig von dem Gebäude. Wenn man das Gebäude abreisst, verschwinden damit auch alle in dem betreffenden Gebäude liegenden Räume. 1.5.2 Generalisierung (is_a) Wird im konzeptuellen Entwurf eingesetzt, um eine bessere und übersichtlichere Strukturierung der Entitytypen zu erreichen. 1.5.3 Aggregation (part_of) Während man bei der Generalisierung gleichartige Entitytypen strukturiert, werden bei der Aggregation unterschiedliche Entitytypen, die in ihrer Gesamtheit einen strukturierten Objekttypen bilden, einander zugeordnet. In dieser Hinsicht kann man die Aggregation als einen besonderen Erstellt aus den einzelnen Dokumenten von den Studenten Seite 7 Zusammenfassung Datenmanagement Beziehungstyp deuten, der einem übergeordneten Entitytyp mehrere untergeordnete Entitytypen zuordnet. Diese Beziehung wird als Teil‐von (part‐of) bezeichnet. 1.6 Sie kennen das Konzept von sichten und mögliche Schwierigkeiten bei der Sichtenintegration Eine View (deutsch Sicht) ist eine logische Relation (auch virtuelle Relation oder virtuelle Tabelle) in einem Datenbanksystem. Diese logische Relation wird über eine im Datenbankmanagementsystem (DBMS) gespeicherte Abfrage definiert. Der Datenbankbenutzer kann eine View wie eine normale Tabelle abfragen. Wann immer eine Abfrage diese View benutzt, wird diese zuvor durch das Datenbankmanagementsystem berechnet. Eine View stellt im Wesentlichen einen Alias für eine Abfrage dar. Die Aufgabe einer View ist es, den Zugriff auf das Datenbankschema zu vereinfachen. Normalisierte Datenbankschemata verteilen Daten auf zahlreiche Tabellen mit komplexen Abhängigkeiten. Dies führt zu aufwändigen SQL‐Abfragen. Außerdem wird ein hohes Maß an Wissen über das Schema vorausgesetzt, um solche Abfragen zu erstellen. Das Bereitstellen geeigneter Views erlaubt einen einfachen Zugriff, ohne Kenntnis des darunter liegenden Schemas und ohne Aufweichung der Normalisierung. Ein weiterer Vorteil von Views ist, dass das DBMS keinen zusätzlichen Aufwand zur Vorbereitung der Abfrage benötigt. Die View‐Abfrage ist vom Parser bereits bei der Erstellung syntaktisch zerlegt und vom Abfrageoptimierer vereinfacht. Ein Nachteil von Views kann sein, dass die Komplexität der dahinter liegenden Abfrage unterschätzt wird. Der Aufruf einer View kann zu sehr aufwändigen Abfragen führen und der unbedachte Einsatz solcher dann zu erheblichen Performanzproblemen. Probleme bei der Sichtenintegration: •
•
•
•
•
Namenskonflikt Typkonflikt Wertebereichskonflikt Bedingungskonflikt Strukturkonflikt 1.7 Sie können für ein gegebenes ERM ein relationales Schema definieren Das Entity‐Relationship Modell besitzt zwei grundlegende Strukturierungskonzepte: •
Entitytypen •
Beziehungstypen Dem steht im relationalen Modell nur ein einziges Strukturierungskonzept – nämlich die Relation – gegenüber. Es werden also sowohl Entitytypen als auch Beziehungstypen jeweils auf die Relation abgebildet. Erstellt aus den einzelnen Dokumenten von den Studenten Seite 8 Zusammenfassung Datenmanagement 1.7.1 rundlagen des relationalen Modells • Ausprägung: der aktuelle Zustand der Datenbasis •
Schlüssel: minimale Menge von Attributen, deren Werte ein Tupel eindeutig identifizieren •
Primärschlüssel: wird unterstrichen o Einer der Schlüsselkandidaten wird als Primärschlüssel Ausgewählt o Hat eine besondere Bedeutung bei der Referenzierung von Tupeln hören: {[MatrNr: integer, VorlNr: integer]}
lesen: {[PersNr: integer, VorlNr: integer]}
arbeitenFür: {[AssistentenPersNr: integer, ProfPersNr: integer]}
voraussetzen: {[Vorgänger: integer, Nachfolger: integer]}
prüfen: {[MatrNr: integer, VorlNr: integer, PersNr: integer, Note:
decimal]}
1.7.2 Verfeinerung des relationalen Schemas 1:N‐Beziehung Initial‐Entwurf Vorlesungen : <pre>{[VorlNr, Titel, SWS]}
Professoren : {[PersNr, Name, Rang, Raum]}
lesen: {[VorlNr, PersNr]}</pre>
Verfeinerung durch Zusammenfassung Vorlesungen : {[VorlNr, Titel, SWS, gelesenVon]}
Professoren : {[PersNr, Name, Rang, Raum]}
Regel Relationen mit gleichem Schlüssel kann man zusammenfassen aber
nur diese und keine anderen!
Hierbei verwenden Sie ausschliesslich die Notationen unseres Buches!! None: DMGModellieren erstellt durch tamazena Erstellt aus den einzelnen Dokumenten von den Studenten Seite 9 Zusammenfassung Datenmanagement 2. Sie kennen die Entwurfstheorie und Normalformen 2.1 Sie kennen den Begriff der funktionalen Abhängigkeit und können funktionale Abhängigkeiten identifizieren Eine Relation wird durch Attribute definiert. Bestimmen einige dieser Attribute eindeutig die Werte anderer Attribute, so spricht man von funktionaler Abhängigkeit. So könnte man sich etwa eine Kundendatenbank vorstellen, in der die Adresse und die Telefonnummer eines Kunden eindeutig durch seinen Namen zusammen mit seinem Geburtsdatum bestimmt ist. Hier wären also Adresse und Telefonnummer funktional abhängig von Name und Geburtsdatum Kunden Name Geburtsdatum Adresse Telefon# Mit Hilfe funktionaler Abhängigkeiten lässt sich auch der Begriff Schlüssel definieren: 2.2 Sie kennen die Definition eines Schlüssels und können Schlüsselkandidaten identifizieren In Relationalen Datenbanken unterscheidet man die Schlüsselbegriffe Superschlüssel: Menge von Attributen (Spalten) in einer Relation (Tabelle), die ein Tupel (Zeile) in dieser Relation eindeutig identifizieren. Ein trivialer Superschlüssel wäre zum Beispiel die Menge aller Attribute einer Relation. Schlüsselkandidat (auch Kandidatenschlüssel genannt): Eine Teilmenge des Superschlüssels, die aber auch schon die eindeutige Identifizierung eines Tupels ermöglicht (Schlüsselkandidaten Superschlüssel). Primärschlüssel: Ein ausgewählter Schlüsselkandidat, der von anderen Relationen als das identifizierende Attribut verwendet wird. Sekundärschlüssel: Alle anderen Schlüsselkandidaten, die nicht Primärschlüssel sind. Fremdschlüssel: Ein Attribut einer Relation, welches auf einen Primärschlüssel einer anderen Relation verweist. Formale Definition Es sei ein bestimmtes Relationenschema R (das Tabellen‐Gerüst, d.h. alle Spalten) gegeben. Eine Teilmenge S der Attribute des Schemas R heißt Schlüssel, wenn gilt: Eindeutigkeit: Keine Ausprägung von R (keiner der Einträge in die Tabelle) darf zwei verschiedene Tupel (Zeilen) enthalten, bei denen die Werte von S gleich sind. Minimalität: Keine echte Teilmenge von S erfüllt bereits die Bedingung der Eindeutigkeit. Erstellt aus den einzelnen Dokumenten von den Studenten Seite 10 Zusammenfassung Datenmanagement ISBN Autor Titel 666 Dr. Luzi Fehr Rebell 1337 Elise Meier Hax0r 17235 Prof. Wilson Iluminatus Hier ist der Schlüssel ein einzelnes Attribut. Die ISBN eignet sich dafür relativ gut, denn zumindest innerhalb eines Verlages haben keine zwei Bücher die selbe ISBN. Bücher können allerdings sehr wohl den gleichen Titel haben oder vom selben Autor stammen Kunden Name Geburtstag Wohnort Meier 01.01.67 Musterhausen Müller 02.05.80 Lutown ... ... ... Hier wird ein Teil der Attribute als Schlüssel verwendet. Diese Kundendatenbank geht davon aus, dass keine zwei Kunden mit dem selben Namen am gleichen Tag Geburtstag haben; eine Annahme, die in der Realität leicht nach hinten losgehen könnte. 2.3 Sie kennen die Definition der Boyce Codd Normalform (BCNF) Eine Relation ist in BCNF, wenn sie die Voraussetzungen der 3.Normalform erfüllt und gleichzeitig jede Determinante (Menge von Attributen, von denen andere voll funktional abhängen) Schlüsselkandidat ist. Normalisierung Walkthrough 2.4 Sie können entscheiden, ob ein relationales Modell in der BCNF ist 1. Beispiel: jeder Verein bietet nur eine Sportart an. ein Sportler kann in verschiedenen Vereinen spielen, aber nur, wenn diese Vereine unterschiedliche Sportarten betreiben. Damit wird sichergestellt, dass der Sportler nie gegen einen Verein spielt, in dem er selbst Mitglied ist. Sportler Name Sportart Verein Müller Fussball FCL Meier Fussball FCL Erstellt aus den einzelnen Dokumenten von den Studenten Seite 11 Zusammenfassung Datenmanagement Meier Eishockey HCL Verletzung der BCNF Aus den oben genannten Bedingungen folgt, dass das Attribut Sportart funktional abhängig vom Attribut Verein ist, d. h. Verein ist eine Determinante. Jedoch ist Verein KEIN Schlüsselkandidat. Durch diese Konstellation ist die Relation nur in 3NF, nicht in BCNF. 2. Beispiel aus dem formativen Test: In die Tabelle Rechnungsposition kommt zusätzlich das Attribut Frankenwert ‐ mit genau der Bedeutung wie Taxpunkt: Rechnungsposition Rechnung PositionsNr Datum AnzahlTaxPunkte Taxpunkt Frankenwert Diagnose Verletzung der BCNF Frankenwert ist funktional abhänging von Taxpunkt, Taxpunkt hat jedoch (in dieser Tabelle) KEINE Schlüsseleigenschaft. None: DMGEntwurfNormal erstellt durch tabachman Erstellt aus den einzelnen Dokumenten von den Studenten Seite 12 Zusammenfassung Datenmanagement 3. Sie kennen die relationale Algebra 3.1 Operationen 3.1.1 Kreuzprodukt ‐> Wie die Hippies: Jeder mit jedem Beispiel: R × S:
R: A B C D 1 2 3 4 4 5 6 7 7 8 9 0 A B C D E F G
1 2 3 4 1 2 3
S: 4 5 6 7 1 2 3
7 8 9 0 1 2 3
E F G
1 2 3 4 7 8 9
1 2 3
4 5 6 7 7 8 9
7 8 9
7 8 9 0 7 8 9
3.1.2 Vereinigung Alle zusammen. Zwei Mengen werden zusammengefügt. Jedes Element kann nur einmal vorkommen. Beispiel: R A 1 4 B 2 5 C 3 6 S A 7 4 B
8
5
C
9
6
R u S A
7
4
1
B 8 5 2 C
9
6
3
3.1.3 Differenz Menge jener Elemente welcher in der Ersten Relation vorhanden sind, jedoch nicht in der zweiten. Beispiel: R A 1 4 B 2 5 C 3 6 S A 7 4 B
8
5
C
9
6
R \ S A
1
B 2 C
3
3.1.4 Durchschnitt Menge aller Tupel welche in beiden Relationen vorkommen. Erstellt aus den einzelnen Dokumenten von den Studenten Seite 13 Zusammenfassung Datenmanagement Beispiel: R A 1 4 B 2 5 S A 7 4 C 3 6 B
8
5
R ∩ S A
4
C
9
6
B 5 C
6
3.1.5 Division Die Division ist eine Umkehrung des Kreuzproduktes Beispiel: R A a1 a1 a1 a2 a2 S
B
b1
b2
B b1 b2 b3 b2 b3 R ÷ S A a1 3.1.6 Projektion Die Projektion extrahiert einzelne Attribute aus einer Attributmenge. Sie ist mit dem „Select a,b,c“ in SQL zu vergleichen. Wobei a,b und c für die Attribute stehen, welche extrahiert werden sollen. SQL ‐ Algebra select Name from Professoren ‐> II(Name) (Professoren) 3.1.7 Selection Die Selection selektiert eine gewisse Auswahl von Tupeln. Sie ist mit dem „where“ in SQL zu vergleichen. SQL ‐ Algebra select * from Professoren where Name = „Sokrates“ ‐> σ Name=Sokrates(Professoren) 3.1.8 Umbenennung Durch diese Operation können Attribute und Relationen umbenannt werden. Beispiel voraussetzen in v1 umbenennen: V1(voraussetzen) Erstellt aus den einzelnen Dokumenten von den Studenten Seite 14 Zusammenfassung Datenmanagement 3.1.9 Natural Join Beim natural Join werden aus zwei Relationen eine neue gebildet. Es muss eine gleiche Spalte vorhanden sein. Falls das Schlüsselattribute nur in einer Tabelle vorkommt, wird die entsprechende Spalte ausgeblendet. Beispiel R A B 1 2 4 5 7 8 C 3 6 9 D 4 7 0 S A 1 7 F
2
8
G
3
9
R A
1
7
S B
2
8
C
3
9
D 4 0 F 2 8 G
3
9
3.1.10 (full) outer join Eine Kombination von Left Outer Join und Right Outer Join. R S Beispiel R S A B B C
1 2 3 4
2 3 4 5
R A
1
2
‐
S B 2 3 4 C ‐ 4 5 3.1.11 Left outer join Mit einem Left Join wird eine sogenannte linke Inklusionsverknüpfung erstellen. Linke Inklusionsverknüpfungen schließen alle Datensätze aus der ersten (linken) Tabelle ein, auch wenn keine entsprechenden Werte für Datensätze in der zweiten Tabelle existiert. S R Beispiel R S S R A 1 2 B 2 3 B 3 4 C
4
5
A
1
2
B 2 3 C ‐ 4 3.1.12 Right outer join Mit einem Right Join wird eine sogenannte rechte Inklusionsverknüpfung erstellen. Rechte Inklusionsverknüpfungen schließen alle Datensätze aus der zweiten (rechten) Tabelle ein, auch wenn keine entsprechenden Werte für Datensätze in der ersten Tabelle existiert. S R Beispiel R A 1 2 B 2 3 S B 3 4 C
4
5
Erstellt aus den einzelnen Dokumenten von den Studenten R A
2
‐
S B 3 4 C 4 5 Seite 15 Zusammenfassung Datenmanagement 3.1.13 Conditional join Beim Conditional join wird zuerst das Kreuzprodukt gebildet und danach selektiert. Beispiel: S A 1 4 7 R C 4 1 6 B 2 5 8 D 8 9 5 S A
1
4
A = C R B
2
5
C
1
4
D 9 8 3.2. Baumstruktur / Query tree Bei der Baumdarstellung ist am besten von innen nach aussen, bzw. von oben nach unten vorzugehen. Beispiel (Takes Course)))) IIname, SID (σ Name=“DMG“(Students (in SQL: select name, SID from Course join Takes join Students where Name = “DMG”) IIname, SID σ Name=“DMG“ Students Course Takes 3.3. Darstellung von Relationen Eine Relation lässt sich durch einen gerichteten Graphen (DiGraph) darstellen. Beispiel: DiGraph von R auf A = {a, b, c, d} R = {(a, a), (a, c), (b ,a) ,(b, c) (b, d), (c, a), (c, b), (d, a)} Erstellt aus den einzelnen Dokumenten von den Studenten Seite 16 Zusammenfassung Datenmanagement Weisheiten bezüglich Digraphen: 3.4. Äquivalenzrelationen Eine Relation R auf einer Menge A heist Äquivalenzrelation falls sie relfexiv, symmetrisch und transitive ist. Regeln bei Äquivalenzrelationen: jeder Knoten hat eine Schleife (Reflexivität) gibt es eine gerichtete Kante von a nach b, dann muss es auch eine von b nach a geben (Symmetrie) gibt es eine gerichtete Kante von a nach b und eine weitere von b nach c, dann muss es auch eine von a nach c geben (Transitivität) Beispiel Rechnungen Aufgabe: Definieren sie auf der Menge A = {1, 2 ,3 ,4} eine Äquzivalenzrelation und zeichnen sie den Digraphen. Lösung: Damit die Relation refexiv ist, muss in R sicher vorkommen: (1,1),(2,2),(3,3),(4,4) Damit die Relation symmetrisch ist muss sicher vorkommen: (1,2),(2,1),(3,2)(3,2) Damit die Relation transitiv ist muss sicher noch vorkommen: (1,3) und wegen der Symetrie noch (3,1) Erstellt aus den einzelnen Dokumenten von den Studenten Seite 17 Zusammenfassung Datenmanagement Somit: R = {(1,1),(2,2),(3,3),(4,4),(1,2),(2,3),(2,1),(3,2),(1,3),(3,1)} N‐Stellige Relationen Eine n.stellige Relation R auf den Mengen A1, A2 ,A3, …, An ist eine Teilmenge des Kreuzproduktes A1 x A2 x … x An. None: DMGSQL erstellt durch taberli Erstellt aus den einzelnen Dokumenten von den Studenten Seite 18 Zusammenfassung Datenmanagement 4. Sie kennen SQL Die hier aufgeführte SQL Befehle sind in der MS SQL Syntax verfasst. Es gibt kein Gewähr dafür, dass die SQL‐
Statements auch unter anderen Datenbanken wie z.B. PostreSQL, MySQL usw. ausgeführt werden können. 4.1 Sie können ein relationales Schema in SQL definieren Datenbank erstellen Datenbank auswählen CREATE DATABASE sxx_db
USE sxx_db Tabelle erstellen CREATE TABLE tbl_Tabelle1 (
id INTEGER NOT NULL IDENTITY(1,1),
id2 CHAR(x) NOT NULL, PRIMARY KEY (id), FOREIGN KEY (id2) REFERENCES tbl_Tabelle2(id2), name VARCHAR(x) DEFAULT "Müller", vorname VARCHAR(x), datum DATE); x für eine beliebige Zahl Primärschlüsseldefinition Fremdschlüsseldefinition Default ‐> Standartwert Einschränkungen Einschränkungskriterium ‐> CREATE TABLE tbl_Tabelle2( CONSTRAINT ck_feld2 CHECK (feld2 LIKE '[A‐Z][A‐Z]‐[0‐9][0‐9][0‐9][AP]' OR feld2 LIKE '[A‐Z]‐[A‐Z][0‐9][0‐9][0‐9][AP]' )); In diesem Beispiel wird geprüft, ob das Feld feld2 zu Beginn 2 Zeichen A‐Z, gefolgt von 3 nummerischen Werten und ein 'A' oder 'P' am Schluss enthält. 4.2 Sie können das Schema verändern Tabellen änderungen beginnen mit ALTER TABLE tbl_Tabelle1 ‐ weitere Spalte einfügen ‐ Spalteneigenschaften ändern ‐ Spalte löschen ADD spalte1 CHAR(12) NULL ALTER COLUMN spalte1 CHAR(30) NOT NULL DROP COLUMN spalte1 ‐ Einschränkungen einfügen ‐ Primärschlüssel definieren ‐ Fremdschlüssel definieren ADD CONSTRAINT ck_feld3 CHECK (…. ADD PRIMARY KEY (spalte3) ADD FOREIGN KEY (spalte4) ‐ CONSTRAINT löschen DROP CONSTRAINT ck_feld3 #Name unbedingt angeben!! 4.3 Sie können einfache Abfragen formulieren 1. SELECT ALL, zeigt mehrere identische Datens. SELECT [ ALL | DISTINCT ] spalte1, spalte2, … FROM tabelle DISTINCT, zeigt alle vorkommende Erstellt aus den einzelnen Dokumenten von den Studenten Seite 19 Zusammenfassung Datenmanagement Datensätze 1 x an (im Access: Summe) Virtueller Spalten Zählfunktion (mehrere Möglichkeiten) Summe der Werte einer Spalte Durchschnittswerter einer Spalte Kleinster Wert einer Spalte Grösser Wert einer Spalte SELECT wert1, wert2, wert1‐wert2 AS zwischenwert FROM tabelle SELECT COUNT ( * | spaltex | DISTINCT ) AS anzahlx FROM … SELECT SUM(…) AS summe … SELECT AVG(…) AS durchschnitt … SELECT MIN(…) AS minimum … SELECT MAX(…) AS maximum … 2. FROM Verknüpfte Tabellen SELECT a.spalte1, a.spalte2, b.spalte1, c.spalte1 FROM tbla AS a INNER JOIN ( tblb AS b INNER JOIN tblc AS c ON b.id = c.id) ON a.id = b.id AND a.spalte3 > 10; (mit 3 Tabellen) zeigt alle Felder der linken Tabelle SELECT a.spalte1, b.spalte2 FROM tbla AS a LEFT JOIN tblb AS b ON a.id = b.id (Felder ohne beziehung sind NULL) zeigt alle Felder der rechten Tabelle SELECT a.spalte1, b.spalte2 FROM tbla AS a RIGHT JOIN … zeigt alle Felder der Tabellen an SELECT a.spalte1, b.spalte2 FROM tbla AS a FULL JOIN … zeigt alle Felder(‐kombinationen) an SELECT a.sp1, b.sp1 FROM tbla AS a CROSS JOIN tblb AS b; 3. WHERE Einschränkung SELECT * FROM tabelle WHERE spalte1 = 'eingabe' Statt = kann man auch ‐‐> verwenden ,!= ; > ; >= ; < ; <= ; !> (nicht grösser) ; <! (nicht kleiner) ; Allgemeine Suche (Alle Datensätze, die mit "A" beginnen) SELECT * FROM tbl WHERE spalte1 LIKE 'A%' Suche von mehreren Konstanten oder auch möglich SELECT * FROM tbl WHERE spalte1 IN ('ja', 'vielleicht') SELECT * FROM tbl WHERE spalte1 NOT IN ('ja', 'vielleicht') Suche von Zwischenwerte SELECT * FROM tbl WHERE preise BETWEEN 10 AND 10000 % = + alle nachfolgende Zeichen oder Null, 4. GROUP BY Nach definierten Gruppen sortieren und gewünschten Wert anzeigen zeigt in diesem Bps. wie viele Mitglieder von welchem Ort stammen. oder zeigt in diesem Bps. wieviel mal ein Artikel bestell worden ist SELECT ort, count(*) FROM mitglieder GROUP BY ort; SELECT artikel, SUM(menge) FROM bestellung GROUP BY artikel Erstellt aus den einzelnen Dokumenten von den Studenten Seite 20 Zusammenfassung Datenmanagement 5. HAVING Selection der GROUP BY‐Klausel SELECT ort, count(*) FROM mitglieder GROUP BY ort HAVING SUM(einzahlung) > 10; 6. ORDER BY einfache Sortierung ASC = A ‐ Z bzw. 0 ‐ 9 DESC = Z ‐ A bzw. 9 ‐ 0 SELECT * FROM tbl ORDER BY name ASC, vname DESC 4.4 Sie können Abfragen mit mehreren Relationen formulieren. Liste die Namen der Studenten mit ihren Vorlesungstiteln: select Name, Titel
from
Studenten, hoeren, Vorlesungen
where
Studenten.MatrNr = hoeren.MatrNr
and
hoeren.VorlNr
= Vorlesungen.VorlNr;
alternativ:
select s.Name, v.Titel
from
Studenten s, hoeren h, Vorlesungen v
where
s.MatrNr = h.MatrNr
and
h.VorlNr = v.VorlNr;
Quelle: http://www‐lehre.informatik.uni‐osnabrueck.de/~dbs/2001/skript/node55.html 4.5 Sie können Mengenoperationen und geschachtelte Anweisungen formulieren 1. Liste alle Prüfungen, die als Ergebnis die schlechteste Note haben:
2.
3.
select *
from
pruefen
where Note = (select min(Note) from pruefen);
4. Liste alle Studenten, die älter sind als der jüngste Professor:
5.
6.
7.
8.
9.
select s.*
from
Studenten s
where exists (select p.*
from Professoren p
where p.GebDatum > s.GebDatum);
o Alternativ:
10. select s.*
11. from
Studenten s
12. where s.GebDatum < (select max(p.GebDatum)
from Professoren p );
Quelle: http://www‐lehre.informatik.uni‐osnabrueck.de/~dbs/2001/skript/node55.html 4.6 Sie kennen die Aggregatfunktionen und Gruppierungen 1. Liste Geburtstage der Gehaltsklassenältesten (ohne Namen !):
Erstellt aus den einzelnen Dokumenten von den Studenten Seite 21 Zusammenfassung Datenmanagement 2.
3.
4.
select
Rang, max(GebDatum) as Ältester
from
Professoren
group by Rang;
5. Liste Summe der SWS pro Professor:
6.
7.
select
gelesenVon as PersNr, sum(SWS) as Lehrbelastung
from
Vorlesungen
group by gelesenVon;
Quelle: http://www‐lehre.informatik.uni‐osnabrueck.de/~dbs/2001/skript/node55.html 4.7 Sie kennen den exists Operator 1. Liste alle Professoren, die keine Vorlesung halten:
2.
3.
4.
5.
6.
7.
8.
select Name
from
Professoren
where PersNr not in ( select gelesenVon from Vorlesungen );
o Alternativ:
select Name
from
Professoren
where not exists ( select *
from Vorlesungen
where gelesenVon = PersNr );
9. Liste solche Studenten, die alle 4-stündigen Vorlesungen hören:
10. select s.*
11. from
Studenten s
12. where not exists
13.
(select *
14.
from Vorlesungen v
15.
where v.SWS = 4 and not exists
16.
(select *
17.
from hoeren h
18.
where h.VorlNr = v.VorlNr and h.MatrNr = s.MatrNr
19.
)
);
Quelle: http://www‐lehre.informatik.uni‐osnabrueck.de/~dbs/2001/skript/node55.html 4.8 Sie kennen die Problematik der Null­Werte Das Problem mit NULL‐Werten ist, dass diese keinen, nicht mal einen leeren Wert, darstellen. NULL‐Werte müssen immer separate abgefragt und geprüft werden. Liste Namen und Studiendauer in Jahren von allen Studenten: select Name, Semester/2 as Studienjahr
from
Studenten
where Semester is not null;
Quelle: http://www‐lehre.informatik.uni‐osnabrueck.de/~dbs/2001/skript/node55.html 4.9 Sie können Abfragen mit joins formulieren 1. Liste Studenten mit ihren Vorlesungen (mithilfe von join):
Erstellt aus den einzelnen Dokumenten von den Studenten Seite 22 Zusammenfassung Datenmanagement 2.
3.
4.
5.
select s.name, v.titel
from
studenten s
inner join hoeren h
on (s.matrnr=h.matrnr)
inner join vorlesungen v on (h.vorlnr = v.vorlnr);
Quelle: http://www‐lehre.informatik.uni‐osnabrueck.de/~dbs/2001/skript/node55.html 1. Liste aller Studenten mit den Vorlesungsinformationen. Studenten ohne
eingeschriebenen Vorlesungen werden ebenfalls angezeigt.
2.
3.
SELECT s.MatrNr, s.[Name], v.VorlNr, v.Titel FROM Studenten s
LEFT JOIN hoeren h ON s.MatrNr = h.MatrNr
INNER JOIN Vorlesungen v ON h.VorlNr = v.VorlNr;
4.10 Sie kennen die Befehle insert, delete und update 1. Füge neue Vorlesung mit einigen Angaben ein:
2.
3.
insert into Vorlesungen (VorlNr, Titel, gelesenVon)
values (4711,'Selber Atmen', 2125)
4. Schicke alle Studenten in die Vorlesung Selber Atmen:
5.
6.
7.
8.
insert
select
from
where
into hoeren
MatrNr, VorlNr
Studenten, Vorlesungen
Titel = 'Selber Atmen'
9. Erweitere die neue Vorlesung um ihre Semesterwochenstundenzahl:
10. update vorlesungen
11. set
SWS=6
12. where Titel='Selber Atmen'
13. Entferne alle Studenten aus der Vorlesung Selber Atmen:
14. delete from hoeren
15. where vorlnr =
16.
(select VorlNr from Vorlesungen
17.
where Titel = 'Selber Atmen')
18. Entferne die Vorlesung Selber Atmen:
19. delete from Vorlesungen
where titel = 'Selber Atmen'
Quelle: http://www‐lehre.inf.uos.de/~dbs/2001/skript/node56.html 4.11 Sie können Sichten erstellen und nutzen 1. Lege Sicht an für Prüfungen ohne Note:
2.
3.
4.
create view pruefenSicht as
select MatrNr, VorlNr, PersNr
from
pruefen
5. Lege Sicht an für Studenten mit ihren Professoren:
6.
7.
8.
9.
10.
11.
create
select
from
where
and
and
view StudProf (Sname, Semester, Titel, PName) as
s.Name, s.Semester, v.Titel, p.Name
Studenten s, hoeren h, Vorlesungen v, Professoren p
s.MatrNr
= h.MatrNr
h.VorlNr
= v.VorlNr
v.gelesenVon = p.PersNr
12. Lege Sicht an mit Professoren und ihren Durchschnittsnoten:
13. create
14. select
view ProfNote (PersNr, Durchschnittsnote) as
PersNr, avg (Note)
Erstellt aus den einzelnen Dokumenten von den Studenten Seite 23 Zusammenfassung Datenmanagement 15. from
pruefen
16. group by PersNr
17. Entferne die Sichten wieder:
18. drop view PruefenSicht
19. drop view StudProf
drop view ProfNote
Quelle: http://www‐lehre.inf.uos.de/~dbs/2001/skript/node57.html 4.12 Sie kennen die Problematik in Bezug auf Sichten Je mehr Tabellenrelationen eine Sicht enthält, umso länger braucht eine Sicht um die angefordeten Daten bereit zu stellen. Sollte die Aufbereitung zu lange dauern, kann sich der geschickte Einsatz von Indezies lohnen. Allerdings muss man dabei beachten, dass dadurch Systemressourcen in Anspruch genommen werden. None: DMGSQL erstellt durch tamarkov Erstellt aus den einzelnen Dokumenten von den Studenten Seite 24 Zusammenfassung Datenmanagement 5. Sie kennen JDBC 5.1 Sie können in Java den Zugriff auf Datenbanken mittels JDBC programmieren Die JDBC‐Schnittstelle ist im Package java.sql definiert, welches importiert werden muss. Nun muss der/die notwendige/n JDBC‐Treiber geladen werden, damit der DriverManager diesen für die Verbindung verwenden kann. Dafür ist der Java Ausdruck: Class.forName("Treiber-Name");
zuständig. Nun kann man eine Connection aufbauen. Dafür werden dem DriverManager über die Methode getConnection() die nötigen Informationen mitgeteilt, damit dieser eine Verbindung aufbauen kann. Z.B.: Connection conn =
DriverManager.getConnection("jdbc:sqlserver://localhost\\SqlExpress;
database=dbname","username", "password");
Damit nun SQL‐Ausdrücke an die Datenbank abgesetzt werden können, muss man ein Statement‐
Objekt generieren. Dafür ist die Methode createStatement() in der Klasse Statement zuständig. Also lautet die Anweisung meist: Statement stmt = conn.createStatement();
SQL‐Anfragen können nun über die Methoden executeQuery() und Änderungsoperationen über executeUpdate() abgesetzt werden. Um das/die Resultat/e später verwenden zu können, muss ein Objekt der Klasse ResultSet erzeugt werden und darin die Ergebnisse gespeicht. Also z.B.: ResultSet rs = stmt.executeQuery("SELECT * FROM tabelle");
5.2 Sie kennen dafür die Klassen Connection, Statement, ResultSet 5.2.1 Klasse Connection Wichtig ist vor allem die Methode createStatement(). Diese ermöglicht es, über SQL‐Statements mit der Datenbank zu "sprechen". 5.2.2 Klasse Statement Die Klasse Statement erwartet zuerst ein durch die Connection‐Klasse erzeugtes Statement‐Objekt, damit sie überhaupt weiss, wohin die Anfrage oder Änderungsoperation gehen muss. Dies passiert ja über: Statement sql_stmt = conn.createStatement();
Es gibt zwei wichtige Methoden in der Klasse Statement: 1. executeQuery() um SQL‐Abfragen abzusetzen. Diese müssen als String in der Klammer übergeben werden. Erstellt aus den einzelnen Dokumenten von den Studenten Seite 25 Zusammenfassung Datenmanagement 2. executeUpdate um Änderungsoperationen an der Datenbank durchzuführen. Auch diese Methode erwartet einen String. 5.2.3 Klasse ResultSet Diese Klasse stellt eine Iterator‐Schnittstelle für den Zugriff auf eine Menge von Ergebnistupeln einer SQL‐Anfrage zur Verfügung. Zuerst muss eine ResultSet Variable initialisiert werden, in welche dann die Ergebnisse einer SQL‐
Anfrage gespeichert werden. Also z.B.: ResultSet rset = sql_stmt.executeQuery("Das SQL Statement als String!"); Um festzustellen, ob es ein nächstes Tupel gibt, kann die next()‐Methode auf dei ResulSet Variablen verwendet werden, welche einen boolean‐Wert zurückliefert. Weiter gibt es Methoden, welche einen Wert aus einer Spalte zurückgeben. Dabei muss der Datentyp beachtet werden! Z.B.: rset.next(); ‐ Um den Namen (welcher in der Datenbank als varchar abgespeichert ist) in der Spalte "Name" zu erhalten, muss folgende Zeile Programmiert werden (als ResultSet Variable rset): rset.getString("Name"); . Es kann auch der Spaltenindex als Integer verwendet werden. Wichtig ist, dass das Wert in der Tabelle der ausgelesen werden soll, mit dem erwarteten Wert der Methode stimmt. None: DMGJDBC erstellt durch tarutsch Erstellt aus den einzelnen Dokumenten von den Studenten Seite 26 Zusammenfassung Datenmanagement 6. Sie kennen das Konzept der referentiellen Integrität und können es anwenden 6.1 Sie kennen den Begriff der referentiellen Integrität Die referenzielle Integrität ist eine Form der Datenintegrität. Unter der referenziellen Integrität versteht man die Integrität auf Beziehungsebene. Neben der referenziellen Integrität unterscheidet man noch die Wertebereichsintegrität (Integrität auf Datenfeldebene) und die Datenintegrität auf Datensatzebene Die referenzielle Integrität befasst sich mit der Korrektheit zwischen Attributen von Relationen und der Erhaltung der Eindeutigkeit ihrer Schlüssel. Datenintegrität • Integitätsbedingungen o Schlüssel o Beziehungskardinalitäten o Attributdomänen o Inklusion bei Generalisierung • statische Integritätsbedingungen o Bedingungen an den Zustand der Datenbasis • dynamische Integritätsbedingungen o Bedingungen an Zustandsübergänge Referentielle Integrität Fremdschlüssel Weisen auf Tupel einer Relation Bei gelesenVon in Vorlesungen verweist auf Tupel in Professoren referentielle Integrität Fremdschlüssel müssen auf existierende Tupel verweisen oder einen Nullwert enthalten Die referenzielle Integrität sorgt für die Datenkonsistenz, wenn die Daten bearbeitet werden. Ein Beispiel: Angenommen wir haben ein Kochbuch als Datenbank umgesetzt und dort haben wir Kategorien und Rezepte. Es gilt die Bedingung dass jedes Rezept zu einer Kategorie gehört. Nun muss also sichergestellt werden, wenn z.B. eine Kategorie gelöscht wird, dass dann auch alle Rezepte gelöscht werden, da es sonst Rezepte gäbe die auf eine Kategorie verweiden, die es nicht mehr gibt. Diesen Vorgang kann manuell gemacht werden über die Software die Zugriff auf die Datenbank macht. Dies ist aber sehr aufwändig und nicht immer ganz einfach. Darum haben moderne Datenbanken die Fähigkeit diese Konsistenz intern über referenzielle Integritäten zu wahren. In unserem Beispiel müsste bei der Kategorien Tabelle ein on delete cascade angewendet werden, dies würde dafür sorgen dass die Rezepte, die auf die Kategorie verweisen, alle gelöscht werden wenn eine Kategorie gelöscht wird. Natürlich müssen auch die Fremdschlüssel vorhanden sein (KatID in der Tabelle Rezepte) damit die Datenbank überhaupt weiss welche Rezepte zu welcher Kategorie gehören. 6.2 Sie können statische Integritätsbedingungen formulieren Datenfeldebene • Wertebereichseinschränkungen o check Semester between 1 and 13 • Aufzählungstypen o check Rang in (C2´, C3´, `C4´) ... Erstellt aus den einzelnen Dokumenten von den Studenten Seite 27 Zusammenfassung Datenmanagement Beziehungsebene * Default: Zurückweisen der Änderungsoperation • Propagieren der Änderungen: cascade • erweise auf Nullwert setzen: set null 6.3 Sie können Integritätsbedingungen in SQL formulieren. Einige Beispiele Erstellt aus den einzelnen Dokumenten von den Studenten Seite 28 Zusammenfassung Datenmanagement Erstellt aus den einzelnen Dokumenten von den Studenten Seite 29 Zusammenfassung Datenmanagement 6.4 Sie kennen den Begriff der Trigger und können einfache Trigger implementieren Trigger kommen zum Einsatz, wenn die Funktion referentiellen Integrität nicht mehr ausreichen oder wenn bewusst bestimmte Aktionen ausgefürht werden müssen, wenn ein Ereigniss eintrifft. Weitere Infos über Trigger findet ihr au fer Seite 163 im Buch (Kapitel 5.7) Wie ist ein Trigger aufgebaut? Beispiel Code eines Triggers Erstellt aus den einzelnen Dokumenten von den Studenten Seite 30 Zusammenfassung Datenmanagement Ein weiteres Beispiel -- Triggerbeispiel für PostgreSQL (zwangsläufig mit Funktion):
create table logInfo(persNr int, zeitstempel timestamp default
current_timestamp,
benutzer varchar(20) default user,
nameAlt varchar(50), nameNeu varchar(50),
rangAlt varchar(2), rangNeu varchar(2));
CREATE OR REPLACE FUNCTION logAndReset()
RETURNS trigger AS
$$ BEGIN
insert into loginfo(persnr,nameAlt,nameNeu,rangAlt,rangNeu)
values(new.persnr,old.name,new.name,old.rang,new.rang);
if old.Rang = 'C3' and new.Rang = 'C2' then
new.Rang := 'C3';
end if;
if old.Rang = 'C4' then
new.Rang := 'C4';
end if;
if new.Rang is null then
new.Rang := old.Rang;
end if;
return new;
-- return null würde alles beim alten lassen!!
END;
$$ LANGUAGE 'plpgsql';
CREATE TRIGGER ins_prof
BEFORE update -- AFTER wäre falsch!!
ON professoren
FOR EACH ROW
EXECUTE PROCEDURE mylog();
-- zum Testen wie oben (jedes Statement einzeln ausführen!):
update professoren set rang='C2'
Erstellt aus den einzelnen Dokumenten von den Studenten Seite 31 Zusammenfassung Datenmanagement select * from professoren
select * from logInfo
None: DMGrefInt erstellt durch taroeoes 7. Physische Datenorganisation Bedeutung der Physischen Datenorganisation Bei Datenbanken ist es wichtig wo und wie Daten abgelegt sind. Die Unterschiede der Zugriffszeiten z.B. zwischen Hauptspeicher und Festspeicher ist enorm. Somit ist das richtige Management dieser Daten wichtig. Weitere Informationen darüber. (Speichermedien usw.) findet man im Buch ab s. 199 B – Bäume Ein B‐Baum ist immer ein balancierter Suchbaum. Erstellt aus den einzelnen Dokumenten von den Studenten Seite 32 Zusammenfassung Datenmanagement B+ ­ Baum Der B+‐Baum ist eine Erweiterung des B‐Baumes. Bei einem B+‐Baum werden die eigentlichen Datenelemente nur in den Blattknoten gespeichert, während die inneren Knoten lediglich Schlüssel enthalten. B* ­ Baum Bei dem B*‐Baum sind die Basisdaten (vollständige Sätze) nicht mehr im Baum – auch nicht in den Blattknoten – gespeichert, sondern „irgendwo“ und ungeordnet. Eine entscheidende Performance‐Frage für das gezielte Lesen anhand vom B*‐Baum (aber auch vom B+‐Baum) ist die Höhe des Baumes. Dafür sind relevant: a) Wieviele Tupel (Sätze) hat die Tabelle (oben: 100) b) Wie gross ist ein Block (1 kB, 2 kB, 4kB,.. 64kB). c) Wieviele Einträge ((Attribut‐wert, Verweis)‐Paare) sind im Index‐Block (oben 10, die PersNr wird 4B lang sein, ebenso der Verweis; damit brauchen unsere 10 Einträge 80B – dass dafür jeweils ein Block genommen wird, macht nur Sinn bei einer Blockgrösse von etwa 1/8 KB – so kleine Blöcke gibt es nur auf meinen Zeichnungen!) Dass der letzte Eintrag im Indexblock nur noch ein Verweis ist, keinen Wert‐Eintrag mehr hat, lassen wir unberücksichtigt. Erstellt aus den einzelnen Dokumenten von den Studenten Seite 33 Zusammenfassung Datenmanagement Rechnen im B* Baum Formeln: Einträge pro Indexblock = Blockgrösse * Ausnutzungsgrad / (Verweislänge + Attributlänge) Höhe = nächste ganze Zahl von log(Einträge pro Indexblock)(Anz. Einträge) Gesamtblockzahl = (Anzahl Einträge in Verschiedenen Blöcken) + Baumhöhe + (Anzahl Verweise) Tipp für den Taschenrechner: Aufgabe 1: Tabelle: MitararbeiterArbeitsplatz(MitarbeiterID: integer, ArbeitsplatzID: integer) -
MitarbeiterArbeitsplatz umfasst 1'000'000 Einträge -
Blockgrösse ist 1KB -
ein int – Wert belegt 4 Byte, ein Verweis ebenfalls -
alle Blöcke sind zu 80% gefüllt a)
Wie hoch ist der B* Baum 1. Einträge pro Indexblock ausrechnen: Blockgrösse * Ausnutzungsgrad / (Verweislänge + Attributlänge) 1024.8 / ( 4 + 4) = 102 2. Höhe ausrechnen. Höhe = nächste ganze Zahl von log(Einträge pro Indexblock) (Anz. Einträge) log(102) (1000000) = 2.98 ‐> 3 b) Wieviele Blöcke müssen gelesen werden, um die Anfrage „select MitarbeiterId from MitarbeiterArbeitsplatz wehre ArbeitsplatzId = 13“ abzuarbeiten? Es müssen die 3 Blöcke des B* Baums gelesen werden. Gibt es n Mitarbeiter, die sich den Arbeitsplatz teilen, so müssen n „Basis“ Sätze gelesen werden. Sind alle in unterschiedlichen Blöcken, so sind weitere n Blöcke zu lesen. Erstellt aus den einzelnen Dokumenten von den Studenten Seite 34 Zusammenfassung Datenmanagement Aufgabe2: ‐ Es gibt 10'000'000 Rechungspositionen. ‐ Pro Tag gibt es durchschnittlich 1000 Positionen ‐ Die Blockgrösse sei 1KB (gerundet 1000B) ‐ Ein Datumswert braucht 8B ‐ Verweise innerhalb des Indexes (im B* Baum) und von dort auf die Basissätze brauchen 4B ‐ Ausnutzungsgrad von 80% Wie viele Blockzugriffe braucht es für die Abarbeitung von „select * from Rechnungsposition where Datum = …“ ¨über den B* Baum Lösung: Einträge pro Indexblock ausrechnen: 1000 * 0.8 / (8 + 4) = 66.667 ‐> 67 Höhe bestimmen: log(67) (10000000) = 3.833 ‐> 4 Annahme: Die 1000 Einträge an diese Datum sind auf 1000 Blöcke verteilt (sehr pessimistisch) Die Verweise auf 1000 Records passen in 1000/ 67 Blöcke ‐> 15 Blöcke Gesamtblockzahl = (Anzahl Einträge in Verschiedenen Blöcken) + Baumhöhe + (Anzahl Verweise) Gesamtblockzahl = 1000 + 4 + 14 = 1019 Erstellt aus den einzelnen Dokumenten von den Studenten Seite 35 Zusammenfassung Datenmanagement 8. Sie verstehen die Optimierung von Anfragen 8.1 Sie kennen die Bedeutung der Datenbankoptimierung Durch die Datenbankoptimierung sollen Datensätze effizienter aus der Datenbank gelesen werden. Dies lässt sich auf zwei Weisen durch die logische und durch die physische Optimierung bewerkstelligen. Zum einen besteht die Möglichkeit, auf relationenalgebraische Ausdrücke Äquivalenzumformungen anzuwenden; z.B. können die Argumente der Joinoperation aufgrund ihrer Kommutativität vertauscht werden. Zum anderen gibt es für einen Operator der logischen Algebra oft mehrere unterschiedliche Implementierungen, d.h. Übersetzungsmöglichkeiten in die physische Algebra. In beiden Fällen werden Heuristiken zur Steuerung der Alternativengenerierung eingesetzt. 8.2 Sie können die logische Anfrageoptimierung einer Anfrage durchführen 1. Folgende Anweisung soll optimiert werden (Kanonische Darstellung) 1. Als erster Ansatz, werden die Auswahlkriterien den einbezogenen Entitäten näher gebracht Erstellt aus den einzelnen Dokumenten von den Studenten Seite 36 Zusammenfassung Datenmanagement 3.Als nächstes werden die Kreuzprodukte zu Joins umgeformt 4. Des weiteren kann vom Kommutativ‐ und Assoziativgesetzt Gebrauch gemacht werden. D.h. Es werden dort Selektionen vorgenommen, wo am meisten Daten zurück kommen. Erstellt aus den einzelnen Dokumenten von den Studenten Seite 37 Zusammenfassung Datenmanagement 5. Um unnötige Datenbestände auszuradieren, können Projektionen eingesetzt werden: By the way: Hier ein Auszug aus der wichtigsten algebraischen Regeln. Erstellt aus den einzelnen Dokumenten von den Studenten Seite 38 Zusammenfassung Datenmanagement 8.3 Sie kennen Techniken der physischen Optimierung Techniken der physischen Optimierung: •
•
•
•
•
Selektion Binäre Zuordnung (Matching) Gruppierung und Duplikateliminierung Projektion und Vereinigung Zwischenspeicherung 8.3.1 Selektion Eine Variante in der Implementierung der Selektion stellt der "Brute Force"‐Algorithmus dar, welcher bereits auf eine Indexstruktur (sei es ein B‐Baum oder eine Hashtabelle) zugreift. Beim Aufruf von next wird auf ein die Bedingung erfüllendes Tupel zurückgeliefert, bis die Eingabequellen erschöpft sind. 8.3.2 Binäre Zuordnung (Matching) Join, Mengendifferenz und Mengendurchschnitt lassen sich auf sehr ähnliche Weise implementieren. Daher fasst man sie unter der Bezeichnungbinäre Zuordnungsoperatorenzusammen. Beim Join werden Attribute zweiter Tupel verglichen, bei Differenz und Schnitt komplette Tupel. Erstellt aus den einzelnen Dokumenten von den Studenten Seite 39 Zusammenfassung Datenmanagement 8.3.2.1 Ein einfacher Join‐Algorithmus Beim einfachen Join‐Algorithmus werden zwei ineinander geschachtelte Schleifen (engl. nested loops) verwendet 8.3.2.2 Ein verfeinerter Join‐Algorithmus Die Tupel einer Relation sind auf Seiten abgespeichert und müssen dementsprechend für eine Bearbeitung seitenweise vom Hintergrundspeicher in den Hauptspeicher geladen werden. Stehen im HauptspeichermSeiten für die Berechnung des Joins zur Verfügung, reserviert der verfeinerte Join‐
AlgorithmuskSeiten für die innere Schleife undm‐kfür die äussere. Die äussere RelationRwird in Portionen zum‐kSeiten eingelesen. Für jede dieser Portionen muss die komplette innere RelationSin Portionen zukSeiten eingelesen werden. Alle Tupel der RelationR, die sich auf denm‐kSeiten befinden, werden mit allen Tuplen ausSin denkSeiten verglichen. Erstellt aus den einzelnen Dokumenten von den Studenten Seite 40 Zusammenfassung Datenmanagement 3.8.2.3 Ausnutzung der Sortierung Bei vorsortierten Relationen können die bereits geordneten Positionen der Tupel ausgenutzt werden. Die Relationen werden parallel von oben nach unten abgearbeitet. Bei nicht vorhandener Sortierung muss diese natürlich vorher durchgeführt werden, um denSort/Merge‐Joinanwenden zu können. 3.8.2.4 Ausnutzung von Indexstrukturen In diesem Verfahren werden die bereits bestehenden Indexstrukturen ausgenutzt. Auf das AttributBder RelationSist ein Index angelegt. Daher braucht man für jedes Tupel ausRnur die passenden Tupel ausBim Index nachzuschlagen. Erstellt aus den einzelnen Dokumenten von den Studenten Seite 41 Zusammenfassung Datenmanagement 3.8.2.5 Hash‐Joins Die Idee des Hash‐Joins besteht darin, die Eingabedaten so zu partitionieren, dass die Verwendung einer Hauptspeicher‐Hashtabelle möglich ist. BeimNested‐LoopJoin muss jedes Element der ArgumentrelationRmit jedem Element der RelationSverglichen werden, was einer vollständigen Schraffierung der Fläche im Bild entspricht (linke Abbildung). Mit der Partitionierung werden vorher die Tupel der Argumentrelationen so gruppiert, dass nur die schraffierten Rechtecke in der Diagonalen berücksicht werden müssen (rechte Abbildung). Die Vorgehensweise dazu sieht dann wie folgt aus: Erstellt aus den einzelnen Dokumenten von den Studenten Seite 42 Zusammenfassung Datenmanagement 8.3.3 Gruppierung und Duplikateliminierung Während beid er Gruppierung Tupel zusammengefasst werden, bei denen ein bestimmtes Attribut im Wert übereinstimmt, werden bei der Duplikateliminierung diejenigen Tupel zusammengefasst, die vollständig übereinstimmen. Als Vorgehensweise kann einer der drei bekannten Methoden eingesetzt werden: Brute‐Force Methode: vergleicht analog zum Nested‐Loop Join in zwei geschachtelten Schleifen jedes Tupel mit jedem. Liegt eine Sortierung vor, braucht die Eingabe lediglich von Anfang bis Ende einmal durchsucht und alle Duplikate eliminiert bzw. Gruppe bearbeitet zu werden. Wurde ein B+‐Baum verwendet, befinden sich in den Blättern des Baums entweder die Tupel oder Zeiger auf die Tupel der Eingaberelation in sortierter Reihenfolge. 8.3.4 Projektion und Vereinigung Projektion und Vereinigung sind sehr einfach zu implementieren. Da der Projektionsoperator der physischen Algebra keine Duplikateliminierung vornimmt, braucht er lediglich jedes Tupel der Eingabe auf die entsprechenden Attribute zu reduzieren und an die Ausgabe weiterzureichen. Bei der Vereinigung werden nur nacheinander alle Tupel der linken und rechten Eingabe ausgegeben, da auch hier der physischen Algebra keine automatischen Duplikateliminierung durchgeführt wird. Erstellt aus den einzelnen Dokumenten von den Studenten Seite 43 Zusammenfassung Datenmanagement 8.4 Sie können basierend auf der logischen Optimierung für eine einfache Abfrage einen Auswertungsplan bestimmen In Auswertungsplänen wird beschrieben, mit welchen physischen Verfahren logische Anfragen umgesetzt werden sollen. 1. Eine Join‐Operation kann entweder mit einem NestedLoop, MergeJoin, IndexJoin oder HashJoin realisiert werden: 2. Eine Selektion kann mit einem Select oder einem IndexSelect erstellt werden: 3. Eine Projektion wiederum kann mit NestedDup, SortDup oder IndexDup vorgenommen werde: Nachdem alle logischen Operatoren physischen Verfahren zugewiesen wurden, sollte ein Auswertungsplan entstanden sein, der in etwa so aussehen könnte: Erstellt aus den einzelnen Dokumenten von den Studenten Seite 44 Zusammenfassung Datenmanagement Natürlich hängt die Wahl vom Datenbanksystem und dem Server auf dem es läuft ab. Deshalb gibt es keine perfekte Lösung. Meist ist das Erstellen eines Auswertungsplanes ein Try‐And‐Error Verfahren. None: DMGAnfragen erstellt durch tamarkov Erstellt aus den einzelnen Dokumenten von den Studenten Seite 45 Zusammenfassung Datenmanagement 9. Sie kennen das Transaktionskonzept und dessen Anwendung in Fehlerbehandlung und Mehrbenutzersysnchronisation 9.1 Sie können das ACID Prinzip erklären. Sie kennen die möglichen Zustände einer Transaktion ACID‐Prinzip: • Atomicity: 'Alles‐oder‐Nichts'‐Eigenschaft • Consistency: Eine erfolgreiche Transaktion erhält die DB‐Konstistenz (Menge der definierten Integritätsbedingungen) • Isolation: Alle Aktionen innerhalb einer TA müssen vor parallel ablaufenden TAs verbrogen werden • Durability: Sobald eine TA ihre Änderungen freigegeben hat, muss das System das Überleben dieser Änderung trotz beliebiger (erwarteter) Fehler garantieren (Persistenz) potentiell TA wartet und ist bereit in den Zustand "aktiv" zu wechseln. Der Übergang heisst "inkarnieren". aktiv TA rechnet und konkurriert um Betriebsmittel mit anderen TAs. wartend TA wurde vom System (z.B. wegen zu hoher Last) angehalten. Verringert sich die Last des Systems, kann die TA wieder aktiviert werden. abgeschlossen TA wurde durch commit abgeschlossen, Integritätsbedingungen wurden noch nicht überprüft, Änderungen der TA noch nicht persistent. persistent Änderungen der TA wurden in Datenbasis persistiert. gescheitert TA wurde durch abort, Systemfehler oder durch Verletzung von Konsistenzbedingungen abgebrochen. wiederholbar Gescheiterte TAs sind u.U. wiederholbar, zunächst müssen aber die Änderungen der TA zurückgesetzt werden. Danach kann die TA neugestartet werden. aufgegeben Gescheiterte TA ist nicht wiederholbar. Erstellt aus den einzelnen Dokumenten von den Studenten Seite 46 Zusammenfassung Datenmanagement 9.2 Sie kennen die möglichen Fehler, die zu einem Recovery führen. 1. Lokaler Fehler einer noch nicht persistenten TA 2. Fehler mit Hauptspeicherverlust 3. Fehler mit Hintergrundspeicherverlust 9.3 Sie kennen die Konzepte für die Ersetzung von Puffer Seiten (steal und NOTsteal). Sie kennen Möglichkeiten des Einbringens von Änderungen (force und NOTforce). Schreibstrategien: •
FORCE (write‐through), schreibt geänderte Seiten spätestens beim commit zurück •
NO FORCE (write‐back), schreibt geänderte Seite erst bei Verdrängung aus dem DB‐Puffer zurück Ersetzung von Puffer‐Seiten: •
NO STEAL, das Ersetzen von TAs modifizierten Seiten ist verboten •
STEAL, jede Seite darf ersetzt werden ¬force <‐> redo steal <‐> undo Einbringstrategie: •
•
•
Update in Place o Jede Seite hat genau eine Heimat auf dem hintergrundspeicher o Der alte Zustand der Seite wird überschrieben Twin‐Block‐Verfahren o Für jede Seite werden zwei Versionen gehalten Schattenspeicherkonzept o nur geänderte Seiten werden dupliziert o weniger Redundanz als beim Twin‐Block‐Verfahren 9.4 Sie können eine Log Datei (logische Protokollierung) lesen und erstellen. Sie können Winner und Loser Transaktionen identifizieren. Sie können eine Log­Datei analyisieren. Sie können den Wiederanlauf nach einem Fehler auf Papier nachvollziehen. Sie kennen das Konzept der Sicherungspunkte Struktur der Log‐Einträge: [LSN,TA,PageID,Redo,Undo,PrevLSN] • LSN (Log Sequence Number) o IDs werden monoton aufsteigend vergeben o chronologische Reihenfolge der Einträge kann hiermit ermittelt werden Erstellt aus den einzelnen Dokumenten von den Studenten Seite 47 Zusammenfassung Datenmanagement •
•
•
•
•
TA (Transaktions ID) o Kennung der Transaktion, die die Änderung durchgeführt hat PageID o Seite auf welcher die Änderung gemacht wurden o bei mehreren Seiten: pro Seite ein Log‐Eintrag Redo o Information wie die Änderung nachvollzogen werden kann Undo o Information wie die Änderung rückgängig gemacht werden kann PrevLSN (Previous Log Sequence Number) o Verweis auf die vorhergegangene LSN o wird aus Effiziengründen benötigt o z.B. rückwärts Durchlaufen der LSNs einer TA für lokales Zurücksetzen Das WAL‐Prinzip 2 Regeln, die beide befolgt werden müssen: 1. Bevor eine Transaktion festgeschrieben (committed) wird, müssen alle zu ihr gehörenden Log‐Einträge ausgeschrieben werden. 2. Bevor eine modifzierte Seite ausgelagert werden darf, müssen alle Log‐Einträge, die zu dieser Seite gehören, in das temporäre und das Log‐Archiv ausgeschrieben werden. Es werden grundsätzlich alle Log‐Einträge bis zum letzten notwenidigen Log‐Eintrag geschrieben. Erstellt aus den einzelnen Dokumenten von den Studenten Seite 48 Zusammenfassung Datenmanagement Winner und Loser Transaktionen Transaktionen der Art T1 müssen hinsichtlich ihrer Wirkung vollständig nachvollzogen werden . Transaktionen dieser Art heissen Winner. • Transaktionen, die wie T2 zum Zeitpunkt des Absturzes noch aktiv waren, müssen rückgängig gmeacht werden. Diese Transaktion heissen Loser. Wideranlauf: 3 Phasen 1. Analyse des Logs a. Die Log‐Datei wird vom Anfang aufsteigend durchlaufen b. commit‐Einträge im Log kennzeichnen Winnder‐TAs c. TAs ohne commit sind Loser 2. Redo‐Phase a. alle Änderungen werden in zeitlicher Reihenfolgen in die Datenbasis eingebracht (auch die der Loser) b. Änderung nur notwendig falls LSN der Seite kleiner aktuelle LSN: in diesem Fall wird die aktuelle LSN auf die Seite geschrieben. 3. Undo‐Phase a. Log‐Datei wird absteigend vom Zeitpunkt des Absturz durchlaufen b. Winner‐Einträge werden ignoriert Für jeden c. Loser‐Einträg wird Undo ausgeführt (unabhängig von LSN) Sicherungspunkte • Problem: Log‐Datei wird mit zunehmender Betriebszeit des DBMS grösser • Folge: Wiederanlauf dauert immer länger • Lösung: markiere einen Sicherungspunkt im Log, über den man beim Wiederanlauf nicht hinausgehen muss Transaktionskonsistente Sicherungspunkte •
Erstellt aus den einzelnen Dokumenten von den Studenten Seite 49 Zusammenfassung Datenmanagement •
Idee: alle neuen TAs, die nach Si eintreffen, werden suspendiert bis alle laufenden TAs committed haben Beispiel: •
•
•
T1 und T2 werden materialisiert Alte Log‐Datei kann gelöscht werden T3 wechselt nach aktiv 9.5 Sie kennen Fehler beim unkontrollierten Mehrbenutzerbetrieb. Sie kennen den Begriff der Historie und der Serialisierbarkeit. Sie können eine Historie in eine äquivalente Historie umformen. Sie können den Serialisierbarkeitsgraphen einer Historie erstellen und interpretieren. Verlorengegangene Änderungen (lost update) Abhängigkeit von nicht freigegeben Änderungen Erstellt aus den einzelnen Dokumenten von den Studenten Seite 50 Zusammenfassung Datenmanagement Phantomproblem Serialisierbarkeit • Historie ist "äquivalent" zu einer seriellen Historie • denoch parallele (verzahnte) Ausfürhung möglich Serielle Ausfürhung von T1 vor T2, also T1 / T2 Erstellt aus den einzelnen Dokumenten von den Studenten Seite 51 Zusammenfassung Datenmanagement Nicht serialisierbare Historie Zwei verzahnte Überweisungs‐Transaktionen Erstellt aus den einzelnen Dokumenten von den Studenten Seite 52 Zusammenfassung Datenmanagement Serialisierbarkeit • Jeder serielle Ablauf von Transaktionen wird als korrekt angesehen, weil die Transaktionen vollständig isoliert voneinander ablaufen. Andererseits will man mehr Parallelität von Transaktionen zulassen. Deshalb soll das Datenbanksystem serialisierbare Abläufe von Transaktionen erlauben. Serialisierbar ist ein paralleler Ablauf von Transaktionen, wenn er einem seriellen Ablauf entspricht. Zwei Operationen sind vertauschbar, wenn der Zustand der Datenbank (d.h., welche Tupel in der Datenbank welche Attributwerte haben) und die Werte von Variablen eines Anwendungsprogramms nicht von der Reihenfolge der Operationen abhängt. Beispiel: •
Konto1 = temp1 und Konto2 = temp2 . Nicht vertauschbare Operationen stehen zueinanderin Konflikt. Beispiel: Konto1 = temp1 und temp2 = Konto1 . Der Wert von temp2 hängt (in der Regel) von der Reihenfolge beider Operationen ab.Wenn man zu einem parallelen Ablauf von Transaktionen einen äquivalenten seriellen Ablauf der Transaktionen sucht, bestimmen die Konflikte zwischen den mit Commit beendeten Transaktionen, in welcher Reihenfolge die Transaktionen in einem äquivalenten seriellen Ablauf ausgeführt werden müßten: Wenn eine Operation o1 aus T1 vor einer Operation o2 aus T2 vorkommt und o1 und o2 zueinander in Konflikt stehen, d.h., nicht vertauschbar sind, dann besteht eine Abhängigkeit von T1 zu T2. In einem äquivalenten seriellen Ablauf müßte die ganze Transaktion T1 vor der ganzen Transaktion T2 ausgeführt werden. Die mit Abort abgebrochenen Transaktionen verändern die Datenbank nicht, die Reihenfolge ihrer Operationen (innerhalb eines parallelen Ablaufs von Transaktionen) ist deshalb belanglos. Aus den Abhängigkeiten zwischen den mit Commit beendeten Transaktionen definiert man den sogenannten Serialisierbarkeitsgraphen. Die Knoten sind die mit Commit beendeten Transaktionen eines Ablaufs und die Kanten sind die Abhängigkeiten zwischen diesen Transaktionen. Genau dann wenn dieser Serialisierbarkeitsgraph (=Abhängigkeitsgraph) zyklenfrei ist, nennt man den Ablauf serialisierbar. Beispiel: T1 T2 1 BOT 2 read( Konto1 ) 3 write( Konto1 ) 4 read( Konto2 5 BOT 6 read( Konto2 ) 7 write( Konto2 ) 8 write( Konto3 ) 9 write( Konto3 ) 10 commit 11 commit Erstellt aus den einzelnen Dokumenten von den Studenten Seite 53 Zusammenfassung Datenmanagement Dieser Ablauf enthält folgende Abhängigkeiten, •
(6‐>7) read( Konto2 ) ‐> write( Konto2 ), also T2 vor T1 (8‐>9) write( Konto3 ) ‐> write( Konto3 ), also T2 vor T1 weil auf denselben Datensätzen Leseoperationen zu Schreiboperationen und Schreiboperationen zu Schreiboperationen in Konflikt stehen.Keine Abhängigkeit besteht zwischen folgenden Operationen: •
(4‐>6) read( Konto2 ) ‐> read( Konto2 ), weil Leseoperationen auf denselben Datensätzen nicht zueinander in Konflikt stehen. Alle Abhängigkeiten verlangen T2 vor T1, also gibt es einen äquivalenten seriellen Ablauf, nämlich T2 vor T1, also ist der Ablauf aus dem Beispiel serialisierbar. 9.6 Sie kennen verschiedene Sperrmodi. Sie kennen Methoden der sperrbasierten Synchronisation. Sie können einen Wartegraphen erstellen und Verklemmungen (deadlocks) erkennen. Sperrbasierte Synchronisation • Zwei Sperrmodi o S (Shared lock, read, Lesesperre) o X (eXclusive lock, write, Schreibsperre) • Verträglichkeitsmatrix (Kompatiblitätsmatrix) NL S X S ok ok ‐ X ok ‐ ‐ 2PL Kaskadierendes Rücksetzen Erstellt aus den einzelnen Dokumenten von den Studenten Seite 54 Zusammenfassung Datenmanagement • Was passiert, wenn T1 direkt vor Schritt 15 scheitert? • Dann muss T2 zurückgesetzt werden , da T2 'dreckige' (dirty) Daten von T1 gelesen hat. Verklemmung (Deadlock) Preclaming zur Vermeidung von Verklemmungen Wie weiss die TA vorher, welche Datenobjekte sie benötigt? Deswegen in der Praxis nicht realisierbar Verklemmungsvermeidung durch Zeitstempel •
•
Zeitstempelmethode ist garantiert verklemmungsfrei Nachteile: o zuviele TAs werden unnötig zurückgesetzt o wound‐wait: junge TAs haben das Nachsehen o wait‐die: alte TAs haben das Nachsehen None: DMGTransaktionskonzept erstellt durch tbnieder Erstellt aus den einzelnen Dokumenten von den Studenten Seite 55 Zusammenfassung Datenmanagement 10. Sie kennen Sicherheitsaspekte in SQL 10.1 Sie kennen die Befehle der Zugriffskontrolle in SQL Die hier verwendeten Befehle orientieren sich nach der Syntax des Buches. Die Beispiele wurden übernommen von http://www‐lehre.informatik.uni‐osnabrueck.de/~dbs/2001/skript/node136.html 10.1.1 Der Grant­Befehl Der Syntaxaufbau für den Grantbefehl lautet: grant { select | insert | delete | update | references | all }
on <relation> to <user> [with grant option]
Es wird zwischen den folgenden Ausführungsmöglichkeiten unterschieden, mit welchen ein Benutzer die Datenbank pflegen kann: select darf Tupel lesen insert darf Tupel einfügen delete darf Tupel löschen update darf Tupel ändern references darf Fremdschlüssel anlegen all select + insert + delete + update + references
with grant option <user> darf die ihm erteilten Rechte weitergeben Beispiel: Lese‐ und Einfügerechte für Benutzer B grant read, insert on angest to B with grant option Benutzer B darf diese Rechte weitergeben
grant read on angest to C with grant option Leserechte für Benutzer C Benutzer C darf diese Rechte weitergeben
grant insert on angest to C
Einfügerechte für Benutzer C 10.1.2 Der Revoke­Befehl Jeder Benutzer, der ein Recht vergeben hat, kann dieses mit einer Revoke‐Anweisung wieder zurücknehmen: revoke { select | insert | delete | update | references | all }
on <relation> from <user>
Beispiel: B: revoke all on angest from C
Es sollen dadurch dem Benutzer C alle Rechte entzogen werden, die er von B erhalten hat, aber nicht solche, die er von anderen Benutzern erhalten hat. Ausserdem erlöschen die von C weitergegebenen Rechte. 10.2 Sie kennen die Idee der Rollen und können sie in dem verwendeten Datenbank­System umsetzen Für eine implizite Autorisierung von Subjekten werden so genannte Rollen und Rollenhierarchien eingeführt. Bei der rollenbasierten Autorisierung werden Benutzern Rollen zugeordnet. Erstellt aus den einzelnen Dokumenten von den Studenten Seite 56 Zusammenfassung Datenmanagement Zugriffsrechte werden dabei nicht mehr direkt den Benutzern gewährt, sondern diesen Rollen zugeordnet. Die Benutzer aktivieren in einer Session die für die Aufgabe nötige Rollen und können dann die Operationen durchführen, de den aktivierten Rollen gestattet sind. Rollen Erstellen in MS‐SQL Erstellt eine neue Rolle 'UniMitarbeiter' Löscht die Rolle 'UniMitarbeiter' Erstellt ein neues Login Namens 'chris' Erstellt einen neuen Benutzer 'chrs' und weisst diesen dem Login 'chris' zu Fügt den Benutzer 'chris' zur Rolle 'UniMitarbeiter' Löscht den Benutzer 'chris' create role UniMitarbeit
drop role UniMitarbeite
create login chris with p
create user chris for log
exec sp_addrolemembe
drop user chris;
10.3 Sie können Zugriffsrechte auf Relationen und Sichten vergeben Folgendes Beispiel zeigt wie eine Rolle erstellt, ein Benutzer erzeugt, eine Sicht kreiert und die entsprechenden Rechte auf Relationen sowie auch auf Sichten vergeben werden: create role UniMitarbeiter;
create login chris with password='chris1';
create user chris for login chris;
exec sp_addrolemember UniMitarbeiter, chris;
# Lese‐ und Updaterechte auf Relation 'Professoren' erteilen grant select, update on Professoren to UniMitarbeiter;
# Updaterechte auf Relation 'Professoren' entziehen. revoke update on Professoren from UniMitarbeiter cascade
# Sicht erzeugen CREATE VIEW viewProfessoren AS
Select [Name], [Raum] FROM Professoren;
Erstellt aus den einzelnen Dokumenten von den Studenten Seite 57 Zusammenfassung Datenmanagement # Leserechte auf Sicht für Rolle 'UniMitarbeiter' erteilen grant select on viewProfessoren to UniMitarbeiter;
None: DMGSicherheit erstellt durch tamarkov 11. Sie kennen die Definitionssprache (ODL) und die Abfragesprache (OQL) der ODMG Beispiel class Professoren {
attribute long PersNr;
attribute string Name;
attribute string Rang;
relationship Raeume residiertIn inverse Raeume::beherbergt;
};
class Raeume {
attribute long RaumNr;
...
relationship Professoren beherbergt inverse
Professoren::residiertIn;
};
';' am Schluss der Klassendefiniton beachten 11.1 sie kennen die zwei Vererbungen in der ODL der ODMG (interface und extends) Von einer Klasse erben, in ODL ist nur Einfachvererbung gestattet. class Professor extends Employee
(extent professors)
{...}
Vom Interface StudentIF erben
class Student: StudentIF
(extent students)
{...}
11.2 Sie können Beziehungen in der ODL beschreiben 1:N Beziehung class Professoren {
...
relationship set<Vorlesungen> liest inverse
Vorlesungen::gelesenVon;
};
class Vorlesungen {
...
relationship Professoren gelesenVon inverse Professoren::liest;
};
Erstellt aus den einzelnen Dokumenten von den Studenten Seite 58 Zusammenfassung Datenmanagement N:M Beziehung class Studenten {
...
relationship set<Vorlesungen> hoert inverse Vorlesungen::Hoerer;
};
class Vorlesungen {
...
relationship set<Studenten> Hoerer inverse Studenten::hoert;
};
11.3 Sie können ein Datenmodell in ODL interpretieren siehe Arbeitsblaetter 11.4 Sie können ein einfaches Datenmodell erstellen module myCompany {
exception NoSuchEmployee{};
...
struct Address {
string street;
long number;
string city;
short zip;
}
class Department (extent departments)
{
attribute string name;
relationship Employee boss
inverse Employee::is_boss_of;
relationship list<Employee> has_employee
inverse Employee::works_in;
};
class Employee (extent employees)
{
attribute string name;
attribute short id;
attribute Salary annual_salary;
void hire();
void fire() raises (NoSuchEmployee);
}
Wasi ned checke esch fuer was dases NoSuchEmployee brucht, well en OOP ruft me d Methode vom betraeffende Objekt us uf, also me chas gar ned ufruefe wenns ne ned get, hani gmeint.. 11.5 Sie kennen die Grundlagen der Anfragesprache der ODMG (Object Query Language, OQL) (iknsbes. Anfragen auf Extents, Path Expressions, Methodenaufrufe) Einfaches Beispiel Erstellt aus den einzelnen Dokumenten von den Studenten Seite 59 Zusammenfassung Datenmanagement select struct(n: p.Name, r: p.Rang)
from p in AlleProfessoren
where p.Rang = "C4";
Pfadausdruecke select s.Name
from s in AlleStudenten, v in s.hoert
where v.gelesenVon.Name = "Sokrates";
Methodenaufrufe oldest_child ist eine Methode von Persons, die ohne Parameter aufgerufen werden kann. Die Methode lives_in erwartet einen Ortsnamen als Parameter. select p.oldest_child.address.street
from Persons p
where p.lives_in("Paris")
11.6 Sie können Anfragen interpretieren. Sie können Anfragen selber formulieren In OQL existieren neben den bekannten Boolschen Operatoren noch zwei weitere: andthen und orelse. Dabei wird der 2. Wert nur angeschaut, wenn dies noetig ist, aehlich wie && oder || in c oder der bash. Beispiel select p.name
from Persons p
where p.address != nil
andthen p.address.city = "Paris"
None: DMGDefinitionssprache erstellt durch tabrueng Erstellt aus den einzelnen Dokumenten von den Studenten Seite 60 Zusammenfassung Datenmanagement 12. XPath und XQuery 12.1 Einführung XML ist eine Sprache für das Web und wird insbesondere als standardisiertes Datenaustauschformat zwischen verteilten Anwendungen gesehen. In XML werden, im Gegensatz zu HTML, kontext‐ bzw. anwendungsspezifische Tags verwendet, die die Bedeutung der Elemente angeben und nicht nur die reine Formatierung. 12.2 XML Struktur Ein XML Dokument ist sehr einfach strukturiert und besteht aus drei Teilen: •
•
•
einer optionalen Präambel (Angabe der XML‐Version) einem optionalem Schema (Die Document Type Definition oder das neuere XML Schema) einem einzigen Wurzelelement, das dann beliebig viele und beliebig tief geschachtelte Unterelemente beinhalten kann. Elemente sind die atomaren Informationseinheiten. Ein Element wird immer von einem Start‐ und Ende‐Tag eingeschlossen. (Bsp. <Vorlesung>Biologie</Vorlesung>). Der eigentliche Inhalt eines Elements besteht aus einer geordneten Liste aus (Unter‐)Elementen oder Informationseinheiten. 12.3 XML Schema Ein XML Dokument kann entweder ein Schema besitzen oder auch nicht. Wenn einem Dokument ein Schema zugeordnet ist, muss dieses auch eingehalten werden. Ein Schema kann folgendermassen definiert werden: <!-- Schema als DTD -->
<!DOCTYPE Buch[
<!ELEMENT Buch (Titel, Autor*, Verlag)>
<!ATTLIST Buch Jahr CDATA #REQUIRED>
<!ELEMENT Titel (#PCDATA)>
<!ELEMENT Autor (#PCDATA)>
<!ELEMENT Verlag (#PCDATA)>
]>
Erstellt aus den einzelnen Dokumenten von den Studenten Seite 61 Zusammenfassung Datenmanagement Das Element Buch beschreibt, wie das Buch selber aufgebaut sein soll. Ein Buch muss zumindest ein Unterelement Titel haben, der als Parsable Character angegeben ist. Die Anzahl der Autoren ist zwischen null oder beliebig vielen, was durch den Stern angegeben ist. Zuletzt muss es auch einen Verlag enthalten. Das Buch muss ein Attribut Jahr aufweisen, da dieses Attribut als #REQUIRED angegeben ist. Optionale Attribute werden mit #IMPLIED deklariert. Rekursive Struktur Die Struktur wäre rekursiv wenn beispielsweise im Element Bauteil, als Unterelement Bauteil selber definiert wurde: <?xml version="1.0" encoding='ISO-8859-1'?>
<!-- Schema als DTD -->
<!DOCTYPE Bauteil[
<!ELEMENT Bauteil (Beschreibung, Bauteil*)>
<!ATTLIST Bauteil Preis CDATA #REQUIRED>
<!ELEMENT Beschreibung (#PCDATA)>
]>
<!-- Wurzelelement-->
<Bauteil Preis="350000">
<Beschreibung>Maybach 620 Limousine</Beschreibung>
<Bauteil Preis="50000">
<Beschreibung>V12-Biturbo Motor mit 620 PS</Beschreibung>
<Bauteil Preis="2000">
<Beschreibung>Nockenwelle</Beschreibung>
</Bauteil>
</Bauteil>
<Bauteil Preis="7000">
<Beschreibung>Kühlschrank für Champagner</Beschreibung>
</Bauteil>
</Bauteil>
Erstellt aus den einzelnen Dokumenten von den Studenten Seite 62 Zusammenfassung Datenmanagement Somit kann ein Bauteil aus mehreren Unterbauteilen zusammengesetzt sein. 12.4 Analyse von Dateninhalten Gegeben sind folgende Dateninhalte einer Universität: <?xml version="1.0" encoding='ISO-8859-1'?>
<Universität UnivName="Virtuelle Universität der Großen Denker">
<UniLeitung>
<Rektor>Prof. Sokrates</Rektor>
<Kanzler>Dr. Erhard</Kanzler>
</UniLeitung>
<Fakultäten>
<Fakultät>
<FakName>Theologie</FakName>
<ProfessorIn PersNr="2134">
<Name>Augustinus</Name>
<Rang>C3</Rang>
<Raum>309</Raum>
<Vorlesungen>
<Vorlesung VorlNr="5022">
<Titel>Glaube und Wissen</Titel>
<SWS>2</SWS>
</Vorlesung>
</Vorlesungen>
</ProfessorIn>
</Fakultät>
<Fakultät>
<FakName>Physik</FakName>
<ProfessorIn PersNr="2136">
<Name>Curie</Name>
Erstellt aus den einzelnen Dokumenten von den Studenten Seite 63 Zusammenfassung Datenmanagement <Rang>C4</Rang>
<Raum>36</Raum>
</ProfessorIn>
<ProfessorIn PersNr="2127">
<Name>Kopernikus</Name>
<Rang>C3</Rang>
<Raum>310</Raum>
</ProfessorIn>
</Fakultät>
<Fakultät>
<FakName>Philosophie</FakName>
...
...
</Fakultät>
</Fakultäten>
</Universität>
Würde man diese Struktur grafisch aufzeichnen, so käme folgender Baum heraus: Erstellt aus den einzelnen Dokumenten von den Studenten Seite 64 Zusammenfassung Datenmanagement Abbildung 1: Baumdarstellung der Baumelemente
Man sieht, es existiert nur ein Wurzelknoten „Universität“ mit dem Attribut „UnivName“ und den beiden Elementen „UniLeitung“ und „Fakultäten“. Es ist zwar nicht notwendig, aber Code‐Einrückungen im XML vereinfachen das Lesen enorm. 12.5 XML­Anfragesprache XQuery •
•
•
Basiert auf Xpath, einer Sprache für Pfadausdrücke Ein Lokalisierungspfad besteht aus einzelnen Lokalisierungsschritten Jeder Lokalisierungsschritt besteht aus bis zu drei Teilen: Achse::Knotentest[Prädikat] 12.6 XPath­Achsen •
•
•
•
•
self: Hierbei handelt es sich um den Referenzknoten. attribute: Hierunter fallen alle Attribute des Referenzknotens (falls er überhaupt welche besitzt) child: Entlang dieser Achse werden alle direkten Unterelemente bestimmt. descendant: Hierunter fallen alle direkten und indirekten Unterelemente, also die Kinder und deren Kinder u.s.w. descendant‐or‐self: Wie oben, außer dass der Referenzknoten hier auch dazu gehört. Erstellt aus den einzelnen Dokumenten von den Studenten Seite 65 Zusammenfassung Datenmanagement •
•
•
•
•
•
•
parent: Der Vaterknoten des Referenzknotens wird über diese Achse ermittelt. ancestor: Hierzu zählen alle Knoten auf dem Pfad vom Referenzknoten zur Wurzel des XML‐
Baums. ancestor‐or‐self: Wie oben, außer dass der Referenzknoten auch mit eingeschlossen wird. following‐sibling: Dies sind die in Dokumentreihenfolge nachfolgenden Kinder des Elternknotens von self. preceding‐sibling: Hierbei handelt es sich um die in Dokumentreihenfolge vorangehenden Kinder des Elternknotens von self. following: Alle Knoten, die in Dokumentreihenfolge nach dem Referenzknoten aufgeführt sind. Die Nachkommen (descendant) des Referenzknotens gehören aber nicht dazu. preceding: Alle Knoten, die im Dokument vor dem Referenzknoten vorkommen ‐‐ allerdings ohne die Vorfahren (ancestor). Abbildung 2: Grafische Darstellung der XPath-Achsen
12.7 XPath Ausdrücke Beispiel – Anfrage mit Bedingung doc("Uni.xml")/child::Universität[self::*/attribute::UnivName="Virtu
elle Universität der Großen Denker"]
Erstellt aus den einzelnen Dokumenten von den Studenten Seite 66 Zusammenfassung Datenmanagement Folgendes geschieht: Öffne das Dokument „Uni.xml“ und wähle die Unterelemente vom Typ „Universität“, welche ein Attribut „UnivName“ beinhalten mit dem Eintrag „Universität der grossen Denker“. Dadurch erhalten wir einen Baum wie in der vorletzten Abbildung der Universität mit dem spezifizierten Namen. Beispiel – Anfrage doc("Uni.xml")/child::Universität/child::Fakultäten/child::Fakultät/
child::FakName
Folgendes geschieht: Gib alle Elemente „FakName“ von allen Fakultäten aus. Folgendes Ergebnis erscheint: <FakName>Theologie</FakName>
<FakName>Physik</FakName>
<FakName>Philosophie</FakName>
Selbes Ergebnis erscheint auch mit: doc("Uni.xml")/descendant-or-self::FakName
Somit greift man direct auf “FakName” zu, ohne die übergeordneten Elemente einzutippen. Beispiel – Anfrage mit Bedingung 2 doc("Uni.xml")/child::Universität/child::Fakultäten/child::Fakultät[
child::FakName="Philosophie"]/child::ProfessorIn[child::Rang="C4"]/c
hild::Vorlesungen/child::Vorlesung/child::Titel
Folgendes geschieht: Es werden alle Titel der Vorlesungen ausgegeben, die ein Professor mit Rang „C4“ unterrichtet der Fakultät „Philospophie“. Beispiel – Anfrage mit Existenzprüfung doc("Uni.xml")/child::Universität/child::Fakultäten/child::Fakultät/
child::FakName[parent::Fakultät/child::ProfessorIn/child::Vorlesunge
n]
Erstellt aus den einzelnen Dokumenten von den Studenten Seite 67 Zusammenfassung Datenmanagement Folgendes geschieht: Es werden nur die Namen von Fakultäten angezeigt, wo die Fakultät Professoren beinhaltet, die eine Vorlesung unterrichten. Ergebnis: <FakName>Theologie</FakName>
<FakName>Philosophie</FakName>
12.8 Verkürzte Syntax Durch die verkürzte Syntax wird die Lesbarkeit deutlich vereinfacht. •
•
•
•
•
. Aktueller Referenzknoten .. Vaterknoten / Abgrenzung einzelner Schritte oder Wurzel ElemName1/ElemName2/ElemName3 // descendant‐or‐self::node() @AttrName Attributzugriff 12.9 XPath Ausdrücke mit verkürzter Syntax Ausgabe aller Vorlesungen der Fakultät „Physik“ doc("Uni.xml")/Universität/Fakultäten/Fakultät[FakName="Physik"]//Vo
rlesung
Ausgabe der zweiten Vorlesung (erstes Element hat nicht Index 0 sondern 1) der Fakultät „Physik“ doc("Uni.xml")/Universität/Fakultäten/Fakultät[position()=2]//Vorles
ung
doc("Uni.xml")/Universität/Fakultäten/Fakultät[2]//Vorlesung
Ausgabe aller Vorlesungen, welche von Professoren unterrichtet werden an der Fakultät „Physik“ doc("Uni.xml")/Universität/Fakultäten/Fakultät[FakName="Physik"]/Pro
fessorIn/Vorlesungen/Vorlesung
Beachte: Will man alle Unterelemente eines Knotens ausgeben, so muss dies bspw. mit // (descendant‐or‐self) erfolgen. / ist nur eine Abgrenzung und würde zu einem leeren Resultat führen. Erstellt aus den einzelnen Dokumenten von den Studenten Seite 68 Zusammenfassung Datenmanagement 12.10Effektive XQuery Anfragen (MSSQL) SELECT uniXml.query('
for $f in //Fakultaet[FakName="Theologie"]//Vorlesung/Titel
return $f
') as Result
FROM uniTb
WHERE id=2
Resultat:
<Titel>Glaube und Wissen</Titel>
Ausgabe der Vorlesungen der 2. Universität der Fakultät „Theologie“ SELECT uniXml.query('
for $r in //Vorlesungen/Vorlesung
return
<VorlTitelNummer>
{$r/@VorlNr}
{$r/Titel}
</VorlTitelNummer>
') as Result
FROM uniTb
WHERE id=2
Resultat:
<VorlTitelNummer VorlNr="5022">
<Titel>Glaube und Wissen</Titel>
</VorlTitelNummer>
<VorlTitelNummer VorlNr="5041">
<Titel>Ethik</Titel>
</VorlTitelNummer>
Erstellt aus den einzelnen Dokumenten von den Studenten Seite 69 Zusammenfassung Datenmanagement ...
Ausgabe der Nummer und des Titels aller Vorlesungen der 2. Universität. Hier sieht man, dass man sogar für das Resultat die Struktur für die Ausgabe definieren kann <VorlTitelNummer> Joins in XQuery SELECT uniXml.query('
for $s in //Student[Name="Carnap"],
$p in //Vorlesung
where contains($s/@hoert, $p/@VorlNr)
return $p/../../Name
') as Result
FROM uniTb
WHERE id=4
Ausgabe der Namen der Professoren, die Vorlesungen unterrichten, die der Student Carnap besucht. None: DMGXML erstellt durch tahauck Erstellt aus den einzelnen Dokumenten von den Studenten Seite 70 Zusammenfassung Datenmanagement 13. Sie kennen das Konzept des Datawarehouse 13.1 sie können einige wesentliche Unterschiede zwischen OLAP und OLTP nennen OLAP(Online Analytical Processing)
•
beschäftigt sich mit der Datenanlyse z.B. für Marketing entscheidungen. Wie hat sich die Auslastung der Transatlantikflüge über die letzten zwei Jahre entwickelt? oder Wie haben sich besondere offensive Marketingstrategien für bestimmte Produktlinien auf die Verkaufszahlen ausgewirkt? OLTP(Online Transaction Processing)
beschäftigt damit möglichst viele kleinere Anfragen innert sehr kurzer Zeit zu beweltigen.
Anzahl gleichzeitiger
Benutzer
Antwortzeiten
Zugriffsfrequenz
Datenvolumen pro Zugriff
Änderung des
Datenbestands
Datenstrukturierung
Kritische Faktoren
OLTP
OLAP
mehrere 1000
< 100
Millisekunden
hoch
niedrig
Sek. bis Min.
niedrig - mittel
hoch
laufend
durch def. Updates
detailliert
Performance Antwortzeitverhalten
Ausfallsicher-heit
verdichtet
Datenbankgrösse strukturelle Än
Datenqualität
13.2 Sie kennen das Sternschema (Fakten­ und Dimensionstabellen) und dessen Eigenschaften (in Bezug auf Normalisierung und Join­Tiefen) Stern-Schema bei Data Warehouse-Anwendungen
•
•
Eine sehr große Faktentabelle o Alle Verkäufe der letzten drei Jahre o Alle Telefonate des letzten Jahres o Alle Flugreservierungen der letzten fünf Jahre o normalisiert Mehrere Dimensionstabellen o Zeit o Filialen o Kunden o Produkt o Oft nicht normalisiert Erstellt aus den einzelnen Dokumenten von den Studenten Seite 71 Zusammenfassung Datenmanagement Das Stern Schema fasst sehr viel Daten zusammen, damit möglichst viele Abfragen gemacht
werden können. Die Anfragen (Dimensionstabellen) auf die Faktentabelle sind meist nicht
normailisert, wird dies gemacht so kommt man vom Sternschema zum Schneeflocken Schema
So sieht ein Stern-Schema aus:
Die Faktentabelle könnte so aussehen und basiert auf die Tabellen unterhalb der
Faktentabelle:
Erstellt aus den einzelnen Dokumenten von den Studenten Seite 72 Zusammenfassung Datenmanagement Erstellt aus den einzelnen Dokumenten von den Studenten Seite 73 Zusammenfassung Datenmanagement Erstellt aus den einzelnen Dokumenten von den Studenten Seite 74 Zusammenfassung Datenmanagement Erstellt aus den einzelnen Dokumenten von den Studenten Seite 75 Zusammenfassung Datenmanagement 13.3 Sie können den Cube Operator anwenden Weitere Beispiele für cube siehe:
Magazin > HTA > Bachelor > Fachbereich Technik > Fachbereich Technik W06 >
HTA.DMG.W06 > Unterlagen > Lösungen > abgegebene Lösungen :
DMGT_SW14_2_2006_Lösungen
None: DMGDatawarehouse (zuletzt geändert am 2007-02-21 13:34:56 durch taroeoes)
Erstellt aus den einzelnen Dokumenten von den Studenten Seite 76 Zusammenfassung Datenmanagement 14. Sie kennen Konzepte von Verteilten Datenbanken 14.1 Sie können den Begriff der verteilten Datenbanken definieren Eine verteilte Datenbank besteht aus einer Sammlung von Informationseinheiten, die auf
mehreren über eine Kommunikationsnetz miteinander verbunden Rechnern verteilt sind. Jede
Station des Netzwerks kann autonom lokal verfügbare Daten verarbeiten und somit lokale
Anwendungen "vor Ort" ausführen. Jede Station des verteilten Datenbanksystems nimmt aber
zusätzlich an mindestens einer globalen Aufgabe teil, die über das Kommunikationsnetz
abgewickelt wird.
•
14.2 Sie können die horizontale und vertikale Fragmentierung erläutern Es gibt drei grundlegende Korrektheits-Anforderungen an eine Fragmentierung:
1. Rekonstruierbarkeit: Die fragmentierte Relation lässt sich aus den Fragmenten
wiederherstellen
2. Vollständigkeit: Jedes Datum ist einem Fragment zugeordnet
3. Disjunktheit: Die Fragmente überlappen sich nicht, d.h. ein Datum ist nicht mehreren
Fragmenten zugeordnet.
14.2.1 Horizontale Fragmentierung Bei der horizontalen Fragmentierung wird die Relation in disjunkte Tupelmengen zerlegt.
Erstellt aus den einzelnen Dokumenten von den Studenten Seite 77 Zusammenfassung Datenmanagement •
Anhand der Beispielrelation Professoren soll eine horizontale Fragmentierung dargestellt
werden. Die Professoren werde nach Fakultätszugehörigkeit gruppiert und in entsprechende
Datenbanken abgespeichert.
•
14.2.2 Vertikale Fragmentierung Bei der vertikalen Fragmentierung werden Attribute mit gleichem Zugriffsmuster
zusammengefasst. Die Relation wird somit vertikal durch Ausführung von Projektionen
zerlegt.
•
Erstellt aus den einzelnen Dokumenten von den Studenten Seite 78 Zusammenfassung Datenmanagement Bei beliebiger vertikaler Aufspaltung wäre aber die Rekonstruierbarkeit nicht gewährleistet.
Es gibt zwei Ansätze, die Rekonstruierbarkeit zu garantieren:
1. Jedes Fragment enthält den Primärschlüssel k der Originalrelation. In gewisser
Hinsicht verletzt man dadurch aber die Disjunktheit der Fragmente.
2. Jedem Tupel der Originalrelation wird ein eindeutiges Surrogat (ein künstlich
erzeugter Objektidentifikator) zugeordnet. Dieses Surrogat wird in jedes vertikale
Fragment des Tupels mit aufgenommen.
Ein kleines Beispiel aus dem Skript:
•
14.3 Sie wissen, was Allokation bedeutet Allokation bezeichnet den Vorgang, in welchem die Zuordnung der Fragmente auf Stationen
des verteilten Datenbanksystems, nachdem das Fragmentierungsschema festegelegt wurde,
vorgenommen wird. Man unterscheidet zwei Arten von Allokation:
1. redundanzfreie Allokation: In diesem Fall wird jedes Fragment genau einer Station
zugeordnet. Es handelt sich dann um eine N:1-Zuordnung von Fragmenten zu
Stationen.
2. Allokation mit Replikation: Hierbei handelt es sich um eine N:M-Zuordnung. Einige
Fragmente werden repliziert und mehreren Stationen zugeordnet.
3.
Erstellt aus den einzelnen Dokumenten von den Studenten Seite 79 Zusammenfassung Datenmanagement Beispiel:
In diesem Beispiel wurde die Relation Professoren horizontal h und vertikal v aufgesplitten:
•
Aus dieser Konstellation ergibt sich folgende Allokationschema:
•
By the way: Hierbei handelt es sich offensichtlich um eine Allokation ohne Replikation, also
eine redundanzfreie Zuordnung.
14.4 Sie können Fragmentierungs­ und Allokationstransparenz erläutern Unter Transparenz versteht man den Grad an Unabhängigkeit, den ein VDBMS (verteiltes
Datenbankverwaltungssystem) den Benutzern beim Zugriff auf verteilte Daten vermittelt.
14.4.1 Fragmentierungstransparenz Dies ist der Idealzustand: Die Benutzer arbeiten mit dem globalen Schema, und es ist die
Aufgabe des VDBMS, die Operationen auf der globalen Relation zu übersetzen.
Beispiel: Wir arbeiten direkt mit der Relation Professoren
select Titel, Name
from Vorlesungen, Professoren
where gelesenVon = PersNr;
14.4.2 Allokationstransparenz Die etwas niedrigere Stufe der Unabhängigkeit besagt, dass die Benutzer zwar die
Fragmentierung kennen müssen, aber nicht den "Aufenthaltsort" eines Fragments.
Erstellt aus den einzelnen Dokumenten von den Studenten Seite 80 Zusammenfassung Datenmanagement Beispiel 1: Die Benutzer müssen jetzt wissen, dass die gewünschte Information im Fragment
ProfVerw zu finden ist.
select Gehalt
from ProfVerw
where Name = 'Sokrates';
Beispiel 2: Unter Umständen ist eine explizite (Teil)Rekonstruktion der Originalrelation
notwendig. Jemand in der Verwaltung möchte wissen, wieviel die C4-Professoren der
Theologie insgesamt verdienen.
select sum(Gehalt)
from ProfVerw, TheolProfs
where ProfVerw.PersNr = TheolProfs.PersNr and
Rang = 'C4';
14.5 Sie kennen das 2­Phase­Commit Protokoll als wichtiges Element der Transaktionskontrolle 14.5.1 Einführung in die Problematik Transaktionen können sich über mehrere Rechnerknoten erstrecken. Jeder Rechnenknoten
besitzt jeweils lokale gehaltene Protokolleinträge. Dieses Protokoll wird lokal für das Redo
und das Undo benötigt:
•
•
Redo: Wenn eine Station nach einem Fehler wiederanläuft, müssen alle Änderungen
einmal abgeschlossener Transaktionen auf den an dieser Station abgelegten Daten
wiederhergestellt werden.
Undo: Die Änderungen noch nicht abgeschlossener lokaler und globaler
Transaktionen müssen auf den an der abgestürzten Station vorliegenden Daten
rückgängig gemacht werden.
Die Redo/Undo-Behandlung ist nicht anders als im zentralisierten Fall - mit der Ausnahme,
dass nach einem Abbruch einer globalen Transaktion die Undo-Behandlung auf allen lokalen
Stationen, auf denen Teile dieser Transaktion ausgeführt wurden, initiiert werden muss.
Eine prinzipielle Schwierigkeit stellt die EOT (End-of-Transaction)-Behandlung von
globalen Transaktionen dar. Eine globale Transaktion muss nämlich atomar beendet werden,
d.h. sie wird entweder an allen (relevanten) lokalen Stationen festgeschrieben (commit) oder
gar nicht (abort).
Beispiel: Überweisungstransaktion bei einer Bank
•
•
Entweder - im Falle des commit - werden dem Konto A auf Station Sa 500,- Euro
abgezogen und dem Konto B auf Station Sb gugeschrieben oder
die Kontostände von A und B werden in ihrem ursprünglichen Zustand
wiederhergestellt - im Falle eines abort.
14.5.2 Das 2PC­Protokoll Um die Atomarität der EOT-Behandlung gewährleisten zu können, wurde das ZweiphasenCommit-Protokoll (2PC-Protokoll) konzipiert. Das 2PC-Verfahren wird von einem
Erstellt aus den einzelnen Dokumenten von den Studenten Seite 81 Zusammenfassung Datenmanagement sogenannten Koordinator K überwacht und gewährleistet, dass die n Agenten - Stationen im
VDBMS - A1, ..., An, die an einer globalen Transaktion beteiligt waren, entweder alle die von
der transaktion T geänderten Daten festschreiben oder alle Änderungen von T rückgängig
machen.
Sobald alle Aktionen der Transaktion T abgeschlossen sind, übernimmt der Koordinator K die
EOT-Behandlung, die in folgenden vier Schritten abläuft:
1. K schickt alle Agenten eine PREPARE-Nachricht, um herauszufinden, ob sie in der
Lage sind, die Transaktion festzuschreiben.
2. Jeder Agent Ai empfängt die PREPARE-Nachricht und schickt eine von zwei
möglichen Nachrichten an K:
a. READY, falls Ai in der Lage ist, die Transaktion T lokal festzuschreiben.
b. FAILED, falls Ai kein commit durchführen kann - weil z.B. ein Fehler oder
eine Inkonsistenz festgestellt wurden.
3. Sobald der Koordninator K von allen n Agenten A1, ... An ein READY empfangen
hat, kann K ein COMMIT-Nachricht an alle Agenten schicken, in der sie aufgefordert
werden, die Änderungen von T lokal festzuschreiben. Falls einer der Agenten mit
FAILED antwortet, oder ein timeout festgestellt wird, sendet K eine ABORTNachricht an alle Agenten.
4. Nachdem die Agenten ihre lokale EOT-Behandlung abgeschlossen haben, schicken sie
eine ACK-Nachricht an den Koordinator K.
5.
Beispiel: Nachrichtenaustausch zwischen Koordinator und 4 Agenten beim 2PC-Protokoll
Erstellt aus den einzelnen Dokumenten von den Studenten Seite 82 Zusammenfassung Datenmanagement •
None: DMGVerteilt erstellt durch tamarkov
Erstellt aus den einzelnen Dokumenten von den Studenten Seite 83