Multivalue Database

A little Pick of history

Brief Explanation

Multivalue Concepts (Data Storage)

Reporting from a Table

Relating information to other tables for reporting

Programming in Unibasic

Journaling

Debugging

A little Pick of history

The earliest implementation of what is now called the Pick Database was in 1965 by Don Nelson and Richard Pick at TRW Inc., which was later used by the U.S. Army. Originally called the Generalized Information Retrieval Language Systems (GIRLS) on an IBM S/360.

Richard Pick died in October, 1994. He was the driving force behind all Pick systems, with extremely strong views against Relational Database Management Systems and the Structured Query Language.

He was quoted in one trade journal as saying that "...SQL is brain­dead...". Advanced PICK, which is the latest implementation and runs under Unix, now supports SQL!

Microdata Corporation became the first company in 1973 to release a commercial implementation of the Pick Operating System. This product became to be know as Reality Operating System

After parting with Microdata, Dick Pick founded Pick & Associates, which is now known as Pick Systems. Dick Pick had a history of litigation to protect his intellectual property, most court cases were successful The most crucial of these was the Pick versus Microdata case, which resulted in both parties retaining the rights to their own implementation, but only Pick Systems with the right to license their implementation. Pick Systems and their licensees, meanwhile successfully ported their operating system to an amazing array of hardware platforms.

In 1984 a group of Microdata VARs formed a 'consortium', which was established with a charter, which at the time was very farsighted . To develop a Pick database under the Unix operating system. At the time, Unix was even more primitive and not in any one's wildest dreams ever considered to be a viable "commercial" operating system.  Now known as Vmark Software, it is probably (other vendors do not publish sales revenue) the leading supplier of Pick databases in the world today, in terms of annual sales revenue.

At the time the product was conceived, the only Pick database not running under the Pick operating system was, Prime INFORMATION. Hence many of the base functionality of the core product stems from this product. Undoubtably, Vmark Software had to settle court cases both with Pick Systems and Prime Computer regarding the basis of their product.

http://www.pcsnet.com.br/d3datapro.htm

The U2 databases consist of UniVerse and Unidata (hence U2), which were originally developed by VMark and Unidata respectively. Subsequently, the two companies merged to become Ardent Software and this in turn was bought by Informix, primarily for the company's DataStage ETL (extract, transform and load) tool.  

The U2 databases are and how they are differ from standard databases:

UniVerse and Unidata are relational databases with a difference. In conventional relational environments the first rule of relational technology is that you cannot have something called a repeating group. This would occur, for example, if you stored order header details and then all the order line details that pertained to that order within the same database table. In a relational database the order header details and order lines are stored in separate tables. Technically, this is known as First Normal Form. All standard relational databases adhere to this principle.

Brief Explanation

However, as it happens, relational algebra (which is based on set theory) does not actually require adherence to First Normal Form. If you are careful enough about your implementation then you can preserve the integrity of relational algebra while allowing the use of repeating groups. This is what the U2 databases do and, for this reason, they are sometimes referred to as NF2 databases (Non First Normal Form).

NF2 has two big advantages. The first is that you get better performance. By storing order lines with header details you can retrieve all relevant details from a single table rather than multiple tables. Secondly, you have far fewer tables. This makes the organization of the database very much easier to understand and manage. Not surprisingly, therefore, the NF2 databases have proved very popular with VARs and software houses that want an easily managed, "fire­and­forget" database that they can embed within their software packages. As a result, the U2 databases are leading providers within the embedded database market, behind Oracle and Progress.

http://www.theregister.co.uk/content/53/29457.html

Multivalue Implementations PosessCommand­line interface Provides an interface to all other functions. 

Terminal Control Language (TCL), PEFORM, etc.

An editor Usually a line­editor, but more recent implementations incorporate full­screen editors with programmable function­keys on industry standard terminals or emulators. This is the key tool, as it allows to create, maintain and delete virtually any element within the database. ED, EDFS, UV.VI, etc.

Database Manager Responsible for the management of all aspects of the files and interfaces directly to the operating system. It determines the file type (hashing method), space allocation, maintains file integrity via various utilities

Query Language

http://members.ozemail.com.au/~dhona/pick.html

Multivalue Concepts Data StorageAll data is held in a data “file” which is similar to a table

These files are created with a CREATE.FILE command and consist of two operating system files.

The data file with the name used in the create file command

The dictionary file which is the same name preceded with a D_

These files are placed in the “account” which is the present working directory when the client program is started.  (the udt)

The vocabulary or VOC file is a file in the account that contains information about all data files,  cataloged programs, directories, keywords, menus, multilevel files, synonyms and procedures.

Files and programs can be in other directories as long as their vocabulary entry correctly points to the other location by its path.

The Voc file is really just a data file with a special name.  It too has it's own dictionary just like any other data file.   (D_VOC)

A files dictionary define the files attributes.

A data file is sometimes referred to as a dynamic file.

A file is a collection of records that are somehow related.

A record is a group of related attributes.

The Primary key or @ID of a record is THE unique id for the record.

Each record  is a dynamic array.Delimiter Symbol Ascii Value Name Description

NA 255 @RM or record mark Marks the end of a record~ 254 @AM or attribute mark Marks the end of an attibute} 253 @VM or value mark Marks the end of a value| 252 @SM or subvalue mark Marks the end of a subvalue{ 251 @TM or text mark Marks the point where values wrap to a new line

A dictionary file is like a data file in that it is a collection of records containing attributes.

DICT.DICT is the master dictionary of dictionaries. (not recommended to edit)

Dictionary records can be one of a few types:  D,V,X,PH and SQ.  The most important of which are the D and V.  D is for dictionary item and V is for verb.

D types define a name for an attribute and there can be as many of these synonyms as desired.  A name for an attribute is required for queries and for reports, but not for programs unless it uses queries on that attribute.

Dictionary Files

V type dictionary records are virtual attributes or verbs and can be used to relate information in this table to information in another table.

Verbs can contain operators, extractors, functions and calls to unibasic subroutines.

Dictionaries: Relating Information

X dictionary records are user defined.  May be used for sequences or any other user defined purpose.

PH records are for phrases.  These are parts of uniquery sentences.

SQ type records are for converting dictionaries for SQL/ODBC compliance.

Dictionary Continued

Uniquery is the language used to perform queries against unidata files and records.  

Uniquery is used to produce reports based on the dictionary records defined.

Uniquery is also used in unibasic programs to select record lists for process

Uniquery statements are not used to update or add to tables.

Uniquerry statements must contain a verb (or command) followed by a file name.

The command can be COUNT, LIST, SELECT, SORT, SSELECT, SUM or USHOW.

Uniquery Reporting

The sentence takes the form: command [DICT] filename [display attributes] [record_IDs] [selection criterion] [sorting criterion]

When multivalued attributes are listed, each value is displayed.  Attributes can be associated with each other in the dictionary.  Associated attributes will display like a table within a table during a uniquery list command.

Other useful keywords are TOTAL, DET­SUPP and the BREAK­ON keyword for summing attributes by some other attribute and ID­SUPP to suppress reporting the unique identifier.

Views are not supported in uniquery and must be accomplished within the verbs of the dictionary.

Data access is achieved through a read statement.

The file must first be openedOPEN 'PART' TO PARTFILE ELSE PRINT “Failed to open “: "PART";ERROR=1

READ PART.REC FROM PARTFILE,PART.ID THEN

     PRINT PART.ID:” “:PART.REC<1>:” “:PART.REC<1>

END

The record from the data file is a dynamic array and is read into the variable as a dynamic array.

The <> operator is an extraction operator and is used to designate specific information in the array that is desired.

Unibasic Programming

Using the attributes, values and subvalues in the dynamic array is achieved with the extraction operator.

<attribute,value,sub value>

This is very similar to an multidimensional array in c with some differences.

all variables can be dynamic arrays weather they use multi dimensions or not depending on how they are used.

no need to declare the dimensions, size or data type.

no ability to declare the dimensions, size or data type.

data type is kept track of by the programmer and not the database.  (with the exception of the dictionary for reporting purposes only)

dynamic arrays can shrink to null and grow at will in all dimensions without fuss.

Another way to read from the database is with MATREAD

DIM PART.REC(200)

MATREAD PART.REC FROM PARTFILE,PART.ID THEN

  FOR CNT = 1 TO DCOUNT(PART.REC(39),VM)

     PRINT PART.ID:” “:PART.REC(39)<1,CNT>:” “:PART.REC(40)<1,CNT>

  NEXT CNT

END

Each element of the matrix is an attribute from the record which is a dynamic array.

This is used when performance may be an issue on larger records.

Another way to read from the database is with READVREADV PART.AT FROM PARTFILE,PART.ID,1 ELSE PART.AT=””

PRINT PART.ID:” “:PART.AT

The variable now has the value of attribute 1 of the PART.ID record in the part file.

If you don't need all of the attributes of a record, you don't need to get them.

Writing a record is achieved with a WRITE statement.

Record locking is achieved with a READU keyword.

READU PART.REC FROM PARTFILE,PART.ID THEN

     PART.REC<1>=INPUTVALUE

     PRINT PART.ID:” “:PART.REC<1>

     WRITEU PART.REC ON PARTFILE,PART.ID

END

The execution of the write command clears the lock.

The lock can be unlocked with a RELEASE command.

Programs with READU can be written to request user interaction if the record is locked.  The above example would cause the user to be frozen until the lock is released.  

CMD='SELECT BACK WITH CUST.NO = “MYCUST”'EXECUTE CMD CAPTURING OUTPUTLOOP  READNEXT BACK.ID ELSE BACK.ID="< EOF >"UNTIL BACK.ID="< EOF >" DO  BACK.LIST<­1>=BACK.IDREPEAT

LCNT=DCOUNT(BACK.LIST,AM)FOR BACKCOUNT = 1 TO LCNT  BACK.ID = BACK.LIST<BACKCOUNT>  MATREAD BACK.REC FROM BACK.FV, BACK.ID THEN    PRINT BACK.ID:" ":BACK.REC(198)<1,1,4>  ENDNEXT BACKCOUNT

Programs can use, however they do not require a query to decide what records to read.

Data types are converted in programs by the programmer.  In reports data is converted by the conversion type in the dictionary.

TOT.LBS=OCONV(TOT.LBS,"MD3")TOT.EXT=OCONV(TOT.EXT,"MD2")TOT.COST=OCONV(TOT.COST,"MD2")DATE.STMT = 'WITH 42 GE "':OCONV(BEG.DATE,"D2/"):'"'DATE.STMT = DATE.STMT:' AND WITH 42 LE "':OCONV(END.DATE,"D2/"):'"'MSG = MSG:'FROM ':OCONV(BEG.DATE,"D2/"):' TO ':OCONV(END.DATE,"D2/")

Journaling

Journaling is a feature of Unidata used for the purpose of fault tolerance.

A journal is timestamped writing of all records that are modified to a file.

This file can be a regular file or a tape device.

In case of emergency, a copy of the database from last nights tape and the journal file can bring the database back to it's status just before catastrophic failure.

Unibasic DebuggingVery useful is the ability to debug programs.

Unidata comes with a debugger capable of

stopping a DEBUG statements in the program or being run with a debug flag

Establishing breakpoints, tracepoints and watches by line and/or by condition.

Viewing and watching data values.

Performing TCL and operating system commands.

Dual terminal debugging.

Viewing data in a record in a data file.