Object-Relational Mapping(Part-I)
There has always been a debate on how to represent data in an application and how it should be persisted in a backend RDBMS. Why can't there be a uniform methodology for both? It has been an eternal debate but we have to live with the fact that data is represented using object-oriented methodology within an application where as it is stored in the RDBMS in accordance with the relational theory. The inherent differences between these two approaches can be attributed to the fact that the underlying methodologies, i.e. Object-Oriented and Relational theories are based on sofware-engineering and mathematical principles respectively. And the difference in the way data is represented in relational and object-oriented world is termed as object-relational impedance mismatch.
In a series of articles, I will discuss the impedance mismatch problem, some of the approaches to solve it and a few most widely used Object-Relational Mapping frameworks. In this article we will try to understand the fundamental characteristics of these two systems.
Object Systems
Characteristics of an Object model can be defined by four basic parameters: identity, state, behavior and encapsulation. The most important parameter in my point of view is identity because it is implicit to the object itself, in other words every object is uniquely identified by its identity irrespective of its state which means even if two objects have same state, they are still different and distinct. They may be similar or equivalent or a mirror image of each other but they are distinctly represented in memory. Behavior is basically a set of operations user can invoke to interact or manipulate the object. Encapsulation prevents user from reading and modifying the internal details of the object. Other important characteristics like inheritance, polymorphism, association, type etc can be derived from the above mentioned basic parameters.
Relational Systems
Relational model is completely based on predicate logic and set theory. The word Relation is used synonymously with Table in a database model contrary to the popular belief that relation is a link between different tables on the basis of some keys. Characteristics of a relational model is defined by relation, attribute, tuple, relation value and relation variable [Date 95]. A relation is a truth predicate having a set of attributes that gives some meaning to the predicate.
For example, we can define a relation "Customer" as {Customer ID, Name, Address, City, State, Zip} There exists a Customer with a Customer ID who has a Name and lives at an address specified by Address, City, State and Zip.
Attributes are statement of facts about the relation and ordering of attributes are not specified in a relation.
A tuple is a truth statement in context of a relation containing attribute values which map the required attributes in the relation. For example,
<Customer Customer ID="100001", Name="Farrukh Nizami", Address="Mehdipatnam", City="Hyderabad", State="AP", Zip="500028">
Two tuples are considered identical if their corresponding relation and attribute values are also identical. The ordering of attribute values is immaterial.
A relation value consists of a relation and a set of tuples that match the relation and a relation variable is a placeholder for a given relation and can change value with time. Therefore, inside an insurance company, a relation variable PolicyHolder can be written to hold the relation Customer and consist of the relation value
{ <Customer Customer ID="100001", Name="Farrukh Nizami", Address="Mehdipatnam", City="Hyderabad", State="AP", Zip="500028">
<Customer Customer ID="100002", Name="Kishore Gopalan", Address="BTM Layout", City="Bangalore", State="KN", Zip="560034>
<Customer Customer ID="100003", Name="Noor Mohammed", Address="Tollichowki", City="Hyderabad", State="AP", Zip="500028">
}
Commonly used words for these are Table (Relation Variable), Rows (Tuples), Columns (Attributes) and a collection of relation variables is called Database. These basic characteristics are combined against one another with the help of some operators like join, union, intersection etc. to form the basis for SQL. The use of operators allow us to create derived relation variables which are relations that are created from other relation values in the database.
Already you can see the difference in the way the two worlds view the system. I will elaborate these differences in the next article, so keep watching this space for more on Object-Relational Mapping concepts.
Comments
The impedance mismatch is the difference between the object models interpretation of state and the database schemas storage of state.Most O/RMs are domain modeled and focus on an ODBMS implementation to suit the use of transparent persistence. Unfortunately they then throw in a smattering of methods to cater for translating RDBMS data. If a requirement falls outside of object model persistence their effectiveness as O/RMs is dramatically lost. The impedance mismatch is nullified if you can translate data from any data base schema model to any other object model using a simple standard approach. Our product, GURA, allows you to implement the object model (ODBMS) or database schema (RDBMS) driven design methodology or a combination of the two. This gives latitude to the developer and allows them to decide which part of the of object model to database schema spectrum they choose to use, without any overhead cost or reduction in effectiveness.
Posted by: Steven Hughes | February 19, 2008 11:44 AM