The object-oriented database model ties related packages together. In other words, a data set and all its attributes are combined with an object. In this way, all of the information is directly available. Instead of distributing everything across different tables, then, the data can be retrieved in one package. Alongside the attributes, methods are also stored in the objects. This is where the databases’ proximity to object-oriented programming languages becomes clear. As in programming, each object has certain activities that it can carry out.
In turn, objects are brought together in classes. Or, to put it more accurately: an object is a concrete unit in an abstract class. This generates a hierarchy of classes and subclasses. Within such a construct, subclasses assume the properties of higher-level classes and expand on these with their own attributes. At the same time, objects in one class can also be connected with other classes. This breaks up the strict hierarchy and makes sure that the objects are interlinked. Simple objects can be combined with complex objects.
To address the various objects, the corresponding database management system automatically assigns a one-off identification to each unit. In this way, objects can be easily retrieved again after they have been saved.
Let’s look at an example. Assume we are saving the concrete object of a bicycle as an object-oriented unit with all of its properties and methods. It is red, you can ride it, it has a saddle, and so on. This object is then simultaneously part of the class ‘Bicycles’. Inside the same class, for example, we might also find a blue and a green bicycle. The class ‘Bicycles’ is in turn a subcategory of ‘Vehicles’, which also contains ‘Cars’. At the same time, however, the object also has a connection to the class ‘Leisure activities’. If we retrieve our object via its unique ID, all of its related attributes and methods are directly available.