Enterprise DB Methodology

The biggest challenge in implementing the enterprise/application database pair is the analysis and design of the tables, relationships and data found in an organization's business objects. This exercise should also demonstrate that business objects also follow similar patterns. Once you have analyzed a dozen or so business object you will recognize these patterns. Try to avoid re-inventing stuff.

A business object is defined as a collection of data organized around and supporting a business transaction or information requirement. Business objects take the form of fill-in-the-blanks paper forms (documents), computer screen snapshots (views/dialogs), reports, spreadsheets and ledgers. Business Objects take many forms, ranging from the simple to the highly complex.

All of the business object exhibits within an application need to be identified, collected, categorized and analyzed. The results of this analysis is, in the aggregate, the basis of the business object tables design. Once the location of the business object are identified, they are located in the existing tables. If the analyst is looking at new data it must be added to existing tables or new tables need to be constructed -- nd don't forget the relationships -- especially the "hidden" ones.

This section contains an overview of the Business Objects Analysis process used to produce the data objects and relationships contained in the BusinessObject class. This deliverable is known as a data model or schema. When a single business object is modeled it is called a subschema. The process is executed one exhibit at a time. Start with the simple ones and work your way up to the complex forms. This sequence allows the Data Architect to learn the business environment during the process.

The process begins by selecting a single business object from the exhibits collected during the Requirements phase of the Systems Development Lifecycle (SDLC) or Rational Unified Process (RUP). The exhibit used in this example is fairly standard, in that it contains heading, detail and footer sections. The goal is to produce a subschema for each business object and an attributes list. When all objects are modeled, the attribute lists are combined, removing duplicates and the subschema are combined into one, full schema, also removing duplicate objects and relationships.