PV Universal Database (PVU)
The PVU database will store PV information on a per-PV.FIELD basis to conveniently provide data for the configuration and maintenance of some of our packages. The database design will start off as simply as possible, while also being extensible for future enhancements. The central tables will not initially contain device data, just PV descriptive information. Subsystem extensions may well contain device data eventually.
Uses of the data include:
For an example channel name TRS8:KLY1:BODY:TEMP.HIHI
RECORD is the part of the name that doesn't include the field name (before the dot).
CHANNEL refers to the field name (the part after the dot).
There is one row in PVU_RECORD_TYPE per valid record type.
The master list of all records. The primary key REC_ID will be generated automatically from an Oracle sequence. Attributes in this table are common to all records.
There is one row in PVU_REC per RECORD (which some people might call a PV).
There are 1 to many rows in PVU_REC per PVU_RECORD_TYPE.
Contains all names for each record and the dates each name was valid, creating a history of names for each record. Most records will have one row in this table, the current record name, which would have an End_Date of NULL. If necessary for speed, we can duplicate the currently valid name in the PVU_REC table.
SUBNAME1 through 6 are the parsed components of each record name generated and stored in the VMS-based PV_LIST table. For example, record HB60:SVT:RADWARN:STAT:VSTA would have:
SUBNAME1 = HB60There are 1 to many PVU_REC_NAME rows per PVU_REC row.
SUBNAME2 = SVT
SUBNAME3 = RADWARN
SUBNAME4 = STAT
SUBNAME5 = VSTA
SUBNAME6 = null
Contains the list of in-use fields (channels - which some people might call a PV) for each record. The primary key is REC_ID, F_NAME. Legal values of F_NAME for each record are based on PVU_REC.R_TYPE, and can be validated in the PVU_DBD table (see below). Only channels used by one or more packages will be stored in this table.
There are 1 to many PVU_CHAN rows per PVU_REC row (so, REC_ID 999 might have PVU_CHAN rows with F_NAME VAL, LOLO, HOPR, etc. Every record has at least a VAL row.)
Contains the list of subsystems using each channel. For example, a channel that is tracked by Channel Watcher and ALH will have two rows in this table.
There are 0 to many PVU_CHAN_USE rows per PVU_CHAN row.
Basically DBD files loaded into the database. It will contain the master list of field names (PVU_CHAN.F_NAME) per record type. This table will be generated periodically by importing dbd file data into the table structure. Based on further analysis of what dbd data looks like, this could become multiple tables.
There are many PVU_DBD rows per record type.
A group of tables, each of which contains attributes for a particular package, per relevant channel. For example PVU_CW_CHAN contains channel attributes required by Channel Watcher. As some package requirements are more complex, PVU_package_CHAN might actually expand out into multi-table structures, such as the one to handle the ALH group hierarchy. Examples include:
PVU_ARCH_CHAN - channel archiver attributes (probably just a pointer to the CA Oracle DB)
PVU_ALH_CHAN - ALH attributes
PVU_CW_CHAN - Channel Watcher attributes
PVU_DB_CHAN - Alternate implementation of PVU_record-type-db-template_REC below
(The "package" part of the table names in this section could be set up to correspond to the values in PVU_CHAN_USE.Used_by.)
There are 0 to 1 rows in each PVU_package_CHAN table per PVU_CHAN row.
Group of tables, each of which contains values used for generating EPICS db template files, with configuration field values. For example, we would have PVU_AI_REC, PVU_MBBO_REC, etc. Examples include:
PVU_AI_REC - template params for AI recordsThere are 0 to 1 row in PVU_record-type-db-template_REC table per PVU_REC row.
PVU_BI - template params for BI records
Please contact Judy Rock with comments on the PVU database and/or this web page