Changes between Version 13 and Version 14 of BluePrintRegionsAndIncidents


Ignore:
Timestamp:
02/18/11 09:30:44 (11 years ago)
Author:
Pat Tressel
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrintRegionsAndIncidents

    v13 v14  
    131131Open for ideas -- please add suggestions here!
    132132
    133 An incident involves:
     133An incident might involve (at least):
    134134
    135135 * Personnel
     136  * Individuals
    136137  * Teams
    137   * Projects / work assignments
     138  * Projects / work assignments / work logs
    138139 * Material resources
    139140  * Vehicles assigned
    140141  * Inventory allocated
    141  * Associated entities (Are these simply tagged as being part of this Incident & we filter by default to the already-tagged ones, but can also remove this filter if we want to find a resource from the wider pool)
     142 * Associated entities
    142143  * Hospitals
    143144  * Shelters
    144145  * Other orgs involved
    145146  * Assessments
    146  * Information (e.g. work logs, instructions)
     147 * Information for responders & public
     148  * Documents
     149  * Social network ids / feeds
     150
     151What else could go with an incident?
     152
     153Re. associated entities: Fran: Are these simply tagged as being part of this Incident & we filter by default to the already-tagged ones, but can also remove this filter if we want to find a resource from the wider pool? Pat: (NB: If we use relationship tables (see below), no tag is applied to the entity itself.) If the user selects an incident, we'd apply a filter where appropriate -- probably this should be the default, i.e. assume the user is interested in entities already associated with the incident. The user would need a way to turn off the filter in order to find and add entities to the incident.
    147154
    148155==== Use an org ====
     
    150157
    151158==== Use relationship tables ====
    152 Many types of entities are associated with an incident.  The "relational" way to tell which entities go with which incidents, without adding fields to entities, is to use relationship tables that associate an incident with each of the types.  That is, there could be an "incident assessment" table in which each record has a foreign key reference to an incident and to an assessment, and so-on for the other associated types.  This allows overlap between incidents -- one entity can be associated with more than one incident.  Additional data can be included in the relationship tables, such as a start date and end date.  When an entity is no longer needed for an incident, it's relationship can be deleted or "expired" by setting an end date.
     159Many types of entities are associated with an incident.  The "relational" way to tell which entities go with which incidents, without adding fields to entities, is to use relationship tables that associate an incident with each of the types.  That is, there could be an "incident assessment" table in which each record has a foreign key reference to an incident and to an assessment, and so-on for the other associated types.  These relationship tables are components of incident.  Use of relationships allows overlap between incidents -- one entity can be associated with more than one incident.  It's simple to associate another entity type with an incident -- just add a relationship table.
     160
     161Additional data can be included in the relationship tables, such as a start date and end date.  When an entity is no longer needed for an incident, its relationship can be deleted or "expired" by setting an end date.
    153162
    154163If a "paper trail" is needed, i.e. a record of what was used for each incident, and when, or who worked on it, and when, there are several ways of providing that.  One is to add start and end dates to the relationship tables.  If someone / something stops being associated with an incident, its end date is set.  If that person / resource later comes back to the incident, a new relationship record is created.  (Think of keeping a log of hours worked on each of several consulting projects -- a simple way is to record start and end times for each work session.)  Since those old records could clutter the table over time, and slow access, one could dump / pickle historical data, or move it to a parallel set of "expired" relationship tables.  Keeping it online would be more convenient for preparing reports.  Simplest is to leave them in the main incident relationship tables but set their end dates.