Salvaging Information Engineering Techniques in the Data Warehouse Environment

Abstract

Introduction During the 1980s and early 90s, Information Engineering (IE) was in its prime. Most major corporations were utilizing some form of system development methodology that could be tied back to IE. The first step in any IE project was the Information Strategy Plan or ISP. The ISP would look at the data, process, organization, technology, and interactions of an enterprise. The ISP was top-down analysis at its best. Three key deliverables of ISP were a data model, functional decomposition, and an interaction (CRUD) matrix. The data model was an entity relationship diagram that encompassed the entire enterprise. The functional decomposition diagram would examine the business functions and decompose to a process level. The CRUD diagram would examine the business functions and decompose to a process level. The CRUD matrix examined the interaction of data and process. These three deliverables provided a basis for top-down analysis. The Entity Relationship Diagram The entity relationship diagram is the standard data technique for creating data models. According to Martin, entity relationship diagrams are composed on entities that are defined as something, real or abstract, about which we can store data. (Martin, 1998 p. 297) The entity relationship diagram enables an analyst to create a graphical view of the data concepts of an organization and their relationships. Tradition system development dictates creation of an Entity Relationship diagram that is converted to a database design of a relational database. In a data warehouse environment, the traditional normalized Entity Relationship cannot be easily translated into a database design. By nature a normalized Entity Relationship diagram tends to separate the data concepts into separate entities. A traditional approach to Entity Relationship modeling is concerned with three concepts: entities, relationships, and attributes. Components of the Entity Relationship Diagram There are many works that describe Entity Relationship diagramming in detail. It is not the intention of this work to present exhaustive details; instead a brief description of the component is presented. * Entity--A data concept that has relevance to the enterprise. An entity can be a person, place, thing, or concept. Typically an entity consists of a single identifiable concept such as EMPLOYEE, STUDENT, CLASS, PURCHASE ORDER, or SHIPMENT. An entity can consist of subtypes. Subtypes are a decomposition of an entity into its various types. For example an EMPLOYEE entity can be modeled with subtypes FULL-TIME and PART-TIME. Subtyping is necessary when clarity is required about the data (and to some respect the behavior) of the Supertype entity. * Relationship--A relationship, as the name suggests, is a description about the relationship that exists between two entities. Information about how the entities relate, in particular, the optionality and cardinality of the relationship is modeled. A relationship should only be modeled when the relationship has relevance. If one desired, any entity could loosely be related to any other entity, but this is not the intention of modeling relationships. A special relationship, known as a recursive relationship, exists between an entity and itself, such as an EMPLOYEE to EMPLOYEE related by a REPORTS TO relationship. * Attributes--Attributes are details about a specific entity. These details provide greater clarification about the data that can or will be captured regarding an entity. One must be careful not to confuse entities and attributes. Entities can exist without attributes, but attributes cannot exist without entities. There are many nomenclatures for the actual diagrams. For demonstration purposes, this paper will adopt the Crow's Foot diagramming technique. Data Modeling for a Data Warehouse There has been significant work done on utilizing specialized data modeling techniques for data warehousing. …