Unit V Emerging Trends in Databases Created by

Unit V Emerging Trends in Databases Created by: Faraz Bagwan 521003 ME Comp.

Content • Introduction • Temporal Databases • Spatial & Geographical Databases • Multimedia Databases • Mobility Databases

Temporal Database

Non-Temporal Databases • Non-Temporal databases i. e. DBMS, allow the storage of huge amounts of data. • This data is usually considered to be valid now. Past or future data is not stored. • Non-Temporal database provides abstract information, meaning, the data present is true but incomplete as time dimension is absent. • Example: Oracle, Sybase, Informix and O 2. Emp. ID 10 12 13 Name John George Ringo Department Sales Research Sales Salary 12000 10500 15500

Temporal Databases • Some data may be inherently historical ‒ e. g. , medical or judicial records • Temporal databases provide a uniform and systematic way of dealing with historical data. • By attaching a time period to the data, it becomes possible to store different database states. • A first step towards a temporal database thus is to timestamp the data. • There are mainly two different notions of time for temporal databases. 1. Valid time: denotes the time period during which a fact is true with respect to the real world. 2. Transaction time: is the time period during which a fact is stored in the database.

Temporal Databases Timestamp Valid Time Historical Database Transaction Time Rollback Database

Temporal Databases Emp. ID 10 10 10 11 12 13 Name John Paul George Ringo Department Research Sales Salary 11000 12000 10500 15500 Valid. Time. Start Valid. Time. End 1985 1990 1993 INF 1988 1995 1991 INF 1988 INF • The attributes Valid. Time. Start and Valid. Time. End actually represent a time interval which is closed at its lower bound and open at its upper bound. • The time period (1985 - 1990), employee John was working in the research department, having a salary of 11000. Then he changed to the sales department, still earning 11000. In 1993, he got a salary raise to 12000. The upper bound INF denotes that the tuple is valid until further notice. Note that it is now possible to store information about past states. • We see that Paul was employed from 1988 until 1995. In the corresponding non-temporal table, this information was (physically) deleted when Paul left the company.

Different Forms of Temporal Databases • The two different notions of time - valid time and transaction time allow the distinction of different forms of temporal databases. • A historical database stores data with respect to valid time. • A rollback database stores data with respect to transaction time. • A bi-temporal database stores data with respect to both valid time and transaction time. • Commercial DBMS are said to store only a single state of the real world, usually the most recent state. Such databases usually are called snapshot databases.

Different Forms of Temporal Databases Fig: SNAPSHOT DATABASE

Different Forms of Temporal Databases Fig: Bi. TEMPORAL DATABASE (Time. DB)

Spatial & Geographic databases

Spatial & geographic databases • A spatial database is a database that is optimized to store and query data that represents objects defined in a geometric space.

Spatial and Geographic Databases • Spatial databases store information related to spatial locations, and support efficient storage, indexing and querying of spatial data. • Special purpose index structures are important for accessing spatial data, and for processing spatial join queries. • Computer Aided Design (CAD) databases store design information about how objects are constructed E. g. : designs of buildings, aircraft, layouts of integrated-circuits • Geographic databases store geographic information (e. g. , maps): often called geographic information systems or GIS. 13

Representation of Geometric Information 14

Open. GIS • Open. GIS is a standard solution to process spatial data. • Out of the many standards in the Open. GIS, the one standard needed to understand/process the spatial DBMS is Simple Feature. • Simple Feature components: 1. Geometry Object Model (data type): Point, Line. String and Polygon 2. Spatial Operation, and 3. Coordinate System (two and three dimension).

Open. GIS

Open. GIS ‘Query’ and ‘analysis’ blocks are Spatial Operations. 17

Geographic Data I. Raster data consist of bit maps or pixel maps, in two or more dimensions. • Example 2 -D raster image: satellite image of cloud cover, where each pixel stores the cloud visibility in a particular area. • Additional dimensions might include the temperature at different altitudes at different regions, or measurements taken at different points in time. • Design databases generally do not store raster data. 18

Geographic Data II. Vector data are constructed from basic geometric objects: points, line segments, triangles, and other polygons in two dimensions, and cylinders, spheres, cuboids, and other polyhedrons in three dimensions. • Vector format often used to represent map data. • Roads can be considered as two-dimensional and represented by lines and curves. • Some features, such as rivers, may be represented either as complex curves or as complex polygons, depending on whether their width is relevant. • Features such as regions and lakes can be depicted as polygons. 19

Spatial Queries • Nearness queries request objects that lie near a specified location. • Nearest neighbor queries, given a point or an object, find the nearest object that satisfies given conditions. • Region queries deal with spatial regions. e. g. , ask for objects that lie partially or fully inside a specified region. • Queries that compute intersections or unions of regions. • Spatial join of two spatial relations with the location playing the role of join attribute. 20

Spatial Queries • Spatial data is typically queried using a graphical query language; results are also displayed in a graphical manner. • Graphical interface constitutes the front-end • Extensions of SQL with abstract data types, such as lines, polygons and bit maps, have been proposed to interface with back-end. • allows relational databases to store and retrieve spatial information • Queries can use spatial conditions (e. g. contains or overlaps). • queries can mix spatial and nonspatial conditions 21

Applications of Geographic Data • Examples of geographic data • map data for vehicle navigation • distribution network information for power, telephones, water supply, and sewage • Vehicle navigation systems store information about roads and services for the use of drivers: • Spatial data: e. g, road/restaurant/gas-station coordinates • Non-spatial data: e. g. , one-way streets, speed limits, traffic congestion • Global Positioning System (GPS) unit - utilizes information broadcast from GPS satellites to find the current location of user with an accuracy of tens of meters. • increasingly used in vehicle navigation systems as well as utility maintenance applications. 22

Multimedia Database

What is a Multimedia DBMS? • A multimedia database management system (MM-DBMS) is a framework that manages different types of data potentially represented in a wide diversity of formats on a wide array of media sources. • Like the traditional DBMS, MM-DBMS should address requirements: • Integration • Data items do not need to be duplicated for different programs • Data independence • Separate the database and the management from the application programs • Concurrency control • allows concurrent transactions MM Database 24

Requirements of Multimedia DBMS • Persistence • Data objects can be saved and re-used by different transactions and program invocations • Privacy • Access and authorization control • Integrity control • Ensures database consistency between transactions • Recovery • Failures of transactions should not affect the persistent data storage • Query support • Allows easy querying of multimedia data MM Database 25

Requirements of Multimedia DBMS (cont. ) • In addition, an MM-DBMS should: • have the ability to uniformly query data (media data, textual data) represented in different formats. • have the ability to simultaneously query different media sources and conduct classical database operations across them. query support • have the ability to retrieve media objects from a local storage device in a smooth jitter-free (i. e. continuous) manner. storage support • have the ability to take the answer generated by a query and develop a presentation of that answer in terms of audio-visual media. • have the ability to deliver this presentation in a way that satisfies various Quality of Service requirements. presentation and delivery support MM Database 26

Major Issues: Query Support • Allow easy query of multimedia data • What is query by content? • Can query be specified as a combination of media (examples) and text description? • How to handle different MM objects? • What query language should be used? • Allow efficient query of multimedia data • What algorithms can be used to efficiently retrieve media data on the basis of similarity? • How should we index the content of different MM objects? • How to provide traditional DBMS supports? MM Database 27

Major Issues: Storage Support • How do the following (standard) storage devices work? • disk systems • CD-ROM systems • tape systems and tape libraries • How is data laid out on such devices? • How do we design disk/CD-ROM/tape servers so as to optimally satisfy different clients concurrently when these clients execute the following operations • • playback rewind fast forward pause MM Database 28

Major Issues: Presentation & Delivery Support • How do we specify the content of multimedia presentations? • How do we specify the form (temporal/spatial layout) of this content? • How do we create a presentation schedule that satisfies these temporal/spatial presentation requirements? • How can we deliver a multimedia presentation to users when there is • a need to interact with other remote servers to assemble the presentation (or parts of it) • a bound on the buffer, bandwidth, load, and other resources available on the system • a mismatch between the host server's capabilities and the customers machine capabilities? • How can such presentations optimize Quality of Service (Qo. S)? MM Database 29

A Sample Multimedia Scenario • Consider a police investigation of a large-scale drug operation. This investigation may generate the following types of data • Video data captured by surveillance cameras that record the activities taking place at various locations. • Audio data captured by legally authorized telephone wiretaps. • Image data consisting of still photographs taken by investigators. • Document data seized by the police when raiding one or more places. • Structured relational data containing background information, back records, etc. , of the suspects involved. • Geographic information system data remaining geographic data relevant to the drug investigation being conducted. MM Database 30

Possible Queries Image Query (by example): • Police officer Rocky has a photograph in front of him. • He wants to find the identity of the person in the picture. • Query: “Retrieve all images from the image library in which the person appearing in the (currently displayed) photograph appears” Image Query (by keywords): • Police officer Rocky wants to examine pictures of “Big Spender”. • Query: "Retrieve all images from the image library in which “Big Spender” appears. " MM Database 31

Possible Queries (cont. ) Video Query: • Police officer Rocky is examining a surveillance video of a particular person being fatally assaulted by an assailant. However, the assailant's face is occluded and image processing algorithms return very poor matches. Rocky thinks the assault was by someone known to the victim. • Query: “Find all video segments in which the victim of the assault appears. ” • By examining the answer of the above query, Rocky hopes to find other people who have previously interacted with the victim. Heterogeneous Multimedia Query: • Find all individuals who have been photographed with “Big Spender” and who have been convicted of attempted murder in South China and who have recently had electronic fund transfers made into their bank accounts from ABC Corp. MM Database 32

MM Database Architectures Based on Principle of Autonomy • Each media type is organized in a media-specific manner suitable for that media type • Need to compute joins across different data structures • Relatively fast query processing due to specialized structures • The only choice for legacy data banks MM Database 33

MM Database Architectures (cont. ) Based on Principle of Uniformity • A single abstract structure to index all media types • Abstract out the common part of different media types (difficult!) metadata • One structure - easy implementation • Annotations for different media types MM Database 34

MM Database Architectures (cont. ) Based on Principle of Hybrid Organization • A hybrid of the first two. Certain media types use their own indexes, while others use the "unified" index • An attempt to capture the advantages of the first two • Joins across multiple data sources using their native indexes MM Database 35

Organizing Multimedia Data Based on the Principle of Uniformity • Consider the following statements about media data and they may be made by a human or may be produced by the output of an image/video/text content retrieval engine. • The image photol. gif shows Jane Shady, “Big Spender” and an unidentified third person, in Sheung Shui. The picture was taken on January 5, 1997. • The video-clip videol. mpg shows Jane Shady giving “Big Spender” a briefcase (in frames 50 -100). The video was obtained from surveillance set up at Big Spender’s house in Kowloon Tong, in October, 1996. • The document bigspender. txt contains background information on Big Spender, a police’s file. MM Database 36

Metadata and Media Abstraction • All these statements are Meta-data statements. • Associate, with each media object oi, some meta-data, md(oi) • If our archive contains objects o 1, . . . , on, then index the meta data md(o 1), . . . , md(on) in a way that provides efficient ways of implementing the expected accesses that users will make. • We expect to take use of a single data structure to represent metadata • This can be achieved via media abstractions • Media abstractions are mathematical structure representing such media content. Let’s consider a simple multimedia database system (SMDS) hereafter! MM Database 37

Querying SMDSs (Uniform Representation) Querying SMDS based on top of SQL. Basic functions include: • Find. Type(Obj): This function takes a media object Obj as input, and returns the output type of the object. For example, Find. Type(iml. gif) = gif. Find. Type(moviel. mpg) = mpg. • Find. Obj. With. Feature(f): This function takes a feature f as input and returns as output, the set of all media objects that contain that feature. For example, Find. Obj. With. Feature(john)= {iml. gif, im 2. gif, im 3. gif, videol. mpg: [1, 5]}. Find. Obj. With. Feature(mary)= {videol. mpg: [1, 5], videol. mpg: [15, 50]}. MM Database 38

Querying SMDSs (Uniform Representation) (cont. ) • Find. Obj. With. Featureand. Attr(f, a, v): This function takes as input, a feature f, an attribute name a associated with that feature, and a value v. It returns as output, all objects obj that contain the feature and such the value of the attribute a in object obj is v. E. g. • Find. Obj. With. Featureand. Attr(Big Spender, suit, blue): This query asks to find all media objects in which Big Spender appears in a blue suit. • Find. Featuresin. Obj(Obj): This query asks to find all features that occur within a given media object. It returns as output, the set of all such features. For example, • Find. Featuresin. Obj (iml. gif): This asks for all features within the image file iml. gif. It may return as output, the objects John, and Lisa. • Find. Featuresin. Obj(videol. mpg: [1, 15]): This asks for all features within the first 15 frames of the video file videol. mpg. The answer may include objects such as Mary and John. MM Database 39

Querying SMDSs (Uniform Representation) (cont. ) • Find. Featuresand. Attrin. Obj(Obj): This query is exactly like the previous query except that it returns as output, a relation having the scheme (Feature, Attribute, Value) where the triple (f, a, v) occurs in the output relation iff feature f occurs in the query Find. Featuresin. Obj(Obj) and feature f's attribute a is defined and has value v. For example, • Find. Featuresand. Attrin. Obj(iml. gif) may return as answer, the table MM Database 40

Querying SMDS by SMDS-SQL • All ordinary SQL statements are SMDS-SQL statements. In addition: • The SELECT statement may contain media-entities. A media entity is defined as follows: • If m is a continuous media object, and i, j are integers, then m: [i, j] is a media-entity denoting the set of all frames of media object m that lie between (and inclusive of) segments i, j. • If m is not a continuous media object, them m is a media entity. • If m is a media entity, and a is an attribute of m, then m. a is a mediaentity. • The FROM statement may contain entries of the form <media> <source> <M> which says that only media-objects associate with the named media type and named data source are to be considered when processing the query, and that M is a variable ranging over such media objects. MM Database 41

Querying SMDS by SMDS-SQL (cont) • The WHERE statement allows (in addition to standard SQL constructs), expressions of the form term IN func_ca 11 where • term is either a variable (in which case it ranges over the output type of func_call) or an object having the same output type as func_call and • func_call is any of the five function calls stated above MM Database 42

Sample SMDS-SQL Statements • Find all image/video objects containing both Jane Shady and Big Spender. This can be expressed as the SMDS-SQL query: SELECT M FROM smds source 1 M WHERE (Find. Type(M)=Video OR Find. Type(M)=Image) AND M IN Find. Obj. With. Feature(Big Spender) AND M IN Find. Obj. With. Feature(Jane Shady). MM Database 43

Sample SMDS-SQL Statements (cont. ) • Find all image/video objects containing Big Spender wearing a purple suit. This can be expressed as the SMDS-SQL query: SELECT M FROM smds sourcel M WHERE (Find. Type(M)=Video OR Find. Type(M)=Image) AND M IN Find. Obj. With. Featureand. Attr(Big Spender, suit, purple) MM Database 44

Sample SMDS-SQL Statements (cont. ) • Find all images containing Jane Shady and a person who appears in a video with Big Spender. Unlike the preceding queries this query involves computing a "join" like operations across different data domains. In order to do this, we use existential variables such as the variable "Person" in the query below, which is used to refer to the existence of an unknown person whose identity is to be determined. SELECT FROM WHERE M, Person smds sourcel M, M 1 (Find. Type(M)=Image) AND (Find. Type(M 1)=Video) AND M IN Find. Obj. With. Feature(Jane Shady) AND M 1 IN Find. Obj. With. Feature(Big Spender) AND Person IN Find. Featuresin. Obj (M 1) AND Person Jane Shady AND Person Big Spender MM Database 45

Querying SMDSs (Hybrid Representation) • SMDS-SQL may be used to query multimedia objects which are stored in the uniform representation. • “What is it about the hybrid representation that causes our query language to change? ” • In the uniform representation, all the data sources being queried are SMDSs, while in the hybrid representation, different (non. SMDS) representations may be used. • A hybrid media representation basically consists of two parts - a set of media objects that use the uniform representation (which we have already treated in the preceding section), and a set of media-types that use their own specialized access structures and query language. MM Database 46

Querying SMDSs (Uniform Representation) (cont. ) • To extend SMDS-SQL to Hybrid-Multimedia SQL (HM-SQL for short), we need to do two things: • First, HM-SQL, must have the ability to express queries in each of the specialized languages used by these non-SMDS sources • Second, HM-SQL, must have the ability to express “joins” and other similar binary algebraic operations between SMDS sources and non-SMDS sources MM Database 47

HM-SQL is exactly like SQL except that the SELECT, FROM, WHERE clauses are extended as follows: • the SELECT and FROM clauses are treated in exactly the same way as in SMDS-SQL. • The WHERE statement allows (in addition to standard SQL constructs) expressions of the form term IN MS: func_call where 1. term is either a variable (in which case it ranges over the output type of func_call) or an object having the same output type as func_call as defined in the media source MS and MM Database 48

HM-SQL (cont. ) 2. either MS=SMDS and func_call is one of the five SMDS functions described earlier, or 3. MS is not an SMDS-media source. , and func_call is a query in QL(MS). • Thus, there are 2 differences between HM-SQL and SMDS-SQL: 1. func_calls occurring in the WHERE clause must be explicitly annotated with the media-source involved, and 2. queries from the query languages of the individual (non. SMDS) media-source implementations may be embedded within an HM-SQL query. This latter feature makes HM-SQL very powerful indeed as it is, in principle, able to express queries in other, third-party, or legacy media implementations. MM Database 49

Sample HM-SQL Statements • Find all video clips containing Big Spender, from both the video sources, videol, and video 2, where the former is implemented via an SMDS and the latter is implemented via a legacy video database: SELECT FROM WHERE M smds video 1, videodb video 2 M IN smds: Find. Obj. With. Feature(Big Spender) OR M IN videodb: Find. Video. With. Object(Big Spender) MM Database 50

Sample HM-SQL Statements (cont. ) • Find all people seen with Big Spender in either video 1, video 2, or idb. (SELECT FROM WHERE P 1 smds video 1 V 1 IN smds: Find. Obj. With. Feature(Big Spender)AND P 1 IN smds: Find. Featuresin. Obj(V 1) AND Pl Big Spender) UNION P 2 videodb video 2 V 2 IN videodb: Find. Video. With. Object(Big Spender) AND P 2 IN videodb: Find. Objectsin. Video(V 2) AND P 2 Big Spender) UNION P 3 imagedb idb I 3 IN imagedb: getpic(Big Spender) AND P 3 IN imagedb: getfeatures(I 3) AND P 3 Big Spender) MM Database 51

Connective Summary When faced with the problem of creating a multimedia database, we must take into account the following two questions: • What kinds of media data should this MM database provide access to? • Do legacy algorithms already exist (and are they available) to index this data reliably and accurately using content-based indexing methods? determine the use of uniform representation or hybrid representation !! In the text, the author has also shown how to index SMDSs with enhanced inverted indices (an easyto-implement mechanism for indexing large document bases). MM Database 52

Mobility Databases

Mobility Databases • The rapid advancements of wireless communication technology and computer miniaturizing technology have enabled users to utilize computing resources anywhere in the computer network. • Some Mobile Trends include, ‒ The notebook and laptop Computers ‒ low-cost wireless digital communication devices, ‒ wireless local-area networks (wifi, hotspot), ‒ cellular digital packet networks, and other technologies

Mobile DBMS • Some of the commercially available Mobile relational Database systems are: i. IBM's DB 2 Everywhere 1. 0 ii. Oracle Lite iii. Sybase's SQL

Wireless Computing Issues • Changing client location • Limited battery life • Disconnectivity • Recoverability • Consistency

Mobile Computing Architecture Slide 30 - 57 The general architecture of a mobile platform

Mobile Computing Architecture • It is distributed architecture where a number of computers, generally referred to as Fixed Hosts and Base Stations are interconnected through a high-speed wired network. • Fixed hosts are general purpose computers configured to manage mobile units. • Base stations function as gateways to the fixed network for the Mobile Units. Slide 30 - 58