What is the Object-Relational Model?
The object-relational model is designed to provide a relational database management that allows developers to integrate databases with their data types and methods. It is essentially a relational model that allows users to integrate object-oriented features into it.
This design is most recently shown in the Nordic Object/Relational Model. The primary function of this new object-relational model is to more power, greater flexibility, better performance, and greater data integrity then those that came before it.
Some of the benefits that are offered by the Object-Relational Model include:
- Extensibility - Users are able to extend the capability of the database server; this can be done by defining new data types, as well as user-defined patterns. This allows the user to store and manage data. .
- Complex types - It allows users to define new data types that combine one or more of the currently existing data types. Complex types aid in better flexibility in organizing the data on a structure made up of columns and tables .
- Inheritance - Users are able to define objects or types and tables that procure the properties of other objects, as well as add new properties that are specific to the object that has been defined. .
- A field may also contain an object with attributes and operations. ..
- Complex objects can be stored in relational tables.
The object-relational database management systems which are also known as ORDBMS, these systems provide an addition of new and extensive object storage capabilities to the relational models at the center of the more modern information systems of today.
These services assimilate the management of conventional fielded data, more complex objects such as a time-series or more detailed geospatial data and varied dualistic media such as audio, video, images, and applets.
This can be done due to the model working to summarize methods with data structures, the ORDBMS server can implement complex analytical data and data management operations to explore and change multimedia and other more complex objects.
Database developers can now work with somewhat familiar tabular structures and data definition but with more power and capabilities. This also allows them to perform such task all the while assimilating new object management possibilities. Also the query and procedural languages and the call interfaces in the object relational database management systems are familiar.
The main function of the object relational model is to combine the convenience of the relational model with the object model. The benefits of this combination range from scalability to support for rich data types.
However, the relational model has to be drastically modified in order to support the classic features of the object oriented programming. This creates some specific characteristics for the object-relational model.
Some of these characteristics include:
- Base Data type extension
- Support complex objects
- Inheritance (which we discussed in more detail above.)
- And finally Rule systems
The History of the Object-Relational Model
As said before the Object-Relational model is a combination of the Relational Model and the Object Oriented Model. The Relational Model made its way into the world of data in the 1970s; it was a hit but managed to leave developers wanting more flexibility and capability.
Later in the 1990s the Object-Relational model was developed, combining the advantages of its most successful predecessors such as; user defined data types, user defined functions, and inheritance and sub-classes.
This model grew from the research conducted in the 1990s. The researches many goal was to extend the capabilities of the relational model by including objects oriented concepts. It was a success.
Object-Relational mapping is a programming method used to convert data between incompatible data type systems in relational databases and object oriented languages. Here are some basics when it comes to mapping. Java classes can be mapped to relational database management systems tables.
The easiest way to begin mapping between a enduring class and a table is one-on-one. In a case such as this, all of the attributes in the enduring class are represented by all of the columns of the table. Each case in point of a business class is then in turn stored in a row of that table.
Though this particular type of mapping is pretty straightforward, it can conflict with the existing object and entity-relation (we discussed entities in the previous article) models. This is partially due to the fact that the goal of the object modeling is to model an organizational process using real world objects, (we will discuss more about object modeling in the following article), where as the goal of entity-relational modeling is to normalize and retrieve data in a quick manner.
Due to this two types of class to table modeling methods have been adopted by most users. This was to help overcome the issues caused by differences between the relational and object models. The two methods are known as SUBSET mapping and SUPERSET mapping.
Let’s talk briefly about these two methods.
SUBSET Mapping is used mostly when all of the attributes of a class are mapped to the same table. This method is useful also when a class is not concerned with a portion of the columns of its table in the database due to the fact that they are not a part of the business model.
SUBSET Mapping is used to create projection classes as well for tables with a sizable number of columns. A projection class contains enough information to enable the user to choose a row for complete retrieval from a database.
This essentially reduces the amount of information passed through out the network. This type of mapping can also be used to help may a class inheritance tree to a table of using filters.
Now let’s consider SUPERSET Mapping. With a persistent class the superset mapping method holds attributes taken from columns of more then one table. This particular method of mapping is also known as table spanning.
Mapping using the SUPERSET method is meant to create view classes that cover the underlying data model, or to map a class inheritance tree to a database by using a Vertical mapping tactic.
The final word
There are millions of other aspects and advantages to this model. The Object-Relational model does what no other single model before it could do. By combining the strongest points of those that did come before it, this model has surpasses expectations, and taken on a definitive role in database technology. Despite what models follow it, this model is here to stay.
Here is wonderful example of this model.
What is the Object Model?
Unlike the relational model, where a complicated data structure needs to be flattened to fit into tables or even joined from those tables to form the in-memory structure, object models have little or no performance overhead used to store or retrieve a hierarchy of inter-related objects. The one-to-one mapping of object programming languages to the database object had two major benefits over the older storage methods. One, it offers a higher performance management of objects. Secondly, it allows for better management of the more complex inter-relationships between objects. These two aspects make object modeling much better suited to support applications such as a financial portfolio risk analysis system, telecommunications service applications, design and manufacturing systems, and even patient record systems, all of which have very complex relationships between data.
Are there different types of object models?
So what exactly is a Document Object Model? Well you might see it often referred to as a DOM, this model is a platform and language neutral interface that allows programs or script to vigorously access as well as update the content, structures, and styles of documents. The document can then be processed further and the results can be incorporated back into the contents of the page.
The Component Object Model which is also referred to as COM, this model is basically a component software architecture that enables users to build applications and systems alike from components supplied by different software vendors. Component Object Models are the underlying design that forms the foundation for some higher-level software services. Some of these services include those that are provided by OLE. Any PC user may be surprised to learn that a COM is also known as ActiveX. An application we are all familiar with, especially those of use that spend a lot of time surfing the internet.
Many of the traditional operating systems were designed to deal with only the application binaries and not the actual components. Due to this the benefits of good component-oriented designs have until now never gone beyond the compilation step. In a world that is object-centric it is confusing that our operating systems still can not recognize objects. Instead our operating systems have been dealing with only application binaries or EXEs. This prevented objects in one process from communication with objects in a different process while using their own defined method.
History
The object model really hit the programming scene in the mid-1990s. Around October of 1998 the first specification of the Document Object model was released by W3C, it was known as DOM 1. Later in 2000 DOM 2 followed, it surpassed its older version by including specifics with the style sheet Object Model and style information manipulation. Most recently DOM 3 wowed the programming world with its release in 2004. Thus far there have been no more current releases, as of now we are still using the DOM 3 model, and it has served us well.
The history of the Component Object Model is a bit lengthier; we will summarize its more dramatic points. DDE was one of the very first methods of inter-process communication. It allowed sending and receiving communications or messages between applications. This is also sometimes referred to as a conversation between applications. At this point I think it is important to point that Windows is the leading Component Object Model vendor, and the history of COM is based richly on the information a discoveries made by Windows.
The budding technology of COM was the base of OLE, which means Object Linking and Embedding. This was one of the most successful technologies introduced with Windows. The programs we soon being added into application like Word and Excel by 1991, and on into 1992. it was not until 1996 that Windows truly realized the potential for their discover. They found that the OLE custom controls could expand a web browsers capability enough to present content
The first example we will cover it the Document Object Model. This example is a remake of a more detailed example, I have reduced the information provided in the example in order to express on the important features of the model. This example can be seen below:
By looking at the example provided above, we can clearly see the process in which the Document Object Model is used. The sample model is designed to show us the way in which the document is linked to each element and the coinciding text that is linked to those elements..
Now we will take a quick look at a simple component object model example. This particular example has been based on one of the models provided by window themselves.
So after exploring the Object model we can safely come to the conclusion that the Object model does serve an important purpose that no model before it was able to grasp. Though the model has been modified to fit with specific instances the main use is to model object data.
Windows is one of the more notable vendors who have put the Object Model in the limelight; it will be interesting to see what heights this model reaches with their assistance. I will be keeping a close eye out for the next evolutionary change in the Object Model.









0 comments:
Post a Comment