KEYWORDS: Databases, Image processing, Time metrology, Thulium, Data centers, Data storage, Image retrieval, Computer programming, Complex systems, Data processing
We compare the efficiencies of a relational database, MySQL, and an object oriented database, Objectivity, for simple functionalities, like handling data produced by a reduction pipeline. For each test, we then challenge two designs as similar as possible, both capable to handle the same amount of useful data, and which both have the same functionalities implemented on top of the design. From this study, we then discuss which system is more suited or more efficient for these types of applications. In particular, the impact of the design on the global application efficiency is addressed, as well as the advantages and limitations of the two systems. The tests show that relational system are more efficient for simple queries. The absence of a global query syntax for object oriented database turns out to be a disadvantage when dynamic behavior is needed or required. Moreover, it implies an additional effort in API (Application Programming Interface) development, which reduces the strength of object oriented system when handling complex data structure and related queries.
AVO Work Area 2 consists of deployment and demonstration of an interoperability prototype. Access to archives of all the partners (ESO, ESA, AstroGrid, Terapix, Jodrell Bank) is implemented via the CDS data federation and integration tools: VizieR and Aladin. The prototype is available for science usage and more functionalities, based in particular on the usage of Uniform Content Descriptors (UCDs) for data mining, will be developed. Case by case discussion with data providers will help to establish a set of practical recommendations for interoperability. Science requirements and new technologies studied by the other AVO work Areas will also be tested. Discussions on standards are ongoing among all VO projects.
The design of the link between data and its data description defines the flexibility and application. A static configuration refers to a situation where metadata are externally defined. Conversely, in dynamic cases the data descriptions are no longer frozen, but are explicitly formalized and stored at a certain hierarchy level. We used two levels in order to test dynamic design; catalogs as dynamic lists and images as dynamic items. We then considered three kinds of objects, always containing a static data part and eventually a dynamic data part. Using the object oriented database Objectivity, we measured the retrieval speed for several configurations. When selection criteria apply to the static part of items, the retrieval speed is independent of the data kind extracted (static or dynamic). However, when the selection criteria apply on dynamic parts, the speed is strongly decreased. This clearly shows the strength of static implementation of informations whenever it is possible in order to guarantee a fast data access. It also point out a serious limitation to data mining, where a priori knowledge is in general not available. Fortunately, a dynamic implementation at a level of lists, could resolve the problem. The most elegant way, in the VO context, would be the usage of VOTable as data access layer interface.
Access to the requested content is limited to institutions that have purchased or subscribe to SPIE eBooks.
You are receiving this notice because your organization may not have SPIE eBooks access.*
*Shibboleth/Open Athens users─please
sign in
to access your institution's subscriptions.
To obtain this item, you may purchase the complete book in print or electronic format on
SPIE.org.
INSTITUTIONAL Select your institution to access the SPIE Digital Library.
PERSONAL Sign in with your SPIE account to access your personal subscriptions or to use specific features such as save to my library, sign up for alerts, save searches, etc.