View maintenance issues for the chronicle data model (extended abstract)
H. V. Jagadish, Inderpal Singh Mumick, Abraham Silberschatz · 1995
To meet the stringent performance requirements of transaction recording systems, much of the recording and query processing functionality, which should preferably be in the database, is actually implemented in the procedural application code, with the attendant difficulties in development, modularization, maintenance, and evolution.To combat this deficiency, we propose a new data model, the chronicle model, which permits the capture, within the data model, Queries over the stored sequence of transaction records, with stringent response time requirements.Of particular interest are summary queries, that access summarization, or aggregation information of past transactional activity.For example, a cellular phone company may want to provide a facility for a summary query that computes the total number of minutes of calls made in the current billing month from a phone number.This query could be executed whenever a cellular phone is turned on, and the result could be displayed on the customer's phone instrument.Another example of a summary query that a customer care agent in the cellular company may want to execute is: What is the total number of minutes of calls made from a given cellular number since the number was assigned to the current customer.These applications can be (and are) implemented using commercially available relational databases.However, the relational model is not suitable to capture and exploit the peculiar characteristics of a transaction recording system.For example, there is no support for answering a summary query over a sequence that is not