About SFSU IS Projects
- Home
- Project Overview
- Project Organization
- Training Registration
- 5-HELP
- CMS Performance Reporting Form
- Meeting Request
- Suggestion Box
- Contact Us
SFSU Business Intelligence
SFSU Human Resources Management System
- Log into HRMS
- Overview
- Implementation Team
- Implementation Timeline
- Documentation
- FAQs
- HRMS Forms
- HRMS System Status
SFSU Financial Management System
- Log into FMS Production
- Overview
- FRS Translation to FMS
- Implementation Team
- Implementation Timeline
- FMS Forms
- FMS System Status
Related Links
SFSU Business Intelligence > Technical Overview
Business Intelligence Technical Overview
A dimensionally modeled data warehouse
Transactional systems such as PeopleSoft HRMS and FMS are modeled for optimal transaction performance – a large volume of small transactions must be processed efficiently. Dimensional modeling, on the other hand, focuses on the opposite – efficient processing of a relatively small volume of large transactions . To achieve the objective of dimensional modeling, the data is de-normalized before it enters the data warehouse dimensions. Data de-normalization results in fewer silos of information providing better query flexibility and performance. In essence, the individual pieces of information spread around the transactional systems are organized by general subject . For example, all of the data about Time (day name, month name, fiscal year, etc) is together in one place (Time Dimension); all of the data about Project (project title, project number, etc) is together in another place (Project Dimension), and so on. The dimensional model is much easier to understand. |
|
 |
|
Dimensions also contain information about hierarchies such as organizational charts, time roll-ups, project roll-ups, etc. For example, at SF State, accounts roll up to projects and projects roll up to funds. This information allows for drilling up or down to different levels – either higher level summaries (at the Fund level, for example), or lower level detail (at the Account level, for example). So, a business user can start by looking at the fund budget totals and drill down to the underlying projects and accounts to see the detailed information that contributed to the fund total. This kind of functionality would be prohibitively costly without a dimensional data warehouse. |
|
 |
Dimensional data modeling lends itself to data visualization such as a cube providing users with a straight forward way of associating information with the business. In the hypothetical cube on the left, the budget figures can be tracked by Employee by Grant by period of Time. Without a dimensional model, the same would require IT staff experienced with navigating complex transactional models. A cube with more than three dimensions is called a hypercube , which is difficult to illustrate. However, OLAP cubes can have many axes (or dimensions) that can be used for targeting specific data. The main purpose of a cube is to allow an analyst to focus on a particular set of data. This can be a subset of the data in a data warehouse to study a well-bounded business problem. OLAP cubes can be tuned in some specific ways for better performance. |
| Cubes are themselves dimensional sources of information, and they can be stored either in the database or as a stand alone file outside of a data warehouse. Typically, cube generation is a feature of an information analysis and reporting tool. |
|
1600 Holloway Avenue, San Francisco, CA 94132
Last modified January 14, 2008 by IS Projects Web Team