Search
Subscribe

Bookmark and Share

About this Blog

As enterprise supply chains and consumer demand chains have beome globalized, they continue to inefficiently share information “one-up/one-down”. Profound "bullwhip effects" in the chains cause managers to scramble with inventory shortages and consumers attempting to understand product recalls, especially food safety recalls. Add to this the increasing usage of personal mobile devices by managers and consumers seeking real-time information about products, materials and ingredient sources. The popularity of mobile devices with consumers is inexorably tugging at enterprise IT departments to shifting to apps and services. But both consumer and enterprise data is a proprietary asset that must be selectively shared to be efficiently shared.

About Steve Holcombe

Unless otherwise noted, all content on this company blog site is authored by Steve Holcombe as President & CEO of Pardalis, Inc. More profile information: View Steve Holcombe's profile on LinkedIn

Follow @WholeChainCom™ at each of its online locations:

« NY Times Bits: The Inexact Science Behind DMCA Takedown Notices | Main | US Patent 5,987,423: Object oriented technology framework for order processing (IBM Corporation) »
Thursday
Jun052008

Advantages of object oriented databases over relational databases

The following quoted text is taken from an IBM patent filed in 1991 and issued in 1994 entitled Access control policies for an object oriented database, including access control lists which span across object boundaries.

Here's the take-away quote:

"One shortcoming of relational databases is that access permission control is on a record basis and does not deal with objects, where objects represent complex entities and specific methods."

  • "In a relational database, data is viewed as rows and columns, where a row represents a record, in tables. In order to retrieve records that represent the spanning of multiple tables, relational operators, such as a join operation, are utilized. Although relational operators are used within applications or by users through a query language, these relational operations are not incorporated within the data such that the relational database manager can automatically intuit such relationships. In order to retrieve a record from the database, the user must have read permission for that record. In order to change the data in the record, the user must retrieve (select and fetch) the data into memory, update the record in memory, and then write the updated record to the database. The user must have permission to write the record before the database manager allows the previous data to be overwritten in the database. Moreover, in order to update the record in memory, the user must be cognizant of the column's attributes, such as whether that column contains integers, characters, strings etc.

    In an object oriented database, the navigation through the data is similar to that of the network model where an object oriented database manager traverses the relationships defined amongst the objects and subobjects. In contrast to the relational database model, relationships between objects and subobjects are defined through the data, and not through explicit operations. Moreover, in complex application environments, objects and their relationships usually show very complex internal structures and comprise larger number of properties; such properties include methods. In addition, the object oriented database model parallels the object oriented programming model in that one may inherit attributes and methods from predecessor objects. However, the object oriented programming model generally deals with objects that are temporal in nature, i.e., memory resident. The object oriented database model extends the programming model by allowing one to deal with objects that persist, i.e., are disk resident. One of the features of object oriented databases (analogous to the programming model) is to provide the ability to define generic operations, i.e. methods, which apply to the objects, for the purposes of manipulating and retrieving them. In the relational database model, all operations to retrieve and manipulate records are performed by using the database manager's application programming interface or query language. The object oriented methodology insulates the users of the database from the data representation and/or data structures that comprise objects. All retrieval and update operations may be performed through the use of these methods.

    Object-oriented database systems allow the semantics of a given environment to be modeled as a set of objects and relationships among them. Moreover, in complex application environments, objects and their relationships usually show very complex internal structures and comprise larger numbers of properties. With today's database systems, which are generally based upon a classical data model (hierarchical, network, or relational), they tend to be tailored to represent rather simple entities, thus resulting in large semantic gaps when dealing with more complex entities. In part this is true because one conceptual entity must be represented by a number of database objects (for example, records, tuples and so on). An object-oriented database system differs in that it offers a data model that allows the user to represent one conceptual real world entity by exactly one object or object class. This implies that an object-oriented model allows entities to be composed of subentities that are entities themselves, including recursive definition. There are several levels of object orientation:

    Structurally object-oriented: Allows one to define data structures to represent entities of any complexity.

    Operationally object-oriented: Includes generic operators to deal with complex objects in their entirety.

    Behaviorally object-oriented: Borrows types from the object-oriented programming paradigm, a data model that incorporates features to define object descriptor types of any complexity together with a set of specific operators (abstract data types).

    In summary, an object-oriented database paradigm offers increased modeling power by providing the ability to handle semantically meaningful objects rather than normalized tuples or single records. Such an approach greatly reduces the semantic gap between the real world and the database representation, while at the same time offering a more precise semantic definition of our real world.

    In the relational database model, access privileges may be set on the records such that grant and revoke authorization privileges can be determined per user of the database. The records are tagged with either read or write privileges for specific users. For example, the first record could be read by users A, B, and C, and only written by user C. Likewise, the second record could be tagged such that only user A has the permission to read, and only user A has the permission to write.

    For example, if a database contained payroll information, members of the payroll department may be able to read all of the payroll information for all departments except the payroll record for their payroll department. Only the manager of the payroll department would have the permission to read the record containing the payroll department data. If a user attempted to retrieve the records which did not define read privilege for the user, that user would not be granted the ability to see that record of data.

    One shortcoming of relational databases is that access permission control is on a record basis and does not deal with objects, where objects represent complex entities and specific methods."

PrintView Printer Friendly Version

EmailEmail Article to Friend

References (1)

References allow you to track sources for this article, as well as articles that were written in response to this article.

Reader Comments (1)

A great read but OOD has a long way to go. Take for instance the process of normalization which you described as a con of RDMS. Well, I believe normalization actually simplifies information to its smallest denominator, giving the process of building systems a lot more structure. You can also define structural integrity within records in a RDMS DB by adding Foreign Keys and of course Primary Keys, thus giving your "Entity" more "body". I guess with OOD, the approach is completely reversed because you have to envision whole entities which is a lot more difficult to implement and maintain.

August 16, 2012 | Unregistered CommenterAriel Pangilinan

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>