This Document describes an initiative in progress at the San Francisco Information Resource Management Field Office of the Department of Veterans Affairs. It was written under contract to DVA by Jule Meyn of Jule Meyn Consulting, Inc. and submitted to all vendors of FileMan to SQL products and other interested parties as a Request For Comments. SQLI may represent a major milestone in the development of FileMan.
FileMan is a mature database management system (DBMS) which serves over 100 Department of Veteran Affairs (DVA) medical installations. Implemented in the MUMPS programming language (M), it has reached a very high degree of development, demonstrating excellent performance, reliability and scalability. Developed and maintained by the DVA's San Francisco Information Resources Management Field Office (SFIRMFO), FileMan is in the public domain and has more installations outside the DVA than within, in medical and non-medical applications. In the first 20 release versions, FileMan was a host based system, available on-line only to users through terminals on the host computer or cluster. Version 21 provides a DBMS server interface (DBS) which sets the stage for extending access to non-host users on local and wide area networks.
In the relational model:
Any database that conforms to constraints I through VIII is a relational database. Because every element is a set, tuples are unordered and unique within relations, and attributes are unordered and unique within tuples. Because tuples are unique there must be at least one set of attributes in each tuple which is unique within the relation. One such set is chosen to be the primary key of the relation.
From an operational point of view, FileMan is hierarchic, not relational. It supports a data type, "Multiple", which permits the nesting of tables within tables recursively. Its paradigm is the single argument version of the M $ORDER command, where the path to any data item is top-down and left-to-right in a directed graph. But a point by point comparison of the contents of FileMan data dictionaries ^DIC and ^DD with the constraints enumerated above tells a different story:
If fields with multiple data type are ignored, with the sole exception of constraint VIII, FileMan data dictionaries define a fully relational database.
The analysis above is amply confirmed by successful efforts to manage FileMan databases with the SQL language, which was designed specifically to implement the relational model. Before using SQL, FileMan files must be projected as relational tables.
Because FileMan doesn't support repeating fields, all projected tables will be at least truly relational, or first normal form (1NF). Because DVA programming standards require that applications use the pointer data type to eliminate redundancy, functional dependencies among non-key columns, if any, are rare; this implies third normal form (3NF). Almost all primary key elements are system generated integers, guaranteeing zero functional dependency among key columns and irreducibility of the primary key. Therefore, most DVA tables will be projected in Boyce-Codd (BCNF), fifth (5NF) or higher Normal Form.
Even before Version 21 was released, several commercial vendors had implemented SQL interfaces to the FileMan database, some of them with well developed TCP/IP interfaces to Microsoft's Open DataBase Connectivity (ODBC) tool. Access from Microsoft SQL Server products (Access, Excel, etc.), Lotus 123, Paradox and others has been shown. Oracle Corporation has used its Transparent Gateway product to provide ad hoc query capability joining FileMan databases with DB2 and ODBC compliant ones across Wide Area Networks.
All current implementations of M support the SQL language and ODBC, either directly or using third party applications.
Each vendor maps FileMan into its own SQL data dictionary directly from M files which are under the control of SFIRMFO. FileMan data dictionary files are reasonably stable, but they are subject to extension and modification by the DVA at any time causing vendor software to execute from out-dated mapping.
Some features of the DBMS are hidden from the vendors, among them, column level security screening. Inability to support such features may impede implementation of vendor systems for security sensitive FileMan applications.
Each vendor has it's own methodology for generating SQL identifiers for FileMan objects. Inconsistent naming makes it hard to build SQL applications that are portable across FileMan sites using different vendors.
FileMan is, and has always been, a developing DBMS. The development team at SFIRMFO needs to insulate vendors from the details of data-dictionary structure so they can continue freely to enhance their product.
In March 1995, at the direction of the Office of the CIO of the Department of Veterans Affairs, a goal was established for Software Services to provide ODBC/SQL access to the Distributed Hospital Computer Program (DHCP) database. This feature will benefit sites intending to emply commercial relational database tools for ad hoc queries and, through ODBC, to provide a seamless interface between Commercial Off-The-Shelf Software (COTS) and DHCP.
As a first step toward this goal the SFIRMFO team will implement an SQL Interface (SQLI) which projects in simple form all the information required to define FileMan in purely relational terms. SQLI will relieve vendors of the necessity of "hacking" the M globals to determine certain parameters that are not explicit in FileMan and will isolate vendor code from proposed changes in the FileMan data dictionary.
SQLI will publish DVA Standard SQL identifiers for each table and column, project FileMan data types as SQL data types, functions and domains, and provide an "impure" semaphore to trigger vendor remapping when an object in the data dictionary changes. SQLI will be implemented as an integral part of DHCP.
The target date for completion of SQLI is March 15, 1997. It will be available for delivery to all Veterans Administration sites in April, 1997.
Date | Milestone |
October 22, 1996 | Distribution of RFC complete |
November 22, 1996 | End of RFC period |
December 15, 1996 | Approval of revised specifications based on RFC |
January 5, 1996 | SQLI ready for field test |
March 1, 1997 | End of field test, product acceptance |
March 31, 1997 | Completion of docmentation and training plan. End of project |
Table 1. SQLI Milestones
The remainder of this document is a proposed specification for SQLI. It is written in the present tense because, when the RFC period has expired, the review process is complete, and the product delivered, conformance to this document will be, in part, the definition of completion.
SQLI is implemented as a set of FileMan files within a single M global with no multiples (sub-files) except word processing fields. Because no functional dependencies exist in any file except on a simple primary key, a mapping of SQLI to SQL will be fully relational, in 5th normal form (5NF). Hereafter, the files of SQLI will be called tables, and the fields, columns. The words file and field are understood to refer to FileMan data dictionary globals.
The organization of SQLI tables mirrors SQL2 standard Data Definition Language syntax. Additional syntax has been added to support the definition of M global structures, virtual columns, key and output formats and other objects outside the scope of the SQL standard. This is reflected in the table names (actual names are prefixed by FM_ to avoid keyword conflicts in mapping applications). See Entity-Relationship Diagram (1.3).
The M global structure of FM_TABLE_ELEMENT (1.4.7) will look like:
^DMSQ("E",E_ID,0)=E_NAME^E_TABLE^E_TYPE^E_DESC ,"B",E_NAME,E_ID)="" ,"C",E_TABLE,E_ID)="" ,"CA",E_TABLE,E_TYPE,E_ID)=""
Column E_TABLE in this structure is a FileMan pointer data type which is a foreign key to a row in the FM_TABLE table. E_TYPE is a set-of-codes data type; codes are C for column, P for primary key and F for foreign key. Primary keys are named in this structure, although they aren't in the SQL standard. FM_TABLE_ELEMENT is indexed by E_NAME, E_TABLE and (E_TABLE, E_TYPE).
This diagram shows the functional relationships between SQLI tables .
Figure 1. Entity-Relationship Diagram
Each link represents a -equijoinii between a column and a primary key. One-to-many relationships are indicated by M, one-to-one by 1. Arrows indicate the direction one many.
The relationship between FM_DATA_TYPE and FM_OUTPUT_FORMAT may be overridden in either FM_DOMAIN or FM_COLUMN.
FM_FOREIGN_KEY is one-to-many with FM_COLUMN, one-to-one with FM_PRIMARY_KEY
and FM_TABLE.
Column names followed by a asterisk ("*") are required to be NOT NULL. Each table is subscripted by a single integer column called in FileMan an Internal Entry Number, or IEN. In SQL terms, each IEN in the following table is either a primary key, or a foreign key to a different table.
M code in the table uses the following symbols as place-holders:
Symbol |
Usage |
{I} |
Internal value of a column - used for storage |
{B} |
Base value of a column - used for computation |
{E} |
External value of a column - used for display |
{V[1..n]} |
Value - used for function arguments and output value |
{K[1..n]} |
Key value - {K} is the current key, {K1} is the first key, etc. |
Table 2. Place-holder Symbols in M Code
Table |
Section |
Table |
Section |
FM_SCHEMA |
|
FM_TABLE |
|
FM_TABLE_ELEMENT |
|
FM_COLUMN |
|
FM_PRIMARY_KEY |
|
FM_FOREIGN_KEY |
|
FM_DOMAIN |
|
FM_DATA_TYPE |
|
FM_KEY_FORMAT |
|
FM_OUTPUT_FORMAT |
|
FM_KEY_WORD |
|
Table 3. Directory to Tables
SQLI is conceptually organized by application, or "package". Each application group will have its own schema, for instance, SQLI itself is identified in schema DATA_DICTIONARY.
Column | Domain | Description |
FM_SCHEMA_ID* | INTEGER(3) | IEN of schema (Primary key) |
S_NAME* | CHARACTER(30) | Schema name, an SQL identifier |
S_SECURITY | CHARACTER(8) | M routine to check privileges |
S_DESCRIPTION | CHARACTER(60) | A short description of the mapped application group. |
Table 4. FM_SCHEMA Columns
FM_SCHEMA is indexed by S_NAME, which is unique by DVA site.
FileMan data types map easily to SQL although date, time and date-time have unique internal representations, and pointers, when directly referenced have the column attributes of the referenced identifier. SQLI provides a set of special domains which provide conversion of FileMan internal constructs to recognized SQL (and standard M) data types. Specifically, the three date-time valued domains will cast FileMan internal values to M $HOROLOG base values.
FileMan Data Type | FM_DOMAIN | FM_DATA_TYPE |
Free Text | CHARACTER | CHARACTER |
Numeric (>0 decimal places) | NUMERIC | NUMERIC |
Numeric (0 decimal places) | INTEGER | INTEGER |
Boolean | BOOLEAN | BOOLEAN |
Set of codes | FM_CODE_SET | CHARACTER |
Word processing | FM_MEMO | HUGE_CHARACTER |
Date only | FM_DATE | DATE |
Date-time | FM_MOMENT | DATE_TIME_STAMP |
MUMPS | MUMPS | CHARACTER |
Table 5. FileMan Data Type Projection
Table FM_DATA_TYPE is a simple list of SQL standard data types represented by the custom FileMan domains in FM_DOMAIN..
Column | Domain | Description |
FM_DATA_TYPE_ID* | FM_DATA_TYPE_ID | IEN of data type (Primary key) |
D_NAME* | CHARACTER(30) | Data type name, an SQL identifier |
D_COMMENT | CHARACTER(60) | A brief description |
D_OUTPUT_FORMAT | FM_OUTPUT_
FORMAT_ID |
IEN of FM_OUTPUT_FORMAT (1.4.5) |
D_OUTPUT_STRATEGY | CHARACTER(245) | Execute M code which converts value in X to output format in X |
Table 6. FM_DATA_TYPE Columns
FM_DATA_TYPE is indexed by D_NAME.
Column | Domain | Description |
FM_DOMAIN_ID* | FM_DOMAIN_ID | IEN of domain (Primary key) |
DM_NAME* | CHARACTER(30) | Domain name, SQL identifier |
DM_DATA_TYPE* | FM_DATA_TYPE_ID | IEN of FM_DATA_TYPE
( 1.4.2) |
DM_COMMENT | CHARACTER(60) | A brief description |
DM_TABLE | FM_TABLE_ID | IEN of FM_TABLE (1.4.6) referenced, only if data type is TABLE_ID |
DM_WIDTH | INTEGER(5) | Maximum width of external value |
DM_SCALE | INTEGER(1) | Default number of decimal places,
NUMERIC data types only |
DM_OUTPUT_FORMAT | INTEGER(2) | IEN of FM_OUTPUT_FORMAT
(1.4.5) |
DM_INT_EXPR | CHARACTER(250) | M expression to convert base values to internal format |
DM_INT_EXEC | CHARACTER(250) | M execute statement to convert base values to internal format |
DM_BASE_EXPR | CHARACTER(250) | M expression to convert internal values to base form |
DM_BASE_EXEC | CHARACTER(250) | M execute statement to convert internal value to base form |
Table 7. FM_DOMAIN Columns
The M expressions and executable code fragments use the symbols {I} and {B} to represent internal and base values respectively. Vendors may use these fragments in code generators by replacing the symbols with vendor specific variable names. Code fragments will use standard FileMan utility routines and will preserve all variables except the one representing the output symbol.
FM_DOMAIN is indexed by DM_NAME and DM_TABLE.
Key formats are used for index table primary keys to specify conversion
of the storage values of a column to an internal value when the two differ.
They must be used for "lossy" conversions such as Soundex and
lower-to-upper case conversions. In FileMan, subscript length is limited
to 30 characters, so a standard key format, LONG_CHARACTER, will be supplied
and installed for all index primary keys with maximum length greater than
30 characters.
Column | Domain | Description |
FM_KEY_FORMAT_ID* | FM_KEY_
FORMAT_ID |
IEN of key format, (Primary key) |
KF_NAME* | CHARACTER(30) | Key format name, SQL identifier |
KF_DATA_TYPE* | FM_DATA_TYPE_
ID |
IEN of FM_DATA_TYPE (1.4.2) of internal value |
KF_COMMENT | CHARACTER(60) | A brief description |
KF_INT_EXPR | CHARACTER(250) | M expression to convert internal value {I} to internal value. |
KF_INT_EXEC | CHARACTER(250) | M executable code to set internal value {I} to internal value {K} |
Table 8. FM_KEY_FORMAT Columns
FM_KEY_FORMAT is indexed by KF_NAME and KF_DATA_TYPE.
Output formats are used to specify the default output format for data types, domains and columns. Domain output format overrides data type, and column output format overrides domain.
Column | Domain | Description |
FM_OUTPUT_FORMAT_ID* | FM_OUTPUT_
FORMAT_ID |
IEN of output format, Primary key |
OF_NAME* | CHARACTER(30) | Output format name, SQL identifier |
OF_DATA_TYPE* | FM_DATA_TYPE_
ID |
IEN of data type (1.4.2) to which output format applies |
OF_COMMENT | CHARACTER(60) | A brief description |
OF_EXT_EXPR | CHARACTER(250) | M expression to convert base value to external value |
OF_EXT_EXEC | CHARACTER(250) | M executable code to convert base value to external value |
Table 9. FM_OUTPUT_FORMAT Columns
FM_OUTPUT_FORMAT is indexed by OF_NAME and OF_DATA_TYPE.
FileMan files, cross-reference structures and multiples (sub-files), including word processing fields, are projected into SQLI tables. Only FileMan default (regular) index types are projected; MUMPS, trigger, key-word and other types are not.
Column | Domain | Description |
FM_TABLE_ID* | FM_TABLE_ID | IEN of table (Primary key) |
T_NAME* | CHARACTER(30) | Recommended DVA SQL identifier for the table |
T_SCHEMA* | FM_SCHEMA_ID | IEN of FM_SCHEMA (1.4.1) |
T_COMMENT | CHARACTER(60) | Brief description of the table |
T_MASTER_TABLE | FM_TABLE_ID | IEN of FM_TABLE (1.4.6) of which this table is an index. |
T_VERSION_FM | INTEGER(10) | Version number of table, incremented by FileMan when file is modified. |
T_ROW_COUNT | INTEGER(10) | Number of rows in table |
T_SIZE | INTEGER(10) | Estimated average size in bytes of each row |
T_GLOBAL | CHARACTER(245) | M global variable name with keys represented by {K} |
T_FILE | NUMERIC | FileMan file number of table |
T_UPDATE | DATE | Date last updated |
Table 10. FM_TABLE Columns
FM_TABLE is indexed by T_NAME, T_SCHEMA, T_MASTER_TABLE and (T_SCHEMA, T_NAME). T_NAME is unique by T_SCHEMA.
In SQL Data Definition Language (DDL) a table is defined by CREATE TABLE <table-name> (table-element-commalist). Table elements include columns, foreign keys and primary keys. Columns and foreign keys are named objects whose names must be unique by table.
SQLI names both primary and foreign keys and gives them domains. Domains of column type elements have the data types shown in Table 6., but domains of primary and foreign keys have a special data type, PRIMARY_KEY. Every foreign key to a given table has the same domain as the primary key of that table. While not supported by SQL, this convention makes entity relationships more explicit and should help vendors maintain referential integrity constraints during mapping.
FM_TABLE_ELEMENT contains the two essential elements of an attribute in the relational model: attribute-name (E_NAME) and domain (E_DOMAIN). Elements not defined in the relational model, but necessary for physical mapping and formatting are contained in FM_COLUMN (1.4.8), FM_PRIMARY_KEY (1.4.9) and FM_FOREIGN_KEY (1.4.10).
Column | Domain | Description |
FM_TABLE_ELEMENT_ID* | FM_TBL_
ELEMENT_ID |
IEN of table (Primary key) |
E_NAME* | CHARACTER(30) | Recommended SQL identifier for the table element. Foreign keys are distinguished by the suffix _FK, primary keys by _PK |
E_DOMAIN* | FM_DOMAIN_ID | IEN of FM_DOMAIN (1.4.3) |
E_TABLE* | FM_TABLE_ID | IEN of FM_TABLE (1.4.6) |
E_TYPE* | CHARACTER(1) | "C" for columns, "F" for foreign keys and "P" for primary keys |
E_COMMENT | CHARACTER(60) | A short description |
E_FILE | NUMERIC | FileMan file number |
Table 11. FM_TABLE_ELEMENT Columns
FM_TABLE_ELEMENT is indexed by E_NAME, FM_DOMAIN, E_TABLE, E_TYPE and (E_TABLE, E_TYPE).
The projection of FileMan fields into columns is non-trivial, to say the least. FileMan supports the concept of fields representing multiples, or sub-files, while the SQL standard recognizes only scalar, or atomic, columns. In SQLI, all fields of multiple data type are decomposed into tables. FileMan's word processing multiple is also projected as a column for vendors who support a HUGE_CHARACTER or MEMO data type.
The pointer data type conforms to SQL's foreign key constraint, and is projected as such in SQLI. FileMan, however, allows direct reference to a pointer field, returning the text value of the primary identifier of the row reached by recursively following the pointer chain until the identifier is not itself a pointer. This usage is projected in SQLI by giving pointers a numeric or integer domain and an output format which uses DBS to return the value.
The variable pointer data type is not relationally atomic, the only true violation of the relational model in FileMan. In SQLI variable pointer fields are normalized by decomposition into one simple pointer column set (1.4.8.2) for each possible prefix value. They have a character domain and an output format to return the FileMan display value independent of source.
Projection of computed fields is complicated mildly by the fact that SQL DDL syntax supports only base data, while Data Manipulation Language supports expressions. For vendors who support virtual columns in their data dictionaries, FileMan computed fields are projected as columns flagged as such, permitting the vendor to retrieve their values using DBS.
An output format is provided for each set-of-codes value to display the long form.
Boolean fields will be supported by domain logic which returns a value of 0 for false or 1 for true.
Column | Domain | Description |
FM_COLUMN_ID* | FM_COLUMN_ID | IEN of column (Primary key) |
C_TBL_ELEMENT* | FM_TABLE_
ELEMENT_ID |
IEN of FM_TABLE_ELEMENT (1.4.7) |
C_WIDTH | INTEGER(3) | Maximum display width of column |
C_SCALE | INTEGER(1) | Default number of decimal points for NUMERIC data type only. |
C_OUTPUT_FORMAT | FM_OUTPUT_
FORMAT_ID |
IEN of FM_OUTPUT_FORMAT (1.4.5) |
C_FILE | NUMERIC | FileMan file number of column's file |
C_FIELD* | NUMERIC | FileMan field number from which column is derived. |
C_NOT_NULL | BOOLEAN | True if column must have a value |
C_SECURE | BOOLEAN | True if access to column is restricted. Value should be retrieved from DBS if true. |
C_VIRTUAL | BOOLEAN | True if column is computed. If true, the following columns are NULL and the value should be retrieved from DBS. |
C_PARENT | FM_COLUMN_ID | IEN of FM_COLUMN (1.4.8) to which C_GLOBAL is appended, or to which C_PIECE or C_EXTRACT is applied. |
C_GLOBAL | CHARACTER(30) | M fragment immediately to left of this column's identifier in M global variable name syntax. Ends with ")" for non-key columns. |
C_PIECE | INTEGER(2) | The $PIECE sequence argument in $P(C_PARENT,"^",sequence) |
C_EXTRACT_FROM | INTEGER(3) | The $EXTRACT first character to extract from C_PARENT |
C_EXTRACT_THRU | INTEGER(3) | The last $EXTRACT character to extract from C_PARENT |
C_COMPUTE_EXEC | CHARACTER(245) | M code execute to get value through DBS |
C_IDENTIFIER | CHARACTER(245) | Set-of-codes string, or pointer global root |
Table 12. FM_COLUMN Columns
FM_COLUMN is indexed by C_TABLE_ELEMENT, C_PARENT and C_TABLE, and by C_FILE by C_FIELD.
Primary key definitions are in a separate table because all FileMan multiples are projected as tables with more than one primary key element. Although primary keys are not ordered in SQL, FileMan keys and M globals in general are; thus the sequence number.
Primary keys represent the subscripts of FileMan files, which aren't, in general, reflected in the data dictionary. By default, they are system generated integers, but with design effort they may have any data type. In SQLI, every subscript is represented by a unique column whose IEN is contained in P_CLM_ELEMENT below.
Column | Domain | Description |
FM_PRIMARY_KEY_ID* | FM_PRIMARY_
KEY_ID |
IEN of primary key element, Primary key |
P_TBL_ELEMENT* | FM_TABLE_
ELEMENT_ID |
IEN of primary key's FM_TABLE_ELEMENT (1.4.7) |
P_COLUMN* | FM_COLUMN_ID
|
IEN of FM_COLUMN (1.4.8) of column in tables primary key |
P_SEQUENCE* | INTEGER(1) | Sequence number of primary key element |
P_KEY_FORMAT | FM_KEY_
FORMAT_ID |
IEN of FM_KEY_FORMAT (1.4.4) if any |
P_START_AT | CHARACTER(5) | M literal to initialize subscript for $ORDER |
P_END_IF | CHAR(250) | M expression using {K} which returns true when $ORDER reaches end-of-file, e.g.: '{K} |
P_ROW_COUNT | INTEGER(10) | Estimated number of key values for this element |
P_PRESELECT | CHAR(250) | Code to execute before selection |
P_KEY_FORMAT | FM_KEY_
FORMAT_ID |
IEN of FM_KEY_FORMAT (1.4.4) of this primary key |
Table 13. FM_PRIMARY_KEY Columns
FM_PRIMARY_KEY is indexed by P_TBL_ELEMENT and (P_TBL_ELEMENT, P_SEQUENCE).
SQLI projects one or more foreign keys for every instance of a pointer or variable pointer data type, and one for each ancestor table. Most contain only a single column, but tables with grandfather or older tables contain multiple key columns.
FM_FOREIGN_KEY matches columns in the referencing table to primary key elements in the referenced table. If required, the foreign key sequence number can be obtained from the primary key element row through F_PK_ELEMENT.
The referenced table is obtained from the domain of F_TBL_ELEMENT.
Column | Domain | Description |
FM_FOREIGN_KEY_ID* | FM_FOREIGN_KEY_
ID |
IEN of foreign key, Primary key |
F_TBL_ELEMENT* | FM_TABLE_
ELEMENT_ID |
IEN of table element (1.4.7) of this foreign key element |
F_PK_ELEMENT* | FM_PRIMARY_KEY
_ID |
IEN of primary key element (1.4.9) of the referenced table. |
F_CLM_ELEMENT* | FM_COLUMN_ID | IEN of column (1.4.8) which matches F_PK_ELEMENT |
Table 14. FM_FOREIGN_KEY Columns
FM_FOREIGN_KEY is indexed by F_TBL_ELEMENT.
Column | Domain | Description |
FM_KEY_WORD_ID | FM_KEY_WORD_ID | IEN of primary key |
KW_KEY_WORD | CHARACTER(30) | Key word reserved for SQL, ODBC or vendors. Not available as user defined SQL identifiers. |
Table 15. FM_KEY_WORD columns
FM_KEY_WORD is indexed by KW_KEY_WORD.
Consistent naming of columns and tables is a major goal of the project. Among the benefits is portability of queries across DVA sites, regardless of DVA vendor.
FileMan DBS provides complete value retrieval and update services for vendors, and is the safest way to reference the database but the nature of the relational model requires a more general approach to parsing and optimization. Therefor, vendors are encouraged to parse the files and extract internal values with optimized M code generated using the structural and statistical data in SQLI. Exceptions where the vendor should use DBS are noted in sections 1.5.5, 1.5.6 and 1.5.7 below.
SQLI publishes M strategies to present data in DVA default formats. Vendors are encouraged to use these as their own default formats. In particular, set-of-code and pointer data types are supported by output formats projected in SQLI.
Column T_VERSION_FM is incremented to a new version number whenever the SQLI projection of the table changes. If vendors keep track of the version number last mapped, the vendor's data-dictionary can easily be synchronized with SQLI whenever the table is to be referenced by SQL.
Although computed fields can be implemented by executing the internal M code of the data dictionary, SFIRMFO cannot guarantee preservation of variables or, indeed, the integrity of the executable code. Only DBS is safe for these calculations.
Sites are responsible for the security of their data. Applications which violate that security must be removed from the system.
DVA business rules are far too complex to emulate. Using DBS is the
only approved way to modify the databases.