Database Schema

Diagram of the relationships in the flight database

Random collection of thoughts

One objective of this database is to keep track of all the files that are created by the various processes and if/where those files are backed up. To this effect, the files table keeps track of the complete file path and the drive name of every instance of a file.

Those files can be images, metadata, fov, sensor information, everything. The image files and fov files are always kept together side-by-side with the same uuid so there isn't a specific database entry for those files, but it should be expected that the telemetry processor generates a fov file for each image, with that image's uuid.

Additionally, the acquisition controller created a metadata file for each telemetry frame. The telemetry processor will create a database entry with the highlights of that frame, as well as create a capture entry which will point to the metadata file.

During the development of that schema, there was some interest in creating a centralized index that would track all the images and their physical location even if those physical locations were not currently accessible. This way, analysis teams could at least know about the existence of some frames and request they be retrieved whenever possible, mainly in the event of missing coverage or bad quality images. This idea seems to have lost traction in the recent times but the infrastructure should allow for it should it be of interest again.