The Database Design Resource Center



OO Programming and Relational Databases

Database application architecture: How does a computer operate?

Actually, much relies on the application architechture. OO-Programming is the name of the game in SW development these days. But, the call for Object-Oriented databases comes mostly from a community experienced in Java, but not in database modeling. However, can't the two live together?

As I have stated earlier, it depends on how you define the OO-programming application arcitecture: SQL statements should NOT be allowed in the application, but should rather be placed in stored procedures and functions, contained in database packages.

But how do you do that?

Although I deal with data analysis and database modeling, I have to have a certain knowledge on the matter, and I often participate in writing the actual database-side PL/SQL code. So I put up a page on how you define and use a ref cursor as mentioned above.

This worked well and a lot of people were happy. However, a lot of you have wondered how you actually could use that 'miracle' feature.

OK: Back to writing again.

I had to supply you with some info on that. So here is the Java side (application) of how to separate database access from the application logic.

This is very rudimentary, but should give you the picture. I have not taken into account all object-technology terms like encapsulation (but the function obviously is, just look at it again...), methods (overloaded function interface), object instance dynamics (which it supports) and so on.

This is just a simple example on how easy it really is to save the database from inexperienced OO-programming programmers.

Do you get the benefits?

1. The programmer does not need to worry about the database structure
2. Tuning of SQL is done independently of how many times (or rather places) this access path is in use.
3. Changes in the database structure/access paths are not influencing the application logic.
4. Not to mention: It will easily outperform any world-leading (or wannabe) Java programmer.

Actually, I claim that this is a far better approach than the attempts made to create an Object-relational database (whatever that would be), doing trivial mappings, not getting the point that your information structure is not dependent on how you represent it inside a given program in a given programming language.

Well, now I got carried away with programming :-)

Return to Application Architecture


Exclusive interviews with:
Steven Feuerstein, PLSQL expert
Donald Burleson, Top IT consultant


Free eBook

Subscribe to my newsletter and get my ebook on Entity Relationship Modeling Principles as a free gift:


What visitors say...

"I just stumbled accross your site looking for some normalization theory and I have to say it is fantastic.

I have been in the database field for 10+ years and I have never before come across such a useful site. Thank you for taking the time to put this site together."

Mike, USA

Read more Testimonials



Database Normalization eBook:


Database Normalization eBook




Copyright © www.databasedesign-resource.com /
All rights reserved.
All information contained on this website is for informational purposes only.
Disclaimer: www.databasedesign-resource.com does not warrant any company, product, service or any content contained herein.

Return to top

Copyright acknowledgement note:

The name Oracle is a trademark of Oracle Corporation.
The names MS Access/MS SQL Server are trademarks of Microsoft Corporation.
Any other names used on this website may be trademarks of their respective owners, which I fully respect.