Dbs1 - HSR Teil 2

Multi Version Concurrency Control

Schreiber blockieren keine Leser, Leser blockieren keine Schreiber

Schreiber blockieren andere Schreiber, welche dasselbe Tupel modifizieren wollen

Beim Update werden Tupels mit x-Locks versehen --> Deadlocks möglich

Beim Lesen werden keine Locks gesetzt

Jeder Update führt zu einer neueren Version des Tupels

ein Statement liest nur Daten mit derselben Version

die ganze Transaktion liest nur Daten mit derselben Version

Wird nicht unterstützt

koordiniert die von den Applikationen gestarteten Transaktionen

ist für parallelität von Transaktionen zuständig

ist bei Fehlern welche zum Abbruch der transaktion zuständig dafür, dass die Daten in einem konsistenten zustand sind. Führt ein Log File

ist zuständig für interne DB Puffer und stellt mit Storage Manager Transfer von Daten zwischen Haupt und Sek. Speicher sicher

transaktionen schreiben Änderungen in DBMS Puffer. Hintergrundprozess in Sekundärspeicher

1. Data Definition Language (DDL) - CREATE, ALTER, DROP, TRUNCATE, COMMENT, …
2. Data Manipulation Language (DML) - SELECT, INSERT, UPDATE, DELETE
3. Date Control Language (DCL) - GRANT, REVOKE
4. Transaction Control Language (TCL) - COMMIT, ROLLBACK, SAVEPOINT, SET TRANSACTION
 

Transaktionen sperren sich gegenseitig aus

T1= W1(x)W1(y)

T2=W2(y)W2(x)

Timeout - Nach einer bestimmten Wartezeit brechen die Transaktionen ab

Deadlock Erkennung - Abbruch einzelner Transaktionen (Opfer) bei Deadlock

Transitive Hülle ist:

• A ist Vorgesetzer von B, C, D, E
• B ist Vorgesetzter von C, D, E
• C ist Vorgesetzter von D, E

Mit Hilfe von Normalisierung kann redundanzfreiheit eines Datenmodells überprüft werden Ansammlung von Unstrukturierten Attributen in Tabellen zu strukturieren

Eine Funktionale Abhängigkeit zwischen Attribut Y und Attribut X liegt dann vor, wenn es zu jedem X genau ein Y gibt

Eine vollständig funktionale Abhängigkeit liegt dann vor, wenn das Nicht-Schlüsselattribut nicht nur
von einem Teil der Attribute eines zusammengesetzten Schlüsselkandidaten funktional abhängig ist,
sondern von allen Teilen eines Relationstyps. Die vollständig funktionale Abhängigkeit wird mit
der 2. Normalform (2NF) erreicht.
 

Eine transitive Abhängigkeit liegt dann vor, wenn Y von X funktional abhängig und Z von Y, so ist Z
von X funktional abhängig. Diese Abhängigkeit ist transitiv. Die transitive Abhängigkeit wird mit 3.
Normalform (3NF) erreicht.
 

Jede Tabelle hat einen Primärschlüssel

Atomare Werte in den Tupeln.

Von der 0. NF auf die 1. NF, Tupeln aus z.b Kommagetrennten Werten aufteilen

( | Peter, Meier | -> | Peter | Meier | )

Jede Tabelle welche keine zusammengesetzten Schlüssel hat, ist automatisch in der 2. Normalform.

Von der 1. NF auf die 2. NF kommt man indem man einen eindeutigen Schlüssel setzt pro Tabelle. Zusammengesetzte Schlüssel aufteilen in separate Tabellen und Attribute die von einem Teilschlüssel abhängig sind in andere Tabelle verschieben.

Verhindert, dass Teile zweier aus mehrerer Feldern zusammengesetzten Schlüsselkandidaten voneinander abhängig sind.

Probleme: Performanzprobleme bei Anfragen über mehrere Tabellen, komplizierter Zugriff
Beispiele: Webdatenbanken, Data Warehouses
Lösung: Denormalisierung in 2. NF
• Vertretbar wenn sich abhängige Eigenschaften selten ändert
• Aspekt des physischen Modells
• Modellierung eines kaum gebrauchten Objekttyps entfällt
 

DROP USER if exists fussballclub;

CREATE USER fussballclub WITH PASSWORD 'fussballclub';

Schemas unterteilen eine Datenbank in Namensräume.

Fasst CREATE und GRANT Anweisungen zusammen.

• DB-weit eindeutiger Identifier "Schemald"
• Tabellen, Views, Indices, Stored Procedures, Triggers, Synonyms, Sequences
• Jedes DB-Objekt hat einen DB-weit eindeutigen Identifier "Schemald.ObjectID"