We present an exception handling facility suitable for languages used to implement database-intensive Information Systems. Such a mechanism facilitates the development and maintenance of more flexible software systems by supporting the abstraction of details concerning special or abnormal occurrences. We consider the type constraints imposed by the schema as well as various semantic integrity assertions to be normalcy conditions, and the key contribution of this work is to allow exceptions to these constraints to persist. To achieve this, we propose solutions to a range of problems, including sharing and computing with exceptional information, exception handling by users, the logic of constraints with exceptions, and implementation issues. We also illustrate the use of exception handling in dealing with null values, estimates, and measurements. Keywords and phrases: semantic integrity, violations of type constraints, exception handling, accommodating exceptions, conceptual models CR ...

Integrating a production rules facility into a database system provides a uniform mechanism for a number of advanced database features including integrity constraint enforcement, derived data maintenance, triggers, alerters, protection, version control, and others. In addition, a database system with rule processing capabilities provides a useful platform for large and efficient knowledge-base and expert systems. Database systems with production rules are referred to as active database systems, and the field of active database systems has indeed been active. This chapter summarizes current work in active database systems; topics covered include active database rule models and languages, rule execution semantics, and implementation issues. 1 Introduction Conventional database systems are passive: they only execute queries or transactions explicitly submitted by a user or an application program. For many applications, however, it is important to monitor situations of interest, and to ...

Through implicit invocation, procedures are called without explicitly referencing them. Implicit announcement adds to this implicitness by not only keeping implicit which procedures are called, but also where or when — under implicit invocation with implicit announcement, the call site contains no signs of that, or what it calls. Recently, aspect-oriented programming has popularized implicit invocation with implicit announcement as a possibility to separate concerns that lead to interwoven code if conventional programming techniques are used. However, as has been noted elsewhere, as currently implemented it establishes strong implicit dependencies between components, hampering independent software development and evolution. To address this problem, we present a type-based modularization of implicit invocation with implicit announcement that is inspired by how interfaces and exceptions are realized in JAVA. By extending an existing compiler and by rewriting several programs to make use of our proposed language constructs, we found that the imposed declaration clutter tends to be moderate; in particular, we found that for general applications of implicit invocation with implicit announcement, fears that programs utilizing our form of modularization become unreasonably verbose are unjustified.

Active mechanisms based on event-condition-action rules will play an important role in next-generation database management systems. As an event, in its most general form, is essentially a point in time, it is obvious that an appropriate concept of time is needed for the specification of events. However, there are also other aspects related to time that need to be considered in active database systems, and which should tie in with the general concept of time in case the active database is also a temporal one. This position paper gives a brief account of where time issues arise in active database systems, and especially demonstrates various options for powerful event specification features. 1 Motivation and relationship to temporal databases Active mechanisms are generally considered to be one of the important features needed in next-generation database systems [Comm 90], and a lot of research is currently being conducted in this field [Chak 93]. While their origins date far back to sim...

Properties. Given RA, D, and U # as above, a set #={del R 1 (x 1 ), ...,del R n (x n )} of delete requests is called ---founded, if for all del R(x)##, there is a #del R (x # )#U # s.t. (R(x), R # (x # )) # (note that here, we need reflexivity for covering R # (x # ) itself), ---complete,if del R P (y)##and (R C (x), R P (y)) ---feasible, if (i) (R C (x), R P (y)) implies del R P (y) / ##, (ii) del R P (y)##and (R C (x), R P (y)) ---admissible, if it is founded, complete, and feasible.