Basics-Relationale Datenbanken

Unter einer relationalen Datenbank ist eine Datenbank zu verstehen, die der Benutzer als eine Sammlung von Beziehungen (Relations) oder zwei-dimensionalen Tabellen wahrnimmt. Die Structured Query Language (SQL) wird für die Daten-Manipulation in relationalen Datenbanken verwendet.

Wichtig: Datenintegrität! (Genauigkeit und Konsistenz der Daten) – darüber wacht das DBMS!
Entity-Integrität: Kein Teil des Primärschlüssels kann NULL sein.
Referentielle Integrität: Ein Fremdschlüssel muß dem Wert eines bestehenden Primärschlüssels entsprechen (oder NULL sein).
Spalten-Integrität: Eine Spalte darf nur Werte enthalten, die mit dem definierten Datenformat der Spalte konsistent ist.
Benutzerdefinierte Integrität: Die in einer Datenbank gespeicherten Daten müssen mit den Unternehmensregeln übereinstimmen.

Eine ausführliche Kriterienliste für relationale Datenbanken ist hier zu finden. Beispiele und Unterlagen für die Einführung des Themas im Unterricht sind hier zu finden.

Vom ER-Modell zur DB

ER ist gut und schön. Aber nicht für den Alltag zu gebrauchen. Da benötigt mensch die DB. Es gilt aus dem Entity-Relation Modell ein logisches Datenbank Design zu transformieren. Dafür ist ER eine gute Basis. Eine Übertragung zur DB ist kein 1:1 Prozess.
Aber es gibt grundlegende Entsprechungen (ER->DB):

ANALYSE -> DESIGN

Entity -> Tabelle
Beziehung -> Fremdschlüssel
Attribut-> Spalte
Eindeutiger Bezeichner (UID)->Primärschlüssel/Eindeutiger Schlüssel

Beispiel: ER siehe Posting zuvor

Tabelle: Projekt mit Spalten: projektnummer(UID), projekttitel, schultyp

Die einzelnen Instances werden dann in der Ausgabe aus den entsprechenden Werten aus den Tabellen dargestellt. Daher können die Attribute von Entities bei Bedarf auch auf mehrere Tabellen verteilt sein.

ER-Modell

Hierbei handelt es sich nicht um eine Genderfrage. Ein ER Modell ist nicht männlich, sondern drückt die Beziehungen (Relationship) zwischen Objekten (Entities) aus.

Entities müssen in Bezug auf die Abbildung in der Datenbank RELEVANZ haben und es müssen dazu INFORMATIONEN (Daten) vorliegen. Die Informationen zu einer Entity werden über Attribute genauer beschrieben.

Eine Entity beinhaltet in der Regel mehrere Instances (vergleichbar mit Datensätzen).

Als zweiter Schritt ist es nötig, die Beziehungen zwischen den Entities zu bestimmen. Jede Entity muss in irgendeiner Beziehung zu mind. einer anderen stehen.

Beziehungskomponenten sind:

• Name (definiert inhaltlich die Beziehung)
• Modalität (möglich/kann oder unbedingt/muss)
• Grad (einzig oder mehrfach) – 1:1, 1:n, n:m

Eindeutigkeit ist sehr wesentlich. Damit einzlene Instances unterwscheidbar werden gibt es „Eindeutige Bezeichner “ (UID-Unique Identifier). Diese können durch einzelne oder mehrere Attribute oder auch durch eine Kombination von Attributen und Beziehungen erstellt werden.
Beispiel: Ich benötige für meine Arbeit eine Projektdatenbank, damit ich den Überblick behalte, welche LehrerInnen an welcher Schule bereits Projekte abgelaufen sind, ob diese mit BetreuerInnen aus meiner Institution durchgeführt wurden bzw. welche Projekte gerade am Laufen sind oder geplant werden. Zusätzlich gibt es auch interne Projekte, die ebenfalls erfasst werden sollen und nicht unmittelbar Schulen zugeordnet werden können.

Entities (Attribute): Projekt (Titel, Projektnummer,…)- Person (Name, Kontaktadresse, Telnr, Funktion …) – Schule (Schulnummer, Typ, Anschrift, Telefon, …).

Instances zu LehrerInnen sind dann z.B. die konkreten Personen (Franz Maier…).

Grafisch könnte das dann so aussehen (ist nur als Anschauung gedacht – kein Anspruch auf Vollständigkeit):

Wichtig ist es anschließend das Modell zu validieren.

Von Daten und Models

Der Datenbank- Entwicklungsprozess umfasst drei Stufen:

• Konzeptionelle Datenmodellierung (Erfassen der Objekte und Beziehungen, ER-Modell)
• Logisches Datenbank – Design ( Erstellen der konkreten Datenbank)
• Physikalisches Datenbank – Design ( Implementieren bestehender Daten in eine konkrete Datenbank)

Ich werde mich in den nächsten Schritten mit den Grundlagen der Erstellung eines ER-Modells und die Implementierung in eine relationale Datenbank beschäftigen. Hinter den KM Systemen stehen oftmals Datenbanken. Die Erstellung und das Design der Datenbank erfolgt dabei oftmals automatisiert innerhalb der Applikationen . Bei CMS werden die verwendeten Datenbanken einmal im Zuge der Installation angelegt und die weitere Strukturierung erfolgt für UserInnen nicht sichtbar automatisiert . Die Qualität eines CMS hängt jedoch wesentlich vom Design des dahinterliegenden Datenbanksystems ab. Auch mögliche Schnittstellen für die standardisierte Ein- und Ausgabe von Daten werden nur möglich, wenn die Datenbank entsprechende Datenstruktur aufweist und den Standards entsprechende Abfragen zulässt.

Von Daten und deren Banken

Banken gibt es viele und ebenso Bedeutungen. Dermal gehts um jene Banken, die unsere Daten beheimaten. Ohne diese Datenbanken würde vieles an IT nicht funktionieren und passt die Datenbank nicht, dann funktioniert vieles eben nicht. Auch diese Zeilen hier werden in einer Datenbank abgelegt und das darf mir beim Verfassen der Zeilen ziemlich egal sein. Es muss nur funktionieren. Normalerweise ist zwischen der Datenbank (DB)und dem Benutzer ja auch noch ein Anwendungsprogramm und jedenfalls ein mit der DB verbundenes Datenbankverwaltungsprogramm (DBMS). Im Open Source Bereich ist MySQL das verbreitetste RDBMS.

Damits funktioniert ist nötig, dem Datenbankverwaltungsprogramm zu erklären, was es mit den Daten machen soll. Aber das Programm kann nur gut werden, wenn klar ist, wofür die Datenbank dienen soll. Daher: Analyse des Einsatzbereiches und Strukturdefinition und dann Datenmodellierung und Datenbankdesign. Der Datenbank – Entwicklungsprozess ist also eng mit dem Anwendungsentwicklungsprozess gekoppelt. Es gilt sowohl bei der Datenmodellierung als auch beim Datenbankdesign ein Funktionsmodell und ein Datenmodell zu erstellen und die beiden in Einklang zu bringen (Funktionstestung). Die Datenmodellierung erfolgt unabhängig von der danach beim Datenbankdesign zu nutzenden Software.
Ziel ist, wie Eingangs erwähnt, ein operationales System zu schaffen, das sowohl eine operationale Datenbank als auch ein operationales Anwendungssystem umfasst.