Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Books on Demand
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Deutsch
- Veröffentlichungsjahr: 2019
Es gibt zum Thema C++ Bücher wie Sand am Meer. Auch zu Visual Studio ist jede Menge Literatur verfügbar. Und natürlich ebenso für Datenbanksysteme wie Oracle. Wenn man aber versucht, ein Buch zu finden, in dem die Entwicklung einer Windowsanwendung mit Visual C++ und einer Oracle Datenbank im Hintergrund beschrieben wird, wird die Luft nicht nur dünner, nein, dann taucht man ins literarische Vakuum ein. Der Autor beschäftigt sich mit genau diesem Thema seit vielen Jahren, und hat diese Inhalte auch in zwanzig Jahren Lehrtätigkeit Hunderten von Fachhochschulstudenten vermittelt. Da bekommt man natürlich ein Gefühl dafür, wo die Schwierigkeiten liegen, wo man als Einsteiger "hängen bleibt". Das vorliegende Buch ist mit dem Ziel entstanden, dazu einen gut verständlichen Einstieg zu bieten, typische, immer wieder gemachte Fehler vermeiden zu helfen, und vor allem Wege aufzuzeigen, die auf dem kürzesten Weg zu professionellen Ergebnissen führen.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 383
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Der Autor:
Dipl. Ing. GÜNTER LEITENBAUER
Jahrgang 1965, Technischer Physiker (Studium an der TU Wien)
1995 - 2015 Lehrtätigkeit an der Fachhochschule Wels für AAPT (automatisierte Anlagen- und Prozesstechnik), MeWi (Mechatronik / Wirtschaft) und BUT (Bio- und Umwelttechnik) in den Schwerpunkten Informationstechnologie, Datenbanken und Projektarbeit
Seit 2001 Geschäftsführer der Leitenbauer GMBH (http://www.leitenbauer.at)
Vorwort und Dank
Ich habe in meinem Leben das eine oder andere Buch über Programmierung oder über Datenbanken in meinen Händen gehalten. Und nie verstanden, warum solche Bücher immer so fürchterlich unvollständig und/oder holprig zu lesen sein müssen. Oftmals fehlten genau die Schritte, bei denen ich Schwierigkeiten bekam. Der Verdacht liegt da nahe, dass viele Bücher weniger aus der Praxis kommen und vielmehr schlicht und einfach irgendwo abgeschrieben wurden.
Das, verehrte Leser, garantiere ich Ihnen, ist hier nicht der Fall. Ob das Buch sonst gut und leicht zu lesen ist, das mögen Sie beurteilen. Aber ausnahmslos alle Beispiele hier im Buch wurden programmiert, kompiliert und ausgeführt, bis sie funktionierten.
Und es wurde auch nichts weggelassen, von dem ich der Meinung war, dass es für das Verständnis der Materie notwendig sei. Was bedeutet, dass eigentlich fast gar nichts weggelassen werden konnte.
Tippfehler kann niemand ausschließen, und sicherlich sind auch in diesem Buch welche zu finden. Die Codefragmente allerdings sind 1:1 aus den Sourcen kopiert, und nur das Format wurde da und dort an die Erfordernisse des Drucks angepasst.
Der Aufbau eines Buchs ist immer eine Entscheidung, die wohlüberlegt sein sollte. Ich habe mich hier für eine Struktur entschieden, die den Leser von den grundsätzlichen Prinzipien bis zu schon einigermaßen speziellen Techniken begleitet, wobei versucht wurde, ein durchgängiges Beispiel eben Stück für Stück zu erweitern, zu verfeinern und zu perfektionieren. Ich hoffe, dass mir dies gelungen ist.
Um die Druckkosten (und damit den Buchpreis) in einem vernünftigen Rahmen zu halten, wurde eine eher kleine Schriftgröße gewählt. Für mich ist das aber (zumindest mit meiner Lesebrille, wenn ich sie finde) kein Problem. Im Original waren die Sourcecodebeispiele zudem farbig codiert – auch dies fiel dem Druck zum Opfer. Ich hoffe dennoch, dass Ihnen das Buch gefällt!
Die endgültige Beurteilung liegt natürlich bei Ihnen. Scheuen Sie sich nicht, mir Feedback zu geben, ich vertrage Kritik. Die Emailadresse finden Sie am Ende des Buchs.
An dieser Stelle möchte ich mich für das Korrekturlesen, speziell bezüglich der Rechtschreib- und Tippfehler, aber auch für so manch anderen wertvollen Hinweis, bei Doris Rettenegger bedanken.
Günter Leitenbauer, September 2019
Inhalt
WOHIN GEHT DER WEG?
1.1 A
UFBAU DES
B
UCHS
1.2 D
AS
O
RACLE
D
ATENBANKMANAGEMENTSYSTEM
1.3 D
IE
V
ISUAL
S
TUDIO
E
NTWICKLUNGSUMGEBUNG
1.4 W
EITERE
W
ERKZEUGE
1.5 D
IE
D
ATEN ZUM
B
UCH
1.6 N
OMENKLATUR
1.7 L
IZENZEN UND
V
ERWERTUNGSRECHTE
DIE DATENBANK
2.1 V
ORARBEITEN IN DER
D
ATENBANK
2.1.1 Das Zugriffswerkzeug SQL*Plus
2.1.2 Masteruser anlegen
2.1.3 Das Werkzeug SQL*Plus
2.1.4 Datenbankrollen
2.2 D
IE ERSTE
T
ABELLE
2.2.1 Der Primärschlüssel
2.2.2 Öffentliche Namen (public synonyms)
2.2.3 Zugriffsrechte auf Tabellen
2.3 E
IN ERSTER
D
ATENSATZ
2.4 Z
U GUTER
L
ETZT
–
EINE
D
ATENBANKABFRAGE
2.5 Z
USAMMENFASSUNG
VISUAL STUDIO C++ - DER EINSTIEG
3.1 W
ELCHE
V
ERSION VON
VS
SOLL MAN INSTALLIEREN
?
3.2 W
AS IST BEI DER
I
NSTALLATION VON
VS
ZU BEACHTEN
?
3.3 D
AS
P
ROJEKT WIRD ERSTELLT
3.3.1 MFC in der Nussschale
3.3.2 SDI und MDI Document/View Architektur
3.3.3 SDI oder MDI für unser Projekt?
3.4 P
ROJEKTHANDLING
3.4.1 Löschen des Projektverzeichnisses
3.4.2 Entfernen des Projekts aus Visual Studio
3.5 U
NSER ERSTES
E
XECUTABLE
3.6 S
TARTEN DES
P
ROGRAMMS
3.6.1 Debug oder Release?
3.6.2 Programm debuggen
3.7 Z
USAMMENFASSUNG
VERBINDEN MIT DER DATENBANK
4.1 D
ATENBANK
API
4.1.1 ODBC Schnittstellen
4.1.2 Das OCI und das OCCI
4.1.3 OCILIB
4.2 D
IE
I
NTEGRATION VON
OCILIB
INS
P
ROJEKT
4.2.1 OCILIB in der aktuellen Version downloaden
4.2.2 OCILIB ins Projekt kopieren
4.2.3 Konfiguration und Includepfade in Visual Studio
4.3 W
IR ERSTELLEN EINE
D
ATENBANKVERBINDUNG
4.3.1 Windows Umgebungsvariablen
4.4 W
IR ERSTELLEN EINE
D
ATENBANKANBINDUNG
4.4.1 Initialisierung der OCI-Umgebung
4.4.2 Beenden der Anwendung
4.5 V
ERBINDEN EINES
U
SERS MIT DER
D
ATENBANK
4.5.1 Meldungsausgabe in Visual C++
4.5.2 Exceptionhandling mit OCILIB
4.5.3 Endlich – wir melden uns an der Datenbank an
4.6 Z
USAMMENFASSUNG
EINE DATENBANK-BASISKLASSE
5.1 O
RDNUNG SCHAFFEN IM
P
ROJEKTMAPPENEXPLORER
5.2 E
INE NEUE
K
LASSE ERZEUGEN
5.2.1 Ein wenig Nomenklatur sollte sein
5.2.2 Was soll unsere neue Klasse können?
5.2.3 Login / Logout
5.2.4 Zeichenketten und die Klassenfamilie CString
5.2.5 Erweiterung der Hauptrahmenfensterklasse
5.3 A
UFBAU DER
D
ATENBANKKLASSE
CVCODB
5.3.1 Erzeugen eines Objekts – der Konstruktor
5.3.2 Zerstören eines Objekts – der Destruktor
5.3.3 Ein weiterer Konstruktor
5.4 E
INIGE WICHTIGE
M
ETHODEN DER
K
LASSE
5.4.1 Zugriff auf das Connection-Objekt
5.4.2 Abfragemethode
5.5 Z
USAMMENFASSUNG
DER LOGIN-DIALOG
6.1 D
ER
R
ESSOURCENEDITOR
6.1.1 Hinzufügen von Bedienelementen
6.1.2 Eigenschaften von Bedienelementen
6.1.3 Die weiteren Bedienelemente hinzufügen
6.1.4 Dialogeigenschaften ändern
6.2 E
RSTELLEN DER
D
IALOGKLASSE
6.2.1 Anpassen der Headerdatei
6.2.2 Anpassen der Quellcodedatei
6.2.3 Datenaustausch mit Membervariablen
6.2.4 Der Datenaustausch in MFC
6.2.5 Implementierung der DDX-Methode
6.2.6 Das Eventhandling für den Button „OK“
6.2.7 Vorbereitung der Anmeldung an die Datenbank
6.2.8 Anmeldung an die Datenbank
6.3 A
UFRUF DES
L
OGINDIALOGS
6.3.1 Dialoge aufrufen in MFC
6.3.2 Aufruf unseres Logindialogs im Hauptrahmenfesnter
6.4 Z
USAMMENFASSUNG
DIE WINDOWS REGISTRY
7.1 A
UFBAU DER
W
INDOWS
R
EGISTRY
7.2 Z
UGRIFFE AUF DIE
R
EGISTRY AUS
MFC A
NWENDUNGEN
7.3 E
INE EINFACHE
R
EGISTRY
-K
LASSE
7.3.1 Die Klasse erstellen
7.3.2 Die Implementation der Klasse CRegEntry
7.4 V
ERWENDUNG DER
R
EGISTRYKLASSE IM
L
OGINDIALOG
7.4.1 Logindaten in die Registry ablegen
7.4.2 Logindaten aus der Registry einlesen
7.5 E
RWEITERUNG AUF ANDERE
D
ATENTYPEN
7.6 Z
USAMMENFASSUNG
MELDUNGSTEXTE
8.1 S
TRINGTABLES
8.2 S
TRINGTABLEEINTRÄGE IM
P
ROGRAMM VERWENDEN
8.3 S
PEZIELLE
M
ELDUNGSTEXTE
8.3.1 Die Methode CString::Format()
8.3.2 Das Zeichen „%“ als Zeichen im Text
8.4 F
EHLERMELDUNG BEIM
V
ERBINDUNGSAUFBAU
8.4.1 Eine eigene Fehlermeldungsmethode
8.5 W
ARTECURSOR
8.6 Z
USAMMENFASSUNG
MENÜS UND MENÜPUNKTE
9.1 D
IE
R
ESSOURCE
M
ENU
9.1.1 Der Aufbau von Menüs
9.1.2 Menüs bearbeiten
9.1.3 Menüeintragseigenschaften
9.1.4 Die Menüressource IDR_HELP_MENU
9.1.5 Die Menüressource IDR_OUTPUT_POPUP
9.1.6 Die Menüressource IDR_POPUP_EDIT
9.1.7 Die Menüressource IDR_THEME_MENU
9.2 R
EAKTION AUF EINEN
M
ENÜEINTRAG
9.2.1 Windowsanwendungen mit MFC und Menüauswahl
9.3 E
IN EINFACHER
O
PTIONENDIALOG
9.3.1 Erstellen der Optionendialogressource
9.3.2 Aufruf des Optionendialogs mit dem Menüeintrag
9.3.3 Ablegen des Checkbox-Status in der Registry
9.3.4 Erweitern der Fehlerbehandlungsmethode
9.4 Z
USAMMENFASSUNG
DIE ERSTE DATENBANKABFRAGE
10.1 D
ATENBANKTABELLEN MIT
SQL
BEARBEITEN
10.1.1 Grundsätzliches zu SQL-Abfragen
10.2 D
ER
D
IALOG
„P
ERSONEN
“
10.2.1 Suchkriterien
10.2.2 Das Tabellenelement
10.3 E
RSTELLEN DER
D
IALOGKLASSE
10.4 E
RSTELLEN DES
M
ENÜEINTRAGS
10.5 A
UFRUF AUS DEM
M
ENÜ
10.6 W
IR FÜLLEN DIE
K
LASSE MIT
I
NTELLIGENZ
10.6.1 Vorbelegen der Comboboxliste mit Werten
10.6.2 Suchfelder mit Registryfunktionalität
10.6.3 Eventhandler für den Button „Suchen“
10.7 D
IE EIGENTLICHE
S
UCHE IN DER
D
ATENBANK
10.7.1 Erzeugen der SQL Abfrage
10.7.2 Ausführen der SQL Abfrage
10.7.3 Holen der gefundenen Datensätze
10.7.4 Die Resultatstabelle und die Klasse CListCtrl
10.7.5 Die Where-Klausel-Funktion
10.8 Z
USAMMENFASSUNG
DATENSÄTZE ÄNDERN
11.1 D
EN
D
OPPELKLICK AUF EINE
T
ABELLENZEILE VERARBEITEN
11.1.1 Tabellenzeilen selektierbar machen
11.1.2 Doppelklick auf eine Tabellenzeile
11.1.3 Unsere eigene ListCtrl-Klasse
11.1.4 Bearbeitung der Nachricht im Dialog
11.2 D
ER
Ä
NDERUNGSDIALOG
11.2.1 Die Dialogressource zum Ändern von Personen
11.2.2 Die Dialogklasse zum Ändern von Personen
11.2.3 Übergabe der zu ändernden Daten
11.2.4 Hart kodierte Konstanten
11.3 A
BSPEICHERN DER
Ä
NDERUNGEN IN DIE
D
ATENBANK
11.3.1 Zusammenbau des SQL Statements zum Ändern
11.3.2 Ausführen des SQL Statements und Fehlerbehandlung
11.4 Z
URÜCK IN DEN
P
ERSONENPFLEGEDIALOG
11.5 Z
USAMMENFASSUNG
EINEN NEUEN DATENSATZ ERSTELLEN
12.1 E
INDEUTIGE
K
UNSTSCHLÜSSEL
12.1.1 Sequenzen
12.1.2 Erweiterung unserer Datenbankklasse
12.2 D
ER
E
INFÜGEDIALOG
12.2.1 Button „Neu“ im Dialog „Personenpflege“
12.2.2 Änderungen im Eingabedialog
12.2.3 Die Methode „DoInsert()“
12.3 D
AS
E
RGEBNIS
12.3.1 Pflichtfelder
12.4 Z
USAMMENFASSUNG
LÖSCHEN VON DATENSÄTZEN
13.1 L
ÖSCHEN VON
D
ATEN IN EINER
D
ATENBANK
13.2 L
ÖSCHFUNKTIONALITÄT IM
D
ATENPFLEGEDIALOG
13.2.1 Ein Kontextmenü für die Tabelle
13.2.2 Aufruf des Menüs im Programm
13.3 D
AS
K
ONTEXTMENÜ UND DIE
K
LASSE
CVCOL
IST
C
TRL
13.3.1 Aufrufen eines Kontextmenüs
13.4 B
EARBEITEN DER
M
ELDUNGEN IN DER
D
IALOGKLASSE
13.4.1 Löschen eines Datensatzes aufrufen
13.4.2 Das eigentliche Löschen in der Datenbank
13.5 U
NSERE FERTIGE
P
ERSONENPFLEGE
13.6 Z
USAMMENFASSUNG
ERWEITERN DER DATENBANK
14.1 D
IE
T
ABELLE
VCO_TESTFALL
14.1.1 Problemfestlegung
14.1.2 Das Script für die Tabelle
14.1.3 Fremdschlüsselattribute und referentielle Integrität
14.1.4 Anlegen der Sequenz
14.2 B
EISPIELDATEN ANLEGEN
14.2.1 Datumswerte in Oracle
14.2.2 NULL-Werte
14.3 A
BFRAGEN DER
W
ERTE
14.3.1 Datenbankjoins
14.3.2 Zusammenfügen in der Abfrage
14.4 Z
USAMMENFASSUNG
DER TESTFALL-DIALOG
15.1 D
IE
D
IALOGRESSOURCE FÜR
T
ESTFÄLLE
15.2 N
EUE
R
EGISTRY
-K
ONSTANTEN
15.3 D
IE
D
IALOGKLASSE FÜR
T
ESTFÄLLE
15.3.1 Das Headerfile
15.3.2 Der Datenaustausch
15.3.3 Dialoginitialisierung
15.3.4 Der Eventhandler für den Button „OK“
15.3.5 Die Methoden „OnSearch()“ und „DoSearch()“
15.3.6 Der Eventhandler für das Ändern von Daten
15.3.7 Der Eventhandler für das Neuanlegen von Daten
15.3.8 Der Eventhandler für das Löschen von Daten
15.4 D
ER
M
ENÜEINTRAG
„T
ESTFÄLLE
“
15.5 E
RWEITERUNG DER
T
ABELLE
15.6 D
ATEN ÄNDERN UND
N
EUANLEGEN
15.6.1 Die Datenklasse „CDataTestfall“
15.6.2 Die Änderungsdialog-Ressource
15.6.3 Eine Combobox mit Datenbankanbindung
15.6.4 Die Änderungsdialog-Klasse
15.7 F
ERTIGSTELLEN DER
T
ESTFALLKLASSE
15.7.1 Der Eventhandler für das Ändern von Daten
15.7.2 Der Eventhandler für das Neuanlegen von Daten
15.7.3 Der Eventhandler für den Klick auf den Button „Neu“
15.8 A
USPROBIEREN DES
D
IALOGS
15.9 Z
USAMMENFASSUNG
ERWEITERUNG DER TABELLENKLASSE
16.1 A
BSPEICHERN UND
E
INLESEN VON
S
PALTENBREITEN
16.1.1 Abspeichern der Spaltenbreiten
16.1.2 Einlesen der Spaltenbreiten
16.1.3 Setzen der Spaltenbreiten
16.2 A
NDERE DENKBARE
E
RWEITERUNGEN
16.3 Z
USAMMENFASSUNG
DAS AUSGABEFENSTER
17.1 D
AS
O
UTPUT
W
INDOW
17.1.1 Das Output Window in der MFC Anwendung
17.1.2 Anpassen an unsere Bedürfnisse
17.1.3 Eine einfache Ausgabemethode
17.1.4 Eine globale Funktion zur Methode
17.2 A
USGABEMELDUNGEN AUSGEBEN
17.3 Z
USAMMENFASSUNG
EXCELDATEIEN ERSTELLEN
18.1 D
IE
B
IBLIOTHEK
LIBXL
18.1.1 Integration der Bibliothek ins Projekt
18.1.2 Die LIBXL DLL
18.2 E
RSTELLEN DER
R
EPORTDATEI
18.3 E
IN NEUES
M
ENÜ
„A
USWERTUNGEN
“
18.4 A
UFRUF AUS DEM
M
ENÜ
18.5 D
IE
R
EPORTING
-K
LASSE
18.5.1 Öffnen einer Exceldatei
18.5.2 Befüllen der Daten
18.5.3 Speichern der Report-Datei
18.5.4 Befüllen der Personendaten
18.5.5 Eine Zeilenkopiermethode erstellen
18.6 D
ER FERTIGE
R
EPORT
18.7 D
ATEIEN MIT EINER
A
NWENDUNG ÖFFNEN
18.8 Z
USAMMENFASSUNG
ORACLE BINDEVARIABLEN
19.1 B
INDEVARIABLEN
19.1.1 Bindevariablen in OCILIB
19.2 D
AS
E
RGEBNIS
19.3 Z
USAMMENFASSUNG
EINE DIALOG-BASISKLASSE
20.1 D
IE
K
LASSE
„CVCOD
LG
“
20.2 E
INE
D
IALOGKLASSE ERSTELLEN
20.2.1 Eine Datenklasse für Datenbankspalten und Felder
20.3 D
IE EIGENTLICHE
D
IALOGKLASSE
„CVCOD
LG
“
20.3.1 Attribute der Dialogklasse
20.3.2 Methoden der Dialogklasse
20.3.3 Eventhandler und weitere Funktionalität
20.3.4 Virtualität
20.4 V
ERWENDUNG DER
D
IALOGKLASSE
20.5 E
RWEITERUNGEN UND
V
ERBESSERUNGEN
20.6 Z
USAMMENFASSUNG
DAS RELEASE
21.1 K
ONFIGURATIONEN
21.2 D
IE
R
ELEASE
-K
ONFIGURATION
21.3 D
AS
V
ERTEILEN AUF ANDERE
C
LIENTS IM
N
ETZWERK
21.3.1 Oracle Client Installation
21.3.2 Visual C++ Redistributables
21.4 D
AS
S
ETUPPROGRAMM
21.5 T
ROUBLESHOOTING
21.6 „U
NVORBELASTETE
C
LIENTRECHNER
“
21.7 Z
USAMMENFASSUNG
A STICHWORTVERZEICHNIS
B ABBILDUNGSVERZEICHNIS
C LITERATURVERZEICHNIS
1 Wohin geht der Weg?
Es gibt zum Thema C++ Bücher wie Sand am Meer. Auch zu Visual Studio ist jede Menge Literatur verfügbar. Und natürlich ebenso für Datenbanksysteme wie Oracle. Wenn man aber versucht, ein Buch zu finden, in dem die Entwicklung einer Windowsanwendung mit Visual C++ und einer Oracle-Datenbank im Hintergrund beschrieben wird, wird die Luft nicht nur dünner, nein, dann taucht man ins literarische Vakuum ein.
Der Autor beschäftigt sich mit genau diesem Thema seit vielen Jahren und hat diese Inhalte auch in zwanzig Jahren Lehrtätigkeit Hunderten von Fachhochschulstudenten vermittelt. Da bekommt man natürlich ein Gefühl dafür, wo die Schwierigkeiten liegen, wo man als Einsteiger „hängen bleibt“.
Das vorliegende Buch ist mit dem Ziel entstanden, dazu einen gut verständlichen Einstieg zu bieten, typische, immer wieder gemachte Fehler vermeiden zu helfen, und vor allem Wege aufzuzeigen, die auf dem kürzesten Weg zu professionellen Ergebnissen führen. Die Probleme liegen nämlich meistens nicht in der Programmiersprache oder dem fehlenden Datenbankwissen, sondern sind erfahrungsgemäß sehr oft scheinbar nur kleine Hürden im Bereich der eingesetzten Werkzeuge und deren Einstellungen:
Welche Compileroptionen muss man beachten, um eine Anwendung erfolgreich zu kompilieren? Welche Programmierschnittstellen versprechen einen performanten und trotzdem einfach zu programmierenden Zugriff auf Datenbanken? Wie soll ich mich bei all diesen Einstellmöglichkeiten des Werkzeugs XY zurechtfinden? Wie bekomme ich meine abgefragten Daten am einfachsten ein eine Exceltabelle? Und so weiter, und so fort.
Das Werk geht daher bewusst nicht den Weg, langatmig die Grundlagen der verwendeten Werkzeuge, Programmiersprachen und Datenbankhintergründe zu erarbeiten, bevor man, vielleicht auf Seite 400, dann noch als Alibi ein paar einfache Programmfragmente einfügt. Vielmehr wird hier von der grünen Wiese weg versucht, eine (anfangs noch sehr einfache) Anwendung bei ihrer Entstehung zu begleiten. Und es wird darauf Wert gelegt, gerade am Anfang wirklich alle Kleinigkeiten, die zu einem Scheitern führen könnten, genau zu beschreiben.
Um nicht irgendein fiktives Thema konstruieren zu müssen, verfolgt das Buch die Erstellung einer einfachen Testfallverwaltung, etwas, dem man in der Softwareentwicklung immer wieder begegnen wird.
Was dieses Buch nicht sein will
Eine Einführung in die Programmiersprache C++ oder in das (objektorientierte) Programmieren an sich. Auch dazu gibt es mehr als ausreichend Literatur. Es wäre sinnlos, hier ein weiteres Werk zu positionieren. Daher werden Grundlagen in der objektorientierten Programmierung mit der Programmiersprache C++ als bekannt vorausgesetzt. Wo es allerdings in speziellere Bereiche der Programmierung von Datenbankanwendungen geht, werden die nötigen Grundlagen vermittelt.
Und natürlich werden auch Spezifika der verwendeten Klassenbibliothek von Microsoft, der Microsoft Foundation Classes (MFC), erörtert. Will man mit der Sprache C++ Anwendungen für Windows entwickeln, führt an den MFC einfach kein Weg vorbei.
Zusammenfassend veranschaulicht, ist dieses Buch daher für folgendes Publikum konzipiert, beziehungsweise setzt folgendes Basiswissen voraus:
•
Datenbanken:
minimale Kenntnisse in relationalen Datenbanken
•
C++:
Grundlagen der Programmiersprache
•
Visual Studio:
keine Vorkenntnisse
1.1 Aufbau des Buchs
Am Anfang eines Abschnitts oder Kapitels steht immer eine kurze Problembeschreibung, die in der Folge dann gelöst wird. So wie es eben auch in der Praxis der Softwareentwicklung vorkommt.
Dabei wird hier aus Gründen des Umfangs auf die wichtigen Entwicklungsphasen „Pflichtenhefterstellung“ und „Systementwurf“ nicht oder nur im für das Verständnis unbedingt nötigem Maße eingegangen. Jeder Softwareprojektleiter weiß, dass in diesen Phasen die Grundlagen für den Erfolg oder Misserfolg eines Projektes gelegt werden, und zu diesem Thema gibt es mehr als ausreichend Literatur.
Das vorliegende Werk widmet sich, wie bereits erwähnt, mehr den praktischen Problemen, die auftauchen, wenn das Projekt in die Realisierungsphase kommt. Naturgemäß kommt man dabei nicht umhin, auch dem Programmcode viel Platz einzuräumen. Dieser wird dabei wie folgt gekennzeichnet:
// Ist man an die Datenbank angemeldet?
boolCVCODB::IsConnected()const
{
returnm_bIsConnected;
}
Solche Code-Beispiele können wie oben C++ Code oder auch Datenbankscripts (SQL, DML, etc.) sein. Worum es sich im Einzelfall handelt, wird aus dem Text stets klar ersichtlich sein.
Das Buch ist zudem mit vielen Grafiken und Bildern ausgestattet, um das Verständnis zu erleichtern.
1.2 Das Oracle Datenbankmanagementsystem
Zum Zeitpunkt des Entstehens dieses Buchs ist die aktuelle Version von Oracle die 12g, wobei die Nachfolgeversion 18 gerade herausgegeben wurde. In der Praxis sind aber auch ältere Versionen dieses DBMS (Datenbankmangementsystems) weit verbreitet im Einsatz. Ab der Version 8i, auf jedem Fall aber ab der Version 9 hat sich dabei in den Funktionalitäten, die für unser Vorhaben interessant sind, nicht mehr allzu viel geändert. Die Datenbanktechnologie ist Jahrzehnte alt und dementsprechend stabil.
Daher kann die Leserin1 davon ausgehen, dass die hier gezeigten Mechanismen und Funktionen für alle Oracle DBMS ab der Version 9 funktionieren.
Auf die Installation einer Oracle Datenbank wird in diesem Buch nicht eingegangen. Die Administration eines Oracle DBMS ist ein Thema, das selbst ganze Bücher füllt. Allerdings reicht es für unsere Zwecke glücklicherweise, wenn das Oracle DBMS einfach mit den Standardvorgaben installiert wird, und dazu braucht man weder ein Buch noch einen dreiwöchigen Administrationskurs des Herstellers.
Das nächste Kapitel befasst sich eingehender mit der Datenbank, wobei aber hier gleich eines vorweggenommen wird:
Dies ist kein Grundlagenbuch zum Thema Datenbanken!
Wir werden die für das Verständnis und unser Projekt nötigen Datenbankfunktionalitäten zwar darstellen, uns aber auch genau darauf beschränken. Bücher zu den Themen Datenbanken und SQL gibt es zuhauf, es wäre nicht zielführend, das vorliegende Werk damit unnötig aufzublasen.
1.3 Die Visual Studio Entwicklungsumgebung
Im Gegensatz zu Oracle hat sich bei Visual Studio in den letzten Jahren funktional und auch von der Benutzeroberfläche her einiges fundamental geändert. Ab der Version 2015 scheint sich diese Entwicklung verlangsamt zu haben, sodass die meisten Funktionalitäten, die hier beschrieben werden, wohl in allen neueren Releases von Visual Studio sehr ähnlich aussehen.
Die Beispiele im vorliegenden Buch wurden mit Microsoft Visual Studio Community 2017 (V15.6.3) erstellt. Die Community-Variante von Visual Studio ist für nichtkommerzielle Verwendung gratis lizensierbar (Stand: Februar 2019) und für unsere Zwecke absolut ausreichend.
1.4 Weitere Werkzeuge
Zum Editieren der Datenbankscripts reicht ein beliebiger Texteditor. Mehr werden wir hier auch nicht verwenden. Natürlich bietet ein Spezialwerkzeug gerade beim Erstellen von Datenbankmodellen2 erhebliche Vorteile. Unser Modell wird aber sehr einfach und einigermaßen überschaubar bleiben.
1.5 Die Daten zum Buch
Alle Datenbankscripts und alle Sourcedateien können vom Autor kostenlos angefordert werden.
Emailadresse: [email protected]
1.6 Nomenklatur
Dieses Buch verwendet an vielen Stellen das vorangestellte Kürzel VCO. Es steht für „Visual C++ mit Oracle“ und dient in erster Linie der eindeutigen Unterscheidung des Sourcecodes von anderen Sourcen (z. B. denen von Drittanbietern wie OCILIB oder LIBXL).
1.7 Lizenzen und Verwertungsrechte
Alle in diesem Buch veröffentlichten Sourcecodes des Autors dürfen zwar für den Privatgebrauch (aber nicht kommerziell!) frei verwendet werden. Ausgenommen sind davon Bibliotheken und Sourcen von Drittanbietern. Für diese sind die beim Anbieter genannten Lizenzbestimmungen maßgebend.
Für eine kommerzielle Nutzung der Sourcen im Buch ist mit dem Autor ein gesondertes Einvernehmen herzustellen.
1 Dieses Buch verwendet die weibliche und die männliche Form generisch, das heißt: Das jeweils andere Geschlecht ist stets mitgemeint. Auf die schwer lesbaren Schreibweisen wie LeserInnen oder Leser_innen oder gar Leser_*innen, etc. wird hier bewusst verzichtet.
2 Siehe dazu das Buch „Datenbankmodellierung“ vom gleichen Autor, erschienen 2003 im Franzis‘ Verlag.
2 Die Datenbank
Warum fangen wir mit der Datenbank an und nicht mit Visual Studio C++?
Die Datenbank ist das Backend jeder Datenbankanwendung, während die Anwendung zumeist als Frontend bezeichnet wird. Nun tut man sich schwer, eine Anwendung zu programmieren, wenn man noch nicht weiß, wie die zugrundeliegende Datenhaltung, in unserem Falle die Datenbank, aufgebaut ist. Ganz abgesehen davon, dass man so eine Anwendung weder testen noch auch nur laufen lassen könnte.
Wir benötigen daher zuallererst ein Grundgerüst, also ein Datenmodell inkl. einiger weniger Beispieldaten.
Man kann nun die gesamte Datenbank (genauer: das Datenmodell) entwerfen und implementieren (über Scripts die entsprechenden Tabellen im DBMS anlegen) und dann beginnen zu programmieren. Zumindest, wenn man entweder ein Genie ist, äußerst strukturiert zu arbeiten gewohnt ist, oder so etwas tagtäglich macht. Wer sich damit permanent beschäftigt, benötigt vermutlich das vorliegende Buch nicht, zumindest nicht dieses Kapitel. Ähnliches dürfte für Genies zutreffen. Und derart strukturiert zu arbeiten, dass man alle Eventualitäten im Datenmodell schon zu dieser frühen Phase überblickt, bleibt wohl ebenfalls einigen wenigen Koryphäen überlassen.
Alle anderen, so wie auch ich, verfolgen eher die Strategie, dass sich das Datenmodell mit dem Frontend (dem „Programm“) mit zu entwickeln hat. Oracle unterstützt dies auch recht gut, wie alle namhaften DBMS Hersteller3.
Tipp:
Entwickeln Sie das Datenmodell und die Anwendung parallel, sobald Sie das Problem grundsätzlich analysiert haben. Natürlich ist das keine geeignete Strategie für größere Softwareprojekte, an denen mehrere Mitarbeiter zugleich und vor allem miteinander arbeiten. Das ist aber in unserem Miniprojekt auch nicht der Fall.
Der Projektname
Wie sollen wir unser Projekt nennen? Eine Bezeichnung benötigt es schon allein für die Festlegung des Visual Studio Projektnamens (siehe im nächsten Kapitel).
Vorschlag: VCO. Das steht für „Visual C++ mit Oracle“, ist kurz und griffig und meines Wissens nach noch nicht in Verwendung (jedenfalls nicht in einem mir bekannten Programm).
2.1 Vorarbeiten in der Datenbank
Bevor wir unsere erste Datenbanktabelle anlegen können, müssen wir einige Vorarbeiten in der Datenbank durchführen. Wir gehen dabei davon aus, dass die Datenbank korrekt installiert4 wurde, zugreifbar ist, und wir einen Account als Datenbankadministrator (dba) haben, zum Beispiel SYS, SYSTEM oder INTERNAL.
2.1.1 Das Zugriffswerkzeug SQL*Plus
Um SQL, DML oder DDL Scripts in der Datenbank ablaufen zu lassen, kann man verschiedene Tools benutzen.
Wir werden hier das mit Oracle mitgelieferte und mitinstallierte Werkzeug SQL*Plus verwenden, ein Kommandozeilenwerkzeug. Die hier angeführten Scripts werden dann einfach ins SQL*Plus kopiert (Block markieren und im SQL*Plus einfügen).
Wenn man ein anderes Werkzeug benutzen möchte, ist dies natürlich auch möglich.
2.1.2 Masteruser anlegen
Wir gehen weiters davon aus, dass wir Administrationsrechte auf der Datenbank besitzen. Es wäre jetzt aber keine gute Idee, die Datenbankobjekte (User, Tabellen, Views, etc.) unter dem Administrationsuser SYS oder SYSTEM von Oracle anzulegen.
Erstens würden sie dann im SYSTEM Tablespace abgelegt, und der sollte tunlichst nicht mit Userobjekten „verseucht“ werden.
Zweitens ist es immer gut, eine Datenbank5 mit all ihren zugehörigen Objekten in einem eigenen „Schema“ anzulegen.
Daher benötigen wir zuallererst eine Art „Masteruser“ in der Datenbank, der über die nötigen Rechte verfügt, Tabellen und Views anlegen zu dürfen, andere User, etc. In der Datenbankwelt nennt man so einen User üblicherweise „Administrator“ oder „dba“ (Database-Administrator). Er hat einen Usernamen wie jeder andere Datenbankanwender, aber weit darüberhinausgehende Rechte. Wir nennen diesen User am besten so, wie auch unser Projekt heißt: VCO. Das installierte Oracle DBMS hat immer eine sogenannte „SID“. Die SID ist der Name, mit dem sie im Netzwerk erreicht werden kann. Nehmen wir mal an, dieser Name ist in unserem Falle „VCO“ – oder eben der Name, den wir der Oracle Datenbank bei der Installation gegeben haben.
Dazu legen wir uns in einem beliebigen Texteditor ein Script „01_User.sql“ an, das wie folgt aussieht:
rem 01_User.sql
rem 06.02.2019
rem Dipl. Ing. Guenter Leitenbauer
rem Erstellung des DBA Users
rem DBA User "VCO"
connect internal@VCO;
create user VCO identified by meinpasswort
default tablespace USERS
temporary tablespace TEMP;
grant dba to VCO;
Im Wesentlichen ist das selbsterklärend. Ein paar Punkte sollen dennoch erwähnt werden:
Groß-/Kleinschreibung ist für Befehle und Bezeichner in SQL/DML/DDL irrelevant.
Die Oracle DDL (Data Definition Language) ist eng an SQL angelehnt, Kommentare kann man mit „rem“ (Remark) oder auch mit zwei Minuszeichen „—“ beginnen. Der Rest der Zeile gilt dann als Kommentar.
Die folgende Zeile
connect internal@VCO;
veranlasst Oracle, den Benutzer „INTERNAL“ (dies ist ein bei der Installation standardmäßige angelegter Benutzer mit Administrationsrechten, allerdings geringeren als SYSTEM, den man auch verwenden könnte) an der SID (Datenbank) „VCO“ anzumelden. Oracle wird daraufhin mit einer Aufforderung zur Eingabe eines Passwortes reagieren.
create user VCO identified by meinpasswort
default tablespace USERS
temporary tablespace TEMP;
legt einen Datenbankuser VCO an, weist ihm das Passwort “meinpasswort6“ zu und definiert, dass alle Objekte, die dieser User anlegt, standardmäßig am Tablespace USERS abgelegt werden. Für alle temporären Objekte soll Oracle den Tablespace TEMP verwenden.
grant dba to VCO;
weist diesem User Administrationsrechte zu. Damit vermeiden wir, dem User jedes spezielle Recht einzeln zuweisen zu müssen, zum Beispiel zum Erzeugen von Tabellen. Es gibt zum Thema SQL/DML/DDL von Oracle Datenbanken jede Menge gute Literatur. Wir werden hier nicht alle Befehle immer Zeile für Zeile erklären, sondern setzen ein gewisses Maß an Wissen zu diesem Thema voraus.
2.1.3 Das Werkzeug SQL*Plus
Im SQL*Plus muss man sich zuerst anmelden:
Abb. 1: SQL*Plus Anmeldefenster
Danach meldet sich das Werkzeug in etwa wie folgt (hier die Version von Oracle 9.2):
Abb. 2: SQL*Plus Rückmeldung nach erfolgreichem Login
Nun kann man beliebige SQL, DML oder DDL Kommandos eintippen oder auch mit Copy & Paste einfügen. Das funktioniert auch für mehrzeilige Kommandos, weil in SQL ein Kommando erst dann abgeschlossen ist, wenn ein Semikolon gesetzt wird.
2.1.4 Datenbankrollen
Falls uns dieser Begriff jetzt nichts sagen sollte: Datenbankrollen sind gut vergleichbar mit den Benutzergruppen im Windows. Wir können den Begriff „Datenbankrolle“ oder kurz „Rolle“ daher mit „Benutzergruppe“ synonym verwenden. Diese Rollen haben einen großen Vorteil:
Wenn man alle Rechte in der Datenbank nicht den einzelnen Usern direkt zuweist, sondern den Rollen (und die Rollen dann den Benutzern), spart man in der Folge viel administrativen Aufwand ein, und bekommt als Belohnung auch noch ein übersichtliches Rechtekonstrukt.
Beispiel:
Der User „guenter“ soll das Recht bekommen, auf die Tabelle „T_PERSON“ lesend zuzugreifen. Dies würde man in Oracle mit folgendem Befehl erreichen können:
grant select on T_PERSON to guenter;
Irgendwann kommen weitere User dazu, zum Beispiel die Userin „susanne“. Dann muss man, wenn sie die gleichen Rechte wie „guenter“ haben soll, alle diese Grants auch für sie noch einmal durchführen. Das kann bei vielen Tabellen, Views und weiteren Datenbankobjekten, und vor allem bei vielen Usern, schnell in Arbeit ausarten. Erstellt wir uns also stattdessen eine Rolle, nennen wir sie „VCO_USER“ und weisen diese Rechte einmalig der Rolle zu:
create role VCO_USER identified by schonwiedereinpasswort;
grant select in T_PERSON to VCO_USER;
Nun können wir im Falle, dass wir einen neuen User benötigen, diesem einfach die Rolle zuweisen:
create user guenter identified by vcotest
default tablespace USERS
temporary tablespace TEMP;
grant VCO_USER to guenter;
Selbstverständlich kann man verschiedene Rollen mit verschiedenen Berechtigungen definieren. Man sollte das System allerdings möglichst einfach (und damit gut administrierbar) halten.
Anmerkung:
Die Berechtigungen in verschiedenen Oracle Rollen addieren sich, genau wie Windows-Benutzerrechte, zu einer Vereinigungsmenge aller Berechtigungen, wenn einem User mehrere Rollen zugewiesen werden.
Die Vorteile von Rollen beschränken sich allerdings nicht auf neu anzulegende User. Man kann nämlich Rollen auch ganz einfach wieder entziehen, wenn man einem User beispielsweise (temporär oder auf Dauer) die mit der Rolle verbundenen Rechte wegnehmen will:
revoke VCO_USER from guenter;
Die Vorteile dieser Rollen sollten hiermit erkennbar sein. Wir erweitern jetzt unser Script „01_User.sql“ also um folgende Einträge:
create role VCO_USER identified by schonwiedereinpasswort;
grant create session to VCO_USER;
grant alter session to VCO_USER;
Die beiden Grants gestatten es jedem User mit der Rolle „VCO_USER“, sich an unsere Datenbank zu konnektieren (eine Session zu eröffnen).
2.2 Die erste Tabelle
Wir sind jetzt so weit, unsere erste Datenbanktabelle anzulegen, müssen uns also Gedanken über das Datenmodell zu unserer Anwendung machen. Der Autor hat dazu 2003 ein Buch veröffentlich, das sich fast ausschließlich mit Datenmodellierung im kommerziellen Umfeld beschäftigt. Dieses Thema kann und soll daher hier nicht zum zentralen Inhalt werden. Wenn man Software testen möchte, wird man dazu jemanden brauchen, der die Testfälle schreibt, eine Person eben. Man wird auch jemanden brauchen, der die Tests durchführt, ebenfalls eine Person. Das weist uns auf die erste zu realisierende Datenbanktabelle hin, eine Personentabelle.
Tipp:
Man kann potenzielle Kandidaten für Datentabellen oft sehr einfach an den häufig vorkommenden Substantiven in einem Text identifizieren.
Damit man nicht von Anfang an Gefahr läuft, gerne und oft gemachte Fehler zu wiederholen, sollte man gewisse Richtlinien für die Datenmodellierung einhalten:
Richtlinien zur Datenmodellierung:
Bei der Realisierung von Datenbanktabellen gibt es einige „Quasinormen“, die man tunlichst einhalten sollte:
Tabellennamen sind immer im Singular
Es ist sinnvoll, Tabellen in einem Projekt mit einem vereinbarten Kürzel (in unserem Projekt mit „VCO_“) beginnen zu lassen
Der Primärschlüssel einer Tabelle sollte immer als numerischer Kunstschlüssen (z. B. fortlaufende Zahl) realisiert werden, das vereinfacht die Programmierung
Unsere Personentabelle könnte also wie folgt aussehen:
rem 020_CreateTables.sql
rem Dipl. Ing. Guenter Leitenbauer
rem Erstellung der Tabellen
rem DBA User "VCO"
rem Unser VCO muss angemeldet sein!
CREATE TABLE VCO_PERSON (
PersonIDNUMBERNOT NULL,NameVARCHAR2(40)NOT NULL,DBKennungVARCHAR2(32)NULL,VornameVARCHAR2(40)NOT NULL,TitelVARCHAR2(20)NULL,GeschlechtVARCHAR2(20)NOT NULL)
PCTFREE 10
TABLESPACE USERS
STORAGE ( INITIAL 10K )
;
Dabei sind die Angaben „PCTFREE“, „TABLESPACE“ und „STORAGE“ Parameter, die man problemlos auch weglassen kann. Sie dienen dazu, die neue Tabelle größenmäßig vorzugeben, wobei das aber keine Einschränkung darstellt. Oracle erweitert Tabellen selbständig, wenn sie den reservierten Platz zu einem gewissen Prozentsatz (100 minus PCTFREE) ausgeschöpft haben. Wir werden diese Storageparameter daher in Zukunft der Übersichtlichkeit halber weglassen.
Legen wir die Tabelle also in SQL*Plus an7:
Abb. 3: Tabelle in SQL*Plus anlegen
2.2.1 Der Primärschlüssel
In jeder Tabelle in einer relationalen Datenbank gibt es genau ein Attribut (dabei kann es sich auch um eine Attributkombination handeln), das als „Primärschlüssel“ fungiert. Primärschlüssel sind immer eindeutig. Das heißt, keine zwei Datensätze in einer Tabelle können den gleiche Primärschlüsselwert besitzen. Die Datenbank verhindert das beim Einfügen oder Ändern konsequent. Weiters kann man sogenannte „Indizes“ auf Tabellenspalten (oder Kombinationen von Spalten) legen, die die Suche beschleunigen. Bei Schlüsselattributen sollte man immer solche Indizes definieren, bei Spalten, nach denen man häufig sucht, ist es empfehlenswert. Wir legen also einen solchen Index8 an, und geben der Datenbank bekannt, welches Attribut in unserem Falle der Primärschlüssel ist:
-- Index fuer Primaerschluesselspalte
CREATE INDEX XIPK_VCO_PERSON ON VCO_PERSON
(
PersonID
)
TABLESPACE INDX
STORAGE ( INITIAL 20K )
;
-- PersonID als PK definieren
ALTER TABLE VCO_PERSON
ADD ( PRIMARY KEY (PersonID)
USING INDEX
TABLESPACE INDX
STORAGE ( INITIAL 20K )
);
Falls es in unserer Datenbank keinen eigenen Tablespace „INDX“ geben sollte, verwenden wir statt „INDX“ einfach „USERS“.
2.2.2 Öffentliche Namen (public synonyms)
Damit haben wir unsere erste Tabelle erfolgreich erzeugt. Allerdings ist sie im Moment noch nur für den User VCO sichtbar, wir benötigen daher noch einen öffentlichen Namen:
CREATE PUBLIC SYNONYM VCO_PERSON for VCO.VCO_PERSON;
SQL*Plus sollte uns das mit der folgenden Meldung bestätigen:
SQL> CREATE PUBLIC SYNONYM VCO_PERSON for VCO.VCO_PERSON;
Synonym wurde angelegt.
SQL>
Und spätestens jetzt verstehen wir auch, warum wir allen Tabellen, Views, etc. in diesem Projekt ein „VCO_“ voranstellen:
Öffentliche Namen (public synonyms) müssen eindeutig sein, dürfen also nicht doppelt vorkommen. Die Wahrscheinlichkeit, dass es eine Tabelle „PERSON“ innerhalb einer Datenbank aber schon gibt, ist umso größer, je mehr Projekte diese Datenbank nutzen.
2.2.3 Zugriffsrechte auf Tabellen
Die eben erzeugte Tabelle ist nun zwar allgemein sichtbar (in ihrer Existenz), das heißt aber noch lange nicht, dass darauf auch jedermann zugreifen kann9. Dieses Recht muss in Oracle gesondert gesetzt werden. Wir ergänzen daher unser Script noch einmal um eine weitere Zeile:
GRANT ALL on VCO_PERSON to VCO_USER;
SQL*Plus bestätigt uns die Vergabe des Zugriffsrechtes auf diese Tabelle:
SQL> GRANT ALL on VCO_PERSON to VCO_USER;
Benutzerzugriff (Grant) wurde erteilt.
SQL>
Man kann dabei verschiedene Rechte vergeben. Von Bedeutung sind vor allem zwei Rechte:
GRANT ALL
Ermöglicht lesenden, ändernden, löschenden und einfügenden Zugriff.
GRANT SELECT
Ermöglicht nur lesenden Zugriff.
Man beachte, dass wir diese Berechtigung der Rolle „VCO_USER“ und nicht etwa bestimmten Anwendern zugewiesen haben!
2.3 Ein erster Datensatz
Eine Tabelle ohne einen einzigen Datensatz (Record, Row) ist von keinem großen Nutzen. Da wir noch keine Anwendung haben, die einen solchen Datensatz einfügen kann, werden wird das manuell machen. Auch wenn das vorliegende Werk kein Lehrbuch zum Thema SQL sein kann oder sein will, sei das entsprechende Statement hier angeführt:
INSERT INTO VCO_PERSON
(PersonID, Name, DBKennung, Vorname, Titel, Geschlecht)
VALUES (1, 'Leitenbauer', 'guenter', 'Günter', 'Dipl. Ing.', 'm');10
Man kann zwar die Spaltenbezeichnungen weglassen, dann muss man allerdings die Werte (VALUES) in der korrekten Reihenfolge und vollständig angeben. Es ist daher immer besser, die Spaltenbezeichnungen (Inhalt der ersten Klammer) explizit anzuführen. Wenn man obiges Statement in SQL*Plus eingibt, sollte man folgende Rückmeldung bekommen:
1 Zeile wurde erstellt.
SQL>
Das ist (noch) eine temporäre Zeile, die erst dann in die Datenbank übernommen wird, wenn wir die Änderung bestätigen:
commit;
Daraufhin bekommen wir folgende Rückmeldung der Datenbank:
Transaktion mit COMMIT abgeschlossen.
SQL>
Falls wir beim INSERT einen Fehler gemacht haben, können wir, anstatt zu bestätigen, auch alles rückgängig machen:
rollback;
Daraufhin bekämen wir dann folgende Rückmeldung der Datenbank:
Transaktion mit ROLLBACK rückgängig gemacht.
SQL>
Wenn man einmal ein commit abgesetzt hat, sind die Änderungen fix in der Datenbank. Es gibt dann kein Undo oder Rollback mehr. Man sollte also die Rückmeldungen der Datenbank nach jedem Statement genau lesen, bevor man sein commit absetzt!
2.4 Zu guter Letzt – eine Datenbankabfrage
Wir können nun überprüfen, was in unserer neu erstellten und mit einem Datensatz befüllten Tabelle enthalten ist, indem wir eine Datenbankabfrage mittels SELECT durchführen:
SELECT Name, Vorname
FROM VCO_PERSON;
Die Datenbank liefert uns (hoffentlich) etwas in der Art:
2.5 Zusammenfassung
Wir haben in diesem Kapitel gelernt,
einen Datenbankuser anzulegen
was Datenbankrollen sind und wie man sie anlegt
wie man Rechte auf der Datenbank sinnvoll zuweist (über Datenbankrollen, die den Benutzern zugewiesen und entzogen werden können)
wie man einen Datenbankanwender anlegt und ihm eine Rolle zuweist.
was öffentliche Synonyme sind, wozu man sie verwendet und wie man sie anlegt
wie man einen Datensatz einfügt
wie man die Datensätze einer Tabelle abfragt
Im nächsten Kapitel wird es nun auch in Bezug auf die Programmierung der Datenbankanwendung in C++ ernst. Wir werden uns jetzt daran machen, eine erste kleine Anwendung zu schreiben, mit der wir uns an die Datenbank anmelden und Datensätze aus der obigen Personentabelle abfragen können.
3 An dieser Stelle sei darauf hingewiesen, dass die hier gezeigten Mechanismen selbstverständlich auch auf andere DBMS-Produkte anwendbar sind. Allerdings sind dann speziell bei den Datenbankzugriffsklassen entsprechende Anpassungen nötig.
4 Wenn man die Datenbank neu installieren muss, weil man vielleicht noch keine Installation hat, sollte man auf jeden Fall die vom Oracle Installer vorgeschlagenen Standardparameter und Standardverzeichnisse beibehalten. Das spart Nerven und verhindert Probleme!
5 Die Begriffe „Datenbank“ und „Datenbankmanagementsystem“ (DBMS) beschreiben nicht das Gleiche. Oracle ist ein DBMS, also eine Software, die eine oder mehrere Datenbanken verwalten kann. Eine Datenbank ist dabei eine zusammengehörige Menge von Datenbankobjekten wie Tabellen, Views, User, etc.
6 Sie sollten dieses Passwort nicht verwenden oder nach der Erstellung des Anwenders ändern. Das Passwort eines Users ändert man in Oracle mit dem Befehl „alter user VCO identified by xxx;“, wobei statt xxx dann das neue Passwort eingetippt wird.
7 In Zukunft werden wir meist nur noch die Scripts respektive Kommandos anführen. Wie man sie in SQL*Plus ablaufen lässt, sollte mit obiger Erläuterung nun klar sein.
8 Diese Indizes kann man frei benennen, wir benennen unsere hier „XIPK_VCO_PERSON“ (XI für Index, PK für Primary Key und dann den Tabellennamen).
9 Oracle unterscheidet sehr genau zwischen „Sichtbarkeit“ und „Zugriff“.
10 In relationalen Datenbanken werden Zeichenketten nicht in doppelte sondern in einfache Hochkommas eingeschlossen.
3 Visual Studio C++ - der Einstieg
Microsoft hat mit Visual Studio in der aktuellen Version ein wirklich fantastisches Werkzeug am Markt. Dem geht natürlich eine lange Geschichte voraus, die uns hier aber nicht interessiert. Wichtig ist vielmehr, dass man mit den derzeit erhältlichen Versionen (wir verwenden MS Visual Studio 2017, ab jetzt kurz „VS“) sehr zielgerichtet und gut arbeiten kann, wenn man einige Untiefen umschifft.
3.1 Welche Version von VS soll man installieren?
Wenn man die Downloadseite11 von VS besucht, bekommt man drei mögliche Lizensierungsvarianten angezeigt:
Abb. 4: MS Visual Studio Lizenzmodelle
Wo liegen die Unterschiede?
Um es kurz zu machen: Die funktionalen Unterschiede der Gratisversion zu den kostenpflichtigen Versionen liegen in erster Linie im Bereich „Teamentwicklung“, „Debugging“ und „Softwaretest“. Für Einzelentwickler und kleine Teams (bis maximal fünf Entwickler) gibt es in der kostenlos erhältlichen Version keine für uns relevanten Einschränkungen. Es ist allerdings zu beachten, dass man im Bereich der kommerziellen Programmentwicklung auf jeden Fall eine kostenpflichtige Version von VS benötigt.
Fazit: Wir installieren uns für unser Projekt die Community Version von Visual Studio 2017.
3.2 Was ist bei der Installation von VS zu beachten?
Eigentlich nicht viel. Die Standardinstallation reicht völlig, man sollte nur darauf achten, die Programmiersprache C++ nicht abzuwählen. Ob man die anderen Programmiersprachen wie C# oder Visual Basic auch installiert, hängt nur davon ab, ob man sie in anderen Projekten benötigt oder nicht.
Tipp:
Wenn man keine gewichtigen Gründe hat, sollte man bei Installationen immer die Voreinstellungen belassen. Erfahrungsgemäß spart das in der Folge Ärger.
Die Installation von Visual Studio wird in diesem Buch nicht beschrieben. Wir gehen in der Folge davon aus, dass die Entwicklungsumgebung korrekt installiert worden ist12.
3.3 Das Projekt wird erstellt
Visual Studio verwendet den Begriff „Projekt“ für ein zusammengehörendes Ensemble von Sourcen, Ressourcendateien, Makefiles, etc., sodass man in der Folge beim Öffnen der Entwicklungsumgebung stets nur einen Klick auf die entsprechende Projektdatei benötigt, um die gesamte Entwicklungsumgebung exakt in dem Zustand wieder vorzufinden, indem man sie zuletzt beendet hat. Das ist äußerst praktisch und benutzerfreundlich, muss man sich so doch nicht einmal merken, wo man die Arbeit am Vortag beendet hatte. Visual Studio kann dabei mehrere Projekte verwalten, und man kann zudem mehrere Instanzen von Visual Studio zugleich geöffnet haben. Das ist hilfreich, wenn man ein Beispielprojekt dazu benutzen möchte, um Fehler im eigenen Projekt zu beheben oder Änderungen darin durchzuführen.
Wenn man Visual Studio startet, werden die zuletzt verwendeten Projekte angezeigt, wobei man Projekte, die man nicht oft benötigt, auch ausblenden kann. Man muss dann nur noch das entsprechende Projekt anklicken – oder ein neues erzeugen:
Abb. 5: MS Visual Studio 2017 Startbildschirm
Unter „Zuletzt verwendet“ sieht man eventuell schon existierende Projekte, hier z. B. „UDOY.sln“. Dabei ist „UDOY“ der Projektname und „.sln“ die Dateierweiterung für „(Visual Studio) Solution“. Wir klicken hier aber kein bestehendes Projekt an, sondern erzeugen über den Punkt „Neues Projekt“ (rechts) und den Unterpunkt „MFC Anwendung“ ein neues Projekt (die blaue Schrift zeigt den ausgewählten Typ an):
Abb. 6: MS Visual Studio 2017 Projekttyp wählen
Daraufhin öffnet sich ein weiterer Auswahldialog, in dem wir die Art der Anwendung auswählen und den Projektnamen sowie den Speicherort festlegen können, wie im folgenden Bild gezeigt:
Abb. 7: MS Visual Studio 2017 Projektgrunddaten
Wir wählen natürlich als Projekttyp „MFC Anwendung“. Wir wollen ein Programm erstellen, keine DLL und auch kein ActiveX-Steuerelement. Der Projektpfad ist in unserem Falle „D:\VCO“. Man kann aber natürlich jeden Pfad verwenden.
Netzwerkpfade sind natürlich flexibler, weil man dann auch auf verschiedenen Rechnern im Netzwerk entwickeln kann und weil man in einer Netzwerkumgebung üblicherweise Netzwerklaufwerke sichern lassen kann.
Allerdings hat die Entwicklung auf einem lokalen Laufwerk (wie oben) auch Vorteile, vor allem in der Geschwindigkeit.
Unten rechts sieht man eine Checkbox13 „Neues Git-Repository erstellen“. Was hat es damit auf sich?
Git ist ein einfaches Versionskontrollsystem. Das heißt, dass das System auf Benutzerwunsch von einem Entwicklungsstand einen Snapshot (Schnappschuss) anlegt, also alle zugehörigen Dateien archiviert. Diese sind dann jederzeit wiederherstellbar, zum Beispiel, wenn man sich im Zuge einer Entwicklung „verlaufen“ hat oder Dateien irrtümlich gelöscht hat. Der Hauptunterschied zwischen Git und anderen Versionskontrollsystemen besteht in der Art, wie Git Daten betrachtet. Viele andere Systeme speichern Information als eine fortlaufende Liste von Änderungen an Dateien (Differenzspeicherung). Diese Systeme (SCCS, CVS, Subversion, Perforce, usw.) betrachten die Informationen, die sie verwalten, als eine Menge von Dateien und die Änderungen, die über die Zeit hinweg an einzelnen Dateien vorgenommen werden.
Git geht einen anderen (einfacheren, aber auch unflexibleren) Weg. Git betrachtet seine Daten als eine Reihe von Snapshots eines Minidateisystems. Jedes Mal, wenn der Anwender den gegenwärtigen Status des Projekts als eine Version in Git speichert, sichert Git den Zustand sämtlicher Dateien in diesem Moment als „Snapshot“ und speichert einen Verweis auf diesen Snapshot. Um dies möglichst effizient und schnell tun zu können, kopiert Git unveränderte Dateien nicht etwa, sondern legt lediglich eine Verknüpfung zu der vorherigen Version der Datei an. Trotzdem wächst natürlich in Abhängigkeit von der Anzahl der Snapshots der Speicherbedarf entsprechend an. Um dieses Buch nicht mit zusätzlicher Komplexität zu belasten, die dem eigentlichen Ziel nichts Essentielles hinzufügen würde, werden wir Git hier deaktivieren, die Checkbox also abwählen (kein Haken gesetzt).
Damit sind die Grunddaten definiert. Mit einem Klick auf den Button „OK“ legt Visual Studio das Projekt nun an, will aber vorher noch einige weitere Informationen. Dazu öffnet Visual Studio folgenden Dialog:
Abb. 8: MS Visual Studio 2017 Weitere Projektgrunddaten
Diese Einstellungen bedürfen einer Erläuterung, vor allem die Combobox „Anwendungstyp“.
3.3.1 MFC in der Nussschale
Was ist eigentlich dieses „MFC“?
MFC steht für „Microsoft Foundation Classes” und war ursprünglich eine reine Klassenbibliothek, also eine Hierarchie vorgefertigter Klassen zur Erleichterung der Programmierung von Windows. Diese Bibliothek basierte (und tut das noch) auf einer gemeinsamen Basisklasse „CObject“. Davon abgeleitet waren Klassen für wichtige Datentypen (wie Zeichenketten oder Felder), und auch Das Document-View-Konzept und das so genannte OLE (Object Linking and Embedding) waren schon integriert. Später hat Microsoft diese Bibliothek zu einem kompletten Anwendungsgerüst erweitert. Dies beinhaltete Windowsfensterklassen, Steuerelementklassen, Unterstützung für das Öffnen, Speichern und Drucken von Dokumenten (Dateien) und vieles mehr. In der Folge wurden weitere Klassen integriert. Dies umfasst Klassen zur Anbindung von Datenbanken mit ODBC, Klassen für ActiveX, Unterstützung von http-Protokollen, etc.
Man könnte MFC vielleicht am besten als Gerüst zur Erstellung verschiedenster Windowsanwendungen bezeichnen, mit dem man eine Basisanwendung, die viele typische Windowsfunktionalitäten schon beinhaltet, mit sehr wenig Aufwand erstellen kann, um diese dann mit der speziellen Funktionalität auszustatten, die man benötigt.
3.3.2 SDI und MDI Document/View Architektur
Anwendungen, die die Bearbeitung von Dokumenten wie beispielsweise Texten oder Tabellen erlauben, haben sehr viele Funktionalitäten, die sich von Anwendung zu Anwendung nicht oder nur geringfügig ändern. Man könnte also sagen: Sie folgen einem Muster. Tatsächlich nennt man diese Muster „Designmuster“ oder englisch „Design Patterns“. Das Document-View-Modell ist so ein Designmuster. Es ist vom Muster „Model-View-Controller“ abgeleitet und beschreibt die immer wieder gleichartigen Vorgangsweisen in solchen Programmen:
Im Dokument werden dabei Daten gespeichert. In der View werden sie angezeigt und/oder bearbeitet. Die Trennung ist sehr wichtig, entkoppelt sie doch die (objektiven) Daten von den (durchaus verschiedenen) Anforderungen der Darstellung und Bearbeitung. Wir kennen alle typische Programme mit dieser Architektur: Wenn man in Word eine Datei öffnet, beinhaltet die Datei die Daten, die dem Anwender in verschiedenen Views zur Bearbeitung dargeboten werden. Es gibt eine Entwurfsansicht, eine Gliederungsansicht, eine Seitenansicht, und so weiter. Jede Änderung in einer dieser Views ändert die zugrundeliegenden Daten. Beim Wechsel in eine andere Ansicht sind diese Änderungen in jeder Ansicht sofort aktuell.
So weit, so gut. Was ist nun SDI, und was ist MDI?
SDI steht für „Single Document Interface“. Bei SDI-Anwendungen kann immer nur genau ein Dokument in der Anwendung geöffnet sein. Ein Beispiel dafür ist Microsoft Paint.
MDI steht für „Multiple Document Interface“. Hier kann eine Anwendung mehrere Dokumente zugleich im geöffneten Zustand bearbeiten. Ein Beispiel dafür wäre Microsoft Word.
3.3.3 SDI oder MDI für unser Projekt?
Da wir eine Datenbankanwendung realisieren möchten, ist eigentlich keines der beiden Konzepte für uns passend. Wir haben ja kein „Dokument“ im eigentlichen Sinne. Allerdings sind fast alle anderen Funktionalitäten, die uns MFC bietet, wie für uns gemacht. Wir sehen also über den unwesentlichen Punkt hinweg, dass wir keine Dokumente bearbeiten und wählen daher die einfachere Variante, also SDI14.
Im unter der letzten Abbildung angezeigten Dialog erreichen wir das mit der Auswahl „Einfaches Dokument“ in der Combobox „Ansichtstyp“. Die weiteren Einstellungen lassen wir, wie sie nach der Installation von Visual Studio standardmäßig vorgeschlagen werden:
Die Checkbox „Unterstützung für die Dokument/Ansichtsarchitektur“ lassen wir angewählt.
Die Checkbox „Security Development Lifecycle-Prüfungen (SDL)” lassen wir ebenfalls angewählt. Sie führt nur dazu, dass beim Kompilieren und zur Laufzeit mehr Fehler gefunden werden. Man kann sie später auch sehr einfach abschalten.
Die Combobox „Unterstützung für Verbunddokumente“ belassen wir auf der Auswahl „<keine>“. Microsoft schreibt dazu: „Gibt an, dass Object Linking and Embedding (OLE) nicht unterstützt wird. Der Anwendungs-Assistent erstellt standardmäßig eine Anwendung ohne ActiveX-Unterstützung.“ Wenn wir keine OLE-Unterstützung brauchen, sollten wir uns also damit auch nicht belasten.
Die Combobox „Projektstil“ setzen wir auf „Visual Studio“. Das erlaubt uns im Gegensatz zu „MFC Standard“ die Verwendung andockbarer Bereiche, etc. – kurz: eine moderner wirkende Anwendung. Etwas komplizierter, aber auch modern wirkend wäre „Office“.
