Datenbanksysteme
Datenbanken lassen sich mittels verschiedenen Abstraktionsschichten beschreiben: Conceptual, Logical und Physical. Sprachen zur Beschreibung nennt mensch auch DDL ("data definition language"). Um Daten abzufragen oder zu manipulieren benutzt man eine DML ("data manipulatiion languge").

Conceptual
In der Entwufsschicht wird versucht Daten einer Applikation in einem sogenannten Schema zu strukturieren. Hierbei werden sogenannten Entitäten mit Attributen verwendet. Entitäten haben keine, eine oder viele Beziehungen zu sich selbst (Rekursion) oder anderen Entitäten. Die Anzahl der möglichen teilnehmenden Entitäten in einer Beziehungsrelation wird Kardinalität genannt. Ähnlich der Objektorientierung können Entitäten von anderen erben. Eingesetzt wirds dies bei der Generalisierung (generalization) und Spezialisierung (specialization). Hier wird versucht  Redundanz (Überschneidung von Informationen) möglichst zu vermeiden.

 * Modeliere nicht mehr als ein Objekt aus der Realität in eine Entität/Relation

Logical
In der Logikschicht wird das Entwufsmuster, zum Beispiel in UML oder ERM vorliegend, in eine logische Form gebracht. Das Ergebnis ist meist ein relationales Datenmodel (RDM).

Physical


Basic modeling primitives
 * Entity (Typ)
   * Weak entity: Eine schwache Entität ist ein Typ, der  durch seine Attribute und der Beziehung zu einer anderen Entität identifizierbar ist. Sie kann nicht ohne der Beziehung existieren.
   * Aggregation: verschiedene Entitäten formen zusammen eine neue Entität
     * Komposition: Ist ein Verschärfung der  Aggregation. Sie beschreibt die Beziehung zwischen einem Ganzen (Entität  A) und seinen Teilen (Entität B). Entität B kann ohne A nicht  existieren. Desweiteren muss A sich um die Integrität von beiden  Entitäten kümmern.
 * Attribute (Eigenschaft)
 * Relationship (Beziehung)
   * besitzen immer einen Namen
   * haben keine Richtung (immer bidirektional)
   * können Attribute besitzen
   * besitzen keine Schlüsselattribute  (zur Identifizierung von Einträgen)
   * n-ary Relationship: mehr als 2 Entitäten sind mit einbezogen
 * Cardinality constraints: Legt fest wieviele Beziehungen eine Entität zu anderen (einschließlich sich selbst) haben   kann.
     * Notationsmöglichten:   (min, max)-, 1:N- oder UML+-Notation
     * Kardinalitäten lassen sich Mittels   Relationen mathematisch ausdrücken

Graphische Modellierungssprachen
Entity-Relationship-Model (ERM)
ERM ist ein Daten orientiertes Model. Es wurde 1976 von P. P. Chen vorgestellt. Aufgrund der fehlenden Unterstützung von Operationen wird es als ein statisches Model angesehen. Die graphischen Notationen sind Rechtecke für Typen (Entities), Ellipsen für Attribute und Rauten für Beziehungen zwischen Typen. Anzumerken ist, dass Beziehungen immer bidirektional (beide Richtungen) sind.

Unified modeling language (UML)
UML unterstützt die Modellierung von Daten und Operationen. Es wird nach einem objektorientierten Stil modelliert. Uni- sowie bidirektionale Beziehungen werden unterstützt. Beziehungsrichtungen besitzen Namen (sogenannte Rollen). Kardinaltitätsbedingungen werden "multiplicity" genannt. Jeder Typ hat eine einzigartige Adresse (pointer) und somit können Typen mit gleichen Attributen im Gegensatz zum ERM unterschieden werden. Aufgrund der einzigartigen Adressen gibt es keine Schlüssel und somit können "weak entities" nicht modelliert werden.

Begriffsdefinitionen
 * Klasse = Entitätstyp
 * Objekt = Entität
 * Assoziation = Beziehung

Relationales Datenmodel 
In einem Relationale Datenmodel werden die Relationen in Form von Tabellen dargestellt. Jeder Spaltenname steht für Attribut. Die Zeilen sind die Relationstupel.

Eigenschaften:
 * Doppeleinträge sind nicht erlaubt
 * Es gibt keine Tupel-Reihenfolge
 * Attribute haben einen primitiven Datentyp. Sie müssen nicht unbedingt einen Wert haben (null Wert)
 * single-valued
 * eindeutige Namen

Ein Schlüssel ist eine minimale Untermenge seiner Attribute, mit denen eine Zeile (Tupel) einer Tabelle (Relation) eindeutig indentifizierbar ist. Es ist durchaus möglich, dass es mehrere Schlüsselkandidaten gibt. Jeder einzelne Schlüsselkandidat kann als Primärschlüssel fungieren.

Ein Fremdschlüssel ist ein Attribut mit denen Relationen zwischen Entitäten realisiert werden. Der Fremdschlüssel zeigt immer auf den Primärschlüssel der in relationstehenden Entität. Er muss einen Wert oder null besitzen.

Multi-valued Attribute werden mit HIlfe von Weak Entities realisiert. Die Entität A hat ein multi-value Attribut C. C ist ein Fremdschlüssel auf eine eigene Entität C'. 

Beziehungen
1:N - One to Many - Entität A steht zu Entität B in einer 1:N Beziehung
Entität A muss als Attribut einen Fremdschlüssel auf den Primärschlüssel von Entität B besitzen.

N:M - Many to Many - Entität A steht zu Entität B in einer N:N Beziehung
Um eine N:M-Relation zu realisieren braucht man eine separate Relationstabelle. In dieser werden jedem Primärschlüssel von A ein Primärschlüssel von B zugeordnet. Es handelt sich hierbei um eine "N-ary relationship".

Consolidation
Um ein Datenbankschema zu vereinfachen können Tabellen mit dem gleichen Primärschlüsseln in eine neue Tabelle zusammengefasst werden. Diesen Vorgang nenntn man Konsolidierung (Consolidation) oder auch Vereinfachung (simplification).

Bsp: R(k1,..,kn, a1,...an), S(k1,...,kn, b1,...bm) ⇒ RS(k1,...,kn, a1,...an,b1,...,bm)

Nichtkonsolidierung von 1:N-Beziehungen
 * Wenn viele NULL-Werte erwartet werden
 * Wenn gewisse Attribute selten genutzt werden

N:M-Beziehungen sollten niemals zusammengeführt werden!

Simple Query Langauge - SQL
Beschreibung ... Definition

Datentypen
SQL2
 * NUMERIC (p,s)
 * DECIMAL (p,s)
 * INTEGER
 * SMALLINT
 * FLOAT (p,s)
 * REAL
 * DOUBLE PRECISION
 * CHARACTER [(n)] CHAR
 * CHARACTER VARYING (n) = VARCHAR (n)
 * NATIONAL CHARACTER (n) | NCHAR (n)
 * NCHAR VARYING (n)
 * BIT [(n)], BIT VARYING , BOOLEAN
 * DATE (DATE '2001-5-2')
 * TIME (TIME '01:00:05.011')
 * TIMESTAMP
 * INTERVAL

SQL99
 * CHARACTER LARGE OBJECT = CLOB
 * NATIONAL CHARACTER LARGE OBJECT = NCLOB
 * BINARY LARGE OBJECT = BLOB

Löschen von Tabellen/Datenbanken
Schemainformationen werden mittels DROP-Statement gelöscht.

DROP TABLE <name> [restrict|cascade]
DROP DATABASE <name>

restrict = Löscht zuerst die Referenzen
cascade = Löscht Tabelle und Referenzen

Contraints / Bedinungen
Wertbedingungen (value constraings) schränken mögliche Werte eines Attributs ein (Bsp: not NULL)
Integritätsbedingungen (integrity constraints) sind Invarianten einer Datenbank.In jedem möglichen gültigen Zustand der Datenbank sind diese erfüllt. Sie  schränken somit den Zustand  der Datenbank ein.

Syntax: CONSTRAINT <name> <def> [ON DELETE/UPDATE <option>] [DEFERED|IMMEDIATE]

Constraintarten:
 * UNIQUE (<attribute1>,...,<attributeN>)
 * PRIMARY KEY (<key1>,..,<keyN>)
 * CHECK(<bedingung>)
 * FOREIGN KEY (<key>) REFERENCES (<Table>.<key>)

Um die Integrität einer Datenbank bei Schlüsselveränderung weiterhin zu garantieren gibt es die die ON DELETE- und ON UPDATE-Statements.
Mögliche Optionen sind CASCADE (alle referenzierte Tupel), SET NULL oder DEFAULT.

Um Kreisbedingungen (Huhn-Ei-Problem) zu ermöglichen, können Constraints auch nach der Tabellenerstellung mit TABLE ALTER <Tabellenname> ADD|MODIFY ... hinzugefügt werden. 

CREATE TABLE chicken(cID INT PRIMARY KEY,
                     eID INT);
CREATE TABLE egg(eID INT PRIMARY KEY,
                 cID INT);

ALTER TABLE chicken
    ADD CONSTRAINT chickenREFegg
    FOREIGN KEY (eID) REFERENCES egg(eID);
ALTER TABLE egg
    ADD CONSTRAINT eggREFchicken
    FOREIGN KEY (cID) REFERENCES chicken(cID) ;

Probleme treten hier nun aber beim Einfügen von Daten auf. Abhilfe kann hier die DEFERRABLE-Option sein. Damit lassen sich sogenannte Transaktionen ermöglichen. Eine Transaktion kann mehrere SQL-Statements beinhalten. Die Constraints werden erst aber nach dem ausführen aller SQL-Statements überprüft. Transaktionen müssen immer mit dem COMMIT; abgeschloßen werden.

Variante:
 * INITIALLY DEFERRED DEFERRABLE
 * INITIALLY IMMEDIATE DEFERRABLE

Assertions / Annahmen

Trigger / Auslöser

Metadata

Virtual Tables / Views
Views sind ein Konstrukt um virtuelle Tabellen zu ermöglichen. Nützlich können Views sein um bessere Performance bei vielen Lesevorgängen zu erzielen.
View integration: Integration of  Conceptual models, which are related but have been designed separately,  into one single mod

Funktionale Eigenschaften
Funktionale Abhängigkeiten generalisieren das Schlüsselkonzept. Sie können zur Formalisierung von Integritätsbedingung von Attributen und Beziehungen benutzt werden.

Formale Notation
 * Relation: R ⊆ dom(a1) x dom(a2) x ... x dom(an)
 * Attribute set: Σ(R) = {a1, a2, ..., an} = RA , signature
 * Tuple: r ∈ R
 * Degree of R: number of attributes
 * Relation Schema: R(a1, a2, ..., an)
 * Database schema: set of relation schemas

Begriffsdefinition
 * Relation = table ( file) (relations are sets, tables may have duplicate entries)
 * Tuple = row, record
 * Attribute = field (component)

Def.: Functional Dependencies (FDs)
Let A = Σ(R)* = {a,b,c,...ai,..} be the attribute set of a relation Rand X, Y ⊆ A , r, r' ∈ R, r ≠ r'
Y is functionally dependent on X ( written: X → Y)
 :⇔ (∀ xi ∈ X ) r.xi = r’.xi ⇒ (∀ yi ∈ Y ) r.yi = r’.yi

A functional dependency Y → Z is called implied by a set
   F= {F1, ... , Fn} of functional dependencies, if Y → Z can be proven from F.
   
A functional dependency Y → Z can be inferred (¢ )by a set of inference rules R = {r1,...rm} from set F = {F1, ... , Fn} of functional dependencies
if Y → Z can be constructed by a finite number of syntactic transformations of F according to rules ri

Types of functional dependencies:
1. Key dependencies
2. Partial dependencies on one of the candidate keys
   expl.: {p#} -> {name}
       // R(p#,name,qualification, ...)
           since key is {p#,qualification}
3.  Dependencies among non-key attributes
    expl.: {responsible_Scientist} -> {institute}
4. Dependencies among attributes of different candidate keys


Normalformen
erste Normalform - 1NF
Eine Relation liegt in der 1NF vor, wenn jedes Attribut nur einen atomaren Wertebereich hat. Das heißt, dass zusammengesetzte (Name = Vorname + Nachname), mengenwertige (Telefonnummer={123,456,789} oder geschachtelte Attributwerte nicht erlaubt sind.

A relation is in 1NF :⇔ all attributes are single valued and atomic

zweite Normalform - 2NF
Eine Relation liegt in der 2NF vor, wenn es die Bedingungen der 1NF erfüllt und dazu weiter kein Attribut von einer Untermenge der Schlüsselkandidaten funktional abhängt. Hierdurch werden Teilabhängigkeiten vermieden.

R is in Second Normal Form (2NF), :⇔ ∀X ⊆Σ(R),∀a∈Σ(R): 
    a ∉ X ∧ a is not a prime attribute ∧ X -> a ⇒ X is a key or a superset of a key but not a proper subset of any key of R

dritte Normalform - 3NF
Eine Relation liegt in der 3NF vor, wenn es die 2NF erfüllt, sowie kein Nichtschlüsselattribut transitiv von einem Schlüsselkandidat abhängt. Das heißt, dass kein Attribut nur von Schlüsselattributen abhängen darf.

R is in third normal form (3NF) :⇔ R is in 3NF :⇔ no non-prime attribute depends transitively on a key.

Boyce-Codd-Normalform
Every non-trivial functional dependency in the table is a dependency on a  superkey

vierte Normalform - 4NF
Every non-trivial multivalued dependency in the table is a dependency on a superkey

algebraische Operationen
Projektion (Projection)

Selektion (Selection)

Vereinigung (Union)

Unterschied (Difference)

Kreuzprodukt (Cross product)