A recent question came up regarding the difference between “events” and “data”. After all, to a DBA, an “event” is just another data record but with a timestamp! Of course, that is the “static” view of an event – useful only for archiving and “post (-event) processing” activities like data mining, BI and analytics.
However, a more technical answer is that data is derived from events. Customer data? Derived from customer registrations and associated checks – all events. Amount owed? Derived from purchase events. And so forth. So a better answer for the DBA is that “data” is just “information collected from, and associated with, prior events“.
In Complex Event Processing, of course, we are processing this “event data” as it occurs (within the limitations of our system latency, of course!). Typically this event data is correlated with previous events which can be either “relatively recent” (and considered as stored events or event objects) or “historic” (and considered as traditional data), although these are necessarily imprecise concepts. Access to historic data is typically carried out in CEP tools through good-old-database-services: calling the operational data store associated with legacy systems, for example. Another approach is to “event-ise” the legacy applications, extracting new events from logs and data sources as they occur.
TIBCO examples of the above approaches to data access in event processing are TIBCO BusinessEvents’ database interface (what we call DBConcepts) and TIBCO Adapters (e.g. for ERP and HR systems).
Notes:
The EPTS glossary does not define “data” but does mention that event objects contain data…
