obslog - an elementary database model for logging astronomical observations

[DHEB]

Dear all,

I hereby present obslog, a project in which I have been working during the summer, namely a database system for storing my records as an amateur astronomer. (Disclaimer: the text below has also been posted in my astroblog: Epistulae Astronomicae).

The central idea in obslog is that everything an amateur astronomer does, like visual observations, photography, variable star estimations, spectroscopy, etc., takes place during a session. A session occurs during a specific span of time, in a specific place, under a given weather, Moon phase and particularities. These properties are common to all activities that are carried on during a session and do not need to be entered more than once, that is, as a row in a table describing sessions. In the same way, activities that amateur astronomers do during a session have different sets of properties that define them, although some elements might be common. For example, all observations have a target object, are done with an instrument, which can be fitted with an eyepiece, filter, accessories, etc., and result in some kind of note, sketch or data.

In principle, all this might be easily stored in spreadsheets and, in fact, this is what most amateurs do. I nevertheless chose a relational database model because it is more flexible and powerful than a spreadsheet, while being only a bit more complicated. In a relational database entities are described non-redundantly in tables and the retrieval of information is done through queries. Queries can be arbitrarily complicated and may involve information stored in many tables. Following the relational database paradigm, in obslog redundancy is minimized by defining separate tables for specific classes of activity and equipment, like session, observation, object, instrument, eyepiece, etc. Data are stored once, in only one place, and given an unique identifier. Every specific item can thus be uniquely referred to in another table if necessary, minimizing the chance of errors, and when something needs to be changed it only needs to be changed once at the place where it is stored. As it is not always possible or desirable to fill all fields, I deliberately chose to avoid the not null clause in all fields except for the unique identifier (primary key). Also following the relational database model, anything that can be calculated from stored data is explicitly avoided, for example the magnification given by a certain combination of telescope and eyepiece, which if needed can be calculated in a query.

The current design of the database necessarily reflects my style of practicing the hobby: mostly observational sessions, including variable star estimations, with occasional imaging. I therefore include some tables with information from the American Association of Variable Star Observers — AAVSO that is only useful for variable star observers. Obviously, this layout might not be adequate for someone for whom imaging is the entire purpose of her/his sessions. This should not be a problem, as obslog is free software and users have the code at their disposal to make modifications to satisfy a wide variety of purposes.

If you are interested, you can find obslog in the figshare repository:

obslog – an elementary database model for logging astronomical observations

There you can find a pdf manual, a prepackaged database file (obslog.sqlite) and the SQL code to generate it in your system.

obslog is free and open source software released under Apache License version 2.0.

Any comments are welcome!

Good luck and clear skies!

Hernán (Cinco Sauces)