This is the fifth in a series of posts about how to identify entities in data sources that can readily be classified as belonging to each of the 6BI Business Object Categories (BOCs): Parties, Things, Activities, Locations, Events and Motivators. Entity types in the Events BOC identify When production and consumption of things by parties occurs. The fourth post in the series (on Locations, the “Where” aspect) can be found at https://birkdalecomputing.com/2017/08/23/identifying-locations/ .
Concepts and objects in this BOC capture data about a point in time or the duration of time over which products or payments flow from one party to another, or when an enterprise carries out its work. Data element and data element collection names you may encounter that belong to the Events BOC include, but are not limited to, names in the following table[i]. The list gives you a hint of what kind of names to look for in putting together a 6BI Analytic Schema for enabling your data to answer business questions.
Events break down into two major sub-types: (1) Occurrence types, which include Event, Alert, Notification, and Incident from the list above; and (2) Duration types which include, Year, Month, Week, Day, Hour, Minute, Second, Date and Time from the list. Duration type entities, as no doubt is obvious, are units of time and can be used to aggregate facts in a star schema across a temporal hierarchy. Occurrence types are more like things. Instead of being produced and consumed, they occur, that is they are something that can be referred back to that, in addition to any other properties they may have, always have an aspect of time or “when” about them, this aspect is important for data analysis.
Unlike the other BOCs, the Events BOC has both dimensional and fact characteristics. On the one hand, time is already defined into a hierarchy and is standard for everyone. An hour is always an hour, sixty minutes, a minute is always a minute, sixty seconds, and so on. On the other hand event occurrences are things that happen and can be measured and compared. They are data, not metadata as the hierarchy of time is. Events happen and then they are over but there can be much to learn from their having occurred. This BOC is conceived to capture important data about the perspectives of when something happens in your data. These perspectives relate to when, not where, not who, not how, not why, not even what has happened, but when it happened, or will happen.
This BOC captures the characteristics of time that most influence results. It is also important to understand how events differ from either locations or activities, two other previously covered BOCs, with which events are often confused.
A location is concrete. It is a point in space, a place, even if that space is virtual. You can go away and come back to a location, and if most (not necessarily all) other factors are the same, or within tolerances, the location is still there. Not so with an event. An event, though all relevant data may be captured about it, once it occurs, is done and goes away forever. Another instance of a particular class of events can subsequently occur, but each event is unique and has a time when it occurred.
Events and activities are closely related and co-dependent but are not the same. Activities are event-driven. They receive and react to events and create new events which are sent to other activities. Each activity is an independent entity and can execute in parallel with other activities. Coordination and synchronization is by means of events communicated between the activities. Activities react to input events by changing state and creating output events[ii].
The important thing, from a 6BI perspective is that an event provides a temporal association for a result. If the persons, places, products, locations, and motivators are known (or estimated) you still need to know when these aspects came together to create something of significance.
Another instance of the importance of the “When” aspect is in Big Data solutions. Since systems owners often cannot control when data is available to the solution it is important to be able to record when each event occurs, and there could be literally millions of events in a short unit of time producing results which can uniquely aggregate the results.
[i] I would like to thank Barry Williams and his excellent Database Answers website http://www.databaseanswers.org/data_models/ for providing many of the table name examples.
[ii] David Luckham, various writings.
Birkdale Computing 