Research Trends and Issues in Real-Time Database Systems Sang H. Son Dept. of Computer Science University of Virginia Charlottesville, Virginia 22903 son@cs.virginia.edu ABSTRACT Real-time database systems need to be designed and developed to address the challenge of simultaneously satisfying data integrity and timing requirements. The latter arises from the need to preserve the temporal validity of data that reect the state of the environment being monitored and controlled by the system, and to meet the response time requirements coming from applications and physical components of the system. These constraints, in turn, necessitate timecognizant transaction processing to meet the deadlines of transactions, and predictable execution of critical transactions. Studies on real-time database systems have been underway for a decade now, and produced a mature body of research results in several areas. As new applications of real-time database systems appear, however, several important aspects need further research, especially in the light of recent information technology trends. In this report, after introducing the characteristics of data and transactions in real-time databases, we discuss issues that are critical in processing time-constrained transactions and improving the predictability of the system. We also address current research activities and remaining important issues for future research.
1 Introduction Many real-world applications involve time-constrained access to data as well as access to data that has temporal validity. For example, consider telephone switching systems, network management, program stock trading, process control in automated factories, and command and control systems. All of these involve gathering data from the environment, processing the information gathered in the context of information acquired in the past, and providing a timely and temporally correct response. In several cases, those systems are used for safety-critical applications, in which human lives or expensive machinery may be at stake. Their missions are often long-lived and noninterruptible, making maintenance or reconguration dicult. The constant demands from the operating environments of such systems often pose rigid requirements on their timely performance. These requirements are often dened as real-time constraints on their temporal behavior. For example, in real-time systems an action performed too late (or too early), or a computation that uses temporally invalid (or temporally inconsistent) data may be useless, and sometimes harmful even if such an action or computation is functionally correct. The growing interest in real-time systems has led to a body of real-time computing research work, which permeates many areas in computer science and information science. As real-time systems continue to evolve, their applications become more complex, and often require timely and predictable access to massive amounts of data. This need for advanced data management functionalities in real-time systems poses formidable intellectual and engineering challenges to database researchers and practitioners. Since databases often employ ecient but unpredictable data structures to store the high volume of information, they result in the variations in the data access time. In addition, conventional database systems do not schedule transactions to meet their timing requirements and they commonly lock data to assure consistency. Locks and timedriven scheduling are basically incompatible. Low priority transactions may block higher priority transactions, leading to timing requirement failures. For these reasons, most general-purpose database products are not acceptable to real-time system applications. A real-time database system can be viewed as an amalgamation of a conventional database management system and a real-time system. Like a conventional database system, it has to process transactions and guarantee basic correctness criteria. Furthermore, it has to operate in real-time, satisfying timing constraints imposed on transaction commitments and on the temporal validity of data. A real-time database system may exist as a stand-alone system or as an embedded component in a larger multidatabase system. The tradeos faced by the designers of real-time database systems are quite dierent from those faced by the designers of general-purpose database systems. For example, the conventional concurrency control with transaction blocking may cause some real-time transactions to miss deadlines, even though the database integrity is maintained. To meet the fundamental requirements of timeliness and predictability, we should not only replace the conventional methods for scheduling and concurrency control, but also employ new concepts that have not been considered in non-real-time database systems. Two main issues that must be addressed in real-time database systems are the temporal nature of data and transactions, and predictability of transaction execution. Much of the data in a real-time database is "active" in that it models a rapidly changing environment. Furthermore, transactions may need to have "temporally coherent" views of the database as well as to meet deadlines. The temporal nature of data and transactions has a number of implications: Active data becomes invalid as time progresses; that is, the validity of active data is inde-
pendent of the database state and activities. A real-time database may never be completely correct, since there is a time lag between the monitoring and recording of active data. Since active data is not necessarily updated at the same time or rate, there may be a dispersion of ages of active data. That is, their values may not co-exist in any snapshot of the real-world. Schedules must not only be serializable, but temporally-correct; that is, the correctness of a transaction may depend on the ages and dispersion of ages of the data read, as well as a completion time. Real-time transactions must be executed in a timely and predictable manner. Timely and predictable execution of transactions requires good estimates of their worst-case execution times, which is usually dicult to obtain since transactions' execution times depend on the values of data items they access, transactions can be blocked or aborted due to data and other resource conicts, resource requirements and data access requirements of transactions are hard to predict, and I/O scheduling and buer management techniques aect transaction execution time. It is useful to categorize transactions in real-time database systems as hard, soft, and rm transactions. Hard transactions are those for which missing a deadline could result in catastrophic consequences, and hence must not happen. If completed transactions are assigned values to measure the benets obtained by completing them, a hard transaction with a missed deadline is given a very large negative value. In contrast, soft transactions have timing constraints, but there is still justication in completing them after the deadline, since they have some monotonically decreasing value that drops to zero at some point in time. For rm transactions, the value drops to zero at the deadline. Most current work on real-time database systems deals with soft real-time systems, such as program trading in the stock market. They are designed soft because missing a deadline is not catastrophic. Usually, algorithms and protocols for such systems explicitly address deadlines and make a best eort at meeting deadlines. Database systems that support hard transactions are usually called hard real-time database systems, while soft real-time database systems support only soft and rm transactions. Most hard real-time database systems are main memory databases of small size, with predened transactions, and hand crafted for ecient performance. The metrics for hard real-time database systems are dierent from those for soft real-time database systems. For example, in a soft real-time database system, metrics include response time, throughput, and the percentage of transactions which meet deadlines. The system supports consistency (serializability), atomicity, and permanence of transactions. On the other hand, in a hard real-time database, not all transactions have those properties (serializability, atomicity, and permanence). Those properties need to be supported only for specic transactions in certain situations. Metrics such as maximizing the value imparted by completed transactions and maximizing the percentage of soft/rm transactions that complete by their deadlines are primary metric. Throughput and response times are secondary metrics, if they are used at all.
While many of the techniques used in real-time systems and databases systems may be combined and applied to problems arising in real-time database systems, it is clear that some fresh approaches and modications are required. Meeting timing constraints demands new approaches to data and transaction management, some of which can be derived by tailoring, adapting, and extending solutions proposed for real-time systems and database systems. In this report, we present some of the basic concepts and terminologies and review some of the recent advances in real-time database research. We also present current research activities and future work in this area. 2 Scheduling Models for Real-Time Systems Hard real-time systems must meet the deadlines for their tasks. For many safety-critical applications, missing the deadline of an important task may bring the system to failure and the application to disaster. It is thus important for the system designer to adopt some well-studied system model and scheduling algorithms that can guarantee all important tasks meet their timing constraints. In this section, we review some commonly used scheduling algorithms. Many dierent types of timing constraints may be dened in real-time systems. The most commonly dened constraint is the deadline which species when a task must be nished. Tasks may also have ready times when they can start to be executed. Many scheduling algorithms have been designed to schedule tasks with some specic types of timing constraints. In scheduling tasks with repetitive requests, a well-known approach is to use the periodic task model. Using the periodic model, each task T i has a period P i and an execution time e i. T i must be executed once in every period. The execution of the task in any one period (called a job) is scheduled independently of the executions of the same task in other periods. The problem of scheduling periodic task systems has been extensively studied [53, 47]. Using this approach, every task (or job) is assigned a priority. At any time during execution, the system executes the job with the highest priority among those unnished active jobs. For periodic task systems, Liu and Layland [53] have shown that the rate-monotonic (RM) and the earliest-deadline-rst (EDF) priority assignments are optimal for xed and dynamic priority-driven preemptive scheduling schemes, respectively. Using RM, tasks with shorter periods are assigned higher priorities. The EDF algorithm assigns priorities to jobs according to their deadlines. The earlier a job's deadline is, the higher its priority. Another dynamic priority policy is the least slack rst (LSF). The slack of a task is dened to be the dierence between its deadline and its remaining execution time. It has been shown that LSF is as eective as EDF. Dening e i P i as the processor utilization of task T i, Liu P and Layland [53] have shown that as n long as the total utilization is less than or equal to 1, i.e. i=1 e i P i 1, the system with n periodic tasks is schedulable using the EDF algorithm. The least upper bound of the total utilization for a system using the RM algorithm is nx e i n(2 1=n? 1) (1) P i=1 i
The bound can be used for pessimistically checking the schedulability of a real-time system since the condition is only a sucient, not necessary, condition. In other words, meeting the condition means all tasks in the system can meet their deadlines, but violating the condition doesn't always mean that the system cannot meet all task deadlines using RM priorities. In fact, studies show that most system with utilizations around 0.85 can still meet all deadlines using the xed priority assigned by RM. A more precise but more complicated schedulability condition has been presented in [47]. For systems where some tasks are not periodic, or some tasks may have occasional overrun, systems can use additional protocols to handle them [46]. If tasks must share some data or resources in an exclusive manner, a priority ceiling protocol can be used to prevent unbounded delays [63] for systems using the RM xed priority scheduling. Protocols for bounding resource access delays under EDF have also been studied [7]. 3 Concurrency Control Database systems are designed to manage persistent data that are shared among concurrent tasks. Maintaining its logical consistency while processing concurrent transactions is one of the primary requirements for most databases. In real-time databases, temporal aspects of data and timing constraints of transactions must be considered as well. The temporal consistency of data requires that the actual state of the external world and the state represented by the contents of the database must be close enough to remain within the tolerance limit of applications. In general, temporal consistency of data has two aspects: absolute and relative. The absolute temporal consistency represents the requirement of data freshness, while relative temporal consistency represents the required correlation among data that is used together, as described below: An absolute validity interval is the length of time during which the current value of the data object is considered to be valid. The value of a data object x achieves absolute temporal consistency (or external consistency) only when t now? t x avi x, where t now is the current time, t x is the timestamp of x, and avi x is the absolute validity interval of x. A relative validity interval is associated with a set of data objects y used to derive a new data object y. Such a set y has a relative temporal consistency when the timestamp dierence (or temporal distance) between the data object y and any data object in the set is not greater than the relative validity interval rvi y. The value of a derived object y has temporal consistency only when all the values of data objects in y are externally consistent and y satises relative temporal consistency. The real-time (or temporal) characteristics of data in a real-time database system have also been discussed in details in [59]. These characteristics may give rise to stringent timing constraints that must be satised when transactions are executed. These constraints are in addition to the logical constraints imposed by the concurrency control protocol to ensure the database integrity. The satisfaction of both timing and logical constraints is inherently dicult due to the fact that concurrency control algorithms may introduce unpredictable delays due to transaction restarts and/or blocking. Early attempts to solve this problem have focussed on relaxing either the deadline semantics ( for soft [31] and rm [27] deadlines), or the transactions ACID properties (serializability in
particular) [60, 50, 84, 42, 51]. Various concurrency control algorithms dier in the time when conicts are detected, and in the way they are resolved. Pessimistic Concurrency Control (PCC) protocols detect conicts as soon as they occur and resolve them using blocking. Optimistic Concurrency Control (OCC) protocols detect conicts at transaction commit time and resolve them using rollbacks. Most real-time concurrency control schemes considered in the literature could be viewed as extensions of either PCC-based or OCC-based protocols [85]. In particular, transactions are assigned priorities that reect the urgency of their timing constraints. These priorities are used in conjunction with PCC-based techniques to make it possible for more urgent transactions to abort conicting, less urgent ones (thus avoiding the hazards of blockages). Examples include the Priority Abort (PA) technique [2], Priority Inheritance (PI) technique [62], and variations of these techniques [61, 30, 6, 65, 80]. These priorities are also used in conjunction with OCC-based techniques to favor more urgent transactions when conicting, less urgent ones attempt to validate and commit (thus avoiding the hazards of restarts). Examples include the Broadcast Commit (BC) technique [41, 27] and the Wait-50 technique [26]. Performance evaluation studies of these concurrency control techniques can be found in [2, 29, 63, 32, 1, 28, 31]. Other priority-driven real-time concurrency control protocols, which are not direct extensions of PCC or OCC, were also suggested in the literature. In [35], Kim and Srivastava studied and evaluated the potential performance improvement of using several protocols based on multipleversion two-phase locking concurrency control in real-time database systems. In [52, 66], Son et al propose a hybrid protocol that combines OCC and timestamp ordering. Using that protocol, the decision regarding the exact serialization order of transactions is delayed as much as possible to allow urgent transactions to commit. This is done through the dynamic allocation and adjustment of timestamp intervals [17]. In [12], Bestavros and Braoudakis proposed the use of Speculative Concurrency Control (SCC), whereby a transaction is allowed to use more resources so as to achieve better speculation and hence improve its chances for a timely commitment. One of the major problems in priority-based locking protocols is that, due to the eect of blocking, a condition known as priority inversion may occur. Priority inversion is said to occur when a higher priority task is forced to wait for the execution of a lower priority task for an indenite period of time. When two transactions attempt to access the same data object, the access must be serialized to maintain consistency. If the transaction of the higher priority task gains access rst, then the proper priority order is maintained; however, if the transaction of the lower priority gains access rst and then the higher priority transaction requests access to the data object, this higher priority task will be blocked until the lower priority transaction completes its access to the data object. Priority inversion is inevitable in transaction systems. However, to achieve a high degree of schedulability in real-time applications, priority inversion must be minimized. To address this problem, the priority ceiling protocol was proposed in [63]. It tries to achieve not only minimizing the blocking time of a transaction to at most one lower priority transaction execution time, but also preventing the formation of deadlocks. While the priority ceiling protocol is very useful in providing a bound on transaction blocking delay and schedulability analysis, it suers from unnecessary blockings due to the conservative transaction scheduling in data access. Recently, several approaches are being proposed to improve the performance by applying the notion of dynamic adjustment of serialization order, avoiding unnecessary blockings [40, 43].
4 Resource Management and Operating System Support The interaction between a real-time database system and its underlying operating system (OS) is another important topic of research because the correct functioning and timing behavior of realtime database systems cannot be guaranteed without a thorough understanding of the impact of OS internals including resource management in general, and scheduling in particular. The interplay between OS and real-time database system can be best understood through implementation eorts. In [5], Adelberg, Kao and Garcia-Molina describe their implementation of the Stanford STRIP platform. The main philosophy underlying STRIP is that soft real-time database systems are likely to be part of larger open systems (i.e. not a monolithic stand-alone system) consisting of many heterogeneous databases. Towards that end, STRIP is designed on top of UNIX and provides support for value function scheduling and for temporal constraints on data. Son et al. developed a suite of database systems on several platforms, including UNIX, ARTS, and Real-Time Mach [55]. The main focus of their work has been to apply current real-time technology to architect an actual real-time database systems [68]. The issues they considered included the interface between OS and real-time database systems [36], exible control of concurrent transactions [45], resource and data contention [49, 67], and predictable transaction execution [37]. One of the most recent work on resource management in real-time databases is the BeeHive project [75, 74]. BeeHive is an eort to develop a distributed real-time database which could oer features along dierent types of requirements: real-time, fault-tolerance, security, and quality-of service for audio and video. Support of these features and potential trade-os between them could provide a signicant improvement in performance and functionality over current distributed database and object management systems. BeeHive is an application-focussed distributed database system. For example, it could provide the database level support needed for information technology in the integrated battleeld. BeeHive is dierent from the World Wide Web and databases accessed on the Internet in many ways including BeeHive's emphasis on sensor data, use of time valid data, level of support for adaptive fault tolerance, support for real-time databases and security, and the special features that deal with crisis mode operation. Parts of the system can run on xed secure hosts and other parts can be more dynamic such as for mobile computers or general processors on the Internet. It is important to mention that BeeHive, while application focussed, is not isolated. BeeHive can interact with other virtual global databases, or Web browsers, or individual non-application specic databases via BeeHive wrappers. BeeHive will access these databases via downloaded Java applets that include standard SQL commands [75]. There are many research problems that must be solved to support a large scale distributed realtime databases. Solutions to these problems are needed both in terms of a distributed environment at the database level as well as real-time resource management below the database level, i.e., in both the operating system and network layers. Included is the need to provide end-to-end guarantees to a diverse set of real-time and non-real-time applications over the current and next generation Internet. Some of the research problems are developing an overall a priori analysis on the performance and security properties of the system, given a collection of adaptive objects, developing ecient techniques for on-line dynamic composition of these new objects, analyzing interactions and tradeos among the myriad of choices available to the system,
determining if the fault models are sucient, creating time bounded resource management and admission control policies, determining if there is enough access to legacy systems to achieve the security, functionality, timeliness, and reliability required, determining how the system works in crisis mode, and determining how the system scales. One of the main challenges in applying real-time technology (e.g., scheduling) to database systems is that the resources needed by a transaction may not be known a priori. A priori knowledge of transaction requirements is important for building a predictable system, even more so for meeting hard deadlines. This a priori knowledge is the underlying assumption taken by Ulusoy and Buchmann in their eorts described in [81] to improve timeliness by exploiting main memory database system features. Possessing complete knowledge of transaction requirements reduces resource management problems (e.g., concurrency control, memory and buer management) to scheduling problems. For many applications, however, the set of objects to be read (written) by a transaction may be dependent on user input (e.g., in a stock market application) or dependent on sensory inputs (e.g., in a process control application). In such systems, the a priori reservation of resources (e.g., read/write locks on data objects) to guarantee a particular Worst Case Execution Time (WCET) becomes impossible. And the non-deterministic delays associated with the on-the-y acquisition of such resources pose the real challenge of integrating scheduling into database system technology. This non-determinism has led to a wealth of work on scheduling and resource management techniques for best-eort systems (e.g., [20]), and prot-based systems (e.g., [13] and [21]). Scheduling issues permeates several facets of a real-time database system. One such facet is I/O scheduling and memory management. Example work includes the development of time-cognizant variants of the traditional SCAN disk scheduling algorithm by Abbott and Garcia-Molina [4] and by Carey, Jauhari, and Livny [20], the development of time-cognizant broadcast disk organizations by Bestavros [10], the development of priority-based buer managers by Abbott and Garcia-Molina [3] and by Kim and Srivastava [35], and the development of page replacement strategies for realtime memory managers by Carey, Jauhari, and Livny [20, 33] and by Abbott and Garcia-Molina [4]. In [57], Pang, Carey and Livny consider memory management at a higher level. They propose an admission control algorithm for real-time queries with large memory requirements, in which the multiprogramming level is related to the dynamic demand on the system's resources (memory). 5 Models and Paradigms Given the diverse and often conicting requirements on real-time database systems, it is useful to have a powerful real-time database model which can consistently address the tradeos among the requirements. The notion of transaction values and value functions [34, 54] has been utilized in both general real-time systems [15, 19] as well as in real-time database systems [2, 29, 73]. In [15, 19], the value of a task is evaluated during the admission control process. The decision to reject a task or remove a previously guaranteed task is based upon tasks' values. A task that is accepted into the system is conditionally guaranteed to complete its execution provided that no higher valued (critical) task (with which it conicts) arrives.
In [38, 39], Kim establishes a real-time database system model which includes both hard and soft real-time transactions, maintains temporal and logical consistency of data [59], and supports multiple guarantee levels. Under this model, an integrated transaction processing scheme is devised, providing both predictability and consistency for real-time database systems such that every application in the system is assured to achieve its own performance goal (the guarantee level) and maintain consistency requirement. A simulation study shows that higher guarantee levels require more system resources and therefore cost more than non-guaranteed transactions. In [18], Braoudakis takes a dierent approach, whereby transactions are associated with value functions that identify the nature of their timing constraints, as well as their overall importance to the system's mission. Under this framework a whole spectrum of transactions could be specied, including transactions with no timing constraints, as well as transactions with soft, rm, and hard deadlines. The novelty of this approach is that it allows transaction processing to be carried uniformly on all types of transactions. The ecacy of this approach has been demonstrated by applying it to the concurrency control problem in real-time database systems. In particular, speculative concurrency control algorithms [11] were extended to work under this framework and were shown to yield superior performance. An area which is closely related to real-time database is the Temporal and Active Databases. A temporal database is one that supports some aspects of time [76]. It is in general based on two dimensions of time: valid time which denotes the time a fact was true in reality, and transaction time during which the fact was was present in the database as stored data. An event's valid time is the time the event occurred in the real world, regardless of whether it is stored in some database. Valid time can also be in the future, if it is expected that a fact will be true at a specied future time. The transaction time (in fact, an interval) of a fact identies the transaction that inserted the fact into the database and the transaction that removed it from the database. While temporal databases deal with the validity of data and support a rich semantics for specifying temporal data models, they do not deal with time-constrained access of transactions which is essential in real-time database systems. For many applications such as control systems, a real-time constraint is imposed on a transaction to guarantee that the system's response to a trigger is committed in a timely manner. If the generation of this trigger depends on the state of the database, then the database is characterized as being both real-time and active. Application areas for active real-time database systems include automated manufacturing, air trac control, and stock market trading, among others. Early work on active real-time database systems include Dayal et al's High Performance ACtive (HiPAC) Database System project [23] and Korth et al's active real-time database system paradigm [41]. Over the last few years, interest in active real-time database systems has grown substantially [9]. We expect to see more fruitful work on the protocols designed for the integrated database model in the near future. 6 Predictability and Temporal Consistency There has been a signicant amount of work in real-time transaction processing [1, 14]. However, most of the work supports only soft/rm real-time transactions, and cannot provide predictability which is essential to support hard real-time transactions. In fact, there is no clearly dened notion of predictability widely accepted in the research community. It is important to identify the issues to guarantee hard real-time transactions and the temporal consistency requirements of data to be accessed by those hard real-time transactions.
One of the interesting research issues to be studied here is how to handle interactions between hard and soft/rm real-time transactions. Another important issue associated with predictability is how to schedule update transactions triggered by changes in the external world, while supporting timeliness of real-time transactions. If the system does not consider the dynamic workload of triggered transactions to enforce the temporal consistency, the desired level of predictability may not be achieved. In several applications, recomputing values of derived data could spend a signicant amount of resources, and hence in situations where real-time objects are changing rather rapidly, the system cannot keep up with the requirements of maintaining the real-time data "fresh" while satisfying all the timing constraints of transactions. Since the performance requirements may be dierent for each type of real-time applications, the term \predictability" should be interpreted in a specic context. A hard real-time system must be predictable in the sense that we should be able to know beforehand whether its tasks will complete before their deadlines. This prediction will be possible only if we know the worstcase execution time of a task and the data and resource needs of the task. However, in real-time database applications, it is not always possible to get this information in advance. Thus, we cannot give this kind of guarantee to all real-time transactions. Instead, we should provide dierent levels of guarantee to each type of real-time transaction. For example, for a group of real-time transactions, we should be able to predict at least what percentage of the transactions will meet the deadlines. The objective is to support all the hard timing constraints of critical transactions and temporal consistency requirements of data accessed by those critical transactions, and to achieve the specied guarantee levels or to minimize the deadline miss ratio of other transactions. Classifying transactions and data based on their characteristics and requirements, to be studied in the modeling work, is essential to the success of this eort. One approach is to determine certain attributes of a transaction (e.g., period and priority) based on the requirements, and then apply dierent processing schemes to each transaction [39]. Predictability is also important for soft deadline transactions, albeit to a lesser degree. For instance, using some scheduling policies designed for on-line scheduling, a system may provide an earlier feedback on whether a transaction can be completed before its deadline. Within the xed-priority preemptive scheduling framework, a number of approaches have been proposed for scheduling soft real-time tasks. One of the promising approaches for improving the timeliness of soft real-time tasks is dynamic slack stealing [48]. In the dynamic slack stealing algorithm, the slack stealer computes the slack time of each task at each time instant. The slack time is the spare time that can be yield to other tasks without violating the next deadline. However, since the abstraction of task and transaction is based on dierent assumptions, this approach is not directly applicable to soft real-time transaction scheduling. The dynamic slack stealer steals slacks with the highest priority and serves the slacks for soft-deadline transactions. When processing soft-deadline transactions using these slacks, it is desirable that we satisfy both the deadlines and the temporal consistency. If we process updates (recomputes) rst, every transactions can always read valid data but many soft-deadlines might be missed. Otherwise, more soft-deadlines can be met but the temporal consistency might be sacriced instead. Therefore, balancing the update (recompute) processing and transaction processing is an important problem. There are two approaches to maintaining temporal consistency of real-time data objects: static and dynamic. In a static approach, temporal consistency requirements are transformed into timing constraints of transactions. The system has only to provide a guarantee on the timing constraints
since as long as the corresponding transactions meet their deadlines, the temporal consistency of the data accessed by the transactions is automatically maintained. In a dynamic approach, the system repeatedly checks the temporal constraints of data at run time and tries to meet the temporal consistency requirements dynamically, either by using multiple versions of data objects or by delaying some transactions in favor of more urgent transactions to enforce the temporal consistency at the specic moment. The main concern is how to keep the data objects "fresh", while at the same time ensuring that transactions read valid data and meet the deadlines. It is necessary to consider how to handle transient overloads and develop proper mechanisms for time-cognizant scheduling. Previous work in supporting temporal consistency in real-time databases is mostly based on static enforcement to reduce overhead. The schemes that use this approach update image data objects or recompute derived data objects periodically so that the data is kept "always fresh". To achieve this objective, the update or recompute period of a real-time data object should be less than the half of the valid interval of that object. However, it can be easily seen that data need not always be fresh because it is sucient to maintain the data fresh only when the data is actually used by transactions. These needless updates consume processor time and hence reduce the probability that aperiodic soft real-time transactions can be completed by their deadlines. Another problem with this approach is that hard real-time deadlines are not solely determined by the original requirements coming from the specication of the application, but are strictly restricted by the update or recompute period of real-time data. This restriction on the deadline reduces the schedulability of the given transactions that require guaranteed service. In certain applications, update and recompute loads can be very high and thus an ecient scheme is needed to balance the update (recompute) processing and transaction processing. Several approaches need to be investigated for enforcing the temporal consistency of real-time data. One possible approach to minimize the updates (recomputes) is updating (recomputing) the image data (derived data) only when these updates are actually required by hard-deadline transactions. Such approach is called the on-demand update scheme. In the on-demand scheme, a transaction is blocked when it tries to read an invalid data object, and another transaction is triggered to update the invalid data. On-demand schemes are expected to show the good performance in terms of the temporal consistency. If data are updated whenever they are to be used, we can guarantee that transactions always read fresh data. However, to satisfy the temporal consistency, a transaction should be committed before the valid interval of any data read by it expires. To guarantee this, it is necessary to adjust the deadline of the transaction by considering both absolute temporal consistency and relative temporal consistency requirements. 7 Object-Oriented Paradigm The increasing interest in Object Oriented (OO) systems, as shown in several real-time applications being developed using an object-oriented paradigm, has prompted a number of researchers to investigate the suitability of the OO paradigm for real-time database systems. In [86], Zhou, Rundensteiner, and Shin propose ROMPP, a Real-time Object Model with Performance Polymorphism, to capture the characteristics of real-time control applications. In [82], issues of temporal and logical consistency, and precision are investigated within an OO framework. The object-oriented approach seems promising for complex real-time system development. However, it is not clear whether object-oriented database systems would be superior to rela-
tional database systems for supporting real-time applications. Object-oriented data models can better support advanced data-intensive applications by providing the capabilities for modeling, storing and manipulating complex objects, and improve software engineering in building large and complex application systems by providing the support for encapsulated objects. The need for supporting real-time database requirements with object-oriented data models arises because real-time applications may require the modeling of complex encapsulated objects. Is there any inherent problem in object-oriented data models satisfying timing constraints of real-time applications? It is obvious that the basic features of object-oriented data models (objects, attributes, methods, messages, classes, class hierarchy, and inheritance) do not directly help timely processing of transactions. It is also true, however, that none of these features particularly interfere with the active pursuit of timely processing of transactions, except for the potential lack of ecient implementation techniques. Thus, issues in supporting real-time requirements with an objectoriented data model lie in extending the object-oriented data model to include specication of timing constraints on objects (more specically on attributes/methods), and to actively pursue timely execution of transactions, rather than in combating any incompatibility between objectoriented data models and real-time requirements. In order for an object-oriented database to support real-time applications, it would be necessary to integrate features for scheduling real-time transactions with the conventional object-oriented database model. There are four major policies for scheduling transactions in real-time requirements: (1) priority assignment, i.e., a policy for assigning priorities to transactions, (2) eligibility test, i.e., a policy to determine which transactions are eligible for service, (3) concurrency control, i.e., a basic synchronization mechanism, and (4) conict-resolution, i.e., a policy for resolving con- icts between two (or more) transactions that access the same data object. Each scheduling policy should work cooperatively to maximize the number of transactions that meet their deadlines. Object-oriented databases generalize the traditional database model in several ways. First, nested executions of transactions on objects are natural, since a method can invoke another method on some other objects. Second, instead of simple read and write operations on database objects, object-oriented databases permit arbitrary operations on objects. Finally, inheritance in objectoriented databases allows class hierarchies. These properties often make the problem of ensuring data consistency in object-oriented databases more dicult, because objects of arbitrary complexity become the unit of locking (resulting in less concurrency in transaction execution), and sometimes concurrency control requires the locking of not only the object accessed by a transaction, but also several other objects not directly accessed by the transaction. Specically, due to inheritance, (1) while a transaction accesses instances of a class, another transaction should not be able to modify the denition of any of the super classes of the class, and (2) while a transaction is evaluating a query, a set of class sub-hierarchies must not be modied by a conicting transaction. Also, diculties in managing transactions caused by objects of arbitrary complexity and their hierarchical relationship make the implementation of an object-oriented database system complicated, and have an adverse impact on its capability to support real-time applications. In order for an object-oriented database system to eciently support real-time applications, the system needs to be carefully designed to mitigate the complexity in transaction management. One of the important issues that need to be investigated is the interaction between triggering mechanisms and the object class hierarchy. To control potentially unbounded triggering sequences, the system must put certain restrictions to control the complexities coming from the class hierarchy and its interaction with triggering schemes of active real-time database systems.
8 Integrating Security Requirements In many applications of real-time databases, security is another important requirement, since the system maintains sensitive information to be shared by multiple users with dierent levels of security clearance. As more and more of such systems are in use, one cannot avoid the need for integrating them. That is, real-time systems have to be made acceptably secure and the secure systems need to support the timeliness requirements of real-time applications. For example, electronic commerce becomes an interesting application where both security and real-time requirements should be considered together. Security is critical in electronic commerce applications where the system often manages sensitive information (such as credit card numbers). Service providers are usually very sensitive to the needs of the clients, including implicit and explicit timing constraints. In some cases, if providing full security to each activity causes the system to become less timely (e.g., missing deadlines), the service providers would be reluctant in providing necessary security guarantees. If the amount of money at stake is below certain threshold (e.g., less than $10), the system should use mechanisms with less overhead for timely service, although it may involve certain level of insecurity (e.g., loss of $10 due to incomplete credit check). Another example could be command and control in military applications. When an attack is under way or damage/failure is detected and considered severe, the system must switch into crisis mode so that critical transactions and data must be maintained. In such situations, it would be much more desirable to allow minor security violations to satisfy critical timing constraints than to keep strict security rules and lose the battle. Although some recent work recognizes the need to consider non-absolute security (e.g., [16, 79]), the notion of security has been considered binary. A system is either secure or not. A security hole either exists or not. The problem with such binary notion of security is that in many cases, it is critical to develop a system that provides an acceptable level of security and risks, based on the notion of partial security rather than unconditional absolute security, to satisfy other conicting requirements such as real-time performance. In that regard, it is important to consider multiple security service levels for real-time database applications. To achieve that, the meaning of partial security must be clearly dened for security violations of sensitive data must be strictly controlled, while the cost of providing that level of service should not reduce the timeliness of the system. To improve the timeliness and security in such applications, several issues need to be carefully considered. The research in this area has been focused on identifying architectural and transaction processing issues. It is clear that a more rigorous model to capture the characteristics and semantics of transactions and data in secure real-time databases is necessary. This can enable ecient processing to improve the timeliness of the system. In addition, new approaches need to be developed and analyzed for supporting both requirements in transaction processing that can make trade-os if necessary. Security is concerned with the ability of a system to enforce a certain policy governing the use, modication, and destruction of information. There are two dierent policies that have been studied: discretionary security policy and mandatory (or multilevel) security policy. While discretionary access control has been used in several systems, it may not be adequate for preventing unauthorized disclosure of the information. Recently, many systems have been developed based on multilevel security policy such as the Bell-LaPadula model [8]. In the Bell-LaPadula model, security policies are stated in terms of subjects and objects. A subject is an active entity that can access objects. Every object is assigned a classication, and every subject a clearance. Classications and clearances are collectively referred to as security classes (or levels) and they are partially ordered.
Database systems that support the Bell-LaPadula properties are called multilevel secure database systems. The Bell-LaPadula model prevents direct ow of information from a higher access class to a lower access class, but the conditions are not sucient to ensure that security is not violated indirectly through what are known as covert channels [44]. A covert channel allows indirect transfer of information from a subject at a higher access class to a subject at a lower access class. An important class of covert channels that are usually associated with database systems are timing channels. A timing channel arises when a resource or object in the database is shared between subjects with dierent access classes. From earlier study, it became clear that security requirements are not compatible with real-time requirements [58, 69, 71, 72]. Frequently, priority inversion is necessary to avoid covert channels. Consider a transaction with a high security level and a high priority entering the database, and it nds that a transaction with a lower security level and a lower priority holds a write lock on a data item that it needs to access. If the system preempts the lower priority transaction to allow the higher priority transaction to execute, the principle of non-interference is violated, for the presence of a high security transaction aects the execution of a lower security transaction. On the other hand, if the system delays the high priority transaction, a priority inversion occurs. The system has encountered an unresolvable conict. In general, these unresolvable conicts occur when two transactions contend for the same resource, with one transaction having both a higher security level and a higher priority level than the other. Therefore, creating a database that is completely secure and strictly meets real-time requirements is not feasible. A system that wishes to accomplish the fusion of multi-level security and real-time requirements must make some concessions at times. An important but challenging problem to be addressed in supporting security and real-time is identifying the correct metrics to evaluate the level of security obtained in an adaptable system. To achieve the desired level of timeliness, the system may need to allow potential security violations at times. When the system has to trade-o security, the system is no longer completely secure; rather it only will be partially secure. In that case, it is extremely important to dene the exact meaning of partial security. In fact, several security practitioners recognize that complete security is a fallacy there is no system completely secure. In one way or the other, any operational system becomes vulnerable to security leaks. The real question is how we can make the system acceptably secure while it remains available and provides timely services. With appropriate policies and the mechanisms to enforce them in the system, increased availability and timeliness can be provided in situations where other systems without such capability may just freeze or stop operating to ensure the (imaginary) complete security. Two of the major research issues to be addressed are 1) to identify policies to specify quantitative levels of partial security, and 2) mechanisms to enforce the required level of partial security. One approach involves adapting the Bell-LaPadula security model and dening security requirements such that partial security could be allowed only between certain security levels. In this way, the designer can specify that the most sensitive information will never be allowed to be involved in potential security violations. Initially, the system may support the original Bell- LaPadula security model. As the real-time performance of the system degrades, the system allows more potential security violations and reduces the number of security conicts. Using this scheme, guarantees can be made about the security of the data, based on the specication of the security policy. It is possible to combine this approach with other methods of specifying the degree of potential security violations. For example, the bandwidth of the covert channels that may show up as the