Chapter24

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition


Enhanced Data Models For AdvancedApplications

Chapter 24


Active Databases and Triggers

Temporal Database Concepts

Multimedia Databases

Introduction to Deductive Databases

Chapter Outline


Triggers is a technique for specifying certain types of active rules.

The Event-Condition-Action (ECA) is a model for specifying active database rules. A rule in ECA model has three components:

1) The event would be a database update operations, temporal events, or other kinds of external events.

2) The condition determines whether the rule action should be executed.

3) The action is a sequence of SQL statements, transactions, or an external program that will be automatically executed.



Example: Consider a simplified version of the Company database

In this version, the TOTAL_SAL attribute is a derived attribute, whose value should be the sum of the salaries of all employees who are assigned to the particular department.



Maintaining the correct value for TOTAL_SAL can be done via an active rule. The events that may cause a change in the value of TOTAL_SAL are:

1) Inserting new employee tuples.

2) Changing the salary of existing employees.

3) Changing the assignment of existing employees from one department to another.

4) Deleting (one or more) employee tuples.



FIGURE 24.2Specifying active rules as triggers in Oracle notation. (a) Triggers for automatically maintaining the consistency of TOTAL_SAL of DEPARTMENT.



FIGURE 24.2 (continued)Specifying active rules as triggers in Oracle notation. (b) Trigger for comparing an employee’s salary with that

of his or her supervisor.



The optional FOR EACH ROW clause is known as a row-level trigger (i.e., the rule is triggered separately for each tuple).

If FOR EACH ROW clause was left out, the trigger would be known as a statement-level trigger (i.e., the rule would be triggered once for each triggering statement).

The keywords NEW and OLD can only be used with row-level triggers.



FIGURE 24.3A syntax summary for specifying triggers in the Oracle

system (main options only).



The first issue concerns, activation, deactivation, and grouping of rules.

The activate command will make the rule active again.

The deactivate command will make the trigger event not be triggered.

The delete command deletes the rule from the system.

The rule set option can be used to group rules (so, the whole set of rules can be activated, deactivated, or dropped).

The PROCESS RULES command can triggers a rule or rule set.

Design Issues for Active Databases


The second issue concerns whether the triggered action should be executed before, after, or concurrently with the trigger event.

A related issue is whether the action being executed should be considered as a separate action or whether it should be part of the same transaction that triggered the rule.

The rule condition evaluation is also known as rule consideration.



Three main possibilities for rule consideration:

1) Immediate consideration: the condition is evaluated as part of the same transaction as the trigger event, and is evaluated immediately; in one of the following formsa) Before executing the trigger event.

b) After executing the trigger event.

c) Instead of executing the trigger event.

2) Deferred consideration: the condition is evaluated at the end of transaction that include the trigger event.

3) Detached consideration: the condition is evaluated as a separate transaction.



Difficulties with using active rules:1) To verify that a set of rules is consistent.2) To guarantee termination of a set of rules under

all circumstances.

FIGURE 24.4 An example to illustrate the termination problem for active rules.



To allow notification of certain conditions that occur (e.g., to monitor the temperature of an industrial furnace).

To enforce integrity constraints by specifying the types of events that may cause the constraints to be violated.

Automatic maintenance of derived data (e.g., the derived attribute TOTAL_SAL in the simplified version of Company schema).

Potential applications for Active Databases


Temporal databases encompass all database applications that require some aspect of time when organizing their information (e.g., reservation system in hotels, airline, etc.).

For temporal databases, time is considered to be an ordered sequences of points (e.g., seconds, minutes, day, etc.).

Is SQL2, the temporal data types include DATE, TIME, TIMESTAMP, INTERVAL, and PERIOD



A temporal database will store information concerning when certain events occur.

Types of temporal information:Point events: associated in the database with a single time point (e.g., 15/08/1998).Duration events: associated in the database with a specific time period (e.g., [15/08/1998, 15/08/2000]).

An interpretation of a temporal database in which the associated time with their events is a valid time in the real world, is known as a valid time database.



An interpretation of a temporal database in which the associated time with their events is the value of the system time clock, is known as a transaction time database.

Incorporating time in relational databases can be done by adding attributes VST (Valid_START_TIME) and VET (VALID_END_TIME) into an ordinary relation.

Each tuple, V, represents a version of the entity member that is valid in the interval [V.VST, V.VET].

The current version has a special value, now.



FIGURE 24.7 Different types of temporal relational databases.

(a) Valid time database schema. (b) Transaction time database schema. (c) Bitemporal database schema.



The special value, now, is a temporal variable that implicitly represents the current time as time progresses.

In order to update a tuple, a new version is created and the current version is closed (by changing its VET to the end time).

In proactive update, the database is updated before it becomes effective in the real world.

In retroactive update, the database is updated after it becomes effective in the real world.



To deleting a tuple the current version is closed.

To insert a new entity member, create the first tuple version and make it the current version (i.e., VST being the effective time, and VET= new).

Note: in a valid time relation, the nontemporal key, such as SSN in EMPLOYEE relation, is no longer unique in each version. The new relation key for EMP_VT is a combination of the nontemporal key and the valid start time attribute VST.



FIGURE 24.8Some tuple versions in the valid time relations EMP_VT

and DEPT_VT.



Attributes that change over time are called time-varying attributes.

Attributes that do not change over time are called non-time-varying attributes.

In tuple versioning approach, whenever an attribute value in changed a whole new tuple version is created.

In attribute versioning approach , a single complex object is used to store all the temporal changes of the object.



FIGURE 24.10Possible ODL schema for a temporal valid time Employee_VT object class using attribute versioning



Spatial databases store objects that have spatial characteristics that describe them (e.g., cartographic databases store maps).

The main extensions that are needed for spatial databases are models that can interpret spatial characteristics.

The basic extensions needed are to include two dimensional geometric concepts such as points, lines, circles, polygons, and arcs.



Typical types of spatial queries:

1) Range query: finds the objects of a particular type that are within a given spatial area (e.g., finds all hospitals in a given suburb or city).

2) Nearest neighbor query: finds an object of a particular type that is closest to a given location (e.g., finds the nearest shopping center).

3) Spatial joins or overlays: joins the objects of two types based on some spatial conditions (e.g., finds all homes that are within two km of a lake).



One of the best known technique, in order to answer spatial queries, is the use of R-trees and their variations.

R-trees group together objects that are in close spatial physical proximity on the same leaf nodes of a tree-structured index.

Other spatial storage structures include quadtrees and their variations.

Quadtrees divide each space into equally sized areas, and proceed with the subdivisions of each subspace to identify the positions of various objects.



Multimedia databases provide features that allow users to store and query different types of multimedia information (e.g., images, video clips, audio clips, and documents).

The main types of database queries involve locating multimedia sources that contain objects of interest. These types of queries are called content-based retrieval queries.

Identifying the contents of multimedia sources is a difficult and time-consuming task.



Two main approaches to content-based retrieval:

1) Automatic analysis: uses different techniques depending on the type of multimedia source (e.g., image, text, video, or audio).

2) Manual identification: depends on the objects and activities of interest in each multimedia source and on using this information to index the source.It requires a manual preprocessing phase where a person has to scan each multimedia source to identify and catalog the objects and activities it contains.



A database system that includes capabilities to define (deductive) rules, which can deduce or infer additional information from the facts that are stored in the database is called a deductive database.

Rules are specified through a declarative language –we specify what to achieve rather than how to achieve it.

The model used for deductive databases is related to the logic programming and the prolog language.

Deductive Databases


A variation of Prolog called Datalog is used to define rules declaratively in conjunction with an existing set of relations.

Two main types of specifications:

1) Facts: similar to the way relations are specified, except that it is not necessary to include the attribute names (note that a tuple in a relation describes some real-world facts).

2) Rules: similar to relational views –that are not actually stored but can be formed from the facts by applying inference mechanisms based on the rule specifications.

Deductive Databases


A logic program can be thought of:

A set of facts (assuming that these are all the fact in our modeled mini-world)

A set of permissible deductions (proof rules)

A method of deducting

A goal to prove (or a query to answer)

An important difference between rules and facts is that, rules specify things that are true if some conditions are satisfied.

Prolog/Datalog Notation


A predicate has an implicit meaning and a fixed number of arguments.

If the arguments are all constant values, the predicate states a fact.

If the arguments contains variables, then it is either a query or as part of a rule or constraint.

Constant values in a predicate are either numeric or strings – stating with lowercase letters.

Variable names always start with an uppercase letter.



A rule is of the form head :- body, where

The head or left-hand side (LHS) or conclusion is a single predicate.

The body or right-had side (RHS) or premise consists of one or more predicates.

A predicate with constants as arguments is called ground or an instantiated predicate.



FIGURE 24.11 (a) Prolog notation. (b) The supervisory tree.



A program contains a number of built-in predicates. Two main types of built-in predicates:

1) The binary comparison predicates <, <=, >, >= (corresponding to less, less_or_equal, greater, greater_or_equal) over ordered domains.

2) The comparison predicates =, /= (corresponding to equal, not_equal) over unordered domains.

A program is built from basic objects called atomic formulas. Atomic formulas are literals of the form p(a1, a2, …, an), where p is the predicate name and n (the arity or degree of p) is the number of arguments.



A literal is either an atomic formula (in this case it is called a positive literal), or it is an atomic formula preceded by not (in this case it is called a negative literal).

Prolog/Datalog has an internal inference engine that can be used to process and compute the results of queries.

Prolog inference engine return one result to the query at a time, but Datalog returns results set-at-a-time.



Two interpretation of rules:1) Proof-theoretic: considers the facts and rules

to be true statements, or axioms.a) Facts are ground axioms –have no variables

b) Rules are deductive axioms –can deduce new facts.

2) Model-theoretic: assigns to a predicate every possible combination of values as arguments and specifies the combination of the arguments that make the predicate true.

An interpretation is called a model for a specific set of rules if the rules are always true under that interpretation.



FIGURE 24.12Proving a new fact.



A model is called minimal model for a set of rules if we cannot change any fact from true to false and still get a model for these rules.

Two main method of defining the truth values of predicates in Datalog programs:

1) Fact-defined predicates (or relations): listing all the combinations of values (the tuples) that make the predicate true.

2) Rule-defined predicates (or views): being the LHS of one or more Datalog rules. They correspond to virtual relations whose content can be inferred by the inference engine.



FIGURE 24.14Fact predicates for part of the database from Figure 5.6.



FIGURE 24.15 Rule-defined predicates.



Many operations of the relational algebra can be specified in the form of Datalog rules.

We do not need to specify the attribute names.

The arity (degree) of each predicate and the domain (data type) of each attribute is important for operations such as UNION, INTERSECTION, and JOIN.



FIGURE 24.16 Predicates for illustrating relational operations.


Date post:	18-Jan-2015
Category:	Documents
Upload:	gourab87
View:	1,800 times
Download:	1 times

Chapter24

Documents