APPENDIX A. DATABASE SYSTEMS

Definitions of the term "database system" vary from "nothing more than a computer-based record-keeping system" (Date 1981] to "a generalised collection of data which is structured on natural data relationships so that it provides all necessary access paths to each unit of data in order to fulfil the differing needs of all users" [Deen 1977]. The power of a database system lies with its DBMS (Database Management System), "a set of programs that operates on the database in accordance with the user's commands"

[Kroenke 1977]. The DBMS is a means of centralising physical and conceptual control of the data and its usage. A DBMS enhances the

~uality of the data maintaining its integrity, consistency privacy and secu ity. It can also synchronise re~uests in a multi-user envi onment and can provide a high degree of data

independence. Data independence is the insensitivity of application programs using a common database to restructuring of the data- i.e. programs do not depend on any one particular storage structure or access strategy. There are numerous other advantages to using a database system, such as simplicity, flexibility, protection and recovery procedures and elimination of uncontrolled redundancy. In addition, most database systems provide a ~uery language facility for direct interrogation of the database without the need for an application program. Database systems aim at reducing processing time and storage space: this however depends on the database design, programmer expertise and the nature of the organisation using the database; results will vary accordingly.

The three 'views' database system, are

of a database, and then the three types of briefly described. Thereafter a short

•

•

•

•

comparison of these three approaches is made.

B1 . Views.

IN ANSI/SPARC [Tsichritzis 1978] terminology, an external view is one individual' s view of the database. Usually there are several differing external views of a database, since users generally work with only a sect ion of the database, and may not visualise shared data in the same way. The conceptual view is a view of the entire information cont ent of the database, in other words it is a consolidation of all the external views. In contrast, the internal view is the view of the entire database as it is actually physically stored. Ideally, only the DBMS should be concerned with the latter , and not the application programmers. The conceptual view is specified by writing a schema, as was explained in chapter two of this thesis. This task is performed by or in conjunction with the Database Administrator, who is also responsible fo database maintenance. The data definition language almost invariably has statements that describe the physical layout of the database. Although it conflicts with the aim of data independence, the efficiency of the system can be improved by taking advantage of this. Security and integrity constraints are also given in the schema. Subschemas, as outlined in chapter two, epresent different views of the database, and are derivable from, and usually a subset of, the schema.

B2. Network Database Systems.

In 1971 the Database Task Group (DBTG) of the Conference on Data Systems Languages (CODASYL) [Codasyl 1971] laid down proposals for a network database system, which included specifications of the network model, and of· notations for a DDL, SDDL and DML. The network model represent entities as records, and relationships as

•

•

Appendix A. Database Systems.

-194

sets.

Sets are the major CODASYL innovation. In the schema, they require an explicit definition and have properties of their own. A set type is described as having a certain record type as owner and another record type as member. A set represents a 1 :many relationship or mapping from the owner to the member (or 1:1, as a special case). Several member record types can participate in one set type, and two or more set types with owner R1 and member R2 can be defined. Many-to-many relationships, and associations involving only one record type, cannot be directly implemented in a network database. Although there are ways of circumventing these problems, they tend to make the network intricate and thus more difficult to work with. A description of a database in the schema DDL consists of four major sections : an introductory clause, one or more area clauses, one or more record clauses, one or more set clauses. The introductory clause is used ot name the database and to state certain global security and integrity constraints. An area is a subdivision of the database, which in many implementations corresponds to a file. These sections have already been explained in the body of the thesis.

An interesting aspect of the CODASYL schema is that it includes the specification of access strategy and storage structure, which are physical considerations.

B3 Hierarchical database systems.

In a hierarchical database system, an entity is represented by a segment, which is analogous to a 'record' in the network model.

That is, it is the unit of data access and comprises a number of fields. Relationships between segments are represented by means of rooted trees or hierarchies. A tree is a structure in which every segment has one and only one parent( analagous to 'owner' in

•

the DBTG model), except for one segment type, the root, which has no parent. A parent:child association represents a 1 :many mapping from parent to child. Unlike network models, a segment occurrence can only be linked to one occurrence of its parent. For example, in a CODASYL schema, two sets ROUTE->SHIP can be defined, to represent the current and previous routes of each ship. In the hierarchical model this could not be implemented directly in this way, because a SHIP occurrence could only have one ROUTE occurrence as parent. Every segment has one or more fields designated as its key, and children are linked to their parent in key se~uence order. This factor is utilised in the DML, which , • includes commands such as 'get next', meaning next with respect to chis hierarchical key se~uencing. Many-to-mal!y relationships between segments cannot be directly represented in a hierarchical

•

database; however several commercial hierarchical DBMSs provide a means of circumventing this problem. IBM's IMS for example uses the concept of 'virtual pairing'. This involves using two tree types, where the child segment of each tree acts as a pointer to the appropriate data in the other tree type. The hierarchical model uses different terminology from that of the CODASYL DBTG:

The schema comprises one DBD (Database Definition) for each PDB (Physical Database); a subschema is termed a PSB (Program Specification Block) and constitutes one PCB (Program Communication Block) for each LDB (Logical Database) in that view.

A PCB can refer to a subsection of the DBD, in which case the segments it re~uires are called 'sensitive segments'. If a segment is non-sensitive, none of its "descendants" can be defined in that PCB.

B4. Relational databases.

The relational model was invented by E.F.Codd and differs from the