SQL-Dump

Struktur & Daten sichern & transportieren

Ein 'Dump' ist die Standard-Methode, um Strukturen und Daten von Datenbanken ßerhalb des SQL-Servers zu verwenden. Dump-Filess sind reine Text-Dateien und werden zur Sicherung, sowie für Transport und Übersiedelung eingesetzt.
SQL Die Datenbank-'Sprache' (Standard Query Language)
Dump Erklärung und Beispiel
Text-Export Die Übersiedlung von Daten
Fixe Länge Export von Datensätzen fixer Länge
Variable Länge Export von Datensätzen variabler Länge

DUMP

SQL-Dump

Ein Dump ist die Standard-Methode für Transport, Sicherung und Übersiedlung von Strukturen und Daten im Umfeld von SQL-Servern.
Jeder Dump besteht aus beliebig vielen SQL-Anweisungen, die in Text-Dateien gesammelt sind.

Struktur & Daten

Es ist vorteilhaft, Struktur und Daten zu trennen:

Ein Struktur-Dump (Beispiel rechts oben) enthält alle Befehle zur Herstellung einer kompletten Datenbank-(DB)-Struktur ohne Daten. Struktur-Dumps sollten eine gesamte DB mit allen dazugehörenden Elementen (ungeteilt) abbilden.

Ein Daten-Dump (Beispiel rechts) enthält alle Befehle zum Einlesen von Daten in eine vorhandene DB-Struktur. Wenn viele Daten vorliegen, oder wenn es aus anderen Gründen sinnvoll ist, wird ein Daten-Dump in kleinere Portionen zerlegt.
Nur bei sehr kleinen Lösungen ist es sinnvoll, einen kompletten Dump von Struktur und Daten in einer einzigen (Text)-Datei zu speichern.
Die Bedienungs-Oberfläche der Datenbank (meistens Script-Programme für dynamische Webseiten) ist nicht Teil des Dumps und muss unabhängig gesichert werden. 		Dump-Datei personen_struktur.sql
-- Beispiel fuer einen Struktur-Dump
DROP TABLE IF EXISTS `personen`;
CREATE TABLE IF NOT EXISTS `personen` (
`p_pk` int(10) unsigned NOT NULL auto_increment,
`p_vorname` varchar(20) collate latin1_bin default NULL,
`p_zuname` varchar(30) collate latin1_bin default NULL,
PRIMARY KEY (`p_index`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_bin AUTO_INCREMENT=106 ;

Dump-Datei personen_daten.sql
-- Beispiel fuer einen Daten-Dump
INSERT INTO `personen` (`p_pk`, `p_vorname`, `p_zuname`) VALUES (101, 'Alfred', 'Ammer'),
(102, 'Berta', 'Bieder'),
(103, 'Christian', 'Chormeister'),
(104, 'Dora', 'Daun'),
(105, 'Emil', 'Erpel');

Sicherheit

Von jeder Datenbank sollte ein aktueller Struktur-Dump an einer sicheren Stelle gespeichert sein. Nach jeder Änderung der Struktur müssen diese Sicherungs-Dateien erneuert werden. Daher ist es sinnvoll, das Datum im Datei-Namen zu verankern. Der Platzbedarf ist minimal, die Wichtigkeit sehr hoch, daher ist es sinnvoll, mehrere Kopien an unterschiedlichen Stellen zu speichern.

Zeichencode

Die SQL-Anweisungen sollten ausschließlich → ASCII-Code enthalten. Sonderzeichen beliebiger Sprachen werden mit → UTF-8 codiert, allfällig vorhandene Binär-Daten (Blobs) werden ASCII-codiert (z.B. Binhex). Im Text sind Kommentare möglich, diese sollten jedoch ebenfalls nur ASCII-zeichen enthalten.

Werkzeug

Dumps werden normalerweise automatisch erstellt. Jeder SQL-Server und jedes Administrations-Werkzeug (z.B. → phpMyAdmin) bietet dazu Optionen. Das Einlesen gespeicherter Dump-Dateien erfolgt dagegen meist halbautomatisch unter besonderer Aufsicht.

Recover-Test

Ein Dump ist wertlos, wenn sich daraus nicht garantiert (!) die Strukturen und Daten wiedergewinnen lassen. Das muss daher regelmäßig ausprobiert werden - normalerweise nicht auf dem Original-Server sondern auf einem (virtuellen) Test-PC. Ein derartiger Test muss nach jedem wesentlichen Software-Update ausgeführt werden.

Aufwand

Daten-Dumps erfordern weit mehr Aufwand als Struktur-Dumps. Für große Daten-Mengen braucht man einige Zeit und viel Speicherplatz.
Es ist praktisch, die Größe der erzeugten SQL-Dateien zu begrenzen, z.B. auf 10 MB. Viele kleine Dump-Dateien lassen sich leichter verarbeiten als wenige große. Damit vermeidet man auch Probleme mit der maximalen Laufzeit der dafür meist eingesetzten Script-Programme (PHP, Perl, ..). Daten-Sicherungen sind für Spionage interessant und müssen daher entsprechend sicher aufbewahrt werden: Am besten auf CD/DVD in einem feuersicheren Tresor, am schlechtesten auf einer Festplatte im lokalen Netzwerk (LAN).

Zeitpunkt

Ein Dump sollte möglichst nur dann ausgeführt werden, wenn die Datenbank für normale AnwenderInnen stillgelegt ist. Die sicherste Methode dafür ist die Trennung des SQL-Servers vom Netzwerk, in kleinen Betrieben auch die Ausführung bei Nacht bzw. am Wochenende.
Nur sehr große Server müssen ständig in Betrieb bleiben, dort muss die Sicherung während des laufenden Betriebs erfolgen.
Dumps werden am besten vollautomatisch und regelmäßig ausgeführt, zusätzlich manuell bei einem entsprechenden Anlass.

Format

Die Speicherung erfolgt als Klartext (text/plain) in Form kompletter SQL-Anweisungen. Wenn Speicherplatz knapp ist, dann komprimiert man die Text-Dateien in Archive (z.B. *.zip).
Es wäre möglich, die Daten in anderen Text-Formaten zu speichern, z.B. mit Tabulator oder Beistrich (CSV) als Trennzeichen. Der Gewinn an Speicherplatz ist jedoch gering, die Einbuße an Brauchbarkeit erheblich.
In binärer Form (z.B. die Original-Datanbank-Dateien) ist keine Sicherung sinnvoll, da sich die Daten aus solchen Dateien - wenn überhaupt - nur mit sehr großem Aufwand wiedergewinnen lassen.

Text-Export
In kleinen Betrieben und auf privaten PC gibt es noch zahlreiche PC-Datenbanken älterer DB-Programme, wie z.B. dBase, MS-Access oder FileMaker.
Früher oder später erfolgt die Umstellung bzw. Übersiedlung der Daten auf einen Standard SQL-Server.
Kaum eines der älteren DB-Programme bietet eine Option zum Speichern von SQL-Dumps, ein Daten-Export ist allerdings immer möglich. 		Eine derartige Umstellung erfordert sehr sorgfältige Vorbereitung, typisch über einen Zeitraum von mehreren Wochen ... Monaten. Es gibt kein allgemeines Rezept für die beste Codierung der Daten zum Zwecke der Übersiedlung. Nachfolgend sind einige Indizien angeführt, nach denen sie eine spezielle Situation beurteilen können.

Datenbank-(DB)-Struktur

Keines der älteren DB-Programme bietet die Möglichkeit eines Struktur-Dumps. Aus diesem Mangel macht man am besten eine Tugend:

Länger gelaufene Lösungen sind ohnehin nur selten optimal organisiert. Deshalb ist es sinnvoll, nach der Übersiedlung gleich eine neue, verbesserte Struktur zu verwenden. 		Erstellen sie daher manuell eine komplett neue Struktur auf einem SQL-Server und testen sie die Lösung ausgiebig - Zuerst mit wenigen typischen Test-Daten, dann mit (evtl. auch unzulässigen) worst-case-Daten, zuletzt mit einer Kopie der echten Daten.

Machen sie bei Erstellung der Struktur keine Kompromisse, sondern versuchen sie eine saubere Lösung nach den Vorgaben der Datenbank-Theorie (Entity Relation Model). Diese Vorgangsweise kann vordergründig kompliziert erscheinen, macht sich jedoch langfristig immer bezahlt.

Daten

Da überholte Software meist keinen SQL-Daten-Dump anbietet, müssen alle Daten als reiner Text exportiert werden. Ein Export in binären Formaten (Access, dBase, Excel, Lotus, Paradox, ... ) kommt normalerweise nicht in Frage.
Der größte Teil üblicher Daten kann mit einfachen Mitteln ohne besondere Behandlung in eine SQL-Datenbank übersiedelt werden. Eine genau Analyse (siehe unten) sollte allerdings sicherstellen, dass keine Sonderfälle auftreten.
Manche Daten erfordern eine besondere Aufbereitung (Umwandlung):

Daten-Aufbereitung vor dem Export Aufbereitung vor dem Export
Die Aufbereitung erfolgt am besten noch in der 'alten' Datenbank mit deren Funktionen oder bei MS-Access mit → Basic (VBA).
Dazu kann man gut die Zeit bis zur Fertigstellung der SQL-Datenbank nutzen. - Zum Zeitpunkt der Daten-Übernahme ist dann die Aufbereitung auch der neuesten Daten bereits fertig.
Der Aufwand zur Verarbeitung oder Beseitigung von Sonderfällen vor dem Export ist bedeutend geringer als nachher.
Daten-Aufbereitung nach dem Export Aufbereitung nach dem Export
Alternativ muss die Aufbereitung der Daten nach ihrem Export erfolgen. Dazu kann man z.B. → Perl-Programme einsetzen, mit deren Hilfe die Verarbeitung von Text besonders einfach ist.
Dieser Fall tritt auch dann ein, wenn die 'alte' Lösung bereits beschädigt oder überhaupt nicht mehr arbeitsfähig ist.

Wenn die Daten vor dem Export nicht aufbereitet wurden, dann muss die Software eine große Anzahl komplizierter Sonderfälle berücksichtigen. Das macht Übernahme-Programme kompliziert, unüberschaubar und damit anfällig gegen Fehler.

Wenn bei der Analyse nicht alle Sonderfälle entdeckt wurden, dann werden manche Daten evtl. fehlerhaft in die SQL-DB übernommen. Solche Fälle sind besonders unangenehm, weil davon meist nur wenige Datensätze betroffen sind und die Fehler lange unentdeckt bleiben.
Aufbereitung, Validierung und Säuberung der Daten
Die Daten der 'alten' DB werden am besten vor der Migration von Karteileichen, Dubletten und sonstigem Daten-Mist gesäubert.
Am besten ist eine komplette Validierung, d.h. alle (!) Daten werden auf sinnvolle oder zulässige Werte überprüft. Das erfordert relativ viel Zeit, jedenfalls aber weniger als eine spätere Reparatur.
Die folgenden Beispiele sollen nur Anregungen liefern, die Angaben sind nicht immer sinnvoll anwendbar !
Spezielle Fälle bei der Daten-Aufbereitung

Leer
Eine SQL-Datenbank unterscheidet zwischen dem Wert NULL (unbestimmt) und einem leeren Text - beide Werte sind zulässig. Sie sollten vor dem Export sicherstellen, dass solche Werte nicht irrtümlich auftreten. Meistens ist es besser, solche Werte durch genauere Angaben (z.B. 'Unbekannt', 'Fehler', ..) zu ersetzen.

Unbekannt
In der Praxis kommt es relativ oft vor, dass Daten zumindest über eine begrenzte Zeit unbekannt sind. Das trifft für alle Felder zu, die von Menschen eingegeben oder geändert werden können. Stellen sie fest, wie der Wert 'Unbekannt' in jedem dieser Felder codiert sein sollte, und kontrollieren sie die realen Daten. Vor dem Export sollte jedes der betroffenen Felder eine eindeutige Aussage enthalten (auch 'Unbekannt' ist eine Aussage).

Fehler
In manchen Fällen ist es notwendig, den Wert 'Fehler' in einem Feld oder einem Datensatz einzutragen. Stellen sie fest, ob und wie das codiert sein sollte, und kontrollieren sie die realen Daten. Es ist in jedem Fall besser, Fehler-Werte zu kennzeichnen, als die Daten zu löschen. Vor dem Export sollte jedes der betroffenen Felder eine eindeutige Aussage enthalten (auch 'Fehler' ist eine Aussage).

Tricks
Im alltäglichen Kampf mit der 'alten' Datenbank haben deren AnwenderInnen meist einige Tricks entwickelt, um die Software zu überlisten, wenn das notwendig ist. Sie sollten diese Tricks kennenlernen und darauf reagieren:
Am besten ist es, wenn die alten Daten so korrigiert werden, dass die Tricks nicht mehr notwendig sind. Mindestens jedoch muss die neue SQL-DB alle derartigen Fälle sauber berücksichtigt.
Archiv
Die Migration einer DB-Lösung ist der richtige Zeitpunkt zur Archivierung nicht mehr benötigter Kartei-Leichen. Veraltete Daten werden niemals gelöscht, sondern lediglich aus der laufenden DB in ein Archiv übertragen.
Zur Archivierung wird am besten ein eigenen Feld vorgesehen. Je nach den Daten dieses Feldes werden die Daten archiviert oder in die neue Version übernommen.

Meist ist es sinnvoll, die Daten des Archiv-Feldes automatisch einzugeben. Man sucht z.B. gezielt nach Kunden, die schon jahrelang nichts gekauft haben, oder nach Artikeln, die schon jahrelang nicht mehr im Sortiment sind. Darüber hinaus können MitarbeiterInnen wertvolle Daten liefern: Jeder kennt den Daten-Mist, der bei der eigenen Arbeit öfters auftritt und kann solche Daten zur Archivierung markieren.
Auch offensichtlich fehlerhafte Datensätze werden nicht gelöscht sondern archiviert.

Wenn die Tabellen ihrer DB verknüpft sind, dann müssen sie die Archivierung genau überlegen und testen. Bei Entfernung von Kunden- oder Artikel-Daten können/müssen z.B. auch dazugehörende Rechnungen entfernt werden, usw.

Die Archiv-Daten könnten einfach in der 'alten' DB bleiben, und werden nicht in die SQL-DB exportiert. Das ist problematisch, denn nach einiger Zeit wird die alte DB-Software auf keinem PC mehr laufen.
Besser ist es, die Daten getrennt zu exportieren: Archiv-Daten werden auf Datenträger (CD) kopiert, Live-Daten in die SQL-Lösung übernommen.

Die Archivierung kann unabhängig von der Übersiedlung der Lösung auf den SQL-Server bereits lange vorher erfolgen. Das ist vorteilhaft, denn wenn sich im realen Betrieb herausstellt, dass manche archivierte Daten noch gebraucht werden, dann wird das noch vor der Migration korrigiert.

Zeichensatz

Ältere PC-Programme verwenden meist nationale Zeichensätze wie z.B. → ISO-8859 oder sogar firmen-spezifische Zeichensätze wie → CP-1250. Das ist nicht mehr zeitgemäß, beschränkt die Anzahl verwendbarer Zeichen und behindert den Austausch der Daten. Für neue Entwicklungen wird nur der Standard → Unicode verwendet, meist in der Codier-Form → UTF-8.
Ältere Daten müssen in UTF-8 umgewandelt werden. Davon sind in deutschen Texten die Zeichen ÄÖÜäöü߀ betroffen.
Die Umwandlung erfolgt zwar am besten vor dem Export, die PC-Programme sind dazu jedoch meist ungeeignet. Insbesondere neigen MS-Programme zur unkorrekten Codierung des €-Zeichens. Die Code-Umwandlung wird daher entweder mit einem eigenen Programm (z.B. Perl, PHP) an den exportieren Daten durchgeführt, oder erst nach dem Import in die SQL-Datenbank.
♦ Details zu Zeichen-Codes, Unicode und UTF-8.

Binäre Daten

(z.B. Bilder) können in manchen Datenbanken gespeichert werden. Sie werden für den Transport am besten in lesbaren Text oder in einzelne binäre Dateien umgewandelt. Überlegen sie bei dieser Gelegenheit, ob die Daten tatsächlich in einer Datenbank am besten aufgehoben sind. Eine Alternative ist die Ablage von Bild-Dateien im Dateisystem und die Speicherung der Pfade zu den Bildern als Texte in der Datenbank.
Für die Decodierung / Codierung von Binär-Daten eignet sich z.B. der Binhex-Algorithmus, der auch von einigen Programmiersprachen unterstützt wird.

Leere oder unbekannte Werte (NULL)

Wenn ein Feld unbekannte Daten enthält, dann wird dieser Fall (NULL) von einem leeren Text ("") oder der Zahl (0) von SQL streng unterschieden. Ältere Software nimmt die Unterschiede nicht so genau. Überlegen sie, ob solche Fälle vorkommen, ob sie zulässig sind, und wie sie für den Export eindeutig zu codieren sind.

Zahlen

Ganze Zahlen (z.B. 1, 2, 3, ...) mit oder ohne Vorzeichen stellen kein Problem dar. Sie werden von jeder Software fehlerlos in Texte und zurück in Zahlen umgewandelt, und zwar unabhängig davon, ob führende Nullen oder Leerzeichen entfernt wurden.
Gleitkomma-Zahlen (z.B. 3.141592) werden am besten mit der intern verwendeten → Genauigkeit (7 oder 14 Dezimalstellen) in Text umgewandelt.
Dezimal-Komma: Alle Programmiersprachen und SQL verwenden Komma-Punkte, nur deutsche Versionen von AnwenderInnen-Programmen verwenden Komma-Beistriche. Das Komma-Zeichen muss in solchen Fällen ausgetauscht werden.
Kommerzielle Daten erfordern meist nur die Festlegung auf ein Komma-Zeichen. Die Angabe von 2-5 Dezimalstellen genügt meistens.
Technisch-wissenschaftliche Daten erstrecken sich oft über große Werte-Bereiche. In diesen Fällen muss entweder der minmal / maximal vorkommende Zahlenwert analysiert und für die Komma-Stellen berücksichtigt werden, oder man verwendet die Exponential-Darstellung mit entsprechend vielen Nachkomma-Stellen.

Datum und Zeit

werden von den meisten älteren Programmen in einem internen Format gespeichert. → MS-Access oder → Filemaker verwenden spezielle Formate, die Daten sind daher für die direkte Übernahme in eine SQL-Datenbank ungeeignet.
Datum und Zeit werden dazu entweder in Strukturen zerlegt oder in Texte (Strings) codiert.

Die Verwendung von Strukturen ist die sicherste Variante: Vor (!) dem Export werden alle Datum-&-Zeit-Werte in 6 ganzzahligen Bestandteile (YYYY, MO, DD, hh, mi, ss) zerlegt, danach wieder zusammengesetzt.

Die Verwendung von Texten (Strings) ist einfacher, aber riskanter: Sie müssen unbedingt sicherstellen, dass die Daten eindeutig (!) codiert und decodiert werden.

MS-Access exportiert in der deutschen Version ein Datum in der Form dd.mo.yyyy in variabler Länge: Einstellige Tage und Monate verkürzen den exportierten Text.

Eine sichere Form der SQL-Eingabe sind Strings fixer Länge nach → ISO-8601 in der Form "YYYY-MO-DD".
Sie haben die Wahl, ISO-Strings vor dem Export mit Funktionen der alten Datenbank zu erstellen, oder bei der Verarbeitung aus dem exportierten Datum-Text zu erzeugen.
Das Jahr sollte in Texten immer 4stellig angegeben werden. 2stellige Varianten sind zu unsicher.
Zeitzone und Sommerzeit können Probleme verursachen: Kleine lokale PC-Programme speichern meist ungefragt die jeweilige Lokalzeit. Größere (international verwendete, professionelle) Datenbanken verwenden jedoch ausschließlich die Weltzeit UTC. In diesem Fall muss die Lokalzeit bei einem Transport der Daten umgerechnen (inkl. Sommerzeit !).
♦ Details zu Datum und Zeit (interne Datenformate, ISO-8601, SQL)

Daten: Schlüssel (Primary Key, foreign keys)
Jede Tabelle muss ein Feld (Primärschlüssel, Primary Key) mit einem eindeutigen Inhalt enthalten. Dieses Feld darf nicht leer oder unbestimmt sein (NOT NULL), und es darf innerhalb einer Tabelle keine Dubletten von Primärschlüsseln geben (gleiche Werte in mehreren Datensätzen / Zeilen).
Mit Hilfe der Schlüssel wird die Verknüpfung aller Daten organisiert.

Der Schlüssel am besten durch eine fortlaufende positive ganze Zahl (Unsigned Integer) realisiert. Diese Zahl sollte von der Datenbank automatisch vergeben werden (auto-increment).
Schlüssel-Daten sollten für menschlichen Zugriff unzugänglich sein, jedenfalls muss eine Änderung durch AnwenderInnen ausgeschlossen werden. 		Es hat sich bewährt, für die DB immer eigene interne Schlüssel zu verwenden - Auch dann, wenn ein anderes Daten-Feld die Forderungen scheinbar erfüllt.

Ein typisches Beispiel ist die Sozialversicherungs-Nummer, die für jede Person eindeutig sein sollte.
In der Realität müssen jedoch manchmal Datensätze auch für Personen angelegt werden, die (noch) keine SVNr haben oder deren SVNr unbekannt ist, durch Tippfehler können Dubletten auftreten, usw.
In all diesen Fällen arbeitet die DB mit ihrem eigenen (unzugänglichen) Schlüssel korrekt, unabhängig von den real aufgetretenen Problemen.
Ähnlich unzuverlässig sind alle vergleichbaren Daten, wie z.B. Artikel-Nr, KundInnen-Nr, Konto-Nummern, Auto-Kennzeichen, usw...
● Wenn einige Tabellen ihrer DB-Lösung noch kein Schlüssel-Feld haben, dann müssen sie das Feld anlegen und eindeutig fortlaufend nummerieren. Jede DB-Software bietet das Werkzeug dazu. Sie sollten diesen Punkt auch dann erfüllen, wenn sie nicht vorhaben, die Daten dieses Feldes zu verwenden (z.B. für Verknüpfungen)

● Wenn es Tabellen gibt, deren Schlüssel durch AnwenderInnen eingegeben oder geändert werden, dann ergänzen sie diese Tabellen durch einen automatisch erzeugten internen Schlüssel. Das manuell eingetragene Feld bleibt erhalten, jedoch ohne Schlüssel-Funktion.

● Das Schlüssel-Feld darf in keinem Datensatz leer sein.

● Es darf keine Schlüssel-Dubletten geben.
Manche DB-Software bietet die Möglichkeit, nach Dubletten gezielt zu suchen. Wenn das nicht möglich ist, dann sortieren sie alle Datensätze nach dem Schlüssel und suchen nach Datensätzen, welche im Schlüssel den gleichen Wert aufweisen wie der nächste / vorige Datensatz. Je nach Software finden sie leere Schlüssel am Anfang oder am Ende der sortierten Tabelle. 		● Falls es leere Schlüssel oder Schlüssel-Dubletten gibt, dann muss einer der Datensätze einen neuen (garantiert noch nicht verwendeten) Wert erhalten.
Dabei muss besonders darauf geachtet werden, ob der zu ändernde Schlüssel evtl. als Fremdschlüssel in anderen Tabellen verwendet wurde. Wenn das zutrifft, muss der Wert auch in diesen Feldern geändert werden - Diese heikle Prozedur erfordert genaue Planung und darf nur nach dem Ende der Betriebszeit (in der Nacht, am Wochenende) ausgeführt werden, wenn keine anderen AnwenderInnen mit der DB arbeiten.

● Es spielt keine Rolle, wenn der Schlüssel Lücken aufweist (wenn z.B. Werte 100 . . 199 nicht vorkommen).
Die 'freien' Schlüssel-Werte archivierter oder gelöschter Datensätze sollten keinesfalls für neue Datensätze verwendet werden.

Daten: Zahlen

Einschränkungen

Für Zahlen-Felder (wie für alle Daten-Typen) gilt:
● Wenn eine Einschränkung sinnvoll möglich ist, dann sollt sie auch realisiert werden. Das vermindert die Gefahr von Fehlern.

Beispiel: Wenn in einem Feld nur positive ganze Zahlen im Bereich 0..100 vorkommen 'können', dann sollten sie dafür sorgen, dass dieses Feld tatsächlich nur solche Daten enthält, d.h. keine Texte, keine negativen Zahlen usw.
● Wenn eine Einschränkung existiert, dann müssen sie garantieren, dass alle betroffenen Daten nur zulässige Werte enthalten.

● Wenn keine Einschränkung existiert, dann werden die vorliegenden Daten analysiert, ob man eine solche einfühten könnte: Durch jede Art der Einschränkung verringert sich die Anzahl möglicher Fehler, durch Anklicken von Kategorien verbessert sich der Komfort, die Sicherheit und die Arbeits-Geschwindigkeit.

Leer

Leere Zahlenfelder sind nur selten sinnvoll. Meistens deuten solche Werte auf falsche oder fehlende Daten hin. Klären sie, ob leere Felder zulässig sind.
Falls nicht, können die Daten leerer Felder meist durch die Zahl 0 ersetzt werden.

Sonder-Werte

Stellen sie fest, ob es sinnvoll möglich ist, die Aussagen "Unbekannt" oder "Fehler" zu codieren. Wenn das sinnvoll ist, werden dafür meist Zahlenwerte außerhalb des 'normal' zulässigen Bereichs verwendet (z.B. -1)
Vor dem Export sollten jedenfalls alle als fehlerhaft erkannten Daten auch als solche eingetragen werden.

Daten-Typ

Kontrollieren sie den Daten-Typ: Unter besonderen Umständen sind manchmal andere Daten (Text) in die Felder gelangt. Sie müssen solche Fälle finden und die unzulässigen Daten ersetzen.
Typische Fehler: Texte in Zahlen-Feldern, Gleitkomma-Zahlen in Ganzzahlen-Feldern.

Werte-Bereich

Kontrollieren sie den Werte-Bereich: Alle Daten-Werte müssen innerhalb des vorgegebenen Bereichs liegen.
Wenn das nicht zutrifft, dann muss entweder der zulässige Bereich erweitert werden, oder die Werte der Daten müssen ersetzt werden. In solchen Fällen liegen meistens fehlerhafte Ausreißer (z.B. durch Tippfehler) vor.

Dezimalkomma

Programmiersprachen und SQL verwenden aussschließlich einen Dezimalpunkt. Deutsche AnwenderInnen-Software verwendet meistens ein Dezimal-Beistrich. Stellen sie durch Tests fest, ob ihre alte DB Gleitkomma-Zahlen mit Dezimalpunkt exportieren kann. Falls nicht, müssen alle Dezimal-Beistriche nach dem Export durch Dezimal-Punkte ersetzt werden.

+ Gleitkomma-Bereich und -Genauigkeit: Beim Export wird die intern meist sehr hohe Genauigkeit von Zahlen auf die Anzahl der exportierten dezimalen Ziffern reduziert.
Kommerzielle Daten sind meistens mit 2-5 Nachkomma-Stellen ausreichend genau dargestellt. Wenn jedoch technisch-wissenschaftliche Daten vorliegen, dann können diese einen sehr großen Werte-Bereich umfassen. Dafür ist die Exponential-Darstellung üblich, z.B. 299792458  = 2.99792458E08
Kontrollieren sie, ob ihre DB Zahlen in diesem Format exportieren kann. Falls nicht, kann es notwendig sein, ein zusätzliches Feld anzulegen und darin die Zahl als Text (!) im Exponentialformat einzutragen (natürlich mit Dezimal-Punkt). Dieses Feld wird an Stelle der Zahl exportiert und kann problemlos in einem SQL-Dump-Befehl verwendet werden.

+ Analyse: Wenn ein Zahlenfeld noch keine Beschränkung enthält, dann sollten sie unvoreingenommen die vorhandenen Werte testen:
Wenn sich dabei Minimal- und Maximal-Werte abzeichnen, ist es meistens sinnvoll, die Eingabe von Daten (in der SQL-Datenbank) auf diesen oder einen etwas größeren Bereich zu beschränken.
Bei ganzen Zahlen sollten sie eine Statistik ihrer Häufigkeit anlegen. Wenn sich zeigt, dass nur wenige Werte verwendet werden, dann ist es naheliegend, dieses Feld auf eine Auswahl-Liste zu beschränken.

Daten: Datum und Zeit
Datum und Zeit wird je nach Software in einem anderen (nur intern zugänglichen) Format gespeichert. Dazu werden Zahlenwerte verwendet. Normalerweise gibt es 2 Methoden zum sicheren Export von Datum-&-Zeit Daten: Als Strukturen ganzer Zahlen oder als Standard-Text. Wenn sie mit der internen Codierung vertraut sind, dann können sie diese Zahlen exportieren und sinnvoll zu SQL-Befehlen verarbeiten. In diesem Falle sollten zur Validierung alle Punkte beachtet werden, die für Zahlen-Felder angeführt sind.

Sonder-Werte

Leere Felder sowie die Aussagen für "Unbekannt" und "Fehler" werden so behandelt wie bei allen anderen Feldern.

Teilweise unbekannt

Bei Datum und Zeit ist es möglich, dass die Daten 'teilweise' bekannt sind.
Nur wenige DB-Lösungen gehen sauber mit solchen Fällen um, obwohl sie häufig vorkommen. So hat z.B. das Datum einer Fotografie durchaus einen Wert, wenn nur Jahr und Monat bekannt sind, nicht jedoch der Tag. Sie sollten feststellen, ob solche Fälle in der alten DB möglich sind, und wie sie codiert werden. Meist haben die AnwenderInnen Tricks entwickelt, mit solchen Fällen in der Praxis umzugehen. Sie sollten diese Gewohnheiten kennen und in geordnete Bahnen lenken.
Dabei hilft eine Analyse der Daten: Wenn z.B. der erste Monatstag eine wesentlich höhere Häufigkeit als alle anderen Monatstage aufweist, dann ist klar, wie ein unbekannter Tag eingegeben wird.

Jahr

Alle vorkommenden Jahreszahlen müssen 4stellig sein, oder vor dem Export auf 4stellige Zahlen geändert werden.

Struktur

Datum & Zeit können für den Export in ihre Bestandteile zerlegt und getrennt als Strtukturen zusammengehörender ganzer Zahlen (yyyy,mo,dd,hh,mi,ss) exportiert werden.
Diese Variante ist sehr sicher und funktioniert mit allen Systemen.
Sie sollten sicherstellen, dass nur zulässige Werte in den Zahlen auftreten, z.B. 1..mo..12
Andernfalls kann die Ziel-Software unerwünschte Resultate liefern.

ISO-Text

Alternativ können sie Datum & Zeit in Standard-Texte codieren, am besten in Strings fixer Länge nach ISO-8601 ("yyyy-mo-dd hh:mi:ss";). Der String wird an Stelle des Datum-Feldes exportiert.

- Access exportiert (in deutschsprachigen Versionen) Datum und Zeit ungefragt als Texte in der Form (dd.mo.yyyy hh:mi:ss). Die Länge ist variabel, da keine führenden Nullen verwendet werden. Solche Daten werden wie Zahlen exportiert (ohne Text-Kennzeichen).

Datum: Text
Die große Mehrheit aller in DB gespeicherten Daten sind Texte.
Da der gesamte Export als Text erfolgt, haben manche Zeichen als 'Steuerzeichen' besondere Bedeutung, z.B. zur Kennzeichnung der Grenzen von Feldern und Datensätzen. Auf Grund dieser Mehrfach-Bedeutung sind einige Maßnahmen notwendig.

Zeichen-Code

Tatsächlich werden keine Zeichen gespeichert, sondern nur der intern verwendete Code, z.B. Code=65 für das Zeichen A.
In einer globalisierten Welt werden unterschiedliche Codes verwendet. Der gleiche Zahlenwert kann daher in einem anderen Staat oder auf einem anderen Betriebssystem ein anderes Zeichen darstellen.
Diese Tatsache muss bei der Übersiedlung von Daten berücksichtigt werden.

Sonder-Werte

Leere Text-Felder sowie die Aussagen für "Unbekannt" und "Fehler" werden so behandelt wie bei allen anderen Feldern.

Steuer-Zeichen

Einige Punkte sorgen für eine sinnvolle Einschränkung der verwendeten Zeichen:
Die nicht druckbaren Steuerzeichen sollten nicht vorkommen. Dazu gehören z.B. Glocke (Code=7), Tabulator (Code=9), Zeilen-Umbruch (Code=10 und/oder Code=13), das Lösch-Zeichen (Code=127) und das geschützte Leerzeichen (Code=160). Wenn nicht unbedingt notwendig, werden diese Zeichen aus allen Textfeldern aller Tabellen entfernt oder durch Leerzeichen (Code=32) ersetzt.

Umbruch

Wenn es unbedingt notwendig ist, in einem Feld nicht druckbare Sonderzeichen zu führen, dann erstellt man dafür ein zusätzliches Feld, in dem diese Zeichen maskiert werden. Dieses Feld wird an Stelle der Original-Daten exportiert.
Ein Text mit       Tab und
Umbruch erscheint dann im Export als
"Text mit \t Tab und \n Umbruch";

Trennzeichen

Es wird analysiert, wie oft Kandidaten für Trennzeichen vorkommen ( , ; # \ ' " usw.).
Nur wenn gesichert ist, dass ein bestimmtes Zeichen in keinem Textfeld keiner Tabelle vorkommt, kann es beim Export als Trennzeichen verwendet werden.
Wenn ein Zeichen nur sehr selten vorkommt, dann kann man es meist durch ein anderes ersetzen und danach als Trennzeichen verwenden.

+ Wenn das ausgewählte Trennzeichen in manchen Feldern zugelassen werden muss, dann wird es am besten maskiert, so wie für Tabulator und Umbruch beschrieben.

+ Alle Mehrfach-Leerzeichen werden durch einfache Leerzeichen ersetzt. Das wird so lange durchgeführt, bis keine Treffer mehr auftreten.
Diese Punkte betreffen die verwendeten Zeichensätze:

+ + Wenn mit der Übersiedlung auch ein Wechsel des Zeichensatzes erfolgt, dann können die Texte bereits in der 'alten' DB umgewandelt werden.
Die betroffenen Felder bleiben unverändert, zusätzliche Felder mit den gleichen Texten in einem anderen Code werden (z.B. mit VBA) berechnet und später exportiert. So kann man z.B. Übersiedlungen Apple-EBCDIC-DOS-Windows gut vorbereiten.
+ In seltenen Fällen enthalten alte Daten Unicode-Sonderzeichen (z.B. slawische, griechische .. Zeichen). Diese Daten werden z.B. von Access ohne Warnung fehlerhaft oder gar nicht als Text exportiert. Die Texte müssen daher vor dem Export in eine Transport-Form umgewandelt werden, z.B. in UTF-8.
+ Das Euro-€-Zeichen (Unicode 8364) wird von M$-Software gerne mit Code=128 falsch codiert. Wenn das Zeichen in Texten vorkommt, dann wird es am besten maskiert, und später mit dem korrekten Code in die SQL-Datenbank eingegeben. 		 
Text  

Daten: Kategorie
Kategorie-Daten dürfen nicht alle Werte annehmen, sondern nur die Werte einer Auswahl-Liste. Das kann Text- oder Zahlen-Felder betreffen.
● Wenn eine solche Einschränkung sinnvoll möglich ist, dann sollte sie unbedingt realisiert werden. - Das verbessert die Sicherheit gegen Fehler und den Komfort bei der Anwendung. 		Je nach Anwendung kann nur ein einziger Wert zulässig sein (wechselseitiger Ausschluss, z.B. durch 'radio-buttons') oder eine Kombination mehrerer Werte (z.B. durch 'checkboxes' oder Listen mit Mehrfach-Auswahl).

Kategorie-(Auswahl)-Liste


● Die Auswahl-Liste selbst sollte in einer eigenen Tabelle enthalten sein.
Wenn das noch nicht der Fall ist, dann sollte diese Tabelle bereits vor der Übersiedlung der Daten-Hauptmenge in der SQL-DB angelegt und die Werte eingetragen werden. Achten sie darauf, in der Tabelle ein Schlüssel-Feld anzulegen - Dieses Feld wird später als Fremdschlüssel in anderen Tabellen eingesetzt.

● Die Auswahl-Liste sollte keine nicht-druckbaren Zeichen (Tabulator, Zeilen-Umbruch) und keine Interpunktions-Zeichen (, . ; :) enthalten, am besten auch keine Leerzeichen. Wenn möglich wird die Liste bereinigt und alle bestehenden Daten entsprechend ersetzt.
● Jedes Element der Auswahl-Liste sollte eine vernünftig überschaubare Anzahl an Datensätzen (Treffern) ergeben. Wenn sie z.B. KundInnen nach Marketing-Kategorien einteilen, dann sind 2 verschiedene Kategorien vermutlich zu wenig, aber 30 Kategorien unsinnig und unübersichtlich. Erstellen sie eine Statistik (s.u.) und prüfen sie gemeinsam mit den Betroffenen eine vernüftige Erweiterung oder Kürzung der Auswahl-Liste.

● Erstellen sie für jede Auswahl-Liste eine Statistik ihrer Verwendung: • Den größten praktischen Wert haben Kategorien mit ähnlichen Anteilen an den Daten.
Beispiel: Artikel-Gruppen, nach denen ihre Artikel in 5 etwa gleich große Bereiche geordnet werden.
• Den geringsten Wert haben Kategorien mit sehr vielen oder sehr wenigen Treffern. Sie sollten mit den Betroffenen eine Aufspaltung oder Abschaffung solcher Kategorien diskutieren.
Wenn eine Änderung erfolgen soll, dann müssen alle davon betroffenen Daten sinnvoll geändert werden:

Katgorie-Daten


+ Alle Daten müsen auf zulässige Werte überprüft werden. Zulässig sind nur die Werte der Auswahl-Liste. Unzulässige Daten müssen entweder durch zulässige ersetzt werden, oder es wird die Liste entsprechend ergänzt.

+ Leere Werte werden meist besser durch sinnvolle Start-Werte (z.B. "Neukunde") ersetzt.
+ Wenn Mehrfach-Auswahl (z.B. mit checkboxen) möglich ist, dann müssen derartige Daten vor dem Export fast immer aufbereitet werden.
Das Original-Datenfeld bleibt unverändert, wird jedoch nicht exportiert.
Erstellen sie ein zusätzliches Text-Feld, dessen Inhalt berechnet wird: Das Feld soll alle ausgewählten Daten als eindeutig formatierte Liste enthalten, z.B. Worte ohne Leerzeichen und Sonderzeichen, voneinander durch Beistrich getrennt.
Dieses Feld wird später zum Export verwendet, daraus kann man bequem die Daten der SQL-DB entnehmen.

Datensätze fixer Länge
Datensätze fixer (Text)-Länge wurden früher auf Großrechnern eingesetzt und sind heute kaum noch üblich.
Sie müssen für jedes (!) Feld jeder Tabelle die maximal vorkommende Anzahl Zeichen feststellen. Damit wird die fixe Länge des jeweiligen Feldes festgelegt. 		Die fixe Länge eines Datensatzes ergibt sich als Summe der Längen aller darin enthaltenen Felder.
Der große Vorteil dieses Text-Formates ist, dass die darin enthaltenen Texte alle Zeichen enthalten dürfen.
Ein großer Nachteil: Beim Transport der Daten macht ein einziges fehlendes oder überschüssiges Zeichen alle folgenden Daten unbrauchbar. Noch schlimmer: Wenn einander 2 (4,6,..) derartige Fehler kompensieren, dann sind alle dazwischen liegenden Daten fehlerhaft, der Fehler kann jedoch unentdeckt bleiben.
Daten dieser Form werden z.B. aus Access so exportiert: Datei | Exportieren | Dateiname=personen_fix.txt | Dateityp=Text(*.txt) | Feste Breite | Fertigstellen (die führenden Nullen der Zahlenfelder werden von Access nicht exportiert).

Unten ein Beispiel für ein Perl-Programm zur Umwandlung einer derartigen Datei in einen SQL-Dump. 		Datei personen_fix.txt 
00101Alfred      Ammer
00102Berta       Bieder
00103Christian   Chormeister
00104Dora        Daun
00105Emil        Erpel
Die Darstellung ist nicht ganz korrekt, denn eine derartige Text-Datei kennt keinen Zeilen-Umbruch. Nach einer fixen Anzahl Zeichen/Datensatz folgt unmittelbar der nächste Datensatz.

Verarbeitung einer Text-Datei mit Datensätzen fixer Länge:


Das Beispiel rechts ist in → Perl programmiert, weil diese Programmiersprache zur Verarbeitung von Texten besonders gut geeignet ist.

Das Programm verarbeitet eine Text-Datei personen_fix.txt mit folgenden Feldern fixer Länge pro Datensatz:
p_index (5 Zeichen)
p_vorname (15 Zeichen)
p_zuname ( 20 Zeichen)
das ergibt 40 Zeichen pro Datensatz.

Von der Datei FIX wird in jedem Durchlauf der while-Schleife ein Datensatz $rec der Länge 40 Byte gelesen.
Mit einem Regulären Ausdruck ( → RegExp) wird er in 3 Teile der fixen Länge 5,15,20 Zeichen zerlegt und an die Variablen $p_index, $p_vorname und $p_zuname übergeben.
Das Hilfsprogramm strip entfernt nachfolgende Leerzeichen und maskiert die beiden Zeichen '\
Zuletzt wird ein SQL-Befehl $sql zusammengesetzt und in die Ausgabe-Datei SQL geschrieben.

♦ Details zur Eingabe und Ausgabe von Dateien mit Perl und zu Regulären Ausdrücken.
my($rlen,$rec,$sql);
my($p_index,$p_vorname,$p_zuname);
open(FIX,"personen_fix.txt");
binmode FIX;
open(SQL,"> export_sql.txt");
$rlen = 1;
while($rlen) {
$rlen = read(FIX,$rec,40);
if($rlen==40) {
$rec=~m/(.{5})(.{15})(.{20})/;
$p_index=$1+0;
$p_vorname=strip($2);
$p_zuname=strip($3);
$sql="INSERT INTO `personen` ";
$sql.="(`p_index`,`p_vorname`,`p_zuname`) ";
$sql.="VALUES($p_index,'$p_vorname','$p_zuname');";
print SQL "$sql\n";
}
}
close FIX;
close SQL;

sub strip{
my($t)=@_;
$t=~s/\s+$//;
$t=~s/'/''/;
$t=~s/\\/\\\\/;
return $t;
}

Datensätze variabler Länge
Datensätze variabler Länge sind die heute übliche Form zum Transport von Texten. Sie ist flexibler und platzsparend, erfordert jedoch Trennzeichen.
Die einzelnen Felder jedes Datensatzes werden durch Feld-Trennzeichen (field-separator) getrennt, die Datensätze durch Satz-Trennzeichen (record-separator, meist ein Zeilen-Umbruch). 		Übliche Feld-Trennzeichen sind Tabulator (ASCII-Code=9), Beistrich (comma-separated values, CSV, Code=44) oder Strichpunkt (Code=59), übliche Datensatz-Zeilen-Trennzeichen CR (Code=13), LF (Code=10) oder beide Zeichen zusammen.

Analysieren sie die Daten aller Text-Felder aus allen Tabellen:
Die von ihnen gewählten Trennzeichen sollten in keinem einzigen der Texte vorkommen !
Maskierung:
Wenn es nicht möglich ist, nach diesem Kriterium ein Trennzeichen zu finden, dann üssen manche Zeichen der Daten 'maskiert' werden. Dabei hält man sich am besten an eine bestehende Regel, z.B. zur Maskierung in C++ oder Javascript. So wird z.B. jeder Zeilen-Umbruch (Zeichen CR und LF) in die Zeichen-Kombination \r\n umgewandelt.
Alle zur Maskierung verwendeten Zeichen (hier z.B. \ ) müssen selbst maskiert werden, wenn sie im Text vorkommen, z.B. jeder backslash (\) in die Zeichen-Kombination \\
Vor (!) dem Export müssen alle betroffenen Texte in die maskierte Form umgewandelt werden.
♦ Details zur Maskierung von Zeichen.
Text-Kennzeichnung:
ist eine weitere Möglichkeit, bei der Ausgabe auch die verwendeten Trennzeichen zu exportieren. Jedes Text-Feld wird von Textbegrenzungszeichen eingeschlossen (meist " "). Das erspart die Maskierung, kompliziert aber die Verarbeitung.
Es ist möglich, dass sowohl Separator-Zeichen als auch Textbegrenzungszeichen in den Daten von Textfeldern vorkommen können.
Normalfall (Datenbank-Text, darunter exportierter Text):
Das ist ein Text
"Das ist ein Text";
Export-Steuerzeichen (Datenbank-Text, darunter exportierter Text):
Strich;Punkt und "Begrenzung"
"Strich;Punkt und ""Begrenzung""";
In einfachen Fällen ist der Aufwand zur Verarbeitung noch vertretbar. Sonderfälle (nur Datenbank-Texte) wie
; oder " oder ";" oder "; oder . .
erfordern jedoch einen hohen Aufwand - In solchen Fällen sollten sie besser eine Maskierung (s.o.) anwenden.
Daten wie im Beispiel rechts werden z.B. aus Access so exportiert:
Datei | Exportieren | Dateiname=personen_var.txt | Dateityp=Text(*.txt) | Mit Trennzeichen | Trennzeichen=Semikolon | Feldname in erste Zeile | Textbegrenzungszeichen=" | Fertigstellen
Hinweise:
Die 1. Zeile kann die Feld-Namen enthalten, leere Felder sind möglich, Text-Felder werden in " " eingeschlossen und können Separator-Zeichen enthalten, . . 		Datei personen_var.txt
"pers_pk";"pers_vorname";"pers_zuname";"pers_Zahl"
101;"Alfred";"Ammer";1,23
102;"Berta";"Bieder";-2,34
103;"Christian";"Chormeister";
104;"Dora";"Daun";1
105;"Emil";"Erpel";999
Verarbeitung einer Text-Datei mit Datensätzen variabler Länge:

Auch das Beispiel rechts ist in Perl programmiert.

Das Programm verarbeitet eine Text-Datei personen_var.txt mit folgenden Feldern variabler Länge:
p_pk, p_vorname, p_zuname
Feld-Trennzeichen ist ein Strichpunkt, Datensatz-Trennzeichen ein Zeilen-Umbruch.

Von der Datei VAR wird in jedem Durchlauf der while-Schleife ein Datensatz variabler Länge (= je 1 Zeile) gelesen.
Mit Funktion split wird er nach dem Trennzeichen ; in das Array fa zerlegt und an die Variablen $p_pk, $p_vorname und $p_zuname übergeben.
Zunächst werden alle Zeichen (" double quote) mit dem Hilfsprogramm strip entfernt, dann wird eine SQL-Anweisung $sql zusammengesetzt und in die Ausgabe-Datei SQL geschrieben.

In einer Luxus-Variante könnten sie aus der ersten Zeile die Namen der Felder lesen und direkt zur Formulierung des SQL-Befehls verwenden.

♦ Details zur Eingabe und Ausgabe von Dateien mit Perl und zu Regulären Ausdrücken.
my($rec,$sql);
my(@fa);
my($p_pk,$p_vorname,$p_zuname);
open(VAR,"personen_var.txt");
open(SQL,"> sql_dump.txt");
while ($rec=<VAR>){
@fa = split(/;/,$rec);
$p_pk = strip($fa[0])+0;
$p_vorname = strip($fa[1]);
$p_zuname = strip($fa[2]);
$sql = "INSERT INTO `personen` ";
$sql.= "(`p_pk`,`p_vorname`,`p_zuname`) ";
$sql.= "VALUES ($p_pk,'$p_vorname','$p_zuname');";
print SQL "$sql\n";
}
close VAR;
close SQL;

sub strip{
my($t)=@_;
$t=~s/"//g;
return $t;
}

Zum Inhaltsverzeichnis Homepage von PS-Trainer   >   Entwicklung   >   SQL   >   Dump