Ligar para um número de emergência como 911 ou 112 não é algo que esperamos, mas ficamos felizes em tê-lo quando precisamos! Do outro lado da linha, é um trabalho estressante e há pouco espaço para erros. Tudo precisa funcionar perfeitamente.
Hoje, vamos dar uma olhada no modelo de dados que um serviço de emergência pode usar para processar e responder às chamadas recebidas.
Ideia
Os números de emergência diferem de país para país. Os números 911 (América do Norte e alguns outros países) e 112 (Europa e partes da África e Ásia) são amplamente utilizados. Esses números são usados para entrar em contato com todos os três serviços de emergência (polícia, ambulância e bombeiros e resgate) em uma chamada. Alguns países usam um número diferente; outros não têm um número de emergência centralizado. Neste modelo, vou me concentrar em situações em que existe um número tão centralizado.
A ideia principal é que, quando alguém faz uma ligação, um operador cuida dessa ligação, coleta todas as informações relevantes e encaminha essas informações para os responsáveis. Um exemplo pode ser um acidente de carro:após receber a ligação, o operador deve saber onde ocorreu o acidente e qual a gravidade. Eles podem então enviar a polícia e uma ambulância para lidar com a situação. Outro exemplo poderia ser um incêndio em um prédio de apartamentos, que poderia exigir todos os três serviços de emergência.
Modelo de dados
O modelo de dados consiste em três áreas de assunto:
Countries & citiesCallsActions & services
Descreveremos cada uma dessas áreas de assunto na ordem em que estão listadas.
Países e cidades
Esta área de assunto não é específica para este modelo, mas ainda é necessária para rastrear os locais de origem das chamadas.
Temos apenas duas tabelas nesta área temática. O
country A tabela contém uma lista de country_name ÚNICO valores. Podemos esperar que teremos apenas um país aqui porque os serviços de emergência funcionam principalmente em nível nacional. Em um país maior, essa tabela pode ser usada para armazenar nomes de estado ou província. Uma lista de todas as cidades e vilas é armazenada na
city dicionário. Para cada cidade, armazenaremos uma combinação ÚNICA de country_id - city_name . Podemos esperar que esta tabela contenha uma lista de todas as cidades e vilas de um determinado país. Chamadas
Existem duas áreas de assunto específicas para este modelo de dados:
Calls e Actions & services . No fluxo do tempo, as chamadas vêm primeiro e acionam outros eventos. Portanto, descreveremos esta seção primeiro. 
As
Calls área de assunto é composta por cinco tabelas. Enquanto a call table é obviamente a central, descreveremos as outras quatro tabelas primeiro porque todas são referenciadas na tabela de chamadas. Os usuários iniciam chamadas usando seus telefones fixos ou celulares. Precisamos armazenar cada número que ligou para 112 ou 911, então precisaremos de um
phone_number tabela. Cada vez que uma nova chamada é iniciada, verificamos se o número já existe nesta tabela. Caso contrário, inseriremos uma nova linha. Para cada registro de tabela, armazenaremos:phone_number– O número que iniciou uma chamada.number_status_id– Uma referência aonumber_statusdicionário. Este valor deve indicar se o número que fez o “primeiro contato”, está na “lista negra” ou “bloqueado”, etc. Este valor pode nos ajudar a decidir o que fazer, por exemplo. não criar uma nova chamada se um número estiver bloqueado, emitir um aviso se um número estiver na lista negra ou simplesmente registrar informações para o operador.notes– Todas as notas relacionadas a esse número, inseridas por qualquer operador. Este não é um campo obrigatório e conterá principalmente valores NULL.
O
operator tabela é usada para armazenar uma lista de todos os operadores que recebem chamadas. Para cada operador, armazenaremos um operator_code ÚNICO (uma designação interna), o first_name do operador , e seu last_name . Não armazenaremos detalhes aqui, como informações de contato dos operadores ou um sinalizador indicando se o operador está ocupado ou não. Para cada chamada, queremos atribuir um determinado status. Para fazer isso, primeiro precisamos de um
call_status dicionário. Este dicionário contém um conjunto de status_name ÚNICO valores. Alguns valores esperados são:“chamada interrompida”, “chamada interrompida”, “chamada bem-sucedida” e “chamada redirecionada”. Agora estamos prontos para descrever a
call tabela. Uma chamada é iniciada pelo chamador. Depois que o número é inserido no banco de dados (se for um número anteriormente desconhecido), a chamada também é inserida. Para cada chamada, precisaremos armazenar:operator_id– Uma referência aooperatorque recebeu esta chamada.phone_number_id– O número que fez a chamada. Em quase todos os casos, esse atributo conterá um valor referenciando ophone_numbertabela. Ainda assim, deixei uma opção para inserir uma chamada sem número de telefone. Isso pode acontecer quando um número estiver oculto ou se houver algum tipo de erro de rede.call_status_id– Uma referência aocall_statusdicionário que descreve o resultado da chamada. Este valor será inserido no final da chamada.city_id– Uma referência àcitydicionário, denotando a cidade onde foi feita a chamada. Também pode ser NULL, pois essas informações podem ser desconhecidas ou desnecessárias.call_start_time– Indica quando a chamada foi iniciada. Pode ser NULL em alguns casos especiais, por exemplo. o operador ouviu o toque da linha, mas a chamada nunca foi realmente estabelecida.call_end_time– Quando a chamada terminou. Este valor será atualizado no momento em que a chamada terminar. Ele conterá um valor NULL se a chamada nunca foi iniciada ou se a chamada foi iniciada, mas ainda está em andamento.notes– Todas as notas, em formato textual livre, que o operador inseriu relativamente a esta chamada.
Ações e Serviços
Depois que uma chamada é feita, é hora de agir. Essas ações devem alertar automaticamente os serviços de emergência necessários; também devemos ser capazes de inserir ou remover alertas conforme necessário.
Para cobrir isso, usaremos mais cinco tabelas.
No
emergency_service tabela, armazenaremos uma lista de todos os serviços de emergência disponíveis. Esta tabela contém um service_name ÚNICO e qualquer informação necessária para estabelecer um contato. As informações de contato são armazenadas em um formato estruturado semelhante ao JSON em contact_details atributo. Alguns dos serviços de emergência esperados são “polícia”, “bombeiros” e “ambulância”. Ainda assim, poderíamos ter outros também, como “resgate na montanha”, “guarda civil”, etc. O
action_catalog dicionário contém uma lista de todas as ações possíveis que podem ser necessárias como resultado de uma chamada. Esta tabela contém uma lista de tais action_name EXCLUSIVOS valores. Alguns valores esperados aqui são “alertar todos os serviços”, “alertar ambulância”, etc. Agora precisamos definir uma lista de todos os alertas que devem ocorrer automaticamente quando uma ação é atribuída a uma chamada. Esses valores são armazenados no
alert_service tabela. Armazenaremos o par UNIQUE action_catalog_id – emergency_service_id , denotando que um determinado serviço de emergência deve ser contatado quando esta ação for atribuída. Ainda assim, às vezes podemos querer revisar isso, então deixarei uma opção para fazer isso. Se o sinalizador always_alert estiver definido como True, enviaremos este alerta sem supervisão manual; caso contrário, o operador pode intervir. A atribuição de uma ação a uma chamada é feita por meio do
action_required tabela. Podemos precisar ter mais de uma ação para cada chamada, então precisamos desta tabela. Armazenaremos a combinação ÚNICA call_id – action_id bem como as notas, se houver, inseridas pelo operador. A última tabela em nosso modelo é o
alerted_service tabela. Pares ÚNICOS de action_required_id – emergency_service_id denotam os alertas reais que foram iniciados para essa ação (e chamada). Estes serão todos os registros com o alert_service.always_alert definido como Verdadeiro e todos os alertas definidos manualmente depois que o operador os revisou. Possíveis melhorias
Este modelo é apenas a espinha dorsal de uma solução possível. Posso sugerir pessoalmente muitas melhorias:
- Como os dados dos operadores são armazenados.
- Incluindo a possibilidade de rastrear o que aconteceu depois que os serviços de emergência foram alertados.
- Permitir que um operador inicie uma chamada.
- Relacionar eventos no banco de dados para que possamos definir se uma determinada chamada está relacionada a outra chamada, ação ou alerta. No momento, sabemos apenas o pedido deles.
Como funcionam esses serviços em seu país? Perdemos alguma coisa? O que você adicionaria ou removeria deste modelo? Por favor, conte-nos nos comentários abaixo.
