PDF file - IDB - Universität Bonn

Diplomarbeit
Entwurf und Implementierung eines
datenbankgestützten Werkzeugs zur
harmonischen Analyse musikalischer Werke
Anita Scholz (geb.Sosnecki)
Rheinische Friedrich-Wilhelms-Universität Bonn
Institut für Informatik III
Gutachter:
Prof. Dr. Rainer Manthey
Prof. Dr. Michael Clausen
Hiermit versichere ich, dass ich die Arbeit selbständig verfasst und keine anderen als die
angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich gemacht habe.
Bonn, 31. März 2008
Danksagung
Bedanken möchte ich mich vor allem bei Prof. Dr. Manthey für die interessante Aufgabenstellung, seine konstruktiven Anregungen und für den immer wieder motivierenden Zuspruch.
Weiterhin möchte ich mich bei der gesamten Arbeitsgruppe Clausen, insbesondere Christian
Fremerey, für die Bereitstellung zahlreicher Marterialien und Werkzeuge bedanken.
Desweiteren möchte ich mich bei Kristina Barth bedanken, die sich bereit erklärt hat, diese
Arbeit Korrektur zu lesen.
Ganz besonderer Dank geht an meinen Ehemann Sascha, der mich trotz eigener Herausforderungen während der gesamten Arbeit sowohl moralisch als auch fachlich unterstützt
hat.
Ebenfalls bedanken möchte ich mich bei meinen Eltern Renate und Andrzej Sosnecki, ohne
deren Unterstützung mein Studium und diese Arbeit nicht möglich gewesen wäre.
5
Inhaltsverzeichnis
1 Einleitung
9
2 Relevante Grundlagen aus der Musikwissenschaft
2.1
2.2
2.3
2.4
Allgemeine Musiklehre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.1
Musiknotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.2
Intervalle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.3
Tonleitern und Tonarten . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.4
Akkorde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Grundlagen der harmonischen Analyse . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.1
Generalbass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.2
Stufentheorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.3
Funktionstheorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.4
Kadenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.5
Modulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Digitale Musikrepräsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.1
MIDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.2
Lilypond
2.3.3
MusicXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Computergestützte harmonische Analyse . . . . . . . . . . . . . . . . . . . . . . 39
2.4.1
Humdrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.4.2
Rubato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3 Relevante Grundlagen aus der Informatik
3.1
3.2
13
43
Relationale Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.1
Relationen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.1.2
Konzeptuelle Modellierung mit ER-Diagrammen . . . . . . . . . . . . . 46
3.1.3
Umsetzung von ER-Diagrammen in relationale Schemata . . . . . . . . 49
3.1.4
SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7
8
Inhaltsverzeichnis
3.2.1
Die Java-Plattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.2.2
Grundlagen der Java-Programmierung . . . . . . . . . . . . . . . . . . . 58
3.2.3
Objektorientierte Programmierung mit Java . . . . . . . . . . . . . . . . 61
3.2.4
Programmierung grafischer Oberflächen mit Swing . . . . . . . . . . . . 64
3.2.5
JOGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.2.6
JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4 Partiturdarstellung im relationalen Datenmodell
75
4.1
Motivation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.2
Konzeptuelle Modellierung von Musikelementen . . . . . . . . . . . . . . . . . . 77
4.3
Entwurf der ScoreStore-Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.3.1
Primärdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.3.2
Sekundärdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5 Harmonische Analyse mit SQL
99
5.1
Bestimmung zeitgleich erklingender Töne . . . . . . . . . . . . . . . . . . . . . 99
5.2
Intervallbestimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.3
Akkordbestimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.4
Funktions- und Stufenbestimmung . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.4.1
Bestimmung mit gegebener Grundtonart . . . . . . . . . . . . . . . . . . 109
5.4.2
Unbekannte Tonart und Tonartwechsel . . . . . . . . . . . . . . . . . . . 118
6 Architektur und Funktionalität des Analysesystems
123
6.1
Aufbereitung von Musikdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
6.2
Hinzufügen von Werken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
6.3
6.2.1
Datenimport durch ScoreCompiler . . . . . . . . . . . . . . . . . . . . . 126
6.2.2
Vorbereitung für ScoreViewer . . . . . . . . . . . . . . . . . . . . . . . . 128
Analyse von Musikwerken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
6.3.1
ScoreAnalyzer
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
6.3.2
ScoreViewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
7 Zusammenfassung und Ausblick
133
Literaturverzeichnis
135
1 Einleitung
Die harmonische Analyse musikalischer Werke gehört zum zentralen Aufgabenbereich der
Musikwissenschaft und ist eine sehr anspruchsvolle und zeitintensive Aufgabe. Sie basiert
auf der Harmonielehre, die als systematische Erfassung von akkordischen Zusammenhängen
ausgehend von Partiturinformationen eines Musikwerkes verstanden wird. Mittels der Stufenund Funktionstheorie werden die harmonischen Abläufe von Musikwerken bestimmt und
beschrieben. Insbesondere die Funktionstheorie, die von Hugo Riemann begründet wurde,
soll anhand von Funktionen die hörbaren Spannungsbeziehungen zwischen einzelnen Akkorden erfassen (z. B. der Ruheklang Tonika). Derselbe Akkord kann dabei in verschiedenen
Zusammenhängen unterschiedliche Funktionen haben. Die dafür benötigten Informationen
berücksichtigen den gesamten musikalischen Kontext der Musikwerke und sind ausgehend von
Partiturinformationen nur schwer herleitbar. So lässt sich bspw. die Tonart aufgrund von Modulationen und Nichteinhaltung bestimmter Regeln nur sehr schwer bestimmen (z. B. Der letzte
Ton bestimmt den Grundton der Tonart!). In manchen Situationen ist es daher notwendig,
die Tonart durch Vorspielen vom Benutzer absichern zu lassen. Die Voraussetzung für beide
Theorien ist zunächst allerdings die Bestimmung von Akkorden ohne die Berücksichtigung
eines tonalen Zusammenhangs.
Einige anspruchsvolle und zeitintensive Aufgaben bei der Bearbeitung harmonischer Fragestellungen können mittels Computereinsatz erleichtert und zum Teil sogar automatisiert werden.
Beispielsweise können Analyseprogramme Musikwissenschaftlern als Hilfsmittel zur Verkürzung
der Analysezeit dienen, indem sie eine automatische Akkorduntersuchung durchführen. Gleichzeitig können sie als Hilfestellung bei der wesentlich komplexeren Aufgabe der Funktionsuntersuchung dienen. Desweiteren ist ein Einsatz als Lernhilfe oder zur Kontrolle der manuellen
Analyse möglich.
Eine weitere Einsatzmöglichkeit solcher Systeme jenseits der reinen harmonischen Analyse
könnte sein, gleichzeitig mehrere Werke zu betrachten und diese auf Ähnlichkeiten hin zu
untersuchen (z. B. Gib mir alle Positionen im Werk A und B aus, an denen gleichzeitig
ein G-Dur Akkord auftritt!). Eine interessante, aber andererseits auch deutlich komplexere
Fragestellung ist: Gib mir alle Akkorde und Zeitpunkte im Werk A und B aus, wo sowohl
9
10
Einleitung
die Akkorde gleich sind als auch im Liedtext das Wort Gott vorkommt! Dazu muss einerseits
eine Beziehung zwischen dem Liedtext und dem Notentext eines Werkes bestehen, andererseits muss die Datenkodierung der Werke derart gewählt werden, dass sie miteinander
verglichen werden können. Allerdings existiert bis dato keine umfassende, breit eingesetzte
Standardsoftware zur computergestützten harmonischen Analyse, sondern nur ein Bouquet
vieler kleiner spezialisierter Tools, die sich meist auf die Akkorduntersuchung beschränken.
Zumeist existiert auch keine benutzerfreundliche grafische Oberfläche für diese Analysetools, so
dass sie eher selten zum Einsatz kommen. Das bekannteste Analysewerkzeug ist das auf UnixSystemen verfügbare Humdrum-Toolkit, das z. T. sehr komplexe Untersuchungsmöglichkeiten
bietet. Für die Durchführung der harmonischen Analyse mit Humdrum werden allerdings tiefe
Kenntnisse über die Arbeitsweise und Funktionalität des Systems benötigt, so dass es für
Nicht-Unix-Experten schwer einsetzbar ist. Im Übrigen gibt es keine grafische Oberfläche, was
die Benutzung dieser Analyseprogramme noch weiter erschwert.
Alle existierenden Systeme zur harmonischen Analyse verwenden eigene Notationsformate und
Implementierungen für die Verwaltung der Musikinformationen. Die Benutzung relationaler
Datenbanken im Bereich Musik beschränkt sich dabei bislang auf die Speicherung von Metadaten wie z. B. Titel, Komponist oder Interpret von Musikwerken. Der Vorteil von relationalen
Datenbanken besteht darin, dass die in Partituren vorkommenden Musikinformationen mittels
eines relationalen Schemas in natürlicher Weise modelliert werden können. In der Musik betrifft
dies z. B. die Beziehung zwischen Intervallen und Noten. So lässt sich die Intervallbeziehung,
zu der immer genau zwei Noten gehören, sehr gut durch eine Relation ausdrücken. Desweiteren
können alle Vorteile des zu jeder relationalen Datenbank gehörenden Datenbankmanagementsystems (DBMS) genutzt werden (z. B. interne Speicherung, Datenintegrität). Die Realisierung
des Schemas erfolgt mit Hilfe der standardisierten Datenbanksprache SQL, die von jedem
DBMS verstanden wird, so dass die Umsetzung grundsätzlich unabhängig von einem konkreten
DBMS ist. Desweiteren können mittels SQL unterschiedliche Sichten auf die Daten spezifiziert
werden. Dabei erlaubt SQL, sich auf die inhaltlichen Zusammenhänge einer Anfrage zu konzentrieren, da die technische Realisierung nicht von zentraler Bedeutung ist. So können vom
DBMS transparent Optimierungen komplexer Anfragen durchgeführt werden, um Anfragen
auch auf großen Datenbeständen effizient auswerten zu können. Durch die weite Verbreitung
von relationalen Datenbanken und SQL sind darüber hinaus gute Anbindungsmöglichkeiten
für externe Anwendungen vorhanden.
In dieser Arbeit soll untersucht werden, in wieweit sich relationale Datenbanken für die Analyse
musikalischer Werke eignen. Dabei wird insbesondere das Teilgebiet der harmonischen Analyse
betrachtet. Im Fokus liegt zunächst eine für die harmonische Analyse geeignete Modellierung
11
wichtiger Musikparameter von Partituren sowie der musiktheoretischen Grundlagen, die auf
ein relationales Datenbankschema übertragen werden. Darauf aufbauend werden mittels SQL
die aus musiktheoretischer Sicht grundlegendsten und wichtigsten Fragestellungen erarbeitet
und spezifiziert. Dazu gehört die Untersuchung bzgl. des Aufbaus sowie der Funktion von
Akkorden.
Zur Evaluation des entwickelten Analysesystems wurde eine prototypische Applikation entwickelt, die den Einsatz des Systems anhand einzelner ausgewählter Fragestellungen demonstriert.
Hierbei ist es insbesondere wichtig, eine möglichst intuitive Interaktion zwischen Benutzer und
Anwendung zu schaffen. Dafür wird u. a. auch die grafische Repräsentationsform der Partitur
zur Fragenspezifikation sowie zur Ergebnispräsentation genutzt.
Zunächst wird im Kapitel 2 eine Einführung in die musikalischen Grundlagen gegeben, die
die Basis für eine harmonische Analyse bilden. Anschließend werden die unterschiedlichen
Repräsentations- und Kodierungsformen von Musik, insbesondere MusicXML, vorgestellt
und erörtert und die wichtigsten Systeme für computergestützte harmonische Analyse von
Musikwerken präsentiert. Im Kapitel 3 werden die informatischen Grundlagen der eingesetzten
Techniken vorgestellt, die für das im Rahmen dieser Arbeit entstandene Analysesystem benötigt
werden. Zuerst wird auf relationale Datenbanken eingegangen und eine kurze SQL-Einführung
gegeben. Das Kapitel schließt den Grundlagenteil mit einer Zusammenfassung der eingesetzten
Java-Techniken.
Im Kapitel 4 wird die konzeptuelle Modellierung und das relationale Schema der für die harmonische Untersuchung benötigten Informationen musikalischer Werke vorgestellt. Nach einer
Beschreibung des Gesamtaufbaus des Systems wird auf einzelne Bausteine näher eingegangen.
Im Kapitel 5 werden zunächst die mit dem Analysesystem lösbaren Fragestellungen aufgeführt
und beschrieben. Desweiteren werden exemplarisch einzelne Fragestellungen ausgewählt und
detailliert besprochen. Nach der Vorstellung des eigentlichen Analysewerkzeugs wird im Kapitel 6 die entwickelte Applikation vorgestellt. Dabei werden zunächst die Gesamtstruktur des
Systems und das Zusammenspiel der eingesetzten Komponenten beschrieben. In folgenden
Abschnitten wird auf die einzelnen Komponenten näher eingegangen, insbesondere werden
ihre Einsatzmöglichkeiten präsentiert.
2 Relevante Grundlagen aus der
Musikwissenschaft
Die Analyse von Musik gehört zum zentralen Aufgabenbereich der Musikwissenschaft und
dient dem besseren Verständnis musikalischer Werke. Dabei werden sowohl formale Aspekte
und Techniken als auch inhaltliche Gesichtspunkte untersucht, um zusammen genommen die
Intention des Komponisten deutlich werden zu lassen. Die Musikanalyse stellt jedoch kein
mechanisches und immer gleichartiges Verfahren dar, sondern hängt stark von der Analyseabsicht ab. Grundsätzlich beinhaltet sie die Untersuchung bzgl. bestimmter Eigenschaften in
einem musikalischen Werk. Mögliche Fragestellungen bei der Durchführung einer musikalischen
Analyse können z. B. sein: Welche Akkorde treten am häufigsten auf? Wann und wie treten
Modulationen auf? Zu welchen Zeitpunkten gibt es Tempoänderungen, und haben sie etwas
miteinander gemeinsam? Gibt es sich wiederholende rhythmische Muster?
Aufgrund der Komplexität musikalischer Werke werden bei der Musikanalyse immer nur einzelne Aspekte besonders betrachtet und auf bestimmte Eigenschaften hin untersucht, während
andere zwischenzeitlich in den Hintergrund treten. Durch die isolierte Betrachtungsweise
können aber möglicherweise Informationen verloren gehen. Grundsätzlich kann der Fokus bei
der Analyse von Musikwerken auf harmonische, melodisch-thematische, formale, rhythmische,
dynamische oder weitere Aspekte gelegt werden. Für die Untersuchung der einzelnen Aspekte
ist zunächst das Herausfiltern der relevanten Musikparameter wichtig, was nur durch exakte
Kenntnis der Fragestellung möglich ist.
Die harmonische Analyse beschäftigt sich im Wesentlichen mit dem Bau und den Beziehungen
von Harmonien, dem Zusammenklang mehrerer Töne. Voraussetzung für diese Untersuchung
ist ein in schriftlicher Form (d. h. mit Noten) festgehaltenes Musikwerk. Aufgrund der Vielzahl
zu berücksichtigender Parameter ist die harmonische Analyse eines großen und möglicherweise
komplexen Musikwerkes eine sehr anspruchsvolle und zeitintensive Aufgabe, die allerdings
mittels Computereinsatz erleichtert und zum Teil sogar automatisiert werden kann. Damit
der Computer als Hilfsmittel für die Analyse eingesetzt werden kann, müssen die benötigten
Informationen aber zunächst in digitaler Form vorliegen. Diese Arbeit beschäftigt sich mit
13
14
Relevante Grundlagen aus der Musikwissenschaft
der Frage, in wieweit sich die bei der harmonischen Analyse auftretenden Fragestellungen mit
Hilfe relationaler Datenbanken (siehe Kapitel 3) modellieren und beantworten lassen.
Dieses Kapitel beginnt mit einer Einführung der wichtigsten musiktheoretischen Grundlagen,
die größtenteils auf [Michels 2005], [Ziegenrücker 1993], [Dachs-Söhner 2007] und [Binkowski
et al. 1996] basieren. Begonnen wird mit der schriftlichen Darstellung von Musik und den
Beziehungen der einzelnen Musikparameter, bevor schließlich auf die Harmonielehre mit den
Grundlagen der harmonischen Analyse eingegangen wird. Im zweiten Teil des Kapitels werden
Möglichkeiten der Repräsentation von Musik mit dem Computer vorgestellt und klassifiziert,
sowie die wichtigsten existierenden Programme für eine harmonische Analyse diskutiert.
2.1 Allgemeine Musiklehre
Innerhalb der Musikwissenschaft gibt es die Gebiete Allgemeine Musiklehre, Harmonielehre
mit Modulationslehre, Kontrapunkt, Formenlehre, Melodielehre, Instrumentationslehre und
die Lehre von Rhythmik und Metrik. Die Allgemeine Musiklehre kann dabei als Grundlage der
Musiktheorie angesehen werden, welche Wortschatz und Grammatik der Musik beschreibt. Sie
befasst sich mit dem musikalischen Schriftbild sowie mit den Lehren von Intervall, Tonleiter,
Tonart, Rhythmus, Melodie, Takt und Tempo. Teilweise wird die Akkordlehre auch dazu
gezählt. Überwiegend wird sie aber als Teilgebiet der Harmonielehre betrachtet, die sich mit
den Verbindungen von Harmonien bzw. Akkorden befasst [Finscher u. Blume 1994].
Für die Durchführung einer harmonischen Analyse wird die schriftliche Form eines musikalischen Werkes benötigt. Bevor im Folgenden die einzelnen Notationselemente beschrieben
werden, muss zunächst der Begriff des musikalischen Werkes eindeutig definiert werden. Er
bezeichnet einerseits ein einzelnes Musikstück, andererseits das Gesamtwerk eines Komponisten
(z. B. Bach-Werke). Die Einzelwerke sind in der Regel nach einer bestimmten Verzeichnisstruktur gruppiert und eindeutig nummeriert. Ein einzelnes Werk kann weiter in kleinere in sich
abgeschlossene Einheiten (Sätze) unterteilt sein. So findet man bspw. im Bachwerkeverzeichnis
unter der Nummer BWV 1049 das Brandenburgische Konzert Nr. 4“, das aus drei Sätzen
”
besteht. Diese unterscheiden sich sowohl thematisch als auch im Tempo. Daher wird in dieser
Arbeit für die harmonische Analyse die kleinste Einheit eines musikalischen Werkes (bspw. ein
Satz) als Arbeitselement betrachtet, das im relationalen Modell repräsentiert wird.
Ein Musikwerk kann in Form einer Partitur bzw. eines ausgeschriebenen Stückes vorliegen.
Während bei einer Partitur alle Stimmen voneinander getrennt und jeweils im eigenen Notensystem notiert sind, werden sie im ausgeschriebenen Stück zusammengefasst. Dabei wird
15
Allgemeine Musiklehre
4
4
4
4
4
4
44
1/1
1/1
1/2
1/4
1/2
1/4
1/8
1/16
1/8
1/16
Abbildung 2.1: Noten- und Pausensymbole unterschiedlicher Dauer
1/2+1/4
44 1/2
4
4 1/4
1/4+1/8
1/4
1/4
1/8
1/4+1/8
1/4
1/8
Abbildung 2.2: Verlängerung der Tondauer durch Punktierung und Haltebögen
häufig nur die Melodiestimme von den begleitenden Stimmen räumlich durch Darstellung
im eigenen System getrennt. Bei einer Analyse wird meistens die Partitur verwendet, da sie
aufgrund ihrer Übersichtlichkeit einfacher zu handhaben und somit zu untersuchen ist.
2.1.1 Musiknotation
Musiknotation ist die grafische Art der Musikdokumentation, die mittels einer eigens dafür
entwickelten Notenschrift alle musikalischen Parameter festhält, die ein Werk ausmachen. Im
Gegensatz zur Überlieferung durch Vorspielen oder Vorsingen hat die schriftliche Musiknotation
den Vorteil, dass eine praktische Umsetzung von Musikern mehrfach wiederholt werden
kann. Allerdings ist sie keine strikte Spielanweisung, so dass bei der Umsetzung gewisse
interpretatorische Freiheiten vorhanden sind. Grundsätzlich besteht sie aus Symbolen und wird
durch den Einsatz von Buchstaben und Zahlen erweitert. Das Hauptelement der Notenschrift
stellt das fünflinige Notensystem dar, in dem alle Informationen über ein Musikwerk beschrieben
werden. Dazu gehören die zu spielenden Töne, die in Form von Noten abgebildet werden, aber
auch weitere Angaben wie Takt, Tempo und Dynamik des jeweiligen Werkes.
16
Relevante Grundlagen aus der Musikwissenschaft
f
g'
c'
c'
Abbildung 2.3: Notenschlüssel mit dazugehörigem Referenzton. Schlüssel von links nach rechts:
Bass, Violin, Alt, Tenor.
Noten
Ein Ton in einem musikalischen Werk wird durch das Notensymbol in einer Partitur ausgedrückt und kodiert den Notenwert bzw. die Notendauer. Um weitere Eigenschaften zu
spezifizieren, werden zusätzliche Zeichen oder Symbole verwendet (z. B. Akzente für unterschiedliche Betonungen). Jede Note ist aus drei voneinander unabhängigen Teilen konstruiert:
dem Notenkopf, Notenhals und Fähnchen bzw. Balken bei Notengruppen. Durch Kombination
der einzelnen Teile lassen sich verschiedene Notensymbole erzeugen, die jeweils mit unterschiedlicher Wertigkeit bezüglich der Spieldauer belegt sind (siehe Abbildung 2.1). Die möglichen
Notenwerte erhalten wir durch Halbierung eines definierten Ausgangswertes, angefangen bei
der ganzen Note, die den Wert 1/1 hat. Mit der ersten Teilung wird die halbe Note realisiert,
die den Wert 1/2 erhält. Weitere Halbierungen ergeben dann eine Viertelnote (1/4), eine
Achtelnote (1/8) usw. Analog zu Noten werden Pausen verschiedener Länge dargestellt.
Befindet sich ein Punkt hinter einem Element (Note oder Pause), so nennt man dieses punktiert.
Rhythmisch bedeutet dies, dass der Wert um die Hälfte des eigenen Wertes verlängert wird.
Eine punktierte halbe Note entspricht somit der Wertigkeit 1/2 + 1/4. Die Verlängerung
einer Note kann auch durch den Einsatz eines Haltebogens (Ligatur) erfolgen. Damit lassen
sich beliebige Verlängerungen auch über eine Taktgrenze hinaus realisieren (siehe Abbildung
2.2). Grundsätzlich wird ein Musikwerk in Takte unterteilt, in denen jeweils mehrere Noten
zusammengefasst werden.
Um die Tonhöhe einer Note festzulegen, wird das Notensystem und ein Notenschlüssel benötigt.
Durch die vertikale Einordnung der Note im System wird die Tonhöhe relativ in Beziehung zu
einem Referenzton festgelegt. Dieser wird durch einen Notenschlüssel definiert, wodurch die
absolute Tonhöhe der Note bestimmt ist. Die am häufigsten verwendeten Schlüssel sind der
Violin- und Bassschlüssel (bzw. G- und F-Schlüssel). Der Violinschlüssel umschließt dabei die
zweite Linie von unten und definiert auf dieser g’ als Referenzton, während der Bassschlüssel
die zweite Linie von oben umschließt und f als Referenzton festlegt (s. u. für die Bezeichner).
Weitere bekannte Notenschlüssel sind der Alt- und Tenorschlüssel (siehe Abbildung 2.3).
17
Allgemeine Musiklehre
C D E F G A H c d e f
g a h
g'' a'' h''
c' d' e' f' g' a' h' c'' d'' e'' f''
Abbildung 2.4: Oktavräume zwischen der großen und der zweigestrichenen Oktave. Die einzelnen
Oktavbereiche sind durch Färbung gekennzeichnet.
Abbildung 2.5: Zuordnung der Stammtöne zu Klaviertasten. Die Töne e und f sowie h und
c liegen jeweils im Halbtonabstand zueinander. Weitere Halbtöne sind durch Alteration der
Stammtöne erreichbar (z. B. g#=gis, ab=as). Die Noten gis und as beschreiben dabei denselben
Ton und heißen damit enharmonisch verwechselbar.
Insgesamt werden sieben mit Buchstaben benannte Stammtöne (c, d, e, f, g, a, h) unterschieden
und zu einem Oktavbereich zusammengefasst. Durch mehrmaliges Hintereinanderschalten
dieser Reihe erhalten wir das gesamte Tonsystem. Das Spektrum der Oktavbereiche erstreckt
sich dabei von der Subsubkontraoktave (8,2 Hz) bis hin zur fünfgestrichenen Oktave (4186 Hz).
Prinzipiell können weitere Reihen angefügt werden, wobei die menschliche Hörgrenze aber
spätestens in der achtgestrichenen Oktave erreicht ist. Die Namen der Noten erhalten in den
verschiedenen Oktavbereichen unterschiedliche Bezeichnungen, wodurch die absolute Tonhöhe
der Note angegeben wird (siehe Abbildung 2.4).
Bei näherer Betrachtung eines einzelnen Oktavbereiches lassen sich Unterschiede in den
Abständen der aneinander liegenden Töne feststellen. Der kleinstmögliche Abstand ist dabei
der Halbtonschritt, der in der Stammtonreihe zwischen den Tönen e und f sowie h und
c liegt. In der Notenschrift ist dieser nicht erkennbar, sehr wohl aber auf einer Klaviatur
(siehe Abbildung 2.5). Zwei Töne liegen genau dann im Halbtonabstand zueinander, wenn
kein weiterer Ton dazwischen liegt. Damit besitzen alle übrigen nebeneinander liegenden
18
Relevante Grundlagen aus der Musikwissenschaft
g
ges
geses
g
gis
gisis
g
Abbildung 2.6: Mögliche Tonhöhenänderung (Akzidenzien) am Beispiel der Note g’
cis'
dis'
eis'
fis'
f'
g'
a'
b'
Abbildung 2.7: Festlegung und Änderung der Generalvorzeichnung
Stammtöne einen größeren Abstand (Ganztonschritt). Auf weitere Details bzgl. der Beziehung
zweier Töne wird in Abschnitt 2.1.2 eingegangen.
Um einen Ton um einen Halbton zu ändern, werden Versetzungszeichen (Akzidenzien) verwendet, die direkt vor einer Note bekannt gegeben werden. Die Gültigkeit solcher Änderungen
(Alterationen) ist nur auf einen Takt beschränkt und muss ggf. in folgenden Takten wiederholt
werden. Mittels des Kreuz-Vorzeichens (#) wird die Erhöhung eines Tons erreicht, während das
Vorzeichen Be (b) eine Erniedrigung bewirkt. Das Vorzeichen verändert die Tonhöhe um einen
Halbton, und an den Notennamen wird jeweils die Endung is bzw. es angehängt, abgesehen
von einigen Spezialfällen, bei denen die Notenbenennung abweicht (z. B. erniedrigtes h = b).
Änderungen um mehr als einen Halbton, sowie Auflösung der Änderung sind ebenfalls möglich
(siehe Abbildung 2.6).
Die Vorzeichnung bietet eine weitere Möglichkeit, Änderungen von Tonhöhen festzulegen.
Anders als bei der Anwendung von Akzidenzien werden die Vorzeichen am Anfang eines
Notensystems definiert und gelten für die gesamte Partitur oder bis zu einer Änderung. Eine
Änderung muss dabei immer durch Auflösung der alten Vorzeichnung eingeleitet werden
(siehe Abbildung 2.7). Weiterhin wird durch die Vorzeichnung die Grundtonart eines Werkes
festgelegt (siehe Abschnitt 2.1.3).
Töne, die gleich klingen aber anders benannt werden, heißen enharmonisch verwechselbar. In
der Stammtonreihe zählen z. B. alle schwarzen Tasten der Klaviatur dazu. So beschreiben cis
und des, dis und es usw. vom Klang her jeweils dieselben Töne, obwohl die Bezeichnung sich
unterscheidet (siehe Abbildung 2.5).
19
Allgemeine Musiklehre
42
(1)
=
(3)
(2)
4
4
=
_
3
4
=
6
4
=
(5)
(4)
_
5
8
=
_
Abbildung 2.8: Taktarten und ihre Betonung (Hauptbetonung: =, Nebenbetonung: -): (1) einfache
gerade Taktart (2) zusammengesetzte Taktart einer geraden Taktart (3) einfache ungerade Taktart
(4) zusammengesetzte Taktart einer ungeraden Taktart (5) kombinierte Taktart.
Takte
Mit Hilfe von Takten wird die rhythmisch-metrische Ordnung festgelegt, die Struktur und
Fluss eines Musikwerkes bestimmt. Ein Takt besteht aus betonten und unbetonten Zählzeiten,
die durch die Angabe der Taktart festgelegt werden. Die Anzahl und Art der Notenwerte einer
Taktart wird als Zähler und Nenner am Anfang einer Partitur festgelegt (z. B. 4/4, 3/4 usw.).
Ein 4/4-Takt besteht beispielsweise aus vier Viertelnoten und wird manchmal auch durch ein
großes C“ gekennzeichnet. Das Ende eines Taktes wird durch einen Taktstrich realisiert.
”
Grundsätzlich werden gerade (Zweier-Takte), ungerade (Dreier-Takte), zusammengesetzte
sowie kombinierte Taktarten unterschieden. Zu den einfachsten geraden bzw. ungeraden
Taktarten zählen alle Taktarten, die im Zähler eine 2 bzw. eine 3 enthalten (z. B. 2/4 oder
3/4). Durch die Zusammenfassung mehrerer einfacher gerader Taktarten entstehen zusammengesetzte Taktarten (z. B. 4/4 = 2/4 + 2/4). Analog dazu lassen sich auch ungerade
zusammengesetzte Taktarten bilden (z. B. 6/4). Bei einer kombinierten Taktart handelt es sich
um eine Taktart, welche aus geraden und ungeraden Taktarten zusammengesetzt wurde (z. B.
5/8). Die Hauptbetonung liegt dabei bei allen Taktarten immer auf der ersten Zählzeit. Weitere
Betonungen (Nebenbetonungen) sind von der jeweiligen Taktart abhängig (siehe Abbildung
2.8).
Dynamik
Die Dynamik bezeichnet in der Musik die Lautstärke, mit der ein Stück zu spielen ist. Sie wird in
der Regel am Anfang einer Partitur für das Gesamtwerk festgelegt, wobei Änderungen möglich
sind. Es werden meist Abkürzungen der aus dem italienischen kommenden Lautstärkebegriffe
verwendet. Der Grad der Lautstärke reicht von pianissimo piano (ppp, so leise wie möglich),
bis fortissimo possible (fff, so stark wie möglich). Weiterhin sind kontinuierliche Übergänge der
Lautstärke über Bereiche von Notengruppen möglich, die abhängig von der Generaltonstärke
ein stetiges Leise- bzw. Lautwerden anordnen. Dies wird mit Hilfe der Begriffe crescendo
20
Relevante Grundlagen aus der Musikwissenschaft
Andante
3 4
f
p
Abbildung 2.9: Notationen für Dynamik (unten) und Tempo (oben). Andante bezeichnet ein
langsames Tempo (ca. 80 Viertelnoten pro Min.). f (forte: stark) und p (piano: leise) sind die
Angaben für die Tonstärke. Der Lautstärkeübergang im vierten Takt ist mit Decrescendo-Gabel
(stetiges Leisewerden) gekennzeichnet und leitet das piano“ im Takt fünf ein. Die Punkte über
”
den Noten indizieren eine Staccato-Spielweise (d. h. kurzes, abgehacktes Anspielen).
(cresc.) bzw. decrescendo (decresc.) realisiert. Anstelle dieser Bezeichnungen können auch
sogenannte Gabeln verwendet werden (siehe Abbildung 2.9). Schließlich können einzelne Noten
durch Setzen von Akzenten besonders hervorgehoben werden (z. B. fp: laut, dann plötzlich
leise).
Tempo
Die Notenwerte geben nur die relative Tondauer in Bezug auf andere Noten an, d. h. dass
z. B. eine halbe Note doppelt so lang erklingt wie eine Viertelnote. Erst durch Angabe des
Tempos zu Beginn des Werkes wird die tatsächliche Dauer konkretisiert (siehe Abbildung 2.9).
Man unterscheidet Tempi von largo (breit) bis hin zu presto (schnell). Largo bedeutet, dass
ca. 40 – 60 Schläge pro Minute erfolgen, während bei Presto ca. 168 – 208 Schläge gefordert
werden. 100 Schläge pro Minute entsprechen dabei dem Erklingen von 100 Viertelnoten in
der Minute. Eventuelle Tempoänderungen können ebenfalls mittels bestimmter Tempobegriffe
festgelegt werden (z. B. accelerando, accel. , beschleunigend). Zusätzlich zur Tempoangabe
spielt bei der Tondauer die Interpretation des Musikers eine Rolle. Je nachdem wie dieser
das Tempo interpretiert, kann die einzelne Notendauer im Vergleich zu anderen Interpreten
variieren.
2.1.2 Intervalle
Der Abstand zweier Töne zueinander wird als Intervall bezeichnet und mit lateinischen Namen
für Ordnungszahlen (Prim, Sekund, Terz, Quart, Quint, Sext, Septim, Oktav usw.) benannt.
Dabei werden zwei unterschiedliche Abstandsdefinitionen für die eindeutige Identifizierung
des Intervalls benötigt. Zunächst wird der Abstand zwischen den Stammtönen bestimmt, der
21
Allgemeine Musiklehre
Intervall
vermindert
klein
rein
groß
übermäßig
1 Prime
-
-
0
-
1
2 Sekunde
-
1
-
2
3
3 Terz
2
3
-
4
5
4 Quarte
4
-
5
-
6
5 Quinte
6
-
7
-
8
6 Sexte
7
8
-
9
10
7 Septime
9
10
-
11
12
8 Oktave
..
.
11
..
.
..
.
12
..
.
..
.
13
..
.
Abbildung 2.10: Intervalle innerhalb einer Oktave. Die Intervall-Spalte enthält die diatonischen
Abstände (Ganztonschritte). Alle übrigen Spalten enthalten chromatische Abstände (Halbtonschritte).
diatonische Abstand. Dazu werden alle Stammtöne beginnend beim ersten und endend beim
letzten Stammton des zu bestimmenden Abstands gezählt. Zwischen den Tönen c und e ist
der diatonischer Abstand drei (Terz), da nur ein weiterer Stammton dazwischen liegt. Anhand
einer zusätzlichen Abstandsdefinition wird der diatonische Abstand näher charakterisiert (rein,
klein, groß, übermäßig, vermindert). Bei letzterer Abstandsdefinition handelt es sich um den
sog. chromatischen Abstand, der die Anzahl der Halbtonschritte zwischen den Stammtönen
angibt. Wird wieder das Beispiel c – e betrachtet, so ergibt sich ein Halbtonabstand von vier
(große Terz). Wird c um einen Halbton erhöht, bleibt der diatonische Abstand gleich, während
der chromatische Abstand um eine Einheit kleiner wird (kleine Terz).
Die Benennung bei der Feinbestimmung durch den chromatischen Abstand lässt sich durch
Bilden der sog. Ober- bzw. Unterintervalle begründen. Beim Oberintervall handelt es sich um
einen Abstand, der von unten nach oben bestimmt wird (umgekehrt beim Unterintervall).
Werden alle Ober- und Unterintervalle ausgehend von der Note c gebildet, so stellt man
fest, dass die Abstände (diatonisch und chromatisch) bei Prime, Quarte, Quinte und Oktave
in beide Richtungen exakt gleich sind. Damit sind diese Intervalle in ihrer Grundform rein.
Bei den restlichen Intervallen (Sekunde, Terz, Sexte, Septime) treten dagegen Unterschiede
auf, wodurch sich zwei Grundformen ergeben, welche als klein bzw. groß bezeichnet werden.
Die weiteren zwei Kennzeichnungen übermäßig und vermindert lassen sich jeweils durch
Erhöhung bzw. Erniedrigung der Grundformen erreichen. Eine Übersicht über die mögliche
Intervallbildung innerhalb einer Oktave ist in Abbildung 2.10 dargestellt.
22
Relevante Grundlagen aus der Musikwissenschaft
Zu jedem Intervall existiert ein Komplementärintervall, welches das Intervall zu einer Oktave
ergänzt. Der Abstand von c nach f beträgt eine reine Quarte. Um das zugehörige Komplementärintervall zu erhalten, wird die Note c bzw. f um eine Oktave nach oben bzw. nach unten
versetzt. Das neu entstandene Intervall ist dabei eine reine Quinte. Bei reinen Intervallgrundformen sind ihre Umkehrungen ebenfalls rein, während sie bei der anderen Gruppe jeweils
vertauscht sind. Das Komplementärintervall zur großen Terz ist damit eine kleine Sexte.
Der kleinste definierte Abstand ist der Halbton, der sich z. B. in der Stammtonreihe zwischen
den Tönen e – f und h – c befindet. Bei der Intervallbestimmung wird er hier eindeutig
als kleine Sekunde identifiziert, da sowohl beim diatonischen als auch beim chromatischen
Abstand die Differenz eins beträgt (siehe Abbildung 2.10). Natürlich gibt es auch Intervalle,
die über eine Oktave hinausgehen (None, Dezime, Undezime usw.). Das Verhalten bei der
Feinbestimmung wird dabei auf das Verhalten der Intervalle innerhalb einer Oktave abgebildet.
Bei der Betrachtung des Nonen-Intervalls lässt sich feststellen, dass dieser aus einem Oktavund Sekund-Intervall konstruiert werden kann. Damit ist das Verhalten einer None bei der
Feinbestimmung dem einer Sekunde gleichzusetzen.
2.1.3 Tonleitern und Tonarten
Jeder Musik liegt eine bestimmte Tonleiter oder Skala zugrunde, wobei nahezu alle bekannten
Tonleitern innerhalb einer Oktave gebildet werden. Verschiedene Unterteilungen der Oktave
ermöglichen dabei viele unterschiedliche Skalenkombinationen. Die am häufigsten eingesetzten
Oktavunterteilungen machen die fünf- bzw. siebentönigen Tonleitern aus. Die pentatonische
Tonleiter ist dabei die bekannteste fünftönige Skala, welche meist in den afrikanischen und
asiatischen Musikkulturen verwendet wird. Den in dieser Arbeit betrachteten Werken liegt allerdings die heptatonische (siebentönige) Tonleiter mit einer diatonischen Tonabfolge zugrunde.
Das bedeutet, dass die Töne in einem bestimmten Wechsel von Ganz- bzw. Halbtonabständen
zueinander stehen. Der Wechsel erfolgt jeweils nach zwei oder drei Ganztönen (siehe Abbildung
2.11). Die sieben Haupttöne entsprechen dabei der oben vorgestellten Stammtonreihe.
Zu der Gruppe der siebentönigen diatonischen Tonleitern zählen u. a. Dur- und Moll-Tonleitern,
welche ca. Mitte des 16. Jahrhunderts aus den Kirchentonarten (Modi ) entstanden sind.
Grundsätzlich bauen beide Tonleitern auf einem Grundton auf. Ihre diatonischen Tonabfolgen
sind jedoch unterschiedlich und bestimmen jeweils das Geschlecht der Tonleiter (Dur oder Moll).
Die Dur-Tonleiter wird durch die Stufenfolge (1 – 1 – 1/2 – 1 – 1 – 1 – 1/2) charakterisiert,
während die Moll-Leiter um zwei Stufen nach rechts verschoben ist. Die übrigen Stufen werden
vorne wieder angefügt (1 – 1/2 – 1 – 1 – 1/2 – 1 – 1). Dabei entspricht die 1 einem Ganztonschritt
Allgemeine Musiklehre
23
Abbildung 2.11: Dur- und Moll-Tonleiter mit den jeweiligen Stufenfolgen (Ganztonschritt: Bogen,
Halbtonschritt: spitze Klammer)
und 1/2 einem Halbtonschritt. Um ein solches Stufenschema zu erreichen, werden zunächst
alle Oktavtöne ausgehend von einem Grundton der Höhe nach geordnet. Im weiteren Schritt
werden einzelne Töne angepasst (erhöht bzw. erniedrigt), um die geforderte Stufenfolge zu
realisieren. Entsprechend der verschiedenen Oktavtöne werden jeweils 12 Dur- und Moll-Leitern
unterschieden. Die einfachste Form bilden dabei die vorzeichenlosen Tonleitern C-Dur und
a-Moll, die auf der Klaviatur jeweils nur aus den weißen Tasten bestehen. Die Klein- und
Großschreibung in den Bezeichnungen der Grundtöne weist jeweils auf das Geschlecht hin: das
Dur-Geschlecht wird immer mit Großbuchstaben und das Moll-Geschlecht mit Kleinbuchstaben
gekennzeichnet.
Bei einer genaueren Betrachtung der Dur-Leiter lässt sich feststellen, dass sie aus zwei parallelen
Viertongruppen, den sog. Tetrachorden besteht. Am Beispiel der C-Dur-Leiter lässt sich dies
besonders gut erkennen: Der Wechsel von Halb- und Ganztonschritten ist bei der Tonfolge (c,
d, e, f) sowie (g, a, h, c) gleich. Der dritte und siebte Ton (e bzw. h) werden Leittöne genannt,
da sie eine spannungsaufbauende Wirkung haben und zur Auflösung in bestimmte Zieltöne
drängen (hier f und c). Die Verbindung der zwei Tetrachorde wird durch einen Ganztonschritt
erzielt.
Bei Moll-Tonleitern werden noch zwei weitere abgewandelte Formen unterschieden. Neben der
bisher betrachteten reinen Moll-Tonleiter gibt es noch die harmonische und die melodische
Form (siehe Abbildung 2.12). Durch Erhöhung der siebten Stufe der reinen Moll-Toneiter
24
Relevante Grundlagen aus der Musikwissenschaft
C-Dur
a-Moll (rein)
a-Moll (melodisch)
a-Moll (harmonisch)
Abbildung 2.12: Übersicht über den Aufbau von Dur- und allen Formen der Moll-Leiter am
Beispiel von C-Dur und a-Moll. Halbtonschritte sind durch Klammern gekennzeichnet. Mit Ausnahme vom sechsten zum siebten Ton in harmonischer Moll-Leiter (übermäßige Sekunde) weisen
alle übrigen Abstände einen Ganztonschritt auf. Die farblich hervorgehobenen Viertongruppen
sind die Tetrachorde. Bei Dur- und harmonischer Moll-Leiter ist der zweite Tetrachord identisch.
entsteht die harmonische Moll-Tonleiter, die wie eine Dur-Tonleiter einen Halbtonschritt zum
achten Ton (Leitton) beinhaltet. Vom sechsten zum siebten Ton ergibt sich dadurch eine
übermäßige Sekunde. Die melodische Moll-Tonleiter gleicht durch eine weitere Erhöhung
der sechsten Stufe die übermäßige Sekunde der harmonischen Moll-Leiter aus, wodurch das
Stufenschema des zweiten Tetrachords identisch mit dem der Dur-Tonleiter ist.
Eine Tonart legt die Vorzeichnung, den Grundton der Leiter und die damit verbundene
harmonische Verwandtschaft fest. Der Grundton wird durch den ersten Ton einer Tonleiter
bestimmt. Die Tonarten C-Dur bzw. a-Moll sind dabei die einfachsten Tonarten, die keinerlei
Vorzeichnung besitzen. Da beide Tonarten sich derselben Gebrauchstonleiter bedienen, d. h.
dieselben Töne enthalten, wird a-Moll auch als Paralleltonart zu C-Dur bezeichnet. Daher wird
durch die Vorzeichnung alleine keine eindeutige Aussage über die Tonart getroffen, sondern
lediglich eine Eingrenzung auf zwei mögliche Tonarten erreicht. Eine exakte Angabe lässt sich
nur aus dem Gesamtkontext des Musikstückes bestimmen (z. B. mit Hilfe der sog. Kadenz,
siehe Abschnitt 2.2.4).
Alle vorkommenden Tonarten und ihre Verwandschaftsbeziehungen lassen sich im sog. Quintenzirkel visualisieren. Die Grundtöne der Tonarten mit demselben Geschlecht sind jeweils im
Abstand einer Quinte angeordnet (Quintverwandschaft), wohingegen Dur-Tonarten und ihre
parallelen Moll-Tonarten terzverwandt sind (siehe Abbildung 2.13).
Allgemeine Musiklehre
25
Abbildung 2.13: Der Quintenzirkel. Gleichgeschlechtliche Tonarten sind quintverwandt, während
zwischen Dur und Moll eine Terzverwandschaft besteht. [Wikipedia 2008]
2.1.4 Akkorde
Ein Zusammenklang von mehr als zwei Tönen unterschiedlicher Tonhöhe wird als Akkord bzw.
Harmonie bezeichnet. Akkorde werden nach bestimmten Gesetzmäßigkeiten aufgebaut. Bei
der sog. Terzschichtung werden die Töne jeweils im Abstand von Terzintervallen übereinander
gelegt. Beginnend mit einem Grundton können beliebig viele Töne übereinander geschichtet
werden, wobei jeweils ein Abstand von großer bzw. kleiner Terz zum nächsttieferen Ton vorliegt.
Andere Akkordtypen sind beispielsweise Quartenakkorde oder Cluster (freie Schichtung). Bei
der traditionellen Harmonielehre wird die Terzschichtung als Grundlage für den Akkordaufbau verwendet. Im Rahmen dieser Arbeit wird deshalb von der Untersuchung anderer
Gesetzmäßigkeiten abgesehen.
Die wichtigste Akkordgruppe bilden die aus drei verschiedenen Tönen bestehenden Dreiklänge.
Hierbei muss beachtet werden, dass Töne im Abstand einer Oktave als gleich betrachtet werden.
So kann ein Dreiklang auch aus mehr als drei Tönen bestehen. Der Grundton eines Dreiklangs
liegt auf der untersten bzw. tiefsten Position (Bass) und bestimmt den Namen des Akkordes.
Ihm folgen Terzton und schließlich der Quintton. Ein derart geschichteter Dreiklang befindet
sich in der sog. Grundstellung und hat als Rahmenintervall eine Quinte (Abstand zwischen
Grund- und Quintton). Allerdings können auch Terzton oder Quintton an tiefster Position
26
Relevante Grundlagen aus der Musikwissenschaft
a)
b)
1
c)
3
2
1
2
3
Abbildung 2.14: a) Aufbau: Grundton (rot), Terzton (grün), Quintton (blau), Terzschichtung
(kleine Klammern), Rahmenintervall (große Klammer) b) Stellung: Grundstellung (1), erste
Umkehrung (2), zweite Umkehrung (3) c) Diskantlage: Quintlage (1), Oktavlage (2), Terzlage (3).
Dur
Moll
vermindert
uebermaessig
Abbildung 2.15: Dreiklangstypen
liegen. Die entsprechenden Stellungen bilden die erste Umkehrung (Sextakkord) bzw. zweite
Umkehrung (Quartsextakkord). Analog zur Lagebestimmung bzgl. des tiefsten Tons wird
die sog. Diskantlage bzgl. des höchsten Tons (Sopran) bestimmt. Abhängig vom Sopranton
unterscheidet man die Oktav-, Quint- und die Terzlage. Bei der Oktavlage liegt der Grundton
im Sopran (siehe Abbildung 2.14).
Die möglichen Schichtungskombinationen des kleinen und großen Terzintervalls ergeben insgesamt vier verschiedene Dreiklangstypen (Dur, Moll, vermindert und übermäßig). Beim
Dur-Dreiklang liegt zwischen dem Grund- und Terzton eine große Terz und zwischen dem
Terz- und Quintton eine kleine Terz, während die Reihenfolge beim Moll-Dreiklang vertauscht
ist. Der verminderte oder übermäßige Dreiklang wird dagegen aus zwei kleinen bzw. großen
Terzen gebildet. In Abbildung 2.15 werden die vier verschiedenen Dreiklangstypen aufgeführt.
Die Bezeichnungen Dur und Moll beschreiben analog zu den Tonleitern von Tonarten das
Geschlecht von Akkorden.
Vierklänge, Fünfklänge und weitere Akkordgruppen werden allgemein als Mehrklänge bezeichnet. Durch Schichtung von vier Tönen entstehen Septakkorde (Vierklänge). Der bekannteste
davon ist der Dominatseptakkord, der auf dem fünften Ton bzw. der fünften Stufe einer
Tonleiter aufgebaut wird und stark zur Auflösung in die sog. Tonika (siehe Abschnitt 2.2.3)
strebt. Werden fünf Töne übereinander geschichtet, erhalten wir Fünfklänge, die auch Septnonenakkorde genannt werden.
Grundlagen der harmonischen Analyse
27
2.2 Grundlagen der harmonischen Analyse
In der Harmonielehre wird der Bau, das Wesen und die Verbindung bzw. das Verhältnis
zwischen den Harmonien studiert [Dachs-Söhner 2007]. Dabei wird einerseits die vertikale
Dimension, d. h. die Struktur des einzelnen Zusammenklangs betrachtet (also die Akkorde).
Andererseits wird die horizontale (zeitliche) Dimension untersucht, die sich mit den Gesetzen
der Verbindungen von Harmonien und ihrer Funktion befasst.
Die Grundlage für die Untersuchung von harmonischen Zusammenhängen bilden Dreiklänge,
die das Grundgerüst der westlichen, mehrstimmig tonalen Musik sind. Der vierstimmige Satz
ist dabei der Standard bei der Harmoniebildung und wird deshalb im Folgenden als Grundlage
für die harmonische Betrachtung angenommen. Er beinhaltet (von tief nach hoch) die vier
Stimmen Bass, Tenor, Alt und Sopran, wobei die Sopranstimme in der Regel die Melodiebildung
übernimmt. Die restlichen Stimmen werden bzgl. der Melodiestimme zu Akkorden geformt
und haben begleitenden Charakter. In diesem Zusammenhang wird die Überführung in die
Mehrstimmigkeit als Harmonisieren bezeichnet. Die Verwendung von Dreiklängen in einem
vierstimmigen Satz hat dabei zur Folge, dass ein Dreiklangston unter Einhaltung gewisser
Regeln verdoppelt werden muss. Diese und insbesondere die Regeln zur Verbindung einzelner
Akkorde beim Ausharmonisieren sind Thema der Lehre vom Kontrapunkt.
Im Folgenden stehen die Beziehungen zwischen den Harmonien im Vordergrund. Der kontrapunktische Aspekt wird z.T. außer Acht gelassen. Grundsätzlich sind zusammen mit dem
Generalbass drei unterschiedliche Theorien der Harmonielehre bekannt, die im nächsten Abschnitt vorgestellt werden. Im weiteren Verlauf wird auf die wichtigste funktionale Verbindung,
die sog. Kadenz, eingegangen. Mit der Betrachtung von Modulationen (Tonartwechseln) wird
der musikalische Grundlagenteil abgeschlossen.
2.2.1 Generalbass
Die Generalbass-Notation (Basso continuo) ist mit dem Einzug mehrstimmiger Werke, insbesondere dem vierstimmigen Satz, entstanden, um die im Werk vorkommenden Harmonien
festzuhalten. Die Voraussetzung und der Grund für diese Notationsform war, dass sich der
Dreiklang zur Grundlage des harmonischen Geschehens entwickelte. Beim Generalbass wird
lediglich die Bassstimme notiert und geeignet beziffert, um das Gesamtkonstrukt des Akkordes
zu beschreiben. Die Ziffern geben dabei das Intervall gemessen vom notierten Basston (dem
untersten Ton) an. Bleibt die Bezifferung aus, so ist ein vollständiger leitereigener Dreiklang
28
Relevante Grundlagen aus der Musikwissenschaft
I
II
III
IV
V
VI
VII
I
C-Dur
d-Moll
E-Dur
D-Dur
G-Dur
a-Moll
h-verm.
C-Dur
Abbildung 2.16: Leitereigene Dreiklänge am Beispiel der C-Dur-Tonleiter
43
3
4
(1)
C-Dur
(2)
e-Moll
G-Dur
C-Dur
6
6
4
Abbildung 2.17: (1) Unbezifferter Bass: Im Bass (unten) sind jeweils die Grundtöne der Dreiklänge enthalten, wodurch unterschiedliche Akkorde entstehen (oben und unten). (2) Bezifferter
Bass: Alle drei Akkorde bescheiben jeweils den selben Dreiklang (C-Dur). Die Bezifferung weist
auf unterschiedliche Stellungen der Akkorde hin (Sext- bzw. Quartsextakkord).
anzunehmen. Dies sind Dreiklänge, die aus den Tönen einer Tonleiter gebildet werden können
(siehe Abbildung 2.16).
Die Bezifferung gibt allerdings nur Anhaltspunkte über den zu spielenden Akkord und
ermöglicht dem Interpreten eigene gestalterische Freiheiten, die durch die Stimmführungsregeln
eingeschränkt sind. So wird beim unbezifferten Basston ein vollständiger Dreiklang in Grundstellung angenommen. Die Lage des Akkordes lässt sich allerdings nicht ablesen und muss
satztechnisch sinnvoll ergänzt werden. Zu Beginn der Mehrstimmigkeit wurden meist leitereigene, unkomplizierte Zusammenklänge verwendet, die durch die Bezifferung gut erfasst werden
konnten (siehe Abbildung 2.17). In späteren Epochen wurden immer größere harmonische
Zusammenhänge erschlossen, wodurch auch ein detaillierteres Verständnis der Harmonielehre
erforderlich wurde.
2.2.2 Stufentheorie
Die später entstandene Stufentheorie systematisierte den Akkordaufbau, indem sie ihn auf seine
Grundstruktur zurückführte. Dabei wurde stets von terzgeschichteten Akkorden ausgegangen.
Über jedem Ton der Tonleiter des durmolltonalen Systems wird jeweils ein Dreiklang gebildet
Grundlagen der harmonischen Analyse
29
und den Akkordgrundtönen eine Stufe zugewiesen. Der niedrigste Tonleiterton entspricht der
Stufe I, der nächsthöhere der Stufe II usw. Durch zusätzliche Verwendung der Generalbassnotation wird die volle Information über die betrachtete Harmonie spezifiziert. Die Stufe bezeichnet
dabei den Akkordgrundton, der sich durchaus vom Basston unterscheiden kann, während
die zusätzliche Bezifferung Auskunft über die Struktur der Harmonie gibt (z. B. Umkehrung,
Diskantlage). Dadurch werden der Terzaufbau und der innere Zusammenhang der Akkorde
mit ihren Umkehrungen deutlich. Um die Stufe eines Zusammenklangs zu bestimmen, ist
eine vorangehende Erkennung der Tonart und des Akkordgrundtons nötig (siehe Abbildung
2.18).
2.2.3 Funktionstheorie
Die Funktionstheorie als Erweiterung der Stufentheorie beschreibt zusätzlich die Beziehungen
der Akkorde untereinander. Einzelne Akkorde erhalten dabei abhängig von den sie umgebenden
Harmonien eine bestimmte Funktion zugewiesen. Jede Stufe der Tonleiter erfüllt eine bestimmte
Funktion: Tonika (T) ist die Hauptfunktion einer Tonart und bildet das harmonische Zentrum.
In der Stufentheorie liegt sie auf der ersten Stufe. Zu weiteren Hauptfunktionen zählen die
Subdominante (S) und Dominante (D), die in einer Quintverwandschaft zur Tonika stehen.
Im Abstand einer Oberquinte (Quinte nach oben, siehe Abschnitt 2.1.2) liegt die Stufe,
auf der der dominantische Akkord liegt. Auf der Stufe im Unterquinteabstand wird die
Subdominante gebildet. Diese Funktionen werden der Stufe IV bzw. V zugeordnet und haben
eine spannungsaufbauende Wirkung. Insbesondere drängt die Dominante zur Auflösung in die
Tonika, dem Ruhepol der Tonart (entspannende Wirkung). Allen übrigen Akkorden der Leiter
werden sog. Nebenfunktionen zugeordnet (z. B. Tonikaparallele, Tonikagegenklang). Prinzipiell
werden Parallel- und Gegenklänge unterschieden, die in Kleinterzabstand bzw. Großterzabstand
zu den Hauptfunktionen stehen. Die Dominantparallele (Dp) einer C-Dur-Tonleiter wird bspw.
durch e-Moll beschrieben und liegt auf der dritten Stufe in der Leiter. Der Bezeichner Dp
bedeutet dabei, dass es sich um die Dominantparallele einer Dur-Tonart (großes D) handelt,
wobei das Tongeschlecht des Dreiklangs Moll ist (kleines p) (siehe Abbildung 2.18).
2.2.4 Kadenz
Unter Berücksichtigung der Stimmführungsregeln lässt sich grundsätzlich jeder Akkord mit
jedem anderen (zeitlich) verbinden. Die Wirkung der Verbindungen hängt dabei von ihren
funktionalen Verwandschaftsbeziehungen ab. Bei der Kadenz, der wichtigsten Verbindung
von mehr als zwei Akkorden, werden nur leitereigene Akkorde verwendet. Sie beginnt und
30
Relevante Grundlagen aus der Musikwissenschaft
C-Dur
I
II
Sp
T
a-Moll (rein)
-
t
III
IV
V
VI
VII
VIII
Dp
S
D
Tp
-
T
tP
s
d
sP
dP
t
Abbildung 2.18: Zuordnung der Stufen und Funktionen einer C-Dur und a-Moll Tonleiter. Die
Hauptfunktionen bilden die Stufen I, IV und V. Alle übrigen Dreiklänge werden als Nebenfuktionen
der Hauptstufen bezeichnet.
1
V I
D T
IV I
S T
2
I V
T D
3
IV V
S D
4
V VI V VI
D Tp D tG
I
T
IV V I
S D T
I
t
IV V I
s D t
Abbildung 2.19: Schlüsse und Kadenzen. (1) Ganzschlüsse: authentisch, plagal (2) Halbschlüsse
(3) Trugschlüsse (4) Kadenzen: C-Dur, a-Moll.
endet jeweils mit dem harmonischen Zentrum einer Tonart, der Tonika (Ruheklang), die am
Ende einen schlussbildenden Charakter besitzt. Die dazwischen liegenden Harmonien sind der
Ruhelage entgegen gesetzte Zusammenklänge mit spannungsaufbauender Wirkung.
Die Kadenz kann grundsätzlich in einer einfachen oder erweiterten Form auftreten. Eine
Einfache Kadenz besteht nur aus den Hauptfunktionen und wird durch die Akkordfolge
T – S – D – T (bzw. I – IV – V – I) beschrieben. Zudem umfasst sie sämtliche Töne der
Tonleiter, womit die Tonart eindeutig bestimmt ist. Die Struktur der einzelnen Harmonien
bestimmt dabei das Geschlecht der Tonart (Dur oder Moll). Wird die Kadenz aus den
Hauptdreiklängen C-Dur, F-Dur und G-Dur aufgebaut, so handelt es sich um die Tonart
C-Dur, während die Akkorde a-Moll, d-Moll und e-Moll auf die Paralleltonart a-Moll schließen
lassen (siehe Abbildung 2.19).
Da der Tonikadreiklang innerhalb einer Tonart eine Schlusswirkung besitzt, muss dieser immer
am Schluss auf einer betonten Zählzeit stehen. Um eine vollkommene Schlusswirkung zu erzielen
31
Grundlagen der harmonischen Analyse
T
D
T
Sp
=t
t
s
D
t
Abbildung 2.20: Beispiel einer diatonischen Modulation. Übergang von C-Dur (rot) nach d-Moll
(blau). Der violette Akkord (d-Moll) wird funktional umgedeutet. Er ist sowohl in C-Dur als auch
in a-Moll enthalten.
wird zusätzlich die Oktavlage gefordert. Die Akkordverbindung D – T wird als authentischer
Schluss bezeichnet, während S – T einen plagalen Schluss darstellt. Eine weitere Schlussart
bildet der sog. Halbschluss, wobei seine Schlusskraft nicht mit der einer Tonika zu vergleichen ist.
Diese Schlussbildung wird beispielsweise mit der Verbindung I – V realisiert. Der Schlussakkord
liegt dabei immer auf der Dominante, die für weitere Erhaltung der Spannung sorgt. Ein
anderer Schluss basiert auf der erweiterten Kadenz, die neben den mit Hauptfunktionen
belegten Dreiklängen noch weitere leitereigene Dreiklänge zulässt (z. B. V – VI). Bei diesem
sog. Trugschluss erklingt nach dem Dominantakkord nicht wie erwartet die Tonika, sondern der
auf der sechsten Stufe liegende Dreiklang (z. B. Tp, tG). Statt der erhofften Schlusswirkung
bleibt dadurch die Spannung weiterhin erhalten.
2.2.5 Modulation
Komplexe musikalische Werke verbleiben nur selten über die gesamte Dauer in der zu Beginn
definierten Tonart. Durch Modulation, das Ausweichen in andere oft benachbarte Tonarten, wird
ein farbigerer und interessanterer Verlauf erreicht. Dieser Wechsel in ein neues harmonisches
Zentrum kann nur wenige Takte betreffen oder aber über eine längere Zeitdauer durchgehalten
werden. Die Überführung in die Zieltonart geschieht in der Regel nicht abrupt, sondern erfordert
eine gewisse Vorbereitung (z. B. Benutzung leiterfremder Töne). Insgesamt existieren viele
verschiedene Modulationsarten, die fast immer eine funktionale Umdeutung eines bestimmten
Akkordes mit sich bringen (z. B. Subdominante wird zur neuen Tonika). Die einzelnen Arten
bieten weiterhin viele unterschiedliche Wege der Durchführung der Modulation, um in eine
bestimmte Zieltonart zu gelangen.
Zu den wichtigsten Modulationsarten zählen die diatonische, die chromatische und die enharmonische Modulation. Bei der diatonischen Modulation wird die Funktion des Akkordes der
32
Relevante Grundlagen aus der Musikwissenschaft
Ausgangstonart in eine andere Funktion der Zieltonart umgedeutet (siehe Abbildung 2.20).
Schrittweises Alterieren der Stammtöne bis zur Erreichung der Zieltonart wird dagegen als
chromatische Modulation bezeichnet. Dabei werden die Töne eines Akkordes derart verändert,
dass der Klang schließlich eine andere Funktion erhält. Bei der letzten Modulationsart werden
die Akkordtöne enharmonisch alteriert, wodurch eine neue Funktion der Harmonie entsteht.
Für diese Art der Modulation kommen insbesondere dominantische Klänge in Frage.
Durch Verwendung von Modulationen wird bei musikalischen Werken zwar ein interessanterer
Verlauf erzielt, die Komplexität bei der harmonichen Analyse steigt aber dadurch deutlich an.
Voraussetzung für die Funktionsbestimmung der einzelnen Harmonien ist die Kenntnis der
aktuellen Tonart, die sich von der Grundtonart eben duch Modulation unterscheiden kann.
Eine eindeutige Identifizierung der Tonart lässt sich nur durch Betrachtung im Gesamtkontext
des Werkes vornehmen. Schon für die Bestimmung der Grundtonart ist dies notwendig. Bei
Auftreten von Modulationen ist die Tonartbestimmung aber eine weitaus schwierigere Aufgabe,
da überhaupt erst einmal ein Tonartwechsel im Werk erkannt werden muss. Die Bestimmung
der Tonart erfolgt dann in einem zweiten Schritt, indem aufgrund unterschiedlicher Indizien
(z. B. Kadenz) auf die Tonart geschlossen wird.
2.3 Digitale Musikrepräsentation
Musik lässt sich auf verschiedene Arten mit Hilfe des Computers repräsentieren. Grundsätzlich
unterscheidet man zwischen symbolischen, grafischen und akkustischen Darstellungsformen.
Diese enthalten unterschiedlich viele semantische Informationen über die Musik. Bei der
symbolischen Repräsentation werden Noten und ihre Attribute direkt repräsentiert, wohingegen
grafische und akkustische Repräsentationsformen diese Information nicht direkt enthalten
[Fremerey 2006].
Grafische Darstellungen beinhalten die Musikinformationen in Form von Bildern (z. B. von
Partituren). Diese können in verschiedenen Formaten vorliegen, z. B. als pixelbasierte Bitmapgrafik, die nur Farb- oder Graustufeninformationen enthält (z. B. BMP, JPG, TIFF oder
PNG). Auf der anderen Seite gibt es die vektorbasierten Formate, die frei skalierbare und u. U.
editierbare Informationen über grafische Elemente wie Linien, Kreise usw. enthalten (z. B.
SVG). Beiden Formen ist gemeinsam, dass sie in der Regel keine semantischen Informationen
über die Noten und Notenattribute in den Dokumenten enthalten. Diese müssten ggf. durch
einen fehleranfälligen Bild- bzw. Mustererkennungsschritt extrahiert werden.
Digitale Musikrepräsentation
33
Ähnliches gilt für akkustische Repräsentationsformen von Musik, wobei hier die Rekonstruktion
der Noteninformation ungleich schwieriger ist. Wenn ein Interpret (möglicherweise ist dies ein
ganzes Orchester) ein Musikstück spielt, gehen Informationen aus den Noten unweigerlich
verloren. Dies betrifft insbesondere unscharfe Angaben in den Noten wie Lautstärke- oder Tempoangaben, die abhängig von der Interpretation des Musikers unterschiedliche Ausprägungen
annehmen. Aber auch die Extraktion einzelner Stimmen aus einem mehrstimmigen Satz ist
schwierig. Akkustische Repräsentation mit dem Computer geschieht durch Abtastung und
Quantisierung analoger Signale (z. B. WAV-Dateien). Auch dabei können bereits Informationen verloren gehen, die allerdings im Idealfall für das menschliche Gehör nicht wahrnehmbar
sind. Häufig werden die Informationen nach psychoakustischen Modellen verlustbehaftet komprimiert (z. B. MP3). Bei geeignet hoher Datenrate ist für den menschlichen Zuhörer kein
Unterschied zur unkomprimierten Variante feststellbar.
Auch symbolische Repräsentationen von Musik haben, je nach Anwendungsgebiet, unterschiedliche Ausprägungen. Auf der einen Seite stehen Formate, die nur Spiel- und Steueranweisungen
enthalten, wie z. B. das im Studiobereich gebräuchliche MIDI-Format. Dem gegenüber existieren Formate, die rein auf die visuelle Präsentation von Noten und Partituren ausgelegt sind.
Populäre Beispiele hier sind Lilypond und MusicTEX.
Zusätzlich hat sich neben einer unübersichtlich großen Anzahl offener und proprietärer Formate
das relativ junge XML-basierte Format MusicXML als universelles Austauschformat etabliert.
Eine Übersicht über die vielen Datenformate für Musiknotation findet sich in [Castan]. Beispielhaft wird im Folgenden auf MIDI, Lilypond und MusicXML eingegangen. Letzteres wird
von dem im Rahmen der Diplomarbeit entstandenen Werkzeug zur harmonischen Analyse
beim Import von Musikdaten verwendet. Mit Lilypond sind die Noten und Partituren in dieser
Arbeit gesetzt worden, aufgrund dessen sich auch hierzu eine Darstellung lohnt.
Daneben existieren einige nur in speziellen Werkzeugen verwendete Formate. Das in Abschnitt
2.4.1 vorgestellte Humdrum-Toolkit benutzt bspw. eine ganze Sammlung verschiedener Formate,
die jeweils Informationen für bestimmte Aufgabenstellungen enthalten. Auf zwei dieser Formate
wird bei der Vorstellung von Humdrum eingegangen.
2.3.1 MIDI
Das 1981 entwickelte und sehr weit verbreitete MIDI-Format (Musical Instrument Digital
Interface) ist eigentlich ein Protokoll zur Übertragung von Steuerinformationen zwischen
Instrumenten und Studioequipment bzw. einem PC [MIDI]. Im Gegensatz zu den anderen
hier vorgestellten Formaten enthält es keine expliziten Informationen über die Dauer einer
34
Relevante Grundlagen aus der Musikwissenschaft
Note, sondern benutzt Kommandos zum Ein- und Ausschalten eines Klangs. Diese sind in
sog. MIDI-Events organisiert. Neben dem eigentlichen Kommando enthält ein Event einen
Zeitstempel, der eine präzise Einordnung in den Ablauf eines Musikstückes ermöglicht.
MIDI bietet mit sog. Meta-Events die Möglichkeit, neben den reinen Steuerinformationen
beliebige zusätzliche Informationen über die Noten zu realisieren. Allerdings ist dies nicht im
Standard definiert, und es gibt auch keine Konvention zur einheitlichen Einbettung bestimmter
Daten. Ohne zusätzliche Informationen eignet sich MIDI schon aus einem einzigen Grund
nicht für eine harmonische Analyse: Tonhöhen werden ausschließlich in Halbtonschritten von 0
bis 127 nummeriert. So entspricht die 73 dem zweigestrichenen cis, gleichzeitig aber auch dem
zweigestrichenen des. MIDI unterscheidet also nicht zwischen enharmonisch verwechselbaren
Tönen. Derart dargestellte Musik ist einer harmonischen Analyse nur schwer zugänglich,
weil Akkorde nicht eindeutig definiert sind. Daher findet MIDI im Rahmen der Arbeit keine
Verwendung.
Trotz vieler auch in anderen Bereichen bestehender Einschränkungen hat sich MIDI zu einem
Quasistandard für den Musikdatenaustausch entwickelt. Allerdings treten beim Austausch
zwischen verschiedenen Programmen häufig Kompatibilitätsprobleme auf, die den Verlust von
Informationen beim Import zur Folge haben können. Das 2004 vorgestellte MusicXML ist
bestrebt, dieser Herausforderung zu begegnen und ein einheitliches und umfassendes Format
zum Austausch von Spielanweisungs- und Notensatzdaten zu schaffen.
2.3.2 Lilypond
Lilypond [Nienhuys u. Nieuwenhuizen 2003] ist ein freies, für alle gängigen Betriebssysteme
verfügbares Notensatzprogramm. Zur Beschreibung der Partituren kommt eine textbasierte
TEX-ähnliche Beschreibungssprache zum Einsatz, welche sehr präzise Angaben zum Notensatz
erlaubt. Lilypond übersetzt den Quelltext in eine ansprechende dem traditionellen handgesetzten Notenbild ähnliche Darstellung.
Das teilweise in der funktionalen Programmiersprache Scheme geschriebene Lilypond hat keine
grafische Oberfläche, sondern besteht nur aus einem Kommandozeilenwerkzeug. Dadurch kann
es aber leicht in andere Programme und Prozesse integriert werden. Beispielsweise stellt die
freie Partiturdatenbank Mutopia [Mutopia] alle Noten auf der Webseite mit Lilypond dar und
erlaubt auch das Herunterladen ganzer Stücke im Lilypond-Format.
Obwohl zahlreiche Exportmöglichkeiten z. B. nach Postscript, PDF und auch MIDI vorhanden
sind, eignet sich Lilypond nicht sehr gut für eine harmonische Analyse. Der Fokus liegt eindeutig
Digitale Musikrepräsentation
\relative c’ {
c d e f
g a b c
35
}
Abbildung 2.21: Beispiel einer einfachen Lilypond-Visualisierung mit zugehörigem Quelltext.
Das Kommando relative wählt die Oktave eines Tons derart, dass das Intervall zum vorherigen
Ton minimal ist.
auf der visuellen Repräsentation von Noten bzw. Partituren. Einfache Beispiele wären zwar
leicht zu handhaben, aber bei komplexen Darstellungen fehlt im Format eine hierarchische
Gliederung der Musikinformationen. Ebenso wie bei MIDI gibt es keine einheitliche Konvention
oder einen Standard zur Repräsentation von zusätzlichen (Meta-) Informationen, da Lilypond
niemals als universelles Austauschformat gedacht war.
Auch die Noten in dieser Arbeit sind mit Hilfe von Lilypond und einem zusätzlichen Werkzeug
zur direkten Integration von Lilypond-Beschreibungen in das LATEX-System entstanden. In
Abbildung 2.21 ist eine Beispieldarstellung mit dem zugehörigen Lilypond-Quelltext gegeben.
Das Kommando \relative sorgt dafür, dass eine Note immer relativ zur vorherigen Note
gesetzt wird. Dabei wird der Oktavbereich eines Tons derart gewählt, dass der Abstand zur
vorherigen Note minimal ist. Auf diese Art und Weise lassen sich Melodieverläufe sehr schnell
kodieren. c’ hinter der Anweisung bezeichnet die Startnote für die Berechnung der relativen
Beziehung (hier also das eingestrichene c). Diese Note selbst wird aber nicht dargestellt,
sondern erst alle darauf folgenden. Im Beispiel werden keine Angaben zu Notenschlüssel oder
Taktart gemacht, so dass als Standard ein Violinschlüssel sowie ein 4/4-Takt angenommen
wird.
2.3.3 MusicXML
Das erst 2004 in der Version 1.0 fertiggestellte und seit 2007 in der Version 2.0 verfügbare
Musikformat MusicXML [Good 2000] hat sich in kürzester Zeit als universelles Austauschformat
für Musikdaten etabliert. Die von vielen freien und kommerziellen Programmen und auch in
dieser Arbeit zum Datenimport verwendete Version ist MusicXML 1.1 aus dem Jahr 2005.
Gegenüber dieser Version sind in MusicXML 2.0 einige neue Attribute hinzugekommen. Vor
allem aber wurde eine komprimierte Variante vorgestellt, die den Platzbedarf deutlich reduziert.
Allerdings wird es von den in der Arbeit verwendeten Programmbibliotheken bislang nicht
unterstützt, was die Verwendung von MusicXML 1.1 erforderlich macht.
36
Relevante Grundlagen aus der Musikwissenschaft
Als XML-basiertes Format hat MusicXML den Vorteil, dass es mit vorhandenen XMLProgrammbibliotheken leicht zu handhaben und manipulieren ist. Die manuelle Bearbeitung
der in Textform vorliegenden Dateien ist zwar denkbar, wird aber bei steigender Dateigröße
sehr schnell unübersichtlich. Viele populäre Musiknotationsprogramme erlauben den Datenimport und -export von MusicXML-Dateien, wodurch ein zuverlässiger Austausch von
Musik in Notenform zwischen interessierten Personengruppen (wie z. B. Komponisten oder
Musikwissenschaftlern) ermöglicht wird.
MusicXML enthält sowohl Spielanweisungs- als auch Steuerinformationen, so dass es in vielen
Fällen als Ersatz für MIDI dienen kann. Zusätzlich können Layoutinformationen gespeichert
werden, um die Visualisierung von Partituren zu ermöglichen. Ab Version 2.0 ist es darüber
hinaus möglich, in einem zusätzlich definierten komprimierbaren Container-Format Bilder,
Audiodateien und andere Multimediadokumente zu speichern.
Im nächsten Abschnitt gehen wir kurz auf die wichtigsten Elemente von MusicXML 1.1
ein. Nach Vorstellung eines Beispiels werden die in dieser Arbeit relevanten und später im
relationalen Modell abgebildeten Attribute erläutert. Für eine vollständige und detaillierte
Betrachtung aller Eigenschaften sei auf [MusicXML] verwiesen.
Anschließend werden der grundsätzliche Aufbau und die im Rahmen der Arbeit verwendeten
Attribute aus dem MusicXML-Format erläutert. Das Beispieldokument in Abbildung 2.22
repräsentiert ein eingestrichenes c als ganze Note. Dieses ist definiert in einem Notensystem
mit Violinschlüssel, welches die Taktart 4/4 besitzt.
Jedes MusicXML-Dokument enthält im Kopf die nötigen XML-Deklarationen und den Verweis
auf die jeweilige DTD (Document Type Definition). Hier wird auf die sog. Partwise-DTD von
MusicXML verwiesen, d. h. im Dokument werden jeweils Takte pro Stimme (Part) notiert. Bei
der Timewise-DTD ist es genau umgekehrt, so dass in einem solchen MusicXML-Dokument
die Stimmen einzeln pro Takt notiert werden.
Das alle anderen Elemente umschließende Wurzelelement eines MusicXML-Partwise-Dokuments
ist das XML-Element <score-partwise version="1.1">. Unter diesem sind die einzelnen
Parts angeordnet. Zuvor werden diese aber in einem <part-list>-Element deklariert. Der einzige vorkommende Part im Dokument, der im Anschluss durch ein <part>-Element eingeleitet
wird, enthält wiederum nur einen einzigen Takt (<measure number="1">).
In diesem Takt werden zunächst im <attributes>-Element Eigenschaften für diesen Part
des Musikdokumentes festgelegt. Die Eigenschaften legen fest, wie die im Anschluss definierten musikalischen Entitäten (z. B. Noten) interpretiert werden. Die im Beispiel festgelegten
Attribute sind:
Digitale Musikrepräsentation
4
4 <? xml version = " 1.0 " encoding = " UTF -8 " standalone = " no " ? >
<! DOCTYPE score - partwise PUBLIC
" -// Recordare // DTD MusicXML 1.1 Partwise // EN "
" http: // www . musicxml . org / dtds / partwise . dtd " >
< score - partwise version = " 1.1 " >
< part - list >
< score - part id = " Part1 " >
< part - name > Part1 </ part - name >
</ score - part >
</ part - list >
< part id = " Part1 " >
< measure number = " 1 " >
< attributes >
< divisions >1 </ divisions >
< key >
< fifths >0 </ fifths >
</ key >
< time >
< beats >4 </ beats >
< beat - type >4 </ beat - type >
</ time >
< clef >
< sign >G </ sign >
< line >2 </ line >
</ clef >
</ attributes >
< note >
< pitch >
< step >C </ step >
< octave >4 </ octave >
</ pitch >
< duration >4 </ duration >
< type > whole </ type >
</ note >
</ measure >
</ part >
</ score - partwise >
Abbildung 2.22: MusicXML-Repräsentation der ganzen Note c’ in einem 4/4 Takt
37
38
Relevante Grundlagen aus der Musikwissenschaft
Divisions: Dieses Attribut legt die Basiseinheit für die Dauer der später definierten Noten
fest. Definiert ist dieses Attribut als die Anzahl von Unterteilungen einer Viertelnote.
Der im Beispiel festgelegte Wert 1 bedeutet, dass die kleinste im Part vorkommende
Note eine Viertelnote ist. Andere Werte größer 1 haben feinere Unterteilungen zur Folge.
Beispielsweise bedeutet eine 4, dass die kleineste darstellbare Note eine 1/16-Note ist.
Key: Mit dem <key>-Element wird die Anzahl und Art der Vorzeichen festgelegt. Der hier
verwendete Wert 0 hat zur Folge, dass keine Vorzeichnung besteht (entspricht u. a. C-Dur).
Positive Werte legen die Anzahl der Kreuz-Vorzeichen fest, negative die Anzahl der
Be-Vorzeichen. Die Bezeichnung Fifths hat ihren Ursprung in der englischen Übersetzung
des Wortes Quintenzirkel (Circle of Fifths).
Time: <time> legt die Taktart fest. Die Kindelemente <beat> und <beat-type> stehen dabei
für Zähler und Nenner. Im Beispiel wird ein 4/4-Takt benutzt. Daher haben beide
Attribute den Wert 4.
Clef: Dieses Attribut legt schließlich den Notenschlüssel fest. Dabei bezeichnet das im <sign>Element eingetragene G, dass ein Violinschlüssel (oder G-Schlüssel) benutzt wird. Die
Notenlinie, auf der das g’ definiert wird, wird im <line>-Element eingetragen. Mit dem
Wert 2 wird die übliche Verwendung des Violinschlüssels erreicht, die das g’ auf der
zweiten Notenlinie definiert.
Zu beachten ist, dass die Tonhöhe später unabhängig von Notenschlüssel und Vorzeichnung
angegeben wird. Daher haben diese Angaben nur Bedeutung für das Layout, was von Notensatzprogrammen genutzt werden kann.
Nach der Definition der für den gesamten Part geltenden Eigenschaften folgen im Anschluss
daran die einzelnen musikalischen Elemente. Im vorliegenden Beispiel wird an dieser Stelle
in einem <note>-Element eine einzige Note definiert. Die hier festgelegten Eigenschaften für
diese sind:
Pitch: Das <pitch>-Element legt die Tonhöhe der Note fest. Im Gegensatz zum MIDIFormat wird diese nicht durch eine Halbtonnummer bestimmt, sondern wird durch
Stammton innerhalb einer Oktave, Nummer der Oktave und Alteration in Halbtonschritten
angegeben. Dies hat den Vorteil, dass enharmonisch verwechselbare Tonhöhen eindeutig
den entsprechenden Stammtönen zugeordnet werden können. Im Beispiel wird durch
<step> C der Stammton C und mit <octave> 4 die eingestrichene Oktave verwendet.
Alterationen werden mit dem Element <alter> definiert. Dieses kann aber, wie hier,
ausgelassen werden, wenn kein Vorzeichen benutzt werden soll.
Computergestützte harmonische Analyse
39
Duration: Mit dem <duration>-Element wird die Dauer einer Note normiert auf die Anzahl
von Unterteilungen einer Viertelnote angegeben. Eine ganze Note, wie hier im Beispiel, hat
die Dauer von vier Viertelnoten. Wie oben erläutert, werden im Beispiel die Viertelnoten
nicht unterteilt, woraus sich hier ein Wert von 4 ergibt. Bei vier Unterteilungen (also
1/16-Noten als kleinste Einheit) ergäbe sich andererseits der Wert 16, da eine ganze Note
aus ebenso vielen 1/16-Noten zusammen gesetzt werden kann.
Type: Eine gewisse Redundanz bzgl. der Notendauer birgt das <type>-Element. Im Beispiel
wird mit dem Wert whole nochmals festgelegt, dass hier eine ganze Note beschrieben
wird. Der Grund hierfür ist, dass je nach Anwendungsgebiet die eine oder andere Darstellungsform einfacher zu benutzen ist. Weitaus wichtiger ist aber, dass es Fälle gibt, in
denen eine Note anders vom Interpreten (dies kann auch ein Computerprogramm sein)
gespielt werden soll, als sie notiert ist. Populäre Beispiele sind die Interpretation von
Achtelnoten im Jazz oder Swing.
2.4 Computergestützte harmonische Analyse
Die Analyse eines musikalischen Werkes unter Berücksichtigung des harmonischen Aspektes
ist eine sehr arbeitsintensive und komplexe Aufgabe. Im ersten Schritt werden die einzelnen
Zusammenklänge separat betrachtet. Dabei wird sowohl eine Akkordbestimmung durchgeführt,
als auch der Bau des Zusammenklangs untersucht. Im nächsten, weitaus schwierigeren Schritt
werden die Funktionen der Akkorde bestimmt und schließlich die Wirkung von Akkordfolgen
betrachtet und analysiert. Dabei werden in den meisten Fällen Informationen benötigt, die
sich auf den Gesamtkontext beziehen. Aufgrund der Komplexität der harmonischen Analyse
kann der Computer als Hilfsmittel nur eine unterstützende Aufgabe übernehmen.
Zunächst müssen die einzelnen Werke in eine vom Computer lesbare Sprache übersetzt werden,
damit eine Analyse mittels spezieller computergestützter Werkzeuge erfolgen kann. Dafür ist die
geeignete Kodierung der benötigten musikalischen Parameter von großer Wichtigkeit. Nicht alle
Datenformate, die Musik repräsentieren, sind für die harmonische Analyse gleich gut geeignet.
Beim MIDI-Format fehlt bspw. einem gegebenen Ton die Zuordnung zum entsprechenden
Stammton, eine Grundvoraussetzung für die Intervallbestimmung.
In den folgenden Abschnitten werden die zwei fortgeschrittensten existierenden Werkzeuge
für die computergestützte harmonische Analyse, Humdrum und Rubato, vorgestellt. Darüber
hinaus behandeln auch einige für die Komposition tonaler Werke gedachte Werkzeuge Teila-
40
Relevante Grundlagen aus der Musikwissenschaft
**kern
**kern
**hint
*M4/4
*M4/4
*M4/4
=1-
=1-
=1-
4c
4c’
P1
4d
4b
P6
4e
4a
4f
4g
=2
=2
4g
4f
M2
4a
4e
P4
4b
4d
M6
4c’
4c
P1
*-
*-
*-
(a)
P4
M2
=2
(b)
(c)
Abbildung 2.23: Intervallbestimmung mit Humdrum. (a) Die Quelldatei in **kern-Notation
enthält zwei Spalten für die zwei Stimmen (b) Notendarstellung des Beispiels (c) Resultat der
Intervallbestimmung in **hint-Notation.
spekte der harmonischen Analyse. So können u. a. OpenMusic [Agon u. Assayag 2002] und
Capella Tonica [Capella] eine Akkordbestimmung durchführen.
2.4.1 Humdrum
Wesentlich bessere und komplexere Analysemöglichkeiten als die Kompositionsprogramme
bietet das Humdrum-Toolkit [Humdrum], welches aus einer Bibliothek von einzelnen unabhängigen Analyseprogrammen besteht, die speziell für die Analyse von Musikwerken unter
Unix-Systemen entwickelt wurden. Die Einzelprogramme arbeiten dabei auf speziellen textbasierten Datenformaten, die in Zeilen und Spalten organisiert sind, und sich daher auch mit
vorhandenen Unix-Werkzeugen wie grep, sed oder awk verarbeiten lassen. Dies ist auch für
tiefergehende Analysen mit Humdrum unerlässlich.
Das Basisformat für die Repräsentation von Partituren ist die **kern-Darstellung. Sie enthält
ähnlich wie MusicXML die einzelnen Noten u. a. mit Angaben über Tonhöhen, Tondauern
und Alterationen. Exemplarisch wird im Folgenden gezeigt, wie mit Humdrum alle Intervalle
eines kurzen Musikausschnittes bestimmt werden (siehe Abbildung 2.23).
Computergestützte harmonische Analyse
41
Die Ursprungsdatei im **kern-Format beginnt mit einer Deklaration des Formates und der
Festlegung der Taktart (Measure) für jede der in den beiden Spalten notierten Stimmen. Daraufhin wird der erste Takt mit einem unsichtbaren Taktstrich (=1-) eingeleitet. Im Anschluss
daran wird zeilenweise jeweils eine Note pro Stimme definiert. Diese werden durch Tondauer
und Tonhöhe bestimmt (z. B. 4c für eine c’ -Viertelnote). Nach vier Noten wird ein sichtbarer
Taktstrich für den zweiten Takt (=2) eingefügt und schließlich nach weiteren vier Noten das
Ende der Spalten markiert (*-).
Um nun alle Intervalle zwischen den parallel verlaufenden Stimmen zu bestimmen, benutzt man
das Kommandozeilenwerkzeug hint, welches aus der **kern-Datei eine **hint-Datei erzeugt,
die die Intervallinformationen enthält. Diese Datei ist ähnlich wie die Quelldatei aufgebaut,
enthält aber nur noch eine Spalte, da zwei der ursprünglichen Noten jeweils ein Intervall
definieren. Kodiert werden die Intervalle durch zwei Attribute: zunächst die Intervallform (z. B.
P für perfect = rein, M für major = groß) und im Anschluss die Anzahl der Stammtonschritte
(z. B. 4 für eine Quarte). Beachtet werden muss, dass eine Oktave einer Prime gleichgesetzt
wird und die Intervallbestimmung jeweils vom tiefsten Ton ausgeht, weswegen im Beispiel die
Intervalle symmetrisch auftreten.
Humdrum besitzt eine große Menge weiterer Funktionalitäten. Dazu zählen bspw. Visualisierungs- oder Abspielwerkzeuge sowie Werkzeuge für die Transformation zwischen verschiedenen
Formaten. Weitere Möglichkeiten bieten Transformations- und Filterwerkzeuge. Hilfreich für
die harmonische Analyse ist die Möglichkeit, auch auf einzelne Musikausschnitte Algorithmen
anzuwenden, die z. B. versuchen, die in diesem Teil gültige Tonart zu bestimmen. Lediglich
eine grafische Oberfläche zur interaktiven Durchführung von Arbeitsschritten jenseits von
Kommandozeilenwerkzeugen ist in Humdrum nicht vorhanden.
2.4.2 Rubato
Das Rubato-Rahmenwerk ist eine Software zum künstlichen Abspielen von Musikstücken,
die auf den Erkentnissen der mathematischen Musiktheorie aufbaut [Mazzola u. Zahorka
1994]. Die eigentliche Funktionalität ist in Plugins, den sog. Rubetten, implementiert. Für
die harmonische Analyse existiert dafür die Harmo-Rubette, welche auf den Grundlagen der
Riemannschen Funktionstheorie aufbaut.
Rubato verfolgt das Konzept der halbautomatischen Musikanalyse. Bei der Analyse können
Gewichtungsfaktoren vergeben werden, welche später beim Vorspielen durch die PerformanceRubette verifiziert werden. Allerdings erfordert die Analyse mit Rubato eine umfangreiche
42
Relevante Grundlagen aus der Musikwissenschaft
Einarbeitung in die zugrunde liegenden Theorien, so dass eine detaillierte Betrachtung im
Rahmen der Diplomarbeit nicht möglich ist.
Rubato wurde ursprünglich auf dem NextStep-Betriebssystem implementiert und später nach
MacOS X portiert. Der neuentwickelte Rubato Composer implementiert das Rahmenwerk und
die wichtigsten Rubetten in Java [Milmeister 2006].
3 Relevante Grundlagen aus der Informatik
In diesem Kapitel wird eine kurze Einführung in die relevanten Themenbereiche aus der
Informatik gegeben. Relationale Datenbanken bilden die Grundlage des im Rahmen der
Diplomarbeit entwickelten Werkzeugs zur harmonischen Analyse, weshalb ein Einblick in
diesen Bereich für das spätere Verständnis unerlässlich ist. Die darauf aufbauende Anwendung ist in Java implementiert. Daher wird auch hierfür eine kurze Einführung gegeben.
In diesem Zusammenhang werden auch die benutzten Bibliotheken für die Darstellung der
grafischen Benutzeroberfläche (Swing und JOGL) und für die Datenbankanbindung (JDBC)
kurz vorgestellt.
Die in diesem Kapitel gemachten Ausführungen sind hierbei ausführlicher als üblich, da sie
auch für Musikwissenschaftler im Rahmen interdisziplinärer Zusammenarbeit einen leichten
Einstieg in die Materie bieten sollen.
3.1 Relationale Datenbanken
Die Aufgabe einer Datenbank (DB) bzw. genauer eines Datenbankmanagementsystem (DBMS)
besteht in der strukturierten, anwendungsunabhängigen Speicherung und Verwaltung von
Informationen. Zentrale Aufgaben neben der eigentlichen Speicherung der Daten sind die
Verwaltung der Struktur- bzw. Schemainformationen sowie die Bearbeitung von Anfragen.
Anfragen umfassen in diesem Zusammenhang nicht nur einfache lesende Zugriffe (z. B. wie bei
einer Suche im Internet), sondern auch komplexe Leseanfragen sowie schreibende Zugriffe auf
die Daten und die Schemainformationen. Ein Schema beschreibt hierbei, wie die gespeicherten
Daten strukturiert sind und welche Verknüpfungen sie untereinander besitzen.
Eine wichtige Aufgabe des DBMS ist die Sicherstellung der Konsistenz der gespeicherten
Informationen. Dies betrifft einerseits die physische Ebene, auf der eine Behandlung von Fehlersituationen (z. B. Hardware-Defekte, Stromausfall, ungenügender Speicherplatz) erfolgen muss.
Auf der anderen Seite ist auch die semantische Korrektheit der gespeicherten Informationen
von grundlegender Bedeutung. Beispielsweise muss bei einer Geldüberweisung sichergestellt
43
44
Relevante Grundlagen aus der Informatik
sein, dass ein von einem Konto abgebuchter Betrag auch auf dem Zielkonto korrekt verbucht wird. Bei einem Fehler muss die gesamte Überweisung rückgängig gemacht werden.
Eine solche Menge von zusammenhängenden Änderung wird als Transaktion bezeichnet. Die
Transaktionsverwaltung ist daher eine zentrale Aufgabe eines DBMS.
Die Einführung in diesem Kapitel befasst sich nicht weiter mit diesen Verwaltungsebenen eines
DBMS, da sie für das weitere Verständnis nicht von großer Bedeutung sind. Trotzdem sollte
dieser Punkt nicht vernachlässigt werden, da er einen wesentlichen Vorteil bei der Benutzung
von Datenbanken darstellt. Hier steht aber die Modellierung der Informationen im Vordergrund.
Zunächst wird daher kurz erklärt, was Relationen sind und wie sie in relationalen Datenbanken realisiert sind. Im Anschluss wird eine Einführung in Entity-Relationship-Diagramme
gegeben, die ein zentrales Werkzeug beim Datenbankentwurf sind. Die Datenbanksprache
SQL (Structured Query Language) ist die Standardsprache, mit der mit Datenbanksystemen
kommuniziert wird, also Anfragen an sie gestellt werden. Daher ist ihr ein wesentlicher Teil
dieses Abschnitts gewidmet.
Grundlage dieses Abschnitts über relationale Datenbanken sind [Kemper u. Eickler 2006] und
[Manthey 2005] sowie [Date u. Darwen 1998] für die Ausführungen über SQL.
3.1.1 Relationen
Relationalen Datenbanken liegt das mengentheoretische Konzept der Relation zu Grunde.
Relationen in diesem Sinne beschreiben ebenso wie allgemein gebräuchlich, ob Dinge (Entitäten) in Beziehung zu einander stehen. Beispielsweise liegt die Stadt Rom im Land Italien,
weswegen sie in der Relation Stadt liegt in Land enthalten ist. Man kann sich eine Relation im
Datenbankbereich als eine Tabelle vorstellen, die Einträge für alle in dieser Relation enthaltenen Entitätsbeziehungen enthält. Im vorliegenden Beispiel wäre dies eine Tabelle mit den
Spalten Stadt und Land (Attribute). Die Zeilen enthielten dann die jeweiligen Beziehungspaare
(Tupel), z. B. (Rom, Italien).
Mathematisch gesehen ist eine Relation R eine Teilmenge eines kartesischen Produktes von
Mengen An ; n ∈ N:
R ⊂ A1 × · · · × An
A1 × · · · × An := {(a1 , . . . , an )|(a1 ∈ A1 ∧ · · · ∧ an ∈ An }
Das kartesische Produkt von n Mengen enthält alle möglichen n-Tupel, die aus den Elementen
dieser Mengen gebildet werden können. Eine Menge ist dabei eine ungeordnete und duplikatfreie
Sammlung von Objekten. Prinzipiell kann sich die Anzahl und Art der Objekte in den Mengen
unterscheiden. Im Bereich relationaler Datenbanken wird aber angenommen, dass die Art (der
45
Relationale Datenbanken
Städte × Länder
Städte
Länder
Rom
Italien
StadtInLand
Rom
Italien
Rom
Frankreich
Rom
Italien
Paris
Frankreich
Paris
Italien
Paris
Frankreich
Paris
Frankreich
Abbildung 3.1: Kartesisches Produkt und Relationen in Tabellendarstellung.
Typ) der Objekte in einer Menge gleich ist (z. B. nur Text oder nur ganze Zahlen). Darüber
hinaus sind die Tupel in den Tabellen geordnet gespeichert, was in der Praxis aber keine
semantische Bedeutung hat (außer wenn explizit eine Sortierung oder Gruppierung gefordert
wird). Grundsätzlich sind in relationalen Datenbanken auch Duplikate in den Zeilen einer
Tabelle möglich. Meistens wird aber über ein eindeutig identifizierendes Attribut, einen sog.
Primärschlüssel (z. B. eine Nummer oder eine eindeutige Abkürzung), auf die Tupel zugegriffen,
so dass Duplikatfreiheit gewährleistet ist. Primärschlüssel müssen nicht einzelne Attribute
sein. Es ist ebenso möglich, dass Kombinationen von Attributen als Primärschlüssel verwendet
werden.
Beim betrachteten Beispiel gibt es die Mengen Städte und Länder, die beispielsweise Rom
und Paris sowie Italien und Frankreich enthalten könnten. Das kartesische Produkt dieser
Mengen sind dann die Paare (Rom, Italien), (Rom, Frankreich), (Paris, Italien) und (Paris,
Frankreich), also alle Kombinationen von Städten und Ländern. Eine Relation könnte nun
z. B. die tatsächlichen Beziehungen speichern, würde also nur zwei Tupel enthalten: (Rom,
Italien) und (Paris, Frankreich) (siehe Abbildung 3.1). Spezialfälle für Relationen sind die
Mengen selbst, da sie selbst auch der Definition einer Relation entsprechen (hier also Städte
und Länder ).
Für die Konsistenzerhaltung ist es wichtig, Integritätsbedingungen zu definieren. Beispielsweise
soll die Relation StadtInLand nur Städte und Länder enthalten, die auch in den Stadt- bzw.
Land -Relation existieren. Beim Löschen eines Eintrags z. B. aus der Stadt-Relation könnte
dann darüber hinaus auch der entsprechende Eintrag aus der StadtInLand -Relation entfernt
werden (sog. referentielle Integrität). Voraussetzung für diese Art von Beziehungen ist die
Definition eines Primärschlüssels auf einer Relation, die ein Tupel eindeutig identifiziert. In
den Stadt- und Land -Relationen ist dies der jeweilige Name der Entität, der damit nur einmal
in der Relation vorkommen darf. Aber auch die StadtInLand -Relation könnte einen Schlüssel
haben. So kann von einer anderen Relation eindeutig eine bestimmte Stadt in einem Land
referenziert werden (z. B. (Cambridge, USA) gegenüber (Cambridge, GB)).
46
Relevante Grundlagen aus der Informatik
3.1.2 Konzeptuelle Modellierung mit ER-Diagrammen
Am letzten Beispiel zur Identifikation gleich bezeichneter Städte in verschiedenen Ländern
ist auch eine Schwierigkeit deutlich geworden: Wurde zunächst davon ausgegangen, dass ein
Eintrag in der Stadt-Relation genau einer Stadt in der Realität entspricht, so haben letztere
Überlegungen dies widerlegt. Tatsächlich repräsentiert ein Eintrag eben nur den Namen einer
möglichen Stadt, die erst durch weitere Charakterisierung auf eine Entität in der realen Welt
abgebildet wird. Dies muss beim Enwurf einer Datenbank berücksichtigt werden, da sich Fehler
dabei nach dem Einfügen von Daten deutlich schwerer korrigieren lassen.
In der Entwurfsphase können sog. Entity-Relationship-Diagramme (ER-Diagramme) bei der
Modellierung helfen. Sie eignen sich dafür, Entitätstypen (wie hier z. B. Stadt und Land )
und Beziehungen (z. B. StadtInLand ) herauszuarbeiten und konzeptuell darzustellen. Diese
Modellierung kann dann später bei der Realisierung des Datenbankschemas herangezogen
werden.
In dieser Arbeit werden zur konzeptuellen Modellierung ER-Diagramme in UML-Klassendiagramm-Notation [UML] verwendet. Sie eignen sich besonders, um darauf aufbauend die
Realisierung eines Datenbankschemas vorzunehmen [Sparks 2004]. Die ursprüngliche Form von
ER-Diagrammen ist die Darstellung in Chen-Notation [Chen 1976]. Im Folgenden werden die
in der Arbeit verwendeten Elemente vorgestellt und an kleinen Beispielen erläutert. Weitere
Details zu ER-Diagrammen finden sich in [Kemper u. Eickler 2006].
Entities
In den hier vorgestellten ER-Diagrammen werden Entitätstypen (Entities) durch Rechtecke
repräsentiert. Eventuell vorhandene zusätzliche Attribute können als Text darunter geschrieben
werden. Im Beispiel gibt es die Entitätstypen Stadt und Land. Letzteres hat als Attribut das
zweistellige internationale Länderkürzel. Falls die Attribute für den aktuellen Kontext nicht
von Bedeutung sind, können sie weggelassen werden.
Stadt
Land
Abkürzung
47
Relationale Datenbanken
Relationships
Beziehungen (Relationships) zwischen Entitätstypen werden als Verbindungslinien dargestellt.
Die Benennung der Relationships ist optional und wird bei Bedarf in der Mitte der Linie
notiert. Häufig ergibt sie sich direkt aus dem Kontext der beteiligten Entitätstypen.
Stadt
StadtInLand
Land
Relationships mit mehr als zwei beteiligten Entitätstypen werden mit eine Raute gekennzeichnet. Im Beispiel wird angenommen, dass jeder Dozent einer Vorlesung zu einem Thema
an einer Universität bestimmte Bücher empfiehlt. Je nach Dozent führt eine Vorlesung zum
gleichen Thema also zu unterschiedlichen Empfehlungen. Es gibt folglich eine Zuordnung
(Vorlesung, Dozent) → Bücher.
Vorlesung
empfehlen
Buch
Dozent
Funktionalitäten
Nähere Charakterisierungen der Relationships können in ER-Diagrammen durch Funktionalitäten ausgedrückt werden. Wird bspw. vereinfachend angenommen, dass eine Stadt mit
einem bestimmten Namen nur einmalig in einem Land vorkommt (also Städte in verschiedenen Ländern immer unterschiedliche Namen besitzen), und ein Land viele Städte enthalten
kann, ergibt sich eine 1:n-Beziehung. Bei den hier verwendeten ER-Diagrammen werden die
Funktionalitäten an die Verbindungslinien geschrieben. Dabei wird n durch einen Stern (*)
repräsentiert. Bezeichner für n:m-Beziehungen dürfen weggelassen werden, weil sie den Standardfall darstellen. Genauere Angaben der Funktionalitäten können mit der min..max -Notation
ausgedrückt werden (z. B. 1..* oder 2..4). Hierbei ist * gleich 0..n und 1 gleich 1..1.
1:1- und 1:n-Beziehungen entsprechen einer bzw. zwei mathematischen Funktionen, da eine
eindeutige Zuordnung in eine bzw. in beide Richtungen gegeben ist. Im Zusammenhang von
48
Relevante Grundlagen aus der Informatik
Datenbanken spricht man hier von sog. funktionalen Abhängigkeiten. Voraussetzung für eine
funktionale Abhängigkeit ist, dass jede Entität an der Relationship teilnimmt. Bspw. dürfte es
keine Städte ohne zugeordnetes Land geben. Auf der Land -Seite muss also die Funktionalität
1 stehen.
Stadt
1..*
StadtInLand
1
Land
Generalisierung
Zur Bildung von Typhierarchien wie in der objektorientierten Programmierung (siehe Kapitel
3.2.3) wird Generalisierung benutzt. Auf diese Weise können hierarchische Vererbungsbeziehungen realisiert werden. So könnte man Städte und Länder jeweils zu einem Obertyp Region
gehörig modellieren, auf dem Attribute definiert sind, die ebenfalls für die Untertypen gelten.
Bei disjunkter Zerlegung des Obertyps in die Untertypen werden gemeinsam einlaufende Pfeile
verwendet, ansonsten werden einzelne Elemente verwendet. Da relationale Datenbanken keine
Vererbung unterstützen, können mit Hilfe von Generalisierung modellierte Hierarchien nicht
direkt in ein Datenbankschema abgebildet werden.
Region
Stadt
1..*
StadtInLand
1
Land
Aggregierung
Eine weitere hierarchische Gliederung von Entitätstypen kann mit Hilfe der Aggegierung
erreicht werden. Aggregierungen fassen Entitätstypen zusammen, wenn sich Entitäten eines
Obertyps aus Instanzen von Untertypen zusammensetzen. In den ER-Diagrammen wird diese
spezielle Art der Beziehung durch einen Diamanten dargestellt. Bei vollständiger Aggregierung
(sog. Komposition) wird ein ausgefüllter, sonst ein nicht ausgefüllter Diamant verwendet. Dem
hier gegebenen Beispiel liegt ein sehr vereinfachtes Modell eines Fahrrads zu Grunde, welches
nur aus Rahmen und Rädern besteht.
49
Relationale Datenbanken
Fahrrad
1
1
Rahmen
2
Rad
3.1.3 Umsetzung von ER-Diagrammen in relationale Schemata
Nachdem die Entitätstypen und Relationships konzeptuell modelliert worden sind, stellt sich
die Frage, wie eine konkrete Realisierung in einer Datenbank aussehen könnte. Beispielsweise
kann eine durch Generalisierung ausgedrückte Vererbungshierarchie nicht direkt in einer
relationalen Datenbank dargestellt werden.
Es existieren aber Regeln, nach denen Modellierungen in ein Datenbankschema überführt
werden können. Grundsätzlich sind diese aber nicht eindeutig und es gibt gute und weniger
gute Realisierungen ein und derselben ER-Modellierungen. Kriterien für einen guten Datenbankentwurf sind sicherlich der Speicherplatzbedarf und die Zugriffszeit beim Beantworten
von Anfragen sowie der Aufwand beim Ändern von Daten. Besonders wichtig ist aber die
Vermeidung redundanter Speicherung von Informationen, da sie einerseits bei Änderungen
zu Inkonsistenzen (sog. Anomalien) führen kann, Änderungen aber auch einfach aufwendiger werden, da sie immer an mehreren Stellen gleichzeitig durchgeführt werden müssen.
In diesem Zusammenhang sind die Begriffe Funktionale Abhängigkeit und Normalisierung
von besonderer Bedeutung. Bei der Normalisierung werden Relationen bzw. Tabellen auf
Grundlage funktionaler Abhängigkeiten zerlegt, um Redundanzen zu vermeiden und somit die
Leistungsfähigkeit der Datenbank zu erhöhen. An dieser Stelle wird aus Platzgründen nicht
detailliert auf dieses Thema eingegangen, sondern nur einfache Regeln für die Überführung
einer konzeptuellen Modellierung in ein Datenbankschema vorgestellt. Zu beachten ist die
unterschiedliche Bedeutung der Bezeichnungen Relation und Relationship. Eine Relationship bezeichnet die Beziehung zwischen Entitätstypen. Ihrerseits können Entitätstypen und
Relationships in Datenbankschemata durch Relationen, d. h. Tabellen realisiert werden.
Vom grundsätzlichen Prinzip her ist die Umsetzung der konzeptuellen Modellierung ins relationale Schema einfach zu bewerkstelligen. Entitätstypen werden als Tabellen (d. h. als
Relationen) realisiert, wobei ihre Attribute als Spalten gespeichert werden. Identifizierende
Attribute werden auf Primärschlüssel abgebildet. Relationships können ebenfalls als Tabellen
50
Relevante Grundlagen aus der Informatik
realisiert werden. Für die Repräsentation der beteiligten Entitätstypen kommen sog. Fremdschlüsselbeziehungen zum Einsatz. Ein Fremdschlüssel referenziert eine andere Entität durch
sein Primärschlüsselattribut, welches die Entität eindeutig identifiziert. Für den häufigen Fall
von 1:n-, n:1- oder 1:1-Beziehungen kann jedoch auf das Anlegen eigener Tabellen für die
Relationship verzichtet werden. Stattdessen können die über die Relationship verknüpften
Entitätstypen in die Tabelle des mit n markierten Entitätstypen integriert werden. Bei 1:1Beziehung kann die Integration auf jeder Seite erfolgen. Um die Eindeutigkeit der Beziehung
zu gewährleisten, muss aber in jedem Fall der Primärschlüssel des integrierten Entitätstyps
zum Primärschlüssel des integrierenden Entitätstyps hinzugefügt werden.
Aggregierungen und Generalisierungen können ebenfalls nach bestimmten Regeln ins relationale
Schema überführt werden. Da in relationalen Daten aber bspw. keine Vererbungen von Attributen möglich sind, sind mehrere Möglichkeiten denkbar, die diese spezielle Beziehung nachbauen.
In den Details sind diese Mechanismen durchaus kompliziert und anwendungsabhängig, so
dass an dieser Stelle nicht weiter darauf eingegangen wird.
Mit Hilfe der bei der konzeptuellen Modellierung mit ER-Diagrammen verwendeten UMLNotation lässt sich ebenfalls die Realisierung eines relationalen Datenbankschemas darstellen.
Zur Unterscheidung von der konzeptuellen Modellierung werden Tabellenelemente dabei mit
<<table>> überschrieben. Die Schlüsselattribute bekommen <<key>> vorangestellt. Mit den
bisher vorgestellten Mitteln darstellbar sind auch Fremdschlüsselbeziehungen (d. h. mit Hilfe
von Verbindungslinien). Dabei werden die Beziehungen zusätzlich mit sog. Rollen auf jeder
Seite versehen, die mit den Namen der Primär- bzw. Fremdschlüsselattribute bezeichnet werden.
Als Beispiel kommt hier das bekannte StadtInLand -Beispiel zum Einsatz. Als Unterstützung
zur Navigation wird die Fremdschlüsselbeziehung zusätzlich mit einer Pfeilspitze versehen, die
auf die referenzierte Tabelle verweist.
<<table>>
Stadt
<<key>> Name
Kennzeichen
Einwohner
Land
1..*
Land
1
Name
<<table>>
Land
<<key>> Name
Abkürzung
Einwohner
3.1.4 SQL
Zur Definition des Datenbankschemas, zum Einfügen und Verändern von Daten und zur Beantwortung von Anfragen kommt eine Datenbanksprache zum Einsatz. Zwar bieten die meisten
Relationale Datenbanken
51
Datenbank-Managementsysteme (wie das im Rahmen der Diplomarbeit verwendete Microsoft
Access [Access]) eine grafische Oberfläche, allerdings lassen sich damit größere Projekte nur
schwer realisieren, da eine saubere und übersichtliche Definition des Datenbankschemas und
der Anfragen damit nur schwer möglich ist. Viel entscheidender ist allerdings, dass sich Operationen mit einer grafischen Oberfläche nicht automatisieren lassen. Beispielsweise sind die
Funktionen zum Importieren der Daten aus externen Quellen häufig sehr beschränkt, so dass
sie sich für das gerade vorliegende Format häufig nicht eignen.
Mit Hilfe einer Datenbanksprache, die sich innerhalb der grafischen Oberfläche sowie ebenso von
externen Programmen aus nutzen lässt (siehe Kapitel 3.2.6), lassen sich diese Herausforderungen
anwendungsunabhängig lösen. Meistens kommt hierfür die standardisierte Datenbanksprache
SQL (Structured Query Language) zum Einsatz, die von allen gebräuchlichen relationalen
Datenbank-Managementsystemen verstanden wird. SQL (ursprünglicher Name SEQUEL,
Structed English Query Language) ist 1970 von IBM entwickelt worden. Trotz 1992, 1999 und
2003 vorgenommener Standardisierungen versteht jedes DBMS häufig aber nur einen Teil der
jeweiligen Standards und darüber hinaus eigene Erweiterungen. In diesem Abschnitt wird eine
kurze Einführung in SQL gegeben, wobei hier der Microsoft Access-Dialekt verwendet wird.
Eingegangen wird in der Einführung nur auf die für das Verständnis der im Verlauf der Arbeit
benutzten SQL-Anfragen nötigen Grundlagen. Eine umfassende Einführung in SQL kann in
[Date u. Darwen 1998] nachgelesen werden.
Die Sprache SQL besteht aus drei Teilen: DDL (Data Definition Language), DML (Data
Manipulation Language) und DCL (Data Control Language). Auf die bspw. die Vergabe von
Berechtigungen ermöglichende DCL wird hier nicht eingegangen. Der Fokus liegt auf der DML
zur Manipulation und Abfrage von Daten in der Datenbank. Auf die DDL, welche das Anlegen
von Tabellen und sog. Sichten ermöglicht, wird zu Anfang kurz eingegangen.
DDL
Der SQL-Einführung in diesem Abschnitt liegt eine Beispieldatenbank eines Händlers zu
Grunde. In ihr sollen Produkte, Kunden und ihre Bestellungen gespeichert werden. Das relationale Schema der Datenbank ist in Abbildung 3.2 dargestellt. Kunden (Customers), Produkte
(Products) und Bestellungen (Orders) werden jeweils eindeutig durch Nummern identifiziert,
die die Primärschlüssel der Tabellen sind. Zusätzlich hat ein Kunde die Kontaktdatenattribute
name und address. Die Produkte werden ebenfalls durch einen Namen und natürlich den
Preis (name, price) charakterisiert. Eine Bestellung referenziert über das Attribut customerId
den Primärschlüssel der Customers-Tabelle (Fremdschlüsselbeziehung). Zusätzlich wird das
52
Relevante Grundlagen aus der Informatik
<<table>>
Orders
<<key>> id
orderDate
customerId
<<table>>
OrderItems
<<key>> orderId
<<key>> productId
quantity
<<table>>
Products
<<key>> id
name
price
<<table>>
Customers
<<key>> id
name
address
Abbildung 3.2: Relationales Schema der Kunden-Beispieldatenbank. Die Funktionalitäten und
Rollenbezeichnungen für die Fremdschlüsselbeziehungen sind aus Gründen der Übersichtlichkeit,
und da sie eindeutig sind, weggelassen worden.
Datum der Bestellung im Attribut orderDate abgelegt. Für die in einer Bestellung enthaltenen
Elemente existiert die Tabelle OrderItems, die in einer 1:n-Beziehung zu Orders steht. Für
jedes in einer Bestellung enthaltenes Produkt wird in ihr über Fremdschlüsselbeziehungen
die jeweilige Bestellung und das bestellte Produkt referenziert. Als zusätzliches Attribut
wird die bestellte Anzahl (quantity) des in der jeweiligen Bestellung enthaltenen Produktes
gespeichert.
Zum Anlegen der Datenbank kommt der DDL-Teil von SQL zum Einsatz (Data Definition
Language). Er bietet u. a. Möglichkeiten zum Anlegen, Verändern oder Löschen von Tabellen
und Sichten. Die folgenden CREATE TABLE-Anweisungen legen bspw. die beschriebene Beispieldatenbank an. INTEGER und VARCHAR sind Datentypen für ganze Zahlen bzw. Zeichenketten
mit einer angegebenen maximalen Länge. Mit PRIMARY KEY und REFERENCES werden die oben
beschrieben Primärschlüssel und die Fremdschlüsselbeziehungen definiert.
CREATE TABLE Customers (
id
INTEGER PRIMARY KEY ,
name
VARCHAR (80) ,
address
VARCHAR (160)
);
CREATE TABLE Orders (
id
INTEGER PRIMARY KEY ,
orderDate
DATE ,
customerId
INTEGER REFERENCES Customers
);
CREATE TABLE Products (
id
);
INTEGER PRIMARY KEY ,
name
VARCHAR (80) ,
price
FLOAT
Relationale Datenbanken
53
CREATE TABLE OrderItems (
orderId
INTEGER REFERENCES Orders ,
productId
INTEGER REFERENCES Products ,
quantity
INTEGER ,
PRIMARY KEY ( orderId , productId )
);
Mit der Anweisung DROP TABLE ist es möglich, eines Tabelle später wieder zu löschen. ALTER
TABLE ist ein Mechanismus zur Schemaevolution, d. h. hiermit können auch nach dem Anlegen einer Tabelle Änderungen an ihrer Definition vorgenommen werden. Entsprechende
Anweisungen existieren ebenso für Sichten. Im folgenden Beispiel wird mit Hilfe einer CREATE
VIEW-Anweisung eine Sicht erzeugt, die die Namen aller Kunden enthält. Der SELECT..FROMTeil ist eine Anfrage aus der DML. Im nächsten Abschnitt wird genauer hierauf eingegangen.
CREATE VIEW CustomerNames AS (
SELECT name FROM Customers
);
DML
Mit Hilfe der DML (Data Modification Language) aus SQL können u. a. Daten in die mit
der DDL angelegten Tabellen eingefügt werden. Andere Operationen löschen oder ändern
vorhandene Daten. Ebenso vorhanden sind umfangreiche Möglichkeiten zur Gestaltung von
Anfragen für die in der Datenbank gespeicherten Daten. Dieser Teil von DML macht den
größten Teil der hier gegebenen Einführung in SQL aus.
Zum Einfügen von Daten wird die INSERT-Anweisung benutzt. Angegeben werden hierbei der
Tabellenname, die zu befüllenden Spalten und schließlich die eigentlichen Werte, die eingefügt
werden sollen. In die Beispieldatenbank werden hier einige wenige Kunden, Produkte und eine
Bestellung gespeichert.
INSERT INTO Customers ( id , name , address )
VALUES (1 , ’ Homer Simpson ’ , ’ Springfield ’) ;
INSERT INTO Customers ( id , name , address )
VALUES (2 , ’ Harry Potter ’ , ’ Hogwarts ’) ;
INSERT INTO Products ( id , name , price )
VALUES (1 , ’ Nimbus 3000 ’ , 999) ;
INSERT INTO Products ( id , name , price )
VALUES (2 , ’ Donut ’ , 1.50) ;
54
Relevante Grundlagen aus der Informatik
INSERT INTO Orders ( id , orderDate , customerId )
VALUES (1 , ’ 2008 -03 -20 ’ , 2) ;
INSERT INTO OrderItems ( orderId , productId , quantity )
VALUES (1 , 1 , 2) ;
Ähnlich funktioniert der Mechanismus zum Löschen von Daten. Ein wesentlicher Unterschied
hierbei ist, dass auch mehrere Elemente gleichzeitig gelöscht werden. Entfernt werden alle
Elemente aus der angegebenen Tabelle, die der Bedingung im WHERE-Teil der DELETE-Anweisung
genügen.
DELETE FROM Customers WHERE id = 2;
Falls ein Tupel in einer Tabelle nicht gelöscht, sondern lediglich verändert werden soll, wird
dies mit einer UPDATE-Anweisung erreicht. Ebenso wie beim Löschen findet auch hier ein
Vergleich aller in der Tabelle gespeicherten Daten mit der Bedingung im WHERE-Teil statt, so
dass auch mehrere Elemente verändert werden können. Die neuen Werte werden im SET-Teil
gesetzt.
UPDATE Customers
SET
name = ’ Homer J . Simpson ’
WHERE
id = 2;
Die DML bietet umfangreiche Möglichkeiten, um Anfragen bzgl. der in der Datenbank gespeicherten Informationen zu formulieren. Die Grundstruktur einer Anfrage ist einfach. In ihr
finden sich die betrachteten Tabellen (tables), eine Bedingung, mit der Tupel selektiert werden
(condition) und schließlich die Angabe, welche Spalten extrahiert werden sollen (columns).
Falls die Tabellen nur unterschiedlich benannte Spalten enthalten, reicht hier die Angabe dieses
eindeutigen Namens. Im anderen Fall muss der Name der Tabelle, aus der die Spalte stammt,
in der Notation table.column angegeben werden. Falls alle Spalten in die Ergebnismenge
übernommen werden sollen, reicht die Angabe *.
SELECT { columns }
FROM
{ tables }
WHERE
{ condition };
Im WHERE-Teil können u. a. Vergleichbedingungen, Existenzbdingungen, boolesche Verknüpfungen (AND, OR, NOT), Existenzbedingungen oder Bedingungen für die Duplikatfreiheit benutzt
werden. Die folgende Anfrage selektiert bspw. alle Nummern von Produkte, die in einer einzigen
Bestellung mehr als zehn mal bestellt wurden. DISTINCT sorgt dafür, dass Duplikate aus der
Ergebnismenge entfernt werden. Im Beispiel gäbe es Duplikate, wenn ein Produkt schon in
mehreren Bestellungen mehr als zehn mal bestellt wurde.
Relationale Datenbanken
55
SELECT DISTINCT productId
FROM
OrderItems
WHERE
quantity > 10;
Für die Formulierung komplexer Anfragen dürfen SQL-Anfragen geschachtelt werden. In dem
hier gegebenen Beispiel wird die Anfrage von eben wiederverwendet, um zu den gefundenen
Produkten den Namen herauszufinden. EXISTS prüft hierbei, ob die Unteranfrage leer ist.
SELECT name
FROM
Products
WHERE
EXISTS ( SELECT productId
FROM
OrderItems
WHERE
quantity > 10 AND productId = id ) ;
Eleganter lässt sich diese Anfrage mit einer Join-Operation (Verbund ) ausdrücken. Bei
einem Verbund werden Tabellen über eine Bedingung miteinander verknüpft. Die häufigste
Verbundart ist der INNER JOIN, welcher auch in der Diplomarbeit verwendet wird. Bei diesem
Verbund wird zunächst das Kreuzprodukt der angegebenen Tabellen gebildet, also jedes Tupel
mit jedem aus der anderen Tabelle verknüpft. Danach wird schließlich eine Auswahl der Tupel
gemäß der Verbundsbedingung, also eine Selektion, durchgeführt.
SELECT name
FROM
Products INNER JOIN OrderItems
ON productId = id
WHERE
quantity > 10;
Ergebnisse von Anfragen mit gleichen Spalten können in mengentheoretischer Sicht verknüpft
werden. Im Beispiel wird mit UNION eine Vereinigung von zwei Ergebnismengen erreicht.
Natürlich hätte in diesem einfachen Fall auch eine boolesche OR-Verknüpfung den selben Zweck
erfüllt.
( SELECT DISTINCT productId
FROM
OrderItems
WHERE
quantity > 10;
)
UNION
( SELECT DISTINCT productId
)
FROM
OrderItems
WHERE
quantity < 5;
56
Relevante Grundlagen aus der Informatik
Für die Verarbeitung von Elementen stehen in SQL sog. Aggregatfunktionen zur Verfügung.
Mit COUNT kann bspw. die Anzahl von Tupeln in einer Anfrage bestimmt werden. Weitere
Aggregatfunktionen berechnen bspw. das Minimum, das Maximum oder das arithmetische
Mittel von Elementen in einer Spalte (MIN, MAX, AVG). Im vorliegenden Beispiel wird mit SUM
der Gesamtpreis einer Bestellung mit gegebener Nummer bestimmt. Zusätzlich werden hier die
Tabellen für die Benutzung in der Anfrage mit Hilfe von AS temporär umbenannt, damit die
Anfrage übersichtlicher ist. Darüber hinaus wird die Gesamtsumme mit einem bezeichnenden
Namen versehen.
SELECT
I . orderId , SUM ( P . price * I . quantity ) AS orderPrice
FROM
OrderItems AS I INNER JOIN Products AS P
ON I . productId = P . id
WHERE
I . orderId = 1
Mit den bisherigen Mitteln ist es nicht möglich, den jeweiligen Gesamtpreis aller Bestellungen
auszugeben, da die Aggregatfunktionen immer auf der Gesamtmenge der Zeilen arbeiten und
daher höchstens den zusammengerechneten Gesamtpreis aller Bestellungen berechnen könnten.
Mit Hilfe von GROUP BY wird dies möglich gemacht, da mit dieser Anweisung eine Gruppierung
vorgenommen werden kann. Die Aggregatfunktionen werden dann statt auf die Gesamtmenge an
Zeilen jeweils auf die einzelnen Gruppen angewendet. Zusätzlich ermöglicht HAVING, einzelne
Gruppen zu selektieren. Im Unterschied zu WHERE dürfen hier auch Aggregatfunktionen
verwendet werden.
SELECT
I . orderId , SUM ( P . price * I . quantity ) AS orderPrice
FROM
OrderItems AS I INNER JOIN Products AS P
ON I . productId = P . id
GROUP BY I . orderId
HAVING
SUM ( P . price * I . quantity ) > 10000
Auch Kontrollstrukturen sind in SQL in gewissem Maße vorhanden. Im Folgenden wird bspw.
ein Rabatt von 10% auf ein Produkt gewährt, wenn mindestens fünf davon gleichzeitig bestellt
werden. Die Microsoft Access-spezifische IIF-Anweisung ermöglicht dies. Sie arbeitet wie eine
if...then...else-Bedingung aus gewöhnlichen Programmiersprachen. Natürlich muss der
hier gewährte Rabatt bei der Preisberechnung später noch berücksichtigt werden.
SELECT I .* ,
IIF ( I . quantity >= 5 , 0.1 , 0) AS discount
FROM
OrderItems AS I
Auch Access-spezifisch ist die Möglichkeit, benannte Platzhalter als Parameter in Anfragen zu
definieren. Bei Ausführung innerhalb der Access-Oberfläche wird dann ein Dialog angezeigt, der
Java
57
zur Eingabe des entsprechenden Wertes auffordert. Nicht verwendbar sind solche Parameter,
wenn SQL-Anfragen über JDBC (siehe Kapitel 3.2.6) gestellt werden.
SELECT *
FROM
Customers
WHERE
name = [ Customer name ];
3.2 Java
Das im Rahmen der Diplomarbeit entwickelte Programm zur Musikanalyse ist in der Programmiersprache Java [Java] geschrieben. Java bezeichnet allerdings nicht nur die Programmiersprache selbst, sondern auch die sog. Java Virtual Machine und die Java-Plattformbibliothek,
bestehend aus einer großen Sammlung an Funktionen z. B. für mathematische Operationen,
Netzwerkkommunikation, grafische Oberflächen, Interpretation von XML-Daten sowie Eingabeund Ausgabebehandlung.
Zusätzlich zu den in den Standardinstallation vorhandenen Bibliotheken der Java-Plattform
wird die JOGL-Bibliothek [JOGL] zur Visualisierung der Partituren und der Ergebnisse der
Musikanalyse benutzt. Zur Kommunikation mit der zugrunde liegenden Datenbank wird JDBC
[JDBC], für die Erzeugung der grafischen Oberfläche die Swing-Bibliothek [Swing] verwendet.
Letztere sind in der aktuellen Standardbibliothek enthalten. Nach einer kompakten Einführung
in die Java-Programmierung wird in diesem Kapitel in jeweils eigenen Abschnitten auf die
benutzten Technologien eingegangen. Die Einführung in Java basiert in Teilen auf [Flanagan
2005], wo die angesprochenen Themen detailliert behandelt werden.
3.2.1 Die Java-Plattform
Java wurde 1995 von Sun Microsystems vorgestellt und hat sich seitdem zu einer der am
meisten benutzten Programmiersprachen entwickelt. Ausgehend von der Version 1.0 bis zur
aktuellen Version 6 (auch Version 1.6) gab es deutliche Änderungen und Verbesserungen zur
Steigerung der Produktivität. Zudem wurde die Java-Plattform 2007 unter eine freie Lizenz
gestellt. Sie besteht aus der Programmiersprache Java, der Java Virtual Machine und der
Plattformbibliothek. Zusätzlich zu der hier benutzten Java Standard Edition gibt es die Java
Enterprise Edition, welche zusätzliche Bibliotheken und eine komplette Server-orientierte
Architektur mit dem Fokus auf Unternehmensanwendungen beinhaltet.
58
Relevante Grundlagen aus der Informatik
Die syntaktischen Wurzeln von Java liegen in der Programmiersprache C++. Anders als diese
wurde Java aber von Grund auf mit dem Fokus auf Einfachheit und Lesbarkeit neu entworfen.
Dabei wurde keine Rücksicht auf Abwärtskompatibilität zu anderen Programmiersprachen
genommen, so dass keine syntaktischen Altlasten enthalten sind. Java ist eine durchgängig
objektorientierte (siehe Abschnitt 3.2.3) und typisierte Programmiersprache. Letzteres bedeutet,
dass der Typ einer Variablen zur Kompilierzeit definiert ist und daher schon zu diesem Zeitpunkt
eine statische Überprüfung der Semantik stattfinden kann, wodurch weniger Fehler zur Laufzeit
auftreten.
Dies entspricht dem Grundgedanken beim Entwurf der Java-Plattform. Im Zentrum stand die
Idee, ein einmal geschriebenes und kompiliertes Programm überall laufen lassen zu können.
Möglich wird dies dadurch, dass bei der Übersetzung kein von der jeweiligen Architektur
und dem Betriebssystem abhängiger Maschinencode erzeugt wird, sondern ein sog. Bytecode,
der von jeder Java Virtual Machine (JVM) gleich interpretiert wird. Die JVM selbst ist
prinzipiell plattformabhängig, es existieren aber verschiedene Implementierungen für alle
gängigen Betriebssysteme und Architekturen. Dies schließt nicht nur Großrechner und PCs
ein, sondern auch mobile Geräte wie Handys und PDAs. Zur Laufzeit erzeugt die JVM
plattformabhängigen Maschinencode, indem sie den Bytecode interpretiert. Alternativ kann
beim Starten oder zur Laufzeit des Programms mit Hilfe eines Just-in-Time-Compilers einmalig
Maschinencode erzeugt werden, der fortan direkt auf dem Prozessor lauffähig ist. Aktuelle
JVM-Implementierungen führen meist einen solchen Schritt durch, ohne dass der Benutzer
etwas davon bemerkt.
Im Fokus bei Java liegt die Entwicklung netzwerkfähiger Programme. Dies äußert sich einerseits durch einen großen Satz vorhandener Bibliotheken, die es z. B. erleichtern, Teile der
Funktionalität über sog. Web Services aus dem Internet zu beziehen. Andererseits erlaubt
es die JVM auch, direkt im Browser eines Benutzers Anwendungen auszuführen, die somit
Webseiten mit Java-Technologie erweitern (Applets). Benötigte Bibliotheken können dabei für
den Benutzer transparent nachgeladen werden. Zur Ausführung dieser Anwendungen kommt
ein umfangreiches Sicherheitsmodell zum Einsatz, damit z. B. kein unberechtigter Zugriff auf
Ressourcen auf dem lokalen Computer erfolgt.
3.2.2 Grundlagen der Java-Programmierung
Im Folgenden wird die grundlegende Syntax in Java geschriebener Programme vorgestellt.
Dabei beschränkt sich die Einführung auf einige wichtige Konzepte, um einen kurzen Überblick
zu geben. Dieser dient als Basis für spätere Erläuterungen.
Java
59
Eine detaillierte Einführung in die Syntax von Java würde den Rahmen dieses Abschnittes
sprengen, weswegen zunächst nur erwähnt sei, dass ein Java-Programm aus einer oder mehreren
Dateien mit der Endung .java besteht, die Deklarationen und Anweisungen enthalten. Das
folgende Beispielprogramm gibt die Zahl 42 aus, wobei es zum Kompilieren in einer Datei
HelloWorld.java enthalten sein muss:
public class HelloWorld {
public static void main ( String [] args ) {
// Gibt die Zahl 42 aus
System . out . println (42) ;
}
}
In der ersten Zeile des Programms wird eine Klasse HelloWorld definiert, welche eine Methode main enthält, die als Einsprungspunkt dient. Die genaue Bedeutung der verschiedenen
Deklarationen wird im Abschnitt über objektorientierte Programmierung erklärt. Hier ist
zunächst relevant, dass die einzige Anweisung System.out.println(42) die Zahl 42 ausgibt
und wie jede Anweisung in Java mit einem Semikolon endet. In der Zeile darüber wird mit //
ein für den Programmfluss irrelevanter Kommentar eingeleitet. Mehrzeile Kommentare werden
mit /* begonnen und mit */ beendet.
Java ist eine typisierte Sprache. Das bedeutet, dass jeder Ausdruck einen definierten Typ
besitzt. Im obigen Beispiel ist die Zahl 42 vom primitiven Datentyp int, welcher im Speicher
durch 32 Bits repräsentiert wird und ganze Zahlen im Bereich von -2147483648 bis 2147483647
aufnehmen kann. Andere primitive Typen repräsentieren Gleitkommazahlen (float und
double), einzelne Zeichen aus dem Unicode-Alphabet (char) [Unicode] oder Wahrheitswerte
(boolean). byte, short und long nehmen ebenso wie int ganze Zahlen auf, werden aber intern
durch 8, 16 bzw. 64 Bits repräsentiert, aufgrund dessen sie unterschiedliche Zahlenbereiche
enthalten können.
Zum Speichern von Werten eines bestimmten Typs werden Variablen benutzt. So deklariert
das folgende Beispiel eine Variable mit dem Namen i vom Typ int. Eine Variable kann überall
dort eingesetzt werden, wo auch die literarische Form einer Zahl vom Typ int gültig ist. Initial
steht i für den Wert 0. Durch die Zuweisung kann der Wert allerdings jederzeit geändert
werden.
int i ;
i = 45 - 3;
60
Relevante Grundlagen aus der Informatik
Im letzten Beispiel wurde der Variablen i der Wert 42 zugewiesen. Dieser wurde jedoch nicht
direkt eingegeben, sondern mit Hilfe eines Operators aus zwei Literalen berechnet. Java stellt
neben den üblichen arithmetischen Operatoren +, -, * und / viele weitere Operatoren z.B. für
Vergleiche und boolesche Operationen, Zugriff auf zusammengesetzte Datentypen wie Arrays
und Klassen sowie Operatoren für Bitoperationen zur Verfügung. Die Operatoren besitzen
unterschiedliche Prioritäten. Wie bei den Grundrechenarten üblich, kann eine Änderung durch
Setzen von Klammern erreicht werden.
Zur Strukturierung eines Java-Programms können Methoden definiert und aufgerufen werden,
die bestimmte Funktionalität kapseln und optional einen Rückgabewert besitzen können.
Die Angabe eines Rückgabewertes erlaubt es, einen Methodenaufruf dort zu verwenden, wo
ein Wert dieses Typs erwartet wird. Ein fehlender Rückgabewert wird durch Angabe des
Schlüsselwortes void angezeigt:
public class MethodExample {
public static double pi () {
return 3.14159;
}
public static void print ( double arg ) {
System . out . println ( arg ) ;
}
public static void main ( String [] args ) {
print ( pi () ) ;
}
}
Verschiedene Kontrollstrukturen erlauben die Implementierung der eigentlichen Programmlogik.
Java stellt unter anderem Bedingungen (if . . . else, switch . . . case) bereit, die abhängig
vom Wahrheitswert eines Ausdrucks das Programm verzweigen. while, do . . . while und
for-Schleifen erlauben die wiederholte Ausführung von Programmteilen:
// Alle geraden Zahlen von 0 bis 8 ausgeben
int i = 0;
while ( i < 10) {
if ( i %2 == 0) System . out . println ( i ) ;
i ++; // wie i = i +1
}
// Dasselbe mit einer for - Schleife
for ( int i =0; i <10; i ++) {
if ( i %2 == 0) System . out . println ( i ) ;
}
Java
61
Als kleiner Vorgriff auf die im nächsten Kapitel eingeführten Referenztypen werden an dieser
Stelle Arrays (Datenfelder) vorgestellt. Sie dienen dazu, mehrere Elemente eines Typs innerhalb
einer Variablen zu speichern. Der Zugriff erfolgt mit Hilfe des []-Operators. Mit Hilfe einer foroder for/in-Schleife kann man über den Inhalt eines Arrays iterieren. Die for/in-Schleife
weist der Variablen entry bei jedem Durchlauf ein neues Element aus dem Array zu. Dadurch
ist das Programm zwar kürzer, man hat andererseits aber keinen Zugriff auf die Zählvariable.
int a [] = { 0 , 2 , 4 , 6 , 8 };
for ( int i =0; i <10; i ++) System . out . println ( a [ i ]) ;
for ( int entry : a ) System . out . println ( entry ) ;
3.2.3 Objektorientierte Programmierung mit Java
Java ist eine durchgehend objektorientierte Sprache. Was dies genau bedeutet, wird in diesem Abschnitt erklärt. Als Eingangsmotivation dient ein kleines Beispiel: Zur Speicherung
der persönlichen Daten von vielen Personen ist es nicht sehr praktisch, jeweils die Namen,
Adressen, Telefonnummern usw. in einzelnen Arrays zu speichern. Beispielsweise müssen bei
der Entfernung einer Person alle Arrays durchlaufen werden, um das die Person betreffende
Element zu entfernen und alle nachfolgenden Elemente nach vorne zu schieben. Effizienter
ist es, einen eigenen Typ Person zu definieren, der einfachen Zugriff auf die Eigenschaften
ermöglicht. Nichts anderes erlaubt eine Klasse in Java, wobei der hier verwendete Datentyp
String eine Zeichenkette beinhalten kann.
public class Person {
public String name ;
public String address ;
}
Die Definition eines eigenen Typs Person bietet darüber hinaus noch weitere Vorteile. So
können Methoden definiert werden, die nur Argumente vom Typ Person erlauben oder
zurückgeben. Dies wird im allgemeinen als Typsicherheit bezeichnet. Die Erzeugung einer sog.
Instanz von der Klasse Person erfolgt mit Hilfe des Schlüsselwortes new. Beim Zugriff werden
der Variablenname und das sog. Attribut der Instanz durch einen Punkt getrennt:
Person p = new Person () ;
p . name = " Harry Potter " ;
p . address = " Hogwarts School of Witchcraft and Wizardry " ;
Das Schlüsselwort public vor den Attributen in der Definition der Klasse Person erlaubt
den Zugriff auf die Attribute von außerhalb der Klasse. Weitere Zugriffsspezifizierer sind
62
Relevante Grundlagen aus der Informatik
protected und private, die einen Zugriff nur innerhalb der Klasse und sog. abgeleiteter
Klassen bzw. nur innerhalb der Klasse erlauben. Dies ist bei Attributen sinnvoll, um eine
Kapselung der Funktionalität zu erreichen. So ist es möglich, die Schnittstelle für die Benutzer
einer Klasse stabil zu halten und gleichzeitig die Implementierung zu ändern. Ein Beispiel
wäre, die Informationen zu einer Person im Nachhinein statt in der Instanz zu speichern, in
eine Datenbank abzulegen und bei Bedarf zu laden. Im einfachsten Fall werden die Werte
einfach durchgereicht, wobei jede der definierten sog. Methoden auf die jeweiligen Attribute
der Instanz zugreift, auf der sie aufgerufen wird:
public class Person {
private String name ;
public String getName () { return name ; }
public String setName ( String newName ) { name = newName ; }
...
}
Der Aufruf von Methoden auf einer Instanz funktioniert ähnlich wie die Benutzung von
Attributen:
Person p = new Person () ;
p . setName ( " Harry Potter " ) ;
System . out . println ( p . getName () ) ;
Statische Attribute erlauben es, Information nicht pro Instanz, sondern nur einmalig pro Klasse
zu speichern. So ist es beispielsweise möglich, einen Zähler für die Anzahl der gespeicherten
Personen anzulegen. Eine spezielle Methode, die den Namen der Klasse trägt, wird immer
beim Anlegen einer Instanz mit new ausgeführt. In diesem sog. Konstruktor kann der Zähler
inkrementiert werden (der Einfachheit halber als public deklariert):
public class Person {
public static int counter = 0;
public Person () { counter ++; }
...
}
Allerdings stellt uns diese Lösung vor eine Herausforderung. Zwar bietet Java die Möglichkeit,
eine Instanz explizit mit new anzulegen, eine Löschoperation gibt es aber nicht. Dies liegt
daran, dass in der JVM im Hintergrund eine automatische Speicherbereinigung (Garbage
Collection) läuft, die nicht mehr referenzierten Speicher wieder freigibt. Dies tritt z. B. auf,
Java
63
wenn nach dem Anlegen einer Instanz die einzige Variablen, der diese Instanz bekannt ist, auf
den speziellen Wert null zurückgesetzt wird:
Person p = new Person () ;
p = null ;
Das eigentliche Problem besteht darin, dass diese automatische Speicherbereinigung asynchron
geschieht, es also nicht definiert ist, wann die JVM den Speicher wieder freigibt. So kann
der obige Zähler für diesen Fall nicht sinnvoll implementiert werden. Eine alternative Implementierung benutzt einen explizit definierten PersonManager mit expliziter Registrierung der
Instanzen. Im Beispiel findet sich mit ArrayList<Person> eine Arraytyp mit dynamischer
Größe, der in der Java-Standardbibliothek (als sog. generischer Typ) enthalten ist.
import java . util . ArrayList ;
public class PersonManager {
private ArrayList < Person > people ;
public void addPerson ( Person p ) { people . add ( p ) ; }
public void removePerson ( Person p ) { people . remove ( p ) ; }
public int getCount () { return people . size () ; }
}
Zum Abschluss dieses Abschnitts werden zwei Techniken angesprochen, die es erlauben,
einmal definierte Typen zu erweitern. Mit Hilfe von Vererbung ist es möglich, eine ist-einBeziehung zwischen zwei Typen herzustellen. Dabei hat eine Klasse genau eine sog. Basisklasse.
Implizit hat jede Klasse die Basisklasse Object. Es ist so z. B. möglich, eine Klasse Employee zu
definieren, die alle Eigenschaften von Person erbt und als Spezialisierung weitere Eigenschaften
definieren kann:
public class Employee extends Person {
private double salary ;
public double getSalary () { return salary ; }
public void setSalary ( double newSalary ) { salary = newSalary ; }
}
Überall, wo eine Person erwartet wird, kann man nun eine Instanz von Employee einsetzen:
Person p = new Employee () ;
Eine sehr mächtige Möglichkeit der Erweiterung von Typen bieten Schnittstellen (Interfaces).
Vererbungen modellieren eine Beziehung zwischen realen oder abstrakten Entitäten, wohingegen
Schnittstellen häufig eingesetzt werden, um gemeinsames Verhalten auch nicht verwandter
64
Relevante Grundlagen aus der Informatik
Entitäten zu definieren. Eine Klasse kann darüber hinaus nur von einer Basisklasse ableiten,
aber beliebig viele Schnittstellen implementieren. Durch die Implementierung der Schnittstelle
Comparable durch die Klasse Person ist es z. B. möglich, mit in der Java-Standardbibliothek
vorhandenen Algorithmen eine Menge von Person-Instanzen sortieren zu lassen.
public class Person implements Comparable < Person > {
public int compareTo ( Person arg0 ) {
return name . compareTo ( arg0 . name ) ;
}
...
}
Eigene Schnittstellen lassen sich mit Hilfe des Schlüsselwortes interface anstelle von class
definieren, wobei aber im Vergleich zu einer Klasse Einschränkungen bestehen. Beispielsweise
können Schnittstellen keine veränderbaren Attribute enthalten.
Für die Anzeige von Fehlersituationen können Ausnahmen (Exceptions) erzeugt werden. Falls
eine Ausnahme nicht abgefangen wird, führt sie zum Abbruch des laufenden Programms. Zum
Abfangen kommt ein try..catch-Block zum Einsatz. Häufiger Einsatzbereich von Ausnahmen
sind Eingabe-Ausgabe-Operationen, bei denen entsprechend auf Fehler reagiert werden muss
(z. B. falls kein freier Speicherplatz auf dem Datenträger verfügbar ist). Im Beispiel wird aus
einer Zeichenkette ein int-Wert, also eine Zahl, erzeugt. Falls die Zeichenkette keine gültige
Zahl darstellt, wird eine NumberFormatException ausgelöst, auf die reagiert werden kann. In
diesem Fall wird hier bspw. ein Standardwert für die Zahl angenommen.
int i ;
try {
i = Integer . parseInt ( " 5 " ) ;
} catch ( N u m b e r F o r m a t E x c e p t io n e ) {
i = 42;
}
3.2.4 Programmierung grafischer Oberflächen mit Swing
Die bislang vorgestellten Beispielprogramme besitzen keine grafische Oberfläche, sondern
arbeiten auf der Kommandozeile, geben also auch nur dort Informationen aus. Grafische
Oberflächen ermöglichen eine wesentlich intuitivere und interaktive Steuerung von Programmen.
Eine Möglichkeit zur Erstellung von grafischen Oberflächen bietet die im JDK enthaltene SwingBibliothek [Swing]. Swing ist ebenso wie die restlichen Teile des JDK plattformunabhängig,
Java
65
so dass das Programm auf jedem Betriebssystem gleich aussieht und sich gleich verhält. Das
folgende Beispielprogramm zeigt ein Fenster mit einer Textnachricht an. Beim Schließen des
Fensters wird das Programm beendet.
import javax . swing .*;
public class HelloWorldSwing {
public static void main ( String [] args ) {
// Legt ein neues Fenster an
JFrame frame = new JFrame ( " Hello , World ! " ) ;
frame . s e t D e f a u l t C l o s e O p e r a t i o n ( JFrame . EXIT_ON_CLOSE ) ;
// Hinzufügen einer Textanzeige
JLabel label = new JLabel ( " Hello , World ! " ) ;
frame . getContentPane () . add ( label ) ;
// Anzeigen des Fensters
frame . setSize (300 , 200) ;
frame . setVisible ( true ) ;
}
}
Die Swing-Bibliothek arbeitet ereignisorientiert. Das bedeutet, dass durch die Aktion des
Benutzers Ereignisse ausgelöst werden, die dann vom Programm verarbeitet werden. Dementsprechend gestaltet sich die Programmierung von Swing-Anwendungen. Meistens implementiert
man bestimmte Methoden in Schnittstellen oder leitet von Klassen ab, die dann im System
registriert werden und beim Auslösen des passenden Ereignisses aufgerufen werden. Dies
wird im nächsten Beispiel verdeutlicht, das eine Schaltfläche enthält, die beim Drücken das
Programm beendet:
import java . awt . event .*;
import javax . swing .*;
public class ButtonExample implements ActionListener {
public ButtonExample () {
// Legt ein neues Fenster an
JFrame frame = new JFrame ( " Hello , World ! " ) ;
frame . s e t D e f a u l t C l o s e O p e r a t i o n ( JFrame . EXIT_ON_CLOSE ) ;
// Hinzufügen eines Knopfes zum Beenden
JButton quitButton = new JButton ( " Quit " ) ;
66
Relevante Grundlagen aus der Informatik
Abbildung 3.3: Swing-Beispielprogramm
frame . getContentPane () . add ( quitButton ) ;
quitButton . addAc tionLi stener ( this ) ;
// Anzeigen des Fensters
frame . setSize (100 , 50) ;
frame . setVisible ( true ) ;
}
public void actionPerformed ( ActionEvent event ) {
System . exit (0) ;
}
public static void main ( String [] args ) {
new ButtonExample () ;
}
}
Hierbei implementiert die ButtonExample-Klasse die ActionListener-Schnittstelle. Die in
der Schnittstelle deklarierte actionPerformed-Methode wird von der Swing-Bibliothek immer
dann auf der registrierten Instanz aufgerufen, wenn der Knopf vom Benutzer gedrückt wurde.
In ähnlicher Weise lassen sich auch Menüs realisieren (siehe Abbildung 3.3). Hier wird der
ActionListener statt bei einer Schaltfläche bei einem Menüeintrag registiert, der die Aktion
auslöst, wenn er aktiviert wird.
import java . awt . event .*;
import javax . swing .*;
public class MenuExample implements ActionListener {
public MenuExample () {
// Legt ein neues Fenster an
JFrame frame = new JFrame ( " Hello , World ! " ) ;
Java
67
frame . s e t D e f a u l t C l o s e O p e r a t i o n ( JFrame . EXIT_ON_CLOSE ) ;
// Hinzufügen eines Menüs
JMenuBar menuBar = new JMenuBar () ;
JMenu actionsMenu = new JMenu ( " Actions " ) ;
menuBar . add ( actionsMenu ) ;
frame . setJMenuBar ( menuBar ) ;
// Hinzufügen eines Menüeintrags
JMenuItem quitItem = new JMenuItem ( " Quit " ) ;
quitItem . addA ctionL istene r ( this ) ;
actionsMenu . add ( quitItem ) ;
// Anzeigen des Fensters
frame . setSize (300 , 200) ;
frame . setVisible ( true ) ;
}
public void actionPerformed ( ActionEvent event ) {
System . exit (0) ;
}
public static void main ( String [] args ) {
new MenuExample () ;
}
}
3.2.5 JOGL
Für die Darstellung von Partituren verwendet die im Rahmen der Diplomarbeit entwickelte
Software den ScoreViewer aus dem SyncPlayer-Framework [Kurth et al. 2005; Fremerey 2006].
Für die Visualisierung benutzt dieser die JOGL-Bibliothek [JOGL], mit dessen Hilfe von Java
aus auf OpenGL-Funktionen [OpenGL] zugegriffen werden kann. Das ScoreViewer-Plugin
wurde für das während der Arbeit entstandene Programm um zusätzliche Funktionen erweitert.
Daher wird kurz auf die in diesem Zusammenhang verwendete JOGL-Bibliothek eingegangen.
JOGL ermöglicht die Nutzung von OpenGL-Funktionalität innerhalb von Java-Programmen.
OpenGL ist primär eine Bibliothek zum Erzeugen von 3D-Grafikanwendungen, deren Darstellungen auf spezieller Grafik-Hardware beschleunigt berechnet werden können. Die dabei
verwendeten Techniken wie Texturierung sind aber auch für 2D-Anwendungen interessant,
und kommen daher in diesem Bereich immer häufiger zum Einsatz. Die populärsten Beispiele
68
Relevante Grundlagen aus der Informatik
hierfür sind die Desktops von Windows Vista und Mac OS X. Der ScoreViewer verwendet
OpenGL-Funktionen für die Darstellung von Bildern von Partituren. Mit Hilfe der TexturFunktionen von OpenGL können auf einfache Weise skalierbare Darstellungen dieser Bilder
erzeugt werden. Mit geringem Aufwand können darüber hinaus auch transparente Objekte
für Hervorherbungen bestimmter Bereiche dargestellt werden. OpenGL übernimmt dabei die
Berechnungen für die Transparenz.
OpenGL und JOGL sind umfangreiche Bibliotheken, auf die an dieser Stelle nur sehr oberflächlich eingegangen werden kann. Für ein grundlegendes Verständnis der Funktionsweise
wird im Folgenden ein minimales JOGL-Programm vorgestellt, welches ein buntes Dreieck auf
hellblauem Hintergrund zeichnet. Da das Beispiel deutlich umfangreicher als die bisherigen
ist, wird auf einzelne Ausschnitte eingegangen, anstatt das Programm direkt vollständig
aufzulisten.
Das HelloWorldJOGL-Programm beginnt mit den nötigen import-Anweisungen für Swing
und JOGL. Die Klasse ist von einem Swing-Fenster abgeleitet und setzt im Konstruktor
ein paar Einstellungen. Schließlich wird eine Methode aufgerufen, die grundlegende JOGLInitialisierungen vornimmt.
import javax . media . opengl .*;
import javax . swing .*;
public class HelloWorldJOGL extends JFrame
implements GLEventListener {
public HelloWorldJOGL () {
super ( " Hello , World with JOGL ! " ) ;
setSize (300 , 300) ;
s e t D e f a u l t C l o s e O p e r a t i o n ( JFrame . EXIT_ON_CLOSE ) ;
initJOGL () ;
}
In der JOGL-Initialisierungsmethode wird ein GLCapabilities-Objekt angelegt, mit dem Einstellungen für den OpenGL-Rendering-Kontext vorgenommen werden können. Im Beispiel wird
hier nur die Hardware-Beschleunigung aktiviert. Das erzeugte Objekt wird danach zur Konfiguration an einen GLCanvas übergeben, welcher die Zeichenfläche für die OpenGL-Darstellung
repräsentiert. Für bestimmte Ereignisse wird hier die Klasse selbst für die Ereignisbehandlung
registiert. Dafür implementiert sie die Schnittstelle GLEventListener. In dieser ist bspw.
eine Funktion display deklariert, welche aufgerufen wird, wenn neu gezeichnet werden muss.
Schließlich wird die Zeichenfläche zum Swing-Fenster hinzugefügt.
Java
69
public void initJOGL () {
GLCapabilities caps = new GLCapabilities () ;
caps . s e t H a r d w a r e A c c e l e r a t e d ( true ) ;
GLCanvas canvas = new GLCanvas ( caps ) ;
canvas . add GL Ev en tL is te ner ( this ) ;
getContentPane () . add ( canvas ) ;
}
Als erste Methode aus der GLEventListener-Schnittstelle wird beim Erzeugen des Fensters
die init-Methode aufgerufen. Dort werden für die folgenden OpenGL-Zeichenbefehle die
Hintergrundfarbe und die Projektionsmatrix festgelegt. Hier wird eine orthogonale Projektion
festgelegt, was einem 2D-Zeichenbereich mit Layern entspricht. Dabei reichen die Koordinaten
für (x,y,z) im sichtbaren Bereich von (0,0,-1) bis (1,1,1). Weitere Informationen hierzu und
zu weiteren Details der OpenGL-Programmierung finden sich in [Shreiner et al. 2007].
public void init ( GLAutoDrawable drawable ) {
GL gl = drawable . getGL () ;
gl . glClearColor (0.8 f , 0.8 f , 1.0 f , 0) ;
gl . glMatrixMode ( GL . GL_PROJECTION ) ;
gl . glLoadIdentity () ;
gl . glOrtho (0 , 1 , 0 , 1 , -1 , 1) ;
}
Die Methoden reshape und displayChanged werden aufgerufen, um auf Fenstergrößenänderungen bzw. auf Änderungen in den OpenGL-Einstellungen für die Zeichenfläche reagieren zu
können. Im Beispiel ist dies nicht notwendig, so dass die Implementierungen leer sind.
public void reshape ( GLAutoDrawable drawable , int x , int y , int w ,
int h ) {
}
public void displayChanged ( GLAutoDrawable drawable , boolean
modeChanged , boolean deviceChanged ) {
}
Die eigentlich Arbeit geschieht in der display-Methode. Sie wird immer aufgerufen, wenn
der Zeichenbereich erneuert werden muss, bspw. wenn das Fenster minimiert oder verdeckt
wurde und jetzt wieder sichtbar wird. Nachdem zu Beginn der entsprechende Kontext zum
Absetzen von OpenGL-Befehlen geholt wurde, wird das Fenster zunächst gelöscht. Das folgende
70
Relevante Grundlagen aus der Informatik
Kommando legt fest, dass darauf folgende Koordinaten jeweils in Tripeln zu Dreiecken gehören,
die entsprechend gezeichnet werden. OpenGL ist eine Zustandsmaschine, die Einstellungen
immer bis zu einer Änderung beibehält. So legen die glColor3f-Aufrufe die Zeichenfarbe bis
zur nächsten Änderung fest. Die glVertex3f-Aufrufe erzeugen dann schließlich die Eckpunkte
eines Dreiecks, die in der jeweils aktuellen Farbe gezeichnet werden. Abgeschlossen werden die
Zeichenbefehle mit glEnd(). Der glFlush-Aufruf am Ende sorgt dafür, dass alle Kommandos
sofort ausgeführt werden, und kehrt erst danach zurück.
public void display ( GLAutoDrawable drawable ) {
GL gl = drawable . getGL () ;
gl . glClear ( GL . G L_ C O LO R _ BU F F ER _ B IT ) ;
gl . glBegin ( GL . GL_TRIANGLES ) ;
gl . glColor3f (1 , 0 , 0) ;
gl . glVertex3f (0.25 f , 0.25 f , 0) ;
gl . glColor3f (0 , 1 , 0) ;
gl . glVertex3f (0.75 f , 0.25 f , 0) ;
gl . glColor3f (0 , 0 , 1) ;
gl . glVertex3f (0.25 f , 0.75 f , 0) ;
gl . glEnd () ;
gl . glFlush () ;
}
In der main-Methode wird das HelloWorldJOGL-Fenster erzeugt und sichtbar gemacht. Wie
auch in den vorherigen Beispielen beendet sich das Programm beim Schließen des Fensters.
Das Ergebnis des JOGL-Beispiels ist in Abbildung 3.4 dargestellt.
public static void main ( String [] args ) {
new HelloWorldJOGL () . setVisible ( true ) ;
}
}
JOGL bietet auch über reine OpenGL-Funktionalität hinaus gehende Möglichkeiten. Dazu
zählen bspw. Fähigkeiten zur Textdarstellung innerhalb von OpenGL-Zeichenbereichen. Diese
Funktionalität wird ebenfalls vom ScoreViewer und auch bei der im Rahmen der Arbeit
entwickelten Erweiterung benutzt. Auf eine detaillierte Beschreibung wird aber hier aus
Platzgründen verzichtet. Informationen hierzu finden sich in [JOGL].
Java
71
Abbildung 3.4: JOGL-Beispielprogramm
3.2.6 JDBC
JDBC (Java Database Connectivity) [JDBC] ist eine Bibliothek zur Abfrage und Veränderung
von tabellarischen Daten. Häufigstes Einsatzgebiet ist die Kommunikation mit relationalen Datenbanken. JDBC besteht aus mehreren Teilen. Die JDBC-Programmierschnittstelle
stellt Klassen und Methoden bereit, um von Java aus auf relationale Datenstrukturen zuzugreifen. Somit können SQL-Anfragen auf einer relationalen Datenbank ausgeführt werden
und die Ergebnisse direkt in Java verarbeitet werden. Ein weiterer Teil von JDBC ist der
Driver Manager, der sich um das Laden und die Benutzung von Treibern für unterschiedliche Datenbanken kümmert. An dieser Stelle können sowohl plattformabhängige als auch
plattformunabhängige Treiber zum Einsatz kommen. Falls für die benutzte Datenbank kein
spezieller JDBC-Treiber verfügbar ist, kann eine JDBC-ODBC-Brücke benutzt werden, die
JDBC-Befehle auf ODBC-Befehle abbildet. ODBC (Open Database Connectivity) ist eine
standardisierte Datenbankschnittstelle, die auf vielen Plattformen und für viele Datenbanken
verfügbar ist.
Ein JDBC-Programm beginnt mit dem nötigen import-Befehl für java.sql.*. Als erste
Anweisung wird dann der Datenbanktreiber geladen. Im Beispiel wird über die ODBCBrücke eine Verbindung zu einer Microsoft Access-Datenbank hergestellt, die vorher über das
ODBC-Konfigurationsprogramm auf den Namen testdb gebunden wurde. Die Class.forNameAnweisung lädt den JDBC-ODBC-Treiber. Danach wird über den Driver Manager eine
Verbindung hergestellt, auf die später über die Variable connection zugegriffen werden
kann.
72
Relevante Grundlagen aus der Informatik
import java . sql .*;
public class HelloWorldJDBC {
private static Connection connection = null ;
public static void initConnection () throws ClassNotFoundException ,
SQLException {
Class . forName ( " sun . jdbc . odbc . JdbcOdbcDriver " ) ;
connection = DriverManager . getConnection ( " jdbc : odbc : testdb " ) ;
}
Zum Anlegen einer Tabelle wird zunächst mit createStatement ein Statement-Objekt erzeugt.
Diesem kann dann ein SQL-Befehl als Zeichenkette zur Ausführung übergeben werden. Falls
während der Ausführung ein Fehler auftritt (z. B. Verbindung wurde beendet, Tabelle existiert
bereits), wird eine SQLException-Ausnahme erzeugt, die zum Abbruch des Programms führt.
public static void createTable () throws SQLException {
Statement stmt = connection . createStatement () ;
String str = " CREATE TABLE Staedte ( name VARCHAR (80) ) " ;
stmt . execute ( str ) ;
}
In ähnlicher Weise können auch Daten in die soeben erzeugte Tabelle eingetragen werden. Hier
wird über eine gegebene Liste von Städtenamen iteriert, die mit einzelnen INSERT-SQL-Befehlen
in die Tabelle geschrieben werden.
public static void insertData () throws SQLException {
String [] cities = { " Rom " , " Paris " , " London " , " Berlin " };
for ( String c : cities ) {
Statement stmt = connection . createStatement () ;
String str =
" INSERT INTO Staedte ( name ) VALUES ( ’ " + c + " ’) " ;
stmt . execute ( str ) ;
}
}
Zum Abfragen von Daten gibt es zwei Möglichkeiten. Zunächst wird die einfachste vorgestellt,
die mit festen SQL-Befehlen arbeitet. Wie oben wird auch hier ein Statement-Objekt erzeugt.
Allerdings wird der SQL-Befehl nun mit executeQuery ausgeführt, welches ein Ergebnisobjekt
Java
73
zurückliefert. Auf diesem können nun die Ergebnisse der Anfrage ausgelesen werden. Hier
werden sie dann auf der Konsole ausgegeben.
public static void queryData () throws SQLException {
Statement stmt = connection . createStatement () ;
String str = " SELECT * FROM Staedte " ;
ResultSet rs = stmt . executeQuery ( str ) ;
while ( rs . next () ) {
String name = ( String ) rs . getObject ( " name " ) ;
System . out . println ( name ) ;
}
}
Die zweite Variante zum Ausführen von SQL-Anfragen arbeitet mit einem sog. PreparedStatement. Hierbei können SQL-Anfragen mit Platzhaltern einmalig angelegt werden und
später mit Daten befüllt und dann ausgeführt werden. Dies hat den Vorteil, dass die SQLAnfrage nicht jedes Mal neu aus der Zeichenkette eingelesen werden muss. In initPrepared
wird im Beispiel eine einmalige Vorbereitung durchgeführt. Mit Hilfe der queryPreparedMethode können dann später Abfragen durchgeführt werden, die den Platzhalter (?) mit
einem Wert belegen.
private static P repare dState ment p repare dState ment = null ;
public static void initPrepared () throws SQLException {
String str = " SELECT * FROM Staedte WHERE name =? " ;
prep aredSt ateme nt = connection . prepareStatement ( str ) ;
}
public static void queryPrepared () throws SQLException {
prep aredSt ateme nt . setString (1 , " Rom " ) ;
ResultSet rs = prepa redSta tement . executeQuery () ;
while ( rs . next () ) {
String name = ( String ) rs . getObject ( " name " ) ;
System . out . println ( name ) ;
}
}
Zum Löschen der Tabelle kann die dropTable-Methode benutzt werden, die ähnlich wie
die createTable-Methode arbeitet. Auch hier wird zunächst mit createStatement ein
Statement-Objekt erzeugt, mit dessen Hilfe dann eine DROP TABLE-SQL-Anweisung an das
DBMS gesendet wird.
74
Relevante Grundlagen aus der Informatik
public static void dropTable () throws SQLException {
Statement stmt = connection . createStatement () ;
String str = " DROP TABLE Staedte " ;
stmt . execute ( str ) ;
}
In der main-Methode werden alle vorgestellten Methoden aufgerufen. Zunächst wird eine
evtl. schon vorhandene Tabelle gelöscht. Hierbei wird eine SQLException abgefangen und
unterdrückt, die bspw. auftritt, falls die Tabelle noch nicht existiert. Danach wird die Tabelle
erzeugt, Daten hineingeschrieben und danach abgefragt.
public static void main ( String [] args ) throws Exception {
initConnection () ;
try {
dropTable () ;
} catch ( SQLException e ) {
}
createTable () ;
insertData () ;
queryData () ;
initPrepared () ;
queryPrepared () ;
}
}
4 Partiturdarstellung im relationalen
Datenmodell
Im Rahmen dieser Arbeit wurde ein Werkzeug zur Unterstützung der harmonischen Analyse
von Musikwerken entwickelt, welches einige zeitintensive und aufwendige Arbeitsschritte automatisieren kann. Den diesbezüglich arbeitsintensivsten aber gleichzeitig auch grundlegendsten
Teil stellt die Akkordbestimmung mit der zugehörigen strukturellen Akkorduntersuchung dar.
Darauf aufbauend lässt sich schließlich die Funktionsbestimmung der Akkorde durchführen.
Den Kern des Analysesystems bildet eine ScoreStore genannte relationale Datenbank, in der alle
für die harmonische Analyse benötigten Informationen abgelegt werden. Dazu zählen primär
die Partiturinformationen der betrachteten Musikwerke. Zur Durchführung der Analyse werden
darüber hinaus auch musiktheoretische Grundlagen in Form von Grundparametern wie Note,
Intervall usw. benötigt, die ebenfalls im relationalen Datenmodell repräsentiert werden. Darauf
aufbauend lassen sich schließlich mit Hilfe der Datenbanksprache SQL Fragestellungen bzgl.
harmonischer Eigenschaften an das DBMS formulieren. Weitere Teile des Analysesystems sind
eine interaktive grafische Oberfläche sowie eine Komponente zum einfachen Konvertieren und
Einfügen von Partiturdaten in die Datenbank. Diese werden in einem Kapitel 6 vorgestellt.
In diesem Kapitel wird detailliert auf die Kernkomponente des Analysesystems, die ScoreStore-Datenbank, eingegangen. Nach einer Motivation bzgl. der Benutzung von relationalen
Datenbanken für die harmonische Analyse folgt eine konzeptuelle Darstellung von Musikinformationen mit Hilfe eines ER-Diagramms. Im folgenden Abschnitt werden die Vorteile der
zur Umsetzung gewählten Technologie vorgestellt und diskutiert. Den Hauptteil des Kapitels
bildet die Präsentation der Datenmodellierung. Dabei wird zunächst auf die Abbildung der
Partituren auf relationale Datenbanken eingegangen, bevor schließlich die Modellierung der
zur harmonischen Analyse benötigten musiktheoretischen Grundlagen vorgestellt wird.
75
76
Partiturdarstellung im relationalen Datenmodell
4.1 Motivation
Die Benutzung relationaler Datenbanken im Bereich Musik beschränkt sich weitgehend auf die
Speicherung von Metadaten wie z. B. Titel, Komponist oder Interpret von Musikwerken. Die
Notendarstellung der eigentlichen Musikinformationen ist nur indirekt vorhanden. Beispiele
hierfür sind die Speicherung von Audioinformationen im MIDI- oder MP3-Format sowie
bildlicher Darstellungen von Partituren. Häufig werden noch nicht einmal die Dateien selbst
in der Datenbank abgelegt, sondern nur Verweise auf sie gespeichert.
Auch existierende Systeme zur harmonischen Analyse benutzen keine relationalen Datenbanken zur Speicherung von Partituren und zur Durchführung der Untersuchungen. Stattdessen
kommen eigene Notationsformate und Implementierungen für die Verwaltung der Musikinformationen zur Laufzeit zum Einsatz. Dabei besitzt eine relationale Darstellung viele Vorteile,
auf die im Folgenden eingegangen wird.
Ein grundsätzlicher Vorteil der Speicherung von Informationen in einer relationalen Datenbank
besteht darin, dass existierende Beziehungen zwischen Entitäten in natürlicher Weise modelliert
werden können. In der Musik betrifft dies z. B. die Beziehungen zwischen Intervallen und Noten.
So lässt sich die Intervallbeziehung, zu der immer genau zwei Noten gehören, sehr gut durch
eine Relation ausdrücken. Weiter gehende Charakterisierungen bspw. einer einzelnen Note
können durch zusätzliche Attribute und Verknüpfungen zu anderen Entitäten repräsentiert
werden. Die Modellierung geschieht nur auf logischer Ebene, so dass von der tatsächlichen
Implementierung abstrahiert wird.
Die Abstraktion betrifft insbesondere die Unabhängigkeit von der verwendeten Datenbank bzw.
dem DBMS. Die Realisierung des Schemas erfolgt mit Hilfe der Datenbanksprache SQL. Da
diese standardisiert ist und von jedem DBMS verstanden wird, ist auch die hier beschriebene
Umsetzung grundsätzlich unabhängig von einem konkreten DBMS. Im Gegensatz zu einer
objektorientierten Modellierung erlaubt SQL darüber hinaus das direkte Arbeiten mit den
gespeicherten Informationen, ohne dass z. B. die Auseinandersetzung mit Datenstrukturen
notwendig ist. Im direkten Vergleich zur imperativen Programmierung wird mit SQL eine
Lösung deklarativ spezifiziert, anstatt den Lösungsweg zu beschreiben. SQL erlaubt es somit,
sich auf die inhaltlichen Zusammenhänge einer Anfrage zu konzentrieren, da die technische
Realisierung nicht von zentraler Bedeutung ist. Anfragen können als SQL-Sichten (Views)
gespeichert werden. In anderen Anfragen können diese später wiederverwendet werden, in
denen die Views transparent alternative Sichten auf die vorhandenen Daten ermöglichen. Diese
Arbeitsweise ist ähnlich wie in Humdrum (siehe 2.4.1), wobei hier allerdings keine explizite
Konvertierung der Daten nötig ist.
Konzeptuelle Modellierung von Musikelementen
77
Die für eine harmonische Analyse benötigten Partiturinformationen lassen sich in natürlicher
Weise mit Hilfe eines relationalen Schemas darstellen. Abgesehen davon bieten Datenbanksysteme weitere Vorteile. So können vom DBMS Optimierungen komplexer Anfragen durchgeführt
werden, um Anfragen auch auf großen Datenbeständen effizient auswerten zu können.
Durch die weite Verbreitung relationaler Datenbanken sind darüber hinaus gute Anbindungsmöglichkeiten für externe Anwendungen vorhanden. Davon macht auch das im Rahmen
dieser Arbeit entwickelte Analysewerkzeug Gebrauch. Ebenso denkbar sind Erweiterungen des
Datenschemas und die Definition eigener Sichten durch Benutzer des Analysesystems.
4.2 Konzeptuelle Modellierung von Musikelementen für die
harmonische Analyse
In dieser Arbeit soll mit Hilfe von relationalen Datenbanken eine harmonische Analyse
musikalischer Werke durchgeführt werden. Dabei ist als erstes die Bestimmung von Akkorden
erforderlich, um in einem weiteren Schritt schließlich die Beziehung zwischen den einzelnen
erkannten Harmonien untersuchen zu können. In diesem Abschnitt werden für die spätere
Konkretisierung in der Datenbank zunächst die benötigten Musikinformationen erarbeitet
und mit Hilfe eines ER-Diagramms konzeptuell dargestellt. Hierbei werden grundlegende
Elemente aus der Musik als Entitätstypen modelliert und miteinander in Beziehung gesetzt.
Das ER-Diagramm dient zum besseren Verständnis der im weiteren Verlauf des Kapitels
vorgenommen Realisierung des Datenbankschemas.
Die Grundlage einer harmonischen Analyse bildet das Musikwerk, das die zu untersuchenden
Daten in Form einer Partitur enthält. In der Partitur sind viele verschiedene Informationen
enthalten, anhand derer bspw. eine Wiedergabe des Musikwerkes möglich ist. Eine harmonische
Analyse beschäftigt sich mit dem Bau und Wesen von Akkorden und deren Beziehungen
untereinander, weswegen bei der hier vorgenommenen Modellierung nur die dafür wichtigen
Parameter betrachtet werden. Beispielsweise können Angaben zur Dynamik oder zum Tempo
außer Acht gelassen werden.
Im Folgenden werden die wichtigsten musikalischen Entitätstypen vorgestellt und ihre Beziehungen beschrieben. Dabei werden wie in der Informatik üblich englische Bezeichner verwendet.
Dies vermeidet insbesondere bei den später folgenden SQL-Anfragen uneinheitliche Sprachenverwendung. Aus Konsistenzgründen wird bereits hier Englisch verwendet. Die Übersetzungen
der Begriffe werden jeweils an geeigneter Stelle definiert. Abbildung 4.1 zeigt eine grobe
Übersicht über die vorgestellten Entitätstypen und ihre Beziehungen.
78
Partiturdarstellung im relationalen Datenmodell
Partitur: Alle Partituren werden im Entitätstyp Score zusammengefasst. Diese wird durch die
Eigenschaft CatalogNumber für die Katalognummer eindeutig identifiziert. Desweiteren
können einer Partitur zusätzliche Attribute wie Name des Komponisten, Erscheinungsjahr
usw. zugeordnet werden. Diese Informationen werden hier allerdings nicht vollständig
dargestellt, da sie für eine harmonische Untersuchung nicht von Bedeutung sind. Eine
Partitur besteht aus Noten und Pausen, die im Entitätstyp MusicElement (Musikelement)
zusammengefasst sind. Dies kann durch die Beziehung MusicElementInScore ausgedrückt
werden. Jeder Partitur werden darin zu einem bestimmten Zeitpunkt und für ein Notensysten Musikelemente zugeordnet. Desweiteren wird eine Partitur durch eine oder mehrere
Tonarten bestimmt. Durch die Beziehung KeyInScore zwischen den Entitätstypen Key und
Score mit Angabe des Zeitpunkts (Time) lassen sich alle Tonarten des Musikwerkes festlegen. Für die Strukturierung der Musikelemente wird die Taktart benötigt. Im Entitätstyp
TimeSignature werden alle möglichen Taktarten zusammengefasst. Der Beziehungstyp
TimeSignatureInScore enthält alle verwendeten Taktarten der betrachteten Partitur. Die
Zeitpunkte der Taktartwechsel werden auch hierbei durch ein Beziehungsattribut Time
definiert.
Musikelement: Ein Musikelement wird durch Noten und Pausen spezialisiert. Eine Note wird
eindeutig durch die absolute Tonhöhe und die Tondauer definiert. Die absolute Tonhöhe
entspricht dabei dem tatsächlich erklingenden Ton (z. B. c’ = Note c in der eingestrichenen
Oktave). Der Entitätstyp Note enthält somit alle möglichen Notenentitäten. Die absolute
Tonhöhe wird durch mehrere Attribute definiert, weswegen sie einen eigenen Entitätstypen
AbsolutePitch bildet. Dieser wird durch Attribute für die relative Tonhöhe (RelativePitch,
z. B. cis, d ) und eine Oktave (Octave, d. h. einen bestimmten Oktavbereich wie z. B. die
eingestrichene Oktave) eindeutig bestimmt. Die relative Tonhöhe wird ihrerseits schließlich
durch einen Stammton und ein Vorzeichen spezifiziert. Ein weiteres den melodischen
Verlauf beeinflussendes Element ist die Pause (Rest). Da sie nur einen Moment der Stille
anweist (und daher keine Tonhöhe besitzt), besitzt sie als einziges Attribut nur eine Dauer,
für die eine Stimme bzw. Instrument pausieren soll. Da sowohl Noten als auch Pausen
den Verlauf eines Musikwerkes beeinflussen, werden sie in dem Entitätstyp MusicElement
zusammengefasst. Gemeinsames Attribut ist die Dauer (Duration).
Intervall: Im Entitätsyp Interval sind alle Intervalle zusammengefasst (z. B. kleine Terz).
Ein Intervall wird durch die Attribute DiatonicDistance und ChromaticDistance für die
diatonischen und chromatischen Abstände eindeutig bestimmt. Desweiteren hat jedes
Intervall ein Attribut Name für die Bezeichnung. Jedes Intervall besteht aus genau zwei
Noten, weshalb zwischen Note und Interval eine Beziehung NoteInInterval besteht.
79
Konzeptuelle Modellierung von Musikelementen
Score
1
1
1
*
Scale
1
1
*
Key
*
*
MusicElement
TimeSignature
* Root
Note
1
7
*
Function
Rest
2
1
AbsolutePitch
*
*
7
1
1
1
RelativePitch
Octave
*
Root
*
Chord
Interval
3
Triad
2
Tetrachord
*
*
Abbildung 4.1: Konzeptuelle Darstellung von Musikelementen für die harmonische Analyse
80
Partiturdarstellung im relationalen Datenmodell
Akkord: Das wichtigste Element für die harmonische Analyse ist der Akkord (Chord ), also
ein Zusammenklang von mehr als drei Tönen unterschiedlicher Tonhöhe. Ein Akkord
wird durch unterschiedliche Akkordarten spezialisiert: Ein Dreiklang (Triad ) ist ein Zusammenklang von drei Tönen. Diese Töne stehen jeweils in einer bestimmten Beziehung
zueinander, wodurch ein Dreiklang exakt bestimmt werden kann. Dafür sind die Intervalle
zwischen dem Basston und dem nächsthöheren Ton sowie dem Basston und dem obersten
Ton notwendig. Ein Vierklang (Tetrachord) wird ähnlich wie ein Dreiklang definiert, nur
dass noch eine zusätzliche Note und ein Intervall hinzukommt. Allen Mehrklängen gemeinsam sind die Attribute Geschlecht (Mood ), Stellung (Inversion) und Grundton (Root).
Vollständig definiert werden die Akkorde schließlich durch die enthaltenen Intervalle.
Tonart und Tonleiter: Jede Tonart (Key) lässt sich durch einen Grundton (Root), die Vorzeichnung (KeySignature) und das Geschlecht (Mood ) beschreiben. Zu jeder Tonart
existiert eine Tonleiter (Scale), bestehend aus sieben Tönen, die auf dem Grundton
der Tonart aufgebaut ist. Im Beziehungstyp (RelativePitchInScale) zwischen dem Entitätstypen RelativePitch und Scale mit dem Attribut Stufe (Degree) lassen sich die
einzelnen Tonleitern aufbauen. Der Entitätstyp Scale bildet wieder einen Obertyp, der
durch die Entitätstypen MinorScale und MajorScale für Moll- und Durtonleitern spezialisiert wird (im ER-Diagramm nicht dargestellt).
Funktion: Die einzelnen Stufen einer Tonleiter haben eine spezielle Bedeutung in der Harmonielehre, die Funktion. Im Entitätstyp Function sind die möglichen Funktionen modelliert
(z. B. Tonika, Tonikaparallele). Durch die Beziehung FunctionInScale sind zu jeder Tonleiter die Funktionen definiert.
4.3 Entwurf der ScoreStore-Datenbank
Für die Durchführung einer harmonischen Analyse werden zunächst die zu betrachtenden
Partituren benötigt. Die Beziehung der einzelnen Musikelemente (Noten und Pausen) ist dabei
für die Untersuchung von besonderer Bedeutung. Daher werden diese Elemente ohne weitere
für die harmonische Untersuchung irrelevante Attribute (z. B. das Layout betreffende) in der
Datenbank gespeichert. Bei Bedarf können natürlich weitere Attribute hinzugefügt werden.
Diese, die jeweiligen Musikwerke direkt betreffende Informationen, werden im Folgenden als
Primärdaten bezeichnet und in der ScoreStore-Datenbank modelliert.
Mit Hilfe der Primärdaten und einer externen Anwendung wäre es bereits so möglich, eine
harmonische Analyse durchzuführen. Allerdings gingen dabei einige der eingangs beschriebe-
Entwurf der ScoreStore-Datenbank
81
ScoreStore
Primary Data
Secondary Data
Score
Note
Interval
ScoreContext
Octave
ScoreMeta
...
Abbildung 4.2: Unterteilung von ScoreStore in Primärdaten und Sekundärdaten
nen Vorteile der Benutzung von Datenbanksystemen verloren, insbesondere die deklarative
Benutzung von SQL und mögliche Anfrageoptimierungen des DBMS. Das Ziel besteht also
darin, Anfragen bzgl. harmonischer Eigenschaften im Kontext der Datenbank auszuführen.
Voraussetzung dafür ist, dass bestimmte musiktheoretische Zusammenhänge ebenfalls in der
Datenbank modelliert sind und geeignet mit den Primärdaten verknüpft werden (siehe Abbildung 4.2). Diese zusätzlichen Informationen werden als Sekundärdaten bezeichnet und im
zweiten Teil dieses Kapitels detailliert beschrieben.
4.3.1 Primärdaten
Die Primärdaten enthalten die eigentlichen Musikwerkinformationen. Dazu zählen alle in
einer Partitur enthaltenen Noten inklusive ihrer Eigenschaften. Diese stellen eine Spielanweisung für ein gegebenes Musikwerk dar und werden in der Score-Tabelle modelliert. Weitere
den Gesamtkontext des Musikwerkes bzw. einzelner kleinerer Notenabschnitte betreffende
Informationen (z. B. die Grundtonart oder die Taktart) werden in einer zusätzlichen Tabelle
ScoreContext repräsentiert. Zusätzliche Daten über die Musikwerke, wie Name, Komponist
oder Katalognummer, können in der ScoreMeta-Tabelle gespeichert werden.
Eine Partitur kann mit Hilfe von Notenschrift beschrieben werden und dient als Spielanweisung.
Diese Spielanweisung lässt sich als eine Folge von Zeitpunkten betrachten, zu denen bestimmte
musikalische Ereignisse eintreten. Die Ereignisse selbst bestehen aus einem oder mehreren
Musikparametern. Zu den wichtigsten Parametern zählen Noten und Pausen, die den melodischen Ablauf eines Werkes beschreiben. Die hier betrachteten Musikwerke sind mehrstimmig
(z. B. Sopran, Alt, Tenor, Bass). Aufgrund dessen treten pro Zeitpunkt meist mehrere Noten
82
Partiturdarstellung im relationalen Datenmodell
Abbildung 4.3: Abbildung der Partiturdaten in ein relationales Tabellenformat. Auschnitt aus
dem Werk Winterreise von Franz Schubert (Winterreise d 911, Satz 1). Die Musikelemente (Noten
und Pausen) werden jeweils auf einzelne Tupel der Score-Tabelle abgebildet.
gleichzeitig auf, die in der Partitur durch unterschiedliche Notensysteme getrennt dargestellt
werden. Das relationale Modell einer Partitur soll genau diese Zusammhänge widerspiegeln.
Die oben beschriebenen Eigenschaften der musikalischen Ereignisse werden in einer Partitur
durch den Zeitpunkt des Auftretens (Takt und Position im Takt), sowie Note (Notensymbol)
und Notensystem beschrieben. Die absolute Tonhöhe der Note wird durch zusätzliche Angabe
des Notenschlüssels eindeutig identifiziert. Die in der Notenschrift verwendeten Notensymbole
beinhalten meist mehrere Eigenschaften. Ein Notensymbol kodiert bspw. den Stammton
und die Tondauer. Für eine Modellierung im Datenmodell wird die in einem Notensymbol
enthaltene Information zerlegt und einzeln repräsentiert. Insgesamt kann eine einzelne Note
im relationalen Modell durch folgende Eigenschaften repräsentiert werden: Zeitpunkt des
Auftretens, Notensystem, Stammton, Alteration, Oktave und Tondauer.
Die genaue Darstellung dieser Informationen wird im Folgenden anhand eines Beispiels
erläutert. Zu diesem Zweck wurde ein Ausschnitt aus dem Werk Winterreise von Franz
Schubert ausgewählt (vgl. Abbildung 4.3). Im vorliegenden Beispiel lässt sich erkennen, dass
das Ereignis an erster Position im zweiten Takt (siehe Markierung) aus mehreren Elementen
(Noten und Pausen) besteht. Im relationalen Modell werden alle Elemente eines Ereignisses
einzeln betrachtet und durch jeweils ein Tupel repräsentiert. In den folgenden Abschnitten
werden die zur Partiturrepräsentation benötigten Attribute einzeln vorgestellt und diskutiert.
Im Unterschied zur konzeptuellen Modellierung, bei der eine Partitur durch einen Entitätstypen
dargestellt wurde, entspricht die Realisierung der Score-Tabelle in der ScoreStore-Datenbank
einer Beziehung (Relationship) zwischen den dargestellten Musikelementen.
Entwurf der ScoreStore-Datenbank
83
Tonhöhe
Die Tonhöhe einer Note lässt sich auf unterschiedliche Arten kodieren. Hier muss insbesondere
eine Repräsentation gewählt werden, die eine effiziente harmonische Untersuchung ermöglicht.
Voraussetzung dafür ist, dass sowohl die Information über den Stammton als auch über den
genauen Halbton innerhalb der 12 Oktavtöne vorliegt. Nur so kann eine direkte Bestimmung
eines Intervalls vorgenommen werden.
Die Kodierung der Tonhöhe mittels eines einzigen Attributs kann diese Anforderung nicht
erfüllen. Eine solche Darstellung ist bspw. die Tonhöhenkodierung des MIDI-Formats, bei der
die Töne der gesamten Tonreihe durchnummeriert werden. Als Abspielanweisung reicht diese
Repräsentationsform zwar aus, allerdings geht die Stammtoninformation verloren. Dies führt
zur enharmonischen Verwechslung der Töne und macht das Format damit für eine mögliche
harmonische Analyse ungeeignet.
Die Erweiterung dieser Kodierungsform um ein weiteres Attribut, das genau diese Stammtoninformation speichert, würde grundsätzlich ausreichen, um alle für die harmonische Analyse
benötigten Informationen zu berechnen. Diese Form der Speicherung ähnelt der mittels Notenschrift kodierten Partitur. Auch hier wird der Stammton und die Zuordnung zu einem
Oktavbereich (durch Angabe des Notenschlüssels) realisiert.
Eine der Partiturdarstellung noch ähnlichere Form der Repräsentation wurde schließlich in der
ScoreStore-Datenbank umgesetzt. Dabei wird zunächst die relative Tonhöhe (d. h. die Tonhöhe
innerhalb einer Oktave) durch Stammton und Alteration kodiert. Mit Hilfe eines dritten
Atrributs wird dann der Oktavbereich festgelegt, wodurch letztlich die absolute Tonhöhe
bestimmt ist.
Um bspw. die oberste Achtelnote im mittleren Notensystem aus dem Beispielausschnitt in
das relationale Datenmodell zu übertragen, werden die Eigenschaften dieser Note wie folgt
abgebildet: Der vorliegende Ton ist ein zweigestrichenes e. Im Modell entspricht der Stammton
e durch Zahlenkodierung dem Wert 2. Alle anderen Töne der Stammtonreihe lassen sich analog
durch Zahlen aus dem Bereich zwischen 0 und 6 kodieren, wobei 0 der Note c, 1 der Note d usw.
entspricht. Eine detaillierte Beschreibung der Tabelle Note erfolgt im Abschnitt 4.3.2. Eine
Alteration der Note e liegt hier nicht vor, daher ist in das entsprechende Feld eine 0 einzutragen.
Mögliche andere Werte geben negative und postive Änderungen gegenüber dem Stammton in
Halbtonschritten an. Die gültigen Oktavbereiche sind von 0 bis 10 durchnummeriert, wobei
die zweigestrichene Oktave bspw. durch die Nummer 6 identifiziert wird. Mit Hilfe dieser
drei Attribute (octave, diatonic, alter) lässt sich die Tonhöhe jeder beliebigen Note eindeutig
bestimmen. Im Fall des zweigestrichenen e entspricht dies der Darstellung (6,2,0).
84
Partiturdarstellung im relationalen Datenmodell
Tondauer
Eine weitere Eigenschaft der Note ist der Notenwert, der durch das Attribut duration in der
Tabelle repräsentiert wird. Der Wertebereich dieser Eigenschaft ist allerdings nicht begrenzt,
so dass grundsätzlich beliebig große bzw. kleine Notenwerte sowie beliebige Zwischenwerte
möglich sind. Deshalb wird, anders als in Partituren, die für jeden Notenwert ein bestimmtes
Notensymbol verwenden, die Notendauer im relationalen Format bzgl. der kleinsten Werteinheit
berechnet, mit der alle in der Partitur vorkommenden Noten dargestellt werden können. Damit
wird eine einheitliche Darstellung der Notendauer in der Tabelle bezogen auf ein Werk
erreicht. Dies führt dazu, dass sich die Notenwerte der einzelnen im relationalen Format
vorliegenden Partituren unterscheiden können, was sich aber mit einfachen Mitteln normieren
lässt. Der kleinste im Notenbeispiel vorkommende Notenwert ist eine 1/32-Note, die an der
letzten Position im zweiten Takt vorkommt. Im relationalen Format wird sie als Note mit
der kürzesten Notendauer mit einer Einheit kodiert (duration = 1). Für die betrachtete Note
e, die als Achtelnote eine viermal so lange Notendauer aufweist wie eine 1/32-Note, ergibt
sich dadurch eine Notendauer von vier Einheiten (duration = 4). Um aus der Dauer den
tatsächlichen Notenwert zu bestimmen, wird in der ScoreContext-Tabelle die Anzahl der
benötigten Einheiten für eine Viertelnote pro Werk kodiert (siehe Abschnitt 4.3.2).
Zeitpunkt
Der Zeitpunkt, zu dem eine Note erklingt, wird ebenfalls relativ zur Dauer der kürzesten
Note im Werk kodiert. Dem ersten Ereignis im ersten Takt wird dabei immer der Startwert
1 zugewiesen, von dem ausgehend die Zeitpunkte für alle weiteren Ereignisse bestimmt sind.
Da im Beispiel ein Takt aus vier direkt aufeinander folgenden Achtelnoten besteht (jeweils
duration = 4), ergibt sich daraus, dass das erste Ereignis im zweiten Takt zum Zeitpunkt 17
auftritt. Im relationalen Modell wird dieser Zeitpunkt durch das Attribut time modelliert.
Um eine Note eines einstimmigen Werkes eindeutig im relationalen Schema abzubilden, werden
genau die vorgestellten Attribute Stammton (diatonic), Alteration (alter ), Oktave (octave),
Zeitpunkt (time) und Dauer (duration) benötigt.
Notensystem
Für die harmonische Analyse werden hauptsächlich mehrstimmige Werke verwendet. Dies
hat zur Folge, dass noch ein weiteres Attribut benötigt wird, welches jede Note eindeutig
einem Notensystem zuordnet. Im Schema wird dies durch das Attribut staff modelliert.
Entwurf der ScoreStore-Datenbank
85
Das vorliegende Beispiel besteht aus drei Notensystemen, auf die die einzelnen Noten- und
Pausenelemente aufgeteilt sind. Ihnen wird jeweils ein Zahlencode zugewiesen, der sich aufgrund
der Nummerierung der Systeme ergibt (von oben nach unten beginnend bei 1). Die betrachtete
Note e liegt im zweiten System und bekommt daher den Attributwert 2 zugewiesen. Analog
werden die Werte der restlichen Elemente des betrachteten Ereignisses bestimmt und in die
entsprechenden Felder eingetragen. Die Noten eines mehrstimmigen Werkes lassen sich damit
jeweils durch ein Sechs-Tupel von Attributwerten eindeutig modellieren.
Kontextinformationen
Das gesamte Musikwerk, bzw. kleinere Abschnitte betreffende Kontextinformationen (z. B.
Grundtonart, Taktart), werden in der ScoreContext-Tabelle modelliert. Die Tabelle hält ähnlich
wie die Hauptrelation im Attribut time alle Zeitpukte fest, an denen die Informationen zum
ersten Mal definiert werden bzw. sich geändert haben. Zu den modellierten Eigenschaften
zählen die Grundtonart (fifths), das Tonartgeschlecht (keyMood ), die Taktart (beats und
beatType) und die Anzahl der Einheiten pro Viertelnote (divisions). Die Grundtonart wird
durch eine Zahl von -6 bis 6 kodiert, die jeweils der Anzahl der Vorzeichen einer Tonart
entspricht. Negative Zahlen verweisen dabei auf Tonarten mit Erniedrigungsvorzeichen (b),
während positive auf Kreuzvorzeichen (#) verweisen. Durch das Tonartgeschlecht wird die
Tonart schließlich eindeutig definiert. Dur-Tonarten werden dabei durch den Wert 1 und
Moll-Tonarten mit dem Wert -1 kodiert. Die Taktart wird ebenso wie in der Partitur durch
zwei Attribute kodiert. Der Nenner beatType legt dabei die Art des Notenwertes fest, während
der Zähler beat die Anzahl dieser Werte bestimmt. Mit der Eigenschaft divisions wird die
Anzahl der Unterteilungen einer Viertelnote festgelegt, die die Abbildung einer Notendauer
auf einen Notenwert ermöglicht (wie im Abschnitt über Tondauer erläutert).
Realisierung
Um die Inhalte einer Partitur mit der oben vorgestellten Modellierung in relationalen Datenbanken zu repräsentieren, werden die Tabellen Score und ScoreContext benötigt. Die
Unterteilung in zwei Tabellen lässt sich dabei durch die unterschiedliche Größe der beiden
Tabellen begründen. Während die Score-Tabelle z. T. aus mehreren Tausend Tupel bestehen
kann, da für jede Zeiteinheit das jeweils aktuell vorliegende musikalische Ereignis gespeichert
werden muss, liegen in der ScoreContext-Tabelle nur wenige Tupel. Wären die übergeordneten
Informationen zum jeweiligen Musikwerk ebenfalls in der Score-Tabelle enthalten, würde dies
zur Folge haben, dass in vielen Tupeln der gleiche Wert für diese Attribute hinterlegt wäre.
86
Partiturdarstellung im relationalen Datenmodell
<<table>>
Score
*
1
id
id
id
time
staff
octave
diatonic
alter
duration
<<table>>
ScoreMeta
1
*
id
id
<<key>> id
name
composer
catalog
number
...
<<table>>
ScoreContext
<<key>> id
<<key>> time
fifths
beats
beatType
divisions
keyMood
Abbildung 4.4: Modellierung der Score-, ScoreContext- und ScoreMeta-Tabellen. Die Fremdschlüsselbeziehungen über id sind nicht notwendig für die harmonische Analyse. Sie wurden in der
Implementierung aus Speicherplatzgründen weggelassen. Stattdessen wird ein Werk über einen
eindeutigen Tabellennamen identifiziert.
Diese Modellierung wäre ineffizient, da sie viele Redundanzen enthalten würde. Die Abbildung
4.4 zeigt die Modellierung der Score-, ScoreContext- und ScoreMeta-Tabellen.
Das in Abbildung 4.4 dargestellte Attribut zur Identifizierung des Werkes ist optional. Der
Grund dafür ist, dass für jede Partitur eine eigene Tabelle angelegt und nach dem Namen des
Musikwerkes benannt wird (z. B. Schubert d911 01 winterreise). Es wäre auch möglich gewesen,
alle Partiturdaten in einer einzigen Tabelle zu verwalten. Dann müsste pro Musikwerk ein
zusätzliches Identifizierungsattribut gepflegt werden, das z. T. bei mehreren Tausend Tupeln
(abhängig von der Partiturgröße) immer den gleichen Wert enthielte. Da sich die meisten
Fragestellungen zur harmonischen Analyse allerdings nur auf ein Musikwerk beschränken,
müsste dieses bei einer solchen Modellierung zunächst extrahiert werden. Daher wurde die oben
erläuterte Vorgehensweise gewählt. Kombinierte Abfragen von harmonischen Informationen
über Werksgrenzen hinweg könnten in dieser Modellierung über Vereinigung der Tabellen (vgl.
Kapitel 3.1) und temporäre Erzeugung einer Musikwerk-Identifikationsnummer erfolgen. Die
Namen der jeweiligen Tabellen sind in ScoreMeta gespeichert.
Ein weiteres Argument für die Abspeicherung der Partituren in getrennten Tabellen gibt die
Datenbank selbst vor. Die für diese Diplomarbeit verwendete Access-Datenbank beschränkt
die Größe einer Tabelle auf 2 GB. Eine Speicherung aller Partituren in einer Tabelle würde
diesen Grenzwert vergleichsweise schnell überschreiten.
4.3.2 Sekundärdaten
Die im oberen Abschnitt vorgestellte relationale Repräsentation von Musikwerken reicht
alleine nicht aus, um mittels SQL und des DBMS eine harmonische Analyse durchzuführen.
Entwurf der ScoreStore-Datenbank
87
Diesbezüglich fehlen in der Datenbank noch Informationen über musiktheoretische Grundlagen.
Anhand der einzelnen Score-Tabellen ist es bspw. noch nicht einmal möglich, die Notennamen
des Musikwerkes zu bestimmen, da die verwendete Zahlenkodierung bislang nicht definiert
wird. Gleiches gilt für Intervalle und Akkorde. Ohne Modellierung weiterer Informationen
sind die Inhalte der Primärdatentabellen nicht sehr aussagekräftig. Erst durch Spezifikation
und Modellierung musikalischer Grundlagen in der ScoreStore-Datenbank erhalten diese einen
inhaltlichen Sinn, realisiert durch Verknüpfungen der einzelnen Tabellen.
Die Grundlagen werden in Form von Musikparametern wie z. B. Note, Intervall, Akkord etc. in
einzelnen Tabellen modelliert und in der ScoreStore-Datenbank als Sekundärdaten gespeichert.
Diese Informationen werden grundsätzlich nur einmal modelliert und bleiben unverändert
bestehen. Die später vorgestellte und darauf aufbauende Anwendung hat nur einen lesenden
Zugriff auf diese Daten, so dass diese nicht manipulierbar sind. Selbstverständlich ist es aber
denkbar, die Sekundärdaten um weitere Musikparameter und Attribute zu erweitern.
Die Sekundärdaten werden hauptsächlich für die harmonische Analyse der Primärdaten
benötigt. Es ist aber ebenfalls möglich, diese alleine zu verwenden, um musikalische Grundlagen,
insbesondere die der Allgemeinen Musiklehre, abzufragen (z. B. Welche Intervalle sind rein?).
In den folgenden Abschnitten soll das gesamte Schema der Sekundärdaten in der ScoreStoreDatenbank vorgestellt und diskutiert werden, angefangen mit dem wichtigsten Musikparameter,
der Note.
Note
In der Tabelle Note werden alle innerhalb eines Oktavraumes vorkommenden Noten zusammengefasst. Dabei werden nicht nur die einzelnen Stammtöne, sondern auch die durch
unterschiedliche Vorzeichen veränderten Noten abgebildet. Die am häufigsten verwendeten
Alterationen bilden die Einfach- und Doppelerhöhungen bzw. -erniedriegungen, so dass sich
eine Gesamtanzahl der verwendeten Möglichkeiten von 35 ergibt. In der Tabelle Note ist
zusätzlich die Pause enthalten, obwohl sie eigentlich keine Note darstellt. Sie beeinflusst aber
ebenso wie die Note den melodischen Ablauf eines Musikwerkes. Da sie darüber hinaus nur
aus einem Objekt besteht, wird sie zur Tabelle Note hizugefügt. Die Attributwerte einer Pause
werden jeweils durch den Wert -1 kodiert, wodurch eine klare Abgrenzung zu richtigen“ Noten
”
vorliegt. Diese Kodierung hat den Vorteil, dass alle Noten- und Pausenelemente vollständig
identifiziert und benannt werden können. Stattdessen könnte man aber auch einen Null-Wert
für die Note eintragen und diesen als Pause interpretieren.
88
Partiturdarstellung im relationalen Datenmodell
Abbildung 4.5: Diatonische- und chromatische Notenkodierung. Die obere Zahlenfolge (rot)
entspricht der zwölftönigen Oktavkodierung. Die untere Darstellung (blau) repräsentiert die Töne
der Stammtonreihe. Mittels des zusätzlichen Attributs alter lassen sich ebenfalls alle Halbtöne
modellieren.
Jede Note wird durch die Angabe von fünf Attributwerten vollständig charakterisiert und
definiert, so dass die darauf aufbauende Durchführung einer harmonischen Analyse möglich ist.
Hauptsächlich besteht die Tabelle Note aus Attributen, die die unterschiedlichen benötigten
Kodierungsformen von Noten repräsentieren. Im Folgenden soll auf diese fünf Charaktereigenschaften (diatonic, alter, chromatic, name, id ) näher eingegangen werden.
diatonic und alter: Diese beiden Attribute repräsentieren jeweils den Stammton und das
Vorzeichen einer Note. Diese, der Notenschrift ähnliche Kodierungsform, erlaubt dabei
eine eindeutige Definition von Noten (keine enharmonische Verwechslung) und stellt daher
auch den Primärschlüssel der Tabelle dar. Da Partituren die Basis für eine harmonische
Analyse bilden und insbesondere die Information über die einzelnen Noten von großer
Wichtigkeit ist, wird auch bei der relationalen Partiturdarstellung diese Kodierungsform
verwendet, um einen Informationsverlust zu vermeiden. Eine weitere wichtige Bedeutung
besitzt diese Darstellung für die harmonische Analyse. Bei der Bestimmung von Intervallen,
insbesondere für den diatonischen Abstand, wird die Kodierung der Stammtöne benötigt,
um ein Intervall eindeutig zu klassifizieren.
chromatic: Eine weitere benötigte Kodierungsform wird durch das Attribut chromatic beschrieben. Hierbei wird eine Note durch die zwölf möglichen Oktavtöne repräsentiert,
die jeweils durch die Werte von 0 bis 11 in der Tabelle dargestellt werden können (siehe
Abbildung 4.5). Dabei wird wie bei der Kodierung der Stammtöne auch bei 0 angefangen,
um später einfacher Berechnungen durchführen zu können (z. B. Modulo-Berechnungen).
Diese Kodierungsform beschreibt alle tatsächlich vorkommenden Töne innerhalb einer
Oktave. Da die Anzahl möglicher Noten in einem Oktavraum allerdings weitaus größer
Entwurf der ScoreStore-Datenbank
<<table>>
Note
<<table>>
Octave
<<key>> diatonic
<<key>> alter
chromatic
name
<<key2>> id
<<key>> number
name
short
89
Abbildung 4.6: Modellierung von Note und Octave. Die Tabelle Note wird eindeutig durch die
Attribute diatonic und alter identifiziert (Primärschlüssel). Die Oktave wird hingegen durch ihre
Nummer (number ) eindeutig beschrieben. Es besteht keine Beziehung zwischen den Tabellen.
ist, ist durch diese Darstellung keine eindeutige Notenrepräsentation gegeben. So kann
z. B. die Tonnummer 1 (erste schwarze Taste auf der Klaviatur) ein cis oder ein des
oder aber ein hisis bedeuten. Im Falle einer Verwendung dieser Notation zur exakten
Notenkodierung, muss zusätzlich der Stammton mit angegeben werden. Beide zusammen
führen schließlich zur genauen Beschreibung einer Note (z. B. diatonic=4 und chromatic=8
entspricht der Note gis). Trotzdem ist die zwölftönige Oktavrepräsentation unabdingbar,
da sie für die Feinbestimmung der Intervalle (chromatischer Abstand) benötigt wird. Die
Berechnung aus der Stammtondarstellung ist mit geringem Aufwand nicht möglich.
name: Dieses Attribut ordnet jeder Note einen Namen, wie aus der Musiklehre bekannt, zu,
so dass eine eindeutige Benennung von Noten innerhalb einer Oktave verwendet wird.
Die Pause erhält dabei den Namen Pause zugewiesen.
id: Dieses Attribut ist ein zusätzliches künstlich erzeugtes Attribut, mit dessen Hilfe einfacher
referenziert werden kann. Es repräsentiert eine Note durch eine eindeutige Nummer, die
auf keine der oben vorgestellten Eigenschaften zurückgeführt werden kann.
Oktave
Die hier vorgestellte Kodierung einer Note ist allerdings nur eine relative Beschreibung der
Töne, aus der noch nicht ersichtlich wird, in welchem Oktavbereich die Töne erklingen. In der
Tabelle Octave werden alle Eigenschaften von Oktavbereichen festgelegt (siehe Abbildung 4.6).
Wie bei MIDI wird ein Tonraum von insgesamt 128 Tönen zugelassen, wobei sie von 0 bis 127
durchnummeriert werden. Hierbei wird dem Ton 0 die Note c in der Subsubkontra-Oktave
zugewiesen. In der Tabelle ist diese Eigenschaft durch das Attribut number beschrieben. Wird
der gesamte Tonraum in Oktavräume unterteilt, so erhält man insgesamt 11 Oktavbereiche. Den
ersten bildet dabei die Subsubkontra-Oktave. Den letzten Oktavraum bildet die sechsgestrichene
90
Partiturdarstellung im relationalen Datenmodell
<<table>>
Note
<<key>> diatonic
<<key>> alter
chromatic
name
<<key2>> id
1
diatonic
alter
*
diatonic
alter
<<table>>
Score
*
octave
id
time
staff
octave
diatonic
alter
duration
1
<<table>>
Octave
number
<<key>> number
name
short
Abbildung 4.7: Beziehungen von Score, Note und Octave
Oktave, die allerdings nicht vollständig ist. Der Ton 127 entspricht der Note g in diesem
Oktavraum. Diese Darstellung wurde gewählt, um eine mögliche Konvertierung aus und in
MIDI zu ermöglichen. Durch das Attribut name werden die einzelnen Oktavbereiche jeweils
durch einen Namen näher charakterisiert (z. B. große Oktave, kleine Oktave). Das Attribut
short speichert eine abgekürzte Bezeichnung der einzelnen Oktavräume. Die eingestrichene
Oktave wird dabei durch das Zeichen ’, die zweigestrichene Oktave durch ’ ’ usw. kodiert
(eingestrichenes e entspricht also e’ ). Generell werden alle Noten ab der großen Oktave abwärts
mit Groß- und aufwärts mit Kleinbuchstaben gekennzeichnet.
Durch die Elemente aus Note und Octave werden die Inhalte der Score-Tabellen vollständig
beschrieben. Es lassen sich mittels geeigneter Verknüpfungen die exakten Tonhöhen und
Namen der Noten bestimmen. Desweiteren sind unterschiedliche Notenkodierungen möglich. In
Abbildung 4.7 ist das gesamte Schema dargestellt. Hierbei lässt sich erkennen, dass die Tabellen
Note und Octave keine Beziehung haben, obwohl sie eigentlich sehr eng miteinander verbunden
sind und nur zusammen z. B. die Tonhöhe einer Note bestimmen. Das liegt daran, dass die
verwendete Modellierung nur die möglichen Noten und Oktavbereiche definiert, anstatt alle
Noten in allen Oktavbereichen explizit aufzulisten.
Intervall
Die Intervallbestimmung ist der erste Schritt bei der Bestimmung von Akkorden. Ein Intervall
besteht aus zwei Noten und wird durch zwei unterschiedliche Abstandsdefinitionen eindeutig
identifiziert. Der diatonische Abstand wird dabei durch die Distanz zweier Stammtöne definiert
und bestimmt gleichzeitig den Namen des Intervalls. Die zweite Abstandsdefinition bezieht sich
auf die Anzahl der Halbtonschritte zwischen den Noten, wodurch eine feinere Abstufung des
betrachteten Intervalls angegeben werden kann. Da ein Halbtonabstand mehreren diatonischen
91
Entwurf der ScoreStore-Datenbank
0 (v)
Sekunde
1 (k)
2 (g)
3 (ue)
2 (v)
Terz
3 (k)
4 (g)
5 (ue)
Abbildung 4.8: Mehrdeutigkeit beim chromatischen Abstand. Abstand von drei Halbtönen
(Werte unterhalb von Noten) kann sowohl auf eine übermäßige (ü) Sekunde, als auch auf eine
kleine (k) Terz hindeuten. Die Kennzeichnungen (v) und (g) verweisen dabei auf verminderte bzw.
große Intervalle.
Intervallen zugeordnet werden kann, ist es sinnvoll, diese beiden Abstandsdefinitionen in einer
Tabelle zu modellieren. Ein Abstand von drei Halbtönen kann z. B. sowohl einer kleinen Terz
als auch einer übermäßigen Sekunde zugeordnet werden (siehe Abbildung 4.8).
Die Modellierung von Intervallen erfolgt durch die Tabelle Interval, welche nur die verwendete
Intervallkodierung speichert. Weiter gehende Eigenschaften wie bspw. die genaue Benennung
von Grundintervall und Spezialisierung werden durch zusätzliche Tabellen modelliert. Im
Folgenden werden zunächst die drei Attribute diatonic, chromatic und spec beschrieben, die
ein Intervall eindeutig bestimmen.
diatonic: Das Attribut diatonic enthält die Distanz, die bei der Berechnung des diatonischen
Abstands von zwei Noten entsteht. Der diatonische Abstand zwischen den Noten c und
d ist eine Sekunde (lat: entspricht dem Wert zwei). Dies entspricht der Anzahl der
Stammtöne von c nach d. Die hier gewählte Repräsentationsform speichert jedoch den
tatsächlichen Abstand zwischen den Tönen, um insbesondere die Intervallberechnung zu
vereinfachen. Im oberen Beispiel wäre die Distanz somit 1 (1(d ) - 0(c) = 1). Innerhalb
einer Oktave gibt es insgesamt acht verschiedene Intervalle. Die Prime wird dabei durch
die Distanz 0, die Sekunde durch die Distanz 1 usw. kodiert. Über einen Oktavraum
hinausgehende Intervalle (z. B. None) werden bis zur Tredezime (Distanz 12) ebenfalls
dargestellt. Diese Intervallfolge lässt sich beliebig weiter führen, weshalb hier nur die
gebräuchlichsten Intervalle kodiert wurden.
chromatic: Der für die Feinbestimmung des Intervalls benötigte chromatische Abstand wird
im Attribut chromatic gespeichert. Für die Durchführung der Abstandsberechnung ist die
zwölftönige Darstellung der Note erforderlich, mit der sich der Halbtonabstand zwischen
zwei Noten ausrechnen lässt (z.B. 2(d ) - 0(c) = 2). Zusammen mit dem Attribut diatonic
lässt sich somit ein Intervall eindeutig identifizieren.
92
Partiturdarstellung im relationalen Datenmodell
spec: Die Abstufungen eines Intervalls bei der Feinbestimmung werden durch die Bezeichner
vermindert, klein, rein, groß und übermäßig angegeben. Genau diese Intervallcharakterisierungen werden durch das Attribut spec (specialized ) kodiert. Dabei werden die einzelnen
Eigenschaften auf die Werte von -2 bis 2 abgebildet. Genauso wie durch das Attributpaar
diatonic, chromatic, wird auch durch diatonic und spec eine eindeutige Intervallidentifizierung erzielt. Im Gegensatz zu chromatic werden aber durch die spec-Attributwerte
alle möglichen Abstufungen der Intervalle eindeutig kodiert. Aus diesem Grund wird das
Paar (diatonic, spec) als Primärschlüssel der Interval -Tabelle verwendet (z. B. entspricht
diatonic = 4 und spec = 0 einer reinen Quinte).
Zusätzlich zu dem Primärschlüssel diatonic und spec ist als weiterer Schlüssel auf der Interval -Tabelle diatonic und chromatic definiert. Damit kann von anderen Tabellen über
Fremdschlüsselbeziehungen sowohl auf den Primärschlüssel als auch auf den zusätzlichen
Schlüssel verwiesen werden.
In der Tabelle Interval wird lediglich die Kodierungsform der Intervalle gespeichert. Um
Redundanzen zu vermeiden, werden weitere Eigenschaften der Intervalle in zusätzliche Tabellen ausgelagert. Eine Terz kann bspw. in mehreren Feinabstufungen vorkommen (siehe
Abbildung 4.8). Das Attribut diatonic referenziert daher die Tabelle IntervalDiatonic, die
weitere Eigenschaften bzgl. des diatonischen Intervalls speichert. Die Bezeichnung des Intervalls
wird durch das Attribut name repräsentiert. Desweiteren exisiert noch die Eigenschaft perfect,
die mittels eines Wahrheitswertes kodiert, ob es sich bei dem betrachteten Intervall um ein
reines Intervall handelt (true enspricht dabei einem reinen Intervall). Die Tabelle IntervalSpec
bildet die einzelnen in der Tabelle Interval vorkommenden Werte des Attributs spec auf deren
tatsächliche Benennung ab. Diese wird durch das Attribut name modelliert (z. B. name = 0
entspricht der Eigenschaft rein).
Zu jedem Intervall innerhalb eines Oktavbereiches existiert auch ein Umkehrintervall (siehe
Kapitel 2.1), modelliert durch die Tabelle IntervalInverse. Hierzu wird jedem Intervall sein
Umkehrintervall zugeordnet. Jedes Tupel wird dabei durch vier Attributwerte diatonicInverse,
specInverse, diatonic und spec beschrieben. Die Attribute diatonic und spec beziehen sich
dabei auf die Primärschlüsselattribute der Interval -Tabelle, während die anderen beiden
die Umkehrung des betrachteten Intervalls darstellen. So besitzt z. B. die kleine Terz als
Komplementärintervall eine große Sexte. Das IntervalInverse-Tupel würde demzufolge durch
diatonicInverse = 5, specInverse = 1, diatonic = 2 und spec = -1 kodiert werden. Das gesamte
Schema des Intervallmodells ist in Abbildung 4.9 dargestellt.
93
Entwurf der ScoreStore-Datenbank
<<table>>
IntervalSpec
<<key>> spec
name
1
spec
*
*
<<table>>
Interval
spec
diatonic
1
diatonic
<<key,key2>> diatonic
<<key>> spec
<<key2>> chromatic
diatonic 1
spec
diatonic
spec 0..1
<<table>>
IntervalDiatonic
<<key>> diatonic
perfect
name
1 diatonic
spec
diatonicInverse
0..1 specInverse
<<table>>
IntervalInverse
<<key>> diatonic
<<key>> spec
diatonicInverse
specInverse
Abbildung 4.9: Modellierung des Intervalls. Ein Intervall lässt sich eindeutig durch ein Tupel
aus der Interval -Tabelle bestimmen. Weitere Eigeschaften wie z. B. die Benennung werden durch
die Tabellen IntervalDiatonic und IntervalSpec modelliert. In der Tabelle IntervalInverse werden
alle Komplementärintervalle zusammengefasst.
Akkord
Die wichtigsten Elemente für die harmonische Analyse sind Akkorde. In diesem Abschnitt wird
ihre Modellierung exemplarisch anhand von Dreiklängen beschrieben. Weitere Mehrklänge
lassen sich analog repräsentieren. Ein Dreiklang besteht aus drei Noten unterschiedlicher
Tonhöhe, die jeweils in der Grundstellung in Terzen übereinander geschichtet vorliegen (siehe
Kapitel 2.1.4). Durch die Intervallbestimmung lassen sich folgende Beziehungen zwischen den
Noten identifizieren:
• Grundton (G) – Terzton (T): Abstand eines Terzintervalls; Grundton entspricht
gleichzeitig auch dem Basston (B)
• Terzton (T) – Quintton (Q): Abstand eines Terzintervalls
• Grundton (G) – Quintton (Q): Abstand eines Quintintervalls; Rahmenintervall
Für die exakte Ermittlung des Dreiklangs werden lediglich zwei dieser Beziehungen benötigt.
Am besten geeignet sind dabei die Beziehungen Grundton – Terzton (GT) und Grundton –
Quintton (GQ), da sie jeweils von einem bestimmten Ton ausgehen. Werden z. B. die Intervalle
große Terz (GT) und reine Quinte (GQ) erkannt, so entspricht dies Dur-Dreiklängen in der
94
Partiturdarstellung im relationalen Datenmodell
Grundstellung. Das Geschlecht (hier Dur), als weitere Charakterisierung des Dreiklangs, muss
ebenfalls abgespeichert werden, um die Beziehung zwischen den Intervallen und dem Geschlecht
herzustellen.
Ein Dur-Dreiklang kann allerdings noch in zwei weiteren Akkordstellungen auftreten, wobei
diese jeweils andere Intervallbeziehungen als die oben beschriebenen aufweisen (z. B. erste
Umkehrung = Sextakkord). Damit dieses Gebilde trotzdem als ein Dur-Dreiklang erkannt
wird, müssen diese Intervallbeziehungen ebenfalls kodiert werden. Beim Sextakkord liegt bspw.
der Terzton im Bass (entspricht dem tiefsten Ton des Akkordes). Ausgehend vom Basston
lassen sich die Intervalle kleine Terz und kleine Sexte identifizieren. Ein Dreiklangstyp (z. B.
Dur) lässt sich damit durch drei unterschiedliche Zusammenklänge darstellen.
Grundsätzlich könnten alle Akkorde, unabhängig davon, aus wie vielen Tönen sie bestehen, in
einer Tabelle dargestellt werden. Dieser könnte durch die Attribute Akkordtyp (z. B. Dreiklang,
Vierklang), Intervall, Geschlecht und Akkordstellung beschrieben werden. Dies würde aber
bedeuten, dass ein Zusammenklang, abhängig von der Anzahl der vorkommenden Töne, aus
mehreren Entitäten zusammengesetzt werden müsste. Ein Dur-Dreiklang in der Grundstellung
würde dementsprechend durch die Entitäten (Dreiklang, große Terz, Dur, Grundstellung) und
(Dreiklang, reine Quinte, Dur, Grundstellung) beschrieben werden. Um alle seine Definitionen
abzudecken, werden damit noch vier weitere Entitäten für die erste- und zweite Umkehrung
benötigt. Desweiteren fällt auf, dass Informationen über den Akkordtyp, Geschlecht und die
Stellung redundant gespeichert werden. Aus diesen Gründen wurde eine Modellierung gewählt,
bei der jeweils Akkorde abhängig von der Notenanzahl durch Tupel unterschiedlicher Tabellen
dargestellt werden. So werden alle Zusammenklänge, die aus drei Tönen bestehen, in der
Tabelle Chord3, die aus vier Tönen bestehenden in Chord4 usw. repräsentiert.
Im Folgenden wird die Modellierung der Tabelle Chord3 am Beispiel eines Dreiklangs vorgestellt. Die benötigten Attribute sind zwei Intervalle (diatonic1, chromatic1, diatonic2 und
chromatic2 ), das Geschlecht (chordMood ) und Akkordstellung (inversion).
Intervalle: Die Attribute diatonic1, chromatic1, diatonic2 und chromatic2 repräsentieren
jeweils zwei unterschiedliche Intervalle, durch die Dreiklänge wie eingangs beschrieben
exakt definiert werden können. Jedes Tupel entspricht also genau einem bestimmten
Dreiklangsakkord. Die ersten zwei Attribute diatonic1 und chromatic1 beschreiben das
vom Basston zum nächsthöheren Ton entstehende Intervall, während das zweite Intervall
(diatonic2, chromatic2 ) den Abstand vom Basston zum obersten Ton repräsentiert.
Damit dem Akkord ein bestimmtes Geschlecht zugeordnet werden kann, wird ein weiteres
Attribut benötigt.
Entwurf der ScoreStore-Datenbank
<<table>>
Interval
<<key,key2>> diatonic
<<key>> spec
<<key2>> chromatic
1
diatonic
chromatic
*
diatonic
chromatic
<<table>>
Chord3
diatonic1
chromatic1
1
*
diatonic2
chromatic2
<<key>> diatonic1
<<key>> chromatic1
<<key>> diatonic2
<<key>> chromatic2
chordMood
inversion
chordMood *
chordMood 1
<<table>>
ChordMood
<<key>> chordMood
name
shortcut
95
*
inversion
1
inversion
<<table>>
Chord3Inversion
<<key>> inversion
name
Abbildung 4.10: Modellierung des Akkordes. Ein Akkord läßt sich eindeutig durch zwei Intervalle
definieren. Darauf ergibt sich das Akkordgeschlecht (chordMood ) und die Umkehrung (inversion),
die jeweils in eigenen Tabellen näher charakterisiert sind.
Geschlecht: Das Attribut chordMood kodiert das Geschlecht eines Akkordes und erlaubt
damit eine nähere Charakterisierung eines Zusammenklangs. Bei Dreiklängen existieren
vier verschiedene Typen: Dur, Moll, vermindert und übermäßig, die durch die Werte 1,
-1, -2 und 2 kodiert werden. Definiert werden diese Werte in der Tabelle ChordMood, wo
auch der zugehörige Name (name) und eine Abkürzung (shortcut) gespeichert sind.
Umkehrung: Die Umkehrung eines Akkordes wird durch das Attribut inversion kodiert. Der
Wert 0 bedeutet dabei, dass der betrachtete Akkord in der Grundstellung steht, der Wert
1 steht für die erste Umkehrung usw. Die entsprechenden Umkehrungen werden in der
Tabelle Chord3Inversion dargestellt.
Die vollständige Modellierung mit den Beziehungen ist in Abbildung 4.10 dargestellt.
Tonart und Tonleiter
Tonarten und die zugehörigen Tonleitern werden ebenfalls in der ScoreStore-Datenbank
modelliert. Die Tabelle Key enthält alle Informationen zu einer Tonart mit einem bestimmten
Geschlecht (siehe Abbildung 4.11). Ausgehend von der Anzahl und der Art der Vorzeichen
(fifths) und des Tonartgeschlechts (keyMood ) ergibt sich der Grundton (root) der jeweiligen
96
Partiturdarstellung im relationalen Datenmodell
1
<<table>>
Fifths
fifths
<<table>>
KeyMood
1
fifths
<<key>> fifths
<<key>> keyMood
1 keyMood
fifths *
<<table>>
Scale
<<key>> fifths
<<key>> diatonic
alter
* keyMood
*
1
diatonic diatonic
alter
alter
<<table>>
Note
1
fifths
*
*
id
root
<<key>> diatonic
<<key>> alter
chromatic
name
<<key2>> id
<<table>>
Key
<<key>> fifths
<<key>> keyMood
root
Abbildung 4.11: Modellierung von Tonart und Tonleiter
Tonart. Bei den Vorzeichen stehen negative Zahlen für Be-Vorzeichen und positive Zahlen
für Kreuz-Vorzeichen. Beim Tonartgeschlecht steht eine -1 für Moll und eine 1 für eine
Dur-Tonart.
In der Scale-Tabelle sind zu einer Tonart mit bestimmten Vorzeichen die jeweiligen Tonleitertöne modelliert. Dabei ist die Information über das Geschlecht nicht enthalten. Scale
enthält zu einem Vorzeichen (fifths) die jeweiligen Noten in (diatonic, alter)-Darstellung. Die
Alteration ergibt sich aus dem Stammton und der Vorzeichnung, weswegen diatonic und fifths
gemeinsam den Primärschlüssel der Tabelle Scale bilden (siehe Abbildung 4.11).
Zusätzlich wird die Tabelle Fifths modelliert, die alle gültigen Vorzeichen aus dem Quintenzirkel
enthält. Sowohl Key als auch Scale verweisen über Fremdschlüsselbeziehungen bzgl. der
jeweiligen fifths-Attribute auf diese Tabelle. Analog dazu ist die Tabelle KeyMood definiert, die
alle gültigen Geschlechtsinformationen für Tonarten enthält. Über Fremdschlüsselbeziehungen
referenziert werden diese Tabellen auch von ScoreContext.
Funktion
Die für die Funktionsbestimmung von Akkorden notwendigen Informationen sind in der ChordFunction-Tabelle modelliert (siehe Abbildung 4.12). Sie enthält zu jeder Stufe (scaleOrder )
in einer Tonleiter den zugehörigen Funktionsnamen und das Geschlecht des auf dieser Stufe
97
Entwurf der ScoreStore-Datenbank
<<table>>
ChordMood
<<key>> chordMood
name
shortcut
1
*
chordMood chordMood
<<table>>
ChordFunction
*
1
keyMood keyMood
<<key>> scaleOrder
<<key>> keyMood
function
chordMood
<<table>>
KeyMood
<<key>> keyMood
Abbildung 4.12: Modellierung der ChordFunction-Tabelle zur Funktionsbestimmung von Akkorden
vorkommenden Dreiklangs. Die diatonische Notendarstellung in der Scale-Tabelle enthält noch
keine Informationen über den Grundton der Tonleiter. Dieser muss durch Kombination mit
der Key-Tabelle ermittelt werden, bevor anschließend die Stufen der jeweiligen Tonleitertöne
berechnet werden können (siehe Kapitel 5). In der ChordFunction-Tabelle erfolgt lediglich die
Zuordnung von scaleOrder und keyMood zu function bzw. chordMood.
5 Harmonische Analyse mit SQL
In diesem Kapitel wird beschrieben, wie mit Hilfe der ScoreStore-Datenbank Musikwerke
bzgl. harmonischer Eigenschaften untersucht werden können. Zunächst wird die Beantwortung
einfacher Fragestellungen mit Hilfe von SQL-Anfragen erklärt. Diese werden dann später in
komplexeren Anfragen wiederverwendet.
Als einleitendes Beispiel wird mit der Frage begonnen, welche Töne zu einem gegebenen
Zeitpunkt gleichzeitig in einem Werk erklingen. Dies bildet die Basis für die im darauf
folgenden Abschnitt vorgestellte Anfrage zur Intervallbestimmung. Aufbauend auf diesen
kann danach beantwortet werden, welcher Akkord zu einem gegebenen Zeitpunkt erklingt.
Im abschließenden Abschnitt wird dann erklärt, wie unter bestimmten Bedingungen eine
Funktionsbestimmung von Akkorden (z. B. Tonika, Dominante) durchgeführt werden kann.
Die in diesem Kapitel vorgestellten Anfragen zur harmonischen Analyse verknüpfen die
konkreten Informationen über die Musikwerke (also die Primärdaten) mit den ebenfalls gespeicherten werkunabhängigen Musikparametern (Sekundärdaten). Über die hier besprochenen
Fähigkeiten hinaus gehend sind natürlich weitere Verknüpfungen zur Beantwortung anderer
Fragestellungen denkbar, z. B. auch zur Bearbeitung werkübergreifender Fragestellungen. In
der ScoreStore-Datenbank werden Musikwerke jeweils durch einzelne Tabellen repräsentiert
(z. B. Schubert d911 01 winterreise bsb). Zur Vereinfachung wird in den vorgestellten Anfragen
immer auf eine Tabelle Score zugegriffen, die für die gerade zu analysierende Partitur steht,
d. h. die jeweiligen Daten enthält.
5.1 Bestimmung zeitgleich erklingender Töne
Für die Bestimmung zu einem Zeitpunkt gleichzeitig erklingender Töne in einer Partitur
wird die Score-Tabelle benötigt, welche die zu untersuchenden Daten beinhaltet. Um die
einzelnen Noten benennen zu können, wird zusätzlich die Tabelle Note verwendet. Durch die
Verknüpfung dieser beiden Tabellen und durch die Angabe eines Parameters für den Zeitpunkt
lässt sich das gewünschte Ergebnis ermitteln. Bei zeitgleich erklingenden Tönen handelt es
99
100
Harmonische Analyse mit SQL
sich um alle Noten, die zu einem bestimmten Zeitpunkt klingend sind, obwohl sie dort nicht
explizit angeschlagen werden müssen. Die Spalte time der Score-Tabelle enthält dagegen alle
Zeitpunkte, zu denen die Noten tatsächlich angeschlagen werden. Die folgenden Schritte sind
für die Bestimmung aller zu einem gegebenen Zeitpunkt klingenden Noten durchzuführen.
Zunächst werden alle Tupel aus der Score-Tabelle selektiert, die zu dem gegebenen Zeitpunkt
t angespielt werden (d. h. time=t). Alle Pausen werden dabei aus der Ergebnismenge entfernt (d. h. diatonic=-1). Um auch die noch klingenden Noten, die zu früheren Zeitpunkten
angeschlagen wurden, zu erfassen, müssen ebenfalls die davor liegenden Zeiten betrachtet
werden (d. h. time≤t). Es werden nur die Töne in die Ergebnismenge aufgenommnen, deren
Dauer (duration) so groß ist, dass sie zum Zeitpunkt t noch klingen. Insgesamt muss time
der Bedingung t − duration < time ≤ t genügen, um alle zu einem gegebenen Zeitpunkt
klingenden Noten zu umfassen. Der Parameter duration entspricht hier der Notendauer des
gerade betrachteten Tupels. Mit SQL lässt sich diese Anfrage wie folgt realisieren:
-- NotesAtTime -SELECT diatonic , alter , octave
FROM
Score
WHERE
time
<= [ t ] AND
time
>
[ t ] - duration AND
diatonic <> -1;
Die SQL-Anfrage lässt sich mit CREATE VIEW als Sicht (z. B. NotesAtTime) abspeichern und
später als Unteranfrage verwenden (z. B. bei der Akkordbestimmung). In Microsoft Access ist
alternativ eine Eingabe über die grafische Oberfläche möglich.
Um die Noten zu benennen, lässt sich die Sicht NotesAtTime mit der Tabelle Note über die
zwei bestimmenden Attribute (Stammton=diatonic und Vorzeichen=alter ), die in beiden
Tabellen vorkommen, verknüpfen. Das dadurch entstandene Ergebnis wird anschließend auf
die Spalte name aus der Tabelle Note projiziert.
-- NoteNamesAtTime -SELECT name
FROM
NotesAtTime INNER JOIN Note
ON NotesAtTime . diatonic = Note . diatonic AND
NotesAtTime . alter
= Note . alter ;
Soll diese Anfrage auf alle Zeitpunkte ausgeweitet werden, wird eine zusätzliche Sicht (TimesInScore) mit allen Zeitpunkten benötigt. Diese lässt sich aus der Score-Tabelle durch Projektion
auf das time-Attribut erzeugen.
101
Bestimmung zeitgleich erklingender Töne
44 4
4
1
2
3
4
1
2
3
1
2
3
4
5 6
Abbildung 5.1: Zuordnung einer Positionsnummer zu jedem neuen Ereignis in einem Takt
beginnend jeweils mit der ersten Position. Ein Ereignis stellt dabei eine neu angeschlagene Note
oder den Beginn eines Pausenelements dar.
-- TimesInScore -SELECT DISTINCT time
FROM
Score
Um schließlich alle klingenden Noten zu allen Zeitpunkten zu bestimmen, werden TimesInScore
und Score durch das Kreuzprodukt miteinander verknüpft und zu allen möglichen Zeitpunkten
die oben genannte Bedingung ausgeführt.
-- NotesAtAllTimes -SELECT TimesInScore . time , diatonic , alter , octave
FROM
TimesInScore , Score
WHERE
Score . time
<= TimesInScore . time AND
Score . time
>
TimesInScore . time - Score . duration AND
Score . diatonic <> -1;
Anstatt einen absoluten Zeitpunkts t angeben zu müssen, ist es wesentlich intuitiver, diesen
in Form einer Taktnummer und einer Position im Takt anzugeben. Dafür ist es zunächst
notwendig, die absoluten Zeitpunkte auf die Repräsentation Takt und Position in Takt
abzubilden. Ein Takt besteht jeweils aus einem oder mehreren Zeitpunkten, zu denen eine
bzw. mehrere Noten gleichzeitig angeschlagen werden oder Pausen vorkommen können. Diese
Zeitpunkte werden jeweils pro Takt durchnummeriert. Die Anzahl der Zeitpunkte kann dabei
von Takt zu Takt varriieren (siehe Abbildung 5.1). Ein 4/4-Takt kann bspw. aus zwei halben
oder vier Viertelnoten bestehen. Die Position im Takt bezeichnet in diesem Zusammenhang
also die Nummer des Zeitpunkts im Takt, zu dem eine oder mehrere Noten angeschlagen
werden.
Um NotesAtTime dahingehend zu erweitern, wird eine zusätzliche Sicht benötigt, welche die
Taktnummer und die Position im Takt auf den absoluten Zeitpunkt abbildet (PosInBarToTime). Die Positionen in einem Takt werden dabei vom kleinsten bis zum größten vorkommenden
102
Harmonische Analyse mit SQL
Abbildung 5.2: Die Anfrage NotesAtPosInBar angewendet auf die zweite Position im dritten Takt
ergibt als Ergebnis vier Tupel, die die Noten d, f, a, d (ausgehend vom tiefsten Ton) repräsentieren.
Zeitpunkt sortiert und nummeriert. Durch Verknüpfung dieser Sicht mit der Score-Tabelle
über das Attribut time lässt sich NotesAtTime um genau diesen Aspekt zu NotesAtPosInBar
erweitern.
-- NotesAtPosInBar -SELECT PosInBarToTime . time , diatonic , alter , octave
FROM
PosInBarToTime INNER JOIN Score
ON PosInBarToTime . time = Score . time
WHERE
Score . time
<= PosInBarToTime . time AND
Score . time
>
PosInBarToTime . time - Score . duration AND
Score . diatonic <> -1;
In Abbildung 5.2 ist diese Anfrage am Beispiel der Winterreise von Franz Schubert durchgeführt. Dabei wird die zweite Position im dritten Takt betrachtet. Als Ergebnis der Anfrage
NotesAtPosInBar(3,2) erhalten wir die zu diesem Zeitpunkt erklingenden Noten d, f, a, d.
5.2 Intervallbestimmung
Intervalle lassen sich bzgl. gleichzeitig gespielter (simultan) oder bzgl. hintereinander gespielter
Noten (sukzessiv) bestimmen. Die Vorgehensweise ist bei beiden Varianten grundsätzlich gleich.
Im ersten Schritt müssen zunächst die zu untersuchenden Noten bestimmt werden, und es
muss festgelegt werden, welche der beiden Noten die untere und welche die obere Note ist.
Danach werden die zwei Abstandsdefinitionen angewendet, die das Intervall exakt bestimmen
(d. h. chromatischer und diatonischer Abstand). Für die Akkordbestimmung ist insbesondere
Intervallbestimmung
103
die simultane Betrachtung von Bedeutung, weshalb hier exemplarisch das Intervall zwischen
zwei gleichzeitig erklingenden Noten bestimmt wird.
Im ersten Schritt werden mit Hilfe der Sicht NotesInfoAtTime alle benötigten Informationen
bzgl. der zeitgleich erklingenden Noten zusammengestellt. Sowohl für die Bestimmung des
Basstons als auch für die darauf aufbauende Intervallbestimmung wird die chromatische
Darstellungsform der Note benötigt. Sie läßt sich nicht direkt aus der Score-Tabelle auslesen.
Für die Berechnung wird NotesAtTime, die auf Score basiert, mit der Tabelle Note über die
Attribute diatonic und alter verknüpft. Desweiteren wird zusätzlich die absolute Tonhöhe
berechnet und als Attribute chromaticAbs und diatonicAbs in der Sicht beschrieben.
-- NotesInfoAtTime -SELECT
N . diatonic , N . alter , N . octave ,
Note . chromatic , Note . id , Note . name ,
( N . octave * 12 + N . chromatic )
( N . octave *
FROM
AS chromaticAbs ,
7 + Note . diatonic ) AS diatonicAbs
NotesAtTime AS N INNER JOIN Note
ON Note . diatonic = N . diatonic AND
Note . alter
= N . alter ;
Für die Bestimmung des Basstons wird der minimale absolute Notenwert (chromaticAbs)
berechnet und in der entsprechende Ton in einer eigenen Sicht NoteBassAtTime gespeichert,
so dass eine Verwendung auch in anderen Anfragen möglich ist.
-- NoteBassAtTime -SELECT DISTINCT *
FROM
NotesInfoAtTime
WHERE
chromaticAbs = ( SELECT DISTINCT MIN ( chromaticAbs )
FROM NotesInfoAtTime ) ;
Im nächsten Schritt werden die diatonischen und chromatischen Abstände zum Basston
bestimmt. Ist der Basston bspw. die Note d (diatonic=1), so ist der Abstand zum darüber
liegenden f (diatonic=3) gleich 2. Eine analoge Berechnung wird auch für den chromatischen
Abstand durchgeführt. Falls gewünscht, können die Abstände an dieser Stelle auf eine Oktave
normiert werden. Dafür müssen die entsprechenden Werte Modulo 12 (chromatic) bzw. Modulo
7 (diatonic) gerechnet werden.
Die folgende SQL-Anfrage berechnet die Abstände für alle zu einem Zeitpunkt klingenden
Noten. Der Basston wird herausgefiltert, da er immer den Abstand 0 besitzt und für die
weitere Betrachtung nicht von Bedeutung ist.
104
Harmonische Analyse mit SQL
-- No t e s Di f f Ba s s At T i me -SELECT Info .* ,
( Info . diatonicAbs
- Bass . diatonicAbs )
AS diatonicDiff ,
( Info . chromaticAbs - Bass . chromaticAbs ) AS chromaticDiff ,
FROM
NoteBassAtTime INNER AS Bass JOIN NotesInfoAtTime AS Info
ON Bass . chromaticAbs <> Info . chromaticAbs
Schließlich werden die errechneten Informationen über die Abstände mit der Tabelle Interval verknüpft, um eine wirkliche Darstellung als Intervall zu repräsentieren. Für weitere
Verwendungen sind die Noteninformationen weiterhin enthalten.
-- In t e r va l s Ba s s At T i me -SELECT Interval . diatonic , Interval . chromatic , Interval . spec
N ot e s D if f B as s A tT i m e .*
FROM
Interval INNER JOIN N ot e s Di f f Ba s s At T i me
ON Interval . diatonic
= N ot e s Di f f Ba s s At T i me . diatonicDiff AND
Interval . chromatic = N o t es D i f fB a s sA t T im e . chromaticDiff ;
Um weitere Informationen bzgl. der Intervalle zu erhalten (z. B. den Namen), reicht es aus,
diese Sicht mit den IntervalDiatonic- und IntervalSpec-Tabellen zu verknüpfen.
-- I n t e r v a l B a s s N a m e s A t T i m e -SELECT IntervalDiatonic . name , IntervalSpec . name
FROM
( I nt e r va l s Ba s s At T i me INNER JOIN IntervalDiatonic
ON I nt e r va l s Ba s s At T i me . diatonic = IntervalDiatonic . diatonic )
INNER JOIN IntervalSpec
ON In t e rv a l sB a s sA t T i me . spec = IntervalSpec . spec )
5.3 Akkordbestimmung
In diesem Abschnitt wird eine Akkordbestimmung mit der ScoreStore-Datenbank und darauf
arbeitender SQL-Anfragen durchgeführt. Die Bestimmung wird exemplarisch anhand von
Dreiklängen vorgestellt. Die Unterschiede bei Mehrklangsbestimmungen (z. B. Vier- und
Fünfklänge) werden an geeigneter Stelle erläutert. Die Dreiklangsbestimmung wird an dem
aus den vorhergehenden Abschnitten bekannten Beispiel erklärt. Hier wird der Dreiklang an
zweiter Position im dritten Takt der Partitur aus Abbildung 5.2 bestimmt.
In der Chord3 -Tabelle wird jeder Dreiklangstyp (z. B. Moll) in drei Tupeln repräsentiert.
Jedes Tupel beschreibt dabei eine Stellung des Zusammenklangs, welche durch zwei Intervalle
(zwischen Basston und den darüber liegenden Tönen) eindeutig bestimmt wird. Die in diesem
Akkordbestimmung
105
Abschnitt beschriebene Akkordbestimmung untersucht genau diese Notenbeziehungen, so dass
eine exakte Identifizierung des Akkordtyps möglich ist. Der Grundton des Akkordes lässt sich
dann anhand der erkannten Stellung bestimmen. Bei der Grundstellung entspricht der Grundton
dem Basston, bei der ersten Umkehrung dem obersten Ton und bei der zweiten Umkehrung
schließlich dem ersten Ton oberhalb des Basstons. Um einen Dreiklang zu bestimmen, werden
folgende Schritte durchgeführt:
1. Bestimmung aller zu einem gegebenen Zeitpunkt t gleichzeitig erklingenden Töne (siehe
Abschnitt 5.1). Im betrachteten Beispiel handelt es sich dabei um die Töne d, f, a, d.
2. Bestimmung des Basstons, der als Basis für die folgende Dreiklangsbestimmung dient
(siehe Abschnitt 5.2). Zum gesuchten Zeitpunkt im vorliegenden Ausschnitt wird die Note
d als tiefster Ton identifiziert.
3. Für die Untersuchung der Intervallbeziehungen bei der Akkordbestimmung werden die
Töne in sog. enger Lage benötigt. Das bedeutet, dass sie ausgehend vom Basston der
Tonhöhe nach sortiert werden, so dass kein weiterer Ton des betrachteten Dreiklangskandidaten dazwischen liegt. Noten, die bspw. in der Reihenfolge g – e – c vorkommen,
werden in die neue Reihenfolge g – c – e gebracht.
Die Sortierung der Noten wird durch Eingrenzung des Abstands vom Basston auf eine
Oktave erreicht. Ein Nonenabstand wird so bspw. zu einer Sekunde. Für Drei- und Vierklänge ist diese Kodierung bereits ausreichend, da die in Terzen geschichteten Akkordtöne
innerhalb eines Oktavbereiches aufgebaut werden können (z. B. der Vierklang (c – e – g
– h)) und der größte vorkommende Abstand ein Septimintervall ist. Werden aber bspw.
in Terzen geschichtete Fünfklänge betrachtet, so reicht ein Oktavbereich nicht mehr aus
(z. B. c – e – g – h – d ). Damit auch diese Mehrklänge bestimmt werden können, wird
nach der Eingrenzung auf Oktavabstand ein weiterer Arbeitsschritt durchgeführt.
Bei Fünklängen bspw. in Grundstellung liegt der oberste Ton mehr als eine Oktave über
dem Basston, genauer gesagt im Nonenabstand. Durch Eingrenzung auf eine Oktave liegt
dieser nun eine Sekunde über dem Basston, wodurch sich die Akkordtöne nicht mehr
in Terzschichtung befinden. Diese kann nur wieder hergestellt werden, wenn alle Töne,
die diese Bedingung verletzen, eine Oktave nach oben verschoben werden. Mit diesem
Verfahren können Mehrklänge bestehend aus bis zu sieben Tönen behandelt werden.
Die Eingrenzung auf einen Oktavbereich geschieht durch Modulo-7- bzw. Modulo-12Berechnungen auf den diatonischen bzw. chromatischen Abständen zum Basston. Die
Terzschichtung wird überprüft, indem berechnet wird, ob der diatonische Abstand gerade
106
Harmonische Analyse mit SQL
oder ungerade ist. Falls er ungerade ist, ist die Terzschichtung ungültig, und der betroffene
Ton wird um eine Oktave nach oben verschoben.
Zusätzlich werden Duplikate eliminiert, die durch Verdopplung von Dreiklangstönen
entstehen können, aber für die Akkordbestimmung nicht relevant sind.
-- N o t e s H a r m o D i f f B a s s A t T i m e -SELECT DISTINCT
IIF ( Diff . diffDiatonic MOD 7 MOD 2 = 0 ,
Diff . diffDiatonic MOD 7 ,
Diff . diffDiatonic MOD 7 + 7) AS harmoDiatonic ,
IIF ( Diff . diffDiatonic MOD 7 MOD 2 = 0 ,
Diff . diffChromatic MOD 12 ,
Diff . diffChromatic MOD 12 + 12) AS harmoChromatic ,
Diff . name
FROM N ot e s Di f f Ba s s At T i me AS Diff ;
Im vorliegenden Beispiel befindet sich an der betrachteten Position ein Dreiklang in der
Grundstellung, weshalb hier die Kodierung durch harmoDiatonic = (0 (d), 2 (f ), 4(a))
und harmoChromatic = (0, 4, 7) bestimmt wird.
4. Nach der Intervallbestimmung (bzw. der diatonischen und chromatischen Abstände) kann
schließlich auch der Dreiklang mit Hilfe der Chord3 -Tabelle bestimmt werden. Durch
die Verknüpfung der Chord3 -Tabelle mit den zwei berechneten Intervallen über die
zugehörigen Intervallabstände (diatonic und chromatic) lässt sich die Akkordstellung
ermitteln. Das Geschlecht des Akkordes ist ebenfalls in der Chord3 -Tabelle gespeichert
und kann mittels der ChordMood -Tabelle auf den eigentlichen Namen des Geschlechts
abgebildet werden. Der folgende SQL-Code bestimmt schließlich den Dreiklang zum
gegebenen Zeitpunkt.
-- Chord3AtTime -SELECT IIF ( inversion = 0 ,
( SELECT name FROM NoteBassAtTime ) ,
IIF ( inversion = 1 ,
Harmo2 . name ,
Harmo1 . name ) ) AS root ,
( SELECT name FROM ChordMood
WHERE chordMood = Chord3 . chordMood ) AS chordMood
FROM
( Chord3 INNER JOIN N o t e H a r m o D i f f B a s s A t T i m e AS Harmo1
ON Chord3 . chromatic1 = Harmo1 . harmoChromatic AND
Chord3 . diatonic1
= Harmo1 . harmoDiatonic )
Funktions- und Stufenbestimmung
107
INNER JOIN N o t e H a r m o D i f f B a s s A t T i m e AS Harmo2
ON Chord3 . chromatic2 = Harmo2 . harmoChromatic AND
Chord3 . diatonic2
WHERE
= Harmo2 . harmoDiatonic
Harmo1 . harmoDiatonic = ( SELECT MAX ( harmoDiatonic )
FROM N o t e H a r m o D i f f B a s s A t T i m e )
AND
Harmo2 . harmoDiatonic = ( SELECT MAX ( harmoDiatonic )
FROM N o t e H a r m o D i f f B a s s A t T i m e ) ;
Das betrachtete Beispiel wird auf ein Chord3 -Tupel abgebildet, das einen Dreiklang in
der Grundstellung mit Mollgeschlecht repräsentiert. Im SELECT-Teil der SQL-Anweisung
werden die geforderten Informationen schließlich konkretisiert und ein d-Moll Dreiklang
erkannt. Das Attribut root beschreibt dabei den Grundton des Akkordes, während
chordMood das Geschlecht beschreibt.
In Abbildung 5.3 sind die für Intervalle und Akkorde verwendeten Sichten und die ihnen zu
Grunde liegenden Tabellen dargestellt. Ein Pfeil steht dabei für eine direkte Abhängigkeit von
der jeweiligen Sicht oder Tabelle, also ob sie im FROM-Teil der SQL-Anfrage benutzt wird.
Die Tabellen sind gelb markiert, Sichten sind in grau gezeichnet.
5.4 Funktions- und Stufenbestimmung
Das Auseinandersetzen mit den Beziehungen zwischen Harmonien in einem Musikwerk gehört
zur Hauptaufgabe einer harmonischen Analyse. Notwendige Voraussetzung für die Bestimmung der Stufen bzw. Funktionen von Akkorden (nach Stufen- und Funktionstheorie) ist die
Kenntnis über die Tonart und damit auch über die zugehörige Tonleiter. Desweiteren wird
eine Bestimmung der im Musikwerk vorkommenden Harmonien benötigt (siehe Kapitel 2.2).
Der in den vorherigen Abschnitten als Beispiel verwendete Ausschnitt aus der Winterreise
von Franz Schubert ist in d-Moll geschrieben. Da in der ScoreStore-Datenbank ebenfalls die
Grundtonart des betrachteten Werkes gespeichert ist (ScoreContext-Tabelle), lässt sich hierbei
die Stufe 1, d. h. die Tonikafunktion der Harmonie, leicht ermitteln.
Bei den bisherigen Untersuchungen wurden ein bzw. mehrere Zeitpunkte eines Musikwerkes
als gegeben vorausgesetzt und bzgl. bestimmter Aspekte untersucht. Es ist aber auch der
umgekehrte Fall möglich, bei dem eine Note, ein Intervall, ein Akkord usw. vorgegeben wird,
und im Musikwerk nach allen Zeitpunkten gesucht werden soll, an denen das gesuchte Ereignis
auftritt.
108
Harmonische Analyse mit SQL
NotesAtTime
Score
TimesInBar
NoteNamesAtTime
Note
RankInBar
NotesInfoAtTime
PosInBarToTime
NoteBassAtTime
NotesAtPosInBar
NotesDiffBassAtTime
TimesInScore
IntervalsBassAtTime
Interval
NotesAtAllTimes
IntervalSpec
IntervalBassNamesAt
Time
IntervalDiatonic
NotesHarmoDiffBassAt
Time
Chord3AtTime
Chord3
Abbildung 5.3: Für Intervalle und Akkorde verwendete Sichten und zu Grunde liegende Tabellen.
Ein Pfeil steht für eine direkte Abhängigkeit von der jeweiligen Sicht oder Tabelle, also ob sie im
FROM-Teil der SQL-Anfrage benutzt wird. Die Tabellen sind gelb markiert, Sichten sind in grau
gezeichnet.
Funktions- und Stufenbestimmung
109
In diesem Abschnitt soll daher beispielhaft, ausgehend von der Tonart d-Moll, die Menge aller
Zeitpunkte bestimmt werden, zu denen ein Tonika-Akkord im Werk Winterreise von Franz
Schubert vorkommt. In komplexen Musikwerken (dazu gehört auch das betrachtete Beispiel)
stellt die Tonart allerdings keinen konstanten Musikparameter dar. Diese kann im Verlauf des
Werkes für kurze oder längere Abschnitte in andere Tonarten ausweichen (siehe Kapitel 2.2.5).
Diese sog. Modulationen sind stark kontextabhängig und in den meisten Fällen nur schwer
erkennbar, so dass weder eine automatische Bestimmung des Modulationsbereiches, noch die
eindeutige Identifizierung der Tonart möglich ist. Unter diesen Voraussetzungen kann daher
keine vollständig automatisierte Funktionsbestimmung der Harmonien durchgeführt werden.
In einem weiteren Abschnitt wird deshalb genauer auf dieses Thema eingangen.
5.4.1 Bestimmung mit gegebener Grundtonart
In diesem Abschnitt sollen alle möglichen Zeitpunkte (d. h. Zeitpunkte, an denen mindestens
eine Note angeschlagen wird) bestimmt werden, zu denen eine gewünschte Akkordfunktion
vorkommt. Beispielhaft soll im Werk Winterreise von Franz Schubert (Winterreise d 911,
Satz 1) der Tonikaakkord gesucht werden. Dieses Werk steht, wie eingangs erwähnt, in d-Moll,
wobei zwischendurch ein durch Vorzeichnung gekennzeichneter Tonartwechsel nach D-Dur
stattfindet.
Für die Suche aller Zeitpunkte ist es ausreichend, die Dreiklangstöne der gesuchten Harmonie
zu bestimmen und diese jeweils exakt mit den zu allen Zeitpunkten vorkommenden Tönen zu
vergleichen. Die Ergebnismenge bilden alle Zeitpunkte, zu denen genau diese Töne erklingen.
Da im Musikwerk Bereiche mit unterschiedlichen Tonarten vorkommen, müssen zu diesen
jeweils andere Akkordtöne bestimmt werden, nach denen dann in dem Bereich gesucht wird.
Die Durchführung dieser Aufgabe mit Hilfe der ScoreStore-Datenbank lässt sich grob in drei
Schritte unterteilen, die im weiteren Verlauf dieses Abschnitts näher erläutert werden.
1. Bestimmung der Akkordtöne des Dreiklangs bzgl. der gewählten Funktion und der im
Musikwerk vorhandenen Grundtonarten (d. h. Akkordtöne pro Grundtonart-Bereich).
2. Bestimmung der unterschiedlichen Noten zu allen möglichen Zeitpunkten (ähnlich wie im
Abschnitt 5.3).
3. Suche der (für die jeweiligen Bereiche) im ersten Schritt bestimmten Akkordtöne in der
Menge der unterschiedlichen Noten pro Zeitpunkt.
110
Harmonische Analyse mit SQL
Bestimmung der Akkordtöne
Für die Bestimmung der Akkordtöne werden die Tabellen ScoreContext, Scale, Note, ChordFunction und Chord3 benötigt. Davon ausgehend soll eine Sicht definiert werden, welche zu
jedem Grundtonart-Zeitbereich die zugehörigen Akkordtöne der gegebenen Funktion enthält.
Dazu werden als erstes die exakten Zeitbereiche ausgehend von ScoreContext-Informationen
extrahiert. In weiteren Schritten werden die Gebrauchstonleitern und die dazugehörigen Stufen
bestimmt, bevor schließlich die Akkordtöne zu den jeweiligen Bereichen berechnet werden
können.
Im ersten Schritt werden die exakten Zeitbereiche des Vorkommens der unterschiedlichen
Grundtonarten (in der Partitur durch die Vorzeichnung gekennzeichnet) bestimmt. Die Tonarten sind werkübergreifende Informationen und daher in der ScoreContext-Tabelle durch
die Attribute fifths (Vorzeichnung) und keyMood (Tonartgeschlecht) angegeben, wobei das
letzte Attribut manuell hinzugefügt wurde (siehe Kapitel 6). Das Attribut time legt dabei den
Anfang des Geltungsbereiches dieser Kontextinformationen fest. Mit Hilfe der Sicht ScoreContextInPeriods werden die exakten Zeitbereiche durch die Attribute time und zusätzlich
endTime bestimmt. Die Informationen der ScoreContext-Tabelle sind ebenfalls vollständig in
dieser Sicht erhalten. Sie baut auf der Sicht ScoreDuration auf (siehe dazu Abbildung 5.4 auf
Seite 117).
ScoreDuration filtert aus Score die letzten Ereignisse heraus und bestimmt die Länge des
Musikwerkes dadurch, in dem ausgehend von diesen das Ereignis mit der größten Dauer
(duration) selektiert wird. Von time wird ebenfalls erneut das Maximum genommen, da zur
Speicherung in dem Attribut length auf alle bestimmenden Werte eine Aggregatfunktion
angewendet werden muss.
-- ScoreDuration -SELECT ( MAX ( duration ) + MAX ( time ) ) AS length
FROM
Scores
WHERE
time = ( SELECT MAX ( time )
FROM
Scores ) ;
ScoreContextInPeriods verknüpft ScoreContext mit sich selbst (SC und SC2 ), um zu jedem
Startzeitpunkt auch den Endzeitpunkt des Bereichs zu ermitteln. Hierzu werden alle Tupel
verknüpft, deren Startzeitpunkt größer als der betrachtete ist. Von diesen ist der kleinste
Zeitpunkt minus 1 der Endzeitpunkt des betrachteten Bereichs. Für den letzten Bereich liegt
kein größerer Startzeitpunkt vor. Daher wird an dieser Stelle mit Hilfe von ScoreDuration die
Länge des Werkes benutzt.
Funktions- und Stufenbestimmung
111
-- S c o r e C o n t e x t I n P e r i o d s -( SELECT
SC . time
MIN ( SC2 . time - 1) AS endTime ,
SC . fifths , SC . beats , SC . beatType , SC . divisions , SC . keyMood
FROM
ScoreContext AS SC INNER JOIN ScoreContext AS SC2
ON SC . time < SC2 . time
GROUP BY SC . time , SC . fifths , SC . beats , SC . beatType , SC . divisions ,
SC . keyMood
)
UNION
( SELECT
SC . time ,
SD . length AS endTime ,
SC . fifths , SC . beats , SC . beatType , SC . divisions , SC . keyMood
FROM
ScoreContext AS SC ,
ScoreDuration AS SD
WHERE
SC . time = ( SELECT MAX ( time ) FROM ScoreContext )
);
Aufbauend auf dem ersten Schritt und der zusätzlichen Verwendung der Tabellen Scale
(Tonleitertöne abhängig von Vorzeichen), Key (Zuordnung von Vorzeichen und Geschlecht zu
Grundton der Tonleiter) und Note werden zu allen Bereichen die Tonleiternoten bestimmt.
Zusätzlich wird eine Sortierung der Tonleitertöne ausgehend vom Grundton vorgenommen
(ScalesSortedInPeriods).
Durch Verknüpfung der Tabelle Key mit der Scale-Tabelle über den Primärschlüssel fifths
lassen sich alle möglichen Tonleiternoten bestimmen, welche durch die Sicht ScoreContextInPeriods über die dort ebenfalls enthaltenen Attribute fifths und keyMood konkretisiert werden.
Der Grundton ist als Attribut root in der Key-Tabelle gespeichert. Damit lassen sich die
Tonleitertöne in eine bzgl. des Grundtons richtige Reihenfolge bringen, so dass sie den Stufen
aus der Stufentheorie entsprechen. Bei der Berechnung der Sortierung werden alle Noten um
sieben diatonische Stufen erhöht, damit die Modulo-Berechnung immer ein positives Ergebnis
hat.
112
Harmonische Analyse mit SQL
-- S c a l e s S o r t e d I n P e r i o d s -SELECT SC . time ,
SC . endTime ,
Scale .* ,
Key . keyMood AS keyMood ,
( Scale . diatonic - Note . diatonic + 7) MOD 7) AS scaleOrder
FROM
S c o r e C o n t e x t I n P e r i o d s AS SC
INNER JOIN
(( Key
INNER JOIN Scale
ON Key . fifths = Scale . fifths )
INNER JOIN Note
ON Key . root = Note . id )
ON SC . fifths = Key . fifths
WHERE
Key . keyMood = SC . keyMood ;
Ausgehend von der Sicht (ScalesSortedInPeriods) lassen sich nun auch die Akkordtöne berechnen. Dazu werden allerdings zunächst noch die Intervalle bzgl. der gegebenen Akkordfunktion
ausgehend vom Grundton der Harmonie benötigt, mittels dieser schließlich die Dreiklangstöne
bestimmt werden können. Bei der Tonikafunktion handelt es sich im betrachten Beispiel im
ersten Zeitbereich um einen d-Moll-Dreiklang. Ein Moll-Dreiklang besteht, ausgehend vom
Grundton (d. h. Akkord in der Grundstellung: inversion = 0) aus den Intervallen kleine Terz
(Interval.diatonic = 2 und Interval.chromatic = 3) und einer reinen Quinte (Interval.diatonic
= 4 und Interval.chromatic = 7).
Die Intervalle zu allen Stufen einer Tonleiter lassen sich mit Hilfe der Tabellen ChordFunction
(Zuordnung von Tonnummer und Tonartgeschlecht) und Chord3 bestimmen. Zusätzlich zu
den Intervallattributen und der Stufenposition muss auch das Attribut keyMood (Tonartgeschlecht) der ChordFunction-Tabelle mitgeführt werden, damit die Akkordtöne bzgl. des
richtigen Tonartgeschlechts bestimmt werden. Die Tonikafunktion bei Moll-Tonarten ist bspw.
ein Moll-Dreiklang, während sie bei Dur-Tonarten ein Dur-Dreiklang ist. In der Sicht ChordIntervalsAtFunction werden diesbezüglich alle Informationen zusammengestellt.
-- C h o r d I n t e r v a l s A t F u n c t i o n -SELECT ChordFunction . scaleOrder , ChordFunction . keyMood ,
Chord3 . diatonic1 , Chord3 . chromatic1 ,
Chord3 . diatonic2 , Chord3 . chromatic2
FROM
Chord3 INNER JOIN ChordFunction
ON Chord3 . chordMood = ChordFunction . chordMood
WHERE
Chord3 . inversion = 0;
Funktions- und Stufenbestimmung
113
Für die Berechnung der Akkordtöne mittels der Intervalle wird die diatonische und chromatische Notendarstellung benötigt. Da die Sicht ScalesSortedInPeriods diesbezüglich nur das
Notenattribut diatonic enthält, muss sie zusätzlich mit der Note-Tabelle verknüpft werden,
um die chromatische Darstellung zu erhalten. Dies geschieht mit Hilfe der Sicht ChordRootsAtFunction.
-- C h o r d R o o t s A t F u n c t i o n -SELECT SC . time , SC . endTime ,
SC . diatonic , Note . chromatic ,
SC . keyMood , SC . scaleOrder
FROM
S c a l e s S o r t e d I n P e r i o d s AS Scales INNER JOIN Note
ON Scales . alter
= Note . alter AND
Scales . diatonic = Note . diatonic ;
Mit Hilfe der Sichten ChordIntervalsAtFunction und ChordRootsAtFunction und einer gegebenen Akkordfunktion lassen sich schließlich zu allen Bereichen die gesuchten Akkordtöne
bestimmen. Die Sichten werden dabei über die Attribute scaleOrder und keyMood verknüpft,
so dass die richtigen Intervalle zur Bestimmung der Akkordtöne selektiert werden. Das scaleOrder -Attribut wird dabei auf die gewünschte Funktion (z. B. Tonika) gesetzt. Zur Berechnung
der Akkordtöne werden jeweils die diatonischen und chromatischen Intervallabstände zu
den Grundtönen der Akkorde addiert. Die Grundtöne selbst sind aus den entsprechenden
Tonleiterstufen bekannt.
-- C h o r d N o t e s A t F u n c t i o n -SELECT CF . time , CF . endTime ,
CF . diatonic , CF . chromatic ,
(( CF . diatonic
+ CI . diatonic1 )
MOD 7)
AS diatonic1 ,
(( CF . chromatic + CI . chromatic1 ) MOD 12) AS chromatic1 ,
(( CF . diatonic
+ CI . diatonic2 )
MOD 7)
AS diatonic2 ,
(( CF . chromatic + CI . chromatic2 ) MOD 12) AS chromatic2
FROM
C h o r d I n t e r v a l s A t F u n c t i o n AS CI
INNER JOIN
C h o r d R o o t s A t F u n c t i o n AS CF
ON CI . keyMood
= CF . keyMood AND
CI . scaleOrder = CF . scaleOrder
WHERE
CF . scaleOrder = [ Function ( Number starting at 0) ];
Die Sicht ChordNotesAtFunction beschreibt jeweils in einem Tupel die zu einem Zeitbereich
gehörenden Noten (diatonic1, chromatic1 und diatonic2, chromatic2 ). Um eine einfachere
Bestimmung aller Zeitpunkte, die diese Akkorde enthalten, zu ermöglichen, werden die Noten
114
Harmonische Analyse mit SQL
in die durch das Attribut id der Tabelle Note gegebene eindeutige Darstellungsform konvertiert.
Zudem werden die innerhalb eines Tupels gespeicherten Akkordtöne getrennt und jeweils durch
ein Tupel bestehend aus dem Zeitbereich (time und endTime) und einem Akkordton (NoteId )
beschrieben.
-- C h o r d N o t e s S p l i t A t F u n c t i o n -( SELECT CF . beginTime , CF . endTime , Note . id AS noteId
FROM
C h o r d N o t e s A t F u n c t i o n AS CF INNER JOIN Note
ON CF . diatonic
= Note . diatonic AND
CF . chromatic = Note . chromatic
)
UNION
( SELECT CF . beginTime , CF . endTime , Note . id AS noteId
FROM
C h o r d n o t e s A t F u n c t i o n AS CF INNER JOIN Note
ON CF . diatonic1
= Note . diatonic AND
CF . chromatic1 = Note . chromatic
)
UNION
( SELECT CF . beginTime , CF . endTime , Note . id AS noteId
FROM
C h o r d n o t e s A t F u n c t i o n AS CF INNER JOIN Note
ON CF . diatonic2
= Note . diatonic AND
CF . chromatic2 = Note . chromatic
);
Im betrachten Beispiel sind insgesamt drei Zeitbereiche gefunden worden (d-Moll, D-Dur und
d-Moll). Die dazu gehörenden Tonika-Akkordtöne stellen bei d-Moll die Töne (d, f, a) und bei
D-Dur (d, fis, a) dar.
Bestimmung unterschiedlicher Noten
Im Gegensatz zu den Erklärungen über die Bestimmung von Akkorden (siehe Abschnitt 5.3),
wo ein Zeitpunkt gegeben war, zu denen der Akkord mit Tönen und zusätzlichen Informationen
exakt bestimmt werden sollte, sind hier die Akkordtöne zu einer gesuchten Funktion bereits
gegeben. Die Aufgabe besteht nun noch darin, alle Zeitpunkte im Werk zu bestimmen, an
denen exakt diese Töne vorkommen. Verdopplungen von Tönen sind hierbei ausgenommen.
Beispielsweise ist der Akkord c’, e’, g’, c” tatsächlich ein c-Dur-Dreiklang in Grundstellung,
der bei der Suche gefunden werden muss.
Ausgegangen wird von der Sicht NotesAtAllTimes, die zu allen Zeitpunkten im Werk die klingenden Noten enthält (siehe 5.1). Da hier ebenfalls zusätzliche Noteninformationen (z. B. die
Funktions- und Stufenbestimmung
115
id der Note) benötigt werden, wird analog zu Abschnitt 5.3 eine weitere Sicht (NotesInfoAtAllTimes) definiert, die alle diese Informationen beschreibt. Zwar werden nicht alle Informationen
im weiteren Verlauf der Anfrage benötigt, aber durch diese allgemeine Definition lässt sich die
Anfrage auch in anderen Zusammenhängen verwenden (z. B. bei der Akkordbestimmung).
-- No t e s In f o At A l lT i m es -SELECT N . time ,
N . diatonic , N . alter , N . octave ,
Note . chromatic , Note . id , Note . name ,
( N . octave * 12 + N . chromatic )
( N . octave *
FROM
AS chromaticAbs ,
7 + Note . diatonic ) AS diatonicAbs
NotesAtAllTimes AS N INNER JOIN Note
ON Note . diatonic = N . diatonic AND
Note . alter
= N . alter ;
Aufbauend auf dieser Sicht lassen sich schließlich zu allen möglichen Zeitpunkten alle unterschiedlichen Tonhöhen durch die Sicht NoteDistinctAtAllTimes bestimmen. Erreicht wird dies
dadurch, dass bzgl. die relative Tonhöhe innerhalb einer Oktave beschreibender Attribute
gruppiert wird und innerhalb der jeweiligen Gruppe die Note mit der minimalen Tonhöhe
berechnet wird.
-- N o t e s D i s t i n c t A t A l l T i m e s -SELECT
N . time , N . diatonic , N . alter , N . chromatic , N . id , N . name ,
MIN ( N . chromaticAbs ) AS chromaticAbs ,
MIN ( N . diatonicAbs )
FROM
AS diatonicAbs
N ot e s In f o At A l lT i m es AS N
GROUP BY N . time , N . diatonic , N . alter , N . chromatic , N . id , N . name ;
Um die Ergebnismenge für die weitere Verarbeitung einzugrenzen, werden nur diejenigen
Tupel selektiert, welche genau drei unterschiedliche Noten (wie ein Dreiklang) enthalten (d. h.
vervielfachte Töne in der gleichen oder anderen Oktaven werden hier schon entfernt). Dazu
wird zunächst für jeden Zeitpunkt die Anzahl der Töne aus der Sicht NotesDistinctAtAllTimes
gezählt und alle Zeitpunkte entfernt, zu denen nicht genau drei unterschiedliche Töne klingen.
-- T i m e s N o t e s D i s t i n c t 3 A t A l l T i m e s -SELECT
time
FROM
NotesDistinctAtAllTimes
GROUP BY time
HAVING
COUNT ( id ) = 3;
Schließlich wird zu diesen Zeitpunkten erneut die Noteninformation verknüpft. Zudem wird
auf die bzgl. der Gesamtaufgabe relevanten Attribute projiziert (time und id ).
116
Harmonische Analyse mit SQL
-- N o t e s D i s t i n c t 3 A t A l l T i m e s -SELECT ND . time , ND . id
FROM
N o t e s D i s t i n c t A t A l l T i m e s AS ND
INNER JOIN
T i m e s N o t e s D i s t i n c t 3 A t A l l T i m e s AS TND
ON ND . time = TND . time ;
Bestimmung aller Zeitpunkte zur Akkordfunktion
Für die Bestimmung aller Zeitpunkte, zu denen ein Akkord mit der gegebenen Funktion
vorkommt, wird nur noch eine Anfrage benötigt, welche die im ersten und zweiten Schritt
gewonnenen Informationen zusammensetzt. Die Sicht NotesDistinct3AtAllTimes enthält die
Information über die unterschiedlichen Tonhöhen im Musikwerk zu allen Zeitpunkten mit drei
unterschiedlichen Noten, während die Sicht ChordNotesSplitAtFunction alle Zeitbereiche mit
den zu suchenden Noten enthält. Durch Verknüpfung dieser beiden Sichten über das Attribute
id für die Note erhält man als Ergebnis alle Zeitpunkte von NotesDistinct3AtAllTimes, zu
denen mindestens eine beliebige id gleich der in der Sicht ChordNotesSplitAtFunction ist. Um
diese Verknüpfung einzuschränken, wird für jeden Zeitpunkt geprüft, in welchem Zeitbereich er
sich befindet. Um schließlich zu gewährleisten, dass alle drei Akkordtöne zu einem Zeitpunkt
vorkommen, werden die Tupel der Ergebnismenge bzgl. des Zeitpunkts gezählt und nur
diejenigen aufgenommen, welche genau drei Noten enthalten.
-- FunctionAtTimes -SELECT
N . time
FROM
N o t e s D i s t i n c t 3 A t A l l T i m e s AS N
INNER JOIN
C h o r d N o t e s S p l i t A t F u n c t i o n AS C
ON N . id = C . noteId
WHERE
N . time BETWEEN C . time AND C . endTime
GROUP BY N . time
HAVING
COUNT ( N . id ) =3;
117
Funktions- und Stufenbestimmung
NotesAtAllTimes
Score
ScoreDuration
ScoreContext
ScoreContextInPeriods
Key
ScalesSortedInPeriods
Scale
NotesInfoAtAllTimes
Note
ChordRootsAt
Function
NotesDistinctAtAllTimes
ChordFunction
ChordIntervalsAt
Function
Chord3
TimesNotesDistinct3AtAll
Times
ChordNotesAtFunction
NotesDistinct3AtAllTimes
ChordNotesSplitAt
Function
FunctionAtTimes
Abbildung 5.4: Für die Funktionsbestimmung von Akkorden verwendete Sichten und zu Grunde
liegende Tabellen. Ein Pfeil steht für eine direkte Abhängigkeit von der jeweiligen Sicht oder
Tabelle, also ob sie im FROM-Teil der SQL-Anfrage benutzt wird. Die Tabellen sind gelb markiert,
Sichten sind in grau gezeichnet. Grün gekennezeichnet ist die NotesAtAllTimes-Sicht, die mit ihren
Beziehungen bereits in Abbildung 5.3 dargestellt ist.
118
Harmonische Analyse mit SQL
5.4.2 Unbekannte Tonart und Tonartwechsel
Grundvoraussetzung für die Funktionsbestimmung von Akkorden ist das Wissen über die
aktuelle Tonart, die durch die Vorzeichnung und das Tonartgeschlecht eindeutig definiert
ist. In Partituren wird in der Regel nur die Vorzeichnung angegeben, die Kennzeichnung des
Geschlechts bleibt aus. Damit ist der rein visuelle Inhalt von Partituren für die vollständige
Durchführung der harmonischen Analyse nicht ausreichend. Die Funktionsbestimmung der
Akkorde, wie sie im vorherigen Abschnitt beschrieben wurde, ist in dieser Form nur dann
möglich, wenn zuvor das Tonartgeschlecht bestimmt wird und als zusätzliches Attribut in der
Tabelle ScoreContext abgespeichert wird.
Im Folgenden Abschnitten wird zunächst die Problematik bei der Bestimmung der Tonarten
und Modulationen diskutiert. In einem weiteren Abschnitt werden schließlich mögliche Ansätze
vorgestellt, die eine harmonische Analyse trotz nicht angegebener und damit unbekannter
Tonart ermöglichen.
Problemstellung
Die Tonart eines Musikwerkes ist eine werkübergreifende Information, die in Partituren
meistens nur durch Vorzeichnung ohne Angabe des Tonartgeschlechts gekennzeichnet ist.
Für die Funktionsbestimmung von Akkorden ist aber auch das Tonartgeschlecht zwingend
erforderlich, weshalb eine Bestimmung notwendig ist.
Die Bestimmung des Tonartgeschlechts ist allerdings eine große Herausforderung. Aus den zur
Verfügung stehenden Partiturinformationen kann es nicht einfach abgelesen werden, und es ist
nicht ausreichend, nur bestimmte Stellen in der Partitur zu betrachten. Dafür ist der gesamte
Inhalt relevant, da es zur Tonartuntersuchung kein eindeutiges Regelwerk gibt, an das sich alle
Komponisten halten. Es gibt zwar gewisse Anhaltspunkte, die auf das Geschlecht hinweisen,
wie z. B. dass der letzte Ton des Werkes den Grundton der Tonart bildet. Diese Annahme
ist jedoch häufig nicht erfüllt, so dass eine Bestimmung der Tonart aufgrund dieser Tatsache
zusammen mit der Vorzeichnung nicht ausreichend ist. Da sich Dur- und Moll-Tonarten vom
Klang her unterscheiden (fröhlich, traurig), würde ein Abspielen des Werkes vermutlich schon
ausreichend sein, um das Geschlecht und somit auch die Tonart durch das Hören zu bestimmen.
Diese Information ist für ein Computerprogramm jedoch nicht direkt zugänglich.
Aus der Harmonielehre ist desweiteren bekannt, dass durch die Kadenz alle Töne der Tonleiter
definiert sind (d. h. die Kadenz enthält alle Töne der Gebrauchstonleiter). Zusammen mit
den in der Kadenz vorkommenden Harmonien (Dur oder Moll) kann die Tonart eindeutig
Funktions- und Stufenbestimmung
119
identifiziert werden. Die Suche nach solchen Verbindungen im gesamten Musikwerk wäre als
Bestätigung der Tonart damit ausreichend. Die Herausforderung besteht hierbei allerdings
darin, dass die Kadenz in ihrer reinen Form (T, S, D, T) in komplexeren Musikwerken eher
die Ausnahme darstellt. In der Regel werden die dort vorkommenden Akkorde durch eine
oder mehrere leitereigene bzw. leiterfremde Harmonien unterbrochen. Da die Kadenz aber
für die Tonartbestimmung am geeignetesten zu sein scheint, wird im folgenden Abschnitt
eine mögliche Tonartbestimmung vorgestellt, die nach genau dieser Harmonieverbindung
sucht. Der Benutzer spielt dabei keine unerhebliche Rolle. Anhand der Ergebnisse entscheidet
dieser schließlich interaktiv, welche Tonart tatsächlich vorliegt. Da dabei ebenfalls Akkorduntersuchungen (Akkordbestimmung und Akkordverbindung) vorgenommen werden, wird die
Tonartbestimmung als Teil des Analysevorgangs angesehen.
Eine wesentlich größere Herausforderung stellen Modulationen dar. Im Gegensatz zur exakten
Festlegung der Tonart, wo nur das Geschlecht bestimmt werden muss, fehlt hier in der Regel
auch die Angabe über die Vorzeichnung. Damit existiert im Musikwerk keine Kennzeichnung,
die auf einen Tonartwechsel schließen ließe. Die erste Hürde besteht also darin, überhaupt
den Beginn des Tonartwechsels auszumachen und schließlich den Bereich, in dem eine andere
Tonart vorherrscht, einzugrenzen. Dies lässt sich bspw. durch leiterfremde Töne bzgl. der
Grundtonart erkennen, wobei darauf geachtet werden muss, dass kurze Abweichungen von der
Gebrauchstonleiter nicht unbedingt sofort auf eine Modulation und damit einen Tonartwechsel
schließen lassen. Desweiteren werden häufig sehr nahverwandte Tonarten verwendet, die sich
möglicherweise nur durch einen einzigen Gebrauchsleiterton unterscheiden. Die quintverwandten Tonarten C-Dur und G-Dur besitzen bspw. bis auf den Ton f (in C-Dur) bzw. fis (in
G-Dur) die gleiche Gebrauchstonleiter. Dies erschwert die Eingrenzung der modulierten Bereiche zusätzlich, da nicht immer sofort klar wird, ob es sich um eine kurze Abweichung oder aber
um einen tatsächlichen Tonartwechsel handelt. Lässt sich jedoch trotz dieser Herausforderung
ein Modulationsbereich ausmachen, besteht die nächste schwierige Aufgabe in der Bestimmung
der Tonart. Dazu müssen zunächst alle unterschiedlichen Tonhöhen bestimmt und exakt auf
eine Tonleiter abgebildet werden. Allerdings beschränken sich die vorkommenden Töne nicht
unbedingt auf eine einzige Gebrauchstonleiter, wodurch eine Abbildung auf eine bestimmte
Tonleiter erschwert wird (z. B. bei Verwendung leiterfremder Töne). Genauso wie bei der
Geschlechtsbestimmung der Tonart ließe sich dies durch das Auffinden der Kadenz der Tonleiterkandidaten realisieren. Fehlt allerdings einer der Akkordtöne, so lässt sich die Tonart nicht
mehr eindeutig erschließen. In Abbilding 5.5 ist die Schwierigkeit bei der Tonartbestimmung
dargestellt. Die dort vorkommmenden Harmonien können sowohl der Tonart C-Dur als auch
G-Dur zugeordnet werden, da der Stammton f der Gebrauchsleiter fehlt, um die Tonart
120
Harmonische Analyse mit SQL
usw.
C
G
e
a
G
a
e
Abbildung 5.5: Identifizierung der Tonart durch Kadenzen. Fehlt wie in diesem Bespiel einer der
Kadenzakkorde, so ist die Tonart nicht mehr eindeutig. Die Akkordabfolge könnte somit entweder
C- bzw. zu G-Dur gehören, da der Akkord, der f bzw. fis enthält, fehlt.
eindeutig festzulegen.
Lösungsansätze
Die Bestimmung der Tonart ausgehend von Partituren stellt ein grundsätzliches Problem
bei computergestützten Werkzeugen dar, die als Hilfsmittel bei der Durchführung einer
harmonischen Analyse eingesetzt werden. Die exakte Tonart wird in den Werken meist
nicht explizit angegeben, und eine genaue Bestimmung ist aufgrund des fehlenden eindeutigen
Regelwerks nicht möglich. Eine Eingrenzung der Tonart durch die Kadenz ist denkbar, allerdings
wegen des Vorkommens von Modulationen und der starken Kontextabhängigkeit nur begrenzt
einsetzbar.
Aus den oben genannten Gründen ist eine automatische Durchführung einer harmonischen
Analyse mit Hilfe des im Rahmen dieser Arbeit enwickelten Werkzeugs nicht möglich (d. h.
die gesamten Partiturnoten eines Werkes lassen sich nicht durch einen Klick automatisch
auswerten und auf harmonische Aspekte hin untersuchen). Aufgrund der Komplexität von
Musik ist für derartige Aufgaben ein interaktives System wesentlich besser geeignet (d. h. der
Benutzer erarbeitet zusammen mit dem System die Ergebnisse). Das System soll dem Benutzer
für Aufgaben, die nicht eindeutig lösbar sind, Lösungsvorschläge anbieten, die der Benutzer
durch Bestätigung oder Eingabe schließlich konkretisiert. Bei der Bestimmung der Tonart
markiert der Benutzer bspw. einen Bereich in der Partitur. Das Analysesystem bestimmt
anschließend die dort vorkommenden Harmonien und die Gebrauchstonleiter, die z. B. auf zwei
Tonarten schließen lässt (z. B. C-Dur, a-Moll) und präsentiert diese dem Benutzer. Anhand
dieses Lösungsvorschlags (Akkorde und vorgeschlagene Tonart ) und evtl. durch Einsatz
weiterer Hilfsmittel (z. B. Vorspielen) kann der Benutzer das richtige Ergebnis bestätigen.
Funktions- und Stufenbestimmung
121
Aufwendige und zeitintensive Aufgaben (z. B. Akkordbestimmung der Zusammenklänge in
einem Bereich) werden weiterhin vom Analysesystem übernommen. Der Benutzer soll lediglich
die Richtung vorgeben und gewisse Entscheidungen treffen, durch die das System für die
weitere Vorgehensweise bei der harmonischen Analyse beeinflusst wird. Im Folgendem soll
anhand der Konkretisierung der Tonart und Bestimmung von Modulationen ein möglicher
Lösungsansatz vorgestellt werden.
Um den Grundton der Ausgangstonart zu bestimmen, ist es ausreichend die Tonart durch
das Vorkommen einer Kadenz abzusichern. Da die Gebrauchstonleiter bekannt ist, könnten
zunächst zu allen möglichen Zeitpunkten die Akkorde mit den Hauptfunktionen (Kadenz)
auf der Grundlage des vom Benutzer angenommenen Tonartgeschlechts (Dur oder Moll)
bestimmt werden. Um eine bessere Übersicht zu erhalten, sollten die erkannten Zeitpunkte
zusammen mit der Angabe der Funktion im Partiturbild farbig dargestellt werden. Zusammen
mit den musiktheoretischen Kentnissen des Benutzers lässt sich auf diese Weise der Grundton
der Augangstonart aufgrund der erkannten Harmonienabfolgen identifizieren. Zudem lassen
sich die möglichen Bereiche, in denen diese Tonart vorherrscht, durch die in der Partitur
hervorgehobenen Zeitpunkte durch den Benutzer besser eingrenzen. In einem weiteren Schritt
können schließlich die bzgl. der Tonart gewonnen Informationen in der ScoreContext-Tabelle
gespeichert werden und für weitere Untersuchungen harmonischer Eigenschaften benutzt
werden.
Wesentlich schwieriger ist die Aufgabe bei Modulationen, bei denen die Angabe über die
Tonart in der Partitur fehlt. Hierbei müssen zunächst die modulierten Bereiche eingegrenzt
werden. Diese können u. a. durch das Vorkommen tonleiterfremder Töne bestimmt werden.
Allerdings weist ein solcher tonleiterfremder Ton nicht immer sofort auf eine Modulation hin,
sondern kann auch nur eine kurze Ausweichung darstellen, die keinen Tonartwechsel begründet.
Daher sind auch hier Angaben vom Benutzer notwendig. Der Benutzer könnte bspw. einen
Bereich wählen, in dem die erkannten tonleiterfremden Töne enthalten sind. Das System
bestimmt die dort vorkommenden Akkorde und die möglichen Gebrauchstonleitern bzw. die
möglichen Tonarten und präsentiert diese dem Benutzer als Lösungsvorschlag (wie bei der
Bestimmung der Ausgangstonart s. o.). Auf dieser Grundlage kann die Tonart direkt bestimmt
werden, falls die Tonleiter eindeutig ist. Ansonsten muss auch eine Auswahl der Tonleiter
vorgenommen werden. Zur Unterstützung könnten die jeweiligen Funktionen bzgl. der zur
Auswahl stehenden Tonleitern im betrachten Ausschnitt angezeigt werden.
6 Architektur und Funktionalität des
Analysesystems
Im Rahmen der Diplomarbeit ist ein auf der ScoreStore-Datenbank basierendes prototypisches
Analysesystem für harmonische Untersuchungen entwickelt worden. Das in diesem Kapitel
vorgestellte Frontend bildet der ScoreAnalyzer, der über JDBC mit der Datenbank kommuniziert, d. h. darüber in SQL formulierte Anfragen bzgl. harmonischer Eigenschaften sendet und
die Ergebnisse visualisiert.
Der ScoreAnalyzer bietet dem Benutzer eine grafische Oberfläche, über die eine strukturelle Akkorduntersuchung durchgeführt werden kann. Darauf aufbauend lässt sich schließlich
eine Funktionsbestimmung der Akkorde durchführen, die allerdings aufgrund der fehlenden
Informationen bzgl. des Gesamtkontextes der Partitur nur ansatzweise gelöst werden konnte
(z. B. bei Tonartwechseln). Daher werden die Akkordfunktionen ausgehend von der jeweiligen
Grundtonart bestimmt.
Zur Visualisierung der Partituren wird der ScoreViewer verwendet, der im Rahmen des
SyncPlayer -Projekts in der Arbeitsgruppe von Prof. Clausen des Instituts für Informatik der
Universität Bonn entwickelt wurde [Kurth et al. 2005; Fremerey 2006]. Dieser wurde um
zusätzliche Funktionalität zur Ergebnispräsentation und Anfragespezifikation erweitert, so
dass zur Ergebnishervorhebung wie auch zur Orientierung bei der Anfragespezifikation farbige
Markierungen verwendet werden. Mit Hilfe des ScoreViewers wird dem Benutzer eine intuitive
Schnittstelle zur Steuerung und Durchführung der harmonischen Analyse geboten.
In diesem Kapitel wird die Funktionalität und die Architektur des Analysesystems vorgestellt.
Voraussetzung für den Einsatz ist, dass sowohl semantische als auch layoutbezogene Informationen bzgl. der zu untersuchenden Partituren vorhanden sind. Dafür werden unterschiedliche
Datenformate verwendet (z. B. für Bilder von Partituren oder für Notendarstellungen von
Musik). Auf die wesentlichen in der Verarbeitungskette verwendeten Formate und Werkzeuge
wird im weiteren Verlauf des Kapitels eingegangen. Dazu gehört auch der ScoreCompiler,
123
124
Architektur und Funktionalität des Analysesystems
der Partiturdaten aus dem MusicXML-Format einliest, die Daten konvertiert und anschließend in die ScoreStore-Datenbank importiert. Eine Übersicht über die Architektur und die
beteiligten Komponenten bei der harmonischen Ananlyse mit dem ScoreAnalyzer und der
ScoreStore-Datenbank ist in Abbildung 6.1 dargestellt.
6.1 Aufbereitung von Musikdaten
Bevor das Analysesystem eingesetzt werden kann, müssen die in Partituren enthaltenen
Informationen in der ScoreStore-Datenbank gespeichert werden, um diese schließlich mittels
des Datenbanksystems auf harmonische Aspekte hin zu analysieren. Dafür werden aus den
im Bildformat vorliegenden gescannten Partituren alle wichtigen Parameter extrahiert und
nach geeigneter Konvertierung in das relationale Datenformat übertragen. Eine manuelle
Durchführung ist aufgrund der großen Datenmenge nicht möglich. Desweiteren wäre eine genaue
Kenntnis über das relationale Datenbankschema erforderlich, weshalb hier als Zwischenformat
MusicXML zum Einsatz kommt. MusicXML ist zum Datenaustausch sehr gut geeignet, da
es alle inhaltlichen Informationen von Partituren speichern kann. Zudem ist es aufgrund
der einfachen Benutzbarkeit mittlerweile etabliert, wodurch eine Unterstützung von vielen
verschiedenen Softwareprodukten, die sowohl einen Import als auch Export ermöglichen,
gewährleistet ist. Im Rahmen der Diplomarbeit wurde eine Java-Bibliothek für MusicXML
verwendet, die von der Arbeitsgruppe Clausen des Instituts für Informatik der Universität
Bonn bereit gestellt wurde.
Zunächst werden aus den in Bildern vorliegenden Partituren die nötigen Informationen
extrahiert und in das MusicXML-Format konvertiert. Die Extraktion der Informationen lässt
sich dabei mittels Methoden aus dem Bereich der automatischen Bilderkennung, insbesondere
der Optical Music Recognition (OMR), durchführen. Der Notenerkennungsprozess wird hier
mit Hilfe der kommerziellen Software SharpEye [SharpEye] realisiert, welche den Export der
eingescannten Partiturdaten ins MusicXML-Format erlaubt. Aufgrund der Komplexität der
Notenschrift treten beim Erkennungsprozesses häufig noch Fehler auf, die nur durch manuelle
Korrektur berichtigt werden können (z. B. Note wird nicht bzw. falsch erkannt).
Für das zur Visualisierung der Partitur eingesetzte ScoreViewer-Plugin werden noch zusätzliche
Informationen bzgl. des Layouts benötigt, damit bei der Ergebnispräsentation die richtigen
Stellen im Partiturbild markiert werden können. Dafür wird das SharpEye-eigene Format
MRO verwendet, welches detailliertere Layoutinformationen als MusicXML erlaubt (z. B. (x,y)Bildkoordinaten des Taktanfangs). Zur eigentlichen Visualisierung werden die eingescannten
Bilder der Partituren benutzt.
125
Aufbereitung von Musikdaten
Score Sheet (Paper)
Scanner
Score Image (TIFF)
SharpEye
Score Data for Analysis
(MusicXML)
ScoreCompiler
Score Data for Layout
(MRO)
R
R
Controller
Batch
Update
JDBC
R
GUI
R
JDBC
Primary Data
ScoreViewer
Annotation Creator
Secondary Data
Annotation Data
Score Image Data
(JPG)
ScoreStore
ScoreAnalyzer
Abbildung 6.1: Architektur des Gesamtsystems bestehend aus ScoreAnalyer und ScoreStoreDatenbank. Ebenso abgebildet sind die nötigen Vorverarbeitungsschritte. Die Elemente mit abgerundeten Ecken stehen im Diagramm für Datenspeicher (z. B. Datenbanken, Dateien). Die
rechteckigen Elemente beschreiben Komponenten des Systems, die lesend oder schreibend auf
Daten zugreifen können (Pfeile). Die Komponenten können über Kanäle (z. B. Funktionsaufrufe,
Netzwerkkommunikation) miteinander kommunizieren. Die Richtung der Anfragen (Requests) ist
dabei durch einzelne Pfeilelemente gekennzeichnet [Knöpfel et al. 2006].
126
Architektur und Funktionalität des Analysesystems
6.2 Hinzufügen von Werken
Für die Durchführung der harmonischen Analyse werden Musikwerke in Form von Partituren
benötigt. Die ScoreStore-Datenbank beinhaltet in der Rohversion zunächst nur Sekundärdaten,
weshalb ein Import der zu untersuchenden Partituren erforderlich ist. Dies wird durch die im
Analysesystem enthaltene ScoreCompiler-Komponente realisiert, die ausgehend vom ScoreAnalyzer gesteuert werden kann. Durch Betätigen des Import-Knopfes aus dem Menü des
ScoreAnalyzers und einer anschließenden Auswahl von MusicXML-Dateien, wird der ScoreCompiler für ihre Verarbeitung angestoßen. Desweiteren wird eine für den Einsatz des
ScoreViewers benötigte sog. Annotationsdatei erzeugt, falls sie noch nicht vorhanden ist.
In den folgenden Unterabschnitten wird zunächst die Arbeitsweise des ScoreCompilers vorgestellt, bevor schließlich eine knappe Beschreibung des für den ScoreViewer benötigten
Arbeitsschrittes erfolgt.
6.2.1 Datenimport durch ScoreCompiler
Der ScoreCompiler ist für die Übersetzung der Informationen aus MusicXML in das relationale
Datenformat der ScoreStore-Datenbank zuständig. Da MusicXML weitaus mehr Informationen
über eine Partitur (z. B. Layoutinformationen) beinhalten kann als hier benötigt, müssen
zunächst einmal nur die relevanten Daten extrahiert werden. Ein Musikwerk in der ScoreStore-Datenbank wird im Primärdatenteil der Datenbank mittels zwei Tabellen Score und
ScoreContext repräsentiert, wobei diese nur die für die harmonische Analyse relevanten Informationen kodieren. Alle weiteren Informationen können vernachlässigt werden, da sie für die
hier durchgeführte Analyse nicht verwendet werden (siehe Kapitel 4).
In der Score-Tabelle werden durch die Attribute time, diatonic, alter, octave, duration und
staff die Spielanweisungen von Partituren gespeichert, während in der ScoreContext-Tabelle
zusäzliche Informationen (z. B. die Tonart) enthalten sind. In MusicXML-Dateien werden diese
entsprechend durch die Elemente <note> und <attributes> repräsentiert.
In Abbildung 6.2 ist die vom ScoreCompiler durchgeführte Konvertierung anhand einer einzigen
Note dargestellt. Dazu wird einem MusicXML-Ausschnitt ein Datensatz der Score-Tabelle
direkt gegenüber gestellt. Bei der kodierten Note handelt es sich um die Achtelnote f ’, die im
zweiten Notensystem eines Notenbeispiels vorkommt. Das Attribut time der Score-Tabelle ist
dabei das einzige, das berechnet werden muss. Dafür existiert in MusicXML kein Element, da
dort Noten pro Takt (<measure>-Element) gespeichert werden. Für einfacher durchzuführende
Berechnungen wird im relationalen Format der absolute Zeitpunkt gespeichert. Dafür werden
127
Hinzufügen von Werken
<note>
<pitch>
<step>F</step>
<octave>4</octave>
</pitch>
<duration> 4</duration>
<voice>2</voice>
<type>eighth</type>
<stem>down </stem>
<staff>2</staff>
<beam number= "1">begin</beam>
Score-Entry
time: 17
diatonic: 3
alter: 0
octave: 5
duration: 4
staff: 2
<notations>
</notations>
</note>
Abbildung 6.2: Abbildung der benötigten Informationen aus MusicXML in das relationale
Tabellenformat von ScoreStore
alle bis zu diesem Zeitpunkt vorkommende duration-Werte aufaddiert. Es muss darauf geachtet
werden, dass in MusicXML mit <forward> und <backward>-Elementen navigiert wird, um
gleichzeitig erklingende Töne zu realisieren, so dass einzelne <duration>-Werte in einem Takt
subtrahiert bzw. addiert werden. Alle übrigen Attribute sind ebenfalls in MusicXML enthalten,
weshalb sie nur geeignet umkodiert werden müssen. Falls ein Element doch ausbleibt, so wird
der festgelegte MusicXML-Standartwert angenommen. Im Beispiel ist dies bei dem Element
<alter> der Fall.
Nach dem Auslesen und der geeigneten Übersetzung der Daten in das für ScoreStore erforderliche Tabellenformat , werden die Daten durch einen sog. Batch Update in die Datenbank
überführt. Dazu werden die Daten zunächst in einer Textdatei zwischengelagert und anschließend durch einen einzigen Datenbankzugriff in ScoreStore als eine neue Tabelle gespeichert.
Ein spezielles in Visual Basic erzeugtes Microsoft Access-Makro dient dabei als Hilfe für den
Import. Die JDBC-Schnittstelle bietet zwar INSERT-Methoden, um Datensätze in Datenbanktabellen einzufügen, diese werden allerdings datensatzweise eingefügt, was bei umfangreicher
Datenmenge aufgrund der hohen Anzahl an Datenbankzugriffen zu einer großen Laufzeit
führt. Bei der verwendeten Methode wird nur ein Zugriff benötigt und die Daten nur dann in
die Datenbank eingefügt, falls die für die Tabelle festgelegten Integritätsbedingungen nicht
verletzt werden. Ansonsten schlägt der gesamte Datentransfer fehl. Aufgerufen wird das Visual
Basic-Makro über ein Microsoft .NET -Programm [DotNet], das in einem eigenen Prozess von
Java aus gestartet wird.
128
Architektur und Funktionalität des Analysesystems
6.2.2 Vorbereitung für ScoreViewer
Für den Import einer Partitur in die ScoreStore-Datenbank kann prinzipiell jede beliebige
MusicXML-Datei mit dem ScoreAnalyzer eingelesen und anschließend analysiert werden.
Dadurch ist allerdings nur die Analyse ausgehend von der grafischen Kommandoschnittstelle
des ScoreAnalyzers möglich. Um den vollen Funktionsumfang samt des ScoreViewers nutzen
zu können, muss eine Annotationsdatei vorliegen, die die Bildinformationen mit den Layoutinformationen aus den MRO-Dateien verknüpft. Diese werden bspw. benötigt, um Ergebnisse
bei der Analyse durch Markierungen im Partiturbild richtig setzen zu können. Dafür ist es
erforderlich, dass die benötigten Datenformate synchronisiert sind. Dies ist z. B. der Fall, wenn
die Dateien mit Hilfe der Notenerkennungssoftware SharpEye erzeugt werden. Dabei wird
ein direkter Zusammenhang zwischen den verwendeten Partiturbildern und den erzeugten
MusicXML- und MRO-Dateien erstellt. Da der ScoreViewer diese Informationen bei jedem
Anzeigen immer wieder verwendet, wird ein Verzeichnis ScoreData angelegt, welches alle diese
Informationen beinhaltet.
Liegen die entsprechenden Daten sowohl in der Datenbank, als auch in dem zuvor beschriebenen
Verzeichnis vor, lässt sich darauf aufbauend mittels des ScoreAnalyzers eine harmonische
Analyse durchführen.
6.3 Analyse von Musikwerken
Exemplarisch ist im ScoreAnalyzer die Bestimmung einzelner Zusammenklänge implementiert
worden. Der ScoreAnalyzer bietet die Möglichkeit, eines der vorher importierten Musikwerke
aus dem Menü heraus auszuwählen, um dieses anschließend auf harmonische Eigenschaften hin
zu untersuchen. Beim Öffnen eines Musikwerkes wechselt die Oberfläche des ScoreAnalyzers
zur Einzelanalyse eines Zusammenklangs und der ScoreViewer wird mit der entsprechenden
Partiturvisualisierung gestartet. Die Analyse kann anschließend vom ScoreAnalyzer aus durch
Eingabe der zu untersuchenden Positionen gesteuert werden, alternativ auch direkt aus dem
ScoreViewer durch Anklicken einer Stelle im Partiturbild. In den folgenden zwei Abschnitten
wird die Funktionalität und Zusammenarbeit dieser beiden Komponenten vorgestellt.
6.3.1 ScoreAnalyzer
Die grafische Kommandoschnittstelle des ScoreAnalyzers ist in zwei Bereiche unterteilt (siehe
Abbildung 6.3). Im Anfragebereich wird die Anfrage spezifiziert. Durch Auswahl des Taktes
Analyse von Musikwerken
129
Abbildung 6.3: Grafische Kommandooberfläche des ScoreAnalyzers. Im oberen Teil befindet sich
der Anfragebereich. Unten werden die Ergebnisse präsentiert.
und der Position im Takt lässt sich der zu untersuchende Zusammenklang definieren. Weiterhin
können hier weitere zu untersuchende Aspekte bzgl. des Baus des Akkordes (z. B. Umkehrung,
Diskantlage) einfach durch entsprechendes Markieren einer Checkbox hinzugefügt werden. Die
Funktionsbestimmung ist hier ebenfalls realisiert, allerdings nur auf die Grundtonart bezogen.
Durch Anklicken des Bestimmen-Knopfes wird schließlich ein Ereignis ausgelöst und dadurch
der Zusammenklang auf die vorher spezifizierten Aspekte hin untersucht. Dabei wird die
entsprechende SQL-Anfrage über die JDBC-Schnittstelle (siehe Kapitel 3.2.6) an das DBMS
gesendet, welches die Analyse durch Auswertung der SQL-Anweisung durchführt.
Nach der Verarbeitung schickt das DBMS die Ergebnismenge als Antwort wieder an den
ScoreAnalyzer zurück. Dieser präsentiert die Antwort einerseits in textueller Form im Antwortbereich des eigenen Kommandofensters. Zusätzlich wird der ScoreViewer angesprochen,
der die entsprechende Position (Takt und Position im Takt) farbig markiert. Dafür fragt der
ScoreAnalyzer zunächst den ScoreViewer nach den Koordinaten des betrachteten Taktes und
berechnet anhand dieser und der bekannten Position im Takt die Koordinaten zur Markierung
der richtigen Stelle im Partiturbild. Dies wird dem ScoreViewer mitgeteilt, so dass dieser
schließlich die entsprechende Stelle im Bild markieren kann. Das Ergebnis erscheint damit in
textueller Form auf der Oberfläche des ScoreAnalyzers und durch farbige Hervorhebung in der
Partiturvisualisierung des ScoreViewers.
130
Architektur und Funktionalität des Analysesystems
Abbildung 6.4: Farbige Hervorhebung der Ergebnisse der Akkordbestimmung in der Partiturvisualisierung des ScoreViewers. Hier wird erneut ein Ausschnitt aus der Winterreise von
Franz Schubert betrachtet. Zusätzlich wird an der Position des Mauszeigers das Ergebnis der
Akkorduntersuchung als Tooltip eingeblendet.
6.3.2 ScoreViewer
Der ScoreViewer ist eine Komponente der ScoreAnalyzer-Applikation. Die Kommunikation
zwischen diesen beiden ist ereignisorientiert (siehe Actions und ActionListener im Kapitel
3.2.4). Eine Kommunikation mit der ScoreStore-Datenbank ist nur über den ScoreAnalyzer
möglich.
Zusätzlich zur Ergebnispräsentation ermöglicht der ScoreViewer ebenfalls eine Spezifikation
der Analyseabfragen. Dabei wird der gewünschte Zeitpunkt, zu dem eine Akkordbestimmung
stattfinden soll, durch Anklicken im Partiturbild bestimmt. Weitere zu untersuchende Aspekte können durch die Kommandoschnittstelle des ScoreAnalyzers spezifiziert werden. Diese
Möglichkeit der Analysedurchführung ist für den Benutzer wesentlich komfortabler und intuitiver, da hier direkt in der Partitur mit dem Mauszeiger der gewünschte Zusammenklang für
die Untersuchung bestimmt werden kann (siehe Abbildung 6.4). In der grafischen Schnittstelle
des ScoreAnalyzers muss der Benutzer dagegen die gewünschte Position manuell angeben.
Um einen gewünschten Zusammenklang ausgehend vom ScoreViewer zu untersuchen, reicht es
aus, die entsprechende Position im Partiturbild anzuklicken. Zur besseren Orientierung werden
Analyse von Musikwerken
131
dabei sowohl die einzelnen Takte farbig umrandet und die Taktnummer angezeigt, als auch die
möglichen zu untersuchenden Zeitpunkte in jedem Takt durch eine schwache Färbung hervorgehoben. Diese Markierungen werden dabei nur für den Bereich angezeigt, über dem sich der
Mauszeiger aktuell befindet. Aufgrund der sehr groben und ungenauen Layout-Informationen
ist eine exakte Bestimmung der Position des gewünschten Zusammenklangs und damit die
korrekte Markierung im Rahmen der Diplomarbeit nicht möglich gewesen. Die Funktionalität
ist aber derart implementiert, dass eine genauere Markierung durchgeführt werden kann,
sobald genauere Layout-Informationen zur Verfügung stehen. Die aktuelle Implementierung
verwendet eine Heuristik, wodurch die Positionen im Takt grob der tatsächlichen angenähert
werden. Jeder Takt wird dabei durch die Anzahl dort existierender Zeitpunkte geteilt und in
gleichmäßige Bereiche unterteilt. Aufgrund unterschiedlicher Taktbreiten und der nicht immer
gleichen Notenverteilung im Takt durch bspw. Zusatzinformationen wie Vorzeichen entstehen
z. T. ungenaue Positionsmarkierungen. Die verwendete Hervorhebung der einzelnen Positionen
dient daher u. a. als Orientierungshilfe für den Benutzer zur Festlegung der gewünschten
Zeitpunkte des zu untersuchenden Zusammenklangs.
Durch Anklicken der gewünschten Position im Partiturbild des ScoreViewers wird ein Ereignis
ausgelöst. Dabei werden dem ScoreAnalyzer die Positionskoordinaten der angeklickten Stelle
mitgeteilt, die dieser anschließend in die entsprechende Darstellung (Takt und Position im
Takt) umrechnet. Nach der Umrechnung wird die grafische Oberfläche des ScoreAnalyzers
diesbezüglich angepasst. Gleichzeitig setzt der ScoreAnalyzer mit den berechneten Positionsangaben eine Anfrage zur Akkordbestimmung an das DBMS ab. Die darauf folgende
Ergebnispräsentation verläuft schließlich genauso ab, als wenn die Anfrage im ScoreAnalyzer
spezifiziert worden wäre.
Das Ergebnis im ScoreViewer wird ebenfalls durch farbige Markierung des untersuchten
Zusammenklangs hervorgehoben. Dabei wird eine kräftigere Färbung verwendet, um diese
von der oben beschriebenen Färbung für die Orientierungshilfe zu unterscheiden. Wird der
Mauszeiger über die Markierung geschoben, erscheint ein Tooltip mit den zugehörigen Ergebnisinformationen (siehe Abbildung 6.4). Zusätzlich dazu wird die Position im Takt mit
angegeben. Dieses Ergebnis bleibt sichtbar, bis der Knopf Zurücksetzen im ScoreAnalyzer
gedrückt wurde oder eine neue Anfrage abgesetzt wurde. Implementiert wurden die farbigen
Hervorhebungen und die Tooltip-Darstellung als Erweiterung der ScoreViewer-Komponente
direkt mit JOGL-Funktionalität, d. h. mit OpenGL-Befehlen.
7 Zusammenfassung und Ausblick
In dieser Arbeit wurden Datenbanken erstmalig zur harmonischen Analyse von Musikwerken
basierend auf Partiturinformationen eingesetzt und die sich dadurch bietenden Möglichkeiten
untersucht. Dafür wurde zunächst ein geeignetes konzeptuelles Modell von Partiturdaten entworfen und auf ein relationales Datenbankschema übertragen. Zusätzlich zu der Modellierung
und Speicherung der tatsächlichen Partiturdaten war es ebenfalls notwendig, Grundlagen aus
der Musik (z. B. Note oder Intervall) in der Datenbank zu modellieren und abzuspeichern. Erst
mit diesen Informationen zusammen ergeben die Partiturtabellen einen sinnvollen Zusammenhang. Mit Hilfe der Datenbanksprache SQL wurden schließlich basierend auf der entworfenen
Datenbank Fragestellungen zur harmonischen Analyse formuliert, die vom zugehörigen DBMS
ausgewertet werden. Zur Evaluation des Analysesystems wurde aufbauend auf der Datenbank
eine Applikation entwickelt, die dem Benutzer eine komfortable und intuitive Schnittstelle zur
Anfragespezifikation und Ergebnispräsentation bietet. Der Benutzer kann dabei u. a. direkt
auf dem in der Applikation vorhandenem Partiturbild operieren. Hier können sowohl Anfragen
spezifiziert werden, als auch die dort präsentierten Ergebnisse interpretiert werden.
Mit Hilfe der entwickelten relationalen Datenbank ist es möglich, viele Aufgaben bei der
harmonischen Analyse zu lösen, sofern die erforderlichen Daten in der Datenbank vorliegen. So
lassen sich bspw. Fragestellungen zur Intervall- und Akkordbestimmung durch SQL-Abfragen
formulieren. Partituren geben allerdings nicht alle benötigten Informationen (z. B. Tonart und
Tonartwechsel) von Musikwerken direkt her. Desweiteren sind sie aufgrund der Komplexität von
Musikwerken auch nicht offensichtlich bestimmbar. Diese wichtigen Informationen fehlen somit
ebenso in der Datenbank, wodurch eine vollkommen automatische Durchführung der Analyse
basierend auf den Partiturdaten nicht möglich ist. Eine Weiterentwicklung des Analysesystems
könnte daher eine halbautomstische Lösung sein, bei der der Benutzer durch Interaktion mit
dem System Ergebnisse bzgl. Fragestellungen zur harmonischen Analyse erarbeitet.
Bei den bisherigen Ausführungen wurden keine Angaben bzgl. der Effizienz bzw. der Laufzeit
der verwendeten Anfragen gemacht. Der Fokus lag allerdings nicht auf der Optimierung der
Anfragen, sondern grundsätzlich auf der modularen Umsetzung. Diesbezüglich problematisch
sind komplexe Anfragen über große und umfangreiche Musikwerke. Dazu gehören insbesondere
133
134
Zusammenfassung und Ausblick
Anfragen, die große Bereiche von Werken betrachten (z. B. Bestimmung der Akkorde zu allen
möglichen Zeitpunkten). Zur Verkürzung der Laufzeit können in einigen Fällen Anfragen
materialisiert, d. h. als Tabellen permanent gespeichert werden. Darüber hinaus sind die vorgestellten Sichten nicht immer auf eine bestimmte Aufgabe hin optimiert, da sie in verschiedenen
Kontexten einsetzbar sein sollten. Die in einer Anfrage mitgeführten Attribute werden nicht
für alle Anfragen gleichermaßen benötigt. Dies führt zwar zu Effizienzeinbußen, allerdings
ist der generische Aufbau von Vorteil, da so einzelne Anfragen wiederholt in unterschiedlichen Aufgaben eingesetzt werden können. Durch Optimierung der Anfragen auf bestimmte
Aufgaben hin läßt sich die Effizienz hier leicht steigern.
Weitere interessante Fragestellungen bzgl. harmonischer Aspekte könnten sich dem Vergleich
mehrerer Musikwerke des gleichen bzw. unterschiedlicher Komponisten widmen. Durch den
Einsatz von relationalen Datenbanken können Musikwerke direkt in Beziehung gesetzt werden,
um z. B. die Struktur der harmonischen Abläufe direkt vergleichen zu können.
Literaturverzeichnis
Access
Microsoft Access. –
http://office.microsoft.com/access.
Agon u. Assayag 2002
Agon, Carlos ; Assayag, Gérad: Object-Oriented Programming in OpenMusic. In:
Mazzola, Guerino (Hrsg.): Topos of Music – Geometric Logic of Concepts, Theory, and
Performance. Birkhäuser, 2002. – ISBN 3–7643–5731–3.
Binkowski et al. 1996
Binkowski, Bernhard ; Hug, Manfred ; Koch, Peter: Musik um uns. J.B. Metzlersche
Verlagsbuchhandlung, 1996. – ISBN 3–476–20318–2.
Capella
Capella-Software GmbH. –
http://www.capella.de.
Castan
Castan, Gerd: Datenformate für Musiknotation. –
http://www.music-notation.info.
Chen 1976
Chen, Peter Pin-Shan: The Entity-Relationship Model – Toward a Unified View of Data.
In: ACM Transactions on Database Systems (1976), S. 9–36. – ISSN 0362–5915. –
http://dx.doi.org/10.1145/320434.320440.
Dachs-Söhner 2007
Dachs-Söhner: Harmonielehre – Erster Teil. Kösler-Verlag, 2007. – ISBN 3–466–30013–4.
Date u. Darwen 1998
Date, Chris J. ; Darwen, Hugh: SQL – Der Standard. Addison-Wesley, 1998. – ISBN
3–8273–1345–7.
135
136
Literaturverzeichnis
DotNet
Microsoft .NET. –
http://www.microsoft.com/germany/msdn/netframework.
Finscher u. Blume 1994
Finscher, Ludwig ; Blume, Friedrich: Die Musik in Geschichte und Gegenwart (MGG)
Sachteil. Metzler, 1994. – ISBN 3–476–41022–6.
Flanagan 2005
Flanagan, David: Java in a Nutshell. O’Reilly Media, 2005. – ISBN 0–596–00773–6.
Fremerey 2006
Fremerey, Christian: SyncPlayer – a Framework for Content-Based Music Navigation
(Diplomarbeit) / Universität Bonn. 2006.
Good 2000
Good,
the
1st
Michael:
Representing
International
Symposium
Music
on
Using
Music
XML.
Information
In:
Proceedings of
(ISMIR),
2000.
–
http://ismir2000.ismir.net/posters/good.pdf.
Humdrum
The Humdrum Toolkit: Software for Music Research. –
http://music-cog.ohio-state.edu/Humdrum.
Java
Java Technology, Sun Developer Network. –
http://java.sun.com.
JDBC
JDBC Overview, Sun Developer Network. –
http://java.sun.com/products/jdbc/overview.html.
JOGL
JOGL API Project. –
https://jogl.dev.java.net.
Kemper u. Eickler 2006
Kemper, Alfons ; Eickler, Andre: Datenbanksysteme. Oldenbourg Verlag, 2006. – ISBN
3–486–57690–9.
137
Literaturverzeichnis
Knöpfel et al. 2006
Knöpfel, Andreas ; Gröne, Bernhard ; Tabeling, Peter: Fundamental Modelling
Conecepts – Effective Communication of IT Systems. Wiley, 2006. – ISBN 3–470–02710–X.
Kurth et al. 2005
Kurth, F. ; M., Müller ; Damm, D. ; Fremerey, Ch. ; Ribbrock, A. ; Clausen, M.:
SyncPlayer - An Advanced System for Multimodal Music Access. In: Proceedings of the
6th International Conference on Music Information Retrieval (ISMIR), 2005, S. 381–388,
http://www-mmdb.iai.uni-bonn.de/projects/syncplayer.
Manthey 2005
Manthey, Rainer:
Folien der Vorlesung Informationssysteme.
Universität Bonn,
2005/2006 (Wintersemester). –
http://www.informatik.uni-bonn.de/~manthey.
Mazzola u. Zahorka 1994
Mazzola, Guerino ; Zahorka, Oliver: The RUBATO Performance Workstation on
NEXTSTEP. In: Proceedings of the International Computer Music Conference (ICMC),
1994.
Michels 2005
Michels, Ulrich: dtv-Atlas Musik – Musikgeschichte von den Anfängen bis zur Gegenwart.
Deutscher Taschenbuch Verlag, 2005. – ISBN 3–423–08597–5.
MIDI
MIDI Manufacturers Association, The Complete MIDI 1.0 Detailed Specification, Second
Edition. –
http://www.midi.org.
Milmeister 2006
Milmeister, Gérad: The Rubato Composer Music Software: Component-Based Implementation of a Functorial Concept Architecture, Universität Zürich, Diss., 2006. –
http://www.rubato.org.
MusicXML
Recordare LLC, MusicXML 1.1 Document Type Definition. –
http://www.recordare.com/xml.html.
Mutopia
The Mutopia Project: Free Sheet Music for Everyone. –
http://www.mutopiaproject.org.
138
Literaturverzeichnis
Nienhuys u. Nieuwenhuizen 2003
Nienhuys, Han-Wen ; Nieuwenhuizen, Jan: Lilypond – A System for Automated Music
Engraving. In: Proceedings of the XIV Colloquium on Musical Informatics (XIV CIM
2003), 2003.
OpenGL
OpenGL – The Industry’s Foundation for High Performance Graphics, OpenGL 2.1
Specification. –
https://www.opengl.org.
SharpEye
Visiv SharpEye Music Scanning. –
http://www.visiv.co.uk.
Shreiner et al. 2007
Shreiner, Dave ; Woo, Mason ; Neider, Jackie: OpenGL Programming Guide: The Official Guide to Learning OpenGL, Version 2.1. Addison-Wesley, 2007. – ISBN 0–321–48100–3.
Sparks 2004
Sparks, Geoffrey: Database Modelling in UML. In: Methods & Tools (2004). –
www.sparxsystems.com/downloads/whitepapers/Database_Modeling_In_UML.pdf.
Swing
JDK6 Swing, Sun Developer Network. –
http://java.sun.com/javase/6/docs/technotes/guides/swing.
UML
Object Management Group – Unified Modelling Language, UML 2.1.1 Infrastructure
Specification. –
http://www.uml.org.
Unicode
Unicode Homepage. –
http://www.unicode.org.
Wikipedia 2008
Wikipedia:
Quintenzirkel (polnisch) — Wikipedia, Die freie Enzyklopädie.
http://pl.wikipedia.org/wiki/Fullpagename?oldid=11103061.
[Online; Stand 15. Februar 2008].
Version: 2008. –
Literaturverzeichnis
139
Ziegenrücker 1993
Ziegenrücker, Wieland: Allgemeine Musiklehre. Deutscher Verlag für Musik, 1993. –
ISBN 3–7957–8201–5.