The data objects stored in DB are pre-defined by c-structs in header files (located in $STAR/StDb/include directories). The database is fed the information about these c-structs which it stores in a pair of tables used to re-construct the c-struct definitions used for storing the data. This information can also be used to provide the memory allocation for the tables returned in the C++ API, but this can also be over-ridden to request any c-struct type allowed by the request. That is, as long as the table requested contained (at some time) items in the user-input c-struct description, the data will be return in the format requested.

To perform such operations, the two DB tables used are,

structure

schema

name Name of the c-struct

lastSchemaID more recent schema version identifier

ID internal index for the structure used by other tables

entryTime timestamp for when structure was last modified

Comment comments associated with structre

IsBinary Y/N enumeration for whether entire c-struct is stored as binary

name name of the element

type basic type of this element (e.g. float, int, ...)

storeType "ascii/bin" enumeration for this storage of this element

length array length of element (is 1 for non-arrays)

mask schema-version association

ID internal index for element used by other tables

structName named association with structure

structID index link to structure table's ID

position relative position in structure

offset offset in memory of binary stored structure( *** not used )

entryTime timestamp for when element was last modified

Comment comments associated with element

There are c-structs which are used for more than one purpose. For example, Daq's detector structure is common to all types of detectors but referenced by different names when a detector specific set of data is requested or stored. Thus a request for a structure is actually a request for a named reference which in many cases is simply the name of the structure but can be different.

This information is kept in the namedRef table which contains;

name reference name for a c-struct

ID internal index for the reference name used by other tables

structID index link to structure table's ID

entryTime timestamp for when named reference was last modified

Comment comments associated with named reference

Data is accessed from the database via reference contained in an index table called dataIndex. The purpose of this table is to provide access to specific rows of specific storage tables per the request information of name, timestamp, and version . Additional requests for specific element identifiers are also allowed (e.g. Sector01 of the tpc)via this index. The table contains the following fields;

count automatic internal row count on the index

nameID internal index to the namedRef table identifying data type stored

entryTime timestamp for when index row was last modified

schemaID link to the schema-version used for storing data

beginTime timestamp of beginning point of validity interval (endpoint is next relevant beginTime)

version version key for data instance

elementID sector, module, .... division of rows as needed

numRows for binary store where many rows are stored in a single mysql row

dataID index to row of the data storage table

There are 2 general type of storage tables used in the mysql database. The first type of storage makes use of MySQL basic storage types to store the data as specified by the schema of the c-struct. That is, each element of the c-struct is given a column in which values are recorded and can subsequently be queried against. The name of the table is the same as the name of the structure obtained from the structure table and referenced directly from the namedRef table. Within this structure, large arrays can be handled using binary storage (within mysql) by defining the storage type as being binary. Each row of each storage table contains a unique row id that is used by the dataIndex table.

example: The tpcElectronics table contains the following fields;

dataID unique row index

numberOfTimeBins

nominalGain mV/fC

samplingFrequency MHz

tZero us (microseconds)

adcCharge fC/adc count

adcConversion mV/adc count

averagePedestal adc counts

shapingTime ns

tau ns

The content of the stored data is extracted using the information about how it was stored from the namedRef, schema, & structure tables. The bytes table contains the following fields;

dataID unique row index

bytes the data blobs

The term Configurations within the Star Databases refers to ensembles of data that are linked together in a common "named" structure. The extent of a Configuration may span many Star Databases (i.e. a super-configuration) to encompass a entire production configuration but is also complete at each database. For example, there is a data ensemble for the Calibrations_tpc database that can be requested explicity but that can also be linked together with a Calibrations_svt, Calibrations_emc, ... configurations to form a Calibrations configuration.

The data ensembles are organized by a pair of tables found in each database. These tables are

Nodes

NodeRelation

The Nodes table contains the following fields;

Name node name

KeyName Key or version associated with this Node instance

NodeType DB, directory, Configuration, or table

baseLine Y/N for whether data is retrieveable without timestamp

elementID ID-list (e.g. sector-#s, wafer-#s,...) that Node contains

ID internal index for the reference name used by other tables

entryTime timestamp for when Node was last modified

Comment comments associated with Node

ID internal index for the reference by other tables

ParentID Node Id of a parent node

NodeID Node Id of a child node

entryTime timestamp for when relation was last modified

The Catalog structure in the database is used to organized different configurations into understandable groupings. This is much like a folder or directory system of configurations. Though very similar to the configuration database structure it is different in use. That is, the Nodes and NodeRelation tables de-reference configurations as a unique data ensemble per selection. The Catalog is used to de-references many similar configurations into groupings associated with tasks.

The Catalog table structure has only seen limited use in Online databases and is still under development. Currently there 2 tables associated with the catalog,

CatalogNodes

CatalogNodeRelation

The Nodes table contains the following fields;

Name Catalog Node Name

Author Author of this CatalogNode instance

ID internal index for the reference name used by other tables

entryTime timestamp for when Node was last modified

Comment comments associated with Node

ConfigID Index to a configuration

ID internal index for the reference by other tables

ParentID CatalogNode Id of a parent node

ChildID CatalogNode Id of a child node

entryTime timestamp for when relation was last modified

The Offline production chain does not use the Configurations & Catalog structures provided by the database. Rather an independent configuration is stored and retrieved via an offline table, tables_hierarchy, that is the kept within the St_db_Maker. This table contains the fields;

parnam name of parent to this row

tabnam name of table of this row

typenam type of table of this row