Object based Data Models

Imagine we have to design database for college. What is the real world entities involved with college? They are college, Students, Lecturer, Course, Subject, Marks etc. Once all the entities are listed, we find out the relationship between them and try to map all of them. Also we list what are the attributes related to each entity like student id, name, lecturer name, course that he is teaching, different subjects, pass mark, grade levels etc. Here we are not bothered about what data value is stored, what is the size of each data etc. We know only entities involved, their attributes and mapping at this stage.

Object based Data Models are based on above concept. It is designed using the entities in the real world, attributes of each entity and their relationship. It picks up each thing/object in the real world which is involved in the requirement.

There are two types of object based data Models – Entity Relationship Model and Object oriented data model. ER data model is one of the important data model which forms the basis for the all the designs in the database world. It defines the mapping between the entities in the database. Object oriented data model, along with the mapping between the entities, describes the state of each entity and the tasks performed by them.

Entity Relationship Data Models

Consider the example above. It maps entities like Student, Lecturer, Subjects, and Marks with each other to form the relation among them. It also list attributes of each objects. ER model represents the all these entities, attributes and their relationship in the form of picture to make the developer understand the system better. A simple ER diagram for above example can be drawn as below. Are you able to understand what are the entities involved, what are its attributes and their relations that we were discussing better here? Yes, it is clean and clear what a STUDENT database look like. It gives the clear understanding of how they are scattered and mapped. If we have missed any entities or attribute or the mapping, we can easily identify here. If we represent it in some tables, it would be difficult to identify this gap.

In the below diagram, Entities or real world objects are represented in a rectangular box. Their attributes are represented in ovals. Primary keys of entities are underlined. All the entities are mapped using diamonds. This is one of the methods of representing ER model. There are many different forms of representation. More details of this model are described in ER data model article.

Basically, ER model is a graphical representation of real world objects with their attributes and relationship. It makes the system easily understandable. This model is considered as a top down approach of designing a requirement.


  • It makes the requirement simple and easily understandable by representing simple diagrams.
  • One can covert ER diagrams into record based data model easily.
  • Easy to understand ER diagrams


  • No standard notations are available for ER diagram. There is great flexibility in the notation. It’s all depends upon the designer, how he draws it.
  • It is meant for high level designs. We cannot simplify for low level design like coding.

Object Oriented Data Models

This data model is another method of representing real world objects. It considers each object in the world as objects and isolates it from each other. It groups its related functionalities together and allows inheriting its functionality to other related sub-groups.

Let us consider an Employee database to understand this model better. In this database we have different types of employees – Engineer, Accountant, Manager, Clark. But all these employees belong to Person group. Person can have different attributes like name, address, age and phone. What do we do if we want to get a person’s address and phone number? We write two separate procedure sp_getAddress and sp_getPhone.

What about all the employees above? They too have all the attributes what a person has. In addition, they have their EMPLOYEE_ID, EMPLOYEE_TYPE and DEPARTMENT_ID attributes to identify them in the organization and their department. We have to retrieve their department details, and hence we sp_getDeptDetails procedure. Currently, say we need to have only these attributes and functionality.

Since all employees inherit the attributes and functionalities of Person, we can re-use those features in Employee. But do we do that? We group the features of person together into class. Hence a class has all the attributes and functionalities. For example, we would create a person class and it will have name, address, age and phone as its attribute, and sp_getAddress and sp_getPhone as procedures in it. The values for these attributes at any instance of time are object. i.e. ; {John, Troy, 25, 2453545 : sp_getAddress (John), sp_getPhone (John)} forms on person object. {Mathew, Fraser Town, 28, 5645677: sp_getAddress (Mathew), sp_getPhone (Mathew} forms another person object.

Now, we will create another class called Employee which will inherit all the functionalities of Person class. In addition it will have attributes EMPLOYEE_ID, EMPLOYEE_TYPE and DEPARTMENT_ID, and sp_getDeptDetails procedure. Different objects of Employee class are Engineer, Accountant, Manager and Clerk.

Here we can observe that the features of Person are available only if other class is inherited from it. It would be a black box to any other classes. This feature of this model is called encapsulation. It binds the features in one class and hides it from other classes. It is only visible to its objects and any inherited classes.


  • Because of its inheritance property, we can re-use the attributes and functionalities. It reduces the cost of maintaining the same data multiple times. Also, these informations are encapsulated and, there is no fear being misused by other objects. If we need any new feature we can easily add new class inherited from parent class and adds new features. Hence it reduces the overhead and maintenance costs.
  • Because of the above feature, it becomes more flexible in the case of any changes.
  • Codes are re-used because of inheritance.
  • Since each class binds its attributes and its functionality, it is same as representing the real world object. We can see each object as a real entity. Hence it is more understandable.


  • It is not widely developed and complete to use it in the database systems. Hence it is not accepted by the users.
  • It is an approach for solving the requirement. It is not a technology. Hence it fails to put it in the database management systems.
Translate »