This month we continue where we left off in the last column – undertaking our data warehouse design through a process of requirements gathering. Based on the size and complexity of the proposed approach, requirements gathering can be done using a number of different methods separately or in combination. However, the end result should be the same – a dimensional data model showing the logical structure of the database design, a process model showing the types of business activities which are to be supported and the view/form the information should take on the user’s desktop. The types of activities that can be employed in requirements gathering include:

  • Brainstorming
  • Interviews
  • Dimensional data modeling
  • Process and context modeling
  • Prototyping
  • Story boarding

The sequence of how these techniques are applied is:

  1. Background materials and systems research and assessment.
  2. Brainstorming and/or interviewing.
  3. JAD which includes data and process modeling.
  4. Prototyping and revision of the data and process models.

Based on whatever analysis methods we choose, the focus here is to develop our understanding of what is required by:

  1. Establishing an understanding of the business (process modeling).
  2. Understanding how deep or detailed this analysis needs to be which will set the grain of our fact tables and surrounding dimensions (data modeling).

The data model provides:

  1. An understanding of the core business properties (dimensions).
  2. The essential knowledge to be analyzed (facts).
  3. The level of detail (the grain of the base fact tables).
  4. How core business objects need to be shared (conformed dimensions).
  5. The business meaning of each dimension, fact and data item.
  6. A user view of the data which can be immediately recognized and utilized by the business (the star schema model).

The process model provides:

  1. The canned or predictable processes required to access and format data for end-user consumption in terms of user views.
  2. The ad hoc process in accessing data at any level in the warehouse.
  3. The data quality audit processes in verifying data loading into the warehouse.
  4. The data access authorization (security) processes in governing access to the various levels of the data warehouse.
  5. The change and problem management processes required to support access to the data warehousing environment.

The basic mistake made is that much like in OLTP-systems analysis, process and data analysis are undertaken as separate and disjoint tasks. It is a crucial requirement that process and data modeling be done together. That is, we usually start with a context model or high-level view of the area of analysis. This model shows the major players and interfaces (source systems) which will feed our data warehouse. The next step is to drive out the essential business activities that form the candidate fact tables of our warehouse design. For example, in an insurance-based data warehouse, the processes being modeled may include fraud detection, claims processing, invoicing and collections. These four business activities may eventually form candidate fact tables called "fraud," "claim," "invoice" and "collection." Once these key business activities are understood in terms of focus, frequency and content, the corresponding dimensions can be identified and modeled as our star schema design. Once we have identified all the key business events, we can cross-check them against the identified fact and dimension tables to be sure that all processes have a star schema model view defined for them and all stars we have modeled actually will be accessed by a business activity as identified in our process analysis sessions. To allow this cross model validation to occur, we usually flip back and forth between process and data analysis sessions with the user group until we complete the analysis of the business activities included within our scope and constrained by our context model which forms the "fence" for our analysis (and keeps us honest in terms of digressing from our stated scope). Next, we combine all our process-centric star schema views into one overall model which share our now "conformed" dimensions across all the fact tables at the various levels of granularity which fall within our scope as illustrated in Figure 1.

  • Logical Modeling Steps
Develop user views containing fact tables of interest for each user department/function

The user-view star models can also be used to understand what data sharing will be required by the various user groups and the degree of data sensitivity. The final step in our analysis is to confirm the levels of aggregation required to satisfy our requirements based on the types of analysis being done, the volume of data and the number of required levels of aggregation.

In summary, once completed we should at least know:

  • The grain or level of granularity for each of our fact table (s).
  • The number of conformed (cross-subject area) dimensions.
  • Overall size for each dimension and fact table.
  • Initial number and type of aggregates.
  • The types and number of the predictable queries to be run against the model and their frequency.
  • Currency and security regarding data for each dimension and fact.
  • Validation in that each attribute in our model is referenced or used by a process object.
  • A view into what will be required in terms of source system data to populate our model.
  • The types of analytic tools to provide the users access to the information as contained in our model.

Business requirements analysis needs to cover these essential activities in a sequence of the following tasks:
Conduct Business Requirements Analysis

1) Schedule end-user requirements gathering sessions.
a) Conduct end-user requirements sessions.
i) Determine all tactical reporting requirements.
ii) Determine all strategic analysis requirements.
(1) Determine all dashboard or EIS- based requirements.
(2) Determine all decision support or analytic requirements.
(3) Determine all data mining requirements.
(4) Determine all ad hoc reporting/access requirements.
b) Publish and obtain feedback.
i) Prepare requirements statement for sponsor/steering committee approval.

2) Develop subject-area data model (in concert with the business requirements sessions).

a) Refine/establish data modeling/repository tool environment and update process.
i) Identify/model fundamental entity types (dimensions) for analysis.
ii) Identify/model business requirements processes (facts or events) for analysis.
(1) Define all derived and key-based attributes.
(2) Document all required business rules and determine what initial summarization data. will be required for fact and dimension table attribute aggregation definition during the design phase.

Next month we will continue this discussion by reviewing source system assessment, the second of five major activities we need to accomplish as part of data warehouse design.