The data model design in Fig. 3 is based on the data structure of the FITS-IDI file and the information obtained via the real-time data collection process. Ten relational Sybase tables are needed to model the SMADB. Using this data model, the physical schema is designed (see Tables 1-10). Table 1 (RUN_LOG) contains the general information for each observing run. The information about the correlator that generates the visibility data is included in Table 2 (CORR). The mandatory keywords for each FITS-IDI file are stored in Table 3 (FITS_KEY). The general information on FITS tables in each FITS-IDI file is stored in Table 4 (TAB_NM). The parameters for frequency setup, source coordinates and velocities are stored in Tables 5 (FREQ), Table 6 (SOUR), and Table 7 (VELO). The information regarding the array geometry is saved in Table 8 (ARR_GEO). The information on the visibility table and information about each FITS-IDI file can be found in Table 9 (VIS) and Table 10 (DFILE), respectively. The tables are laid out as: The 1st column is the variable name; the 2nd column is the data type; and the comments on each variable is given in the 3rd column.
 |
The parameter ``obscode'' is unique for each observing run and has been designed as the cluster index in this particular relational database. The ``cluster'' index of a table (there can only be one per table) is used to indicate the physical ordering of table's row. Therefore, SMADB is organized based on the order of obscode assigned for each observing run.
In each of the tables, we also listed the ``nonclustered'' index. This index provides access to the table's data in an alternate order. Although access time via this type of index is not as good as by using the cluster index, nonclustered indexes allow the user to look at the table's data in more than one way. For example, we can look at the data in an order as the source's coordinates (either ra, or dec).
One ``composite'' index, full_filename (filename, location), is used in this database. This index is composed of two column variables in DFILE. Composite indexes are helpful when two or more columns are best searched as a unit.
The tables can be linked to each other through the common parameters (primary key) as indicated in Fig. 3.
We also list the byte size in the end of each table. A total of 1 Kbytes is estimated for each set of table data. For a typical observation track, the observing time is about 8 hrs. In other words, the SMA will daily produce three sets of table data that need to be stored into SMADB. Assuming 300 observing days each year, only about 1 Mbyte table data will be produced for the database per year if no text files of scientific proposals are considered to be stored in Sybase. Optionally, we could also store the text files of scientific proposal into Sybase. The size of the database would be roughly increased by an order of magnitude.