The document discusses several topics related to advanced database applications including: 1. Active databases and triggers which allow specifying rules that automatically execute actions in response to events. 2. Temporal databases which incorporate time aspects into data organization and allow storing information about when events occur. 3. Multimedia databases which provide features for storing and querying different types of multimedia information like images, video, and audio.

2. Enhanced Data Models For Advanced Applications Chapter 24

3. Active Databases and Triggers Temporal Database Concepts Multimedia Databases Introduction to Deductive Databases Chapter Outline

4. 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: The event would be a database update operations, temporal events, or other kinds of external events. The condition determines whether the rule action should be executed. The action is a sequence of SQL statements, transactions, or an external program that will be automatically executed. Active Databases and Triggers

5. 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. Active Databases and Triggers

6. 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: Inserting new employee tuples. Changing the salary of existing employees. Changing the assignment of existing employees from one department to another. Deleting (one or more) employee tuples. Active Databases and Triggers

7. FIGURE 24.2 Specifying active rules as triggers in Oracle notation. Triggers for automatically maintaining the consistency of TOTAL_SAL of DEPARTMENT. Active Databases and Triggers

8. 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. Active Databases and Triggers

9. 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. Active Databases and Triggers

10. FIGURE 24.3 A syntax summary for specifying triggers in the Oracle system (main options only). Active Databases and Triggers

11. 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

12. 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 . Design Issues for Active Databases

13. Three main possibilities for rule consideration: 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 forms Before executing the trigger event. After executing the trigger event. Instead of executing the trigger event. Deferred consideration: the condition is evaluated at the end of transaction that include the trigger event. Detached consideration: the condition is evaluated as a separate transaction. Design Issues for Active Databases

14. Difficulties with using active rules: To verify that a set of rules is consistent. To guarantee termination of a set of rules under all circumstances. FIGURE 24.4 An example to illustrate the termination problem for active rules. Design Issues for Active Databases

15. 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

16. 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 Temporal Database Concepts

17. 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. Temporal Database Concepts

18. 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. Temporal Database Concepts

19. FIGURE 24.7 Different types of temporal relational databases. Valid time database schema. Transaction time database schema. Bitemporal database schema. Temporal Database Concepts

20. 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. Temporal Database Concepts

21. 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. Temporal Database Concepts

22. FIGURE 24.8 Some tuple versions in the valid time relations EMP_VT and DEPT_VT. Temporal Database Concepts

23. 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. Temporal Database Concepts

24. FIGURE 24.10 Possible ODL schema for a temporal valid time Employee_VT object class using attribute versioning Temporal Database Concepts

25. 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. Multimedia Databases

26. Typical types of spatial queries: 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). Nearest neighbor query: finds an object of a particular type that is closest to a given location (e.g., finds the nearest shopping center). 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). Multimedia Databases

27. 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

28. 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. Multimedia Databases

29. Two main approaches to content-based retrieval: Automatic analysis: uses different techniques depending on the type of multimedia source (e.g., image, text, video, or audio). 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. Multimedia Databases

30. 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

31. 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: 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). 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

32. 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

33. 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. Prolog/Datalog Notation

34. 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. Prolog/Datalog Notation

35. FIGURE 24.11 (a) Prolog notation. (b) The supervisory tree. Prolog/Datalog Notation

36. A program contains a number of built-in predicates. Two main types of built-in predicates: The binary comparison predicates <, <=, >, >= (corresponding to less, less_or_equal, greater, greater_or_equal) over ordered domains. 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(a 1 , a 2 , …, a n ), where p is the predicate name and n (the arity or degree of p) is the number of arguments. Prolog/Datalog Notation

37. 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. Prolog/Datalog Notation

38. Two interpretation of rules: Proof-theoretic: considers the facts and rules to be true statements, or axioms. Facts are ground axioms –have no variables Rules are deductive axioms –can deduce new facts. 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. Prolog/Datalog Notation

39. FIGURE 24.12 Proving a new fact. Prolog/Datalog Notation

40. 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: Fact-defined predicates ( or relations): listing all the combinations of values (the tuples) that make the predicate true. 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. Prolog/Datalog Notation

41. FIGURE 24.14 Fact predicates for part of the database from Figure 5.6. Prolog/Datalog Notation

42. FIGURE 24.15 Rule-defined predicates. Prolog/Datalog Notation

43. 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. Prolog/Datalog Notation

44. FIGURE 24.16 Predicates for illustrating relational operations. Prolog/Datalog Notation