Relational Database Model
Comparing and Contrasting the Relational Database Model and OO Model
The relational database model is based upon tables or relations. In this model, the physical implementation of the database is abstracted away from the user. Users query the database using a high-level query language, such as SQL. The relations are made up of columns, which have headings indicating the attribute represented by that column. Tables have key fields, which can be used to identify unique records. Keys relate tables to each other. The rows of the relation are also called tuples, and there is one tuple component for each attribute – or column – in that relation. A relation or table name, along with those relation’s attributes, make up the relational schema. Relational Database models are server-centric.
When designing a Relational Database, you must create a table for each entity type, choose or invent a primary key for each table; add foreign keys to represent one-to-many relationships; create new tables to represent many-to-many relationships; define referential integrity constraints; evaluate schema quality and make necessary improvements; and choose appropriate data types and value restrictions for each field (if necessary).
The real power of relational systems lies in the ability to perform complex queries over the data. Relational systems are well understood, and can be highly optimized in terms of queries, scalability, and storage. There is a uniqueness of table rows and primary keys, as well as ease of implementing future data model changes – flexibility and maintainability. To build an effective and efficient application in the relational model, the developer must have a comprehensive knowledge of the tables, and any relationships among them.
Object oriented database management systems are viewed as an alternative approach to meeting the demands of more complex data types. The need to handle complex object-centric data as the main data element is the driving force behind Object Oriented database models. These systems attempt to extend Object Oriented programming languages, techniques, and tools to provide a means to support data management tasks. Object Oriented models are client centric. Object Oriented databases uses attributes containing object identifiers to find objects that are related to other objects.
When designing an Object Oriented model, you must first determine which classes require persistent storage; define persistent classes; represent relationships among persistent classes; and choose appropriate data types and value restrictions for each field.
Object Oriented database models approach from the opposite direction (a programming language itself) to solve the problem of handling complex data types. Since an Object Oriented database model is based upon the language constructs & semantics of the underlying Object Oriented programming language, no query language is required. Instead, the object access semantics of the language are used.
Classes in the object model are self-contained entities. In common with relational tables, they contain their information. But a significant difference is that related data can be stored within the container class rather than as a separate table requiring a foreign key type construct.
Some main differences between the two models are that the business logic is not applied externally in the object model. Instead, a class implements methods that contain code for operating on the class’ properties. As stated on the JFWK.com website,
The Object-Oriented model tends to work well for systems with complex behavior and state-specific behavior in which data is secondary, or systems in which data is accessed navigationally in a natural hierarchy (e.g. bills of materials). The RDBMS model is well suited to reporting applications and systems in which the relationships are dynamic or ad-hoc. (Undated, 1).
An Object Oriented application tends to look like a network of records, or objects. Relational, on the other hand, is based on the concept of tables. There are also semantic differences and,
… due to the semantic differences between the OO and relational paradigms, how the two issues are implemented vary greatly. For example, with respect to concurrency control, granularity of a data item is semantically different in a relation database versus an OODB. Consider a single Customer entity, containing first and last name attributes. In a relational database, the Customer data item would be a database record (a row or tuple) in a relational database table, with columns representing the first and last names. In an OODB, the granularity would be represented as an object (instance) of the Customer entity, whose member variables (fields) would represent the first and last name. (Torres, 2003 3)
In conclusion, after much research on the so-called differences and similarities, I found that either model is fine, depending on how the user will use it, how much information will be stored and how simplistic the task is. Relational models provide a simple, flexible model of the data and a general-purpose declarative query language. Object Oriented models provide a relatively much more complex data model and procedural query language to navigate it. It was also found that relational databases seem to be ever improving. As stated by Craig Mullen in his online article entitled, Mixing DB2 and Object Orientation, “Increasingly, RDBMSs are adding the capability to store more logic in the database. With triggers and user-defined functions and stored procedures, more behavior can be encapsulated in relational tables”. (Mullen, 1999 5).
References:
Java Framework (undated). Object relational mapping. Frontier Technologies. Retrieved on Saturday, June 19, 2004 from the World Wide Web: http://www.jfwk.com/orm.html
Mullen, C. (1999). Mixing DB2 and object orientation. IDUG Solutions Journal. Retrieved on Monday, June 21, 2004 from the World Wide Web: http://www.craigsmullins.com/idug_oo.htm
Torres, J.T. (2003). Concurrency and transaction management in an object database. Project proposal. Retrieved on Tuesday, June 22, 2004 from the World Wide Web: http://students.depaul.edu/jtorres4/se690/formal_project_proposal.html
