Relational databases catered to the need of backend database in application development arena for quite a long time, but there are other types of databases that have the potential to do the same. We should not overlook their merit while dealing with a RDBMS as they can serve similar purposes equally well, and possibly in a better way. These database models are related to the relational concepts in doing what they do best. This article provides a perspective on the philosophies of database systems that are designed to be different from the relation database model yet have a similar kind of vibe in their approach.
It is important that database application developers have a fairly good idea about general database administration as well as that they be experts in SQL. In the process of attaining knowledge, however, developers have little inclination towards knowing the inner working of the various database management systems. The reason for this keep-aside attitude towards understanding the inner workings of an RDBMS is that it isn't helpful for hosting or maintaining databases servers nor is it helpful for developing applications that use the system. Knowing how the system is organized helps in creating better solution which is equally important. Sometimes the concepts of the inner working principles can provide the essential ideas necessary to modify and extend its feature in better ways. It is also important to have a good idea on the basic principles behind popular database system like ORDBMS, OODBMS compared to RDBMS.
There are quite a few popular variants or types of database system such as relational (RDBMS), object-relational (ORDBMS) and object-oriented (OODBMS). The differences lie in the architecture or design. They have many common as well as distinct features. Here, we provide a brief overview on each of them.
The structure of a relational database management system is based upon relational data model introduced by Ted Codd of IBM Research in 1970. This model uses the concept of mathematical relation. Its building block is tables and values. The functionality is based upon set theory and first order predicate logic. Once this concept was out, it quickly garnered interest among a number of vendors who built several commercial implementations based upon this model. Today, there are many popular RDBMSs such as IBM DB2, MySQL, Microsoft SQL Server, and Microsoft Access.
The idea of a relational database and its associated features that form a package called RDBMS flowered from the basic concept of a collection of relations. Each relation is represented as a table and the rows in the table represents a collection of related data values. The table and the column name give a clue to the meaning of the values in each row. For example, each row in the EMPLOYEE table represents a specific real-world entity such as a record of an employee. The column names such as – emp_id, name, birth_date, join_date determines how to interpret the data values in each record according to the column it is in. Of course, all values in the column must be the same data type, otherwise they disturb consistency.
Most commercial relational database management system implements Structured Query Language (SQL) as a de-facto language to communicate with the database. Some say SQL has no other relation with relational model except as a communication means for availing the storage and retrieval services of the database. However, we must also understand that as words cannot be separated from its sound, SQL cannot be separated from RDBMS. SQL is very much a part of it.
There are many merits and demerits of this system. If we sum up the merit, it is the its robustness that has stood the test of time. However, down the years its upkeep has significantly increased both its size and complexity. The addition and modification of feature as well as the tools built to support changing needs, often had the challenge to coerce different technologies. This is a clear call for unavoidable complexity.
Even having to deal with many of its pros and cons, relational database management systems (RDBMS) are here to stay. This is true even in the day and age of big data, No SQL and what not. Professionals have devoted a lot of their expertise to improving and assimilating it with many of new technological system. When the wave of object-oriented technology became the forefront of the application development, RDBMS seemed too incompatible. But miscible components were conjugated with techniques like Hibernate, JTA and the like. These techniques became so popular and effective that RDBMS may not seem like a system of yore and can be quite a reliable backend companion in many projects. The fact is, there are many old systems still available today and many new systems thriving on the relational model.
The object-relational database systems are an attempt to merge the two different kind of system. It is an object database enhancement of a relational model, a hybrid in design. Perhaps, the most visible aspect that we might observe is in the addition of object database features in the SQL revision for this hybrid model. One of the pitfalls of relation model was in describing complex objects. The vibe of object-oriented mechanisms was brought into the play with the introduction of type constructors to describe row type that corresponds to the tuple constructor, array type for specifying collections, sets, list, mechanism for specifying object identity, encapsulation, inheritance, and more.
Note that the core technology used in ORDBMS is based upon the relational model. The commercial implementations simply added a layer of some of the object-oriented principle on top of the relational database management system. The simplest example is Microsoft SQL Server. Since this system is based on relational model, there is one more problem added to it: translating object-oriented concept to relational mechanism. However, this problem is extenuated by an object-oriented application that helps in the communication between the object-oriented application with the underlying relational databases.
Understand that relational and object-oriented principle do not go well together, because they work on different principle. Therefore, it may seem that this model somehow tries to coerce them into a truce for the sake of developer's convenience. The real reason is to permit storage and retrieval of objects in an RDBMS way by providing extension to the query language to work on the object-oriented principle.
The object-oriented database systems are of different genre. OODBMSes attempt to imbibe the object-oriented principle to database functionality right from its core implementation. If RDBMS carries the rich tradition of query language and its extension, then an ORDBMS champions the cause of adding rich data types to the relational model, OODBMS provides a seamless integration with OOP languages. The query mechanism of OODBMS focuses on object manipulation using specialized object-oriented query language such as ODL (Object Description Language) and OQL (Object Query Language).
An object consists to two components: state represented by value and behavior represented by operations. In a typically object-oriented programming language (OOPL) transient objects exists in memory. OODBMS extended this idea and stores the object permanently beyond program termination and can be retrieved later. Most unusual feature of the OODBMS is that it provides the mechanism to persist complex objects with both structure and behavior that can be applied to this object via object-oriented programming interface. This mechanism leverages the modelling of real-world objects as accurately as possible without forcing a relationship among entities as we can see in the relational model.
Introduction
It is important that database application developers have a fairly good idea about general database administration as well as that they be experts in SQL. In the process of attaining knowledge, however, developers have little inclination towards knowing the inner working of the various database management systems. The reason for this keep-aside attitude towards understanding the inner workings of an RDBMS is that it isn't helpful for hosting or maintaining databases servers nor is it helpful for developing applications that use the system. Knowing how the system is organized helps in creating better solution which is equally important. Sometimes the concepts of the inner working principles can provide the essential ideas necessary to modify and extend its feature in better ways. It is also important to have a good idea on the basic principles behind popular database system like ORDBMS, OODBMS compared to RDBMS.
Types of Database Systems
There are quite a few popular variants or types of database system such as relational (RDBMS), object-relational (ORDBMS) and object-oriented (OODBMS). The differences lie in the architecture or design. They have many common as well as distinct features. Here, we provide a brief overview on each of them.
The Idea of Relational Database (RDBMS)
The structure of a relational database management system is based upon relational data model introduced by Ted Codd of IBM Research in 1970. This model uses the concept of mathematical relation. Its building block is tables and values. The functionality is based upon set theory and first order predicate logic. Once this concept was out, it quickly garnered interest among a number of vendors who built several commercial implementations based upon this model. Today, there are many popular RDBMSs such as IBM DB2, MySQL, Microsoft SQL Server, and Microsoft Access.
The idea of a relational database and its associated features that form a package called RDBMS flowered from the basic concept of a collection of relations. Each relation is represented as a table and the rows in the table represents a collection of related data values. The table and the column name give a clue to the meaning of the values in each row. For example, each row in the EMPLOYEE table represents a specific real-world entity such as a record of an employee. The column names such as – emp_id, name, birth_date, join_date determines how to interpret the data values in each record according to the column it is in. Of course, all values in the column must be the same data type, otherwise they disturb consistency.
Most commercial relational database management system implements Structured Query Language (SQL) as a de-facto language to communicate with the database. Some say SQL has no other relation with relational model except as a communication means for availing the storage and retrieval services of the database. However, we must also understand that as words cannot be separated from its sound, SQL cannot be separated from RDBMS. SQL is very much a part of it.
There are many merits and demerits of this system. If we sum up the merit, it is the its robustness that has stood the test of time. However, down the years its upkeep has significantly increased both its size and complexity. The addition and modification of feature as well as the tools built to support changing needs, often had the challenge to coerce different technologies. This is a clear call for unavoidable complexity.
Even having to deal with many of its pros and cons, relational database management systems (RDBMS) are here to stay. This is true even in the day and age of big data, No SQL and what not. Professionals have devoted a lot of their expertise to improving and assimilating it with many of new technological system. When the wave of object-oriented technology became the forefront of the application development, RDBMS seemed too incompatible. But miscible components were conjugated with techniques like Hibernate, JTA and the like. These techniques became so popular and effective that RDBMS may not seem like a system of yore and can be quite a reliable backend companion in many projects. The fact is, there are many old systems still available today and many new systems thriving on the relational model.
The Idea of Object-Relational Database System (ORDBMS)
The object-relational database systems are an attempt to merge the two different kind of system. It is an object database enhancement of a relational model, a hybrid in design. Perhaps, the most visible aspect that we might observe is in the addition of object database features in the SQL revision for this hybrid model. One of the pitfalls of relation model was in describing complex objects. The vibe of object-oriented mechanisms was brought into the play with the introduction of type constructors to describe row type that corresponds to the tuple constructor, array type for specifying collections, sets, list, mechanism for specifying object identity, encapsulation, inheritance, and more.
Note that the core technology used in ORDBMS is based upon the relational model. The commercial implementations simply added a layer of some of the object-oriented principle on top of the relational database management system. The simplest example is Microsoft SQL Server. Since this system is based on relational model, there is one more problem added to it: translating object-oriented concept to relational mechanism. However, this problem is extenuated by an object-oriented application that helps in the communication between the object-oriented application with the underlying relational databases.
Understand that relational and object-oriented principle do not go well together, because they work on different principle. Therefore, it may seem that this model somehow tries to coerce them into a truce for the sake of developer's convenience. The real reason is to permit storage and retrieval of objects in an RDBMS way by providing extension to the query language to work on the object-oriented principle.
The Idea of Object-Oriented Database System (OODBMS)
The object-oriented database systems are of different genre. OODBMSes attempt to imbibe the object-oriented principle to database functionality right from its core implementation. If RDBMS carries the rich tradition of query language and its extension, then an ORDBMS champions the cause of adding rich data types to the relational model, OODBMS provides a seamless integration with OOP languages. The query mechanism of OODBMS focuses on object manipulation using specialized object-oriented query language such as ODL (Object Description Language) and OQL (Object Query Language).
An object consists to two components: state represented by value and behavior represented by operations. In a typically object-oriented programming language (OOPL) transient objects exists in memory. OODBMS extended this idea and stores the object permanently beyond program termination and can be retrieved later. Most unusual feature of the OODBMS is that it provides the mechanism to persist complex objects with both structure and behavior that can be applied to this object via object-oriented programming interface. This mechanism leverages the modelling of real-world objects as accurately as possible without forcing a relationship among entities as we can see in the relational model.
Posts
0 comments:
Post a Comment