Database Reference
In-Depth Information
werden müssen (was zu Fehlern führen kann). Sollte es Ab-
weichungen geben, dann können diese beim Artikel direkt hin-
terlegt werden. Andernfalls müsste man für jeden Spezialfall
ein neues Gebinde anlegen.
Nun folgen noch die Beschreibungen von ein paar ausgewähl-
te Spezialfällen.
Die Tabelle „Kunden-Artikel“ hat folgende Kurzschreibweise:
Kunden-Artikel
(
KundNr
,
ArtNr
,
Kaufdatum
, Menge)
Hier fällt auf, dass das Kaufdatum Teil des Primärschlüssels ist.
Dies ist notwendig, weil ein Kunde einen bestimmten Artikel
auch mehrmals kaufen kann, weshalb das Kaufdatum inklusive
Zeit (es soll Kunden geben, die den gleichen Artikel mehrmals
täglich kaufen) als zusätzliches Kriterium benötigt wird.
Das Feld „Menge“ wird mit dem Feld „Lagermenge“ aus der
Tabelle „Artikel“ gekoppelt. Die verkaufte Menge muss vom
Lagerbestand abgebucht werden. Dies kann mit einem Daten-
banktrigger auf der Tabelle „Kunden-Artikel“ realisiert werden.
Auf der anderen Seite muss das Feld „Lagermenge“ erhöht
werden, wenn neue Artikel angeliefert werden.
Bei den Lieferanten gibt es folgende Tabellen:
Lieferanten
(
LiefNr
, LiefName, LiefTyp)
Lieferung
(
LiefNr
, Lieferzeiten, LKontaktperson)
Entsorgung
(
LiefNr
, Mindestmenge, EKontaktperson)
Diese Tabelle resultieren aus Bild 7.5 (generalisierte Entitäts-
menge „Lieferanten“ und die spezialisierten Entitätsmengen
„Lieferung“ und „Entsorgung“ mit zugelassener Überlappung).
Der Sinn und Zweck solcher Konstruktionen ist eine redun-
danzfreie und somit speichersparende Datenverwaltung. In die
spezialisierten Tabellen „Lieferung“ und „Entsorgung“ werden
nur dann Datensätze gespeichert, wenn effektiv Daten vorlie-
gen. Als 1994 die erste Auflage dieses Buches erschien, waren
Festplatten- und Arbeitsspeicher noch kostbar. Heute schert es
einen Datenbankadministrator nicht mehr im Geringsten, ob
die Datenbank nun 4 oder 5 Gigabyte groß ist. Aus Geschwin-
digkeitsgründen ist es ohnehin besser, möglichst wenige Tabel-
