In previous work [KERR91b] we have given detailed reasons for the rejection of a general purpose Operating System, and the use of a Data Storage Description Language (DSDL) in IDIOMS. Below, we summarise our findings.
The role of an operating system is essentially the allocation of resources (memory, processing time, use of peripherals). Most of the functions provided are not needed for a dedicated machine, and additionally, the transputer [INMO88], which we are using as the hardware base, is able to provide those facilities which we do require. Memory is allocated statically at compile time, and is thus dealt with by language compilers. This is not a major restriction given the size of real memory that can be made available. Further, the problems of memory fragmentation and garbage collection do not occur. Processing time is allocated by means of a micro-coded process scheduler built into the transputer. This scheduler provides the two scheduling modes required to support database processing [SHAR91], namely a high priority non-preemptive mode suitable for OLTP, and a low priority mode, which time-slices between processes, and is suited to MIS. here are no peripherals to control, apart from storage disks, which have their own (possibly shared) disk controller. The access interface which we have constructed can be easily modified to deal with any type of disk, thereby enabling easy incorporation of new faster disk technology.
There is a fundamental mismatch between the file organisations normally provided by an operating system (serial and random) and those needed by a database system. Thus most systems claiming portability implement their own storage access mechanism using low level operating system calls. The database implement is faced with the task of designing a special purpose data access method in any event. This is precisely what happens in the IDIOMS machine, except that the additional system software interface is omitted thereby improving efficiency. A further problem with file systems is that the generation of multi-volume files is very difficult to manage. A large database will usually have tables which span many disk volumes. The control of what data is placed upon which disk volume usually cannot be finely controlled.
Our conclusion is that an operating system does not help with the efficient operation of a database machine, especially when it is built with transputers. The only aspect which requires control is the actual placement of rows to a particular unit of data storage. This is achieved by the DSDL [KERR91c].
The whole reason for using SQL is that (MIS) data is accessed by content rather than a navigational technique. The DSDL naturally expresses the partitioning of data by content over the data storage. This has the advantage that the search space of a query can be reduced if a predicate in the query refers to a column which is used to partition the data. For example, rows containing personal details can be partitioned by gender. Queries referring to a particular sex will only need to be sent to the required partition. A partial DSDL specification, relating to our example partitioning (figure 4) discussed later, is shown in figure 6.
A further aspect of (OLTP) database access is that sophisticated indexing strategies are used. Such strategies are not normally provided by operating systems. We have included this capability in the DSDL.