Database Systems

In this chapter we discuss in an informal manner the idea of a database as an abstract machine. An abstract machine is a model of the key features of some system without any detail of implementation. The objective of this chapter is to describe the major components of a database system without introducing any formal notation, or introducing any concepts of representation, development or implementation. Concepts of representation are considered in part 1; concepts of implementation are considered in part 2; concepts of development are considered in part 3.

In this chapter we broaden the discussion of chapter 1 by establishing an initial definition for some of the major concepts which are discussed in chapters which follow: database, database management system, data model. All three concepts are bundled together closely in the process of database development.

The relational data model is unusual in being largely due to the efforts of one man, E. F. Codd. In 1970 E. F. Codd published a seminal paper which laid the foundation for probably the most popular of the contemporary data models. From 1968 to 1988 Codd published more than 30 technical papers on the Relational Data Model. He refers to the total content of the pre-1979 papers as version one of the Relational Data Model (Codd, 1990).

In this chapter we discuss the two so-called classic data models: the hierarchical data model and the network data model. In section 1.5.3 we defined the idea of a classic data model in terms of record-orientation. In this sense, we might include the relational data model in amongst the classic data models. Here, the network and hierarchical data models are also described as being classic in the sense that they formed the basis for the first commercially available DBMS. Although currently relational systems have tended to outstrip network or hierarchical DBMS, a large number of legacy systems still exist running under these approaches.

An OVUM report published in 1988 predicted that database systems adhering to an object-oriented data model as opposed to a relational data model would overtake relational database systems by the mid 1990s (OVUM, 1988). Although this clearly has not happened, there is no doubt that object-oriented concepts are influencing the development of information systems. As evidence of this many relational DBMS vendors are beginning to offer OO features and SQL3 (chapter 6) is reported to be addressing object-orientation. However, there is some confusion about what it actually means to be object-oriented. The present chapter attempts a brief discussion of this issue in terms of database systems.

In this chapter we shall reflect the relational data model (chapter 3) against the contemporary practice of relational database systems. Contemporary practice is primarily centred around a language known as SQL (Structured Query Language). SQL was originally designed as a query language based on the relational calculus (section 3.3.11). The current specification of SQL is however much more than simply a query language. It is more accurately described as being a database sublanguage. Indeed, this database sub-language is becoming the standard interface to relational and non-relational DBMS.

In this chapter we describe some of the operational issues we would expect to find characterising the kernel of any DBMS. We shall discuss such features particularly with reference to relational DBMS. We begin however with a brief discussion of the physical storage of data on disk devices.

To review, modem-day relational DBMS can be considered as having three parts: a kernel, an interface and a toolkit. The kernel comprises the core DBMS functions such as storage and concurrency control. The interface comprises generally some database sub-language such as SQL. Around this standard interface most vendors offer a range of additional software tools for producing information systems. We call this collection the DBMS toolkit. Thus the concept of DBMS originally discussed in chapter 2 is extending further outwards to encompass more and more areas of application building. In this chapter we concentrate on tools for information systems development and use. We do not consider tools for monitoring and administering databases. These are briefly discussed in chapter 11.

The 1990s have been portrayed by many as the era of the distributed database system (Ozsu and Valduriez, 1991). We begin this chapter by describing some of the major objectives, advantages, and disadvantages of distributed systems. This leads us to a discussion of some of the major types of distributed database system. We conclude with a detailed look at client-server database systems.

In chapters 6 to 8 we have discussed the component parts of a DBMS in vendorindependent terms. In chapter 9 we discussed the distribution of components and data. In this chapter we provide an overview of two prominent commercial DBMS, one relational the other object-oriented. Our aim is to illustrate the functionality of existing DBMS products.

In this chapter we link the issues involved on the management of existing database systems with the development of new database systems. To do this we distinguish between two key roles which have emerged with the rise of database systems: the database administrator and data administrator. The data administrator is now one of the key persons involved in the development of databased information systems. We also describe some of the key functions of the database administrator, particularly the development of views and granting data and facilities privileges to users via some DBMS. We close with a look at the concept of a data dictionary and its use in data and database administration.

In his seminal paper on the relational data model, E. F. Codd formulated a number of design principles for a relational database (Codd, 1970). These principles were originally formalised in terms of three normal forms: first normal form, second normal form and third normal form. The process of transforming a database design through these three normal forms is known as normalisation. By the mid-1970s third normal form was shown to have certain inadequacies and a stronger normal form, known as Boyce-Codd normal form, was introduced (Codd, 1974). Subsequently Fagin introduced fourth normal form and indeed fifth normal form (Fagin 1977, 1979). In this chapter we consider Codd 's original ideas on normalisation whilst also describing a graphic technique used for designing fully normalised schema. We particularly emphasise the use of normalisation as a bottom-up technique for database design.

In this chapter we describe in some detail the top-down approach to data analysis based around a diagrammatic technique known as entity-relationship diagramming. In the bottom-up approach (chapter 12) of normalisation we must have a data-set in place before we can begin the process of logical database design. The aim of bottomup data analysis is to divide this data-set into logical groupings. Bottom-up data analysis is therefore concrete data analysis. In contrast, top-down data analysis is data analysis in the abstract. There need be no data-set in place which the data analyst can examine. Instead, he or she has to build a model of the ‘things of interest’ to an organisation. Such a model is usually referred to as a data model.

Logical database design is the process of constructing a business data model, that is, a model of the business rules applying to some enterprise. Physical database design involves taking the results from the logical design process, fine-tuning them against the performance and storage requirements of some application and then implementing them in the mechanisms of some DBMS. With the rise of the relational data model, the emphasis has changed in the database literature. Prior to the relational data model the emphasis in texts on database design tended to concentrate on physical database design. Nowadays, the emphasis is clearly directed at logical database design. This is primarily because some success has been achieved in formalising logical design. Physical design, in comparison, is relatively unformalised.

A computer can conveniently be considered to be made up of three parts excluding any man-machine interfaces such as keyboard, screen, printers, etc. These three parts are the central processor, the main memory and the backing store. A simple representation of such a system is shown in figure 16.1.

The aim of this chapter is twofold: first, to introduce the idea of connecting together the two concepts of intelligence and databases; second, to survey some of the research and development within the field of computing that serves to implement aspects of this connection. The first aim really serves to define intelligent databases as lying at the intersection between work in databases and work in artificial intelligence. The second aim is particularly bound up with identifying the key business advantages of so-called ‘intelligent’ databases.

In chapter 5 we mentioned that modem database systems have been extremely effective at providing efficient solutions for handling standard commercial data. By standard commercial data we mean data subject to a limited range of data types such as integer, character, etc. However, as the realms of information systems impinge on more and more areas of human activity, so the idea of applying database technology to the problems of handling more complex data has become significant. As an illustration of this trend, this chapter considers in overview the application of database systems to two such complex realms: hypermedia systems and geographical information systems. The chapter is meant to give the reader some feel for short-term developments in the database arena.