CSC/ECE 517 Fall 2009/wiki3 12 obj to relational: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 5: Line 5:


[[Image:Fp1059-shape-ball.JPG |thumb]] [10]
[[Image:Fp1059-shape-ball.JPG |thumb]] [10]
Object-orientation and the relational model are different paradigms of programming.[1] The object paradigm is based on building applications out of objects that have both data and behavior,
Object-orientation and relational model are different paradigms of programming.[1] The object paradigm is based on building applications out of objects that have both data and behavior,
whereas the relational paradigm is based on storing data. With the object paradigm, one traverses objects via their relationships whereas with the relational paradigm one duplicates data to join the rows in tables.[2] The difference between how object models work and relational databases is known as the “Object-Relational Impedance Mismatch”. This is just nerd-speak for “they are different”. In analogy, we could consider the example of the ball and shape game. It's the same thing; you can’t fit a square in a triangle hole.[10]
whereas the relational paradigm is based on storing data. With the object paradigm, one traverses objects via their relationships whereas with the relational paradigm one duplicates data to join the rows in tables.[2] The difference between how object models work and relational databases is known as the “Object-Relational Impedance Mismatch”. This is just nerd-speak for “they are different”. In analogy, we could consider the example of the ball and shape game. It's the same thing; you can’t fit a square in a triangle hole.[10]


When objects
One way to avoid the impedance mismatch between objects and relations is to use an object-oriented
need to be stored in relational databases, the gap between the two different sights needs to be bridged.
database. However, systems often need to store objects in a relational database. Sometimes a system needs
If only data abstraction modules have to be mapped to a relational database, life is comparably easy
relational calculus or the maturity of a relational database. Other times the corporate policy is to use a relational database rather than an object-oriented database. Whatever the reason, a system that stores
[Kel+97]. With full blown object models the concepts of object oriented programming have to be
objects in a relational database needs to provide a design that reduces the impedance mismatch.
mapped to relational table structures.[1]
 
This paper describes only a part of a pattern language for mapping objects to relations, but it describes the
patterns that we thought were not adequately described elsewhere.[5]
 
 
 


The Object-Relational Mismatch
The Object-Relational Mismatch
This fundamental difference results in a non-ideal combination of the two paradigms, although when have you
 
ever used two different things together without a few hitches? One of the secrets of success for mapping
One of the secrets of success for mapping
objects to relational databases is to understand both paradigms, and their differences, and then make
objects to relational databases is to understand both paradigms, and their differences, and then make
intelligent tradeoffs based on that knowledge.[2]
intelligent tradeoffs based on that knowledge.[2]


Most modern business application development projects use object technology such as Java or C# to build the
 
application software and relational databases to store the data. This isn’t to say that you don’t have other options,
there are many applications built with procedural languages such as COBOL and many systems will use object
databases or XML databases to store data. However, because object and relational technologies are by far the norm
that’s what I assume you’re working with in this article. If you’re working with different storage technologies then
many of the concepts are still applicable, albeit with modification (don’t worry, Realistic XML overviews mapping
issues pertaining to objects and XML).
Unfortunately we need to deal with the object relational (O/R) impedance mismatch, and to do so you need to understand two things: the
Unfortunately we need to deal with the object relational (O/R) impedance mismatch, and to do so you need to understand two things: the
process of mapping objects to relational databases and how to implement those mappings. in this article the term “mapping” will be used to refer
process of mapping objects to relational databases and how to implement those mappings.[3]
to how objects and their relationships are mapped to the tables and relationships between them in a database. As you’ll soon find out it isn’t
quite as straightforward as it sounds although it isn’t too bad either.[3]


Designing software to connect an object-oriented business system with a relational database is
Designing software to connect an object-oriented business system with a relational database is
Line 42: Line 39:
layers by providing some missing patterns and links.[4]
layers by providing some missing patterns and links.[4]


Developers of object-oriented systems that use a relational database usually spend a lot of time making
 
objects persistent. This is because of a fundamental impedance mismatch1 between the two paradigms;
 
objects consist of both data and behavior and often have inheritance while relational databases consist of
 
tables, relations and basic predicate calculus functions to return desired values.
One way to avoid the impedance mismatch between objects and relations is to use an object-oriented
database. However, systems often need to store objects in a relational database. Sometimes a system needs
relational calculus or the maturity of a relational database. Other times the corporate policy is to use a
relational database rather than an object-oriented database. Whatever the reason, a system that stores
objects in a relational database needs to provide a design that reduces the impedance mismatch.
This paper describes only a part of a pattern language for mapping objects to relations, but it describes the
patterns that we thought were not adequately described elsewhere. An overview of the entire pattern
language can be found in [Keller 98-2]. Some of the patterns that are described well are the patterns for
designing the relational database and optimizing it [Brown 96] [Keller 97-1, 97-2, 98-1]. The Serializer
pattern [Riehle et al. 1998] describes how to serialize objects so they can be stored and retrieved from
different backends, such as flat files, relational databases, and RPC buffers.[5]




Revision as of 23:47, 17 November 2009

Patterns for mapping objects to relational databases

The Object-Relational Mismatch

[10]

Object-orientation and relational model are different paradigms of programming.[1] The object paradigm is based on building applications out of objects that have both data and behavior, whereas the relational paradigm is based on storing data. With the object paradigm, one traverses objects via their relationships whereas with the relational paradigm one duplicates data to join the rows in tables.[2] The difference between how object models work and relational databases is known as the “Object-Relational Impedance Mismatch”. This is just nerd-speak for “they are different”. In analogy, we could consider the example of the ball and shape game. It's the same thing; you can’t fit a square in a triangle hole.[10]

One way to avoid the impedance mismatch between objects and relations is to use an object-oriented database. However, systems often need to store objects in a relational database. Sometimes a system needs relational calculus or the maturity of a relational database. Other times the corporate policy is to use a relational database rather than an object-oriented database. Whatever the reason, a system that stores objects in a relational database needs to provide a design that reduces the impedance mismatch.

This paper describes only a part of a pattern language for mapping objects to relations, but it describes the patterns that we thought were not adequately described elsewhere.[5]



The Object-Relational Mismatch

One of the secrets of success for mapping objects to relational databases is to understand both paradigms, and their differences, and then make intelligent tradeoffs based on that knowledge.[2]


Unfortunately we need to deal with the object relational (O/R) impedance mismatch, and to do so you need to understand two things: the process of mapping objects to relational databases and how to implement those mappings.[3]

Designing software to connect an object-oriented business system with a relational database is a tedious task. Object-orientation and the relational paradigm differ quite a bit. An application that maps between the two paradigms needs to be designed with respect to performance, maintainability and cost to name just a few requirements. Luckily there are numerous patterns of object/relational access layers, but looking at the body of pattern literature you will find that some patterns are still to be mined, while there's no generative "one stop" pattern language for the problem domain. This paper provides a systematic roadmap of the patterns in the field, and fills some pot holes on the road towards a full pattern language for object/relational access layers by providing some missing patterns and links.[4]






Object-relational mapping.

Concurrency Patterns

Read/Write Access Pattern

Conclusion

The concurrency patterns discussed above involve coordinating concurrent operations. They address two types of problems:[5]

Shared resources - When concurrent operations access the same data or another type of shared resource, operations may interfere with each other if they access the resource at the same time. To ensure that operations on shared resources execute correctly, the operations must be sufficiently constrained to access their shared resource one at a time. However, if the operations are overly constrained, then they may deadlock and not be able to finish executing.

Sequence of operations - If operations are constrained to access a shared resource one at a time, it may be necessary to ensure that they access the shared resource in a particular order. For example, an object cannot be removed from a data structure before it is added to the data structure.

See Also

References

[1] Wolfgang Keller, Mapping Objects to Tables - A Pattern Language http://www.objectarchitects.de/ObjectArchitects/papers/Published/ZippedPapers/mappings04.pdf

[2] Scott W. Ambler, President, Ronin International, Mapping Objects To Relational Databases http://www.crionics.com/products/opensource/faq/docs/mappingObjects.pdf

[3] Scott W. Ambler, Mapping Objects to Relational Databases: O/R Mapping In Detail http://www.agiledata.org/essays/mappingObjects.html

[4] Wolfgang Keller, Object/Relational Access Layers - A Roadmap, Missing Links and More Patterns http://citeseer.ist.psu.edu/4328.html

[5] Joseph W. Yoder, Ralph E. Johnson, Quince D. Wilson, Connecting Business Objects to Relational Databases http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.34.7703&rep=rep1&type=pdf

[6] Michael R. Blaha, William J. Premerlani and James E. Rumbaugh, Relational Database Design using an Object-Oriented Methodology http://www.sims.monash.edu.au/subjects/ims2501/seminars/oomodelling.pdf

[7] http://www.cetus-links.org/oo_db_systems_3.html

[8] http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/

[9] http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?MappingObjects2Tables/mapping_object.htm

[10] http://cantgrokwontgrok.blogspot.com/2009/03/tech-day-1-nhibernate.html

[11] http://www.adobe.com/newsletters/edge/october2008/articles/article2/index.html?trackingid=DWZST

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_12_obj_to_relational&oldid=27690"