Northgate Reality

What is Reality & MultiValue?

New to Reality MultiValue databases, then read on...

Database Technology Background:
Relational (SQL) databases are prevalent owing to the IT marketplace being dominated by the remaining huge providers like Oracle, Microsoft and IBM. There are also the so called open and/or free offerings like MySQL and PostgreSQL which may not be so “open”, “free”, or suitable for resilient commercial use.

However, there is another way to describe and use data in a more efficient and flexible way...
... the MultiValue Way.

What Is MultiValue? (term created by reated by IDBMA www.intl-spectrum.com)
An efficient and flexible database technology designed to work in a virtual machine, but one that predates relational (SQL) databases. Current terminology includes multidimensional and post relational.

Compared to relational (SQL) databases…
… MultiValue (MV) has:

For each database table (file in MV):
Each field (attribute in MV) within a record/row (item in MV) can have repeating data elements (values in MV) and each value can have multiple sub-values – for relational databases each field is fixed to one value.
Each attribute, value and sub-value is dynamic in length – for relational databases each fiseld has a fixed length.
A more “natural language like” and efficient built-in enquiry and reporting tool...
... refer to the MV Query example below for comparison with a relational database.
Inbuilt database environment features that typically mean little to no ongoing maintenance – for relational databases they have always needed dedicated Database Administrators (DBAs).

When compared to relational databases these features of MV alone typically provide MultiValue Databases with higher performance, lower volumes of stored data, lower total cost of ownership – while being much more adaptable for application building and redevelopment.

What is Reality?
Reality is the original commercial MultiValue Database that includes a complete development and operational environment – inbuilt application programming, enquiry and print spooling. It also has integrated resilience from simple transaction based local data saving to twin FailSafe systems and, on recent versions of Reality, even remote disaster recovery systems.

Reality also offers extensive interoperability as it’s SQL-enabled with inbuilt features like ODBC/JDBC access, Web Services, ActiveX, TCP Socket and web-enabled programming. As binary data can also be efficiently stored within items, picture and sound files can reside in the same database rather than deploying separate web servers. Current versions are massively feature enhanced, when compared to the original model applied to early microcode on proprietary hardware going back to 1973. Reality retains the efficient and fully scalable underlying virtual machine model.

Reality Host Platforms
Reality has moved on from proprietary hardware and now runs under the latest open hardware/host operating systems from Sun Microsystems SPARC with Solaris, Intel with Windows/Linux and IBM pSeries with AIX. This means that as well as scaling up for additional users based on host scalability, you can also typically scale up the complexities of Reality data access without the overhead that’s imposed by typical relational database technology.

MultiValue V SQL Enquiry Example: “a real world example”

The following is an actual site example, where an SQL database is maintained alongside an MV. In order to verify the data between the two systems, some queries had to be written. Below is one of the SQL queries, followed by what was needed for MV to achieve the same thing.

SQL Query:
SELECT
category_minors.major_id
SUM(invoice_detail.qty_ship * product_master.pieces ) AS TotQty,
FROM
invoice_master
INNER JOIN invoice_detail ON
(invoice_master.invoice_id=invoice_detail.invoice_id)
INNER JOIN product_skus ON
(invoice_detail.sku_id=product_skus.sku_id)
INNER JOIN product_master ON
(product_skus.prod_id=product_master.prod_id)
INNER JOIN category_codes ON
(product_master.category_id=category_codes.category_id)
INNER JOIN category_minors ON
(category_codes.minor_id=category_minors.minor_id)
INNER JOIN category_majors ON
(category_minors.major_id=category_majors.major_id)
WHERE
(invoice_master.fiscal_year = 2008) AND
(invoice_master.fiscal_period = 4) AND
(category_minors.major_id = 'M101')
GROUP BY
category_minors.major_id

MV Query:
SORT INVOICES WITH F.YEAR = "2008" AND WITH F.PERIOD = "04" BY-EXP MAJOR.ID = "M101" TOTAL PCS.QTY DET-SUPP
…somewhat shorter, easier to understand and more efficient in resources to process.