The MV DBMS Model

The Multi-Value name refers to the notion that this model supports multiple values in a single field of data. This eliminates the need for multiple joined tables, though in many cases it's simply appropriate to use multiple files for related data. Here is some customer data as an example:

01 ABC Corporation
02 1 N Main ] Suite 202
03 Home ] Work
04 555-1234 ] 555-4567 \ 555-7890

In this sample one customer has a single name. They also have a single address field which happens to have two lines. Since both of these lines are address lines, they are considered multiple values within the same field. Field 03 identifies the types of phone numbers available for this customer. Rather than having a separate table for customer phone numbers keyed with the customer ID and some unique identifier, it's simply convenient to keep all of this data in one place. Note that a bracket denotes multiple values in this field. The fourth field has two values which correspond to the two phone type values. These fields, called attributes, are synchronized. Coincidentally, this customer happens to have more than one Work phone number, with sub-values delimited by a backslash.

The general structure of the multivalue DBMS can be seen here:

SYSTEM
    ACCOUNT
        FILE
            ITEM
                ATTRIBUTE
                    VALUE
                        SUBVALUE
                            CHARACTERS

This looks very similar to an XML hierarchy. Everything you need can be found by selecting the right IDs for drill down. There are often more than one MV SYSTEM in an environment. Once you have connected to a system you select the Account that has the data and programs you need. An MV Account is equivalent to a single relational Database. The Account contains a collection of an unlimited number of Files, as a relational Database contains a collection of Tables. Files have an associated Dictionary to define the data, just like relational Tables have a schema. Each MV File can have an unlimited number of Items, which are the same as relational Records.

At the File (table) level we can do many forms of Selecting for Items (records), each of which is a dynamic array. The dynamic array is a collection of fields, as in relational, but then as described above, we can have associated Values spread across multiple Attributes, and this is where we get our MultiValued traits.

Having associated multivalues in a single item saves us from creating another table and doing a join, though in many cases that's really the best way to go too. When you have a customer ID in an invoice you do want to join to the customer file to get the name, country, total receivable balance, etc. Sometimes using values is a matter of flipping a coin, other times using values is much better than joining to another file, and other times using values or especially sub-values can be a mistake. At least we have the option, and in the relational world they're learning that this option can be beneficial.

Database queries and updates are usually made programmatically using a dialect of BASIC on the server. More verbose queries are made with SQL-like syntax (actually pre-dating SQL) and using the definitions from Dictionaries related to each file. For example:
SQL: SELECT * FROM CUSTS WHERE BAL > "500.00" ORDER-BY NAME.
MV: SELECT CUSTS WITH BAL > "500.00" BY NAME

For external, object oriented access into the environment, Nebula R&D recommends mv.NET with VB.NET, C#, and other languages supporting the .NET framework. mv.NET facilitates access into all popular MV DBMS platforms, to access dynamic arrays directly or to use more SQL-like query operations for integration with ADO.NET. Of course many other connectivity options are available for various MV environments.

More information will be provided here as time permits. Please contact us if you'd like to contribute basic information or links to other information sites about the Pick / MV data model.

© 2007 Nebula Research and Development