Patterns are defined as "a proven solution to a known problem". They are used in more than one specific context, which makes them widely applicable. In software terms, patterns are essentially the "distillation of the wisdom" gained by practitioners of what works well when specifying, designing and implementing object-oriented software and relational or object-relational databases.

As such they can be considered as a "best way" of dividing sets between co-operating objects or components. Once patterns are identified and documented, they can be reused again and again without reinventing the solution. Although the idea of defining and using patterns has been around for years, they are now becoming very popular in J2EE design and development.

Applying patterns to your own database designs becomes the ultimate cut-and-paste technique. Because of this nature more and more CASE tools and wizards in integrated development environments (IDE) are applying these commonly accepted ways of working.

The eight patterns (plus Type) presented in this section as data models, are produced from the nine components documented in the previous section. The nine components represent a collection of tables, table properties, primary, secondary and foreign keys, data and data properties. They are organized to produce a subject area data model. Each of these subject area data models contains a class of data.

The components are the building blocks. Each component represents a table type in the target, physical database. Each of the table types solves a particular data storage problem. The relationships that exist between these table types are known, observable, appropriate and provide transportation through the database.

There are also examples of the pattern's data model's underlying tables. The data in each table is a minimum. You will need data to support your requirements. What is most important about these tables are the keys and the key structure.

The Patterns

Type ~ Type is not really a "class" of data. It's function is to organize and manage the classes. Type contains the nouns and adjectives that represent the vocabulary of the business

Organization ~ The class Organization contains the attributes that describe government, business, academic, religious, political and other groups of people associated for a common purpose. Entities, such as Customer, Supplier, Shipper and Competitor are members of this class.

Person ~ The class Person contains the attributes that describe a human being. Entities, such as Employee, Contractor, SalesRep and Client are members of this class.

Activity ~ The class Activity contains the attributes that describe work. Entities, such as Campaign, Promotion, Project and Task are members of this class.

Location ~ The class Location contains the attributes of a postal address. It also contains longitude, latitude and altitude (GIS) data. There are no entities in this class.

Property ~ The class Property contains the attributes of real property (real estate). Entities, such as Office, Store, Warehouse and Factory are members of this class.

Item ~ The class Item contains the attributes that describe things. Entities, such as Product, Part, Hardware and Software are members of this class. Items may have Instances (of an Item) that contain data for individual, serial numbered items.

Code ~ The class Code contains codes and their corresponding definitions or descriptions. Also known as reference data. These are the most enduring of all legacy data. Codes may have a hierarchy, where one code depends on another. I hate this one, but if you have ever built stuff for government agencies, you better handle their codes. Government workers won't ever, ever give up their codes.

BusinessObject ~ The only data class that does not require membership (see component Member). The class BusinessObject contains the attributes and relationships found on computer forms and documents that do not exist in nature but are a creation of a business function or activity. Instances, such as Order, Invoice, Claim and Bill of Lading are examples of this class. It is very, very rare that BusinessObjects are stored in the database, but it must exist to document their existance and their relationships.

Beware of creating new classes that can be accommodated in an existing class using the Entity component. One of the goals of the enterprise data architecture is to reduce the number of objects and therefore reduce complexity.