Sehr geehrte Leserinnen und Leser,
damit wäre das schon mal erledigt. Puh, ich hasse diese Stelle in jedem Text den ich verfasse…
Das Schlimmste was es für mich gibt! :D
Da du deinen Weg hierher gefunden hast, bist du vermutlich an das Thema SQL oder auch Datenbanken allgemein interessiert. Nun, hierbei handelt es sich um ein ausführliches Tutorial welches sich mit folgenden Themen beschäftigt:
Im Großen und Ganzen beschäftige ich mich hier hauptsächlich mit SQL Datenbanken, jedoch versuche ich möglichst viele Hintergrundinformationen mitzuliefern, um dir ein gutes Allgemeinbild über Datenbanken und SQL zu hinterlassen.
Für dieses Tutorial sind keine Vorkenntnisse notwendig. Es wurde so geschrieben, dass auch ein Anfänger in die Thematik herein findet und möglichst viel versteht.
Das Tutorial gliedert sich allgemein in sieben großen Abschnitten. Die sieben einzelnen Abschnitte bauen aufeinander auf und sollen entsprechend die oberen Fragen beantworten und in die Thematik einführen. An einigen Stellen gibt es auch praktische Teile wo du kleinere Übungen durchführen kannst, um das erlernte Wissen direkt einmal anzuwenden.
Falls du schon bereits Vorkenntnisse hast, steht es dir natürlich frei die entsprechenden Teile zu überspringen.
In diesem Abschnitt klären wir erst einmal was eine Datenbank überhaupt ist. Dabei zeige ich dir einige konkrete Beispiele wie eine Datenbank aussehen kann und wie man sie verwendet. Es gibt unterschiedliche Datenbankformen und jede Datenbank kann unterschiedlich aussehen. Hauptsächlich sollst du einen Eindruck davon bekommen wie du Datenbanken in der Programmierung einbinden kannst und welche Möglichkeiten es da für dich gibt.
In diesem Teil klären wir, was ein Datenbankmanagement System ist und wie es zusammen mit einer Datenbank interagiert. Zudem schreiben wir unser eigenes kleines Datenbankmanagement System um dessen Funktionsweise besser zu verstehen. In Kombination mit den Datenbanken kann ein Datenbankmanagement System für unterschiedliche Zwecke designt und eingesetzt werden.
Nachdem wir geklärt haben was eine Datenbank überhaupt ist, gehen wir näher darauf ein was es mit einer SQL Datenbank auf sich hat. Dabei sehen wir uns einmal genauer an, wie solch eine SQL Datenbank strukturiert ist und was eigentlich dahinter steckt.
Nachdem wir geklärt haben was eine SQL Datenbank ist, beschäftigen wir uns damit wie wir auf diese zugreifen. Da eine SQL Datenbank aus einer Kombination von einem Datenbankmanagement System und einer Datenbank ist, lernst du die Sprache welche die bekannten Datenbankmanagement System Software verstehen.
In diesem Teil lernst du, wie du eine SQL Datenbank entsprechend planst. Je nach Anwendungsfall kann eine SQL Datenbank unterschiedlich aussehen und verfolgt verschiedene Konzepte und Anforderungen. Hier lernst du die allgemeine Vorgehensweise um eine SQL Datenbank entsprechend für die unterschiedlichen Anforderungen aufzubauen.
Nachdem dann der ganze Theorie Krempel durch ist, wird es Zeit auf die SQL Datenbank mit AutoIt zuzugreifen. Dabei lernst du die unterschiedlichen UDFs kennen, welche von energischen AutoIt Benutzern entwickelt wurde. Ich stelle dir die wichtigsten vor und erläutere dir wie die einzelne UDF im einzelnen funktioniert.
Dieser Teil beinhaltet ein konkretes Beispiel, wie eine umfassende Applikation mit einer SQL Datenbank aufgebaut und geplant werden kann. Dies soll dir als ersten Einblick dienen, wie man das gelernte Wissen nun praktisch umsetzt.
… noch ein paar Worte. Ich versuche dir in diesem Tutorial einen guten Einblick in die Thematik zu verschaffen und dir damit einen Startpunkt zu geben. Für weitere Informationen ist dann entsprechend Tante Gockel (Google) zu fragen. Natürlich kannst du auch deine Fragen in dem Forum stellen, wo du dieses Tutorial gefunden hast. Ich wünsche dir viel Spaß!
Die deutsche Duden Definition einer Datenbank sieht folgendermaßen aus:
www.duden.de | Datenbank
elektronisches System, in dem große Bestände an Daten (2, 3) zentral gespeichert sind
Prinzipiell kommt da erst einmal alles Mögliche in Frage. Sicherlich hast du schon mal Daten auf die Festplatte gespeichert. Sei es manuell oder in einen AutoIt Skript. Jede Form der Datenablage auf der Festplatte, die der Datensicherung für Weiterverarbeitung dient, kann als Datenbank angesehen werden. Je nach Software und Anforderungen können solche Daten unterschiedlich in den Datenbanken strukturiert sein. Einige Datenbankformate strukturieren ihre Daten so, dass sie von Menschen in einem Editor gut ausgelesen und manipuliert werden können. Andere wiederum versuchen die Daten möglichst zu komprimieren, um auf der Festplatte wenig Speicher einzunehmen. Diese Datenbanken werden dann eher maschinell verarbeitet. Andere lagern ihre Daten vielleicht in viele unterschiedliche Dateien ab um den Zugriff zu beschleunigen. Egal um welches Datenbankformat es sich dabei handelt, jedes versucht unterschiedliche Anforderungen abzudecken.
Glücklicherweise brauchen wir uns in den meisten Fällen nicht damit herumschlagen, da es schon viele bekannte Datenbankformate gibt die wir nutzen können. Manche wurden vielleicht nicht als Datenbankformat entwickelt, werden jedoch gerne schon mal dafür verwendet weil die Verarbeitung in der Programmierung schlichtweg bequem ist. Sehen wir uns doch einmal an, welche Datenbankformate es doch so gibt.
INI Dateien werden üblicherweise als Konfigurationsdateien von Microsoft Windows Anwendungen genutzt. Sie dient also an erster Stelle dazu, bestimmte Einstellungen für eine Software zu speichern. Jedoch wird dieses Dateiformat gerade in AutoIt gerne als Datenbankformat genutzt, da es einfach zu verwendende Built-In Funktionen gibt wodurch die Verarbeitung der Daten ziemlich einfach ist.
Eine INI Datei besteht im Groben aus benannten Sektionen. Jede Sektion beinhaltet dabei Datenpaaren welche sich aus einen Schlüssel und einen Wert zusammensetzen. Durch die Kombination durch die Sektion und dem Schlüssel, können die Daten adressiert werden.
; Kommentar
[Sektion]
Schlüssel=Wert
Viel mehr gibt es dazu nicht zu wissen. Durch die Einfachheit dieses Dateiformates können unterschiedliche Daten entsprechend gespeichert werden. Ein Beispiel könnte dabei ein Stundenplan sein, welcher seine Daten in solch einer INI Datei abbildet.
; Die leeren Datenpaare könnten auch weggelassen werden...
[Montag]
Block1=MAT
Block2=MAA
Block3=MAA
Block4=
[Dienstag]
Block1=
Block2=ENG
Block3=DAB
Block4=
[Mittwoch]
Block1=BEN
Block2=MAT
Block3=KOM
Block4=DAB
[Donnerstag]
Block1=
Block2=ENG
Block3=RZZ
Block4=DAB
[Freitag]
Block1=KOM
Block2=BEN
Block3=
Block4=
#include <Array.au3>
#include <File.au3>
; Beinhaltet die obere Datei als String
Local $bin = "0x3B20446965206C656572656E20446174656E7061617265206BF66E6E74656E20617563682077656767656C617373656E2077657264656E2E2E2E0D0A0D0A5B4D6F6E7461675D0D0A426C6F636B313D4D41540D0A426C6F636B323D4D41410D0A426C6F636B333D4D41410D0A426C6F636B343D0D0A0D0A5B4469656E737461675D0D0A426C6F636B313D0D0A426C6F636B323D454E470D0A426C6F636B333D4441420D0A426C6F636B343D0D0A0D0A5B4D697474776F63685D0D0A426C6F636B313D42454E0D0A426C6F636B323D4D41540D0A426C6F636B333D4B4F4D0D0A426C6F636B343D4441420D0A0D0A5B446F6E6E6572737461675D0D0A426C6F636B313D0D0A426C6F636B323D454E470D0A426C6F636B333D525A5A0D0A426C6F636B343D4441420D0A0D0A5B467265697461675D0D0A426C6F636B313D4B4F4D0D0A426C6F636B323D42454E0D0A426C6F636B333D0D0A426C6F636B343D"
Local $tmp = _TempFile(Default, Default, ".ini")
FileWrite($tmp, BinaryToString($bin))
ConsoleWrite(BinaryToString($bin) & @CRLF)
; Einlesen der INI Datei
Local $nms = IniReadSectionNames($tmp)
_ArrayDisplay($nms)
Local $sec
For $i = 1 To $nms[0]
$sec = IniReadSection($tmp, $nms[$i])
_ArrayDisplay($sec)
Next
MsgBox(0, "", IniRead($tmp, "Mittwoch", "Block3", ""))
FileDelete($tmp)
Wenn du mehr über das INI Dateiformat wissen möchtest, kannst du dir die genaue Beschreibung dazu auf MSDN ansehen.
Eine CSV Datei ist wohl eines der einfachsten Datenbankformate die mir spontan einfallen. Dieses Datenbankformat wird üblicherweise immer dann gewählt, wenn Daten in einer tabellarischen Struktur vorliegen. Dabei ist das Format so einfach gehalten, dass es keine einheitliche Standardisierung dazu gibt. Dadurch kann es immer dann zu Problemen kommen, wenn eine CSV Datei von unterschiedlicher Software aus bearbeitet werden soll. Allerdings hat man 2005 versucht allgemeine Informationen zu der normalerweise üblichen Struktur einer CSV Datei zu verfassen. Diese Informationen sind in der RFC 4180 niedergeschrieben wurden und dienen als allgemeine Richtlinien für dieses Dateiformat.
Die Grundstruktur einer CSV Datei ist eigentlich schnell zusammengefasst. Da eine CSV allgemein Tabellen abbilden soll, sind die Daten in der Datei relativ einfach getrennt. Jede Spalte wird mit einen Komma und jede Zeile mit einen Zeilenumbruch markiert. Dazu ein einfaches Beispiel:
| Spalte A | Spalte B | Spalte C | |
|---|---|---|---|
| Zeile 1 | A1 | B1 | C1 |
| Zeile 2 | A2 | B2 | C2 |
| Zeile 3 | A3 | B3 | C3 |
Diese Tabelle würde in eine CSV Datei folgendermaßen aussehen:
,Spalte A,Spalte B,Spalte C
Zeile 1,A1,B1,C1
Zeile 2,A2,B2,C2
Zeile 3,A3,B3,C3
Das ist auch eigentlich schon das Geheimnis hinter einer CSV Datei. Die RFC 4180 beschreibt ansonsten noch ein paar extra Regelungen für übliche Konflikte mit diesem Dateiformat. Was ist, wenn einer unserer Daten ein Komma beinhaltet? Wenn wir das Komma einfach so abspeichern würden, würde unsere ganze Struktur zusammenbrechen. Das Gleiche gilt für einen Zeilenumbruch. Wer sich für die Lösung über diesen Konflikt interessiert kann sich die RFC 4180 ja mal genauer ansehen, allerdings reichen uns die derzeitigen Informationen für eine Darstellung dieses Formates aus.
Eine Verarbeitung dieses Formates ist aufgrund der Einfachheit in jeder Programmiersprache, ohne großen Aufwand, möglich. Ein einfaches Beispiel soll dies einmal verdeutlichen:
#include <Array.au3>
#include <File.au3>
; Beinhaltet die obere Datei als String
Local $bin = "0x2C5370616C746520412C5370616C746520422C5370616C746520430D0A5A65696C6520312C41312C42312C43310D0A5A65696C6520322C41322C42322C43320D0A5A65696C6520332C41332C42332C4333"
Local $tmp = _TempFile(Default, Default, ".csv")
FileWrite($tmp, BinaryToString($bin))
ConsoleWrite(BinaryToString($bin))
; Einlesen der CSV Datei und die Ausgabe
Local $csv
_FileReadToArray($tmp, $csv, $FRTA_NOCOUNT, ",")
_ArrayDisplay($csv)
FileDelete($tmp)
Nach den beiden einfachen Datenbankformaten kommen wir zu einem Format, welches etwas komplexer ist. XML ist eine erweiterbare Auszeichnungssprache welche dafür entworfen wurde um einen Datenaustausch zu gewährleisten. Dieses Format bringt eine Vielzahl an Richtlinien mit, um nach Möglichkeit viele unterschiedliche Daten in unterschiedlichen Strukturen darzustellen und entsprechend abzuspeichern. Über XML lässt sich ein eigenes Tutorial verfassen, jedoch sehen wir uns die Grundzüge einmal an.
Vereinfacht gesagt, besteht ein XML Dokument aus einer Hierarchie, Elementen, Attributen und der Daten selber. Im wesentlichen beschränken wir uns in diesem Tutorial auf die Hierarchie und den Elementen, die Attribute lassen wir einmal außen vor da diese für einen kurzen Einblick nicht relevant genug sind.
Alle Daten in einem XML Dokument werden in ein übergeordnetes Element gepackt, welches als Wurzelelement dient. Ein Element selber wird in dabei in folgenden Format dargestellt: <Bezeichner>
Alle untergeordneten Elemente oder die eigentlichen Daten werden in diese Elemente verschachtelt:
<Wurzel>
<Element>Daten</Element>
</Wurzel>
Diese Basisregeln reichen schon aus, um ein gültiges XML Dokument zu beschreiben. Es gibt eine Vielzahl an Regeln welche alle auf W3C exakt beschrieben sind.
Da XML uns sonst keine weiteren Vorgaben zu der Struktur macht, können die Daten auf unterschiedlichste Weise ausgelesen und dargestellt werden. Je nach Struktur, die wir uns frei durch eine entsprechende Hierarchie aussuchen können, haben wir unterschiedliche Möglichkeiten in der Verwendung eines XML Dokumentes. Ein etwas komplexeres Beispiel soll dies einmal verdeutlichen:
Gehen wir einmal von einer Applikation aus, welches wichtige Firmendaten verwaltet und übersichtlich darstellt. Diese Daten werden in einem XML Dokument gespeichert welches als Datenbank fungiert. Die Daten, welche die Firma speichern und verwalten möchte sind unter anderem die Mitarbeiter (Vorname, Nachname, Geburtstag, Adresse, Kontonummer, Gehalt, …) wie auch die Abteilungen (Geschäftsführung, Personalabteilung, Rechnungswesen, Finanzen, Rechtsabteilung, …) welches die Firma selber hat. Zudem soll die Datenbank auch beinhalten, welche Produkte hergestellt werden und für welchen Preis sie diese verkaufen und wie viel bisher verkauft wurde.
Dies dürfte als einfaches Beispiel genügen. Natürlich hat eine Firma viel mehr an Daten welche verwaltet und gespeichert werden wollen. Die Zwecke sind dabei komplett unterschiedlich. Letztendlich läuft es aber darauf hinaus, dass durch diese Datenspeicherung genau kalkuliert und geplant werden kann, wo an Herstellungskosten gespart werden kann. Dabei fängt es bei dem Einkauf der Rohstoffe an bis hin zu ineffiziente Abteilungen und dessen Mitarbeitern. Eine Übersicht über eine Firma zu haben und entsprechend zu planen ist nicht einfach.
Um auf unser Beispiel zurück zu kommen: Im Folgenden stellen wir die Abteilungen mit ihren Mitarbeitern in einem XML Dokument dar. Mit einer Applikation wollen wir dann später, anhand der Datenbank, herausfinden wie viele Mitarbeiter in welcher Abteilung arbeiten und wer ihr Vorgesetzter ist. Zudem berechnen wir auch deren Gehälter im gesamten Betrieb, wie auch pro Abteilung.
Zuerst einmal überlegen wir uns, welche Informationen wir für einen Mitarbeiter abspeichern wollen. Für unser Vorhaben reich uns erst einmal der Vor- wie auch Zuname, Gehalt und die Information in welcher Abteilung dieser arbeitet. Eine Struktur mit diesen Informationen könnte in XML folgendermaßen aussehen:
<Mitarbeiter>
<Vorname> </Vorname>
<Nachname> </Nachname>
<Abteilung> </Abteilung>
<Gehalt> </Gehalt>
</Mitarbeiter>
Nun haben wir noch die einzelnen Abteilungen. Diese Abteilungen beinhalten (der Einfachheitshalber) lediglich den Namen der Abteilung, wer der Abteilungsleiter ist und welche Mitarbeiter diese beschäftigt. Eine Struktur wie diese könnte z.B. so aussehen:
<Abteilung>
<Bezeichnung> </Bezeichnung>
<Leiter> </Leiter>
<Mitarbeiter> </Mitarbeiter>
</Abteilung>
Nun müssen diese beide Strukturen nur noch sinnvoll zusammen geführt werden. Wir könnten sämtliche Mitarbeiter einer Bestimmten Abteilung beispielsweise in Abteilung -> Mitarbeiter hinein schachteln. In dem Fall würde dann das Element Mitarbeiter -> Abteilung entsprechend wegfallen, da wir durch unsere Struktur bereits schon bestimmt haben, in welcher Abteilung dieser Mitarbeiter arbeitet. Das könnte folgendermaßen aussehen:
<Abteilung>
<Bezeichnung> </Bezeichnung>
<!-- Der Leiter ist auch ein Mitarbeiter...
Bezeichnen wir der Einfachheitshalber jedoch als "Leiter" -->
<Leiter>
<Vorname> </Vorname>
<Nachname> </Nachname>
<Gehalt> </Gehalt>
</Leiter>
<Mitarbeiterliste>
<Mitarbeiter>
<Vorname> </Vorname>
<Nachname> </Nachname>
<Gehalt> </Gehalt>
</Mitarbeiter>
<Mitarbeiter>
<Vorname> </Vorname>
<Nachname> </Nachname>
<Gehalt> </Gehalt>
</Mitarbeiter>
<Mitarbeiter>
<Vorname> </Vorname>
<Nachname> </Nachname>
<Gehalt> </Gehalt>
</Mitarbeiterliste>
<!-- usw... -->
</Mitarbeiter>
</Abteilung>
Wir könnten allerdings auch die Mitarbeiter und Abteilung getrennt voneinander führen. Dazu geben wir der Abteilung und den Mitarbeitern eine ID um diese als Markierung für Assoziationen zu nutzen.
<Firma>
<Abteilungen>
<Abteilung>
<Id> </Id>
<Bezeichnung> </Bezeichnung>
<Leiter> </Leiter>
</Abteilung>
<Abteilung>
<Id> </Id>
<Bezeichnung> </Bezeichnung>
<Leiter> </Leiter>
</Abteilung>
</Abteilungen>
<Mitarbeiterliste>
<Mitarbeiter>
<Id> </Id>
<Vorname> </Vorname>
<Nachname> </Nachname>
<Abteilung> </Abteilung>
<Gehalt> </Gehalt>
</Mitarbeiter>
<Mitarbeiter>
<Id> </Id>
<Vorname> </Vorname>
<Nachname> </Nachname>
<Abteilung> </Abteilung>
<Gehalt> </Gehalt>
</Mitarbeiter>
</Mitarbeiterliste>
</Firma>
Beide Strukturen haben ihre Vor- und Nachteile was die Verarbeitung und benötigter Zeitaufwand darstellt. Je nach Anforderungen kann solch eine Struktur unterschiedlich dargestellt werden. Erinnern wir uns doch noch mal zurück, was wir eigentlich mit den Daten machen wollen:
Versuche doch einmal selber mit einigen Testeinträgen diese Informationen herauszulesen. Such dir einer der oberen Strukturen aus, füge einige Informationen ein und probier mal ob du alle 4 Anforderungen erfüllen kannst. Vielleicht fällt dir ja auch selber eine andere Struktur ein.
Dies dürfte als kleiner Einblick in das Thema Datenbanken genügen. Es gibt viele unterschiedliche Varianten Daten in eine einzelne Datei zu verpacken und diese zu verarbeiten. Jedes Format hat dabei ihre eigenen Vor- und Nachteile und sind für unterschiedliche Zwecke optimiert. Die einen Formate wollen einfach zu handhaben sein, die anderen wollen ein schnelles einlesen der Daten gewährleisten. Wichtig ist jedoch, dass du einmal verstanden hast, was Datenbanken sind und welche Bedeutung ihnen zugeschrieben wird.