patterns notation

This data model is a visual representation of the notation used for the Patterns data models. The text under each object identifies the primary keys. The rest is self-explanatory -- or should be. It will become clear when you review the Pattern data models.

The model notation used is data modeling notation, which means there is no references to process. These are not Entity-Relationship Diagrams. The double arrow on the relational connector represents the location of a foreign key or the many-end of the relationship.

The components are the building blocks. There are 9 components. 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.

The models are produced from a finite set of components. These 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 nucleus of a Class is the Class component. A Class is identified by its common attributes list and is named logically. The examples of Classes used in this site are; Organization, Person, Activity, Location, Property, Item and Document. The Enterprise Data Architect should freely build other Classes from the components as needed.

The Class table type has relationships to other components in order to provide membership, resolve intra-Class and inter-Class relationships, log events and maintain seamless integration to the legacy systems.

The model notation used is data modeling notation, which means there is no references to process. These are not Entity-Relationship Diagrams. The double arrow on the relational connector represents the location of a foreign key or the many-end of the relationship.

Rule: The primary key is always in the parent table at the one-end of the relationship. The foreign key is always in the child table at the many-end of the relationship.

Since any component may be "Journaled," the Journal component is not shown. By creating a child table and adding date (time) to the primary key of any component, historical tracking of the parent component's data is achieved.

Exercise some engineering rigor and do not change the structure of these keys. They will work for you as designed. Avoid non-numeric primary keys. They are death for performance.

"Class".Id, the primary key of each of the base classes and should look like the 64-bit, 128-bit or 256-bit registers in the Central Processor (CPU). The DBMS storage and retrieval algorithms perform much faster when they are doing their work in the registers (CPU memory) as opposed to main memory (RAM, DRAM).