Top content

Interaktionsdaten: Big-Data-Technologien vs. relationale Speicherung

Dieses Thema ist Teil eines Forschungsprojektes, welches derzeit ein relationales Schema verwendet. Persistiert werden Daten, die von „Traceability“-Tools generiert werden. Diese Tracing-Daten beinhalten Informationen zu:

1. Artefakten (z. B. Quellcode-Dateien, Anforderungstexte, Testfälle, Bug-Reports ...) und
2. Links (=die Beziehungen zw. den Artefakten, bspw. „Java-Klasse C1 setzt Anforderung A5 um“ oder „Test T11 testet Java-Klasse C3“).

Diese Form von Tracing-Daten ist die „traditionelle“ Variante, wie sie von vielen Tools und Methoden aus dem Traceability-Bereich verwendet wird. Eine Besonderheit des Forschungsprojekts ist die Erweiterung dieser Daten um dynamische Eigenschaften, sodass bspw. der Lebenszyklus der Artefakte und Links erfasst wird – vom ersten Anlegen über alle Modifikationen hinweg bis ggf. zu ihrer Löschung. Die Basis hierfür sind Interaktionen zwischen dem Entwickler und den Software-Werkzeugen. Beispielhafte Interaktionsarten sind das Öffnen, Lesen und Modifizieren von Artefakt-Dateien:

• Quellcode (in der IDE)
• UML-Diagramme (im Editor)
• Anforderungstexte (in Office-Anwendungen).

Eine typische Nutzung dieser erweiterten Tracing-Daten ist das Ermitteln aller zu einem bestimmten Zeitpunkt existierenden Artefakte und Links. Hier finden sich bereits zwei Aspekte der Problemstellung:
1. Diese in Worten leicht zu formulierende Frage ist mit dem relationalen Schema als vergleichsweise komplexes SQL-Statement umsetzbar. Zu untersuchen wäre, ob dies in anderen Datenbanktechnologien einfacher gelöst werden kann.
2. Durch die Interaktionserfassung werden sehr viele Daten gespeichert - je nach Konfiguration bspw. auch einzelne „Klicks“ in den Artefakten/Dateien. Diese Datenmengen beeinflussen die Performance der ohnehin bereits komplexen Anfragen sehr stark, sodass auch hierfür die Eignung alternativer Technologien untersucht werden sollte.

Zu diesem Thema ist also Ausgangsmaterial vorhanden (insb. das relationale Schema, Beispieldaten, Anfragen/SQL-Statements). Die weitere Bearbeitung besteht dann aus:

• Recherche alternativer Datenbanktechnologien/Persistierungsformen
• Vergleich der Alternativen untereinander mit anschließender Auswahl (mind. eine geeignete Technologie)
• Transfer der relationalen Daten und Statements in diese Technologie
• Evaluation: Vergleich der Nutzung mit der relationalen Variante (s. o.: Statement-Komplexität und Performance)

Freiheit besteht in der Auswahl der alternativen Technologien. Wenn bereits Vorkenntnisse mit „Big Data“-Persistierung, NoSQL etc. vorhanden sind, kann dort angeknüpft werden.

Bei Interesse wenden Sie sich an Dennis Ziegenhagen.