DMAWK(ID:7629/)Database language based on AWKRelated languages
References: Introduction Modern languages for specifying database operations typically rely on relational descriptions, implicit retrieval strategies, and sometimes natural-language input. Often they are frustrating to implement and to use. This paper describes a different kind of programmed interface for a database: the DMAWK language for database reports, queries, and repairs. DMAWK is expressly algorithmic and resembles AWK, the UNIX* system's data-processing language. Though DMAWK is tailored for the TUXEDO* transaction-processing and database system, its basic design is portable to other database systems. Extract: Design Considerations Design Considerations The new language was designed with these tacit considerations: -- It should use a syntax familiar to programmers. -- It should let commonly useful operations be specified easily. -- It must express TUXEDO's file, record, and field structure. -- It should avoid deadlocks and other temporary database failures. -- It must not delete many records in a single operation. -- It should avoid infinite loops. DMAWK (Database-Management Awk) was written to satisfy these constraints. Its syntax is described below. The only loop construct available is a loop through the records of a database file, which is guaranteed to be finite. Only one record at a time can be deleted. Every modification to a database file occurs in a separate transaction, so deadlocks are almost impossible. (Deadlocks remain possible because of TUXEDO's use of indexing files.) The retry function, described later, provides a "'safety net" against deadlocks. DMAWK was not formally specified in advance. As it was programmed, it evolved in accordance with its intended applications: database repairs and reports. Extract: Data types Data types DMAWK recognizes these data types: integers, reals, strings, records, field sets, and the null object. A record is a set, possibly empty, of field--value pairs. Several pairs may exist for the same field, and are maintained in sequence, numbered from zero. A typical record looks like this: K_PAT_ID 123486 K_EXM_GMT 602468024 K_CREAT_STAT RIS0 E_ID RIS00602468024 E_SH_DIAG Possible multiple E_SH DIAG or Lyme disease sclerosis TUXEDO fields may be long or short integers, long or short reals, single characters, or variable-length arrays of characters with or without null-byte terminators. A field's data type is determined by table lookup. In DMAWK fields within a record are specified by a period: patreo. K_PAT_ID = "123-48-6789" Multiple occurrences of the same field in a record are distinguished by subscripts in brackets: reo. E_SH_DIAG[ 1 ] = "or Lyme disease" An empty subscript denotes the last occurrence, except that when you assign a value to it, it denotes a new occurrence after the last one. For example, myreo.K_PAT_ID[0] = "101"; myreo.K_PAT_ID[ ] = "202" ; myreo.K_PAT_ID[ ] = "303" ; assigns values to the 0th, 1st, and 2nd occurrences of K PAT ID. You can count the occurrences of a field with the ? operator; e.g., exam. E_MIMG_CNT = inreo?K_IMG_NO If you reference a field without a subscript, the field must occur uniquely in the record. If you assign a value to a field without a subscript, after the assignment the record will contain exactly one occurrence of the field. A field set is a set of fields without values, used to extract a set of selected field values from a record while ignoring its other fields. wanted = fieldset("K PAT ID","E ID"); shortrec = extract(dbrecord, wanted); DMAWK recognizes numeric constants (including floating-point), strings enclosed in double quotes, and the special symbol @, which denotes the null object. A variable may take any type of value. A reference to a field in a variable implicitly establishes its value as a record. Extract: Discussion Discussion An early application of DMAWK was to rewrite GETARCLST, a popular report program written in C. The C code contained 300 non-comment lines and occupied 300,000 bytes when compiled. The equivalent DMAWK program contains 27 non-comment lines. GETARCLST used to be maintainable only by experienced C programmers; it is now so simple that many of our customers can modify it to suit themselves. At present our system comes with eight DMAWK programs. Most of them perform mass deletions from or single corrections to the database, and are driven by interactive shell scripts. DMAWK is also used in debugging and customer support, to display or alter a relevant set of database records. DMAWK lacks some common programming constructs because they were not urgently needed for applications. For example, it has no else statement. Alternative logic must be specified by parallel if statements: if (exam. E_STATUS == @) { }; if (exam. E_STATUS I= @) { }; The best that can be said for this style is that it makes conditional logic unmistakable. In DMAWK you cannot loop on input, on the occurrences of a field in a record, or even on a simple finite range of numbers. Arithmetic is possible only by artifice: # Add one to image.K_IMG_NO. image. K_IMG_NO = length(sprint("z%*s", image.K_IMG_NO, "zzzzzzzzzz")) The above example fails for values greater than 10. DMAWK has no implicit recovery for missing fields. If some data records may lack "mandatory" fields, the programmer must check for the possibility: for (exam in EXAM) { if (exam?E_EXM_DATE == @) print (file=2) "no exam date for "exam. K_PAT_ID; if (exam. E_EXM_DATE != @) { } } Otherwise the program will fail as soon as it encounters a defective record. DMAWK ignores TUXEDO's database transaction system. Every database modification is a separate transaction; there is no way to make a group of modifications stand or fail together. This limits DMAWK to applications that do not require database modifications to be synchronized. These limitations aside, DMAWK amply satisfies its design goals. With it database utilities can be written quickly and reliably, and systematic database repairs can be performed with small tailor-made programs running in the background. The ordeal of repairing a customer's data records one by one is a thing of the past. Since DMAWK uses explicit programming constructs, it is not for the non-programmer. But it is simple enough for inexperienced programmers to use effectively. Though its input language is designed for CommView databases, it could in theory be adapted to any database with a record structure. Simple algorithmic languages like DMAXVK, while lacking the glamour of fourth-generation database languages, can sometimes be of greater help to users. in SIGPLAN Notices 26(05) May 1991 view details |