tinydb.tex

tinyos中文手册,是根据tinyos系统自带手册翻译过来的,虽然质量不好,但是对英文不强的人还是有用的

\leavevmode
{\includegraphics[width=1.5in]{commandwin}}
\end{center}
\caption{Command Window}
\label{fig:command}
\end{minipage}
\end{figure}

\section{Using TinyDB\index{TinyDB}}
\label{sec:queries}
TinyDB provides a high-level, {\em declarative}\index{declarative}
language for specifying queries.  In a declarative language you
describe {\em what} you want, but not {\em how} to get it.
Declarative languages are advantageous for two reasons.  First, they
are relatively easy to learn, with queries that are easy to read and
understand.  Second, they allow the underlying system to change how it
runs a query, without requiring the query itself to be changed.  This
is important in a volatile context like sensor networks, where the
best underlying implementation may need to change frequently --
e.g. when motes move, join or leave the network, or experience
shifting radio interference.  In TinyDB, the execution strategy for a
user query can change each time the query is run, or even {\em while}
the query runs, without any need for re-typing the query or
recompiling an application that embeds the query.

Before describing TinyDB's query facilities, a few words on
TinyDB's data model are in order.  TinyDB implicitly queries one
single, infinitely-long logical table\index{table} called {\tt sensors}.  This
table has one column for each attribute in the catalog\index{catalog}, including
sensor attributes, nodeIDs\index{ID}, and some additional ``introspective''\index{introspection}
attributes (properties) that describe a mote's state.  This table conceptually
contains one row for each reading generated by any mote, and hence the
table can be thought of streaming infinitely over time.  A given mote
may not be able to generate all the attributes, e.g., if it does not
have the sensor that generates the attribute.  In that case, the mote
will always generate a NULL value for that attribute.

TinyDB's query language is based on SQL\index{SQL}, and we will refer
to it as TinySQL\index{TinySQL}.  As in SQL, queries in
TinySQL\index{TinySQL} consist of a set of
attributes\index{attribute} to select (e.g. light, temperature), a set
of {\it aggregation\index{aggregation} expressions\index{expression}}
for forming aggregate result columns, a set of {\it
selection\index{selection} predicates\index{predicate}} for filtering\index{filter}
rows, and optionally a grouping\index{group} expression for
partitioning the data before aggregation.  Aggregation
is commonly used in the sensor environment.  

Currently, TinySQL\index{TinySQL} results are very similar to SQL\index{SQL}, in that they
are based on snapshots\index{snapshot} in time -- that is, they are
posed over rows generated by multiple sensors\index{sensor} at one
point in time.  {\it Temporal}\index{temporal} queries that combine
readings over several time periods are not supported in the current
release.  Instead, TinySQL runs each query repeatedly, once per
time-period or ``epoch''\index{epoch}.  The duration of an epoch can be specified
as part of a TinySQL query; the longer the duration, the less
frequent the results, and the less drain on the mote\index{mote} batteries\index{battery}.


\subsection{The Query Window}
\label{sec:querywindow}
The query window provides a graphical interface for building queries.
As you use the widgets in the window, query text is dynamically
constructed in the text box in the middle of the screen.  This box is
also used for error messages.

\vspace{.1in}
\renewcommand{\baselinestretch}{1.0}\rm
\fbox{\parbox{.9\columnwidth}{
{\bf TIP:}The current query text can
always be refreshed by clicking on a column in the {\bf Available
Attributes} list.}}
\renewcommand{\baselinestretch}{1.2}\rm
\vspace{.1in}

The topmost widget in the window is the {\bf Epoch
  Duration}\index{Epoch Duration}\index{epoch} widget,
which specifies the interval at which the query is re-evaluated.
% Motes periodically take sensor readings from the environment, called
% {\em samples}\index{sample}, in order to generate rows in the {\tt
% sensors} table.  
We recommend that the epoch duration be set as large as possible to
minimize power drain on the motes\index{mote}.

To specify the query to run each epoch\index{epoch}, you first choose the
attributes and/or aggregate expressions\index{expression} to appear in the output.
Attributes are specified by choosing them in the {\bf Available
Attributes} list, and pressing the ``$>>>$'' button so that they
appear in the {\bf Projected Attributes} list.  Optionally, attributes
may be placed in simple {\em aggregate}\index{aggregate} {\em
expressions}\index{expression} by choosing an aggregate from the
pull-down menu in the middle of the screen (default: {\bf None}).  At
this stage, the Projected Attributes list must
contain either all aggregate expressions, or all attributes; a mixture
will result in an error message unless there is a GROUP BY\index{Group By}\index{group}
clause.  We will return to this point shortly.

To select only some of the rows to be considered in the query, you can
specify predicates\index{predicate} to filter\index{filter} the data,
via the {\bf New Predicate} button at the bottom of the screen.  All
the predicates you select will be implicitly ``AND''ed together.  ``OR'' is
not yet supported.

If you used aggregate expressions\index{expression} in your {\bf Projected
Attributes} list, you can also specify a GROUP BY\index{Group By}\index{group} column by
clicking on the {\bf GROUP BY} checkbox and selecting from the
pulldown menu.  The pulldown menu to the right of the GROUP BY column
is for right-shifting the (binary) value of the column before
grouping; each shift divides the value of the GROUP BY column by 2.
This has the effect of reducing the number of possible groups: the
more times you divide by 2, the fewer possible groups there can be.

After adding a GROUP BY\index{Group By}\index{group} column, you can now add it (unaggregated!) to
the {\bf Projected Attributes} by selecting it from the {\bf Available
Attributes} list and pressing the ``$>>>$'' button.  This is the only
way to mix aggregates and attributes in your query
output\footnote{Note that this restriction also exists in SQL\index{SQL}, and is
implicit in the meaning of aggregation.  The only non-aggregated
attributes that are meaningful in the SELECT list are attributes that
appear in the GROUP BY list.  As an example, consider a query
with {\em no} GROUP BY attributes.  It can only produce one output row
per epoch\index{epoch}, which contains aggregate values computed from all the
input rows.  It is not meaningful to ask for a raw attribute in the
output of such a query -- there can be multiple values for each
attribute in the input, so there is no well-specified unique value to
place in the single output column.  The same restriction applies in a
GROUP BY query, with the exception of the columns in the GROUP BY
expression\index{expression} -- these columns are guaranteed to have a
single unique value per group, and hence can appear alongside aggregate
expressions.}.

\subsubsection{Triggers}\label{sec:triggers}\index{triggers}

TinyDB includes a facility for simple {\it triggers}\index{triggers}, or queries
that execute some command when a result is produced.  Currently, triggers can be
executed only in response to some local sensor reading that satisfies the conditions
specified in the {\tt WHERE} clause of the query.  {\it Aggregate queries cannot
have triggers associated with them.}  Whenever a query result satisfies the
{\tt WHERE} clause of a query, the {\it trigger action}\index{trigger action} is executed.  This
action is a named command stored in the schema of the mote (see Section \ref{sec:schema}
for more information.)  

The current TinyDB interface includes simple trigger actions\index{trigger action} for blinking LEDs and
sounding the sounder \index{sounder} (the small speaker on the Mica sensor board.)  A trigger
action can be specified via the GUI by clicking the {\tt TRIGGER ACTION} checkbox and selecting the appropriate
action.  Other actions can be specified via the textual interface (see the next section) and the schema
API (described in Section \ref{sec:schema}.)  

As an example of what triggers can be used for, consider an application where the user wants to sound
an alarm whenever the temperature near a sensor goes above some threshold.  This can be accomplished
via the simple trigger query:

\noindent{\tt \hspace{.5in}SELECT temp\\
\hspace*{.5in}FROM sensors \\
\hspace*{.5in}WHERE temp > {\it thresh}\\
\hspace*{.5in}TRIGGER ACTION SetSnd(512) \\
\hspace*{.5in}EPOCH DURATION 512
}

\noindent The {\tt SetSnd} command sounds the sounder, and the value of 512 specfies a sound duration of
512 ms.



\subsection{Composing Your Own TinyDB Queries}
\label{sec:tinydbsqlsyntax}
When using TinyDB, it is also possible to write queries by
hand, either by using the ``Text Interface'' pane of the the GUI\index{GUI}
(which can be brought up by default by using the command-line \index{command-line} argument ``-text''), 
or via the {\tt SensorQueryer.translateQuery} API\index{API} call.  We assume here that
the reader has a familiarity with the basics of SQL\index{SQL}.  A number of
books and websites provide simple SQL tutorials.  No deep knowledge of
SQL is required to use TinyDB; the basics will do.  The simplest way
to learn TinySQL\index{TinySQL} is to use the graphical query
builder described in Section~\ref{sec:querywindow}.  However, we also
provide a simple, informal description of the syntax here.

TinyDB provides an SQL\index{SQL}-like query language, which is simplified in a
number of ways, but which also provides some new sensor-specific syntax.
TinySQL\index{TinySQL} queries all have the form:

\noindent{\tt \hspace{.5in}SELECT {\em select-list}\\
\hspace*{.5in}[FROM sensors] \\
\hspace*{.5in}WHERE {\em where-clause}\\
\hspace*{.5in}[GROUP BY {\em gb-list} \\
\hspace*{.5in}[HAVING {\em having-list}]]\\
\hspace*{.5in}[TRIGGER ACTION {\em command-name}[({\em param})]] \\
\hspace*{.5in}[EPOCH DURATION {\em integer}]

}
 
The {\tt SELECT}\index{Select}, {\tt WHERE}\index{Where}, {\tt GROUP
  BY}\index{Group By}\index{group} and {\tt HAVING}\index{Having} clauses
are very similar to the functionality of SQL\index{SQL}.
Arithmetic\index{arithmetic} expressions\index{expression} are
supported in each of these clauses.  As in standard SQL, the {\tt
GROUP BY}\index{Group By} clause is optional, and if {\tt GROUP BY} is
included the {\tt HAVING}\index{Having} clause may also be used optionally.

\subsection{TinySQL\index{TinySQL} vs. Standard SQL\index{SQL}}

\noindent
{\bf Limitations}
\begin{itemize}
\item The {\tt FROM}\index{From} clause must always list exactly one table\index{table},
entitled {\tt sensors}.  The {\tt FROM}\index{Having} clause is also optional.
\item In the current version the {\tt WHERE}\index{Where} and {\tt
    HAVING}\index{Having} clauses can contain only simple conjunctions
  over arithmetic\index{arithmetic} comparison operators.  There is no
  support for the Boolean operators {\tt OR}\index{Or} and {\tt
    NOT}\index{Not}, or string matching\index{string matching}
  comparisons (SQL's\index{SQL} {\tt LIKE}\index{Like} and {\tt
    SIMILAR}\index{Similar} constructs).
\item  There is currently no support for sub-{\tt SELECT}s\index{Select} (subqueries)\index{subquery}.
\item There is currently no support for column renaming
  (SQL's\index{SQL} {\tt AS}\index{As} construct) in the {\em
    gb-list}.
\item Arithmetic\index{arithmetic} expressions\index{expression} are
  currently limited to the form {\em column op constant}, where {\em
    op} is one of \{$+, -, *, /$\}.
\end{itemize}

\noindent
{\bf Sensor-Specific Features}\\

The {\tt TRIGGER ACTION} clause specifies an (optional) trigger
action\index{trigger action} that should be executed whenever a query
result is produced.  See Section \ref{sec:triggers} for more
information about triggers.  The command name must be a command
registered with the {\tt COMMAND} \index{command} component (see
Section \ref{sec:schema}.)  An optional integer parameter may be
passed to the command.

The time between epochs\index{epoch} is specified in the query via the
{\tt EPOCH DURATION}\index{Epoch Duration} clause.  The units for this
duration are specified in milliseconds.  If no epoch duration is
specified, a value of 1024 ms is used by default.

\subsection{The Command Line}\label{sec:commandline}
TinyDB provides a few simple command line \index{command line}
options, as follows:

\begin{itemize}
\item {\tt -text}: Start the GUI in the text panel.\index{GUI}
\item {\tt -gui}: Start the GUI in the graphical query input window (default.)
\item {\tt -cmdwindow}: Display the command window (overrides the
  config file (see Section \ref{sec:configfile}) setting.)
\item {\tt -configfile {\it filename}}: Loads the config file from
  {\it filename}.\index{configuration}
\item {\tt -run ``{\it query}'' }: Executes the specified query in
  text-mode (see Section \ref{sec:textmode}.)\index{text mode}
\item {\tt -debug}: Enable debugging messages (causes lots of messages
  to be printed on the command line.
\item {\tt -sim}: Connect to a simulated mote-network.  See \ref{sec:tossim} for
  more information.
\end{itemize}

\subsection{Event-Based Queries}\index{event,event-based,event-based queries}
\label{sec:event-queries}

Event-based queries begin running when a low-level ``event'' occurs.  Example
events are interrupt lines being raised on the processor or sensor readings
going above or below some threshold.  There are two steps involved in authoring
event-based queries:  defining the operating system event and registering
the query with TinyDB.  

To define an event, you must write a component that registers the event and
signals that it has fired whenever it occurs.  Registering events is much 
like registering commands and is covered in the TinySchema documentation which
should have accompanied this document.