Data Management - Part IV (Data Model)

Data Model

Every database and indeed every DBMS, must adhere to the principles of some data model. However the term data model is somewhat ambiguous. Here we consider a number of alternative data models. They are:

• Hierarchical model
• Network model
• Relational model

The first two data models fall under the term navigational, since they require the use of pointer technology in order for the user to navigate the database. Although these models were extremely popular in there time they have several drawbacks - mainly that making changes to the inherent structure of the database difficult.

Hierarchical Model

The hierarchical model depends on every entity being subject to a higher one. A single example is where parent can be immediately identified from the child and vice versa. Generally speaking, retrieval up and down the hierarchy are easily managed (not always)

Example

This example shows a hierarchy, which is based around the invoicing of customers and their payments. We assume that one customer can have several invoices and that an invoice can be paid by installments. This particular hierarchy would have been designed with a specific set of processing requirements in mind. For example, a query such as which invoices were sent to a particular customer? would be processed easily - since this is what the structure was supposed to handle However, a query which is the inverse of this one that is who was this particular invoice sent to? could not perform well because it was not anticipated, Effectively the second query requires a traversal of pointers in an upward direction and this is not straight forward.

The most important drawback is that the hierarchical model was used in such a way that only pre-specified structures were implemented and making any changes to them meant that the data structures would have to be amended. Major problem is that in many cases it is just not in the form of a hierarchy. If we modify the above example to allow a single payment to be paid for several invoices we are effectively destroying the hierarchy by adding this new element.

Drawbacks of the hierarchical model

Difficult to change the structure:
Once the database designer has formulated a particular hierarchy in response to a set of current needs. It becomes very difficult to make amendments to the structure. Many organizations are dynamic and this drawback has serious implications to the way in which it is possible to cater to this changing aspect.

Unplanned queries are difficult to support:
The beauty of database systems is that a user is able to perform ad-hoc queries- unfortunately this is not possible within the hierarchical model since the structure of data is only able to reflect one particular type of processing.

The Network model

The network model represents a complex structure. Within a network any record may have many immediate parents as well as many dependents. In other words, the restriction to one hierarchical parent does not apply. The network model is thus able to reproduce a greater number of real-world situations.

The network model can now successfully manage the scenario of the previous example, namely the ability for a payment to serve more than one invoice.

The main difference as far as this example is concerned is that in the hierarchical model invoice records were stored physically next to the customer record to which they belonged. As far as the network model is concerned this does not have to be the case.

Since pointers are used heavily to make a chain of invoice records which can be traced back to a particular customer. This is what makes answering the query'to which customer does a particular invoice belong?' much easier. ln the same example the aspect that we can now model successfully is when it is possible for a payment to cover more than one invoice.

Drawbacks of the network approach

Pointer technology is used to implement relationships:

• The network model relies heavily on pointer technology This causes a reasonable amount of overheads and performance is an issue.
• Unplanned queries are difficult to support
• No assumptions can be made
• As soon as the structure changes the programmer must be aware of it.

The Relational Model

Most people are familiar with the relational approach since it is the most popular choice for database development currently. A brief list of its advantages is given here only in order to compare with previous models.

Data stored in relation:
The relation(which is the only construct in model) is based on sound mathematical theory and has several very useful properties.

Easy to understand concepts:
Even naive users are able to interact with a relational database since the idea of table with rows and columns is familiar to every one. Also the relational database comes with a filly defined query language which contains just a handful of commands which can be easily understood.

No Physical pointers:
The main advantage over earlier approaches is the fact that there are no physical pointers for the user to worry about. Indeed at the lowest level there maybe well usage of pointers, but this is never made evident to the user. The advantages of this is that the user is no longer burdened with having to navigate the database.

Logical/Physical clearly separated:
One of the consequences of not using physical pointers is that now the logical and physical aspects of the system can be separated- this ensure high degree of data independence.

Easy to set up and change:
The query language includes DDL commands which are relatively easy to use. It is a straightforward thing to be able to add a new relation to an existing set of relations (and indeed discard it later). Changing needs can be more readily reflected in a relational database.