An active database performs functions based on specific inputs and predefined relationships. It is event-driven and can execute immediate, separate, or deferred transactions. Examples include automatic bill payments and POS systems that reorder products based on inventory levels.
An active database is an automated interface that performs certain functions depending on specific inputs of information. Programmers and administrators can manipulate active database systems to execute transactions based on predefined relationships. Similar to the idea of cause and effect, some of these relationships or questions are referred to as “mating.” Within the database design, there are parameters that specify what information will be shared and with whom it will be shared.
The main difference between a conventional database and an active one is that something happens as a result of something else. Automatic bill payments are an example of an active database. A bank customer can instruct his or her institution to pay a payee a specified amount on a specific date each month. Upon reaching the indicated date, electronic payments are automatically sent to the beneficiaries 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 can automatically reorder product for a retail store once it receives information that the current inventory has dropped to a predefined amount. Depending on how the database parameters are set, the actual reordering can happen immediately, as a separate transaction, or be deferred.
Immediate transactions occur together with the triggering events. For example, a POS system can reorder product by universal product code (UPC) or stock holding unit (SKU). It can process inventory levels and order transactions at the same time. Many mass retailers operate with this type of active database that receives continuous input from a variety of sources, including sales and reception personnel.
Separate transactions are set to occur at different times. Typically, the database is designed to look at the triggering event and it may need to be matched against additional rules to take an action. For example, a retailer’s POS system may be triggered by low inventory, but the action taken may depend on whether product is discontinued or if an item is supplied through a vendor. The database may fail to process an order if the rules are set to deny action if the product fails the evaluation.
Deferred transactions are similar to the idea of separate transactions, except that the first must finish before the second is processed. In the POS example, the database can record that the inventory of a particular product fell below acceptable levels at the start of the day. With a deferred transaction, the reordering process would not run until the close of business, when the final inventory levels are posted.
Protect your devices with Threat Protection by NordVPN
