8 Datenbank-Anwendungen mit ADO.NET

Wollen Sie große Datenmengen dauerhaft und geordnet speichern,
dann kommen Sie an Datenbanken nicht vorbei.

Falls Sie noch nicht mit relationalen Datenbanken vertraut sind, liefert Ihnen der erste Abschnitt dieses Kapitels das nötige Hintergrundwissen. Anderenfalls können Sie diesen Teil überspringen und gleich zum Abschnitt 8.2 übergehen.

8.1 Was sind relationale Datenbanken?

Beim relationalen Datenmodell werden die Daten in Form von Tabellen angeordnet. Eine den Erfordernissen der Praxis genügende Datenbank wird sich aber kaum in einer einzigen Tabelle organisieren lassen. Sie wird vielmehr aus mehreren Tabellen bestehen, die miteinander in Beziehung (Relation) stehen. Eine solche Datenbank bezeichnet man als relational.

Sowohl die Tabellen als auch die Relationen lassen sich sehr einfach auf den physikalischen Speicher abbilden. Der Nachteil einer relationalen Datenbank besteht darin, dass zusätzliche Hilfsdatenstrukturen, sogenannte Indizes, aufgebaut und ständig aktualisiert werden müssen. Diese Indizes erleichtern die Abfrage, Suche und Sortierung in relationalen Datenbanken.

Je größer und komplexer eine Datenbank wird, desto mehr überwiegen jedoch die Vorteile der klaren Strukturierung der Daten und der Speicherplatz-Einsparung gegenüber dem Nachteil durch den Aufbau und die Aktualisierung der Indizes.

8.1.1 Beispiel »Lager«

Als anschauliches Beispiel für den Entwurf einer Datenbank soll die Erfassung des Lagerbestands eines Einzelhändlers dienen. Die Artikel des Lagers sollen durch die Daten aus Tabelle 8.1 gekennzeichnet werden.

Tabelle 8.1 Artikeldaten

Beschreibung	Abkürzung
eigene Artikelnummer	artnr
Bestellnummer für diesen Artikel beim Lieferanten	bestnr
vorhandene Anzahl	anz
Lieferantennummer	lnr
Adresse des Lieferanten	adr
Telefonnummer des Lieferanten	telnr
Regional-Vertreter des Lieferanten	vertr
Einkaufspreis	ek
Verkaufspreis	vk

Erster Entwurf

Im ersten Entwurf für eine solche Datenbank werden die Daten in einer Tabelle mit dem Namen artikel gespeichert, siehe Tabelle 8.2.

In diesem Beispiel sind acht verschiedene Artikel im Lager, zu jedem dieser Artikel existiert in der Tabelle eine Zeile. Eine solche Zeile in einer Datenbanktabelle wird Datensatz genannt. Die Spalten einer Datenbanktabelle nennt man Felder, sie werden durch ihre Überschrift, den Feldnamen, gekennzeichnet.

Alle Artikel sind innerhalb einer Tabelle abgelegt. Dies wirkt auf den ersten Blick sehr übersichtlich, man erkennt allerdings schnell, dass viele Daten mehrfach vorhanden sind. Bei jedem Artikel des gleichen Lieferanten sind Adresse, Telefonnummer und Vertreter in jedem Datensatz erfasst. Es ergibt sich eine Datenredundanz, d. h. viele Daten sind überflüssig. Außerdem können sich schnell inkonsistente, uneinheitliche Daten ergeben, falls die Telefonnummer eines Lieferanten sich ändert und diese Änderung nur in einem Datensatz eingetragen wird.

Tabelle 8.2 Erster Entwurf

artnr	Bestnr	anz	lnr	adr	telnr	vertr	ek	vk
12	877	5	1	Köln	162376	Mertens	23	35
22	231	22	3	Koblenz	875434	Mayer	55	82
24	623	10	4	Bonn	121265	Marck	12	18
30	338	30	12	Aachen	135543	Schmidt	77	116
33	768	5	1	Köln	162376	Mertens	90	135
56	338	2	1	Köln	162376	Mertens	125	190
58	338	16	3	Koblenz	875434	Mayer	50	74
76	912	15	12	Aachen	135543	Schmidt	45	70

Zweiter Entwurf

Daher geht man dazu über, den Lagerbestand in zwei Tabellen abzulegen, die miteinander verbunden sind. Die reinen Artikeldaten werden in der ersten Tabelle mit dem Namen artikel gespeichert. Die Felder sieht man in Tabelle 8.3.

Tabelle 8.3 Zweiter Entwurf, Artikel

artnr	bestnr	anz	lnr	ek	Vk
12	877	5	1	23	35
22	231	22	3	55	82
24	623	10	4	12	18
30	338	30	12	77	116
33	768	5	1	90	135
56	338	2	1	125	190
34658	346338	34616	3463	34650	34674
34676	346912	34615	34612	34645	34670

Die zweite Tabelle lieferanten enthält nur die Daten zu den einzelnen Lieferanten. Die Felder sieht man in Tabelle 8.4.

Tabelle 8.4 Zweiter Entwurf, Lieferanten

lnr	adr	telnr	Vertr
1	Köln	162376	Mertens
3	Koblenz	875434	Mayer
4	Bonn	121265	Marck
12	Aachen	135543	Schmidt

Außer den beiden Tabellen wird noch eine sogenannte 1:n-Relation aufgebaut. Diese Relation (= Beziehung, Verknüpfung) wird zwischen den beiden Feldern mit dem Namen lnr in den beiden Tabellen geknüpft. In Abbildung 8.1 sind die beiden Tabellen mit ihren Feldnamen und der Verknüpfung dargestellt.

Abbildung 8.1 Relation zwischen Lieferanten und Artikeln

Um also die vollständige Information über einen Artikel zu erhalten, müssen Sie zuerst den Datensatz innerhalb der Tabelle artikel aufsuchen und anschließend über das Feld lnr den zugehörigen Datensatz in der Tabelle lieferanten beachten. Auf diese Weise werden redundante Informationen vermieden und Sie können einen erheblichen Teil an Speicherplatz einsparen.

Diese beiden verknüpften Tabellen werden, zusammen mit einem geeigneten Abfragesystem zum schnellen Auffinden und Auswerten der Daten, als relationales Datenbanksystem bezeichnet. Zu einem solchen System gehören Indizes und Relationen.

8.1.2 Indizes

Ein Index ist eine sortierte Hilfstabelle, in der sich die indizierten Felder in der entsprechenden, sortierten Reihenfolge befinden. Außerdem steht hier ein Verweis auf den Ort des zugehörigen Datensatzes. Wenn das Datenbanksystem beim Suchen oder Sortieren einen Index benutzen kann, können effizientere Verfahren angewendet werden, weil nicht Satz für Satz der Tabelle verarbeitet werden muss. Dies bringt besonders bei großen Tabellen Geschwindigkeitsvorteile.

Da für jeden Index Speicherplatz benötigt wird, wächst die Datenbank entsprechend. Außerdem müssen die Index-Hilfstabellen beim Eingeben und Ändern der Daten aktualisiert werden, was die Geschwindigkeit beim Bearbeiten der Daten verlangsamt. In diesem Zusammenhang sind die Begriffe Primärindex und Sekundärindex von Bedeutung.

Primärindex

Jede Tabelle kann ein Feld aufweisen, das als Primärindex dient. In einem Primärindexfeld ist jeder Wert einzigartig, d. h. zwei Datensätze haben niemals den gleichen Wert im Primärindexfeld. Diese Eigenschaft wird vom Datenbanksystem überwacht, wenn Sie ein Feld oder eine Gruppe von Feldern als Primärindex definieren. Über das Primärindexfeld kann jeder Datensatz eindeutig identifiziert werden.

Ein Beispiel aus dem vorigen Abschnitt: Innerhalb der Tabelle artikel versehen Sie sinnvollerweise das Feld artnr mit einem Primärindex. Jede Artikelnummer sollte in dieser Tabelle nur einmal vorkommen. Innerhalb der Tabelle lieferanten versehen Sie das Feld lnr mit einem Primärindex.

Sekundärindex

Wird für ein Feld oder eine Gruppe von Feldern die Eigenschaft Sekundärindex vereinbart, kann mehrfach derselbe Feldinhalt vorkommen. Eine eindeutige Identifizierung eines Datensatzes ist also über einen Sekundärindex nicht möglich. Trotzdem empfiehlt es sich, Sekundärindizes anzulegen, wenn schnellere Sortierung oder schnelleres Suchen nach diesen Feldern möglich sein sollen.

Ein Beispiel aus dem vorigen Abschnitt: Innerhalb der Tabelle lieferanten versehen Sie z. B. das Feld adr mit einem Sekundärindex. Dadurch ermöglichen Sie das schnelle Sortieren der Tabelle nach Adressen, bzw. das schnelle Suchen nach einer bestimmten Adresse.

8.1.3 Relationen

Wenn Sie mehrere Tabellen haben, werden diese meist in einer Relation (= Beziehung) zueinander stehen. Das Datenbanksystem ermöglicht das Festlegen der Relationen zwischen je zwei Tabellen, um diese miteinander zu verknüpfen.

Eine 1:1-Relation

Eine 1:1-Relation liegt dann vor, wenn einem Datensatz der einen Tabelle genau ein Datensatz der zweiten Tabelle zugeordnet ist. Die Verknüpfungsfelder müssen in beiden Tabellen eindeutig sein. Im Prinzip könnten Sie zwei Tabellen, die zueinander in einer 1:1-Relation stehen, zu einer einzigen Tabelle zusammenfassen. Es kann aber Gründe geben, die das Führen von zwei Tabellen notwendig machen, z. B. Datenschutz-Erfordernisse.

Im Beispiel aus dem vorigen Abschnitt könnten Sie die Daten des ersten Entwurfs auch in zwei Tabellen anordnen, die über das Feld lnr miteinander verbunden sind. Beide Tabellen haben acht Datensätze, zu jedem Datensatz in der ersten Tabelle gibt es genau einen Datensatz in der zweiten Tabelle.

Die persönlichen Daten eines Lieferanten, die in einer eigenen Tabelle stehen (siehe Tabelle 8.6), können so von den Daten des Artikel-Lagers getrennt werden (siehe Tabelle 8.5). Falls Sie für einzelne Benutzer nur den Zugriff auf die Artikeltabelle ermöglichen, haben Sie an dieser Stelle den Datenschutz gewährleistet, ohne die Funktion der Artikel-Verwaltung zu beeinträchtigen.

Tabelle 8.5 1:1-Relation, erste Tabelle

artnr	Bestnr	anz	lnr	ek	vk
12	877	5	1	23	35
22	231	22	3	55	82
24	623	10	4	12	18
30	338	30	12	77	116
33	768	5	1	90	135
56	338	2	1	125	190
58	338	16	3	50	74
76	912	15	12	45	70

Tabelle 8.6 1:1-Relation, zweite Tabelle

lnr	Adr	telnr	vertr
1	Köln	162376	Mertens
3	Koblenz	875434	Mayer
4	Bonn	121265	Marck
12	Aachen	135543	Schmidt
1	Köln	162376	Mertens
1	Köln	162376	Mertens
3	Koblenz	875434	Mayer
12	Aachen	135543	Schmidt

Eine 1:n-Relation

Bei einer 1:n-Relation können zu einem Datensatz der ersten Tabelle mehrere Datensätze der zweiten Tabelle vorliegen, die sich darauf beziehen. In einem Datenbanksystem wird die Tabelle der 1-Seite auch als Mastertabelle für diese Relation bezeichnet, die Tabelle der n-Seite wird auch Detailtabelle genannt.

Im Beispiel aus dem vorigen Abschnitt sind die Daten über eine solche 1:n-Relation miteinander verbunden. Die Mastertabelle für diese Relation ist die Tabelle der Lieferanten, die Detailtabelle ist die Tabelle der Artikel.

Eine m:n-Relation

Bei einer m:n-Relation entsprechen einem Datensatz der ersten Tabelle mehrere Datensätze der zweiten Tabelle, aber auch umgekehrt entsprechen einem Datensatz der zweiten Tabelle mehrere Datensätze der ersten Tabelle. Eine m:n-Relation lässt sich nicht unmittelbar, sondern nur über den Umweg einer dritten Tabelle definieren.

Um eine Datenbank mit einer m:n-Relation darzustellen, muss das einfache Beispiel aus dem vorigen Abschnitt erweitert werden. Bisher konnte ein Artikel nur von einem Lieferanten bezogen werden. Im neuen Beispiel soll es die Möglichkeit geben, einen Artikel unter unterschiedlichen Bestellnummern bei verschiedenen Lieferanten zu beziehen. Die Tabelle artikel würde erweitert, wie in Tabelle 8.7 zu sehen.

Tabelle 8.7 Tabelle »Artikel«, unterschiedliche Lieferanten

artnr	bestnr	anz	lnr	ek	vk
12	877	3	1	23	35
12	655	2	4	26	35
22	231	22	3	55	82
24	623	10	4	12	18
30	338	30	12	77	116
33	768	5	1	90	135
56	338	2	1	125	190
58	338	3	3	50	74
58	442	5	1	47	74
58	587	6	4	42	74
58	110	2	12	55	74
76	912	15	12	45	70

Sowohl der Artikel 12 als auch der Artikel 58 sind unter unterschiedlichen Bestellnummern und Einkaufspreisen bei verschiedenen Lieferanten zu beziehen. Die Tabelle artikel hat nun keinen Primärindex mehr im Feld artnr, da eine Artikelnummer mehrfach vorkommen kann.

Diese Daten legen Sie zur besseren Strukturierung in den folgenden drei Tabellen an:

• Tabelle lieferanten mit den Lieferantendaten
• Tabelle art_einzel mit den unterschiedlichen Daten pro Artikel und Lieferant
• Tabelle art_gesamt mit den gemeinsamen Daten der Artikel

Tabelle 8.8 Tabelle »lieferanten«

lnr	adr	telnr	vertr
1	Köln	162376	Mertens
3	Koblenz	875434	Mayer
4	Bonn	121265	Marck
12	Aachen	135543	Schmidt

Tabelle 8.9 Tabelle »art_einzel«

artnr	bestnr	anz_einzel	lnr	ek
12	877	3	1	23
12	655	2	4	26
22	231	22	3	55
24	623	10	4	12
30	338	30	12	77
33	768	5	1	90
56	338	2	1	125
58	338	3	3	50
58	442	5	1	47
35258	352587	3526	3524	35242
35258	352110	3522	35212	35255
35276	352912	35215	35212	35245

Tabelle 8.10 Tabelle »art_gesamt«

artnr	vk
12	35
22	82
24	18
30	116
33	135
56	190
58	74
76	70

Die Tabelle lieferanten ist über das Feld lnr mit der Tabelle art_einzel über eine 1:n-Relation verbunden. Die Tabelle art_gesamt ist über das Feld artnr mit der Tabelle art_einzel ebenfalls über eine 1:n-Relation verbunden.

Zwischen den beiden Tabellen lieferanten und art_gesamt gibt es eine m:n-Relation, da es zu jedem Lieferanten mehrere Artikelnummern und zu jeder Artikelnummer mehrere Lieferanten geben kann.

Primärindizes gibt es in der Tabelle lieferanten auf lnr und in der Tabelle art_gesamt auf artnr, siehe Abbildung 8.2.

Abbildung 8.2 Zwei 1:n Relationen, ergeben eine m:n-Relation

8.1.4 Übungen

Bei den nachfolgenden Übungen sollen eigene, relationale Datenbanken übersichtlich auf Papier modelliert werden. Vermeiden Sie dabei Redundanzen und Inkonsistenzen. Kennzeichnen Sie Primärindizes und gegebenenfalls Sekundärindizes. Zeichnen Sie 1:n-Relationen und (falls vorhanden) m:n-Relationen ein.

Übung »Projektverwaltung«

Modellieren Sie eine eigene, relationale Datenbank projektverwaltung zur Verwaltung von Personal, Kunden und Projekten innerhalb einer Firma. Folgende Basis-Informationen stehen Ihnen zur Verfügung und sollen in der Datenbank verfügbar sein:

• Ein Mitarbeiter hat Name, Vorname und Personalnummer.
• Ein Kunde hat einen Namen und kommt aus einem Ort.
• Ein Projekt hat eine Bezeichnung und eine Projektnummer und ist einem Kunden zugeordnet.
• Ein Mitarbeiter kann an mehreren Projekten innerhalb der Firma beteiligt sein.
• Ein Projekt kann von einem oder mehreren Mitarbeitern bearbeitet werden.
• Jeder Mitarbeiter notiert jeden Tag, wie viele Stunden er für welches Projekt gearbeitet hat.

Übung »Mietwagen«

Modellieren Sie eine eigene, relationale Datenbank mietwagen zur Verwaltung einer Mietwagenfirma. Folgende Basis-Informationen stehen Ihnen zur Verfügung und sollen in der Datenbank verfügbar sein:

• Ein Fahrzeug hat eine Fahrgestellnummer, ein Kfz-Kennzeichen, gehört zu einer Preisklasse, hat einen Kilometerstand und einen Standort.
• Die Mietwagenfirma hat mehrere Standorte. Gemietete Fahrzeuge können nur an der gleichen Station zurückgegeben werden.
• Ein Kunde hat einen Namen, einen Vornamen, eine Adresse und eine Kundennummer. Er kann beliebig oft Fahrzeuge mieten.
• Bei einem Mietvorgang sind wichtig: Zeitpunkt (Beginn und Ende), gewünschte Preisklasse, tatsächlich gemietetes Fahrzeug, Mietstation und gefahrene Kilometer.
• Eine Preisklasse beinhaltet die Kosten pro Tag (bei 300 Freikilometern) und die Kosten für jeden zusätzlichen Kilometer.

---

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.