Datenbanken-Theorie - BuchPlus - HERDT

Theoretisches Wissen zu Datenbanken
1.
Theoretisches Wissen zu Datenbanken
1. Allgemeines zu Datenbanken
Datenmengen verwalten
Es werden im Folgenden einige Grundbegriffe der Datenbanksprache vermittelt sowie einige
Hilfsmittel und Techniken bei der Datenbankentwicklung vorgestellt.
In vielen Fällen ist dort, wo Arbeitsabläufe EDV-unterstützt
abgewickelt werden, auch die
Speicherung von großen Datenmengen erforderlich.
Lohn- und
Gehaltsabrechnung
Zuordnungsliste:
Mitarbeiter in den
Abteilungen
Adressliste sortiert
nach Wohnort
PERSONALDATEN
ABTEILUNGSDATEN
KUNDENVERZEICHNIS
Ein Datenbankprogramm verwaltet diese Daten und ermöglicht
es, diese Daten zu lesen, zu
ändern, zu löschen und neue hinzuzufügen.
Wie die Daten letztendlich gespeichert werden, hängt sowohl vom Datenbanktyp als auch vom
Datenbanksystem selbst ab.
Es gibt verschiedene Typen von Datenbanken, von denen der relationale Datenbankaufbau der
bekannteste ist.
Datenbanktypen
Datenbanktyp
Bemerkungen
Hierarchische
Datenbanken
Zwischen den Datensätzen besteht eine Rangordnung. Ein untergeordneter
Datensatz gehört immer zu einem anderen, übergeordneten. Die Beziehungen zwischen den Daten sind immer vom Typ 1 : n, sodass ein gerichteter
Graph entsteht, der auch als Baum bezeichnet wird.
Netzwerkdatenbanken
Dieses Modell ist dem hierarchischen Modell ähnlich. Die Daten sind aber
nicht in einem einheitlichen Baum angeordnet, sondern in einem vom
Datenbankentwickler definierten Netz.
© HERDT-Verlag
1
Theoretisches Wissen zu Datenbanken
2. Sichten auf eine Datenbank
Unterschiedlicher Informationsbedarf
Unterschiedliche Personengruppen, die mit einer Datenbank arbeiten, haben je nach Aufgabe
unterschiedliche Sichten auf die Datenbank.
Der Personalleiter benötigt beispielsweise Informationen über Personaldaten, während der
Datenbankverwalter mit der Datenspeicherung und Datensicherheit beschäftigt ist.
Die Details des physischen Datenbankentwurfs sind für den Personalleiter irrelevant. Sie werden
vom Datenbankadministrator festgelegt und bei Bedarf gewartet. Aus dem logischen und physischen Datenbankentwurf ergibt sich die Datenbank-Architektur:
Benutzersicht
(externe Sicht)
Lagerbestand
(Formular 1)
Umsätze
(Formular 2)
Logische Sicht
Lagerbestand
(Abfrage 1)
Umsatz pro Kunde
(Abfrage 2)
Interne Sicht
2
Artikeltabelle
(Access-Datenbank)
Kundentabelle
(Access-Datenbank)
Europäische
Top-10-Kunden
(Bericht)
Top-10-Exportkunden
(Abfrage 3)
Rechnungen
(Excel-Arbeitsmappe)
Europäische Kunden
(Abfrage 4)
Ausländische Kunden
(dBase-Datenbank)
Interne Sicht
Die interne Sicht beschäftigt sich mit der physikalischen Anordnung der
Daten auf den Datenträgern. Die Daten können auf verschiedenen Rechnern
in unterschiedlichen Gebäuden und Städten verteilt sein. Daten, die später
zum Beispiel als eine Tabelle zu sehen sind, müssen nicht zwangsläufig
gemeinsam gespeichert werden.
Logische Sicht
Die Gesamtheit aller Daten wird in der logischen Sicht mit ihren Beziehungen
dargestellt. In der logischen Sicht setzt das Datenbankdesign ein: Welche
Informationseinheiten werden wo verwaltet und welche Beziehungen
bestehen zu anderen Informationen?
Benutzersicht
Stellt die Sicht des Anwenders dar, der nur mit einem Teil der Daten arbeitet.
Er kennt weder den internen Aufbau noch die Gesamtsicht der Datenbank,
sondern nur die für ihn sichtbar gemachten Daten. Diese Daten können auf
andere Weise verknüpft und zusammengestellt sein als in der logischen
Sicht.
© HERDT-Verlag
Theoretisches Wissen zu Datenbanken
Vorteile der Abgrenzung von interner, logischer und Benutzersicht
D Die Benutzer einer Datenbank müssen nicht wissen, wie die Daten physikalisch organisiert
sind. Dadurch kann die physische Datenstruktur geändert werden, ohne dass sich das Datenbankdesign oder die Sicht der Benutzer ändert (zum Beispiel können die Daten auf mehrere
Computer verteilt werden, weil die Datenmenge zu groß geworden ist). Insbesondere laufen
die Anwendungsprogramme, die mit der Datenbank arbeiten, problemlos weiter.
D Auf der internen Ebene können unterschiedliche Tabellenformate (z. B. Access oder MySQL)
verwendet werden. Der Benutzer muss nicht wissen, woher die Daten kommen.
D Die Datenstruktur einer Benutzersicht ist speziell auf die Bedürfnisse und Berechtigungen
der Benutzer ausgerichtet. Der Personalchef darf beispielsweise die Gehälter der Mitarbeiter
sehen, während ein Angestellter der Personalverwaltung nur eine Sicht auf die Adressdaten
der Angestellten hat.
Logischer
Datenbankentwurf
Der logische Entwurf beschreibt die Struktur der Daten und der
Bindungen untereinander:
D Welche Daten werden wie zusammengefasst (zum Beispiel in
Tabellen)?
D Wie sehen die Beziehungen zwischen den Daten aus?
D Einfügen der Business-Logik: Gültigkeitsprüfungen, Eingabeformate
etc. Diese Logik steht dann automatisch jedem Nutzer der Daten zur
Verfügung. Dadurch ist eine konsistente Datenhaltung gewährleistet.
Physischer
Datenbankentwurf
Der physische Entwurf beschäftigt sich mit dem Abspeichern der Daten:
D Wie werden die Daten auf dem Datenträger verteilt?
D Welche Zugriffsmöglichkeiten bestehen zu den Daten (Netzwerk,
Internet, lokal ...)?
D Optimierung der Abspeicherung der Daten für oft auftretende
Suchoperationen
D Automatische Sicherungsmechanismen sind einzubauen (zum
Beispiel Daten mehrfach, gespiegelt abspeichern – bei Ausfall eines
Datenbankrechners existiert dann ein Ersatzrechner mit den gleichen
Daten).
© HERDT-Verlag
3
Theoretisches Wissen zu Datenbanken
3. Relationale Datenbanken
Beschreibung des relationalen Datenbankmodells
Das relationale Datenmodell wurde 1970 von dem Mathematiker E. F. Codd entwickelt und
mithilfe der Mengentheorie beschrieben. Dieses Modell bildet die Basis für relationale Datenbanken.
In einer Datenbank sollen Informationen über bestimmte Objekte und deren Eigenschaften
(Attribute) gesammelt werden. Ein solches Objekt könnte zum Beispiel eine Person (der Kunde
Müller), ein Gegenstand (der Artikel Bleistift) oder ein Ablauf (die Bestellung Nr. 22) sein.
Objekte, die durch die gleichen Attribute beschrieben werden können, werden als Objektmenge
zusammengefasst (Müller, Schulze und Meier bilden die Objektmenge Kunden).
Attribute (Spalten, Felder)
Tabellen (Relationen)
In einem relationalen Datenbankdesign muss
jedes Objekt in einer Tabelle gespeichert
sein. Zwischen den Tabellen können
Beziehungen über sogenannte Schlüssel
hergestellt werden.
Nummer
NachName
PLZ
Ort
Straße
1
Schulze
04173
Leipzig
Sassstr. 6
2
Meier
28199
Bremen
Hauptstr. 123
3
Müller
60320
Frankfurt
Dorfstr. 2
Tupel (Datensatz)
Attribut (Spalte, Feld)
Eigenschaften (Attribute)
Die jeweils zu einem Objekt vorhandenen Informationen werden in Eigenschaften aufgeteilt.
Eigenschaften einer Person könnten zum Beispiel der Name oder das Geburtsdatum sein. Eine
Eigenschaft (Attribut) besitzt einen Namen (z. B. Geburtsdatum) und für jede Zeile einen Wert
(z. B. 25.03.1976). In der Tabelle wird die Eigenschaft durch die Spaltenüberschrift dargestellt.
Wertebereiche (Domänen)
Eine Domäne beschreibt den zulässigen Wertebereich eines Attributs. Das können fest vorgegebene Werte sein (z. B. Januar, Februar ...), Bereiche (z. B. von 0 bis 999, von A bis G) oder
Mengenangaben bzw. Datentypangaben (z. B. natürliche Zahl, Datum).
In Access wird der Begriff Domäne auch für eine Gruppe von Datensätzen in einer Tabelle oder
Abfrage verwendet.
Tupel
Ein Tupel stellt die Menge der Attribute eines Objekts, also einen Datensatz, dar. Der Aufbau aller
Tupel einer Tabelle ist gleich. In der Tabelle Mitarbeiter werden z. B. in jedem Tupel die Adressdaten Nachname, Vorname, Straße, PLZ und Wohnort einer Person immer in dieser Reihenfolge
abgespeichert. Sie stellen in der Tabelle die Zeilen dar.
4
© HERDT-Verlag
Theoretisches Wissen zu Datenbanken
Schlüssel (Indizes)
Primärschlüssel
Das Relationen-Modell fordert, dass jede Tabelle ein Attribut oder eine Attributkombination
enthält, über das bzw. die jeder Datensatz eindeutig identifiziert werden kann. In der Praxis
kommen Attribute, die in jedem Fall eindeutig sind, selten vor. Beispiele wären Kraftfahrzeugkennzeichen oder eine Kombination aus Bankleitzahl und Kontonummer. Oft werden daher
zusätzliche Attribute definiert, welche die Datensätze fortlaufend oder nach einem Nummernkreis durchnummerieren. Sie können vor dem Benutzer verborgen bleiben und nur der internen
Datenbankverwaltung dienen oder sichtbar sein, wie zum Beispiel Artikel- oder Kundennummern.
Solche eindeutigen Felder werden auch auf der physikalischen Ebene benötigt und dienen unter
anderem dem schnellen Auffinden von Datensätzen in großen Tabellen. Sie werden Primärschlüssel genannt. Eine Tabelle kann nur einen Primärschlüssel haben. Die Tabelle wird standardmäßig nach diesem Schlüssel sortiert. Ein Primärschlüssel ändert normalerweise während der
gesamten Existenz eines Datensatzes seinen Wert nicht.
Sekundärschlüssel
Häufig sollen die Datensätze einer Tabelle in einer anderen Reihenfolge durchlaufen werden als
durch den Primärschlüssel vorgegeben, zum Beispiel nach Postleitzahlen. Dazu muss die gesamte
Tabelle nach diesen Postleitzahlen sortiert werden. Bei großen Datensatzmengen kann dies eine
lange Zeit in Anspruch nehmen. Um den Zugriff auf die Daten zu beschleunigen, können zusätzlich zum Primärschlüssel weitere Schlüssel angelegt werden, die auch als Sekundärschlüssel
bezeichnet werden. Mit Sekundärschlüsseln ist es möglich, nach anderen Dateninhalten als dem
Primärschlüssel zu suchen, ohne dass alle Datensätze einer Tabelle durchlaufen werden müssen.
Fremdschlüssel
Ein Fremdschlüssel ist ein Feld in einer Tabelle, welches mittels einer Beziehung einen Verweis
auf den Primärschlüssel einer anderen Tabelle herstellt. Beispielsweise befindet sich in der Beispieldatenbank Buero in der Tabelle Bestellung in jedem Datensatz eine Kundennummer des
Kunden, der die Bestellung ausgelöst hat. Diese Kundennummer verweist auf den Primärschlüssel
der Tabelle Kundenverwaltung und identifiziert den Kunden eindeutig. Die Kundennummer in der
Auftragstabelle stellt somit einen Fremdschlüssel („fremder“ Schlüssel einer anderen Tabelle)
dar.
Hilfsmittel und Methoden zum Datenbankentwurf
Das Entwerfen einer relationalen Datenbank ist eine komplexe Aufgabe. Sie müssen sämtliche
Informationen sammeln, die in der Datenbank verwaltet werden sollen, und passende Tabellen
dafür anlegen. Außerdem müssen Sie Beziehungen und sogenannte Integritätsregeln definieren
sowie unterschiedliche Benutzersichten realisieren.
© HERDT-Verlag
5
Theoretisches Wissen zu Datenbanken
Um die notwendigen Schritte beim Datenbankentwurf korrekt und übersichtlich durchzuführen,
können Sie sich folgender Regelwerke bedienen:
Normalisierungsprozess
Der Normalisierungsprozess ist eine Methode zur redundanzfreien
Speicherung (keine mehrfache Speicherung) von Daten und zur
Vermeidung fehlerhafter Datenerfassung beim Löschen, Ändern und
Hinzufügen von Daten.
Dabei werden die Daten über mehrere Stufen, die sogenannten
Normalformen, auf Tabellen verteilt, bis möglichst keine Redundanzen
und Inkonsistenzen mehr vorhanden sind. Mithilfe der Normalisierung
wird das relationale Datenbankdesign erreicht.
Entity-RelationshipModell
Mithilfe des Entity-Relationship-Modells (ER-Modell) können Sie eine
grafische Darstellung der Informationen zu den definierten Tabellen
und den Beziehungen zwischen ihnen anfertigen.
Sie können so die ganze Datenbankstruktur mit Papier und Bleistift
entwerfen, bevor Sie irgendwelche Arbeiten am Computer vornehmen.
Integritätsregeln
Die Integritätsregeln sind Bestimmungen, welche den logischen Aufbau
und die Korrektheit der Datenbank garantieren. Datenbankmanagementprogramme können diese Regeln überwachen und die
Daten bei Änderungs-, Lösch- und Einfügevorgängen überprüfen.
4. Die erste Normalform
Mehrfachwerte in einzelnen Feldern vermeiden
Sie möchten Ihre CD-Sammlung in einer Datenbank verwalten. Nachdem Sie sich überlegt haben,
welche Informationen in der Datenbank verwaltet werden sollen, haben Sie eine Tabelle angelegt, die alle diese Informationen beinhaltet.
Der Übersichtlichkeit halber sind einige Informationen, die noch interessant sein könnten
(etwa das Erscheinungsjahr einer CD), weggelassen worden. Im Beispiel die Tabelle „CDs“ ohne
Normalisierung (Atomisierung).
6
© HERDT-Verlag
Theoretisches Wissen zu Datenbanken
Der Weg, alle Daten in einer Tabelle unterzubringen, hat unverkennbar einige Nachteile. Was
zuerst auffällt, ist, dass das Feld Lieder nicht jeweils einen, sondern mehrere Werte annehmen
kann. Das hat Nachteile, weil …
D beim Bearbeiten der Lieder umständlich im Innern des Feldes gearbeitet werden muss;
D nach den Liedern nicht sortiert werden kann;
D in einem Feld Speicherplatz für eine unbekannte Zahl von Werten bereitgehalten werden
muss, was nicht immer gelingen wird und bei CDs mit wenigen Liedern zur Vergeudung von
Speicherplatz führt;
D die spätere Speicherung von zusätzlichen Informationen zu einzelnen Liedern, etwa die
Spieldauer, nicht oder nur schwer möglich wäre.
Um diese Nachteile zu vermeiden, ist es sinnvoll, die Tabelle in die erste Normalform zu bringen.
Definition der ersten Normalform
Eine Relation befindet sich dann in der ersten Normalform, wenn alle Attribute atomar, also
unteilbar sind.
Eine neue Relation
Die Beispieltabelle befindet sich deswegen nicht in der ersten Normalform, weil das Attribut
(Spalte) Lieder nicht atomar ist. Um die erste Normalform zu erreichen, legen Sie eine neue
Tabelle Lieder an, die für jedes Lied einen eigenen Datensatz enthält. Es bestehen nun eine Tabelle CDs und eine Tabelle Lieder, zwischen denen Sie eine Beziehung herstellen müssen. Die Tabelle
CDs enthält alle Hauptdatensätze und stellt somit die sogenannte Mastertabelle dar. Die Tabelle
Lieder enthält alle untergeordneten Datensätze und stellt daher die sogenannte Detailtabelle dar.

Um eine Beziehung zu erstellen, fügen Sie
in der Tabelle Lieder das Feld CDID  als
Fremdschlüssel hinzu. Das Feld CDID dient in
der Tabelle CDs als Primärschlüssel und ist
das verknüpfte Datenfeld für die notwendige
1:n-Beziehung zwischen den Tabellen CDs
und Lieder.
Sie haben jetzt die Möglichkeit, zu jedem einzelnen Lied
weitere Informationen, wie beispielsweise die Spieldauer,
zu speichern.
© HERDT-Verlag
7
Theoretisches Wissen zu Datenbanken
5. Die zweite Normalform
Redundanzen vermeiden
Eine CD-Sammlung beinhaltet oft mehrere CDs von jeweils dem gleichen Künstler beziehungsweise von der gleichen Band. In diesem Beispiel ist das der Interpret Rabih Abou-Khalil. Sein
Name ist daher mehrfach gespeichert. Dies hat folgende Nachteile:
D Wenn Sie merken, dass Sie den Namen immer falsch geschrieben haben, müssen Sie ihn an
mehreren Stellen ändern.
D Wenn Sie den Namen nur an einer Stelle falsch geschrieben haben, werden Sie beim Suchen
und Sortieren in der CD-Tabelle kein richtiges Ergebnis erhalten.
D Es ist nicht möglich, Informationen über Bands zu speichern, zu denen keine CD vorhanden
ist.
D Es wird unnötig Speicherplatz belegt. Das kommt insbesondere dann zum Tragen, wenn Sie
noch weitere Informationen über die Interpreten speichern möchten.
Definition
Eine Relation befindet sich in der zweiten Normalform, wenn sie sich bereits in der ersten
Normalform befindet und jedes Nichtschlüsselfeld (Felder, die nicht als Primärschlüssel dienen)
funktional vom Primärschlüssel abhängt.
Realisierung
Sie können dieser Forderung nachkommen, indem Sie eine neue Tabelle
Kuenstler anlegen. Das Feld Bandname
wird dafür aus der Tabelle CDs entfernt. Die Verbindung zwischen den
Tabellen kann durch das neue Schlüsselfeld KuenstlerID hergestellt werden.
Dass dieses Datenmodell keine Unterscheidung zwischen Einzelkünstlern
und Bands kennt, ist eine zulässige
Vereinfachung.
8
© HERDT-Verlag
Theoretisches Wissen zu Datenbanken
Das Datenmodell kann dem Vorkommen von CD-Samplern
gerecht werden, wenn Sie die neue Beziehung nicht zwischen den Tabellen Kuenstler und CDs, sondern zwischen
Künstler und Lieder anlegen. Es kommt so der abzubildenden Wirklichkeit näher. Es gibt eine direkte Beziehung
zwischen Künstlern und Liedern, die von der Zusammenstellung der CDs unabhängig ist.
Das Datenmodell ist dennoch nicht vollständig. Die Möglichkeit, dass dasselbe Lied desselben Künstlers auf verschiedenen CDs enthalten sein kann, kann hier ohne Redundanz
nicht abgebildet werden. Als Beispiel mag es dennoch
genügen.
Aus den gleichen Gründen wird das Feld Label aus der
Tabelle CDs in eine neue Relation verschoben. In beiden
neuen Tabellen können nun zusätzliche Informationen
gespeichert werden, die weder von den Liedern noch von
den CDs abhängen.
6. Die dritte Normalform
Abhängigkeiten zwischen Feldern vermeiden
Es fällt auf, dass in der Tabelle Labels die Inhalte der beiden Felder Land-Kuerzel und Land
unmittelbar voneinander abhängen. In solch einem Fall wird von transitiver Abhängigkeit
gesprochen. Zugleich können Werte mehrmals vorkommen. Das hat eine Reihe von Nachteilen:
D Wenn in einem Datensatz der Wert des Feldes Land-Kuerzel geändert wird, muss auch der
Wert des Feldes Land geändert werden.
D Die Werte für beide Felder müssen mehrfach gespeichert werden, wenn mehrere Labels
aus dem gleichen Land in der Sammlung vorkommen.
Definition
Eine Relation befindet sich in der dritten Normalform, wenn sie sich bereits in der zweiten
Normalform befindet und kein Nichtschlüsselfeld von einem anderen Nichtschlüsselfeld abhängig
ist.
© HERDT-Verlag
9
Theoretisches Wissen zu Datenbanken
Realisierung
Im vorliegenden Beispiel wird diese Forderung durch die
Einführung einer neuen Tabelle Laender erfüllt. Da die
Länderkürzel in der Praxis eindeutig sind, können sie als
Schlüsselfeld verwendet werden.
Fortgesetzter Vorgang
Jede neue Information, die in eine Datenbank aufgenommen wird, kann neue Fragen hinsichtlich
des geeigneten Datenmodells aufwerfen. Wenn Sie Ihre Datenbank von Anfang an bis zur dritten
Stufe normalisieren, werden Ihnen spätere Änderungen und Ergänzungen wesentlich leichter
fallen, als wenn Sie etwa in eine nicht normalisierte Tabelle neue Felder einfügen müssen.
Weitere Normalformen
Die Datenbanklehre kennt noch eine 4. und eine 5. Normalform. Diese dienen der Beseitigung
von Redundanzen innerhalb zusammengesetzter Schlüssel. Sie haben jedoch in der Praxis nur
eine geringe Bedeutung und kommen daher hier nicht zur Sprache.
7. Grundlagen zum Entity-Relationship-Modell
Ein Hilfsmittel zur Darstellung von Datenbanken
Wenn Sie sicherstellen möchten, dass alle relevanten Informationen in einem Datenbanksystem
berücksichtigt werden, ist eine Beschreibung des Anwendungsgebietes und der notwendigen
Objekte hilfreich. Das bekannteste und meist verwendete grafische Hilfsmittel zu diesem Zweck
ist das Entity-Relationship-Modell (kurz: ER-Modell). Mithilfe des ER-Modells kann der Abschnitt
aus der realen Welt, der in der Datenbank beschrieben werden soll, abgebildet werden.
In einer relationalen Datenbank werden die Sachverhalte tabellarisch dargestellt. Mit einem
ER-Modell können die notwendigen Tabellen abgeleitet werden. Eine Tabelle bzw. Relation im
relationalen Datenmodell ist gekennzeichnet durch:
D
D
D
D
D
10
einen eindeutigen Namen, beispielsweise Abteilung;
mehrere Attribute;
keine bis beliebig viele Tupel (Tabellenzeilen);
einen einzigen Wert pro Feld (Attribut);
einen Primärschlüssel, bestehend aus einem oder mehreren Datenfeldern, der jeden
Datensatz bzw. Tupel eindeutig identifiziert und dessen Wert sich während der Existenz
des Datensatzes nicht ändert.
© HERDT-Verlag
Theoretisches Wissen zu Datenbanken
Elemente und grafische Darstellung des ER-Modells
Entität (Entity), Entitätstyp (Entity-Typ), Entitätsmenge (Entity-Set)
In einer Datenbank sollen Informationen zu unterscheidbaren Objekten gespeichert werden. Diese
Objekte werden im ER-Modell als Entität (Entity)
bezeichnet. Eine Entität kann z. B. eine Person
(Frau Schmidt), ein Gegenstand (Bleistift), eine
Firma (Fa. Axial) oder ein Ablauf (Bestellung 112)
sein.
Jede Entität kann durch bestimmte Attribute
(Eigenschaften) beschrieben werden. Attribute
einer Person könnten zum Beispiel der Name oder
das Geburtsdatum sein.
Um das Datenbankmodell möglichst überschaubar
zu halten, werden alle Entitäten, die man durch die
gleichen Attribute beschreiben kann (z. B. Name,
Geburtsdatum), übergeordneten Entitätstypen
(Entity-Typ) zugewiesen. Bei der Planung einer
Datenbank werden nicht die einzelnen Entitäten
betrachtet, sondern der Entitätstyp.
Werden alle Entitäten, die demselben Entitätstyp
angehören, zusammengefasst, erhält man die
Entitätsmenge (Entity-Set).
Sie ist die konkrete Sammlung von Entitäten mit
gleichen Attributen (z. B. Name), aber unterschiedlichen Eigenschaftswerten (Schmidt, Mayer,
Müller), zu einem bestimmten Zeitpunkt. Entitätsmengen sind zeitlich veränderlich. Eine Entitätsmenge entspricht im relationalen Datenmodell
einer Tabelle.
Entitäten:
Frau Schmidt
Forschungsabteilung
Projekt-1009
Attribute:
Name, Geburtsdatum (Schmidt)
Name, Geburtsdatum (Mayer)
Mitglieder, Etat (Forschungsabteilung)
Entitätstypen:
Mitarbeiter
Abteilung
Projekt
Entitätsmengen:
Alle Mitarbeiter
(Schmidt, Maier, Müller usw.)
Alle Abteilungen
(Forschungsabteilung, Personalabteilung,
Rechtsabteilung usw.)
Alle Projekte
(Projekt-1009, Projekt-1010, Projekt1011 usw.)
Überlegen Sie zuerst, welche Entitäten Ihre Datenbank verwalten soll und welche Entitätstypen sich daraus ableiten lassen.
Im ER-Modell werden Entitätstypen als Rechteck dargestellt.
© HERDT-Verlag
11
Theoretisches Wissen zu Datenbanken
Beziehung (Relationship), Beziehungstyp
Eine Beziehung ist eine Verknüpfung von Entitäten.
Beziehungen unterscheiden sich voneinander
durch ihre jeweiligen Eigenschaften.
Der Beziehungstyp beschreibt die numerischen
Zusammenhänge zwischen den einzelnen
Elementen, beispielsweise wie viele Datensätze
der Tabelle Mitarbeiter einem Datensatz der
Tabelle Abteilung zugewiesen werden.
Der Beziehungstyp wird durch folgende Angaben definiert:
0
- keine Zuordnung
1
- genau eine Zuordnung
n, m - viele Zuordnungen
Beziehung:
Mitarbeiter Schmidt arbeitet an Projekt
1009.
Beziehungstyp:
1 Abteilung besteht aus n Mitarbeitern.
n Mitarbeiter arbeiten an m Projekten.
ABTEILUNG
ABTEILUNG
M
ITARBEITER
MITARBEITER
1
n
n
besteht aus
m
arbeitet in
M
ITARBEITER
MITARBEITER
PROJEKT
PROJEKT
Die Beziehungen werden im ER-Modell durch Verbindungslinien dargestellt.
In einem Symbol wird die Beschreibung der Beziehung eingetragen.
Über den Linien wird die Art der Beziehung – zum Beispiel 1:n – eingefügt.
Attribute (Eigenschaften), Domänen
Attribute (Eigenschaften) charakterisieren einen
Entitätstyp oder einen Beziehungstyp.
Attributswerte charakterisieren eine Entität oder
eine Beziehung.
Attribute:
Abteilungsname
Personalnummer
Projektnummer
Domänen:
Eine Domäne beschreibt den zulässigen Wertebereich einer Eigenschaft.
Mitarbeiter:
PersonalID
AbteilungsID
Legen Sie alle Attribute für einen Entitätstyp fest. Geburtstag
Bestimmen Sie die zugehörigen Domänen
(Wertebereiche) der Attribute.
PersonalID
12
1 - 999
1-9
tt.mm.jj
MITARBEITER
Name
Vorname
AbteilungsID
© HERDT-Verlag
Theoretisches Wissen zu Datenbanken
Primärschlüssel
Der Primärschlüssel ermöglicht die eindeutige
Identifizierung einer Entität dadurch, dass sein
Wert in einer Entitätsmenge nur ein einziges
Mal vorkommt. Er setzt sich aus einem oder
mehreren Attributen zusammen.
Bestimmen Sie für jede Relation den Primärschlüssel. Grafisch können Sie den
Schlüssel durch Unterstreichung der betreffenden Felder hervorheben.
Die Relation Mitarbeiter besitzt den
Primärschlüssel PersonalID.
MITARBEITER
PersonalID
Name
AbteilungsID
Vorname
8. Beschreibung des ER-Modells
Abbildung der Struktur
In einem Unternehmen gibt es Mitarbeiter, Abteilungen und Projekte. Zur Verwaltung aller
Informationen und Ereignisse soll eine Datenbank erstellt werden. In der folgenden Abbildung
sind alle Elemente der Datenbank und deren Beziehungen untereinander zusammengestellt.

A B T E IL U N G
1
b e s te h t a u s
n

M IT A R B E IT E R



A b t e ilu n g s ID
B e z e ic h n u n g
P e r s o n a l ID
n
a rb e ite t a n

P r o j e k t ID
Nachnam e
V o rn a m e
A b t e i l u n g s ID
m


P R O JE K T
P e r s o n a l ID
P r o j e k t ID

B e s c h r e ib u n g
D Alle Informationen lassen sich in drei Entitätstypen  aufteilen: Abteilung, Mitarbeiter und
D
D
D
D
D
Projekt.
Zwischen den Entitätstypen lassen sich zwei Beziehungen  erkennen: Eine Abteilung
besteht aus Mitarbeitern, die in Projekten arbeiten.
Da eine Abteilung aus mehreren Mitarbeitern besteht, aber ein Mitarbeiter nur einer
Abteilung zugewiesen ist, besteht hier eine 1:n-Beziehung .
Bei einer 1:n-Beziehung ist es erforderlich, das Schlüsselfeld der Haupttabelle in die Detailtabelle einzufügen. Die Tabelle Mitarbeiter besitzt demnach einen sogenannten
Fremdschlüssel AbteilungsID.
Ein Mitarbeiter kann in mehreren Projekten arbeiten, in einem Projekt können mehrere
Mitarbeiter arbeiten. Hier ist eine m:n-Beziehung erkennbar .
Die Entitätstypen Abteilung, Mitarbeiter und Projekt besitzen Attribute. Beispielsweise
besitzt der Entitätstyp Projekt die Attribute ProjektID und Beschreibung. Das Attribut
ProjektID ist eindeutig und soll als Primärschlüssel  dienen, daher der Unterstrich.
Eine m:n-Beziehung erfordert einen weiteren Entitätstyp, welcher die Beteiligung eines
Mitarbeiters an einem Projekt beschreibt .
Der neu entstandene Entitätstyp setzt sich mindestens aus den Schlüsselfeldern der beiden
Entitätstypen, die in der m:n-Beziehung stehen, zusammen. Sie könnte aber auch noch
andere Attribute erhalten; in diesem Beispiel etwa die Arbeitszeit eines Mitarbeiters für ein
Projekt.
© HERDT-Verlag
13
Theoretisches Wissen zu Datenbanken
Textbeschreibung eines Datenmodells
Um eine kompakte Beschreibung der Relationen sowie deren Attribute und Schlüsselfelder zu
erhalten, können Sie die folgende Textform verwenden. Zu Beginn stehen der Name der Relation
und in Klammern die Attribute, wobei die Primärschlüsselfelder unterstrichen sind.
ABTEILUNG (AbteilungsID, Bezeichnung)
MITARBEITER (PersonalID, Nachname, Vorname, AbteilungsID)
PROJEKT (ProjektID, Beschreibung)
PROJEKTAUSWERTUNG (ProjektID, PersonalID, GeleisteteStunden)
ER-Modell in eine Datenbank umsetzen
Aus dem obigen ER-Modell lassen sich für eine Access-Datenbank vier Tabellenstrukturen ableiten. Die Anzahl der Tabellen hängt von den definierten Entitätstypen und bei m:n-Beziehungen
auch vom Beziehungstyp zwischen den Tabellen ab.
Tabelle Abteilung
Tabelle Mitarbeiter
Tabelle Projekt
14
© HERDT-Verlag
Theoretisches Wissen zu Datenbanken
Besonderheit bei m:n-Beziehungen
Eine m:n-Beziehung, wie sie zwischen den Tabellen Mitarbeiter und
Projekt besteht, erzwingt Mehrfacheinträge.
Damit nachträgliche Änderungen
die Konsistenz der Daten nicht beeinträchtigen, entsteht aus einer
m:n-Beziehung eine neue Tabelle,
die sich aus den Primärschlüsseln
der beiden Tabellen Projekt und
Mitarbeiter zusammensetzt.
Mehrfacheinträge
(Datenredundanz)
Fremdschlüssel
Datenredundanz durch Fremdschlüssel
Tabelle Projektauswertung
Wurden alle notwendigen Tabellen und Beziehungen für die Datenbank erstellt, können anschließend die weiteren Objekte, wie Formulare, Abfragen und Berichte, hinzugefügt werden.
9. Planung einer Datenbank
Das Buch Grundlagen für Datenbankentwickler hilft Ihnen, anhand der Beschreibungen und
Übungen die wichtigsten Funktionen einer Access-Datenbank kennenzulernen. Diese Grundlagen
und die unten beschriebene Vorgehensweise unterstützen Sie bei der Entwicklung einer eigenen
Datenbank.
Lernen Sie zunächst Access gut kennen.
Legen Sie eine Liste an mit allen Vorgängen, die in der Datenbank ausgeführt werden sollen.
Planen Sie die einzelnen Tabellen. Welche Daten sollen in welche Tabellen abgelegt werden?
Vermeiden Sie Redundanzen.
Überlegen Sie, welche Felder Sie in den Tabellen benötigen. Legen Sie die Feldnamen, Felddatentypen, Felddateneigenschaften (wie Größe, Eingabe erforderlich, Formate oder
Gültigkeitsregeln) für jede Tabelle fest.
Denken Sie darüber nach, zwischen welchen Tabellen Beziehungen entstehen sollen. Überprüfen Sie die Feldeigenschaften der Felder, die miteinander in Beziehung treten.
Definieren Sie Primärschlüssel für Ihre Tabellen.
Überprüfen Sie die erste Normalform. Sind Ihre Daten atomar? Gibt es wiederholte Daten,
die in eine neue Tabelle ausgelagert werden können?
Überprüfen Sie die zweite und dritte Normalform. Sind die Daten Ihrer Tabellen eindeutig
beschrieben? Überprüfen Sie, ob alle erforderlichen Primärschlüssel gesetzt wurden. Gibt
es „Nicht-Schlüsselfelder“, die in Beziehung treten?
© HERDT-Verlag
15
Theoretisches Wissen zu Datenbanken
Planen Sie alle erforderlichen Formulare und ihre Eigenschaften. Entwickeln Sie ein Layout,
das dem Corporate Design (CD) Ihres Unternehmens entspricht. Bedenken Sie dabei die
Bildschirmtauglichkeit von Formularen.
Planen Sie alle erforderlichen Berichte. Die Gestaltung der Berichte sollte ebenfalls dem
Corporate Design entsprechen.
Eine umfassende Vorbereitung kann Ihnen helfen, Mängel in der Datenbankstruktur zu vermeiden. Müssen Mängel in der Datenbankstruktur einer bestehenden und gefüllten Datenbank
korrigiert werden, ist ein weit höherer Arbeitsaufwand erforderlich.
Namenskonventionen
Normen und Konventionen sind kein Muss, sie
können jedoch den Arbeitsalltag enorm erleichtern. Im Bereich von Datenbanken wird häufig
auf die sogenannte Reddick-VBA-Namenskonvention verwiesen. Sollte in einer Datenbank
programmiert werden, kann das den Namen der
Datenbankobjekte vorangestellte Präfix bei
Unterscheidungen der Datenbankobjekte in der
Programmierung hilfreich sein. Sie können diese
Informationen in Ihrer Datenbankplanung bei
Bedarf einbeziehen.
Namenskonvention nach Reddick
Objekt
Präfix
Beispiel
Tabellen (engl. tables)
tab
tabKunden
Abfragen (engl. queries)
qry
qryBestelldetails
Formulare (engl. forms)
frm
frmKunden
Berichte (engl. reports)
rpt
rptKatalog
Makros (engl. macros)
mcr
mcrFunktionen
Module (engl. modules)
bas
basFunktionen
Es gibt verschiedene Namenskonventionen für Datenbanken, die sich in den Präfixen unterscheiden können.
Wenn Sie Namenskonventionen verwenden möchten, überprüfen Sie zunächst, ob es bestehende
Konventionen in Ihrem Arbeitsumfeld gibt. Definieren Sie Namenskonventionen bereits bei der
Planung Ihrer Datenbank und verwenden Sie diese durchgängig.
16
© HERDT-Verlag