The MV data structure is capable of storing data in a compact and reasonably easily read form. It has some of the characteristics of just about any form that has been used - heirarchical, relational, object - it "sort of" looks like them all. One expert even said it would look like "the next thing" and when XML came along it did!. However, it has some curiosities.
An MV system organises data as a string of writable characters using the eight bit ASCII character set. The first 32 characters (0-31) are unused. Characters 32 to 127 are the letters and numbers of English in the seven bit character set. The three characters 254, 253, and 252 are delimiters called attribute mark, value mark, and subvalue mark respectively. The original R83 Pick implementation used character 255 as a hidden delimiter called a segment mark. At least one implementation of MV uses character 128 as a null and character 251 as a further delimiter (text mark). The use of these specific high-order ASCII characters means that MV is incompatible with other character sets.
The most fundamental thing in MV is the idea of a record (item) consisting of a string of data split by the attribute mark into a number of fields (attributes). MV uses a dictionary definition to indicate the nature of these fields by reference to their postion. The dictionary definitions are, however, indicative and not prescriptive. I should note that in at least one implementation it is possible to overlay an SQL model which enforces prescriptive definitions. It is also true to say that many MV applications enforce this by various means - most of these depend on maintaining a site discipline.
Any attribute can be set up as a string consisting of repeated fields separated by value marks. These are called multivalues and are one of the most flexible, useful, and controversial aspects of the MV data structure. The use of multivalues is often regarded by relational data advocates as something akin to a heresy because it appears to violate a 'rule' of atomicity of data. If one here establishes the basic concept that MV is a data structure, rather than a DBMS, then the difficulty disappears. One is then left with a very compact method of grouping data that is in the nature of a list. There is an inherent order in the list which may or may not be meaningful. My own view is that it is unwise in the practical situation to assume the order of the list means anything.
A single-valued attribute is closely comparable to an attribute in XML. One with multiple values in it compares to repeated elements in XML.
A further subtlety is to link a number of attributes that are multivalued. These are called associated multivalues and are a way to define data that is tabular in nature. In this case the position of each value has meaning in that the 'nth' value in each attribute are linked with each other as part of a meaningful set of data. A good practical example is using associated multivalues to store the various fields on lines of an invoice in the same record as the invoice header information. This somewhat resembles the object model of data, but is more usually referred to as a 'nested relational' model. It compares with an XML element enclosing repeated sets of other elements.
MV allows each value to be further divided into subvalues. In my experience, this is not at all common - mainly because the enquiry language has no way to use this data. I have seen it used in defining complex structures used to drive specific '4GL' tools. The only other time I have seen this used (in a way I felt made sense) was in a product called ALL where an attribute could contain an entire subtable. The value marks were used to separate table rows and the subvalue marks were analogous to attribute marks in the standard MV data structure. I see this as being effectively the same thing as associated multivalues. It has the benefit of keeping related data close to each other in the physical sense (you lose the benefit of keeping similar data close to each other). It also might mean that data could be held more compactly, depending on the existence and nature of 'empty' fields that may occur in the data.
The enquiry language in MV (this goes by various names, but I will here use the R83 name 'Access') allows for a great deal of subtlety and power by means of complex dictionary definitions. Among the most useful mechanisms is the ability to refer to the contents of other files by using attributes or multivalues from one file to refer to keys (or parts of keys) in other files. In MV terminology, these referred to as 'T-correlatives'. Dictionary definitions used by Access contain a number of other correlatives. They can also use other things called 'conversions' (EG converting a day number to a date). These mechanisms provide very sophisticated means to extract and format data for reporting purposes. This is a large and somewhat specialised part of the MV system, so I won't go into any more detail.
It's a result of the age of the MV data structure, but unfortunately the use of the very high order ASCII characters as delimiters makes for difficulties with some of the European language sets. There are a parallel set of characters from 128 to 159 which, unlike MV's delimiters, are not used in the ISO 8859 character sets (which is the basis for most Internet protocols).
In the traditional MV model, an item (record) could have one level of nesting. That is, it could have within itself one or more tables; but it could not contain tables nested within tables (ignoring for now the slight extension of using multi-subvalues within associated multivalues). In my opinion this limitation is more apparent than real. It is extremely difficult to keep your mind focused on the information in a complex nested structure. I think MV goes just far enough in this regard.
Here are a couple of source papers
Nelson, Pick, Andrews 1967 GIM-1 paper
and a thought I had on extending the data structure SuperPick