Changes between Version 13 and Version 14 of BluePrintRegionsAndIncidents
- Timestamp:
- 02/18/11 09:30:44 (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
BluePrintRegionsAndIncidents
v13 v14 131 131 Open for ideas -- please add suggestions here! 132 132 133 An incident involves:133 An incident might involve (at least): 134 134 135 135 * Personnel 136 * Individuals 136 137 * Teams 137 * Projects / work assignments 138 * Projects / work assignments / work logs 138 139 * Material resources 139 140 * Vehicles assigned 140 141 * 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 142 143 * Hospitals 143 144 * Shelters 144 145 * Other orgs involved 145 146 * Assessments 146 * Information (e.g. work logs, instructions) 147 * Information for responders & public 148 * Documents 149 * Social network ids / feeds 150 151 What else could go with an incident? 152 153 Re. 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. 147 154 148 155 ==== Use an org ==== … … 150 157 151 158 ==== 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. 159 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. 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 161 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, its relationship can be deleted or "expired" by setting an end date. 153 162 154 163 If 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.
