So nun sind wir im 2. Teil unseres Tutorials angekommen.

In diesem Teil wollen wir uns ein bisschen mit Datenbanken beschäftigen, mit ihrem Aufbau und natürlich unserem Datenmodell.

Am Anfang ein bisschen was zu Datenbanken.

Auch hier versuche ich mich mal auf das wesentlichste zu beschränken. d.h. einige Begriffe sind wenn man es genau betrachtet nicht wirklich korrekt genutzt.
Das Tutorial ist im Prinzip auf jede Datenbank anwendbar. Auf Besonderheiten der einzelnen Datenbanken möchte ich hier nicht genauer eingehen.

Eine Datenbank als gebräuchliches Wort ist eigentlich ein Datenbanksystem (DBS).
Es beinhaltet grob eingeteilt 3 Teile.

Die Datenbank (DB) selbst (also die Menge der Daten) und ein Datenbankmanagementsystem (DBMS). Das DBMS strukturiert die Daten anhand des Datenbankmodells. Ebenso stellt sie eine externe Schnittstelle für den Zugriff auf Daten bereit.

In der DB selbst sind einerseits die Daten als auch ihre Beschreibung (Meta) beinhaltet.

Was uns eigentlich nur interessiert wenn wir mit DBS umgehen ist die externe Schnittstelle.

Sie sollte uns 3 Sprachkonstrukte zur Verfügung stellen.

• DML: Data Manipulation Language


• DDL: Data Definition Language


• DCL: Data Control Language

Also Sprachkonstrukte zum Manipulieren, zum Strukturieren und zum Kontrollieren. Wir wollen in unserem Tutorial die Datenbanksprache SQL verwenden. Sie vereinigt alle 3 Konstrukte in einer Sprachsyntax.
Als Beispiel:

• DML: select id,name from gb where id = 1 // delete from gb where id = 2


• DDL: create table gb (id INT NOT NULL PRIMARY KEY, name char(15) NOT NULL)


• DCL: grant select, delete on table gb to user

Nun gut, DBS sind recht "doof" und Daten gehen ganz schnell verloren weil eine Datenbank ja nicht weiss was für uns logisch ist... also sollten wir ein paar Grundregeln bei der Anlage und Abfrage einer Datenbank beachten...

1. Daten sollten nicht redundant sein. Nehmen wir mal an wir speichern in einer Tabelle unseren User ab und in einer anderen die Gästebucheinträge. Wenn wir jetzt in den GBeinträgen den UserNamen reinschreiben, haben wir die Daten schon mehrfach. Ändert sich der Username jetzt, müssten wir dran denken schon in 2 Tabellen den Usernamen zu ändern (Updateanomalie). Vergessen wir aber und schon haben wir eine inkonsistente Datenbank.
2. Datensätze sollten eindeutig identifizierbar sein. Haben wir 5 Datensätze mit dem exakt gleichen Inhalt, haben wir schon ein massives Problem. Wir wissen nicht mehr welcher Datensatz wohin gehört. Also brauchen wir eindeutige Bezeichner, so genannte Primärschlüssel. (z.B. eine auto increment id)
3. Daten sollten schnell auffindbar sein. Das können wir mit Indizes erreichen. Damit wird zwar DBS intern mehr Speicher verbraucht aber gleichzeitig die Suchleistung erhöht.
4. Nur wichtige und findbare Daten sollten indiziert werden
5. Datenstrukturen sollten immer die kleinstmögliche Datenspeichermöglichkeit verwenden. (DBgrösse) Als Beispiel wenn wir wahr oder falsch in der Datenbank ablegen können wir den Datentyp int verwenden (klar wir können 0 oder 1 speichern. Jedoch benötigen wir jetzt für jedes Datenfeld einen Speicher von 32 Bit). Sinnvollerweise verwenden wir gleich Boolean mit genau 1 Bit (Die Speicherlängen variieren je nach DBS aber die grundsätzliche Logik sollte klar sein)
6. Selbiges gilt für üble Speicher- und Performancefresser wie z.B. blob oder TEXT. Hier sollte ein Verweis (z.B. Pfad) auf eine Datei erfolgen, anstatt die Datei oder einen ganzen Text in der Datenbank einzulagern, aber auch das kommt auf das Anwendungsgebiet an.
7. Datenbankanfragen sollten minimiert bzw. optimiert werden. Fulljoins machen nicht immer Sinn. Übelste Anfrage über zig Tabellen hinweg evtl mit virtuellen tables und Unteranfragen (beispielsweise in PostgreeSQL, jedoch nicht in MySQL4) sollten besser zu frequenzarmen Zeiten erfolgen.
8. Eine Datenbankverbindung sollte nur so kurz wie möglich, aber so lange wie nötig offen gehalten werden.
9. Unnötige Datenbankanfragen sollten vermieden werden. (Warum 10 gejointe Anfragen auf einer Seite wenn ich einen Datensatz sowieso schon habe...)

• Wikipedia (zuviel für einzelne Links hier)


• Relationale Algebra


• Datentypen usw siehe jeweiliges DBS z.B. mysql

Den Aufbau von SQL will ich an dieser Stelle nicht vertiefen.

Jetzt wollen wir uns erstmal überlegen was wir für Daten benötigen für unser Gästebuchsystem.

Dazu sollten wir uns wieder unser kleines Schema hervorholen:



Fangen wir mit den Akteuren an.

Das hat jetzt auf den ersten Blick noch nichts mit der Datenstruktur im DBS zu tun sondern soll uns generell mal etwas über den User klar machen, wir brauchen die gleiche Tabelle später nochmal.

Kursiv geschriebenes kam anscheinend drüber schon mal dran...

Benutzer
IP
Datum wann gekommen
Browser

Admin
Name
Passwort
Datum wann gekommen
Browser

einträge lesen
Eintrag Überschrift
Eintrag Text
Eintrag Datum
Eintrag freigegeben
von wem geschrieben

einträge schreiben
Eintrag Überschrift
Eintrag Text
Eintrag Datum
Eintrag freigegeben
von wem geschrieben

einträge verwalten
Eintrag Überschrift
Eintrag Text
Eintrag Datum
Eintrag freigegeben
von wem geschrieben

login
Name
Passwort
Datum wann gekommen
Browser

Na gut, jetzt haben wir recht viel Aufwand betrieben und sind zu dem Schluss gekommen, dass sich unsere Anforderungen auf ein Substrakt unseres UML-Diagramms beschränken oder in Relationenalgebra ausgedrückt:

RDBS = RGes - Rkursiv

Jetzt wollen wir uns noch Gedanken machen wie wir das ganze absolut identifizierbar machen.

Also fügen wir IDs mit ein.

Jetzt müssen wir uns noch überlegen wie wer zusammenhängt und wir müssen uns überlegen wie wir das machen wollen, da wir ja unbekannte User haben (nur eine IP und bekannte User, also admins) und da wir ja das Ganze voll skalierbar machen wollen, fügen wir jetzt einen Dummyuser ein, z.B. Gast. Damit wäre der User also gleichberechtigt dem Admin und so müssen wir die 2 unterscheidbar machen.
Also braucht der User noch ein Merkmal.

Achtung: UML ist eigentlich nicht dazu gedacht Datenstrukturen eines DBS zu modellieren. Seht es also nicht als UML-Diagramm sondern als vereinfachtes ER-Schema.

Achtung 2: Fehlerteufel :-), User ist doppelt

Zum Schluss überlegen wir uns dann noch wie die 2 Datenstrukturen zusammenspielen. In diesem Fall recht einfach. 1 User kann 0 - * Einträge haben, Ein Eintrag muss 1 User haben (restriktiv).



Jetzt kommen nur noch die richtigen Datentypen und wir müssen noch diese Verbindung modellieren und schon haben wir unsere fertige Datenstruktur.



Hier sehen wir dann auch schon wie suboptimal UML für Datenstrukturen in einem DBS ist.
Wir können einfach nicht die richtigen Datentypen angeben (gut, wir könnten sie selbst deklarieren...)

Das machen wir jetzt aber von Hand.

Eintrag
id:int primary key, auto increment
ueberschrift: varchar (256)
text: text..... *seufz* text nehmen
datum:int
Browser:varchar(150)
ip:int (Achtung mit v6 brauchts Laenge 22)
freigabe:boolean
fkeyUser:int (immer selbe laenge wie primary key Benutzer!!!!!)

Benutzer
id:int
name:varchar(256)
passwort:varchar(256)
Datum:int
isadmin:boolean

Ein kleines Addon zu Mysql und TEXT type. Der Texttype wird in der neuesten Version als longvarchar geführt.
An sich ganz nett, hat aber Einschränkung in der Durchsuchbarkeit, Performance (eigenes Object im Speicherbaum) und Einschränkung in der Sortierbarkeit.


Schon haben wir unseren nächsten Teil unseres Tutorials geschafft.
Im nächsten Teil machen wir ein bisschen Prototyping und versuchen mal die benötigten Klassen zu finden.
Ich hoffe es hat euch Spaß gemacht, ein kleines Feedback was nicht so toll ist oder was ganz toll war wäre natürlich nett.

Ansonsten viel Spaß beim basteln,
Debua

>> Allgemeine Fragen oder Probleme mit dem Tutorial? Hier gehts zum Forum!