Tagging Observations

Let’s say we are using the observation pattern from the previous post to track properties (observations) of a large number of different objects (subjects). Each object can have many properties and different objects have different properties. The catch is that not all people (users) are interested in all properties. Using a computer for example; geeks are interested in processor, memory and screen resolution; managers in pricing, warranty and preferred supplier; material handlers in packaging and weight. So, there is no sense in displaying all possible properties of an objects to all the people.

The model allows for tagging of property (observation) types, similar to labelling messages in Gmail, including tag hierarchies. For example height, weight and width would be tagged with: all, dimensions, physical; some other tags would be: accounting_interest, tracking_specific, and so on. This way a user can subscribe to a set of tags she may be interested in.

  • One observation type (height, weight, color) can have many tags, one tag may be applied to many observation types.
  • Each tag may have a parent tag forming a hierarchy.
  • A user stores preferences for a set of tags that she usually monitors.

alt text

Observation Pattern

The post relates to a stackoverflow question on DB design and my answer there.

To summarize relationships:

  • One report can list many observations, an observation can appear in many reports.
  • One subject (under observation) can undergo many observations, an observation relates to one subject only.
  • An observation is of a specific type, there can be many observations of the same type.
  • Measurement and trait are types of observations. Measurement is a numeric observation, like height. Trait is a descriptive observation, like color.

This is a simplified model based on Fowler’s observation pattern, for more details see Analysis Patterns by Martin Fowler.

Organization Model

This is related to a stackoverflow question on DB design and my answer there.

To summarize relationships:

  • Customer, vendor and distributor are types of organizations.
  • One organization can have many contacts, a contact belongs to only one organization.

A few notes on tables:

  • The Organization table has columns common to all organizations.
  • The Customer, Vendor, and Distributor tables contain only specific columns for each one.
  • The primary key in the Customer table also serves as a foreign key to Organization ID; same for Vendor and Distributor.