Read Me

The reader is encouraged to read the Database/OLTP sections -- application then enteprise -- in sequence before the Data Warehouse/OLAP sections. The OLAP architecture uses OLTP architectural components.

The key to both architectures is a solid understanding of the components. The nine components are used to rapidly produce databases and data warehouses, so make sure you read and understand "Components" in the Enterprise Architecture section. By understanding the components well and recognizing them in legacy databases, the data warehouse architecture and methodology will work for you even if you do not implement the enterprise database concept.

The components are combined to produce database patterns. Patterns are proven solutions to known problems. The patterns are documented, by class, using data model notation. There are eight data classes documented in this web text. They are Organization, Person, Activity, Location, Property, Item, BusinessObject and Code.

The eight patterns are combined into an enterprise schema and implemented as a prototype containing the enterprise/application database pair. The prototype exists both as a "proof of concept" and as a seed enterprise database. The prototype is also used to mitigate concerns over the performance of the enterprise/application database pair.


I don't like to do ribbons and badges, but you need to know where this stuff comes from. So here it is.

Between 1967 and 1987 I built application systems and databases for everybody -- at least it seemed like it. I trained thousands in graduate classes, professional development seminars and since I always worked facilitating teams -- on the job.

Between 1987 and 1992 my company had the sole-source contract to design the program-wide data architecture for NASA's Space Station Program. The program had a $50 billion, 50 year lifecycle, 500 contractors, 25,000 people and more stuff than the 3rd Army. Producing a data model that documented the pieces and parts and people was a big freaking job, but we had a set of proprietary tools that made the job possible.

Using our end-user driven expert system. my team produced detailed, optimized designs with loads and response forecasts and then ported finished data models and design structures into a number of popular CASE tools. The project took 4 years and had 450 project participants -- NASA directors, managers and staff, contractors and sub-contractors. The completed project was described by the NASA Space Station Program Manager as "highly successful."

The name of the game was reducing the redundancy between administrators, vendors and contractors, managers and staff, the pieces and parts of the station, the projects/activities/tasks/jobs/steps, languages (we had foreign partners), centers, directorates, divisions, branches and offices -- and NASA had six different acronyms for the same thing or the same acronyms for different things. Acronyms, abbreviations and mnemonics are death to a study of data. Get rid of them. The best tool ever invented for naming data is the English language (or whatever your native language is)

The first week on the job, we were given a Rockwell-produced copy of the B-1 Bomber Data Model that had over 800 objects in it. Space Station dwarfed the B-1 Project so it was pretty clear right away, that if we were to model the program, bigger wasn't better. [A radical concept on federal jobs where it seems you get paid by the object -- the more the better. Nothing like building in complexity to produce billable hours.] Instead of looking at the real or perceived differences between every little detail, I chose to look at commonalities with the goal in mind of reducing redundancies.

In the process of attempting to reduce redundancy, I stumbled -- and that's the correct word -- stumbled on a set of patterns that work universally and are a cut-one solution to designing databases -- any database. The eight patterns also make the perfect Operational Data Store (ODS), the platform that facilitates the transfer and reorganization of OLTP database data into OLAP data marts and data warehouses. Take it to the bank. I've used it successfully on my last three large commercial projects.

Over the next ten years of building application databases and business intelligence data warehouses, I refined what I learned into what's in here. It's good stuff and it works -- every time.