Schema Vacuuming in Temporal Databases

Abstract

Abstract-Temporal databases facilitate the support of historical information by providing functions for indicating the intervals during which a tuple was applicable (along one or more temporal dimensions). Because data are never deleted, only superceded, temporal databases are inherently append-only, resulting, over time, in a large historical sequence of database states. Data vacuuming in temporal databases allows for this sequence to be shortened by strategically, and irrevocably, deleting obsolete data. Schema versioning allows users to maintain a history of database schemata without compromising the semantics of the data or the ability to view data through historical schemata. While the techniques required for data vacuuming in temporal databases have been relatively well covered, the associated area of vacuuming schemata has received less attention. This paper discusses this issue and proposes a mechanism that fits well with existing methods for data vacuuming and schema versioning.

A rule-based tool for gradual granular data aggregation

“…The management of obsolete data through data vacuuming (oldest data is physically deleted or migrated from primary to secondary storage) and schema versioning is presented by [14,13], respectively. The main direction of both these works is to provide the base for correct processing of queries and updates against vacuumed databases and schemas.…”

“…The snapshot of data consists of one task and four parameters with two different levels of time granularities. The data at the detailed level is represented as (10,191126,248,2.51); (10, 191126, 41, 0.13); (10, 11467562, 247, 13.44); (10, 11467562, 1, 11.20); (10,11467563,247,13.57); (10, 11467563, 1, 11.20)... (10, 11467621, 247, 15.73); (10,11467621,1,11.00). In this example data, parameter 247 and parameter 1 have granularity (logging frequency) equal to a "second" and parameter 248 and parameter 41 have granularity equal to a "minute".…”

“…For example, an old row at a granularity level equal to "second" in the Time granularity table contains the following data: (27880001, 2010, 3, 10, 12, Day [8-16[, [12-16[, 15, [20-40[, [20-30[, 25, 40, second). Subsequently, a new row at a granularity level equal to "minute" appears as follow: (1000346, 2010, 3, 10, 12, Day [8][9][10][11][12][13][14][15][16][12][13][14][15][16]15,[20][21][22][23][24][25][26][27][28][29][30]25,NULL,minute). The new Timeid is generated as: ((25+1)+60*(15+1)+144 0*(12)+44640*(10)+35444940*(2010-2010)+535680)=100 0346, whereas, the old Timeid was generated as: ((40+1)+ 60*(25+1)+3600*(15+1)+86400*(12)+2678400*(10)+349 09261* (2010-2010) The complete stored program consists of 450 lines of code This example shows how the row at a higher granularity level re-uses the values of the row at a lower granularity level.…”

“…Moreover, the GROUP BY (line 19) clause is based on the specified level of time granularity; it has the ability to aggregate data at higher granularity level(s) from the lower granularity level(s). For example in the data aggregation query (lines [8][9][10][11][12][13][14][15][16][17][18][19][20][21][22], the GROUP BY clause aggregates data to minute granularity level from second granularity level. The data is aggregated per task level and stored in a Temporary fact table.…”

A framework for manipulating vacuumed data in temporal relational database

“…Skyt studied data management methods for physically removed data [3] and suggested a framework for vacuuming temporal data [4]. Roddick's aim was preventing some relations from removal in vacuuming process, so he searched about schema versioning [5] [6]. He also did researches about data mining on temporal database systems [7].…”