Prüfungsfragen

Daten und Funktionalität sind redundant, es kommt zu Inkonsistenzen.

Transaktionseigenschaften (Atomarität, Isolation) gefährdet, parallele Arbeit auf gleichen Daten von mehreren Benutzern/Anwendungen i. Allg. nicht störungsfrei möglich (Nebenläufigkeit - „Concurrency“), keine physische Datenunabhängigkeit, Datenschutz/-sicherheit nicht gewährleistet.

Weniger Aufwand, Entwicklung neuer Anwendungen ohne DB-Technologie wäre zu komplex, muss sich aus (Problemen aus Frage 1) weniger Gedanken machen

Daten mehrfach gespeichert, Probleme: Verschwendung von

Speicherplatz, „Vergessen“ von Änderungen

keine zentrale, „genormte“ Datenhaltung

Programm wird entweder ganz oder gar nicht ausgeführt

keine inkonsistenten Zwischenzustände werden sichtbar

Programm oder Folge von Kommandos, die in Interpreter

eingegeben werden

• Menge von Relationenschemata + globale Integritätsbedingungen

• DBMS: Datenbank-Management-System (ist Software zur Datenverwaltung, ein DBMS, aber mehrere (viele) Datenbanken)

• DBS: Datenbanksystem (DBMS + Datenbank)

• DB: Datenbank sind die eigentlichen Daten

• Lokale und globale Integritätsbedingungen

• Häufig vorkommende Datenbankabfragen (Queries) können unter einem „Sichtnamen“ als „virtuelle“ Tabelle gespeichert werden. (Sicht = Query (+ Name))

Er findet einen Relationenalgebra-Ausdruck, der äquivalent ist („das gleiche Ergebnis liefert“) zum gegebenen, aber effizienter auszuwerten ist.

• Externe Sicht: Unterschiedliche Ausschnitte der Daten für unterschiedliche Benutzer

• Konzeptionelles Schema: Was ist mein Diskursbereich? Welche Entitäten der realen Welt interessieren uns

• Internes Schema: physische Repräsentation der Daten

• (Vorgehen beim Entwurf: Erst konzeptuelles Schema, dann internes.)

Physikalische Organisation der DB kann geändert werden, ohne das logische Schema oder Anwendungsprogramme ändern zu müssen. (Man muss interne (physische) Repräsentation der Daten nicht kennen)

• Das logische DB-Schema kann geändert werden, ohne externe Sichten oder Anwendungsprogramme ändern zu müssen

Grad an Bedeutungstreue einer Datenbasis

Legitime Zustände durch Ausführen der Operatoren mit

Interpretation des Schemas, Einhaltung vorgegebener

Konsistenzbedingungen

Idealfall konsistenter Zustände: volle, aktuelle

Übereinstimmung von Datenbasis und Miniwelt

Menge von Tabellen und Ansichten, die bei Abfragen gelesen werden. Enthält keine Anwendungsdaten, sondern Metadaten, welche die Struktur der Anwendungsdaten beschreiben (und nicht den Inhalt selbst).

Da Schemakonsistenz vom DBMS überprüfbar ist und dadurch höhere Bedeutungstreue erreicht werden kann

Lokale/globale Integritätsbedingungen als Teil der Relationen- bzw. Datenbankschema sind konzeptionellem Schema zuzuordnen

• Weil der Bestandteil der physischen Ebene ist, welche dem internen Schema

  zuzuordnen ist

Die Möglichkeit, Wertebereiche in create Table anzugeben (bspw. Entscheidung zwischen char(n) und varchar(n)) sollte streng genommen nicht dem Anwendungsentwickler obliegen und steht somit im Gegensatz zu physischer Datenunabhängigkeit.

endliche Menge von Tupeln (= Menge von Zeilen einer Tabelle

(Instanz eines Relationenschemas))

Menge von Attributen (Tabellenkopf))

Fremdschlüsselbedingung ist Teil der Schema-Definition. Attribute tauchen im ER-Modell nur einmal auf.

• genauso viele Instanzen in beiden Fällen darstellbar

Optimieren = Verschmelzen von Relationenschemata. Bei zwingenden Beziehungen [1, _] möglich

• Doppelte Umrahmung

• Rekursive Beziehungen: Kardinalitäten der referenzierten Entitäten sind schwer darstellbar

• Partitionierung, Generalisierung: Generalisierung und Disjunktheitsbedingungen mit Schlüsseln und Fremdschlüsseln nicht ausdrückbar

• Umbennenung von Attributen und Relationen.

  Wichtig, um folgendes zu ermöglichen: § Joins von unterschiedlichen benannten Relationen,

  • §  kartesische Produkte, wo es gleiche Attributnamen gibt, insbesondere

    auch mit der gleichen Relation, und

  • §  Mengenoperationen zwischen Relationen mit unterschiedlichen

    Attributen

SELECT Region, count(*) AS Anzahl

FROM Erzeuger

NATURAL JOIN Weine

GROUP BY Region

HAVING count(*) > 1

A=A ist bei Vorliegen von Nullwerten keine Tautologie, sondern ergibt unknown

In Relation R(X,Y) ist Y von X funktional abhängig, falls zu jedem Wert von X genau ein Wert von Y gehört.

die Originalrelationen können durch Verbund der

Basisrelationen wiedergewonnen werden

nur semantisch sinnvolle und konsistente Anwendungsdaten können dargestellt werden können (Menge der erfassten Abhängigkeiten äquivalent zur Menge der im System darstellbaren Abhängigkeiten (etwa Schlüssel und Fremdschlüssel))

minimale Anzahl von Relationenschemata, die die anderen Eigenschaften erfüllt.

• Einfügeanomalie: Null-Werte bei unvollständigem Eintrag möglich.

• Updateanomalie: Ändern mehrerer Einträge erforderlich – aufwendig, fehleranfällig.

• Löschanomalie: Mehr Information als gewünscht kann verloren gehen.

• 1NF: nur atomare Attribute

• 2NF: keine partielle Abhängigkeit eines Nicht-Primattributes von einem Schlüssel

• 3NF: keine transitive Abhängigkeit eines Nicht-Primattributes von einem Schlüssel

• 4NF: keine nichttrivialen MVDs zulassen. (d.h. Relation soll aufgespalten werden)

• BCNF: alle FDs sind durch Schlüssel impliziert

Unkontrollierte nicht-serielle Ausführung führt zu Problemen, insbesondere Inkonsistenz.

Inkonsistenz, Lost Updates, inkonsistente Lesezugriffe („non-repeatable read“), Dirty Reads, d. h. Reads von Updates, die noch nicht committet sind. Phantome

Wenn wir eine Ausführung haben, die korrekt ist, aber diese Ausführung aufgrund eines Systemabsturzes nicht korrekt zu Stande kommt, bleibt die commited projection übrig. Wenn das Korrektheitskriterium die Eigenschaft prefix commit closedness hat bedeutet das, dass das, was übrig bleibt, auch diese Korrektheitseigenschaft hat, ist also korrekt in unserem Sinne.

Wenn wir wissen, dass unser Korrektheitskriterium prefix commit closed ist, dann ist automatisch gegeben, dass die Korrektheit auch nach einem Systemausfall weiterhin gegeben ist.

Wenn es für eine History möglich ist, eine äquivalente, serielle Ausführung zu finden, dann ist das für ein Präfix auch möglich. (Das finden einer seriellen Ausführung ist im Fehlerfall nach Zurücksetzen unvollständiger Transaktionen sogar einfacher)

Serialisierbarkeit: H ist serialisierbar, wenn C(H) zu serieller History HS äquivalent ist.

• Serialisierbarkeit von Schedules nur im nachhinein überprüfbar.

• Administrativer Overhead ist zu hoch: Abhängigkeiten zu bereits terminierten Transaktionen müssen ebenfalls berücksichtigt werden.

Sowohl (a) und (b): ja. Bspw. Zählen, wie oft eine Transaktion schon zurückgesetzt wurde.

Die zeitliche Reihenfolge der Commits ist c1 vor c2 vor c3, die der äquivalenten seriellen Ausführung jedoch c3 vor c2 vor c1.

Kriterien bspw. Transaktionen mit Priorität versehen, Zeitstempel, ..., beliebige Kriterien möglich

• Optimierbarkeit: Bestehend aus wenigen Operationen, für die es Optimierungsregeln gibt

• Effizienz: Jede Operation ist effizient ausführbar (Im Relationenmodell hat jede Operation eine Komplexität ≤ O(n2) mit n Anzahl der Tupel einer Relation)

• Mengenorientiertheit: Jede Operation soll auf Mengen von Daten gleichzeitig arbeiten, nicht navigierend nur auf einzelnen Elementen (one-tuple-at-atime)

Die Reihenfolge, nach der zwei Relationen miteinander verbunden werden. Reihenfolge ist wichtig, da (1) das Ergebnis davon abhängt und (2) die Reihenfolge Einfluss auf die Zeit zur Berechnung hat. Gute Join-Reihenfolge ist abhängig von den Daten in den Relationen und schwierig zu erkennen. Keine Festlegung der Join-Reihenfolge in SQL

Algorithmen des logical/physical/cost-based optimization anwenden.

Implementierung der anwendungsspezifischen Funktionen, Bereitstellung von „Geschäftsobjekten“

Iterator

ist Datenbankschnittstellen-Spezifikation für den Zugriff auf relationale Datenbanken aus anderen Anwendungen heraus.

Variablen einer Host-Sprache (hier bspw. Java) die in SQL-

Anweisungen auftreten können

Vorübersetzung der eingebetteten SQL-Anweisung in echten JAVA Code durch Übersetzer sqlj erlaubt Syntax- und Semantik-Check der Statements zur Übersetzungszeit. Es gibt jedoch keine Garantie, dass sich das Schema zur Laufzeit nicht geändert hat.

• Optimierung durch DBMS einfacher möglich, da Prozeduren nur vom DBMS abhängig sind

• zentrale Kontrolle der Prozeduren ermöglicht eine redundanzfreie Darstellung relevanter Aspekte der Anwendungsfunktionalität

• Konzepte und Mechanismen der Rechtevergabe des DBMS können auf Prozeduren erweitert werden

• Prozeduren können in der Integritätssicherung verwendet werden (etwa als Aktionsteil von Triggern)