Thursday, October 3, 2019

The Limitations Of RDBMS Systems

The Limitations Of RDBMS Systems To combat the limitations of RDBMS and meet the challenge of the increasing rise of the Internet and the Web, programmers developed object-oriented databases in the 1980s. The main objective of Object-Oriented Database Management Systems, commonly known as OODBMS, is to provide consistent, data independent, secure, controlled and extensible data management services to support the object-oriented model. They were created to handle big and complex data that relational databases could not. There are important characteristics involved with object-oriented databases. The most important characteristic is the joining of object-oriented programming with database technology, which provides an integrated application development system. Object-oriented programming results in 4 main characteristics: inheritances, data encapsulation, object identity, and polymorphism. Inheritance allows one to develop solutions to complex problems incrementally by defining new objects in terms of previously defined objects. Data encapsulation or simply encapsulation allows the hiding of the internal state of the objects. Encapsulated objects are those objects that can only be assessed by their methods instead of their internal states. There are three types of encapsulated objects users and developers should recognize. The first is full encapsulation, in which all the operations on objects are done through message sending and method execution. The second is write encapsulation, which is where the internal state of the object is visible only for reading operations. The third is partial encapsulation, which involves allowing direct access for reading and writing for only a part of the internal state. Object identity allows objects of the database to be independent of each other. Polymorphism and dynamic binding allow one to define operations for one object and then to share the specification of the operation with other objects. This allows users and/or programmers to compose objects to provide solutions without having to write code that is specific to each object. The language important to OODBMS is data definition and manipulation language (DDML). The use of this language allows persistent data to be created, updated, deleted, or retrieved. An OODBMS needs a computational versus a relational language because it can be used to avoid impedance mismatch. DDML allows users to define a database, including creating, altering, and dropping tables and establishing constraints. DDMLs are used to maintain and query a database, including updating, inserting, modifying, and querying data. The OODBMS has many advantages and benefits. First, object-oriented is a more natural way of thinking. Second, the defined operations of these types of systems are not dependent on the particular database application running at a given moment. Third, the data types of object-oriented databases can be extended to support complex data such as images, digital and audio/video, along with other multi-media operations. Different benefits of OODBMS are its reusability, stability, and reliability. Another benefit of OODBMS is that relationships are represented explicitly, often supporting both navigational and associative access to information. This translates to improvement in data access performance versus the relational model. Another important benefit is that users are allowed to define their own methods of access to data and how it will be represented or manipulated. The most significant benefit of the OODBMS is that these databases have extended into areas not known by the RDBMS. Medicine, multimedia, and high-energy physics are just a few of the new industries relying on object-oriented databases. As with the relational database method, object-oriented databases also have disadvantages or limitations. One disadvantage of OODBMS is that it lacks a common data model. There is also no current standard, since it is still considered to be in the development stages. Who is currently using an OODBMS to handle mission critical data? The following information was gleaned from the ODBMS Facts website. The Chicago Stock Exchange manages stock trades via a Versant ODBMS. Radio Computing Services is the worlds largest radio software company. Its product, Selector, automates the needs of the entire radio station from the music library, to the newsroom, to the sales department. RCS uses the POET ODBMS because it enabled RCS to integrate and organize various elements, regardless of data types, in a single program environment. The Objectivity/DB ODBMS is used as a data repository for system component naming, satellite mission planning data, and orbital management data deployed by Motorola in The Iridium System. The Object Store ODBMS is used in Southwest Airlines Home Gate to provide self service to travellers through the Internet. Ajou University Medical Center in South Korea uses Intersystems Cachà ¨ ODBMS to support all hospital functions including mission-critical departments such as pathology, laboratory, blood bank, pharmacy, and X-ray. The Large Hadron Collider at CERN in Switzerland uses an Objectivity DB. The database is currently being tested in the hundreds of terabytes at data rates up to 35 MB/second. As of November, 2000, the Stanford Linear Accelerator Center (SLAC) stored 169 terabytes of production data using Objectivity/DB. The production data is distributed across several hundred processing nodes and over 30 on-line servers. Below is a list of advantages and disadvantages of using an OODBMS over an RDBMS with an object oriented programming language. Advantages Composite Objects and Relationships: Objects in an OODBMS can store an arbitrary number of atomic types as well as other objects. It is thus possible to have a large class which holds many medium sized classes which themselves hold many smaller classes, ad infinitum. In a relational database this has to be done either by having one huge table with lots of null fields or via a number of smaller, normalized tables which are linked via foreign keys. Having lots of smaller tables is still a problem since a join has to be performed every time one wants to query data based on the Has-a relationship between the entities. Also an object is a better model of the real world entity than the relational tuples (attributes) with regards to complex objects. The fact that an OODBMS is better suited to handling complex, interrelated data than an RDBMS means that an OODBMS can outperform an RDBMS by ten to a thousand times depending on the complexity of the data being handled. Class Hierarchy: Data in the real world is usually having hierarchical characteristics. The ever popular Employee example used in most RDBMS texts is easier to describe in an OODBMS than in an RDBMS. An Employee can be a Manager or not, this is usually done in an RDBMS by having a type identifier field or creating another table which uses foreign keys to indicate the relationship between Managers and Employees. In an OODBMS, the Employee class is simply a parent class of the Manager class. Circumventing the Need for a Query Language: A query language is not necessary for accessing data from an OODBMS unlike an RDBMS since interaction with the database is done by transparently accessing objects. It is still possible to use queries in an OODBMS however. No Impedence Mismatch: In a typical application that uses an object oriented programming language and an RDBMS, a signifcant amount of time is usually spent mapping tables to objects and back. There are also various problems that can occur when the atomic types in the database do not map cleanly to the atomic types in the programming language and vice versa. This impedance mismatch is completely avoided when using an OODBMS. No Primary Keys: The user of an RDBMS has to worry about uniquely identifying tuples by their values and making sure that no two tuples have the same primary key values to avoid error conditions. In an OODBMS, the unique identification of objects is done behind the scenes via OIDs and is completely invisible to the user. Thus there is no limitation on the values that can be stored in an object. One Data Model: A data model typically should model entities and their relationships, constraints and operations that change the states of the data in the system. With an RDBMS it is not possible to model the dynamic operations or rules that change the state of the data in the system because this is beyond the scope of the database. Thus applications that use RDBMS systems usually have an Entity Relationship diagram to model the static parts of the system and a separate model for the operations and behaviours of entities in the application. With an OODBMS there is no disconnect between the database model and the application model because the entities are just other objects in the system. An entire application can thus be comprehensively modelled in one UML diagram.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.