ingo.strauch.diplom - Desy

3.2. KONZEPTE IM OO-PROJEKT 19
Die Auswertung der vom Runkatalog zur Verfügung gestellten Daten obliegt dem H1Tree,
welcher in Abschnitt 3.2.3 näher beschrieben wird.
Für den Runkatalog wird eine relationale Datenbank nach dem SQL-Standard (SQL = Standard
Query Language) benutzt. Zur Zeit ist dies MySQL, eine frei verfügbare Datenbank, die unter der
GPL (GNU Public License) steht. Die benötigten Leistungsmerkmale sind verfügbar, das Plus
dieser Wahl liegt darin, einen MySQL-Server ohne kostenpflichtige Lizenzen an externen Instituten
aufsetzen zu können. Am DESY selbst gibt es einen “Master” und einen “Slave” Server
auf verschiedenen Rechnern. Das Replizieren auf einem PC an externen Instituten ist ebenfalls
getestet und durchführbar.
Die Alternative zu MySQL ist Oracle, für das das DESY bereits Lizenzen besitzt. Das Interface
in ROOT unterstützt zur Zeit genau diese beiden Datenbanken, d.h. ein Übergang wäre
transparent. Diese Umstellung auf Oracle ist dann zu erwägen, wenn sich herausstellt, daß an
externen Instituten kein Bedarf für einen Slave-Server besteht, oder wenn mit MySQL nicht noch
ein weiteres System gepflegt und administriert werden soll.
3.2.3 Das zentrale Objekt: der H1Tree
Bei dem H1Tree (siehe auch [Pro] Abschnitt 2) handelt es sich um eine Generalisierung des
TTree von ROOT. Dieser wiederum ist eine Verallgemeinerung des N-Tupel-Prinzips und dient
der Strukturierung und effizienten Speicherung von großen Datenmengen (siehe auch [BRP + 00]).
Die wesentlichen Unterschiede zu einem N-Tupel sind, daß nicht nur Zahlen und Arrays gespeichert
werden können sondern auch Objekte, ein TTree kann auf mehrere Dateien verteilt und
Teile – sogenannte Branche – unabhängig voneinander geladen werden. Genau genommen stellt
ein H1Tree drei parallele Trees dar, die über ein und dasselbe Interface angesprochen werden.
Dabei ist es besonders hilfreich für den Benutzer, daß sich der H1Tree um die Zugriffe
auf die Dateien kümmert. Ein Physiker muß selbst nur noch einen Run/Event Bereich angeben,
wobei es für ihn nicht wichtig ist, in welchen Dateien die Informationen gespeichert sind und
auf welchem Rechner und in welchen Verzeichnissen die Daten physikalisch liegen. Weiterhin
werden nur dann Informationen in den Arbeitsspeicher gelesen, wenn sie auch wirklich angefordert
werden, d.h. es wird nicht generell das gesamte Ereignis eingelesen. Folgendes Beispiel
illustriert, wie dies ausgenutzt werden kann:
Die Listen identifizierter Teilchen auf dem µODS enthalten nicht die kinematischen
Informationen. Ein sogenannter “Smart Pointer” (siehe auch Abschnitt 3.2.4)
verweist auf einen Eintrag in der Liste aller Teilchenkandidaten, von wo aus auf die
kinematischen Eigenschaften zugegriffen werden kann.
Will man nun weitere Schnitte anwenden, die ohne kinematische Information
auskommen, so bietet es sich an, die (u.U. recht große) Liste aller Teilchenkandidaten
erst dann zu laden, nachdem die zusätzliche Selektion stattgefunden hat. Dies
geschieht automatisch wenn die Smart Pointer dereferenziert werden, d.h. auf das
Objekt zugegriffen werden soll, auf das sie verweisen. Die zugehörige Liste muß
also nicht von Hand angefordert werden.