CEP & Causality Example
Suppose one is interested in describing events involved in the spreading of a piece of gossip initially known by Joe. Joe tells Mary. Mary tells Pete. Pete tells Jim and Frank, etc. The event of telling someone creates a dependency between the event that makes someone aware of the gossip and the event that transfers this knowledge to the next person(s). These events and their causal relationships can be modeled as a table with the following signature.
Knows (teller, listener)
The rows in this database represent people who know the gossip (the teller column) and the causal relationship between that teller and the listener (in the listener column). Thus, an event database that stores six people who know the gossip might look as follows:
| teller |
listener |
| Joe |
Mary |
| Mary |
Pete |
| Pete |
Jim |
| Pete |
Frank |
| Jim |
null |
| Frank |
null |
Each event of telling the gossip to someone creates a new row. Note that causal relationships are modeled as embedded identifiers in the listener attribute. This attribute could just as well be named causes to indicate the causal path.
Questions regarding causality can be addressed through SQL queries. To determine who caused Jim to know the gossip, execute a simple lookup.
Determining and identifying all of the people who Jim is responsible for within two tellings, use a straight-forward self-join. While it may sound computationally expensive to use a self-join to follow relationships, it need not be if the proper indices are available.
Uncovering all of the people that Pete caused to know the gossip either directly or indirectly, perform a recursive query which SQL-99 now supports through the WITH RECURSIVE construct.
Other kinds of causal relationships can be computed in a similar way. Thus, causality can be represented and manipulated in relational databases.
« Previous 1 | 2 | 3 | 4 | 5 | 6 ] 7 Next »