Chapter 10 – Object Technology and DBMS – Introduction to Database Management Systems

Chapter 10






Object Technology and DBMS

Most modern computer software development is based on object-oriented principles. Objects can be organized, classified, created, detstroyed and so on.

Chapter Highlights

  • Object Technology
  • Object Oriented (OO) Fundamentals
  • Relevance of OO Technology to RDBMS Technology
  • Design of OO Systems in Relation to RDMS
  • Object Oriented Database Management Systems (OODBMS)

10.1 AN INTRODUCTION TO OBJECT TECHNOLOGY

As the name suggests, the basis of object technology is an object. The revolution brought about by object technology can be largely attributed to the idea of objects. What is an object afterall?

At the simplest level, anything that we see, touch, smell or feel is an object.

Thus, the book that you are reading now is an object, each page itself is an object, and you are also an object! Well, this is a fairly loose definition of the term object. Let us be a bit more technical, and understand what the term object means.

The basics of object technology can be traced back to the 1960s. A language called as Simula (abbreviation for Simulation language) first used the ideas of object technology. It was designed to build precise models of complex and large physical systems (e.g. big buildings, aircrafts, machines, etc.), which could consist of thousands of components. In Simula, models were defined as objects. For instance, the wing of an aircraft is an object, which is turned by another object called shaft, and so on.

In the world of computer technology, an object is a self-contained unit which contains both operations as well as data. Note that this is dramatically different from what we had discussed so far. In the procedural approach, we had mainly talked about the operations, and introduced data only at the very end. Even then, we had clearly mentioned that operations and data are separate entities in a program. Now, we are talking about operations and data as two portions of a single entity, which we call an object. Data is no longer considered in isolation—it is tightly coupled with an object. This idea is shown in Fig. 10.1.

Fig. 10.1 Object = Operations + Data

Object technology has evolved since the days of traditional Structured Systems Analysis and Design (SSAD). Object-oriented systems are supposed to provide significant benefits in terms of reuse and maintainability of software. Relational databases and object technology are quite opposite of each other in their view of applications and data. Therefore, they must be brought to a common platform to make their interaction smoother.

Also note that we have not mentioned the term program here. We are talking about objects. How do objects relate to a program, then? Well, in the world of object technology, a program actually becomes a collection of well-defined objects. We no longer talk about a program as a collection of operations and data; instead, we call it as a group of objects, as shown in Fig. 10.2.

Fig. 10.2 Program in object technology

For example, in a billing application, the objects could be customer, invoice, payment, inventory, and so on. All these objects would interact with each other as and when needed to constitute an application program. Similarly, in a geometric application, the various objects could be circle, triangle, line, and so on.

10.1.1 Attributes and Methods

In object technology, operations or functions are called methods. On the other hand, variables are called attributes.

For instance, if you consider a dog as an object, the dog's eyes, ears, nose, legs tail are all its attributes. This is shown in Fig. 10.3. Similarly, barking, eating, running standing still are the dog object's methods.

Quite interestingly, this nature of objects makes them self-sufficient. For instance, the moment we think of a dog, we can describe everything about a dog (either in the form of attributes or methods). There is nothing more about the object, that is the dog, which is missing here. This characteristic of object technology is quite enthralling and useful. From a designer's perspective, this means that an object no longer depends on other objects for its own features and characteristics. Similarly, from a programmer's point of view, an object can be constructed as a black box which is completely self-contained and can be safely guarded from the outside world.

Fig. 10.3Dog object and its attributes

10.1.2 Messages

However, the self-sufficient nature of objects raises a question. We know that a dog can bark. But how can we instruct a dog to bark? Unless we are able to do so, the dog object, although complete in its own respect, would be quite useless to the external world. This means that we must be able to have a mechanism by which we can instruct the dog to perform the desired action. Object technology provides this facility in the form of messages.

We can pass a message to an object, requesting it to perform a
specific action.

In the real world, objects can interact with each other in a number of ways, and for a variety of purposes. To achieve this, one object can send a message to another object. This message requests the called object to perform one of its methods. This idea is shown in Fig. 10.4, in which a message is being passed on to the dog, which causes it to invoke its bark method.

This leads us to another question. How do we know that a dog can bark? Well, that might be easy, consider an object called as student and assume that we are interested in finding out the student's birth date. How would we know what message we should send to the student object, so that it can send us the student's birth date? We cannot simply assume or hope that the student object would contain a method for this purpose. Consequently, as it turns out, each object must let the external world know which methods it supports. Without this, it is not possible for other objects to send any messages to it. The process of achieving this objective is actually quite simple. Every object must publish a list of methods that it contains. This would enable other objects to consult this published list and send messages to execute its methods. This idea is shown in Fig.10.5.

Fig. 10.4 Sending a message to the dog object to invoke its bark method

Fig. 10.5 List of methods published by the dog object

Thus, an object A can send a message to object B, requesting it to execute one of its methods. Similarly, object B can invoke any method of object A by sending a message, and so on, as shown in Fig. 10.6.

Fig. 10.6 Objects send messages to each other to call each other's methods

The diagram also brings a very crucial point to the fore. Note that an object can send a message to another object, requesting it to execute its method. However, an object does not seem to have an access to another object's data. This is indeed true. In general, an object cannot access another object's data. An object hides its data from the outside world, which is exactly the opposite of what it does with its methods (which it publishes to the entire world). Of course, in the real world of softwares, there are slight variations to this concept. However, at this juncture, it is safe to assume that an object guards its data safely, and does not allow an outsider to access it. However, it exposes its methods to everyone else.

If you think of it, this is quite sensible. Allowing data access to more than one entity almost always leads to some sort of problems. Object technology recognises this pitfall early, and makes the boundaries between objects quite explicit when it comes to handling data items. This is even more significant in the case of object technology, since we have been calling objects as self-sufficient. If they have to remain as self-sufficient entities, not only must they be capable of handling their data items, but they must also be assured that no one else can touch their data items.

10.1.3 What is Modelling?

The term object orientation is frequently used in object technology. It's meaning is quite simple. It is the technique of modelling a system. Note that the term system is used in a very vast context here. It can refer to as simple an entity as a single program, or it can actually point to a very complex application system consisting of a number of programs, databases and other infrastructure pieces.

The idea here is to model a system in the form of a number of objects which interact with each other. For instance, consider a person Ana who watches TV when at home and goes to office in her car. If we have to model this situation using object technology, the resulting picture will be as shown in Fig.10.7.

Fig. 10.7 Interaction between real-world objects

As we can see, the beauty of this scheme is the minimum differences in the way we perceive the various objects (e.g. Ana, TV, office, car) and the way they can actually be modelled in a computer-based system. We think of computer objects in the same breath as real-world objects. This is a revolutionary concept in the computer world, where analysts and designers are generally forced to think in terms of computer-based entities such as databases, programs, and so on, right from the beginning. Now, they can think of real-world objects as, well, objects! This principle, which reduces the gap between what we perceive and how we model, is called ‘reduction in the semantic gap’. As we can guess, the semantic gap is the gap between the outside view of an object, and its implementation/model. This is shown in Fig. 10.8.

Fig. 10.8 Semantic gap

The smaller the semantic gap, the better, simply because it means that objects can be modelled as closely as possible to their real-world form.

The two main benefits of a small semantic gap are: (a) It makes the process of understanding the requirements of modelling easy, and (b) It makes the process of modifications to software simpler. The second point is important because a smaller semantic gap means that objects are as highly self-contained as possible and, therefore changes to one object do not greatly affect other objects in the system.

10.1.4 Practical Example of an Object

We have discussed the concept of object at great length, and have considered examples that are usually not relevant to real-world computer programming. Therefore, let us now try to model an object that represents student information – an example that is very close to real-world computing.

Typically which information about a student would we like to store? The basic minimum set of information could consist of roll number, name, class, division, gender and date of birth. Of course, there could be many such categories, but for simplicity, we shall ignore them. It should be clear from our discussion so far that each of these information pieces can be modelled as an attribute. As we know, the second aspect of any object is methods. What should be the methods for this object? From our earlier discussion, an object must tightly hold all its attributes to its chest, and reveal whatever it wants only in the form of methods. Therefore, in this case, if another object wants to know the date of birth of a student, the student object must provide a method which provides this information (i.e. date of birth). Similarly, the student object should also provide methods that obtain or get information on the name, class, division and gender, given a roll number. Since these methods get information about a student, we can name them as getName, getClass, getDivision, and so on. Thus, our student object would look as shown in Fig.10.9.

This should give us a fairly good idea as to how objects look in real-life. In fact, the code written to declare a student object in an object-oriented language, such as Java or C++, is actually not dramatically different from the way we have written it here!

Fig. 10.9 Student object

10.1.5 Classes

Another key concept related to object technology is that of class. A class is a generic form of objects. For example, Tom, Ram, John and Ana are all persons. We can treat each one of them as an object. However, at a broader level, we can group them as belonging to a generic class called person. Similarly, truck, train, airplane and car are all vehicles. Therefore, we can treat all of them as objects, and make vehicle a generic entity; which means that vehicle would be a class. Numerous such examples can be given. However, the point is that a class is a generic template, whereas an object is a specific instance of that template. This idea is shown in Fig. 10.10.

Understanding the concept of a class from a programming perspective is actually quite easy. Recall how we declare an integer or a floating point number in a programming language such as Java or C#. It is done using the following syntaxes:

int i;

float f;

(Note: We shall ignore minor syntactical errors in order to keep the discussion simple rather than make it technically correct and complicated).

Fig. 10.10 Class and objects

What do these declarations convey? They tell us that i is going to be a number, which is an integer, whereas f is a floating point number. In comparison to our earlier discussion, are there certain equivalences? Well, we can consider int and float as similar to classes, and i and f as similar to objects of these two classes, respectively. Taking this idea a step further, can we declare an object (say car) for the vehicle class? The following statement in Java or C# should achieve it.

vehicle car;

Thus, we have a very important idea, as illustrated in Fig. 10.11.

Fig. 10.11 Classes and objects

This should help us understand the relationship between classes and objects very clearly. Just as integers, floating-point numbers are generic templates (i.e. classes); and so can be other types such as vehicle, student and person. For every such class, we can declare one or more specific instances (i.e. objects). This is shown in Fig. 10.12, in which we have a class and three objects corresponding to that class, with their unique identifiers.

Fig. 10.12 Class and objects

This description also tells us something more about classes and objects. A class has general characteristics, which all its objects automatically inherit. For instance, when we think about an int, we immediately perceive a number that cannot have fractional part or a value exceeding a maximum. Therefore, when we declare any number (say i) as an integer, it automatically obeys all these restrictions. Extending this concept, when we declare a student class, and ana as an object of this student class, ana automatically picks up all the default characteristics of the student class, such as roll number, name, date of birth, and others.

10.1.6 The Essence of Classes and Objects

Let us now revisit the question on how to declare classes and objects in a programming language, such Java or C#. For that, let us consider the same example of declaring an integer. We know that declaring an integer i takes the following simple form.

int i;

We know that int is the class here, and i is its object. An interesting observation is, we simply declare i as belonging to the category of integers. It automatically knows that it cannot store fractions, values beyond a certain range, and so on. Similarly, we should be able to simply declare ana as a student, and ana should automatically pick up all the characteristics of a student from the perspective of our current discussion (i.e. roll number, name, date of birth, etc). The following statement should do the trick:

student ana;

Unfortunately, things do not work this way. The reason for this is quite simple. Programming languages define certain classes as standard or default, which means that the compiler of the programming language knows how to deal with these classes. Examples of these are the basic data types, such as integers and floating point numbers. Thus, the moment we declare i as type int, the compiler enforces all the characteristics of integers with reference to i. However, when we declare ana to be of type student, the compiler has absolutely no clue as to what a student, and therefore, ana, means. Therefore, the declaration of ana as a student would fail. This means that we must first inform the compiler what a student means. Only when we tell the compiler what characteristics a student has, can we create instances or objects of it.

A data type, such as student is thus made up of many basic data types like integers, strings, floating point numbers, and so on, as shown in Fig. 10.13.

Fig. 10.13 Class is made up of a combination of many basic data types

The declaration of a student class in Java is shown in Fig. 10.14. Do not worry about the syntactical details. Concentrate only on the concept.

Fig. 10.14 Declaration of student class

Now, the compiler knows what the meaning of a student class is. It treats an object of this student class in a manner that is not completely different from an integer variable. Thus, it simply considers student as a higher-level data type. Now, the following statement makes sense to the compiler:

student ana;

It now knows that ana can have a roll number, name, class, and other attributes and that another object can send a message to her to obtain her name, class, division, and so on.

One clarification is necessary at this juncture. Consider the above student class. Let us assume that the attributes of the student class require 100 bytes of memory in the computer's RAM, and that the methods of the student class occupy 500 bytes of memory. Then, the memory representation of the student objects Ajay, Sunil and Shilpa would look as shown in Fig. 10.15.

Fig. 10.15 Memory consumption of objects (as it first appears)

Can we think of an improvement here? What would the attributes and methods of the student objects contain?

  • The attributes for these different objects would certainly have different values. For instance, the names of the students are different (note that the name is one of the attributes of the student). Similarly, their role numbers, classes, divisions, and other attributes are likely to be different.
  • What about the methods? We can see that every object would access the same method (i.e. the same code) of the class. There is nothing unique for every object, here.

Does this mean that we cannot share the attributes of different objects, but can share methods? Certainly, this is possible, and in fact this is how object technology implements attributes and methods. All the objects of a class have their own set of attributes, which is not shared with any other object. However, all the objects of a class share its methods. This saves on the memory of the computer and makes implementation of object methods easier. Thus, in the case of the student class, where we had 600 bytes of memory requirement per object, we would now need just 100 bytes per object. In addition, we would also need a common pool of 500 bytes of memory shared by all the objects for the methods portion.

Thus, the 1800 bytes that we would have needed for three student objects (3 objects, each of size 600 bytes) can be replaced with just 800 bytes (3 objects, each of size 100 bytes, plus a common area of 500 bytes for memory). This is shown in Fig. 10.16.

Fig. 10.16 Memory consumption of objects (as it actually is)

10.2 Abstraction

The concept of abstraction is very important in object technology. It is one of the most fundamental concepts in this area. Interestingly, abstraction is an extremely useful concept in our daily lives too. For example, we normally do not consider a book to be made up of many pages and diagrams, or a car to be made up of 100 different parts. If we do that, it would be difficult to cultivate the thinking process. Instead, we think of all these things as sub-parts of a book or a car object, respectively. Internally, these objects have a specific set of attributes (pages, spare parts) and behaviours (can be read, can be turned right). This allows us to think about these objects in an abstract fashion. Thus, we can read a book and drive a car easily. We are not bothered about their technical details. We think about objects as a whole.

Even in technical terms, abstraction is actually not restricted only to object technology. All programming languages support abstraction at various levels. Let us understand this.

  • A high-level language provides the programmer with keywords, variables, functions, and so on. For example, a high-level language would contain instructions such as ADD, COPY, MOVE, and others (or their equivalents). For instance, an instruction COPY A, B could mean copy the contents of variable B to variable A.
  • An assembly language is at a lower level in the sense that one instruction in a high level language maps to one or more assembly language instructions. For instance, a COPY instruction in a high-level language could result in multiple assembly language instructions, such as LOAD and STORE.
  • Furthermore, each assembly language instruction is translated to its corresponding machine language code. This is the language of zeroes and ones.
  • Finally, the machine language abstracts the voltages and current pulses inside a computer, and provides a language of zeroes and ones to the programmer.

This idea is shown in Fig. 10.17.

Fig. 10.17 Abstraction in programming languages

We must clarify that the idea of abstraction in object technology has more to do with the abstraction of objects themselves.

One observation must be stated. The object-oriented concepts are not limited to programming alone. The computer software's life has different steps such as analysis (understanding the problem), design (mapping the solution to the problem in terms of data structures), programming (actually writing the program code for the created designs) and storing data (traditionally in the form of files or databases). The object technology experts recommend that the true benefits of object technology can be realised only by applying it through the whole process.

An analyst has to identify different objects, their properties (attributes and methods), how they are going to interact with each other (messages) to achieve various functionalities, produce reports and create queries of the system. Then the analyst has to write specifications for the methods of the different objects. The programmer can then write programs. It is at this stage that object-oriented languages such as Java or C# can be used for coding. These languages allow you to define and manipulate objects. Ordinary languages such as C or COBOL do not allow definition of objects (although enterprise COBOL is evolving). Thus, they cannot be used for object-oriented systems. Similarly, we can perform the analysis in a traditional, structured way, which is process-oriented (where no objects are identified) and still use object-oriented languages such as C++ or Java. We will not get the real benefit of object technology in this case. For real benefit, the whole approach, from the beginning to the end, has to be object-oriented.

Fig. 10.18Abstraction can be used to generalise similar ideas

Abstraction allows an analyst to concentrate only on the essential aspects of objects and to ignore their non-key aspects. It facilitates postponing of many decisions to as late a date as possible. This also means that the analyst does not make commitments regarding the design or implementation. Thus, the analyst can focus only on the actual problem at hand (i.e. analysing a system and its requirements), rather than worrying about the implementation details. In other words, abstraction allows an analyst to think about what needs to be done, rather than how to achieve it. Because this analysis model is at a high level of conceptualisation, it can be reused in the later stages of a software project, such as design coding, testing and implementation.

Let us consider another example of abstraction. We normally stand in a queue when we visit a bank, a pizza shop, post office, and so on. In a similar way, the finished goods in a factory also move in sequence to form a queue. Let us assume that we need to represent these ideas in a computer program. We can apply the principles of abstraction here. That is, we can abstract the two ideas, and think only about the concept of a (generic) queue. We can apply the same principle in both the examples, using a single abstraction. The idea is shown in Fig. 10.18.

10.3 ENCAPSULATION

Encapsulation essentially protects the data in an object. As we have previously discussed, only certain methods defined within an object can be executed for manipulating the data within that object. We have to use one of them, if available, to update or even view the data. One object cannot interfere with the data within another object except through properly authorised requests for the execution of certain methods.

Encapsulation is actually a pretty old idea. Way back in the 1940s, programmers realised that the same sets of instructions were being repeated in their code at several places. Maurice Wilkes and his colleagues at Cambridge University soon realised that the repeating sets of instructions could be carved out and called from the main program as and when needed. This formed the basis for subroutines. In the context of object technology, we talk of encapsulation with reference to controlling data access inside an object from outside.

This example will help in relating this to our daily lives. When we switch a lamp on, it turns on. We are not bothered if it needs 200 volts or more, if the current is enough or if the electrons are flowing or not. The lamp gives us a single interface to work with, which is the switch. We always interact with the switch. What happens inside as a result does not bother us. We cannot change the lamp's state without the switch. For instance, we cannot change the current inside and light the bulb by other means (except if the electrician tampers with the circuit) without switching the switch on. Switch is the only interface with us. Similarly, a microwave oven or a washing machine has its own interface, only through which can it be manipulated. As an important aside, opening the microwave oven door or turning the washing machine on does not switch on our lamp. Thus, an action on one object does not cause any change to another object, except through structured messaging, as we will learn later. Every object responds only to its own interface and nothing else.

Encapsulation is a very powerful tool in object-oriented technology. Once an object is ready, all one needs to know is its methods or interfaces. How they are implemented internally (i.e. the program code of the methods) is not of any interest. An object is expected to perform a specific, pre-defined task without worrying about any side effects. To ask an object to do a specific pre-defined task, its methods are called. Suppose there are two methods in an employee object for creating a new employee record and updating some of the fields. This can be as shown in Fig. 10.19.

Fig. 10.19 Encapsulation

As the figure shows, an employee object gives the view of a black box. It tells the outside world that its interface is made up of two methods: create and update. How they work internally is not known. In fact, hardly anything else is known about the employee object apart from these two method names. To update the address of an employee, for example, the update method must be called and the new address should be passed to that method. That is the whole idea. Other objects need not know anything about the internal structure of the employee object such that the internal structure of the employee object can be changed without affecting other objects.

This concept is shown in Fig. 10.20 with another example. Here, an account-holder object sends a message transfer to an ATM object to transfer funds from itself to another account. The account-holder object does not know the ATM object works internally. However, the ATM object performs the funds transfer successfully and returns an acknowledgement in the form of a receipt to the account-holder object. This is precisely what the account-holder object expects, anyway!

Fig. 10.20 Encapsulation enables simple message passing between objects

Thus, the main idea of encapsulation is hiding of internal details of an object. This means that the changes to the internal details of one object do not cause many rippling changes to other objects in the system. These changes to an object could be due to different reasons, such as change in requirements, bug fixing, performance improvement, as on.

By using the idea of encapsulation, objects become self-sufficient and fairly independent of each other. One object need not depend on, or interfere with, other objects in the system. At the same time, because each object knows how it can interact with any other object (by calling its methods), this does not impose any limitations on the interaction between objects.

An intuitive way of depicting encapsulation is shown in Fig. 10.21. Here, we show an object that has certain attributes, and it possesses certain methods. The attributes portion is completely hidden from the outside world. This is indicated with the help of a question mark (which is what the outside world sees). However, the object has a border consisting of interfaces, which allow other objects to interact with it, by sending messages.

Fig. 10.21 Another way of depicting abstraction

We can describe the main advantages of restricting access to the data elements of an object from other objects, as follows:

Object technology specifies many features that are expected to make software engineering and development better. Examples of these features are abstraction (focus on what needs to be done, not how to do it), inheritance (create hierarchies of objects so as to make data and code sharing effective), polymorphism (allow the same method to perform different tasks, depending on the context), and so on.

  1. This information hiding facilitates local decision-making. Design changes inside an object do not affect other objects in any manner. Thus, the designers of an object are free to make changes to the object in any manner, as long as they do not change the external interface of the object to the outside world.
  2. This facilitates decoupling of the internal representation details of an object from the way others see it. This also means that others cannot make any alterations to an object.

10.4 INHERITANCE

Inheritance is the process by which one object acquires the properties of one or more other objects.

It involves sharing of attributes and operations or methods among classes based on a hierarchical relationship. Note that this is different from association or aggregation.

A class can be created at a broad level and then refined progressively into finer subclasses. Each subclass incorporates, or inherits all the properties of its super class to which it can add its own properties. It is interesting to notice that deriving the common attributes of more than one object creates a class. Inheritance extends this basic concept so that the classes themselves can be generalised. This means, a super class now shares common attributes among different classes. This is a very interesting and important idea.

To take a simple example, vehicle can be defined as a class at a broad level—it would be the super class. Cars, scooters and mopeds are all different kinds of vehicle. Suppose the super class vehicle has an attribute called tires; the attribute value indicates the number of tires for a vehicle. Thus, while the attribute would be common to all vehicles, the value of the attribute would differ. For example for a car the value would be 4; for a scooter, it would be 2, and so on. Therefore, rather than defining the attributes in each type of vehicle, it can be defined at the top of the hierarchy, that is in the vehicle class.

The vehicle class is the super class. The different vehicle types are the subclasses. Each vehicle type (subclass) automatically inherits all the properties – such as tires – of the vehicle class (super class). Wherever they differ, the differences would be added in the subclass. For instance, tires of a car would be different from the tires of a scooter. However, from the viewpoint of the super class vehicle, all tires are the same. It is then up to the subclass to point out the differences (by defining additional attributes). The super class would provide only the basic minimum features. Take another example of the attribute horn. The horn of a scooter would produce a different sound from that of a car. However, the super class vehicle would provide only a basic sound attribute. It is then up to the subclass to add more attributes such as beep and blow. The basic idea is as shown in Fig. 10.22.

Inheritance is not limited to a single level. For instance, we can see that mopeds and scooters are two-wheelers; whereas cars are four-wheelers. Therefore, we can group (or generalise) scooters and mopeds into another class called two-wheeler. The cars can go into another class called four-wheeler. If we are sure that we will not add trucks, jeeps or anything else to the family of four-wheelers, we can keep car as a directly subclass of the vehicle super class, similar to the one shown earlier. However, if we do add further categories to the sub classes four-wheeler and two-wheeler, our new inheritance relationship would look as shown in Fig. 10.23.

Fig. 10.22 Inheritance concept

Fig. 10.23 Inheritance extended to another level

As the figure shows, inheritance can be extended to more than one level. Why does one need to extend inheritance to more than one level anyway? The reason for adding another level of inheritance is to combine classes into still finer groups. Thus, classes are not only grouped, but they are also specialised. For example, cars and small trucks are not particular cases of vehicles: they are particular cases of four-wheelers.

This kind of extention gives software designers and developers a better level of control. Thus, only the very basic and common features would be kept in the vehicle class. It would be fine-tuned to have features of only four-wheelers in the four-wheeler class. Similarly the two-wheeler class would contain features of only two wheelers. Obviously, apart from inheriting properties from its super class, a class can have its own additional properties. A class can pass on both the inherited and the new properties to its subclass. Clearly, this is very useful when writing software as it reduced the chances of duplication of efforts. Once the super class is created, the subclasses can inherit all its attributes and methods automatically, so there is no need to write them once again. As discussed, this can be extended any desired level.

Also, any other application that needs to deal with vehicle information can simply use the vehicle class and inherit its own subclasses from this generic class. Therefore, we do not need to write separate programs for this. That is, we can reuse the programs written for vehicle super class. This feature is called code reusability.

Inheritance is a logical extension of the concept of abstraction. Actually, the concept of inheritance was present even in the days of procedural programming. This was achieved by writing common procedures, which could be reused by other programs/procedures. However, inheritance takes this idea a step ahead. Now, the relationships between classes can be defined, which allows for not only code reuse but also better design, by factoring in commonalities of the various classes. The designer's job here is to start thinking about such commonalities, and look for them in the classes that are being designed. For instance, an application could have student and teacher as two classes. Obviously, they may share some basic attributes, such as name, date of birth, sex, and others. These and other such common attributes can be abstracted to form a super class called person. Student and teacher could become the subclasses of this super class, thus inheriting the properties of the person super class. Since the super class forms the foundation or base of sharing, it is also called base class.

Of course, the similarities between a student and a teacher end at some point. That is when the idea of generalisation no longer continues to be true and specialisation begins. Once we are through with all the possible commonalities between a student and a teacher, we should carve out a person class, and include all these common features in this class. At the next stage, we need to think of the differences between the two – that is the specialties of the student, as well as the teacher. For instance, a student would have attributes such as total marks obtained, and ranking among her peers. These are not at all relevant to a teacher who will have some completely unrelated specialties, such as the subject that she teaches. These special attributes of the student and the teacher would go into their respective subclasses. The ideas of generalisation and specialisation are shown in Fig. 10.24. As we can see, generalisation starts from the bottom, and goes to the top. On the other hand, specialisation starts at the top, and moves down to the bottom.

Technically, arrows originating from the subclasses towards the super class show the inheritance relationship. The arrows indicate that the subclass inherits from the super class. If class A is the super class and class B is the subclass, this relationship can be shown as depicted in Fig.10.25.

Object technology specifies many features that are expected to make software engineering and development better. Examples of these features are abstraction (focus on what needs to be done, not how to do it), inheritance (create hierarchies of objects so as to make data and code sharing effective), polymorphism (allow the same method to perform different tasks, depending on the context), and so on.

Fig. 10.24 Generalisation and specialisation

Fig. 10.25 Inheritance relationship

Just as aggregation can be found out by looking for has a relationship, inheritance can be found out by looking for is a relationship. For instance, when we say that student and person are subclass and super class respectively, we actually mean that student is a person. Since a student is a person, it already knows what it means to be a person! Therefore, it needs to highlight only the specialties of a student, which are missing in a person. Thus, in general, a sub class needs to point out only the differences as compared to its super class. A subclass can do all that its super class can, and more!

Other terms for a super class are: parent class or ancestor. Similarly, other names for a subclass are: child class or descendent.

10.5 OBJECT TECHNOLOGY AND RDBMS

10.5.1 Identifying a Record Uniquely

We have noted that the basis for identifying a RDBMS record uniquely in a table is the primary key associated with that record. In object technology, an object has an implicit object ID, which helps the underlying technology to identify that record. These two concepts gel with each other in the sense that both RDBMS and object technologies believe that records and objects have existence beyond their properties. Of course, the major difference between the two is that while the primary key is explicit (i.e. visible to the entire world), the object ID is implicit (i.e. hidden from the external world). This idea is illustrated in Fig. 10.26.

Fig. 10.26 Concept of primary key and object ID

It may seem straightforward to map the concept of primary keys to objects. That is, it may seem that just as a table has a primary key column, a class should have an attribute equivalent to that column. Therefore, a student class would perhaps have student_ID, a salesperson class would have salesperson_ID, and so on. However, there is a lot of debate regarding the usage of such identifiers in objects. Of the many reasons that are quoted, the following are the key ones:

  • The main objection to the idea of identifiers comes from the fact that object technology is perceived as an extension of our natural thinking. People consider objects as computer-representation of real-world objects. Therefore, questions are often raised as to why we should have explicit identifiers identifying computer-based objects uniquely, when we do not have any such scheme in the real world!
  • Another objection to the idea of special identifiers comes from technologists who believe that the very notion of adding identifiers to objects means that the analyst/designer has already started thinking about how the objects would get stored on the disk (i.e. implementation), rather than what they should do. This could pose the danger of the analyst/designer losing focus.

It may surprise us to read this, given the fact that both RDBMS and object technology actually use identifiers in some way. But as we have noted, RDBMS requires the presence of an identifier in the actual record. On the other hand, object technology associates the identifier with an object internally, and resists having the identifier as an explicit attribute of the object. This should clarify the point that although the basic motive in both the cases is the same, the envisaged usage is quite different.

Regardless of the objections, it is usually seen that we need to add IDs to objects. There is no other way we can easily map them to RDBMS table structures.

10.5.2 Mapping Classes to Tables

If we need to store classes (actually, objects) on a disk, there must be some way of mapping them to RDBMS structures. Because, objects are otherwise in-memory constructs, they do not have life beyond the execution cycle of a program. The moment a program is removed from the main memory of the computer, all the objects associated with that program also die. When we think of mapping objects to tables, three possibilities emerge:

  • One object maps to exactly one table
  • One object maps to more than one table
  • More than one objects map to one table

These possibilities are depicted in Fig. 10.27.

Fig. 10.27 Different possibilities in object-to-table mapping

The objects corresponding to a class can be partitioned horizontally and/or vertically.

n Horizontal partioning: If a few instances (i.e. objects) of a class are referenced to more frequently than others, it may be a good idea to place the frequently-accessed instances in one physical table. The ones not frequently accessed can be put in another table. It is imperative that the application using these tables should know which table contains the frequently-accessed data, of it would not benefit from such a partitioning scheme. An example of horizontal partitioning is shown in Table 10.1.

Table 10.1 Horizontal partitioning

Student ID Student Name Marks
01 Atul 62
02 Ana 70
03 Jui 82
04 Harsh 89

(a) Original table

Student ID Student Name Marks
01 Atul 62
02 Ana 70

(b) Horizontal partition number 1

Student ID Student Name Marks
03 Jui 82
04 Harsh 89

(c) Horizontal partition number 2

  • Vertical partioning: There are after situations when some attributes of a class are more frequently accessed than others. That is, the class may have varying access patterns. In such cases, the table corresponding to the class can be partitioned vertically. The frequently accessed attributes can be placed in one table and the other attributes can be placed in another (with appropriate record identifiers). An example is shown in Table 10.2.

Let us now consider an example of mapping a simple class to a table. Let us assume that we have a Student class, containing two attributes: student name, and marks. This is the view of our object model. When we want to map this to an appropriate table, there are two main steps: (a) Outline the corresponding table model for this class, and (b) Write the SQL code corresponding to the table model.

While transforming the object model to the table model, we add a record identifier (student ID). Moreover, we also provide greater details about the table model. For instance, we specify that the student ID must be unique and must not be null, which makes it our ideal primary key. We also mention that the student name must have some value – it cannot be null. However, because two or more students can have the same name, this cannot be a primary key but a secondary one. This would mean that we would create an index on the student name (in addition to the default index on the student ID), thus facilitating a quicker search based on the student name. Marks is a simple attribute without any regards to the key.

Table 10.2 Vertical partition

Student ID Student Name Marks
01 Atul 62
02 Ana 70
03 Jui 82
04 Harsh 89

(a) Original table

Student ID Student Name
01 Atul
02 Ana
03 Jui
04 Harsh

(b) Vertical partition number 2

Student ID Marks
01 62
02 70
03 82
04 89

(c) Vertical partition number 3

The entire process is depicted in Fig. 10.28.

Fig. 10.28 Mapping a class to a table

Mapping classes to tables is usually quite simpleforward. The challenges in mapping begin to surface when we start thinking about mapping associations (i.e. relationships between two or more different classes) to tables. Associations may or may not map to tables, depending on the designer's view, and the problem domain. In general, associations can be binary (which means that values from two classes are derived), ternary (which means that values from three classes are derived), and so on. We will discuss binary associations now.

10.5.3 Mapping Binary Associations to Tables

Binary associations can be largely classified into two types: (a) Many-to-many associations, and (b) One-to-many associations. Simple examples of these are: many students choosing many subjects for their courses, and thus obtaining some marks in each one (many-to-many); and a school enrolling many students per standard (one-to-many). Depending on the type, we can decide how to map these constructs to tables.

  • Many-to-many associations

    Many-to-many associations always map to a distinct table. In other words, if we have a class X, another class Y, and their many-to-many association as XY, then we always end up with three tables: one for X, one for Y, and one for XY.

    Let us consider an example. Suppose we have two classes: Student (containing attributes Student name and Address) and Subject (containing Subject name and Details). Many students can choose many subjects. That is, given a student name, we can have multiple subjects chosen by the student; and given a subject name, we can have multiple students choosing that subject. Then we are posed with a problem of not only modelling the student class and the subject class, but also of relating the students with the subjects. Quite clearly, student and subject details would go into their own respective tables. Additionally, we would derive a third table, called Result, which would capture the relationship (i.e. many-to-many association) between the students and the subjects, along with the marks obtained.

Fig. 10.29 illustrates the modelling process for this situation. We will discuss details of this profess after taking a look at the figure.

We have not shown the details of the student and subject classes, which should be easy to understand. In order to depict the association between these two classes, we have created a third table, called Result. This table links the student (based on her ID) with the subject (based on the subject ID), using the marks obtained. As before, we assume that the student ID and subject ID are derived unique identifiers, which are not a part of the basic student and subject classes.

We have mentioned that the primary key of the Result table is a combination of the student ID and the subject ID. This is quite logical. After all, the Results table can have multiple records for a student, as well as for a subject. Therefore, the only way to identify a record uniquely is based on a combination of the student ID and the subject ID. This is also the reason why the student ID and subject ID fields cannot have any null values. However, we have allowed the Marks column to allow null values, because it is possible that the examination results are not yet announced.

Fig. 10.29 Mapping many-to-many association to tables

We have also declared the student ID and the subject ID as foreign keys. This means that they refer to some other tables, where they are primary keys. Of course, these tables are the Student table and the Subject table, respectively.

For enabling fast searches (e.g. find all subjects chosen by a student, find which students have chosen a particular subject), we have created two secondary indexes: one on the student ID, and another on the subject ID.

  • One-to-many associations

    To illustrate one-to-many associations, we take the example of a school enrolling many students per standard. A student may or may not actually enroll in any school at all, and yet we may want to maintain information about that student. Also, there can be many schools, in which the students are seeking admission, and we want to store information about all of them. Do not get confused that this causes the relationship to become many-to-many. It is still one-to-many, because for a given school there can be many students, but given a student, there can be only one school. Thus, we know that there must be two tables to start with: Student and School. How do we model their relationship? There are two possibilities:

(a) Creating a distinct association table: Similar to the way in which we had earlier modelled the many-to-many association relationship, we can create a third table called as Enrollment. This table will contain the School ID, Student ID, and the standard. We can make the student ID the primary key of this table, since it would always be a unique value. If we examine this carefully, we will note the following advantages:

(i) We are creating a separate table to store the association relationship. Thus, we are not mixing different objects into a single table. This is in line with the encapsulation principle of object technology.

Fig. 10.30 Mapping one-to-many association to tables – Distinct association table

(ii) This design is symmetrical, because we are not complicating any existing objects with additional attributes. Instead, we are creating a third table.

This design also has the following drawbacks:

(i)  It leads to one more table than the basic design needs.

(ii) The performance may be slow, since we would need to navigate more tables.

Let us depict this pattern as shown in Fig. 10.30.

Note that we have used a hollow circle at the end of the school class, and a filled circle at the end of the student class. This indicates the one-to-many relationship between a school and its students.

(b) Hidden foreign key: In this approach, we do not create a third table to store the association relationship between a school and its students. Instead, we alter the design of the original Student table to include information about which school she studies in. The student table would thus also have School-ID as one of its columns. This column is a foreign key, which refers to the School table. There would be no change in the School table. The design is shown in Fig. 10.31.

Fig. 10.31 Mapping one-to-many association to tables – Hidden foreign key

The advantages of this approach are apparent. Because of fewer tables, this would work faster. But it also suffers from the drawbacks of being asymmetrical in nature. For instance, even when a student is not enrolled into any school, that student record will still have the column of school ID (although it would be empty). Thus, in this table, we are contaminating the student object with additional information, which can actually be kept in a third, separate table.

As we can see, both the approaches have their own pros and cons. Depending on the needs of the application, the better approach would generally be adopted for each specific use.

10.5.4 Modelling Generalisations to Tables

How do we map generalisation relationships to tables? That is, how do we depict the inheritance relationships between classes in the form of table relationships? To understand this, we will use the generalisation relationship as shown in Fig. 10.32.

Fig. 10.32 Generalisation example

There are four possible approaches that can be used for this kind of modelling. Let us discuss them one by one.

  1. Super class and subclass tables

    This is the simplest of all approaches. Here, we map the super class (i.e. Employee) to a table, and the two subclasses (i.e. Manager and Clerk) to two their respective tables. Thus, we have three tables in this design. The identity of an object is maintained throughout the design with the help of a unique employee ID. For instance, an employee, Ana, may occupy a row in the Employee table with 100 as employee ID, and a row in the Manager table, with the same employee ID (i.e. 100). The idea is depicted in Fig. 10.33.

Fig. 10.33 Modelling generalisations – Super class and subclass tables

We will note that this is a very simple and straightforward approach. It is also extensible. For example, if we have more attributes in any of the classes, it would be trivial to add the corresponding columns to the respective tables. On the drawbacks side, this approach involves many tables, and the access from the super class to the subclass can be time-consuming. Consider that we need to find out all the information regarding an employee. The steps for this retrieval process would be as shown in Fig. 10.34.

Fig. 10.34 Obtaining a subclass record

For example, suppose the user wants all the information regarding an employee named as Ana. The application obtains the employee ID (say 100) and grade (say Manager) of Ana from the Employee table. Since Ana is a manager, the application now looks up the Manager table, and tries to find a match for a row containing the employee ID 100. When it finds one, it retrieves the values of the bonus and the number of subordinates for Ana.

As we can see, this makes the retrieval quite slow. Another problem with this model is actually not noticeable at this juncture. To bring that problem to surface, let us write the SQL code corresponding to our design, as shown in Fig.10.35.

Fig. 10.35 SQL code for super class and subclass tables

The subclass tables include employee ID, and by using the concept of foreign keys, they associate themselves with the super class table. This is perfectly all right. But the problem with this scheme is that there is no direct way for us to prevent the existence of the same employee in both the subclasses. That is, we cannot prevent an employee from becoming a manager as well as a clerk! For instance, we can have an employee, with ID 100, in the Employee table, in the Manager as well as the Clerk tables. We can only stop the application from having more than one employee/manager/clerk within the same table (i.e. as a duplicate entry). Nonetheless, we cannot prevent its occurrence across the subclass tables. We must make appropriate checks for this via additional program code.

2. Many subclass tables

In this approach, we do not have a table corresponding to the super class. Instead, we have one table per subclass. Obviously, in such a design, we must replicate the information that would have been in the super class table into all the subclass tables. The fact that there is no super class table means that we cannot depend on any outside table, when we need to obtain information from a subclass table. All subclass tables must be self-sufficient.

Fig. 10.36 shows the table design for the case where we have no super class table, but only the subclass tables.

Fig. 10.36 Modelling generalisations – Many subclass tables

Because there is no super class table here, the navigation steps are reduced by one. This also means that a search operation on the subclass table would be faster than it was earlier.

Since we replicate all the super class attributes in the subclass tables, this approach can be used in situations where the super class attributes are small in number, and the subclass attributes are quite high.

Although this approach satisfies the third normal form, the main problem with this approach can be described as follows.

An employee can be a manager as well as a clerk. This is because although the employee ID would be unique within a table (i.e. in the Manager table or in the Clerk table), it may not be unique across both the tables. RDBMS technology does not provide any in-built mechanisms to thwart this problem.

3. One super class table

In this approach, rather than eliminating the super class, we do away with the subclasses. At the same time, we retain the super class. This means that there is only one table in the design now: the super class table. There is no other table.

As we have only the super class, this super class must model all the attributes of the subclasses as well. In other words, we must replicate all the subclass attributes within the super class, and add one column each to the super class table.

Fig. 10.37 illustrates the design of this approach.

Fig. 10.37 Modelling generalisations – One super class table

What are the characteristics of this model? All the subclasses are tied together. If we have 10 managers and 50 clerks in the organisation, then this model would have 60 records in the employee table. This is because one record will store information about one subclass type (i.e. either manager or clerk). In the case of the manager records, the column Number of pending tasks would contain nulls. Similarly, in the case of clerk records, the columns Bonus and Number of subordinates would contain nulls.

Notably, this table also violates the third normal form. This is because although employee ID is the primary key of the table, the values of the subclass columns such as bonus, number of subordinates and number of pending tasks depend on the value of the grade attribute, which is not a primary key of the table.

In spite of its disadvantages, this approach can be considered when the number of subclasses and their attributes are small.

10.6 Object Oriented Database Management Systems (OODBMS)

10.6.1 Basic Concepts

Although RDBMS is the preferred choice of the computing industry worldwide, a recent development has taken place in the area of the Object Oriented Database Management Systems technology. An OODBMS provides a persistent (i.e. permanent) storage for objects. By persistent or permanent storage, we mean storage beyond the life of a program.

OODBMS is generally used in a multi-user client/server environment. It controls the concurrent access to objects, provides locking mechanisms and transactional features, offers security features at the object level and also ensures object backup and restoration.

The biggest difference between a RDBMS and an OODBMS is that whereas the former stores the data related to an object in a table, the latter stores the state of an object. Each object in an OODBMS has a unique Object Identifier (OID), which is used to identify and link it with other objects when needed (e.g. in referential integrity relationships). An OODBMS supports encapsulation and inheritance.

We know that SQL is used in conjunction with RDBMS. OODBMS generally uses class definitions and traditional OOP languages, such as C++ and Java, to define, manipulate and retrieve data. That is, an OODBMS is an extension (on the disk) of the in-memory data structures such as objects. An OODBMS integrates database-handling operations directly into the base OOP language. The idea is shown in Fig. 10.38.

This architecture may raise a doubt. We know that SQL is language-neutral. That is, we can type SQL commands simply on a command prompt, or we can also use SQL inside programming languages such as C++, Java, COBOL, and others with the same basic syntax.

From what we have discussed about OODBMS, it appears that a programmer must be familiar with OODBMS with C++ or OODBMS with Java syntaxes, etc. In other words, are we saying that the syntax for using OODBMS in C++ is different from using OODBMS in Java? Does it mean that we must relearn OODBMS syntax the moment we change from one OOP language to another?

This was indeed the case! Thankfully, however, to address this problem, an Object Database Management Group (ODMG) was set up. This group has come up with a specification for using OODBMS in a certain way. This specification has three main aspects, as shown in Fig. 10.39.

Object Oriented Database Management Systems (OODBMS) have not become as successful as it was initially thought. Apart from many other reasons, one striking factor behind this is that it is not easy to program for OODBMS systems. Once someone gets used to writing SQL queries, which are almost English-like, it is difficult to comprehend as to why one needs to learn and remember such cryptic syntaxes as used in most OO languages and OODBMS as well. The most practical way ahead seems to be the marriage of object or traditional programs with RDBMS for data storage and retrieval.

Fig. 10.38 OODBMS concept

Fig. 10.39 Aspects of OODBMS as per ODMG specifications

Let us discuss these in brief.

  • Object Definition Language (ODL) is similar in concept to the Data Definition Language (DDL) of SQL.
  • Object Query Language (OQL) is similar in concept to the Data Manipulation Language (DML) of SQL. It provides support for most common SQL SELECT statement forms, including joins. However, it does not provide support for SQL INSERT, UPDATE or DELETE.
  • Object Manipulation Language (OML) is an extension of OQL. Whereas OQL is a generic standard that can be used across OOP languages (just as SQL syntax is the same no matter from which programming language you access it), OML is language-specific. Thus, OQL would always be the same for Java, C++ and C#, but OML would be different for these languages. OML includes support for SQL INSERT, UPDATE and DELETE statements.

Overall, the execution of a program using these features goes via the steps shown in Fig. 10.40. As we can see, the data definitions go via the ODL route, whereas the data manipulations go through OQL and OML.

Fig. 10.40 Steps in development of program using OODBMS

We shall later discuss some simple examples of ODL, OQL and OML.

10.6.2 When Should OODBMS be Used?

Traditional business applications require data to be stored in the form of rows and columns. For example, a payroll application would need employee details to be stored in one table, the payment details in another, and so on, all in a tabular form. This makes the conceptual understanding as well as the retrieval of the data quite easy. However, for applications that deal with complicated data types, this style may not be suitable. This is because, in these applications, it is not wise to split the data into rows and columns, and instead, the data must be stored in its original form. In other words, an object should be stored as an object, and not as a group of rows and columns. Fig. 10.41 illustrates the idea.

Fig. 10.41 RDBMS versus OODBMS storage concept

What are these applications? Typically, these applications consist of Computer Aided Design (CAD) drawings, Computer Aided Machines (CAM), Computer Aided Software Engineering (CASE) tools, and so on. Therefore, we can say that all engineering, scientific and construction activities, among others, fall within this category.

10.6.3 Advantages of OODBMS

Let us summarise the advantages offered by OODBMS, especially in contrast to the features of RDBMS.

  1. Quicker access to information: An OODBMS keeps track of objects via their unique object IDs. This means that a search operation moves from one object to another via these IDs, and not through complex foreign key traversals. As a result, the search operations in OODBMS are generally faster than those in RDBMS. Fig. 10.42 shows the idea.

    Fig. 10.42 Quick access to information

  2. Creating new data types: An OODBMS does not restrict the type of data that can be stored. Any complex data type can be created and stored on the disk by declaring an appropriate object description. In contrast, RDBMS provides a fixed number of data types, such as integers and strings. If we have to store complex data into RDBMS, we need to first flatten it into rows and columns. Fig. 10.43 illustrates the point.

    Fig. 10.43 Storing complex data

  3. Integration with OOP languages: As we have mentioned, OODBMS is actually an extension of OOP languages, such as Java and C++. As such, they represent the in-memory data structures on the disk. This means that there is no impedance mismatch between the language and the DBMS. What do we mean by this? Contrast this approach with the traditional approach of accessing an RDBMS table in a language such as C. In this case, we would typically execute a SELECT query via the C program, which may return multiple rows. The C program stores them in a buffer (i.e. main memory), and processes them one-by-one. Therefore, the view of the C program is one row at a time, whereas that of the RDBMS is multiple rows at one shot. This difference is called impedance mismatch. As opposed to this, an OODBMS deals with one object at a time, just as an OOP language would do. Moreover, OODBMS preserves the original characteristics of an object, because it stores it as is. Fig. 10.44 depicts this in a nutshell.

    Fig. 10.44 Integration with OOP languages

10.6.4 Examples of ODL, OQL and OML

Having discussed the theory behind OODBMS, let us move on to the syntax of ODL, OQL and OML. Since we do not intend to teach these languages here, the focus would be to simply give an overview. More specifically, we shall make an attempt to grasp the broad-level syntaxes, and not worry about the precise rules of these languages.

Declaring classes using ODL

The declaration of a class in ODL involves three main aspects:

  • The keyword interface
  • The name of the class
  • A list of attributes of the class

The keyword interface in ODL means class. That is, just as we declare a class in Java, C++ or C#, by using the keyword class, we need to use the keyword interface in the case of OODBMS.

An example of a class declaration in ODL is shown in Fig. 10.45. We can see that this declaration is quite similar to a class declaration in an OOP language.

Fig. 10.45 Declaration of a class in ODL

Declaring class relationships using ODL

We know that SQL uses the concept of foreign key declarations to establish relationships between tables. In a similar fashion, ODL uses the keyword relationship for this purpose. Suppose we have two classes–A and B. Furthermore, let us imagine that while declaring class A, we want to establish a relationship with class B. Then, in class A, we should add the following line:

relationship B rel-a-b;

The keyword relationship links class A with class B. The last portion ‘rel-a-b’ is simply a name given to this relationship. It can be any other suitable name, as the user finds appropriate. Let us now link our earlier employee class with the department class using this syntax, as shown in Fig.10.46. For this purpose, we have to change the declaration of the employee class. Obviously, we will need to have a department class for this purpose, which is not shown here.

Fig. 10.46 Declaration of a relationship in ODL

Declaring keys using ODL

In ODL, an attribute is declared to be a key attribute by using the keyword key. The key declaration must be made before the internal description of a class begins. That is, the keyword key must follow the class declaration. An example of this is shown in Fig. 10.47.

Fig. 10.47Declaration of a key in ODL

If more than one attribute make up the key, then we should list all these attributes inside a parenthesis after the keyword key, as shown in Fig. 10.48.

What we are saying here is that no employee can have the same ID and the same department ID. That is, the combination of the employee ID and the department ID must be unique, although on their own they may be duplicated. If two employees have the same employee ID, their department ID must differ. Conversely, if their department ID is the same, then their employee ID must be different. Some of the allowed and disallowed values are shown in Fig.10.49. Note that in part (b) of the figure, we have the employee record A occurring twice within department A, and employee record 300 occurring twice in department D. Both of these cases are disallowed, since within a department, the same employee must not be duplicated. However, in case (a), there is no problem since the combination of employee ID and department ID is always unique.

Fig. 10.48 Declaration of a key with multiple attributes in ODL

Fig. 10.49 Examples of keys values: What is allowed, what is not?

Interestingly, the declaration of key in Fig. 10.50 is different from the one shown earlier, and it also has a different meaning.

Fig. 10.50 Declaration of multiple keys in ODL

Note that we have now removed the bracket surrounding the attributes of the key. This changes the meaning dramatically. The employee ID and the department ID must be independently different. Both attributes are keys by themselves. Now, every employee ID and department ID must be unique on their own. Thus, we no longer need only the combination of the employee ID and the department ID to be unique, but we also need the uniqueness of the two attributes. Thus, now what is allowed and what is not, is shown in Fig.10.51.

Fig. 10.51 Examples of keys values: What is allowed, what is not

Case (a) is straightforward, as we have unique values in the employee ID and the department ID columns. However, case (b), violates the key declaration in two ways:

  • Employee IDs 200 and 300 repeat
  • Department IDs A and D repeat

Moreover, as a side-effect, the combination of employee ID and department ID 300-D also repeats.

Reading data using OQL

We have mentioned that the Object Query Language (OQL) provides syntax and features similar to that of the SQL SELECT statement. Let us consider a simple example to understand this, as shown in Fig. 10.52.

Fig. 10.52 OQL query example

All the other major SQL features are also available in OQL, but we shall not discuss them here.

Abstraction

Base class

Code reusability

Generalisation

Impedance mismatch

Inheritance

Attribute

Class

Encapsulation

Horizontal partitioning

Information hiding

Many-to-many association

Message

Modelling

Object Database Management Group (ODMG)

Object ID

Object orientation

Object Query Language (OQL)

One-to-many association

Semantic gap

Super class

Method

Object

Object Definition Language (ODL)

Object Manipulation Language (OML)

Object Oriented Database Management System (OODBMS)

Object technology

Relationship

Subclass

Vertical partitioning

  • Object technology is based on the concept of objects. An object is a self-contained representation of real-life objects.
  • An object contains data (attributes) as well as the functions that operate on them (methods).
  • Class is a template for similar kinds of objects. For example, Person can be a class, and Atul, Ana, Jui, and Harsh can be the objects of this class.
  • Objects interact with each other by passing messages in an Object Oriented (OO) system.
  • Object technology has emerged as a very popular method of analysis, design and systems development.
  • Abstraction is a concept that allows the analyst/designer to focus on key aspects of a system. It frees the user from unnecessary details.
  • By using encapsulation, attributes of a class can be protected. These are accessible only to the methods of that class. Thus, the outside world cannot access the attributes of the class.
  • Encapsulation also ensures that the attributes and methods of a class stay close to each other, in a tight environment.
  • The concept of inheritance helps create hierarchy of classes. For example, if Person is the class at the top (i.e. parent class), then Man and Woman can be the two classes at one level below (i.e. child classes).
  • The parent class in an inheritance relationship is called as the super class. The child class is the subclass. The inheritance relationship can span many levels.
  • There are several challenges in marrying object technology with RDBMS.
  • We identify a record in RDBMS uniquely based on its primary key. In the case of an object, the object identifier identifies a unique object.
  • There are several ways to model classes so that their data can be stored in RDBMS.
  • Objects can be fragmented vertically or horizontally before they are stored in RDBMS tables.
  • One object can map to one table, one object can be split into multiple tables, or multiple objects can be combined to form one table. The decision depends on the nature of the application.
  • Care needs to be taken while mapping generalisation and binary relationships in objects to RDBMS tables.
  • The Object Oriented Database Management Systems (OODBMS) allow objects to be stored as objects, and not as RDBMS tables.
  • In OODBMS, there are three main aspects, similar to the DDL and DML portions of SQL.
  • The Object Definition Language (ODL) is similar in concept to Data Definition Language (DDL) of SQL.
  • The Object Query Language (OQL) is similar in concept to Data Manipulation Language (DML) of SQL.
  • The Object Manipulation Language (OML) is an extension to OQL. Whereas OQL is a generic standard that can be used across OOP languages (just as SQL syntax is the same no matter from which programming language you access it), OML is language-specific.
  • The choice of RDBMS versus OODBMS depends on the nature of the application being developed.

  1. Object and class mean the same thing.
  2. Java is a non-OO language.
  3. A method in object technology is similar to a function in traditional technologies.
  4. In abstraction, we think about the minute details of an object.
  5. Inheritance leads to specialisation relationships.
  6. OODBMS uses the concept of tables.
  7. A unique object ID identifies every object.
  8. OQL is similar to the DML portion of SQL.
  9. ODL is similar to the DDL portion of SQL.
  10. There is no direct equivalent to DCL in OO technology.

1.  Attributes and methods make up _______.

(a) an object

(b) a template

(c) a program

(d) a function

2.  The generic template for objects is called a ________.

(a) method

(b) message

(c) program

(d) class

3.  The parent class in an inheritance relationship is called as ______.

(a) subclass

(b) super class

(c) main class

(d) father class

4.  An example of an OOP language is _____.

(a) C

(b) COBOL

(c) C++

(d) Pascal

5.  In ______, we protect the attributes of a class.

(a) abstraction

(b) polymorphism

(c) encapsulation

(d) inheritance

6.  To model _______, we need to create tables for super class and subclass.

(a) abstraction

(b) polymorphism

(c) classes

(d) generalisation

7.  In order to store objects in RDBMS, we need to transform them into ________.

(a) classes

(b) tables

(c) files

(d) segments

8.   _____ is similar to DML.

(a) OML

(b) OCL

(c) ODL

(d) OQL

9. The difference between a programming language and the way it accesses data is called _________.

(a) impedance mismatch

(b) hierarchy difference

(c) impedance difference

(d) level mismatch

10.  In OODBMS, objects are stored as _______.

(a) tables

(b) objects

(c) files

(d) relations

  1. Discuss the term object technology.
  2. What is an object? How is it different from a class?
  3. What are attributes and methods?
  4. Explain the idea of abstraction.
  5. What is inheritance?
  6. Describe the meaning of the term encapsulation.
  7. What are the various ways in which we can model an object as a table in RDBMS?
  8. What is an OODBMS?
  9. When should we use OODBMS?
  10. Discuss the advantages of OODBMS.

  1. Learn more about an OOP language, such as Java or C++.
  2. Investigate the precise differences between traditional analysis/design techniques and object technology.
  3. What are the various ways of accessing RDBMS from an OOP language? (Hint: Learn more about ODBC, JDBC).
  4. Given an object that needs to be stored in an RDBMS, which main characteristics would you look for?
  5. How would you test a program written in OOP language that accesses RDBMS? (Hint: Look for aspects such as how to map classes to tables, how to represent primary/foreign key relationships, how to take care of referential integrity, etc).
  6. Study more about an OODBMS product, such as ObjectStore or Jasmine.
  7. Why do you think OODBMS has not caught up as much as it was expected to?
  8. Is a hierarchical DBMS same as an OODBMS? Why?
  9. What is RUP? (Hint: It stands for Rational Unified Process).
  10. Find out more about three persons: Booch, Rambaugh and Jacobson and their contributions to object technology. (Hint: They are the pioneers of the Object Oriented Analysis and Design methodologies).