Rdbms Oodbms Ordbms And Xml Information Technology Essay

Data modeling refers to the process where data is structured and organized. It is a key component in the field of computer science. Once data is structured, it is usually then implemented into what is called a database management system (DBMS). The main idea behind these systems to manage vast amounts of both structured and unstructured data.

Unstructured data include documents, word processing, e-mail messages, pictures, and digital video and audio files. Structured data, what is needed to make a data model (via a data model theory), is found in management systems like relational databases. A data model theory is the formal description of a data model.

In the development of software, the projects may focus on the design of a conceptual data model, or a logical data model. They represent two ways of describing data models. The logical description focuses on the basic features of the model, outside of any particular implementation. The physical description, on the other hand, focuses on the implementation of the particular database hosting the model’s features.

Get Help With Your Essay

If you need assistance with writing your essay, our professional essay writing service is here to help!
Find out more about our Essay Writing Service

1.2 Data Models

We can define the Data Model as a collection of concepts that can be used to describe the structure of a database, provides the necessary means to achieve this abstraction. Notice that we mean by structure of a database the data types, relationships, and constraints that should hold on the data. Most data models also include a set of basic operations for specifying retrievals and updates on the database.

In addition to the basic operations provided by the data model, it is becoming more common to include concepts in the data model to specify the dynamic aspect or behavior of a database application. This allows the database designer to specify a set of valid user-defined operations that are allowed on the database objects.

Database Model can be categorized according to the data structures and operators they present to the user.

(1) E-R Model

(2) Hierarchical Data Model

(3) Network Data Model

(4) Semi Structured Data Model

(5) Relational Data Model (RDBMS)

(6) Object Oriented Data Model (OODBMS)

(7) Object Relational Data Model (ORDBMS)

Among all data models mentioned below, relational model followed by object oriented and object relational models enjoyed most popularity, we are going to compare them and then we try to find out what is the relationship between XML and these relational data models.

COMPARISON RDBMS, OODBMS, ORDBMS and XML

2.1 Relational Database Management System (RDBMS)

The relational model is based on the structure of a database. A database is simply a collection of one or more relations or tables with columns and rows. The use of set theory allows for data to be structured in a series of tables that has both columns and rows. Each column corresponds to an attribute of that relation, while each row corresponds to a record that contains data values for an entity.

The main elements of RDBMS are based on Ted Codd’s 13 rules for a relational system, the concept of relational integrity, and normalization. The three fundamentals of a relational database are that all information must be held in the form of a table, where all data are described using data values. The second fundamental is that each value found in the table columns does not repeat. The final fundamental is the use of Standard Query Language (SQL).

Benefits of RDBMS are that the system is simple, flexible, and productive. Because the tables are simple, data is easier to understand and communicate with others. RDBMS are flexible because users do not have to use predefined keys to input information. Also, RDBMS are more productive because SQL is easier to learn. This allows users to spend more time inputting instead of learning. More importantly, RDBMS’s biggest advantage is the simplicity with which users can create and access data and extend it if needed. After the original database is created, new data categories can be added without the existing application being changed.

There are limitations to the relational database management system. First, relational databases do not have enough storage area to handle data such as images, digital and audio/video. The system was originally created to handle the integration of media, traditional fielded data, and templates. Another limitation of the relational database is its inadequacy to operate with languages outside of SQL. After its original development, languages such as C++ and JavaScript were formed. However, relational databases do not work efficiently with these languages. A third limitation is the requirement that information must be in tables where relationships between entities are defined by values.

Today, the relational model is the dominant data model as well as the foundation for the leading DBMS products, which include IBM’s DB2 family, Informix, Oracle, Sybase, Microsoft’s Access and SQLServer.

2.3 Object Oriented Database Management (OODBMS)

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 has 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.

A significant difference between object-oriented databases and relational databases is that object-oriented databases represent relationships explicitly, supporting both navigational and associative access to information. As the complexity of interrelationships between information within the database increases, so do the advantages of representing relationships explicitly. Another benefit of using explicit relationships is the improvement in data access performance over relational value-based relationships.

2.4 Object Relational Database Management System (ORDBMS) 

Object Relational Database Management System (ORDBMS) is an extended development of existing relational database system. To overcome the certain limitations and to increase the performance level, and to achieve the benefits of relational model and object model, ORDBMS technology evolved by combining the relational databases and object oriented concepts.

We can incorporate our custom data types, functions, operators and methods with the database and we can store images, geographical information and multimedia objects such as audio and video in ORDBMS. And it allows us to raise the level of abstraction at which we want to view the problem domain.

In RDBMS, it is difficult to map the objects to the database whereas in OODBMS object oriented features are supported extensively. However, in ORDBMS limited support of object oriented features, mostly to new data types. Moreover, it supports abstract data types (ADTs) and complex relationships.

ORDBMSs have the same query centric approach to data management as we have in RDBMS. Through declarative SQL statements, we can handle the data access and there is no procedural or object-at-a-time, navigational interface. ORDBMS allows us to continue using our existing systems, without having to make major changes. Another advantage is that it allows users and programmers to start using object-oriented systems in parallel. In ORDBMS technology the concept of extensibility is a principal innovation.

ORDBMSs have an extended functionality of DBMS and information system which can be deployed over different machines as it has a central server program whereas OODBMS has a typical distributed data architecture. This is the difference in architectures of ORDBMS and OODBMS. Another difference between ORDBMS and OODBMS is, an object-oriented database’s design is based solely on Object-Oriented Analysis and Design (OOAD) principles whereas ORDBMS is an extended development of traditional relational database with object oriented concepts structures such as abstract data type, nested tables, and varying arrays.

In simple words, we can say that ORDBMSs synthesize the features of RDBMSs with the best ideas of OODBMSs. 

Where Does Xml Fit?

DBMS have advanced into the Internet and Web Age. Stored data is widely being accessed through a Web browser. Today, queries are being generated through Web-accessible forms and answers are being formatted using a mark-up language such as HTML or XML. In addition, many vendors and distributors are adding features to their DBMS aimed at making it better equipped for Internet usage

If your application requires moving data between enterprises, XML is a good solution. XML lets you send data across the Internet and through firewalls by using the standard HTTP protocol. XML is also a good choice if your application needs to move data between hardware or software platforms (OSs). XML is not machine- or OS-specific. Finally, XML is a good choice if you simply want to ensure that your application or data source is robust even if the data schema changes. XML enables your application to be extensible because you access the XML-formatted data by using element and attribute names instead of offsets, which structured programming languages use. If you have one or more of these application requirements, then XML is a good solution.

3.1 Data storage using XML

XML Databases offer the same functionality of Object Databases, data is structured in a hierarchical manner and they store XML documents instead of theoretical Objects. We could even say that the XML database model is just a comeback of the hierarchical model because in principle this is the same concept of data storage, indexation and querying. XML databases have the added benefit of being able exchange the data in its native format, which is perfect for today’s web requirements.

3.2 Data exchange using XML

 XML messages exchanged are by nature hierarchical and deeply tree structured, sometimes the data is even unpredictable and sometimes the structure is prone to change at any time, developers trying to map this data to a relational structure may find their lives becoming more and more difficult.

XML Databases can accept structured as well as unstructured data. XML documents do not have to conform to any set Schema so a developer can fire anything they wish at the database, no need to modify tables and columns. XML Schema allows one to define an XML document in both its node structure (e.g. elements and attributes) as well as the data types contained within these nodes. It allows one to define these data types in very explicit detail.

This usage has a lot of advantages, at least for front-end applications:

– It saves a lot of memory by removing application-specific classes and replacing it with a small set of classes, the DOM. This means that a single application server can handle a lot more of different data types. This is important to us as we designed our presentation layer for Application Service Provider (ASP) usage. The ASP context means that to keep costs as low as possible, you run many different applications in the same application server. If each application had its own set of application-specific classes to model data, the application server would be crowded with classes.

– It saves a lot of time and energy by the sheer flexibility of XML. If your data and application code are written in XML, adding or removing data to the presentation layer is a way much easier than if data was modelled in application-specific classes. You don’t have to modify the application-specific classes, recompile the whole application and redeploy.

There are of course some disadvantages, but I think it’s just a matter of work and time before they can be fixed:

-If you don’t seem to have a requirement to move data between enterprises, across the Internet, or through firewalls. So, unless you’re trying to make your applications more extensible, XML isn’t a good choice for your scenario

-Using XML as your database will work fine as long as your datasets stay relatively small. Meaning, it can all fit in memory and stay there comfortably. Once your data grows to the point where it will not all fit in memory, you will probably start seeing serious performance degradation

-The problem for many XML aspirations is that the core of an RDBMS are its relations. In particular, the set of constraints that exist between tables, and that are enforced by the RDBMS are what make RDBMS’s so useful and powerful. XML has no inherent mechanism for enforcing constraints.

-If you have a heavy investment in an Object-Relational DBMS (Oracle, MS, IBM) and have learned to live with them changing the data model in such systems from relational to anything else would entail a huge amount of work and risk.

Conclusions

Relational databases have a strong-hold on the current database market due to their maturity, reliability, the majority of existing applications using the relational model. As object-oriented programming languages continue emerging as the favored or dominate programming language for building new applications, probably OODMBS will surpass the RDBMS as the most popular and dominate database management systems in the business market. Something similar is happening to the object-relational database management system (ORDBMS) which the main objective is to merge the benefits of both the relational and object-oriented model. Many RDBMS products on the market today are releasing first generation ORDBMS products. If these products are able to fulfill the main objective of ORDBMS as well as enable companies to convert existing relational models to partial or full object-oriented models, the end of relational databases could be eminent. The growth in popularity of XML has been almost as dramatic as that of OO. As a consequence, new standards for data objects and new development products based on XML keep emerging.

In my opinion the main reason why RDBMS Data Model dominates the market right now is because RDBMS design has evolved to disallow users from asking questions that the database isn’t good at answering. The fact that we ship databases that only permit things that we know how to answer efficiently does NOT imply that we will never be able to answer other questions more efficiently. It is quite easy to see a trend in the industry that shows consistent continual progress at solving hard query problems. Of course some problems will always be hard (distributed cost-based query optimization is one), but I would point out that research on RDBMS optimizations has tapered off quite a bit and we have seen major increases in research geared towards semi-structured data. So we are simply easing off on some of the traditional RDBMS constraints and beginning to allow things like recursive self-joins, ragged hierarchies, etc. and we are optimizing these things. I mean, we already solved the RDBMs optimization challenge and now it is time to move to the next thing. XML seems like a very appropriate evolutionary step.