Mehrere miteinander verknüpfte Tabellen!
Genau das habe ich vorgeschlagen.
Und deshalb kann ich Excel-Tabellen nicht für mein Musiknotenarchiv gebrauchen.
Es ist halt die Frage, wie die Datenbank ausgestaltet werden soll. Welches Programm - Da muß jeder selber gucken, womit er am besten klar kommt. Ich arbeite halt schon fast 20 Jahre mit Access. Da steig ich nur um, wenn's unbedingt sein muß.
Bevor es Excel gab, hab ich schon etwas mit dbase "herumprobiert". Bis etwa 1995 organisierte ich alles mögliche mit Excel-Tabellen. Man mußte bei Änderungen höllisch aufpassen, dass man nicht durch irgendwelche Flüchtigkeitsfehler Datensätze durcheinander brachte. Als ich "Works" in einem Office-Paket fand, experimentierte ich auch damit, stellt mich aber schließlich im Bereich Buchhaltung und Archiv-Verwaltung (Bibliothek, Audiothek, Videothek, Notenarchiv) komplett auf Access um. Mit den Jahren wächst man halt rein.
In Access legte ich für die Verwaltung und Nutzung des Notenarchivs unterschiedliche Formulare an, die mir bei der Eingabe und Auswertung der Daten helfen.
Beispiel Unterrichtsvorbereitung:
Ich habe mehrere Musikgruppen und möchte für jede dieser Gruppen einen neuen Stoffplan erstellen.
Also öffne ich die Datenbank, in der diese Gruppen angezeigt werden.
In dieser Datenbank ist ein Formular hinterlegt, in dem zu jeder Gruppe ein Unterformular mit Terminen und Unterrichtsinhalten aufgerufen und weiter ausgefüllt werden kann.
Das Feld, in das der Musiktitel eingegeben wird, ist mit einer Auswahlliste verknüpft. Wenn ich beginne, einen Musiktitel zu schreiben, wird der Text automatisch mit den hinterlegten Möglichkeiten vervollständigt. So wird sichergestellt, dass identische Liedtitel auch immer identisch geschrieben werden.
In einem anderen Formular kann ich mir anzeigen lassen:
1. Methodischer Aufbau einer Unterrichtsstunde mit den ausgewählten Aufgaben
2. Literaturverweise: Wird im methodischen Aufbau der Unterrichtsstunde ein Musiktitel genannt, kann ich dieser gefilterten Liste entnehmen, in welchem Buch auf welcher Seite die Noten gefunden werden können. Des weiteren wird zu jeder gefundenen Version angezeigt, wer den Satz bearbeitet hat, für welche Besetzung die Bearbeitung gedacht ist, in welcher Tonart sie notiert ist usw.
3. Unterrichtshilfen: Wenn zu einem Musikstück methodische Hinweise, Werkbetrachtung oder anderes erarbeitet wurden, verweist ein Link auf den Ordner, wo all dies abgelegt wurde; über einen anderen Link kann man ein hinterlegtes PDF direkt aufrufen.
Diese und andere Informationen sind in verschiedenen eigens dafür strukturierten Tabellen eingetragen, die den eigentlichen Datenbestand der Datenbank ausmachen. Sie können für sich allein betrachtet (Lebensdaten und sonstige Informationen zu einem Komponisten oder Texter; Informationen über ein (Noten-)Buch; Informationen über einen Verlag; Informationen über ein Musikstück; Inhaltsverzeichnisse von Notenbüchern; Unterrichtsinhalte usw.) oder zueinander in Beziehung gesetzt werden. Abfragen und Formulare haben sich in meinen Datenbanken zu komplexen "Konstrukten" entwickelt, die ich häufig getrennt vom eigentlichen Datenbestand (den Tabellen) in einer anderen Access-Datenbank abspeichere.
Wenn man von Anfang an darauf achtet, dass es eindeutige Verknüpfungsmöglichkeiten zwischen den verschiedenen Tabellen gibt, ist der Rest eigentlich nicht schwer. Wenn man merkt, das irgendetwas fehlt, läßt es sich nachbessern.
Die Verteilung der Informationen auf mehrere Datenbanken ist auch dann sinnvoll, wenn man ausschließlich eine Inventur der Noten anlegen möchte. Aus verschiedenen Gründen sind die Lebensdaten der Komponisten interessant. Es würde aber die Datenbank unnötig aufblähen, wenn man diese Information an jeden Musiktitel schreiben würde. Also legt man eine Tabelle für Komponisten an, in der man solche und andere Daten ein einziges Mal einträgt. Bei Bedarf kann man diese Informationen mit den Musikstücken verknüpfen. Ähnliches gilt für detaillierte Angaben über Notenbücher.
Beispiel Konzertprogramm erstellen:
Auch dafür legt man miteinander zu verknüpfende Tabelle an. Eine Tabelle enthalt diverse Informationen zu Konzerttermin wie Datum, Veranstalter, Veranstaltungsort etc. Eine andere Tabelle enthält die ausgewählten Titel und Programmnummern, um die Titel in Programmfolge geordnet anzeigen zu können. Bei der Ausarbeitung eines Konzertprogramms kann man mit ganz verschiedenen Auswahlkriterien arbeiten. Formulare lassen sich so gestalten, das sich die Noten nach beliebigen Kriterien gefiltert anzeigen lassen.
Beispiel Notenverleih
Da wird es schon etwas komplizierter, weil mit Hilfe von zwei verschiedenen Tabellen Berechnungen gemacht werden müssen, um automatisch anzeigen zu können, wieviele Noten "unterwegs" sind.
Der Notenkatalog muß ein Zahlenfeld enthalten, in dem angegeben wird, wie viele Exemplare von einem bestimmten Notenbuch oder einer Stimme insgesamt vorhanden sind.
In einer anderen Tabelle werden die Personen aufgelistet, die die Noten ausgeliehen haben. Mit Hilfe von Ausleihtermin und Rückgabetermin kann der Status festgestellt werden. Das ist ein Lagerhaltungs-Projekt.
Beispiel Inventur
Wenn der ganze Notenbestand neu geordnet wird, macht es Sinn, eine Tabelle anzulegen, die anzeigt, wo die verschiedenen Noten abgelegt werden. In dieser Tabelle sind detaillierte Angaben zur Musik überflüssig. Die Ausgestaltung der Datenbank ist Geschmacksache und eine Frage des Bedarfs.
Es macht keinen Sinn hier noch weiter ins Detail zu gehen. Darüber haben andere dicke Wälzer geschrieben.
Mir ist klar, dass die von mir angedeuteten Projekte weit über einen einfachen Katalog der Notensammlung hinaus gehen. Die Frage ist halt, was man will. Mir ist eine simple Liste zu wenig. Aber auch die läßt sich in Access erstellen und ist dann meiner Meinung ebenfalls auf Anhieb beherrschbar.
Gruß
Lisa
