JPT/bachelorthesis
0
0
Fork 0
Code Issues Pull Requests Activity

[TASK] Generic commit.

Browse Source
This commit is contained in:
Jan Philipp Timme 2016-09-29 10:51:23 +02:00
parent 74a5bebdbc
commit 7f69b83e27
2 changed files with 6 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

0
Bachelorarbeit.synctex.gz(busy)
View File

38
Bachelorarbeit.tex
View File

@ -395,7 +395,7 @@ Im Rahmen von Complex Event Processing werden Ereignisdaten als Instanzen von Er
Jedes Ereignis trägt abhängig von seinem Ereignistypen eine geringe Menge von Daten mit sich, die für das Ereignis spezifische Informationen enthalten. Dies können beispielsweise Daten von Sensoren, Angaben über eine Benutzersitzung oder Statusdaten eines Systems sein. Diese Daten sind jedoch nur \emph{Momentaufnahmen} und verlieren mit fortschreitender Zeit meist an Gültigkeit. Listing~\ref{lst:sample_abstract_car_status_event} zeigt beispielhaft eine Instanz des Ereignistypen \texttt{CarStatusEvent}.
\begin{lstlisting}[caption={Exemplarische Statusmeldung eines PKW in abstrakter Notation},label={lst:sample_abstract_car_status_event}]
CarStatusEvent(ID=2342, timestamp=1344829400, relatedCarNumber=11, speed=63)
CarStatusEvent(ID=2342, timestamp=1344829400, relatedCarID=11, speed=63)
\end{lstlisting}
Dafür treten diese primitiven Ereignisse häufig mit einer sehr hohen Frequenz auf, da ein komplexer Vorgang während seiner Durchführung eine Vielzahl von Ereignissen auslösen kann. Beobachtet man beispielsweise einen aus dem Stand anfahrenden PKW bis zu seiner Erreichung von 30km/h, so würde man zusätzlich zu periodisch gemeldeten Messwerten von Sensoren aus dem Motorraum und Informationen über Gangwechsel des Getriebes eine Flut von Informationen darüber erhalten, wie die Pedale durch den Fahrer bedient wurden oder wie das Lenkrades eingeschlagen wurde.
@ -603,28 +603,17 @@ Nachdem die Wahl der CEP-Engine auf die C-SPARQL-Engine gefallen ist, sollen in
\section{Ereignisse in RDF-Datenströmen}
Ereignisse werden aufgrund der Nutzung von RDF-Datenströmen als Transportmedium nun durch RDF-Tupel beschrieben. Diese tragen neben den typischen Inhalten von Tripeln (Subjekt, Prädikat und Objekt) nun eine vierte Information mit sich: den Zeitstempel, zu dem das Ereignis ausgelöst wurde. Da die Tupel nun mit dem Zeitstempel insgesamt vier Angaben enthalten, werden sie als \emph{Quadrupel} bezeichnet.
Ereignisse --- genauer: Ereignisinstanzen --- werden aufgrund der Nutzung von RDF-Datenströmen als Transportmedium nun durch RDF-Tupel beschrieben. Diese tragen neben den typischen Inhalten von Tripeln (Subjekt, Prädikat und Objekt) nun eine vierte Information mit sich: den Zeitstempel, zu dem das Ereignis ausgelöst wurde. Da die Tupel nun mit dem Zeitstempel insgesamt vier Angaben enthalten, werden sie als \emph{Quadrupel} bezeichnet.
Um die Ereignisquadrupel trotz identischer Ereignistypen oder Zeitstempel voneinander unterscheiden zu können, ist es nötig, die Ereignisse mit einer eindeutigen ID zu versehen. Um dies zu erreichen, werden die einzelnen Ereignisse als eigene, separate Subjekte in RDF repräsentiert. Dadurch erhalten alle Quadrupel eines Ereignisses eine eindeutige Zuordnung zu ihrem Ereignissubjekt.
Um die Ereignisquadrupel trotz identischer Ereignistypen oder Zeitstempel voneinander unterscheiden zu können, ist es nötig, die Ereignisse mit einer eindeutigen ID zu versehen. Um dies zu erreichen, werden die einzelnen Ereignisinstanzen als eigene, separate Subjekte in RDF repräsentiert. Dadurch erhalten alle Quadrupel eines Ereignisses eine eindeutige Zuordnung zu ihrem Ereignissubjekt.
Um dies zu verdeutlichen folgt nun ein kleines Beispiel. Gegeben seien zwei beispielhafte Ereignisse mit Statusdaten über einen PKW. Listing~\ref{lst:sample_abstract_event_data} zeigt diese beiden Ereignisse in abstrakter Notation.
\begin{lstlisting}[caption={Zwei Statusereignisse eines PKW in abstrakter Notation},label={lst:sample_abstract_event_data}]
CarStatusEvent {
ID: 324,
timestamp: 1344829400,
relatedCar: ->[Car(ID: 0)],
speed: 63
}
CarStatusEvent {
ID: 325,
timestamp: 1344829405,
relatedCar: ->[Car(ID: 0)],
speed: 75
}
CarStatusEvent(ID=324, timestamp=1344829400, relatedCarID=0, speed=63)
CarStatusEvent(ID=325, timestamp=1344829405, relatedCarID=0, speed=75)
\end{lstlisting}
Wie aus Listing~\ref{lst:sample_abstract_event_data} zu erkennen ist, ist jedes Ereignis ein eigenes Objekt, welches alle für sich relevanten Daten entweder direkt oder als Zeiger auf andere Objekte enthalten kann. Um diese über RDF-Datenströme zu transportieren, müssen diese Ereignisse mit RDF-Quadrupeln beschrieben werden. Listing~\ref{lst:sample_event_rdf_quads} zeigt die Beschreibung der Ereignisse aus Listing~\ref{lst:sample_abstract_event_data} mit RDF-Quadrupeln.
Wie aus Listing~\ref{lst:sample_abstract_event_data} zu erkennen ist, ist jede Ereignisinstanz quasi ein eigenes Objekt, welches alle für sich relevanten Daten entweder direkt oder als Zeiger auf andere Objekte enthalten kann. Um diese über RDF-Datenströme zu transportieren, müssen diese Ereignisse mit RDF-Quadrupeln beschrieben werden. Listing~\ref{lst:sample_event_rdf_quads} zeigt die Beschreibung der Ereignisse aus Listing~\ref{lst:sample_abstract_event_data} mit RDF-Quadrupeln.
\begin{lstlisting}[caption={RDF-Quadrupel mit Zeitstempeln beschreiben zwei Ereignisse eines PKW},label={lst:sample_event_rdf_quads}]
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@ -645,24 +634,9 @@ Wie aus Listing~\ref{lst:sample_abstract_event_data} zu erkennen ist, ist jedes
\section{Sprachkonzepte für C-SPARQL}
Um die Ereignisdatenströme von RDF-Quadrupeln nun in der C-SPARQL-Engine verarbeiten zu können, werden im Verarbeitungsprozess CEP-Regeln benötigt, um die Ereignisdaten auszuwerten. Im Fall der C-SPARQL-Engine sind CEP-Regeln als C-SPARQL-Queries zu formulieren. Anhand einer abstrakten CEP-Regelsprache soll dieses Kapitel veranschaulichen, wie die einzelnen Aspekte eines C-SPARQL-Queries zur Verarbeitung von Ereignisdaten verwendet werden können.
\begin{lstlisting}[mathescape=true,label={lst:sample_abstract_cep_rule},caption={Beispiel für abstrakte CEP-Regelsprache}]
CONDITION (SomeEvent AS e $\longrightarrow$ AnotherEvent AS a $\longrightarrow \neg$NoEvent)[Window:15min,SlideInterval:15s]
$\wedge$ e.foo = a.foo
$\wedge$ e.threshold > 42
ACTION
new FooEvent(Bla=42, Blubber=5)
\end{lstlisting}
\section{C-SPARQL als Sprache für CEP-Regeln}
\begin{lstlisting}[label={},caption={}]
CONDITION
...
ACTION
...
\end{lstlisting}
\paragraph{Sliding Windows}
Um mit der Verarbeitung von Ereignisdatenströmen beginnen zu können, müssen die kontinuierlich einströmenden Ereignisdaten auf eine endliche Menge an Daten reduziert werden. Da je nach Anforderungen ältere Ereignisse in die Verarbeitung mit eingebezogen werden sollen, muss eine CEP-Regel in der Lage sein, Einfluss auf das Sliding Window zu nehmen, indem sie dessen Größe definiert.