5. CAPS™ layer 1: the Infinite Filing Cabinet (IFC™)

CAPS™ Layer 1 builds, on top of the relational DB in Layer 0, a real-time, transactional Object-Oriented Database (OODB).

The "Infinite" adjective in Layer 1's name refers to the fact that, by design, the IFC™ _never removes information_. Data that is logically "deleted" or "updated" is in fact simply marked up as "deprecated" so that by default it does not show up in normal searches.

This approach intrinsically provides a _perfect audit trail_ for all transactions performed in the IFC™. Furthermore, the approach ensures that a wealth of data remains permanently available for any future "data mining" requirements. Applications built with the CAPS™ framework need no special precautions to ensure auditability, nor to support "data mining" operations.

The ability to physically delete and obliterate data can be provided separately, through a dedicated "administrative console" interface that is not normally accessible to applications. This functionality is necessary in the rare case of applications for which legal requirements mandate physical, irrecoverable deletion of some data. The same interface, in theory, could also be used to recover storage space by forgetting some history. However, that is not the design intent of CAPS™. With the predicted rate of cost decrease and capacity increase of storage solutions, we judge it most likely that the business value provided by keeping all historical data around will far outstrip the modest per-bit costs of storage subsystems.

The OO architecture of the IFC™ separates _queries_, which yield the sets of objects meeting certain conditions, from _requests_, which yield the values of specified attributes of a given set of objects. Queries and requests can be employed in the same way as queries are used in traditional database operations. Such "traditional" queries and requests (known in CAPS™ as _transient_ ones) obtain the sets of objects, or attribute values, "captured" at the time the query or request is performed. In addition, as befits the real-time enterprise capabilities of the IFC™, queries and requests can be flagged as _subscriptions_. In this case, the IFC™ sends information about updates to the relevant sets (additions, removals, changes in attribute values), each time the database changes in ways that modify the sets.

This crucial "subscription" ability ensures that all subsystems downstream of the IFC™ can, if they wish, display constantly-updated information, without any need for continuously "polling" the IFC™ with repeated requests and queries.

The real-time enterprise abilities of the IFC™ also include "IFC™ events". Events are similar to the "triggers" and "stored procedures" popular in RDBMSs. However, IFC™ events can be triggered or masked by the passage of time, as well as by conditions related to the data held in the database. Each IFC™ event alerts CAPS™ layer 2, the BL, so that the BL can perform appropriate actions specific to the event.

IFC™ events may be "normal", "timed", or "rule-based". Each kind of IFC™ event is represented by a corresponding kind of event-object. A _normal_ event-object sends an alert when certain attributes change to given values, or away from given values, or from given "entry" values to given "exit" values. A _timed_ event-object sends the alert if, and only if, speci fied attributes have certain given values at a given instant of time. A _rule-based_ event-object is similar to a normal event-object, but, rather than applying to specific existing objects, it applies to all newly created objects that satisfy specified rules.