Llamar a un número de emergencia como el 911 o el 112 no es algo que anhelemos, ¡pero nos complace tenerlo cuando lo necesitamos! En el otro extremo de la línea, es un trabajo estresante y hay poco espacio para errores. Todo tiene que funcionar perfectamente.
Hoy, veremos el modelo de datos que un servicio de emergencia podría usar para procesar y responder llamadas entrantes.
Idea
Los números de emergencia difieren de un país a otro. Los números 911 (Norteamérica y algunos otros países) y 112 (Europa y partes de África y Asia) se utilizan mucho. Estos números se utilizan para comunicarse con los tres servicios de emergencia (policía, ambulancia y bomberos y rescate) en una sola llamada. Algunos países usan un número diferente; otros no tienen un número de emergencia centralizado. En este modelo, me centraré en situaciones en las que exista un número tan centralizado.
La idea principal es que cuando alguien hace una llamada, un operador se ocupa de esa llamada, recopila toda la información relevante y reenvía esta información a los responsables. Un ejemplo podría ser un accidente automovilístico:después de recibir la llamada, el operador debe saber dónde ocurrió ese accidente y qué tan grave es. Luego pueden enviar a la policía y una ambulancia para manejar la situación. Otro ejemplo podría ser un incendio en un edificio de apartamentos, que podría requerir los tres servicios de emergencia.
Modelo de datos
El modelo de datos consta de tres áreas temáticas:
Countries & citiesCallsActions & services
Describiremos cada una de estas áreas temáticas en el orden en que aparecen.
Países y Ciudades
Esta área de asunto no es específica de este modelo, pero aun así es necesaria para rastrear las ubicaciones de donde provienen las llamadas.
Solo tenemos dos mesas en esta área temática. El country la tabla contiene una lista de country_name ÚNICOS valores. Podemos esperar que solo tengamos un país aquí porque los servicios de emergencia funcionan principalmente a nivel nacional. En un país más grande, esta tabla podría usarse para almacenar nombres de estados o provincias.
Una lista de todas las ciudades y pueblos se almacena en la city diccionario. Para cada ciudad, almacenaremos una combinación ÚNICA de country_id - city_name . Podemos esperar que esta tabla contenga una lista de todas las ciudades y pueblos de un determinado país.
Llamadas
Hay dos áreas temáticas que son específicas de este modelo de datos:Calls y Actions & services . En la corriente del tiempo, las llamadas son lo primero y desencadenan otros eventos. Por lo tanto, describiremos esta sección primero.
Las Calls El área temática está compuesta por cinco tablas. Mientras la call table es obviamente la central, describiremos las otras cuatro tablas primero porque todas están referenciadas en la tabla de llamadas.
Los usuarios inician llamadas utilizando sus teléfonos fijos o móviles. Necesitamos almacenar cada número que llamó al 112 o al 911, por lo que necesitaremos un phone_number mesa. Cada vez que se inicie una nueva llamada, comprobaremos si el número ya existe en esta tabla. Si no, insertaremos una nueva fila. Para cada registro de la tabla, almacenaremos:
phone_number– El número que inició una llamada.number_status_id– Una referencia alnumber_statusdiccionario. Este valor indicará si el número que realizó el “primer contacto”, está “en la lista negra” o “bloqueado”, etc. Este valor podría ayudarnos a decidir qué hacer, p. no crear una nueva llamada si un número está bloqueado, lanzar una advertencia si un número está en la lista negra o simplemente registrar información para el operador.notes– Todas las notas relacionadas con ese número, insertadas por cualquier operador. Este no es un campo obligatorio y en su mayoría contendrá valores NULL.
El operator La tabla se utiliza para almacenar una lista de todos los operadores que reciben llamadas. Para cada operador, almacenaremos un operator_code ÚNICO (una designación interna), el first_name del operador y su last_name . No almacenaremos detalles aquí, como la información de contacto de los operadores o una bandera que indique si el operador está ocupado actualmente o no.
Para cada llamada, queremos asignar un estado determinado. Para hacerlo, primero necesitaremos un call_status diccionario. Este diccionario contiene un conjunto de status_name ÚNICOS valores. Algunos valores esperados son:"llamada interrumpida", "llamada interrumpida", "llamada exitosa" y "llamada desviada".
Ahora estamos listos para describir la call mesa. Una llamada es iniciada por la persona que llama. Después de que el número se inserta en la base de datos (si es un número previamente desconocido), la llamada también se inserta. Para cada llamada, necesitaremos almacenar:
operator_id– Una referencia aloperatorque recibió esta llamada.phone_number_id– El número que realizó la llamada. En casi todos los casos, este atributo contendrá un valor que haga referencia alphone_numbermesa. Aún así, dejé una opción para insertar una llamada sin número de teléfono. Esto podría suceder cuando un número está oculto o si hay algún tipo de error en la red.call_status_id– Una referencia alcall_statusdiccionario que describe el resultado de la llamada. Este valor se insertará al final de la llamada.city_id– Una referencia a lacitydiccionario, indicando la ciudad donde se hizo la llamada. Esto también podría ser NULL, ya que esta información podría ser desconocida o innecesaria.call_start_time– Indica cuándo comenzó la llamada. Puede ser NULL en algunos casos especiales, p. el operador escuchó el timbre de la línea, pero la llamada nunca se estableció realmente.call_end_time– Cuando terminó la llamada. Este valor se actualizará en el momento en que finalice la llamada. Contendrá un valor NULO si la llamada nunca comenzó realmente, o si la llamada comenzó pero aún está en curso.notes– Todas las notas, en formato de texto libre, que el operador insertó con respecto a esta llamada.
Acciones y Servicios
Después de hacer una llamada, es hora de actuar. Estas acciones deberían alertar automáticamente a los servicios de emergencia requeridos; también deberíamos poder insertar o eliminar alertas según sea necesario.
Para cubrir esto, usaremos cinco tablas más.
En el emergency_service tabla, almacenaremos una lista de todos los servicios de emergencia disponibles. Esta tabla contiene un service_name ÚNICO y cualquier información necesaria para establecer un contacto. La información de contacto se almacena en un formato similar a JSON estructurado en contact_details atributo. Algunos de los servicios de emergencia esperados son "policía", "cuerpo de bomberos" y "ambulancia". Aún así, podríamos tener otros también, como “salvamento en montaña”, “guardia civil”, etc.
El action_catalog El diccionario contiene una lista de todas las acciones posibles que podrían ser necesarias como resultado de una llamada. Esta tabla contiene una lista de tales action_name ÚNICOS valores. Algunos valores esperados aquí son "alerta a todos los servicios", "alerta a ambulancia", etc.
Ahora necesitamos definir una lista de todas las alertas que deberían ocurrir automáticamente cuando se asigna una acción a una llamada. Estos valores se almacenan en el alert_service mesa. Guardaremos el par ÚNICO action_catalog_id – emergency_service_id , lo que indica que se debe contactar a un determinado servicio de emergencia cuando se asigna esta acción. Aún así, a veces es posible que queramos revisar esto, así que dejaré una opción para hacerlo. Si la bandera always_alert está configurado en Verdadero, enviaremos esta alerta sin supervisión manual; de lo contrario, el operador puede intervenir.
La asignación de una acción a una llamada se realiza a través de action_required mesa. Es posible que necesitemos más de una acción para cada llamada, por lo que necesitamos esta tabla. Guardaremos la combinación ÚNICA call_id – action_id así como las notas, en su caso, insertadas por el operador.
La última tabla en nuestro modelo es el alerted_service mesa. Pares ÚNICOS de action_required_id – emergency_service_id indican las alertas reales que se iniciaron para esa acción (y llamada). Estos serán todos los registros con alert_service.always_alert establecido en Verdadero y todas las alertas configuradas manualmente después de que el operador las revisó.
Posibles mejoras
Este modelo es solo la columna vertebral de una posible solución. Puedo sugerir personalmente muchas mejoras:
- Cómo se almacenan los datos de los operadores.
- Incluyendo la posibilidad de rastrear lo que sucedió después de que se alertó a los servicios de emergencia.
- Permitir que un operador inicie una llamada.
- Relacionar eventos en la base de datos para poder definir si una determinada llamada estaba relacionada con otra llamada, acción o alerta. Por el momento, solo conocemos su orden.
¿Cómo funcionan estos servicios en su país? ¿Nos perdimos algo? ¿Qué le agregarías o quitarías a este modelo? Cuéntanos en los comentarios a continuación.
