• 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

• 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

• Superschlüssel: Nur 1. Eigenschaft erfüllt
• Schlüsselkandidat: 1. und 2. Eigenschaft erfüllt
• Primärschlüssel: Ein beliebiger aber fester Schlüsselkandidat

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).

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

• 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)