• Fehlende Datenunabhängigkeit (änderung des Dateiformats)
• Redundanz (u.a. Änderungsanomalien)
• Schnittstellen (Jeder kocht sein eigenes Süppchen)
• Mehrbenutzer System
• Datenverlust bei Systemabsturz/deffekt
• Zugriffkontrolle

• DB-Anwendung
• DBS
  • DBMS
  • DB

• Integration einheitlicher Zugriff auf alle Daten einer Anwendung
• Operationen auf den Daten (ändern, löschen, …)
• Data Dictionary Schema anschauen
• Benutzersicheten views
• Konsistenzüberwachung bei Änderung
• Zugriffskontrolle
• Transaktionen
• Synchronisation (Mehrbenutzersystem)

• Data Definition Language
• Data Manipulation Language

• Objekte der Datenbank
• Beziehungen zwischen verschiedenen Objekten
• Integritätsbedingugen
• Angebotenen Operationen (zum Abfragen)

• Hierarchisches ~
• Netzwerk ~ (Art linked list, was den parent im link Ring beinhaltet)
• Relationales ~
• Objektorientiertes ~
• Objekt-Relationales ~

• API
• DSL

Query in Funktionsbaum übersetzten

• Kaskadierter Kartesische Produkte (nur 2 Eingänge)
• Jede WHERE Bedingung einzeln

Beispiel

SELECT A1, A2
FROM R1, R2, R3
WHERE B1, B2

Ergibt $\pi_{A_1, A_2}(\sigma_{B_1}(\sigma_{B_2}(R_1 \times (R_2 \times R_3))))$

Optimierung: Filter so früh wie möglich

• Logische Anfrageoptimierung
  Auswertungsplan umbauen
• Physische Anfrageoptimierung
  • Join Strategie
    • Nested Loop
      Kartesisches Produkt Filtern
    • Sort Merge
      Vorher Sortieren, dann mergen
    • Indexed Loop
      Tabelle 1 abarbeiten, Tabelle 2 über Index mergen
  • Index Verwenden?

• Regelbasiert
  Heuristiken
• Kostenbasiert
  Iterativ Heuristiken ausprobieren und Kostenentwicklung beobachten

• Atomicity
• Consistency
• Isolation
• Durability

Technische Fehler

• Statische Integrität
  Einschränkung der Datenbankzustände
• Dynamische Integrität
  Einschränkung der Zustandsübergänge
• Modellinhärente Integrität
  • Typintegrität
  • Schlüsselintegrität
  • Referentielle Integrität

Non-repeatable read mit Aggregiertem read

Graph Zeichen

• Knoten: Transaktionen
• Kanten: Abhängigkeiten

Kein rr(x)

Zyklenfrei? ⇒ Serialisierbar durch topologisches sorieren

• Pessimistische Ablaufsteuerung (Locking)
• Optimistische Ablaufsteuerung (Zeitstempelverfahren)
  Notfalls rollback

• Call-Level-Schnittstelle (library)
• Embedded SQL

1. Declaration
   SQL eingeben
2. Open
   Ausführen
3. Fetch loop
4. Close

Vorübersetzes SQL mit Platzhaltern

• Partielle funktionale Abhängigkeit: $X \rightarrow Y$
• Volle funktionale Abhängigkeit: $X \dot{\rightarrow} Y$ (Minimalität)

AttrHülle(F,X) mit
F = FDs
X = Start Attributmenge

Starte mit X und wende so lange F ab, bis nichts mehr geht. (“Schau wie weit du kommst”)

• Update~
  Nicht alles wird geupdatet
• Insert~
  Inkonsistentes insert
• Delete~
  Löschen der letzten Verwendung, löscht auch Objekt

Bedingung

Alle Attribute atomar

Attributwerte dürfen nicht …

• Listen sein: {Telefon1, Telefon2, Telefon3, …}
• Zusammengesetzt sein: (Hausnummer, PLZ, …)

Bedingung

Jedes Attribut entweder
voll funktional Abhängig von jedem Schlüsselkandidaten
– oder –
prim (teil eines Schlüsselkandidaten)

Trivial: nur ein einelementiger Schlüsselkandidat ⇒ 2. NF

Sonst: Vom Schlüssel nicht voll funktional Abhängige Attribute werden herausgelöst, in eigene Tabelle

Bedingung

1. Kanonische Überdeckung
   1. Linksreduktion
      Komme ich von X-x und identischem FD dennoch auf Y, dann streiche x aus X
   2. Rechtsreduktion
      Komme ich von X und FD ohne y dennoch auf y in Y, dann streiche y aus Y
   3. $X \rightarrow \emptyset$ entfernen
   4. Gleiche X zusammenfassen
2. Relationsschema erzeugen und FDs zuweisen
   1. Aus jedem FD erzeuge eine Relation mit X als Primärschlüssel und Y als Attribute
   2. Ordne jedes FD den Relationen zu, die alle seine “Buchstaben” enthält
3. Schlüsselkandidat rekonstruieren
   Stelle sicher, dass eine Relation einen ehemaligen Schlüsselkandidaten enthält, notfalls erzeuge eine neue mit leerem ohne zugeordnete FDs
4. Überflüssige Relationen eliminieren
   Lösche Relationen, die Teilmenge einer anderen sind.

Bedingung

Wirkung

Nicht mehrere Tabellen in einer.

Bedingung

MVD (Multi Valued Dependency): Mehre Attributwerte, eines Attributs, sind von der linken Seite abhängig.

• Domain
  • = Typ
  • Kann auch Liste Sein
  • endlich
  • unendlich (nicht in DB Darstellbar)
  • z.B. Int, Sting, Date, {rot, gel, käsekuchen}
• Relation = Ausprägung eines Relationsschemata = Menge = {}
• Tupel = Zeile = Ausprägung einer Relation = ()
• Grad = Stelligkeit = Elemente im Tupel
• Relationsschema: Über eine Tabelle
• DB-Schema: Über alle Tabellen

1. Eindeutig
   $t_1 \ne t_2 \Rightarrow \pi_S(t_1) \ne \pi_S(t_1)$
   Unterschiedliche Tupel ⇒ Unterschiedliche Schlüssel
2. Minimal
   $\text{Eindeutig}(T) \wedge T \subseteq S \Rightarrow T = S$
   Keine Teilmenge des Schlüssels erfüllt die 1. Eigenschaft

(Minimal bedeutet nicht: Die wenigsten Attribute)

Schlüssel und FD sind semantische Eigenschaften (nicht anhand von aktueller Ausprägung erkennbar)

• Superschlüssel: Nur 1. Eigenschaft erfüllt ($S \rightarrow R$)
• Schlüsselkandidat: 1. und 2. Eigenschaft erfüllt ($S \dot{\rightarrow} R$)
• Primärschlüssel: Ein beliebiger aber fester Schlüsselkandidat

Primes Attribut: Teil eines Schlüsselkandidaten

Beispiel: Beweise das S = (A, B) Schlüsselkandidat ist.

1. Eindeutigkeit
   $S \rightarrow R$ herleiten
2. Minimalität
   Zeigen das weder $A \rightarrow R$ noch $B \rightarrow R$ gild

Formel	Name	Iden- tisch	Duplikat- elimi- nation	SQL	Kommentar
$A \cup B$	Vereinigung	X	X	UNION UNION ALL	Duplikatelimination in SQL nur bei UNION
$A - B$	Differenz	X		EXCEPT MINUS
$A \times B$	Kreuzprodukt Kartesisches Produkt
$\sigma_F(A)$	Selektion			WHERE
$\pi_{a, b, \dots}(A)$	Projektion		X	SELECT
$A \cap B$	Durchschnitt	X		INTERSECT
$A \div B$	Quotient				Allquantor. Die Tupel aus A, die alle Attribute aus jedem B Tupel gleich haben, ohne die B Attribute.
$A \bowtie B$	Natural Join			NATURAL JOIN t	Inner-Join (Tupel ohne Partner gehen verloren) Vergleich aller gleichbenannten
$A \underset{a = b}{\bowtie} B$	Equi Join		X	JOIN t USING(id)	Inner-Join (Tupel ohne Partner gehen verloren)
$A \underset{a \Theta b}{\bowtie} B$	Theta Join			JOIN t ON f	Inner-Join (Tupel ohne Partner gehen verloren) Θ = Vergleichsoperator

Identisch

• Relationale Algebra: Typ und Name jedes Attributs muss übereinstimmen (Schemata identisch)
• SQL: Typ jedes Attributs muss kompatibel sein (nur die Position ist maßgebend)

• Für jeden relationalen Ausdruck existiert ein SQL statement (SQL ist relational vollständig)
• SQL Projektion entfernt nicht immer Duplikate implizit (Explizites DISTINCT bei umsetzung!!)
• SQL kann mehr: Sortieren, Aggregation

t ∈ Schema ⇔ Schema(t) t[A] ⇔ t.A

Ψ(r | t): Ersetze t in Ψ(r | t) mit dem konkreten Tupel r

• Relationale algebra
  prozedual (wie)
• Relationen-Kalkül
  deklarativ (was)
  • Tupelkalkül: Variable = ein Tupel
  • Bereichskalkül: Variable = einfacher Typ

Quantoren sind nur im Relationenkalkül möglich.

Variable ist …

• frei: keinem ∃ oder ∀ zugeordnet
• gebunden: einem ∃ oder ∀ zugeordnet
• Zuordnungszustand kann sich ändern

Es ist möglich unendlich (nicht speicherbare) Relationen zu beschreiben.
Eine Relation ist sicher wenn alle Vaiablen x einer (gespeicherten) Relation angehören Schema(x).

Jeder zusätzlich Schlüssel wirkt sich negativ auf updates aus.

• Datenorganisierende Strukturen
  Suchbaumverfahren (B+-Baum)
• Raumorganisierende Strukturen
  dynamische Hash-Verfahren

Seitenarten (für Daten- und Raumorganisierende Strukturen)

• Directoryseiten
  Verweis auf Datenseiten
• Datenseiten
  Die eigentlichen Daten

Schlüsselarten

• Primärschlüsselsuche
  • B+-Baum
  • Lineares Hashing
• Sekundärschlüsselsuche
  • Invertierte Listen

• Alle Daten ausschließlich in den Blättern (Datenseiten)
• Schlüssel (Seperatoren) kommen mehrfach in Directoryseiten vor.
• Mit rechtem Bruder ausgleichen

• Ordnung m
• Wurzel: 1 … 2m Kinder
• Knoten: m … 2m Kinder

• Die Zahlen geben an, wie viele Bits “beachtet” werden müssen.
• Die Zahl des Diresctorys ist immer größer-gleich der Zahl der Datenseiten, ansonsten Directory Zahl inkrementieren & Directory verdoppeln
• Läuft eine Datenseite über ⇒ Split + Zahl inkrementieren

$\text{Belegungsfaktor} = \frac{\text{Alle Schlüssel}}{\text{Kapazität in \textit{Primär}seite}} > 0.8 \Rightarrow \text{Expansion}$

• Alle Attribute einzeln indizieren
• einzeln suchen
• Schnittmenge der Ergebnislisten bilden

• Für LIKE “Horst%”

mehrere Attribute

• Attributwerte werden concatiniert sortiert gespeichert
• Reihenfolge wichtig

Elemente:

• Entitie (eckig)
• Relationship (raute)
  • Können Attribute haben
• Attribute (oval)
  • Primärschlüssel unterstreichen
• (strich)
  • Können Rollen haben
  • Pfeil = 1-KArdinalität
  • Voller Kringel: 1.. / NOT NULL
  • Hohler Kringel: 0.. / NULL
• Vererbung (Pyramide)
  • Text: “isa”

Umsetzen:

• Vererbung
  • Eine gemeinsame Tabelle
    – ODER –
  • “isa” in einzelne Relationen auflösen
• 1:1 Relation
  1. Beide Relationen zusamenfassen
  2. Nur einer der alten Primärschlüssel wird der neue Primärschlüssel

http://www.postgresql.org/docs/9.2/static/datatype-numeric.html

• NOT NULL
• PRIMARY KEY
• UNIQUE
• REFERENCES t(a)
• DEFAULT w
• CHECK f

• PRIMARY KEY (a1, a2, …)
• UNIQUE (a1, a2, …)
• FOREIGN KEY (a1, a2, …) REFERENCES t(b1, b2, …)
• CHECK f

• Schlüsselkandidat
  • UNIQUE
  • UNIQUE (a1, a2, …)
• Primärschlüssel
  • PRIMARY KEY
  • PRIMARY KEY (a1, a2, …)
• Fremdschlüssel
  • REFERENCES t(a)
  • FOREIGN KEY (a1, a2, …) REFERENCES t(b1, b2, …)

Folgende sachen können am Ende einer REFERENCES Angabe stehen

• ON DELETE SET NULL
  Wenn das Referenzierte gelöscht wird, wird dieser auf NULL gesetzt
• ON DELETE CASCADE
  Wenn das Referenzierte gelöscht wird, wird auch dieser gelöscht
• ON UPDATE CASCADE
  Wenn das Referenzierte geändert wird, wird auch dieser geändert

• % 0…n beliebige Zeichen
• _ 1 beliebiges Zeichen

CREATE TABLE name (
  name typ constraints,
  name typ constraints,
  integritätsbedingungen
)

DROP TABLE name

ALTER TABLE name ADD (
  name typ constraints,
  name typ constraints
)

ALTER TABLE name DROP (
  name,
  name
)

ALTER TABLE name MODIFY (
  name typ constraints,
  name typ constraints
)

SELECT [DISTINCT]
  *,
  t.*,
  t.a,
  42,
  32 AS Foo    -- Hier AS
FROM
  t,
  Unisinn u,   -- KEIN AS
  (SELECT ...)
WHERE

INSERT INTO name [(a1, a2)]
VALUES
  (v11, v21),
  (v12, v22)

INSERT INTO name (a1, a2)
(SELECT ...)

UPDATE name
SET
  a1=v1, 
  a2=v2
[WHERE ...]

DELETE FROM name
[WHERE ...]

GRANT
  ALL
  ALL PRIVILEGES
  SELECT
  INSERT
  DELETE
  UPDATE
  UPDATE(a, b)
ON
  t
TO
  TU PUBLIC,
  userName
[WIDTH GRANT OPTION]

REVOKE
  ALL
  ALL PRIVILEGES
  SELECT
  INSERT
  DELETE
  UPDATE
  UPDATE(a, b)
ON
  t
FROM
  TU PUBLIC,
  userName
[RESTRICT | CASCADE]  -- RESTRICT: Nur den user löschen
                      -- CASCADE: nehme die rechte auch denjenigen, die sie vom user bekommen haben

CREATE INDEX name ON t (a1, a2, ...);
DROP INDEX name;

-- Laut script kein START TRANSACTION
SET TRANSACTION READ-ONLY  -- kein INSERT, UPDATE und DELETE. Dafür bessere Transaktionsplanung
SET TRANSACTION READ-WRITE -- default
SAVEPOINT name
COMMIT
ROLLBACK
ROLLBACK TO name

• inner
• outer
  • left
  • right
  • full

WHERE EXISTS (SELECT ...)             -- Ergebnis Form egal
WHERE NOT EXISTS (SELECT ...)         -- Ergebnis Form egal
WHERE ... a Θ ALL (SELECT ...)        -- Ergebnis genau ein Attribut, aber mehre Tupel
WHERE ... a Θ SOME/MANY (SELECT ...)  -- Ergebnis genau ein Attribut, aber mehre Tupel
WHERE ... a IN (SELECT ...)           -- Ergebnis genau ein Attribut, aber mehre Tupel

GROUP BY x
HAVING SUM(y) > 42

keine Aggregartfunktionen in WHERE

In SELECT nur erlaubt

• Groupierte Attribute
• Aggregatfunktionen
  • COUNT
  • SUM
  • AVG
  • MAX
  • MIN

In SELECT nicht erlaubt

• *
• An groupierte Elemente gejointe Elemente, die selbst nicht groupiert sind.
  Abhilfe:
  • Auch nach denen groupieren
  • MAX(x)

ORDER BY a [ASC/DESC], b [ASC/DESC], ...

• ASC: 0, 1, 2, … (default)
• DESC: 9, 8, 7, …

Typ jedes Attributs muss kompatibel sein

• Nur die Position ist maßgebend
• Länge bei Strings egal
• Genauigkeit bei Zahlen egal

[Im Gegensatz zur relationalen Algebra, wo Typ und Name jedes Attributs übereinstimmen muss (Schemata identisch)]

$A \cup B$	Vereinigung	UNION [CORRESPONDING]	mit Duplikatseliminierung
	Vereinigung	UNION ALL [CORRESPONDING]	ohne Duplikatseliminierung
$A - B$	Differenz	EXCEPT [CORRESPONDING] MINUS [CORRESPONDING]
$A \cap B$	Durchschnitt	INTERSECT [CORRESPONDING]

SELECT ...
UNION/UNION ALL/EXCEPT/MINUS/INTERSECT [CORRESPONDING]
SELECT ...

• CORRESPONDING beschränkt Ergebniss auf gleiche Namen. Die Position ist dann egal.
• Besser: Explizite Auswahl/Sortierung mit SELECT
• Tip: Explizites NULL in SELECT bei fehlenden Werten.

Nutzen

• Übersicht
• Datenschutz

CREATE [OR REPLACE] VIEW v AS SELECT ...
DROP VIEW v

Nicht erlaubt in Basisrelation:

• ORDER BY

INSERT INTO mv (SELECT ...)

Kein merkbarer unterschied zwischen View und Relation

Finde Paare mit gleicher Eigenschaft <code sql> SELECT DISTINCT t1.name, t2.name FROM Foo t1, Foo t2 WHERE

t1.attrib = t2.attrib
AND
t1.name < t2.name  -- Macht aus  (AA, AB, BA, BB) : (AB)