Skip to content

System Architecture

Jump to bottom
Linkesh Diwan edited this page Jun 19, 2013 · 8 revisions

Here are some details about the system architecture.

Database Schema

The following design is no way intended to be a complete design of the database. It is provided to be a reference to the developer.

Global ID Table

Disaster-wide Message ID (GID) | Internal ID | Has Response? | CSV of update GIDs

Why is this table necessary? Basically, each message that is entered onto a CrisisCommunicator is communicated to the others by radio broadcast (or whatever database synch method is finalized on). Therefore, it is necessary to have a unique message ID for every message across the whole disaster area. This is accomplished by giving each device it's own ID, and using that ID to generate disaster-wide unique IDs for each device.

"Has response" is a boolean, which enables other disaster response personnel to add information to a record.

Updates are broadcast as complete messages, but are stored as updates in the database.

Comments Table

Internal ID | CSV of Comments

Comments can be added by communications operators to any of the messages. This provides a kindof Facebook-like functionality, but it's meant for serious stuff, not trivial smileys. :)

Person

Internal ID | Person ID (pid) | Name | Age | Gender | .....

Depending on the situation, PIDs may be generated (similar to the disaster-wide message ID, GID), or may use government identifier numbers, if available.

User

Internal ID | pid | Role

Missing Persons Table

Internal ID | pid | source_camp | missing_since | ...

Refugees

Internal ID | pid | ...

Refugee Center

Internal ID | Center ID (cid) | Name | GPS Location | no_refugees | capacity | supplies_available_for

Center IDs Can be generated or named

Deceased

Internal ID | pid | time | ....

Supply

Internal ID | cid | Type of resource | Location | Description

Alerts

Internal ID | crid | Type | Location | Refugee Center | Description

Map specific tables

The software is expected to have maps functionality built into it, which would have a schema of its own. We're not experts in this, I expect that you know more than we do! One thing is definitely needed, that's the geo-coordinates.

Guidelines for DB Sync Daemon

The DB Sync Daemon is necessary to make sure that messages entered on one device gets entered on all devices in the area. It's job is to facilitate two-way synchronization of the database over small SMS-length packets.

More coming soon.

  • validate the messages before inserting into the DB (check if the message has all the required fields)
  • the records inserted by the user and the ones received from the test server should be validated.

Clone this wiki locally