Inhaltsverzeichnisgcc.uni-paderborn.de/www/WI/WI2/wi2_lit.nsf... · Inhaltsverzeichnis 6 2...

LSUNG

5

23 Inhaltsverzeichnis

Einleitung 15

1 Das kleine Einmaleins der Visual-Basic-Datenbanken 29

1.1 Was ist eigentlich eine Datenbank? 301.1.1 Die Zukunft der Datenbanken: OLAP(?) 321.1.2 Datenbank = Tabelle + Datenstze + Felder 331.1.3 Wie wird aus Daten eine Datenbank? 351.1.4 Datenbanken eine technische Definition 371.2 Visual Basic und die Datenbanken 391.3 Das Datenbank-Management-System 401.4 Die Rolle der Jet-Engine 411.5 Allgemeines zu den Objekten 431.6 ADO oder DAO? 441.7 Die wunderbare Genialitt von SQL 441.8 Beziehungen zwischen Tabellen das relationale Modell 471.8.1 Die Rolle der Schlssel 501.8.2 Datenintegritt 521.8.3 Die Rolle der Indizes 521.9 Ein Blick zurck so war es frher 531.10 Wichtige Begriffe aus der Datenbankwelt 601.10.1 Die Rolle von ODBC 601.10.2 Die Rolle von OLE DB 631.10.3 Lokale Datenbanken und Remote-Datenbanken 631.10.4 Das Client/Server-Prinzip 651.11 Zusammenfassung 661.12 Wie geht es weiter? 671.13 Fragen 67

Inhaltsverzeichnis

Inhaltsverzeichnis

6

2 Datenbankdesign fr Visual-Basic-Programmierer 69

2.1 Allgemeine berlegungen zum Datenbankdesign 702.2 Regeln fr den Entwurf einer Datenbank 722.2.1 Von der Idee zum Datenbankdesign 722.2.2 Aller Anfang ist (nicht) schwer 732.2.3 Ein erster Entwurf fr eine Tabelle 742.2.4 Felder mssen einen einheitlichen Inhalt besitzen 752.2.5 Felder sollten einen Inhalt besitzen 752.2.6 Felder mssen thematisch zusammengehren 762.2.7 Felder mssen atomar sein die 1. Normalform 762.2.8 Das Problem der Redundanz 782.2.9 Die Rolle der Schlssel 792.2.10 Die Bedeutung der funktionalen Abhngigkeit 812.2.11 Die 2. Normalform keine teilweisen Abhngigkeiten 822.2.12 Die 3. Normalform keine transitiven Abhngigkeiten 852.2.13 Weitere Normalformen 872.2.14 Vorsicht vor bernormalisierung 872.2.15 ber den Sinn der Normalisierung 882.2.16 Das Problem der Mehrfachfelder 882.2.17 Designberlegungen bei der Fuhrpark-Datenbank 892.2.18 Die Rolle der Schlssel 922.2.19 Zusammenfassung zum Thema Datenbankdesign 952.3 Die Organisation einer Access-Datenbank 962.3.1 Die Rolle von Tabellen und Feldern 982.3.2 Der Datentyp eines Feldes 982.3.3 Bilder, Hyperlinks und andere binre Dinge 1002.4 Zusammenfassung 1012.5 Wie geht es weiter? 1012.6 Fragen 102

3 Die erste Datenbank im Eigenbau 105

3.1 Der Visual Data Manager 1063.1.1 Der Aufruf des Visual Data Managers 1073.1.2 Die Fenster des Visual Data Managers 1073.1.3 Die Mens des Visual Data Managers 1083.1.4 Die Symbolleiste des Visual Data Managers 1103.2 Das Anlegen einer neuen Datenbank 111

Inhaltsverzeichnis

7

3.2.1 Der Aufbau der Datenbank 1123.2.2 Der Aufbau der Tabelle Modelldaten 1123.2.3 Der Aufbau der Tabelle Fahrzeugdaten 1163.3 Das Anlegen von Tabellen in der Datenbank 1173.4 Das Anlegen von Feldern in einer Tabelle 1203.5 Die Eingabe von Daten 1253.5.1 Die Rolle der Stammdaten 1263.6 Das Erstellen einer Eingabemaske fr das

Bearbeiten der Daten 1293.7 Das Hinzufgen weiterer Tabellen 1303.8 Die Datenbank wird erweitert 1313.8.1 Festlegen eines Primrschlssels 1313.8.2 Sichtbarmachen einer Beziehung in Microsoft Access 1343.9 Anlegen einer UDL-Datei 1363.10 Zusammenfassung 1383.11 Wie geht es weiter? 1393.12 Fragen 139

4 Das ADO-Datensteuerelement und diegebundenen Steuerelemente 141

4.1 Steuerelemente knnen gebunden sein 1424.1.1 Alte und neue gebundene Steuerelemente 1434.1.2 Das Datensteuerelement als Vermittler 1444.2 Das ADO-Datensteuerelement stellt sich vor 1454.3 Das ADO-Datensteuerelement und die gebundenen

Steuerelemente in der Praxis 1464.4 Mehr ber das ADO-Datensteuerelement 1544.4.1 Die Eigenschaften des ADO-Datensteuerelements 1544.4.2 Die Methoden des ADO-Datensteuerelements 1564.4.3 Die Ereignisse des ADO-Datensteuerelements 1564.5 Weitere gebundene Steuerelemente 1574.5.1 Das DataGrid-Steuerelement 1584.5.2 Die CellText- und die CellValue-Eigenschaften 1644.5.3 Das DataList- und das DataCombo-Steuerelement 1644.5.4 Das Chart-Steuerelement 1654.5.5 Das DataRepeater-Steuerelement 1694.5.6 Das HFlexGrid-Steuerelement 176

Inhaltsverzeichnis

8

4.5.7 Das FlexGrid-Steuerelement 1774.5.8 Die Steuerelemente MonthView und DatePicker 1774.6 Zusammenfassung 1794.7 Wie geht es weiter? 1804.8 Fragen 180

5 Die ADO-Objekte stellen sich vor 183

5.1 Warum berhaupt Objekte? 1845.1.1 Ein Wort zur Versionsnummer 1855.2 Das ADO-Objektmodell in der bersicht 1875.3 Die Idee der Objektvariablen 1895.4 Das Connection-Objekt 1915.4.1 Herstellen einer Verbindung ber das ffnen eines

Connection-Objekts 1935.4.2 Herstellen einer Verbindung beim ffnen des

Recordset-Objekts 1935.4.3 Die wichtigsten Mitglieder des Connection-Objekts 1945.5 Das Recordset-Objekt 1955.5.1 Besonderheiten der Open-Methode 1965.5.2 Kurzer Exkurs: die Idee der Auflistungen 1985.5.3 Die Rolle des Datensatzzeigers 1995.5.4 Eine Frage des Cursors 1995.5.5 Die wichtigsten Mitglieder des Recordset-Objekts 2005.6 Das Field-Objekt 2035.6.1 Die wichtigsten Mitglieder des Field-Objekts 2035.7 Das Command-Objekt 2045.8 Das Parameter-Objekt Abfragen mit Parametern 2075.9 Das Errors-Objekt fr die Fehlerkontrolle 2095.10 Das Property-Objekt 2105.11 Die Ereignisse der ADO-Objekte 2115.11.1 Allgemeines zu den ADO-Ereignissen 2115.11.2 Die Parameter der ADO-Ereignisse 2145.11.3 Verhindern, da ein gendertes Feld in die Datenbank

bernommen wird 2165.11.4 Abschlieende Anmerkungen zu den ADO-Ereignissen 2185.12 ADO und Microsoft Access 2000 2185.13 Zusammenfassung 219

Inhaltsverzeichnis

9

5.14 Wie geht es weiter? 2205.15 Fragen 220

6 Der Umgang mit Datenumgebungen 223

6.1 Was ist eine Datenumgebung? 2246.2 Die Idee der Designer 2256.3 Warum sind Datenumgebungen so praktisch? 2276.4 Der Umgang mit dem Datenumgebungs-Designer 2286.5 Eine Datenumgebung fr die Fuhrpark-Datenbank 2296.6 Fortgeschrittene Eigenschaften der Datenumgebung 2346.6.1 Der direkte Zugriff auf die Recordset-Objekte 2356.6.2 Das Erstellen von SQL-Kommandos 2356.6.3 Der Aufbau von Befehlshierarchien 2366.6.4 Die Nutzung von SQL-Aggregatfunktionen 2386.6.5 Gruppieren des Fahrzeugbestands nach Fahrzeugtyp 2416.7 Zusammenfassung 2436.8 Wie geht es weiter? 2436.9 Fragen 244

7 Das ABC der Datenbanksprache SQL 245

7.1 Ein kurzer Rckblick zum Thema SQL 2467.1.1 AccessSQL 2477.1.2 SQL und VBA 2477.2 Ein berblick ber SQL 2497.2.1 Eine bersicht ber die wichtigsten SQL-Schlsselwrter 2497.3 Der Visual Data Manager als SQL-Trainer 2537.3.1 SQL-Abfragen mit Komfort 2557.4 Allgemeine Regeln zum Umgang mit SQL 2577.5 Das SELECT-Kommando 2587.5.1 Doppelte Datenstze ausfiltern mit DISTINCT 2617.5.2 Das Prdikat TOP 2627.5.3 Vergleiche mit Namen 2627.5.4 Ein Wort zu den Platzhaltern 2637.5.5 Vergleiche mit Stringvariablen 2647.5.6 Verknpfte Bedingungen 2657.5.7 Der Operator AND 2657.5.8 Der Operator OR 265

Inhaltsverzeichnis

10

7.5.9 Der Operator NOT 2657.5.10 Rechenoperationen in SQL-Kommandos 2667.5.11 Felder knnen einen Aliasnamen besitzen 2667.5.12 VBA-Funktionen 2667.6 Gruppieren von Datenstzen mit GROUP BY 2677.6.1 Die HAVING-Klausel 2677.6.2 Gruppierung und JOIN-Operation 2687.7 Das UPDATE-Kommando 2687.8 Das DELETE-Kommando 2697.9 Das INSERT-Kommando 2717.10 Aggregatfunktionen 2727.10.1 Aggregatfunktionen und Unterabfragen 2737.11 Verknpfungen mehrerer Tabellen 2747.12 Zusammenfassung 2757.13 Wie geht es weiter? 2757.14 Fragen 275

8 Der Umgang mit Datensatzgruppen 277

8.1 Datensatzgruppen ffnen und schlieen 2788.1.1 Das ffnen einer Verbindung 2788.1.2 Direktes ffnen eines Recordset-Objekts 2798.1.3 Feststellen, ob Datenstze vorhanden sind 2828.1.4 Die Anzahl der Datenstze feststellen 2828.1.5 Feststellen, was ein Recordset-Objekt so alles kann 2828.2 Ausfhren von SQL-Kommandos 2838.3 Schlieen von Datensatzgruppen 2858.4 Bewegen in der Datensatzgruppe 2858.4.1 Move around! 2858.4.2 Das direkte Ansteuern eines Datensatzes 2868.4.3 Ist das Ende erreicht? 2878.4.4 Die Position des Datensatzzeigers abfragen 2898.5 Sortieren von Datensatzgruppen 2898.6 Filtern von Datensatzgruppen 290

Inhaltsverzeichnis

11

8.7 Suchen und Finden von Datenstzen 2908.7.1 Die Find-Methode in der bersicht 2918.7.2 Die Find-Methode im Einsatz 2918.7.3 Die Seek-Methode im Einsatz 2928.8 Hinzufgen von Datenstzen 2948.9 Entfernen von Datenstzen 2948.10 Spezielle Operationen mit Datensatzgruppen 2958.10.1 Einlesen einer kompletten Datensatzgruppe 2958.10.2 Umwandeln einer Datensatzgruppe in eine Zeichenkette 2968.11 Zusammenfassung 2968.12 Wie geht es weiter? 2978.13 Fragen 297

9 Datenbankoberflchen 299

9.1 Die Validierung der Eingabe 3009.1.1 Abfrage auf NULL 3019.2 Die formatierte Anzeige von Datenbankfeldern 3029.2.1 Mehr ber das DataFormat-Objekt 3039.3 Das DataCombo-Steuerelement zum Darstellen einer

n:1-Beziehung 3069.4 Das HFlexGrid-Steuerelement zur Anzeige hierarchischer

Datensatzgruppen 3109.5 Ein Formular zum Bearbeiten der Modelldaten-Tabelle 3149.5.1 Das Bewegen in der Datensatzgruppe 3159.5.2 Hinzufgen eines neuen Datensatzes 3159.5.3 Aktualisieren des Datensatzes 3179.5.4 Lschen des aktuellen Datensatzes 3179.5.5 Suchen nach einem oder mehreren Datenstzen 3189.5.6 Den aktuellen Datensatz neu anzeigen 3199.5.7 Eine Anmerkung zum Schlu 3199.6 Das Jahr-2000-Problem 3209.7 Zusammenfassung 3249.8 Wie geht es weiter? 3249.9 Fragen 324

Inhaltsverzeichnis

12

10 ADO fr (etwas) Fortgeschrittenere 327

10.1 Zugriff auf Binrfelder 32810.1.1 Die ActualSize-Eigenschaft 32910.2 Zugriff auf Bitmaps in der Jet-Engine 33110.3 Recordset-Objekte zur Laufzeit anlegen 33610.4 Recordset-Objekte knnen sich selbst speichern 33710.5 Zugriff auf ISAM-Datenbanken 33810.5.1 Der Zugriff auf eine Excel-Tabelle per ODBC 33810.5.2 Der Zugriff auf eine Textdatei per ODBC 34010.5.3 Der Zugriff auf eine Textdatei per ISAM-Treiber 34210.6 Weitere Tips zu ADO 34310.6.1 ADO-Datensteuerelement zur Laufzeit initialisieren 34410.6.2 Update des aktuellen Datensatzes erzwingen 34510.6.3 Recordset-Objekte auf Nothing setzen 34510.6.4 Einzelne Spalten im DataGrid sperren 34510.6.5 Ausliefern einer ADO-Anwendung 34610.7 Zusammenfassung 34710.8 Wie geht es weiter? 34710.9 Fragen 347

11 Datenreports 349

11.1 bersicht ber den Datenreport-Designer 35011.1.1 Allgemeines zur Bedienung 35011.1.2 Hinzufgen eines Datenreports 35111.1.3 Das Hinzufgen von Datenbankfeldern 35211.1.4 Anordnen von Steuerelementen 35211.1.5 Einfgen von Seitenzahlen und Datum 35311.1.6 Allgemeine Tips fr das Erstellen eines Reports 35411.1.7 Eigenschaften und Methoden des Datenreport-Objekts 35411.2 Ein Datenreport Schritt fr Schritt erstellt 35511.2.1 Das programmgesteuerte Erstellen von Datenreports 35811.2.2 Ausblick auf etwas fortgeschrittenere Themen 35911.3 Zusammenfassung 35911.4 Ausblick 359

Inhaltsverzeichnis

13

Anhang A: Datenbankprogrammierung von A bis Z 361

Anhang B: Die Active Data Objects (ADO) 369

B.1 Das Connection-Objekt 369B.1.1 Die Eigenschaften des Connection-Objekts 369B.1.2 Die Methoden des Connection-Objekts 371B.1.3 Die Ereignisse des Connection-Objekts 372B.2 Das Recordset-Objekt 372B.2.1 Die Eigenschaften des Recordset-Objekts 372B.2.2 Die Methoden des Recordset-Objekts 374B.2.3 Die Ereignisse des Recordset-Objekts 376B.3 Das Field-Objekt 376B.3.1 Die Eigenschaften des Field-Objekts 376B.3.2 Die Methoden des Field-Objekts 377B.4 Das Command-Objekt 377B.4.1 Die Eigenschaften des Command-Objekts 377B.4.2 Die Methoden des Command-Objekts 378B.5 Das Parameter-Objekt 379B.5.1 Die Eigenschaften des Parameter-Objekts 379B.5.2 Die Methoden des Parameter-Objekts 380B.6 Das Property-Objekt 380B.6.1 Die Eigenschaften des Property-Objekts 380B.6.2 Die Methoden des Property-Objekts 381B.7 Das Error-Objekt 381B.7.1 Die Eigenschaften des Error-Objekts 381B.7.2 Die Methoden des Error-Objekts 381B.8 Die Ereignisse des Recordset-Objekts 382B.8.1 Die Parameter der ADO-Ereignisse 382

Anhang C: Die Data Access Objects (DAOs) 385

C.1 Einbinden der DAOs in ein Projekt 386C.2 Das DAO-Objektmodell 386C.3 Das Database-Objekt 388C.4 Das Recordset-Objekt 389C.5 Unterschiede zwischen Dynaset-, Snapshot- und

Table-Recordsets 390

Inhaltsverzeichnis

14

C.6 Kleine Beispiele zu den DAOs 390C.6.1 Durchlaufen einer Datensatzgruppe 390C.6.2 Die geheimnisvolle RecordCount-Eigenschaft 391C.6.3 Die Suche nach einem Datensatz 392C.6.4 Editieren von Datenbankfeldern 393C.6.5 ffnen Datenbankabfrage (ber ein QueryDef-Objekt) 394C.6.6 Anlegen eines QueryDef-Objekts 395C.6.7 Aktionsabfragen 396C.6.8 Abfragen mit Parametern 397C.7 Eine Gegenberstellung DAO zu ADO 398C.8 Versionsnummern bei DAOs 398C.9 Zusammenfassung 399

Anhang D: Antworten zu den Fragen 401

Anhang E: Ressourcen fr angehendeDatenbankprogrammierer 415

E.1 Bcher und Zeitschriften 415E.2 Microsoft-Webseiten 417E.3 Weitere Informationen im Internet 418E.4 Newsgroups 418E.4.1 Ein Tip zum Schlu 420

Stichwortverzeichnis 421

15

24 Einleitung

Die Datenbankprogrammierung ist ein wichtiges Thema. Vermutlich ist esfr Visual-Basic-Programmierer sogar das wichtigste Thema, denn bei einervon Microsoft im Vorfeld der Einfhrung von Visual Basic 6.0 durchgefhr-ten Umfrage setzten mehr als 90% der Befragten das Thema Datenbankzu-griff an oberste Stelle ihrer Priorittenliste. Es verwundert daher nicht, daMicrosoft bei Visual Basic den Datenbankzugriff von Version zu Versionverbessert hat und es auch zum Schwerpunkt knftiger Entwicklungen ma-chen wird. Doch was bedeutet Datenbankprogrammierung konkret? In denmeisten Fllen versteht man darunter den Zugriff auf bereits vorhandeneDatenbanken. Hier ein konkretes Beispiel von vielen aus der Praxis. StellenSie sich vor, eine Stadtbcherei hat sowohl ihren Buchbestand, die Adres-sen ihrer Entleiher als auch die aktuellen Entleihdaten (also wer zur Zeitwelches Buch ausgeliehen hat und welche Bcher von wem vorbestellt sind)in einer Datenbank untergebracht. Dann mu es natrlich mglich sein,nach diesen Daten zu suchen, um z.B. beim Entleihen eines Buches nachEingabe der Mitgliedsnummer den vollstndigen Namen des Entleihers undvielleicht auch die Titel aller noch nicht zurckgegebenen Bcher zu sehen.Dies ist eine typische Datenbankabfrage nach dem Motto Zeige mir alleDatenstze, die ein bestimmtes Kriterium erfllen. Aber Datenbankpro-grammierung bedeutet noch (viel) mehr. Zum einen mchten die Besitzerder Daten sehr schnell mehr aus ihrem Datenbestand (der nicht selten dasKapital des Unternehmens darstellt; denken Sie an die vielen Direktversen-der oder an Headhunting-Agenturen, die ohne ihre Geschftsdaten nichtfunktionsfhig wren) herausholen. Unsere Stadtbcherei mchte z.B. wis-sen, welche Buchkategorie am hufigsten ausgeliehen wird, wann ein be-liebtes Buch zum frhesten Termin vorbestellt werden kann oder in welchenStadtteilen die Ausleihfreudigkeit am hchsten ist. Alles das sind Dinge,

Einleitung

Kap

itel

2

Einleitung

16

die sich mit Datenbankprogrammierung ohne groen Aufwand erledigenlassen. Leider ist dabei auch schnell jene unsichtbare Grenze erreicht, diesich bei kritischer Betrachtung durchaus als Mibrauch der Daten auslegenlt. Wrde die Stadtbcherei z.B. die Namen ihrer schulpflichtigen Klien-ten, die ihre Bcher vormittags ausleihen, an die Schulbehrde weiterleiten,die sie wiederum mit den (in einer anderen Datenbank gespeicherten) Stun-denplnen vergleicht, um jene Schler herauszufinden, die ihren persnli-chen Spielraum bei der Gestaltung ihres Unterrichts ber Gebhr ausnut-zen, so wre das zwar programmiertechnisch machbar und fr einen Pro-grammierer durchaus reizvoll, es wre aber auch (vermutlich) ein Verstogegen die Datenschutzbestimmungen1.

Datenbankprogrammierung bedeutet also in erster Linie das Abfragen dervorhandenen Daten. Zwar ist es kein Problem, eine Datenbank in VisualBasic (auch programmgesteuert) neu zu erstellen, doch wird diese Aufgabein der Regel von dem Datenbanksystem bernommen. Datenbankpro-grammierung beinhaltet aber auch andere wichtige Aufgaben, wie das so-genannte Einpflegen der Daten (also die bernahme neuer Daten in die Da-tenbank, etwa wenn eine komplette Schulklasse aufgenommen werden soll,die Stadtbcherei aber nur eine unvollstndige Liste der Namen und An-schriften erhlt), die Durchfhrung von Sicherungskopien, das Anfertigenvon Datenbankreports und andere Dinge. Kurzum, die Datenbankpro-grammierung ist ein hochinteressanter und vielseitiger Bereich. Und da un-sere (entstehende) Informationsgesellschaft immer mehr auf den RohstoffDaten angewiesen ist, gewinnt dieser Bereich immer mehr an Bedeutung.

Visual Basic und die DatenbankenWarum gerade Visual Basic? Warum werden die im letzten Abschnitt be-schriebenen Aufgaben nicht von dem Datenbankprogramm erledigt? Nun,so ist es in der Praxis in vielen Fllen auch noch. Wenn Sie etwa eineStadtbcherei betreten, werden Sie dort nicht automatisch (Windows-)PCsantreffen, sondern meistens sogenannte EDV-Systeme, bei denen die Da-tenbank und die Software, die auf die Datenbank zugreift, eine Einheit dar-stellen. Irgend jemand hat die Software in einer fr das Datenbanksystemtypischen Programmiersprache programmiert und das komplette System andie Stadtbcherei verkauft. Dies ist der traditionelle DV-Ansatz. Doch dieseAnstze befinden sich in der Auflsung. An Datenbankanwendungen wer-den Anforderungen gestellt, die sich mit traditionellen Systemen nicht mehrrealisieren lassen. Die Stadtbcherei wird mit anderen Stadtbchereien in

1 Das Beispiel ist natrlich konstruiert und nicht ganz ernst gemeint es soll lediglich diegrundstzlichen Mglichkeiten andeuten.

Einleitung

17

einen Verbund eingegliedert, die Buchbestnde sollen bergreifend abfrag-bar sein. In einer mobilen Bcherei sollen auch die Daten aller Hauptbche-reien abfragbar sein, die Datenbestnde mssen auf die Notebook-Compu-ter der mobilen Stationen repliziert werden. Das Ausleihen soll auch berdas Internet mglich sein und vieles mehr. Dies sind Dinge, die sich mit tra-ditionellen Datenbanksystemen im allgemeinen nicht oder nur mit hohemAufwand realisieren lassen. Jetzt kommt Visual Basic als ein vielseitiges,modernes und leistungsfhiges Programmiersystem ins Spiel, das vor allemeine preiswerte Software-Entwicklung ermglicht. Wer heute eine Daten-bankanwendung (also ein Programm, das auf einer Datenbank basiert) pro-grammiert, mu sich zwischen einer speziellen Lsung (bei der manchmalauch die Hardware schon vorgegeben ist) und einer universellen Lsungentscheiden. Beide Anstze haben ihre spezifischen Vor- und Nachteile. DerVorteil der ersten Lsung ist vor allem Stabilitt, Robustheit und eine ge-naue bereinstimmung mit dem Arbeitsablauf in dem Unternehmen (meistwurde dieser ber die Jahre an die Gewohnheiten der EDV-Anlage ange-pat). Der Vorteil der zweiten Lsung ist die Flexibilitt (und in der Regelauch der Preis), denn Visual Basic ist auf keine Datenbank fixiert, sonderndank standardisierter Schnittstellen (ODBC und OLE DB) weitestgehendoffen. In der PC-Welt gibt es eine groe Auswahl leistungsfhiger Daten-banksysteme: Oracle, Informix, Visual FoxPro, der SQL-Server von Micro-soft und natrlich Microsoft Access seien hier als Beispiele genannt. Diemeisten Datenbanksysteme bieten eine starke Datenbank, aber nur eineschwache Programmierungsumgebung (Visual FoxPro natrlich ausgenom-men). Hier kommt Visual Basic als leistungsstarke Ergnzung ins Spiel, dieentscheidende (Standort-)Vorteile besitzt: Es ist relativ leicht zu lernen, ver-hltnismig preiswert und inzwischen sehr weit verbreitet. Das ist derGrund, warum der Datenbankprogrammierung mit Visual Basic eine solchgroe Bedeutung zukommt, die in Zukunft vermutlich weiter steigen wird.

Visual Basic oder Microsoft Access?Dies ist eine wichtige Frage, die an dieser Stelle dennoch nur kurz abgehan-delt werden soll. Auch das populre Microsoft Access ist ein vollstndigesEntwicklungssystem, mit dem sich komplette Datenbankanwendungen er-stellen lassen. Allerdings kommt Microsoft Access aus der Ecke der Endan-wender-Produkte. Der normale Werdegang eines Access-Entwicklers siehtso aus: erst Microsoft Access als reine Endanwendung kennenlernen undnach und nach in die Programmierung mit VBA (frher AccessBasic) ein-steigen. Fr viele kleinere und mittlere Anwendungen ist das auch eine op-timale Strategie. Visual Basic ist dagegen ein universelles Entwicklungswerk-zeug mit einer sehr guten Datenbankschnittstelle. Allerdings steht die Da-

Einleitung

18

tenbank anders als bei Microsoft Access nicht im Mittelpunkt. Wer einneues Formular hinzufgt, erhlt damit keinerlei Datenbankanbindung.Diese mu erst Schritt fr Schritt hinzugefgt werden. Dafr bietet VisualBasic eine Reihe von Leistungsmerkmalen, die es bei Microsoft Access nichtgibt: einen echten Compiler (der Maschinencode produziert), die Mglich-keit, COM-Komponenten erstellen zu knnen, eine um Add-Ins und Desi-gner erweiterbare Entwicklungsumgebung (das gibt es erst bei Microsoft Ac-cess 2000) und vor allem ein Programmiermodell, das nicht automatischdatenbankzentriert ist. Vereinfacht lt sich folgende Empfehlung geben:Wer nicht oder nur wenig programmiert, aber eine richtige Datenbankan-wendung mit VBA-Programmierung erstellen mchte, ist bei Access besseraufgehoben. Wer dagegen in erster Linie an einem universellen Program-mierwerkzeug interessiert ist, aber die Datenbankprogrammierung dennochin den Mittelpunkt stellen mchte, findet mit Visual Basic das leistungsfhi-gere Werkzeug. Natrlich gibt es auch einen Bereich, in dem sich beideProdukte berschneiden.

ADO oder DAO keine leichte EntscheidungDatenbankprogrammierer, die mit Visual Basic oder Microsoft Access arbei-ten, stehen zur Zeit vor einer Entscheidung: ADO oder DAO? Beide Buch-stabenkrzel stehen fr eine Datenbankzugriffsmethode (am Ende des Bu-ches werden Sie diese und viele andere Krzel im Schlaf beherrschen), wo-bei ADO die moderne und DAO die alte Variante ist. Fr DAO spricht, daes sich in der Vergangenheit beim Zugriff auf Access-Datenbanken bewhrthat, es viele Programmierer beherrschen und ein Umstieg auf ADO einemehr oder weniger umfangreiche Neuprogrammierung erforderlich macht teilweise mit ungewissem Ausgang, weil noch nicht alle DAO-Merkmale un-ter ADO implementiert wurden. Fr ADO spricht der Umstand, da es dieZukunft in der Microsoft-Strategie ist. DAO drfte keine wesentlichen Wei-terentwicklungen mehr erfahren, Microsoft steckt die gesamte Entwick-lungsarbeit in ADO. Visual Basic 6.0 ist mit seinen neuen Datenbanktools,wie dem Datenumgebungsdesigner, der beste Beweis. Visual InterDev, dasMicrosoft Entwicklungssystem fr Webanwendungen, basiert vollstndig aufADO. ber kurz oder lang werden alle Programmierer auf ADO umsteigenmssen, wenngleich DAO auch von kommenden Visual Basic- und Access-Versionen untersttzt wird.

Da der Umstieg von DAO auf ADO noch eine Weile dauern kann, stelltesich natrlich auch fr mich als Buchautor die Frage, welcher Datenbank-technologie ich den Vorzug geben sollte. Auch wenn sich ADO und DAO inein und derselben Prozedur gemeinsam einsetzen (allerdings nicht kombi-nieren ein DAO-Recordset und ein ADO-Recordset sind inkompatibel)

Einleitung

19

lassen, mute eine Entscheidung getroffen werden, denn ein Mix aus DAOund ADO wrde nicht nur den Platzrahmen ber Gebhr beanspruchen, eswrde auch viele Leser irritieren. Nach reiflicher berlegung habe ich daherentschieden, ADO in den Mittelpunkt zu stellen und DAO weitestgehend zuignorieren. Auch wenn DAO, gerade wenn es um den Zugriff auf Access-Datenbanken geht, genau das ist, was ca. 70% aller Datenbankprogram-mierer jemals bentigen werden, die Zukunft gehrt ADO. Wer jetzt DAOlernt, wird mit an Sicherheit grenzender Wahrscheinlichkeit in den nchstenzwei bis drei Jahren wieder umlernen mssen. Zwar hneln sich ADO undDAO in ihren Grundzgen, doch ist das sehr viel flexiblere und universellereKonzept von ADO gerade fr erfahrene DAO-Programmierer eine echteHerausforderung. Diese vermissen ihre vertraute FindNext-Methode, dieSeek-Methode und die NoMatch-Eigenschaft und wundern sich, wie sie umalles in der Welt eine ODBC-Tabelle an eine Access-Datenbank hngenoder auf Datenbanken ber einen ISAM-Treiber zugreifen sollen. Wer dage-gen bereits mit den RDO-Objekten unter der Enterprise Edition von VisualBasic 5.0 programmiert hat, wird bei ADO viele vertraute Konzepte wieder-finden.

Als Anwender einer so zentralen Technologie wie es die Datenbanktechno-logie nun einmal ist, gert man schnell in die typische Microsoft-Falle.Microsoft (der Hersteller von Windows, Visual Basic, Office und vielen an-deren schnen Produkten) basiert seine gesamte Universal Data Strategy(UDA) auf OLE DB und ADO, einem beraus leistungsfhigen Konzept.Dagegen gibt es grundstzlich nichts einzuwenden. Im Gegenteil, ADO ver-spricht eine Menge und kann davon bereits jetzt einiges halten (ADO 1.0wurde ursprnglich mit dem Internet Explorer 4 eingefhrt). ADO bedeutetmaximale Flexibilitt bei maximaler Performance und vieles mehr. DasProblem dabei ist nur, da ADO eine Komplexitt einfhrt, von der vieleVisual-Basic-Programmierer nicht oder nur indirekt profitieren. Wer nureine Adreverwaltung, eine Lagerverwaltung, eine normale kaufmnnischeAnwendung oder eine Webdatenbank programmiert, kommt mit einer Da-tenbankfunktionalitt aus, die in eine 400 Kbyte groe DLL gepackt wer-den kann. Fr diese Anwender sind eine flexible Auswahl einer Datenquelle,Skalierbarkeit auf SQL-Server, asynchrone Abfragen, persistente Datenstzeund verbindungslose Recordsets einfach kein Thema. Dennoch zahlen Sieden Preis (in Form von Lernaufwand), den auch jene Programmierer zah-len mssen, die in Unternehmen Gigabyte groe Datenbanken mit Tausen-den von Anwendern konzipieren, die auf Multiprozessorensystemen laufenund Tag und Nacht im Einsatz sind. Das ist in etwa so, als wrde Microsofteinen Hochleistungs-LKW mit 24 Gngen, einem supermodernen Motor,geringem Benzinverbrauch, automatischer Be- und Entladung und anderenHigh-End-Eigenschaften zu einem konkurrenzlosen Preis (oder gar kosten-

Einleitung

20

los) anbieten. Fr Inhaber von Speditionsfirmen wre es eine tolle Sache(sofern die Wartungskosten nicht exorbitant sind), wer dagegen nur seinenUmzug machen oder ein paar Gegenstnde um den Huserblock fahrenwill, mu erst einmal einen Speziallehrgang fr Fernfahrprofis besuchen1.Bezogen auf die Datenbankprogrammierung sind die ADOs der hochmo-derne Truck, die DAOs der Kleintransporter, der strker auf die Bedrfnisseder klassischen PC-Datenbankprogrammierer ausgerichtet ist.

Eine der wenigen Alternativen zur Jet-Engine und den damit einhergehen-den DAO- und ADO-Schnittstellen ist CodeBase von der kanadischenFirma Sequiter (www.sequiter.com), das hohe Performance bei geringemPlatzbedarf verspricht und sich im Grunde als ideale Lsung darstellt. Hiergibt es keine Objekte (wenngleich ein Zugriff alternativ ber ODBC undOLE DB und damit ber DAO und ADO mglich ist), statt dessen sieht dieProgrammierung so aus, wie es einige ltere Datenbankprogrammierernoch aus der xBase- und Clipper-ra gewohnt sind. Allerdings ist CodeBasenicht ganz billig und erfordert letztendlich eine Programmierung, die mit dermodernen Visual-Basic-Programmierung nicht viel gemeinsam hat. Wer sichauf eine Speziallsung einlt, hat es spter einmal schwer, diese auf einanderes System zu bertragen.

Das bekannte Fazit lautet wieder einmal: Der Fortschritt ist nicht aufzuhal-ten und wer nicht technologisch auf ein Abstellgleis fahren will, mu sichanpassen. Die Radikallsung, nmlich die vllig Abkehr von einer Microsoft-Datenbankschnittstelle, kommt bei Visual Basic fr die meisten Program-mierer nicht in Frage. Zum einen gibt es kaum Alternativen zur Jet-Engine,DAO und ADO, zum anderen koppelt man sich ebenfalls vom Zug derEntwicklung ab und kann dann gleich bei Visual Basic 3.0 bleiben. Dieletzte Alternative wre der Einsatz eines ganz anderen Entwicklungssystems,doch soll diese Variante aus begreiflichen Grnden in diesem Buch nichtnher diskutiert werden2, zumal dort die gleiche Problematik, diesmal unteranderem Vorzeichen, wieder auftauchen drfte.

Die ganze Betrachtung soll Sie als hoffnungsfrohen Neuling bei der Daten-bankprogrammierung natrlich nicht entmutigen oder gar abschrecken. Siesoll lediglich die Entscheidung pro ADO ein wenig illustrieren und deutlichmachen, da es im Leben im allgemeinen und in der Software-Entwicklung

1 Ganz so kra ist ADO natrlich nicht, es sind auch mit ADO kleine und berschaubareProgramme mglich die Beispielprogramme in diesem Buch beweisen es.

2 Nicht, da dies ein Tabuthema wre, doch mu eine solche Entscheidung jeder nachsorgfltiger Abwgung der Vor- und Nachteile fr sich selber treffen. Eine allgemeineEmpfehlung ist praktisch unmglich.

Einleitung

21

im speziellen nur selten eindeutige Verhltnisse gibt. Die Wirklichkeit istuerst vielschichtig.

An wen richtet sich das Buch?Das Buch richtet sich an erfahrene Visual-Basic-Programmierer, die aberbislang mit der Datenbankprogrammierung entweder keinen Kontakt hattenoder die neuen ADO-Objekte noch nicht kennen. Gute Grundkenntnisse inder Visual-Basic- bzw. VBA-Programmierung werden vorausgesetzt. EinenEindruck soll der Titel nmlich nicht erwecken: Dies ist kein Buch fr Pro-grammiereinsteiger. Wer also gerade erst mit der Programmierung begon-nen hat oder vielleicht sogar erst davor steht, sollte sich zunchst einmal inRuhe mit den Programmiergrundlagen beschftigen (dafr empfehle ichganz uneigenntzig mein Buch Jetzt lerne ich Visual Basic, ebenfalls er-schienen bei Markt&Technik selbstverstndlich gibt es noch viele anderesehr gute Bcher zu diesem Thema, wobei auch das Handbuch gelobt wer-den mu). Das Buch setzt voraus, da Sie wissen, wie Visual Basic funktio-niert, die wichtigsten Sprachelemente von VBA kennen und vor allem mitdem Prinzip der Objekte (etwa der Mglichkeit, ber den MenbefehlEXTRAS/VERWEISE eine Typenbibliothek einbinden zu knnen) vertraut sind.Wer diese Grundkenntnisse nicht besitzt, wird manches in dem Buch nurschwer nachvollziehen knnen. Hier ein kleiner Schnelltest nach dem MottoWie gut kenne ich Visual Basic?. Welches Objekt wird durch den folgen-den Ausdruck angesprochen:

Anwendung.FensterListe("Hauptfenster")._UnterfensterListe("Unterfenster1").Titel?

Klar, dieser Ausdruck spricht (vermutlich) ein Unterfenster-Objekt an, ge-nauer dessen Titel-Eigenschaft1.

Eines mu man als angehender Datenbankprogrammierer wissen: Es gibtkeine einfache Datenbankprogrammierung. Visual Basic 6.0 bietetbereits eine Menge Komfort, kommende Versionen von Visual Basic wer-den diesen Komfort mit Sicherheit weiter steigern. Doch von diesem Kom-fort profitieren in erster Linie erfahrene Datenbankprogrammierer, die sichviele Routineschritte sparen knnen. Wer nicht wei, wozu die neuen Toolsda sind, und die einzelnen Begriffe nicht einordnen kann, wird den neuenKomfort auch nicht nutzen knnen. Um es einmal etwas harsch zu formu-lieren: Wer nicht wei, was ein Recordset oder eine ODBC-Datenquelle ist,

1 Hundertprozentig lt sich das aus dem Ausdruck allerdings nicht ableiten. Es istlediglich eine vernnftige Annahme, da eine Auflistung mit dem NamenUnterfensterListe auch Unterfenster-Objekte enthlt.

Einleitung

22

kann zwar den Datenumgebungsdesigner nach Anleitung bedienen und eineDatenbankanbindung herstellen. Er oder sie wird jedoch vermutlich nichtverstehen, welche Arbeit ihm oder ihr der Designer tatschlich abnimmtund welche Nachteile durch den Komfort erkauft werden. (Komfort zieht das ist eine Programmiererweisheit stets gewisse Nachteile bei Perfor-mance und Flexibilitt nach sich beim Datenumgebungsdesigner sind esallerdings erstaunlich wenige Nachteile.)

Diese Warnung soll natrlich niemanden entmutigen. Im Gegenteil, verste-hen Sie sie bitte als Herausforderung. Das vorliegende Buch soll Ihnen dieerforderlichen Grundlagen vermitteln. Erwarten Sie bitte nur nicht, da diesa) im Handumdrehen b) an einem Wochenende oder c) in 14 Tagen ge-schieht. Um ein guter Datenbankprogrammierer zu werden, knnen schonein paar Monate vergehen.

Als Belohnung winkt ein universelles Grundwissen, das Sie auf vielfltigeWeise einsetzen knnen. Es ist ein Wissen, das sich so schnell nicht ndernwird. Auch wenn es nicht den Anschein haben mag, so hat sich, was dieDatenbankwelt angeht, in den letzten 10 bis 20 Jahren nicht allzu viel ge-ndert.

Wie ist das Buch aufgebaut?Das Buch ist in zwlf hoffentlich bersichtliche Kapitel aufgeteilt, wobei je-des Kapitel einen anderen Aspekt der Datenbankprogrammierung mit Vi-sual Basic behandelt. Es beginnt ganz einfach mit dem allgemeinen Aufbaueiner Datenbank und endet bei fortgeschrittenen Themen, wie dem Anferti-gen von Datenbankreports. Ein warnender Hinweis aber vorweg. EineLinearitt bei der Vorgehensweise wre (wie in jedem Buch) wnschens-wert, lt sich aber leider bei diesem Thema nicht realisieren. Sie findendaher, vor allem in der Mitte des Buches, hufiger Themen, die erst in denfolgenden Kapiteln ausfhrlicher erklrt werden. So ist es sinnvoll, im Kapi-tel ber das ADO-Datensteuerelement (Kapitel 4) Codebeispiele mit denADO-Objekten vergleichend gegenberzustellen, die aber erst in Kapitel 5vorgestellt werden. Sowohl in Kapitel 4 als auch in Kapitel 5 finden Siekleine SQL-Beispiele, wobei SQL aber erst in Kapitel 7 eingefhrt wird.Diese Struktur geht konform mit dem Aufbau eines Internet-Dokuments,wo Sie ber Querverweise Ihre eigene Lesereihefolge bestimmen knnen.Whrend Sie im Internet nur mit der Maus klicken, mssen Sie bei diesemBuch ein wenig blttern. Der rote Faden ist jedoch klar: Mit jedem Ab-schnitt lernen Sie etwas mehr ber die Datenbankprogrammierung, so daSie am Ende des Buches mit allen wichtigen Aspekten vertraut sind.

Einleitung

23

Was lesen Sie in diesem Buch?In diesem Buch erhalten Sie einen berblick ber die Datenbankprogram-mierung mit Visual Basic und den Active Data Objects (ADO). DieseKenntnisse knnen Sie problemlos auch mit VBA und Office 97 bzw. vorallem Office 2000 einsetzen, wenngleich auf diesen Aspekt in diesem Buchnur am Rande eingegangen wird.

Kapitel 1: Das kleine Einmaleins der Visual-Basic-Datenbanken

Sie lernen in diesem Kapitel erst einmal die wichtigsten Grundbegriffe ausder Sicht eines Visual-Basic-Programmierers kennen und erfahren, welcheForm der Datenbankschnittstelle Microsoft fr Visual Basic 6.0 gewhlt hat.

Kapitel 2: Datenbankdesign fr Visual-Basic-Programmierer

Eine Datenbank besteht aus Tabellen, Feldern, Relationen, Abfragen,Schlsseln und einigem mehr. Wie diese Begriffe zusammenhngen, wirdam Beispiel der Buchdatenbank Fuhrpark.mdb erklrt.

Kapitel 3: Die erste Datenbank im Eigenbau

In diesem Kapitel legen Sie mit Hilfe des Visual Data Managers, einem klei-nen Visual-Basic-Hilfsprogramm, Ihre erste Datenbank an, die in den fol-genden Kapiteln als Grundlage fr alle Beispiele verwendet wird.

Kapitel 4: Das ADO-Datensteuerelement und die gebundenenSteuerelemente

In diesem Kapitel lernen Sie das ADO-Datensteuerelement und die gebun-denen Steuerelemente kennen, mit denen sich in wenigen Schritten Ein-gabemasken fr das Ansehen und Bearbeiten von Datenbankinhaltenerstellen lassen.

Kapitel 5: Die ADO-Objekte stellen sich vor

In diesem Kapitel geht es an den Kern der Datenbankprogrammierung mitVisual Basic. Sie lernen die Active Data Objects (ADO) im Detail kennen,auf denen die gesamte Datenbankprogrammierung basiert.

Kapitel 6: Der Datenumgebungsdesigner

Mit Hilfe des Datenumgebungsdesigners lassen sich Connection- undCommand-Objekte einmal anlegen, so da sie bei knftigen Projekten nurnoch in Form einer Designerdatei eingefgt werden mssen. Der Umgang

Einleitung

24

mit dem Datenumgebungsdesigner, eine der wichtigsten Neuerungen beiVisual Basic 6.0, steht in diesem Kapitel im Vordergrund.

Kapitel 7: Das ABC der Datenbanksprache SQL

In diesem Kapitel lernen Sie das ABC der Datenbanksprache SQL kennen.Die Beispiele werden auf die in Kapitel 3 vorgestellte Fuhrpark-Datenbankangewendet.

Kapitel 8: Der Umgang mit dem Recordset-Objekt

Im Mittelpunkt aller Datenbankzugriffe mit ADO steht das Recordset-Ob-jekt. Mchten Sie Datenstze lschen, aktualisieren oder nach ihnen su-chen? Das Recordset-Objekt ist der Schssel dazu.

Kapitel 9: Die Dateneingabe in der Praxis

Neben einer Datenbank und den ADO-Objekten mu eine Datenbankan-wendung auch Eingabedialogfelder enthalten. Dazu gehrt z.B. das Suchenin einer Datenbank, das mit Hilfe von Eingabeformularen und per SQLoder mit der Find-Methode des Recordset-Objekts Datenstze erledigtwird.

Kapitel 10: ADO fr (etwas) Fortgeschrittene

In diesem Kapitel geht es um die etwas fortgeschritteneren Themen derProgrammierung mit ADO. Dazu gehrt unter anderem das Einlesen einerDatensatzgruppe in ein Feld, das Abspeichern einer Datensatzgruppe oderdas Einlesen einer Tabellenstruktur.

Kapitel 11: Anfertigen von Datenbankreports

Irgendwann (meistens ziemlich schnell) mchte man die Daten nicht nur amBildschirm sehen, sondern Schwarz auf Wei in der Hand halten. Wie sichDatenbankreports sozusagen in Schnschrift mit dem Visual-Basic-Daten-bankreportmodul anfertigen lassen, verrt dieses Kapitel.

Kapitel 12: Eine Datenbankanwendung in derGesamtbersicht

Im letzten Kapitel des Buches wird die Fuhrpark-Anwendung, die sich wieein roter Faden durch das Buch zieht, noch einmal im Gesamtberblickvorgestellt. Dabei werden die einzelnen Schritte zusammengefat, die zumErstellen einer vollstndigen Datenbankanwendung notwendig sind.

Nicht weniger informativ sind wie immer die Anhnge.

Einleitung

25

Anhang A: Datenbanken von A bis Z

In der Datenbankprogrammierung wimmelt es von Abkrzungen und Be-griffen. In diesem Anhang finden Sie eine fast vollstndige bersicht.

Anhang B: ADO-Referenz

In diesem Anhang werden die ADO-Objekte mit ihren Eigenschaften, Me-thoden und Ereignissen zusammengefat.

Anhang C: Die Data Access Objects (DAO)

In diesem Anhang werden die Data Access Objects (DAOs) vorgestellt, diespeziell dem Zugriff auf die Jet-Engine und Access-Datenbanken dienen.Anhand kleiner Beispiele werden die wichtigsten Datenbankoperationenveranschaulicht. Auerdem finden Sie hier eine direkte Gegenberstellungzu den ADO-Objekten.

Anhang D: Die Antworten zu Fragen

Am Ende eines jeden Kapitels werden eine Reihe von leichten und wenigerleichten Fragen gestellt, deren Antworten Sie in diesem Anhang finden.

Anhang E: Weiterfhrende Informationen

Dieses Buch kann nur die Grundlagen behandeln. Wer tiefer in die Daten-bankprogrammierung mit Visual Basic, ADO oder SQL Server einsteigenwill, findet in diesem Anhang ein paar Tips zu weiterfhrender Literatur.

Welche Visual-Basic-Version wird vorausgesetzt?Dieses Buch setzt Visual Basic ab Version 6.0 voraus1. Die meisten Bei-spiele (aber nicht alle) lassen sich auch mit dem kostenlos erhltlichenAblaufmodell von Visual Basic 6.0 umsetzen2. Sie finden das Ablaufmodellbei verschiedenen Gelegenheiten (z.B. auf Zeitschriften-CDs), aber nicht alsDownload im Internet. Wer sich ernsthaft mit der Datenbankprogrammie-rung beschftigen mchte, sollte sich die Profi-Edition von Visual Basic 6.0zulegen. Die Enterprise-Edition ist nicht zwingend erforderlich, da die zu-stzlichen Features, wie etwa der SQL-Server 6.5, der T-SQL-Debuggerund andere Tools, fr das Lernen von Visual Basic und bei normalen Da-

1 Sollte es, wenn Sie dieses Buch lesen, bereits ein Visual Basic 7 geben, drfte esbezglich der elementaren ADO-Objekte und des Datenumgebungsdesigners keineUnterschiede geben.

2 Ich habe damit viele Beispielprogramme des Buches entwickelt.

Einleitung

26

tenbankanwendungen keine Rolle spielten drften. Wer nur Visual Basic5.0 besitzt, kann einen Teil der Beispiele umsetzen, mu dabei aber immerbedenken, da es den Datenumgebungsdesigner, der in vielen Beispielenvorausgesetzt wird, bei Version 5.0 nicht gibt. Wie sich der Datenumge-bungsdesigner durch entsprechende ADO-Befehle ersetzen lt, wird inKapitel 5 beschrieben. Visual Basic 5.0-Programmierer bentigen die ADO-Objekte, die sich im Rahmen des Microsoft Data Access Components-Pack (MSDAC) unter http://www.microsoft.com/data/mdac2.htm herunterladen lassen. (Laden Sie nicht das SDK, sondern lediglich das MicrosoftData Access Components 2.0 Typical Setup der genaue Wortlaut kannvariieren mit ca. 6 Mbyte Umfang herunter.) Wer noch unter Visual Basic5.0 programmiert und dennoch nicht auf ein ADO-Datensteuerelement ver-zichten mchte, kann es als Freeware von der Firma IsgSoft unterhttp://www.isgsoft.com/products/ISGData/ herunterladen. Eine Zusammen-stellung wichtiger Ressourcen fr angehende Datenbankprogrammiererfinden Sie in Anhang E.

Gibt es diesmal keine Buch-CD-ROM?Autor und Verlag haben sich entschlossen, diesem Buch keine CD-ROMbeizulegen, da es abgesehen von den relativ kleinen Beispielprogrammenund der Fuhrpark-Datenbank nicht allzu viel beizulegen gbe. Ich gehe da-von aus, da jeder Leser ber Visual Basic 6.0 (oder Version 5.0) verfgt.Die Beispielprogramme des Buches sind so gehalten, da sich durch dasAbtippen und Ausprobieren ein Lerneffekt ergibt, der gerade bei der Da-tenbankprogrammierung von groer Bedeutung ist. Auch die DatenbankFuhrpark.mdb, die in Kapitel 3 vorgestellt wird, sollten Sie Schritt frSchritt umsetzen und nicht einfach von einer CD-ROM kopieren (die in die-sem Fall nicht existiert). Wer sich diese Arbeit dennoch ersparen mchteoder partout nicht weiterkommt, kann sich die Datenbank Fuhrpark.mdbsowie einige der Beispielprogramme des Buches von meiner Webseite her-unterladen. Ich mchte jedoch an dieser Stelle jeden ermutigen, es zunchstauf eigene Faust zu probieren. Auch, wenn ein Beispiel auf Anhieb nichtfunktionieren sollte (das kommt schon einmal vor), der Lerneffekt ist einfachgrer.

Brauche ich einen Internet-Anschlu?Grundstzlich natrlich nicht, doch Sie werden schnell feststellen, da derInternet-Anschlu viele praktische Vorteile bietet. Sie knnen sich ber dieneuesten Entwicklungen bei Microsoft informieren, mit anderen EntwicklernTips und Erfahrungen in verschiedenen Newsgroups austauschen, die

Einleitung

27

Webseite des Autors besuchen und sich den Straenbahnfahrplan derFidschi-Inseln ausdrucken lassen. Selbst wer keinen Internet-Anschlu be-sitzt, kann in unzhligen Internet-Cafs (z.B. in einem Kaufhaus) etwa dieBeispielprogramme des Buches herunterladen oder mehr ber die ADO-Programmierung lesen. Ein Internet-Anschlu lohnt sich in jedem Fall undsollte fr Visual-Basic-Entwickler selbstverstndlich sein.

Kontakt mit dem AutorWie immer freue ich mich ber Zuschriften, Kommentare, Anregungen(darber besonders), aber natrlich auch ber Kritik, Hinweise auf Fehler,Geldspenden usw. Ich gehe davon aus, da nicht alles auf Anhieb klar seinwird und sich sicherlich auch das eine oder andere Fehlerchen eingeschli-chen haben wird. Aktuelle Fehlerkorrekturen sowie die Beispielprogrammeund die Datenbank des Buches finden Sie auf meiner Webseite mit derAdresse:

www.activetraining.de/jldb.htm

Die Endung jldb steht brigens fr Jetzt lerne ich Datenbankprogrammie-rung, was das Erinnern der URL ein wenig erleichtern drfte. Meine E-Mail-Adresse lautet:

[email protected]

Am Ende dieser Einleitung mchte ich Ihnen viel Spa und Erfolg beim Ein-stieg in die Datenbankprogrammierung mit Visual Basic und den ActiveData Objects (ADOs) wnschen. Es wird nicht immer ganz leicht sein, doches lohnt sich in jedem Fall, denn die Datenbankprogrammierung unter Vi-sual Basic bzw. Office wird auch im Jahr 2000 (also im nchsten Jahrtau-send) zu den mit Abstand wichtigsten Themen in der Windows-Welt geh-ren.

Viel Spa beim Entdecken der vielen Mglichkeiten wnscht Ihnen

Peter Monadjemi

29

1 Das kleine Einmaleins der Visual-Basic-Datenbanken

Wer sich mit dem Thema Datenbanken beschftigt, mu sich mit einerMenge Begriffe, Definitionen und Abkrzungen herumschlagen, die mei-stens nur indirekt etwas mit der Datenbank und ihren Daten, um die es sichletztendlich immer dreht, zu tun haben. Da gibt es Tabellen und Felder alsGrundelemente einer jeden Datenbank und Begriffe wie Relationen, Re-cordsets, Primrschlssel, referentielle Integritt (ein wahres Wortmonstrum,mit einer zum Glck recht einfachen Bedeutung) und eine schier unber-sehbare Vielfalt an Abkrzungen, wie ADO, DAO, ODBC, OLE DB, RDO,RDS, SQL usw. (dies wurde in der Einleitung bereits angedeutet). Als hoff-nungsfroher Visual-Basic-Programmierer, der eigentlich nur eines will, Da-ten in einer (Access-) Datenbank zu speichern und diese, wenn es erlaubtist, auch wieder abzurufen, ist man natrlich zunchst geplttet und mei-stens alles andere als erfreut. Es gibt aber keinen Grund zur Frustration,denn zum einen ist das meiste doch recht simpel, zum anderen darf mannicht erwarten, da sich ein Gebiet, das in den letzten drei Jahrzehntenimmerhin gut 80% der klassischen Datenverarbeitung ausgemacht hat undsicherlich auch 80% der heutigen Informationstechnik ausmacht, in weni-gen Stzen umfassend beschreiben und an einem Wochenende vollstndigerschlieen lt. Und auch, wenn es zu diesem Zeitpunkt eher ein wenigzynisch klingen mag: Als Visual-Basic-Programmierer darf man froh sein,da das Ganze noch relativ berschaubar geblieben ist. Denn wenn es SQLnicht gbe und Microsoft mit ODBC und jetzt mit OLE-DB/ADO keine ver-bindlichen Standards geschaffen htte, sehe die Angelegenheit vielleichtnoch sehr viel unbersichtlicher aus (sptestens am Ende dieses Kapitelswissen Sie, was es mit den drei Abkrzungen auf sich hat).

D as kleine Einmaleins der Visual-Basic-D atenbanken

Kap

itel

1

KAPITEL 1 Das kleine Einmaleins der Visual-Basic-Datenbanken

30

In diesem Kapitel lernen Sie das kleine Einmaleins der Datenbanken ken-nen, bezogen auf Visual Basic und die Microsoft-Welt1. Eine gewisseRedundanz lt sich leider nicht vermeiden. Sie werden einige der in diesemKapitel vorgestellten Begriffsdefinitionen im weiteren Verlauf des Buchesnoch einmal lesen. Das ist hoffentlich im Sinne der meisten Leser, denneinige Dinge kann man nicht oft genug wiederholen2.

Sie lernen in diesem Kapitel etwas ber die folgenden Themen:

Was ist eigentlich eine Datenbank?

Visual Basic und die Datenbanken

Die Rolle der Jet-Engine

Der Unterschied zwischen der Jet-Engine und Microsoft Access

ADO und DAO

Die wunderbare Genialitt von SQL

Die Rolle von ODBC

Lokale Datenbanken und Remote-Datenbanken

Das Client/Server-Prinzip

1.1 Was ist eigentlich eineD atenbank?

Eine Datenbank ist ein Ort, an dem Daten gespeichert werden. Woher derBegriff Datenbank stammt, lt sich offenbar nicht genau feststellen. Ver-mutlich ist es lediglich eine bersetzung des Originalbegriffs Database,wobei dazu gesagt werden mu, da, anders als viele andere Dinge, Daten-banken auch bei uns in Deutschland eine Tradition besitzen, die noch aufdie sechziger Jahre zurckgeht. (Es ist also nicht so, da Datenbanken beiuns erst mit Microsoft Access oder dBase einer PC-Datenbank der frhenachtziger Jahre populr wurden.) Wann die erste Datenbank ins Lebengerufen wurde, lt sich vermutlich nicht genau bestimmen. Ein markantesDatum in der Geschichte der Datenbanken drfte jene 11. Volkszhlung aus

1 Dieser Hinweis ist nicht unwichtig, da es natrlich nicht nur Microsoft gibt und andere

Datenbankfirmen, wie etwa Oracle, Informix, IBM oder Inprise (frher Borland),leistungsfhige Alternativen anbieten und dabei teilweise auch andere Namen undAbkrzungen verwenden.

2 Was natrlich kein Freischein des Autors fr endlose Wiederholungen und anderePlatitden sein soll.


31

dem Jahre 1890 in den USA gewesen sein (die sogenannte Inventur derAmerikaner), bei der zum ersten Mal die Daten aller Einwohner auf Loch-karten erfat wurden. Die Idee stammte von dem Amerikaner HermanHollerith (18601929), der 1884 ein Patent unter dem Namen Art ofCompiling Statistics fr sein Lochkartensystem anmeldete, das 1889 aucherteilt wurde. Bereits 1896 grndete der geschftstchtige Ingenieur die Ta-bulating Machine Company, aus der 1924 die International BusinessMachines Corporation hervorging, die den meisten eher unter dem KrzelIBM bekannt sein drfte. Der deutsche Ableger mit dem Namen DeutscheHollerith Maschinengesellschaft (Dehomag) ging 1949 in der IBM auf1.

Der Begriff Daten steht universell fr alles, das sich erfassen, kategori-sieren und damit auch (irgendwo) speichern lt. Ein Name, die Tempe-ratur des Badewassers, der Kurs einer Aktie, die Lautstrke einer Grilleoder der Fllstand eines Tanks sind Daten, die man erfassen (also ir-gendwo aufschreiben), einordnen (d.h. einer bestimmten Kategorie zu-ordnen) und abspeichern kann. Werden die Daten systematisch erfat,entsteht eine Datenbank. Werden die Daten nach verschiedenen Ge-sichtspunkten neu zusammengestellt, spricht man von Datenverarbei-tung (DV).

So innovativ und umwlzend Herman Holleriths Idee am Ende des 19.Jahrhunderts auch war, die erfaten Daten muten damals mechanisch er-fat und auf Papier gespeichert werden, was den Zugriff auf die Daten deut-lich einschrnkte. Eine elektronische Erfassung wurde erst mit dem Auf-kommen der Rechenanlagen in den fnfziger Jahren mglich, wobei derkommerzielle Einsatz der Grorechner erst in den sechziger Jahren begann.

Ein weiteres markantes Datum in der Geschichte der Datenbanken sind dieArbeiten der amerikanischen Mathematiker C. Date und E.F. Codd2, dieAnfang der 70er Jahre zum relationalen Modell der Datenbanken und zurDatenbanksprache SQL fhrten. Wenngleich dies auch schon wieder 30Jahre zurckliegt, sind die damals entworfenen Grundregeln fr die Organi-sation einer Datenbank gem dem relationalen Modell und die Abfrageund Manipulation per SQL auch heute noch topaktuell. Sie werden im wei-teren Verlauf des Buches im Zusammenhang mit einer kleinen Access-Da-tenbank angewendet.

1 Alles wunderschn nachzulesen in dem Buch Informationen, Daten und Signale von

Rolf Oberliesen (rororo Sachbuch Nr. 7709), das es unter Umstnden noch imSouvenierladen des Deutschen Museums in Mnchen zu kaufen gibt.

2 Wer hat gesagt, da die Dinge einfach sein mssen?


32

1.1.1 D ie Zukunft der D atenbanken: OLAP(?)Auch wenn die theoretischen Grundlagen fr das, was Sie whrend dernchsten 300 Seiten beschftigen wird, bereits etwas lter sind, hat es na-trlich auch in den achtziger und neunziger Jahren wichtige Fortschritte imBereich der Datenbanktechnologien gegeben (Stichwort: Verteilte und ob-jektorientierte Datenbanken oder der 1992 verabschiedete ANSI 92-SQL-Standard). Dennoch hat keine dieser Entwicklungen den Datenbankbereichso grundlegend prgen knnen, wie es mit dem relationalen Modell undSQL der Fall war. Das knnte sich allerdings in den nchsten Jahren(endlich) wieder ndern. Unter den Stichworten Knowledge Management,Data Warehousing und vor allem On-Line Analytical Processing, kurzOLAP, werden neue Verfahren beschrieben, nach denen verknpfte Tabel-len multidimensional in Form von (unsichtbaren, also nur logisch existieren-den) Wrfeln dargestellt werden. Auf diese Weise lassen sich die Daten un-ter Gesichtspunkten auswerten, die mit dem relationalen Modell alleinenicht oder nur aufwendig mglich wren. OLAP, dem eine groe Zukunftvorausgesagt wird, ist bereits Realitt, da unter anderem der Microsoft SQLServer 7.0 in Form seiner OLAP Services und in Verbindung mit ADO, daseinen speziellen OLE DB Provider fr OLAP zur Verfgung stellt, eineMglichkeit bietet, Datenbankdaten in Form eines multidimensionalen Wr-fels zu analysieren.

Der Begriff Information steht fr Daten, die sich in einem bestimmtenKontext befinden. Die Zahl 23 kann alles bedeuten, wird sie dagegen imKontext einer Temperaturangabe genannt, erhlt sie nicht nur eine be-stimmte Bedeutung, sondern auch eine Reihe kontextabhngiger Impli-kationen. Steht sie im Zusammenhang mit der Lufttemperatur, impli-ziert sie z.B. den Zustand angenehm, steht sie dagegen im Zusam-menhang mit dem Inhalt einer Badewanne, impliziert sie den Zustandeindeutig zu kalt. In den letzten Jahren fand ein bergang von derreinen Datenverarbeitung (DV) zur Informationsverarbeitung (IT) statt,bei der es nicht mehr alleine um das Erfassen, Abspeichern und Aus-werten von Daten, sondern in zunehmenden Mae auch um die Inter-pretation dieser Daten geht.

Anwendungen fr OLAP gibt es mehr, als Sie wahrscheinlich zunchst ver-muten wrden. Allerdings lohnt sich der Aufwand nur dann, wenn groeDatenmengen im Spiel sind, aus denen in krzester Zeit neue Erkenntnissegewonnen werden sollen. Ein Beispiel von vielen sind jene Einzelhndler,bei denen ein groer Teil der Kundschaft bereits mit der EC-Karte bezahltund so (oft ohne es zu wissen) mit jeder Transaktion neben dem Verkaufsda-


33

tum auch Anschriftendaten hinterlt. Zusammen mit mikrodemoskopi-schen Daten (etwa dem Kaufkraftquotienten fr eine bestimmte Region) sitztder Einzelhndler auf einer wahren Daten-Schatztruhe, die er nur nochmit dem passenden Schlssel ffnen mu. Wieviel Prozent der ber dieletzte Zeitungsbeilage angesprochenen Kunden waren innerhalb der darauf-folgenden Tage in meinem Laden und haben fr mehr als 100 DM etwasgekauft? Wie anziehend ist ein Sonderangebot auf eine bestimmte Re-gion? Wo werden die meisten Shorts im Winter verkauft? Fragen berFragen, die sich mit einfachem SQL nicht oder nur mit groem Aufwandbeantworten lassen. OLAP, das, sowohl als Endanwenderwerkzeug als auchin Form programmierbarer Objekte, fester Bestandteil von Excel 2000 ist,knnte hier eine Antwort bieten.

Das ist fr Sie als angehender Datenbankprogrammierer allerdings im Mo-ment nichts mehr als ein Ausblick in eine ferne Zukunft. Am Ende des Bu-ches sollen Sie in erster Linie Access-Datenbanken ansprechen, Tabellenffnen, mit Recordset-Objekten umgehen und einfache SQL-Abfragen for-mulieren knnen, nicht aber die Kaufkraft der Region auf zwei Stellen nachdem Komma analysieren. In diesem Kapitel geht es um sehr viel elementa-rere Fragen. Die wichtigste Frage, nmlich was ist eine Datenbank, wurdenoch nicht vollstndig beantwortet.

1.1.2 D atenbank = Tabelle + D atenstze + FelderSie wissen bereits, da eine Datenbank ein Ort ist, an dem Daten aufbe-wahrt werden (wie dieser Ort physikalisch aussieht, wird in Kapitel 2 er-klrt). Allerdings sind diese Daten nicht bunt durcheinander gewrfelt, son-dern auf verschiedene Behlter verteilt, die als Tabellen bezeichnet wer-den. Jeder dieser Behlter besitzt eine feste Anzahl an Unterteilungen, dieman sich als kleine Schubladen vorstellen kann. Eine solche Schublade wirdauch als Feld bezeichnet. In jede Schublade kann genau ein Datum1, etwaein Name oder eine Zahl, abgelegt werden. Mchte man etwa den Namen,das Geburtsdatum und das Lieblingsgetrnk einer Person speichern, werdendafr drei Schubladen (Felder) bentigt. Eine Schublade fr den Namen,eine weitere Schublade fr das Geburtsdatum und schlielich eine dritteSchublade fr den Namen des Getrnks. Alle Schubladen (Felder) zusam-men bilden einen Datensatz. In jedem Datensatz lt sich (bezogen auf dasBeispiel) genau ein Name, ein Geburtsdatum und ein Getrnkename spei-chern. Mchte man weitere Personendaten speichern, so wird einfach eineneue Reihe bestehend aus drei Schubladen, also ein Datensatz, hinzugefgt.

1 Die Einzahl von Daten.


34

Eine Datenbank besteht aus einer oder mehreren Tabellen. Jede Tabelleenthlt keinen, einen oder mehrere Datenstze. Jeder Datensatz bestehtaus einer festen Anzahl von Feldern. Alle Datenstze der gleichen Ta-belle weisen die gleiche Anordnung an Feldern auf. Jedes Feld enthltgenau ein Datenelement.

Gem dieser Definition ist eine Datenbank mit einem Karteikasten ver-gleichbar, in dem auf den einzelnen Krtchen die Namen und Adressen vonPersonen aufgefhrt sind. Der gesamte Karteikasten ist die Datenbank. EineUnterteilung (etwa in private und geschftliche Adressen) entspricht einerTabelle. Jede Tabelle enthlt ein oder mehrere Krtchen, die als Datenstzebezeichnet werden. Anders als im richtigen Leben mu es auf jeder Kartei-karte einer Tabelle die gleiche Unterteilung geben. Jemand, der seine Auf-gabe sehr genau nimmt, wrde daher, fein suberlich mit Bleistift und Li-neal, auf jeder Karte die gleiche Anzahl an Unterteilungen eintragen, wobeijede Unterteilung, die in diesem Zusammenhang als Feld bezeichnet wird,den gleichen Typ von Daten enthlt. Weder fr die Anzahl der Unterteilun-gen noch fr die Anzahl der Karteikarten gibt es eine Grenze. Wer einenschnell wachsenden Freundeskreis oder aus geschftlichen Grnden einenschnell wachsenden Kundenkreis besitzt (erfahrungsgem geht im richtigenLeben manchmal das eine mit dem anderen einher), schafft einfach neue

Bild 1.1:Eine Daten-

bank bestehtaus Tabellen,Datenstzenund Feldern


35

Karteikarten oder neue Ksten an. Dem Wachstum der Datenbank sindrein physikalisch keine Grenzen gesetzt.

1.1.3 Wie wird aus D aten eine D atenbank?Eine Antwort auf diese wichtige Frage kann im Moment nur angedeutetwerden, da Sie die wichtigsten Regeln zur Umsetzung einer Datenbank erstin Kapitel 2 und 3 kennenlernen werden. Sie haben die Daten, wie wirddaraus eine Datenbank? Der erste Schritt ist das Eingeben der Daten inelektronischer Form, so da sie auf einem Datentrger, wie einer Festplatte,gehalten werden knnen. Das ist einfacher, als Sie es vielleicht vermuten.Windows verfgt, wie jedes Betriebssystem, ber das denkbar einfachsteDatenerfassungsprogramm, den Editor. Starten Sie also Notepad (denWindows-Editor), und geben Sie Ihre Daten Datensatz fr Datensatz ein.Die einzige Bedingung ist, da Sie die Daten in Form von Datenstzen ein-geben. Das bedeutet konkret, da die erste Zeile die Namen der einzelnenFelder enthlt. Also zum Beispiel:

Name, Geburtstag, Lieblingsgetrnk

Nun folgen Zeile fr Zeile die einzelnen Datenstze, wobei Sie stets die glei-che Reihenfolge einhalten und die einzelnen Felder durch ein Trennzeichen,z.B. ein Semikolon, trennen mssen. Also zum Beispiel:

Jean Paul, 3.3.49, RotweinBill G., 28.10.56, Pespi LightBruno, 7.2.65, Jolt-ColaPeter, 25.10.63, Bier

Bild 1.2:Die gute alteKarteikarteentsprichteinem einzel-nen Datensatz,wo jeder Ein-trag in einerSpalte ein Felddarstellt


36

Speichern Sie das Ganze nun in einer Textdatei ab fertig ist die Daten-bank. Da es sich dabei tatschlich um eine (Pseudo-)Datenbank handelt,wird deutlich, wenn Sie die Schrittfolge in Kapitel 10 (Datenbankzugriff aufeine Textdatei) durchfhren, durch die Sie jede (tabellarisch aufgebaute)Textdatei wie eine Datenbank ansprechen knnen. Natrlich ist dies nochkeine echte Datenbank, da wichtige Merkmale fehlen, doch erfllt auch eineTextdatei die eingangs getroffene Definition. Mit der wichtigen Ausnahme,da jede Textdatei fr eine Tabelle steht. Soll die Datenbank aus mehrerenTabellen bestehen, mssen alle Textdateien in einem Verzeichnis unterge-bracht werden. In diesem Fall spielt das Verzeichnis die Rolle der Daten-bank, die aus mehreren Tabellen besteht.

Na wunderbar, warum sind wir dann nicht einfach beim Karteikartensystemgeblieben? Statt dessen mssen wir viel Geld (demnchst in Euro) ausgeben,um genau das zu haben, was unsere Vorfahren scheinbar mit etwas Klein-geld und sehr viel weniger Stre schon hatten.

Nun, dieser Vergleich ist nur scheinbar so attraktiv. Ein Karteikasten ist zwarals Datenhalde prinzipiell geeignet, versagt jedoch, wenn es um das Ab-fragen der Daten geht. Stellen Sie sich nur vor, wie lange es dauern wrde,in einer Kartei mit 1000 Freunden nur alle jene herauszusuchen, die seitmehr als fnf Jahren nichts mehr von sich hren lassen haben. Was nachdem guten alten System einen Nachmittag in Anspruch nehmen wrde,

Bild 1.3:Der Inhalt

einer Daten-bank einmal

vom Editor ...

Bild 1.4:... und einmal

durch Micro-soft Accessdargestellt


37

lt sich mit einer elektronischen Datenbank im Bruchteil einer Sekundeerledigen. Wenn Sie jedoch noch feststellen mchten, ob zwischen IhremVersenden von Weihnachtskarten (ber das Sie ebenfalls Buch gefhrthaben) und der Kontaktfreudigkeit Ihrer Freunde ein Zusammenhangbesteht, so lt sich dieser (etwa mit dem neuen OLAP) in wenigen Sekun-den erkennen, whrend die traditionelle Methode vermutlich im Ansatzscheitern wrde.

Das soll nicht heien, da Karteikarten (oder Aktenordner) als Datenme-dium prinzipiell untauglich wren. Sie bieten einfach nicht mehr die erfor-derliche Flexibilitt1. Ein wenig anders sieht es aus, wenn Sie Ihre Karteikar-ten mit dem unter Windows 3.1 damals populren Karteimanager verwal-ten. Da dieser seine Daten in tabellarischer Textform speichert, ist es keingroer Aufwand, in Visual Basic einen OLE DB-Provider zu programmie-ren, so da die Cardfile-Datenbank, etwa per SQL, wie eine richtige Da-tenbank angesprochen werden kann. Mglich ist dank der Flexibilitt vonOLE DB und ADO praktisch alles. Voraussetzung ist natrlich, da die Da-ten in elektronischer Form vorliegen.

Halten wir fest: Eine Datenbank ist ein Ort, an dem Daten in tabellarischerForm gespeichert werden. Jede Tabelle enthlt Datenstze, ein Datensatzbesteht aus einer bestimmten Anzahl an Feldern. Ein Datensatz ist damiteine Informationseinheit innerhalb einer Datenbank. Vergleicht man eineDatenbank mit einem Karteikasten, so entspricht ein Datensatz einer Kar-teikarte. Die Informationen in einem Datensatz sind nochmals in soge-nannte Felder unterteilt. Bei einer Adredatenbank mit einer Tabelle kn-nen in einem Datensatz z.B. die Felder Nachname, Vorname, Strae,Hausnummer, Postleitzahl, Ort und Telefonnummer existieren.

1.1.4 D atenbanken eine technische D efinitionMit dieser hoffentlich recht einfachen Definition kann man es fr den An-fang bewenden lassen. Wer mehr ber das Wesen der Datenbanken verste-hen will, mu ein wenig tiefer einsteigen. Ein kurzer Abstecher in die Infor-matikvorlesung 1. Semester erffnet tiefergehende Einblicke. Zu den wich-tigsten Merkmalen einer Datenbank gehren:

Strukturierung der Daten

Trennung von Daten und Anwendung

1 Auf meinen Schreibtisch steht nach wie vor ein File-O-Flex mit kleinen Krtchen. Ein

Personal Organizer hat sich noch nicht durchsetzen knnen.


38

Der erste Punkt ist schnell erklrt. Eine Datenbank dient der Strukturierungvon Daten (wie Sie bereits wissen in Tabellen, Datenstze und Felder). Auchder zweite Punkt ist im Prinzip selbstverstndlich. Die Daten werden in einerDatenbank und nicht im Programmtext gespeichert Anwendung und Da-ten sind voneinander unabhngig. Damit ergeben sich eine Reihe weitererMerkmale:

Datenunabhngigkeit

Integritt, d.h. Konsistenz, zum Beispiel eine automatische Validierung(Kontrolle) eingegebener Daten

Datensicherung

Datenschutz

Zeitliche Permanenz (Daten werden durch die Datenbank gespeichert)

Spezifische Benutzersichten (der Benutzer kann festlegen, auf welcheWeise die Daten prsentiert werden sollen)

Die ersten beiden Punkte erscheinen als selbstverstndlich, denn der Aufbaueiner Datenbank ist unabhngig von den Daten, die darin gespeichert wer-den, da sich prinzipiell smtliche Daten speichern lassen sollten. Datenban-ken sollten fr ihre eigene Konsistenz sorgen, das heit verhindern, da einAnwender unsinnige Daten eingeben oder einen Datensatz in der Stamm-datentabelle lschen kann, auf den in anderen Datenstzen verwiesen wird.Datensicherung und Datenschutz sind ebenfalls wichtige Bereiche, wobeizumindest Microsoft Access den ersten Punkt dem Anwender berlt undbeim zweiten Punkt nicht gerade brilliert. Zeitliche Permanenz bedeutetnichts anderes, als da sich die Datenbank um das Abspeichern der einge-gebenen Daten kmmert. Auch die spezifischen Benutzersichten sind jedemAccess-Anwender bestens vertraut. Es bedeutet, da sich der Anwenderverschiedene Ansichten entwerfen kann, die festlegen, auf welche Weiseder Inhalt einer oder mehrerer Tabellen zurckgegeben (also angezeigt)wird. Mchte ein Anwender von den Auftrgen in der Auftragstabelle nurdie Betrge sehen oder gleich die Namen und den Kontostand (bezogen aufdie bisher gettigten Bestellungen) der Auftraggeber? Diese Informationmag nicht direkt in der Datenbank enthalten sein, doch durch Zusammen-stellen einer Ansicht tut die Datenbank so, als stammen alle Daten aus einerTabelle.

Visual Basic und die Datenbanken

39

1.2 Visual Basic und dieD atenbanken

Von der Welt der abstrakten Begriffe und Definitionen geht es nun in jeneWelt zurck, der wir gerne einen Teil unserer kostbaren Frei- und Arbeitszeitwidmen, der Visual-Basic-Programmierung. Der Zugriff auf Datenbankenspielt bei der Visual-Basic-Programmierung eine sehr wichtige Rolle. DochVisual Basic, genauer gesagt VBA (die Programmiersprache von VisualBasic), enthlt keinen einzigen Datenzugriffsbefehl1 und ist daher vonHaus alleine nicht in der Lage, auf eine Datenbank zuzugreifen. Fr den Da-tenzugriff benutzt Visual Basic vielmehr ein allgemeines Prinzip, das grund-stzlich immer dann zur Anwendung kommt, wenn ein Visual-Basic-Pro-gramm auf Funktionen zugreifen soll, die sich in anderen Programmen,DLLs oder Systemdateien mit einer sogenannten COM-Schnittstelle befin-den: Die Einbindung einer Objektbibliothek, die die Namen von Objektenund deren Eigenschaften, Methoden und Ereignisse enthlt. ber den Men-befehl PROJEKT/VERWEISE wird durch die Auswahl der entsprechendenObjektbibliothek die Verbindung zwischen dem Visual-Basic-Programm undeiner Datenbankschnittstelle hergestellt. Letztere enthlt eine Reihe allge-meiner (Datenbank-)Objekte, mit denen z.B. Datenbankabfragen durchge-fhrt werden.

VBA enthlt keine eingebauten Datenbankbefehle. Der Zugriff aufeine Datenbank (bzw. eine Datenquelle) wird ber eine Objektbibliothekhergestellt, die ber den Menbefehl PROJEKT/VERWEISE in ein Projekteingebunden wird.

Grundlage fr den Datenbankzugriff ist das Component Object Modell(COM), das als eine Systemerweiterung von Windows unter anderem da-fr sorgt, da sich zwei Objekte in einer Anwendung ber Eigenschaf-ten, Methoden und Namen ansprechen knnen.

1 Von den netten Oldtimer-Befehlen Open, Close, Get und Put einmal abgesehen

mehr dazu am Ende des Kapitels.


40

Um ein VBA-Projekt datenbankfhig zu machen, gehen Sie stets wie folgtvor. Sie ffnen das PROJEKT-Men, whlen den Eintrag VERWEISE und wh-len jene Objektbibliothek aus, ber deren Objekte der Zugriff auf die Daten-bank durchgefhrt werden soll. Wie Sie im weiteren Verlauf dieses Kapitelsnoch erfahren werden, gibt es dafr zwei Alternativen:

Die Microsoft ActiveX Data Objects Library 2.0

Die Microsoft DAO Object Library 3.51

Was es damit auf sich hat und welche Unterschiede zwischen beiden Ob-jektbibliotheken bestehen, wird noch ausfhrlich errtert. Zunchst mu dieRolle des Datenbank-Management-Systems geklrt werden.

1.3 D as D atenbank-Management-System

Eine Datenbank ist letztendlich nichts anderes als eine Ansammlung vonDaten in einer einzelnen Datei oder einer eigens dafr vorgesehenen Struk-tur auf der Festplatte. Eine Programmiersprache, wie VBA, greift auf dieseDaten ber Objekte zu. Doch diese Objekte fhren nicht den eigentlichenDatenbankzugriff durch. Sie sind lediglich Vermittler zwischen dem Pro-gramm und dem Datenbank-Management-System, dessen Aufgabe dieVerwaltung der Datenbank ist. Der Begriff Datenbank-Management-System(kurz DBMS, wenngleich diese Abkrzung in der Welt der PC-Datenbankennur selten verwendet wird) darf nicht zuviel implizieren. Es kann eine gigan-tisch groe (und entsprechend teure) Software sein, es kann aber auch einMiniprogramm sein, das auf eine einzelne HD-Diskette pat. Allen DBMSist gemeinsam, da sie folgende Grundttigkeiten ausfhren knnen:

Bild 1.5:Erst durchEinbinden

einer Referenzauf eine

Objektbiblio-thek wird

Visual Basicdatenbank-

fhig

Die Rolle der Jet-Engine

41

Das Erstellen von Datenbanken und das Hinzufgen von Tabellen undFeldern

Das Erstellen von Abfragen mit einer Abfragesprache (in der Regel perSQL)

Administrative Aufgaben, wie das Komprimieren der Datenbank oderdas Exportieren bzw. Importieren von Daten

Visual Basic ist (anders als z.B. Microsoft Access) kein vollstndiges DBMS.Es ist lediglich in der Lage, mit Hilfe von Objektbibliotheken ber ein (imPrinzip beliebiges) DBMS auf Datenbanken zuzugreifen und die oben be-schriebenen Ttigkeiten mit Hilfe des DBMS auszufhren. Da die Daten-bankprogrammierung bei Visual Basic einen hohen Stellenwert besitzt, wirdVisual Basic seit der Version 3.0 mit einem DBMS ausgeliefert. Es ist dieJet-Engine, die auch von Microsoft Access verwendet wird und im nchstenAbschnitt besprochen wird. Darber hinaus bietet seit der Version 5.0 dieEnterprise Edition von Visual Basic mit dem Microsoft SQL-Server ein wei-teres, beraus leistungsstarkes DBMS an.

Gehorcht ein DBMS den allgemeinen Regeln relationaler Datenbanken(mehr dazu in Kapitel 2), wird es auch als RDBMS (Relationales DBMS) be-zeichnet. Das ist allerdings nur eine allgemeine Klassifizierung und keinQualittsmerkmal. Microsoft Access untersttzt zwar das relationale Daten-bankmodell, ist aber dennoch ein typisches RDBMS, da es z.B. Daten-banken in Dateien speichert.

Sie wissen nun, was eine Datenbank ist, welche Rolle das DBMS ber-nimmt und wie man prinzipiell von einem Visual-Basic-Programm ber Ob-jektschnittstellen auf ein DBMS und damit auf eine Datenbank zugreift. Imnchsten Abschnitt wird mit der Jet-Engine das wichtigste DBMS fr Visual-Basic-Programmierer vorgestellt.

1.4 D ie Rolle der Jet-EngineDer Begriff Jet-Engine ist erfahrungsgem nicht allen Visual-Basic-Pro-grammierern gelufig. Hufig werden die Begriffe Jet-Engine, MicrosoftAccess und Access-Datenbank auch synonym verwendet, was streng ge-nommen nicht korrekt ist und daher bei der Frage, welche Form der Da-tenbankuntersttzung Visual Basic bietet, nicht selten Verwirrung stiftet.Microsoft Access ist eine (Bro-)Anwendung, genau wie Visual Basic und


42

Microsoft Word. Was ist allen drei Anwendungen gemeinsam? Sie werdenmit ein und demselben Datenbank-Management-System (DBMS) ausgelie-fert. Dieses DBMS heit Jet-Engine. Die Jet-Engine ist kein ausfhrbaresProgramm, sondern liegt in Gestalt mehrerer Systemdateien vor (Sie kn-nen sie daher nicht aufrufen). Diese Systemdateien (DLLs) knnen ber ihreObjektschnittstelle DAO, ber ODBC und jngst ber OLE DB und ADOvon vielen Programmen aus angesprochen werden von Visual Basic(VBA), von Java wie von VBScript. Microsoft Access ist lediglich der ber-aus komfortable Rahmen, in dem sich Jet bedienen lt und mit dem sichAnwendungen auf der Basis von Jet aufbauen lassen. Da Microsoft Accessund die Jet-Engine eng miteinander verflochten sind, ist es fr einen An-wender praktisch unmglich, eine Trennlinie zu ziehen (aus der Sicht einesAnwenders ist dies auch gar nicht erforderlich). Auch fr Programmiererergibt sich diese erst bei nherer Betrachtung. Deutlicher wird der Unter-schied bei Microsoft Access 2000, wo die Anwender auswhlen knnen, obeine neue anlegte Datenbank auf der Jet-Engine (die in der Version 4.0 vor-liegt) oder der neuen Microsoft Desktop Engine (MDE), der Desktop-Versiondes Microsoft SQL-Servers 7.0, basieren soll.

Die Jet-Engine ist ein kleines, aber sehr leistungsfhiges DBMS. Aller-dings ist es keine eigenstndige Anwendung. Um auf die Jet-Engine zu-zugreifen, werden z.B. Microsoft Access, der Visual Data Manager vonVisual Basic (siehe Kapitel 3) oder ein Visual-Basic-Programm bentigt.

Die Jet-Engine untersttzt gleiche mehrere Datenbankformate, wobei dasDatenbankformat die Art und Weise beschreibt, wie die Daten in der zu-grundeliegenden Datei organisiert werden:

Das eigene Format (auch Access- oder Mdb-Format genannt)

Verschiedene ISAM-Formate (z.B. dBase, Paradox, FoxPro usw.)

ODBC-Datenbankformate

Das mit Abstand wichtigste Format ist das Access-Format. Hier liegt dieDatenbank im gleichen Format vor (zu erkennen an der typischen Erweite-rung .Mdb), das auch von Microsoft Access verwendet wird1.

1 Wenn Sie ber die Frage grbeln, was es eher gab: Die Jet-Engine wurde fr Microsoft

Access 1.0 entwickelt, gleichzeitig aber so konzipiert, da sie auch von anderenProdukten genutzt werden kann. Ein Henne-und-Ei-Problem gibt es hier nicht.

Allgemeines zu den Objekten

43

1.5 Allgemeines zu den ObjektenSie werden in diesem Buch eine Menge ber Objekte lesen. Als erfahrenerVisual-Basic-Programmierer ist Ihnen das alles natrlich vertraut, denn beiVisual Basic sind von Anfang an Objekte in Form von Steuerelementen,Formularen, dem Clipboard-Objekt und natrlich in Form von Klassen imSpiel. Ein Objekt ist, das noch einmal zur Wiederholung, ein Programm-name, der ber Eigenschaften und Methoden angesprochen wird und in ei-nigen Fllen auch auf Ereignisse reagieren kann.

Beim Datenbankzugriff stehen die Objekte im Mittelpunkt. Microsoft hatsich dafr entschieden, smtliche Datenbankzugriffe ausschlielich berObjekte regeln zu lassen. VBA besitzt, wie Sie bereits erfahren haben, kei-nen einzigen Datenbankbefehl. Die Datenbankobjekte werden in der Ent-wicklungsumgebung ber PROJEKT/VERWEISE einem Projekt hinzugefgtund stehen anschlieend zur Verfgung, als wren sie schon immer Teil vonVBA gewesen. Allerdings heien die Datenbankobjekte nicht etwa VBAData Objects, sondern Active Data Objects (ADO), Remote Data Objects(RDO) und Data Access Objects (DAO). Weitere Objektschnittstellen gibt esbrigens nicht, so da Sie nicht befrchten mssen, mit weiteren Krzelnkonfrontiert zu werden (zumindest nicht was die Datenbankobjekte angeht).

In diesem Buch finden Sie an vielen Stellen den Begriff ADO-Objekte(eigentlich mte es ja AD-Objekte heien, weil das O natrlich frObjects steht, doch hat sich diese Kurzschreibweise nicht eingebrgert).

Wie in der Einleitung schon dargestellt wurde, bespricht dieses Buch nichtdie DAOs (oder die RDOs). Im Mittelpunkt stehen die ADOs. Dahinter ver-bergen sich sieben Objekte (in der Version 2.1 in Zukunft knnen es mehrwerden), die fr den Zugriff auf eine Datenquelle benutzt werden mssen.Welche Objekte dies sind, wird in Kapitel 5 ausfhrlich erlutert. Sie solltensich den Begriff ADO-Objekte aber jetzt schon merken und wann immer Sieihn lesen oder hren an diese sieben Objekte und ihre spezifischen Eigen-schaften, Methoden und auch Ereignisse denken. Das ist der Kernpunkt beider Datenbankprogrammierung mit Visual Basic, Microsoft Office usw.

Entsprechend steht auch der Begriff DAO-Objekte fr verschiedene Ob-jekte, die fr den Datenbankzugriff verwendet werden knnen. Sie tragenallerdings andere Namen und besitzen eine andere Bedeutung. Eine kurzeGegenberstellung ADO-DAO finden Sie im Anhang C.


44

Erschrecken Sie bitte nicht angesichts von Begriffen wie ADO-Objekte,Objektmodell, Objektschnittstelle usw. Hinter all diesen Begriffen steht einsimples Prinzip. Da die Begriffe absolut essentiell fr die Datenbankpro-grammierung sind1, sollten Sie sich mit ihnen mglichst schnell anfreunden.

1.6 AD O oder D AO?Keine Sorge, in die Zwischenberschrift hat sich kein tckischer Buchsta-bendreher eingeschlichen, es erwartet Sie auch kein Ratespielchen mitzweifelhaftem Hauptgewinn. Es geht vielmehr um die Rolle der zwei wich-tigsten Datenbankschnittstellen fr den Zugriff auf die Jet-Engine im speziel-len und alle brigen Datenbanken im allgemeinen. Wie es in der Einleitungschon beschrieben wurde, gab es bis Visual Basic 5.0 nur DAO. Mit VisualBasic 6.0 wurde als Alternative ADO eingefhrt (wenngleich ADO unab-hngig von Visual Basic ist). Fr jemanden, der gerade erst mit der Daten-bankprogrammierung beginnt, ist es wie mit den meisten jungen Leuten,die nach der Wiedervereinigung geboren wurden. Fr sie ist das KrzelDDR nur ein mehr oder weniger umfangreicher Teil der Geschichtsbcher,zu dem sie vermutlich keinerlei persnlichen Bezug entwickeln werden.hnlich ist es mit DAO, dem in ein paar Jahren vermutlich nur eine freund-liche Funote in den Datenbankprogrammierbchern zuteil werden wird.ADO ist die Zukunft, und das ist (bis auf einige Ausnahmen) auch gut so.Anders sieht es fr die Visual-Basic-Programmierer aus, die bereits mehroder weniger umfangreiche Programme auf der Basis von DAO entwickelthaben. Sie werden ihre Programme zwar auch in Zukunft ausfhren undpflegen knnen, mssen aber mittelfristig auf ADO umlernen. Allerdings,und das werden Sie auch noch fter lesen, ist es kein Problem, ADO undDAO in einem Programm gemeinsam zu benutzen. Es ist also denkbar, einProgramm schrittweise auf ADO umzustellen.

1.7 D ie wunderbare Genialitt vonSQL

Es gibt Erfindungen, die sind so genial, da man sich kaum noch vorstellen,wie das Leben ohne sie aussehen wrde. Das Telefon fllt in diese Katego-rie, der Verbrennungsmotor, das Fernsehen sicher auch und mit Penicillinund dem Pizzaservice liee sich die Liste noch viel weiter fortfhren. In derWelt der DV ist die Structured Query Language (zu deutsch strukturierte

1 Ich hoffe, dies ist die korrekte Steigerungsform.

Die wunderbare Genialitt von SQL

45

Abfragesprache, meistens aber ausgesprochen wie ciehquell oder kurzSQL) eine solche geniale Erfindung. Genial deswegen, weil SQL genau dasrichtige Werkzeug fr den sehr wichtigen und praktisch allgegenwrtigenZweck der Daten(bank)abfrage ist, weil es zum richtigen Zeitpunkt kam(nmlich so frh, da es nicht in die Machtspielchen der groen Software-Firmen geraten konnte) und weil es von jedem vorbehaltlos akzeptiert wird(was nicht heien soll, da es nicht verbesserungswrdig ist)1.

SQL ist keine Programmiersprache, sondern eine Beschreibungssprache.Anstatt genau festzulegen, wie eine Datenbank geffnet und ihr Inhalt aus-gewertet werden soll, sagt man per SQL nur, welche Daten man erhaltenoder welche Daten auf welche Weise verndert werden sollen. Um das ge-naue Wie und Wo kmmert sich das DBMS. SQL besteht aus Kommandos,Funktionen und Operatoren. Das vermutlich einfachste SQL-Kommandosieht wie folgt aus:

SELECT * FROM Authors

Dieses SQL-Kommando gibt alle Datenstze der Tabelle Authors zurck.Mchte man lediglich die Namen aller Autoren sehen, die mit dem Buch-staben S beginnen, mu das SELECT-Kommando ein wenig erweitert wer-den:

SELECT Author FROM Authors Where Author Like 'S*'

Auf diese Weise lt sich sehr genau angeben, nach welchen Kriterien dieDatenbank durchsucht werden soll, wobei es natrlich auch mglich ist, ver-schiedene Tabellen oder gar verschiedene Datenbanken in die Suche einzu-beziehen. Machen Sie sich im Moment noch keine Gedanken, auf welcheWeise SQL und VBA zusammenspielen und wie z.B. Datenstze an einProgramm zurckgegeben werden. Sptestens in Kapitel 7 wird diese An-gelegenheit ausfhrlich besprochen.

SQL besitzt nicht nur Kommandos zur Datenmanipulation (diese Komman-dos bilden die Data Manipulation Language, kurz DML), sondern auchKommandos zur Datendefinition (die Data Definition Language, kurzDDL), mit denen sich z.B. neue Tabellen oder ganze Datenbanken anlegenlassen.

Wie universell SQL (dank ADO) unter Windows ist, soll das folgende kleineExperiment deutlich machen. Es setzt allerdings voraus, da Sie mit Win-

1 Wer sich ber den aktuellen Stand von SQL (Stichwort: SQL3) informieren mchte,

findet unter http://www.jcc.com/sql_stnd.html eine bersicht. Doch Vorsicht, SQLspielt sich nach wie vor zum grten Teil in der Gro-DV ab. Begriffe wie Windows,Visual Basic oder ADO finden sich nicht im SQL-Standarddokument.


46

dows 98 arbeiten und/oder der Windows Scripting Host (eine kleine Win-dows-Erweiterung, die man bei Windows 95 und Windows NT 4.0 kosten-los nachinstallieren kann Sie finden ihn im Internet z.B. unterhttp://msdn.microsoft.com/scripting/windowshost/download/default.htm) installiert wurde. Auerdem mssen bereits die ADO-Objekte installiertsein, was z.B. durch die Installation von Visual Basic 6.0 automatisch ge-schieht. Haben Sie diese allgemeinen Voraussetzungen erfllt, fhren Siefolgende Schritte aus:

Schritt 1:

Starten Sie Notepad (den Windows-Editor), und geben Sie folgende(VBScript-) Befehle ein:

Option ExplicitDim Rs, CnSet Cn = CreateObject("ADODB.Connection")Set Rs = CreateObject("ADODB.Recordset")Cn.Provider = "Microsoft.Jet.OLEDB.3.51"Cn.ConnectionString = _"C:\Programme\Microsoft Visual Studio\VB98\Biblio.mdb"Cn.OpenSet Rs.ActiveConnection = CnRs.Source = _"Select * From Authors Where Author = 'Tischer, Michael'"Rs.OpenMsgBox Rs.Fields("Au_ID").ValueCn.Close

Schritt 2:

berprfen Sie bitte den Datenbankpfad in der Befehlszeile:

Cn.ConnectionString = _"C:\Programme\Microsoft Visual Studio\VB98\Biblio.mdb"

Hier mu unbedingt der korrekte Pfad der Datei Biblio.mdb auf Ihrem PCeingetragen werden. Bei Biblio.mdb handelt es sich um die zweite Demo-datenbank (neben Northwind.mdb), die von Visual Basic 6.0 automatischinstalliert wird. Sie finden sie im Visual-Basic-Verzeichnis.

Schritt 3:

Speichern Sie die Textdatei unter dem Namen SQLAbfrage.vbs. Whrendder Dateiname keine Rolle spielt, ist die Erweiterung .vbs wichtig, da dieDatei als Scriptdatei erkannt werden soll.

Beziehungen zwischen Tabellen das relationale Modell

47

Schritt 4:

ffnen Sie die Scriptdatei (z.B. per Doppelklick). Wenn Sie alles richtig ge-macht haben (und der Windows Scripting Host und die ADOs auf Ihrem PCinstalliert sind), sollte nach einer kurzen Bedenkzeit die Zahl 1155 ange-zeigt werden. Dabei handelt es sich allerdings nicht um die Antwort auf alleFragen des Universums, sondern lediglich um den Inhalt des Feldes Au_Idin der Tabelle Authors der Datenbank Biblio.mdb des Autors Michael Ti-scher, dessen Datensatz ber eine SQL-Anweisung lokalisiert wurde.

Sie sehen an diesem kleinen Beispiel: Um Datenbankzugriffe per SQLdurchfhren zu knnen, bentigen Sie weder Visual Basic noch MicrosoftAccess. Dank der Active Data Objects (ADOs) und einem kleinen Script-programm (in diesem Beispiel ist es ein VBScript-Programm), das auf dieseObjekte zugreifen kann, ist SQL ganz allgemein unter Windows einsetzbar.Natrlich knnen Sie das Beispiel 1:1 unter Visual Basic (bzw. allgemeinVBA) ausfhren, doch ich denke, da diese kleine Demonstration etwaseindrucksvoller ist.

1.8 Beziehungen zwischen Tabellen das relationale Modell

Sie wissen inzwischen, da eine Datenbank aus Tabellen, eine Tabelle ausDatenstzen und ein Datensatz aus Feldern besteht. Dieses einfache Modellist aber noch nicht jenes Modell, das die moderne Datenbankentwicklungkennzeichnet. Das moderne Modell basiert auf Relationen zwischen Tabel-len und wird daher als relationales Datenbankmodell bezeichnet. Es gehtzwar bereits auf die 70er Jahre zurck, ist aber auch fast dreiig Jahre sp-ter das dominierende Modell im Bereich der PC-Datenbanken.

Haben Sie das allgemeine Modell der Datenbanken verstanden, also dieRolle von Tabellen, Datenstzen und Feldern, ist es zum relationalen Modellnicht mehr weit. Es basiert auf diesem einfachen Modell, packt es aber ineinen mathematischen Kontext (der in diesem Buch aber nicht vertieft wird)und verallgemeinert es dabei.

Gem dem relationalen Modell besteht eine Datenbank aus Tabellen, dieals relationale Tabellen oder einfach nur Relationen bezeichnet werden.Jede Tabelle enthlt einen oder mehrere Datenstze, die in diesem Zusam-menhang allerdings als Reihen (engl. rows) bezeichnet werden. Wo sichdiese Tabellen physikalisch aufhalten, spielt genauso wenig eine Rolle wiedie Anzahl der Tabellen und Datenstze sowie die Reihenfolge der einzelnen


48

Reihen in einer Tabelle (es gibt also anders als z.B. in einer Excel-Tabelleoder einem Visual-Basic-Grid keine festgelegte Sortierreihenfolge).

Jede Reihe besteht aus einem oder mehreren Feldern, die in diesem Zu-sammenhang auch als Spalten (engl. columns) bezeichnet werden. EineTabelle setzt sich demnach aus Reihen und Spalten zusammen. Nach demrelationalen Modell ist eine Reihe nicht zwingend an eine Tabelle gebunden,denn durch eine Datenbankabfrage knnen mehrere Spalten zu einer neuen(virtuellen) Tabelle kombiniert werden, die fr den Anwender (und damitauch fr den Programmierer) als eine Tabelle mit eigenen Zeilen und Rei-hen erscheint.

Halten wir fest: Eine Reihe in einer Tabelle entspricht einem Datensatz,eine Spalte einem Feld des Datensatzes. Eine Datenbank kann eine belie-bige Anzahl an Tabellen besitzen.

Bislang war alles noch einfach, und das wird auch so bleiben. Das Attributrelational leitet sich von dem Umstand ab, da zwischen den Feldern ver-schiedener Tabellen Beziehungen bestehen knnen, die in diesem Fall eben-falls Relationen heien. Relationen werden am besten an einem konkretenBeispiel deutlich. Stellen Sie sich eine Datenbank eines kleinen PC-Hnd-lers vor, der sowohl die Adressen seiner Kunden als auch die Auftrge die-ser Kunden in einer Datenbank speichern mchte. Der erste Ansatz knntedarin bestehen, alle Daten in einer Tabelle abzulegen:

Name Adresse Bestell-datum

Artikel-Name1

Artikel1-Preis

Artikel2-Name

Artikel2-Preis

Bernd Hohe Strae 1,22333 Hamburg

2.3.99 Celeron333-CPU

189.00

Dieter Westanlage 52,35398 Gieen

4.5.95 T8-Trans-puter

999.00 256 MbyteRAM

159.00

usw.

Bereits diese aus zwei Datenstzen bestehende Tabelle macht deutlich, dadieser Ansatz scheitern mu. Es wre sehr ungeschickt, zu jedem Auftragsmtliche Kundendaten zu speichern. Nicht nur, da die Tabelle dadurchrelativ umfangreich werden wrde, das Ausma an identischen Daten(Redundanz) wre enorm. Fr diesen Fall bietet das relationale Modell eineLsung an: das Verteilen der Daten auf mehrere Tabellen und das Herstel-len von Beziehungen zwischen den Feldern einzelner Tabellen. Bezogen aufunseren PC-Hndler mte dieser als erstes eine Tabelle fr seine Kunden-daten einfhren:

Beziehungen zwischen Tabellen das relationale Modell

49

KundenNr Name Strae Ort PLZ Telefon eMail

1001 Dieter Westanlage 52 Gieen 35398

1002 Reinhold Henselstrae 4 Gieen 35396

usw.

Diese Tabelle (die natrlich rein fiktive Daten enthlt) wird auch als Stamm-datentabelle bezeichnet, da die darin enthaltenen Daten den Kern (Stamm)des Datenbestands bilden und, anders als z.B. die Auftragsdaten, relativ sel-ten gendert werden.

Auch fr die Produkte wird eine eigene Tabelle angelegt:

ProduktNr Produkt Typ D istributor EK-Preis AnzahlLager

5001 Celeron-CPU 333 1 ABC 179,00 33

5001 T8-Transputer 3 DEF 555,00 2

usw.

Auch hier sind die Inhalte, wie z.B. die Produktnummern, fiktiv. In der Pra-xis werden sich diese Daten meistens an bereits vorhandenen Gegebenhei-ten, wie einen Produktkatalog oder eine Preisliste, orientieren. Bleiben nurnoch die Auftragsdaten, denen ebenfalls eine Tabelle spendiert wird.

AuftragsNr KundenNr D atum ProduktNr Anzahl Rabatt Zahlart

9001 1001 1.4.1999 5001 2 20 Kredit

9002 1002 2.4.1999 5001 12 40 Bar

usw.

Anstatt alle Daten in eine Tabelle zu packen, wurden die Daten auf drei Ta-bellen verteilt. Ein kleines Problem gilt es aber noch zu lsen. Die Tabellemit den Auftragsdaten enthlt keine Kundennamen mehr. Wie kann ein Da-tenbankprogramm herausfinden, welche Auftrge etwa der Kunde Dieterbereits erteilt hat? Ganz einfach, die Tabelle mit den Auftragsdaten enthltein Feld mit dem Namen KundenNr, ber dessen Inhalt ein Datensatz inder Tabelle Kundendaten ausgewhlt wird. Das Feld KundenNr der Auf-tragstabelle verweist somit auf das Feld KundenNr der Kundenstammdaten-tabelle (die Namensbereinstimmung ist rein zufllig). Durch diese Relationwird eine Beziehung zwischen beiden Tabellen hergestellt. Das ist die Ideerelational

Inhaltsverzeichnisgcc.uni-paderborn.de/www/WI/WI2/wi2_lit.nsf... · Inhaltsverzeichnis 6 2...

Documents

Transcript of Inhaltsverzeichnisgcc.uni-paderborn.de/www/WI/WI2/wi2_lit.nsf... · Inhaltsverzeichnis 6 2...