Deductive Data Warehouses

Deductive Data Warehouses

Kornelije Rabuzin (University of Zagreb, Varazdin, Croatia)
Copyright: © 2014 |Pages: 16
DOI: 10.4018/ijdwm.2014010102
OnDemand PDF Download:
$37.50

Abstract

This paper presents the idea of deductive data warehouses. Deductive data warehouses rely on deductive databases but instead of a database in the background a data warehouse is used. The authors show how Datalog (as a logic programming language) can be used to perform OLAP analysis on data. Since data warehouses don't use all the technologies that databases do (locking, transactions, integrity constraints, etc., which are not relevant in this context), some things are different and simpler then when working with deductive databases. The authors demonstrate the idea on an example and the authors show that Datalog rules can be used to perform OLAP analysis on data.
Article Preview
Box 1.
[ WITH [ RECURSIVE ] with_query [, ...] ]
INSERT INTO table_name [ (column_name [, ...]) ]
{ DEFAULT VALUES | VALUES ({ expression | DEFAULT } [, ...]) [, ...] | query }
[ RETURNING * | output_expression [ [ AS ] output_name ] [, ...] ]

Square brackets represent that some things are optional, | represents or and … means that something can be repeated more than once. However, during the years SQL has become quite complex and some statements (especially queries) have started to cause problems even for professionals (and for end users as well).

In this paper we present the idea of deductive data warehouses; Datalog is used as a language to analyze data in the data warehouse by simulating (advanced) OLAP capabilities. The paper is organized as follows: the following part defines deductive databases and deductive data warehouses. Next, a small example is built and data is analyzed by means of an advanced OLAP tool and by means of defined Datalog rules. In the end the conclusion is presented.

Deductive Databases

A problem (already mentioned earlier) whose consequences are still visible is the direct consequence of bad planning (or “no planning at all” approach). Many companies have implemented (over the years) many applications and/or information systems; however, they were all implemented in different applications languages (different generations of application languages were used) and they used different data storage mechanism (some applications used different types of files, some applications used databases, etc.). Today we know that you cannot focus on just one aspect of business; you have to have in mind the whole picture in order to manage and to know what is really going on. One cannot focus on sales data and not having in mind the purchasing department results and global trends (for example). Let’s assume that incomes were reduced in the past quarter; although this may seem to be bad, if we compare the global trends and our competitor’s (sales) results we can conclude that (for example) the decline was even worse for them (and that we are doing OK).

A data warehouse is a database organized (usually) in the form of a star (or snowflake) schema. A star schema usually contains dimensions and facts; these are both tables differing in that dimension tables are used to store attributes that are used to analyze data in fact tables that contains measures (i.e. numbers) used to evaluate (measure) business processes.

Figure 1 is easy to understand and end users can pose queries by themselves using OLAP tools that represent an intuitive way to analyze data. We will see some examples later on.

Figure 1.

Star schema

Complete Article List

Search this Journal:
Reset
Open Access Articles: Forthcoming
Volume 13: 4 Issues (2017): 3 Released, 1 Forthcoming
Volume 12: 4 Issues (2016)
Volume 11: 4 Issues (2015)
Volume 10: 4 Issues (2014)
Volume 9: 4 Issues (2013)
Volume 8: 4 Issues (2012)
Volume 7: 4 Issues (2011)
Volume 6: 4 Issues (2010)
Volume 5: 4 Issues (2009)
Volume 4: 4 Issues (2008)
Volume 3: 4 Issues (2007)
Volume 2: 4 Issues (2006)
Volume 1: 4 Issues (2005)
View Complete Journal Contents Listing