MÜNCHEN-Eine Datenbank alleine macht noch kein Informationsparadies. Die Analyse des Umfeldes, in dem die Datenbank eingesetzt werden soll, ist Grundvoraussetzung für ihren sinnvollen Einsatz. Hemmnisse und Enttäuschungen sind zusätzlich häufig vom Hersteller provoziert, der durch seine Verkaufsargumentation Erwartungen über schnelle Implementierung und leichte Handhabung weckt, die überzogen sind. So jedenfalls eine der Aussagen auf dem Symposium der CW-Seminargruppe CSE (CW-Publikationen) zum Thema Datenbanken in der Praxis. Beurteilungs-und Auswahlkriterie für DB-Systeme in Procluktionsbetrieben stellte Dr. Wolfgang Michels aus Kempen in seinem Referat vor, das hier in zusammengefaßter Form abgedruckt ist.
Datenbanken und die sie verwaltenden Datenbanksysteme haben mittlerweile in der Verwaltung, bei Behörden, in Handels- und Dienstleistungsunternehmen und in jüngerer Zeit zunehmend auch in produzierenden Unternehmen ein breites Einsatzgebiet gefunden. Die Erfahrung hat gezeigt, daß eine Online-Verarbeitung zielführend vorzugsweise auf der Basis integrierter Datenbanken zu erreichen ist. Weit weniger verbreitet ist hingegen die Erkenntnis, daß der Aufbau einer Datenbank und der Einsatz eines Datenbanksystems einer umfassenden systemanalytischen Vorbereitung bedürfen. Vielfach ist noch die Meinung anzutreffen, daß integrierte Datenverarbeitung bedeute, möglichst alle Funktionskreise im Unternehmen DV-mäßig abzudecken.
Logische Strukturen ermitteln
Mit dem Erwerb eines Datenbanksystems erhofft man, die bekannten Redundanz-, Aktualitäts- und Wartungs-/Pflegeprobleme einschlägiger Konglomerate von gewachsenen Insellösungen beheben zu können. Dem ist nur zu entgegnen, daß mit der Entwicklung von Datenbanksystemen keineswegs das Schlaraffenland ausgebrochen ist. Daher ist auch eines der Haupthemmnisse für den Einsatz von Datenbanksystemen in der sehr problematischen Umstellbarkeit bereits vorhandener Anwendungen zu sehen.
Will man die Zweckmäßigkeit des Einsatzes von Datenbanksystemen für einen Anwendungsfall fundiert beurteilen, so muß dieser Anwendungsfall ausreichend spezifiziert sein. Dies bedeutet zunächst, daß die logischen Datenstrukturen möglichst der gesamten Anwendung zu ermitteln sind.
Ferner müssen die erforderlichen Einstiegsmöglichkeiten und Suchfolgen in den einzelnen Datensatzarten, sowie der Verarbeitungsmodus in den jeweiligen Anwenderprogrammen (online-batch) bekannt sein. Dies gilt insbesondere für zeitkritische Anwendungen, wenn gegebenenfalls durch geeignete physische Speicherung die Zugriffsintensität gemindert werden soll.
Bei der Online-Verarbeitung hat es sich gezeigt, daß wenige Programmtypen die differenzierten Anforderungen einer Anwendung im Regel-falle abdecken.
Es ist in jedem Falle für alle Satzarten einer Anwendung zu klären, ob ein direkter Einstieg erforderlich ist, ob dieser qualifiziert oder eventuell teilqualifiziert erfolgen muß und ob eine logische Suchfolge zu realisieren ist. Ferner ist zu klären, ob sekundäre Einstiege und Suchfolgen notwendig sind und hierbei gegebenenfalls Schlüsselduplikate erlaubt werden müssen.
Hinsichtlich der logischen Verbindung und Abhängigkeit von Datensatzarten ist zu ermitteln, ob die Abhängigkeit in jedem Falle besteht und somit eine automatische Verbindung angelegt werden kann, oder ob eine sogenannte optionale Abhängigkeit vorliegt, die nur bei bestimmten Bedingungen erzeugt werden darf.
Voraussetzung für automatische Verbindung ist naturgemäß, daß "untere" Datensätze nur mit bereits gespeicherten "oberen" Datensätzen verbunden werden können, und somit obere Sätze von der Verbindung bereits angelegt sind. Um diese Verhältnisse mit hinreichender Sicherheit beurteilen zu können, muß die zeitlich-organisatorische Entstehungsfolge der Datensatzarten bekannt sein.
Zur Quantifizierung der jeweiligen Aufgabenstellung und Anforderungen ist weiterhin die Ermittlung eines Mengengerüstes für die zu erwartenden Datenbestände sowie die Ermittlung der Benutzungshäufigkeit der einzelnen Anwenderprogramme unerläßlich.
Analysebedarf oft nicht erkannt
Es ist also festzuhalten, daß zur Beurteilung und Auswahl eines Datenbanksystems eine weitgehend komplette Systemanalyse der anstehenden Aufgabenstellung vorliegen muß. Dies einem potentiellen Anwender klarzumachen, ist nicht immer einfach. Insbesondere die Verkaufsargumente vieler Hersteller sind dieser Vorgehensweise nicht gerade förderlich, da sie kurzfristigen Verkaufserfolgen fast immer im Wege stehen. Andererseits müßte es einsichtig sein, daß man sich kein Haus bauen läßt, um sich anschließend von Experten bestätigen zu lassen, daß Architektur und Statik nicht stimmen.
Zur Beurteilung der Einsatzmöglichkeit eines Datenbanksystems reicht dessen Fähigkeitsprofil alleine keineswegs aus. Vielmehr müssen die Umfeldaspekte, die sich im wesentlichen aus dem konkurrierenden Online-Mehrnutzerbetrieb, dem Datenschutz- und Datensicherheitspunkten, den Integritäts- und Rekonstruktionsaspekten sowie letztlich aus der Programmierfreundlichkeit ableiten lassen, berücksichtigt werden.
Dies bedeutet, daß die Datenbank-, die Datenkommunikations- und die Data-Dictionary-Komponente sowie die allgemeinen Dienstprogramme immer im Zusammenhang beurteilt werden müssen.
Systemdiskussion zu emotional
Die Streitfrage, ob Codasyl-Systemen oder relationalen Systemen die Zukunft gehört, ist in der Vergangenheit sehr unter emotionalen Aspekten diskutiert worden. Im folgenden werden einige generelle Gesichtspunkte, die vorwiegend auf Anwendererfahrungen basieren, betrachtet.
Zunächst ist festzuhalten, daß es zur Realisierung einer Datenbankanwendung nicht zwangsläufig des Einsatzes eines Datenbanksystemes bedarf. Bei entsprechender Anwendungsprogrammierung ist eine Datenbank auch auf der Basis konventioneller Dateiorganisationsformen realisierbar.
Datenbanksysteme, die den Forderungen der Codasyl-Norm entsprechen, bilden im Regelfalle die (..)ischen Abhängigkeiten zwischen den verschiedenen Satzarten einer Datenbank über physische Adressverkettung ab. Darüber hinaus ist meist die physisch benachbarte Speicherung logisch benachbarter Datensätze beeinflußbar. Die Möglichkeit der Sekundärindizierung/Invertierung ist keine Forderung der Codasyl-Norm. Wenn Codasyl-Systeme diese Komponente aufweisen, so ist dies als zusätzlicher Komfort zu betrachten.
Programmierfehler auf Logik ohne Einfluß
Eine weitere wesentliche Eigenschaft von Codasyl-Systemen besteht darin, daß die logische Konsistenz einer Datenbank nicht durch fehlerhafte Anwendungsprogrammierung zerstört werden kann. So ist es nicht möglich "Owner-Sätze" (..) löschen, wenn noch entsprechende "Member-Sätze" im System gespeichert sind.
Relationale Datenbanksysteme bilden die Abhängigkeiten zwischen Datensatzarten über logische Schlüsselverkettung ab. deren Pflege naturgemäß dem Anwender obliegt. Hierin liegt eine gewisse Gefahr, da bei nachlässiger Anwendungsprogrammierung die logische Konsistenz der Datenbank nicht gewährleistet ist.
Es ist nicht selten anzutreffen, daß beim Einsatz von relationalen Systemen zum Beispiel Stücklistenzeilen ohne Stücklistenköpfe oder Auftragspositionen ohne zugehörige Aufträge gespeichert sind. Das häufig vorgebrachte Argument, daß relationale Systeme programmierfreundlicher seien, ist insofern mit Vorsicht zu betrachten.
Gesamtdatenfamilie angesprochen
Codasyl-Systeme haben generell dort Vorteile, wo sogenannte Datenfamilien vorwiegend in ihrer Gesamtheit angesprochen und eventuell verarbeitet werden. Unter einer Datenfamilie ist beispielsweise ein Kundenauftrag mit sämtlichen zugehörigen Auftragspositionen zu verstehen. Allgemein formuliert entspricht eine Datenfamilie einer Set-Occourence im Sinne von Codasyl. Durch geeignete Beeinflussung der physisch benachbarten Speicherung von Datenfamilien kann die Zugriffsintensität günstig beeinflußt werden. (..)fahrungen aus der Praxis zeigen (daß) derartige Datenfamilien vorzugsweise stark vernetzten Datenbeständen anzutreffen sind.
Relationale Systeme haben dort gravierende Vorteile, wo eine hohe Auskunftsbereitschaft der Datenbank bei alternativen Suchargumenten gefordert wird. Je höher der Invertierungsgrad bei gleichzeitig gering vernetzten Datenbeständen ist, je mehr ist der Einsatz relationaler Datenbanksysteme zu empfehlen.
Ein Datenbanksystem muß in jedem Falle gewährleisten, daß die logischen Datenstrukturen einer Anwendung weitestgehend beschränkungsfrei abgebildet werden können. Dies ist bei Systemen, die der Codasyl-Norm entsprechen, der Fall.
Relational ist gleich linear
Relationale Systeme kennen nur lineare Strukturen. Abhängigkeiten werden durch Schlüsselverweise in den Relationen dargestellt. Insofern sind alle Datenstrukturen relational abbildbar.
Insbesondere bei den sogenannten Codasyl-ähnlichen Systemen sind jedoch bisweilen Beschränkungen hinsichtlich der Abbildbarkeit anzutreffen, welche in der Regel nur durch erhöhte Programmieraufwand kompensiert werden können.
Als Beispiel sei die Strukturebenenbegrenzung auf zwei Strukturebenen bei den DB-Systemen Total und Image-3000 angeführt. Der Nachteil dieser Systeme läßt sich durch die Hilfskonstruktion des "Automatical Master" umgehen. Es ist jedoch anzumerken, daß bei tief strukturierten und vernetzten Datenbeständen der Einsatz derartiger Hilfskonstruktionen zu kaum noch überschaubaren Verhältnissen führt.
Weiterhin sei auf die Restriktionen hingewiesen, die beim DB-System DL/1 hinsichtlich der Abbildbarkeit von Netzwerken bestehen. Eine Seite des Netzwerkes kann immer nur logisch abgebildet werden. Dieser Nachteil ist allerdings durch die Verbesserung der Sekundärindizierung stark gemildert worden. Ferner ist auf Mengenbeschränkungen hinsichtlich der Definition von Satzarten, Abhängigkeiten und Datenfeldern zu achten. Ein Datenbanksystem, das beispielsweise lediglich die Definition von rund 250 Datenfeldern zuläßt, ist natürlich hinsichtlich seiner Einsatzmöglichkeiten kritisch zu beurteilen.
Effizienz hängt vom Verfahren ab
Die Effizienz eines Datenbanksystems hängt wesentlich von der Effizienz der in ihm realisierten Zugriffsverfahren ab. Komfortable Bildschirmanwendungen im Online-Betrieb erfordern zunehmend gezielte Einstiegsmöglichkeiten und logisch sortierte Abarbeitungsmöglichkeiten aller Datensatzarten einer Datenbank.
Diese Forderung wird bei indizierten/invertierten Speicherungsformen und Zugriffsverfahren immer erfüllt. Hier liegt auch der unbestreitbare Vorteil relationaler Datenbanksysteme. Allerdings muß eine effiziente Indexverwaltung ohne die Notwendigkeit zu periodischer Reorganisation gewährleistet sein.
Bei kalkulierten Zugriffsverfahren (Hash-Verfahren) sind einmal die Restriktionen des Hash-Algorithmus auf die Dateiauslegung und den Füllungsgrad der Datei zu beachten. Ferner sei auf den prinzipiellen Nachteil des Hash-Verfahrens hingewiesen, nämlich daß keine logischen Suchfolgen realisierbar sind und kein teilqualifizierter Einstieg in eine Datei möglich ist.
Als Speicherungsstrukturen zwischen verschiedenen Satzarten kennt Codasyl die Strukturen Chain, Pointer-Array und List. Die Speicherungsstruktur Chain basiert auf der Adressverkettung. Ein wesentliches Bewertungskriterium ist, ob das DB-System eine logisch sortierte Verkettung zuläßt. Dies ist insbesondere bei Untermengen von Datenbanksystemen für kleine Anlagen (so Image 250) bisweilen nicht der Fall.
Dummy Owner als Anker
Die logische Verkettung von Stammdaten wird häufig empfohlen, wenn bei Hash-Zugriff dennoch eine logische Sortierfolge realisiert werden muß. Vom Anwender muß in solchen Fällen ein "Dummy Owner" definiert werden, der als Ankersatz der Kette fungiert. Letztlich ist zu beachten, daß bei logischer Verkettung und langen Ketten das Einfügen von Datensätzen zeitaufwendig wird.
Beim kalkuliertem Zugriff auf Kettsätze ist allgemein zu beachten, daß kalkulierte Speicherung und physisch benachbarte Speicherung einer kette sich ausschließen. In solchen Fällen geht ein wesentlicher Vorteil von Codasyl-Systemen verloren.
Bei Datenbanksystemen, die ausschließlich die Speicherungsstruktur Chain kennen, wird vielfach empfohlen, die Kettenordnung nach Performance-Gesichtspunkten vorzunehmen und Einstiegsmöglichkeiten und Sortierfolgen über zusätzliche, vom Anwender zu pflegende Index-Dateien zu realisieren. In diesem Zusammenhang ist sicher die Frage erlaubt, ob dann nicht lieber gleich ein relationales Datenbanksystem eingesetzt werden sollte. In diesem Falle muß bei solchen Überlegungen geklärt werden, ob die in Frage kommende Index-Organisationsform wiederanlaufunterstützt ist.
Ferner muß überprüft werden, ob der DB-Key beim Indexaufbau verwendet werden kann. Hierfür ist Voraussetzung, daß Datensätze während ihrer Speicherungsdauer ihre Adresse nicht verändern. Dies ist nicht bei allen Datenbanksystemen der Fall.
Die Codasyl-Speicherstruktur "Pointer-Array" kennt die geschilderten Nachteile der Adreßverkettung nicht. Bei dieser Speicherungsform sind gezielter Einstieg und sortierte Abarbeitung sowohl auf Set-Ebene als auch auf Datensatzebene möglich.
Die Speicherungsform "List" beinhaltet die sequentielle Speicherung von Owner-Sätzen und zugehörigen Member-Sätzen. Sie ist bei Online-Anwendungen nur bedingt einsetzbar.
Eine Datenbank wird im Regelfalle für eine Vielzahl von Anwendern aufgebaut. Für Online-Anwendungen typisch, daß die Benutzer simultan auf die Datenbank zugreifen wollen.
Hieraus leiten sich einige Anforderungen an die Basissoftware, aber auch an die Gestaltung der Anwenderprogramme ab. Hinsichtlich der Basissoftware lassen sich verschiedene Konzepte unterscheiden. Je nach Konzeption ergeben sich unterschiedliche Auswirkungen auf die Schnittstellengestaltung zum Anwenderprogramm, die im jeweiligen Anwendungsfalle zu klären sind.
Beim konkurrierenden Zugriff mit Update-Option muß verhindert werden, daß ein Anwender Daten ändern kann, die ein anderer Anwender zum gleichen Zweck bereits gelesen hat. In solchen Fällen werden die Datenbestände solange für andere Benutzer gesperrt, bis der Änderungsvorgang abgeschlossen ist.
Die einfachste Methode ist, die gesamte Datenbank zu sperren. Dies hat praktisch eine Serialisierung der Programmabarbeitung zur Folge. Ob dies tragbar ist, hängt vom jeweiligen Anwendungsfalle ab. Die meisten Datenbanksysteme sperren die Datenübertragungseinheiten, also physische Blöcke. Hierbei kann sich der Vorteil der physisch benachbarten Speicherung ins Gegenteil umkehren, wenn häufig angesprochene Datenfamilien komplett oder überwiegend gesperrt werden.
Deadlock beim Datensperren
Beim Sperren von Datenbeständen können sogenannte Deadlock-Situationen auftreten, wenn sich Prozesse gegenseitig sperren. Es gibt prinzipiell zwei Arten zur Behandlung dieses Problems:
- Verhinderung der Situation. Dies ist schwierig und aufwendig.
- Erkennung und Aufheben der Situation durch Rücksetzen eines der beteiligten Prozesse. Dieses Verfahren wird nahezu ausnahmslos eingesetzt.
Für den Anwender ist jedoch primär relevant, ob eine Deadlock-Situation für ihn überhaupt erkennbar wird. Hierin unterscheiden sich die DB-Systeme beziehungsweise die Basissoftware zum Teil erheblich.
Im Idealfalle wird das Wiederaufsetzen zurückgesetzter Prozesse vom System übernommen. Weit weniger komfortabel sind Systeme, die dem Anwender einen Deadlock-Status abliefern und ihm bei Verlust der Eingabeinformation einen weiteren Versuch zumuten. In solchen Fällen müssen bei der Anwendungsprogrammierung die Eingabedaten präventiv gesichert werden, damit sie bei Auftreten der Situation dem Benutzer zurückgegeben werden können und er zumindest den Eingabeaufwand nicht wiederholen muß.
Hersteller kaschieren Recovery-Komponente
Es gibt die verschiedensten Ursachen für inkonsistente Datenbestände. In jedem Falle muß gewährleistet sein, daß die Datenbank unter Minimierung von Datenverlusten in einen konsistenten Zustand zurückversetzt werden kann. Man unterscheidet in diesem Zusammenhang die sogenannte "Backward-recovery" und die "Forward-recovery".
Voraussetzung für die Backward-recovery ist das Before-Image-Logging. Die Datensätze werden im Zustand von der Veränderung protokolliert. Bei fehlerhaften Transaktionen wird auf diesen Zustand zurückgesetzt. Diese Komponente sollte in jedem Falle verfügbar sein. Hersteller, die die Bedeutung dieser Komponente mindern, kaschieren damit nur ihre fehlende Verfügbarkeit. Die Forward-recovery beinhaltet die Wiederherstellung der Datenbank auf der Basis der letzten Sicherungskopie durch Nachfahren sogenannter After-Image-Kopien. Dies ist immer dann erforderlich, wenn die Datenbank mit den before-Image-Kopien nicht mehr rekonstruiert werden kann, wie zum Beispiel bei physischer Zerstörung des Speichermediums. Viele Anwender verzichten auf das After-Image-logging und nehmen den Verlust von Eingabeinformationen bewußt in Kauf, um das aufwendige Loggen zu sparen.
Individuelle Steuerung oft sinnvoll
Die meisten Hersteller bieten mittlerweile Generationsprogramme zur Erzeugung von Bildschirmmasken und Ausgabelisten an. Insbesondere beim Einsatz von Maskengeneratoren ist deren Funktionsumfang genau zu prüfen. Ferner weisen diese Generatoren einige Restriktionen auf, die vor der Maskenkomposition bekannt sein sollten. So ist es wesentlich, zu wissen, ob die pro Bildschirmzeile und Gesamtbildschirm definierbare Anzahl von Feldern von der Wahl der Feldattribute beeinflußt wird und ob die Attribute selbst Platz am Bildschirm benötigen. Weiterhin ist es wichtig zu wissen, ob Systemkommentare eine eigene Bildschirmzeile benötigen oder nicht. Es ist unter Umständen sinnvoller, eine individuelle Formatsteuerung zu schreiben, wenn die Restriktionen des Generators die Anwendung negativ beeinflussen.
Bei der Konversation mit Datenbanken sind prinzipiell zwei Konversationsarten zu unterscheiden. Industrielle Anwendungen sind gekennzeichnet durch einen hohen Anteil von Veränderungen der Datenbestände. Genannt seien die Stücklisten- und Arbeitsplanverwaltung, Termin- und Mengenplanungsvorgänge sowie entsprechende Rückmeldungen. Hierzu sind Bildschirmprogramme zu erstellen, mit denen der Anwender in der Fachabteilung seine Aufgaben erfüllen kann. Diese Programme werden von Spezialisten erstellt, der Benutzer wird durch das Programm geführt, seine Eingaben werden format und auf logische Plausibilität geprüft. Der Benutzer sollte immer vor der Erstellung der Programme seine spezifischen Anforderungen einbringen können, er ist jedoch an der eigentlichen Programmierung nicht beteiligt. Im praktischen Betrieb arbeitet er mit dem Programm im sogenannten Teilhaberbetrieb. Die Programme werden unter Benutzung der Befehle der Datenmanipulationssprache des DB-Systems in einer der üblichen Anwenderprogrammiersprachen geschrieben.
Update-Befehle gefährlich
In den Fachabteilungen werden sich jedoch immer situationsbedingte Informationsbedürfnisse einstellen, die mit obigen Programmen nicht voll abgedeckt werden können. Für solche Abfragen sollte den Anwendern eine einfach erlernbare Abfragesprache zur Verfügung stehen. Solche Query-Sprachen werden von den DB-Systemherstellern angeboten. Vielfach weisen diese Sprachen aber auch Update-Befehle auf. Dies ist ausgesprochen gefährlich, da der Anwender hiermit bewußt Oder unbewußt Datenbestände zerstören kann. So ist es zum Beispiel möglich, mit einem einfachen Befehl ganze Schlüsselfelder einer Datei blank zu setzen. Die Möglichkeiten des Einsatzes von Update-Komponenten der Query-Sprachen müssen für den Anwender in jedem Falle unterbunden werden. In jüngster Zeit wird zunehmend als Verkaufsargument angeführt, mit Query-Sprachen sei die Anwendung selbst in kürzerer Zeit zu programmieren, als mit konventioneller Programmierung. Hier werden unverantwortliche Erwartungshorizonte erzeugt, die bei der späteren Realisierung nie erfüllt werden können.
Dienstprogramme stark restriktiv
Datenbanken sind meist auf mehrere Jahrzehnte Lebensdauer ausgelegt. Bei solchen Zeiträumen werden allein durch den Wandel der Anforderungen strukturelle Änderungen der Datenbank nach ihrer Inbetriebnahme unvermeidlich sein. In solchen Fällen muß die Datenbank entladen, neu definiert und wieder geladen werden können. Die Hersteller bieten mehrheitlich entsprechende Dienstprogramme an. Diese weisen jedoch in ihrer Mehrzahl gravierende Restriktionen bezüglich der zulässigen Strukturveränderungen auf.
Aus Erfahrung empfiehlt es sich oft, solche Routinen anwendungsspezifisch selbst zu schreiben. Als positiver Nebeneffekt ist zu sehen, daß beim Entladen durch Überlesen Löschvorgänge ersetzt werden können, sofern die entsprechenden Datenbestände als solche erkannt werden können. Ferner sind anwendungsspezifische Unload/Load-Programme im Regelfalle schneller als entsprechende Standardroutinen. Ein gutes Datenbanksystem sollte möglichst die folgenden Standardroutinen für laufende Aufgaben der Datenbankadministration zur Verfügung stellen:
- Dienstprogramm zur Datensicherung
- Dienstprogramm zur Reorganisation
- Dienstprogramme zur Datenbankauswertung.
Beim systematischen Vergleich von Datenbanksystemen empfiehlt es sich, die in Frage kommenden Systeme anhand der in der Abbildung dargestellten Checkliste zu vergleichen. Darüber hinaus empfiehlt es sich in jedem Falle, den Hersteller auf der Basis der formulierten Aufgabenstellung in die Verantwortung einzubinden. Dies gilt sowohl für das Leistungsprofil der angebotenen DB, DC und DD-Software, als auch für die Auslegung der Hardware. Es ist nicht selten zu beobachten, daß zunächst Minimalkonfigurationen angeboten werden, die dann bei Nutzung aller Komponenten teilweise erheblich erweitert werden müssen.
Letztlich sollte man sich bei einer zu entwickelnden Datenbankanwendung immer der Verfügbarkeit eines Systemspezialisten des Herstellers versichern. Dies gilt einmal für die optimale Auslegung des Datenbank-designs unter Performance-Aspekten und zum anderen für die schnelle Fehlerbehebung, da auch Datenbanksysteme-insbesondere neuere -anfangs selten fehlerfrei sind.
Die Proceecdings dieses Symposiums sind bei der Seminargruppe der COMPUTERWOCHE CW-CSE, Friedrichstraße 31 , 8000 München 40 , zum Preis von 110 Mark erhältlich.