An active database is an automated interface that performs certain functions that are dependent on specific inputs of information. Programmers and administrators can manipulate active database systems to execute transactions according to predefined relationships. Similar to the idea of cause and effect, some of those relationships or queries are referred to as “coupling.” Within the database’s design, there are parameters that specify what information will be shared and whom it will be shared with.
The main difference between a conventional database and an active one is that something occurs as the result of something else. Automated bill payments are an example of an active database. A bank customer may instruct his institution to pay a payee a specific amount on a certain date each month. When the specified date is reached, the electronic payments are automatically sent to the payees indicated by the information in the database.
Sometimes referred to as event-driven architecture, an active database is designed to take actions based on certain triggers. There is usually a relationship between the events. For example, point of sale (POS) database systems may automatically re-order product for a retail store once they receive information that current inventory has fallen to a predefined amount. Depending upon the way the database parameters are set, the actual re-ordering may occur immediately, as a separate transaction, or be deferred.
Immediate transactions occur alongside triggering events. For instance, a POS system may re-order product according to universal product code (UPC) or stock keeping unit (SKU). It may process inventory levels and ordering transactions at the same time. Many mass retailers operate under this type of active database that receives continual inputs from several sources, including sales and receiving personnel.
Separate transactions are set up to occur at different times. Typically, the database is designed to examine the triggering event and may need to compare it to additional rules in order to execute an action. For example, a retailer’s POS system may be triggered by a low inventory level, but the action taken may depend on whether product is discontinued or if an item is supplied through a vendor. The database may not process an order if the rules are set to reject action if the product does not pass the evaluation.
Deferred transactions are similar to the idea of separate transactions, except that the first one must end before the second one is processed. In the POS example, the database may record that inventory for a certain product has fallen below acceptable levels early in the day. With a deferred transaction, the re-ordering process would not be executed until close of business when final inventory levels are recorded.