Database Issues

Creating simulations using fire modeling techniques is a time consuming process. For fire fighting personnel, it would be helpful if there is a visual depiction of the growth and spread of fire. But it would be prohibitive to use fire modeling techiques in real time, since time is of essence. Our solution is to create a database of simulations carried out apriori, connect this database to the sensors in a building and provide visual depictions of predicted futures (based on retrieving the simulations which best match the fire).

The database is mainly constrained by the need for fast access and retrieval.

The schema for the database is shown below. There are two tables based on the following considerations:

Spatial distance between sensors

Sensors (s_id:int, neighbour1:int, neighbour2 :int, neighbour3:int)

The attributes in the table are sensor ids. Each sensor is given a unique number as identification. The next attribute is again the Sensor attribute which is nearest to the indexing sensor id.
Primary key is sensor number (s_id).
Constraint: In this table the order is contained within the attributes themselves. The first column is the sensor in consideration . Its neighboring columns provide the information about the nearness in space to that sensor. It is possible that two sensors are equidistant from the given sensor and in that case they are stored in no particular order. Thus, for a given sensor (a single tuple ) Sensors.neighbour1 would give the nearest sensor, Sensors.neighbour2 the second nearest (or equidistant) and so on. This design is again dictated by the need for minimal computation. Again note that there are no predicate matches / comparisons required. This apriori ordering saves a large number of computations since most queries for finding the nearest neighbor of a given sensor requires accessing consecutive columns.

Temporal distance between sensors in each simulation

Firedata (sim_id:int, s_id:int, going_off:int, time:float)

The attributes in order are the simulation ID, sensor ID, going off number and time. Each tuple represents a simulation in which the particular sensor is the nth to go off at some real time.
The primary key is (sim_id, s_id).
Constraint:Depending upon the number of sensors in the structure under consideration, there are several tuples with the same simulation ID. For example, say there are 8 sensors in a room. Then a simulation of that room might have 8 sensors going off in a particular sequence. We will have at most 8 tuples in the firedata table for each such simulation. The time is represented in seconds.

Matching real fires and simulations

The database is queried to retrieved simulations which are similar to a real fire situation. The input parameters to the querying algorithm are the activated sensors along with the activation times. It is highly important to have an efficient matching algorithm since time is a critical factor for fire fighting personnel. The paper, Matching Fires and Simulations by Jayesh Govindrajan, Prof. Matthew Ward and Prof. Jonathan R. Barnett looks into several considerations for the matching algorithm.