<\/p>\n
Eine besondere Anforderung an das Datenmodell und die Gestaltung der Formulare zur Bearbeitung der Daten stellt sich immer dann, wenn sich der Inhalt eines oder mehrerer Felder ändert, die bereits mit anderen Tabellen verknüpft wurden. Ein Beispiel sind Bestellungen, und hier speziell die Preise von Artikeln: Diese werden meist mit der Zeit teurer, oder der Mehrwertsteuersatz ändert sich und hin und wieder gibt es Währungsreformen. Welche Probleme dies mit sich bringt und wie Sie diese lösen, zeigt dieser Beitrag.<\/b><\/p>\n
Bestellungen verwalten – naive Variante<\/p>\n
Eine Artikeltabelle enthält mindestens Informationen wie den Artikelnamen und den Preis des Artikels (s. Bild 2). Zur Vereinfachung verwenden wir zunächst keine separate Kundentabelle, deren Einträge wir über ein Fremdschlüsselfeld in der Tabelle tblBestellungen <\/b>auswählen, sondern einfach nur ein Feld namens Kunde <\/b>– dieses soll lediglich den Namen des Kunden aufnehmen.<\/p>\n
![\"pic001.png\"](\"..\/fileadmin\/_temp_\/2010_04\/ZeitabhaengigeDaten_5-web-images\/pic001.png\")
<\/p>\n
Bild 1: Die denkbar einfachste Variante einer Artikeltabelle<\/span><\/b><\/p>\n Bild 2: Eine weitere Tabelle speichert die Basisdaten einer Bestellung.<\/span><\/b><\/p>\n Wie kombinieren wir nun eine Bestellung mit den gewünschten Artikeln Durch eine weitere Tabelle namens tblBestellpositionen<\/b>. Diese enthält zwei Fremdschlüsselfelder: Das erste heißt BestellungID <\/b>und verknüpft die Tabelle mit dem Feld BestellungID <\/b>der Tabelle tblBestellungen<\/b>, das zweite heißt ArtikelID <\/b>und sorgt dafür, dass Sie einer Bestellung Einträge aus der Tabelle tblArtikel <\/b>zuweisen können. Das Feld ArtikelID <\/b>der Tabelle tblBestellpositionen <\/b>legen Sie als Nachschlagefeld aus, welches die Felder ArtikelID <\/b>und Artikel <\/b>der Tabelle tblArtikel <\/b>enthält – dies spart später bei der Formulargestaltung einige Arbeit. Ein drittes Feld namens Anzahl <\/b>enthält die Anzahl des jeweiligen Artikels für diese Bestellung. Den Entwurf dieser Tabelle zeigt Bild 4 aus.<\/p>\n Bild 3: Die Tabelle tblBestellpositionen kombiniert Bestellungen und Artikel.<\/span><\/b><\/p>\n Bild 4: Datenmodell der naiven Variante der Bestellverwaltung<\/span><\/b><\/p>\n Sie finden diese Version der Bestellverwaltung übrigens in der Beispieldatei PreiseVerwalten_1.mdb<\/b>. Da wir später andere Versionen mit geänderten Datenmodellen vorstellen, haben wir für jede Version eine eigene Beispieldatenbank angelegt.<\/p>\n Das Verwalten von Bestellungen geschieht in Haupt- und Unterformular. Das Hauptformular verwendet die Tabelle tblBestellungen<\/b> als Datenherkunft und zeigt all ihre Felder an. Das Unterformular verwendet die Abfrage aus AbbBild 5. 5 als Datenherkunft. Diese Abfrage enthält alles, was wir brauchen: Das Feld ArtikelID <\/b>der Tabelle tblBestellpositionen<\/b>, um den gewünschten Artikel auszuwählen, das Feld Anzahl <\/b>sowie das Feld Preis <\/b>der Tabelle tblArtikel <\/b>– diese soll nach dem Auswählen des Artikels den Preis beisteuern. Das erste Feld, BestellungID<\/b>, wird im Unterformular nicht angezeigt, aber es soll die Beziehung zum Datensatz im Hauptformular herstellen – mehr dazu gleich.<\/p>\n Bild 5: Die neue Datenherkunft für das Unterformular<\/span><\/b><\/p>\n Wenn Sie das Unterformular sfmBestellungen <\/b>erstellt und mit den drei Feldern ArtikelID<\/b>, Anzahl <\/b>und Preis <\/b>versehen haben, können Sie es zum Hauptformular hinzufügen. Dazu öffnen Sie das Formular frmBestellungen <\/b>in der Entwurfsansicht und ziehen das Unterformular sfmBestellungen <\/b>per Drag and Drop aus dem Datenbankfenster (Access 2003 und älter) beziehungsweise dem Navigationsbereich (Access 2007 und jünger) in den Detailbereich. Das Ergebnis soll etwa wie in Bild 6 aussehen.<\/p>\n Bild 6: Entwurfsansicht des Formulars frmBestellungen mit dem Unterformular sfmBestellungen<\/span><\/b><\/p>\n Wie sorgen Sie dafür, dass das Unterformular nur solche Artikel anzeigt, die Sie für eine bestimmte Bestellung angelegt haben Dies erledigt Access unter den gegebenen Umständen automatisch: Es erkennt, dass das Unterformular eine Datenherkunft enthält, deren Fremdschlüsselfeld mit dem Primärschlüsselfeld der Datenherkunft des Hauptformulars verknüpft ist, und stellt die beiden Eigenschaften Verknüpfen von <\/b>und Verknüpfen nach <\/b>des Unterformular-Steuerelements auf die Namen der an der Verknüpfung beteiligten Felder ein.<\/p>\n Wenn Sie das Formular nun in der Formularansicht öffnen und im Hauptformular eine Bestellung angelegt haben, können Sie über das Kombinationsfeld im Unterformular ganz einfach Artikel zur Bestellung hinzufügen (s. Bild 8).<\/p>\n Bild 7: Eingabe der Artikel einer Bestellung<\/span><\/b><\/p>\n Bild 8: Die Einstellung des Standardwerts sorgt dafür, dass das Feld beim Anlegen eines neuen Datensatzes den angegebenen Wert erhält.<\/span><\/b><\/p>\n Meldung bei doppelten Artikeln vermeiden<\/b><\/p>\n Da wir weiter oben einen zusammengesetzten, eindeutigen Index für die beiden Felder BestellungID <\/b>und ArtikelID <\/b>der Tabelle tblBestellpositionen <\/b>erstellt haben, zeigt Access eine Meldung an, wenn Sie versuchen, einen Artikel der gleichen Bestellung zweimal zuzuweisen.<\/p>\n Diese Meldung ist für den Benutzer jedoch unter Umständen nicht besonders aussagekräftig, sodass wir diese durch eine eigene Meldung ersetzen. Auf diese Meldung können Sie im Ereignis Bei Fehler <\/b>des Unterformulars reagieren. Wählen Sie für diese Eigenschaft des Unterformulars den Wert [Ereignisprozedur] <\/b>aus und klicken Sie auf die Schaltfläche mit den drei Punkten. Der VBA-Editor öffnet sich und zeigt gleich eine leere Prozedur an, die Access beim Auftreten eines Fehlers im Formular ausführt.<\/p>\n Ergänzen Sie diese Prozedur wie in Listing 1<\/a>. Die erste Zeile prüft die Fehlernummer, die in unserem Fall 3022 <\/b>lautet. Die Fehlernummer finden Sie heraus, indem Sie in der gleichen Prozedur ganz oben die folgende Zeile einfügen:<\/p>\n Listing 1: Abfangen des Fehlers, der beim mehrfachen Anlegen eines Artikels in derselben Bestellung ausgelöst wird<\/p>\n Die erste Zeile innerhalb der If…Then<\/b>-Bedingung gibt eine Meldung aus, die den Benutzer darauf hinweist, dass er einen bereits vorhandenen Artikel zur Bestellung hinzugefügt hat (s. Bild 9). Die zweite macht die zuletzt am aktuell bearbeiteten Datensatz durchgeführten änderungen rückgängig (beim Neuanlegen einer Bestellposition wird diese wieder entfernt, und wenn der Benutzer den Artikel einer bereits bestehenden Bestellposition geändert hat, wird der zuvor ausgewählte Artikel wiederhergestellt). Fertig: Sie können nun einfache Bestellungen eingeben.<\/p>\n Bild 9: Diese Meldung erscheint, wenn ein Artikel mehrfach zu einer Bestellung hinzugefügt wird.<\/span><\/b><\/p>\n Probleme beim ändern des Preises<\/b><\/p>\n Mit der aktuellen Lösung geben Sie die Daten ein, die beispielsweise zum Erstellen von Berichten zur Ausgabe von Bestellscheinen oder Rechnungen nötig sind (mit Ausnahme der Kundendaten: Wir haben hier nur den Kundennamen in die Tabelle tblBestellungen <\/b>eingetragen – normalerweise würden wir hier auf eine Tabelle namens tblKunden <\/b>mit den detaillierten Kundendaten verweisen).<\/p>\n Diese Lösung funktioniert so lange zuverlässig, bis sich der Preis eines Artikels ändert, der bereits in einer Bestellung erfasst wurde. Nehmen wir an, Sie hätten eine Bestellung aufgenommen, bei der ein Artikel 10 Euro kostet, und dem Kunden eine anschließend eine entsprechende Rechnung geschickt. Kurze Zeit später erhöht sich der Preis des Artikels auf 11 Euro. Der Kunde meldet sich, weil er die Rechnung verlegt hat und eine Kopie der Rechnung benötigt. Diese lässt sich aus der Anwendung heraus nun zwar noch erstellen, allerdings wird der neue Preis von 11 Euro für den Artikel ausgewiesen.<\/p>\n Behandlung von Preisänderungen<\/b><\/p>\n Grundsätzlich gibt es mehrere Möglichkeiten, das Problem zu umgehen. Die erste und einfachste ist, dass die Rechnung als PDF-Dokument ausgegeben und archiviert wird. Damit wäre dem Auftragnehmer und auch dem Kunden gedient, denn beide können nun auf eine korrekte Version der Rechnung zugreifen.<\/p>\n <\/p>\n Sobald der Benutzer der Bestellverwaltung jedoch einmal eine Statistik etwa über den Umsatz erstellen möchte und dabei die Tabellen tblBestellungen<\/b>, tblBestellpositionen <\/b>und tblArtikel <\/b>hinzuzieht, erhält er nach einer Preisänderung eines Artikels, der in einer Bestellung enthalten ist, ein falsches Ergebnis. Also müssen wir einen anderen Weg finden, um die Preise in irgendeiner Weise zu speichern. Dabei gibt es zwei Varianten:<\/p>\n €¢ Die einfachere Variante verwendet ein Feld in der Tabelle tblBestellpositionen<\/b>, das den zum Zeitpunkt der Bestellung gültigen Preis für den Artikel enthält.<\/p>\n €¢ Die zweite Möglichkeit ist das Speichern der verschiedenen Preise für einen Artikel im Laufe der Zeit. Dazu ist eine weitere Tabelle nötig, welche den Preis und den Zeitraum der Gültigkeit des Preises enthält.<\/p>\n Preis in der Bestellposition speichern<\/b><\/p>\n Die Variante mit dem zusätzlichen Preis-Feld hat zusätzlich den Charme, dass Sie einen Preis je nach Kunde oder auch nach Bestellmenge mit einem individuellen Rabatt versehen können. Der Nachteil ist, dass es keine genauen Informationen darüber gibt, wann und wie sich der Preis eines Artikels im Laufe der Zeit geändert hat. Sie können lediglich den aktuellen Preis in der Tabelle tblArtikel <\/b>betrachten. Einen zeitlichen Verlauf des Preises erhalten Sie nicht: Selbst das Kontrollieren aller in der Tabelle tblBestellpositionen <\/b>gespeicherten Datensätze für diesen Artikel liefert keine genauen Informationen, wenn Sie dort auch die individuelle Rabattierung erlauben. Bild 10 zeigt die änderung der Tabelle tblBestellpositionen<\/b> für diese Variante (diese Version finden Sie übrigens in der Beispieldatenbank PreiseVerwalten_2.mdb<\/b>).<\/p>\n Bild 10: Die Tabelle tblBestellpositionen mit einem zusätzlichen Feld zum Speichern eines individuellen Artikelpreises<\/span><\/b><\/p>\n Desweiteren ändert sich die Datenherkunft des Unterformulars im Formular frmBestellungen<\/b>. Die Abfrage qryBestellpositionen <\/b>sieht nunmehr wie in Bild 11 aus. Die Tabelle tblArtikel<\/b> wird dort gar nicht mehr benötigt, da das für die Bestellung relevante Feld Preis <\/b>bereits in der Tabelle tblBestellpositionen <\/b>enthalten ist.<\/p>\n Bild 11: Datenherkunft des Unterformulars zur Anzeige der Bestellpositionen<\/span><\/b><\/p>\n Fehlt noch eine kleine änderung im Unterformular sfmBestellungen<\/b>. Damit der Benutzer den Preis des Artikels nicht jedes Mal selbst eintragen muss, soll standardmäßig der aktuell in der Tabelle tblArtikel <\/b>gespeicherte Preis in das Feld Preis<\/b> der Tabelle tblBestellpositionen <\/b>geschrieben werden. Dies gelingt leider nicht über die Einstellung eines entsprechenden Standardwerts, da diese Eigenschaft nur statische Werte oder Access-Funktionen, aber keine benutzerdefinierten Funktionen erlaubt. Wir müssen also dafür sorgen, dass das Unterformular beim Anlegen eines neuen Datensatzes in der Tabelle tblBestellpositionen <\/b>und hier speziell nach dem Auswählen eines neuen Artikels den aktuellen Preis des hinzugefügten Artikels ausliest und diesen in das Feld Preis <\/b>einträgt.<\/p>\n Das richtige Ereignis hierfür heißt Nach Aktualisierung <\/b>und wird durch das Kombinationsfeld zur Anzeige des Artikels ausgelöst.<\/p>\n Die fertige Prozedur sieht wie folgt aus und verwendet die DLookup<\/b>-Funktion, um den Inhalt des Feldes Preis <\/b>aus der Tabelle tblArtikel <\/b>für den Datensatz auszulesen, dessen ArtikelID <\/b>mit dem aktuellen Wert des Kombinationsfeldes übereinstimmt:<\/p>\n Der Benutzer kann diesen Preis dann nach seinem Gusto mit einem Rabatt versehen.<\/p>\n Preis in Abhängigkeit von der Zeit speichern<\/p>\n Die detaillierte Notation des Preisverlaufs über eine zusätzliche Tabelle der Preise der verschiedenen Artikel liefert hier exaktere Informationen. Sie können in dieser Tabelle den Preis zu einem bestimmten Zeitpunkt eindeutig ermitteln. Und auch auf die individuelle Rabattierung eines Artikels brauchen Sie nicht zu verzichten: Dies ist weiterhin möglich, und zwar über ein dafür vorgesehenes Feld in der Tabelle tblBestellpositionen<\/b>, das den Rabatt in Prozent enthält.<\/p>\n Schauen wir uns zunächst die notwendigen änderungen am Datenmodell an, damit die Preise zeitabhängig gespeichert werden können – die Version der Beispieldatenbank finden Sie in der Datei PreiseVerwalten_3.mdb<\/b>. Das Feld Preis<\/b> kann in der Tabelle tblArtikel <\/b>entfallen, da wir es in eine weitere Tabelle namens tblPreise <\/b>auslagern. Diese sieht wie in Bild 13. Auch in der Tabelle tblBestellpositionen <\/b>ist kein Platz mehr für eine Preisangabe. Da es für jeden Artikel mehrere Preise geben kann, benötigt die Tabelle ein Fremdschlüsselfeld zur Verknüpfung mit dem jeweiligen Artikel. Für die Angabe des Zeitraums gibt es wiederum verschiedene Möglichkeiten:<\/p>\n Bild 12: Preise der Artikel in Abhängigkeit vom Datum<\/span><\/b><\/p>\n Bild 13: Aktuelle Version des Datenmodells der Anwendung<\/span><\/b><\/p>\n €¢ Sie geben Startdatum und Enddatum des Gültigkeitszeitraums eines Preises für einen Artikel an.<\/p>\n €¢ Sie geben nur das Startdatum des Gültigkeitszeitraumes des Preises eines Artikels an.<\/p>\n €¢ Sie geben nur das Enddatum des Gültigkeitszeitraums des Preises eines Artikels an.<\/p>\n Alle Varianten haben Vor- und Nachteile. Die erste Variante beispielsweise ist fehleranfällig. So kann es passieren, dass es einen Zeitraum gibt, für den ein Artikel gar keinen Preis hat. Oder die Zeiträume zweier Preisangaben überschneiden sich – beides wäre keine gute Grundlage für die zuverlässige Lieferung von Daten.<\/p>\n Wenn Sie nur das Startdatum des Gültigkeitszeitraums oder nur das Enddatum eingeben, erhalten Sie auch nicht auf jeden Fall zu jedem Zeitpunkt nur einen gültigen Preis. Es kann auch sein, dass der Benutzer zwei Preise für ein und dasselbe Start- oder Enddatum einträgt.<\/p>\n In allen drei Fällen ist die Ermittlung des jeweils gültigen Preises mit Aufwand verbunden: Bereits die Anzeige des aktuellen Preises im Unterformular des Formulars frmBestellungen <\/b>zieht eine entsprechend aufwendigere Abfrage als in der zuvor beschriebenen Version nach sich. Und auch die spätere Auswertung kann nicht gleich über einen in der Tabelle tblBestellpositionen <\/b>enthaltenen Preis erfolgen, sondern muss über den Umweg von tblArtikel <\/b>und tblPreise <\/b>geschehen.<\/p>\n Wir schauen uns die Lösung zunächst unter Angabe des kompletten Gültigkeitszeitraums des Preises für einen Artikel an, also unter Verwendung der Felder GueltigVon <\/b>und GueltigBis<\/b>.<\/p>\n Artikelpreise verwalten<\/b><\/p>\n Bevor wir uns der Umgestaltung des Formulars frmBestellungen <\/b>und dort speziell des Unterformulars sfmBestellungen <\/b>widmen, müssen wir überhaupt eine Möglichkeit schaffen, Preise und Zeiträume für die Preise einzugeben.<\/p>\n Dies geschieht ebenfalls in einer Kombination aus Haupt- und Unterformular. Das Hauptformular heißt frmArtikel <\/b>und verwendet die Tabelle tblArtikel <\/b>als Datenherkunft. Das Unterformular sfmArtikel <\/b>basiert auf einer Abfrage, die alle Felder der Tabelle tblPreise <\/b>enthält, wobei diese nach dem Feld GueltigVon <\/b>aufsteigend sortiert werden (s. Bild 14).<\/p>\n Bild 14: Die Datenherkunft des Unterformulars sfmArtikel sortiert die Preise eines Artikels nach dem Beginn des Gültigkeitszeitraums.<\/span><\/b><\/p>\n Das Unterformular zeigt die drei Felder Preis<\/b>, GueltigVon <\/b>und GueltigNach <\/b>der Tabelle tblPreise <\/b>an. Durch die Eigenschaften Verknüpfen von <\/b>und Verknüpfen nach <\/b>des Unterformularsteuerelements zeigt das Unterformular nur diejenigen Preise an, die zum aktuell im Hauptformular angezeigten Artikel gehören (s. Bild 15).<\/p>\n Bild 15: Dieses Formular dient der Eingabe der Preise eines Artikels und der entsprechenden Gültigkeitszeiträume.<\/span><\/b><\/p>\n Bestellformular für Preise mit Gültigkeitszeiträumen nachrüsten<\/b><\/p>\n Nun wenden wir uns der Anpassung des Unterformulars sfmBestellungen <\/b>zu. Zunächst benötigen wir eine Datenherkunft, welche die Auswahl der Artikel für die aktuelle Bestellung ermöglicht und für jeden Artikel den Preis anzeigt, der zum im Feld Bestelldatum <\/b>des Hauptformulars angegebenen Zeitpunkt gültig ist. Die Abfrage aus Bild 16 liefert genau diese Datensätze.<\/p>\n Bild 16: Diese Abfrage liefert einen Artikel samt aktuell gültigem Preis.<\/span><\/b><\/p>\n Wenn wir diese Abfrage als Datenherkunft des Unterformulars sfmBestellungen <\/b>einstellen, erscheint für eine bereits vorhandene Bestellung auch der richtige Preis für eine Bestellposition (s. Bild 17). Allerdings lassen sich damit keine neuen Bestellpositionen anlegen, da die zugrunde liegende Abfrage nicht aktualisierbar ist.<\/p>\n Bild 17: Bestellpositionen mit Preisen aus Gültigkeitszeiträumen lassen sich nicht aktualisieren und auch nicht neu anlegen.<\/span><\/b><\/p>\n Aus diesem Dilemma kommen wir nur heraus, wenn wir ein Feld namens Preis<\/b> in der Tabelle tblBestellpositionen <\/b>belassen und den Preis für diesen Artikel aus der Tabelle tblPreise <\/b>beim Auswählen des Artikels einer Bestellposition ermitteln und in dieses Feld eintragen. Dies scheint insgesamt ein brauchbarer Kompromiss: Immerhin erhalten wir so die Möglichkeit zurück, den Preis individuell je nach Kunde und\/oder Menge anzupassen, und führen gleichzeitig eine Historie der Preise der Artikel mit.<\/p>\n Wir wechseln von der in einer Sackgasse steckenden Beispieldatenbank PreiseVerwalten_3.mdb <\/b>zur finalen Version PreiseVerwalten_4.mdb <\/b>und nehmen dort weitere änderungen vor.<\/p>\n Zunächst fügen wir der Tabelle tblBestellpositionen <\/b>wieder das Feld Preis <\/b>hinzu. Dann ändern wir die Abfrage, die als Datenherkunft für das Unterformular sfmBestellungen<\/b> dient, zurück auf den Stand aus Bild 11. In dieser Version der Beispieldatenbank benötigen wir eine Ereignisprozedur, die nach dem Aktualisieren des Kombinationsfeldes zur Auswahl des Artikels einer Bestellposition ausgelöst wird. Diese hat den Preis aus den Artikelstammdaten ausgelesen und diesen in das Feld Preis <\/b>des aktuellen Datensatzes der Tabelle tblBestellpositionen <\/b>eingetragen.<\/p>\n![\"pic002.png\"](\"..\/fileadmin\/_temp_\/2010_04\/ZeitabhaengigeDaten_5-web-images\/pic002.png\")
<\/p>\n![\"pic003.png\"](\"..\/fileadmin\/_temp_\/2010_04\/ZeitabhaengigeDaten_5-web-images\/pic003.png\")
<\/p>\n![\"pic004.png\"](\"..\/fileadmin\/_temp_\/2010_04\/ZeitabhaengigeDaten_5-web-images\/pic004.png\")
<\/p>\n![\"pic005.png\"](\"..\/fileadmin\/_temp_\/2010_04\/ZeitabhaengigeDaten_5-web-images\/pic005.png\")
<\/p>\n![\"pic006.png\"](\"..\/fileadmin\/_temp_\/2010_04\/ZeitabhaengigeDaten_5-web-images\/pic006.png\")
<\/p>\n![\"pic007.png\"](\"..\/fileadmin\/_temp_\/2010_04\/ZeitabhaengigeDaten_5-web-images\/pic007.png\")
<\/p>\n![\"pic008.png\"](\"..\/fileadmin\/_temp_\/2010_04\/ZeitabhaengigeDaten_5-web-images\/pic008.png\")
<\/p>\nMsgBox "Fehlernummer: " & DataErr<\/pre>\n
Private Sub Form_Error(DataErr As Integer, Response As Integer)\r\n If DataErr = 3022 Then\r\n MsgBox "Sie haben diesen Artikel bereits zur Bestellung hinzugefügt." & vbCrLf & vbCrLf _\r\n & "ändern Sie die Anzahl, um den Artikel mehrfach zu bestellen.", _\r\n vbOKOnly + vbExclamation, "Doppelter Artikel"\r\n Me.Undo\r\n Response = acDataErrContinue\r\n End If\r\nEnd Sub<\/pre>\n
![\"pic009.png\"](\"..\/fileadmin\/_temp_\/2010_04\/ZeitabhaengigeDaten_5-web-images\/pic009.png\")
<\/p>\n![\"pic010.png\"](\"..\/fileadmin\/_temp_\/2010_04\/ZeitabhaengigeDaten_5-web-images\/pic010.png\")
<\/p>\n![\"pic011.png\"](\"..\/fileadmin\/_temp_\/2010_04\/ZeitabhaengigeDaten_5-web-images\/pic011.png\")
<\/p>\nPrivate Sub ArtikelID_AfterUpdate()\r\n Me!Preis = DLookup("Preis", "tblArtikel", _\r\n "ArtikelID = " & Me!ArtikelID)\r\nEnd Sub<\/pre>\n![\"pic012.png\"](\"..\/fileadmin\/_temp_\/2010_04\/ZeitabhaengigeDaten_5-web-images\/pic012.png\")
<\/p>\n![\"pic013.png\"](\"..\/fileadmin\/_temp_\/2010_04\/ZeitabhaengigeDaten_5-web-images\/pic013.png\")
<\/p>\n![\"pic014.png\"](\"..\/fileadmin\/_temp_\/2010_04\/ZeitabhaengigeDaten_5-web-images\/pic014.png\")
<\/p>\n![\"pic015.png\"](\"..\/fileadmin\/_temp_\/2010_04\/ZeitabhaengigeDaten_5-web-images\/pic015.png\")
<\/p>\n![\"pic016.png\"](\"..\/fileadmin\/_temp_\/2010_04\/ZeitabhaengigeDaten_5-web-images\/pic016.png\")
<\/p>\n![\"pic018.png\"](\"..\/fileadmin\/_temp_\/2010_04\/ZeitabhaengigeDaten_5-web-images\/pic018.png\")
<\/p>\n
![\"pic020.png\"](\"..\/fileadmin\/_temp_\/2010_04\/ZeitabhaengigeDaten_5-web-images\/pic020.png\")
<\/p>\n![\"pic019.png\"](\"..\/fileadmin\/_temp_\/2010_04\/ZeitabhaengigeDaten_5-web-images\/pic019.png\")
<\/p>\n![\"pic021.png\"](\"..\/fileadmin\/_temp_\/2010_04\/ZeitabhaengigeDaten_5-web-images\/pic021.png\")
<\/p>\n