MultiValue Database
MultiValue is a type of NoSQL and multidimensional database, typically considered synonymous with PICK, a database originally developed as the Pick operating system.
MultiValue databases include commercial products from Rocket Software, TigerLogic, jBASE, Revelation, Ladybridge, InterSystems, Northgate Information Solutions and other companies. These databases differ from a relational database in that they have features that support and encourage the use of attributes which can take a list of values, rather than all attributes being single-valued. They are often categorized with MUMPS within the category of post-relational databases, although the data model actually pre-dates the relational model. Unlike SQL-DBMS tools, most MultiValue databases can be accessed both with or without SQL.
History[edit]
Don Nelson designed the MultiValue data model in the early to mid-1960s.[1] Dick Pick, a developer at TRW, worked on the first implementation of this model for the US Army in 1965. Pick considered the software to be in the public domain because it was written for the military. This was but the first dispute regarding MultiValue databases that was addressed by the courts.[1]
Ken Simms wrote DataBASIC, sometimes known as S-BASIC, in the mid-70's. It was based on Dartmouth BASIC, but had enhanced features for data management. Simms played a lot of Star Trek while developing the language, in order to have the language function to his satisfaction.[2]
Three of the implementations of MultiValue: PICK version R77, Microdata Reality 3.x, and Prime Information 1.0, were very similar. In spite of attempts to standardize, particularly by International Spectrum and the Spectrum Manufacturers Association, who designed a logo for all to use, [3] there are no standards across MultiValue implementations. Subsequently, these flavors diverged, although with some cross-over. These streams of MultiValue database development could be classified as one stemming from PICK R83, one from Microdata Reality, and one from Prime Information.[4] Because of the differences, some implementations have provisions for supporting several flavors of the languages. An attempt to document the similarities and differences can be found at the PRDB [5]
Marketing groups and others in the industry over the years have classified MultiValue databases as pre-relational, post-relational, relational, and embedded, with detractors classifying it as legacy. It could now be classified asNoSQL. With a data model that aligns well with XML and that permits access with or without the use of SQL.
One reasonable hypothesis for this data model lasting more than 40 years, with new database implementations of the model even in the 21st century is that it provides database solutions in a big bang for the buck fashion. Historically, with industry benchmarks tied to SQL transactions, this has been a difficult hypothesis to test, although there are considerable anecdotes of failed attempts to get the functionality of a MultiValue application into arelational database framework.
In spite of a history of more than 40 years of implementations, starting with TRW, many in the MultiValue industry have remained current so that various MultiValue implementations now employ object-oriented versions of Data BASIC, support AJAX frameworks, and because no one needs to use SQL (but some can) they fit under the NoSQL umbrella. In fact, MultiValue developers were the first to acquire nosql domain names, likely prior to other database products classifying their offerings as NoSQL as well. MultiValue is a seasoned data model, but with so many vendors competing in this space, it has been constantly enhanced over the years.
Data model example[edit]
In a MultiValue database system:
- a Database is called an "Account"
- a Table is called a "File"
- a Column is an "Attribute" composed of "Multivalue attribute" and "Subvalue attribute" to store multiple values in the same attribute.
Data is stored using two separate files. A "File" to store raw data and a "Dictionary" to store the format for displaying the raw data.
For example, assume there's a file (table) called "PERSON". And in this file there is a attribute called "eMailAddress". The eMailAddress field can store a variable number of email address values in the single record.
So the list [joe@example.com, jdb@example.net, joe_bacde@example.org] can be stored and accessed via a single query / disk read when accessing the associated record.
To achieve the same (1-to-many) relationship within a traditional Relational Database System one would be required to create an additional table to store the variable number of email Addresses associated to a single "PERSON" record. However, modern Relational Database Systems do support this data model too. For example, in PostgreSQL one can set up a column of type Array of baseType (baseType being any PostgreSQL data type).
MultiValue DataBASIC
Like the Java programming language, the typical DataBASIC compiler compiles to P-code and runs in a P-machine. It has as many different implementations (compilers) as there are MultiValue databases.
Like PHP programming language, the DataBASIC language does all the typecasting for the programmer.
MultiValue Query Language
Known as ENGLISH, ACCESS, AQL, UniQuery, Retrieve, CMQL, and by many other names over the years, corresponding to the different MultiValue implementations, the MultiValue query language differs from SQL in several respects. Each query is issued against a single dictionary within the schema, which could be understood as a virtual file or a portal to the database through which to view the data.
- LIST PEOPLE LAST_NAME FIRST_NAME EMAIL_ADDRESSES WITH LAST_NAME LIKE "Van..."
The above statement would list all e-mail addresses for each person whose last name starts with "Van". A single entry would be output for each person, with multiple lines showing the multiple e-mail addresses (without repeating other data about the person).
No comments:
Post a Comment