VAX/Rdb Relational Database
VAX/Rdb Relational Database
Debra S. Baddorf Document styling produced by
Originally written for CS425
IIT Computer Science Database course
30-NOV-1986
Digital's VAX Rdb/VMS (Relational DataBase) has relational conceptual and external models. Rdb/VMS runs on Digital's VAX or MicroVAX computers under the VMS or MicroVMS operating systems. There is also Rdb/ELN which runs under VAXELN, which has no general purpose operating system. Rdb supports concurrent use (maximum 512 users), providing both locking and rollback facilities. An Rdb database can span multiple disks, so the size of the database is limited only by the amount of storage available.
This command creates the VMS file which will contain the database definition and the data. Additionally, the database definitions are stored in the VAX CDD - Common Data Dictionary (a separate product) --- if available. This data dictionary allows user-written programs to include the record and field definitions into a program at compile time and thus be assured that the program's record variable structure matches that of the database.
Fields can be defined using the DEFINE FIELD command, or later within the DEFINE RELATION command. The DEFINE FIELD command allows some small measure of domain support in Rdb/VMS. The field-attributes clause includes selection of a datatype from the following choices:
The field-attributes clause can also include a VALID IF clause, which restricts attribute values to any set expressable as a conditional expression. Another field attribute clause is MISSING VALUE IS. The missing value clause indicates what to print in the field if it is null. An example might be
To ensure that a primary key field does not contain null values, you can specify
VALID IF NOT MISSING.
The missing value and validity clauses are both optional.
PRICE DATATYPE IS SIGNED WORD.
DISCOUNT_PRICE COMPUTED BY (PRICE * 0.9).
LATE_PAYMENT COMPUTED BY (PRICE * 1.1).
Protection can be defined for an entire database or for a relation or view using VMS access control lists (ACL's). Access rights delimit the actions a user is authorized to perform, and range from the privilege to read data or update data (modify, store, erase all separately grantable) to the privilege to make changes in the data definitions. ACL's allow specification of rights for an individual user, a class of users (by rights identifiers such as SECRETARIES, MANAGERS, DATAENTRY),
and access mode (BATCH, NETWORK, INTERACTIVE, LOCAL, DIALUP, REMOTE).
S.SNAME.
SUP_NAM FROM S.SNAME.
GRMWT COMPUTED BY (P.WEIGHT * 454).
The ``rse'' specified in the DEFINE VIEW statement is a record selection expression. It can include any data selection statements valid in Rdb.
Rdb permits data update in a view only if it is from one relation.
You cannot use DELETE on a field that is referenced by a view, a constraint, or a COMPUTED BY field. You must remove all references first. A new field could be added to our suppliers database by performing the following:
Rdb/VMS provides you with a feature that helps the database to maintain referential integrity. For example, to ensure that any shipments entered in the SP relation correspond to a valid supplier and part, you can define the following constraint:
ANY is the equivalent of the English ``there exists''. You cannot place constraints on views. Also, the use of many complex constraints can inhibit concurrent database access, since Rdb puts locks on any relation it needs to consult for a write transaction.
See Figure for examples of the define commands.
You begin a session with a database (the file containing the relations of interest) by using the INVOKE database command. When you are through, you use the FINISH database command. For each desired set of operations, you issue a START_TRANSACTION command, in which you specify whether you want a read only transaction or a write transaction, which relations are to be reserved, and whether the relations involved may be shared. All operations are recorded in a run-unit journal file until you either COMMIT or ROLLBACK the transaction. This insures that all the related changes are either made or not made together. After either a COMMIT or a ROLLBACK, the locks taken out by the system on all related tables are released. These locks include relations which are involved via a defined CONSTRAINT, as well as records actually specified in your query.
New records are added with the STORE command. Its format is (via an example):
See also Figure . Both STATUS and CITY can be left blank if that information is not yet available. Information can be added later using the MODIFY command.
To eliminate a record you no longer want, use ERASE.
Rdb's equivalence to SELECT or RETRIEVE is the FOR ... PRINT ... END_FOR block. You specify a range of records with selection expressions in the FOR block, then specify which fields are to be selected in the PRINT statement. In a way, the PRINT part of the process makes more sense than SQL's SELECT statement, because SQL ``selects'' the record for display purposes only. Rdb is clearer about its intent with the PRINT statement.
Rdb's set of permissible relational operators includes: = & > & UNIQUE
NE & LT & LE & CONTAINING
<> & < & <= & STARTING WITH
BETWEEN & ANY & MISSING & tabular } tex2html_wrap Example: Print the first five distinct last names with ``on''as the last 2 letters but 1.
We can list suppliers with the status value missing as follows:
The following statistical expressions are available:
Fields with MISSING values are omitted for all but the COUNT function.
RA: Rdb:
To stray from my proof for a moment, and do a further comparison of Rdb and SQL, I note that Rdb will, by default, give you all of the values in a projection, without eliminating the duplicates. If you want duplicates eliminated, use the REDUCED TO clause. You can also sort records as desired.
Note that the natural join over matching fields is easily done by using R CROSS S OVER CITY, but that you must specify the fields to be printed if you do not want both CITY fields. Also, the OVER CITY clause can be equivalently replaced by WITH SZ.CITY = PZ.CITY, if that is clearer or more natural.
Another journal, the ``run-unit journal'', keeps a record of any changes to the database definitions or the data itself. This is the file which holds copies of data before a transaction takes place, and to which the database is restored if a rollback is requested. This type of journaling is not optional (the other is); it also uses a separate file for each database user. Run unit journals are automatically applied after a system crash. These journals will help if the system crashes in the middle of a transaction. The after-image journaling is needed in case there is actually a failure of the medium on which the database resides.
Depending on the data being accessed (how the query is optimized; how tightly the records are restricted) the needed locking during transactions can be done at the file level, the index or the cluster level, or at the individual record level. The last, of course, permits the most activity to go on around it, without other users needing to wait until a lock is released.
There is therefore no need to make sure that only one program maintains a given foreign key. Foreign key comments can be placed in the relation definitions.
Due to the CONSTRAINT mechanism, I would venture to say that Rdb is closer to ``fully relational'' than is either SQL/DB2 or INGRES, though perhaps the amount I've learned about those two systems from Date does not do them full justice.
Keywords: EPICURE, RDCS, Rdb, Relational, Database
Distribution: normal, Joel Butler, Bob Trendler