Function Points FAQs

Data Warehouses

ISSUE

How should the functionality of a Data Warehouse be counted?

FUNCTIONAL OVERVIEW

While it is recognised that Data Warehouse systems each have their own unique characteristics, there are certain generic characteristics shared by the family of systems known as Data Warehouses. These include:

  1. The prime purpose of a Data Warehouse is to store, in one system, data and information that originates from multiple applications within, or across, organisations. The data may be stored 'as received' from the source application, or it may be processed upon input to validate, translate, aggregate or derive new data/information.
  2. Most of the data load functions are processed in batch. There are few on-line data maintenance functions. The on-line functions that do exist tend to update the reference files and data translation tables.
  3. A database alone does not constitute a Data Warehouse system. At a minimum, a Data Warehouse system must include the database and corresponding load functions. Data reporting functions are optional. They may or may not be an integral part of the Data Warehouse system.
  4. The prime purpose of storing the data is to support the information reporting requirements of an organisation, i.e. multiple users and multiple applications.
  5. The Data Warehouse may or may not provide the required reporting functions. In some cases, external applications access the Data Warehouse files to generate their own reports and queries.
  6. Data Warehouse functions are often based upon packaged software. An example is the Business Objects product.
  7. Where the data within the Warehouse supports the reporting requirements of multiple applications and users, the data may be physically stored based upon the user requirements. Separate database segments may store the 'user views' for a particular user. This results in the physical storage of a considerable amount of redundant data. The data storage approach is designed to optimise data/information retrieval.

GENERAL DISCUSSION AND RESOLUTION

Note: The following list of functions is intended to be a generic guide for counting this type of application; there may be instances where particular applications may offer more or less functionality.

Files: Internal Logical Files

The main issue with Data Warehouse (DW) systems is how to count the files. Typically a DW is required to support the information needs of multiple applications/users. Data is input to the systems from a number of source systems (usually core systems). At the time the data is loaded it may be processed in multiple ways and update multiple files, each of which supports a different user's needs. With DW files, it is not possible to force a logical view of the files. The same data can be stored in multiple physical files because it supports that particular user's view of their requirements.

Where they exist, the following may be counted as ILFs for the Data Warehouse System:

  • Master Data Files

    • These may store processed information or data as received from the source core systems. Redundant data may be stored in various physical tables that are required to support user views of data. Count each physical database table as a logical file. Count the redundant DETs as DETs in the files in which they occur. Do not count redundant DETs that occur within the one file.

  • Reference/Translation Tables
    • The possibilities are many and varied. However, under the recommended guidelines, only one translation table is counted per application. See Section 3.4.7, Reference tables - Identification Guidelines
    • Log/Event Files

    Files may exist which maintain information about the currency of the data within the DW. For example, they may record when data was last refreshed from a particular source application.

Transactions: External Inputs

The EI load transactions are identified from a physical perspective as well.

Where they exist, the following may be counted as EIs for the Data Warehouse System:

  • Data Load Functions

    • Records in files are not necessarily loaded as a complete record. It depends upon where the source data has come from and how the load process has been designed i.e. the amount of pre-processing that is done on the source data. For example, a load function may only load certain attributes into a file or, alternatively, one load process may load multiple files at the same time. It is assumed that what is implemented is what the user requested, and there was a good business reason for adopting the implemented approach.

    In most cases the EI load functions process the data received. An exception situation occurs where the data is simply loaded as received from the source system. In this case, theoretically, the Load should not count as an EI and the file loaded should be counted as an EIF. This can cause the unusual situation where the DW loads a file that is typed as an EIF. The downstream reporting system reads the DW file and also types it as an EIF. This situation is rare and it is recommended that the load function be counted as an EI and the DW file as an ILF

  • Maintenance functions for Reference/Translation Tables

    • Count as per IFPUG 4.1.

Transactions: External Outputs and External Enquiries

Where they exist, the following may be counted as EOs and/or EQs for the Data Warehouse System:

  • Data Reporting Functions
    • DW systems usually do not have their own reporting functions. They are not 'reporting users' of their own files. Other external applications reference the DW files (as EIFs) and produce the necessary reports. This can result in a considerable amount of double counting of files across the portfolio, but this is usual when application boundaries are drawn in this way. Sometimes the DW does use a reporting tool such as Business Objects to generate reports. If so, count as per IFPUG 4.3.

    Note: When the bulk of the processing (i.e. derived and calculated data) is performed as part of the data load processing most of the reports produced are technically EQs
    • Data Enquiry Functions. Count as Per IFPUG 4.3