Data Warehouse Concepts - Data Warehouse Systems: Design and Implementation - page 72

about the average monthly balance of clients' accounts for a period
covering several years. In contrast, an operational database may not have
explicit temporal support, since sometimes it is not necessary for day-to-
day operations and it is also dicult to implement.
A data warehouse is aimed at analyzing the data of an entire organization.
It is often the case that particular departments or divisions of an organization
only require a portion of the organizational data warehouse specialized for
their needs. For example, a sales department may only need sales data, while
a human resources department may need demographic data and data about
the employees. These departmental data warehouses are called data marts .
However, these data marts are not necessarily private to a department; they
may be shared with other interested parts of the organization.
A data warehouse can be seen as a collection of data marts. This view
represents a bottom-up approach in which a data warehouse is built by
first building the smaller data marts and then merging these to obtain the
data warehouse. This can be a good approach for organizations not willing
to take the risk of building a large data warehouse, which may take a long
time to complete, or organizations that need fast results. On the other hand,
in the classic data warehouse view, data marts are obtained from the data
warehouse in a top-down fashion. In this approach, a data mart is sometimes
just a logical view of a data warehouse.
Table 3.2 shows several aspects that differentiate operational database (or
OLTP) systems from data warehouse (or OLAP) systems. We analyze next
in detail some of these differences.
Typically, the users of OLTP systems are operations and employees who
perform predefined operations through transactional applications, like payroll
systems or ticket reservation systems. Data warehouse users, on the other
hand, are usually located higher in the organizational hierarchy and use
interactive OLAP tools to perform data analysis, for example, to detect
salary inconsistencies or most frequently chosen tourist destinations (lines
1-2). Therefore, it is clear that data for OLTP systems should be current
and detailed, while data analytics require historical, summarized data (line
3). The difference on data organization (line 4) follows from the type of use
of OLTP and OLAP systems.
From a more technical viewpoint, data structures for OLTP are optimized
for rather small and simple transactions, which will be carried out frequently
and repeatedly. In addition, data access for OLTP requires reading and
writing data files. For example, in the Northwind database application, a
user may be able to frequently insert new orders, modify old ones, and delete
orders if customers cancel them. Thus, the number of records accessed by an
OLTP transaction is usually small (e.g., the records involved in a particular
sales order). On the other hand, data structures for OLAP must support
complex aggregation queries, thus requiring access to all the records in one or
more tables, which will translate in long, complex SQL queries. Furthermore,