What's the Difference Between Events and Data?

Events are a type of data. What is special about events is that they are created at a specific point in time and signify that something meaningful has happened. Somebody has judged that when something happens or someone does something, it is important and an event record should be created. As such events are a very important type of data for business intelligence purposes because analyzing them should usually lead to some action, automated or manual.

While there is a close relationship between the two; I don't believe events and data are mutually exclusive. Data can be described as a collection of information derived from prior events. While an event is an action or verb that contains information that can answer questions that can be stored as data or passed along to a subsequent event.

Based on the various touch points between events and data I don't think about it in terms of "differences" but rather the relationships that can exist between the two.

Data can be a temporal version of events; for example monthly account balance or daily stock price.

Events contain some forms of data; answering questions of who, what, where...Who executed the data, what day did the trade execute

While an event can also occur with out requirement of existing data; it can also be enriched by existing data during processing. Is this equity transaction in compliance or within acceptable boundaries of risk.

I'm so glad to see someone dealing with this! Perhaps next you'll ask for contradistinction "tag" and "category"?

(I found myself remembering Finite State Modelling when I first read your quest, but won't go there right at the moment.)

I'd like to suggest that it has everything to do with salience. But first, let me explore what I describe as a continuum, i.e.:
static/noise => signal/data => information

That "we" (our company) have thingamabobbles as a production input is known. So that we have X thingamabobbles is known.
"42 thingamabobbles in stock" is data. But "42 thingamabobbles in stock; we'll need 80 for this week's production, and the next shipment in is next Tuesday" is a whole different constellation. To describe "we don't have enough thingamabobbles" as information understates the case!

I'd call "thingamabobbles levels fall below requirement" as an event.

@bentrem

p.s. information as "data that matters" is handy; what I'm grappling with is how some information is narrative while other is salient to a pending decision.

The way I think about Events and Data are that Events represent Data that do not have value beyond a defined period of time.

For example, if you place a Buy order with your broker for company X at $35 a share and Sell order for Company Y at $20 a share to cut your lossses, the date and time that Company X shares reach $35 and company Y reaches $20 are all events. If the broker executes those orders at say $35.25 and $20, those are data but still the events that trigger them are $35 and $20.

Events have to do with real-time happenings that signify some action or culmination of some thing. Data may capture the information around those events and may become information and when consolidated become Intellgence.

For a long time in Business Intelligence we have been ignoring events. They are just as important as Data. Toyota encountering all those complaints about out of control cars are events. Their current sales and losses are all part of the data that resulted from those events!

Events do have intrinsic value, since they can be thought of incident/response pairs for business capabilities. The event value gradient is bound by how quickly an organization can respond to it - similar to risk management. The longer the period between the event occurrence (or incident) and event response, the more less value is realized (or more risk is taken on) by the organization. That curve is what has been used to justify the value of operational intelligence vs. traditional business intelligence implementations. In the past year, we've recommended to our clients to reposition their intelligence investments away from BI and toward OpIntel.

Regards,

Aleks

It's tempting to think that events are "data that do not have value beyond a defined period in time"... but I think in reality, that's true of all enterprise information.

For example a list of customers is valuable for a while, but if you don't keep it up-to-date then after a few months it might be pretty useless.

However there's some truth to the fact that time is a distinction in some way: in this respect, the difference is really all to do with the rate at which the value of the data decreases.

Commonly in "event processing" scenarios the value of a piece of information lasts only a few seconds at most; whereas other enterprise information (you might think of this as "information at rest"; I think of it as "persistent event shadows") might still be valuable after days, weeks or months.

An event is a thing that happened. A tree fell. A phone rang. A dog jumped on the UPS guy.

The digital recording and notification that the thing happened is data.

See: http://blog.elementallinks.net/2006/07/omg_soasig_meet.html

Also: what Brenda said.

Events and event driven relationships - authored and tacitly captured metadata on who did what, when, to what - can add invaluable long-term context to other forms of data that for navigation, search, correlation, and relevance ranking.

Why Enterprise Search Sucks: http://traction.tractionsoftware.com/traction/permalink/Blog713

Taking the cue from the classic definition of OOPS (Object Oriented Programming System), 'Data' defines the state of being of an entity while 'Events' refer to any activity that has the potential to change the entity's state of being (or data). In the OOPS world, data is encapsulated by functions that have the ability to change the data.

The concept of data & entity does have a profound impact in the way BI applications are modeled, analyzed and interpreted. A good BI system should not only have the ability to capture & store data but should also have the flexibility to capture the events (remember the 'accumulating snapshot' fact table grain) that drive changes to data elements.

An event denotes something that takes place at a specific date and time that can be identified with a well defined meaning having a specific terminology for a particular context.

Data can be associated with the event in several ways.

1. There can exist metadata that provides information about the event itself.

2. Information that the event either uses for its particular purpose or creates because of its purpose.

What's interesting about events and data (I agree with the earlier post declaring that data is the digital representation of an event) is that the barrier to collecting data on events is getting lower. With more digital devices in place(electric meters, tags, surveillance devices etc.) that generate data automatically, many many more events can now be captured and recorded at almost zero cost.

The opportunity is to learn how to use this high volume of "data fragments" from lots of events to make better decisions. This is where traditional approaches to data management fall short since they cannot recognize patterns and communicate the potential impact quickly enough to make a difference.

With this in mind, perhaps it would be better to focus on the contrast between an application using moderate volumes of high value data (orders, trades etc.) vs. one that uses very high volumes of relatively valueless data points (5 minute meter reads, clicks etc,).

It's no doubt that these two are different (I agree with the most of said above) yet I found that most of events we deal with in process management may be considered as creation, updates or deletion of certain data records. It happens so often that I wonder: are there really other events than these three types?
Of course we may take the opposite perspective of an event creating a data record. But the data is what we have to deal with anyway so it's tempting to subordinate events to data in sake of simplicity.