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.

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


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

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:
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
N:M-Beziehungen sollten niemals zusammengeführt werden!

Simple Query Langauge - SQL


Beschreibung ... Definition

Datentypen


SQL2

SQL99

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:
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:

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