This paper explores a mechanism to support user-defined data types for columns in a relational data base system. Previous work suggested how to support new operators and new data types. The contribution of this work is to suggest ways to allow query optimization on commands which include new data types and operators and ways to allow access methods to be used for new data types. 1. INTRODUCTION The collection of built-in data types in a data base system (e.g. integer, floating point number, character string) and built-in operators (e.g. +, -, *, /) were motivated by the needs of business data processing applications. However, in many engineering applications this collection of types is not appropriate. For example, in a geographic application a user typically wants points, lines, line groups and polygons as basic data types and operators which include intersection, distance and containment. In scientific application, one requires complex numbers and time series with appropriate operat...

Alpine is a file system that supports atomic transactions and is designed to operate as a service on a computer network. Alpine’s primary purpose is to store files that represent databases. An important secondary goal is to store ordinary files representing documents, program modules, and the like. Unlike other file servers described in the literature, Alpine uses a log-based technique to implement atomic file update. Another unusual aspect of Alpine is that it performs all communication via a general-purpose remote procedure call facility. Both of these decisions have worked out well. This paper describes Alpine’s design and implementation, and evaluates the system in light of our experience to date. Alpine is written in Cedar, a strongly typed modular programming language that includes garbage-collected storage. We report on using the Cedar language and programming environment to develop Alpine.

Currently most distributed file systems transfer messages about files between machines. The implementation of file system that uses a lower level, communications interface (BB-NFS) is described. This system uses a `block-based' interface that exchanges information about the blocks that make up the file but not about the les themselves. It provides the Unix file system interface and demonstrates the feasibility and implementability of the block-based approach. The advantages of this approach include a reduction of the processing required at the server, uniformity in managing file blocks and fine-grained placement and replication of data. The simple communications model also lends itself to efficient implementation both at the server and in the communications protocols that support the interface. These advantages come at the cost of a more complex client implementation and the need for a lower level consistency mechanism. Leases are used to maintain consistency of file system meta-data...

This paper ditcusses the functions preseni in a sophisticated relation browser with support for icons, maps, text and normal fixed format relations. A discussion of some of the required data base extensions to support, such a browser is also presented. I INTRODUCTIOX This paper suggests the design of TIMBER (Text, icon and Map Browser for Extended Relations), a user friendly, graphics-oriented browser for a relational data base. There are four motivations for TIMBER which will be discussed in t,urn. 1) Relation Editor There is a need for a software iacility which would allow a user to “browse ” through a relation. Commands such as “next tuple ” and “search for the first tuple ” sztisfying a given constraint are required. A proposal along these lines is presented in [CATEBO] for a CODASYL data base. The various proposals for interaction with a data base through forms, e.g. [ROWE32, DEJOBO], can be used to implement a relation editor. One would define a default form which can be used with any reiation. Tuples from any given relation can then be displayed through the form. However, most forms proposals are limited to a single form on the screen at one time and to a single data base tuple in any form. What we propose is a more sophisticated