SIMILARITIES AND DIFFERENCES IN DATABASE MODELS
Name:
Course:
Presented to:
Date:
Introduction
Different organizations and institutions need to manage large quantities of data, which may be structured or unstructured. In order to effectively manage this data, organizations need to employ or develop information systems which are used to organize and document data. Each information system is developed based on a specific database design model (Coronel et al, 2012). Database design models describe rules of entities’ relationships or how people, materials and objects interact within an organization. This paper identifies five database models, describes them and the functions of each and compares and contrasts them.
Database Differentiation Matrix
Data Model Description Similarities and Differences Function
Relational Model This is a database design model that allows for the definition of structures, integrity constraints and storage and retrieval operations. Data in a relational model of a database is organized into tuples that are grouped into relations (Song et al, 2007). The data and relations between them are then presented in tabular form. A table contains a collection of records, each of which contains the same fields. The properties of these tables are; similarity in column values; have atomic values; each row is unique; the sequence in rows and in columns is insignificant; and each column has a unique name (Grad, 2012). Data is grouped into ‘entity types’ just like in the other models.
However, the relation model presents data in tables, unlike the other models discussed in this paper. It has just a single concept (relation) unlike other models such as the entity-relationship model which has many concepts (attributes, relations, entities). Also, relational model is better suited for presenting and defining manipulations on complex data compared to the other models.
However, it requires the use of key and index tables which slows down applications (Gerald & Albert, 2001). The network model, for instance, provides faster access to the data compared to the relational model. The main purpose of this model is to provide a declarative method in which the views of the users about what they think should be contained in a database system can be collected and be incorporated in the database system (Song et al, 2007). The model also provides a method for specifying data and queries and provides procedures for answering questions to database users.
Entity-Relationship Model The Entity-relationship model is a method of describing database in an abstract way. It describes a way of presenting data in tables, but unlike in the relational model, some of the data in these tables is related to or points to data in other tables (Chen, 1975). This model may be developed into conceptualization data model, logical data model and physical data model, all of which contribute immensely to the final output (Chen, 1975). Diagrams related to this model do not show single instances of relationships or single entities. Rather, they show relationship sets and entity sets. This model classifies entities as either strong or weak (Chen, 1975).Strong entity types are those that exist independently from others (such as an employee) while weak entities depend on others. Both strong and weak entities have different attributes which are presented in entity-relationship model diagrams. Like in other models, data is grouped into ‘entity types.’ This model has many concepts (attributes, relations, entities), unlike the other models, which do not have multiple concepts (Gerald & Albert, 2001). Unlike the other models, this model does not have operations on its structures. Finally, the entity-relationship model is not well suited for computer implementation, in comparison with the other models (Gerald & Albert, 2001). This model explains the relationship that exists among human beings, between human beings and properties or projects and among projects or properties in an organization (Chen, 1975). Further, it helps to distinguish between relevant and irrelevant information when designing a database system. According to Chen (1975), this model is also used to describe data objects contained in a database system. Lastly, entity-relationship model diagrams help in designing logical databases.
Hierarchical Model In this model, data is organized in a tree like structure and is represented using parent/child relationship. This model is based on the argument that a child can only have one parent but a parent can have many children (Taofiki, 2011). Thus, any record or details of a specific record are listed under a particular entity type. The tree structure is equivalent to a table: each individual attribute is represented as a column and each record as a row (Taofiki, 2011). Different entities are related to one another using a one-to-many relationship (also written as 1: N relationship). Hierarchical model is similar to the network model in that both adopt a parent-child relationship in their representation of data (Gerald & Albert, 2001). However, this model recognizes that a child can have only one parent, unlike the network model which allows a child to have several parents (Cummer et al, 1998). Further, the horizontal and vertical structure of data presented in this model is equivalent to rows and columns in a relational model respectively. However, hierarchical model is less suitable in presenting complex data, in comparison with relational and entity-relationship models (Gerald & Albert, 2001). Hierarchical model is primarily applied in database management systems that store data in hierarchical format, such as libraries and phone number databases (Cummer et al, 1998).
Network Model The Network database model is a more flexible way of representing objects and their relationships in a hierarchy (D’Auria & Resnick, 2006). The distinguishing feature of this model is that the schema, viewed as a graph in which relationship types (also known as arcs) and object nodes (also known as nodes), is not restricted to being a lattice or a hierarchy (D’Auria & Resnick, 2006). This model allows child records to connect to multiple parents, creating a generalized graph structure. The network model is similar to the hierarchical model since both represent data as a tree of records. However, unlike the hierarchical model which represents a relationship where a parent has many children and a child has only one parent, the network model allows a child to have many parents (Cummer et al, 1998). Further, Cummer et al (1998) explains that unlike the hierarchical model, the network model allows for natural modeling of relationship between entity types. According to Cummer et al (1998), network model offers a lower level, less declarative interface compared to the relation model. One of the main functions of the network model is to represent complex data relationship more effectively and in a way that it can be easily understood by the user(s) (D’Auria & Resnick, 2006). Secondly, the distinct features of this model help to improve database According to D’Auria and Resnick (2006), this model is applied in the process of imposing database standard (D’Auria & Resnick, 2006).
Object-Oriented Model This is a database design model in which data is represented in form of objects. This model allows programmers to develop products, store them in databases as objects and modify existing objects to make new ones within an object-oriented management system (Coulondre & Libourel, 2002). Unlike the other models, object-oriented model represents data in form of objects (Gerald & Albert, 2001)., It also lucks performance overheads to store or retrieve data, unlike the hierarchical and the network models. However, the objects developed by this model provide for higher level of performance in comparison with hierarchical and network models. As well, it allows for better management of complex interrelationships than hierarchical and network models (Gerald & Albert, 2001). Finally, this model maintains a less clear division between an application and database model compared to hierarchical, network and relational models. The object-oriented model is used in extending semantics of Java, Smalltalk and C++ object programming languages to enhance full-featured database programming capability. It also ensures native language compatibility is retained during database development.
Conclusion
In conclusion, various database design models have been developed, each of which is unique and fulfils and fulfils a defined function. However, all of them are meant to help database managers and designers in analyzing available information and information needs within organizations or institutions. These models include object-oriented model, hierarchical model, network model, entity-relationship model and relation model.
References
Chen, P. (1975). The entity-relationship model: toward a unified view of data. ACM SIGIR
Forum. 10(3), p. 9
Coronel, C., Morris, S., and Rob, P., (2012). Database systems: design, implementation, and
management. New York: Cengage Learning
Coulondre, S. & Libourel, T. (2002). An integrated object-role oriented database model, Data &
Knowledge Engineering. 2002, 42, (1), pp. 113 – 141
Cummer, L., McClure, S., HYPERLINK “http://shu.summon.serialssolutions.com/search?s.dym=false&s.q=Author%3A%22Mullins%2C+Craig+S%22” Mullins, C. & S; Lalonde, G., (1998). Database management systems
[Feature report], Computing Canada. 24(3), p. 23
D’Auria, B and Resnick, SI (2006), Data network models of burstiness, Advances in Applied
Probability. 38(2), pp. 373 – 404
Gerald, V. & Albert K., (2001). Comparison of database management systems. The Journal of
Computer Information Systems. 41(4), p. 43
Grad, B., (2012). Relational Database Management Systems: The Formative Years [Guest
editor’s introduction], IEEE Annals of the History of Computing. 34(4), pp. 7 – 8
Song, E., Yin, S., & Ray, I. (2007). Using UML to model relational database operations,
Computer Standards & Interfaces. 29(3), pp. 343 – 354
Taofiki A. A., (2011), Hierarchical Database Model for Querying Economic Network
Independence Distribution. International Journal of Decision Support System Technology (IJDSST). 3(3), pp. 58 – 67
