This is an old revision of the document!
A Data Object (DO) is a collection of one or more other pieces that when aggregated together impart meaning to the whole. In other words, Data Object is an alternate way of saying “this group of data should be considered as one piece of data.”
A common example of DOs are a data tables where each row represent one Data Object and the columns represent the pieces of data that comprise the object. Some other examples of DOs include arrays, structures, collection of other Data Objects and scalar types (i.e., not the value but rather the type).
Another way to conceptualize a “data object” is as a way of compartmentalizing information into smaller, reusable pieces that are easier to understand and analyze with Subject Matter Experts (SMEs) usually being responsible for the definitions. It is a good idea to model Data Objects as concepts in Unified Modeling Language (UML) or System Modeling Language (SysML).
There is no single internal organization of a Data Object and it depends on the implementor of the Data Object to select and use the models that work best for the intended purpose of the Data Object. Some common models described by Grant1) are:
Data Objects are stored in memory or permenant storage using any number of architectures. In addition, regardless of how a Data Object is stored in Memory or on permanent storage, while in transit the data may use a different architecture. For example, a Relational DataBase Management System (RDBMS) may be transmitted over the wired using a set of key-value pairs such as JSON.
SQL Datastores are built around Structured Query Language (SQL). Most SQL Datastores are Relational DataBase Management System (RDBMS), which store data that is primarily structured. SQL has been in existence since the 1970's, and is standardized for use across many RDBMS systems. (See Grant)
NoSQL Datastores, as the name implies, generally do not rely on SQL, though some may use SQL-like languages. Some, in fact, say NoSQL stands for “Not only SQL.” NoSQL Datastores are generally less structured, more diverse, and newer overall than their SQL counterparts. Some common examples are listed below. (See Grant)