Chapter24

3,857 views

Published on

Navate Database Management system

1 Comment
10 Likes
Statistics
Notes
No Downloads
Views
Total views
3,857
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
297
Comments
1
Likes
10
Embeds 0
No embeds

No notes for slide

Chapter24

  1. 2. <ul><li>Enhanced </li></ul><ul><li>Data Models </li></ul><ul><li>For </li></ul><ul><li>Advanced </li></ul><ul><li>Applications </li></ul>Chapter 24
  2. 3. <ul><li>Active Databases and Triggers </li></ul><ul><li>Temporal Database Concepts </li></ul><ul><li>Multimedia Databases </li></ul><ul><li>Introduction to Deductive Databases </li></ul>Chapter Outline
  3. 4. <ul><li>Triggers is a technique for specifying certain types of active rules. </li></ul><ul><li>The Event-Condition-Action (ECA) is a model for specifying active database rules. A rule in ECA model has three components: </li></ul><ul><ul><li>The event would be a database update operations, temporal events, or other kinds of external events. </li></ul></ul><ul><ul><li>The condition determines whether the rule action should be executed. </li></ul></ul><ul><ul><li>The action is a sequence of SQL statements, transactions, or an external program that will be automatically executed. </li></ul></ul>Active Databases and Triggers
  4. 5. <ul><li>Example: Consider a simplified version of the Company database </li></ul><ul><li>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. </li></ul>Active Databases and Triggers
  5. 6. <ul><li>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: </li></ul><ul><ul><li>Inserting new employee tuples. </li></ul></ul><ul><ul><li>Changing the salary of existing employees. </li></ul></ul><ul><ul><li>Changing the assignment of existing employees from one department to another. </li></ul></ul><ul><ul><li>Deleting (one or more) employee tuples. </li></ul></ul>Active Databases and Triggers
  6. 7. <ul><li>FIGURE 24.2 </li></ul><ul><li>Specifying active </li></ul><ul><li>rules as triggers </li></ul><ul><li>in Oracle notation. </li></ul><ul><li>Triggers for </li></ul><ul><li>automatically </li></ul><ul><li>maintaining the </li></ul><ul><li>consistency of </li></ul><ul><li>TOTAL_SAL of </li></ul><ul><li>DEPARTMENT. </li></ul>Active Databases and Triggers
  7. 8. <ul><li>FIGURE 24.2 (continued) </li></ul><ul><li>Specifying active rules as triggers in Oracle notation. </li></ul><ul><li>(b) Trigger for comparing an employee’s salary with that of his or her supervisor. </li></ul>Active Databases and Triggers
  8. 9. <ul><li>The optional FOR EACH ROW clause is known as a row-level trigger (i.e., the rule is triggered separately for each tuple). </li></ul><ul><li>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). </li></ul><ul><li>The keywords NEW and OLD can only be used with row-level triggers. </li></ul>Active Databases and Triggers
  9. 10. <ul><li>FIGURE 24.3 </li></ul><ul><li>A syntax summary for specifying triggers in the Oracle system (main options only). </li></ul>Active Databases and Triggers
  10. 11. <ul><li>The first issue concerns, activation, deactivation , and grouping of rules. </li></ul><ul><ul><li>The activate command will make the rule active again. </li></ul></ul><ul><ul><li>The deactivate command will make the trigger event not be triggered. </li></ul></ul><ul><ul><li>The delete command deletes the rule from the system. </li></ul></ul><ul><ul><li>The rule set option can be used to group rules (so, the whole set of rules can be activated, deactivated, or dropped). </li></ul></ul><ul><ul><li>The PROCESS RULES command can triggers a rule or rule set. </li></ul></ul>Design Issues for Active Databases
  11. 12. <ul><li>The second issue concerns whether the triggered action should be executed before, after , or concurrently with the trigger event. </li></ul><ul><li>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. </li></ul><ul><li>The rule condition evaluation is also known as rule consideration . </li></ul>Design Issues for Active Databases
  12. 13. <ul><li>Three main possibilities for rule consideration: </li></ul><ul><ul><li>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 </li></ul></ul><ul><ul><ul><li>Before executing the trigger event. </li></ul></ul></ul><ul><ul><ul><li>After executing the trigger event. </li></ul></ul></ul><ul><ul><ul><li>Instead of executing the trigger event. </li></ul></ul></ul><ul><ul><li>Deferred consideration: the condition is evaluated at the end of transaction that include the trigger event. </li></ul></ul><ul><ul><li>Detached consideration: the condition is evaluated as a separate transaction. </li></ul></ul>Design Issues for Active Databases
  13. 14. <ul><li>Difficulties with using active rules: </li></ul><ul><ul><li>To verify that a set of rules is consistent. </li></ul></ul><ul><ul><li>To guarantee termination of a set of rules under all circumstances. </li></ul></ul><ul><ul><li>FIGURE 24.4 </li></ul></ul><ul><ul><li>An example to illustrate the termination problem for active rules. </li></ul></ul>Design Issues for Active Databases
  14. 15. <ul><li>To allow notification of certain conditions that occur (e.g., to monitor the temperature of an industrial furnace). </li></ul><ul><li>To enforce integrity constraints by specifying the types of events that may cause the constraints to be violated. </li></ul><ul><li>Automatic maintenance of derived data (e.g., the derived attribute TOTAL_SAL in the simplified version of Company schema). </li></ul>Potential applications for Active Databases
  15. 16. <ul><li>Temporal databases encompass all database applications that require some aspect of time when organizing their information (e.g., reservation system in hotels, airline, etc.). </li></ul><ul><li>For temporal databases, time is considered to be an ordered sequences of points (e.g., seconds, minutes, day, etc.). </li></ul><ul><li>Is SQL2, the temporal data types include DATE, TIME, TIMESTAMP, INTERVAL, and PERIOD </li></ul>Temporal Database Concepts
  16. 17. <ul><li>A temporal database will store information concerning when certain events occur. </li></ul><ul><li>Types of temporal information: </li></ul><ul><ul><li>Point events: associated in the database with a single time point (e.g., 15/08/1998) . </li></ul></ul><ul><ul><li>Duration events: associated in the database with a specific time period (e.g., [15/08/1998, 15/08/2000]). </li></ul></ul><ul><li>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. </li></ul>Temporal Database Concepts
  17. 18. <ul><li>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. </li></ul><ul><li>Incorporating time in relational databases can be done by adding attributes VST (Valid_START_TIME) and VET (VALID_END_TIME) into an ordinary relation. </li></ul><ul><li>Each tuple, V, represents a version of the entity member that is valid in the interval [V.VST, V.VET]. </li></ul><ul><li>The current version has a special value, now. </li></ul>Temporal Database Concepts
  18. 19. <ul><li>FIGURE 24.7 Different types of temporal relational databases. </li></ul><ul><li>Valid time database schema. </li></ul><ul><li>Transaction time database schema. </li></ul><ul><li>Bitemporal database schema. </li></ul>Temporal Database Concepts
  19. 20. <ul><li>The special value, now , is a temporal variable that implicitly represents the current time as time progresses. </li></ul><ul><li>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). </li></ul><ul><li>In proactive update , the database is updated before it becomes effective in the real world. </li></ul><ul><li>In retroactive update , the database is updated after it becomes effective in the real world. </li></ul>Temporal Database Concepts
  20. 21. <ul><li>To deleting a tuple the current version is closed. </li></ul><ul><li>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). </li></ul><ul><li>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. </li></ul>Temporal Database Concepts
  21. 22. <ul><li>FIGURE 24.8 </li></ul><ul><li>Some tuple versions in the valid time relations EMP_VT and DEPT_VT. </li></ul>Temporal Database Concepts
  22. 23. <ul><li>Attributes that change over time are called time-varying attributes. </li></ul><ul><li>Attributes that do not change over time are called non-time-varying attributes . </li></ul><ul><li>In tuple versioning approach , whenever an attribute value in changed a whole new tuple version is created. </li></ul><ul><li>In attribute versioning approach , a single complex object is used to store all the temporal changes of the object. </li></ul>Temporal Database Concepts
  23. 24. <ul><li>FIGURE 24.10 </li></ul><ul><li>Possible ODL </li></ul><ul><li>schema for a </li></ul><ul><li>temporal valid </li></ul><ul><li>time </li></ul><ul><li>Employee_VT </li></ul><ul><li>object class </li></ul><ul><li>using attribute </li></ul><ul><li>versioning </li></ul>Temporal Database Concepts
  24. 25. <ul><li>Spatial databases store objects that have spatial characteristics that describe them (e.g., cartographic databases store maps). </li></ul><ul><li>The main extensions that are needed for spatial databases are models that can interpret spatial characteristics. </li></ul><ul><li>The basic extensions needed are to include two dimensional geometric concepts such as points, lines, circles, polygons, and arcs. </li></ul>Multimedia Databases
  25. 26. <ul><li>Typical types of spatial queries: </li></ul><ul><ul><li>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). </li></ul></ul><ul><ul><li>Nearest neighbor query: finds an object of a particular type that is closest to a given location (e.g., finds the nearest shopping center). </li></ul></ul><ul><ul><li>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). </li></ul></ul>Multimedia Databases
  26. 27. <ul><li>One of the best known technique, in order to answer spatial queries, is the use of R-trees and their variations. </li></ul><ul><li>R-trees group together objects that are in close spatial physical proximity on the same leaf nodes of a tree-structured index. </li></ul><ul><li>Other spatial storage structures include quadtrees and their variations. </li></ul><ul><li>Quadtrees divide each space into equally sized areas, and proceed with the subdivisions of each subspace to identify the positions of various objects. </li></ul>Multimedia Databases
  27. 28. <ul><li>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). </li></ul><ul><li>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. </li></ul><ul><li>Identifying the contents of multimedia sources is a difficult and time-consuming task. </li></ul>Multimedia Databases
  28. 29. <ul><li>Two main approaches to content-based retrieval: </li></ul><ul><ul><li>Automatic analysis: uses different techniques depending on the type of multimedia source (e.g., image, text, video, or audio). </li></ul></ul><ul><ul><li>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. </li></ul></ul>Multimedia Databases
  29. 30. <ul><li>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. </li></ul><ul><li>Rules are specified through a declarative language –we specify what to achieve rather than how to achieve it. </li></ul><ul><li>The model used for deductive databases is related to the logic programming and the prolog language. </li></ul>Deductive Databases
  30. 31. <ul><li>A variation of Prolog called Datalog is used to define rules declaratively in conjunction with an existing set of relations. </li></ul><ul><li>Two main types of specifications: </li></ul><ul><ul><li>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). </li></ul></ul><ul><ul><li>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. </li></ul></ul>Deductive Databases
  31. 32. <ul><li>A logic program can be thought of: </li></ul><ul><ul><li>A set of facts (assuming that these are all the fact in our modeled mini-world) </li></ul></ul><ul><ul><li>A set of permissible deductions (proof rules) </li></ul></ul><ul><ul><li>A method of deducting </li></ul></ul><ul><ul><li>A goal to prove (or a query to answer) </li></ul></ul><ul><li>An important difference between rules and facts is that, rules specify things that are true if some conditions are satisfied. </li></ul>Prolog/Datalog Notation
  32. 33. <ul><li>A predicate has an implicit meaning and a fixed number of arguments. </li></ul><ul><ul><li>If the arguments are all constant values, the predicate states a fact. </li></ul></ul><ul><ul><li>If the arguments contains variables, then it is either a query or as part of a rule or constraint. </li></ul></ul><ul><ul><li>Constant values in a predicate are either numeric or strings – stating with lowercase letters. </li></ul></ul><ul><ul><li>Variable names always start with an uppercase letter. </li></ul></ul>Prolog/Datalog Notation
  33. 34. <ul><li>A rule is of the form head :- body , where </li></ul><ul><ul><li>The head or left-hand side (LHS) or conclusion is a single predicate. </li></ul></ul><ul><ul><li>The body or right-had side (RHS) or premise consists of one or more predicates. </li></ul></ul><ul><li>A predicate with constants as arguments is called ground or an instantiated predicate. </li></ul>Prolog/Datalog Notation
  34. 35. <ul><li>FIGURE 24.11 (a) Prolog notation. (b) The supervisory tree. </li></ul>Prolog/Datalog Notation
  35. 36. <ul><li>A program contains a number of built-in predicates. Two main types of built-in predicates: </li></ul><ul><ul><li>The binary comparison predicates <, <=, >, >= (corresponding to less, less_or_equal, greater, greater_or_equal) over ordered domains. </li></ul></ul><ul><ul><li>The comparison predicates =, /= (corresponding to equal, not_equal) over unordered domains. </li></ul></ul><ul><li>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. </li></ul>Prolog/Datalog Notation
  36. 37. <ul><li>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 ). </li></ul><ul><li>Prolog/Datalog has an internal inference engine that can be used to process and compute the results of queries. </li></ul><ul><li>Prolog inference engine return one result to the query at a time, but Datalog returns results set-at-a-time. </li></ul>Prolog/Datalog Notation
  37. 38. <ul><li>Two interpretation of rules: </li></ul><ul><ul><li>Proof-theoretic: considers the facts and rules to be true statements, or axioms. </li></ul></ul><ul><ul><ul><li>Facts are ground axioms –have no variables </li></ul></ul></ul><ul><ul><ul><li>Rules are deductive axioms –can deduce new facts. </li></ul></ul></ul><ul><ul><li>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. </li></ul></ul><ul><li>An interpretation is called a model for a specific set of rules if the rules are always true under that interpretation. </li></ul>Prolog/Datalog Notation
  38. 39. <ul><li>FIGURE 24.12 </li></ul><ul><li>Proving a new fact. </li></ul>Prolog/Datalog Notation
  39. 40. <ul><li>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. </li></ul><ul><li>Two main method of defining the truth values of predicates in Datalog programs: </li></ul><ul><ul><li>Fact-defined predicates ( or relations): listing all the combinations of values (the tuples) that make the predicate true. </li></ul></ul><ul><ul><li>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. </li></ul></ul>Prolog/Datalog Notation
  40. 41. <ul><li>FIGURE 24.14 </li></ul><ul><li>Fact predicates </li></ul><ul><li>for part of the </li></ul><ul><li>database from </li></ul><ul><li>Figure 5.6. </li></ul>Prolog/Datalog Notation
  41. 42. <ul><li>FIGURE 24.15 Rule-defined predicates. </li></ul>Prolog/Datalog Notation
  42. 43. <ul><li>Many operations of the relational algebra can be specified in the form of Datalog rules. </li></ul><ul><li>We do not need to specify the attribute names. </li></ul><ul><li>The arity (degree) of each predicate and the domain (data type) of each attribute is important for operations such as UNION, INTERSECTION, and JOIN. </li></ul>Prolog/Datalog Notation
  43. 44. <ul><li>FIGURE 24.16 </li></ul><ul><li>Predicates for </li></ul><ul><li>illustrating </li></ul><ul><li>relational </li></ul><ul><li>operations. </li></ul>Prolog/Datalog Notation

×