An analisys of RDBMS, OOP and NoSQL conccepts. (2024)

ABSTRACT

Software applications often work with data. This data needs to bemanaged in careful way as to not be easy corrupted or lost. At the sametime, programmers need a way to access this data and work with it.Classicaly, data was stored in a database that, more often than not,used the well known relational model. Programmers access these systemsdirectly, trough and API, or they use Object Relational Mapping systems,a relatively old term (the first ORM, for SmallTalk, TopLink wasreleased way back in 1994). A more recent database technology term isNoSQL (reinvented in 2009). We describe this term and what the systemsthat implement the concept do in the second part of the paper.

Keywords: SQL, RDBMS, ORM, NoSQL, MapReduce, OOP

1. INTRODUCTION

In the early 1960's, the database term was introduced as asimple support for what will represent the structure of a system.Besides that the splitting of data applications was a new and viableconcept, it has opened the way to more robust-like applications. In thatmoment the databases consisted of devices that were using tape, butimmediately they became easy to use, being used on systems with directdisc-access.

In 1970, Edgar Codd has proposed a more efficient data-storagemethod--the relational model. This model was also using SQL to allowapplications to find table stored data. This relational model was almostidentical with what we call today the traditional relational model.Although this model was generally accepted, until the 1980s thereweren't hardware devices which could fully use this model'sadvantages. Until 1990, the hardware industry managed to evolve at amore adequate level, thus the relational model became a dominant methodfor storing data.

As well as any other technology domain, the relational databasemanagement systems competition started. Some examples of RDBMs areOracle, Microsoft's SQL Server, MySQL and PostgreSQL.

After the year 2000 applications began to output huge amounts ofdata because of complex processes. Social networks were invented.Companies wished to use their data more efficiently. The change broughtdatabase structure, performance and data-availability problems whichhaven't been addressed by the previous relational model. With theseweak spots and the need to manage huge chunks of data more efficiently,the NoSQL term appeared.

2. APPLICATION-LEVEL DATA PROCESSING OPTIMIZATION THROUGH ORM(OBJECT-RELATIONAL MAPPING) SYSTEMS

Object Relational Mapping is a programming technique used by thedevelopers for converting data between incompatible systems. Thistechnique is used in object oriented programming languages, thus the"object" from the ORM.

ORM systems are frequently used by developers when they interactwith relational database management systems. An ORM system refers tocreating classes which reflect database tables but in abusiness-oriented manner unlike the normalized form of a RDBMS(Relational database management system).

The need for ORM systems arose from the way data is being storedand manipulated by different DBMS's and programming languages. Thetwo kinds of systems can be grouped as such: RDBMS's (most of themfollow the relational model) and programming languages (most of themhave object oriented programming features or are completelyobject-oriented). The methods whereby data is manipulated by the twosystems are totally different.

The Relational Model

Formulated by E.F. Codd in 1969, the relational model is the mainstoring model used by most of the RDBMS's. The main idea of therelation model is to describe a database as collection of predicatesover a finite set of variables, describing the restrictions overpossible value combinations. The content of a database is a finite model(logical) anytime, for example a set of relations, one per predicatevariable so all predicates are satisfied. A query for information fromthe database is also a predicate.

Motivation behind the relational model is to supply a declarativemethod for data specification and queries: the users declare whatinformation the database has and what information they want from it andthen let the RDBMS to take care of the description structures forstoring data and methods of data retrieval for queries.

Normalization is another feature of relational databases. Theobjective of database normalization is to decompose the anomaly-riddenrelations to produce more smaller and compact relations. Normalizationusually includes splitting the bigger tables in smaller tables (and lessredundant) and defining the relations between them. The objective is toisolate data because the additions, deletions or modifications of afield to be done in a single table and get propagated throughout therest of the database though the defined relations.

The relational model with the normalization technique are welldefined for storing data because if they are used correctly they cansupply a safe, rapid and without-anomalies model of data-storing.

The SQL standard is used to query databases. It was created by IBMin 1970 to be used in System R, the first database system based on therelational model. The SQL Standard is based on algebra and relationalmath like the relational model therefore relational databases are usingthe logic for storing and manipulating data.

Object Oriented Programming

Many people learn to program for the first time using a languagethat is not object-oriented. Non-OOP languages can be a long list ofcommands. The more complex programs will group command lists infunctions and subroutines, each having a special task. When theprogram's complexity raises allowing any function to modify anypart from the data can trigger anomalies which can have cascadingeffect.

In contrast, the object oriented programming method encourages theprogrammer to store data in places not accessible directly by the restof the program. Instead, data is being accessed through specialfunctions, called methods, which are encapsulated with data or inheritedfrom the object classes and behave like auxiliary elements for retrievalor modification of data. The programming construction which combines thedata with a set of access and management methods of theirs is called anobject.

This model is used on a larger scale because it uses structureswhich work with data and groups the variables and functions into objectproperties and methods.

Combining the relational model and object oriented programming

The two structuring models are not compatible. This is due to thefact that they are completely different. One is being used for storingand manipulating huge quantities of data and the other one is used forimplementation of data processing algorithms.

A programmer uses SQL to recover and send data back to themanagement system of the database. Moreover, he needs to know thestructure of the database, tables, relations and data-processingrestrictions exactly. This is a burden for each programmer because it isstill a matter that needs to be taken into account. If the structure ofthe database changes, a programmer needs to update his code, classes andfunctions.

It's clear that by issuing relational stored data in an objectoriented programming language can be a difficult matter sometimes. Toaddress this issue the ORM technique was invented. It behaves like abridge between the two systems so that the programmer can ease hisworrying related to the mode by which the data is stored and recoveredand to concentrate how it's processed in the application which hecreates.

ORM system functionality

This system functions like an intermediate between the programmerand a management system of a database by building queries to thedatabase for him and getting the data back in an object-oriented manner.Normally the programmer doesn't query the database managementsystem and doesn't need to worry about the SQL Standard becauseeverything is being created by the ORM system. In exchange, theprogrammer queries the ORM system.

The ORM system is actually a library (sometimes created by theprogrammer) which is designed to work with one or more databasemanagement systems.

ORM is a programming technique for converting data betweenincompatible systems in an object oriented language. This method createsa virtual database which can be used from the programming language.

Data management tasks in object oriented programming are usuallyimplemented by object manipulation which have often non scalar values.Yet many database management systems can store and manipulate onlyscalar values such as integers and strings of characters organized intables. The programmer needs either to transform the value of theobjects in simple value groups in order to be stored in the database(and then to convert them back for recovery), or to use simple scalarvalues in the program. ORM is used to implement the first method.

The main issue is converting the logical representations of theobjects into an atomized form which can be stored into the database,while the properties of the objects and relations being preserved inorder to be reloaded as objects when needed. If the storage and backupfunctionality is implemented, it's being said that the objects arebeing persistent.

Compared to other traditional exchange techniques, between anobject oriented language and a relational database the ORM often reducesthe volume of required code to be implemented.

The disadvantages of ORM systems occur, in general because of thehigh abstraction level which cloaks what actually happens in theimplementation code of this concept. A variety of difficulties occurwhen trying to implement such a concept. These difficulties are beingcalled the object relational impedance mismatch.

The mismatches which appear between the two systems when takinginto account the object oriented programming concepts

* Encapsulation: object oriented programs are created by usingtechniques which result in encapsulated object whose representations arehidden. In an object oriented platform, the underlying properties of anobject are hidden to all interfaces except the one in which isimplemented alongside the object.

* Accessibility: In the relational thinking, the private and publicconcepts are thought as relative concepts rather than absolute (like inobject oriented programming). The relational model and object orientedobjects usually have conflicts at relativity versus the absolutism ofdata classification and characteristics.

* Interface, class, inheritance and polymorphism: under anobject-oriented paradigm, the objects have interfaces which togethersupply the only access to the internal components of this object. On theother side the relational model uses derived relations variables (views)to supply different perspectives and restrictions in order to assuredata-integrity. Similarly, the essential OOP concepts for objectclasses, inheritances and polymorphism are not supported by therelational database systems.

A correct link between the relational and object oriented conceptscan be made if the relational database's tables are tied by thekinks found in the object oriented analysis.

The differences between the data types used by the both modelsshould be considered.

A major asymmetry between the existent relational languages andobject oriented languages lies upon the differences between the datatypes used by both these systems. The relational model strictly forbidsreference-type attributes (pointers) while the object oriented uses thisconcept widely. Scalar types and operator semantics are as well veryoften different between these two models.

For example the majority of SQL systems support strings withdifferent specified collations and maximum limited lengths (opentext-types are usually a bottleneck for performance), while the majorityof OO languages consider the alphabet as an argument for the sortingroutines and the character strings which are intrinsically enlargedbased on the available memory. A more subtle example would be that SQLsystems usually ignore the ending white space of a character stringbecause of comparison reasons while the OO character string librariesdon't do that.

Another mismatch is related to the differences between thestructural and integrity aspects of the models. In OO languages, theobjects can be composed from other objects. This matter can make theconversion to a less simple relational schema difficult. This problem isdue to the fact that the relational data tends to be represented in aset of global relation variables and not interspersed. Relations per sebeing tuple sets, all conform to the same header don't have aperfect namesake in OO languages. The restrictions in OO languages aregenerally not declared, but do manifest just like the logical protectionaround the code which operates on internal encapsulated data. Therelational model on the other hand requires declarative restrictions onscalar types, attributes, relation variables and on the database as awhole.

The semantic differences are especially evident in the manipulationaspects of the context models. The relational model has a relativelysmall and well defined intrinsic set of primitive operators for use inqueries and data manipulation while the OO languages generally managequeries and manipulations through some routines and special definedoperators.

Solving the mismatch issue (impedance mismatch) for the OO programsbegins with the recognizing of the differences between the utilizedlogical systems and minimizing, compensating for the mismatches.

There were several attempts of constructing management systems ofobject oriented databases (OODBMS) which avoided these mismatch issues.These had a small grade of practical success, mainly because of the OOprinciple limitations in data modeling. There were researches carriedout about the possibility of extending the OO language capabilities byincluding notions such as transactional memory.

A solution which is often used for solving such a mismatch issue isto split the domain logic from the business one. In this concept, the OOlanguage is used to solve specific relational aspects in the executionmoment, avoiding if possible a static approach of data. The platformswhich use this model usually have analog elements for the tuple andrelation concepts. The advantages of such an approach are:

* Simple ways to build automation elements for the domain datatransfer, presentation and validation;

* Lower dimension programs, fast compilation and fast loadingtimes;

* The possibility of dynamic change of data schema;

* Restrictions check;

* Reduced complexity in model synchronization.

The raise in popularity of XML databases led to the occurrence ofother alternative architectures which try to solve the mismatch betweenthe two models. These architectures use XML technology inside the clientapplication and native XML databases on the server by using the XQuerylanguage for querying the data. This matter allows the usage of a singledata model and of a single querying language of data (XPath) in theclient application and on the persistence server.

The mismatch between the two systems when it comes to applicationinterfaces is even more visible when it's required to buildinterfaces which would allow the non-technical users to manipulate datawhich is being stored into the database. Building such interfacesrequires thorough knowledge related to the nature of different databaseattributes from the database (more than the nature of the attribute anddata type). Usually building visual interfaces which prevents illegaltransactions (transactions that would break the database restrictions)by the users is considered a best practice. This matter requires mostlyduplication of the present domain logic of the database in the visualinterface.

Because of a limited set of data-types the SQL standard makes theproper projection of objects and business domain a difficult matter.Also the SQL standard represents an inefficient interface between adatabase and an application (built in an object oriented manner or not).Anyways SQL is momentarily the only general standard accepted forquerying databases. Using proprietary database querying languages isseen as a bad practice and is discouraged. Other querying languages wereproposed for standardization as Business Systems 12 and Tutorial D, butneither of these were adopted on a wide scale by no RDBMS vendor.

In the actual popular RDBMS systems such as Oracle and MicrosoftSQL Server, the upper problems were partially resolved. Within theseproducts, the base functionalities of the querying language can beextended with stored programs (functions and stored procedures) writtenin modern OO programming languages (Java for Oracle and .Net languagesfor Microsoft), and these programs can be invoked in querying SQL in atransparent mode. This matter means that the user doesn't know anddoesn't need to know that these routines weren't initially apart of the RDBMS in cause. The modern projection models are fullysupported, thus a developer can create a library of re-usable routinesin the context of multiple relational schemas.

These vendors decided to add these functionalities in the RDBMSproducts because they realized that despite the attempts made by the ISOStandardization Committee SQL-99 to introduce procedural functionalitiesin the standard SQL, this will never have the rich library set and datastructures found in the actual programming languages and thatapplication developers wait to access. Because of this the differencebetween the application development and database administration is atthe moment undefined: the implementation of robust functionalities suchas restrictions and triggers require the work of a developer with bothdatabase administration and object oriented programming capabilities.This matter also has an effect over the split of responsibilities.

Yet, many voices think that the SQL Standard does exactly what itwas designed to do, namely to facilitate querying, sorting, filteringand storing of very big sets of data. Adding object orientedcapabilities to this standard would only promote a wrong architecturalstyle by including business logic at the level of data storage, which iscontrary to the initial principles of RDBMSs.

In a RDBMS the canonic form of data is represented and stored. Themodel of databases presumes that the RDBMS is the only responsibleauthority with the modifications which occur at the data level. Anyother systems which facilitate replication of those modifications useonly copies of the data and any other modifications which occur at thedatabase data are usually the modifications which must be takencarefully into consideration. Yet, many application developers prefer toview the data representation contained by the objects that they use asthe correct stance and view the RDBMS only as a deposit for the eventualdata storage.

Splitting responsibilities between the application programmers anddatabase administrators is a sensible topic. It usually happens thatwhen there's necessary code modifications (to implement a new thingor new functionality) that these will cause according modifications ofthe database. In most organizations maintaining the database is theresponsibility of its administrator. Because databases must bemaintained all the time, many administrators refuse to applymodifications above the structure of the database which they considersuperficial. This matter is to be understood because the databaseadministrators are usually held accountable if after a modification of adatabase's structure led to data loss. So the majority ofdefinition and functionality modifications of data are maintained at theapplication level because at this level the possibility to lose data isless probable. Still, as applications evolve, the schema of the databaseremains constant and the differences between the two systems increase insuch a manner that it becomes very difficult to implement newfunctionalities without needing to modify important portions of theapplication.

The main differences between the relational model and the objectoriented one are:

* Declarative and imperative interfaces--Relational thinking tendsto use data as interface not behavior as an interface. Thus it has atendency towards the projection philosophy in contrast with thebehavioral tendency of the object oriented model.

* Schema--The objects won't need to follow a parent schema forthe attributes or methods which an objects encapsulates, while thetable's tuples must follow the schema of the entity. A given tuplemust be part of only one entity. The closest thing in OO is theinheritance but is in general optional.

* Access rules--In relational databases the attributes are beingaccessed and modified through the predefined relational operators. Inthe OO model each class allows the creation of interfaces for modifyingof the state and attributes.

* Unique identifier--Unique identifiers (keys) generally have atext representable form but objects don't require a visible uniqueidentifier.

* Normalizations--The practices of relational normalizations areusually ignored by the OO design. Another perspective is that acollection of objects, interconnected with pointers is the equivalent ofa network database which, in turn, can be seen as an extremelyde-normalized relational database

* Schema inheritance--The majority of databases doesn'tsupport the schema inheritance. Although such a trait could be added intheory to reduce the conflict with the OOP, the supporters of relationalconcepts don't believe in the utility of such hierarchical taxonomybecause they tend to consider that the taxonomies based on sets andclassification systems to be more powerful and flexible than Tree.

* Structure and behavior--The OO model is mainly based on theassurance that the program's structure is reasonable (easy tomaintain, easy to understand, extensible, reusable, safe), while therelational systems concentrate on the behavior type (efficiency,adaptability, error-tolerance, logical integrity, etc.). Object-OrientedMethods generally presume that the main user of the object oriented codeand it's interfaces are the application developers. In therelational systems, the behavior of the system from the user'spoint of view is considered more important. With all these, therelational queries and views are common techniques to reproduceinformation in specific applications configurations.

* Multiple relations and Graph--The relation between differentelements (objects or records) tend to be treated differently than thetwo models. Relational relations are usually based off expressions takenfrom the theory of sets, while the relations between objects are basedoff expressions adopted from the theory of graphs (including Tree).Although each model can represent the same information like the other,the approach which they offer for the access and management ofinformation differs.

3. APPLICATION-LEVEL DATA MANAGEMENT USING NOSQL

The NoSQL term isn't an abbreviation for "no SQL",in fact it's an acronym for "not only SQL". NoSQLdatabases are a group of long-lasting solutions which aren't usingthe relational model and they don't use SQL for queries. Inaddition, NoSQL wasn't launched in order to replace the relationalsystems but for being a support for the lack of features relationaldatabases have.

The first special aspect of NoSQL databases is the data structure.There is a variety of methods in which NoSQL databases can classifythemselves.

Classifying NoSQL databases

NoSQL databases (most of them) can get classified in 4 majorcategories:

* Key-Value stores: Saving data with a unique key and a value.Their simplicity allows them to be extremely fast and adaptable to bigquantities of data

* Column stores: They're similar to the relational databaseones but instead of records they store all the associated column valuesinto an array.

* Document stores: Saving data without being integrated into aschema, grouping a multitude of key-value pair in a single object. Thisstructure is similar to an associative table.

* Graph databases: Data is being stored in a flexible graph whichcontains a node for each object. The nodes have properties and relationswith other nodes.

In principle, NoSQL databases are easily scalable because they arebased off distributed systems and ignores the ACID model.

When there's a discussion about a distributed system (notnecessarily database related), there's a concept that defines itslimits. This is known as the CAP theorem.

The CAP Theorem

Eric Brewer introduced the CAP theorem in 2000. It dictates that inany distributed environment there's impossible to guarantee theethings at the same time, more specifically:

* Consistency: All the system's servers will have the samedata. Therefore anyone using the system will get the most recent versionof the data, no matter from what node the distributed system accessstarted.

* Availability: All the servers will return data, no matter whatmoment.

* Partitioning availability: The system continues to work as awhole even if a server is offline or cannot be found in the network.

When a system becomes so pervasive that one node cannot cope withdata traffic, adding additional servers for the system is usually acommon solution. When adding nodes there must be a method for datasplitting between these nodes. Does other several databases exists withthe same data? Are there ways to place sets of data on differentservers? Are other servers allowed to write data and other to read it?

No matter what option the developer would choose, the major problemlies at the synchronization of those servers. If some information iswritten in a specific node, how can there be any assurance that a querydirected through another server will return the most recent data insteadof the old ones? These events can succeed in few milliseconds. Even witha modest data collection, this matter can be extremely complex.

When it's absolutely necessary that all clients to have accessto a valid database image, a node's users will have to wait for allthe nodes to get to an accord before reading or writing into thedatabase.

In this case we can observe how the availability loses priorityover data integrity. In any case, there are situations when availabilitybecomes a priority: any system node should take decisions based on itsown status. If the situation requires that the system to operate onintensive-like traffic conditions and nodes have to get to a consensusfor each data-accessing then the servers are in danger of failing. Ifthe developer is interested into scalability, any algorithm which forcesservers to get to an integrity consensus will lead to problems.

The Acid Model

ACID is a set of properties which get applied in transactionsbetween databases and lies at the relational model's base. Whilethe transactions are quite useful, they're the cause of read andwrite lagging in the context of them being used in relational databases.ACID is made out of four major properties:

* Atomicity: This is an essential concept when there is datamanipulation. All transitioned data must be sent in succession or nochange will be registered. This is a key property when money orconsiderations are interacting with the system, requiring a verificationmethod.

* Consistency: Data will be accepted only if it passes alldatabase's validations such as type, value, event restrictions.

* Durability: Once the data is saved, they're protectedagainst errors, destruction or software anomalies.

Advantages of NoSQL databases

Along with NoSQL's introduction, many advantages showed up,such as:

* It allows things that weren't allowed in the past by therelational database's processing power

* Client's data is scalable and flexible, allowing a necessaryscalability politic approach since the installation moment.

* There are new data types to be taken into consideration. Therewon't be the need for a developer to force a specific data-typewhich wouldn't have any logic in the context.

* Data-Writing is being made extremely fast.

As it can be seen, there are few clear advantages of NoSQLdatabases, but there's also negative aspects.

Disadvantages of NoSQL databases

Meanwhile there's also shorts which NoSQL systems have:

* There's no reference standard, each database behavesdifferently than the others.

* Queries aren't using the well-known SQL model to findrecords.

* NoSQL is a new technology and it's in a constantimprovement.

* There are newer non-standard models with operable data, thismatter sometimes can be ambiguous for developers when it comes to dataclassifying

* Because NoSQL avoids the ACID model, there's no guaranteethat the writing of data will be successfully done.

Using NoSQL systems

After presenting the advantages and disadvantages, we arepresenting the situations where NoSQL can be used as an efficientmanagement instrument:

* Applications who write lots of data

* Applications in which the schema and structure can get modifiedany time

* Huge chunks of unstructured or semi-structured data

* Relational database are quite restrictive for the developer andhe'll need something new.

Situations in which NoSQL databases should be avoided are thefollowing:

* Any application that implies having money or value exchangetransactions. The result would be catastrophic, knowing that NoSQL isavoiding the ACID model and data not being 100% available because of thedistributed system.

* Essential or classified data of business application where thelack of a single record could cause major issues.

* Data being strongly relational between themselves, requiring thefunctionality of a relational system.

For all these situations, the developer should choose for arelational database which would guarantee him that data will bemanipulated safely. Of course, NoSQL can be included there where thiskind of manipulation has logic.

The Map/reduce concept

Map/Reduce is a software concept and it became increasingly popularin distributed processing domain. Its main concept is based off twofunctions--indexing and compression, both being used with a batch ofinput values.

The indexing function produces a result for each article in thelist while the compressing function produces a single result for thewhole list. CouchDB exploits the features of these two functions toproduce successive calculated reports. This can be explained by the factthat each time a document is updated in the database, CouchDB, only thedocuments that must be modified will be reprocessed by the indexing andcompression functions.

Google is using a map/reduce implementation in its web index.Google has thousands of servers which are processing terabytes of data,centralized all over the World Wide Web. Issues that can be solved by asingle server within months are processed within hours because of thedistribution model. The Map/Reduce library used by Google includesfacilities such as traffic counterbalancing and disc-writing dataoptimizations, important ways of increasing the efficiency of thesystem. Also, the architecture is robust, thus errors or hardwaremalfunctions won't negatively influence the solving of the initialissue. Actually, according to public made researches on Google based onMap/Reduce, Google lost at a time 1600 from its 1800 servers from acluster, yet the system managed to produce a result of the problem.

4. CONCLUSION

As we can see, the Realtional Model is here to stay. NoSQL systemsoffer great performance, but they can not completely replace RDBMSs. Thebest thing tot do is use what's best from both worlds, all inconjunction with an ORM system. NoSQL systems are great for storingcached objects or SQL query results, for example. Because of theirspeed, they are a great source for primary data for appliccations thatneed data fast but don't need it to be consistent. For consistencywe can fall back to an RDBMS.

5. ACKNOWLEDGEMENTS

The article has been supported by scientific research within theproject entitled "PRACTICAL SCHOOL: Innovation in Higher Educationand Success on the Labour Market", project identified asPOSDRU/156/1.2/G/132920. The project is co-financed by the EuropeanSocial Fund through the Sectorial Operational Programme for HumanResources Development 2007-2013. Investing in people!

REFERENCES

* Abramova, V., & Bernardino, J. (2013). NoSQL databases. InProceedings of the International C* Conference on Computer Science andSoftware Engineering - C3S2E '13 (pp. 14-22). ACM Press.http://doi.org/10.1145/2494444.2494447

* Cattell, R. (2011). Scalable SQL and NoSQL data stores. ACMSIGMOD Record.

* Halpin, T. (1998). Data modeling in ORM. In Handbook onArchitectures of Information Systems (pp. 81-102). Springer-Verlag.http://doi.org/10.1007/3-540-26661-5_4

* Halpin, T. (2000). Entity Relationship Modeling from an ORMPerspective: Part 1. Journal of Conceptual Modelling (2000: 12),(December), 1-10. Retrieved from http://www.orm.net/pdf/JCM11.pdf

* Han, J., Haihong, E., Le, G., & Du, J. (2011). Survey onNoSQL database. In Proceedings - 2011 6th International Conference onPervasive Computing and Applications, ICPCA 2011 (pp. 363-366).

* Hecht, R., & Jablonski, S. (2011). NoSQL evaluation: A usecase oriented survey. In Proceedings - 2011 International Conference onCloud and Service Computing, CSC 2011 (pp. 336-341).

* Leavitt, N. (2010). Will NoSQL Databases Live Up to TheirPromise? Computer.

* Pokorny, J. (2011). NoSQL databases: a step to databasescalability in web environment. In Proceedings of the 13th InternationalConference on Information Integration and Web-based Applications andServices - iiWAS '11 (p. 278). ACM Press. Retrieved fromhttp://dl.acm.org/citation.cfm?id=2095536.2095583

* Richardson, C. (2009). ORM in dynamic languages. Communicationsof the ACM.

* Song, H., & Gao, L. (2012). Use ORM middleware realizeheterogeneous database connectivity. In 2012 Spring World Congress onEngineering and Technology, SCET 2012 - Proceedings.

* Stonebraker, M. (2010). SQL databases v. NoSQL databases.Communications of the ACM.

* Van Zyl, P., Kourie, D. G., & Boake, A. (2006). Comparing theperformance of object databases and ORM tools. Proceedings of the 2006Annual Research Conference of the South African Institute of ComputerScientists and Information Technologists on IT Research in DevelopingCouuntries - SAICSIT '06, 1-11. Retrieved fromhttp://portal.acm.org/citation.cfm?doid=1216262.1216263

Xia, C., Yu, G., & Tang, M. (2009). Efficient implement of ORM(Object/Relational Mapping) use in J2EE framework: Hibernate. InProceedings - 2009 International Conference on ComputationalIntelligence and Software Engineering, CiSE 2009.

Dragos-Paul POP (*1)

Edward Cristi BUTOIU (2)

(1*) Corresonding author. Romanian--American University. 1B,Expozitiei Blvd., district 1, code 012101, Bucharest, Romania. Email:[emailprotected]

(2) Romanian--American University. 1B, Expozitiei Blvd., district1, code 012101, Bucharest, Romania. Email: [emailprotected]