• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Chapter24
 

Chapter24

on

  • 1,485 views

Navate Database Management system

Navate Database Management system

Statistics

Views

Total Views
1,485
Views on SlideShare
1,485
Embed Views
0

Actions

Likes
0
Downloads
72
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Chapter24 Chapter24 Presentation Transcript

    •  
      • Enhanced
      • Data Models
      • For
      • Advanced
      • Applications
      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:
        • 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
      • 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
      • 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
      • 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
      • 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
      • 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
      • FIGURE 24.3
      • A syntax summary for specifying triggers in the Oracle system (main options only).
      Active Databases and Triggers
      • 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 .
      Design Issues for Active Databases
      • 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
      • 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
      • 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
      Temporal Database Concepts
      • 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
      • 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
      • FIGURE 24.7 Different types of temporal relational databases.
      • Valid time database schema.
      • Transaction time database schema.
      • Bitemporal database schema.
      Temporal Database Concepts
      • 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
      • 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
      • FIGURE 24.8
      • Some tuple versions in the valid time relations EMP_VT and DEPT_VT.
      Temporal Database Concepts
      • 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
      • FIGURE 24.10
      • Possible ODL
      • schema for a
      • temporal valid
      • time
      • Employee_VT
      • object class
      • using attribute
      • versioning
      Temporal Database Concepts
      • 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
      • 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
      • 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
      • 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
      • 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
      • 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:
        • 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
      • 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.
      Prolog/Datalog Notation
      • 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
      • FIGURE 24.11 (a) Prolog notation. (b) The supervisory tree.
      Prolog/Datalog Notation
      • 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
      • 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
      • 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
      • FIGURE 24.12
      • Proving a new fact.
      Prolog/Datalog Notation
      • 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
      • FIGURE 24.14
      • Fact predicates
      • for part of the
      • database from
      • Figure 5.6.
      Prolog/Datalog Notation
      • FIGURE 24.15 Rule-defined predicates.
      Prolog/Datalog Notation
      • 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
      • FIGURE 24.16
      • Predicates for
      • illustrating
      • relational
      • operations.
      Prolog/Datalog Notation