Logical Data Model

From Daya Bay
Revision as of 13:24, 9 August 2007 by Coyote (talk | contribs) (Copied over from private Wiki.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This topic provides the backgound to the the Logical Data Model write up.

Introduction

With the recent adoption of Gaudi, now is a good time to try and agree on a logical data model that can be used throughout the offline software, independent of implementation as this will then drive the Gaudi implement step which needs to follow soon.

The origins of this write up come from the synthesis and distilation of previous documents, email threads and personal discussions about the way data will be handled within the Daya Bay experiment. Some of these source documents are:

* Ideas on Offline Data Structure
* Data Structure Ideas Revisited
* Event Data Issues
*  Data Structure Requirements
*  Data Structure Use Cases

The Current State of the Writeup

The current version of the writeup is version DYB-doc-1004-v2. The aim of this version is to provide a framework for defining and filling in those areas of the model that are missing (and, yes, there are plenty) and to act as a blueprint for how the data model should be defined.

Currently only the raw and calibrated layers of the "physics" stream are well fleshed out. Along with those, the mechanism for both finding existing objects and navigating between them is also fairly completely documented.

The Plan for the Writeup

With the delivery of a Gaudi prototype planned for Aug 1st, integrating the Monte Carlo information into this model is a high priority and should also happen soon (though not necessarily in the next version). This requires an understanding of how the Monte Carlo structures relate to themselves and to the 'generated' data. The current expectation is that on the time scale of the prototype there will be MC objects that can be mapped onto 'CalibratedTriggers' as this skips, to 1st order, the need to worry about modelling the DAQ trigger. The generated 'CalibratedTriggers' can then be used in analysis algorithms written to work with the "Physics" stream.

The other area of concentration in the near future is defining the attributes of the Footprint and Candidate layers to complete a first pass at the full Physics model.

The Gaudi geometry service is under development so it is hoped that some of that model can be written up soon.


-- SjPatton - 24 May 2007